HMart

do what joebarnin said the .getBoolKey(string), or .getKey(string), etc, are used to get key value pares, also called spawn arguments or spawn args that you defined in the entity definition file the .def file. Is not a hard rule but those functions/methods should be used at entity spawn/init, why, because is way faster, to save the spawn arg value into a script variable and then use that during real gameplay, than opening from disk, a entire text file to read, loop through it and get data from it, that is obviously slower than just reading a float from memory.

Tables is what's used to drive flickering lights, In my fast search I didn't find a explanation about them in the TDM wiki (doesn't mean there's none) but here are some links that explain, what they are and more or less what they do. This links are obviously not directed at TDM, so have in mind that some things may work differently or not at all now. But personally I still think they are useful for TDM editing at lest as a hint or pointer. https://modwiki.dhewm3.org/Table_(decl) https://iddevnet.dhewm3.org/doom3/materials.html

IMO they aren't necessarily wrong, many modern effects today use voxels in the background, they are not what gets drown in the end but they do enter in the equation.

I think is defined in the character definition file, at lest I see it here in the Doom 3 monster default definition, not sure if the same is true for TDM. entityDef monster_default { ... "editor_var mass" "character's mass." ... }

What format is the model in? ASE or LWO? Never used ASE but If LWO make sure the model or handle material has a smoothing angle of 180% (at lest that is how is done in Modo, the 3D tool I use), if the model has a single material and you don't want the full model to look smooth, then you can create hard edges by cutting and pasting manually (in blender I think is called extracting) the model faces you want flat, hope this makes sense to you.

I don't think so, because idTech 5 source, was never (fully) released but I'm not 100% sure. I never worked with Rage SDK and perhaps the tools source, could be in there somewhere, but imo is very unlikely.

I wish I was so good at math as you guys, so I could help but alas. I can just say they used idStudio (their new editor) to do BFG maps and If you have Rage 1, it comes with idStudio, you can see if the lights still work the same there, even thou is a new editor still works mostly like Doom 3 Radiant so should be familiar. Here someone did some tutorials for it. https://www.moddb.com/mods/ehrlia-summerwheel/tutorials/rage-toolkit-tutorials-and-updates

The steps for non MD5 models are relatively simple: create a model and make sure it is all in a single layer (when exporting) be mindful of the scale diference between the 3d tool and the game, one way to see the scale needed, is to create a cube in DR export has obj and import in blender. make sure the model is made of triangles no quads (you can work in quads then triangulate at export) uvmap the model and make sure the uv's fall within the 0/1 window and don't overlap create a diffuse texture (colors only no shading) create a normal map create a specular map (you can put color on it) create or edit a .mtr material file and define your model material there. make sure the material name, for the model surfaces, in blender, is the name of the material you have created inside the .mtr file if you want to create, a shadow mesh or a collision mesh make sure the surfaces/models lay in the same layer as the main model (they overlap it) apply to each model the invisible "texture/common/collision" or "texture/common/shadow" material names depending on the model function you want (for collision models if making a physics enabled model a 'movable' in idtech 4 parlance, make sure the collision proxy has no more than 16 faces) export as a single .ASE or .LWO hope I didn't forget anything.

