Search the Community

Time ago it was discussed here about Hearing Impaired and Hearing Unimpaired modes. Nothing was decided back then and now we have everything. This actually turned to be a good move because code-wise we now have lots of tools at our disposal but, in my opinion, by firing everything at all players we may end up alienating many / most. I want the average player - interested in subtitles - to keep subs enabled and have a good time enjoying the good work done here and elsewhere and I keep working on an alternative: Alt Subtitles for 2.12 v0.1 Background replaced with a (fake) font outline Widget removed (too many things to focus on) Text transparency based on distance (imperfect) Story subs can take up to three slots Barks limited to a single instance Yellow color for story subs (intensity reduced a little from previous attempts) Light grey color for barks It is far from perfect but it may lead to other ideas. Download the pk4 attached to this post and move it to your root folder. I suggest taking the Braeden Church mission for a spin. Delete the pk4 once testing is complete. z_alt_subtitles_v0.1.pk4

I think this is probably "it depends". If a single AI is giving a story monologue, it may be implemented as a single .ogg file, just broken up into subtitles. So this would all be in the same slot. (Likewise, there are some long barks in a single .ogg file too). But the story could be in multiple .ogg files, delivered by one or several AI. Then, the slot could vary, if there also barks happening that scrambled things up. I could be wrong about this. I recall there was some chatter a long while ago about making what slot an particular AI uses somewhat sticky. That's interesting, about volume (or distance) threshold triggering of subtitle display. I'm guessing no threshold test is applied for story subs.

I suggest you use the term "I", to make clear that it is something YOU want, and that you speak for yourself. But, as wesp5 mentioned, I don't really know what this is about, at all. And, I'm also wondering about all the newly registered people lately, who just arrived at this forum, and already want to revolutionize this mod. This is a thing I noticed 2 or 3 years ago, and which hasn't been present in the 15 years I play this mod and frequent these forums now. Really seems like a common thing these days, to not knock on the door, but kick it in, and stomp right in.

Maybe start with finding who are these "we" people who want to change the license to assets?... As a programmer, I definitely do not want to maintain any additional packages. And I do not want to get entangled into any kind of licensing questions. Just that I understand: A license that forbids commercial usage is considered not free (CC-NC). A license that allows commercial usage but efficiently forbids making money from it is considered free (GPL and AGPL). Yes, this is a great distinction Now someone should come and say "but hey, you can sell your support for GPL product!" UPDATE: Well, I think there is also an approach when company provides reduced version under GPL and expanded version under commercial license (like Qt). As long as reduced version is reduced enough, it seems to work fine.

