Dr Brain

The code.

Can someone change the title from (its back) to (it was back, but now its gone again)? Thanks.

This isn't a forum skin, but it's a pretty neat app to help with the "eye-searing" you get late at night. http://stereopsis.com/flux/

Because they (historically) have destroyed flagging for everyone. No one has come up with a clever solution yet, so we've stuck to the 2 flagging freq alternative.

I agree with Lynx, completely. This is a $300,000 job (~1 man year at $150/hr) to develop a game where the community is largely opposed to any sort of capitalization. Lets be honest, most of the people that play this game only play because it's free. If you make $5 a box/download (not the end price, but the amount the company makes after expenses, such as hosting servers) then you'd have to sell sixty thousand copies to even get your original investment back. SubSpace *might* have as many as 60k players at the moment, but most of those wouldn't switch, especially if it cost them hard earned money to do so. I don't think it's realistic to approach this from a "lets make some money" perspective, because there's no good way to do it. The best you can hope for is someone to finish a client for the love of the game. We've got a couple of people building clients with that in mind, and all we can do is pray that their love sustains them through to the end of the grueling process that is game development.

My point stands, it's not the bomb level. A casual reader might assume bomb level from reading through your otherwise detailed post.

And remember, the shrapnel level is taken from the gun level, not the bomb level.

I'm not much of a console expert, but I'd think without any way to chat the game loses its most important feature.

1 tile is 16 pixels. You can get a good approximation of the ship radii using that. There are complete copies of HS's settings around this forum, but I can't be bothered to find a link at the moment.

I think it had to do with speccing so many players at once. It exposed race conditions or some such. It was a long time ago and I don't really remember. To be honest I don't actually remember removing the module.

Prove to us that it can be done. Take a basic zone with publicly available settings (like Chaos) and make an infantry version, changing as little as humanly possible. You probably don't need to spend much time on the map (I'm presuming it can be done if one takes the time to do it), but everything else should be duplicated. The things you can't duplicate will dictate how likely people are to move.

A bit array is more compact than a byte array, but it may not be faster since you'll have to do bit operations to get the tile you want. Of course there's all sorts of cache considerations that reverse this conclusion, but I figured the simpler data structure (programatically) was still the best one. map[j] is connected to map[i+1][j], map[i-1][j], map[j+1], map[j-1], with appropriate edge of map detection. What more do you need than this?

I think a quadtree is the most obvious for accessing local tiles quickly. Though to be perfectly honest, a fully populated 1024x1024 byte array would only consume 1MB. Not really a bad way to go in this age of 4GB memory being standard on new computers. I don't think any other data structure will be faster than this.

You've doubled the complexity. sendToHost and sendToChat have no commonality as they use entirely different protocols. You've also doubled the number of servers that have to be run.

Sounds like a huge step backwards. Put the frequently used commands in a GUI, of course, but don't make them impossible to use through typing. Commands are the easiest way to do complex server interaction.

Doesn't seem much point in having the server not handle chat. It's probably 1% of the packets that it handles, and the clients still need to send ?commands to the server. So a lot of extra complexity with very little gain. Still, that doesn't mean you can't integrate some external chat with the game. I think that makes a lot of sense if you do it on the server and not the client.

Either there's a setting that controls it client side (and I've forgotten it exists), or you've got some other issue, like position packet routing distance. Probably just up the routing distance to maximum (Net:PositionExtraPixels=16384). It won't hurt for a small zone.

What's the problem? EG faced a very technical problem, one which I believe they sorted out with help from Grelminar.

You can install a 32-bit version of linux in a virtual machine (like VirtualBox) and compile your 32-bit modules there.

Looks like you're compiling a 64-bit module for a 32-bit zone. Try adding -m32 to your CFLAGS in the makefile. This will likely cause you to see all kinds of missing dependencies. You may be better off trying to run a 64-bit zone.

The only reason the game is still going is that there's limited centralized leadership.

I agree that security through obscurity isn't a wonderful solution. However, it is my opinion that none of the other methods for security will work for a true SS replacement. Server side checking works fine for quake and others because it has a much lower player limit than any SS zone, so the burden isn't excessive. Perhaps Moore's law has brought us to the point where server side checking is feasible, but somehow I doubt we're there yet.

You'll note I didn't say it's the only way or even the best way (though I personally do believe it is both). I simply pointed out (in response to kylratix's assertion that it's proven to fail) that it has worked in the past.

I think there's an item loaded callback in hscore_database. If not there should be.

Security through obscurity has worked for the past 12 years.