[00:54:13] PK has quit: Read error: 104 (Connection reset by peer)
[02:39:40] dingobloo has joined #peragro-dev
[04:23:29] dingobloo has quit: Read error: 104 (Connection reset by peer)
[06:42:34] iceeey has joined #peragro-dev
[06:42:34] ChanServ sets mode: +o iceeey
[07:04:50] dingobloo has joined #peragro-dev
[08:37:28] iceeey has quit: Remote closed the connection
[11:23:30] dingobloo has quit: Read error: 110 (Connection timed out)
[11:49:18] PK has joined #peragro-dev
[11:49:18] ChanServ sets mode: +o PK
[12:09:46] sueastside has joined #peragro-dev
[12:09:46] ChanServ sets mode: +o sueastside
[13:07:21] caedes has joined #peragro-dev
[14:34:38] dingobloo has joined #peragro-dev
[15:43:36] dingobloo has quit: Read error: 131 (Connection reset by peer)
[15:45:02] dingobloo has joined #peragro-dev
[15:53:10] iceeey has joined #peragro-dev
[15:53:10] ChanServ sets mode: +o iceeey
[15:53:32] <iceeey> hi
[18:14:33] <thebolt> Hi
[18:43:36] dingobloo has quit: Read error: 54 (Connection reset by peer)
[20:25:38] <thebolt|away> iceeey: i'll probably start writing some code later tonight.. i'm going to finish watching a movie and then maybe play some gears of war first though ,)
[20:28:15] <CyaNox> and I'll be checking why commits act strange on the server
[20:43:50] <iceeey> thebolt|away, okay, be sure to check out the wiki later
[22:08:28] thebolt2 has joined #peragro-dev
[22:24:52] iceeey has quit: Read error: 110 (Connection timed out)
[23:18:04] JohnTitor has joined #peragro-dev
[23:18:04] ChanServ sets mode: +v JohnTitor
[23:22:26] thebolt2 changed nick to: thebolt
[23:22:32] ChanServ sets mode: +o thebolt
[23:22:39] <thebolt> Hey
[23:29:15] iceeey has joined #peragro-dev
[23:29:15] ChanServ sets mode: +o iceeey
[23:29:29] JohnTitor has joined #peragro-dev
[23:29:30] ChanServ sets mode: +v JohnTitor
[23:32:32] JohnTitor has joined #peragro-dev
[23:32:33] ChanServ sets mode: +v JohnTitor
[23:32:43] <thebolt> hm, john seems a bit unstable today ;)
[23:32:50] <thebolt> or is it CyaNox playing around with settings?
[23:34:13] <CyaNox> no its me trying to find why its not working properly whyit is working properly on a different machine.
[23:34:22] <thebolt> hehe okay :)
[23:34:43] <CyaNox> so sorry for the mess ... but I really need to figure out why its acting like this.
[23:35:58] <thebolt> sure, just wondered if it was a real problem or an induced one ;)
[23:35:59] <CyaNox> (its btw even worse on another channel and network ... there I'm testing currently with 3 bots ... :p)
[23:37:03] <CyaNox> I'm kinda stumped ...
[23:37:13] <CyaNox> it should work ... and yet it does not.
[23:40:40] <CyaNox> stupid sockets ...
[23:41:27] <iceeey> there are a few issues i ran into when writing that... first how is walking implemented? second, changing behaviors in real-time seems iffy
[23:41:57] <CyaNox> it works fine on my ubuntu laptop, on my win2k box, it worked fine on my old debian box. But its refusing to accept connections on my new server.
[23:44:05] <thebolt> iceeey: yea.. having full roundtrip to server for every walk command every frame or so seems a bit, excessive ;)
[23:44:19] <iceeey> yep
[23:45:41] <thebolt> otoh, the server should be authorative on where you can move
[23:46:57] <thebolt> another issue is at what levels to put thread saftey
[23:47:05] <thebolt> you don't want all code thread safe (for performance reasons)
[23:47:08] <iceeey> yeah, i didn't really mention that
[23:47:46] <thebolt> well, it is more of an implementational issue
[23:47:59] <iceeey> true
[23:48:56] <thebolt> however an important and hard such ,)
[23:49:15] <iceeey> re walking, i guess the client can do whatever prediction/interpolation it wants, but the server will be telling you your position every so often
[23:50:44] <thebolt> yea.. one idea would be that when you click somewhere the client sends a "move here" action, server does some initial checking and then tells client "okay, i think you can move there, start moving" (using client-side CD), then correcting / watching the client every now and then
[23:53:01] <iceeey> random thought: we could have an exception thrown if a client behavior tries to modify a server authoritative property
[23:53:50] <iceeey> because i think the server will just ignore those messages. it won't say "you can't do that"
[23:54:33] <CyaNox> ignore is indeed the best for performance
[23:54:43] <sueastside> exception is a bit much, just log it...
[23:55:10] <iceeey> who says you can't log it?
[23:55:41] <thebolt> i don't think exceptions are right way either
[23:55:50] <thebolt> or well, who's going to trap the exception?
[23:56:19] <iceeey> probably no one and then it will die
[23:56:29] <iceeey> unless you are able to put something higher in the stack
[23:56:57] <thebolt> exactly
[23:57:08] <thebolt> which makes me think it is wrong thing to do
[23:57:15] <thebolt> (very easy way for client to dos the server ;)
[23:57:41] <iceeey> bah
[23:57:49] <iceeey> i meant the exception is on the client side
[23:58:05] <iceeey> because the client also knows which properties are server-authoritative