Jump to content
Charon

Modder´s Wisdom

Recommended Posts

A collection of discoveries when you are modding. Feel free to suggest more.

When this thing gets too big you can search with "Crtl+F" to look for your topic.

 

  • For future references its important to keep in mind: XCE is not a mod and doesnt follow the same rules, its the base from wihich the modular system starts to work.

 

  • The Items.xml doesnt take the libre calcualator way of saving well (libre style for future reverences)
  • Capital letters and non capital letters are not inerchangeable and cause crashes.
  • Xml sheets only save to the 65536 cell, which means for instance that the researches.xml only saves to the 645th row. After that it bugs out. Solution: put the remaining research lines into another researches.xml and make another mod with it called part 2. Looks to work fine, an invisible bug stopped the game from taking additional cells after the 650th one.
  • The requirement cell from the manufactures.xml can only be so long, if its too long it crashes
  • "Empty" requirement cells in researches.xml won´t overwrite XCE/vanilla/other mods for existing researches.
  • Empty Cells in general get ovewrwritten by ANYTHING else, meaning if you want to make a vanilla/XCE research which doesnt require anything not possible. Better make a new research or set the requirement very low, Alien Invasion for instance
  • Be careful when copying from libre office to excel, there is a lot which can get wrong, namely when you select cells to copy from libre to rows from excel.

 

About the Aircraftweapons.xml and items.xml:

  • Every (human) Aircraft weapon will get looked up by the game and compared if there is an appropriate item in the items.xml. If there is none the game wont recognice every following weapon in the aircrafts.xml, going by the order of weapons in the aircraftweapons.xml
  • Modmerge doesnt work for the aircraftweapons.xml. It only "update"s but doesnt "insert" new items if 2 mods (excep XCE) add aircraftweapons.xml. This means that in order to have higher priority mod to get acknowledged by the modmerge system the new items and weapons need to be in the lower priority mod as well for both the items.xml as well as aircraftweapons.xml. Is solvable - bug occurred because every aircraft weapon has to be in the items list as well, even the alien ones and the ones not used.
  • Weapons which target missiles/torpedos, anti missile weapons or AM for short, produce a crash whenever 2 AM projectiles from the SAME Aircraft are in the game. This applys to 2 AM weapons equipted on the same aircraft as well as the shoot before the last AM projectile vanished or hit its targaet.

Aircraft:

  • Autoresolve seems to do a lot more dmg to the winning squad if the main UFO can evade. From 2 times up to ? dmg.

manufactures.xml

  • If you change or delete an manufacture which a savegame already registered as available the save game will no longer be compatible with your version of xenonauts
  • If you are working with the manufacture_categories.xml remember to put an modmerge command like "replace" on the head of the file.
  • The vanilla manufactures.xml has code lines which excel cant reproduce/deal with. If you try to modmerge/change these lines without the proper code, which needs an notepad++ or similar program edit, the game modmerge errors your file out.

xenopedia.xml:

  • Some entries in the Vanilla/XCE have additional rows which need to be overtaken as well in order to overwrite them.
    Namely: Researches.AlienLeaderInterrogation; Researches.AlienOfficerInterrogation; Researches.AlienInvasion; Researches.AndronDisassembly; Researches.WraithAutopsy; Researches.ReaperAutopsy, and the Researches.AlienAssaultPlasma. Otherwise this leads to a MODMERGE error.

 

  • You can only "update" and not "replace" the civilian code in aiprops.xml

 

aiprops:

  • The "Abilities" line only works for units, not races

weapons_gc:

  • Melee weapons cant do emp damage
  • In case a unit may receive emp damage the game calculates if the normal or emp damage is higher and applies the higher one

psionicpowers_gc:

  • The "dread" ability is a praetor race exclusive one

 

Strings.xml & xenopedia.xml

  • Although there are color codes in the files it is not possible to change ingame colors of strings. Its hardcoded ( Solver ).

 

On 6.10.2016 at 6:50 PM, Solver said:

Damage randomisation when you attack aliens seems to be:

Damage = WeaponDamage * RaceBonus * (1 + Reduction * 0.01)