When talking about a possible libre version of TDM (https://forums.thedarkmod.com/index.php?/topic/22346-libre-version-of-tdm/) it seems we believe all media/gamedata included in TDM is licensed CC-BY-NC-SA. I am not familiar with how the process of adding new media/gamedata works today; I have seen files uploaded to the bugtracker which developers then commit to SVN, but I don't know if there are other ways. It may be a good idea to implement a process that when new components (media/gamedata included in TDM) are added, the contributor is asked to be explicit about the license (a choice which may defaults to their previous preference, for usability). It won't fix the past, but it may help in the future. This will make it easy for contributors to add future data under a more permissive license if they choose. Libre media can be added and its license can be tracked, rather than assumed to be CC-BY-NC-SA. I suggest looking at how Wikimedia Commons has implemented this: the contributor state the source and license at the time the data is uploaded. This can be done either by providing urls or by saying "It's my work and I choose this licsense". The first step could be to add a way to keep track of each filepath in SVN, author, license, sources. Start by setting the value for each file's license to "(default/legacy CC-BY-NC-SA)". Possible implementations for a user interface for new additions are: * Use our own wiki, which runs Mediawiki (same as Wikimedia Commons). I see several benefits of this, but we also need a way to accept uploads of batches, not just single files. * Look at how other open source projects have solved this. There may be more appropriate solutions available. ... but I'll leave the implementation open. Suggestions are very welcome! If the author of each file already in SVN can be tracked, then it may be possible that the author is willing to give a blanket permission for all their past files in one statement, and all their files in SVN can be updated in one commit. A productive contributor willing to release some of their work under a more permissive license could make a big change. If Dark Radiant would support letting mappers search media/gamedata by license (does it already?), it would make it easier for mappers to create a completely libre mission, which would help facilitate a TDM-libre release. If I understand things correctly. This post does not address all details and it may contain misunderstandings or assumptions, but it's a start. Also relevant: * Is there a compiled and maintained list of recommended or deprecated resources for mappers to use? * https://forums.thedarkmod.com/index.php?/topic/20311-external-art-assets-licensing/

I am less familiar with the MLA Handbook, so I don't know what (if anything) it says about how to account for definite and indefinite articles when sorting lists based on titles. I can't find anything about it online. Let's hope they don't come after us if they find out and disagree. Edit: According to the link I provided in my previous post, "MLA style follows the The Chicago Manual of Style", so there is no conflict between them.

See this post: I wonder if it could be modified so that the set_frobable could be done when box is at a quarter of open animation. I think that this has to do with frob-distance and/or if the container where the item is in also has frob-higlight. It think that when the box is opened, frob-highlight for the box-body should be enabled. So the best would be probably: If box is closed, whole box should have frob-highlight enabled. When box is open, only lid should have frob-highlight enabled. This should be applied to all core prefabs. I also have this sometimes with messages sticking to doors, where it is very difficult to frob the message or door.

See also this post from @jonri about the original command I used for screenshots and look at the amount of wait's: bind "KP_SLASH" "con_noprint 0;wait;wait;wait;getviewpos;wait;wait;wait;screenshot;con_noprint 1"

Thanks! I added your names to my post. Okay, I'll post there next time. Feel free to move or merge this post if it belongs better somewhere else.

Actually my name and @JackFarmershould be also under aditional mapping. Normally one would post in the topic of the fm and then hope that someone (the author) comes along to fix it. But this is one of the main 2 missions in tdm.

Very informative post, @Fiver. Few months have passed and it probably is time to ask this again

TDM has tons of textures from "free" texture resources that do not allow redistribution and cannot be incorporated into a commercial project. Someone would need to create a huge replacement pack of textures that do not break the look of existing missions and do not infringe on the copyrighted textures. Also, many artists who contributed to this project do not want 3rd party entities to use their work in commercial projects. They intended the models, textures, sounds, animations to be exclusively used for Darkmod content. You would either have to replace ALL assets or contact every contributor and ask them to re-license their assets. Many contributors are no longer active with the project and haven't visited the forums in years so it would be no easy feat. I cannot speak to Debian policy but I think that they treat installers that add non-free content the same as non-free content itself. One could argue that Steam is such an installer but I guess Debian would counter that there are a few fully Libre games on Steam. I think Debian, Ubuntu, or Linux Mint need to consider a repo that allows for games (etc) that include non-libre content but intentionally offer this content for free to the community with no stipulations other than "don't try to sell it as a product".

This post differentiates between "gratis" ("at no monetary cost") and "libre" ("with little or no restriction") per https://en.wikipedia.org/wiki/Gratis_versus_libre * A libre version of TDM could: ** Qualify TDM for an article on the LibreGameWiki *** TDM is currently listed as rejected https://libregamewiki.org/Libregamewiki:Rejected_games_list because "Media is non-commercial (under CC-BY-NC-SA 3.0). The engine is free though (modified Doom 3) (2013-10-19)" ** Qualify for software repositories like Debian *** TDM is currently listed as unsuitable https://wiki.debian.org/Games/Unsuitable#The_Dark_Mod because 1) "The gamedata is very large (2.3 GB)", and 2) "The license of the gamedata (otherwise it must go into non-free with the engine into contrib)" and links to https://svn.thedarkmod.com/publicsvn/darkmod_src/trunk/LICENSE.txt Questions: 1) tdm_installer.linux64 is 4.2 MB (unzipped), which is far from the 2.3 GB which is said to be too large. Yes, the user can use it to download data that is non-libre, but so can any web browser too. If the installer itself is completely libre, does anyone know the reason why it cannot be accepted into the Debian repository? 2) If adding the installer to the repository is not a viable solution, would it be possible to package the engine with a small and beginner friendly mission built only from libre media/gamedata into a "TDM-libre" release, and add user friendly functionality to download the 2.3 GB media/gamedata using "TDM-libre" (similar to mission downloading)? 3) Would such a "TDM-libre" release be acceptable for the Debian repository? 4) Would such a "TDM-libre" release be acceptable for LibreGameWiki? 5) Would the work be worth it? * Pros: Exposure in channels covering libre software (e.g. the LibreGameWiki). Distribution in channels allowing only libre software (e.g. the Debian repository). * Cons: The work required for the modifictions and release of "TDM-libre". Possible maintenance of "TDM-libre". I'm thinking that the wider reach may attract more volunteers to work on TDM, which may eventually make up for this work and hopefully be net positive. 6) Are there any TDM missions that are libre already today? If not, would anyone be willing to work on one to fulfill this? I'll contribute in any way I can. 7) I found the following related topics on the forum: * https://forums.thedarkmod.com/index.php?/topic/16226-graphical-installers-for-tdm/ (installing only the updater) * https://forums.thedarkmod.com/index.php?/topic/16640-problems-i-had-with-tdm-installation-on-linux-w-solutions/ (problems with installation on Linux) * https://forums.thedarkmod.com/index.php?/topic/17743-building-tdm-on-debian-8-steamos-tdm-203/ (Building TDM on Debian 8 / SteamOS) * https://forums.thedarkmod.com/index.php?/topic/18592-debian-packaging/ (Dark Radiant) ... but if there are other related previous discussions, I'd appreciate any links to them. Any thoughts or comments?

The gamepad implementation allows for a great degree of flexibility to personalize settings, aside from a few minor issues that I mentioned here: https://forums.thedarkmod.com/index.php?/topic/22337-gamepad-bindings/ I would say that playing TDM with a gamepad works very well, especially considering that it was implemented as experimental and hasn't been changed since then. If I could, I'd go back to 2021-you and congratulate you on buying that gamepad. I notice that your DarkmodPadbinds.cfg looks very different from mine...

It seems like more and more "thief" and "thief players" is becoming a short hand to dismiss community members earnest desire to improve the game - which happens to be a barely legally distinct "thief style" game which was made by thief fans for thief fans and is "designed to simulate the stealth gameplay of Thief". Who is the predominant player base of the game supposed to be beyond fans of the thief games? Is there some better avenue to find feedback for the game beyond this forum? FOSS and linux forums? I have seen maybe half a dozen posts from that segment. I am a thief fan, I play thief fms, my association with those games is what drives me to play and make things for this game. Are we supposed to pretend the original games are not a huge reason why most of us are here at all? TL;DR version:

Snatcher and myself argued for ages to make shouldering long frob, but as this was completely blocked and the issue for me at least is consistency, I now would like to have the other special actions fit to the shouldering scheme. As you said, from the new perspective of a new default, short frob should extinguish any lights and eat any food. - Bodies: short > shoulder, long > move - Lights: short > extinugish, long > move - Consumables: short > eat, long > move - Loot and items: short > take, long > multi take (this was always different to the others) This leaves all other physical items for which short frob means moving, which could also be helpful in the sense that if you short frob something and it is moved, it has no special action.

No, I remembered the old system, but I also was using my patch so I suspected at first I messed something up before I remembered that the handling of bodies and lights are so counter intuitive right now. I could easily add my own patch solution to make extinguishing lights short frob again, but I would rather see a consistent version of it in the core game! To provide some background information, I had just finished both the Cyberpunk DLC and The Outer Worlds DLCs, both of which use short-use and long-use systems too so my mindset somehow was expecting something more consistent ;).

