i read a lot about ppl thing there will be all these different version of the client and the server and that the clients may not work will all the servers.

I know this is a game but it still is nothing more then a client server app. the client sends and receives messages from the server and the server sends and receives message from the client.

The Fix for that would be to create and RFC(Request for Comments) Protocol for MOUL info about RFC is here
http://en.wikipedia.org/wiki/Request_for_Comments

and here is one for Internet Relay Chat
Server: http://www.rfc-editor.org/rfc/rfc2813.txt
CLient: http://www.rfc-editor.org/rfc/rfc2812.txt

all this does is layout how the client and server talk to each other it what the message is and how it is formatted and what actions take place on the client or server side.

when you link a message is sent to the server and the server send a message to the client(s) the RFC would layout what how the message is formatted what the server does with the message and what the client(s) does with the message.

now if every one who makes a client or server follows the RFC all server and clients can work with each other even with one hass something the other does not.

Lets say i make a server and client and i follow the RFC when i do but then i add IRC stuff to the server and the client some one with a client that does not of my IRC stuff should still be able to log on to the server and play the same whould go for my client if i log on to some one else server then does not have the IRC stuff and they followed the RFC when they made there server i should still be able to play on the server with my client.


so if this is set up right it does not matter what a serer are client does if they now what to do with the messages a link message is just that link to an age.

There is already a protocol for Uru that has been defined by cyan. It already does a lot of the stuff we need, (cross server interaction etc)

The problems that we don't have are talking to servers

What the issues will be are the funding or resources to run a multi homed shard without some serrious dontations or support from an outside company.

The OP is a none issue

Last edited by DarK on Sun Jan 04, 2009 3:13 pm; edited 1 time in total

Sasurael wrote:

i read a lot about ppl thing there will be all these different version of the client and the server and that the clients may not work will all the servers.

I know this is a game but it still is nothing more then a client server app. the client sends and receives messages from the server and the server sends and receives message from the client.

As DarK said, the protocol has already been defined, and there isn't much of a point in suggesting it for standardization. The "fix" for your above problem would be for clients and servers not to diverge too much from the main branch, which would hamper progress. Clients don't become incompatible deliberately, but as a side effect of experimenting with new features and different approaches to existing features. It's inevitable.

_________________
Sören Nils 'chucker' Kuklau; KI number: 196082
MYSTcommunity & MYSTlore
I write soeren says. You don't.

The communication protocols already exist and are likely already documented, so writing a RFC is pointless.

There's also no point in standardizing the communication protocols, because this would prevent the communication protocols from being changed. Changes can be useful and may even be necessary in order to keep improving Uru.

In any case, a high-quality, nicely-formatted online publication of the protocols would be an asset. I can't imagine Cyan had the time to really refine its documentation to commercial standards.

_________________
OpenUru.org: An Uru Project Resource Site : Twitter : Perfect Speed Is Being There.

JWPlatt wrote:

In any case, a high-quality, nicely-formatted online publication of the protocols would be an asset. I can't imagine Cyan had the time to really refine its documentation to commercial standards.

Sure, that would be neat. But most open source projects are hardly known for their terrific, comprehensive documentation.

_________________
Sören Nils 'chucker' Kuklau; KI number: 196082
MYSTcommunity & MYSTlore
I write soeren says. You don't.

chucker wrote:

JWPlatt wrote:

In any case, a high-quality, nicely-formatted online publication of the protocols would be an asset. I can't imagine Cyan had the time to really refine its documentation to commercial standards.

Sure, that would be neat. But most open source projects are hardly known for their terrific, comprehensive documentation.

Aye. The 'code is the documentation', dangit! ...and there was much weeping...

_________________
Through space and time; along the threads of the stars; we seek the knowledge and wisdom of the ages.

Actually, if the protocol currently isn't easily extensible, it might be worthwhile to change that early in the process, so that people can more easily add functionality to the protocol. Then you could document the protocol and keep the basic functionality set in stone while allowing people to experiment with additional features (the goal being to put those features back into the trunk and update the docs, of course).

I think ddfreyne's point is not that the protocol isn't easily extensible, but rather documenting the beejeezus outta it before it's ripe would be a limit on imagination and could hamper communication between people working on the project: "Well why'd you change that? Says right here it's..."

And basic functionality...well, it was a part of the Half-Life netcode's (and Quake's as well) basic functionality that the amount of updates you sent to a server was based entirely on your framerate. Thankfully they didn't keep that "functionality" set in stone! The point not being that OS Uru's developers are clueless, but some startling development could always happen.

Actually, Cyan's protocol does all it really will need to do. The flexibility comes not with devs changing the len and checksum byte offsets of packets randomly every few months, but rather with the info that's delivered.

As with most things Plasma, it relies on pretty common bases for everything. Since the server isn't controlling and pushy with Plasma's setup, adding more functions is a matter of adding new packet classes to the client. This can't be done with opening up a .txt file and adding one line of text, but if you're a half decent programmer and know your way around Plasma's layout I'm sure there will be no problem with adding new stuff.

It's important to understand that Plasma has a certain layout and if you want to rewrite it to work under fundamentally different principles, you're wasting your time. If you want the client-server layout of some other game then you should develop for them. Personally, I feel very strongly about this since one of the reasons I'm interested in working on Plasma is because I like Plasma's rather unique way of doing things. I'm not doing this for "Uru" at all really. I'm more into the engine than coding a special network structure for sending a message to all clients to have Yeesha to running around leaving a trail of blue flowers (as one example of developing _for_ "Uru").

_________________
Guild of Writers Councilor
PyPRP2 Developer
Plasma Hacker

Several people have brought up the idea of having different client side software versions. Someone may make a chat window that polarizes the community around it. Some love it and others hate it. Some use it some won't.

It has happened in most of the other MMO's that have gone open source. So, I expect once the code is out someone will distill out the existing protocol. In whatever version control system gets used, there will likely be a place for that spec. Writing one now seems premature.

Since most of the virtual world developers are moving toward modular code and separating client and server software, we will likely do the same. I don't imagine changes and additions will be that difficult. However, legacy and upgrade support can be a pain for those changes. If there is to be any change, early on would be better.

_________________
Nalates - GoC - 418 - MOULagain: Nal KI#00 083 543, Nalates 111451 - Second Life: Nalates Urriah
Guild of Cartographers

Nalates wrote:

Several people have brought up the idea of having different client side software versions. Someone may make a chat window that polarizes the community around it. Some love it and others hate it. Some use it some won't.

It has happened in most of the other MMO's that have gone open source. So, I expect once the code is out someone will distill out the existing protocol. In whatever version control system gets used, there will likely be a place for that spec. Writing one now seems premature.

Since most of the virtual world developers are moving toward modular code and separating client and server software, we will likely do the same. I don't imagine changes and additions will be that difficult. However, legacy and upgrade support can be a pain for those changes. If there is to be any change, early on would be better.

I highly doubt that many people will agree on a network change if they have the slightest idea what a changing the protocol could actually do for them (it'd do nothing for them really, just add tons of new bugs).

I also highly doubt Cyan will allow alterations to their Plasma trunk that makes it more of a "generic engine". MOUL had it's problems as do other online games. For instance: other games I've seen suffer a lot from network lag, this is not the case with Plasma.

Of course others can do as they please with their branches. If I'll let their clients on my server is a different matter.

_________________
Guild of Writers Councilor
PyPRP2 Developer
Plasma Hacker

Nalates wrote:

Several people have brought up the idea of having different client side software versions.

Hopefully to have the idea shot down in flames.

Plasma's network classes are all based on the same Messaging system that the rest of the engine uses.

To add a new part of the protocol, you simply add a new message class. Cyan has done this a number of times in MOUL, for adding things such as the Jalak pillars and the BlueSpiralGame (Delin & Tsogal).

The network packets are really just an internal Plasma message wrapped in TCP or UDP headers (UU used UDP, MOUL used TCP).

Rusty_Russell wrote:

Nalates wrote:

Several people have brought up the idea of having different client side software versions.

Hopefully to have the idea shot down in flames.

Quite the contrary, actually

As long as the client's communications with the server are all legal, there's no problem. If they want to see through walls, that is their choice - it doesn't create any apparent gameplay problem. In any case, there are going to be multiple revisions of the client and possibly even the server, no matter what opinions are aired here. I don't see a cause for concern.

And I wonder if you'd consider compiling the source optimized for some specific processor or OS (32 bit versus 64) would create a "different version." Certainly it would be a different binary.