[Documentation] Active camouflage and predator vision ;-)

[Dioxine]

Strange, it used to... At least when I was testing 0.99A.1??? Wtf?

[Yankes]

Its very unlikely with latest Meridian OXCE+ or my OXCE.

[Meridian]

Since v2016-11-05:

"activeCamouflage" is replaced by "camouflageAtDay" and "camouflageAtDark"
"predatorVision" is replaced by "antiCamouflageAtDay" and"antiCamouflageAtDark"

the AtDay and AtDark variants are applied together with "visibilityAtDay" and "visibilityAtDark" respectively

Please help with testing.

[Solarius Scorch]

Actually I found something I'm not sure if is right.

Here's a screenshot:



The enemy below has the following armour flags:

Code: [Select]

  - type: ZSRR_RED_OPS_MALE_ARMOR
    camouflageAtDay: 30
    camouflageAtDark: -2
    visibilityAtDark: 14

Which means that in darkness, he should be visible from 2 tiles less than the enemy's normal vision. (Dioxine told me so. ) But he seems to be visible at the edge of the field of vision. What am I missing?

For reference, the X-Com agent on the hill has the following armour flags:

Code: [Select]

  - type: STR_JUMPSUIT_GREEN_UC
    camouflageAtDay: 30
    camouflageAtDark: -2
    visibilityAtDark: 9

Also a save attached, for X-Com Files (Quick Battle).

[Meridian]

Camo works fine.

The visibility=9 is decreased by camo=-2 to effective visibility of 7 tiles (resp. 7*16=112 voxels).

The distance between the units though is calculated as 96 voxels... which seems wrong (not 100% sure).

I haven't made any changes in this particular part of the engine (calculating lines and distances)... so we may need help of Warboy, Yankes, Stiansel, karadoc or whoever made any changes there and/or understands what is going on there.

EDIT: the distance=96 is actually not a real mathematical distance... it is a number of voxels between the units (in discrete space)... and these voxels can be either 1 or sqrt(2) or sqrt(3) distance units apart from each other (depending if we move straight or diagonally)... the real mathematical distance check was unfortunately removed by Yankes in OXCE 3.3 because of the visibility scripts: https://github.com/Yankes/OpenXcom/commit/eaf67137a2cc4a3a8c598f40bd612d439e29839d#diff-8817a4e728e82fd5808cc76936f5488eR978

[Solarius Scorch]

Alright, thanks for the answer!

I don't think it's a problem.

[Yankes]

Camo works fine.

The visibility=9 is decreased by camo=-2 to effective visibility of 7 tiles (resp. 7*16=112 voxels).

The distance between the units though is calculated as 96 voxels... which seems wrong (not 100% sure).

I haven't made any changes in this particular part of the engine (calculating lines and distances)... so we may need help of Warboy, Yankes, Stiansel, karadoc or whoever made any changes there and/or understands what is going on there.

EDIT: the distance=96 is actually not a real mathematical distance... it is a number of voxels between the units (in discrete space)... and these voxels can be either 1 or sqrt(2) or sqrt(3) distance units apart from each other (depending if we move straight or diagonally)... the real mathematical distance check was unfortunately removed by Yankes in OXCE 3.3 because of the visibility scripts: https://github.com/Yankes/OpenXcom/commit/eaf67137a2cc4a3a8c598f40bd612d439e29839d#diff-8817a4e728e82fd5808cc76936f5488eR978

One correction, this is not discrete but https://en.wikipedia.org/wiki/Taxicab_geometry
I will think about some solution for this.

[Meridian]

One correction, this is not discrete but https://en.wikipedia.org/wiki/Taxicab_geometry
I will think about some solution for this.

Two corrections

1/ This is not taxicab geometry. Taxicab geometry has 2D diagonal distance = 2, Euklidian = sqrt(2), but our geometry here has 2D diagonal distance = 1.

The distance on Solar's example screenshot would be:
a/ Taxicab: 12 tiles (6+6)
b/ Euklidian: 8.5 tiles (sqrt(6*6+6*6))
c/ our geometry: 6 tiles (6 * 2D diagonal distance = 6 * 1)

2/ This is indeed discrete... although I wasn't referring to geometry but rather to space itself (which can be described/measured by different geometries)... 1 tile has exactly 16x16x24 voxels and there is nothing between those voxels... thus discrete space. But that's irrelevant to our discussion here anyway, point 1/ is the important one.

PS: I made a small fix/workaround... which may be also a permanent fix... depending on your vision of script's power... the scripts already cannot override the global maximum distance, so maybe they shouldn't be able to override also the "global" maximum distance at dark... but I'll leave that up to you

[Yankes]

Two corrections

1/ This is not taxicab geometry. Taxicab geometry has 2D diagonal distance = 2, Euklidian = sqrt(2), but our geometry here has 2D diagonal distance = 1.

The distance on Solar's example screenshot would be:
a/ Taxicab: 12 tiles (6+6)
b/ Euklidian: 8.5 tiles (sqrt(6*6+6*6))
c/ our geometry: 6 tiles (6 * 2D diagonal distance = 6 * 1)

2/ This is indeed discrete... although I wasn't referring to geometry but rather to space itself (which can be described/measured by different geometries)... 1 tile has exactly 16x16x24 voxels and there is nothing between those voxels... thus discrete space. But that's irrelevant to our discussion here anyway, point 1/ is the important one.

