Question for MDLC gurus

G

gavinc

SOH-CM-2022
Hi,
the recent discussions about using MDLC & scasm code and editing aircraft models to enable features that are't normally part of the CFS2 realm, changing the rear canopy key mapping to front canopy etc, has brought me back to have another go at a problem that has bugged me off and on for a while.

Does anyone know why the following happens and how to fix it?

There are specific models that exhibit this behaviour, for example Greg Peppers HU-16 Albatross for FS2004 (v2) and the C-46 Commando by Greg Pepper, Tom Gibson and Libardo Guzman. (And it is not just a Greg Pepper problem - it just so happens that those are the 2 aircraft I have in front of me)

If I convert the model to CFS2 format using MDLC it works fine. However if I then create scasm code of the CFS2 converted model and recompile it (without making any changes whatsoever to the code) , the recompiled model will cause CFS2 to crash.

It gets stranger because the crash doesn't happen immediately. I can start CFS2, go into free flight, pull up the aircraft and fly with it just fine, I can change views (Panel, HUD, VC, external etc) no problem. Then when I go to change the plane for a different one, or end free flight CFS2 will crash. Sometimes if I start free flight with a different aircraft, switch to my bad boy, and switch back it will behave - as long as I don't change the views. If I change the view then bang CTD.

the commands I am using are as follows

create the SCASM code
MDLC /a foo.mdl foo.sca

recompiling the SCASM code
MDLC /m foo.sca foo.bgl
MDLC /l foo.bgl foo.mdk
MDLC /c foo.mdk foo.md2
MDLC /t foo.md2 foo.mdt

copy foo.mdt foo.mdl