It is already implemented. This is exactly what my extension of the new control scheme does. tdm_holdfrob_drag_all_entities Have fun, mate! EDIT: Correction: Sorry, I misread your post a little bit. Only for extinguished lights and food remains, the hold-type-grabber is used with my extension. For lit candles and food, short frob is still grabber and long frob is extinguish / eat. The thing is that there are plans to keep only one control scheme on the long run, which I am totally against, 'though, see below. I have already commented/suggested internally that the frob-code needs refactoring anyway, and if we were to do that for 2.13, we might as well introduce a simple switch. Basically, the code would determine if short frob or long frob has been pressed and then decide which action to perform based on the chosen control scheme. And for your information, my preferred solution has always been to keep the original controls, but have long-frob as a shortcut for frob + use. This might be an option with the proposed refactor. Let's try to keep the discussion constructive, please. There is no need to make it more heated.

The new system is great and, in my opinion, does not need changing. But just for the sake of this discussion: what if the default action for bodies (drag or shoulder) could be chosen with an option? A simple checkmark that switches these around (either short frob = drag and long frob = shoulder or the other way around)? Both variants would be ok with me.

So the old system is still present in 2.12? Then I truly fail to see the issue some others perceive Can't agree with you there. The implementation would be very counter-intuitive as it would clash with picking up swords/crates/etc with a single short click. If short frob becomes the new special action and we assume some new players won't know about long frob, then they also won't know they can move objects around. I can think of several missions where moving crates or magic orbs or lamps is vital to progression. Hell, picking up loot is done with short frob while long frob automatically picks up everything without the need to keep clicking. Long frob already is special action, changing it would create an inconsistent mess. If the argument is that shouldering should be long frob after picking the body with short frob, then perhaps you want to look at shouldering from a new perspective; shouldering is the new default, it is the most common thing a taffer will do with a body, while ragdoll manipulation is the new special action for specific situations.

I just played the new beta mission and wondered why I couldn't extinguish moveable lights as I had already forgotten that I need to use hold-frob in 2.12. This is completely counterintuitive to shouldering bodies and there is no global information about this, so please make it so that hold-frobing takes a moveable light and short frobing extinguishes it! This would also be more consistent to the static lights. The same should be done for consumables too: short frob eat, long frob pick up...

