Search the Community

Some folks have been asking about the new tdm_show_viewpos cvar and screenshot_viewpos command, so I thought I'd make an thread about it as a reference. The purpose of the cvar is to show the viewpos on the player HUD, and the purpose of the command is to add the viewpos to screenshots in order to help with troubleshooting and beta testing. Bug tracker: https://bugs.thedarkmod.com/view.php?id=6331 tdm_show_viewpos tdm_show_viewpos is a cvar to show/hide the viewpos on the player HUD, which can be set to the following: 0 --- hide 1 --- gray font color 2 --- cyan font color screenshot_viewpos screenshot_viewpos is a command that takes a screenshot with the viewpos added to it. screenshot_viewpos screenshot_viewpos <gamma> screenshot_viewpos can be typed at the console or bound to a key. The "gamma" is an optional argument, which as of 2.12 Beta is the r_ambientGamma value. Some mission authors prefer to have screenshots (from players) that are brighter, so they can see what is in the screenshot more easily. Setting the "gamma" argument is a convenient way to temporarily adjust the gamma just for the duration of the screenshot. For example, I have the following bound: bind "F12" "screenshot" bind "F11" "screenshot_viewpos" bind "F10" "screenshot_viewpos 1.3"

I suspected a Python issue may be involved as well. To test this I tried: ./configure --prefix=/home/mircea/Downloads/DarkRadiant/install/ --enable-debug --enable-relocation --disable-python --enable-darkmod-plugins This removes the Python related symbol error, however the RegisterModule one remains. DR still fails to start with the same complaint about no ScriptingSystem module, whether due to that remaining missing symbol or some other reason not shown in the logs. mircea@linux-qz0r:~/Downloads/DarkRadiant/install/bin> ./darkradiant Gtk-Message: 22:39:25.363: Failed to load module "appmenu-gtk-module" ModuleLoader: loading modules from /archive/mircea/Downloads/DarkRadiant/install/bin/../lib/darkradiant/modules/ ModuleLoader: Loading module '/archive/mircea/Downloads/DarkRadiant/install/bin/../lib/darkradiant/modules/sound.so' ModuleLoader: Loading module '/archive/mircea/Downloads/DarkRadiant/install/bin/../lib/darkradiant/modules/libradiantcore.so' /archive/mircea/Downloads/DarkRadiant/install/bin/../lib/darkradiant/modules/libradiantcore.so: undefined symbol: RegisterModule ModuleLoader: loading modules from /archive/mircea/Downloads/DarkRadiant/install/bin/../lib/darkradiant/plugins/ ModuleLoader: Loading module '/archive/mircea/Downloads/DarkRadiant/install/bin/../lib/darkradiant/plugins/dm_stimresponse.so' ModuleLoader: Loading module '/archive/mircea/Downloads/DarkRadiant/install/bin/../lib/darkradiant/plugins/dm_difficulty.so' ModuleLoader: Loading module '/archive/mircea/Downloads/DarkRadiant/install/bin/../lib/darkradiant/plugins/dm_gui.so' ModuleLoader: Loading module '/archive/mircea/Downloads/DarkRadiant/install/bin/../lib/darkradiant/plugins/dm_editing.so' ModuleLoader: Loading module '/archive/mircea/Downloads/DarkRadiant/install/bin/../lib/darkradiant/plugins/dm_gameconnection.so' ModuleLoader: Loading module '/archive/mircea/Downloads/DarkRadiant/install/bin/../lib/darkradiant/plugins/dm_objectives.so' ModuleLoader: Loading module '/archive/mircea/Downloads/DarkRadiant/install/bin/../lib/darkradiant/plugins/dm_conversation.so' XMLRegistry: looking for XML files in /archive/mircea/Downloads/DarkRadiant/install/bin/../share/darkradiant/ [filters] Loaded 16 filters from registry. Exception initialising modules: ModuleRegistry: Module doesn't exist: ScriptingSystem [skins] in tdm_epi_skins.skin: skin steam_engine_003_off previously defined in steam_engine_003.skin! [skins] in tdm_epi_skins.skin: skin steam_engine_003_on previously defined in steam_engine_003.skin! Aborted (core dumped) I have the python-devel package installed, however that refers to version 2.7... there should be a python3-devel but for some reason it's not showing up for me, I will investigate. As for openSUSE Tumbleweed it's easy to download and install the latest snapshot (x86_64 DVD image): https://software.opensuse.org/distributions/tumbleweed

