Log for on 4th May 2014:
Times are UTC Toggle Colours
03:04:00  *** Supercheese has joined
03:04:00  *** ChanServ sets mode: +v Supercheese
06:54:42  *** Alberth has joined
06:54:42  *** ChanServ sets mode: +v Alberth
07:11:16  *** Supercheese has quit IRC
08:06:02  <fonsinchen> Should distribution mode be a newgrf property of cargo types?
08:06:14  <fonsinchen> If so, what should the distribution mode settings do?
08:06:41  <fonsinchen> Override the newgrf property or provide a default for the case where no newgrf property is set?
08:06:49  <planetmaker> if you make that a newgrf property then the settings become pointless
08:07:30  <fonsinchen> Yes, the third option is to require the property. However, that would be fairly brutal as existing cargoes don't have it.
08:07:38  <planetmaker> I'd not advise to do so. If so, provide a property for cargoes which puts them in the three categories we have the setting for
08:08:59  <fonsinchen> I don't understand? "provide a property for cargoes which puts them in the three categories we have the setting for" <= that's the basic premise. If that property existed, what should happen to the settings?
08:09:12  <planetmaker> sorry, four categories as in settings: pass, mail, valu, other
08:09:30  <fonsinchen> That is already the case. We have cargo classes
08:11:41  <fonsinchen> I think allowing newgrfs to define their distribution mode, possibly referring to their own newgrf settings, fits the general direction we're going with settings vs scripts/newgrfs better.
08:11:43  <planetmaker> well. Thus NewGRFs can already control it
08:13:15  <planetmaker> I don't like the idea that a NewGRF defines whether I play with cargodist or not.
08:14:39  <fonsinchen> We could reduce the setting to "override newgrf distribution mode": "no/on/off"
08:14:57  <fonsinchen> "on" has to be defined somehow.
08:15:14  <planetmaker> rather just add a mode to the existing: "use NewGRF suggestion"
08:16:39  <planetmaker> but why does it need to be a NewGRF / cargo property?
08:17:47  <planetmaker> I'm still a bit unclear as to what problem it fixes :)
08:18:02  <planetmaker> and whether this wouldn't add more confusion
08:18:41  <fonsinchen> You could have more fine grained control. That pax/mail/valu/other distinction is quite a hack.
08:19:00  <fonsinchen> So the newgrf could switch cargodist on for goods, but not for coal or similar.
08:19:12  <planetmaker> I have to agree on that point, yes
08:20:02  <planetmaker> so effectively it would make sense to have a choice of off/symmetric/asymmetric/NewGRF
08:21:07  <fonsinchen> I'll open a topic in newgrf technical discussion and ask the giraffers what they think about it.
08:21:32  <planetmaker> andy will be +1 :P
08:21:39  <planetmaker> or call it BAD FEATURE. dunno ;)
08:21:47  <Alberth> or both :p
08:21:54  <planetmaker> yeah ;)
08:25:31  <Alberth> extending towards newgrf seems like a good idea; in the extreme case, we might want to have a window to set the mode for each cargo type indivually
08:25:57  <planetmaker> yes. I thought of that way
08:26:19  <planetmaker> that requires the new game dialogue to be re-designed: set NewGRFs before cargo distribution settings :)
08:26:29  <planetmaker> as it needs to know the active cargoes for the game
08:30:21  <fonsinchen> Who is going to go through 32 settings just to define the distribution types when starting a new game?
08:30:36  <Alberth> you'd be surprised :p
08:30:49  <Alberth> but "random" sounds like fun too
08:30:52  <planetmaker> fonsinchen, enough people
08:31:05  <planetmaker> hm :)
08:31:22  <Alberth> if you play with FIRS all the time, it pays to tune your settings to your liking
08:32:06  <planetmaker> yup
08:32:31  <planetmaker> every server owner will want to do that. Thus all people who play on servers could possibly profit from it
08:33:36  <fonsinchen> FIRS could just provide 32 NewGRF settings if andy feels like it.
08:37:41  <Alberth> hmm, interesting idea, can we have a newgrf similar to basecosts?
08:39:45  <planetmaker> Alberth, providing a NewGRF which just defines one property, the cargodist one, for each cargo is possible then for sure
08:40:07  <planetmaker> like for every other property. Though it would need more looking into when one needs to check for available cargoes
08:40:57  <Alberth> thus killing any need for gui settings?
08:41:24  <Alberth> although a rough one, like the current ones, may be useful for newbies
08:41:53  <Rubidium> in the long run it'd be useful to have some settings with a 'default' and cargo specific override. However, I think the time for doing that is after we merged the game/advanced settings and thus introduced a way to dynamically construct certain sections of the configuration window
08:42:16  <planetmaker> well, as said, I would like the option to decide myself what cargo mode I play
08:42:50  <planetmaker> limiting it to newgrf-only would reduce the amount of possible games
08:44:11  <Rubidium> hmm... what about the notion of NewGRFs having access to all the settings during new game, and the user having the choice to use the "suggested by NewGRF" settings
08:44:39  <planetmaker> that's an interesting thought
08:44:55  <planetmaker> what to do when two different newgrfs suggest different value for a setting, though?
08:45:03  <planetmaker> last one wins, as usual?
08:45:05  <Rubidium> access in the sense of saying: I'd like wagon speed on, and I'd like steepness to be 10%, etc.
08:45:15  <Rubidium> show both suggestions?
08:45:38  <Rubidium> ECS A, ECS B and ECS C suggest: wagon speed limits off
08:45:45  <Rubidium> NUTS suggests: wagon speed limits on
08:46:22  <planetmaker> slope steepness: 5% (dropdown 0,1,2,3 (suggested iron horse, nars), 4,5,6,7 (suggested nuts), 8, 9, (suggested ogfx+trains), ...) ?
08:46:35  <fonsinchen>
08:46:40  <planetmaker> assuming I have those 4 trainsets active?
08:47:26  <Rubidium> hmm... slope steepness gives us yet another answer for "how long is a tile" ;)
08:47:37  <planetmaker> lol
08:47:57  <Rubidium> after all, a tile is 30 m high, so at 10% that'd be 300 meters long ;)
08:48:03  <planetmaker> not 50m?
08:48:25  <Rubidium> hmm..
08:50:09  <Rubidium> true... so tiles are even longer
12:05:25  *** frosch123 has joined
12:05:25  *** ChanServ sets mode: +v frosch123
12:34:30  <fonsinchen> We should have autotest AIs game scripts that test the API for correctness.
12:34:58  <fonsinchen> I don't feel very confident about changing anything there.
12:35:26  <fonsinchen> ^... AIs and game sripts ...
12:35:53  <frosch123> we have that for ais
12:36:04  <fonsinchen> where?
12:36:09  <frosch123> "make regression"
12:36:40  <frosch123> loads a savegame from bin/regression with an ai from bin/regression, runs a number of ticks and compares the output
12:37:11  <frosch123> the compile farm runs that test, so we know when stuff changes unexpectedly
12:37:12  * fonsinchen looks into it
12:37:41  <frosch123> if you change it: you can pipe the output of "make regression" directly into "patch" to adjust the "expected result"
12:38:42  <fonsinchen> it looks for graphics sets in some unusual place and doesn't find one
12:39:21  <frosch123> it has a custom config file, so you need to put your baseset into the public directory ~/.openttd
12:39:28  <frosch123> not into a checkout-specific one
12:41:14  <fonsinchen> great
12:41:22  <frosch123> anyway, many of the newer functions are missing from the test :)
12:43:57  <frosch123> fonsinchen: btw. ai and gs have access to all game settings
12:44:09  <frosch123> so they can already identify whether cdist is active
12:44:37  <fonsinchen> Yes, they also have that GetDistributionMode method
12:44:46  <frosch123> ah never mind, we have some gscargo functions already
12:45:05  <fonsinchen> However, only identifying whether it's active isn't much.
12:45:32  <fonsinchen> See for some suggestions
12:45:35  <frosch123> yeah, i had a discussion with zuu about that area before
12:45:40  <frosch123> i'll add some links
13:25:02  *** mg_ has quit IRC
13:30:02  *** Alberth has left
13:36:07  <fonsinchen>
13:37:06  <fonsinchen> I don't like the fact that the regression test doesn't actually test for waiting cargo but only for valid parameters
13:37:16  <fonsinchen> That's a different thing, though.
13:42:41  <frosch123> ai_changelog and gs_changelog are missing
13:46:36  <frosch123> looks fine otherwise
13:57:49  *** DorpsGek changes topic to "OpenTTD Dev Channel || Latest SVN: r26557 || Logs: || Voice (talk-right) upon request via #openttd; make sure you are registered to NickServ before asking"
14:54:59  <frosch123> <- add various mapgen settings to adv. settings window
14:55:14  <frosch123> (specifically those settings which are supported by the window)
14:56:15  <frosch123> it also allows changing some settings in game, which have (meanwhile) a meaning there
14:56:18  <frosch123> like industry density
14:57:52  <frosch123> hmm, compile farm has a different compiler than fonsinchen and me
14:58:14  <fonsinchen> link?
14:58:20  <frosch123>
15:01:32  <fonsinchen> template nesting hell
15:04:42  <fonsinchen> It doesn't construct the multimap iterators from begin() and end()
15:06:56  <frosch123> i guess it does not figure out whether to use iterator or const_iterator
15:07:10  <frosch123> i guess writing it as "if" instead of "?" fixes it
15:07:44  <frosch123> or maybe giving make_part the explicit const_iterator as template params
15:09:11  <fonsinchen> maybe
15:10:22  <frosch123> if you want to keep the "?" i would try with explicit make_pair<>
15:10:30  <fonsinchen> OK ...
15:10:53  <frosch123> in your diff the compiler still has to figure out the make_pair variant
15:11:40  <fonsinchen>
15:11:47  <fonsinchen> This is about as explicit as it gets
15:12:18  <frosch123> does that compile?
15:12:26  <frosch123> only one template param there
15:12:32  <fonsinchen> here it does
15:12:37  <fonsinchen> where?
15:12:41  <frosch123> make_pair
15:12:58  <fonsinchen> Argh
15:13:37  <Rubidium> at least gcc 4.4 and 4.6 fail. 4.7, 4.8 and 4.9 seem to be not affected
15:13:59  <fonsinchen> then
15:14:15  <fonsinchen> This is weird. I have 4.7
15:14:27  <Rubidium> clang says it's due to ambiguity
15:15:15  <Rubidium> I'm stupid again, but how do I get a diff from github?
15:15:24  <frosch123> add ".diff" to the url
15:15:31  <frosch123> or ".patch" ?
15:16:01  <Rubidium> seems to work
15:16:59  *** DorpsGek changes topic to "OpenTTD Dev Channel || Latest SVN: r26558 || Logs: || Voice (talk-right) upon request via #openttd; make sure you are registered to NickServ before asking"
15:32:43  <frosch123> any comments on the settings helptexts above?
15:34:01  <Rubidium> I don't really line the camel casing of terragenisis
15:34:23  <Rubidium> Perlin should probably be capitalized because it's a name
15:34:27  <frosch123> that's how it is called in the dropdown
15:34:45  <Rubidium> s/shall/should/?
15:35:33  <Rubidium> because there might be reasons it can't be maintained
15:35:41  <frosch123> hmm, no other appearances of "shall" in english.txt
15:35:44  <Rubidium> and then it's better to have should than "must"
15:36:29  <Rubidium> STR_CONFIG_SETTING_VARIETY_HELPTEXT seems unfinished
15:37:38  <frosch123> i did not miss anything
15:37:44  <frosch123> how do you mean?
15:38:12  <Rubidium> the otherwise at the end seems to imply some more text to me
15:38:24  <frosch123> i am refering to the other settings there
15:38:39  <frosch123> is that no english?
15:39:30  <Rubidium> I doubt it is good english
15:40:47  <frosch123> "(TerraGenesis only) Control whether the map should contain both mountainious and flat areas. Since this only makes the map flatter, other settings should be set to mountainious"?
16:13:56  <Rubidium> that sounds better
16:17:26  *** DorpsGek changes topic to "OpenTTD Dev Channel || Latest SVN: r26559 || Logs: || Voice (talk-right) upon request via #openttd; make sure you are registered to NickServ before asking"
16:55:26  *** Alberth has joined
16:55:26  *** ChanServ sets mode: +v Alberth
16:57:19  <LordAro> frosch123: "mountainious" --> "mountainous"
16:57:38  <LordAro> x2
16:58:30  <LordAro> i'd recommend "should contain" -> "contains" also
17:45:10  *** DorpsGek changes topic to "OpenTTD Dev Channel || Latest SVN: r26560 || Logs: || Voice (talk-right) upon request via #openttd; make sure you are registered to NickServ before asking"
18:23:00  <frosch123> aw, 9x failed
18:23:24  <frosch123> same line :p
18:24:44  *** DorpsGek changes topic to "OpenTTD Dev Channel || Latest SVN: r26561 || Logs: || Voice (talk-right) upon request via #openttd; make sure you are registered to NickServ before asking"
18:26:50  *** DorpsGek changes topic to "OpenTTD Dev Channel || Latest SVN: r26562 || Logs: || Voice (talk-right) upon request via #openttd; make sure you are registered to NickServ before asking"
18:45:11  <fonsinchen> Weird compiler
18:47:29  <fonsinchen> It does some crazy type transformation. make_pair isn't templated by the same types as the resulting pair.
18:48:20  <fonsinchen> So I guess leaving out the explicit templating of make_pair while keeping the explicit constructors would do the trick.
18:49:17  <fonsinchen> Is there a way to test that before I commit it?
18:49:35  <frosch123> not that i know of
18:49:59  <fonsinchen> should I just commit it and pray?
18:50:18  <frosch123> we can trigger the farm again after the release, so we do not have to wait 24 hours
18:50:21  <Rubidium> I could check it with gcc 4.4 or so
18:50:29  <Rubidium> (on Linux)
18:50:41  <Rubidium> where it failed before, so we'd know whether that works
18:51:04  <frosch123> does it currently fail for 4.4?
18:51:10  <Rubidium> no
18:51:33  <Rubidium> but IIRC the CF uses 4.4
18:51:47  <frosch123> i thought 4.0 ?
18:53:38  <Rubidium> hmm, it uses 4.5.2 it seems (based on assertion in FS#4874)
18:54:08  <frosch123> oi, that new even
18:54:14  <frosch123> but yeah, now i remember
18:54:49  <fonsinchen> would be my next guess
18:58:39  <Rubidium> that works on 4.4 and 4.6
18:59:02  <Rubidium> (don't have 4.5)
19:01:08  <fonsinchen> seems to agree with my theory
19:02:25  <fonsinchen> I'll commit it
19:03:55  *** DorpsGek changes topic to "OpenTTD Dev Channel || Latest SVN: r26563 || Logs: || Voice (talk-right) upon request via #openttd; make sure you are registered to NickServ before asking"
19:46:00  <frosch123> yay, 9x worked :)
20:39:49  *** Alberth has left
22:16:04  *** frosch123 has quit IRC

Powered by YARRSTE version: svn-trunk