stannius' semi-automatic spaaace script
- Thread starter stannius
- Start date
I already have code to do that (sort of)
Code:
if (contains_text(questLogPage1,"Find and repair the shield generator on Hamburglaris."))
{
AssertHasItem($item[E.M.U. Unit]);The problem, as per the bug report, is that mafia's internal state thinks you have the Unit, so this check will pass. I'll see if I can check for lack of the constituent items. (Assuming mafia detects the gain thereof.)
Odd... I'll check it out when the kingdom comes back up...
Last edited:
Winterbay
Active member
Yeah, and now it should detect the loss again so that code should work. The problem is if the script somehow manages to lose three times in the porko game the quest log will still show that you have gotten that far and if you don't have the unit the script will then exit rather than try again.
Also: I think a better solution might be to make sure it doesn't lose three times
Also: I think a better solution might be to make sure it doesn't lose three times
Yeah, and now it should detect the loss again so that code should work. The problem is if the script somehow manages to lose three times in the porko game the quest log will still show that you have gotten that far and if you don't have the unit the script will then exit rather than try again.
Also: I think a better solution might be to make sure it doesn't lose three times
Version 0.2 had an off-by-one error in the porko code, but that was hopefully fixed in 0.3.
I will manually lose Porko and try to make my script recover.
Try to catch the game text you get the first two times you loose.
Will do!
Winterbay
Active member
Not sure if this is a Scritp bug or a Mafia bug but here we go:
I have no idea how the 1.38's showed up there. They shouldn't (max chance should be 1). I would suggest putting in a sanity-check to make sure the choosen value isn't >1 and if it is abort and let the user poke at it.
I loaded it up in the relay browser and now the preferences say:
So it appears that the preferencce wasn't updated from the last time I played Porko last ascencion?
Code:
[1441] Hamburglaris Shield Generator
Encounter: Big-Time Generator
Encounter: Big-Time Generator
Probablities: 1.00:1.00:1.00:1.38:1.38:0.83:0.09:0.09:0.09
best choice is 4 at 1.38 ev.
Encounter: Big-Time Generator
Encounter: Big-Time Generator
Programmer error: Lost Porko. This should not happen and probably indicates a bug.
> prefref porko
lastPorkoBoard (user, now '2222331313311211323213211323112333331133133112211111112122212121212213131231333223332331321113212332113123331221221333212332212333212222', default )
lastPorkoExpected (user, now '1.00:1.00:1.00:1.38:1.38:0.83:0.09:0.09:0.09', default )
lastPorkoPayouts (user, now '022120013', default )I have no idea how the 1.38's showed up there. They shouldn't (max chance should be 1). I would suggest putting in a sanity-check to make sure the choosen value isn't >1 and if it is abort and let the user poke at it.
I loaded it up in the relay browser and now the preferences say:
Code:
lastPorkoBoard (user, now '1213323322223111211122233113111233213131232312321311113322111113121113311121133323233122122331231212112311311133321211121122122211111113', default )
lastPorkoExpected (user, now '1.00:1.00:0.62:0.59:0.28:0.00:0.00:0.00:0.00', default )
lastPorkoPayouts (user, now '000010000', default )So it appears that the preferencce wasn't updated from the last time I played Porko last ascencion?
xKiv
Active member
"ev" is expected value (in this case, it should be sum of probability(ends in slot i)*payout(slot i) over all bottom slots). This can be as high as 3 (100% probability of getting 3 isotopes) and is important - 50% of getting 3 is way better than 51% of getting 1.
Weird. I was unable to test the porko code this run because I hit a 6% chance to succeed. In fact, given that every porko game is probabilistic, it's hard to tell if the script chose the right choice or if it just got lucky. Anyways I am spinning up a test multi and will try to fix this asap.
I ran with a multi and found (and fixed) a couple problems.
1) Even as a pastamancer (yay noodlecannon) I can lose the SLG if I lose init. Not sure what a low-skilled player can do about that, but I can recommend boosting init at least. At least I was able to find a bug in the code "what happens if you lose the SLG" - it won't run again because the quest log still says "Escort Axel Otto" even though you don't have her. Fixed in 0.5.
2) If a user has arcadeGameHints=false then lastPorkoExpected is an empty string. Added a check for that case and abort. Also, I added a CYA check that if the best porko prob is anything other than 1.0, abort.
V 0.5 uploaded with the changes. The porko code still isn't as tested as I would like. I am trying to ascend my testing multi for another run at it.
1) Even as a pastamancer (yay noodlecannon) I can lose the SLG if I lose init. Not sure what a low-skilled player can do about that, but I can recommend boosting init at least. At least I was able to find a bug in the code "what happens if you lose the SLG" - it won't run again because the quest log still says "Escort Axel Otto" even though you don't have her. Fixed in 0.5.
2) If a user has arcadeGameHints=false then lastPorkoExpected is an empty string. Added a check for that case and abort. Also, I added a CYA check that if the best porko prob is anything other than 1.0, abort.
V 0.5 uploaded with the changes. The porko code still isn't as tested as I would like. I am trying to ascend my testing multi for another run at it.
How strange. KoLmafia only looks at the property to decide if it should decorate the Porko game in the relay browser; the actual solving has already happened when you visited the board - regardless of that property.
Hmm, that is strange. I could definitely be wrong about why lastPorkoExpected was an empty string. That's why I defensively added a check for the max prob == 1.0. It's just so hard to test this with only one try per ascension...
Winterbay
Active member
What is the rationale behind using "-moxie" in this maximizer call?
outfit = "DA, DR, -moxie, 1 hand, +equip spooky little girl";
That makes it so that, at least during my myst runs, I end up wearing the Furry outfit with its wonderful effect on my moxie (last run I was down at 10 I think, this town it was "only" 39). Removing that keyword works excellent for mystclasses (well at least mine).
outfit = "DA, DR, -moxie, 1 hand, +equip spooky little girl";
That makes it so that, at least during my myst runs, I end up wearing the Furry outfit with its wonderful effect on my moxie (last run I was down at 10 I think, this town it was "only" 39). Removing that keyword works excellent for mystclasses (well at least mine).
The goal is to lower the the attack stat of the scaling monsters in the area, hypothetically minimizing damage taken.
My hypothesis was that lowering moxie would lower the amount of absolute damage taken, which is my guess at what counts for that part of the quest.
At the very least I need to weight it way lower than the other keywords. I'll put that into the next version.