greebo

Well, we (speaking as TDM team members who are unfortunately forum mods too) could easily have pulled the trigger on the ban and lock buttons on several occasions already, but usually we prefer to handle this like adults (as you put it) and we talk it over, that's really the only reason this thread is still alive. Though we all can remember people being banned in the past (it must have been two members over the past 16 years, if I recall correctly), it will happen if people are really asking for it. I personally am pretty tired of seeing threads being bombed with that kind of bullshit. What hurts me the most is that this kind of thing is directly subtracted from the team's productivity. Devs as the only mods here have to deal with forum bullshit instead of developing source code or entityDefs. So I'd really, really appreciate if everybody pulled themselves together and make this a nice place to be around, discuss and work on TDM stealth gameplay.

"I had to do it, they didn't admit they were wrong!" ++numberOfKilledThreads;

No thread locking, let's just wait a little bit longer. There's still a chance that this might be the first time in the history of the internet for someone to change another person's mind merely by posting on a discussion forum. I can feel it.

DarkRadiant 2.13.0 is ready for download. A lot of fixes and improvements made it into this release. Several point files can be selected for display now. DarkRadiant is now capable of comparing maps, both in differential A vs. B comparisons as well as three-way merge scenarios (when both maps share the same ancestor). Windows and Mac Downloads are available on Github: https://github.com/codereader/DarkRadiant/releases/tag/2.13.0 and of course linked from the website https://www.darkradiant.net Thanks go out to all who helped testing this release! Please report any bugs or feature requests here in these forums, following these guidelines: Bugs (including steps for reproduction) can go directly on the tracker. When unsure about a bug/issue, feel free to ask. If you run into a crash, please record a crashdump: Crashdump Instructions Feature requests should be suggested (and possibly discussed) here in these forums before they may be added to the tracker. Changes since 2.12.0 Feature: Ability to choose from several different pointfiles Feature: Aspect ratio preserving Fit Texture option Feature: ModelSelector: add ability to rescan folders without having to reload all models Feature: Add "Show Material Definition" to ShaderSelector tree views Feature: Paste material-header to surface from clipboard with hotkey. Feature: A way to display editor_usage in the Entity Inspector window Feature: Selection by coords Feature: Three-Way and Differential Map Merge Feature: Map Comparison/Diffing Feature: Git Version Control Integration Plugin Improvement: Show axis when 'R'otating entities Improvement: Improve workflow for adjusting light brightnesses Improvement: Map Loading Performance Improvements Improvement: Refresh entity inspector when reloading defs Improvement: Increase maximum zoom level of 2D views Improvement: "Choose entity..." button for all def_ spawnargs Improvement: CTRL + MMB in orthoview: place camera at height of most recent selection Improvement: Added Documentation for Layer Script Interface Improvement: "Shift textures randomly" shifts all selected faces by the same amount Fixed: Problems with particle preview obstructing the view Fixed: Cannot view or copy from built-in Filters Fixed: Auto-save is slow when animation or particle viewer is playing Fixed: Non uniform light volume scaling not working Fixed: BC5 normal maps cannot be loaded Fixed: Copying a particle in the Particle Editor creates an ___editor list entry which can lead to crashes Fixed: Create Entity window no longer remembers the previous item Fixed: Model exporter: no model is exported if folder path doesn't exist yet Fixed: Non power of 2 textures show up black in Fixed: 'Change game/project' fails to save if a decent-sized .map was loaded Fixed: Reload Defs is messing up the entityDefs Fixed: Crash when using Reloading Defs after placing an Entity Fixed: Entity & Speaker windows don't remember their size Fixed: Restore non-uniform scaling for texture browser. Fixed: Some ASE models do not load Fixed: Prefabs importing miles away Fixed: Path entites rotate 15 degrees, each time when dragged. Fixed: Crash when activating GameConnection Feature "update entities on every change" Fixed: Model previewer not displaying ASE or LWO models Fixed: Crash when selecting an MD5 model in "Create Model..." menu Fixed: Crash when activating the Material Editor in Doom3 game config The list of changes can be found on the our bugtracker changelog. Have fun mapping!

I'll try to create a release in the next few days. We've been in the pre-release stage for far too long now, and given the feedback I'm not sure we have that many testers in the first place.

