Jump to content

greebo

Root
  • Posts

    16711
  • Joined

  • Days Won

    47

Posts posted by greebo

  1. Changing the project/game setup and paths is a pretty massive change from DR's perspective. Almost everything needs to be re-initialised when setting the paths, which sometimes takes longer than a clean restart. (For similar reasons, the TDM engine itself needs to be restarted completely when you install a FM.) DR is able to make that leap while keeping the same process alive, but it's a very expensive step, and it's better to restart to clean up any resources that are left behind when switching configs (for instance, all defs that have been loaded from another map/project are kept in memory.)

    From a design perspective, I'd rather not have loading a map implicitly change the whole project setup. At some points it might not be deducible or even wanted to have the paths changed on map load.

    When regularly switching between projects, a possible help might be to create separate DarkRadiant shortcuts, passing the FM project path as argument to DarkRadiant.exe.

     

     

    • Thanks 1
  2. 4 hours ago, datiswous said:

    This issue still remains in 3.6 (under Linux) . If I remember correctly this doesn't happen in Windows (10). Should I create a bugreport in the tracker?

    Since it only affects the Model Selector window, I might have fixed that a few commits back. The Model Selector didn't have a parent window set (since it is initialised very early during startup), that's why it had also been possible to focus on the main window even with the Model Selector open.

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

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

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

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

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

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

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

×
×
  • Create New...