SmartStasis -- a complex script for a simple CCS

Winterbay said:
The problem here is actually that while SS decides on all those things BatBrain uses yoru yellow ray as soon as it can when it sees that you have the option against a ftf_yellow monster potentially overriding the decision made by SS.
Click to expand...
fxer said:
Hmm yes I see that ftf_yellow is handled in BatBrain.ash but is described in this post as a feature of SmartStasis. Doesn't SS seem like a better place to handle yellow-rays, especially with the existence of conditional drops that you would want to pickpocket attempt before yellow beaming, in addition to throwing putties first etc?
Click to expand...

Hmm, well any ideas on the best way to ensure puttying is going to happen no matter what with BB & SS, then let SS & BB continue consulting to fire the beam?
 
Last edited:
zarqon said:
Additional #1. The reason is that the script has no idea that Release the Boots will end the combat, so it is trying to protect you from the damage it predicts you will be taking (as mentioned above, a fix for this is under consideration).
Click to expand...

I would assume that same fix would allow pickpocketing and putty-tossing before Release the Boots/Point at your Opponent/Unleash Nanites? All of those skills end the combat and it generally happens before important stuff, pickpocketing & puttying, has a chance to happen
 
Last edited:
In the interim, since currently BB has a 1 in 3 chance of yellow-beaming my puttied monster to death before making another copy, would this code change work for?

Original:
PHP: 
   if (my_fam() == $familiar[he-boulder] && have_effect($effect[everything looks yellow]) == 0 &&
       contains_text(action," yellow eye") && contains_text(to_lower_case(vars["ftf_yellow"]),to_lower_case(m.to_string())))
      return act(use_skill($skill[point at your opponent]));

Wait until after round 4 to think about beaming:

PHP: 
   if (my_fam() == $familiar[he-boulder] && have_effect($effect[everything looks yellow]) == 0 &&
       contains_text(action," yellow eye") && contains_text(to_lower_case(vars["ftf_yellow"]),to_lower_case(m.to_string())) && round > 4)
      return act(use_skill($skill[point at your opponent]));

It looks like the variable 'round' is set at this point in the script?

EDIT: hmm well didn't work with round > 3, it dropped out of SmartStasis after round 1 (pickpocket)...what to do
 
Last edited:
fxer said:
I would assume that same fix would allow pickpocketing and putty-tossing before Release the Boots/Point at your Opponent/Unleash Nanites? All of those skills end the combat and it generally happens before important stuff, pickpocketing & puttying, has a chance to happen
Click to expand...

Right, except for Point at Your Opponent. That's a special case because it's reactive; it depends on the current color of the eye. Detections and reactions are both handled in BatBrain's act() function and also included in batround(), since including conditional reactions in your submitted macros saves server hits. However, Pointing is technically more of a custom action. If it weren't reactive, it would naturally belong toward the end of build_custom(). Thus our quandary.

So far, I've kind of assumed that you don't need to do a bunch of other stuff before you Point, since Pointing is the main goal, and thus monsters specified in ftf_yellow are to be Pointed at whenever possible, even if that precludes other actions. It seems that you are wanting to do a bunch of actions first, seemingly in a farming situation -- getting maximum drops from a specific monster and its copies. Typically in farming situations you aren't in danger of dying if a few rounds go by, so I think different behavior is called for depending on how safe you are.

I'm going to change these two things specifically because of this friggin' special skill:

1) Check if Point is planned for the monster before enqueueing +item disco combos. There's no need to cast Rave Concentration before Pointing.
2) If you are safe, delay Pointing so long as custom actions remain. If you are not safe, treat ftf_yellow monsters as now (Point ASAP).

Does that address your needs to your satisfaction? I'm a wee bit leery that this will lead to complaints from another direction: if there are any other custom actions which end the combat for that specific monster, it will never get Pointed at. I tend to think those combat-enders are included because they're always desirable, but what if someone wanted to yellow ray a clingy pirate, yet they have cocktail napkins? Aaaaahhh
 
