~ Captain's Log ~

[Zarathustra_the]

See the thing is, this would not handle if multiple curses were in play. Because flags themselves naturally override. I am talking about a multi-instance compatible system.

Also it would only be valid so long as both characters remained in the same province. I would like to be able to have the characters meet only in passing...

 

[richvh]

You'd have the same problem with any other system. As far as multiple curses... I don't see why the flags wouldn't work. Anyway, start a new thread to further discuss this. We've cluttered up the Captain's thread enough.

 

[jursamaj]

But really, if you can't come up with pseudocode you haven't thought it out well enough …

That's just plain BS. We both *did* post pseudocode, and it wasn't comprehended. We both have thought of this quite enough to know what we want, but since there *is* no example syntax of what we want, pseudocode simply doesn't convey it well.

It actually appears that you *do* understand the question, which is why you suggested your kludge with a generic flag plus the flag@scope. Both Z and I both are asking if you can set a flag@scope, and then test for the existence of *any* flag@scope, whatever the original scope. It appears the answer is "no".

As Z pointed out, your kludge fails when Bob sets my_flag@<Bob's ID> on John, the Tom sets my_flag@<Tom's ID> on John. Both would set my_flag on John. Either: one of the them will later remove both the generic & scoped flags, leaving John with the other scoped flag but no generic flag; or neither will remove the generic flag, and subsequent events will keep seeing the generic flag when there is no scoped flag.

The opinion_modifier route has the benefit of 'has_any_opinion_modifier = <modifier>' and 'random_opinion_modifier_target', to scope to the target of the modifier.

 

[Zarathustra_the]

You'd have the same problem with any other system. As far as multiple curses... I don't see why the flags wouldn't work. Anyway, start a new thread to further discuss this. We've cluttered up the Captain's thread enough.

No the original question was for Captain Gars who you are certainly not, are we getting any additional commands to enable us to manipulate the dynamic flags, it was his benefit not yours I bothered with pseudo-code rather than just telling you to jack off.

 

[richvh]

So you use had_character_flag to expire the generic flag, rather than the event string.

 

[zijistark]

Anyhow, @Captain Gars, it looks like you overlooked dynasty flags (stored in the dynasty object, accessible from any character scope) for dynamic script flags. Was this intentional? It'd be rather handy to be able to use dynasty flags in this fashion as well (e.g., simple handling of dynastic blood feuds, etc.).

A very, very minor request (so minor), but in the event that you want to present the complete flag API with this feature, here's a prod for ya.

 

[zijistark]

See the thing is, this would not handle if multiple curses were in play. Because flags themselves naturally override. I am talking about a multi-instance compatible system.

Also it would only be valid so long as both characters remained in the same province. I would like to be able to have the characters meet only in passing...

Sounds like what you need is an @unique pseudo-dynamic-script-flag that substitutes a unique, never to repeat, number into the flag ID upon each use (to be combined with dynamic scopes embedded in the flags). But, then, all of this is just a hack around a fully relational model for titles, characters, and provinces (AND A NEAT HACK THAT I WILL TAKE, SIR!).

Also, and I risk digression from the thread topic here, but I doubt you'll take any issue: @richvh: never, ever say that a flag [in CK2script land] takes only a single bit of memory. Nosiree. This is not statically-compiled C++, no no no. Every character in that flag name costs you bucks, and every flag in that [hopefully] hash table of flag names mapped to [hopefully] 32-bit dates costs you more bucks, increasingly so.

... And we're back on topic.

 

[illathid]

Anyhow, @Captain Gars, it looks like you overlooked dynasty flags (stored in the dynasty object, accessible from any character scope) for dynamic script flags. Was this intentional? It'd be rather handy to be able to use dynasty flags in this fashion as well (e.g., simple handling of dynastic blood feuds, etc.).

A very, very minor request (so minor), but in the event that you want to present the complete flag API with this feature, here's a prod for ya.

I would second the request for dynasty flags as well. Lets just say it'd make the book of grudges easier to deal with.

 

[Captain Gars]

Just to clarify, each did_something_to_999 will be a unique flag, correct? So I couldn't do:

random_character = {
   limit = {
     has_character_flag = did_something_to_ # affect anybody who has the flag in relation to any other body
   }
   ...
}

If you play character 999 and set the flag did_something_to_@ROOT on a number of characters, then all of them will have the flag did_something_to_999, and thus can all be reached with:

