Patch delivery, Sync Problems

[Auswaschbar]

his archives are binary identical, so he must have made something wrong when packaging a not-0.78.2.1 version of spring.

[Argh]

My vote is that it's not quite that simple. For example, the "pre-install" version was binary-identical for all SDZs, but didn't include the /Music directory, which is content external to the SDZs but is called from a Lua script.

Result, if people didn't have the full music installed? Desync. Even if everything else was exactly the same. And the /Music directory isn't even referred to until the game starts. Weird, eh?

I'm pretty much at the point where I think that doing anything but a full install, or going to some sort of auto-update system, is the only way to go. I don't know how to build an auto-update system, though, so I guess I'm stuck in the Dark Ages for now.

[imbaczek]

it's a problem with archive scanner i guess, it only knows about two kinds of archives - mod and map - and both types change respective checksums. there should probably be a third type, unsynced data, which won't be included in checksumming. (IIRC that idea has been talked about circa a year ago...)

[BrainDamage]

springignore.txt is a list of regex of paths to not scan for checksum
EDIT: changed file to path and fixed grammar

[lurker]

Result, if people didn't have the full music installed? Desync. Even if everything else was exactly the same. And the /Music directory isn't even referred to until the game starts. Weird, eh?

Did you test this? Add a music folder and nothing else and the sync fixed?

[Argh]

Did you test this? Add a music folder and nothing else and the sync fixed?

Eman did, said that resolved things.

Meh, it's fine, once people have upgraded /Music to current, it's probably not going to change for awhile. Just one of the little things that are aggravating, I'm tired of seeing stuff go off the rails for end-users because I broke things up, and tbh it's a pain in the ass maintaining it all.

I'm starting to think that the all-SDD route is the only way that's really workable, long term. Having to re-download giant archives because I change one tiny thing sucks for end-users. Up until this point, it's not "one tiny thing", so it's justifiable, but it's getting close to that point now.

I'll look into deploying SVN on my dev box when I get home, I think it's time to finally tackle that and just send out packages that just contain the changed files (and their directories) in a zip archive or an installer package for Windows users.

[lurker]

Have any replays of such a desync?

[Argh]

Of course not, the desync's before the game can start, in the Lobby. Meh, it's resolved at this point anyhow, once Eman found the problem.

[lurker]

That's more or less impossible to be the cause; can you replicate it just by changing what oggs are in that folder?

[Argh]

He said he got them to, "install all of the music", whatever that meant. IDK whether that was the full bare-bones or what. It's irrelevant anyhow, whatever solution I go for next is going to need to concentrate on smaller updates and some sort of version control system, so that I'm not having to make people download large files over and over again.

I think SDD + SVN on dev box might be an acceptable way to do it for beta, but after all of the other mysterious desync issues, I'm a little bit wary of the whole thing. Among other problems, I'd have to maintain very tight versioning to successfully bring maintenance forward (which is a pain because of dependencies, which other games aren't worrying about yet, because they aren't following the "ideal model" I have used, to clearly identify / separate content and code), including deleting people's previous versions, so that there isn't endless confusion about what version of the game we're playing today.

No professional game would dare have 50 different versions of their game floating around, confusing their customers. This issue's really annoying me. I can't win no matter which way I go.

If I go SDD, then I may see people unable to sync on a regular basis, because they aren't applying updates on a regular basis and are maybe doing it out of order, etc., etc. Their "version number" will be "correct", since that's a string in a text file, not a true measurement of anything, and they'll bitch (rightly) that I'm screwing up. Not good.

If I stay with SDZ, then I end up continuing to waste massive amounts of time on each build (pushing out multiple installers, QA'ing them to make sure they're basically functional, uploading them, waiting on ModDB, etc.). This is a big pain in the ass, wastes valuable time, is stressful, and there are invariably screwups, because I'm just one guy, and I can't possibly QA everything perfectly.

Both options suck. I need something that ensures that when people play the game, they get the current version, with up-to-the-minute revisions, and in a way that's not clunky, confusing, or requires following complex directions or knowing how to mess with the innards of Spring. It should not leave previous versions of the game around to confuse end-users, either, that's unprofessional.

It's increasingly clear to me that we need some sort of real push-install to force update stuff, like Steam uses, either built into Lobby clients (so that I can basically just push out an update, players log on, have the game, get update without having to do anything) or a custom solution specifically for P.U.R.E. and World Builder (assuming that once other projects figure out how to integrate the Editor / SDK, it doesn't get forked like crazy, which I don't really see happening atm, and may not happen at all, since there's little profit to be had from a fork when if you just want more content, add it as another dependency, have a nice day).

