Vision changes in 1.11

[SlowThinker]

I think this feature deserves its own thread:

Please note, that I just commited support for a vision= attribute in [unit] and [unit_type]
which can be used to make the vision sight independent from the movement of a unit.

It can for example be used to define a radar unit with low or even no movement but a huge sight range.

Together with it there is support for [vision_costs] in [movement_type], allowing different view than movement costs.
It can be used for example to define a unit which can see over deep water even if it is not possible to move the unit there.

____________________________________________________________

I speculated about applying not a radar, but a reverse mechanism in an add-on: units that have shorter vision than move. It would imply some interesting strategic aspects:

• even the fastest unit would take a risk when advancing in unknown lands, and players would face decision
• fighting for information: Players would have to fight through enemy units in order to find out whether a specific hex/unit is safe. (Admittedly the effect would not be very bold in a standard Wesnoth game, where a kill is almost always advantageous. Also the only situation where a unit is extremely important in a standard game is a wounded leader.)

The problem is without a TBS-fog (see this thread) a player would extremely hardly record which hexes were revealed and which ones were not.

On a side note, the current code base of modern combat involves the usage of the [teleport] tag which is no longer working the way it had before 1.10.

What happened to [teleport]?

[fabi]

I speculated about applying not a radar, but a reverse mechanism in an add-on: units that have shorter vision than move. It would imply some interesting strategic aspects:

• even the fastest unit would take a risk when advancing in unknown lands, and players would face decision
• fighting for information: Players would have to fight through enemy units in order to find out whether a specific hex/unit is safe. (Admittedly the effect would not be very bold in a standard Wesnoth game, where a kill is almost always advantageous. Also the only situation where a unit is extremely important in a standard game is a wounded leader.)

Good idea, I am working on exactly the same thing

The problem is without a TBS-fog (see this thread) a player would extremely hardly record which hexes were revealed and which ones were not.

This has been fixed in trunk, to a certain degree. While you do still not see "old" units in regions which are not uncovered anymore, the fog gets now restored after your
turn finished and not at the time you move the unit away.

What happened to [teleport]?

[teleport] used to be hardcoded to the only use case "Silver Mage".
The new implementation can be used to define different mechanics.
Just have a look in the wml reference wiki.

[Mabuse]

hello,
this is really a good idea.
in any way, alone for this feature im looking forward to trunk

I speculated about applying not a radar, but a reverse mechanism in an add-on: units that have shorter vision than move. It would imply some interesting strategic aspects:

even the fastest unit would take a risk when advancing in unknown lands, and players would face decision
fighting for information: Players would have to fight through enemy units in order to find out whether a specific hex/unit is safe. (Admittedly the effect would not be very bold in a standard Wesnoth game, where a kill is almost always advantageous. Also the only situation where a unit is extremely important in a standard game is a wounded leader.)

well, of course with the new vision, you can do a lot of things

1)
you can have terrain that blocks vision to a certain degree (like forest, mountains, hills), other terrains like unwalkable terrain can be overlooked now -

2)
and that dependent of the unit type (fliers would have a overall good vision) ect.
some units could have a better vision than others

3)
last but not least, now cliffs can be incorporated and put into the terrain list

4)
and since vision can be edited via effects, you could also implement a WML solution that enhances vsion if standing on certain hexes like mountains, hills,

[fabi]

Added the description of [vision_costs] to the wml reference wiki.
I would also like to add a description for vision=, but I can't find one for movement= and I wanted to group them together.

[SlowThinker]

I think max_moves, max_experience and max_hitpoints are missing in these pages:
http://wiki.wesnoth.org/SingleUnitWML
http://wiki.wesnoth.org/UnitTypeWML

You may want to edit movetypes too:
http://wiki.wesnoth.org/UnitsWML

[Crendgrim]

Why don't you do that yourself, SlowThinker (assuming that what you said is right)? The wiki is to be edited by anyone, that's why it's a wiki and not a plain documentation.

[Jabie]

I've often felt there is a need for a recon unit in shroud Wesnoth scenarios. This would improve hide-and-sneak sceanrios considerably. Falcons and Griffons are obvious candidates for high vision, due to the aerial capabilities.

[SlowThinker]

Why don't you do that yourself, SlowThinker (assuming that what you said is right)? The wiki is to be edited by anyone, that's why it's a wiki and not a plain documentation.

I didn't want to suggest fabi he should correct max_moves= by himself, I just explained why he wasn't able to find the description.

Why I don't correct it myself? Please read end of this post: Cooperation in Wesnoth development (?)

[fabi]

This is an additional feature to vision, thus I don't open another thread.

Jamming

A unit can feature some jamming ability, the attribute jamming= is similar to vision.
If no additional [jamming_costs] section is added, all terrain is unreachable, thus the unit will only jam its own location.
Say the jammer has jamming=5 but no costs given.
A fog clearer with vision=10 (or movement if you like) on a terrain area where he has costs of one,
will need to get as close as 5 hex fields to reveal the jammer's location.

Now let's have the jammer a costs of one at the terrain area in question.
Now it will produce one additional costs for the viewer at a ring with radius 4,
2 at a ring with radius 3, 3@2, 4@1, and still 5 at the jammers own location.

Note that 5 might be an extreme high value.

[alexanderthegre]

