Config
Log for #openttd on 3rd April 2016:
Times are UTC Toggle Colours
00:15:29  *** Quatroking [~Quatrokin@ip226-139-211-87.adsl2.static.versatel.nl] has quit [Read error: Connection reset by peer]
00:15:45  *** FLHerne [~flh@dsl-217-155-24-22.zen.co.uk] has quit [Quit: There's a real world out here!]
00:16:53  *** Hiddenfunstuff [~Geth@y32.ip1.anvianet.fi] has quit [Quit:  HydraIRC -> http://www.hydrairc.com <- *I* use it, so it must be good!]
00:18:02  *** Eddi|zuHause [~johekr@p5B0DAE69.dip0.t-ipconnect.de] has joined #openttd
00:39:01  *** Samu [~oftc-webi@po-217-129-255-23.netvisao.pt] has quit [Quit: Page closed]
00:46:22  *** Eddi|zuHause [~johekr@p5B0DAE69.dip0.t-ipconnect.de] has quit []
00:52:27  *** Eddi|zuHause [~johekr@p5B0DAE69.dip0.t-ipconnect.de] has joined #openttd
01:03:00  *** Snail [~jacopocol@172-81-159-131.static-ip.telepacific.net] has joined #openttd
01:33:49  *** Snail [~jacopocol@172-81-159-131.static-ip.telepacific.net] has quit [Quit: Snail]
01:55:03  *** LadyHawk [~LadyHawk@5751e87a.skybroadband.com] has quit [Read error: Connection reset by peer]
01:56:29  *** LadyHawk [~LadyHawk@5751e87a.skybroadband.com] has joined #openttd
02:57:26  *** glx [~glx@000128ec.user.oftc.net] has quit [Quit: Bye]
03:24:33  *** liq3 [liq3@CPE-120-147-195-191.gdiv2.lon.bigpond.net.au] has quit []
03:51:19  *** HerzogDeXtEr1 [~farci@i59F6AE4C.versanet.de] has quit [Read error: Connection reset by peer]
03:58:16  *** Snail [~jacopocol@172-81-159-131.static-ip.telepacific.net] has joined #openttd
04:04:11  *** Snail [~jacopocol@172-81-159-131.static-ip.telepacific.net] has quit [Quit: Snail]
04:10:47  *** Ketsuban [~ketsuban@2a02:c7d:a34a:9000:35e4:4b:13e:e068] has quit [Quit: Leaving]
04:13:11  *** Snail [~jacopocol@172-81-159-131.static-ip.telepacific.net] has joined #openttd
04:17:03  *** Snail [~jacopocol@172-81-159-131.static-ip.telepacific.net] has quit []
04:21:40  *** Snail [~jacopocol@172-81-159-131.static-ip.telepacific.net] has joined #openttd
04:46:29  *** _johannes [~johannes@port-92-203-187-62.dynamic.qsc.de] has joined #openttd
05:02:55  *** Ketsuban [~ketsuban@2a02:c7d:a34a:9000:a08f:babc:787b:40e5] has joined #openttd
05:12:18  *** Snail [~jacopocol@172-81-159-131.static-ip.telepacific.net] has quit [Quit: Snail]
06:00:36  *** sla_ro|master [slamaster@89.136.141.100] has joined #openttd
06:17:21  *** Alberth [~alberth@2001:981:c6c5:1:be5f:f4ff:feac:e11] has joined #openttd
06:17:24  *** mode/#openttd [+o Alberth] by ChanServ
06:34:31  *** Arveen [~Arveen@ip-95-223-75-47.hsi16.unitymediagroup.de] has joined #openttd
06:45:31  *** Ketsuban [~ketsuban@2a02:c7d:a34a:9000:a08f:babc:787b:40e5] has quit [Quit: Leaving]
06:50:23  *** andythenorth [~Andy@host86-166-179-224.range86-166.btcentralplus.com] has joined #openttd
06:50:32  <andythenorth> o/
06:58:43  *** Progman [~progman@p57A1819B.dip0.t-ipconnect.de] has joined #openttd
07:04:51  *** andythenorth [~Andy@host86-166-179-224.range86-166.btcentralplus.com] has quit [Ping timeout: 480 seconds]
07:05:00  *** Supercheese [~Superchee@cpe-76-178-136-186.natnow.res.rr.com] has quit [Quit: Valete omnes]
07:07:47  <Alberth> moin andy
07:51:06  *** andythenorth [~Andy@host86-166-179-224.range86-166.btcentralplus.com] has joined #openttd
07:55:03  *** Hiddenfunstuff [~Geth@y32.ip1.anvianet.fi] has joined #openttd
07:57:04  *** Wolf01 [~wolf01@0001288e.user.oftc.net] has joined #openttd
07:57:37  <Wolf01> o/
08:03:02  <Alberth> hi hi
08:08:45  <_johannes> Can there be trains that are engines but have unit number 0 ?
08:10:35  <_johannes> ah, if the train has multiple engines, the others can have id 0
08:27:59  *** sla_ro|master [slamaster@89.136.141.100] has quit []
08:35:00  *** Clockworker_ [~Clockwork@189-10-213-131.paemt701.dsl.brasiltelecom.net.br] has joined #openttd
08:42:20  <andythenorth> stupid alumninium plant
08:42:23  <andythenorth> is unbalanced
08:42:34  *** Clockworker__ [~Clockwork@189-10-213-131.paemt701.dsl.brasiltelecom.net.br] has quit [Ping timeout: 480 seconds]
08:43:06  <andythenorth> :D
09:00:12  <Alberth> add more buildings :p
09:04:17  <Wolf01> o/
09:06:04  <Wolf01> lol andy, I got 300 more vip points as excuse reward because I just asked why the inversion switch was removed from the power functions switch
09:06:33  <Wolf01> official answer " The version of the LPF Control switch with the control direction switch on is discontinued and replaced by a newer version without this switch. The reason for removing the switch in the newer version is that it was not used often and had quite a cost overhead"
09:06:46  *** andythenorth [~Andy@host86-166-179-224.range86-166.btcentralplus.com] has quit [Ping timeout: 480 seconds]
09:06:59  <Wolf01> ;_; andy
09:20:46  *** frosch123 [~frosch@00013ce7.user.oftc.net] has joined #openttd
09:21:02  *** MonkeyDrone [~Monkey@84.255.150.202] has joined #openttd
09:28:25  *** Quatroking [~Quatrokin@ip226-139-211-87.adsl2.static.versatel.nl] has joined #openttd
09:31:34  *** ConductCat [~Conductor@pool-108-56-8-121.washdc.east.verizon.net] has joined #openttd
09:38:21  *** ConductorCat [~Conductor@pool-108-56-8-121.washdc.east.verizon.net] has quit [Ping timeout: 480 seconds]
09:53:04  *** andythenorth [~Andy@host86-166-179-224.range86-166.btcentralplus.com] has joined #openttd
09:54:05  <andythenorth> ho
09:54:13  * andythenorth ‘won’ Silicon Valley in 42 years
09:54:17  <andythenorth> just missed bronze :P
09:59:21  *** tokai|noir [~tokai@00012860.user.oftc.net] has joined #openttd
09:59:24  *** mode/#openttd [+v tokai|noir] by ChanServ
10:00:37  <frosch123> cookies are the best, you can eat them :)
10:01:13  <andythenorth> so I need to get subtype into GetTileTrackStatus_Road
10:01:27  <andythenorth> seems stuffing submode parameter is better than adding another parameter?
10:01:36  <frosch123> definitely :)
10:01:46  <frosch123> because it is shared with rail and ship
10:01:51  <andythenorth> hmm
10:02:24  <frosch123> you could change all of them into a struct ofc
10:03:01  <andythenorth> that’s just words to me right now :D
10:03:16  <andythenorth> not sure if I patch veh.compatible_roadtypes (probably not)
10:03:29  <andythenorth> or find all places RVs call GetTileTrackStatus
10:03:33  <andythenorth> and patch those calls
10:03:56  <andythenorth> seems more like the latter
10:06:03  <frosch123> i think you already patched all of them :p
10:06:19  *** tokai [~tokai@00012860.user.oftc.net] has quit [Ping timeout: 480 seconds]
10:07:12  <andythenorth> nah, not yapf and npf ones yet
10:07:32  <andythenorth> nor overtaking :x
10:11:14  <andythenorth> hmm only 22 uses of compatible_roadtypes
10:11:24  <andythenorth> can I stuff that and leave all the other things alone? o_O
10:11:53  *** Wormnest [~Wormnest@s5596abd2.adsl.online.nl] has joined #openttd
10:11:55  <andythenorth> compatibility is a union of mode (tram / road) and subtype
10:12:07  <andythenorth> unrelated, ROADTYPE would be better renamed MODE or so :P
10:25:33  <frosch123> if you add some INVALID roadtype and tramtype, you likely do not need the RoadTypes in the submode
10:29:12  *** Nathan1852 [~Nathan185@HSI-KBW-134-3-201-222.hsi14.kabel-badenwuerttemberg.de] has joined #openttd
10:35:25  *** Defaultti [defaultti@lakka.kapsi.fi] has quit [Quit: Quitting.]
10:36:49  *** Defaultti [defaultti@lakka.kapsi.fi] has joined #openttd
10:41:01  <andythenorth> hmm
10:41:13  <andythenorth> don’t I need them to get the right set of track bits?
10:42:17  <frosch123> TypeError: endswith first arg must be bytes or a tuple of bytes, not str <- i don't get that
10:42:41  <frosch123>  changes = [w[3:] for w in changes if w.endswith(file_ext)] <- what is the first arg? "w" or "file_ext"?
10:45:33  <Alberth> w
10:45:45  <Alberth> x.f(y)  <-->  f(x, y)
10:45:58  <frosch123> to my understanding both "w" and "file_ext" should be strings
10:48:04  <frosch123> i may need to add a "universal_newlines=True" to subprocess.check_output
10:48:24  <Eddi|zuHause> the "first argument" of "x.blah(y)" is "x"
10:48:42  <andythenorth> is w bytes or string
10:48:54  <Alberth> you do,  check_output  has weird semantics for text-files if you don't provide that
10:49:03  <Eddi|zuHause> but that error makes not a lot of sense
10:49:16  <andythenorth> bytes.endswith() somehow?
10:49:24  <Alberth> I think it gets confused on a weird combination of bytes and str
10:50:08  <Eddi|zuHause> what if you try "str(w).endswith(...)"?
10:57:36  <frosch123> universal_newlines fixed it
10:57:49  *** Samu [~oftc-webi@po-217-129-255-23.netvisao.pt] has joined #openttd
10:58:47  <frosch123> https://dev.openttdcoop.org/projects/openttd-android-translate/repository/diff?utf8=%E2%9C%93&rev=b01fc7c7abd2b143a63d20ef3122dc533778db39&rev_to=6cf248be5eae8a175a8285eb463715129d46fada <- eints' first git commit :)
11:00:50  <Eddi|zuHause> so that's a "it works \o/"?
11:01:29  <frosch123> i guess so
11:01:43  <frosch123> i just learned about ssh ControlMaster though, so maybe i can speed up eints scritps a lot
11:08:26  <frosch123> hmm, it slowed it down from 30s to 160s?
11:08:33  <frosch123> what :p
11:11:34  <andythenorth> biddle bobble
11:15:39  <andythenorth> compatible_roadtypes returns RoadTypes not RoadType?
11:15:50  * andythenorth assumes from reading it
11:21:18  <andythenorth> but RoadTypeToRoadTypes takes just one roadtype
11:21:22  * andythenorth confused
11:28:20  <frosch123> compatible_roadtypes makes little sense with your patch
11:28:43  <frosch123> you define compatiblity on subtype level, while road and tram are always separate
11:32:03  <andythenorth> so I can replace it
11:32:28  <andythenorth> but I need to preserve the bits for is road / is tram
11:34:40  <andythenorth> hmm if there are no compatible subtypes on the tile, that’s equivalent to ROADTYPES_NONE
11:35:20  <andythenorth> frosch123: so INVALID might be a subtype for each of roadtype and tramtype?
11:35:25  <andythenorth> 0 or so
11:36:40  <frosch123> usually 0xFF
11:43:33  *** andythenorth is now known as Guest10197
11:43:43  *** andythenorth [~Andy@host86-166-179-224.range86-166.btcentralplus.com] has joined #openttd
11:44:39  <andythenorth> seems like I could patch compatible_roadtypes
11:44:54  <andythenorth> and return 1st bit as bool, road/tram, and then the subtype bits
11:45:02  <andythenorth> and that would be enough
11:45:15  <andythenorth> and for places that are looking only at road/tram, it’s a trivial fix
11:46:43  *** Guest10197 [~Andy@host86-166-179-224.range86-166.btcentralplus.com] has quit [Ping timeout: 480 seconds]
11:47:18  <andythenorth> but RoadType and RoadTypes are enums, so now I am lost :D
11:47:34  <andythenorth> I know an enum is just a list, but how do I bitstuff that?
11:49:43  <Alberth> ?
11:50:52  <andythenorth> exactly :|
11:51:21  <Alberth> /me is mostly confused about "enum is a list" :)
11:51:59  <Alberth> but looking at the source, RoadType is a single roadtype, each with a number (0=road, 1=tram)
11:52:11  <Alberth> RoadTypes is the bitset already
11:52:14  *** liq3 [liq3@CPE-120-147-195-191.gdiv2.lon.bigpond.net.au] has joined #openttd
11:53:11  <Alberth> roadtypes_road is the bitset with only road,  roadtypes_tram is the bitset with only tram, and roadtypes_all is the bitset with both road and tram
11:53:13  <andythenorth> I need to patch v->compatible_roadtypes
11:53:20  <andythenorth> which expects RoadTypeToRoadTypes
11:53:51  <andythenorth> which returns RoadTypes
11:54:18  <Alberth> ok
11:54:31  <andythenorth> not sure how I extend RoadTypes :)
11:54:46  <andythenorth> I want the first bit to be the roadtype, and the remaining bits to be the subtype
11:55:04  <andythenorth> ach, maybe I just don’t use RoadTypes
11:55:35  <Alberth> roadtypes has 2 bits now, 1 for road and 1 for tram
11:55:57  <Alberth> ie 4 possible values (nothing, only road, only tram, or both)
11:56:28  <Alberth> lots of aren't used yet, there :p
11:56:36  <Alberth> +bits
11:57:02  <Alberth> but maybe code expects only 2 bits always, which must be verified
11:57:13  <Alberth> and/or fixed
11:57:35  * andythenorth tries to understand
11:57:44  <andythenorth> when working with tiles, the RoadTypes structure makes sense
11:57:56  <andythenorth> but when working with vehicles, there can only be one roadtype
11:58:04  <andythenorth> this extensible structure is a dead end
11:58:17  <andythenorth> maybe
11:59:11  <andythenorth> road or tram is just a single bit
12:00:10  <Alberth> you can use a bitset with 1 bit set (ie  only road or only tram), or you can use a RoadType value
12:00:49  <andythenorth> can I pack the subtype bits into RoadTypes as well?
12:01:25  <Alberth> you can add a new field for the subtype
12:01:55  <Alberth> but existing code doesn't expect extra bits
12:02:23  <Alberth> so you need a masking function to pull just the current bitset out, and apply that everywhere
12:02:37  <Alberth> or at least check things don't break if you don't
12:02:43  <andythenorth> seems most efficient to change what compatible_roadtypes is doing
12:02:48  <andythenorth> and stop returning RoadTypes from it
12:02:59  <andythenorth> and instead return a bitset containing what I need
12:03:58  <Alberth> you can also make another bitset, but then we'll have 3 sets for road and tram :p
12:04:36  * andythenorth has brain ache :)
12:12:40  <Wolf01> if you want I can give you more :)
12:13:05  * Wolf01 waits another "connection reset by pear"
12:13:14  <Wolf01> or by beer
12:13:23  <Wolf01> sure is not peer
12:14:28  <Alberth> we'll wait for the message and see :p
12:15:07  <Wolf01> andythenorth: I've got an official response from lego about the new pf switch without the inversion switch, it's just to reduce the costs
12:15:55  <Wolf01> also I've got 300 more vip points because I only asked why they decided to change this
12:16:43  <Alberth> ask more questions :)
12:16:47  <Samu> I finally got what the hell is wrong with my research! 3 variables that I got to work with: slopes, edges and corners
12:17:25  <Samu> I was working with the slopes and corners the wrong way
12:17:54  <Wolf01> is there a right way to work with slopes and corners?
12:18:15  <Wolf01> (+5 points to griffindor)
12:18:40  <Samu> if I am seeing this right, the edge_offset has to be split into edge_offset and corner_offset
12:19:07  <Alberth> recursive splitting!
12:19:35  *** andythenorth [~Andy@host86-166-179-224.range86-166.btcentralplus.com] has quit [Quit: andythenorth]
12:19:39  <Samu> it's hard to find what to do, but I'm getting somewhere
12:20:48  *** andythenorth [~Andy@host86-166-179-224.range86-166.btcentralplus.com] has joined #openttd
12:24:13  *** gelignite [~gelignite@x4e3033df.dyn.telefonica.de] has joined #openttd
12:24:24  <andythenorth> meh
12:24:55  <andythenorth> function_name(my_param = {tram_flag: False, subtype: 0})
12:25:01  <andythenorth> is all I want to do, but in C++
12:25:53  <Alberth> :)
12:26:18  <Alberth> where do you want that dictionary?
12:26:48  <andythenorth> in place of compatible_roadtypes
12:26:53  <Alberth> (probably not as dictionary, but in an enum or so?
12:27:27  *** HerzogDeXtEr [~farci@i59F6AE4C.versanet.de] has joined #openttd
12:27:46  <Alberth> RoadTypes compatible_roadtypes;    <-- change that type?
12:28:06  <andythenorth> I think so
12:28:16  <andythenorth> can I just use a uint and shift it? :P
12:28:41  *** MonkeyDrone [~Monkey@84.255.150.202] has quit [Read error: Connection reset by peer]
12:29:12  <Alberth> hmm, field name would be wrong too, I guess
12:34:12  <andythenorth> the places that consume compatible_roadtypes are just looking for a bit currently
12:34:20  <andythenorth> seems over-engineered :)
12:36:29  * andythenorth biab
12:36:30  *** andythenorth [~Andy@host86-166-179-224.range86-166.btcentralplus.com] has quit [Quit: andythenorth]
12:58:52  *** MonkeyDrone [~MonkDAce@80.88.255.40] has joined #openttd
12:59:34  *** FLHerne [~flh@dsl-217-155-24-22.zen.co.uk] has joined #openttd
13:04:56  <Eddi|zuHause> Wolf01: the best one i've seen yet is "Peer Gynt"
13:07:56  <Wolf01> hah poor guy :D
13:10:15  <Wolf01> I've never read that poem, but I think I've had it on my school book
13:11:05  <Eddi|zuHause> i only know the music...
13:16:49  <Wolf01> Yeah, the music is famous
13:23:49  <Wolf01> bah, I'm tired of making lego pantographs... need something else to do
13:27:23  *** norro_ [~quassel@vm-1-2.k023.de] has quit [Quit: http://quassel-irc.org - Chat comfortably. Anywhere.]
13:27:25  *** norro [~quassel@vm-1-2.k023.de] has joined #openttd
13:31:34  <Eddi|zuHause> get me a replacement pantograph for an old E69 model (in H0)
13:38:11  *** FLHerne [~flh@dsl-217-155-24-22.zen.co.uk] has quit [Read error: No route to host]
13:38:14  *** FLHerne [~flh@dsl-217-155-24-22.zen.co.uk] has joined #openttd
13:41:59  *** norro [~quassel@vm-1-2.k023.de] has quit [Remote host closed the connection]
13:42:03  *** norro [~quassel@vm-1-2.k023.de] has joined #openttd
13:42:16  *** norro [~quassel@vm-1-2.k023.de] has quit [Remote host closed the connection]
13:42:16  *** norro [~quassel@vm-1-2.k023.de] has joined #openttd
14:08:30  *** norro [~quassel@vm-1-2.k023.de] has quit [Remote host closed the connection]
14:16:04  *** Eddi|zuHause [~johekr@p5B0DAE69.dip0.t-ipconnect.de] has quit []
14:23:30  *** Eddi|zuHause [~johekr@p5B0DAE69.dip0.t-ipconnect.de] has joined #openttd
14:28:44  *** Eddi|zuHause [~johekr@p5B0DAE69.dip0.t-ipconnect.de] has quit []
14:30:04  *** Eddi|zuHause [~johekr@p5B0DAE69.dip0.t-ipconnect.de] has joined #openttd
14:47:40  *** andythenorth [~Andy@host86-166-179-224.range86-166.btcentralplus.com] has joined #openttd
14:51:31  <Alberth> https://paste.openttdcoop.org/p3rj9kpfy   hi hi, random-ish attempt to make an extended RT version, for inspiration :)
14:52:47  <Wolf01> :thumb_up:
14:53:41  * andythenorth is going to have to learn what an enum actually is
14:53:46  <andythenorth> google knows
14:56:01  * andythenorth needs a better google
14:56:09  <Wolf01> ask here
14:57:21  <andythenorth> it looks like a dumb class
14:57:35  * andythenorth struggling to see the purpose
14:59:11  <Alberth> enum does 2 things
14:59:33  <Alberth> 1:  introduce names for magic numbers
14:59:58  <Alberth> sort of const, but scales better for bigger amounts of constants
15:00:20  <andythenorth> this guide starts to make sense http://www.learncpp.com/cpp-tutorial/45-enumerated-types/
15:00:42  <Alberth> 2: Introduce a type, so names are grouped under an umbrella
15:01:02  <andythenorth> is it odd to keep unrelated things in same enum?
15:01:05  * andythenorth assumes so
15:01:40  <Alberth> it is
15:01:56  <Alberth> hmm, negative numbers aren't actually allowed in an enum
15:03:54  <andythenorth> ok, so it makes sense to be able to write code using ROADTYPE_TRAM
15:04:14  <andythenorth> rather than checking a specific bit is 1 in 19 places
15:05:28  <andythenorth> so  ROAD_FOO_ROAD = 1 << ROADTYPE_ROAD
15:05:32  <andythenorth> is shifting by 0 or 1?
15:05:33  <Alberth> yep, it helps a lot, I'd say
15:06:03  <Alberth> don't understand the 0/1 question
15:06:19  <Alberth> lowest bit is numbered 0
15:06:49  <Alberth> 1 == (1 << 0)
15:07:12  <Alberth> 1 == 2**0
15:08:59  <andythenorth> trying to understand what RoadFoo does :)
15:09:50  <andythenorth> seems the subtypes would need to be in an enum for sanity
15:11:10  <Alberth> yup, uint8 is a bit blunt :p
15:11:35  <Alberth> you also likely don't have 256 subtypes
15:11:38  <andythenorth> no
15:11:43  <andythenorth> but there are two types of subtype
15:11:45  <andythenorth> tram and road
15:12:01  <Alberth> and you can have both at the same time?
15:12:04  <andythenorth> yes
15:12:17  <andythenorth> tram and road are completely independent, they happen to occupy same tile
15:12:49  <Alberth> make a "no road" sub-type, and a "no-tram" sub-type, and the road and tram bits can be removed
15:13:03  <Alberth> (lack of tram bit == "no-tram" sub-type)
15:13:30  <Eddi|zuHause> andythenorth: maybe you should further separate them in the code. so you have one data type TramType and one RoadType
15:13:35  <Alberth> so you only have road sub-type and tram sub-type
15:13:49  <Eddi|zuHause> then you don't have to fiddle with weird orthogonal combinations
15:13:57  <Eddi|zuHause> every tile gets a roadtype and a tramtype
15:14:06  <Alberth> +1
15:14:19  <andythenorth> that seems counter-intuitive to me, having read the code a lot :)
15:14:34  <andythenorth> RoadType is only used to distinguish between road and tram
15:14:49  <andythenorth> if they’re split, what do you use to distinguish them?
15:15:04  <Eddi|zuHause> what i named "roadtype" here would be the subtype
15:15:20  <andythenorth> i.e. there is much code of the type (ROADTYPE_ROAD ? 1 : 0)
15:15:34  <andythenorth> which is then used for RV or tram bits, movement code, drawing etc
15:16:15  <andythenorth> I considered splitting them, but it would mean copying all the functions redundantly, afaict
15:16:19  <andythenorth> much more legible though
15:16:20  <Eddi|zuHause> you could also replace all those by (IsRoadSubtype(subtype)?1:0)
15:16:39  <Eddi|zuHause> then have all subtypes as either a road or a tram type (defined by newgrf)
15:16:44  <andythenorth> that would be appealing, but it needs some way to map subtypes back to road or tram
15:16:53  <andythenorth> which I can’t conceive how to do
15:16:57  <Eddi|zuHause> then you have 16 subtypes, which the newgrf can divide up as it wishes
15:17:55  <andythenorth> yes
15:20:47  <andythenorth> all of the is beyond me right now tbh
15:21:09  <Eddi|zuHause> this is usually the point where you stop coding and start planning
15:21:41  <andythenorth> I think I have enough prototype thrown at the wall
15:22:08  <andythenorth> but I would like to get rid of current compatible_roadtypes use before I stop
15:22:24  <andythenorth> I don’t really understand it, nor what breaks if it is changed
15:22:37  <Eddi|zuHause> i can't help you with that
15:22:46  <andythenorth> nah
15:22:58  <andythenorth> I’ve set it to 0
15:23:06  <andythenorth> for stupidity, and now I need to find how it’s used
15:23:55  <andythenorth> maybe 1 is better
15:24:07  <andythenorth> ROADTYPE_ROAD seems to be 0 sometimes, and 1 other times
15:26:57  <andythenorth> yeah ok, changing current use of compatible_roadtypes breaks a bunch of stuff
15:27:17  <andythenorth> it relies on checking multiple bits to detect if vehicle is road or tram
15:27:33  <andythenorth> moving that to a flag in one bit doesn’t work
15:32:25  <andythenorth> the simplest thing would be simply to add a subtype parameter to all the get_tile_track_status_proc functions
15:32:31  <andythenorth> but that seems like total string
15:38:56  *** Ketsuban [~ketsuban@2a02:c7d:a34a:9000:1191:95f8:c397:ed86] has joined #openttd
15:39:05  *** andythenorth [~Andy@host86-166-179-224.range86-166.btcentralplus.com] has left #openttd []
15:49:42  *** andythenorth [~Andy@host86-166-179-224.range86-166.btcentralplus.com] has joined #openttd
15:49:53  <andythenorth> how do I count how many bits an enum uses?
15:51:12  <andythenorth> stack overflow says I shouldn’t try, it’s not safe
15:51:16  <andythenorth> but I need to know
15:52:38  <Alberth> at value level, or memory storage level (ie how many bytes the compiler gave the type)
15:53:08  <andythenorth> specifically I need to know how big compatible_roadtypes is
15:53:09  <Alberth> at value level, find the biggest number of the enum, and how many bits that number needs
15:53:14  <andythenorth> so I can shift some other bits alongside it
15:53:46  <andythenorth> that will be value level
15:54:19  <andythenorth> highest value is 255?
15:54:28  <Alberth> biggest number is 0xff (INVALID_ROADTYPES), ie 8 bits
15:55:05  <andythenorth> thanks
15:55:43  <andythenorth> frosch gave me the method to implement this specific part of the patch yesterday btw, but until I understand why, I understand nothing much :)
15:55:50  <andythenorth> and as yet, I understand nothing much :P
15:55:57  <Alberth> :)
15:56:09  <Alberth> that's where it always starts
15:56:37  <Alberth> exploding into nice generic solution also always happens :p
15:56:51  <andythenorth> it now makes sense why the sub_mode parameter to GetTileTrackStatus_Road should be “road_types | road_subtype << 8 | tram_subtype << 16"
15:57:16  <Alberth> needs parentheses
15:57:30  <andythenorth> yup :)
15:57:46  <andythenorth> only needs to be added in 11 places :P
15:57:59  <Samu> I could composite the edges of river tiles on slopes, but I have bad news :( the green color combinations of the edge stripes won't match... different greens
15:58:10  <Samu> what to do?
15:58:37  <Samu> need more greens!
15:58:49  <andythenorth> nah, it must be possible
15:59:03  <andythenorth> I drew the current river sprites, I was not short of greens
15:59:29  <Alberth> blues were a bigger problem I guess :p
15:59:33  <Samu> the stripes are aligned, but the scolors doesn't really look good
15:59:37  <Samu> colors*
15:59:39  <andythenorth> screenshot?
15:59:53  <Alberth> what's the value of road_subtype if road_types has no road bit?
16:00:00  <andythenorth> meaningless
16:00:06  <andythenorth> it defaults to 0
16:00:41  <andythenorth> currently I wouldn’t bother trying to read it anywhere, I’d check the road bit first
16:00:51  <Alberth> if you redefine 0 as "no road" you don't need the road bit of road_types
16:00:58  <Alberth> and similarly for tram bit
16:00:59  <andythenorth> yes
16:01:51  <andythenorth> lots of places use it, I think it’s a refactoring goal rather than a prototype
16:02:04  * andythenorth should write a spec and plan
16:02:17  <Alberth> fair enough
16:03:02  <andythenorth> hmm Arctic Basic is as popular as cold sick apparently
16:03:14  <andythenorth> can’t win em all :(
16:03:55  <Samu> http://i.imgur.com/9GcNZIC.png
16:04:07  <Samu> i still dont have the water sprite
16:04:26  <Samu> and i didn't align corners yet
16:04:46  <andythenorth> what’s the problem with greens? o_O
16:04:48  <Samu> but the NE edge vs NW edge... the colors
16:04:59  <Alberth> ugh, "it is not realistic -> not good"  :(
16:05:01  <Samu> the different greens
16:05:14  <andythenorth> it’s not lit correctly
16:05:20  <andythenorth> the greens are available in the palette
16:05:35  <andythenorth> don’t worry about that too much at that moment, as long as you have the right pieces
16:05:46  *** Snail [~jacopocol@172-81-159-131.static-ip.telepacific.net] has joined #openttd
16:05:54  <andythenorth> if I was doing this, I’d actually draw pink / red / yellow / blue sprites, to avoid looking too much at the appearance
16:06:06  <andythenorth> and instead focus on getting the right sprite in the right place :)
16:06:58  <Samu> speaking of corners
16:07:06  <andythenorth> Alberth: I can’t see past the antagonistic stuff about car industries :P
16:07:10  <Samu> I don't have a N corner sprite :(
16:07:42  <Samu> well I have many N corner sprites, but not one that aligns well given those 2 edges configurations
16:07:44  <andythenorth> I’m not nationalistic, but UK car industry is ~same size as France, bigger than Italy.  Provocative assertions, based on wrong facts :|
16:08:01  <andythenorth> Samu: the sprites you need likely don’t exist yet
16:08:19  <andythenorth> if you try and composite existing riverbank sprites you’ll get the effect in the screenshot :)
16:08:43  <Alberth> it's arctic -> greenland -> has no car industries -> wrong
16:09:09  <andythenorth> they’re factually correct, maybe I just remove ‘inspired by’ :P
16:09:15  <Alberth> while in my view, it's good to have something different than the ever coal / wood thingies
16:09:40  <andythenorth> indeed :)
16:10:21  <andythenorth> so if road / tram bits went away and instead subtype 0 was “TRAM_NONE” or similar
16:10:22  <andythenorth> inline bool IsTram() { return IsRoadTT() && HasBit(RoadVehicle::From(m_veh)->compatible_roadtypes, ROADTYPE_TRAM); }
16:10:23  *** NGC3982 is now known as NGC1
16:10:25  <andythenorth> would be simpler no?
16:11:30  <Alberth> it would, less duplication of state, so simpler to manage. however I can see the point of making it work first
16:11:33  <Eddi|zuHause> that doesn't make a lot of sense
16:12:23  <andythenorth> Eddi|zuHause: as it currently exists?
16:12:26  <andythenorth> or my proposal?
16:12:40  <Eddi|zuHause> the "TRAM_NONE" thing
16:13:00  <andythenorth> does it make sense to drop the road / tram bits?
16:13:15  <Eddi|zuHause> "compatible_roadtypes" should probably be replaced by something derived from the newgrf, like for railtypes
16:13:55  <andythenorth> I don’t understand that tbh
16:14:14  <andythenorth> newgrf can’t change the definitions of ROADTYPE_ROAD and ROADTYPE_TRAM
16:14:26  <andythenorth> that’s well out of scope
16:14:36  <Eddi|zuHause> yes, but they can add more, that are either compatible to ROAD, TRAM or neither
16:14:42  <andythenorth> no they can’t
16:14:50  <andythenorth> well, not the way I’m planning to do it
16:14:52  <Eddi|zuHause> but they should become able to
16:14:55  <andythenorth> that’s a whole other ball game
16:15:17  <Eddi|zuHause> then i don't understand what you're trying to achieve
16:15:30  <andythenorth> why add more types?
16:16:01  <Eddi|zuHause> narrow gauge trams, broad gauge trams, subways, trails, whatever
16:16:12  <andythenorth> yes but that’s not what ROADTYPE does
16:16:37  <Eddi|zuHause> but maybe that's what it should do?
16:16:46  <andythenorth> I don’t see anyone ever achieving that tbh
16:16:50  <andythenorth> nobody has wanted to so far
16:17:39  <andythenorth> seems better to just stick with ROADTYPE_ROAD and ROADTYPE_TRAM as they exist
16:18:14  <Eddi|zuHause> so then what's the difference between tram subtypes?
16:19:04  <Eddi|zuHause> and why bother adding tram subtypes if you can't make them incompatible?
16:19:07  * andythenorth wonders about ROADTYPE_SUBWAY now
16:19:47  <andythenorth> doesn’t need drawing
16:19:55  <andythenorth> nothing to patch in the drawing functions...
16:20:00  <Wolf01> I have that feeling like "I should offer my help"
16:20:25  <Eddi|zuHause> you probably should cast that subway thought aside very quickly
16:20:37  <Eddi|zuHause> "subway" should simply be a tram built underground
16:20:46  <andythenorth> if I leave RoadTypes untouched, then it’s plausible that $someone can come along and add more types in future
16:21:20  * andythenorth wonders if that can be done whilst still eliminating the 2 road/tram bits
16:21:25  <Eddi|zuHause> the point was that you don't think about what types to add, but the newgrf does
16:21:32  <sim-al2> I don't know if roads can hide vehicles somehow, but subway probably wouldn't work if you can't
16:21:49  <andythenorth> just don’t draw them :)
16:22:00  <sim-al2> Ok fair enough
16:22:03  <Eddi|zuHause> sim-al2: there is a "fake subway" grf
16:22:22  <Wolf01> I also want highways
16:22:36  <andythenorth> ‘want’ :P
16:22:47  <andythenorth> my 6 year old wants ‘faster roads that cost more'
16:22:49  <Eddi|zuHause> Wolf01: that's easy, just implement objects with state machines
16:23:01  <andythenorth> I explained that speed is set by vehicle not road :P
16:23:04  <andythenorth> he still wants them
16:23:12  <Eddi|zuHause> andythenorth: i'd call that a "highway" :p
16:23:22  <Wolf01> eddi: like I never tried
16:24:20  <andythenorth> what do I rename compatible_roadtypes to if it contains both RoadTypes (first 8 bits) and subtypes (next 8 bits)
16:24:28  <Eddi|zuHause> Wolf01: well, it's done in 3 easy steps: 1) implement state machines for airports. 2) extend state machines for articulated vehicles. 3) add state machines to road stations and objects
16:24:30  <sim-al2> A roadtype with concrete barriers or guardrails might look close enough
16:24:51  <Wolf01> "easy"
16:24:55  <andythenorth> hmm I don’t know how to make the code non-specific to tram / road
16:25:08  <andythenorth> Eddi|zuHause: all the tram code is specific to trams, how would newgrf redefine that?
16:25:20  <andythenorth> or add it’s own movement code for new roadtypes?
16:25:30  * andythenorth can’t see it
16:25:31  <Eddi|zuHause> andythenorth: with a property flag "this behaves like a tram"
16:25:40  <andythenorth> but that’s still tied to trams
16:25:51  <Eddi|zuHause> andythenorth: look at how maglev is treated differently for rails (acceleration model)
16:26:03  <andythenorth> yes, but how to add arbitrary types?
16:26:20  <Eddi|zuHause> andythenorth: just reserve the bits, let the newgrf fill them with meaning
16:26:51  <andythenorth> still has to resolve to road or tram though?
16:26:58  * andythenorth is confused
16:27:21  <Eddi|zuHause> yes. every newgrf-defined type will have a flag "behaves like tram" set or unset
16:27:34  <Alberth> think so, or you cannot have a road and a tram at a single tile
16:27:51  <Eddi|zuHause> so every "roadtype == ROADTYPE_TRAM" will become "hasroadtypetramflagset(roadtype)"
16:29:01  <andythenorth> that is more pleasing tbh
16:29:24  *** HerzogDeXtEr1 [~farci@i59F6C8F2.versanet.de] has joined #openttd
16:30:11  <andythenorth> the current implementation has the overhead of unused extensibility, whilst not delivering much that can be built on for subtypes :)
16:32:53  <frosch123> andythenorth: don't listen to eddi :)
16:33:10  <frosch123> you made a spec with separate roadtypes and tramtypes
16:33:29  <frosch123> don't start over :p
16:33:46  <andythenorth> I am not sure if I have understood Eddi|zuHause or not :)
16:34:02  <frosch123> nah, eddi is just adding bs
16:34:04  <andythenorth> either he has a completely different idea, or he’s just filling in the gaps on how to implement subtypes
16:34:18  <Eddi|zuHause> i likely have 3 different different ideas
16:34:21  <andythenorth> all this roadtype == foo stuff in current code is
unhelpful :P
16:34:23  <frosch123> i doubt he even followed the earlier discussion
16:34:28  <Wolf01> why 2 specs for the same thing?
16:34:44  *** HerzogDeXtEr [~farci@i59F6AE4C.versanet.de] has quit [Ping timeout: 480 seconds]
16:35:09  <Eddi|zuHause> but what i said about refactoring the == into a function call is independent from my ideas
16:35:13  <andythenorth> yes
16:35:14  *** Clockworker_ [~Clockwork@189-10-213-131.paemt701.dsl.brasiltelecom.net.br] has quit [Read error: Connection reset by peer]
16:35:16  <andythenorth> that seemed useful
16:35:18  <andythenorth> anyway, I am stuck on GetTileTrackStatus_Road
16:35:37  *** Clockworker_ [~Clockwork@189-10-213-131.paemt701.dsl.brasiltelecom.net.br] has joined #openttd
16:35:38  <andythenorth> I only have one parameter for sub_mode, and I don’t have the vehicle in scope in that function
16:35:49  <andythenorth> so I can’t get the subtype from the vehicle, unless I stuff it into sub_mode
16:36:02  <andythenorth> that means changing 11 callers, adding an ugly || to each
16:36:17  <Eddi|zuHause> add a parameter?
16:36:17  <andythenorth> or I change the meaning of compatible_roadtypes, and fix a few places that expect the old meaning
16:36:34  <andythenorth> adding a parameter means changing 13 tile functions, almost totally unrelated to roads
16:36:35  <Eddi|zuHause> i really don't know what that function is doing
16:37:12  <andythenorth> ^ this exposes that compatible_roadtypes is nearly useless for a subtype-based idea, and could be refactored away
16:38:01  <andythenorth> I was hoping I could get rid of RoadTypes entirely, and the associated road / tram bits, and rely on the subtype bits
16:38:07  * andythenorth can’t eat that elephant in one go :(