• 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.

FSXA Taxiway lines

Messages
13
Country
italy
Hi everyone!

I'm having a little problem in porting an airport designed for FS2004 to FSX. In this particular airport, taxiway lines are generated using scasm commands rrstart and roadcont, preceded by the correct declaration of loadbitmap.
Now, these lines DO show up, the point is that they have the default high traffic road texture, even though the rrstart command specifies to use the last loaded texture. I even tried with a color instead of a texture (setting the first parameter value to 0 in rrstar, of course), but they keep showing up with the default road texture.
Just to be sure of my process, I tried to render them with the first parameter set to 4 (railroad if I remember correctly), and they do use the default railroad texture. I even tried with 6 (which shouldn't be a valid parameter) and they get rendered with the default concrete texture oO

What am I doing wrong, here? Is this approach supported by FSX?

Thanks in advance! =)

P.S.
I'm not 100% sure these lines are rendered through scasm code, I just decompiled the relative bgl file into a sca file and it looks correct (indeed, it recompiles without trouble).
 
Hi,

I never tried to use these old commands in FSX, but I wouldn't be surprised if they do not work anymore. This technique is really from the time of FS2000 and FS2002.

You could try to load the file in ModelConverterX, it might produce some polygons with the same shape as the lines.
 
Thanks for the suggestion, arno.
Indeed I tried to open it up in ModelConverterX, but it fails to import it (I don't remember the actual error, if you need it I can tell you) and there's nothing shown, not event the basic grid.
 
Hi,

The error might help indeed.
 
Well, if I try to open the original bgl file in ModelConverterX I immediately get an error saying "The file <file name> is of a non-supported BGL format".

If instead, I decompile the bgl into a sca file (using a very old version of bgl analyze, it should be version 3.1, for decompiling FS98, 2000 and 2002 bgl files), recompile it with the latest version of scasm and open it in ModelConverterX it take a bit longer to open it, but in the end I get a lot of warning and information entries, and no object opened. Just to be thorough, when I open it, it presents me a dialog asking for a value for variable "tod", by default set to 1 (which I don't modify).
I'll list all entries (a lot are repeated):
- Unknown BGL opcode A8 at position 46
- Trying to continue after last jump, might be data block
<repeat the above many times, I guess 200, see later>
- Unknown BGL opcode A6
<this one above only once>
- Starting reading of subobject <n> (where n is from 0 to 199)
- Unsupported command AntiAlias in line 64
- Finished reading of subobject <n> (where n is from 0 to 199)
<repeat the 3 above 200 times, from 0 to 199, generally with odd values missing the unsupported command warning, but sometimes having 2 consecutive objects with the unsupported command warning, thus swapping the order of skips>

Now, looking at the scasm file, there are indeed 200 objects (plus one flatten polygon which doesn't seem to be taken into account by ModelConverterX). Following the same rule seen in the list of warnings in ModelConverterX, I have "objects" composed of road commands (these generate the unsupported command warnings) and "objects" composed of dot commands. I don't know if this is useful.

Maybe related to the problem, if I reopen with ModelConverterX a ground polygon bgl converted for FSX using ModelConverterX ground poly wizard, the program is able to open it, but I still get a Uknown BGL opcode A6 warning once. Any clue what this may be?

Once again, thanks for support! :)
 
Hi,

Let me take a look. It could be that those road commands are not supported yet, you are probably seeing their opcodes in the log.
 
I think your right. I don't have the exact errors here, but I remember trying opening the scasm file in ModelConverterX and it was unable to interpret road commands...
 
Back
Top