Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[Vanshilar]

Not the first time I see Gryphons praised but from my experience Gryphon AI is absolutely suicidal which does not pair well with the Gryphon's weak tank.

Yeah Gryphons really depend on overwhelming firepower. If it doesn't have that, it's toast. Basically a glass cannon.

Having said that, what I do is I put a single HVD on it, with ITU. I'm not sure if it helps the AI with range, but it'll generally stay at standoff-range. It sometimes does decide to charge in, especially with full assault mode on (which admittedly is how I run it most of the time), but that seems to work well. Plus that helps picks off targets.

The main problem with the armor fudge is how to implement such an armor fudge factor. For example, if I just increase armor HP by a factor of 4, then that also increases damage reduction. I'll discuss this in a bit more detail in my reply to Vanshilar below, but I think a reasonable rough estimate could be given by implementing armor "regeneration" to compensate for the ship turning at a rate such that the TTK is increased by a factor of 2, so maybe 1/6th of the starting armor / second. This is actually not even enough, since the most effective combos took the ship out at 17 seconds now, but it'll probably illustrate the effects.

No, regenerating armor will distort the results by favoring weapons good against armor, and disfavoring weapons bad against armor. Also, once armor is gone, it's supposed to be gone, not to come back to block more damage. I would say it's easier to simulate it by having a wider band of armor cells.

Attached is a screenshot of the Dominator and its armor cells (in the lower left corner). As far as I can tell, the size of the armor cells is about 17.5 pixels wide (noting that my display naturally rescales sizes to about 80%, thus the weapon range is important for measurement purposes). So assuming that a shot always hits in an armor band that's 6 cells wide means that you assume all shots will hit in the center half of the Dominator. In practice, not only will shots hit across the entire face of the Dominator, but some shots will be so far off that they miss.

Fortunately, the face of most ships can be approximated as a line, since you're really just hitting the perimeter of the ship most of the time. Thus you can just approximate it as a wider armor band. And thus to accommodate that, the normal distribution for the width of the weapon shot also needs to widen. But these are relatively easy to do.

Unfortunately, it seems like different ships have different armor cell sizes. I'm not sure how that's calculated. The Dominator's armor cells seem to be around 17.5 pixels wide, for example, while the Starliner's is around 28 pixels wide. Obviously, the smaller the armor cell size, the more protection it provides. I don't know how it's determined though, but that might be worth looking at to see which ships have bigger or smaller armor cells (smaller armor cells are better).

Thanks for the thoughtful feedback and criticism. This model really should have probably been validated a bit more, see above. Probably a problem stemming from it being just for fun and not being a real research project but this is also one of my weaknesses as a researcher that I tend to get carried away with models and fumble with the "boring" parts TBH. Comparing to simulation results is important. But there are some questions I have about the simulation: is the enemy turning? Is it retreating? Does it have point defense?

Actually I think the hardest part is already done. Damage to shields is easy to estimate. Damage to hull is also easy to estimate. It's always been how damage to armor is calculated that's difficult to simulate, and also how to conceptualize the effect of maneuvering, weapon spread, etc. Modeling this as a band of armor being hit by a weapon with a distribution (i.e. normal distribution in this case) neatly solves those issues. The width of the armor band encapsulates the width of the ship and how much it rotates, and the width of the normal distribution encapsulates maneuvering and weapon spread (where if it's wider than the armor band, it's considered a miss). These parameters can be estimated from combat results.

I'm not sure what hit strength vs. hull means. Can you elaborate?  From what I understood from the previous thread, for the damage that goes through to hull, the multiplier is not applied, so that's how the model calculates damage. The multiplier is only applied to the proportion blocked by armor.

Any time a weapon hits a ship (i.e. not to shields, but to the ship itself), the hit strength calculation is applied, using the local armor at the point of impact. It doesn't matter if there is any armor remaining or not; even if none is remaining (i.e. it's hitting bare hull), then it's assumed that there is still a residual amount of 5% of the base armor rating for the purposes of this hit strength calculation. And once the summed armor value of the local armor goes below 5%, it again assumes 5% remaining. So that minimum of 5% always exists. Weapon multipliers for the purposes of hit strength as if they're hitting armor (i.e. /2 for kinetic, *2 for HE, /4 for frag) also apply here. This is step #2 above.

