[[ 2.10 ] New Frob Shader]

36 minutes ago, OrbWeaver said:

To be honest I have no idea how you'd even fix this. Presumably the problem occurs when the virtual box expands through a thin surface and captures a frobbable object on the other side, but you'd need a lot of additional line checks to make sure that some part of the object was actually visible to the player, which would complicate the code and probably impose a performance cost.

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.

[[ 2.10 ] New Frob Shader]

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.

[Connection to TDM with automation]

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.

42 minutes ago, stgatilov said:

Is it worth exposing game connection toggles/buttons for console?

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.

42 minutes ago, stgatilov said:

What about Python scripting?
Can it generate an event? Can it run a command?

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/

3 hours ago, stgatilov said:

What's the difference between command and statement?

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.

[Connection to TDM with automation]

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.

[Wishlist For Darkradiant]

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.

[(POLL) Normalised texel-scale when applying new textures?]

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?

[DarkRadiant 2.13.0 released]

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.

[DarkRadiant 2.13.0 released]

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

[hide_distance broken again?]

5 minutes ago, roygato said:

I would say you do, when the punishment for that behavior is nothing.

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.

[hide_distance broken again?]

4 minutes ago, peter_spy said:

After several pages of patient discussion, posting relevant links and referring to facts, which he ignored entirely, since his subsequent responses were still the same make-believe? Yes, unfortunately.

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

++numberOfKilledThreads;

 

 

 

[hide_distance broken again?]

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 released]

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!

[DarkRadiant 2.13.0 pre-release test]

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.

[Connection to TDM with automation]

21 minutes ago, stgatilov said:

Yes, but I'd like DR users to have this GUI before Spring 2022

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...)

[Connection to TDM with automation]

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

Quote

Please notice that while 3.1.0 is officially a “development” version because it is not fully compatible with 3.0.x, the list of backwards incompatible changes is very short, so you shouldn’t have any problems updating to this version from 3.0.x in practice, and you’re encouraged to try this version out and use it in production in spite of its odd version number.

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.

[Exceptions in DarkRadiant]

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.

[Exceptions in DarkRadiant]

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.

[(POLL) Normalised texel-scale when applying new textures?]

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.

2 hours ago, LDAsh said:

If the "Default Texture Scale" setting in 'Preferences' isn't supposed to mean anything, then why would it even be there anymore?  Why was it ever there in the first place?

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.

[Connection to TDM with automation]

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.

[Connection to TDM with automation]

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.

 

[Connection to TDM with automation]

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);
    ...
}

 

[Connection to TDM with automation]

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.

[Connection to TDM with automation]

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.)

[Ability to select all entities with the same model]

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

[Which features of Connection menu do you use?]

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.