IRC logs for #openttd on OFTC at 2013-06-28
⏴ go to previous day
00:33:36 *** HerzogDeXtEr1 has joined #openttd
00:49:44 *** roboboy has joined #openttd
01:22:35 *** Eddi|zuHause has joined #openttd
02:06:10 *** DarkAce-Z is now known as DarkAceZ
03:12:05 *** Diablo-D3 has joined #openttd
03:13:10 *** Diablo-D3 has left #openttd
03:40:01 *** Belugas has joined #openttd
03:40:01 *** ChanServ sets mode: +o Belugas
03:49:15 *** Belugas has joined #openttd
03:49:15 *** ChanServ sets mode: +o Belugas
04:02:50 *** DorpsGek` has joined #openttd
04:02:50 *** ChanServ sets mode: +o DorpsGek`
04:03:28 *** TinoDid|znc has joined #openttd
04:04:23 *** __20h___ has joined #openttd
04:04:29 *** DorpsGek is now known as Guest1367
04:04:29 *** DorpsGek` is now known as DorpsGek
04:04:29 *** Guest1367 is now known as Guest1371
04:04:41 *** peter1139 has joined #openttd
04:04:50 *** joho^_^ has joined #openttd
04:05:42 *** TinoDid|znc is now known as TinoDidriksen
04:09:13 *** Belugas has joined #openttd
04:09:13 *** ChanServ sets mode: +o Belugas
04:20:23 *** roboboy has joined #openttd
04:56:17 *** Eddi|zuHause has joined #openttd
06:40:17 *** Devroush has joined #openttd
06:59:27 *** sla_ro|master has joined #openttd
07:12:36 *** roboboy has joined #openttd
07:17:02 *** Alberth has joined #openttd
07:17:02 *** ChanServ sets mode: +o Alberth
07:21:54 <Alberth> can someone please stop ordering bad rainy weather? It's supposed to be summer sunny :(
07:35:17 <peter1139> It's a British summer :D
07:46:42 <__ln__> why did the britons choose to live on an island with such a bad weather in the first place?
07:57:09 <szaman> as a Pole, i think, it's because it is safe there, you don't have armies running west->east nad east->west all the time :]
08:00:22 <szaman> one way or another, it's raining in Poland for 6 days now :P
09:19:52 *** oskari89 has joined #openttd
09:23:55 *** HerzogDeXtEr has joined #openttd
09:39:55 <roboboy> we have lots of rain here down under, but it is Winter
10:23:38 *** Ristovski has joined #openttd
10:27:40 *** Devroush367 has joined #openttd
11:18:44 *** TheMask96 has joined #openttd
11:19:02 *** roboboy has joined #openttd
11:30:28 *** Prof_Frink has joined #openttd
11:30:57 *** sla_ro|master has joined #openttd
12:49:10 *** roboboy has joined #openttd
13:03:26 * NGC3982 has bought a new suit.
13:17:14 *** TomyLobo has joined #openttd
13:24:03 <Alberth> NGC3982: tip: also buy furniture at the same day, the suit then doesn't look very expensive :p
13:24:19 <Alberth> found a nice train set btw?
13:26:03 <planetmaker> try something completely different. Try george's xussr set as found on the devzone
13:29:08 <planetmaker> also hello everyone :-)
13:42:20 <Eddi|zuHause> hello, everyplanet and everyelement
13:44:22 <NGC3982> Alberth: Yes, indeed. I had totally missed out on the Dutch trainset.
13:45:03 <NGC3982> Alberth: Although, i (funny enough, right this moment) realized that the server has crasched due to NewGRF problems with the Dutch trainset
13:45:10 <NGC3982> And something about carts being too long.
13:45:48 <Eddi|zuHause> that only happens when you mess with newgrfs after game start (or when there's a serious bug)
13:46:48 <NGC3982> The only thing changed mid-play was station_spread and max_train_length
13:47:07 <NGC3982> Though, the problem did not occur while changing any of those parameters, but over night.
13:48:15 <NGC3982> Luckily, it's a game save used on a dedicated server. I'll try to restart (and replicate) the problem.
13:48:17 <planetmaker> then... you should report it :-)
13:49:17 <NGC3982> There is nothing to report until i replicate it, i guess.
13:49:43 <NGC3982> Since, i'm now also noticing i can't access any of my servers.
13:50:31 <planetmaker> if it crashed, you have all info you need on the server: crash.log, crash.sav
13:51:08 <planetmaker> and possibly an autosave which is from somewhen before that. Sometimes it comes in handy, sometimes it#s not needed
14:10:37 <Eddi|zuHause> on the title savegame?
14:10:48 <NGC3982> No, on joining the server, playing the savegame.
14:11:07 <NGC3982> Though, this is not about the game itself, but all of my current OpenTTD servers
14:11:13 <NGC3982> I can't join any of them
14:11:34 <Eddi|zuHause> again, you know where to put the savegames
14:12:06 <NGC3982> Derp. This is so broken.
14:12:18 <NGC3982> The Ubuntu server's got an average load of >9.
14:12:34 <NGC3982> And no process running past ten percent.
14:12:39 <NGC3982> Hardware, oh hardware.
14:18:08 <planetmaker> what does the message say, NGC3982 ?
14:19:27 <Eddi|zuHause> the train "blah" has wrong length. obviously :)
14:19:56 <planetmaker> sure? Only last sentence I can decode to roughly "problem found with newgrf and game may desync or crash"...
14:20:14 <NGC3982> I'm sorry PM, i'll come back to that. I'm having hardware issues.
14:20:47 <Eddi|zuHause> ogiltig = ungültig
14:22:22 <Eddi|zuHause> and if in doubt, grep through the language file to find the string id :p
14:30:15 <NGC3982> God. The CPU fan b0rked.
14:34:37 <Eddi|zuHause> that probably causes all sorts of problema, but this one is really unlikely :p
14:43:23 <NGC3982> I can't seem to find the installer for OpenTTD 1.3.0
14:58:26 <NGC3982> Client #3 is dropped because it took longer than 1000 ticks to join
14:58:27 <NGC3982> dbg: [net] '8293CGN' made an error and has been disconnected. Reason: 'processing map took too long'
14:58:45 <NGC3982> I still get that, after updating the server and the client to 1.3.1, trying to join a UKRS2+FIRS game.
14:58:56 <NGC3982> Let's try this on another computer.
15:00:27 <Eddi|zuHause> try to pause the game?
15:01:39 <Eddi|zuHause> the client has to catch up the calculation for all ticks that passed during downloading the map. if the game is too busy this may take a long time
15:02:14 <NGC3982> Sure, but that will not fix my initial problem. Something is preventing me from joining a game that i've had no problem with before.
15:04:08 <NGC3982> And, it worked out on the second laptop next to this one. Thus, something on this laptop prevents me from joining.
15:28:37 <NGC3982> That's odd. Reinstalling it completely did not help.
15:32:20 *** ntoskrnl has joined #openttd
15:41:13 <Alberth> it's scary enough that it appears to solve something at times, imho
15:48:35 <planetmaker> breaks as in: graphics are not found any longer and most action0 properties are set to 0 in the purchase list
15:50:32 *** DarkAceZ has joined #openttd
16:03:35 *** sla_ro|master has joined #openttd
16:08:15 *** TheMask96 has joined #openttd
16:26:38 *** Kurimus has joined #openttd
16:40:52 <Rubidium> planetmaker: I can spell it, does that count? ;)
16:50:16 <planetmaker> I fear it needs understanding of what it exacly does... but as far as I got so far it simply tries to access - as told - some variables of the parent scope - which totally messes up things. And I'm not yet convinced that the code is wrong. Nor actually correct... devil's in the detail there, I guess with those adv. varaction2s
17:08:37 <Mazur> Hm, why is PublicServer not responding?...
17:12:49 <Mazur> Ah yes, Stablean responds to me, so I exist.
17:18:33 *** gelignite has joined #openttd
17:38:24 *** Progman has joined #openttd
17:45:24 <DorpsGek> Commit by translators :: r25494 /trunk/src/lang (3 files) (2013-06-28 17:45:19 UTC)
17:45:25 <DorpsGek> -Update from WebTranslator v3.0:
17:45:26 <DorpsGek> catalan - 7 changes by juanjo
17:45:27 <DorpsGek> spanish - 5 changes by juanjo
17:45:28 <DorpsGek> vietnamese - 9 changes by nglekhoi
17:45:32 *** frosch123 has joined #openttd
17:45:48 <planetmaker> hullo Wolf01 & quak ;-)
17:47:51 <planetmaker> I believe yes, but... it needs someone who speaks NFO more fluently than myself
17:48:31 <Wolf01> sorry about yesterday evening, I was in the middle of a online game, for the meeting instead I think I won't be able to participate
17:49:47 <planetmaker> the broken one is broken as in that purchase sprites and stats are zeroed
17:52:04 <planetmaker> the difference basically is a pointless access of two variables of the related object. That breaks it
17:53:11 <Jogio> planetmaker, can I click on "mark"in the webtranslator when I think a translation is improveable?
17:55:12 <Jogio> ok, it's maybe better because some translations bother me, but I don't nothing better :-)
17:56:11 <Jogio> and the field to edit is to small
18:01:28 <Rubidium> wasn't there a meeting about a new translator tool in the near future?
18:02:34 <planetmaker> yeah, that meeting... :D It has a tight schedule. Translator tools, admin port tools, cakes, bbq...
18:02:43 <frosch123> planetmaker: i assume it fails in the purchase list?
18:03:40 <frosch123> it accesses the speed variable
18:03:47 <frosch123> which is unavailable in the purchase list
18:03:55 <frosch123> accessing unavailable variables is an error
18:04:10 <frosch123> which is defined to chain to the first case no matter what
18:04:19 <frosch123> so it chains to the dummy range
18:04:23 <planetmaker> it accesses invalid variables, yes... but should that reset *all* properties for the purchase list?
18:04:47 <frosch123> cb36 has no flag, and all cb chains run into that case
18:05:00 <frosch123> and that chani does not end with a cb failure, but with a cb result 0
18:05:20 <planetmaker> so... default should be CB_FAILURE?
18:05:29 <frosch123> and all vehicle resolving fails
18:06:19 <frosch123> i would give the dummy case the same value as the default case
18:06:32 <frosch123> whatever you write there, it is wrong
18:06:45 <frosch123> either it fails for sprite resolving or for callbacks
18:09:10 <DorpsGek> Commit by rubidium :: r25495 trunk/src/station_cmd.cpp (2013-06-28 18:09:07 UTC)
18:09:11 <DorpsGek> -Fix [FS#5553]: when addings bits to a (train) station, the train trying to stop there could overshoot the (new) stop location and not stop at all
18:10:33 <Wolf01> and if the station was a terminus one?
18:11:15 <planetmaker> it obviously could not overshoot or not stop :-)
18:12:04 <frosch123> yeah, train drivers get very confused if you change their platform while they enter
18:12:23 <frosch123> they are also worried if they stand at a red signal, and then someone removes it
18:13:09 <Jogio> ".... , da Banken kein Gold an Goldminen oder Diamanten und Diamantenminen schicken. Im gemäßigten Klima kann auch "symmetrisch" gewählt werden, da Banken sich gegenseitig Wertsachen schicken."
18:13:43 <Jogio> I think "schicken" is not good
18:14:15 <planetmaker> the "und" between "Diamanten" and "Diamantenminen" is wrong
18:15:10 <Jogio> technically they just produce it
18:15:25 <planetmaker> technically we only play the delivery service
18:15:27 <Jogio> you have to transport it
18:17:55 <Jogio> ".... ,da Banken kein Gold an Goldminen oder Diamanten an Diamantenminen liefern. Im gemäßigten Klima kann auch "symmetrisch" gewählt werden, da Banken sich gegenseitig Wertsachen zusenden."
18:21:00 <Jogio> there was 4 times "schicken in the whole string xD
18:24:18 <Rubidium> frosch123: just use block signals, then they're not worried. They just start driving ;)
18:26:26 <planetmaker> frosch123, thanks for that analysis :-)
18:30:57 *** Pensacola has joined #openttd
18:40:57 *** andythenorth has joined #openttd
18:42:37 <andythenorth> forums are quiet
18:42:40 <andythenorth> someone post something :P
18:43:53 <frosch123> make a post in the (25+4)k topic, that you are attending or so
18:44:22 <frosch123> or that you send a cake via mail :p
18:46:34 <andythenorth> if I remember :P
19:02:27 <frosch123> planetmaker: is it actually a nml bug? i mean nml cannot do much about accessing invalid variables, so the code is wrong anyway
19:02:51 <frosch123> it's just the fastest way to make it obvious that there is a problem
19:03:06 <planetmaker> frosch123, yes. no. maybe :-)
19:03:30 <frosch123> the va2 evaluationis aborted on error
19:03:42 <frosch123> so the service date is not stored either for example
19:03:58 <planetmaker> the callbacks define there don't look worrysome. But it works, if you remove all but the two graphics ones
19:04:07 <frosch123> i always believed the "choose range 0 on error" was only some way to make it obvious that it is wrong
19:04:34 <planetmaker> possibly that was the thinking behind it. Not sure. But it makes sense
19:04:41 <planetmaker> now that you mention it :-)
19:05:40 <frosch123> so, should ottd print a more visible error message?
19:06:37 <planetmaker> not sure that it would solve the problem completely. If you look at the code I linked: if you keep the first 3 callbacks (default, purchase and articulated_part). Would you assume that it zeros all properties in purchase view?
19:08:59 <frosch123> well, but it made it very obvious that there is something wrong
19:09:26 <frosch123> and if ottd would blame the grf for accessing invalid stuff, it would be easier to see
19:09:54 <DorpsGek> TrueBrain: Commit by rubidium :: r25496 /branches/1.3 (9 files in 2 dirs) (2013-06-28 19:09:47 UTC)
19:09:55 <DorpsGek> TrueBrain: [1.3] -Backport from trunk:
19:09:56 <DorpsGek> TrueBrain: - Fix: When town creation failed, removing remnants of the construction failed on protected houses [FS#5603] (r25429)
19:09:57 <DorpsGek> TrueBrain: - Fix: There were two hotkeys to toggle between 'unload' and 'unload if possible' (r25406)
19:09:58 <DorpsGek> TrueBrain: - Fix: The size of station construction windows could oscillate when resizing the window moved the mouse into the window [FS#5596] (r25395)
19:10:16 <planetmaker> yes, that's true, frosch123
19:19:04 *** Eddi|zuHause has joined #openttd
19:20:47 <DorpsGek> Commit by frosch :: r25497 trunk/src/economy.cpp (2013-06-28 19:20:45 UTC)
19:20:48 <DorpsGek> -Fix (r25479): byte is not unit
19:21:17 <frosch123> yay, 97 fixing 79 :)
19:21:30 <DorpsGek> Commit by rubidium :: r25498 /branches/1.3 (5 files in 3 dirs) (2013-06-28 19:21:24 UTC)
19:21:31 <DorpsGek> [1.3] -Backport from trunk:
19:21:32 <DorpsGek> - Fix: [NewGRF] When cargo NewGRF define a multiplier to modify vehicle capacities, use the same multiplier to modify loading speed (r25497, r25479)
19:21:33 <DorpsGek> - Fix: [OSX] OS X SDK versions >= 10.5 always have a non-const iconv declaration (r25480)
19:21:34 <DorpsGek> - Fix: Disable the depot-refit button in the order GUI, if the consist is not refittable unless it already has a refit order (r25459, r25458, r25457)
19:24:03 * andythenorth tries an OS X compile
19:24:10 <andythenorth> what was breaking anyway?
19:24:14 <Rubidium> too bad of the trailing space in my commit, otherwise I could've backported that even sooner ;)
19:24:46 <DorpsGek> Commit by rubidium :: r25499 /branches/1.3 (11 files in 3 dirs) (2013-06-28 19:24:39 UTC)
19:24:47 <DorpsGek> [1.3] -Backport from trunk:
19:24:48 <DorpsGek> - Fix: Do not send encoded texts to names, but decode them into a plain C string and then pass them on [FS#5613] (r25489, r25488)
19:24:49 <DorpsGek> - Fix: Do not allow control codes in names of things (signs, vehicles, towns, stations, etc), so they have a known maximum fixed size and are, by definition, the same for everyone (r25487)
19:24:50 <DorpsGek> - Fix: Missing length validation for town and president names in script APIs (r25486)
19:26:38 <Eddi|zuHause> "Following the ancient religious principle of alms for the poor, the Church of England is reportedly to back a £1bn investment in more than 300 branches of the Royal Bank of Scotland."
19:28:25 <andythenorth> fontcache error on compile :)
19:28:40 <andythenorth> openttd/src/fontcache.cpp:194: error: ‘>>’ should be ‘> >’ within a nested template argument list
19:28:59 <andythenorth> didn't run configure first
19:29:17 <DorpsGek> Commit by rubidium :: r25500 /branches/1.3 (16 files in 4 dirs) (2013-06-28 19:29:08 UTC)
19:29:18 <DorpsGek> [1.3] -Backport from trunk:
19:29:19 <DorpsGek> - Remove: SETX(Y) does not work at all with other than default fonts, so get rid of it (r25454)
19:29:20 <DorpsGek> - Fix: When addings bits to a (train) station, the train trying to stop there could overshoot the (new) stop location and not stop at all [FS#5553] (r25495)
19:29:21 <DorpsGek> - Fix: The face of the manager differed on clients when the company was started after the clients joined [FS#5610] (r25491, r25490)
19:31:37 <DorpsGek> Commit by rubidium :: r25501 trunk/src/fontcache.cpp (2013-06-28 19:31:31 UTC)
19:31:38 <DorpsGek> -Fix: compilation error on OS X
19:31:48 <Rubidium> andythenorth: and you didn't update to current HEAD yet ;)
19:31:54 *** Biolunar has joined #openttd
19:40:21 <NGC3982> For some reason, i can't get my laptop to connect to my server.
19:40:35 <NGC3982> It works fine on anything other computer.
19:40:56 <NGC3982> Is there a setting on how much time a client is allowed before disconnecting?
19:41:02 <NGC3982> Whilst loading a map, that is.
19:44:35 <DorpsGek> Commit by rubidium :: r25502 /branches/1.3 (25 files in 6 dirs) (2013-06-28 19:44:28 UTC)
19:44:36 <DorpsGek> [1.3] -Backport from trunk:
19:44:37 <DorpsGek> - Fix: Proper support for Brahmic scripts (e.g. Tamil and Thai) [FS#5481] (r25501, r25493, r25485, r25483, r25482, r25481, r25478, r25477, r25476, r25474, r25473, r25472, r25471, r25470, r25469, r25468, r25467, r25466, r25465, r25463, r25462, r25455, r25452, r25451, r25450, r25447, r25446, r25445, r25444, r25443, r25442, r25441, r25440, r25439, r25438, r25437, r25436, r25343, r25157)
19:48:16 <DorpsGek> Commit by rubidium :: r25503 /branches/1.3 (20 files in 2 dirs) (2013-06-28 19:48:10 UTC)
19:48:17 <DorpsGek> [1.3] -Backport from trunk: language updates
19:52:20 *** ntoskrnl11 has joined #openttd
19:52:47 <andythenorth> openttd/src/video/cocoa/cocoa_v.mm:477: warning: format not a string literal and no format arguments
20:04:43 <NGC3982> It worked itself out by increasing max_join_time
20:04:56 <NGC3982> Although, the issue remains worked around, but not fixed.
20:05:59 <andythenorth> probably I don't understand bounding boxes :P
20:12:54 <andythenorth> faster FIRS compiles ftw
20:12:58 <andythenorth> this is way more productive :P
20:16:35 <andythenorth> these farmhouses are all a bit same-same eh?
20:22:34 <Alberth> I never quite understood why firs has all these different farms, but they bring different cargoes afaik
20:22:52 <andythenorth> I considered making them all one kind more or less, with random
20:23:00 <andythenorth> (for the cargos)
20:23:02 <andythenorth> which might have been fine
20:23:05 <andythenorth> but I didn't go that route
20:23:15 <Alberth> I was thinking that just now too :)
20:23:35 <Alberth> (that alternative, that is :) )
20:23:49 <andythenorth> I think random cargo is annoying
20:24:26 <andythenorth> Alberth: you playing a FIRS game currently?
20:24:44 <Alberth> yeah, it's nice to be able to know what to expect when seeing the graphics
20:25:19 <Alberth> currently not, I am experimenting with cdist and cargoes, that doesn't really need the complexity of FIRS yet :)
20:26:04 <Alberth> I am starting to get to understand how to handle a single cargo :p
20:26:11 <andythenorth> I should play a game
20:26:40 <andythenorth> trying to teach child #1 that
20:27:20 <Alberth> you need to play optimal then, otherwise you loose :)
20:29:42 <andythenorth> graphics for Coffee Estate
20:29:53 <andythenorth> I hope the base set has some bushes and stuff
20:31:11 <andythenorth> think there will be some
20:31:25 <andythenorth> dunno what they look like in ogfx though
20:47:41 <Alberth> it looks like a wrong solution to the problem :p
20:53:47 <DorpsGek> Commit by rubidium :: r25504 trunk/Doxyfile (2013-06-28 20:53:42 UTC)
20:53:48 <DorpsGek> -Feature [FS#5563]: allow images in the (doxygen) documentation (adf88)
20:54:11 <DorpsGek> Commit by rubidium :: r25505 trunk/src/elrail.cpp (2013-06-28 20:54:05 UTC)
20:54:12 <DorpsGek> -Fix [FS#5563]: use proper doxygen style link to images
20:59:45 <Eddi|zuHause> i think it's an elegant solution (although i have not looked at the implementation)
21:00:09 <Eddi|zuHause> you reuse the concept of the conditional orders, so you need no new GUI elements
21:03:25 <andythenorth> it's quite a programmatic way of thinking
21:03:34 <andythenorth> elegant, but possibly unintuitive ;)
21:06:44 * Rubidium wonders how "bad" it is, if you change the text to "stay as long as <xyz>". Though yes, it might make things nasty-ish
21:08:28 <andythenorth> changing the text makes it better
21:08:43 <Eddi|zuHause> well, any other solution would involve using the "load" options dropdown, and then the GUI gets more complicated than the feature
21:08:47 <andythenorth> indent the line :P
21:09:05 <andythenorth> so it's subsidiary to the 'goto station'
21:09:27 <Eddi|zuHause> that means, the feature must be delayed until a complete timetable GUI redesign
21:10:07 <andythenorth> so change the text
21:10:18 <andythenorth> worse is good enough :)
21:10:40 <andythenorth> :o Full FIRS economy has an insane number of industries :o
21:10:52 * andythenorth has been looking at smaller economies
21:11:05 <andythenorth> must be pretty overwhelming the first time you see FIRS minimap :P
21:11:41 <DorpsGek> Commit by rubidium :: r25506 /trunk/src (5 files in 4 dirs) (2013-06-28 21:11:35 UTC)
21:11:42 <DorpsGek> -Document: a function, and name it slightly better
21:22:19 *** Progman has joined #openttd
21:43:33 <andythenorth> I ran out of things I want to code tonight :)
21:44:46 <Rubidium> so continue with the stuff you want to code tomorrow
21:45:06 <andythenorth> no coding allowed at weekends :(
21:47:51 <Eddi|zuHause> even better, then you can go straight to monday :p
23:43:04 *** tokai|mdlx has joined #openttd
continue to next day ⏵
