Section 8 questions - WaWMapEd

[omegaall]

Section 8 questions re Fred Chlanda´s WaWMapEd.

In this I gather from RockingHarry’s document S8 Bytes 6 and 8 are classed as:
Byte 6 - armor/infantry spotting or defensive (?)
Byte 8 - armor/infantry spotting or (defensive (?) HARDCODED)

Firstly what is the actual difference between these two, Byte 6 and 8 as they are described as armor/infantry spotting or defensive?

Further on it indicates that these bytes are “Line of Sight Hindrance/Concealment for Inf&Armor?”

Is it a case that Byte 6 is line of sight hindrance and Byte 8 Concealment?
Thus are they separate issues or do these two actually work together to formulate a concept of Line of Sight Hindrance and Concealment?

With this if a hex is marked as a stone building, ie S8 Byte 0 is set to 16, S8 Byte 6 to 0, S8 Byte 8 set to 0 and the S8 pull down menu set to stone building, that hex in SPWAW blocks line of sight past that hex, that is it casts a line of sight shadow.
After loading the map in SPWAW and then returning to WaWMapEd, S8 Byte 6 and 8 are set by the game engine as Byte 6 to 20 and Byte 8 to 100. As a comparison if in the SPWAW map editor a stone building is placed these two bytes hold the following data, Byte 6 set to 20, Byte 8 set to 110. Again in SPWAW the placed stone building produces the same line of sight shadow as the previous pretend stone building.

So with this does it mean the Byte 6 defines the probability of a unit in a hex being spotted, and the Byte 8 value the defensive probability? Here I use the concept of probability not actual value.

Thanks

[RockinHarry]

ORIGINAL: omegaall

Section 8 questions re Fred Chlanda´s WaWMapEd.

In this I gather from RockingHarry’s document S8 Bytes 6 and 8 are classed as:
Byte 6 - armor/infantry spotting or defensive (?)
Byte 8 - armor/infantry spotting or (defensive (?) HARDCODED)

Firstly what is the actual difference between these two, Byte 6 and 8 as they are described as armor/infantry spotting or defensive?

Further on it indicates that these bytes are “Line of Sight Hindrance/Concealment for Inf&Armor?”

Is it a case that Byte 6 is line of sight hindrance and Byte 8 Concealment?
Thus are they separate issues or do these two actually work together to formulate a concept of Line of Sight Hindrance and Concealment?

With this if a hex is marked as a stone building, ie S8 Byte 0 is set to 16, S8 Byte 6 to 0, S8 Byte 8 set to 0 and the S8 pull down menu set to stone building, that hex in SPWAW blocks line of sight past that hex, that is it casts a line of sight shadow.
After loading the map in SPWAW and then returning to WaWMapEd, S8 Byte 6 and 8 are set by the game engine as Byte 6 to 20 and Byte 8 to 100. As a comparison if in the SPWAW map editor a stone building is placed these two bytes hold the following data, Byte 6 set to 20, Byte 8 set to 110. Again in SPWAW the placed stone building produces the same line of sight shadow as the previous pretend stone building.

So with this does it mean the Byte 6 defines the probability of a unit in a hex being spotted, and the Byte 8 value the defensive probability? Here I use the concept of probability not actual value.

Thanks

I´ll try to give some in depth answers in short![:)] ...did you check here for some more already?

http://www.spwaw.com/phpBB2/viewtopic.php?t=5329

Btw, to see the screenshots you need to be logged in!

[omegaall]

Thanks. What has me more confused is the use of the S8 Byte8 value and the comments re line of sight.

The way I see this, and I might be wrong, is that Byte 6 sets the chance of being seen while the byte 8 sets the concealment value for that aspect of terrain. So low value in Byte 6 indicates a high chance of being spotted, high vaue not being spotted. The same with Byte 8 low valu such as 10 open ground poor concealment but good vision, vs higher number good concealment and limited vision. Vision range also being defined by the vision ofteh scenario also.

Am I on the right track?

[omegaall]

After some more mucking about with these two Byte values it appears as if they are iner-related in how the overall effect is obtained. I think I ahve he effects of byte 6 sorted out but Byte 8 is not making sence.

[RockinHarry]

ORIGINAL: omegaall

Thanks. What has me more confused is the use of the S8 Byte8 value and the comments re line of sight.

