If you play on realistic, that is what you will mostly see unless it is the correct time of the month.
so I don't know how to find information about it...
I want to replace image (head), but whole character model disapears.
I edited the .png image with Gimp
any ideas?:l
.zip issue, double folder inside .zip ><
Last edited:
windows 7 32 bit
game does not look like "windows 64 bit only"
maybe make it "windows 10 only"?
or "windows 11 only"?
game is outdated to be "windows 64 bit only"
game does not look like "windows 64 bit only"
maybe make it "windows 10 only"?
or "windows 11 only"?
game is outdated to be "windows 64 bit only"
Last edited:
Not without editing the code (game_roles/role_pregnant_definition_ren.py). And per comment in the code, is seems reason for the delay is to let all events play out correctly, so just changing the number might break things.
i mean you could try to run it but it might peak your cpu
there are some win7x64bit but you would be better fit by getting win10 or 11 and if security/customization is your thing then you may wanna look into hacking it. fyi linux should technically run anything... if you are a coder lmao
there are some win7x64bit but you would be better fit by getting win10 or 11 and if security/customization is your thing then you may wanna look into hacking it. fyi linux should technically run anything... if you are a coder lmao
Anyone else want to see a chain where you corrupt Jennifer's boss's daughter as the solution to the "I'll help you find other girls" response when asking him to leave Jennifer alone?
deviantfiend999
Active Member
- Apr 21, 2018
- 502
- 607
- 245
Yeah that was supposed to be a possibility according to comments in the code too
You don't have permission to view the spoiler content.
Log in or register now.
You don't have permission to view the spoiler content.
Log in or register now.
However, since the daughter is just a generic NPC at the moment, and no part of the roadmap mentioned the two, they are probably way back on the burner.
Well, she has been given a static last name of Vandenberg, a daughter of Christine and sister to Emily. She is also the same Iris that you meet during Lily's phone taboo event. So we already are likely corrupting the wife and both daughters of Mom's boss. More definitely is to be written there eventually though.
Oh really, even after you use a potion?
Actually the 20% increase in fertility does nothing.
Last edited:
The increase is relative, so 1% increased by 20% results in 1.2%, which is still not very much. However, on realistic, girl has multiple chances to get pregnant from a single load, so the actual chance is way higher than what you see.
Looking at the code now, it looks like on realistic girls can get pregnant each turn for 3 days after a insemination, which is 15 turns minimum. This means that 1% chance each time actually translates into 14% chance overall if my math is correct.
I thought so too, but that's different from how it used to work, and not how it's written, plus it doesn't show the boost on the pregnancy chance either.
this is why i say the game is still in its early stages. the potential fetishes/kinks that can be expanded are near limitless. even small subplots like the breeding cow employee subplot was awesome for me.
the main difficulty (imo) is staying within the constraints of this fictional world that has been created. every time something is added, the addition needs to be organic so people don't ask things like "wait, why is so and so a virgin even though we've been shagging for the last 76 days and she's already pregnant?" etc
Here is a remodeled version of the game core, relating to the development and use of the serum.
Although it will be mostly useful for those who create add-ons to the game on their own, it also fixes some bugs in the existing version of the game.
The reason for its creation is that the original version of the game from Vren, when saving, memorizes many things that shouldn't be saved because they are constants.
And if we change them in the program code of the game, these changes have no effect after loading the saved game.
For this reason, it was quite difficult to add new serum traits to the game.
In order to be able to add them, the game developers created SerumTraitMod.
This mod is quite workable, but it did not eliminate many problems, and therefore it is impossible to pass the game, each time saving and loading saves without using cheat mods.
The new kernel allows to eliminate this problem, and supports the work of already saved games.
If you play with Pen'Py SDK, you just need to unpack the archive into the folder with the game, replacing the existing files. Base Beta version of the kernel is from 2023.12.11.
The following will outline information for those who make additions to the game on their own.
To create a new serum trait you need to either in a new file or in an existing file, write the following lines:
<name_trait> = <"Displayed Serum Name">: my_new_serum_trait = "My New Trait"
Naturally, the variable name must be unique, just like the serum name. If you use an already existing name, it may cause errors in the game, and to give an identical already existing displayed name, you will not allow the parser, giving an error message and stopping the execution of the program.
Next, you should describe the functions on_apply, on_remove, on_turn, on_day, if you intend to use them. You should not give them unique names, because they are usually not used and only clutter the namespace.
It is enough to describe a function once, before calling the class constructor, and then create a function with the same name (but with a different code), because the reference to the previously written function will be saved in the object attribute.
def on_apply(person, design, effect, add_to_log):
____<function code>
I chose not to create copies of the SerumDesign object each time I gave the drug to the girls, because that takes up a lot of memory.
Instead, a new instance of the SerumPreparate class is added to the girls with only a few attributes: a reference to the original SerumDesign object, the number of remaining moves of the serum's action, and a list of several lists, originally and usually consisting of a reference to the SerumTrait object.
The run_on_#### functions take as arguments a reference to the source SerumDesign object (design), and a list containing a reference to the source SerumTrait object (effect), since the game already has serums that have parameters that change as a result of their use.
If a function needs to save any data for later transfer to another function, the "effect" parameter is used as a stack, for example with effect.append() in on_apply and effect[-1] effect[-2] e.t.c. in on_remove.
Now instead of the SerumTrait class, the STBDDS class is used when adding a serum trait to the game. # (Serum Trait Base Default Data Store).
Giving a name to the created object is pointless.
The names passed in when the object is created are the same as those used when the SerumTrait objects were created.
STBDDS(name = my_new_serum_trait, desc = "This is a new serum trait", e.t.c
The variable we set at the beginning of the creation of a new serum trait should be passed as the name, because it allows us to avoid misprints and, of course, to use it later, if necessary.
Among the parameters that are passed when creating a whey trait we include "triggers" - a string, a list, or a logical True value.
This is to make certain traits in the scenario available or unavailable for research or use at a certain point in the game. Previously, this was done with:
list_of_traits.append(some_trait)
some_trait.tier = n
then the command is given here
enable_trait(some_trait)
or
disable_trait(some_trait)
respectively, instead of
if some_trait in list_of_traits:
is used
if trait_enabled(some_trait):
or
if trait_disabled(some_trait):
If we pass True as "triggers", triggers accepts as a value a list consisting of the trait name.
However, it is possible to set another value common to multiple traits to "enable" them with a single command:
traits_triggers_list.append(some_common_value)
Or we can set a list of several values, if several conditions are required to activate a trait.
We also introduced the "Reserchable" parameter - it determines whether a trait is explorable, and whether a SerumTrait object corresponding to it should be created.
The SerumTraitBlueprint and side effects traits are not explorable.
In fact, no other actions are necessary to make the serum trait in the game.
Parameters equal to default parameters are ignored when creating an object of STBDDS class and class variables are used instead.
STBDDS objects are created each time the game is launched and cannot be changed.
They are stored in the STBDDS.traits class dictionary.
When loading a saved game, the dict_of_traits dictionary is checked for SerumTrait objects corresponding to STBDDS objects - both are found by the key <name_trait>, which is specified in the description of the serum (as described earlier).
This variable can be used to get a SerumTrait object or an STBDDS object at any time, if the existence of a SerumTrait object is not assumed:
get_trait(some_trait:string|SerumTrait|STBDDS)->SerumTrait|STBDDS|None
The SerumTrait object contains only a couple variables: "base"&"progress" are actually the key name and the state in the study of this trait.
All other values are obtained by methods from the base object STBDDS and mathematical calculation.
However, it is possible to set values for the attributes of the SerumTrait object during the game that differ from the constants obtained from STBDDS.
When loading a saved game of the previous version, the program processes the objects contained in list_of_traits and mc.business.blueprinted_traits, and changes the state of research for the created new set of traits.
SerumDesign objects are also processed, both in mc.business.serum_design and in segum_effects of each girl, and references to the previous SerumTraits objects in them are replaced with new ones.
However, 100% guarantee in the absence of any errors cannot be given yet, and I would like you to test this kernel.
P. S. I just found two error. Tomorrow I will send two corrected files.
Although it will be mostly useful for those who create add-ons to the game on their own, it also fixes some bugs in the existing version of the game.
The reason for its creation is that the original version of the game from Vren, when saving, memorizes many things that shouldn't be saved because they are constants.
And if we change them in the program code of the game, these changes have no effect after loading the saved game.
For this reason, it was quite difficult to add new serum traits to the game.
In order to be able to add them, the game developers created SerumTraitMod.
This mod is quite workable, but it did not eliminate many problems, and therefore it is impossible to pass the game, each time saving and loading saves without using cheat mods.
The new kernel allows to eliminate this problem, and supports the work of already saved games.
If you play with Pen'Py SDK, you just need to unpack the archive into the folder with the game, replacing the existing files. Base Beta version of the kernel is from 2023.12.11.
The following will outline information for those who make additions to the game on their own.
To create a new serum trait you need to either in a new file or in an existing file, write the following lines:
<name_trait> = <"Displayed Serum Name">: my_new_serum_trait = "My New Trait"
Naturally, the variable name must be unique, just like the serum name. If you use an already existing name, it may cause errors in the game, and to give an identical already existing displayed name, you will not allow the parser, giving an error message and stopping the execution of the program.
Next, you should describe the functions on_apply, on_remove, on_turn, on_day, if you intend to use them. You should not give them unique names, because they are usually not used and only clutter the namespace.
It is enough to describe a function once, before calling the class constructor, and then create a function with the same name (but with a different code), because the reference to the previously written function will be saved in the object attribute.
def on_apply(person, design, effect, add_to_log):
____<function code>
I chose not to create copies of the SerumDesign object each time I gave the drug to the girls, because that takes up a lot of memory.
Instead, a new instance of the SerumPreparate class is added to the girls with only a few attributes: a reference to the original SerumDesign object, the number of remaining moves of the serum's action, and a list of several lists, originally and usually consisting of a reference to the SerumTrait object.
The run_on_#### functions take as arguments a reference to the source SerumDesign object (design), and a list containing a reference to the source SerumTrait object (effect), since the game already has serums that have parameters that change as a result of their use.
If a function needs to save any data for later transfer to another function, the "effect" parameter is used as a stack, for example with effect.append() in on_apply and effect[-1] effect[-2] e.t.c. in on_remove.
Now instead of the SerumTrait class, the STBDDS class is used when adding a serum trait to the game. # (Serum Trait Base Default Data Store).
Giving a name to the created object is pointless.
The names passed in when the object is created are the same as those used when the SerumTrait objects were created.
STBDDS(name = my_new_serum_trait, desc = "This is a new serum trait", e.t.c
The variable we set at the beginning of the creation of a new serum trait should be passed as the name, because it allows us to avoid misprints and, of course, to use it later, if necessary.
Among the parameters that are passed when creating a whey trait we include "triggers" - a string, a list, or a logical True value.
This is to make certain traits in the scenario available or unavailable for research or use at a certain point in the game. Previously, this was done with:
list_of_traits.append(some_trait)
some_trait.tier = n
then the command is given here
enable_trait(some_trait)
or
disable_trait(some_trait)
respectively, instead of
if some_trait in list_of_traits:
is used
if trait_enabled(some_trait):
or
if trait_disabled(some_trait):
If we pass True as "triggers", triggers accepts as a value a list consisting of the trait name.
However, it is possible to set another value common to multiple traits to "enable" them with a single command:
traits_triggers_list.append(some_common_value)
Or we can set a list of several values, if several conditions are required to activate a trait.
We also introduced the "Reserchable" parameter - it determines whether a trait is explorable, and whether a SerumTrait object corresponding to it should be created.
The SerumTraitBlueprint and side effects traits are not explorable.
In fact, no other actions are necessary to make the serum trait in the game.
Parameters equal to default parameters are ignored when creating an object of STBDDS class and class variables are used instead.
STBDDS objects are created each time the game is launched and cannot be changed.
They are stored in the STBDDS.traits class dictionary.
When loading a saved game, the dict_of_traits dictionary is checked for SerumTrait objects corresponding to STBDDS objects - both are found by the key <name_trait>, which is specified in the description of the serum (as described earlier).
This variable can be used to get a SerumTrait object or an STBDDS object at any time, if the existence of a SerumTrait object is not assumed:
get_trait(some_trait:string|SerumTrait|STBDDS)->SerumTrait|STBDDS|None
The SerumTrait object contains only a couple variables: "base"&"progress" are actually the key name and the state in the study of this trait.
All other values are obtained by methods from the base object STBDDS and mathematical calculation.
However, it is possible to set values for the attributes of the SerumTrait object during the game that differ from the constants obtained from STBDDS.
When loading a saved game of the previous version, the program processes the objects contained in list_of_traits and mc.business.blueprinted_traits, and changes the state of research for the created new set of traits.
SerumDesign objects are also processed, both in mc.business.serum_design and in segum_effects of each girl, and references to the previous SerumTraits objects in them are replaced with new ones.
However, 100% guarantee in the absence of any errors cannot be given yet, and I would like you to test this kernel.
P. S. I just found two error. Tomorrow I will send two corrected files.
Last edited:
I agree, that particular aspect of the realistic setting does not add anything particularly interesting and is quite confusing, since this is not explained anywhere.
I also figured out why the boosted fertility is not shown. It's because on realistic setting, if a girl is more than 3 days from ideal fertility day, the fertility is hard-coded to be 1% and no modifiers from serums are applied to it. So the display works correctly, but the boost does not work unless the time of the month is right.