Make.meat.fast
- Thread starter dj_d
- Start date
Do you mean you want the script to select the buffs and use items for effects based on the location to be farmed, and maybe even the monster you are facing? How do you propose to let the script know what you are interested in: meat, certain items (like recipe components), certain stats, ... I would love to have a script that would farm for a list of items or a list of recipes (collecting the needed ingredients or buying them - which ever is more economical).
And yes, this is just because I'm lazy and prefer to do nothing but type farm.ash, choose false, and eat a sandwich.
It sounds like a combination of scripting, ccs and moods. Of course, a script could be packaged with a number of ccs's and then just call the appropriate one when needed. This would be a big job to make it handle each class, gender, sign, area, monster, etc while parsing your items, etc.
If you are only farming one area, research and play around until you figure out what you want to do, then write or customize a script, mood and ccs and you will have it.
But if you do write the big one, I am sure that there are lots of folks that would use it (like me). I am finally getting scripting and ccs, but not yet the moods.
Something I've noticed: as of some mafia builds ago, farm.ash will behave a little differently. Not every line shows up, and it's very slow to respond if you hit the ESC key. I'm not sure when this happened, but it can make it look like farm.ash crashed.
It takes about 2 min to run (may vary significantly based on your connection speed and computer speed), though, and when it's done calculating it seems to work fine.
It takes about 2 min to run (may vary significantly based on your connection speed and computer speed), though, and when it's done calculating it seems to work fine.
Nightmaster
New member
Well, I don't want to be a party pooper, but I've given this script several shots, but it has never successfully completed, sim or otherwise. It just gets bogged mid-process, and never recovers, no matter how much time I give it. If you manage to come up with what I should do, I am open to suggestions. I'm going to try to clean up my Hard drives, and see if that helps.
Last edited:
aqualectrix
Member
Nightmaster, your problem may be related to mine. It would be interesting to know what OS you are running on, and what version of Java.
Anyway, my complaint is an odd one. Farm.ash is too fast.
It kept eating the whole of Mafia's heap (well, just about -- never got an actual error), then hanging Mafia (understandably). So I tried giving it more heap to work in, launching my .jar from the command line:
> java -Xmx128m -jar KoLmafia-7822.jar
It took longer, but still ate the heap and hung. I wondered if garbage collection just wasn't happening often enough, so I stuck a line at the top of the location-evaluation loop:
cli_execute("gc");
But still, no go. Perhaps the GC isn't getting enough time, I speculated, because I don't know much about how the Java GC works, and added this line too:
wait(5);
Aha! Success! (But only with 128m; at 64m Mafia still can't handle it.)
I wondered if it was the garbage collection or the waiting that was doing the trick, so I disabled my forced garbage collection and tried again. The heap grew more than before, but Mafia was able to do its own garbage collection often enough that it never hit the limit.
I can drop the wait time down to 3 if I leave the forced garbage collection in.
For some reason, on my system, with my Java, farm.ash is doing too much too quickly for Mafia's garbage collection to keep up. I am running OS X 10.5.8. Java reports its version to be 1.5.0_20; I haven't updated whatever came with the OS.
Anyway, others with the "it just hangs" problem may want to try this solution; it makes farm.ash pretty slow with all that artificial wait time, but at least it completes (for me, in ~20 minutes, during which I read webcomics or something).
I don't think this is a problem with farm.ash, or even necessarily with Mafia. It's just how Mafia behaves on my system with my Java version.
I bet dj_d wasn't expecting to ever get complaints that the script was too fast!
Anyway, my complaint is an odd one. Farm.ash is too fast.
It kept eating the whole of Mafia's heap (well, just about -- never got an actual error), then hanging Mafia (understandably). So I tried giving it more heap to work in, launching my .jar from the command line:
> java -Xmx128m -jar KoLmafia-7822.jar
It took longer, but still ate the heap and hung. I wondered if garbage collection just wasn't happening often enough, so I stuck a line at the top of the location-evaluation loop:
cli_execute("gc");
But still, no go. Perhaps the GC isn't getting enough time, I speculated, because I don't know much about how the Java GC works, and added this line too:
wait(5);
Aha! Success! (But only with 128m; at 64m Mafia still can't handle it.)
I wondered if it was the garbage collection or the waiting that was doing the trick, so I disabled my forced garbage collection and tried again. The heap grew more than before, but Mafia was able to do its own garbage collection often enough that it never hit the limit.
I can drop the wait time down to 3 if I leave the forced garbage collection in.
For some reason, on my system, with my Java, farm.ash is doing too much too quickly for Mafia's garbage collection to keep up. I am running OS X 10.5.8. Java reports its version to be 1.5.0_20; I haven't updated whatever came with the OS.
Anyway, others with the "it just hangs" problem may want to try this solution; it makes farm.ash pretty slow with all that artificial wait time, but at least it completes (for me, in ~20 minutes, during which I read webcomics or something).
I don't think this is a problem with farm.ash, or even necessarily with Mafia. It's just how Mafia behaves on my system with my Java version.
I bet dj_d wasn't expecting to ever get complaints that the script was too fast!
Last edited:
Nightmaster
New member
That sounds very possible. My OS is XP, and my Java is the latest version. It does always seem like the last thing I see before it hangs it the memory bar in the top right maxed out. Perhaps either a delay or a forced GC would be good?
aqualectrix
Member
Yeah, even with this solution it does the "seems to hang, but is actually still working" thing. But without it, at least for me and the time I've had the patience to wait, it's no go.
Edit: I wouldn't advocate wait() in that loop as a default behavior for the script. Plenty of people seem to run it just fine. If enough people have an issue like this it could perhaps be an option; otherwise a note in the first post about where to insert a wait() line should serve for the few who need to get around it.
Edit: I wouldn't advocate wait() in that loop as a default behavior for the script. Plenty of people seem to run it just fine. If enough people have an issue like this it could perhaps be an option; otherwise a note in the first post about where to insert a wait() line should serve for the few who need to get around it.
Last edited:
Jazzmin
New member
I have been trying unsuccessfully to use this script. My problem seems to be that the script gets booted from the internet or something. I see a ton of attempts to re-login, where it gets stuck at synchronizing moon data... if I try to escape out of it it says "Kolmafia declares world peace" and then immediately continues exactly what it was doing before. The only way to stop it is to close mafia. This may be a net limitation at work.
However when attempting to run it from home I get a message saying some error occurred and that it printed the debug log. The debug log is singularly unhelpful, all it says is "Unexpected error, debug log printed" and it has a timestamp.
However when attempting to run it from home I get a message saying some error occurred and that it printed the debug log. The debug log is singularly unhelpful, all it says is "Unexpected error, debug log printed" and it has a timestamp.
Yeah, just purchased ascend.ash today (for this script, I'm probably never going to use ascend.ash). I got to where it was calculating something with the albino bat (I was simulating), and it just hanged. 10 minutes later, it was still hanging.
If this is a mafia problem, is there a chance it can be fixed?
If this is a mafia problem, is there a chance it can be fixed?
aqualectrix
Member
Aha!
As I was musing to a friend of mine how odd it was to make a post complaining that something was too fast, his interest was caught. He took a look at the code. He said:
"Java strings are immutable. Every time you do a string concatenation, you produce a new object that the garbage collector has to track."
Now, farm.ash is chock-full of very helpful print statements, all generated on the fly and full of concatenation. Could this really be the issue?
I took out my cli_execute("gc") and wait() statments. I commented all output and print statements in the main location loop out (except the ones actually stating which location was being analyzed). I launched KoLmafia (build 7828) in the default configuration, 64m.
Whoosh! Locations flew by. Heap size never rose above around 40m. farm.ash finished successfully. (Of course, I no longer had the end-report with the location details in it, just the final conclusion.)
I'm not too familiar with ash yet, I admit, but these results are impressive. I would indeed expect removing output to speed execution (communicating with hardware to show things is relatively slow), but not to decrease memory use so dramatically.
Possibly a workaround could be to use buffers somehow? You'd want to do all the construction as buffers, then let print() take care of turning the completed buffer into a string. It might make the output process more annoying (construct buffer, pass to output() which now takes a buffer, etc.), but it might be worth it.
As I was musing to a friend of mine how odd it was to make a post complaining that something was too fast, his interest was caught. He took a look at the code. He said:
"Java strings are immutable. Every time you do a string concatenation, you produce a new object that the garbage collector has to track."
Now, farm.ash is chock-full of very helpful print statements, all generated on the fly and full of concatenation. Could this really be the issue?
I took out my cli_execute("gc") and wait() statments. I commented all output and print statements in the main location loop out (except the ones actually stating which location was being analyzed). I launched KoLmafia (build 7828) in the default configuration, 64m.
Whoosh! Locations flew by. Heap size never rose above around 40m. farm.ash finished successfully. (Of course, I no longer had the end-report with the location details in it, just the final conclusion.)
I'm not too familiar with ash yet, I admit, but these results are impressive. I would indeed expect removing output to speed execution (communicating with hardware to show things is relatively slow), but not to decrease memory use so dramatically.
Possibly a workaround could be to use buffers somehow? You'd want to do all the construction as buffers, then let print() take care of turning the completed buffer into a string. It might make the output process more annoying (construct buffer, pass to output() which now takes a buffer, etc.), but it might be worth it.
jasonharper
Developer
While use of buffers can certainly improve performance in certain cases, it's NOT going to significantly reduce the amount of string garbage produced. Reason: after every ASH operation, the results are printed to the debug stream - which is normally not open, so this has no effect, but the parameters get evaluated anyway. In the case of buffer values, this means that a string copy of the buffer is produced after every step, which the garbage collector will have to get rid of.
It would be useful if someone who can reproduce this problem, and has a full JDK installation, could produce a heap dump as previously described for tracking down memory leaks: that would at least make it possible to tell just what's clogging up the tubes.
1. Get mafia into the non-responsive state.
2. Run jps to get mafia's current ID.
3. Run jmap -heap:format=b ID to produce the dump, which will be called something like heap.bin.
4. Zip & attach that file to a message here.
It would be useful if someone who can reproduce this problem, and has a full JDK installation, could produce a heap dump as previously described for tracking down memory leaks: that would at least make it possible to tell just what's clogging up the tubes.
1. Get mafia into the non-responsive state.
2. Run jps to get mafia's current ID.
3. Run jmap -heap:format=b ID to produce the dump, which will be called something like heap.bin.
4. Zip & attach that file to a message here.
