Jump to content
The Dark Mod Forums

greebo

Root
  • Posts

    16732
  • Joined

  • Days Won

    50

Posts posted by greebo

  1. Thanks for doing the digging. Libxml2 is so widely used, that it's hard to imagine nobody else has this kind of trouble, so I'm still thinking it must be in the way we use it. Also, why just in Linux, it all doesn't make much sense. I agree it's not worth doing more investigations when an easier alternative is at hand.

    Yes, I'd add them to the libs, and I'm probably going to set the PUGIXML_HEADER_ONLY flag, at least in Windows.

  2. Oh boy. Thanks for investigating this, reading the issue description I suspected that the XPath queries might be failing, but I thought it was rather due to the libxml2 version used in newer Ubuntus. I recall now that the automated Ubuntu build on Github is not running the unit tests (couldn't get it to run and gave up at some point) - so I missed that this is breaking stuff.

    I searched around for existing code to find out what to pass for that encoding parameter in xmlReadFile, but I couldn't find anything useful, everybody seems to pass NULL as argument, which I ended up doing too.

    12 hours ago, OrbWeaver said:

    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

    I'm all for that, I was that close of doing it when I upgraded libxml2 for Windows. As long as it's supporting XPath and XML Tree manipulations, I'd go for the most light-weight one, maybe even header-only. Our libxml2 usage is confined to xmlutil, so it should be possible to switch. edit: I'd vote for pugixml, it seems to be still alive and has XPath support. It's what I've been using in the TDM game code too.

    But still, if it's the tree manipulations that break the queries, we can either try to find out what we are doing wrong here, or move away from pushing the .game data into the registry trees - it might not be necessary after all, since most (if not all) code is relying on the GameManager interface to get do the queries.

    For the moment being, I can revert the change to xmlReadFile, so that my repo is functional again.

    Are you still investigating this? You seem to have gotten quite far already.

  3. 16 hours ago, Skaruts said:

    I tried having separate portable DR installations for each project, but it seems DR isn't properly portable either, as the game setups are also stored globally. So that didn't work either.

    You can create shortcuts to DR, passing an fs_game=your_fm parameters to DarkRadiant.exe, e.g.

    DarkRadiant.exe fs_game=fms/yourmission

    It will override the setting saved to the user.xml file in your settings folder. Works with fs_game_base as well.

    • Thanks 2
  4. On 1/6/2024 at 7:21 AM, datiswous said:

    You can download a portable version of each, although the settings are shared, so it's not really portable.

    Since a few versions the settings are saved by minor version - so DR 3.7 is storing its settings in a "3.7" subfolder, and DR 3.8.0 is saving them in "3.8". (DR 3.7.1 and 3.7.2 would use the same "3.7" folder.)

    Settings are carried forward the first time you start a newer version. So, when DR 3.9 first starts up, it will use the settings of the highest previous version available, then store its settings in the "3.9" subfolder to not overwrite anything from previous versions. (This is similar to what's Blender is doing, at least I think it is.)

    What's correct though is that the "portable" version is not differing from the installed one in terms of where it stores it settings. They both behave the same. One could maybe vote for having the portable version to store its settings right next to the executable. But to support this, we'd need a configurable code path or maybe even a separate compilation for the portable edition.

    • Like 1
  5. On 1/7/2024 at 10:24 PM, demagogue said:

    Hopefully you can let me know if DR is something I can run on this laptop or not.

    Don't see much in the dump, I'm afraid. I can see it's been running into a critical failure, but that's it. Can you have a look at your darkradiant.log file, or maybe send it to me? Maybe it tells me something.

    (You already tried to remove your settings XML files from C:\Users\greebo\AppData\Roaming\DarkRadiant\3.8, I take it?

    You can back them up if you need them around. Just move the whole contents of the C:\Users\greebo\AppData\Roaming\DarkRadiant\ folder to somewhere else and start DR. In case you didn't try that already.)

  6. You will run into problems with worldspawn geometry, since the engines are usually working with single-precision floats. You'll not be able to distinguish anymore from planes that are 0.5 units apart (which sounds ok, but for angled intersections and sealing geometry this might not cut it, literally).

    (This question really is not so much about the editor, which is working with doubles to store geometry - even though the DR renderer is also operating on single precision floats - this provides a huge performance benefit over doubles).

    • Like 2
  7. Changing the project/game setup and paths is a pretty massive change from DR's perspective. Almost everything needs to be re-initialised when setting the paths, which sometimes takes longer than a clean restart. (For similar reasons, the TDM engine itself needs to be restarted completely when you install a FM.) DR is able to make that leap while keeping the same process alive, but it's a very expensive step, and it's better to restart to clean up any resources that are left behind when switching configs (for instance, all defs that have been loaded from another map/project are kept in memory.)

    From a design perspective, I'd rather not have loading a map implicitly change the whole project setup. At some points it might not be deducible or even wanted to have the paths changed on map load.

    When regularly switching between projects, a possible help might be to create separate DarkRadiant shortcuts, passing the FM project path as argument to DarkRadiant.exe.

     

     

    • Thanks 1
  8. 4 hours ago, datiswous said:

    This issue still remains in 3.6 (under Linux) . If I remember correctly this doesn't happen in Windows (10). Should I create a bugreport in the tracker?

    Since it only affects the Model Selector window, I might have fixed that a few commits back. The Model Selector didn't have a parent window set (since it is initialised very early during startup), that's why it had also been possible to focus on the main window even with the Model Selector open.

    • Like 1
  9. 1 hour ago, cvlw said:

    Usability:  the windows risk docking quite aggressively even if not intended.  I am liking that the properties parent window holds all of these child windows in one place rather than in separate windows.  Perhaps make docking the parent Properties window optional?  I like moving this window around and even moving partially off the screen if I don't close it.  If I move it too far in any direction, it gets sucked into a dock.

    Not much I can change about the docking "magnetism", but as a workaround you can hold down Ctrl or Alt to prevent docking of moved windows.

    1 hour ago, cvlw said:

    Actual bug:  the sizing of the objects within the Entity window (N key) resets when closed and needs to be dragged back out every time it is opened.  This is the area shown in the attached screenshot.

    That should go to the bugtracker please, then I'll look into it for the next release.

×
×
  • Create New...