Times are UTC Toggle Colours
03:54:58 *** JacobD88 has joined #openttd.dev 04:11:04 *** JacobD88 has quit IRC 06:20:15 *** Alberth has joined #openttd.dev 06:20:15 *** ChanServ sets mode: +v Alberth 07:02:40 *** Supercheese has quit IRC 07:36:20 *** Supercheese has joined #openttd.dev 07:36:20 *** ChanServ sets mode: +v Supercheese 08:41:53 *** adf88 has joined #openttd.dev 08:41:53 *** ChanServ sets mode: +v adf88 08:47:04 <adf88> hi there 08:47:14 <adf88> i have a micro feature request 08:47:23 <adf88> i think we will agree on this 08:47:51 <adf88> it's about to put industries on top of other things in the smallmap 08:48:19 <adf88> curretly, if you zoom out, small industries will disapper 08:48:35 <adf88> especially those in towns 08:49:06 <adf88> but also oil rigs (they will be hidden behind oil rig "station") 08:49:43 <adf88> all that has to be done is to modify the "_tiletype_importance" array 08:49:46 <adf88> https://hg.openttd.org/trunk.hg/file/185bbf16ad7c/src/smallmap_gui.cpp#l400 08:50:20 <adf88> just give highest importance for industries 08:52:04 <Alberth> hmm, what was I thinking there at the time? :) 08:55:47 <adf88> perhaps it bacame an issue since smallmap zooming featere 08:56:20 <Alberth> no I added that too at the time 08:56:37 <Alberth> iirc the idea was that you only needed global orientation 08:57:16 <Alberth> ie details get lost anyway 09:01:41 <Alberth> what happens if you don't show industries in such a case? 09:06:14 <adf88> nothing bad 09:06:21 <adf88> they will be just ignored 09:07:33 <adf88> or maybe... 09:07:37 <adf88> wait a minute 09:12:20 <adf88> yes, something will happen 09:13:06 <adf88> "pixels" will become blank 09:13:28 <adf88> e.g. 09:13:36 <Alberth> :) code has a way to never make anything simple :) 09:14:01 <adf88> when there is a station and an industry within a single "pixel" 09:14:22 <adf88> booth will disapper 09:14:45 <adf88> perhaps GetTileTypeImportance can be altered in a way 09:15:10 <adf88> no 09:15:21 <adf88> not GetTileTypeImportance, GetEffectiveTileType 09:15:42 <adf88> https://hg.openttd.org/trunk.hg/file/185bbf16ad7c/src/smallmap_gui.cpp#l416 09:16:00 <adf88> maybe include the industry filter into this function 09:16:16 <adf88> so it will return MP_CLEAR for industries that are turned off 09:17:06 <adf88> however, this "issue" is not specific to industries only 09:17:42 <adf88> other things that can be filtered out 09:18:04 <adf88> will hide "underlying" stuff 09:18:28 <adf88> making it disappear 09:19:34 <Alberth> you need something that knows what will be displayed I guess 09:20:02 <Alberth> GetEffectiveTileType is way older than the tile importance code btw 09:20:53 <adf88> filtering can be included into GetEffectiveTileType 09:20:59 <adf88> however, this would mean 09:21:50 <adf88> that filter would have to be applied on every tile 09:23:09 <adf88> currently, only the "effective" tile is processed 09:23:10 <Alberth> somewhere the code should walk over every tile of the 'pixel', right? 09:23:45 <adf88> yes, every "pixel" is a TileArea 09:24:06 <adf88> GetEffectiveTileType walks over the area 09:24:22 <adf88> and picks "effective" tile 09:24:31 <adf88> then the filter is applied 09:27:06 <adf88> sorry, not the GetEffectiveTileType walks over the area but SmallMapWindow::GetTileColours 09:27:56 <adf88> but the order is the same, firstly walk and choose effective tile, then applying filter 09:28:54 <adf88> this can be reversed - apply the filter during the walk 09:31:27 <Alberth> for town and industry, I can see the value 09:32:08 <Alberth> for tracks/road and industry, I don't know 09:32:28 <Alberth> neither would I know for station and industry 09:33:35 <Alberth> hmm, perhaps you're right. If you have industries on, you want to see industries 09:34:04 <Alberth> hmm, hidden industries.... 09:41:05 <adf88> i think it's more important to prevent industries from disappearing then the issue with hidden industries causing other things to disappear 09:43:09 <adf88> there is also another think that can be done - different tile type importance for different map types 09:43:33 <adf88> e.g. in the industries map, industries would have higher importance 09:44:38 <Alberth> could be an option 09:46:14 <Alberth> that should solve the blank pixels 09:47:45 <Alberth> or maybe not... 09:48:36 <Alberth> say I have a very small map, where one tile is one pixel, then current implementation would have blank pixels in other modes, wouldn't it? 09:50:14 <Alberth> maybe it has though, very few people play small maps, and look at minimaps in different modes 10:44:23 *** frosch123 has joined #openttd.dev 10:44:23 *** ChanServ sets mode: +v frosch123 11:10:49 <frosch123> i wonder what could me non-deterministic abuot loading times 11:10:53 <frosch123> *be 11:35:47 *** Supercheese has quit IRC 11:36:16 *** Supercheese has joined #openttd.dev 11:36:16 *** ChanServ sets mode: +v Supercheese 11:41:21 <Rubidium> amount of cargo at station + non-full load 11:41:32 <frosch123> the station is empty 11:41:54 <frosch123> the vehicle arrives, waits for 1 (?) tick and reverses 11:42:51 <frosch123> just that it reverses 1 (?) tick earlier on the server 11:42:57 <Rubidium> that doesn't use loading times, does it? 11:44:12 <frosch123> anyway, the client joins about 1 day before the mismatch occurs 11:44:22 <frosch123> all savegames are identical up to that point 11:44:50 <frosch123> so i wonder what propagates from the join time (when the train is slowing down) to the loading 11:46:02 <frosch123> anyway, i try to narrow the time further 11:48:17 <Rubidium> any new newgrfs? 11:48:24 <frosch123> iron horse 11:48:58 <frosch123> i backported the fixes to the implicitly timetabled waiting times 11:49:01 <frosch123> but they had no effect 11:55:10 <Rubidium> does it arrive later? (you'd need to log the loop-index of the TrainController calls) 12:31:27 <frosch123> wow 12:32:19 <frosch123> devs.openttd.org/~frosch/dmp_cmds_c92067db_000acf30_00.sav <- that savegame does not survive the load/resave test 12:32:25 <frosch123> it differs in m3low 12:32:37 <frosch123> on some weird tile 12:32:54 <frosch123> not sure whether i can figure out which 12:44:17 <frosch123> hmm, no the map array uses some hyper complex format, which my tool cannot decode 12:45:03 <frosch123> hmm, does it? maybe Load_MAP3 is just a little magical with buffers 12:45:37 <Rubidium> really? 12:45:58 <frosch123> yeah i wonder what that myself 12:46:12 <frosch123> maybe i did something wrong 12:46:23 <Rubidium> oh, might it be a number of 4096 element arrays? 12:47:00 <frosch123> yes, but the blocks do not seem to insert anything into the save 12:47:13 <frosch123> anyway, with my computation i end up at some tree tile 12:47:15 <frosch123> which makes no sense 12:47:50 <frosch123> ah, i see where my tile computation failed 12:49:12 <frosch123> its the presignal on tile 656860 12:49:19 <frosch123> no visible train nearby 12:49:49 <frosch123> haha, ok, nevermind 12:50:06 <frosch123> the replay contains a build signal command at exactly that tick :) 12:50:43 <frosch123> though i wonder why it does not create the savegame at the same spot 12:51:48 <frosch123> hmm, are dmp_cmds created at the beginning or at the end of an tick? 12:53:15 <Rubidium> basically the begin 12:54:00 <Rubidium> at least the begin of StateGameLoop 12:55:25 <Rubidium> local command queue is executed just before StateGameLoop 12:56:45 <frosch123> yup, looks better if i remove that command from the command-log 12:56:59 <frosch123> the command was already executed in the save 12:57:13 <frosch123> every desync-debugging sessions results in something new :) 12:57:14 <Rubidium> so the commands of the tick-of-load-of-dmp_cmds are executed twice with the current code 12:58:24 <Rubidium> autosave is before the commands are executed 13:02:27 <Rubidium> normal saving is just after autosave but way before command injection 13:08:17 <frosch123> now i have a difference in the "pathfinder lost" flag of a single train 13:10:52 <frosch123> same station as the original desync later 13:10:55 <Rubidium> oh god... pathfinder cache issues? 13:11:22 <Rubidium> those are especially nasty 13:15:21 <frosch123> likely something with reversing in stations 13:16:20 <frosch123> actually, likely its the same as before 13:16:26 <frosch123> station reverses at different ticks 13:16:33 <frosch123> in one the pf already found the path 13:16:40 <frosch123> in the other one it was not yet started 13:16:47 <frosch123> so, likely same desync, just earlier 13:17:53 <frosch123> though funnily none of the progress variables differ 13:20:27 <frosch123> actually, now i am down to join after 4 days of server start, and then 1 day do desync 13:20:31 <frosch123> so, i guess good enough 13:20:35 <frosch123> let's add more output 13:54:08 <frosch123> i wonder what weird pathfinder setting coop activated :p 13:56:34 <frosch123> anyway, above savegame devs.openttd.org/~frosch/dmp_cmds_c92067db_000acf30_00.sav is still the right savegame to look at 13:57:02 <frosch123> train 52 of company 5 will shorty reverse after loading and then get lost 13:57:06 <frosch123> while there is actually a path 13:57:26 <frosch123> it remains lost on the server, while a client which joins slightly later will find the path 13:59:49 <frosch123> so, well, debugging can continue in singleplayer :) 13:59:55 <frosch123> but i am going to catch some sun 14:48:50 <adf88> I have two straightforward bug fixes 14:49:03 <adf88> checkout www.dropbox.com/sh/aehg8ruvuyyle44/AABVn97iLm-e80W-U9zu8__8a?dl=0 14:49:37 <adf88> they fix glitches when drawing lines (GfxDrawLine) 14:50:24 <adf88> first one 14:50:26 <adf88> "vert-horz-dashed-line-drawing-glitch" 14:51:06 <adf88> is about vertical/horizontal dashed lines :) 14:51:32 <adf88> load the included savegame and show the linkgraph 14:52:09 <adf88> you will see how lines glitch when ship moves 14:52:28 <adf88> there is also a screenshot 14:53:20 <adf88> currently the dashing start at the clipping rectangle which is bviously wrong 14:54:15 <adf88> Second patch is about glitching thick lines 14:54:54 <adf88> the more thick and horizontal line is the bigger glitches 14:55:24 <adf88> try moving a window near such a line and you will see the glitches 14:55:42 <adf88> it's shown on included screenshot 14:57:32 <adf88> the width of the line is handled wrong during the clipping 14:57:44 <adf88> thus glitches 14:59:53 <adf88> these two patches also improve comments a little 15:40:22 <frosch123> hmm, why do the horizontal/vertical lines have special clipping code anyway? 15:42:34 <frosch123> is it some kind of optimisation? but for what case :o 15:45:28 <frosch123> second diff looks correct to me, except spelling booth -> both :) 15:46:26 <frosch123> ah, replacing the "dl=0" with "dl=1" in the url gives a proper file 15:47:15 <frosch123> hmm, wget doesn't work though 15:53:16 <frosch123> haha, actually forgot to fix the spelling :p 15:53:19 <frosch123> @services op 15:53:19 *** ChanServ sets mode: +o DorpsGek 15:54:14 *** DorpsGek changes topic to "OpenTTD Dev Channel || Latest SVN: r27323 || 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:19:21 <adf88> vert/horz lines are most common 16:19:26 <adf88> and clipping is easy 16:20:12 <adf88> probably that's why 16:20:55 <adf88> ok, maybe they WERE most common before the linkgrapf :) 16:21:40 <frosch123> most horz/vert lines actually use GfxFillRect 16:21:56 <frosch123> mainly the tree views use drawline 16:22:23 <adf88> bounding boxes 16:22:27 <frosch123> but the tree view lines are never particulary long 16:22:27 <adf88> industry chain 16:22:28 <adf88> ... 16:22:38 <frosch123> so, i wonder whether just removing that optimisation 16:22:47 <frosch123> it does not seem worth it 16:25:29 <frosch123> @commit 25119 16:25:29 <DorpsGek> frosch123: Commit by frosch :: r25119 trunk/src/gfx.cpp (2013-03-24 12:54:37 +0100 ) 16:25:30 <DorpsGek> frosch123: -Codechange [FS#5512]: Improve the clipping/visiblity check before sending lines to blitter for drawing. (fonsinchen) 16:27:06 <frosch123> so, the optimisation was added for the linkgraph :p 16:27:32 <adf88> :) 16:27:48 <adf88> not much useful for the lingraph 16:33:45 <frosch123> what do you think? i am having an affinity to removing the clamp, and let Blitter::DrawLine do the clamping in all cases 16:34:06 <frosch123> no special case for horz(vert lines 16:34:20 <adf88> hmmm 16:35:01 <adf88> seems reasonable 16:35:03 <adf88> yes 16:38:08 <adf88> there is a catch inside this clipping, line shouldn't be shorter then 2px so information about the direction is not lost 16:38:34 <adf88> so yes, removing this entirely would simplify the code 16:40:27 <frosch123> the clamping is actually weird 16:40:41 <frosch123> it clamps x for horizontal lines, while it should actually check y 16:42:13 <adf88> I think it's ok 16:43:21 <frosch123> https://paste.openttdcoop.org/p0xbst66f?/p0xbst66f <- i mean something like that 16:44:04 <frosch123> (one of the y should be a y2) 16:44:11 <adf88> it's already done 16:44:18 <adf88> GfxPreprocessLine 16:44:46 <frosch123> ah, another place with clamping :p 16:45:04 <adf88> aaa 16:45:06 <adf88> yes 16:45:33 <adf88> no 16:45:37 <adf88> no, no, no 16:47:23 <adf88> it's all ok 16:48:10 <adf88> it was ok in the trunk and it was ok in my patch 16:48:22 <adf88> your patch is wrong (y instead of y2) 16:48:37 <frosch123> https://paste.openttdcoop.org/p1xfftxyo <- so, only that 16:49:44 <adf88> this is it 16:54:25 *** DorpsGek changes topic to "OpenTTD Dev Channel || Latest SVN: r27324 || 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:59:38 <frosch123> yay, at least turning on yapf cache debugging still compiles :) 17:03:54 <frosch123> and it triggers indeed 17:04:01 <frosch123> dbg: [yapf] CACHE ERROR: CheckReverseTrain() = [F, T] 17:04:17 <frosch123> while the client savegame does not trigger it, thus the desync 17:28:18 <frosch123> ok, it's caused by railtypes again 17:28:29 <frosch123> didn't someone change something with that 2 year ago? :p 17:32:25 <Rubidium> it was me, wasn't it? 17:32:51 <frosch123> statistically likely :p 17:36:53 <frosch123> https://bugs.openttd.org/task/6329 <- now we 'only' need someone who knows yapf :) 17:39:29 <frosch123> it looks like if a elrail trains follows the straigh elrail track, it removes the non-elrail junction 17:39:39 <frosch123> so, maybe something in follow_track 17:41:00 <frosch123> follow_track.hpp:344 ? 17:43:13 <frosch123> ESRB_CACHED_MASK ? 17:43:22 <frosch123> should not contain ESRB_RAIL_TYPE, right? 17:44:46 <frosch123> doesn't change things 17:49:57 <frosch123> yapf_costrail.hpp:490 18:00:27 <frosch123> changed something, fixed that one case, broke many others :p 18:16:44 <frosch123> hmm, when was elrail added? 18:16:50 <frosch123> is yapf older than elrail? 18:18:45 <frosch123> anyway, what i think is wrong was already there in 0.7 18:19:23 <planetmaker> o_O? For a *desync*? 18:19:47 <frosch123> well, how many people build mixed railtypes :) 18:20:43 <Rubidium> 0.5.0-RC1, no 18:22:53 <Rubidium> actually, the branch of YAPF is after the merge of elrail 18:23:10 <frosch123> both kind of in parallel though 18:23:52 <Rubidium> yeah, based on dates it looks like that 18:25:00 <frosch123> https://paste.openttdcoop.org/pprpjbtbv?/pprpjbtbv <- anyway, changed that 18:25:12 <frosch123> but there must be more, since path reservation now fails :p 18:25:43 <frosch123> (meaning: it triggers cache errors) 18:26:38 <Rubidium> isn't Yapf().GetCompatibleRailTypes the set of rails a train can drive on 18:27:10 <frosch123> yes, but if you use that to construct segments for the cache, the cache is only valid for that train 18:27:20 <frosch123> instead segments must be of a single type only 18:27:54 <Rubidium> or should caches be maintained for each compatible railtype bit? 18:28:13 <Rubidium> although I can imagine that being too expensive 18:28:15 <frosch123> yapf_costrail.hpp:529 actually checks for that 18:28:20 <frosch123> but it only checks the first and last tile 18:28:31 <frosch123> the other tiles must be handled by the trackfollower 19:57:11 *** frosch123 has quit IRC 20:47:39 *** Alberth has left #openttd.dev 21:07:54 *** adf88 has quit IRC 23:49:33 *** gnu_jj has joined #openttd.dev