Jump to content
The Dark Mod Forums

greebo

Root
  • Posts

    16733
  • Joined

  • Days Won

    51

Posts posted by greebo

  1. 1 hour ago, cvlw said:

    Usability:  the windows risk docking quite aggressively even if not intended.  I am liking that the properties parent window holds all of these child windows in one place rather than in separate windows.  Perhaps make docking the parent Properties window optional?  I like moving this window around and even moving partially off the screen if I don't close it.  If I move it too far in any direction, it gets sucked into a dock.

    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.

    1 hour ago, cvlw said:

    Actual bug:  the sizing of the objects within the Entity window (N key) resets when closed and needs to be dragged back out every time it is opened.  This is the area shown in the attached screenshot.

    That should go to the bugtracker please, then I'll look into it for the next release.

  2. 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?

  3. 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?

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

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

    • Like 1
  6. 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.

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

    assertion.png.1a36203343673e9c6487f7e92f422c43.png

    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?

  8. 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
  9. 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. 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.

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

×
×
  • Create New...