Spring RTS Engine

So I found this:
http://springrts.com/wiki/Lua_OpenGL_Api#Textures
and made a mosaic:


http://pastebin.com/Zy288RrH

Problem is, "$info" always changes to whatever viewmode is currently active. Press F4, it changes to metalview. Press F1, it shows slopemap.
I want it to always display the LOS mode. Idea was to then draw that texture over the minimap, so that minimap can have fog of war too.

Also why does "$heightmap" not work despite HeightMapTexture=1 set in spring config?

And why does &grass not look more like this picture here: http://springrts.com/wiki/Mapdev:grass

I want it to always display the LOS mode

you can't because there is only one (shared) texture and it gets recycled when switching between the F* modes

Also why does "$heightmap" not work despite HeightMapTexture=1 set in spring config?

your GPU might be too old/crappy to support the HMT format (NPO2FP32)

Kloot wrote:

I want it to always display the LOS mode

you can't because there is only one (shared) texture and it gets recycled when switching between the F* modes

Maybe put it into a lowres texture that is in LosMap resolution (Pako made such a request iirc).

Kloot wrote:

Also why does "$heightmap" not work despite HeightMapTexture=1 set in spring config?

your GPU might be too old/crappy to support the HMT format (NPO2FP32)

FP32 values exceed 0..1 range, so such a texture will mostly be white (and black for underwater parts)

FP32 values exceed 0..1 range, so such a texture will mostly be white (and black for underwater parts)

ah yes, on maps with water there is a black & white image.

if the shared $info texture was seperated, that would be usefull I guess.

So what's the point of $heightmap? Asking because I tried using that to implement heightmap saving as a picture in Toolbox as car requested and I got the same results (with negative heightmap as black).

Normally textures GL_RGBA8 with 8bits per channel. Here you got a FP32 texture 32bit signed-float in a single channel. So it's not a texture in the old fashion, instead it's a data container in the new shader world. Means you cannot really render it to screen, if you want to use it, you must use a shader to process its data and put in something useful.
E.g. read it in a vertex shader to deform a vertex plane, or raycast in it, ...
But in your case you don't need a shader to _save_ it, cause you want to save it in a 32bit bitmap/png (w/o writing it myself I don't know how the final code would look like to do so).