HMart

This most be a TDM only thing, because I tried it right now and I can use volume keyword, in a sound shader, in Dewm 3 engine, to both increase and decrease sound volume. Or unless is particular to the player footsteps, I didn't tested those, will see and update this comment. Worked with the player footsteps sounds as well but I remember messing around with the c++ code to make those work. I used Blendo Games starter pack and the player system that comes with it, has the footstep system disabled, this because the starter pack has no real player model, just a floating camera. Ps- btw I add to call reloadDecls in the console NOT reloadSounds for the volume keyword to work.

demagogue to me its doesn't matter that its "somewhat right" what it wrote there, is mostly BS, is not true. Not such game mode on this game... nor this game community is called "Dark Mod", that is the name of the game. I bet the AI said that, because many indeed refere to this community online has "The Dark Mod" community but the AI totally failed to get the real meaning/context of those words. Again there's no such game mode, nor players make levels using ingame tools and resources. That is obviously marketing from some online MMORPG game or such. Again to me it doesn't matter that the intention is almost there, you and me know that because we know the game and its community, but if we were new players, the truth is, that description would give us a totally wrong idea about this game. Because players don't assume the role of builders, builders are a ingame enemy faction, players don't build anything, they play the missions and the roles of thief's or assassins', mission makers (no matter if they are themselves players) are the ones that build missions, the only thing right in that quote is " trying to avoid detection by patrolling guards". What that original quote show to me, is that the AI can write coherent frases but still be totally wrong, is just a clever mashup of cool marketing words, from other games i bet, being reused in a new context, mixed with a few correct bits/words from Dark Mod.

Soma uses Newton Dynamics (Newton 2.x or 3.x? )I know that physics engine, is very accurate, is also why it is slower than Havok and PhysX for games, unlike the others it takes very few shortcuts in its physics calculations (there the name), that made it's joints and friction handling very stable and perfect for the type of player world interaction that Frictional Games wanted for Penumbra, the fact the physics engine was so stable and rather unknown, is IMO one of the main reasons their first game was so unique and successful. Btw Newton Dynamics started as a physics engine for robotics and stuff in academia, so it needed to be accurate, the main developer of the engine, is now making a modern version more focused at games, Newton 4.x and it is way faster than the former versions, but I assume that with that speed comes less calculation stability but I don't really know.

John Carmack the main idTech 4 developer once said, "best way to mesure performance is not FPS numbers but frame timing" and I agree, we tend to mesure game performance by counting higher and higher fps's but you can have a very responsive and playable game at 30fps, if the frame timing is constant and a very lagging game if not, even if the fps numbers are 60 or higher. And today in the age of Nvidia DLSS 3 AI frame generation, FPS numbers, are imo becoming irrelevant, hardware unboxed found that with DLSS 3 you can have a game, for example show 120fps but feel almost exactly like a 60fps game (because is the speed the game is really running at, DLSS 3 is just inserting fake frames between each real one and artificially upping the frame rate).

Perhaps you have a infinite loop in one of your scrips? Infinite loops can cause freezes. But I also thought the script parser was able to caught those? Btw I don't remember ever having, Doom 3 in this case, freeze because of changing a def file (or even a script?), the worse it could happen is crash the game or cause ingame bugs but I'm not absolutely sure on this.

I don't think we need a extra PPU card not today, I'm just saying that Ageia failed, not because their competitors could do the exact same or better, without a accelerator but because they just couldn't show, or didn't knew how, the true promise of the PPU to the public, in visual terms, not in a way that non tech savy people could see it. And when some of its effects, could be made "good enough" with less physics complexity, and or faked like for example Valve did in HL2 with the baked "cinematic" physics, it add no chance. hahah Indeed Not trying to start a debate over this stuff but CPU's even modern ones, IMO aren't still capable of what even the old PPU could do, at lest I haven't seen a game with CPU only physics doing that, you are free to show me wrong thou. Agree Is like saying software rendering, everything done on the CPU is said as being done in "software" but at the end of the day, is a peace of hardware doing the calculations. We agree we disagree on this? Plus Havok is as dead as Ageia PPU today, Nvidia PhysX pretty much dominates the physics engine market. I certainly can't argue with that, totally agree. Btw Bullet physics engine made by a old Physx engineer (if I'm not mistaken) did support OpenCL acceleration on AMD and the company did showcased it but like almost AMD stuff, it didn't add any use, in gaming at lest. Btw guys sorry for the huge replies but is hard to say everything I wanted to say about this subject in a few words.

Havok never did such a thing, I know because I was a owner of a Ageia card and Havok demos or games, were never able to reach the same level of physics Ageia PhysX demos displayed. I know Ageia is now a joke and people have forgotten most of it but I experienced it first hand and let me tell you, to this day, there's not a single, Havok or Nvidia PhysX, game or demo, that to me, does what some of the old Ageia demos did, at lest not all of it, again I saw it with my own eyes and played them on my PC. Warning massive wall of text: edit: Revelator I see that you were also a owner of a Ageia PPU, that makes your comment even more strange to me, what Havok demo/game did you played that made you get that impression?

IMO there's some benefits to using "" around paths, one it permits you to put spaces in your paths (thou I don't recommend that at all), second it breaks your paths into easier strings, for the text parser to read/deal with, it also help us visually distinguish what's is what better. They aren't a rule you can ignore them but imo using them maybe decreases the probably of parsing errors. About lower case, I'm not sure but unless you are comparing strings, I don't think the parser itself cares about the case of character in a string. Thou because of portability to linux and other OS's idSoftware recommended, no spaces in folder names and no higher case letters in a path, the engine even has a warning message just for that. But like you see above, even I forget that sometimes, is why I have plenty of warnings about non portable paths in the console!

