I think the tactical map you see in the game is a Window into the full map as contained in the Map files.
The window moves (in 8KM strips?) as you progress.

Now I've got the game running again will check that.
Cheers,
Keith

The reason I don't believe that is, each time a new "strip" is added, LB goes through the decompression routine (for example - Decompressing AZR 3,0 > 4,0).
It takes about 25% of the time to do this as it does to go from NTC to AZR, where it requires decompressing an entire map from scratch. Since the game won't let you fly all the way to the edge of the tactical map screen, I can't tell if there is everything decompressed that is shown on the Nav map or not. I can see out there past the point where I get halted, but not as far as the edge of the Nav map. I assume they do this so you don't see the edge of the world and go insane.
Do you see what I'm getting at with the decompression routine, or am I off base here?

I can confirm that. It has to do with the campaign and so called "phase lines". They change according to the progress of the battle and dynamic campaign engine updates this window moving about the map. I have those infos from "Strategy Guide".

In AZR & NTC phase lines are E-W and sectors N-S. AZR has three maps ,but because of the overlap its practically only 2. NTC is only 1 map and was meant for multiplay playground.

Which brings little "heads up". Changing terrain may affect how campaign is played out. I know only from the book that movement of armor and therefore campaign progress depends largely on how flat the terrain is. We need to consider those mechanics too.

This thread is really quite long. How about splitting subjects and categorising them according to the game files or folders?

Excellent idea, these could then become stickys.

Re map sizes - it seems the full map is actually 50 KM by 50 KM.
Comparing a printout of ter_ul.map for azer6 with the in-game map for the 1st mission they are identical.

Cheers,
Keith

Keith, I have finaly put that puzzle map ter_?.map together. Do you need a sequence of that scramble?

The other way we could do some investigation about the original content of the maps is to see and compare what size are the files of equal size as maps, but in different formats and modes (index, rgb etc.) This lack of color is intriquing. Looking at textures in the game I do not think that hight method computation was used.

Is there any compression found in *.map file format.?

Have you guys read page 1.14 in the manual?

Those images look familiar! ;-)

What do you make of the "profiler" map function?

I also see that the Kiowa has a minimap/GPS thingy. Wonder how that's drawn?

Polak,
I think I've worked out the sequence.
Each MAP file is divided into 36 areas.
......
......
......
......
GHIJKL
ABCDEF
For UL there is one tile per area
for L there are 4 tiles per area
CD
AB
for M there are 16 tiles per area
IJKL
EFGH
ABCD
for H there are 64 tiles per area
........
IJKLMNOP
ABCDEFGH

What do you think?
---------------
I think the colours are generated by relative height - the valley floors are sandy, the slopes are scrubby, there are no repetitions that you would see with tiles.
Roads and rivers seem well implemented, I've seen much worse when tiled textures were used.
For 1997 I'm impressed!
There just isnt anywhere for colour data to be hidden in the files, just the palettes which are very small, enough to be used in code but nothing else.
The headers in the MAP file may define which palettes apply to which parts of the file?

The maps in the terrain folder are not compressed, the ones on the CD are.
They are also approx 1.6 times bigger than on disk - I guess the file on disk is a window in to the one on CD, as we were discussing earlier about decompressions during campaign play.

Cheers,
Keith

I'll address that map code later because I am still at work. I think there is small discrepancy in what I have came up with. But I wonder why they scrambled those maps?

As far as the color, perhaps you are right, but lets wait for someting on "field type" data.
If you guys go and register with gamasutra.com (nice name no?)and search the archive articles about texturing you may come up with pretty interesting ones. I'll search first and post titles later because do not remember now.
Multitexturing maybe, but we need to find yet those textures somewhere. There are textures because close by they are blurry. Programatically painted pixels would be I think rather pretty sharp. And there are visible edges of the tiles where pixels of different color do not allign.

I am combing files with hexeditor to search for *.tga, *.bmp, *.jpg strings. Anything else should I look, while I am at it? Anyone perhaps willing to do this "dirty" work too?
That may speed things up and bring us to the point that we really be repainting those pictures.

Sure give us a list of tools to use and what files to look at and what data to look for, and we'll help.

Many hands make light work!

Best way to look for strings is to use a program like Textscan from Analogx
Its free and extracts all types of strings for you nice and quick.
Has other good features too.

---
I guess the reason the LB2 devs coded the height tiles the way they did is to minimise memory use - just the set of high-resolution tiles around your location may be in memory?

Cheers,
Keith

