Library object placement - BGLC code

[Guest christian]

A while ago M$ 'blessed' us with the BGLPlacer. I like the idea of the csv files (they even work with excel), but M$ had to spoil it for us once again.First, if any at M$ is reading this: take a big fat pen and write TEST SOUTHERN HEMISPHERE onto your monitor! Why do we always get punished? First those ugly shadow bands in FS2000, now the BGLC has a bug when translating the csv to asm... :-8Secondly, BGLC omits the BGL_CRASH_INDIRECT call. So, I assume that the objects placed with BGLPlacer will be 'crash-free'.In other words, the tool is close to being useless...Here is the BGLC code that most default objects in FS2002 use:

(header ommited); OBJECT DATABASEobject_data	label	word	LATBAND_START	LATBAND_REL 55272, 55700, object_list_0001; adjust values	LATBAND_ENDobject_list_0001	label	word	NEAR_FAR_SMALL_OBJECT_HEADER 0ffb14c92h, 77b14916h, object_end_0001, 100; adjust values	BGL_CRASH_INDIRECT 0, object_call_0001, object_scale_0001, object_instance_0001	SHADOW_CALL object_scale_0001	ADDOBJ object_scale_0001	JUMP object_end_0001object_scale_0001	label	word	SCALE_AGL object_fail_0001, 6000, 33, 00020000h, 0ffb14c92h, 0000h, 77b14916h, 0000h, 0, 0; adjust valuesobject_instance_0001	label	word	INSTANCE_CALL object_call_0001, 0, 0, 0object_fail_0001	label	word	BGL_RETURNobject_call_0001	label	word	BGL_LIBRARY_CALL 0C545A272h, 11D2E2ECh, 1000849Ch, 2AE60C5Ah; adjust values	BGL_RETURNobject_end_0001	label	word	EOL	EOF

This should be easy to change and not too hard to understand...Cheers, Christian

[rhumbaflappy 113]

Hi Christian.The Placer/BGLC bug... is it the header that's fouled up? Or are all the locations fouled up?I remember the Western Hemisphere 'tmf2bgl' header bug.Just curious.Dick

[Guest GerrishGray]

The bug in BGLPlacer is well known. I did have a vague idea that someone said there was a cure somewhere, but I didn't bother to pursue it because, as you say, the tool is fairly redundant anyway when you know how to code the stuff properly yourself ...Dick, is there a cure for the TMF2BGL bug then? It would save having to manually patch the Longitude in the BGL header, which is what I resort to at present.RegardsGerrish

[rhumbaflappy 113]

Hi Gerrish.Sorry, The 'cure' I use is a hex editor. But, some enterprising programmer could write a replacement for TMF2BGL... it just writes a BGL header for the file. Burkhard Renk has a small program that will alter the header: BGLPatch.zip]I do have a problem with BGL Placer... I can place objects in the southern hemisphere. Here's a state capitol building just north of Ryan's Creek:

