Freeware object libraries?

[robystar]

Hi,

I am probably barging in with a stupid comment as it has nothing to do with a centralized object library.
But what I do miss in FSX is an easy program to make your own objects like what was possible in fs2002 with EOD and FSSC.
I made my own house in a jiffy with the trees and bushes I find in my yard, Camp Holland in Afghanistan all with self made objects like tents, people, fences etc and other sceneries surely not interesting for others but for myself. Even If I were ever able to do this in FSX,(and if I set my mind to it, I probably would) it would take me ages to finish it.
So for me,a laymen scenery object design program for FSX would be the X-mas present.

Roby

PS ADE comes close but is not an object making program.

 

[scruffyduck]

This might be a starting point http://www.flightsimtools.com/iom/

 

[jdhaenens]

I've recently changed copyright statements in my newly uploaded libraries to say that use in freeware is unrestricted and requires no further permission. The thing that would make it worthwhile to conglomerate libraries is to just transfer the .mdl file with text friendly name and GUID and associated textures rather than putting it in a library, then have the receiving folks make their own libraries with what they need.

I've been making a few in between and along with projects lately, and I generally put just a few related objects together.

Jim

 

[arno]

Hi Jim,

For FSX distributing the MDL files might prove to become a problem. As the GUID is in the MDL file you might end up with the same GUID being available in multiple libraries it different designers include the MDL you distribute. This could lead to strange problem if one set of texture is different or things like that.

 

[Timmo]

actually....kind of on the same topic.

When making some fences I found that they were inheriting a texture from somewhere else (one of the default fences)

I tried changing the name of the texture and the problem persisted

I then changed the friendly name of the fence and it solved it. From memory I was using 'Fence' as my friendly name. Is this name reserved? I would think the friendly name even mattered?

 

[arno]

Hi,

The friendly name is not used anywhere, as far as I know, so that should not matter. But if there is another object with the same GUID in the simulation already you never know which one you will get.

 

[jdhaenens]

When you use a library management/ placement program like Instant Scenery, it reassigns the guids anyway. It seems to me there is an equal chance for duplicate guid's whether you place the .mdl's into a library .bgl and call them by guid or just distribute the original .mdl. I can see that there may be a problem with texture names, although, generally speaking once the scenery is developed, all the textures go into the local texture file, and that is where fs looks for the associated textures first. I don't see anything insurmountable.

Jim

 

[Simon853]

But if there is another object with the same GUID in the simulation already you never know which one you will get.

Is that even possible, assuming GUIDs have been created afresh and not cut'n'pasted?

I always assumed GUIDs were generated using a hash of the date, time and MAC address in order to be unique.

Si

 

[scruffyduck]

Is that even possible, assuming GUIDs have been created afresh and not cut'n'pasted?

I always assumed GUIDs were generated using a hash of the date, time and MAC address in order to be unique.

Si

It is quite possible if the same object is replicated in more than one library. This is why re-packaged object libraries are not always a good thing. Also there are one or two cases between FS9 and FSX where different objects have the same GUID. As you suggest the best way is to create them as random but there are lots of ways to define a GUID including setting it yourself. Some libraries (FS9 I think) start with a base for the GUID set by the designer and then each object is incremented off it.

 

[arno]

When you use a library management/ placement program like Instant Scenery, it reassigns the guids anyway. It seems to me there is an equal chance for duplicate guid's whether you place the .mdl's into a library .bgl and call them by guid or just distribute the original .mdl. I can see that there may be a problem with texture names, although, generally speaking once the scenery is developed, all the textures go into the local texture file, and that is where fs looks for the associated textures first. I don't see anything insurmountable.

I may hope a tool like Instant Scenery does not touch the GUID of an object that is in a library already. I never heard of that and if it would happen that would be a very bad thing.

When a scenery is finished the texture will normally not change, but I have seen a lot of problems already because an object was in two libraries. Let me give some examples.

If you would for example update your local copy of the textures to improve them. It could very well be that you never see that chance, because the object is loaded from the other library with the old textures.

Or imagine the other library has some missing textures, then you could still see an untextured object and it can be very hard to debug why if you think everything is fine in your own copy.

When the designer decides to release an update things get even worse. The GUID will not change in that case, but you might have libraries with different versions. It's a big lottery which object you will get in that case...

 

[arno]

Is that even possible, assuming GUIDs have been created afresh and not cut'n'pasted?

I always assumed GUIDs were generated using a hash of the date, time and MAC address in order to be unique.

Of course it is possible. If you spread the MDL file outside of a library, two people can put it in their libraries. The GUID is already in the MDL, so you get two libraries with the same GUID in it.

When creating a new GUID the chances of creating exactly the same one are very very small indeed. That is not something we should worry about. Although I am not sure if the date, time and MAC address are involved.

 

[arno]

Some libraries (FS9 I think) start with a base for the GUID set by the designer and then each object is incremented off it.

That is how I did it in Library Creator XML 1.0. In the end it proved not to be the most optimal way, so in version 2.0 I changed it so every object gets a new and unique GUID.

 

[GHD]

Although I am not sure if the date, time and MAC address are involved.

This was true for Version 1, but Version 4 uses random numbers and Version 5 is a hash of the domain name, an object identifier and either a distinguished name or names in ununspecified namespaces. (Isn't wikipedia marvellous).

I have no idea which version is used by Microsoft.

George

 

[jdhaenens]

I may hope a tool like Instant Scenery does not touch the GUID of an object that is in a library already.

What the library maker part of Instant Scenery does is change the guid of the .mdl files before it makes the library .bgl.


So if we were to pass around .mdl's and make our libraries with a library maker that assigned truly random guid's, the chances that any would be the same would be very small indeed.

I still think the .mdl is the way to go.

 

[arno]

What the library maker part of Instant Scenery does is change the guid of the .mdl files before it makes the library .bgl.

So if we were to pass around .mdl's and make our libraries with a library maker that assigned truly random guid's, the chances that any would be the same would be very small indeed.

I still think the .mdl is the way to go.

In that case we would prevent double GUIDs indeed, but I find it slightly worrying that a tool changes some information inside a MDL file. Most people will not be aware of that. And if a user would simply use the SDK tools (BGLComp) something like this would not happen indeed.

 

[scruffyduck]

In that case we would prevent double GUIDs indeed, but I find it slightly worrying that a tool changes some information inside a MDL file. Most people will not be aware of that. And if a user would simply use the SDK tools (BGLComp) something like this would not happen indeed.

I think that GUIDs can be changed for FS9 objects because the guid is defined by the xml code when creating the library but I thought GUIDs for FSX objects come from the mdl and are not defined in the xml but I could be way off base here

 

[solid]

What is badly needed is for freeware authors to release their objects for other developers,in freeware scenery obviously, to use without the hassle of writing for permission to use them.

 

[arno]

I think that GUIDs can be changed for FS9 objects because the guid is defined by the xml code when creating the library but I thought GUIDs for FSX objects come from the mdl and are not defined in the xml but I could be way off base here

That is correct Jon.

 

[art209]

That is correct Jon.

I checked and confirmed that LibraryCreatorXML did not change the GUID assigned to the MDL file. Is it established that distribution of scenery objects is okay either in a library or as a MDL?

I'm trying to compile a library of airport buildings using default FSX textures to replace the floating generic buildings. Along that line, does anyone know what a small single aircraft hanger depicted in the attached picture is called? I'd like to find out how the front wall with the doors is supported and can't find anything on line.

Art