Game crashing every time I start to play my mission from the Editor

Flux on 22/5/2009 at 19:42

Quote:

Or has anyone else built such a big mission (i.e. close to the peoperty limit of 61440) without saving issues?

To be honest with you I don't know how can I check "property" thing in my map. Since I didn't encounter such an error in both valley and cabot I don't know much about them. Can I check such stats for my missions via editor?

Beleg Cúthalion on 22/5/2009 at 19:46

Go into game mode using the debug version, get the concole and type in dropinternalpropinfo. After that, the T3Main.log in your TDS folder (wher it stores the savegames) will contain a pretty list. (http://www.ttlg.com/forums/showthread.php?t=91954) More of that.

I've dropped in at a German UnrealEd forum about the property fragmentation issue, maaaaayyybeeeee someone knows what an unr file is made of.

Flux on 22/5/2009 at 20:09

Here is Valley, total number of properties is 29872.

Just for reference:

Code:

Property Tag : 4954 [ 720235] (.\PropSysInternals.cpp : 271)
Property Touching : 3913 [ 720296] (.\PropSysInternals.cpp : 271)
Property StaticMesh : 3584 [ 720314] (.\PropSysInternals.cpp : 271)
Property ObjectMesh : 2747 [ 720359] (.\PropSysInternals.cpp : 271)
Property bHidden : 2135 [ 720392] (.\PropSysInternals.cpp : 271)
Property DrawScale : 962 [ 720458] (.\PropSysInternals.cpp : 271)
Property CollisionFlags : 703 [ 720471] (.\PropSysInternals.cpp : 271)
Property CastShadows : 564 [ 720479] (.\PropSysInternals.cpp : 271)
Property Culprit : 265 [ 720495] (.\PropSysInternals.cpp : 271)
Property HealthState : 235 [ 720497] (.\PropSysInternals.cpp : 271)
Property LightColor : 182 [ 720500] (.\PropSysInternals.cpp : 271)
Property AddSurfacesToNavMesh : 176 [ 720500] (.\PropSysInternals.cpp : 271)
Property CanSubdivideNavMesh : 164 [ 720501] (.\PropSysInternals.cpp : 271)
Property RenderType : 154 [ 720502] (.\PropSysInternals.cpp : 271)
Property TriggerScripts : 146 [ 720503] (.\PropSysInternals.cpp : 271)
Property ContactResponse : 144 [ 720503] (.\PropSysInternals.cpp : 271)
Property bHideDontDestroy : 130 [ 720504] (.\PropSysInternals.cpp : 271)
Property Disposition_vs_Player : 83 [ 720505] (.\PropSysInternals.cpp : 271)
Property Disposition_vs_Faction0 : 82

But Harwin says this

"you shouldn't be able to get the level in a state where it has too many properties within an editor session without it crashing"

So how come your level doesn't crash in the editor anyway?:confused:

Edit:Ok, makes sense...hitting 65000 limit won't let u open the map in the editor, something around that number crashes on save...

I want to play this mission for sure, it looks wonderful!...Hopefully we'll sort it out...

Beleg Cúthalion on 22/5/2009 at 22:03

Well, it won't play over 61440, it won't even open over 65535 and I fear it won't save over 61440 - [whatever it takes to create a savegame]. I could release it as a version that doesn't allow saving but I guess it would be better in that case to release it not at all. We cannot afford any shots in the stove as we say here (i.e. total failures :p).

str8g8 on 28/5/2009 at 11:49

hey BG did you get any response from the unreal community? Just wondering what your options are now?

Beleg Cúthalion on 28/5/2009 at 12:02

They were quite good in completely ignoring me. :p Well, I even deleted all brushes and navmesh volumes before baking the ibt/gmp files (that's more than 1000 objects less) without any result. If I delete lots of SMs (I think close to 1000 as well), I'm able to save at the beginning of the game but not later. If I delete all static meshes, it probably works. So I guess saving requires completely free property slots (I have app. 400-800 now according to the list) and only after deleting lots of objects the count of used properties drops so far that there are completely free ones again and not only "used but freed" ones which wouldn't allow saving since they're all... let's say "SMed" properties.

I'll have to make a test with two computers (have that at home, so no problem), to drop the property storage count after loading the level, after playing a few minutes and then after saving to compare if it rises and by which number. Since you had a look at the "Quirks etc." thread, you know that my only reasonable option (besides dropping half of the map or something) is to find someone to write a defrag tool for unr files. They look quite fancy in a hex editor but I haven't got a clue about programming so I don't know whether it's possible or not.

Beleg Cúthalion on 27/7/2009 at 13:07

I'm adding the loot it had before, music and then it has all the main AI, working (hopefully) objectives and all that sort of rough FM interieur. After that I'll try to add detail as long as possible.

58,000 is quite large already. Try to add the mission actors and get yourself a GL-ready zip to play it outside T3Ed. If saving still works after some minutes (e.g. after triggering some scripts and visiting all AIs) you should be fine, otherwise there might be issues. On my latest T3Ed test it looked like playing some minutes and saving decreased the property count while after some more playing it went up very high again so I carefully think saving takes app. 10,000 property slots or 10-20%. I haven't checked the original missions yet but I don't know if their complexity would be worth comparing.

Tiens on 28/9/2009 at 04:51

Quote Posted by Beleg Cuthalion

...I want to solve this saving issue first. It still crashes the game when I take it to GL and install it there. It runs fine, all the objectives and scripts work, inventory, everything, but I get a windows error plus CTD when I try to save. Well, not always, sometimes it just freezes in the saving menu...

Ups! I think that today I faced this problem too. I'm still a bit in shock because all day long I had a fight with this exotic error. Just as you said - at some locations the game crashed while saving process!

I mean, before the crash-test my mission was made of 4 maps (or loading zones). At 1st and 4th maps I saved great from the beginning. At 2nd and 3rd maps my saving worked properly (and even saved successfully from time to time) and but t3main.exe crashed much quicker. I have never seen this bug before!

For the first moment I thought I'll have to create "save-points" (or "check-points"? I'm not sure that I know the correct word). But a day of brainstorming gave me a better solution - I cut both crashing loading maps into two peaces.

I'm sure, that if I had more free time, I could experiment a little with deleting one or two sectors on my map, re-buildings, re-packings ect. Maybe I could find this "the last straw that broke the camel's back" but it consumes too much time.

It's finny but the largest map (the 1st one) gave no save-crashes at all. I began to think that it depends on how brush-buildings are complicated. I mean, if you have subtracting brushes only (room - corridor - room - corridor - ...), your map will be huge. If there is a big subtracted box with small added brushes inside, the map will be as small as an original South Quarter.