Charon Posted May 15, 2016 Share Posted May 15, 2016 (edited) 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 Set the starting ATP to the desired phase get earth wide coverage with a cheated radar put a quantum encryptor into the starting layout of the base Collect the data of every UFO that spawns intil the end of the phase 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 April 23, 2017 by Charon Quote Link to comment Share on other sites More sharing options...
Charon Posted May 15, 2016 Author Share Posted May 15, 2016 Reserved Quote Link to comment Share on other sites More sharing options...
Charon Posted May 15, 2016 Author Share Posted May 15, 2016 Reserved Part 2 Quote Link to comment Share on other sites More sharing options...
Charon Posted June 19, 2016 Author Share Posted June 19, 2016 (edited) 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 June 19, 2016 by Charon Quote Link to comment Share on other sites More sharing options...
Charon Posted June 23, 2016 Author Share Posted June 23, 2016 Autoresolve seems to do a lot more dmg to the winning squad if the main UFO can evade. From 2 times up to ? dmg. Quote Link to comment Share on other sites More sharing options...
Charon Posted July 13, 2016 Author Share Posted July 13, 2016 You can only "update" and not "replace" the civilian code in aprops.xml Quote Link to comment Share on other sites More sharing options...
damnboy10 Posted July 14, 2016 Share Posted July 14, 2016 me too.. reserve Quote Link to comment Share on other sites More sharing options...
Charon Posted July 14, 2016 Author Share Posted July 14, 2016 Congratz, you just won the most active user in this forum trophy, take good care of it. Quote Link to comment Share on other sites More sharing options...
Charon Posted July 26, 2016 Author Share Posted July 26, 2016 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. Quote Link to comment Share on other sites More sharing options...
Charon Posted July 26, 2016 Author Share Posted July 26, 2016 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. Quote Link to comment Share on other sites More sharing options...
Charon Posted August 5, 2016 Author Share Posted August 5, 2016 Although there are color codes in the files it is not possible to change ingame colors of strings. Its hardcoded ( Solver ). Quote Link to comment Share on other sites More sharing options...
Charon Posted August 30, 2016 Author Share Posted August 30, 2016 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 Quote Link to comment Share on other sites More sharing options...
Charon Posted August 30, 2016 Author Share Posted August 30, 2016 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 Set the starting ATP to the desired phase get earth wide coverage with a cheated radar put a quantum encryptor into the starting layout of the base Collect the data of every UFO that spawns intil the end of the phase 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: ? Quote Link to comment Share on other sites More sharing options...
Charon Posted October 6, 2016 Author Share Posted October 6, 2016 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) Quote Link to comment Share on other sites More sharing options...
Charon Posted October 15, 2016 Author Share Posted October 15, 2016 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. Quote Link to comment Share on other sites More sharing options...
Charon Posted October 16, 2016 Author Share Posted October 16, 2016 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. Quote Link to comment Share on other sites More sharing options...
Charon Posted October 25, 2016 Author Share Posted October 25, 2016 If you are working with the manufacture_categories.xml remember to put an modmerge command like "replace" on the head of the file. Quote Link to comment Share on other sites More sharing options...
Charon Posted November 6, 2016 Author Share Posted November 6, 2016 (edited) ManTech.ParticleClip from the vanilla files is buggy, take extreme caution in using that. Edited November 8, 2016 by Charon Quote Link to comment Share on other sites More sharing options...
Charon Posted November 8, 2016 Author Share Posted November 8, 2016 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. Quote Link to comment Share on other sites More sharing options...
Charon Posted November 21, 2016 Author Share Posted November 21, 2016 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. Quote Link to comment Share on other sites More sharing options...
Charon Posted December 1, 2016 Author Share Posted December 1, 2016 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. Quote Link to comment Share on other sites More sharing options...
Charon Posted December 5, 2016 Author Share Posted December 5, 2016 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. Quote Link to comment Share on other sites More sharing options...
Charon Posted December 5, 2016 Author Share Posted December 5, 2016 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) Quote Link to comment Share on other sites More sharing options...
Charon Posted December 5, 2016 Author Share Posted December 5, 2016 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. Quote Link to comment Share on other sites More sharing options...
Charon Posted December 5, 2016 Author Share Posted December 5, 2016 <Props sightRange="18" suppressionMultiplier="0.7" /> it's sebs ai code, not hardcoded. Quote Link to comment Share on other sites More sharing options...
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.