Posts made by clyf
Okay that's fair. I don't think we can sleep on alpha strike + range increase given how much AA tends to shoot at fast moving aircraft that tend to get away + quickly have an opportunity to repair.
But let me take a step back, move the goalposts, and say that if the role of a unit is being changed significantly, I'd like to see the numbers worked out from first(ish) principles (say, based on the unit they're targeting) instead of suspiciously round percentages. Whenever I see +50%/+100% etc. I get the vibe there's not a ton of analysis going on behind the scenes.
So first we need to define what role SAMs play now (in relation to flak and interceptors/ASF, which both have strong identities), and what role we'd like them to play. From the OP, looks like FunkOff's suggestion is long-range, heavy hitting, and (implicitly) aerial denial. That appeals to me on multiple levels, establishes a unique identity for the unit, interesting interactions with jamming, etc. etc.
Increasing the range also A. allows SAM health to be decreased without compromising their usefulness and B. opens the door for them to rely on radar more, which makes radar more relevant as a tactical target.
Later, after we get runaway balance issues/sprinkle some salvia in our coffee we can talk about anti-missile defense (lasers, flares) for big, slow air units we don't want to get absolutely trashed by the changes. Or radar adjacency effects. Sky's the limit.
I think a better alternative to a hard minimum range would be altering the missile guidance so they tend to miss more at close range against moving targets.
I like the idea of sams as heavy aa, but my power creep sense is tingling with the increase in damage because it increases the odds of an increase to t3 air health down the road. I think balancing it within the existing state would be better, the numbers for air just feel so wonky in comparison to anything else in the game*.
*Especially in how many secondary AA weapons (on ships etc., not cruisers) are underpowered to the point of being eye candy.
Queue isn't displaying properly when selected with the control group. It isn't two entities, giving a build order to the control group selected variant still adds to the queue as expected.
Much smaller: https://totalannihilation.fandom.com/wiki/Vulcan
Could be some room (mod-wise) for tactical t3 artillery that doesn't take up a city block, though I can already hear the Fatboy whinnying in fear.
You need OnLayerChange
and EnableShield
/DisableShield
in Unit.lua
for when a unit is moving into/out of water. You'll also need to modify EnableShield
to prevent them from being turned on when in the water.
Something as specific as a micro-guide on the state of ASF vs. ASF combat would be a valuable addition to the wiki.
I believe there's also a limit (for performance) on the amount of pathfinding that can be done any given tick. Completely speculative, but if you're spawning hundreds of units at once and giving them all simultaneous move orders the CanPathTo function might be timing out. If you haven't already, try cycling through the units that fail the check one at a time and doing it again.
ziggity:
https://github.com/FAForever/fa/pull/5653
None of that BuffBlueprint bs (that probably won't work, as Jip surmised), but we can bypass the problem entirely by simply telling the transports to unload when they're very close (1-2 ogrids), as opposed to the extremely close currently asked for by the engine (<1 ogrid).
With a little flexibility ("little" as in, a rounding error compared to that introduced by a group unload order) in the dropoff point, we're free to adjust the flight performance parameters to whatever we like. See the Courier in the above PR.
Thought this (markers showing up off map) was a bug tbh.
It's on my list, and very near and dear to my heart. Some very general updates:
- I've become intimately familiar with the OnMotionEventChange functions during some recent work on the Fire Beetle, so I'm confident the front piece--reliably and tidily detecting (read as: without a forked thread) when the transport is landing/picking up/taking up--is possible.
- The end bit (a working flight profile) has always been possible.
- That leaves the middle bit, actually modifying the transports themselves on an individual basis.
Just for kicks, the behavior I'm trying to emulate:
(Ignore the engine failure part, engine failure and descending as fast as possible have a lot in common!)
Hipshot--do you have no-rush enabled, and is a no-rush area not established in your custom map?
I haven't gotten the melee functions to work yet, so their nature is occluded from me. The concept seems a little hacky though, have to see how they look if I do ever get them working.
I added a SetSpeedThroughGoal
adjustment to the Beetle PR, and it improved tailchase performance by another major step (also had no idea about navigators
and what they did, some interesting possibilities there).
Current issues:
- Performance against experimentals with large hitboxes is bad, because weapon targeting is generally evaluated to the center of the target. This is an issue with the stock beetle.
- No improvement for non-attack attacks (guard, patrol).
Adding another dummy weapon with a range significantly larger (~`10) than the current AOE (6.5) could help. Right now the main kamikaze weapon doesn't have a target until immediately prior to detonating, so it's no help with fudging our detonate radius. A dummy longer range detector could address that, both with large hitboxes and for letting the unit know if it has a target or is just on patrol.
Yeah that's a good spot.
What we're bumping up against is the stutter step effectively reduces the average speed of the beetle to somewhere around 4* (I tested it against the flare and speed 4 sera hovertank, it'll catch em eventually, but too long for any practical purposes).
We can artificially reduce the effect of that by bumping the acceleration multiplier up to ~20 (only when we're chasing, and set it back to normal as soon as we're not) which doesn't look bad and addresses the problem somewhat. But other than that I think we're out of luck.
*Actually, the average speed gets lower as target speed and distance decreases, because the beetle starts stuttering more and more.
To elaborate further on what Nex said about pathfinding, the specific issue is that the meta "location to move into range" check is performed every couple of seconds or so. That's fine for units with longer ranges, but means short ranged units get tunnel vision and often need to re-check when they get to their "in range" position (potentially nodded to by the existence of the ominously named Unit:MeleeWarpAdjacentToTarget
).
See here for the pr Nex mentioned.
There's a couple of aspects in play in the above (which to be clear is not integrated):
- In the blueprint, setting
MaxRadius
(the distance to the target at which the beetle will explode) to a low number means the beetle will get closer to the target before firing, and presumably have a better chance of damaging other nearby enemies. - Likewise in the bp, setting the distance at which the beetle tracks the target to be equal to
DamageRadius
(via math,MaxRadius * TrackingRadius = DamageRadius
) allows beetles to move closer to an automatically acquired target before exploding, instead of exploding immediately when the first enemy enters the tracking radius. - In the script, there's a bit of logic that prevents beetles in motion from exploding when a unit that hasn't been deliberately targeted comes into range (this was the original feature request).
- Finally, in testing I also found that decreasing
MaxRadius
made beetles perform poorly when chasing moving units, doing the endless stop/start that I'm sure you're familiar with. The script adds a "tail chase" check that will artificially boostsMaxRadius
to be equal toDamageRadius
after one stop and start, which allows the beetle (speed 5) to catch anything slower than speed ~4.
@Nex, based on the above, the beetle should stutter step once, then explode on the next stopping event. Do you have a video of it continuing to chase with the tailchase script?
(Doing another thought pass on it now, the whole tailchase check may not be necessary, because against a stationary target the beetle won't start slowing down until it's close anyway.)
(Edit: it is, for some reason OnMotionHorzEventChange
is called almost immediately after a target comes into range, so the stutter step is required)
Allowing the arc to be adjusted with a toggle would allow t2 arty behind hills to shoot at ships while being protected from them.
Didn't even know that your team winning the game after you were killed counted as a win for you.