HMart

You are right, there's a slight flaw in the system but even thou the light maybe entity zero the c++ code only considers the entity, the world entity, if it has this particular spawnarg, that lights don't have. So even if you create a light first and a worldspawn brush second everything should work fine. else if (!idStr::Icmp(key, "classname") && !idStr::Icmp(value, "worldspawn")) { worldent = true; } I bet idSoftware never cared to have a test for that error because all their level designers, first create a room than create all the other entities and that is how they have been doing since quake or even the first doom. Plus this kind of problem seems to be so rare that in decades following idtech 4 scene this is the first time I saw someone cause such a error. ps. Btw nothing gained from creating a light first, because lights only work if they have some surface to interact with, if no surface will just be a black void no matter how many lights you spawn.

That sure makes more sence to me now, that would be what i would do has well.

Ah ok thanks, not that I have much confidence on windows but makes me more relieved that is not worse than Vulkan, there's not much around but I've yet to have a vulkan game/demo crash windows and for now, I don't see anyone complaining about that in TDM, so that is also a good sign.

I said almost the same thing to him Destined, in another thread, what I got in return was imo scorn. To me not a good start in this community.

Was reading about bindless textures to know what they are and saw this: Is that really that unsafe?

The engine is not mine sir "I am an experienced tester..."

I didn't realized you were talking about a single room, in my mind I though you were talking about your entire map so my bad. But even so be carefull, If your room is relatively small and square shaped, I don't think theres any problem. I learned to map by doing it, even thou I never released a TDM mission or anything of importance yet, I did spent many hours, just messing around with DR not going anywhere but it did permitted me to learn but you don't really have to map to know what I said, I'm following the Doom 3/idtech 4 mapping scene for decades now, I learned many things along the way. Springheel far from me to try giving you a lesson, you certainly know your craft well more than me. But just to clear some stuff to me, what you said is totally true, entities don't seal the void and you need worldspawn geometry to seal against it but IMO even thou it works fine in most instances, I'm I wrong in assuming that if, for example, you create a cross shaped corridor + and you just make a sealing room around all that, it will cause problems with AAS, sound pathing and cause light leaks, all because you will not be able to portalize (is that the word?) the corridors?

The programmer of this game is not a single person... I also work with idtech 4 and have many experience with it but that doesn't mean what I know serves or works in DarkMod, why, because it doesn't use the original Doom 3 engine, it has been changed in many aspects. You shouldn't expect, all console cmds that worked in Doom 3 to still work, they could be dead code that was just not removed, even the original idtech 4 engine has console commands that do nothing, console cmds are very volatile and change or get deprecated during development. You also shouldn't expect this game to work, in your PC like Doom 3 did, why because, it has a relatively modern render, using GLSL 3.0+ I think and doesn't support old GPU's that Doom 3 supported fine. Having said that there's no harm in telling the darkmod team that some commands don't work, perhaps they should but have in mind what I said above.

If the tutorial teaches that then, it is teaching a bad behavior, you should never solve leaks, by just making a "room" around your map, leaks are VERY important to catch, if a map has a leak, the engine portal system will fail to properly occlude geometry, sound and light and the map will run like garbage, have sound going through walls and light leak into rooms it shouldn't, causing visual and auditory glitch's. Another thing that causes leaks is the origin of models being in the vacum, the origin IS NOT where the model is visually, the origin is a invisible point, used by the engine to know where they are and place models around, even though a model may be visually inside a room, its origin may be not. When you select a model, its origin shows up as a gizmo shown as Red, Green, Blue lines (x, y, z) coordinates, if you select a entity and don't see the gizmo, then it means the origin is far away from it.

I will not jump immediately 100% to the side of Frogwares, like many here, why, because this seems really suspicious to me, Nanco left huge clues behind, like they didn't care if they got caught, is if they are very sure they will win any law suit frogwares throw at them and that maybe because of something we don't know. We only heard one side here. But don't think I condone the behavior or any publisher stealing developers.

stgatilov I know this will increase coding complexity and work but couldn't you guys do that automatically in the background, when the user brings the rez down in the menu? IMO it would totally eliminate this complains. So I would remove the resolution scale from the menu to minimize confusion, keep the "old school" resolution option but when the user is messing with the rez they are in reality messing with the rendering scale, the rez label is just a front to hide the truth but to the final user the visual effect should be the same, what do you think?