where Reduction = Random(0, DamageRandomChance * 2)
- Only between 100% + X%, where X is the damage randomifier. X cant be higher than 100.

- Original Calculation seems to be correct - Draku

 

How the game picks a UFO

 

On 30.8.2016 at 8:10 PM, Charon said:

Thats a complicated question.

The files you have to look for are all the AM_***files but this wont really help you in the best way possible although it gives you an idea how the game works.

Let me tell you how the game works.

Theres a minimum UFO count and a maximum UFO count. In our case


  <minMissionCount value="4"     comment="This is the mininum number of mission for a wave." />
  <maxMissionCount value="7"    comment="This is the maxinum number of mission for a wave. Numbers from the next two parameters will be added to it." />

the next 2 parameters are


  <maxMissionAlienBaseModifier value = "1" comment = "Add this much to maxMissionCount for every alien base on the map" />
  <maxMissionHumanBaseModifier value = "0" comment = "Add this much to maxMissionCount for every human base on the map" />

and the ATP for when the maxMissionCount gets spawned


  <highBandTicker  value="1400" comment="This is the ticker value from where the maxMissionCount missions are going to be spawned." />

This is the new count.


Then there are the AM_* files. Everyone is a respective mission which can get picked. These are the categories


Ticker	230
Chance	10
Escort chance	100
Once per wave	true

The ticker value is the starting point from which the game is allowed to pick this particular mission when the wave wheel spins. The chance for it is the chance for it to get picked, although its not "%" but "points". 10 means 10 "points" not 10%. All points from all mission files will get added up just like every mission gets different big stops in a roulette. Other files have 8 points and some others 13 for instance.

In our case we set the total number to 100 points which means the 10 points is actually 10% in our case.

Once per wave means that this mission can only be picked once per wave. This doesnt mean that anotehr mission cant spawn the same UFO with another goal.

These are the other variables


m:airplane.alien.corvette	150	100
m:airplane.alien.landingship	300	30
m:airplane.alien.exlandingship	300	20
m:airplane.alien.lightcruiser	300	50
m:airplane.alien.supplyship	700	20
m:airplane.alien.exsupplyship	700	10
m:airplane.alien.carrier	700	70
m:airplane.alien.cargoship	1100	20
m:airplane.alien.excargoship	1100	10
m:airplane.alien.battlecarrier	1100	70
e:airplane.alien.fighter	100	100
e:airplane.alien.heavyfighter	300	100
e:airplane.alien.hunter	700	100
e:airplane.alien.interceptor	1100	100
e:airplane.alien.heavyinterceptor	1400	100

The second row is the ATP at which this particular UFO can be spawned. The third row is the "chance" again, or "points". The first is the UFO. Note that there can be the same UFO for different ATP values.

This means that all the "chance" points for an ATP will get added up. In our case all points are the % at the same time.

This points will equally degrade over time make them less likely to happen but the % chance for the same ATP stays the same.

 

Example:

at 300 ATP 3 UFOs get introduced: landing, exland, lightcru,

the chances are 30%, 20%, 50% respectively for these UFOs to spawn when the mission gets picked.

Lets say we introduce another UFO (supplyship) at 350 ATP with 50 points. This means that the points for the other have already degraded for instance to 15, 10, 25.

Now the points are 15, 10, 25 and 50. Altogether this equals to a 15%, 10% ,25% and 50% chance to get this particular UFO to spawn when the mission gets picked.

Nothing much is know about how quickly points degrade. Only 2 things are for sure:

  • The ratio always stays the same because points always degrade equally and never really vanish
  • In X-Division, i have never seen an UFO from the last phase spawn in the current one. So points degrade so quickly that they a not appropriate UFO phase spawn is almost equivalent to 0%.

 

 

So when the game decides to spawn a wave it first determines how many UFOs will spawn. After that it checks all available missions and rolls for the first. Then it counts together the points and roles for which UFO spawns for that mission. Rinse and repeat.

Once per wave UFOs will only spawn once per wave, effectively increasing the chance for other missions to get picked after they dropped out ( got picked ).

