Timestamps are in GMT/BST.
| 00:53:00 | | koda Quit (Quit: I used to be chatting like you. Then I took an arrow in the knee) |
| 02:33:00 | | LordDVG Quit (Remote host closed the connection) |
| 02:36:00 | sam686 | http://sam686.maxhushahn.com/bitfighter/counter_meter.png |
| 02:56:00 | raptor | /j hedgewars |
| 03:04:00 | raptor | interesting sam686 |
| 03:05:00 | sam686 | want to see the code? |
| 03:06:00 | raptor | i would ask watusimoto what he thinks - i don't know if it would be a good addition or not... is there a maximum value stored somewhere for each of those bars? |
| 03:07:00 | sam686 | yes, every CounterMenuItem have a min and max |
| 03:10:00 | raptor | i'm heading in early for the night... |
| 03:10:00 | sam686 | http://sam686.maxhushahn.com/bitfighter/counter_meter.patch |
| 03:11:00 | raptor | looks simple enough |
| 03:11:00 | raptor | i'm thinking that the bars should be aligned |
| 03:12:00 | raptor | if we use them |
| 03:12:00 | sam686 | yes, thats one problem, especially when changing values moves the bar sideways |
| 03:13:00 | sam686 | as in,going from 99 to 100 suddenly moves the whole bar box.. |
| 03:13:00 | raptor | yeah |
| 03:13:00 | raptor | but also, it would look cleaner if all the bar rendering were aligned on the right |
| 03:14:00 | raptor | but i'm falling asleep... so good night! |
| 03:14:00 | sam686 | there is bars in the editor attributes too.. |
| 03:14:00 | | raptor Quit (Remote host closed the connection) |
| 05:33:00 | | sam686 has left |
| 05:52:00 | | karamazovapy Quit (Read error: Connection reset by peer) |
| 10:00:00 | | watusimoto has joined |
| 10:00:00 | | ChanServ sets mode +o watusimoto |
| 10:00:00 | watusimoto | !bug |
| 10:00:00 | BFLogBot | To enter a bug, please make sure it is reproducible and then go to http://code.google.com/p/bitfighter/issues/list | Also, see current buglist for 016: http://bitfighter.org/wiki/index.php?title=Buglist_016 |
| 10:47:00 | | LordDVG has joined |
| 11:47:00 | | CrazyLinuxNerd has joined |
| 12:47:00 | | CrazyLinuxNerd Quit (Quit: Leaving) |
| 15:00:00 | | karamazovapy has joined |
| 15:13:00 | | CrazyLinuxNerd has joined |
| 15:56:00 | | raptor has joined |
| 15:56:00 | | ChanServ sets mode +o raptor |
| 15:56:00 | raptor | good day! |
| 15:59:00 | raptor | nice post karamazovapy... |
| 15:59:00 | raptor | is that your secret? |
| 15:59:00 | raptor | let me look at JPG file format real quick... |
| 16:01:00 | | Watusimoto_ has joined |
| 16:04:00 | CrazyLinuxNerd | hey guys is the TL tracker down? |
| 16:04:00 | CrazyLinuxNerd | woops wrong window, sorry |
| 16:21:00 | watusimoto | hi |
| 16:21:00 | raptor | hi |
| 16:22:00 | watusimoto | looked at the callgrind graphs... not really sure what the problem is |
| 16:22:00 | watusimoto | looks like half our cpu is being sucked up with puzzle solving, which doesn't seem right |
| 16:23:00 | watusimoto | not half, but a big chunk |
| 16:24:00 | raptor | look at the lua piece |
| 16:24:00 | watusimoto | did |
| 16:24:00 | raptor | on 016 there are substantially more resources dedicated to the lua calls |
| 16:24:00 | watusimoto | mostly to looking for objects |
| 16:24:00 | watusimoto | it seems |
| 16:24:00 | raptor | oh, is that what you mean, then? |
| 16:24:00 | watusimoto | if we wanted to pick a single piece |
| 16:25:00 | raptor | ah, doFindItems |
| 16:25:00 | watusimoto | I don't even know if that's changed |
| 16:25:00 | watusimoto | at least not the lua end |
| 16:25:00 | watusimoto | maybe the database slowed down somehow? |
| 16:26:00 | raptor | ok, so in 016 doFindItems is a little over 1/3 the resources of everything under the lua_pcall |
| 16:26:00 | watusimoto | I assume you ran the same robots, same level, same everything to make the comparison |
| 16:26:00 | raptor | correct |
| 16:27:00 | watusimoto | well, we should probably see why doFindItems takes so much more juice now than before |
| 16:27:00 | watusimoto | at least see if the relevant code changed |
| 16:27:00 | raptor | yeah, its only 1/6 the resources in 015a |
| 16:28:00 | watusimoto | oh, I see that the database portion was only 5% |
| 16:28:00 | raptor | but see all the other stuff? lots of 'thunk' |
| 16:28:00 | raptor | so it's not just doFindItems |
| 16:28:00 | watusimoto | lots of dynamic_cast overhead as wel |
| 16:28:00 | raptor | yes.. |
| 16:28:00 | watusimoto | I think I added a significant new use of dynamic_cast (DC) |
| 16:29:00 | watusimoto | casting all the objects to determine their type solved a big design headache |
| 16:29:00 | watusimoto | maybe at the cost of a performance hit |
| 16:29:00 | raptor | looks like that is the major portion of doFindItems |
| 16:29:00 | watusimoto | yes |
| 16:29:00 | watusimoto | so that's something to look at |
| 16:29:00 | watusimoto | actually, that's probably the findItems cost right there |
| 16:30:00 | raptor | yep, i agree |
| 16:30:00 | watusimoto | doesn't look like the event manager adds much overhead, which is good |
| 16:31:00 | raptor | 1.8 million calls to dynamic_cast |
| 16:31:00 | raptor | that is bad |
| 16:32:00 | watusimoto | I wonder if we can dial back the tnlpuzzle thing a little to improve performance |
| 16:32:00 | watusimoto | that uses > 25% of our total cpu |
| 16:32:00 | watusimoto | and accomplishes nothing productive |
| 16:32:00 | raptor | haha, i noticed that big piece, too... |
| 16:32:00 | raptor | that was in 015a |
| 16:32:00 | watusimoto | hasn't changed |
| 16:33:00 | raptor | is that run on every connection? |
| 16:33:00 | watusimoto | the puzzle is supposed to make it expensive to flood the server with bogus connect requeswts |
| 16:33:00 | watusimoto | not sure |
| 16:33:00 | watusimoto | puzzles grow harder with each subsequent request to connect |
| 16:33:00 | watusimoto | maybe we can make that first puzzle really easy |
| 16:33:00 | raptor | yeah, it should be expensive client-side more, i think... |
| 16:34:00 | raptor | or somehow cache the puzzle solutions and change them every hour |
| 16:34:00 | watusimoto | though it's unclear if it's a big cpu hit right at the beginning, then nothing afterwards |
| 16:34:00 | watusimoto | caching would undo the flood protection |
| 16:34:00 | raptor | i bet that's it |
| 16:35:00 | watusimoto | maybe we can try profiling when the network is unplugged to reduce that sort of stuff |
| 16:35:00 | watusimoto | so the dc looks liek the biggest single place to look |
| 16:35:00 | watusimoto | but even subtracting 16 from the lua_pcall still leaves a big number |
| 16:37:00 | raptor | yes - those 'thunks' come from somewhere |
| 16:38:00 | raptor | if you have a patch, i can run another callgrind.. |
| 16:38:00 | raptor | whenever |
| 16:38:00 | watusimoto | also lua_v has increased |
| 16:38:00 | watusimoto | I wonder if that has to do with luavec? |
| 16:38:00 | raptor | i don't know what that is... |
| 16:38:00 | watusimoto | and if my mods there somehow made things worse |
| 16:39:00 | raptor | want me to get a graph from before those changes? |
| 16:39:00 | watusimoto | you could, but it's pretty speculative |
| 16:40:00 | raptor | ok, i'll wait.. |
| 16:40:00 | watusimoto | doing a few quick searches makes me think they're unrelated |
| 16:41:00 | watusimoto | unreleated |
| 16:42:00 | watusimoto | only one change inside luaV related to luavec, but it is the one I was most unsure of |
| 16:43:00 | watusimoto | lets start with the dynamic_cast issue, and see if that can be worked around |
| 16:45:00 | raptor | ok, i don't know where you made those.. i'll check logs |
| 16:45:00 | watusimoto | in lunar, I think |
| 16:45:00 | watusimoto | I can look tonight |
| 16:47:00 | raptor | so ideally, at 015a levels, Robot::idle should take up about 35% of ServerGame::idle() (in my test with 30 bots on a simple bitmatch level) |
| 16:48:00 | raptor | where as now it takes up 99.91% of ServerGame::idle() |
| 16:48:00 | watusimoto | I think the change was to use dynamic_cast to identify certain objects, or maybe to convert arbitrary objects to GameObjects |
| 16:49:00 | watusimoto | 99! |
| 16:49:00 | raptor | three 9s |
| 16:49:00 | watusimoto | that's 27% |
| 16:49:00 | watusimoto | not so bad |
| 16:49:00 | raptor | bad refrence to server uptime... |
| 16:50:00 | raptor | 99.9 = three 9s |
| 16:50:00 | watusimoto | (I know :-) well at least I know somehting about what the issue might be |
| 16:50:00 | watusimoto | bad reference to my kid's math |
| 16:50:00 | raptor | all nuance is lost over IRC.. |
| 16:50:00 | raptor | ha! |
| 16:50:00 | watusimoto | indeed |
| 16:53:00 | raptor | did you say turrets should or should not shoot their own core? |
| 16:53:00 | watusimoto | I hemmed and hawed... probably not |
| 17:04:00 | | BFLogBot - Commit 3b6da2999aea | Author: buckyballreaction | Log: Fix turrets shooting at same team's Cores |
| 17:05:00 | raptor | i think i see the dynamic_cast problem: robot.cpp:827: GameObject *obj = dynamic_cast<GameObject *>(fillVector[i]); |
| 17:05:00 | raptor | fillVector[i] is a DatabaseObject* |
| 17:06:00 | raptor | so, how to get from DatabaseObject* to GameObject* without a dynamic cast? |
| 17:06:00 | watusimoto | mmmm.... not sure that's the problem |
| 17:06:00 | watusimoto | static_cast? |
| 17:06:00 | raptor | well, that's the one called by LuaRobot::doFindItems |
| 17:06:00 | watusimoto | since we don't check the results of the cast, I suppose that would be called |
| 17:06:00 | watusimoto | sorry |
| 17:06:00 | watusimoto | that would be ok |
| 17:06:00 | raptor | i tried that: robot.cpp:827:64: error: cannot convert from base ‘Zap::DatabaseObject’ to derived type ‘Zap::GameObject’ via virtual base ‘Zap::BfObject’ |
| 17:07:00 | watusimoto | ah. |
| 17:07:00 | watusimoto | c-style cast? |
| 17:07:00 | watusimoto | not sure if that would work |
| 17:07:00 | watusimoto | could make databaseObject non-virtual |
| 17:07:00 | watusimoto | by implementing all methods |
| 17:07:00 | raptor | c-style casts is more expensive - it just tries all the casts until it finds one that works |
| 17:07:00 | raptor | (I think) |
| 17:08:00 | watusimoto | implement with things like {TNLAssert(false, "Not implemented!") } |
| 17:08:00 | watusimoto | we do that elsewhere |
| 17:09:00 | raptor | i don't see how it is virtual right now... do you mean just via the methods? |
| 17:09:00 | raptor | I'm looking at DatabaseObject |
| 17:09:00 | watusimoto | yes; either a method is defined with = 0... well that's all I can think of |
| 17:10:00 | raptor | there are 4 virtual methods in DatabaseObject |
| 17:10:00 | raptor | all the rest (about 20) are non-virtual |
| 17:10:00 | watusimoto | virtual methods are not, in themselves, a problem, if we provide an implementation |
| 17:10:00 | raptor | and i see no Parent of it |
| 17:10:00 | watusimoto | can you instantiate a DatabaseObject? |
| 17:10:00 | raptor | yes |
| 17:11:00 | watusimoto | DatabaseObject *x = new DatabaseObject works? |
| 17:11:00 | watusimoto | if so, I don't understand the problem |
| 17:11:00 | raptor | ah, no it doesn't - because it has 'pure' virtual methods with the =0... |
| 17:12:00 | watusimoto | those are what need implementaitons |
| 17:12:00 | raptor | i didn't realize that using pure virtual methods did that to a class.. |
| 17:12:00 | watusimoto | I don't understand why, but know it does |
| 17:12:00 | watusimoto | I mean why it impacts static_casting |
| 17:15:00 | raptor | ok, DatabaseObject *x = new DatabaseObject works now |
| 17:15:00 | raptor | so trying static_cast.. |
| 17:15:00 | raptor | robot.cpp:827:64: error: cannot convert from base ‘Zap::DatabaseObject’ to derived type ‘Zap::GameObject’ via virtual base ‘Zap::BfObject’ |
| 17:16:00 | raptor | clean compiling.. |
| 17:16:00 | watusimoto | ?!? |
| 17:16:00 | raptor | same error |
| 17:16:00 | watusimoto | need to study casting! |
| 17:17:00 | raptor | DatabaseObject is not a child of anything... should it be? |
| 17:18:00 | watusimoto | don't think so |
| 17:18:00 | watusimoto | it's just something that fits into a database |
| 17:18:00 | raptor | ah, i see it: GameObject -> BfObject -> DatabaseObject |
| 17:18:00 | watusimoto | maybe bfObject is virtual? |
| 17:18:00 | raptor | child -> parent.. |
| 17:19:00 | raptor | no pure virtual method sin BfObject |
| 17:19:00 | watusimoto | because you can cast to grandparent |
| 17:19:00 | raptor | well, the problem is taking a DatabaseObject and casting to grandchild of GameObject |
| 17:20:00 | watusimoto | right, well that should work too |
| 17:20:00 | watusimoto | otherwise you could cast to bfobject then to gameobject |
| 17:20:00 | watusimoto | maybe you could try that, just to see where it breaks down |
| 17:21:00 | raptor | huh, that worked... |
| 17:21:00 | watusimoto | really?? |
| 17:21:00 | watusimoto | maybe static_cast can't skip generations... |
| 17:21:00 | watusimoto | if all is working, we should do a search and see if we can now eliminate other dynamic_casts |
| 17:22:00 | watusimoto | and replace them with static or the assert+static cast I like |
| 17:24:00 | raptor | same problem going from BfObject -> DatabaseObject saying its a virtual base |
| 17:24:00 | raptor | but i don't see the pure virtual methods.. |
| 17:24:00 | raptor | in BfObject.. |
| 17:24:00 | raptor | maybe another parent.. |
| 17:25:00 | watusimoto | try instnatiating one; might give clearer error msg |
| 17:27:00 | watusimoto | heading out |
| 17:27:00 | raptor | by |
| 17:27:00 | raptor | grumble grumble |
| 17:28:00 | watusimoto | will try to get at least one furhter case close tonight |
| 17:29:00 | watusimoto | bye |
| 17:32:00 | raptor | bye |
| 17:33:00 | | watusimoto Quit (Read error: Operation timed out) |
| 18:08:00 | Watusimoto_ | hi, for the moment at least |
| 18:08:00 | raptor | hi! |
| 18:08:00 | raptor | i found the problem |
| 18:08:00 | raptor | class GameObject : public virtual BfObject, public NetObject |
| 18:09:00 | raptor | public virtual BfObject <-- this disallows static_cast |
| 18:09:00 | raptor | however, when removing the 'virtual'.. a whole host of problems arise between other classes saying they have ambiguous methods |
| 18:09:00 | Watusimoto_ | interesting... not sure what that virtual means? simply disallows instnatiation? |
| 18:10:00 | Watusimoto_ | ambiguous methods? |
| 18:10:00 | raptor | for example: http://pastie.org/3196440 |
| 18:10:00 | raptor | i guess allowing BfObject to be instantiated provides multiple copies of methods somehow... |
| 18:22:00 | | Watusimoto_ Quit (Ping timeout: 255 seconds) |
| 19:19:00 | | Watusimoto has joined |
| 19:20:00 | Watusimoto | hi again |
| 19:21:00 | Watusimoto | was whisked away for dinner |
| 19:21:00 | Watusimoto | and child strife |
| 19:22:00 | Watusimoto | about the pastie: is the problem that now there are two parent classes implementing a method with a particular name? |
| 19:34:00 | | Little_Apple has joined |
| 19:34:00 | Little_Apple | hi |
| 19:34:00 | karamazovapy | what's up sauce? |
| 19:34:00 | Little_Apple | high |
| 19:34:00 | Little_Apple | soup sauce |
| 19:35:00 | karamazovapy | funny. didn't think you were type. |
| 19:35:00 | Little_Apple | why am i sauce? |
| 19:35:00 | karamazovapy | apple sauce |
| 19:35:00 | karamazovapy | a little apple sauce |
| 19:35:00 | Little_Apple | i hate apple sauce. |
| 19:35:00 | Little_Apple | its like eating crushed up people. |
| 19:35:00 | karamazovapy | you shouldn't say that, you're a nice person |
| 19:36:00 | Little_Apple | i also have hiccups |
| 19:36:00 | Little_Apple | huzzah |
| 19:36:00 | Little_Apple | . |
| 19:36:00 | Little_Apple | crumpet trumpets |
| 19:37:00 | Little_Apple | HEY WAIT |
| 19:37:00 | karamazovapy | waiting |
| 19:37:00 | Little_Apple | SOUP IS SOUPY! DID YOU KNOW THAT?? i didnt. |
| 19:37:00 | karamazovapy | except when it's Snoopy |
| 19:37:00 | Little_Apple | as you can see i am very bored. |
| 19:38:00 | karamazovapy | Opti still hasn't noticed that the thread he's changing names on is actually the New Computer thread |
| 19:38:00 | Little_Apple | lolz |
| 19:38:00 | | CrazyLinuxNerd has left |
| 19:38:00 | Little_Apple | my cats breath smells like cat food |
| 19:38:00 | Little_Apple | DUCK SEASON |
| 19:38:00 | Little_Apple | earwax pops |
| 19:38:00 | Little_Apple | i made up the last one |
| 19:39:00 | Little_Apple | ITSA MEEE |
| 19:39:00 | Little_Apple | MARIOS |
| 19:40:00 | Little_Apple | ITSA LUIGEE |
| 19:41:00 | Little_Apple | they should play bitfighter at mlg. |
| 19:41:00 | Little_Apple | respond. |
| 19:41:00 | Little_Apple | or perish. |
| 19:42:00 | Little_Apple | i see you have chosen obliteration. |
| 19:42:00 | Little_Apple | i shall shoot you through the monitor |
| 19:42:00 | Little_Apple | dangit |
| 19:42:00 | Little_Apple | i missed |
| 19:43:00 | Little_Apple | have a cracker |
| 19:43:00 | Little_Apple | have a pink lamp |
| 19:43:00 | Little_Apple | have a lump of golden poo |
| 19:43:00 | Little_Apple | have a have a |
| 19:44:00 | Little_Apple | oh i forgot |
| 19:44:00 | Little_Apple | _K!!!!!!!1 I HAVE A PROBLEM TO REPORT IN BITFIGHTER |
| 19:44:00 | karamazovapy | yes? |
| 19:44:00 | Little_Apple | i real problem |
| 19:44:00 | Little_Apple | in the f1 menu |
| 19:44:00 | Little_Apple | in the server commands |
| 19:45:00 | Little_Apple | it says set the server password is /setlevpass :| |
| 19:45:00 | Little_Apple | its all mixed up |
| 19:46:00 | Little_Apple | helloooo |
| 19:46:00 | Little_Apple | moooooo |
| 19:46:00 | karamazovapy | hey LA |
| 19:46:00 | Little_Apple | hi |
| 19:46:00 | Little_Apple | did you see it? |
| 19:46:00 | karamazovapy | http://bitfighter.org/forums/viewtopic.php?f=9&t=1130 |
| 19:46:00 | karamazovapy | click on thelink |
| 19:47:00 | Little_Apple | what about it |
| 19:47:00 | karamazovapy | click it |
| 19:47:00 | Little_Apple | i did |
| 19:47:00 | karamazovapy | where did it go? |
| 19:47:00 | Little_Apple | rabbit season |
| 19:47:00 | karamazovapy | no - the link in the post |
| 19:47:00 | Little_Apple | ? |
| 19:47:00 | Little_Apple | which post? |
| 19:48:00 | karamazovapy | the first post in the thread |
| 19:48:00 | Little_Apple | ok |
| 19:48:00 | raptor | Watusimoto: when making BfObject a non-virtual parent, other classes seem to think they have multiple methods of the kind like 'getTeam()' |
| 19:48:00 | Little_Apple | what the dell? |
| 19:48:00 | Little_Apple | "the best of ralph wiggum" |
| 19:49:00 | Little_Apple | why. |
| 19:49:00 | karamazovapy | I like to think of Opti as Ralph Wiggum |
| 19:49:00 | Little_Apple | uhh |
| 19:49:00 | Little_Apple | im on my old g3 |
| 19:49:00 | Little_Apple | i cant exactly watch youtube videos |
| 19:49:00 | Little_Apple | on here... |
| 19:49:00 | Little_Apple | but isnt my animation amazing?? |
| 19:49:00 | Watusimoto | raptor: bummer; you were able to eliminate one set of casts though, right? |
| 19:50:00 | Little_Apple | raptor |
| 19:50:00 | Little_Apple | i has something |
| 19:50:00 | Little_Apple | to tell you |
| 19:50:00 | Little_Apple | i think _k ignored it |
| 19:50:00 | raptor | Watusimoto: no |
| 19:50:00 | Little_Apple | RAPTORRR |
| 19:51:00 | raptor | i was ready to start changing the entire object-model, and then i had to do some work... :) |
| 19:51:00 | Little_Apple | raptor |
| 19:51:00 | Watusimoto | careful |
| 19:51:00 | Little_Apple | in the help menu, the server commands are mixed up :| |
| 19:51:00 | raptor | Little_Apple: i'm a bit busy right now, i can answer if it is quick |
| 19:51:00 | Little_Apple | k |
| 19:51:00 | raptor | Little_Apple: help pages have been cleaned up for 016 |
| 19:51:00 | Little_Apple | ok good :3 |
| 19:53:00 | Little_Apple | karamazovapy: so you imagin opti as a balding child with a flute lodged up his nose? |
| 19:56:00 | Little_Apple | that is rather peculiar. |
| 19:56:00 | Little_Apple | HAVE A BISCUIT |
| 19:56:00 | Little_Apple | FISH AND CHIPS? |
| 20:01:00 | | Little_Apple Quit (Ping timeout: 258 seconds) |
| 20:01:00 | | CrazyLinuxNerd has joined |
| 20:10:00 | raptor | Watusimoto: i was joking - i wasn't going to mess with the object model since i know you put in so much time into it... :) |
| 20:10:00 | Watusimoto | if you can improve it, I'd say great! |
| 20:10:00 | raptor | c++ has been upsetting me of late with all of its gotchas... |
| 20:11:00 | Watusimoto | it might just be more than you bargained for |
| 20:11:00 | | CrazyLinuxNerd Quit (Read error: Connection timed out) |
| 20:12:00 | | CrazyLinuxNerd has joined |
| 20:14:00 | Watusimoto | drawing outlines for items from levelgen script is far more complex than I had thought |
| 20:16:00 | raptor | ha! |
| 20:16:00 | raptor | everything about levelgen was more complex than i thought |
| 20:20:00 | raptor | karamazovapy: i think you were right - not many people are technical enough to know what to do with my SVG converter utility |
| 20:21:00 | karamazovapy | yeah |
| 20:22:00 | karamazovapy | even the ones who say they want to learn things aren't committed enough to do anything on their own |
| 20:22:00 | raptor | sadly, yes... |
| 20:23:00 | karamazovapy | I'm not sure we'll make it through a third "coding club" |
| 20:23:00 | raptor | actually - footloose asked me for help on her homework |
| 20:23:00 | raptor | which i took as a positive sign.. |
| 20:23:00 | karamazovapy | she gets it pretty well, and I think blackbird does too, actually |
| 20:24:00 | karamazovapy | little_apple has a shorter attention span |
| 20:24:00 | raptor | little_apple reminds of 'dug' from the move 'Up' |
| 20:24:00 | raptor | haha |
| 20:24:00 | karamazovapy | yeah |
| 20:26:00 | karamazovapy | either way, we're coming to a sink-or-swim point with coding |
| 20:27:00 | raptor | yes, i think so - the logic required ahead of them may just be at the point of their developed minds |
| 20:28:00 | karamazovapy | it'll be a moderate success if they can figure out how to copy and paste existing code to make their own levelgens |
| 20:33:00 | | sam686 has joined |
| 20:33:00 | | ChanServ sets mode +v sam686 |
| 20:34:00 | | LordDVG Quit (Ping timeout: 276 seconds) |
| 20:36:00 | raptor | argh, OK, since BfObject is no longer a virtual parent, all sorts of evil things happen |
| 20:36:00 | Watusimoto | I'm kind of amazed you're even making the effort, to be honest |
| 20:36:00 | Watusimoto | @r: :-) |
| 20:36:00 | Watusimoto | I hear ya |
| 20:36:00 | raptor | i do not which to go down that route... |
| 20:36:00 | Watusimoto | I'm not even sure that;s the offending cast |
| 20:37:00 | raptor | well, it's the one called on every search object |
| 20:37:00 | raptor | in doFindItems |
| 20:38:00 | Watusimoto | well, I can;t find the one I think it is, so maybe I;m wrong |
| 20:39:00 | Watusimoto | we need a way to avoid the cast altogether |
| 20:39:00 | Watusimoto | testing wall insertion |
| 20:40:00 | Watusimoto | that didn;t work so well... |
| 20:41:00 | raptor | yes - i've started that issue 4 times now... |
| 20:41:00 | Watusimoto | well, I know why you were conufsed |
| 20:42:00 | Watusimoto | there's at least 3 differet dbs that hold bits and parts of the walls |
| 20:42:00 | Watusimoto | we were passing just one of them around, the other two were always referred to directly as members |
| 20:42:00 | Watusimoto | now we need to pass all three around |
| 20:42:00 | raptor | ah |
| 20:42:00 | raptor | wonderful |
| 20:42:00 | Watusimoto | indeed |
| 20:43:00 | Watusimoto | but it may offer a chance to combine the three somehow |
| 20:43:00 | Watusimoto | and thus simplify things a little |
| 20:43:00 | Watusimoto | not sure yet |
| 20:43:00 | sam686 | the problem with static casting is this: "class GameObject : public virtual BfObject, public NetObject" (the virtual part) That prevents the use of "(GameObject *)some_bf_object" |
| 20:43:00 | Watusimoto | all I know is that something is not working, and in a big way |
| 20:44:00 | raptor | sam686: the issue we're having is how to get rid of the dynamic_cast on robot:cpp:827 |
| 20:44:00 | raptor | so see if that reduces the robot overhead |
| 20:45:00 | sam686 | GameObject have virtual BfObject, and BfObject have DatabaseObject |
| 20:46:00 | raptor | and yes, because of the BfObject model being a virtual parent to so many classes, making it not virtual means many objects have several of the same grandparent |
| 20:46:00 | raptor | reminds me of the song: "i'm my own grandpa..." |
| 20:47:00 | Watusimoto | maybe we need a second WallSegmentManager |
| 20:48:00 | Watusimoto | one for regular items, one for items brought in with ctrl-R |
| 20:48:00 | raptor | makes sense to me |
| 20:48:00 | Watusimoto | I think it may be easier than what I'm trying to do now |
| 20:49:00 | raptor | since we have a separate DB for other levelgen items, i think that's a good way to go |
| 20:50:00 | Watusimoto | WSM only has 6 data members |
| 20:50:00 | Watusimoto | 3 of which I'm already dealing with |
| 20:50:00 | Watusimoto | will have to revert a lot of code |
| 20:52:00 | sam686 | there could be 1 easy option for "dynamic_cast on robot:cpp:827", have each DatabaseObject store the pointer of it's own GameObject... |
| 20:53:00 | raptor | sam686: that might work... you mean upon insertion into the DB? |
| 20:53:00 | Watusimoto | that seems wholly wrong to me |
| 20:53:00 | raptor | yes, me too - but i am not above trying :] |
| 20:54:00 | sam686 | yes, maybe even in a constructor of GameObject setting DatabaseObject stuff |
| 20:54:00 | Watusimoto | it pretty much breaks the object model |
| 20:54:00 | karamazovapy | are all the bugs on the current list must-do prior to 016 release? |
| 20:54:00 | Watusimoto | mostly |
| 20:54:00 | Watusimoto | they are mostly editor related, and those are pretty serious |
| 20:55:00 | Watusimoto | the list is getting pretty short, though |
| 20:55:00 | Watusimoto | we're being good about feature creep |
| 20:55:00 | karamazovapy | yeah, I just have no sense of how difficult the fixes are |
| 20:55:00 | karamazovapy | or how that might translate to release date |
| 20:55:00 | Watusimoto | there;s a reason why we saved them for last :-) |
| 20:55:00 | raptor | hehe |
| 20:56:00 | Watusimoto | mostly because we've tried and failed and given up in frustration |
| 20:56:00 | karamazovapy | speaking of release dates getting pushed back, anybody want some top-secret info? |
| 20:56:00 | raptor | 4 times on some! |
| 20:56:00 | karamazovapy | see this highly cool art museum? |
| 20:56:00 | karamazovapy | http://broadmuseum.msu.edu/ |
| 20:56:00 | karamazovapy | not a right angle in the building, the whole thing will be steel and glass |
| 20:57:00 | raptor | wow |
| 20:57:00 | karamazovapy | well the only place they could get to do the glass is a company in germany |
| 20:57:00 | karamazovapy | so the cutting and everything takes a couple weeks, then there's another couple weeks because the glass has to travel by boat to the states |
| 20:57:00 | karamazovapy | it's supposed to open in april |
| 20:58:00 | karamazovapy | ...but surprise! about 40% of the glass panes don't fit |
| 20:58:00 | raptor | ha! |
| 20:58:00 | raptor | sounds like a dream come true |
| 20:58:00 | karamazovapy | this isn't public information yet, but they have to push the grand opening back at least a month |
| 20:58:00 | karamazovapy | and there are works of art coming in from around the world |
| 21:00:00 | raptor | yikes |
| 21:00:00 | karamazovapy | yep. the people in charge are shitting themselves with rage. |
| 21:01:00 | karamazovapy | there's a conference call this afternoon with the germans to see if they have any explanation |
| 21:01:00 | raptor | all the germans i've worked with take pride in being very, very exact |
| 21:02:00 | karamazovapy | they've checked the contractors' work several times, and they're pretty sure it's the glass |
| 21:02:00 | raptor | wow |
| 21:02:00 | karamazovapy | it's very close, but a couple millimeters make the difference |
| 21:03:00 | karamazovapy | anyway - non-public information - don't alert the press |
| 21:03:00 | raptor | ok |
| 21:04:00 | raptor | agreed - but i can't stop them from scanning the log files! |
| 21:04:00 | karamazovapy | eh. shouldn't be a problem. |
| 21:04:00 | karamazovapy | do the IRC logs get crawled by search engines? |
| 21:07:00 | raptor | nope, i disable it in robots.txt |
| 21:07:00 | raptor | actually let me check the new server... |
| 21:08:00 | Watusimoto | if they'd just build a normal building, they wouldn;t have problems like these |
| 21:08:00 | Watusimoto | wow -- no snow. must have been photographed in august |
| 21:08:00 | karamazovapy | yeah, that's what you get for hiring an internationally acclaimed architect |
| 21:09:00 | karamazovapy | those are renders |
| 21:09:00 | raptor | ok, it wasn't disallowed in robots.txt, but is now |
| 21:09:00 | karamazovapy | lol |
| 21:09:00 | Watusimoto | architects are idiots |
| 21:10:00 | Watusimoto | at lest that's what they taught us in engineering school |
| 21:10:00 | karamazovapy | next up: Architects vs. Engineers |
| 21:11:00 | | LordDVG has joined |
| 21:18:00 | raptor | Watusimoto: look what i did: http://199.192.229.168/~raptor/zap_doxygen/ |
| 21:18:00 | raptor | of particular note: http://199.192.229.168/~raptor/zap_doxygen/class_zap_1_1_bf_object.html |
| 21:18:00 | Watusimoto | nice; I've built this before for my own use |
| 21:19:00 | raptor | notice things like SimpleLine is a descendent three times |
| 21:19:00 | raptor | that only works because BfObject is virtual parent |
| 21:19:00 | Watusimoto | this looks weirdd |
| 21:21:00 | raptor | haha: http://199.192.229.168/~raptor/zap_doxygen/class_zap_1_1_simple_line.html |
| 21:21:00 | raptor | now that's awesome |
| 21:21:00 | Watusimoto | like why are all the geometries children of bfObject? |
| 21:21:00 | Watusimoto | good lord |
| 21:24:00 | raptor | i like this one, too: http://199.192.229.168/~raptor/zap_doxygen/class_zap_1_1_ship.html |
| 21:25:00 | raptor | actually, no.. this is my favorite, because it is very complete: http://199.192.229.168/~raptor/zap_doxygen/class_zap_1_1_item.html |
| 21:25:00 | Watusimoto | trying a compile with simpleline not inheriting from bfobject to see what breaks |
| 21:25:00 | raptor | ok |
| 21:26:00 | Watusimoto | a lot, apparently |
| 21:26:00 | raptor | wow, everything breaks! |
| 21:27:00 | raptor | doxygen is great! i don't know why I haven't used this before... |
| 21:28:00 | Watusimoto | I'm not sure I saw this view before |
| 21:28:00 | Watusimoto | it is good |
| 21:32:00 | Watusimoto | maybe we should combine editorObject and gameObject |
| 21:32:00 | Watusimoto | that woudl simplify things |
| 21:32:00 | Watusimoto | could just throw all the editorObject things onto gameobject |
| 21:32:00 | Watusimoto | maybe |
| 21:34:00 | Watusimoto | what a mess |
| 21:39:00 | raptor | wow, Geometry classes are all over the place |
| 21:39:00 | karamazovapy | I read that as an academic statement, as opposed to a coding one |
| 21:39:00 | raptor | haha |
| 21:41:00 | Watusimoto | yeah |
| 21:41:00 | Watusimoto | originally the geometries were separate objects that were soemthing an object had, and to which all geometric work was delegated |
| 21:42:00 | | koda has joined |
| 21:42:00 | Watusimoto | somewhere along the line, it became sopemthing that was inherited |
| 21:42:00 | Watusimoto | not sure why we did that, but it still doesn;t seem right |
| 21:43:00 | raptor | we have BfObject inheriting Geometry... and a host of other classes inheriting bfobject to get the geometry... |
| 21:44:00 | raptor | ok, i've dug myself into a deep hole, i need to restart this... |
| 21:45:00 | sam686 | one possible solution to static cast, or "(GameObject *) some_database_object)" is to get rid of virtual class (BfObject) |
| 21:47:00 | raptor | BfObject was designed in response to this, right? http://stackoverflow.com/questions/6523991/proper-way-to-design-object-hieararchy |
| 21:54:00 | Watusimoto | no |
| 21:54:00 | raptor | well, i mean a similar situation... |
| 21:54:00 | raptor | not specifically that, no |
| 21:54:00 | Watusimoto | I think bfobject preceded the question |
| 21:55:00 | sam686 | looks like: class PointGeometry doesn't need "virtual public BfObject" |
| 21:55:00 | Watusimoto | did you try compiling without it? |
| 21:56:00 | raptor | sam686: yes - i was trying to remove any BfObject parent for any of the Geometry classes, but i ran into compile errors |
| 21:58:00 | raptor | i'm an id10t |
| 21:59:00 | raptor | looks like that dynamic cast is in 015a, too (the one in robot.cpp i keep trying to get rid of...) |
| 21:59:00 | raptor | so that can't be the problem... |
| 21:59:00 | raptor | but at least we now know there are crazy hierarch problems.. |
| 22:06:00 | Watusimoto | did a global search for dynamic_cast, none stood out as being the one I'm thinking of |
| 22:07:00 | raptor | yeah, it's something else i think - doFindItems migh tjust be called more often |
| 22:08:00 | raptor | in 015a, idle calls vs lua_pcall: 1873 vs 2150 |
| 22:09:00 | raptor | in 016: 424 vs 13142 |
| 22:09:00 | raptor | 016 normalized to 015a: 1873 vs 58054 |
| 22:10:00 | raptor | that's 27x the number of lua_pcall s in 016 |
| 22:12:00 | raptor | that makes me think i went on a wild goose chase to dynamic_cast... |
| 22:15:00 | Watusimoto | I killed a couple of dynamic_casts... not likely to have much impact though |
| 22:16:00 | sam686 | i found a windows CPU profiler with a weard name, http://www.codersnotes.com/sleepy |
| 22:16:00 | raptor | make me think that EventManager is the overhead... |
| 22:19:00 | Watusimoto | I don't see any evidence for that |
| 22:22:00 | sam686 | maybe your /maxfps 1000 on 016 is the overhead? |
| 22:22:00 | sam686 | or debug compile mode might also be some overhead.. |
| 22:22:00 | raptor | i compiled both with debug options |
| 22:22:00 | raptor | maxfps was defaulted to 100 |
| 22:22:00 | raptor | on both |
| 22:22:00 | raptor | used same level, same number of bots |
| 22:23:00 | sam686 | maybe the conversion from typemask to typenumber might be slow when looking for more then one type... |
| 22:31:00 | raptor | maybe i need to do an hg bisect... |
| 22:36:00 | raptor | yes, sorry, not EventManager... i mean something used in it |
| 22:39:00 | sam686 | the changes on 016 is robot will idle through event manager, it looks like |
| 22:40:00 | sam686 | Robot::idle have "Robot::getEventManager().fireEvent(EventManager::TickEvent, deltaT);" |
| 22:41:00 | Watusimoto | correct |
| 22:42:00 | Watusimoto | killed a bunch more dynamic_casts |
| 22:42:00 | Watusimoto | none likely to be our problem |
| 22:44:00 | sam686 | i think i found the problem, when testing timer bot, with 2 bots, it is calling onTick twice as much for each bots |
| 22:44:00 | sam686 | for 10 bots, it is calling ontick 10 times as much for each bots, a total of 100 onTick |
| 22:45:00 | sam686 | that makes timer bot print twice as fast |
| 22:45:00 | sam686 | or 10 times faster.. |
| 22:46:00 | sam686 | doesn't this " Robot::getEventManager().fireEvent(EventManager::TickEvent, deltaT);" call onTick on ALL ROBOTS? |
| 22:47:00 | raptor | i don't know.. |
| 22:48:00 | raptor | i have to go - be back in 2 hours or so... |
| 22:49:00 | sam686 | "Robot::getEventManager().fireEvent(EventManager::TickEvent, deltaT);" appears to call On-tick on ALL ROBOTs |
| 22:51:00 | raptor | wow, so we have onTick^2 always called? |
| 22:51:00 | sam686 | yes, that makes adding 10 bots 10 times slower... |
| 22:52:00 | sam686 | or adding 20 bots 400 times slower, i meant |
| 22:52:00 | raptor | so my 60 bots is pretty gnarly |
| 22:53:00 | sam686 | have to go raptor? |
| 22:54:00 | raptor | yes, i'll be back later |
| 22:54:00 | sam686 | later.. |
| 22:54:00 | | raptor Quit (Remote host closed the connection) |
| 22:59:00 | | LordDVG Quit (Remote host closed the connection) |
| 23:04:00 | sam686 | Watusimoto ? your FireEvent TickEvent is causing problems with multiple robots, where robot onTick being called more then once per game tick... |
| 23:05:00 | Watusimoto | it is?!? |
| 23:06:00 | sam686 | running Robot::getEventManager().fireEvent(EventManager::TickEvent, deltaT); once causes all robots to run onTick |
| 23:07:00 | sam686 | with multiple robots, each runs that same fire event onTick, causing robots to run onTick multiple times |
| 23:11:00 | Watusimoto | mmmm.... so with 10 robots, we're running ontick 100 times |
| 23:11:00 | Watusimoto | I think you found the problem! |
| 23:11:00 | sam686 | yes, that slows down the game by a whole lot... |
| 23:12:00 | sam686 | possible solution is moving the fireEvent(TickEvent...) out of Robot::Idle and into ServerGame::Idle, but what about "Clear out current move."? |
| 23:27:00 | Watusimoto | I think your proposed move makes sense, not sure what you mean by clear out current move |
| 23:27:00 | Watusimoto | oh, a comment in robot.cpp |
| 23:28:00 | Watusimoto | fire tick event after all robots have idled? that doesn't seem right |
| 23:29:00 | Watusimoto | create a robot::clearMove method, run that on all bots before firing onTick, then idle bots? |
| 23:31:00 | Watusimoto | where is robot's idle called? |
| 23:38:00 | sam686 | robot::idle is called from ServerGame::idle, like all other objects call idle |
| 23:39:00 | Watusimoto | just figured that out |
| 23:39:00 | sam686 | or maybe, simply clearing out robot's move after parent::idle |
| 23:39:00 | sam686 | will work |
| 23:39:00 | Watusimoto | I'm not sure exactly when the bot's onTick gets called in relation to when the event is fired |
| 23:40:00 | Watusimoto | but the sequence needs to be clearMove, execute onTick |
| 23:40:00 | sam686 | when the event if fired, it immediately calls the LUA functions (fire idle event, it imediately caled onTick) |
| 23:41:00 | sam686 | sequence is clear move, execute, then do parent::idle (parent = Ship) |
| 23:41:00 | sam686 | simply moving he clear move to the end may work, i guess |
| 23:41:00 | Watusimoto | actually, I think you can safely do the the tick event after bots have idled |
| 23:42:00 | Watusimoto | so move it to the serverGame::idle after other objects have idled |
| 23:42:00 | sam686 | yes |
| 23:42:00 | sam686 | are you fixing that? |
| 23:42:00 | Watusimoto | you can; I'm so sleepy I might do something stupidcurrently in bot::idle, only thing that happens |
| 23:42:00 | sam686 | ok i can fix.. |
| 23:43:00 | Watusimoto | ...that happens is the parent::idle |
| 23:43:00 | Watusimoto | and while I haven't checked, I can't imagine theres anything in there that would have bearing... so the bots arlready do onTick after they've idled |
| 23:44:00 | sam686 | i think the only thing robot onTick do it set up proper move after some calclating of currect state... |
| 23:44:00 | Watusimoto | actually... crap... this is compex |
| 23:45:00 | Watusimoto | the parent::idle does some processing of the move |
| 23:45:00 | sam686 | though, robot can chat, but Eliza doesn't use onTick to chat... |
| 23:45:00 | Watusimoto | no; it doesn';t care about tick events |
| 23:45:00 | Watusimoto | it subscribes to chat message events |
| 23:45:00 | sam686 | yes |
| 23:46:00 | sam686 | Ship::idle does move processing like module and firing, and aiming and moving (Robot calls Ship::idle) |
| 23:47:00 | Watusimoto | yes |
| 23:47:00 | Watusimoto | that's probably important |
| 23:47:00 | Watusimoto | so maybe my first suggestion? in servergame clear all bot moves, fire onTick, run bot::idle |
| 23:59:00 | Watusimoto | ok, got to go to bed |
