Aircraft have limited ammo and need to rearm at air staging.

(I'd adjust costs as well but that's against the rules)

Short Form: When a structure and its wreck are destroyed in one shot ("gibbed"), create some secondary wreck fragments that add up to a percentage of the original wreck mass.

1. Some Sort of Ethos

I believe in nicely written software and innovative solutions that fit cleanly within existing systems. I like the idea of pushing as much decision-making bandwidth up to the macro scale as possible, but appreciate the micro dynamics that make the game interesting on a small scale. I play whatever games I can get. My rating sucks.

2. Identify a Problem

TML destruction of wrecks in one shot is consistently mentioned as an issue with TML balance.

3. Showcase the Problem

Think this one speaks for itself. I haven't put together a tech demo, but would be happy to do so if there's any interest.

4. Find a Solution

On simultaneous destruction of a unit and its wreck (something to do with overkillRatio--haven't worked out the details but am confident it's implemented in the lua), cast a small number of scrap metal props into the surround on a ballistic arc.

5. Justify the Solution

Debris flying through the air looks cool, and provides a video-game-familiar explanation for what happened to all that mass you had invested in that t2 extractor. Aside from providing a little flavor and a visual explanation to the player, the balance side is easily tunable.

You'll be fine. First, a little background.

1. A Little Background

Everything bolded is basic control theory terminology.

Think of the controller as a little computer, within which the distance between the current location of the aircraft and the target or desired location is referred to as error. For each term (P, I, or D) in a controller--be it a proportional (P), proportional-derivative (PD), or proportional-derivative-integral (PID) controller--the error, integral of the error, or derivative of the error is multiplied by a gain constant. The sum of the product of each of those modifications is then given as the output of the controller, translating into the force we want the thrusters of the aircraft to apply[0]. In a discrete system (like we have in a video game with sim beats, instead of the real world which is effectively continuous), that thrust is applied over the time of simulation step, or time step[1] (0.1 seconds, in our case), accelerating the aircraft on the desired trajectory towards the target location.

[0] This max force/thrust is capped at the maximum force that can be applied by the motor or thruster (think of a small electric motor--you can ask for a lot, but it will only give you as much as it will give, or light on fire, potentially). Max thrust may be a blueprint value, I don't have it in front of me. If it is, increasing maximum thrust will raise the ceiling of system performance.

[1] This may not be completely accurate in regards to the precise internals of the sim, but it's close enough for our purposes.

2. A Quick Calculus Refresher:

i. The derivative of the error is the rate of change of the error. This will be negative if we're moving towards our desired location (the error is becoming smaller and smaller with each sim step--the greater the rate it's becoming smaller, the greater the force it will ask for in the opposite direction) and positive if we're moving away from it, so increasing the derivative gain constant will reduce our tendency to overshoot the target while increasing the total time, or rise time, it takes us to reach the target (or reach the target for the first time, if we're oscillating around it).

ii. The integral of the error is the sum of all errors in each beat, from the start of the system to the present moment. If we're sitting across the room from each other not moving, the integral of the error between us will increase continuously (in a continuous system) by that amount each second, or by error*delta_t each sim beat, where delta_t is (again, in the case of FAF) 0.1 seconds. Introducing an integral term into the controller (which, as long as the aircraft has not reached its target, will ask for continuously more force from the motor or thruster) will compensate for steady-state error, or error introduced by steady state forces like gravity (in the case of an aircraft trying to maintain a given altitude). We're in a made up video game world, so we generally don't have to worry about steady state error. For this reason an integral term is not included in the controller in question (no "KLiftIntegral"), and we'll pay it no further heed.

3. What You Came For, Or the Brass Tacks

Adjusting the gain constants of a controller to produce the desired behavior is known as tuning the controller. There are analytical methods for tuning a system; they require knowledge of its internals (mass of the aircraft, drag, max thrust, etc.) and a certain baseline theoretical background. Given that calculus was the end of the line a long time ago, you're going to be tuning by hand (read as: trial and error). A basic tuning by hand heuristic is:

First the integral and derivative gains are set to zero. Increase the proportional gain until you observe oscillation in the output. Your proportional gain should then be set to roughly half this value. After the proportional gain is set, increase the integral gain until any offset is corrected for on a time scale appropriate for your system. If you increase this gain too much, you will observe significant overshoot of the SP value and instability in the circuit. Once the integral gain is set, the derivative gain can then be increased. Derivative gain will reduce overshoot and damp the system quickly to the SP value. If you increase the derivative gain too much, you will see large overshoot (due to the circuit being too slow to respond). By playing with the gain settings, you can maximize the performance of your PID circuit, resulting in a circuit that quickly responds to changes in the system and effectively damps out oscillation about the SP value.

(SP refers to set point--target position, in your case. Remember, you can ignore the parts that mention an integral.)

Increasing bp.maxThrust[3] or decreasing bp.aircraftMass (which are proportional in their effect on the system as seen in Force = Mass * Acceleration, if they exist) will generally increase the possible performance of the system (read as: shorten the time it takes for the transport to settle on the desired location). Note that modifying either of those parameters will require retuning the gain constants.

[3] Assuming there's a bp.maxSpeed, you should be able to do this without throwing transport speed balance out of whack.

*EDIT:

Looking at the base air unit blueprint, there does not appear to be a MaxThrust (but there is a MaxAirspeed). I suspect increasing the gain constants will change flight characteristics without bound, as you discovered when you sent the little guy flying off the map.

You could look into dynamically adjusting the flight parameters via script when moving to pickup or dropoff to get the behavior you want. It's an intriguing enough idea that I might look into it myself if I get a minute.

@arma473 said in Suggestion: remove "t2 to t3 mex rebuild" game mechanics maybe?:

It just comes down to this: do we want to give people the option to do a little song and dance, to trade APM in exchange for about 600 extra mass?

This is the key question and all other considerations--faction diversity, time-to-wreck, consistency, that destroying something to rebuild it saves resources (??!?) doesn't make any sense at all--are secondary. And the least interesting part of decisionproblem.com is at the very beginning, when you're clicking a button to make more paperclips.

@ftxcommando said in Suggestion: remove "t2 to t3 mex rebuild" game mechanics maybe?:

The "counterintuitive" aspect is adding a weird rule to t3 mex upgrades.

The numbers aren't the last word on consistency, player behavior is. It doesn't pay to ctrl-k t1 mexes, shields, and radars, why should it for t2 mexes?

Everyone has seen the most recent APM graph. 80 APM is never just sitting around. Every click spent executing a construction algorithm by hand is taken away from a more interesting decision, for any player at any level.

Welcome to hell: https://electronicscoach.com/proportional-derivative-controller.html

(not really, but buckle up rooster)

Those parameters are inputs for the aforementioned proportional derivative controller, an instance of which controls the motion of each aircraft.

A straight proportional controller would produce oscillatory motion around the target point that the aircraft is moving to. The introduction of a derivative (damping) term reduces oscillation while increasing the time to reach ("rise time") the target.

You can see about tuning PD controllers by hand here (ignore the integral Ki term, not relevant here), where Kp ~ KLift and Kd ~ KLiftDamping: https://www.ctrlaltftc.com/the-pid-controller/tuning-methods-of-a-pid-controller

Before any follow up questions, what's your level of math education?

That interpretation should have some discussion attached to it instead of being implemented unilaterally. Melanol makes good points.

1. Tone criticisms from people who tend to be thin on common courtesy is a little incongruous. We can all seek to be more respectful, all the time.

2. The job of the balance team for any game is never easy; for FaF, when it's a team of volunteers without corporate authority, the job is all that much harder. When things tend to devolve into a shitfight (see #1) it's harder still. I like to keep all that in mind before I do a mindread on anyone's motives.

3. @Evildrew I'll speak for myself and say that I am genuinely interested in your methodology for how you arrived at these changes.