The way I see this, and I might be wrong, is that Byte 6 sets the chance of being seen while the byte 8 sets the concealment value for that aspect of terrain. So low value in Byte 6 indicates a high chance of being spotted, high vaue not being spotted. The same with Byte 8 low valu such as 10 open ground poor concealment but good vision, vs higher number good concealment and limited vision. Vision range also being defined by the vision ofteh scenario also.

Am I on the right track?

From my past observations I think we both coincide about what Byte 6 might do in the game; concealment/spotting chance. Byte 8 still is a little bit of a riddle. While it definitely influences Line of Sight through the hex, it does not linearly, in example with a staraight 0 to 100 chance (not regarding weather and Max view range). Figures go up to 131 for multihex buildings and that messes with my "theory". Whether Byte 8 also serves as additional cover modifier, well I can´t really tell. I was told that cover (the defensive value of a particular terrain) is hard coded in the mech.exe and is not to be changed by data in the *.dat files. Now that Mike Wood just reappeared in the forum, we should take the opportunity to ask him about that! He surely knows as he did code all that stuff![:)]

[omegaall]

ORIGINAL: RockinHarry


From my past observations I think we both coincide about what Byte 6 might do in the game; concealment/spotting chance. Byte 8 still is a little bit of a riddle. While it definitely influences Line of Sight through the hex, it does not linearly, in example with a staraight 0 to 100 chance (not regarding weather and Max view range). Figures go up to 131 for multihex buildings and that messes with my "theory". Whether Byte 8 also serves as additional cover modifier, well I can´t really tell. I was told that cover (the defensive value of a particular terrain) is hard coded in the mech.exe and is not to be changed by data in the *.dat files. Now that Mike Wood just reappeared in the forum, we should take the opportunity to ask him about that! He surely knows as he did code all that stuff![:)]

On this topic and to add confusion re S8 Byte 8 I did some minor tests as follows:

Tests using test range as in pic attached
Scenario settings:
Time setting: 1200 hr
Weather setting: 1
Visibility setting 15
Map tile type: Summer

Test 1
byte 0 0
byte 1 0
byte 2 0
byte 3 0
byte 4 1
byte 5 0
byte 6 2
byte 7 0
byte 8 10
s29 12
stationary unit visual contact at 5 hexes
moving unit visual contact at 3 hexes
scenario visual range set 15
map visual range(from grass) 15

Test 2
byte 0 0
byte 1 0
byte 2 0
byte 3 0
byte 4 1
byte 5 0
byte 6 2
byte 7 0
byte 8 20
s29 12
stationary unit visual contact at 5 hexes
moving unit visual contact at 3 hexes
scenario visual range set 15
map visual range(from grass) 15

Test 3
byte 0 0
byte 1 0
byte 2 0
byte 3 0
byte 4 1
byte 5 0
byte 6 2
byte 7 0
byte 8 40
s29 12
stationary unit visual contact at 4 hexes
moving unit visual contact at 3/4 hexes
scenario visual range set 15
map visual range(from grass) 15

Test 4
byte 0 0
byte 1 0
byte 2 0
byte 3 0
byte 4 1
byte 5 0
byte 6 2
byte 7 0
byte 8 80
s29 12
stationary unit visual contact at 4 hexes
moving unit visual contact at 4 hexes
scenario visual range set 15
map visual range(from grass) 15


Outcomes:
In these tests the only change was to the value of S8 Byte 8.

Though these are minimal tests it may be considered that S8 Byte only provides additional factoring to the effects caused by S8 Byte 6.

S8 Byte 6 sets the Line Of Sight / Terrain Masking Effects for a specific terrain type. It appears to have a greater affect that on this aspect than S8 Byte 8

S8 Byte may have effects that determine the ability of a ‘searching party to see the stationary one. That is it has effects on the concealment factors of the terrain on a non moving unit, especially infantry.

From most of this it would appear the main terrain effects to Line Of Sight / Terrain Masking Effects is carried out by S8 Byte 6.

So it leaves some question as to making changes to the S8 Byte 8 value.[:@]

[RockinHarry]

No real news regarding Byte 8 as it seems. I keep using Byte 8 for line of sight blocking purposes since it works pretty well for me this way. IE I set Byte 8 of those hexes to about 2-5 that I want to serve as light woods or tree lined roads. This way you could see farther along tree lined roads as usual. The standard value for trees (30) usually blocks LOS after 2-3 hexes at the latest.

