Timestamps are in GMT/BST.
| 01:43:13 | | koda has joined |
| 04:17:45 | | Nothing_Much Quit (Ping timeout: 264 seconds) |
| 04:21:42 | | Watusimoto_ has joined |
| 04:31:02 | | Nothing_Much has joined |
| 04:36:34 | | Watusimoto_ Quit (Ping timeout: 276 seconds) |
| 04:50:36 | | ozbitfighter has joined |
| 04:51:29 | | Watusimoto_ has joined |
| 04:54:07 | | BFLogBot Commit: d41176b70eaf | Author: kaen | Message: Add Socket::isWritable() and wait for a writable socket in HTTPRequest |
| 04:54:12 | kaen | hopefully the levelDB stuff works in windows now |
| 04:55:54 | kaen | what a horrifying incursion into WSA |
| 04:56:11 | kaen | right where its slimy tendrils intertwine with BSD sockets |
| 05:00:39 | kaen | oh boy! |
| 05:01:17 | kaen | I've broken the linux build with a windows fix... |
| 05:01:26 | kaen | how the tables have turned... |
| 05:17:40 | | LordDVG has joined |
| 05:25:19 | ozbitfighter | wb LordDVG |
| 05:25:32 | LordDVG | hello ozbitfighter |
| 05:25:38 | LordDVG | what are you doing? |
| 05:25:53 | ozbitfighter | trying to play teeworlds. |
| 05:26:35 | LordDVG | this is a nice game |
| 05:26:50 | LordDVG | for LAN party |
| 05:27:04 | ozbitfighter | bitfighter or teeworlds |
| 05:27:05 | ozbitfighter | or both? |
| 05:29:48 | ozbitfighter | . |
| 05:30:10 | LordDVG | both |
| 05:47:53 | | Watusimoto_ Quit (Ping timeout: 252 seconds) |
| 05:56:58 | | BFLogBot Commit: 768e7f668691 | Author: kaen | Message: fix compiling on linux |
| 05:56:59 | | BFLogBot Commit: d6b62f750e1d | Author: kaen | Message: understand EINPROGRESS as a WouldBlock error on linux |
| 05:57:01 | | BFLogBot Commit: 7c925d47d875 | Author: kaen | Message: fix warning in udp.cpp |
| 05:57:02 | | BFLogBot Commit: d711d36d12ec | Author: kaen | Message: use fixed connection timeout in HttpRequest |
| 05:58:55 | kaen | I fixed the UnknownError on successfully connect call in linux! |
| 06:09:19 | kaen | sometimes my grammarator goes all wonky... |
| 06:11:43 | ozbitfighter | eh? |
| 06:11:51 | ozbitfighter | speak engliosh! |
| 06:12:00 | ozbitfighter | ah umj Enghrish |
| 06:12:02 | ozbitfighter | English |
| 06:13:44 | kaen | I can Inglush pretty good sometimes |
| 06:14:02 | kaen | but not immediately after waking up :) |
| 06:36:59 | ozbitfighter | This ubuntu font is cool. |
| 06:37:14 | ozbitfighter | But then I thought that about Comic sans when it first came out. |
| 06:38:08 | ozbitfighter | No trebuchet font i mean. |
| 06:48:11 | kaen | watusimoto, does taking a screenshot on windows work for you? |
| 06:48:27 | kaen | and could you try uploading something to the level DB to see if it uploads a screenshot? |
| 07:24:18 | kaen | nevermind, I fixed it |
| 07:25:27 | | BFLogBot Commit: 463b68e875ba | Author: kaen | Message: explicitly use binary mode in readFile |
| 07:42:10 | | raptor has joined |
| 07:42:10 | | ChanServ sets mode +o raptor |
| 07:43:10 | kaen | morning |
| 07:43:18 | raptor | mornig! |
| 07:43:58 | raptor | kaen: you've been busy over the night! |
| 07:44:03 | raptor | and it looks like ugly stuff.. |
| 07:44:09 | kaen | indeed. |
| 07:44:10 | kaen | on both counts. |
| 07:45:32 | raptor | i've always thought that the TNL socket stuff was a little wonky |
| 07:45:45 | kaen | oh how it is |
| 07:45:57 | raptor | but i never had the courage to go tinkering.. |
| 07:46:32 | raptor | is this opposite logic than you intended?: https://code.google.com/p/bitfighter/source/detail?r=7c925d47d8757d1ff1fd51db53e73ff1609726aa |
| 07:47:08 | kaen | oh nope :x |
| 07:47:14 | kaen | nice catch |
| 07:48:19 | kaen | er, I meant "yes". it's wrong as committed. |
| 07:51:23 | | BFLogBot Commit: 86b92fa37c0f | Author: kaen | Message: fix inverted logic in Socket::isWritable() |
| 07:54:39 | kaen | my host still hasn't recovered my node yet... |
| 07:55:56 | raptor | :( |
| 07:59:08 | kaen | also, there is this crazy bug with pleiades regarding authorship and ownership... |
| 07:59:10 | kaen | e.g. http://bitfighter.org/pleiades/levels/view/33 |
| 07:59:18 | kaen | and I can't figure it out for the life of me... |
| 08:09:26 | watusimoto | hi kaen |
| 08:09:31 | kaen | hello |
| 08:09:41 | watusimoto | yes, screenshot works |
| 08:09:45 | watusimoto | at least it did last night! |
| 08:10:08 | watusimoto | and hi raptor |
| 08:11:05 | raptor | hi watusimoto |
| 08:11:19 | kaen | it works/has worked |
| 08:11:44 | kaen | it wasn't opening the temporary screenshot file in binary mode, so the pngs were empty |
| 08:11:59 | kaen | anyway it works now |
| 08:12:27 | kaen | (as far as I know) |
| 08:12:33 | kaen | I'll be back in like an hour |
| 08:17:33 | watusimoto | ok, great |
| 08:17:38 | watusimoto | glad I could help! |
| 08:19:28 | raptor | watusimoto: that variable and respective comment (from the editor) could breed insanity |
| 08:19:41 | raptor | that undoundolevellevl |
| 08:22:31 | watusimoto | allUndoneUndoLevel? |
| 08:22:39 | raptor | yeah, that thingy |
| 08:22:46 | watusimoto | you saw my mail, no? |
| 08:22:54 | raptor | i thought the variable was bad enough, then I say the associated comment |
| 08:22:56 | raptor | yes |
| 08:23:02 | raptor | *saw |
| 08:23:19 | watusimoto | seems clear enough to me :-) |
| 08:23:31 | watusimoto | what would you name it? |
| 08:23:51 | raptor | i'm still not sure I know what it means! |
| 08:24:35 | watusimoto | so if I do an action |
| 08:24:41 | watusimoto | I can then undo it and be back where I started |
| 08:24:58 | watusimoto | if I do two actions, and undo one, I am not back where I started |
| 08:25:05 | watusimoto | but if I undo the second, I am |
| 08:25:08 | watusimoto | clear so far? |
| 08:25:28 | raptor | y |
| 08:25:51 | watusimoto | so that variable points to the undo level at which I have undone all the edits I have made. In the examples I game, it would point to level 0 |
| 08:26:06 | watusimoto | but if I made two changes, then saved, it would point to the 2nd state |
| 08:26:41 | watusimoto | I could undo past that, back to a version before I saved, then redo back to my 2nd state, and I would be back to having made no changes in the level (since my save) |
| 08:26:48 | raptor | ok |
| 08:26:54 | watusimoto | does that make more sense? |
| 08:26:57 | raptor | yes |
| 08:27:05 | watusimoto | so that's what it is! |
| 08:27:19 | watusimoto | the level at which all undos have been undone |
| 08:27:24 | raptor | yes ok |
| 08:27:37 | watusimoto | so... what would you call that? |
| 08:28:20 | raptor | now look at it from my perspective - an unsuspecting, naive coder looks at a variable becaue it showed up in a method he was refactoring |
| 08:28:30 | raptor | he see that variable and comment.. |
| 08:28:41 | raptor | his brain breaks |
| 08:28:58 | watusimoto | I created that var and comment before there were any unsuspecting naieve coders poking around :-) |
| 08:29:24 | watusimoto | but I see you still haven't proposed a more intuitive name |
| 08:29:47 | raptor | :) |
| 08:29:49 | watusimoto | I can only conclude that you agree the name I chose is the best there could be! |
| 08:29:54 | raptor | it's because i'm in the middle of a refactor! |
| 08:29:54 | watusimoto | so thank you! |
| 08:30:14 | raptor | haha |
| 08:55:28 | ozbitfighter | . |
| 09:38:59 | | bobdaduck has joined |
| 09:44:51 | | Nothing_Much Quit (Quit: l8r) |
| 09:45:13 | | Nothing_Much has joined |
| 09:45:17 | | Nothing_Much Quit (Changing host) |
| 09:45:17 | | Nothing_Much has joined |
| 09:59:59 | raptor | ok |
| 10:00:01 | raptor | well |
| 10:00:21 | raptor | i'm done with converting the editor ID dialogs into real UI menus |
| 10:00:36 | raptor | except for one part |
| 10:01:01 | raptor | right now if you try to enter a duplicate ID, it renders red |
| 10:01:11 | raptor | not sure how to do that.. |
| 10:01:18 | raptor | with the current flow of things |
| 10:06:07 | watusimoto | I'm not sure either, off the top of my head, but there is probably a way. I assume you have creaeted a more normal menu structure than the hack that was in place. In this case, I think there are two strategies available -- either create a new menu item after the id has been changed (setting its color appropriately using a possibly yet-to-be-coded design), or maybe adding a callback mechanism that can set the color after the item has been cha |
| 10:06:07 | watusimoto | already have such a callback, not sure) |
| 10:06:30 | raptor | yeah, i just found the callback with the TextEntryMenuItem |
| 10:06:35 | raptor | looks promising.. |
| 10:06:43 | raptor | now to try and hook it up to the rendering method.. |
| 10:12:53 | watusimoto | I suspect we do not have a way to change an entry's color... though we might. If not, it would be easy enough to add, and the callback could just check for dupes and call it |
| 10:17:19 | raptor | 99999 IDs should be enough for anyone, right? |
| 10:17:37 | | koda Quit (Ping timeout: 240 seconds) |
| 10:17:38 | raptor | RIGHT BOBDADUCK? |
| 10:18:03 | bobdaduck | rofl |
| 10:18:17 | bobdaduck | Levelgen carnival is my highest, it has 60 ID'd objects. |
| 10:18:23 | bobdaduck | ....9999 sounds just about right. |
| 10:37:50 | watusimoto | raptor: why the limit to 99999? is that what we had before? |
| 10:38:21 | raptor | we had a limit of 10 digits, which I just kept... so we can go to 9999999999! |
| 10:39:02 | watusimoto | is that under S32max? |
| 10:39:07 | raptor | yes |
| 10:39:09 | watusimoto | I'm too bleary eyed to count the 9s |
| 10:39:18 | kaen | /////////////////////////////////////// __ ___ |
| 10:39:18 | kaen | /////////////////////////////////////// /__ _. ._ _ _ | ._ _ |
| 10:39:18 | kaen | /////////////////////////////////////// \_| (_| | | | (/_ | \/ |_) (/_ |
| 10:39:18 | kaen | /////////////////////////////////////// / | |
| 10:39:20 | raptor | wait actually no... |
| 10:39:21 | raptor | haha |
| 10:39:23 | kaen | gets me every time. |
| 10:39:28 | raptor | i'll reduce it.. |
| 10:39:28 | watusimoto | yay!! |
| 10:39:52 | watusimoto | because we have S32 ids (I think), with positive (user assigned) and negative ones (system assigned) |
| 10:40:03 | watusimoto | of course, U32 has no more digits than S32 |
| 10:40:14 | kaen | surely there's a map of long gametype names to abbreviations somewhere... right? |
| 10:40:24 | watusimoto | probably, yes |
| 10:40:54 | kaen | gametypesenum |
| 10:40:59 | kaen | looks promising |
| 10:41:09 | watusimoto | or ... maybe not -- you may theorteically need to instantiate the gametype to get the short game string |
| 10:41:16 | watusimoto | I'm just not sure |
| 10:41:42 | kaen | well |
| 10:41:46 | kaen | that makes sense actually... |
| 10:42:15 | watusimoto | there is no mapping |
| 10:42:17 | watusimoto | const char *HTFGameType::getShortName() const { return "HTF"; } |
| 10:42:45 | watusimoto | though you could create one by adding to xmacro GAME_TYPE_TABLE |
| 10:43:07 | kaen | grep '::getShortName()' -r . |
| 10:44:08 | kaen | hmm |
| 10:44:18 | watusimoto | ok, I need to head out... I'm staying logged in here, so don't be fooled. I'll be on later. |
| 10:45:55 | raptor | so you can read my variable name complaints in the morning! |
| 10:46:33 | kaen | umm, can we normalize these abbreviations a bit? |
| 10:46:46 | kaen | http://pastie.org/8059988 |
| 10:46:59 | raptor | haha |
| 10:47:09 | raptor | actually |
| 10:47:23 | raptor | maybe there should be another method getAbbrev() |
| 10:47:35 | raptor | and it corresponds to 'SOC' instead of 'S' |
| 10:47:54 | raptor | that method might just be used for in-game display in the game clock |
| 10:48:05 | kaen | I think you're right |
| 10:48:21 | kaen | except that I still think we should just change these methods :) |
| 10:48:33 | kaen | or decide to always use these names |
| 10:48:52 | kaen | because I'm actually just working on pleiades, and I'd like to use the same "short" names |
| 10:49:12 | kaen | and if we added abbreviation methods they'd be unused (as yet) |
| 10:50:04 | raptor | so you think the game timer should also show the same as the levels in the database? |
| 10:50:15 | kaen | yes, whichever that ends up being |
| 10:50:17 | raptor | I'm thinking they should be consistent... |
| 10:50:30 | kaen | I think we should specifically *not* have two ways to abbreviate things. |
| 10:50:33 | raptor | i don't know why watusimoto changed them when redoing the game timer |
| 10:50:41 | raptor | heh, i agree |
| 10:50:57 | kaen | okay |
| 10:51:12 | kaen | I'll just use these for now until we make a decision |
| 10:51:18 | kaen | since it's not in c++ land anyway |
| 10:51:26 | raptor | I think I take issue with 'S' for Soccer |
| 10:51:32 | kaen | ditto |
| 10:51:34 | raptor | S can be anything! |
| 10:51:57 | kaen | I'm thinking use true abbreviations, or first three letters for single word gametypes |
| 10:52:14 | kaen | HTF/CTF/COR/NEX |
| 10:52:25 | raptor | i think bobdaduck had some input once about what they should be.. |
| 10:52:35 | kaen | that's a pretty simple algorithm |
| 10:52:40 | bobdaduck | We should just use the first letters |
| 10:52:42 | kaen | you could guess them without knowing them. |
| 10:52:43 | raptor | he was reorganizing the forums |
| 10:52:45 | kaen | ZON? |
| 10:52:47 | raptor | BIT |
| 10:52:59 | raptor | i think BM is better |
| 10:53:03 | kaen | see, for those ZC and BM make more sense to me and sound better |
| 10:53:08 | raptor | yes, me too |
| 10:53:09 | kaen | and fall into my simple rule :) |
| 10:53:09 | bobdaduck | yeah |
| 10:53:31 | raptor | so they do! |
| 10:57:47 | | LordDVG Quit (Remote host closed the connection) |
| 10:59:21 | ozbitfighter | i should sleep. |
| 10:59:42 | ozbitfighter | where is everyone? |
| 11:01:00 | raptor | Utah, USA |
| 11:06:30 | raptor | i'm using void pointers in callbacks! |
| 11:06:36 | raptor | remember to dynamic cast! |
| 11:11:38 | bobdaduck | I'm trying to make all the points of a nexus' geom move around randomly in levelgen carnival |
| 11:11:42 | bobdaduck | Sup? |
| 11:13:07 | bobdaduck | rofl |
| 11:13:08 | bobdaduck | got it |
| 11:13:30 | | ozbitfighter Quit (Quit: Page closed) |
| 11:13:44 | kaen | uh |
| 11:13:45 | kaen | GAME_TYPE_ITEM( HTFGame, "CoreGameType", "HTF", "Hold the Flag" ) \ |
| 11:14:06 | bobdaduck | math.random(10) - 6 |
| 11:14:07 | bobdaduck | right? |
| 11:14:10 | kaen | how has that not broken anything yet? |
| 11:14:29 | bobdaduck | rofl |
| 11:14:30 | raptor | that looks beautiful! |
| 11:15:24 | bobdaduck | if I'm trying to get an x coord between -5 and 5 |
| 11:15:34 | raptor | maybe it wasn't used properly? |
| 11:16:01 | kaen | in fact bitmatch and ctf are the only two that are correct |
| 11:17:05 | bobdaduck | or will math.random(10) - 6 lead to a higher negative number roll? |
| 11:18:32 | raptor | so that's 1 to 10 minus 6 ... |
| 11:18:39 | raptor | so -5 to 4 ? |
| 11:18:53 | bobdaduck | I'm trying to get -5 to 5 |
| 11:18:57 | bobdaduck | math.random 11? |
| 11:19:02 | kaen | correct |
| 11:19:59 | raptor | i thin it starts at 1 |
| 11:20:01 | bobdaduck | oh marvelous |
| 11:20:02 | raptor | *think |
| 11:20:03 | raptor | but |
| 11:20:09 | raptor | we actually override math.random |
| 11:20:27 | raptor | so it's actually random |
| 11:20:32 | raptor | ish |
| 11:21:24 | bobdaduck | I feel like levelgen carnival should start slowing down sometime soon. |
| 11:21:46 | bobdaduck | but it hasn't yet |
| 11:21:58 | bobdaduck | 16 ontick functions |
| 11:22:37 | bobdaduck | And in DnD its like 5 ontick functions per player |
| 11:22:52 | bobdaduck | So the threshold of "you're doing too many things each tick" is about... 25. |
| 11:23:50 | raptor | ok dynamic_cast of void* is not allowed |
| 11:23:51 | raptor | stink |
| 11:32:02 | raptor | make sense though.. |
| 12:20:43 | | bobdaduck Quit (Remote host closed the connection) |
| 13:28:44 | | bobdaduck has joined |
| 13:47:20 | | LordDVG has joined |
| 13:54:56 | kaen | wow. this is the latest announcement from my vps host: http://pastie.org/8060604 |
| 13:55:47 | bobdaduck | okay? |
| 13:56:08 | raptor | oh lovely |
| 13:56:34 | kaen | so they got hacked, lost all of our data, had a bad backup/restore system, were unable to perform restores for everbody, and said "screw it, you get a 'fresh' VPS" |
| 13:56:35 | raptor | is it back that when I saw the word 'Chicago', I thought "that figures.." |
| 13:56:44 | raptor | *bad |
| 13:56:52 | bobdaduck | lol |
| 13:56:55 | kaen | i.e. with none of my data (and work building the cross compiler toolchains) |
| 13:57:02 | raptor | NOOOooooo |
| 13:57:06 | kaen | yeah. |
| 13:57:21 | bobdaduck | It says you can open a ticket and they can restore? |
| 13:57:42 | raptor | yeah, open a ticket and slip a little under the table *wink*wink* |
| 13:58:00 | kaen | it's worth a shot |
| 13:58:18 | raptor | well with 'Chicago' in the name, I think that's what they're expecting... |
| 13:58:27 | kaen | lol :) |
| 13:58:29 | raptor | I'm not prejudiced or anything.. |
| 13:58:40 | raptor | ok, I am, and should shut up.. |
| 13:58:51 | bobdaduck | lol |
| 13:58:59 | kaen | yep |
| 13:59:03 | kaen | still can't access the control panel |
| 13:59:21 | kaen | top comment on the blog post I pastied: |
| 13:59:26 | kaen | "You get what you pay for" |
| 13:59:36 | bobdaduck | rofl |
| 13:59:57 | kaen | yeah... so I don't even have a "fresh" vps available yet |
| 14:00:12 | kaen | I have a large greyed-out control panel button |
| 14:00:37 | kaen | and I'm missing a static IP address... |
| 14:00:40 | kaen | I used to have two |
| 14:01:48 | | LordDVG Quit (Remote host closed the connection) |
| 14:08:57 | bobdaduck | Are dungeons still a thing? |
| 14:09:01 | bobdaduck | I'm making another dungeon |
| 14:15:37 | kaen | I fixed gametype display on pleiades |
| 14:15:46 | kaen | and added a drop-down for the search page |
| 14:16:05 | raptor | OK I need to display an error message in the editor... |
| 14:16:07 | kaen | but you have to edit/update your levels for the gametype to change |
| 14:16:08 | raptor | somehow |
| 14:16:20 | raptor | oooo drop-down |
| 14:16:27 | kaen | I used displaySaveMessage("...", false) |
| 14:16:36 | raptor | thanks! |
| 14:16:36 | kaen | for level uploading errors |
| 14:19:48 | raptor | We don't have a framework for really preventing duplicate IDs |
| 14:20:42 | raptor | and I don't feel like writing one... |
| 14:20:49 | kaen | how about just preventing inputting a duplicate ID into the editor menu? |
| 14:21:01 | raptor | ! |
| 14:21:04 | | Watusimoto_ has joined |
| 14:21:07 | raptor | that's such a simple and great idea |
| 14:27:28 | raptor | thank you for saving my sanity |
| 14:28:41 | kaen | just returning the favor :) |
| 14:35:56 | Watusimoto_ | hi |
| 14:36:05 | raptor | hello |
| 14:36:28 | raptor | I've only spend the better part of two days on this... I hope to get it done soon.. |
| 14:41:20 | Watusimoto_ | raptor: do you want/need my help on anything at the moment? |
| 14:42:12 | | BFLogBot Commit: b7ffa7467ea7 | Author: watusimoto | Message: Try a star goal zone icon |
| 14:42:13 | | BFLogBot Commit: c83ac67ce02d | Author: watusimoto | Message: Bursts explode on contact with turrets, ffps, and all ships except that of the shooter |
| 14:42:15 | | BFLogBot Commit: 7ad829748a00 | Author: watusimoto | Message: Merge |
| 14:43:04 | raptor | I think I'm OK now... with enough casting and callbacks, I've finally gotten to the point that we have similar functionality as before |
| 14:46:00 | raptor | should a private member be: mHasError OR mError ? |
| 14:51:40 | Watusimoto_ | I like mHasError |
| 14:52:09 | raptor | oh my goodness it works! |
| 14:52:13 | raptor | I think I can even check-in! |
| 15:04:31 | raptor | here she comes! |
| 15:05:37 | | BFLogBot Commit: fe16291762dd | Author: buckyballreaction | Message: Convert our old Editor 'EntryMode' to use a real UI. Also, for ID input, prevent saving a duplicate ID. What do you think of my implementation? |
| 15:07:13 | bobdaduck | oh man |
| 15:07:15 | bobdaduck | there she is |
| 15:07:50 | raptor | I'm closing down UIEditor.cpp! may I never see you again for at least a week! |
| 15:08:05 | bobdaduck | lol |
| 15:08:52 | raptor | let's test this burst-on-impact stuff... |
| 15:11:10 | raptor | works well! |
| 15:11:56 | bobdaduck | huh? |
| 15:11:58 | raptor | Watusimoto_: is burst-on-impact stuff client-side predicted? (and if not, can it be?) |
| 15:12:09 | raptor | bursts explode on direct impact with a ship now |
| 15:12:15 | raptor | and turreds/ffps |
| 15:12:23 | raptor | *turrets |
| 15:13:05 | bobdaduck | ...huh. |
| 15:13:12 | Watusimoto_ | no and maybe |
| 15:13:36 | Watusimoto_ | but usually we only client-side predict stuff that is reversible... unlike a burst explosion |
| 15:13:43 | raptor | i seem to remember that bursts/mines/seekers were a little weird client-side.. |
| 15:13:49 | raptor | yes that.. |
| 15:13:51 | raptor | ok |
| 15:33:47 | Watusimoto_ | ok, so I implemented the bursts because kaen suggested it in a forum thread, and people seemed to agree |
| 15:33:54 | Watusimoto_ | if it doesn't work, it's trivial to remove |
| 15:35:55 | kaen | you still on raptor? I'm building right now to test |
| 15:36:28 | raptor | hi |
| 15:36:43 | raptor | Watusimoto_: i like the burst thingy |
| 15:36:51 | Watusimoto_ | good |
| 15:37:02 | Watusimoto_ | we can see how it works with a little lag |
| 15:37:05 | Watusimoto_ | it should be ok |
| 15:37:40 | Watusimoto_ | one thing we might be able to do is make it not bounce when it hits a target client-side (but not explode either) that might address some (supposed, not demonstrated) wonkiness |
| 15:37:52 | kaen | Assert: Expected userdata! in /home/charon/code/bitfighter/zap/LuaWrapper.h line 324 |
| 15:38:07 | raptor | oh... yeah.. umm... LuaW... |
| 15:38:22 | raptor | so bots are sort of broken unless it's just you and a bot |
| 15:38:44 | kaen | kicked the bots |
| 15:39:52 | bobdaduck | A lot of things are sort of broken... |
| 15:45:13 | Watusimoto_ | want to work on luaw? |
| 15:45:21 | raptor | sure! |
| 15:46:03 | raptor | ok, results of playtesting with kaen |
| 15:46:15 | Watusimoto_ | alright, what do I need to do to get to a good starting point? No hurry, take your time |
| 15:46:16 | raptor | the burst needs some client-side prediction somehow.. |
| 15:46:29 | raptor | Watusimoto_: looking.. |
| 15:46:43 | Watusimoto_ | I was afraid of that |
| 15:47:14 | kaen | are other bullet collisions CSP'd? |
| 15:47:38 | raptor | i could actually never tell with bullets... |
| 15:47:45 | kaen | I think the "reversible" criteria is a pretty good one |
| 15:47:50 | raptor | i think so, but since the explosion isn't so large.. |
| 15:49:10 | raptor | Watusimoto_: let's start in LuaW_push |
| 15:49:43 | Watusimoto_ | I think bullets are not csp'ed |
| 15:50:03 | Watusimoto_ | ok, what version should I use? the latest, or some forlk? |
| 15:50:19 | raptor | latest please |
| 15:50:45 | Watusimoto_ | ok |
| 15:51:11 | raptor | first, let me get you a diff between us and upstream |
| 15:52:29 | raptor | Watusimoto_: http://sam6.25u.com/upload/luaW_zap-upstream_difference.diff |
| 15:52:40 | raptor | ok so |
| 15:52:44 | raptor | basically what happens is |
| 15:53:00 | Watusimoto_ | ok, so the version we are looking at is the old working, leaky version |
| 15:53:06 | raptor | no |
| 15:53:26 | raptor | I updated our LuaW to have everything in upstream plus our proxies |
| 15:53:37 | raptor | that is what is in the repo now |
| 15:53:55 | raptor | so in _push, if it finds that the BfObject has a proxy, it looks for it in the LuaW cache |
| 15:54:01 | raptor | if it finds it in the cache, it uses it |
| 15:54:30 | Watusimoto_ | ok... does our current work or crash? |
| 15:54:35 | raptor | that works... but only if there is one script running (one of either a robot or levelgen). I did almost all of my testing with robots |
| 15:54:37 | Watusimoto_ | just so I'm oriented |
| 15:54:45 | Watusimoto_ | two scripts crash |
| 15:54:49 | raptor | it 'works' and throws an assert |
| 15:54:55 | raptor | no, they don't crash |
| 15:55:02 | Watusimoto_ | ok, and this problem is because of the changes you made |
| 15:55:03 | raptor | unless you consider the assert the crash |
| 15:55:28 | raptor | yes - so consider this problem completely new, like we're starting from a clean slate |
| 15:55:30 | Watusimoto_ | and the changes were merging with upstream, except for what's in the diff |
| 15:55:33 | Watusimoto_ | ok |
| 15:55:35 | Watusimoto_ | fine |
| 15:55:47 | raptor | yes |
| 15:56:05 | Watusimoto_ | so push looks in the cache if a proxy exists |
| 15:56:22 | Watusimoto_ | because the only way a proxy could exist is if it were creaetd and put in the cache, if I recall correctly |
| 15:56:38 | raptor | yes |
| 15:56:41 | Watusimoto_ | ok |
| 15:57:22 | raptor | so basically our state is we've added our proxies to upstream LuaW |
| 15:57:30 | raptor | that's it |
| 15:57:38 | raptor | I reverted any other hacks along the way |
| 15:57:48 | raptor | ok |
| 15:57:49 | raptor | so |
| 15:57:53 | raptor | what happens |
| 15:58:15 | raptor | if another script runs, the cache loses its objects |
| 15:58:42 | raptor | so if i add a second s_bot, _push will find the proxy of the first s_bot but not the cache item |
| 15:59:12 | raptor | this returns nil: LuaWrapper<T>::identifier(L, obj) |
| 15:59:14 | Watusimoto_ | I'm confused |
| 15:59:21 | Watusimoto_ | bot 1 runs |
| 15:59:25 | raptor | the one right under if(proxy) |
| 15:59:30 | raptor | yes bot 1 runs |
| 15:59:33 | raptor | good cache |
| 15:59:40 | Watusimoto_ | it hits luaw, no proxy, luaw creates proxy and caches userdata |
| 15:59:44 | raptor | yes |
| 15:59:45 | Watusimoto_ | bot 2 runs |
| 15:59:51 | Watusimoto_ | it has no proxy |
| 15:59:59 | raptor | so far so good |
| 16:00:07 | Watusimoto_ | luaw detects this creates a proxy, and caches the second userdata |
| 16:00:11 | raptor | correct |
| 16:00:14 | raptor | however |
| 16:00:21 | Watusimoto_ | hold on |
| 16:00:34 | Watusimoto_ | so we have 2 user datas cached using the addresses of our 2 proxies |
| 16:00:34 | raptor | by the time it caches the second userdata, the cache for the first has disappeared, but *not* its proxy object |
| 16:00:36 | Watusimoto_ | ok |
| 16:00:47 | Watusimoto_ | why did the cache disappear |
| 16:00:50 | raptor | exactly! |
| 16:00:54 | raptor | i spent hours and hours |
| 16:00:58 | Watusimoto_ | it shouldn't be removed until the proxy object is removed |
| 16:01:03 | raptor | correct! |
| 16:01:06 | Watusimoto_ | ok |
| 16:01:13 | Watusimoto_ | so is the first bot still alive and well? |
| 16:01:16 | raptor | printfs everywhere, dozens of recompiles |
| 16:01:23 | raptor | yes, the first bot is still alive and well |
| 16:01:32 | raptor | if I were to remove the asserts in _push |
| 16:01:35 | Watusimoto_ | but its cache has magically disappeared |
| 16:01:39 | raptor | correct |
| 16:01:51 | Watusimoto_ | and the reason we need the cache is to maintain consistent userdatas |
| 16:02:03 | Watusimoto_ | (not the key issue here, but trying to rmember how this all works) |
| 16:02:07 | raptor | yes |
| 16:02:10 | Watusimoto_ | ok |
| 16:02:11 | raptor | also to save processing |
| 16:02:14 | Watusimoto_ | yes |
| 16:02:17 | raptor | and memory |
| 16:02:24 | Watusimoto_ | though the first is the most important, I think |
| 16:02:28 | Watusimoto_ | but nonethelss |
| 16:02:45 | raptor | so the side effect of removing the asserts... |
| 16:02:50 | Watusimoto_ | and all this happens with the code in the repo |
| 16:02:55 | Watusimoto_ | that we're looking at |
| 16:02:58 | raptor | is that our logic returns the userdata of the second bot for the first |
| 16:03:05 | raptor | and basically all bots run in harmony |
| 16:03:17 | raptor | but that's not the real issue - just a side effect so you know |
| 16:03:28 | Watusimoto_ | which assert trips? |
| 16:03:31 | raptor | yes, with the code in the repo |
| 16:03:34 | Watusimoto_ | line 324 or 325? |
| 16:03:42 | raptor | both |
| 16:03:46 | raptor | if you continue |
| 16:04:02 | Watusimoto_ | 311 proves our proxy exists |
| 16:04:03 | raptor | line 314 actually puts 'nil' on the stack instead of the ID |
| 16:04:43 | Watusimoto_ | so that's the real problem... the asserts follow on from that? |
| 16:04:51 | raptor | correct |
| 16:05:04 | Watusimoto_ | so the question is why does 314 push nil |
| 16:05:04 | raptor | i've printed out the entirety of the cache at a dozen different points |
| 16:05:29 | raptor | as soon as the second bot is added, the cache is already empty in _push |
| 16:05:47 | raptor | 314 is nil because the cache is empty |
| 16:06:02 | raptor | there's no longer an userdata there |
| 16:06:11 | Watusimoto_ | so the identifier comes from luaW_defaultidentifier(lua_State* L, T* obj)? |
| 16:06:26 | Watusimoto_ | (because we use the default identifier function, and don't override) |
| 16:06:31 | raptor | yes, and that is basically the userdata pointer as the id |
| 16:07:00 | Watusimoto_ | lua_pushlightuserdata(L, obj); ==> pushes address of obj |
| 16:07:28 | Watusimoto_ | i.e. address of the proxy object |
| 16:07:44 | raptor | yes, the address, that's right |
| 16:07:51 | Watusimoto_ | so, to b e clear, this pushes nil? |
| 16:07:52 | Watusimoto_ | LuaWrapper<T>::identifier(L, obj); |
| 16:07:55 | raptor | yes |
| 16:08:03 | Watusimoto_ | then what is the address of obj? |
| 16:08:03 | raptor | but only after the second bot is added |
| 16:08:17 | raptor | if there's only one bot, it finds it in the cache OK |
| 16:08:37 | raptor | obj is a BfObject* |
| 16:08:52 | Watusimoto_ | because that's only pushing the address of obj, and obj is not null, so it has an address... so where does the nil come from? |
| 16:09:21 | raptor | it is nil because ::identifier is looking up the userdata by address in cache table. since it can't find it, it pushes nil |
| 16:09:32 | Watusimoto_ | no that's not what it's doing on 314 |
| 16:09:38 | raptor | oh wait |
| 16:09:41 | Watusimoto_ | 314 is only pushing the address |
| 16:10:08 | Watusimoto_ | I think the bug is lower down, where the lookup actually happens |
| 16:10:15 | raptor | wait! you're right |
| 16:10:20 | Watusimoto_ | 319 |
| 16:10:21 | raptor | i was mistaking, it is pushing the address |
| 16:10:28 | raptor | 319 returns nil |
| 16:10:30 | raptor | dug |
| 16:10:31 | raptor | duh |
| 16:10:33 | raptor | sorry :/ |
| 16:10:35 | Watusimoto_ | ok, so the address that's being pushed is correct |
| 16:10:40 | Watusimoto_ | but the lookup is going wrong |
| 16:10:53 | raptor | yes |
| 16:11:03 | Watusimoto_ | one thing to check is if the address is somehow changing |
| 16:11:09 | Watusimoto_ | maybe you've done that |
| 16:11:21 | Watusimoto_ | but a printf("%p", obj) would show that |
| 16:11:39 | raptor | it's not changing |
| 16:11:42 | raptor | of that I am sure |
| 16:11:43 | Watusimoto_ | it's almost certainly not, but if it were, it would explain the problem |
| 16:11:44 | Watusimoto_ | ok |
| 16:11:55 | raptor | the proxy was constant |
| 16:12:03 | raptor | even after commenting out the asserts and having two bots |
| 16:12:11 | raptor | it would alternate between the same two proxy addresses |
| 16:12:20 | Watusimoto_ | so the table is coming from here: |
| 16:12:20 | Watusimoto_ | luaW_wrapperfield<T>(L, LUAW_CACHE_KEY); |
| 16:12:23 | raptor | yes |
| 16:12:43 | Watusimoto_ | but you are sure that adding the 2nd bot doesn't somehow change the addr of the first one |
| 16:12:45 | | bobdaduck Quit (Read error: Connection reset by peer) |
| 16:13:09 | Watusimoto_ | from what you said, it's not the presence of the second bot, but the addition of the 2nd bot that seems to be the problem |
| 16:13:14 | raptor | I saw the addresses of both proxy objects and userdatas, they alternated back and forth |
| 16:13:25 | raptor | well |
| 16:13:30 | raptor | both |
| 16:13:37 | Watusimoto_ | ok, this is probably not the issue anyway |
| 16:13:55 | raptor | with two bots, the cache is cleared at the start of each _push again, on every call |
| 16:14:01 | Watusimoto_ | so the table comes from luaW_wrapperfield |
| 16:14:13 | raptor | I printed out the full cache table at 4 or 5 different spots in _push to verify that |
| 16:14:33 | Watusimoto_ | which in turn just looks up a table in the registry |
| 16:14:38 | raptor | yes |
| 16:14:44 | Watusimoto_ | using the key LUAW_CACHE_KEY |
| 16:15:07 | raptor | yes |
| 16:15:08 | Watusimoto_ | could luaW_initialize be being run twice? |
| 16:15:31 | Watusimoto_ | the second pass could (possibly) wipe the table from the first |
| 16:15:35 | raptor | I wondered that - I don't remember my findings... |
| 16:15:44 | kaen | that's what it sounds like to me |
| 16:15:48 | Watusimoto_ | how can I test? |
| 16:15:54 | Watusimoto_ | start game and add two bots? |
| 16:16:01 | raptor | yes |
| 16:16:04 | Watusimoto_ | I'll stick a break point in there and see how many times it gets hit |
| 16:16:05 | raptor | add one bot |
| 16:16:08 | raptor | then add another bot |
| 16:16:21 | raptor | kaen: you following along? |
| 16:16:23 | raptor | :) |
| 16:16:26 | kaen | indeed :) |
| 16:16:31 | kaen | always watching... |
| 16:16:56 | Watusimoto_ | 611 was only hit once, during game startup |
| 16:17:12 | raptor | I was tired in the NICU for a couple days working on this so I could easily be missing something simple.. |
| 16:17:29 | Watusimoto_ | I'm seriously hoping you did |
| 16:18:50 | Watusimoto_ | 608 gets hit a bunch |
| 16:19:11 | raptor | what about 611 |
| 16:19:22 | Watusimoto_ | only once, during startup |
| 16:19:27 | raptor | well great! |
| 16:19:41 | Watusimoto_ | and 608 without 611 is harmless |
| 16:19:57 | raptor | and not so great, because that means the bug is elsewhere.. |
| 16:20:11 | Watusimoto_ | exaclty |
| 16:21:09 | Watusimoto_ | ok, so you've dumped out the table pointed to by LUAW_CACHE_KEY |
| 16:21:32 | Watusimoto_ | and you see that the first bot's cached userdata is wiped when we add the 2nd bot |
| 16:21:47 | raptor | yes |
| 16:22:06 | raptor | and it is empty again when _push is called on the first bot |
| 16:22:11 | raptor | empty again on the 2nd, etc.. |
| 16:25:30 | Watusimoto_ | so |
| 16:26:17 | raptor | so buttons! |
| 16:27:28 | Watusimoto_ | testing some stuff here |
| 16:30:18 | Watusimoto_ | building takes forever with this stuff |
| 16:30:25 | raptor | yes :( |
| 16:37:39 | Watusimoto_ | ok |
| 16:37:44 | Watusimoto_ | still crashes :-) |
| 16:39:30 | | BFLogBot Commit: 8056bb218081 | Author: watusimoto | Message: Add a tiny bit more logging... not terribly useful |
| 16:39:32 | | BFLogBot Commit: 6b859acab682 | Author: watusimoto | Message: Merge |
| 16:39:53 | Watusimoto_ | well, here's a question |
| 16:40:11 | Watusimoto_ | what if we created a different cache table, or two cache tables, or... |
| 16:40:36 | Watusimoto_ | like I wonder if there's something about the table itself that is the problem |
| 16:40:46 | raptor | I think it would be hard to make work without an indefinite number of cache tables |
| 16:40:51 | raptor | yes |
| 16:41:05 | raptor | so, i saw a note about it being a weak table |
| 16:41:14 | Watusimoto_ | I don't think it is |
| 16:41:32 | raptor | well... rats... because i did research on weak tables |
| 16:41:40 | raptor | and thought that it was garbage collected |
| 16:41:42 | Watusimoto_ | we have this |
| 16:41:43 | Watusimoto_ | // Create a cache table, with weak values so that the userdata will not |
| 16:41:43 | Watusimoto_ | // be ref counted |
| 16:41:43 | Watusimoto_ | lua_newtable(L); // ... nil LuaWrapper {} |
| 16:41:43 | Watusimoto_ | lua_setfield(L, -2, LUAW_CACHE_KEY); // ... nil LuaWrapper |
| 16:41:58 | kaen | lua_pushstring(L, "v"); // ... nil LuaWrapper {} "v" |
| 16:41:59 | Watusimoto_ | but where is the table made weak? |
| 16:42:04 | kaen | 629 |
| 16:42:10 | raptor | the 'v' |
| 16:42:12 | kaen | that sets the metatable mode to weak |
| 16:42:19 | kaen | according to http://lua-users.org/wiki/WeakTablesTutorial |
| 16:42:23 | raptor | oh but that's the main LuaW table, right? |
| 16:42:28 | raptor | not our cache table |
| 16:42:29 | kaen | that's for CACHE_METATABLE |
| 16:42:36 | Watusimoto_ | ah |
| 16:42:38 | raptor | ah |
| 16:42:40 | Watusimoto_ | maybe that's the problem |
| 16:42:42 | kaen | so the metatable of the cache |
| 16:42:54 | raptor | so i put printfs in luaW_gc |
| 16:43:07 | Watusimoto_ | maybe the whole table has been collected |
| 16:43:16 | raptor | and it is only getting run twice (one for each bot) when I exit the level |
| 16:43:18 | Watusimoto_ | what's actually being made weak here |
| 16:43:36 | Watusimoto_ | lua_newtable(L); // ... nil LuaWrapper {} |
| 16:43:36 | Watusimoto_ | lua_setfield(L, -2, LUAW_CACHE_KEY); // ... nil LuaWrapper |
| 16:43:40 | Watusimoto_ | this creates the cache table |
| 16:43:45 | Watusimoto_ | not weak (yet) |
| 16:44:01 | Watusimoto_ | then we create another table |
| 16:44:01 | Watusimoto_ | lua_newtable(L); // ... nil LuaWrapper {} |
| 16:44:14 | Watusimoto_ | that new table is made weak |
| 16:44:15 | Watusimoto_ | lua_pushstring(L, "v"); // ... nil LuaWrapper {} "v" |
| 16:44:15 | Watusimoto_ | lua_setfield(L, -2, "__mode"); // ... nil LuaWrapper {} |
| 16:44:29 | Watusimoto_ | (cache table still strong, i think) |
| 16:44:43 | raptor | yeah, still strong |
| 16:44:59 | Watusimoto_ | the weak table is stored with key LUAW_CACHE_METATABLE_KEY |
| 16:45:20 | raptor | but what does the LUAW_CACHE_METATABLE_KEY actually do? |
| 16:45:22 | kaen | wait |
| 16:45:31 | kaen | that metatable is for the cache |
| 16:45:48 | kaen | setting __mode to "v" on the *metatable* makes the *table* weak |
| 16:45:59 | Watusimoto_ | but it's not yet a metatable |
| 16:46:06 | Watusimoto_ | it's still a table at this point |
| 16:46:20 | Watusimoto_ | in luaW_setfuncs it becomes a metatable, I think |
| 16:46:27 | Watusimoto_ | but why here? |
| 16:46:34 | Watusimoto_ | and could this be the problem? |
| 16:46:35 | kaen | because this is the stock metatable |
| 16:46:47 | Watusimoto_ | yes |
| 16:46:47 | kaen | and it gets assigned to each new userdata that's created I believe |
| 16:46:52 | Watusimoto_ | but we have only one cache table |
| 16:46:57 | Watusimoto_ | and it needs only one metatable |
| 16:47:02 | Watusimoto_ | and that only needs to be set once |
| 16:47:08 | Watusimoto_ | so why not set it where all this is created? |
| 16:47:12 | kaen | there is only one metatable |
| 16:47:13 | Watusimoto_ | why set it in luaW_setfuncs? |
| 16:47:25 | Watusimoto_ | there is one metatable and one cache table |
| 16:47:26 | kaen | but each new userdata in lua needs to have its metatable set |
| 16:47:36 | kaen | to refer to the one metatable for its class |
| 16:47:48 | kaen | so this one global weak meta table is created only once |
| 16:47:51 | kaen | here in initialize |
| 16:47:55 | Watusimoto_ | yes |
| 16:47:58 | kaen | and then assigned to each new ud |
| 16:48:01 | kaen | so this looks correct. |
| 16:48:16 | Watusimoto_ | ahm I see |
| 16:48:17 | Watusimoto_ | ok |
| 16:48:20 | Watusimoto_ | yes, it might well be |
| 16:48:37 | Watusimoto_ | but still, I'm going to check |
| 16:49:02 | Watusimoto_ | luaW_setfuncs should only be run once for each class, not each object |
| 16:49:09 | Watusimoto_ | of it's run once per object, we have a problem |
| 16:51:22 | raptor | I've wondered if there was some sort of conflict between class types and objects |
| 16:51:33 | raptor | like it detects another Robot class and wipes the cache |
| 16:54:14 | Watusimoto_ | raptor, did you create an stof function? |
| 16:54:18 | Watusimoto_ | or was that preexisting? |
| 16:54:54 | Watusimoto_ | i.e. in your last checkin |
| 16:54:54 | raptor | i don't remember, one of the two.. |
| 16:55:01 | raptor | not in my last checkin no |
| 16:55:09 | raptor | i didn't touch stringutils... |
| 16:55:12 | raptor | i think |
| 16:55:16 | Watusimoto_ | because it's no longer compiling |
| 16:55:19 | Watusimoto_ | no you didn't |
| 16:56:10 | Watusimoto_ | weird |
| 16:57:03 | raptor | in the wrong namespace? |
| 16:57:08 | raptor | or using the wrong one.. |
| 16:57:11 | raptor | brb |
| 16:57:33 | | raptor Quit () |
| 16:59:41 | | raptor has joined |
| 16:59:45 | | ChanServ sets mode +o raptor |
| 17:00:35 | Watusimoto_ | ok, I'm going to bed |
| 17:00:43 | raptor | ok |
| 17:00:45 | Watusimoto_ | but before I do, I'm going to tell you what the problem is |
| 17:00:49 | raptor | what |
| 17:00:54 | Watusimoto_ | :-) |
| 17:01:13 | Watusimoto_ | Look at the block beginning with lua_getfield(L, -1, LUAW_CACHE_KEY); |
| 17:01:45 | Watusimoto_ | this is what creates the cache table for a particular class |
| 17:02:08 | raptor | i see two of those.. |
| 17:02:16 | Watusimoto_ | this table should be created once |
| 17:02:18 | Watusimoto_ | c. 706 |
| 17:02:30 | Watusimoto_ | (my numbers are now slightly different) |
| 17:02:55 | raptor | ok |
| 17:02:57 | raptor | i'm there |
| 17:03:06 | Watusimoto_ | so do you agree this should only run once? |
| 17:03:12 | Watusimoto_ | (for a particular class) |
| 17:03:27 | Watusimoto_ | create the cache table for, say robots, then never again do that for robots |
| 17:03:33 | raptor | let's see... that's in setFuncs |
| 17:03:40 | raptor | yes ok |
| 17:03:44 | Watusimoto_ | you agree? |
| 17:04:03 | Watusimoto_ | well, it does get run once, when you start up |
| 17:04:06 | raptor | agree (after reading the comments again) |
| 17:04:08 | Watusimoto_ | as it should |
| 17:04:21 | Watusimoto_ | but when I add two bots, it gets run twice more |
| 17:04:31 | Watusimoto_ | for all classes |
| 17:04:40 | raptor | that's not good |
| 17:04:49 | Watusimoto_ | the thrid time 9for the 2nd bot) will likely wipe out the cache table |
| 17:04:58 | Watusimoto_ | and cause all the mayhem you've observed |
| 17:05:21 | Watusimoto_ | it's getting called from prepareEnvironment() |
| 17:05:29 | raptor | that's only called from _register |
| 17:05:34 | Watusimoto_ | from runScript() |
| 17:05:41 | raptor | it's our code! |
| 17:05:48 | Watusimoto_ | yes |
| 17:06:02 | raptor | oh interesting... so for each of our script environments... |
| 17:06:44 | raptor | wait... isn't that what we want though? does that mean we're using a static cache table when it shouldn't be? |
| 17:06:49 | Watusimoto_ | so I suspect that if we fix this so it only runs once, the problem will go away |
| 17:07:08 | raptor | ok, well that's just on set-up |
| 17:07:11 | Watusimoto_ | if it runs once for each bot, the 2nd bot will wipe out the first cache |
| 17:07:21 | raptor | so no, we want just one... |
| 17:07:27 | raptor | ok |
| 17:07:30 | raptor | good find |
| 17:07:40 | Watusimoto_ | i'm 90% confident |
| 17:07:59 | raptor | better than gov't work! |
| 17:08:15 | Watusimoto_ | not better than the nsa |
| 17:10:26 | kaen | so that comment says once per script type... |
| 17:10:35 | kaen | does it really mean once per L? |
| 17:11:02 | raptor | ha |
| 17:11:06 | Watusimoto_ | where does it say that? |
| 17:11:12 | kaen | registerClasses(); // Register classes -- needs to be differentiated by script type |
| 17:11:13 | raptor | the NSA knows you said that.. |
| 17:11:18 | kaen | 514 LuaScriptRunner |
| 17:12:28 | Watusimoto_ | so, if I recall, that comment is correct |
| 17:12:52 | Watusimoto_ | though |
| 17:13:01 | Watusimoto_ | void LuaScriptRunner::registerClasses() |
| 17:13:01 | Watusimoto_ | { |
| 17:13:01 | Watusimoto_ | LuaW_Registrar::registerClasses(L); // Register all objects that use our automatic registration scheme |
| 17:13:01 | Watusimoto_ | } |
| 17:13:20 | Watusimoto_ | that does not depend on script type, so maybe the comment is wrong |
| 17:13:34 | Watusimoto_ | that should happen only once per L |
| 17:14:01 | Watusimoto_ | as should, I think, registerLooseFunctions |
| 17:14:17 | raptor | correct on the loosey functions |
| 17:14:23 | Watusimoto_ | in fact, I think all of prepareEnvironment should only be run once per L |
| 17:14:26 | Watusimoto_ | i.e. once. |
| 17:14:46 | Watusimoto_ | at least up to here: |
| 17:14:47 | Watusimoto_ | luaL_dostring(L, "e = table.copy(_G)"); |
| 17:15:04 | raptor | like my sandbox? :) |
| 17:15:13 | Watusimoto_ | the part from that line down probably does need to run once perscript |
| 17:15:15 | Watusimoto_ | yes |
| 17:15:20 | Watusimoto_ | like your sandbox |
| 17:16:58 | kaen | building... |
| 17:17:10 | Watusimoto_ | probably all that junk should go here: |
| 17:17:11 | Watusimoto_ | configureNewLuaInstance |
| 17:17:24 | Watusimoto_ | is that what you did, kaen? |
| 17:17:30 | Watusimoto_ | or should I try that here? |
| 17:17:39 | kaen | yes, had to make them static too |
| 17:20:26 | kaen | and then rebuild 80% of the codebase... |
| 17:21:41 | kaen | playing with two bots works fine |
| 17:21:46 | kaen | is that success? |
| 17:21:54 | Watusimoto_ | it is |
| 17:22:00 | kaen | 12 bots |
| 17:22:24 | Watusimoto_ | why static? |
| 17:22:59 | kaen | because configurenewluainstance is static |
| 17:23:26 | kaen | those should be static anyway because they don't depend on any object state :P |
| 17:23:57 | kaen | http://pastie.org/8061231 |
| 17:24:04 | kaen | I added those lines to the end of configurenewluainstance |
| 17:24:14 | kaen | and removed them from prepareenvironment |
| 17:24:58 | kaen | 30 bots |
| 17:25:06 | | BFLogBot Commit: 8933c3a1fa02 | Author: watusimoto | Message: Fix compiling trivial cleanup |
| 17:26:30 | raptor | so does that mean success? |
| 17:26:36 | Watusimoto_ | sounds good! and bots work! |
| 17:26:39 | kaen | I think so |
| 17:26:41 | kaen | can I push? |
| 17:26:44 | raptor | sure! |
| 17:26:49 | Watusimoto_ | so where does that leave us? |
| 17:26:54 | Watusimoto_ | (yes) |
| 17:26:54 | raptor | memory testing.. |
| 17:27:00 | raptor | i'll do some of that.. |
| 17:27:09 | raptor | i know just the level... |
| 17:27:12 | Watusimoto_ | does that mean that the luaw stuff is now upgraded? |
| 17:27:18 | Watusimoto_ | or is there still more to do? |
| 17:27:28 | raptor | define 'upgraded' |
| 17:27:35 | raptor | it is equal with upstream |
| 17:27:35 | Watusimoto_ | finished for the moment |
| 17:27:39 | raptor | (plus our proxies) |
| 17:27:47 | Watusimoto_ | so, leak is fixed |
| 17:27:50 | raptor | could be.. |
| 17:27:51 | Watusimoto_ | (theoretcially) |
| 17:27:55 | raptor | i will do memory testing |
| 17:28:00 | Watusimoto_ | and inconsistent userdata issue is fixed |
| 17:28:05 | Watusimoto_ | (probably) |
| 17:28:10 | raptor | well... luaW_hold is being called |
| 17:28:17 | raptor | before we commented it out... |
| 17:28:29 | Watusimoto_ | oh, right, that was the source of our leak, no? |
| 17:28:32 | raptor | correct |
| 17:28:42 | raptor | because without it, it would do the inconsistent userdata thingy |
| 17:28:43 | Watusimoto_ | wait, we want it commented out? no |
| 17:28:53 | Watusimoto_ | so being called is good |
| 17:28:57 | raptor | yes |
| 17:29:09 | Watusimoto_ | ok, good, so the script in our running bugs page should now work |
| 17:29:12 | raptor | also, that test level of sam686's works without crashing (the test for the inconsistent userdata) |
| 17:29:16 | Watusimoto_ | theoretically of course |
| 17:29:17 | raptor | yes that one |
| 17:29:21 | raptor | i will test that again, too |
| 17:29:21 | | BFLogBot Commit: d8fd5cefa350 | Author: kaen | Message: move once-per-L setup to configureNewLuaInstance |
| 17:29:26 | Watusimoto_ | awesome |
| 17:29:31 | Watusimoto_ | good team work!!! |
| 17:29:35 | kaen | good job guys |
| 17:29:38 | raptor | yay! |
| 17:29:49 | Watusimoto_ | I really like breakpoints |
| 17:29:56 | raptor | haha |
| 17:30:02 | kaen | I <3 gdb so much |
| 17:30:21 | kaen | sometimes I'll just be walking around doing something completely unrelated to programming |
| 17:30:33 | kaen | and I'll just think to myself, "man, I'm glad I have gdb" |
| 17:30:57 | raptor | wait, registerClasses was virtual... |
| 17:31:12 | kaen | it was never reimplemented |
| 17:31:14 | kaen | I checked :) |
| 17:31:18 | raptor | ok phoew |
| 17:32:00 | raptor | Robot::registerClasses() |
| 17:32:14 | kaen | ._. |
| 17:32:24 | raptor | LuaLevelGenerator::registerClasses() |
| 17:32:47 | kaen | robot is a passthrough |
| 17:33:01 | kaen | to LuaScriptRunner::registerClasses |
| 17:33:03 | kaen | somehow |
| 17:33:08 | kaen | I don't quite understand that |
| 17:33:20 | kaen | oh! |
| 17:33:21 | kaen | haha |
| 17:33:33 | raptor | a useless override? |
| 17:33:36 | kaen | yep |
| 17:33:49 | kaen | calls the same method on its parent and does nothing else |
| 17:33:53 | raptor | ha |
| 17:33:58 | raptor | nuke it |
| 17:34:34 | kaen | kind of weird that eclipse didn't find those overrides |
| 17:35:14 | raptor | that's because RObot isn't a subclass of LuaScriptRunner |
| 17:35:24 | raptor | oh wait, yes it is |
| 17:35:28 | raptor | oddness |
| 17:36:17 | | fordcars has joined |
| 17:36:50 | kaen | sounds like pebkac :P |
| 17:37:15 | raptor | had to look that up... |
| 17:37:20 | raptor | that's an acronym now? |
| 17:37:22 | raptor | haha |
| 17:40:36 | kaen | so... |
| 17:40:59 | kaen | now userdata should be equal in between callback invocations? |
| 17:41:20 | raptor | yes, hopefully |
| 17:41:27 | kaen | better check... |
| 17:41:44 | | BFLogBot Commit: 6e6aced18e6e | Author: kaen | Message: remove dead registerClasses overrides |
| 17:41:52 | raptor | oh, when you remove the useless overrides, can you fix the comments next to registerClasses |
| 17:41:56 | raptor | err |
| 17:42:03 | raptor | too quick |
| 17:42:05 | raptor | for me |
| 17:43:57 | kaen | ah |
| 17:47:34 | raptor | now for the memory test (DnD) |
| 17:50:27 | raptor | hee hee: http://sam6.25u.com/upload3.php |
| 17:50:30 | raptor | oops |
| 17:50:33 | raptor | http://sam6.25u.com/upload/3screenshot_26.png |
| 17:50:51 | raptor | star-studded sword! |
| 17:50:56 | | BFLogBot Commit: 503762541b1f | Author: kaen | Message: fix comment by registerClasses() call |
| 17:51:28 | raptor | 2min. of DnD commences... |
| 17:51:32 | | Watusimoto_ Quit (Ping timeout: 240 seconds) |
| 17:51:33 | raptor | (with 10 bots) |
| 17:51:41 | raptor | last time it rose RAM to 160MB |
| 17:54:35 | raptor | ok, after 2.5 min. |
| 17:54:39 | raptor | holding stead at 77MB |
| 17:54:41 | raptor | *steady |
| 17:55:17 | kaen | wow |
| 17:55:29 | raptor | and actually - i think my last test was with 5 bots... |
| 17:55:33 | kaen | dare we say... |
| 17:55:35 | kaen | we fixed it? |
| 17:55:46 | kaen | all the tests run, the performance is in line... |
| 17:55:59 | raptor | i think there may a couple of leaks on our side left.. |
| 17:56:09 | raptor | I just kicked bots, then added 5 more |
| 17:56:13 | raptor | RAM is rising again.. |
| 17:57:02 | raptor | loot bags with stars are cool, too |
| 17:57:27 | raptor | i'll run this test with 5 bots for 10 min.. |
| 18:01:21 | kaen | stars look so awesome... |
| 18:01:56 | kaen | maybe they could only have one outline though |
| 18:02:48 | kaen | looks so cool on that level with the roundabout I'm working on |
| 18:05:10 | raptor | ok, so after 10 min with 5 bots RAM is at 230MB |
| 18:05:17 | raptor | 8 min |
| 18:05:19 | raptor | :( |
| 18:05:40 | kaen | :x |
| 18:06:06 | kaen | and it gets cleared when the next level starts? |
| 18:23:44 | raptor | 450MB |
| 18:23:50 | raptor | (sorry went to dinner) |
| 18:23:54 | raptor | ok restarting level... |
| 18:24:53 | raptor | still 453... |
| 18:25:02 | raptor | ok, exiting to main menu.. |
| 18:26:19 | raptor | still at 455... maybe i need to give it more time? |
| 18:27:14 | kaen | sounds like valgrind could help us out |
| 18:28:14 | raptor | onwards to valgrind! |
| 18:30:24 | raptor | this is going to be resource intensive... |
| 18:38:11 | raptor | i have heated up the house with that test.. |
| 18:40:14 | raptor | ok, well there is one big leak: http://pastie.org/8061394 |
| 18:42:18 | raptor | that's a known leak I think |
| 18:42:21 | kaen | in getCurrLoadout |
| 18:42:25 | kaen | interesting. |
| 18:42:27 | raptor | yes - that's known |
| 18:42:45 | raptor | but I don't think it has any bearing on our big leak.. |
| 18:42:55 | raptor | maybe i need a heap dump.. |
| 18:49:19 | raptor | ok, now how to read massif data |
| 18:50:00 | kaen | try opening it in vim! |
| 18:50:05 | kaen | :) |
| 18:50:06 | raptor | really? |
| 18:50:13 | kaen | uh if you know how to use it a little |
| 18:50:21 | kaen | my vim comes with cool highlighting for valgrind dumps |
| 18:50:45 | kaen | hjkl to scroll |
| 18:51:03 | kaen | and :q<Enter> to quit |
| 18:51:27 | raptor | i know the vim basics... didn't know about the scroll |
| 18:51:33 | kaen | heh |
| 18:55:49 | raptor | graphics!: http://sam6.25u.com/upload/2snapshot12.png |
| 18:56:15 | raptor | here's the file: http://sam6.25u.com/upload/massif.out.4771 |
| 18:56:20 | kaen | l_alloc |
| 18:57:47 | kaen | that is beautiful, btw |
| 18:58:53 | raptor | :) |
| 18:59:57 | kaen | still one in luaw_push it seems |
| 19:00:34 | raptor | that's the loadout one |
| 19:01:43 | kaen | that's also the only mention on l_alloc in that dump |
| 19:01:49 | raptor | huh |
| 19:01:51 | raptor | you're right... |
| 19:02:05 | raptor | maybe that's really the big issue with bots now.. |
| 19:02:23 | kaen | it would make sense |
| 19:02:31 | kaen | think how often bob is pushing loadouts... |
| 19:02:39 | raptor | oh yeah! |
| 19:02:43 | raptor | that's make total sense |
| 19:04:15 | raptor | ha, look at the comment in Ship::lua_getReqLoadout |
| 19:10:41 | kaen | hehehe |
| 19:11:36 | kaen | that made my day. |
| 19:11:39 | raptor | haha |
| 19:11:56 | raptor | i don't think luaW_hold is doing what it was thought it did.. |
| 19:13:02 | raptor | what if we just used scoped_ptr and removed the _hold ? |
| 19:13:10 | raptor | or even... do we need 'new' there at all?? |
| 19:30:35 | raptor | i'm not even sure what to do here... |
| 19:46:33 | | fordcars Quit (Ping timeout: 250 seconds) |
| 20:02:33 | | fordcars has joined |
| 20:04:28 | raptor | i feel like the only way to do this is to cache every loadout combination... |
| 20:04:48 | raptor | luaW_gc is never being called... |
| 20:06:09 | kaen | wait, does there really need to be a hold there? |
| 20:06:32 | kaen | when you push it you either reference it immediately or store it in a real reference. |
| 20:07:00 | raptor | looking.. . _push has _hold in it.. |
| 20:07:45 | raptor | so no, hold is not needed there anymore - i wonder if this comes from using a much older LuaWrapper |
| 20:13:10 | raptor | but i imagine there is still a leak? let me get another heap dump.. |
| 20:14:25 | raptor | (without the _hold) |
| 20:14:58 | raptor | unrelated note: is there some rogue printf statement printing out lots of empty lines at the start of bitfighter? |
| 20:22:27 | raptor | without the _hold, still a big leak with the LuaLoadout |
| 20:41:51 | | Nothing_Much Quit (Quit: l8r) |
| 20:55:54 | raptor | I think the issue is that luaW_gc is not being called on anything but the proxies (and even then not until level end) |
| 21:09:23 | raptor | converting to a shared_ptr self-deletes immediately and loadouts don't work.. |
| 21:13:14 | kaen | raptor, check out this rating display: http://bitfighter.org/pleiades/levels/view/24 |
| 21:13:17 | kaen | oh wait |
| 21:13:28 | kaen | http://bitfighter.org/pleiades/levels/view/16 |
| 21:13:54 | raptor | the big '0' ? |
| 21:14:08 | kaen | eh |
| 21:14:16 | kaen | you have to be logged in |
| 21:14:27 | raptor | ha! |
| 21:14:28 | kaen | and viewing a map that isn't yours |
| 21:14:29 | raptor | i love it |
| 21:14:56 | raptor | green and red, too! |
| 21:52:19 | | bobdaduck has joined |
| 21:52:23 | bobdaduck | bad server up |
| 21:52:39 | raptor | bobdaduck: we found the source of the memory leak |
| 21:52:45 | bobdaduck | shiny! |
| 21:53:51 | raptor | you need to reduce your calles to getCurrLoadout |
| 21:53:55 | raptor | calls |
| 21:54:01 | raptor | make sure that it isn't in onTick... |
| 21:59:48 | bobdaduck | why getcurrloadout? |
| 22:00:01 | raptor | because there's an honest-to-goodness memory leak in c++ |
| 22:00:05 | bobdaduck | xD |
| 22:00:20 | raptor | and it is only created when the lua API want the current (or requested) loadout |
| 22:01:30 | bobdaduck | ..huh. |
| 22:01:32 | raptor | I'm going to merge LuaLoadout and LoadoutTracker... maybe that'll solve the memory leak |
| 22:02:09 | raptor | back in a bit.. |
| 22:02:15 | bobdaduck | how would I solve that |
| 22:02:24 | bobdaduck | like I need to call getCurrLoadout every tick xD |
| 22:02:30 | raptor | really? |
| 22:02:40 | bobdaduck | Nah I suppose not |
| 22:02:51 | raptor | you'll have to somehow figure out how to not do it.. |
| 22:03:07 | raptor | sorry, gotta go, back soon |
| 22:03:32 | bobdaduck | k |
| 22:31:31 | raptor | so i've been thinking |
| 22:31:55 | raptor | instead of checking loadout in each onTick() only do it when a ship enters a loadout zone |
| 22:32:36 | raptor | store the players current loadout somewhere and update it when it changes (also at the same time update their class) |
| 22:47:19 | raptor | bobdaduck: http://sam6.25u.com/upload/3screenshot_26.png |
| 22:54:03 | | bobdaduck Quit (Ping timeout: 248 seconds) |
| 23:06:45 | | Nothing_Much has joined |
| 23:07:10 | | Nothing_Much Quit (Changing host) |
| 23:07:11 | | Nothing_Much has joined |
| 23:24:15 | raptor | ladies and gentlemen! |
| 23:24:28 | raptor | DnD has been playing for 4 min and RAM is at 24 MB |
| 23:24:34 | raptor | (with 5 bots) |
| 23:35:52 | | BFLogBot Commit: e3983fb101c9 | Author: buckyballreaction | Message: Get rid of a nasty, rotten, lying memory leak: the creation of a new LuaLoadout object was actually never being cleaned up, despite its assurances it was - Remove LuaLoadout class and merge it with LoadoutTracker |
| 23:36:41 | raptor | it's been 10 min with 10 bots on DnD |
| 23:36:48 | raptor | I lost 100 K in RAM... |
| 23:36:57 | raptor | \o/ |
| 23:47:32 | | bobdaduck has joined |
| 23:47:56 | raptor | WOW |
| 23:48:00 | raptor | memory leak solved! |
| 23:48:49 | raptor | bobdaduck: i just ran an old version of DnD for 10 min with 10 bots - RAM was at 28 MB the entire time |
| 23:52:01 | bobdaduck | rofl |
| 23:52:04 | bobdaduck | wait um? |
| 23:52:32 | raptor | yes so 019 will not eat your RAM with DnD |
| 23:52:53 | bobdaduck | lol |
| 23:54:04 | bobdaduck | yay |
| 23:54:11 | bobdaduck | I'm probably going to run the changes anyway though |
| 23:54:27 | bobdaduck | keeping loadout calling to onShipEnteredZone will speed it up. Slightly. Supposedly. |
| 23:54:53 | raptor | it may speed it up significantly - it did for me |
| 23:55:24 | bobdaduck | You tried the changes yourself? |
| 23:55:39 | raptor | no |
| 23:55:56 | bobdaduck | oh okay. |
| 23:55:59 | bobdaduck | just trying it in 019? |
| 23:56:20 | raptor | but my change in 019 was a direct result of getCurrLoadout - and I was able to load about 5x as many bots without it freaking out |
| 23:56:42 | bobdaduck | wow. |
| 23:56:43 | raptor | so that method only was slowing everything down |
| 23:57:21 | bobdaduck | did you commit? can I try loading that now? |
| 23:57:26 | raptor | I did commit |
| 23:57:38 | raptor | so Lua is friendly again now |
| 23:57:40 | bobdaduck | dang |
| 23:57:48 | raptor | ? |
| 23:57:49 | bobdaduck | I didn't know the extent of the memory leak |
| 23:57:53 | bobdaduck | But with 15 bots |
| 23:58:00 | bobdaduck | the memory usage |
| 23:58:09 | bobdaduck | which started at 100k ish |
| 23:58:15 | bobdaduck | is now at 750k |
| 23:58:26 | raptor | you mean MB? |
| 23:58:31 | raptor | (not KB..) |
| 23:58:47 | bobdaduck | KB. |
| 23:58:53 | bobdaduck | For whatever reason that's what it tracks it in |
| 23:59:21 | bobdaduck | now its at 1,000,000ish |
| 23:59:24 | raptor | ok... KB is actually pretty small... |
| 23:59:26 | raptor | hahaha |
| 23:59:37 | raptor | that's a large number |
