The present package is a system for dynamically adjusting the time and energy cost of teleportation with respect to distance.

1. Energy cost scales quadratically* according to teleport_dist^2.
2. Time required scales logarithmically according to log(teleport_distance), with a minimum time equal to UnitBlueprint.TeleportDelay.
3. The above two values are displayed in a reticle adjacent to the teleportation cursor. When multiple teleporting units are selected, the energy displayed will be equal to the sum of the individual costs of all units. The displayed time will be the individual maximum among the selected units.

Technical implementation includes the externalization of the teleport cost function to lua/shared, allowing access by the sim and the ui, and a reticle class in controls/worldview.lua with an eye towards future applications.

Github here, mod version in attached zip file.

Alternatively, copy and paste this into your Game.prefs file, under UserKeyActions, and play the game however you like!

['Select nearest idle land scout'] = {
    order = 40,
    action = 'UI_SelectByCategory +nearest +idle LAND INTELLIGENCE',
    category = 'selection'
},

More info on making new hotkeys here.

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

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

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!)

Just out of curiosity I went a lookin:

Call of Duty: Every six months (you get a new name change token every six months)

Starcraft II: One free change every season (~3 months)

Fortnite (lol): Every two weeks

League of Legends: "You wanna see the cards you gotta pay the money" ($10)

Warthunder: First is free, all after $2.49.

AOE2: Connected to steam/xbox username (steam you can change as much as you want, xbox first time free/second time fee--also what masochist is playing aeo2 on the xbox)

Rocket League: Platform name (steam/epic/etc.)

Valorant: Free every three months, looks like LOL is going in this direction as well.

Blizzard games: One for free, more for fee

EVE Online: You will be who you are forever

UI minimod that shows a visual warning when an enemy launches a strategic missile, including a warning for multiple inbound missiles.

Color and warning text can be modified in nukelaunchping.lua in the mod hooks/lua/ui/game folder.

Find on the mod database under "Strategic Launch Text Notification".

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?

Variable teleport costs demo here.

I'll get onboard with hanging up my balance-discussion cleats (my rating is 400 git.at.me) if the message given to low-rated players when they try to contribute is "snowy801 decided your rating was too low for you to have an original, nuanced, and relevant opinion".

Seriously: It's a bad idea. There's like four people who are consistently clogging up the balance discussion channel with bad takes. Warn/ban those people and moderate the channel if you want it to improve.

@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.

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).

That is not the correct interpretation.

https://www.collinsdictionary.com/us/dictionary/english/bring-forward

@redx

A good majority of the "front page" of balance suggestions is low/no effort posts by people who've explicitly said they have nothing better to do. It's low hanging fruit. Even just trimming the bad topics would help immensely. Adding "downvotes"/hiding downvoted posts would as well (not sure how that would be implemented technically).

@Blodir

For me personally the biggest hindrance in reading balance posts is the argumentation.

I think the only solution here is to be the change you wish to see in the world. Contribute thoughtfully, stay on topic, ask other people to do the same/be respectful, and summarize the framing/points of agreement/disagreement whenever appropriate.

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.

I've been experimenting with using blueprint buffs to modify the flight characteristics of transports based on whether they're dropping off/picking up/flying etc. If there's a reliable fix to be made, I think it's there.

(Hadn't occurred to me before, but the same technique could also address the leisurely pace with which aircraft enter carriers)

"Use the little wrench in the corner of the chat window to make "To Allies" the default setting."

I can't believe it took me until today to figure that one out.

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