itch.io

Age is a relatively superficial attribute that doesn't affect much except how many times someone can use the Maturing or Youthing potions before hitting the age limits.

globals.weightedrandom([ ['tiny', 0.1], ['petite', 0.2], ['short', 0.4], ['average', 0.8], ['tall', 1.2], ['towering', 0.6] ])
globals.weightedrandom([ {'value':'tiny', 'weight':0.1}, {'value':'petite', 'weight':0.2}, {'value':'short', 'weight':0.4}, {'value':'average', 'weight':0.8}, {'value':'tall', 'weight':1.2}, {'value':'towering', 'weight':0.6} ])

Hair colors are assigned from a small set of colors, but unlike many attributes the game has no limits for what a hair color can be. The player can use the Hairdye item to change the color of a person's hair to "lavender", "silver", "neon pink", "radioactive green", "skunk", "snakes", "burning", or "s!x7y N!N3".

Portrait packs use specific names for hair colors so that the Improved Random Portraits mod can pair images with person data. The mod uses hard coded lists of colors rather than fetch them from the game's files so the mod will not bias the image selection towards matching any new colors.

There is no time based aging in Strive. There was a mod that added the concept, but it never got popular. The Maturing and Youthing potions are the only ways to change a person's age after creation/birth.

I haven't used Visual Basic in at least a decade so I don't remember, but in most languages I know the dot operator is only used to access member functions of the class or member variables of the object.

In GDScript, objects and dictionaries use C++ compiled functions in similar-ish ways to compiled languages, but it includes more steps as the data is evaluated and handled in realtime due to the lack of strict data typing. If the string after the dot operator doesn't correspond to any compiled preset then it is processed as a key for a lookup.

In compiled languages member variables of an object are accessed by converting the name into a memory offset from the starting memory address of the object. In GDScript, member variables are string keys used to access values in an internal dictionary, so the relative offsets of variables in memory are not constant. Compiled languages don't use complex lookups like dictionaries as a core part of their design, so I would only expect such a feature to exist in an interpreted scripting languages where convenience is more important than efficiency.

Edit: It might be time to start a new chain of posts as this one is getting quite deep and less convenient to find.

The debug mode will generally tell you exactly what line had the error and give a decent short explanation of the error. Your error happened at this point

"clothes: " + clothes

because the + operation does not accept a string and a dictionary as arguments. If the first operand is a string, then the second operand must also be a string. The correct form would be

"clothes: " + str(clothes)

Yes, it is possible to combine everything into a single line, but it starts to get cumbersome if you wish to include proper contingency management. The "get" function will attempt to retrieve the value corresponding to the given key, but if that key is not in the dictionary then it will return a null. The square bracket operation ( dictionary[key] ) will do basically the same thing but it will cause an error if the key is not in the dictionary. The dot operation for objects and dictionaries is simply an alias for the square bracket operation with a string key. Therefore these two lines are equivalent.

globals.state.unstackables.get(person.gear.accessory).code
globals['state']['unstackables'].get(person['gear']['accessory'])['code']

When an item slot is empty there is a null stored in that slot and there is no null in the "unstackables" dictionary, so get() is used to avoid errors. However, nulls have no indexing operations like get() or [], so "null.code" will cause an error. There is an optional second argument to get() that replaces the null with another value, which if passed a dictionary will allow the indexing without an error, like this:

globals.state.unstackables.get(person.gear.accessory, {}).code

The downside to this approach is that it creates and discards the blank dictionary every time the line runs. Since dictionaries are part of the core structure of GDScript, you will have skipped creating another entry in an existing dictionary for your variable in favor of creating an entire new dictionary.

Your getaccessory() is correct as far as I can see, but if you are looking for shortcuts then there are several you could use here. Since "acc" is simply a temporary storage for the return value, you could skip the variable and return immediately.

func getaccessory(code):
    match code:
        "accslavecollar":
            return "collar"
        "acchandcuffs":
            return "handcuffs"
    return null

However your entire function is simply searching for a key and returning the corresponding value, which is exactly what a dictionary does but slower.

var accessoryTextDict = {'accslavecollar':"collar", 'acchandcuffs':"handcuffs"}
var accessory = accessoryTextDict.get( globals.state.unstackables.get(person.gear.accessory, {}).code )

