Forged Alliance Forever Forged Alliance Forever Forums 2014-02-16T13:52:14+02:00 /feed.php?f=2&t=6215 2014-02-16T13:52:14+02:00 2014-02-16T13:52:14+02:00 /viewtopic.php?t=6215&p=65505#p65505 <![CDATA[Re: Unit command lag fix]]>
3630 will have that value set to 2500. (the exe will be patched, no need to hack the lua sim :))

Statistics: Posted by Ze_PilOt — 16 Feb 2014, 13:52


]]>
2014-01-30T13:25:02+02:00 2014-01-30T13:25:02+02:00 /viewtopic.php?t=6215&p=63663#p63663 <![CDATA[Re: Unit command lag fix]]>


We just need willing players to make tests

Statistics: Posted by dstojkov — 30 Jan 2014, 13:25


]]>
2014-01-29T19:34:02+02:00 2014-01-29T19:34:02+02:00 /viewtopic.php?t=6215&p=63623#p63623 <![CDATA[Re: Unit command lag fix]]>
Annoying issue too IMO ! (even if some people will say shit pathfinding allow for stuck ACUs snipes and make the game even more wonderfull)

Statistics: Posted by Poch — 29 Jan 2014, 19:34


]]>
2014-01-29T19:08:00+02:00 2014-01-29T19:08:00+02:00 /viewtopic.php?t=6215&p=63621#p63621 <![CDATA[Re: Unit command lag fix]]>
If you have some logical sense of how p2p networking multiplayer sync is working for a game like Forged Alliance, then you should know that it is highly un-logical to have command lag issues. For anything else if a player CPU isn't powerfull enough, the game is micro-pausing for everyone while waiting for the slowest CPU to finish calculations. And the simspeed goes down...

