siege_maintain_button/siege_assault_button don't always trigger ButtonPressed events

[Withwnar]

Clicking these buttons only fires a ButtonPressed event every second time.

monitor_event ButtonPressed ButtonPressed siege_maintain_button
  console_command add_money 1
end_monitor

Lay siege to a settlement then click "Maintain Siege": 1 money is added. Perfect. Now go and lay siege to another settlement with another army and click "Maintain Siege": nothing happens. Now click it again: 1 money is added.

Doing an "abandon siege" (right name?) in between makes no difference and it doesn't seem to be fixing itself during a turn end.

The siege_assault_button has the same problem.

So surely this means that any script hanging off of either of these button clicks will not work half of the time. e.g. Garrison scripts.

Anybody noticed this and found a solution?

[danny X]

If it applied to garrison scripts too, wouldn't people of noticed by now?

[Withwnar]

It was while working on the Third Age garrison script that I found it. That one has three triggers: these two buttons and a TurnStart one. The latter is intended for AI-vs-AI only, using a shorter cool-off period and slightly different unit makeup/bonuses.

So I'm not overly surprised by lack of notice because the TurnStart trigger will still make the garrison appear. Just not at the time that it should have appeared. I am 90% sure that I have noticed that before: that sometimes the garrison appeared when clicking the maintain siege button and other times not until during turn end.

But the real point with this particular GS is that those triggered by TurnStart are different to those triggered by the player clicking buttons. If the button fails then yes they still get a garrison but the wrong kind and a shorter countdown before it can trigger again. The GS is the one intended for AI attacks, not player, so the script is broken for 50% of player attacks. Broken as in "not quite working as intended".

If you had a garrison script that did not have this also-during-turn-end 'fallback', or some other script that is only triggered by these buttons, then people will notice for sure.

EDIT: and another thing...

TATW's garrison script should be creating a garrison when the player directly attacks a settlement with artillery. i.e. No siege, straight to the "assault" button. In this case there is no turn end fallback mechanism so there is no garrison script, 50% of the time. Maybe people who notice this assume that it is due to the cooldown period still being in effect.

A workaround for that one would be to also use a GeneralAssaultsResidence event, as a backup. [ButtonPressed siege_assault_button] will trigger first so if that does indeed trigger then by the time that GeneralAssaultsResidence triggers the GS would already have been applied and the cooldown period activated, therefore GeneralAssaultsResidence's script will do nothing.

However, GeneralAssaultsResidence has its own shortcomings: second half of this post: http://www.twcenter.net/forums/showt...1#post13247247

[Taiji]

Well spotted, Withwnar. Thanks for sharing.

edit:

One solution that occurs is to use this:

Identifier: I_CharacterTypeNearTile
Trigger requirements:
Parameters: faction, character type, distance in squares, x, z
Sample use: I_CharacterTypeNearTile romans_julii named_character, 10 48,30
Description: Is a particular character type of a faction near a particular tile?
Battle or Strat: Strat
Class: I_CHARACTER_NEAR_TILE
Implemented: Yes
Author: Guy

And then spawn them when an enemy army enters the ZOC.

[Gigantus]

It appears to be connected to all the siege_xxx_button apart from the fight one.

This one works, but replacing it with another siege button didn't

    declare_counter hist_schlacht
    monitor_event ScrollOpened ScrollOpened prebattle_scroll
        if I_CompareCounter hist_schlacht = 1
            campaign_wait 1
            disable_cursor
            ui_flash_start prebattle_fight_button
            campaign_wait 3
            select_ui_element prebattle_fight_button
            simulate_mouse_click lclick_down
            simulate_mouse_click lclick_up
        end_if
        enable_cursor
        set_counter hist_schlacht 0
        
    end_monitor

[Withwnar]

I think you'd also need to replace the ScrollOpened argument: seige_scroll?

[Gigantus]