If you would rather avoid the empty dictionary, then use an if statement:

var accessoryTextDict = {'accslavecollar':"collar", 'acchandcuffs':"handcuffs"}
var accessory = globals.state.unstackables.get(person.gear.accessory)
if accessory:
    accessory = accessoryTextDict.get( accessory.code )

Including "!= null" in the if statement adds clarity, but null converts to false so it is optional in this case. The accessoryTextDict can be put in file scope so that it is re-used for the duration of the file rather than created anew each time a function is run. You may use typeof() checks whenever you want, but generally we refrain from having the code protected against every conceivable problem in favor of designing with the expectation that the data is well controlled. It may be a bit more risky, but development time is a larger problem around here.

The print() function will put text in the standard output stream which will be displayed in the terminal window if you are using the Debug mod or in the output panel if you are running the game through the Godot editor. If you are not using either of those, then everything in the output stream is ignored.

The string values need to be used in the dictionary "globals.state.unstackables" to find the dictionary typed item data for that specific item.

Something to note is that the game randomly switches between American English and British English for spelling and grammar, which likely reflects the fact that the game was proofread by players from around the world. With all the inconsistencies in how the language is handled there are some places where if it sort of fits and it isn't clearly wrong then it gets a pass.

Documentation: https://docs.godotengine.org/en/3.3/classes/class_dictionary.html?highlight=dict...

The first format is a Python styled dictionary creation, the advantages being that it is more obvious that the keys are string values and the keys aren't as limited, for instance including a space between words.

The second format is a Lua styled dictionary creation, the advantage is it's simplicity with less quotation marks to type and read. The downsides are that it can sometimes be confusing to read and it's limited in terms of functionality.

var gold = 5
var formatPython1 = { gold : gold }  # creates { 5 : 5}
var formatPython2 = { 'gold' : gold }  # creates { 'gold' : 5}
var formatLua = { gold = gold }  # creates { 'gold' : 5}
var emptyDict = {}
emptyDict[gold] = gold  # creates { 5 : 5}

Both formats are only relevant when creating the dictionaries, afterwards they have no impact on how the data behaves. This seems to be the source of most of your confusion as you seem to have assumed that the formats used to create the dictionaries impact how they look up keys. Therefore the weirdness you are experiencing is the result of you not properly attributing the data types used as keys and comparisons. For reference, GDScript has the function typeof() that can be used to return the integer that corresponds to https://docs.godotengine.org/en/stable/classes/class_@globalscope.html#enum-glob...

You can use a simple line such as this to learn more about what a referenced value currently contains:

print("value: ", value, "  type: ", typeof(value) )

This line probably doesn't work because there is no variable within the context named "costume":

if person.gear[costume] != null:

This should be quite obvious if you were to read the error messages from the Debug mod. The editor will also show the error message, but it can sometimes get lost among the other things it likes to complain about.

Finally, the "gear" data for persons is a simple dictionary with string keys and the values are either null or string typed item IDs. The string values need to be used in the dictionary "globals.state.unstackables" to find the dictionary typed item data for that specific item. The process for checking for items is usually over-complicated by programmers that don't fully understand the gear system nor power of GDScript.

var temp = globals.state.unstackables.get( person.gear.accessory )
var handcuffs = temp && temp.code == 'acchandcuffs'

The core of the modding system uses .gd files in the mod as though the mod folder was the "files" folder to apply changes to matching .gd files in the game folder. To do anything outside of that core you need to use either the "patch" folder or the dynamic mod folder functions, both of which are explained in the modding guild found in-game in the Mod menu's "Help". Note that you need to use the BugFix mod if you want to use the patch system to add new folders for the new files.

English is not Mav's first language, so he missed some of the subtle parts of the language.

Indeed, fortunately these sorts of sub-optimal code are rarely a significant problem in a game without real time events.

Yes, "get_tree().get_current_scene().rebuild_slave_list()" will do exactly as you expect.

To prevent spamming the name change, I'd probably add a member variable to person.gd to track which day the name was changed and then essentially put the stat effects on cooldown. Though the simpler method might be to simply subtract some energy from the player as a minor cost and require sufficient energy to enable the button, which doesn't fit quite as well intuitively but works okay as a game mechanic.

"Mute" gets attention because it's obvious, but there's always room for slaves to be more expressive in terms of their traits.