Escorts are determined in the same way. First the Escort chance gets taken ( which is real % this time), if the ship gets an escort the interceptors will get roled for in the same way - points together and role.

 

So this tells you not how much a landingship can spawn. The best method is simply to

  1. Set the starting ATP to the desired phase
  2. get earth wide coverage with a cheated radar
  3. put a quantum encryptor into the starting layout of the base
  4. Collect the data of every UFO that spawns intil the end of the phase
  5. Rinse and repeat

After 5 phases you will have a statistical data for everything that can spawn in that phase.

Here is my data:

medium scout: 7

bomber cruiser: 2

light cruiser: 6

Striker corvette: 6

terror battleship: 3

light shuttle: 6

terror carrier: 2

landingship: 3

exlanding: ?

 

sound.xml & sound_gc.xml

 

On 21.11.2016 at 10:01 PM, Policenaut said:

Some crash testing ahead:
Windows 7 Laptop - cannot reproduce crashing when loading GC saves
Windows XP PC - can reproduce crashing when loading GC saves
XP PC has better graphics card and processor. XP uses Intel processor and W7 laptop uses AMD processor. Both are 32bit systems.

Test on Windows XP PC - each test was repeated multiple times.

  • #1. No ambient sound mod enabled - no apparent problems
  • #2. Ambient sounds without fix - freeze/crash during load of GC save from main menu and when switching to Geoscape, random crashing afterwards on Geoscape more details later below
  • #3. Ambient sounds with fix (group 1 instead of 2 + modmerge improvements) - worked fine when loading from main menu, had one crash when changing to Geoscape, random crashing afterwards on Geoscape more details later below
  • #4. Ambient sounds with alternate fix 1 (#3 + looping ambient sounds use group 2 with no repeattimer) - worked fine when loading from main menu, ambient sounds no longer looped and hard CTD which created a .dmp file when changing to Geoscape - .dmp file here: XenonautsCrashDump(Ambient sounds with alternate fix 1).dmp
  • #5. Ambient sounds with alternate fix 2 (#3 + looping ambient sounds use repeattime="0" instead of repeattime="0-0") - worked fine when loading from main menu and doesn't seem to crash most of the time when loading Geoscape, random crashing afterwards on Geoscape more details later below
  • #6. Ambient sounds with alternate fix 3 (#3 + looping ambient sounds use repeattime="0.01-0.02" instead of repeattime="0-0" or repeattime="0") - worked fine when loading from main menu and doesn't seem to crash most of the time when loading Geoscape, random crashing afterwards on Geoscape but much less than with repeattime="0-0" or repeattime="0" more details later below
  • #7. Ambient sounds with alternate fix 4 (#3 + no looping ambient sounds) - worked fine when loading from main menu and doesn't seem to crash most of the time when loading Geoscape, random crashing afterwards on Geoscape but much less than with looping ambient sounds more details later below

During all tests except #1 after completing a GC mission via loading a GC save from the main menu and returning to the Geoscape, and then trying to load another GC save would cause the game to crash every time during load. Test #6 and test #7 was able to load saves sometimes but never more than once before crashing and the loaded save would be more crash prone.
During all tests except #1 after completing a GC mission from a GC save from the main menu and then returning to the Geoscape, the game would randomly crash after fast forwarding time for a bit on the Geoscape. Test #6 and test #7 had much less crashing but it could still happen.
During all tests except #1 the switch to Geoscape could sometimes crash, test #3-7 experienced it much less than test #2.
Loading a Geoscape save from the main menu and then never loading another save seems to never trigger any of these crashes.
There was no apparent difference between quicksaves, autosaves and manual saves during my testing.
The logfile.txt never reported anything of note.

Summary:

It seems that the prime cause of the crashing was the looping ambient sounds using repeattime="0-0" and group="2". Changing looping ambient sounds to use repeattime="0" seems to improve it somewhat but the problem still remains. Changing looping ambient sounds to be above 0, i.e repeattime="0.01-0.02", seems to improve it even more but there's still a chance of crashing. Removing the looping ambient sounds completely was similar to changing them to use a repeattime above 0. Not using any ambient sounds at all seems to work flawless. I could load saves any number of times without any issues.

