Mr Ekted

Sure, but it used to be just LVL file. It was easiest to just make it work the same way for now. This kind of change requires modifications to client AND server. I'm sure PriitK is waiting for new server before he does anything serious to protocol, and frankly this specific idea would be like #500 on my list of important things.

Many keyboards stop sending key codes to the computer when certain combinations are down. For example, on my keyboard I can't hold shift + left + up at the same time, so i can't move, turn and boost at the same time, so I remapped boost to the Z key and use X for bullets in Hockey ZoOne.

I get just as intense/mean as the next guy, sometimes warranted, sometimes not.

Yes, just conforming numpf's statement that I was not talking about CoCo. I have basically no control or say over stuff in Continuum outside of the menu. So in that respect, I don't bother racking my brains. I do, however, look at how SS works and consider what *I* would do if I were to do it myself. It is easy to fall into the "if it can't be perfectly safe, it's not worth doing" mindset. You try to protect/predict/detect every single aspect of play, and if one of them can't be done.... In a twitch game like SS, there are just too many things the client must do locally, even if the server "checks" them afterwards: movement, recharge, damage and death, picking up greens, warping and portalling, etc. Any of these aspects of the game are targets for cheating. Lets say you wanted to "secure" movement. Send all keys to the server, and let the server tell you where you are? Even at 100ms ping, this is unacceptible. It might work on a LAN. Have the server implement physics on its own and compare where you are to where it thinks you should be? This puts a lot of burden on the server. And what is the threshold? Any allowed threshold could still be used effectively by cheaters. And what about false positives? I fly towards a corner tile so that I will miss it by a pixel. The last update my client sends, I have thrusted a bit so I actually hit the tile and bounce. This packet is not received by the server, so when the next packet arrives, I am 64 pixels from where the server thinks I should be, but I have not cheated. 64 pixel tolerance is way more than enough to cheat. So much for securing movement. All other types of cheating/securing have similar arguments. The delays and inaccuracies are prohibitive to reasonable solutions. So if there's going to be ANY insecure stuff in the client, you might as well live with it and spend a serious amount of time obscuring the client a) in ways that minimize hacking risk, and in ways that are easy to mutate if ever a real hack emerges.

Yes I *could* change it easily. But when you give newbies the ability to screw themselves they invariably do it... "Do you see the green text?" "No just purple." "WTF purple?" "Ya just purple and gray." "Sigh. Read each line off to me then and I'll try to help you..."

Not trying to be mean, although it's hard not to. It's so easy for people to come in here and say "open source is the only way" or "obscurity is not security" who have never written a single line of code, or written a game, or have the slightest clue. I would expect someone with a serious idea to actually propose it in detail. I have spent the last several years, on and off, considering ways to protect Subspace better. I have seen nothing yet other than the typical technological rhetoric. The following are NOT serious/valid ideas... - re-do entire protocol for server-authoritative - use RSA/PGP/3DES/blah encryption - open-source the client John Carmack (Quake) himself has given in to the fact that closed-source obscurity is the ONLY solution to "good enough" security in fast-action games. Btw, gravity bombs are kinda cool.

Sounds like you have some app running that is taking focus away from Cont, possibly some instant messenger or toolbar or desktop thingy.

Angel, do you have anything obscure running on your comp that deals with file system? This is just too freaky. I do nothing with temp files. I use the normal windows calls to prompt user for a file, and open the file using fopen(name, "wt"); guest, please post new topics and a new topic.

The langauge? ASM?

Chat window text is currently hard-coded.

Granted CoCo, but Subspace will always be client-authoritative, and Jeffp's/PriitK's solutions are valid and necessary given that. I cracked all of subspace.exe in about 3-4 days. Although I've never tried or looked, I would guess it would take me more than a month to do the same with continuum.exe. I'm not willing to put in the time, but if I did and was able to execute any obvious cheat, it would take a day to change everything. How many people are skilled/malicious/persistent enough to spend a month hacking after each modification comes out a day later?

This error only occurs if the chosen file can't be written to. Is it read-only? Is it a directory? Are you pointing to a folder (or other device) that is not writable? Is your hard drive full?

etrigan, please post your ideas to prove me wrong, but be aware you will be making a fool of yourself. If you are in the security industry, then you can explain in excruciating detail how to protect a client from the user of that client through encryption (or whatever your ideas are). Please, we are all on the edge of our seats.

We've been all through this before... The ONLY security is obscurity. If you do not understand this, then you are not knowledgeable enough to even be discussing the issue. Cont will never be open-source for security reasons. Cont was not made using any existing source code. JeffP (et al) would never risk their careers.

Rather than inventing new specific weapons to add, I would prefer to see a more generalized weapon definition system. An arena could define any number of weapons and their properties... Name Image(s) Fire rate Energy Movement Bounce Prox Timer (I would love to be able to have weapons that detonate after a time period, or even manual detonation by shooter) etc etc Subspace as it is has weapon settings too interlinked: shrap controlled by bullet damage, all bomb levels do same max, mine = bomb damage and prox, thor related to bomb, burst related to bullet?, multi related to single fire, a given weapon of a given level works the same for all ships, etc. It's really a pain in the -*BAD WORD*- to get exactly what you want, and some stuff is currently impossible (eg different bombs for different freqs, but same properties).

We don't share code. We defined an interface between Cont and menu and code to that. If I had all code, Cont would be at about 0.60 by now with new weapons, ships, specials, more settings, an MP3 player, file sharing, stock trading... I may be exaggerating.

Use smaller LVZ file names to keep the line shorter.