greebo

When you hit Build Solution, everything should be compiled automatically, including the Download of windows dependencies. That's also what happens on the build server too, something must be different in your working copy. This is the same for every configuration: The DarkRadiantCore module is what was missing, but I can't see why it shouldn't build when you hit Build Solution. Did you just hit F5 to run the UI binary? That might perhaps do it.

This problematic situation was there right from the start, I think Fidcal solved in Thief's Den by adding trickery to the chest lid, like triggering the contents to make them frobable as soon as the chest is opened. Something similar could be applied to the situation of the secret lever that is frob-highlighted unintentionally: The thing that is obscuring the lever might need to be moved away first to reveal the lever and make it frobable at the same time.

If I recall correctly, the code is not just relying on a single trace, but performs a small bounds expansion at the point of impact to find things that have been closely missed by the trace, which could be the reason behind things lighting up near or behind the trace end point. I might be remembering wrongly though since I haven't looked at that code for a very long time.

A few months ago I changed a few things to the simpler and the last registration, calling EventManager.addCommand with twice the same argument should not be necessary anymore, since the events automatically find the correct command when they are connected to controls. A whole lot of things are possible through the console, and while you don't have to expose the game connection commands to the console, it doesn't hurt at all. You get that console access for free anyway, since creating a command is necessary for the UI to connect to, and creating a command automatically makes it accessible through the console entry box. No events. But Python scripts can at the very least run console commands like "TexShift '0.3 0.4'". But most core modules have a "proper" Python interface and you can work with those natively. There's a huge wiki page describing the interface, and there are example scripts in install/scripts/ A command is the thing that is registered as callable function, like "TexShift" or "SnapToGrid". A statement can be more complex, calling one or more commands in a row, with and without arguments, like: "TexShift '0.1 0.2'; TexRotate '0.12'; ConvertSelectedToFuncStatic; UnselectSelection". It's more like a macro, similar to the "bind" command in TDM. You can also create those statements and assign shortcuts to them, they are persisted between sessions.

The TransientWindows are usually just hidden when clicking on the X on their corner. They stay alive in the background and are toggled, like the SurfaceInspector or the Texture Tool. There are methods to override to run code right before the window is shown and after it's hidden, in case the controls need to be updated or listeners have to be unhooked. In DR, keyboard shortcuts are assignable to all "commands" that don't require arguments to work. Commands are registered in the GlobalCommandSystem, if you do a text search for that you should find many examples. There is some support for UI stuff like toggling a checkbox and binding toggle shortcuts to registry keys, iirc this is handled the GlobalEventManager in the UI module, but I have to check to be sure.

What I would do to achieve the shown example is to create a longer, upright beam, fit/adjust the texture it as long as the brush is still upright, then rotate it with texture lock enabled, and finally cut the extending parts off with the clipper. I know that's not as convenient, but as OrbWeaver described it's just not possible for the texture to follow along the shear operation. Rotating would be different (otherwise the texture lock wouldn't be working), but in this example it's the shearing that makes it very hard to sense what should be adjusted.

I'm ok with introducing such an option. For me it's important to know what "applying" actually means, since there are so many options to do it. Am I assuming right that you're referring to a) assigning a texture by clicking a tile in the texture browser and b) assigning it by the Browse button in the Surface Inspector?

I figured most materials in TDM maps will be lit by sources that have a flame-like colour, so this resembles the final appearance best. But of course it doesn't offer a neutral view on the material which might be desirable too. I think remembering the value would be best, please feel free to open a tracker entry for that.

If it's reproducible, off to the tracker it goes!

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.