Yes it is not what we are used to, it breaks our old mental model of how resolutions work but do what stgatilov said, lower the rendering scale in the menu to 0.5 and it will do the same thing, even thou the final image is 1080p the GPU is only rendering a 540p image and upscaling it, so better performance and worse image quality but that would be true, even in the old lowering resolution situation, unless you are using a CRT Monitor, on most LCD screens that have a fixed resolution, anything lower than native rez looks blurry has hell, that is the case with my old 3D LCD monitor.

Sorry I should have said that I don't work with TDM, so I don't really know all the details about the ways stuff is done here, specially when the TDM engine has changed much from older idtech 4, what i know (using the original Doom 3 engine) may be totally deprecated in modern TDM, but def_attach5: atdm:prop_torch_gothic_on is a normal link to a entity definition. here in the file tdm_prop_items.def // -------------------------------- // Carryable Lights // -------------------------------- // lit torch for AI to carry around entityDef atdm:prop_torch_on { "inherit" "atdm:moveable_base_carry_l" "editor_displayFolder" "Props" "editor_usage" "A lit torch to be carried in the left hand." "model" "models/darkmod/lights/extinguishable/torch.lwo" "mass" "2" "bouncyness" "0.02" "friction" "0.2" "snd_bounce" "tdm_impact_handle_long" "angles_hand_l" "90 90 0" "origin_hand_l" "0 4 0" // forward from hand, height, x "angles" "90 90 90" "frobable" "0" // don't frob until the AI drops it "is_mantleable" "0" "drop_when_ragdoll" "1" "drop_set_frobable" "1" // grayman #2900 - to make LightsToggle() work correctly: "extinguished" "0" "extinguish_on_drop" "1" "extinguish_on_drop_delay" "3" // in seconds "extinguish_on_drop_delay_random" "2" // random time added to base delay time "remove" "0" // a light that can be carried around (opposed to AIUSE_LIGHT) "AIUse" "AIUSE_LIGHTSOURCE" "lightType" "AIUSE_LIGHTTYPE_TORCH" "def_attach" "atdm:prop_torchflame_moving" "scriptobject" "tdm_light_holder" "arrowsticking_disabled" "1" // grayman #837 "replace_anim_walk_alerted" "walk_alerted_torch" //so they hold torch up "is_torch" "1" // can be used to relight doused flames } // lit torch for AI to carry around entityDef atdm:prop_torch_gothic_on { "inherit" "atdm:prop_torch_on" "editor_displayFolder" "Props" "editor_usage" "A lit gothic torch to be carried in the left hand." "model" "models/darkmod/lights/extinguishable/torch_gothic.lwo" "arrowsticking_disabled" "1" // grayman #837 } both "def_attach" "atdm:prop_torchflame_moving" "scriptobject" "tdm_light_holder" may control the light, i don't know.

Not sure but hope this helps, If the "torch" is a normal particle than it has no light (unless the effect is created using a fx file), so perhaps is a prefab, meaning a group of many entities, if so afaik, you need to edit the prefab/group, by ungrouping the prefab and selecting the light entity itself and than you can edit it in DR like any normal light.

Will just leave this here for some future inspiration.

Normally the shaders used for water are the heatHaze ones at lest in normal idtech 4. But to be sure, you can see what material is on a surface by opening the console and typing r_showSurfaceInfo 1 that will display the name of the surface the player is currently looking at, be mindful that this detects invisible materials as well, like nodraw, shadow, collision surfaces, etc, so you may have to move the view around, until the ray hits the required surface. By knowing what material the surface uses, you can search for it and see what shader it calls, or if it calls a shader at all, many materials don't call a shader they get processed automatically by the engine internal rendering system.

Personally I totally agree with New Horizon you can make a retro looking game look has fresh has a modern game with clever art direction. Case in point. https://www.youtube.com/watch?v=CgrLN9Wl4xU and

I'm not totally sure but I think that is just the case of getting the depth information, from the depth buffer, but like I said I'm not a shader guy. If is the depth buffer and if I'm recalling well, TDM has that exposed to the material system, to solve some of the water shaders bugs, like the old case, where the player was looking in some direction and the weapon happened to be on top off some water, from far away obviously but we could see it reflected on the water as if it was in the water itself. But I will not fall in the same trap again, perhaps he just doesn't know how to access the depth buffer, neither do I or the code he found, uses some other technique, if he can't he can't and that's fine.

