Gameplay downgraded?

Okay, you're going to have to explain to me how you think this works. Because in no way shape or form does it work that way.
This code is client side. It can't slow down your game time, only the server can do that. It just smooths things visually.

Yep, I honestly don't think it will be much of a big issue. Only overly relying on the slowdown would be a bad thing. The server-performance still needs to be improved, and if that's not a phenomenal upgrade, Uber probably will still need better servers.

The thing atm might addtionaly be the PTE-sever having a bit of an overload, since they are bringing the release version with the shiny deathstar.

Isn't the game running slower cause by the server tanking sim-fps in the first place? I thought the time dilation in PA only kicks in for the client, not the server.

I can't possibly debate with someone who thinks slower gameplay is a good thing.

As I've stated above I'm perfectly aware of physical limitations that won't go away. I've also, said, what in my opinion were the solution to those.

my point is that this is the obvious answer for someone who doesn't want to run a 1.0 simspeed game!

and that that is what we were aiming for from the start with UBER and have not changed to this day

this day we admit we're not able to and cave in to the same gameplay as on FA.

the fact of the matter is the server has ALWAYS been overloaded.

For a year now.

(my first post in this thread)

and that' by allowing the time dilation code into PA, we're saying we no longer need more servers, we no longer need unit cap.

We'll just play the game UBER slow.

This bit of code allows you to do ANYTHING, ANYTHING AT ALL, give you TAKE THE TIME to do it.

I really fear you fail to understand how this exempts uber from buying any new server and letting us all lag in hell.

the game is synchronous for all players. meaning server and all players are all at the same game state at the same time.

If the server is playing the game time slower then everybody else follows.

time-dilatation is not a client-side thing.

I don't think its a good thing, I think it's a better thing then massive amounts of freezing and units warping around.

Better then the side show, not better overall.

And yeah, better servers will be better, but nothing has changed recently to effect that in a bad way, the games performance has gotten better with optimization but other then that.

We wait for better servers from fans and dev's.

Like I said, it's a seatbelt. If sim framerate tanks, it helps make the game look better. If sim framerate is fine, it does nothing. Nobody's going to satisfied with 50% speed gameplay, there's no way this is going to be an 'excuse' not to improve the server performance.

And like I said before, I think turning the in-game timer red and showing the current speed multiplier in red next to it would be a good way of keeping people informed about sim speed. When you can see that the sim is running at 50% speed, no amount of smoothing is going to make that okay.

Haha, no. It would have been an nightmare to develop. Synchronous P2P network structure and multithreading? That's a whole can of worms, as Mavor would put it.

massive amount of freezing and warping and warping around forces uber to adress the problem.

You're so naive, why can't you think of PA as an engine rather than a game.

If the engine was left as is and we got server-side free of time-dilatation

you could have played on my server free of freezing and time dilatation.

Isn't NO type of lag better than SOME type of lag?

The new 'time-dilation' code is only a client-side thing. Sim speed changes are a fixed-framerate induced thing, you can't really code around them. They are impossible to 'fix'.

the whole point is we wanted to get rid of single-core AND P2P

It is. The server has no such thing as time dilatation, it operates on a best effort base. It also operates on a discrete, fixed time base, so it is in no need of it.

Time dilatation is computed and applied by the client in order to match server time.

Ah, so you're talking about the server being adjusted for going for slower sim-speeds, no the client time dilation itself.
Edit: But what does that actually change server-side? Sounded like a client-only thing to me.

I think we should just wait for now. Let's give time for Uber to do a potential upgrade, maybe make a thread asking for optional unit limits?

So that's the reason for the limited multithreading. What a reveleation.

Well, in that case the usual rules matter: Don't try stuff that doesn't work well. Or at least deliver the server-tools to avoid these issues. As said, FA even had issues in Singleplayer and against the AI.

That's one thing that PA&Uber do really well!

sorry but you're gonna have to come up with some proof on that one.

that's can't be possible because of synchronous.

I don't see how the server could be like : ok I'm over here now but don't show that yet we're gonna gradually show it from our last recorded point.

if the server has data it's done processing, in the interest of not getting desynced data bewteen players you have to distribute it without waiting.

The server has no dilatation, only the client does.

And the dialation only occurs when your server chugs and stutters.

If your server isn't bad then the client won't have the smoothing effect.

Forrest told you himself. That's what the new code does; it smooths out movement on the client. Did you not read his post?

I *think* forrest may have said so earlier actually.

to me that is not what is to be understood by what he said.

Yes, and there were reasons why this wasn't possible with SupCom back then. Mostly bandwidth requirements. Heck, it was remarkable that they managed to provide Internet multiplayer with a game of that size back then, and with a surprisingly low number of network issues, too. (Low. Compared to what could have went wrong. Not non-existent.)

That's called interpolation. That's actually how many games (off the top of my head, any online source engine games) work. They only show you what happened one or two frames in the past (well, an interpolation between them actually, based on your interp settings), so that you have a buffer of a frame or two of what is going to happen (in case of lost data), so that you don't constantly see everyone jittering around.

You distribute the data, the client recieves the data, but the client doesn't need to show the absolute latest frame right then and there. Like I said, interp is a thing.

Then just try to figure how you would implement it yourself, in the easiest way possible?

That would probably be:

1. Have the server record real time timestamps for each server frame
2. Have client buffer a frame or two.
3. Have client compare timestamps, to estimate how long the current buffer is to last (1/10th of a second per buffered frame) and how long it will take for the server to provide the next frame (difference between last two timestamps, or a few more and then calculate the median)
4. Have client stretch all animations by the computed factor. Also helps smoothening the animation if the server happens to only have a stutter for a frame or two.
5. Speed up if the client starts lagging behind the server because it overestimated the dilatation.