any_realm_character = {
   limit = {
     has_character_flag = did_something_to_999
   }
   ...
}

or, if character 999 is in the ROOT scope:

any_realm_character = {
   limit = {
     has_character_flag = did_something_to_@ROOT
   }
   ...
}

 

[Captain Gars]

What I mean is, is it possible to have some events set character flags of the form some_flag_@ROOT (or other scope, that's not the important part), such that multiple people have the flag with multiple people's IDs, and then in some other trigger, be able to test if a character has *any* some_flag_<any ID>? Or is that something we're best sticking with the dummy opinion modifiers for?

No. But again, I don't understand what you're after. If the id appended at the end doesn't matter when you want to find those characters, why have them?

 

[Zarathustra_the]

Captain, what about characters outside of your realm? Will that still require the heavy resource task of scoping to all realms and then working back?

 

[zijistark]

Captain, what about characters outside of your realm? Will that still require the heavy resource task of scoping to all realms and then working back?

See: any_opinion_modifier_target, random_opinion_modifier_target from patch 2.3.

 

[Captain Gars]

Captain, what about characters outside of your realm? Will that still require the heavy resource task of scoping to all realms and then working back?

I'm guessing what you're after are scopes like any_character/random_character etc. I'm thinking of adding them but such triggers are very performance heavy and should not be used without great care.

 

[Captain Gars]

Update:

- Added any_character trigger scope
- Added any_province trigger scope
- Added any_landed_title trigger scope
- Added any_character effect scope
- Added any_province effect scope
- Added any_landed_title effect scope
- Added random_character effect scope
- Added random_province effect scope
- Added random_landed_title effect scope

"With great power comes great responsibility"

These triggers and effects should be used with extreme care - especially the triggers, and especially the trigger any_character. If you run into performance issues, you are on your own...

 

[ngppgn]

Update:

- Added any_character trigger scope
- Added any_province trigger scope
- Added any_landed_title trigger scope
- Added any_character effect scope
- Added any_province effect scope
- Added any_landed_title effect scope
- Added random_character effect scope
- Added random_province effect scope
- Added random_landed_title effect scope

"With great power comes great responsibility"

These triggers and effects should be used with extreme care - especially the triggers, and especially the trigger any_character. If you run into performance issues, you are on your own...

Sorry if this is derailing, but I am very curious:

-why are the triggers more dangerous than the effects?
-it is more efficient (I mean, will be, when the update is released) to use, say, any_character = {} or any_independent_ruler = { any_realm_character = {} } ?
-when you recommend using them with care, what are you hinting at? Just using more restricted scopes whenever possible? Or whenever possible using limit = {} to restrict them, or asomething else?

 

[richvh]

Use more restrictive scopes when possible, because using these, especially any_character, will eat up a lot of processing time.

 

[jursamaj]

Sorry if this is derailing, but I am very curious:

-why are the triggers more dangerous than the effects?
-it is more efficient (I mean, will be, when the update is released) to use, say, any_character = {} or any_independent_ruler = { any_realm_character = {} } ?
-when you recommend using them with care, what are you hinting at? Just using more restricted scopes whenever possible? Or whenever possible using limit = {} to restrict them, or asomething else?

All of those would be important. Always use the smallest scope that will accomplish what you want.

The problem with any_independent_ruler & any_realm_character is that they apparently ignore the ruler whose scope they starts in. This can be very annoying. Also, unless it's been addressed recently, any_independent_ruler doesn't catch some people who are in revolt, but they don't show up as a any_realm_character of their original liege either. Thus they can't be scoped in this way at all.

Triggers are especially dangerous if they have to be evaluated continuously, for example in a MTTH event trigger. Effects are likely to be executed more rarely.

 

[richvh]

Use event targets when appropriate to avoid evaluating any_ or random_ scopes multiple times in an event or an event string.

 

[Captain Gars]

All of those would be important. Always use the smallest scope that will accomplish what you want.

The problem with any_independent_ruler & any_realm_character is that they apparently ignore the ruler whose scope they starts in. This can be very annoying.

This is mostly standard in our games though, to not include the scope your in.

Also, unless it's been addressed recently, any_independent_ruler doesn't catch some people who are in revolt, but they don't show up as a any_realm_character of their original liege either. Thus they can't be scoped in this way at all.

This has been fixed.

 

[Captain Gars]

Update:

- Added ai_will_do to minor titles
- Added ai_will_do to religious titles