Search the Community

Yes, I would like to find out what the issue is even if the ultimate decision is to use a different library in future. So far I have established that this line in Game.cpp is apparently working (no exception is thrown): // Import the game file into the registry GlobalRegistry().import(fullPath, "", Registry::treeStandard); but this (and any subsequent attempt to getKeyValue) then fails: // Get the engine path _enginePath = getKeyValue(enginePath); I can only think of two hypotheses: It's a timing issue or race condition: the import call is returning but something in libxml2 has not "finalised" the tree so it isn't ready to do XPath queries yet. I don't think there is any asynchronous or threaded code in the libxml2 API but who knows. There's something different about how XPath queries need to be formatted after merging. E.g. perhaps "//game" no longer works, and it has to have some other prefix. Further debugging is therefore needed. Edit: OK, there's definitely something weird going on with encodings. Adding a Registry::dump call into the Game constructor gives me output like this: output error : string is not in UTF-8 output error : string is not in UTF-8 eCrosshairs" ="mU" ���mU="SHIFT"/>< ="ToggleGrid" ="(&#xB3;R"/>< ="ToggleView" ="U" ���mU="SHIFT+CONTROL"/>< ="NextView" ="" ���mU="CONTROL"/>< ="ZoomIn" ="Delete"/>< ="ZoomOut" ="Insert"/>< ="CenterXYViews" ="" ���mU="CONTROL+SHIFT"/>< ="CenterXYView" ="" ���mU="CONTROL+ALT"/>< ="ToggleCubicClip" ="" ���mU="SHIFT"/>< ="ToggleCamera" ="U" ���mU="SHIFT+CONTROL"/>< ="TogTexLock" ="" ���mU="SHIFT"/>< ="DragVertices" ="U"/>< ="DragEdges" =""/>< ="DragFaces" =""/>< ="ToggleSelectionFocus" ="" ���mU="CONTROL"/>< ="ThickenPatchDialog" ="" ���mU="CONTROL"/>< ="ToggleShowAllLightRadii" ="" ���mU="CONTROL+SHIFT+ALT"/>< ="ToggleClipper" ="mU"/>< ="MouseTranslate" =""/>< ="MouseRotate" =""/>< ="MouseDrag" =""/>< ="NewOrthoView" ="" ���mU="CONTROL+ALT"/>< ="SetGrid0.125" ="" ���mU=""/>< ="SetGrid0.25" ="" ���mU=""/>< ="SetGrid0.5" ="" ���mU=""/>< ="SetGrid1" ="" ���mU=""/>< ="SetGrid2" ="U" ���mU=""/>< ="SetGrid4" ="" ���mU=""/>< ="SetGrid8" ="" ���mU=""/>< ="SetGrid16" ="" ���mU=""/>< ="SetGrid32" ="" ���mU=""/>< ="SetGrid64" ="" ���mU=""/>< ="SetGrid128" ="" ���mU=""/>< ="SetGrid256" ="" ���mU=""/>< ="ToggleTextureTool" ="" ���mU="CONTROL+ALT"/>< ="ToggleMainControl_TextureTool" ="" ���mU="CONTROL+ALT+SHIFT"/>< ="NormaliseTexture" ="" ���mU=""/>< ="TexToolGridUp" ="plus" ���mU="SHIFT"/>< ="TexToolGridDown" ="minus" ���mU="SHIFT"/>< ="TexToolMergeItems" ="" ���mU="Y&#x11D;mU"/>< ="GroupCycleBackward" ="ISO_Left_Tab" ���mU="SHIFT"/>< ="GroupCycleForward" ="" ���mU=""/>< ="RevertToWorldspawn" ="" ���mU="SHIFT"/>< ="SavePosition1" ="" ���mU="CONTROL+ALT"/>< ="SavePosition10" ="(&#xB3;R" ���mU="CONTROL+ALT"/>< ="SavePosition2" ="U" ���mU="CONTROL+ALT"/>< ="SavePosition3" ="" ���mU="CONTROL+ALT"/>< ="SavePosition4" ="" ���mU="CONTROL+ALT"/>< ="SavePosition5" ="" ���mU="CONTROL+ALT"/>< ="SavePosition6" ="" ���mU="CONTROL+ALT"/>< ="SavePosition7" ="" ���mU="CONTROL+ALT"/>< ="SavePosition8" ="" ���mU="CONTROL+ALT"/>< ="SavePosition9" ="" ���mU="CONTROL+ALT"/>< ="LoadPosition1" ="" ���mU="Y&#x11D;mU"/>< ="LoadPosition10" ="(&#xB3;R" ���mU="Y&#x11D;mU"/>< ="LoadPosition2" ="U" ���mU="Y&#x11D;mU"/>< ="LoadPosition3" ="" ���mU="Y&#x11D;mU"/>< ="LoadPosition4" ="" ���mU="Y&#x11D;mU"/>< ="LoadPosition5" ="" ���mU="Y&#x11D;mU"/>< ="LoadPosition6" ="" ���mU="Y&#x11D;mU"/>< ="LoadPosition7" ="" ���mU="Y&#x11D;mU"/>< ="LoadPosition8" ="" ���mU="Y&#x11D;mU"/>< ="LoadPosition9" ="" ���mU="Y&#x11D;mU"/>< ="ToggleOrthoBackgroundPanel" ="U" ���mU="Y&#x11D;mU"/>< ="ToggleRotationPivot" ="" ���mU="CONTROL"/>< ="ToggleAasVisualisationPanel" ="" ���mU="CONTROL+SHIFT"/>< ="GroupSelected" ="" ���mU="CONTROL+SHIFT"/>< ="UngroupSelected" ="" ���mU="CONTROL+SHIFT"/></mU><> Whereas with xmlParseFile there are no weird characters and the output just looks like properly formatted XML. I wonder if we have some nonstandard characters in our XML files for some reason.

