Times are UTC Toggle Colours
00:32:23 *** Ristovski has quit IRC 06:14:30 *** DorpsGek changes topic to "OpenTTD Dev Channel || Latest SVN: r25593 || Logs: http://webster.openttdcoop.org/?channel=openttd.dev || Voice (talk-right) upon request via #openttd; make sure you are registered to NickServ before asking" 06:28:36 *** frosch123 has joined #openttd.dev 06:28:36 *** ChanServ sets mode: +v frosch123 06:35:08 *** DorpsGek changes topic to "OpenTTD Dev Channel || Latest SVN: r25594 || Logs: http://webster.openttdcoop.org/?channel=openttd.dev || Voice (talk-right) upon request via #openttd; make sure you are registered to NickServ before asking" 06:40:36 *** DorpsGek changes topic to "OpenTTD Dev Channel || Latest SVN: r25595 || Logs: http://webster.openttdcoop.org/?channel=openttd.dev || Voice (talk-right) upon request via #openttd; make sure you are registered to NickServ before asking" 07:48:25 <Rubidium> frosch123: any success/extra info with the content download thing? 07:48:39 <frosch123> hmm, might try that again 07:55:01 <frosch123> tcpdump output suggests it's totally a client problem 07:55:15 <frosch123> ottd just does not send out a packet anymore 07:56:16 <frosch123> hmm, or actually, it sends a packet and never gets a response 07:56:21 <frosch123> then it stops sending the next or so 07:56:40 <frosch123> i guess i need to increase the verbosity 08:05:02 <frosch123> haha, caught my rss feed reader updating 08:05:24 <frosch123> looked scary when suddenly some html appeared between the content stuff 08:10:29 <frosch123> http://paste.openttdcoop.org/show/2389/ <- those are the last packets, before it stops 08:11:04 <frosch123> [R] seems to mean that openttd.org resets the connection 08:11:10 <frosch123> and apparently out client cannot handle that 08:14:07 <frosch123> it stops in the middle of downloading the list 08:14:36 <Rubidium> do you have a slow-ish internet connection? 08:15:08 <frosch123> depends what you consider slow :p 08:15:31 <frosch123> i have 6mbit and a video stream running 08:15:42 <frosch123> so, yeah, there is other stuff on the line 08:16:03 <Rubidium> the server shouldn't close the connection when it's still sending stuff 08:16:31 <Rubidium> unless... it's all in the OS send queue at the server, but the server should only timeout after 2 minutes 08:16:50 <frosch123> it had no time to timeout, i was spamming it with requests 08:18:03 <Rubidium> and the master server stopped sending stuff? 08:18:09 <Rubidium> s/master/content/ 08:18:39 <frosch123> yes, it transferred half of the list, and then those [R] packets 08:19:04 <frosch123> then every communication stops, no matter what i do in ottd, until i quit it 08:19:24 <Rubidium> even UDP? 08:20:19 <frosch123> no, only content 08:20:25 <frosch123> server list still works 08:20:47 <frosch123> i mean the content client does not time out or similar 08:23:45 <Rubidium> how easy is it to reproduce? 08:24:20 <frosch123> easy, i position the inro gui so that the content button is in the same place as the close button in the content gui 08:24:35 <frosch123> and then click at random 3 second intervals 08:24:41 <frosch123> until it stops moving 08:25:20 <frosch123> oh, actually, transmisstion stops in the middle of a contentinfo 08:27:41 <frosch123> no, sorry, read stuff wrong 08:28:56 <Rubidium> and how many times do you need to click on average? 08:30:26 <frosch123> maybe 30 08:46:23 <Rubidium> frosch123: can you still reproduce it? 08:55:46 <frosch123> did you change something? 08:56:08 <Rubidium> yes 08:57:02 <Rubidium> also, next time just say "after 120 seconds from opening the connection to the content server" ;) 08:57:13 <Rubidium> much more reliable measurement 08:57:19 <frosch123> :p 08:57:56 <Rubidium> http://rbijker.net/openttd/msu.diff 08:57:57 <frosch123> looks reasonable 08:59:09 <frosch123> anyway, shouldn't the client recover somehow? 09:01:25 *** DorpsGek changes topic to "OpenTTD Dev Channel || Latest SVN: r25596 || Logs: http://webster.openttdcoop.org/?channel=openttd.dev || Voice (talk-right) upon request via #openttd; make sure you are registered to NickServ before asking" 09:01:54 <Rubidium> yep, but couldn't figure out where it trashes the client 09:03:57 <frosch123> ok, confirmed, cannot reproduce it 09:06:37 *** Ristovski has joined #openttd.dev 09:12:50 <Rubidium> http://rbijker.net/openttd/fs5635.diff 09:12:51 *** ntoskrnl has joined #openttd.dev 09:14:40 <Rubidium> r6400h will even be hard for RC2 ;) 09:15:49 <Rubidium> at least when I want a translator flush ;) 09:18:34 *** Alberth has joined #openttd.dev 09:18:34 *** ChanServ sets mode: +v Alberth 09:19:27 <Rubidium> planetmaker: did you document the corner case with content and rcon end? and update the rcon documentation for the new packets? 09:20:36 <planetmaker> ah, not yet 09:20:42 <planetmaker> forgot 09:22:25 *** DorpsGek changes topic to "OpenTTD Dev Channel || Latest SVN: r25597 || Logs: http://webster.openttdcoop.org/?channel=openttd.dev || Voice (talk-right) upon request via #openttd; make sure you are registered to NickServ before asking" 09:28:06 <planetmaker> http://devs.openttd.org/~planetmaker/patches/tmp.diff maybe, Rubidium ? 09:29:42 <Rubidium> almost... 09:30:08 <Rubidium> the RCON_END of the content stuff comes after the command is executed. Not after all output is generated 09:30:35 <Rubidium> so for at least update and download it comes before the interesting stuff 09:30:49 <planetmaker> hm... worse even :-) 09:30:59 <Rubidium> i.e. the "connection established" and "downloaded file X" 09:31:28 <Rubidium> and the "connection closed" will come even later (a minute or so after the last reply) 09:31:43 <Rubidium> although... they might not even go back to the rcon requester 09:31:52 <Rubidium> they probably go to the console altogether 09:35:48 <Rubidium> something that should probably be tested ;) 09:36:42 <planetmaker> http://devs.openttd.org/~planetmaker/patches/tmp.diff updated 09:37:11 <Rubidium> cron -> rcon 09:37:26 <planetmaker> oh :-) 09:55:23 *** DorpsGek changes topic to "OpenTTD Dev Channel || Latest SVN: r25598 || Logs: http://webster.openttdcoop.org/?channel=openttd.dev || Voice (talk-right) upon request via #openttd; make sure you are registered to NickServ before asking" 09:57:29 <Rubidium> http://rbijker.net/openttd/misc/backport.txt <- anything missing? 10:00:44 <planetmaker> lots of fixes 10:01:18 <planetmaker> not missing though :-) 10:03:57 <Rubidium> that Japanese translator is prolific 10:05:02 <planetmaker> he was very eager to get started :-) 10:05:20 <planetmaker> when not answered in 24h he sent another e-mail :D 10:06:07 <planetmaker> you could backport 25598, too 10:06:25 <planetmaker> and you did 10:07:43 <frosch123> 25574 and 25573 are sorted incorrectly 10:09:15 <frosch123> looks complete 10:10:09 *** DorpsGek changes topic to "OpenTTD Dev Channel || Latest SVN: r25599 || Logs: http://webster.openttdcoop.org/?channel=openttd.dev || Voice (talk-right) upon request via #openttd; make sure you are registered to NickServ before asking" 10:12:13 <Rubidium> if the translators keep working, then we need to do one trunk commit per day to reach r6420h 10:12:53 <Rubidium> (assuming no backport for 1.3.2) 10:13:20 <frosch123> hmm, did we just miss the chance to turn r25ki into rc2? 10:15:01 <Rubidium> yes ;) 10:15:24 <Rubidium> well... could still do it, but it's going to be a massive break of common sense 10:15:45 <frosch123> yeah, translations backport and tag in one commit :p 10:16:00 <frosch123> oh, and wt3 commit 10:17:03 <Rubidium> and doc update 10:17:38 <Rubidium> so rather not ;) 10:24:45 *** DorpsGek changes topic to "OpenTTD Dev Channel || Latest SVN: r25600 || Logs: http://webster.openttdcoop.org/?channel=openttd.dev || Voice (talk-right) upon request via #openttd; make sure you are registered to NickServ before asking" 10:33:30 *** DorpsGek changes topic to "OpenTTD Dev Channel || Latest SVN: r25601 || Logs: http://webster.openttdcoop.org/?channel=openttd.dev || Voice (talk-right) upon request via #openttd; make sure you are registered to NickServ before asking" 10:36:11 *** DorpsGek changes topic to "OpenTTD Dev Channel || Latest SVN: r25602 || Logs: http://webster.openttdcoop.org/?channel=openttd.dev || Voice (talk-right) upon request via #openttd; make sure you are registered to NickServ before asking" 10:42:05 *** DorpsGek changes topic to "OpenTTD Dev Channel || Latest SVN: r25603 || Logs: http://webster.openttdcoop.org/?channel=openttd.dev || Voice (talk-right) upon request via #openttd; make sure you are registered to NickServ before asking" 11:27:20 *** Supercheese has quit IRC 11:27:52 *** Supercheese has joined #openttd.dev 13:52:15 <Rubidium> http://rbijker.net/openttd/fs5550.diff <- frosch123: is that a better version of planetmaker's version (from the bug tracker)? 13:56:03 <frosch123> looks fine to me 13:56:24 <frosch123> i did not know HasEngineType 13:56:41 <frosch123> i wonder how much code i wrote in the past years can be simplified with it :p 14:07:35 <Rubidium> is that ~15 commits worth of simplifications? 14:08:28 *** DorpsGek changes topic to "OpenTTD Dev Channel || Latest SVN: r25604 || 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:08:54 <frosch123> unlikely 14:27:18 <frosch123> oh, hm... hgsubversion does not export svn:external 14:37:56 <Rubidium> http://rbijker.net/openttd/fs5641.diff <- is that good enough of a bug report? 14:38:06 <Rubidium> s/report/fix/ 14:39:44 <frosch123> what about the 15 thingie? 14:40:02 <Rubidium> 88 B Station size in form NL; N=number of platforms, L=length 14:40:11 <frosch123> so, build default if bigger? 14:40:26 <Rubidium> it can build bigger yes... 14:40:40 <Rubidium> but... I doubt many will need that ;) 14:40:58 <frosch123> well, i wonder whether that function should fail at all 14:41:08 <frosch123> or whether it should always build default station instead 14:41:43 <frosch123> giving the ai ERR_UNKNOWN and telling them to call the non-newgrf function in that case sounds weird 14:42:30 <frosch123> shouldn't it just build default station in all cases when newgrf fail for this or that? 14:43:18 <Rubidium> was toying with that idea as well ;) 14:46:23 <Rubidium> http://rbijker.net/openttd/fs5641v2.diff <- not quite sure it works right though... 14:49:57 <Rubidium> after all, DoCommand does odd things 14:52:55 <frosch123> tunnel construction does quite different things to build the connecting roads for tunnels 14:53:30 <frosch123> i am not exactly sure how the suspension and resume works for ais 14:54:23 <frosch123> ah, you do the normal station if the test-run fails, right? 14:56:33 <frosch123> looks fine to me 14:56:47 <Rubidium> it seems to work ;) 14:57:17 <Rubidium> so the first test run fails, and thus it works as no suspension started yet 14:59:55 *** DorpsGek changes topic to "OpenTTD Dev Channel || Latest SVN: r25605 || 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:50:36 <planetmaker> http://devs.openttd.org/~planetmaker/patches/tmp.diff makes sense I think 16:50:48 <planetmaker> Older versions don't support grf v8 anyway and will already barf on that 16:59:44 <frosch123> well, they won't exactly barf 17:00:08 <frosch123> we only check the grfversion since one year before adding grfv8 or so 17:00:59 <frosch123> 0.7 will happily accept a grfv8 grf, no idea what it does with it though 17:01:33 <frosch123> but ok, the version requirement in the action b might be nonsense :) 17:02:22 <frosch123> i guess you can remove that check, if you enable container 2 in Makefile.grf.in 17:07:33 <planetmaker> right. So, containter v2 then? 17:09:22 <planetmaker> (diff updated) 17:12:11 <frosch123> should it check var 1d= 17:12:13 <frosch123> ? 17:12:37 <frosch123> or do we not care? 17:13:00 <planetmaker> grf v8 and ttdpatch? :-) 17:13:26 <planetmaker> I leave those checks out usually for container v2. It implies openttd in my eyes 17:13:49 <planetmaker> I could amend the comment by that, if you like? 17:15:49 <planetmaker> like the updated diff :D 17:16:30 <frosch123> looks fine to me 17:18:52 <planetmaker> cleanup or change? :D 17:19:28 <Rubidium> what's the reason for this? 17:19:46 <planetmaker> a few - in the nfo? 17:20:06 <Rubidium> and a bigger grf? 17:21:39 <planetmaker> seems so 17:22:23 <planetmaker> 891646 vs 825364 bytes 17:25:10 <Rubidium> also, the version checks have been in there since the beginning 17:26:21 <planetmaker> that hardly is an argument. Or we should not cleanup or change anything 17:27:35 <Rubidium> it was only to 'debunk' frosch123's statement about it 17:28:29 <planetmaker> the size otoh is an argument 17:30:11 <Rubidium> though... the version check is incorrect for GRF v8 17:30:34 <Rubidium> on the other hand, I have no real clue why r23232 changed it from 7 to 8 17:31:35 <Rubidium> having said that... does ttdpatch barf on v8? 17:31:41 <Rubidium> what about older openttds? 17:33:27 <Rubidium> on the other hand, if they use that one their installation is screwed anyhow 17:37:06 <frosch123> ttdp barfs on v8 17:37:11 <frosch123> older ottd do not barf on v8 17:41:33 *** DorpsGek changes topic to "OpenTTD Dev Channel || Latest SVN: r25606 || Logs: http://webster.openttdcoop.org/?channel=openttd.dev || Voice (talk-right) upon request via #openttd; make sure you are registered to NickServ before asking" 17:51:13 <frosch123> http://devs.openttd.org/~frosch/diffs/msu_psql/ <- compiles and links 17:51:18 <frosch123> no idea whether it works :p 17:54:35 <Rubidium> just make your own masterserver and join your own server to it ;) 17:55:15 <Rubidium> and... heisen-ishbugs are annyoing 17:55:33 <Rubidium> e.g. FS#5444 17:55:59 <Rubidium> just had it, but... not reproducable 17:56:16 <frosch123> yup, next task is to start a bananas and master server :p 17:56:44 <frosch123> i am just not yet able to upload stuff to bananas 17:56:56 <Rubidium> bananas is trickier with the separate files and such 17:57:48 <frosch123> yeah, i need to get rid of the mirroring :p 17:58:07 <Rubidium> just keep ismirrored false ;) 18:09:58 <Rubidium> frosch123: about 5542etc; the first two todos shouldn't check the other tiles. In that case the whole platform would be reserved at tile 1 and the subsequent tiles would get a "can't reserve" return value which implies the track being occupied 18:12:22 <Rubidium> frosch123: the last todo (NPF); if you do not undo the reservation of the target tile, then 6 lines later it can't reserve the tile and it undoes everything, i.e. it's marked as unreachable I guess 18:24:08 <Rubidium> frosch123: the first YAPF one is the tile the train is already at (so reserved). If it returns false there, the reservation 'fails' 18:25:46 <Rubidium> frosch123: and the second YAPF on seems to be "don't unreserve what we haven't tried to reserve"; it was the tile that already has a reservation 18:32:14 <michi_cc> With hindsight I'm not sure it was a wise decision to stick with the platform skipping in the YAPF code. Seeing all the problems in that area it might have been better to throw that out and handle stations tiles like any other tile in YAPF/ the track follower. The only part of the code that directly depends on it is the station length penalty. 18:40:33 <frosch123> replaces some of the TODOs with a comment :) 18:40:43 <frosch123> let's see whether it actually works 18:46:01 <frosch123> it doesn't :p 18:46:15 <frosch123> it does not reserve station platforms 18:46:23 <frosch123> only when reversing in the station 18:47:02 <Rubidium> so it might be a case of FS#5216 ? 18:47:24 <Rubidium> some track changes are seen as dead end 18:47:33 <Rubidium> even though the train can travel over it 18:47:43 <frosch123> it reserves up to the station 18:47:49 <Rubidium> it that's the case here, it'll just reserve until the 'dead end' 18:47:58 <frosch123> oh 18:48:05 <frosch123> yeah, that might be it 18:49:23 <frosch123> yeah, it reserves the platform when the endtile is compatible 18:49:32 <Rubidium> the msu patchqueue looks okay at first sight 18:50:55 <frosch123> hmm, these stupid tracktypes do not show reservations properly 18:51:11 <frosch123> looks like they reserve up to the tile which the train can reach upon entering 18:51:20 <frosch123> but reserve the whole platform when reversing 18:52:14 <Rubidium> but something stupid happens; if you make the first tile "betuweroute", then it will go up to the last 'normal' track of the first stretch of normal tracks 18:52:17 <frosch123> yay, two trains can even tner the platform independently 18:55:16 <Rubidium> hmm... your 'reserve the whole platform' thing does not even reserve the whole platform? 18:55:55 <frosch123> i think the issue is with the TODOs in the yapf (did not check npf) 18:56:03 *** ntoskrnl has quit IRC 18:56:05 <frosch123> i guess it only reserves from where the pathfinder ended 18:57:16 <frosch123> i blame ReserveRailStationPlatform 18:57:24 <frosch123> let's printf what m_origin_tile actually is 19:03:39 <frosch123> yeah, i guess it has to extent the resrvation in the other direction 19:04:22 <Rubidium> it's the end tile? 19:04:39 <frosch123> tile is the end tile of the compatible track 19:04:53 <Rubidium> so it really might be just FS#5216 19:04:59 <Rubidium> and solving that would solve this as well 19:05:45 <frosch123> no, i extended the platform with a tracktype which the train is not compatible to 19:05:55 <frosch123> the pathfinder stops there because the train cannot enter it 19:06:02 <frosch123> but the reservation shall extent nevertheless 19:06:29 <Rubidium> too bad... my desyncy fix for FS#5216 doesn't solve it 19:06:41 <Rubidium> though, in this case the track is compatible with the train 19:07:58 <Rubidium> it's GetPlatformLength that messes things up 19:09:21 <Rubidium> or rather... GetTrainStopLocation should get the platform length that the train can drive on 19:09:32 <frosch123> that part works for me 19:09:36 <frosch123> the stopping is correct 19:10:25 <Rubidium> ah, your patch accounts for that 19:29:10 *** ChanServ sets mode: +v orudge 19:38:08 <frosch123> hmm, maybe the right thing is to ignore railtypes when extending the path to the save waiting point 19:39:17 <planetmaker> simplifies the checks definitely 19:40:31 <planetmaker> and I can't come up with a real-world scenario which breaks 19:41:52 <frosch123> hmm, FindNearestSafeTile already has a parameter "override_railtype" 19:41:57 <frosch123> what's that? :p 20:40:29 *** frosch123 has quit IRC 20:52:42 *** SmatZ has quit IRC 20:52:56 *** SmatZ has joined #openttd.dev 20:52:56 *** ChanServ sets mode: +v SmatZ 21:15:24 *** Alberth has left #openttd.dev 23:01:50 *** Ristovski has quit IRC