Now, it looks like the devs made a compromise with that initial order "processing" : it is executed asynchronously, and thus is not blocking the game even if it take 5 seconds to figure out where the unit has to go. You can see that even with only 1 unit in the game. Just ask it to go somewhere very very far away with hills or obstacles on the orad. It can take up to a few seconds for the unit find his path and start moving. (if you play rock on seton and you ever sent your first engy to the island cliff, to make a factory you know what i'm talking about).
Then, I suppose some part of the networking sync code is about knowing when ALL cpus have figured out where the unit has to go. If it is not the case, then it means that a "credit" is a so precise amount-of-CPU-power that the game can actually predict when a move order will be pathed based on his complexity or something like that. Maybe each order has an inner "complexity" value that translates directly into credits. I find it hard to believe but who knows.

So anyway, clearly the devs didnt wanted to allow a high priority to unit pathfinding : if units can't path, game simulation goes on it doesn't pause. So how did they implemented it ? Simply by allowing "cpu time credits" per tick to pathfinding calulcations. You can think of them as a % of available CPU dedicated to pathfinding. If that % is not enough to calculate all pathing for current tick, then it is reported to next tick and units wait.

Now, i've seen people saying "it will slow down the game to allow more resources to pathing". Of course, there is some impact, will it be noticeable or not, we can't tell. But what i can tell you is this : the best CPU available when Supreme Commander came out was a Core2Duo Q6600.
Now a cheap Core i5-2300 is almost 200% more powerfull than a Q6600.
And a good Core i7-4770K is almost 200% more powerfull than a i5-2300.
(okay more like 180% than 200% in both case, but brute power isn't everything)
So my 6 months old 4770K is 3-4x more powerfull than the best CPU available when SC came out. And SC had to work on 1v1 or 2v2 for all computers back then. Like Athlon X2...
Maybe for math-specific stuff like pathfinding it is 1000% perfs increase who knows.

So now you have to think about balance between CPU power, engine optimizations and what the players are asking from the game. If one element changes radically over the years, it seems logical to adjust the others as well. It seems obvious to increase the CPU time allowed to unit pathfinding for that reason. Now, when you know that this was introduced back in 2007, *probably* because CPU were shit back then, and when you know that we still have issues because of this in 2013, it makes even more sense to increase the CPU budget allowed to pathfinding.

---

One thing we should test, though is the meaning of those "credits". What does 1000 credit means ? Is it brute CPU power ? Is it a % of the actual CPU (and then it scales auto to cpu power) ? I would bet on finished CPU power amount, because it would allow for some consistency accross all simulations. And this amount HAS TO BE something that was manageable in background for crappy CPUs of year 2007. For me that reason it self-sufficient to justify the credit increase if it is safe.

Also, one could argue you should set credit count accordingly to player count regardless of your CPU power. Maybe the game multiply the credit value by # of players in game ?

And then, what we should try to know "is how much power each credits mean". And after that "how does the engine manage credits" ?

I think we could do those tests to get the answers :

TEST 1 : determine if a slower computer can delay unit pathing even at game start
  • A player with a very high end cpu create a game on a very very large and complicated map. Alone.
  • Make 1 engy, ask him to move to the other side of the map.
  • Measure reaction time between move order and engy start to move.
  • Redo the test but with the worst CPU you can get.
  • Redo the test but with the 2 players in the same game.
If you get the same delay in all cases, it means credit is a finished amount of CPU power, consistent across all machines. (ideal)
If you get a different delay, try to increase pathfinding credits until you get the same delay with a good/crappy CPU.

TEST 2 : determine how good or bad FA manage pathfinding credits
My theory is that, if the credit number was infinite, you would never get pathfinding lag, because the simulation would wait for all path commands. What would be nice is that if FA could do it smoothly as long as you get CPU power Or would it cause very annoying simulation lags ?
  • Set credits to an insanely high value. Like the maximum value of a 32bit signed integer or something like that.
  • Start a huge game with a lot of players, build a ton of shit, and report how game reacts when it needs to do a lot of pathfinding with infinite credits.
What would be very bad here is if a high credit count makes the simspeed go down even if there are no ongoing calculations. It would mean CPU-power reserved for pathfinding can't be used for anything else. Even if it the case i still think we should raise value but to a reasonnable amount.
What would be ideal is to see the simspeed go down (not too much...) only after there is a ton of units and getting 0 command lag issues (relative to the simulation ofc). It would mean you can change credit value without any effects for normal sized games.

---

For the engy stuff : Cool ideas here but all of them feel more like workarounds than real improvements. I like the idea of upgrading BP to a factory tough, but i'd like it even if there were no issues with engy. The best thing i've seen so far is SCAccount post about the engies not colliding when using assist moves, so personally i would support using that behavior for all assists orders rather than the other proposals.

---

EDIT : Found some informations

Discussions on GPG forums :

Other path console commands :
Code:
 
path_ArmyBudget - Budget for each army to do pathfinding each tick
path_BackgroundBudget - Maximum number of steps to run pathfinder in background
path_BackgroundUpdate - Update pathfinding tables in background
path_GeneratePreview - Do a pathfind for the UI preview
path_MaxInstantWorkUnits - Budget for instant pathfinds by the AI
path_TimeoutPreview - Maximum number of ticks to allow pathfinder preview to take
path_TimeoutSearch - Maximum number of ticks to allow a single pathfind to take
path_UnreachableTimeoutSearch - Maximum number of ticks to allow a single pathfind to take for an unreachable path
PathDebug - Debug the path finder

Statistics: Posted by Poch — 29 Jan 2014, 19:08


]]>
2014-01-28T07:43:27+02:00 2014-01-28T07:43:27+02:00 /viewtopic.php?t=6215&p=63483#p63483 <![CDATA[Re: Unit command lag fix]]>
Flipper wrote:
Would it be possible to implement some system where you tell engineers to "become" a part of the factory, and as they meld into it, they increase it's build capacity?


Read the thread. LOL.

Flipper wrote:
problems include that since the engies are in the fac, they can't be killed, so you remove the ability to cripple your opponents build power, and it removes the ability to get vet on players build power, which is something I think about when I pack build power around facs.


Hence my suggestion of still allowing "engies" to be killed after perma-assist, but I don't think that idea was simple enough to gain traction/popularity.

Anyway, let's open a new thread for this, because as mentioned, it's not completely on topic re: Crotalus' fix.
(Refer: viewtopic.php?f=2&t=6467)

