Timestamps are in GMT/BST.
| 00:42:50 | | Flynnn Quit (Quit: This computer has gone to sleep) |
| 00:44:55 | | Flynnn has joined |
| 00:45:17 | | raptor Quit () |
| 00:57:25 | | Flynnn Quit (Quit: This computer has gone to sleep) |
| 00:57:58 | | Flynnn has joined |
| 02:04:00 | | Invisible has joined |
| 03:13:45 | | Invisible Quit (Ping timeout: 260 seconds) |
| 03:17:58 | | Flynnn Quit (Quit: This computer has gone to sleep) |
| 03:18:46 | | Flynnn has joined |
| 04:14:33 | | Watusimoto has joined |
| 04:17:32 | | Flynnn Quit (Quit: This computer has gone to sleep) |
| 04:19:31 | | Platskies has joined |
| 04:21:06 | | Platskies Quit (Client Quit) |
| 04:25:42 | | Akien has joined |
| 04:45:56 | | Watusimoto Quit (Ping timeout: 260 seconds) |
| 05:16:52 | | Invisible has joined |
| 06:48:13 | | Watusimoto has joined |
| 07:01:49 | | Invisible Quit (Quit: Invisible) |
| 09:08:05 | | raptor has joined |
| 09:08:05 | | ChanServ sets mode +o |
| 09:08:17 | raptor | mornin' |
| 09:17:53 | Nothing_Much | Mornin' raptor |
| 09:25:31 | raptor | hi |
| 09:57:16 | raptor | Watusimoto: I could also expand idea in GameSettings to have a getSetting<F32>(indexType) - then we'd just have that one method with the setting key |
| 10:03:11 | raptor | that's probably a good idea anyways to reduce the length of the settings call |
| 10:32:20 | | Akien Quit (Remote host closed the connection) |
| 10:41:58 | | Nothing_Much Quit (Read error: Connection reset by peer) |
| 10:49:55 | | BFLogBot Commit: 47881984b9 | Author: buckyballreaction | Message: Create a getSetting() method to reduce verbosity |
| 10:49:56 | | BFLogBot Commit: 60d3edf4a4 | Author: buckyballreaction | Message: User our new getSetting/setSetting methods everywhere that has been migrated to the new system |
| 11:47:04 | | Nothing_Much has joined |
| 11:56:25 | | Nothing_Much Quit (Quit: Konversation terminated!) |
| 11:58:05 | | Nothing_Much has joined |
| 11:59:11 | | raptor Quit () |
| 12:49:07 | | Watusimoto Quit (Ping timeout: 255 seconds) |
| 12:51:12 | | Watusimoto has joined |
| 13:08:41 | | fordcars_us has joined |
| 13:09:05 | fordcars_us | Guess where I am? |
| 13:10:11 | fordcars_us | Maine, Us hehe |
| 13:10:31 | fordcars_us | Coming back home tomorrow |
| 13:14:54 | | fordcars_us Quit (Ping timeout: 246 seconds) |
| 14:04:14 | | Invisible has joined |
| 14:17:26 | | Watusimoto Quit (Ping timeout: 250 seconds) |
| 14:18:05 | | Invisible Quit (Ping timeout: 260 seconds) |
| 14:48:42 | | Watusimoto has joined |
| 16:40:57 | | raptor has joined |
| 16:40:57 | | ChanServ sets mode +o |
| 16:42:38 | raptor | hello again! |
| 16:53:45 | Watusimoto | hi |
| 16:54:07 | raptor | hi |
| 16:54:41 | raptor | I've run into another issue with the settings: if something isn't an INI option, where should it be stored? |
| 16:54:48 | raptor | for example: oldDisplayMode |
| 16:55:13 | raptor | it's derived from the displayMode (which is in the INI), but only used internally to the game |
| 17:01:16 | raptor | would we want to store these derived/internal settings with the ones from the INI on the same object (mSettings)? |
| 17:01:38 | raptor | or maybe just on the GameSettings object... |
| 17:01:42 | Watusimoto | well... things can be complicated |
| 17:01:55 | raptor | if on mSettings, would the be part of the SETTINGS_TABLE ? |
| 17:02:03 | Watusimoto | we also need to store two states of many settings -- that which should be written to the INI, and that which we are using in game |
| 17:02:23 | Watusimoto | they are not always the same, if, for example, someone overrides a setting on the cmd line |
| 17:02:38 | raptor | hmmm |
| 17:02:40 | raptor | interesting |
| 17:02:45 | raptor | i hadn't considered that |
| 17:03:06 | Watusimoto | and you don;t want to write the override to the INI file, even though that is the active value for the game |
| 17:03:06 | raptor | and I tied together the INI and Settings objects last night with that new setSetting() template |
| 17:03:18 | Watusimoto | that looks ok |
| 17:03:32 | Watusimoto | just so long as we don;t use it when dealing with cmd line overrides |
| 17:03:57 | raptor | but don't we write out all Settings to the INI at the game close anyways? |
| 17:04:19 | Watusimoto | yes -- but if someone specifies an override on the cmd line, we don't want to save that setting to the INI |
| 17:04:44 | Watusimoto | so we have to keep track of the "working value" and the "saving value" |
| 17:04:55 | Watusimoto | usually they'll be the same, but not always |
| 17:04:59 | raptor | ok, that makes sense |
| 17:05:14 | raptor | but maybe I bulldozed through that exception with my latest commit... |
| 17:05:59 | raptor | did you intend the mSettings object to be the working copy (even though it is found on an object named 'IniSettings') ? |
| 17:06:08 | Watusimoto | yes, I think so |
| 17:06:12 | raptor | ok |
| 17:06:30 | raptor | so what if... |
| 17:06:43 | Watusimoto | you can be sure by looking at where the cmd line settings are merged with the INI settings |
| 17:07:03 | raptor | what if i start the game with a command line option, like -displaymode, but then change the mode in-game which calls a working and saving copy update? |
| 17:07:07 | Watusimoto | I think the IniSettings are what we want to be written |
| 17:07:16 | Watusimoto | and the mSettings are what we want to use |
| 17:07:42 | Watusimoto | if you change something in-game like that, I think we want to save your change to the INI, regardless of what you did on the cmdline |
| 17:07:45 | raptor | I've been modifying code under the impression that mSettings is the working copy from which everything is set/get |
| 17:08:49 | raptor | the 'iniFile' object is what is actually written-to-disk and so that is the saving copy |
| 17:08:59 | Watusimoto | so one simplification is that while we may start off with several settings that differ (ini vs. cmd line override), there will never be more than we start with... that is, if anything changes in-game, we want to save that to the ini |
| 17:09:07 | Watusimoto | yes |
| 17:09:13 | raptor | ok |
| 17:09:49 | raptor | maybe I should modify my setSetting() method to take a boolean that turns on/off the ini write |
| 17:09:58 | raptor | sorry, ini object write |
| 17:10:02 | raptor | (not write-to-disk) |
| 17:10:26 | Watusimoto | you could -- but that would only be used when merging cmd line and ini... thereafter write would always be true |
| 17:10:38 | Watusimoto | so it might be clearer to treat that as a special case |
| 17:11:00 | raptor | ok, then maybe for cmd line stuff i just call the internal mSettings object directly |
| 17:11:06 | Watusimoto | yes |
| 17:11:09 | Watusimoto | I think that would be fine |
| 17:11:17 | raptor | call setVal<DataType>() on it and leave it at that |
| 17:12:44 | Watusimoto | I think there must be a clean architectural solution to this issue, but I haven't found it |
| 17:13:05 | Watusimoto | I've started 3 or 4 times to propose a solution (in the last couple of minutes), but keep deleting it because it isn't very clear |
| 17:13:57 | Watusimoto | I learned somethign about bikes today, btw... there was a time when bikes had two speeds -- you used one while pedaling forwards, and the other by pedaling backwards. |
| 17:15:31 | raptor | haha, oh yeah |
| 17:15:56 | Watusimoto | crazy complex chain paths on those |
| 17:16:19 | Watusimoto | not to distract from the issue at hand, just thought I'd mention it |
| 17:17:24 | Watusimoto | here's a modern version |
| 17:18:30 | raptor | found this: http://www.frankb.us/gears/ |
| 17:19:59 | raptor | pretty nifty, actually |
| 17:20:11 | raptor | sometime I think I'd like to do mechanical engineering... |
| 17:20:54 | raptor | half the magic is in the rear axle |
| 17:34:45 | raptor | huh - ok, so a 'directive' isn't a setting option |
| 17:46:01 | | Nothing_Much Quit (Quit: Konversation terminated!) |
| 17:47:48 | | Nothing_Much has joined |
| 17:58:48 | Watusimoto | I'm not sure what you meant by that last remark |
| 18:01:24 | raptor | there are two categories of command line options, directives and params |
| 18:02:18 | Watusimoto | I suppose there are, yes... it's been years since i looked at that stuff! |
| 18:02:23 | raptor | which sent me down the wrong path for a little while... but a directive is something like -help or -rules that will not actually start the game |
| 18:02:37 | raptor | a param is something that actually sets a setting |
| 18:02:39 | Watusimoto | yes, kind of non-game functionality |
| 18:02:41 | Watusimoto | yes |
| 18:02:45 | raptor | yes |
| 18:02:54 | raptor | i'm adding a little doc as I figure this out... |
| 18:08:22 | Watusimoto | excellent |
| 18:08:32 | Watusimoto | feel free to rename things or whatever to make stuff clearer |
| 18:21:04 | raptor | taking off... night! |
| 18:21:09 | raptor | i am doing so |
| 18:27:18 | | raptor Quit () |
| 18:27:23 | | BFLogBot Commit: 2ff603cc95 | Author: buckyballreaction | Message: Minor clean-up |
| 18:27:24 | | BFLogBot Commit: 7d1f4d6a75 | Author: buckyballreaction | Message: Clarification regarding parsing and usage of command-line parameters |
| 19:03:01 | | Watusimoto Quit (Ping timeout: 272 seconds) |
| 21:55:47 | | raptor has joined |
| 21:55:47 | | ChanServ sets mode +o |
| 23:49:26 | raptor | my new favorite method I just found: GameSettings::saveMasterAddressListInIniUnlessItCameFromCmdLine() |
| 23:55:04 | | BFLogBot Commit: faaf0d616f | Author: buckyballreaction | Message: Migrate another set of settings to the new system |
| 23:56:49 | | raptor Quit () |