Excavator - gausie's spading script

Ryo_Sangnoir said:
On the monster parts project, certain submissions seem a lot more like Anatomical Injuries than Monster Parts. In particular, looking at "giblets", "kidney", "solar plexus", "throat"...

I expect the wiki is wrong about one of the things we thought were monster parts (or one of the regexes is catching too much).
Click to expand...

Hmm. This makes me worried - perhaps we should have tagged monster parts with which regex source we spaded them from. The sources are here and a once-over seems looks on the surface to be all in order. Perhaps one of these was accidentally connected to the wrong word bucket. Since we're getting those anatomical injuries in goo monsters we can assume its happening in one of the sources that is currently in standard.
 
It's the Bowlet, probably.

Against a crate, whose only part is "crate":
Code: 
Tutchell flaps directly into your opponent's head, causing 12 damage!

Checking my logs, I see "groin", "kidney", "lower back" -- and the wiki page for Bowlet agrees it's anatomical injuries, not monster parts.
 
Ryo_Sangnoir said:
It's the Bowlet, probably.

Against a crate, whose only part is "crate":
Code: 
Tutchell flaps directly into your opponent's head, causing 12 damage!

Checking my logs, I see "groin", "kidney", "lower back" -- and the wiki page for Bowlet agrees it's anatomical injuries, not monster parts.
Click to expand...

Well, removing Bowlet is easy but rooting out the bad data is not ��. I've submitted a bug report about this anyway, because that's clearly the wrong bucket.
 
Easiest thing to do is to remove anything that's an anatomical injury submitted before the update was made. Yes, this will remove valid parts like head, arm, leg but without knowing how they were generated you can't know the Bowlet wasn't involved.
 
What link are you looking at? It is still mainatined yes, though not very actively
 
lostcalpolydude said:
I think that happens with every github-hosted script, that trying to visit the URL in a web browser that is used for checkout gives a 404.

Trimming the URL to remove any trunk gives a useful page.
Click to expand...
Does this mean the first post and svnrepo.json need to be updated or not?
 
Few updates recently:
  • Removed: WLF Bunker. It was decided there's no discernable pattern of the requests
  • Added: Beach combing rarity
  • Added: Beach combing twinkling tiles
 
I appreciate that Excavator asks for permission to send out the kmail with the spading data, but would like to request the ability to tell it "Yes to all" for at least a given backlog of data being sent, if not ideally some form of preference to indicate that permission is not required.

The reason for this is that with the recent addition of beach squares to the data being gathered, at the end of my autoscend day I have to click "Yes" for each individual walk.
 
Laserrobotics said:
I appreciate that Excavator asks for permission to send out the kmail with the spading data, but would like to request the ability to tell it "Yes to all" for at least a given backlog of data being sent, if not ideally some form of preference to indicate that permission is not required.

The reason for this is that with the recent addition of beach squares to the data being gathered, at the end of my autoscend day I have to click "Yes" for each individual walk.
Click to expand...

Go back and start reading at https://kolmafia.us/threads/excavator-gausies-spading-script.25076/#post-159396

The previous resolution was to add a couple lines to a logout script.
 
fronobulax said:
Go back and start reading at https://kolmafia.us/threads/excavator-gausies-spading-script.25076/#post-159396

The previous resolution was to add a couple lines to a logout script.
Click to expand...
This was presented as the solution to the user needing to prompt Excavator to send data, not as the solution to Excavator prompting the user to confirm that data should be sent. It will not resolve this issue as it is automatically happening before a logout script would take any actions, given that a logout has not yet been initiated.

This is happening at the end of an autoscend day; given that I cannot find anywhere that autoscend (or indeed anything at all in my script folder) is explicitly making calls to Excavator I assumed that this was something Excavator was doing of its own accord after beach combing was finished.
 
autoscend is calling the mafia command `spade` in auto_bedtime.ash, which loops though the spadingData variable and prompts you to confirm before sending each kmail. You can call `spade autoconfirm` and mafia won't prompt you.
 
Laserrobotics said:
This was presented as the solution to the user needing to prompt Excavator to send data, not as the solution to Excavator prompting the user to confirm that data should be sent. It will not resolve this issue as it is automatically happening before a logout script would take any actions, given that a logout has not yet been initiated.

This is happening at the end of an autoscend day; given that I cannot find anywhere that autoscend (or indeed anything at all in my script folder) is explicitly making calls to Excavator I assumed that this was something Excavator was doing of its own accord after beach combing was finished.
Click to expand...


OK. I was always forced to interact with the Excavator reporting until I implemented the logout. Perhaps the real "issue" is autoascend?
 
So I have two instances installed. I manually installed one via SVN and a recent return to autoscend seems to be what installed the other via git. I can certainly uninstall both versions and reinstall the git version, but I have local changes in SVN. Specifically I have a new project file that writes data about getting beaten up to a local file and a line added to excavator.ash that includes my new project.

I am using SVN's merge capability to preserve my changes across updates.

How do I make the same thing happen with git?

Ideally whatever I do would only involve KoLmafia implemented git commands and would preserve my changes across updates from the remote, but I could use TortoiseGIT with enough guidance.

Since SVN access to GIT is being phased out I may be a test case for how to tell people what to do.
 
I need to actually fix the git code to preserve changes across updates. I had thought it would work automatically (if you made your changes in the git folder, like how I thought SVN worked)

If you're willing to use TortoiseGIT, I think the following should work:
* make your local changes in the `git/gausie-excavator` folder
* make a local commit that includes your changes
* update the script as normal: as it updates using `git pull`, your changes should automatically be included
 
You must log in or register to reply here.
Back
Top