Sign in to follow this  
arno

The answer to 'locked library objects!!!!!!!!!'

Recommended Posts

I finally figured this one out...The scenery is not locked!!! It just hasn't spawned into memory...i.e. FS can only display a BGL contents that are residing in the computers memory...If you have the library object built in with the scenery in the BGL, guess what, your library object will not be present in the computer's memory to be able to call the object and display it...As soon as you fly into the scenery area that holds the scenery library object, the BGL loads into the computers memory and is then able to spawn the MDL's in that BGL....I'll explain why they have developed this technique the next time I post..Again, the MDL's are not locked, they are just haven't been spawned into memory and cannot display an object unless the BGL that contains that object has been loaded into memory...Ever have a "Duh, that was so simple the answer wsa staring us in the face all along" moment???

Share this post


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

Well, that is the normal process with any part of the scenery. The geographical position of any object within a BGL of the new type is in some way coded within the section header (I was not able to figure out the exact algorithm for that). You can check this if you write XML code for positioning an object in different parts of the world and then compare the result with a HEX editor. Files containing only MDL objects (without XML code to position them) have no position indicated in the section header. Apparently the sim loads them into memory (or at least loads pointers to them) during start-up. That is the reason why the sim rebuilds the indices during startup whenever you have changed something with MDL object libraries.- osman

Share this post


Link to post
Share on other sites

Hi all.If you use a decompiler on one of the locked libraries ( example... cairo.bgl in the "C:Program FilesMicrosoft GamesFlight Simulator 9SceneryAfriscenery" folder ), and recompile it with XML/BGLComp, the new recompilation will NOT be the same as the original cairo.bglThe original is locked, your recompiled version is not locked. This is because the BGLComp program we use cannot lock a library. Microsoft has used a different program to compile libraries. The program Microsoft uses can lock a library. The difference is in bytes 9-56 of the locked Library. Those bytes must be setting the bounds of the library, where our bytes 9-56 are blank.The work-around we have been using is to trick the sim using placement code in the library. As Arno has pointed out, this is not the best solution, as the trick can fail under the right circumstances. At best, we are making code that reliably shows only in specific areas.The bytes 9-56 are apparently 3 sets of 16 bytes ( or perhaps 6 sets of 8 bytes ). 48 bytes total. If 16 bytes, sets 2 and 3 are similar sets.Should we be able to decode these three sets, we should be able to make a tool that will absolutely lock the library, by altering the bytes 9-56 of our Library BGLs. BGLComp ( XML code ) cannot do this... we need to alter the bytes in the hex code.Dick

Share this post


Link to post
Share on other sites

Hi Dick,I have just been looking into this as well, I think it is byte 24 till 55 that does the locking.This is the first part of the anaheim.bgl as found in the namw scenery folder. I used this library as it conntains only one object, making it easier to read for me.01 02 92 19 38 00 00 00 F0 CB E8 AE 51 31 C3 0103 18 05 08 01 00 00 00 AE 30 08 00 AF 30 08 0004 32 08 00 05 32 08 00 06 32 08 00 07 32 08 0000 00 00 00 00 00 00 00 2B 00 00 00 05 00 00 00After I compared it with a library I had made myself, I found out that byte 24 is a 02 there and the rest are zeros. So I changed the anaheim.bgl to this:01 02 92 19 38 00 00 00 F0 CB E8 AE 51 31 C3 0103 18 05 08 01 00 00 00 02 00 00 00 00 00 00 0000 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0000 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00After that the locking was gone and I could place it anywhere in the folder.I think the locking code is grouped in pieces of 4 bytes, because when I make a BGL from an XML file that contains only one object, I only get 4 bytes of code from byte 24. The rest remains zero. As the origional anaheim.bgl has 5 groups of 4 bytes code, I think it has a wider allowed location then the XML code gives when you just compile a XML with a placement.Now indeed the only step is to figure out how the locking code works. I am chaning the position in the XML at the moment and looking at how these 4 bytes change. Hopefully I get some results out of that.

Share this post


Link to post
Share on other sites

Do any of the regular scenery BGL's have this code?Edit: Now for my gripe! Why do these forums let me log in only 30% of the time???? It's getting really frustrating! AVSIM needs some new forum software!!! phpbb.com has awesome BB software.... What is the likelyhood of an upgrade please??????????I may not be able to log back in to any replies...

Share this post


Link to post
Share on other sites

What do you call a regular scenery? I took an object library from the default scenery. The BGL files with the object placement also have hex code at these positions that looks similar.

Share this post


Link to post
Share on other sites

Hi Arno.You can lock a file in this manner:Make an XML file that contains you ModelData, and contains placement code. The placement code can be of a Bogus MDL... one that never existed:

