Scripting the birth of a new life.

[AlbinoRhino]

One thing that I added to my "newLife" script for BIG! runs was to get the leaflet from the council and install the Frobozz house rather than the tent. Not sure if that works for everyone's playstyle. But I find that the leaflet stats don't matter much and that one of the first things that your Universal Recovery script does for me is use up my free rests (b/c I have that enabled) and I get a lot more MP at the run's start for buffs/effects/summons etc.. Just thought I would throw the idea out there.

 

[ckb]

For BIG! runs, another combat/meat option in the Bedroom:

One Nightstand
choiceAdventure83
set to 1 (get old coin purse)
not 2 (enter combat)

 

[lostcalpolydude]

For BIG! runs, another combat/meat option in the Bedroom:

One Nightstand
choiceAdventure83
set to 1 (get old coin purse)
not 2 (enter combat)

At +100% item, you get as much meat on average from the combat as from just getting a coin purse. Plus anything else you might get from your familiar, Crown of Thrones, or whatever else is active.

 

[Bale]

Yeah, I left that one alone because there are two meat drops from the mahogany nightstand and fairies are pretty much the default in BIG, so fighting is arguably better. Though I am glad though that you were paying attention.

 

[ckb]

Ok, sure. You could get more stuff from the combat... but that is like, at least 2 extra clicks or something.

 

[Bale]

 

[Bale]

Updated newLife to v1.14.4

• Distribution has migrated over to SVN. With a current daily build, please copy/paste the following line into KoLmafia's CLI and press enter:
  svn checkout https://svn.code.sf.net/p/bale/new-life/code/

 

[fronobulax]

Feature request for consideration: I generally burn turns with BCCAscend. Because I can I am doing 100% familiar runs. I would have a warm fuzzy feeling if NewLife had an option to confirm that the zLib is_100run, the BCC 100% and BCCdefault familiar (not the exact variable names, obviously) were all consistent. I'd prefer to have the is_100 drive the process since my relay script to change that uses a dropdown for familiars and so I don't have to remember with it is NPZR or NZPR or how to expand which one is right. I realize I could do this myself and it only is a useful option for people who use both NewLife and BCCAscend, but I figured I would ask. Thank you.

 

[Bale]

Since I've never used BCCAscend and have little familiarity with its code, please explain that in a way that I can implement without having to examine the program. Using things like "exact variable names, obviously."

I know that zlib is_100run refers to vars["is_100run"] it is either "none" or a string corresponding to the name of a familiar, but I have no idea what the other two variables might be or what their values might be.

If I have to research BCCAscend I won't implement this.

 

[Theraze]

Those would be:
vars["is_100_run"]
get_property("bcasc_100familiar")
get_property("bcasc_defaultFamiliar")

In order of priority. All of which need a .to_familiar() to properly resolve, but if they're set to != "", they're at least attempting to exist.

 

[Winterbay]