There is another curve on this issue (as if it wasn't bad enough)
I have managed to get a lot of the animations corrected by using a variant on Caleb Flerks directions on editing mdl files.
I edit the scasm code and then create a bgl directly using SCASM. Then I open the bgl file and the mdl file in a hex editor (I am using Frhed) and copy the data from the bgl to the mdl file. This works great if I am changing something that already exists (ie. connecting a rear canopy to the front canopy), however if I have to change something to something new (i.e. replace the water_rudder GUID with the Concorde Visor GUID as an activating keystroke for landing lights) then the revised triggering key doesn't work. I know that the change is valid and will work because if I take the edited SCASM code and re-compile and link it via MDLC the new key will trigger the animation correctly but CSF2 will CTD everytime.

Anybody have any thoughts or suggestions?

Thanks
Gavin
 
Hi Gavin,
I know what you mean, it IS strange why some ac either do not compile or cause a CTD??

A couple of things, I take it you are using MDLC 1.90 either in command line or mk_MDLC?

The C46 is a Gmax model and if all the ones that crash are Gmax, then there might be the answer.

You know that you do not have to go to those lengths to change a simple ani, that can all be done in ASCI with the scasm'd mdl in one go.

Have you tried scasm-ing the mdl before conversion ie changing things whilst still an Fs9mdl, then re-compiling to a CFS2 mdl using /m, l/, /t, /c with a f switch to force CFS2 anis?
It may be that you are converting the /t anis last where the /c with an f switch should be last?


Cheers

Shessi
 
Hi Gavinc,

This is what I have been using, but do not know for sure if is going to fix it. I have found some models do not cooperate well with mdlc for some reason (beyond my capability to understand it). Also check opcodes at the end of the scasm to see if mdlc listed any that could not be found.

Converting to SCA to edit and back to MDL

mdlc /b foo.mdl
mdlc /a foo.mdl

edit sca

mdlc /m foo.sca
mdlc /l foo.bgl
mdlc /c foo.mdk

rename foo.md2 to foo.mdl

Command: /a = convert to Scenery Assembler Source (SCA) file
/b = convert to Scenery (BGL) file
/f = convert to Flight Simulator 2002 (MD8) file
/c = convert to Combat Flight Simulator 2 (MD2) file
/x = convert to ASCII Drawing Interchange (DXF) file
/t = fix Animation Table and output to (MDT) file
/r = add Visual Model reflective texture to (MDR) file
/s = set Visual Model shining and output to (MDS) file
/z = set Visual Model size radius output to (MDZ) file
/m = compile Scenery Assembler Source file to (BGL) file
/l = link Scenery file to Flight Simulator 2002 (MDK) file
/w = link Scenery file to Scenery Library (BGK) file

For batch file for compiling:

mdlc /m foo.sca
pause
mdlc /l foo.bgl
pause
mdlc /c foo.mdk
pause
ren foo.MD2 foo.MDL

I Reccommend using the pause, which request a "press any key to coninue" after the previous command. For my pc, this gives mdlc time to complete its task before going to the next command. It caused problems for me without the pause in the batch file. Also it gives time to view to see if mdlc was able to complete the process without errors.

I hope it helps out some.
 
Just got the C46 and changed a few things in scasm, recompiled ok. Now initially it fired up ok and changed ac, views etc etc no ctd. Then it started to do it, not every time. I thought it may be the texs, took those out, and no. Sometimes panels can cause odd probs, but changed it to a simple cfs2 one, and no not that either.

I've removed the g-lightstates and crash check, so it's not those. I think it may be the mdl size and/or Gmax models??? OR????

Shessi
 
I don't for sure what causes random crashes especially when switching models, but I have observed the same recently, so you are not alone. I have also one or two models that will not recompile causing mdlc to crash, even when I haven't edited them.
As for hex editors , HxD here has more features than frHed. For editing large text files like scasm sources I am now using Context here.
I have at sometime thought or maybe heard that crash checking causes random CTD. I know that stock CFS2 planes don't have crash checking built into their models. In stock CFS2, crashing with scenery objects is handled via dp, crashing with AI is done by comparing the model size entry in the mdl headers.There is a setting in MDLC.ini for it.
But the FS crash checking does work in CFS2. If you fly a plane with crash checking into an fs2k2 scenery object you will crash with it, if you fly a stock cfs2 plane into the same object it will pass right through. Recently I have left crash check in place. It does not always causes a CTD. More research is needed.
As for models that won't recompile. Recent models are so detailed scasm throughs a line buffer error. So when MDLC writes the .sca file it doesn't check the linebuffer setting passed to scasm.
The entries in the sca file after the DICT section and before the bgl section.
Code: 
Set( RAW 1 )
Set( BUF 4096 )
Set( LABELS 9000 )
Set( PATCHES 9000 )
Set( LINBUF 8192 )                   <<<<<<<<<<<<<    double this for models with big vertex lists
Set( MAXPTLST 3000 )
Set( FSVERS 0x0732 )

mdlc /m foo.sca
pause
mdlc /l foo.bgl
pause
mdlc /c foo.mdk
pause
ren foo.MD2 foo.MDL
Click to expand...
Good tip Mr Oglivie

I've removed the g-lightstates
Click to expand...
g_lightstates causes CTD when the plane is AI.
mdlc disables by setting to userdefined0, but this leaves behind the actual Lights, Ive had problems with these. Randomly being on , especialy when using userdefined0 for something else. maybe some instability there. Models with no Lights seem more stable, more research needed there too.
 
Hi guys,
thanks for the insights, I have a few things to try this evening when I am at home.

I have been using MDLC 1.90 but I just went back and tried the process via MDLC 1.68 and the CTD seems to be resolved but it no longer recognizes the visor key stroke.

Shessi - yes thanks, I do realize that I can do multiple edits on the source code and re-compile it in one go. I was just trying to verify that the issue wasn't caused by my modding of the source code. What do you use as your hex editor? I am using Frhed but haven't figured out how to search for the hex strings directly.

Gavin
 
Hi Gavin,
I wasn't insulting your inteligence, honest! :jump: I was just making sure you knew all the 'moves'.

Like you I use Frhed, but you can't search easily with it. I also use Hex-editor XVI32 at http://www.chmaas.handshake.de, which makes it a lot easier.
I'll certainly look at Simons editors. There seems to be many more these days when they're not so needed!!

Cheers Shessi
 
Shessi said:
I wasn't insulting your inteligence, honest!
Click to expand...

You can't insult something that doesn't exist:icon_lol:

I haven't had a chance to do thorough testing yet but it is starting to look like a dual MDLC approach might work.
I have created the scasm code in MDLC 1.90 and then re-compiled to an FS2002 model. Then take that FS20002 model and convert to CFS2 using MDLC 1.68.
I have only had time to do 1 basic test but the animations all work and it didn't CTD. On holidays all next week so hopefully I will have time to do a bit more thorough testing.

Gavin
 
Not much good news.

Hi all,
Hope you are all having a good holiday season.

Well unfortunately I don't have a lot of success to report. If I take one of these problematic models, decompile to scasm and recompile I am still getting intermittent errors and CTDs. It appears to be less of an issue with 1.68 than with 1.90 (quite often with 1.68 the compiled model will only cause the CTD upon exiting of CFS2) still frustrating. The only clue I have is that it appears to be re-writing the ppath.log file sometimes. Unfortunately ppath.log is a binary file so no smoking gnu there.

There is some good news tho. If you have a model that behaves well if you just do a normal conversion, you can insert the modified code into the well behaving model and it still is well behaving (ie no CTD). Compile the model to a bgl using SCASM and then use Caleb Flerks method to copy data from the bgl and paste it into the model file
http://www.cfgse.calebflerk.com/CFG_Step5.htm

Hope this is useful to someone.

Gavin
 
gavinc said:
If I take one of these problematic models, decompile to scasm and recompile I am still getting intermittent errors and CTDs
Click to expand...
Hi gavinc, Happy Holidays,
I just wanted to point out an item that CFS2 will not accept. These have given me intermittent CTD's in the past.

They are the light codes you can find when the model is in Scasm format. They're un-associated with g_lightstates so as not to be confusing the two.

Here is some information provided to me by Bc 241 for a different topic...but the same still applies.

********************
First, you create and run a cmd *.bat to convert the FS9.mdl to a FS9.sca file and *.mdd file simultaneously (and not with the mk_MDLC interface). Next open the *.sca file with Scasm Editor. Find the lights and change their coding from "3" to "10". In the case of this F104 there are two lights to change (the F4's only have one):

Example

Light( m 3 0.0000000000 0.0000000000 0.0000000000 20 0.6000000238 0.4000000060 C0 255 192 192 0.0000000000 0.0000000000 1.0000000000 )

TO:

Light( m 10 0.0000000000 0.0000000000 0.0000000000 20 0.6000000238 0.4000000060 C0 255 192 192 0.0000000000 0.0000000000 1.0000000000 )


types of lights

0 = beacon

1 = ?

2 = ?

3 = taxi light

4 = nav light

5 = landing light

6 = strobe

9 = project landing light on ground only (FS8)

10 = proj. taxilight on ground only <<<<<<<<<<<<<<<<<<<<<<

11 = draw landing light cone only

12 = draw taxi light cone only


Save the *.sca and convert it to a *.bgl. Then create and run a cmd *.bat file to link the bgl and the *.mdd into a *.mdk file for FS8. Copy the *.mdk to the aircraft's model folder and reame it as the original mdl after backing up the original. The run mk_MDLC to convert to CFS2, fix animation and set collision bubble to "6" for a good size in the selection window.
*************************

If the original model has wing landing light set at 3 = taxi light, I've gotten CTD's intermittent.

Changing them to 10 = proj. taxilight on ground only has cured this with the added benefit of the landing lights remaining folded up to the wing instead of uselessly hanging in the down position. The edits were done while in Fs8 .sca form.

I would really hate to send you on a wild goose chase, but on some models this has worked for me in the past.

It might be worth a try. :ernae:
Dave
 
Shessi said:
Like you I use Frhed, but you can't search easily with it. I also use Hex-editor XVI32
Click to expand...

XVI32 has the Hex search option. The only way I have found to do it with Frhed is a bit more complex, but it works. For a bit more exitement: Convert the hex searching for to decimal. Then using the number pad on the key board, hold the Alt key down and type the decimal equilvalent number on the number pad for each of the hex (two digit) numbers with Num Lock on. I use Notepad to display the characters and then copy and paste to the Frhed search window.
Much easier though to use XVI32 for hex searches.

Sample:
Hex = 4e 45 4c 33
Dec = 78 69 76 51
Numpad characters = NEL3 (Frhed search characters)

Merry Christmas
:ernae:
 
And the provisional winner is ....

It looks like Dave may be on to something.
dvslats said:
Changing them to 10 = proj. taxilight on ground only has cured this with the added benefit of the landing lights remaining folded up to the wing instead of uselessly hanging in the down position.
Click to expand...

I went thru the Greg Pepper Grumman Albatross model and changed the Lights to 10. So far no CTD.

The lights in this model were coded for 9 & 11 not 3 but it still seems to have helped. The landing lights weren't rotated up into the wings by changing the lights code but a quick bit of rotation table manipulation fixed that. At the same time I connected the landing lights to the concorde visor key and so they can now be raised and lowered at will.

Thanks for all the help guys.

Gavin
 
We are all winners Gavin, I for one have learned something very useful. I had figured that Lights made models unstable and so have been removing them by simply commenting out. Now I have learned we can keep the light coding and just change a single parameter. Much more satisfactory.
 
You must log in or register to reply here.
Back
Top