Sign in to follow this  
Guest GerrishGray

Scasm Library BGL - Error w/multiple objects

Recommended Posts

Hey guys. I have been battling something for several months regarding the creation of object libraries. I have exhausted all my resources.I get the "Scenery Object Not Found" messages whenever I compile a library SCA containing multiple objects (with the latest SCASM compiler). When I split the file into 2 objects and compile them into 2 separate libraries, they work just fine.Here is a super simple SCA file containing two objects:

Header( 1  N80:00:00.00 S80:00:00.00 E180:00:00.00 W178:60:00.00 )LatRange(  S80:00:00.00  N80:00:00.00 )ObjID( 0146A176 95F37A12 089DEEEE 31C7E096 )LibObj(  PWR 100  SIZE 53  SCALE 1024  TYPE 2  NAME "Test Triangle 1" )BGLVersion( 0800 )Call32( :_tmp_0_Polygon_0 )EndVersionReturn:_tmp_0_Polygon_0TransformEndReturnEndObjObjID( 14A16BC2 09968740 F2458DEF 8F7C755D )LibObj(  PWR 100  SIZE 53  SCALE 1024  TYPE 2  NAME "Test Triangle 2" )BGLVersion( 0800 )Call32( :_tmp_0_Polygon_2 )EndVersionReturn:_tmp_0_Polygon_2TransformEndReturnEndObj