Instead of that try this to see if it works, it does on my end skins/bathroom/Tube01a_waterclean { model "models/mapobjects/washroom/bathtub_oldA.lwo" "textures/common/nodraw" "textures/water_source/Water_clear" } change the stuff for your own model/materials of course

Those pics look very good. About glass behind glass, that is a problem in all game engines, using rasterization, no matter how modern they are, is a limitation of rasterization itself, is not impossible thou, there's a trick to make it work called "Order-independent transparency" but afaik is complex and demanding and apart from a very old AMD (or was it Nvidia?) demo, I never saw any game use that trick, specially not now that real time raytracing is a thing. Thou on the link I posted it says the ancient Dreamcast console add special hardware for OIT.

Hum I think I see the problem. Btw If you haven't, I recommend that you read the gui documentation in TDM wiki, may give you better advice than me. I think the problem is that grayman "gui::startSelect" is handled by the engine c++ code, thought another gui file (if any), this is because gui:: vars aren't global to all guis, they are "baked" in the gui they are defined, meaning you can't just reuse them in any other gui file as is.

That's exactly what the code you posted does, it selects only a single spawn entity, a custom one if you give it or the default one. Looking at the code you posted, grayman changed the code in a way to permit anyone to override the default spawn entity, for a custom one, by setting a gui var called "gui::startSelect" to the name of the entity you want to use as spawnpoint, but is still a single one and that's logical, because there's no way to spawn the player in more than one spot at the same time! Unless the player was a quantum particle! joking

Oh! I didn't knew that! Thanks for the correction. Is what happens when I take knowhow from the original Doom 3 engine (and Dewm 3 engine) as a starting point. :S

The engine has multi spawn positions but only for multiplayer, the single player code does not handle that but I see a way to go around this, what about using the player teleportation feature? Something like this, In DR put special "go to" entities, just used as locations to transport too, then in the main menu GUI set which entity the player should jump too and then transport the player to it when he spawns, you can do a fade transition to hide the jump, for the player will be like he spawned there in the first place.

What function are you using to render the subtitle text? Is it idRenderSystemLocal::DrawSmallStringExt() ? The comment above it says it does drop shadow but I didn't analyzed the code at all to know if true. That 480p virtual background rendering, does sounds like a problem, too text at lest, specially when you guys are still using the text textures at max 48 size, like Doom 3. The engine is essentially using the same "basic" text system from quake 2 or even quake, texture atlas, and it makes for blurry text when scaled, specially from 480p. Btw no pressure here just a suggestion, if you haven't looked at the OverDose source code imo you should, they claim is a very advanced quake 2 engine but internally, looking at it, is almost identical to idTech 4 but with a more advanced modern GL render just like TDM engine . I'm talking about that engine, particularly because they upped the text atlas scale to max 96 and you could look how they did it, that should help a little with the blurry text. And IMO, not affect performance that much, specially today when thanks to your fantastic job TDM engine is so fast. Also they even have a nice tool to create fonts for their engine (and other tools and documentation, some of it imo still relevant for Doom 3 editing and perhaps even TDM). And lastly I know is probably not possible and would be a bunch of work for you and I bet you are already busy with other more pressing things but some day, something similar to this would be awesome, if a open source equivalent exists...

Would be to hard to do drop shadow for the text? Afaik that (and or using other color than white text like you see in thief 3) is how almost everyone solves that bright text over bright backgrounds. P.S Unfortunately the example image I attached, looks worse than I thought, but in the real thing the text with drop shadow is very visible. And the drop shadow can be made stronger than that.

