HMart

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.

Sorry if this was already explained but this was something I also doubted for a time but then I realized the answer was there all the time, I just didn't noticed, is on the name of this args, they are called entity spawnargs by the engine for a reason and this reason is, they are updated at entity spawn time only. What made me so confused for a time was that script has functions to read and write into spawnarg's, so I thought, if I can write into them, then they should update immediately and when I read the spawnarg again the value is updated but like you found that is not what happens. So imo If you want to keep some special state volatile/updatable, during a entire gameplay section, use a global variable in your script instead. And if you need to save this state, to pass it on to a next level for example, then save the value on a entity spawnarg, you then read it at next entity spawn and it will work. just my two cents.

Afaik yes .cm files (means collision model) can be used as a separate collison model, for a ingame entity, I think that there's even a special func entity for that but the fact is, it was hardly used by idsoftware for that purpose, majority of Doom 3 models have the collision surface incorporated in the model itself (like the shadow model) they did it on Maya, 3DS Max and Modo. So motorsep I ask, why would you want to make a separate collision model in DR? Can't you edit the model in Blender for example?

Ok that does sounds very interesting and now that you talk about it, I think C4 engine add that ability but I could be mistaken.

peter_spy is right that is total overkill, for grass at lest and imo the wrong approach (specially with such high rez textures), thou I know is the "easy" and only approach for those that can't use shaders. The right approach but harder to those that don't know shader coding, is to create a vertex shader that moves each vertices of the grass plane. Btw this is possible to do, more or less realistically, even in the original idtech4, without making a new shader or using frame animations. textures/nature/grass { nonsolid noimpact noShadows noSelfShadow qer_editorimage textures/nature/plant_ed.jpg { blend diffusemap map textures/nature/plant_d.tga rotate .003*sintable[ time *.2 ] } { blend bumpmap map textures/nature/plant_local.tga rotate .003*sintable[ time *.2 ] } }

To me that sounds more game engine specific and not something for a separate level editor like DR. What use would be to DR to have the ability to stream in, map files into other map files? IMO sounds good for real time gameplay in a game, not while working on a map in a editor. Thou I recall the entire prefab system of the dead indie engine, C4 engine, was based on this concept, a map file was a collection of other map files but afaik they were not streamed in.

This game started has a Doom 3 mod and even thou I'm not on the team, I bet idTech 4 was chosen at the time, because it's real time per-pixel lighting and shadows, strongly resembled the look of Thief 3 and also the engine itself was very mod friendly, afaik more so than the heavily modified Unreal 2 engine used in Thief 3. IMO this game will be active for years to come, at lest while there's people willing to work on it and making new missions, players will come. And also the current TDM engine, is not the original Doom 3 engine, it got updated by the team through the years and as surpassed the original in many ways and will keep on evolving, while there's good c++ coders in the team, like currently they have.

Like a console warning? If yes, first personally, I don't see any use in it, because IMO console messages, are meant for developers not players but if you or anyone really want to do that, then use the script printLine function for a fake console message. But remember, they will only be visible, in the console, hidden to players that would need to toggle it to see it, unless you force con_noPrint to zero, this will show all console messages, no matter if the console is visible or not, that I don't recommend at all for something meant to players.

Merry Christmas to all.

Instancing may not be necessary for TDM dark and relative small spaces, but afaik, before UE5 nanite tech, was the only way using conventional polygon rasterization, to be able to render large open scenes. Scenes filled with large amounts of vegetation and other stuff, ala Crysis and others, those games are filled with cloned/instanced geometry all over the place and personally, I don't remember people strongly complaining about them felling very repetitive. That's because there's ways to break the repetition and make the scene feel more unique/varied, even if they are just rendering hundreds or millions of the same geometry/model. Just look at this IMO fantastic in-game forests scenes, in the medieval simulator game, Kingdom Come Deliverance. These are made in Cryengine 3.x, using instanced geometry and Imposters.

Func_statics are the wrong entity for that, those are optimized and used for static objects, meaning objects that don't move at all. What you want is to use a func_mover, these don't move unless you script them to move but they are specially handled by the engine and have dedicated script code that func_statics don't have, for example func_movers have special rotating functions called RotateDownTo, RotateUpTo, RotateOnce, etc and special moving functions as well, those should be defined in TDM_events.script. Btw don't confuse with func_movable that is for rigid body physics objects only.

I agree and I remember saying something similar before and the answer if I recall correctly was, stencil stays in, that was a few years ago, and they add (and still have) very valid reasons, one was because maps in TDM, was still in its infancy and not well optimized, but it has improved much since (stencil also with the soft shadow option). Thou I know this is not a easy decision for the team, you can't just delete the stencil shadow code and everything will be fine, TDM age and success, is also a big problem for the way it handles shadows, because of how old and popular it is, it has hundreds of assets and missions made, with stencil shadows alone in mind, changing those assets today (materials mostly), in particular those with alpha enabled, will require free work, from someone, and will also with no doubt, break shadows in all missions made until now and not forget, decrease performance, by the simple fact that, more stuff that didn't cast shadows, trees, grass, banners, decals, etc, now will and some of them shouldn't, so the missions will have to be updated, and it may never happen if the mission maker is gone. Is not a easy problem to solve.

Looking at the func_pendulum c++ class, shows that it doesn't care or use angles var for anything. So the only thing I can think right now, to solve this, is to bind the visible entity, to a invisible pendulum mover, moving in the direction you want the visible one to follow, its own axis doesn't matter (visually but do matter to the pendulum movement), you can even make it a brush box. Hope you get what I mean. Also here is a old Doom 3 pendulum tutorial that I found, I didn't bother to search in TDM wiki, so perhaps there's one there as well, but just in case see if this helps. https://web.archive.org/web/20100522163241/http://www.doom3world.org/phpbb2/viewtopic.php?p=84076#84076

To add to frost_salamander reply about performance, game objects/entities, created by native c++ code and used in editor, through the entity definitions func_* whatever, imo should be faster than a custom pure script based object, for the simple reason that like I mentioned, they are made/call directly from a c++ based class, and c++ is objectively faster than DoomScript.

Sorry for the extremely late reply to this. First not that any of this matters, as I don't think LOD's will ever be done in this way, but for academic reasons, you don't need to save LOD distances in the model, just hardcode in the engine c++, reasonable default distances for each layer and give the ability to change them later if necessary, like always editor entity spawnargs, but if the defaults are well thought out, you the mission maker, probably wouldn't even need to mess with the distances most of the time, everything would be automatic for the mission maker, like the shadow and collision model. And please to everyone reading, even thou this may sound cool, don't think any of this is easy to code, because is not. Many times making life easy to the end user, requires a ton of work and knowhow from the coder. But the answer to the question is yes, how to do it, does depend on the format you are exporting.