Unfortunately Mr. Michael Woods declared this particular info to be propriatary information [8|], well...I can´t remember having asked him for showing parts of the "code" so the question would be why editors are shipped with the game that allow to edit data declared as "propriatary information" ???????????????[8|]

[omegaall]

From my simple example Byte 8 does little with "grass" here it is apparently better to use Byte 6.

I am beginning to think Byte 8 has more effect on "solid" things such as wood as you have pointed out.

In general these two work together in some mysterious way.

I wounder if the "propriatary information" is because this is some little bit of code not easily understood by the people rehacking the original code..

Something that could be called [&o]" Programmer's Secret Business" ..

As it is I am looking for a way to increase the "hiding" ability of high grass/sand dunes but not actually reducing teh viewing ability of a unit in this terrain.

[RockinHarry]

ORIGINAL: omegaall


I wounder if the "propriatary information" is because this is some little bit of code not easily understood by the people rehacking the original code..

Something that could be called [&o]" Programmer's Secret Business" ..

What I had in mind actually was a "simple" confirmation whether Bytes 6´n 8 work the way we think...or not. That would be a "satisfactory" answer. The "propriatry" thingy is non agreeable to me. Don´t ship the editors with the game or delete the section from the manual where I make all the statements concerning the terrain data system. Maybe asking Gary Grigsby would be the better way....

[omegaall]

ORIGINAL: RockinHarry

What I had in mind actually was a "simple" confirmation whether Bytes 6´n 8 work the way we think...or not. That would be a "satisfactory" answer. The "propriatry" thingy is non agreeable to me. Don´t ship the editors with the game or delete the section from the manual where I make all the statements concerning the terrain data system. Maybe asking Gary Grigsby would be the better way....

I agree the "proprity" thing is a cloud. The more the users, espicially scenario designers, understand the better the game will be and the quality of scenarios can only improve more.

I still find that the combination of Bytes 6 & 8 are connected and to some level linked to teh settings of Bytes 0 -3.
This is I suspect a non trivial problem. Trial and error testing will take huge amounts of time just in setting up each test with out recording results.

I think you suggestion of going to the [&o][&o][&o] "Source", would be useful IF there is going to be an answer.

[Mike Wood]

Hello...

What I meant was that I could not show you any sizeable portion of the code. I really have no idea what it is that you are talking about or what you are trying to do. I asked Gary and he has no idea, either. Your discussion is based on a hack made of a file. I have never seen that code or even the editor. I delt with things using a different convention and from a different viewpoint. Below may be what it is you are looking for and then again, it may not be. Let me know.

Hope this Helps...

Michael Wood

enum terType_e
{
TER_NONE =0,
TER_FIELD =1,
TER_SLOPE =2,
TER_TREE =4,
TER_RIVER =8, // stream
TER_BUILDING_S =16, // stone building
TER_BUILDING_W =32,
TER_ROAD_DIRT =64,
TER_ROAD_PAVED =128,
TER_BRIDGE_W =256, // wood
TER_BRIDGE_S =512,
TER_SWAMP =1024,
TER_LAKE =2048,
TER_ROUGH =4096,
TER_HOLE =8192,
TER_TRENCH_I =16384,
TER_TRENCH_G =32768,
TER_RAIL =65536,
TER_BRIDGE_R =131072,
TER_IMPASS =262144,
TER_RICE =(TER_IMPASS*2),
TER_WATER_S =(TER_RICE*2),
TER_WATER_D =(TER_WATER_S*2),
TER_WRECK =(TER_WATER_D*2),
TER_ORCHARD =(TER_WRECK*2),
TER_WALL =(TER_ORCHARD*2),
TER_TRAIL =(TER_WALL*2),
TER_BOCAGE =(TER_TRAIL*2),
TER_CLIFFS =(TER_BOCAGE*2),
TER_ROCKS =(TER_CLIFFS*2),
TER_IMPASSABLE =(TER_ROCKS*2),
TER_ALL =(TER_IMPASS*2-1)
};

ORIGINAL: RockinHarry

ORIGINAL: omegaall


I wounder if the "propriatary information" is because this is some little bit of code not easily understood by the people rehacking the original code..

Something that could be called [&o]" Programmer's Secret Business" ..

