Nemesis quest script

I'm testing this by using questG04Nemesis but it didn't behave the same on the two accounts I tried.

I think the difference was that one account I picked up the quest by hand and showed "started" and on the account that the script unlocked the guild and picked up the quest, it didn't change and stated "unstarted".

I will need to check this again but it will need to wait until I ascend again.

It isn't a major bug, I simply put all the Epic weapon in my closet before starting the script and it seems to work.
 
Well, slyz did apparently log into the site three weeks ago. So not completely gone. Could commit changes, could add someone else active to the SVN repo pool.

If someone had commit rights, then it might happen. Otherwise, getting it into the SVN would actually be someone making a new SVN instead...
 
I have full SVN access, and I had the best of intentions of fixing the whole script and updating the SVN... but that has not happened yet. I can go ahead and update that last (untested) code that was posted here. Maybe one day I will get to making it all run more pretty.
 
So for some reason, this script (with the updates from ckb) gets confused on the Halloweiner adventures, even though I have a perfectly fine default programmed in on the "Choice Adventures" tab. It still stalls on those adventures, seemingly in an endless loop when it encounters them. Is there a tweak I can add to the script so that it'll just select the automatically-selected default?
 
It's still offered in the Scripts menu and slyz still logs in so....

I have been doing hybrid runs. I run BCCA and when it stops for some reason and "the time is right" I run nemesis. I expect it to run to the point where the wandering thugs start appearing and then tell me it can't get the map.

In my two most recent runs as a seal clubber, I have run it. It fights the ghosts but does not seem to craft correctly and aborts. I manually craft and then it aborts saying I need a seal clubbing club. I think by equipping the EW and visiting the guild this gets resolved. I start it and it opens the cave but then it aborts rather than get the appropriate pods. I get them manually, it runs for a bit and then aborts because of clownosity. I fix that and it runs, without hiccups.

If nemesis is still being maintained, it would be nice if this were looked at :-) I'd also ask for a feature request to have it adventure for clownosity items (or not) based on a preference or just automatically do so in HC.

Thanks.
 
I just tried as a sauceror and a pastamancer and didn't run into any problem. It crafted everything. I will reroll as a seal clubber and check it again.
 
OK I just tried this as a SC and it did everything correctly. It did everything from opening the clan to solve the maze. I do not use BCCA so maybe some weird interaction with a pre/post adventure script?
 
I just ran this as a sauceror and it just kept looking for my peppercorns of power when it already had the item. Got a lovely bunch of lemons, though! But, it also ran flawlessly on a different account with the *exact* same gear, skills, settings, etc. Maybe it's gremlins!
 
Was it possibly equipped when you kicked off the script, so failed to be detected by an item_amount check?
 
So... this just broke my 100% familiar run (not a black cat run, just a regular 100% familiar run). Any idea why it would do this? According to the change log it is supposed to respect 100% familiar runs as of an older update. And I have used this before without that issue... the only thing that seems different is that this time I ran it after breaking the crystal.

Also, when encountering a holiday wandering monster as a sauceror it just spammed it with gu gone until HP got so low that my auto abort (from another thing) triggered. It really should auto abort whenever any wandering monster is encountered (by having a list of allowed monsters which are the monsters that can be expected to be found in the nemesis quest)

Also, during the sauceror nemesis quest when fighting "Lumpy, the Sinister Sauceblob" (the encounter where it drops the pants) it was trying to spam it with gu gone for some reason
 
Last edited:
By Crystal, do you mean Prism ( freeing King Ralph )?
If so, once you break the prism, your ascension is recorded and ended. Anything done afterwards ( aftercore ) does not effect the ascension record. Does not effect 100% familiar runs, if you change your familiar after breaking that prism and freeing Ralph.

Wandering Crimbo monsters can also be turned off via,
Seaside town > Right side of the tracks > Tammy's camp > R&D Tent.

Hope you find this helpful.
 
Born Identities said:
By Crystal, do you mean Prism ( freeing King Ralph )?
If so, once you break the prism, your ascension is recorded and ended. Anything done afterwards ( aftercore ) does not effect the ascension record. Does not effect 100% familiar runs, if you change your familiar after breaking that prism and freeing Ralph.
Click to expand...
I did mean freeing ralph. While it records the % at prysm break, it also records a second value called total run. I know total run is used for black cat runs. Is everything else other than a black cat using prysm % instead?

