Log for on 28th June 2015:
Times are UTC Toggle Colours
03:54:58  *** JacobD88 has joined
04:11:04  *** JacobD88 has quit IRC
06:20:15  *** Alberth has joined
06:20:15  *** ChanServ sets mode: +v Alberth
07:02:40  *** Supercheese has quit IRC
07:36:20  *** Supercheese has joined
07:36:20  *** ChanServ sets mode: +v Supercheese
08:41:53  *** adf88 has joined
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>
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>
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
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
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> <- 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  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
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: || 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> <- 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> <- so, only that
16:49:44  <adf88> this is it
16:54:25  *** DorpsGek changes topic to "OpenTTD Dev Channel || Latest SVN: r27324 || Logs: || 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> <- 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> <- 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
21:07:54  *** adf88 has quit IRC
23:49:33  *** gnu_jj has joined

Powered by YARRSTE version: svn-trunk