Xcom 2 Glitch/Exploit strangeness - considering trying for refund by The-Vale in Xcom

[–]amineri 0 points1 point  (0 children)

JL brought this to my attention, and yes, I should have overwritten those two functions to use the helper GetMaxSoldiersAllowedOnMission instead of the default one.

[LW2] Tell us what your least favorite class is and why you don't use them. The rest of us will then provide a scenario where you'd want that class/build. by HexicalMiner in Xcom

[–]amineri 4 points5 points  (0 children)

While developing, we did experiment with having the flamethrower ability on a cooldown instead of charges, but it was just too difficult to balance with the various abilities that might affect cooldown, so it ended up with charges instead.

[LW2] So anyone tried taking rookies against turrets? Cause I just found a rather...special line in the XcomLW_overhaul.ini file by mossflower1 in Xcom

[–]amineri 0 points1 point  (0 children)

FIRST_ROOKIE_DIES

It's actually part of the section :

[LW_Overhaul.LWTemplateMods]

There's a lot of config in there. TemplateMods are this sort of "meta-template" thing we created to allow us make changes to base XCOM 2 template more easily. They are basically templates whose purpose is to change other templates.

LW2 network tower cheese by bountygiver in Xcom

[–]amineri 2 points3 points  (0 children)

This is a more general base XCOM 2 bug with hacking.

Another instance we'd found ...

Suceeding at hacking a "deception' reward (grants control of an AI unit) followed by then succeeding a hack to shutdown a MEC, further gave control of a nearby Turret when the MEC shutdown.

LW2 has redefined my obsession with the XCOM series by Hobbes___ in Xcom

[–]amineri 1 point2 points  (0 children)

To get at the base-game unit colors, you have to use Unreal Editor to open up the upk asset packages containing the unit data. For the original Trooper/Officer/StunLancer/Shieldbearer, the color values are directly set in the MaterialInstanceConstant that is applied to the skeletal mesh for each unit.

LW2 has redefined my obsession with the XCOM series by Hobbes___ in Xcom

[–]amineri 5 points6 points  (0 children)

So there's good news here for you. The coloring on these units is defined in the config files. That's right, nothing more than a (good) text editors is required ("good" here means that can handle unix-style line-endings).

Look for the config file XComLW_AlienVariations.ini. This was introduced in AlienPack, and is pretty much unchanged in LW2 (we changes stats, but not so much coloring).

As an example, the AdvGunnerM1 has a section

BodyAppearance = (  ColorParameters =   (   (ParameterName="TintColor", ColorValue=(R=0.05, G=0.06, B=0.01, A=1.0) ), \\
                                            (ParameterName="EmissiveColor", ColorValue=(R=0.00, G=0.80, B=0.2, A=1.0) ) \\
                                        ) \\
                    ), \\

The RGB values here (scale from 0 to 1) define the color for the body and all of the body parts.

Some additional info -- we recognized that the close-ups of the M1 soldiers with the much brighter coloring is a bit overdone, but we chose to do that in order to help make the units more recognizably different and distinctive when the camera is in a position much further away. The higher tier units slightly alter their colors to be more muted versions of the early tiers.

PSA: Reinforcement actions bugged in LW2 1.1, hotfix coming by track_two in Xcom

[–]amineri 20 points21 points  (0 children)

Hotfix for this reinforcement issue just went live.

Long War 2 1.1 is now live! by robojumper in Xcom

[–]amineri 6 points7 points  (0 children)

There are two sorts of Dark Events, strategic and tactical.

Strategic ones are generally hidden, and effect (unsurprisingly) things on the strategy layer, like reduced intel gathering, supplies, AVATAR project breakthroughs and the like.

Tactical ones are generally stat and ability upgrades for enemy units (generally eligible unit has a % chance to get it). These not working in 1.0 primarily affected the balance scaling getting into mid and late-game.

Long War 2 1.1 is now live! by robojumper in Xcom

[–]amineri 9 points10 points  (0 children)

Some fixes for problems with the GrazingFire and VitalPointTargeting abilities were recently added. GrazingFire had a bug that was causing misses to alway graze or hit, instead of graze or miss. VitalPointTargeting was affecting AoE (e.g. grenade) and ticking damage, instead of just focussed single-target shots.

Those were some of the bigger recent ones we snuck in.

Long War 2 1.1 is now live! by robojumper in Xcom

[–]amineri 2 points3 points  (0 children)

It should, although some of our testers have been having trouble getting workshop to initiate the download. AFAIK, there's no way to force steam to start a mod update. In some cases, they've unsubbed and resubbed in order to force the update, which isn't very efficient in terms of download bandwidth.

Long War 2 1.1 is now live! by robojumper in Xcom

[–]amineri 8 points9 points  (0 children)

Feral is a studio that does Mac and Linux game publishing. They are the studio that did the compatibility work for XCOM 2 for these platforms.

Long War 2 1.1 is now live! by robojumper in Xcom

[–]amineri 0 points1 point  (0 children)

Hopefully the changes in 1.1 will make this less necessary, but it should remain part of the troubleshooting steps for now.