Yes, this is happening for me as well. @Dragofer perhaps the immobilization script is misbehaving in 2.12? Should this be added to the 2.12 beta thread?

*****UPDATE***** cabinet1 fans! Version 2 of the cabinet1 extension pack is here with a new desk and bench model as well 5 unique hutch and curio cabinet prefabs! Big thanks to cabinet1 expert @Dragofer who generously polished the models and prefabs and fixed up the naming/pathing/definitions to be core mod compliant. God speed! cabinet1_xtended.zip *****Original Post***** Jumping over from the Discord where you should definitely join us if you aren't there already. No modelling skill here what so ever, but I have long found myself hopelessly addicted to cabinet1. Now it has gotten even worse with desk02 and desk03 being such great new assets. I just wanted/needed a little more matching furniture for my map so I put these together in DR. To be clear these are very basic but along the way I thought they might be of utility to anyone else who just needs more of that cabinet1 magic and can't wait for the pros to deliver the next dose. Of course just like cabinet1, desk02 and 03 they all have the "desk_old" skin variant and there is a prefab for the curio cabinet with working doors. God speed.

So... that happened.

Thanks for summarizing the most relevant arguments. Saved me from reading this monster of a thread in its whole. It is obvious that a lot of thought from a lot of smart people has already gone into this. Still, it kind of rubs me the wrong way that the grabber-interaction with bodies is so fundamentally different than the rest and it frequently annoys me that I can't hold-type-grab junk objects as well. So maybe, to catch two flies with one stone, the hold-type-grabber-interaction just needs to be added to a few more entity types. In other words, stick to the frobbing-rules you guys developed in this thread, but additionally add hold-type-grabber-interaction to Junk and Tools, and if possible, Loot as well. Entity type Short Press Long Press Junk Toggle-Grabber Hold-Grabber Food Toggle-Grabber Eat Loot Pick-up Hold-Grabber?? Bodies Shoulder Hold-Grabber Lights Toggle-Grabber Exstinguish Tools Inventory Hold-Grabber (Highlighted interactions in the table differ from the new control scheme)

Unless I am missing something the only really difference in this table vs the current implementation would be inverting the shoulder/grabber behavior for bodies (I guess it also removes the fall back on long press to do the default action on things like junk - not sure if it is actually preferable for some reason to just do nothing in these cases). Switching the body interaction to shoulder on frob is one of the foundational elements of this change and judging by the polling information is supported by a majority of players. The reasons for this change are well articulated in this thread, but the short version is that this has been confusing new players for years who actually think there is no shouldering mechanic in the game at all. The first thing the game shows them is fine manipulation of bodies via the dragging mechanic, and they must learn to use an unfamiliar key combination to actually carry one. This is only described in a easy to miss readable in the training mission. I am myself only learned of this mechanic after playing several missions and by accident. You can read accounts of players literally giving on the game elsewhere in this thread. I imagine they would potentially support this change as well. Which is the more common action a player must undertake in the game - shouldering a body or manipulating limbs and slowly dragging it around? So if that is the only element of the implementation which is “inconsistent” (again I don’t think this is actually important - shouldering is the primary interaction with bodies in almost every other similar game and this confuses no one) then I think it’s a pretty small tradeoff for a pretty big pay off.

