Campaign script won't run after adding simple entry to it, no error in logs

[Withwnar]

My original link is to a post that is building on stuff from earlier posts in that thread. See the second half of this post: http://www.twcenter.net/forums/showt...1#post14075960

[euskingc]

Seems fair enough. I don't have a problem with GS re-happening during a siege because a siege depletes soldiers.

Honestly I was on the fence too. On the one hand, you're starving them out and disease sets in, on the other hand, they'd be doing everything they can to manufacture more weapons and train every last recruit they can find...


Some tweaking might be appropriate though so they don't get a whole pile of new recruits all at once on one seemingly arbritrary turn.


Yeah. You just gave me the idea was all =)

Not sure about that red line. Seems to me that the counter should stop if it's under siege, regardless of who owns it.

Yeah, I wasn't sure either. For example, if Gondor takes Minas Morgul in a siege, it sets the counter to 4, then if Mordor counterattacks and besieges them the next turn, should they have to wait 3-4 full turns from the end of that second siege for them to be able to benefit fully from the GS again?
Or does the city simply flood with a host of fresh new orcs?
And if the siege ends quickly then it only half floods but if it lasts a long time it fully floods? Doesn't make a whole lot of sense.



I think I like it your way, yeah.
I'll lose the line =)

[euskingc]

That's pretty unfortunate that the left doesn't know what the right hand is doing as soon as the right hand does it...

I don't know. I don't know how fast a top of the line machine could execute two sieges... or else a good 30 new monitors. Hmm.

Thanks for the lessons either way. I'll get to rewriting it all now =)

EDIT:
Scratch that, not a good 30 new monitors, still only using a handful...

but still, with your way, you can't ever 'rush' them with spies or artillery before the script kicks in.

[Gigantus]

Most GS scripts now use the GeneralAssaultsResidence event to disable rushing (from 1648):

    monitor_event GeneralAssaultsResidence TargetFactionType portugal   ; attacked faction
        and IsTargetRegionOneOf Herzogtum_Bayern   ; region
        and I_SettlementUnderSiege Muenchen   ; settlement
        if I_TurnNumber < 100
            create_unit Muenchen, BuergerwehrG, num 4, exp 0, arm 0, wep 0
            create_unit Muenchen, GrenadiereG, num 1, exp 0, arm 0, wep 0
            create_unit Muenchen, MusketiereG, num 2, exp 0, arm 0, wep 0
            create_unit Muenchen, PikeniereG, num 3, exp 0, arm 0, wep 0
            set_counter Muenchen_siege 1
        end_if
        if I_TurnNumber > 99   ; if they still need it then they might as well perish
            terminate_monitor
        end_if
    end_monitor

[Withwnar]

I don't know if the linked thread mentions it but the difference between the two approaches is this...

Transgression TransgressionName = TC_INSTIGATE_SIEGE --> fires when an army makes the initial move against the settlement, BEFORE the decision to rush-attack (e.g. with artillery), lay siege or withdraw. (EDIT: I mean before the scroll with the Lift Siege, Assault and Maintain Siege buttons.)

GeneralAssaultsResidence --> fires only when the actual attack begins (rush-attack or after a siege), not triggered by laying siege itself and certainly not by withdraw.

So it's a largely a question of whether the garrison should be visible while the siege is going on. Personally I think it's better that it is, rather than a nasty surprise at the end of a long siege where everything seemed safe for all that time. On the other hand, moving against a settlement, then withdrawing, and GS still kicking in is a bit suspect.

GeneralAssaultsResidence has some unique problems of its own though. It screws up the soldier counts in battle. See the second half of this post: http://www.twcenter.net/forums/showt...1#post13247247 And the post after it regarding AI-vs-AI garrison scripts.

[Gigantus]

The above 1648 script comes with a disbanding script (based on custom attribute) to avoid garrison units being used in further game play, that takes care of the withdrawal issue. I was never one for providing free units to the AI.

