Timestamps are in GMT/BST.
| 00:00:07 | Watusimoto_ | My guess is that something isn't being saved properly |
| 00:00:16 | Watusimoto_ | though I suppose that's pretty obvoius |
| 00:01:01 | Watusimoto_ | write a test!! |
| 00:01:14 | | kaen_mbp has joined |
| 00:02:25 | Watusimoto_ | hi kaen_mbp |
| 00:05:39 | | kaen_mbp Quit (Ping timeout: 245 seconds) |
| 00:08:11 | Watusimoto_ | bye kaen_mbp |
| 00:08:34 | raptor | heh |
| 00:26:18 | sam686 | hi raptor, watusimoto, seen my problem yet i had at one time? http://sam6.25u.com/bitfighter/bf_upload_to_db_bug_019d.avi |
| 00:26:30 | raptor | hi sam686 |
| 00:26:36 | raptor | no, i didn't see that. let me look |
| 00:28:04 | raptor | whoa! |
| 00:28:10 | raptor | did your entire level disappear?? |
| 00:28:36 | sam686 | it reverts any unsaved changes that is made |
| 00:28:44 | sam686 | and even blanks out the level when changing filename |
| 00:29:02 | raptor | could that be because it tried to reload a file from the new name? |
| 00:29:15 | sam686 | probably yes |
| 00:29:37 | raptor | side note - there are two bugs, right? the first one being the level credits not saving? |
| 00:29:58 | sam686 | not just level credits, also every unsaved changes |
| 00:30:10 | raptor | ahh |
| 00:31:12 | raptor | huh |
| 00:31:14 | sam686 | I had a spawn point disappear when uploading to DB, because i didn't save after adding spawn point |
| 00:31:26 | raptor | would a good fix be to save the level first? |
| 00:32:23 | sam686 | probably yes, or at least ask that level needs saving |
| 00:40:12 | raptor | ok, i'll take a look, probably tomorrow... i'm sleepy right now |
| 00:40:17 | raptor | good night! |
| 00:41:01 | | raptor Quit () |
| 02:02:46 | | kaen_mbp has joined |
| 02:07:18 | | kaen_mbp Quit (Ping timeout: 250 seconds) |
| 04:04:17 | | kaen_mbp has joined |
| 04:08:38 | | kaen_mbp Quit (Ping timeout: 250 seconds) |
| 04:46:15 | | BFLogBot_ Commit: c6b9130737 | Author: watusimoto | Message: Variable names and the like -- no change in functionality |
| 04:46:17 | | BFLogBot_ Commit: abf7fce68a | Author: watusimoto | Message: Comments |
| 04:46:18 | | BFLogBot_ Commit: bc5f033ff7 | Author: watusimoto | Message: Better to call parent, even when it does nothing |
| 04:46:20 | | BFLogBot_ Commit: e1d914a1ec | Author: watusimoto | Message: Add some sample code (commented out) that will cause Text/Line Items to be removed from clients after player changes teams. TNL does not send the removal until the object has changed somehow. |
| 04:46:21 | | BFLogBot_ Commit: c3fa344bec | Author: watusimoto | Message: Add more tests, do some cleanup and renaming in TNL |
| 04:51:58 | | Watusimoto_ Quit (Ping timeout: 250 seconds) |
| 04:55:40 | | LordDVG has joined |
| 06:05:50 | | kaen_mbp has joined |
| 06:10:09 | | kaen_mbp Quit (Ping timeout: 256 seconds) |
| 06:46:04 | | CrazyLinuxNerd Quit (Quit: Going.. Going.. Gone) |
| 06:46:59 | | CrazyLinuxNerd has joined |
| 07:02:45 | | LordDVG Quit (Remote host closed the connection) |
| 08:07:24 | | kaen_mbp has joined |
| 08:07:38 | | Darrel Quit (Ping timeout: 244 seconds) |
| 08:07:45 | | Darrel has joined |
| 08:11:33 | | kaen_mbp Quit (Ping timeout: 246 seconds) |
| 08:54:47 | | Darrel Quit (Ping timeout: 252 seconds) |
| 08:55:09 | | Darrel has joined |
| 10:08:57 | | kaen_mbp has joined |
| 10:13:28 | | kaen_mbp Quit (Ping timeout: 265 seconds) |
| 10:25:17 | | koda has joined |
| 11:14:48 | | raptor has joined |
| 11:14:48 | | ChanServ sets mode +o |
| 11:14:54 | raptor | good day! |
| 11:28:33 | | kaen_mbp has joined |
| 12:55:47 | | Watusimoto_ has joined |
| 13:20:13 | | Watusimoto_ Quit (Ping timeout: 264 seconds) |
| 13:29:09 | | koda Quit (Quit: koda) |
| 13:38:29 | watusimoto | hi |
| 13:45:13 | raptor | hello |
| 13:53:15 | watusimoto | I learned a lot about TNL scoping last night |
| 13:53:40 | watusimoto | before getting totally stuck on a problem we didn't even know was a problem |
| 13:54:05 | watusimoto | but I woke up this morning with a solution to that, and another bug that, it turns out, I created in my recent mucking around |
| 13:54:25 | watusimoto | hooray for mental downtime |
| 13:54:50 | raptor | the shower, in the morning, is where i usually end up solving the tough problems at work... |
| 13:55:21 | watusimoto | pretty funny how the mind works |
| 13:55:43 | watusimoto | the tnl problem I was trying to solve was you have a red text item, which is visible to you on the red team |
| 13:55:54 | watusimoto | I fixed things so that red text is no longer sent to the blue team |
| 13:56:00 | raptor | oh good |
| 13:56:08 | watusimoto | but if you are on the red team, and change to blue, what should happen? |
| 13:56:09 | raptor | no more client-side hacks! |
| 13:56:22 | watusimoto | the red text is no longer in scope... |
| 13:56:45 | raptor | isn't there a team flag on the network packet? that would need to update the client |
| 13:56:57 | watusimoto | the text didn't change -- there is no flag to set |
| 13:57:01 | watusimoto | only the client changed |
| 13:57:14 | watusimoto | if you change the team of the text, yes, it works as expected |
| 13:57:48 | watusimoto | but if the player changes, what happens is the object is marked as out of scope, but is not actually deleted on the client until the text itself changes somehow |
| 13:58:06 | watusimoto | which it never does, so the now blue player still has access to the red text |
| 13:58:33 | watusimoto | so I found what I think is a relatively elegant solution to that problem, easily implemented, which I will try tonight |
| 13:58:41 | raptor | i thought a team change triggers scope updates for all objects in the vicinity of the player |
| 13:58:54 | watusimoto | it turns out there is a special culling mechanism for when we run out of slots for ghosted objects |
| 13:58:55 | | LordDVG has joined |
| 13:59:11 | watusimoto | the trick will be, I think, to trigger this culling mechanism when you switch teams |
| 13:59:13 | raptor | so add the objects to that |
| 13:59:51 | watusimoto | it's not a list of objects to cull, but rather a process that passes over all objects in scope |
| 14:00:05 | raptor | ah |
| 14:00:14 | watusimoto | anyway, I'll create a mechanism to trigger this manually, and then do that when the ship changes teams |
| 14:00:34 | watusimoto | then the red text will be removed from the blue (formerly red) client |
| 14:00:56 | watusimoto | that same mechanism would work for all sorts of things; mines, for example, or other items that were in scope, but no longer are |
| 14:00:57 | raptor | so does that mean... if i change teams and there was a cloaked, non-moving teammate beside me, do i still see him after the switch? |
| 14:01:12 | raptor | it seems like there should already be a mechanism for this somewhere |
| 14:01:16 | watusimoto | that's a different case; nothing has changed for that, yet |
| 14:01:24 | watusimoto | there is a different case for that out there |
| 14:01:43 | watusimoto | you would not see him because th elcient handles the cloaking |
| 14:01:49 | watusimoto | but you would still know about him |
| 14:01:55 | watusimoto | or rather the client would |
| 14:01:55 | raptor | ah that's right |
| 14:01:59 | raptor | be we don't want it too |
| 14:02:04 | raptor | that should be server-ish side |
| 14:02:07 | watusimoto | but fixing that will be similar |
| 14:02:19 | raptor | *to |
| 14:02:21 | watusimoto | yes, it will be server side at some point |
| 14:02:21 | raptor | yeah, ok |
| 14:02:27 | sam686 | i think part of the reason it doesn't remove non-scope objects from clients right away is to save bandwidth when its back into scope and that object haven't changed, also for when changing teams back and forth doesn't need to resend unchanged text items |
| 14:02:37 | watusimoto | I'm just working on items hidden from one team |
| 14:02:48 | watusimoto | sam686: yes, that's almost certainly it |
| 14:03:19 | watusimoto | I'm not deleting all objects, only triggering the culling mechansim that will remove out-of-scope items |
| 14:03:35 | watusimoto | and I've already changed the way scoping works so that red text is considered out-of-scope for blue teams |
| 14:03:54 | watusimoto | so when combined, we get what we want, without too much overhead |
| 14:04:19 | raptor | i was sure TNL already provided something for this.. |
| 14:04:43 | watusimoto | it provides the culling mechanusm, and will remove the out-of-scope objects if they change somehow (move, for example) |
| 14:05:21 | watusimoto | but I think they decided that a stationary object, once you know about it, you'll always know about it. |
| 14:05:31 | watusimoto | and that usually works, except for text and lines |
| 14:06:04 | watusimoto | another advantage is that we could make red text available to blue players by changing the scoping rules on the server; no mod to client required |
| 14:06:15 | sam686 | back in about 015? it was limited to about 1024 or 2048 ghostable objects per client, i think i did something that removed unscoped items to free enough entries for more ghostable items in scope |
| 14:06:18 | watusimoto | so we could make a server option to show all text to all players, or something |
| 14:06:37 | watusimoto | maybe that mechansim I am referring to was written by you |
| 14:06:48 | watusimoto | it basically gets triggered when there are only 10 slots left |
| 14:07:11 | raptor | sam686 increased it... just for one specific map, i think - Fast Nexus |
| 14:08:33 | sam686 | well, the limit of ghostable objects (and a few other things) can't be changed except between incompatible versions |
| 14:08:37 | watusimoto | having a test set up to test various scenarios has made figuring this out really easy |
| 14:08:47 | watusimoto | tweak tnl, run the test |
| 14:09:19 | watusimoto | I think raptor meant you changed the number globally to make a specific map still work |
| 14:10:00 | raptor | yes |
| 14:10:04 | sam686 | tnlEvents should not be changed or it could break compatibility with master, but tnlGhost is server-clisnt only, master connection don't use tnlGhost |
| 14:10:11 | raptor | just as a history lesson :) |
| 14:10:42 | watusimoto | my fix will change nothing on the clients; only affects when the server culls out-of-scope objects using existing mechanisms |
| 14:10:58 | watusimoto | this could be backported to 019x, though it would hardly be worth it |
| 14:12:17 | raptor | nah... too complicated for 019x |
| 14:12:25 | watusimoto | if you want to see where in the code, look in ghostconnection.cpp, and look for "< 10" |
| 14:12:38 | watusimoto | that's the block that needs to be triggered when a player changes teams] |
| 14:12:55 | watusimoto | another nice feature is it only affects object scoping for the particular client, not all clients |
| 14:27:53 | sam686 | http://sam6.25u.com/upload/text1502/150219_13-26-24.txt something like that might do |
| 14:28:28 | sam686 | noticed that my if(mGhostFreeIndex > MaxGhostCount - 10) check runs the loop 2 times in order to remove unscoped objects.. |
| 14:50:00 | watusimoto | We don't want to remove unscoped objects on every pass... only when the player changes teams |
| 14:50:35 | watusimoto | by keeping unchanging unscoped objects around, it lets "discovered" items show up on the cmdrs map even when the fall out of scope |
| 14:51:41 | watusimoto | oops. earlier I should have written - 10, instead of < 10 :-) |
| 14:52:56 | watusimoto | but yes, your code might do the trick |
| 14:55:04 | sam686 | if you read the function void GhostConnection::removeUnscopedObjects() it only affects 1 client, if you do gameConnection->removeUnscopedObjects() if you put that function into ghostConnection |
| 14:55:33 | watusimoto | yes |
| 14:55:41 | watusimoto | and call that from the c2s change teams |
| 14:55:48 | watusimoto | function |
| 14:55:59 | watusimoto | or rahter, from a function that is called from inside that |
| 15:27:39 | raptor | meeting! back soon |
| 16:53:50 | | koda has joined |
| 17:28:41 | watusimoto | ugh... here at work I've written over 600 lines of code and can't test it at all. who knows if any of it works?!? |
| 17:53:59 | | Watusimoto_ has joined |
| 18:07:16 | raptor | test after full compile and run in production ! |
| 18:18:19 | | LordDVG Quit (Remote host closed the connection) |
| 18:42:23 | | raptor Quit (Remote host closed the connection) |
| 18:45:44 | | koda Quit (Quit: koda) |
| 19:06:06 | | Watusimoto_ Quit (Ping timeout: 246 seconds) |
| 20:15:09 | | Watusimoto_ has joined |
| 21:24:29 | | watusimoto Quit (Quit: Leaving.) |
| 21:50:00 | | koda has joined |
| 22:28:39 | | watusimoto has joined |
| 22:28:39 | | ChanServ sets mode +o |
| 22:29:22 | | koda Quit (Quit: koda) |
| 23:11:13 | | CrazyLinuxNerd Quit (Ping timeout: 264 seconds) |
| 23:37:00 | | raptor has joined |
| 23:37:00 | | ChanServ sets mode +o |