I compiled DR with no extra options on Ubuntu 23.10, and installed it, all without any error, but when I try to launch DR it comes out with "no game type selected" and after ok, the code Aborts due to a memory overflow, I opened a bug in: https://bugs.thedarkmod.com/view.php?id=6472 where I supplied the log, any idea of what might be going wrong?

Of course, it is one of the reasons for the decline of online forums, since the advent of mobile phones. Forums on a mobile are a pain in the ass, but on the other hand, for certain things there are no real alternatives to forums, social networks cannot be with their sequential threads, where it is almost impossible to retrieve answers to a question that is asked. has done days ago. For devs for internal communication, the only thing offered is a collaborative app, such as System D (not to be confused with systemd). FOSS, free and anonymous registration, access further members only by invitation, full encrypted and private. https://www.system-d.org

Related to looking into the stray marks associated with Stone font characters... I've noticed that the nominal 12 pt DDS (which as discussed above only kicks in under 8 pt) has only ASCII glyphs... nothing with code points above 127. Maybe that's why the corresponding 12 pt DAT file was not distributed, as a workaround to force the engine to use 24pt instead, because tels never got around to finishing the low-priority aspects of the project. The 24 pt DDS does have the ANSI glyphs. At a glance, most are fine; a few are a bit ragged. I didn't check compliance and completeness with TDM's character map as given on the wiki. I don't feel ANSI improvement is a 2.12 item. I've got a test FM to show all the characters. At some point, after refinement, I'll post a link.

So, if I understand you, no Thief Gold FM does sound and text notifications of completed objectives? The missions in The Black Parade surely did. I'm completely confused now. I was sure that original Thief Gold had those objective complete notifications (at least the sound). Reading this thread suggests otherwise though: https://www.ttlg.com/forums/showthread.php?t=132977

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?

There also such thing as "code inertia". You are discussing something as simple as "controls" or "bindinds". But in reality it is the whole logic of frobbing, grabbing, dragging, light extinguishing, light handles, scripts and spawnargs --- all tied in a single knot. The code existed long time in a way that you can shoulder a body only after you grab it, and you can extinguish a candle only after you grab it. As far as I understand, @Daft Mugi did not refactor everything so that this idea no longer exists --- that would be too hard right now and probably break too much. Under the hood, there old logic somewhat remains in addition to the new one. Such things often bite back with bugs, corner cases. Also it makes it even harder to further change things in frobbing. Of course, one could say that the new code has been extensively play-tested, but then we'll find yet another mission where something is used in unexpected way and we need to change something again. Indeed, happy people will just add more if-s and condition-s, but often it just shifts the problem into a different case. So you know, if there are several plausible solutions, I would definitely lean to a more conservative one, which better complements the old one.

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.

