Section 8 questions - WaWMapEd

[Mike Wood]

Hello...

Have it set up, so that if base terrain is 10, then that is the height. If there are trees in the hex, it does not add to the height of the hex base terrain. The program looks at the 'ground' and adds 'hgt' to it (in your example 10+8), when determining line of sight (LOS). In the game the base terrain height is what the mouse over indicates, as it ignores trees (it assumes troops are not up in tree tops).

Density works with visibility. If you have a visibility of 90 hexes, then you can see through several tree hexes, and if visibility is 10, then one tree hex blocks LOS. Density and visibility determine how much undergrowth, leaves in trees, low hanging branches, fullness of crop or field hexes, and so forth. Trees have a lower density than buildings, for instance.

Hard to explain, but I spent a number of months adding code to an already obscure system that was nearly 10 years old, when I got it and relied a lot on a library for which I never had the code. Somewhat complicated.

Bye...

Michael Wood

ORIGINAL: 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?

[omegaall]

I thought that there would be a level of ANDing/OR and XOring in teh final determinations.

Without going into teh code is that ANDing etc done with the initial settings as per teh tables. As an example a wooded hex has a i16_t ground of 0, (ZERO), and it has an i16_t hgt set to 8 with a u8_t density set to 30. These values for i16_t hgt and u8_t density are they directly taken from the various terrain tables you mentioned or the result of teh ANDing etc of some value.

My problem is I am putting together a map where I have light scrub but it has a high concealment level but small height about 3 - 4 ft high. I have tried various combinations of the i16_t hgt and u8_t density settings to get teh correct effect but I am not going far. If I set the i16_t hgt value to about 2, using base level of ZERO, and a u8_t density setting even around 30 I have little or no difference to a u8_t density of 100. The viewing unit, placed outside teh vegetation, can see straigh through the vegetation. The sight range should not go beyond 1 hex, (50 m) in real life. If you are actually in the vegetation you can see out quite well. This is a desert setting. I have tested the real setting as it just out of town so this little problem has been giving me hell trying to get it right.

Would the various values from the terrain tables assist in setting the various values in the terrain struct?

Thanks again for this help

ORIGINAL: 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 that height. 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. Once 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. Code was never designed for end user modification.

Hope this Helps...

Michael Wood

[Mike Wood]

Hello...

The game was designed to allow terrain placement in the in game editor. Are you using that or something else?

Thanks...

Michael Wood

ORIGINAL: omegaall

I thought that there would be a level of ANDing/OR and XOring in teh final determinations.

Without going into teh code is that ANDing etc done with the initial settings as per teh tables. As an example a wooded hex has a i16_t ground of 0, (ZERO), and it has an i16_t hgt set to 8 with a u8_t density set to 30. These values for i16_t hgt and u8_t density are they directly taken from the various terrain tables you mentioned or the result of teh ANDing etc of some value.

My problem is I am putting together a map where I have light scrub but it has a high concealment level but small height about 3 - 4 ft high. I have tried various combinations of the i16_t hgt and u8_t density settings to get teh correct effect but I am not going far. If I set the i16_t hgt value to about 2, using base level of ZERO, and a u8_t density setting even around 30 I have little or no difference to a u8_t density of 100. The viewing unit, placed outside teh vegetation, can see straigh through the vegetation. The sight range should not go beyond 1 hex, (50 m) in real life. If you are actually in the vegetation you can see out quite well. This is a desert setting. I have tested the real setting as it just out of town so this little problem has been giving me hell trying to get it right.

Would the various values from the terrain tables assist in setting the various values in the terrain struct?

Thanks again for this help

ORIGINAL: 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 that height. 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. Once 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. Code was never designed for end user modification.

Hope this Helps...

Michael Wood

[omegaall]

Thanks,

I suspected that the code would not have lots of needed documentation. Seen that too often.

I am slowly getting the picture of how it sort of goes together.