IMO Thief was certainly not successful as HL, for example I never heard of it before thief 3 came out, while I knew about HL very fast and early because all my friends talked about it and passed it along. About making a new thief game on the old dark engine, imo is totally possible, I don't believe will ever happen but is possible, but some graphical updates most be done to the engine, if not even old school gamers would look at it funny. None of the retro games that I know use the pure old engine and graphics, they all implemented modern stuff in the render, is just not realistic to expect a large number of modern gamers, to accept a new game, looking like a pure game made in the 90's. For example look at Solaco is retro and modern at the same time but still this developers don't expect to sell to the level of AAA games, is a nich market game, is retro but still add to update the engine to be able to realisticaly sell and gain support. Another example of a old school retro game that still looks "old" but is modern at the same time. https://www.moddb.com/mods/wasteland-gentek/videos/wasteland-smith-wesson-model-29-part-2

I certainly don't know enough about gl blend modes, the most I use is blend, add and filter, so if is hard to do that forget it. I'm just saying that imo using a simple name, is better to understand for a artist, even if is just a vague descripting than gl_src_one, gl_dst_one (aka add), photoshop soft light maybe vague but imo gives a better idea of the final effect (or intended effect) than any gl blend keyword. And for those that don't know english (that i assume are few here) the small name becomes a association with a effect, even if they don't know what the word means, and that is true even for the gl blend keywords but at lest the name would be shorter. So based on this discussion, perhaps the custom blend modes should be considered advanced? IMO only someone well versed on gl blending really knows how to mix and match the gl blend keywords, if not is a "throw mud at the wall and see what sticks" thing (but to be fair that is true even for the photoshop blends... ).

To me is not easy to sugest what the basic section should have, because people using this tool, will be using it in diferent versions of idtech 4, with diferent basic requirements, so to simplify things it should support only the basic requirments of original idtech4 and obviously TDM. So imo yes blend modes, should be in the basic tab but if I may suggest, instead of using the OGL low level keywords, like gl_zero, gl_one_minus_src_alpha, etc, I suggest that they should be named in a more user friendly way, something similar to what photoshop does, you already have, add, blend, modulate and filter, that imo doing exactly the same thing is redundant, the engine has to support both for backwards compatibility but the material editor could force the usage of only one, perhaps filter?, then maybe invent names for other blend types that we may find in TDM materials or even Doom 3 materials that don't have a "name" assigned but use the low level gl keywords. based on this discussion this maybe the equations for photoshop blend modes (didn't tested them), also don't know if idtech4 supports all this blend modes using the gl blend keywords multiply a * b screen 1 - (1 - a) * (1 - b) darken min(a, b) lighten max(a, b) difference abs(a - b) negation 1 - abs(1 - a - b) exclusion a + b - 2 * a * b overlay a < .5 ? (2 * a * b) : (1 - 2 * (1 - a) * (1 - b)) hard light b < .5 ? (2 * a * b) : (1 - 2 * (1 - a) * (1 - b)) soft light b < .5 ? (2 * a * b + a * a * (1 - 2 * b)) : (sqrt(a) * (2 * b - 1) + (2 * a) * (1 - b)) dodge a / (1 - b) burn 1 - (1 - a) / b next to blend mods the following imo are also some good candidates for the basic section; surface type list: wood, rock, grass, etc (any way to assign custum surfaces?) editor image : optional? perhaps use automatically the diffusemap? description: this one is totally optional in normal idtech 4, I didn't used it at all in my materials, but afaik it is required for TDM? turn on or off shadows/selfshadows: alpha on off translucency solid surface or not two-sided or not The rest of the global material keywords could go into the advanced section, or have a toggle next to the list that says "show all global keywords"? Just my two cents.

I know that your intention was good and to help improve the tool but imo you need to control your temper. No one wants you to go away from this type of threads, just be calm and in the future accept that others don't take things as seriously has you may take. or may take things seriously but not in the same way, all this debacle would be avoided if you just did that. Please lets all calm down and help improve the material editor.

That is a very good idea afaik not even the Doom 3 included material editor does that.

greebo please don't let peter_spy get on your nerves, he can be a little obtuse but he has sometimes good advice to give, we just need to separate it from his way of giving that advice. Please continue working on the material editor and work on what you want to work, do continue posting here for us to "critic" constructively and give our input and also our kudos imo you and OrbWeaver deserve more praise than what is giving. Now I believe many here don't care much about the look of the tools, if we did, we wouldn't be working on idtech 4 and would be working on any other modern engine, where the tools looks, in some way, are more important than the engine itself.