Questions

[Texvor]

I see windcatcher might be opensourcing this... what language is it written in? Does anyone know?

[Texvor]

Im having some small issues do I need to use an older version of mysql?

[Texvor]

and another question I hope this is in the right place...

Would it be possible to update the source that comes with this for the server, to use say the 0.5.8 items table and zone table? If so how difficult will it be to do?

[Texvor]

I saw in the log for settup up delphi for oz that the same or nearly the same setup is needed for SC is that correct? Or will there need to be other changes needed in addition?

[Cripp]

very close..

SC source proly isnt going to be released anyways.

so quit dreamin!

[Texvor]

Windcatcher said he would probably be releasing it today earlier in this thread right?

[Garekas]

Well he said he was mulling it over actually. Im sure we all hope he does release it, but in the end it is his project so its his decision alone

[chuckltn73]

Just for clarification, Windcatcher is it being released or not? Above you said sunday but thats come and gone and we have had no updated word fron you yet on your thoughts?

[Windcatcher]

I still haven't decided. For everyone out there, PLEASE STOP PM-BOMBING ME ABOUT IT! I plan to work on it tonight to see what improvements I can make, but one thing that would really help (big time) would be an intelligent discussion on how server ops could deal with the possibility of cheating with an open-sourced client. I suspect that it would involve one or more layers of encryption in a closed-source version, but this isn't something where I'm knowledgeable. Maybe there should be a common LS-level crypto with individual world-level crypto? I have no idea, but if I had some idea of what is required I could at least put some hooks in place. The main point of trying to spur this discussion among all of you though is so I can make a more informed decision. Releasing the source is not something that can be undone so I want to be certain that it won't be a catastrophic mistake.

In the meantime I want to try to make a minor architectural change to prepare for a *possible* open-source release as well as try to address the bugs that have been found recently. I might even add a really simple options window so things like window fade can be controlled. I have no set plan for tonight, but these are some of the things I have in mind.

[chuckltn73]

Ok well, hrmmm call me crazy but i generally go with the simplest solution to a given problem, Richardo hit it on the head I believe it was and some others I think.

A simple check of a preassigned variable that only the server Op can change in the source. I think there was mention of using the variables table expansion field to this end.

I know I personally will impliment some kind of encryption, Ive already been Working on ClearLogin and the login packetmanager dll you included, well not much of work more of looking through and preparing to add the encryption and authentication.

I think there are many possibilities the serverOp could impliment, which would be the beauty of opensourcing it people would be able to share ideas, and at the same time be able to see what can work the best within those given ideas.

[chuckltn73]

Humm seems I can not edit my post;

On the subject of encryption I wanted to touch base a bit more in depth. Something like encryption should truly be left to the serverOp to deal with, for the very simple and important reason that, a global encryption system that is predistributed will very quickly undermine, said encryption. It would basicly defeat the purpose of adding the encryption if that encryption was distributed (Did that make any sense?)

[KLS]

Problem with that is the variable would be easy to work around for anyone competent enough to modify the client. Simply connect with the client you want to replicate to your own server see what version it sends to the server and put that secret version in a new version of your client: tada it now has replicated the secret key.

If you add a little basic encryption it makes it harder but not impossible to replicate.

client-> RequestConnection -> server 
server -> Reply (Including secret key for this connection) -> client
*figure out patches and stuff* if it's a SC patch then:
server -> Challenge -> client
client -> ChallengeReply: SecureHash(SecureHash(variable) + SecretKey)) -> server
server compares clients version to it's own internal hashed version and if they don't match disconnects.

That's pretty basic right there but would probably be enough. Would be harder to get the variable but not impossible because well the binary is in the hands of the enemy and he can simply decompile it to see what the key is, or they could potentially brute force it as well.

I think simple things like server side checks to see if players can do this or do that when they attempt to do something will cover most cases. Collision is the only real problem as it would be difficult to detect serverside. You could put a check in the movement code to see if someone is under the world and track how often it happens, if it happens a lot odds are there's a problem with your zone or someone is cheating. That wouldn't cover all cases though as there would be situations where people would be able to travel through small walls undetected.

One thing that might be an option is using a plugin type system for the various parts of the client, for example network is handled by a network.dll and ui is handled by ui.dll and various core mechanics handled by core.dll etc etc etc, would allow the release and modification of most the client while still keeping sensitive things tucked away in the main binary. Not sure how well that would work with your code though.

[sesmar]

Originally Posted by Texvor

I see windcatcher might be opensourcing this... what language is it written in? Does anyone know?

Simple Client is written in Delphi


[Edit]
Well, apparently I did not read far enough down to see that this was not needed anymore, sorry.