Hakaku

Clearly it was the work of aliens.

Grav, what L.C. just said was that you don't need to convert them; he already provided the necessary graphics in .bm2 format (which coincides with what I had written earlier - I hadn't actually checked the contents of his zip), the rest are perfectly fine in .png format and will be loaded by Continuum.

I think it depends on the specific graphic, since I know I've encountered this problem before. For example, Continuum will read the background images fine if they're in png, but it will refuse to load shipsets if they're using pngs (or was it bmp's, or both?). You don't really need to convert them per se, just rename the file extension to preferably .bm2.

Why would you compress settings in a lvz file? Continuum already ignores extra settings, so that's not really an issue at all. For Subgame2 support, I think Discretion should only implement the protocol, and let the server implement the extra settings (e.g. maxships = 8, etc) for Discretion to handle. That, or have the settings default on the same ones as Continuum if the particular setting doesn't exist, kind of like how ASSS does it.

That's pretty awesome. I noticed that the support is similar to that of ASSS, which makes it ideal for doxygen. Perhaps this could also be of use to someone (html + latex).Discretion complete documentation.rar

I noted it a long time ago, and I think Doc Flabby even included a copy of the directory protocol page along with his directory server. Interesting read, but it's all still giberish to me

The download stays stuck at 0% :/

If you want a new design that pressingly, try dropping larrythehamster a note.

It was a very basic summary. In the end, the files were removed and the members of team A split in three different directions which reflected each of their personal views on the matter, while team B remained status quo. No matter how it's worded it'll remain subjective. And you laugh that it could have been avoided with better communication, yet you are the ones who opted not to go down this path. I'm not really sure how either team could have 'better planned' the situation, it wasn't even planned in the first place, it was just done. This is kind of redundant with the entire thread discussed already.

team A builds script, downloads all files from ssdl. ssdl server goes down 3 hours. bandwidth go boom. team B gets mad. A & B falconpunch each other. team A loses, runs away. team C says chillax. team A comes back. everyone happy happy.

lolz drama, everyone likes to take the quick way out it seems.

Thing is, you can't really say that open discourse wasn't attempted before. For anyone who doesn't remember, refer to this.

Although I know I'm not contributing to the issue by adding this, but you can reduce the filesize much more if you don't use basic .zip compression. .rar (+best compression method) is a step up, but 7-Zip would be much better suited for such things.

The sad thing in my opinion is that the worse and repeat offenders are always the ones that have their bans reduced and removed, mostly because they know how to guilt trip operators. It's sad. And in light of that, I would definitely vote in favour of removing all existing netbans.

Hi, welcome to SubSpace and thanks for posting. Unfortunately sometimes people will wind up caught under someone else's ban, as is your case. Like the message says, it would be best for you to go over to http://bang.subspaceonline.com/ and submit a new ticket with exactly what you wrote here, and selecting the option "caught in ban". Hopefully an operator shouldn't be too long.

There seems to be some confusion. The idea of a proxy, a (bridged) biller, or a bridged layer as I worded it earlier are all essentially the same thing. The only difference between the proxy and the biller part is that the proxy wouldn't have an independant banning or user authentication system, and it would also lack the ability of collecting scores among other information. The proxy would also not seek to potentially be a replacement to the current biller. But they all function on the same principle that an intermediate application would act as a relay between the SSC biller and zones connected via this proxy by using the zone<->biller UDP protocol. It's possible, and was accomplished, but issues arose that hindered its/their continued development and adoption.

