MDL Objects

[Helli]

Hello Arno!

I am the guy who pestered Jon Masterson with so many questions, that he finally opened a new thread in OTHER/Other/Object Placement Pros and Cons.
Unfortunately not many contributions were offered.

So I had to start this investigation myself.
I started with "OBPLACER XML" and ran soon into a snag, which the manual cannot solve for me.

I went to basics and produced with Gmax a simple object (à la Erwin Horjus in "Build your own house" part1)
Its export produces an MDL-file and an XML-file, the latter contains syntax errors and a non-European location (where do they come from ??)

I started "ObPlacer XML" and I find on the left side of the screen under "Available Objects" also an entry "MDL Objects".
Now I have for my object a MDL file and a XML-file (which contains errors).

On page 6 of your manual you are a little bit hazy, how one should proceed to open/import/include/transport/whatever a MDL-file.
All my trial-and-error efforts end with the XML-file, the opening of which fails, probabely because of its defects.

The menu promises the possibility of opening of a MDL-file.

How??

your advice will be highly appreciated

Servus
Helli

 

[arno]

Hi,

It is always a good idea to come with your questions to the author of the tool .

I'll try to explain it a little more detailed than in the manual here. Hopefully that will make things more clear.

First, you can throw away the XML file created by GMax, it is only an example of the XML code you could use. But ObPlacer XML will create all the needed XML code for you.

The next step you need to take is either create a new XML file in ObPlacer XML (File -> New) or open an existing file to which you want to add your new object (File -> Open).

Once you have done that the next step is to add your MDL object to the file. You can do this by clicking with the right mouse button on the MDL object section of the tree list. In the menu you get then, you should see an entry called "Add local MDL". If you click on this option, you get a screen where you can select your MDL file made with GMax. Once you have selected it, you should see your new object in the tree view as well.

One note about this. When adding a MDL object like this it will become geographically locked, so you can not use it everywhere in the world, only near the place where you placed it in this XML file. So if you want to use your object in multiple projects, it is probably better to create a object library for it. But to not confuse you more, I will not discuss that in more detail here .

So, you have now added your object in the tree view. The next step is to actually place it. This is easiest done by placing your aircraft at the position where you want the object in FS (in slew mode this will be easier). Then you can double click on the MDL file in the tree view to place it. During this step, the latitude and longitude will be read from FS.

Now you last step is to compile your BGL file to be used in FS. This is done from the File menu again.

Hopefully this made things more clear and if you still have questions, just ask.

 

[Helli]

Hello Arno,

thanks a lot for your answer.
When I posted my question above I was slightly apprehensive, since I do not like to annoy the experts with silly questions, which have already been raised similarily in the same forum.

But I am sure now, that I would not have found the answer, which you gave me by trial-and-erroring around.
Now it is clear.

What led me astray too is the non-uniform use of:
"object-/user-/library-/placement-/default-/local-/no prefix at all" --> XMLs and BGLs.
I do quite a lot of object placement and make use of libraries extensively. But due to the rareness of comprehensive explanations I still struggle sometimes.

