uncadonego on 29/4/2006 at 19:16
Yes but as I said that area has not changed one iota for weeks. It's somehow definitely the tunnels below ground outside of the field of view. I even tried putting blockables at the two manhole entrances just in case, but that didn't help. Getting rid of the tunnels stopped the error, and since they are not needed for the gameplay in that area, they're gone. The tunnels in the the area where they are needed for gameplay are not causing any problems, so they can stay, thank goodness.
I saved that mis file, so some day when I have the time, I'll try a bazillion things to see if I can fix it. I don't spend a lot of time arguing with dromed. It says no, so the answer's no. I'll try to find out why later....:erg:
The Pixie on 29/4/2006 at 21:43
I have had a problem with terrain that was a long away causing a crash. The distant terrain was complex, but several 100 units away, and completely isolated (the player had to go through a portal to get there isolated). If you use area brushes and just portalise that one area does it still happen?
uncadonego on 30/4/2006 at 06:32
the pixie
do you mean a maw portal, or a physical tunnel? Because long straight tunnels will freak out dromed too. If not acid trails, a downright crash will occur.
It won't crash if I me only the entire map, excluding the lowest portions with the sewers. Those sewers might still get rebuilt, only with more twists and turns. If Dromed is seeing those tunnels even though they are underground (well, I shouldn't say dromed, let's say the engine), maybe later when I have everything else finished and working, I'll make some shorter sewers and give it a shot.
I hate Dromed:mad:
The Pixie on 30/4/2006 at 12:44
A maw portal. There were no connecting brushes at all, and a load of solid between them.
uncadonego on 1/5/2006 at 06:26
Ah! Then your situation is something similar to mine. There is about 16 to 22 feet of solid (original Dromed solid, not solid brush) between the street and the tunnels. Bizarre. I wonder if an air brush large enough to cover the view of that terrain hundreds of feet away, then made "blockable" would have any helpful effect.
nicked on 4/5/2006 at 15:57
try turning on the reverse render order (can't remember the command right now). It'll show you the furthest away rendered brushes in front of the nearer ones so you can see if Dromed's rendering unseen brushes. Anyone know the command?
muzboz on 16/9/2013 at 03:54
My reply may come some 7 years late, but could still be relevant to people, as I just had this problem too.
I was playing with multibrushes, as I've never used them before. I tried making some stairs (which I haven't touched since 2001!) into a multibrush group, as an experiment. I selected all 30 objects or so, and made them into a group, and moved them all outside. I did a Quick Light portalise. Worked. So I put them back inside where they'd always been, happy with my multibrush experiment. I did a Quick Light portalise again.
Then when I moved the camera around, I was getting a ton of the "draw_surface: too many vertices" warning happening! I can see them in the new DromEd 1.21 MONO window. I couldn't figure out why they started happening, seeing as I hadn't REALLY changed anything.
I changed to Object Lighting and did a Tools > Complete Processing, and now it seems to have gone away again! I guess maybe it needs to run the optimise process or something, to clean up excess polygons, or something.
All the best, taffers.
Artificer Rob on 16/9/2013 at 10:14
Multibrushing can cause a lot of issues with polygon count (and by extension - vertices). When you move multibrushes around, they often become unsnapped from the grid. Whenever you move a multibrush, it's important to set your grid to the lowest size you're using and do a quick combination of highlight_unsnapped and snap_highlighted to get things to fit back into their places. Otherwise, you'll end up accidentally creating an exponentially larger amount of polygons in a given area.
Complete processing might have solved the issue for you, muzboz, but this was probably due to the portal optimization. I'd still recommend snapping the rest of your brushes when you get the chance :)
As for the OP, I've had this error recently with an area with lots of archways. They had all been 24-sided, but whenever I placed the last one in, the mission failed to portalise. After troubleshooting the brush in question and looking for anything out of place, I couldn't get the mission to work with that final brush in place. I took them all down to 12-sides each and everything ran alright.
john9818a on 17/9/2013 at 04:45
With vbrush_snap in the user.cfg file multibrushes snap to the grid at whatever size it is set at.
