Caradavin on 6/8/2014 at 08:57
(
http://www.ttlg.com/forums/showthread.php?t=133626&highlight=room+brush+with+portal+outside) Similar to this issue here, I have been editing this map almost every day for years, and this issue never happened. Suddenly, I get bombarded with this huge list of room brushes that have centers in other room brushes as well as room brushes with portals in solid rooms. I fixed about half of them, but all I did to "fix" them was move them away and then back to where they were. Is this some type of glitch or something? I don't understand how these brushes are suddenly being pointed out when I've done nothing different and the brushes have been in place for months now. In fact, I've not needed to add any room brushes for quite some time, so they are all old placements. Why would Dromie choose now to tell me this when it didn't before??
fibanocci on 6/8/2014 at 10:25
Maybe you should examine you map before and after that incident. For example, load an older cow and run Build Room Database.
What has changed? Maybe you snapped a lot of brushes to the grid-->terrain brushes change a bit. Did you update DromEd to another version?
Remember what you did.
R Soul on 6/8/2014 at 13:25
Bad roombrushes are highlighted if check_rooms is is in user.cfg. Perhaps you didn't have it before now. Another cause of the problem could be the accidental cloning of roombrushes. If that's the case you should get the highlight every time you rebuild the rooms DB.
In post #4 in that link Telliamed says "there's two phases to check_rooms". Only one type of error gets highlighted, so maybe you had one or two brushes with the first kind, you fixed them and then a load of errors of the second kind were highlighted. Also note what he says about rotated roombrushes causing false positives. You can easily spot ones rotated by, say, 45 degrees, but check for 90, 180 etc. Also check for cylinders that have been roombrushed. If you make a tunnel the cylinder could have a pitch of 90, as will the room brush if you use shift_insert. When I'm in a situation like that I un-rotate the roombrush and swap the dimensions to make it fit again.
Caradavin on 7/8/2014 at 09:56
Well, I checked all the blue highlighted brushes and I'll be danged if it wasn't absolutely correct in that they were bad. I am glad this happened, I would hate to imagine what would have happened in final build :laff: thanks, new dark. I did notice, though, that it gave me brush ids that were not accurate to the actual brush ids. If I had been going by the brush ids given in the error messages, then I would have been fixing the wrong brushes, of course, this doesn't really matter as the highlighting gets rid of any confusion. I'm guessing I have check rooms now when I originally didn't. Thanks for the help; I have learned new things.
Xorak on 7/8/2014 at 20:50
The error does give the correct brush ids. Make sure you're looking at the black number underneath Time, and not the current time number of the brush.
john9818a on 12/8/2014 at 03:45
If you mean the two objects are in solid space, they won't make any sounds in solid space regardless of whether they are in a roombrush or not.
The "failed to load palette/interface synch" line can be ignored. It may have been specific to LGS's set up but isn't needed at all for Thief to work properly.
Caradavin on 12/8/2014 at 08:01
No, the objects are not in solid space. They are lights, on the ceiling, in a roombrushed room. They are those Lost City lights that brighten when one enters the room and dims when they leave. For some reason, I keep getting this error message that they are not making on/off sounds. I have fixed everything else but this one small issue (and the palette thing; I figured I could probably ignore that, but thanks for confirming it :D ) I don't understand what is causing it.
fibanocci on 12/8/2014 at 09:13
I think that's related to the script. Is there any difference, if you trigger the LCLight with a boundstrigger or a roombrush?
R Soul on 12/8/2014 at 18:04
The script warning occurs when an object has the OnOffSounds script but it doesn't have a valid Schema > Class Tags property. An LCLite straight from the hierarchy should not generate that warning.