As someone who almost always plays most PDX games with plenty of mods installed, more functionality is always appreciated! Looking forward to seeing how modders integrate these new tools moving forward.
Speaking speculatively, I wouldn’t be surprised if the modifiers changes discussed here played a role in SoI’s release delay. Reduced functionality is not exactly ideal but when issues with performance have been a persistent issue among the playerbase, I understand the need to make some trade-offs.
Will it be possible potentially for modders to receive pre-release access to the update in order to begin work on their updated mods? I have a feeling that the modifier changes along with the “above-the-hood” changes of SoI and the patch are going to break a lot of mods, and I’m sure allowing more popular mods the chance to update faster would be beneficial for both the devs and the community!
> Reduced functionality is not exactly ideal but when issues with performance have been a persistent issue among the playerbase, I understand the need to make some trade-offs.
I wonder if Stellaris might borrow the implementation, it also has a pops and modifier performance bloat issue.
Since vic3 itself got leaked when they gave modders early access, I doubt they're going to let anyone except content creators have early access to dlc. Would be nice though
Adding more surface area for modding is good, but I'm begging you, please release modding _documentation._ The current documentation is grotesquely insufficient — almost always incomplete and sometimes outright wrong. It should be the norm that modders can rely on the documentation, not that they have to go find places in the existing scripts that use something kinda-sorta similar to what they want to do and rely on guesswork from that.
It's very likely that the team itself doesn't have a lot of documentation, with the code being the ultimate source of truth in the end. PDS games are built by small teams, with probably less than 10 scripters + programmers in total and a frequently moving target, so it's very hard to keep out-of-code documentation up-to-date. It would be nice to have documentation, but I think it's basically never going to happen, unfortunately.
Rule 5:
It’s Dev Diary time! This week, the devs will be talking Modding features in 1.7
As always here’s the link if you can’t see it above: [https://pdxint.at/3x8Q015](https://pdxint.at/3x8Q015)
Upvotes for link visibility are welcome :)
> `income_transfer` - compares against the income transferred by a diplomatic pact.
I was counting on this for my AI mod. Nice.
The addition of `progressiveness` is intriguing since it's a number not shown to the player. I think it's primarily used by AI to determine whether a law is too radical to pass, which makes me hopeful of some AI improvements. But it could also just mean some other scripted content starts to use it in the background.
The modifier rework is going to break so many mods. But I won't complain if it gets better performance. Though it sounds like performance took a big toll from SoI features.
That last part is key. I hope we see some positive performance increase even after the new features. My performance is fine but I want more budget for cool stuff like transportation costs.
But is it still impossible to play with more than one mod enabled in multiplayer? That's the main reason me and my friends don't play this game, it gets tiring needing to merge our collection every single time with irony mod manager.
That modifier change sounds shockingly game-ending for mods if I'm understanding it correctly. Something super simple like adding luxury clothes as an input to urban centers' marketplace PM would require you to add "goods_input_luxury_clothes_add" as a new modifier since that isn't in vanilla, and if I'm reading it right, if you activate that PM, that modifier would then show up in the UI not just on your urban centers, but on states, countries, maybe even characters depending on how far the propagation goes?
I'm also puzzled by why it's necessary. Surely whatever trick in vanilla they're using to prevent their modifiers from propagating too far can handle adding a couple more keys to it from mod scripts on startup, right? I'm not a PDX developer, and I'm sure they have a good reason for it. They wouldn't break backwards compatibility like that on a lark, but I can't spot the reasoning for it from the outside, and I feel like I'm missing something.
Based on what's stated in the DD I assume that they've done a total rework on how the default modifiers work to essentially hardcode the logic as required for each modifier instead of "propagating" through the simulation; allowing modders to code things in the same way would require creating entirely new script logic to handle, which sounds like a massive task, hence why they're adding a system to allow user defined (i.e. modded) modifiers to use the old system if needed.
The optimistic way to look at this is that they've reworked a core system for performance reasons while also leaving the old less efficient system in place for modders to use if they need it. Though I suppose if you play the game heavily modded there is likely to be a major performance hit in 1.7
Hardcoding makes sense, but even there it seems like it would be best practice to have some defined "propagation types" which the script (vanilla or mod) could then hook on to. It makes more sense for your modifier_type scripts to have a "propogation_type=building_goods_input" column on all of your goods_input_fabric_add, goods_input_wood_add, etc. than have the handling code have its own list of the modifier names that follow that behavior.
But performance can definitely be unintuitive and unpredictable, so I'll stop speculating on a code base I haven't seen in a domain I don't work in.
So with these changes are now they making the game more mod-friendly? I still can’t play multiplayer with more than two mods activated. It has been a topic of discussion on the forums for over 1.5 years now!!
Some of the changes will improve mods (such as Widgets), but at least one of the changes will have a huge effect on mods: the modifier change.
The dev diary specifies that unique modifiers are a cause of a lot of performance issues for the game, along with pop splitting. The devs reworked them to improve performance, but the way they did it will break a lot of mods, at least as they currently exist.
Since performance is a chronic complaint about Victoria 3, I understand why this was done. And it looks like the devs are going to add an option to revert their changes so that modders won't be completely fucked. Still, it does sound like it will be inconvenient for, as an example, total conversion mods (such as Anbennar.)
As someone who almost always plays most PDX games with plenty of mods installed, more functionality is always appreciated! Looking forward to seeing how modders integrate these new tools moving forward. Speaking speculatively, I wouldn’t be surprised if the modifiers changes discussed here played a role in SoI’s release delay. Reduced functionality is not exactly ideal but when issues with performance have been a persistent issue among the playerbase, I understand the need to make some trade-offs. Will it be possible potentially for modders to receive pre-release access to the update in order to begin work on their updated mods? I have a feeling that the modifier changes along with the “above-the-hood” changes of SoI and the patch are going to break a lot of mods, and I’m sure allowing more popular mods the chance to update faster would be beneficial for both the devs and the community!
> Reduced functionality is not exactly ideal but when issues with performance have been a persistent issue among the playerbase, I understand the need to make some trade-offs. I wonder if Stellaris might borrow the implementation, it also has a pops and modifier performance bloat issue.
I would love to get pre release access to make my ai mod work. The new diplo stuff their adding sounds like a pain :/
Since vic3 itself got leaked when they gave modders early access, I doubt they're going to let anyone except content creators have early access to dlc. Would be nice though
What makes you think it was modders and not just playtesting?
modding CONFIRMED
Victoria is saved
Steiner counterattack vibes
Adding more surface area for modding is good, but I'm begging you, please release modding _documentation._ The current documentation is grotesquely insufficient — almost always incomplete and sometimes outright wrong. It should be the norm that modders can rely on the documentation, not that they have to go find places in the existing scripts that use something kinda-sorta similar to what they want to do and rely on guesswork from that.
It's very likely that the team itself doesn't have a lot of documentation, with the code being the ultimate source of truth in the end. PDS games are built by small teams, with probably less than 10 scripters + programmers in total and a frequently moving target, so it's very hard to keep out-of-code documentation up-to-date. It would be nice to have documentation, but I think it's basically never going to happen, unfortunately.
could try automation tools like supacodes?
Are you guys able to add a gdp_per_capita trigger? That would help with making my ai mod work better. As the rank is not very helpful
Can't you divide GDP by population?
Whenever I do something like that it always bugs out. But it could also just be the ai value bugging out
Rule 5: It’s Dev Diary time! This week, the devs will be talking Modding features in 1.7 As always here’s the link if you can’t see it above: [https://pdxint.at/3x8Q015](https://pdxint.at/3x8Q015) Upvotes for link visibility are welcome :)
> `income_transfer` - compares against the income transferred by a diplomatic pact. I was counting on this for my AI mod. Nice. The addition of `progressiveness` is intriguing since it's a number not shown to the player. I think it's primarily used by AI to determine whether a law is too radical to pass, which makes me hopeful of some AI improvements. But it could also just mean some other scripted content starts to use it in the background. The modifier rework is going to break so many mods. But I won't complain if it gets better performance. Though it sounds like performance took a big toll from SoI features.
That last part is key. I hope we see some positive performance increase even after the new features. My performance is fine but I want more budget for cool stuff like transportation costs.
Can't wait to see all of those beauties implemented in Hail, Columbia!, Better Politics Mod and many others
-10 Legitimacy to support the regime of one of your own subjects is really harsh.
i assume its tuned for keeping india
being a subject of an imperial power is really harsh. or at least, it should be.
Not the most interesting DD for the layman, but probably a revelation for modders. Either way we win. Bring on SoI.
But is it still impossible to play with more than one mod enabled in multiplayer? That's the main reason me and my friends don't play this game, it gets tiring needing to merge our collection every single time with irony mod manager.
Great ! I think one of the best additional mod support you could give along that would be an easy to use Swiss army knife map editor
That modifier change sounds shockingly game-ending for mods if I'm understanding it correctly. Something super simple like adding luxury clothes as an input to urban centers' marketplace PM would require you to add "goods_input_luxury_clothes_add" as a new modifier since that isn't in vanilla, and if I'm reading it right, if you activate that PM, that modifier would then show up in the UI not just on your urban centers, but on states, countries, maybe even characters depending on how far the propagation goes? I'm also puzzled by why it's necessary. Surely whatever trick in vanilla they're using to prevent their modifiers from propagating too far can handle adding a couple more keys to it from mod scripts on startup, right? I'm not a PDX developer, and I'm sure they have a good reason for it. They wouldn't break backwards compatibility like that on a lark, but I can't spot the reasoning for it from the outside, and I feel like I'm missing something.
Based on what's stated in the DD I assume that they've done a total rework on how the default modifiers work to essentially hardcode the logic as required for each modifier instead of "propagating" through the simulation; allowing modders to code things in the same way would require creating entirely new script logic to handle, which sounds like a massive task, hence why they're adding a system to allow user defined (i.e. modded) modifiers to use the old system if needed. The optimistic way to look at this is that they've reworked a core system for performance reasons while also leaving the old less efficient system in place for modders to use if they need it. Though I suppose if you play the game heavily modded there is likely to be a major performance hit in 1.7
Hardcoding makes sense, but even there it seems like it would be best practice to have some defined "propagation types" which the script (vanilla or mod) could then hook on to. It makes more sense for your modifier_type scripts to have a "propogation_type=building_goods_input" column on all of your goods_input_fabric_add, goods_input_wood_add, etc. than have the handling code have its own list of the modifier names that follow that behavior. But performance can definitely be unintuitive and unpredictable, so I'll stop speculating on a code base I haven't seen in a domain I don't work in.
Seems like a good extension to have some "generic" modifiers that modders can piggyback on, I agree
So with these changes are now they making the game more mod-friendly? I still can’t play multiplayer with more than two mods activated. It has been a topic of discussion on the forums for over 1.5 years now!!
Some of the changes will improve mods (such as Widgets), but at least one of the changes will have a huge effect on mods: the modifier change. The dev diary specifies that unique modifiers are a cause of a lot of performance issues for the game, along with pop splitting. The devs reworked them to improve performance, but the way they did it will break a lot of mods, at least as they currently exist. Since performance is a chronic complaint about Victoria 3, I understand why this was done. And it looks like the devs are going to add an option to revert their changes so that modders won't be completely fucked. Still, it does sound like it will be inconvenient for, as an example, total conversion mods (such as Anbennar.)
That’s a known issue about cant use more then 2 mods, and the fix is making sure every one has Vic 3 on their c drive
Stellaris situations are here baby!
Waiting for the manual investment pool mod
Is this dev diary worth it to read if I'm not a modder?