Thank you. I have more questions but I would be wasting your time. I will have a look at the source code someday.

Greetings everyone! I recently got into TDM and am already having a lot of fun playing through and ghosting missions. However, coming from Thief, I am mostly relying on the rules and my experience with that game, while there are clearly differences in how TDM works. Right now, there is talk in the ghosting discussion thread on TTLG to amend the ruleset and include clarifications pertaining to TDM. So I wanted to drop by and ask: is there an active TDM ghosting community already and have any rules for this playstyle been developed? I would also like to ask someone to take a look at the draft of this addendum to see whether everything looks correct: https://www.ttlg.com/forums/showthread.php?t=148487&page=16&p=2473352&viewfull=1#post2473352 Thanks!

As I understand the TDM license there are roughly three types of contributions to the TMD project as a whole: 1) Contributions to the source code of TDM: These are licensed GPL or BSD and can therefore be used already today by commercial projects. 2) Contributions to the 2.3 GB media/gamedata included in TDM at install: These are licensed CC-BY-NC-SA and restricts commercial use. 3) Contributions of fan missions that can be played using TDM and are added by the end-user after the install (either by the ingame downloader, website, or other source): These are not part of the core product and the license says "Any missions [...] are the property of their respective authors, and different licensing may apply.". This means the FM creators can choose any license they want, anything between CC-0/PD and strict copyright. Possibly even put additional restrictions on its use (e.g. say "You may only download and play this on regular TDM"), right? It is up to the end-user to abide by the stipulated license. The included missions "Training Misson", "A New Job", and "Tears of St Lucia" appears to fall into category (2) according to "Unless explicitly stated otherwise, all [...] non-software components that are distributed with The Dark Mod are licensed under [CC-BY-NC-SA]". Does anyone know if their license says anything else?

Personally I can see some ancillary benefits from trying to move TDM from non-commercial-libre to true-libre, beyond getting off the FOSS community's naughty list. There are a fair few indie devs who have tried to make modernized Thief-likes. None of them have done half as good a job as this community. I think that is generally down to the engine. All the detection and movement systems take a lot of time to implement, which you guys have already paid down. Imagine if those indie devs had the option to use TDM as the base for their games. More of these games would be published, and more would be successful. And this in turn would grow the public knowledge base about working in Dark Radiant and TDM. Some of those devs might make their own public FMs. Some might contribute to the wiki and documentation. Some might contribute to project maintenance or even donate new features that they develop. Personally I would call this one of the bigger things that you could do to keep the project alive. It would definitely be a big project to bring the project assets into compliance or to fork off a compliant TDM-lite. A year ago I would have said it is impossible, but AI is changing things. It can make art and it can write code, and especially when it has a working example of the thing it is recreating to learn from. It still would not be easy, but at least possible. Let this be a lesson for creators to select your licensing carefully. It is not always easy to change after the fact.

As much as I'm a big fan of FOSS, it gets messy when it involves assets with a whole mix of licenses. The engine? Sure that'll work, but TDM is useless with just the engine. Even if you have a separate libre version with verified assets, you've now split the project into a full version and a libre-only version and for what? Some entry in a niche wiki and the Debian repo? Once people want actual full missions to play you begin to drift away from the restricted licenses imposed on the libre version and have to code and accommodate for that. If TDM was developed with the day-one intention of only allowed libre licensed assets then there'd be no problem, but it hasn't and what your asking is probably too much work and effort for little benefit.

A Problem Arises I've paused subtitling of the Lady02 vocal set, because of a problem with the voice clips described here: https://forums.thedarkmod.com/index.php?/topic/21741-subtitles-possibilities-beyond-211/&do=findComment&comment=490151 While a way forward is being determined, I'll work on a different vocal set. Maybe manbeast, for which Kingsal just provided me the voice script.

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