I'd bet you're right, the hot video card at the time was the VooDoo2 with a whopping 8M of video memory. This would also explain why you see the terrain "warping" into shape around you as you fly. Now, what setting adjusts the range at which the detail chages from Medium detail texture to High detail texture, and can we modify it so it's not so noticable?
Do you think it's related to these settings in the OBJVIEW.INI file:

[Haze]
NumHazeTables=32
MaxHazeDistance=400000
HazeChunkBase=CM_HAZ__

[CTS]
Num256Buffers=4
Num128Buffers=2
Num64Buffers=1
Num32Buffers=1
DetailLevelling=1
TextureDLDepth0=70000
TextureDLDepth1=120000
TextureDLDepth2=200000
TextureDLDepth3=350000

[TerrainSystem]
MaxPolys=9000
PerspectiveDepth=40000

I kind of think that's what determines it, but what is a unit (i.e. 40000 = what distance?).
There are a lot of interesting-sounding settings in that file, I just wish I could change them on-the-fly for comparison, because I'm having a REAL hard time picking out the change once I exit and re-enter the game.

EL,
we have 4 levels of terrain height detail, which would point to TextureDLDepthn maybe,
high detail up to 700 M
medium up to 1.2 KM
etc
just a guess...
But assuming DL stands for DetailLevelling then maybe not?

What could CTS stand for?

Haze has the same 40000 distance so it might be possible to measure the distance to where an object disappears into haze?

Good Luck,
Keith

Thanks Keith, I downloaded it. I can actually use this at work too!

+G
Man, I've hacked on those values to no end. While it does have an effect, it's sure hard for me to pinpoint exactly WHAT it is effecting. I guess I don't have a very good eye. I wish I could multiplay with my 2 PCs here, I have identical systems and monitors, maybe if I run one with the hacked .ini and one with the original, I could tell better what the heck is going on. If anyone is interested, I've posted copies of my modified OBJVIEW.ini and CA.ini files on this Web page. They don't cause any problems with the game, but backup your original first, just to be safe.
Link

EL - I'll give those new settings a go this week.

Here is the TER_l.map code. I call it scramble code. TER_l.map is 144 textures 256x256 each which are loaded in sequence 2matching tiles a the time. Top row indicates original sequence, the bottom are the positions on the grid they have to be moved in order to became legeable picture. All of them need to be vertically flipped too.

So to make new map reverse process needs to be applied. The question is are the other maps scrambled the same way and from what if any reason? Looking at the Keith's post above the answer appears to be - no. And your sequence for TER_l.map was correct.


1 2 3 4 5 6 7 8 9 10 11 12
123 124 127 128 131 132 135 136 139 140 143 144

13 14 5 16 17 18 19 20 21 22 23 24
121 122 125 126 129 130 133 134 137 138 141 142

25 26 27 28 29 30 31 32 33 34 35 36
99 100 103 104 107 108 111 112 115 116 119 120

37 38 39 40 41 42 43 44 45 46 47 48
97 98 101 102 105 106 109 110 113 114 117 118

49 50 51 52 53 54 55 56 57 58 59 60
75 76 79 80 83 84 97 88 91 92 95 96

61 62 63 64 65 66 67 68 69 70 71 72
73 74 77 78 81 82 85 86 89 90 93 94

73 74 75 76 77 78 79 80 81 82 83 84
51 52 55 56 59 60 63 64 67 68 71 72

85 86 87 88 89 90 91 92 93 94 95 96
49 50 53 54 57 58 61 62 65 66 69 70

97 98 99 100 101 102 103 104 105 106 107 108
27 28 31 32 35 36 39 40 43 44 47 48

109 110 111 112 111 114 115 116 117 118 119 120
25 26 29 30 33 34 37 38 41 42 45 46

121 122 123 124 125 126 127 128 129 130 131 132
3 4 7 8 11 12 15 16 19 20 23 24

131 134 135 136 137 138 139 140 141 142 143 144
1 2 5 6 9 10 13 14 17 18 21 22

+G
Don't bother replacing the OBJVIEW.INI file, I'm now convinced it didn't improve the game any visually, and I reverted back to the original. Now, the CA.INI (which is the file that has values set when you enter the "Custom Graphics Settings" screen in-game) has some values that I was able to set higher than was possible with the slider bars, and it does improve the visuals (things like smoke effects and mesh detail). Just give that one a go and see what you think. Note that if you use the custom graphic sliders in-game, CA.INI will get modified and you'll need to re-load my file. I couldn't get the terrain mesh to quit "warping" no matter what I modified, the distance must be set by the .exe. I had such hopes.