overthrow_ruler_no_calls CB fails to force liege to abdicate on_success

[zijistark]

This CB, despite its completion tooltip saying that the current ruler will be forced to be abdicate if the rebelling vassal wins, does NOT result in that ruler abdicating. I suspect this is an issue with the CB code, but it might also be related to @Ispil's recent changes to how forced-abdication works (i.e., don't abdicate to a guy that's already abdicated in that realm).

Additionally, I suspect that the regular overthrow_ruler variant of this CB also has the same problem due to a casual experience with it quite awhile ago, but IDK, as I haven't tested it at all recently.

[zijistark]

I checked out the CB code, and unlike the regular overthrow_ruler CB, overthrow_ruler_no_calls (the one right after it -- and the engine seems to select between them for is_revolt_cb = yes-type CBs either randomly or perhaps based upon the relative power of the vassal rebelling, as the _no_calls suffix specifically means that the CB doesn't allow anyone else to join, it doesn't create a revolt title, and it uses the old-school rebellion method of setting the rebel temporarily independent for the duration of the war).

Anyway, I noticed that the CB in question was using emf_willfully_abdicate = yes. I went ahead and changed it to the proper emf_abdicate = yes so that the code runs down the forced abdication path that it should.

While that doesn't explain the problem, it DOES raise some questions... Is it possible that emf_willfully_abdicate is actually not working outside the context of being called by emf_abdicate?

The only other thing of interest in that CB is that the current_heir before abdication is saved as the heir event target, solely so that it can provide the emf_liege_change hint to the new ruler after the abdication (which is, of course, a potentially inaccurate hint since forced-abdication might skip over the heir-apparent, so we should probably move this logic straight into our core abdication code). Perhaps that target conflicts with something?

Probably not, since my style re: naming event targets that are used within [or even more so if entirely contained within] scripted effects, since there's such a larger likelihood of name collisions in actually semi-reusable code such as that.

My guess is that emf_willfully_abdicate is currently not WAD without being first invoked by emf_abdicate (i.e., whatever event target / flag / etc. state it sets up allows it to work).

Of course, our entire abdication pipeline could be broken too, since TBH, I haven't personally noticed any cases of abdications at all in my current playthrough (plenty of claimant faction / antiking faction / independence, etc. working properly but none of those use abdication -- the one I should watch for is the lower CA faction, as a liege losing a war w/ that CB might result in an abdication), but I haven't been looking, and my vassals have been pretty happy consistently, so I've not faced the potential need to abdicate myself.

@Ispil You really ought to verify this. I was under the impression that you tested your recent enhancement of the abdication-heir-picking code & had zero issues when testing it. Maybe so, and maybe there's no problem with that code, but the CB code for what I directly observed[1] is solid & simple AF.

[1] I was a participant in the war on the rebel side (Comte of Holland), because I wanted his liege (Roi of Lotharingia) to have to abdicate to his underage heir, which would allow me to snap up the last Carolingien kingdom in Europe with the HRE Unfication CB.

[Ispil]

emf_willfully_abdicate is nothing more than a rename of the original emf_abdicate, with not a single line of code changed besides the name. You can verify it in this commit: 21f5093#diff-63fa6c46a753a211a787e8cc24f5ef4c