Is it possible to test when two named characters are in the same army?

[es157]

The title sums it up. I seek a script that is able to test when two named characters are located in the same tile. Can be inside the same settlement or outside in the same army, whichever works.

Any suggestions are welcome. I have done a similar thing before, but it was specific about two characters inside one specific settlement, which I suppose makes it much easier.

[Gigantus]

I_CharacterTypeNearCharacterType comes to mind with a zero distance value. It will however trigger twice as the character types are identical.

[es157]

I_CharacterTypeNearCharacterType comes to mind with a zero distance value. It will however trigger twice as the character types are identical.

Can I use "leader" as a character type? Can I in any way filter the parameter by label or trait?

[Gigantus]

CharacterType in your case would be 'named character'.

It will not be possible to effectively define further as the condition literally means 'any [character type] of this faction near any [character type]** within this range'. Meaning that if you test a character for a specific trait first and then add this condition it may return 'true' but it could simply be that character A (the tested one) has the trait but it's character B and C that are together.

** from any faction - as the range will be zero it can only be from the same faction.

[es157]

CharacterType in your case would be 'named character'.

It will not be possible to effectively define further as the condition literally means 'any [character type] of this faction near any [character type]** within this range'. Meaning that if you test a character for a specific trait first and then add this condition it may return 'true' but it could simply be that character A (the tested one) has the trait but it's character B and C that are together.

** from any faction - as the range will be zero it can only be from the same faction.

This approach seems promising on the surface, but it has this limit. I can't specify the characters individually.

Can you think of any other way? The best I can think of is making hundreds of monitors testing for each settlement where the two characters may be. This is ridiculously complex and not worth it. Probably would break the game.

Another alternative could be using IsRegionOneOf. Could it work to specify the characters? No doubt it would still require lots of monitors, but I could optimise it to require fewer than the above method.

By the way, I should clarify that it is OK if the two characters are not in the same tile, as long as they are close to each other, so being in the same region can suffice if the rest fails.

[Gigantus]

IsRegionOneOf tests for the region as the name suggests. It will not be suitable for your purpose as it will only test for presence of the individual character, see below as well.

The main issue you have is to figure out how to reference the characters. Even if you ran a incremental monitor that tests if a character is on a specific tile and then increments and then performs a check if the counter is increased again yo will still lack the reference required to perform an actual on that character.

[Jadli]

Think the best solution for you is this "HighestAttAdjacentChar piety named_character >= 5"

Give to the special character(s) an unsued attribute (either widely unused, or simply an attribute thats mean for other character types), hence the value of the attribute will not change over time, and you can reliably test this, I for example used "Magic" for dungeon characters in my mod to target them for missions... but you can literally use dozens of others, and also 10 times each (for exaple Magic 1 will be Robb, Magic 2 Jon Snow, etc). Not sure how much is "adjacent", but I assume its pretty close...

You can combine it with the idea by Gigantus, to narrow down the possible error, I think thats the closest you can get to what you want with this engine.

[es157]

Think the best solution for you is this "HighestAttAdjacentChar piety named_character >= 5"

Give to the special character(s) an unsued attribute (either widely unused, or simply an attribute thats mean for other character types), hence the value of the attribute will not change over time, and you can reliably test this, I for example used "Magic" for dungeon characters in my mod to target them for missions... but you can literally use dozens of others, and also 10 times each (for exaple Magic 1 will be Robb, Magic 2 Jon Snow, etc). Not sure how much is "adjacent", but I assume its pretty close...

You can combine it with the idea by Gigantus, to narrow down the possible error, I think thats the closest you can get to what you want with this engine.

Oh, this one sounds very good. Can you give one working example for me to base myself on? I never used this before.

Also, in your experience how does the game interpret "adjacent"? Is it nearby, same tile, same region? Or is it the closest character in the map who has the required attribute? If it's the latter, it may be useless.

[Jadli]

I dont have a script example right now, its not often used in scripts... but you simply use CharacterTurnStart, CharacterTurnEnd or CharacterSelected (or other) as monitor_event (I assume you want this in a script), so something like this should work

monitor_event CharacterTurnStart CharacterIsLocal
and IsGeneral
(and Trait other_unique_character 1 if you want two specific characters to meet I guess)
and HighestAttAdjacentChar piety named_character = 5

do something

terminate_monitor
end_monitor

As I said, not really sure what adjacent means in this context, you will need to test, unless someone knows. In the vanilla its for getting negative traits for generals when near witches, so I assume it ought to be close, maximally within a region, but probably less?

[Gigantus]

Well, adjacent means 'next to', so it has to be a very short distance if not right next to each other. Certainly will work if both character are in the same army\town, possibly also when next to other if not some short distance apart.

As you said: needs testing to confirm.

Edit: it will work as EDA\EDCT trigger as well.