The ID increments any time a person is generated, so every step of your exploration that generates an encounter with persons in it increases the counter even if you choose to ignore or evade the encounter. The ID and 'unique' data stay the same for a person for their entire existence until they are deleted. This means that even if you sell and re-buy someone they maintain all their relations and relatives data with other persons. I mention the 'unique' data entry because some people like the idea of having multiple custom starting slaves.

A safe approach is to change a transferring slave's ID to be the current value of "globals.state.slavecounter" and then increment that value manually. It may also be safe to change IDs to be negative for transfers, though I haven't checked this thoroughly. However, if you are moving multiple slaves and want them to maintain a friendship, rivalry, or family status, then the corresponding ID values have to be changed to match the new IDs. The rest of that data should be deleted or not transferred to the new progress otherwise a transferring slave may have some preconceptions about slaves they have never met before.

Using the mod system to apply your changes introduces a whole new set of potential problems, but also likely explains the gap between what is shown and the results you get. Here's a mod that correctly though crudely implements your changes, plus 1 line to update the GUI after changing the name.

https://mega.nz/file/aFpSGKyD#Kt8X026t4Bo8QkecY3hL1ierERvHrwNW2DW-C9JySVo

Yes, it is possible to move slaves between progresses, but there are a few data points to be careful of duplicates. Newly generated persons are simply assigned an ID number from a the counter "globals.state.slavecounter", which then increments. Some functions search for slaves by ID, which would only be capable of finding the first slave in the list with that ID. There is also the 'unique' data which identifies starting slaves and quest slaves, which could have similar problems. Finally, any relations data or data involving interactions with other slaves would be incorrect.

I don't see any problems with the code as presented, including the commented out code. Probably due to itch.io formatting you are missing leading whitespace in the functions so I'll have to take your word that it is not an issue. You haven't specified if you are using the Debug mod or the editor, so I can't rule out the possibility of a tangentially related error somehow sabotaging you.

Itch.io code can be formatted but it doesn't play nice with copy and paste. Edit: seems extra lines really don't work, though adding a space to them works.

code
code after extra line break
    code after tab
 
code after extra line break with space

If we assume that there are no errors, then we will have to get creative in looking for the source of the problem. Please verify that you are not editing the files in the "backup" folder for Strive as those files are 100% copies but are not used except to replace the game's files whenever the mod system applies or resets mods. Note that any changes you have made to the non-backup files will be erased if you use the mod system, and the Debug mod doesn't actually use the mod system. Additionally if you have made your own copies of the files, make sure that the game is using files with your latest changes. Finally, I've had people report in some cases that editors like Notepad++ were somehow editing something like copies of files rather than the actual files so their edits had no effect, though I've never had this happen to me.

Using the Debug mod or editor it is possible to use print() to get direct feedback as to the state of the program in functions, which can be more useful than relying on the Game's GUI to behave as expected. The game also has a system designed for file based trace statements in globals.gd, but those are more helpful for dealing with crashes.

Hello, I basically became the leader of the modding community here after I spent a couple years debugging this game, though I haven't been as active lately. Usually the fastest way to get help is to ask on the Discord (https://itch.io/t/284398/discord), but I try to keep an eye on this site as well.

