Thank you. You made things a bit clearer. I chose 45 and 8 in the .ini. And then 6 for aim and 4 for mobility (hopefully, this means you lose mobility faster than aim). I will have to test that.
Vanilla Red Fog notes say that movement and minimum Aim penalty of -15 cannot be removed by Medkits. Based on the function presented, I can now heal the debuff away but the -2 Mobility penalty stays?
Wait, can you explain what's happening a bit more? In vanilla, red fog penalties aren't ever removed by medkits, but for Long War if you heal back to 100% health it should remove any and all penalties for both aim and mobility. Should be the same with this mod added onto Long War.
If you're trying to use this with Vanilla it probably won't work.
Hi. Yeah, as LeoKian said, I didn't even look at the original function in vanilla. In long War, the function uses a current health / max health ratio to determine the Red fog effects, so if creature is cured, Red Fog won't apply any penalty.
Per the LW Changelog: "Aim and Mobility penalty scales linearly with damage taken". So Red Fog in LW not only applies to aliens and robots now but acts completely differently. I am guessing that the Mobility penalty follows the same function as the Aim penalty?
Hi. It depends on the version you downloaded. In LeoKian's files, yes. In the "all in one" file, you can choose different parameters for Aim and Mob. Even if you choose to install one of the original files (LeoKian's), you can download the geogebra visualizer to understand the effects on Aim and/or Mob, as well as the max values determined in DGC.ini.
Gotta make sure you don't already have existing settings applied. If you do, apply the uninstall.upk to clear previous settings, then apply new settings.
I like people who find such matters trivial... Keeping the GeoGebra file up to date for a third S variable, that would be trivial ! (strange editing behavior in the Nexus tonight...)
I haven't played XCOM in a while, but I thought the mobility penalty also affected the range of grenades and rockets, although I could just be confusing it with chem/flashbangs. There's quite a bit of empty space in the ApplyHPStatPenalties function, so it has room to grow if AoE could be added, but that would need adding new variables from different functions. That's above my head, but it shouldn't be too bad for someone more experienced with modding XCOM. Then again, sometimes surprising things are hardcoded, so it's hard to say for sure.
You can't re-use variables from different functions. It was exploited by modders for some time, but then we discovered that it creates more problems than it solves: CTDs on Linux and Mac and weird behavior on Windows.
You can resize objects with patcher, so fitting the code in is not a problem. But you really shouldn't use 'borrowed' variables. Instead of this, you can turn a variable into static array, effectively increasing the number of variables of the same type. For example, if you need two int variables and you have just one, with relatively simple editing you can turn that one int into int[2] static array and then use var[0] as first variable and var[1] as second.
Fair enough. That being said, XGUnitNativeBase.m_aCurrentStats is already in the ApplyHPStatPenalties function, and if the AoE penalties are stored in that same array (which they might not be), then it would be fairly trivial to add in a Red Fog AoE penalty, wouldn't it?
That being said, XGUnitNativeBase.m_aCurrentStats is already in the ApplyHPStatPenalties function, and if the AoE penalties are stored in that same array (which they might not be), then it would be fairly trivial to add in a Red Fog AoE penalty, wouldn't it?
Yes. But as you pointed out, surprising things are hardcoded sometimes.
97 comments
Tl;dr for anyone late to the party. Works with LW 1.0.
You can edit the penalty in the defaultgamecore.ini
SW_ABDUCTION_SITES=35.0f ; Red Fog aim penalty cap
SW_COVER_INCREASE=6.0f ; Red Fog mobility penalty cap
then download the main file from this mod and chose what version you want to use. install it with PatherGUI.
I set aim penalty to 50 and mobility cap to 8. And I use 1/4 from this mod.
Also, when you use medkits the penalties will be reduced or even eliminated if you get up to full health.
If you're trying to use this with Vanilla it probably won't work.
Yeah, as LeoKian said, I didn't even look at the original function in vanilla.
In long War, the function uses a current health / max health ratio to determine the Red fog effects, so if creature is cured, Red Fog won't apply any penalty.
It depends on the version you downloaded.
In LeoKian's files, yes.
In the "all in one" file, you can choose different parameters for Aim and Mob.
Even if you choose to install one of the original files (LeoKian's), you can download the geogebra visualizer to understand the effects on Aim and/or Mob, as well as the max values determined in DGC.ini.
Other mods I've used PatcherGUI for are working fine, it's just this one. What's wrong?
Are you using the latest PatcherGUI version?
Keeping the GeoGebra file up to date for a third S variable, that would be trivial !
(strange editing behavior in the Nexus tonight...)
You can't re-use variables from different functions. It was exploited by modders for some time, but then we discovered that it creates more problems than it solves: CTDs on Linux and Mac and weird behavior on Windows.
You can resize objects with patcher, so fitting the code in is not a problem. But you really shouldn't use 'borrowed' variables. Instead of this, you can turn a variable into static array, effectively increasing the number of variables of the same type. For example, if you need two int variables and you have just one, with relatively simple editing you can turn that one int into int[2] static array and then use var[0] as first variable and var[1] as second.
Fair enough. That being said, XGUnitNativeBase.m_aCurrentStats is already in the ApplyHPStatPenalties function, and if the AoE penalties are stored in that same array (which they might not be), then it would be fairly trivial to add in a Red Fog AoE penalty, wouldn't it?
Keeping the GeoGebra file up to date for a third S variable, that would be trivial !
Yes. But as you pointed out, surprising things are hardcoded sometimes.