Grelminar

I was in Verboten too! And The Long Patrol before that, for a very short time. I think I only played one or two league games, if even that. I wasn't much good except maybe as a defender. I do recognize a lot of names here, even though I haven't played SS at all in a few years. I still have a lot of old files, including a zip file with 50 old aswz maps (though many are similar). I attached it here. aswz-maps.zip

Based on the preliminary results, it's obvious that "all versions" is the most popular. But all those people who voted "all versions" have an opinion that they didn't indicate with their first vote: if they were forced to pick one single version, which would it be? The modified poll reveals this opinion.

Nobody's mentioned lag comas for months, so I !@#$%^&*umed it wasn't a big problem anymore. When was the most recent time you (or anyone else) observed it happening? Anyway, lag comas are just a bug, not a fundamental feature of the design. A tricky bug, to be sure, but something that will be fixed. Edit: I just looked at the relevant code again (after not thinking about it for months), and realized that I'm doing something really dumb. I think fixing the dumbness might go a long way toward fixing lag comas. I'll try to do it this weekend.

This would be much more helpful if the "all versions" option wasn't there. It might be possible to support more than one version at once, but I really really really don't want to do it. So assume the decision is between .38 and .39pr1 for now.

I'm a little confused. I've seen the !@#$%^&*ertion repeated that "!@#$%^&*s can't support large zones", but nobody's explained why. Perhaps it's not the easiest piece of software to configure although I could argue it's no harder than subgame, it's just that people are used to subgame). But that's not really a problem for larger zones, just small ones with limited staff and expertise. I think the main reason large zones haven't adopted it is because they've invested a lot of time in their bots and their current serving infrastructure, and it would be too much effort to switch. That's a valid reason, although I should point out that recent releases include a "sgcompat" module that should allow most bots to work with no modification. If I'm wrong about the reason, though, I'd appreciate if someone actually told me, so that perhaps I could help address it.

Sounds like good progress. Coding around fatal flaws is always a bad idea I was wondering how you were going to do the periodic flag reward stuff. Will it be based on the existing periodic module, or something else? I'm curious mostly because, as you might have heard, I'm completely rewriting the flags code, and the interface will be somewhat different. It's relatively easy to port stuff (at least the stuff I've ported), but will take some effort. You can see a preview of the interface at http://sscx.net/!@#$%^&*s/flagcore.h . The good news is that this will allow all sorts of new flag games (like real ctf), and also fix a bunch of bugs in the old flag stuff.

ASSS has a built-in game recorder. it's far from perfect (doesn't record flags or balls yet), but it gets the basic parts of a game.

I thought the last two (Foundation's Edge, and Foundation and Earth) were probably the best, not so much for their characters or style, but for the sheer coolness of the ideas he put in them. Of course, ideas are the only reason to read Asimov in the first place, so you'll probably like them.

The PNG format is actually quite flexible: it's easy to embed arbitrary data in a PNG file (in a new chunk type) and have it still be compatible with all programs. You'd have to make a special program to do the embedding of the tileset into the level file, though.

Re: new protocol features. I've come up with some, mainly new game features, and suggested them to Priit. I don't think any of the significant ones have been implemented in cont yet. He's also suggested some, mainly bandwidth reduction things. I haven't implemented these yet, primarily because there wasn't a good way of evaluating the benefit of any new scheme that we might come up with. Since then, I've written some load generating programs, and added some more measurement stuff to ASSS. I'll need to write some more measurement stuff, so I can get a better idea of typical traffic, and then implementing and evaluating some of these ideas will be possible.

Re: lag measurement. This is pretty hard, and requires cooperation between the client and server, especially because most of the traffic is in unreliable packets. Currently, cont does some work, and ASSS does a little more, but I didn't put that much effort into lag measurement in ASSS (yet). I just got it "good enough" to figure out some averaged ping and ploss values, and then spent more time on penalties you can enforce based on those numbers. There's room for more work there, but to make it much better, I'd need cont to measure and report more detail than it does now.

I never said anything about his skills. I just implied that he was asking too many questions. Mr. Ekted's analogy is good, but in this situation, there's no easy engineering course someone could point him to. Instead, there's the way everyone else learned the answers to the stuff he's asking: experimentation, packet sniffing, reverse engineering. That stuff is the easy part of writing something like what's he's attempting to write. If he can't do that on his own without help from 10 people on message boards, that's probably a sign that he's got a lot to learn first. I have no problem encouraging people doing productive things, and giving them help when necessary. But in this case it's pretty obvious to me that he's in over his head, and nothing will come out of this project.

Better yet, why don't you try doing some actual work on your own, rather than asking anyone who will listen to you about every little problem you come up against?

Unofficial (i.e., not standardized by some RFC) mime subtypes are supposed to use a prefix of "x-". And although periods are now allowed, they weren't always, so its probably better to use dashes. So I'd go with "application/x-subspace-lvl" and "application/x-subspace-lvz".

Tunneling the actual game protocol through HTTP, while technically possible, would create something so laggy that it would be impossible to play, or even to spectate effectively. And it would certainly take much more than a half hour to implement.