Spring RTS Engine

Argh wrote:available

check.

Argh wrote:released

check.

Argh wrote:players

check.

are you aware I've had a version working very well for over a year?
it was only pulled from the production server because of a bug relating to a ton of concurrent users I hadn't previously encountered.

anyway, much further and I'll need to split this.

Orly? So it's the official server finally? I'm aware you've had a "working version", but that's like saying that P.U.R.E. 1.3 is "available" because I'm playing the still-very-buggy dev builds by myself over here.

At any rate, that's a side issue. My point is "why are you so down on solving this problem"?

Argh wrote:At any rate, that's a side issue. My point is "why are you so down on solving this problem"?

I'm only pointing out gaping flaws where they exist.
I don't consider it a solution if I can permanently nullify it in a matter of minutes.

Argh wrote:Software that's available and released and has players

Ehhh what's your lobby server's address again? I'd like to confirm this claim...

Meh. Steam works on fairly similar principles, in terms of anti-cheat. The only major difference is that they have a server-client model, where the server can be the final arbiter of what's real.

So, given that changing that isn't in the cards, how can clients form a secure connection to each other, and verify that each of the other clients is also genuine?

They can't.

The only major difference is that they have a server-client model, where the server can be the final arbiter of what's real.

Spring also has a server-client model. "Desync" means out of sync in relation to the server. The real major difference is that Spring clients locally simulate everything.

But clients for things like IM have to do these sorts of things, to prevent certain types of attacks, invasion-of-privacy, etc.

Surely there are ways.

IRC is famously prone to various spoofing and related attacks. MSN...well I get about 10 msn messages a day that are not actually from the relevant contacts. Et cetera.

That's the whole fun thing about absolute security. There's no such thing.

IRC is ancient, and wasn't designed for security.

And spam isn't the same as cheating, it's just abuse of a feature.

So... lemme put it another way. If the host is the server, then is the issue that the server has no way to determine if clients are doing something spurious? Could this be addressed by checking some basic things?

I mean... what are people going to do with executable-side hacks?

1. See everybody else, no LOS.

2. Give themselves additional resources.

3. Make their units invulnerable.

They're not likely to hack Lua-side stuff. They're going to do the things that will let them win.

ah, I see. you missed the memo saying only unit orders are transmitted and most cheats are impossible to transmit to other clients.

If the host is the server, then is the issue that the server has no way to determine if clients are doing something spurious?

Yes, when the spurious doings are in unsynced code. Synced code cannot be tampered with.

I mean... what are people going to do with executable-side hacks?

1. See everybody else, no LOS.

2. Give themselves additional resources.

3. Make their units invulnerable.

1. Yes
2. No
3. No

LOS is unsynced?

Why?

RENDERING is unsynced.

LOS is not unsynced. Each client just has all the data of which allyteam can see what. You can exploit that without breaking sync.

Argh wrote:LOS is unsynced?

uh, you can read from memory without changing it... LOS is in memory...

Each client just has all the data of which allyteam can see what. You can exploit that without breaking sync.

Ah. So the host doesn't transmit that to the other clients, keeping everybody in the dark about changes until the next update? Hmm.

That LOS proposal I put out would make it fairly painless to quit allowing that.

Clients would then just have the local state of their AllyTeams, because it would be a very small piece of data.

you don't really know how spring works... anything other than the current system would require a major rewrite and have side effects.

You're certainly right, I have no idea how the netcode works. I would have assumed that sending an updated LOS list (since my proposal is to get rid of the LOS map entirely) would be trivial. It's just a series of UnitIDs, after all.

Then LOS would be whatever the host says it is, basically. Not really complicated.

That would make absolutely no difference in this context. Wouldn't matter if Michael Jackson descended from the heavens to hand-deliver the los data to each client, when the client can simply choose to render units that aren't in los.

But the client wouldn't know what unitIDs were in use, other than the ones that are yours or are in that LOS list.

Makes it a bit harder, if clients really don't have the same data that the host does.