@datiswous I added three "wait" commands (code rev 10628). Please let me know if it fixes KP_SLASH for you. The fix should be included in 2.12 beta5.

In that case, separating libre components from non-libre components does not seem possible, and like you say we may then have to assume it is CC-BY-NC-SA. That is something we may want to address, but I'll start a new topic for that. According to the TDM license (https://svn.thedarkmod.com/publicsvn/darkmod_src/trunk/LICENSE.txt), both GPL and BSD "3-clause license" apply for the source code: * The portions base on Doom 3 (1999-2011) is GPL * The portions by Broken Glass Studios / The Dark Mod Team (2005-2011) "were"(?) distributed under "revised BSD license". According to the Debian Free Software Guidelines (https://www.debian.org/legal/licenses/): * Both GPL and "modified BSD License" are accepted into the Debian "main" repository * "Non-Commercial License" (it sounds likely CC-BY-NC-SA falls into this category) is accepted into the Debian "non-free" repository ("revised BSD license" and "modified BSD License" are different names for the BSD "3-clause license", see https://en.wikipedia.org/wiki/BSD_licenses)

@stgatilov, I've been looking into the stray marks associated with Stone 12 pt. Not much progress, because there's something strange going on. Any change I make to the metadata in fonts/english/stone/fontimage_12.dat (whether in the core or as an FM "/fonts/" override) is ignored. Whereas changes to the corresponding 24 pt .dat (whether in core or override) do show up in the nominally 12 pt subtitles (with either gui textscale of 0.24 or 0.25). Is there something in the engine code that is keeping this 12 pt .dat from being used? There are no warning about such at startup. Perhaps some engine hack left over from when there was a missing file?

Nowhere. I don't think it exists. I believe the engine source code and shaders are assumed to be under GPL (except for third-party libraries, which have their license but are essentially distributed in TDM under GPL terms). All the rest is assumed to be CC-by-nc-sa.

Yeah, there's nothing in the syntax that tells you if the gui parameter is set in a gui script or the engine. Sometimes there's a comment in the script that helps out by saying, for instance, "// set by SDK". If you really need to know - say, you're writing a wiki article - then typically you'd do a full-text search for the parameter name within and across files. Namely, the search scope may include: FM-specific .gui files Core .gui (and sometimes .guicode) files Engine .cpp (and sometimes .h) files, of the source code retrieved from, for instance, github I use TextPad to do this. In the case of (2), I have a local copy of the latest official TDM distribution (currently 2.11), where I have replaced every .pk4 with its unzipped equivalent. Because TextPad can't look inside .pk4 files. In the case of "ModNotesText", method (2) found nothing except the line you indicated. Method (3) found this line in a version of the source code: \darkmod_src-trunk\darkmod_src-trunk\game\ModMenu.cpp(81): gui->SetStateString("ModNotesText", info != NULL ? info->GetModNotes() : ""); So, yes, it's set by the engine.

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?)

So how it works is not defined in a script, but in this case in the engine code? How can I know that a GUI::Parameter is pointing at engine code instead of a script? Is this the same for "gui::ModNotesText" on line 593 of mainmenu_newgame.gui ?

In the file DarkmodPadbinds.cfg (https://wiki.thedarkmod.com/index.php?title=Bindings_and_User_Settings): 1) bindPadButton LONG_PRESS PAD_B "_mantle" is listed and does what it says. bindPadButton LONG_PRESS PAD_A appears to do "jump-mantle". Standing in front of a box and doing jump will differ from doing "jump-mantle". Why is "jump-mantle" not listed in the file? (And how come it works without being listed in the file?) 2) bindPadButton MODIFIER PAD_L2 appears to bind a modifier functionality to the "button name" PAD_L2. If a user wants to find out the "button name" of other buttons on their gamepad (e.g. buttons which are not currently listed in the file), what would be a good way to do that? 3) Will TDM be able to recognize unusual "button names" (i.e. be able to capture any "button name" or will button names have to be implemented in the code before it works)?

doh just found out my board does not support rebar by default, i had to use a hack with the rebar code injected into the bios and a small tool to enable it in windows it does help quite a bit though.

Maybe I have to look into the glfw code if I can find something. Where is that in the codebase?