So, in a simplied form, its a complete combination of visibility as defined by the scenario setting, and this is ANDed/ORed/XORed with the values from i16_t hgt and u8_t density in some "little uncomplicated" equation..

ORIGINAL: Mike Wood

Hello...

Have it set up, so that if base terrain is 10, then that is the height. If there are trees in the hex, it does not add to the height of the hex base terrain. The program looks at the 'ground' and adds 'hgt' to it (in your example 10+8), when determining line of sight (LOS). In the game the base terrain height is what the mouse over indicates, as it ignores trees (it assumes troops are not up in tree tops).

Density works with visibility. If you have a visibility of 90 hexes, then you can see through several tree hexes, and if visibility is 10, then one tree hex blocks LOS. Density and visibility determine how much undergrowth, leaves in trees, low hanging branches, fullness of crop or field hexes, and so forth. Trees have a lower density than buildings, for instance.

Hard to explain, but I spent a number of months adding code to an already obscure system that was nearly 10 years old, when I got it and relied a lot on a library for which I never had the code. Somewhat complicated.

Bye...

Michael Wood

[

[omegaall]

I am desiging the base terrain using the Game editor. That is building hills, dry creeks etc. Final toutches such as gentle slopes I am using Fred Chlanda'sMap Editor that comes with the game as an 'add on'. Also I am using this to set the values for i16_t hgt and u8_t density settings on special vegetation settings. This is after I have used the game Editor to build everything.

ORIGINAL: Mike Wood

Hello...

The game was designed to allow terrain placement in the in game editor. Are you using that or something else?

Thanks...

Michael Wood

ORIGINAL: omegaall

I thought that there would be a level of ANDing/OR and XOring in teh final determinations.

Without going into teh code is that ANDing etc done with the initial settings as per teh tables. As an example a wooded hex has a i16_t ground of 0, (ZERO), and it has an i16_t hgt set to 8 with a u8_t density set to 30. These values for i16_t hgt and u8_t density are they directly taken from the various terrain tables you mentioned or the result of teh ANDing etc of some value.

My problem is I am putting together a map where I have light scrub but it has a high concealment level but small height about 3 - 4 ft high. I have tried various combinations of the i16_t hgt and u8_t density settings to get teh correct effect but I am not going far. If I set the i16_t hgt value to about 2, using base level of ZERO, and a u8_t density setting even around 30 I have little or no difference to a u8_t density of 100. The viewing unit, placed outside teh vegetation, can see straigh through the vegetation. The sight range should not go beyond 1 hex, (50 m) in real life. If you are actually in the vegetation you can see out quite well. This is a desert setting. I have tested the real setting as it just out of town so this little problem has been giving me hell trying to get it right.

Would the various values from the terrain tables assist in setting the various values in the terrain struct?

Thanks again for this help

ORIGINAL: 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 that height. 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. Once 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. Code was never designed for end user modification.

Hope this Helps...

Michael Wood

[omegaall]

Mike, soory But I have to go as its hit the 2:am point.

[RockinHarry]

ORIGINAL: Mike Wood

Hello...

Have it set up, so that if base terrain is 10, then that is the height. If there are trees in the hex, it does not add to the height of the hex base terrain. The program looks at the 'ground' and adds 'hgt' to it (in your example 10+8), when determining line of sight (LOS). In the game the base terrain height is what the mouse over indicates, as it ignores trees (it assumes troops are not up in tree tops).

Density works with visibility. If you have a visibility of 90 hexes, then you can see through several tree hexes, and if visibility is 10, then one tree hex blocks LOS. Density and visibility determine how much undergrowth, leaves in trees, low hanging branches, fullness of crop or field hexes, and so forth. Trees have a lower density than buildings, for instance.

Hard to explain, but I spent a number of months adding code to an already obscure system that was nearly 10 years old, when I got it and relied a lot on a library for which I never had the code. Somewhat complicated.

Bye...

Michael Wood

ORIGINAL: 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?

Thank you very much Mike! [:)] That actually answers my initial questions without having to look at pieces of the code! There´s a couple of abstractions, but this is what I was working and editing with Freds editors anyway and it´s the final effects that count. So far I have it all working in a satisfactorily manner.[:)]

