New Content - Implemented Zombie Skills, Horde as MP, Combat/Noncombat, etc.

Here is a path with changes to support skill type 7 (Combat/Noncombat healing).

I changed Zombie Maestro to "combat" type, since it doesn't fit type "7" anymore. I don't really see how it applies out of combat though, the wiki isn't clear on that.
 

Attachments

It's a passive skill, applying in combat and out of combat, reducing the horde cost of all zombie skills. It isn't something you can cast outside of combat. I guess that makes it a passive/combat skill.
 
I see. I wonder if we should add a category just for it though. Leaving it as "combat" would mean that $skill[ Zombie Maestro ].passive will be false instead of true, but that is the only drawback I can see.

I was looking into adding Devour Minion as a restoration option, but it turns out that, according to a clanny, KoL ignores the "quantity" field and always casts it only once.

Since it is the only non-multiuseable skill I can think of (apart from Summon Clip Art, which isn't really a skill from Mafia's point of view), I guess a hardcoded exception in UseSKillRequest.run() and HPRestoreItemList.recoverHP() will do the trick.
 
That patch is working fine for me for Devour Minions. I currently have other changes that I'm working on in SkillDatabase for Summon Minion and Summon Horde to make it more complicated to actually commit the code.
 
Alternatively, would it be sane to consider using a bitfield to represent type? (an added "bonus" is that we could use categories such as "castable on others" and "castable on self")

example:
Code: 
0x01: passive
0x02: combat
0x04: noncombat
0x10: summon
0x20: castable on self
0x40: castable on others
0x80: AT song

If you store it in an int, even, you'll have plenty of space (24 bits) for extensibility.
 
Meat Shields is not marked as a combat skill

Meat Shields is not marked as a combat skill. That is keeping it from being used in CCS. Post on main forum.

Code: 
[COLOR="Olive"]> ash $skill[meat shields][/COLOR]

Returned: Meat Shields
level => 5
traincost => 2500
class => Zombie Master
libram => false
passive => false
buff => false
[B]combat => false[/B]
song => false
permable => true
dailylimit => -1
timescast => 0

It also should not be permable. Are there are a lot of Zombie Master skills that are marked permable?
 
Last edited:
I think all of the Zombie skills are marked permable.

Also Zombie Maestro and Devour Minions should be marked as combat usable as well.
 
They should also not have a "traincost" since you don't buy them in the guild.

The "should be marked as combat usable" is the unfinished skill type 7, mentioned in the general thread discussing Zombie skills. Which this bug report should, perhaps, have gone into. ;)

I am not planning on doing another Zombiecore run. I am sure that those who are planning on doing such will fix all these things, by and by.
 
Devour Minion, Meat Shields, and Zombie Maestro should be recognized for in-combat use. The training cost for zombie skills has been fixed. Zombie skills are marked as not permable now. (As of 11440).

Lure Minion: I don't know if I want to add support for this. Maybe it could be added as a separate command.

Howl of the Alpha: This is probably like Banishing Shout, but someone needs to actually check.

Summon Minion: It looks to me like I have the code written for this. However, the code in ChoiceManager.specialChoiceHandling() is only triggering the first time the choice adventure is reached, and not the second time to leave the choice adventure. That works fine when casting it the first time, but it leaves KoL in a state where all skills that use choice adventures are messed up until you visit main.php.

Summon Horde: I have this coded, and it's working properly. Most of the code is common with Summon Minion, so I've been waiting on it in case I change things around, but maybe I should just add it.

Zombie Maestro: The -1 to skill cost still needs to be added. However, this is currently bugged in KoL (subtracting 1 from the total cost of multi-casting instead of 1 from the cost of the skill), so I think it should wait.
 
Nothing has changed with Lure, except that slyz has a nice script for it. Summon Minion and Summon Horde are implemented. Maestro still has the KoL bug.

Howl is essentially the same as Banishing Shout. I was going to add it to the same block, reusing the setting even. However, I realized that the current check is in FightRequest.registerRequest(), meaning it won't recognize failure due to unbanishable monsters, and that is likely to happen with Howl's secondary purpose of doing lots of damage.

I think the right thing to do is move it to updateRoundData() and check FightRequest.nextAction to see if the skill was used. There's enough going on in FightRequest that I'm not even sure I would properly test all the relevant cases, but I'll try that tomorrow if there's no feedback.

Badly Romantic Arrow needs the same treatment, it looks like. Maybe other things in there too.
 
heeheehee said:
Alternatively, would it be sane to consider using a bitfield to represent type? (an added "bonus" is that we could use categories such as "castable on others" and "castable on self")

example:
Code: 
0x01: passive
0x02: combat
0x04: noncombat
0x10: summon
0x20: castable on self
0x40: castable on others
0x80: AT song

If you store it in an int, even, you'll have plenty of space (24 bits) for extensibility.
Click to expand...

Flags, good. Bitfields, noooo! Please, no bitfields. Bitwise math is really easy to get wrong for even good developers, of which I am not one.
 
Well, the only reason to use bitfields would be for a more concise representation in datafiles (and an easier way to specify multiple behaviors). In the actual core of Mafia, it should probably be represented with a (very small) class.
 
heeheehee said:
Well, the only reason to use bitfields would be for a more concise representation in datafiles (and an easier way to specify multiple behaviors). In the actual core of Mafia, it should probably be represented with a (very small) class.
Click to expand...

:) Even if you stored these in datafiles as 4-byte UTF strings w/ the words spelled out ("combat, noncombat, etc") ala prefs, we would barely impact the data usage footprint of kolmafia. Sorry, bitfields are a pet peeve of mine. They made sense when apps had 16k of memory and were written in assembly, but nowadays the size benefits are significantly outweighed by the downsides of the complexity. Anyways...
 
Right, (at the very least) letters would be more sane. Bitfields are just so convenient when you're working at a lower level, though... But yeah, probably not the best design decision in this case.
 
Howl of the Alpha is tracked in 11500, so I'm marking this Implemented. If Maestro is ever handled properly by KoL then it can be a separate thread.
 
In 11510, Mafia is not recognizing Bite Minion (upgraded with Devour Minions) as a method of removing negative status effects. (Specifically Cunctatitis. "uneffect Cunctatitis" returns "Cunctatitis cannot be removed with an available item or skill... You need 1 more soft green echo eyedrop antidote to continue.")
 
Emtu said:
(upgraded with Devour Minions)
Click to expand...
That's why it isn't straightforward to add.
Emtu said:
(Specifically Cunctatitis.)
Click to expand...
You can simply add a trigger in your current mood for "When an effect is gained ... Cunctatitis ... cast 1 bite minion". This will make Mafia use "cast 1 bite minion" as the default action to uneffect Cunctatitis.

It will also auto-remove Cunctatitis if you have Mafia set to run moods, but that is just a bonus.
 
This is an untested patch that adds an ugly hard-coded exception to UneffectRequest for Bite Minion. I hope someone comes up with a better way to add this.
 

Attachments

You must log in or register to reply here.
Back
Top