greebo

Not much I can change about the docking "magnetism", but as a workaround you can hold down Ctrl or Alt to prevent docking of moved windows. That should go to the bugtracker please, then I'll look into it for the next release.

It's trying to create the folder "F:/.../maps/", that's the point where DR was by the time you created the dump. Could there be anything that might block the application from creating that folder?

You can't even end the process? That doesn't sound like DR is at fault, ending a process is a windows thing. Next time it stalls, I'd be interested in a memory dump, to see where it hangs.

Can you check out the latest release 3.6.0, there it should be possible to undock and close that property panel. With the property panel closed, you can hit N to toggle it on demand.

DarkRadiant 3.6.0 is ready for download. What's new: Feature: Selection Focus (Ctrl-F) Feature: Add Radiant.findEntityByName script method Feature: Media Browser shows a thumbnail preview when selecting folders Feature: Map is remembering layer visibilities between loads Fixed: ModelDefs are shown in T-pose Fixed: Patch vertices are the wrong colour Fixed: Shader Clipboard source gets cleared on 'copy shader' operation Fixed: Nodes of hidden layers are still visible after loading the map Fixed: Can't close properties window Fixed: Merge Action rendering is broken Fixed: After using ToggleMainControl_Camera, the center panel is grey after restart Fixed: When using ToggleMainControl_Camera, arrow keys cannot be used to move the viewer Fixed: Property Panel not remembering undocked/closed tabs Fixed: Texture Tool not updating during manipulation Fixed: Orthoview ignores filters for surfaces in models Fixed: Blue dot when selecting one face removed Tweak: Conversation Editor: double-click opens selected conversation Tweak: Preference option to disable drag select in camera view Tweak: ESC key should clear the resource tree view filter text Tweak: New layers function: tooltip popup getting in the way Feature: Selection Focus (see video) Windows and Mac Downloads are available on Github: https://github.com/codereader/DarkRadiant/releases/tag/3.6.0 and of course linked from the website https://www.darkradiant.net Thanks to all the awesome people who keep using DarkRadiant to create Fan Missions - they are the main reason for me to keep going. 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. The list of changes can be found on the our bugtracker changelog. Have fun mapping!

I can't reproduce this. Anything you need to do before this happens? Any layout/camera adjustments that I might not have on my end?

Hm, if it's not too much work, maybe you could download some of the older versions and see where it started happening?

10 mInutes, seriously? Any hint on when this started to happen? Everything else is working without lag, once it finally started?

Thanks. It appears this bug is fixed in a later wxWidgets version, but the workaround is fine too. I merged your latest master into mine.

The focused elements are not necessarily from the same single group, right now any selection can be focused on. When cloning or creating objects adding it to a group might not be what's intended. Of course, selecting just a single group would make that desirable, not sure if the logic determining that would be a nightmare or not. This would be a separate feature request. It's similar to the reparent primitives or merge entities commands. There'll be need for some conventions when having more than one group selected. I see the point, and yes, it's possible to disable drag-selection for cam views. Separate feature request of course.

D'oh, sorry yes, of course I meant Ctrl-Tab. I'll wait a bit before doing anything, but I think it's desirable. Since the whole point of entering focus is to manipulate it in the orthoview, it makes sense to align the view to that area.

Probably not, but a couple of people around here have. I can upload it to my google drive if people don't want to create a Github account. That is something I need to look into, probably the user-defined input.xml is interfering, I have to check out how to properly override that without disrupting all the user bindings. I also thought about adding a button to the top toolbar next to the selection modes. As a workaround I can suggest pressing Alt-Tab since that will re-focus the ortho views to the selection OR the focus area if nothing is selected. So hitting Ctrl-F and then Alt-Tab should bring the ortho view into place. What about aligning the ortho view automatically to the focus once activated? Is that always desirable? I also have to make the involved colours configurable and come up with usable default colours for every colour scheme DR is shipping. I'm using the Maya/LW colour scheme since forever, and that's probably why I didn't notice it being less than helpful in Super Mal.

I got a feature in the works, allowing to select and manipulate only "focused" items, which should hopefully be useful for manipulating grouped items without having to disband the group. There's a demo video here: https://www.darkradiant.net/images/videos/selection_focus.mp4 It works like this: You select some items in the map. It doesn't matter what it is, it can be a group or many groups or just two unrelated brushes. Hit Ctrl-F to enter focus mode (the command is called "ToggleSelectionFocus" if you want to bind your own shortcut) Your actions will be restricted to just that selection You cannot select other items that are not in the group (unless you use Layer or Filter selections, or Invert selection) You'll get a visual indication about the focused items in the ortho view Grouping information is ignored while in focus, you can select single parts of any group You can select, move, rotate, delete, edit vertices etc. Hit Ctrl-F again to exit, or (maybe more intuitively) hit ESC until you left the focus The previous selection (before entering focus) is now active again, you can proceed manipulating that I'd appreciate if you folks could have a go and try it and then give feedback about it. There's no release yet, but you can grab a portable release from Github: https://github.com/codereader/DarkRadiant/actions/runs/3403010325

I would have assumed that the assertion wouldn't fire if existingIndex == -1 since that is also < tab count. At any rate, if existingIndex == -1 at this point in the code either the addControl or findControlIndexByName seem to have failed. Can you step through it and figure out what goes wrong? Is addControl failing?

That's a more specific stacktrace, I'd be interested in the message that g_log_structured_array() is receiving, can you see it somewhere in the local variable/stack? It seems to originate from gtk_scrolled_window, but maybe that's only used somewhere internally. Can you also try to run the application with an environment variable set, maybe it prints something: G_MESSAGES_DEBUG=all ./path/to/darkradiant

You can try PropertyNotebook::undockSelectedTab() - that's in radiant/ui/mainframe/PropertyNotebook.cpp

I think this exception is nothing unusual, these are all caught in the cmd::Argument class. (Not that this design is particularly good, but it should not cause a problem, let alone a shutdown). Is there anything else following this part? Any messages in the .log file?

The DR log file is all there is to see, I'm afraid. In case of crashes it will attempt to write some trace lines to the file, so maybe it contains something. DR doesn't have any log verbosity to configure like TDM. Otherwise it's just gdb and you, if there's no SIGSEGV or something recorded by gdb, then it's not a regular crash, maybe it's an exception - in which case there should be some log output in darkradiant.log too.

Can you get hold of a backtrace of that crash?

Ok, please report that (along with the distro you're using), I'll try to look into it. (Sorry if I'm seemingly asking all the time about your Linux configs, I just can't keep track who's using what combination).

Can anybody of the other folks running Linux confirm this troublesome rendering issue?

@AluminumHaste@SeriousToni This should be fixed in source now. The automated build is running on Github, you can grab a portable package when the build is done (scroll down to the Artifacts section): https://github.com/codereader/DarkRadiant/actions/runs/3358810112

Wow this looks like any openGL rendering is broken altogether. Which distro/window manager configuration is that?

I have doubts about whether everybody would like that. I myself would find the 2D view more important than the camera, most of the time I'm working on 2D. But I'm open to hear other people's preferences. Though it's possible to add some entries to the main menu, assign default shortcuts, or add an entry to the 2D view's context menu. To make it easier to find the "make camera main" option.

One can hold down the Ctrl or the Alt key to prevent docking of a floating window while dragging it, but that's of course not the full solution. If you report the issue on the tracker, I'll see to it that the property panel can be closed again. A shortcut bringing up a control that is docked as a property panel tab should then make the window appear again (or close it if it's visible).