I have read the manual. I have read some stuff that was relevant that I found in forum searches. I am wondering if there are anymore resources available that explain the built-in networking and how it works. If Locoweed's tutorial is still relevant I wouldn't mind reading that. Unfortunately the links in his thread are all dead. If you know of any other resources that a new person like me doesn't, I would appreciate a link to it as well.

there is a multiplayer section in lite-c workshops check it out.
("online tutorial" link on sidebar)

Right. I have read and used the multiplayer tutorial. I've also looked at the AUM 70s workshops on multiplayer.

I guess I'm just wondering if there is a better overview of the networking system. There seems to be little bits of relevant information here and there, but no really good explanation of how Game Studio's implementation works in one document.

The first stage is to look up the manual as reference

http://manual.3dgamestudio.net/

under network functions.

This gives you an overview about what functions are
relevant for multiplayer, and how they basically work.

Here are some things I do not understand. I have an A7 multiplayer tank game that works as expected, but it gets out-of-sync. It is using ODE physics. In this game players get pushed and moved around using physics. I am attempting to use the client-side type movement of tutorial 25_2.

From what I can understand of the game engine, tutorial 25_2 is doing an 'exact simulation' type of networking. In this simulation the server receives all the keystrokes and uses that to create an exact simulation of what I am doing on my clients. This probably works ok for c_move type games but I can understand that physics might calculate differently on both ends. It also does not take into account that one player could change the location of another player through pushing, etc. So this is my assumption of how things work and what is wrong.

If that is the case then I obviously do not understand how to send updates or corrections to the server simulation of where my tank really is. In my current version I can see a 'ghost' of my other client tank(s) that is in the correct position. This ghost blinks on for a few frames but doesn't correct anything.

What I am really trying to figure out is what the "server" is doing and how to react to it. The manual says:



But what is it referring to when it says 'level updates'? Every entity? Does dplay_localfunction = 2; cause this to change?

If the server is sending updates how can I watch for them and make use of them? Does this only apply when running actions on the server only?

These are the types of questions I do not currently understand about the engine multi-player implementation.

Ok. I found 2 versions of A6 multiplayer tutorials in the AU resource site. The one I was looking for by Locoweed and another by George. I think I have a better understanding of what is going on between the server and client. Not perfect, but better.

The basic Idea of the implemented Multiplayer is, that the
server does all logic and calculations (such as Movement)
and sends the important data to the clients. (like the
position, pan,etc)

The clients on the other hand usually only send commands to the
server via send_skill or send_var.

(look up these functions in the manual)

The server either reachts on changes to these commands using
a server event or comparing it with the previous state.
Then the logic of the entity action on the server does the
game-dodo and for example moves the entity.

Changes are (on default) automatically send to the client,
wich sutomatically moves the entity or updates skills.

--

If you like to have the client have more control, you can
change some setups to manually exchange data between client and server,
or let the server send updates to specific clients.
Here it gets tricky, and cant be explained in short.

---

The "syncronous simulation" you mentioned is not
the default concept, but can be reached with workarounds.
For it to work properly, you need to keep a very
close eye on the way gamelogic is calculated, to keep
it fully syncronous on all clients.
using physics is not the best idea in such a system,
as it will most likely give different result on
different client, wich multiply quickly.