itch.io

It appears that you have posted the Windows error message, which seems to indicate that either your driver is the problem or your system lack another resource like memory. As the game only uses about 312MB of RAM, I don't expect memory to be the problem unless you added a lot of portrait packs or images.
If you run the game using the Batch file named "Strive for Power 2 - console", then the Godot engine will post it's own error messages to the terminal, though I don't know that it will reveal anything new.

Godot Engine version 3.5.1

I'd recommend changing your driver version, either forward or backwards, as Nvidia sometimes releases buggy drivers. Otherwise, you would need an error log with useful information in order to get help here, though this is the wrong forum for your post.

No problem, at least it all makes sense now.

If you downloaded Strive from somewhere other than itch.io then it's possible your game folder is corrupt, which would explain the contradictions in how the mod system interacts with your Strive program folders.

Otherwise there have been rare cases where a computer has weird permissions everywhere and the best solution is to put the game folder in the roaming folder beside the game's user data folder since this usually provides all necessary permissions to edit files and folders.

The Windows explorer can be used to create folders within the Strive program folder instead of waiting for the mod system to create them. There are folders within ".../Strive/mods/AricsExpansion/patch/" that do not correspond to folders within the Strive program folder. For instance, in "res://files/aric_expansion_images/abils/panic.png.import" from the the errors you just gave "res://" refers to your Strive program folder, which contains the "files" folder. However there will not be the folders "aric_expansion_images/abils" within that folder, so the panic png.import file cannot be copied to there.

Edit: Many of your errors are a missing folder in the backup folder "res://backup/.import".

No, but it can help you change the settings of the mod once it works.

Part of the fixes to the mod system was changing an incorrect directory function which prevented the mod system from creating new folders when patching, which is the source of the errors when patching files to aric_expansion_images. Manually adding that folder will remove those errors, but it's not a reasonable solution.

It's possible your backup folder is corrupt from deleting it but keeping the rest of the program folder while Aric's mod was installed, but using a fresh extraction of the game would solve that. Any permissions issues would raise errors long before the mods were applied.

Also your copied messages are self contradictory as you copied it incorrectly.

Are you using Bugfix version 6b? You are not getting the necessary fixes to the mod system. Since you are not listing any errors when opening the Mods menu, this eliminates various OS and folder permissions problems, so there should be no need to change locations. Also no errors listed for when installing the Bugfix indicates no folder permissions problems.
The data in the user/app data folder is almost always safe from corruption and does not need to be deleted. Deleting the Strive program folder after a failed install is a good practice to avoid using corrupt files. Deleting only the backup folder is a good way to make the current state of your game files permanent, as the game will use the current game files to create new ones, though this is rarely advisable as it can cause problems when installing mods. The mods can be extracted into the Strive mods folder at any time before the start of the game as they only affect the install process and game files if they are selected when Apply is pressed.

I get these exact set of errors when I install AricsExpansion without first installing the Bugfix mod and restarting the game. There are a few bugs in the mod system which prevent AricsExpansion from installing correctly so the game must restart in order to be running the fixed modding system. Also, you may shorten this post to after the first two ERROR lines and delete the second post as those are simply the same two errors repeated for a few dozen files.

This error is common when people try to run the game without first extracting it from the zip archive, or if the executable file is separated from the game's "project.binary" and "project.godot" files.

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