When the damage is actually applied to those cells, yes, to hull it always applies as 100%. But that's the damage that has already gone through the hit strength calculation -- that's step #3 above, which is after the damage reduction applied in step #2. This prevents people from doing things like, taking a bunch of Vulcan cannons (500 DPS, 25 frag hit strength), firing a Reaper into the rear of an Onslaught, and then wailing into the hull of the ship with the Vulcans. Well, they can, but it ends up doing 75 DPS to hull (due to the minimum 15% for the hit strength calculation) instead of the 500 DPS stated on the weapon stat card.

For the Locust, because of the hit strength calculation, the damage to hull is going to be 50/(50+75) = 40% of the original damage. So for 2 Locusts firing into hull, the model should be showing that the ship loses 1600 hull per second during the volleys. That should be easy enough to validate by setting shieldregen and shieldmax to 0 and then seeing what happens after armor is gone (assuming no armor regen, of course).

So by the calculations time to kill is 16 sec. In the simulation the time for this combo was 22-28 sec. But that also includes weapons missing and projectile travel time and the enemy rotating I presume.

Actually it doesn't include weapon missing nor travel time, since it's based on how many hits were actually registered; Detailed Combat Results doesn't count misses (although it would be great if it could). You can see for example that there were 212 to 237 Locust hits among the 3 tests, and since each Locust volley is a total of 80 shots, this means the ship died toward the end of the 3rd Locust volley. (All Locust shots hit due to its good tracking.) That's where my time estimates come from.

[attachment deleted by admin]

[CapnHector]

Okay, then we 're almost done since I am now confident in the code. Next step would be to simply calibrate vs simulation results to find the actual normal distribution. But here's a Q that needs to be resolved going forward: I understand from your post that each cell can take advantage of the minimum armor rule. But from https://fractalsoftworks.com/forum/index.php?topic=22331.0 I got that it is instead applied if the matrix's pooled armor value is sub 5% (but specifically not if the pooled value is over 5% even if the cell has 0 armor). That is why my model uses the probability weighted average instead of calculating it cell by cell. If, however, it works cell by cell, then the model is again overestimating locust and needler damage.

But do we have evidence one way or another?

[Vanshilar]