I'll keep the console command version in mind for the next time I use create_unit (better to script individual units to add instead of bulk in case of overfilling), the missing unit count is indeed a problem if anything script wise is attached to that but wouldn't that happen, regardless of the event used?

[Withwnar]

Regarding Withdrawal I was only referring to the Transgression method. My mistake: I meant "Lift Siege". You can walk a general up to a settlement and right-click him onto it to initiate the attack: at that point the Lift-Siege/Assault/Maintain-Siege options are available AND the script will fire; the garrison appears even if you click Lift-Siege immediately (i.e. abandon this attack you just initiated). But yes, that's another good point: if you want auto-disbanded GS then you need a GS that only happens when the fight is about to begin (not during sieges), which rules out the Transgression method.

but wouldn't that happen, regardless of the event used?

Only GeneralAssaultsResidence. I think it's because that event fires at some point after clicking the Fight or Autoresolve buttons, so by then any new units (GeneralAssaultsResidence-spawned ones) are too late to be included in the battle's calculations. "ButtonPressed siege_assault_button" and Transgression both fire before that time, before the pre-battle Fight/Autoresolve/Withdraw scroll appears.

EDIT: the sequence is...

1) General makes attack move against settlement --> Transgression TC_INSTIGATE_SIEGE event fires
2) "Siege Details" scroll: Lift-Siege/Assault/Maintain-Siege buttons
3) Player clicks Assault --> ButtonPressed siege_assault_button event fires
4) "Battle Deployment" scroll: Fight/Autoresolve/Withdraw buttons
5) Player clicks Fight or Autoresolve

I'm not sure where GeneralAssaultsResidence fires but it's definitely sometime after 4), maybe after 5).

[Gigantus]

Does that problem also occur when a siege gets maintained, eg if the actual battle is in the next round? If not then the problem is confined to rush battles and the probability of it happen relatively small.

Is there somewhere one can look up what the various transgressions export? I am only taking an educated guess that the instigate_siege transgression will export the same stuff as assaults_residence, but I am not betting on it. If it does then it obviously makes more sense to use the transgression road.
I would still add the units right away and remove them with a disbanding script once the siege is lifted.

Edit: just read a bit at the beginning of the thread - even commenting should be done in a precise manner:

;============ Ensures Player Owned Settlements =================
;========== Are Local On Turn Start and Turn End ===============

'Ensure' implies an action to do so - 'testing if' would describe what actually is done.

And: I thought the 'IsFactionAIControlled' condition requires a faction to be stipulated?

[Withwnar]

Does that problem also occur when a siege gets maintained, eg if the actual battle is in the next round? If not then the problem is confined to rush battles and the probability of it happen relatively small.

The soldier count problem?

Is there somewhere one can look up what the various transgressions export?

Transgression is just an event type, so is in the demons. It exports: faction, target_faction, resource_description.

I would still add the units right away and remove them with a disbanding script once the siege is lifted.

Then they'd also need removing upon siege maintain. The auto-disband-GS idea works on the assumption that only one garrison can exist anywhere at one time.

And when an attack begins after a siege ... how to trigger the garrison spawn? Transgression won't fire again at that point, so the options are:
1) GeneralAssaultsResidence - same old problem so it's not solving anything most of the time because most settlement attacks will be after a siege
2) ButtonPressed siege_assault_button - not sure how script could tell the difference between this happening after a siege and being a direct assault: if the latter then the garrison will double because they already exist via the Transgression event. Maybe I_SettlementUnderSiege can help with that, but only if it's false for a direct assault, i.e. true only after maintain siege has been invoked. I don't know.

And: I thought the 'IsFactionAIControlled' condition requires a faction to be stipulated?

It uses the faction exported from the event. I_IsFactionAIControlled does need a faction argument.

[Gigantus]

Then they'd also need removing upon siege maintain. The auto-disband-GS idea works on the assumption that only one garrison can exist anywhere at one time