It is quite litigated in the thread already whether it is particularly important or common in games for a context sensitive input be "consistent" or whether this inherently means something is intuitive - so I won't repeat my thoughts on it. I will say It seemed like it was quite difficult to get this change as it is into the game, so while I think anything can be improved I am not sure anyone wants to go through another 10 pages, polls, etc. So I hope I don’t sound short or dismissive, it’s really not my intention, it’s just been a very long thread. I will say if an object is frob highlighted, ie subject to an interaction prompt, if frobbing it then does not do anything or provide any feedback the game immediately feels very strange and broken. I do not think it is good a idea to have objects which can only be interacted with via long press. The current design is around primary interactions being on short press and the secondary more situational actions being on hold, while also retaining compatibility with all legacy interactions. There is some disagreement as far as what is a "primary" interaction, but I find it pretty intuitive in practice as it is today. There are some exceptions that did not work out in testing. I will the example of candles/lanterns - having extinguish as the primary interaction makes a lot of sense, but in practice didn't work very well. The game is full of extinguished candles, empty candle holders, etc that are now simple physics objects that require a long press to pickup and have no primary interaction - see issue above. You also have to handle lanterns differently, which can be toggled off/on. You could code in the TDS method which is extinguish a lit candle on frob, then it becomes a physics object (“junk” in the parlance of your table) so the primary interaction should then be grabber. There seemed in general to be a lot of concern about keeping the code clean. Being able to grab moveable inventory objects on hold without having to do the current dance of bringing them into inventory first and then “dropping” them - like keys and tools - could be a nice addition. Many loot objects are not moveables so these might be a bit of issue?

i have the source code for the game libraries as well though there are precompiled versions included in the above archive they were built using msvc 4.0 so for anyone wanting to port this to a more modern compiler would probably need these as well. I would have to upload it to someone here as the original link is long gone. Its about the size of a floppy so close to the max size that can be uploaded to the site. i split the archive into 3 and recompressed it.DarkEngine_2_libs.7z.002DarkEngine_2_libs.7z.001

Bumping this thread. I was trying to parse the code for LibreCoop recently, the multiplayer coop mod for Doom3, or Dhewm3 more exactly. The main alternative is OpenCoop, but I think LibreCoop is more developed. Anyway, it got me thinking how much work would have to go into a coop mod for TDM. It's still my biggest wish item. The idea I got was one has to basically walk system by system through the code and think about the client and server side of packet swapping. TDM has a lot more and more complicated systems than Doom3, but once you start getting a feel for it, I think the basic system doesn't change that much. In a way it reminded me a bit of a pared down save/load system, what you need to update a game state, except you're streaming it in in real game-time, and you using tricks to fill in gaps to ease the load. The other thing I noticed is that maps themselves need their scripts tweaked and anything else happening in the world. But I wonder if there's a way to procedurally do that when a map is loading, so one could just use the FM files as released. It looks like it'd take more than a year or two if one were working steadily through it, although I think one would get efficient at it over time. Like I was noticing, there's a consistent logic to it. But most of all I think it'd be worth it. I really like Thief coop, and I think it'd be great for TDM. I'm just FYI'ing about it now because I was browsing through the other coop mods. Not even soliciting opinions or anything. Just thinking aloud (avisible?) about it.

I guess posts about helping people understand what this thread is not for kind of still count.

Is there a feature request thread?

Hello everybody. The Beta Testing subforum said to recruit testers before making a thread there, so I'd like to recruit first and then make a thread there if anybody's willing and interested. I've just finished work on my first Fan Mission, "The Threepenny Revue" and I'd like to get outside opinions on it. I have a zip file with the directory and files that can be dumped into the /fms/ directory and it should play, but it hasn't otherwise been packed up properly yet. The files will be available on my own site, and I'll post a link to it in the Beta Testing thread if there any takers here. I'm still finding my legs with the process of sharing FM files, so I might mess things up but hopefully it works. Thanks in advance.

I haven't been able to make contact with the Mission Archive built into the game. Its telling me it cannot connect to the server. I currently have 135 missions downloaded. Could it be that's all there is, as I also get a comment "No new mission packages available for download".

There's a group of players who have meticulously tested and adjusted ghosting rules for The Dark Mod. Please see: Official Ghosting Rules: https://www.ttlg.com/forums/showthread.php?t=148523 Ghost Rules Discussion: https://www.ttlg.com/forums/showthread.php?t=148487 Why alienate an established group of dedicated players?

