OrbWeaver

You're right, libxml2 can't be fundamentally broken since it is such a core dependency on Linux, plus the exact same XPath queries work perfectly fine even within our own XmlTest, so it must be something specific to how XML is being used within the registry setup. I found a couple of online sources which suggested that XPath queries might fail if the DTD doesn't validate, but we don't have any DTDs in our XML files and the XML_PARSE_DTDVALID option is not set by default in any case. Encodings are another possible culprit (especially since the problem seems to be OS-specific), but as far as I know encodings wouldn't change the parsing of characters like "[" or "@", and if the encoding was so fundamentally wrong that even regular 7-bit ASCII failed to parse, then how would "//game" ever be found? It seems that whatever the cause of the problem is, it is very well hidden within the API and would probably require building libxml2 from source and diving into it with the debugger to find out what is going wrong. Right, that sounds like the best approach. I'll set the HEADER_ONLY flag on Linux too then for consistency, and integrate it as a header-only dependency like libfmt.

Well I think I've gone as far as I can with this but libxml is simply not doing what it's supposed to. I can put code like this in the Game constructor: auto games = GlobalRegistry().findXPath("//game"); assert(!games.empty()); // SUCCESS assert(games[0].getAttributeValue("name") == _name); // SUCCESS assert(!GlobalRegistry().findXPath("//game[@name='" + _name + "']").empty()); // FAIL The "//game" node is there, it has an attribute "name" with value "Doom 3 Demo" (or whatever the first game to be loaded is), but passing that exact name string back to an XPath query using the [@name='blah'] syntax just doesn't work, even though it used to work fine, and should work according to the XPath specification. I even dug down into the Document::findXPath function to see if something was being set in one of the C structures to indicate what is going wrong, but even though there is a lastError struct, it is empty. If there is any indication of the problem, it is buried deep within impenetrable and poorly-documented C structures. So, I am done with libxml and will look at C++ alternatives. If we were going to integrate this, what is the best way of doing so? I seem to recall from previous discussions you would prefer not to have git submodules linked into the repo, and it looks like pugixml is just one .cpp and one header file, so I guess the simplest approach is just to download the files and add them directly to the build in a suitable directory (like we do with the libfmt library).

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 did some debugging in unit tests. The first problem is that although we have a basic XmlTest, it uses the full RadiantTest fixture which can only be constructed if the XML registry is working fine, so these basic XML tests are not runnable. I managed to fix that by changing the behaviour (on Linux only) to use TEST_BASE_PATH instead of _context.getTestResourcePath() to find the test resource files, so that RadiantTest is not required. This confirmed that the basic functionality of loading XML is working perfectly fine, even with the switch to xmlReadFile(). All of the XML tests pass, and I can load one of the game files in a unit test and examine its properties. So there is nothing fundamentally wrong with the XML structure being created by the new function call. The problem seems to be that within the Game class, any attempt to look up key values in the registry fail. Although each Game class is constructed successfully and imports its content, any searches for its own XPath root (e.g. "//game[@name='Doom 3 Demo']") return a list of 0 nodes, even though that exact XPath string can be used successfully within the basic XML test to find the <game> node which was loaded directly into an xml::Document. So there must be something going wrong with either when or how the .game file content is being merged into the global registry hierarchy.

I very much doubt it. You are building from source on Ubuntu whereas demagogue is reporting a problem with the released Windows build. I believe your error is the same one I encountered here: This error is triggered by a change in Greebo's repo which I haven't yet merged, so if you build from my repo you should avoid this issue.

For an as-yet unknown reason, this commit seems to break XML parsing on Linux: #6439: Use xmlReadFile instead of xmlParseFile which has been deprecated and removed. Privatise Document() constructor accepting an xmlDocPtr. As far as I can see, the commit is entirely correct. xmlParseFile is indeed deprecated, and the new usage of xmlReadFile matches what the libxml2 examples are suggesting. But the result is that although the xmlDoc* returned from the function is not NULL, nothing XML-related works, the entire registry system returns only empty values, and almost all of the tests are broken (because the main radiant core cannot be initialised without any registry values available). Changing back to xmlParseFile makes the problem go away but is an unsatisfactory solution because it specifically reintroduces a deprecated function call. I am not sure whether this is a bug in the specific version of libxml2 on my Ubuntu system, or something incorrect about how we are calling xmlReadFile (i.e. perhaps it requires an encoding or a particular non-default option to correctly process our XML files). Unfortunately like many of the core GNOME C libraries, the documentation is bare-bones and explains almost nothing (like what any of the parsing options actually mean), and I cannot see an obvious way to ask libxml2 to return meaningful errors, or to query exactly what might be wrong with a constructed xmlDoc* object. It makes me wonder if it would be better in the long term to ditch the reliance on libxml2 and instead use one of the light-weight C++ XML parsing libraries like RapidXml or pugixml instead. Not exactly a trivial change but might not be too cumbersome since the existing XML code is wrapped in our own xmlutil classes and not generally used directly by the rest of the codebase.

