Dr Brain

Couldn't have put it better myself. No one is willing to put in the time to code new modules. Either take the league as it is, or don't. No one is forcing you to play.

That's your complaint? That unofficial HS 1v1 duel rules are not being applied to official 4v4 duels?

There's a major difference in trust between allowing a ref access to ?lockship and ?grantitem.

I haven't changed anything in the main arena since the ?flagging freqs.

If you find it easy, please make it.

Complaining about it won't make any difference in how the match runs. Your best bet is to figure out how to counter people using items, and how to use items to your advantage. It's not like you don't have access to thors too. Don't forget, though, that there will be no restocking during play, so a lot of "lame" tactics used during basing will be more difficult to perform. I also assume players will be locked into a single ship during each half, though I haven't checked that with ipwn.

The server only controls greens that come after death. The other ones are completely client side. It would be technically possible to repeatedly kill a fake player in the field, but that has other complications associated with it, such as the fact that the death packet does not include position. That puts a limit on how quickly the greens can be distributed in the field. That said, there really isn't any benefit to a green dropper. Any effect available in a green is available as part of a *prize packet. Shields and super, however, aren't terribly useful effects for a field. Super has a random duration (one that includes 0 time), and shields are similarly hard to manipulate into a useful effect. The other prizes, such as thrust, have to be deprized afterward, which is really the crux of the issue. It's pretty straightforward to debuff with engine shutdown, but that's not the topic of this thread.

Repels, bursts and thors are available to practically all participants. Players can choose to play without them, but that is their choice. If the cost of a few special items is beyond your means, omni, then I'm sure we could look into starting a repel charity fund.

Sounds like fun. Make sure you post match times on the forums so spectators like me can watch.

The point was that ANYONE can do that with basically no work. Testtube needs to change it if he doesn't want it to happen again.

Yeah, pretty much impossible to implement, unless we take away one level of bullets, or something crazy like that.

I listen to him because I agree with his principles, and I like to hear his opinions on the news of the day. I don't listen to him because of who he is as a person, so attacking that has no meaning to me, and I will not waste my effort to defend it. Since apparently this thread is about who he is as a person, I will no longer be contributing.

I'm not denying that it happens. I'm denying that it's a significant percentage of the community's programmers.

How so? For every whining quitter on the forums, there are 10 more actually doing something useful.

2% of the game is about inter-zone relations, which the SSC regulates. If the programmers can't find something to do with the other 98%, then they're really not trying.

I offered to make a new distributed billing framework for the SSC, but was basically told that it wouldn't get used. So it ended there for me.

BS Computer Engineering MS Electrical Engineering

Again, you attack the person?

http://asss.minegoboom.com/ is a copy of the asss.yi.org site. It's as good as anything else.

In that case, it takes an act of God.

I love how everyone on the left can't contradict our ideas, so the have to resort to trying to destroying the person conveying those ideas. To reply to your quote: he rails against international bodies, yes, but that quote fails to mention that he also rails against the failing US court systems. Further digging reveals that the domain doesn't have any direct contact information associated with it. That could be the reason it was submitted to the WIPO instead. It's hard to sue an anonymous person in a civil court (though not impossible, of course). Finally, reading through what they submitted to the WIPO, it seems like it's mostly about protecting their trademark, rather than objecting to the content of the site. There's some complaining about the lack of a clearly defined parody notification, but it seems tacked on.

No.

That really won't protect against a DDoS, since the server still has to process the incoming data. By funneling the requests through the server, DDoS attacks are limited to single zones, and not the entire network. That's why the authentication server's public key needed to be supplied to the client beforehand. A single billing system (distributed, preferably) isn't intrinsically monopolistic.

While your scenario does work, it does have a few drawbacks: Every player can connect to the auth server. This presents a great target for DDoS attacks. Also, neither server is authenticated as part of the process. This is the technique I've had in my mind for a few months: Player sends auth request to game server, including a username and random public key X. Game server forwards request to billing/auth server. Auth server generates reply containing X and a random token Y, and encrypts BOTH with the auth server's private key, and sends it back to the game server. Game server forwards reply to player. Player decrypts X and Y using the auth server's public key (presumably supplied as part of the client). If X is unchanged, the auth server is assumed to be the true one. Player generates hash(password), then generates hash(hash(password)+Y) and sends it to the game server. Game server forwards hash to auth server. Auth server has a copy of hash(password) used in web registration process. It uses this and Y to generate a copy of the received hash. If they match, player is authentic. Auth server tells game server to permit player to enter. To facilitate further secure transactions between the player and the billing/auth server, the following can be done: A symmetric key K can be generated. K is encrypted by the auth server using its private key, then encrypted again using X. This is forwarded to the game server. The game server forwards the mess to the player The player decrypts using its private key. The player then decrypts the result using the auth server's public key. The resulting K can only have come from the auth server, and cannot have been read by anyone else. Key K is used for all further communication between the player and biller/auth server. While the game server is not directly authenticated as part of this, it is assumed that the auth server would not be connected to a rogue server. Either way, no password information is divulged to the server as part of the process. The server has two possible attacks using this setup: It can prematurely disconnect the player from the auth/biller. It can also fail to notify the auth/biller when the player disconnects. Neither attack can do long term damage, as the server cannot spoof communication from either party. The worst I can see is some kind of ?usage exploit. That could be mitigated by a keepalive ping originating from the auth/biller once or twice an hour.

I'd like to wrap up all of my thoughts in a single post: ASSS is not for everyone. There is no short term or long term need for people to switch. I believe it gives developing zones an edge, but I've never advocated it for zones with established populations with no desire to innovate. I do not advocate for people to switch prematurely. A bad experience makes it less likely for them to stay with ASSS, and almost certainly eliminates any possibility of switching at a later date. I do not hold to the belief that Discretion will make ASSS required for all zones. ASSS offers many benefits for long term administration. A good deal of these may not be obvious when first switching. The flexible staff groups, and the modularity are the tip of the iceberg. Some of these features are aimed at players (?|command chaining), some are aimed at staffers (?setcm), and others are aimed at hosts (chrooting, and symlinking binaries into /corebin). It is possible to put config, map and lvz files in the root directory. I do not endorse this, as I feel it will cause significant administration headaches further down the road. Security problems are the most likely. It is possible to put the remaining files into the root directory with only minimal coding. In most cases the change would involve a single line. Again, I feel this will cause significant headaches down the road. People setting up servers are used to organization (e.g. Apache). I do not believe that the fact that /conf/global.conf is not /server.ini is putting any prospective users off. And lets face it, if it is, they're probably not going to benefit from ASSS anyway. Finally, creating a zone is hard work. It's not easy at any step of the way. Balancing settings, creating a map, building a player base, organizing a community, hiring staff, hiring developers, managing developers, finding hosting, finding billing, dealing with players, creating a plan for growth, none of those is easy. If someone is going to crumble at the first step of setting up the server, then chances are they don't have what it takes to build a successful zone. I'm not saying it can't be easier to setup a zone. I'm saying it doesn't matter, since the same people will succeed and fail either way.