-
Which the release of FS2020 we see an explosition of activity on the forun and of course we are very happy to see this. But having all questions about FS2020 in one forum becomes a bit messy. So therefore we would like to ask you all to use the following guidelines when posting your questions:
- Tag FS2020 specific questions with the MSFS2020 tag.
- Questions about making 3D assets can be posted in the 3D asset design forum. Either post them in the subforum of the modelling tool you use or in the general forum if they are general.
- Questions about aircraft design can be posted in the Aircraft design forum
- Questions about airport design can be posted in the FS2020 airport design forum. Once airport development tools have been updated for FS2020 you can post tool speciifc questions in the subforums of those tools as well of course.
- Questions about terrain design can be posted in the FS2020 terrain design forum.
- Questions about SimConnect can be posted in the SimConnect forum.
Any other question that is not specific to an aspect of development or tool can be posted in the General chat forum.
By following these guidelines we make sure that the forums remain easy to read for everybody and also that the right people can find your post to answer it.
GeoLock Beta Thread
- Thread starter tgibson
- Start date
tgibson
Resource contributor
- Messages
- 10,801
- Country
-
EDIT: I have now looked at version 1.0, thanks.
Is that OK? Since if FS reads the object first from the default Sydney.bgl file it will geo-lock the object for all instances during that FS session (at least for FS2004 as my testing found). Or does FS limit reading the library BGL file to when you are within that geo-locked area? I don't know that, but I'll test that.
OK, I'm back with my findings. I created a locked BGL file from the Orlando.bg file (using GeoLock_1000.zip) containing only the fantasy DC-3 and locked it to KMSY (values: 29.5, 30.5, -90.75, -89.75). I also created a placement file that places this object on the runway at KMSY. I moved both my locked BGL and the placement BGL file into a higher scenery layer, temp/scenery, then restarted FS. The DC-3 was present on the runway right where I placed it, so it appears that FS is reading the locking information in the header from my locked BGL file (in a higher scenery layer) rather than from the default Orlando.bgl file. It was untextured though, since I hadn't copied the textures. I know FS is loading the object from my BGL file because when I immediately go to FA08 and look at the default DC-3 it is also untextured, confirming my assumption that after FS loads an object with a given GUID, it always displays that object for the rest of the session. If I load FS at FA08 I get a textured DC-3, and if I then move to KMSY it's still displayed as textured.
So if present in more than one library BGL file, FS will load the object from the library BGL file that has a header located at the first airport loaded, and will display that object for the rest of the session.
One issue: When I create a BGL file with only one object (the fantasy DC-3) from the Orlando.bgl file (which is 813 KB), the resulting file is still 813 KB. If I then decompile it with BGLXML and recompile it with BGLComp, the size is now 363 KB. So the old model data from the unused objects appear to be included in the file? When loaded into Instant Scenery, only the DC-3 is available for placement.
Hope this helps,
Is that OK? Since if FS reads the object first from the default Sydney.bgl file it will geo-lock the object for all instances during that FS session (at least for FS2004 as my testing found). Or does FS limit reading the library BGL file to when you are within that geo-locked area? I don't know that, but I'll test that.
OK, I'm back with my findings. I created a locked BGL file from the Orlando.bg file (using GeoLock_1000.zip) containing only the fantasy DC-3 and locked it to KMSY (values: 29.5, 30.5, -90.75, -89.75). I also created a placement file that places this object on the runway at KMSY. I moved both my locked BGL and the placement BGL file into a higher scenery layer, temp/scenery, then restarted FS. The DC-3 was present on the runway right where I placed it, so it appears that FS is reading the locking information in the header from my locked BGL file (in a higher scenery layer) rather than from the default Orlando.bgl file. It was untextured though, since I hadn't copied the textures. I know FS is loading the object from my BGL file because when I immediately go to FA08 and look at the default DC-3 it is also untextured, confirming my assumption that after FS loads an object with a given GUID, it always displays that object for the rest of the session. If I load FS at FA08 I get a textured DC-3, and if I then move to KMSY it's still displayed as textured.
So if present in more than one library BGL file, FS will load the object from the library BGL file that has a header located at the first airport loaded, and will display that object for the rest of the session.
One issue: When I create a BGL file with only one object (the fantasy DC-3) from the Orlando.bgl file (which is 813 KB), the resulting file is still 813 KB. If I then decompile it with BGLXML and recompile it with BGLComp, the size is now 363 KB. So the old model data from the unused objects appear to be included in the file? When loaded into Instant Scenery, only the DC-3 is available for placement.
Hope this helps,
Last edited:
- Messages
- 8,893
My testing is unlocking more then locking. I am trying to understand the need for saving a texture sub folder in the geolocked folder.
As per the picture it says some of the textures were not found which is true for the bgl I unlocked but the same missing textures are in many other texture folders such as Global\texture, NAMW\texture and FSX\Texture. I don't think it is a problem but maybe the document could say some missing textures are being called for from other folders since those other folders are scope to the world placement.
As per the picture it says some of the textures were not found which is true for the bgl I unlocked but the same missing textures are in many other texture folders such as Global\texture, NAMW\texture and FSX\Texture. I don't think it is a problem but maybe the document could say some missing textures are being called for from other folders since those other folders are scope to the world placement.
The first thing that strikes me is that I should only report the texture as missing once.
The documentation does note the only textures that will be accessed are those in a companion texture folder. But I will emphasize the point as you suggest.
Available textures are saved routinely in the Geolock\Texture folder. Whether or not they need to be placed along with the generated library depends on the specific circumstances and can only be determined by the user. I'll give more coverage to that in the user manual as well.
Thanks,
Don
The documentation does note the only textures that will be accessed are those in a companion texture folder. But I will emphasize the point as you suggest.
Available textures are saved routinely in the Geolock\Texture folder. Whether or not they need to be placed along with the generated library depends on the specific circumstances and can only be determined by the user. I'll give more coverage to that in the user manual as well.
Thanks,
Don
Seems to work ok on the limited objects i tried 
i don't know if I'm comfortable with the unlocked/locked bgl being placed in the same folder as the stock one,
i wonder if it would be better to be put in a "sub folder" like the textures are in the GeoLock/texture folder to save any mistakes in the stock folder
just a thought, what do the others think?
i don't know if I'm comfortable with the unlocked/locked bgl being placed in the same folder as the stock one,
i wonder if it would be better to be put in a "sub folder" like the textures are in the GeoLock/texture folder to save any mistakes in the stock folder
just a thought, what do the others think?
Last edited:
- Messages
- 8,893
Ray
I don't mind if the unlocked/locked bgl is placed in the same folder as the stock one. Using ADE you have to load the unlocked bgl into the LOM so the scenery object that was locked can be placed anywhere in the world.
The geolocked utility is another way to place a locked object which we have being doing since the early days of FS2004. In my testing the only difference is procedural. I do like the features Don has added using some of the MCX coding.
EDIT---------------------------------
I failed to say that my testing is for airports I work on. Your case may be different since you develop for the masses
I don't mind if the unlocked/locked bgl is placed in the same folder as the stock one. Using ADE you have to load the unlocked bgl into the LOM so the scenery object that was locked can be placed anywhere in the world.
The geolocked utility is another way to place a locked object which we have being doing since the early days of FS2004. In my testing the only difference is procedural. I do like the features Don has added using some of the MCX coding.
EDIT---------------------------------
I failed to say that my testing is for airports I work on. Your case may be different since you develop for the masses
Jim, I didn't appreciate what you were saying in your first point above until after removing the duplicate entries in the missing files list and updating the documentation as you suggested in your second point. Then I realized that reporting textures as missing simply because they were not located in a companion \texture folder was unnecessary. If those textures were not otherwise available, the original models would be affected and, so, why would you want to copy them. And, if they were available to the original models, they would be available to the copies via the same mechanism.
So, I'm going to eliminate the missing textures reporting entirely.
Ray, I doubt any inflexible storage scheme I might implement would completely satisfy more than a small portion of users. What I would consider is another text box down by the "action" buttons allowing the user to specify a save location. The textbox would be initialized automatically to the source location. The user could change it and any change would persist from session to session (i.e., the automatic initialization would not occur). The user could revert to the source location by clearing the current selection. This scheme has the added advantage that, if the user chose to save to a folder named "scenery", Geolock could save the textures to a companion "texture" folder - creating one if it doesn't exist.
Don
Jim, Tom, if you haven't already done so, please install GeoLock 1.0.01 from http://stuff4fs.com.
Don
Don
tgibson
Resource contributor
- Messages
- 10,801
- Country
-
Hi,
Version 1.0.01 seems to have the same problem as earlier versions - when I chose only the DC-3 from the Orlando.bgl file the file size of the unlocked file is 813 KB, the same size as the original file. It should be smaller.
Hope this helps,
Version 1.0.01 seems to have the same problem as earlier versions - when I chose only the DC-3 from the Orlando.bgl file the file size of the unlocked file is 813 KB, the same size as the original file. It should be smaller.
Hope this helps,
It was due to the "half-fix" I applied this morning. While the file remains the original length, only the selected subset of the models will be active. The rest is simply wasted disk space. I won't bother re-releasing for a day or so to allow other comments.
Thanks again,
Don
Thanks again,
Don