GeoLock Beta Thread

[gadgets]

Thanks for the update, Jim. I wouldn't anticipate any problems with unlocking files. All I do is clear the lock.

Locking is another matter. I had thought that defining the NW ands SE corners of the locked coverage area would be sufficient. However, all that produced was two small coverage areas at the corners. (Tom, The SW area must have been large enough to show the DC-3 at KMSY, but the NE corner area was not large enough to include KORL.)

I need to write some code to provide coverage for the whole rectangle defined by those corners. Its rather tedious, so it may be a day or so before I get back to you.

Don

 

[tgibson]

Thanks for not giving up.

 

[gadgets]

Not good news. It appears geo-locking is only effective for placements in the file. That is, if there are no placements in the file, the objects are ignored by FS - whether or not the user aircraft is within the geolocked area. Jim, is this consistent with your findings?

So, I can make it work if I add a dummy placement (e.g. below ground so they won't be seen) in the file for each object in the file. But this would seem to defeat the purpose of locking, i.e., to reduce overhead.

I will try a few other things. But, bottom line, unlocking may be all we can accomplish. However, there is a bonus, The program allows you to examine each object in the library (now that I've got the viewer working) - no need for thumbnails - though I expect there are other utilities available serving that purpose.

Don

 

[tgibson]

That's odd, since the Orlando.bgl file contains no placement data but is geo-locked. But I understand it might be something esoteric that MS added so we have no idea how it could work.

For now I guess I could examine this further by creating my own locked BGL file using BGLComp (by including placement data) and then creating a new file with only ModelData lines and using the header from my test file. Not very easy, but I should end up with a locked library BGL file with no placement information.

 

[gadgets]

That's odd, since the Orlando.bgl file contains no placement data but is geo-locked.

The standard compiler only generates header QMIDs (geolock code) when there is placement code in the file which defines the lock. It will not geo-lock a simple library file. So, MS did something special when it generated those geo-locked libraries.

What I have done so far is generate a single QMID covering the entire area. That's not working. The Orlando file contains a series of smaller-area QMIDs which, I suspect, collectively define the area of interest (I'll know by the end of the day. It may be that there is a limit to the size of the area that may be geolocked and your test area - which I am using - exceeds that limit.)

by creating my own locked BGL file using BGLComp (by including placement data) and then creating a new file with only ModelData lines

Not clear what this gains you. You'd have to include placement data for every use of every object in the file to be sure you had full coverage. Why then extract the placement data (and, presumably, put it in another file.)

MS has never made a habit of making it easy for us. Why should this be an exception?

Patrick Germain has just sent me the source code for BGLViewer. Perhaps I'll find the "secret" in there.

Don

 

[gadgets]

GOOD NEWS!!!!

The problem had nothing to do with geo-locking. It was my file naming scheme. Geo-locking now works fine - and has been for a while (but not back to the beta release you are using).

Turns out that FS does a non-standard interpretation of file names. It uses everything after the first period (.) in a file name as the file extension. So, if you have a file named "Orlando.bgl_Locked.bgl", for example, FS won't display it since it interprets file type as "bgl_Locked.bgl", not just "bgl". Get rid of the period in "o.b" and the DC3 shows up where it should.

Actually, it's my fault. I outsmarted myself. To make my life simpler, I added ".xxx" to "Orlando.bgl" so it wouldn't display. But, when I used that file as the source for my model I just stripped-off the ".xxx" and added "_Locked", giving "Orlando.bgl_locked.bgl".

I'll have a new beta release out later today - once I strip out all the test code I inserted trying to get this thing to work.

Don

 

[jvile]

Jim, is this consistent with your findings?

Don

So far all my testing as been unlocking bgl's. When you release the next beta I will test more in the area of locking bgl's since you are reworking the name scheme.

 

[gadgets]

New version attached (only the .exe and user manual have changed).

Currently, the "lock" area is a single QMID rectangle, which can result in a much larger geo-locked area than specified. I plan to investigate using several smaller areas instead where possible (the file header is limited to 8 QMIDs). So expect a Version 0.0.03 in a few days (or sooner if I'm lucky.)

Don

 

[tgibson]

Hi Don,

Yes, this seems to work fine using the FS9 Orlando.bgl file. I unlocked it, then locked the unlocked file. I do get proper unlocking and locking of the objects - thanks!

Some comments (the first two you already know):

1. The textures are not displaying on the displayed objects.
2. The lat long values increase a lot from the values I enter. For example, my values:
27 29
-82 -80

increase to:
22.5 33.75
-90 -75

That means that the new Orlando_Locked.bgl file is available in Miami and Atlanta - a huge area.

It's possible you could instead place two small QMID rectangles at the NE and SW corners (or something similar) and FS might produce a smaller locked area? Can you understand the QMID areas that BGLComp produces when it geo-locks a file?

3. It would be so nice if the program could read the min and max lats and longs of the included objects and enter those when you press the Geo-Lock button. If you enter your own values, it does not do that. Or add another button called something like Object Coordinates which would fill in the boxes? That would then light up the Geo-Lock button.

Thanks again,

 

[gadgets]

Thanks for the update, Tom. Responding to some of your comments:

The textures are not displaying on the displayed objects.

Do you mean in the Geolock Viewer or by Flightsim. They display for me in the viewer. If in flightsim, I suspect you'll have to copy the textures into a companion texture folder - unless the textures are located along Flightsim's default texture path. I can generate a list of textures required for the included objects - or I can create a new "texture" folder and place it in the Geolock folder for the user to move as necessary.

The lat long values increase a lot from the values I enter. For example, my values:
27 29
-82 -80

increase to:
22.5 33.75
-90 -75

That means that the new Orlando_Locked.bgl file is available in Miami and Atlanta - a huge area.

Yes. This is what I was referring to in the previous post and am about to attempt a fix. You need to understand QMID's to appreciate why the locked area will be larger than the specified boundaries unless those boundaries fall on a QMID boundary. I'm hopeful I'll have a fix in the next day or so.

It's possible you could instead place two small QMID rectangles at the NE and SW corners (or something similar) and FS might produce a smaller locked area?

That's what I did initially. Unfortunately, doing so results in coverage in the two small areas at the corners and nowhere else.

It would be so nice if the program could read the min and max lats and longs of the included objects

Unfortunately, objects don't include any positioning information. So, the best I can do is show the locked area.

I think you'll like the next version more.

Don

 

[gadgets]

MORE GOOD NEWS.

I have now implemented the new and improved QMID calculation. Your 27.9/29.0/-80 boundaries now compute to 26.71/ 29.53/-82.5/-78.75 - which is very much smaller than the previous single block result.

Now, for the textures.

Don

 

[tgibson]

Hi,

Great news about the area - that's perfect.

Perhaps you could have the program load a BGL file containing object placement data and create lat long values from that?

And I figured out my problem with the textures - they show up fine now. It helps if you have the textures present!!

Thanks,

 

[gadgets]

Perhaps you could have the program load a BGL file containing object placement data and create lat long values from that?

Not sure what you think that might accomplish. If the file contains placement data, the placement data will have been analysed by the compiler and the corresponding QMIDs set in the header setting out the smallest QMID-based area that will contain those placements. Knowing the individual lat/lons won't allow you to make it smaller.

If on the other hand, you are suggesting this simply as an alternative to the user specifying the boundaries, that could be done - but lets get the basic's stable first.

Don

 

[gadgets]

New version attached. It includes the update QMID generation (i.e., smallest possible lock areas) and textures are saved to the Geolock\Texture folder.

I'll give some thought to allowing the user to specify a locked file from which boundary coordinates are to be taken.

Don

 

[tgibson]

Hi,

I'll check it out. What I meant is that I have a BGL file the places these objects at a given airport (or airports). I would like to lock the library BGL (that contains the objects for this placement file) using the area defined by the objects' locations in this placement file. But now that I think about it I don't think it will be that useful (since there are objects in most of these placement files that are derived from multiple library files), so just defining a square around an airport's lat and long will be just fine for me, and I can do that manually.

 

[tgibson]

Hi,

I'm back. I checked it out, and it locks perfectly. It's just slightly larger than the entered coordinates and Instant Scenery reports the locking is exactly the size reported once you load the file back into GeoLock again. I find that if I lock my Orlando.bgl file using 28, 29, -82, -81 it gives coordinates quite similar to the original Orlando.bgl file, so that's what MS must have used for the most part - one lat and one long in size.

The only thing I would really like is a Select All button, or have the default load situation be all selected.

The texture system is neat, since I don't need to figure out the textures used for the objects selected - works great (assuming they are all there) All textures reported in the ModelConverterX Material Editor are included, which is good enough for me.

BTW, I am receiving some error messages - "Unable to Write File" and "Could Not Find Part of the Path" are the messages in the single error box, both referring to an MDL file, and then that MDL file doesn't appear in the MDL list. A restart of GeoLock seems to fix it.

Thanks again,

 

[gadgets]

The only thing I would really like is a Select All button, or have the default load situation be all selected.

Currently, as soon as you change any of the four boundaries, if you haven't selected any models, all are selected. But, I see no harm in selecting them all at startup. It will be done.

All textures reported in the ModelConverterX Material Editor are included, which is good enough for me.

Since the source of the data is the same in both cases (i.e., the TEXT block of the model) they should both report the same - except when files are missing - in which case I should (and will) list the missing files in the confirmation message.

I am receiving some error messages - "Unable to Write File" and "Could Not Find Part of the Path" are the messages in the single error box, both referring to an MDL file, and then that MDL file doesn't appear in the MDL list.

At what point in the process does this happen, please?

Don

EDIT: As soon as I looked at the code, I realized that harm would be done if I selected all models on startup. If any models are selected, a new file is generated containing only those models. All positioning data is discarded. If no models are selected, only the Unlock button is enabled. Click on it and the entire file will be saved - unlocked. So, a Select All button it is.

 

[jvile]

Question

I am working with the default Stock bgl's and ADE. I unlock the Sydney bgl and place a scenery object MDL building at JFK in New York.

If I share this airport with someone else will they see the building since they have not unlocked Sydney?

 

[gadgets]

If I share this airport with someone else will they see the building since they have not unlocked Sydney?

No. If you plan on sharing the airport, you should include in your airport archive a file (locked for New York) that includes the desired models.

This sounds like a question I should discuss in the user manual. Thanks.

Don

 

[gadgets]

Gentlemen, attached is the version of GeoLock I plan to release generally tomorrow (subject to your observations).

Please give it one last check.

Don