Vision changes in 1.11
Moderator: Forum Moderators
-
- Posts: 876
- Joined: November 28th, 2008, 6:18 pm
Vision changes in 1.11
I think this feature deserves its own thread:
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:
____________________________________________________________[url=http://forums.wesnoth.org/viewtopic.php?p=527336#p527336]here[/url] fabi wrote: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.)
What happened to [teleport]?fabi wrote: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.
Last edited by SlowThinker on May 7th, 2012, 8:52 pm, edited 1 time in total.
I work on Conquest Minus • I use DFoolWide, Retro Terrain Package and the add-on 'High Contrast Water'
I moved to Nosebane's corner (Doc Paterson's signature); I am spending my time there, so PM me if I don't answer your post in forums
I moved to Nosebane's corner (Doc Paterson's signature); I am spending my time there, so PM me if I don't answer your post in forums
Re: Vision changes in 1.11 (vision= vision_costs=)
Good idea, I am working on exactly the same thingI 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.)
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 yourThe problem is without a TBS-fog (see this thread) a player would extremely hardly record which hexes were revealed and which ones were not.
turn finished and not at the time you move the unit away.
[teleport] used to be hardcoded to the only use case "Silver Mage".What happened to [teleport]?
The new implementation can be used to define different mechanics.
Just have a look in the wml reference wiki.
Re: Vision changes in 1.11 (vision= vision_costs=)
hello,
this is really a good idea.
in any way, alone for this feature im looking forward to trunk
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,
this is really a good idea.
in any way, alone for this feature im looking forward to trunk
well, of course with the new vision, you can do a lot of thingsI 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.)
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,
The best bet is your own, good Taste.
Re: Vision changes in 1.11 (vision= vision_costs=)
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.
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.
-
- Posts: 876
- Joined: November 28th, 2008, 6:18 pm
Re: Vision changes in 1.11 (vision= vision_costs=)
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
http://wiki.wesnoth.org/SingleUnitWML
http://wiki.wesnoth.org/UnitTypeWML
You may want to edit movetypes too:
http://wiki.wesnoth.org/UnitsWML
I work on Conquest Minus • I use DFoolWide, Retro Terrain Package and the add-on 'High Contrast Water'
I moved to Nosebane's corner (Doc Paterson's signature); I am spending my time there, so PM me if I don't answer your post in forums
I moved to Nosebane's corner (Doc Paterson's signature); I am spending my time there, so PM me if I don't answer your post in forums
Re: Vision changes in 1.11 (vision= vision_costs=)
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.
UMC Story Images — Story images for your campaign!
Re: Vision changes in 1.11 (vision= vision_costs=)
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.
-
- Posts: 876
- Joined: November 28th, 2008, 6:18 pm
Re: Vision changes in 1.11 (vision= vision_costs=)
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.Crendgrim wrote: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.
Why I don't correct it myself? Please read end of this post: Cooperation in Wesnoth development (?)
I work on Conquest Minus • I use DFoolWide, Retro Terrain Package and the add-on 'High Contrast Water'
I moved to Nosebane's corner (Doc Paterson's signature); I am spending my time there, so PM me if I don't answer your post in forums
I moved to Nosebane's corner (Doc Paterson's signature); I am spending my time there, so PM me if I don't answer your post in forums
Re: Vision changes in 1.11 (vision= vision_costs=)
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.
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
- Posts: 193
- Joined: December 8th, 2011, 3:23 am
- Location: nowhere
Re: Vision changes in 1.11 (vision= vision_costs=)
Okay, that's just cool. I can't wait for 1.11.fabi wrote: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.
-
- Posts: 876
- Joined: November 28th, 2008, 6:18 pm
Re: Vision changes in 1.11 (vision= vision_costs=)
Did I understand jamming well? I will try to rephrase:
First the effect of vision=:
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?The jamming power on every individual hex increases vision_cost for enemy mini-explorers.
Last edited by SlowThinker on May 7th, 2012, 5:32 pm, edited 1 time in total.
I work on Conquest Minus • I use DFoolWide, Retro Terrain Package and the add-on 'High Contrast Water'
I moved to Nosebane's corner (Doc Paterson's signature); I am spending my time there, so PM me if I don't answer your post in forums
I moved to Nosebane's corner (Doc Paterson's signature); I am spending my time there, so PM me if I don't answer your post in forums
Re: Vision changes in 1.11 (vision= vision_costs=)
You explained that very well, except that "vision_costs=" should be "[vision_costs]".SlowThinker wrote:Question: what happens if two jammers cooperate? The total jamming power is equal to maximum of individual jamming powers?
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.
-
- Posts: 876
- Joined: November 28th, 2008, 6:18 pm
Re: Vision changes in 1.11 (vision= vision_costs=)
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
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
I work on Conquest Minus • I use DFoolWide, Retro Terrain Package and the add-on 'High Contrast Water'
I moved to Nosebane's corner (Doc Paterson's signature); I am spending my time there, so PM me if I don't answer your post in forums
I moved to Nosebane's corner (Doc Paterson's signature); I am spending my time there, so PM me if I don't answer your post in forums
Re: Vision changes in 1.11
Would it be possible for this to be specified as an option within the ability?SlowThinker wrote:Will the jammed hexes be covered by fog (and so the presence of jamming unit will be revealed) or not?
I can think of cases where either would be desirable, and it would be nice to have the flexibility.
Nothing is true; everything is permissible.
Re: Vision changes in 1.11
Yes, the calculation that comes with stacking might be very much unmanageable for the player.SlowThinker wrote:Now I don't see a good reason for stacking of powers.
Thus alone for keeping it simple the stacking can be avoided.
They stay covered by fog, thus you can guess were the enemy is using a jamming unit.The_Other wrote:Would it be possible for this to be specified as an option within the ability?SlowThinker wrote:Will the jammed hexes be covered by fog (and so the presence of jamming unit will be revealed) or not?
I can think of cases where either would be desirable, and it would be nice to have the flexibility.
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].
The unit help page already shows the values for vision= and jamming= if they are given.SlowThinker wrote:Did you add support for new vision features to player's interface?
Displaying the vision_costs and jamming_costs in the costs table is nearly ready to commit and will follow soon.
No, there is no equivalent feature right now.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
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.