[RockinHarry]

ORIGINAL: Mike Wood

Hello...

The game was designed to allow terrain placement in the in game editor. Are you using that or something else?

Thanks...

Michael Wood

The game is shipped with a particular terrain editor made by Fred chlanda. It has a unique interface and it lets you edit data that is directly stored in the scenario or map (*.dat) files. It´s just the variables stored from within the game editor, not code to compute these variables. I don´t know how data structures are organized from within the game, but Fred Chlanda figured out the scenario files are subdivided in the many sections and Section 8 was the one we are discussing now. This section contains the particular data of each hex of a given map or scenario loaded into the editor.

[RockinHarry]

Mike, I also would like to point you to a bug related to "high Grass" terrain. This "terrain" type obviously is one of those not to be set directly by the "enum terType_e " types and is rather set by "i16_t ground" =1, "i16_t hgt" =1 or 2 (for jungle grass) and "u8_t density" =10. Now if you place "high grass" on standard hills (levels) with the ingame editor, it happens that the value of "i16_t ground" obviously is added to "u8_t density" which makes high grass placed on hills more impenetrable with each higher level. Example: Level 0 grass is "u8_t density" =10, Level 10 hill "u8_t density" =20 and Level 30 hill "u8_t density" =30! Normally original value of "u8_t density" should be preserved for all subsequent (higher) levels.

