Added as "The ability to randomize a number within a range, E.G., age = (int, 20-25), or troop_loss = (float, 0.2-0.4)"
-
We have updated our Community Code of Conduct. Please read through the new rules for the forum that are an integral part of Paradox Interactive’s User Agreement.
Uhm...maybe I'm missing something, but doesn't the Shia Islam have its own icon (Crescent moon with a Sword) instead of the Sunni heresy icon (red Crescent moon). Also, the Shia isn't a Sunni heresy, according to the 00_religions.txt.
On another note: "More moddable UI, E.G., being able to make specific UIs for specific groups" means being able to mod a muslim ui (for example) for a religious group that isn't muslim, right?
Shia is a Sunni heresy in PB. As a result, it uses the "heresy_icon" defined for Sunni, overriding its own icon.
Nah, it's more that if you wanted to make a unique UI for Orthodox characters as contrasted with Catholic ones, you should be able to do so. Especially useful for fantasy mods.
Ah okay, now I get it. But why? I loooove the Shia Calpihate uprising event *sniff*. Ah well, nevermind. And yeah, so basically for any religion creating its own UI, only instead of restricting it to a religious group you're giving each religion a separate UI. :3
Only way to give them proper relations towards one another; the "religious differences" opinion modifier is nowhere near harsh enough for Sunni-Shia relations.
In my current mod I just found out that the command "port=no" does not mean inland provinces only, so a command for buildings that means inland provinces only. Possibly also something for river provinces only, I'm sure people could find that useful.
Put it in the potential scope and it should work.
River check is already on the list.
The ability to change a title's colour through event, similar to how you can change its name. Say to make it so that the Byzantine, Latin, and Muslim Rum (Ottoman) Empires are all the same title but with different colours and names.
Rum is a kingdom level title, I'm talking about the empire that the Ottomans became after they took Constantinople.
The ability to set a person's title place via culture.
Genghis Khan would no longer be "Khan Genghis" ingame, but "Genghis Khan".
Genghis Khan would no longer be "Khan Genghis" ingame, but "Genghis Khan".
I'd like the ability to set the "from X" dynasty names as formed from suffixes as opposed to prefixes. Currently for instance we can only have "Bob de Scarborough", but I'd like the option to have a "Bob Scarboroughde". So in the cultures code instead of "from_dynasty_prefix = "de "" we'd have the possibility for a "from_dynasty_suffix = "de""
One culture group this would work for are the Iranians, who would have the -i suffix for such names (i.e. Balkhi, Tehrani, Shirazi, etc.)
One culture group this would work for are the Iranians, who would have the -i suffix for such names (i.e. Balkhi, Tehrani, Shirazi, etc.)
.png){kind=avatar}
In addition, a trigger to check the number of holding slots ( location = { max_settlements = <INTEGER>|<PROVINCE_TARGET> } ).
Since we're on the topic of numbers now, as a regular programmer too, this is far and away one of the most infuriating things into which I've run while hacking on CK2: lack of proper numeric (or even flags, in the case of titles) variable support. It's downright terrible the things one has to do to, in the simplest and most supported case of character scope comparison (only because they're the only scopes with numeric variables at all, best I can tell) of one variable to another variable, not a literal float.
The simplest realistic example of which I can think is having, e.g., the variable "dejure_holdings" defined for two or more different characters. It is the [integer] count of the number of holdings that are de facto vassal or below plus demesne titles of a given character that fall into some de jure territory-- let's say a kingdom. The meaning of the variable is irrelevant to the point, but I like immersion. The modder wants to compare these two characters' essentially arbitrary numeric "dejure_holdings" variables to each other and determine which is larger. This fundamental operation, variable comparison, is a prerequisite for almost any useful work that needs to deal with numbers and logic-- long before we get to needing arbitrary [integer] arithmetic even. You'd think that the following syntax would work, but it most certainly does not.
This does not work. If somebody (Meneth, please?) knows the best way to achieve an at-least-approximate numeric comparison sort of an arbitrary number of different instances of the same variable or even the simple one-to-one aforementioned comparison with a hack that doesn't require 14,000 lines of packed comparisons to literal integers-- all completely redundant combinations-- then please let me know. My hacking around at this has only resulted in frustratingly silly solutions.
From an implementation standpoint, it'd be braindead simple to implement a check_variable = { which = "my_variable" value = <TARGET> }, as the numeric variables tagged with their name are already attached to each of those character objects in-game and are even kept statefully, beyond the scope of their utility in some cases, and serialized to savegames. Likewise, set_variable = { which = "my_variable" value = <TARGET> } should naturally come along with that revolutionary feature. I probably shouldn't even think to ask for arithmetic commands like addition of two arbitrarily-valued variables together or multiplication (which allows us to simulate division too). But I will.
The necessity or even impossibility of hacks to try to eek arithmetic out of a pre-Babbage virtual machine are grossly inefficient (far more than the cost of an internal hash table lookup by variable name and performing a floating-point compare, which I admit is still gross for what little computation was accomplished, but it's the difference between 5 seconds and microseconds for some jobs), terribly disabling of smart functionality (e.g., it has killed many micro-projects undertaken to improve AI behavior), and a damn shame to the rest of this neat scripting engine.
Can we have proper variable logic operations please? Could we even have arithmetic operations on those variables (existing change_variable command with a target scope instead of a literal value would cover addition-- multiplication or division would be the only thing to require addition of new syntax and are less important)? In other words, the commands already exist and have a syntax that would naturally apply in congruence with the rest of the language. Just allow them to use target scopes. It's OK if they're only available for characters, although, like title flags (!), they would also be very useful for titles, particularly in combination with the increasingly dynamic title support.
The simplest realistic example of which I can think is having, e.g., the variable "dejure_holdings" defined for two or more different characters. It is the [integer] count of the number of holdings that are de facto vassal or below plus demesne titles of a given character that fall into some de jure territory-- let's say a kingdom. The meaning of the variable is irrelevant to the point, but I like immersion. The modder wants to compare these two characters' essentially arbitrary numeric "dejure_holdings" variables to each other and determine which is larger. This fundamental operation, variable comparison, is a prerequisite for almost any useful work that needs to deal with numbers and logic-- long before we get to needing arbitrary [integer] arithmetic even. You'd think that the following syntax would work, but it most certainly does not.
Code:
# we're in some character scope; set the variables (contrived, obviously)
set_variable = { which = dejure_holdings value = 73 }
FROM = { set_variable = { which = dejure_holdings value = 119 } }
# ... later on in same context as before (unaware of the values in the variables)
if = { limit = { check_variable = { which = dejure_holdings value = FROM } }
# greater than or equal to FROM's variable "dejure_holdings"
# ...
}From an implementation standpoint, it'd be braindead simple to implement a check_variable = { which = "my_variable" value = <TARGET> }, as the numeric variables tagged with their name are already attached to each of those character objects in-game and are even kept statefully, beyond the scope of their utility in some cases, and serialized to savegames. Likewise, set_variable = { which = "my_variable" value = <TARGET> } should naturally come along with that revolutionary feature. I probably shouldn't even think to ask for arithmetic commands like addition of two arbitrarily-valued variables together or multiplication (which allows us to simulate division too). But I will.
The necessity or even impossibility of hacks to try to eek arithmetic out of a pre-Babbage virtual machine are grossly inefficient (far more than the cost of an internal hash table lookup by variable name and performing a floating-point compare, which I admit is still gross for what little computation was accomplished, but it's the difference between 5 seconds and microseconds for some jobs), terribly disabling of smart functionality (e.g., it has killed many micro-projects undertaken to improve AI behavior), and a damn shame to the rest of this neat scripting engine.
Can we have proper variable logic operations please? Could we even have arithmetic operations on those variables (existing change_variable command with a target scope instead of a literal value would cover addition-- multiplication or division would be the only thing to require addition of new syntax and are less important)? In other words, the commands already exist and have a syntax that would naturally apply in congruence with the rest of the language. Just allow them to use target scopes. It's OK if they're only available for characters, although, like title flags (!), they would also be very useful for titles, particularly in combination with the increasingly dynamic title support.
Last edited:
Hell, a trigger and an effect. For most maps, there are plentiful extra baronies (sometimes 15+ in SWMH) defined such that it'd be fine to adjust max_settlements at runtime, just as the engine does in province history files. If you bumped max_settlements beyond the linked county title's number of defined baronies or 7, well, then undefined behavior results. Like the rest of such effects. This too would be a province scope.
A low priority, but it allows scripted historical map rebalancing, even just from history file effects let alone due to dynamic conditions in the game. Or dynamic map reorganization scenarios. Again, a low priority.
Added as: The ability to change a title's color by event-
Added as: Ability to put someone's rank after their name (E.G., Genghis Khan rather than Khan Genghis) dependent on culture.
Added as: Ability to use a cultural suffix rather than prefix with "from X" dynasty names. E.G., "Scarboroughde" rather than "de Scarborough"
Added as: The ability to change the number of holding slots in a province by event
Added as: A condition to check the current filled holding slots in a province, and a condition to check the number of holding slots in a province
CK2Plus uses variables quite a bit, so I'd recommend you look into those event files. I'm not sure what limitations there are to how these variables can be used though.
Wiz's AI kingdom creation code, faction variable maintenance, and realm size tracking (before he-- or at least I assume it was he-- added the realm_size trigger) are where I grokked the syntax from in the first place. Nowhere does he actually compare a variable in one character scope to a same-named variable in another character scope. Nowhere is there actual numeric variable comparison. There is comparison of a variable with a hard-coded literal value (or 500 comparisons to achieve an approximation to a real variable comparison-- "is A > B?" rather than "is A > 10?"). Knowing that this is definite must-have for any intelligent logic, stateful or not, and that the implementation would be a no-brainer given the support already there while the preexisting syntax also matches perfectly-- to allow variables to be compared or set to targets rather than just hard-coded literals, I spent many hours trying to get this to work (and many more hours trying to devise strategies for workarounds).
This is something simple and extremely powerful Paradox has overlooked. Oh, to be a developer at Paradox for a week (4 days to orient myself and 1 afternoon to make the change, and what, you thought I was going spend the weekend on it too?). I'd do it for free. The reason they've overlooked it is that whenever they run into something that needs to, well, be able to compare numbers and perhaps perform general arithmetic, they're coding it directly into the executable. That makes sense, of course, as usually for such tasks one simply wouldn't think to settle for an obtuse modding syntax and any restrictions on their calculations (let alone runtime performance hits from using dynamically-named variables, at the same level CK2+ incurs them currently, rather than statically compiled code in the executable). Unfortunately, that means you can't calculate shit if you're a modder. Whether you're trying to make a smart dynamic scenario generator that runs on startup or you're trying to keep track of certain weights to make the AI act more intelligently (either in general or for the constraints of your mod), you're just out of luck. You don't get to just open up the appropriate C++ source files and alter some calculations or what have you, compile, and be done with it. Somebody has to let them know that fully implementing their already-there variable support (syntax wouldn't even change, unless you also implement multiply/divide, which can be done without, relatively speaking) would be a boon for modders both now and in future games.
Double-post, sorry. Doing it anyway.
I was just [starting] browsing the EUIV forum and within the first 5 seconds of scanning the threads, what did I see but a [perhaps ill-formed] question addressed to Paradox about supporting variables.
http://forum.paradoxplaza.com/forum/showthread.php?704299-variables!
People do really want this. And I think I put the request in pretty specific and formal terms in my first post here on the subject. If you don't think so, let me know.
I was just [starting] browsing the EUIV forum and within the first 5 seconds of scanning the threads, what did I see but a [perhaps ill-formed] question addressed to Paradox about supporting variables.
http://forum.paradoxplaza.com/forum/showthread.php?704299-variables!
People do really want this. And I think I put the request in pretty specific and formal terms in my first post here on the subject. If you don't think so, let me know.