Scripting the birth of a new life.

Well, it would cost me 160 meat to get 200 DA instead of 80 DA to start which would mean absorbing 35% damage instead of 18% damage. (Passive sills are awesome.) For an unskilled character it would give them 70 DA (instead of 10) so that it can absorb 16% of damage.

That doesn't suck, but I wonder if it is worth 160 meat at the beginning of the game.
 
I started doing it because it was good to have for a meat maid. But outside of oxy, you shouldn't really make one in-run anymore. However, I personally find the DA is worth it; at early levels that often means surviving one more hit without healing. But yeah, it depends on having Tao (not worth it without), and it probably still isn't worth it unless you're pumping ML quite a bit. (Which I am; <3 teh sauce, as ASS would say.)
 
Request;

Could you add free pulling of all bricks, so that I can hit my clannies before they get their tent up? NB; storage_amount() doesn't seem to work on free pulls, but available_amount(); does.
 
Code: 
retrieve_item( available_amount($item[brick]), $item[brick] );

Seriously? That code is funny just to look at it. I doubt that's of general interest, so why don't you just add that to your personal stuff?
 
Well, there are other ways you could code it, if that's your main concern. :p

Honestly, it just seemed useful. But I'm used to HCN, where we always try to brick each other before the tent is up. I have no idea if this is common elsewhere, as I don't really spend time elsewhere. If it's not, yeah, not worth adding. But it certainly wouldn't hurt, in any case, aside from code aesthetics. ;)
 
The update to KoL yesterday broke a couple of lines in this script. :(

I've updated the script to account for the changes!
 
Bale; while you're making changes, would you mind moving the set_choice() functions outside of new_ascension()? There are a couple of choice adventures I like to set differently than the script, and it would be awesome to have access to those functions in my script for clarity.
 
StDoodle: Done. I updated the script in the first post, but I'm not changing the version number since it's functionally identical. Enjoy.

Also, you might note the special() section at the end. You can put your character's name there if you want those functions to execute.
 
Thanks Bale, this saves a lot of work when ascending and is well laid out so it was easy to modify to my preferred settings. I was wondering if it would be possible to modify the First things first settings from this. As an example, I would prefer only to olfact zombie waltzers as mox and not as a mus or mys. I'm a script virgin so forgive me if I'm asking the impossible :)
 
That would quite be possible, it could easily reset zlib variables. I don't use FTF to control my olfaction settings, so I only have a vague idea of what you're asking. Please explain what you envision. In detail. Explain why those changes are likely to be universally accepted. I have no idea what the FTF issue is, so assume that I need the basics explained to me. (I only use FTF&SS for handling troublesome zones like the junkyard.)
 
Easy to set that it only happens when moxie... just put
Code: 
if (my_primestat() == $stat[moxie])
before what you're limiting.
 
The script already has a switch on primestat. My question is regarding what he wants to do and why.

Perhaps I misread jwylot's question. I thought he was suggesting how I should alter the script, but maybe he was asking for help altering it himself. It would be easiest to tuck class specific stuff into the big switch-case statement that checks your primestat. Set the zlib variables appropriately there. Then at the bottom use updatevars() to save the new values for those zlib variables.
 
Just add something like this (after case $stat[moxie] I guess) :
Code: 
vars["ftf_olfact"] = "blooper, dairy goat, shaky clown, some zombie waltzers, goth giant, knott yeti, hellion, violent fungus"

Add the same thing without the waltzers in the other cases.
 
Bale, according to a recent (though I'm afraid I can't remember which) Diamond Radio Program, selecting the stats / mp / hp option in the Defiled Cranny is considered "optimal" under pretty much all circumstances. I'm not sure what your exact criteria are on some of the choice adventure settings, but just thought you may want to take that into account.

P.S. Thanks for the set_choice() access! Also, is there any particular reason that several scripters make lots of their functions encapsulated or whatever the terminology is that way? Except for the rare instance of a function that's only useful inside of another function, I don't understand why it's done.
 
Guessing a bit here, but in a lot of cases, it's significantly easier troubleshooting if you encapsulate your functions... you don't need to worry as much about whether or not the proper type/data will be sent, you just know it will work if nothing got broken. Also, if you're less sure about the proper initialization methods and the like, you can pass data between your functions more easily with encapsulated functions than you can with discrete ones...
 
Sometimes I do it for the reasons that Theraze states. Other times I do it because I want to make use of a script's variable as a global to the function.

slyz said:
Just add something like this (after case $stat[moxie] I guess) :
Code: 
vars["ftf_olfact"] = "blooper, dairy goat, shaky clown, some zombie waltzers, goth giant, knott yeti, hellion, violent fungus"

Add the same thing without the waltzers in the other cases.
Click to expand...

And don't forget to updatevars()
 
Thanks guys, that's perfect. I use smartstasis through most of a run. As a mox, olfacting walters when I visit the ballroom to set the quartet or to open the wine cellar is fine as I might pick up a dancecard while waiting for the choice adventure but this isn't something I would want to do as another class. So being able to change the FTF olfact setting depending on class from New Life will make just one less thing to remember on ascension.

Once again, thanks for a great script.
 
StDoodle: In a way, a function is just another kind of flow control, like a while loop. If you have code which is going to be repeated in your function, putting it in a nested function can make a lot of sense.

For me the main reason to use a nested function rather than a loop is when I can use the return value to avoid declaring a temporary variable. As a fairly bad example, rather than

PHP: 
int a = item_amount(thingy);
if (a < 1) a = 1;
perform_action(a, thingy);

I can do

PHP: 
int max(int a, int b) { if (a > b) return a; return b; }
perform_action(max(1,item_amount(thingy)), thingy);

Basically, I really don't like declaring temporary variables which will stick around longer than their usefulness -- or overloading variables in-script, which can be confusing. Return values seem much more suited to the task. Since ASH is Java-based, I would assume that resources are eventually "garbage collected" rather than immediately freed, but it seems a better practice regardless.

Of course, in the end, it doesn't matter as long as the script works well. :)
 
StDoodle said:
Bale, according to a recent (though I'm afraid I can't remember which) Diamond Radio Program, selecting the stats / mp / hp option in the Defiled Cranny is considered "optimal" under pretty much all circumstances. I'm not sure what your exact criteria are on some of the choice adventure settings, but just thought you may want to take that into account.
Click to expand...

I must admit I always run NCs and go for the mainstat choice in the appropriate area and the stat/restore choice in the cranny so I changed the script accordingly.
 
You must log in or register to reply here.
Back
Top