There seems to be some inherent problem with repeattime that the ambient sounds use. I'm not a programmer but my guess is that the timer data is not properly saved in the GC save file which causes the crashing. I have no idea why the Windows 7 laptop, which is less powerful than my Windows XP PC, never experienced any crashing. Is it an Intel/AMD issue or is it related to the operating system?

However, I will later upload a version of the tropical/swamp tileset to steam workshop/nexusmods without ambient sounds and update the Ultimate Ambient Sounds to include those ambient sounds. I will also change it to use the data in test #6. It should hopefully reduce the crashing when loading GC saves for people who experience it but it won't fully eliminate it. There's nothing I can do to fix the bugs related to the ambient sound system repeattime and the sound system in general.

Thanks to everyone who helped investigate this issue and hopefully this gets fully fixed in a future X:CE update.

 

Suppression mechanics and formulas

On 1.12.2016 at 4:07 PM, Charon said:

Summary Suppression mechanics:

  • The threshold for alien units is the bravery stats value. Once it exceeds 0 the unit gets suppressed
    It doesnt seem to be affected by "regeneration" abilities, but it does regnerate, like moral would normally ( untested )
     
  • <ArmourSuppressionPercentage>1</ArmourSuppressionPercentage> activated means that armour reduces incoming suppression damage by its armour in %. So a 20 armour reduces the suppression damage by 20%. This can go up to 100% decrease.
    It is possible to modify the importance of the armour with this value, "1" meaning 100% of the armour.
    The degradation of armour means that more suppression damage can be dealt
     
  • The formula for the armour reduction is ( Armour - mitigation of the weapon)
    The formula for the suppression damage is: suppression value * 52/75 ( against aliens) * 1-armour reduction
    The total formula is: Bravery Value - ( suppression value * 52/75 ( against aliens, its 1 for xenonauts) * 1-armour reduction )
     
  •  i think its an interesting system because
    1. it makes armour degradation important as less armored units are more prone to suppression. This is a real battlefield waryness implemented. Because the more your armor degrades, the more prone to suppression you become. I think its a nice "real" 
    2. it gives weapons with more mitigation an edge over non mitigation weapons.
    All in all i believe this is a valid representation of "battle fatigue", if your armour numbers go drastically over 100 than its hard to use that system though.
     
  • If you dont activate this system with <ArmourSuppressionPercentage>0</ArmourSuppressionPercentage> its a flat counter.
     
  • The formula for this system is:
    suppression value * 52/75 ( against aliens, its 1 for xenonauts ) - armour value
    Bravery Value - ( suppression value * 52/75 ( against aliens, its 1 for xenonauts) - armour value )
    If that value goes beloew 0 the unit is suppressed
     
  • Every "bullet" carries the same suppression value, and every "shot" only gets counted once per unit, no matter how many bullets gets sprayed. 1000 bullets carry the same impact as 1 does, if it happens in the same shoot.
     
  • Theres a third system. If you set the <ArmourSuppressionPercentage>1</ArmourSuppressionPercentage> to something like 0.00001 you are completely offsetting the armor percentage decrease, but 1 point.

    The advantage of this system is that you are evading the issue that suppression damage is always armour type dependend. With this you can set up a completely flat system, without any armour interfering, where the only variables are the suppression value minus 1, and the bravery stat of the unit.

    Heres an example:

    [3744] Soldier (AI character 0) hit suppression:
    [3744]   armour damage reduction (17) = max(0, armour resistance (17) - armour mitigation (0))
    [3744]   damage (9) = max(0, damage (10) * armour damage modifier (99))
    [3744]   suppression score (65) - damage (9) = suppression score (56)
    [3744]   morale change by (0.000) = damage (9) * moraleRate (0.000)
     

  • The alien reduction coefficient ( 52/75 ) only seems to apply to sebillians. This means sebillians are around 30% less prone to suppression. This is propably hardcoded to the race. <Props sightRange="18" suppressionMultiplier="0.7" /> it's sebs ai code, not hardcoded.

 

 

