IRC logs for #openttd on OFTC at 2019-01-16
⏴ go to previous day
00:03:54 <DorpsGek_II> [OpenTTD/OpenTTD] J0anJosep commented on pull request #7065: Change: Make ships stop and change direction slowly instead of instantly turning. https://git.io/fhW3c
00:03:56 <Samu> testing without asserts, keks
00:05:02 <Samu> many of the asserts were repeating in similar functions
00:06:05 <Samu> looks like it wasn't the asserts
00:06:13 <Samu> it's still slow, oh well, I tried
00:07:56 <Samu> because it can search deeper?
00:08:47 <dwfreed> this is where profiling comes in handy
00:10:00 <Samu> remaining depth was usually quickly decreased from 4 to 2 when heading into coasts
00:11:24 <Samu> it's not quickly decreased now, I suspect I "doubled" its depth, by letting it search deeper on more directions
00:11:35 <Samu> ok let's try a depth of 2 then, brb
00:14:50 <Samu> holy smokes, what a huge difference
00:15:01 <Samu> from 220 ms avg to 4 ms avg
00:15:15 <Samu> looks like i still dont understand depth
00:17:20 <Samu> many lost ships now, gonna try 3
00:21:51 <Samu> depth 3 also with lost ships
00:34:34 <Samu> nevermind, it's worse than i though
00:34:38 <Samu> clearly i dont get depth
00:41:02 <Samu> IsTileFlat is somewhat expensive for no apparent reason
00:53:57 *** Thedarkb-T60 has joined #openttd
01:05:54 *** Wormnest has joined #openttd
01:07:29 <DorpsGek_II> [OpenTTD/OpenTTD] glx22 commented on pull request #7000: Some NewGRF variables concerning railtypes https://git.io/fhWn9
01:07:43 *** snail_UES_ has joined #openttd
01:15:23 <Eddi|zuHause> i should have noticed that
01:15:48 <Eddi|zuHause> also... why did my rebase just eat a commit?
01:16:27 <LordAro> it'll eat empty commits
01:24:50 <Eddi|zuHause> 10 answers to... something... that are either not the original question or "let's look at the internals first"
01:25:43 <LordAro> Samu: i know you think you're bragging, but you're really not
01:27:56 <Eddi|zuHause> but... what i actually wanted to know... after i checkout or --reset hard an older commit, how do i point my branch back to that commit?
01:31:12 <LordAro> oh, not that difficult
01:32:31 <Eddi|zuHause> hm, i thought i did that
01:32:50 <Eddi|zuHause> must have been that wrong turn at albuquerque again
01:37:34 <Eddi|zuHause> it did it again?
01:37:39 <Eddi|zuHause> i don't understand it...
01:41:48 <Eddi|zuHause> apparently in a rebase -i if you "edit" a commit, you must use commit --amend, but if it has a conflict at a "pick" you must not use commit --amend
01:42:07 <Eddi|zuHause> who comes up with this?
01:43:59 <LordAro> do not question the great Linus
01:44:18 <LordAro> though i'm pretty sure Linus handed git off long before rebasing was implemented
01:44:24 <LordAro> and he never uses it anyway
02:10:48 <glx> LordAro: manually moving -lstdc++ from the begining of LDFLAGS to the end of LDFLAGS allow to compile with freetype on MSYS2
02:13:38 <dwfreed> makes sense; stdc++ should be at the end anyway
02:34:24 <DorpsGek_II> [OpenTTD/OpenTTD] glx22 commented on pull request #7057: Fix: A few minor compile warnings under MinGW https://git.io/fhW4k
03:14:30 *** Thedarkb-X40 has joined #openttd
04:25:52 *** HerzogDeXtEr has joined #openttd
05:21:48 *** HerzogDeXtEr has joined #openttd
05:52:06 *** HerzogDeXtEr1 has joined #openttd
05:54:53 *** Eddi|zuHause has joined #openttd
07:20:00 *** sla_ro|master has joined #openttd
07:47:10 <peter1138> LordAro, weird, it was rebased to HEAD on master already? o_O
07:47:38 <DorpsGek_II> [OpenTTD/OpenTTD] PeterN updated pull request #7065: Change: Make ships stop and change direction slowly instead of instantly turning. https://git.io/fhWk0
07:48:03 <peter1138> (Changed some spacing)
07:53:03 <DorpsGek_II> [OpenTTD/OpenTTD] PeterN commented on pull request #7065: Change: Make ships stop and change direction slowly instead of instantly turning. https://git.io/fhWVQ
08:27:54 <LordAro> peter1138: weird. i just looked at the commit date and assumed the branch was old
08:34:04 <peter1138> Mmm, 'poached' egg on toast.
08:34:26 <peter1138> (Microwaved in a Pyrex jug is not quite poaching...)
08:36:51 <peter1138> LordAro, my RGB company colours patch has commits dating from 2013 :-)
08:53:31 *** andythenorth has joined #openttd
09:12:18 *** WWacko1976-work has joined #openttd
09:17:09 *** chomwitt has joined #openttd
09:36:19 <AKTheKnight> Sacrilege, how dare you call microwaving in a Pyrex jug poaching
09:59:51 *** andythenorth has joined #openttd
10:01:57 <peter1138> AKTheKnight, I know! But it's much simpler, and takes 40 seconds.
10:05:22 <peter1138> Saying that, I've never tried to actually poach an egg.
10:07:49 <AKTheKnight> Haha I did my first solo one the other day, poached it in my ramen
10:07:53 <AKTheKnight> Turned out pretty good tbh
10:08:20 <peter1138> Ah, so it was semi-contained by the ramen.
10:14:24 *** andythenorth has joined #openttd
10:22:27 <DorpsGek> andythenorth: pikka was last seen in #openttd 12 weeks, 6 days, 20 hours, 57 minutes, and 51 seconds ago: <Pikka> yo
10:22:44 <peter1138> He was... 'getting back into it'
10:22:56 <peter1138> I see pikkarail is empty again.
10:23:22 <andythenorth> the ship-turning in canals is a bit crap
10:23:48 <andythenorth> it seems to drive to edge of tile, then turn
10:24:11 <peter1138> Edge of tile is where vehicles turn around, usually.
10:24:25 <peter1138> Comment on the PR, suggest improvements.
10:24:54 <andythenorth> it's better having it than not
10:25:05 <andythenorth> the dock behaviour is much nicer
10:25:09 <peter1138> Maybe it's possible to have a ship move backwards slowly and then turn when it has space.
10:25:32 <andythenorth> just say 'no room to turn'
10:25:46 <andythenorth> "Ship becomes lost if destination is greater than maximum order distance"
10:25:50 <andythenorth> isn't that just a tautology?
10:25:52 <peter1138> Make Ships Crap Again.
10:26:02 <andythenorth> ship orders don't work, ship is lost, case closed?
10:26:17 <andythenorth> 'lost' == 'orders aren't valid'
10:26:24 <peter1138> Also, if you use NPF in that situation, it doesn't find a path either.
10:27:21 <andythenorth> " it becomes within distancemanhattan reach and re-invokes the pathfinder again, only to get out of reach again, lost."
10:27:27 <andythenorth> sounds like a bug though :|
10:27:38 <andythenorth> if it's in distance, it should work?
10:27:55 <andythenorth> issue described doesn't match issue title?
10:27:58 <peter1138> The actual route is far longer than the manhattan distance.
10:28:12 <peter1138> Due to a landmass being in the way.
10:29:00 <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.
10:31:23 <LordAro> i'd prefer the latter
10:31:40 <peter1138> I would actually, but we've been wanting that for YEARS.
10:36:53 <peter1138> Is it lunch time yet?
10:38:11 <LordAro> i hope not, i've not gotten to work yet
10:46:15 <AKTheKnight> It's always lunchtime somewhere
10:46:47 <peter1138> I've settled for a cuppa instead.
10:53:36 * andythenorth should very working
10:54:33 <andythenorth> was Horse finished by christmas?
10:54:45 <andythenorth> 84% now, probably not
11:09:09 <Gabda> what are your thoughts on the map cache array in PR #7047?
11:11:20 <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)
11:24:24 <peter1138> An array of bools isn't 1 bit ;-)
11:32:55 <Gabda> and if I add the /tile?
11:44:28 <Eddi|zuHause> does C(++) even make any promises about the size of a bool?
11:50:04 <Xaroth> To the stack overflow? :P
11:55:40 <LordAro> to the standards document!
12:01:03 <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."
12:01:17 <LordAro> "sizeof(bool) is not required to be 1."
12:02:18 <LordAro> i *imagine* that matches C & _Bool
12:05:40 <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."
12:09:29 <Eddi|zuHause> i would find different ways to escape boredom than reading the c standard
12:20:31 <LordAro> well, more of a distraction
12:36:53 *** andythenorth has joined #openttd
12:56:14 *** snail_UES_ has joined #openttd
13:04:56 <tokai> I worked on systems where sizeof(bool) (or for the system "BOOL" type) resulted in 4. Good old times. :)
13:05:17 <andythenorth> that's like my python code
13:05:24 <andythenorth> len(string), oops
13:08:44 <Eddi|zuHause> i don't think that is remotably comparable :p
13:09:00 <Gabda> if we don't look at the size of the bool array as it can be optimised
13:09:28 <Gabda> the idea about a separate map cache can go?
13:10:06 <Eddi|zuHause> what was the idea again?
13:10:14 <Eddi|zuHause> we already have a map array
13:11:08 <Eddi|zuHause> you could adapt the saveload code to skip parts?
13:11:10 <Gabda> (and might be synchronised between clients)
13:12:14 <Gabda> and the information in it falls to another logical category
13:12:55 <Gabda> as it is purely visual info
13:13:51 <Eddi|zuHause> there was this idea floating around about caching the closest town
13:14:43 <Eddi|zuHause> that is game state, not "purely visual"
13:14:49 <Gabda> at first I thought this info could be stored in a way that the lookup would be constant
13:16:51 <Gabda> but that would need the O(#tiles) array
13:17:26 <Eddi|zuHause> yes. memory and time are often opposite optimisation goals
13:18:05 <Gabda> and as I looked around, the closest town searching is not called that often
13:18:34 <Eddi|zuHause> well, not currently, because it's expensive and thus avoided
13:18:48 <Eddi|zuHause> if it was cheaper, it could be used more
13:20:04 <Gabda> are there ideas that could validate the extra memory usage?
13:20:23 <Eddi|zuHause> the example use case would be railtypes
13:21:29 <Eddi|zuHause> which are notoriously low on storage space, and thus lack easy access to town zone, that roads have access to
13:22:30 <peter1138> Gabda, not 1 bit / tile either. Bool is usually 1 byte, not a 1 bit.
13:23:24 <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.
13:23:47 <Gabda> i don't understand this railtype thing
13:24:35 <Gabda> peter: even if it is only has one member at the moment?
13:24:57 <peter1138> Yes. Otherwise you need to touch everywhere that uses it if it gets extended in the future.
13:27:18 <Gabda> yes, I planned to do that: rewrite it everywhere when the cache structure is updated :)
13:27:58 <Eddi|zuHause> Gabda: that's what we have map accessors for
13:28:19 <Eddi|zuHause> Gabda: to abstract away the data structure from the data access
13:29:12 <Gabda> it is behind one layer of accessor, I just need to add another layer if the cache gets a 2nd function
13:29:22 <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
13:29:40 <Gabda> but as I am not sure that this is the right way, I did not to complicate it in the first version
13:31:58 <Gabda> yes, I also like that GB and SB solution
13:39:14 <Gabda> but I still don't know which is the more supported way
13:39:56 <Gabda> 1: do this cache properly: can add station catchment and debug layer easily later
13:40:33 <Gabda> 2: make a closest town array, which is a few times bigger, but can enable new functions later
13:41:22 <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
13:41:25 <Gabda> 3: stay at original idea of calculating the closest town every time a tile geta dirty, even if it can be computationaly heavy
13:41:58 <Eddi|zuHause> define what goes in the array in the map accessors
13:42:18 <Eddi|zuHause> which are found in *_map.h
13:42:58 <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?
13:44:43 <Eddi|zuHause> we will find enough ways to fill it with content once it's there
13:44:51 <Gabda> ok, I can do it that way
13:46:25 <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?
13:47:42 <Eddi|zuHause> the size of the members of _m and _me should be a power of 2
13:49:16 <Gabda> oh, that is right, i forgot
13:49:49 <Eddi|zuHause> (likewise, the members of a potential _mc)
13:50:48 <Gabda> yes, that is why I said 1 byte for initial size
13:51:13 <Gabda> ok, thanks Eddi, you helped me a lot
13:51:17 <Eddi|zuHause> there should be an "assert_compile" for that
13:57:35 <peter1138> Gabda, it will never be 1 bit / tile.
13:57:55 <peter1138> Gabda, bool arrays are not memory optimized that way.
13:59:06 <Gabda> if I store it in a way that 1 byte * map size/8, it can be 1 bit/tile
14:00:09 <Eddi|zuHause> that might be more memory optimized, but it's not maintainable/extendable
14:13:26 <peter1138> Yeah, that's a bad idea.
14:14:20 <peter1138> What information does your 1 bit store, anyway?
14:17:25 *** tokai|noir has joined #openttd
14:17:25 *** ChanServ sets mode: +v tokai|noir
14:18:15 <peter1138> Hmm, just whether it is in a town zone.
14:18:32 <peter1138> But not which town. So if you have multiple zones showing, it's a bit... meh.
14:24:02 <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
14:25: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
14:26:16 <peter1138> It's not saved because it's purely used for a visual toggle.
14:26:20 <peter1138> It's not needed by the game.
14:26:34 <peter1138> Saving this single bit wouldn't help at all.
14:26:37 <DorpsGek_II> [OpenTTD/OpenTTD] glx22 commented on pull request #7065: Change: Make ships stop and change direction slowly instead of instantly turning. https://git.io/fhWjR
14:26:42 <peter1138> *game -> game logic.
14:28:14 <Eddi|zuHause> so, that would actually evolve into a more generic "map overlay" cache
14:28:58 <Eddi|zuHause> which begs the question why evaluate that over the whole map, when (usually) only a small part is visible?
14:29:55 <Eddi|zuHause> well, ok, you could make a minimap view of that
14:30:56 <Eddi|zuHause> but then that makes it tricky to show different things on minimap and various viewports
14:57:45 <peter1138> Well, it does evaluate only a small part.
15:21:21 <peter1138> Hmm, why does this code no longer run :/
15:36:21 *** Thedarkb-T60 has joined #openttd
15:46:29 <andythenorth> refit menu directly on each vehicle in the depot?
15:46:34 <andythenorth> probably clashes with drag, eg
15:57:49 <Gabda> this map cache can handle multiple towns
15:58:34 <Gabda> what do you mean by circular nature?
15:59:42 *** Thedarkb-T60 has joined #openttd
16:00:44 <Gabda> (I was away on a git training, that's why my late response)
16:04:33 <Eddi|zuHause> Gabda: town zones are a circle around the town center, with a radius depending on the number of houses
16:05:13 <peter1138> In which case you can just use that radius and don't need any cache.
16:05:56 <Eddi|zuHause> peter1138: that needs looking up the town
16:05:57 <Gabda> but if you have free space between the houses, that won't belong to the local authority
16:06:19 <Gabda> if it is outside of the set distance
16:06:25 <peter1138> Eddi|zuHause, but we already know which town we want to view.
16:07:26 <peter1138> Oh, town zone is not the same as local authority influence?
16:07:33 <Gabda> and when 2 towns grow together, you don't know which house belongs to which town
16:07:50 <Gabda> just from the distance from the towns
16:08:09 <peter1138> But if you have a house, you know which town it's in.
16:09:22 <Gabda> in those cases I don't use the info from the cache
16:13:44 <Gabda> the evaluation only goes for the dirty l
16:14:17 <Gabda> and only checks it, 2 or 3 checks, but no calculation
16:14:41 <Gabda> calculation is only done when the zone button is pressed
16:15:11 <Gabda> and it is only done once per button press
16:31:57 *** sla_ro|master has joined #openttd
16:34:44 <Gabda> is there an original town zone, or you are asking about the zone that is shown in the new overlay?
16:35:16 <Gabda> because the overlay wants to show the local authority influence
16:35:37 <Gabda> all the tiles that belongs to the influence
16:56:15 <peter1138> So, nearest town, or actual town for tiles that store the town.
16:56:55 <peter1138> And yeah, nearest town is slow.
17:55:37 *** Progman has joined #openttd
17:56:27 <Samu> distancemaxplusmanhattan is almost similar to distancesquare between the same points
17:58:40 <Samu> (distancemaxplusmanhattan(tile_1, end_tile) < distancemaxplusmanhattan(tile_2, end_tile)) == (distancesquare(tile_1, end_tile) < distancesquare(tile_2, end_tile))
17:59:52 <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
18:00:32 <Samu> not 100% sure, didn't use asserts
18:00:48 <Samu> it's what it appears to be
18:01:15 <Gabda> i think there are cases when it is the opposite
18:05:26 <Samu> assert((distancempm_i < distancempm_best_track) == (distances_i < distances_best_track));
18:05:26 <Samu> assert((distancempm_i == distancempm_best_track) == (distances_i == distances_best_track));
18:05:26 <Samu> assert((distancempm_i > distancempm_best_track) == (distances_i > distances_best_track));
18:05:44 <Samu> using the 5000 ship savegame
18:06:05 <Samu> perhaps i'm conditioning the result
18:07:27 <Gabda> form (0;0) calc the two distances of (0;100) and (51;51) with the two methods
18:09:12 <nielsm> Samu, you're right in 98% of cases
18:09:28 <Gabda> oh, you wrote distanceMAXPLUSmanghatten
18:09:29 <nielsm> over 10000 iterations of random tile coordinates
18:09:50 <Gabda> mayve i need another example
18:11:03 <nielsm> there's how I tried it
18:14:56 <Samu> it has yet to assert, i think im conditioning the sample
18:16:13 <Samu> your distancemax looks different
18:16:29 <Samu> const uint dx = Delta(TileX(t0), TileX(t1));
18:16:29 <Samu> const uint dy = Delta(TileY(t0), TileY(t1));
18:16:29 <Samu> return dx > dy ? 2 * dx + dy : 2 * dy + dx;
18:17:50 <Gabda> end_tile (0;0) first tile (0;100), second tile (3;99)
18:17:56 <Samu> hmm, strange then, i'm not getting an assert
18:19:06 *** Alberth has joined #openttd
18:19:06 *** ChanServ sets mode: +o Alberth
18:19:42 <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
18:21:08 <Samu> i'm doing it wrong maybe
18:21:27 <Samu> tile 1 and tile 2 are not exactly randomly picked
18:21:41 <Gabda> if you draw concentric circles with similar diameters, and "concentric" stars with a similar size than the circles
18:22:05 <Gabda> you can find points that are on the outer circle but the inner star
18:22:28 <Gabda> and points that are on the innes circle but the outer star
18:29:32 *** HerzogDeXtEr has joined #openttd
18:31:07 <Samu> no asserts happened, 5000 ships testing for about 10 minutes
18:31:45 <Samu> maybe i'm gonna try 2 random tiles indeed
18:35:34 <Gabda> you can try those coordinates I wrote
18:38:00 <Samu> i wish i could visualize this
18:38:31 <Samu> where did you find those circles Gabda?
18:41:07 <peter1138> Hmm, anyone got a savegame with a load of slow ships?
18:42:18 <Samu> slow ships, u mean their max speed?
18:42:45 <peter1138> I had made one but it was artificial and my tweaks fixed it.
18:45:46 <peter1138> Slow enough, makes the game run at 19 fps for me.
18:45:47 *** frosch123 has joined #openttd
18:45:54 *** Gabda_math has joined #openttd
18:46:05 <Gabda_math> I hope I can paste really long links
18:48:08 <peter1138> Oh but it's using OPF. HAH.
18:48:16 <Gabda> the maxplusmanhattan has a different shape than I immagined at first
18:50:10 <Gabda> (I imagined the minplusmanhattan instead)
18:50:12 <Eddi|zuHause> what non-problem are we trying to solve today?
18:52:34 <Gabda> you can't solve actual problems all day...
18:52:46 <peter1138> Samu, that save is only slow because it uses OPF :/
18:53:46 <Samu> ok, let me find something slow that is not opf
18:54:35 <Gabda> if it comes to that, is it OK to necro an issue that Andy closed because it won't get any attention?
18:54:51 <peter1138> If you give it attention, then yes.
18:56:52 <peter1138> Oh, removing my debug output improves performance a bit :p
18:57:33 <Samu> got one that is slow with NPF, is that ok? have to kill the ai
18:57:43 <peter1138> So my ship path cache does reduce CPU usage.
18:57:57 <peter1138> I need slow with YAPF, because I'm not ever ever ever intending to optimise OPF or NPF.
18:58:34 <peter1138> 2.8ms average vs 3.7ms
18:58:50 <peter1138> Well, that's actually pretty significant.
18:58:56 <DorpsGek> LordAro: 0.756756756757
18:59:12 <peter1138> That's caching a path for a whopping 64 tiles though.
18:59:38 <peter1138> And it uses a stack. There may be a more optimal storage system, say a ringbufffer.
19:00:52 <peter1138> This is overall ship ticks, btw, not time spent in the pathfinder.
19:00:57 <Samu> this one i got here, if u switch to yapf, will still be slow, at least in 1.8.0
19:02:14 <Samu> actually, i have a yapf one
19:02:29 <peter1138> Hmm, 2.6ms with a 128 tile cache.
19:02:38 <peter1138> But that could be statistical noise.
19:03:07 <DorpsGek_II> [OpenTTD/OpenTTD] SamuXarick commented on pull request #6928: Fix #5713: Use pathfinder to find closest ship depot https://git.io/fhlBi
19:04:52 <Samu> sec, maybe i'll point to the topic
19:06:08 <Samu> many saves from my ai testings
19:07:52 <Wolf01> So is brexit, isn't it?
19:08:33 <Samu> a good one is OtviAI v418 (N), 1.6.1
19:08:56 <Samu> it's NPF, but Otvi likes to make huge distant connections without buoys, maybe if you switch to yapf
19:08:56 <peter1138> ^ somewhat better...
19:09:30 <peter1138> Otvi is broken then :p
19:09:38 <peter1138> Is our order-distance checker GUI only? :p
19:10:02 <Samu> NPF didn't have the check
19:13:50 <peter1138> That's not what I meant.
19:14:19 <Samu> opf checks for 130 distance limit
19:14:27 <Alberth> aurcraft crashes when it's out of fuel?
19:14:27 <Samu> between order when inserting order
19:15:10 <Samu> unless that was changed recently
19:20:19 <Samu> NPF can insert huge distances between orders
19:21:02 <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
19:28:10 <Samu> and not sure if it's in more places
19:31:25 <Eddi|zuHause> can you observe it during runtime?
19:34:42 <nielsm> ...but massively different from running TTD in dosbox
19:35:06 <Eddi|zuHause> yeah, it doesn't sound anything like my SB AWE32 :p
19:35:37 <Eddi|zuHause> except it's been maybe 15 years since i last heard that thing :p
19:36:39 *** gelignite has joined #openttd
19:43:18 <peter1138> Yay, I crashed it :D
19:49:49 <nielsm> okay now I'm just executing the music driver "by hand" via dosbox' debugger
19:50:05 <nielsm> since it's a TSR controlled via calling int66 I can just do that
19:50:23 <Samu> compared to adlib compatible it sounded so much awesome
19:51:35 <peter1138> Yeah, so my patch needs work if the terrain changes beneath a cached path, but that shouldn't be a huge issue.
19:52:28 <Samu> isn't it like path reservation from trains?
19:52:37 <Samu> instead of using map array, use the vehicle itself
19:53:56 <peter1138> It is stored in the vehicle, yes.
19:54:29 <peter1138> However it may actually be better to store it within the orders, so that shared orders benefit.
19:55:36 <peter1138> There are others doing it that way though, e.g. implicit orders.
19:58:22 *** andythenorth has joined #openttd
20:08:39 <peter1138> s/others/other ways/
20:08:46 <andythenorth> planetmaker you here? o_O
20:08:55 <peter1138> Oh, no that doesn't make sense.
20:09:40 <peter1138> ^ oh yeah, those savegames were unpaused at the same time, so one is definitely better :p
20:10:30 <DorpsGek_II> [OpenTTD/OpenTTD] andythenorth commented on pull request #7065: Change: Make ships stop and change direction slowly instead of instantly turning. https://git.io/fhl2J
20:14:26 <nielsm> hm I need a little assembler or C compiler or pascal compiler or something to make real mode programs >_>
20:16:37 <nielsm> hm nah that's going to lack useful libraries, after all
20:16:48 <nielsm> just an assembler I guess, nasm maybe
20:17:31 <LordAro> andythenorth: you replied to the wrong comment
20:19:02 <andythenorth> how do I reply to previous comments :P
20:19:24 <DorpsGek_II> [OpenTTD/OpenTTD] andythenorth commented on pull request #7065: Change: Make ships stop and change direction slowly instead of instantly turning. https://git.io/fhlaI
20:27:01 <DorpsGek_II> [OpenTTD/OpenTTD] LordAro approved pull request #7063: Fix: deps calculation call could fail due to command line length https://git.io/fhla1
20:27:09 <DorpsGek_II> [OpenTTD/OpenTTD] LordAro merged pull request #7063: Fix: deps calculation call could fail due to command line length https://git.io/fhcKl
20:29:16 *** Thedarkb-T60 has joined #openttd
20:29:17 <DorpsGek_II> [OpenTTD/OpenTTD] LordAro updated pull request #7057: Fix: A few minor compile warnings under MinGW https://git.io/fhn6E
20:35:09 <andythenorth> so just how big is 1.9.0 then?
20:37:12 <andythenorth> going by eyeball, biggest releases were 1.3.x, 1.1.x and 0.6.x
20:39:04 <andythenorth> someone could write a stats script quickly, if they care :P
20:39:30 <andythenorth> * changelog lines
20:39:58 <andythenorth> the intertia of working on mature software tends to result in smaller changesets
20:40:01 <Eddi|zuHause> git diff 1.x.0 1.(x+1).0 | wc -l?
20:40:36 <Eddi|zuHause> did we even port over release branches/tags?
20:41:45 <LordAro> but the branches will make that difficult
20:42:15 <Eddi|zuHause> it's just a rough estimate anyway
20:43:51 <andythenorth> the gradient is steeper for mature software
20:44:13 <andythenorth> it's pretty easy to achieve high change count in unfinished / broken product
20:45:06 <andythenorth> my point is that this one might be pretty significant, given that it's going into a headwind
20:46:06 <andythenorth> planetmaker: I had two qs, if you have time?
20:46:14 <andythenorth> "don't ask to ask" :P
21:07:37 <nielsm> okay, so my dumb little player also fails after a while, in funky ways
21:27:35 <planetmaker> shoot ahead, andy
21:28:18 <planetmaker> hm, the airport tile animation
21:28:23 <planetmaker> well... yes, possibly a good idea
21:34:01 <andythenorth> my other idea was cleaning up stickies in tt-forums, ottd suggestions and ottd dev
21:34:08 <andythenorth> they are kind of aging badly
21:40:15 <planetmaker> they do. Let me first create a PR for that anim trigger thing
21:44:32 *** andythenorth has joined #openttd
21:45:43 <DorpsGek_II> [OpenTTD/OpenTTD] planetmaker opened pull request #7066: Add: [NewGRF] Airport animation trigger for plane landing (#6334, patch by Supercheese) https://git.io/fhliz
21:46:37 <LordAro> looks like the CI has gotten stuck again
21:47:30 <Eddi|zuHause> we need that clone of TrueBrain...
21:48:30 <planetmaker> well, a build may take more than 2 minutes. But possibly yes
21:50:52 *** andythenorth is now known as Guest934
21:50:52 *** andythenorth has joined #openttd
21:50:57 <LordAro> yay, the CI is useful!
21:51:05 <LordAro> error messages are godawful
21:51:17 * andythenorth unstable connection :x
21:51:32 <planetmaker> actually.. it should fail even with a failed CF :P
21:51:45 <planetmaker> *without a failed...
21:53:08 <Eddi|zuHause> it was definitely clearer what failed with the non-azure-CI
21:53:20 <Eddi|zuHause> and what was being tested
21:57:56 <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
21:59:56 <DorpsGek_II> [OpenTTD/OpenTTD] planetmaker updated pull request #7066: Add: [NewGRF] Airport animation trigger for plane landing (#6334, patch by Supercheese) https://git.io/fhliz
22:00:39 <milek7> windows errors looks better
22:01:27 <LordAro> not entirely sure why that is though
22:01:39 <LordAro> some magic azure is doing with msvc/msbuild
22:01:47 <planetmaker> it simply must look better. It's one of their cash cows :P
22:03:05 <planetmaker> Eddi|zuHause, how did you get to that details page for the build?
22:03:26 <Eddi|zuHause> planetmaker: click on details, click on more details, click on more details
22:03:38 <LordAro> mm, lots of clicking, and you can't permalink
22:04:26 <andythenorth> there is a weird tool for permalink
22:04:29 <planetmaker> I mean when I'm on github... any way to get there?
22:04:56 <Eddi|zuHause> next to the build failed thingie there's a "details" link
22:05:05 <Eddi|zuHause> on the bottom of that page is a "more details at azure" link
22:05:26 <Eddi|zuHause> then you can click on a build, and on the log of that build
22:05:38 <Eddi|zuHause> it's deeply unsatisfactory
22:05:48 <Eddi|zuHause> that it's buried that deep
22:06:00 <andythenorth> we could probably engineer it not to be
22:06:24 <andythenorth> there's probably a dirty route where we use a bot to monitor azure, and triage the result
22:06:39 * andythenorth watching jobs complete live
22:06:42 <andythenorth> strangely satisfying
22:06:57 <andythenorth> planetmaker: "@azure-pipelines OpenTTD CI In progress — This check has started..."
22:07:53 <andythenorth> then "View more details on Azure Pipelines"
22:07:57 <andythenorth> then click a job
22:08:06 <andythenorth> then eventually after more clicks....log output
22:08:27 <andythenorth> does anyone except TB know how the job results are posted to the PR?
22:08:32 <andythenorth> is it a built-in GH thing?
22:08:40 <andythenorth> an Azure-specific extension?
22:08:41 <planetmaker> omg. hidden in plain sight. Thank you!
22:09:17 <milek7> azure is on 'github marketplace'
22:09:22 <LordAro> andythenorth: builtin
22:09:38 <andythenorth> is it webhooks or something?
22:09:41 <LordAro> specifically, an azure plugin that uses the GH "Checks" API
22:09:50 <andythenorth> I'm just wondering if we can control the content, and provide better links
22:09:58 <andythenorth> or we wait for it to be fixed upstream
22:10:04 <andythenorth> we could even...provide feedback :o
22:11:07 <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)
22:11:23 <LordAro> and there's just a bit of stderr output when initialising the docker build
22:11:38 <LordAro> if you can work out how to suppress that, the error messages might be a bit more helpful
22:14:58 <andythenorth> so it did pass planetmaker
22:21:55 <andythenorth> planetmaker: I can't get it to work with 7066 PR, ogfx+ airports 0.5.0
22:26:59 <andythenorth> I can see the sprites are defined
22:27:10 <andythenorth> I can see the trigger is defined in ottd
22:27:47 <andythenorth> @seen supercheese
22:27:47 <DorpsGek> andythenorth: supercheese was last seen in #openttd 7 weeks, 6 days, 22 hours, 54 minutes, and 7 seconds ago: <Supercheese> spem spam spum
22:30:49 <DorpsGek_II> [OpenTTD/OpenTTD] andythenorth commented on pull request #7066: Add: [NewGRF] Airport animation trigger for plane landing (#6334, patch by Supercheese) https://git.io/fhlMd
22:31:28 <andythenorth> the parameter is inverted
22:32:11 <andythenorth> yeah works for me now planetmaker
22:32:34 <andythenorth> parameter was on, wasn't working, I toggled it off/on, works now
22:32:44 <andythenorth> might have been cached action 14 or something
22:34:10 <planetmaker> thanks for actually testing
22:35:27 <andythenorth> still not sure it's working for all airports
22:36:50 <andythenorth> yeah only functioning for small airport so far
22:36:55 <andythenorth> dunno if that's a grf issue
22:38:03 <andythenorth> ok maybe it just has high threshold
22:38:30 <andythenorth> I run the game on ffwd, it starts to show
22:55:30 <planetmaker> it should not show immediately, yes
22:59:14 <DorpsGek_II> [OpenTTD/OpenTTD] glx22 approved pull request #7057: Fix: A few minor compile warnings under MinGW https://git.io/fhl90
23:45:30 <peter1138> Hmm right I should either fix this patch, or go to bed.
23:47:14 <Eddi|zuHause> fix the patch from bed?
23:49:44 <peter1138> That... is not happening.
23:50:02 <peter1138> Besides I also need to consider multiplayer compatibility (none at the moment)
23:51:25 *** HerzogDeXtEr has joined #openttd
continue to next day ⏵
