Generalised adjacency/ZoC effects
Moderator: Forum Moderators
Forum rules
Before posting a new idea, you must read the following:
Before posting a new idea, you must read the following:
Generalised adjacency/ZoC effects
I was contemplating a unit with an "anti-illuminates" effect, and thought that it would be quite useful to generalise the existing ZoC effects, such as illuminates and heals, and allow such effects to be describes in WML. For instance, something like this
would describe the existing "illuminates" ability, while this would give "leadership"
and so up up to the most complex existing ability
Of course, the real benefit comes not from being able to express existing abilities in WML rather than C++, but from the ease with which new abilities could be developed and explored. I've seen a few proposals for new ZoC effects; this would make adding them so much easier. For example, an advocate of a fear (anti-leadership) ability could easily write
Or to go beyond just reversing existing abilities
would give a unit a ZoC with a built-in "slow" effect
And so on through all the other attributes of a neigbouring unit that could be affected by a ZoC field effect.
Wadja think?
CJ.
Code: Select all
[zoc_effect]
id="illuminates"
name="illuminates"
[effect]
apply_to="timezone"
time="illuminated_time"
[/effect]
[/zoc_effect]
Code: Select all
[zoc_effect]
id="leadership"
name="leadership"
[filter]
side="own"
level="lower"
[effect]
apply_to="attack"
increase_damage="25%"
[/effect]
[/filter]
[/zoc_effect]
Code: Select all
[zoc_effect]
id="cures"
name="cures"
[filter]
side="own"
poisoned="false"
[effect]
apply_to="hitpoints"
increase="8"
total_increase="18"
[/effect]
[/filter]
[filter]
side="ally"
poisoned="false"
[effect]
apply_to="hitpoints"
increase="8"
[/effect]
[/filter]
[filter]
side="own,ally"
poisoned="true"
[effect]
apply_to="status"
poisoned="false"
[/effect]
[/filter]
[/zoc_effect]
Code: Select all
[zoc_effect]
id="fear"
name="fear"
[filter]
side="enemy"
level="lower"
[effect]
apply_to="attack"
increase_damage="-25%"
[/effect]
[/filter]
[/zoc_effect]
Code: Select all
[zoc_effect]
id="vortex"
name="vortex"
[filter]
side="enemy"
[effect]
apply_to="movement"
increase="-50%"
[/effect]
[effect]
apply_to="attack"
bonus_attacks="-1"
[/effect]
[/filter]
[/zoc_effect]
And so on through all the other attributes of a neigbouring unit that could be affected by a ZoC field effect.
Wadja think?
CJ.
It basically opens the door to any type of mage you could dream of. Wow.
Hope springs eternal.
Wesnoth acronym guide.
Wesnoth acronym guide.
-
- Posts: 719
- Joined: December 9th, 2003, 9:31 pm
- Contact:
I Wholeheartedly Support The Idea And/Or Endeavor.
now i just wish a coder will take a look at it. specialties being expressed in WML seems like a good idea to me.
now i just wish a coder will take a look at it. specialties being expressed in WML seems like a good idea to me.
For I am Turin Turambar - Master of Doom, by doom mastered. On permanent Wesbreak. Will not respond to private messages. Sorry!
And I hate stupid people.
The World of Orbivm
And I hate stupid people.
The World of Orbivm
On the other hand....
It's not something the game needs
Adding code means adding bugs
Put it at the top of the post-1.0 list, unless it's easy like the [allow_undo] thing
It's not something the game needs
Adding code means adding bugs
Put it at the top of the post-1.0 list, unless it's easy like the [allow_undo] thing
Hope springs eternal.
Wesnoth acronym guide.
Wesnoth acronym guide.
With any luck, this might mean *removing* code , that is, all the dedicated code for implementing each of the ZoC effects.scott wrote:On the other hand....
It's not something the game needs
Adding code means adding bugs
Put it at the top of the post-1.0 list, unless it's easy like the [allow_undo] thing
I'm studying the source now ...
It certainly doesn't look trivial, because area effects come into play at several different times (start-of-own-turn, for healing; during battle, for leadership/illumination, etc). But I haven't figured out enough of it to say just how difficult it might be ...
<aside>
when a unit is healed by an allied healer, does that occur at the start of the healed unit's turn, or the healer's?
</aside>
healed unit's turn.CyberJack wrote:when a unit is healed by an allied healer, does that occur at the start of the healed unit's turn, or the healer's?
Very. The healing code is already 300-lines long. The lighting code is spread over a lot of files, same for leadership. The AI is bad at handling the effects at the moment, it would be even worse once a non-deterministic (since user modifiable) system is implemented. In order to take care of all the issues, the patch would be well over 1500 lines imo if done correctly. I don't mean it's impossible. Not at all. But you are not the first one to propose this system, and none of your predecessors ever reached the first line of a patch.CyberJack wrote:But I haven't figured out enough of it to say just how difficult it might be ...
If you really want to take care of this project, I suggest you start tackling smaller issues to familiarize yourself with Wesnoth code. For example you could look for bugs in the healing code (is the "(unit_side > side)" condition really sane in actions.cpp:will_heal?) and reorganize it. Also take a look at the AI to see how to handle moving (since attached to units) zone of effects. Once you have clearly restricted the various Wesnoth zone of effects to a few places in the code, by a lot of small patches, it will get a lot easier to make a bigger patch go in (in fact, you would already have earned CVS access by that time).
I concur with silene.
I've actually had this kind of idea for a while now, but have been putting it off, since I think there are far more important things to do.
The main 'very hard' thing about this idea is designing a system that makes it feasible for the AI to use effectively.
And silene is completely right that a 1500 LOC patch has almost no chance of getting past the developers if it comes from someone who hasn't built up credibility with the development team (and by that time they would likely have CVS write access).
David
I've actually had this kind of idea for a while now, but have been putting it off, since I think there are far more important things to do.
The main 'very hard' thing about this idea is designing a system that makes it feasible for the AI to use effectively.
And silene is completely right that a 1500 LOC patch has almost no chance of getting past the developers if it comes from someone who hasn't built up credibility with the development team (and by that time they would likely have CVS write access).
David
“At Gambling, the deadly sin is to mistake bad play for bad luck.” -- Ian Fleming