I don't have a solution for any of this- hell, I don't even have the time to develop one atm, I need to work on SP missions immediately, to get the game finished. But basically, I don't think we have a good solution atm.

CA's updater just basically grabs you the latest SDZs. Not useful, for something that's 200MB every time right now- and that's the smallest it's ever going to get, I can't really emphasize that enough tbh. Forb's solution, at least the last time I tested it, was too rough and wasn't automated enough. These were both attempts to solve these problems, and they're not terrible, they're just not something you expect at a really professional level.

I need something that basically checks version numbers, checks a location on my server for the latest one available, and then performs any updates between X and Y, in order, and is entirely dummy-proof and automated (maybe using snapshots of the hashes at each release, and if none match, re-download 1.0, start from scratch?). No users should ever be using 1.0, unless they're saving the SDDs somewhere as backups. There has to be a good way to do this, I just don't know what it looks like yet, or how to implement it. But I think it's the only way to reconcile Spring's sync system with the nature of updates, in a serious game where content is a major load.

[lurker]

He said he got them to, "install all of the music", whatever that meant. IDK whether that was the full bare-bones or what.

You need to be clearer when you're just guessing.

If I go SDD, then I may see people unable to sync on a regular basis, because they aren't applying updates on a regular basis and are maybe doing it out of order, etc., etc. Their "version number" will be "correct", since that's a string in a text file, not a true measurement of anything, and they'll bitch (rightly) that I'm screwing up. Not good.

If I stay with SDZ, then I end up continuing to waste massive amounts of time on each build (pushing out multiple installers, QA'ing them to make sure they're basically functional, uploading them, waiting on ModDB, etc.). This is a big pain in the ass, wastes valuable time, is stressful, and there are invariably screwups, because I'm just one guy, and I can't possibly QA everything perfectly.

What do you mean? You need to do QA on plain SDDs just as much, and SVN doesn't work at all when you want to sync, beyond just being slow.

CA's updater just basically grabs you the latest SDZs.

Don't make things up. It grabs every tiny little file in the mod that changed and puts it all in a zip. CA's 75MB. Put half the effort of writing your post into researching it.

[det]

CA's update system is designed for incremental updates. It is a very simple system that only downloads an index file and any changed files that you don't have. The size of the index file is about 28 bytes per file in your mod.

PS. did you really think people downloaded 75MB every new commit o_O

[SpliFF]

Actually that's exactly what I thought. I'm just used to multi-MB downloads taking under a minute on 1.5Mb/s DSL. It's good to see it does things the "right way". If it isn't too OT could someone point me to some doco on what steps I need to make my mod fully compatible with the downloader (ie, does it only work the way described for CA or for all mods/maps?). Also does anyone know if SpringLobbys downloader works incrementally as well?

[hoijui]

In the beginning, the CA downloader was a separate program. then it got osmehow remodelled to be a spring engine tool, and the CA part was thereafter only a module (as it is now). I would like it too is it were rather a mod incremental downloader, and therein would support incremental downloads of various mods. Thing is just.. that its hte CA teams work, and they possibly want the too keep at least the (already reduced) credit they have for it now. So maybe it would have to be called the "CA incremental mod downloader", and CA always beeing at the first place in hte list of mods or so...
You should negotiate with the CA guys is the usefull part of what i have to say

[koshi]

Also does anyone know if SpringLobbys downloader works incrementally as well?

No it does not. It's a client for the torrent system, not the CA updater.

[BrainDamage]

You need to do QA on plain SDDs just as much, and SVN doesn't work at all when you want to sync, beyond just being slow.

it actually syncs if you filter out .svn folders using springignore.txt and you add a dummy file in the main .sdd folder to touch on every commit to trigger an hash refresh

but that's nothing for any production system imo

[Argh]

CA's update system is designed for incremental updates. It is a very simple system that only downloads an index file and any changed files that you don't have. The size of the index file is about 28 bytes per file in your mod.

Okie doke, so that's changed since the last time I messed with it. It's been awhile, and I tend to just get the latest stables from JJ anyhow.

I'll look at CA's system, see whether it's worth negotiating over, or whether I should use a commercial software-update system. I found several yesterday, but I haven't had time to test them and see what I'd get for my investment (none of them are free)... and none of them would support Linux users.

[det]

Okie doke, so that's changed since the last time I messed with it. It's been awhile, and I tend to just get the latest stables from JJ anyhow.

No, it never grabbed the whole sdz on every update.

[Argh]

I admit ignorance, I shall test it, and move from there.

[Argh]

Ok, done with testing.

Seems to me that I could maintain the game using a P.U.R.E. module for the SpringDownloader system and appropriate resources on the Web. So, if the maintainers would like to talk about integrating such a thing into the downloader, let's talk about that via pm.