Well, I circumvent the whole issue somewhat: my test usually checks if GS settlements *** owned by one faction are 'siege free' and then disbands all garrison units of that faction that where spawned on either transgression or assault_residence event. The units have zero upkeep so there are no financial implications. It has the drawback that multiple simultaneous sieges against one faction may make garrison units available for a short time to that AI faction. I would think that to be preferential (having a low probability) to only one global garrison, which presents a very tempting exploit otherwise - unless I misunderstood how that discussed siege script works.

*** usually not more then 15-20 in total, depending on the set up of factions and their vulnerability.

[CavalryCmdr]

And when an attack begins after a siege ... how to trigger the garrison spawn? Transgression won't fire again at that point, so the options are:
1) GeneralAssaultsResidence - same old problem so it's not solving anything most of the time because most settlement attacks will be after a siege
2) ButtonPressed siege_assault_button - not sure how script could tell the difference between this happening after a siege and being a direct assault: if the latter then the garrison will double because they already exist via the Transgression event. Maybe I_SettlementUnderSiege can help with that, but only if it's false for a direct assault, i.e. true only after maintain siege has been invoked. I don't know.

Could you use a counter on the Transgression spawn script that would be removed when the garrison is, then add that counter condition to the siege_assault_button script?

For that matter, maybe just use the siege_assault_button without the Transgression script at all if it's only meant to apply to player controlled attacks, otherwise siege_assault_button would not work anyway.

edit: Right, you want the player to see the garrison, so disregard the last part

[Withwnar]

The script would need to know which settlement is in question when any of these button clicks happen, so it knows which counter to set. I don't know how it would determine that in a maintain...attack situation.

Also, I now remember another problem: ButtonPressed siege_assault_button only fires half of the time.

[euskingc]

This has been a very interesting conversation. You folks should do it more often lol


Yeah... you guys are like my gods these days.
Don't let it go to your heads though =)

I don't know if the linked thread mentions it but the difference between the two approaches is this...

I don''t remember now but someway or another it became clear.

The above 1648 script comes with a disbanding script (based on custom attribute)

What do you mean by custom attribute?



Honestly that use of console command to create the units slipped right by me. Had Gigantus not mentioned it I wouldn't even have noticed.

Also, I now remember another problem: ButtonPressed siege_assault_button only fires half of the time.

Withwnar Stormcrow lol
I'm laughing but I fully realize my project just got longer
=)



Thanks for pointing it out though.



In other news I think I'm starting to accept that if it doesn't fire during a rush attack, hey, that's just what happens sometimes when a city is caught with little time to prepare. Think the romans at cartegena or something.

[CavalryCmdr]

