IRC logs for #openttd on OFTC at 2018-05-13
⏴ go to previous day
00:12:20 *** chomwitt has joined #openttd
00:41:16 *** supermop has joined #openttd
00:52:05 *** Supercheese has joined #openttd
01:18:49 *** snail_UES_ has joined #openttd
01:25:11 *** Thedarkb-X40 has joined #openttd
04:34:49 *** muffindrake1 has joined #openttd
05:22:15 *** Supercheese has joined #openttd
05:51:40 *** sim-al2 is now known as Guest2552
05:51:41 *** sim-al2 has joined #openttd
06:06:38 *** sim-al2 has joined #openttd
06:12:51 *** cr1t1cal has joined #openttd
06:13:04 <cr1t1cal> does anyone want to play a game of openttd?
08:23:31 *** sla_ro|master has joined #openttd
09:13:40 *** Progman has joined #openttd
09:14:39 *** andythenorth has joined #openttd
09:31:21 *** Alberth has joined #openttd
09:31:21 *** ChanServ sets mode: +o Alberth
09:37:46 *** ChanServ sets mode: +v tokai
09:52:23 *** Supercheese has joined #openttd
10:16:51 <Pikka> not much sup... heading out in a minute
10:28:54 <Eddi|zuHause> something feels wrong about the 32 types debate...
10:30:53 <Eddi|zuHause> ok, the reason why they request more than 16 is that you run out with combinatoric explosion, but that means with 32 you get pretty much the same problem pretty much immediately, as it is just one single step in the combinatoric explosion
10:31:05 <Eddi|zuHause> and the whole UI part was basically ignored
10:31:31 <Eddi|zuHause> "look i got this 4k screen, why should i care?"
10:32:43 <TrueBrain> I like how map-array-redesign pops up again
10:32:45 <Eddi|zuHause> like, if we continue the 640k analogy, then extending to 32 is basically just himem.sys
10:32:47 <TrueBrain> I have been hearing that for 15 years now :P
10:32:56 <Eddi|zuHause> instead of EMM386
10:33:20 <TrueBrain> OpenTTD always has had talks about its limits .. that will never stop I guess
10:33:40 <TrueBrain> I remember we bumped the vehicle limit to 5k .. like .. that for sure should be enough, not?!
10:35:07 <TrueBrain> but as it goes with any of these talks .. you just need someone to say: this is what we are going to do, deal with it
10:35:14 <TrueBrain> as it is better to pick something, than to pick nothing :)
10:35:22 <LordAro> new map array pops up because anything to do with extending it right now continues to be a hack :p
10:35:45 <Eddi|zuHause> there is not going to be a "new map array", ever...
10:36:20 <TrueBrain> besides the whole practical point, there is basically not a faster way to do this
10:36:58 <Eddi|zuHause> and it's completely not relevant to the discussion. any extension (32,256,65k) you could imagine would be possible with the existing map array
10:37:27 <Eddi|zuHause> it just has to be made bigger
10:37:49 <TrueBrain> what is funny to me .. I keep reading rants on the forums about devs not adding anything, the default blablabla
10:37:58 <TrueBrain> but I also keep on reading: what you are about to add, is not sufficient, blablabla
10:38:08 <TrueBrain> so ... how about we do something, instead of talking about nothing? :D
10:39:22 <Eddi|zuHause> ok, but before doing "something", i am of the opinion that we should reach some sort of consensus what that "something" should be
10:39:36 <TrueBrain> I thought they did :)
10:39:38 <Eddi|zuHause> and i don't see that we reached that consensus yet
10:40:10 <TrueBrain> how many types are in NRT now?
10:40:27 <Eddi|zuHause> yesterday it was 15+15
10:40:42 <TrueBrain> so isnt that a good starting point? Increasing values is always possible
10:40:44 <TrueBrain> nothing is set in stone
10:40:51 <TrueBrain> so why not first go with 15+15 .. and see what happens?
10:41:07 <TrueBrain> (I might be completely missing the point, but I dont see how talking about extending is useful without having something first)
10:42:42 <Eddi|zuHause> like, one part of the problem is "patchpack <XYZ> contains a patch for 32 types, so i design my set for that. it will not be compatible with trunk."... which i think is a stupid path to follow
10:43:12 <TrueBrain> and so the endless: we have to please everyone, issue comes around
10:44:16 <andythenorth> it's what rubidium said: none
10:44:43 <andythenorth> I am only doing forum blah blah chat because I can do piss all about moving NRT any further :)
10:44:44 <TrueBrain> andythenorth: it cannot be 2 answers
10:45:28 <andythenorth> I am out for most of day, but I am hoping I can help Wolf remove the remaining TODO lines
10:45:39 <andythenorth> then maybe we can have 15 + 15
10:45:44 <andythenorth> which is better than none
10:45:48 <TrueBrain> isnt it already in NRT?
10:46:02 <andythenorth> yes, but NRT is effectively dead, unless someone moves it
10:46:14 <andythenorth> like it's had every possible long testing period
10:46:15 <Alberth> moin, hopefully with a not entirely unstable connection
10:46:34 <TrueBrain> andythenorth: so no offense, but you just added noise to the conversation :)
10:46:40 <TrueBrain> its not none .. it is 15+15
10:46:43 <andythenorth> the ones who started NRT just need to remove remaining 1% of issues
10:46:54 <andythenorth> we're just FAIL :P
10:47:15 <andythenorth> TrueBrain: you're right, but eh, I'm embarassed about NRT
10:47:29 <TrueBrain> Eddi|zuHause: I did my fair share of Product Owner stuff leading people bla ... I am of the opinion you need to have a bit of BOFH attitude .. at a certain point someone just has to say: this is what we are going to do .. join us or leave us
10:47:38 <TrueBrain> as having endless debates about stuff just demotivates
10:47:39 <andythenorth> it could have been done weeks ago, I just don't want to face the work
10:47:49 <TrueBrain> andythenorth: don't be :) Were you around for TGP?
10:48:01 <TrueBrain> TGP was "done", by a group of people not devs
10:48:10 <TrueBrain> they were like: this is ready to merge in trunk, tested, everything
10:48:25 <TrueBrain> so me and .. some other dev (sorry, cant remember) took it on to merge it into trunk
10:48:25 <andythenorth> mostly I make newgrfs on my own, because then it's 100% on me
10:48:31 <TrueBrain> it took 3 months :P
10:48:33 <Eddi|zuHause> ah, the "well tested" meme :p
10:48:46 <TrueBrain> but that is okay ... it got in there
10:48:52 <TrueBrain> sometimes things sit idle for a bit
10:48:57 <TrueBrain> as long as they sit idle for the right reasons
10:49:07 <TrueBrain> having debates about things that can be changed later ... is not a good reason :D
10:49:12 <Eddi|zuHause> cargodist existed for like 5 years before it finally got merged
10:49:22 <TrueBrain> another nice example :)
10:49:32 <TrueBrain> OpenTTD often lacks a bit of balls
10:49:43 <TrueBrain> I ahve seen it with BaNaNaS .. some authors REFUSED to add their grfs to it
10:49:57 <TrueBrain> just no way you can get them all on board
10:50:07 <TrueBrain> ask for opinions, weight them, dismiss a few
10:50:24 <andythenorth> what's in NRT 2?
10:50:48 <andythenorth> I use a lot of "we can look at that in a future version, let's ship something"
10:50:57 <andythenorth> then the people who like to talk talk about v2
10:51:02 <andythenorth> and the people who are bored by talk ship v1
10:51:21 <TrueBrain> the forum not really being flexible is not helping :)
10:51:25 <TrueBrain> 1 thread for everything is just annoying
10:51:38 <andythenorth> doesn't really bother me :)
10:51:54 <andythenorth> it's obviously terrible for suggestion/feature chat
10:51:55 <TrueBrain> currently all I can see is that NRT is talking bla about how many toys they are going to get
10:52:05 <andythenorth> that's just noise
10:52:05 <TrueBrain> totally missing the other good stuff in that thread :)
10:52:14 <andythenorth> the interesting stuff is the other threads with people making test grfs
10:52:19 <Eddi|zuHause> andythenorth: the problem i see with that approach is that you're dividing the already low manpower for shipping something into two projects, which will even further delay shipping
10:52:37 <andythenorth> Eddi|zuHause: no, it segments off those who were delaying it with noise
10:52:45 <andythenorth> they had a negative net contribution
10:52:53 <TrueBrain> as with any project, also in real life, you need a captain who has enough balls to call out commands ... right or wrong, not relevant .. :)
10:53:11 <TrueBrain> better to be wrong than to stand still
10:53:18 <peter1138> Was my suggestion last night about road types feasible? Or just stupid...
10:53:19 <andythenorth> so it comes to: I can't remove the TODO because I don't know why they are there, but wolf seems to know
10:53:36 <andythenorth> so help Wolf remove TODO, ship big diff, profit
10:53:39 <TrueBrain> sounds like a good focus andythenorth :) Slap Wolftill they are gone :P
10:53:57 <Eddi|zuHause> andythenorth: then split off the whole 32types discussion into a "Suggestions" thread, keep the "Development" thread about things to do for merging the existing implementation
10:54:18 <Eddi|zuHause> andythenorth: call it a "feature freeze"
10:54:28 <TrueBrain> now you are talking like a Product Owner :D
10:54:39 <TrueBrain> set your Minimal Viable Product, and GO GO GO
10:54:39 <andythenorth> oh you mean the thread is a rambling off-topic disaster Eddi|zuHause? :)
10:54:48 <andythenorth> I don't have forum rights, don't want them
10:55:09 <Eddi|zuHause> then grab yourself a moderator :p
10:55:38 <andythenorth> the rambling doesn't bother me at all :)
10:56:08 <TrueBrain> as long as you keep your current focus split off from the rambling :)
10:56:41 <andythenorth> remove TODO, ship diff, profit
10:56:51 <andythenorth> peter1138: which suggestion? o_O
10:57:00 <andythenorth> "8 bit index to a roadtype/tramtype combination table"
10:57:01 <peter1138> Merge conflict in media/extra_grf/openttdgui.png ;(
10:57:15 <andythenorth> seems like it's solving a non-problem
10:57:22 <andythenorth> that merge conflict is the icons
10:57:31 <andythenorth> thought you fixed that already? o_O
10:57:33 <peter1138> Yes, I know what it is.
10:57:47 <Eddi|zuHause> andythenorth: i don't think that "solution" is either viable or possible
10:58:00 <peter1138> andythenorth, yes, but I fixed those icons in master since.
10:58:35 <andythenorth> want me to fix the png? I can't do it for ~8 hours, but happy to later
10:58:43 <peter1138> Eddi|zuHause, which? And why?
10:59:33 <Eddi|zuHause> peter1138: the "instead of 16 road and 16 tram types, have 256 (road+tram)-type combinations"
10:59:37 <peter1138> andythenorth, I can do it, just more work :-)
11:00:00 <peter1138> Eddi|zuHause, okay. It was my suggestion, so tell me :-)
11:00:10 <andythenorth> I had the idea of pooling *types
11:00:22 <andythenorth> player can install as many as they want, but only 16 can be on the map at once
11:00:31 <andythenorth> so they could cycle them as they upgrade
11:00:45 <Eddi|zuHause> that sounds soo horrible
11:00:50 <andythenorth> like inventory in a MUD game
11:00:53 <Eddi|zuHause> i wouldn't want to play that game
11:01:14 <andythenorth> "your satchel has space for 16 railtypes"
11:01:36 <Eddi|zuHause> "you can't convert to this road, until you remove every trace of that road from the map"?!?
11:02:21 <peter1138> I considered that for railtypes as well.
11:02:35 <peter1138> It's basically the same thing as the 8 bit index.
11:02:42 <peter1138> (But 8 bits gives you more room)
11:03:23 <peter1138> Okay, when merging binary files, how do you get the us and them versions?
11:03:28 <Eddi|zuHause> the main problem there is that you offload what would be a design decision from the newgrf author onto the player
11:04:26 <Eddi|zuHause> and the player doesn't know he will have to make that decision, and will run face first into a wall
11:04:58 <Eddi|zuHause> and the error message he will get will be cryptic enough to not be understood by a large portion of players
11:05:43 <peter1138> A while back, someone wanted a hidden railtype that couldn't be built directly, but was there for mixing compatibility up. Can't remember who or what the complete purpose was.
11:05:59 <andythenorth> it's to permit vehicles to transcend types
11:06:11 <andythenorth> there's a GH issue about it
11:06:16 <Eddi|zuHause> it's always the same one... have a dual-voltage vehicle without having a dual-voltage railtype
11:06:44 <andythenorth> vehicle that can go on both ROAD and DIRT
11:07:16 <Eddi|zuHause> we've had versions of that discussion for like 10 years every now and then
11:07:46 <Eddi|zuHause> IMHO that is best solved by having two articulated parts, and each part getting a different railtype
11:08:07 <Eddi|zuHause> (currently the implementation of articulated parts does not allow that)
11:09:12 * peter1138 considers the obvious benefit to just going out on the bike.
11:09:41 <andythenorth> I am going out to do outdoor things
11:10:07 <andythenorth> the map array is inextensible, right :P
11:10:44 <andythenorth> we have bits 0-A, and adding B is not practical?
11:10:45 <Eddi|zuHause> not the word i would use
11:11:39 <TrueBrain> a bit longer answer to your question yesterday
11:13:09 <andythenorth> oh 0-A are tile classes?
11:13:36 <andythenorth> and then each class has 9 attributes
11:13:53 <peter1138> Eddi|zuHause, so anyway, you covered the not viable part, due to gameplay reasons. What about not possible?
11:15:00 <andythenorth> so each tile uses 80 bits for landscape? is 80 historical, or is there some constraint / optimisation?
11:15:15 <andythenorth> I'm not proposing changing anything, just learning :P
11:15:20 <peter1138> We already increased it back in the day.
11:15:52 <Eddi|zuHause> well, how is that combination table made up? you count the number of types collectively defined in all newgrfs? then calculate A*B, and when that number is >256 then what? how about adding newgrfs mid-game, you have to recalculate all the indices?
11:16:15 <peter1138> Eddi|zuHause, it's built as the combinations are used.
11:17:34 <peter1138> So to start with, it has no entries, then a town builds a road and it has one entry.
11:18:04 <peter1138> Hence it solves one limit but adds another.
11:18:41 <Eddi|zuHause> so, it solves a hard limit, but adds a completely incomprehensible soft limit
11:18:58 <peter1138> Well it's still a hard limit but less obvious, yes :-)
11:19:12 <andythenorth> limits are good :)
11:20:37 <peter1138> But it also allows for having, say 25 road types and 5 tram types, which wouldn't push past the limit.
11:20:55 <peter1138> 25/10 would be possible too
11:22:55 <peter1138> So you could engineer it so that the combination limit is < 256, then you'd have no weird gameplay limit.
11:23:25 <peter1138> I mean, obviously every author will want 32 road types and 32 tram types, but meh.
11:24:24 <peter1138> You could then have the hidden types not take up a slot.
11:33:16 *** synchris has joined #openttd
11:39:44 <peter1138> So yeah, if you put that limit in... is that worth doing? Hmm.
11:46:33 *** Wacko1976 has joined #openttd
11:48:15 *** gelignite has joined #openttd
12:09:06 *** Wormnest has joined #openttd
12:36:07 *** HerzogDeXtEr has joined #openttd
12:58:11 *** Thedarkb-X40 has joined #openttd
14:11:43 *** sim-al2 has joined #openttd
14:57:55 *** Thedarkb-X40 has joined #openttd
15:02:30 *** goodger has joined #openttd
15:34:19 *** supermop has joined #openttd
15:34:20 *** andythenorth has joined #openttd
15:38:52 *** Thedarkb-X40 has joined #openttd
15:41:15 <andythenorth> or just add 32 bits to each tile :P
15:42:09 <LordAro> how much does each tile have currently?
15:42:56 <andythenorth> looks like 80 bits by my count
15:43:03 <andythenorth> docs/landscape_grid.html
15:43:26 <andythenorth> 2 x 16 bits for * types
15:43:36 <andythenorth> then can also do 2 railtypes per tile
15:43:45 <andythenorth> or some bollocks with 'electrification types'
15:47:01 <Wolf01> ButGroundTypes might solve everything
15:59:56 <LordAro> TrueBrain: are you thinking of making github-dorpsgek some sort of supybot plugin?
16:36:50 *** Progman has joined #openttd
16:47:28 <TrueBrain> LordAro: supybot is kinda dead
16:47:38 <TrueBrain> but I was more thinking what-ever-IRC-bot, is part of that repo
16:47:50 <TrueBrain> (most likely via a 'pip install' in a Dockerfile orsomething)
16:48:13 <TrueBrain> but it has to be an IRC bot and a HTTP server-ish
16:49:14 <LordAro> i'm not sure i know of any existing bots that have that sort of framework
17:17:47 <LordAro> TrueBrain: you'll be pleased to know i'm currently 14 comments into a midi driver PR review
17:28:11 <LordAro> there are new warnings
17:29:36 *** Thedarkb-X40 has joined #openttd
17:37:18 <LordAro> two classes of warnings*
17:37:44 *** snail_UES_ has joined #openttd
17:57:28 <nielsm> LordAro, the "glitch" thing in my music code is meant as an easter egg, it emulates a bug I had while working on it (but without crashing and walking all over memory)
17:57:48 <peter1138> Is that... useful? o_O
17:58:08 <LordAro> feels like a bit too much code for an easter egg
18:03:38 <nielsm> well the majority of the code is for the UI, otherwise it's just three lines :P
18:12:06 *** Wormnest_ has joined #openttd
18:22:20 <andythenorth> Wolf01: if we knock out one TODO at a time...
18:22:23 <andythenorth> we can get it done
18:22:29 <andythenorth> we should maybe fork Peter's fork :P
18:24:15 <LordAro> but that would be using git as it was intended!
18:24:29 <Wolf01> There are only 4 todos to work on, 3 are on town_cmd and the town_roads branch should address those, one is a "I don't know how to perform a valide check here", all the others are nonsense
18:24:30 <andythenorth> we could file patches on tickets
18:24:46 <andythenorth> some just need deleted?
18:24:53 <andythenorth> "it could be done by christmas!"
18:41:07 *** Wacko1976_ has joined #openttd
18:54:48 *** supermop has joined #openttd
19:56:45 *** Supercheese has joined #openttd
20:07:16 *** frosch123 has joined #openttd
20:08:23 *** supermop has joined #openttd
20:45:22 <andythenorth> if (rt == ROADTYPE_ROAD) rst |= ROADSUBTYPES_NORMAL; // Road is always available. // TODO
20:45:27 * andythenorth looking for TODOs
21:39:21 <peter1138> I haven't finished rebasing yet.
21:41:37 <andythenorth> I've got your fork checked out
21:43:46 <peter1138> Will just need a rebase later, not difficult
21:47:35 <andythenorth> I haven't changed anything :P
21:47:41 <andythenorth> I don't know what these TODOs mean
21:47:57 <andythenorth> hoping Wolf01 turns up and we fix them one at a time :)
21:49:15 <Wolf01> I'll look at it in the next days
21:51:14 *** supermop has joined #openttd
22:05:01 * peter1138 ponders ... playing ... this game ...
22:05:20 <peter1138> Or should I stick on the VR headset and do a bit of space flying. Hmm.
22:14:33 <andythenorth> FIRS needs a decent economy though
22:14:36 <andythenorth> it all sucks currently
22:23:38 <andythenorth> why does Busy Bee keep crashing then? :|
22:24:04 <andythenorth> Alberth: "Your script made an error: wrong number of parameters" o_O
22:25:29 *** snail_UES_ has joined #openttd
22:28:21 <andythenorth> V453000: FIRS has no concept :P
22:29:00 <V453000> I think it's pretty great as is
22:32:04 <andythenorth> much trains to draw
22:33:35 <V453000> honestly, I would consider FIRS finished and instead of breaking it I would either just add economies which don't wreck existing stuff, or even make a new industry set ... with a concept if you say so :P
22:34:31 <snail_UES_> I was reading about the 32 railtypes debate…
22:34:46 <V453000> who needs 32 railtypes :0
22:34:50 <snail_UES_> since the patch already exists, and some patchpacks already use that, why not adding it to trunk as well?
22:35:15 <snail_UES_> otherwise, it sounds like dictating newGRF authors what they “should” and “should not” do...
22:36:08 <LordAro> no one's making them make a grf that only works with a patchpack
22:37:04 <V453000> I don't know the technical obstacles, but why is 16 not enough? :d
22:37:31 <snail_UES_> because historically there were many different kinds of electrification
22:37:56 <snail_UES_> normal catenary, threephase, third rail
22:38:41 <snail_UES_> even when we exclude different voltages, we still have multiple types… and, if a set wants to cover the period 1840 - today, it needs a decent number of track types (around 6 to 8 if it covers different gauges)
22:38:48 <V453000> and non-historically in my mind is a wetrail, slugrail and a turtlerail...
22:39:16 <snail_UES_> the thing is, some people would find this feature useful
22:39:19 <LordAro> i think going for that sort of historical accuracy in OTTD is silly
22:39:30 <snail_UES_> why not helping them, instead of trying to convince them they’re "wrong"...?
22:39:54 <Alberth> andythenorth: don't know, I think it's a problem in openttd, but haven't checked where it comes from
22:40:22 <andythenorth> seems reproducible
22:40:33 <andythenorth> I've seen it on two different OS versions
22:40:46 <V453000> if it's not a technical obstacle, I agree with you snail_UES_ ,even if I do consider this kind of realism just perverse
22:41:16 <snail_UES_> V453000: fine, many people think differently :)
22:41:37 * andythenorth sets realistic train colours in game
22:41:41 <Alberth> yeah, but squirrel code hasn't changed, and we claim compatibility with some version which thus should stay compatible too
22:41:48 <andythenorth> if only there was a livery UI
22:42:12 <andythenorth> Alberth: have you seen the error?
22:42:18 <peter1138> The 32 railtype patch is uglyh.
22:42:53 <peter1138> Borrowing a bit from a different place in the map array.
22:42:59 <Alberth> yep, a game of mine crashed on load, while I loaded it before without problem' should try if I can get older versions of that save to crash too
22:43:58 <snail_UES_> peter1138: why ugly?
22:44:14 <LordAro> snail_UES_: a common issue with the stuff in the patchpacks is they're often done in a hacky and unmaintainable way - the core game *must* be stable, load old save games and generally not be awful code
22:44:49 <peter1138> 21:42 < peter1138> Borrowing a bit from a different place in the map array.
22:45:42 *** sim-al2 has joined #openttd
22:45:50 <Alberth> it's like extending a graphics by adding a piece at a different place in the image
22:47:26 <andythenorth> this stuff can also make any future features harder
22:47:46 <andythenorth> FWIW, 16 cargos would not be enough, but 32 is :P
22:48:00 <andythenorth> not sure that is a useful comment though
22:48:08 <peter1138> Wasn't the original limit 12 or something? :p
22:48:51 <LordAro> andythenorth: you mentioned adding another 32bits earlier - if the current total is 80bits, i'd think it better to add another 48bits to round out to 128. cache lines will probably be nicer about stuff that way
22:49:13 <andythenorth> what would we do with so many bits? o_O
22:49:13 <LordAro> (not that it particularly matters anyway)
22:49:56 <DorpsGek> LordAro: 4503599627370496
22:49:58 <snail_UES_> well, the number of needed railtypes would be limited by what exists in the real world
22:49:59 <frosch123> i would approve 64k railtypes :)
22:50:08 <frosch123> but only for visual difference
22:50:16 <frosch123> compatibility is boring
22:50:32 <andythenorth> 1 type for each tile on the map
22:50:55 * andythenorth ponders electrification type limited by map tile
22:50:56 <LordAro> OpenTTD. Is. Not. A. Simulation.
22:51:05 <andythenorth> so 25% of map is 1500V DC
22:51:17 <andythenorth> and there are transition zones :P
22:51:27 <Eddi|zuHause> <LordAro> andythenorth: you mentioned adding another 32bits earlier - if the current total is 80bits, i'd think it better to add another 48bits to round out to 128. cache lines will probably be nicer about stuff that way <-- that's why the map array is actually split into two, one 64-bit and one 16-bit (used to be 8-bit) array entries
22:51:35 <peter1138> Also, splitting off electrification from railtype is a silly idea.
22:51:48 <snail_UES_> peter1138: why is that?
22:52:09 <peter1138> Because it reduces the number you can have
22:52:15 <Eddi|zuHause> snail_UES_: the short answer is: "we've been over that already, and it was impractical"
22:52:49 <snail_UES_> I think Locomotion did that...?
22:53:08 <snail_UES_> you would build the rail, and then you could overlay catenary and/or third rail on top of that
22:53:17 <LordAro> Locomotion is a completely different game, underneath
22:53:58 <andythenorth> "playing it safe can cause a lot of damage in the long run"
22:55:47 <snail_UES_> ok… but I’m still not sure why it would reduce the number you can have
22:55:59 <snail_UES_> you’d have 8 railtypes and 3 electrification types
22:56:31 <snail_UES_> and you would mix them as you wanted… each vehicle would check if it’s compatible and powered on those present in a tile
22:56:51 <andythenorth> 2 electrification types if my maths is right
22:57:00 <andythenorth> one of which is 'not electrified'
22:57:24 <LordAro> that 5th bit can't (easily) happen, remember
22:57:40 <snail_UES_> ok, so 4… not electrified, catenary, third rail, threephase
22:58:00 <Eddi|zuHause> andythenorth: but playing it unsafe will almost definitely cause a lot of damage
22:58:14 <snail_UES_> it was just an example
22:58:25 <andythenorth> Eddi|zuHause: Banksy doesn't have to write a spec, just graffiti :)
22:58:33 <snail_UES_> the idea is to offer flexibility to newgrf authors
22:58:44 <Eddi|zuHause> andythenorth: maybe he should use a modern language?
22:59:23 <peter1138> What about 5th rail?
22:59:48 <peter1138> What about AC vs DC?
22:59:54 <snail_UES_> peter1138: these are all questions a newGRF author would take care of
22:59:56 <peter1138> What about low voltage vs high voltage?
23:00:06 <peter1138> Where would it fit?
23:00:15 <peter1138> Is that an electrification system, or a railtype?
23:00:17 <snail_UES_> I feel OTTD could be a base and offer flexibility to those authors
23:00:37 <Eddi|zuHause> we have that flexibility, it's called a railtype label
23:01:00 <peter1138> What about when I add narrow gauge, does it need to support all 4 of these electrification types?
23:01:18 <andythenorth> could we check 'powered' by pathfinding from current tile to nearest 2 'substations'
23:01:24 * andythenorth has sillly ideas
23:01:28 <snail_UES_> peter1138: thanks! you’re proving my point :)
23:01:38 <andythenorth> electrify like signals, e.g. similar to PBS reservations
23:01:40 <peter1138> Does it need to support all 4 of those types?
23:01:46 <andythenorth> build a feed-in tile
23:02:08 <snail_UES_> if railtypes and electrification types are baked together, if I had a different gauge, I need to define as many railtype labels as electrification systems it supports
23:02:10 <V453000> 2nd map level with underground electric wiring logistics
23:02:27 <Eddi|zuHause> underground pipes!
23:02:29 <andythenorth> each tile has 'power' level on it
23:02:34 <snail_UES_> if they’re separate, on the other hand, I just define NG… and then I could build electrification on top of that
23:02:48 <peter1138> Who provides the graphics for the electrification of narrow gauge in that case?
23:03:04 <andythenorth> electricity grf!
23:03:17 <snail_UES_> a newGRF author should provide graphics for its combinations
23:03:29 <V453000> well the base set has catenary?
23:03:45 <peter1138> And back to maglev, what electrification systems are supported there?
23:04:02 <Eddi|zuHause> 3rd rail monorail :p
23:04:13 <V453000> don't forget WETRail :>
23:04:45 <peter1138> 4 types of electrification may not fit what a railtype can do
23:05:10 <andythenorth> the nice thing is that patchpacks will be easier soon
23:05:22 <peter1138> To separate railtype from electrification simply wastes space.
23:05:42 <snail_UES_> I think each newGRF would define rail and electrification types, then be able to combine them… without combining pieces from different GRFs
23:05:42 <peter1138> To have 4 electrification types would use up 2 bits.
23:05:50 <peter1138> That would leave 2 bits remaining for the railtype.
23:05:56 <peter1138> So you could then only have 4 railtypes.
23:06:11 <Eddi|zuHause> snail_UES_: the main problem with separating tracks from electrification is exactly this problem of "are all combinations valid?", because if not, then you need the same storage space (which is the limiting factor currently) but you actually reduce the number of total railtypes available in the game
23:06:53 <peter1138> Right, it every rail type supported every combination of electrification, then you'd end up exactly where you are at the moment.
23:07:07 <peter1138> If some railtypes don't support some combination, you are in a WORSE situation.
23:07:28 <peter1138> Because you have wasted some combination of bits that can't be used now.
23:07:30 <snail_UES_> so the issue is to find the 5th bit?
23:07:56 <snail_UES_> and you solved it using a workaround?
23:08:17 <Eddi|zuHause> yes. basically piecing together 5 bits from leftover cutouts
23:08:32 <Eddi|zuHause> which is... terrible quality
23:08:44 <Eddi|zuHause> even if on the surface it works
23:08:45 <snail_UES_> if the issue is technical, then I can understand...
23:08:54 <peter1138> There is simply no instance where splitting railtype and electrification type is actually a benefit.
23:09:14 <snail_UES_> what I don’t always agree with, is when someone tries to convince others they “don’t need” more railtypes :p
23:09:18 <peter1138> Of course it is technical.
23:10:20 <peter1138> For instance, borrowing a bit from elsewhere requires 2 reads of the map array every time.
23:10:38 <peter1138> (And 2 writes, which also needs 2 reads itself.)
23:11:02 <Eddi|zuHause> snail_UES_: yeah, no, the "you don't need that" argument is nonsense. but the actual argument is "even if we did that, next week another person would come along and demand a 6th bit, so we wouldn't actually solve anything"
23:12:04 <peter1138> Don't start of 64 types ;)
23:12:12 <peter1138> That requires way more changes than 32 types.
23:12:16 <Eddi|zuHause> snail_UES_: so we're carefully finetuning the levels of "impossible" that we're actually willing to tackle
23:12:32 <snail_UES_> then I think I’ll design my newGRF with 21 railtypes, adding a parameter that undefines 5 of them to work with trunk :p
23:12:54 <snail_UES_> maybe I’ll keep 16 as the default value of this parameter
23:13:08 <peter1138> Now, the drop down list certainly will suck with such a large number.
23:13:50 <snail_UES_> peter1138: speaking of the dropdown list, any chance we could have some railtypes excluded from there?
23:14:08 <snail_UES_> say a set has AC and DC voltages, and some engines are bi-current (can run on both)
23:14:22 <snail_UES_> this set will have to define a railtype compatible with both for these engines
23:14:36 <peter1138> So it is conceivable that the UI could be changed to provide a "base" railtype, and have electrification types "extend" that base railtype. But it would and should still be separate labels.
23:14:37 <snail_UES_> but this railtype shouldn’t actually be buildable...
23:14:57 <snail_UES_> peter1138: I like your idea
23:14:58 <V453000> doen't xUSSR or dutch trains already do some stuff like that?
23:15:22 <V453000> I mean that AC DC whatever nonsense
23:15:31 <Eddi|zuHause> snail_UES_: i think that issue has come up in the past (e.g. in the unified railtype scheme discussion), and the two arguments i have there are: 1) is it really necessary to hide that combined type? there are real-world applications where voltage can be switched in some stations
23:15:59 <andythenorth> it's another variant of the mixed gauge thing
23:16:01 <Eddi|zuHause> 2) i'd rather like it if the dual-voltage could be done as articulated vehicles, where each part gets a different railtype
23:16:11 <andythenorth> or the '4x4 trucks on dirt roads and highways' thing
23:16:34 <Eddi|zuHause> with 2) you wouldn't need to reserve a railtype slot
23:16:49 <peter1138> ^ it's buildable ;)
23:17:27 <snail_UES_> Eddi|zuHause: so the first half is DC, the second is AC, both are “compatible” with DC and AC railtypes, and either one would be powered on any of these two...?
23:17:38 <peter1138> (That would not be possible if "electrification type" was stored separately, btw)
23:17:41 <Eddi|zuHause> snail_UES_: yes, basically
23:18:03 <Eddi|zuHause> snail_UES_: i've never actually looked into what would be necessary to allow that, though
23:18:17 <Eddi|zuHause> snail_UES_: the current specs say "you mustn't do that"
23:18:21 <peter1138> As a bonus, it automatically provides the correct power/TE output. If it was supported which it is not.
23:18:59 <peter1138> That image is actually another reason why splitting electrification type off is not a good idea.
23:19:20 <peter1138> You'd need 1 bit on the map array for each type, else you couldn't combine them.
23:19:31 <snail_UES_> peter1138: only if a rail tyle could have one and only one electrification type
23:19:54 <peter1138> snail_UES_, yes. You need *loads* of bits if it's to be a combination.
23:19:59 <Eddi|zuHause> snail_UES_: well, it currently can have only one railtype.
23:20:18 <peter1138> 4 electrification types would need 3 bits (you don't need a bit for none in that case)
23:20:22 <V453000> would that mean you can't build two differently powered tracks on the same diagonal tile?
23:20:25 <peter1138> Which would leave you with 1 bit for railtype. lol.
23:20:35 <V453000> now you can at least get an universal railtype to solve that issue
23:20:41 <snail_UES_> ok… I was hoping you could overlay, say, “catenary” AND “third rail” on a rail tile
23:20:58 <snail_UES_> if it’s such a hassle then I understand
23:21:10 <andythenorth> not unless you have CA3R or something as the type
23:21:10 <peter1138> So yeah, this is why railtypes and electrification types are not separate. There's no logical way it makes sense.
23:21:16 <andythenorth> and then you bodge the sprites
23:21:21 <peter1138> By all means it could be "faked" in the UI.
23:22:50 *** Supercheese has joined #openttd
23:23:18 <peter1138> So who'll be brave and add another 8 bits ;)
23:24:09 <snail_UES_> even just a 5th bit would be a great step forward ;)
23:24:18 <peter1138> Yeah it doesn't work like that.
23:25:06 <andythenorth> @calc 4096 * 4096 * 32
23:25:06 <DorpsGek> andythenorth: 536870912
23:25:20 <andythenorth> @calc 536870912 / 1024
23:25:20 <DorpsGek> andythenorth: 524288
23:25:39 <peter1138> @calc 4096 * 4096 * 8
23:25:39 <DorpsGek> peter1138: 134217728
23:25:47 <peter1138> 134MB, not too bad.
23:26:04 <peter1138> @calc 4096 * 4096 * 32 / 8
23:26:37 <peter1138> Although 32 bits makes no sense.
23:26:44 <peter1138> It has to be 16 bits or 48 bits, as LordAro said.
23:26:58 <LordAro> well it doesn't *have* to
23:27:05 <LordAro> but you'd be pretty insane not to :p
23:27:13 <andythenorth> 16 bits for type 1, 16 bits for type 2, 16 bits spare
23:27:25 <andythenorth> 16 bits for evil ideas I have
23:27:30 <peter1138> If you added 16 bits to the array...
23:27:59 <peter1138> Would 64 railtypes ever be enough :p
23:28:25 <andythenorth> you know it wouldn't
23:28:27 <peter1138> You'd need to move stuff around in the map array of course.
23:28:33 <andythenorth> it's not nearly enough
23:28:52 <peter1138> I guess m4 is used for level-crossings with NRT.
23:28:55 <andythenorth> because every grf will then contain 30 or 40 types
23:29:00 <peter1138> Actually I guess it's used anyway.
23:29:07 <andythenorth> so to combine grfs, the 64 limit will be hit trivially
23:29:30 <andythenorth> tragedy of the commons
23:29:31 <peter1138> In theory they should be using the same labels if it's the same type.
23:29:45 <snail_UES_> peter1138: 64 railtypes wouldn’t be enough, if newGRF authors started using them as visually different variants
23:30:16 <peter1138> Slightly less rusty rails
23:30:26 <peter1138> Clean rails with 48km/h limit
23:30:35 <peter1138> Dirty rails with 49.5km/h limit
23:31:02 <LordAro> rails with leaves with a 0km/h limit
23:31:10 <andythenorth> thermite welded rails with concrete sleepers
23:31:31 <andythenorth> bullhead rail on wooden sleepers with chairs
23:31:39 <andythenorth> pandrol clipped rails
23:31:48 <andythenorth> rails on concrete cast bed with rubber pads
23:31:52 <supermop> rails with a bit of little trash every 100m
23:31:57 <snail_UES_> yes… but if it’s technically possible, I wouldn’t see why OTTD shouldn’t support more railtypes
23:32:05 <andythenorth> AWS ramp rail (1 tile only)
23:32:08 <supermop> rails with a bit of trash every 50 m
23:32:09 <snail_UES_> I can understand the argument that it’s technically difficult
23:32:12 <andythenorth> rail with pax crossing tile
23:32:19 <andythenorth> rail with catch point
23:32:30 <andythenorth> in a nice way, imagine what GarryG would do with it
23:32:37 * andythenorth loves GarryG's stuff
23:32:38 <peter1138> Well, adding more space to the array is not technically difficult. It's just not done without an exceptional reason.
23:32:48 <snail_UES_> but it’d be useless to dictate newGRF authors what hey “should” and “shouldn’t” do
23:32:50 <andythenorth> it's not worth it unless we go big :P
23:32:56 <peter1138> How would you use 64 railtypes up?
23:33:24 <snail_UES_> peter1138: as for me? I’d only need 21
23:33:33 <snail_UES_> I can’t see how I’d use more up...
23:33:34 <peter1138> That seems a lot less than 64.
23:33:37 <andythenorth> peter1138: easy, just make loads of eye candy
23:34:10 <snail_UES_> andythenorth: yes, I can see some people wanting them. Not my case
23:37:10 <andythenorth> snail_UES_: at least you come and make the case in discussion :)
23:37:20 <andythenorth> unlike people who just complain in forum
23:40:36 <snail_UES_> andythenorth: yeah… well you can’t please everyone all the time, but seeing something in a patchpack and not in trunk can be frustrating at times
23:41:07 <snail_UES_> the reason why something is not in trunk is not always clear to everyone
23:42:14 <peter1138> Most probably a patch pack has just increased the size of the map array.
23:43:47 <andythenorth> such sleeping I must
23:43:54 *** andythenorth has left #openttd
continue to next day ⏵
