Jump to content
The Dark Mod Forums

HMart

Member
  • Posts

    1547
  • Joined

  • Last visited

  • Days Won

    10

Everything posted by HMart

  1. It is possible to override "core" files in TDM, without messing with the original files, from the beginning. This is a feature of the Doom 3 engine and obviously transitioned into TDM. In Doom 3 and TDM, you just make a copy of a def, mtr or any other file inside your mod or mission folder, respect the same virtual file path from the originals and the modified files will take precedence over the files inside the .pk4's. This could be used by mission makers to for example override the "noshadows" from some alpha materials, for example to permit trees, grass, banners, etc, in their mission to cast shadow maps, something the core materials can't do because they are limited by the need to support the old stencil shadows. But a brave mission maker, could recommend players to only use shadow maps on their mission and say, if a player wants stencil shadows they will have to accept that trees will cast ugly shadows. (I'm sure there's ways to automatically disable shadows for trees and such, when a user sets stencil shadows on, but it may take a bit of scripting madness...)
  2. HMart

    Risen 2... ARRR!

    Indeed sad times.
  3. I agree with @OrbWeaver, IMO DR is not the right tool to make models for Godot or any other engine using triangle mesh's only, if anyone wants a simple and relatively easy 3D tool (but still very powerful in the right hands) to make models, I personally recommend Wings3D instead, is free as Blender, way less complex (no animation/bones support) and it supports obj, collada, and other formats.
  4. This is what I personally know about it: No diffuse means "skip the diffuse path code for this light" essentially means don't add/mix this light color/texture color info unto the surface, only use it as a simple b&w light. No specular is essentially the same but for specular textures, it skips the specular component/code/calculation and makes the light less heavy by removing the specular effect. About performance impact, for today GPU's, I don't think is as important as it was in 2004, but still, I'm sure it does have a small impact on performance, for the better of course, specially if done for many lights, but will also make them way more unrealistic. Btw lights with both no diffuse and nospecular, were used for the "projected shadows" or lights used to project fake "shadows" unto surfaces, this was used in Doom 3 to simulate basic, shadow mapping, for rotating fans and grid materials that use alpha textures, all because stencil shadows ignore those. Now that TDM has real shadow mapping, IMO such lights are less necessary and I wouldn't recommend their use for such effect. Thou lights with no specular and no normal mapping, are still useful for some effects, like simulating casting colored light from painted glass, like something bellow, and they are faster then normal lights:
  5. HMart

    Risen 2... ARRR!

    Is all a matter of opinion and tastes but to me, Risen 1 was awesome, with its indie Gothic feel, I'm even replaying it today. Risen 2 was cool for many hours I most say but I reached a point, got bored and never finished it. Risen 3 somehow I never played more than 10 minutes of it, it just didn't get me.
  6. What do you mean? If you are talking of the second par of brackets then in my experience, materials are done like this. [material name] { [global material options] { //material stage 1 or draw call 1 [local stage1 options] } { //material stage 2 or draw call 2 [local stage2 options] } ... } So those brackets are used to define individual material stages or "layers".
  7. Oh that makes sense! I didn't thought of that, it was just that "ai_see" keyword throwed me off, because to me implied more "object is or not visible to AI", so I wondered why not put that in the object .def file or mark it in the editor with a spawnarg? But, yes now I see why, you may want to mark some individual surfaces as see through for AI, but still imo the keyword could be made more descriptive, for a material, like "aiSeeThrough" for example.
  8. Glad it worked it means that is a global material token, btw those 2nd brackets are called "stages" and a single material can have more than one stage (draw call). But I still don't get the reason why an AI vision feature, is handle at the material level?! Normally you mark a entire entity/model invisible to the AI, not just a single surface on a model.
  9. Not a TDM developer so perhaps that is how it works but why would such a thing as "ai_see 0" be a surface/material token?! That to me sounds more like something that should be on the light entity definition the .def file not the .mtr file, but I don't really know. Also if it is a real material token, try putting it at material global section, where the description is, outside the second pair of brackets.
  10. Why? What did I miss? And personally I don't have the asset pack and if I add I would do what you demand. Just curious why you decided to do this.
  11. Yes a gui editor would be cool but IMO is very easy to just have the game running the gui in real time, edit the code, press a key bound to reloadGuis and see the gui update ingame, in almost real time, that is the main reason idSoftware never did a gui editor. And the one the Quake 4 dev's (Raven software) made is unfinished (the above may explain why...), very bare bones and I don't recommend using it, specially in TDM.
  12. My implementation is just a simple gui script cmd, is very naive and just follows the same system of other existing gui script cmds, made by idSoftware. I have zero idea if is synchronous or asynchronous that is beyond my expertise, nor if it is the same as done in Quake 4. Plus like I said above I do remember experiencing some small problems with it, when trying to use it to call more complex namedEvent's, that may be connected to the "synchronous or asynchronous" stuff.
  13. There's ages that a wrote scripting for TDM or idTech4 in general but I think something like this should work. float objstate = $player1.getObjectiveState(objNum); if(objstate == OBJ_INVALID) { sys.print("warning invalid Objective found!"); } else if( objstate == OBJ_INCOMPLETE ){ sys.print("Objective is not complete. Please find all the apples."); } else if(objstate == OBJ_COMPLETE ){ sys.print("Objective is complete. Congrates you have all the apples!"); } else if(objstate == OBJ_FAILED ) { sys.print("Objective failed. The time to get all the apples as passed!"); } edit: modified the script code to be more correct according too @Dragofer suggestions bellow.
  14. I updated for the new build and saw overly bright plates in "The House of deLisle" mission.
  15. More or less, it doesn't save any real brush data in it, it is more like a "tag", is a peace of memory where info that should represent the entire "world" is defined and handled and brush data is "tagged" has THE worldspawn. Again is where all map data that should effect the entire map is handled, it is where the map script is run/called and other global stuff.
  16. Afaik worldspawn is also a entity ( at lest in c++ it is a instance of idEntity), the only diference is that is a entity that represents all brush data.
  17. Nice knowing you are looking at this. Btw when I made my own version of "namedEvent" gui cmd, I just copied the convention of other gui cmds like the "localSound" cmd, what I found is that it made the usage of simple nameEvents in GUI's very fast, with no need to mess with c++ and compile the engine. I think exactly the same reason quake 4 developers said they implemented it, thou like you said we don't know how they made their version. Perhaps is why I had some issues with my implementation when trying to call more complex onNamedEvents, so is something that needs to be well tested. Simple example of usage (the following code is untested and should be looked as "pseudo" code) windowDef Desktop { rect 0,0,640,480 backcolor 0,0,0,1 menugui 1 float "text_state" 0 onInit { // just in case ... if("Desktop::text_state" != 0) { set "Desktop::text_state" "0"; } } //*************** Events ************************* onNamedEvent ClearText { set "Text::text" ""; set "Desktop::text_state" "0"; } onNamedEvent SetText { set "Text::text" "Hello world"; set "Desktop::text_state" "1"; } //************************************************ windowDef Text { rect 240,41,165,110 visible 1 forecolor 1,1,1,1 text "" textscale 0.5 font "fonts/micro" textalign 1 } windowDef back_btn { rect (320-55),(240-35),50,30 visible 1 text "Click Me" textalign 1 textscale 0.3 font "fonts/an" onActionRelease { if("Desktop::text_state" == 1){ namedEvent "ClearText"; } else { namedEvent "SetText"; } } } }
  18. yes but this requires that you make a copy of the original .def file where the text entity is defined, that I personally don't know where in TDM (in Doom 3 is in misc.def) and make a def folder for your own mission where you put the .def file copy (your copy will override the original def file, when your mission is played). see the new "text" default var entityDef text { "editor_color" "1 1 0" "editor_mins" "-4 -4 -4" "editor_maxs" "4 4 4" "editor_showangle" "1" "editor_rotatable" "1" "editor_usage" "Used to display debug text in a level" "editor_var text" "text to print" "editor_bool force" "if set to 1 prints always otherwise only in developer mode" "editor_bool playerOriented" "if set to 1 text always faces the player" "editor_var scale" "text scale" "scale" "0.25" "text" "default text shown for all text entites" "spawnclass" "idTextEntity" }
  19. Sikkmod has some cool shaders indeed but wasn't the old ARB2 render totally removed in TDM and now only uses the modern GLSL one? At lest that is what I seem to have read some time ago. So if the ARB2 render was removed, sikkmod shaders will not work in modern TDM as is they would need to be converted to GLSL, don't know how hard that is.
  20. This is why AAA developers have specialized lighting artists in house, is very important for the mood of a scene indeed.
  21. Unfortunately many things in this engine are best done on the editor and then called through script, not created directly through script, one of them afaik is triggers. You normally create a trigger by creating a square brush on the editor manually, and give it the trigger_hurt material, so the size and shape comes from that brush, it also creates the physics (a clip model) automatically, then just need to use the script function, entity ent = sys.FindEntity("entity_name"); To get it and use it in the script to do whatever you want. Creating a clip model from script, is probably possible, thou I never did it, so I don't know how... thou I do know how to do it through c++. But I don't think there's any equivalent script functions exposed to the script system, if I'm mistaken please anyone correct me. Perhaps something to recommend in the TDM roadmap?
  22. Can you show the actual script code? Is better to know what is really happening, at lest to me, because at first glance it should work. But you should know that I'm not a TDM mission maker, even thou I do know a fair bit about idTech 4 scripting and c++ coding, but because of the changes done to TDM engine and scripting, what i know may not apply in TDM. But in any case are you really sure you are calling PlayerHealth = $player1.getHealth(); sys.print("health now = " + PlayerHealth + "\n"); after doing the damage? I know you say the light gem shows new damage, so this is indeed strange. Btw just to debug, try to manually set the player health with $player1.setHealth(value) and see if it prints the new value. If it still prints the wrong thing then there's something wrong, with how you are calling the code or some bug on how the explosion damage handles the player. Also I would use sys.println instead, it does the same but includes the newline automatically less typing imo.
  23. No problem btw there's no vertex blend texture, the vertex colors are baked in the mesh itself, meaning they should be exported in the .ase file itself. And yes the first "path" in a material is just a material name, it can be any unique identifier, the real textures are defined inside the material itself. materialname { //global space { // diffuse material stage blend diffusemap map path/to/the/real/texture.tga } } or materialname { //global space diffusemap path/to/the/real/texture.tga }
  24. If you already know this ignore it but if you don't, then know that if's in materials stages turn on and off those stages, so you need to make sure you are setting parm11 to a valid value above zero in a script somewhere. But if removing those, didn't solved the problem, then the problem could be the vertex colors itself, are you sure the model has the correct vertex color info on it? Afaik the engine only supports grayscale vertex colors in the RGB format no alpha. Also instead of blend diffusemap keyword try the blend add (gl_src_one gl_dst_one) not sure if this matters but the basic example for vertex colors in this link uses it. I haven't used vertex blending for a very long time so all of this is rusty on my mind unfortunately. Also not sure what you mean with ""lawn_vertex_blend" is the vertex-blended DDS image file exported from Blender and is also referenced in the .ase file." but a material name like yours "textures/darkmod/map_specific/lawn_vertex_blend" shouldn't be a link to a real texture, in reality that is just a virtual path to a fake folder that DarkRadient uses to display in the media section of the editor. You can have a material with just a single word on its name and it will show in the media tab, just not inside a folder but in the global space. it is like this: virtual path/material name { material code } or material name { material code }
  25. Indeed func_movers don't do anything unless you script them but they have a good amount of script functions to make it easy to use and is also imo what makes them powerful and versatile, but if a func_door does the job you want, by all means use it.
×
×
  • Create New...