IMO this engine problem, is really not so much the polycount but the number of lights that cast unto the model surface triangles, the full model gets draw again, each frame, for each light that cast into it. So if you make the light count, striking models low, use LOD's (level of detail) models, don't go crazy on shadow casting lights as well, do optimized low poly shadow mesh's for your models, don't go crazy on the model material "stages", everything inside a starting { and a ending } in a single material, is a stage and every stage, requires a new render call/pass and of course, use portals to optimize visibility, portals are required for the way TDM maps are constructed. I'm sure i'm forgetting something but If you do all the above plus use normal mapped models and not use crazy polycounts per model, then is perfectly possible to use high quality photogrammetry models in this engine. I have at lest 2 models that I converted from PBR and photogrammetry and they look awesome on the engine. BUT I need to warn you, there's no support for PBR materials/shaders in the Dark Mod engine (at lest that I know), this is a "old school" engine, similar to Unreal Dev Kit (UE3) or Source (minus the lightmaps...). This unless you write your own PBR glsl shaders, but is not easy, requires deep knowhow of the engine backend and frontend render and perhaps even some new c++ code, plus with PBR, you can't use ANY of the current TDM assets, as is, including even the light materials, particle materials, everything based on old non PBR system. Btw personally, I don't recommend working outside of TDM tool set, engine capabilities and way of doing things, or you will have to learn way more about the engine and have way more barriers. You will also have to get the modern PBR ideas from your head and if necessary, relearn the older way to do materials for games. Can't just take a Quixel mixer material or something and throw it directly into TDM but don't take my word for it. Btw peter_spy, another user here, does high quality modeling for TDM so he may give you better advice. But in the mean time, I don't think it does any harm to see this two links of wikis for more info, they are from two different versions of the same engine but share plenty between the two, of course you should focus more on the TDM one: https://modwiki.dhewm3.org/Modelling https://wiki.thedarkmod.com/index.php?title=Modeling And last but not least, IMO would be better if you just created the models and gave them to the community and others more knowledgeable of the engine, used them on their missions, instead of you having to learn modeling and level design/mapping at the same time, for TDM, all the credit for the models, will still be yours, you would still be able to use them has portfolio peace's, plus all models used in TDM, have a non comercial license, so others can't just take your TDM models and create a comercial game with them, just my two cents, you do what you think is best.

Yes is unfortunate how idtech 4 lighting has little to no GI capabilities I wonder how Metro games before the raytracing one does it's GI stuff, all lighting on Metro is fully dynamic and still shows plenty of ambient bounce. Cryengine for example uses a special voxel system for GI and all its lighting is also fully dynamic, no lightmap baking on that engine. About the extra lights shining through walls, perhaps you turn them off, when the player is out of the zone/room they are in? This will need a script but imo is doable. Do lights still shine even if they are on a room where the portal zone they are in is closed? Btw don't think this will solve the light leak but if you really want a "free" light, don't use the ambient light materials, use a light with a light material with the "blendLight" keyword in it. Blend Lights are just very simple additive lights, used mostly in Doom 3 to simulate fake shadow maps, they do no interactions with surfaces, so afaik no real lighting, no shadows and no specular/normal maps.

Yes it does but it also centers the view on the selected entity, is the way I always used to do what Brendon asked. Btw Brendon loved the latest trailer of Skin Deep, add a smile during the entire thing, in this early stage is already shaping off to be a cool and funny game!

Is a 11 years old card with supposed support for D3D 11 (11.2) and OGL 4.4, so on the API front should be more than enough to play TDM but it apparently only has 512MB of VRAM and that can be a big limitation on the bigger missions.

Strange that I have that off?! Here is the rest of my settings also has you can see sliders have no image still.

Here is mine example: stencil maps I used the windows overlay for this examples both stencil and maps at medium.

I have a RX570 8GB VRAM, also using latest drivers and I didn't saw such a stark diference in performance between the two! At lest not on the "The gatehouse" mission. Can you remind me what mission is that pic from? Also do you have the RX 570 4GB? If yes could be perhaps a VRAM limitation? But would be very surprising to me, if TDM maps would stress a 4GB GPU!

Just to clarify, if someone maybe wondering, the 16 poly limit, is only for dynamic rigid body physics, not the normal static world and mesh collision mesh's. Now IMO, you can't really compare idtech 4 physics engine, to any other in the market, is a very basic and simple physics engine, done inhouse by a single developer at idSoftware, made to be more complex than Quake 3 physics but still a very performant and fast simple physics system, "good enough" for a 2003 game. In reality, is inferior to any third party physics engine on the market, ODE (used in Stalker), Newton dynamics (used by Frictional games), Bullet, Havok, PhysX and others, are way better and more complex physics engines, today any of them, are a better choice for a game engine than idtech 4 physics engine, why, because they are all multicore physics engines (not sure about ODE), while the one on idtech4, afaik still runs on a single core! And if someone is thinking this, even thou it would be awesome, I don't think the TDM physics engine will ever be replaced, the source of it, was the first thing idSoftware released in 2004 and no one, apart from AAA dev houses, have to this day, at lest that I know, improved it further or even replaced it entirely. So imo If 16 polys is the limit than so be it, time to be cleaver and creative with shapes!

