Page 1 of 1

Implement a Paradox-style defines.lua system for editing engine variables

Posted: Wed Dec 11, 2024 8:43 pm
by PyroGamer666
In Paradox games like Europa Universalis IV, the game has all in-engine variables stored in a file called defines.lua. In this file are all variables that are central to how the game operates, including variables that determine the aggressiveness of AI, the way that being ahead of time in technology affects technology cost, and the amount of money that AI players will keep in reserves at all times. Modders have the ability to write lua files that make changes to defines.lua before any other content in the game loads. https://eu4.paradoxwikis.com/Defines

In Factorio, there are certain hardcoded variables that modders have no way of changing, such as how quality affects machine speed and turret/enemy range, and how the maximum velocity of ships is calculated. There aren't as many hardcoded variables as in the typical Paradox game, but they still exist.

If Wube offered a predetermined defines list that mods would be able to modify, including currently hard-coded engine variables such as "quality-range-modifier" and "quality-speed-modifier", variables which would be non-performant to expose to the current modding API, that would greatly increase the number of tools available to modders. I'm sure the developers have a better idea of which in-engine variables would be suitable candidates to be exposed to modders.

One possible issue with doing this is two mods which modify the same define would conflict with each other if both of them make an absolute instead of relative change, but that problem already exists when modifying vanilla prototypes.

Re: Implement a Paradox-style defines.lua system for editing engine variables

Posted: Wed Dec 11, 2024 9:58 pm
by curiosity
It already exists. So you should ask for whatever it is you want (viewtopic.php?f=28&t=120398 from the sound of it).

Re: Implement a Paradox-style defines.lua system for editing engine variables

Posted: Wed Dec 11, 2024 10:26 pm
by Rseding91
Generally most constants we care to expose are already exposed in utility constants. For every one we expose it’s a potential performance issue in that the variable can no longer be inlined and the optimizer always has to do a memory read when interacting with it over a compile time constant.

Additionally every variable put into utility constants needs to be constrained so mods don’t do something like make the range modifier 700 chunks per level - which would have a massive performance impact.