Quote:

1) How hard do you suppose it would be to mitigate existing 3DGS MP code to Raknet?


It depends very much on your code. If you have a modular design, where you have an abstraction layer over the 3DGS functions, this will be very easy. The best case scenario is a codebase with clearly seperate pieces of code for creating and handling every seperate type of message. For example, a clearly seperated function that creates a movement update (as a string or series of skills for example) and a corresponding packet for handling such incoming messages could easily be converted to a function that creates a BitStream and a network event function that reads the BitStream and acts upon the contents. Your code should not use the native entity updates.

if your code is a mess with send_*()s everywhere, it is still possible to convert to RakGS, for example by using a single MessageID for every kind of variable (kind of like inventing your own network indices as used by 3DGS).

In any case, the problem for you will most likely not be that it is too hard to convert your code (after learning Lite-C it's a breeze) but that it most likely is a large amount of code.

How much your existing codebase would benefit from RakGS is dependent on how much you where thinking "The RakNet way" while designing your code. For me, I have wanted to write code the way you can with RakGS since the beginning, so my code uses concepts that easily map to RakGS functions. Those concepts where internally implemented as "workarounds" in my 3DGS code, but when converting to RakGS they should work gracefully.

Quote:

2) As we both know, one of the more annoying things we've had to do is implement our own routines so that only relevant entities (ie within a certain radius) send information to a client (my Sphere Of Influence if you remember). Does RakNet have an inbuit solution to this or would we still have to program this in?


RakNet does not have an inbuilt solution for determining which entities are near which ones, since it doesn't deal with entities. (When using RakGS, you must break the thought-link between entities and clients, they are not the same.). However, I have implemented a system that automatically assigns SystemIDs to connected systems. SystemIDs are useful for several purposes. You can conveniently relate SystemIDs with client data on the server (by an array of Client structs, indexed by their SystemID). You can store a pointer to the player character entity inside your Client struct, and store the SystemID in a skill of the entity. You could then use your old scan code to detect nearby entities and write their SystemIDs to a list in the Client struct. This list can be used to send to those clients:
RAKGS_send(chatMessage, client.SOI[ i ]); in a loop that increments i.
instead of an ugly lookup system.

Quote:

Honestly Ex, if this pans out, I would be the first to ask Conitec to make this their native network engine... seems to make more sense to use Rak than to use the Sunset DirectPlay as it does now.


I have spoken to jcl and he will consider RakNet when the need to change network libraries arives. He says "DirectPlay is depreciated, but still a
reliable workhorse. The engine network functions are implemented on a higher
layer and not dependent on the underlying network library.". This is an understandable point of view, since it is quite a lot of work to convert I think (in hindsight). Also, he most likely wants to maintain backward compatibility so he cannot change the design of the 3DGS network engine significantly.

Quote:

Oh, and if I may, I would develop in this order... merely my opinion of course:

- Remote procedure calls
- Secure connections and encryption with a single function call.
- Statistics
- Autopatcher
- Voice chat
- Network simulator



Yes I'll implement RPCs and secure connections first..

If you promise to write a little more sophisticated test app and let me know what you think

shader tutorial