Fastlane69: May I just answer on your feature request without waiting for more threads and polls?

- Lose DPLAY and go with Raknet, Enet, ???
Planned, but DPLAY is not the reason of a multiplayer problem. It's not the fasteest, but despite contrary rumors it's reliable. At least the dplay features we use, which are just the basic client/server send and receive functions.

- Server to server communication
Ok. This is one feature that we found does not work with DPLAY, so for this we'd indeed need to switch the library.

- Lobby system
Planned, but a lobby server can be also done with the current functions.

- Security Fixes (ie: the ability of a dummy GS client to crash ANY GS server)
Only in nonencrypted mode. A dummy client can not crash a server when you use encrypted mode for sending. Invalid packets, i.e. packets that don't come from a server or client of your project are then detected.

- File transfer
Planned, but not essential for an MMOG.

- Web Player
Same as above.

- Individual Client update
Ok.

- Better network diagnostic panel
What diagnostics are you missing?

- Native MySQL integration
There are already several DLLs by users for this purpose.

When I extract from the above features those that you probably really need for finishing your MMOG, I'd select a different library, server to server communication, and a client update range. Can you finish your game when you get those three features?

non-moderator users are only able to start polls in Morbius' afaik.

hey your right ! thats an amazing coinsidance when i tested my theory about page style i tested it there by starting a thread but not finishing so it wouldnt show up , so i thought i solved it what are the odds of me going to the only forum it would work
thats freaky

Thanks for the reply, JCL. I'm happy to have you specific feedback on these issues and your viewpoints on priorities as a way to focus our discussion.



I've already programmed a client update (works okay) and I have a (lousy) workaround for the needed server-server communication. However, I can't go commercial, nobody can, while this remains...

"- Security Fixes (ie: the ability of a dummy GS client to crash ANY GS server)"

...and if encryption will fix this, then please, please move encryption up the priority scale to "ULTRA TOP URGENT" because all our MP projects are non-commercial until this is fixed.



I will argue that Dplay is the problem on these three points:

1) you admit it's not the fastest which with todays advances in network engines, is an understantment. As an example, if it takes dplay 2ms to process a packet that another library process in 1.9ms, that is a HUGE deal for MP and especially MMP games.

2) you admit server-server is not possible with Dplay. We admit that it is critical to a well designed MMP. Thus I argue that Dplay is indeed holding the MMP community from growing. What can we do as developers to convince you as engineers that server-server is indeed a critical feature for the growth of the GS MMP community? I've only been saying this for 4 years after all..

3) From a business perspective, if you are trying to sell your product, be it to an investor or a publisher, they will cringe at the mention of Dplay. Dplay carries a bad reputation in the industry and NO GAMES HAVE BEEN MADE WITH IT IN ABOUT 5 YEARS. Thus keeping it as the frontline GS solution means that any MP/MMP developer is already at a HUGE disadvantage in terms of funding and commercializing their game merely because they are using an outdated and often mocked engine.


As always, I represent the MMP camp and thus do not represent the full MP community. Others should chime in JCL's feedback to get a good view of what the GS MP community needs.

Encryption is in beta:

http://www.conitec.net/beta/dplay_encrypt.htm

I know this might be a little off-topic but:

I see encryption is coming for A7, will this be rolled out to the older A6 or is this security hole only apply to A7? If this security issue is a problem for A6 do I then need to upgrade? This rabbit hole really does run down a long way...

The more I read, the more worried I get

As A6 is no longer supported and encryption may very well turn out to be a Lite C feature, I'm guessing you'll have to upgrade as encryption will not make it into A6 (since nothing new will make it into A6).

Which is not a bad thing considering that you get to make and send structs over the network with A7 and integration with other Net Libraries should you choose is more transparent in Lite C than C-Script.

I've not switched bcz I am concerned about the learning curve for A7, considering how long I have been working with A6.

Now it looks like I will have to schedule this upgrade in, thats not to mention the fact that this exploit must have been a threat to A6 and therefore undermined the commercial use of our Pro purchase...

Doesn't seem right to me, but I guess if it's no longer supported there will be no comeback...

It's not like I am having enough problems with Multiplay as it is!

Edit: Maybe someone could look at our code and estimate how long it would take to re-write for A7? Any takers PM me

Going from C-Script A6 to C-Script A7 is trivial. Do not worry about that.

Going from C-Script A6 to Lite-C A7 is more involved, but not a whole rewrite. Merely look at what Conitec says in the manual about the conversion and I think you'll be fine.

Yeah I have done a little digging on this, maybe its not a huge deal. Still no rush for it just yet, until we're further with our own MP development I think A6 will be just fine until then.

Thanks your advice and re-assurance has restored my confidence a little. plus I made some personal progress with our first steps at multiplay support

I am looking forward to reading the next response from conitec for future MP functionality and when d_play is changed, what is it changing too?

Very interesting indeed. Thanks again