Last edited:
But if someone wants to yellow ray clingy pirates wouldn't they have clingfilm as a goal then? IIRC BatBrain won't cocktail napkin clingy pirates in that case (there are probably other cases, but I don't think that should be one of the concerns).
 
zarqon said:
Does that address your needs to your satisfaction?
Click to expand...

Thanks for your post here and in the BB thread, and yes that sounds perfect for me. I don't know if it changes anything with how you would have BB/SS interact with yellow rays but I do have the monster I want puttied and not immediately beamed set as the autoPutty monster in Mafia.
 
zarqon, since you're getting ready to update your combat suite, I'd like to make a request/suggestion for SmartStasis. Twice I have had SS quit flyering without the arena being happy until I manually flyered 1 more monster, presumably due to ML variance. Could you keep flyering until it is at 101% complete instead of just 100% complete? kthnxplz!
 
@Bale: yesthxdone. Although, I think I'll do 100.5% for now and if the problem reoccurs, we'll bump it up to 101.

@Winterbay: Yeah my example wasn't great, but there may be a situation where someone prefers yellow raying to whatever the custom combat-ender is. Oh well, it wouldn't be the first time I've had to add special case handling to my combat scripts! hahaha Also I just dropped a bomb in your thread, go check it out.
 
Last edited:
If smartstasis decided to jiggle, then the script aborts:

[399] F'c'le
Encounter: cleanly pirate
Strategy: AoJ.ccs [default]
Round 0: Derp loses initiative!
You lose 21 hit points
Round 1: Derp executes a macro!
Round 1: Derp jiggles the Staff of the Staff of Life
Round 2: You jiggle the staff. There is a weak coughing sound, and a little puff of flour shoots out of the end of it. Oh well. You rub the flour on some of your wounds, and it helps a little.Your opponet is too busy snickering to attack you this round.
Round 2: You gain 10 hit points.
You're on your own, partner.
Click here to continue in the relay browser.

My .ccs:

[ default ]
consult smartstasis.ash
skill boil
 
Last edited:
Something else new:

Round 0: JoeDerp wins initiative!
The string "/\/\^v^/\/\" is not an integer; returning 0 (zlib.ash, line 181)
The string "/\/\^v^/\/\" is not an integer; returning 0 (zlib.ash, line 182)
Round 1: JoeDerp executes a macro!
 
That's BatBrain, not SmartStasis. And it's because Zarqon is amused by letters and symbols in his to_int version checker. It'll go away after the next next version of BatBrain. :)
 
BATS! With glowing red eyes and glistening fangs, these unspeakable giant bugs drop into your CLI when you least expect it!
 
With r12007 and the current versions of BatBrain, SmartStasis and WHAM my character was beaten up because SmartStasis decided to go wild with identification of Bang Potions against a monster without queuing a stun action.

Code: 
342] Haunted Library
Encounter: writing desk
Round 0: Arbos wins initiative!
WHAM: Running SmartStasis
Round 1: Arbos executes a macro!
Round 1: Arbos uses the swirly potion!
Round 2: writing desk drops 3 attack power.
Round 2: writing desk drops 2 defense.
You lose 1 hit point
Round 2: Arbos uses the smoky potion!
You lose 15 hit points
Round 3: Arbos uses the cloudy potion!
You lose 15 hit points
Round 4: Arbos uses the effervescent potion!
You lose 31 hit points
Round 5: Arbos uses the fizzy potion!
Round 6: Arbos uses the dark potion!
You lose 40 hit points
You lose an effect: Beaten Up
WHAM: SS has finished the fight. Aborting script execution.

Any thoughts on how to prevent this?
 
Don't be weak enough that accidentally boosting a monster's stats makes you die to its newly boosted stats?

Pre-boosting, you'd have survived. Post-boosting... well, you saw the result.
 
Agreed. If I had been adventuring manually and identifying bang potions I would have queued a stun first. It would be nice if SmartStasis would account for that.
 
Except that the stun would have only protected you during the period when they weren't really hurting you. :) It wasn't until round 4 that you'd double-buffed their attack to where you were actually dying, which is the same point (3 potions w/o funkslinging - or rounds - in) that noodles would have worn off.
 
You must log in or register to reply here.
Back
Top