Using replication to achieve black magic?

Discussions about Coding and Scripting
JackGriffin
Godlike
Posts: 3774
Joined: Fri Jan 14, 2011 1:53 pm
Personal rank: -Retired-

Re: Using replication to achieve black magic?

Post by JackGriffin »

PrinceOfFunky wrote:simulated legal cheater
Image
So long, and thanks for all the fish
nogardilaref
Masterful
Posts: 577
Joined: Tue Jun 20, 2017 1:00 pm
Personal rank: ⚋⚊⚌☰⚞⌖⚟☰⚌⚊⚋

Re: Using replication to achieve black magic?

Post by nogardilaref »

Well, the thing is, the engine is pretty much already optimized to hell.
I do not mean that it's fully optimized and there isn't room to improve or anything like that, what I mean is that it was designed to run on dial-up connections, and nowadays even what is considered a "bad" connection is still some orders of magnitude better than that.
So, any optimizations on bandwidth of that nature aren't really a concern whatsoever.

However, doing it that way might not actually save you any bandwidth in practice, it might actually make it worse, and not only in bandwidth, but also in CPU usage and latency, which are often neglected, yet real constraints on replication too (all those rules and checks on whether or not to replicate have to be processed, they're not free, and they still have to go all the way from the server to the client).

This is because the only way to avoid replication to occur (in UScript) is for the player actor (the PlayerPawn) to stop being relevant to other clients, replication-wise, or if the properties are yours, you can also define in which conditions they replicate at all in the replication block.
This means that you have to change a few properties (and not just a single one) so the conditions of relevancy are no longer met in existing classes.

The thing is however, when an actor stops being relevant to a client, it effectively ceases to exist in that client altogether, which means that by the time it becomes relevant again, it gets replicated again to the client as if the actor just spawned again in the server, and it might be the case then that there's enough data being sent on those moments, and enough CPU usage and higher latency for the actor to "appear", which might not compensate the loss of relevancy at all.

This is specially important when a mechanic such as this potentially involves a player to appear right in front of another player after having shortly disappeared.
User avatar
PrinceOfFunky
Godlike
Posts: 1200
Joined: Mon Aug 31, 2015 10:31 pm

Re: Using replication to achieve black magic?

Post by PrinceOfFunky »

nogardilaref wrote:The thing is however, when an actor stops being relevant to a client, it effectively ceases to exist in that client altogether, which means that by the time it becomes relevant again, it gets replicated again to the client as if the actor just spawned again in the server, and it might be the case then that there's enough data being sent on those moments, and enough CPU usage and higher latency for the actor to "appear", which might not compensate the loss of relevancy at all.
Would this apply to long-time loss of relevancy either (I mean the compensation)?
"Your stuff is known to be buggy and unfinished/not properly tested"
Higor
Godlike
Posts: 1866
Joined: Sun Mar 04, 2012 6:47 pm

Re: Using replication to achieve black magic?

Post by Higor »

The whole dial-up thing is a mumbo jumbo.

There's 2 dimensions to replication:
- data optimization / prediction.
- environment size, dynamicity.

UT 99 ran on dialup using 7/10 optimization and 2/10 in terms of size and dynamicity.
You can't do any more than 4 simultaneous players on screen on low tickrates for dialup clients, unless you're a fan of rocket warping and missing events.

Once connections got better, server capacities went up. That's a plus on size.
Once mods and mutators started evolving, dynamicity increased, making better connections necessary.

Take the uk|Siege server, 25 players and maximum dynamicity. It barely holds up on clients because it's maxed at 25.000 instead of 20.000 and because there's massive native and uscript optimizations going on.
I'd rate it 9/10 on optimization and prediction and 8/10 in terms of size and dynamicity.
What would it take it to get a 10/10 in optimization?
-1: A feature developed in UT2k4 (or UE3, can't remember), replicating the first 1024 hardcoded names differently so they take less data, making function calls and event transfers far more optimal.
-2: Identifying the remote client in the uscript 'replication' block (something only native does).
If UT99 had these features on dial up, it would have run even better.

So no, the more updated the netcode, the better it runs.
That the game environment is shaped differently and is more dynamic is a completely different factor affecting bandwidth usage and requirements between different games.

EDIT:
Another interesting feature that would have been great to have (at the expense of CPU power) would be the ability to count the amount of updates done for an actor to a certain player.
So you only poll a certain set of properties every... let's say 5 checks/updates.
nogardilaref
Masterful
Posts: 577
Joined: Tue Jun 20, 2017 1:00 pm
Personal rank: ⚋⚊⚌☰⚞⌖⚟☰⚌⚊⚋

Re: Using replication to achieve black magic?

Post by nogardilaref »

I see... although the problem doesn't inherently look like being with replication itself, but rather how the overall classes are designed.
It should have been good design first, optimizations later, and not the other way around.

I mean, you literally have a single god class called "Actor" in this engine, this is by far one of the heaviest classes there is by default in the entire engine, which should be in fact one of the lightest, but proper OOP code back then was inexistent in most things, which they tried to improve in later iterations of the engine, tbf.
And this has some implications, like having far more checks and more data being transmitted over a single actor than necessary, which means more CPU and bandwidth.

The way it is transmitted however, although it could be improved, and even after your explanation, still doesn't seem to be the primary concern here, it seems only to patch over what is a glaring design problem in the first place.

Siege for instance, has always been a gametype which confused the hell out of me how it took so much CPU and network usage, when it doesn't really look like something that requires so much data traveling back and forth if some thought was put in fully redesigning it properly, and CPU usage overall other than perhaps the spam of projectiles from the guardians.
But then I realized that the builds are pawns and whatnot, only adding fuel to a raging fire, and I am not sure about it nowadays, but it seems they still are? Why?

I realize I might be missing some bit of critical information which would explain it all to me, but as of now it's just confusing, hence my current view on things.
Having that said, it has indeed severely improved over the years, and I could notice that, but it still looks to me to be suffering from a greater problem, and it's the foundations of how it was first built in the first place, which seems to be still mostly similar to the first versions from Badger years ago (iirc the original author).

The way I see it, simple components ought to remain simple and as actual components, but there are many things which suffer from unnecessary complexity and violate a whole set of simple principles, and might still inducing whatever's left of the current UT99 developers still doing the same kind of mistakes by example, due to "Epic did it like this, so it must be right".

One of the things I mean to investigate a bit in the future, is the replication of simple objects (extending from Object). They might not be nor act like actors, but they run UScript just fine and are much much lighter than actors, and for certain tasks they would replace actors just fine, or even become proxies of them.
PrinceOfFunky wrote: Would this apply to long-time loss of relevancy either (I mean the compensation)?
Well, in practice, if the time between disappearance and reappearance is small enough, the player actually never stops being relevant, because even when the relevancy conditions are no longer met, the relevancy still lingers for a few seconds so that if the actor becomes relevant again within that time, the server doesn't have to do the whole "let's send this whole actor all over again" thing.

If the time is long enough, then even if the player was visible in the first place and was just in another area, they wouldn't be relevant either so no data would be replicated anyway.
So, in both cases, tweaking the relevancy would be pretty much useless.
Post Reply