2000-03-14: Movement discussion with Sal

05:52:39 *** You are now known as aloril
06:02:03  Aloril!!!
06:02:05 * Sal  cheers
06:02:14  I need your help :)
06:12:51  hi Sal!
06:12:53  what?
06:31:40  I got libatlas compiling last night,
06:31:59  and then updated xclient.  It connects to cyphesis now, as
                        before...
06:32:22  an its sending movement request, and cyphesis is logging them,
                        so I know its recieveing them,
06:32:36  but I can't seem to control the character...
06:32:44  its like he moves on his own
06:33:09  I'm using observerclient to watch while I move around in xclient
06:33:11  hmm.. uups forgot that auto flag...: is this at first connect
                        or second one?
06:33:42  hmm... I dont remember which connect...
06:34:42  it was happening after the first connect, that's for sure
06:34:49  hmm...  it should not by default do anything ... hmm
06:35:28  well... what you receive from server?
06:35:45  should receive first: current pos+velocity
06:36:03  then after a while: new position+zero velocity
06:36:10  if you used target location
06:36:14  if you used velocity only:
06:36:25  then you should receive every 3s : pos+velocity
06:37:27  ok, I'll have xclient dump position responses. hmm
06:37:59  isn't there another cyphesis client that prints out coords, so I
                        can verify that its recieveing my requests?
06:38:24  yes... displayMovement.py I think
06:38:56  for verifying receiving... hmm.. certain log file should show
                        that: 
06:39:05  don't use observerClient.py at all:
06:39:19  then everything that happens at world.log is from you
06:39:56  ahh ok.
06:40:03  hmm.. there should be per/connection log too: use connection
                        number+".log" to view it
06:52:09  hmm... the .log says its recieving my pos info.
06:52:47  hmm.. what does it reply?
06:52:50  (in logs)
06:53:01  connection_num.log should give reply too
06:53:57  
06:53:58  
06:54:08  accnt_2
06:54:09                           
06:54:09                                   world_0
06:54:09                                   
06:54:09                                   -22.88-124.010.0
06:54:09                                   
06:54:13                           
06:54:23  
06:54:24  
06:54:36  [...]
06:54:39  
06:54:41                                                   world_0
06:54:41                                                   
06:54:41                                                   -16.31-109.3610.0
06:54:41                                                   
06:54:41                                                   
06:54:43                                                   000
06:54:45                                                   
06:54:47                                           
06:55:08  hmm, the response pos is different from the request?
06:55:28  weird..
06:55:45  it would be ok if velocity was nonzero, but not now.. hmm..
06:57:43  start server from fresh, connect only using xclient and send
                        connection_num.log to me?
06:57:53  ok
07:02:26  ok its sent
07:02:36  in xclient I logged in,
07:02:48  then moved forward for some units, stopped,
07:03:01  then moved straight up some units, then logged off.
07:08:22  quite good compression ;-) :
07:08:23  255546  Defl:N          8989  97%
07:08:34  1/28 ratio
07:08:45  good 'ol zip :)
07:09:53  255k is a lot though, I was onle in xclient for a few seconds...
                        we have some optimization to do there...
07:10:52  seems I have forgotten flush from logging but should not be
                        problem: I think there is enough
07:10:58 * aloril  nods
07:11:18  both in how much info attributes it uses and binary1
07:11:26  9K is not that much though?
07:12:11  hmm thats 72 kbits...
07:12:34  I'm on a 28.8 kbit per sec connection,
07:12:55  its cutting it a tad close, but it should work.
07:13:10  we could make it much smaller though, with a custom binary
                        layer
07:15:00  hmm.. removing unneeded attributes and binary3 should be much
                        smaller too
07:15:21 * Sal  nods
07:15:32  ie for movement request we only need something like:
07:15:52  {byte}{float}{float}{float}
07:16:05  and binary3 should practically provide that
07:16:15  and we need it only once / second
07:16:22  even {byte}{short}{short}{short} if we really wanted to optimize
07:16:56  and byte only allows 255 possible messages, but we could do:
07:17:16  {byte=255}{byte2}{... ... ...} for more expansion.
07:17:51  how often you send movement?
07:18:01  um... lemme check
07:18:32  every 300ms
07:19:05  and only if the position is changed...
07:19:16  ahh.. hmm.: 
07:19:27  when you send movement, then it starts moving
07:19:48  so if xclient does this: I'm here now: then it will intepret
                        reply wrong
