Scooby-Doo and the Case of the Missing Zone Portals

[Ironblayde]

I'm using UnrealEd 2, and noticing a few odd things happening. The first concerns my zone portals. The other day while I was working on my map, I switched into zone view and noticed that my whole map was one big zone, even though there are supposed to be six. I looked at my wireframe mode and found that every one of my zone portals had vanished. I took the time to recreate them, and all was right with the world.

A few hours later, I noticed I had a few too many zones. So I switched to wireframe view again, and lo and behold, all those zone portals that had disappeared were back! Thus I had two sets of zone portals, and some of my new ones were placed slightly differently than before, which gave me a few zones about 32UU wide. Aggravated now, I wiped out one set of zone portals so my map was correct again.

Today the problem is occurring again. Some of my zone portals -- specifically, the ones that remain from my original set -- disappear more often than not. They do not cut off zones correctly, and don't appear at all in wireframe view. Those portals that remain from the second set never disappear.

Now, here's the strange thing. If I Build All, most of my zones leak into one another. However, if I do a Build Geometry Only, followed by Build Lighting Only, all the zones are correct, though most of my portals still don't appear in wireframe mode! After I've built it in such a way, I can see the zone portal sheets in my map, even where they don't appear in the wireframe. If I Shift+Click to select the brush associated with that sheet, my Object Properties sheet does show properties for a brush, but the brush is nowhere to be seen in any of my viewports.

Needless to say, this is all extremely confusing for someone who just started with UnrealEd. My questions are:

1. Do you think this is an isolated incident? i.e. Should I simply create new zone portals and hope the problem doesn't arise again? If so, how can I get rid of my "invisible" zone portals?

2. Does this behavior have anything to do with the Add Special Brush tool? i.e. Would it be less problematic if I instead made my zone portals by using a regular additive brush and then setting the surface properties appropriately?

3. What exactly is the difference between executing the Build All command and executing each of the individual Build commands (Geometry, Lighting, Paths)? This is not the first time I've observed problems generated by Build All that are not generated by running the individual Build commands.

Sorry for all the questions, but I'm really beating my head against the wall over this. I've attached an early screenshot of what I'm working on if anyone cares.

 

[coolhead2100]

1.) This is worth a shot, but the problems will probably aris again. To find them for deletion click the binoculars icon at the top of the editor, and search for 'zone' or even just 'z' then select the zone portals that hsould have shown up in the search box and delete them.

2.) The add special brush tool should not have anything to do with it, but what you might want to do is add a plane set it to a zone portal and have some wacky texture applie to it so that it is clearly distinguished as a zone portal then rebuild all, see what happens and if all goes well simply hide it.

3.) Not sure about this one. Build All does have a few extra options (Atleast in UED 3 it does) but I see no major differne in it and using all the builds separately besides saving time.

 

[Hourences]

"2. Does this behavior have anything to do with the Add Special Brush tool? i.e. Would it be less problematic if I instead made my zone portals by using a regular additive brush and then setting the surface properties appropriately?"

your sheets are non solid i hope ?

they are hidden ? select properties, advanced, bhidden ed true ?
or top menu, group browser = anything weird going on there ?


if all fails try to export import your map, filters out garbage

 

[Ironblayde]

Thanks for the tips. Yes, Hourences, my portals are non-solid and invisible; they were functioning properly for some time before they decided to pack up their stuff and leave. There's nothing to be found in my Group browser. I've never tried to use Groups before, so I wonder what you were getting at there. Does setting the Group field of an Actor create a potential for error somehow? I've crashed UnrealEd enough times in the past week or two that I won't be surprised if I learn of another bug.

Since posting this I have created a new set of zone portals, and thus far, there have not been any more problems with them. I created the new ones using the exact same method I did for the old, so I don't know what, if anything, is different. While I'm on the topic of unexplained behaviors in UnrealEd 2, though, there are two more things I've noticed that I wonder if anyone has seen:

- First, once in awhile when I select a brush, my Actor properties sheet says that two brushes are selected instead of one. If I then press the Delete key, one of the brushes will be deleted, but the other will remain, and I can't get rid of it. However, I've found that the next time I reload the map, the extraneous brushes have vanished. This is a mere annoyance, not something that's preventing me from working, but I'm still curious as to what causes it.

- Second, occasionally when I select a number of brushes in order to move them all at once, I have noticed that one of them may translate or rotate at a different rate than the others. Specifically, yesterday I duplicated a set of four brushes and tried to rotate my new copy, and one of the brushes rotated at a rate exactly 1.5 times that of the others. I did a Transform Permanently on the brushes before duplicating them, as that was my only thought, but it did nothing to alleviate the error. This problem comes up very rarely, but it still worries me. With four brushes, I can just rotate the offending brush individually, but what happens when it comes time to duplicate the entire blue base and rotate it into place to serve as the red one? If I'm rotating hundreds of brushes, and some of them don't move as expected, that could be pretty irritating. Any ideas on this?