This is an additional feature to vision, thus I don't open another thread.

Jamming

A unit can feature some jamming ability, the attribute jamming= is similar to vision.
If no additional [jamming_costs] section is added, all terrain is unreachable, thus the unit will only jam its own location.
Say the jammer has jamming=5 but no costs given.
A fog clearer with vision=10 (or movement if you like) on a terrain area where he has costs of one,
will need to get as close as 5 hex fields to reveal the jammer's location.

Now let's have the jammer a costs of one at the terrain area in question.
Now it will produce one additional costs for the viewer at a ring with radius 4,
2 at a ring with radius 3, 3@2, 4@1, and still 5 at the jammers own location.

Note that 5 might be an extreme high value.

Okay, that's just cool. I can't wait for 1.11.

[SlowThinker]

Did I understand jamming well? I will try to rephrase:

First the effect of vision=:

Any fog-clearing unit sends mini-explorers in all directions, their movement depends on [vision_costs]; all hexes they can reach become visible.

Now the effect of jamming:

The jamming unit sends mini-jammers in all directions, they occupy all reachable hexes. The reachability depends on [jamming_costs]. Every mini-jammer occupies his hex with a jamming power = remaining jamming movepoints.
The jamming power on every individual hex increases vision_cost for enemy mini-explorers.

Question: what happens if two jammers cooperate? The total jamming power is equal to maximum of individual jamming powers?

[fabi]

Question: what happens if two jammers cooperate? The total jamming power is equal to maximum of individual jamming powers?

You explained that very well, except that "vision_costs=" should be "[vision_costs]".
Since the powers of the explorers do not stack (at least not without extra work) I also thought that stacking of jamming powers would be unbalanced.
Only the highest value of all jamming is used to increase the vision_cost for the field.

Stacking of powers can be discussed but I think that must be done for both competing forces then.

[SlowThinker]

Now I don't see a good reason for stacking of powers.

Will the jammed hexes be covered by fog (and so the presence of jamming unit will be revealed) or not?

Did you add support for new vision features to player's interface?
I mean some analogy to this functionality:
if a player hovers his mouse over a foreign unit, a radius of max_moves is highlighted (decreased by ZOCs).
if a player clicks on a unit, a radius of remaining moves (decreased by ZOCs) is highlighted

[The_Other]

Will the jammed hexes be covered by fog (and so the presence of jamming unit will be revealed) or not?

Would it be possible for this to be specified as an option within the ability?
I can think of cases where either would be desirable, and it would be nice to have the flexibility.

[fabi]

Now I don't see a good reason for stacking of powers.

Yes, the calculation that comes with stacking might be very much unmanageable for the player.
Thus alone for keeping it simple the stacking can be avoided.

Will the jammed hexes be covered by fog (and so the presence of jamming unit will be revealed) or not?

Would it be possible for this to be specified as an option within the ability?
I can think of cases where either would be desirable, and it would be nice to have the flexibility.

They stay covered by fog, thus you can guess were the enemy is using a jamming unit.
Remember, jamming can only work if fog is enabled, it's not able to produce fog in scenarios (or better for sides) where fog is disabled.

I can see why the difference is important, let me present some use cases:

The first one is a jamming vehicle, fragile, medium velocity, low vision but with a reasonable jamming value.
It can be used to disguise units from the enemy but the huge amount of radiation involved in the jamming process means that the enemy is aware that
there is something going on and he can roughly guess the position of the vehicle as well.
One of many different use cases might be to disguise the long ranged heavy artillery behind the lines, making it untouchable by the enemies' long range weapons.
The fantasy setting equivalent is a dark mage producing some artificial darkness with the help of black magic. (The feature might only work at night?)
The unusual darkness is a hint to his position like in the modern example.

The second use case is a stealth fighter (fighter == airplaine, in this context).
It's not using radiation to disguise in the artificial noise but has a low profile and thus does not reflect enough signal to get recognized among the background noise.
It won't jam a hex field or area but just be invisible until strong enough vision breaks the stealth.

The third use case is even more futuristic, it's a building producing a stealth field, that reflects the radiation used by the viewer as if there was nothing there but the empty terrain.
It's able to give the stealth to all units inside the field making them invisible while keeping the viewer in the illusion of lifted fog.

The 4th use case combines both features. It's using active disguise by emitting radiation while having the form and material that makes it a stealth unit.

Regarding a switch between lifting the fog or not, this needs some extra work.
It means two passfinding passes, one for lifting fog/shroud on the hexes and one for marking units on revealed hex fields invisible.
I still need to investigate if this is doable without heavy changes to the engine and most use cases might be doable with [hides].

Did you add support for new vision features to player's interface?

The unit help page already shows the values for vision= and jamming= if they are given.
Displaying the vision_costs and jamming_costs in the costs table is nearly ready to commit and will follow soon.

I mean some analogy to this functionality:
if a player hovers his mouse over a foreign unit, a radius of max_moves is highlighted (decreased by ZOCs).
if a player clicks on a unit, a radius of remaining moves (decreased by ZOCs) is highlighted

No, there is no equivalent feature right now.

My guts told me that implementing a "Show Enemy Vision" equivalent to "Show Enemy Move" would be enough.
Vision is caused by units but the result is not bound to a single one thus it might not be necessary.