07:20:01  oh I just ignore replys now...
07:20:13  I only send stuff...
07:20:13  because sending only coords (or coords+velocity) means: I
                        want to be there
07:20:44  hmm
07:20:45  so if you send current position: 
07:21:05  it sends first you your real position in world and velocity
                        toward requested position
07:21:24  and when you reach it then it sends you requested position (+
                        zero velocity)
07:21:33  (and every 3s it sends updates)
07:22:03  so ... it lags because xclient opinion and server opinion
                        about position differs
07:22:07  hmm..
07:22:28  ahh
07:22:37  gotta replace python libatlas with C++ one though: python one
                        is quite slow: lots of abstract layers + it's in python
07:22:44  so C++ should be quite speedup
07:22:51  that is another reason for lag
07:23:04  well the best way would probably be if the clients send they're
                        current position, plus current velocity.
07:23:22  yeah... but you can't really move faster than server allows
                        ;-)
07:23:26  that would be best suited for prediction/collision
07:23:29 * aloril  nods
07:23:34  and cyphesis should support it
07:23:46  or even better:
07:23:48  yep... that's how quake1 works too
07:23:59  read what cyphesis sends about your position and send only
                        velocity
07:24:05  otherwise it might be jerky
07:24:19  server->client responses for all entities are the same way in
                        quake
07:24:25  let server handle all position handling you control it by
                        changing velocity: except when you stop
07:24:31 * aloril  nods
07:26:18  811 bytes/msg now and 30 bytes/msg with zip
07:26:47  actually now that I think about it... does server really need to
                        know clients velocity at all?
07:26:58  843+1=65 bytes
07:27:02  uups
07:27:19  432+1=25 bytes
07:27:28  Sal: yes
07:27:34  so it can send it to other clients 
07:27:47  so other clients can predict your movement too
07:28:05  it only needs the positioning... and if the client moved to an
                        invalid location it should respond with the correct position
07:28:06  hmm...
07:28:06  and of course it needs to move you the way you are yourself
                        thinking you do
07:28:19  so this is how I think it should be:
07:28:26  but I could send fals velocity no? and it would disrupt other
                        ppl's view of me...
07:28:26  you get your current position
07:28:41  C: sends velocity to direction you start moving
07:28:59  server can calc velocity from the last two positions...
07:29:04  S: comfirms your request (if it was ok)
07:29:16  S: after a while sends you changed pos+velocity
07:29:31  Sal: yes.. but only after fact
07:29:37  and thats too late ;-)
07:29:55  and of course it takes some time to move to new position
07:30:08  but wait,
07:30:09  so when you request new position, then it starts moving
07:30:16  server knows the initial position...
07:30:20  so it will always be behind
07:30:30  so after it recieves the first movment request, it has a
                        velocity...
07:30:31  yes it know so you only need to send velocity
07:31:02  Sal: what velocity? it currently uses 'max allowed for this
                        char'
07:31:30  it knows you position and client request: "I want to move
                        here"
07:31:51  hmm... well we move it there using max velocity then and tell
                        it that it started moving
07:32:03  and when it reaches: tell it that it reached and stopped
                        moving
07:32:24  thats how it works now
07:32:57  and if you use velocity + target location: same as above but
                        using given velocity
07:33:23  if you use only velocity: it moves using given velocity until
                        something happens (you give new orders or collision)
07:33:52  I see what you're thinking...
07:34:18  I had something totally different in mind, which I stole from
                        the quake 1 src code :) Wanna hear it?
07:34:39  btw.. 30 bytes for zip compression vs 25 bytes for
                        pos+velocty+byte is not much difference ;-)
07:34:58  so I think that suitable removing of attributes and suitable
                        codec we can achieve that
07:35:03  sure
07:35:17  that's pretty good, 30 bytes
07:35:18  anyhow
07:35:22  in quake:
07:35:49  client moves anywhere it wants, and every X ms tells the server
                        its current position
07:36:17  the server checks the line from pos1->pos2 for any obstructoin,
                        and if there is, it send the point of collision
07:36:37  if there is no obstruction, the server makes no response at all,
                        and client keeps moving.
07:37:07  however, when the server sends the client info about other
                        players,
07:37:26  it sends they're postion and velocity, not just position.
07:37:42  (so that your client can do prediction)
07:38:25  and if the entity's velocity is the same, the server just sends
                        the new position...
07:38:45  its very minimal communicate for the sake of bandwidth,
07:39:25  hmm. does it check for speed too... ie distance between
                        pos1,pos2 ?
