numpf

actually, I think I remember making threats when I was mad at someone, maybe zippy :/ then stfu? -numpf

your responses are as obtuse as your "paper," I'm not going to read them. Do a mental trace of what would happen with ekted's case 2, which I'll clarify (I'm not sure you understand it given your replies): Position packet is sent at server_time 0x00010001, meaning 0x0001 is in the packet. It is received by the client at what it calculates to be a server_time of 0x0000FFFF (Receiving a packet "earlier" than when it was sent is possible with latency problems during sync; you may have admitted that in your "paper" but I didn't bother reading that part). Well -*BAD WORD*- it, since I got this far, I might as well finish the trace for you. timestamp is initialized to 0x0000FFFF loword in the pkt is 0x0001 the first condition passes, since 0xFFFF is (much) greater than 0x0001 timestamp ends up being 0x00000001 That's wrong. If you do the same trace in my code, timestamp will end up 0x00010001, which is correct. I didn't poke fun at merv (but don't bait me), I edited specifically to state that merv just copies 1.34. -numpf

aww how cute, catid recently took a discrete math course. Using QED doesn't make you look smart buddy, it makes you look like a pretentious re-*BAD WORD*-. Your "paper" is perhaps the most obtuse piece of garbage I've ever seen. Anyway, here is the code in merv being argued over (edit: the code in merv is what's in 1.34, meaning 1.34 is wrong. I do not know if Cont does the right thing or sticks to 100% 1.34 compatibility by using this incorrect code) original: Uint32 loword = getShort(msg, 2); Uint32 timestamp = h->getHostTime() & 0x7FFFFFFF; if ((timestamp & 0x0000FFFF) >= loword) { Â Â timestamp &= 0xFFFF0000; } else { Â Â timestamp &= 0xFFFF0000; Â Â timestamp -= 0x00010000; } timestamp |= loword; // fill in the low word corrected code by numpf: Uint32 loword = getShort(msg, 2); Uint32 timestamp = h->getHostTime() & 0x7FFFFFFF; Uint32 ts_loword = timestamp & 0x0000FFFF; timestamp &= 0xFFFF0000; if (ts_loword >= loword) { Â Â if (ts_loword - loword > 0x7FFF) Â Â Â Â timestamp += 0x00010000; } else { Â Â timestamp -= 0x00010000; } timestamp |= loword; // fill in the low word If you wanted to be really picky you would say 0x7FFF should be higher, but that means you care about appropriately processing packets that are more than five MINUTES late, and that would make you a moron. This change is what catid wrote his "paper" instead of doing. QED catid is a re-*BAD WORD*-. -numpf

You are either re-*BAD WORD*-ed or ignorant and should never post here again. I leave it as an exercise to the 1 or 2 informed people on this board to explain why.

The server response to ?arena is a special packet, not text. Ekted can't do anything before Priitk allows him to access that info.

is pointless. There are only a handful of real developers who play SS, and most of them do not browse this forum. Since we have no apparent moderation, the threads are either feature requests that fall under - already thought of and discussed by the appropriate people (grel/priitk/ek) - masturbatory fantasy for feature-seekers or amateur programmers or stupid questions that - should be addressed in an FAQ - are asked by people so obviously uninformed as to be a waste of time to answer so ends my brief stint on this board, I urge all of you to find something better to do. -numpf

theoretically almost every part of the client count be opensourced. A necessary exception would be the encryption. However, you couldn't allow anyone to compile the code and play; people would only be able to play if they used the actual compiled binary that you thoroghly protected. The problem with opensourcing parts is that you lose some measure of security. With OS'd code, I could compile certain routines, then try to dis!@#$%^&*emble the cont exe and try to match the compiled routine with cont. So it's effectively like giving potential hackers a roadmap. The menu GUI is not sensitive, and its binary (the DLL) isn't protected (it is however checksumed by cont, so dont bother editing/replacing it). Continuum might be more secure if the menu was compiled in though, if just for the simple fact of making the EXE a larger m!@#$%^&* of code to work through. There's no absolute rule, but since the source code is knowledge, and the only security is obscurity (hiding knowledge), you trade away some security for every line of source you let out. -numpf

The dev board isn't dead, given the activity and # of topics. Development of bots and custom billing servers and their features is still important. ASSS is open source and extensible and set to replace subgame, so you can develop for that. And of course issues relating to general clients can be discussed, and frankly it wouldn't be so hard for anyone to rewrite the client. Continuum is another issue. It is effectively a production product, and should NOT be thought of as a pet project for you moronic amateurs. The security issues are such that it should and will be kept tightly controlled and closed. ek covered the rest pretty well. -numpf

I've been holding back, but it's time for flame mode. No -*BAD WORD*-. This is what several people have been saying. Huh? what other POV do you want? Here I must begin to believe that you are mentally challenged. I have explained several times that a 'plugin' interface is something PriitK WONT do because it's not worth it to him overall. PriitK passing on the sourcecode seems very unlikely, and the top candidate to receive that source seems like it'd be ekted, who has explained what he thinks about this. More specifically snrrrub has been passed off as an amateur, from what I've seen and heard. There are things you can look for, like a passing suggestion that we should use .NET and compile continuum into microsoft-specific bytecode because it has executable permissions ("managed code"), that mark someone as a newbie. -numpf

The fact that you dont know this is why you shouldn't even be talking about it. You wont get your plugin interface unless you rewrite cont yourself, end of story. That goes for a lot of the rest of you. If some of you are acedemically interested in how it MIGHT be implemented (and why it must be), there are some good examples out there you can find if you know how to use google. I'm pretty sure there was a nice util shipped with BG2 that allowed you to sorta create a custom script lang. One of the practical restrictions of such a language would be NO memory management or pointers. Some articles that sound good (i didn't read/review any for you, sorry) are linked from here and here -numpf

you have 2 choices, not 3. plugins would require priitks cooperation which you shouldn't expect and wont get. -numpf

The security of the custom encryption in continuum is that you MUST crack the binary AND find the encryption within it to have any hope of decrypting the packet stream. !@#$%^&*uming good protection of the binary, if you can find and decipher the encryption in it you may as well just modify the client to cheat. -numpf

Except priitk wasn't paid. A critical point that many of you miss. If you (a) really have a big problem with priitk's time restraints, and ( believe you have the sufficient skill to contribute, there is nothing keeping you from rewriting the client from scratch. It really wouldn't be that hard. This is somewhat incorrect. If you do things properly (use a proven encryption method and put some obfuscation on top of it) a hacker would need to gain access to code to decrypt and fiddle with game traffic. -numpf

first i'd like to request that orb360 never post here again. You remember when you claimed to have some SS AI written but not physics? It's a running joke. Many of you need to remember that continuum is developed is coded in priitk's free time. Also remember that the primary reason continuum was created was security and the fact that twister existed. Opening cont up to arbitrary code in it's process space as ekted said is a security risk. To minimize the risk priitk would have to write a custom interpreter/compiler for a 'sandbox' language as ekted described. That would cost too much time, and there would be the additional security risk of bugs in such an interpreter. All those factors considered, it simply isn't worth as much in terms of priitk's time as many other things would be. Don't expect to see this soon, if ever. -numpf

First of all, ek was replying to etrigan, not you. Normally i'd crispify people for a miss like that, but English isn't your first language, so i'll give you a break there. I'm not sure what your point is though. Please do, otherwise you have no credibility. Ekted doesn't think that the current game protocol is perfect. What he meant was rewriting the game to be _100%_ server-auth isn't practical. The technical aspects of the game problem will therefore always require trusting the client to an extent, even if you can make some things server-authoratative that aren't currently (example: goal-scoring protocol for powerball). Huh? You said earlier that you agreed obscurity is the only way. I think you need to do some reading on risk management and reconsider your definition of "good enough." If the only option isn't good enough, then the project isn't worthwhile, i.e. no client-authoritative games are worthwhile. That's laughable. Also, you dont sound cool insulting/marginalizing experienced (let alone famous) professionals, just ignorant. Ekted has had the urge to rewrite parts, and even the whole thing. ek and I have had extensive private discussions about many aspects of the protocol and what might be improved/changed. Whether and to what extent you actually do it involves 100 other factors. As it is ek has written a widely-used bot core and SSVCR. -numpf

given the performance/timing requirements, it is necessary for a significant portion of the game state to be managed by the client. Therefore the client must be protected so the server can trust it. The only means of protecting the client is obfuscation. -numpf