Confirmed has_won_war_against trigger no longer accepts event targets and scopes

[Loganplayseu4]

Integrity​

I have verified my game files (on Steam)​

Yes

I have disabled all mods​

Yes

Required​

Summary​

has_won_war_against trigger no longer accepts event targets and scopes

Description​

has_won_war_against is a trigger for missions, events, etc that, as the title implies, allows you to check for if someone has won a war against someone else, with an additional clause for how recently it has to of been.

However, as of 1.36.1, this trigger, which used to accept inputs for the who clause such as "emperor", "ROOT", "PREV", etc, no longer does, seeing these as invalid.

Now, this wouldn't be as big a deal, however, it also breaks the non-diplomatic completion criteria for the Domination Ottomans mission 'The Relations With Venice', making it impossible to complete. Surprised this slipped past QA, given that it winds up breaking actual existing content that was actively adjusted during KoK/1.36 dev.

Attached are a picture of the bug from my mod (Attachments), and a picture of the bug from vanilla Domination Ottomans (Screenshot).

Steps to reproduce​

You can either replicate this by using ROOT/PREV/THIS/emperor/any event target in has_won_war_against as a trigger, OR as Ottomans, win a war against Venice within the past 25 years, and insult them, and notice that you still cannot complete the mission because said criteria isn't true... or just notice that Venice doesn't display their name in the trigger.

Game Version​

1.36.1

OS​

Windows

Additional​

Bug Type​

• Other

Attachments​

Screenshot​

 

[Loganplayseu4]

Disregard: was a one-time refusal to update. Actual bug consists of the tooltip being bugged.

 

[grotaclas]

I tried it and I can reproduce that the PREV is missing in the tooltip, but the Ottoman mission still works for me when I declare the war:

I think the issue is not the event-target or scope, but instead the bug is that it doesn't count wars which were won by the defender.

The developers are already looking into this issue(except the missing country in the tooltip), because it also applies to the event "Rumelihisari Castle":

Rumeli Hisari event not prevented by victory

Not really a bug but more a design question. So I played Byzantium and successfully took back my cores from the Ottomans in the first war. But then I still got the event where the Ottomans build a castle "On our side of the Bosporus", I lose...

forum.paradoxplaza.com

So it is likely going to get fixed in the next patch

 

[Loganplayseu4]

I tried it and I can reproduce that the PREV is missing in the tooltip, but the Ottoman mission still works for me when I declare the war:
View attachment 1054919

I think the issue is not the event-target or scope, but instead the bug is that it doesn't count wars which were won by the defender.

The developers are already looking into this issue(except the missing country in the tooltip), because it also applies to the event "Rumelihisari Castle":

Rumeli Hisari event not prevented by victory

Not really a bug but more a design question. So I played Byzantium and successfully took back my cores from the Ottomans in the first war. But then I still got the event where the Ottomans build a castle "On our side of the Bosporus", I lose...

forum.paradoxplaza.com

So it is likely going to get fixed in the next patch

I assume you saw the discussion in the mod co-op? Yea, I agree here, hence me putting the reply I did.

 

[grotaclas]

I assume you saw the discussion in the mod co-op? Yea, I agree here, hence me putting the reply I did.

I'm not in the mod co-op anymore. Did you also discover that it is broken for defensive wars? Or does the issue lie somewhere else?

 

[Loganplayseu4]

I'm not in the mod co-op anymore. Did you also discover that it is broken for defensive wars? Or does the issue lie somewhere else?

In the case of the vanilla one, it was indeed a defensive war (specific circumstances were that it was a defensive war inherited from the Mamluks when I made them my Eyalet), hence why I thought you saw what I said there.

In the case of the modded instance, it was a one-off refusal to update.

 

[Qloc_knee_armor]

Hello there! With your help, we have now confirmed the issue and added it to our database!