• There seems to be an uptick in Political comments in recent months. Those of us who are long time members of the site know that Political and Religious content has been banned for years. Nothing has changed. Please leave all political and religious comments out of the forums.

    If you recently joined the forums you were not presented with this restriction in the terms of service. This was due to a conversion error when we went from vBulletin to Xenforo. We have updated our terms of service to reflect these corrections.

    Please note any post refering to a politician will be considered political even if it is intended to be humor. Our experience is these topics have a way of dividing the forums and causing deep resentment among members. It is a poison to the community. We appreciate compliance with the rules.

    The Staff of SOH

  • Server side Maintenance is done. We still have an update to the forum software to run but that one will have to wait for a better time.

FS9 to CFS2 occasionally crashes to desktop

P

PJMack

Charter Member
I converted an FS9 model perfectly but she causes a crash to desktop often. Any help is appreciated.:wiggle:
 
Hi PJ,
Lyndsay is partially correct, as it's part of the whole FS9 'g_lightstates' conversion problem (Fs9 has many more internal/external/vc lighting display options which CFS2 doesn't and cannot port over in the conversion, so causes crashes).

If you are using MDLC190 for conversions then this should remove the g_lightstates entry automatically. There is also a way of doing this manually through hex editing.

It could also be an FS9 gauge or sound connected to a gauge, especially in the vc. Replace with a good old CFS2 2d panel, which also will remove the vc gauges, see if that makes a difference.

If the mdl is a biggie, ie 5Mb+ then it can sometimes just cause CFS2 to give up trying to move such huge amounts of info.

Cheers Shessi
 
Hi PJMack,

Also the FS9 "Crash Check" seems to cause problems. One way to test this it to crash the aircraft and see if you get a CTD. This can be fixed with a SCASM edit.

Regards,
B24Guy
 
The gurus have spoken...all excellent replies IMHO. But to narrow it down, if the model loads and flies in FF as single player, then CTD's on exit, its gonna be a panel gauge problem in VC. If it CTD's in QC with wingmen flying the same model, its the lightstates. As for possibly having an oversized mdl, if that's the case, it won't even load when selected from the aircraft selection window -- the sim will hang or CTD the moment you select the model. And finally, as B24 said, if it CTD's when it crashes or collides with other planes, its still got its original FS crash check flag in the mdl file.

Going back to the gauge probability, the best way to test is to replace the entire panel outfit with a blank panel config from one of the old freeware Alphasim products. Their early CFS2 freeware releases all came with a blank panel setup that had no graphical 2D panel and no gauges in the VC or 3D panel. By replacing the current FS9 panel outfit with this and flying about 10 sessions or so, you'll know for certain.
 
I thought it was the detailed aircraft...........

I have experienced crashes to desktop with most FS9 planes when I have more than one of the planes on a mission.............

I call them........solo performers

These FS9 planes are very detailed........but I thought this hyper detail was just too much for CFS2 to handle?

More than one is like eating to much eye candy.......

one is fine.......but many causes problems....
 
Crash Check?

Could one of you fine gents enlighten me on the scasm edit for this? :ques:
Dave
 
Scasm almost any FS9 mdl, open the sca file with a text editor and then do a word search for crash_check. You'll find something like this in the upper guidparam section:

;UINT16 CC 2 {0EECADB4-1724-41C6-B977-D87A4C9544E8} crash_check

And in the body of the proceeding text, you'll see text lines like this:

:L000408
;uName: crash_check uOffset: 0xCC
IfVarAnd( :L000414 0xCC 0xFFFF )
Call( :L00042C )
:L000414
Jump32( :L0004E4 )
:L00041A
Jump32( :L099976 )
:L000420
Jump32( :L0004E4 )
:L000426
Jump32( :L0CD7DA )
:L00042C

And in the bottom variable table:

;Variable Table used by IfVarRange (0x24), IfVarAnd (0x39), TransformCall (0x46), Interpolate (0x9E), IfInF (0xB3)
;uOffset uName
;----------------------------------------
;0x00 params_length
;0x68 gen_model
;0x6E left_ailer
;0x70 right_ailer
;0x72 left_flap
;0x74 right_flap
;0x76 elevator
;0x78 rudder
;0x90 parts_visible
;0x98 g_lightStates
;0xA8 engine0
;0xAA prop_slow/ still/ burred
;0xCC crash_check
;0xDA engine1
;0xDC prop_slow/ still/ burred
;0xE6 c_tire
;0xEA l_tire
;0xEE damaged0
;0xF0 r_tire

To correct all of these, first delete the entire crash_check line in the top guidParam section. For the other entries, replace the text crash_check with userdefined0.
 
Bearcat

Thank You, Thank You, Thank You! :applause: It works! You don't know how many castaways I've had because of this. Always thought my .dp's were suspect. Somehow over the years I missed this one. :salute:
Dave
 
Very informative thread.

Can the crash_check thing be avoided by unchecking the "Crash" check box in MakeMDL compiler options?
If so, I'll re-compile current aircraft to have better compatibility to CFS2.

Cheers

Daisuke
 
Hi Daisuke,
I would think so, but that might only apply to aircraft for output to Fs9. Why not try un-checking it, compile to a CFS2 ac and then scasm it and find if the crash_check call is still there. If not you have the answer my friend!

