List of non or mal functioning script terms (events, conditions and commands)

[Jurand of Cracow]

GeneralPrisonersRansomedCaptor causes a CTD when it fires if used for an ancillary.

Hi Guys,
what does it actually mean "used for an ancillary"?

Besides, I've got in my notes that "GeneralHPLostRatioinBattle" is also a faulty term, but it's not included in the first post by Gigantus. How it is in reality?

cheers
JoC

[Erken]

what does it actually mean "used for an ancillary"?

in export_descr_ancillaries.txt

Besides, I've got in my notes that "GeneralHPLostRatioinBattle" is also a faulty term, but it's not included in the first post by Gigantus. How it is in reality?

GeneralHPLostRatioInBattle ? (never used, but this is a priori a/the problem)

[Alondite]

I'm wondering that for the command "give_everything_to_faction", if FROM faction has a crusade target and:

1. TO faction is catholic and not excommunicated : I know it will cause CTD
2. TO faction is catholic but excommunicated : will it cause CTD?
3. TO faction is orthodox : will it cause CTD? (as far as I know, we cannot call a crusade against orthodox factions, right?)

Thanks

[Erken]

destroy_buildings : Destroys only one building of the same chain per settlement.

campaign_wait : The parameter "true" can be added, and then prevent some CTDs (ex: campaign_wait 0 true). It works in some very particular cases at least.

unit_unset_morale & unit_group_unset_morale : Both don't work.

unit_toggle_task_interrupt : The parameter "rout" provokes CTDs by conflicting with the morale update when the general is killed in action.

BattleArmyTired : "Fly you fools!" (can decide to ignore the connected conditions...can also fire with PostBattle...etc...)

[Withwnar]

campaign_wait : The parameter "true" can be added, and then prevent some CTDs (ex: campaign_wait 0 true). It works in some very particular cases at least.

Is there a thread or post somewhere on this? I feel like this thread isn't the place for lengthy discussions and I'd love to know more about this one.

[Erken]

I have opened a more explicit thread here.

[Gigantus]

destroy_buildings : Destroys only one building of the same chain per settlement.

Can you explain more - under normal circumstances you can only have one building of the same chain per settlement. I am not even sure if you could script multiple buildings of the same chain but I guess you may be referring to that setup?

I have added the 'unset', 'interrupt' and 'tired' commands to the list

[Erken]

I have a script allowing to capture settlements by surprise, which creates an invisible building in the targeted city. At the first selection of a settlement with this building, a random message is generated, explaining the circumstances of the capture, and a second invisible building of the same chain is then created to prevent the generation of another message next (this is just a way to avoid to have 198 counters).

The buildings are destroyed at the end of the turn following the capture, but the command destroys only one building (the first built i guess, but i am not sure of this), so it requires to repeat the operation.

But this is a marginal usage, so yes it's not very useful to know.

[Gigantus]

That's roughly what I thought was the underlying reason. Simply running the destroy command twice with a wait 1.0 command in between solves the issue as you noticed.

It really isn't a failure of the script term, but thanks nevertheless in sharing that observation. Sounds like an interesting script idea - would you mind sharing it as a resource in the text edit forum?

[Erken]

would you mind sharing it as a resource in the text edit forum?

No problem, but give me the time to release it first^^

[Jurand of Cracow]

The EBII team considers it confirmed.

BTW, Gig, I don't understand what "if used for an ancillary" means in the sentence "-GeneralPrisonersRansomedCaptor causes a CTD when it fires if used for an ancillary"

It's the use in a EDCT trigger that causes a crash.

I'll update the NumEnemies entry, thanks.

Gig, did you mean EDCT or EDA?

[Gigantus]

Yeah, my bad, mixed EDA and EDCT - the original statement itself was from the bottom of this quoted post.

[youneuoy]

set_option usage:

Spoiler Alert, click show to read: 

I think from the screenshots it’s clear how to use the command.

[Gigantus]

Great find, changing options during game play may come handy - have you tried if it works via regular script?

Edited opening post accordingly.

[Callistonian]

I_FactionLeaderAttribute - PostBattle: if leader was killed in that battle then looks like it is still treating him as leader, i.e. this is not testing the new leader.
CeasedFactionLeader - PostBattle: if leader was killed in that battle then looks like it is still treating him as leader, i.e. this is not testing the new leader.

This does not indicate that these conditions are broken. They may still be broken (I haven't tested), but this is certainly not why they would be broken.

The PostBattle event fires immediately after you return to the strat map (maybe before). At this time, the enemy character is still alive, the settlement hasn't changed ownership (if a siege battle), etc. Only after the killed general has finished his death animation does the game consider him truly dead and only at this point will conditions such as I_WorldWideAncillaryExists, I_SettlementOwner, etc. return the expected values. My suspicion is that adding a 'campaign_wait 4' after PostBattle but before I_FactionLEaderAttribute will make the condition return the correct character as ~4 seconds is required for the death animation (unless you've changed the animation length).

Of course, this solution won't work for event conditions like CeasedFactionLeader that require the data exported by the event immediately at the time of the event. You simply can't use CeasedFactionLeader with the PostBattle event and expect to test whether or not the leader died as a result of that battle. And for I_ conditions, the solution requires adding 4 seconds of lag after every one of these battles that you're monitoring.