What I had in mind actually was a "simple" confirmation whether Bytes 6´n 8 work the way we think...or not. That would be a "satisfactory" answer. The "propriatry" thingy is non agreeable to me. Don´t ship the editors with the game or delete the section from the manual where I make all the statements concerning the terrain data system. Maybe asking Gary Grigsby would be the better way....

[omegaall]

Mike, thanks for that. I find it an interesting enum from a programming point anyway.
The problem is a bit more complex as it relates to aspects of terrain and the ability of that terrain to provide viewing and concealment ability.

The values you provide define the terrain type and from my point explain a few things.

I am not sure if RockinHarry can easily put it into words here or not.

One option would be to put together a more detailed description of what we are trying to discuss and email it to you direct. Is that Ok?

I suspect this is a topic for a few of us who do scenario/map work so its not a big public topic.

Mike just in case we are not chasing teh source code just the behaviour.

[Mike Wood]

Hello...

Should probably post "detailed description" here. That way, if any others have same question, they can refer to this thread.

Thanks...

Michael Wood

ORIGINAL: omegaall
...One option would be to put together a more detailed description of what we are trying to discuss and email it to you direct...

[omegaall]

Ok. Give me something to do other than work for the rest of the night

[omegaall]

Mike, I ahve tried to outline the situation we have been discussing below:


From what I can determine from various sources terrain is defined as a C type struct
This structure has a complete size of 20 bytes.
This is broken down as:

Terrain Type:
This is probably a signed long/extended int type value, (signed/unsigned?), (32 bits)
Consists of byte 0 – 3 describe the actual terrain type, e.g. field woods etc

Terrain Height
This is probably a signed int,(long int), type value, (signed), (16 bits)
Consists of byte 4 – 5 describe the height of the terrain hex.
This has a range of –32257? to 32767

Line of Sight terrain effects/modifier:
This is probably a signed int,(long int), type value, (signed), (16 bits)
Consists of byte 6 – 7, the value tends to be in the low byte,(byte 6).

Defence/concealment modifier:
This is probably a signed/unsigned? char type value, (8 bits)
Consists of byte 8
The actual effects are not actually clear.

The rest cover terrain effects such as:

Byte 9: Smoke Values (0-100%) 101 means fire in Hex!
Byte 10: hex damage level 0-200%, used for shell holes and rubbled buildings (graphics)
Byte 11: (Map Text container number)
Byte 12: secondary road connections
Byte 13: primary road connections
Byte 14: RR connections
Byte 15:? (not used?)
Byte 16:???? Hex fire Spread/Smoke Spread???
Byte 17:? (not used?)
Byte 18:? (not used?)
Byte 19:? (not used?)

The discussion at present is concentrated on the interaction of the “Line of Sight terrain effects/modifier”, which we have been referring to as S8 Byte 6 and the “Defence/concealment modifier” which has been referred to as S8 Byte 8.

The terms S8 and Byte 6/8 come from the use of the SPWAW Map editor by Fred Chlanda, which comes with teh game, hence the terminology confusion.

The problem we are encounting is how to interoperate the use of the values stored in this section of the Terrain description record. There are situation as map/scenario designers it is useful to modify the game defined values to improve the realism of the terrain we are working on. As a simple example high grass in the pacific arena has different characteristics that high grass in the European arena. Similarly woods are not all as dense as defined by the standard game model.

To use these areas of terrain description it we are trying to find out what the values do and the interaction between theses values.

Harry might be able to expand on this as he has more experience with map design.

Thanks

[RockinHarry]

ORIGINAL: Mike Wood

Hello...

What I meant was that I could not show you any sizeable portion of the code. I really have no idea what it is that you are talking about or what you are trying to do. I asked Gary and he has no idea, either. Your discussion is based on a hack made of a file. I have never seen that code or even the editor. I delt with things using a different convention and from a different viewpoint. Below may be what it is you are looking for and then again, it may not be. Let me know.

Hope this Helps...

Michael Wood