<?xml version="1.0" encoding="ISO-8859-1"?><FSData version="9.0" xmlns:xsi='http://www.w3.org/2001/XMLSchema-instance' xsi:noNamespaceSchemaLocation="bglcomp.xsd">	<SceneryObject lat="1.0000" lon="1.0000" alt="0" pitch="0" bank="0" heading="0" altitudeIsAgl="TRUE" imageComplexity="NORMAL">		<LibraryObject name="00000000000000000000000000000000" scale="1.0" />	</SceneryObject>	<ModelData name="0B723A314BE5DA79E22448B2E54B2E20" sourceFile="100MeterCube.mdl" /></FSData>

Or it can be of the real MDL itself. Here the lock is N1.000 by E1.000As was noted earlier, if you first visit this object's location, then you can place the object anywhere and it will display. This is also true of MS' default objects that are locked. You can place them anywhere in the world, and then they will show, as long as the original placement was first visited. As noted above, it means they are not placed in memory until they are first displayed.Even more shocking, if you visit the relocated placement first the object won't display ), then use a FLT file to go to the default locked location, the default will not show in either!So this is a bug, not a feature. And that makes me rethink my position concerning the redistribution of unlocked generic BGLs. If it is a bug, then we wouldn't necessarily be violating a EULA or copyright if we are fixing a product that was determined defective. An unauthorised "bug fix" wouldn't be an item that courts would take seriously... we have done that in the past with flight simulator in different versions for many years. We're actually doing Microsoft a favor by correcting defective software. As long as the fix was not sold or distributed with other retailed software, we'd be fine.===================I've been aware that different MDLs can share the same GUID. I don't know how that would affect autogen displayed MDLs, but the "local" folder priority seems to control which MDL is displayed. I don't know if the "IFIN_BOX_PLANE" ASM command would help define areas of local vs. global mdl usage for identical GUIDS.Having bounds for a GUID usage would make a lot of sense, but the current usage is buggy as demonstrated.For future versions of Flight Simulator, the best course would be for the design crew to allow us the ability to have much more local control over the global elements of the sim... so we can replace mesh and flattens with certainty, or use local autogen.xml files that can replace autogen display easily... or allow bounds on GUIDs. Much better than trying to "trick" the sim. Dick

Share this post


Link to post
Share on other sites

Hi Dick,Thanks, your conclusions are the same as the ones I had (locking does not work when origional placement loaded first and if you load another location first nothing shows at all).So indeed, I see it more like a bug than a feature as well.I think it would still be interesting to see how the locking in the BGL exactly works, as I have found the bytes that change due to the locking. I only need to find out how they relate to the position. Changing these bytes as shown above is enough to stop the locking (and thus also solve the bug).What if I made a little tool that could remove this locking? Then people can decide themself if they want to fix it. And we don't have to distribute new BGL files.

Share this post


Link to post
Share on other sites

Arno that sounds like a great idea ;)But will that interfere with my attempts to localize the autogen ???

Share this post


Link to post
Share on other sites

Hi flightsimstudios.If Arno's tool just located and altered the default BGLs ( the best solution ), yours would still be locked. Just keep in mind the locking is not foolproof. I still think you will need to crack the code that MS used to lock the objects to an area rather than a specific refpoint. MS is not using simple lat-long designation such as BGLComp can produce... it is some kind of QUAD or QMID scheme.Dick

Share this post


Link to post
Share on other sites

What MSFT is doing is setting a boundary on the BGL file to limit the memory overhead. Every file opened by the FS engine incurs a memory hit so if an BGL file contains objects that are only used in a small geographic area this 'locking' prevents the file from being opened when the user isn't flying in that area. MSFT uses a program that 'touches' the compiled BGL file to set these bounds and probably should have included it with the SDK and encouraged third party developers to use it. Maybe they'll update the BGLComp SDK...

Share this post


Link to post
Share on other sites

Hi tdragger.I'm sure you are right.It would be nice if we didn't have to reverse engineer the bounding numbers, but it's unlikely that will occur. MS is done with the FS9 SDKs. Our best hope is that FS10 will be better documented, with better tools, and the bugs removed. As I found, this locking is buggy, and perhaps not of much use to us... once they are loaded, changing location outside of the bounds doesn't release them ( or their textures ) from memory.You can't really blame the designer team for this. Their focus is not on reworking the sim, but on simply on creating the base product. They never considered the need to release the objects from memory outside the bounds.They could just as easily left them unlocked. I've unlocked them in my sim in the past, and the memory usage is relatively small, with no FPS slowdown.Dick

Share this post


Link to post
Share on other sites

<>Ha! Yeah, they know about that. Doubt we'll see it fixed, though... :-(

Share this post


Link to post
Share on other sites

Hi Dick,>I still think you will need to crack the code that MS used to>lock the objects to an area rather than a specific refpoint.>MS is not using simple lat-long designation such as BGLComp>can produce... it is some kind of QUAD or QMID scheme.I think you are right about some sort of QUAD or QMID scheme, I just can't understand the logic in it at the moment. I have been evaluating how the values change when I move the reference point, but can't find the logic in it yet.It would be useful if we could also add locking to a library (although it is not perfect).

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