4. There's always virtue to experimentation, even if there's likely a few too many changes here to approach methodically. Most interesting things start out as a compost heap (and I gotta take a look at these mobile factories).

Also, because it's on the table--when something is added to the base release (spread attack), if it's bad there's a pretty good chance it won't stick around. A feature in the base game is tested constantly by the entire player base, people get experience with it, and feedback is forthcoming.

When something is removed from the game, getting it back in requires:

1. Reimplementing it
2. Distributing it
3. Getting enough people to play it to actually form an opinion
4. Marshalling enough support from #3 to get it re-added to the release

After the axe falls here, someone interested in getting "deceivers cloak carriers" back in the game will need to do #1, #2, and #3 all by their lonesome (I can see the very respectful forum posts now, something along the lines of "it was taken out for a reason, idiot") while a feature newly added to the game--like the new spread attack--gets that administrative overhead for free.

Finally, removing something because "it's practically never used" is a bad metric. Something that isn't used remains in the solution space, with the possibility to find use when A. a future adjacent change is made or B. some new interaction or pattern is discovered to be effective. I'll speak for myself and say that I like it when unusual stuff happens. Locking doors for no reason other than people aren't using them moves the game away from that.

@heybabe

It's not necessary to loop through all the preceding levels. The extra pair of { } is declaring an integer indexed array which you can access the elements of with SomeArray[1].

See the lua docs on tables, specifically:
"A common mistake for beginners is to confuse a.x with a[x]. The first form represents a["x"], that is, a table indexed by the string 'x'. The second form is a table indexed by the value of the variable x. ... To represent a conventional array, you simply use a table with integer keys."

In this case, "Weapon" and "Tarmac" in the blueprint (which could be more intuitively named "Weapons" and "Tarmacs") are convential arrays, indexed by integers. containing a subtable of the data for each weapon/tarmac on the unit. When you declare a table of tables in lua without specifying a key for each, lua automatically integer indexes them.

Take this hypothetical table declaring two weapons:

