Sperry on 11/1/2021 at 10:41

---

I don't know if anyone has posted this, but I could totally use a feature that would automatically implement the most optimized "Time" for each brush, without changing the in-game geometry, to get the lowest cell-count with just a click!

Renault on 24/1/2021 at 07:26

---

No idea if anything like this is technically possible, but I would love to have some way to tidy up the players inventory. A key ring for all your keys, a notebook for all your readables, etc.

DirkBogan on 25/1/2021 at 00:30

---

There are always edge cases, but the general rules for time efficiency are:
1) Lowest time for big air brushes, especially ones with lots of solid inside them.
2) Large solids after, but still early
3) Small air and solids later, though small air can often have big savings if made early.

Air brushes are 'usually' a bigger source of savings. For example, I recovered 3053 cells by changing only six brush times in Builder's Paradise using the following method:
a) set time to 0
b) if no savings, set time to 100
c) if no savings, set time to 1000
d) give up or try 2000, 3000 etc.

You can always just try swapping times on single brushes in a particularly expensive area. There is no substitute for brute force, unfortunately. It's usually safe to do these with area brushes (lower cell count locally is almost always lower cell count globally) but rarely a lower local count will produce a higher global count.

Always be careful not to unintentionally cause visible geometry changes when doing this. To avoid accidental carving, it's best to have big airbrushes as early as possible anyway.

EDIT: the best method for solids is to try setting it to either a very early time (100 is usually safe to avoid unwanted carving) or To End'ing it, and seeing if either is cheaper than its original time. Oftentimes it will be staggeringly more expensive either way, so always keep track of you cell count before and after. This goes for any change.

PinkDot on 25/1/2021 at 16:17

---

Let's face it - getting automatic optimization of time of brushes is a close to impossible task. There's too many gray areas plus results would be hard to predict, so as Dirk is saying, it often needs to be brute-forced.

What I'd like to see instead would be more control over the portalization process. Namely - order of brush planes for cells splitting. For example, having a floating solid cylinder in an air cube, I'd like to choose, whether the top/bottom faces would be splitting the cube first, or whether sides should go first, and then the top and bottom. Or any arbitrary order really. This could be useful, if we had for example staircase in this room as well - I could observe an impact of different cuts of cylinder on the cuts caused by the steps and choose the best scenario.

vfig on 27/8/2021 at 12:15

---

okay, heres a grab bag of more interface improvements that i would love to see:

scaling rotated brushes

it would be helpful if resizing rotated brushes, whether by ctrl+dragging or brush_stretch commands, would operate in the same world space reference frame as they do for unrotated brushes.

for example, ctrl+dragging in the top viewport should always scale the worldspace x and y axes. similarly, "brush_stretch 5" and "brush_stretch 2" (ctrl+keypadplus/ctrl+keypadminus in many keybind sets) should scale along the worldspace z axis.

now i appreciate that this is inappropriate for brushes that have been rotated by non-multiples of 90 degrees, as it would cause skewing. in such cases i suggest the brush be treated as though it were in whichever 90-degree-rotations-only reference frame that it is closest to; for 45 degree angles, a consistent "rounding up" or "rounding down" choice should be made when selecting the reference frame. for example, a sideways-ish pyramid (Bank 73 degrees), when scaled in the top viewport, would only change its Depth and Height.

this would be of enormous benefit when building with wedges, which are very often rotated by multiples of 90 degrees on one or more axes; and also of great benefit when building organic-feeling terrain.

obviously for compatibilty this should be have a config option to enable it.


hilights

it would be useful to have a few more commands for hilights:


* hilight_brush_off <int> // unhilight current (0) or brush_id
* hilight_brush_toggle <int> // toggle hilight of current (0) or brush_id
* highlight_the_multibrush // hilight all brushes in the current multibrush
* hilight_render_inverse [int] // draw only unilighted brushes (1) or all brushes (0); toggle if parameter is omitted


(note the inconsistent spelling of hilight in these commands is consistent with the existing commands ive patterned these after.)

hilight_render_inverse would be of particular value to me for enabling an easy "temporarily hide this" feature, similar to pressing H in Hammer, DarkRadiant, and Blender works.

future workflow improvements (though i am not proposing this right now, as it would need more careful thought) could include enabling the hilight bits to work as pseudo-layers, with additional parameters to the hilight commands to specify which bit to affect; configs for different colours for the different hilight bits; the option for some bits to be drawn darker when distant as normal brushes are; and so on.


multibrushes

some improvements to interacting with multibrushes would be very welcome. the main problems i encounter are:

* i cannot tell in the wireframe which brushes are part of an non-current multibrush and which are standalone brushes.
* the existing shift-click does double duty as "make this the current multibrush" and "add this brush to the current multibrush", which can result in accidentally creating multibrushes when meaning to select an existing one.
* when precision_select_default is on, trying to remove a brush from the current multibrush in the 2d viewports when there are overlapping brushes often results instead in accidentally adding additional brushes to the multibrush.
* its hard to keep track of multiple multibrushes in a mission.
* importing multibrushes results in off-grid brushes far too easily!
* rotating multibrushes results in off-grid brushes far too easily!!
* scaling multibrushes results in off-grid brushes far too easily!!!
* scaling multibrushes just gives up entirely for rotated brushes, even those only rotated by multiples of 90 degrees.


in general i would love to see a config option that makes multibrushes behave a little more like "groups" in many vector editors. the specific suggestions i think would enable this:


* a config option to draw unselected brushes that are members of a non-current multibrush in a different colour, enabling multibrushes to be distinguished in the viewports
* a second config option that, when enabled, would mean clicking or ctrl+clicking with the mouse, if the selected brush is a member of a multibrush, would make that multibrush current.
* a third config option (or possibly the same as the 2nd) that would mean shift+clicking a brush would toggle it as a member of the current multibrush without making it the selected brush.
* when both the 2nd and 3rd config options are enabled, shift+clicking a brush that is a member of a non-current multibrush would toggle as members of the current multibrush all the brushes in that other multibrush, not only the clicked one.
* a new command to affect whether the selected brush is in the current multibrush: multibrush_selected [int] // 0: remove from multibrush; 1: add to multibrush; omitted: toggle
* a config option that, when enabled, uses the nearest grid-integral position to the selected brush as the pivot for rotating, scaling, saving, and loading multibrushes. this would make
* a change that when scaling a multibrush, the same behaviour as in "scaling rotated brushes" above is applied to rotated brushes.



links

a couple of suggestions to make working with links easier and more capable (especially with the multibrush improvements above):


* an optional second argument for link_multi that would specify the flavor and avoid the dialog popup
* an optional third argument for link_multi that, when the flavor was ScriptParams, would specify the link data.
* an optional third argument for link_chain that, when the flavor was ScriptParams, would specify the link data.
* a new command link_fan <flavor> that would create links between the brushes in the multibrush in a fan pattern, i.e. adding links from the first object to each of the other objects. for consistency with link_multi and link_chain, the first object added to the multibrush should be the origin of the link. for example, this would make it easier to connect a single switch to several lights.


the idea behind the link data arguments is to add hotkeys or menu items for "link_multi ScriptParams @@" to prompt for the data parameter. it is possible that the link data arguments would also be useful for other flavors of link than ScriptParams, if there are other flavors with a single, simple data value that would be useful to either script or prompt for with @@; off the top of my head i cannot think of any.

i know all this is a lot to ask for, but i can dream, cant i, of specific changes with practical workflow benefits? :cool: