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

Is modeldef.xml downwardly compatible?

Paul Domingue

Paul Domingue

Resource contributor
Messages
1,532
Country
us-california
Now that I have the latest release of P3D with the SDK I don't want to work with different copies of modeldef.xml. Are all the sections of code retained back to the FSXA SDK modeldef.xml? And I guess I might as well ask about FSXSE although I don't currently have it.

file size for stock modeldef.xml
P3D v3.x = 523k
" v2.x = 518k
" v1.4 = 516k
FSXA = 516k
 
Paul, regardless of file size, the actual scripts are identical.

For my own sanity though, I create a new modeldef.xml file for each aircraft project which contains only the actual scripts I'm using. It makes things a whole lot faster when I don't have to sort through hundreds of entries when tagging parts with animation, mouse, or visibility codes.

I name each using the project name so they may be saved separately, for example KA350i_modeldef.xml, T50_modeldef.xml, etc. I then load whichever file I am going to work with and save a copy as modeldef.xml and get on with my work. Whenever I need to switch projects, I save a copy of the current modeldef.xml back to its permanent name so I don't loose any of my new or edited work.
 
n4gix said:
Paul, regardless of file size, the actual scripts are identical.

For my own sanity though, I create a new modeldef.xml file for each aircraft project which contains only the actual scripts I'm using. It makes things a whole lot faster when I don't have to sort through hundreds of entries when tagging parts with animation, mouse, or visibility codes.

I name each using the project name so they may be saved separately, for example KA350i_modeldef.xml, T50_modeldef.xml, etc. I then load whichever file I am going to work with and save a copy as modeldef.xml and get on with my work. Whenever I need to switch projects, I save a copy of the current modeldef.xml back to its permanent name so I don't loose any of my new or edited work.
Click to expand...
I like your concept Bill. You've got my gears cranking.
 
Paul, here are a couple more tips from experience that can save a lot of scrolling up/down as your build your custom modeldef.xml file.

1. Not all of the <Animation name="xxxx" guid="nnnnn" ...../> entries need to be at the top of the file! Instead, you can group them in some logical fashion such as:

Code: 
<!-- FLIGHT GUIDANCE SYSTEM ANIMATIONS -->

<Animation name="AP_AP"    guid="8c95e7c3-5a77-4110-a6c7-083dc817692d"typeParam2="AP_AP"length="5"type="Sim"typeParam="AutoPlay" />
<Animation name="AP_TURB"  guid="f1a6de1d-e48a-4a80-8f1e-1df1501babd2"typeParam2="AP_TURB"length="5"type="Sim"typeParam="AutoPlay" />
Place all of the actual scripts for the above entries immediately following the above.

2. Create new sub-groups as desired to keep things that are related to specific sub-panels or systems together.

3. Generate and keep a text file with a collection of random generated guid numbers handy, then highlight and Ctrl-X to copy/delete from that file before pasting in your modeldef.xml file. That will eliminate the possibility of a duplicated guid number! I don't remember the exact mathematics, but suffice it to say that we'll experience the heat death of the universe before running out of unique guid numbers... :rotfl:

4. Build your new custom modeldef.xml file from the bottom up. This will keep you from having to scroll up/down vast distances as the file grows longer.

5. Keep a copy of the original modeldef.xml file (such as ORG_modeldef.xml) that you can use to copy/paste "stock scripts" from quickly. This will prevent having to reinvent the wheel and reduce the possibility of typographical errors during entry.

6. It is absolutely critical that you export and test your scripts often to make certain that there are no errors in your scripts. Believe me, finding a tiny error is much easier when you don't have thousands of entries to search through!
 
