Custom libraries revisted

[Shaka 2]

Hi all,I've been working on updating my Bangkok scenery to FS9, and I recently started making my own custom library objects. I originally just made some trees, but once I got the hang of it, I moved on to other objects. I know that I could have just used Gerrish Grey's excellent tree library, but there is extra satisfaction in figuring it out myself. At first, making the libraries didn't go so well, since my knowledge of SCASM isn't very good, but now I realise how easy it is - just cut and paste, and it takes about a minute. So now all my trees, light poles, and other repeated objects are in a library. My first realization was that my BGL filesize had been cut in half, and the sim seems to run much more smoothly than before. I wish I had used these before.Does it make a difference if I have several small library BGLs to distribute, or would it make more sense to combine them into one big one? Will this affect performance at all?- Martin

[arno 1]

I don't think the amount of files really matters. It is more the amount of Area commands and objects you use. And it doesn't really matter in how many files they are.Also, I would not advice to link a library BGL with a normal BGL.

[Shaka 2]

>Also, I would not advice to link a library BGL with a normal>BGL.Ok, I'm not sure what you mean by "linking". I put my objects into the library, and then I created macros to call them. I put these macros into AFW, and then compiled my scenery BGL. Is this a bad idea? What other way would there be to compile the scenery object? Is it possible to put a library object into the regular BGL, and call it from there?Well, I am still learning about this :) . I always appreciate your help Arno. There's probably 5 or 6 guys in the forum who are very knowledgable and helpful to others, and I always try to search the forum to fix my problems before I ask. There's a lot of good information in here, that's for sure.- Martin

[arno 1]

Hi Martin,No what you are doing know is correct. You have one BGL that contains all the objects, the library BGL. And with your design program you make another BGL that calls these objects.What I tried to indicate is that combining the library BGL and the calling BGL is not a very good idea. The approach you are using now is much better (you can for example update the library easy, without it affecting the calling BGL).

[Shaka 2]

That's great, thanks.- Martin

[Guest GerrishGray]

Hi MartinActually, putting all the scenery and library objects into one BGL is a good approach that will give better performance if, but only if, the objects are used only by this one scenery.If, on the other hand, the library objects are going to be a 'shared resource' used by more than one different scenery then it is better to put them into a separate, self-contained, BGL.Another important factor with library objects is to use an efficient numbering scheme for the GUID's. Unfortunately, MS's suggestion of using a random number generator, whilst it is safe because it virtually guarantees that the GUID's are unique for every object in the whole scenery database (which is essential), is hopeless from an efficiency/performance standpoint. I wrote a separate post about this some months ago.Note that there are also considerations about where you should install shared library BGL's (and, indeed, shared textures) ... we could make a separate thread about this if you want to expand on the subject.As regards the size of BGL's generally, it is better from a performance standpoint to put everything into one combined BGL for a single scenery in a specific area, but, of course, easier from a design/maintenance standpoint to work with separate, neatly-compartmentalised, files. Which is what SCLINK, supplied with SCASM, is for. Design/build in separate files, link into one larger file for runtime/distribution.CheersGerrish

[Guest GerrishGray]