07:39:42  yep! it does
07:39:59  checks the distance vs. time, makes sure the client isn't
                        cheating.
07:40:25  if the clients ducked, underwater, etc. Then the allowable
                        distance is even less, because they are not allowed to move as fast.
07:41:10  that's it :) pretty simple no?
07:42:49  what about initial movement? what speed it sends to other
                        clients?
07:45:33  well updates are only 333ms apart,
07:46:08  so it is too crucial.  plus if you take the initial position +
                        request, you get a pretty accurate velocity
07:46:24  isn't too crucial I meant
07:47:32  the reason I like this, is that the client could move a very far
                        distance, with no server responses,
07:47:43  its very efficient...
07:48:02  only if hte client makes an illegal move does the server
                        respond.
07:49:06  hmm.. there is kinda lag for client->server->another client:
07:49:32  another client needs position before it know about change of
                        direction
07:52:20  hmm... the other client would recieve the new position+current
                        velocity together, from the server
07:53:02  al, imagine this:
07:53:16  there is a bird flying around in a circle, around a tree...
07:53:19  hmm... there is slight lag in changing direction... about
                        333ms
07:53:26 * Sal  nods
07:53:51  with my method there no lag at all (except CPU+network of
                        course)
07:54:07  now if there is a lag inbetween packets, the client will
                        interpret the bird as flying around in the wrong location...
07:54:35  and the server doesnt know really that the client has the
                        incorrect coordinates for the  bird...
07:55:18  so this causes problems.  the most accurate way would be to send
                        the birds positioning instead...
07:55:28  this way there is minimal error, no?
07:56:11  you're absolutely right though, sending a velocity instead of a
                        position gives the server a head start by a few ms
07:58:18  Aloril: can you hack cyphesis to work with my status updates?
07:58:25  you can trust the client for now...
07:58:38  just so I can get basic movment/prediction working
07:59:21  hmm.. you mean just move it to where you want it to be?
07:59:30  yep...
07:59:47  and send that position to the other clients...
08:00:05  hmm... you can use change operation but... that woulnd't
                        update others using movement then :-(
08:02:53  gotta go for 1h
08:03:33  Sal: I think about some flag for now (ie keep current
                        behavior but setting some flag you can bypass it)
08:03:47 *** You are now known as aloril_away_1h
08:03:48  ah, that would be great!
08:03:54  or make just another message...
08:04:00  loc2? I dunno
09:10:52 * kosh is now known as koshbed
09:25:48 * You are now known as aloril
09:26:08  or coords2... gotta test though which is eventually best
                        method:
09:26:33  and it might be that this is temporary thing that is later
                        removed
09:28:05  hmm... couldn't xclient send immediately when user starts
                        moving velocity?
09:29:13  yep, I could do that
09:30:00  but then it requires that I read responses to make sure that the
                        server has my positioning right...
09:30:45  I'm afraid the network mismatch will cause the server->client to
                        go out of sync, sending the position info seems more dependable no?
09:31:22  ahh... yes 
09:31:31  have you read unreal network paper?
09:31:44  nope...
09:31:54  I got the url once, didnt get around to it though
09:32:09  do you have it? I'll look at it...
09:32:09  http://unreal.epicgames.com/Network.htm
09:32:29  seems there client does more complicated prediction
09:35:34  reading...
09:36:54  hmm... I think that paper has influenced how I did
09:37:46  In a typical low quality 28.8K ISP connection, unreliable data
                        is generally received 90%-95% of the time.  In other words, it is
                        very frequently lost. 
09:37:54  so...
09:38:10  in a UDP game there is much packet loss,
09:38:30  what if a velocity packet is skipped? wouldnt the entity be
                        moving in the wrong direction?
09:39:30  ahh... well I have somewhat combined ideas from there but
                        assumed TCP ;-)
09:39:42  :-)
09:39:42  UDP will be there later
09:39:51  but I don't think we need it yet
09:40:00  but still, even with TCPIP...
09:40:15  what happens is packets come in bunches,
09:40:30  they arent spaced apart as even as the server sent them, so...
09:41:17  the client will rotate two '90 degree left' packets too close to
                        each other, when it was supposed to do it further apart...
09:41:30  the result: entities are severly in the wrong position...
09:41:40  Al, one more thing,
09:42:02  Sal: well.. each packet has time stamp about when it was sent
09:42:06  when I was coding XServer for Warforge demo1, I did just what
                        you said, only sent velocities...
09:42:50  and it cause the problems that I speak of, I would just like to
                        let you know :) sending the positioning info really made things much
                        easier.
