load_group_ex is a new dark thing though right? . . . I haven't been roughing it all these years with load_group for no reason have I?
All the DromEd basic menu options are explained in the .\docs\DromEd Basic Menus Explained.rtf. You might find something useful or interesting in there you might want to add to your own menus.
load_group_ex is a new dark thing though right? . . . I haven't been roughing it all these years with load_group for no reason have I?
Yeah, it's Newdark only.
I'm glad to be of service, and good luck with your mission!
As for me, I haven't touched DromEd in three years now.
I have at last (many months after starting to use Dromed) got the grid and Dromed Basic's numpad move/scale tamed! It'd been bugging me for a long time that the numpad commands (which I use most of the time) used a different scale than the grid (which applies when I move/scale brushes in the 2d views), and that I had to use the mouse to change the grid, but < and > to change the numpad scale, which also zoomed annoyingly. But I'd just kept working around their quirks as best as I can. Now I have them under control!
Effectively there's only one scale now, which adjusts the grid and the numpad scale in sync. I press < to reduce the scale, and > to increase the scale. Neither key affects the zoom of the 2d views at all. As long as I don't touch the grid size in the GFH, they remain in sync, and I have the same grid scale applied whether I shift/ctrl+drag in the 2d views or use the numpad/ctrl+numpad to nudge my brushes.
I did this with two new .cmd files:
Code:; ./Cmds/GridUp.cmd global_scale 1 zoom_all 0.5 grid_scale 2.0And corresponding binds:Code:; ./Cmds/GridDown.cmd global_scale 0 zoom_all 2.0 grid_scale 0.5
To make sure that both scales start in sync, I added this to ./Cmds/StartUp.cmd:Code:edit bind < "run .\cmds\GridDown.cmd" edit bind > "run .\cmds\GridUp.cmd"
And finally, I had for a while had "translate_by_grid" set in Dromed.cfg so that numpad translation (but sadly not scale) respected the visible grid, but with these new settings it's probably redundant, so I've turned it off again.Code:; start with grid scale 13 grid_abs_scale 0.5
I am now a much happier builder!
Instead of manually finding and correcting Joint Positions for locked doorhandles on unlocked door, the command fix_my_locks does it automatically.
EDIT: sadly, this command is actually much less reliable than it first appears, and depends on the status of a few other properties that are harder to track down. It is usually better just to manually adjust Joint Position degrees.
Last edited by DirkBogan; 10th Dec 2019 at 00:56.
Great find, DB! I am so happy to learn of that command!
"show_sounds"
this toggles blue circles at the source of all sounds audible to the player.
Very useful for visually identifying how far the radius of an ambient actually extends in-game, and tracking down bad sound propagation through walls.
Bump for an embarrassingly late discovery: As is well-known, when dragging around an object's position or orientation, you'll only see the object's bounding box in the 3D view until you release the mouse. BUT, when in multibrush mode, objects will update in the 3D view in realtime as you drag around, even if it's only a single object. This could be very useful for doing fine positioning, like leaning things up against walls, etc.
In my defense, everything I've ever read about multibrushing says DON'T drag stuff around with the mouse, enter coordinates in the GFH instead.
Yeah dragging a multibrush with the mouse completely ignores gridsnapping. Would be fine with objects though.
It's not even the grid snapping that's the main issue. Apparently dragging stuff around in multibrush mode is performed as cumulative move operations, rather than current offset from origin, so if you drag a bunch of brushes around, then go into the GFH and zero all the coordinates, it won't put everything back exactly where it started.
i dont see this here. whether in multibrush mode or not, the 3d view only redraws the wireframes in the 3d view (so the object is still visible in its starting position while its bounding box wireframe moves), until i release the mouse button.
i would love it if it would redraw continuously!
Apparently I spoke too soon. Objects only redraw in realtime if in multibrush mode AND one or more of the selected objects is scaled.
WTF.
I just noticed that when holding shift, alt, or ctrl to modify a brush, we can let go of the key and the click and drag action will continue. I'd always assumed we had to keep holding the key. I've been doing some complex terrain work, and still have more to do, so it could prevent a bit of fatigue building up.