Godot Script is mostly Python with a little LUA mixed in so the basics should be intuitive to anyone that has messed around with other scripts, but it does a few things in eccentric ways. Most of the files can be edit in text editors, though I recommend using the Debug mod (https://itch.io/t/1137280/debugmod-v10d) for dealing with errors. For general editing of the GUI (scene files .scn and text scene files .tscn) I strongly recommend using the editor provided for the Godot Engine. The game's program folder is mostly the same as the project folder and it uses a version between 3.2 and 3.3 (the latter is likely the closest match).

Strive for Power was created by a beginner programmer so the code can be straightforward to read but messy in design. Large sections of code and even entire files are no longer used, with no clear indications most of the time. This problem was rather low on the priorities list so I haven't gotten around to it.

Scene files are generally used to create GUI that is not expected to dynamically change form or order during run time. Godot provides multiple ways to connect functions to actions such button presses. For buttons created in scene files the standard approach is the stuff you found at the bottom of the file:

[connection signal="pressed" from="MainScreen/slave_tab/stats/callorder/callconfirm" to="MainScreen/slave_tab/stats" method="_on_callconfirm_pressed"]

However, Strive has multiple systems for dynamically creating buttons during runtime and the system relevant to what you are working on is "func dialogue" found in ".../scripts/Mansion.gd". In another function it uses the following code to bind functions to the button presses.

newbutton.connect("pressed", destination, array.function, array.args)

However, this all works pretty well and there's not really anything to worry about besides making certain that you spelled things consistently.

You have excluded some details of your version, so it's not possible for me to determine the exact causes of your problems. My first guess would be that you have not named your name change function exactly 'namechange', put something in the wrong file, or missed renaming something not shown.  I would expect it to be in statstab.gd and look something like this:

func namechange():
    get_node("namechange").popup()

You didn't specify the location and said it works, but I assume your dynamic button data looks similar to this:

buttons.append({text = person.dictionary("Order to call you ..."), function = 'callorder'})
buttons.append({text = person.dictionary("Change Name"), function = 'namechange'})

For clarity, the name of the function should be as you specified in your dynamic button data. The node names and paths for get_node() in your function should be as you specified in mansion.tscn.

Also, while it doesn't appear to cause any errors and you mentioned not adding line breaks, the signal connection lines contain breaks that are not originally present in the file. A bigger problem would be using spaces instead of tabs within your code.

Besides the loot screen, the game only has access to the full inventory through shops or the mansion, and equipment can only be changed in the mansion.
That could probably be modded into the game, but I don't know of any such mods.

The first link doesn't work.

Mechanically speaking, there are no animal characters in this game; the "animals" provided by the kennel for sex are simply temporary persons labeled as animals. Without mods the description "their offspring will often swing back to fully human or fully beast." is simply flavor text. The Aric's Expansion mod adds more flexibility to halfkin by allowing them to rarely produce beastkin, but there are still no animal characters in the game.

Indeed, I missed that note about gender changing not being available. As far as I'm aware the only problems caused by the MarriageAndMore mod are reverting some GUI that would add new features for v1.9a and causing crashes when clicking on the combat party members while exploring.

Wrong mod. This is probably the mod you are looking for https://itch.io/t/2331752/marriageandmore-mod-v3.

Note that the version that is compatible with Arics mod is only only compatible with version 1.8d, as 1.9a made changes to the GUI that require fixes, which are available on the Aric's mod Discord.

Please use the Debug mod (https://itch.io/t/1137280/debugmod-v10d) to get the error messages as that will better narrow down the source of your problem. The Debug mod will have the side effect of stopping the game from crashing, but your problems will not be gone. Note that if you are making your changes directly to the files in the program folder then those changes will be erased if you press Apply or Reset in the Mods menu.

https://strive4power.fandom.com/wiki/Potions#Aphrodite_Brew

Have one of these in your inventory.

When mods conflict the results can occasionally cause small parts of the game to malfunction, but more often than not the game simply crashes. The mods you listed and in the order you listed are generally safe. The notable exception currently being for AricsExpansion versions since 1.9, the Marriage and More mod will need the fix from the AricsExpansion Discord. That said, there are no conflicts that would be expected to impact the laboratory. Instead it's simply a normal AricsExpansion bug.

In order to add the increased body part sizes for things like breasts, AricsExpansion added 6 new arrays of size names to replace the single array of sizes in the original game. However, in the laboratory the single comparison for breast size was never changed from the original array to the new array, thus any new sizes would register as a size -1 and hollow nipples would be unavailable. The fix for this is simple, open up ".../files/scripts/laboratory.gd" in the program folder with a text editor and change the line:

if globals.sizearray.find(person.titssize) >= 3 && person.mods.has('hollownipples') == false:

to:

if globals.titssizearray.find(person.titssize) >= 3 && person.mods.has('hollownipples') == false:

Save the file and restart the game. Since this only changes the program file, any time you apply mods it will be erased and need to be changed again.

There should be no functional difference between the 64 bit and 32 bit versions of the game, except that the 64 bit game will not run on a 32 bit computer, but those don't really get used anymore. I didn't notice that you were installing duplicates of the mod until you mentioned there being a 3rd mod. The GitHub main and 1.9 should be mostly the same though the GitHub version may have fixed one or two things. Either way, installing two versions of the mod is a sure way to cause problems.

Strive is currently distributed with a normal executable, which doesn't log anything when it crashes upon a substantial error. There is a Debug mod(https://itch.io/t/1137280/debugmod-v10d) which will provide error messages and avoid crashing by aborting smaller sections of the game with errors rather than aborting the entire program. The percentages are not correlated to any specific features, but the first few error messages will likely indicate what went wrong, followed by an avalanche of errors resulting from parts of the game being aborted.

If I were to guess, I'd say that the cause was the mod folder name, as Aric's Expansion references the contents of the folder as "AricsExpansion" and anything else will break a lot of things. When downloaded from GitHub the name of the folder is altered, which often causes problems. Most other common problems don't quite fit your report as they tend to have errors reported by the mod system or crash the game upon starting.

Congratulations on setting an incredible record at necroposting a thread that is 5 years, 7 months, and 4 days old.
As to your question, I have never seen any evidence here or on Discord that this mod was ever distributed.

If you don't like those genes, then open up expansionsetup.gd with any decent text editor and use a Find utility to locate 'Emily' or any other unique name. You can change the genes to whatever you want, change the condition after the "if" to false, or delete their entire section starting at the "if" or "elif" to the last line with one more leading tab than the start. Note there are two sets of code, the first is for playing without Ralph's tweaks and the second is for playing with Ralph's tweaks.

Which issue?

Here's a new link https://mega.nz/file/zRB0GB7Z#bQNGTlpRgOZm-9_3ZtZxLxLHbSsImgh1b5H36YrqRlM

This uses the Godot Engine. This requirements page was created as of version 4.2, whereas Strive is about version 3.2, but otherwise should be roughly correct. I run Strive on Windows 7, but I have doubts that it works on prior OS.

Okay found the errors.

In outside.gd, lines 1585 and 1591, replace xp_boost with boost_xp.
Remember to  re-apply the mod after changing the mod files.

The mod is currently buggy as the coders are busy with other projects. This is a known problem with a couple simple fixes. The simple approach is to disable the level up requirements using the Constants mod to enable "disable_levelup_gate".
Otherwise these edits should address the issue:

in outside.gd, lines 1584 and 1590, replace levelupreqs with xp_boost_reqs
in statstab.gd, line 1628 has same problem.
replacing those 6 instances in the mod files should resolve the problems. the mod needs to be re-applied to take effect

There isn't any mods that increase the limits on rooms because the Patreon supporters panel includes a cheat that effectively removes the limits, the code for mansion upgrades is a little bit convoluted compared to other parts of the game, and before recent versions the game would lag and crash with relatively low numbers of slaves.

The current version of the game is less prone to problems, especially if the progress is never loaded from a save file, but I suspect that the game would still crash when loaded from a save with somewhere between 50-100 slaves. It's been a long time since anyone mentioned running into that problem, but the fixes were aimed at reducing lag not preventing crashes so it should still crash.

If you still want to tinker with the limits, then the text file ".../files/scripts/mansionupgrades.gd" in the program folder will contain the level limits for upgrades. I recommend getting the Debug mod if you are editing the files as it makes it easier to deal with typos. Also note that applying mods in-game will erase any edits made directly to scripts.

The end of day logs are generated in a specific order with work coming first and escape attempts happening later. There isn't much that correlates between the two. Low obedience is a requirement to escape but not a requirement to work. The only odd part is that Ayneris should be acquired with relatively high obedience, so escape shouldn't normally occur on the first day unless you have some significant problems.

Normally when a slave escapes they are deleted from the game data so there is no hope of recovery. However, from your second screenshot you appear to be playing with Aric's mod, which includes semi-persistent data for NPCs. So for a little while after escaping she should be present in outskirts of your home town. It's a complex system so it's hard to say what your chances of encountering her are. The mod will not keep infinite NPCs on file and with each additional person generated for random encounters the chances of her getting purged from the file increase, also her data will be updated after each day so she may move to nearby areas. I believe there is an auction/execution event that occurs in the town center when the mod purges NPCs.

Otherwise it's quite easy to edit the save file to reset her quests and acquire a new Ayneris.

Strive only provides images for most of the unique slaves acquired through quests, and it does not provide any images for random slaves, which is why there is a section on itch.io (https://itch.io/board/252654/portarits-packs) and Discord(https://itch.io/t/284398/discord) for images. Since Emily's portrait appears I believe we can conclude that the problem is unlikely to be a hardware issue.

Strive runs on the Godot engine which only supports loading images with ".png", ".jpg", and ".webp" extensions. The slave image selection scripts contain filters to restrict the displayed files to exactly these types, which has the side effect of excluding game images from being selected for slaves.

The "Add custom image" button allows the user to change the file type filters and select images with other extensions, but that doesn't mean that the game will be able to use them. Additionally, that button does not provide nor maintain the tags of the image, so it will not be compatible with the "Race locked" option nor the automatic random portrait assignment system.

I recommend grabbing a portrait pack from the itch.io section linked above and extracting it to the location mentioned in this thread https://itch.io/t/3797794/struggling-to-install-portrait-packs#post-10016618. If that does not work after restarting the game, then I recommend grabbing the Debug mod to check for other problems (https://itch.io/t/1137280/debugmod-v10d. Note the game won't automatically assign images to existing slaves without images in a save file unless you get the Bugfix mod (https://itch.io/t/1167355/bugfix-for-10d-v6b), though it won't fix your other problems.

In the code "Far Eerie Woods" is referred to as "grove" so I would assume that at some point in development the name was changed. The scripts do not use the name of the area to generate the travel buttons, and the inconsistency wasn't noticed until a couple years ago so it wasn't included in any bugfixes. Hopefully I'll eventually get around to a new version of bugfixes to remedy that.

While "grove" and "woods" are similar enough that native English speakers would likely overlook the difference, the developer is not a native English speaker, though he speaks English quite well.

The image packs are put in the app data folder, also called user data, which can be accessed in-game by selecting a slave, pressing Customization, pressing either "Portrait" or "Full Body Image", and pressing "Open system folder". There is also a "Select Folders" button lower down if you want to change the paths to the image folders.

On Windows the shortcut to the app data folder is "%appdata%/Strive", which is equivalent to "C:\Users\USER_NAME\AppData\Roaming\Strive", with your user name inserted. The path can be opened using the Run utility, which can be opened with the Windows key + R, or through the start menu. Otherwise the path can be entered into the address bar of Windows Explorer.

Other problems:
If you run the game through the itch.io launcher then the app data folder will be in a different location, so usually it is recommended to download the zip archive for the game, extract it into a new folder, and run it as a stand alone program.
The game will not see the images if they are in a zip archive or if they are not tagged correctly. Many portrait packs use folders to tag the images, so removing the images from those folders will affect how the game uses them.

The game isn't really designed for gameplay with only a single sex, but it is still possible to complete the quests. There are a few options:

• Use the Laboratory to change the genitals of a slave to match the sex you need.
• Temporarily change the random generation settings to be only the sex you need and go fight people to capture someone of the sex you need.
• Use the Mutate spell or have them use several potions, and hope that they change sex in the way you want. This could take a very long time.
• Learn to mod the game and change the quest requirements to work for worlds containing only futas.

The fix shouldn't require much understanding, just change the text from one layout to the other. For instance in Mansion.gd there is:

halfsiblings.append_array(entry.halfsiblings)

Effectively "halfsiblings" is" array1" and "entry.halfsiblings" is "array2". which can be moved to the other layout:

halfsiblings += entry.halfsiblings

The existing line can be replaced with this line and it should work.

As a quick reminder, the mod system makes text changes to the game when mods are applied, so if you change the text of the mod files you will probably need to re-apply the mod for those changes to have any effect.

Without error messages to show otherwise I would assume that it is due to use of "array1.append_array(array2)", which was added in the more recent version of Godot used by 1.0d. While it would not be entirely equivalent, "array1 += array2" can probably be used as a substitute as long as you don't change anything else.

It appears in the following files:

scripts/Mansion.gd
scripts/slave_tab.gd
scripts/exploration.gd
customScripts/expansiontravel.gd
customScripts/expansionsetup.gd

If you continue to have issues, then I suggest checking the output terminal window that opens with the game. If your game does not open with such a window, then you can create your own by opening Terminal, navigating to the app(cd <path to folder containing app>), and start the game(open -a "Strive For Power").

Please note, none of the modding community, including myself, use Mac so we can only get details and test solutions using Mac users like yourself.