09:43:52  Al: yep, we'd have to send timestamps... its difficult to
                        synchronize. positioning packets would make it easier on us, I
                        promise :)
09:43:59  time+velocity or pos+velocity should handle above problem
09:44:19  sure positioning is easier.. but unoptimal I suspect ;-)
09:44:22  but just pos would work too :)
09:44:44  it is optimal... really, only need to send one vector...
09:44:50 * Sal  begs Aloril
09:45:05  pleeeease :) It would make this easy on me
09:45:36  hmm... well I think with velocity you can send less packets,
                        so it's optimal in both sense: bandwidth and lag
09:45:44  but I'll add it temporary there
09:45:53  thanks!
09:46:10  and then test things on what is good so we have more info
09:46:18  but wait... temporary?  I think atlas should be able to have
                        this feature...
09:47:03  no?
09:47:29  then people can choose which one they would like to use...
09:47:43  ie maybe Karsten wants to do it your way...
09:47:51  hmm... well.. it is kind of cheating: client tells: "I'm
                        here" server replies: "Seems reasonable, I agree, you can have your
                        333ms advantage"
09:47:58  and I could still do it my way.  It would make a good atlas
                        feature :)
09:48:17  well client doesnt really have an advantage...
09:48:35  because the world is simulated serverside.
09:48:59  client does have 0.3s movement change advantage
09:49:17  ie: server simlates movement after it has happened
09:49:27  in fact its better if the client 'lies' about its position to
                        the server (like quake does) depending on ping... so that the user
                        sees something more accurate
09:50:16  hmm.. good point
09:51:03  I've been playing with xclient + xserver for a long time, this
                        works best, you gotta trust me :)
09:53:48  besides, I don't think we can go wrong by implementing both
                        methods.  'Tis a compromise
09:58:58  Sal: search for "Player Prediction" in that paper
10:04:04  reading...
10:06:32  yep, this is how xclient+xserver works now,
10:06:37  quake also...
10:07:00  the server sends 'adjustmove message' if the client moves
                        incorrectly
10:08:16  their method is a bit less efficient thatn quake because they
                        send all info all the time it seems.
10:08:34  ie the client send pos+vel+timestamp for every move.
10:08:58  +viewpitch +viewyaw
10:09:01  etc.
10:10:01  well... 3KB/s / 3upd/s = 1KB/ each update ..ok : that would
                        be only one direction: but
10:10:12  more important is accurate info that size of it
10:10:23  even modem can send easily 500B/s
10:10:42  or 100B/msg I think... of course there are others too:
10:10:54  hmm.. if 1000B would be useful bandwidth:
10:11:31 *** Sal has quit (Connection reset by peer)
10:11:32  then with 50B messages (12 doubles) you would get 20 updates
10:15:15 *** Sal (~sferro@port16.pontiac05.tir.com) has joined #cyphesis
10:15:29  [10:10:01]  well... 3KB/s / 3upd/s = 1KB/ each update
                        ..ok : that would be only one direction: but
10:15:29  [10:10:12]  more important is accurate info that size
                        of it
10:15:29  [10:10:23]  even modem can send easily 500B/s
10:15:29  [10:10:42]  or 100B/msg I think... of course there
                        are others too:
10:15:29  [10:10:54]  hmm.. if 1000B would be useful bandwidth:
10:15:29  [10:11:31] *** Sal has quit (Connection reset by peer)
10:15:30  [10:11:32]  then with 50B messages (12 doubles) you
                        would get 20 updates
10:16:44  yep... accuracy is important.
10:17:00  and with an rpg we can lag thing more than with a FPS game like
                        quake,
10:17:07  (ie 1 sec. updates if we want)
10:18:07  but sometimes you dont need to send all info... if velocity
                        didnt change, then no need to send it again...
10:18:14  right?
10:18:40  hmm.. seems I didn't remember unlreal right: it's mix of what
                        I did and what you propose
10:18:44 * aloril  nods to Sal
10:19:09  also rotation.  If you walk in a straight line, you're rotation
                        never changes,  so no need to send a whole rotation vector every
                        frame
10:19:34  so unreal too allow client to do things at 'past'
10:19:58  yep
10:20:16  and I guess it's more important that you client gets that
                        advantage than:
10:20:22  now very far at past though, only a few hundred MS :)
10:20:30  you get more laggy movement and others get more accurate
                        movement bu you
