Room brushes with portal centers outside the world have been hilighted. - by LarryG
LarryG on 18/10/2010 at 15:29
I understand how to fix this thanks to Yandros asking and R Soul answering back in 2003.
Quote Posted by R Soul
Room brushes with portal centers outside the world have been hilighted means that the centre of the intersection of the RoomBrushes is in solid.
When you select one of the RBs and click ShowSel, the blue line joins the centre of the RB to the centre of any overlapping RB
via the centre of their intersection.
I don't know if there is a nice dromed command to take you striaght to this intersection, but in game mode you can use show_player_room, and you can see the blue line in 3D.
If you don't want to adjust the terrain (ie to move the solid out of the way), you could just move one of the RBs a little, then resize if necessary. This would move the centre of the intersection.
. . .
The intersections of the indicated room brushes
are clearly in solid space, so this is a legitimate thing for DromEd to complain about, I guess.
But what I don't understand is why, all of a sudden, dozens of room brushes that have not changed since they were created are getting flagged when none were flagged before? The surrounding terrain has not changed and neither have the room brushes.
I did fix a room brush that had a center inside two other room brushes (a doorway between two rooms) by shrinking both of the problematic rooms' room brushes so that they did not overlap the center of the doorway's room brush. Could that one error have masked all these other errors? That is, does DromEd not report on this error until all of the "Room brushes with centers inside other room brushes have been hilighted" have been resolved?
Inquiring minds want to know!
qolelis on 18/10/2010 at 16:26
I had that happen to me a lot while roombrushing TSWTSW, so yes, from my experience, room brush errors can mask each other.
Also, the center of the shared volume (center of the intersection volume) of two overlapping room brushes cannot be inside a solid either. That also happened to me a lot while working on TSWTSW, because of its somewhat nontraditional layout.
darthsLair on 18/10/2010 at 21:22
Out of curiousity, I always open up each fm I play in dromed to learn more. I have noticed that alot of fms show bad room brushes, but it doesn't seem to effect sound propagation. Isn't this a more common problem, similar to " object not in room" type error.
To avoid this problem recently, I have started using 2 and 3 room brushes per room so that the centers of the room brushes are in center of the room. It seems like a waste, but sound propagation seems to improve with multiple brushes. This could also be my cornball way of thinking too !:cheeky:
Telliamed on 19/10/2010 at 22:08
That's just Dromed being paranoid. A brush can be hilighted but still propagate sound. You can treat the warning as a hint of where to look for potential problems.
Also, there's two phases to check_rooms. The first, checking for room centers in solid space or overlapping, is always an error and should be cleared. The second, portals out-of-world, can occasionally be ignored. In particular, Dromed gets bitchy when you rotate room brushes, which is where I usually see the false positives.
Yandros on 20/10/2010 at 00:11
That's good to know, thanks. Where've you been lately?
LarryG on 20/10/2010 at 19:58
Yesterday, just as I was typing a reply to this thread, the power pole one house down from me was struck by lightning. Fried my UPS system, but all the computers and electronics came through just fine. Picture power lines down sputtering and hissing in the street, fire trucks, street taped off with yellow warning tape, gawkers, and the day progressively darkening, with occasional lightning flashes in the distance. So I lit a fire in the fireplace, and watched real flames lick at real wood and thought I should probably tweak the SFX on my fire logs some more once I get DromEd back up. :laff:
In any event ...
So far, all of the problematic room brushes have been the result of using auto-roombrush on large rooms or long hallways, resulting in excessively large room brushes which inadvertently and unintentionally overlapped other room brushes. While sound worked fine, I suspect that it was propagating where it shouldn't have, and fixing them will tighten that up.
Yandros on 21/10/2010 at 00:39
I've gotten in the habit in recent years of immediately adjusting the size of a roombrush created with Shift-Insert so it is only slightly (0.2-0.4) smaller than the airbrush. It's too bad you can't bind that keystroke to be a + n instead of a % increase.
What you're doing is a pain but worth it.
LarryG on 21/10/2010 at 16:29
I never got that to work. So I'm stuck with the % increase and then manually resizing. Besides, 0.5 is too loose for me. I would still be having the problems outlined above with that amount of overlap. If it were 0.25 or better yet 0.125 ... then I might go back and try to make the command work again.
Ricebug on 21/10/2010 at 23:05
Since we're on the subject, should I completely finish and fine-tune a mission and THEN set the EAX for each RB? I find it most annoying that DromEd shifts the EAX params if you delete and add RBs.
In another FM, I had made a "trigger the mission's end" RB. So I'm chugging along, plopping in rooms and RB-ing them as I go. Next thing I know, every friggin' RB is an "end level." :mad:
