Jump to content
The Dark Mod Forums

HMart

Member
  • Posts

    1541
  • Joined

  • Last visited

  • Days Won

    9

Posts posted by HMart

  1. 3 hours ago, stgatilov said:


    Speaking of putting double-quotes vs not putting them: I think it is a good idea to enclose every item in double-quotes.
    Literal numeric values are perhaps the only exception.

    I remember some idSoftware dev on Doom3World forum saying exactly that, they also said that in 

    float "somevar" "0"  the "0" is ignored 

    Quote

    Additional user variables may be defined with the 'definevec4', 'definefloat', and 'float' commands. Note you cannot set the initial value for the variable (it will always be 0). There are guis in Doom 3 that specify an initial value, but it is ignored

    From iddevnet, but you can look at the c++ and see if is true or not just to make sure.

     

    3 hours ago, stgatilov said:

    The section User Variable says this is OK syntax:

    float crouch_scale=0;

    I'm sure this is not correct, and hope that recent dev builds produces a warning on it.

    That is indeed not correct, unless is for Doom script...

    idSoftware says for Gui script user var definitions you should do:

    float myfloat

    or 

    float "myvar" "0"    // see above about zero or other value being defined here at user var definition

     

    3 hours ago, stgatilov said:


    String comparison section says that there is some special "quoted comparison operator":

    if ("LSGSaveGameNameEntry::text" "!=" "") {

    I don't recall seeing anything specific regarding double-quotes around operators.

    Hum you maybe right but Doom 3 main menu does uses that "!=" 😕

    if ( "SGC1Title::text" "!=" "" ) {
    		set "forecolor" "0.6 1 1 1" ;
    		set "SGCBtn1EdgeG::matcolor" "0.5 0.7 0.8 0.5" ;
    		set "SGCBtn1BorderG::matcolor" "0.5 0.7 0.8 0.5" ;
    		set "SGCBtn1CornerG::matcolor" "0.5 0.7 0.8 0.5" ;
    		set "noevents" "0"
    }

     

    3 hours ago, stgatilov said:

    There is Multiple If section, which totally lacks the most important caveat of GUI ifs that usually kills all attempts of writing any complicated logic in GUI scripts!

    While you can write expressions inside If conditions (and now also on the right side of Set command), they are evaluated not when you normally expect it to!
    All the expressions are evaluated before script commands are executed. So if you Set the value of "gui::myvar" from 0 to 1, the following "if (gui::myvar)" will still be considered false.
    I believe all the expressions are evaluated at the same time, regardless of whether they are on the right side of property definition (aka 'visible "gui::LootIconVisible"') or inside script.

    This is very important to understand when you write expressions, since normal people assume that script commands are evaluated sequentally, and their changes are propagated immediately.

    And yes, you can write nested ifs, but with the caveat of early evaluation they probably won't give you much.

    This is awesome info and explains why some of my ifs didn't seem to do what i expected.

    but is that

    Quote

    "gui::myvar" from 0 to 1, the following "if (gui::myvar)" will still be considered false

    still true, if you change it through c++, using "_gui->SetStateInt("gui_var", value);" or is only when doing it from Doom Script?

  2. I have not read your wiki about the gui scripting, so sorry if this was already known by you and talked about, but if not, imo is always good to know that gui scripting language, can do a little more than what idSoftware used and talked about. Unless i failed to see where idSoftware talked about this stuff.

    I discovered this by accident, when I tried a few stuff that Doom Script supports, to see if they worked with gui scripting and they did.

    For example the gui language, other than #include also supports #define, just like Doom Script, thou in a more limited way, so you can do basic text substitution using #define like:

    #define COLOR_WHITE 1,1,1,1

    #define WIND_HEIGHT 480

    #define WIND_WIDTH  640

    or more complex

    #define RECT_SIZE   ((WIND_HEIGHT/2)-(320/2)),((WIND_WIDTH/2)-(240/2)),320,240

    then used as:

    rect RECT_SIZE 

    -----------

    It also has basic support for pointers! using $ sign, example:

    transition "start_white::matcolor" "$Desktop::COLOR_WHITE" "$Desktop::COLOR_BLUE_07" "1000"; 

    and other capabilities that I may be forgetting, have not messed with gui scripting for ages now.

     

    Thou i remember macro and pointers support was not free of problems, there's some idiocentricities with this stuff, for example macros using #define and defined in the global space, meaning outside the main desktop windowdef or any other windowdef, work globally and are accessible directly by name (just like in Doom script), but seem to work, only in some things, like "rect", "backcolor" and others but not in transitions, I remember having trouble with those, the only thing that worked well for this ones, was defining the "macro" in another way, like this and inside the main desktop windowdef:

    definevec4 "COLOR_WHITE"  1,1,1,1

    Despite  #define COLOR_WHITE 1,1,1,1  and  definevec4 "COLOR_WHITE"  1,1,1,1 looking similar and apparently do the same thing, behind the scenes they seem to be handled totally differently.

    I don't claim to have tested this macro stuff very deeply but imo has potencial to make gui scripting life easier, but caution in the few tests I made, transitions using macros, were the most unstable GUI feature, they work the best inputting values directly, specially because those are separated by spaces not commas. Thou using pointers like I show above, even using colors defined using commas worked, sometimes...

    I think this, spaces versus commas, most be why macros and pointers were mostly ignored by idSoftware, most of their GUI's only use a "safe" subset of the GUI script language and I unless I missed it, I never saw #define being used in any of their gui's.

    But they do work in the basic tests I made, Gui scripters just need to be aware of the limitations.

    • Like 1
  3. 4 hours ago, datiswous said:

    I must say, I expected a much smaller map. The frob-animated boxes are cool.

    That brought some memories :) is a very old test map/thing that I used to learn DR and TDM modding, I spend a few weeks messing with it only. I add almost no idea what I was doing the scale is all wrong for example. Thou If I remember correctly, this test map has at lest 2 or 3 custom models that i made that I don't recall ever being used on any real mission, would be a petty if no one took a look at them to see if they are of any use. 

    Btw those frob-animated boxes, were my first foray into coding and Doom Scripting, also trying to code any ingame interaction with the language, to see if i could do it, so the script code logic most be a absolute mess and perhaps hardly useful but happy you find it cool. :) 

    • Like 1
  4. Personally I don't like depth of field, in real gameplay at lest, for screenshots and cinematics is fine but if you want to try including it yourself, sikkmod for Doom 3 has a ARB shader for it, so if you learn basic Doom 3 ARB and TDM GLSL shader code, you could translate it to TDM, both engines follow the same basic principles.

     

    • Like 2
  5. 11 hours ago, SeriousToni said:

    Im always confused which one is better. Stencil or mapped shadows. I can't even tell which I chose right now in the game. Could this be renamed for 2.11 to just shadow quality high and low maybe? :D

    IMO that is not a good idea, stencil shadows and shadow maps, are two totally different things, technically and visually, putting them both under a single shadow quality option, IMO is not correct and may lead to way more confusion by mission makers.

    Spoiler

    Stencil shadows and shadow maps, have visual diferences and IMO you cannot say one, is higher quality than the other, depends on preference and implementation.

    Stencil shadows look very sharp (if you disable soft shadows), no matter the quality level, maps can look very pixelated if you use lower shadow map sizes.

    Stencil shadows is extruded geometry (triangle mesh's).

    Shadow maps is textures simulating shadows (there its perfect support for alpha mapped materials). 

    The only reason some may think, stencil and maps are the same, is because afaik, in TDM the team is forced to limit shadow maps to what stencil shadows can do. What I mean by this is, for example, transparent textures, grass, tree branches and other stuff using alpha maps, shadow maps support those perfectly, stencil shadows don't, so because TDM started historically with stencil shadows alone, afaik no "perforated" materials (alpha mapped materials) in TDM cast shadows.

    This is a historical limitation and one that TDM may never be able to change, because has the potencial to break shadows on many older missions, also saves performance...

     

    • Thanks 1
  6. 6 hours ago, Something Hank said:

    That's done it, thank you. Took me a second to even figure out where to start when you said "spawnarg". So is spawnarg a universal term for the properties you slap (or come default) onto entities and such? Been using those plentyish.

    "spawnarg" is just spawn argument, is a variable you write inside a object definition (the .def files) that gets used at spawn time, to do many things, they are both accessible by the script language and c++. Hope this clears some things.

     

  7. On 9/2/2022 at 8:38 AM, Obsttorte said:

    Nice. I was so free to setup everything for it to be used as a LOD model in TDM. Two notes, though:

    1. The lod distance values are set erratic. They probably need tweaking. But this is something mission authors should do anyway.
    2. The models don't seem to have a dedicated shadow mesh. That could make them unneccessarely performance houngry. Someone with model expertise would have to take a look at this.

    https://www.mediafire.com/file/nwdnwtriio5d0co/tdm_statue_sealandbear.pk4/file

     

    In this case for a shadow and physics mesh imo is very easy, just make two extra copies of the lowest LOD, slap the shadow material in one and the collision material on the other and make sure both occupy the same space and are on the same item mesh/layer has the main model.

    In blender (or any other 3D Tool) you don't need to import any TDM material or texture, you just make a basic material for the shadow and collision mesh and make sure to give each the name of the shadow and collision material respectively (not the .mtr file name the full material name, inside the file), is that easy!

        bear_statue_example.7z 

    ps- here is a fast example of what I said, sorry for not making it plug&play to TDM.

    I add too mess with the model because I use Modo and it doesn't open ase files, I add to convert to obj using another tool and also rotate it in Modo to be able to work with it, so now is not a, one to one, to the original model and so shouldn't be used with the LOD's that were provided, this because I assume they will not match, but I didn't tested, plus the material name for the main mesh is not the correct, only for the shadow and collision mesh's are correct (follows doom 3 convention).

    This should be seen just as a model for anyone to know how a shadow and a collision model should be setup. (for those that don't know)

    I also used the second LOD counting from the last because the lowest LOD seems to not follow the main model silhouette perfectly, it could very well work at the distance but not for a shadow and collision mesh.

    • Like 1
  8. On 9/12/2022 at 4:24 PM, greebo said:

    I've tried to look for similar reports like this, but there's nothing that sounds like the problem here. That might also be due to GLCanvas not being used that much (and wxWidgets 3.2.0 itself is not that widespread yet to begin with). At this point I can only speculate, since I haven't access to any AMD hardware at the moment.

    I can offer to look at a crashdump you produce with DR 3.0.0, and see if its trail is also leading to the AMD drivers.

    Sorry if late but if still useful, here is a memory dump of the DR 3.0.0 crash. :) 

    https://drive.google.com/file/d/1Ws7FFyG15NTp-q8GuGnWUMKTUVwkoCpY/view?usp=sharing

  9. 20 hours ago, greebo said:

    It appears that this is something that changed between DR 3.2.0 and DR 3.0.0, at least for you?

    Yes indeed but DR 3.0.0 like I said also crashs but is after, not during initialization and is random, sometimes it crashs, sometimes it works fine.

    Btw If other AMD users aren't getting the same behavior, it may very well be my particular PC configuration, I did some stuff to this computer that may not be desirable, like hot swapping the entire motherboard, the CPU and the GPU for new hardware without reinstalling windows, it works fine (and I've read online that windows is ok with it) in pretty much I do but it could influence DR somehow?  

  10. The physics on that video do look better, I still think they aren't "normal" looking, i mean not similar to Havok, PhysX or more recent physics engines but I can't deny that was way better than the older video. :) 

    Btw I knew that using a faster single core CPU, would make the idtech 4 physics engine able to calculate more objects, what I didn't knew, was that you guys made it able to use multiple cores?! Is that right?

  11. 3 hours ago, stgatilov said:


    I watched this video and it looks great to me.
    What exactly you don't like in how TDM behaves in this scenario?

    I think the current engine has very bad transitivity issues.
    Like you remove a table, but some things on the table don't drop.
    Of when elevator goes up, some things stacked on top of each other don't behave as expected.
    And etc.

    Look how few boxes there's moving on that simple scene and already the performance feels so low. 

    Next to the problems you pointed you can clearly see in the TDM video, how the physics objects move in very obvious discreet steeps, looks has if performance took a nose dive at that instant, but is that really performance going down or just how the idTech 4 physics were made to work? Instead of a continuous smooth movement they move in steeps?

  12. 12 hours ago, AluminumHaste said:

    Would be nice,

    ...

    Indeed it would :) 

    About the video I knew something like that was already possible on TDM, the problem imo is the physics objects, behavior/speed and performance. 

    And guys don't take me wrong, TDM being a Thief homage, I don't think should go crazy on physics, I just think that with a better physics engine, some doors would open to make some cool physics based stuff, in or outside the TDM/Thief lore.

    Would be cool if possible but I know you can't just swap the physics engine there's a bunch of work involved, this is just a "what if" . 

  13.  

    The physics engine is open source (MIT licence) and it seems it was used on a AAA game already see here.

    https://github.com/jrouwe/JoltPhysics

     

    I can only dream that some day this may happen to some idtech4 based engine.

    So much cool physics based gameplay would be possible in that case. 

    A small glimpse at what perhaps some TDM traps could look with a better physics engine, thou I do think some of the traps in the video bellow aren't suited for TDM and or are already possible with current TDM physics. 

    https://www.moddb.com/games/shadwen/videos/video-2

    • Like 1
  14. Spoiler

    Not sure if the best idea but doing the following change on this code bellow, makes crouch work has you want but it needs extensive testing to see if it breaks the game, my testing was very limited.

     

    void ButtonStateTracker::Update()
    {
    	int timeSinceLastCheck = gameLocal.time - _lastCheckTime;
    
    	if (timeSinceLastCheck == 0) return; // no double-checking in the same frame
    
    	//DM_LOG(LC_FROBBING, LT_INFO)LOGSTRING("Updating button states\r");
    	for (ButtonHoldTimeMap::iterator i = _buttons.begin(); i != _buttons.end(); /* in-loop increment */)
    	{
    		int impulse = i->first;
    
    		if (impulse != IMPULSE_CROUCH)
    		{
    			if (common->ButtonState(KEY_FROM_IMPULSE(impulse)))
    			{
    				// Key is still held down, increase the hold time 
    				i->second += timeSinceLastCheck;
    
    				_owner->PerformKeyRepeat(impulse, i->second);
    
    				// Increase the iterator
    				++i;
    			}
    			else
    			{
    				int holdTime = i->second + timeSinceLastCheck;
    
    				// Delete the impulse from the map, and increase the iterator immediately afterwards
    				_buttons.erase(i++);
    
    				// Notify the player class about the keyrelease event
    				_owner->PerformKeyRelease(impulse, holdTime);
    			}
    		}
    		else
    		{
    			int holdTime = i->second + timeSinceLastCheck;
    
    			// Delete the impulse from the map, and increase the iterator immediately afterwards
    			_buttons.erase(i++);
    
    			// Notify the player class about the keyrelease event
    			_owner->PerformKeyRelease(impulse, holdTime);
    		}
    	}
    
    	// Remember the last time the buttons have been checked
    	_lastCheckTime = gameLocal.time;
    }


    For TDM programmers and people that know how to edit and compile the engine.

    • Like 1
  15. I'm not 100% sure (have not tested it) but I have read a long time ago that the material names can be any size, even a single word, like this below 

    ivyloose06
    {
    	qer_editorimage  textures/decals/ivyloose06_ed.jpg
    
    	diffusemap 	textures/decals/ivyloose06_d.tga
    	specularmap   	textures/decals/ivyloose06_s.tga
    	bumpmap       	textures/decals/ivyloose06_local.tga
    }

    the name doesn't need to be a path, paths are relative anyway, (relative to the texture folder) and are only important for the textures inside the material itself. 

    I think the material name written as a path "textures/somefolder/materialname" is used by the editor to create the folder structure in the media browser, that's all, if you don't give the editor (DR) a "path" it just puts the material in the main "textures" ones. 

  16. Not 100% sure about TDM but this is what idSoftware said for Doom 3

    Quote

    The only animation system supported in Doom 3 is skeletal (no vertex animation like in Quake)

    and I never read that the team changed how md5 animations are handled.

    A community member, did revived the unused md3 animation system from quake 3, that was disabled but still on the engine and that is pure vertex animation but making the md3 play the animation, is not that user friendly and no one has ever made md5 and md3 models work together on the same character, for example md5 skeletal animations for the body and md3 vertex animations for the head, would be cool thou if possible.

  17. Hi Frank Cotton, please do what you want, but if you don't mind, I have some suggestions for you to consider, If perchance along modeling, you know how to animate, personally and I mean personally, I would love if someone would make more animations for the werewolf character, specially a better run animation and a cool roar one for when he detects the player.  

    Also again IMO, if instead of rework existing ones (that imo are fine for the time being), a totally new character would be cool, for example, like we have the small spider like guard bot, to me would be cool, to have a relative big, biped steampunk robot, with animations, at lest walk and search animations, why, because based on Doom 3, imo is sad to me that the engine has AI AAS support (ability to navigate in a level) for big monsters but TDM has none to take advantage of that.

    I can imagine some missions where the player goes to some inventor guild place and has to go around a massive robot to reach some high value thing. 

    Something like 

    30662813507_0ee1ba83ed_b.jpg&f=1&nofb=1

     

    where the head is a search spot light that goes around and he makes steam boat sounds when he detects the player. :) 

     

    I know this second one is very probably way harder to make than the one above and TDM already has a automaton character but imo is to much a obvious reskin of the builder guard.  A better automaton would be cool, one that is more or less the representation of a human guard but still very different, something not like but akin to the following, world be cool

    593d5cb8325271cc967e71590eba49f1.jpg&f=1

    Where his eyes are red and cast a spot light

    mood example

    700_015568e50977c50710335387e2861eb2.jpg

     

    Of course all of this new characters without animations, will be almost useless only used has static props, so again if you can't animate, reworking a existent character is obviously better.

    Just my two cents. 

×
×
  • Create New...