Witchie NL Posted October 28, 2006 Report Posted October 28, 2006 that java sucks and they need to replace all of Java with C++.
KrynetiX Posted October 28, 2006 Report Posted October 28, 2006 I'm not a programmer that would be my brother he will help when he gets out (XaNiTH).But I believe java would be better because it's multiplatform ALTHOUGH I hear Wine is upgraing everyday and similar applications are rising. So, with that in mind i believe C would be the best bet. Because, lets face it, it's powerful. (and my brother's prolly too arrogant to help with java)
KrynetiX Posted October 28, 2006 Report Posted October 28, 2006 So who's not sleeping or eating becoming 'tweaked into the oneness' & programming this core? You should be done soon.
Yoink Posted October 28, 2006 Report Posted October 28, 2006 Kryn you have to realise that the problem isn't that C++ is Windows only (because it most certainly isn't), it's that certain features of Windows only programming are more attractive than taking the time to make it work on all platforms. I think I got that correct. OpenGL FTW .
Drake7707 Posted October 28, 2006 Report Posted October 28, 2006 i hate linux ... very much. It always crashes when i'm using it (and no although i have not so much experience with linux, i don't !@#$%^&* things up like a noob) So for me there doesn't even has to be linux support. Windows ftw ^^ *hides for linux fanboys or fangirls (although i doubt the latter will be worse than the first)*
L.C. Posted October 28, 2006 Report Posted October 28, 2006 Although slightly off-topic, I can't help but to contribute on Linux vs Windows: I don't like Linux, personally. It's not user-friendly or anything...Microsoft beats that so well. However, there's things like Ubuntu and stuff - ok! I think Windows (XP mainly) is overally far better than Linux, BUT - Linux has a slightly major componant/advantage over Windows. In Linux, it doesn't give a crap about file permissions or who owns the file; so instead of getting "Permission denied" errors, it's clean and swift when in Linux you can do whatever you want to the file. In short: Windows beats Linux overally, but Linux beats Windows by its feature of having complete control over files. ;o That's the only thing I like about Linux. Linux has about 1500+ more vulnerabilities than Windows, and they don't always get patched/quickly enough compared to Microsoft (this is from my understanding). Though I disagree with the thought of Windows servers. Linux ftw when it comes to servers.
Bak Posted October 29, 2006 Report Posted October 29, 2006 People need to stop talking out of their !@#$%^&*es about everything. If you don't know about something, don't say anything; your unintelligent rabble only takes away from the topic at hand.
Drake7707 Posted October 29, 2006 Report Posted October 29, 2006 yeah you're right, sorry, delete my previous post and posts following up on that.
Smong Posted October 29, 2006 Report Posted October 29, 2006 I think the only thing people can learn off this page (I am using 10 posts per page) is that C/C++ can be recompiled under linux instead of using wine to run a windows executable. (And maybe also SOS isn't raving about C# so much). Edit: previous page, grr.
»doc flabby Posted October 29, 2006 Author Report Posted October 29, 2006 linux vs mircosoft debate. my main reason why linux must be supported it to try and break mircosofts monoploy and finally bring some real innovation to the desktop computer arean instead of endless cloans of windows 95. how much in terms of using windows have things changes since windows 95? windows vista (without the eye candy) looks and plays prety mcuh the same as windows 95. create another thread if u wanna argue about this crap please... -------------------------ok back to topic.------------------- game engine will be written in crossplatform C/C++. only ASSS zones will be supported. it must have linux, mac and windows (98/2000/XP/vista) support the lobby client can be written in java/delphi/c#/whatever. It doesnt matter. I would choose java as it would make it simplist (no porting required between platforms) or deplhi/freepascal as its got a great IDE for gui dev.
Drake7707 Posted October 29, 2006 Report Posted October 29, 2006 server should be optimized for speed as they will have to process everything what's going on in the zone. It's always a trade-off, do much on the client side will put less weight on the server and less traffic between client and server, but easier for cheaters to hack the local data. On the other hand, do everything on the server, then you get too much traffic and heavy processing for the server.
Smong Posted October 29, 2006 Report Posted October 29, 2006 I don't know much about the internals of server-side games, like CSS, but I think they use things called frames that contain all the world information. Everyone gets sent the frames a certain amount of times per second (hence 66 tickrate servers in CSS). Also from playing the BF2142 demo (which keeps disconecting you), you can tell the server is giving you a movement velocity and also a rotation velocity about each player (you see tanks spin slowly around a point downward into the ground! during "connection problem"). So what am I getting at? To be a truly versatile engine it must support trace hit weapons. By this I mean things like guns. SS only has projectile weapons. I would imagine tracehit client side would be awful since everyone plays "in the future", ships can easily be more than 1 ship length out of place. I think one problem with moving stuff server side is you need low pings for players to see everything smoothly, we would need more servers in different countries.
Wild Luck Posted October 30, 2006 Report Posted October 30, 2006 I did not read the complete thread but a new client would be good
Smong Posted October 30, 2006 Report Posted October 30, 2006 If people are gonna say this will make cheating easier. It wont. The binarys distributed will be signed with a secret key. Servers will be able to choose to accept unsigned client or to reject them.Can you write a program or an example to prove this?
Drake7707 Posted October 30, 2006 Report Posted October 30, 2006 if you really want to protect against it, you'd also have to hash the traffic with rsa in order to prevent sniffing, and packets that are time based to prevent duplication of the packets that are send (on purpose)
Smong Posted October 30, 2006 Report Posted October 30, 2006 You could just attack the program instead of the network traffic.
Bak Posted October 30, 2006 Report Posted October 30, 2006 I wouldn't rule out server side verification. Even if the server is only capable of checking 10 clients at any one time, with proper heuristics you could probably stop most cheating. Other clients could even hint the server when people appear to be cheating (moving too fast and such).
»doc flabby Posted October 31, 2006 Author Report Posted October 31, 2006 If people are gonna say this will make cheating easier. It wont. The binarys distributed will be signed with a secret key. Servers will be able to choose to accept unsigned client or to reject them.Can you write a program or an example to prove this? i've just relised there is a flaw in my idea. the main problem is the key has to be inaccessable to the user on the client for this to work. this is impossible. the next best solution would be to make the key very difficult to discover. in otherwords exactly how continuum's protection works -_- however the key could be kept out of gpl (ie non open source) and the binaries sutibly protected and obsured to make it work. im only talking about protecting the program. network traffic is easy to protect, once the program is sutiably secure. I think bak is right server-side heuristics is probabbly going to be most effective EDIT: have just had an interesting idea. what if the server was to execute code (with a large number of permutations over 1million) on the client each time it connected to verify the binary. only the server would know what the result should be. there are still flaws in this idea as well... hmm 've just realised what i have said a long time ago is acctually true. only the server can be trusted....
Drake7707 Posted October 31, 2006 Report Posted October 31, 2006 or create a function in an external dll that generates a key based on the hash code of the binary of the process that calls the function + a time based factor (so the client can't fake the function by sending the same sniffed data before). The dll itself is encrypted and protected, and distributed with the open source. Or the server gives a challenge, and the dll calculates the answer based on the crc32 of the client. Then sends it back to the server, and the server can reject if the solution doesn't match the crc32 of the original distributed version (again some time factor could be handy to put sniffers out of the loop)
»doc flabby Posted October 31, 2006 Author Report Posted October 31, 2006 or create a function in an external dll that generates a key based on the hash code of the binary of the process that calls the function + a time based factor (so the client can't fake the function by sending the same sniffed data before). The dll itself is encrypted and protected, and distributed with the open source. Or the server gives a challenge, and the dll calculates the answer based on the crc32 of the client. Then sends it back to the server, and the server can reject if the solution doesn't match the crc32 of the original distributed version (again some time factor could be handy to put sniffers out of the loop) That was pretty much my idea, just different process. The weakness lies in with that is you can just alter the dll to always give the correct answer as in you feed the dll a exe which has the correct crc32/hash but then acctually use your custom client to connect
Drake7707 Posted October 31, 2006 Report Posted October 31, 2006 hmm yeah, and passing the handle as argument wouldn't do any good either as it can be another one... isn't there an way to know in the dll what app called it ?
Bak Posted October 31, 2006 Report Posted October 31, 2006 You'd p!@#$%^&* it a path to an exe file, it would run the version check then spawn the process... But it's not going to work since you'll always be able to fake it, what checks your exe? another exe checker? then what checks that one? It's not even as hard as dis!@#$%^&*embling the executable, since you can just intercept traffic between the real exe and the server, then after the integrity check completes, direct traffic to your modified exe instead of the real one. This method is still vulnerable to memory hacking.
Recommended Posts