PS: I made a small fix/workaround... which may be also a permanent fix... depending on your vision of script's power... the scripts already cannot override the global maximum distance, so maybe they shouldn't be able to override also the "global" maximum distance at dark... but I'll leave that up to you

If I understand code correctly `calculateLine` with `doVoxelCheck` count steps for "forward" move and for "drift" move ("a" metric).
Tile line count only for "forward" move ("c" metric).

[Meridian]

I don't see much into that to be honest.

What I think is the core issue, is that the variable "visibleDistanceVoxels" probably doesn't contain a distance at all... it contains "a number of voxels along the line of sight" (a size of the trajectory vector)... which for me is a completely different thing.

The number of voxels could be for example 96 as we see in this example, where as the real distance is 135 or so.

But again, I might be wrong.
There is definitely a bug somewhere tho, instead of seeing in a circle around a soldier, we now see in a square.

[Yankes]

I don't see much into that to be honest.

What I think is the core issue, is that the variable "visibleDistanceVoxels" probably doesn't contain a distance at all... it contains "a number of voxels along the line of sight" (a size of the trajectory vector)... which for me is a completely different thing.

The number of voxels could be for example 96 as we see in this example, where as the real distance is 135 or so.

But again, I might be wrong.
There is definitely a bug somewhere tho, instead of seeing in a circle around a soldier, we now see in a square.

I agree there is bug that need be fixed, I only disagree on small side detail Case "a" or "c" do not change fact that it wrong and it should be something approximal to "b".

[Meridian]

Maybe instead of using the size of the trajectory vector... you could just take the first and the last voxel from that vector and calculate the distance between those two voxels the good old way?

EDIT: only for real distances of course... the smoke obstruction calculation should still use this funky method to be compatible with vanilla

EDIT2: the more I look at it, the more my workaround actually looks like a proper fix... can't help it

[Yankes]

Maybe instead of using the size of the trajectory vector... you could just take the first and the last voxel from that vector and calculate the distance between those two voxels the good old way?

EDIT: only for real distances of course... the smoke obstruction calculation should still use this funky method to be compatible with vanilla

EDIT2: the more I look at it, the more my workaround actually looks like a proper fix... can't help it

For way to fix it I think this can be fixed by reducing "weight" of "drift" voxels. This would require replacing call to `calculateLine` by `calculateLineHitHelper`.
This will expose all needed information to handle it properly. Another benefic will be drop of `_trajectory` that cause lot of useless allocations.

I will start working on it when I finish merge with nightly (3/4 done already).

[wolfreal]

Hi.

Sorry, but surely I´m extremely dumb, and I don´t think I´m understanding well all the invisibility, camouflage, and predator vision stuff (neither the thermal part), even after reading the thread.

First, some clarification (Better say, please correct me if this is totally wrong.)

Invisibility is positive values in camoAtX (Where X is day or night)
Camouflage is  negative values in camoAtX
antiCamouflageAtDay is the ability to negate camouflage (But not invisibility?)

Let´s have some examples to see if I´m getting this well. (I´m excluding the night-day stuff.)

A.

I have a soldier with the next armor.
vision: 15

And an enemy with this armor.
vision: 20
camo: -3

Then. My soldier could see the enemy in 15-3 = 12 titles. The enemy can see me in 20 titles.

B.
Soldier.
Vision: 12
Camo: -8

Enemy:
Vision: 20
camo: -3

Soldier see enemy in 12-3 = 9 titles
Enemy see soldier in 20 - 8 = 12 titles.

If vision - camo <= 1 them seeStuff is =1

Them, the biggest the negative number (Camo), the better.

C.
Soldier
Vision 20
camo = +8

Enemy:
Vision: 20
camo = +5

Them
Soldier can see enemy at 5 titles
Enemy can see soldier at 8 titles.

D.
Soldier
Vision 20
camo = +8
antiCamo = 20

Enemy:
Vision: 20
camo = +5
antiCamo = 10

Them
Soldier can see enemy at 5 titles
Enemy can see soldier at 8 titles.

The result is the same as the other option? In this case, A lower number is a better one?

Please correct my wrong understanding.

On another relationated aspect. How do you determine visibility in smoke?. How the heatVision works? I´m asking too much question in the incorrect thread?.

Thanks!

[legionof1]

Invisibility is a fixed distance at which you will seen. Ghost armor as an example is seen at 5 tiles.

Camo reduces the distance at which a unit is seen by subtracting from vision range of enemy. Predator vision counters camo by reducing the camo value by a given amount. Example: Vision - (Camo - Predator)=Final spotting range. Camo cannot be reduced below 0 by predator vision.

Thermal ignores a stated % of smoke thereby reducing smokes impact on vision. Each tile of smoke a unit tries to spot through is stacking penalty to vision range. IF i recall correctly 4 tiles of smoke negates normal vision completely. The more thermal a unit has the more thickness of smoke is needed to reduce vision to zero. Note that smoke only starts subtracting from vision within or past the smoke. 
Example: A unit with 40 vision is 15 tiles from the edge of a cloud. The first tile costs 5 extra for an effective distance of 21. The next tile is another 5 for an effective 27. 3rd tile 33. 4th 39. 5th tile 45.
Now i don't actually know what the penalty is i just used 5 for illustration. There is also multiple densities of smoke with different penalties. The 4 tiles i mentioned above for blocking vision is for "full" smoke.

I may be wrong about some of this as i learned some of it a very long time ago.