Back to Home / #openttd / 2019 / 01 / Prev Day | Next Day
#openttd IRC Logs for 2019-01-16

---Logopened Wed Jan 16 00:00:23 2019
00:06-!-HerzogDeXtEr1 [] has quit [Read error: Connection reset by peer]
01:20-!-sla_ro|master [] has joined #openttd
01:20-!-sla_ro|master is "slamaster" on #sla #openttd
01:47<@peter1138>LordAro, weird, it was rebased to HEAD on master already? o_O
01:47<DorpsGek_II>[OpenTTD/OpenTTD] PeterN updated pull request #7065: Change: Make ships stop and change direction slowly instead of instantly turning.
01:47*peter1138 updates anyway.
01:48<@peter1138>(Changed some spacing)
01:53<DorpsGek_II>[OpenTTD/OpenTTD] PeterN commented on pull request #7065: Change: Make ships stop and change direction slowly instead of instantly turning.
02:27<LordAro>peter1138: weird. i just looked at the commit date and assumed the branch was old
02:34<@peter1138>Mmm, 'poached' egg on toast.
02:34<@peter1138>(Microwaved in a Pyrex jug is not quite poaching...)
02:36<@peter1138>LordAro, my RGB company colours patch has commits dating from 2013 :-)
02:53-!-andythenorth [] has joined #openttd
02:53-!-andythenorth is "andythenorth" on #openttd
03:07<LordAro>peter1138: :)
03:12-!-WWacko1976-work [] has joined #openttd
03:12-!-WWacko1976-work is "YO!" on #openttd #/r/openttd
03:17-!-chomwitt is "chomwitt" on #debian #debian-games
03:17-!-chomwitt [] has joined #openttd
03:19-!-andythenorth [] has quit [Quit: andythenorth]
03:36<AKTheKnight>Sacrilege, how dare you call microwaving in a Pyrex jug poaching
03:52-!-Gabda [] has joined #openttd
03:52-!-Gabda is "Gabda" on #openttd
03:59-!-andythenorth [] has joined #openttd
03:59-!-andythenorth is "andythenorth" on #openttd
04:00-!-sla_ro|master [] has quit []
04:01-!-andythenorth [] has quit []
04:01<@peter1138>AKTheKnight, I know! But it's much simpler, and takes 40 seconds.
04:05<@peter1138>Saying that, I've never tried to actually poach an egg.
04:07<AKTheKnight>Haha I did my first solo one the other day, poached it in my ramen
04:07<AKTheKnight>Turned out pretty good tbh
04:08<@peter1138>Ah, so it was semi-contained by the ramen.
04:14-!-andythenorth [] has joined #openttd
04:14-!-andythenorth is "andythenorth" on #openttd
04:20<@peter1138>Mr the North.
04:21-!-Laedek [~quassel@] has quit [Quit: Laedek]
04:22<andythenorth>so it is
04:22<andythenorth>@seen pikka
04:22<@DorpsGek>andythenorth: pikka was last seen in #openttd 12 weeks, 6 days, 20 hours, 57 minutes, and 51 seconds ago: <Pikka> yo
04:22<@peter1138>He was... 'getting back into it'
04:22<@peter1138>I see pikkarail is empty again.
04:23<andythenorth>the ship-turning in canals is a bit crap
04:23<andythenorth>ship it anyway
04:23<andythenorth>it seems to drive to edge of tile, then turn
04:24<@peter1138>Edge of tile is where vehicles turn around, usually.
04:24<@peter1138>Comment on the PR, suggest improvements.
04:24<andythenorth>it's better having it than not
04:25<andythenorth>the dock behaviour is much nicer
04:25<@peter1138>Maybe it's possible to have a ship move backwards slowly and then turn when it has space.
04:25<@peter1138>Who knows!
04:25<andythenorth>just say 'no room to turn'
04:25<andythenorth>'ship is lost'
04:25<andythenorth>also this
04:25<andythenorth>"Ship becomes lost if destination is greater than maximum order distance"
04:25<andythenorth>isn't that just a tautology?
04:25<@peter1138>Make Ships Crap Again.
04:26<andythenorth>ship orders don't work, ship is lost, case closed?
04:26<andythenorth>'lost' == 'orders aren't valid'
04:26<@peter1138>Also, if you use NPF in that situation, it doesn't find a path either.
04:27<andythenorth>" it becomes within distancemanhattan reach and re-invokes the pathfinder again, only to get out of reach again, lost."
04:27<andythenorth>sounds like a bug though :|
04:27<andythenorth>if it's in distance, it should work?
04:27<andythenorth>not fail?
04:27<andythenorth>issue described doesn't match issue title?
04:27<@peter1138>The actual route is far longer than the manhattan distance.
04:28<@peter1138>Due to a landmass being in the way.
04:29<@peter1138>As my comment says, I think either the pathfinders should be limited to the max order distance, or we fix the pathfinders some other way and remove the distance limit completely.
04:31<LordAro>i'd prefer the latter
04:31<@peter1138>I would actually, but we've been wanting that for YEARS.
04:36<@peter1138>Is it lunch time yet?
04:38<LordAro>i hope not, i've not gotten to work yet
04:38*LordAro speeds up
04:46<AKTheKnight>It's always lunchtime somewhere
04:46<@peter1138>I've settled for a cuppa instead.
04:53*andythenorth should very working
04:54<andythenorth>was Horse finished by christmas?
04:54<andythenorth>84% now, probably not
04:55-!-andythenorth [] has quit [Quit: andythenorth]
05:01-!-Laedek [~quassel@] has joined #openttd
05:01-!-Laedek is "Laedek" on #openttd
05:09<Gabda>what are your thoughts on the map cache array in PR #7047?
05:11<Gabda>if thinks like this is OK, I plan to add a station catchment layer and a debug layer (making the cache 4bit / tile instead of 1 bit)
05:24<@peter1138>An array of bools isn't 1 bit ;-)
05:32<Gabda>and if I add the /tile?
05:44-!-Lejving_ [] has quit [Read error: Connection reset by peer]
05:44<Eddi|zuHause>does C(++) even make any promises about the size of a bool?
05:50<Xaroth>To the stack overflow? :P
05:55<LordAro>to the standards document!
06:01<LordAro>"sizeof(char), sizeof(signed char) and sizeof(unsigned char) are 1; the result of sizeof applied to any other fundamental type is implementation-defined. [Note: in particular, sizeof(bool) and sizeof(wchar_t) are implementation-defined."
06:01<LordAro>"sizeof(bool) is not required to be 1."
06:02<LordAro>i *imagine* that matches C & _Bool
06:05<LordAro>"While the number of bits in a _Bool object is at least CHAR_BIT, the width (number of sign and value bits) of a _Bool may be just 1 bit."
06:06<LordAro>i was bored.
06:09<Eddi|zuHause>i would find different ways to escape boredom than reading the c standard
06:20<LordAro>well, more of a distraction
06:36-!-andythenorth [~andytheno@] has joined #openttd
06:36-!-andythenorth is "andythenorth" on #openttd
06:56-!-snail_UES_ [] has joined #openttd
06:56-!-snail_UES_ is "Jacopo Coletto" on #openttd
07:04<+tokai>I worked on systems where sizeof(bool) (or for the system "BOOL" type) resulted in 4. Good old times. :)
07:05<andythenorth>that's like my python code
07:05<andythenorth>len(string), oops
07:08<Eddi|zuHause>i don't think that is remotably comparable :p
07:09<Gabda>if we don't look at the size of the bool array as it can be optimised
07:09<Gabda>the idea about a separate map cache can go?
07:10-!-snail_UES_ [] has quit [Quit: snail_UES_]
07:10<Eddi|zuHause>what was the idea again?
07:10<Eddi|zuHause>we already have a map array
07:10<Gabda>but tah
07:10<Gabda>that one gets saved
07:11<Eddi|zuHause>you could adapt the saveload code to skip parts?
07:11<Gabda>(and might be synchronised between clients)
07:12<Gabda>and the information in it falls to another logical category
07:12<Gabda>as it is purely visual info
07:13<Eddi|zuHause>there was this idea floating around about caching the closest town
07:14<Gabda>there was
07:14<Eddi|zuHause>that is game state, not "purely visual"
07:14<Gabda>at first I thought this info could be stored in a way that the lookup would be constant
07:16<Gabda>but that would need the O(#tiles) array
07:17<Eddi|zuHause>yes. memory and time are often opposite optimisation goals
07:18<Gabda>and as I looked around, the closest town searching is not called that often
07:18<Eddi|zuHause>well, not currently, because it's expensive and thus avoided
07:18<Eddi|zuHause>if it was cheaper, it could be used more
07:20<Gabda>are there ideas that could validate the extra memory usage?
07:20<Eddi|zuHause>the example use case would be railtypes
07:21<Eddi|zuHause>which are notoriously low on storage space, and thus lack easy access to town zone, that roads have access to
07:22<@peter1138>Gabda, not 1 bit / tile either. Bool is usually 1 byte, not a 1 bit.
07:23<@peter1138>Gabda, if you add a cache, add it as a struct with the member you need from the start, rather than just a bool/byte.
07:23<Gabda>i don't understand this railtype thing
07:24<Gabda>peter: even if it is only has one member at the moment?
07:24<@peter1138>Yes. Otherwise you need to touch everywhere that uses it if it gets extended in the future.
07:26*Sacro touches everywhere
07:27<Gabda>yes, I planned to do that: rewrite it everywhere when the cache structure is updated :)
07:27<Eddi|zuHause>Gabda: that's what we have map accessors for
07:28<Eddi|zuHause>Gabda: to abstract away the data structure from the data access
07:29<Gabda>it is behind one layer of accessor, I just need to add another layer if the cache gets a 2nd function
07:29<Eddi|zuHause>Gabda: so, for example, if we decided to merge _m and _me then we only have to touch a dozen places instead of hundreds
07:29<Gabda>but as I am not sure that this is the right way, I did not to complicate it in the first version
07:31<Gabda>yes, I also like that GB and SB solution
07:39<Gabda>but I still don't know which is the more supported way
07:39<Gabda>1: do this cache properly: can add station catchment and debug layer easily later
07:40<Gabda>2: make a closest town array, which is a few times bigger, but can enable new functions later
07:41<Eddi|zuHause>independent from content, if you add another array, do it the same way as the existing _m and _me arrays, just skip it in the saving code
07:41<Gabda>3: stay at original idea of calculating the closest town every time a tile geta dirty, even if it can be computationaly heavy
07:41<Eddi|zuHause>define what goes in the array in the map accessors
07:42<Eddi|zuHause>which are found in *_map.h
07:42<Gabda>Eddi: even if it means that the size is 1 byte / tile instead of 1 bit/ tile, and the other 7 bit is empty until a new feature uses them?
07:44<Eddi|zuHause>we will find enough ways to fill it with content once it's there
07:44<Gabda>ok, I can do it that way
07:46<Gabda>and a new variable like _mc is OK, or I should create a e.g. m9 in _me and skip the loading and saving part, + update the _me documentation?
07:47<Eddi|zuHause>the size of the members of _m and _me should be a power of 2
07:49<Gabda>oh, that is right, i forgot
07:49<Eddi|zuHause>(likewise, the members of a potential _mc)
07:50<Gabda>yes, that is why I said 1 byte for initial size
07:51<Gabda>ok, thanks Eddi, you helped me a lot
07:51<Eddi|zuHause>there should be an "assert_compile" for that
07:52<Gabda>on how to go forward
07:57<@peter1138>Gabda, it will never be 1 bit / tile.
07:57<@peter1138>Gabda, bool arrays are not memory optimized that way.
07:59<Gabda>if I store it in a way that 1 byte * map size/8, it can be 1 bit/tile
08:00<Eddi|zuHause>that might be more memory optimized, but it's not maintainable/extendable
08:13<@peter1138>Yeah, that's a bad idea.
08:14<@peter1138>What information does your 1 bit store, anyway?
08:17-!-tokai|noir [] has joined #openttd
08:17-!-mode/#openttd [+v tokai|noir] by ChanServ
08:17-!-tokai|noir is "Christian Rosentreter" on +#openttd
08:18<@peter1138>Hmm, just whether it is in a town zone.
08:18<@peter1138>But not which town. So if you have multiple zones showing, it's a bit... meh.
08:22-!-Arveen [] has joined #openttd
08:22-!-Arveen is "realname" on #openttd
08:24<Eddi|zuHause>i'm a bit unsure about the "not saved" part. currently the town zone is usually evaluated in the tileloop, which is saved
08:24-!-tokai [] has quit [Ping timeout: 480 seconds]
08:25<Eddi|zuHause>also, i don't really like the circular nature of the town zones and for future more organic growth, it would also need to be saved
08:26<@peter1138>It's not saved because it's purely used for a visual toggle.
08:26<@peter1138>It's not needed by the game.
08:26<@peter1138>Saving this single bit wouldn't help at all.
08:26<DorpsGek_II>[OpenTTD/OpenTTD] glx22 commented on pull request #7065: Change: Make ships stop and change direction slowly instead of instantly turning.
08:26<@peter1138>*game -> game logic.
08:28<Eddi|zuHause>so, that would actually evolve into a more generic "map overlay" cache
08:28<Eddi|zuHause>which begs the question why evaluate that over the whole map, when (usually) only a small part is visible?
08:29<Eddi|zuHause>well, ok, you could make a minimap view of that
08:30<Eddi|zuHause>but then that makes it tricky to show different things on minimap and various viewports
08:57<@peter1138>Well, it does evaluate only a small part.
09:04-!-Flygon [] has quit [Quit: A toaster's basically a soldering iron designed to toast bread]
09:21<@peter1138>Hmm, why does this code no longer run :/
09:24<Eddi|zuHause>cosmic rays
09:36-!-Thedarkb-T60 [] has joined #openttd
09:36-!-Thedarkb-T60 is "realname" on #openttd #oolite
09:46<andythenorth>refit menu directly on each vehicle in the depot?
09:46<andythenorth>probably clashes with drag, eg
09:57-!-Thedarkb-T60 [] has quit [Ping timeout: 480 seconds]
09:57<Gabda>this map cache can handle multiple towns
09:58<Gabda>even if they connect
09:58<Gabda>what d
09:58<Gabda>what do you mean by circular nature?
09:59-!-Thedarkb-T60 [] has joined #openttd
09:59-!-Thedarkb-T60 is "realname" on #openttd #oolite
10:00<Gabda>(I was away on a git training, that's why my late response)
10:04<Eddi|zuHause>Gabda: town zones are a circle around the town center, with a radius depending on the number of houses
10:05<@peter1138>In which case you can just use that radius and don't need any cache.
10:05<Eddi|zuHause>peter1138: that needs looking up the town
10:05<Gabda>but if you have free space between the houses, that won't belong to the local authority
10:06<Gabda>if it is outside of the set distance
10:06<@peter1138>Eddi|zuHause, but we already know which town we want to view.
10:07<@peter1138>Oh, town zone is not the same as local authority influence?
10:07<Gabda>and when 2 towns grow together, you don't know which house belongs to which town
10:07<Gabda>just from the distance from the towns
10:08<@peter1138>But if you have a house, you know which town it's in.
10:08<Gabda>from the code,yes
10:09<Gabda>in those cases I don't use the info from the cache
10:11-!-nielsm [] has joined #openttd
10:11-!-nielsm is "Niels Martin Hansen" on #openttd
10:13<Gabda>the evaluation only goes for the dirty l
10:14<Gabda>and only checks it, 2 or 3 checks, but no calculation
10:14<Gabda>calculation is only done when the zone button is pressed
10:15<Gabda>and it is only done once per button press
10:31-!-sla_ro|master [] has joined #openttd
10:31-!-sla_ro|master is "slamaster" on #sla #openttd
10:34<Gabda>is there an original town zone, or you are asking about the zone that is shown in the new overlay?
10:35<Gabda>because the overlay wants to show the local authority influence
10:35<Gabda>all the tiles that belongs to the influence
10:56<@peter1138>So, nearest town, or actual town for tiles that store the town.
10:56<@peter1138>And yeah, nearest town is slow.
10:58-!-Gabda2 [] has joined #openttd
10:58-!-Gabda2 is "Gabda" on #openttd
10:59-!-Gabda2 [] has quit []
10:59-!-Gabda2 [] has joined #openttd
10:59-!-Gabda2 is "Gabda" on #openttd
11:04-!-Gabda [] has quit [Ping timeout: 480 seconds]
11:26-!-Gabda2 [] has quit [Quit: Yaaic - Yet another Android IRC client -]
11:26-!-Gabda [] has joined #openttd
11:26-!-Gabda is "Gabda" on #openttd
11:28-!-Samu [] has joined #openttd
11:28-!-Samu is "..." on #openttd
11:55-!-Progman [] has joined #openttd
11:55-!-Progman is "Peter Henschel" on #openttd
11:56<Samu>distancemaxplusmanhattan is almost similar to distancesquare between the same points
11:58<Samu>(distancemaxplusmanhattan(tile_1, end_tile) < distancemaxplusmanhattan(tile_2, end_tile)) == (distancesquare(tile_1, end_tile) < distancesquare(tile_2, end_tile))
11:59-!-Thedarkb-T60 [] has quit [Ping timeout: 480 seconds]
11:59<Samu>if one is less than, the other is also less than, if one is equal, the other is also equal, if one is more than, the other is also more than
12:00<Gabda>are you sure?
12:00<Samu>not 100% sure, didn't use asserts
12:00<Samu>it's what it appears to be
12:01<Gabda>i think there are cases when it is the opposite
12:01<Samu>gonna assert, brb
12:05<Samu> assert((distancempm_i < distancempm_best_track) == (distances_i < distances_best_track));
12:05<Samu> assert((distancempm_i == distancempm_best_track) == (distances_i == distances_best_track));
12:05<Samu> assert((distancempm_i > distancempm_best_track) == (distances_i > distances_best_track));
12:05<Samu>using the 5000 ship savegame
12:06<Samu>perhaps i'm conditioning the result
12:07<Gabda>form (0;0) calc the two distances of (0;100) and (51;51) with the two methods
12:09<nielsm>Samu, you're right in 98% of cases
12:09<Gabda>oh, you wrote distanceMAXPLUSmanghatten
12:09<nielsm>over 10000 iterations of random tile coordinates
12:09<Gabda>maaybe I
12:09<Gabda>mayve i need another example
12:11<nielsm>there's how I tried it
12:13<Samu>where's the 3rd tile?
12:13<nielsm>at 0,0
12:14<Samu>it has yet to assert, i think im conditioning the sample
12:16<Samu>your distancemax looks different
12:16<Samu> const uint dx = Delta(TileX(t0), TileX(t1));
12:16<Samu> const uint dy = Delta(TileY(t0), TileY(t1));
12:16<Samu> return dx > dy ? 2 * dx + dy : 2 * dy + dx;
12:17<nielsm>that's equivalent
12:17<Gabda>end_tile (0;0) first tile (0;100), second tile (3;99)
12:17<Samu>hmm, strange then, i'm not getting an assert
12:19-!-Alberth [] has joined #openttd
12:19-!-mode/#openttd [+o Alberth] by ChanServ
12:19-!-Alberth is "purple" on @#openttd
12:19<Gabda>if you draw the "surfaces" witg equal values, the square distance gives you a circle. the maxplusmanhattan gives you a star with 4 spikes
12:21<Samu>i'm doing it wrong maybe
12:21<Samu>tile 1 and tile 2 are not exactly randomly picked
12:21<Gabda>if you draw concentric circles with similar diameters, and "concentric" stars with a similar size than the circles
12:22<Gabda>you can find points that are on the outer circle but the inner star
12:22<Gabda>and points that are on the innes circle but the outer star
12:29-!-HerzogDeXtEr [] has joined #openttd
12:29-!-HerzogDeXtEr is "purple" on #openttd
12:31<Samu>no asserts happened, 5000 ships testing for about 10 minutes
12:31<Samu>maybe i'm gonna try 2 random tiles indeed
12:31<Samu>just for fun
12:35<Gabda>you can try those coordinates I wrote
12:35<Samu>aha, it asserted
12:38<Samu>i wish i could visualize this
12:38<Samu>where did you find those circles Gabda?
12:38<Gabda>i draw it on paper
12:41<@peter1138>Hmm, anyone got a savegame with a load of slow ships?
12:42<Samu>slow ships, u mean their max speed?
12:42<@peter1138>Hahaha no
12:42<@peter1138>I had made one but it was artificial and my tweaks fixed it.
12:43<Samu>ought to be slow enough
12:45-!-glx [] has joined #openttd
12:45-!-mode/#openttd [+v glx] by ChanServ
12:45-!-glx is "Loïc GUILLOUX" on #openttd.noai #openttd.notice +#openttd
12:45<@peter1138>Slow enough, makes the game run at 19 fps for me.
12:45-!-frosch123 [] has joined #openttd
12:45-!-frosch123 is "frosch" on #openttd
12:45-!-Gabda_math [] has joined #openttd
12:45-!-Gabda_math is "OFTC WebIRC Client" on #openttd
12:46<Gabda_math>I hope I can paste really long links
12:47-!-Gabda_math [] has quit []
12:48<@peter1138>Oh but it's using OPF. HAH.
12:48<Gabda>the maxplusmanhattan has a different shape than I immagined at first
12:49<Samu>nonocab uses many buoys
12:49<Samu>and yet, opf is slow
12:49<Samu>octogonal shape? :p
12:50<Gabda>(I imagined the minplusmanhattan instead)
12:50<Eddi|zuHause>what non-problem are we trying to solve today?
12:52<Gabda>you can't solve actual problems all day...
12:52<@peter1138>Samu, that save is only slow because it uses OPF :/
12:53<Samu>ok, let me find something slow that is not opf
12:54<Gabda>if it comes to that, is it OK to necro an issue that Andy closed because it won't get any attention?
12:54<@peter1138>If you give it attention, then yes.
12:56<@peter1138>Oh, removing my debug output improves performance a bit :p
12:57<+glx>nasty debug output ;)
12:57<@peter1138>printf :-)
12:57<Samu>got one that is slow with NPF, is that ok? have to kill the ai
12:57<@peter1138>So my ship path cache does reduce CPU usage.
12:57<@peter1138>I need slow with YAPF, because I'm not ever ever ever intending to optimise OPF or NPF.
12:58<LordAro>by how much?
12:58<Samu>ok, let me find moar
12:58<@peter1138>2.8ms average vs 3.7ms
12:58<@peter1138>Well, that's actually pretty significant.
12:58<LordAro>@calc 2.8/3.7
12:58<@DorpsGek>LordAro: 0.756756756757
12:59<@peter1138>That's caching a path for a whopping 64 tiles though.
12:59<@peter1138>And it uses a stack. There may be a more optimal storage system, say a ringbufffer.
12:59-!-Wolf01 [] has joined #openttd
12:59-!-Wolf01 is "Wolf01" on #openttd
13:00<@peter1138>This is overall ship ticks, btw, not time spent in the pathfinder.
13:00<Samu>this one i got here, if u switch to yapf, will still be slow, at least in 1.8.0
13:01<Samu>let me upload
13:02<Samu>actually, i have a yapf one
13:02<@peter1138>Hmm, 2.6ms with a 128 tile cache.
13:02<@peter1138>But that could be statistical noise.
13:03<DorpsGek_II>[OpenTTD/OpenTTD] SamuXarick commented on pull request #6928: Fix #5713: Use pathfinder to find closest ship depot
13:04<Samu>sec, maybe i'll point to the topic
13:04<@peter1138>Yeah, that's slow.
13:06<Samu>many saves from my ai testings
13:07<Wolf01>So is brexit, isn't it?
13:08<Samu>a good one is OtviAI v418 (N), 1.6.1
13:08<Samu>it's NPF, but Otvi likes to make huge distant connections without buoys, maybe if you switch to yapf
13:08<@peter1138>^ somewhat better...
13:09<@peter1138>Otvi is broken then :p
13:09<@peter1138>Is our order-distance checker GUI only? :p
13:10<Samu>NPF didn't have the check
13:10<Samu>only the other 2
13:13<@peter1138>That's not what I meant.
13:14<Samu>opf checks for 130 distance limit
13:14<@Alberth>aurcraft crashes when it's out of fuel?
13:14<Samu>between order when inserting order
13:14<Samu>npf doesn't
13:14<Samu>yapf does
13:15<Samu>unless that was changed recently
13:16-!-andythenorth [~andytheno@] has quit [Quit: andythenorth]
13:17-!-HerzogDeXtEr [] has quit [Read error: Connection reset by peer]
13:20<Samu>no, not changed yet
13:20<Samu>NPF can insert huge distances between orders
13:21<nielsm>gah I don't understand how this driver originally played percussion, I don't see it writing to register 0xBD anywhere, and that's the register controlling the percussion
13:26<Samu>also here
13:27<Samu>and here
13:28<Samu>and not sure if it's in more places
13:31<Eddi|zuHause>can you observe it during runtime?
13:31<nielsm>now, this actually sounds quite correct:
13:34<nielsm>...but massively different from running TTD in dosbox
13:35<Eddi|zuHause>yeah, it doesn't sound anything like my SB AWE32 :p
13:35<Eddi|zuHause>except it's been maybe 15 years since i last heard that thing :p
13:36-!-gelignite [] has joined #openttd
13:36-!-gelignite is "gelignite" on #openttd
13:37<@peter1138>Sounds muffled.
13:43<@peter1138>Yay, I crashed it :D
13:49<nielsm>okay now I'm just executing the music driver "by hand" via dosbox' debugger
13:50<nielsm>since it's a TSR controlled via calling int66 I can just do that
13:50<Samu>i had a SB AWE32
13:50<Samu>compared to adlib compatible it sounded so much awesome
13:50<Samu>those musics
13:51<@peter1138>Yeah, so my patch needs work if the terrain changes beneath a cached path, but that shouldn't be a huge issue.
13:52<Samu>isn't it like path reservation from trains?
13:52<Samu>instead of using map array, use the vehicle itself
13:52<Samu>that was my idea
13:52<Samu>not sure if a good one
13:53<@peter1138>It is stored in the vehicle, yes.
13:54<@peter1138>However it may actually be better to store it within the orders, so that shared orders benefit.
13:55<@peter1138>There are others doing it that way though, e.g. implicit orders.
13:58-!-andythenorth [] has joined #openttd
13:58-!-andythenorth is "andythenorth" on #openttd
14:08<@peter1138>s/others/other ways/
14:08<andythenorth>planetmaker you here? o_O
14:08<@peter1138>Oh, no that doesn't make sense.
14:09<@peter1138>^ oh yeah, those savegames were unpaused at the same time, so one is definitely better :p
14:10<DorpsGek_II>[OpenTTD/OpenTTD] andythenorth commented on pull request #7065: Change: Make ships stop and change direction slowly instead of instantly turning.
14:10<LordAro>peter1138: nice
14:14<nielsm>hm I need a little assembler or C compiler or pascal compiler or something to make real mode programs >_>
14:16<nielsm>hm nah that's going to lack useful libraries, after all
14:16<nielsm>just an assembler I guess, nasm maybe
14:17<LordAro>andythenorth: you replied to the wrong comment
14:18<andythenorth>oops GH UI :P
14:19<andythenorth>how do I reply to previous comments :P
14:19<DorpsGek_II>[OpenTTD/OpenTTD] andythenorth commented on pull request #7065: Change: Make ships stop and change direction slowly instead of instantly turning.
14:19<andythenorth>ah nvm
14:27<DorpsGek_II>[OpenTTD/OpenTTD] LordAro approved pull request #7063: Fix: deps calculation call could fail due to command line length
14:27<DorpsGek_II>[OpenTTD/OpenTTD] LordAro merged pull request #7063: Fix: deps calculation call could fail due to command line length
14:29-!-Thedarkb-T60 [] has joined #openttd
14:29-!-Thedarkb-T60 is "realname" on #openttd #oolite
14:29<DorpsGek_II>[OpenTTD/OpenTTD] LordAro updated pull request #7057: Fix: A few minor compile warnings under MinGW
14:35<andythenorth>so just how big is 1.9.0 then?
14:36<LordAro>bigly big
14:37<andythenorth>going by eyeball, biggest releases were 1.3.x, 1.1.x and 0.6.x
14:38<Eddi|zuHause>by what metric?
14:39<andythenorth>someone could write a stats script quickly, if they care :P
14:39<andythenorth>* changelog lines
14:39<andythenorth>the intertia of working on mature software tends to result in smaller changesets
14:40<Eddi|zuHause>git diff 1.x.0 1.(x+1).0 | wc -l?
14:40<andythenorth>inertia *
14:40<Eddi|zuHause>did we even port over release branches/tags?
14:41<LordAro>they were
14:41<LordAro>but the branches will make that difficult
14:42<Eddi|zuHause>it's just a rough estimate anyway
14:43<andythenorth>the gradient is steeper for mature software
14:44<andythenorth>it's pretty easy to achieve high change count in unfinished / broken product
14:45<andythenorth>my point is that this one might be pretty significant, given that it's going into a headwind
14:46<andythenorth>planetmaker: I had two qs, if you have time?
14:46<andythenorth>"don't ask to ask" :P
14:46<andythenorth>do you want to try and move this one through? I can help test it
15:07<nielsm>okay, so my dumb little player also fails after a while, in funky ways
15:09-!-Jam35 [] has joined #openttd
15:09-!-Jam35 is "Jam35" on #openttd
15:11-!-Jam35 [] has left #openttd []
15:13-!-Happpy [] has joined #openttd
15:13-!-Happpy is " -" on #openttd @#/r/openttd
15:13-!-Happpy [] has left #openttd []
15:20-!-Gja [] has joined #openttd
15:20-!-Gja is "Martin" on #ceph #bcache #openttd
15:27<@planetmaker>shoot ahead, andy
15:27-!-Gja [] has quit [Remote host closed the connection]
15:28<@planetmaker>hm, the airport tile animation
15:28<@planetmaker>well... yes, possibly a good idea
15:34<andythenorth>my other idea was cleaning up stickies in tt-forums, ottd suggestions and ottd dev
15:34<andythenorth>they are kind of aging badly
15:40<@planetmaker>they do. Let me first create a PR for that anim trigger thing
15:42-!-andythenorth [] has quit [Read error: No route to host]
15:44-!-andythenorth [] has joined #openttd
15:44-!-andythenorth is "andythenorth" on #openttd
15:45<DorpsGek_II>[OpenTTD/OpenTTD] planetmaker opened pull request #7066: Add: [NewGRF] Airport animation trigger for plane landing (#6334, patch by Supercheese)
15:46<LordAro>looks like the CI has gotten stuck again
15:47<Eddi|zuHause>we need that clone of TrueBrain...
15:48<@planetmaker>well, a build may take more than 2 minutes. But possibly yes
15:50-!-andythenorth is now known as Guest934
15:50-!-andythenorth [] has joined #openttd
15:50-!-andythenorth is "andythenorth" on #openttd
15:50<@planetmaker>ah, I see
15:50<LordAro>yay, the CI is useful!
15:51<LordAro>error messages are godawful
15:51<Eddi|zuHause>very -ish
15:51*andythenorth unstable connection :x
15:51<@planetmaker>actually.. it should fail even with a failed CF :P
15:51<@planetmaker>*without a failed...
15:52-!-Guest934 [] has quit [Ping timeout: 480 seconds]
15:53<Eddi|zuHause>it was definitely clearer what failed with the non-azure-CI
15:53<Eddi|zuHause>and what was being tested
15:55<nielsm> <- now I'm just being silly
15:55<nielsm>my terrible code:
15:57<nielsm>but really, it's much easier to step into the original code with a debugger when there isn't a huge protected mode game running at the same time
15:59<LordAro> for those interested, here's a random failing cpython PR
15:59<LordAro>just as descriptive
15:59<DorpsGek_II>[OpenTTD/OpenTTD] planetmaker updated pull request #7066: Add: [NewGRF] Airport animation trigger for plane landing (#6334, patch by Supercheese)
16:00<milek7>windows errors looks better
16:01<LordAro>not entirely sure why that is though
16:01<LordAro>some magic azure is doing with msvc/msbuild
16:01<@planetmaker>it simply must look better. It's one of their cash cows :P
16:02-!-Gabda [] has quit [Quit: Yaaic - Yet another Android IRC client -]
16:02-!-gelignite [] has quit [Quit: Good fight, good night!]
16:03<@planetmaker>Eddi|zuHause, how did you get to that details page for the build?
16:03<Eddi|zuHause>planetmaker: click on details, click on more details, click on more details
16:03<LordAro>mm, lots of clicking, and you can't permalink
16:04<milek7>click on line number
16:04<andythenorth>there is a weird tool for permalink
16:04<andythenorth>it does work
16:04<@planetmaker>I mean when I'm on github... any way to get there?
16:04<Eddi|zuHause>next to the build failed thingie there's a "details" link
16:05<Eddi|zuHause>on the bottom of that page is a "more details at azure" link
16:05<Eddi|zuHause>then you can click on a build, and on the log of that build
16:05<Eddi|zuHause>it's deeply unsatisfactory
16:05<Eddi|zuHause>that it's buried that deep
16:06<andythenorth>we could probably engineer it not to be
16:06<andythenorth>but eh
16:06<andythenorth>there's probably a dirty route where we use a bot to monitor azure, and triage the result
16:06*andythenorth watching jobs complete live
16:06<@planetmaker>hm... say, I'm here at a PR: - I fail to find that link
16:06<andythenorth>strangely satisfying
16:06<andythenorth>planetmaker: "@azure-pipelines OpenTTD CI In progress — This check has started..."
16:07<andythenorth>then 'Details'
16:07<@planetmaker>ok ...
16:07<andythenorth>then "View more details on Azure Pipelines"
16:07<andythenorth>then click a job
16:08<andythenorth>then eventually after more clicks....log output
16:08<andythenorth>many clicks
16:08<andythenorth>does anyone except TB know how the job results are posted to the PR?
16:08<andythenorth>is it a built-in GH thing?
16:08<andythenorth>an Azure-specific extension?
16:08<@planetmaker>omg. hidden in plain sight. Thank you!
16:08<andythenorth>our bot?
16:09<milek7>azure is on 'github marketplace'
16:09<LordAro>andythenorth: builtin
16:09<andythenorth>is it webhooks or something?
16:09<LordAro>specifically, an azure plugin that uses the GH "Checks" API
16:09<LordAro>it's slightly new
16:09<andythenorth>I'm just wondering if we can control the content, and provide better links
16:09<andythenorth>or we wait for it to be fixed upstream
16:10<andythenorth>we could even...provide feedback :o
16:10<andythenorth>crazy idea
16:11<LordAro>so it looks like the useless "Pulling fs layer" window is just pulling the first N lines from stderr when building the docker image (as it does with linux... for reasons)
16:11<LordAro>and there's just a bit of stderr output when initialising the docker build
16:11<LordAro>for some reason
16:11<LordAro>if you can work out how to suppress that, the error messages might be a bit more helpful
16:14*LordAro files a bug
16:14<andythenorth>so it did pass planetmaker
16:15<andythenorth>I'll test it
16:21<andythenorth>planetmaker: I can't get it to work with 7066 PR, ogfx+ airports 0.5.0
16:22<andythenorth>should be
16:23-!-Alberth [] has left #openttd []
16:27<andythenorth>I can see the sprites are defined
16:27<andythenorth>I can see the trigger is defined in ottd
16:27<andythenorth>@seen supercheese
16:27<@DorpsGek>andythenorth: supercheese was last seen in #openttd 7 weeks, 6 days, 22 hours, 54 minutes, and 7 seconds ago: <Supercheese> spem spam spum
16:30<DorpsGek_II>[OpenTTD/OpenTTD] andythenorth commented on pull request #7066: Add: [NewGRF] Airport animation trigger for plane landing (#6334, patch by Supercheese)
16:31<andythenorth>the parameter is inverted
16:31<andythenorth>lol :)
16:32<andythenorth>yeah works for me now planetmaker
16:32<andythenorth>parameter was on, wasn't working, I toggled it off/on, works now
16:32<andythenorth>might have been cached action 14 or something
16:34<@planetmaker>great :)
16:34<@planetmaker>thanks for actually testing
16:35<andythenorth>still not sure it's working for all airports
16:36<andythenorth>yeah only functioning for small airport so far
16:36<andythenorth>dunno if that's a grf issue
16:37<@planetmaker>might be
16:38<andythenorth>ok maybe it just has high threshold
16:38<andythenorth>I run the game on ffwd, it starts to show
16:55<@planetmaker>it should not show immediately, yes
16:55-!-frosch123 [] has quit [Quit: be yourself, except: if you have the opportunity to be a unicorn, then be a unicorn]
16:59<DorpsGek_II>[OpenTTD/OpenTTD] glx22 approved pull request #7057: Fix: A few minor compile warnings under MinGW
16:59-!-acklen_ [] has quit [Remote host closed the connection]
17:02-!-acklen [] has joined #openttd
17:02-!-acklen is "Matt" on #openttd
17:02-!-nielsm [] has quit [Ping timeout: 480 seconds]
17:09-!-acklen [] has quit [Read error: Connection reset by peer]
17:12-!-acklen [] has joined #openttd
17:12-!-acklen is "Matt" on #openttd
17:43-!-sla_ro|master [] has quit []
17:45<@peter1138>Hmm right I should either fix this patch, or go to bed.
17:47<Eddi|zuHause>fix the patch from bed?
17:49-!-andythenorth [] has quit [Quit: andythenorth]
17:49<@peter1138>That... is not happening.
17:50<@peter1138>Besides I also need to consider multiplayer compatibility (none at the moment)
17:50<@peter1138>nighty night
17:51-!-HerzogDeXtEr [] has joined #openttd
17:51-!-HerzogDeXtEr is "purple" on #openttd
17:53-!-Wolf01 [] has quit [Quit: Once again the world is quick to bury me.]
17:56-!-Progman [] has quit [Remote host closed the connection]
18:05-!-Thedarkb-T60 [] has quit [Ping timeout: 480 seconds]
18:13-!-Thedarkb-T60 [] has joined #openttd
18:13-!-Thedarkb-T60 is "realname" on #openttd #oolite
18:23-!-D-HUND is now known as debdog
18:25-!-techmagus [chatrix@2604:5040:10:bb65::1] has joined #openttd
18:25-!-techmagus is "Yahanan Xie" on #openttd #/r/openttd #friendica
18:34-!-HerzogDeXtEr [] has quit [Read error: Connection reset by peer]
18:36-!-Thedarkb-T60 [] has quit [Quit: Leaving]
19:12-!-Flygon [] has joined #openttd
19:12-!-Flygon is "Flygon" on #openttd
19:13-!-Thedarkb-X40 [] has joined #openttd
19:13-!-Thedarkb-X40 is "realname" on #openttd #/r/openttd #oolite
19:43-!-Speedy` [] has joined #openttd
19:43-!-Speedy` is "Speedy's my name." on #openttd #sd
20:03<DorpsGek_II>[OpenTTD/OpenTTD] nikolas opened pull request #7067: Fix typo in code comment: Unitializes -> Uninitializes
20:26-!-snail_UES_ [] has joined #openttd
20:26-!-snail_UES_ is "Jacopo Coletto" on #openttd
22:24-!-Thedarkb1-X40 [] has joined #openttd
22:24-!-Thedarkb1-X40 is "realname" on #openttd #/r/openttd #oolite
22:30-!-Thedarkb-X40 [] has quit [Ping timeout: 480 seconds]
22:41-!-Samu [] has quit []
22:58-!-D-HUND [~debdog@2a00:79c0:602:5b00:7a24:afff:fe8a:d04d] has joined #openttd
22:58-!-D-HUND is "Wowbagger" on #openttd #bitlbee
23:01-!-glx [] has quit []
23:02-!-debdog [~debdog@2a00:79c0:657:9400:7a24:afff:fe8a:d04d] has quit [Ping timeout: 480 seconds]
23:22-!-HerzogDeXtEr [] has joined #openttd
23:22-!-HerzogDeXtEr is "purple" on #openttd
23:26-!-Thedarkb1-X40 [] has quit [Ping timeout: 480 seconds]
23:56-!-snail_UES_ [] has quit [Quit: snail_UES_]
23:59-!-HerzogDeXtEr [] has quit [Read error: Connection reset by peer]
---Logclosed Thu Jan 17 00:00:24 2019