Ren'Py Project: Possible [Patch 17a] [Leroy2012 & Muplur]

[Johnboi649]

First page, Changelog: .

But it doesn't say exactly what the new scenes are

 

[Leks Darkmind]

Thank You! a fine quest system this is!
but the mall is shiny. empty, but shiny. must be my old savegame, but maybe check?
and maybe add page counter in gallery? and shops?

 

[Leroy2012]

New update dropped.

10 minutes of content after a month.

Bruh.

No. You're probably just on the wrong paths. It literally says at the start that this might be the case.

 

[95zuser99031]

Tara, and some Kim, art looks fucking weird. Alls fine then I see some new and its "eugh what the fuck".

 

[Agisti31]

I want to ask? is there an animated sex scene or not?

 

[MaienM]

I think I found a softlock. I'm at taraquest3step26 and shegoquest5step22 (as in I've done those but not the next step in the corresponding quests). At this point Tara's quest needs to progress before Shego's will, but the logic that triggers this event calls taraRandomEventOrder which (with events_left() == 2, ensureShegoQuest == 10 and Shego.counter = 20) can never return true (getRandNumber(100) will never result in something smaller than -20). I think the logic of taraRandomEventOrder might need some work (or maybe it shouldn't be used for this event). (Note also that the current implementation of this method will result in a ZeroDivisionError when ensureShegoQuest == Shego.counter.)

 

[Leroy2012]

I think I found a softlock. I'm at taraquest3step26 and shegoquest5step22 (as in I've done those but not the next step in the corresponding quests). At this point Tara's quest needs to progress before Shego's will, but the logic that triggers this event calls taraRandomEventOrder which (with events_left() == 2, ensureShegoQuest == 10 and Shego.counter = 20) can never return true (getRandNumber(100) will never result in something smaller than -20). I think the logic of taraRandomEventOrder might need some work (or maybe it shouldn't be used for this event). (Note also that the current implementation of this method will result in a ZeroDivisionError when ensureShegoQuest == Shego.counter.)

I'm not at all sure what you're saying ^^'

But it sounds like a bug. If you have a solution for it I'd be happy if you posted it. Otherwise I'm not entirely sure how to wrap my head around your comment

 

[MaienM]

It is a bug, yes. The core of it is that in certain conditions it is impossible for taraRandomEventOrder to ever return True, which can lock you out of events. Below is an implementation of this function which preserves most of the existing logic but which does not suffer from the mentioned bugs. The max(chance, 10) on the last line ensures that there is always at least a 10% chance for this function to resolve to True, which avoids ever getting into a situation where you're locked out.

def taraRandomEventOrder():
    shego = float(ensureShegoQuest) - float(Shego.counter)
    chance = (float(events_left()) / min(shego, 1)) * 100
    return getRandNumber(100) < max(chance, 10)

 

[Leroy2012]

It is a bug, yes. The core of it is that in certain conditions it is impossible for taraRandomEventOrder to ever return True, which can lock you out of events. Below is an implementation of this function which preserves most of the existing logic but which does not suffer from the mentioned bugs. The max(chance, 10) on the last line ensures that there is always at least a 10% chance for this function to resolve to True, which avoids ever getting into a situation where you're locked out.

def taraRandomEventOrder():
    shego = float(ensureShegoQuest) - float(Shego.counter)
    chance = (float(events_left()) / min(shego, 1)) * 100
    return getRandNumber(100) < max(chance, 10)

I still can't say I quite understand the specific problem, however, I'll add this code and then hopefully you're just right. I do kinda regret the whole randomness aspect to Tara's events

Edit: I'm not in charge of updating the files here, so if you want me to fix your save you can just send it. Though I feel like you know how to just fix it yourself ^^'

 

[Grim2.o]

Can anyone give a full save?

 

[sleepingkirby]

I still can't say I quite understand the specific problem, however, I'll add this code and then hopefully you're just right. I do kinda regret the whole randomness aspect to Tara's events

Don't put in code you don't understand. You might, unwittingly, introduce exploits and/or flaws into your code.

Basically, what MaienM is saying is that Shego.counter can get really high. In the function of

    def taraRandomEventOrder():
        return getRandNumber(100) < (float(events_left()) / (float(ensureShegoQuest) - float(Shego.counter))) * 100

If Shego.counter is higher than ensureShegoQuest, then this part:

(float(events_left()) / (float(ensureShegoQuest) - float(Shego.counter))

Will return a negative number. (Since any positive number divided by a negative will return a negative number)

And since getRandNumber(100) only returns numbers between 0 and 99, the random events for Tara (taraRandomEventOrder()) will never fire.

But also, since ensureShegoQuest and Shego.counter can be the same value, you might end up dividing by 0.



What MaienM is proposing is that the lower end of:

float(ensureShegoQuest) - float(Shego.counter)

should be capped at 1 since:

min( -9999, 1)

will return 1.

Conversely:

max(9999,10)

Will return 10. Which gives you a 90% chance of the random Tara event firing.

 

[CallmeShaw]

Can someone tell me about how long it would take to play through the current content?

I played from start to finish reading the dialogues, it took a few hours of gameplay, skipping the dialogues maybe 1-2 hours of gameplay

 

[Leroy2012]

Don't put in code you don't understand. You might, unwittingly, introduce exploits and/or flaws into your code.

Basically, what MaienM is saying is that Shego.counter can get really high. In the function of

    def taraRandomEventOrder():
        return getRandNumber(100) < (float(events_left()) / (float(ensureShegoQuest) - float(Shego.counter))) * 100

If Shego.counter is higher than ensureShegoQuest, then this part:

(float(events_left()) / (float(ensureShegoQuest) - float(Shego.counter))

Will return a negative number. (Since any positive number divided by a negative will return a negative number)

And since getRandNumber(100) only returns numbers between 0 and 99, the random events for Tara (taraRandomEventOrder()) will never fire.

But also, since ensureShegoQuest and Shego.counter can be the same value, you might end up dividing by 0.



What MaienM is proposing is that the lower end of:

float(ensureShegoQuest) - float(Shego.counter)

should be capped at 1 since:

min( -9999, 1)

will return 1.

Conversely:

max(9999,10)

Will return 10. Which gives you a 90% chance of the random Tara event firing.

Oh, I understood the code itself. It's the exact place the bug is that I can't really figure out.

Thanks for the explanation though. I do wonder how exactly I ended up making it a negative number... Having to juggle visuals, posing, writing and coding just creates weird issues ^^'

 

[sleepingkirby]

Oh, I understood the code itself. It's the exact place the bug is that I can't really figure out.

Ahh, sorry. I'm very use to having to explain programming stuff from the very beginning.

Thanks for the explanation though. I do wonder how exactly I ended up making it a negative number...

My guess is that, at one point, you intended for Shego.counter to only have a max value of 3 or 4.

./game/events/shegoevents/shegoquest1.rpy:366:    $ Shego.setcounter(0) #up to 3-4

The math would have been okay (or eventually okay) if it stayed that low. But all the Character.counters increment every night unbounded. And unbounded numbers will almost always cause problems eventually.

The only thing I can say is, as a rule of thumb, in programming, I tend to avoid divisions. If there's another mathematical way to represent the same idea without division, I try to do it unless I'm heavily checking the denominator. Like, in this case, I would have multiplied the Shego.counter to the randomly generated number before I would have used it to subtract from a divisor. Numbers approaching infinity (divide by zero) or approaching 0 (when the divisor is infinitely large) is always a very real concern in my mind. >.<

 

[Leroy2012]

Ahh, sorry. I'm very use to having to explain programming stuff from the very beginning.


My guess is that, at one point, you intended for Shego.counter to only have a max value of 3 or 4.

./game/events/shegoevents/shegoquest1.rpy:366:    $ Shego.setcounter(0) #up to 3-4

The math would have been okay (or eventually okay) if it stayed that low. But all the Character.counters increment every night unbounded. And unbounded numbers will almost always cause problems eventually.

The only thing I can say is, as a rule of thumb, in programming, I tend to avoid divisions. If there's another mathematical way to represent the same idea without division, I try to do it unless I'm heavily checking the denominator. Like, in this case, I would have multiplied the Shego.counter to the randomly generated number before I would have used it to subtract from a divisor. Numbers approaching infinity (divide by zero) or approaching 0 (when the divisor is infinitely large) is always a very real concern in my mind. >.<

You know whats funny? I legit don't remember even doing that math.

I generally try to avoid doing math with more than 2 numbers when I do code, so I'm frankly confused about how and when I even made this. Especially cause it would have made much more sense to figure out a way where you either use * or %.

You're right that unbounded numbers can cause issues xD But the way I made this, this number was never intended to be used for anything other than exactly a counter (that is to say, it wasn't supposed to be used for math). Nothing ever checks if it is between something, only if it is higher than (or lower than, to prevent stuff for a bit), in which cases unbounded causes no real issues.

Hopefully this will fix it though. Math is unfortunately not my strong suit and it never has been. I only really understand math when I sit with it, I can't just understand it at a glance.

 

[JoleenStar]

Was fun. Thank god for cheats. I was more invested in Shego than anything else.

 

[sleepingkirby]

You know whats funny? I legit don't remember even doing that math.

I generally try to avoid doing math with more than 2 numbers when I do code, so I'm frankly confused about how and when I even made this. Especially cause it would have made much more sense to figure out a way where you either use * or %.

You're right that unbounded numbers can cause issues xD But the way I made this, this number was never intended to be used for anything other than exactly a counter (that is to say, it wasn't supposed to be used for math). Nothing ever checks if it is between something, only if it is higher than (or lower than, to prevent stuff for a bit), in which cases unbounded causes no real issues.

Hopefully this will fix it though. Math is unfortunately not my strong suit and it never has been. I only really understand math when I sit with it, I can't just understand it at a glance.

That is kind of funny, and a little worrying if you legit don't remember doing the math. Are you working too fast or spreading yourself too thin? Do you have this code on a private repo? Maybe something like git repo where you have to do commits with messages will keep note of things/organized.

The new math will definitely fix the bug. Whether or not it'll do what you intended (because, no one other than the person themselves can truly ever know one's true intentions) is another matter.
The new calculation's will start at 600% for (assuming the denominator is 1) when Tara's random event will happen. As each event happens, that'll go down by 100% until it hits zero. But since the denominator ranges any where from 1 to 14 at the most, the percentage (other than 0 %) can range from 600% to 42% when you still have all of Tara's events, to 100% to 7.14% when you have only 1 of Tara's event. But since there's a max(chance, 10). You can only get a 600% to a 10% chance of an event firing (originally wrote this wrong. MaienM corrected me)

