OrbWeaver

Agreed. Unless there is a strong reason to only monitor a particular type of asset, it would be better to have a single option "Monitor for asset changes" which is either on or off. I don't agree with this, it seems like the common "We can't agree on the correct behaviour so we'll just dump it onto the user through dozens of preferences" approach. Also the DarkRadiant preferences dialog is somewhat limited in terms of UI layout (it's not manually designed, but automatically generated based on adding particular options in code), and having a vertical list of 10 different checkboxes is g

Looks like a great new feature. I'm curious though, how will things like models and sound shaders be created from this view? Will they be dragged and dropped into the 2D view, or will you double-click them and they appear at some default location (e.g. the center)? And this in turn raises the question: could we use this same interface for all assets, not just Favourites? We could turn the Media tab into an Assets tab and allow the same creation mechanism (D&D or double-click), while listing not just textures but models, entities and everything in a single tree structure.

There already is a blacklist mechanism, but it requires changes to the mod asset tree, rather than being accessed through the GUI. https://www.darkradiant.net/userguide/#_features_for_game_distributors

Boost.Process can handle this, however we don't currently have Boost in DarkRadiant (since all of the Boost features we were originally using are now part of Standard C++, and I understand the Boost dependency complicates the build on Windows). I see that wxWidgets has some process related classes, would these be sufficient?

Sounds like what you want is exactly what's implemented, except that it's currently a menu item rather than a button. Again, that's complicating things by introducing a need for DR to "take orders" from another process and trigger UI changes that don't correspond to keyboard or mouse events from the user (and might conflict with those events). It's much safer and simpler to have the currently implementation whereby the trigger to synchronise locations comes from DR menu/button events rather than commands from inside the game.

I believe the reason 2-way sync doesn't exist is because DR is event driven, i.e. it responds to user mouse and keyboard events, therefore all of the sync options are triggered by DarkRadiant (even if the effect is to receive data from the game, such as "Sync camera back now"). Having DR respond to "events" received asynchronously over a network connection, which do not correspond to any wxWidgets input events, would probably require multiple threads and all of the ensuing timing and race conditions that arise when trying to combine multiple event streams.

I'm fine with that wording if users consider it clear enough. Such a question should be addressed to @stgatilov I think, since he implemented this functionality. My only concern is fitting an appropriate DarkRadiant UI around the features. For what it's worth, I tend to agree: if dynamic hot reload works fine (without saving the map), I'm not sure of the benefit of an extra option which only reloads after save. But perhaps there was a good reason for separating this functionality (performance maybe?). No disagreement from me here, and it should be easy to automatically act

"Load camera" from game means moving the DR camera to match the current player position. "Send camera" does the opposite, moving the player position to match the DR camera position but it does this dynamically (whenever you move the camera), hence a checkbox rather than a button. I'm open to suggestions for clearer wording for these options, which need to make clear that the checkbox and button work in different directions (so just labelling them "camera sync" is confusing). That's exactly what a checkbox is, isn't it? "Update on change" activates continuous hot reload (so any ent

Here's another mockup with just the options that make sense: one checkbox and one button for each row, with the names changed to indicate more clearly what each row's options do:

The overall layout looks promising, however in wxWidgets we are not drawing custom buttons/UI but using the system-styled widgets. This is what your layout might look like in wxWidgets: However, the problem with this layout is that there are far too many combinations, many of which don't make sense. Camera sync is either "on movement" or "when button is clicked". So we only need one checkbox and one button on this row. Reload map is either "on save" or "when button is clicked". One button, one checkbox. There is no "on change" because a change which is not saved will h

You can try, but it probably won't work. The minimum version is set based on the used CMake features.

Ubuntu PPA release published for Focal.

This is now implemented in f7f1720bd3109909beea110ac0ed55e1d9d92bc6

I'm not sure about the situation on Ubuntu 20.04, but on 20.10 which I'm currently using, it seems that libjpeg-dev depends on libjpeg-8-dev which in turn depends on libjpeg-turbo8-dev and finally on libjpeg-turbo8, which I presume has been selected as the default JPEG library instead of libjpeg62 for some reason (maybe performance). I think on all Ubuntu versions the development package to install is libjpeg-dev, which might depend on libjpeg62 on some versions and libjpeg-turbo8 on others, but developers don't generally need to worry about the precise libjpeg implementation unless they

In 737a8ae0dd67a463109fb4c8b73062a2f1fbd1fb I am now writing out the relative library path from CMake into config.h and using this to load the modules instead of a hard-coded relative path. I've tested by manually editing CMakeCache.txt to use "lib64" as the library directory on Ubuntu, and the installed software still works, so I'm slightly more confident that this should fix the issues on distros that use lib64 by default.

Damn, just when I thought I'd found the last hard-coded lib. Yes I think you're right, we need to be passing the relative path in as a #define in config.h rather than having directories written into the source.

In Git commit 5ae45caff3147b8baf99ea0917b0068a62d79752 I've added ZLIB as a link dependency when building the radiantcore module, which hopefully will fix this problem. Since I don't see the issue on my system (it looks like linking with libpng automatically includes -lz as well) I can't guarantee that this will be the only place that linking with ZLIB is needed, but any other issues ought to be similarly easy to fix.

Thanks. Definitely no -lz in there, which looks like a deficiency in the CMakeLists. We are not explicitly linking against ZLIB, which probably worked fine on my system because some other library was including it by default but for some reason this doesn't happen on your system.

I think you've run into the same problem that MirceaKitsune had: CMake installing things into lib64 whereas the relative rpath baked into the binary expects lib. I'm hoping it's fixed in my latest master. I'm open to suggestions regarding which should be the default. Both options should work seamlessly in most situations (at least once the currently-reported problems are fixed) and the average user probably won't notice or care much about the difference, but there are edge cases where each one would be more appropriate. ENABLE_RELOCATION=ON will build something more like the Windo

I'm hoping this is fixed in bf5eaaa9264d176362a0d1abf9d5071bdbaa7959

Could you please post the error using verbose make, i.e. make VERBOSE=1 We don't need the whole build log, just the part where it tries to link the problematic library (which will probably say something like "Linking CXX shared module libradiantcore.so").

Although I don't think it's the cause of the problem, I don't recommend using the install directory as the destination for your build. install is not a destination directory, it's a source tree full of the resources, XML files and scripts which need to be copied into the final installation location. Having both the source files and the destination tree in the same directory is confusing and there is no guarantee there won't be some conflict between a source file and some file created by the make install step (which will just silently overwrite whatever is there). It's much better to have the f

@MirceaKitsunePlease can I see the output of: objdump -p /archive/mircea/Games/Quake/TheDarkMod/DarkRadiant_GIT/install/bin/darkradiant ldd /archive/mircea/Games/Quake/TheDarkMod/DarkRadiant_GIT/install/bin/darkradiant find /archive/mircea/Games/Quake/TheDarkMod/DarkRadiant_GIT/install cat config.h (in the top of the source directory, after running CMake)

If that's the only problem, it's not a bug. DR is not intended to be runnable from the build directory without the make install step. I've added a note to the bugtracker issue accordingly.

I've never seen in-game selection of MSAA samples work on Linux. I guess it's a driver issue. The super-sampling AA (r_fboResolution > 1) works fine, although it's heavy on performance.