Times are UTC Toggle Colours
03:04:00 *** Supercheese has joined #openttd.dev 03:04:00 *** ChanServ sets mode: +v Supercheese 06:54:42 *** Alberth has joined #openttd.dev 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> http://www.tt-forums.net/viewtopic.php?f=68&t=70490 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 #openttd.dev 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 http://www.tt-forums.net/viewtopic.php?f=65&t=70492 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 #openttd.dev 13:36:07 <fonsinchen> https://github.com/ulfhermann/openttd/commit/2a71583cb7960d7ccee476976317139acf94fdef 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: http://webster.openttdcoop.org/?channel=openttd.dev || Voice (talk-right) upon request via #openttd; make sure you are registered to NickServ before asking" 14:54:59 <frosch123> http://paste.openttdcoop.org/show/3299/ <- 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> http://farm.openttd.org/browse/OTTD-TEST-3333 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> https://github.com/ulfhermann/openttd/commit/3d9ea66e70e455fdf69ce045c9cb6c5a8a9a3816 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> https://github.com/ulfhermann/openttd/commit/222a787540bb12149ec0e740fc36cd6f1ba4362d 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> https://github.com/ulfhermann/openttd/commit/7348495b2339a616f9c1174775c1569ecf7e8e17 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: http://webster.openttdcoop.org/?channel=openttd.dev || 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: http://webster.openttdcoop.org/?channel=openttd.dev || Voice (talk-right) upon request via #openttd; make sure you are registered to NickServ before asking" 16:55:26 *** Alberth has joined #openttd.dev 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: http://webster.openttdcoop.org/?channel=openttd.dev || 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: http://webster.openttdcoop.org/?channel=openttd.dev || 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: http://webster.openttdcoop.org/?channel=openttd.dev || 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> https://github.com/ulfhermann/openttd/commit/063fbd73f9451cffb7844348c74d9e82b4fba6b0 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> http://stackoverflow.com/questions/15096358/stdmake-pair-cannot-convert-ch-type-char-to-type-char 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: http://webster.openttdcoop.org/?channel=openttd.dev || 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 #openttd.dev 22:16:04 *** frosch123 has quit IRC