It's much simpler than that: TDM includes numerous 3rd-party assets which forbid commercial usage. Even if every single team member approved of a license change, it would still not be possible without identifying and removing all of those 3rd-party assets (and any derived assets based on them) and replacing them with free alternatives. They do. There are numerous easy ways to obtain and install non-FOSS projects on Debian. You can download and extract a tarball, run a dedicated installer, add a custom PPA from Ubuntu or some other source, install an AppImage, or install a FlatPak. You can even install non-FOSS projects directly from Debian using the non-free repository. At no point do they "force" anyone to do anything. What they don't allow is adding non-FOSS or otherwise restricted content into the main Debian repository, which is their right as a free software project.

I'm fairly sure they would accept this, if such a package could be produced. They might accept this, but I'm not sure. If it's an installer that allows users to pick and choose optional packages, some of which may be non-free, this would probably be OK — in fact this is pretty much how the in-game mission downloader works. If it's a single installer that just "makes the rest of the game work", this might be seen as trying to evade the free software guidelines by indirectly packaging non-free content in an otherwise-free package. It might be necessary instead to package all of the non-free content in a separate DEB and put it into the non-free repository as an optional (Suggested/Recommended) extra. Yes, this is the correct way to do things on Linux, and indeed how vanilla Doom 3 worked. In my opinion it would be much better if the Linux build of TDM worked like this, but I don't know how much work would be required to move away from the "everything in one writable directory" model that has been fairly solidly baked into the game implementation for many years.

In theory that should be possible, and I believe (although again, I'm not an authority on Debian policy) that it would permit inclusion in Debian, because the GPL parts could be in the main repository and the non-free parts could be in the dedicated non-free repository. I suspect they wouldn't accept the main package if it didn't contain some minimal playable content (which is basically what the OP is suggesting). But as others have said, separating out the various free vs non-free components would be a huge task. I believe there are also problems with trying to have the game installed in a non-writable system-wide location, because they game expects to be extracted into a writable directory and store its data locally.

Because people don't understand that "freedom" is not a scalar quantity, and talking about "more free" or "less free" is just meaningless nonsense. A license itself is not "free", but it can try to protect freedoms for specific groups of people (users, developers, company owners, etc), some of which might directly conflict with the freedoms of other specific groups of people.

I'm not a Debian developer so I can only guess why, but I'm pretty sure the Debian packaging rules do not allow a package to include just an installer which downloads content, because it bypasses the whole packaging system. Debian (and RPM) packages are supposed to contain the software, so that they can correctly track its installed files, clean it up after removal, etc. Having the software managed by an installer makes any tracking by the packaging system impossible, and defeats the point of using a package in the first place (you might as well just download and run the installer yourself). That's not even a remotely valid comparison. A browser does not require downloaded non-free content in order to perform its function as a web browser. TDM will not work without the 2.3 GB of non-free (according to Debian free software guidelines) content. That content is an integral and necessary part of TDM, it's not just some remote web page that you are "viewing" with the TDM installer. Whether the DEB package contains the entire content or just a downloader which installs the content doesn't make any difference to the licensing aspects.

Speakers only get louder or quieter while you are between the inner and outer sound radius. Once you are within the inner radius, the volume is constant. It is entirely possible to cover a large map area with a single omnidirectional speaker playing ambient music with a large inner radius which ensures a constant volume. However there may be other advantages to using zone-based ambients (such as the ability to adjust the volume in settings, as you mentioned).

Is that the one with the really confusing labyrinthine library that nobody's allowed to go into? I always thought that would make an excellent (part of a) Dark Mod mission.

Not everyone is sensitive to (or can even detect) screen tearing — if you don't have a problem with it, and also don't have a problem with a noisy or overheating GPU rendering at too high a framerate (which could also be solved by capping the FPS, independently of VSync), leaving VSync off is perfectly fine.

The point of VSync is to reduce visual tearing caused by updating the frame halfway through a screen refresh while something is moving on screen, as well as reducing wasted GPU cycles rendering more frames than can be shown on screen (although some people like extremely high framerates for various other reasons). However as far as I can recall, I've never seen the VSync settings in the game have any effect on Linux (and I use AMD cards, so I don't think this is specific to nVidia).