For Crotalus' fix: the way I see it, with or without mods to alleviate the engi pathfinding problem, no reason not to test it more and implement it if it means better pathfinding at a marginal decrease in sim speed in the games when it reaches many units. i.e. I'm all for it.

Statistics: Posted by whootle — 28 Jan 2014, 07:43


]]>
2014-01-27T22:26:35+02:00 2014-01-27T22:26:35+02:00 /viewtopic.php?t=6215&p=63446#p63446 <![CDATA[Re: Unit command lag fix]]>
Flipper wrote:
Would it be possible to implement some system where you tell engineers to "become" a part of the factory, and as they meld into it, they increase it's build capacity? It would be similiar to the Aeon sacrifice. Voila! you get build capacity, pathing gets reduced, and you still have to spend the mass/energy/time on engineers to reap the benefit. If factory you added engineers goes boum, then you lose the engys.

Thoughts?


People have been suggesting this for years, and most specifically while engy mod was in dev. The answer was a resounding NO. Some of the problems include that since the engies are in the fac, they can't be killed, so you remove the ability to cripple your opponents build power, and it removes the ability to get vet on players build power, which is something I think about when I pack build power around facs. It definitely is incentive to build facs instead of engies.

Statistics: Posted by RoundTabler — 27 Jan 2014, 22:26


]]>
2014-01-27T20:27:26+02:00 2014-01-27T20:27:26+02:00 /viewtopic.php?t=6215&p=63439#p63439 <![CDATA[Re: Unit command lag fix]]>
Thoughts?

Statistics: Posted by Flipper — 27 Jan 2014, 20:27


]]>
2014-01-27T20:23:58+02:00 2014-01-27T20:23:58+02:00 /viewtopic.php?t=6215&p=63438#p63438 <![CDATA[Re: Unit command lag fix]]>

I play teamgames with a rating of 1200 and I rarely ever use battleships, but if I need them, the 18 assisting hives will have the same assisting power as 450 engineers and during the roll-off, they will support the factory next to it. Unlike T1 engies, they won't give instant full veterancy to T4 bombers.


Maybe engineer kills shouldn't count toward veterancy anyway - they can't even shoot back (yes I know Sparky can).

Statistics: Posted by Flipper — 27 Jan 2014, 20:23


]]>
2014-01-27T18:25:35+02:00 2014-01-27T18:25:35+02:00 /viewtopic.php?t=6215&p=63429#p63429 <![CDATA[Re: Unit command lag fix]]>
SC-Account wrote:
E8400-CV wrote:Build more factories or get hives; problem solved. I definitely don't want a general slowdown by -0.5 to facilitate those that still want crap out 400 T1 engies. If they can't control their army because of that; even better; it will learn them to not do it.

Good luck at producing battleships out of 10 T3 factories without assisting engineers. I don't know at what level you play, but please stop spreading nonsense -.-

Asides that: no 400 engineers - no slow down.


Then ask for an increase in the buildpower of naval factories or a decrease in buildtime for certain ships. Adding one problem to solve another ....

I play teamgames with a rating of 1200 and I rarely ever use battleships, but if I need them, the 18 assisting hives will have the same assisting power as 450 engineers and during the roll-off, they will support the factory next to it. Unlike T1 engies, they won't give instant full veterancy to T4 bombers.

Statistics: Posted by E8400-CV — 27 Jan 2014, 18:25


]]>
2014-01-27T18:20:17+02:00 2014-01-27T18:20:17+02:00 /viewtopic.php?t=6215&p=63428#p63428 <![CDATA[Re: Unit command lag fix]]>
whootle wrote:
By the way, if the idea about permanent assist is too complex/hard to implement etc. (and I was just trying to keep the same game mechanic while getting rid of pathfinding issues), how about we simply solve the problem by allowing you up upgrade factories' build power?

i.e. press an upgrade button (similar to t1->t2 upg, except only for BP, not tier) and once upgrade is done, factory has a higher BP. No complex perma-engi assist. If you allow unlimited "BP upgrades" on the same factory, you can essentially get what you have with a 200 engi-assisted naval factory.


Whootle you are on to something here. Only problem with your idea is that upgrading the fac requires time which can be spent pumping units, so it would again be more efficient to tricle in build power from other factories instead of upgrading main one.