Recently revisiting the forums after a longer period of time I wanted to check the unread content. I don't know if I am doing this wrong since.. ever... but on mobile (visiting the unread content page on my smartphone) you have to click on that tiny speech bubble to go to the most recent post in a thread. If you don't click correctly you'll hit the headline and end up at post 1 in the beginning of the thread. It's terrible on mobile, since not only the speech bubble is really small and was to miss. But also the thread headline is just millimeters away from it so you go right to the first post that was ever made instead of the most recent ones. Am I doing it wrong? I just want to go through u read content a d the to the newest post from that topic.

I'd like to better understand what you want. The design of dragging bodies is to hold frob (key down) to drag and release frob (key up) to let go. That way it's impossible to walk away while unintentionally dragging a body. Plus, it's quick to grab and move several body limbs in rapid succession. This is thought to provide a better experience, especially for new players. Towards the beginning of this thread, I created a "tdm_frobhold_drag_body_behavior" cvar. https://forums.thedarkmod.com/index.php?/topic/22198-feature-proposal-frob-to-use-world-item/&do=findComment&comment=487580 "tdm_frobhold_drag_body_behavior", default:"1" Which drag body behavior? 1 --- on frob key up, drop body (limb). 0 --- on second frob, drop body (limb), TDM v2.11 (and prior) behavior. That cvar was removed shortly afterwards, because it was said that it wasn't needed. With that cvar set to 0, a second frob would be required to let go of the body. Is that the behavior that you want? If so, I can add that cvar back. Also, I saw elsewhere that you want the ability to revert back to the old way. If you mean that all of the controls match TDM 2.11, that can be done with "tdm_frobhold_delay 0" and there will be a menu setting to disable it as well.

This is the same scheme the most radical voices in this debate have been asking for from the start. (Myself among them.) I thought it was settled that having extinguish on short click created a back-compatibility risk for a small subset of old FMs. I think the concern was putting out candles that are needed as a light source to progress, and then not having flint to relight them. That's why the current (mechanically and cognitively sub-optimal) compromise was selected. Am I remembering right? If so, let's just all reread the thread history rather than rehash this argument over again.

This is what you said: 1) That while playing you found you could not extinguish moveable lights 2) This was because of the need to use the hold frob and did not remember this I know you wouldn’t make a misleading statement about the implementation of the hold frob mechanic as a pretext to bring up your issues with the consistency with the controls, so I assume you forgot the original controls of the game or your custom keybinding for “use inv item” reset when you updated the game or something. At this point in the thread I am not going to recommend to you that you use an optional mechanic that you don’t like. There is a version of the training mission in development which tutorializes the hold frob mechanic - though eventually it would be good to develop a tutorial mission that is less freeeform than the training mission.

Looking at the code, the originals were "pm_mantle_pull 750" and "pm_mantle_pullFast 450". The new "pm_mantle_pull" value is "400". A "pm_mantle_pullFast" value of "450" would be slower than regular pull, not faster. With both being set to "400", they are at least similar. Other than that, it's subjective and the feedback from playtesters was positive. Also, referenced internally here: https://forums.thedarkmod.com/index.php?/topic/22256-movementcontrols-settings-in-main-menu/&do=findComment&comment=489158

