ObPlacer XML announcement

[arno]

I have started coding on the XML version of ObPlacer, which I simply called ObPlacer XML.

Attached to this post you will find the first screenshots of the new tool. It is certainly not finished yet, but gives an idea of the options.

The tools allows you to place library objects (generic or custom) and effect files.

If someone has additional ideas, suggestions, etc, please let me know, maybe I can still use them.

 

[bpahe]

Hi!

Looking forward to this! A thought, the possibility to add a thumbnail showing the object/effect would be nice, particulary since the name of the object is not always easy to decode...

/hans

 

[arno]

Hi Hans,

That idea already slipped through my mind. I think that could indeed be a useful feature, especially for the generic objects. For your own made objects you of course choose an understandable name .

 

[rhumbaflappy]

Hi Arno.

I have 2 suggestions, but perhaps for a later version.

First, objects are not sorted in XML, but they should be. Perhaps "banding" objects north to south by LOD8 area, then sorting them west to east.

Next, I have thought better use could be made of generic buildings if we had the ability to maintain a database ( or library ) of predefined objects, rather than building the long list each time. It would be a real time saver, allowing us to place them quicker than applying autogen.

Dick

 

[arno]

Hi Dick,

First, objects are not sorted in XML, but they should be. Perhaps "banding" objects north to south by LOD8 area, then sorting them west to east.

Yes, I read that in your other post you made some weeks ago. I will try to add that feature as well, so that the objects are sorted before saving.

This is of course only usefull for big projects, when you only place a few local objects I don't think it has a real influence. But if you place objects over a bigger area it might have.

Next, I have thought better use could be made of generic buildings if we had the ability to maintain a database ( or library ) of predefined objects, rather than building the long list each time. It would be a real time saver, allowing us to place them quicker than applying autogen.

For this tool I have now made an XML file that contains the Generic objects. At the moment I only added the autogen objects (listed in the default.xml file), but I plan to extend it with more generic objects later on (first need to find out which work and which don't). The tool just reads this XML file during startup.

Maybe it would indeed be a good idea to store such a list somewhere, although I think there are already some of them in the avsim library.

 

[Joe W]

Could this be connected to FS by FSConnect ?
That would be handy as well.
Joe W.

 

[arno]

Could this be connected to FS by FSConnect ?

Forgot to mention that, just like the old ObPlacer it is connected to FS using FSConnect, so you slew around to place your objects. It is not intended to be used to place objects by typing the coordinates or so.

 

[rhumbaflappy]

Hi Arno.

My mistake... I thought you were refering to the Generic Buildings ( as the SDK refers to them ).

Their code is difficult to retype over and over:

<RectangularBuilding
     roofType="RIDGE"
     sizeX="44"
     sizeZ="44"
     sizeBottomY="5"
     textureIndexBottomX="512"
     textureIndexBottomZ="512"
     sizeWindowY="225"
     textureIndexWindowX="768"
     textureIndexWindowY="3840"
     textureIndexWindowZ="768"
     sizeTopY="5"
     textureIndexTopX="552"
     textureIndexTopZ="552"
     textureIndexRoofX="256"
     textureIndexRoofZ="256"
     sizeRoofY="45"
     gableTexture="30"
     textureIndexGableY="256"
     textureIndexGableZ="256"/>

...better to have a database of known configurations and simply reference a type and number, and the code is entered automatically. Just an idea, if you decide to ever include those object types. We could even share our generic creations to add to the list... with a small picture and the code. they could then be easily dropped all over the landscape, just like library objects.



Dick

 

[arno]

Hi Dick,

OK, now I understand what you mean . Good idea, I will put it on the wishlist for future versions.

 

[Shakakoz]

Currently I place most of objects by slewing around FS, and manually entering the lat/long into notepad. This tool is going to help me out a lot.

I don't need much from this tool, so you don't have to make it too complicated to impress me. One thing I would like to see is a limited ability to organize the onjects. Dick mentioned one method, but I was wondering if you could allow us to name the objects.

What I mean is, when I place an object, could I have a name field which could be inserted into the comments section of the XML file. This way, I could name an object "Control Tower", or "Red car near control tower", or "Tree in NE part of airport number 4". This way when I go back to find certain objects that I want to remove, (or whatever) they will be easier to find. I realize this might be a bit of a chore, so don't worry too much about it - it's just an idea.

Thanks again for all your hard work.

- Martin

 

[arno]

Hi Martin,

Good idea. I already had something like that in mind. I think it is important that you are able to find back your object later on (either in the list presented in ObPlacer or by searching in the source code manual). I will try to implement this.

 

[Gorchi]

Speaking of comments, maybe it would be good if we could also have some standard comments like there were in APIs: MACRODESCR, DESIGNSHAPE, DEFAULTSCALE, DEFAULTTRANGE... The problem is how will BGLComp react on those comments and I am afraid that each software (XMLPlacer, SceneGenX...) will have to remove these comments from XML file before sending it to BGLC. But still, I think we do need some special words to be able to distinguish macros. I think we have to open new discussion on this theme together with other software designers.

Best regards,

 

[arno]

Hi Goran,

This is a very good point.

First, as long as you enter them as comments in the source, they are comments and BGLComp will not notice them while compiling. So it should not give any errors or so.

When I had finished my first version of Library Creator XML, I contacted the authors of SceneGenX with a similar question. I wanted to discuss if it would be possible to add for example shape information to the library objects, so that SceneGenX could display this shape (like the airport symbol code in the old API macros). I got a reply that they would look at it in the future, but have not heard anything since then.

Making use of comments like this only has sense when there is some sort of standard for them of course, but it is certainly a good idea. Maybe we should start a new topic about this, to see what kind of information people would like to be available in the comments, etc.