Please permit me two more questions, the answering of which is not urgent, just nice to have (if they do not belong here, please relocate them to a proper place.

1.
You mention repeatedly the "geo-locking" problem. Out of sheer curiosity I tried to put a "Gmax-BGL" (thats another one!) i.e. with identical GUID but different coordinates into the FS9 Addon Scenery, one in Switzerland and one in Austria.
It worked!
You wrote "you cannot use it everywhere..., only near the place where you placed it in this XML-file".
What are the permitted boundaries, how close to the placement place ?

2.
I presently try - after having placed several objects taken from different libraries - to group them into a separate library for forwarding, which would be much smaller than the collection of all my sources. Of course I have to retain the original GUIDs.
It works so far.
But I read repeatedly the warning, that "activating the same GUID" in several places of the FS9 leads to confusion and conflicts.
To what extend is this true?

Thanks again, you do a great job in this forum!!!

Servus
Helli

 

[arno]

Hi,

You mention repeatedly the "geo-locking" problem. Out of sheer curiosity I tried to put a "Gmax-BGL" (thats another one!) i.e. with identical GUID but different coordinates into the FS9 Addon Scenery, one in Switzerland and one in Austria.
It worked!
You wrote "you cannot use it everywhere..., only near the place where you placed it in this XML-file".
What are the permitted boundaries, how close to the placement place ?

The scenario for the geo-locking is like this. In one XML file you have the ModelData command that links the MDL file with the GUID. If you now also place a copy of this object with the SceneryObject command in this same XML file, the object gets geo-locked. That means that if you try to call the same GUID in a different XML file (in that file there is no ModelData command, only the SceneryObject command) it will only appear if you are close enough to the origional location.

I don't know the exact distance. But try to place the default tower of Pisa somewhere in the US, it will not appear. This is due to the same geo-locking problem.

I presently try - after having placed several objects taken from different libraries - to group them into a separate library for forwarding, which would be much smaller than the collection of all my sources. Of course I have to retain the original GUIDs.
It works so far.
But I read repeatedly the warning, that "activating the same GUID" in several places of the FS9 leads to confusion and conflicts.
To what extend is this true?

Yes, it is not adviced to have the same object with the same GUID defined in multiple libraries. The entire idea of a library is that they store the objects, so you should not have to repack them in a different library if you use them elsewhere. Such make sure that you ship all the required libraries with the scenery.

 

[Helli]

Hello Arno,

thanks for clearing up these issues.

The geo-lock phenomena interests me more "academically" since it obviously does not make sense to do what provokes it.

The multiple-GUID issue is slightly different, since it would make sense to provide with a scenery only a small-sized special library instead of a mult-Megabyte-monster. (I know, a reference to the monsters home-side is even shorter).
Of more than academic interest is however, that even you only issue a warning not to do it without giving a reason or description of real consequences.

Be it as it may --- I close this topic, not without expressing again my sincere appreciation of what you do and how you help.

All the best from

Helli
(Helmuth Hauck)

 

[arno]

Hi,

The geo-lock phenomena interests me more "academically" since it obviously does not make sense to do what provokes it.

For an object like the tower of Pisa it does indeed not make sense, but assume you have made a model of a generic object like a windsock or so. In that case you might want to have it in a library, so that you can use it on aircraft anywhere in the world. So in that case it can be a problem and therefore you in general don't want to mix the placement and the library object definition in one XML file.

The multiple-GUID issue is slightly different, since it would make sense to provide with a scenery only a small-sized special library instead of a mult-Megabyte-monster. (I know, a reference to the monsters home-side is even shorter).
Of more than academic interest is however, that even you only issue a warning not to do it without giving a reason or description of real consequences.

There are a few good reasons not to make libraries with the same GUID:

1. You don't know which object is loaded in the scenery, at first this might not matter as they are the same. But imagine that you update your object later on and only recompile one of the libraries. Can you then tell which object will apear? No you can't.
2. Giving the object a different GUID in the second library is not a very good idea either, because that means you are probably refering to the same object with two GUIDs. This will turn into a nightmare once you start updating the object. Do you need to update it in both places? Do you need to replace the code that calls the object with the other GUID? This can turn out very chaotic.
3. A more academical reason is that the GUID is supposed to be a unique identifier (that is what GUID means after all). So using it twice makes it no longer unique.

And for the size issue, this is something a designer should think about before releasing his library. At that moment he still has the choice to group them in logical libraries. But once they are released and probably used on other places as well, I would not touch them and start re-grouping stuff.

 

[Helli]

Thanks Arno!

What you say makes sense.

I will adhere to it in the future.

Helli

 

[Helli]

Hello Arno,

I hope you do not mind my coming back once more to the "Geo-Lock"-phenomenon.

Do you by chance know the source within the Microsoft documentation, where they write about geo-lock?
I tried to search through the SDK-documents, but could not find anything.

I took it upon me to write some tutorial material in German about scenery objects, placement and libraries, based on my own experiments, on manuals and on advice from you.
Besides passing-on your views on geo-lock I would like also to properly quote Microsoft.

Thanks in advance

Helli

 

[scruffyduck]

Hi Helli

I am sure Arno will correct me but I do not think there is any specific reference to geo-locking in the SDK documentation

 

[arno]

From the FsX BGLComp docs:

If the reference to a model is made in the same XML placement file as the model's position, then that model will not be available worldwide, but will be scoped to the vicinity of the placement (this is for scenery optimization purposes). If the aim is to create a library of models that each have worldwide scope, then create an XML file containing only the ModelData references, and then use additional XML placment files to actually place the models at their various locations.

 

[Helli]

Thanks Arno!

No wonder that I did find it - I was searching in the FS9 documentation.
I have not yet reached the FSX-stage.

All best whishes for for a happy and successful year 2007!!

Helli

 

[Helli]

For Jon

I am sure Arno will correct me but I do not think there is any specific reference to geo-locking in the SDK documentation

Jon, if it is not laid down in the SDKs, where else did Microsoft put it in the FS9 documentation?

Thanks for yout help

Helli

 

[scruffyduck]

Helli

I can't find a reference to it in the FS( BglComp SDK but the comments quoted by Arno are correct for FS9 also as far as I know.

 

[Helli]

Hello Jon,

nice of you to come back so promptly.

Well, I do not doubt Arno!
And I expected the same as you namely to find a quote in the BGLComp of FS9.
But I also failed - and there is nothing in the other relevant SDKs.

I do not want to appear as a Teutonic smart alec, but since I wrote about this issue in a small German tutorial, I am confronted with "demands for Proof" of what I am writing, which I cannot really satisfy so far.

Do you know somebody at Microsoft, whom one could ask?

But again, this issue is not worth while to strain your back!

It's nice talking to you.

Helli

 

[scruffyduck]

Some of the Aces guys participate here so maybe one of them will confirm things for you in answer to this thread

As for demands of proof I would just say - this is the way it is - if you do not believe me then try testing it and see what happens - it is easy enough to test. I guess some people actually need to burn their hand before they believe that fire is hot

 

[arno]

Hi Helli,

I don't think it is written down in the Fs2004 SDKs somewhere. We found out how it worked on forums like this after FsX had been released.

But as you can see they have now written it down in the SDK for FsX and I can assure you that this is also how it works in Fs2004 (I got that confirmed from MS during the beta testing).

 

[Marcello]

Hi Arno,

Apology for my bad English, but I has a question, what you can answer perhaps. In this small German forum, in which Helli its Tutorial published, the following statement was published by a another user (not Helli).

If we want that an object is not "Geo Locked", then we may not use Align to World in GMax to Align the Pivot.
If we use this, then an object is "Geo Locked"

Is this True ? I think, this is not the Problem.

Sorry, this is a little bit offtopic.

Greetings from Switzerland

Marcello

 

[arno]

Hi Marcello,

That is new to me. As far as I know nothing inside the MDL controls the geo-locking. So I don't think that you can control it from within GMax.

Where can I find this GMax option? I don't think I have needed to use it.

 

[scruffyduck]

I don't know anything about GMax but is there not some way to create a bgl rather than an mdl. That would presumably create the XML to generate a geo- locked object. You can certainly do that with FSDS if I recall correctly

 

[arno]

Hi Jon,

No, the BGL export from FSDS just creates a BGL using the XML template the MakeMDL also creates. But in GMax there is no way to create the BGL right away.

And besides that, as the quote from the FsX SDK already says, the geo-locking is controlled by mixing SceneryObject and ModelData commands. To have them not geo-locked the objects should be put in a library without placement commands.