The reason is fairly simple, and is not specific to this mod. When the mod system was updated for Strive version 1.0, leading comments were added to the syntax, however it had the unintended quirk of starting the line counting from the first line of the comments rather than the header. It had become a new standard before I was aware of the oversight and changing that standard would break all existing mods that have compensated for it. I try to avoid changes that break existing mods, and I also try to keep the mod system somewhat intuitive, but I haven't yet committed to breaking so many mods to fix this quirk. Since there is one line of leading comments attached to the definition for newdescriptions you will need to add one to your line count to compensate.
Headers are things like var, func and so on? And leading comments are #-comments right before the header with no lines between them, right?
#leading comment
var example = {
}
#not a leading comment
var example2 = {
}So when I use RemoveFrom and AddTo on usual header, the first line (0) is the next one after header, and with leading comment 0 line is the header itself?
To be clear in this context, "header" is a term specific to the modding system which specifies the part of a definition that is used to identify a match from the mod files to the game files.
https://strive4power.fandom.com/wiki/Modding_Guide#Syntax_of_variables_and_their_variants:
Yes, the leading comments are limited to lines startings with a #.
https://strive4power.fandom.com/wiki/Modding_Guide#Leading_comments:
Yes, with one line of leading comment the first line is the header, and while not intended that is the only way to change or remove a header besides patching the file. Header lines were likely excluded from the count to prevent mistakes, though it does limit modding.
Indeed, it does not appear to be particularly common for "absent" to be used that way, though as someone proficient in English it does not feel wrong. From looking as various language forums, it seems that both "is absent X" and "is absent of X" are not commonly used in English outside of American English, so that is not guaranteed to add clarity. As best as I can tell from reading some dictionaries, it seems to be a mixing of the adjective semantics with the preposition usage. There seems to be better precedence for using words similar to "absent" (such as "without") as prepositions in this syntax, so I expect that the complex semantics of "absent" do not quite work well here.
I'll keep in mind your preference for lowercase in the future.
Capture Changes and Random Awareness are default of 0 which are what it appears they were in the released version for v1.8c. That's always been intended to be left as is for the release, so I'm not sure where it would have changed. I'll admit that those aren't the values I use on my personal playthroughs, so if it went from -3,3 or the multiplier of 10, I might have accidentally left in my personal changes into one of the old releases.
repeatable_quests.gd, line 466
description = "A member of the $rare race desires a worthy mate for reproductive purposes. $He must be at least average in appearance and open to $his mate's commands. ",
In game it looks like this
Vanilla Strive has no less than 3 different dynamic text systems, which have different formats and functionalities. The slave guild has one because the other systems are designed to work for people that exist, but the request for a person is not a person. The slave guild's text system is very bare bones and does not support most gendered pronouns like the single person system, so the fix is most likely adding text replacement for those.
The strangeness you found is the vanilla design for using the "setget" keyword on variables simply to access other values inside a dictionary. This design completely bypasses the member variables that appear in most of the code, so they remain null.
Also strange bugs with hairstyles
First, $his doesn't work in description
Second, hairstyle change is half-broken. When you click on hairstyle option it chooses previous one. So choosing straight hair makes character bald and it's impossible to choose bun.
Tried reinstalling everything and enabling only bugfix and this mod, nothing changes. In vanilla game everything is fine.
It appears that Deadly Blow is missing the effect field: "effect = null,". While I'm not entirely certain this is the cause, I am certain that if you were playing with the debug mod and used this ability then it would cause battle to soft-lock as the debug response to the missing field would be to abort the function and skip the part that manages the battle states.
I don't know how it happened, but during the combat I can't select the target enemy, and the "end turn" button broke. I was spamming "1" to use the basic attack while selecting the enemy, so maybe this is the cause.
The debug console keep writing the same line again ad again.
On a side note, sometime when I minimize the game window the buttons broke in the same way. This happen in several zones, not only in combat.
Sorry if those are already know issues. I tried to search for them but I may have missed them.
Just to re clarify problem occur in both normal and debug mode, you will most likely run into the issue in large group of bandits where using 1 button ends up soft locking game, smaller number of enemies don't run risk of it occurring or significant less to happen and same script error code as the poster.
Just the attack skill, only used constants mod and what it has to offer and the error code points to damage effect scales calculation, doesn't really say where or what group is.
Honestly could be something simple like loading problem with custom images that maybe bit too large size for what its use for, just creating stress on game engine having to resize image and use said image in attack animation causing it to stagger when force to speed up which can end up skipping something leading back to problem. Give that wild theory try later.
You may want to verify that you are looking at the correct file or lines of code. The error message points to this line:
if scene.targetskill.targetgroup == 'enemy' && scene.selectedcharacter.group == self.group:
This line has nothing to do with damage at all. It checks that you haven't selected one of your own party members as the target for a skill that targets the enemy. "group" shows up twice in this line, both being the string member variable of combatants that indicates which group they are apart of.
I have not yet ruled out the possibility of a race condition due to rapid inputs, but it should not be the case that something was skipped due to poor performance.
Oh yeah, thanks for pointing that out I pretty much went with first thing I saw on top the page with 'go to' line function search, still getting hang of coding and it was literally in next code func below.
Anyways think you might be correct with rapid inputs, did some stress test with large images all that was achieved creating lag spikes no change in script flow, only when mashing button inputs you get the problem and a lot sooner in frenzy manner.
Not certain that this is the only gap, but neither the key press event for skills nor the skill button press function checks the battle state before doing stuff. Adding the following couple of lines to the start of pressskill(), should cover this gap.
To assign them to crystal research you need to get the 1st lv. in the mansion upgrade.
func pressskill(skill):
if period != 'base' && period != 'skilltarget':
return
Note that this site converts leading tabs to spaces, so you will need to convert them back to tabs.
This should mean that the window for pressing the 1 key after a mouse click was only about 1/30 of a second.
I believe that was explained in a prior version of the setup instructions, but is no longer included. There are very few mods capable of conflicting with the Improved Random Portraits mod, and those that do conflict will quickly correct themselves as it is considered an essential mod. Thus this mod does not conflict with the Improved Random Portraits mod. I recommend using this version(/t/984434/randomportraits-and-portrait-pack-editor-for-the-10-ver...) as it is more up to date.