Search the Community

(I apologize for the odd poll question layout. I wasn't able to add five yes-no questions, because polls are limited to three questions.) Hi everyone, I've recently been working on some patches for issues that I've read about from players on the TDM and TTLG forums — and Discord. My goal is to make it as easy as possible for players, especially new players and those who need usability/accessibility options, to find what they need in order to have a better TDM experience. I've already written the GUI and game engine code for these settings, which I've been using in my personal build. The reason for this poll and discussion is to both guide the finalization of my work and collect data to help inform the dev team. Which patches I submit depend on the outcome of this poll, discussion, and what the dev team agrees to accept. Once decided, I can coordinate with the dev team. I've attached screenshots of what the new settings menu would look like if all of the settings are accepted. Below, I have detailed each menu setting, so you can have an easier time understanding each one. Very important to keep in mind: None of these settings change TDM default behavior. They are all opt-in. If you are already happy with the behavior of 2.10, 2.11, etc. and these menu settings are accepted, nothing will change for you. Rename "Always Run" to "Run Mode" with options "None, Always, Toggle" After 2.11 was released, @i30817 requested that "toggle run" be added to the settings menu. Its cvar is already in TDM as "in_toggleRun" (same as Doom 3). I propose renaming the "Always Run" setting to "Run Mode" with options: "None", "Always", and "Toggle". None = in_alwaysRun 0; in_toggleRun 0 Always = in_alwaysRun 1; in_toggleRun 0 Toggle = in_alwaysRun 0; in_toggleRun 1 Show Blackjack Helper @Wellingtoncrab suggested that the new blackjack helper be added to the settings menu. Its cvar was added to 2.11 as "tdm_blackjack_indicate". More info: It's the new blackjack helper added to 2.11. When the game detects that the blackjack can be used for a successful hit or KO, the blackjack will rise slightly. I propose a "Yes/No" setting for this. Slider for "View: Head Bob" @ChronA requested a way to disable head bobbing, because a viewer watching him play was having severe motion sickness. Also, there was a bug in TDM that made setting the head bob in the console not stick after loading a saved game. (Even with 2.11, if a mission overrides the "tdm_player_thief.def" file and sets "pm_bobroll", "pm_bobpitch", "pm_bobup", and other cvars, it will override player preferences.) As far back as 2008, players have had trouble setting head bob. Another one from 2018. At the end of 2022, @Shadowex3 registered just to voice the need for a way to control head bob. I propose that a slider be added to adjust the amount of head bob. This would use a new "pm_headbob_mod" cvar with a value between 0.0 and 1.0 (default 1.0, no change). The "pm_headbob_mod" would be a multiplier for "pm_bobroll", "pm_bobpitch", and "pm_bobup". The advantage to this approach is that missions like Volta 2 and Hazard Pay would not need to adjust their "tdm_player_thief.def" files for head bob to work properly. And, the player can still adjust "pm_bobroll", "pm_bobpitch", and "pm_bobup" as they like. Slider for "View: Mantle Roll" This is similar to head bob for those who are sensitive to motion. Its cvar was added to 2.11 as "pm_mantle_roll_mod". A Thief player on Discord said, "2.11 will have a cvar to tune down the mantling animation at last." I propose that a slider be added for "pm_mantle_roll_mod". Auto-Search Bodies @Zaratul requested the "auto-search bodies" feature from Thief 1 & 2. Its cvar was added to 2.12 dev16783-10307 as "tdm_autosearch_bodies". I did a poll on the a Thief Discord server and roughly 20% of players there use the Thief auto-search bodies feature. I propose a menu setting for this, so that players coming from Thief 1 & 2 can easily find it.

Awesome! Post is up! https://forums.thedarkmod.com/index.php?/topic/22200-beta-testing-the-house-of-delisle/#comment-487365 Thanks!

Legacy OpenGL? I guess you should ask @cabalistic about it, but to me it's total bullshit. Of course, you need a "fat" driver with deprecated stuff into order to use them. But I think it is only a problem if you want to use newer features (GL3 and later) at the same time. And I think even Linux drivers support deprecated profile today. As far as I understand, you use GL 2.1 and no more than that, and you rely on glBegin and lots of other stuff anyway. In my opinion it is not wise trying to clean everything to Core profile. It will take a lot of time, result in complicated code, and will most likely be slower than it is now. Did you ever try to reimplement immediate-mode rendering (glBegin/glEnd) in Core GL3 ? It is very hard to achieve the same speed as driver shows. If you manage to put everything into one display list, performance improvement should be crazy, at least on NVIDIA driver. Of course, the results are heavily dependent on the driver. The reason they are rarely used today is that they are not flexible: you cannot modify parameters and enable/disable anything. Display list only fits if you have static sequence of OpenGL calls. Perhaps it won't help with lit preview, but basic "draw things where they are" view is OK. Oh, I did not enable lit mode and profiled the basic one. Yes, calculateLightIntersections is very slow here. With L lights and E entities, you have O(L E) intersections in the loop here. That's a hot loop which should contain only a bare minimum of calculations in it. The problem is that you compute light's bbox O(E) times per frame, and entity's bbox O(L) times per frame. Compute boxes once per frame for each thing, and the problem should go away. After that you will have another problem: I understand that you want to have stable pointers when you put objects into container by value. But the truth is, linked lists are very slow to traverse (The Myth Of Ram should be read by every programmer who cares about performance). Unfortunately, DarkRadiant relies of linked lists in many places, and the same problem happens e.g. during scene traversal. Going through entities/brushes is very slow when they are in a linked list. Maybe use std::vector? Or at least std::deque if addresses must not be change? In this particular case, you can copy _sceneLights into temporary std::vector and use vector in the loop (in calculateLightIntersections). Same applies to bounding boxes: precompute them into std::vector-s before quadratic loop.

Hi guys, through the "cheats" topic I got the idea, that it would be quite useful, if there were tags for missions (the post was about removing the killing restriction in some missions to suit the prefered play style). I don't know how easy or difficult this is, but with them, it would be quite convenient to pick missions with playstyles, environment, etc one does want to use. This could also be expanded to other mission properties. I remember a discussion about climbable drains, handles on doors, that cannot be picked and other things the map author chooses for himself. That way these things would be clearer and as I said before, it is easier to choose missions with playstyles that suit oneself. What do think?

The *DOOM3* shaders are ARB2 ('cause of old GeForce support) carmack plan + arb2 - OpenGL / OpenGL: Advanced Coding - Khronos Forums

I am basically rehashing lots of points of discussion which have already come up on the discord, but I think the biggest problem with gear is that in the event of detection it rarely provides a viable or preferable alternative to reloading the game, and so even if the designer attempts to “lead the horse to water” it still seems much more often they will languish in the players inventory. I guess there is always the thrill and brief endorphin injection from hearing that frob sound! Tools I think should be much more effective means of interrupting and ending the alert states of AI, or at least this strikes me as the most fruitful venue for coaxing players out of the detection = failure = reload the game loop. A flashbomb for example provides a rather brief window for escape into at best a lengthy wait for the simulation to reset. Things like the rather brief “I am blind” animation only looping through once also doesn’t provide very good feedback to players how effective the tool even is. I always got the the impression in thief that blinded AI was pretty much opened up to an easy 360 degree KO from the blackjack (and thus a quick simulation reset) but it doesn’t seem to work this way in TDM (striking them at least seems to re-loop through the “I am blind” animation). I also think the default effect duration could be longer (or at less of penalty to the player, or perhaps I am not very good at not blinding myself). Perhaps bringing over the choke mechanic for moss arrows from TDS, even it’s just using the same blind stim, is another avenue to expand the versatility of tools - then moss arrows become multifunction and can also be used to offensively interrupt alerts and open guards to KO. Maybe this could be expanded further and the moss pads not only dampen player sounds but reduce player fall damage (which I understand is technically more difficult than it sounds and has obvious potential ramifications for legacy missions). TL;DR - players don’t use tools - perhaps they should be more useful.

id Studio did a poor job in defining its categorization of variable nomenclature, so in subsequent documentation and discussions there are divergent views (or just slop). In my series, I had to choose something, and went with what I thought would be clearest for the GUI programmer: Properties, which are either Registers (like true variables) Non-registers (like tags) User Variables (also true variables) I see that your view is more along these lines (which perhaps reflects C++ internals?): Flags (like my non-registers) Properties, which are either Built-in (like my registers) Custom (like user Variables) Also, elsewhere, you refer to "registers" as temporaries. I am willing to consider that there could be temporary registers during expression evaluation, but by my interpretation those would be in addition to named property registers. I'm not sure where to go next with this particular aspect, but at least can state it.

I really knew that & shouldn't have said it, but thank you for correcting that. Oh wow, how did I not hear about EV_GetLocation() before? That's great! As for the performance part, stgatilov makes a good point. If you want to keep running track of the AI's location, you have to keep the script running in a loop, which can really eat up up cycles. (Performance was one of our big concerns with the Location script itself because of that.) One thing I'd think about is having the script or EV_GetLocation function called only when an AI is ready to make a bark, and it quickly gets its location from there and makes the bark, and then it's done. Then it's only a one-shot script or function call, which is always better if you can do it. The catch there is I think that'd call for a custom AI script. The issue is if the a future version of the game ever updates that AI script, the custom scripts won't be updated in that version. But since AI scripts should be self-contained, I mean changes almost always take deprecated old stuff into account so it doesn't break old FMs, a custom AI script shouldn't break the FM with new versions of the game. Those AI just won't have any new bells or whistles, which may still be worth it. Or you just quickly add the new things in and kick out a new version if you need to. Of course another option is that new functionality is added to the core game itself with some new spawnargs added to AI, where barks can be made Location specific. For that matter, the AI scripts might be updated to be more friendly to adding barks to existing AI generally, now that we have a good text-to-voice app to make them. Then all mappers get the ability to do this. That might be nice, if it isn't a big performance hit or otherwise troublesome.

Thanks, I can also recommend gog galaxy. The idea of the custom tags is really nice, I'll have to try this out too!

Keep in mind also that mission size, and complexity have increased dramatically since the beginning. For a lot of veteran mappers, it can take over a year to get a map made and released. The last dozen missions have for the most part been pretty massive, with new textures, sounds, scripts, models etc. We seem to be long past the point of people loading up the tools, and banging out a mission in a few weeks that's very barebones. We still do see some of those, but I noticed in the beta mapper forums and on Discord, that mappers seem to make these maps, but don't release them, and instead use the knowledge gained to make something even better. Could just be bias on my part scrolling through the forums and discord server though.

These pages might help a bit: http://wiki.thedarkmod.com/index.php?title=Editing_FAQ_-_Troubleshooting_%26_How-To#Scripting http://wiki.thedarkmod.com/index.php?title=Scripting_basics http://wiki.thedarkmod.com/index.php?title=Script_objects http://wiki.thedarkmod.com/index.php?title=My_first_map_script You don't have to learn all of C++, but maybe just the first two or three chapters in a guidebook (there are free ones online) would be very helpful, just the really core stuff like what are objects and functions and variables, and how you do boolean logic checks and loops, which you do in practically every script. But even without that, since it does use such a common language what you can do is just search the specific problem you have, and almost any C++ tutorial could give you the answer. I do that sometimes. So you can just search "C++ looping". But to address your issue, scripts are objects that get called, act, and then either keep running the rest of the game in a loop, or they get killed at some point and then they're dead forever. What (it sounds like) you did was create a new script object inside another one (when you call a new script, it's now a new script running independent of the script that called it), which then itself called a new object, and so on in an infinite regress of creating new independent objects. You're just calling 10,000s of new objects whose job is to call another one. The kind of loop I think you want is a "while (x)" loop. Just look it up for the syntax. Or here it is: http://www.cprogramming.com/tutorial/lesson3.html In that loop, at the top is the while(x); clause, where X is some variable. As long as X is true, it will keep looping inside the {}'s, and when it's false, it skips over the {}s and continues with the text after the closing curly bracket. Then the next text can just kill the script or have it be another outside loop. If you just put while(1) or while(TRUE), then it will loop forever, which may be fine if it's a lightweight script. If you really want it to stop when the player is out of range, then you have to first decide, is a new script object going to be called every time you want it to start, and killed every time the player is out of range (in which case you'd have to call a new script to start it again). Or would it be easier to just have one script that starts either when the player enters the location (read the location_settings wiki page for how to call a script by entering a location) or at map start (just put it inside of main, which always starts at map start). So then you can make X in the while loop some variable that tracks proximity of the player. You can take the player's XYZ location and the event's XYZ, and subtract the X, Y, & Z parts, get the absolute values, and do Pythagorean's formula to get the distance (or something like that; I'd look it up or draw it on paper to see what I'm doing). If it's less than the value than set your variable to TRUE, and if it's over that value set your variable to FALSE. But the way I'd do it is the script gets called when the player enters a location (the location_system). Then have a function that returns the name of the location the player is in, and then make a check that if it's equal to the location you want. If it is, it makes your x-variable TRUE, and when the player is outside the location, it's not equal and it sets the x to FALSE. Then when the x is FALSE, the loop ends and it goes on with the instructions after the {}s. It can kill the script from there, which ends it forever, and you'd have to call a new one, e.g., on location entry. Or perhaps the easier thing to do is simply put a while loop inside another one. When the player proximity or in-location is TRUE, then the inner loop loops with all the instructions. And when it's FALSE, it skips over all that script text, and then just loops the outside loop, with just the one instruction for it to make a check for whether the player is in proximity. Or, as I said earlier, you just have the one loop and put while(1) and it loops forever, but if it's only a few lines of instructions the processing load is so minimal that it won't slow anything down. If you keep it looping when the player is outside the location, you need to make sure it can never be called again. Either put a check so location-entry only works once, so if a new one was created it kills itself immediately or the on-entry script is just some script or entity that calls a new script and it's set to one-shot, or something like that. Or you just put the script in main so it's called at game start and loop it forever from there.

YOU TAFFERS! Happy new year! Deadeye is a small/tiny assassination mission recommended for TDM newcomers and veterans alike. Briefing: Download link: https://drive.google.com/file/d/1JWslTAC3Ai9kkl1VCvJb14ZlVxWMmkUj/view?usp=sharing Enjoy! EDIT: I promised to someone to write something about the design of the map. This is in spoiler tags below. Possibly useful to new mappers or players interested in developer commentary.

Seems to confirm: https://bugs.thedarkmod.com/view.php?id=5718 does it happen in the latest dev build: https://forums.thedarkmod.com/index.php?/topic/20824-public-access-to-development-versions/

TTLG? That's Through the Looking Glass Forums. A looking glass fan community. Has been around for a long, long time. https://www.ttlg.com/forums/

I just read@motorsep Discovered that you are able to create a brush, then select it and right click "create light". Now you have a light that ha the radius of the former brush. Just read it on discord and thought it may be of use for some people in the forums here too.

https://github.com/HansKristian-Work/vkd3d-proton/tags <- directx 12 wrapper for dxvk https://github.com/doitsujin/dxvk/tags <- directx to vulkan wrappers D3D 9 to 11 eg. dxvk if you want to try it with horizon zero dawn you need to copy out dxcompiler.dll from Tools\ShaderCompiler\PC\1.0.2595\x64 and bink2w64.dll from Tools\bin and place them next to HorizonZeroDawn.exe. then copy over dxgi.dll from dxvk and d3d12.dll from vkd3d and place them next to it to. now fire up the game and let the shaders recompile -> profit.

I think the reason the dev forums exist is to provide a place where the implementation of features can be discussed without getting mixed up with other debates when someone believes what the devs are doing is wrong. We often post public discussion threads for features with subjective elements like the frob outline, because community feedback is very important. But there will always be vocal defenders with strong views for or against certain features, or how exactly it should be implemented in their opinion. At some point a decision has to be made and be carried through, which is what the dev forums are for. Almost all of the threads are very technical, basically explaining and discussing recent or potential code changes with other devs. Its hard to say. Its a hobby the devs do in their spare time, so people come and go when they're in the mood and when they have the time. The team page is mostly accurate except for some relatively newer additions like myself.

I think there wouldn't be embedding (other than transiently) during the while loop, but you are correct that the last two statements beyond the loop embed it halfway. Might be OK if that was a cushion or straw. Otherwise, taking the gem radius into account would be better. (That could just be baked into "tabletopheight".)