I_NumberOfHeirs - seems to be a count of ALL named characters (family or otherwise) including the leader. Teutonic trees too. Does NOT count off map characters.

It's possible to assign multiple characters the 'heir' attribute, but this throws an error in the log and it doesn't actually do anything except ensure there will always be the same number of characters with the heir icon and title (the "secondary heirs" don't inherit the kingship, their title has no real power, if you will, in the family tree). Clearly, the game only wants us to have one heir at a time, so why have a condition to count the number of heirs?

Perhaps this condition is actually referring to the number of characters who can become heirs. The game has a hidden line of succession, much like a real world royal family, that it uses to pick the next heir in the event that the current leader and heir are simultaneously eradicated. From what I can tell, it uses the same line of succession to pick who gets an ancillary if the condition 'not I_WorldWideAncillaryExists' is used (see workarounds for the broken FatherAnc condition which involve shadow traits). This latter behavior will be observed for teutonic factions as if their characters still have a "succession rank" despite there being no heir title in their faction. The game must be assigning a succession rank to every named character on the map which it uses for picking heirs and giving ancillaries. Off map characters can't get ancillaries and I don't think they can become heirs and I'm pretty sure the campaign will end for a family tree faction that has only off map characters remaining and none on the map. So I'd say this condition is counting the number of characters in the viable line of succession.

I_NumberUnitsInSettlement - cannot use types that have spaces.

It seems using spaces makes the condition always return true. I tried enclosing the name in quotations and it made no difference. 'I_NumberUnitsInSettlement London "banana hammock" > 0' always returns true.

If the character does not have the anc then its effects are still removed from him as though he did have it.

I confirmed this finding, it should be added to the OP. The remove_ancillary command subtracts the attribute points of the specified ancillary from the character even if the character never had the ancillary. The subtraction also applies to negative values. I.e. if the character had 5 command attribute points, and we remove_ancillary that has -5 command points, then the character will be left with 10 command points ( 5 - (-5) == 10 ). The command remove_trait does check the character's traits before removing the attribute points and thus isn't bugged in this way.

[Gigantus]

This does not indicate that these conditions are broken

The initial stage of this thread only had 'broken items - I am going to change 'non functioning' to 'malfunctioning' in the thread title.

I_NumberOfHeirs - the name is misleading I would think, rather it's 'potential' heirs, eg possible succession which any named character can eventually achieve. As you mention in your second paragraph.

Added 'remove_ancillary' observation, not sure how I skipped that one.

[Callistonian]

The initial stage of this thread only had 'broken items - I am going to change 'non functioning' to 'malfunctioning' in the thread title.

If any condition that doesn't work as expected with the PostBattle event can be considered 'malfunctioning' then I'm afraid the list is going to get much, much longer. Sure, there are some conditions that return the right value as soon as PostBattle fires such as WonBattle, GeneralFoughtInCombat, etc. but there are countless threads around here where people have overlooked the fact that most conditions don't update until post-battle animations have finished playing, which does not coincide with the PostBattle event but actually occurs several seconds later. Some of the worst offenders (in addition to the ones you've already identified):

I_SettlementOwner
I_NumberOfSettlements
I_CharacterExists
I_WorldWideAncillaryExists
I_CharacterTypeNearTile
anything starting with "I_FactionLeader..."

PostBattle is the real culprit here - not any of these conditions. I would suggest just mentioning in the OP that many conditions will not work as expected with PostBattle because the values they're checking don't update until post-battle strat animations finish playing.

[Gigantus]

Well, that's not a malfunction of the condition per se, rather the fact that an changing event has to finish before a condition will return true. That's what 'wait' is for in the script, but the inability to use that command in triggers will make those conditions unsuitable with the PostBattle event.

I'll add it to the bottom of the 'events' section:

PostBattle - conditions underneath require an intermittent 'wait' command, will not work in EDA\EDCT triggers

I_NumberOfSettlements
I_SettlementOwner
I_CharacterExists
I_WorldWideAncillaryExists
I_CharacterTypeNearTile
I_FactionLeader...

[Callistonian]

Well, that's not a malfunction of the condition per se, rather the fact that an changing event has to finish before a condition will return true.

That's exactly what I'm saying. There is no malfunction with PostBattle nor with any of those conditions - they're all working exactly as intended, just not the way some people want them to. I recently wrote an ancillary-transfer script that relies on these conditions working the way they do; specifically, I used I_WorldWideAncillaryExists to test if the anc exists at the moment of PostBattle, then wait a few seconds for the animations to finish, then I use the condition again to see if the ancillary no longer exists as a result of the battle.

That list is not nearly exhaustive, I was just pulling examples off the top of my head from threads I've seen around here where this has been an issue. I would hazard a guess that it would be a shorter list of conditions which do work "as expected" with PostBattle, that is to say, their conditions are updated concurrently with the PostBattle event.

[Callistonian]

I feel like I_TurnNumber deserves an honorable mention on the list since it checks the internal turn number (which starts at 0) and not the display number (which starts at 1). I.e. any script with conditions like 'I_TurnNumber == 1' aren't going to fire until turn 2, a very common issue. There is a script posted on page 1 of this very thread using I_TurnNumber = 100 which I strongly suspect was not intended to mean turn 101.