10:20:35  s/bu/by/
10:21:09  so it's cheat/lag tradeoff... one of many we need to do: just
                        need to find right compromise ;-)
10:21:21 * Sal  nods
10:21:40  yep, its a bit of a compromise.  But its the best way to handle
                        the situation, I think :)
10:22:06  also, we can still support you're other way... so no loss..
10:22:14  you're/your
10:22:24  (in other words: other will get more laggy updates about your
                        movement... but they are farther and it matters less for them ;-) )
10:22:41  exactlly!
10:23:46  also, its a bit easier al, to program client side.  You just let
                        the player move normally, and send the server your current position
                        every so often.
10:24:04  and occasioanlly correct your movement
10:24:21  hmm.. what if client doesn't know server physics very well?
10:24:46  in unreal and quake they are same code but here... we can
                        have quite different things:
10:24:48  ahh, good question
10:24:55  different gravity, etc..
10:25:04  and different time rations too
10:25:13  yep.
10:25:38  we will need to have atlas realy info like that... gravity,
                        water(swimming), ice, etc.
10:25:44  realy/relay
10:26:10  but for now I'm eager to get this normal walking to work :)
10:26:24  hmm.. you do need timeratio even now too
10:27:21  timeratio?  Hmm...
10:27:27  for what exactlly?
10:27:40  how much game time moves for each real second
10:28:09  of course if we made each hour or minute have less units that
                        would solve it ;-)
10:28:27  but I think dural is going to have 1/3 or 1/8 speedup
10:28:46  (and cyphesis has currently ridiculous 1/1000 speedup (for
                        acorn maybe 1/1 is ok?)
10:29:04  yeah, 1/1 would be good for now
10:29:22  it would be simpler for calculations... we can accelerate later
10:29:58  hmm... only need to fudge time (ie divide it by certain
                        factor): then it's same
10:30:12  so what is needed for other speedups: get server info about
                        it
10:30:29  wait a sec though... why is this info need clientside, for
                        velocity calulations?
10:30:29  divide all timestamps sent by server for movement purposes
10:30:36  and multiply all sent to server
10:30:57  timestamps ;-)
10:31:11  oh, but I ignore timestamps now :)
10:31:25  are they really needed immediately?
10:31:25  timestamp is same as actual game time... could have separate
                        too but that seems waste
10:31:36  Sal: not now
10:31:42  ok :)
10:31:44  later need those for day/night
10:31:50  etc.. things
10:31:54  yup...
10:32:00  and for movement prediction too
10:32:18  lets get this basic movement working though :) so we can start
                        interacting 
10:32:34  hmm.. actually there is two different times: time as
                        seconds and time as string
10:32:52  what changes you made to cyphesis client?
10:33:07  cyphesisClient.{h,cpp} that is
10:33:20  none really, just some minor tweaks
10:33:29  I check my changes in last night
10:33:51  had to put string("farmer") instead of "farmer" in some places
10:33:59  because of a stl bug.
10:34:28  had to change from #include "Atlas/Net" to "Atlas-c++/src/*"
10:34:35  ahh... looking
10:34:38  etc. nothing major
10:37:33  ie MSVC stl bug? hmm.. maybe we should add *char things there
                        to 'workaround'
10:38:11  its not biggie, Mike says he's going to modify the lib to try
                        and fix it
10:38:22  ahh.. good
10:39:23  so let me know when you make that modification, and what I have
                        to change in xclient to use it.
10:40:02  once that works we can debate about recieving entities too :)
10:46:08 * Sal is now known as Sal_brb
11:10:22 * Sal_brb is now known as Sal
11:14:40  Sal: what about this: I give 0.3-1s second of 'past' time for
                        clients: everything over that is 'truncated' ? hmm.. still would like
                        to have client specified velocity though
11:16:14  ok I can send velocity too, if you really want it.
11:16:48  but change it so that it means the clients 'current' pos &
                        velocity?
11:17:26  yes... unless it's too big position change
11:17:40  yep, thats fine...
11:17:41  so we can keep pure position: I want to move there and stop
11:18:00  and pos+velocity: move me there immediately using this
                        velocity with 0.5s head start
11:18:06  s/immediately//
11:18:10  sure, we can keep that, for NPC's or whatnot
11:18:26  which would be same as move me there immediately for small
                        diff(pos1,pos2)
11:18:42  (small: something that can be traveled in < 0.5s)
11:19:38  hmm... gotta think more
11:19:48  so xclient will send you its current velocity and position every
                        500ms
11:20:17  we should sync our updat times, or send me the update time via
                        atlas somehow...
11:21:10  well.. if they move at same speed: then difference should be
                        much less than 0.5s actually... more like 1-10ms if even that
11:21:23  it's only changes in movement direction where it matters
                        actually
11:22:54  (ie when opinion between server and client differs)
11:23:10  hmm.. means pos+velocity will change meaning more
                        fundamentally... gotta think
11:25:46  from move to this position using this velocity and stop ->
11:26:18 *** Sal has quit (Connection reset by peer)
11:26:22  -"- and continue moving using this velocity (+ add some
                        predetermination if possible)
11:29:41 *** Sal (~sferro@port16.pontiac05.tir.com) has joined #cyphesis
11:29:43  :P
11:29:54  [11:21:10]  well.. if they move at same speed: then
                        difference should be much less than 0.5s actually... more like
                        1-10ms if even that
11:29:54  [11:21:23]  it's only changes in movement direction
                        where it matters actually
11:29:54  [11:22:54]  (ie when opinion between server and
                        client differs)
11:29:55  [11:23:10]  hmm.. means pos+velocity will change
                        meaning more fundamentally... gotta think
11:29:55  [11:25:46]  from move to this position using this
                        velocity and stop ->
11:29:55  [11:26:18] *** Sal has quit (Connection reset by peer)
11:29:55  [11:26:22]  -"- and continue moving using this
                        velocity (+ add some predetermination if possible)
11:30:54  hmm:
11:31:01  1) pos: move to this pos
11:31:08  2) vel: move using this vel
11:31:24  3a) pos+vel: move to this pos using this vel and stop
11:31:28  3b) pos+vel: move to this pos using this vel and continue
11:31:46  all have: give 0.5s head start if possible
11:32:14  there should be a 
11:32:27  4) move from this pos
11:32:42  5) move from this pos using this vel
11:33:22  which is a more accurate description of what xclient would be
                        giving you...
11:33:40  ie by the time the server gets the message, xclient was already
                        at that pos
11:34:06  so it can add vel*ping time to get the clients 'real' pos
11:34:24  hmm..
11:34:50  or server can convert to 1) by adding 300ms*vel + pos
11:35:10  and move it like you do now, internally
11:37:36  yeah.. was thinking that
11:38:09  just can't decide between 3a and 3b... or actually probably
                        going to pick 3a... but still would like: go there using other
                        velocity than max speed ;-)
11:38:42  maybe setting state to "walk" or "run" is enough for 3b?
11:38:54  uups, 3a
11:39:08  3a would work best for you I think, serverside
11:39:50  so if client has problems/disconnects/heavy lag then the server
                        doesnt keep moving the entity where it isn't supposed to
11:39:50  too
11:41:10  well.. but it works very badly with prediction
11:41:14  move/stop/move/stop
11:41:24  and tell other about it: very jerky ;-)
11:41:50  then you should do it like xserver does it :)
11:42:03  well.. 3b is like that?
11:42:34  keep moving the entity until >300ms have elapsed or the client
                        sends a 0 velocity packet
11:42:49  there is no 'stop' point really
11:43:06  (which is why 4) and 5) make more sense to me)
11:43:36  there is only 'start' points in my network movement model
11:43:45  (and quakes, and unreals)
11:44:45  am I making sense?
11:46:31  3b is 5 when requested position makes sense
11:47:00  ie.. say you move at max 1m/s
11:47:15  server thinks you are at 0m
11:47:24 *** Forskis has quit (Connection timed out)
11:47:28  client: move to 0.5m + 0.4m/s
11:47:42 *** sferro (~sferro@port16.pontiac05.tir.com) has joined #cyphesis
11:47:42  server: ok. you are at 0.5m and moving 0.4m/s
11:47:54  [11:46:31]  3b is 5 when requested position makes
                        sense
11:47:54  [11:47:00]  ie.. say you move at max 1m/s
11:47:54  [11:47:15]  server thinks you are at 0m
11:47:54  [11:47:24] *** Forskis has quit (Connection timed out)
11:47:54  [11:47:28]  client: move to 0.5m + 0.4m/s
11:48:06  another client:
11:48:18 * Forskis (^forskis@ess.mineral.ualberta.ca) has joined #cyphesis
11:48:18 * Batlin gives channel operator status to Forskis
11:48:24  move to 10.0 + 0.4m/s
11:48:31 *** Sal has quit (Connection reset by peer)
11:48:38  server: you  are at 1.0m and moving at 0.4m/s
11:48:47  isn't it just same as 5 then?
11:48:48 *** sferro is now known as Sal
11:49:22  well 'move to' thinks that you want to stop at that position
11:49:25  which you usually dont...
11:49:45  and there is no way to know where the client wants to go, ie
                        that would mean predicting the future :)
11:50:15  so 'move from' is the easiest/most accurate way to portray it
11:50:28  the server can calculate a target pos from that...
11:51:12  hmm... well we have 'coords' but really don't have: move to 
                        or move from: that is just intepretation in cyphesis side... should
                        there be something else hmm..
11:51:51  make coords mean 'move from' and vel mean 'current velocity' and
                        xclient will work perfectly :)
11:52:03  but for NPCS it may be easier your way... so we could still have
                        both
11:52:15  make a coords2 ?
11:52:20  and a velocity2?
11:52:36  well.. for velocity it's same?
11:52:53  oh yeah... it is the same
11:53:05  what if you request:
11:53:05  ok just need coords2 then... ?
11:53:13  server thinks: it's at 0m
11:53:22  max speed is: 1m/s
11:53:30  client requests: move from 10m ?
11:55:00  well server knows that the client cant go from 0-10 that fast,
                        so it replies with a 'update position' to the max distance, which
                        would be 1m
11:56:08  vector vdir = vto - vfrom; vdir.normalize;  vat = vfrom +
                        (vdir*vspeed)
11:56:37  that will calculate the 'real' position that the client is at if
                        he request to move too far
11:57:08  oops, vspeed should be 'fSpeed'  (v=vector, f=float)
11:57:56  (vat is the position that you would send back to the client)
12:03:02  yeah... so exactly like 3b ;-)
12:03:22  hmm.. we do have sadd attribute in time field.. 
12:03:38  hmm.. in new atlas it has new name:
12:04:05  except that 3b wants a target pos, rather than a from pos...
12:04:08  future_seconds
12:04:33  Sal: well.. nope: it's same with that fudge: from pos
12:04:42  except when it's too far
12:04:43  ie:
12:04:48  it's from pos is possible
12:04:59  if not, then it's target pos starting as near as possible
12:05:12  s/pos is/pos if/
12:08:06  hmm. so I'll just send it like I am now, except send my velocity
                        too
12:08:08  and it should work fine?
12:09:28  yeah... (still thinking about having both 3a and 3b ;-)
12:09:54  but 3b is what you want I think
12:10:17  ok I'll do that then.  I'll make xclient send velocity too...
12:10:30  btw, you measure velocity in milliseconds right?
12:11:04  ie v(0,1,0) means move up at one unit per millisecond?
12:11:58  it's that 1/1000 ratio ;-)
12:12:04  you can treat it like that
12:12:26  (it's still 1m/s but because 1/1000 speedup behaves like ms)
12:12:44  ok xclient does it in milliseconds... so this matches up fine
                        then
12:12:46  s{ms} {m/ms}
12:13:05  i'll do this now....
12:13:07  Sal: it will change for acorn to real time likely... but I
                        tell you when
12:13:19  ok :)
12:13:27  I can * 1000.0f easy :)
12:13:36  you may need to add one attribute (which would always have
                        same value) later... dunno: I'm still thinking about things
12:13:41 * aloril  though so ;-)
12:14:16  maybe something like: future_seconds=-0.5
12:14:33  al can you run the server? And tell me where you see me move?
12:14:55  hmm.. firewall here :-(
12:15:05  oh ok
12:15:08  use displayClient.py
12:15:08  nm then
12:17:45  I need a hand real quick :) where do I insert the code? I have:
12:17:45     loc =
                        createEntity(Atlas::A("coords",coords),Atlas::A("ref",ref),AEND);
12:17:45     Atlas::Object charEnt =
                        createEntity(Atlas::A("id",m_characterId),
12:17:46                                                                                                                   
                        Atlas::A("loc",loc),AEND);
12:17:46     Atlas::Object moveOp = createOperation("move",
12:17:46                                                                                                                           Atlas::A("from",
                        m_characterId), 
12:17:46                                                                                           Atlas::A(charEnt),
12:17:46                                                                                                                           AEND);
12:17:46     sendMsg(moveOp);
12:18:46  that future_seconds stuff?
12:18:48 * Sal  needs to learn Atlas better
12:19:04  no the velocity stuff...
12:19:04  well it would be new attrubte for operation like "from" is
12:19:08  ahh..
12:19:18  first line
12:19:23  just like coords
12:19:51  ok, what's the exact name? "vel" or "velocity" ?
12:20:02  (hint for future: it's in same level as in XML and uses same
                        name)