; Generated by BGLPlacer 8.0;; format for each line is the following:;    EFFECT, ,,,,,,,,;    LIBRARY, ,,,,,,,,;    WINDSOCK,,,,,,,,,;    BUILDING,,,,,,,,,;LIBRARY,Sco_statecapital1,s46* 53.72',e168* 9.33',AGL,0.00,0.00,0.00,Very Sparse,""[/code

[rhumbaflappy 113]

Hi Christian.I also get object crashes. So the problem is most likely within the library... not BGLC or BGLPlacer. I think George Ioannu had a fix for some of the library files through fsregen... the bounds in the headers were not universal.. but tied to a smaller range ( Northern Hemisphere, of course ). Some discussion was made as to whether altering the bounds, and distributing the fixed libraries was a violation of copyright. That may, or may not, be true. But distributing a patch, that the user could apply to the libraries, would violate nothing.I also wonder if Renk's 'BglPatch', I referenced above, would be capable of 'fixing' the headers.Also, BGLPlacer has the Library object selection hard-coded! How weird! Why hardcode it, then cripple the available objects so they cannot be placed? Also, looking at the newest BGLC, I see the library GUIDs are also hard coded, to accommodate BGLPlacer, and that's why the .csv files work.The only good thing I can see, is that we discover we can use CSV files for some objects and effects, and that may have some use. Perhaps we can use that info for future use of include files with BGLC.In truth, the asm code, or SCASM code, gives a lot greater flexibility, and control.

[Guest GerrishGray]

Hi guysBGLPatch.exeThanks for the link - I hadn't come across that before. I wonder why Burkhard doesn't use it himself in FSLandClass? BGLPlacerAs regards the 'bug' in BGLPlacer, I take it that you are saying that the fault lies not with BGLPLacer itself but with the reduced bounds of the library headers in FS2002? I know of at least one place in the default scenery where MS tripped themselves up with the reduced bounds as they try to call an easter-egg (Stonehenge) that won't display because its position is outside of the bounds in its FS2002 library header - whoops! Apart from patching the bounds, there is another workaround for this by using the equivalent FS2000 libraries instead as the 'standard' ones appear identical in every respect except that they have worldwide bounds. I checked out BGLPatch, but it will only change the Longitude bounds, not Latitude, so it is not a solution to patching the libraries. Back to the old calculator and hex editor.Library Object GUIDsI believe that the reason the library GUID's are hard-coded into BGLPlacer and the latest BGLC is MS's solution to enabling objects to be referenced via their name. It seems that library objects have to be called by their GUID at runtime as the design of the indexing in the BGL header does not provide efficiently for use of the object name. This left MS with the task of[ul][li]either spending further time during the already interminable FS2002 boot sequence compiling an indexed table of library object names[/li][li]or hard coding a translation table into BGLPlacer and BGLC.[/li][/ul]They chose the second approach ... which is a pity because it presumably means that neither BGLPLacer nor the BGL_OBJECT LIBRARY option can be used to place third party library objects, only the default MS ones. The library GUID min-max bounds in the header work in a weird way too, using the least significant 64 bits instead of the most significant. Hardly an efficient way to construct an index for searching. The workaround when designing a library would seem to be to give all GUIDs in any particular library the same id0 and id1 values, so that FS can locate the correct BGL quickly, and then use the id2/3 end to identify the separate objects. Wish I had realised before I constructed my Trees Library, but it probably doesn't make a huge difference anyway.Library Object CrashesThe implication of what you have said is that the CRASH_INDIRECT call must be redundant anyway, which would explain why BGLC doesn't bother with it when compiling the BGLPlacer data. Should be quite easy to verify ... I knew it wasn't needed when calling the BUILDING objects, but assumed that was because they might be coded differently in g3d.dll-----I think that's enough different topics for one post!Gerrish

[Guest christian]

Hmm, how odd. My BGLC refuses to work, and I also used S45. Maybe that's the difference, I used 'S', whereas you used 's'.The csv translation is hardcoded and we can't access it even with include files, as far as I can see. But one can always edit the csv file and put the GUID in there...Gerrish, excellent point about the GUIDs. I always wondered why some of the ids are the same, but that really makes sense. I guess you lose the property of a GUID garanteed to be unique that way, but it should speed up the lookup significantly...About the crash detection. Did I understand it right that the CRASH_INDIRECT isn't needed? It's included in all default library calls in FS2002 and it made sense to me to have it. I guess that can be easily checked though.Cheers, Christian

[Guest GerrishGray]

Hi ChristianI think what Dick was suggesting was that the 'southern hemisphere' bug is simply a result of the restricted lat/lon bounds in the library files - have you looked at the BGL to see whether BGLC actually compiled anything or not?What I said about the GUIDs doesn't make them non-unique, only the first half so that the max/min bounds in the BGL header have a unique value. The correct BGL can then be located as quickly as possible in the first step of the call process, using only the bounds table compiled in the startup sequence. If the bounds cover a wide range that overlaps with other libraries in the table, then the call process may have to look at the full index in several BGLs before finding the object it needs ... Of course, I'm only saying this on the basis of what the FS2k SDK tells us about how the library call process works - who knows how accurate that really is :-hmmm As regards crash detection, I was going on what Dick said, i.e. that objects can generate crashes even when placed via BGLPlacer. The only obvious explanation for that is that CRASH_INDIRECT isn't actually needed in FS2002, which might explain why BGLC doesn't bother with it when working from the csv. I don't find it necessarily surprising that other code always includes the CRASH_INDIRECT code - let's face it, there are all sorts of misleading redundancies and left-overs in lots of MS scenery code - when a command becomes redundant, MS rightly turn it into a NOOP rather than (a) change all their existing BGL code and (:( lose compatibility with older third party scenery. There is of course another way of checking this out ... that would be reading an FS2002 Scenery SDK, but I guess testing will probably be about a million times quicker and at least twice as reliable!CheersGerrish

[Guest christian]

Hi Gerrish>I think what Dick was suggesting was that the 'southern >hemisphere' bug is simply a result of the restricted lat/lon >bounds in the library files - have you looked at the BGL to >see whether BGLC actually compiled anything or not?Yep, I got the explanation, and no, BGLC reports an error in my csv file and DOES NOT produce a bgl due to the error!!! That's my csv:LIBRARY,SCO_ndb_antenna_red,s45 0.0',e 175 0.0',AGL,0.00,0.00,0.00,Very Sparse,"">What I said about the GUIDs doesn't make them non-unique, yes it does theoretically. The GUIDs are produced by your random generator. Now a fully random generated GUID is apparently 'unique' because it's actually not random, but 'pseudo-random' so dependent on your system and the current time. I'm not 100% convinced that microsoft's claim of 'uniqueness' is true, because I don't know if it really is completely impossible that someone else will produce the same GUID. It may be that it just means it is exteremely unlikely such as some thermodynamic effects that could theoretically happen, but are so unlikely that we can safely assume that until now they have never happened, because the universe just isn't old enough.If you keep the first 3 id parts and then by hand modify the last one, you firstly greatly increase the chance that anyone else will reproduce this number by pure chance and also by modifying the last part, you step out of the 'pseudo-random' process, which is a very dangerous thing to do, if you want to make sure your number really is random.However, your argument of fast lookup should overweight the chance that anyone maybe could reproduce your GUID by chance. I don't even know how great that chance would be, it shouldn't be hard to calculate an approximate, but I can't be bothered... Hmm, having said that, I just calculated the chance that one person would pick the first 3 id blocks if they are generated randomly. It's about 8E28. If we get about 100,000 3rd party libraries that are commonly used, the chance of two having the same first 3 ids then is still 1:8E23 (and that doesn't take into account that there still is a forth id, which isn't completely random anymore though). I think we should be on the safe side (although the numbers are only pseudo-random, which can make a BIG difference) :-lol >As regards crash detection, I was going on what Dick said, >i.e. that objects can generate crashes even when placed via >BGLPlacer. I agree, but I think there are 2 possibilities:1) as you said, BGL_CRASH_INDIRECT may be just an old remnant. However, this command is in all the new gmax libraries (scenedb/cities)...2) M$ 'forgot' to include it in the new BGLC. Wouldn't be the first time...We could discuss this for hours, and it can be checked in minutes though, so we should really check...Cheers, Christian