greebo
-
Posts
16735 -
Joined
-
Days Won
51
Posts posted by greebo
-
-
1 hour ago, LDAsh said:
I PM'd you the .DMP file, there is no DarkRadiant.log ever created.
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.
-
- Popular Post
- Popular Post
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!
-
7
-
7
-
On 11/8/2022 at 12:00 AM, joebarnin said:
However, I did notice something in this version of DR. The Camera view does not behave as expected. Examples:
- In Camera view, the ESC key no longer deselects. In ortho views, ESC deselects fine, but in the Camera window, it doesn't do a thing.
- Undo doesn't seem to redraw in the camera window either.
- Selecting an object in ortho view doesn't highlight it in the camera window.
Are these known issues?
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?
-
On 11/10/2022 at 2:31 AM, thebigh said:
I've been having trouble getting version 3.5 to run properly on Linux. As of a few updates ago, it takes up to ten minutes to start, equally long to load even the smallest map, and then lags like crazy in the 3D view. Quitting DR takes another few minutes and then it leaves keyboard input suppressed entirely- I need to log out to be able to so much as type into a terminal again. I'm not sure what I'm doing wrong here. I'm running on Linux Mint 20.2 Uma 64-bit, MATE 1.24.0. DR isn't producing any log files or giving me any error messages that might help me figure out what's going on.
10 mInutes, seriously? Any hint on when this started to happen? Everything else is working without lag, once it finally started?
-
On 11/8/2022 at 8:51 PM, OrbWeaver said:
This does seem to be the cause of the problems. Replacing all calls to FindPage() with GetPageIndex() fixes the issue for me.
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.
-
42 minutes ago, Frost_Salamander said:
with selection focus on, grouping information is ignored. Makes sense as you want to manipulate the individual objects. But what if you want to clone one of the objects and include it in group (if it is in fact a group you are focused on)? Say you are working on a staircase and need to add a couple more steps. Could cloned objects just be automatically added to the group?
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.
44 minutes ago, Frost_Salamander said:I kind of wish there was an 'add to group' or 'merge groups' command in the mouse context menu. Unless you want a bunch of nested groups, you need to select all the objects, then 'ungroup' followed by 'group' to do this.
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.
46 minutes ago, Frost_Salamander said:(probably a separate thing but will ask anyways): Is it possible to disable drag select in the camera view? Frequently I'll be selecting objects one-by-one in the camera view to add to a group. The mouse will drag very slightly and all of a sudden loads of stuff in the background will get selected. You then have to press escape and start all over again. Gets tedious.
I see the point, and yes, it's possible to disable drag-selection for cam views. Separate feature request of course.
-
Just now, Frost_Salamander said:
Did you mean Ctrl-Tab (next view)? Because that worked. Alt-Tab for me switches between windows (in Windows 11).
D'oh, sorry yes, of course I meant Ctrl-Tab.
1 minute ago, Frost_Salamander said:Yes this is what I suggested above ("..automatically focus the ortho view onto the focus group"). I think I would want that - but maybe need to find out of everyone else would want that as well.
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.
-
1
-
-
1 hour ago, Frost_Salamander said:
I couldn't download the release from Github until I signed in - does everyone have a Github account?
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.
1 hour ago, Frost_Salamander said:ToggleSelectionFocus wasn't bound to Ctrl-F by default - it was unbound.
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.
1 hour ago, Frost_Salamander said:When you enter selection focus mode, because all the colours change to white/black it sometimes hard to find the focus group in the ortho view if there is a lot of stuff in the map. I see the light highlighting around it, but it doesn't help that much. If it's an existing group of items I want to manipulate, I would probably select it using the camera view, and manipulate it using the ortho view, meaning I have to find it. Some suggestions to help might be to change the focus group items to a brighter colour (blue/red/green?), or automatically focus the ortho view onto the focus group. I'm using 'Super Mal' colour scheme as well which is grey background, so maybe that combination of black/white/grey doesn't help.
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.
-
- Popular Post
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
-
1
-
5
-
On 11/2/2022 at 9:17 PM, OrbWeaver said:
This is the actual line of code which fails in PropertyNotebook.cpp. It seems that existingIndex is actually -1 here.
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.
-
10 hours ago, Baal said:
But Darkradiant crashes when I undock textures, open the texture tool or the light inspector.
Can you get hold of a backtrace of that crash?
-
22 minutes ago, Baal said:
But Darkradiant crashes when I undock textures, open the texture tool or the light inspector.
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?
-
14 hours ago, AluminumHaste said:
@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
-
1
-
1
-
-
Wow this looks like any openGL rendering is broken altogether. Which distro/window manager configuration is that?
-
1 hour ago, SeriousToni said:
Maybe you could also make the 3d camera standard for the main view instead of the 2d. The solution to look into the keys and setup a new hot key is not so well for newbies especially. (or for stupid people like I am)
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).
DarkRadiant 3.6.0 released
in DarkRadiant Feedback and Development
Posted
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.