ChibiParent

Random events are rather unfortunate. I've seen up to three happen during a single turn.

The version above keeps track of daily adventures used. This allows the script to be more cautious, when balancing, as the remaining adventures decrease. This should mimic attempting to get close to [4, 4, 6, 6] and then adventuring to get there.

Your ChibiBuddy should still survive till tomorrow. After you try the soon-to-be new version of the script, I'll be glad to hear the about the outcome.
 
The new version had to use two adventures right away because one stat was at 9, and it didn't go down on the first attempt. Once it got down to 3/3/8/8 it tried a non-adventure option, and, of course, got hit with a double random event that put it back to the initial state of 3/3/8/9. Then it just spent the rest of the adventures and got to 3/3/7/8. Still hanging in there, hopefully.

I don't think the script made any bad decisions, but these random events are kind of ridiculous.
 
Good thing the script used adventures more freely. Those random adventures can get pretty bad.

Since I didn't get any complaints on the script, I've updated the version. :)
 
Good thing the script used adventures more freely. Those random adventures can get pretty bad.

Since I didn't get any complaints on the script, I've updated the version. :)


eegeee first thanks for this script. I have been trying to nail the trophy for my main and multi. I think I reached day 9 on my main and then it died >.>

Now I am running your script hands off to see if it can pull off the 11 day miracle :)
 
Great, I'm also using the script hands off right now. I hope to eventually add 'ability to reach 11-days' to the description.
 
So I ran 0.4 today, and I noticed a strange choice of priorities to increase stats. Shouldn't the stat at '1' be chosen to be increased first for example? Also, shouldn't the '2's be increased first before a 3? Also I noticed that only adventures are being used...

Code:
Checking for updates (running ChibiParent ver. 0.4)...
Running ChibiParent version: 0.4 (current)
You have the latest ChibiBuddy.txt. Will not check again today.
Obtaining ChibiChanged�..
You acquire an effect: ChibiChanged™ (duration: 40 Adventures)
--- Current Stats ---
Socialization: 1
Intelligence: 2
Alignment: 2
Fitness: 7
--- Total dots: 12 ---
ADVENTURING to increase 'Alignment'.
Countdown: 5 seconds...
Countdown: 4 seconds...
Countdown: 3 seconds...
Countdown: 2 seconds...
Countdown: 1 second...
Waiting completed.
Results:*You and Rocket Sled go to a museum of modern art. You expect him to head straight for the ChibiNudes™, but he spends a lot of time with the Impressionist stuff, uplifted by the beauty all around him.
_chibibuddyAdventuresUsed => 1
--- Current Stats ---
Socialization: 1
Intelligence: 2
Alignment: 3
Fitness: 7
--- Total dots: 13 ---
ADVENTURING to increase 'Socialization'.
Countdown: 5 seconds...
Countdown: 4 seconds...
Countdown: 3 seconds...
Countdown: 2 seconds...
Countdown: 1 second...
Waiting completed.
Results:*You give Rocket Sled a 1,000 piece puzzle. He gets so bored trying to put it together that he calls a bunch of ChibiFriends™ and goes out drinking instead. He kind of resents the implication that you thought the puzzle would entertain him.
_chibibuddyAdventuresUsed => 2
--- Current Stats ---
Socialization: 1
Intelligence: 2
Alignment: 3
Fitness: 7
--- Total dots: 13 ---
ADVENTURING to increase 'Socialization'.
Countdown: 5 seconds...
Countdown: 4 seconds...
Countdown: 3 seconds...
Countdown: 2 seconds...
Countdown: 1 second...
Waiting completed.
Results:*You give Rocket Sled a 1,000 piece puzzle. He gets so bored trying to put it together that he calls a bunch of ChibiFriends™ and goes out drinking instead. He kind of resents the implication that you thought the puzzle would entertain him.
_chibibuddyAdventuresUsed => 3
--- Current Stats ---
Socialization: 2
Intelligence: 2
Alignment: 3
Fitness: 7
--- Total dots: 14 ---
ADVENTURING to increase 'Alignment'.
Countdown: 5 seconds...
Countdown: 4 seconds...
Countdown: 3 seconds...
Countdown: 2 seconds...
Countdown: 1 second...
Waiting completed.
Results:*You and Rocket Sled go to a museum of modern art. You expect him to head straight for the ChibiNudes™, but he spends a lot of time with the Impressionist stuff, uplifted by the beauty all around him.
_chibibuddyAdventuresUsed => 4
--- Current Stats ---
Socialization: 2
Intelligence: 2
Alignment: 3
Fitness: 7
--- Total dots: 14 ---
ADVENTURING to increase 'Alignment'.
Countdown: 5 seconds...
Countdown: 4 seconds...
Countdown: 3 seconds...
Countdown: 2 seconds...
Countdown: 1 second...
Waiting completed.
Results:*You and Rocket Sled go to a museum of modern art. You expect him to head straight for the ChibiNudes™, and he does, but he seems to have a genuinely transcendent appreciation of their aesthetics.
_chibibuddyAdventuresUsed => 5
Finished running ChibiParent