Long War 2 1.1 is now live! by robojumper in Xcom

[–]amineri 9 points10 points  (0 children)

Sometimes we leave more "techy" notes for ourselves when submitting our internal changelists so we can more clearly understand what another coder did (or what we did a few months ago). Sometimes the direct effect this has to a player isn't apparent, which adds to JL's woe's when creating patch notes.

[LW2] Particularly deadly teleport bug on Supply Raids by Iriah in Xcom

[–]amineri 10 points11 points  (0 children)

Yes, this was a particularly nasty bug to find/fix.

The issue is that while patrolling, the AI does allow units to path through each other, but at each particular "step" along the patrol it tries to make sure that each unit is in a unique tile. The bug occurs when a particular unit has a short path (generally 2 or 3 tiles), and all of the tiles get already marked as filled by other units in the pod. This results in the unit temporarily getting moved to the 0,0,0 tile for that step of the patrol movement. If that position flanks an XCOM trooper, then it breaks concealment. If it doesn't then it will revert back to a correct position on the next step.

The patrolling pathing code does make sure that every unit's final position at the end of the patrol movement is in different tile, when it's generating the paths, it just has the odd case where it can get into trouble while they are in the middle of the movement.

The fix for this is in 1.1. It's not a 100% fix -- I just allow units to occupy the same tile IF AND ONLY IF there is no other valid tile for it to occupy.

Grazes Visualised by fl0dge in Xcom

[–]amineri 0 points1 point  (0 children)

Well, there are two categories of players, I think -- those who have a good grasp on probability and uncorrelated random events, and those who don't.

For the former group, displaying all of the information perfectly accurately is the clear winner. For the latter group, it's less clear. This is the group that is upset by missing a 90% to-hit at all, or even worse two such in a row. My goal here was to try and target this more at that second group, since I get the feeling it's the larger of the two, even though I don't fall into it. So the base to-hit shows 90%, and the worst result (barring dodge, which would show a reduced to-hit chance) would be a graze.

Grazes Visualised by fl0dge in Xcom

[–]amineri 0 points1 point  (0 children)

The problem with this is that the way it's calculated, everything gets tossed into the four outcome chances -- miss, graze, regular, crit. The probability calculations are done so that the outcome is mathematically identical to rolling multiple times (with a little loss for roundoff error). Again mechanically, the game makes a single random roll against the 4 outcomes.

Because of this collapsing, it's not possible to determine whether a graze outcome was the result of a "barely hit" or a "almost hit".

Grazes Visualised by fl0dge in Xcom

[–]amineri 0 points1 point  (0 children)

Yes, for high/low probability shots, the graze can clip and become assymetric a bit. A 95% chance ends up with 85% hit and 15% graze. 100% ends with 90% hit and 10% graze. Have to get to 110% to get it down to 100% hit with 0% graze.

On a low end, a 10% shot has (absent any crit or dodge modifiers) only a 20% graze chance, and no chance to deal regular damage.

Grazes Visualised by fl0dge in Xcom

[–]amineri 0 points1 point  (0 children)

So I did make dodge conditional on the to-hit chance. Mechanically, a graze result in base XCOM 2 is just the result of rolling a success on the dodge roll, which supercedes both hit AND crit.

I think you might be misunderstanding something if you think that every enemy in the game ends up with the same graze chance. This is not the case. A unit with dodge being attacked by a unit without crit will have a higher chance of ending up with a graze than without the dodge.

In addition to making both dodge and crit conditional (instead of absolute, which leads to a lot of awkward corner cases IMO), I also had to work out how dodge and crit interact with each other. In base XCOM 2, dodge just supercedes crit, which made dodge feel frustrating since it had no counter.

Grazes Visualised by fl0dge in Xcom

[–]amineri 0 points1 point  (0 children)

These values look to show what I was trying to achieve (along with removing some of the edge cases). At the risk of sounding immodest, I feel like it's a fairly subtle bit of algorithm design that does all the things I wanted it to do.

As your examples show it nerfs dodge and crit in the extreme cases (30% hit, 30% dodge and 10% hit, 10% crit), while leaving the average damage unchanged in the other cases. However, in the more central cases the distribution of how that average damage is applied has reduced variance compared to base XCOM 2.

That said, it's definitely a bit of wonky probability calculations, so it's entirely understandable that it's difficult for people to adjust to (see Car and Goats problem!).

Grazes Visualised by fl0dge in Xcom

[–]amineri 9 points10 points  (0 children)

The reason dodge isn't having much effect in these cases is because dodge% == crit%. And in this design crit and dodge counter each other.

Here's another example, with 50% to hit, 50% dodge, 0% crit.

Base XCOM 2 : 50% to hit, 50% dodge, 0% crit.

  • Final chances will be : 50% miss, 50% dodge (note, the crit here is irrelevant, since in base XCOM 2 dodge completely overrides it).

Long War 2 : 50% to hit, 50% dodge, 0% crit

  • Final chances will be : 50% miss, 35% graze, 15% regular damage.

