VN Ren'Py Completed Battle of the Bulges [v1.0] [EpicLust]

[Dracodadark]

Hey Dev,

not a critique but something I thought would be fun. I think it it would be hilarious to see Jose’s reaction after you send him each conquest, especially his mom. Just a thought other than that I have no complaints.

 

[sjackson3939]

Hey Dev,

not a critique but something I thought would be fun. I think it it would be hilarious to see Jose’s reaction after you send him each conquest, especially his mom. Just a thought other than that I have no complaints.

This has been suggested before but 1) basically ntr which Tim is not a fan of, 2) too much work unless it's just the same Jose angry face everytime. So unlikely Tim would do this and has been against it in the past.

Edit: actually if anyone wants this, what you could do is use the phone screens Jose sends you and change the Sprite to Jose adding your own dialogue. You would then have to insert it in the script after you achieved that specific girl which depending on the character could be over 3 or 4 scripts. Problem is you would need to redo it everytime Tim updates that script.

 

[EpicLust]

This has been suggested before but 1) basically ntr which Tim is not a fan of, 2) too much work unless it's just the same Jose angry face everytime. So unlikely Tim would do this and has been against it in the past.

Actually, that wouldn't be NTR since we are talking about José being pissed off I suppose I could do a single pic for when the MC fucks Anna... As a one-off.

 

[Dracodadark]

Actually, that wouldn't be NTR since we are talking about José being pissed off I suppose I could do a single pic for when the MC fucks Anna... As a one-off.

I just thought it would be some extra comedy that would certainly make me laugh. Love the game though and keep up the great work.

 

[Mattock]

new mini-game: find the flying saucer!
(spoiler)

Spoiler

You don't have permission to view the spoiler content. Log in or register now.

afaik that's number two, I'm anxious to know how many more are hidden. *grin

have fun(I did!) Mattock



feedback for timdonehy200: be warned!...a LOT of text!
about updates -wishes(1)-(spoiler)

Spoiler

You don't have permission to view the spoiler content. Log in or register now.

errors I encountered while playing 0.5.1(spoiler)

Spoiler

You don't have permission to view the spoiler content. Log in or register now.

-wishes(2)-(gui.show_name and voice-playback)(spoiler)

Spoiler

You don't have permission to view the spoiler content. Log in or register now.

EDIT: what I wanted to say about my "voice-playback-wish" but somehow omitted,
is that this is a wish for your NEXT game!..

 

[djskiddy1]

Anyone have a quick summary for Chantelle or is it not possible through the 5 days?

 

[zapallbugs]

Anyone have a quick summary for Chantelle or is it not possible through the 5 days?

Unfortunately Chantelle is not possible for V.0.5. But she likely will be on day 6 with the beauty pageant.

 

[EpicLust]

2nd wish: please roll out the .rpyc you've created with your .rpy (also)
(for overall-compatibility-reasons imho the bytecode is more valuable than the source)[/spoiler]

I'm afraid I have no idea what you mean. How do I do that???

 

[zapallbugs]

I'm afraid I have no idea what you mean. How do I do that???

He means the compiled objects that are compiled from source when you start the game. I think he means that the source has codepage dependencies that the objects don't. So in theory you could run from the rpyc's on a platform that hase codepage issues with the source. I think. @Mattock correct me if I am wrong.

Edit: I have 40+ years experience as a programmer. Situations where the objects are more valuable then the source are very rare. And when you want to make changes you always need to go back to source. If you only trust objects you need a process that decompiles/disassembles them back in to source. For Renpy that is the unren tool. But you almost always loose something in that process. I have never encountered a situation where source wasn't better. As long a you have the system to compile those sources again

 

[EpicLust]

He means the compiled objects that are compiled from source when you start the game. I think he means that the source has codepage dependencies that the objects don't. So in theory you could run from the rpyc's on a platform that hase codepage issues with the source. I think. @Mattock correct me if I am wrong.

