• Which the release of FS2020 we see an explosition of activity on the forun and of course we are very happy to see this. But having all questions about FS2020 in one forum becomes a bit messy. So therefore we would like to ask you all to use the following guidelines when posting your questions:

    • Tag FS2020 specific questions with the MSFS2020 tag.
    • Questions about making 3D assets can be posted in the 3D asset design forum. Either post them in the subforum of the modelling tool you use or in the general forum if they are general.
    • Questions about aircraft design can be posted in the Aircraft design forum
    • Questions about airport design can be posted in the FS2020 airport design forum. Once airport development tools have been updated for FS2020 you can post tool speciifc questions in the subforums of those tools as well of course.
    • Questions about terrain design can be posted in the FS2020 terrain design forum.
    • Questions about SimConnect can be posted in the SimConnect forum.

    Any other question that is not specific to an aspect of development or tool can be posted in the General chat forum.

    By following these guidelines we make sure that the forums remain easy to read for everybody and also that the right people can find your post to answer it.

Convert 'SCASM' scenery item to FS2004 mdl?

C

Chris Eve

Messages
137
Country
jersey
I'm probably overlooking something obvious (or being over-optimistic), but if I take the decompiled section of a "SCASM-style" scenery that contains a "subject of interest", save it as airplane.sca or whatever, then load that file into ModelConverterX, it displays fine.
If I then export it from ModelConverterX as an F2004 mdl it saves fine and will reload into ModelConverterX and display as anticipated ... assuming all texturing names have been dealt with if necessary.
However, if this saved mdl is incorporated into an FS2004 library file, I can't get it to show up in FS2004, even though ModelConverterX will still load and display the library bgl "as normal".
Any indications of where I'm going wrong (assuming the concept is feasible) would be appreciated :)
 
Did you save as a scenery mdl file? I would also check the texture formats, FS2004 does support less formats than newer sims.
 
As Arno says, you can export to two different formats in FS 2004. Make sure you choose the scenery one.
 
Thanks, yes, I'd saved a scenery file, but of course that included the original positioning data so EZ_Scenery didn't acknowledge it as a library file, so I decompiled that bgl, extracted just the model and recompiled that.
Now EZ-Scenery recognises the file as a library, but doesn't show the model in FS2004 even though ModelConverterX shows there to be the model in the file.
It's not a texturing issue (I don't think), the original xxx.0af etc textures had all been renamed to xxx_0af.bmp etc and the references to the original textures in the .sca file changed to suit, so the original still loaded correctly textured into ModelConverterX.

Addendum :
I've since tried loading the original file from ModelConverterX, complete with positioning data, and the model doesn't appear at it's designated location in FS2004, so it would seem that the model is becoming "invisible" during the conversion.

If I'm expecting too much, remembering that I'm playing with a 20-year old program and trying to adapt even older scenery, so be it, it's not a big deal and I can live with the original scenery, but I was hoping there's a tick-box or similar somewhere that I'd missed :)
 
Since you mention that placement and model are in the same file, do you maybe have the same model placed at different locations in multiple files? That could make them geo locked.

And are your BMP textures DXT BMP files?
 
arno said:
Since you mention that placement and model are in the same file, do you maybe have the same model placed at different locations in multiple files? That could make them geo locked.

And are your BMP textures DXT BMP files?
Click to expand...
Sorry, I can't see how the model could be "geo-locked", I've just generated the model from a piece of SCASM source code using ModelConverterX.
Is geo-locking an option in ModelConverterX?
That's the sort of "tick-box" I'm hoping to find, but I simply don't know where to start looking.
The texture files start out as texture.0af, texture.1af etc., so they're probably .R8 files.
To cope with the MakeModel limitations, I rename them to texture_0af.bmp, texture_1af.bmp etc. and edit the SCASM source code to suit.
ModelConverterX displays the generated model at each and every stage, but I can only get it to display in FS2004 in it's original SCASM format.
For the odd one or two instances of any item I'm quite happy to retain the original format, but just occasionally, where I'd like to include multiple instances of the same item, I thought an FS2004-style library object might be more efficient.
As I said, it's no big deal, just trying to tidy up a few bits and pieces around the place ;)
 
Maybe you can share the model and textures so that we can have a look?
 
Attached are some representative files.
Socata_TB20_F-GENS.sca : the original "snippet" from a decompiled SCASM scenery ... this recompiles with SCASM and the resultant bgl displays fine in FS2004 at the original location.
The Socata_TB20_F-GENS.sca file imports into ModelConverterX and displays there fine, but when exported as a scenery file there's nothing to see in FS2004.
The textures have been renamed from the original xxx.0af etc. format to xxx_0af.bmp and the .sca file edited to reflect this for the benefit of MakeMDL, but they remain as R8 type.
Please don't spend too much time or effort on this query ... it really is a "have I missed something obvious" rather than a "can you fix this for me" request :)
 

Attachments

I'll have a look tonight. Always interesting to learn why things do not always work :D
 
Hi,

