Spring RTS Engine

Forboding Angel wrote:http://www.hiverise.com

I saw this earlier... Does it have a solution to what I mentioned above?

I read in another post that spring can resync a game by playing it forward again from scratch. It seems like this is a good and bad thing. Are there any technical constraints preventing the state information itself from being transmitted to all the clients by the host? E.g. If you have 2 MiB of stat...

Playing in shifts... now if only Spring were compatible with the Microsoft touch table. :)

What an interesting 'board game' that would be.

HeavyLancer wrote:My unethical proposal:

They're actually playing BA DSD.

lmao. Off to watch that movie.

Original poster: Spring > SC2... no reason to bring down the average.

What's the largest battle to date?

I just noticed on the about page that spring supports 250 players. The idea of a persistent battle spanning days with 100+ people is pretty awesome :)

I'm on Linux. Linux rules. [Though it might also be vulnerable.] I don't see why scripts would be denied access to the file system. The trick is to make sure that there is a proper mechanism for pre-emption. This can be accomplished by removing or modifying the traditional file access API in Lua so...

Your on the right track, however I propose a slightly different idea. The server would act as a master copy of the simulation and all clients would sync to that master copy. If a de-sync occurs, you transfer every bit of the simulation to that particular client with the game paused for the duration ...

I got another idea too: At start of the game, the map has no metal at all (or very little), but it will start grow while playing, and it grows faster in the areas where there is more metal. So it is like tiberian grow in C&C or ore grow in C&C RA If there is also a corresponding surface def...

I like this idea :) But it should be an optional tag and not always enabled for metal maps. It reminds me of the Startrek Armada series with it's 'regular' dilithium moons and the 'infinite' moons (with the infinite moons being much less likely than the regular kind). Mabye this could be added as a ...

Has anyone noticed how the terrain can do weird things on maps like SpeedyMetal when the hardness is <100 on the map? For example, a nuke will hit a part of the map and make a very deep crater, and at the same time make the rim of the crater VERY high. Its even more noticable when a commander exploa...

Wouldn't moving the sweetspot around via script fix that second problem? That's if spring makes use of the sweetspot, of course. As for the first.....hitboxes would be amazing. If you're feeling really fancy, locational damage would be mind blowing >_> Locational Damage + Mech IK = Awsome Imagine a...

PauloMorfeo wrote:Problems:
- A distribution of Linux usually is made to last some time. People won't bother to download (much less install) a new version of the OS every month.

You could release diffs of the ISO. It dosen't have to be big either, knoppix can be torn down and become very small.

Anyone could easily intercept this by figuring out what each function is supposed to hash to, then intercepting the message when its received and sending the correct number. Building a 100% effective anticheat measure is impossible . I mean, look at what happened with Quake 3 and punkbuster thereaf...

In an in game situation with more than 2 players, we could just check whose machine has the changes and only resync their machine, which will probably be the cheaters machine if a cheater is present, thus any changes the cheater make have to be done over and over and dont affect the game state on t...

how will you check binaries on other architectures or operating systems? Or will you include a list of allowed checksums (making spoofing very easy of course) which is used by the host to allow/disallow clients? Perhaps there could be an authentication server which stores checksums of parts of the ...

I started to play around with some of the code that I mentioned above. It turns out that the way VC8 compiles my demo app, the following happens: void main(...) { void *p = func; _asm { call p // goes to correct function } //p != actual location of func, it points to a jmp <relative address> which t...

Anyone could easily intercept this by figuring out what each function is supposed to hash to, then intercepting the message when its received and sending the correct number. Building a 100% effective anticheat measure is impossible . I mean, look at what happened with Quake 3 and punkbuster thereaf...

as you already say, commenting out a few lines of code and recompiling would break your measures... anyone can always spoof the md5sum message after all... Submitting memory for peer-review might work better. You could scan specific functions with a runtime disassembler for obvious breaks in code. ...

You could at least stem the tide of most cheats by doing a checksum on the executable itself in realtime. Open a handle to the executable and feed it into an md5 hash function. The tricky part would be identifying whether or not the checksum was calculated on the executable being run, instead of one...

Couldn't you structure the 'synced' data in such a way that it periodically takes a checksum of certain parts of the game state? This is slightly different than what goes on at the moment. That way, clients would exchange checksums to determine who caused the game to desync. Then only that particula...