I want to get total run at 100%, but that is just me being OCD on it. In the future I will just make sure to not use the script after releasing ralph

Born Identities said:
Wandering Crimbo monsters can also be turned off via,
Seaside town > Right side of the tracks > Tammy's camp > R&D Tent.
Click to expand...
For this holiday. ideally it would know which specific monsters to expect and then abort if it encounters an unknown monster (eg, some future holiday monster).
still tried to use gu gone on the nemesis himself (the pants dropping one) for some reason.
 
@taltamir: The script use Zlib is_100_run, kolmafia also has singleFamiliarRun but the script doesn't currently use that. I'll add a check for singleFamiliarRun (I'm not even sure how that setting behave after breaking the prism but I'll check). Maybe a user confirmation that you want to preserve your 100% run after the prism is broken.

As for the wandering monster, we can add a check but it would cause a lot of trouble with people who arrow/wink monsters as some people do in aftercore. The only way around that is to make a setting "Abort on unexpected monsters". I'm open to suggestion on that one.

@snooty: I wasn't able to replicate the bug, I'll try again on my next ascension.
 
Grabuge said:
@taltamir: The script use Zlib is_100_run, kolmafia also has singleFamiliarRun but the script doesn't currently use that. I'll add a check for singleFamiliarRun (I'm not even sure how that setting behave after breaking the prism but I'll check). Maybe a user confirmation that you want to preserve your 100% run after the prism is broken.
Click to expand...
Cool, thank you.

Grabuge said:
As for the wandering monster, we can add a check but it would cause a lot of trouble with people who arrow/wink monsters as some people do in aftercore. The only way around that is to make a setting "Abort on unexpected monsters". I'm open to suggestion on that one.
Click to expand...
I see what you mean. Only fully automatic way I can think of handling it is to look for all known monsters in case of arrowing. but that sounds like unrealistic amounts of things to check for. I can't think of any issues with having an "abort on unexpected monster" option though.
 
Last edited:
I am not 100% certain. But I was getting
Code: 
[COLOR=red]Something happened while unlocking the Volcano Maze,      exiting...[/COLOR]
and I thinkthis was happening because it was getting stuck at the "you must have at least 175 mainstat to adventure here" warning when it tried to adventure here
http://kol.coldfront.net/thekolwiki/index.php/The_Nemesis'_Lair
when my mainstat was actually lower and that message was not set to disabled. is it possible for the script to bypass that message? if not, is it possible for it give a more clear error message that states it specifically ran into that problem?
 
I still haven't ascended to test this.
There is a variable to know if the warning is disable or not but it would mean I would have to code the minimum for each zone and check it before adventuring.
It isn't hard but I would need to test it.
 
I noticed that if I run this script before manually acquiring the map to volcano island. Then once it triggers the assassins and you need to wait ~190 turns for all of the assassins, it will actually try to farm 190 turns at the castle in the sky top floor... It really really should not do that.

Instead it should consider that as a break point, stopping the script after triggering the assassins and simply instruct the user to run the script again once the last assassin is defeated.

Also, this script is perfectly happy dying hundreds of times in a row without quitting. Such as in the aforementioned castle in the sky. Or as a low skill accordion thief repeatedly bumping up against an alert mariachi. It should auto abort if you die several times in a row. (or even once really)

Speaking of alert mariachi, as an accordion thief, in the barracks. It does not care which mariachi it is going after, it will happily spend hundreds of adventures dying against an alert mariachi instead of looking for the sleepy mariachi. (sleepy mariachi can actually be pickpocketed, so it doesn't matter if you win or lose. although winning is better, and actually doable as a low skill player against a sleepy one).

Also, when maximizing init for the mariachis, it would often get a prop sword. Not only forcing it to use melee to attack (and thus miss), but also giving a huge malus to actual attacks. If there are not suitable spells permed to easily kill them then it should use the +melee and -melee maximizing strings to ensure a suitable weapon is used

Anyways, issues aside, this is an incredibly convenient script to have. Thank you again for making it.
 
Last edited:
Perhaps you should reread the first post? One of your complaints is specifically called out as a user responsibility and one you are told will happen and what to change if you want something else. You might also consider your audience. The last commit was April 20, 2016.
 
You must log in or register to reply here.
Back
Top