DarkRadiant does not care about engines at all, it only cares about file formats. Whether you can use DR with your Godot-based game will therefore depend on whether your game's assets are arranged in the same way as TDM. More specifically: Your game will need to read map data from the Doom 3 .map format. If it does not, there will be no way to save your map from DarkRadiant in a form that your game can access. Export to OBJ is available but if all you want to do is produce OBJ models then DarkRadiant isn't the right tool for the job (you should use a proper 3D modelling app like Blender/Max/Maya/LightWave etc). Your game assets will need a tree of .def files defining important entities to be placed in your map, including certain "fixed" entity types which are used directly by DarkRadiant itself. There will need to be a light entity defining light volumes, a func_static entity defining a static model, an info_player_start entity to define the starting position, a speaker entity to define sound sources, and probably several others. If these entity types are not defined, then built-in features like "Create light" and "Place player start here" will not work correctly. Your game will need a tree of .mtr files defining material shaders, referring to image paths which will be resolved to either uncompressed .tga files in a textures/ hierarchy, or compressed DDS files in a dds/ hierarchy. If these material shaders are not defined, no materials will appear in DarkRadiant. DR does not make any attempt to load "raw" image file hierarchies which are not referred to by material shaders. Your game will need to define a hierarchy of 3D models in ASE or LWO format. No other formats will show up in the model selector. These models can be stored directly on disk (there is no "model shader" tree required like with materials).

That's actually quite hilarious — using your credits to openly list all the unlicensed content you stole from other games. I wonder if the modelling section of the credits says "Thanks to ThePirateBay for providing the cracked copy of 3DS Max we used for all our custom models".

That layout is possible. You need to: Drag the camera view and dock it at the bottom right. Drag the properties panel and dock it at the bottom left. This will leave a vertically split window, with the properties panel and camera view at the bottom, and a single wide XY window at the top. Choose View -> New XY View to create a new XY window, and drag this window to dock at the top right, leaving the default XY window at the left.

XYWnd.cpp no longer exists, it was renamed to OrthoView.cpp. The Visual Studio project will need to be updated to point to the new name otherwise it will try to compile a file which no longer exists.

If there are missing files reported, it's likely the .vcxproj needs to be updated with moved or renamed source files. Unfortunately I'm not in a position to do that (without guessing) because I only build on Linux which uses an entirely separate (CMake) build script. I don't know the cause of the other errors but I would guess they are downstream consequences of not having all the required source files in the build script.

The old-style view layouts no longer exist since the UI has been converted to use fully customisable dock widgets for all major UI elements.

I think we'd need to see the mesh and the UV map as well, in order to properly diagnose this issue. But it's quite likely it is a clamping issue, as LDAsh suggests. I wouldn't be surprised if you have "clamp" in your MTR file. Note that if your texture doesn't use an alpha channel (and it seems this image doesn't), DXT5 is just a waste of space compared to DXT1. Also this image doesn't tile properly and won't look good as a texture even if you solve the clamping issue.

Yes, I'm familiar with this sort of junk-science "analysis" assembled by journalists or random tech companies counting stuff in a database and using it to form some kind of conclusion. Side note: one of the dumbest articles I ever read was some lazy tech journalist trying to decide which Steam games were popular based entirely on the average total play time (in hours and minutes). He concluded that everybody hated "HL2: The Lost Coast" because the average play time was about 15 minutes, without bothering to check that The Lost Coast is actually a short tech demo that can be completed in a few minutes, so obviously people aren't going to rack up hundreds of hours playing it. For example, consider these numbers: So they count "Debian", which is an entire distro with thousands of packages, separately from "the Linux kernel" which is one component of a Linux system and already included in every other Linux distro. Does that mean the 2357 kernel vulnerabilities need to be subtracted from the 3067 Debian vulnerabilities, or have they already done that? Do the Debian vulnerabilities include only the kernel, core packages, or every package in the distribution (including Firefox, Thunderbird etc)? The article doesn't say, and the source data is not available since this is just a second-hand report of an "analysis" done by a random VPN company, not a proper scientific study. In any case, comparing an entire Linux distro with just "Windows" isn't a valid comparison, because a Linux distro includes thousands of third-party packages. In order to make that a fair comparison you'd also need to include Microsoft Office and everything in the Microsoft store under the "Windows" heading. I realise that everybody hated Windows 8, but I'm fairly sure that it didn't somehow magically vanish from history. And how do we know that it's valid to simply add together the number of vulnerabilities for Windows 7 and Windows 10? As far as I know Windows 10 wasn't re-written from scratch — many of those might be the exact same issues. So they're potentially including a full 16 years of extra vulnerabilities to Debian, by arbitrarily excluding all versions of Windows released before 2009, with absolutely no justification? This analysis is a complete joke. No shit, Sherlock. They got something right at least. Nobody should be complacent about security, since all modern operating systems and software are affected by vulnerabilities, and need to be kept up-to-date with security patches.

You need to install the darkradiant-plugins-darkmod package.

I never realised Bill Gates was a member of these forums. Welcome to the community! I hope you enjoy The Dark Mod. Perhaps your Foundation could help pay for the server hosting or fund the development of some new features?