Oh, in that case... Finding a replacement for the 3.0.x scenario is the only way to go, I'm afraid. The #ifdef is totally up to you, if you think the replacement is really inferior to the 3.1 version, then let's do the #if version check. If the workaround is equally good, then we can just use that one alone. If it's a complex widget, we can also introduce a convenience type to wxutil, not sure if that's worthwile here. I believe there's a wxGauge progress bar widget available in 3.0 that can indicate work without actually showing the state of completion. But it needs to be Pulsed regularly to be animated: https://docs.wxwidgets.org/3.0/classwx_gauge.html (I just checked the wx roadmap, they plan to release 3.1.6 before 3.2.0, and so far there's no sign of 3.1.6. So I wouldn't bet any money on Spring 2022 anyway...)

That's a problem I regularly stumble over. wx 3.1 has many nice advancements, and I more than once had to add ugly preprocessor switches to the code to fall back to some ugly workaround to be able to compile against 3.0.x. Nothing we can do about that, I'm afraid, other than to look out for things that are only available in 3.1.x. It's a rant of course, but I've been using wxwidgets 3.1 in Windows for years and years now and it's stable as a rock, but Linux distros are still stuck with the older 3.0.x because it's not officially realeased as stable (they are all waiting for 3.2.0, I guess). wxWidgets 3.1.0 has been released in 2016, with the following text In 2018 the text changed to "and you’re encouraged to use this release, including in production". But of course, as long as they don't call it final the distros are holding back. From the looks of it, things will clear up rather soon, because the wxWidgets folks want to release 3.2 in autumn, so keep your fingers crossed that distros catch up on the release until Spring 2022.

I'd prefer to have a look at that one myself, if you don't mind. But you can point me to any bad locations you stumble over. I already had a look at the other exceptions myself when loading a smaller map and those are usually thrown in RotationMatrix::setFromAngleString, where an empty spawnarg value is attempted to be processed. I'm pretty sure we can circumvent most if not all of the exceptions by just adding a "value.empty()" check before trying to parse. If there are any more parsing failures causing exceptions, I'd like to see and count those occurrences first, maybe we don't need to change anything.

I'm happy to merge that pull request, thanks for setting it up. While it doesn't affect end-users, it's still worthwile to make dev life easier. I'm curious though how you found out which exception was slowing down the movement? Can you observe such slowdowns in the profiler? Or is it the Output window where studio logs the thrown exceptions? edit: ah, nevermind, I just figured it out. Was not too hard to find it, after all. The output window is spammed with the std::bad_cast messages when you move around.

I can confirm that this was not an active design decision, at least not on my behalf. The texturing code has undergone so many refactorings that the behaviour was bound to diverge at some point from the original GtkRadiant behaviour. Nobody brought it up until this point, so it makes sense for this thread to appear. Also I'd like to state that I'm not defending either default behaviour when applying textures to surfaces. I personally don't care too much since I'm copy/pasting texture projections around all the time using the middle mouse button. I don't switch to a different material and expect them to be perfect, there's always some workflow to be done after changing it before I'm happy with it. As already stated on the bugtracker entry, I just need to know what exactly should change since there are a few ways of applying textures to objects, and all of them work slightly different. And I kinda saw it coming that there might be a different understanding of people on how it should work by default. It's not an either-or discussion where one camp has to win to have their one and only correct way implemented in DR, I don't see why it shouldn't be possible to have the texture scale adjusted according to a preference setting or similar. Let's see some suggestions on what specific behaviour should change in DR and whether it should be a preference setting or not. Then I have an easier time figuring out how I can change the implementation. Not sure if it helps, but If I recall correctly what the code is doing, the value in the "Default Texture Scale" field is the scale that is used when "Normalise Texture" is clicked. People dial it up or down and then click the button to have that "default" scale applied. Maybe it even is used when new brushes are drag-created, but I'd have to check up on that. It is definitely not interpreted as some sort of "Default Texture Density", "Texel Scale" or something like that.

Granted, not saying that an STL thread pool wouldn't be nice to have. Maybe something like this will be added at some point. C++ has been moving faster the last decade. Though one can always look around and pick one of the available thread pool implementations, like this one https://github.com/vit-vit/ctpl This specific one doesn't seem to rely on anything other than STL and doesn't require compiling a static lib, so it seems to be light-weight. I'm sure there are more like those.

