SmartStasis -- a complex script for a simple CCS

Code: 
[COLOR="#808000"]> ash get_property("_meatperhp")[/COLOR]

Returned: 7.000001E-5

[COLOR="#808000"]> ash get_property("_meatperhp").to_float()[/COLOR]

Unexpected error, debug log printed.
Returned: void
meatperhp can get very low when curing a lot of hp with a scroll of drastic healing. What should be the solution?
Click to expand...

float.to_string().to_float() should be an identity. IMO this is a mafia bug. I could re-write to_string(float) but that seems wrong. In the mean time I'd suggest using max(0.001, n) Mafia starts using scientific notation at 1E-4.
 
aqualectrix has recently submitted a bug report about this very issue, after encountering the same problem using the Map Manager.

Thanks for improving the max() workaround CH.
 
I'm going to kill myself for getting into this collaboration because now I'm overthinking it.

It occurred to me that if a player is restoring his hp with skills in hardcore, then that changes the meatperhp calculation that you need for your combat script. That means I need to set meatperhp and meatpermp in hardcore also. It seems I really am duplicating that part of your script regardless of my previously stated desire. After all, your script cannot figure meatperhp based on use of healing skills.

I've managed to make this rather non-trivial. Now I'm calculating meatperhp every time I cast a healing spell. AAAARRRRGGGHHHH!
 
Schematic to assist you. Hopefully. Rather than complicate matters further.

MP base value: cheapest renewable restore
HP base value: whichever is cheaper: cheapest renewable restore or cheapest healing skill (based on meatpermp)

Then,

For MP:
  • !can_interact(): base value
  • using consumable items: value based on mall price
  • using nuns/non-consumables: base value / unchanged

For HP:
  • using skills: amount healed * mp_cost() * meatpermp
  • !can_interact(): base value
  • using consumable items: value based on mall price
  • using nuns/VIP/nonconsumables: base value / unchanged
 
For HP using skills: amount healed * mp_cost() * meatpermp
Click to expand...
I think you mean: mp_cost() * meatpermp / amount healed.

I've got the gist of it. It's just tough integrating it into my script reasonably.
 
I threw that mistake in there so you could feel good about correcting it. Yeah, that's the ticket.
 
Universal Recovery now calculates _meatperhp and _meatpermp and keeps them updated for current values so that SmartStasis can know exactly how much restoration costs. Awesomely, these figures will be accurate, even if the the character is healed with skills.

Also, I think that releasing a script that directly helps a fellow scripter's work should automatically counter the Spiteful Curse of Bale if they have such an effect. Please spade if that is true. I guess if you don't post a reply, then it doesn't counter the curse. :(
 
Last edited:
Thanks Bale! Unfortunately I was in HC and unable to be affected by your cure. But your curse has finally expired so I'm able to post again. So I updated ALL my scripts which I was able to work on while cursed.

Updates!

SmartStasis is now friggin' awesome. I painstakingly rewrote it to use familiar formulas rather than arbitrary values, so now inmeat, inmp, and inhp are actually calculated as the average amount you will make per round. This combined with Universal Recovery's more accurate values for HP and MP will make SS much more accurate in its decisions, particularly with disco combos.

It was a pain to write. But here's why it's worth it. The script now switches on my_familiar() rather than building maps of all familiars that affect the given factor. This runs faster and consumes less memory. In addition, by using formulas and the recovery script's provided values, we can calculate very accurate value per round from a given familiar. So I added a "profitforstasis" variable, which operates in addition to the "meatforstasis", "hpforstasis", and "mpforstasis" variables. This may be useful in cases where the input on any one of those would be too small for stasis, but the overall profit from all of them combined is enough to justify stasis.

I also added familiars that damage the player, so inmeat can be negative, which will effect the value of a round. I foresee all this new more accurate data being very valuable to consult scripts that import SS.

I'm not sure yet how this will play out in SS. Perhaps I'll discard the other three variables and use exclusively profitforstasis. I'm still not exactly sure what a good number for it is. Help in figuring that out (with examples) would be appreciated.

If you set your verbosity high (new ZLib setting) you can see at the start of combat how much profit your current familiar generates.

Enjoy!
 
I love script synergy. Now, SS + UR is better than either by themselves.

After New Year, I'm ascending into a 95%+ Snow Angel run, so I'll get lots of chances to test the script synergy.
 
Exactly that.

Your script is able to figure out if it wants to do the restoration, or let my script do the restoration, based on information my script passes to it. That means a character gets the benefit of having our scripts collaborate to figure out if it is cheaper for him to restore in or out of combat.

Win/Win.
 
Perhaps for a future version, it could factor in the Frumious Bandersnatch for determining whether to use a disco combo. Right now, it checks to make sure that the damage from the disco combos won't kill the monster before the combo finishes. However, if the familiar is a Bandersnatch (without Ode), each of the relevant DB skills will also cause it to deal 1/2 to 1 times its weight in hot damage. So it'll often think it can do a combo but end up killing the monster prematurely.
 
Yay, someone answered my question. I'll be adding Bandersnatch DB bonus damage in shortly, as well as a check for missed Olfaction as discussed in the FTF thread.

I also realized I didn't fully convert the disco combo calculations over to the new system. Once I publish the update, I anticipate that for those using UR (and especially those with mall access), combos will be cast much more frequently, since UR's provided actual cost per MP will be significantly lower than the script previously supposed.

There is only one problem with the calculations: the script assumes an average amount of MP gained per round from your familiar. When deciding to cast disco combos, it offsets the casting cost by the possible MP restoration you will get from the rest of the combat. If you are using a Cocoabo-type, you may or may not actually get this restoration. Further, if you began the combat without enough MP to cast the combo, your familiar may kill the monster before you finish your combo. But these are unlikely cases -- since combos will most likely be autocast against higher-level monsters, we can pretty much count on higher monster HP and the player's larger MP reservoir making this undesirable outcome improbable. Just wanted to mention that.

I'll wait until mafia supports Static Shock before making this update, since that is a skill SS should take advantage of if it's available.
 
I believe this is a bug for Smartstasis, but might be first things first, but I don't think it has the basement monster values, I was using the autobasement.ash and it breaks at every monster saying just after smartstasis giving a bad monster value error.
 
Totally guessing here, but I think mafia includes the floor of the monster in the monster name, making canonical names impossible for the basement.

Luckily, there's no reason to stasis in the basement! I'd recommend not using SS (or FTF) in the basement.
 
Function 'vprint( string, int )' undefined (FirstThingsFirst.ash, line 46)
Consult script 'SmartStasis.ash' not found.
You're on your own, partner.

What does this mean? I read the whole thread, albeit not very carefully, before asking...
 
You must log in or register to reply here.
Back
Top