There is a 'pre_battle' event or atleast a 'scroll opened' event that takes place on the campaign map (not sure what it's called exactly, not on my modding computer right now) I'm fairly sure it kicks back battle type, so I_ConflictType Siege should work. I don't think it kicks back target city, but it might kick back faction. Try adding the army there, then remove it when the scroll is closed and not with a battle started.

[Withwnar]

There is a 'pre_battle' event or atleast a 'scroll opened' event that takes place on the campaign map (not sure what it's called exactly, not on my modding computer right now) I'm fairly sure it kicks back battle type, so I_ConflictType Siege should work. I don't think it kicks back target city, but it might kick back faction. Try adding the army there, then remove it when the scroll is closed and not with a battle started.

PreBattlePanelOpen? It exports faction (only), presumably the faction of the player who's seeing the scroll, not the faction of the enemy (I don't know). I_ConflictType might work, though it's possible that at PreBattlePanelOpen's point in time I_ConflictType doesn't yet give a correct answer (I have no idea, would need testing). Still, without settlement exported we still wouldn't know which counter to be setting.

It won't work for AI-vs-AI GS at all, because AI doesn't see scrolls; PreBattlePanelOpen won't fire. For the same reason ButtonPressed siege_assault[maintain]_button can't be used for AI-vs-AI GS either. And GeneralAssaultsResidence doesn't seem to work for them either, as I mentioned earlier (the script fires but the soldier count issue renders it pointless), though maybe someone can test that to be certain: I find it suspicious that Player-vs-AI autoresolve does work yet AI-vs-AI (which is also autoresolve) does not.

And when an attack begins after a siege ... how to trigger the garrison spawn? Transgression won't fire again at that point

That's an assumption. Perhaps it does. When a player lays siege and maintains the scroll closes. To re-open that scroll later to gain access to the Assault button the player must perform the same action again that instigated the siege in the first place: right-click the general onto the settlement. It is that action which triggers Transgression TC_INSTIGATE_SIEGE, so perhaps performing that action the second time also triggers the event a second time, even though the settlement is already under siege. Something else to test.

[Gigantus]

What do you mean by custom attribute?

There is a tutorial around about removing units based on the EDU attributes. This is not limited to the default attributes - you can add your own attributes to assist in scripting issue like this.

[euskingc]

You just answered something I was wondering about!!

I saw in the campaign_script that when this particular unit gets bored of marching and war and decides to 'go home' they did it with:

destroy_units byzantium autonomy_1

and I was wondering how that was connecting to the unit in question... that makes sense!

I may have this moment just discovered another use for this... I'll post it up in another tread soon as I'll be inviting commentary


EDIT:
Is this the tutorial you had in mind?
http://www.twcenter.net/forums/showt...ampaign-script

It seems to imply I simply come up with any unused sequence of characters (example, I could call the attribute adsfkl) I like for an attribute and just plug it into the EDU without editing any other files, is that the case?
I tested it, and the test SEEMS to confirm that.

EDIT EDIT:
I won't be posting up this new use until tomorrow I imagine... figured out the details just have to finish writing it up.

[Gigantus]

Yes, that was the tutorial. and you are correct in that it doesn't matter what the attribute is named. It is however advisable to use something that gives some reference

[CavalryCmdr]

That's an assumption. Perhaps it does. When a player lays siege and maintains the scroll closes. To re-open that scroll later to gain access to the Assault button the player must perform the same action again that instigated the siege in the first place: right-click the general onto the settlement. It is that action which triggers Transgression TC_INSTIGATE_SIEGE, so perhaps performing that action the second time also triggers the event a second time, even though the settlement is already under siege. Something else to test.

I don't think so, that's used in descr_faction_standing, doing so again after the settlement is under siege repeatedly dose not appear to continue to fire the trigger in that file.

1) General makes attack move against settlement --> Transgression TC_INSTIGATE_SIEGE event fires
2) "Siege Details" scroll: Lift-Siege/Assault/Maintain-Siege buttons
3) Player clicks Assault --> ButtonPressed siege_assault_button event fires
4) "Battle Deployment" scroll: Fight/Autoresolve/Withdraw buttons
5) Player clicks Fight or Autoresolve

When dose TC_INSTIGATE_ASSAULT fire?

[Withwnar]

I don't think so, that's used in descr_faction_standing, doing so again after the settlement is under siege repeatedly dose not appear to continue to fire the trigger in that file.

Fair enough. Makes sense.

When dose TC_INSTIGATE_ASSAULT fire?

I don't know. I have only ever used TC_INSTIGATE_SIEGE. I wouldn't be surprised if it fired when clicking the Assault button on the Siege scroll, or perhaps the Fight and Autoresolve buttons on the Prebattle scroll that follows it (because Withdraw could be clicked there instead, meaning no assault is happening*). It might not be limited to siege battles at all, e.g. also army-vs-army battles like GeneralAssaultsGeneral, or naval battles.

* Then again TC_INSTIGATE_SIEGE fires even though you might go on to abort that decision (lift siege) in the scroll that opens.

Easy to test:

monitor_event Transgression TransgressionName = TC_INSTIGATE_ASSAULT 
  console_command add_money 1
end_monitor

Keep an eye on the money count while clicking Assault, Fight, Autoresolve buttons and when telling an army/navy to attack another on the map.

EDIT: I gave that a quick try and the money never went up. No log errors, it just didn't seem to ever fire.