Widget signing gadget (request)

[Peet]

Oh christ so you really have no idea how spring's synchronized simulation works, or why it is set up the way it is. This discussion is pretty pointless without that information.

[Argh]

OK, so what's the problem there? If the host is allowed to tell other players how many resources they have, why can't it tell them what unitIDs exist, and where they are?

I mean... a client doesn't need to know that a Bertha is at a given position XYZ, unless that Bertha can be seen.

It only needs to know whether a projectile from that Bertha exists- a different issue entirely.

[Kloot]

the host does not tell other players how many resources they have

[Peet]

I am not wearing any pants

[aegis]

the entire game is run on each player's computer.
the only thing transmitted is unit commands.

[Argh]

OK, so everybody's client has the full game-state then?

Why is this desirable or necessary? Why can't the host be the control point, be the only machine with the full game state... and send information to the clients if it's necessary?

I mean... I don't need to know that Peet's reactor is putting out 1000E this SlowUpdate, or even that it exists, if I cannot observe it directly. Even then, I shouldn't know how much E it's making, because that's none of my business.

As an additional thought... what you're telling me is that not only can cheaters see everything in LOS, but they can see all economic data, all Gadgets that cause gameplay effects being activated, etc.

Kinda a big list of available cheating options, then.

[aegis]

full circle.

anything other than the current system would require a major rewrite and have side effects.

[Argh]

OK, so basically it's because nobody wants to correct this badly enough to fix it. Fine.

At least we're clear on that, and the scope of what can be actually done by cheaters, which is far beyond what you can do with a mere Widget.

Since RTS games are, at heart, mainly about information... meh, that's disturbing. Who can possibly take competitive play with this engine seriously, when you'll never know if your opponent was out-guessing you, or just watching your every move?

[Peet]

OK, so basically it's because nobody wants to correct this badly enough to fix it. Fine.

I've been sitting here staring at this quote for awhile and I still haven't come up with an eloquent response. You are clueless on this subject and you need to acknowledge this or at least stop talking about it.

Sure, the above issues do constitute a flaw in the current system, that is granted. Use of the alternative methods is infeasible for this engine.

[aegis]

the server tracking everything and only releasing relevant updates to clients would most likely be very impractical and require ungodly amounts of bandwidth compared the current system... and replays wouldn't work.

[zwzsg]

Oh christ so you really have no idea how spring's synchronized simulation works, or why it is set up the way it is.

Welcome to talking to Argh!

the server tracking everything and only releasing relevant updates to clients would most likely be very impractical and require ungodly amounts of bandwidth compared the current system... and replays wouldn't work.

I must add such a system would allow for true cheats, like giving yourself infinite resource, free units, invunerable units, spawn nuke explosion inside any enemy at will, etc... which is now impossible thanks to how Spring is running synced.

What you call "cheat" are now limited to doing what players can already do.

In order to stop those pretented "cheat", you propose to rewrite the whole engine from the ground up, in a way that would allow real cheat to work.

[Kloot]

Why is this desirable or necessary?

Start by thinking (not aloud) about bandwidth.

[aegis]

well, it's possible to only send commands to the server and have the server give you everything

but that provides a bandwidth issue.

[Argh]

I can see how bandwidth use would go up. But I thought updates were being sent pretty infrequently, and compared to a FPS, surely it would still be a very small increase in packet-size per update.

I mean, again assuming that Tobi works on that LOS proposal... we'd be seeing commands out to the host... then the host sends back resources and visible unitIDs. I guess the big issue is Gadgets, but there it's mainly commands or generated callouts from COB, and that could be treated like a command.

So, where's the bloat, if that's the case? The packet would go up maybe 1K at most, to store that unitID table, not a huge dealio unless you're on dialup.

Oh... wait, you'd have to store all the Projectiles, too. Ugh. That would get cumbersome.

[aegis]

a fps has maybe 32 players to track.

save a spring game and look at the file size.
that's how much data would need to be sent to each client if they all had LOS on the whole map.

[Argh]

But you don't need to send it all. You just need to send what's changed that's visible to a given Team. Projectiles probably can be weeded out, if they aren't close enough to any of your unitIDs.

IDK. Maybe you're right, but my guess is that if you compare what's in a given update in a Replay, vs. what's actually necessary in a host-controlled model that's been optimized, they just aren't the same thing at all.

[aegis]

save a spring game and look at the file size.
that's how much data would need to be sent to each client if they all had LOS on the whole map.

[Argh]

But they don't have LOS over the whole map... and my proposal on LOS would eliminate the LOS maps entirely. We'd just have lists of visible unitIDs per team (and potentially projectileIDs as well, come to think).

So, for each visible unitID, we'd need their type, velocity, position / heading, and their current goal X,Y.

For each projectile, we'd need their type, velocity, position / heading, and if guided, their goal.

Then we could extrapolate from that until the next update.

[aegis]

it's feasible for someone to have LOS on the whole map.

also,

save a spring game and look at the file size.
that's how much data would need to be sent to each client if they all had LOS on the whole map.

[Argh]

It's feasible, sure, but my whole point is that they wouldn't have LOS of the map, but merely have visibility of every unitID. Not equivalent.

One's a giant table of LOS maps... if my LOS proposal was put into place, it would become a far-smaller table of visible unitIDs. Then the client can update itself based on that.

Again, that's just a proposal atm, and hasn't been implemented. But if it was... this would become a lot more practical, I'd think.