adding new objects into library?

[MartijnPleines 0]

Recently, macro's for using existing objects from the Autogen library on an individual basis have been published.My question is...Would the reverse be possible?I'd like to add a new (GMAX) object into the library, and obtain a GUID for it, so I could use it in the new default.xml autogen to add new autogen building types or replace existing ones.For instance, I'd like to replace the cathedrals in the European autogen with a more common, single-steeple type church.It would also be great if we could add entirely new types!Is it possible or will we have to wait for the SDK?Thanks, Martijn

[arno 1]

Humm, I think we need to wait for a SDK for that. Of course you can make your own library BGL (with FsRegen for example). But I don't know if FS will use these objects if you add them to the default.xmll file.

[MartijnPleines 0]

Thanks, Arno.I would love to try building my own library BGL but is FSRegen really the tool for that? It seems to be a tool for placing special effects in scenery BGL's rather than a library compiler? I do not have a clear picture of all the tools involved in scenery creation at the moment but I will look into it some more. Perhaps I have to create a source code file for BGLC myself? I think once that can be accomplished, it might be not too dificult to customize the Autogen further-at least I hope so. Of course the structure of library files seems to have changed in FS9, so the new autogen might need this new format too, in which case there is no alternative but to wait for the new SDK anyway.Regards, Martijn

[arno 1]

FsRegen also has a library compiler function. This is the easiest way to put GMax objects into a library BGL. There is a tutorial about this on my website (see signature).Of course you are right when you say that if the new format is needed we have to wait.I wonder what FS would do when you add new autogen to that XML file. Is that file read by FS? Or is the information stored in some BGL file and have they only placed the XML file there to give us something to play with?

[rhumbaflappy 113]

Hi Arno.I also wonder what would happen if we create a new library BGL... with the same numbers as some of the autogen. Which object would be displayed? The default, or the newer replacement?Dick

[arno 1]

Hi Dick,With the normal library BGL files using the same GUID twice is not a good idea. As far as I know it is not sure then which of the object appears , you can get very strange effects.

[MartijnPleines 0]

Hi Arno,OK, I'll have another look at FSRegen, and your tutorial-Thanks!The XML file controls the 'new' autogen buildings such as various religious buildings, restaurants and barns. If you remove it or rename the extension, these will not be displayed and, indeed, this is being tipped as a way to gain FPS; so it's a real factor, not just for information. I do not know how it ties in with .agn annotator-placed autogen.Best,Martijn

[arno 1]

Thanks, that is interesting to know. It might be possible to add new objects then. Although I have no idea how they will be added used.

[MartijnPleines 0]

No, that's what I'm struggling with too. The file does not seem to tap into any particular library file so perhaps FS creates an internal pool of objects from various library files that can then be accessed via their GUIDs. If this pool 'accepts' objects from old-style libraries, we might be in luck...BTW it turns out I'd downloaded a very early version 0.06(!) FSRegen from the AVSIM library...

[Guest GerrishGray]

Hi guysOne of the processes that happens during the FS startup sequence is that the headers of all BGL files in all folders listed in scenery.cfg are scanned and several tables compiled listing their contents.This, incidentally, is doubtless a major contributor to the problems with changing scenery.cfg 'on the fly' and why MS have removed the facility to do so from FS9...One of the tables compiled is a list of the IDs of all library objects, together with details of the BGL in which they can be found. The table is compiled sequentially, and searched sequentially whenever a library object is called.So you can add further libraries and objects to the 'pool' with no difficulty at all, but they must have unique ID's (hence the term GUID - Globally Unique ID). If you reuse/duplicate an existing object ID you will end up with multiple entries for the same ID in the table, but I believe that only the first of these entries will ever be used by FS because it will always be found first by the sequential search.So the correct way to replace one of the objects used in Autogen is to provide a new object in a new library file with a new ID, and then edit default.xml to replace the original object ID with the new one. There may be some other complication here regarding object names, but I guess a little experimentation will soon reveal what happens.But as regards adding extra objects to default.xml and placing them in Autogen, there is no doubt that we shall have to await the FS9 Autogen SDK and updated Annotator tool. I very much doubt that experimentation or hacking will reveal the secrets until then!I don't think that there is any significance whatsoever as to whether the library BGL has been compiled into the existing format as produced by BGLC/SCASM or into the new RIFF format for which we await the release of a new compiler by MS (hopefully!). We already know that the new objects can be called perfectly successfully from code compiled with the old format. The only provisos are (a) the new format may include some new 'commands' that we don't yet know about (as well as removing many of the older non-FP commands as stated in the FS2002 SDK), and (:( we probably can't yet successfully replace the Vector Autogen objects such as the telephone poles, bridges, etc. because they appear to have a presently unknown mechanism for setting up their Transform Matrix data.CheersGerish