I had a look at your object. I am quite sure that the textures are the problem. It seems that you just renamed the #AF textures to BMP, but the files themselves are still R8 files. I think FS2004 tries to read them as BMP files now and fails on that. I have used the MCX material editor to convert all files to DXTBMP files (see attachment to this post). I think if you put these in your scenery that the object will show in FS2004 as well.
 

Attachments

Thanks for trying, but no difference unfortunately ... I'd already tried that using DXTBMP to convert the textures, but with no result.
My experiences show that FS2004 doesn't seem to actually care what format the texture file is in with relation to it's suffix, as long as the texture file name is the same as the file name the model asks for and the format of the file is one FS2004 understands, FS2004 will (presumably) read the header of the file, ignoring the suffix, and display it accordingly.
I've subsequently tried a similar exercise using one of the SceneGenX-supplied api macros (just a rectangular hanger with a peaked roof, nothing complex), and the results were the same, ModelConverterX displays the model it exported, but FS2004 doesn't.
FWIW, I tried your textures with the scenery from the original SCASM code snippet I sent and they show fine in FS2004, as do my renamed but unconverted textures!
 
The original SCASM bgl that you send does reference the #AF textures, not the BMP variants.

I'll do another check tonight on the bgl. You should be able to convert an API file without issues to FS2004. That's the kind of conversion I started developing MCX for many years ago :D
 
Hi,

I did just notice that the object has some custom condition for image complexity. That is not something you normally see in a MDL file. Did you add this via MakeMDL? Or maybe it is a left over from the SCASM import.
 
What you could try is load the model in MCX again and then in the hierarchy editor remove the visibility conditions from each node. I think that should solve it.

When importing from SCASM it is maybe better to use user specified instead of visibility conditions for the way variables and conditions are handled.
 
Thanks, but I think this has gone far enough.
I'm really not familiar enough with MCX and it's herarchy editor or MakeMDL to get into all this fine tuning.
I was hoping for a simple import/export solution, which obviously is not going to happen.
I'd anticipated that because MCX could display it's own exported file that the exported file would work in FS2004.
That would appear to not be the case :(
 
I can do a quick export for you to test when I'm home, currently on a PC without MakeMDL.
 
IIUC this is decompiled via Winfried Orthmann's BGLAnalyze version 3.1 into *.SCA source code.

I do not know if it would be any easier to decipher if ScDis was used by Takuya Murakami to output source code, but it might be interesting.


Rather obscure conditional display SCASM code in that BGL; IIRC there was a prior discussion of SeparationPlane / Vector Jump here: :scratchch

https://www.fsdeveloper.com/forum/threads/separation-plane.446575/


I used to tinker with some of these old SCASM / ASM 3D objects. ;)

Usually I had to manually disable *.SCA conditional display code so MCX does not see them as "empty", and to process them as 3D objects. :idea:

GaryGB
 
Last edited:
Gary, I think we already came to the conclusion that the SCA code is not the issue here. Chris has been able to convert it to a BGL file already.

The problem are the visibility conditions. I have attached a new BGL file without these. I am quite sure that will fix the issue.

When working with SCA objects it is probably better to set the "use conditions" setting to "user specified" instead of "visibility conditions". The latter will convert all conditions in the object to visibility conditions, but when exporting as scenery object again these will give issues as neither FS2004 nor FSX supports them in scenery.

1762972363302.png


I am considering to also add an option to the exporter to remove all visibility conditions and mouse rectangles on export. That would be an easy way for users to get rid of them all at once in case they want to export without them.
 

Attachments

Thanks for your continued efforts ... this final version seems to have just about cracked it :)
Attached are two screen shots, suitably named.
There's a slight anomaly under the right wing, where the pitot tube is on the original, and at the top of the tail, which was probably a light, but the basic principal is now giving a visible model :)
Bearing in mind that this example was only ever a "representative file", one I happened to have on my desktop when I initially wrote, I see no advantage in trying to "fine tune" it, but if you could document the procedure so's I could use it for when I have multiple instances of the same object, that would benefit from being in an FS2004 library, I'd appreciate it.
I have some "bought and paid for" commercial scenery from many years ago that looks very nice, but which was produced before photo scenery for the relevant area was published, which would benefit from a degree of "realignment".
I know many of the scenery components are replicated, so being able to assemble a library and just "slide" the items into place using EZ-Scenery will save an awful lot of manual editing ;)
The final effort will only ever be for my own enjoyment, not for sharing or distribution, so copyright issues shouldn't arise.
 

Attachments

  • from MCX.jpg
    from MCX.jpg
    156.2 KB · Views: 25
  • from SCASM.jpg
    from SCASM.jpg
    150.2 KB · Views: 16
I have occasionally encountered such objects- what I do is go to the MCX Hierarchy Editor, find then in the list, and click Remove. Hopefully they have not been combined with other objects by MCX - if so, there is a setting called something like CollapseAll or CollapseParts that can help with that. Make it false. Only works when Importing a new object though.
 
You must log in or register to reply here.
Back
Top