How about adding adjacency to factories. So for eg you could build t1 land factory next to air fac and as long as the land fac is not building anything its assisting air fac. And than as you suggested giving it BP upgrade mechanic would mean that air fac can keep producing while adjecent factories are being upgraded and adding more build power to it. This would mimic the slow tricle of engineers to air factories while eliminating engi spam.
Than it would be only matter of adjusting the numbers of bonus BP and nessesery upgrade time from adjecency. For eg have one land fac adjesent to air fac equal 35-40 engineers afther 6-7min or so of constant BP upgrading.
This is not a solution to navy engi spam problem thou, and is off topic of crotas mod.

Statistics: Posted by Marko Box — 27 Jan 2014, 18:20


]]>
2014-01-27T16:47:02+02:00 2014-01-27T16:47:02+02:00 /viewtopic.php?t=6215&p=63424#p63424 <![CDATA[Re: Unit command lag fix]]>

Which would break :fiddles with abacus: everything.

In short, the ability to quickly react to nearly anything with insane building power if you have the eco to do it would be really bad.

Oh know, you spotted some bombers inbound, make a million ASFs in a second and bam, countered.
Spot an early monkey, spam out a million gunships -countered.

I think you see the picture.
The only choice is to load up on mass and not attack as the defender has the ability to counter for less mass.


Those ignorant of history are doomed to repeat it - this is an exact description of supcoms countering mechanism - FA took this and essentially divided/multiplied everything by ten (decreased damage, increased hp - and so forth) - what you experience as FA play is what you described but with mass and buildpower nerfs. Increasing engineer utility will drive a return to SupCom style play (where counters could mass assisted)

Besides you do need the eco, and given how blithely you ignore what is the largest game requirement, I'm inclined to call special pleading rather than take this argument too seriously.

Also dj is right in that this demonstrates the ultimately flawed nature of the attempts to change buildpower factory engy ratios. Engy mod/factory mod could never have worked. We see it here in that it has utterly failed to reduce engy/assist spam.

Statistics: Posted by Anaryl — 27 Jan 2014, 16:47


]]>
2014-01-27T12:15:51+02:00 2014-01-27T12:15:51+02:00 /viewtopic.php?t=6215&p=63401#p63401 <![CDATA[Re: Unit command lag fix]]>
errorblankfield wrote:
we have to watch the game's identity.

And of course add some sorta indicator.


Maybe the new model can have more and more "nanolathe tubes" (but all in a single unit/image) so it remains "supcommy" but no pathfinding issues? But yes, definitely some sort of indicator would be good.

Statistics: Posted by whootle — 27 Jan 2014, 12:15


]]>
2014-01-27T09:52:58+02:00 2014-01-27T09:52:58+02:00 /viewtopic.php?t=6215&p=63391#p63391 <![CDATA[Re: Unit command lag fix]]>
errorblankfield wrote:
In short, the ability to quickly react to nearly anything with insane building power


This is not a insta counter like you can imagine, your opponent has the same build time and also the same build power than you so ... no wonder action in this part.
The true aim in this situation is like you are doing it now don't let you opponent have more resource which mean first map control and second target the resources which include upgraded factory. But again this is nothing new in the game play.


P.S: the eng got also a build range buff and for each level eng a better one
t1 eng range < t2 eng range < t3 eng range
And it helps a lot !!

Statistics: Posted by dstojkov — 27 Jan 2014, 09:52


]]>
2014-01-27T09:12:05+02:00 2014-01-27T09:12:05+02:00 /viewtopic.php?t=6215&p=63390#p63390 <![CDATA[Re: Unit command lag fix]]>
Only problem is that it's slightly un-supcommy. :/
Not a reason to not do it, just we have to watch the game's identity.

And of course add some sorta indicator.

Statistics: Posted by errorblankfield — 27 Jan 2014, 09:12


]]>
2014-01-27T09:07:20+02:00 2014-01-27T09:07:20+02:00 /viewtopic.php?t=6215&p=63389#p63389 <![CDATA[Re: Unit command lag fix]]> Statistics: Posted by BRNKoINSANITY — 27 Jan 2014, 09:07


]]>