Edited by Charon

Share this post


Link to post
Share on other sites

xenopedia.xml:

Some entries in the Vanilla/XCE have additional rows which need to be overtaken as well in order to overwrite them.

Namely: Researches.AlienLeaderInterrogation; Researches.AlienOfficerInterrogation; Researches.AlienInvasion; Researches.AndronDisassembly; Researches.WraithAutopsy; Researches.ReaperAutopsy, and the Researches.AlienAssaultPlasma.

Otherwise this leads to a MODMERGE error.

Edited by Charon

Share this post


Link to post
Share on other sites

Autoresolve seems to do a lot more dmg to the winning squad if the main UFO can evade. From 2 times up to ? dmg.

Share this post


Link to post
Share on other sites

Congratz, you just won the most active user in this forum trophy, take good care of it.

Share this post


Link to post
Share on other sites
On 15.5.2016 at 9:54 AM, Charon said:

For future references its important to keep in mind: XCE is not a mod and doesnt follow the same rules, its the base from wihich the modular system starts to work.

On 15.5.2016 at 9:54 AM, Charon said:

Modmerge doesnt work for the aircraftweapons.xml. It only "update"s but doesnt "insert" new items if 2 mods (excep XCE) add aircraftweapons.xml. This means that in order to have higher priority mod to get acknowledged by the modmerge system it needs to be in the lower priority mod as well for both the items.xml as well as aircraftweapons.xml.

 

Share this post


Link to post
Share on other sites

Weapons which target missiles/torpedos, anti missile weapons or AM for short, produce a crash whenever 2 AM projectiles from the SAME Aircraft are in the game. This applys to 2 AM weapons equipted on the same aircraft as well as the shoot before the last AM projectile vanished or hit its targaet.

Share this post


Link to post
Share on other sites

Although there are color codes in the files it is not possible to change ingame colors of strings. Its hardcoded ( Solver ).

Share this post


Link to post
Share on other sites

manufactures.xml

  • If you change or delete an manufacture which a savegame already registered as available the save game will no longer be compatible with your version of xenonauts

Share this post


Link to post
Share on other sites
3 minutes ago, Charon said:

Thats a complicated question.

The files you have to look for are all the AM_***files but this wont really help you in the best way possible although it gives you an idea how the game works.

Let me tell you how the game works.

Theres a minimum UFO count and a maximum UFO count. In our case


  <minMissionCount value="4"     comment="This is the mininum number of mission for a wave." />
  <maxMissionCount value="7"    comment="This is the maxinum number of mission for a wave. Numbers from the next two parameters will be added to it." />

the next 2 parameters are


  <maxMissionAlienBaseModifier value = "1" comment = "Add this much to maxMissionCount for every alien base on the map" />
  <maxMissionHumanBaseModifier value = "0" comment = "Add this much to maxMissionCount for every human base on the map" />

and the ATP for when the maxMissionCount gets spawned


  <highBandTicker  value="1400" comment="This is the ticker value from where the maxMissionCount missions are going to be spawned." />

This is the new count.


Then there are the AM_* files. Everyone is a respective mission which can get picked. These are the categories


Ticker	230
Chance	10
Escort chance	100
Once per wave	true

The ticker value is the starting point from which the game is allowed to pick this particular mission when the wave wheel spins. The chance for it is the chance for it to get picked, although its not "%" but "points". 10 means 10 "points" not 10%. All points from all mission files will get added up just like every mission gets different big stops in a roulette. Other files have 8 points and some others 13 for instance.

In our case we set the total number to 100 points which means the 10 points is actually 10% in our case.

Once per wave means that this mission can only be picked once per wave. This doesnt mean that anotehr mission cant spawn the same UFO with another goal.

These are the other variables


