greebo

It's all about overall compilation duration for me. And yes, it is indeed a bit self-centered, since I want to use my time effectively when working on DR. I don't want to cut down my own free time just because low-end machines might get into trouble when building from source. Or do you? On a more general note, I don't explicitly force the Visual C++ compiler to do all builds in parallel, I just enable it by setting it the flags and defining the dependencies. I shift the responsibility to not overload the machine to VC++, which I think is respecting the amount of cores and memory, or is it not?

The compilation guide refers to the master branch, since the command git clone git://github.com/codereader/DarkRadiant.git will check out master. I wasn't aware that you're on Linux, because the snapshot builds above won't apply to you, it's for Windows x64 only. You'll have to build from source to test anything in between releases.

It's more like an all-or-nothing thing, you can't really cherry-pick a fix to a specific issue*. By checking out the source code that includes the fix to #5711, you'll also get all the fixes and changes that have been made in between the release 2.13.0 and the fix to #5711. I'd recommend taking a snapshot build that has been compiled from the recent "master", this should be good enough for your testing purposes. While there are no guarantees made, the code in the master branch is usually production-ready and can be used for actual mapping work. If I'm working on something that completely breaks features, I'll do that in a feature/dev branch, like the "textool" branch. *) Coders will correctly point out that this is an incorrect statement, one can probably pick and stitch together certain code changes to get something like "2.13.0 + this fix", but this is more work than it's worth. Just use the latest master.

Yes. One has to be logged into Github to see the download links, but there's a portable package for each pushed set of changes. E.g. https://github.com/codereader/DarkRadiant/actions/runs/1218642341

It's not the wrong area, this forum is fine for this, I'd say. In source means in the DR source code, it's been committed to Git. The next release will have the fix included, and if this is too long too wait, there are snapshot builds available on Github too.

Seems you are talking about this one: https://bugs.thedarkmod.com/view.php?id=5702 It's already fixed in source.

Yes, tracking all the things you work on into online forms is a tedious task that nobody likes, if not outright hates, myself included. Feels like needless bureaucracy invented by control freaks, and as such it feels like my natural enemy... but the only thing more tedious is to skim through dozens or hundreds of git commit messages to gather everything that's been changed in between releases, that's why I do it. And it's admittedly a nice feeling when you get to scratch something off a list when you're done.

2.13 was released in August, so I think yes.

Seeing that nobody actually changed their status in the past 48 hours, it might as well be broken - I haven't tested it myself to be honest

This just seemed to be deactivated. Not sure if it's a good feature, but there you go ==>

I've confirmed two of them right away, feel free to have a go at them! Not so sure about the Ctrl+S one - I can confirm that this is not intended behaviour, but I'm not sure if there's an easy non-hacky fix for that.

I've disabled the ranks feature for the moment being. If more people disapprove I'll consider re-enabling it again, I don't have a strong opinion on that one.

That's already fixed, at least I'd like to believe that: https://bugs.thedarkmod.com/view.php?id=5706 But I appreciate your readiness to look into it, helping hands are always welcome.

That's what effectively the solution and its configuration represents. It defines what projects should be built, like shown in the screenie above. DR doesn't do this, but one can define more configurations than just "Debug" and "Release", and specify which projects should be built and which should be skipped. IIRC, the TDM solution is using Configurations, to skip the compilation of the MayaImport DLL by default (which needs the SDK installed to compile and link successfully). It's a bit like specifying all these ./configure switches --enable-darkmod-plugins, just not as freely combinable.

Yeah, I've seen a few of those mega-solutions, they are rarely nice to handle. They also tend to cause problems with plugins like ReSharper, which severly slow down your VS installation. I can set the DarkRadiant (UI) project to rely on the DarkRadiantCore project, but I deliberately chose not to do that since I want the builds to work in parallel - and technically it wouldn't be true, the UI project really doesn't need the core project to compile and link. Setting the dependency would make the solution wait for the largest core project to have finished before it starts building the second-largest project - waste of time. I always hit Ctrl-Shift-B to build the solution, and I figured everybody would do the same - but I might be wrong on that assumption!

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!