enum terType_e
{
TER_NONE =0,
TER_FIELD =1,
TER_SLOPE =2,
TER_TREE =4,
TER_RIVER =8, // stream
TER_BUILDING_S =16, // stone building
TER_BUILDING_W =32,
TER_ROAD_DIRT =64,
TER_ROAD_PAVED =128,
TER_BRIDGE_W =256, // wood
TER_BRIDGE_S =512,
TER_SWAMP =1024,
TER_LAKE =2048,
TER_ROUGH =4096,
TER_HOLE =8192,
TER_TRENCH_I =16384,
TER_TRENCH_G =32768,
TER_RAIL =65536,
TER_BRIDGE_R =131072,
TER_IMPASS =262144,
TER_RICE =(TER_IMPASS*2),
TER_WATER_S =(TER_RICE*2),
TER_WATER_D =(TER_WATER_S*2),
TER_WRECK =(TER_WATER_D*2),
TER_ORCHARD =(TER_WRECK*2),
TER_WALL =(TER_ORCHARD*2),
TER_TRAIL =(TER_WALL*2),
TER_BOCAGE =(TER_TRAIL*2),
TER_CLIFFS =(TER_BOCAGE*2),
TER_ROCKS =(TER_CLIFFS*2),
TER_IMPASSABLE =(TER_ROCKS*2),
TER_ALL =(TER_IMPASS*2-1)
};

ORIGINAL: RockinHarry

ORIGINAL: omegaall


I wounder if the "propriatary information" is because this is some little bit of code not easily understood by the people rehacking the original code..

Something that could be called [&o]" Programmer's Secret Business" ..

What I had in mind actually was a "simple" confirmation whether Bytes 6´n 8 work the way we think...or not. That would be a "satisfactory" answer. The "propriatry" thingy is non agreeable to me. Don´t ship the editors with the game or delete the section from the manual where I make all the statements concerning the terrain data system. Maybe asking Gary Grigsby would be the better way....

Ok, thanks! At last it appeared to be a simple misunderstanding! My fault.[:o] What all the stuff is good for (editing particular data bytes in Fred Chlanda´s WaWMap Editor) is to make standard SPWAW maps even better and to add "custom" terrain features that are not directly supported by the ingame editor![:)] Section 8 (always with regard to Fred Chlandas categorization of the data sections to be found in scenario *.dat files, NOT the mech.exe code!) contains the most interesting map data for edits and Data bytes 6 and 8 (with regard to a single map hex) is what we try to figure out!

[Mike Wood]

Hello...

Is this of any use?

#define i16_t signed short int
#define u8_t unsigned char

struct block_s
{
terType_t ter; // terrain type now 32 bits
i16_t ground; // height of the ground
i16_t hgt; // height of any obstacles
u8_t density; // density of obstacles
u8_t smoke; // smoke level in hex
u8_t shellHole; // amount of shell holes
u8_t text; // text index 0=none

u8_t dirt; // road data .. uses a bit pattern see mcgraph.c
u8_t paved; // road data
u8_t rail; // road data

unsigned dark : 1; // darken heck
unsigned trench : 1; // trench in hex
unsigned improved : 1; // improvemets in hex
unsigned hole : 1; // is there a shell hole here?
unsigned bDir : 4; // bridge facing

};

Bye...

Michael Wood

ORIGINAL: omegaall

Mike, I ahve tried to outline the situation we have been discussing below:


From what I can determine from various sources terrain is defined as a C type struct
This structure has a complete size of 20 bytes.
This is broken down as:

Terrain Type:
This is probably a signed long/extended int type value, (signed/unsigned?), (32 bits)
Consists of byte 0 – 3 describe the actual terrain type, e.g. field woods etc

Terrain Height
This is probably a signed int,(long int), type value, (signed), (16 bits)
Consists of byte 4 – 5 describe the height of the terrain hex.
This has a range of –32257? to 32767

Line of Sight terrain effects/modifier:
This is probably a signed int,(long int), type value, (signed), (16 bits)
Consists of byte 6 – 7, the value tends to be in the low byte,(byte 6).

Defence/concealment modifier:
This is probably a signed/unsigned? char type value, (8 bits)
Consists of byte 8
The actual effects are not actually clear.

The rest cover terrain effects such as:

Byte 9: Smoke Values (0-100%) 101 means fire in Hex!
Byte 10: hex damage level 0-200%, used for shell holes and rubbled buildings (graphics)
Byte 11: (Map Text container number)
Byte 12: secondary road connections
Byte 13: primary road connections
Byte 14: RR connections
Byte 15:? (not used?)
Byte 16:???? Hex fire Spread/Smoke Spread???
Byte 17:? (not used?)
Byte 18:? (not used?)
Byte 19:? (not used?)