When I try and call these objects, I get the error on both objects. However, when I split the file into 2 objects (each with Header() and LatRange() calls), everthing works out just fine.Also, if I try and concatonate the files with CATBGL.EXE, I also get the same error.I know that I must be missing something very simple here. But, I have been through all the available DOCS and forums and cannot seem to locate any advice. Seems like I am the only one having the problem :(If anyone has ANY suggestions, I would love to hear them.Thanks,Allen Kriesman

Share this post


Link to post
Share on other sites
Help AVSIM continue to serve you!
Please donate today!

Hi Allen,I paste here a part of my library which contains 30 or so objects and compiles without problem.Header( 1 80 -80 -179 180 )Set( BUF 1024 )Set( areamx 1024 )Set( LINBUF 2048 )ObjId( 5469BA99 267300F0 022E0DB1 C0F65F5C )LibObj( PWR 0 SCALE .1 TYPE 1024 NAME Triam_Stairs1 ) VecPoints( m 0 48 226 68 0 23169 -23169 ; 0 48 226 72 0 23169 23169 ; 1;;; skip here Poly( m 0 31085 -10361 145 204 205 202 197 ) ReturnEndObj;;; now the second objectLibObj( PWR 0 SCALE .1 TYPE 1024 NAME Triam_Stairs2 ) VecPoints( m 0 38 81 18 16238 22973 16799 ; 0 38 13 28 12539 0 30272 ; 1;;; and so onThe file terminates with the EndObj of the last object. The ID codes are referred to the first one and I find this to be the best way to avoid any typo error in writing the ID in the calling file.Looking at your file I only see the presence of the LatRange() which surprises me. Actually I do not know why I am not using it. May be there is a was reason that I do not remember.Hope this is helpful, Luis

Share this post


Link to post
Share on other sites

Thanks for the reply Luis.The LatRange() part was put into the SCA file by BglAnalyze, after I disassembled the BGL file (to debug the compile). I do not think that it is really necessary.Are you saying that there is only one "EndObj" statement at the end of the file ? I always thought that there was one "EndObj" statement for every "ObjId" statement. My code compiles just fine. The problem occurs when I try and load the scenery. I also know that my calling method is correct, because it works just fine when the library objects are broken up into separate files.Thanks again,Allen

Share this post


Link to post
Share on other sites

Hi Allen.I wish I could help. I did decompile Gerrish Gray's trees library with BGLAnalyze. The resulting SCASM file appears to recompile correctly. The resulting BGL file is much larger than Gerrish's, but he used BGLZip to compress his file.Combined with Luis' experience, it appears to me the problem isn't with SCASM. :(Why not decompile a few library files, and see if you can spot something different in your code?Dick

Share this post


Link to post
Share on other sites

Hello all,Luis has the right answer on the library, there is not latitude range and any given latitude coordinates in a library, as this example:Set( BUF 1024 )Header( 1 200 -200 -200 200 )Set( LINBUF 1024 )set( fsvers 0x800 )set( areamx 1024 )ObjId( 11111111 22222222 33333333 1 ) ' Object #1LibObj( PWR 100 SIZE 0 SCALE 1 TYPE 0 NAME "name1" ) ....codeReturnEndObjObjId( 11111111 22222222 33333333 2 ) ' Object #2LibObj( PWR 100 SIZE 0 SCALE 1 TYPE 0 NAME "name2" ) ....codeReturnEndObjI Hope it will helpRafael Sanchez[a href=http://www.fsnova.com][http://www.fsnova.com/images/NsAnimation1.gif ][/a][/p]

Share this post


Link to post
Share on other sites

I use the same Header and LatRange values in my library (as the first post with the problem) and it works fine for me.Here is the code I use:

Header( 1  N80:00:00.00 S80:00:00.00 E180:00:00.00 W178:60:00.00 )LatRange(  S80:00:00.00  N80:00:00.00 )ObjId( 00000000 11111979 14122000 06012003 )LibObj( PWR 0 SCALE 0.5 )Include( molen1.sca )ReturnEndObjObjId( 00000001 11111979 14122000 06012003 )LibObj( PWR 0 SCALE 0.5 )Include( molen2.sca )ReturnEndObjObjId( 00000002 11111979 14122000 06012003 )LibObj( PWR 0 SCALE 0.5 )Include( molen2w.sca )ReturnEndObj

I have placed the actual code of the objects in separate files to keep it easy to read (the total library has 30 objects or so).So I would expect the header not to be a problem. At a first look the structure of Call-Return also looks correct (I assume some code has been removed, as I only see a TransformEnd).Arno


Member Netherlands 2000 Scenery Team[link:home.wanadoo.nl/arno.gerretsen]Arno's FlightSim World for scenery design hints, tips and other tricks...

Share this post


Link to post
Share on other sites

Hi Arno. You are correct, I did remove some of the non-applicable code before posting the example.Guys. Thanks for the examples. I tried them (replacing the ObjID statements with my own), and they still don't work.My calling BGLS were compiled with BGLC, not SCASM. Most of the time I use BGLC. I use SCASM only when I create objects with FSDS V2. I am starting to think that there might be some kind of problem in this area (BGLC calling SCASM). What throws me off is why the process works when the library objects are separated into their own files.I'll report back when I find a solution (hopefully).Thanks,Allen

Share this post


Link to post
Share on other sites

It is indeed strange that it works when you split them. I don't expect that BGLC or SCASM has anything to do with it, it must be in the code of the library somewhere.I guess it must be something in the actual code of the object that is wrong. When you have only one object FS probably doesn't complain about the error, but when you have more it does (this is just a wild guess :)).If you want you can send me the library, I would like to have a look at it.... :).Arno


Member Netherlands 2000 Scenery Team[link:home.wanadoo.nl/arno.gerretsen]Arno's FlightSim World for scenery design hints, tips and other tricks...

Share this post


Link to post
Share on other sites

I seem to have solve the problem.When building SCASM libraries, it appears that the AID (aid1..aid4) values for the objects need to be incremented contiguously (as in Arno's example above). This explains why the process works when the objects are broken up into separate library files, but not if combined together.Here is a little blurb from the FS2000 scenery SDK (same as FS2002)..."When a library object is called, the BGL system first searches its memory-resident libraries. If a library object with the same ID is found, it is called. If not, all available BGL files are searched. The search is quick and efficient because just the header of each file is read. If the ID called is out of the specified minimum/maximum range for that file, the next file is searched. When the object is found, it is put into its own memory area inthe library."In BGLC libraries, you can define the min/max range in the header. I guess that SCASM does this for you when it creates the BGL file.Hope this helps someone else down the road. And, thanks for all the suggestions.Cheers,Allen

Share this post


Link to post
Share on other sites

Hi AllenWhat version of SCASM have you been using? Older copies had a problem with indexing multiple objects in a library and I used to have to patch my library BGL's manually after compilation by SCASM. This has been fixed in the current versions of SCASM - make sure that you have the latest version by visiting www.scasm.deIncidentally, it is NOT necessary to sequence the ID's in the manner suggested by the FS2000 SDK or Manfred Moldenhauer's SCASM documentation. You can in fact use any random selection of ID's in any order if you wish. But the best scheme is the one demonstrated by Rafael Sanchez earlier in this thread, whereby one increments the id4 value (NOT id1). Keeping the id1 and id2 values constant throughout any one library BGL, and making sure that this pair of values is different to those used in any other library, will make Flight Simulator's task in searching for any particular library object as quick and easy as possible. (Yes, I know this is not how I indexed the Trees Library BGL's - but like everyone else I was mislead by the SCASM documentation. I know better now after examining how the scenery engine really works!)CheersGerrish

Share this post


Link to post
Share on other sites

Hi Gerrish,Are you sure that is the best way? I had it in my library like the example of Rafael, but I think it was when FsRegen was just new we also had a discussion about this order. Then we reached the conclusion that it is best to increase the id1 (that is also what FsRegen does automatically). I have now changed my library to that format.Arno


Member Netherlands 2000 Scenery Team[link:home.wanadoo.nl/arno.gerretsen]Arno's FlightSim World for scenery design hints, tips and other tricks...

Share this post


Link to post
Share on other sites

Hi ArnoYes, I'm quite sure! A library BGL contains the min and max of the 64-bit id2.id1 values in its header. During the FS boot sequence, FS checks the header of every BGL in the scenery database to see if it contains library objects and compiles a table of the min/max ranges and the BGLs they are contained in. Library BGLs also contain a list of all the full 128-bit id4.id3.id2.id1 GUIDs contained therein, with pointers to the individual code blocks, but this list is not consulted during the initial boot sequence.When 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 the earlier and current (FS2000 onwards) versions of library objects. Manfred Moldenhauer seems to have got a bit confused about this when FS2000 came out, and that is why he made 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 whatsoever 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 at all, 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 SDK that one might use the Windows random GUID generator to create object GUIDs is a very poor suggestion indeed (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 - but there are adequate ways of doing that without having to resort to random 128-bit numbers and the author of the FS2000 SDK obviously wasn't thinking clearly!!!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 he chooses 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 guarantee of unique GUID's and always achieve maximum performance from the library object search process.A final, admittedly 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.Hope this makes sense to everyone now. I did try to explain it once before, but it's sometimes difficult to get one's points understood when others are hell-bent on their own ideas, eh ;-)CheersGerrish

Share this post


Link to post
Share on other sites

Hi AllenYes, I now realise that you did tell us that in your original post - sorry I overlooked that! There was nothing wrong in the code structure that you presented in that post (assuming that there was actually some real code to be called by the Call32 statements and not just an empty framework) and so I have no idea why you had the problems you experienced ... but you say that you have managed to overcome them at last, so no worries! Of course, if you did indeed try using BGLC rather than SCASM (as you suggested in one of your later posts?), then it would have been quite easy to go wrong because of the sheer tedium (and opportunity for typing mistakes) of getting the correct min/max values in the header and constructing the object list section correctly. But, as you say, SCASM looks after that for us (the indexing mistake affected versions up to 2.5# and was corrected from 2.85 onwards).Kind RegardsGerrish

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
Sign in to follow this