I understand what you mean. Though my collisions are done mariokart style(arcade like) and do not hamper the gameplay(or block paths) with the expection of a bounce away from the opposing kart. If this game was very dependant on realistic collisions then this would be a problem. Either way the server still contains the "real" positions of all entities at all times. If you keep the world on the client static to the entity(meaning, things dont affect movement on your comp any different than they do on others) you should be fine. I'd use the server positions and some distance testing to see if there is a collision then initiate the bounce sequence on the clients. So lets say theres a thing on the ground that you run into and spins you out. You'd have the server do the scanning for karts. That way it's fair. But your right about the potential issues... I think i'll have to look into this a bit further yet. Though in the meantime i'll keep to this method and will soon see how it all pans out when I do some more indepth testing(crosses fingers).

10.05.06 i finally got the movement working thanks to william and locoweed for their help.

it works now in my testthing that i can move the host player around and send position to the client. its very smooth and works perfect for me.

now my problem is i have to pack this test into a system where every player can move his own entity by sending coordinates to the server wich then calculates his movement with c_move and sends coordinates back.

right now i need two models, one for event_click and movement and one for the player visual model with animations.

i thought about how to manage this efficient and it gives me headaches. i came to the conclusion that it would be the best to create 2 pointers for each player with ent_create so i can send directly to that entity. the first with the name "player" holds the playernumber and is sensitive to event_disconnect so clients can disconnect. then depending on the playernumber i create an entitypointer depending on the playernumber of the player with the name "thisisplayer1" so i can send directly to that player.

then i create pointers like:

*hosthull
*host
*client1hull
*client1
*client2hull
*client2
.
.
.

and create them locally for each player depending how many players are active in the game.

i use variables like client1wantstomovethere[3]; to let the server know where client1 wants to move. then the server calculates the movement and sends back client1ishererightnow[3]; to all clients 4 times a second.

well right now my code is a little mess, and i have to rewrite lots of it so my system works. i know this might not be very good coding style but at least it should make the code a lot more readable and understandable.

ill let you know when iam done and post the movement code.

Nice to see you moving along.

11.05.06 just a quick update today, i got a damn cold today i hope it goes away or even gets better tomorrow. thus i just did some code reorganizing. i renamed all functions and created a lot of local entities like described above.
so far it works great okay you got a delay on the client but its shorter than in warcraft 3. and iam able to move the client as well as the server player.

anyways i found a thing wich i think is a bug. shorevietam is experiencing the same. the average_bps from the F11 debug panel seems to be buggy. it has problems updating. when iam using 2 send_var the average bps keeps climbing up to no stop. with one it stays around 40 but when i use 2 send_vars constantly its getting higher and higher - this cant be. iam not using more instances of a function. and iam only sending 2 vectors 4 times a second. so it should be around 40-50 i guess but its not. it goes unlimited high climbing slowly. iam pretty shure i have no bug in my code.
that shorevietam is experiencing the same in his mplayertests is interesting too.

12.05.06 the cold is a little bit better but it still hurts. we just had egg big icerain here for 5 minutes i never saw such a thing bevore. well back to the game. apart from some code cleaning i thought all day long how to achieve a good entity handling then it came to my mind.
my game should not be able to allow players to join later. i totally forgot that in awe about a6 multiplayerprogramming

so what i plan now is the following. the external serverbrowser assigns each player a playernumber already. it then passes it via the -d command to the engine. the host will generate a unique number for the game he starts and assign it too with -d.

at gamestart each client sends his unique game number to the host and checks if its right. this way only players wich where in the same lobby can be in the same game.

now for the entity handling:

first thing i do is create an entity for each player with ent_create that allows the player to disconnect. this entity is placed 1000 quants under the level and is just there to handle the disconnect AND it stores the playernumber assigned by the external starter.

the next thing iam gonna do is, that i browse through all entites and check for the player numbers at the server. so at the server i create pointers for the server with the names: thisisclient1, thisisclient2... so that iam able to use send_var_to directly to them saving bandwith.
again, i browse through the entitys wich where created with ent_create and assign pointers to them because they exist both on the server and client and are just there to handle disconnects and store the playernumber. those entities have .nosend flag set.

then i only work with local entites from now on.

i create 10 local entities for each client with the pointers host, client1, client2...client9
the same for the host, he also gets this host, client1, client2...client9.


each of those entities has a different function. i hope you could follow

