| 1 |
You'll
still
encounter
the
problem
even
if
you
limited
it
to
1.
The
problem
is
in
order
to
keep
the
game
synced,
everyone
has
to
send
their
commands
over
the
network.
What
you're
proposing
is
doing
something
after
the
commands
are
sent
(
AllowCommand)
.
What
you
[b]WANT[/b]
is
CommandNotify
which
does
not
provide
enough
information
to
us
to
prevent
the
problem
from
occurring.
CommandNotify
and
AllowCommand
are
two
very
different
callins
(
read:
events)
:
|
1 |
You'll
still
encounter
the
problem
even
if
you
limited
it
to
1.
The
problem
is
in
order
to
keep
the
game
synced,
everyone
has
to
send
their
commands
over
the
network
(
which
means
sending
8000
'build
lotus'
commands
to
everyone
which
causes
the
lag)
.
What
you're
proposing
is
doing
something
after
the
commands
are
sent
(
AllowCommand)
.
What
you
[b]WANT[/b]
is
CommandNotify
which
does
not
provide
enough
information
to
us
to
prevent
the
problem
from
occurring.
CommandNotify
and
AllowCommand
are
two
very
different
callins
(
read:
events)
:
|
| 2 |
\n
|
2 |
\n
|
| 3 |
CommandNotify:
|
3 |
CommandNotify:
|
| 4 |
- Happens BEFORE network transmission
|
4 |
- Happens BEFORE network transmission
|
| 5 |
- Allows coders to block commands from [u]propagating[/u] (Ie: this is what we want to do!)
|
5 |
- Allows coders to block commands from [u]propagating[/u] (Ie: this is what we want to do!)
|
| 6 |
- Does not provide the unitID to the function (only cmdID, cmdParams, cmdOpts)
|
6 |
- Does not provide the unitID to the function (only cmdID, cmdParams, cmdOpts)
|
| 7 |
- is UNSYNCED
|
7 |
- is UNSYNCED
|
| 8 |
\n
|
8 |
\n
|
| 9 |
AllowCommand:
|
9 |
AllowCommand:
|
| 10 |
- Happens AFTER network transmission
|
10 |
- Happens AFTER network transmission
|
| 11 |
- Allows coders to drop commands from units
|
11 |
- Allows coders to drop commands from units
|
| 12 |
- Does provide useful information that would allow limiting queue size
|
12 |
- Does provide useful information that would allow limiting queue size
|
| 13 |
- is SYNCED
|
13 |
- is SYNCED
|
| 14 |
\n
|
14 |
\n
|
| 15 |
What is happening is that we have to transmit huge amounts of data over the network (1000's of commands). This transmission is what generates the "lag" you see. This makes AllowCommand ineffectual (which is what you're suggesting). We need CommandNotify, but we can't get enough information. Now we could do some hacky behavior, and get the selection under the assumption that commands are human issued, but this breaks things (namely commands can also be internally generated. see: unitAI).
|
15 |
What is happening is that we have to transmit huge amounts of data over the network (1000's of commands). This transmission is what generates the "lag" you see. This makes AllowCommand ineffectual (which is what you're suggesting). We need CommandNotify, but we can't get enough information. Now we could do some hacky behavior, and get the selection under the assumption that commands are human issued, but this breaks things (namely commands can also be internally generated. see: unitAI).
|
| 16 |
\n
|
16 |
\n
|
| 17 |
Unfortunately, since this is unsynced malicious actors can and will bypass the protection (see editing game files). While this would caused mod checksum mismatch if done in gadgets-unsynced, it would not stop someone from breaking games unlike if it was synced (which would create desync for that one player).
|
17 |
Unfortunately, since this is unsynced malicious actors can and will bypass the protection (see editing game files). While this would caused mod checksum mismatch if done in gadgets-unsynced, it would not stop someone from breaking games unlike if it was synced (which would create desync for that one player).
|
| 18 |
\n
|
18 |
\n
|
| 19 |
Note also that every time we check something it generates a little bit of 'lag', so checking huge queues like this in AllowCommand would just make the problem way worse because not only do you not prevent the massive flood of packets, now you're having to check every command on top of that.
|
19 |
Note also that every time we check something it generates a little bit of 'lag', so checking huge queues like this in AllowCommand would just make the problem way worse because not only do you not prevent the massive flood of packets, now you're having to check every command on top of that.
|
| 20 |
\n
|
20 |
\n
|
| 21 |
Note as well that once the large queue is done transmitting, it no longer has a sizable impact outside of cluttering the view-all-commands view and creating fps drops there (ie: not really a big problem).
|
21 |
Note as well that once the large queue is done transmitting, it no longer has a sizable impact outside of cluttering the view-all-commands view and creating fps drops there (ie: not really a big problem).
|
| 22 |
\n
|
22 |
\n
|
| 23 |
TL;DR: this is an 'engine needs to do this' problem.
|
23 |
TL;DR: this is an 'engine needs to do this' problem.
|
B1115830 25 on Akilon Wastelands ZK v1 (Multiplayer)