If I could mod the game by global modifiers I would do this:
- area weapons disabled and also area artifact weapons
- colony defense x 10
- fighters and bombers only on carriers and bases
- hyperjump speed x 10
- hyperjump full use x 10 or even more, let the galaxy feel endless
- point deflector disabled - I'm sure ai can't really use it
- colony income x 10
- overall colonizeable colonies set to x
- disable better colonization techs but let terraforming techs enabled
- conquered shakturi race may colonize planets disabled - lategame shakturi can colonize all planets - bad performance in lategame
- maintenance savings disabled
- change one per galaxy to one per empire
And my mod were almost ready but instead I have to disable techs, remove artifacts, change components, edit goverments and change all ship hulls with hangars. And if there comes a new beta or official update and the files get changed I have to compare all of the changed files. To see what changed official and what I changed I have to mark every change by comment. Before the game was released it was written: it will have great modding support. Changing xml files is not great it is really time consuming and annoying. An official editor for editing all xml files were great and a button to publish mod to steam.
Global modifiers would be great and general improvements for modding
Moderator: MOD_DW2
-
- Posts: 607
- Joined: Wed Jun 04, 2014 11:49 am
Re: Global modifiers would be great and general improvements for modding
TLDR:
(reported in redmine Feature #17982)
One Mod says:
Or explaining it a bit different:
Orbtypes_redGiantName.xml:
Here is the wall of text:
Yes, this is a loong ongoing problem.
But you programmers know what we modders need.
We wrote this often and the problem is known.
I guess there is no time to address this.
But if you would change this behavior, that is already working for lets say
gametext.txt
When we write a new little textline different, we can write that into
gametext_a.txt
But this is not working for OrbTypes.xml and other files..
Now with orbtypes as well as all other stuff, there is so much different stuff in it,
that we have to adapt every single beta (when we want to use the most recent version, want to report bugs, etc.).
And also, two mods can not exist besides each other if the one mod changes the name of planets in orbtypes and another mod changes the size of the planet.
and so there is no really a mod that can exist besides others.
Other than those that use this underline file type usage like working with gametext.txt
And the hints.txt and touritems.xml can not placed into a mod folder.
Now we write this over and over again since the first release and we are saying it nice but keep saying it
Thanks for reading
P.S.:
Even for the programmers this system would be very beneficial.
Lets say you test some changes on some stats.
Now i take a file that is working:
ComponentDefinitions_Dhayut.xml
We/You can change ONE component and write this ONE component into a new file saying:
ComponentDefinitions_Dhayut_testCompA.xml
It could work the same with beta files:
ComponentDefinitions_Dhayut_1.2.2.9.xml
If you change some lines (it should be documented how much has to be changed to get it to work, at least a bit),
only the changed lines are overriding the original lines.
In this case, there is only one component. So this is not a good example.
but for your betas, you could name those files like written above. This way we can see what has changed and what not.
Unfortunately, in orbtypes.xml, to use this example, we have to change the whole "component":
But in orbtype.xml, you can see that even this solution is not that easy, because there is much in one object:
<DiameterMinimum>38000</DiameterMinimum>
and another wants to changethe name:
<Name>Red Giant</Name>
we have a problem...
But a translation should not always translate the name again after the Diameter is changed to something else..
Now if you do finetuning like "Dhayut are buffed in various weapon types" we have to include that buff into a translation for instance.
Ahh. Instance is a good idea
Well, in this case not, or yes, it is?!
One Mod says:
(reported in redmine Feature #17982)
One Mod says:
Other mod says:<OrbType>
<OrbTypeId>1</OrbTypeId>
<Name>Red Giant</Name>
</OrbType>
Wouldn't that be nice?<OrbType>
<OrbTypeId>1</OrbTypeId>
<DiameterMinimum>38000</DiameterMinimum>
</OrbType>
Or explaining it a bit different:
Orbtypes_redGiantName.xml:
Orbtypes_redGiantSize.xml:<OrbType>
<OrbTypeId>1</OrbTypeId>
<Name>Roter Riese</Name>;Orig: Red Giant
</OrbType>
-----------------------<OrbType>
<OrbTypeId>1</OrbTypeId>
<DiameterMinimum>36000</DiameterMinimum>;was 38000
</OrbType>
Here is the wall of text:
Yes, this is a loong ongoing problem.
But you programmers know what we modders need.
We wrote this often and the problem is known.
I guess there is no time to address this.
But if you would change this behavior, that is already working for lets say
gametext.txt
When we write a new little textline different, we can write that into
gametext_a.txt
But this is not working for OrbTypes.xml and other files..
Now with orbtypes as well as all other stuff, there is so much different stuff in it,
that we have to adapt every single beta (when we want to use the most recent version, want to report bugs, etc.).
And also, two mods can not exist besides each other if the one mod changes the name of planets in orbtypes and another mod changes the size of the planet.
and so there is no really a mod that can exist besides others.
Other than those that use this underline file type usage like working with gametext.txt
And the hints.txt and touritems.xml can not placed into a mod folder.
Now we write this over and over again since the first release and we are saying it nice but keep saying it

Thanks for reading

P.S.:
Even for the programmers this system would be very beneficial.
Lets say you test some changes on some stats.
Now i take a file that is working:
ComponentDefinitions_Dhayut.xml
We/You can change ONE component and write this ONE component into a new file saying:
ComponentDefinitions_Dhayut_testCompA.xml
It could work the same with beta files:
ComponentDefinitions_Dhayut_1.2.2.9.xml
If you change some lines (it should be documented how much has to be changed to get it to work, at least a bit),
only the changed lines are overriding the original lines.
In this case, there is only one component. So this is not a good example.
but for your betas, you could name those files like written above. This way we can see what has changed and what not.
Unfortunately, in orbtypes.xml, to use this example, we have to change the whole "component":
But in orbtype.xml, you can see that even this solution is not that easy, because there is much in one object:
If one mod changes the size:<OrbType>
<OrbTypeId>1</OrbTypeId>
<Category>Star</Category>
<Name>Red Giant</Name>
<Description></Description>
<ImageFilename>Environment/OrbTypes/RedGiant</ImageFilename>
<LargeImageFilename>Environment/OrbTypes/Large/RedGiant</LargeImageFilename>
<FullsizeImageFilename>Environment/OrbTypes/Fullsize/RedGiant</FullsizeImageFilename>
<SurfaceDrawType>Star</SurfaceDrawType>
<AtmosphereDrawType>Corona</AtmosphereDrawType>
<AmbientSoundEffectFilenames>
<string>Sounds/Ambient/Star_Surging1</string>
<string>Sounds/Ambient/Star_Surging2</string>
<string>Sounds/Ambient/Star_Mid1</string>
</AmbientSoundEffectFilenames>
<SurfaceMaterialFilenames>
</SurfaceMaterialFilenames>
<AtmosphereMaterialFilenames>
</AtmosphereMaterialFilenames>
<AmbientLightColor>
<B>188</B>
<G>208</G>
<R>255</R>
<A>255</A>
</AmbientLightColor>
<AmbientLightIntensity>0.05</AmbientLightIntensity>
<StarColor>
<B>80</B>
<G>96</G>
<R>255</R>
<A>255</A>
</StarColor>
<StarLightColor>
<B>160</B>
<G>192</G>
<R>255</R>
<A>255</A>
</StarLightColor>
<StarColorVariationFactor>0.1</StarColorVariationFactor>
<StarBrightnessFactor>0.8</StarBrightnessFactor>
<StarColorGradient>CoreEffects/ShaderGradients/RedGiant</StarColorGradient>
<EnergyOutputMinimum>0.7</EnergyOutputMinimum>
<EnergyOutputMaximum>0.9</EnergyOutputMaximum>
<LocationEffectId>0</LocationEffectId>
<CommonBonuses>
<BonusRange>
<Type>ResearchShields</Type>
<Minimum>0.06</Minimum>
<Maximum>0.15</Maximum>
<AppearanceChance>0.0085</AppearanceChance>
<Descriptions>
<string>Dense Plasma Vortices</string>
<string>Supercharged Gaseous Flow</string>
<string>Magnetic Inversion Fields</string>
<string>Stable Gravimetric Pulses</string>
</Descriptions>
</BonusRange>
<BonusRange>
<Type>ResearchHyperDrive</Type>
<Minimum>0.06</Minimum>
<Maximum>0.15</Maximum>
<AppearanceChance>0.007</AppearanceChance>
<Descriptions>
<string>Magnetic Inversion Fields</string>
<string>Stable Gravimetric Pulses</string>
<string>Turbulent Energy Oscillations</string>
<string>Powerful Magnetic Bursts</string>
</Descriptions>
</BonusRange>
</CommonBonuses>
<AsteroidFieldProbability>0</AsteroidFieldProbability>
<AsteroidFieldOrbTypeId>0</AsteroidFieldOrbTypeId>
<StarProbability>
<OrbTypeId>0</OrbTypeId>
<Factor>0.15</Factor>
</StarProbability>
<ChildTypes>
<OrbTypeFactor>
<OrbTypeId>7</OrbTypeId>
<Factor>0.006</Factor>
</OrbTypeFactor>
<OrbTypeFactor>
<OrbTypeId>8</OrbTypeId>
<Factor>0.006</Factor>
</OrbTypeFactor>
<OrbTypeFactor>
<OrbTypeId>9</OrbTypeId>
<Factor>0.007</Factor>
</OrbTypeFactor>
<OrbTypeFactor>
<OrbTypeId>10</OrbTypeId>
<Factor>0.035</Factor>
</OrbTypeFactor>
<OrbTypeFactor>
<OrbTypeId>11</OrbTypeId>
<Factor>0.025</Factor>
</OrbTypeFactor>
<OrbTypeFactor>
<OrbTypeId>12</OrbTypeId>
<Factor>0.035</Factor>
</OrbTypeFactor>
<OrbTypeFactor>
<OrbTypeId>13</OrbTypeId>
<Factor>0.04</Factor>
</OrbTypeFactor>
<OrbTypeFactor>
<OrbTypeId>14</OrbTypeId>
<Factor>0.20</Factor>
</OrbTypeFactor>
<OrbTypeFactor>
<OrbTypeId>15</OrbTypeId>
<Factor>0.15</Factor>
</OrbTypeFactor>
<OrbTypeFactor>
<OrbTypeId>16</OrbTypeId>
<Factor>0.04</Factor>
</OrbTypeFactor>
<OrbTypeFactor>
<OrbTypeId>31</OrbTypeId>
<Factor>0.04</Factor>
</OrbTypeFactor>
<OrbTypeFactor>
<OrbTypeId>32</OrbTypeId>
<Factor>0.04</Factor>
</OrbTypeFactor>
<OrbTypeFactor>
<OrbTypeId>23</OrbTypeId>
<Factor>0.008</Factor>
</OrbTypeFactor>
<OrbTypeFactor>
<OrbTypeId>17</OrbTypeId>
<Factor>0.007</Factor>
</OrbTypeFactor>
<OrbTypeFactor>
<OrbTypeId>18</OrbTypeId>
<Factor>0.007</Factor>
</OrbTypeFactor>
<OrbTypeFactor>
<OrbTypeId>19</OrbTypeId>
<Factor>0.03</Factor>
</OrbTypeFactor>
<OrbTypeFactor>
<OrbTypeId>20</OrbTypeId>
<Factor>0.025</Factor>
</OrbTypeFactor>
<OrbTypeFactor>
<OrbTypeId>21</OrbTypeId>
<Factor>0.025</Factor>
</OrbTypeFactor>
<OrbTypeFactor>
<OrbTypeId>22</OrbTypeId>
<Factor>0.025</Factor>
</OrbTypeFactor>
<OrbTypeFactor>
<OrbTypeId>24</OrbTypeId>
<Factor>0.01</Factor>
</OrbTypeFactor>
<OrbTypeFactor>
<OrbTypeId>25</OrbTypeId>
<Factor>0.04</Factor>
</OrbTypeFactor>
<OrbTypeFactor>
<OrbTypeId>26</OrbTypeId>
<Factor>0.04</Factor>
</OrbTypeFactor>
<OrbTypeFactor>
<OrbTypeId>27</OrbTypeId>
<Factor>0.007</Factor>
</OrbTypeFactor>
<OrbTypeFactor>
<OrbTypeId>29</OrbTypeId>
<Factor>0.025</Factor>
</OrbTypeFactor>
<OrbTypeFactor>
<OrbTypeId>30</OrbTypeId>
<Factor>0.025</Factor>
</OrbTypeFactor>
</ChildTypes>
<ChildCountMinimum>0</ChildCountMinimum>
<ChildCountMaximum>8</ChildCountMaximum>
<QualityRangeMinimum>0</QualityRangeMinimum>
<QualityRangeMaximum>0</QualityRangeMaximum>
<OrbitalDistanceFromSunRatioMinimum>0</OrbitalDistanceFromSunRatioMinimum>
<OrbitalDistanceFromSunRatioMaximum>1</OrbitalDistanceFromSunRatioMaximum>
<DiameterMinimum>38000</DiameterMinimum>
<DiameterMaximum>45000</DiameterMaximum>
<ResourceCountMinimum>0</ResourceCountMinimum>
<ResourceCountMaximum>0</ResourceCountMaximum>
<PossibleResources>
</PossibleResources>
</OrbType>
<DiameterMinimum>38000</DiameterMinimum>
and another wants to changethe name:
<Name>Red Giant</Name>
we have a problem...
But a translation should not always translate the name again after the Diameter is changed to something else..
Now if you do finetuning like "Dhayut are buffed in various weapon types" we have to include that buff into a translation for instance.
Ahh. Instance is a good idea

Well, in this case not, or yes, it is?!
One Mod says:
Other mod says:<OrbType>
<OrbTypeId>1</OrbTypeId>
<Name>Red Giant</Name>
</OrbType>
Wouldn't that be nice?<OrbType>
<OrbTypeId>1</OrbTypeId>
<DiameterMinimum>38000</DiameterMinimum>
</OrbType>
Re: Global modifiers would be great and general improvements for modding
Well, I might found what is already years old and solved.
I will try to work with this:
https://www.matrixgames.com/forums/view ... 9&t=381784
P.S.: No, this is not working (for me).
It is outdated. Using Python could be a way..
I will try to work with this:
https://www.matrixgames.com/forums/view ... 9&t=381784
P.S.: No, this is not working (for me).
It is outdated. Using Python could be a way..
Last edited by rxnnxs on Fri Jan 10, 2025 8:18 pm, edited 1 time in total.
-
- Posts: 607
- Joined: Wed Jun 04, 2014 11:49 am
Re: Global modifiers would be great and general improvements for modding
Lua scripting is great for modding. You can overwrite/change functions and objects maybe nearly all of code that is not hardcoded.
-
- Posts: 607
- Joined: Wed Jun 04, 2014 11:49 am
Re: Global modifiers would be great and general improvements for modding
Push
Even start values we cannot mod like start empire:
- money
- corruption
- population
- colony defense
Even start values we cannot mod like start empire:
- money
- corruption
- population
- colony defense
Re: Global modifiers would be great and general improvements for modding
Global modifiers are a comfortable shortcut for certain things but by no means neccessary to mod the game.fruitgnome wrote: Sat Nov 23, 2024 7:13 pm If I could mod the game by global modifiers I would do this:
Also there is no need for editing the big XMLs and overwrite everything. Just the entries one want to modify. The modfolder files will overwrite just these
This is not No Mans Sky where with every patch the MBINS stop working due to the compiling and one has to do the mod from scratch every time or use the AMUMSS system and even
then Hello Games has thrown out the window many times the file structures and deleted entire entries changing the engine itself.
So the few changes to existing XML are quickly detected. Most changes are in the .exe nayway.
Its dead easy once you understand the structure of each XMLfruitgnome wrote: Sat Nov 23, 2024 7:13 pm Changing xml files is not great it is really time consuming and annoying
Welcome to modding my man, its incredibly time consuming, sometimes frustrating and annyoing but it is what it is.fruitgnome wrote: Sat Nov 23, 2024 7:13 pm And my mod were almost ready but instead I have to disable techs, remove artifacts, change components, edit goverments and change all ship hulls with hangars.
Problem is people nowadays come on Steam, post a micro-mod then tell others to like it please because they spent entire 3 hours of their life time "creating" the mod.
For real ???
You have any idea how long it takes to do one proper single location or interior in Skyrim, Starfield, Fallout 4 with the Creation Kit?
Apart from 100+h plus to get comfortable with it and be able to do all of it, quests, markers building etc it takes easy 20-30h to build a location with quests, triggers and all that stuff and by the time you done you have probably reloaded de game 30-50 times cause you failed in something, its not showing, its not working...and so forth.
Once the mod is build modular this is not such an issue. Anyway, on modding Betas etc are to be ignored anyway.fruitgnome wrote: Sat Nov 23, 2024 7:13 pm And if there comes a new beta or official update and the files get changed I have to compare all of the changed files.
To see what changed official and what I changed I have to mark every change by comment
On this I´m with you 100%. Need a Menu Button to Upload to Steam Workshop from the Ingame Mod Loader next to the mod folder you activate.
You not supposed to play the game when doing a mod, you do the modding and find shortcuts to test functionality of whatever you did till you 100% sure you got it all right,fruitgnome wrote: Fri Jul 18, 2025 5:01 pm I want to mod the game but really have the fear that I missed something and have to start a new game to have new modding changes take effect.
its annoying I know, I lost count how many times I have reloaded the game by now...hundreds maybe....just testing functionality to the point then exit, fix stuff, come back...
Maybe this is not possible due to how the engine works with the static data, on the other hand you cant break a game halfway thru. Even if there is massive changes in a patch, you can continue your old save till the end as all data is static, I have a save from May 2024 and I can still play this game despite all the massive changes ever since. So it has advantages...but yes...it would have advantages to have dynamic data too, maybe for components...then again...Im not sure about the ramifications with the enginefruitgnome wrote: Fri Jul 18, 2025 5:01 pm I mean not on the fly while game is running I mean only modding changes should have effect on saved games!
EDIT:
On further thought, if a galaxy gets loaded with maybe hundreds of thousands of objects (ships, troops, stations, battles etc) and data would change for components and other stuff every action in course on time of saving the game would have to be recalculated from scratch to apply all the new values to every object in the galaxy...
I dont see this happen, it sure would cause lots of issues and crashes as it would smash into existing calculations and functions in execution with stored values for variables on moment of saving the game...well, no...I dont think its possible and I also think there is no point asking for it!

Conquest: Terran Frontier Wars - Return to Terra (Terran Campaign DLC) Release 28/7/2025
https://forums.matrixgames.com/viewtopic.php?t=412258

https://forums.matrixgames.com/viewtopic.php?t=412258
