Problems with the new ability system in svn trunk
Moderator: Forum Moderators
- Elvish_Pillager
- Posts: 8137
- Joined: May 28th, 2004, 10:21 am
- Location: Everywhere you think, nowhere you can possibly imagine.
- Contact:
Problems with the new ability system in svn trunk
- The description of "Regenerates" is spelled incorrectly in abilities.cfg.
- If the healing amount given by a village is less than that given by regeneration, the unit will gain the lower amount. (this probably goes for Heals and Cures as well.)
- Poison curing happens only when the healing amount is >= cure_amount, rather than being a setting
- In general, the code seems not to be switched over to the new heal/cure/regen system.
- All abilites seem to be able to be filtered, but not all of them are affected if you put on a filter.
It's all fun and games until someone loses a lawsuit. Oh, and by the way, sending me private messages won't work. :/ If you must contact me, there's an e-mail address listed on the website in my profile.
Re: Problems with the new ability system in svn trunk
Well abilities are still a work in progress...
It is true that filters don't work for every ability, some aren't used yet.
IIRC, it currently works with hides (ie ambush/nightstalk), steadfast, illuminates.
Thank you for pointing problems with heals/regenerate, we shall improve it.
It is true that filters don't work for every ability, some aren't used yet.
IIRC, it currently works with hides (ie ambush/nightstalk), steadfast, illuminates.
Thank you for pointing problems with heals/regenerate, we shall improve it.
- Elvish_Pillager
- Posts: 8137
- Joined: May 28th, 2004, 10:21 am
- Location: Everywhere you think, nowhere you can possibly imagine.
- Contact:
What about it, you ask? The thing which is about it is that it has been proposed in the past, and rejected thoroughly. Do your research.
It's all fun and games until someone loses a lawsuit. Oh, and by the way, sending me private messages won't work. :/ If you must contact me, there's an e-mail address listed on the website in my profile.
- Elvish_Pillager
- Posts: 8137
- Joined: May 28th, 2004, 10:21 am
- Location: Everywhere you think, nowhere you can possibly imagine.
- Contact:
Well i haven't looked exactly how it works, but :
* i don't know if having level >1 changes something to the lawful bonuses
* if it is positive it is a normal 'illuminate'
* if it is negative, it should be a 'desilluminate'
* if an hex is 'illuminated' by two units, one with a positive level, one with a negative level :
- there is no change of the time of day if they have the same absolute levels
- otherwise the 'lilluminates' ability with the biggest absolute level wins
I presume that level should be usually 1 or -1
* i don't know if having level >1 changes something to the lawful bonuses
* if it is positive it is a normal 'illuminate'
* if it is negative, it should be a 'desilluminate'
* if an hex is 'illuminated' by two units, one with a positive level, one with a negative level :
- there is no change of the time of day if they have the same absolute levels
- otherwise the 'lilluminates' ability with the biggest absolute level wins
I presume that level should be usually 1 or -1
The game makes a rank-ordered list of all unique lawful bonuses created by your [time] tags.
Then, it just moves you up and down the ladder based on the level of illuminates.
There is a limitation for scenarios with very fine gradations of lawful bonus, for example if you had 24 time-of-day settings with a 5% bonus increment. You might want the Mage of Light illuminates ability to give you the normal 25% bonus when instead it gives you 5% only. It's a corner case I guess.
Then, it just moves you up and down the ladder based on the level of illuminates.
There is a limitation for scenarios with very fine gradations of lawful bonus, for example if you had 24 time-of-day settings with a 5% bonus increment. You might want the Mage of Light illuminates ability to give you the normal 25% bonus when instead it gives you 5% only. It's a corner case I guess.
Hope springs eternal.
Wesnoth acronym guide.
Wesnoth acronym guide.
- Elvish_Pillager
- Posts: 8137
- Joined: May 28th, 2004, 10:21 am
- Location: Everywhere you think, nowhere you can possibly imagine.
- Contact:
- Elvish_Pillager
- Posts: 8137
- Joined: May 28th, 2004, 10:21 am
- Location: Everywhere you think, nowhere you can possibly imagine.
- Contact:
True, but that's a lot better than sorting the daytimes in a totally nonintuitive way... basically, all it does is screw up the Illuminates ability when an out-of-the-ordinary set of daytimes is used, and I can't even see a way to hackily fix it with WML.
In other words, it removes versitality, rather than adding it.
In other words, it removes versitality, rather than adding it.
It's all fun and games until someone loses a lawsuit. Oh, and by the way, sending me private messages won't work. :/ If you must contact me, there's an e-mail address listed on the website in my profile.
Hum good point, it seems that there are things to fix with [illuminates] :
- on some scenarios, like underground scenarios, illuminates should use some time of day that would never be used as a normal time of day.
- on other scenarios, like 24h scenarios, you should be able to specify that you don't use the next time of day as illuminated time, but a larger offset. I think this should rather be defined in the scenario itself than in the unit.
- on some scenarios, like underground scenarios, illuminates should use some time of day that would never be used as a normal time of day.
- on other scenarios, like 24h scenarios, you should be able to specify that you don't use the next time of day as illuminated time, but a larger offset. I think this should rather be defined in the scenario itself than in the unit.
EP, you could suggest a system that would work better.
Anyway, I suggest adding three new keys to [time]:
(optional) scheduled: no/yes ; If no, this time will not be used in the scheduled times of day.
(optional) lighter: an id of another [time] tag.
(optional) darker: an id of another [time] tag.
lighter and darker would be used to find the proper illuminated time, by traveling through the same number of lighter or darker keys as the level of illumination.
Anyway, I suggest adding three new keys to [time]:
(optional) scheduled: no/yes ; If no, this time will not be used in the scheduled times of day.
(optional) lighter: an id of another [time] tag.
(optional) darker: an id of another [time] tag.
lighter and darker would be used to find the proper illuminated time, by traveling through the same number of lighter or darker keys as the level of illumination.
"It is time people learned about their failures and my successes."
- Elvish_Pillager
- Posts: 8137
- Joined: May 28th, 2004, 10:21 am
- Location: Everywhere you think, nowhere you can possibly imagine.
- Contact:
That's true! In fact, I could suggest four:Xan wrote:EP, you could suggest a system that would work better.
1) Revert to the old system. It works better, after all.
2) Like (1), but have illuminates's "level" be the radius of the effect.
3) Give a 25% lawful-bonus for each level (or malus for negative levels). If Wesnothian dogma deems it necessary, also add illuminate_cap and deilluminate_cap attributes to the scenario.
4) Give a 25% damage bonus per level to adjacent friendly lawful units and a 25% damage malus per level to adjecent enemy chaotic units, i.e. like (3) but making sure to always be a beneficial effect.
It's all fun and games until someone loses a lawsuit. Oh, and by the way, sending me private messages won't work. :/ If you must contact me, there's an e-mail address listed on the website in my profile.