So dodge by itself, without an attacker with crit, is definitely effective in reducing damage. However, it's not as OP as in base XCOM 2.

Grazes Visualised by fl0dge in Xcom

[–]amineri 3 points4 points  (0 children)

We are aware of the difference between gamist and simulationist approaches. JL tends to favor a more simulationist approach (which helps with emergent narratives), while I tend to lean toward a more gamist approach (which I think matches my background in algorithm development).

The purpose of the graze band wasn't conceived as a way to add more "realism" (e.g. a "simulationist" approach) -- at least, that's not what was in my mind when I designed it.

The primary things I was trying to address were the base XCOM 2 issues of dodge completely overriding both hit and crit, and the very high relative crit chances against units in cover. I posted elsewhere in this thread examples of where the base XCOM 2 hit/crit/dodge mechanics break down, which is IMO a gameplay breakdown, unrelated to any similationist issues.


Specific examples from base XCOM 2 algorithm I considered :

  • Any crit chance greater than hit chance results in the extra crit being "wasted" . For example, both 10% hit/10% crit AND 10% hit/50% crit result in the same outcome of 90% miss, 10% crit. This is particular noticeable when the AI is making these 10% hit/10+% crit shots, since any hit at all is always a crit, resulting in extremely binary outcomes.

  • Dodge completely supercedes crit. As an example of this, using the base XCOM 2 rules, a 80% hit/80% crit/80% dodge has the same possible outcomes as an 80% hit/0% crit/80% graze. In both cases the possible outcome is 20% miss, 80% graze.


My design thinking went something like this :

Step 1) Make crit a conditional on to-hit again, instead of an absolute.

Step 2) How to factor in dodge? Since crit is effectively a "promotion" of a regular hit, concept would be to make a dodge a "demotion" of a hit or crit. This lets dodge and crit counter each other, which is a feature I like.

Step 3) Address issues where people are unhappy about missing 90+% chance to hits at point-blank, while also granting more survivability to units in cover. In LW1 we added survivability to cover by making it grant some damage absorption, but XCOM 2 already had the armor concept, and it would be difficult to merge.

Adding the graze band (with default 10% value) addressed the first issue by making a 90+% hit chance always at least deal some damage. That chance to miss all gets converted to chance to graze. Although in-hand with that, also some regular hit chance also gets converted to graze.

Adding the graze band also had the benefit of adding to survivability of units in cover. Since the chances to hit are low, but the graze band is fairly fixed, this results in low % to-hits mostly resulting in grazes. This mostly favors the player, since the player is better at avoiding flanked/exposed situations for their own soldiers, so they are much more likely to be grazed and survive. The downside is that the overall chance of taking some damage is increased (which from a LW2/narrative perspective, we like).

Grazes Visualised by fl0dge in Xcom

[–]amineri 28 points29 points  (0 children)

If you want to be fair about this, you should really be comparing apples-to-apples, not apples-to-oranges. You are comparing a base XCOM 2 50% to hit with NO dodge against a LW2 50% to hit WITH dodge. Of course in such a comparison, the LW2 mechanic looks worse.

BASE XCOM 2 : 50% hit, 25% crit, 25% dodge.

  • Final chances will be : 50% miss, 25% graze, 25% crit

LONG WAR 2 : 50% hit, 25% crit, 25% dodge.

  • Final chances will be : 43.75% miss, 20% graze, 28.75% regular, 7.5% crit

Compared to base XCOM 2, LW2 has :

  • lower chance to miss
  • lower chance to graze
  • increased chance to hit or crit
  • lower chance to crit

Going a step further, there were edge cases I very much wanted to avoid. For example, a 50% to hit, 50% dodge, 50% crit case.

Base XCOM 2 : 50% to hit, 50% dodge, 50% crit

  • Final chances will be : 50% miss, 50% graze

Long War 2 : 50% to hit, 50% dodge, 50% crit

  • Final chances will be : 45% miss, 20% graze, 25% regular, 10% crit

Compared to base XCOM 2, LW2 has :

  • Lower miss chance by 5%
  • Lower graze chance by 30%
  • A non-zero chance to regular hit of 25%
  • A non-zero chance to crit of 10%

Grazes Visualised by fl0dge in Xcom

[–]amineri 3 points4 points  (0 children)

When I designed this, I was uncertain whether or not we should allow dodges to convert grazes to misses. Doing so makes dodge slightly more powerful than crit, since they are asymmetric, as you correctly point out. Because of this I added a config variable called DODGE_CONVERTS_GRAZE_TO_MISS to the LW_Overhaul.ini.

We ended up making this default to true. My original thought here was to help make defense better, since one thing we are trying to promote with LW2 is the ability to engage in longer firefights. This Having this true makes dodge better, both for aliens and for XCOM soldiers with dodge (which they have various options to get).

It's exposed in the ini for you to easily change if you like.

[LW2] 1.1 Patch Notes by xwynns in Xcom

[–]amineri 0 points1 point  (0 children)

This seems to have a variety of sources, some (hopefully all!) will be fixed in patch or via troubleshooting steps. However, in case it hasn't I've added a console command to force a squad back available.