[es157]

Oh perfect. I confess I was quite pessimistic about my prospects when I created this thread, but it turns out it paid off. I think it will work exactly as I intend.

Gonna share the results here soon.

[es157]

So it seems this method is more restrictive than I had thought or would like, but it works fine.

The "adjacent" character must be exactly one tile away from the monitored character. Being two tiles or more away doesn't work, and being in the same tile doesn't work either. This seems a bit silly, as in vanilla the general would only be cursed if he stood right on the side of a witch, and nobody does that.

In any case, I will use this method. Thanks for the suggesting, Jadli.

[Gigantus]

'one tile away' as in ' there is an open tile between them' or 'right next to'?

Thanks for testing and coming back with the results.

And it would be the witch moving next to the general (in the slave faction's turn) not vice versa.

[es157]

'one tile away' as in ' there is an open tile between them' or 'right next to'?

Thanks for testing and coming back with the results.

And it would be the witch moving next to the general (in the slave faction's turn) not vice versa.

Yes, it means the character must be right next to yours, the shortest distance possible. And it doesn't work if they are merged together, sadly.

[Gigantus]

Thanks for confirming - so 'adjacent' lives up to it's name. Which unfortunately makes it unsuitable for your initial purpose.

So you are back to a multitude of monitors (one for each settlement) and incremental counters - all of which only work for settlements and might still have an issue with applying a trait\ancillary.

Idea:
CharacterTurnStart monitor that tests for presence in a settlement and increases a counter, counters (from other settlements as well) gets reset with FactionTurnEnd monitor.
EDCT\EDA CharacterTurnEnd trigger checks for counter value (> 1) and continued presence in settlement, then applies trait\ancillary. Drawback - one of the characters may not be in the settlement anymore and thus not receive the trait\ancillary.

[es157]

Thanks for confirming - so 'adjacent' lives up to it's name. Which unfortunately makes it unsuitable for your initial purpose.

So you are back to a multitude of monitors (one for each settlement) and incremental counters - all of which only work for settlements and might still have an issue with applying a trait\ancillary.

Idea:
CharacterTurnStart monitor that tests for presence in a settlement and increases a counter, counters (from other settlements as well) gets reset with FactionTurnEnd monitor.
EDCT\EDA CharacterTurnEnd trigger checks for counter value (> 1) and continued presence in settlement, then applies trait\ancillary. Drawback - one of the characters may not be in the settlement anymore and thus not receive the trait\ancillary.

Actually I was almost settled for using the Adjacent line anyway, even though it's imperfect. Unfortunately I don't see a viable alternative.

I haven't though much about the settlement checks because I assume it would take too much coding. It would make a heavy campaign just to implement a small event feature. I don't know if I understand exactly what you're suggesting, though. Would your suggestion require 199 monitors? (since my map has 199 settlements)

[Gigantus]

If you can come up with a monitor that uses all I_xyz conditions then you can put those into IF sections which can then be put into one single monitor, thereby having an absolute minimal impact on turn end processing time. Else it's one for each settlement which will start to have an impact eventually as you keep adding monitors in your script.
What kills the processing speed is ACTIVE monitors, eg how often per turn a monitor gets checked - which depends on the event being used.

So if you have 199 Character event monitors that technically get checked for every character on the map then you quickly ramp up numbers.

[es157]

I understand. Unfortunately, I don't think I can put all the necessary parameters in a single monitor, because I need to check that two separate characters are in one place at a time. This will require me to create a counter for when character X is in each possible place, then create the monitors for the other using this counter as a parameter.

I'm not great at math, but I think this would result in 199 times 199 monitors, assuming I want to do it clean without any cuts. Of course I could try adding ifs to reduce the number of monitors, but the number would still be ridiculous.

Anyway, this talk was productive. I know my limits.

[Gigantus]

Creating and using counters should not be an issue as checking counters is one of the I_xyz conditions. See my earlier (post #15) idea.

And it will be only 199 monitors as a character event monitor checks every character. Note that event counters do not need to be declared, they always exist in a zero value state, only ordinary counters need to be declared.

--- Script ---

monitor_event CharacterTurnStart EndedInSettlement
    and SettlementName [name of settlement]
    inc_event_counter [name of settlement]_presence 1
end_monitor

monitor_event FactionturnEnd TrueCondition
    set event_counter [name of settlement]_presence 0
end_monitor


--- Trigger (ancillary example) ---

WhenToTest CharacterTurnEnd 
    Condition EndedInSettlement
    and SettlementName [name of settlement]
    and I_EventCounter [name of settlement]_presence > 1
AcquireAncillary [name of ancillary] chance 100

[es157]

It's still a lot. I could go through with it to implement something bombastic, but in this case it's just a minor feature.

In any case, I'll keep your suggestion in the pocket. It may come in handy.