Widget signing gadget (request)

[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 could see every unit in the game.

it's feasible for EVERYTHING in the game state to change at the same time...

[zwzsg]

and compared to a FPS

You mean 500 unit per player is not much than 1 unit per player? C'mon, we got long ago that you have no idea what you're talking about when it's anything technical, but we at least you could some common sense.

Also, most FPS run unsynced: The server gather the state of each client, then send back the state of every client. The client then attempt to guess what happens until the next update, until it receive a new update at which point it erase its own state to replace it by the one received from server. Spring instead run unsynced: It only send on the network the orders given by players, and let everybody run his own simulation. The engine is perfect enough that different computer simulate exactly the same way, so the state on every computer stay the same only because it started the same and received the same new orders. If different computer didn't all have access to all the simulation, their sim would differ (if only because one computer would have run an extra random roll and then have subsquent call random number give different result). And the only way to make the simulation the same on everybody's would be to send the whole game state, which would take like several minutes. You can't send partial update, or else the sim would break horribly. But the beauty of Spring's system is that it render any cheat useless: If you hack the exe to give you free metal, then it only happens in your sim. In the sim of the other player, they're owning you because you nanostall. Until you're flooded by sync error. But I guess you won't understand the concept of having each player play in his parallel word. Shit why am I even typing that, it's a waste of time. I'll try to sum it up in few words:

Spring now = synced = cheating not even possible

What you ask = unsynced = allow every cheat

[Argh]

You don't need to send that much data, ever. At worst, you're sending the data on every moving unitID and projectileID. That's gotta be... hrmm...

So, one long int, eight long floats per UnitID? I don't know how much data that is without looking it up in Wikipedia, but for 1000 units, that can't be more than 20-30KB per update.

Probably far less, after being compressed.

If the updates are once per second, that's within spec for DSL, even if I take your worst-case.

And ok, if you have DSD 8 vs. 8, and 500 units per Team, that's no longer reasonable. But... again... that's not something that actually happens. Hell, I think I routinely have more real Units in P.U.R.E. in single-player games than most BA players see even in large team games.

Spring now = synced = cheating not even possible

According to what's been said here thus far, lots of cheats are quite possible- they're "merely" information cheats. If everybody has the full game state, then to see everything, people merely have to assign all LOS map stuff to all AllyTeams, and voila, no more LOS.

[aegis]

oh, you want to raise the bandwidth requirement to 240kbits*players^2 upstream for the host?

16 players would require 61mbit upstream... and each player would need 4mbit downstream.

people merely have to assign all LOS map stuff to all AllyTeams

they can't change synced memory.

[Argh]

Upstream --> commands / Gadget calls via COB only. Ever-so-slightly larger than now.

Downstream --> compressed packet. Surely it's compressed and decompressed on the fly right now, right?

[Argh]

Here's a simple demonstration of compression. I'm exaggerating the benefit here because the numbers aren't randomized, but still... before and after compression, with an ordinary textfile... 1000 entries of the type I was stating before.

I'll try to come up with grep to randomize it all, so that it's a little more realistic, but basically I think that the bandwidth problems are being exaggerated somewhat, unless you're currently sending everything raw.

[aegis]

so... when a unit wanders into someone's LOS... everything about that unit must be transmitted to all of the players on the allyteam...

units seem to have a lot of data... 1k coms is a 20mb save...

and while it was compressed successfully to about 1mb, the save itself took over a minute (which was data serialization, as my hdd can easily write 20mb in 1/3 of a second)... and the compression took a couple of seconds...

[Argh]

units seem to have a lot of data... 1k coms is a 20mb save...

IDK, I figured that we don't really need the full COB states, etc., unless they've just entered LOS for the very first time.

Other than that, we can extrapolate based on their movement / target / command state, I would think.

[aegis]

it takes a lot of time to serialize all the data... it would take a lot of time and effort to figure out which client needed which data... and you'd need to transmit a full unit state every time a unit entered LOS...

[trepan]

http://www.cs.ualberta.ca/~mburo/orts/

[Argh]

So, it's doable then. Interesting.

However, Aegis's comment about COB states is a particular issue with Spring. IDK whether there are any good ways around that mess. The more I think about it, the more I see that as the major stumbling block.

If we had a state-based animation system based on frames like MD5, it'd be one thing- we could interpolate updates with the current state... but as things stand... meh. That's a puzzler, and I admit I don't see a solution atm.

[Beherith]

Here's a simple demonstration of compression. I'm exaggerating the benefit here because the numbers aren't randomized, but still... before and after compression, with an ordinary textfile... 1000 entries of the type I was stating before.

I'll try to come up with grep to randomize it all, so that it's a little more realistic, but basically I think that the bandwidth problems are being exaggerated somewhat, unless you're currently sending everything raw.

This is complete and utter retarded bullshit. The entropy of the info in that text file is close to 0, since it not even close to randomly generated.

For fucks sake, you just repeated this line: 9999999,1.49292,1.392923,1.293129,1.49292,1.392923,1.2931291.49292,1.392923,
about 1000 times.

Heres a decent read for ya, it applies to maximum compressibility as well:
http://en.wikipedia.org/wiki/Entropy_(i ... on_theory)

[Forboding Angel]

Banning widgets or using a whitelist is pretty stupid. The only people who get hurt are the players that abide by the rules.

[Regret]

Banning widgets or using a whitelist is pretty stupid. The only people who get hurt are the players that abide by the rules.

What if the rules are 'no widgets'?

[aegis]

Banning widgets or using a whitelist is pretty stupid. The only people who get hurt are the players that abide by the rules.

What if the rules are 'no widgets'?

that would probably fall under "banning widgets"

[Regret]

that would probably fall under "banning widgets"

Maybe read what he said and think about what I could have possibly responded to?

The only people who get hurt are the players that abide by the rules.

[Neddie]

Banning widgets or using a whitelist is pretty stupid. The only people who get hurt are the players that abide by the rules.

To some extent true, but some projects are designed to simply use their own lua and nobody outside the team is equipped or motivated to create superior stable works. If I want to maintain the integrity of my project, I have no issue with a whitelist, though I know it can be circumvented, that puts the responsibility of offering the best lua on me and in turn leads to a better product.

[dizekat]

I am just saying we should address the missing functionality on the gadget side of things. It doesn't matter what they want to try and do, it is their business. I may not like argh or caydr, I might think that it is a wasted effort because cheaters will find a way. However, there was a constructive conversation going which was starting to actually make notes of a few actual issues with the lua implimentation.

Good job though, because insulting people's work on a grounds of popularity really makes a strong argument.Attacking anyone's work as a ground to denounce their arguement is low and frankly inappropriate. It is just weak.

This a bar of soap, clean your mouth.

is it clean now?

Now, wash the soap out your mouth and come back with something real or put the bar back in your mouth.

I'm not insulting you on grounds of popularity. I just find it fairly stupid how people request features that are only somewhat important for starcraft or world of warcraft level of popularity (and in fact even on such level of popularity the point would be moot because it is very easy to patch spring itself to cheat). At the low popularity level, instead, you should rather think how NOT to turn players away, for a change!

I didn't say, or even imply that low popularity means that work sucks - that's your own view by the way.

[Caydr]

Whatever the solution, I hope one is reached before this becomes out of control. Up to now we've been lucky since there's not a lot of malicious users. Or rather, not a lot of malicious users with the intelligence to do anything besides spamming in spec and d-gunning allies. Please work together to find a way to make this game safe for 95% of the players, not the 5% who will get away with cheating no matter what. I think perhaps you are overthinking things a little, trying to invent "perfect" cryptography, but that's not what this is about, it's about a reasonable measure of safety so that the majority can play without fear of getting cheesed.

I'll respond only to FA since I realize this discussion is too high-level for me at this point.

Banning widgets or using a whitelist is pretty stupid. The only people who get hurt are the players that abide by the rules.

A whitelist is not necessarily going to only contain the 3 most popular widgets. If whitelisting were possible, I would take a week, go through every LUA ever made, and add all but the ones which are redundant or which I felt would make the game extremely unfair to a player who was not using the widget. For instance, anything that allows you to perform actions more quickly and precisely than a human with uber-micro.

Ease of use is great, auto-dgunning and auto-build-cancelling is a crock.

If mod-side gadgets and user-side widgets had identical capability, and user-side could be disabled, I would just include all the best gadgets and disable widgets. I'd even allow the ones that at first glance make me scream newb, because my main concern is a level playing field, not necessarily my vision of an ideal one.

[zwzsg]

A whitelist is not necessarily going to only contain the 3 most popular widgets. If whitelisting were possible, I would take a week, go through every LUA ever made, and add all but the ones which are redundant or which I felt would make the game extremely unfair to a player who was not using the widget.

I think you vastly underestimate the amount of widgets that were created while you were away.