Hello, as others have done, I'd like to start my own mapping thread to provide content I create in one place. Feel free to use anything from this map in your maps or for TDM integration. There is a book in the map with more description of the contained content. OGDA_Demomap Version v3: https://das-kartell.org/files/thedarkmod/ogda_demomap/ogda_demomap.zip Installation: Extract the content of the zip-file your "TDM install dir/fms" folder, the folder "TDM/fms/ogda_demomap" should be present afterwards. I'll post new versions from time to time when I have new content ready. Current map contents: v1: New Paintings (for details see here: New paintings thread v2: TDM Fountain prefab expanded with base, water, light and particles Drainable/fillable bath with sounds and secret compartment only accessible when drained Moving bookshelf with hidden compartment, very failsafe, the setup ensures no clipping or false states will happen (with one tiny exception, see book) Buildings (TDM defaults) with lights, monster-clip ond some details added New Buildings, mainly created from Springheel's TDM modules v3: Ambient light setup Additional info for the current version: - Foutain still needs monsterclipping - the largest building on the right side has a working window where the candle is, you can fill the room with content or revert the window to a func_static - most of the content that belongs together is grouped for easier copying/moving - most of the content is created for A night of loot 2, but that map is still in extremely early stages, there's no guarantee or release date for that one Credits: Additionally to content created by me, this map contains content provided by: - The Dark Mod - Obsttorte (i.a. fog script, texture blending) - Springheel (modules shipped with TDM) - TDM community github repo (Thread) Please let me know if you find content created by you in this map in case there isn't a mention yet. Screenshots:

That sort of tone doesn't fly in our forums.

The beta testing thread is up:

DarkRadiant 3.8.0 is ready for download. What's new: Feature: Support new frob-related material keywords Improvement: Mission selection list in Game setup is not alphabetically sorted Improvement: Better distinction between inherited and regular spawnargs Improvement: Silence sound shader button Improvement: Add Reload Definitions button to Model Chooser Fixed: Model Selector widgets are cut off and flicker constantly on Linux Fixed: DarkRadiant will not start without Dark Mod plugins Fixed: GenericEntityNode not calculating the direction correctly with "editor_rotatable" Fixed: RenderableArrow not drawing the tip correctly for arbitrary rotations Fixed: Light Inspector crashes on Linux Fixed: Models glitch out when filtering then showing them Fixed: Skin Editor: models not centered well in preview Fixed: "Copy Resource Path" includes top level folders Fixed: Skin Editor: internal test skins are shown if Material Editor was open previously Fixed: Changing Game/Project doesn't update loaded assets correctly Fixed: Model Chooser: initially hidden materials aren't revealed when enabling them Fixed: Choosing AI entity class 'atdm:townsfolk_commoner_update' causes crash Fixed: Sporadic assertion failure on shutdown due to LocalBitmapArtProvider destruction Fixed: Prefab Selector spams infinite error dialogs on Linux Windows and Mac Downloads are available on Github: https://github.com/codereader/DarkRadiant/releases/tag/3.8.0 and of course linked from the website https://www.darkradiant.net Thanks to all the awesome people who keep using DarkRadiant to create Fan Missions - they are the main reason for me to keep going. Please report any bugs or feature requests here in these forums, following these guidelines: Bugs (including steps for reproduction) can go directly on the tracker. When unsure about a bug/issue, feel free to ask. If you run into a crash, please record a crashdump: Crashdump Instructions Feature requests should be suggested (and possibly discussed) here in these forums before they may be added to the tracker. The list of changes can be found on the our bugtracker changelog. Keep on mapping!

After having trouble dragging the body where he wanted, the player said, "No. Noooo." (29:09) Player said, "I'm sorry. I'm not trying to look up there. It's just very awkward to drag bodies." (30:08) What I see is a player having trouble being stealthy while playing a stealth game, so this video just adds evidence in support of making shouldering the primary action over dragging. I never saw that he figured out how to shoulder a body. I think we are wanting to optimize for two different scenarios: One is to optimize for a stealth experience, and the other is to optimize for a "comical" experience. If I'm understanding you correctly, you have a strong fascination with body manipulation. Earlier in this thread, you stated: What you find as "comical", I see as the player suffering with the gameplay and struggling with the controls. Players have written their frustration with the pre-2.12 controls and stopped playing TDM all together. I've already seen players write about their interest in trying 2.12 based on the recent changes, which is huge. They're willing to give it another go, and that's great for our community. I am interested in watching playthrough videos and reading player experiences with the 2.12 version once released. Then, we'll be able to get more feedback about the 2.12 controls. Body manipulation is still available, and I find that it's even easier to do with the 2.12 controls. @STiFU commented something similar: @snatcher, given that body manipulation is so important to you, then I suggest creating a group and creating content about body manipulation. This could be similar to the groups that ghost or ironman the game. For example, Rule #1: Bodies must be dragged. Shouldering bodies is not allowed.