The only time the hit strength damage reduction calculation is applied is when the shot first hits the ship, and that is as a pooled value (step #2). That is where the minimum armor of 5% of base armor rating applies, and when the lowest possible percentage of 15% of damage that gets through (down to 10% if the ship has Polarized Armor) applies. There is no damage reduction for individual cells (regardless of armor or hull) once it splits up the damage calculated in step #2 toward the individual cells (1/15 to each of the 9 inner cells, 1/30 to each of the 12 outer cells) in step #3. When it goes to apply the damage to individual cells, if there is any armor remaining, it will apply the weapon damage type bonuses/penalties (/2 if kinetic, *2 if HE, /4 if frag) toward removing that armor, while any remaining damage remaining beyond that will go toward the hull at 100%. But that's weapon damage type, not hit strength. The hit strength doesn't matter at that point.

The armor mechanics wasn't first described by me (I think that would be FooF, in 2017, before I started playing the game), but I did test out that this is how it works. Specifically, that this matches with the reported armor/hull damage values shown by the game when you hit the same spot over and over again (or, a neighboring spot, etc.).

[CapnHector]

Okay. But here we don't have individual shots but rather normal distribution shaped waves hitting the ship, so a pooled value for a singular hit armor matrix doesn't exist. So what then is the fraction of the pooled total value that the cell sees to calculate 5%? If we are portioning damage to cells according to a reversible map, then is the armor seen by a cell the pooled armor distributed to cells by the same map? It would seem so, since the map we are using is just a multiplication operation. Specifically if a is damage and b is the armor and k is the number of cells. f(a,i,j) is for a cell (i,j) just a/k*c_ij which is the cell specific value. And sum(1/k(c_ij)) = 1 since sum(f(a,i,j))=a.So calculating the damage reduction we have a*a/(a+b)=sum(f(a))sum(f(a))/(sum(f(a))+b)=(a/k*(sum(c_ij))^2/(a/k*(sum(c_ij))+b/k(sum(c_ij))))=a*a*sum(c_ij)/k/(a+b)=sum(f(a*a/(a+b)).

So presumably, if I adjust the model just so that each cell always gets minimum 0.05*startingarmor*hitprobability(cell) for reducing damage of damage*hitprobability(cell) we're golden?

[intrinsic_parity]

Damage gets done to multiple armor cells on a hit, and the damage is not uniformly distributed between the affected cells (outer cells take half damage), so I don't think you can just uniformly apply some factor.


One thing I'm not sure about is where the shots are actually allowed to land? It seems like armor is divided into a grid over the 2D ship model, but I think shots can only really land on 'edge' of the ship? Or are they allowed to penetrate and hit interior cells as well?

[CapnHector]

Sorry, typing math on phone leads to bad notation. But by c_ij I mean each cell has a particular constant factor of its own. In the model this also includes the division of damage. The hit probability matrix is generated as follows: create a 5 row, 10 column matrix and a 5 row, 5 column matrix. The 5 row, 5 column matrix is filled so that all cells have value 1/30. Then the innermost 15 cells are given value 1/15. This is the damage distribution matrix. (The corners should also be set to 0 here, I need to add that). Then this matrix is summed according to a normal distribution several times over the 5 row, 10 column matrix, and corners are set to 0. This is the cell hit probability matrix mentioned. Though it is technically also a damage distribution matrix.

Anyway, what I meant above by f(a,i,j)=a/k*c_ij is exactly what the program does: spread damage over the matrix, multiply by a cell specific factor. Also the armor adjustment is currently done cell by cell. Thinking about it more I suppose I could also construct a way to pool the damage back... But it would be quite natural to calculate it cell by cell since we do not actually have a par of the ship hit. Intuitively I'd assume the pooled armor for the "expected cell matrix" is also calculated just by using the same 5,10 matrix.

You can essentially imagine this in visual terms as there being a superposition of armor cells that are hit by a wave of ghost shots (expected value shots) according to a normal distribution whose intensities sum to the value of a real shot. Then it's also logical that the intensity (armor value) of the expected armor cells that the shots hit varies according to the same distribution function, summing up to the real armor.

The matrix of adjacent cells does extend outside the sprite according to Vanshilar. Shots are assumed to land on a line of (currently) 6 armor cells. The adjacent cells extend 2 cells outward in all directions from each of these cells.

E: Okay I've tried layouts suggested by the model. And it has definitely improved my Conquest builds, but this needs an accuracy parameter. The stupid HACs that the model thinks are so good can't hit the broad side of a space station on a bad day (probably part of the balance on part of Alex) and yet the model gives them the same accuracy as all other weapons which has to be a problem. They are not actually as good at killing frigates as the model would predict for example.

So I'm thinking there should be several versions of the normal distribution which are applied based on weapon accuracy to get more accurate results. Needs a little thought how to put it into code to express the armor checks vs. weapons with several different distributions dealing damage consecutively.

[Vanshilar]

Okay. But here we don't have individual shots but rather normal distribution shaped waves hitting the ship, so a pooled value for a singular hit armor matrix doesn't exist. So what then is the fraction of the pooled total value that the cell sees to calculate 5%?

Oh, I didn't realize it was probability waves hitting the target. I saw that it was normal distribution but didn't realize that's what you were doing. In which case that's more innovative than I thought.

I would think the most direct way to model it is this. Say you're working with a target that's 5 armor cells deep and 10 armor cells wide. That means that the cells that can be hit by the weapon is the middle 1x6 vector of cells. For each of those cells, you can calculate their effective armor rating by pooling the values of the 5x5 cells around them. I don't know if there might be a tensor or convolution function of some sort in R to do this easily, but even if not, it's easy to just code in with a for statement. That's where the 5% minimum armor is applied.

Then, the incoming weapon shot gets modeled as a normal distribution, where the standard deviation depends on the weapon's inherent spread, the target's maneuverability, and the armor cell size. Each of those can be estimated from combat or measured directly. The normal distribution would be to the width of the "hittable" armor cells, in this case, 6 cells. Any amount to either side is assumed to just miss.

From there, the hit strength damage reduction A/(A+B) formula is calculated for each cell. That's where the 15% minimum for the A/(A+B) is applied. So you get a hit strength damage reduction vector from that. Then, the damage as if the shot hit that cell is calculated, then split to the 5x5, then multiplied by the probability of hitting that cell, and is then applied to the original 5x10 armor band. This is then done for each cell in that 1x6 vector.

The order of operations is important; the hit strength damage reduction vector is calculated before any damage is taken off, and doesn't need to be updated during the shot, so this preserves the simultaneity of calculating each shot in the probability wave as the original armor band's values get updated.

I'm not 100% convinced that this is mathematically equivalent to generating statistics from multiple simulations of each shot hitting the armor band one by one, since the hit strength calculation is nonlinear, but realistically the model will be matched to some actual real-world statistics from combat data so those fudge factors will hopefully iron out any inaccuracies in modeling. It would at least be a huge step up from simulating a shot hitting the same armor cell over and over.

[intrinsic_parity]

The distribution should cover the entire area where the shots can go, even if that is wider than the target. And the probabilities for hitting each cell should total to 1 - probability of missing. The probability mass corresponding to a miss is important, and needs to be included because that is what will account for reduced DPS due to missing.

Also, I'm not so sure about trying to model movement-based inaccuracy. Given actual relative movement with no spread, the shot location is not random, so it really should be a bias in the mean of the distribution rather than a variance. But if you try to model some distribution of possible relative movements, you could maybe come up with some distribution of shot locations from that. Although that would still depend on how the automatic aim leading and the AI works as well. All in all, I think it would be pretty tough to model accurately.

I would definitely start with pure weapon spread before worrying about any of that. I'm pretty sure the actual randomness in shots is implemented as a random error in the angle that the shot is fired at relative the the aiming direction. It should be relatively simple to generate a distribution over the target ship based on range, and the original angle distribution from the code using geometry. Idk what distribution the spread angles are sampled from though. Could probably dig through the code to find it, but maybe someone knows (Alex)?

Other than that, I think you're just interesting in keep track of the expected value of damage done to each armor cell and to hull. For a single shot, that should be something like:
EV[damage to cell_a] = probability(shot landing at cell_b)*(damage done to cell_a given shot lands at cell_b) summed over all the cell_b possibilities (and you can just sub hull for cell_a as well). You should be able to do that pretty easily with a loop or two and all the damage calculations can be done easily in each case given the specific cell_a and cell_b.

Edit: I'm actually quite sure that doing this sequentially (basically using the EV of the damage due to the previous shot as the input for the next EV calculation) is not the same as calculating the EV of the damage of multiple sequential shots. But IDK how much error would accrue. Might actually be interesting to calculate both of those things and check the error. I think the EV of a sequence of shots would be:

E[dt] = E[sum(dn)] = sum(E[dn]) where n is the shot number

but then the EV of the 3rd shot (nth shot requires n nested loops which I didn't want to try and represent lol) would be:

E[d3] = sum_s3(sum_s2(sum_s1(  f(f(f(d0|s1)|s2)|s3)  p(s1)p(s2)p(s3) ))) where s1,s2,s3 are the shot locations of each shot (and sum_sn is a sum over the possible shot locations of the n_th shot), so basically you are doing loops over every possible combination of shot locations and adding the damage from that combo. Also f(d|s) is the function that returns the damage given the shot location. Pretty sure you could do it all in a single loop with some fancy indexing, and write the nested damage function recursively as well, so it might be feasible to do for some small number (like <5) of shots (and possible hit locations), just for a test, but the computation cost scales really poorly for large numbers of shots. Also, you should be able to store the values of a bunch stuff from calculating the Ev of each shot to reuse for the next I think.

[Vanshilar]

By the way, I took a look at how the size of the armor cells are determined. The game looks only at the length of the ship sprite, but not the width:

If the length is < 150, then each armor cell is 15 pixels wide.
If the length is between 150 and 300, then each armor cell is 1/10 the length.
If the length is > 300, then each armor cell is 30 pixels wide.

For reference, an Enforcer is 136 pixels long, a Hammerhead is 164 pixels long, an Aurora is 280 pixels long, and a Legion is 308 pixels long. Testing was done by looking at the lower left green icon in combat of an Atlas whose length and width were set to different amounts in atlas.ship.

This has some interesting implications. Since each armor cell is given 1/15 of the base armor rating, then having smaller armor cells is better, since it means those armor points are more densely packed. Assuming that shots tend to hit in different spots, rather than in the same spot over and over, then this could mean as much as a factor of 2 difference in how much armor the incoming fire needs to remove before hitting hull.

Also, since ships are roughly spherical, this means that "wider" ships are better in terms of taking armor damage, since they'll tend to have somewhat smaller armor cells than "longer" ships. However, this is countered by the fact that "wider" ships provide a bigger frontal area that an opposing weapon could hit, which balances this out. So Alex made the right decision here (in basing armor cell size on length).

Taking a couple of examples, Enforcers are 136 pixels long, so their armor cells are 15 pixels wide. At 900 base armor, each armor cell holds 60 armor to start, so that's 4 armor per pixel. Dominators are 180 pixels long, so their armor cells are 18 pixels wide. At 1500 base armor, each armor cell holds 100 armor to start, so that's 5.56 armor per pixel. Onslaughts are 384 pixels long, so their armor cells are 30 pixels wide. At 1750 base armor, each armor cell holds 117 armor to start, so that's 3.89 armor per pixel. So it turns out, Dominators actually have the most concentrated armor protection. It won't help against focused fire, i.e. taking a Reaper hit or something, but over the course of a long battle, with incoming fire from multiple directions, the smaller armor cells means that it'll be able to absorb a surprising amount of damage since there's more armor packed into a given area.

(What the Onslaught has going for it however is that the nose is "jagged" meaning some shots will land more inward and others more outward, and the sides slope away, both of which increase the number of armor cells that can absorb the damage. So this helps it absorb more damage than a smooth or square shape. Not sure if Alex intentionally designed the Onslaught with this in mind, but this contributes to the Onslaught being able to take a lot of punishment.)

E: Okay I've tried layouts suggested by the model. And it has definitely improved my Conquest builds, but this needs an accuracy parameter. The stupid HACs that the model thinks are so good can't hit the broad side of a space station on a bad day (probably part of the balance on part of Alex) and yet the model gives them the same accuracy as all other weapons which has to be a problem. They are not actually as good at killing frigates as the model would predict for example.

Yeah my testing a while back (here) was that, even with Gunnery Implants (best target leading and -25% recoil) and Ballistic Mastery (+33% projectile speed), something like the Mark IX misses around 24% of the time in actual combat. Heavy Autocannon has similar stats so it probably misses a similar amount of time. That's why I figured the model needs to have a wider distribution (wider than the armor) or some other means of accounting for misses. This is also why it makes sense that in testing, the target Dominator ended up taking ~8-9k of armor damage, since that was roughly the width of the ship (about 12 armor cells wide); the remaining shots would've missed, and hence it could be modeled as an armor band that would be ~17 cells wide.

Then in the model, the distribution's variance would be based on the weapon's inherent spread and some function of the weapon's speed and the target's maneuverability (slower projectile speed and higher target maneuverability means greater variance). In terms of weapons doing damage consecutively, easiest hack would be to base it on weapon speed, i.e. fastest weapon resolves first within each time interval.

Also, I'm not so sure about trying to model movement-based inaccuracy. Given actual relative movement with no spread, the shot location is not random, so it really should be a bias in the mean of the distribution rather than a variance. But if you try to model some distribution of possible relative movements, you could maybe come up with some distribution of shot locations from that. Although that would still depend on how the automatic aim leading and the AI works as well. All in all, I think it would be pretty tough to model accurately.

At that point, the shots are no longer independent of each other, so you're really looking at some sort of Markov Chain Monte Carlo simulation to accurately capture that. Too much effort for too little improvement in modeling accuracy. Also, if the mean is shifting, then it's just equivalent to the ship rotating, so the shots are more or less still seeing the same number of armor cells, just that where they're located physically on the ship is different. So I don't think moving the mean is worth doing here. Easier to just capture all that in the variance.

[intrinsic_parity]

Too much effort for too little improvement in modeling accuracy. Also, if the mean is shifting, then it's just equivalent to the ship rotating, so the shots are more or less still seeing the same number of armor cells, just that where they're located physically on the ship is different. So I don't think moving the mean is worth doing here. Easier to just capture all that in the variance.

To clarify, I was thinking of shifting the mean as being more akin to the ships translating, and the distribution of shots and locations of armor cells as being represented in a tangent plane to the target ship rather than over angles. Personally, I think that makes it easier to visualize translations and rotation of both ships, as well as missed shots all in the same 1D space. But it's not that important (although it might help to interpret what I was trying to say).

The effect of increasing variance is that damage gets spread out over all the visible armor cells and total damage slowly decreases as variance increases and more shots miss. The effect of shifting the mean (which is what happens when your point of aim is off-center due to movement) is that the damage gets shifted to one side of the ship, and total damage suddenly decreases as the center of the distribution moves off of the ship. Those are going to result in very different distributions of damage. The results of your simulation (how armor cells are damaged, how long that takes etc.) will not look like real combat, even if you tune your variance so that the overall TTK is similar. The tuned variance will also only be useful for whatever case you tuned it, and it will not be accurate in other cases.

I would much rather see actual analysis of how specific movements affect accuracy. Stuff like 'weapon A becomes x% less effective against enemies moving over y speed due to missing' rather than 'weapon A did x% less damage than theoretical max on average against a certain fleet'. To me, that is just much more informative for making decision about how to outfit ships against certain opponents, and how to manage firing weapons and target selection IMO.

[intrinsic_parity]

I'm also pretty sure the distribution being sampled from in the actual game when generating shots is not a normal distribution, since I'm pretty sure the error angle for each shot is bounded (while normal distributions are unbounded by definition). I would guess a uniform distribution. That would actually have a non-trivial impact on the probability of hitting a particular cell, and how much damage gets spread out.

[CapnHector]

But if the shot angle has a uniform distribution, then isn't the mean shot angle over several shots a Bates distribution, and so approximately a normal distribution?

Unfortunately some work has come up taking time from more important things like modeling optimal Conquests or building my kingdom on conquered Eventide. It doesn't seem that hard to model this though as you can essentially just pool the armor back up between shots, thinking about it. Or even better,just build a function that selects the appropriate width distribution and uses it for the cell by cell operation. Still need to prove cell by cell = pooled.

Very interesting find on the cells by Vanshilar.

[intrinsic_parity]

But if the shot angle has a uniform distribution, then isn't the mean shot angle over several shots a Bates distribution, and so approximately a normal distribution?

I thiiiink that would be the distribution of the mean value of all the shots, rather than the distribution of the shots themselves. So one sample from a bates distribution would correspond to the mean of n shots sampled from a uniform distribution. But don't quote me on that. I am very sure that sampling repeatedly from a uniform distribution will yield different results than repeatedly sampling from a normal distribution.

It doesn't seem that hard to model this though as you can essentially just pool the armor back up between shots, thinking about it. Or even better,just build a function that selects the appropriate width distribution and uses it for the cell by cell operation. Still need to prove cell by cell = pooled.

For the expected damage of one shot, there is no issue with doing things cell by cell.

The problem comes when you want to get the expected value of the total damage of a sequence of shots. It's not obvious (and I think not true) that taking the expected damage of the previous shot (and resulting armor value) as the starting point to calculate the expected damage of the next shot and then adding them is equivalent to the expected damage of the sequence of two shots.

[Fotsvamp]

This thread has derailed quite a bit, maybe split off a thread for stats analysis rather than Conquest appreciation?

[CapnHector]

This thread has derailed quite a bit, maybe split off a thread for stats analysis rather than Conquest appreciation?

To be fair the ultimate goal of all the math is to find the optimal Conquest. But how about a new thread rule: everyone who posts about statistics must also say something about the Conquest.

I just took out all the [SUPER REDACTED] guardians in the Sector again with a fleet of nothing but Conquests with 2x Squall 2x Gauss 2x Harpoon 2x HAC (playership has 2x Storm Needler instead, but I'm having trouble making it work). Total losses from both fights, 3 Conquests. Conquest is a true powerhouse. I think the important thing is to abuse the missiles and install Hardened Shields and the other appropriate hull mods.

Thing is, I think installing Resonators and Rift Torpedos actually made the ships possibly worse than just the below layout.

This build crushes just about everything in the game when deployed en masse, no other ships needed:


For officer skills I think you want Helmsmanship, Target Analysis, Ballistic Mastery, Field Modulation, Missile Specialization and Gunnery Implants, that's what I'm going for on every officer at least, with Steady personality (Aggressive gets the ships killed). Elites on #1, #3, #4 and #5. If only 1 elite skill then Missile Spec.