m:airplane.alien.corvette	150	100
m:airplane.alien.landingship	300	30
m:airplane.alien.exlandingship	300	20
m:airplane.alien.lightcruiser	300	50
m:airplane.alien.supplyship	700	20
m:airplane.alien.exsupplyship	700	10
m:airplane.alien.carrier	700	70
m:airplane.alien.cargoship	1100	20
m:airplane.alien.excargoship	1100	10
m:airplane.alien.battlecarrier	1100	70
e:airplane.alien.fighter	100	100
e:airplane.alien.heavyfighter	300	100
e:airplane.alien.hunter	700	100
e:airplane.alien.interceptor	1100	100
e:airplane.alien.heavyinterceptor	1400	100

The second row is the ATP at which this particular UFO can be spawned. The third row is the "chance" again, or "points". The first is the UFO. Note that there can be the same UFO for different ATP values.

This means that all the "chance" points for an ATP will get added up. In our case all points are the % at the same time.

This points will equally degrade over time make them less likely to happen but the % chance for the same ATP stays the same.

 

Example:

at 300 ATP 3 UFOs get introduced: landing, exland, lightcru,

the chances are 30%, 20%, 50% respectively for these UFOs to spawn when the mission gets picked.

Lets say we introduce another UFO (supplyship) at 350 ATP with 50 points. This means that the points for the other have already degraded for instance to 15, 10, 25.

Now the points are 15, 10, 25 and 50. Altogether this equals to a 15%, 10% ,25% and 50% chance to get this particular UFO to spawn when the mission gets picked.

Nothing much is know about how quickly points degrade. Only 2 things are for sure:

  • The ratio always stays the same because points always degrade equally and never really vanish
  • In X-Division, i have never seen an UFO from the last phase spawn in the current one. So points degrade so quickly that they a not appropriate UFO phase spawn is almost equivalent to 0%.

 

 

So when the game decides to spawn a wave it first determines how many UFOs will spawn. After that it checks all available missions and rolls for the first. Then it counts together the points and roles for which UFO spawns for that mission. Rinse and repeat.

Once per wave UFOs will only spawn once per wave, effectively increasing the chance for other missions to get picked after they dropped out ( got picked ).

Escorts are determined in the same way. First the Escort chance gets taken ( which is real % this time), if the ship gets an escort the interceptors will get roled for in the same way - points together and role.

 

So this tells you not how much a landingship can spawn. The best method is simply to

  1. Set the starting ATP to the desired phase
  2. get earth wide coverage with a cheated radar
  3. put a quantum encryptor into the starting layout of the base
  4. Collect the data of every UFO that spawns intil the end of the phase
  5. Rinse and repeat

After 5 phases you will have a statistical data for everything that can spawn in that phase.

Here is my data:

medium scout: 7

bomber cruiser: 2

light cruiser: 6

Striker corvette: 6

terror battleship: 3

light shuttle: 6

terror carrier: 2

landingship: 3

exlanding: ?

 

 

Share this post


Link to post
Share on other sites

1 hour ago, Solver said:

Damage randomisation when you attack aliens seems to be:

Damage = WeaponDamage * RaceBonus * (1 + Reduction * 0.01)

where Reduction = Random(0, DamageRandomChance * 2)

Share this post


Link to post
Share on other sites

Modmerge doesnt work for the aircraftweapons.xml. It only "update"s but doesnt "insert" new items if 2 mods (excep XCE) add aircraftweapons.xml. This means that in order to have higher priority mod to get acknowledged by the modmerge system the new items and weapons need to be in the lower priority mod as well for both the items.xml as well as aircraftweapons.xml. Is solvable - bug occurred because every aircraft weapon has to be in the items list as well, even the alien ones and the ones not used.

On 6.10.2016 at 6:50 PM, Solver said:

Damage randomisation when you attack aliens seems to be:

Damage = WeaponDamage * RaceBonus * (1 + Reduction * 0.01)

where Reduction = Random(0, DamageRandomChance * 2) - Only between 100% + X%, where X is the damage randomifier. X cant be higher than 100.

Share this post


Link to post
Share on other sites

Xml sheets only save to the 65536 cell, which means for instance that the researches.xml only saves to the 645th row. After that it bugs out. Solution: put the remaining research lines into another researches.xml and make another mod with it called part 2. Looks to work fine, an invisible bug stopped the game from taking additional cells after the 650th one.

