IRC logs for #openttd on OFTC at 2009-12-19
⏴ go to previous day
00:00:11 <dexter> how I can put opponents in multiplayer games?
00:00:44 <Eddi|zuHause> the server must do that
00:09:51 *** joachim has joined #openttd
00:11:22 <Belugas> mmh... Defying Gravity does not seems to have any kind of remotely possibility to be seen
00:11:34 <Belugas> but yeah, they'll put on a dvd...
00:13:45 <Eddi|zuHause> i think i have up to episode 13 here...
00:13:54 <Eddi|zuHause> but i haven't seen the last 4
00:26:25 *** Eddi|zuHause has joined #openttd
00:42:02 *** Eddi|zuHause has joined #openttd
00:57:08 <terinjokes> TrueBrain oh yes... i know that one
01:27:59 <terinjokes> TrueBrain, Rubidium: terin@THEDESKTOP-LINUX:~/documents/Base2$ file a.out
01:28:00 <terinjokes> a.out: Mach-O executable i386
01:33:29 <Eddi|zuHause> is that a "it works"?
01:34:44 <terinjokes> Eddi|zuHause: my assumption.... need a mac to test it on
01:46:01 <glx> looks like a mac intel exe
01:47:01 <SpComb^> yay, 1921, first BR01/Rheingold service
01:51:31 *** KenjiE20|LT has joined #openttd
01:54:29 <Eddi|zuHause> reminds me of my old miniin game, where i was insane enough to start a daylength 32 game
01:55:17 <Eddi|zuHause> i managed 5 years until the game became unplayably slow (with around 100 trains, mostly BR 38)
02:16:13 <SpComb^> I think 4x is pretty good
02:16:18 <SpComb^> occasionally bump up to 1x
02:27:16 <Eddi|zuHause> yeah, i'm usually doing either 4 or 8
02:32:07 *** Dred_furst has joined #openttd
02:40:06 *** zodttd2 has joined #openttd
02:56:21 *** ChanServ sets mode: +o Rubidium
02:56:21 *** ChanServ sets mode: +v orudge
02:58:29 *** Progman_ has joined #openttd
03:06:13 *** Progman_ is now known as Progman
04:04:30 *** rhaeder has joined #openttd
04:16:49 *** Rubix`` has joined #openttd
04:57:48 *** Singaporekid has joined #openttd
05:23:52 *** Eddi|zuHause has joined #openttd
07:39:52 *** Alberth has joined #openttd
07:49:52 *** Alberth has joined #openttd
08:23:36 *** Cybertinus has joined #openttd
09:21:28 *** edeca_ is now known as edeca
09:21:34 <edeca> Thanks for fixing that bug Rubidium :)
09:22:02 *** edeca is now known as Guest42
09:22:41 *** Guest42 is now known as edeca
09:23:33 <CIA-1> OpenTTD: rubidium * r18533 /trunk/src/pathfinder/npf/npf.cpp: -Fix: don't refer, in the comments, to a long renamed function
09:24:03 <edeca> I'll have to wait for a nightly to get the fix
09:24:15 <edeca> Today's nightly stops 2 revisions short
09:27:52 <Rubidium> that happens when it gets build hours before I even began looking at the issue
09:41:37 *** JVassie has joined #openttd
09:57:22 *** Progman has joined #openttd
10:29:38 *** frosch123 has joined #openttd
10:37:05 *** oskari89 has joined #openttd
10:49:44 <frosch123> yeah, seems to work
10:49:47 <Wolf01> snowy saturday... 22 years since last one... 40cm of snow
10:50:14 <frosch123> you do not need any training, do you?
11:01:28 *** welshdragon has joined #openttd
11:11:49 *** ChanServ sets mode: +v tokai
12:15:12 *** Polygon has joined #openttd
12:16:23 <peter1138> Eddi|zuHause, half-tile rivers you say?
12:19:11 <Xaroth> heh, firefox no like that link
12:19:15 <Xaroth> sais it contains errors :P
12:21:21 <SpComb^> that's what you get with giant screenshots
12:22:16 <Singaporekid> 83mb png file D:
12:23:29 *** fonsinchen has joined #openttd
12:24:43 <peter1138> load average: 10.80, 4.65, 1.85
12:26:29 <Singaporekid> SpComb^: Are you hosting openttd servers?
12:33:17 <SpComb^> Singaporekid: for personal use
12:52:38 <AshKyd> Has the name generator been messed with? It’s coming up with some rather unfortunate names in 0.7.4.
12:53:27 *** KenjiE20 has joined #openttd
12:55:34 <AshKyd> Chuntford and Great Sluttown.
12:55:43 <AshKyd> Those are the only two I’ve noticed.
12:55:46 * edeca giggles like a schoolgirl
12:56:05 <AshKyd> Yeah, I giggled too, but it’s a bit inappropriate. BBL.
12:57:07 <Eddi|zuHause> Wolf01: so what kind of chaos would there be, were this a weekday?
12:58:08 <edeca> Some countries handle snow pretty well. The UK is not one of them :)
12:59:35 <Wolf01> I think it would stop the world
13:07:20 <edeca> You can only imagine that conversation he's having
13:07:29 *** lewymati has joined #openttd
13:08:20 <SpComb^> just drive along slowly and it will go away
13:08:33 <SpComb^> unless someone clamped it to the rails
13:10:33 <Eddi|zuHause> ... or sound the horn really loud
13:14:30 <edeca> Surely the solution there is to get out and push?
13:14:49 <SpComb^> I'll give that drift 8 points score
13:15:04 <SpComb^> but not enough sparks, I think
13:21:27 *** Chruker has joined #openttd
13:35:13 *** Luukland has joined #openttd
14:08:54 *** gathers has joined #openttd
14:16:21 *** HerzogDeXtEr has joined #openttd
14:22:30 *** Dred_furst has joined #openttd
14:28:29 <KingJ> Oops, almost missed the train. Generally considered a bad thing to do...
14:29:24 <SpComb^> Eddi|zuHause: was there ever a reduced-passenger-amounts patch?
14:29:36 <Eddi|zuHause> SpComb^: yes. plenty
14:30:35 <Eddi|zuHause> try www.informatik.uni-halle.de/~krause/lesstuff_2.diff
14:30:39 <Eddi|zuHause> try www.informatik.uni-halle.de/~krause/lessstuff_2.diff
14:31:23 <Eddi|zuHause> i'm not entirely sure if it applies to mail, too
14:31:39 <Eddi|zuHause> change the constant to your liking
14:32:11 <SpComb^> hmmyes, I was looking at that code
14:32:27 <Eddi|zuHause> i found 4 close to the limit that a sensible network can handle, 8 or 16 if you want more spaced out networks
14:33:05 <SpComb^> with or without cargodist?
14:35:33 <gathers> Hi, I'm working on a patch where you can automate timetables, which means that things like adding/removing orders/vehicles etc should "just work". But where should the on/off flag for such a mode best be placed? As a new bit in v->vehicle_flags or as a bool in the OrderList? (if that matters at all?)
14:39:34 <Eddi|zuHause> gathers: for parts of that you might find inspiration in the improved timetable management patch by PhilSophus
14:39:34 <frosch123> every vehicle has its own vehicle_flags, orderlists are shared when using shared orders
14:40:11 <Eddi|zuHause> it's a little outdated, and (minor) parts have gone into trunk
14:40:27 <gathers> yes, and I want it to be shared so it's activated when cloning vehicles etc
14:40:36 <frosch123> despite of that, from your description it does sounds more like a global/per-company advanced setting than a vehicle/order setting
14:41:51 <gathers> Eddi|zuHause: I'm actually basing it on the Timetable based separation patch from Magicbuzz. I have the separation working as well.
14:42:42 <Eddi|zuHause> gathers: the "manual" separation [aka start dates] have been included in trunk
14:43:03 <gathers> frosch123: my idea is that you should be able to both have automated timetables and normal ones. so I have the flag to be carried over when sharing orders.
14:43:14 <Eddi|zuHause> gathers: but the autoseparation was generally viewed as not flexible enough
14:44:07 <Eddi|zuHause> gathers: so the timetable management patch introduced the "headway" feature, which allowed to set automatic or manual separation
14:46:05 *** Coco-Banana-Man has joined #openttd
14:46:21 <gathers> Eddi|zuHause: what was the major complaints about automatic separation? would something the either gives automatic separation or normal plain timetables also be too inflexible?
14:47:13 <gathers> what I'm most interested in is making the user never have to update the timetable after changing something
14:50:56 <Alberth> breakdowns are not handled nicely, I believe
14:51:36 <Eddi|zuHause> gathers: all implementations i have seen had problems with vehicles switching places in the queue
14:53:06 <Wolf01> uhm... where's ended up the BEGIN/END_TILE_LOOP macro?
14:54:16 <gathers> I'll have to test breakdowns and switching places
14:55:26 <Eddi|zuHause> Wolf01: src/map_func.h:TILE_LOOP()?
14:56:00 <Wolf01> I tried to use it in station_cmd.c but it says it's not declared on the current scope
14:56:27 <Wolf01> I thought it was used by the rail station function too
14:56:30 <Alberth> In the few attempts I have done, it simply takes the first round trip time as *the* length of each interval. If at that trip, the vehicle did not break down or got serviced, it constantly runs increasingly late
14:57:13 <Eddi|zuHause> Alberth: it generally estimates the first round too fast, because of loading times etc. even without breakdowns
14:57:45 <Eddi|zuHause> unless you manually add a delay at the end station, vehicles never catch up.
14:58:01 <Eddi|zuHause> it needs an automatic delay factor (like
14:58:08 <gathers> Alberth: yes, that's why I'm making all times automatically adjusting (loading times can increase and decrease)
14:58:26 <gathers> Eddi|zuHause: I've added that to loading, but only set it fixed at 100 ticks for now
14:58:30 <Alberth> I can also build new roads or demolish old ones
14:59:13 <Eddi|zuHause> gathers: yes, but automatically adjusting might also pose problems, if i want to have a fixed cycle length (e.g. to synchronize two lines)
14:59:48 <Eddi|zuHause> that's why i said a general "do it." button is not flexible enough
15:00:35 <Alberth> Eddi|zuHause: perhaps first get it working for a single line first?
15:00:35 <gathers> Eddi|zuHause: but what if the automatic adjustments can be switched off? then what you have it the old static timetable again
15:02:00 <Eddi|zuHause> gathers: but what about having automatic separation, but not automatic timetable adjustment? or what about having asymmetric separation (because of single track with sidings)?
15:02:26 <Eddi|zuHause> gathers: the timetable management had a few parts of that working, you really should take a look at that
15:03:02 <Eddi|zuHause> especially the virtual 24h clock or the station timetables could possibly be reused
15:03:31 <gathers> Eddi|zuHause: I have two options, one for separation one for automatic adjustments :P so you can have just one and not the other. But more advanced timetable handling I haven't much thought about
15:03:58 *** fonsinchen has joined #openttd
15:04:18 <gathers> What I want for my games is just a "activate once and then forget" thing for certain lines.
15:04:36 <CIA-1> OpenTTD: alberth * r18534 /trunk/src/station_gui.h: -Doc: Add doxy strings to StationCoverageType enum.
15:06:56 <gathers> Eddi|zuHause: wish I knew the codebase better, I'm sure there are other things that could be used. Even just figuring out how to get a button in the gui took a while :P
15:16:00 <gathers> let me know if you want to look at the patch now. I think it's working ok but it's not very well tested. I'll post it on the forums later but not sure if it'll be today.
15:17:16 <Eddi|zuHause> gathers: especially the synchronizing of separate routes was the problem of the last autoseparation patch
15:19:17 <gathers> Eddi|zuHause: and that is where station timetables could help?
15:20:28 <Eddi|zuHause> yeah, manually shifting a vehicle back and the autoadjustment recognizing that change
15:22:23 <gathers> Eddi|zuHause: I'll have to try it out, but ideally you should get the same effect by pausing a train for a while and then restarting it. Every train should adjust, not just the one you paused?
15:23:00 <Eddi|zuHause> not entirely sure about that...
15:23:17 <Rubidium> isn't that what headway does?
15:23:34 <Eddi|zuHause> sometimes you want to send a train to depot and want to remove it from the separation queue
15:23:45 <Eddi|zuHause> that's what pausing a train should do imho
15:23:56 <Eddi|zuHause> Rubidium: yeah, i was trying to convince him...
15:24:15 <gathers> I'll have to read up on headway :(
15:25:18 <Eddi|zuHause> SpComb^: + amount = (amount + 1) >> -cf; <-- that's not what my patch said
15:25:32 <gathers> I'm just too impatient to have some kind of automatic separation I took that part straight out of an old patch. but I would like to rewrite the separation part myself as well.
15:26:08 <SpComb^> Eddi|zuHause: it's slightly different
15:26:33 <Eddi|zuHause> and what's the - for?
15:26:50 <SpComb^> you set the factor to -x to decrease cargo by 2**x
15:26:53 <Eddi|zuHause> ah, you want to both increase and decrease
15:27:02 <SpComb^> the increase doesn't make much sense, but why not
15:27:15 <SpComb^> maybe someone likes having 10k passengers waiting at a station for sadistic reasons
15:27:42 <Eddi|zuHause> SpComb^: anyway, the patch did "amount = (amount + (x-1))/x" to prevent rounding down to 0
15:29:33 <Eddi|zuHause> SpComb^: and what about the newgrf callback?
15:29:46 <Eddi|zuHause> i don't find it in your patch
15:29:59 <SpComb^> there's three calls to TownGenerateCargo
15:30:46 <CIA-1> OpenTTD: rubidium * r18535 /trunk/src/pathfinder/ (npf/npf.cpp yapf/yapf_costrail.hpp yapf/yapf_node_rail.hpp): -Fix [FS#2722]: don't account for path reservation costs when entering a signal block via a 'block' signal. This way you won't get double penalties, both red signals and reservation costs, for the block signalled tracks
15:31:35 <CIA-1> OpenTTD: rubidium * r18536 /trunk/src/vehicle.cpp: -Fix [FS#3386]: MSVC warning. Patch by pavel1269
15:32:14 <SpComb^> as for rounding off to zero... hmm
15:34:43 <Eddi|zuHause> SpComb^: there was another patch that kept around the fractional values
15:34:48 <Eddi|zuHause> and added them up
15:35:14 <Eddi|zuHause> like i said, there were multiple patches ;)
15:35:24 <SpComb^> but I guess you do need it, since you're dealing with 10-100s of houses
15:37:13 <SpComb^> but I think I'll just cheat and bump it up to 1 if it goes to zero
15:38:43 *** De_Ghosty has joined #openttd
15:38:55 <Alberth> I thought about that solution too, but you get 1 passenger for a long time (ie between amount == 1 to amount = 2*x -1)
15:41:20 <Eddi|zuHause> SpComb^: well, you should return 0 if the original value was 0
15:41:21 <SpComb^> the raw amount is 0-255 / 8 + 1
15:41:27 <SpComb^> Eddi|zuHause: the original value is never 0
15:41:48 <Eddi|zuHause> SpComb^: even for the newgrf callback?
15:43:16 <SpComb^> if (amt == 0) continue;
15:47:49 <SpComb^> although I guess perhaps the best thing to do would be to just skew the 2^x a bit so that it's not completely exponential, by increasing the range of the raw value to at least 2^x before dividing it
15:48:12 <SpComb^> then you can just use a slightly higher multiplier to compensate
15:51:50 <SpComb^> now where's my graphing calculator...
15:52:07 <CIA-1> OpenTTD: frosch * r18537 /trunk/src/economy.cpp: -Fix (r17436): Also do not account cargo in statistics, if it was not accepted.
15:53:03 <CIA-1> OpenTTD: alberth * r18538 /trunk/src/ (misc_gui.cpp station_gui.h): -Codechange: Split DrawStationCoverageText into a calculation part and a drawing part.
15:54:37 <SpComb^> hmm... a bit too much
15:57:04 *** Gremnon has joined #openttd
16:02:41 <CIA-1> OpenTTD: alberth * r18539 /trunk/src/station_gui.cpp: -Codechange: Re-use cargolist drawing in StationViewWindow::DrawAcceptedCargo()
16:15:10 *** De_Ghosty has joined #openttd
16:18:18 *** worldemar has joined #openttd
16:22:44 <SpComb^> updated, now it's `amount = (amount + ((1 << -cf) - 1)) >> -cf;`
16:25:43 <SpComb^> and, well, it seems to work sensibly :)
16:40:47 <SpComb^> so there's a minimum limit as to the lowest you can get town production to, which is presumeably something on the order of the number of houses in the town
16:50:45 <frosch123> you could change "((1 << -cf) - 1)" to something like "(_date & ((1 << -cf) - 1))" or so
16:51:33 <SpComb^> but I suspect that it'll work well enough even without that
16:52:48 *** Eddi|zuHause has joined #openttd
16:53:35 <SpComb^> Eddi|zuHause: I adjusted the reduction function
16:55:36 <SpComb^> an integer from -16 to +8
16:55:47 <edeca> Should articulated vehicles overtake?
16:55:51 <SmatZ> shifts with negative counts are undefined
16:56:03 <SpComb^> SmatZ: yes, that's why I do either a << or an >> based on the sign
16:56:19 <SmatZ> ok, I didn't see the code :)
16:56:28 <SmatZ> [17:22:46] <SpComb^> updated, now it's `amount = (amount + ((1 << -cf) - 1)) >> -cf;` <== didn't show you care about that ;)
16:57:54 <edeca> The option to buy shares is greyed out (nightly), any reason why:?
16:59:04 <frosch123> disabled in advanced settings?
16:59:16 <edeca> Ah, I didn't realise that was possible
16:59:46 <edeca> Still no joy with my articulated road vehicle overtaking though, hrrm
17:00:04 <SpComb^> hey, I'm learning how to use git \o/
17:00:11 <SpComb^> merging branches is fun
17:02:25 <frosch123> articulated vehicle cannot be overtaken
17:08:25 *** Eddi|zuHause has joined #openttd
17:11:53 <SpComb^> Eddi|zuHause: new reduction function
17:14:47 <CIA-1> OpenTTD: frosch * r18540 /trunk/src/economy.cpp: -Codechange: resulting in better name for 'result'.
17:16:01 <edeca> Hrm, is it a bug if non electric trains wont go to an electric depot when you click "send to depot" ?
17:17:36 *** |Jeroen| has joined #openttd
17:19:14 <Gremnon> I don't think so, since Eltrain depots can make non el-trains
17:21:50 <edeca> So that would mean it _is_ a bug
17:22:21 *** valhallasw has joined #openttd
17:22:39 <edeca> Ah, it could just be that it's not pathfinding far enough ahead
17:23:30 <Gremnon> .... no... A normal depot can only build steam/diesel, and therefore only services them. Electric depots can do everything a normal can, plus electric, so they'll service steam, diesel and electric
17:23:47 <Gremnon> if you want a specific depot, give it an order to go to it
17:24:49 <edeca> The scenario was: upgrade all rail to electric including depots, click station, click "trains that stop here", click "send to depot" and that failed
17:24:59 <edeca> But it seems to be because the depots were too far
17:27:33 <edeca> It seems the "send to depot" is only looking head ~20 tiles ma
17:29:24 <Gremnon> which pathfinder are you using? NPF has no issues for me unless it's really far away
17:31:03 <edeca> glx: That's correct? OK then :)
17:32:27 *** Eddi|zuHause has joined #openttd
17:38:50 <planetmaker> edeca: it's looking ahead exactly 20 tiles
17:45:31 <edeca> planetmaker: Well that was a good guess on my part then :P
17:45:58 <edeca> I've got it cleaned up now anyhow, so that's all good
17:54:49 *** Rubix`` has joined #openttd
17:56:51 <Rubidium> planetmaker: it is not looking ahead 20 tiles, it's looking ahead 20 tiles worth of pathfinder penalty
17:57:17 <Rubidium> and with YAPF 45 degree corners are already like 3 tiles
18:00:50 <CIA-1> OpenTTD: peter1138 * r18541 /trunk/src/ (5 files in 3 dirs): -Feature: Additional map variety option for TGP landscape generator. Evolved from curve map idea from Zephyris.
18:02:50 <Eddi|zuHause> that was quick...
18:03:17 <CIA-1> OpenTTD: alberth * r18542 /trunk/src/window_gui.h: -Codechange: Make nested widget parts obligatory in a window description.
18:05:44 <edeca> Damn it! Looks like I closed the game before it had saved :(
18:06:07 <Alberth> use the last autosave
18:06:12 <planetmaker> ok, missed the PF penalties. Thanks for correcting, RB
18:06:19 <planetmaker> and yes, petern is quick :-)
18:06:40 <edeca> Fantastic Alberth, thank you!
18:07:00 <edeca> What's all this curvy business?
18:07:04 <Alberth> edeca: that's why they exist :)
18:07:29 <Alberth> edeca: new map generation possibilities. There is a forum thread somewhere
18:07:51 <planetmaker> I mean... curves can be tasty :-P
18:07:59 <planetmaker> and nice to look at
18:08:18 <Alberth> maps were nice indeed
18:09:05 <peter1138> it works best with mountainous terrain type
18:09:07 <planetmaker> assumingly not to the worse, though ;-)
18:09:27 <peter1138> no, there's more choice now
18:09:38 <peter1138> although you may not get good maps with all settings
18:09:59 <planetmaker> one didn't either before with the original one
18:12:46 <SpComb^> ugh, trying to form patches between two branches when they're based off different versions of trunk is difficult
18:13:27 <SpComb^> can't just do one `git diff A...B` because you get bits of trunk along with it
18:13:57 *** worldemar has joined #openttd
18:15:11 <gathers> SpComb^: you can perhaps make a dummy branch of one of them, rebase --onto the dummy to where the other starts, and then make the diff
18:15:42 <SpComb^> or just patch them in by hand and then make the diff off the working copy changes
18:16:20 <planetmaker> hm... I need a good catchy translation for "variety distribution"
18:17:18 <Alberth> official strategy is to merge the diff between last trunk update of branch A and branch head of A, on top of head of branch B
18:17:24 <planetmaker> SpComb^: you need something like hg rebase or so
18:17:34 <planetmaker> git probably has that, too
18:18:35 <SpComb^> I presumed that rebaseing from the newer branch onto the older one would also pull in stuff from trunk
18:18:42 <SpComb^> but rebase still confuses me a little
18:18:51 <gathers> SpComb^: take a look at rebase --onto
18:19:33 <peter1138> planetmaker, if you can figure out what it means anyway :s
18:19:36 *** Luukland has joined #openttd
18:19:43 <peter1138> it's not the amount of variety, certainly
18:20:00 <planetmaker> yes. It's the separation of landscape types or so
18:20:19 <michi_cc> SpComb^: git rebase --onto A master B (rebase all commits of B not in master onto branch A)
18:20:53 <frosch123> planetmaker: Diversifizierung/-zität :p
18:21:13 <planetmaker> peter1138: the single selectable entries could use their own translation. Part of the strings were stolen from elsewhere.
18:21:38 <Luukland> Fugas 31 banned users :p
18:21:39 <planetmaker> (are already translated)
18:22:39 <peter1138> you translate "low" as an amount differently?
18:22:51 <planetmaker> It depends on how I name that feature ;-)
18:23:09 <planetmaker> it could "niedrig", "wenig" "gering" "klein"
18:23:13 <planetmaker> depending on context
18:25:28 <planetmaker> frosch123: it's not the worst translation... but too "nose up" ;-)
18:27:25 *** Rhamphoryncus has joined #openttd
18:28:58 <planetmaker> "Geländeformen" seems to be the proper word. And then _I_ don't mind to use the translations for the selections already in place
18:32:10 <planetmaker> hm... no. They don't fit :S
18:33:57 <SpComb^> someone fix the default savegame filename format so that they sort correctly in lexicographic order...
18:34:03 <planetmaker> sorry. I feel like a party-spoiler :-(
18:35:20 <Rubidium> SpComb^: would something like "Advanced settings -> Interface -> Display options -> Use ... format for savegames" suffice?
18:35:49 <SpComb^> even though I didn't know there was an option
18:36:32 <Rubidium> it is the default savegame filename format... it's non-default when you enter the name yourself
18:36:46 <CIA-1> OpenTTD: peter1138 * r18543 /trunk/src/ (genworld_gui.cpp lang/english.txt): -Codechange: Use separate set of strings for variety distribution setting to ease translation.
18:37:34 <Rubidium> oh... someone who intensely loves to translate?
18:38:23 <gathers> SpComb^: what happens with the running costs of vehicles when the daylength is longer? do the per-year values increase as well?
18:39:17 <planetmaker> feel free, peter1138 :-) >:-)
18:39:25 <Eddi|zuHause> a lot of the language features can be blamed on german :p
18:39:51 <planetmaker> Eddi|zuHause: but not in OpenTTD...?
18:41:21 <DorpsGek> Eddi|zuHause: Commit by ludde :: r2594 /trunk (13 files in 3 dirs) (2005-07-16 20:58:04 UTC)
18:41:22 <DorpsGek> Eddi|zuHause: Fix: [strgen] Misc updates to the string system.
18:41:23 <DorpsGek> Eddi|zuHause: - Renamed the plural command to "P" instead of "PLURAL". Now write something like this to append an s on plural: {P "" s}. (You can optionally still add an argument index to explicitly specifiy which number that's used)
18:41:24 <DorpsGek> Eddi|zuHause: - Removed the pluralized cargo strings from the string files. The new method is to use the plural specifier {P}
18:41:25 <DorpsGek> Eddi|zuHause: - Added support for genders. First add "##gender der das die" on top, then use {G=der} on a cargoname/industry to set the gender, and to switch between genders do something like {G neu neu neue} {STRING}
18:42:44 <planetmaker> cases. Not genders. Whatever :-P
18:44:32 <Eddi|zuHause> well, i did say what i mean
18:45:33 <CIA-1> OpenTTD: translators * r18544 /trunk/src/lang/ (6 files in 2 dirs): (log message trimmed)
18:45:33 <CIA-1> OpenTTD: -Update from WebTranslator v3.0:
18:45:33 <CIA-1> OpenTTD: croatian - 36 changes by
18:45:33 <CIA-1> OpenTTD: french - 8 changes by glx
18:45:33 <CIA-1> OpenTTD: german - 8 changes by planetmaker
18:45:33 <CIA-1> OpenTTD: greek - 3 changes by fumantsu
18:45:33 <CIA-1> OpenTTD: norwegian_nynorsk - 10 changes by 2rB
18:45:41 <glx> planetmaker: we are fast ;)
18:46:06 <Eddi|zuHause> but the croatian guy had way more changes!
18:46:26 <planetmaker> I thought it was already too late. Nice! :-)
18:46:45 <Rubidium> Eddi|zuHause: the croatian guy just... uhm... broke WT3
18:46:52 <CIA-1> OpenTTD: frosch * r18545 /trunk/src/video/ (6 files in 2 dirs): -Fix [FS#3292]: Assign '_screen.dst_ptr' as soon as it is allocated.
18:47:16 <planetmaker> I think it was greek before?
18:47:33 <Rubidium> glx: yeah, although this time it isn't blocking language commits and the last time it was
18:47:44 <Rubidium> planetmaker: yeah, the greek broke it before that
18:48:06 <planetmaker> seems to happen... regularily :S
18:48:36 <Rubidium> something's happening with cases
18:48:47 <Rubidium> which probably isn't the best tested part of WT3
18:49:00 <Rubidium> and TB doesn't have much time lately and as such it isn't fixed yet
18:49:40 <peter1138> cool, down to 3 bugs ;p
18:49:45 <planetmaker> cases. nasty cases.
18:49:52 <planetmaker> ^ not the Germans :-P
18:50:42 <Madis> btw, whose idea was it to have all nouns with capital letters in German?
18:51:24 * SpComb^ wonders if the monolithic savegame version scheme could be improved
18:51:25 <planetmaker> Madis: tests show that it makes for slightly faster reading ;-)
18:51:49 <Madis> but it sucks either way
18:52:00 <planetmaker> You don't mind, if I disagree?
18:52:02 <Madis> It's Hard To Read A Sentence Like That
18:52:17 <planetmaker> Es ist nicht so schwer einen solchen Satz zu lesen.
18:52:25 <planetmaker> ^which would be the German equivalent.
18:53:10 <Rubidium> still, it's harder to read than "It's hard to read a sentence like that"
18:53:15 <planetmaker> and the contrary is true :-)
18:53:24 <Rubidium> planetmaker: really?
18:53:42 <Madis> but... Ich kann schlecht Deutch sprechen. If I write it, I have to think whether to capitalize schlecht, Deutch or sprechen
18:53:52 <Rubidium> peter1138: what is harder for you to read? "It's hard to read a sentence like that" or "Es ist nicht so schwer einen solchen Satz zu lesen.
18:54:31 <Prof_Frink> The one in Foreign.
18:54:44 <Madis> I think he just passed out, way too hard for him.. both :D
18:55:07 <Prof_Frink> Yes, but it's unreadable, so should be disregarded.
18:55:07 <planetmaker> tested actually with Dutch people reading German :-)
18:55:22 <Madis> planetmaker only that nobody but you (and the rest 80 million german speakers) can't understand you
18:56:10 <planetmaker> The nouns are important. Therefore capitalized ;-)
18:56:26 <Madis> no, the names are important
18:56:46 <Madis> and in Estonian we don't even capitalize the names of nations or languages
18:56:51 <Madis> only the names of countries
18:57:16 <Xaroth> peter1138: lost cause :P
18:57:25 <Madis> and first word of a sentence, but nothing else, really
18:57:26 <peter1138> i've no idea what they're talking about
18:57:50 <Madis> and German being shitty about it
18:58:05 <Xaroth> Maybe the estonian have it all wrong ;)
18:58:15 <Prof_Frink> Madis: Latin's even better.
18:58:25 <Xaroth> and caps lock is cruise control for cool, i know
19:00:00 <Madis> If I were, would I be listening to Alicia Keys' 1st December concert from utub?
19:01:42 <Eddi|zuHause> * SpComb^ wonders if the monolithic savegame version scheme could be improved <-- the main improvement point would be a name/value dictionary for settings
19:02:07 <Eddi|zuHause> would account for most of the savegame-changing patches
19:02:11 <SpComb^> some kind of way to identify induvidual chunks and their versions
19:04:15 <SpComb^> the most common case is where you have a savegame produced by patch A which adds setting a and bumps the version to x - then you add a patch B which adds a setting b and doesn't bump the savegame version - then you try and load that savegame with that
19:04:41 <SpComb^> which you can workaround by fudging around with the sl versions in the code
19:05:13 <Eddi|zuHause> SpComb^: if you had a dictionary, adding a setting wouldn't require a savegame version bump at all
19:05:34 <SpComb^> I guess, I haven't looked at the internals of the sl system
19:06:29 <planetmaker> he, such change would be interesting indeed
19:06:41 <Rubidium> Eddi|zuHause: yeah... until someone changes the meaning of a variable and you're totally screwed
19:07:00 <planetmaker> Rubidium: yes, but that's what the savegame version is for, isn't it?
19:07:08 <Eddi|zuHause> Rubidium: that, again, could be handled by an actual version bump
19:07:23 <Rubidium> especially the OMANY kind
19:08:08 <Rubidium> Eddi|zuHause: but... what if your slightly patched version also bumps the version? Then it would be loadable in trunk and the conversion wouldn't be done
19:08:51 <Eddi|zuHause> Rubidium: there are always ways to break it...
19:12:06 <SpComb^> mm, I have to crank this exponent down to -4 before my network manages to keep up
19:19:03 *** lobster has joined #openttd
19:21:51 <CIA-1> OpenTTD: rubidium * r18546 /trunk/src/ (6 files): -Codechange: make making the screenshot not asynchronious; just do it at the moment it's requested.
19:29:14 <CIA-1> OpenTTD: rubidium * r18547 /trunk/src/video/sdl_v.cpp: -Fix [FS#3388]: missing thread synchronisation when changing the resolution for SDL via the in game menu
19:33:22 <Noldo> should I need something more than grfcodec and renum to make opengfx?
19:34:00 <Rubidium> a preprocessor and sed/awk/make are probably useful
19:34:25 <Ammler> stuff you use fro building openttd should be enough, afaik.
19:35:42 <Rubidium> might be a missing preprocessor
19:37:18 <Ammler> it somehow fails to remake dependency check.
19:40:24 <planetmaker> Noldo: gcc and md5sum
19:41:20 <Noldo> planetmaker: those I checked earlier
19:41:33 <Noldo> hmm, something isn't liking my new palette
19:41:41 <Noldo> planetmaker: it works now :)
19:42:11 <planetmaker> what did you do differently?
19:42:33 <Noldo> planetmaker: make clean && make, as Ammler told me to
19:42:43 <planetmaker> just a missing make clean
19:42:50 <planetmaker> hm, yes, sometimes it helps
19:43:05 <planetmaker> you could use make remake instead ;-)
19:43:36 <planetmaker> nice that it works, though
19:44:09 *** Rubix`` has joined #openttd
19:44:19 <Noldo> is it grfcodec that is working when it says stuff like: Loading sprites/pcx/mapgen.pcx
19:44:55 <Noldo> it's not happy with the changes palette
19:45:09 <planetmaker> you shouldn't change the palette of a the files
19:45:28 <planetmaker> that nearly always makes grfcodec unhappy
19:47:31 <planetmaker> for all practical purposes the pcx files of OpenGFX need to be in the TTD windoze palette format
19:48:20 <Noldo> it's mapgen.pcx, no-one will notice
19:49:40 <planetmaker> well. yes. grfcodec
19:49:49 <Ammler> [20:42] <planetmaker> you could use make remake instead  <-- does that work now?
19:49:58 <planetmaker> Ammler: it always did
19:50:19 <Ammler> he, you already forgot :-P
19:50:36 <planetmaker> no, I didn't. I never understood that :-)
19:53:17 <planetmaker> remake is an alias for clean and all
19:53:45 <planetmaker> peter1138: it's really fun to generate maps with that new feature. They're awesome :-) Kudos
19:54:10 <Ammler> planetmaker: but it doesn't repeat the depend check
19:54:29 <Ammler> I am quite sure, I told you....
19:55:06 <planetmaker> the deps don't change, do they?
19:56:03 <Ammler> try my scenario... :-P
19:56:25 <Ammler> maybe it is something else...
19:57:12 <Ammler> oh, the nfo is generated but without renum, so it is there but doesn't work
19:57:53 <Noldo> oh my, my trunk checkout was really old
20:05:22 <CIA-1> OpenTTD: peter1138 * r18548 /trunk/src/lang/english.txt: -Fix (r18541): Unused string slipped in.
20:06:50 <peter1138> planetmaker, now you need some rivers ;)
20:06:54 *** lewymati has joined #openttd
20:30:02 <peter1138> did you see my half-tile rivers?
20:31:24 <Eddi|zuHause> not yet, having kinda system problems today
20:31:35 <Eddi|zuHause> pondering restoring the backup...
20:33:31 <Eddi|zuHause> being able to neither "svn up" nor "make" is kinda problematic to development :p
20:37:03 *** Terkhen has joined #openttd
20:53:59 <Eddi|zuHause> src/lang/german.txt:1043: warning: String name 'STR_TERRAIN_TYPE_MIXED' does not exist in master file <-- i guess someone was too fast ;)
20:56:11 <planetmaker> but indeed... rivers will be nice...
20:56:39 <Noldo> planetmaker: I managed to generate new game with my own mapgen sprites
20:59:12 <planetmaker> so... how does it look like, Noldo ?
21:00:18 <glx> Eddi|zuHause: I guess it warns for french too :)
21:00:29 <Noldo> it looks like someone made simple testsprites for mapgenerator and generated a new map on with them
21:01:24 <Noldo> most of the sprites are predominantly of colorindex 0 ie. water
21:03:03 <Eddi|zuHause> it's weird, it's like 100 files in until it discovers that neither libsdl-devel nor libpng-devel are installed ;)
21:03:08 <planetmaker> well... I'm asking for the reason that I also generated some new sprites for them - but it looks very much unlike the original. Only with occasional mountains, independent on the roughness setting
21:03:12 <planetmaker> and that bugs me :-)
21:04:11 <Noldo> I think we need to figure out exactly how the different sprites are used
21:04:50 <planetmaker> that's my guess, too.
21:05:07 <planetmaker> but I didn't get to that yet... nor will in the next hours :-)
21:06:42 <_ln> quite an interesting season finale for Dexter.
21:07:00 <Eddi|zuHause> peter1138: not finding any rivers, do i look in the wrong place?
21:07:21 <Eddi|zuHause> _ln: quite an insane thing to spoil it :p
21:09:09 *** Gremnon has joined #openttd
21:09:28 <_ln> Eddi|zuHause: you are greatly surprised by the fact that the season ends "interestingly", with a cliff-hanger?
21:10:14 <Eddi|zuHause> _ln: no. even "somebody dies" wouldn't exactly be a spoiler with dexter :p
21:10:25 <peter1138> Eddi|zuHause, oh right... i didn't actually post anything... whoops
21:14:20 <Noldo> planetmaker: :/ part of my sprites were still random noice
21:14:56 <planetmaker> ah. If you like I can give you my version, too, to play around with.
21:18:48 <peter1138> hmm, zephyris just posted some
21:19:57 <CIA-1> OpenTTD: rubidium * r18549 /trunk/src/vehicle.cpp: -Fix: first do the time-since-last-service check and only then determine whether autoreplace needs to take place. This way they will not keep autoreplacing continuously on failure, but only after some timeout.
21:30:11 <planetmaker> oh. he. There and those. yes
21:31:57 <Eddi|zuHause> Rubidium: could there be some sanity checks like cargo types of the replacement vehicle before attempting to go for autoreplace-servicing?
21:34:25 <planetmaker> Noldo: but you could give them a try and use those of yours, his and mine which give best results.
21:35:06 <planetmaker> having sprites is only half way. Getting them into the game and testing how they look (and adjusting) is the other half
21:35:46 <Noldo> I still want to figure out how the old generator uses the sprites
21:37:38 <planetmaker> and that would be good to know. Maybe you can document that then also somehow - so that that knowledge doesn't get lost. Maybe add a few appropriate comments to the source where they are used
21:38:18 <Zuu> planetmaker: Maybe you want to know, the program you helped testing has been released and is now available on the website. (www.junctioneer.net)
21:38:44 <planetmaker> congratz, Zuu! :-)
21:39:14 <Zuu> I noticed though that on my Linux system the strings painted by the same font engine becomes slightly longer so there is some glitches in the about dialog for example.
21:39:22 <Noldo> oh no, there's bitsifting
21:40:36 <planetmaker> Noldo: I think only 4 bit or so are used as hightmap. *someone* in this channel said so.
21:40:57 <Noldo> it was Yexo and I did find that from the source too
21:41:53 <Noldo> I also know that is takes to runs of stamping those tempaltes on the map and the locations and orientations are random
21:42:11 <Noldo> the two runs seem to use different sprites
21:42:40 <CIA-1> OpenTTD: smatz * r18550 /trunk/src/town_cmd.cpp: -Fix (r18281): show expected price of town construction even when the company doesn't have enough money
21:42:47 <peter1138> there are 5 different types
21:43:13 <peter1138> which are used depends on the climate selected
21:43:16 <Noldo> and 2 arrays of magical index arrays
21:43:41 <Noldo> 2 arrays of magical indices
21:46:09 <peter1138> they're counts, not indices
21:46:49 <peter1138> (r >> 24) gives you an 8 bit random number used like a percentage (but a per256age)
21:49:07 <Noldo> yes, that part really had me confused
21:50:14 <Noldo> so if the r >> 24 is 0 ans type is 0,1,2 or 3 the sprite id will be 4845?
21:54:01 *** Illegal_Alien has joined #openttd
21:54:47 <CIA-1> OpenTTD: frosch * r18551 /trunk/src/vehicle.cpp: -Fix [FS#1762]: When autoreplace is the only allowed reason to send vehicles to depot, first check some minimal requirements (engine availability, refittability) and a heuristic for the needed money.
21:55:17 <frosch123> Eddi|zuHause: you are impatient
21:56:03 <Eddi|zuHause> no, i'm only ahead of my time :p
21:56:23 <Eddi|zuHause> hm... placing industries destroys rivers
21:56:38 <Eddi|zuHause> they really shouldn't do that...
21:57:57 <Eddi|zuHause> frosch123: they seem to terraform regardless of river presence
21:58:11 <frosch123> on map creation, or also ingame?
22:00:35 <CIA-1> OpenTTD: glx * r18552 /trunk/src/lang/ (french.txt german.txt): -Fix (r18548): some translators were very fast
22:01:36 <Eddi|zuHause> frosch123: seems like only map creation, but not entirely certain
22:03:09 <Eddi|zuHause> frosch123: hm, no, could reproduce it ingame
22:03:16 <Eddi|zuHause> let me test the patch
22:03:21 *** Rubix`` has joined #openttd
22:04:14 <CIA-1> OpenTTD: rubidium * r18553 /trunk/src/aircraft_cmd.cpp: -Fix: make aircraft behave the same on autoreplace/autorenew as other vehicles
22:08:02 <frosch123> hmm, but do towns also clear rivers when expanding?
22:08:22 <Rubidium> clear as in destroy or as in bridge?
22:08:43 <peter1138> they bridge in fact
22:09:24 <Rubidium> peter1138: but only if you can FS#3369 as a bug and not an user error
22:09:27 <frosch123> ah yes, it also uses DC_WATER, and also DC_AUTO
22:10:54 <frosch123> hmm, i guess that scares users away, when they try to find the not-osx section
22:11:38 <peter1138> heh, nice bug in ogfx's rivers
22:11:49 <Eddi|zuHause> frosch123: i have seen towns build bridges, but never destroy river
22:13:12 <frosch123> hmm, does the industry terraforming also clear roads and houses?
22:13:42 <frosch123> ah, DC_AUTO is added by the terraform command itself
22:14:03 <peter1138> half-tile rivers are annoying me now
22:14:32 <frosch123> Eddi|zuHause: any success on testing?
22:15:46 <Eddi|zuHause> frosch123: well, let's say i haven't been able to reproduce the situation
22:17:14 <CIA-1> OpenTTD: frosch * r18554 /trunk/src/industry_cmd.cpp: -Change: Forbid industries to clear sea/river when leveling land.
22:18:32 *** Chruker has joined #openttd
22:19:06 <Eddi|zuHause> peter1138: if both the top half and the adjacent lower half are water, they should form a waterfall
22:20:46 <peter1138> starting to wonder about half-tiles on flat land too
22:21:04 <frosch123> and next to rail :p
22:21:09 <peter1138> but then someone is bound to want that for canals too
22:21:29 <Eddi|zuHause> well, i was going to say that, too ;)
22:22:34 <Eddi|zuHause> but i'm getting nowhere with this terraforming thing...
22:24:13 <Eddi|zuHause> and i get lots of errors "ALSA lib pcm.c:7234:(snd_pcm_recover) underrun occured"
22:24:58 <SmatZ> Eddi|zuHause: so do I - but I think it's caused by some alsa update. I get those warnings when I downgrade to older OTTD version as well.
22:25:39 <frosch123> some emerge printed a note about giving some task higher priority to avoid sound underrun
22:30:30 <frosch123> hmm, cannot find that one
22:36:39 <Eddi|zuHause> i need some threshold on floding when finding a sink... now they stop way too easily on flat areas
22:38:53 <frosch123> maybe do it when the heights are not yet scaled down to 0-15
22:39:37 <Eddi|zuHause> but there are still sinks
22:39:57 <frosch123> do you start in the mountains or at the sea?
22:40:49 <Eddi|zuHause> i start at a random tile, and follow the direction that is "downwards" until i hit 0 or a river tile
22:40:53 <frosch123> maybe start at the sea and try to reach some reasonable height
22:41:20 <planetmaker> I found that proposal to work better for me ^
22:41:42 <planetmaker> but it has it's problems, too :-)
22:41:53 <frosch123> or alternatively create a big lake and start searching from there
22:43:52 <Eddi|zuHause> well, finding the direction that is "down" isn't the problem, the problem is that there are places which are a local minimum
22:44:12 <planetmaker> Eddi|zuHause: yes. And you solve that, if you go up
22:44:38 <frosch123> or you have to create a lake there :)
22:44:44 <Eddi|zuHause> www.informatik.uni-halle.de/~krause/tgp_rivers1.diff <-- see for yourself (WARNING! do not use with a rivers grf)
22:45:37 <Eddi|zuHause> err... something isn't right
22:45:59 <Eddi|zuHause> contains reversal of peter's recent patch...
22:47:32 <Eddi|zuHause> i guess i'm still not familiar with how hg works
22:48:30 *** rhaeder has joined #openttd
22:48:43 <planetmaker> with X and Y being two revisions you want to compare
22:51:19 <Eddi|zuHause> planetmaker: i'm not sure, something went wrong when updating, i think
22:52:04 <planetmaker> hm... usually there shouldn't, if you don't modify the same place
22:52:15 <sparrL> is it possible to force load a different graphics-only GRF than other players are using in a multiplayer game?
22:52:51 <planetmaker> sparrL: you can use static newgrfs. Only from within config file, though
22:53:50 <frosch123> but note, that not everything is "graphics-only" what you might guess :)
22:54:30 <Eddi|zuHause> should be better now...
22:54:58 <Eddi|zuHause> so reload above link
22:55:40 <planetmaker> very little actually
22:56:17 <Eddi|zuHause> typically trees and catenary
22:56:27 <Eddi|zuHause> some rare cases of bridges
22:56:43 <Eddi|zuHause> and road/rail sets
22:57:26 <Eddi|zuHause> and possibly the HQ ;)
23:05:23 <Eddi|zuHause> hm... to flood properly, i probably need a recursive approach, not an iterative one
23:06:54 <planetmaker> don't forget an ending condition ;-)
23:08:24 <Eddi|zuHause> flooding should be BFS
23:08:39 <Eddi|zuHause> so i need a FIFO list
23:08:49 <peter1138> if (whole_map_is_flooded) end;
23:09:49 <Eddi|zuHause> and it might be useful to decide whether to flood or dig a canyon
23:10:22 <Eddi|zuHause> but i have no idea how to achieve sensible canyons
23:13:34 <_ln> why does the font change into a silly one f i choose Finnish or French or something?
23:14:24 <_ln> but e.g. with English, Danish and Estonian the font is non-silly
23:14:30 <Eddi|zuHause> _ln: because you did not update to a recent nightly
23:14:57 <peter1138> heh, trees slowly appear in the scenario editor
23:15:00 <peter1138> are they supposed to?
23:15:19 <Eddi|zuHause> yes, that's been a complaint for years
23:15:31 <Eddi|zuHause> but there's a setting to disable that now, i believe
23:16:01 <frosch123> maybe enforce that setting in SE
23:16:01 <_ln> doesn't sound like a feature that needs a setting
23:16:03 <Zuu> peter1138: I think you can pause in the scenario editor, so I guess it is not too unlogical.
23:16:20 <peter1138> but then guess what
23:16:24 <peter1138> you can't build anything :p
23:17:01 <Zuu> You can build stones and light houses plus some more. :-)
23:17:18 <Zuu> Or, you mean, while paused. Ah sory. :-)
23:17:41 <Zuu> Isn't build on pause cheat available in the scenario editor?
23:18:28 <Zuu> Or maybe you can't cheat in the scenario editor.
23:19:11 <Eddi|zuHause> SmatZ/frosch123: somebody suggested that the buffer underrun message might be related to pulseaudio
23:20:26 <Eddi|zuHause> Zuu: in scenario editor, there's supposed to be no cheating necessary
23:35:45 <SmatZ> Eddi|zuHause: I am not using pulseaudio
23:46:39 <CIA-1> OpenTTD: smatz * r18555 /trunk/ (5 files in 4 dirs): -Fix (r15027): fake definitions of squirrel types were wrong for eg. 64bit systems, don't use them
23:48:54 <CIA-1> OpenTTD: smatz * r18556 /trunk/src/ai/api/squirrel_export.awk: -Fix (r17005): squirrel export didn't accept negative constants
23:51:53 *** weaselboy246 has joined #openttd
23:53:26 <CIA-1> OpenTTD: smatz * r18557 /trunk/src/ai/ (9 files in 2 dirs): -Fix: (most of) gcc errors when using lto caused by some structs having different definition in different object files
continue to next day ⏵