No you misread. I never said anyone had to switch to ASSS. In fact, I actually discourage the new ASSS billing protocol, but that's really aside the point. I said that in the same way Grelminar didn't come around expecting every single zone owner of SubSpace to switch to his server, you shouldn't expect every zone owner to adopt your biller. You should be following ASSS as a model, and allow people to decide whether or not they want to switch. ASSS didn't start with Hyperspace nor Hockey Zone, it started with mere development zones. Eventually people started adopting it for small zones, which has over time attracted more fledged out zones based on the results of the pioneers of this server. Most people prefer seeing a result and contributing ideas for improvements before jumping into something they know nothing about. And I never stated Snrrrub was the only person developing a biller. But I did state that you left the biller development in the hands of one person. The fact that there was 1, 2, or even 8 different projects going on is of no importance to me. But each of them were developped by one person, and given up upon by that same person. The first example of this, before the new biller campaign restarted, was CypherJF's biller. Snrrrub was, in the end, the only person who actually presented a somewhat finished project, but he ended up disappearing like the rest of em. I don't care for what reason, but the problem with all of these projects was that they were kept closed source, which in terms of SubSpace, spells unmaintainable disaster. Anyhow, you can keep stating that I only know what I hear, but you shouldn't dismiss my arguments simply because I disagree with you and your interpretation on matters. I'm not actually as blind about things as you like to make yourself believe.

That's a poor excuse, you're almost assuming that all these sysops were in favour to switching billers. For that matter, your logic is flawed. The point of making a bridged layer was so that any zone would be able to connect without having to wait around and going through Priit, and possibly eventually act as a medium to deprecate the current biller. You can't even realistically expect zones like Trench Wars to be the first ones to switch, especially if you've barely tested and debugged such a biller. Not only that, but you weren't actually providing these zones with a better product, you were just trying to instill them that it was more feature bloated without actually showing anyone any results. To also note, you left the bridged biller development in the hands of one person, who as I already told you from the start, was going to leave anyways; basically a parallel to repeating history. The arguments here are really going back in circles with the previous thread. You should never have to need everyone to forceably agree to switch, for the same reason that not all zones need ASSS for their purposes, and we shouldn't be cut-dry and shoving it down their throats unless they're willing. That, however, should be no reason to give up on matters.

Welcome to the wonderful world of SubSpace. :/

B.A. spécialisé approfondi en traduction anglais-français aka Translation

Priit Kasesalu. You can find him somewhere here. He now works here.

Ah, well I never really went so far as to use absolutely no map to trigger the 'emergency map' (aka tinymap.lvl). If you want to modify that, then it can be found in src/core/mapnewsdl.c, but map data is gibberish to me: if (!data) { /* emergency hardcoded map: */ byte emergencymap[] = { 0x2a, 0x74, 0x69, 0x6e, 0x79, 0x6d, 0x61, 0x70, 0x2e, 0x6c, 0x76, 0x6c, 0x00, 0x00, 0x00, 0x00, 0x00, 0x78, 0x9c, 0x63, 0x60, 0x60, 0x60, 0x04, 0x00, 0x00, 0x05, 0x00, 0x02 }; lm->LogA(L_WARN, "mapnewsdl", arena, "can't load level file, falling back to tinymap.lvl"); data = amalloc(sizeof(*data)); data->checksum = 0x5643ef8a; data->uncmplen = 4; data->cmplen = sizeof(emergencymap); data->cmpmap = amalloc(sizeof(emergencymap)); memcpy(data->cmpmap, emergencymap, sizeof(emergencymap)); astrncpy(data->filename, "tinymap.lvl", sizeof(data->filename)); }

I disagree with this since you're basically granting another SSC monopoly. The client should be connecting to the zone first, then requesting the appropriate authentication server information for validation. As a zone owner, I want to be able to have the freedom to choose the authentication server I want to, just as I choose the biller. If your authserver ever happens to get hacked, I would appreciate a way to opt out of its service.

http://forums.minegoboom.com/viewtopic.php?t=8304 No, you can only include entire files. Note, however, that the last occurence of a certain setting in a file will be used. So you could include an entire settings file from a different arena, then append the rest of the modifications you need for your new arena (this is currently what's already done when you change arena settings in-game or create a new arena). I don't understand. In what context do you need to use return/enter characters? No, smallmap.lvl is in your map folder. I'm not really sure what tile you're talking about because it's not there for me.