Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[JotBe]

When you are in a certain height (on a hill, high plateau or on a mountain) and you want to place objects precisely there, then you must fit the scale of the Google map manually for a detailed reference (this one in the right bottom corner, activated by G-key).

On the other hand, when you are moving around in UFO mode over a landscape with valleys and mountains, you would not like to see the map changing the scale incessantly. Therefore the default behavier fits well!

So what about a checkbox which allows to set the behavier of the Google map scaling to the need?

• Default behavier (dependency on absolute altitude)
• dependency on height above ground

Or the behavier could be determined whether we are in sandbox mode or not?

JB

[cameni]

Actually the default behavior is to respond to a filtered height above the ground, at least that way it worked. It doesn't use the precise height above ground, as the maps tended to oscillate wildly. There should be also some hysteresis.

Or the behavier could be determined whether we are in sandbox mode or not?

This may be a good idea - let it depend on the precise height in the sandbox mode, and use the default behavior outside. But I remember someone wanted also a complete manual control, although that can be problematic - once you rise up and go fast, it could generate gazillion incoherent requests to Google Maps.

[ZeosPantera]

I still just want the ability to resize the map or (in the future) push the map to a second monitor or device.

[JotBe]

Actually the default behavior is to respond to a filtered height above the ground, at least that way it worked

Really? All my observations refer to 2m above ground at plane landscapes, version 3202:

Location:	Altitude:	Ruler displayed on Google Maps:
North Germany, near North Sea:	13m	200m/1000ft
Somewhere in Spain:	630m	1km/1mi
Somewhere in Tibet:	4900m	10km/5mi

If your statement above would apply, then at all visited location the Google Maps ruler should show about "200m/1000ft"?

...once you rise up and go fast, it could generate gazillion incoherent requests to Google Maps.

In order to prevent this a delay in the requests could be established.

And the complete manual control should be kept regardless to other implementation, of course!

Thank you for your reply and your time.

JB

[cameni]

If your statement above would apply, then at all visited location the Google Maps ruler should show about "200m/1000ft"?

Note I said filtered, using a coarse LOD level that changes very slowly, and does not correspond to the precise height.

...once you rise up and go fast, it could generate gazillion incoherent requests to Google Maps.

In order to prevent this a delay in the requests could be established.

There already is, but the point is that requesting high detail data when you are high above is pointless, that's why there's the adaptive mode, after all. But maybe it could be made better.

[JotBe]

Okay. In this context I thought "filtered" means not to take peaks into account, that's why I visited plane landscapes to get reliably average elevation data to compare with...

But what means peaks in a ragged landscape or with unsteadily elevation data? -- Now I see why you had to detach the data for the map scaling from the real elevation data.
If I understood you right this time?


I am sure, there a more important things to improve in this engine/game than my suggestion here. So put it where you want to.


Thanks again for your time!

JB

[cameni]

Well, "filtered" isn't probably the right word. Simply, to make it less sensitive to the local elevation changes, we took one of the coarser terrain level representations. The height changes less dynamically there, and as the result the map does not zoom in and out every time. However, the coarse representation only roughly matches the shape of the terrain, so the zoom level can vary when comparing different locations in the world.

I think your suggestion about basing it of the precise height in the sandbox mode is good and I'll put it in the todo list

[JotBe]

(Please don't kill me because of the following remarks: )

During this total discussion about bad side-effects taking precise elevation data for map scaling, I forgot completely, when I was talking about "2m above ground" and "absolute altitude" I refered on the values the HUD displays! And it seems to me these values are very harmonic, without any erratic changes.
Even if I sweep with high speed over the landscape, however, with negative pitch, the GRD-value keeps remissly at value 2m!
So which problems may occur basing on these numbers? (Me taking forehandedly cover... )

JB 

Okay, please delete this post, I made myself a complete idiot!

[cameni]

I think there's a bug in one mode where the GRD value doesn't update, but in UFO mode (without sandbox) it should be ok.