ZapWizard - Automatically zaps for mall profit

darkcodelagsniper said:
So a year and a bit after writing this script I'm still getting the odd kmail from people using it, which is nice :)

The new update parses stuff that can be zapped (and non-tradeable outfits that can be zapped) from mafia's data files, so the script won't need updating as new stuff gets released.
Click to expand...

Thanks. I use it daily. If you are still interested in tweaks, I stole and reworked the code that checks Coldfront and called it CFStat. Retrofitting it back to Zapwizard has been on my to-do list. Only benefit to that is it gives ZapWizard and other volume checking scripts a common cache file, which they don't have now, but that, in turn, has the potential to reduce hits on ColdFront.
 
Very handy script someone just pointed me to! Is there an option to have ZapWizard simply do the zap and not require user interaction? Also have you thought about a slight modification so you can import and call zapwizard, instead of only cli_execute?
 
You can import it. Call it with: main@ZapWizard()

That looks weird, but it is a valid function call.
 
Hah had no idea you could do that, thanks for the tip Bale! The other part though, zapping without user interaction, would be extremely handy as currently zapwizard halts my logout script until I respond to it :P
 
fxer said:
Hah had no idea you could do that, thanks for the tip Bale! The other part though, zapping without user interaction, would be extremely handy as currently zapwizard halts my logout script until I respond to it :P
Click to expand...

I am running a modified version of ZapWizard which I keep thinking I should release. (Functionality is the same but it handles the Coldfront query differently). I'll add an option to safely zap the best choice without asking and release in, although probably not until after this weekend. PM me if I have not done something by 2013 MAR 20.
 
I just uploaded a version with the zlib var "confirmautozap". Set it to false and it will zap without any user input.

This release also nukes a worrying error message where ZapWizard would claim it wasn't sure what had happened after zapping untradeable outfit parts. It still doesn't tell you if outfit zaps are "successful" or if they duplicate a piece you already had. I should get around to that, and I've plenty of opportunity to test at the moment, thanks to the Raiments of the Final Boss.

I haven't integrated CFStat because I didn't really want to add another dependency for the script, and the number of coldfront hits are minimal anyway. I think it would have been nice if CFStat had been backwards compatible with mallvolumes.txt, and stored average price data in a seperate datafile.
 
The motivation for going to CFStat was because mallvolumes did not contain price data and in my ecosystem of scripts it was more efficient to have one place that cached both rather than maintain backwards compatibility. However I have no intention of hijacking your script and converting to CFStat only benefits the handful of people who are already using other scripts of mine. :)
 
Request... any chance the various definitions set inside main could become script-globals? The issue with how they function now is that if I want to override one, I either have to modify my actual settings or the actual script... would be much easier if I could keep my safe settings, but have a "blowzapwizard" alias that nuked the wand when I'm about to jump the gash.
 
Theraze said:
Request... any chance the various definitions set inside main could become script-globals? The issue with how they function now is that if I want to override one, I either have to modify my actual settings or the actual script... would be much easier if I could keep my safe settings, but have a "blowzapwizard" alias that nuked the wand when I'm about to jump the gash.
Click to expand...
No, I'm not going to change from zlib variables back to globals defined in the script. There are a bunch of benefits to using zlib vars, especially the fact that the users values are preserved when updating the script.

You could modify the script to do this yourself - the parts taking the variables from the zlib vars are all bunched together, you could delete that and replace it with a section setting the vars to whatever you like. But I'm not sure why you'd find changing the variables in the script is easier than changing a zlib var, especially if you use a relay editor like this one.

All that said, I agree with your complaint that blowing up wands is too fiddly. I'll look into ways to make that easier.

EDIT - Hmm, running into problems with this, because it really requires being able to pass an optional argument to main, which ASH doesn't support.
 
Last edited:
Ok another new version in the OP. There's now a little more info given when zapping untradeables, and a new variable "zapwizard_blowupwand".

If you set blowupwand to true, then it overrides the setting for overheat and will continue to zap until the wand blows up.
When the script is run it automatically sets blowupwand back to false, so you don't have to worry about remembering to do it.

It will ask confirmation for every zap if 'confirmautozap' is true (the default setting). I thought about changing this, but that didn't seem satisfactory when the recommendation can easily change due to outfit completion and historical prices getting updated when you mallsell.

I'd have prefererred to make it so you could just put 'zapwizard explode' in the CLI but any args to main must be given a value by the user. That would have broken existing functionality, so this method seems a decent compromise.
 
Well, I was meaning more like what EatDrink does, which is that there are global variables set by your zlib variables, and if you want to override them, you can... But I suppose I can just manually do that myself and edit the script to follow my whims. :)
 
also you can pass args to main from the CLI now thanks to a change from Rinn I believe? 'zapwizard (a, couple, settings)' , just separate them by commas and surround with parentheses
 
Yeah, but my understanding is that if main accepts args then values must be supplied for them. I still want the basic script to be able to run without being prompted to supply arguments.
 
Ah, I see that changed. Nifty. :) And thanks.

And what you can do instead is make your main provide the default values you want, but leave the execution bit outside as an easy import. Basically, just rename your current main() to zapwizard(boolean dozap, boolean blowupwand) and then have your main() just run zapwizard(false, false);
 
Think there is a little typo on the new confirm setting:

setvar("zapwizard_confirmautozap",true); boolean confirmautozap = to_boolean(vars["zapwizard_autozap"]);

should probably be

setvar("zapwizard_confirmautozap",true); boolean confirmautozap = to_boolean(vars["zapwizard_confirmautozap"]);
 
You must log in or register to reply here.
Back
Top