pre_battle_scroll is the window with the options: attack, maintain, retreat (wasn't there a fourth option?) whenever you click on a non faction settlement while you have your character selected.

[Withwnar]

Maybe I misunderstand you but that scroll doesn't have the siege buttons on it so "select_ui_element siege_maintain_button" won't work with pre_battle_scroll. It would need to be this I think...

    declare_counter hist_schlacht
    monitor_event ScrollOpened ScrollOpened siege_scroll
        if I_CompareCounter hist_schlacht = 1
            campaign_wait 1
            disable_cursor
            ui_flash_start siege_maintain_button
            campaign_wait 3
            select_ui_element siege_maintain_button
            simulate_mouse_click lclick_down
            simulate_mouse_click lclick_up
        end_if
        enable_cursor
        set_counter hist_schlacht 0
        
    end_monitor

[Gigantus]

You could have a point there, I'll have to check the interface when maintaining a siege and when to initiate an attack versus an army. For some reason I was under the impression they both are the same.

going by dumb reckoning:
siege_scroll == siege_buttons
pre_battle_scroll ==pre_battle_buttons

Edit: Ha, now I remember which button I meant that didn't work in the other thread: pre_battle_retreat_button. Maybe it has the same problem that you mentioned in the OP.
Sorry for being befuddled, it's been a long coding day.

Regarding the 'garrison on immediate attack' issue - I used the GeneralAssaultsResidence event:

    monitor_event GeneralAssaultsResidence TargetFactionType hungary
        and IsTargetRegionOneOf Reichsstadt_Bremen
        and I_SettlementUnderSiege Bremen
        if I_TurnNumber < 100
            create_unit Bremen, BuergerwehrG, num 4, exp 0, arm 0, wep 0
            create_unit Bremen, GrenadiereG, num 1, exp 0, arm 0, wep 0
            create_unit Bremen, MusketiereG, num 2, exp 0, arm 0, wep 0
            create_unit Bremen, PikeniereG, num 3, exp 0, arm 0, wep 0
            set_counter Bremen_siege 1
        end_if
        if I_TurnNumber > 99    ; if they still need this help then they deserve to die
            terminate_monitor
        end_if
    end_monitor

The units get disbanded after the siege via a custom attribute destroy_unit script.

[Withwnar]

When attacking settlements you see first the siege_scroll and then, upon clicking Assault, the pre_battle_scroll. I tried post 8's script and it works every time, so scripted auto-clicking doesn't seem to suffer from this problem, only player clicking does.

GeneralAssaultsResidence: yep, I think that I'll be using both of them for my garrison script: siege_assault_button and, as a backup, GeneralAssaultsResidence (post 3). Despite the soldier count problem with GeneralAssaultsResidence.

[Gigantus]

soldier count problem - do you refer to the garrison spawn? Or are you trying to test the size of the original garrison before adding more units proportional? create_unit adds units as they are listed until there are 20 units in the settlement. Surplus units will not appear anywhere.
My take on it - the added garrison should be in proportion to the settlement size - after all they are a constant number in relation to it, either permanent or recruited from citizenry in RL.

[Withwnar]

I mean this:

However, GeneralAssaultsResidence has its own shortcomings: second half of this post: http://www.twcenter.net/forums/showt...1#post13247247

[Gigantus]

Ah, that's odd - it's the create_unit that gives the problem not the assault event. Never had cause to experience it. I will use the console command then.
Pity that it's useless at AI versus AI.

GarrisonSettlementRatio may help you to determine the local garrison strength. But I don't know how you will do it feasibly as I have no clue how to test for settlement population numbers.

[Withwnar]

That post is covering two unrelated issues. One is that create_unit can disrupt normal recruitment and the other is that spawning during GeneralAssaultsResidence - regardless of create_unit or console_command create_unit being used to do it - causes havoc with battle odds etc.

GarrisonSettlementRatio may help you to determine the local garrison strength. But I don't know how you will do it feasibly as I have no clue how to test for settlement population numbers.

It isn't something I'm after but instead of population numbers you could test the wall level. That kind of implies the level of population.

[Gigantus]

Wall level won' be very accurate as it only implies a max lev of population. Generally it will have a population within the min and max level of that wall level - unless you get cases like that huge level city in TATW with 400 population (forgot the name - that twin city at the river crossing).

[Withwnar]

And any settlement could have been Exterminate Populace'd one or more times. It can't be relied upon but at least it's something that can be determined.

A shame about population. If you knew that a city had only one full unit of a particular type - and therefore how many soldiers in the garrison - then I assume that GarrisonToPopulationRatio could be used to work out what the population count is. That's all pretty academic though because that "if" is a big one.

(Osgiliath by the way )

[Gigantus]

Those two ratio conditions are pretty much a circular reference without being able to ascertain the population.