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