--- Current Stats ---
Socialization: 2
Intelligence: 2
Alignment: 4
Fitness: 7
--- Total dots: 15 ---

Total times adventured: 5
Total times balanced: 0
Total actions taken: 5

Code:
zlib chibiParent_allowAdventuring = true
zlib chibiParent_allowBalancing = true
zlib chibiParent_allowDynamicBounds = true
zlib chibiParent_haveChat = true
zlib chibiParent_irresponsible = false
zlib chibiParent_maxStatLevel = 8
zlib chibiParent_maxTotalDistance = 2
zlib chibiParent_minStatLevel = 2
zlib chibiParent_optimalStat1 = 4
zlib chibiParent_optimalStat2 = 4
zlib chibiParent_optimalStat3 = 6
zlib chibiParent_optimalStat4 = 6
zlib chibiParent_pause = 5
 
The script decided to go for Alignment since it was furthest stat from its optimal value. With those stats, Alignment needed 4 levels to get its optimal level of 6 whereas only Socialization needed 3 levels to get to its optimal of 4. This happen once again after Alignment was increased. I realise that this might seem counter-intuitive, but if each adventure had managed changed a level (but didn't do to sub-stat points) the final stats would have been [3, 3, 4, 7] which isn't bad.

On all accounts the risk of balancing, without being able to correct random events with adventures, would have been too great. The main condition that triggered this behaviour of adventuring instead of balancing is chibiParent_maxTotalDistance. The total dots were 8 points away from 20 at the start of the script and 5 points away from 20 at the end of the script. If say, the max distance was 6 instead of 2, then the script would have tried to balance when your stats were [2, 2, 3, 7] (total 14), but only if dynamic bounds were disabled. Otherwise with dynamic bounds enabled, the dynamic max total distance would have been adjusted to 5 since four adventures had already been used.

I hope this clarifies the script's strange behaviour.
 
i know zero scripting, is there an easier/better way to set ChibiChat to a dailydeed?
i have a text file that contains:
Code:
zlib chibiParent_haveChat = true;
chibiparent;
zlib chibiParent_haveChat = false;

and i made a 1 use custom daily deed button to run this txt file.

i have chibiparent running in my login script, and i dont always want chibichat right away so i set it in zlib to false so chibiparent will run on login and balance my chibi without chatting
 
Damn another one died. Socialization was at 10 when I logged on. Sigh, try again one more time then I am going back to hardcore for a while :)
 
The script decided to go for Alignment since it was furthest stat from its optimal value.

I suspect that this is not the best approach (though the difference is mostly academical in this particular case).
Brain dump follows:
1) "4,4,6,6" is only called "optimal" because it's the best ending position *given that the sum is 20*. If you get bad random events and/or use many adventure consuming options, you can alter the total.
2) when choosing stat to alter, what actually matters is how far the stat is from *dying*, not from any given position. A stat of 1 is 1 removed from dying, and so is a stat of 9.
In this case, alignment 2 with goal 6 was 2 away from dying, and therefore not as important to change as socialization 1 with goal 4 and 1 away from dying.
3) for optimality, you want the following, in order of priority (most important first):
- so that your chibi doesn't die next day: all stats far enough from 0 and 10 (by at least as much as many rollover events can affect 1 stat plus one - I want to say "at least 3 and at most 7", but maybe it's 2/8 or 4/6; but in any case, having any stat at 1 or 9 is much more dangerous than not having any such stat, so that's what you want to fix first)
- so that you can better balance your stats for the day after next day: two stats at least 5 (or 6? wiki used to say that having 5 results in random increases in that stats, but now I only see "over 5 " and "under 5" with no mention of what happens when you have exactly 5) and two below; this will maximize expected balance of random events (which means you will have to spend less adventures bringing your stats back to balance)
4) if you use the previous two rules instead of always "prefer the one that's futhermost away from its goal", you would just revert the order of the first two steps in this particular case (which would be the more intuitive behavior), but what if you only had 1 adventure left? In that case, increasing alignment first would have been irresponsible.
 
@charred
Lastest update makes it easier to use a daily deed. I added info to the first post.

@Tom Sawyer
Yeah, sucks to login to find a dead buddy.

@xKiv
Having the optimal stats at [5, 5, 5, 5] is better when only using adventures and [4, 4, 6, 6] is better when using balancing (with/without adventuring). This is because when only using adventures, it is better to have the stats as close as possible to the median (consequently 5). On the other hand, when balancing it is better to have the stats evenly spread above and below the median.