Thank you all so much for the help, and I'm sorry to bother you with so many questions.

 

[Hourences]

thats really weird
or you are doing something really basic and simple wrong, or you have a really messed up ued
in any case, i saw strange stuff in all the years i work with ued but havent enouncted the things you said yet

seems to be something is really wrong deep in your map that causes various things to go wrong

did you try an export import ? that really helps a lot sometimes, might do so now too
open map, export entire map by file > export, then do not close ued or youll loose all your textures, but push new map, now import your file in there, save under a new name, rebuild, save again, and see if it works now or not
and maybe dont use full rebuild anymore as the full rebuild also includes an optimalisation pass and sometimes that goes wrong, tho shouldnt go this incredible wrong


does all of this happen in other maps too ?
might want to consider to reinstall the latest patch then, itll overwrite the most important files in case something is wrong
ut.ini user.ini and unrealed.ini also can be resetted to give you the default settings again
and sure you didnt install anything weird ? like a really weird mod or this unoffical ut 451 patch

 

[Ironblayde]

Hmm, I haven't tried an import/export yet, but I'll definitely give that a shot tonight and see if it improves matters at all. I suppose I could try reinstalling the latest patch as well, though I haven't installed anything strange, and I don't use that 4.51 patch. In fact I just reinstalled UT just a month or so ago, but I saved my old .ini files so I wouldn't have to reset all my preferences in-game. If all else fails, I may try tossing out my .inis to see if the default settings do anything for me.

Your question as to whether these things happen in other maps is a good one, but I've only worked on two maps in UnrealEd: the one I'm on now, and a quick piece of crap before that which only served to let me practice using various tools. I've opened many other maps of course, but only to see how certain things were done, not to edit them at all. So it's possible that these problems are something peculiar to the map I'm working on, though I can't imagine what I did wrong. Maybe the import/export will fix it up, as you suggested.

Thanks again for all the help. I really appreciate it.

 

[Ironblayde]

Yet another question for this thread.

Hourences, your idea about performing an import/export on the map solved the problem of some objects moving or rotating at a different rate than others, so thanks a lot for that idea. There's something curious about it though. I have old and new versions of the map now, and when I built each copy, the copy of the map after the import/export had different statistics than the old one. Here are the numbers.

Pre-import/export:

Polys: 2876
Nodes: 5405
Ratio: 1.88:1
Max Depth: 33
Avg Depth: 3
Lights: 598

Post-import/export:

Polys: 2978
Nodes: 5563
Ratio: 1.87:1
Max Depth: 23
Avg Depth: 3
Lights: 598

I don't understand what could account for this. The ratio is slightly better and the BSP tree doesn't go as deep in the extreme case, but where could all those extra polygons have come from? My first thought was to check every instance where I'd merged the polygons in a brush, to see if they'd become separated, but none of them had. Every inspection both in UnrealEd and in UT itself give the impression that nothing has changed in the geometry of the map, but there must be some explanation for the change in those numbers. Is there anything you can think of? For example, is there any way that certain polygons might have been getting misreported in the old copy of the map (even though I never saw any visual defects in playtesting), or any way that the new copy of the map is counting polygons that are completely invisible and thus were not counted in the original totals?

I'm happy that the strange rotation problem is gone (and the other may very well be gone too -- it hasn't resurfaced yet), but I'm a little hesitant on which copy of the map to proceed with, without knowing from where the discrepancy in those statistics arose. Once again, I really appreciate all the help. Hourences, I should send you a cookie or something.

 

[Hourences]

if you dont encounter problems and if you cant see the difference then dont bother about the change in numbers
export cleans the map, so its likely that certain information is deleted now and that other info is being read differently, giving you different stats
or maybe, i said in my previous reply, dont do a full rebuild use seperate ones, did you do that ? if so you skipped a step that you prolly did do in your old version, so that might be it as well

whatever the case, if it works, dont bother
ratio 1.8 is still more then fine, and a few extra polys wont kill you prolly
if you can choose between a highly bugged map, or a slightly more high poly map i would know what to take

 

[Ironblayde]

All right, I won't worry about the numbers then. Thanks a lot for all your help in this thread. You're a gentleman and a scholar.

 

[Kyouryuu]

Pre-import/export:

Polys: 2876
Nodes: 5405
Ratio: 1.88:1
Max Depth: 33
Avg Depth: 3
Lights: 598

Post-import/export:

Polys: 2978
Nodes: 5563
Ratio: 1.87:1
Max Depth: 23
Avg Depth: 3
Lights: 598

The building algorithm is rather nondeterministic. You can run Build All multiple times and not end up with the same end result. It depends on the phase of the moon, the current tides, and the alignment of Jupiter and Saturn.

BTW, looks like a great start for a first-time map!

 

[Ironblayde]

It depends on the phase of the moon, the current tides, and the alignment of Jupiter and Saturn.

I'll be sure to consult an astrologer before attempting any further builds.

 

[quitgrin1]

lol