Posted: Sun Mar 13, 2016 12:18 am Post subject:
The 10 most popular Tiberian Sun crashes (out of 152 known)
Below you can find a list of the most popular crashes of tiberian sun, rankings are decided by the amount of error logs uploaded to the CnCNet crash database. Special thanks goes to all the thousands of CnCNet players who were willing to help out and take advantage of our automatic error log uploading feature
1. 0x006717CB - LaserWaveClass 2. 0x0062E6F6 - TechnoClassOwning_HousesType - colored house on a multiplayer map (like using Nod or GDI buildings/units on a map)
3. 0x006A8D16 - BlitPlain_ushort
4. 0x005DED65 - Create_Units
5. 0x004B955A - GScreenClassAdd_A_Button
6. 0x005DC279 - Fill_In_Data 7. 0x004EE9A8 - IonBlastClass 8. 0x0047C89B - CC_Draw_Shape - wrong Tiberium patch on a slope
9. 0x006703D4 - const WaveClassBlend_Beam
10. 0x004668A8 - Unknown
Please post in here if you have any information about the listed crashes! E.g. do you know how to reproduce one of them? A video of it might help a lot too
Were any of these crashes already fixed by someone? Last edited by FunkyFr3sh on Thu Mar 17, 2016 10:44 am; edited 6 times in total QUICK_EDIT
I don't know if it is the same but WaveClass error got fixed long ago. HyperPatch has it fixed and I think
AlexB's graphics patch (removing backbuffer - video memory) also fixes it. QUICK_EDIT
As far as I know, the #1 crash is solved by using DetailLevel=1 (thin lasers instead of the fat, partially transparent lasers that you have with DetailLevel=2). DTA has it fixed by hardcoding lasers to be drawn like they're drawn with DetailLevel=1, regardless of the actual selected detail level.
0x0047C89B - wrong Tiberium patch on a slope
0x0062E6F6 - colored house on a multiplayer map (like using Nod or GDI buildings/units on a map)
other classic IEs
0046C7E2 - Fog of War was enabled
006BB69C - construction yard build as building construction was cancelled
00458FB2 - foundation overlapping buildings placed on a map got destroyed _________________ SHP Artist of Twisted Insurrection: Nod buildings
As far as I know, the #1 crash is solved by using DetailLevel=1 (thin lasers instead of the fat, partially transparent lasers that you have with DetailLevel=2). DTA has it fixed by hardcoding lasers to be drawn like they're drawn with DetailLevel=1, regardless of the actual selected detail level.
Similarly to the better-known disruptor crash, the half-transparent lasers will crash the game when they fire off the southern border of the screen.
I wish I could reproduce this crash so I could do at least some testing, but it never seems to trigger for me lol
So the disruptor crash and the laser crash are actually the same?
Lin Kuei Ominae wrote:
0x0047C89B - wrong Tiberium patch on a slope
0x0062E6F6 - colored house on a multiplayer map (like using Nod or GDI buildings/units on a map)
other classic IEs
0046C7E2 - Fog of War was enabled
006BB69C - construction yard build as building construction was cancelled
00458FB2 - foundation overlapping buildings placed on a map got destroyed
Thanks! That's good to know, I guess it should be easy to reproduce the two above just by loading the map. Will add the info to the first post QUICK_EDIT
I wish I could reproduce this crash so I could do at least some testing, but it never seems to trigger for me lol
It has always been inconsistent, crashing on some systems and not on others. No one really knows why.
FunkyFr3sh wrote:
So the disruptor crash and the laser crash are actually the same?
Not the same, but similar in nature; they both crash the game when the transparent beams are drawn off the southern border of the screen. But the laser crash is easy to fix by forcing the laser to be drawn with DetailLevel=1. HyperPatch has a fix for the disruptor crash, but it doesn't seem to be perfect. _________________ CnCNet Client | CnCNet TS patches | More Quality-of-Life Improvements for RA Remastered
Patched the game to ignore singleplayer objects in multiplayer maps, that includes Infantry/Buildings/Units/Aircrafts (for Nod and GDI only). Is there anything else that could crash it? triggers etc..?
I've seen GDI and Nod owned units and (IIRC) also structures work on multiplayer maps perfectly fine: these units would then automatically belong to whichever player selected GDI or Nod (if there were multiple players using that side, the player that'd own the units depended on the selected colors).
So if crashes happen, it's only in certain situations (I don't know which) and I don't think it's a good idea to entirely prevent objects owned by GDI or Nod from being present on multiplayer maps.
People could potentially create interesting game modes this way after all (since using the "Entered by" event doesn't work with the Spawn houses, but only with actual factions). _________________ QUICK_EDIT
1. Are you forcing DetailLevel 1 for whole game or only for laser related code?
2. It is better to fix these in the map itself. Removing stuffs would present an incomplete map. Tags might get
ignored by the game if associated objects are missing. But a playable side owner on a trigger might depend
on what action it is performing.
8. Tiberium patch on slopes can be fixed in the map as well. QUICK_EDIT
I've seen GDI and Nod owned units and (IIRC) also structures work on multiplayer maps perfectly fine: these units would then automatically belong to whichever player selected GDI or Nod (if there were multiple players using that side, the player that'd own the units depended on the selected colors).
So if crashes happen, it's only in certain situations (I don't know which) and I don't think it's a good idea to entirely prevent objects owned by GDI or Nod from being present on multiplayer maps.
People could potentially create interesting game modes this way after all (since using the "Entered by" event doesn't work with the Spawn houses, but only with actual factions).
have to try that out, I could then check if a player is there that could take the units and just spawn them
E1 Elite wrote:
1. Are you forcing DetailLevel 1 for whole game or only for laser related code?
2. It is better to fix these in the map itself. Removing stuffs would present an incomplete map. Tags might get
ignored by the game if associated objects are missing. But a playable side owner on a trigger might depend
on what action it is performing.
8. Tiberium patch on slopes can be fixed in the map as well.
1. Only laser
2./3. : yes it would be good to fix finalsun to ensure such problems don't happen in the first place. But the crashes are so popular, I really need to fix them in the game
Already had a quick look into the tiberium on slopes, it goes out of bounds and reads bad memory and then ends up crashing while using a broken pointer. Need to track it down and fix it up QUICK_EDIT
Patched the game to ignore singleplayer objects in multiplayer maps, that includes Infantry/Buildings/Units/Aircrafts (for Nod and GDI only). Is there anything else that could crash it? triggers etc..?
I'm wondering, if you only have any of the TechnoTypes on the map beloning to a SP house, the game crashes?
It does not simply not draw them? _________________
Tiberium slope thing is probably the game trying to read a slope frame for Tiberium, which doesn't exist AfAIK. Might be able to patch the game code and add an exception for Tiberium to appear with another Tiberium frame. QUICK_EDIT
I've seen GDI and Nod owned units and (IIRC) also structures work on multiplayer maps perfectly fine: these units would then automatically belong to whichever player selected GDI or Nod (if there were multiple players using that side, the player that'd own the units depended on the selected colors).
So if crashes happen, it's only in certain situations (I don't know which) and I don't think it's a good idea to entirely prevent objects owned by GDI or Nod from being present on multiplayer maps.
People could potentially create interesting game modes this way after all (since using the "Entered by" event doesn't work with the Spawn houses, but only with actual factions).
IIRC it crashes when you place House Nod Buildings/Units on a map, but only GDI players are present (or vice versa).
Though this whole problem could be already solved by Iran's Spawn house hacks, since they remove already "unwanted" objects from the map.
Another case that caused the game to crash was a House GDI Trigger, when only Nod Players are present (or vice versa)
Though i think these were fixed by Iran's spawner hacks as well.
Simple way to test this is a house GDI "reveal all" Trigger and then let only Nod houses play the map.
\Edit
tested in DTA. Still causing crash. The EIP is 005DC279
which is listed as
6. 0x005DC279 - Fill_In_Data
To reproduce create a testmap with a House GDI Trigger and let only Nod players start the game.
\Edit
House GDI buildings on the map are simply removed in DTA when only Nod players are present. Not sure how vanilla TS reacts to this as i have no vanilla TS to test it at the moment.
\Edit
4. 0x005DED65 - Create_Units
This happens when you set AI BuildTime too low.
e.g. a value under 1.0 in A.I difficulties setup
Though i just tested 0.0 and the AI was still producing fine. It seems to happen only quite rare and i remember DTA had issues with cheap AI objects and a low BuildTime value.
7. 0x004EE9A8 - IonBlastClass
this is probably similar to the sonic and laser waveclass error. The ion cannon ripple wave effect rendered by the engine is causing crashes as well when you scroll with the southern screen border over the effect. _________________ SHP Artist of Twisted Insurrection: Nod buildings
Fill_In_Data is indeed caused by triggers, will add them to the ingore list just like all the other nod/gdi objects until I tested how the game behaves when a player does have the matching house. Will code a special fix for mod maps that (ab)use these houses
6. 0x005DC279 - Fill_In_Data - FIXED
IonBlastClass has a check for DetailLevel 2 at the start of the function, the faulty code will not trigger with lower DetailLevels. I will force it to DetailLevel 1 for now just like the lasers.
Not sure how vanilla TS reacts to this as i have no vanilla TS to test it at the moment.
As far as skirmish goes
For side buildings placed on maps
- whatever the human player side is, those side buildings are removed
- if no AI player belong to a side say none of the AI player is GDI then GDI buildings are removed
- if AI player has a same side as the buildings, then they become the owner
For units if there is no AI side belonging to the placed unit's side then it crashes.
For house triggers, vanilla game doesn't crash on side owned triggers like shroud reveal or play anim/sound etc.
It crashes in TS Client for map reveal but not to play sound etc.. So should DTA/TI. QUICK_EDIT
In my last post, the difference between vanilla TS and TS Client regarding the map reveal trigger was due to
the usage of different event types while testing. Actually both TS Client and vanilla behave in the same manner.
With event 1,8,0,0 (Any Event) - if the side used in trigger is not present then it crashes.
With event 1,13,0,0 (Elapsed Time)/1,47,0,0 (Elapsed Scenario Time) - it doesn't crash if the side used in trigger
is not present. QUICK_EDIT
Patched the game to ignore singleplayer objects in multiplayer maps, that includes Infantry/Buildings/Units/Aircrafts (for Nod and GDI only). Is there anything else that could crash it? triggers etc..?
I'm wondering, if you only have any of the TechnoTypes on the map beloning to a SP house, the game crashes?
It does not simply not draw them?
Cannot tell you any details about it yet, but since bittah said it might be possible to use Nod/Gdi objects in special maps I will have to take a look into it again. Will post details about the new patch in here once done
Iran wrote:
Tiberium slope thing is probably the game trying to read a slope frame for Tiberium, which doesn't exist AfAIK. Might be able to patch the game code and add an exception for Tiberium to appear with another Tiberium frame.
Tested around with it a bit, seems like tiberium on slopes works perfectly fine. The problem is only related to the drawing. So I just disabled drawing faulty tiberium to get around the crash until a proper solution is done
E1 Elite wrote:
In my last post, the difference between vanilla TS and TS Client regarding the map reveal trigger was due to
the usage of different event types while testing. Actually both TS Client and vanilla behave in the same manner.
With event 1,8,0,0 (Any Event) - if the side used in trigger is not present then it crashes.
With event 1,13,0,0 (Elapsed Time)/1,47,0,0 (Elapsed Scenario Time) - it doesn't crash if the side used in trigger
is not present.
Thanks for testing, will have another look into it soon
-
8. 0x0047C89B - CC_Draw_Shape - wrong Tiberium patch on a slope -FIXED- QUICK_EDIT
If it's crashing in CC_Draw_Shape it's most likely attempting to draw the wrong frame. Do you have any idea what frame it's trying to draw?
Considering there are only 152 known crashes, do you have any statistics on the frequency of the crashes. Basically how many times a crash at an address has appeared in your crashes database? I assume there are a bunch of crashes that can be ignored because they're one off on startup with really broken maps or weird game/video card etc config. QUICK_EDIT
ecx (cl) is higher than 4 and it reads junk. I only checked where the high value came from and apperently it is just directly taken from the slope graphic, I think it was slope5.tem which it loads here 004F5940
I updated the crash db some time ago, all crashes are sorted now into folders. I can see how often a crash happens and also if there should be a new crash caused by a bugged patch QUICK_EDIT
There probably is a bug ingame with the logic for reading the Tiberium overlay on map read? Or from tht tiberiumweb thread it looks like FinalSun doesn't write Tiberium on slopes correctly to the map file so you might be able to patch Tiberium slope map reading in the Tiberian Sun EXE to 'fix up' what FinalSun is doing wrong. Apparently some official Westwood maps have Tiberium on slope. if you can have someone produce a test map for it with just one tiberium on slope.
PROBABLY would be a good idea to check by editing a map file to have strange coordinates for other overlays, to see if you can get the same crash. QUICK_EDIT
Tiberium on slopes works fine in general, also when placing it in FinalSun.
You can even chose any tiberium patch and place it on slopes. You don't have to place the special slope patches on slopes. The big flat ground tiberium patches work on slopes too.
But
As soon as you place a tiberium patch on a corner slope, the game crashes.
Ingame the normal growth/spread logic will also never spawn any tiberium on corner slopes.
Since many mappers use the "paint green tiberium" tool with a big Brush size, they carelessly also place tiberium on corners and thus cause the crash.
If FinalSun would by default forbid/prevent any tiberium placement on corner slopes only, there would be no crashes anymore.
\Edit
did a full test for each slope piece
A few of the corner pieces work even with placed tiberium on them.
However, ingame tiberium grows and spreads only on the left 4 straight slope pieces. It will never spread on any of the corner pieces.
Tiberium has slope frames for some of the slope facings, but not all. Have you checked if these correspond with the slopes where Tiberium does not crash (I would assume so). _________________
I placed TIB01, TIB16 and the random "Paint green tiberium". It made no difference which tiberium patch is placed. On the marked corner slopes it crashes, on all others tiberium works regardless which tiberium patch.
Just to complete the info
TIB13, TIB14 is for the first slope piece facing NW (see image above)
TIB15, TIB16 is for the second slope piece facing NE
TIB17, TIB18 is for the third slope piece facing SE
TIB19, TIB20 is for the fourth slope piece facing SW
There are no special graphics for corner slopes.
Placing the slope patch TIB13-20 on flat ground works as well as placing the normal flat ground tiberium patches TIB01-12 on the straight slopes.
It's just a graphical thing. _________________ SHP Artist of Twisted Insurrection: Nod buildings
Only the first 4 slopes will work. That the others partially work is just a random artifact of memory layout. I looked into this issue some time ago here.
There are only 4 SLOP0xZ files for each theater, and if a higher index is used, bad data is read. If you are lucky, the data is 0, which is interpreted as a null pointer, meaning the logic is not used. If you are not quite as lucky, you read a pointer of unexpected type, whose data is then misused and the result will be random. If you are not lucky at all, it's a random value that is not a pointer, in which case it will just crash. _________________ QUICK_EDIT
TIB13, TIB14 is for the first slope piece facing NW (see image above)
TIB15, TIB16 is for the second slope piece facing NE
TIB17, TIB18 is for the third slope piece facing SE
TIB19, TIB20 is for the fourth slope piece facing SW
There are no special graphics for corner slopes.
Are you sure? Coding-wise this may be true (I haven't experimented myself so I can't tell), but graphics-wise the list is not quite as logical: TIB18 seems to be meant for the slope facing SW, TIB19 is for SE, and TIB20 is for the East corner slope (or for the slope facing SE. It's hard to tell for certain). You can tell by doing a side-by-side comparison with the Tiberium overlay and the slope. This could, of course, be just a mistake by Westwood's graphics artists. _________________
I only checked the graphics and tried to find a logical order in them.
I just checked again ingame by giving TIB13-20 one after another Image=VEINS, to see which is spawned on the slopes via the games growth logic.
For that i drastically raised growth/spread and put about 50 slopes of each of the 4 straight slopes on the testmap.
TIB13 spawned/grown on NW slope
TIB14 spawned/grown on NW slope
TIB15 spawned/grown on NE slope
TIB16 spawned/grown on NE slope
TIB17 spawned/grown on SE slope
TIB18 spawned/grown on SE slope
TIB19 spawned/grown on SW slope
TIB20 spawned/grown on SW slope
Thus confirmed previous statement about the directions.
Hey Alex
Any chance you could fix the ugly TurretOffset bug in TS?
When using TurretOffset, the PrimaryFireFLH value is completely messed up, since it doesn't calculates the FLH from the center of the turret, but still from the center of the unit, and after that it simply adds the TurretOffset value to the Forward value of the FLH. (at least this is how it looks like to work)
Since you did such a great bugfixing job, maybe you could also look into rotors for AircraftTypes.
The game even still has several keys concerning rotors, though they don't do anything anymore.
There are the keys CustomRotor and Rotors
and also the hardcoded referenced SHPs RROTOR.SHP,LROTOR.SHP, which seem to be the SHPs that are supposed to be used to show the rotor. _________________ SHP Artist of Twisted Insurrection: Nod buildings
...forcing the detail level to 1? That's not a fix, that's a workaround, and one that disables the game's detail
yep, i'm perfectly fine with all the workarounds we found here. Anything is better than a crash and it gives us time to fix things up properly QUICK_EDIT
What are the top crashes after you applied all the crash fixes you did?
Want to know what is the score of crashes now.
Should be the same order as the ones in the first thread, just the "fixed" ones removed from the list. I don't know what comes after these, I should have the full logs somewhere on drive maybe, old pc died so I can't check the hdd QUICK_EDIT
I created a map with which the Fog of War crash can be consistently reproduced in about 2 seconds without any input from the player, so hopefully this will help with finding a fix for it.
This map works with the public versions of both DTA and TS with Rampastring's client (not with Funky's client right now, because the spawner it includes doesn't have working FoW at all), but you'll have to manually edit Spawn.ini and then run game.exe with the -SPAWN argument to enable Fog of War.
Just make sure that you start on the first starting position/Spawn1 and it should work fine.
It turns out that the crash only happens when the screen is moving and the border of the fog gets clipped by the bottom of the screen (just like with the WCE crashes), which explains why the FoW crashes were always so inconsistent.
Also, the crashes only happen when there are buildings present, while the presence of animations or units makes no difference.
You cannot post new topics in this forum You cannot reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot vote in polls in this forum You cannot attach files in this forum You can download files in this forum