Hello, and welcome back to another Dev Diary for No Step back and 1.11 Barbarossa. Today we will be pulling back the veil a bit and show you how modders can affect and use the new features coming in 1.11.
For those of you who do not get unreasonably excited by hearing about new script commands and changes to databases, the long and short of it is this: We made some fundamental changes to the way the game handles some things, which will probably require your favorite mods to spend some time updating. On the flip side, those changes also allow for some exciting possibilities down the line. If you came here hoping for a release date, we must ask you for just a little more patience. We promise the announcement is very close - but not today.
[h2]Characters[/h2]
Probably the biggest change is in how we handle people on the backend (or ponies, for that matter - we do not discriminate). In the current live version, the game has no real concept of a person as a distinct thing. It only knows about country leaders, military leaders, political and military advisors, and operatives. Cases where a country leader could also be a general had to be handled manually, leading to lots of exciting bugs when the country leader was removed but the general was forgotten about and other such cases.
We have overhauled that side of the game from the ground up with the introduction of characters. This should dramatically reduce the amount of potential zombie generals shambling around, which I am sure the non-zombie population will greatly appreciate.
Characters are defined in the common/character folder, and their definitions look like this:
Every character is defined as a container for different roles they can fulfill, like General (corps_commander), Advisor, country leader etc. Due to technical concerns, Operatives remain their own thing. On the character level itself, things like name and gender are handled. This also means that character names can now be localised and you can refer to a character by ID instead of by name (this helps a lot with character names that have non-english characters in them - turns out this broke some triggers and effects).
This also means that if a character is removed from play - say, through a purge - they are automatically removed from all roles that they could have, which makes such systems a lot easier to do script-side. It also means that if we wanted to allow Zhukov to become a country leader, we could simply add a country leader role for him in the character file, like this:
Or we could also add the role later on, via focus, event, decision... like we do here with Beriya:
hat means there is a lot less confusion and duplication of effort necessary when putting a character into a new role, since stuff like portraits, name etc. are already handled. A broken portrait only needs to be fixed in one place instead of five etc.
Once defined, characters are recruited in the country history file in order to be added to the game. As you can see in the first screenshot, you can use visible triggers for unit leaders to ensure they are not shown if you don’t want them to be.
Characters that can potentially become country leaders are made into country leaders using the promote_character effect, like so:
This is a clear departure from the practice in the live version of the game, where you would create a new country leader in that effect. The old script with create_country_leader and other such effects should still be working, but obviously you don’t get any of the advantages of the unified character system.
So let’s talk about some more things you can do with it!
You can set and check character flags for nefarious purposes:
You can change the traits of advisors without having to make a whole new advisor:
You can check if a character is a certain type of character:
You can save the character as a variable to refer to them later, such as spamming debug messages in the console!
[h2]Tank Designer[/h2]
Next, let’s talk a bit about how the tank designer works on the backend. It shares a lot of concepts with the ship designer, such as modules and module slots. It does, however, work a little differently in some other, important aspects.
While the system pretends that there are only a handful of chassis (light, medium, heavy, super-heavy, amphibious, modern), this is not technically true. Instead, the system maintains a whole host of other, dynamically created chassis. This allows us to make sure that tank designs with the tank destroyer role actually go into tank destroyer battalions etc.
However, these dynamic chassis are still generated from the base chassis, so any changes to them will carry over.
The roles are enabled and disabled on individual modules:
For the unlock of new module categories, you can then use this on a module to unlock that category:
[h2]Railways[/h2]
Railways function a little differently from other buildings. While they are technically province buildings like forts, they are in reality closer to a building that connects two provinces. A railway line is effectively a series of two-province connections, and the lowest one in the chain determines the level of the railroad connection between two supply hubs.
To make it easier to change and maintain the historical railway setup, we have added an option to draw railways into the nudger tool, which you can access by using the nudge command in the console.
The railway setup is in the supply menu in the nudger, and you can easily add new railway lines to the existing setup in this way. It took me about a week and a half to do the entire 1936 setup, including tracking down reference maps (with a lot of help from some of our testers).
If you want to add railways through script, you have the build_railway effect. It gives you a lot of options, with the most basic one being to lay out the path one province at a time:
This is obviously a little cumbersome for longer railways, especially if you don’t really care about the exact path. For that, you have the option to define a start and an end province:
The game will then automatically generate a path from one end to the other using advanced neural network-based self-learning algorithms that use blockchain (read: I have no idea how it works but this sounds impressive).
If finding the province is too much work, or if you want to be somewhat dynamic, you can even use start and end states (also note that you can specify what level of connection should be built):
Note that you can’t mix these, so you can’t define a starting province and a target state for example.
There are also corresponding triggers like can_build_railway and has_railway_connection:
The first checks if a railway can be built between two locations, while the other checks if one such connection already exists.
Finally, there is has_railway_level, which checks if the specified state has a railway line in it with the specified level:
[h2]Miscellaneous new effects, triggers, modifiers[/h2]
In addition to the things described above, we have added a number of useful things that some of you might find useful:
- Building_cost_factor: a new modifier that affects the construction cost of buildings. This takes the buildings from the 00_buildings file, so it should work with mods that add more buildings.
- Core_state scope list, allowing you to run effects and triggers on a country’s core states:
- Add_equipment_to_stockpile effect can now take a variant name to ensure that you add the right kind of equipment.
That’s all for today, I hope you enjoyed these little insights and we are all excited about what crazy things you will do with the new tools at your disposal.
[h3]
Read the full article here[/h3]