What you're basically saying in the 'brain dump' is that you would prefer adventuring to happen as if the optimal stats were [5, 5, 5, 5] instead of the default [4, 4, 6, 6]. What I've done now is, during adventuring, to fix the stat furthest from 5 that is not already optimal. Hope you don't mind the frequency of the updates. :)
 
2 out of my 4 buddies died today using only this script (version 0.4). I think that if you get to the point where you can only use adventures, maybe you should adjust the targets from 4,4,6,6 to 5,5,5,5 automatically? Just trying to think of ideas to help the script keep buddies alive.
 
Last edited:
What you're basically saying in the 'brain dump' is that you would prefer adventuring to happen as if the optimal stats were [5, 5, 5, 5] instead of the default [4, 4, 6, 6].

Definitely not this.
Depending on how 5 works, and how many stats you actually get to 5, going for [5,5,5,5] could be very very bad; if 5 always goes up and you get all 4 to 5, you just guaranteed maximal imbalancing ( [4,4,5,5] would be optimal in that case, in the sense where optimal = furthest away from expected death). Or 5 never increasesor decreases randomly, but you only managed [4,4,5,5] and thus (probably) guaranteed that those two 4s will get reduced without counterbalancing that with a corresponding increase. Or something else.
Does anybody *know* how 5 behaves? (in "morning" random effects *and* in "balancing" choices - those two might work differently, as far as I know).

What I've done now is, during adventuring, to fix the stat furthest from 5 that is not already optimal. Hope you don't mind the frequency of the updates. :)
This is not what I am saying either, but it's mathematically equivalent (at least if the "furthest from 5" stat is 1 or 9), so it's reasonably close.

