Jump to content
The Dark Mod Forums

HMart

Member
  • Posts

    1530
  • Joined

  • Last visited

  • Days Won

    9

Posts posted by HMart

  1. Could it be anything to do with the shape of the geometry? Is a curved staircase looking at the images. 

    Or the thickness? Thou by that image those stairs are anything but thin.  Is just that I have seen thin walls leak light, while ticker ones do not and I have seen this, in more than one engine even in lightmapped ones.

    Also is that brush geometry or a imported triangle mesh? You will correct me if wrong but afaik the engine treats triangle mesh's, a tad differently from brush geometry, like it doesn't automatically inline the triangle mesh geometry, into the overall baked brush geometry (unless your force it), so it leaves a invisible "gap" there where the mesh connects with the brush wall? 

    Could be floating point accuracy problems, like you recently talked about?

  2. 3 hours ago, nbohr1more said:

    BFG has no Dmap source code... checking RBDoom3BFG.

    RBDoom3BFG uses the same as vanilla

    Ah yes all of that makes sense, I just forgot that BFG didn't came with dmap and people add to transfer the original tools to the new engine.

  3. Perhaps id didn't cared for that loss on accuracy, at lest for Doom 3, is hard for me to believe they did that for lack of knowledge or something but who knows.  Is this code still in BFG?

  4. 7 hours ago, OrbWeaver said:

    I'm surprised to hear anyone is using Hungarian notation these days. It's one of the most derided, disliked, obsolete and useless naming conventions in programming. I don't think I've ever seen a modern programming guide or tutorial which advocates it (except perhaps in very limited situations like using "mSomething" to indicate a member variable).

    First I need to say sorry for keeping this of topic subject going, I promise this is the last comment from me on this. 

    Now I also got surprised but Frictional Games still does, at lest in HPL1 and HPL2 engines they do, I assume they still do it on their latest engine as well, only them know why.

  5. Orbweaver said all what I thought, I also hardly always follow programing "rules", mostly because "basic naming conventions in programming" change with times and as the languages evolve and change. So imo no one should get to much hung up on those, specially when some rules aren't even evidence based but some famous coder thought it made the code "cleaner" and people just followed.

    For example Hungarian notation, so many coders use it but to me it can crash and burn. I played around with Penumbra HPL engine for a time and it is riddled with such notation and not once, I felt it helped me understand better the code, for the contrary.

  6. 11 hours ago, peter_spy said:

    I'd say "writeFloat" method that returns void is bigger cringe here.

    Why? Can you explain?

    Personally I see nothing wrong with that, looking at that function is obvious that they made it to not return anything, it just writes a float value to a file, and in C any function that doesn't return anything returns void.

    And those inner write functions may have error handling of some kind, so no need to return a bool for success or failure by the main function.

    The only potencial problem I see with it is they pass the file handle by pointer and there's no guard there for a eventual null pointer being passed to the function and it will crash if that happens but the fact this worked for years tells me they made sure that never happens.

  7. 2 hours ago, Fiver said:

    ...updating other creators' missions, even OMs, was frowned upon or appreciated.

    Doing that without permission from the author/s is frowned upon, saying this because if I'm remembering correctly, caused some stir in this community in the past, including a ban.

    And telling the truth, if I was a mission maker (that I'm not), I personally wouldn't want anyone to mess with my mission without my permission. 

    • Like 3
  8. 16 hours ago, Baal said:

    It actually is possible to override single declarations without touching the core files. I just got it to work with a footstep sound replacement. At least I think so, I am not a hundred percent sure yet.

    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...)  

  9. 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.

  10. 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:

    800px-Projected_texture.jpg&f=1&nofb=1&i

    • Thanks 1
  11.  

    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.

  12. On 1/6/2024 at 1:25 AM, datiswous said:

    Why is there a second bracket at all?

    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".

    • Like 1
  13. 1 hour ago, Dragofer said:

    you want AIs to be able to see through it you need to give it a material that doesn't contain visual clip

    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. 

  14. 40 minutes ago, grodenglaive said:

    😄 also @HMart who suggested moving outside the 2nd bracket, which I would not have thought to try.

    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.

  15. 1 hour ago, grodenglaive said:

    fwiw, I tried cloning the material def for lightbiground1 (materials/lights.mtr) and added ai_see 0, but that gives an unknown token error.

    lights/biground1
    {    
        description "Round point light."
        {
            forceHighQuality
            map    lights/biground1.tga
            colored
            zeroClamp
            ai_see 0
        }
    }

     

    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. 

    • Like 2
  16. 2 hours ago, peter_spy said:

    This asset pack is no longer available. If you have access to it, please don't use it or redistribute it further

    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. 

    • Thanks 1
  17. 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.

    Spoiler

    Btw personally I have done a basic gui in Godot, a bare bones developer main menu, with just a colored background and a few buttons with text and let me tell you, it was not all roses, to me making such basic gui in idTech 4, felt way easier than in Godot!  Just scaling and placing gui nodes, toke me a ton of trail and error, was very frustrating (specially as I didn't follow any tutorial) and was also used to idTech 4 way of making gui's.

    Not sure if this is how all gui making in Godot is like, but the gui node I used (grid container) uses a very restrict, parent child system that makes it so, you can't move, rotate and scale child nodes at will, everything needs to be done through the main parent node, I add to use a bunch of hidden extra child nodes, just to place the visible nodes exactly where I wanted them.

    Now to be fair this is also because the gui system of Godot, is way more powerful and complex, all to support totally arbitrary shaped screens, like cellphone screens for example, while idTech 4 gui system, was made for a single screen shape, horizontal 4:3 screen. 

     

    • Like 1
  18. On 12/5/2023 at 6:53 PM, Geep said:

    It is unclear to me if HMart's implementation is synchronous or asynchronous.

    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.

    • Like 1
  19. On 12/12/2023 at 2:40 PM, grodenglaive said:

    Scripting help🤔 How do I query whether an objective has been completed? 

    The wiki shows:

     

    but this is just gibberish to me. How do I actually write it as a script? I want to use it in an if statement, for example:
    if (Obj1 = 0 && Obj2 = 0){
    	sys.trigger( $thing1 );
    }
    	else {sys.trigger( $thing2 );}
     

    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. :)

    • Thanks 1
  20. 23 hours ago, AluminumHaste said:

    So all brush data fits into 1 entity.

    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.

  21. 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";
    			}
    		}
    	}
    }

     

×
×
  • Create New...