I search for solutions in this order: Past Code, Unreal Source, Wiki, BUF, groups.yahoo, google, screaming at monitor. – RegularX
Legacy:Torin/Navpoint Crashes
3 Oct 2004
Torin: UnrealEd2 crashes on save after import and build of an exported map containing bot navpoints. Specificaly, I was trying to make a symmetrical two-team map by selecting all objects in a map, duplicate, and place the resulting copy. Why it waits until you go to save after a rebuild is beyond me. I should probably add a note to the "UEd bugs", "Crashing UEd", and "Building a CTF map" pages, but I should do a little testing first. Maybe next week...
Foxpaw: The reason why it does this is probrably because it stores the map in a different format in memory than it stores it in RAM. So, it has to convert from the RAM version to an appropriate storage version. When it does this, it's probrably running into something invalid, and hence the error occurs. Since the primary thing that needs conversion is pointers and handles, and invalid pointers DO tend to cause crashes, I would suspect that the paths are not building properly but it doesn't crash until it tries to access something about one of the paths. (Which it would when it saves.)
Torin: I assume you mean "different format on the hard drive" since memory and RAM (Random Access Memory) are generally considered to be equivalent in common usage. ;) While I can't disagree with anything you've mentioned, I'm puzzled by the fact that UEd can't 'Save' something it can 'Build'. To me 'Save' means "dump a bunch of stuff to permanent storage" i.e. the hard drive. However, this is UT we're talking about. Everything seems to be 'Object Oriented' which doubtless means linked lists and b-trees. Maybe the 'Build' function is smarter at navigating than 'Save'. Maybe 'Build' can take shortcuts that 'Save' cannot. Perhaps there were too many points in the botpaths for that particular map. Again, I need to do some testing...
Foxpaw: Err, yes. I did mean the hard drive. The major difference is likely to be, like I said, in RAM it can use pointers and handles, while on disk it cannot, because the pointers would all be invalid when the file is next loaded, unless it happens to get loaded into the exact same spot in memory, which is very unlikely. Therefore, the pointers and handles need to get converted to something that can be safely written to the disk, like an index into some list or something like that.
So build does it's thing, say's you point to that, you point to that, etcetera. One of those "thats" might not actually be anything valid. Assigning a pointer to an invalid value will not cause a crash, however. It's likely when it goes to save and says, "now this pointer has to be converted to an index in some table." So it takes a look at what it's pointing at, perhaps attempting to access some property of it, and wham, you've got yourself a crash. (I would guess a general protection fault, as invalid pointers more often than not point to unallocated memory or memory allocated to a different process.)