Share this post


Link to post
Share on other sites

If you are working with the manufacture_categories.xml remember to put an modmerge command like "replace" on the head of the file.

Share this post


Link to post
Share on other sites

ManTech.ParticleClip from the vanilla files is buggy, take extreme caution in using that.

Edited by Charon

Share this post


Link to post
Share on other sites

ManTech.ParticleClip from the vanilla files is buggy, take extreme caution in using that.

The vanilla manufactures.xml has code lines which excel cant reproduce/deal with. If you try to modmerge/change these lines without the proper code, which needs an notepad++ or similar program edit, the game modmerge errors your file out.

Share this post


Link to post
Share on other sites

Hall of Fame for @Policenaut

34 minutes ago, Policenaut said:

Some crash testing ahead:
Windows 7 Laptop - cannot reproduce crashing when loading GC saves
Windows XP PC - can reproduce crashing when loading GC saves
XP PC has better graphics card and processor. XP uses Intel processor and W7 laptop uses AMD processor. Both are 32bit systems.

Test on Windows XP PC - each test was repeated multiple times.

  • #1. No ambient sound mod enabled - no apparent problems
  • #2. Ambient sounds without fix - freeze/crash during load of GC save from main menu and when switching to Geoscape, random crashing afterwards on Geoscape more details later below
  • #3. Ambient sounds with fix (group 1 instead of 2 + modmerge improvements) - worked fine when loading from main menu, had one crash when changing to Geoscape, random crashing afterwards on Geoscape more details later below
  • #4. Ambient sounds with alternate fix 1 (#3 + looping ambient sounds use group 2 with no repeattimer) - worked fine when loading from main menu, ambient sounds no longer looped and hard CTD which created a .dmp file when changing to Geoscape - .dmp file here: XenonautsCrashDump(Ambient sounds with alternate fix 1).dmp
  • #5. Ambient sounds with alternate fix 2 (#3 + looping ambient sounds use repeattime="0" instead of repeattime="0-0") - worked fine when loading from main menu and doesn't seem to crash most of the time when loading Geoscape, random crashing afterwards on Geoscape more details later below
  • #6. Ambient sounds with alternate fix 3 (#3 + looping ambient sounds use repeattime="0.01-0.02" instead of repeattime="0-0" or repeattime="0") - worked fine when loading from main menu and doesn't seem to crash most of the time when loading Geoscape, random crashing afterwards on Geoscape but much less than with repeattime="0-0" or repeattime="0" more details later below
  • #7. Ambient sounds with alternate fix 4 (#3 + no looping ambient sounds) - worked fine when loading from main menu and doesn't seem to crash most of the time when loading Geoscape, random crashing afterwards on Geoscape but much less than with looping ambient sounds more details later below

During all tests except #1 after completing a GC mission via loading a GC save from the main menu and returning to the Geoscape, and then trying to load another GC save would cause the game to crash every time during load. Test #6 and test #7 was able to load saves sometimes but never more than once before crashing and the loaded save would be more crash prone.
During all tests except #1 after completing a GC mission from a GC save from the main menu and then returning to the Geoscape, the game would randomly crash after fast forwarding time for a bit on the Geoscape. Test #6 and test #7 had much less crashing but it could still happen.
During all tests except #1 the switch to Geoscape could sometimes crash, test #3-7 experienced it much less than test #2.
Loading a Geoscape save from the main menu and then never loading another save seems to never trigger any of these crashes.
There was no apparent difference between quicksaves, autosaves and manual saves during my testing.
The logfile.txt never reported anything of note.

Summary:

It seems that the prime cause of the crashing was the looping ambient sounds using repeattime="0-0" and group="2". Changing looping ambient sounds to use repeattime="0" seems to improve it somewhat but the problem still remains. Changing looping ambient sounds to be above 0, i.e repeattime="0.01-0.02", seems to improve it even more but there's still a chance of crashing. Removing the looping ambient sounds completely was similar to changing them to use a repeattime above 0. Not using any ambient sounds at all seems to work flawless. I could load saves any number of times without any issues.