If a coder chooses to spawn a thousand std::async tasks, I'd really lean towards calling this a design problem, and no one should really rely on the standard library fixing that. It's always the programmer's responsibility to do something reasonable here and partition the work into processable chunks.

This cramped appearance usually indicates that the the parent-child relationship of widgets is messed up. Your code in the constructor to load the XRC-defined panel returns a wxPanel* reference, use that as parent to the indicator: GameConnectionDialog::GameConnectionDialog() : wxutil::TransientWindow(_(GameConnectionDialog_TITLE), GlobalMainFrame().getWxTopLevelWindow(), true) { auto* panel = loadNamedPanel(this, "GameConnectionMainPanel"); //could not find activity indicator in wxFormBuilder auto* ConnectedActivityIndicator = new wxActivityIndicator(panel, wxID_ANY, wxDefaultPosition, wxDefaultSize, 0, wxT("OMG")); replaceControl(findNamedObject<wxWindow>(this, "ConnectedActivityIndicator"), ConnectedActivityIndicator); ... }

Yes. I don't see any other ways to prevent the UI thread from blocking. Doing it in some sort of custom event loop will not work, I guess. Any part of the process launching code can take long enough to block things at least a bit.

Re async: I'd launch the long-running task using std::async, storing the returned std::future in the class to be able to await it if really needed. Within your async method and after the actual work is done, queue an event using GlobalUserInterface().dispatch() - this event will be picked by the regular event loop, it will be executed on the UI/main thread. You still need to take care about the things you touch in the worker thread of course, so the regular threading rules of caution still apply, but using the pattern above you can at least safely update the UI once the task is done without any polling or custom event loops. (There are code examples in the vcs plugin I recently pushed to the master branch.)

Have you tried Scripts > "Select all Models of same type"? It should select all entities with the same model spawnarg.

Note that when you enable com_automation for the first time, the Windows Firewall will ask you for permission. Most players won't have interest neither in mapping nor in having their game process to listen for connections - I think enabling this feature and confirming the firewall dialog should be something that is done on purpose, once when people start playing around with the editor. On the other ideas, I think there's nothing stopping DarkRadiant from launching the game with the +com_automation 1 parameters. That would be useful and resembles some of the functionality that was present in DoomEdit.

Don't bang your head against this, unless you really want to. You don't strictly need the unit test project to use DR you compiled from the sources. Sounds like VS2022 has some minor difference in the google test handling, the DR solution probably has to be adjusted for that.

Well, maybe the path of the header file got changed, who knows. I'll have a look at VS2022 sooner or later, but right now I don't feel like it's urgent since it's not even released yet.

No, I suppose it's part of the Visual Studio test adapter that can be selected in the VS Installer: https://docs.microsoft.com/en-us/visualstudio/test/how-to-use-google-test-for-cpp?view=vs-2019 Entirely possible that the compilation guide is lacking that piece of information. It's only used for the unit tests though, so you could in theory unload the Tests project before compiling.

That dialog and its functionality is ancient. It must have been introduced when there haven't been any patches available at all - Brush Number really refers to "Primitive Number". Entity 0 is the worldspawn, as you found out. Putting Entity 0 and a primitive number will look up the worldspawn brush/patch for you. I guess the dialog should be made to work with non-func_static models too, since the entity number 100 is a valid one and it should be found even if has no child primitives attached to it. Not sure about the workflow though, what's the reason you're looking up the entity by number instead of its name? I guess the Entity List would do a better job at locating entities in most cases.

The master branch on Github should be compiling fine with the dependencies that it downloads using the Python script (either automatically or manually, as you did). I haven't touched VS2022 yet, as there's only just a Preview release of it. It's not unlikely that the new version is causing the trouble.

I think it's this one: https://bugs.thedarkmod.com/view.php?id=5608 To reproduce in 2.12.0, you have to rotate it first, then drag the entity around, iirc.

Thanks. I'm into other things at the moment, so it might be a while.

Nope, not from the distance. I'd have to look into it with the debugger before being able to say anything. If it's tracked, then chances are higher for me to have a glimpse at it sooner or later.