Plan details


First Start
First, intro asks if user is interested in 24/7 and whether user wants realism or not.
If interested in realism, intro uses work life selected, personal life selected, and relationship to user selected.
Then asks if the user wants to go to configuration/setup script or do it later in sessions.




Structure:


SessionSelector->(Session_Type)->(Session_End)[different than End. Session end deals with variable and statistics cleanup]
Tentative Session Types:
* NormalSession = {(Start -> (Module)+->(End)}
* FapRouletteSession={(Module)+->(End)}
* WebTeaseSession={(Start)?->(Module)+->(End)?}
* PunishmentSession1={(Start)?->(Module)+->(End)}
* More possible…
Ideology: Keep the pieces of TAJ structure that would make sense in any session but remove the stroke/link pieces since they aren’t necessarily needed.

There will eventually be several different session types with different structures so for this reason,

To handle the original purpose of link files I propose a new system that will resolve this issue as well as others:

New Module System:

Every Module has at least one category.

How is it enforced/ Where is it stored?

Option 1: Declared in the top of the file when first run. Maybe use set a variable to true while loading the modules and then each module would call if(setCategories(category1, …)){full code of module}. Then setCategories would only return true if we are not loading the module for the first time. Downside is this might screw over the statistics system and also you would have to call run on these modules more than once.
Pros:
* Easy to keep track of when writing modules and easy for new module creators
Cons:
* If the files are run once to initialize then the content would need to happen after a method call which makes writing new modules more complex and unnecessary.
Option 2: Store the category information for each module all in one file or in separate files for each module.
Pros:
* No changes to the actual code of existing modules.
Cons:
* Would be easy to forget to add categories for a module
Chosen Option: **Option 3:** Have the categories stored at the top of each file and then implement custom java logic to go through all the modules and parse the labels and return them and store a dictionary of file path-> array of labels
Pros:
* Hardly any changes to existing files.
* Less Concern of forgetting to categorize files.
* Modules would only be run when needed.
Cons:
* Slower probably but only at personality startup so maybe not an issue.
* Longer time to implement since it’s using java logic under the hood.
* Developers might think the labels aren’t being used since the labels would be in a comment
What categories will be necessary?
Optional: These categories mean that the content is in the file but won’t be used if the user’s settings don’t permit that content.
* Short
* Medium
* Long
* Extra-Long
* Optional:
* Stroking
* Edging
* CEI
* CBT
* Anal
*
How will the categories be used?
The fetish categories will all be optional to be disabled. If the fetish is disabled and it is not optional in a file, that file will never be selected.  Also, each fetish category will have a value from 1 to 10 representing how much the user likes that from 1 (user hates) to 10 (user loves). Then the value will be put through a formula (or mapping if only 1 to 10 instead of 1-100 that weights it such that numbers closer to 1 and 10 are worth significantly more negative or positive weights. Then all these weights are added and the module is chosen based on all the weights of available modules choosing modules that are not in the recent history if possible.

Consider using the design of a neural network?











Most Important Problems to Solve:
* Repetitiveness
* Poor flow


Design considerations:

Think of all possible features but don’t implement until needed so there isn’t a lot of excess unused code