Cheers Shessi

p.s Let us know the results, ta!
 
Confirmed

I confirmed the results.
Uncheking the "Crash" check box in MakeMDL actually removed crash_check routine in SCASM code.
Here are the code sniplets generated by MDLC.
They are the list of dictionary section at the top of the code, but I also confirmed there was not any text that matched "Crash".

Code with checked:
;uType uOffset uLen guidParam uName
;----------------------------------------------------------------------------------------------------
;DICT_SECTION
;UINT16 98 2 {0EECADB4-1724-41C6-B977-D87A4C9544E8} crash_check
;FLOAT32 9A 4 {FC649DE0-34E5-11D3-A479-00105A24D108} c_gear
;UINT32 9E 4 {4CF550DF-134D-4989-BACD-978E3A69D82E} c_tire
;FLOAT32 A2 4 {2A09AF32-34E5-11D3-A479-00105A24D108} l_gear
;UINT32 A6 4 {4D54624D-D897-4408-876E-1E3E38A253B0} l_tire
;FLOAT32 AA 4 {BA9EBED0-34E5-11D3-A479-00105A24D108} r_gear
;UINT32 AE 4 {747D97A8-8770-4FC7-B8F7-1D893A2544BB} r_tire
;UINT32 B2 4 {FBD8EE2C-39A7-4E9C-B527-AA632FE7E50F} engine0
;FLOAT32 B6 4 {9E5C1C91-D1A9-477F-B78C-68AD64D4AF56} f_canopy

Code with unchecked:
;uType uOffset uLen guidParam uName
;----------------------------------------------------------------------------------------------------
;DICT_SECTION
;FLOAT32 98 4 {FC649DE0-34E5-11D3-A479-00105A24D108} c_gear
;UINT32 9C 4 {4CF550DF-134D-4989-BACD-978E3A69D82E} c_tire
;FLOAT32 A0 4 {2A09AF32-34E5-11D3-A479-00105A24D108} l_gear
;UINT32 A4 4 {4D54624D-D897-4408-876E-1E3E38A253B0} l_tire
;FLOAT32 A8 4 {BA9EBED0-34E5-11D3-A479-00105A24D108} r_gear
;UINT32 AC 4 {747D97A8-8770-4FC7-B8F7-1D893A2544BB} r_tire
;UINT32 B0 4 {FBD8EE2C-39A7-4E9C-B527-AA632FE7E50F} engine0
;FLOAT32 B4 4 {9E5C1C91-D1A9-477F-B78C-68AD64D4AF56} f_canopy

So, for GMAX users who build CFS2 model, "Crash" option in MakeMDL has better unchecked for CFS2.

Cheers

Daisuke
 
Thanks for that Daisuke!
Another one to log in the grey-matter....


Hopefully Patrick, that's given you the definitive(?!) list of things to try and reasons why.:salute:


Cheers

Shessi
 
Thank you all for the great input. It proves that Bearcat is once again correct in his omniscient view of this sim. It was the VC.

Thanks all.

PS Shessi, I haven't forgotten the airfile. I'll send it tonight.:salute:
 
PJMack said:
....It proves that Bearcat is once again correct in his omniscient view of this sim. It was the VC.
Click to expand...

Haha...i can't testify to any omniscience regarding this old cyber playmate of ours, but i have had my share of brannigans with it, especially in the area of conversions. :icon_lol:
 
Hi All,
For what it's worth, here are the crash_check bytes ifin you want to do a Frhed hex edit, a trail blazed by Dbolt. Like The B24Guy once stated...sometimes a hex edit saves the animations along with some other items after the basic recompilation.
Myself was having problems with textures occasionally not displaying correctly on the elevators and rudder. So far (two days) they are still showing fine on a C-54 convert.
It's vooodoo I tell you... :icon_lol:

crash_check bytes = b4 ad ec 0e 24 17 c6 41 b9 77 d8 7a 4c 95 44 e8

A simple repetative search for this guy will get you close. In the dict section. é

I gotta quit this stuff, it'll make you nuts! But I can't! :p:
Dave
 
BearCat,

Sorry about asking about the same problem but here it is. I delete the following lines and the model just dissappears. Any further ideas? Thank you.


:L005448
;uName: crash_check uOffset: 0xE4
IfVarAnd( :L005454 0xE4 0xFFFF )
Call( :L005466 )
:L005454
Jump32( :L0055DE )
:L00545A
Jump32( :L1DE18E )
:L005460
Jump32( :L2E61AA )
:L005466
CrashStart( :L0055DC 6425 )
 ;Interpolation Table
Dwd( 176 368 )
Dwd( 16 40 )
Dwd( -2831 -14931 )
Dwd( -20544 -15148 )
Dwd( -14376 -14904 )
 
PJ, don't delete all that. Like i said in post #8 above, "To correct all of these, first delete the entire crash_check line in the top guidParam section. For the other entries, replace the text crash_check with userdefined0."

The portion you've deleted is not in the top guidParam area (also referred to as the dict section). It is one of the proceeding child branches connected to the root dict section entry that i instructed you to delete. Again, for all other child branches, replace the text crash_check with the text "userdefined0".
 
You must log in or register to reply here.
Back
Top