The discussion at present is concentrated on the interaction of the “Line of Sight terrain effects/modifier”, which we have been referring to as S8 Byte 6 and the “Defence/concealment modifier” which has been referred to as S8 Byte 8.

The terms S8 and Byte 6/8 come from the use of the SPWAW Map editor by Fred Chlanda, which comes with teh game, hence the terminology confusion.

The problem we are encounting is how to interoperate the use of the values stored in this section of the Terrain description record. There are situation as map/scenario designers it is useful to modify the game defined values to improve the realism of the terrain we are working on. As a simple example high grass in the pacific arena has different characteristics that high grass in the European arena. Similarly woods are not all as dense as defined by the standard game model.

To use these areas of terrain description it we are trying to find out what the values do and the interaction between theses values.

Harry might be able to expand on this as he has more experience with map design.

Thanks

[RockinHarry]

i16_t ground; // height of the ground might relate to S8 data Byte 4 and 5.

i16_t hgt; // height of any obstacles looks like this one is related to S8 data Byte 6!

and

u8_t density; // density of obstacles looks like this relates to debated S8 data byte 8!

Now without showing any more of the code (well ...the data declaration parts) how do i16_t hgt and i16_t hgt "basically" work in the game? My theory would be that i16_t hgt adds/subtracts from a units "size" maybe and thus serves for spotting (concealment) purposes? i16_t hgt (If S8 Byte 8) then might serve to block line of sight "through" a hex? Just wondering that IE "large multihex buildings" receive value above 100 (=131).[&:]

Thanks[:)]

[omegaall]

Mike thanks for that it is a good help in seeing what is going on with teh terrain.[&o]

RockinHarry I think the the structure maps out as:

terType_t ter; // terrain type now 32 bits Bytes 0 -3
i16_t ground; // height of the ground bytes 4 - 5
i16_t hgt; // height of any obstacles byte 6 -7
u8_t density; // density of obstacles byte 8
u8_t smoke; // smoke level in hex byte 9
u8_t shellHole; // amount of shell holes byte 10
u8_t text; // text index 0=none byte 11

u8_t dirt; // road data .. uses a bit pattern see mcgraph.c byte 12
u8_t paved; // road data byte 13
u8_t rail; // road data byte 14

unsigned dark : 1; // darken heck byte 15
unsigned trench : 1; // trench in hex byte 16
unsigned improved : 1; // improvemets in hex byte 17
unsigned hole : 1; // is there a shell hole here? byte 18
unsigned bDir : 4; // bridge facing byte 19

But from what I have been testing I dont see how u8_t density works on terrain. Also i dont see how i16_t hgt works in say woods. Here the value stays at 8 for all ground levels. It seems this should also change with different heighs as defined by the base ground level. ie on level 1 (10) ground it should be 18 not 8.

Mike is this a glitch or am I reading this wrongly?

[Mike Wood]

Hello...

Oh, t'were so simple. No, height does not modify how hard it is to see a unit. It blocks line of sight. A unit in the hex is located at height of ground, but in some cases he is at the height of hgt (such as in buildings). So, an infantry unit in a tall building can see over things or be seen. There are no such thing as "large multi-hex buildings". I was asked to add them and couldn't due to data structure limitations, so I faked it. When you place a multi-hex building, I place a building in each of the hexes and assign a building graphic to the center hex.

There are about another dozen more tables concerning terrain. One indicates the concealment modifier for any given base terrain type and another for the object or objects in the hex, but we do a lot of ANDing and ORing and XORing with these table values. Plus, a lot of things are hard coded, such as if the unit is at ground or hgt level. Code was never designed for end user modification.

Hope this Helps...

Michael Wood

ORIGINAL: RockinHarry

i16_t ground; // height of the ground might relate to S8 data Byte 4 and 5.

i16_t hgt; // height of any obstacles looks like this one is related to S8 data Byte 6!

and

u8_t density; // density of obstacles looks like this relates to debated S8 data byte 8!

Now without showing any more of the code (well ...the data declaration parts) how do i16_t hgt and i16_t hgt "basically" work in the game? My theory would be that i16_t hgt adds/subtracts from a units "size" maybe and thus serves for spotting (concealment) purposes? i16_t hgt (If S8 Byte 8) then might serve to block line of sight "through" a hex? Just wondering that IE "large multihex buildings" receive value above 100 (=131).[&:]

Thanks[:)]