By the way, here are my notes about GUID numbering schemes:-GUID's for Library ObjectsWhen an object is called, FS takes the following steps:[ol][li]It checks the full GUID to see if the object is already loaded.[/li][li]If not, FS takes the id2.id1 part of the required GUID and compares it with the min/max table compiled earlier to see which BGL(s) the object might be in.[/li][li]The first 'candidate' BGL is opened and the full list of GUIDs is searched sequentially to see if the required value is present. If it is, the corresponding code block is located and loaded into memory ...[/li][li]If the required GUID is not found in the first candidate BGL, each remaining candidate is opened in turn and its list of GUIDs searched until the required object is found.[/li][li]If the required GUID is still not found, the famous 'Missing Object' message is generated![/li][/ol]Incidentally, this process is the same in both versions of FS library objects (i.e. pre-FS2000 and post-FS2000). Manfred Moldenhauer seems to have got a bit confused about this when FS2000 came out and made an the error in SCASM at that time which he has since corrected.Whilst it is true that the full 128-bit id4.id3.id2.id1 value is treated as a single 128-bit integer internally, this is of no practical significance at all as you can see from the description of the search process outlined above.Note in particular that the id4.id3 'high' 64-bits of the GUID are only used when performing the sequential search of the list within the candidate BGL to match the exact GUID required. And the overall sequence of this list does not matter either, as the search is sequential and it is always going to be necessary, on average, to search half the list to find the required object, whether the list is in a sorted sequence or is completely random. (This part of the search is very rapid anyway - it is the loading/opening of the BGL(s) that is the overridingly time-consuming operation).The suggestion in the FS2000/2 SDK that one might use the Windows random GUIDgen.exe generator to create object GUIDs does not seem to be ideal (and is NOT even used by MS themselves!). It would result in numerous overlapping min/max ranges in the headers of different library BGLs and would cause FS, on average, to have to open and search half of all the available library BGLs every time a new library object was first called for in a session - extremely time consuming and contrary to the whole purpose of library objects in the first place. This suggestion came about because of the need to ensure that the GUID of each individual library object is unique - i.e. different to the GUID of any other object in the whole scenery database - but there are adequate ways of doing that without having to resort to random 128-bit numbers.Manfred Moldenhauer's suggested scheme whereby the id1 value is incremented for each successive object in a library is, in fact, fairly efficient, providing that the id2 value remains constant throughout the BGL. Indeed, if the id2 value is itself unique and different from the id2 value(s) contained in any other library BGL, then only one entry in the min/max table will ever match the id2.id1 of a required GUID and FS will only ever have to open the one corresponding BGL to locate the required object ... But with only the id2 part to play with, it is difficult for a designer to ensure that the value choosen is indeed unique amongst all the library BGL's in the scenery database.Rafael Sanchez's scheme (which was actually the scheme originally recommended by Manfred Moldenhauer before he allowed himself to get confused by the FS2000 documentation) fixes id1, id2 and id3 in any one library and increments id4 instead. There is a far better chance that the id2.id1 combination will be unique than when only id2 is fixed, and thus a far better chance that only one BGL will have to be opened at runtime to find the required GUID.A variation on this idea that virtually guarantees a unique entry in the min/max table, and thus direct access to the correct library BGL every time, is to construct the id1 and id2 values from the ASCII codes for an 8-character file name used for the library BGL. Thus, if one's library was going to be called ArnoLib1.bgl, for example, you would use id1="Arno" (= 0x41726E6F) and id2="Lib1" (= 0x4C696231). If we all used this scheme, we would have a a fairly good guarantee of unique GUID's and always achieve maximum performance from the library object search process.Another, admittedly very minor, performance booster if one is creating a large library is to try to put the objects likely to be used most often in the early part of the BGL and relegate those used only rarely to the last part.CheersGerrishP.S. One further point when working with GUID's - if you ever have trouble reading GUID's from a compiled BGL and comparing them with the original SCASM or BGLC source code, it is because the compiled version is byte-reversed for each of the four 32-bit groups. Intel integers are byte-reversed internally, and although a GUID is nominally a 128-bit integer, Intel machines have to store them as four (separately byte-reversed) 32-bit integers.

[Shaka 2]

Hi Gerrish,This was very useful to me. I was incrementing the numbers anyway, but only because it seemed easier that way. I had set id4,id3,id2 to a randomish number that I based on my telephone number, and then incremented id1 starting at 00000001. It is interesting to read how FS looks up library objects, and it is this sort of insight that's going to help me make better scenery.Thanks again,Martin

[Guest sapper42]

Thanks for the Post aswell Gerrish, it cleared up some things i didnt know and or realised for my Library files.it never occured to me about the most common at the top and the least used at the bottom.rgds Jeff