There´s yet another glitch caused by the ingame editor when the "trail" (TER_TRAIL =(TER_WALL*2)) terrain type is placed on the map. On rare occasions the "trail" terrain type secretely converts to "TER_RIVER =8, // stream". I suspect a certain terrain combination to be responsible for the unwanted conversion, but can´t tell which in particular cause the "conversion" mostly is to be recognized long after editing when the map is to be play tested.[X(]

There´s yet another handful of glitches, if you want to know....

[RockinHarry]

ORIGINAL: omegaall

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.

Did not include in my Editor notes (in the game manual and file below), "high grass" placed with "Jungle" tile set active has S8 Byte 6 set to "2" automatically! Clear indication that "Jungle high grass" is supposed to give better hiding capability than the standard type with "Summer" tile set. "Sand dunes" (= high grass in "Desert" tile set) can be customized with a higher setting for S6 as well.

Camo Groups SP2WW2 includes routines that make the terrain density of terrain like "High Grass" or "Wheat fields" more variable by adding a random factor to what would be the equivalent to SPWAW S8 Byte 6/7 (and 8?). You could achieve the same effect by setting Byte6 in Freds Editor. I sometime do this in my maps, although micro editing of hexes assumed to be 50x50m in size ain´t always realistic either. [:o]

[RockinHarry]

Mike, maybe a quick fix: What about lowering the chance for certain terrain types to be set on fire by HE? There´s an unrealistic high chance for trees/woods to become burning hells even in "Hazy" or worse weather (setting 3-6)! "set afire" chance for buildings is ok since it´s mostly the interior of buildings that starts to burn, independent from outside weather conditions.[X(]

I know weather is set by a combination of weather setting AND max viewing range, but I think "set afire" chance should be set by weather setting alone cause it´s in most parts the ground condition (dampness of ground, foliage) instead of current precipitations. Also "smoke" effects should be lowered considerably in "bad" weather!

As it´s now, artillery bombardement into forest hexes IMHO is almost equal to flame thrower effects.[:(]

OTOH "dust" (=smoke) should also be created on summer tile set maps (currently desert only) when weather is dry and in summer months. This would be a nice effect for those russia steppe maps, but maybe less for western europe summer conditions.

Related question: Is it a weapons "Warhead" and "HE kill" values used for computing hex/terrain "set afire" chance?

ok..before this goes overboard....[:D]

Thanks for your time![8D]

[omegaall]

The tree problem at last is makinging sence.

Thanks Mike re the comment visability and density. At last after some tests I managed to get what I need. I had been doing test with visibility setting not appliciable with the actual map I was working on so it was not making sence.

Mike if you could explain something that I don't follow properly.
With a wodden building the following are teh game set values tground is set to 5 and thgt to 15.
This seems to sets the actual height of the building to 10. But from this it appears that a unit in the building is actually at height 5, ie below roof height.

Am I correct on this assumption?

Also would it be correct to say that to put a unit on the roof the tground value would have to be set to 15?

[quote]
Camo Groups SP2WW2 includes routines that make the terrain density of terrain like "High Grass" or "Wheat fields" more variable by adding a random factor to what would be the equivalent to SPWAW S8 Byte 6/7 (and 8?). You could achieve the same effect by setting Byte6 in Freds Editor. I sometime do this in my maps, although micro editing of hexes assumed to be 50x50m in size ain´t always realistic either
[\quote]

In the attached pic of a bit of my map I am going to micro change the density from thin on edges to dense towards the middle. I have spent hours walking this ground and testing various things. Well when its safe to slip over the Army Range fence, "all 3 single strands of wire" [:D]

As you can see 3 main vegetation types, heavy trees 2- 3 m dense, light trees max 2m dense from 0.5 m off ground and very low scrub, 0.3 m.

Still have to fix up the graphics a bit the blue scrub is too hex shaped.

[Mike Wood]

Hello...

Huh? I just went into the game and made a 10 hill and placed a building on it. The mouse over said the building was 15 height. That is what happens when you put a 5 height building on a 10 height hill, 5+10=15.

I then put a building on height 0 grass and it reported the building to be height 5, 5+0=5.

Units in a building hex are automatically put on the roof.

Not sure what you are asking...

Michael Wood

ORIGINAL: omegaall

The tree problem at last is makinging sence.

Thanks Mike re the comment visability and density. At last after some tests I managed to get what I need. I had been doing test with visibility setting not appliciable with the actual map I was working on so it was not making sence.

Mike if you could explain something that I don't follow properly.
With a wodden building the following are teh game set values tground is set to 5 and thgt to 15.
This seems to sets the actual height of the building to 10. But from this it appears that a unit in the building is actually at height 5, ie below roof height.

Am I correct on this assumption?

Also would it be correct to say that to put a unit on the roof the tground value would have to be set to 15?

[omegaall]

ORIGINAL: Mike Wood

Hello...

Huh? I just went into the game and made a 10 hill and placed a building on it. The mouse over said the building was 15 height. That is what happens when you put a 5 height building on a 10 height hill, 5+10=15.

I then put a building on height 0 grass and it reported the building to be height 5, 5+0=5.

Units in a building hex are automatically put on the roof.

Not sure what you are asking...

Michael Wood

Hi Mike, I think I have resolved this.. Problem: Too many late nights and very early mornings. Bad combination..

[Captain Cruft]

The map format, and indeed entire "scenario.dat" format are considered to be proprietary because if you can write these files then you can theoretically build your own "Mega Campaign" type of thing (or other enhanced product) and thereby compete with Matrix.

At least that's my take on it. On the other hand, it just could be that Mike didn't have the time to look at the code. He is very busy maintaining a gazillion different titles all on his own ...

[RockinHarry]

ORIGINAL: Captain Cruft

The map format, and indeed entire "scenario.dat" format are considered to be proprietary because if you can write these files then you can theoretically build your own "Mega Campaign" type of thing (or other enhanced product) and thereby compete with Matrix.

At least that's my take on it. On the other hand, it just could be that Mike didn't have the time to look at the code. He is very busy maintaining a gazillion different titles all on his own ...

Actually no. The Megacampaign is created by its own software not available to the public. Some of the Utility software people (Fred Chland, Ectizen, ect.) know of the format quite well and these are not employees of MG.