UnitBlueprint = {
    Weapon = {
        {
            Damage = 10
            Range = 5
        }
        {
            Damage = 1
            Range = 2
        }
}

Because the Weapon table is declared with a non-integer key ("Weapon"), you can access it with UnitBlueprint.Weapon, as shown in the lua docs. But what happens if you try to access UnitBlueprint.Weapon.Damage? There's two values for damage in there, each declared without a key, in which case lua has secretly done something like this (the following code is wrong, used just as an example to demonstrate the integer indexing, do not try to replicate it) :

UnitBlueprint = {
    Weapon = {
        1 = {
            Damage = 10
            Range = 5
        }
        2 = {
            Damage = 1
            Range = 2
        }
}

In which case (depending on how familiar you are with typical methods of accessing array elements from Python et al) you may intuit that you can grab the first weapon with UnitBlueprint.Weapon[1]. See the lua docs again for why you can access an integer indexed array with SomeArray[1] but not SomeArray.1.

The reason why your loop solution works is because the loop is iterating through the subtables, even though in this case there is only one subtable, which is where I think your confusion arose. Think of Weapon and Tarmac as lists of an arbitrary length (the extra set of "{ }" surrounding them as the giveaway), the elements of which need to be accessed with integer indexes, and I think the solution will become clear to you.

@blackyps

Whether the patch missed some edge case or another/is itself bugged has zero bearing on the justification for implementing it in the first place (and it didn't, as far as I can see the patch linked by SpikeyNoob disables all intel in carriers).

My point was that much hay was made about intel within carriers (IWC) being a glitch that's related to transports within transports (TWT). @Black_Wriggler made a comment--"load a spy plane into a carrier and it has omni"--and I got curious if it held true for all intel, for all units in cargo, regardless of if they're attached to another transport, land, air, whatever. And it does! IWC works regardless of the presence of TWT.

Given that half of the stated reason for removing IWC was glitchiness due to the engine's inability to handle TWT, that there is in fact no relationship between the two would suggest a reassessment of that reasoning is appropriate.

Based on how the conversation has gone so far, I suspect we'll ditch the glitch justification and settle for the local minimum of "it's purely a balance issue" instead. As stated, these are not good signs.

What follows is written with limited knowledge of the internal workings of the balance team and whatever practices they've adopted.

This is a broad topic, so I'll keep it short--I think it would be useful to identity and define more baseline terms and concepts that can be used when discussing the strengths/weaknesses/balancing of a given unit or faction.

Consider DPS: it's a derived quality, not rigorously defined, but is a useful construct when we talk about general effectiveness.

How can we identify more useful concepts like DPS? Consider the blog on MtG R&D lingo here, and the definition for "Knob", reworked for FaF:

"Knobs – These are elements of a [unit], usually involving numbers (things like [mass cost] or [damage]), that give the [balance team] the ability to adjust a [unit] for balance purposes. The more knobs, the better for play design."

I think that's a useful concept, not only for first-line balance discussion, but also in how it makes "have all the relevant knobs and their interactions been recognized when a suggestion is made?" a straightforward method for assessing how much thought has been put into a given balance suggestion.

"Knob" is one possibility. DPS as a distribution instead of a single number is another. I'd like to hear more!

Sounds like fullshare is the priority then, in which case survivability is secondary.

Primary telemazor balance knobs are therefore:

• range
• upgrade cost
• teleport cost
• mazor attributes

Secondary knobs:

• teleport time

Was there much exploration of changing teleporter balance on a per faction basis (cost, range, etc.), not just in regard to synergistic upgrades?
 
@relentless, @FtXCommando
For a variable cost, you could have the number popup next to the cursor. Looks cool, very intuitive, technically easy.

I'm just gonna throw out some knobs for teleport changes that don't involve reducing the range/can be applied on a per faction basis:

1. Add ammo, requiring a rebuild of the component after it's been expended
2. Only allow teleportation to/from Quantum gate* (so QG -> field, or field -> QG). Alternatively, give quantum gate teleports unlimited range, but add a range restriction for backpacks.

*You have the flexibility here to increase the time required for gate teleports, widening the window for scouting while allowing the return time to be balanced independently.

What percentage of games are fullshare, and what's the priority in balancing this particular mechanic around them? Squaring that circle is going to be tough, akin to adding or removing a unit from Cybran based on victory condition.

@indexlibrorum

That's a funny way of saying

Let's not choose violence. His suggestion that a lighter color be used made it unambiguous in the way he intended. An assumption was made in the replies that everybody else wrongly got on board with.

@nflanders

Free as in speech, not beer.

@femtozetta

this is just laziness on account of the people complaining

We can recognize that this is true while recognizing that A. it's never going to change or B. complaining about it in turn does nothing to materially solve the problem.

@BlackYps

Why is the popup in the game not enough?

We can speculate on the flow of entering a lobby--you want to get in there, you want to make sure you're not in an observer slot, you want to pick your color, whatever--but a more robust way of looking at it is that, when a player is going through the steps to get into a game, anything that interrupts that pipeline is going to get rapidly clicked through.

So even an intrusive popup in the play tab wouldn't be that effective! But a notification, that the player can address at any time (but is not required to address at any specific time), takes the player out of the "getting in the game" pipeline and into an "evaluating notification" one. Is the notification to make people update the client not effective?

Main issue is that we shouldn't confuse saying "people are lazy and don't read the patch notes" with anything that materially addresses the problem.

Include a popup on the play tab. The cold, hard reality is that most of the time there isn't new and useful information on the news tab, so people are trained to click by it without looking. People go the play tab. If you want important information to be seen, you need to put it there.

What about sending a notification in the client (like, the little bell that shows up) whenever a commonly used feature is changed? Issue with putting anything on the news tab/another tab is that people will continue to click through it automatically.

Is the suggestion to form the game around playing Astro Crater with one hand?

@jip

As an intermediate thought, what about a button to select the child factory (like pod platforms have)? Would that solve (what I assume) is the problem with the Czar/Tempest, where there's not a good place to put the factory at the "back" of the unit?