[Guest JonP01]

Gerish,As an aside, do you happen to know if / what advantages there are to be found in the new RIFF format BGLs? MS obviously had reason to change the format, I am just speculating as to what that reason is. I am actually looking forward to compiling the same source scenery with both the version 8.0 compiler and the version 9.0 (?) compiler just to see what the difference between the two files will be.

[Guest GerrishGray]

HiI don't think we can really answer that properly until we see the new SDK and compiler. In the FS2002 Floating Point Scenery SDK, MS announced that support for the traditional rendering commands such as Poly(), TexPoly() etc. etc. (to use their SCASM names) was to be dropped and all rendering would in future be done only with the new floating point DirectX-based commands. The new RIFF format appears to be an implementation of this. FS9 continues to support the older format and the older command style as well, but I suppose we can anticipate that the new RIFF format and its new/restricted command set will be compulsory for some future version of FS.The motive behind these changes is probably that the present BGL language has its roots in FS5 and many of the older commands are not totally appropriate to the way that the current scenery engine actually works. We know, for example, that a number of the commands are no longer actually implemented exactly as one would expect from their syntax, but have been preserved in the existing format for backwards compatibility. So this is an opportunity to 'tidy up' the command set / data structures for scenery programming and provide a suitable tool for the future unencumbered by stuff from 10+ years ago ...Whether there will be any measurable improvements in performance when FS9 is working with a new RIFF format BGL as opposed to the older format remains to be seen - I'm doubtful - but the real advantage will be learning the new approach and, presumably, gaining forwards compatibility with future FS versions.But all this is speculation for the time being anyway, and I'm not holding my breath awaiting the release of an FS2004 Scenery SDK and new compiler, I bet it will be quite a while yet before any public release ...CheersGerrish

[Guest JonP01]

>Hi>>I don't think we can really answer that properly until we see>the new SDK and compiler. In the FS2002 Floating Point>Scenery SDK, MS announced that support for the traditional>rendering commands such as Poly(), TexPoly() etc. etc. (to use>their SCASM names) was to be dropped and all rendering would>in future be done only with the new floating point>DirectX-based commands. The new RIFF format appears to be an>implementation of this. FS9 continues to support the older>format and the older command style as well, but I suppose we>can anticipate that the new RIFF format and its new/restricted>command set will be compulsory for some future version of FS.>>The motive behind these changes is probably that the present>BGL language has its roots in FS5 and many of the older>commands are not totally appropriate to the way that the>current scenery engine actually works. We know, for example,>that a number of the commands are no longer actually>implemented exactly as one would expect from their syntax, but>have been preserved in the existing format for backwards>compatibility. So this is an opportunity to 'tidy up' the>command set / data structures for scenery programming and>provide a suitable tool for the future unencumbered by stuff>from 10+ years ago ...>>Whether there will be any measurable improvements in>performance when FS9 is working with a new RIFF format BGL as>opposed to the older format remains to be seen - I'm doubtful>- but the real advantage will be learning the new approach>and, presumably, gaining forwards compatibility with future FS>versions.>>But all this is speculation for the time being anyway, and I'm>not holding my breath awaiting the release of an FS2004>Scenery SDK and new compiler, I bet it will be quite a while>yet before any public release ...>>Cheers>GerrishHi Gerrish,Thanks for the detailed reply. Actually I *was* holding my breath waiting for an FS2004 compiler SDK giventhe change in format and considering it's importance in developing FS2004 upwards compliant scenery. Sounds like I should instead take another gulp of air lest I turn blue and expire...Actually we might be suprised. We could get something for the Christmas / New Year break, but's that is just a totally unsubstantiated guess.

[MartijnPleines 0]

Thanks, Arno, Gerrish,Today I tried it out but the stuff just doesn't show up. I made a GMAX model and created a library file from it using FSRegen as suggested by Arno. I confirmed that the library file was working correctly by creating a standard BGL that called the object from the library in a specific spot, and it did appear.Then I replaced the GUIDs for ag_Building_5 (the cathedral) in the A region of default.xml but the cathedrals simply disappeared, not replaced by anything else. Using the name of my library object as well or recompiling my library object with the proper name (ag_Building_5) for the building didn't help either-so I guess we'll just have to wait for the SDK, and perhaps the right tools, to do this sort of thing...Thanks,Martijn

[rhumbaflappy 113]

Hi Martijn.I repeated your tests and had the same results... I even named the library as Generic.bgl, replaced the original, and made the default.xml reference to my object GUID and name...It just doesn't show.You can replace the GUID with a "valid" guid number ( one of the default one... say exchange the building_1 with an iceberg ) and that will show. zzzzzzzzzzzzz.... waiting for the SDKsDick