IRC logs for #openttd on OFTC at 2018-10-30
⏴ go to previous day
00:37:03 *** yellyFish has joined #openttd
01:30:34 *** triolus has joined #openttd
02:13:35 *** Wormnest has joined #openttd
08:00:12 *** andythenorth has joined #openttd
09:24:38 *** glavinics has joined #openttd
10:01:10 *** glavinics has joined #openttd
10:57:48 <nielsm> an AI has managed to build two tiles that can't render
10:58:47 <ST2> I can hear the driver snoring
10:59:34 <nielsm> tiny rail depot driving out of a smaller rail depot, also driving out of a normal rail depot
11:01:29 <nielsm> this is vanilla, no newgrfs loaded
11:02:04 <peter1138> Some issue with the bit-shuffling I did, I wonder?
11:02:06 <nielsm> and neede a second player
11:02:22 <nielsm> yeah I suspect it might be something with the map array extensions done recently
11:02:25 <peter1138> Oh you're testing with a patch, not vanilla.
11:03:39 <nielsm> let's try it with the PR rebased onto current master
11:04:00 <nielsm> but well the map array is already broken in this save, of course...
11:06:06 *** matt21347 has joined #openttd
11:11:28 <nielsm> okay could dynamite those tiles just fine after using switch company cheat
11:16:41 <nielsm> just going to test the same AI on a non-patched build
11:18:16 <nielsm> yeah it keeps building broken stations
11:21:24 <nielsm> yep it looks like a bug in master
11:21:45 <DorpsGek_II> [OpenTTD/OpenTTD] nielsmh requested changes for pull request #6906: Fix #6742: Only possible to build station next to competitor by using CTRL+click https://git.io/fx51D
11:23:49 <peter1138> Is it a station tile or something else?
11:24:01 <nielsm> it's supposed to be railroad
11:24:38 <nielsm> with or without overhead wires
11:24:47 <nielsm> (the Zzz seems to be intended to be the wires)
11:29:13 <nielsm> yep same AI in 1.8.0 does not produce broken stations
11:31:30 <peter1138> Check which bits are set and what's being read for those tiles. Could be a write bug or a read bug.
11:39:49 <peter1138> In theory it's possible for a player to do it too. Same commands.
12:13:43 *** Gustavo6046 has joined #openttd
12:19:38 <nielsm> let's try out git bisect!
12:20:20 <nielsm> (and spend ages compiling and recompiling)
12:38:41 <peter1138> Why? It'll be one of two and it doesn't really matter.
12:40:16 <nielsm> found a state here where it doesn't build broken tiles, but it fails finding valid routes at all so it never builds
13:07:33 *** wodencafe has joined #openttd
14:07:49 <LordAro> narrowed it down yet?
14:09:17 <nielsm> however I just set a breakpoint in rail_cmd.cpp:484 (CmdBuildSingleRail first line inside if(flags & DC_EXEC)) and game screen looks like this when it breaked: https://0x0.st/sIsO.png
14:09:23 <nielsm> so somehow it's correct for a little bit?
14:17:32 <nielsm> huh no, it actually built this route without errors
14:27:30 <nielsm> it seems somehow m8 (railtype) gets set to 0x21 when there isn't any valid railtype with that value
14:29:36 <peter1138> So... railtype getting corrupted before writing to map, or something else modifying the map railtype later.
14:30:05 <nielsm> trying to set an assert in MakeRailNormal now
14:33:50 <nielsm> yep here is railtype==32 inside CmdBuildSingleRail
14:43:50 <nielsm> okay ScriptStorage::rail_type is set to 32
14:45:00 <peter1138> CmdBuildSingleRail should fail if the railtype is invalid.
14:45:23 <peter1138> I guess I broke that check, or it was never there?
14:46:08 <nielsm> it's supposed to validate it
14:47:53 <nielsm> right no, it's correct
14:48:07 <nielsm> but some integer width issues
14:48:28 <nielsm> question is, why does it set railtype to something invalid
14:51:45 <peter1138> If it's testing for available railtypes, then maybe it also sees 32 as being valid.
15:06:09 <nielsm> looks like explicitly selecting the HasBit template parameter at least avoids the bug
15:06:09 <nielsm> HasBit<uint64>(Company::Get(company)->avail_railtypes, railtype);
15:10:29 <peter1138> I guess I never tested this. I did test > 32 but not all cases. Damn it.
15:10:39 <peter1138> May also be compiler specific I suppose.
15:10:56 <peter1138> Need to check any other railtype HasBit occurrence :/
15:27:27 *** andythenorth has joined #openttd
15:27:31 *** andythenorth has left #openttd
15:43:37 *** TheMaster has joined #openttd
15:55:24 <DorpsGek_II> [OpenTTD/OpenTTD] nielsmh opened pull request #6952: Fix #6951: Explicitly use uint64 when testing for available railtypes https://git.io/fxdY9
15:57:50 <DorpsGek_II> [OpenTTD/OpenTTD] nielsmh opened pull request #6953: Fix: Missing m8 data in console when using Query tool https://git.io/fxdOO
16:12:22 *** WWacko1976-work has quit IRC
16:13:59 *** Wormnest has joined #openttd
16:17:14 <DorpsGek_II> [OpenTTD/OpenTTD] LordAro commented on pull request #6952: Fix #6951: Explicitly use uint64 when testing for available railtypes https://git.io/fxdsR
16:25:59 <DorpsGek_II> [OpenTTD/OpenTTD] PeterN approved pull request #6953: Fix: Missing m8 data in console when using Query tool https://git.io/fxdGo
16:33:16 <DorpsGek_II> [OpenTTD/OpenTTD] nielsmh merged pull request #6953: Fix: Missing m8 data in console when using Query tool https://git.io/fxdOO
16:35:19 <nielsm> any way to re-run the CI test that failed for non-code reasons?
16:35:41 <nielsm> (looks like it failed to connect to github or something)
16:37:22 <DorpsGek_II> [OpenTTD/OpenTTD] nielsmh updated pull request #6952: Fix #6951: Explicitly use uint64 when testing for available railtypes https://git.io/fxdY9
16:37:31 <nielsm> maybe this works... rebased it on the new master and force pushed
16:38:26 <nielsm> Error response from daemon: received unexpected HTTP status: 503 Service Unavailable
16:41:47 <peter1138> Can be rerequested within Jenkins too but I don't know who has logins on that.
16:42:37 *** frosch123 has joined #openttd
16:50:08 <LordAro> maybe jenkins is broke
17:03:42 <nielsm> well, it passed the other PR
17:14:36 <frosch123> nielsm: what is the exact problem in 6952? integer promotion?
17:14:59 <frosch123> is there some way to change HasBit instead of changing how it is called in one place?
17:15:29 <nielsm> 64 bit railtypes bitfield gets truncated to 32 bit
17:15:37 <frosch123> like replacing the "(T)1U" with "1ull" or somezhing
17:19:59 <peter1138> That'd make it 64bit for everything, no?
17:20:21 <nielsm> yeah that would make every usage of it be 64 bit
17:20:39 <frosch123> but what to do when enums are undefined
17:20:50 <frosch123> well, actually, we can also do c++1 enum classes :)
17:21:08 <frosch123> enum class RailtTypes : uint64
17:21:25 <nielsm> would def. prefer that :)
17:22:35 <nielsm> though I do wonder why RailTypes is not treated as uint64 already when the enum does have a UINT64_MAX value
17:23:03 <frosch123> yes, i also wondered that
17:23:08 <peter1138> If that fixes it then that's the correct solution. And my mistake, missing it.
17:23:14 <peter1138> Well, my mistake whatever :p
17:23:27 <nielsm> might also depend on compiler, really
17:23:33 <nielsm> I should test it on my linux machine
17:27:08 <nielsm> no bug on linux with g++ 8.2.1
17:30:37 <nielsm> ah right, there's more locations using HasBit<> with Company::avail_railtypes
17:31:04 <nielsm> not sure whether to change HasBit as frosch123 suggests
17:31:35 <frosch123> does the c++11 method work?
17:32:26 <frosch123> if it's a compiler bug, maybe (T)1ull fixes it :p
17:32:52 <frosch123> i think we had some msvc issues in the past, where it ignored types of function parameters when they were inlined
17:33:00 <nielsm> it breaks DECLARE_ENUM_AS_BIT_SET(RailTypes)
17:33:06 <peter1138> enum RailTypes : uint64
17:33:24 <nielsm> ah, enum class does not break it
17:33:45 <nielsm> enum class breaks it, enum RailTypes : uint64 seems to be acceptable
17:34:17 <frosch123> enum class adds namespace stuff, so many things need changing
17:34:20 <peter1138> "enum classes - enumerator names are local to the enum and their values do not implicitly convert to other types (like another enum or int)"
17:34:32 <peter1138> Safer if you designed it that way from the start :-)
17:37:44 <nielsm> enum RailTypes : uint64 also does fix the bug, but I'm not sure if that's legal C++03
17:38:13 <peter1138> Does it need to be?
17:38:16 <frosch123> yes, it's not, but lordaro already added c++11 stuff in other places
17:38:32 <frosch123> so, ottd is no longer c++03
17:38:55 <LordAro> and it could be easily removed :p
17:39:18 <frosch123> didn't you add tons of inline struct constructors?
17:39:21 <nielsm> so, which fix is it? change the two call sites, or change the enum type?
17:39:45 <frosch123> definitely change the num type
17:39:53 <frosch123> Railtypes is not the only 64bit enum we have
17:40:25 <frosch123> ok, CargoTypes is actually no enum
17:40:45 <frosch123> but still, having to touch every place just ask for more issues
17:41:43 <peter1138> CargoTypes is a bit weird.
17:42:00 <peter1138> It feels like it should be an enum, but there's already a separate type for it.
17:42:40 <DorpsGek_II> [OpenTTD/OpenTTD] nielsmh updated pull request #6952: Fix #6951: Explicitly use uint64 when testing for available railtypes https://git.io/fxdY9
17:43:04 <nielsm> maybe jenkins will succeed this time too
17:43:48 <frosch123> the comment is in the wrong place
17:44:07 <peter1138> It was "easier" when I did it with std::bitmask.
17:44:17 <peter1138> All the HasBits and stuff had to go.
17:45:27 <peter1138> Hmm, don't think these overshoes are going to last long, they're very tight :/
17:46:17 <DorpsGek_II> [OpenTTD/OpenTTD] nielsmh updated pull request #6952: Fix #6951: Explicitly use uint64 when testing for available railtypes https://git.io/fxdY9
17:46:41 <peter1138> I had some bigger ones once but the ankle part was way too big.
17:50:17 <peter1138> LordAro, gotta love the clock change for suddenly requiring lots of lights :/
18:01:12 <LordAro> peter1138: nice ride the other day btw, much impressive
18:29:34 *** yellyFish has joined #openttd
18:46:28 <LordAro> nielsm: have you tried with another version of VS, ooi? might be 2015 specific
18:52:08 <nielsm> I don't have any other versions at hand right now
19:33:52 *** andythenorth has joined #openttd
19:41:30 <DorpsGek_II> [OpenTTD/OpenTTD] nielsmh updated pull request #6946: Doc: More notes for developers adding new PerformanceElements https://git.io/fxHY1
19:50:26 <DorpsGek_II> [OpenTTD/OpenTTD] nielsmh updated pull request #6946: Doc: More notes for developers adding new PerformanceElements https://git.io/fxHY1
19:51:24 <DorpsGek_II> [OpenTTD/OpenTTD] nielsmh commented on pull request #6946: Doc: More notes for developers adding new PerformanceElements https://git.io/fxdS6
19:52:53 <DorpsGek_II> [OpenTTD/OpenTTD] nielsmh commented on pull request #6948: Doxygen improvements and various scan-build findings https://git.io/fxdSD
20:09:29 *** Progman has joined #openttd
20:31:02 <DorpsGek_II> [OpenTTD/OpenTTD] nielsmh updated pull request #6754: Don't automatically deactivate the vehicle clone tool after cloning a vehicle https://git.io/vp8bd
20:31:23 <nielsm> I pushed to someone else's branch
20:32:07 <DorpsGek_II> [OpenTTD/OpenTTD] nielsmh commented on pull request #6754: Don't automatically deactivate the vehicle clone tool after cloning a vehicle https://git.io/fxd5n
20:44:14 <DorpsGek_II> [OpenTTD/OpenTTD] Hemaolle updated pull request #6906: Fix #6742: Only possible to build station next to competitor by using CTRL+click https://git.io/fxddd
20:46:21 <DorpsGek_II> [OpenTTD/OpenTTD] nielsmh approved pull request #6906: Fix #6742: Only possible to build station next to competitor by using CTRL+click https://git.io/fxddj
20:48:57 <DorpsGek_II> [OpenTTD/OpenTTD] Hemaolle commented on pull request #6906: Fix #6742: Only possible to build station next to competitor by using CTRL+click https://git.io/fxdF8
20:53:28 <DorpsGek_II> [OpenTTD/OpenTTD] LordAro commented on pull request #6948: Doxygen improvements and various scan-build findings https://git.io/fxdFQ
20:54:55 <DorpsGek_II> [OpenTTD/OpenTTD] michicc approved pull request #6754: Don't automatically deactivate the vehicle clone tool after cloning a vehicle https://git.io/fxdFj
20:56:15 <DorpsGek_II> [OpenTTD/OpenTTD] LordAro commented on pull request #6948: Doxygen improvements and various scan-build findings https://git.io/fxdbk
20:56:59 <DorpsGek_II> [OpenTTD/OpenTTD] alexanderweiss commented on pull request #6754: Don't automatically deactivate the vehicle clone tool after cloning a vehicle https://git.io/fxdbY
20:58:25 <DorpsGek_II> [OpenTTD/OpenTTD] nielsmh dismissed a review for pull request #6754: Don't automatically deactivate the vehicle clone tool after cloning a vehicle https://git.io/fxdbR
21:01:44 <yellyFish> does anyone now where i can find NARS 2.51 source code? i would like to examine why is it making so many calls to var 0x61 even though it is not implemented
21:07:21 <andythenorth> much flooded Wolf01 ?
21:07:33 <andythenorth> yellyFish: just decompile it
21:09:09 <nielsm> looks like Pikka doesn't release the source for his things
21:10:16 <andythenorth> it might be in forums somewhere
21:10:23 <andythenorth> but I just decompile it
21:10:29 <andythenorth> but then it's uncommented nfo :P
21:18:34 <DorpsGek_II> [OpenTTD/OpenTTD] LordAro updated pull request #6948: Doxygen improvements and various scan-build findings https://git.io/fxHhE
21:18:55 * andythenorth can't keep up with the pull requests :P
21:19:28 <yellyFish> that means that some work is getting done :D
21:20:55 <DorpsGek_II> [OpenTTD/OpenTTD] michicc approved pull request #6952: Fix #6951: Ensure RailTypes bitfield is always treated as 64 bit https://git.io/fxdAd
21:22:38 <nielsm> did someone spill a train full of milk into the river?
21:24:06 <yellyFish> wow. valgrind + kcachegrind is p cool. it show all calls with source code and even assembly, not like i understand all of it tho :D
21:25:37 <Wolf01> This time it was the worst flood since I remember, luckily the wind changed so the sea was able to receive, or I wouldn't be here to tell it but in the cellar to drain the water
21:26:04 <LordAro> Wolf01: doesn't look so bad from that picture, it's not burst its banks yet :p
21:26:07 <yellyFish> Wolf01: does that river ever spill over?
21:26:10 <LordAro> York floods almost every year
21:26:35 <Wolf01> We raised and reinforced the banks :P
21:27:05 <Wolf01> It spilled over on the town at the left like 40 years ago
21:27:36 <yellyFish> time to deepen the river bank or something
21:28:05 <yellyFish> where i live there is also a main river that got flooded years ago
21:28:12 <Wolf01> Nah, we are near the sea, the only hope is the low tide
21:28:37 <yellyFish> or move the town ;^)
21:29:26 <yellyFish> nature really doesn't give a F about where we set houses
21:31:25 <LordAro> "look at this lovely flat land near the river, that's excellent for building houses on"
21:31:32 <LordAro> "what do you mean it's only flat because it floods a lot?"
21:32:09 <yellyFish> ChadBeaver vs VirginEnginner
21:34:52 <yellyFish> The future is gonna be like Waterworld lol
21:41:54 <yellyFish> do we have animals in the game?
21:42:24 <yellyFish> maybe add some monkeys hanging from trees in jungles
21:42:44 <nielsm> well there is the NUTS train set
21:42:56 <nielsm> and some sets have horse-drawn carriages?
21:43:40 <nielsm> (play a game with NUTS if you haven't)
21:46:31 <DorpsGek_II> [OpenTTD/OpenTTD] nielsmh merged pull request #6952: Fix #6951: Ensure RailTypes bitfield is always treated as 64 bit https://git.io/fxdY9
21:54:53 <LordAro> interestingly, the doxygen docs only mention "[in,out]", not "[inout]"
21:55:25 <LordAro> i don't know, i didn't check :p
21:56:29 <LordAro> seems inout works just fine
21:57:47 * LordAro finds some parameters to fix
22:00:37 <frosch123> i have only seen "in, out"
22:01:30 <LordAro> there are actually slightly more results for [in,out]
22:02:42 <LordAro> i can standardise, if you like
22:08:04 <LordAro> it's also 43 to 67 for "@param [..]" vs "@param[..]"
22:09:43 <frosch123> i think one of my editors only properly colored @param[]
22:09:55 <LordAro> i prefer that style too
22:18:36 <andythenorth> so close to 80% done on Horse
22:19:09 *** Wolf01 is now known as Guest1828
22:21:27 <LordAro> ...i went ahead and "fixed" all of them
22:33:10 <andythenorth> am I still using LordAro's fork of OpenTTD? :P
22:33:16 <andythenorth> with configure flags?
22:35:31 <yellyFish> what's standard way of writing multi line comma separated fields? commas end of line or at the start?
22:36:45 <LordAro> commas at the start of the line is for broken people
22:37:11 <yellyFish> D: i write it like that in haskell but don't how it is in C++
22:37:30 <LordAro> i know what i said :p
22:37:53 <LordAro> it is quite common is haskell, and basically nowhere else
22:39:11 <nielsm> I write multiline initializer lists in C++ constructors with commas (and the initial colon) aligned at the start of lines
22:42:11 <yellyFish> but the indentation D:
22:44:20 <frosch123> it is common for the same reason as why you put a comma also for the last value of an enum
22:44:39 <frosch123> to be able to extend/insert stuff without having to change another line by adding/removing a cmoma
22:45:27 <frosch123> ottd probably does not have a style for that though, too little c++ :p
22:55:16 <andythenorth> 171 trains drawn, 44 not drawn
22:55:49 <andythenorth> done by Christmas?
22:56:10 <peter1138> nielsm, thanks for sorting that issue out earlier.
22:56:20 <peter1138> Nice that it wasn't the map array being wrong though :D
22:58:41 <nielsm> the other instance of avail_railtypes being checked with HasBit was in the UI building the build railroad button dropdown
22:59:19 <nielsm> it might have caused problems down the road if someone managed to load newgrfs getting over 32 railtypes
22:59:42 <nielsm> even if I wouldn't want to see the menu that long
23:03:16 *** andythenorth has joined #openttd
23:07:56 <peter1138> I've seen it full ;)
23:08:17 <peter1138> It gets to the point where the UI enhancements would be useful.
23:08:19 <andythenorth> I have between 1 and 3 sizes for each wagon
23:08:37 <andythenorth> so they have, e.g. 'Flat Car (Small)' suffixes
23:08:46 <andythenorth> 'Flat Car (Medium)'
23:08:56 <andythenorth> what about when there's only one?
23:09:01 <andythenorth> is that small, medium, or large?
23:09:05 <andythenorth> or drop the suffix?
23:09:21 <andythenorth> it's all obviously a BAD FEATURE, but that's a given
23:11:01 <andythenorth> nah I don't know either
23:11:10 <andythenorth> I just leave it as 'small' when there's only one :P
23:12:27 <andythenorth> maybe 'small', 'medium', 'large' are stupid
23:12:40 <andythenorth> what about 'Flat Car (20t)', 'Flat Car (30t)', 'Flat Car (40t)'?
23:12:45 <andythenorth> oh, units though :(
23:18:14 *** andythenorth has left #openttd
23:19:16 <nielsm> ugh, wanted to try fluidsynth on windows, and their build system really gets in the way
23:19:34 <nielsm> cmake, and somehow it fails with a "could not find C compiler" error
23:20:05 <nielsm> (when being told to output projects for visual studio, in which you do not specify the path to your compiler)
continue to next day ⏵
