missingManuel.ash - Yet Another Manuel Script!

Veracity

Developer
Staff member
Version 1.44 has all the bosses from Legacy of Loathing.

If are in a run, you'll see each boss in the location you can find it.
Otherwise, they will be grouped within the "Legacy of Loathing" category.

This requires KoLmafia revision 27380.
 

Zulu Romeo

New member
I'm getting a "Bad monster value: "Rene C. Corman" (missingManuel.ash, line 115, char 392 to char 408)" over the last few days - looking at the script and comparing to the wiki there are two monsters with that name - one of them from a world event, the other from a challenge path, so how should this one be named?
 

Aramada

Member
Yeah, I'm still seeing "Bad monster value: "Rene C. Corman" (missingManuel.ash, line 115, char 392 to char 408)" as well. Is there something we need to do on our end...force a refresh or something like that?

p.s. Thank you keeping this script up, Veracity. It's a HUGE time saver!!!

~Aramada
 

xKiv

Active member
Yeah, I'm still seeing "Bad monster value: "Rene C. Corman" (missingManuel.ash, line 115, char 392 to char 408)" as well. Is there something we need to do on our end...force a refresh or something like that?

p.s. Thank you keeping this script up, Veracity. It's a HUGE time saver!!!

~Aramada

go to the file, edit it, go to line 115, find where it says Rene C. Corman
and instead use Rene C. Corman (Zombie Slayer)
 

Veracity

Developer
Staff member
That should do it.

I am confused about how the two monsters appear in monster.txt:

Code:
Rene C. Corman (Zombie Slayer)    1229    reneccorman.gif    NOCOPY Atk: 222 Def: 199 HP: 1000 Init: 200 P: dude Manuel: "Rene C. Corman" Wiki: "Rene C. Corman (Zombie Slayer)"    Thwaitgold maggot statuette (n100)
Rene C. Corman (Skeleton Invasion)    1009    reneccorman.gif    NOCOPY NOMANUEL Atk: 500 Def: 500 HP: 500 Manuel: "Rene C. Corman" Wiki: "Rene C. Corman (The Cannon Museum)"    Stabonic scroll (n100)

They both say Manuel: "Rene C. Corman" indicating that Manuel has the same name for both monsters.
However, the second also says NOMANUEL -- indicating that the monster cannot appear in Manuel and scripts should ignore it.

That's a bug in monsters.txt: any monster with NOMANUEL should not have a Manuel: qualifier.

I'm on the road with only my laptop. I SHOULD be able to fix the script, at least, from here and submit it.
 

Cathy

New member
thanks for keeping this script like all the others you do.

I do have a question, the last time I ran the script I had these pop up

[Unsorted]
fake Baiowulf {3}
fake infinite meat bug {3}
fake Hypnotist of Hey Deze {3}
fake crazy bastard {3}
fake hockey elemental {3}
fake Count Bakula {3}

are they back somehow or is this just to make us cry? :)
 

Veracity

Developer
Staff member
Those monsters were added in KoLmafia r27759.
Presumably we did not have the monster IDs for them before.
(How the author of that PR get them?)

In any case, unlike the other old monsters that were added in the same PR, they were not marked NOMANUEL.
That is a bug in KoLmafia.

(By the way, SVN does not work any more on my laptop (it claims "Bad CPU type") and I cannot install a new version, since doing so depends on python - and I can't find a version of THAT that runs on my old version of OS/X. So, updating missingManuel while I am on the road appears to be an as-of-yet unsolved can of worms.)

 

Ryo_Sangnoir

Developer
Staff member
They were not marked NOMANUEL because they have Manuel factoids -- there is just no way to encounter them at present. Perhaps this should be what NOMANUEL means anyway. It's likely the wire-crossin' elf is in the same boat.
 

taltamir

Member
missingmanuel revision 44 fails to run on mafia r27785 with the error message
Code:
> missingmanuel

Bad monster value: "Rene C. Corman" (missingmanuel.ash, line 115, char 392 to char 408)
 

JLE

New member
Same error here. I assume Veracity's SVN issues while travelling and with only a laptop to work on (reported on 6th Jan) are the reason for there having been no actual updated version of the script since the issue was first reported (Jan 1)?
 

JLE

New member
Current version also appears to mention the fake UR monsters (six of them, because there were only six URs at the time).

These, like the real UR monsters, never had any factoids at all - or, at least, did not have factoids on the day that they were encounterable. (If factoids have been subsequently added, this is another issue: but, on the one day they were available, they had no factoids.)

Also, they were only ever available once, on that single April Fools day, and were non-copyable, so if they still exist in the game's data files, it's still impossible to ever meet them unless they're re-implemented at some point.

So, if they're *not* NOMANUEL, they should be.
 

Veracity

Developer
Staff member
Those monsters were discussed just a little farther up this same page.
I, also, opined that they should be marked NOMANUEL.
Here's what Ryo said.

They were not marked NOMANUEL because they have Manuel factoids -- there is just no way to encounter them at present. Perhaps this should be what NOMANUEL means anyway. It's likely the wire-crossin' elf is in the same boat.

I have no idea how he knows that "they have Manuel factoids".
 

JLE

New member
I have no idea about that either, since they *didn't* have Manuel factoids on the only occasion when they were ever available. If there are factoids for them, they were added later, and only someone who is either on dev or has heard it from someone who is, could possibly know since they're non-copyable and non-wishable.

(PS. *I* didn't know about any factoids for those mobs even when I was on /dev.)

Another thing: Are there any plans to migrate updates for missing-manuel from "svn update" to "git update", like pretty much most other scripts have already done?
 

fronobulax

Developer
Staff member
Another thing: Are there any plans to migrate updates for missing-manuel from "svn update" to "git update", like pretty much most other scripts have already done?
This is only necessary for scripts that were hosted on GitHub but accessed via SVN. That doesn't seem to be the case so "svn update" should work as it always has. Further investigation or a Bug Report might be appropriate if svn update is not behaving.

You might be interested in the gCLI commands checkrepo and checksvngit. The former will report possible duplicates that exist in git and svn repositories and the latter will report GitHub hosted scripts that are accessed via SVN and hence will not be updated via the usual process after January 2024.
 
Top