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?
- Apr 21, 2018
- 457
- 488
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:
Yes I know about the small spoiler and cannot wait for events to go even further
Also I wasn't necessarily suggesting to add male models to the game, because after all, not even MC is shown penetrating the women (in hindsight, that might have made it easier to add other males). But currently, that might ask for too many renders to (re)do, if we're talking sex acts. Even if I'm not gonna lie, trying to picture Jennifer being gangbanged with the renders of dicks in her hands / holes sure looks like a dream (if you want it to happen of course)
But when I was talking about more males options in the scenes, I meant having the option to have a man in the scene the same way you are doing a scene between MC and a woman, choosing what he does to the woman, or doing a MFM threesome the same way the MFF threesomes are currently implemented in the game (except without displaying the other man, kinda like during the mom " NTR " scenes) with options to switch to other positions and stuff like that.
There are plans that are already coming along pretty far, about re-doing all the current ingame poses, bodies, faces and clothes. Because since Vren didn't share the models used or the exact positions, it was impossible to just add more content on top, it needs to be fully redone.
When it's done, plans are to use that foundation to add more content, such as more clothes, more sex acts / poses. So maybe ahegao will drop at some point. Gapes might take longer because that means re-doing already re-done renders to add bigger gape sizes, which might not be a priority when talking about new content, as opposed to bringing new sex positions such as footjobs or thighfuck, for example. But it's still in the realm of the possible, when the rework project is released, and that people can help and focus about adding new stuff.
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.
Fixed (or at least worked myself around) the first two crashes but a bit stuck on the third since i'm not sure if her barista role is supposed to be a "real" job (current her job is set with change_job) or a side job (like Erica, who sets her job with set_side_job) since the game crashes when it tries to change settings on her side job (that doesn't exist).
I should probably wait for a few bug-fixes before bothering with the dev-version
Ignore everything I just wrote, somehow I missed that an update had been made (in the Dec23Content branch) with Kaya-fixes since the version I downloaded that seems like it might fix things
Last edited:
Hi everyone.
Sorry if already asked before but it seems I can't unlock any anal with Ellie the IT girl.
Can't see any of it in her sex positions and anal is a unbroken taboo in skills section of trance opinion changer. So by concequence I can't raise her mastering level and make her anal fetish so I can unlock the last IT project level.
içt seems that nothing is happening in her story line anymore.
I hope to be clear.
Thanks
Sorry if already asked before but it seems I can't unlock any anal with Ellie the IT girl.
Can't see any of it in her sex positions and anal is a unbroken taboo in skills section of trance opinion changer. So by concequence I can't raise her mastering level and make her anal fetish so I can unlock the last IT project level.
içt seems that nothing is happening in her story line anymore.
I hope to be clear.
Thanks
Here are the corrections I promised. Fixed an error in the "review serum design" screen and an error when saving the game
- Apr 21, 2018
- 457
- 488
I don't know much about her since I didn't like most side girl contents, but looking at the code, there seems to be an event trigger for when she "never tried anal" and currently it has no effect (also return "false" so its corresponding event will not fire).
Hello. Thanks for the reply.
I'm not sure to understand 100% what you're saying but in short it's broken right?
I guess I'll have to wait.
It's not that I particulary like her but it's a requirement to max up the IT projects.
- Apr 21, 2018
- 457
- 488
- Nov 29, 2017
- 54
- 67
Hey guys, any word on the next release for this? I have been keen to play it again but sounds like an update might be close to release so wondering if I should hold off. To everyone working on the mods, keep up the great work.
- Apr 23, 2018
- 232
- 65
Just started a new game with this new version and I don't have to option to talk to Stephanie about upgrading the serums. I'm stuck on tier 1 without the ability to ask her about nora. It used to be there was an option that would show how much love she needed but its not even there.