HMart

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.

That's cool, I remember when i was a kid installing modded GPU drivers on my ATI GPU, the same with my Audigy Creative sound card that enabled stuff that they only add available in more expensive models. But personally today, I'm not sure if i would do that, call me paranoid but with all the cripto and nft bs going around, I want such software to come from a reputable source, at lest one that has much to lose if caught doing bs. But that is just me.

Sorry if I felt a tad sensitive also, today was not a good day on the job, a tad stressed. But you are not to blame.

Don't know if it was your intention but this reply makes it sound like I'm lying or something! Or I'm just reading it wrong? If I am, sorry for my reaction, but is hard to detect intention in text. If I'm not, then I'm not asking for you or anyone to believe me and I even said that. Why they copy pasted the entire C++ code instead of reusing? Only the original programmer knows that, but perhaps they were to be different in some special case that never came to happen? Just assuming here. And yes they totally could just have parsed the same keywords in the same c++ code, and in the Quake4 editor (made by Raven software) that comes with Doom 3, they do that. else if ( !token.Icmp ( "definefloat" ) || !token.Icmp ( "float" ) ) { idToken token2; idStr result; if ( !src.ReadToken ( &token2 ) ) { src.Error ( "expected define name" ); return false; } idWinFloat var; idUserInterfaceLocal ui; idWindow tempwin ( &ui ); idStr out; src.SetMarker ( ); tempwin.ParseExpression ( &src, &var ); src.GetStringFromMarker ( out, true ); wrapper->GetVariableDict().Set ( token + "\t\"" + token2 + "\"", out ); continue; } I Just know for certain is that Quake4 removed definefloat (at lest is not discussed in their wiki) and QuakeWars removed definefloat and definevec4 entirely, for float and vec4 respectively. And what about what I asked about supporting vec4 keyword in TDM guis?

I don't have a link and don't take my word for it but I remember this being discussed in the old Doom3World forum and I clearly remember a idSoftware dev saying that definefloat keyword came early, while the script and gui language was being developed, later they decided to support the keyword float alone but because many in world GUI's, were already made with the older keyword, to not waste time converting things that already worked they decided to let it stay, despite doing the exact same thing. Why they made "float" to replace "definefloat" but not "vec4" to replace "definevec4", is something that I always wondered why. What would be your opinion and doing that yourself? Meaning instead of "definevec4" users can write just "vec4" in new GUI's, just like in QuakeWars, thou this last one also supports, vec2 and vec3 but not sure if those are something useful in TDM case.

Yes it could but wouldn't using the skin system be better for that? I know that using the colored system, permits to do variable colors very easily, good for carpets, flags, cloth, etc and also only have a single material, but if your idea is to make more varied looking characters, with a single model, I think the skin system is better, it means more materials need to be created but it also means more flexibility and power. The skin system is very powerful, was designed exactly to make different material variations for a single model and it does way more than just swap colors, you can have characters that look somewhat different geometrically, by hiding or showing hidden peace's on a model, etc. On a animal for example you can have a model with fur and another without it by just hiding the fur geometry, or one with a collar on his neck and another without it, without swapping models, just the skin.

The fact that you can't play Doom3 BFG explains why you can't play modern TDM, afaik both use more or less the same OGL system, thou TDM has since surpassed even BFG graphics. Also if I'm not mistaken Thief 3 is not even a OGL game but a DirectX 8 game, it uses Unreal 2 engine, Doom 3 is a OGL 1.4/2.0 game that came out in 2004 and you already have to play it at lowest graphics settings!? Man that means your GPU is just to slow, I assume is a laptop?

The fact you really can't update drivers and not even OGL 3.2 seams to be fully supported, the only solution for now that I can think of, is to play a older version of the game, one that still has support for the original Doom 3 render based on OGL 2.0, but I don't remember which one, others may help better. Playing a older TDM, does means you will be unable to play the more modern missions, but even so, your GPU is very old anyway and would very probably suffer with the more heavy modern missions and there's still plenty of older ones that are very nice to play.

Unfortunately his are the latest available drivers. But yes based on this link the Radeon HD 3000 should be OGL 3.3 compatible, is TDM using some non core extensions?

I saw totally unrated movies as kid, in national TV, even porn movies and didn't turned into a sexual deviant or a murderer, with such restricted age rating and censorship that we have today, we still have as many sexual deviants and murder cases today, perhaps even more (thou I think that is because they get reported more now) then we add when I was a kid. Just my opinion.

Write what stgatilov says, I didn't looked at the code like he did, only transmitting what idSoftware has said themselves in their old wiki but even their employees, could have been wrong when writing that or it did worked like that but then they updated the gui handling code and forgot to updated the wiki. Only way to be sure, is to look at the c++ code and or test a GUI.

Something like this. not sure if well done but works for me and was really easy, don't know why idSoftware never implemented it originally, seems very obvious and useful, only Quake 4 has similar ability. edit: Took a fast look at the wiki being done and saw this there... That is wrong and not what I recommended at all, if I passed the wrong idea then my bad, was not my intention. What I really said, is exactly the contrary, what i said is that I add problems using, in this case colors, defined with preprocessor macro #define in transitions, only when using definevec4 for that coupled with the $ sign did they work. But the better and widely used method by idSoftware was to input color values directly! Also #define macros aren't really "float parameters", like definevec4 or definefloat, they are exactly like C macro preprocessors like stgatilov said, just text substitution.