Suggestions for Improved Moddability

[Thezezeal]

That would still do nothing about what you want.
if they are born in year 1 then you set them to be 25 that does not make them still born in year 1, it would push their birth date to be in the year -25 (-24 more likely as 0 will count as a year as our date class is just a wrapper for an integer I believe)
So you will still get the issues of a negative date not being supported.

Thanks for the reply.
Could something like an 'offset' for age work, then? Or would that require too big a change to the game?
Like "GameAge = RealAge + AgeOffset" (so a character would still be '1' in RealAge, but look 1+20 and be treated as such by anything that checks their age?

Even a 1.1.1 start won't work well AFAIK. Because of the way the engine deals with dates, 1.1.1 is (again AFAIK) unsafe. See for instance how Augustus in the vanilla files is given as being born on 3 AD instead of 1 AD. Or how title history for things that should be set for the title from the get-go (e.g. whether a title is initially active) is set to 20.1.1 in the vanilla files.

Yeah, I've noticed some stuff like that. What I've got now "appears" to be working OK in general. The few bugs I've noticed I have managed to mainly work around, but... :shrug: There could be a load more issues I'm not seeing :S

The force_age idea can also be nice for situations where you don' want a historical character to exist in one start date, but need them to be a certain age in the next start date and that age is larger than the gaps between the dates.

A work around I've found for that is a combination of "create_character" and "inherit". It's not exactly the best (hence why I'd like a better solution), but it can work OK.

On starting the Game in a suitable era, Scope to the character, create a new character with the 'real' data you want, and then inherit+kill the historical character. If it's done right, it even works for the player character.

 

[blackninja9939]

Thanks for the reply.
Could something like an 'offset' for age work, then? Or would that require too big a change to the game?
Like "GameAge = RealAge + AgeOffset" (so a character would still be '1' in RealAge, but look 1+20 and be treated as such by anything that checks their age?

That would probably be too big of a change, age gets referenced in a lot of places in the code

A work around I've found for that is a combination of "create_character" and "inherit". It's not exactly the best (hence why I'd like a better solution), but it can work OK.

On starting the Game in a suitable era, Scope to the character, create a new character with the 'real' data you want, and then inherit+kill the historical character. If it's done right, it even works for the player character.

That will also still likely have issues I mentioned before with negative birth dates


I honestly don't understand why you are doing this anyway, just have for the purpose of your mod the year 3001 be your first year, that way you can just use pre 3000 dates for negative dates (sure you'll end up with year 0 but eh that is not really an issue). This is what we did in AGOT but with the year 8000.
There is no downside except for the fact when people see under 3000 they have to mentally think ok this is BC or the equivalent for your mod's time period, and if you just put a disclaimer for that in the game start pop up it should be easy enough to understand.

 

[ngppgn]

That would probably be too big of a change, age gets referenced in a lot of places in the code


That will also still likely have issues I mentioned before with negative birth dates


I honestly don't understand why you are doing this anyway, just have for the purpose of your mod the year 3001 be your first year, that way you can just use pre 3000 dates for negative dates (sure you'll end up with year 0 but eh that is not really an issue). This is what we did in AGOT but with the year 8000.
There is no downside except for the fact when people see under 3000 they have to mentally think ok this is BC or the equivalent for your mod's time period, and if you just put a disclaimer for that in the game start pop up it should be easy enough to understand.

That makes me wonder how dates are gonna be done in Imperator. If Cds need to convert BC dates into AUC or something similar... I wouldn't want to be in their shoes.

Now, how is "age being referenced in multiple places" an issue? You just need to have a GetAge() method/accessor/whatever you call it in cpp and make the tweak there once...

 

[theStormWeaver]

That makes me wonder how dates are gonna be done in Imperator. If Cds need to convert BC dates into AUC or something similar... I wouldn't want to be in their shoes.

Now, how is "age being referenced in multiple places" an issue? You just need to have a GetAge() method/accessor/whatever you call it in cpp and make the tweak there once...

Imperator will use AUC, which is a common choice among Antiquity focused games/mods.

If the code doesn't use an accessor method already, changing every reference to do so would be a very large undertaking.

 

[blackninja9939]

That makes me wonder how dates are gonna be done in Imperator. If Cds need to convert BC dates into AUC or something similar... I wouldn't want to be in their shoes.

Now, how is "age being referenced in multiple places" an issue? You just need to have a GetAge() method/accessor/whatever you call it in cpp and make the tweak there once...

Except there is definitely places that check the variable directly when they instead mean to be using GetAge, as when that method was first made it purely returned the variable without modifying the output of GetAge to be anything but the age member variable.
Combined with then having to pick and choose what places should use the masking vs which should just use the real age. Not worth the time when there is a perfectly easy workaround in the script, not ideal workaround but has no real downsides and it is used in the big mods anyway.

 

[Andrelvis]

I honestly don't understand why you are doing this anyway, just have for the purpose of your mod the year 3001 be your first year, that way you can just use pre 3000 dates for negative dates (sure you'll end up with year 0 but eh that is not really an issue). This is what we did in AGOT but with the year 8000.
There is no downside except for the fact when people see under 3000 they have to mentally think ok this is BC or the equivalent for your mod's time period, and if you just put a disclaimer for that in the game start pop up it should be easy enough to understand.

That is a good point. 10001 would work as well, with the added benefit that it is easier to people to just mentally put an 1 in front of the year, and that it is actually a calendar that exists in reality (the so-called "Human Era").

The only issue I've found with dates 10000 and over is that all buildings start off constructed, but that can be solved by using "has_game_started = yes" in the potential. And doing so doesn't break buildings being automatically present on start due to tech, either. It would be nice if that issue were fixed in the engine, though, if that is feasible. Do you know if there would be other problems with dates over 9999?

 

[Andrelvis]

That makes me wonder how dates are gonna be done in Imperator. If Cds need to convert BC dates into AUC or something similar... I wouldn't want to be in their shoes.

Just look at how those things were done for EU: Rome. They used AUC for all dates in the scripts.

 

[blackninja9939]

That is a good point. 10001 would work as well, with the added benefit that it is easier to people to just mentally put an 1 in front of the year, and that it is actually a calendar that exists in reality (the so-called "Human Era").

The only issue I've found with dates 10000 and over is that all buildings start off constructed, but that can be solved by using "has_game_started = yes" in the potential. And doing so doesn't break buildings being automatically present on start due to tech, either. It would be nice if that issue were fixed in the engine, though, if that is feasible. Do you know if there would be other problems with dates over 9999?

Not part of the engine that is game level.
Not looked much into that but I would assume it is less about the year being over 9999 and more that you need to fix up your tech history which would auto build buildings where possible. If that still has issues then just use a lower year

 

[jursamaj]

It seems like using a large signed integer, and the ability to input and output in appropriate forms (BC/AD/AUC/whatever), the engine could handle *any* date.

 

[Andrelvis]

It seems like using a large signed integer, and the ability to input and output in appropriate forms (BC/AD/AUC/whatever), the engine could handle *any* date.

The integer is already signed, I think. In game.log, we see the following line:

[history.cpp:217]: Executing History from -1.1.1 to 2.1.1

Furthermore, from that it seems that 0.1.1 (or 1.1.1 or similar) is used as a date for the default "history" (e.g. the data in the province history files that isn't assigned to a particular date, representing the situation before the actual history begins). That would, of course, be a barrier to using negative dates, but it could be solved by moving the arbitrary "default history" date to -10000 or something like that.

 

[ngppgn]

Looking at Hoi4wiki, I so wish we had their variables in ck2. They can:
1- have temp_variables that can be used in triggers as well as in effects, so all kinds of arithmetic is possible in triggers.
2- these variables also work as event scopes.
3-can be clamped
4-can be rounded with a single command (and when it comes to pdscript arithmetic, the more succint, the less painful to read and understand.
5-can be given a random number
6-can be given the value of a hardcoded stat (so e.g. add_to_variable = { var1 = martial } ).
7-can be compared from different scopes in a more easy way, so e.g. check_variable = { which = var1 value = liege.spouse.father.prestige }
8-can be "targeted" you can store a reference to a second scope as well as a nomber, such as set_variable = { which = new_var@new_character value = 1 } (however, this seems to be subject to the same uses dynamic flags are in ck2script).
9- use an abbreviated syntax: check_variable = { var1 > var2 } instead of check_variable = { which = var1 which = var2 }

 

[Andrelvis]

4-can be rounded

It would be nice to be able to do that with a single step, though we can still do it with two steps:

    divide_variable = { which = population_size value = 1000 }
    multiply_variable = { which = population_size value = 1000 }

 

[ngppgn]

It would be nice to be able to do that with a single step, though we can still do it with two steps:

    divide_variable = { which = population_size value = 1000 }
    multiply_variable = { which = population_size value = 1000 }

Yeah, will precise my statement above

 

[Andrelvis]

Yeah, will precise my statement above

Yup, but when I read your post that wasn't there yet

In any case, I very much agree with you that it would be great to have those features. I didn't even know HoI had that sort of variable moddability...

 

[ngppgn]

Yup, but when I read your post that wasn't there yet

In any case, I very much agree with you that it would be great to have those features. I didn't even know HoI had that sort of variable moddability...

I think it didn't at the start, but it was added like one or two patches ago

 

[Thezezeal]

Would it be possible for Artifacts to have multiple effects with individual triggers, similar to how dynamic blocks on event descriptions work?

Something like :

effect = {
   trigger = {
      martial = 5
      NOT = {
        martial = 10
      }
    }
    combat_rating = 1
}
effect = {
   trigger = {
      martial = 10
    }
    combat_rating = 2
}

Right now I'm periodically checking for appropriate artifacts and using an event to swap them out, but it could be useful to be able to define it inside the artifact itself.

 

[ngppgn]

Would it be possible for Artifacts to have multiple effects with individual triggers, similar to how dynamic blocks on event descriptions work?

Something like :

effect = {
   trigger = {
      martial = 5
      NOT = {
        martial = 10
      }
    }
    combat_rating = 1
}
effect = {
   trigger = {
      martial = 10
    }
    combat_rating = 2
}

Right now I'm periodically checking for appropriate artifacts and using an event to swap them out, but it could be useful to be able to define it inside the artifact itself.

That'd be really interesting.

 

[DaJay42]

In light of the upcoming dlc/patch, I've been playing around with adding new and making existing religions and heresies more interesting, mostly for my own amusement, and have come across a few things I consider suboptimal.

Currently, the Cathar/Messalian "Women may hold all councillor positions" is hardcoded into the respective scripted triggers, which is horrible for extensibility. Any mod wishing to add/remove from that that list, or to add that function to a custom religion, will need to overwrite the entire 00_scripted_triggers.txt, which is obviously beyond terrible for compatibility.
If, instead, we had the religion-level flag(s) (and the respective trigger) analogous to the existing feminist = yes/no and female_temple_holders = yes/no flags (and triggers), this would be a lot easier to extend.

Likewise, the true cognatic succession law is hardcoded to check for Basque/Zhangzhung/Sumpa culture or Cathar/Messalian/Mazdaki religion, requiring overwriting of succession_laws.txt to extend it, which is obviously anything but ideal. Also likewise, having religion/culture level flags and triggers instead would be a major improvement.

[Now of course, having the corresponding flags for enatic/agnatic successions and male holders on top of that would be even more interesting (I imagine male_temple_holders = no alone could already mix things up nicely), but I understand if that is out of scope.]

 

[NoxBestia]

In light of the upcoming dlc/patch, I've been playing around with adding new and making existing religions and heresies more interesting, mostly for my own amusement, and have come across a few things I consider suboptimal.

Currently, the Cathar/Messalian "Women may hold all councillor positions" is hardcoded into the respective scripted triggers, which is horrible for extensibility. Any mod wishing to add/remove from that that list, or to add that function to a custom religion, will need to overwrite the entire 00_scripted_triggers.txt, which is obviously beyond terrible for compatibility.
If, instead, we had the religion-level flag(s) (and the respective trigger) analogous to the existing feminist = yes/no and female_temple_holders = yes/no flags (and triggers), this would be a lot easier to extend.

Likewise, the true cognatic succession law is hardcoded to check for Basque/Zhangzhung/Sumpa culture or Cathar/Messalian/Mazdaki religion, requiring overwriting of succession_laws.txt to extend it, which is obviously anything but ideal. Also likewise, having religion/culture level flags and triggers instead would be a major improvement.

[Now of course, having the corresponding flags for enatic/agnatic successions and male holders on top of that would be even more interesting (I imagine male_temple_holders = no alone could already mix things up nicely), but I understand if that is out of scope.]

A thousand times yes! Anything to help religion modding cross-compatibility. Plus I _really_ like the idea of a male_temple_holders = no option.

I know it has been mentioned before but it merits repeating with so much emphasis on religions in the upcoming DLC. We need a better method for religion icons. A lot of people shy away from religion modding (I even had it recommended that I avoid any religion modding) because it can cause massive inter-compatibility problems due to the icon strip issue. When you have things like AGOT and Warhammer (and many more) that don't just add to the existing strip but completely replace it, then things just become even more complicated.

 

[Arsakes]

Is there a trigger to check troop composition?

i.e that 40% of flank are archers