There seems to be some inherent problem with repeattime that the ambient sounds use. I'm not a programmer but my guess is that the timer data is not properly saved in the GC save file which causes the crashing. I have no idea why the Windows 7 laptop, which is less powerful than my Windows XP PC, never experienced any crashing. Is it an Intel/AMD issue or is it related to the operating system?

However, I will later upload a version of the tropical/swamp tileset to steam workshop/nexusmods without ambient sounds and update the Ultimate Ambient Sounds to include those ambient sounds. I will also change it to use the data in test #6. It should hopefully reduce the crashing when loading GC saves for people who experience it but it won't fully eliminate it. There's nothing I can do to fix the bugs related to the ambient sound system repeattime and the sound system in general.

Thanks to everyone who helped investigate this issue and hopefully this gets fully fixed in a future X:CE update.

 

Share this post


Link to post
Share on other sites

Suppression mechanics and Formulas

3 minutes ago, Charon said:

Summary Suppression mechanics:

  • The threshold for alien units is the bravery stats value. Once it exceeds 0 the unit gets suppressed
    It doesnt seem to be affected by "regeneration" abilities, but it does regnerate, like moral would normally ( untested )
     
  • <ArmourSuppressionPercentage>1</ArmourSuppressionPercentage> activated means that armour reduces incoming suppression damage by its armour in %. So a 20 armour reduces the suppression damage by 20%. This can go up to 100% decrease.
    It is possible to modify the importance of the armour with this value, "1" meaning 100% of the armour.
    The degradation of armour means that more suppression damage can be dealt
     
  • The formula for the armour reduction is ( Armour - mitigation of the weapon)
    The formula for the suppression damage is: suppression value * 52/75 ( against aliens) * 1-armour reduction
    The total formula is: Bravery Value - ( suppression value * 52/75 ( against aliens, its 1 for xenonauts) * 1-armour reduction )
     
  •  i think its an interesting system because
    1. it makes armour degradation important as less armored units are more prone to suppression. This is a real battlefield waryness implemented. Because the more your armor degrades, the more prone to suppression you become. I think its a nice "real" 
    2. it gives weapons with more mitigation an edge over non mitigation weapons.
    All in all i believe this is a valid representation of "battle fatigue", if your armour numbers go drastically over 100 than its hard to use that system though.
     
  • If you dont activate this system with <ArmourSuppressionPercentage>0</ArmourSuppressionPercentage> its a flat counter.
     
  • The formula for this system is:
    suppression value * 52/75 ( against aliens, its 1 for xenonauts ) - armour value
    Bravery Value - ( suppression value * 52/75 ( against aliens, its 1 for xenonauts) - armour value )
    If that value goes beloew 0 the unit is suppressed
     
  • Every "bullet" carries the same suppression value, and every "shot" only gets counted once per unit, no matter how many bullets gets sprayed. 1000 bullets carry the same impact as 1 does, if it happens in the same shoot.

Share this post


Link to post
Share on other sites

Suppression mechanics and formulas

Theres a third system. If you set the <ArmourSuppressionPercentage>1</ArmourSuppressionPercentage> to something like 0.00001 you are completely offsetting the armor percentage decrease, but 1 point.

The advantage of this system is that you are evading the issue that suppression damage is always armour type dependend. With this you can set up a completely flat system, without any armour interfering, where the only variables are the suppression values minus 1, and the bravery stat of the unit.

Share this post


Link to post
Share on other sites

Heres an example:

[3744] Soldier (AI character 0) hit suppression:
[3744]   armour damage reduction (17) = max(0, armour resistance (17) - armour mitigation (0))
[3744]   damage (9) = max(0, damage (10) * armour damage modifier (99))
[3744]   suppression score (65) - damage (9) = suppression score (56)
[3744]   morale change by (0.000) = damage (9) * moraleRate (0.000)
 

Share this post


Link to post
Share on other sites

The alien reduction coefficient ( 52/75 ) only seems to apply to sebillians. This means sebillians are around 30% less prone to suppression. This is propably hardcode to the race.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

×