Jump to content
The Dark Mod Forums

Tels

Member
  • Posts

    14984
  • Joined

  • Last visited

  • Days Won

    23

Everything posted by Tels

  1. latest revision does not compile here: scons: Cannot explain why `build/release/core/renderer/draw_nv20.o' is being rebuilt: No previous build information found scons: *** [build/release/core/renderer/draw_nv20.o] Source `renderer/draw_nv20.cpp' not found, needed by target `build/release/core/renderer/draw_nv20.o'. scons: building terminated because of errors.
  2. After the Top 100 were determined, you can now vote again for "Mod of the Year"
  3. 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
  4. 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.
  5. 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".
  6. Sure, but for me often scripting is easier 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.
  7. 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:
  8. 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.
  9. Hm, and how do I update? "git pull" says "already uptodate" even tho I haven't updated for a week or longer.
  10. 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 );
  11. 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();
  12. 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
  13. 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.
  14. 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.
  15. Tels

    My models

    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.
  16. Tels

    My models

    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.
  17. 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.
  18. 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.
  19. 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.
  20. I can throw in a Geforce 9800 GT (The GT probably stands for "Great Turd"
  21. 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: http://fabiensanglard.net/doom3/dmap.php http://http.developer.nvidia.com/GPUGems/gpugems_ch09.html https://gamedev.stackexchange.com/questions/84297/stencil-shadows-doom-3-engine-precision-errors-shadow-cracks-why
  22. 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. 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?)
  23. 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...)
  24. @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.
  25. 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.
×
×
  • Create New...