Edit: I have 40+ years experience as a programmer. Situations where the objects are more valuable then the source are very rare. And when you want to make changes you always need to go back to source. If you only trust objects you need a process that decompiles/disassembles them back in to source. For Renpy that is the unren tool. But you almost always loose something in that process. I have never encountered a situation where source wasn't better. As long a you have the system to compile those sources again

Err... That's still another language to me guys... What am I supposed to actually DO?
Like, for example, when I make the update v0.6, I was thinking of sending files in a similar manner to v0.5.1 (ie; NOT the whole game). Should I include the .rpyc files or not?

 

[Mattock]

[...]
Situations where the objects are more valuable then the source are very rare.[...]

Err... That's still another language to me guys... Whatam I supposed to actually DO?
Like, for example, when I make the update v0.6, I was thinking of sending files in a similar manner to v0.5.1 (ie; NOT the whole game). Should I include the .rpyc files or not?

As said, as a wish, I would like you to include all your *.rpy and all *.rpyc-files. It is not required.
zapallbugs is of course correct! my reason for wanting the bytecode is most likely renpy-specific.

(and "more valuable" was not a good term) (trying to put it simple: )
There is a "context" stored in savegames of the bytecode-files. If you exchange savegames from different bytecodes, though from the exact same source, renpy uses a "fail-safe"(which mostly works fine, but error is not impossible) because the "context" is different. This also aplies to the "list of all dialogs you have been seen", upon which is decided if you can skip already read text.
...also having both is a safety if one of them would be corrupt

EDIT: (QUOTE=timdonehy200) Corrected most of the bugs you mentioned too.
WOW!

 

[EpicLust]

As said, as a wish, I would like you to include all your *.rpy and all *.rpyc-files. It is not required.
zapallbugs is of course correct! my reason for wanting the bytecode is most likely renpy-specific.

(and "more valuable" was not a good term) (trying to put it simple: )
There is a "context" stored in savegames of the bytecode-files. If you exchange savegames from different bytecodes, though from the exact same source, renpy uses a "fail-safe"(which mostly works fine, but error is not impossible) because the "context" is different. This also aplies to the "list of all dialogs you have been seen", upon which is decided if you can skip already read text.
...also having both is a safety if one of them would be corrupt

OK, I'll do that then! Corrected most of the bugs you mentioned too.
Cheers and thanks for the help!

 

[zapallbugs]

As said, as a wish, I would like you to include all your *.rpy and all *.rpyc-files. It is not required.
zapallbugs is of course correct! my reason for wanting the bytecode is most likely renpy-specific.

(and "more valuable" was not a good term) (trying to put it simple: )
There is a "context" stored in savegames of the bytecode-files. If you exchange savegames from different bytecodes, though from the exact same source, renpy uses a "fail-safe"(which mostly works fine, but error is not impossible) because the "context" is different. This also aplies to the "list of all dialogs you have been seen", upon which is decided if you can skip already read text.
...also having both is a safety if one of them would be corrupt

EDIT: (QUOTE=timdonehy200) Corrected most of the bugs you mentioned too.
WOW!

Hi Mattock, just curious as I am not a Renpy specialist. Do you mean to say that the *same* source when compiled on different platforms (or maybe different versions of the Renpy system) results in different bytecodes? That would put a stop to portability, so I really hope that is not the case.

 

[Mattock]

Hi Mattock, just curious as I am not a Renpy specialist. Do you mean to say that the *same* source when compiled on different platforms (or maybe different versions of the Renpy system) results in different bytecodes? That would put a stop to portability, so I really hope that is not the case.

Hello zapallbugs,
it is not as hard as "stopping portability" in general!, it is more like "breaking portability of savegames("pickle")"
and don't get me wrong! I'm far from understanding everything that happens there!

With the same source you can create the same game! that is granted!(with same renpy-version of course)
...but; with the same source created likely bytecode will not result in exact same "savegames"(renpy-c-pickle)
(that is from observation of mine and looking into docs and sources alot but I have to admit the overall function/working of "pickle" somehow elude me...)

 

