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