Search the Community

Is "assets" synonymous to "media/gamedata"? And are you referring to the 2.3 GB media/gamedata included in TDM at install? If all 2.3 GB media/gamedata were removed from the "TDB-libre" version, then no license change would be needed. Say then we have a small fan mission that is entirely libre, built entirely from libre assets and created to intentionally avoid using any of the current 2.3 GB media/gamedata. If we wanted to play that mission using only the source code, what media/gamedata components would be missing to do that? * GUI graphics and music? * HUD elements? * Any in-game sounds? * Inventory objects? * ... anything else that can neither be included in the mission's own media/gamedata, nor avoided during mission design? I'm assuming here that a mission actually can include its own media/gamedata (textures, sound, models), but I may be wrong and I'm grateful for any explanation that helps me understand. If you ask me, the TDM-installer works perfectly already today, and the instructions are brief and easy to follow. Installation from the Debian repository would be somewhat easier, but I also see other (perhaps greater) benefits which I mentioned earlier.

This is actually a rather old request that we encountered often shortly after going standalone in 2013. Hardcore GNU\Linux folks, especially those who use Debian, think that all open projects should use GPL v3 licenses with full "Libre" licensed content ( Creative Commons ). The goal is that open projects should be a shared resource that no single person or group regulates and can be used for ANY purpose without fear of prosecution or litigation. The primary motivation is "extreme paranoia". Any license restriction is seen as a potential trap that could unintentionally jeopardize contributors or users. For example: Imagine that I create a blog where I review darkmod missions and earn advertising revenue by visits. Through a very convoluted legal premise, the owner of non-free assets used in TDM could claim I owe them revenue since their license doesn't allow "any" commercial exploit of their work. Likewise, the owner of an internet cafe where the game is played might owe the asset owner their revenue. The ISP that made the asset available to it's subscribers might owe them too. The overarching theme is that copyright scope is not clearly defined and can be perverted to sabotage open projects. A fully Libre compliant project is immune to these risks. People who want their favorite projects to be easily available in GNU\Debian evangelize this type of license change. The problem is that most TDM contributors would strongly object to allowing their work to be used by 3rd party commercial projects, especially if those 3rd parties simply rebranded darkmod and sold it as a game in an app store. Even if that were a palatable eventuality, it would also make Embracer Group ( current owners of Thief IP ) more inclined to attempt a legal take-down of our project. A Libre version would need to be a fork that is maintained outside our community so that we can still clearly state that we prohibit all commercial usage. Debian and other similar distros need an easy way to allow users to install projects that are strictly non-commercial rather than forcing all open projects to permit 3rd parties to resell their work.

TDM should contain 2 storages, one that is gpl (the engine) and one with another or more than one license (content), maybe that's already the case? Via the installer you should be able to only install the gpl content? I don't know if that's possible. Everything pure code is gpl, or not? I mean everything outside of media files (images, video's, sound files, etc.). (edit: maybe also models?)

Beta 11 Fix finished-on state auto-update was unreliable Slighty improve scanner title/author detect Tags are now named some whatever regular-version-looking thing to force GitHub to put the newest at the top

I don't think there is any purpose. Windows and Linux have entirely different window/OS integration. They are separate subdirectories with completely different code So there is no wonder that such things are different between Windows and Linux. I think @duzenko spent some time improving the behavior of Windows build. On the other hand, @cabalistic switched Linux build to GLFW. I am afraid of touching this myself because 1) I'm not a Linux user and don't know much about the myriad of desktops and APIs to integrate with them, and 2) I don't want to install Linux natively and this cursor stuff is a bit special inside VM. Maybe it is a simple flag which can be set to GLFW, I don't know.

Hi, Ive been taffing away for years but have taken a forced hiatus, due to some over zealous hammers, but am now back. Anyway Im having some issues installing The Dark Mod and last night tryied twice but both times failed with missing 'chunks' ? or some error similair. Toaday it seems to be going along ok , 27 mins left but i notice on task manager that it keeps hanging ! Not Responding !!! but a few seconds pass and its flicks to Responding again, but this is occuring every 10 secs or so... what gives ?

Here's the draft code patch so that folks who compile TDM themselves can give this proposal a try in game. And, if you do, I look forward to your feedback! https://gist.github.com/daftmugi/41d0324107e8734f364bb3e50ff00794 Install TDM v2.12 (dev16829-10455) Get the SVN repo Download "r10455-add-frobhold.diff" Apply SVN patch: "svn patch r10455-add-frobhold.diff" Compile Copy TheDarkMod.exe and glprogs to TDM (dev16829-10455) directory Or, @Wellingtoncrab has provided a Windows build. (includes new frob and new lean) Install TDM v2.12 (dev16829-10455). Download @Wellingtoncrab Windows build: https://drive.google.com/file/d/13lQig7Yzfc_jovU2zZklxLV1QOKAjkXe/view?usp=sharing Copy the TheDarkModx64.exe binary to your dev16829-10455 directory. Or, @Daft Mugi has provided a Ubuntu/Linux build. (includes new frob and new lean) Install TDM v2.12 (dev16829-10455). Download @Daft Mugi Ubuntu/Linux build: https://drive.google.com/file/d/1j7DoWBKuBAFdVH2Y-2LcYsgdtJNBabmn/view?usp=sharing Copy the thedarkmod.x64 binary to your dev16829-10455 directory.