Sorry my reply was a bit confusing, those macros aren't defined anywhere (thou you can define them yourself...), it was only a idea for the TDM team to implement if they wanted. Sorry for making you waste your time chacing nothing. TDM_MAJOR_VERSION, TDM_MINOR_VERSION and TDM_PATCHLEVEL (and the rest) need to be defined/created by the TDM team, and made part of the standard game defines, you can define them yourself, but that would be useless to anyone else, because only you would have those defines in your copy of the game, so right now afaik there's no way to do what you want, unless the TDM team creates those or something like those macros. I hope this is more understandable.

Hum personally I don't think that exists, at lest for all functions, I could be wrong thou. But TDM, coming from Doom 3 should support https://modwiki.dhewm3.org/HasFunction_(script_event) but this is particular to script objects/entities and not to ask if some generic global script function exists anywhere and I don't really know how that would be implemented. But couldn't script macros be used for that? Something like SDL does. // based verbatin from SDL version define #define TDM_VERSIONNUM(X, Y, Z) \ ((X)*1000 + (Y)*100 + (Z)) #define TDM_COMPILEDVERSION \ TDM_VERSIONNUM(TDM_MAJOR_VERSION, TDM_MINOR_VERSION, TDM_PATCHLEVEL) #define TDM_VERSION_ATLEAST(X, Y, Z) \ (TDM_COMPILEDVERSION >= TDM_VERSIONNUM(X, Y, Z)) #if TDM_VERSION_ATLEAST(2, 11, 0) // run this func only in TDM 2.11 or above func(){ do stuff; } #endif Not totally sure if script language macro support is robust enough for this but it should be.

If you know how to script and make skin files for models then all entities should accept the following script function. Then is just a matter of setting the desired skin, depending on the state you set the light switch. If you don't know how to script, this can still be done, even if not imo the ideal method, done using the special editor entity, target_setModel, if it still exists in TDM, if it does then this can be done directly inside DR , by just using the targeting and triggering functionality. More or less like so: light switch -> triggerOnce ->target_setModel-> new light switch model If I'm not mistaken target_setModel ONLY accepts model names and not skins as input, so this will require you to have two almost identical models, one with light on another with light off. Hope this at lest gives you some pointers.

Yes there should be, not to jump easily to any entity in particular but you can "save" a camera view position and then jump/teleport to it. if TDM engine team didn't changed any of this you could try: cvar "where" or "getviewpos" -> "prints the current view position" so you can know where you are in world coordinates cvar "setviewpos" -> "sets the current view position" ak teleports the player eye/view to that position If this particular cvars don't exist in TDM then look in the TDM wiki for something similar it most exist. btw you can bind keys to cvars, so if you need to jump to a particular position many times, you can do bind key setviewpos x y z yaw -> bind f1 setviewpos -50 30 75 180 and just press f1 to jump to that position when you need Hope this helps.

Totally agree and not only that but if Doom 3 was made on Unity, TDM would never exist, because any game made on Unity is just almost impossible to be modded, unless you do heavy reverse engineering of the files (most don't know how) or the developers make their own mod tools, that I assume less than 1% of Unity game developers bother to do or even know how to develop their own tools. Xolvix that is my supposition as well, but is a petty variety in the game engine world, is slowly dying, not only because that is starving the engine making talent pool, but also because that has a real impact on the look and feel of games, unless the developers go out of their way to remove the engine default look, all games made on Unity or Unreal look and feel the same.

nbohr1more already said most of it but if I can add anything, is that the AI traversal system called AAS (Area Awareness system) also requires brush's to work.

Nothing against implementing such a choice for auto loot, I'm always for player choice. But I most say that I disagree that rotating the bodies to loot them, is not fun or immersive, to me is totally the contrary, plus is a tad more realistic than just "frob body press button" and stuff happens. IMO It also adds to the gameplay, is like a mini-game.

What?! That is news to me, I use .lwo for all my static models and smoothing imports to idtech4 just fine! Thou I most say, I don't use Blender for anything but MD5 models and still use old Modo 601, the same tool Seneca Menard a idSoftware artist uses, and also use his custom Modo plugging's, that he made public, exactly to streamline making static models for Doom 3 and Rage. In modo you can set smoothing angle or edge smoothing (hard or soft edge) and it works in idTech 4, perhaps blender and other tools handle .lwo differently? After all modo was made by the same people that created lightwave 3D, so they literally created the .lwo file system.

Solid 1, if no collision surface is available, will use the model geometry itself for collisions (search for combat model in the code also), so yes is not the best approach, doing a custom collision model is always preferable for performance, but doing it on DR is something I personally don't do and IMO is at most, best for simple box like collision models. Like I said the best is to create the collision surfaces in a 3D Tool like blender, you can use the shadow model for it, just change the material from "shadow" to "collision" or even the lower poly LOD model, can't be easier. Btw isn't AFEntity for ragdool physics? I thought that was only for skinned MD5 models not static ASE or LWO models.