Forged Alliance Forever

Re: Supcom FA eco

2012-05-20T19:35:16+02:00

I don't have the specific knowledge of some of them required to fully analyse them.
The upgrade costs and theories are correct.

However, it is never wise to set out to do a strategy no matter what. It'll always end in tears.

Statistics: Posted by Gowerly — 20 May 2012, 19:35

Re: Supcom FA eco

2012-05-20T18:24:38+02:00

Well I thought I had restrained myself enough to avoid that, guess my efforts were not enough. I will try harder.

How is that :

Root you're wrong. The way you do it is very bad. You let your team down most of the time cause they have to handle a 3v4 for like 20mins. And when the teams are well balance this is auto loss usually. You did this to our team like 2 days ago again.

Less sim city, more support. These are not NR20 games.

Hugs and kisses. Take care.

I hope this time it's nice enough.

Theories don't necessarily need to translate into practice. Talking numbers is fine, it's up to the individual players to do the right things with them.

Numbers, agreed. numbers are numbers. But there are some "disturbing" """""theories"""""" in that post.

Statistics: Posted by -_V_- — 20 May 2012, 18:24

Re: Supcom FA eco

2012-05-20T15:03:14+02:00

Deleted some flaming on this thread.
Those involved: Do it again and you're gone.

Theories don't necessarily need to translate into practice. Talking numbers is fine, it's up to the individual players to do the right things with them.

Statistics: Posted by Gowerly — 20 May 2012, 15:03

Re: Supcom FA eco

2012-05-20T04:07:21+02:00

While we are at it, there is another experiment that i regularly practiced on opponents in the air spot of setons clutch,
who i suspect will play mostly defensively. since it fits the general theme of this thread i'd like to share:
The strategy here is to spam t3 mex and t3 pgens before making any significant amounts of ASF (vulgo: eco-whoring).
The most important results of this experiment:
8 t1 factories in the reclaim phase spamming engis.
2*RAS at ca 11:30, 3 T3 mex at 13:30, then upgrade T3 air fac. with the t3 engi + 30-40 t1 engis spam T3 power.
from 12:00 onwards: +8 t1 factories spamming engis.

so at 13:30 the mass income is 210, a 4600 mass t3 upgrade takes 20 seconds, 10 mex left to upgrade.
of course you spam some ASF, because you do not want to be seen as being eco-whoring and pgens cost mass too. All that results in all 13 mex T3 at 18:00. Meanwhile about 40 ASF have been built and maybe 35k E/s. All the time piles of t1 engis are eagerly waiting around factories to be put to work. You need 600 engis on 3 factories to use up 389m/s.
With that strategy you will have more ASF at 20 or 21 minutes if you play against an opponent who uses an average
macro-strategy. Its also interesting to note that a back spot eco-whore will be behind on score, because the score boils
down to
(mass_spent + energy spent * 20[i think]) / 2 + [second half of the score depends on units killed+units lost]

Since upgrading mex has a mass/energy ratio of 1:7, building t3 power of 1:10 and ASF of 1:100, you will be behind,
regardless of the fact that you spend more mass. At 18:00 what you see is that the eco whore, after starting to produce
asf with ca 600 engis gains score rapidly, like +2000 more per update of the score screen, compared to the standard
build order using opponent. That has the nice effect of making the opponent think he is ahead overall until it is too late.
The obvious downside is an attacking opponent before minute 16-18. If he just wipes out your ASF, thats not a problem,
because you will have 40-50 new ones per minute. But strat bombers are obviously a problem. Or an ally that chooses
to rely on torpedo bombers and ragequits because of your incompetence to defend. But the strategy is far from reckless:
If the enemy circles your base with his 50-80 ASF, you scare them away with SAMs and start spamming with 500 engis, then
survive another minute and take the lead on the plane count. Loosing an ASF battle has no lasting consequence.

But usually it is: 21st minute: no ASF micro skills needed, 23rd minute: bomber time, gg.

Hope the numbers were of interest to some. As a rule of thumb, being behind and in danger from 12:00 onwards pays back 5-6 minutes later. then you will be mostly safe. another 2 minutes later you will be ahead (inevitably).

ps. The T1 engi spam stops at around 19:00-20:00, around which point the income is 389m/s and (correspondingly) 40k e/s.
i.e. its usually not perfectly aligned to the mex upgrading. leaves time to build a nuke defence.

Statistics: Posted by rootbeer23 — 20 May 2012, 04:07

Re: Supcom FA eco

2012-05-20T01:50:19+02:00

Rasmuffin wrote:
rootbeer23 wrote:810[m] - 9[m/s] * 2875[Buildtime in s] / 70[buildpower in b/s] = 440m

Not to be too much of a stickler but your units are out of place:

the correct formula is indeed:
810[m] - 9[m/s] * 2875[buildtime b] / 70[b/s] = 440m

Rasmuffin wrote:
but I am going to throw in the R coefficient to get back to the opportunity cost of engineers reclaiming.

Change in Mass = Change in time * (4m/s - R*AE)

the R * AE must not be related with 4m/s, because that mass rate refers to the timespan from when the upgrade
is finished until 90 seconds after the upgrade started. In that time the engis are available to reclaim.

as an example:
mass_gained = (90[sec] - 900[mass] / (10[m/s] + 5[m/s] * AE)) * 4[m/s]

for 5 engis assisting:
mass_gained = (90 - 900 / (10 + 5 * 5)) * 4 == (90 - 25) * 4 == 256m
reclaim_lost = 5 * 1 * 25 == 125m
total = 256 - 125 == 131m
for 10 engis:
(90 - 900 / (10 + 10 * 5)) * 4 == (90 - 15) == 300m
reclaim_lost = 10 * 1 * 15 == 150
total = 300 - 150 == 150m
2 engis assisting:
mass_gained = (90 - 45) * 4 == 180m
reclaim_lost = 2 * 1 * 45 == 90m
total = 180 - 90 = 90m

an engi converting stored mass to mass production indirectly produces 2m/s, independent of the number of engis
involved (mass_gained / AE / upgr_time). plus it does not even use up the trees. it feeds on mass in storage.
the alternative would be to reclaim faster and upgrading many mexes at the same time, i.e. putting mass from one
storage into another storage (which is the upgrading mex). with sequential upgrading using 5 engis you create 250 mass
per mex out of thin air at the cost of the reclaim delayed by 25 seconds per mex. since all you do with 25 seconds time advantage is juggle mass from storage to storage, that is not even much of a loss.
The situation is of course different if your mass income + mass in storage does not allow you to upgrade with N engis,
but then you would want to use as many AE as you can.

btw, i did an experiment once: setons air spot, 13 mex at 9m/s, ie all mex T2capped + 2*RAS == 154m/s.
I needed 300 engis on 1 factory to use up that mass, together with 15000 power.
while in theory 300 engis can use up 200 m/s when producing ASF. so the release of the unit has quite an impact,
together with the time it takes for the engis to light up and start assisting (all were assisting a single engi).
not much to gain here by building a second T3 fac at the cost of 80 engis. (300 - 80) * 0.66 == ca 150

The one fact that i forgot is the number of t1 factories spamming engis, but it was a lot more than a standard build needs, and certainly more than 10, built right from the start of the game, with 2*RAS being done around the 12 minute mark.

Statistics: Posted by rootbeer23 — 20 May 2012, 01:50

Re: Supcom FA eco

2012-05-19T23:55:09+02:00

rootbeer23 wrote:
While we are at it: note that it is more efficient to reclaim the low tech mex and then directly build the high tech mex.
This does not really apply to T1->T2, because the 32 mass reclaim of a t1 mex is so tiny, but for the T2->T3 case it
is practical.

Reclaiming a t2 mex gives 810 mass.
Assuming is was storage capped and produced mass at a rate of 9m/s, if you manage to reclaim and then build a new
T3 mex in less than 90 seconds, you will have gained some mass.
Given the build time of 2875 for the t3 mex, the break even point is reached with
2875 / 5[buildpower per engi] / 90[seconds] = 6.388888889 engis
Because of the mandatory t3 engi required, the mass savings can be substantial. with 1 t3 engi and 10 t1 engis, you save:
810[m] - 9[m/s] * 2875[Buildtime in s] / 70[buildpower in b/s] = 440m

Very good work there it all lines up. May have to start doing this myself, problem is that it is not possible to que something to reclaim and then build directly afterwords, going to have to micro that.

Not to be too much of a stickler but your units are out of place:
Buildtime is not measured in seconds, it is a unit free modifier, but the outcome is still correct.
Seconds/buildpower/seconds = seconds^2 / buildpower when this is multiplied by the 9[m/s] only one of the seconds will cancel. This is nitpicky but I have Figured out what you have done with this formula and feel dumb that I didn't understand it sooner:

mass_gained = (90[sec] - 900[mass] / (10[m/s] + 5[m/s] * AE)) * 4[m/s]

This is more simply put:
Change in Mass = Change in time * Change in income
I would put deltas instead but don't want to go find out how to insert them. This works very well. but I am going to throw in the R coefficient to get back to the opportunity cost of engineers reclaiming.

Change in Mass = Change in time * (4m/s - R*AE)

Lets set R = 0, 1, 0.5, 0.1 for simplicity sake and use rootbeer23's outputted data set to see if we get an engineer amount that maximizes delta mass.
Engy = # of engineers, T = Time, DT = delta time.
The outputs of the R values are in the difference in mass gained by assisting than with the mex upgrading on its own.

Code:: Engy T DT R=0 R=1 R=0.5 R=0.1 1 60 30 120 90 105 117 2 45 45 180 90 135 171 3 36 54 216 54 135 199.8 4 30 60 240 0 120 216 5 25.7 64.3 257.1 -64.3 96.45 225.05 6 22.5 67.5 270 -135 67.5 229.5 7 20 70 280 -210 35 231 8 18 72 288 -288 0 230.4 9 16.4 73.6 294.5 -368 -36.8 228.16 10 15.0 75.0 300 -450 -75 225

Okay fun times. we got some peaks and that means we have an optimization problem. The Important thing to note is that these R values are based on the map, and 1 is on average the reclaim rate of trees on setons. With a rock cluster the R value will go above 1 for that engineer and this clearly shows that the mass gained from that rock cluster should take priority over assisting a mex. This R >1 case is when there are rocks, and they should take priority during the upgrade not just to avoid going negative mass, but it is a better source of income.

For R = 0 value there is nothing to ever diminish the value of adding another engineer so there is no peak point to discuss. What the R= 0.1 value shows us though that even with a very low amount of reclaim available (1 mass every 10 seconds or 6 mass per minute) the most engineers you should have assisting a t1 mex going to t2 is around 7. There is some mass somewhere that is worth more of your time for the 8th engineer. To hammer this realization home it is better to send your 8th t1 engineer on a full minute trip to reclaim a rock worth 6 mass than to have it help 7 other engineers assisting a mex to t2. this is true and we have assumed that this player never goes negative mass, and there is no bumper car shenanigans.

For R = 0.5 the engineers assisting should be between 2 and 3, if it is 0.6 it should be 2, if 0.4 it should be 3. This is the rule that I will be following on setons, 2 engineers per mex while upgrading, the rest will go reclaim. this number will increase as the forest moves farther away, and therefore R gets smaller.

Anyway. Nice formula there Rootbeer23 just took me a bit to figure it out.

Now all we have to do is incorporate:
Engineers as a function of game time and land factories. One land factory existing at 30 seconds into the game from the commander ejecting out one engineer every 13s + (1s reload time). The important information that we should look for is when (for a fully economically efficient build) a second land factory should be built to create engineers. This will depend on what type of unit we are building but the basic principle is:

Mass income = Engineers * assist-rate (0.7m/s for ASFs) + Factory build-rate (8m/s for ASFs)

At this point every ounce of mass is capable of being put into production. The Assist rate can be split into multiple sections, assisting a GC requires 6.7m/s and therefore require less engineers to equal the total mass income. The next graph I want to see is with a fixed 100 mass/second income, how many t1 engineers are required to use it all to build a single unit.

ASFs => 100m/s = 8m/s + 0.66*Engineers (the actual mass/second value is 0.66mass/second, same as the ratio of power, the display rounds it up).
ASFs = 139.4 engineers

Then there is some unload time... but that can be factored in. Anyway I hope the table above is readable and helpful.

Statistics: Posted by Rasmuffin — 19 May 2012, 23:55

Re: Supcom FA eco

2012-05-19T21:26:16+02:00

While we are at it: note that it is more efficient to reclaim the low tech mex and then directly build the high tech mex.
This does not really apply to T1->T2, because the 32 mass reclaim of a t1 mex is so tiny, but for the T2->T3 case it
is practical.

Reclaiming a t2 mex gives 810 mass.
Assuming is was storage capped and produced mass at a rate of 9m/s, if you manage to reclaim and then build a new
T3 mex in less than 90 seconds, you will have gained some mass.
Given the build time of 2875 for the t3 mex, the break even point is reached with
2875 / 5[buildpower per engi] / 90[seconds] = 6.388888889 engis
Because of the mandatory t3 engi required, the mass savings can be substantial. with 1 t3 engi and 10 t1 engis, you save:
810[m] - 9[m/s] * 2875[Buildtime in s] / 70[buildpower in b/s] = 440m

Statistics: Posted by rootbeer23 — 19 May 2012, 21:26

Re: Supcom FA eco

2012-05-19T20:56:05+02:00

Rasmuffin wrote:
This calculation is intended to get the difference in total mass gained from the two paths at a point of 11 minutes past the initial upgrade time. The first group of 5 ends its engineer assisting phase at approximately 5 minutes meaning there is 6 minutes where those engineers are free to reclaim giving 5eng * 1mass/sec * 60s * 6 min = 1800 mass gained from reclaim between finishing the mexes and storage to the 11 minute mark.

the buildtime for 5 engis is: [ b = buildpower ]
T2 mex: 900 / (10 + 5 * 5b) == 26 sec
T1 storage: 250 / 5 / 5b == 10 sec

meaning you need 26 * 2 + 10 * 4, i.e. 2 minutes to build that kind of infrastructure.

Rasmuffin wrote:
rootbeer23 wrote:would it not be simpler to just calculate the mass gained by assisting:
mass_gained = (90[sec] - 900[mass] / (10[m/s] + 5[m/s] * AE)) * 4[m/s]

That equation needs some more explaining. Mass_gained as a function of AE is exactly the kind of formula that we are trying to achieve in this thread but your units do not line up and make any sense here. Try plugging in 0 = AE and you get
(90s-900m / 10m/s) *4m/s = ((90s-900m)*2s)/5 (units get wonky here) 36ss - 360ms = 36s(1s-10m) which means what? what do you input into your equation? AE? what is the output? it should be something related to mass as a function of time. What is the amount of time you are holding fixed? The other Functions you outlined seem to be pretty solid but they all relate back to this equation that is pretty nonsensical.

insert AE == 0 and you have mass_gained = (90 - 900 / 10) * 4 == 0
AE has no dimension. obey operator precedence. multiplication comes before addition.

the limit of mass_gained is 360 with infinite buildpower and 900 mass in storage (90s * 4m/s), here are some other data points
columns are: number of engis, time for mex upgrade, mass_gained

Code:: Engies Time Mass Gained 1 60 120 2 45 180 3 36 216 4 30 240 5 25.7 257.1 6 22.5 270 7 20 280 8 18 288 9 16.4 294.5 10 15 300 11 13.8 304.6 12 12.9 308.6 13 12 312 14 11.3 315 15 10.6 317.6 16 10 320 17 9.5 322.1 18 9 324 19 8.6 325.7 20 8.2 327.3

Edit by Gowerly: Made that more readable for you

Statistics: Posted by rootbeer23 — 19 May 2012, 20:56

Re: Supcom FA eco

2012-05-19T20:03:59+02:00

rootbeer23 wrote:
Rasmuffin wrote:3 engineers at 3mass/second for 11 minutes = 3*60*11 = 1980mass gained by 3 engies over 11 minutes assuming 1mass/second Now there is travel time involved and I believe my original measurements were total mass&energy gained on average from the center of a forest on setons over 2 minutes.

10570 2M, 4s, 5engies
10403 1M, 4s, 1M, 5engies
12191 2M, 4s, 2engies (1980 mass added)
11183 1M, 4s, 1M 2engines (1980 mass added)

Neither 5 nor 3 engis need 11 minutes to upgrade and build 2M 4S

You're absolutely right I am using the wrong time frame for that calculation. 11 minutes came from the endpoint of the graph and not when the upgrade finishes. The Total Mass gained from the "Upgrade Path" is still over a period of 11 minutes, but the faster built mex should have those engineers go back to reclaiming sooner.

This calculation is intended to get the difference in total mass gained from the two paths at a point of 11 minutes past the initial upgrade time. The first group of 5 ends its engineer assisting phase at approximately 5 minutes meaning there is 6 minutes where those engineers are free to reclaim giving 5eng * 1mass/sec * 60s * 6 min = 1800 mass gained from reclaim between finishing the mexes and storage to the 11 minute mark.

12370: 2M, 4s, 5engies ( 1800 mass added)
12203: 1M, 4s, 1M, 5engies( 1800 mass added)

The three engineers are still reclaiming for the entirety of the 11 minutes but after 8 minutes the two engineers finish and add in: 2eng*1m/s * 60s * 3 min = 360m

12551: 2M, 4s, 2engies (360 + 1980 mass added)
11543: 1M, 4s, 1M 2engines (360 + 1980 mass added)

Lets adjust everything down by 11543 mass so we can see delta mass more clearly:

827: 2M, 4s, 5engies ( 1800 mass added)
660: 1M, 4s, 1M, 5engies( 1800 mass added)
1008: 2M, 4s, 2engies (360 + 1980 mass added)
0: 1M, 4s, 1M 2engines (360 + 1980 mass added)

The 11 minute mark is arbitrary and only needs to be longer than the longest upgrade to work out. The mass income rate is a constant after all the upgrades are finished.

This makes it a much closer result and very interpretable that the best route to go along is 2 engineers doing mexes first then storage. The Mass then storage then mass is not as productive by a long shot than any of the other systems.
Thank you for pointing out my mathematical mistake, and it seems the conclusion that the community can draw from this is that we have evidence that:

2 (rather than 5) engineers are more mass efficient to assist upgrading from t1 to t2 if there are suitable reclaims in the area.

5 engineers are more efficient than 2 engineers, even with reclaims in the area, for building storage around t2 mexes.

While some more numbers should be run for 3 engineers assisting, and so forth this is a great model to set up and can be applied much more thoroughly. The main measurement that needs to be calculated is the distance between mexes (initial 4 assumed to be negligible here). The only factor that will change from distance between mexes is time where engineers are not added in as reclaiming.

rootbeer23 wrote:
would it not be simpler to just calculate the mass gained by assisting:
mass_gained = (90[sec] - 900[mass] / (10[m/s] + 5[m/s] * AE)) * 4[m/s]

That equation needs some more explaining. Mass_gained as a function of AE is exactly the kind of formula that we are trying to achieve in this thread but your units do not line up and make any sense here. Try plugging in 0 = AE and you get
(90s-900m / 10m/s) *4m/s = ((90s-900m)*2s)/5 (units get wonky here) 36ss - 360ms = 36s(1s-10m) which means what? what do you input into your equation? AE? what is the output? it should be something related to mass as a function of time. What is the amount of time you are holding fixed? The other Functions you outlined seem to be pretty solid but they all relate back to this equation that is pretty nonsensical.

Statistics: Posted by Rasmuffin — 19 May 2012, 20:03

Re: Supcom FA eco

2012-05-19T16:08:52+02:00

Rasmuffin wrote:
3 engineers at 3mass/second for 11 minutes = 3*60*11 = 1980mass gained by 3 engies over 11 minutes assuming 1mass/second Now there is travel time involved and I believe my original measurements were total mass&energy gained on average from the center of a forest on setons over 2 minutes.

10570 2M, 4s, 5engies
10403 1M, 4s, 1M, 5engies
12191 2M, 4s, 2engies (1980 mass added)
11183 1M, 4s, 1M 2engines (1980 mass added)

Neither 5 nor 3 engis need 11 minutes to upgrade and build 2M 4S

Statistics: Posted by rootbeer23 — 19 May 2012, 16:08

Re: Supcom FA eco

2012-05-19T12:52:42+02:00

Rasmuffin wrote:
OHHH GOODY!!!! so many interested people, I'm so giddy!!!. First, to the post about it should be simple, I think you're right... the Mass deviation statistic used in the Player tracker system took the total mass collected of each player at every minute marker of the game, and printed it at the end without requiring every person to have the mod installed. While this would obviously be cheating if it showed those amounts durring the game i see no harm in printing them after. All that would need to change from FalconTX's programming would be to take a sample every second instead of every minute.

Thats a flaw in the supcom engine, it should only make the score accessible to the UI mod, instead you can get much more
valuable information about your opponent while the game is running.

Rasmuffin wrote:
So Mathematically speaking we have:
TM1 = 2m/s (Mexes)(t) + R(TE)(t)
TM1 = 2m/s(7)(t) + 1(10)(t)
TM2 = 2m/s(7)(t) - 10m/s(t) -5m/s(AE)(t) + 1(10-AE)(t)
TM3 = 2m/s(6)(t) + 6m/s(1)(t) +1(10)(t)

Our Equilibrium point is when TM1 = TM3 + TM2 (time to get investment back) is minimized and the only thing we can change is AE. This has three variables: TM, AE, t, and three equations. As long as i didn't make one linearly dependent on each other (meh Echelon matrix... why do I feel the need to do one......) this should be solvable. (ahh my equilibrium condition counts as an equation, so I have 4 equations, I'm safe here....)

would it not be simpler to just calculate the mass gained by assisting:
mass_gained = (90[sec] - 900[mass] / (10[m/s] + 5[m/s] * AE)) * 4[m/s]
together with the corresponding time for the upgrade:
upgr_time = 900 / (10 + 5 * AE)

and then calculate:
R_needed = mass_gained / upgr_time / AE

with R_needed being the reclaim efficiency per engi in m/s that you have to achieve to make up for the more efficient upgrade.

and then find AE where R_needed - R_real is largest.

EDIT: ok. since R_needed is always 2 independent of AE, that is rather pointless.
(2 - R_real) * AE is what you gain. R_real * AE * travel_time is what you loose.
Assuming R_real is < 2, it really boils down to how long it takes the engis to make the detour.
So (2 - R_real) * AE * upgr_time - R_real * AE * travel_time is what has to be maximized.
Apart from the travel time, an engi assisting an upgrading t1 mex effectively generates 2m/s
for the duration of the upgrade.
/EDIT

If that is not enough, calculate the effect of:
R_real * upgr_time * AE
because the mass which you didnt reclaim with the AE during the upgrade is still there.
And correlate this to the number of tanks you can factory-assist in that time.

Statistics: Posted by rootbeer23 — 19 May 2012, 12:52

Re: Supcom FA eco

2012-05-19T08:17:13+02:00

I knew supcom players were crazy mathematicians. Nice to be in the company of like minded people.

Statistics: Posted by TA4Life — 19 May 2012, 08:17

Re: Supcom FA eco

2012-05-18T22:53:01+02:00

OHHH GOODY!!!! so many interested people, I'm so giddy!!!. First, to the post about it should be simple, I think you're right... the Mass deviation statistic used in the Player tracker system took the total mass collected of each player at every minute marker of the game, and printed it at the end without requiring every person to have the mod installed. While this would obviously be cheating if it showed those amounts durring the game i see no harm in printing them after. All that would need to change from FalconTX's programming would be to take a sample every second instead of every minute.

Second Ze_pilot...... I am going to destroy your graph, and feel no remorse:
First of all you are correct there is a theoretical in which a t2 mex will pay for its self with a 0 upgrade time and this is admiral and one end of our communal graph. The problem is that there is another end of the graph that you should have mentioned and shown on the graph that is with zero assistance the time to pay for the mex to pay for its self.

it is a piecewise function where TM = Total Mass:
TM1 = 2m/s (t)
TM2 = 2m/s(t) - 10m/s(t) - 5m/s (t)(# of t1 engineers)
TM3 = 6m/s(t)

While I don't know the proper designation of piecewise functions this should suffice:
TM1| mex at t1
TM2| until equation: -10m/s(t) -5m/s (t)(# of t1 engineers) = 900
TM3| when TM2 > 800 mass

The measurement of when will these mexes pay for themselves is when TM1 = TM3 because TM2 will have a negative impact in this case... (OMG 2 mantis supporting a mex will negate its impact at -1 each.. net eco impact is -14 power...... i'll get back to this later.....) ANYWAY... back to reality when TM1 = TM3 we have Ze_pil0t's self paying for mex.

so if the # of engineers goes to infinity we get the simple equation of at t = 0 TM1 = TM3 - 900
so TM1 = TM3 -900 => 2m/s(t) = 6m/s(t) - 900
Because remember people, if you didn't get the upgrade you would have been getting the 2m/s and your total would have gone up. This is like giving your buddy $100, and a year later he gives you $100 back, and you're like, interest is satanic so I'm not bothered that it took this long.
-4m/s(t) = -900
t = 225s
this is not what ze_pil0t got, and I'm not just ashamed of him, but of myself, and everyone else in this community that took 267s as a given until I decided to check the validity and made everyone look like fools. <--- please check my number if I messed up I'll be really ashamed....
Second endpoint of the graph mex with no assistance:
TM2 = 2m/s (t) - 10m/s(t) | until -10m/s(t) = 900 mass (i.e. 90 seconds)

TM1 = TM2(90) + TM3(t) => 2m/s (t) = 2 m/s(90) -10m/s(90) + 6m/s (t)
- 4m/s(t) = 180m - 900m = (-720)
t = 180s (+ 90s cuz remember the TM2 time took 90 seconds)
Time to repay a mex without assistance = 270s
so. we have two points on a graph. Assistance = infinity, (horizontal asymptote approaching t =225s) and just the mex alone t = 270s , hey look, not much time saved it seems.... but it gets more complicated, as I will make everyone's life HELL and add in the crappy little measurement of what an engineer could be doing instead of assisting a mex. It should be simple enough to explain mathematically:

I am still going to insist that the reclaim coefficient that I measured at 1m/s 10 e/s in trees is up for debate and so I will use R as the reclaim coefficient of an engineer on the current map of question. This can be experimentally determined but the predicted value of R will decrease as # of engineers increases and as the total Reclaimed amount increases as well.

TM1 = 2m/s (t) + R(Total # of engineers) (t)
TM2 = 2m/s (t) - 10m/s(t) - 5m/s(t)(Assisting # of engineers) + R(Total # of engineers - Assisting # of engineers)
TM3 = 6m/s (t) + R(Total # of engineers)(t)

I understand that typing out varriable names is why there are abbreviations and letters to replace them, but I want to be very clear about what I am putting out there. From here on Forward I will be using TE, and AE to represent Total and Assisting.

I could partially differentiate this here but I think there can be plenty learned without diving into that process. What I will do though is comparative statics. This will basically create an equilibrium point for two curves from our model and we will see how the equilibrium changes when we fiddle with some constants.

First. Lets make R = 1, simple and what I experimentally gathered from setons.
Second lets make our Model dependent on some number of mexes. this will get very complicated very quickly so lets focus on only the first mex going to T2, and only one mex going up.
Third Lets assume we are still expanding out into the map and we have 7 mexes capped and this is when we determine whether to upgrade or not. (or assume the map only has 7 mexes on it).
Lets finally say we have 10 engineers, we had to build t1 land units for some reason, deter some invaders.
So Mathematically speaking we have:
TM1 = 2m/s (Mexes)(t) + R(TE)(t)
TM1 = 2m/s(7)(t) + 1(10)(t)
TM2 = 2m/s(7)(t) - 10m/s(t) -5m/s(AE)(t) + 1(10-AE)(t)
TM3 = 2m/s(6)(t) + 6m/s(1)(t) +1(10)(t)

Our Equilibrium point is when TM1 = TM3 + TM2 (time to get investment back) is minimized and the only thing we can change is AE. This has three variables: TM, AE, t, and three equations. As long as i didn't make one linearly dependent on each other (meh Echelon matrix... why do I feel the need to do one......) this should be solvable. (ahh my equilibrium condition counts as an equation, so I have 4 equations, I'm safe here....)

WELL SHENANGIGANS.... I'll either edit this post or post a followup. I got a Physics Lab to get to, so you can all digest this for the next couple of hours and hopefully correct my mistakes before I get too wrapped up in this.

p.s. ( remember to save your post to a text document before clicking submit, faforever logs you off after (my 2 hour rant of typing) and I'm glad i had the post backed up before hitting the submit key. may even not like the save button, not about to test my luck with that.)

Statistics: Posted by Rasmuffin — 18 May 2012, 22:53

Re: Supcom FA eco

2012-05-18T16:13:56+02:00

TA4Life wrote:
You got me dreaming about Supcom FA data again. Hotstats was suggested to me before but there are major problems
there:
can't save, can't change x axis, can't change possible functions, available functions explode and without being able to
zoom in on a small window most data is useless.

This raw data would be an excellent addition to supcom fa commentaries where the economy is very much hidden behind
the players' abilities. Analyzing economy stats at the end of a game and correlating data to different game events
(drops, pgen snipes, etc) would provide a more complete picture.

A lot would of course depend on what kind of raw data was obtained. At the bare minimum it would be nice to see
(player#, mass, energy, time) for all times between 0 and victory. It would be even more awesome to have (player#,
massIN, massOUT, energyIN, energyOUT, time). I think having things like #of engies, would get too crazy.

howdy,

It should be pretty simple to get to the raw data, because with playertrack it worked too. But where playertrack probably
just dumped accumulated statistics at the end of the game, what you need for a time chart would be one row of data every N beats, which would be a lot more data to handle. It would make sense in this case to write the statistics to a dedicated file; i'm assuming that playertrack just appended the statistics to the general log and uploaded the whole log.
Hotstats is 5% gathering the info and 95% drawing graphs, so that would not be much work to add 5% to pretty print the stats in text form.

On the other hand, hotstats is fundamentally limited in what it can print, which is all the information that is accessible to
a UI mod. Among the interesting data points for eco-related statistics i see: number of T[1,2,3] mexes, number of T[1,2,3] pgens, number of engis. If that information was accessible to a UI mod for all the players it would obviously allow cheating.
But that kind of information is accessible to simstate lua scripts if i understand that correctly. So there are 2 possibilities:
Given that there was some lua code running in the sim state that would collect the relevant data, it could either make the stats accessible to a UI mod when the game is over or it could write the data to a file on its own. Of course that requires a patch from FAF, which a stats dumper ui mod would not.

From there on its just a perl script / javascript / excel sheet away from more useful statistics (compared to hotstats).

My lua knowledge is nonexistant, but i could spent some time on the problem. Is there information available on the supcom lua api? like opening files, etc?

Statistics: Posted by rootbeer23 — 18 May 2012, 16:13

Re: Supcom FA eco

2012-05-18T11:36:23+02:00

-_V_- wrote:
Hum. Isn't that contradictory to what has been said ?

To be honest, I didn't read very carefully all the posts. What is in contradiction with my maths ?

-_V_- wrote:
The limitation would probably come from the time that the engies need to move from the currently "being upgrading" mex to the next one. I don't think we can make such rules, cause it depends too much on how far the different mexes are from each other.

Well, unless it takes more than 140 seconds to move them, you will gain something IF they are not reclaiming, AND if there is something to reclaim after that near the mex.

-_V_- wrote:
To mitigate the waste, I usually put 5 engies to reclaim near each mex, and use them all once I have the mass to upgrade the mex very fast. From what I've seen lots of people do that.

That's indeed the best and logical thing to do.

Statistics: Posted by Ze_PilOt — 18 May 2012, 11:36