trefoilknot on 11/12/2018 at 14:52
I've run into a weird issue with DromEd. Right now, my map optimizes (albeit with some protestations). I've got a big chunk of the map, which is entirely separate from the rest, that I need to move away from the origin. If I multibrush the whole thing, and translate it by nice round powers of two (e.g. move it 256 units in all three directions), the map stops optimizing. What could cause this?
Some important points I've already looked into extensively:
1) No brushwork is getting left behind
2) It's nowhere close to any boundaries
3) It doesn't collide with any other brushwork, either in it's original location or the new location.
What could cause optimization to be location dependent?
Thanks, all!
Yandros on 11/12/2018 at 14:55
I'm not sure, I don't think I've ever run into that before. You can probably solve the origin being in the gamespace issue in other ways, though. For example, when I was given Deceptive Perception 2, the origin was in the starting room of the warehouse. So, I made a large crate out of solid (and hollowed out the inside) around it to avoid the player ever seeing it.
Unna Oertdottir on 11/12/2018 at 14:59
Always snap the brushes to the grid after multibrushing.
hilight_check_snap 1
hilight_do_snap 1
trefoilknot on 11/12/2018 at 15:40
Unfortunately the origin is about 18 feet off the ground in an outdoor courtyard. I haven't found any reasonably aesthetic way to encase it.
Can multibrushes become unsnapped even when translated purely by typing in a translation? I know click and drag is disastrous, but I thought typing in a translation was safe.
Yandros on 11/12/2018 at 15:49
Not typically but it's possible and wouldn't hurt to snap after moving them. There is a config var which forces multibrushes to snap I think, but it's simple enough to just translate it, un-multibrush and snap the whole map before trying to optimize.
trefoilknot on 11/12/2018 at 16:46
I'll give it a shot after work and report back—thanks, you two!
trefoilknot on 11/12/2018 at 23:38
Well, the verdict is in:
those two commands solved the problem. Curiously, the 'unsnapped' brushes were exactly at integer coordinates and rotations, yet still somehow 'unsnapped.' Even re-entering the coordinates manually (to address any potentially 0.00001 that were obscured in the dromed window) wasn't enough to 'snap' them.
I guess being 'snapped to the grid' is more than just existing at the well-rounded locations and orientations? What does it mean, in a practical sense, for two brushes to have the same coordinates but differ with respect to their 'snappedness'? Is such a distinction intentional? Or just one of the many quirks of the beast?
At any rate, my [current] issues are solved! Many thanks to you both!
Unna Oertdottir on 12/12/2018 at 09:35
Some tutorials mention that even brushes with exactly typed coordinates are not snapped to the grid. You need to snap it with your mouse or use the command.
In this case it's a multibrush issue. Multibrushes are snapped if you enable vbrush_snap but rotated/modified multibrushes never snap to the grid. You need to release the brush (ctrl+d) and use the command.
You can also put the command into a cmd file.
There's already GridSnap.cmd in DromEd toolkit but this is not good for rotated multibrushes
hilight_check_snap
hilight_do_snap
play_schema dinner_bell
Edit it like this:
hilight_check_snap 1
hilight_do_snap 1
play_schema dinner_bell
"1" means: all brushes
john9818a on 12/12/2018 at 09:57
Quote Posted by trefoilknot
Unfortunately the origin is about 18 feet off the ground in an outdoor courtyard. I haven't found any reasonably aesthetic way to encase it.
Can multibrushes become unsnapped even when translated purely by typing in a translation? I know click and drag is disastrous, but I thought typing in a translation was safe.
Maybe you could make a small bell tower or monument that encases the origin.
