Timestamps are in GMT/BST.
| 00:05:18 | raptor | Watusimoto, sam686: do you see my name as underlined in the currently playing list on the forums? |
| 00:05:52 | raptor | oh haha |
| 00:05:55 | sam686 | yes |
| 00:06:14 | raptor | so do the following: watch the JSON, load a game |
| 00:06:18 | raptor | no underline |
| 00:06:19 | sam686 | what? it went not underlined for a few seconds? |
| 00:06:22 | raptor | but after 10 seconds |
| 00:06:26 | raptor | it underlines |
| 00:20:36 | | koda Quit (Quit: you can't say 'hello' without saying 'hell') |
| 00:26:27 | Watusimoto | ok, time to relocate to bed |
| 00:26:32 | Watusimoto | good night |
| 00:38:23 | raptor | night |
| 00:57:42 | | Watusimoto Quit (Ping timeout: 260 seconds) |
| 01:22:00 | | Wuzzy Quit (Quit: Wuzzy) |
| 03:59:37 | | raptor Quit () |
| 08:03:12 | | kodaws has joined |
| 08:56:04 | | watusimoto has joined |
| 08:56:04 | | ChanServ sets mode +o watusimoto |
| 11:47:19 | | raptor has joined |
| 11:47:19 | | ChanServ sets mode +o raptor |
| 13:37:42 | | watusimoto Quit (Quit: Leaving.) |
| 13:37:43 | | watusimoto1 has joined |
| 15:03:48 | | raptor Quit () |
| 16:06:37 | | raptor has joined |
| 16:06:37 | | ChanServ sets mode +o raptor |
| 16:06:49 | raptor | good morning! |
| 17:05:16 | watusimoto1 | hi |
| 17:06:46 | raptor | hi |
| 17:18:08 | | iKoda has joined |
| 17:23:38 | | kodaws Quit (Ping timeout: 245 seconds) |
| 17:23:52 | | iKoda_ has joined |
| 17:26:39 | | iKoda Quit (Ping timeout: 245 seconds) |
| 17:26:43 | | iKoda_ is now known as iKoda |
| 18:05:37 | | iKoda Quit (Quit: Colloquy for iPhone - http://colloquy.mobi) |
| 18:30:13 | | watusimoto1 Quit (Ping timeout: 260 seconds) |
| 18:42:45 | | Watusimoto has joined |
| 19:42:07 | | Watusimoto Quit (Ping timeout: 246 seconds) |
| 19:45:20 | | Flynnn has joined |
| 20:00:45 | | Flynnn Quit (Quit: Leaving) |
| 20:19:43 | | Watusimoto has joined |
| 21:27:31 | Watusimoto | hi |
| 21:27:47 | raptor | hi |
| 21:28:32 | Watusimoto | I'm perplexed |
| 21:28:43 | Watusimoto | I solved the "ghost forcefield" bug you reported |
| 21:28:53 | Watusimoto | but I can't figure out why it happens |
| 21:29:11 | raptor | huh? |
| 21:29:16 | raptor | ok |
| 21:29:21 | Watusimoto | somehow, a forcefield is lingering in the gClientGame database after the game end |
| 21:29:31 | Watusimoto | and when the next level starts, it's there |
| 21:29:37 | Watusimoto | definitely client side |
| 21:29:47 | Watusimoto | definitely not added to the database when the level loads |
| 21:29:55 | raptor | odd |
| 21:29:57 | Watusimoto | almost certainly just never cleared out |
| 21:30:10 | Watusimoto | the solution is easy -- clear the database after the game |
| 21:30:16 | Watusimoto | but where does it come from? |
| 21:30:27 | raptor | maybe the object isn't destroyed for some reason? |
| 21:30:59 | Watusimoto | maybe |
| 21:31:09 | Watusimoto | ffs are unusual in one respect; they're not directly added |
| 21:31:16 | Watusimoto | they're only added by the ffps |
| 21:31:34 | Watusimoto | but why did this just start? certainly we would have noticed this earlier |
| 21:33:08 | raptor | well.. |
| 21:33:19 | raptor | there have been odd FF bugs since 016, i think |
| 21:33:23 | raptor | all client-side |
| 21:34:47 | raptor | there was one where a random FF would appear sometimes on a particular map, after playing on sam |
| 21:34:53 | raptor | sam686's server |
| 21:35:09 | Watusimoto | huh |
| 21:35:17 | Watusimoto | did the ff do anything? of just sit there |
| 21:35:26 | Watusimoto | i.e. would it block objects? |
| 21:35:27 | raptor | it sat in the middle of the map, doing nothing |
| 21:35:32 | raptor | it would block me |
| 21:35:41 | Watusimoto | so not client side then |
| 21:35:56 | Watusimoto | or... maybe it could be if we do client side prediction |
| 21:36:01 | raptor | well, client-side predict would stop me wouldn't it? |
| 21:36:01 | Watusimoto | scratch that |
| 21:36:13 | Watusimoto | yeah, probably |
| 21:36:36 | Watusimoto | well whatever... it's fixed, almost |
| 21:39:22 | raptor | FFs are weird |
| 21:59:12 | Watusimoto | well, I came up with an elegantish solution |
| 22:06:20 | | BFLogBot Commit: 90e06a08e537 | Author: watusimoto | Message: Whitespace |
| 22:06:22 | | BFLogBot Commit: c7321e462c79 | Author: watusimoto | Message: Fix problem with ghost forcfields appearing on levels that don't have them. Adds onGameOver() method to client game |
| 22:06:23 | | BFLogBot Commit: 63e93f96ec71 | Author: watusimoto | Message: Remove random garbage inserted on previous commit |
| 22:43:28 | Watusimoto | raptor: did you ever get the skippy test item to get all skippy? |
| 22:44:34 | raptor | argh no |
| 22:45:04 | raptor | i could usually get it to skip, but never reliably |
| 22:48:48 | Watusimoto | is it in your opinon a serious issue? |
| 22:48:57 | Watusimoto | I have an idea how to approach it |
| 22:48:58 | raptor | i say we keep an eye on it |
| 22:49:14 | raptor | so file it in the back of our heads, and move on |
| 22:49:52 | raptor | but, it may be more prominent connecting to a server... |
| 22:51:30 | raptor | uhh... i can't switch to the 'master' user on the master server |
| 22:51:38 | raptor | did you change the password? |
| 22:53:27 | Watusimoto | no |
| 22:54:17 | raptor | sam686: are you doing anything on the master server right now? |
| 22:57:05 | raptor | well, i have to head home - sam686, i kill your connection... someone has changed the password for master |
| 22:57:14 | raptor | if it wasn't you, i am suspicious |
| 22:57:47 | raptor | back later |
| 22:57:50 | | raptor Quit () |
| 23:36:28 | Watusimoto | ok, here are some research notes on testitems skipping about |
| 23:37:09 | Watusimoto | I added a playBoop() line every time a position packet arrived from the server; this made it easy to confirm that the (small) skips I see are very highly correlated to the arrival of a packet from the server |
| 23:37:30 | Watusimoto | I then started printing the difference btwn renderPos and actualPos every frame |
| 23:37:46 | Watusimoto | I found that when the packet arrives, the difference jumps, the gradually settles back to 0 |
| 23:38:03 | Watusimoto | 0.000000 |
| 23:38:04 | Watusimoto | 2.572169 |
| 23:38:04 | Watusimoto | 2.391845 |
| 23:38:04 | Watusimoto | 2.032357 |
| 23:38:04 | Watusimoto | 1.493716 |
| 23:38:06 | Watusimoto | 0.776119 |
| 23:38:08 | Watusimoto | 0.000000 |
| 23:38:15 | Watusimoto | those are the actual sequence of values, just to give you a sense |
| 23:39:00 | Watusimoto | so a packet arrives, adjusts actualpos, then the system tries to pull the actual and render positions back together, and htat creates the visual skip I see |
| 23:39:44 | Watusimoto | so the question I have is why do the client and server actualposes drift apart? |
| 23:40:11 | Watusimoto | I would think they shoudl advance in lockstep, especially when everything is on the same machine |
| 23:51:01 | Watusimoto | so its interesting -- there are three different regimes for sending velociy |
| 23:51:15 | Watusimoto | when vel is 0, we just send a flag, so there will be no rounding errors |
| 23:51:24 | Watusimoto | when vel is low, we send an angle and a length |
| 23:51:43 | Watusimoto | and when it's higher than a threshold, we just send the full x and y components of the point |
| 23:52:10 | Watusimoto | removing the angle/length regime greatly reduced the skipping when a slow object was drifting across space |
| 23:52:22 | Watusimoto | but it made things worse immediately following a collision |
| 23:52:32 | Watusimoto | acutally, I'm going to retest that |
| 23:52:42 | Watusimoto | with a clean restart |