Not saying this is the main cause for you to get lost, but good lever designers, use light cues to indicate the player where he should go, by calling for his attention and by playing with forced bright ambient, perhaps you could be missing that important light cues.

Holy... I also add that happen to me once, almost made me give up modding altogether, something like that can destroy someone will for a long time, hope you can recover from the situation fast! Btw on windows you can try using Recuva (from the makers of CCleaner) to try to recover some of your work or even all if you are lucky. I can only say good luck and hope that this situation don't make you give up on TDM mission making.

I seen the frob outline show hidden objects one or two times during my plays, bellow is a example on "The outpost", I can frob the hammer before even opening the chest. forgot to save the view position unfortunately, but is the chest next to the kitchen, where the single guard patrols, when you enter the castle bellow through the water. But this doesn't seem like a problem of the frob outline technique itself but the technique, showing a bug that always existed in the game but we never saw it, because the old highlight was hidden by the geometry in front. So in a sense this is helping debug the game!

I certainly comprehend that stance and see the advantages of it, more clean code means, less clutter and so better readability but if idSoftware add the same opinion, we wouldn't had found some of the cool stuff they let in the engine disabled, like the mega texture stuff that even thou unfinished, was a way to learn about it and that someone made work, partially, the ability to read MD3 files and animations that is now a option to use in TDM for "cloth" effects, the liquid surface class that someone, more or less, also made work, the disabled item highlight that I'm even using for some effects and many other stuff they let in and didn't bother to clean from the source, like a extra more realistic player motion. But you guys do what you think is best in your case.

Afaik there's nothing preventing you from being able to tweak each LOD distances individually using the method I suggested, at import time you set a reasonable default distance for each LOD, then after that you just expose entity spawnargs to the mission makers like always. Like I said this can work just like the shadow mesh and the collision mesh, the lods would just be extra surfaces for the code to manage, even thou the former are imbedded in the model file itself and even on top of the main mesh and each other, you can still access them individually.

Good thing that I'm using good old simple crosshairs for my game interactions... But Is a pity this is such a hard problem, such a "modern" effect that new gamers automatically think your game is cooler because of it. I certainly comprehend Cabalistic frustration, so much work for in the end, not have good feedback because of the glitch's and no easy solution in sight, demoralizes anyone. But like the others, please don't remove it from the engine entirely, if that is what you guys are thinking, if so please make it optional, no matter the glitch's, imo why have so much work coding this, for in the end throw it all away and if you guys don't want to spend time, messing in the menu code to support a half broken feature, just leave it has something for players messing in the game console to discover, is always cool to open games consoles and find things that the developers left in disabled, to me is a game in it self.

I add that off, changed* it but still the slider images don't work even after a restart. *I saw another imo strange behavior on this, when I changed that cvar value to 1, restarted the game, went to the console again and inputted, image_preload, just to see the current value, it showed 0, despite being changed before the restart and on the DarkMod.cfg it is 1. The value gets overridden somehow?

Yes I have a AMD GPU, hope you can solve that problem, because I don't think I will change GPU's anytime soon...

My following suggestion would need changes at the engine level and also require the team to reimport and export the models again from a 3D tool or perhaps make a special plugging for DR to mix the models into a single one, so may never happen but I think it should at lest be considered and it is the following: Some games, include the LOD models, in the main model itself, like how the engine currently uses the collision model and the shadow model, the same could be done for the LOD's, this would have the following benefits that I currently see, it would unclutter the model folder, because you would only need to export one model, all necessary info is within the model file itself, two permit DR to continue with the current model chooser and entity chooser, no need to mix the two or change DR model handling in any big way, apart from perhaps creating a special filter, to hide the LOD surfaces/models if necessary, like is done for the shadow model, and the best benefit imo, instead of the mission maker having to bother with setting up LOD's manually that would be automatically setup by the engine at model import time and so prevent the problem that Dragofer talks about, forgetting or even not bothering with setting up LOD's. How to setup the LOD's in the 3d tool? It could be done like the shadow model is done, using a special LOD material, or if possible they could be put in a different layer that you give a "_LOD_X" name and the engine would read that layer has a individual model, this would need the engine to support importing models with more than one layer, that I don't think it does (but I could be wrong) and I'm not even sure if, ASE and MD5 support extra layers, I know LWO does. My two cents on this discussion.