Zoidcom

Movement Replication with several objects

PACUS — Fri Jul 25, 2008 6:29 pm

Author: PACUS

Posted: Fri Jul 25, 2008 6:29 pm

with 2 Players all works fine, but when i add some more Objects with movement-replication, the the movement of the proxy-players starts jerkily.
Only the 2 Players move, the other objects are fix.
I can disable all Updates for this objects, but nothing helps
When i use Objects without the movement-replication, all works fine.

The movement-rep code is the same as for the player.

if you want to see it:
http://www.bombzone.de/bmz_test.rar
Start the Server, then start the Client
to move use: cursor-keys and d,f,g,r
drop a bomb: s

oder meld dich mal

HGE and movement replication help request and example

PACUS — Fri Jul 25, 2008 2:15 pm

Author: PACUS

Posted: Fri Jul 25, 2008 2:15 pm

If you don't use the the "correctionReceived" Function the Positions between different clients and the server are inaccurate.
i think wrong?

Artifact Online - 2D NVE

sharkyx — Tue Jul 22, 2008 8:58 pm

Author: sharkyx

Posted: Tue Jul 22, 2008 8:58 pm

Looking good How far are you planning to go with this? And how much time did you invest to get this far?

No cheat verifying position replicator

Okerampa — Sun Jul 20, 2008 9:56 pm

Author: Okerampa

Posted: Sun Jul 20, 2008 9:56 pm

Thanks ! I'm trying like that ^^ If it's an interesting option, hope it will come somedays.
Zoid is great, good luck continuing the good work.

eggnog

korj — Sun Jul 20, 2008 6:32 pm

Author: korj

Posted: Sun Jul 20, 2008 6:32 pm

This is Vladimir, you told me about some code example...

What does this error mean?

sharkyx — Wed Jul 16, 2008 8:50 am

Author: sharkyx

Posted: Wed Jul 16, 2008 8:50 am

The assertions are no crashes. They are a system to detect invalid data in packets. Without this, it's hard to find bugs where you try to read data from a bitstream which isn't really there. As a sideeffect, any packet that is not coming from a connected or currently connecting Zoidcom client is invalid data and will trigger assertions in debug mode, too.

Release mode on the other hand silently drops invalid packets, which is necessary for normal usage but doesn't help in debugging.

ZCom_Address::getAddressIP modification

sebarnolds — Wed Jul 09, 2008 1:59 pm

Author: sebarnolds

Posted: Wed Jul 09, 2008 1:59 pm

Thank you very much.

Sebastien

Player-Movement

sharkyx — Tue Jul 01, 2008 9:35 pm

Author: sharkyx

Posted: Tue Jul 01, 2008 9:35 pm

Quote:

the "50" in setInterpolationTimem shouldnt that be UPDATE_RATE ?

No. This value determines how much the client lags behind the server. Higher values give more smoothness, because more data is known before it is displayed, but higher values also mean higher display lag.

Quote:

i mean the moverep->updateState thing, the rest is form ex07. is anything more needed exept the moverep->getExtra...things already in doProxy code ?

No, this is fine. Just make sure that for the nonplayer objects you actually update data.position and data.velocity through updatePhysics() in doAuth() otherwise nothing will happen on the proxies. On the proxies you don't call updatePhysics(), only getExtrapolated*().

getExtrapolated*() will give you interpolated data for setInterpolationTime() milliseconds after the last received update. If the time between two updates is larger than that, it starts extrapolating, i.e. the extrapolated position is derived from the last received position in the past + the velocity*time since the last update.

The auth only sends updates when it thinks the proxies can't extrapolate properly anymore, i.e. when the velocity or the acceleration changed.

And floats work fine, the rounding is no problem unless you do scientific simulation.

ZCom_ConnStats -> avg_ping and total_out

sharkyx — Tue Jul 01, 2008 9:35 am

Author: sharkyx

Posted: Tue Jul 01, 2008 9:35 am

The displayed lag represents the travel time only. As Zoidcom sends packet in more or less fixed intervals, you can't measure accurate pings by just waiting for the reply. So Zoidcom subtracts the time between packet arrival and reply sending on the remote computer.

