bizarre problem with my map

[irongull]

OK, here's the deal:

When I load my map in a practice session, it works fine.

I went to test the net code of the mod I'm working on, and I don't have access to an outside server, so I started up a standalone server on my machine, then started a client and connected through localhost. Doing this when one of Epic's maps works fine, so I know the method is sound. However, when I try this with my map, the client crashes when loading and gives the following error message:

Assertion failed: GetLevel()->Actors(0)!=NULL [File C:\UTDev\Engine\Src\UnScript.cpp][Line: 223]

History: AActor::InitExecution <- (Mover dtf-a.Mover3) <- BeginPlay <- UGameEngine::LoadMap <- AttemptLoadPending <- TickPending <- UGameEngine::Tick <- UpdateWorld <- MainLoop

In this example, it crashes on Mover3 - by fooling around with deleting and reordering objects, I've come to the conclusion that it halts on whatever object it encounters first - i.e. when I delete all the movers, it starts halting on lights, then ZoneInfos and on and on. I know that it isn't my code that's doing it, as I also tried deleting all of my novel navigation points and loading it as a simple deathmatch map. I also tried exporting the enire level, importing it into a new level, and rebuilding. No good reason, it just seemed like something to try.

Any tips/insights would be greatly appreciated. I've got to get this mod out the door - its killing my productivity. FYI, its like CTF4, only a bit more flexible. It can be played like CTF, or all the flags can be replaced with Dom style control points. Depending on the map loaded, you can have 2,3, or 4 teams, and as many flags per team as you like. Enough pimpage, please help me!

[Aphex]

I can only say that this has happened to me on one of my maps - I had an attachmover that crashed any connecting client machines whenever it was triggered.
Don't know if that helps though :(

[irongull]

Gather around children, and I will tell you a tale of a stupidity so vast that the planet can barely contain it.

I've been developing a series of similar maps in parallel for my new mod. As I built a bit of architecture in one map, I would export it to the others. While exporting/importing, I noticed that there were a lot of 'garbage' objects imported - i.e. there were far more objects imported than I thought were in the file. After recompiling the map after the first import, the whole map turned into one big BSP hole. So, I figured that those extra actors on the import must be to blame. I redid the import, deselected all the stuff I wanted, then did a delete, which got rid of all the excess junk except for two actors. I couldn't figure out what they were, and I wanted them gone, so I went into advanced options and set bStatic bNoDelete to False, then deleted them. I rebuilt, and the problem was solved.

After running into the psychotic error described in the previous post, and after sleeping on it, I carefully analyzed an export of my entire level and compared it to an export of one of Epic's Maps. Sure enough, there at the very top of my file was the LevelInfo object which had bStatic and bNoDelete set to False. I deleted these lines, imported the file, rebuilt, and it works fine.

There are several morals to this story:
1) exporting levels also carries along a bunch of Inventory Spots that are no big deal. It throws of your 'Selected Actors' count, but thats all (I think - I still worry that they might have caused the BSP error, but I'm a little compulsive).

2) DO NOT EVER monkey around with bStatic and bNoDelete on the LevelInfo object. Dumbass.

3) always test your map/mod in network play before releasing it. And if you have test it by running a separate client and server on the same machine, doing it under Linux works much better.

4) Sleep is good. Sleep clarifies.

[Phragmites]

wise words of wisdom, venerable gull.

[Aphex]

Hmm yes, especially point 4.
Oh btw, the 'selected actors' count problem can crash UnrealEd when doing a PATHS_DEFINE :{