12:20:18  seems later
12:27:50  sal: I'm thinking about flattening location to same level as
                        all other character attributes are
12:32:07  Al: ''velocity' isnt in the atlas spec...
12:32:23  hmm... move.html has it
12:32:47  see cyphesis/doc for cyphesis specific things
12:32:59  i'm looking
                        at:ftp://ftp.worldforge.org/worldforge/users/aloril/atlas/v0.2.3/index.html
12:33:09  (and atlas/spec/move.html for what atlas should should have
                        (and cyphesis too)
12:33:17  see move.html
12:33:36  and use devel instead of v0.2.3
12:34:03  hmm.. I guess it's soon time to release v0.2.4
12:34:49  hmm i looked here:
12:34:49  ftp://ftp.worldforge.org/worldforge/users/aloril/atlas/devel/operation.html#move
12:35:07  searched the whole page for 'vel'
12:35:37  see move.html instead hmm.. shouldn't it have link to move?
                        hmm..
12:35:52  I'm looking for move.html...
12:36:31  (btw.. same stuff is at csv:forge/protocols/atlas/spec too)
12:38:59  hmm, move.html doesnt mention velocity either :)
12:43:24  ahh.. there is "this sector needs rewrite" :-(
12:44:12  see cvs:forge/servers/cyphesis/doc/atlas
12:45:44  aha :) found it
12:52:39  ouch, cyphesis crashed when I moved, hmm.
12:52:52  hmmm... traceback?
12:52:57     loc = createEntity(Atlas::A("coords",coords),
12:52:58                                           Atlas::A("velocity", vel), 
12:52:58                                           Atlas::A("ref",ref),
12:52:58                                           AEND);
12:53:11  is that correct?
12:53:14  seems right
12:53:25  you create vel same way you crate coords?
12:53:36  yep
12:54:24     return res+self.location.atlas2internal(dict)
12:54:24   File "../../../protocols/atlas/libatlas/libAtlasPy\atlas.py",
                        line 393, in atl
12:54:24  as2internal
12:54:24     tuple(self.coordinates))
12:54:25  TypeError: too many arguments; expected 4, got 6
12:54:25  > ../../../protocols/atlas/libatlas/libAtlasPy\atlas.py(393)atlas2internal()
12:54:27  -> tuple(self.coordinates))
12:54:29  (Pdb)
12:54:49  hmm..
12:55:35  type:
12:55:38  p self.coordinates
12:56:06  (Pdb) p self.coordinates
12:56:07  [0.0, 0.0, 10.0, 0.0, 0.0]
12:56:07  (Pdb)
12:56:31  ahh... hmm.. where those two extra coordinates come?
12:56:53  should be [0.0, 0.0, 10.0]
12:56:57  I have no idea... let me remove velocity and see what happens
12:57:19  can you paste lines before "loc = create..." ?
12:58:05     Atlas::Object coords = Atlas::Object::mkList(0);
12:58:06   coords.append(vPos.x); coords.append(vPos.z);
                        coords.append(vPos.y);
12:58:06     Atlas::Object vel = Atlas::Object::mkList(0);
12:58:06   vel.append(vVel.x); vel.append(vVel.z); vel.append(vVel.y);
12:58:23  hmm... weird
13:00:30 * Forskis has quit (Connection timed out)
13:03:13  Forskis (^forskis@ess.mineral.ualberta.ca) has joined #cyphesis
13:03:14  Sal has quit (Connection reset by peer)
13:03:14  Batlin gives channel operator status to Forskis
13:06:16 ** Sal (~sferro@port16.pontiac05.tir.com) has joined #cyphesis
13:06:23  hmm, Al...
13:06:27  wb
13:07:06  displaymovemnt shows nothing...
13:07:58  hmm...
13:08:17  wait, let me try it with observerclient...
13:08:31  that creates motion, correct? observerclient?
13:09:09  observerclient creates NPCs and some objects for them
13:09:16  yes it does
13:12:40  hmm testclient.py made some movement, observerclient isn't
                        though
13:12:50  neither is xclient...
13:14:54  anyhow, I'm not thinking straight, its late :)
13:15:12 *** Sal is now known as Sal_zzz
13:15:24  night sal
13:15:47  we'll continue later :)
13:15:47  night
13:37:05 * Sal_zzz has quit (Leaving)
14:59:57 * You are now known as aloril_away_1h