ZCom_sendData doesn't seem to work

Etabubu — Tue Jun 24, 2008 8:47 am

Author: Etabubu

Posted: Tue Jun 24, 2008 8:47 am

The packet I'm sending is a string (that is variable, but never longer than 12 characters) and an integer made of 3 bits.

I took a look at the log and I couldn't find any error, anything wrong!

The examples work ok, and when I started with this project, in the beginning I was using just sendData() and everything was ok. Then I moved to nodes and events (and they work fine), but the other day I tried to use sendData() again because I didn't want to create a new object just for a quick test. But... what I described in the first post of this thread happened.

Yesterday, I modified the code and I created an actual node with its own events to handle the new communication and everything works fine.

There must be something to do with sendData() or the way I use it that screws things up!

Help with the movement replicator

sharkyx — Mon Jun 23, 2008 10:33 pm

Author: sharkyx

Posted: Mon Jun 23, 2008 10:33 pm

Instead of calling

Code:

ZCom_processReplicators(SIMULATION_TIME_PER_UPDATE);

you call

Code:

ZCom_processReplicators(hge->Timer_GetDelta());

In doOwner() you do the same for the updatePhysics() call. That should be enough to establish a fixed speed. Maybe you have to adjust the timescale with the setTimeScale() function. The default scale is velocity = 1 => 1 unit of movement per millisecond. That means 1000 units per second with a velocity of 1. Set this to 0.5 to half the value etc. The scale you set here has to fit to the actual values your game uses, otherwise the extrapolation will be faster/slower than your actual physics resulting in constant jumping and correction.

The time deltas are dynamic but updatephyics processes in fixed size steps by waiting until a certain amount of time has acummulated. This changes the dynamic ticks back to fixed ones and is necessary to avoid jitter and maintain consistency across the network. Use smaller values for the acummulator treshold if you want finer grained updates in your physics:

Code:

//updatePhysics:
while (data.accum_time > 0 && data.accum_time >= SIMULATION_TIME_PER_UPDATE)
...

If your unmodified ex07 is jumpy you have timing issues probably related to having two ex07s running on the same computer and one being in the background not getting enough cpu time or getting it very unregularly.

3 more, less time consuming to answer, questions XD

sharkyx — Mon Jun 23, 2008 10:12 pm

Author: sharkyx

Posted: Mon Jun 23, 2008 10:12 pm

1) You won't get updates twice, but maybe in the wrong order. Not in the current Zoidcom version, but maybe in the next big version. Just leave it in, it doesn't hurt.

2) Because the physics update processes the time that passed between the last keypress and the current. This time is in the past, before the received key update was generated.

3) _client_time is a timestamp that increases by the value you give to ZCom_Control::ZCom_processReplicators(). It starts out at 0 and is used for measuring time deltas (in case you give real milliseconds to ZCom_processReplicators()) or ticks (in case you just pass 1 to the process function). In any case, you subtract the old value from the new in inputupdated and know how much time/ticks have to be processed.

_estimated_time_sent is a real time according to Zoidcom's local getTime() minus the estimated ping / 2. With an additional getTime() you can roughly tell how much time has passed since the keypress left the client.

"R6025 - pure virtual function call" error in proc

sharkyx — Mon Jun 23, 2008 9:56 pm

Author: sharkyx

Posted: Mon Jun 23, 2008 9:56 pm

Good catch! I found the problem and fixed it.

Questions about synchronization

Etabubu — Sun Jun 15, 2008 2:53 pm

Author: Etabubu

Posted: Sun Jun 15, 2008 2:53 pm

Rhodan wrote:

Except that lag is not constant so you can't rely on it to figure out who pressed the button first.

In my second post above I meant that you just time the period between the client displaying the action and receiving the button press - not from the start of the game to the button press. This will virtually negate any timer differences between the computers.

Sorry Rhodan, could you elaborate your idea a bit more? I don't quite understand.

Using zoidcom in standard c

otty — Fri Jun 13, 2008 8:08 am

Author: otty

Posted: Fri Jun 13, 2008 8:08 am

thank you.
i'll check it out.