New ways to have fun with CFS1
Introduction
Welcome to this HTML version of my thread.
My main objective here is to show you another way to have fun with CFS1;
building things.
Consider this as a hobby, a pastime activity, not as a tutorial on
making macros for scenery or making aircraft to fly with. That said,
you may just end doing just that!
With the help of a few programs, all free, we will
build simple visual objects that can be integrated as static or moving
objects into the game. As we go along, structures will get more
complicated but, I hope, the learning curve will be very progressive.
As I have other activities, time between posts should be irregular and
sometimes quite long, but each of them will leave you "enough meat to
chew on". Don't hesitate to experiment on your own while waiting for
the next installment.
The HTML version will keep basically the narrative of the thread version but the structure will be divided in chapters and sub-chapters rather than posts. Each chapters will include many posts regrouped by subjects. Only the posts relating to the subject will be kept and any third-party posts that I keep will be duly attributed to his (or her) original author.
Chapter 1
The aircraft container
We will work mostly with MDL files, the core of any CFS1
aircraft. So, a short description of it is in order. If you go and open
an "aircraft container" (Microsoft® sophisticated way of calling an
"aircraft folder") in your
CFS1 game folder, you will probably find something like this;
This is a "basic" P-51D aircraft container (sorry for the "ugly" W98 style) without any changes.
The P51d_CHECK.CFG file contains the checklist, not always present in all aircraft. It can be opened an modified with at
TXT editor, providing that you have privileges to do so.
REMARK; From Windows VISTA and on, you need "user account" control to dabble into configuration files. This apply to all
CFS1 CFG files and may apply to other files as well.
The P51d.dp file is also a text file, containing the damage profile. It is also taking care of weapons and special effects.
The P51d.CDP file only exist if you have flown this particular aircraft. It is a "digest version" used by the game engine
(COMBATFS.EXE) to speed things up. If you open it with a TXT editor, you will find that most of the inscriptions are not for human consumption.
It is never edited. You can delete it safely; it will remake itself next time you fly this plane.
The P51d.air file is taking charge of the mechanics of the aircraft. It can be read and edited with specialized programs
(AirEd, FD Editor, AirWrench, to name a few). We don't need to do that for now.
The texture sub-folder contains the textures applied
to your specific aircraft. Note that stock aircraft have a "fall-back"
set of textures in the main
CFS1 texture folder. So, if you emptied the aircraft
texture folder, chances are your aircraft would still be painted! With
an add-on a/c, you would get unpainted surfaces. The
CFS1 main texture folder is also used for buildings and
statics objects textures and, since stock aircraft can be used as
static objects, their textures can be found there as well. It seems
that the game searches first in the aircraft container for textures
and, by default, goes to the main texture folder. These textures are
using the exact same name but are usually of lesser definition quality.
The sound sub-folder contains a sound.cfg file and, often, WAV (wave sound) files. If you only have a
sound.cfg file, chances are your aircraft is using the sounds of another aircraft by
aliasing to it. This is a good way to save disk space. The sound.cfg file can be read and edited with a
TXT editor, the WAV files with a sound editor.
The panel sub-folder also has a configuration file; panel.cfg. If alone, your panel is probably
aliased to another aircraft. You can open and edit this file with a
TXT editor but I would recommend the use of CFGEdit, especially for beginners. It is a
WYSIWYG environment that makes more sense. Our good friend smilo is an expert in panel configuration and do his own with a
TXT editor. I do mine using both methods. The panel sub-folder may also contain
BMP files which are used for 2D panels. The panel.cfg file will call these visual elements as well as
GAU gauge files, found, in CFS1 gauges folder,
to create interactive 2D panels (and 3D non-interactive panels in some
cases). There would be more to say on the matter, but this is
off-topic... at least for now.
Almost last, but not least, the model sub-folder. Again, we have a configuration file named, here,
model.cfg. It can be opened and edited with a TXT editor. Let us have a look into it;
[models]
normal=P51d_n
crash=P51d_c
[colors]
; body - predominate color on plane
00=WHITE
; wing - color of wing, flaps, ailerons
01=WHITE
; altbody - two tone body part
02=WHITE
Under [models] header, we have two MDL
files being called. The "normal" represent the model as we see it most
of the time. In fact, especially in add-ons aircraft, it is often the
only entry in the file. The "crash" model contains the "body parts"
that we see flying of an airplane loosing a tail, a wing, and so on.
The [colors] header is the
remains of an old texturing technique. The "stock" Sopwith Camel is
using it to its full extent. If you want to know more, go download my
10_camel.zip add-on to be found HERE .
The XYZ.mdl file is, as previously stated, the core of any CFS1 aircraft. As I just said, it is often the only other file with the
model.cfg file in this folder. This is what we will be working
with most of the time. This is our bread n' butter for what we will do,
so we will explore it in depth.
If you open it with a TXT editor (WordPad will do), you will find a lot of gibberish with tidbits of comprehensible language. Here is the first line;
Apart from "This program cannot be run in DOS mode.", not much to
make of it. But this little information is useful to learn that, in
fact, a
MDL file is a program! Without going into details (which, for the most part, I'm ignorant of anyway...),
a MDL is a DLL-like program. If you look a bit further, you may find this;
In all these hieroglyphics, you can at least understand
"P51Tex2.bmp" and "P51Tex1.bmp". These are parts of calling
instructions for textures. This is what I referred vaguely to as "the
game" in the
texture sub-folder paragraph. The MDL file, when used by you or the AI a/c, is a program being called by
COMBATFS.EXE, itself calling textures. In fact, it does much
more; it contains spatial coordinates indicating pitch, yaw, roll axis,
speed, altitude, collision "bubble", gear extension, flaps extension,
air brakes... the list goes on. Following that section, the visual
model is being called by a
BGL-like section, where the textures callings we have seen are being made.
You may have heard of BGL files before; they are
commonly found in scenery folders. The type of visual instructions that
they contained is virtually identical to what is contained in the
virtual instructions of a
MDL file. The main difference is that one moves, the other don't (or barely does in relation to a static position). I will let you
guess which is which...
To close this first sub-chapter, a word about one last file; aircraft.cfg.
If XYZ.mdl is the core of an aircraft container, aircraft.cfg is the maestro conducting all parts. Looking at our
P51d aircraft.cfg, a TXT editor will do, we see;
[fltsim.0]
title=North American P-51D (This is the name you will see when choosing that aircraft)
sim=P51d (This is the name you will see as a "tag" in the game, it also calls DP, CDP and AIR files )
model= (This is to call the model folder. If left empty, it calls the "model" folder by default)
panel= (This is to call the panel folder. If left empty, it calls the "panel" folder by default)
sound= (This is to call the sound folder. If left empty, it calls the "sound" folder by default)
texture= (This is to call the texture folder. If left empty, it calls the "texture" folder by default)
checklists=P51d_CHECK (this is to call the checklist)
[forcefeedback] (This is for force feedback sticks)
(...)
In the same aircraft container, you may have different
combinations of model, textures, panels, sounds, DP, AIR, checklists.
In theory, you could take all your aircraft and crammed them into one
big aircraft container. In practice, you use that system for a few
aircraft that share almost identical material, creating incremental
headers [fltsim.n] n=1,2,3,4, etc. I don't know if there is a limit and
I'm not tempted to experiment on that subject.
You don't have to learn by heart all of this; just remember where it is for future reference. It may get useful.
Gutting a model
This diagram illustrate what we're going to do. We will extract the BGL-like part of a
MDL file (this procedure is also called "disassembling"), and
remove the visual code from it (hence the "gutting") and build our own
visual object to take its place. Once done, we will save that
BGL-like code and install it back in the same MDL file ("assembling" or, in this case, "reassembling"). This will be our working platform from now on.
First thing we need is a functional "aircraft container" with a model folder and a
MDL file in it. We need a very simple MDL without animation. There is many different
MDL files, but the one we will use is a MDL610 file. This is a very common
MDL used by AF99 and its grandpa, AF5.
I have chosen a very old aircraft, originally designed for FS4 with AAF (Aircraft Adventure Factory) by Bill Grabowski and converted for
FS5 with FSFS (Flight Simulator Flight Shop) by Chuck Dome; flankr.zip. You will find this file at FlightSim by typing or copy/pasting
flankr.zip in the "File name" basic search
engine. If you can't access FlightSim downloads, go get this alternate FS5 model from
Schoichiro Homma.
Once unzipped somewhere (desktop will do), you will find something like this;
The SU27.DOC file is only there for id and credits. In fact, the whole aircraft is in this "Swiss knife"
SU-27.AIR file! FS4 aircraft had no texture and Chuck Dome kept it that way. The alternate file
(mdfedex) is FS5 material and contains textures, but the Mdfedex.air file still contains all the rest.
We now need to convert our FS5 aircraft into a CFS1 "aircraft container". Luckily, this is exactly what
CFSCONV.exe, a program very often overlooked, is doing. You should find it in
CFS1 main folder. The icon look like this;
If you don't have it, you probably made a custom install. You will have to fetch it from your CD.
Once you open the program, you should get this window;
, click on Options to make sure that
CFS1 main folder and its aircraft folder are showing the right paths;
, we don't want to have to search all over the place for our new
aircraft. Next, we should click on Convert Aircraft Files and navigate
to our AIR file;
Double click on that file and voilà! The SU-27 aircraft container (Mdfedex for the alternate) is in your aircraft folder, ready to go for a spin as
Sukhoi SU-27 Flanker;
or as md11 federal exp;
I invite you to go and fly these at least once. Misters Grabowski,
Dome and Homma do deserve at least an honor flight for their pioneering
work. You will note that the red star and the 02 have been "etched"
with lines. Cockpit, pilot and gears' legs are also "suggested" by
lines and simples polygons. There is a lot of bleeds but, quite
frankly, I have seen worst in much more recent aircraft. Chuck Dome
aerodynamics are remarkably good. How many converted aircraft have I
flown that were jumping like Mexican beans all over the runway and felt
like iron with tiny wings? Not this one! Mister Homma aircraft is
almost to par with what
CFS1 has the best to offer.
This shouldn't be much of a surprise. Most FS98 aircraft that were ever released were "converted"
FS5 aircraft, and many made it to CFS1 as well.
Now, it is time to adapt our newly created aircraft container to our need. From this point on, I will work on
SU-27 only, you will have to adapt if you're using Mdfedex. Go to your
CFS1 aircraft folder and find SU-27;
You will note that there is no checklist, which is common in
CFS1 add-on anyway. Also, no DP or CDP files. This aircraft is using a default damage profile that you can find in the
CFS1 aircraft folder (default.dp). It is basically the Spitfire Mk IX
DP. This is why an imported Cessna from FS98 suddenly becomes a very mean machine.
The texture folder is empty. If it is not, do wipe it clean but
keep the folder. Do the same with panel and sound folders. If these
folders are not there, the aircraft will simply not show in game. But
we do not need to keep anything in them.
We will change the AIR file now. Copy and paste ShDEST.air from my
AAC Destroyer Ship, part of the AAC fleet (aacfleet.zip
HERE), in the model folder of SU-27.
This is not a ploy to increase my "hit" numbers. It took me an
inordinate length of time to get this very stable, flushed to the
ground,
AIR file done. We may as well take profit of all this hard work.
Rename ShDEST.air to playground.air. Eliminate SU-27.air;
Open the model folder. Using a TXT editor, open and modify model.cfg to read under
[models] header;
normal=playground
save and close
Rename SU-27.mdl to playground.mdl.
, close the model sub-folder.
Open the aircraft.cfg with a TXT editor and change the entries for the following (you can copy/paste if you want);
[fltsim.0]
title=SCASM playground
sim=playground
model=
panel=
sound=
texture=
checklists=
Save and close. Now, a few changes in the AIR file are in order. I would suggest
AIREd (found at Simviation
HERE) to do so. First, a few "cosmetic" changes. Feel free to copy/paste.
Under section #1 (Aircraft Name); playground for SCASM
Under section #2 (Description); A place to have fun building things.
Under section #4 (Registration); none
Under section #101 (Normal Model File Name); SCASM playground
This part is a bit less cosmetic, so pay attention to modify it strictly along what follows;
Under section #301 (Fuselage);
(...)
*Cockpit View Above+/Below- CoG (in)= 60 (it will give 59.9769)
*Cockpit View Fore+/Aft- CoG (in)= 0 (it will give 0.000)
Close and save. This will place your Point Of View (POV) five feet above ground over the center.
Now, time to close SU-27 aircraft container and rename it playground.
The only original thing left is Grabowski (or Homma) visual model. In the next post, we will take care of that.
Final gutting
We should get some tools first.
To disassemble playground.mdl, we will need a program called MDLDisAs
(HERE) by Trevor de Stigter. Install first the
mdldisa32.zip and, on top, mdldisa3z.zip, the latest version of MDLDisAs (v. 3.0.4.618).
MDLDisAs is a GUI (General User's Interface or "Front End") for Manfred Moldenhauer
SCASM (SCenery ASseMbler). Download the latest version from
HERE and just put it somewhere handy.
MDLDisAs folder would be a good place. Just make sure MDLDisAs path to
SCASM is correctly entered. The Source Code Files Directory should be on desktop or any other easily accessible place for you.
I also recommend that you get the HTML help file from HERE. In fact, you should get all the goodies on that page while you still can.
We also need a robust TXT editor. Notepad or WordPad simply can't do the job. My own text editor is payware
(EditPad Pro) but, in my incessant pursuit of cheap solutions, I have found a little gem called
Notepad++. You should download the
ZIP file and install by unzipping in a convenient place, then delete the
UNICODE folder. Associate TXT and SCX files to notepad++.exe. You don't teach an old dog new tricks, but I'm very tempted to make the switch myself, this is how good I think this
TXT editor is. Tell me what you think of it.
One last tool to install; FrHed. It is an hexadecimal editor, very useful when you need to tweak something that isn't in the
BGL-like portion of the MDL. Choose and install a stable version (duh...). You should associate
MDL files to it.
WORKING PLACE
What follows is how I work. You may skip it and stick to what's
working for you. But this method will save you time and pain on the
long run.
Create a folder on your desktop, name it whatever you like, mine right now is
"SCASMING FUN". Get shortcuts for the CFS1 game, the MDLDisAs,
FrHed, and any other apps you may use. This is also where you will keep your working
SCX files, the Source Code files, that are your "masters". NEVER let a newly disassembled
SCX file get in there! Why? Simply because you don't want to
overwrite your "masters". Imagine a file that you took months to
elaborate snuffed in an instant. As for me, I don't have to imagine
that... I'm just trying here to save your sanity.
BACK TO WORK
Open MDLDisAS.
And keep it open until I say otherwise.
After a short nagging delay (the only restriction on this shareware), the OK button activates, click on it.
Click on Open File and navigate to your playground "aircraft container", and then to your
playground.MDL.
Open it. In doing so, you're not only loading that
MDL file, you are also indicating the return path.
If everything was OK, you should see something like that. It indicates the type of
MDL file loaded, textures (if any), the path, the file data length and the bytes remaining. The
CkeckMdl button is for when ... hit the fan. This shouldn't be the case, hopefully. So click on
Next.
Make sure that all the settings are the same as in this picture;
Source Code File Content= Std Source Listing
Structure Dimensions in= Feet
List Textures Vertices= On One Line
Designated Assembler= Scasm.exe
This is only so that we can follow each other. Once on your own,
do as you please. We now click on Save File. You will be invited to use
the name
playground.scx and to put it, if you have followed my advice, outside of your working place. Do so. Go copy that
playground.scx and paste it in your working place. One more precaution; change the name (like
playgroundM.scx) to protect it even more against overwriting mishaps.
Now, open the playgroundM.scx file with Notepad++, this is what you should see;
Explanations will come later. For now, scroll down to line #91 and
highlight all the way to line #1352 for Gabrowski visual code, then
delete;
If you are unsure, especially if you're using Homma's longer visual code, the first line to delete is just under the label
:L001284. The last line to delete just before EndA. This should look like this once the deletion is done;
In-between :L001284 and EndA, I want you to put exactly these lines (copy and paste if you want);
Points( 1 ; 4 points
0 0 780 ; 1
0 1560 780 ; 2
0 1560 -780 ; 3
0 0 -780 ; 4
)
SurfaceColor( 05 F0 )
Poly( ai 1 2 3 4 )
SurfaceColor( 06 F0 )
Poly( a 1 2 3 4 )
Return
This should give you that;
Save and close playgroundM.scx. In MDLDisAs window, click on Use Existing File and navigate to load
playgroundM.scx, then click on Assemble. If you see this window , congratulation! Click on
OK. If you get an error message, abort and find what went wrong. You can still copy and paste, then rename
playground.scx to playgroundM.scx, and redo everything.
Once you've clicked OK, a new window shows-up;
You will note a huge reduction in Data length. Click on Update .MDL, say
YES to backup, then go see in CFS1 what its look like;
We have created a 10x10 feet "wall", red on the right side, green on the left. Misters Grabowski and Homma models are gone.
Tidying-up the place
Don't be alarmed if you see two new files in your working folder, it is only normal.
SCAERROR.LOG contains the last error (or success) compilation message and
playgroundM.BGL is a by-product of assembling from playgroundM.scx. Leave them there as they will simply be overwritten next time around.
We will now return to playgroundM.scx to explain briefly what is in it and do some more cleaning.
;*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~* ~*~*~*~*~*~*~*~*~*~
; File: playground.SCX **** Disassembled Graphic Drawing code ****
; Taken from Aircraft Model File playground.mdl
; Produced by MdlDisAs v3.x unregistered
;*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~* ~*~*~*~*~*~*~*~*~*~
This is pretty much self-explanatory. Note that all lines are preceded by a semi-colon
(;). Anything right of a semi-colon on the same line is disregarded by
SCASM during compilation.
Set( FSVERS 700 )
Indicates for which sim version the SCX file is set. 700 means FS2000. For
CFS1, it should be 650, and 610 for FS98. Since all CFS1 commands are still valid in a
FS2000 SCX, this is not a problem.
Set( RAW 1 )
Set the RAW (Read And Write, I think) without Header. A Header is normally the start of a
BGL file and gives geographical position of the object. RAW files are used by moving objects for obvious reasons.
Set( BUF 256 )
Set( LINBUF 256 )
The first line sets the maximum buffer size in KB. The second sets
the size of the internal line buffer for compilation, also in KB.
Area( R )
A very important command! It declares an area of visual commands. When set to
R, it is for RAW Header-less objects. Finishes with EndA command.
;*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~* ~*~*~*~*~*~*~*~*~*~
;*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~* ~*~*~*~*~*~*~*~*~*~
; Comprises 33 Individual Structures as follows:
; All dimensions in Feet
; Start Points Fore Aft Bottom Top Port Stbd
; :L001908 2 0.00 2.95 6.40 6.69 0.00 0.00
; :L002B84 17 2.95 11.71 5.98 10.14 -2.07 2.07
; :L002DAC 24 11.71 51.67 6.10 11.91 -2.45 2.45
; :L001B4C 5 13.00 14.96 10.34 11.12 0.00 0.00
(...)
Was a list of SU-27 structures (parts, lines,
dots, components...) with useful information to find them. As all lines
are preceded by a semi-colon, this was not compiled. But all that is
gone now! We will erase all of it to keep only the firsts two lines in
case we need to place some comments later. This should look like this;
:L001204
Every time you see a colon (:), you're facing a
Label. Each Label is unique within an area, but can be called many times. A colon without characters forces a jump to the end of the area
(EndA). A maximum of 15 characters immediately after the colon are permitted for the
Label, case sensitive. Only letters and numbers. MDLDisAs, when compiling, uses the hexadecimal position in the
MDL to name Labels. This is why our "masters" are so important as lines are constantly changing from one iteration to the next. Most
MDL610 file start at HEX 1204. If you are curious, open playground.mdl with
FrHed and, using Edit > Go to > x1204, you should see something like that;
All that is highlighted in yellow correspond to the visual code we have introduced in the
MDL. Not much hey? All the rest is filled with zeroes. All non-animated MDL610
MDL files are 70 KB in size, no matter, within its own capacity limits, how much visual data we put in them. Animated
MDl610 files are all at 133 KB for the same reason. CFS1 stock aircraft do vary in sizes, which gives some troubles to
MDLDisAs. Back to playgroundM.scx.
Perspective
RefPoint( nsi :[-124] 0x004 v1= 0 v2= 18 )
VFileMarker( 100 )
The Perspective command is "announcing" visual code. RefPoint (for Reference Point) is at the origin and all vertices are placed in relation to it.
"nsi" means "no scale indirect", commonly used for moving objects. The
:[-124] is a label jump of 124 steps backward to "dock" BGL-like code to
non-BGL part. The 0x004 is the global variable pointer that "displaces" the model.
"v1" is the visibility distance and, when set at 0, it is infinite.
"v2" is the radius visibility in meter.
It is a difficult concept to grasp but I will try to explain it.
In static objects, it influences your lateral vision. Remember flying
over a large building, or a runway, only to see it disappear under you?
This is caused by too small a number in that
v2= entry. On moving objects, it apply as well when you're
catching-up and going by another moving object. This is necessary to
reduce the number of visual objects the game has to show. Objects "in
your back" are skipped to save on fps. Set at 18 meters (± 59 feet),
you are pretty safe. But I know of a Zeppelin that would need a bit
more!
VFileMarker purpose is unknown, an it is always set to 100.
Let skip a few lines, normally reserved for landing lights that we don't have, to get to;
:L001222
RefPoint( nsi :[-152] 0x004 v1= 0 v2= 18 )
SetScaleX( :[-164] 0 0 7 )
PBHCall( :L001284 0x01C )
Return
This code is directly related to the visual object itself
(previous code was "declaring" the visual zone). We find some
repetition then
SetScalex command, which decide of the scale of our model.
This is the famous "scale 7" for those who have dabble in scaling
business before.
AF99 aircraft are mostly using that scale, but it can be
changed in some circumstances. This command will be explored in depth
later.
The command PBHCall points to the beginning of visual code (at Label
:L001284). It orient the object along pitch, bank, and heading according to local variable
01C, situated in the non-BGL part of the MDL file.
Return
This command always terminate a subroutine and basically means
"ok, done, what's next?" and return to the next command following the
call to that subroutine. A missing
Return command is a common source of headaches and grinding teeth. Beware!
Then comes a few lines that, if memory serves me, are for propellers and gears. In this
MDL, they don't mean much, but we will leave them for compatibility reasons.
:L001258
ShadowPosInd( 0x04 )
SetScaleX( :L00126C 0 18 7 )
ShadowCallVI( :L001284 0x01C )
:L00126C
Return
:L00126E
ShadowPosInd( 0x04 )
SetScaleX( :L001282 0 0 7 )
ShadowCallVI( :L001284 0x01C )
:L001282
Return
These two sets of subroutines (remark the :Label > commands > Return "sandwich" disposition) are for shadows. They are almost identical. The
ShadowPosInd is referred to the global variable pointer and the SetScaleX
is also set at 7. The only difference between the two is that the first
has an 18 at the second digit position while the other has 0. This is
the v2= instruction incorporated in the shadow command. The first
subroutine is for indirect shadow, when your going by that shadow,
exactly the same way as for the object generating that shadow. The
other is for direct shadow which, unless if you are Peter Pan, you
can't overrun. The first digit is, btw, for
v1=. The ShadowCallVI command is to trace the shadow of a moving object, mostly aircraft. It points to the same variable
PBHCall uses and is directed to the Label :L001284. Which brings us to the visual code.
:L001284
Points( 1 ; 4 points
0 0 780 ; 1
0 1560 780 ; 2
0 1560 -780 ; 3
0 0 -780 ; 4
)
SurfaceColor( 05 F0 )
Poly( ai 1 2 3 4 )
SurfaceColor( 06 F0 )
Poly( a 1 2 3 4 )
Return
This comes just after the comment ";*** Start of Main Aircraft Code
***", so its a no-brainer. But even without this MDLDisAs generated command, you should recognize the configuration
Label > commands > Return of a subroutine.
First, lets take care of the Label. I want you to change :L001284 for
:BEGINNING and to do the same with all occurrences of it. To do so, use the
Search > Find function of Notepad++
and, under the Replace tab, type BEGINNING in the "Replace
with:" window and click on Replace All;
,this is one function you will see quite often. Better get used to it.
Now, a bit of "human" touch. In-between :BEGINNING and the next line, type the following (copy and paste if you want);
;Wall red and green 10x10
Don't forget the semi-colon to start the line. This is a bit of an overkill in such a short
SCX file, but may well save your mental health when you have
hundred of subroutines all looking the same. So now, the visual code
should look like this;
:BEGINNING
;Wall red and green 10x10
Points( 1 ; 4 points
0 0 780 ; 1
0 1560 780 ; 2
0 1560 -780 ; 3
0 0 -780 ; 4
)
SurfaceColor( 05 F0 )
Poly( ai 1 2 3 4 )
SurfaceColor( 06 F0 )
Poly( a 1 2 3 4 )
Return
The line that begins with the command Points starts a "point declaration" array. The opening parenthesis
"(" opens the array, the 1
signifies that the array is numbered starting with 1. Although Manfred
Moldenhauer suggest to start from 0, experience tells me that it is
less confusing to have the first point declaration at 1, the second at
2, the third at 3... and so on. The "; 4 points" is a comment (you all
knew it, I'm sure) telling you how many points they are in that array.
The following four lines all work on the same principles;
(right+ - left- axis) (up+ - down- axis) (forward+ - aft- axis) ; (point number)
REMARK: Notepad++ and EditPad
do not treat tabulation the same way, so I suggest that you take the
good habit of lining-up vertically your point declaration columns,
especially when copy/pasting from this thread.
These points (or vertices) are placed in relation to RefPoint. Under AF99 at
SetScaleX 7, a scale of approximately 1 foot = 156 units
(156.13 for precision sticklers) is used, so we will keep this scale
for compatibility reasons. Units are always integers; if you need half
an inch, you will have to choose between 6 and 7, not 6.5.
The points' array ends with a closing parenthesis;
)
Its omission may again be the cause of violent headaches, cold
sweats, uncontrollable urge to utter profanities, and a long list of
other secondary symptoms. Try to avoid.
On the next line, we have the command SurfaceColor for... well... coloring the surface of the following polygon (I don't
think that you are stupid, I'm simply assuming that you are, lol!). The codes in parenthesis represent an "old-fashioned" method of coloring (more on that later).
The Poly command is used for simple unshaded
polygons. What you have in parenthesis is a code for the application
method (here automatic inverted) and the points used in a clockwise
order. Again, more on that later.
The other side of the wall follows with basically the same instructions with a different color and automatic application.
Then comes the Return command, closing that subroutine.
Finally, the EndA command closes the loop we started with the Area command.
All the lines that follow EndA are generated by MDLDisAs to help figure-out which commands were used and how many. Simply erase them.
You can save and close.
Until my next chapter, I want you to practice with MDLDisAs by fetching
playground.mdl and replacing the "old" playground.scx by this new cleaned-up
playgroundM.scx.
ADDENDUM
By now, all those following this chapter, whether they started with SU-27 or
mdfedex, should be on an equal footing. Their aircraft container should be exactly the same and their
MDL too. After the clean-up, so should be their playgrounM.scx.
I could have done all this in less than 30 minutes with AF99, but this would have meant using a payware that you may not even have and that is getting hard to find anyway.
This is also a great learning experience. Nothing beats making things with your own hands.
I don't know about you but speaking for myself, I had much more
fun at the beach building sand castle than kicking them to oblivion.
If you have problems getting where we are, you can get a "kit" from HERE. It contains the "aircraft container"
playground with all its folders and the playground.mdl file. You also have a
playgroundM.scx "ready to go".
But this is the lazy way to go. I strongly suggest that you build
your own stuff. Quite frankly, if you need this download, you may find
what's to come a bit challenging.
Anyway, we are here to have fun.
Next time; Chapter 2: How big is our playground?