OrbWeaver

Conversation editor restored in Git commit 72c6c52bdf0b6fa1f1ae76ede51ae5bf971258ab

Oops, that's my fault. It seems I missed out the conversation plugin when setting up the CMake build.

If I understand correctly:

If you pull my master branch you'll get some tweaks to the Connection menu items (replace separate enable/disable options with a standard menu toggle) and two new icons in the camera window toolbar which correspond to the camera sync connection options. There is also better error handling, so if the connection cannot be made an error dialog will appear instead of nothing happening. I didn't create a bugtracker entry so far since these sort of GUI tweaks are something of an ongoing process, but I'm happy to create an item to cover these specific changes so it can appear in the changelog.

@Zerg Rush Thanks, grayman sent me a PM giving me some helpful hints, so I'm on my way to completing the missio now.

OK, I'm going to have to admit defeat on this one. I must have wandered around this map for hours, but I still have no idea where I'm even trying to go, much less how to get there. I've found the theater, which seems important and suspicious but despite looking in every room and reading the two or three readables, I couldn't find anything which advanced any of my objectives. I've also been inside a hotel, a couple of workshops, a builder chapel and a lighthouse but still, nothing.

It may be that he is not referring so much to the capabilities of the engine, or even the resolution of the textures and models (which is not all that easy to notice if you are not specifically looking for it), but to the style of map creation. I have noticed that some missions tend to use design techniques which were common in the simpler Thief games but look less realistic compared to the level of detail in modern games, e.g.: Truncated slivers of bricks around and above a doorway rather than a realistic supporting beam or lintel, making it appear that the door or window is just cut

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.