(I would go first for increasing any 1s and decreasing any 9s,
then maybe increasing 2s and decreasing 8s (but I am not sure if this is optimal - maybe just skip directly to "balance to optimal"
then maaaaaybe increasing 3s and decreasing 7s? (probably not optimal)
-- at this point, you have staved off almost certain death, and maybe even possible death
then "balance to optimal" - pick goals for stats and nudge the ones that are furthest away from their goal
)
 
Of my two buddies that died... one of them had a stat at 8 that jumped to 10, the other had a stat at 2 that jumped to 0. So I agree with xKiv's idea above. To prioritize 1,9's first, then 2's, 8's, etc..
 
..what actually matters is how far the stat is from *dying*..
..you would prefer adventuring to happen as if the optimal stats were [5, 5, 5, 5].. to fix the stat furthest from 5 ..
Definitely not this..
Definitely yes, I think you misunderstood. What I'm saying is what I'm sure you meant.

The script not aiming for five, unless it happens to be set as a optimal value. The script is optimizing the stat closest to death (corollary: stat furthest from 5) towards its optimal value.


..I would go first for increasing any 1s and decreasing any 9s, (already happens by default using only adventures)
then maybe increasing 2s and decreasing 8s (but I am not sure if this is optimal - maybe just skip directly to "balance to optimal" (already balances by default unless deemed unwise)
then maaaaaybe increasing 3s and decreasing 7s? (probably not optimal) (same as above with 2s & 8s)
..
then "balance to optimal" - pick goals for stats and nudge the ones that are furthest away from their goal (if the script is at / got to this point with sufficient adventures left, it will happily balance if allowed)
Comments above in bold. So the script is practically doing what you said above.

..if you get to the point where you can only use adventures, maybe you should adjust the targets..
I'm not sure when one could only use adventures? Balancing is always an option.
But if balancing is allowed, then I don't think the optimal stats should be adjusted. This is because one would still like to balance the next day.

Of course if only adventuring is allowed, then the optimal stats should be set [5, 5, 5, 5].


..prioritize 1,9's first, then 2's, 8's, etc..
This is what the script is trying to do :)
 
Definitely yes, I think you misunderstood. What I'm saying is what I'm sure you meant.

The script not aiming for five, unless it happens to be set as a optimal value. The script is optimizing the stat closest to death (corollary: stat furthest from 5) towards its optimal value.

Still no.
Only for when they are 1,2,8,9. If no stat is 1,2,8 or 9, then you can adjust by distance towards [4,4,6,6] (or whatever else might be set as optimal) even when adventuring. Because "remove danger of imminent death" is only a binary priority - either you have the danger and removing it is more important than anything else, or you are not in danger and some other priority can becomes top prriority.
(plus, I wasn't even sure about including 2,8 in that).

So your script might be doing what I mean, but not what I think you say I mean. I think.

Of course if only adventuring is allowed, then the optimal stats should be set [5, 5, 5, 5].
Again, depends on what random events happen to stats that are 5.
If random events always increase 5, then [5,5,5,5] might overnight randomly become [6,6,6,5] (or more?) which is harder to balance. (of course, [4,4,6,6] might have become, what, [4,3,7,7] under the same "hits"?)
If random events never do anything to a 5, then going towards [5,5,5,5] might leave you with, say [6,6,5,5] (because you just didn't have anough adventures and couldn't rebalance to all 5), which will only get worse, again.
With what I know, going for [4,4,6,6] (after you eliminate sudden death) is the best *known to be safe* goal.
 
..either you have the danger and removing it is more important than anything else, or you are not in danger and some other priority can becomes top prriority..
..script might be doing what I mean.. I think
Even though the script is now avoiding danger always, it it also always trying to move towards optimum. So because of this the script will, in effect, first avoid danger and then prioritize for optimum stats.
With all this thinking, I hope I've better explained myself now. :) Otherwise shoot away and I'll get back to you tomorrow.

..depends on what random events happen to stats that are 5..
From Talk:How_to_Chibi, it seems that if a stats is 5, it has an equal chance to go in either direction.
They do say there that [5, 5, 5, 5] is better when only adventuring.
 
Even though the script is now avoiding danger always, it it also always trying to move towards optimum. So because of this the script will, in effect, first avoid danger and then prioritize for optimum stats.
With all this thinking, I hope I've better explained myself now. :) Otherwise shoot away and I'll get back to you tomorrow.

That *is* what I meant.

From Talk:How_to_Chibi, it seems that if a stats is 5, it has an equal chance to go in either direction.
They do say there that [5, 5, 5, 5] is better when only adventuring.

OK. That means [5,5,5,5] is better (expected balance change=0 *and* futher away from death) if you can guarantee that you will end at [5,5,5,5]. That is, if you can guarantee the sum (if you can't then you might end up at something like [4,5,5,5], which has negative expected balance change, which you don't want).


Actually, I had another thought about what might be preferable to "scoring goals": if you have three low stats and one high, and are already safe-ish (the high stat is 7 or lower and the low stats are both at least 3), increasing one of the low stats (you know which - the highest one, or one of the threes if they are all 3) should be prefered over any other, even if they are the same distance from their goal, for future-balancing reasons (want to have two non-low and two non-high).
Example: with goal [5,5,5,5], stats [3,3,4,6] have distances [2,2,1,1], but you probably want to increase the 4 first to improve expected (tommorow's) balance change (by 0.5?).
With goal [4,4,6,6], stats [3,3,5,7] have distances [1,1,1,1], but you probably still want to increase the 5 first (to improve expected balance change by 0.5?).
(and vice versa for three high, one low)
Thought?
 
Of my two buddies that died... one of them had a stat at 8 that jumped to 10, the other had a stat at 2 that jumped to 0. So I agree with xKiv's idea above. To prioritize 1,9's first, then 2's, 8's, etc..

I think mine actually did both simultaneously. It seems that once your stats get too far from the middle, you either need a major lucky streak with balancing, or it's inevitably going to die in a few days. But, again, this isn't really the script's fault so much as the fact that balancing is a risky gamble.

For my resurrected Buddy, I've changed the settings to never attempt balancing, which should prevent random events from making the stats drift too far...of course, the problem with only using adventures is that there may not be enough to keep it optimized. If that turns out to be the case, I'll probably just sell the damned thing, because that would mean it just isn't possible to keep it alive indefinitely (with my horrendous luck, anyway).
 
..another thought about what might be preferable to "scoring goals"
..stats [3,3,4,6] ..probably want to increase the 4
..stats [3,3,5,7] ..probably still want to increase the 5
..Thought?
I actually like that alternate way. I've gone ahead and implemented it using 'priorities'.

How this will work is say you have [a1, a2, b1, b2] then have priorities in increasing order for [a, b]:
  1. [3, 7]
  2. [>=5, <=5]
  3. [2, 8]
  4. [1, 9]
(so from your example [3, 3, 5, 7] -- b1=5 has a priority of 2 which is larger than all the other a's & b's which have a priority of 1)


The highest priority is used to determine which stat to adventure for, and priorities are only used in adventuring when allowed to balance. Otherwise adventuring will fix for the stat furthest from 5.

I'm also using the highest priority and spread to determine if balancing (if allowed) is a good idea. The max highest priority starts at 4 and will be reduced if dynamic bounds are enabled. The spread checks for at least two stats above and below 5 including 5 both ways.
As always balancing will use a1 & b2 unless they are optimal, in which case a2 & b1.

This replaces the min/max stat level variables along with the max total distance variable.
The ability to set custom optimal levels has also been removed. If balancing is allowed the optimum is [4, 4, 6, 6] otherwise [5, 5, 5, 5].

EDIT: removed attachment since latest version includes all these changes
 
Last edited:
Back
Top