now image the following. the client with clientnumber 1 clicks his local entity2. because this is obviously not his own entity he sends a variable request_health_player2 with his player number set. the host then sends the health of player2 to player 1 who requested it by clicking on his local entity for player2.
the same for movement. imagine the client with number 1 clicks his local client1 entity. because of his playernumber 1 he knows this is his entity. now when he clicked the entity he can click somewhere else and this sends the vector client1_wants_to_move_there[3] to the server.
the server then moves his own local entity client1 with c_move, sending back the position client1_is_at[3] 4 times a second. (later ill add sending only to those who can see client1.


i think this is the best system for my kind of game. everything is done by sending variables triggered by local entites back and forth. game logic is kept completely at the host while clients can only make requests and the host then checks if this is possible or not sending results back to clients.


this is contrary to locoweeds system wich was more dynamic but i dont need the ability for players to join and leave as they want because the game is like a soccer game it goes for ~60 minutes average and you level up during that time. so late joined players wont have a chance anyway. only those who join with the right gameid assigned by the serverbrowser will be able to join and pick a race to play with.

because iam not feeling very fresh in my mind right now i postpone the coding to tomorrow probably doing some other designwork for the game right now.

from cleaning up my code i learned, that its better to comment right away when writing. and deleting unused variables as soon as you realize you dont need it. doing this afterwards is just plain boring work.

well i hope there are no flaws in my system and its possible to manage everything from inventory to fighting and so on in my game. if you dont understand a thing just dare to ask or if you find a logical problem please let me know. thanks!

I just thought i'd note that your way of handling pointers and local entities for bot hthe server and client will probably make things harder. When you create normally, the server and every client has the same entity created on them. If someone joins after the start, then they wont have these entities on them. But, since your planning for fixed creation thats allright. Then again, it's gonna make testing tough, unless you create a system so everyone joins at same time or have all the initial local entities sitting in the level at start.

Anyways, if you go with one normal ent_create instead of local creation, pointers are much easier, and sending information is easier too(because of the pointers). Since every client and server creates the entity, they will all have the same pointer. With local entities your going to have to manually assign pointers, since every entity would be unique. For example, a local soldier on the client and a local soldier on the server will have different pointers by natural, so your going to have to set up a huge list of unique pointers(for every new unit) and go about asinging them properly. This might also mess up the "you" type pointers for handles ect. Cause no longer will the you entity on your comp be the exact same entity on all the other comps.

For the intitial pointer set up, just do it this way, client1 is the first client connected to the game, and so on... then if you create a guard, create it server/client wide. It has it's own unique pointer which is by default the same on all computers. If you click on that entity locally, tell the server, the server then sends a move command to the clients, then move it on the server and clients. In the end I think messing with properly setting pointers locally is much tougher than making sure you properly disable all the automatic A6 state sending globally. In my game the only entities that send positions are the main karts. Everything past that is all states so to speak. For example, a weapon i've got is similar to green turtle projectile in Mariokart. I have it follow the kart, then I send a variable across when I left click mouse, that variable tells the projectile to move on each client individually, then I do the logic on the client/server, and when you end up removing that weapon, you dont have to do no poitner work, it removes on all comps with only one "ent_remove" command!

P.S - hope the cold gets better, they can be quite nasty sometimes.

thanks for your input. i haven been thinking about this now. i still have some problems understanding.

imagine i create the entity client2 = ent_create(...) at the client2, now the function of this entity runs at the server only the function given by proc_local runs at all clients. fine then i could move the entity on all clients according to the incoming data from the server.

now i have the problem that i need a bounding box for mouse clicks for each entity. that box i just copied with clickentity2.x = client2.x and so on. now how do i for example set this clickentity to match client2 on each client since i dont have different pointers for it.
how would you solve that?

shorevietam suggested setting numbers to the entity and iterating on the server then sending back and creating pointers but i think this is much more work than my initial idea.

also as far as i understood if i use client2 = ent_create(...) at the client, only! the pointer client2 is valid at the client. if i use the pointer client2 at the server its empty, isnt it?

well i dont really see the point in creating the entities with ent_create apart from the advantage that all players see it right away when created and i dont have to handle this with invisble flags.

Sorry to bust in on your blog, don't really have anything constructive to say (god knows I'm busy enough with my own code) but I just wanted to give you kudos for what you are doing.

This thread will be invaluable for future generations of 3DGS developers and I commend you for the idea and for following through on it.

Great Job, Ulf!!

Oh my, a compliment from fastlane69! I think my heart stopped beating there for a second. It passed. I thought I was going to have to call 911 there.