n4gix said:
Paul, here are a couple more tips from experience that can save a lot of scrolling up/down as your build your custom modeldef.xml file.
Click to expand...
Like minds think alike. ;)
I arrived with the same conclusions in simplifying the process when I attempted my first coding. The same ideas for items 1. - 2. and 4. - 6. but for item 3. I run the GUID generator as needed.
I prefix all the <PartInfo> names with the model name and since I use animation groups I can select just the group I want in the Animation Dialog of the FSX Animation Tool. Using Search in Notepad++ helps as well.
Code: 
<!-- J2F-5 Grumman Duck -->
    <Animation name="j2f-5_switch_master_battery" guid="0F56BFC6-7E68-43c0-B065-30B1446E5390" length="50" type="Sim" typeParam2="j2f-5_switch_master_battery" typeParam="AutoPlay" />

    <AnimationGroup name="Grumman J2F-5" guid="0x3CC98F58-0x4FDF-0x4d44-0x84EA-0xCF6A050241C5">
        <AnimationRef guid="0F56BFC6-7E68-43c0-B065-30B1446E5390"/> <!-- Switch 1 switch_master_battery -->

<!-- Switch 1 -->
    <PartInfo>
        <Name>j2f-5_switch_master_battery</Name>
        <AllThatOtherStuff>
        </AllThatOtherStuff>
    </PartInfo>

Since the advent of P3D v3.x I have redirected Max to point at the Aces Tools in v3.x SDK. On export to .X Max looks at the modeldef.xml in that version. When I use my current setup, as posted in http://www.fsdeveloper.com/forum/threads/3ds-max-mdl.434109/page-2#post-714742
posts #26 and #29, native MDLs for FSXA/P3D v1.4, v2.x and v3.x compile pointing to their respective SDK modeldef.xml file so I have changed the command lines in all three [Send To] CMDs to point at the single modeldef.xml file in the v3.x SDK. Now I need only be concerned with one modeldef.xml file.

What I've found on inspection of each subsequent modeldef is that all code is retained but additional code is added. For instance the code for the avatar was added with v3.x.

I like your idea of using a smaller modeldef with just the code of the model being worked on. I am looking at writing a batch file that will automate renaming and swapping them in the SDK. If I can simplify this task and make it foolproof (I need something like that otherwise I know I'll screw up forgetting to swap or save the file o_O) then I will keep the working modeldef in the model work folder for each project as you suggested.

I'll post more on this as it develops.

Paul
 
I have my aging, built up Modeldef from ages ago. I learned how to section parts off. With each new plane I build, I group new animations and parts. Then in the 'groups' window in Max / P3D tools / Animations, I can select the group that might have an animation I have already done. It also enables me to copy/paste/modify animation blocks and quickly place the new versions into new planes.

Sort of like Max. I keep my entire library and can use parts from other models.

I know you guys like to keep it simple, but I like spare parts. I do not like to do things twice. If I can re-use a switch animation, but change its code to something different to access a master code system, and change its SND sound effect in 2 minutes, thats what I will do. I an also go to a plane that had the right click sounds and things and just use that planes toggles for this new project, etc.

I probably have NOTHING in numbers compared to you, Bill, lol.. Probably why you go new and basic each time. I like mine all in one massive chunk, but all organized into sections.
 
I thought of a few more things that help to keep things simple, tidy and quick to access...

  1. GUID numbers need only be unique to a specific modeldef.xml file. This means that you can recycle entire sections of them from one modeldef.xml file to a new modeldef.xml file! :)
  2. There are many commonly used XML scripts for switches, knobs, levers, etc. in any aircraft. For this reason I have a "Template_modeldef.xml" file containing a set of such XML scripts so they can be quickly copy/pasted/completed as desired. I only need then to "fill in the blanks" of the template copy.
  3. I use Microsoft Visual Studio 2005 to create and edit my modeldef.xml (and other .xml) files because it allows me to have multiple .xml files open as "Tabs" for quicker searching, copying, and pasting operations! Note XMLFile2.xml is an empty scratch file where I can isolate sections of script for quick Find/Replace operations.
Speaking of which, late yesterday evening I use Find/Replace to create new scripts for the copilot's CCP control panel. Changed "CCP1" to "CCP2" and changed "0x110" to "0x120", then copy/pasted back to my current modeldef.xml file. Tagged the objects in Max (animation and mouse), then tried to export selected to test in the sim...

Compiler failed instantly! What did I forget to do? Oh, you silly old man, you forgot to replace the CCP1 guid numbers with unique ones! :oops:

q0pq7.png
 
You must log in or register to reply here.
Back
Top