IRC logs for #openttd.dev on OFTC at 2014-05-04
⏴ go to previous day
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
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: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:22 <Alberth> if you play with FIRS all the time, it pays to tune your settings to your liking
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: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:57 <Rubidium> after all, a tile is 30 m high, so at 10% that'd be 300 meters long ;)
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: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:40 <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: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:35 <frosch123> yeah, i had a discussion with zuu about that area before
12:45:40 <frosch123> i'll add some links
13:30:02 *** Alberth has left #openttd.dev
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
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
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:10:22 <frosch123> if you want to keep the "?" i would try with explicit make_pair<>
15:10:53 <frosch123> in your diff the compiler still has to figure out the make_pair variant
15:11:47 <fonsinchen> This is about as explicit as it gets
15:12:26 <frosch123> only one template param there
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: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: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: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: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:55:26 *** Alberth has joined #openttd.dev
16:55:26 *** ChanServ sets mode: +v Alberth
16:57:19 <LordAro> frosch123: "mountainious" --> "mountainous"
16:58:30 <LordAro> i'd recommend "should contain" -> "contains" also
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: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: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:33 <Rubidium> but IIRC the CF uses 4.4
18:53:38 <Rubidium> hmm, it uses 4.5.2 it seems (based on assertion in FS#4874)
18:54:14 <frosch123> but yeah, now i remember
18:58:39 <Rubidium> that works on 4.4 and 4.6
20:39:49 *** Alberth has left #openttd.dev
continue to next day ⏵