There's a bug I've been noticing for a long time, but for some reason it didn't click with me to mention it till someone else just mentioned seeing the same thing and I realized I'm not the only one. The contents of some chests and small containers like drawers will sometimes not become frobable when you open that container: You may need to close the door and open it again, after which you can frob any scrolls / keys / etc inside. Most likely something is happening with target_setfrobable getting triggered at the wrong time. Even when they are frobable, tiny items in small containers will sometimes only highlight from a very specific position and angle: I've had cases where I needed to lean forward and look at a coin just right and it would only highlight when my crosshair was on that one pixel. I'm sorry I didn't think to note down a FM and viewpos where to test it; If you need I'll keep that mind for when I play the next one. This doesn't happen a lot any might be hard to catch, but often enough as to be noticeable... in most recent FM's it seems to occur at least once in some drawer or lockbox.

Thanks! 1) Doing LONG_PRESS PAD_A (what I, for lack of knowledge, call "jump-mantle" or "_jumpmantle") differs from doing PRESS PAD_A ("_jump"). "_jumpmantle" differs from "_mantle", so they must be mapped to different button-calls. "_jumpmantle" differs from "_jump", so they must also be mapped to different button-calls. This appears to be the case, but it is not evident (or changeable) in DarkmodPadbinds.cfg. "_jumpmantle" seems to be hard coded to always connect to the same button as "_jump" but with a long press. It is as if bindPadButton PRESS PAD_A "_jump" is not actually just binding PRESS PAD_A to "_jump", but rather interpreted as "link PAD_A (regardless of button press time) to behave exactly like keyboard SPACE for short and long presses". I would have expected the default DarkmodPadbinds.cfg to explicitly read: bindPadButton PRESS PAD_A "_jump" bindPadButton LONG_PRESS PAD_A "_jumpmantle" bindPadButton PRESS PAD_B "_crouch" bindPadButton LONG_PRESS PAD_B "_mantle" ... but neither LONG_PRESS PAD_A or "_jumpmantle" is listed in the file. If there are actions "_jump" and "_mantle", I suppose there must also be an action "_jumpmantle" since it is possible for the player to do all those movements: * "_mantle" does the movements "crouch on the high surface, then stand up" * "_jumpmantle" idoes the movements "jump slightly forward, then land standing on the high surface" * "_jump" idoes the movements "jump up, then land exactly where you started" If the actions "_jump" and "_moveup" are not synonymous, then perhaps the action "_moveup" is what i call "_jumpmantle"? 2) Thanks for the link! It was useful in more than one way. I'll link to that page from https://wiki.thedarkmod.com/index.php?title=Bindings_and_User_Settings#Gamepad_Default_Bindings if I can get an account on the wiki, which proved more difficult than i thought (https://forums.thedarkmod.com/index.php?/topic/22327-how-can-i-create-an-account-on-the-tdm-wiki/). However, it does not answer my question how to find out the name ("<button>") used for a button on my gamepad. Basically, I would need to press the button on my gamepad and some program could tell me "That button is called 'PAD_A'". In my case, I have a gamepad "Logitech F310" (https://commons.wikimedia.org/wiki/File:Logitech_F310_Gamepad.jpg) which has a "Logitech button" (see image) that I want to use. I was hoping to find out the "button name" for that button and then edit DarkmodPadbinds.cfg to map it to a function. 3) ... but if that button has an "unusual name" that TDM does not recognize, then it may perhaps not work. E.g. if that button is called "PAD_LOGITECH" and TDM cannot recognize that name, then I cannot map anything to it via DarkmodPadbinds.cfg. Using QJoyPad I can map any keyboard key to it instead, as a workaround, but I cannot map MODIFIER to it (since MODIFIER cannot be set to a keyboard key). If current implementation is still called "experimental", then I must say it works very well; @cabalistic: kudos for that! I may not have continued playing TDM had it not worked with a gamepad.

You can walk through every entity and spawnarg in the set up piece by piece and see if there's a logical problem buried in there. I don't recall how the fade-in works for the initial ambient anymore. It's been too long. But you can experiment to see if it's really borked. But what I came to say is that note there's a Sound Override setting where you can just set up an ambient transition yourself by some trigger if the location transitions aren't working properly for some reason. One thing you might try, if the initial ambient always borks the fade in no matter what you do, is to set a dummy initial sound by immediately triggering the Sound Override as soon as the map starts, like just a quarter second of silence, and then turn the Sound Override off a half second later to have the system immediately transition back into the initial location ambient, and then the fade in should work properly. It's a bit of a hack, but it could fix your problem. You might be able to think of other ways to deal with it along those kinds of lines.

It is possible that this is a setting that needs to be activated to work: https://mantisbt.org/forums/viewtopic.php?t=23221