Tels
-
Posts
14984 -
Joined
-
Last visited
-
Days Won
23
Posts posted by Tels
-
-
After the Top 100 were determined, you can now vote again for "Mod of the Year"
-
Though this would be more appropriate in one of the "offer help" subforums, I have plans to do a thorough write down of errors in the menu and HUD translations into Slovak that are currently present in the game. I am not sure whether the Slovak HUD and menu translation for TDM was machine-made (auto-translated) or not, but there are several glaring errors there. IIRC, when I switched on Slovak, most of the equipment items in a mission's purchasing menu had virtually nonsensical names. So, if no one is against it, I might give this effort a go in the coming weeks and months. Given that I actually work as a professional translator, this kind of topic has me itching.
Well, this and sound design, for the time being. 
(I'm sure I'll be gradually able to contribute more, hopefully up to finished FMs one day. 
)The script reports:
Generating slovak.lang... done, 47792 bytes, 1228 entries, 1065 ( 86.7%) not yet translated.
So I'd say the few entries we have are only a few test strings and are really likely done via an auto-translation
Help in finishing the slovak translation is really appreciated - it is one of the few languages we are missing
-
1
-
-
No, that is not what I meant. How do I update the repository on my maschine?
~/src/tdm_experimental/The-Darkmod-Experimental$ git pull Already up-to-date.
But that cannot be the latest revision, as I haven't updated it for at least 1 or 2 weeks, and you said you fixed stuff in the meantime.
-
It is supposed to work like that:
* triggering happens (or "auto_trigger" is "1" and the entity spawns
* "delay" seconds pass
* the message appears
So, if you put "delay" on the message entity and targeted it from worldspawn (or from a relay or a trigger), that is supposed to show the message after X seconds after the triggering.
Likewise, if you target the entity not at all,but put "auto_trigger" "1" on it and delay "2", the message is supposed to show after 2 seconds.
Does that make it clearer? The "delay" spawnarg in TDM entities usually applies to "x seconds delay after trigger event the action starts".
-
It's a matter of taste; since this map doesn't have an init script already, it was simpler for me to drop a couple of entities into DR.
Sure, but for me often scripting is easier
I tried "delay" on the message entity initially and as far as I remember, no, it didn't work. (Also, I may later want to set up other things on mission start, in which case having them all triggered through the same relay would help keep things organised.)
You need "auto_trigger", too. The spawnargs are generally documented on the entities, so you can look them up in DR. The wiki page is probably not uptodate.
-
Maybe they share the user and team database? Everyone who has an moddb account apparently has one at indiedb, but my password did not work there. Just asked for a reset.
(Edit: my password on moddb neither works, I probably changed it and the browser forgot it.
Edit 2: Yeah, they share the user database. I'm already a member of the team darkmod on indiedb despite never having used the site
)Oh and:
From: "Mod DB" <awards@moddb.com>
Subject: Your mod is in the top 100
Date: Thu, December 11, 2014 6:13 am
Hello mod developers!
You are recieving this newsletter because it appears a mod you are connected to has
made the 2014 Mod of the Year Top 100 -
-
Worldspawn triggers its target (I think it can have only one target) on mission start; you give it a target by selecting any worldspawn brush and giving it a target spawnarg as you would an entity. For example, in the map I'm making I have it pointing at a trigger_relay, which waits a moment and then triggers an atdm:gui_message to put a message on the screen at the start of the mission.
Just for the record: Such simple things like "wait a bit and then trigger a message" are literally 2 lines in the scripting code. No need for the trigger_relay and so on
But I guess we really need a tutorial for scripting And I think worldspawn can have many target spawnargs, if not, that would be a bug
Edit: And I forgot to mention, atdm:gui_message does support "auto_trigger" "1" and "delay" "2" and it would put up the message 2s after mission start. If that doesn't work as such, then that would also be a bug. "auto_trigger" is even documented, but "delay" not.
-
Hm, and how do I update? "git pull" says "already uptodate" even tho I haven't updated for a week or longer.
-
Another possibility is to change the entity def:
// entity 6 { "classname" "atdm:lamp_electric_grill__short_lit" "name" "lamp_auxiliary_room_test" "_color" "0.70 0.55 0.30" "light_center" "0 -8 0" "light_radius" "125 125 125" "model" "models/darkmod/lights/non-extinguishable/grill_light_short.lwo" "nodiffuse" "0" "noshadows" "1" "nospecular" "0" "origin" "136 -91 112" "parallel" "0" "rotation" "-1 1.11022e-016 0 -1.11022e-016 -1 0 0 0 1" "start_off" "1" }(set the color to the one you want)
and then use
$lamp_auxiliary_room_1.fadeInLight( 1.5 );
-
You need the right amount of parameters for each function. fadeInLight() takes the time:
scriptEvent void fadeInLight(float time);
So you can only fade in the light to the _already set in stone_ light color over a given time, but not set the light color AND fade it in over time.
The code atleast looks to me like it will:
* fade the light over time to the full, preset color * run On(), so it should also swap skins
But I'm not certain when the skin will switch, I think it is right before the fade completes. (which might not be what you want)
You might want to try this:
$lamp_auxiliary_room_1.fadeToLight( electricLightBright, 1.5 ); sys.wait( 1.5 ); $lamp_auxiliary_room_1.On();
-
I would the light to fade on, rather than just come on if it all possible. And worst case I can work around the issue by having a model with a colour_me skin and a plain light etc.
As you know, I know pretty much zero about the scripting language we use in the mod, so when you say "LightsOn()" instead of lamp_auxiliary_room_1.fadeToLight? how do you mean 'exactly? and would the "LightsOn()" arg be an instant on instead of fade-to on?
Steve's variant is much better. (But we really should document the script events a bit better, the doc doesn't mention that important difference that "fadeToLight()" only works on lights that are already on.
Anyway, if your light is an entity with the "tdm_light_holder" script object, then you can do:
$lamp_auxiliary_room_1.LightsOn();
If it is just a plain light, you can only call the script events that are documented in script/tdm_events.script. Basically, a script object attached to an entity provides extra functionality. See http://wiki.thedarkmod.com/index.php?title=Script_objects
-
It's the render light that you have to avoid referencing. It's ok to use the viewLight. That's what it's for, to keep the back end clear of the front end's modifications.
From tr_local.h:
// viewLights are allocated on the frame temporary stack memory // a viewLight contains everything that the back end needs out of an idRenderLightLocal, // which the front end may be modifying simultaniously if running in SMP mode.
Did you guys ever get round to creating an svn branch by the way?
If not what's the status of the git repo? Does it compile and run ok right now?
It doesn't link on my system, because libGLEW is too old (or incompatible or I don't have the 32bit variant. However, I just remembered getlibs:
~/src/tdm_experimental/The-Darkmod-Experimental/src$ getlibs -p libglew1.5 libglew1.5-dev The following i386 packages will be installed: libglew1.5 libglew1.5-dev Continue [Y/n]? Y Downloading ... Installing libraries ...
Not sure if that already fixes it.
-
Have you tried using "LightsOn()" instead of lamp_auxiliary_room_1.fadeToLight? fadeToLight bypasses anything and directly sets the color, so the light doesn't know it is now on, or off or changes the skin.
If LightOn() does not set the right color and fadetime, you can change that with spawnarg on the light entity before.
-
ASE models are smothed by default. If you want a sharp edge you need to split edges. But there are no problems making round objects. I guess ase exporter in Darkradiant exports brushes with split edges?
Good question.
On related terms, making things to appear more round is possible, f.i. we have materials for iron bars where you have a square bar and it appears round in game. It's only obvious at the ends of the bars.
This technique is probably not often used, instead patches with more faces are used.
-
In general, I'm not a fan.
1. I have no way to work on .ase models and have to rely on others to make changes if something is amiss. This has been a problem more times that I like to remember.
2. Models made in DR are not going to have a normalmap made from a high-poly model, so they're never going to be as good as models that do.
That said, there are some instances where it might make sense, like building facades that would be using stock textures anyway. Ultimately, I care about the overall quality of the model (assuming it's being put forward as a potential core asset), not how it was made.
In some cases, the DR models are "good enough", however. See some keys for instance. It really depends and I agree that the model quality should be the important thing, not how it was made.
-
I haven't quite got an answer to testing it on a candle yet, but I've done some research.
Steve, this is just fantastic research. Could you do me a favor and put these things on the wiki? The forums are a place where such things are easily lost (and not googable).
Edit: I think the smoke for the AI is used for the breath puff, and for the imp.
-
That seems unlikely to me, since dynamic lighting was very much a showcase feature for the Doom 3 engine when it came out.
But there is a difference between "fixed to position" lights, and "moving lights". And it also depends how many lights move each frame. Isuspect we are using not only many more lights, but also many more moving lights. Most lamp fixtures in D3 levels were fixed (e.g. neon tubes, or bulbs) while we have candles and torches, which oscillate. (And interestingly enough, they only oscillate to create live shadows, not because the light point itself needs to move.)
Also D3 levels never had more than 2048 entities, so I guess they were much much more limited.
-
... maybe moving lights weren't a factor in the original design.
Probably not, I don't think the original D3 had many moving lights. A few like the fireball from imps and rockets, but most stuff was fixed IIRC. We did some Very Bad Things™ like making the player light or candles oscillate every frame, which must be a performance killer if moving lights indeed update a lot of stuff.
-
Yeah, gonna be pretty interesting.
I can try this on an ancient G92b part (GeForce 300 OEM) and a high end 780ti.
I can throw in a Geforce 9800 GT
(The GT probably stands for "Great Turd" -
The pic above was a turbo shadow, so not related to dmapped shadows.
Like you, I assumed that dmap shadow optimisation would merge the smaller shadow into the bigger one, but for whatever reason it doesn't. Here's the same box reverted to worldspawn with its dmapped (green) shadows:
That's very odd, I could have sworn that the example of "merged" shadows was one of the reasons to implement this. But an idea occured to me: Are shadows only merged from different models, but not from the same? E.g. if the big and the small box are different statics, their shadows are merged, but not if they are one and the same (in this case it would result in a sort of self-shadowing optimization).
But then, I can't think that this (one or two entities) should make a difference to the code, maybe by accident?
Edit: A few interesting links:
-
I'll figure it out shortly... I'm working through the 7 (!) different ways of drawing shadows that are in the renderer right now but I could do with a break to look at something with a quicker reward
My guess is it's to do with bounds checks. The normal way a particle effect gets hidden from the renderer is by checking whether it can be seen, using the emitter's origin and the maximum distace of the quads from the emitter. That logic can't be applied where particles are independent of the emitter once released.
Yeah, but then you could put the quads into a quad-tree and cull them based on distance to the player. Using the emitter for the check is cheap, but not quite correct...
There is also the question on how much performance does it actually cost? A few thousand quads more or less is nothing for a GPU nowadays. Unless you compute the quads on the CPU as idtech4 does, then it becomes a CPU bottleneck. Maybe putting the particles to the GPU and compute them right there would help.
No need to be pessimistic! We will get it working, and nicely. As I mentioned a day or two ago in another thread, I'm planning to read up on particle systems from other games and propose something new for TDM this dev cycle anyway. It's a huge bonus to discover there's already an example of a completely customized particle system using the existing particle engine right here in our own code
I don't want to be begging here, but maybe we can create particles that use the physics system. Having smoke not pass through the ceiling, or other solids would be huge. It doesn't have to run on the GPU, tho
But maybe not re-inventingf the wheel and using an existing, open, particle system would be the way forward? (It is amazing that there isn't a usable lib for these things?)
-
Steve, you probably know more about shadows than me, but I remember that the reason for the dmap-shadows was that multiple shadows can be combined, e.g. if you have a stack of static crates, the shadows drawn can be simpler than if you have individual crates.
But from your pic, it looks like that is no longer the case. Maybe this optimization got broken somewhere in between? Or it only worked for certain cases?
It definitely would be good to test if just having a unified shadow calculation to be faster. (Likewise, the way finishSurfaces() recalculates shadows might be expensive...)
-
@Steve: What I meant to say in the last post is that it would be better if the SmokeEmitter quads where merged into the other code, and idSmokeEmitter just sets a flag and proceeds normally. If that is easy and possible, tho.
-
AHA! it never occured to me that smoke emitters use a different system (which really doesn't make much sense, it would be much better to have a system for both and optimize common sub-cases).
So, the firearrow trail probably uses the smoke emitter, like chimney stacks.
One problem with the smoke is that it cannot be turned on/off when the player leaves the visleaf, because that would mean when you return, suddenly the chimneys start to smoke and that looks bad. Probably that is why they use "draw it always".
For candles, that wouldn't matter much, tho.
@Springheel: I don't think it will be that easy. Only entities of the type "idSmokeEmitter" will create such particles, and the candle does not have such a thing. Technically, one could spawn such an emitter during extinguish, then remove it again afterwards. But sounds like a kinda heavy solution for such a small problem.
Would be much better that each particle could just specifiy which way it wants to work.
Revelator's TDM Branch
in The Dark Mod
Posted
latest revision does not compile here: