1 registered members (opm),
778
guests, and 4
spiders. |
Key:
Admin,
Global Mod,
Mod
|
|
|
Re: You guys do NOT make this easy -- MMP Part 2: Technical
[Re: fastlane69]
#222396
08/19/08 04:00
08/19/08 04:00
|
Joined: Mar 2003
Posts: 5,377 USofA
fastlane69
OP
Senior Expert
|
OP
Senior Expert
Joined: Mar 2003
Posts: 5,377
USofA
|
I don't understand what the problem is here, JCL. Every person who has used the GS Network engine says it can't do MMOG. EVERYONE. Every person who has used the GS Network engine says it can't even do MP properly. EVERYONE. What is it going to take for our message to get through? When will you admit that DPLAY is the wrong network to support so we can start thinking about the right network? Or put another way, I and others have been trying to do MP and MMP applications for 5 years... exactly how long have you and Conitec been trying to create a MMOG that your experience should trump the entire MP communities experience?
|
|
|
Re: You guys do NOT make this easy -- MMP Part 2: Technical
[Re: Spirit]
#222399
08/19/08 04:26
08/19/08 04:26
|
Joined: Mar 2003
Posts: 5,377 USofA
fastlane69
OP
Senior Expert
|
OP
Senior Expert
Joined: Mar 2003
Posts: 5,377
USofA
|
Ok, let's get this out of the way right now for it started with JCL and it's snowballed: I don't see WHERE, anywhere, I have stated that my project is a failure. I have created a viable MMOG solution which right now suffers from a "incompatible engine" error that pops up for no reason and is unpublishible (works in development but not when we publish). Thus, by using only session_connect and the send functions, I have created what is a few bugs short of an MMOG. And in order to do this, I had to turn off all GS Dead Reckoning AND entity update routines... the former because it was useless as anyone will tell you and the latter because it update all entities in a server (that's really MMOG friendly there!). As well, we had to create a dll so I could store a players handle in a DB because of GS's notorious "last digit non-precision" when outputing vars outside the GS engine which meant that we could not store a Handle accurately using the native GS code. As well, I had to create a series of lookup tables and other DLL to handle the fact that in my architecture, what I believe is the ONLY MMOG Architecture with native GS, clients and the "server farm" are all bottlenecked at the one true server, thus making a single failure point at the server (which anyone will tell you is bad network architecture design as there is no fail-back option). So you see my friends, it is not because my project is a failure that I ask for these changes but rather because it is a success IN SPITE OF GS NETWORKING that prompts me to this thread. So please, don't read between the lines and please stay on topic; you too JCL: this thread is not about my project, it's about the network engine, it's past, present, and future functionality. There is no need to bring my project into this "as a failure" to discuss this point though I am more than willing to share any aspects of my architecture and code to help you understand my point. And furthermore Spirit, it's not that the functions are buggy. Again, please stay on topic. It's that the entire GS network architecture is flawed, barely MP capable, and not conducive towards MMOGs. If you don't believe me, consider that using GS Networking, with all functions working perfectly, would have the server updating every entity about every other entities position every client_update tick. Does that sound like a MMOG friendly architecture?
|
|
|
Re: You guys do NOT make this easy -- MMP Part 2: Technical
[Re: Tobias]
#222402
08/19/08 07:31
08/19/08 07:31
|
Joined: Mar 2003
Posts: 5,377 USofA
fastlane69
OP
Senior Expert
|
OP
Senior Expert
Joined: Mar 2003
Posts: 5,377
USofA
|
but I can tell you that you can store player handles in a var. Have you tried storing them outside of the engine? There is a chance that this has been fixed, but store several entity handles in a text file and then look at the handles... you will find that several handles repeat themselves in the last (third) decimal digit because of the lack of precision in the last (third) decimal place. And since Handles use all digits, including decimal, for information, this means that if you do this you can't retrieve the right entity. Hence, Handles cannot be stored in a text file nor a Database with native GS. There are several workarounds but the point is they are workarounds to this faulty system and every workaround gets us further and further away from native GS. Does this seem MMOG friendly to you? Client-server systems control the entities on the server and send the speed updates to the clients. That's how MMOGs work Correct. However, the native GS Architecture sends a "speed update" to EVERY client on the server, no matter if those clients can "see" each other in the world. To give you an example, imagine a MMOG Zone based on planet Earth. If you are in the US, do you really need to know the speed of every person in Japan? Of course not and yet that is exactly what native GS Architecture does.
|
|
|
Re: You guys do NOT make this easy -- MMP Part 2: Technical
[Re: fastlane69]
#222411
08/19/08 08:34
08/19/08 08:34
|
Joined: Aug 2000
Posts: 1,140 Baunatal, Germany
Tobias
Moderator
|
Moderator
Joined: Aug 2000
Posts: 1,140
Baunatal, Germany
|
Sure you can store entity handles outside the engine. I use an array of handles in my C++ app that calls the engine DLL. As I said handles are nothing but long integers, so I dont know for what reason you are not able to store them or what you expect Conitec to fix.
If you think theres something wrong with handles, then Spirit is right you should post a bug report, but if storing handles is really one of the things that prevent you from finishing your MMOG, then it seems to me that you have not had much chances anyway. I'm no expert but if you want I can write you a handle storing function in 5 minutes.
Also, sending of entity updates only to close clients is certainly nice but I dont think that this prevents you from doing a MMOG either. When the world is divided in zones, the servers only send updates to entities in that zone anyway, and in no MMOG you would place the US and Japan in the same zone.
|
|
|
Re: You guys do NOT make this easy -- MMP Part 2: Technical
[Re: Tobias]
#222414
08/19/08 08:44
08/19/08 08:44
|
Joined: Mar 2003
Posts: 5,377 USofA
fastlane69
OP
Senior Expert
|
OP
Senior Expert
Joined: Mar 2003
Posts: 5,377
USofA
|
Also, sending of entity updates only to close clients is certainly nice but I cant imagine that this prevents you from doing a MMOG either. This is not just "nice" for MMP, but "necessary" and native GS's inability to deal with this to date is very much preventing ANYONE from creating a MMOG. If you can't see why, then please, respectfully, as someone who admits to not having much working experience with MP, please stay clear of this conversation. As I said handles are nothing but long integers, Under Lite-C this is true. But for those of us that have developed under C-Script (still supported by Conitec last time I checked), handles are Vars and Vars do not "export" well. but if this handle stuff is one of the things that prevent you from doing a multiplayer game, Please read the entire thread before commenting as there are a TON of other issues (most listed above) that affect the ability to achieve a native GS MMOG of which the handle is but one and not even the most important one.
|
|
|
Re: You guys do NOT make this easy -- MMP Part 2: Technical
[Re: fastlane69]
#222419
08/19/08 08:58
08/19/08 08:58
|
Joined: Aug 2003
Posts: 7,439 Red Dwarf
Michael_Schwarz
Senior Expert
|
Senior Expert
Joined: Aug 2003
Posts: 7,439
Red Dwarf
|
I totally understand the issue, I just don't get why to make such a big thing of it. Many companies announce with big words.
Or do you really "enjoy" drinking a Coke? Is the beer you are drinking really the "best premium lager beer"? Is the PC you most recently bought really "the best PC"?
It's marketing, everyone does it. And I'm plenty sure that they still will in the future.
Is it "possible" to make an 1000-player-MMOG with 3DGS using the Acknex Network Engine? It certainly is, but it is never stated that the server would be extremely slow and that you probably have a lag of like 20 seconds. But it "is" possible.
Is it "practical" to make an 1000-player-MMOG with 3DGS using the Acknex Network Engine? No.
Infact, it is ridicously impractical to do so, but still possible.
Use DLL's, period. Even companies using the U2/3 engine need to use plugins. Or even have a look at the Quake 3 engine, many modern games are stillmade with i, but the developers need a lot of plugins in order to include today's features like shaders and the such.
It isn't that big of a deal.
Last edited by Michael_Schwarz; 08/19/08 09:04.
"Sometimes JCL reminds me of Notch, but more competent" ~ Kiyaku
|
|
|
|