If I remember correctly (I tried double-checking right now, but might've missed some point) the bcasc_100familiar setting overrides the default familiar so only the first one is required to be set to get a 100% tun with BCA.

 

[Bale]

To translate, now that I have more information, you're requesting this:

void familiar100() {
	void set_bcc(string f) {
		set_property("bcasc_100familiar", f);
		set_property("bcasc_defaultFamiliar", f);
	}
	if(vars["is_100_run"].to_familiar() != $familiar[none])
		set_bcc(to_familiar(vars["is_100_run"]).to_string());
	else
		set_bcc("");
}

Is that good?

 

[Theraze]

Actually the initial request wasn't needed, as the values override each other in the order I gave. If you have is_100_run set, it is used for everything in BCA. If you have bcasc_100familiar set, it is used for everything in BCA. If you have bcasc_defaultFamiliar set, it will be used anytime there isn't anything specific required.

A better use would be using the familiars in that order for start_familiar() as an override over the current check. Overriding the other values... not good. Despite the request. Since the scripts don't work that way.

 

[Bale]

I'll play nice with vars["is_100_run"] in the manner that Theraze suggests, but I suspect that BCCAscend can look after its own variables and needs no help from newLife to switch familiars. If I did try to look after setting the initial familiar according to BCC's variables I suspect I'd get confused posts from people who used BCCA once last year and don't know why they need to worry about its settings now. That'd be more trouble to me than it would be help for anyone.

svn update newlife

fronobulax, if you disagree, please be more specific than your previous post on the subject which proudly refused to give much information.

 

[Theraze]

Thanks. That should help save planned 100% runs when people start in the relay browser rather than going straight for automation. And if they were going to set their familiar anyways, they probably weren't just going to use start_familiar() as the decision for what the next 100% run was going to be.

 

[fronobulax]

To translate, now that I have more information, you're requesting this:

void familiar100() {
	void set_bcc(string f) {
		set_property("bcasc_100familiar", f);
		set_property("bcasc_defaultFamiliar", f);
	}
	if(vars["is_100_run"].to_familiar() != $familiar[none])
		set_bcc(to_familiar(vars["is_100_run"]).to_string());
	else
		set_bcc("");
}

Is that good?

Yes. I believe that will do what I asked, although I might consider leaving the BCC vars alone if is_100_run is not set or blank because leaving them alone would preserve whatever was entered elsewhere, which might have relevance if it is not a 100% run.

I note several folks are saying that is more than necessary. While that may be true I remember buggy versions of various scripts that did not work the way the authors said they did, so in a belt and suspenders sort of paranoia I see no harm in making them all agree if the alternative has the potential to ruin a run. Realistically, if this is still a concern I would expect it to happen when BCCAscend is stopped for any one of several reasons and then restarted. That definitely does not preserve or restore "state" in all cases, in my experience.

 

[Theraze]

I prefer having them apart, because after I break the prism, I no longer care about the 100% familiar being used by BCA. I do care about it while I'm using BCA, though. For that reason, not setting is_100_run makes me happy currently.

When I'm using Rinn scripts, adventuring manually, or trying to otherwise test something about familiars during automation, the is_100_run variable is great. As is BCA being aware of it and using it if it's set. But I love not being forced into having to waste 3 values when one will do.

Edit: Interestingly, I now only find the bcasc_100familiar value, not a check for is_100_run. Could have sworn it was in there when I looked a few hours ago. Anyways, still enjoy the split. Even if it can screw you up if you use multiple methods.

 

[Winterbay]

I prefer having them apart, because after I break the prism, I no longer care about the 100% familiar being used by BCA. I do care about it while I'm using BCA, though. For that reason, not setting is_100_run makes me happy currently.

When I'm using Rinn scripts, adventuring manually, or trying to otherwise test something about familiars during automation, the is_100_run variable is great. As is BCA being aware of it and using it if it's set. But I love not being forced into having to waste 3 values when one will do.

Edit: Interestingly, I now only find the bcasc_100familiar value, not a check for is_100_run. Could have sworn it was in there when I looked a few hours ago. Anyways, still enjoy the split. Even if it can screw you up if you use multiple methods.

I was just about to say. I mean we don't import zlib and so does not load the vars file and thus have no way of checking said variable.

 

[Theraze]

Yeah, the working together thing is that BBB would override BCA if BCA is adventuring properly. Which may be how frono messed himself up, but... eh.

 

[fronobulax]

I prefer having them apart, because after I break the prism, I no longer care about the 100% familiar being used by BCA. I do care about it while I'm using BCA, though. For that reason, not setting is_100_run makes me happy currently.

As a veer, if the Prisim has been broken does running BCCAscend actually do anything? My experience is No, other than the "thank you for using message". If it doesn't do anything then I see no reason to run it in which case the post-prism values of the BCCAscend variables are irrelevant and other scripts can use the is_100_run value as they choose, or not.

And to be clear, I expected to manually set is_100_run and then just have the appropriate BCC variables changed to be consistent.

Perhaps the solution is to create a KoLmafia equivalent of is_100_run and have scripts convert to using it, in much the same way valueOfAdventure is "global"?

We have probably moved into philosophy now since I can thank Bale for his snippet and incorporate it into my own wrapper script and I'd be happy and everyone else would have the status quo.