So with all 6 of Tara's event available, there's a 10% of them firing. With 1 of Tara's event available, there's a 7.14% of it firing.

A side tangent. I just noticed this.
script.rpy at line 586-587:

        # Multiply the remaining days count by 1
        return remaining_days * 1 + 7

Any number multiplied by 1 is itself so multiplying by 1 doesn't do anything. It has no affect on the game, but yeah, this might a sign you might be working too fast or spreading yourself too thin.

 

[spitfire335]

The new Bonnie scenes were great. Romancing a girl like her is always interesting.

 

[MaienM]

But since there's a max(chance, 10). You can only get a 10% chance of an event firing (I read the percentages wrong on my full explanation. My apologies).

So with all 6 of Tara's event available, there's a 10% of them firing. With 1 of Tara's event available, there's a 7.14% of it firing.

This isn't correct. The max(10, chance) sets a lower bound on the chance for an event to fire, not an upper bound (this function simply returns the highest of the passed in numbers). So if the calculated chance is higher than 10% that will be returned, if it's lower it'll return 10%. max(10, 42) == 42 and max(10, 7.14) == 10.

 

[sleepingkirby]

This isn't correct. The max(10, chance) sets a lower bound on the chance for an event to fire, not an upper bound (this function simply returns the highest of the passed in numbers). So if the calculated chance is higher than 10% that will be returned, if it's lower it'll return 10%. max(10, 42) == 42 and max(10, 7.14) == 10.

Ahh,so I did read it correctly last time. Post corrected. Thank you.