Timestamps are in GMT/BST.
| 01:30:35 | fordcars | Night! |
| 01:31:35 | fordcars | I'll be away for around 2 weeks, going up north, so, no internet (probably). So, see you in 2 weeks! |
| 01:31:38 | | fordcars Quit (Quit: Page closed) |
| 02:04:14 | | destroyerimo_clo has joined |
| 02:04:53 | | destroyerimo Quit (Ping timeout: 240 seconds) |
| 02:09:00 | | Watusimoto has joined |
| 02:18:43 | | Watusimoto Quit (Remote host closed the connection) |
| 05:06:18 | | Watusimoto has joined |
| 07:04:18 | | Flynnn Quit (Quit: This computer has gone to sleep) |
| 07:29:30 | | sam686 has joined |
| 07:29:30 | | ChanServ sets mode +v |
| 07:37:48 | | Flynnn has joined |
| 08:02:06 | | Flynnn Quit (Quit: This computer has gone to sleep) |
| 09:58:35 | | raptor has joined |
| 09:58:35 | | ChanServ sets mode +o |
| 09:58:44 | raptor | good morning! |
| 10:03:02 | raptor | Watusimoto: if you're around - I'd like to solve the GameSettings issues once and for all |
| 10:03:39 | raptor | right now we're in this quasi state where I finally got the game to load, but no settings are actually loaded |
| 10:03:56 | raptor | I was discussing this with kaen last night, and I think we should do one of two things: |
| 10:05:04 | raptor | 1. make a true singleton out of GameSettings, doing it like this: https://stackoverflow.com/questions/1008019/c-singleton-design-pattern/1008289#1008289 |
| 10:05:42 | raptor | then we'd just do GameSettings::get() or something like that whenever we want it. But we'd have to provide an override for tests that set up their own GameSettings object |
| 10:06:13 | raptor | 2. Don't use a singleton and just bass the GameSettings* to the UI class, then just use mSettings from the editor |
| 10:06:41 | raptor | after reading a lot about singletons and global objects, I'm starting to favor #2 over a global like we have now |
| 10:06:49 | raptor | thoughts? |
| 10:24:23 | | Watusimoto Quit (Ping timeout: 240 seconds) |
| 10:28:22 | sam686 | in project 'master' fatal error LNK1104: cannot open file 'master_lib.dir\$(OutDir)\database.obj' |
| 10:28:47 | sam686 | but if I rename Debug directory into $(OutDir) it then works |
| 10:29:38 | raptor | hi sam686, everything is broken at the moment - watusimoto has started changing the GameSettings architecture, and I'm not sure what exactly we should do about it |
| 10:29:39 | sam686 | interesting that this isn't the problem on 'bitfghter' which also use $(OutDir) |
| 10:29:50 | raptor | you make have to do a 'make clean |
| 10:31:14 | raptor | *maybe |
| 10:32:54 | sam686 | trying a cmake again, then full clean and rebuild |
| 10:35:30 | sam686 | now it seems to work fine, except the 'test' errors. http://sam6.25u.com/upload/text1407/140713_09-34-15.txt |
| 10:35:41 | raptor | yes |
| 10:35:50 | raptor | those are broken because of the new gSettings object |
| 10:35:56 | raptor | much of the game is broken, in fact |
| 10:36:14 | raptor | bitfighter doesn't load the settings from the INI anymore and will overwrite the old ones when exiting |
| 10:36:39 | sam686 | oh my the way, notice the 'Win64" part? After finding 64 bit libraries and DLLs it runs ok |
| 10:36:39 | raptor | ri want to talk over a solution with watusimoto, then fix it |
| 10:36:46 | raptor | oh really? |
| 10:36:52 | raptor | that's great! |
| 10:38:20 | sam686 | now i get "Unable to connect ot master" but it worked on earliear revisions as 64 bit windows build |
| 10:40:07 | sam686 | theres an obvious problem of something not reading my bitfighter.ini |
| 10:40:21 | raptor | yep, that's one of them |
| 10:40:44 | sam686 | because of that, it can't find any levels to host/edit |
| 10:41:39 | raptor | yes, same problem here |
| 10:43:36 | raptor | i don't want to change much right now until I can talk to watusimoto - he's playing with the code a lot.. |
| 10:43:54 | | BFLogBot Commit: bb59f1eabf | Author: sam8641 | Message: Fixed some compile errors |
| 10:44:17 | sam686 | There is a small cmake change (added one line) |
| 10:44:26 | raptor | i see it, thanks! |
| 10:46:46 | sam686 | AT some revision earliear, where ini loading and saving did worked (mostly), the volumes keeps going to zero (mute) |
| 10:47:06 | raptor | yes, there is also a config issue that many values fail to actually work |
| 10:49:59 | sam686 | Im starting to see more global variable, like gSettings |
| 10:50:27 | raptor | yes, i'm not sure that's a good idea... |
| 10:51:34 | sam686 | I was thinking of combining 2 separate master connection into 1 when hosting, as of now in 019, it creates a second connection to master when hosting (or testing from editor) |
| 11:58:07 | raptor | I have to go, but, I have gSettings actually working now and loading some settings (others still don't work) |
| 11:58:18 | | destroyerimo_clo Quit (Ping timeout: 240 seconds) |
| 11:58:20 | raptor | but I don't want to check in my changes until i talk to watusimoto |
| 11:58:27 | raptor | so later! |
| 11:58:32 | | raptor Quit () |
| 11:58:40 | | Watusimoto has joined |
| 13:34:22 | | LordDVG has joined |
| 13:48:58 | | Watusimoto Quit (Ping timeout: 240 seconds) |
| 13:56:20 | | YoshiSmb has joined |
| 13:56:35 | YoshiSmb | hi guys |
| 14:19:49 | | YoshiSmb Quit (Ping timeout: 246 seconds) |
| 14:33:48 | | YoshiSmb has joined |
| 14:50:58 | | YoshiSmb Quit (Ping timeout: 246 seconds) |
| 14:53:10 | | Flynnn has joined |
| 15:47:07 | | Watusimoto has joined |
| 15:48:44 | | Flynnn Quit (Quit: This computer has gone to sleep) |
| 16:43:23 | | Flynnn has joined |
| 16:56:45 | | raptor has joined |
| 16:56:46 | | ChanServ sets mode +o |
| 16:56:50 | raptor | good day! |
| 17:08:03 | raptor | Watusimoto: may I refer you to my question this morning: http://bitfighter.org/irclogs/?date=2014-07-13#l17 |
| 17:08:22 | Watusimoto | I'll reply after the match is over... 1/2 hr! |
| 17:08:28 | raptor | haha ok |
| 17:38:27 | | Flynnn Quit (Quit: This computer has gone to sleep) |
| 17:47:48 | | Flynnn has joined |
| 17:48:08 | | Flynnn Quit (Client Quit) |
| 17:57:45 | raptor | ha |
| 17:57:51 | raptor | Germany pulled it off at the end |
| 18:04:45 | Watusimoto | hi |
| 18:04:47 | Watusimoto | yes |
| 18:04:59 | Watusimoto | not the most awesome game, but the last 15 mins or so was exciting |
| 18:05:15 | Watusimoto | I was hoping germany would win, and I thought they would, so I am happy with the outcome |
| 18:05:23 | Watusimoto | so |
| 18:05:44 | Watusimoto | your question about the singleton vs. global objects? |
| 18:05:54 | Watusimoto | is that what you wanted to discuss? |
| 18:06:09 | raptor | not vs |
| 18:06:19 | raptor | since a singleton is global in the instance |
| 18:06:31 | Watusimoto | yes |
| 18:06:34 | raptor | did you read my question from this morning? |
| 18:06:48 | Watusimoto | with the 2 options you presented? |
| 18:06:49 | | LordDVG Quit (Remote host closed the connection) |
| 18:06:54 | raptor | yes... |
| 18:06:56 | Watusimoto | if so, yes |
| 18:07:09 | raptor | right now our code base is in a weird state |
| 18:07:16 | raptor | and I want to make it go one way or the other |
| 18:07:23 | Watusimoto | so the issue I see with putting settings on the UI object is that the server can't access it there |
| 18:07:44 | raptor | ah ok, and that's why it was chosen to put on Game before |
| 18:07:50 | Watusimoto | and we don't want to have two different ways to get it, depending on whether we;re server or client |
| 18:07:56 | Watusimoto | that would obviuosly suck |
| 18:08:24 | Watusimoto | so before there was always a game; now there isn't... well there is, but not all objects have a good connection to it anymore |
| 18:08:25 | raptor | yeah |
| 18:08:46 | Watusimoto | hence the global |
| 18:08:52 | raptor | I wasn't thinking of putting it exclusively on UI, but just passing the pointer around to wherever we needed it |
| 18:08:56 | Watusimoto | but I take it you are experiencing initialization issues |
| 18:09:08 | raptor | yes, so initialization issues are not fun |
| 18:09:12 | Watusimoto | no |
| 18:09:26 | raptor | let me get you a quick diff... |
| 18:09:36 | Watusimoto | so we need a way to ensure that we don't have them anymore |
| 18:10:13 | raptor | yes, and I did that... one moment with the diff |
| 18:10:45 | raptor | like this: http://pastie.org/9386915 |
| 18:11:04 | raptor | this solves initialization issues, with the following 2 downsides: |
| 18:11:13 | sam686 | extern int a; int b = a; int a = b; something like that is the problem, if it were string instead of int it may crash before running main() |
| 18:11:18 | raptor | 1. We have to specify GameSettings::get() everywhere |
| 18:11:39 | raptor | 2. Tests become difficult since there is only ever *one* object |
| 18:14:25 | raptor | #1 is a downside because of verbosity... |
| 18:14:51 | sam686 | you could get rid of gSettings, and put GameSettingsPtr mSettings; everywhere gamesettings needed, all pointing to the same single gamesettings |
| 18:16:55 | Watusimoto | the testing is manageable, I think |
| 18:17:10 | Watusimoto | you can reset the global object to some state before running your tests |
| 18:17:23 | Watusimoto | but I do not like the ::get() bit |
| 18:17:31 | Watusimoto | mainly for aesthetic reasons |
| 18:17:36 | Watusimoto | and verbosity |
| 18:18:15 | Watusimoto | we could, I suppose, revert to passing a settings object around everywhere |
| 18:18:29 | Watusimoto | though i don't really like that |
| 18:18:57 | Watusimoto | but it is probably the best solution from a technical standpoint |
| 18:20:45 | raptor | #typedef GameSettings::get() gGameSettings |
| 18:21:24 | raptor | i wonder if we shouldn't be using typedefs more specifically for the aesthetic purposes |
| 18:21:59 | raptor | If we just pass settings* everywhere, then we don't have to change much infrastructure |
| 18:22:14 | raptor | I can think of two major places that need it: UI and BfObject |
| 18:22:17 | raptor | but... |
| 18:22:36 | raptor | another idea: We could have a Bitfighter object |
| 18:22:54 | raptor | which sort of becomes the new Game, but really is the whole-program-level wrapper |
| 18:23:05 | raptor | and it would contain a GameSettings object |
| 18:23:31 | sam686 | All i mostly seeing in a past 100 commits is code changes that barely add 1 feature and adds more then 10 bugs/crashing that doesn't exist back on 019c |
| 18:23:55 | raptor | haha, such is the fate of refactoring |
| 18:25:14 | sam686 | 90% of users that play bitfighter don't look at C++ code so those that don't look don't care about such code changes like refactoring |
| 18:26:28 | Watusimoto | >>> #typedef GameSettings::get() gGameSettings<<< an interesting idea! |
| 18:27:45 | raptor | although, since making the constructor private, i'm not sure how to integrate that code with tests |
| 18:28:20 | raptor | also it feels really weird to instantiate the class within itself |
| 18:28:24 | Watusimoto | a Bitfighter object is also interesting |
| 18:28:27 | raptor | that's gotta be wrong on some level |
| 18:30:10 | Watusimoto | the other thing we could do (in either case, I suppose) is create a method for setting the settings object to a new settings object for testing. that method could be private, and we could declare the tests to be friend classes |
| 18:30:31 | Watusimoto | how would the Bitfighter object get instantiated? |
| 18:30:42 | Watusimoto | from main? |
| 18:30:47 | raptor | thinking about that Bitfighter object, and trying to remember something that kaen mentioned - it seems as though the Game object was partly originally supposed to be that whole-program-level wrapping object |
| 18:30:49 | raptor | yes from main() |
| 18:31:06 | Watusimoto | we could initialize gSettings from main() |
| 18:31:14 | raptor | that doesn't work |
| 18:31:31 | raptor | well, it does, most of the time |
| 18:31:40 | raptor | but can still have the ordering problems |
| 18:31:56 | raptor | right now we do new GameSettings from main() |
| 18:32:01 | raptor | then pass it around |
| 18:32:13 | sam686 | main() runs after all the global/static initalizing |
| 18:32:44 | Watusimoto | do we have statics that depend on gSettings? |
| 18:32:56 | raptor | ah yes, that's why it doesn't work sometimes from main() - initialization has already completed |
| 18:33:06 | raptor | yes |
| 18:33:08 | raptor | or |
| 18:33:23 | raptor | more like, we have statics that are part of objects that use gSettings |
| 18:33:33 | Watusimoto | then the Bitfighter object won't work either, right? |
| 18:33:40 | raptor | it's not to be a static |
| 18:33:57 | raptor | or a global |
| 18:34:18 | Watusimoto | oh, so we'd pass that around then |
| 18:34:21 | raptor | yes |
| 18:34:24 | Watusimoto | ah, ok |
| 18:34:44 | raptor | but we could fill it out with what ever other objects, like GameSettings, we needed |
| 18:34:46 | Watusimoto | well, I'm not sure that would be better than just passing around the settings |
| 18:35:12 | raptor | the 'better' part is having one object vs. a potential more-than-one as there may be other objects |
| 18:35:24 | Watusimoto | so it seems we have two options: 1) Settings::get() and 2) passing settings around everywhere |
| 18:35:38 | raptor | yes, those were my two from this morning |
| 18:35:40 | Watusimoto | yes, but at least currently, settings is it |
| 18:35:53 | raptor | we can round off #1 with a typedef and some other access for tests |
| 18:36:04 | sam686 | I can try GameSettings &gSettings = NULL; and see where it crash first |
| 18:36:06 | Watusimoto | ok, yes |
| 18:36:11 | raptor | #2 is already implemented |
| 18:36:24 | raptor | mostly |
| 18:36:32 | Watusimoto | yes |
| 18:36:37 | Watusimoto | we just need to undo my undos |
| 18:36:46 | raptor | haha |
| 18:37:00 | Watusimoto | and figure out how to get settings into the BfObject hiearchy |
| 18:37:02 | raptor | I'm willing to fully convert the code base to #1 or #2 |
| 18:37:11 | raptor | I just want to settle on one or the other |
| 18:37:25 | Watusimoto | sam686, what are your thoughts? |
| 18:37:38 | raptor | i think sam686 just wants it to not be broke |
| 18:37:51 | Watusimoto | we all want that! |
| 18:37:58 | raptor | yes! |
| 18:38:06 | Watusimoto | ok, I'll give my vote |
| 18:38:14 | Watusimoto | I would vote for #2 |
| 18:38:28 | raptor | I find a lot of online vitriol against having singletons |
| 18:38:47 | Watusimoto | though I think it is kind of messy |
| 18:38:50 | sam686 | globals initalizing that depends on another to be already initalized in another .cpp file just makes things randomly broken depending on linker order |
| 18:39:06 | sam686 | and we can't always control linker order mostly on windows |
| 18:39:12 | raptor | oh the horror of initialization + linker |
| 18:39:15 | Watusimoto | yes, so that idea won't work |
| 18:39:47 | Watusimoto | I actually did think about initialization order before starting down the gSettings road |
| 18:40:01 | Watusimoto | and I didn't think it would be a problem |
| 18:40:07 | raptor | with #2, our tests will work again... |
| 18:40:11 | Watusimoto | yes |
| 18:40:17 | raptor | ok, i'll do #2 |
| 18:40:19 | sam686 | the problem was hallening on colors.h colors.cpp, until I deside to ditch colors.cpp to fix black color initalizing problem |
| 18:40:29 | sam686 | happen (not hallening) |
| 18:40:40 | Watusimoto | ok |
| 18:41:19 | raptor | i have to go, but i'll be back in about an hour or so and get to work |
| 18:41:24 | Watusimoto | ok |
| 18:41:29 | Watusimoto | I'll probaby be asleep |
| 18:41:34 | Watusimoto | but you never know! |
| 18:41:45 | raptor | i think that putting the *settings object on UI will remove a *lot* of method arguments |
| 18:42:00 | raptor | so we may find that this will be cleaner in the end |
| 18:42:28 | raptor | ok, back alter |
| 18:42:29 | raptor | later |
| 18:42:39 | raptor | night! (maybe( |
| 18:42:41 | raptor | )) |
| 18:43:04 | | raptor Quit () |
| 18:45:06 | sam686 | it looks like nothing uses gSettings before main() runs |
| 18:46:41 | sam686 | im probably falling asleep, later |
| 18:46:44 | | sam686 has left #bitfighter |
| 19:04:58 | Watusimoto | some good website design ideas here: |
| 19:04:58 | Watusimoto | http://eu.wargaming.net/ |
| 20:17:16 | | raptor has joined |
| 20:17:16 | | ChanServ sets mode +o |
| 20:17:23 | raptor | hello again |
| 20:18:01 | raptor | WORLD OF WARPLANES |
| 20:19:51 | raptor | on to the settings refactor! |
| 20:20:42 | raptor | Watusimoto: are you planning on committing anything tonight? |
| 21:26:07 | | Flynnn has joined |
| 21:28:10 | | BFLogBot Commit: 78ceb04ee3 | Author: watusimoto |
| 21:28:12 | | BFLogBot Commit: 2495fd6496 | Author: watusimoto |
| 21:28:13 | | BFLogBot Commit: 3b72eea5b7 | Author: watusimoto |
| 21:28:15 | | BFLogBot Commit: 7b16e2c36a | Author: watusimoto |
| 21:28:16 | | BFLogBot Commit: 1efa8b37ea | Author: watusimoto |
| 21:28:18 | | BFLogBot Commit: 019ca7dbdf | Author: watusimoto |
| 21:28:24 | raptor | OH NO |
| 21:32:44 | | Watusimoto Quit (Ping timeout: 264 seconds) |
| 22:38:41 | raptor | kaen: do you remember why we chose to move the global lua functions outside of LuaScriptRunner and into LuaGlobals? |
| 22:38:51 | raptor | this was the relevant commit: https://code.google.com/p/bitfighter/source/detail?r=e4feff844b46 |
| 22:59:50 | raptor | actually, i thin i foudn it in the logs |
| 23:47:56 | | raptor Quit () |