[zapallbugs]

Hello zapallbugs,
it is not as hard as "stopping portability" in general!, it is more like "breaking portability of savegames("pickle")"
and don't get me wrong! I'm far from understanding everything that happens there!

With the same source you can create the same game! that is granted!(with same renpy-version of course)
...but; with the same source created likely bytecode will not result in exact same "savegames"(renpy-c-pickle)
(that is from observation of mine and looking into docs and sources alot but I have to admit the overall function/working of "pickle" somehow elude me...)

Hi Mattock,
so the problem you are pointing at is that saves are only 100% compatible for the same set of bytecode objects. And that when the source is recompiled (for whatever reason) the resulting bytecodes may not be 100% identical? Sounds like saves contain physical memory dumps without regard for the logical content of said memory. If saves had purely logical content sequence and alignment rules wouldn't matter.
(sorry Tim, for going into geek speek. Just trying to understand Mattocks worries)

 

[Mattock]

[...]so the problem you are pointing at is that saves are only 100% compatible for the same set of bytecode objects. And that when the source is recompiled (for whatever reason) the resulting bytecodes may not be 100% identical[...]

sorry @Tim too for geek speek
as said, I'm not an expert!, but from my understanding, it is quite as you say, but not as critical as you may think...
!what I think!: source.rpy gets converted to bytecode.rpyc AND there is a reference to the PATH the source was, e.g. C:\game\source.rpy and it gets a time-stamp too when the bytecode was created; this is part of what I understand as "context"(?)
those both informations go into the "store" when you save a game
upon loading a game renpy compares in what "context" it is now...and if it is different from the one from the "savegame" e.g. no matter where you were in a "label" you will be sent to the start of that label("fail-safe")(never tried what happens if that label just don't exist in this game...suppose an exception)

EDIT: your (under this) post helped me in understanding too! thx

 

[zapallbugs]

sorry @Tim too for geek speek
as said, I'm not an expert!, but from my understanding, it is quite as you say, but not as critical as you may think...
!what I think!: source.rpy gets converted to bytecode.rpyc AND there is a reference to the PATH the source was, e.g. C:\game\source.rpy and it gets a time-stamp too when the bytecode was created; this is part of what I understand as "context"(?)
those both informations go into the "store" when you save a game
upon loading a game renpy compares in what "context" it is now...and if it is different from the one from the "savegame" e.g. no matter where you were in a "label" you will be sent to the start of that label("fail-safe")(never tried what happens if that label just don't exist in this game...suppose an exception)

Ah, now it is getting understandable. A save consists of a variable area and a jump-to point at the time of the save. The problem is in the jump-to point, not the variable area. I can't see the source path being too relevant, but the timestamp is a crude version indicator. If the from timeststamp and to timestamp are different, the bytecode object may (!) be different. No way for the save to know unless hashes of the objects were included too. And when different you can't have the jump-to point as just an offset into bytecode as something different may be there. So the only thing left is to jump to the last label encountered as that is a logically identical point. And pray that label is present in the new bytecode. If not, or it means something different altogether, you are lost in space anyway.

(sorry, people for this geek interlude in the thread. But it also means that people who strictly use only the .rpyc's Tim has promised to ship will have no problems. Only people that fiddle with the code may have. Incidentally this is another argument for not cheating by fiddling with the code)

 

[EpicLust]

Pamela is ready. Are you?
$20 patrons WHOSE PLEDGES WERE PROCESSED at the beginning of the month can now enjoy playing v0.6 of the game.

 

[Bloodhunter]

View attachment 260351

Pamela is ready. Are you?
$20 patrons WHOSE PLEDGES WERE PROCESSED at the beginning of the month can now enjoy playing v0.6 of the game.

Hot Damn

 

[Elpenetrador93]

Anyone know how to get Reagan and Maria's titfuck scenes and who are the 4 new girls your able to fuck