Yeah, I always found this ambiguous, the same as "uninstall mission", which could imply it will be removed from your computer. This is why I changed all similar appearances in my patch from "install/installed" to "activate/activated". I believe this is better than "selected" because you first need to select a mission in the list to be "activated" or "deactivated".

If the "mission fails as soon as stealth score turns non-zero," that would not be good for ghost players. They might need to find out "how" they failed and experiment to avoid alerting guards. They might need to take those score points as a "bust". They might need to take those score points to complete an objective. Then, mission authors would need to encode exceptions into their missions, which would be a lot of work (if they decide to do it at all). However, part of what makes ghosting challenging and fun is when mission authors do not create their missions with ghosting in mind. Please see: Official Ghosting Rules: https://www.ttlg.com/forums/showthread.php?t=148523 Writing code for these rules would be a huge undertaking. Ghost Rules Discussion: https://www.ttlg.com/forums/showthread.php?t=148487 Creating an official mode could alienate these dedicated ghost players, because it would clash with what is considered ghosting in the community. Including the Stealth Stat Tool mod in the official release would be more useful. Or, making the audible alert states of guards quick and easy to recognize could help as well. For these reasons, I don't agree with an official "Ghost" mode. If the dev team were to do it, we should consult with @Klatremus so we get it 100% correct or not pursue it at all. (This ghosting bit should probably be in its own thread.)

With TDM 2.12, after the credits finished, the "Mission Complete" screen did not display. I found that the screen was black and I could hear my footsteps when I tried to move around. I think the reason for the mission not completing successfully was that the "Do not kill or harm allies" objective was never marked as "1 = STATE_COMPLETE" instead it was left as "0 = STATE_INCOMPLETE". Note, I didn't use noclip throughout the mission. Same as: https://forums.thedarkmod.com/index.php?/topic/18054-fan-mission-the-accountant-2-new-in-town-by-goldwell-20160509/&do=findComment&comment=458491

How about using TDM automation framework (and maybe pcem/qemu)? More info see: https://forums.thedarkmod.com/index.php?/topic/19828-automation-features-and-discussion/

Beta 13 More robust TDM file reading attempts: we now try until we can access them or until a 5 second timeout If a TDM file is not found at all, we now continue immediately and don't wait the 5 seconds Rework auto-refresh system to be simpler and more robust: Refreshes run completely on the UI thread now Refreshes happen immediately or not at all; no more deferred refreshes Refreshes are not allowed when the main window is blocked or disabled (mostly if a progress box is up) If a dialog window is open (Settings, About, etc.) then a "lightweight" refresh (UI update only) is allowed, but a "heavyweight" refresh (FM list reload, possible scan and/or readme cache update) is not. Remove installed status from unavailable TDM FMs (those not found on disk) Gracefully handle scenarios where some or all watched TDM files or directories may not exist (clean install, partially broken install etc.) Ignore empty or invalid FM dirs (dirs with no pk4 files in them; TDM clean installs may add an empty "saintlucia" folder for example)

Phew, it's almost exactly been 3 years since my first post about my VR modification for TDM. Three more versions of the game have been released in the meantime, and with them come performance improvements that I feel it's finally viable to continue my work on the VR adaptation So without further ado, head on over to https://github.com/fholger/thedarkmodvr and grab the latest release. It's based on the future 2.09 version, but is fully compatible with a 2.08 install. Although I've tried to make the VR version use its own set of resources (separate `darkmod_vr.cfg` and shader folders), I'd recommend you make a backup or copy of your TDM installation to be able to get back to the flat version cleanly without effort. Please heed the README in the repository, particularly about the choices of VR backends. Some noteworthy information for this new version: performance should be considerably improved from the old alphas. That doesn't mean it's perfect - although the CPU bottleneck is now completely gone, the game is now severely fill-rate limited. So if you have a current-gen headset with high resolution and/or a weaker video card, forget about any supersampling or AA. I also strongly recommend to stick to stencil shadows and disable soft shadows and ambient occlusion - the latter isn't that impressive in VR, anyway, and simply not worth the GPU cost. And even then, there will be some scenes in some missions where reprojection is just unavoidable, even with the beefiest GPU. That being said, I have tried a multitude of maps, and I think it's very playable. the UI is finally usable! Both the menu and ingame HUD elements are projected to a virtual screen in front of your sitting position. It's not the most elegant or immersive solution for the HUD, but it works vertical mouse movement is excluded from the VR view - this was suggested by some of you way back, and I think it makes the experience much more enjoyable. It can make it a little hard, though, to aim with the mouse for actions like frobbing items, because there's currently no visual indication to where the mouse is pointing. I'm planning to add one asap, but in the meantime, you can equip a weapon to get a vague sense of your mouse orientation. If you do want to re-enable vertical movement in the view, set 'vr_lockMousePitch' to 0 in the console. Other than that, I hope you enjoy this new version. Let me know which improvements you'd like me to work on first. Also, there are probably any number of render and other bugs still left in there somewhere. If you find one, please report them over at the Github tracker (https://github.com/fholger/thedarkmodvr/issues), so I can keep track of them. Latest Update:

As I don't know what else to do to help debug this, I went through the process of verifying if the issue can be reproduced in a VM. Took me over an hour due to some problems on my end, in the end I managed to confirm that it can! I've laid out the exact steps needed for anyone (including Windows users) to reproduce this: Install VirtualBox, get the Manjaro KDE / Plasma iso from https://manjaro.org/download In VBox create a new VM of Type: Linux, Version: Other Linux (64-bit). Under its Settings - Storage add the iso as optical drive with the option "Live CD/DVD", also add a virtual hard drive to install to. Booting up the VM should start a live Manjaro session. It will provide a prompt to start the installer; Do so using the default settings, choose any username and password but don't enable automatic login. Restart once it's finished and boot from the virtual drive instead of the iso (F12), the VM should now load into the installation. The SDDM login manager should present you with the login screen after booting. Before typing your password look in the bottom-left corner: You have options for Plasma X11 and Plasma Wayland, click it and select the later. After changing the session type use the password you chose in the installer and log in. Open a console (Konsole). Clone DarkRadiant with "git clone https://github.com/codereader/DarkRadiant.git". After that follow the instructions at https://wiki.thedarkmod.com/index.php?title=DarkRadiant_-_Compiling_in_Linux to install Manjaro dependencies with the "pacman" command followed by "cmake .;make --jobs=4;sudo make install". This takes a while so remember to give your VM a few CPU cores then use them in the jobs argument. Open up the DarkRadiant binary, you should find it in /usr/local/bin. Skip past any questions and warnings regarding the DarkMod data, you don't need TDM for this test, note that may crash it at first. As DR shows up right-click in the 2D or 3D view to take control: You should be seeing my issue as the views go all over the place. I'm sorry for the messy setup again... can understand if the team doesn't have time to bother with it, but still hope you can find a moment to try it out. The good news is once this setup is in place, you should be able to push changes to the VM and recompile (only part of the code changes) to test the result immediately. I'm happily ready to run any tests myself and confirm any solution found! Let me know if I can help with any more information.

I dom't use it, i found it here with the filter set to OpenSource. the TOS and PP isn't excluding for an OpenSource app, if they use ads mean that they also need to pay an server for this online service. OpenSource is not synonymous with free either, perhaps after the beta phase it is no longer free, so perhaps you can take advantage of the fact that it is still free to create a series of textures that can be used or search another one in Futuretools. AI generated textures and assets, by definition, don't have any copyright, so you can use them as you want. https://www.futuretools.io/?pricing-model=free|open-source&tags-n5zn=gaming

To cater to both audiences. I mentioned LibreGameWiki as one example. nbohr1more mentioned other uses. Explicitly allowing reuse and spread will help TDM reach a wider audience and would hopefully attract more volunteers. More volunteers which can help improve both TDM versions. There are several benefits for a project of being in the Debian repo. One is that TDM Debian-users can report defects on any package directly to Debian (no need to register on separate forums). Debian may then fix the issue themselves (in their "TDM-libre" package) and will offer the patch upstream to TDM, who can then choose to accept or reject the patch. I envision "TDM-libre" to have the same capability of downloading any mission as regular TDM. The only difference is that "TDM-libre" would come packaged with the regular engine (which is GPL+BSD) and an included mission that has libre media/gamedata. When I play TDM by myself, I want the unlimited-play and can accept commercial restrictions. But if I were to promote it somewhere, or charge for a stream when playing online, or make a video, I would want a version without commercial restrictions (and can temporarily accept limited-play) to make sure I don't violate anyone's copyright. Perhaps. That's what I'm trying to find out.

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.

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".

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:

I got tdm_installer.exe but when I run it, it eventually stalls on some pk4. file. I try and try again and it stalls and stalls again. Can anyone assist? Thanks Ed

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.

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