Config
Log for #openttd on 29th December 2020:
Times are UTC Toggle Colours
00:57:48  *** glx has quit IRC
01:04:02  *** WormnestAndroid has quit IRC
01:04:16  *** WormnestAndroid has joined #openttd
01:12:50  *** WormnestAndroid has quit IRC
01:13:04  *** WormnestAndroid has joined #openttd
01:14:48  *** WormnestAndroid has quit IRC
01:16:52  *** WormnestAndroid has joined #openttd
01:18:21  *** Progman has quit IRC
01:29:14  *** gelignite has quit IRC
01:38:03  <supermop_Home> i know scale is not consistent for base set houses
01:38:13  <supermop_Home> or even between base set office buildings
01:38:24  *** Afdal has quit IRC
01:39:06  <supermop_Home> but most ogfx offices and flats use 6px floor to floor, with a few 8-10px
01:40:30  <supermop_Home> but one thing that always bothered me about the arctic hotel is just how weirdly out of scale it looks
01:43:04  <supermop_Home> i can't tell, maybe all of the arctic buildings are of a bigger scale
01:54:54  <DorpsGek> [OpenTTD/OpenTTD] Eddi-z commented on issue #8424: Trains can crash through depots https://git.io/JLXif
02:06:30  <DorpsGek> [OpenTTD/OpenTTD] James103 commented on issue #8424: Trains can crash through depots https://git.io/JLXif
02:07:31  *** Wormnest has quit IRC
02:17:58  <DorpsGek> [OpenTTD/OpenTTD] Eddi-z commented on issue #8424: Trains can crash through depots https://git.io/JLXif
02:32:51  <DorpsGek> [OpenTTD/OpenTTD] Eddi-z commented on issue #8424: Trains can crash through depots https://git.io/JLXif
02:38:11  <DorpsGek> [OpenTTD/OpenTTD] Eddi-z commented on issue #8424: Trains can crash through depots https://git.io/JLXif
02:44:08  *** Flygon has joined #openttd
03:26:27  *** debdog has joined #openttd
03:29:53  *** D-HUND has quit IRC
05:42:25  *** sla_ro|master has joined #openttd
06:22:00  *** HerzogDeXtEr has joined #openttd
06:54:03  *** sla_ro|master has quit IRC
06:57:29  *** sla_ro|master has joined #openttd
07:15:00  <DorpsGek> [OpenTTD/OpenTTD] UnsuspiciousGooball commented on issue #8424: Trains can crash through depots https://git.io/JLXif
07:33:48  *** andythenorth has joined #openttd
07:36:06  <andythenorth> yo
07:56:15  <DorpsGek> [OpenTTD/OpenTTD] UnsuspiciousGooball commented on issue #8424: Trains can crash through depots https://git.io/JLXif
08:19:39  *** Compu has joined #openttd
08:44:33  *** Compu has joined #openttd
09:22:08  <LordAro> moin
09:34:30  * andythenorth wades into computer science terms
09:35:01  <andythenorth> if I try and describe 'like message queues' as 'async' does that make any sense?
09:35:14  <andythenorth> or does async immediately mean 'XHR and node.js'?
09:42:16  <andythenorth> oof 'async' is such a stupid term in web world
09:42:46  <andythenorth> the common use for async is "I want to synchronise what's on the screen with the backend state"
09:43:04  <andythenorth> so we use async to maintain sync, because otherwise all you've got is a page load
09:43:21  <andythenorth> 'lolz'
09:46:48  <LordAro> async is more like XHR & node rather than message queues
09:47:06  <LordAro> but message queues might be better at maintaining state :p
09:48:53  <andythenorth> I wondered
09:49:27  <andythenorth> message queues are just a form of async according to wikipedia, but people's brains aren't organised according to wiki P
09:50:05  <andythenorth> if I use the wrong terms talking about GS-grf communication, it spends 10 days going in semantic circles :D
09:58:43  * andythenorth revisiting pub-sub
09:58:46  <andythenorth> that's a blast from the past
10:03:03  *** DasPoseidon has joined #openttd
10:25:55  * andythenorth learns new words "Isochronous" and "Anisochronous" :P
10:48:23  *** WormnestAndroid has quit IRC
10:48:36  *** WormnestAndroid has joined #openttd
10:50:29  *** Progman has joined #openttd
11:13:11  *** DasPoseidon has quit IRC
11:15:05  *** DasPoseidon has joined #openttd
11:19:08  *** Samu has joined #openttd
11:31:49  *** J0anJosep has joined #openttd
11:34:20  *** gelignite has joined #openttd
12:06:44  <DorpsGek> [OpenTTD/OpenTTD] SamuXarick updated pull request #8461: Feature: Permanent rivers https://git.io/JLS3A
12:08:15  <DorpsGek> [OpenTTD/OpenTTD] SamuXarick commented on pull request #8461: Feature: Permanent rivers https://git.io/JLSho
12:09:15  <TrueBrain> andythenorth: describe what you want it to do, instead of telling how it should be done; might help avoid these conflicts :)
12:09:24  <TrueBrain> async vs sync is such an implementation detail :)
12:09:54  <TrueBrain> it is why I rather use things like: GS is event-based where NewGRF uses callbacks
12:10:09  <TrueBrain> (first is async, second is sync, but that is just a result of the higher-level choice)
12:10:46  <TrueBrain> (as there is always this one person noting: but you can do event-based async too. Yes, yes you can. But that is not the point :)
12:11:10  <TrueBrain> async = sync, in that last one; what-ever :P
12:11:28  <Samu> I found a "maybe-not-a-bug" about towns trying to check where they can expand with roads. They use a clear command but they don't enforce the tile to have no water, so when checking for rivers, towns think they can build a road there
12:11:42  <Samu> it returns clear for water
12:11:51  <Samu> for river*
12:12:31  <Samu> it's at line 914 town_cmd.cpp
12:14:07  <Samu> the town then goes on with the wrong information, thinking it can expand a road on the river
12:17:42  <andythenorth> ha ha whatever-sync :)
12:17:52  <andythenorth> the best kind of sync
12:18:41  <TrueBrain> what are you syncing about!
12:18:59  <Eddi|zuHause> from what i hear, that is "go". "this can be async, or sync, you never know"
12:19:16  <andythenorth> I am syncing that my syncing could be better
12:19:33  <andythenorth> I'm not even sure what accent makes 'think' 'sync' but it's funny
12:19:38  <Eddi|zuHause> maybe you should go lip-syncing instead :)
12:20:00  <andythenorth> good, we're having a lolz day
12:20:47  <Eddi|zuHause> you started it :p
12:21:22  <andythenorth> lol
12:32:42  <TrueBrain> andythenorth: have you considered only doing GS -> GRF ?
12:32:55  <andythenorth> no but let's explore?
12:33:15  <TrueBrain> your Discussion is severely lacking use-cases, but I cannot really think of a usecase for GRF -> GS
12:33:30  <andythenorth> I could try and generate more use cases
12:33:31  <TrueBrain> (your discussion is basically: either of these 2 solutions, but it fails to state what you are solving :P)
12:33:53  <andythenorth> I can write out some 'problems' in a gist?
12:34:07  <andythenorth> they're more 'opportunity' than 'problem' :D
12:34:13  <TrueBrain> normally you start with "what am I trying to solve", so we can help think in if either of your solution is a good idea :)
12:34:17  <TrueBrain> now I am just full of assumptions :P
12:34:27  <TrueBrain> that is why I am not talking about problems, but about use-cases
12:34:34  <TrueBrain> problems is biased towards "we should fix this as it is broken"
12:34:42  <andythenorth> sometimes the ideas come from what is possible, not the other way round, but I write some more use cases
12:34:43  <TrueBrain> use-cases are just telling you what you expect the system to do in what scenario :)
12:35:16  <andythenorth> we're ok that 8 out of 10 use cases turn out to be terrible in game, and get deleted, yes yes yes?
12:35:26  <andythenorth> otherwise we just nitpick the use case and miss the point :)
12:35:45  <TrueBrain> well, you have some scenarios in mind when you wrote this
12:35:49  <TrueBrain> otherwise you wouldn't have written it :P
12:35:55  <andythenorth> yes I write them down now
12:36:06  <TrueBrain> and ideas cannot be wrong
12:36:08  <TrueBrain> they can be terrible
12:36:11  <TrueBrain> just not wrong :P
12:37:35  <andythenorth> ok I just write them, without pitching 'why' too much, can add that later
12:38:27  *** duckfullstop has quit IRC
12:42:48  *** Progman has quit IRC
12:46:55  <Timberwolf> I wonder how horrific porting https://github.com/JGRennison/OpenTTD-patches/commit/99b2698658660539d0e56cebfdfaf033c17acfd7 back to trunk would be.
12:47:09  <TrueBrain> trunk .. hihi :)
12:47:11  <TrueBrain> sorry :p
12:47:32  *** Eddi|zuHause has left #openttd
12:47:44  *** Eddi|zuHause has joined #openttd
12:48:10  <Timberwolf> It seems to build on a few caching things introduced in JGR, but makes a big improvement.
12:51:44  * andythenorth needs more use cases :P
12:51:46  <andythenorth> let's see
12:51:57  *** sla_ro|master has quit IRC
12:52:12  <andythenorth> I have a whiney use case which is 100% possible already, but I've been told "Don't do that" by multiple people
12:52:16  <andythenorth> let's write it anyway!
12:57:18  <DorpsGek> [OpenTTD/OpenTTD] TrueBrain commented on pull request #7653: Add: BuildVehicleSmartGUI https://git.io/JL9es
12:57:21  <DorpsGek> [OpenTTD/OpenTTD] TrueBrain closed pull request #7653: Add: BuildVehicleSmartGUI https://git.io/fjXmK
12:57:36  <TrueBrain> that was an interesting PR .. lots of activity, but .. nothing after that. And then you read the date: Jul 2019 .. oef
13:00:10  <DorpsGek> [OpenTTD/OpenTTD] TrueBrain commented on pull request #7607: Feature: Rail/Road/Tram/Canal-Planner (WIP) https://git.io/JL9e0
13:00:13  <DorpsGek> [OpenTTD/OpenTTD] TrueBrain closed pull request #7607: Feature: Rail/Road/Tram/Canal-Planner (WIP) https://git.io/fjB7y
13:06:58  <DorpsGek> [OpenTTD/OpenTTD] TrueBrain commented on pull request #7745: Feature: setting for more flexible town spacing https://git.io/JL9eX
13:07:01  <DorpsGek> [OpenTTD/OpenTTD] TrueBrain closed pull request #7745: Feature: setting for more flexible town spacing https://git.io/JeOBG
13:11:48  <DorpsGek> [OpenTTD/OpenTTD] TrueBrain commented on pull request #7895: Savegame regression testing https://git.io/JL9eF
13:13:42  <TrueBrain> LordAro: can you give me an indication what the state of https://github.com/OpenTTD/OpenTTD/pull/8285 is to me? Do we want this? Did it went out-of-scope too much? Was it just forgotten? No judgement, just trying to get a feel for it :)
13:16:56  <TrueBrain> and that leaves the list with 1 more PR I have no clue what to do with .. clearly no dev wants to touch it .. I need to understand the subject a lot better to form an opinion :)
13:17:11  <TrueBrain> the rest of the list is pretty much in good shape, as far as I am concerned
13:17:41  <michi_cc> Which PR is the no-touch PR?
13:17:56  <TrueBrain> ah, you are here, good, as I was meaning to ask you about it :D
13:18:05  <TrueBrain> as you reopened it :D
13:18:21  <TrueBrain> https://github.com/OpenTTD/OpenTTD/pull/7000
13:18:35  <michi_cc> Oh, that one.
13:18:40  <TrueBrain> from the PR-point-of-view, you reopened it after someone was being a bully
13:18:45  <TrueBrain> but I am sure there was more to it than that :P
13:18:59  <Eddi|zuHause> i was about to guess #7000 :p
13:19:17  <TrueBrain> I know way too little about NewGRF to even remotely understand what the PR is about
13:19:23  <TrueBrain> so I can only judge the flow of events :)
13:20:02  <michi_cc> It's the quitessential "add some NewGRF stuff that is usefull for specific case, but not according to some master plan"-PR.
13:20:14  <TrueBrain> ah; we have a lot of those :D Not always a bad thing
13:20:21  <TrueBrain> but for NewGRFs always a bit more troubling
13:20:31  <michi_cc> I would just merge it, but I don't write NewGRFs either and apparently lots of people have opinions on that one.
13:20:46  *** glx has joined #openttd
13:20:46  *** ChanServ sets mode: +v glx
13:21:05  <Eddi|zuHause> i think we should make another pass over it to clean it up
13:21:13  <Eddi|zuHause> as i don't remember half the things i did
13:21:30  <TrueBrain> yeah, and you failed to address 1 comment for years now :P :D (I am just teasing)
13:21:36  <michi_cc> Well, it needs a rebase/conflict solving anyway :)
13:21:50  <TrueBrain> what would it take to put this in a bigger picture
13:22:04  <TrueBrain> not a master-plan as such, but to give it a bit more body?
13:22:15  <Eddi|zuHause> an idea what the bigger picture would be
13:22:41  <michi_cc> The bigger picture is: how to best support/code multi-power train engines (e.g. electro/diesel).
13:23:18  <michi_cc> Like haveing different HP for different tracktion types, but supporting any possible NewGRF railtype.
13:23:59  <TrueBrain> so if this is that obvious, what is the problem exactly? (sorry to ask, but again .. I am not connected to NewGRF :P)
13:26:06  <michi_cc> With the PR? Or the bigger picture?
13:26:16  <TrueBrain> both :D
13:26:47  <TrueBrain> just that nobody wrote down what a good approach would be?
13:26:53  <michi_cc> For the PR, rebase and I'll merge it. I don't have problems with that :)
13:27:13  <TrueBrain> yeah, but if that pisses off other people, we are not winning anything :)
13:27:13  <Eddi|zuHause> "Global Var 3F", that was a very experimental hacky thing that i'm not sure it even works
13:28:03  <michi_cc> For the bigger picture: Engines have exactly one railtype they belong to, and from which they take powered/compatible etc. Which makes having true multi-railtype engines hard.
13:28:21  <TrueBrain> ah, okay, that I understand :D
13:29:00  <michi_cc> Work-arounds right now are either hidden dummy railtypes or railtype tables that try to be exhaustive (but must necessarily fail in the future).
13:29:19  <TrueBrain> so people are doing it anyway already
13:29:22  <TrueBrain> that is always good to know :)
13:30:06  <TrueBrain> anyway, before we merge we should talk to frosch honestly
13:30:23  <michi_cc> Roadtypes have a similar issue (see e.g. https://www.tt-forums.net/viewtopic.php?p=1239660#p1239660), but different than railtypes because they don't distinguish between compatible and powered.
13:30:39  <TrueBrain> and Eddi|zuHause , if you can clean up the PR to not include stuff you are no longer sure about, that might help the process for sure :D
13:30:46  <andythenorth> I need 'spoiler' in gist :P
13:30:49  <TrueBrain> would be greatly appreciated
13:31:13  <michi_cc> #7000 was initially mostly around the difference between compatible and powered.
13:32:38  <michi_cc> TrueBrain: Being a pain-in-the-arse as never stopped people from trying things, even if they aren't necessarily smart in the long term :) See e.g. regearing cargo or railtypes with 5 km/h speed limit increments.
13:33:06  <michi_cc> Or snail playing around with simulation rack rails.
13:33:11  <TrueBrain> I always like it when people went through lengths to do something despite the game not really supporting it
13:33:18  <TrueBrain> it shows that no matter what we do, they are going to do it anyway
13:33:23  <TrueBrain> which makes it more compelling to add it
13:33:31  * andythenorth has videos
13:33:38  <andythenorth> of dumb things like that
13:33:41  <TrueBrain> (it is a positive thing for me, to read people are already doing it, basically :D)
13:33:41  <andythenorth> for another day
13:34:12  <michi_cc> Which is the main reason why I'm pro #7000. People do it anyway, and unless somebody has a better plan ready to go, it makes no sense to leave people waiting for some indeterminate future.
13:34:32  <andythenorth> ok full version, including "why can't do it now" https://gist.github.com/andythenorth/c9b0cbeea881859d091dc5a3c37a25c7  but......redacted version might be better Truebrain I think https://gist.github.com/andythenorth/20f62a064656e4ce17ea53ce97e36f79
13:34:50  <andythenorth> "why can't do it now" kind of frames it prematurely
13:34:54  <TrueBrain> michi_cc: that is true iff (yes, I used iff) it doesn't break other things in the future completely and irreversible :)
13:35:02  <TrueBrain> which is always a gamble, so subjective
13:35:15  <TrueBrain> but it requires a domain-expert to judge ... which is not me :D
13:36:38  <michi_cc> Adding props and variables to NewGRF will never irreversibly break things. At worst, OTTD can always ignore them or supply a fixed dummy value. As such, the absolute worst would be to break some NewGRFs in some way.
13:37:04  <TrueBrain> useful information :D
13:37:21  <TrueBrain> so yeah, if Eddi|zuHause can clean up the PR, we can ask frosch if there are any blockers, and merge it :)
13:38:06  <Eddi|zuHause> we definitely need an exhaustive test-case GRF for the var 3F stuff, because that would be a fairly significant addition to the specs
13:38:35  <TrueBrain> I would suggest we reduce the PR to be minimal but useful :)
13:38:54  <TrueBrain> andythenorth: tnx; now playing Factorio, will read soon :)
13:39:10  <andythenorth> I might clean up the formatting TBH
13:39:13  <andythenorth> bit rushed
13:39:30  <TrueBrain> I don't care; I just want to see the world you are seeing
13:41:03  <Eddi|zuHause> might be a scary place, the world someone else is seeing :p
14:03:59  <DorpsGek> [OpenTTD/OpenTTD] michicc commented on pull request #8451: Codechange: Simplify GetRailDepotTrack. https://git.io/JL9sd
14:04:11  <LordAro> TrueBrain: (re 8285) that's more or less it. just got overly complex for what it was actually doing
14:04:41  <TrueBrain> what are we going to do with it?
14:04:46  <TrueBrain> ask him to make it into smaller PRs?
14:04:47  <michi_cc> Contra-opinions on #8451?
14:05:19  <LordAro> michi_cc: i agree with you :)
14:05:22  <TrueBrain> the latter is convincing to me!
14:05:25  *** DasPoseidon has quit IRC
14:05:29  <LordAro> TrueBrain: redo it ourselves is probably easier :p
14:05:35  <TrueBrain> if compilers do the right thing, it is a useless change :)
14:05:51  <TrueBrain> LordAro: okay, good enough answer to me :)
14:06:54  <michi_cc> It's also semantically wrong as the map stores a DiagDir and we but these explicit conversion functions in exactly to not have to assume how each type is built bit-wise.
14:07:34  <DorpsGek> [OpenTTD/OpenTTD] michicc closed pull request #8451: Codechange: Simplify GetRailDepotTrack. https://git.io/JLyUV
14:09:01  <Eddi|zuHause> yeah, go with the descriptive version, not the bitstuffing version
14:10:47  <LordAro> changes without purpose make me uncomfortable anyway
14:11:14  <TrueBrain> a local itch :)
14:18:35  <Samu> when I type restart, sometimes I get an assert [img]https://i.imgur.com/8iKiGr1.png[/img]
14:18:49  <Samu> i tried to reproduce it, but I can't
14:19:10  <Samu> I don't know how to trigger it
14:21:38  <michi_cc> You start by hitting Retry to get the exact call stack that leads to the error.
14:24:26  <Samu> https://pastebin.com/raw/8ZcDZXGH
14:26:35  *** JGR has joined #openttd
14:27:20  <JGR> That is probably this: https://github.com/JGRennison/OpenTTD-patches/commit/530a3a2f4d8229836467a380e71a264cb00729f3
14:27:27  <JGR> I'd forgotten about that and can PR it later
14:27:38  <Samu> honestly, I don't like it when restart starts loading the savegame again, instead of starting all over
14:27:46  <Samu> when did that change?
14:29:21  *** JGR has quit IRC
14:30:25  <LordAro> recently
14:30:56  <Samu> i can't reproduce world generation
14:31:52  <Samu> was trying to reproduce world generation with a different code to check for changes in towns
14:32:10  <Samu> but thx to restart loading the same savegame, I can't do it anymore
14:34:06  <TrueBrain> so .. use "newgame" instead?
14:35:39  <Samu> that would imply I now the exact game seed and have the exact game settings
14:37:11  *** nielsm has joined #openttd
14:42:32  <LordAro> well do that then
14:44:14  <Eddi|zuHause> currently trying to figure out what https://github.com/OpenTTD/OpenTTD/commit/d5f05fb7813c2c835010932aee6e5e9edf93c82b was trying to achieve
14:44:40  <Eddi|zuHause> as that's the one that conflicts with #7000
14:48:32  <Samu> 3044240721
14:49:02  <TrueBrain> 5485416597 it says here
14:49:06  <TrueBrain> you are us that is correct?
14:50:20  <Samu> there are differences in the bottom town: https://i.imgur.com/HVuE5ro.png
14:50:45  <Samu> so, changing the code here actually affects how the town generates
14:50:57  <TrueBrain> and the industries! Think about the forest!
14:51:25  <Samu> ignore industries for now, towns are generated first
14:51:28  <FLHerne> Eddi|zuHause: I think it was related to the tests frosch made for https://github.com/OpenTTD/nml/pull/175
14:52:10  <Eddi|zuHause> i think it just shuffled around some code, i think i can deal with that
14:53:04  <FLHerne> No, I was probably wrong
14:55:48  <DorpsGek> [OpenTTD/OpenTTD] Eddi-z updated pull request #7000: Some NewGRF variables concerning railtypes https://git.io/fhI7h
14:56:34  <DorpsGek> [OpenTTD/OpenTTD] Eddi-z commented on pull request #7000: Some NewGRF variables concerning railtypes https://git.io/JL9r9
15:03:56  <DorpsGek> [OpenTTD/OpenTTD] SamuXarick opened issue #8462: Towns testing whether a road is allowed on a river tile return true https://git.io/JL9o3
15:04:48  <michi_cc> Eddi|zuHause: Somebody forgot the modify 'condtype > 0x0E' when adding NRT. Frosch made that more explicit by cleanly separating the three different cases for the future.
15:08:19  <DorpsGek> [OpenTTD/OpenTTD] michicc commented on pull request #7000: Some NewGRF variables concerning railtypes https://git.io/JL9oW
15:08:59  <michi_cc> Eddi|zuHause: One bug, but otherwise +1 from me.
15:12:55  <andythenorth> oof ebaying things is boring
15:12:58  * andythenorth derails topic
15:13:10  * andythenorth clearing out some model trains
15:41:36  <DorpsGek> [OpenTTD/OpenTTD] J0anJosep commented on pull request #8451: Codechange: Simplify GetRailDepotTrack. https://git.io/JL9KK
15:44:12  *** Progman has joined #openttd
15:47:32  *** andythenorth_ has joined #openttd
15:54:22  <DorpsGek> [OpenTTD/OpenTTD] Eddi-z updated pull request #7000: Some NewGRF variables concerning railtypes https://git.io/fhI7h
15:54:42  *** andythenorth has quit IRC
15:54:59  <Eddi|zuHause> michi_cc: i think that was right?
15:56:03  <TrueBrain> andythenorth_: re: gist; most of what you describe requires a concept of regions .. not sure if GS <-> GRF is going to solve that for you :)
15:56:18  *** Flygon has quit IRC
15:58:11  <TrueBrain> but tnx for the write-up, makes it a bit more clear what you talk about
15:58:36  <Eddi|zuHause> "regions" might be a thing for the Town AI stuff
15:58:39  <andythenorth_> yes GS<->GRF is just a trojan horse to get it discussed
15:58:54  <TrueBrain> I can fully imagine GS -> GRF can be useful; I am just not so sure about GRF -> GS. That sounds unwanted, from my perspective
15:58:57  <andythenorth_> also I am going to experiment with grf industry<->town and see how far it goes
15:59:09  <TrueBrain> of course there are minor things to fix, like making a "town effect" without side-effect in cargos
15:59:12  <TrueBrain> but that is relative easy :P
15:59:30  <TrueBrain> yeah, the problem with such "trojan horses" is that the wrong thing gets discussed ;)
15:59:54  <TrueBrain> so it might be more fruitful to talk through some ideas people have, and see how we can make it so you can build that :D
16:00:17  <andythenorth_> the issues in the discussion remain valid issues, they're just not the interesting ones
16:00:57  <TrueBrain> I am still amazed you cannot close or label Discussions
16:01:01  <andythenorth_> grf-global register would be useful and probably harmless, but that's 1 point of several
16:01:39  <andythenorth_> and the packaging or expression of dependency for GS / GRF is a bit WTF?
16:01:49  <andythenorth_> like I could make a FIRS companion GS but I've been told not to
16:01:54  <TrueBrain> there btw has to be some community-based convention when you do stuff like this; but that in most games works itself out in a few months
16:01:55  <andythenorth_> because players won't understand it
16:02:19  <andythenorth_> told / reminded why it won't work /s
16:02:19  <TrueBrain> I have been told "not to" many times in my life
16:02:24  <andythenorth_> nah 'told' is wrong
16:02:33  <andythenorth_> people pointed out why my idea will fail
16:02:41  <TrueBrain> on paper, every idea fails
16:02:41  <andythenorth_> saving me time helpfully
16:02:48  <TrueBrain> I am more curious what happens if someone tries :D
16:03:01  <andythenorth_> odd that https://github.com/andythenorth/town-experiments-GS
16:03:04  <andythenorth_> TEGS
16:03:04  <TrueBrain> but, given you can only have 1 GS, things are a bit more difficult
16:03:21  <andythenorth_> also I don't understand how people write them
16:03:42  <andythenorth_> as far as I can tell so far, it's pretty much 'start a new game' every time you want to test a change
16:03:48  <andythenorth_> maybe I doin it wrong :P
16:04:05  <TrueBrain> for AIs you can just reload from the GUI; I assume GS works the same
16:04:09  <andythenorth_> I have switched to using JGR for GS authoring, seems to do more
16:04:14  <andythenorth_> but reload isn't permitted
16:04:24  <andythenorth_> unless it's a setting I miss
16:04:25  <TrueBrain> (GS was build on AI, but I remember it a lot less more vague than I do AIs :P)
16:04:27  <andythenorth_> or a GS config item
16:04:41  <andythenorth_> adventures in GS!
16:04:55  <TrueBrain> lot less more vague .. that is FANTASTIC English, and not wrong AT ALL
16:05:13  <andythenorth_> perfectly English understandable
16:05:23  <andythenorth_> I will finish this ebay crap and try some more TEGS nonsense
16:06:38  <TrueBrain> well, I am going to have some dinner :D
16:06:39  <TrueBrain> ha!
16:13:25  <DorpsGek> [OpenTTD/OpenTTD] 2TallTyler opened pull request #8463: Change: Default settings improved for new players https://git.io/JL96K
16:19:49  <Eddi|zuHause> michi_cc: i'm thinking the same kind of limit check is missing on the action 7 part
16:20:05  <LordAro> TrueBrain: you wouldn't happen to have a copy of http://hg.openttd.org/developers/yexo/airports.hg/ anywhere, would you?
16:22:05  <andythenorth_> so....can I generate a GS from a python compile :P
16:22:07  <andythenorth_> let's find out
16:22:42  <michi_cc> Eddi|zuHause: Looks right, and yes, the Action 7 is the same. We don't want out-of-bounds reads from untrusted input.
16:23:07  <TrueBrain> LordAro: in archives likely, I can dig for it later tonight if you like
16:23:33  *** Wormnest has joined #openttd
16:23:36  <LordAro> TrueBrain: if you could, that'd be great
16:23:39  <LordAro> no rush though :p
16:23:46  <LordAro> something like that probably shouldn't die
16:23:53  <LordAro> (newgrf airports v2)
16:24:57  <LordAro> i definitely remember a patch somewhere that meant that aircraft reversed out of their bays at airports, which i thought was really neat
16:24:58  <Eddi|zuHause> hm... what exactly is the difference between railtype_map and railtype_list?
16:25:17  <LordAro> can't remember who wrote it or anything else about it now :/
16:25:23  <Eddi|zuHause> i might have used the wrong one
16:26:14  <Eddi|zuHause> ok, no, sounds right.
16:26:16  <andythenorth_> "I am good at GS" :P https://grf.farm/images/TEGS-1.png
16:26:30  <Samu> i placed a town near a tunnel: https://i.imgur.com/eQ66bA9.png
16:26:36  <andythenorth_> but can I make a FIRS detector?
16:28:11  <andythenorth_> oh I missed industry closure off the list of use cases :|
16:28:13  <andythenorth_> oopsie
16:28:39  <andythenorth_> and industrial revolutions
16:28:52  * andythenorth_ asleep at wheel
16:30:11  <michi_cc> For the town effect is at least a byte everywhere. We could simply allow NewGRFs to define additional effect that do nothing except to be usable by GS for e.g. town growth.
16:30:52  <andythenorth_> there's some adjacent issue with cargodist and town cargos also
16:31:03  <andythenorth_> can't remember details
16:32:02  <andythenorth_> michi_cc would that be additional discrete effects, or just a single flag "town cargo"?
16:32:13  * andythenorth_ doesn't have any idea which is better
16:34:22  <michi_cc> Additional values, othwise you couldn't attach separate goals to them.
16:34:37  <andythenorth_> seems fine
16:35:38  <michi_cc> OTTD supplies a built in goal according to town effect for GS (in addition to the complete growth control).
16:35:55  * andythenorth_ looks in NoGo spec
16:36:40  <andythenorth_> oh there's GSTownEffectList also
16:36:47  <DorpsGek> [OpenTTD/OpenTTD] Eddi-z updated pull request #7000: Some NewGRF variables concerning railtypes https://git.io/fhI7h
16:37:14  <DorpsGek> [OpenTTD/OpenTTD] Eddi-z updated pull request #7000: Some NewGRF variables concerning railtypes https://git.io/fhI7h
16:37:52  <andythenorth_> I found SetCargoGoal(), is that the built in?
16:37:56  * andythenorth_ noob at GS
16:38:13  <michi_cc> Yes
16:38:16  <DorpsGek> [OpenTTD/OpenTTD] Eddi-z commented on pull request #7000: Some NewGRF variables concerning railtypes https://git.io/JL9Pv
16:40:01  <michi_cc> Now we just have to decide whether to wait for frosch or not...
16:40:18  <andythenorth_> hmm GS can do cdist stuff (read-only) it seems
16:40:23  <DorpsGek> [OpenTTD/OpenTTD] michicc commented on pull request #7000: Some NewGRF variables concerning railtypes https://git.io/JL9XU
16:40:40  <andythenorth_> so we could have towns that hate nuclear materials going through them
16:40:49  <andythenorth_> so realism
16:42:11  <andythenorth_> https://nucleartrains.wordpress.com/faq/
16:43:22  * andythenorth_ can't remember what goes wrong currently if too many cargos have town effect flag set
16:43:43  <andythenorth_> think it's just an aesthetic problem mostly
16:44:16  *** TooTallTyler has joined #openttd
16:44:51  <andythenorth_> ha it won't help that FIRS sets some to TOWNGROWTH_GOODS which is a none-thing
16:48:09  <Eddi|zuHause> i somehow keep accumulating browser tabs for the same tasks, because i click on DorpsGek links all the time :p
16:51:13  <andythenorth_> same
16:51:13  <andythenorth_> PEBKAC
17:07:38  *** sla_ro|master has joined #openttd
17:15:10  <michi_cc> andythenorth_: It's not a default thing, but a GS can still do something with it.
17:16:03  <andythenorth_> I'm curious what author would do
17:16:17  * andythenorth_ has GS listing town effect cargos now
17:16:51  <andythenorth_> I'm not very good at ideas for this, I find town growth a bad mechanic, they just get in the way of my trains :)
17:17:38  <glx> GS can totally ignore town effect of cargos and decide to grow a town depending on any cargo :)
17:18:28  <andythenorth_> I know town growth has a playerbase, so I'm not being rude about other people's choices...
17:18:43  <andythenorth_> but in my games, growing a town is like 'congrats, you ruined this area of the map for building routes'
17:19:07  <andythenorth_> 'and you also blocked all your passenger stations with waiting passengers'
17:19:14  <andythenorth_> it's like the opposite of winning :)
17:22:38  <TooTallTyler> Gotta have towns to fill your passenger trains though
17:22:46  <Eddi|zuHause> not sure how your communication layer would help with that :p
17:23:17  <DorpsGek> [OpenTTD/team] absay opened issue #115: [es_MX] Translator access request https://git.io/JL9yJ
17:23:52  <andythenorth_> Eddi|zuHause me neither.  How would it help with that?
17:24:05  <TooTallTyler> My solution to towns taking over the map is a lower town and industry density
17:24:42  *** rptr_ has joined #openttd
17:25:23  <Eddi|zuHause> with the Town AI stuff you could designate towns to stay villages
17:27:29  <andythenorth_> I am curious about varying cargo payment rates
17:31:43  <andythenorth_> hmm towns can already stay as villages by preventing growth?
17:31:45  <Timberwolf> This is what drove me to write Villages Is Villages.
17:33:09  <andythenorth_> I guess I am trying to find ways to make towns...more interesting...as they grow, instead of just...bigger
17:33:22  <andythenorth_> not sure how it all fits together
17:33:39  <andythenorth_> but it's also related to having a larger grid, so routes can be fitted in
17:33:58  <Timberwolf> As implied, you need something that makes growth a reward rather than an annoyance.
17:34:07  <andythenorth_> increasing gameplay depth?
17:34:11  <andythenorth_> more cargos to transport?
17:34:25  <DorpsGek> [OpenTTD/OpenTTD] kiwitreekor updated pull request #7575: Feature: Industry production graph https://git.io/fjc3i
17:34:32  <andythenorth_> but transporting more is usually a malus currently, as town is already choked
17:34:54  <Timberwolf> Yes.
17:35:13  <Timberwolf> Maybe if the vehicle distributor was input-limited based on the population of its nearest town?
17:35:22  <andythenorth_> possible
17:35:34  <andythenorth_> limits are very...tricky...with cargodist
17:35:43  <TooTallTyler> One thing I did with Improved Town Industries is add a population requirement to many big processing industries. Steel Mills only spawn in towns population += 300, for example. If I wasn't worried about having all industries available from the start, it could be interesting to "unlock" industries by growing towns.
17:35:45  <andythenorth_> I am going to try having town 'satisfaction' which affects some industry production
17:35:46  <Timberwolf> Oh, yes - hadn't thought of that issue.
17:36:12  <TooTallTyler> (300 population is a city in 1856)
17:36:12  <andythenorth_> TooTallTyler if the game could handle spawning industries reliably, that would be an interesting mechanice
17:36:18  <andythenorth_> mechanic *
17:36:54  <TooTallTyler> I haven't encountered problems with spawning reliability, but I have a lot fewer industry types than FIRS
17:37:15  <Timberwolf> I guess that also breaks any attempt to make industries require passengers, as you'd be relying on cargodist to route them there.
17:37:16  <andythenorth_> it's very hard to make a new type available during gameplay
17:37:34  <TooTallTyler> How so?
17:37:57  <TooTallTyler> I've got it working pretty reliably
17:38:08  <andythenorth_> can't remember the details, but all the industry transition stuff was ripped out of FIRS
17:38:17  <andythenorth_> and I've removed all the intro dates
17:38:51  <Timberwolf> I think having an industry output level dependent in part on the growth state of the nearest town would be interesting. (Like the scrap yard, but maybe more complex)
17:38:55  <andythenorth_> I guess if it works, maybe it works now
17:39:11  <andythenorth_> Timberwolf that's the route I'm thinking
17:39:16  <Timberwolf> Perhaps more for things like factories and secondaries.
17:39:29  <andythenorth_> use growth state as a proxy for labour force
17:39:29  <Timberwolf> Like "this factory needs a big enough town to supply its workers"
17:39:44  <andythenorth_> it would be another production booster
17:39:51  <andythenorth_> I am going to explore that after FIRS 4 release
17:39:56  <andythenorth_> and electricity and gas grids
17:39:58  <Timberwolf> Or sth like "automation supplies" as an alternative.
17:40:03  <TooTallTyler> Growth state meaning the town is currently growing, or it's larger than some minimum population?
17:40:08  <andythenorth_> dunno :)
17:40:12  <andythenorth_> some level of sophistication?
17:40:24  <andythenorth_> I wish I could just leave that to GS or house grf TBH
17:40:30  <andythenorth_> doesn't interest me at all
17:40:48  <michi_cc> andythenorth_: Getting new industries requires others closing. As you are very pro closure, ... :p
17:41:06  <andythenorth_> maybe it needs skyscrapers, maybe it needs 200 mill worker cottages TooTallTyler :)  Dunno, I don't mind
17:41:17  <andythenorth_> michi_cc maybe that was the issue
17:41:42  <Eddi|zuHause> andythenorth_: for example the original idea with TaI was that villages have a different set of houses to choose from
17:41:49  <andythenorth_> nice idea
17:42:00  *** rptr_ has quit IRC
17:42:15  <Timberwolf> Yes, I liked the TaI thing where the town randomly chose what "type" it would be.
17:42:27  <Eddi|zuHause> so they would e.g. use 2x2 houses with low population
17:43:08  *** J0anJosep has quit IRC
17:44:44  <andythenorth_> ok so...industry closure
17:44:53  <andythenorth_> I have a few confusions
17:45:09  <andythenorth_> (1) it was recommended not to solve it in newgrf because newgrf has no view on the map
17:45:14  <DorpsGek> [OpenTTD/OpenTTD] kiwitreekor commented on pull request #7575: Feature: Industry production graph https://git.io/JL9St
17:45:19  <andythenorth_> (2) what should cause an industry to close?
17:45:33  <andythenorth_> I hate the original mechanic, although it was very funny the first time it happened to me
17:45:45  <andythenorth_> 'funny' / 'troll' /s
17:45:50  <andythenorth_> childhood traumas :P
17:46:04  <glx> usually the first time it happens right when you finish to build the line
17:46:28  <andythenorth_> exactly what happened to me
17:46:32  <andythenorth_> 1994 memories
17:46:48  <andythenorth_> it was a steel mill, I can still recall the moment exactly :P
17:47:06  <TooTallTyler> Industry closure is probably the key reason why introduction dates work for me and not for you
17:48:06  <andythenorth_> yes
17:48:31  <Eddi|zuHause> industries always closed on me in TTO, except the few times where i wanted them to close because they were in the way
17:49:03  <andythenorth_> I have a few ideas around industry 'health'
17:49:07  <andythenorth_> and also 'unluckiness'
17:49:27  <andythenorth_> but I don't know why an industry _should_ close :P
17:49:55  <Eddi|zuHause> dunno either
17:51:02  <Eddi|zuHause> the worst part is that you only get a "industry is about to close" message, at which point you can't do anything about it anymore
17:51:26  <DorpsGek> [OpenTTD/team] glx22 commented on issue #114: [ru_RU] Translator access request https://git.io/JLSq3
17:51:34  <Eddi|zuHause> also, you might miss it, and then you won't know that the industry that you're trying to connect now is already doomed
17:51:49  <DorpsGek> [OpenTTD/team] glx22 commented on issue #115: [es_MX] Translator access request https://git.io/JL9yJ
17:53:05  <TooTallTyler> I like the secondary industry mechanic where it only closes after 5 years of no production. Obviously this won't work for primary industries though.
17:53:47  <andythenorth_> https://youtu.be/c4ZggZ39fN8?t=411
17:54:33  <andythenorth_> "uh the planet just exploded sir"
17:56:21  <FLHerne> Greatest film ever
17:56:34  <Eddi|zuHause> TooTallTyler: the problem with that is that usually the player starts serving only a small area of the map, and the rest of the map suddenly goes empty after 5 years
17:56:49  <FLHerne> "Hey....bomb!"
17:57:32  <TooTallTyler> But don't new industries spawn to replace them?
17:57:42  <andythenorth_> it was part of my degree course :P
17:58:25  <andythenorth_> so what's the fundamental reason for closing industries?
17:58:33  <andythenorth_> [other than to make space for new types]
17:59:07  <Eddi|zuHause> to annoy the player by disrupting their network
17:59:19  <TooTallTyler> to give andythenorth childhood trauma
17:59:23  <andythenorth_> yes!
17:59:36  <andythenorth_> and then I spend 26 years trying to recover
17:59:52  <Eddi|zuHause> and, did you?
18:00:01  <Timberwolf> I agree the worst part is the announcement is the point of no return.
18:00:05  <TooTallTyler> An actual reason: if you don't like where an industry spawned, ignore it and it will go away
18:00:41  <andythenorth_> Eddi|zuHause only by obsessively trying to remake the thing that hurt me!
18:00:58  <andythenorth_> the industry message could be handled in grf
18:01:10  <andythenorth_> spawning a message and also putting it in the industry window
18:01:16  <andythenorth_> but that relies on grf handling the closure
18:01:27  <andythenorth_> and we didn't discover any good random seed to distribute closures with
18:01:27  <Samu> TooTallTyler, this may be related with default settings: https://github.com/OpenTTD/OpenTTD/issues/7872
18:01:40  <Samu> since you're working on that
18:01:45  <andythenorth_> I tried some, but I just got waves of simultaneous closure on large maps
18:01:58  <Samu> my english :(
18:01:59  <Eddi|zuHause> really, message in the industry window should be core game
18:02:02  <andythenorth_> reducing the probability results in waves of 'no closure' :P
18:02:29  <andythenorth_> I did wonder about using the town index as a seed factor, as it's probably unique-ish per industry
18:02:52  * andythenorth_ didn't try it
18:03:15  <andythenorth_> Eddi|zuHause not GS?
18:04:29  <Eddi|zuHause> what would the GS even know about the industry?
18:05:43  <Eddi|zuHause> other than that there is an industry, and possibly a list of input/output cargos
18:07:47  *** DasPoseidon has joined #openttd
18:08:45  <andythenorth_> it has the view on the map
18:08:48  <TooTallTyler> Samu: That's a separate issue, I think. My PR tweaks default settings for new players; yours changes default map settings to fix an industry not spawning.
18:08:55  <andythenorth_> it knows how many industries there are, and how many types there are
18:09:41  <andythenorth_> and it can know which industries closed recently, and where
18:09:57  <TooTallTyler> Are you proposing a GS to manage a specific industry newgrf, or all industries?
18:10:06  <andythenorth_> I don't have a proposal
18:10:08  <andythenorth_> :)
18:10:14  <Eddi|zuHause> so, a GS might reasonably tell an industry "go close yourself with <reason>"
18:10:35  <andythenorth_> on the one hand we have a vague use case, we don't know why we want to close industry
18:10:44  <Eddi|zuHause> but still the message "this industry will close in <X> months for <reason>" should be core game
18:10:48  <andythenorth_> and on the other we have a crippled spec, so we don't know how we can close industry
18:10:57  <andythenorth_> the two do not make good outcome :)
18:11:24  <andythenorth_> Eddi|zuHause so you think that should be provided semaphore thing?
18:11:27  <andythenorth_> and it could be reset?
18:11:42  <TooTallTyler> I agree that it should be core game. Secondary industries are especially easy, just send a notification after 4 years of no production. Unless a player delivers something within the next year, the industry closes at year 5 as expected
18:12:08  <andythenorth_> historically, fixing that has been refused as content (grf) can do it
18:12:43  <TooTallTyler> That's silly
18:12:54  <Eddi|zuHause> there's at least 3 different problems here. 1) it's currently unclear to the player that an industry is about to close, 2) there's no way to reverse a closure announcement, and 3) there's disputed responsibility between GS and GRF who gets to decide closure
18:13:10  <andythenorth_> +1
18:13:32  <andythenorth_> 1) and 2) can be solved in newgrf though
18:14:04  <andythenorth_> but that introduces problem 4) nobody found a way for newgrf to reliably close industry without waves of closure
18:14:08  <Eddi|zuHause> 1) should be core, 2) can possibly stay newgrf, 3) iunno
18:14:13  *** Wolf01 has joined #openttd
18:15:05  <andythenorth_> 4) must be solvable somehow, just hasn't been tried properly
18:15:12  <glx> 1) may be fixed by GUI modification, like addind the info after industry name in industry list
18:15:23  <glx> *adding
18:15:27  <andythenorth_> can the industry XY position be used to spread out closures?
18:16:06  *** snail_UES_ has joined #openttd
18:16:15  <andythenorth_> all it needs is a guaranteed unique random number per industry type, that doesn't have pathological cases (like 4000 years)
18:16:36  <andythenorth_> and doesn't collide when a new industry of the type opens
18:16:49  <andythenorth_> and doesn't collide if an industry closure counter is reset, then triggered again
18:16:56  <Eddi|zuHause> andythenorth_: conceptually "stop waves" is the opposite of "random"
18:16:59  <andythenorth_> yes
18:17:16  <andythenorth_> I realised after I wrote them, my requirements are self-satire :(
18:17:18  <andythenorth_> unintended
18:17:44  <TrueBrain> LordAro: so let me think what would be the best place to find such mercurial repo ... as those deprecated years ago :D Euhm ... hmmmm
18:17:49  <andythenorth_> GS can simply choose to 'close 1 of this type' per month
18:17:54  <andythenorth_> none of these silly requirements
18:18:53  <Wolf01> andythenorth_, you have a strange trailing char, like a cat tail
18:19:08  *** andythenorth_ is now known as andythenorth
18:19:40  <andythenorth> I think I'm still stuck at 'why' currently
18:19:45  <andythenorth> 'how?' is less interesting
18:20:01  <andythenorth> it's just that the 'how?' prevents testing 'why?' ideas in current spec
18:20:17  <Wolf01> BTW, I was thinking about an industry set where only the base industries are generated, you may fund the construction of new ones which grants different benefits when combined
18:20:45  <Eddi|zuHause> that should be possible
18:21:15  <andythenorth> you can count industries of type x on the map
18:21:32  <andythenorth> industry tech tree / progression / levels probably can be done
18:22:31  <TooTallTyler> There's a parameter in ITI to generate primary industries only, and you can fund secondary industries yourself. The tech tree isn't that interesting though, just save up a bunch of money to afford the next industry.
18:22:52  <TooTallTyler> There's no research requiring specific things to be delivered like in Factorio
18:26:14  <DorpsGek> [OpenTTD/OpenTTD] DorpsGek pushed 1 commits to master https://git.io/JL9Qq
18:26:15  <DorpsGek>   - Update: Translations from eints (by translators)
18:27:31  <Wolf01> I mean like you have the common wood industry chain wood->sawmill->goods, you will be able to build an industry which sits in the middle of the chain or is an alternative of the sawmill, which accepts I say chemicals/machinery/etc and has double the production of the sawmill, but funding it costs a shitload of money and must be done only by hand
18:27:37  <Samu> this looks too perfect to be a mock up in paint https://user-images.githubusercontent.com/50259667/102848153-f5b91600-43c8-11eb-9dcc-11aeed555951.png
18:28:28  <TrueBrain> LordAro: I found 3 patches (seems to be from an MQ set) and a specs.txt .. let me extract them, see if that is anything you are looking for :)
18:28:57  <TrueBrain> 2010-08-17 14:20 (..)/airports/spec.txt
18:28:59  <TrueBrain> it is old :P
18:29:22  <TooTallTyler> So the Paper Mill? :P Not double the production, but it is quite expensive, accepts chemicals, and produces Goods right away instead of having to ship Lumber first
18:29:59  <TooTallTyler> Regarding industry closure messages, it looks like the closure already checks for an original economy type: https://github.com/OpenTTD/OpenTTD/blob/master/src/industry_cmd.cpp#L2789
18:30:15  <TooTallTyler> Thus negating the grf / base game issue over who gets to close industries
18:31:20  *** iSoSyS has joined #openttd
18:31:21  <TooTallTyler> I think it would be easy to add another check of the same things except for 4 years, and produce a message saying that the industry will close in 1 year if not served
18:31:23  <Eddi|zuHause> TooTallTyler: i'm afraid you're missing a few steps there, as a) we talked about GS, not base game, and b) there's a GRF callback messing with closure
18:31:38  <snail_UES_> hi guys, I saw you just updated pull request 7000
18:31:50  <Eddi|zuHause> snail_UES_: any input is very welcome
18:32:05  <TrueBrain> LordAro: the diffs are useless, but I do have some specs :P
18:32:09  <snail_UES_> “querying poweredness compared to an arbitrary railtype”, how does it work? does it just check for the presence of a catenary?
18:33:05  <Eddi|zuHause> no, you give it a RTT index, and it tells you if your vehicle would be considered "powered" on that railtype
18:33:43  <snail_UES_> an index like a number? or a label?
18:34:01  <Eddi|zuHause> a number, position in your railtype translation table
18:34:07  <snail_UES_> right, I see
18:34:17  <TrueBrain> LordAro: 2009-07-12 18:54 openttd-web/var/repos/hg/developers/yexo/airports.hg/.hg <- seems that is what you are looking for ... 2009 ... so not sure what to expect here :D But let me extract it
18:34:50  <TrueBrain> he also already had a regions patchset :P
18:34:56  <Eddi|zuHause> in NML, you can use the Id of the railtype, which internally is treated as the index
18:35:01  <TrueBrain> (from 2009)
18:35:51  *** iSoSyS has quit IRC
18:35:54  <TrueBrain> Eddi|zuHause: there are several CI warnings in #7000; that needs some attention I guess :)
18:36:52  <snail_UES_> well, my vehicle newGRF initially defines the railtype translation table, by listing all the labels in the matching railtype newGRF, and adding RAIL, ELRL, MONO and MGLV at the end
18:37:07  <Eddi|zuHause> TrueBrain: where would i see them?
18:37:23  <TrueBrain> https://github.com/OpenTTD/OpenTTD/pull/7000/files
18:37:29  <DorpsGek> [OpenTTD/team] absay commented on issue #115: [es_MX] Translator access request https://git.io/JL9yJ
18:37:31  <TrueBrain> GitHub displays warnings inline; it is such a great feature :)
18:37:39  <snail_UES_> so far I check whether a vehicle is powered or not, and whether the axle weight limit supports it or not, by using the “veh_railyupe” function in m4nfo
18:37:45  <snail_UES_> *veh_railtype
18:38:12  <snail_UES_> and that function needs the labels as inputs
18:38:30  <TooTallTyler> Eddi|zuHause: The code I linked only runs if the callback fails, so it wouldn't affect GRFs which use the callback to control industry behavior. I also think a 1-year warning is much more useful as a base game feature than in GS
18:38:55  <snail_UES_> obviously, this doesn’t work if a player doesn’t use my railtype GRF together with the trainset.
18:39:43  <Eddi|zuHause> snail_UES_: yes, checking the railtype label has some problems, with this new variable it should be more robust
18:40:18  <snail_UES_> hmm, ok but it would be quite tricky, wouldn’t it?
18:40:21  <Eddi|zuHause> TrueBrain: ah, i see
18:40:34  <DorpsGek> [OpenTTD/team] TrueBrain commented on issue #115: [es_MX] Translator access request https://git.io/JL9yJ
18:40:56  <Eddi|zuHause> snail_UES_: no, from a GRF point of view, it should be very easy
18:40:59  <snail_UES_> in my standard gauge set I envision multiple types of catenary… AC, DC, different voltages… with some vehicles being able to run on a few of them (as opposed to one and only one)
18:41:43  <snail_UES_> also, ideally a railtype should provide not only the type of power (if any), but also the max axle weight
18:41:54  <snail_UES_> max speed would be unimportant
18:42:35  *** TooTallTyler has quit IRC
18:44:07  <andythenorth> so stack the checks
18:44:14  <andythenorth> or something )
18:44:15  <andythenorth> :)
18:44:51  <andythenorth> snail_UES_ this might have evolved, but I originally requested #7000 to solve the problem of _other_ railtype grfs existing
18:44:52  <snail_UES_> to allow an engine that can run on both 1.5kV and 25kV, I’m envisioning creating a “ghost” railtype that wouldn’t even show up in the purchase list: engines of that “ghost” type would be compatible and powered on both types
18:44:59  <andythenorth> handling your own railtype grf is trivial-ish
18:45:14  <Eddi|zuHause> snail_UES_: so simple example, imagine if you have a diesel/electric hybrid engine, defined for RAIL, you check var 0x63 with parameter 1 (=ELRL), to check if it is currently running on any electrified track. doesn't matter which electrification, so long as the railtype grf sets ELRL vehicles to be powered on that track
18:45:35  <snail_UES_> andythenorth: true, but it would be still be useful coz it’d remove the need of ghost railtypes
18:45:47  <andythenorth> I don't see how tbh
18:46:02  <andythenorth> but I don't understand railtypes, they are super-complicated
18:46:13  <andythenorth> I just wanted a way to ignore them :)
18:46:41  <TrueBrain> LordAro: 259 commits, including sync commits for 5000 revisions ... let me see if I can export this in a sane way ..
18:47:43  <Eddi|zuHause> i'm not sure if you can erase all "ghost railtypes"
18:47:54  <snail_UES_> Eddi|zuHause: got it, so if there a foreign railtype label which is powered in ELRL, your vehicle would still understand it
18:48:09  <snail_UES_> you remove the need to know the exact label of that foreign railtype, right?
18:48:15  <Eddi|zuHause> exactly
18:48:18  <andythenorth> I believe for multi-voltage electrics, you need the ghost railtype
18:48:27  <Eddi|zuHause> it will be future-proof on any "sane" new railtype set
18:48:31  <andythenorth> +1
18:48:35  <snail_UES_> right, I see
18:48:45  <andythenorth> Iron Horse doesn't work with NuTracks for example
18:48:47  <andythenorth> currently
18:49:03  <andythenorth> I could make it work by including every railtype in every known railtype grf
18:49:10  <andythenorth> but that's....low on my todo list tbh
18:50:16  <LordAro> TrueBrain: only the non-svn commits are necessary :)
18:50:26  <snail_UES_> andythenorth: NuTracks follows the standardized scheme I guess? it would be rather easy to support it
18:50:49  <TrueBrain> LordAro: because of the merges, that would be rather useless to you :P
18:51:06  <andythenorth> if someone could explain how, I guess I would
18:51:06  <snail_UES_> so far I was able to make my trains kind-of-compatibleish with NuTracks
18:51:19  <andythenorth> but I have formed the impression that newgrf trains aren't supposed to determine powered-ness
18:51:34  <Eddi|zuHause> snail_UES_: no, NuTracks predates the standardized scheme
18:51:35  <andythenorth> that has been delegated to railtypes in some kind of design I don't understand :)
18:51:43  <LordAro> TrueBrain: true :p
18:52:03  <TrueBrain> can't believe you are reviving a 10+ year old patch-set :P
18:52:06  <andythenorth> as far as I can see, currently train authors need to provide code for every railtype grf
18:52:16  <LordAro> TrueBrain: :p
18:52:21  <andythenorth> but they don't get to determine poweredness, except when they do
18:52:48  <andythenorth> but fortunately....eddi will save us :)
18:53:00  <Eddi|zuHause> andythenorth: we might be doomed :p
18:53:14  <snail_UES_> andythenorth: I agree it’s tricky now. When you define a vehicle, you only determine one and only one railtype for it.
18:53:50  <andythenorth> ghost railtypes to the rescue :)
18:54:04  <DorpsGek> [OpenTTD/team] absay commented on issue #115: [es_MX] Translator access request https://git.io/JL9yJ
18:54:08  <snail_UES_> That’s why I strongly suggest players to use my trains and my railtypes together :p not because I’m a rivet counter (well I am, but anyway) but because it’s the only way to make sure your trains work exactly as you want
18:54:47  <DorpsGek> [OpenTTD/team] absay commented on issue #115: [es_MX] Translator access request https://git.io/JL9yJ
18:54:47  <andythenorth> I am going to move Termite into Iron Horse at some point :)
18:54:51  <Eddi|zuHause> snail_UES_: defining vehicles for two basetypes without ghost types might be more tricky, #7000 won't solve that, but maybe we can allow articulated parts to have different railtypes
18:55:29  <DorpsGek> [OpenTTD/team] TrueBrain commented on issue #115: [es_MX] Translator access request https://git.io/JL9yJ
18:55:45  <snail_UES_> how about having a list of compatible, and powered, railtypes for each vehicle?
18:55:51  <snail_UES_> as opposed to only one entry?
18:56:06  <Eddi|zuHause> i don't think that will happen :)
18:56:06  <andythenorth> doesn't that break railtypes somehow?
18:56:28  <andythenorth> someone did explain railtypes design to me once, and why it was correct, and it was convincing
18:56:35  <andythenorth> but I forgot :)
18:56:51  <andythenorth> it's something about being able to redesign existing train grfs or something
18:57:00  <andythenorth> snail_UES_ did you ever try railtype property 11 https://newgrf-specs.tt-wiki.net/wiki/Action0/Railtypes#Curve_Speed_advantage_multiplier_.2811.29
18:57:35  <snail_UES_> andythenorth: to be honest, the current system isn’t bad if I develop trains and railtypes simultaneously
18:57:50  <snail_UES_> the problem is when someone uses trains and railtypes that weren’t designed together
18:57:55  <andythenorth> current railtypes seems fine to me, I just stay out of the confusing parts and ignore all bug reports
18:58:06  <Eddi|zuHause> andythenorth: that setting is kinda silly, as it doesn't have any spectrum on the low speeds
18:58:07  <andythenorth> like...railtypes related bug report? ...'not my problem'
18:58:18  <andythenorth> Eddi|zuHause I couldn't get it to work at all
18:58:21  <snail_UES_> andythenorth: not yet, because narrow gauge trains are too slow anyway :)
18:58:33  <snail_UES_> I’m going to use it with the standard gauge trains
18:58:48  <andythenorth> is it one of these where to get it to 'work' you can only provide a malus
18:58:51  <andythenorth> but no bonus
18:58:52  <andythenorth> ?
18:58:56  <andythenorth> like cargo aging
18:59:00  <Eddi|zuHause> no
18:59:08  <andythenorth> hmm
18:59:24  <Eddi|zuHause> but the speed limits are "high" and "ridiculously high"
18:59:52  <andythenorth> well either my test is invalid, or my grf is wrong, or nml is wrong, or OpenTTD is wrong
19:00:01  <andythenorth> I did check all of them, then I gave up
19:00:01  <TrueBrain> LordAro: I send you an invite to a private repo
19:00:05  <TrueBrain> it is uploading atm
19:00:05  <Eddi|zuHause> probably a combination of all of those :p
19:00:31  <TrueBrain> it is a hg->git repo of the airports.hg, and I included the spec.txt I found in his public folder
19:01:40  <TrueBrain> upload done; let me know when you cloned this, so I can remove the repo again :)
19:03:05  <TrueBrain> git diff 3c1cff2fad4e0664251bd9a29970673678fc7ec3..ed63c5a8b6ef2321eacef6f29315513584f11088 shows the full changes he made, I think :)
19:04:12  <TrueBrain> only 2000 lines, 845 additions, 248 removals
19:04:16  <TrueBrain> that is not a very large diff :)
19:04:30  <LordAro> :)
19:04:42  <TrueBrain> if you want the original hg, that is possible too; this was just easier :)
19:06:11  <LordAro> cloning...
19:06:57  <TrueBrain> I could have replayed it on upstream, but that took effort :P
19:07:25  <TrueBrain> if commit_message starts with "(svn r", lookup git commit on upstream, otherwise, import commit
19:08:54  <snail_UES_> andythenorth: cargo aging was an interesting concept, but it has been implemented in a way (using a hyperbula function) that doesn’t make a big difference in-game
19:10:06  <LordAro> is the repo normally this huge? 500MB of objects and i'm only at 50%
19:10:31  <TrueBrain> OpenTTD is not small, but this is a very rough export from hg to git
19:10:38  <TrueBrain> pretty sure that could have been done more elegant
19:10:56  <snail_UES_> ok, so this would be my wishlist for railtypes…
19:12:01  <snail_UES_> 1. possibility of querying the max axle weight of a railtype: this could return a number in tonnes (ideally decimal, such as “7.5”), would return 255 if no max axle weight is set … a bit like with max speed (which, as I stated, is irrelevant)
19:13:14  <Eddi|zuHause> that's tricky, because axle weight isn't actually a property of railtypes
19:13:43  <snail_UES_> 2. possibility of querying “poweredness”, where ideally each power type could be a bit, whose meaning could be standardized (there aren’t infinite types of power anyway): 1 could be DC, 2 could be AC, 4 could be threephase etc. So a “bi-current” engine could check for eigher bits 0 or 1
19:13:54  <snail_UES_> *either
19:14:17  <snail_UES_> Eddi|zuHause: I know. It should be added as a property first, defaulting to 255
19:14:20  <Eddi|zuHause> but you should be able to find out axle weight with war 0x63 (from #7000) by testing increasing weight railtypes, and checking which ones flip from true to false
19:15:05  <snail_UES_> yes, that’s how I do now, using railtype labels. #7000 would allow me to switch from labels to numbers
19:15:18  <snail_UES_> but still, this wouldn’t simplify my code
19:15:39  <Eddi|zuHause> #7000 would help massively with this, as you don't have to worry about a combination of weight and electrification
19:16:25  <snail_UES_> Eddi|zuHause: I kind of already do that
19:16:41  <Eddi|zuHause> you just check against the unelectrified railtypes to find out weight
19:17:08  <snail_UES_> when I use the function veh_railtype in m4nfo, I already check against all the labels for railtypes of a certain weight, regardless of electrification
19:17:24  <snail_UES_> for example, my code reads:
19:17:26  <snail_UES_> ref(19) if(NAAN,NAAE,NAA3)	// medium: 11t
19:17:33  <snail_UES_> to check for the intermediate-weight railtypes
19:17:57  <snail_UES_> and it checks for unelectrified, catenary-powered, and third-rail powered
19:17:57  <Eddi|zuHause> yes, that's what i mean, you have to state all the possible weight/electrification combinations
19:18:01  <snail_UES_> yes
19:18:12  <Eddi|zuHause> with var 0x63 you have to only state NAAN
19:18:30  <snail_UES_> would I? how so?
19:19:38  <Eddi|zuHause> assuming the railtype grf defines that any vehicle that runs on NAAN can also run on NAAE or NAA3
19:23:28  <andythenorth> https://grf.farm/images/curve_speed_prop_11_255.png
19:23:44  <andythenorth> not sure what I did there ^ but the nml looks about right
19:23:53  <andythenorth> can't remember if I read the nfo
19:24:05  <LordAro> TrueBrain: cloned
19:24:22  <TrueBrain> LordAro: enjoy :)
19:24:30  <snail_UES_> Eddi|zuHause: yes, but even vehicles that run on higher axle-weight limit railtypes (let’s say NABN) can run on NAAN
19:24:37  <Eddi|zuHause> andythenorth: i think 255 might be out of bounds. it should be like "0: normal, 1: faster, 2: fastest, other? invalid" or something like that
19:24:47  <snail_UES_> an 18-ton vehicle can still run on 11-ton rails, but very, very slowly
19:25:38  <Eddi|zuHause> snail_UES_: you define the 18-ton vehicle as NAAN in that case (because it technically can run on that), and define NABN as incompatible to NAAN
19:26:09  <Eddi|zuHause> then the 18-ton vehicle checks var 0x63 with NABN, and if it returns true, it increases speed
19:26:36  <snail_UES_> rather, it decreases speed if it returns false
19:26:49  <Eddi|zuHause> tomato, banana.
19:27:55  <Eddi|zuHause> snail_UES_: the exact same check you can use on a vehicle defined for NAAE
19:28:27  <Eddi|zuHause> the game will prevent it from going on NAAN or NABN, but checking for NABN will also return true if it's currently on NABE
19:28:29  <snail_UES_> so it would simplify the checks in my veh_railtype function
19:32:47  <Eddi|zuHause> yes, simplify them, and make them more compatible with other railtype sets
19:33:47  <snail_UES_> how about crossings and switches?
19:34:24  <snail_UES_> if I build an X type crossing, will there be a way to make the NW-SE track of one railtype, and the NE-SW of another?
19:34:26  <snail_UES_> probably not...?
19:34:39  <Eddi|zuHause> no
19:35:06  <Eddi|zuHause> that needs map array changes
19:35:27  <Eddi|zuHause> which is code for "never" :p
19:35:45  <andythenorth> hmm I have changed curve speed prop value to 12
19:35:48  <andythenorth> no difference
19:35:54  <andythenorth> not sure I can debug railtypes in game?
19:36:08  <Eddi|zuHause> andythenorth: have you tried 0, 1 and 2?
19:36:10  <andythenorth> can't find a bug icon anywhere :)
19:36:40  <andythenorth> trying 0 now
19:37:11  <andythenorth> I guess I have to read the nfo
19:37:12  <snail_UES_> can there be a way to check how long has passed since a train used the rails on a particular tile?
19:37:41  <snail_UES_> it’d be nice if we could I could draw some grass on unused tracks. There used to be a patch for that time ago
19:37:48  <Eddi|zuHause> no, but there was an ancient patch once that added grass
19:40:36  <snail_UES_> I remember that, it must have checked for the last time the tracks were used somehow… couldn’t OTTD exploit the same trick?
19:42:23  <Eddi|zuHause> i don't remember how they did it, but if i were to implement it now, i would increase a counter in the tile loop, and decrease it when a train enters
19:43:32  <Eddi|zuHause> that's sort of how fences are placed next to tracks
19:44:18  <Eddi|zuHause> or how snow is added/removed to tiles if the snowline changes
19:44:31  * andythenorth writing nfo
19:44:36  <andythenorth> oof counting hex on my fingers P
19:45:53  <snail_UES_> Eddi|zuHause: right, so that would theoretically be possible
19:46:16  <Eddi|zuHause> snail_UES_: it needs some space in map array, and probably the old patch died when that space was reused by something else
19:46:52  <Eddi|zuHause> snail_UES_: notoriously a tight spot for map array space is level crossings and stations
19:48:19  <andythenorth> this looks suspicious to me
19:48:26  <andythenorth>   458 * 86	 00 10 0D 01 FF 0F 00 08 "UNIV" 17 89 E9 0A 00 1B 12 DC 09 12 DC 0A 12 DC 0B 12 DC 0C 12 DC 0D 12 DC 0E 05 "UNIVRAILELRLMONOMGLV" 0F 05 "UNIVRAILELRLMONOMGLV" 11 10 12 00 13 40 01
19:48:32  <TrueBrain> MALWARE DETECTED
19:48:33  <andythenorth> lot of 12 values for props
19:48:35  <TrueBrain> TERMINATE TERMINATE
19:48:55  <snail_UES_> got it...
19:49:05  <snail_UES_> how about having catenary pylons on both sides?
19:49:18  <snail_UES_> something like A-shaped portals trains pass under
19:50:25  <Eddi|zuHause> that opens a huge can of worms for custom catenary pole placement, like spanning multiple tracks and stuff :)
19:50:32  <Eddi|zuHause> not sure i would want to go there :)
19:50:49  <Eddi|zuHause> also, probably needs some clever UI
19:51:05  <andythenorth> prop 11 is prop 11 in nfo right?
19:51:17  <andythenorth> because prop 0B is prop 0B
19:51:22  <Eddi|zuHause> yes
19:51:23  <andythenorth> which means prop 11 can't be prop 0B
19:51:34  <andythenorth> ok well the nfo looks correct
19:51:58  <andythenorth> trip to openttd src next I guess
19:52:11  <Eddi|zuHause> whenever you say prop numbers, you're talking in HEX
19:52:18  <snail_UES_> Eddi|zuHause: right. Well, tracks in OTTD are visually very far apart anyway. I’m not sure if I’d like to have poles spanning multiple tracks
19:52:36  <snail_UES_> I’d just like to have two pylons on the sides of one track
19:52:41  <snail_UES_> one on each side
19:52:54  *** jottyfan has joined #openttd
19:53:11  <snail_UES_> and distinguish rail types that have only one pylon on one side, from those that have two pylons
19:53:50  <Eddi|zuHause> i'm pretty sure pylon placement is currently hardcoded, and also complicated. not sure it's worth touching just for this
19:55:02  <andythenorth> it has all kinds of magical cases
19:55:13  <andythenorth> I looked it for the original incarnation of NotRoadTypes
19:55:25  <andythenorth> which was NotCatenaryForSteamTrams
19:55:29  <andythenorth> and would have been less painful
19:55:39  <andythenorth> but NRT!
19:55:40  <andythenorth> hurrah :)
19:57:03  <snail_UES_> having specific bridge types only for certain railtypes would also be nice
19:57:04  <andythenorth> I am hoping that GetCurveSpeedLimit has the answer to my puzzle also
20:02:02  <Eddi|zuHause> andythenorth: i'm fairly certain that you'll find a bunch of presets for speed limits, and prop 11 selects which preset to use, out-of-bound values will revert to default
20:02:16  <andythenorth> what about 0, 1, and 2?
20:02:38  <andythenorth> also that's not how I read L354 https://github.com/OpenTTD/OpenTTD/blob/master/src/train_cmd.cpp#L354
20:02:45  <Eddi|zuHause> i've already told you to try those :p
20:03:15  <andythenorth> I did
20:03:20  <andythenorth> they make no difference
20:03:39  <andythenorth> doesn't L344 just clamp the max speed and make the newgrf property irrelevant?
20:04:04  * andythenorth changes the test case in game
20:06:24  <andythenorth> hmm let's take the tilt speed bonus off the trains
20:06:36  *** Eddi|zuHause2 has joined #openttd
20:10:43  <andythenorth> can't see any difference
20:10:54  <andythenorth> such fun :)
20:11:01  *** Eddi|zuHause2 is now known as Eddi|zuHause3
20:11:04  *** Eddi|zuHause3 is now known as Eddi|zuHause2
20:11:06  *** Eddi|zuHause2 is now known as Eddi|zuHause4
20:12:03  <andythenorth> oh god they're multiplying
20:12:06  <andythenorth> 1 is fine
20:12:08  *** Eddi|zuHause has quit IRC
20:13:23  *** Eddi|zuHause4 is now known as Eddi|zuHause
20:13:38  <andythenorth> rti->curve_speed = buf->ReadByte(); isn't clamped, suggests any value up to FF will be used as a multiplier
20:13:49  <andythenorth> but I don't think that's relevant
20:13:58  <Eddi|zuHause> i can't see any prop 11 in the specs
20:14:18  <andythenorth> https://newgrf-specs.tt-wiki.net/wiki/Action0/Railtypes#Curve_Speed_advantage_multiplier_.2811.29
20:14:45  <Eddi|zuHause> oh, railtypes, not trains
20:15:46  <snail_UES_> why would curve speed multiplier be determined by a railtype?
20:16:05  <andythenorth> because that's the spec :)
20:16:12  <andythenorth> sorry, not a good rationale, but it's fine, no?
20:16:19  <snail_UES_> the curve radius is the same all over… always 45-degree, unless a railtype also allows 90-degree
20:16:24  <andythenorth> max speed is determined by track geometry
20:16:32  <andythenorth> cant
20:16:53  <snail_UES_> it should be determined by the curve radius and, if you will, by the gauge
20:17:18  <Eddi|zuHause> "For the default rail types this property is 0 for normal rail and electrified rail, 1 for monorail, and 2 for maglev."
20:17:22  <andythenorth> or maglev or monorail
20:17:24  <andythenorth> anyway frick
20:17:28  <snail_UES_> tilting trains have an advantage because they can vary their center of gravity
20:17:30  <andythenorth> openttd has loaded the wrong grf in my save
20:17:42  <andythenorth> and RT info is cached
20:17:45  <andythenorth> so now my train is broken
20:17:57  <Eddi|zuHause> tilting is another 20% bonus separate from wthis property
20:18:59  <andythenorth> well whatever I have done is NOT savegame safe
20:19:19  <Eddi|zuHause> so if normal rail curve speed is 100%, tilting is 120%, monorail is 150%, and maglev is 200%
20:20:03  <FLHerne> snail_UES_: 'curve radius' is distance between two turns in the same direction
20:20:08  <snail_UES_> right. I think any new “normal” railtype shouldn’t fiddle with this property, unless one creates a new monorail or maglev type
20:20:44  <Eddi|zuHause> technically, you could have tilting monorail, which would be 180%, and tilting maglev, which would be 240%
20:21:04  <FLHerne> (re. "the curve radius is the same all over… always 45-degree [...]"; perhaps I misunderstand the point)
20:21:07  <snail_UES_> FLHerne: yes, and that doesn’t vary with the railtype. It only depends on the geometry of the laid out tracks
20:21:38  <FLHerne> snail_UES_: Well, "gauge" is the railtype, no?
20:21:41  <Eddi|zuHause> track geometry, train length, and wagon length
20:21:59  *** y2kboy23 has quit IRC
20:22:00  <FLHerne> Your railtype might be rollercoaster track so that corners don't matter
20:22:33  <Eddi|zuHause> curve speed is weird.
20:22:37  <snail_UES_> FLHerne: yes, narrow gauge allow for narrower curves in real life… so for my NG tracks, I allow 90-degree curve
20:22:46  <andythenorth> Eddi|zuHause in concept, or implementation?
20:22:47  <Eddi|zuHause> we should rip it out and reimplement it
20:22:55  <Eddi|zuHause> implementation
20:22:56  *** y2kboy23 has joined #openttd
20:23:02  <andythenorth> I have patched it to 	return absolute_max_speed;
20:23:11  <andythenorth> I was curious what is going on with it
20:25:23  <FLHerne> snail_UES_: Tighter curves, but also less stability when taking curves at speed
20:26:18  * andythenorth is a 90-degree curve holdout
20:26:27  <andythenorth> even if they wreck the pathfinder
20:27:40  <FLHerne> In favour of, or against?
20:27:47  <FLHerne> They're hideos
20:27:48  <FLHerne> u
20:27:49  <andythenorth> in favour of
20:27:52  <FLHerne> WHY
20:28:01  <andythenorth> escape depots
20:28:16  <andythenorth> too limiting too place them on 45 degree only
20:28:26  <andythenorth> don't use them otherwise
20:28:30  <andythenorth> *I don't
20:28:54  <FLHerne> Escape depots are hideous and also cheating :p
20:29:41  <andythenorth> Steeltown kind of imposes them
20:29:53  <andythenorth> or you'll be station walking
20:30:15  <andythenorth> or just...ships! :)
20:30:40  <snail_UES_> FLHerne: true, but NG trains are always slower :)
20:32:07  <andythenorth> hmm
20:32:12  <andythenorth> when is curve speed cached?
20:32:30  <andythenorth> and what railtype is returned in a depot?
20:33:07  <supermop_Home> hmm really don't feel like sweetening a bunch of brick noise texture. want to just mask off all the faces and fill them in
20:34:30  * andythenorth should learn how to printf or something in C++
20:34:45  <andythenorth> do we use printf?
20:34:47  <andythenorth> or something else?
20:35:34  <Eddi|zuHause> depends
20:35:45  <andythenorth> I guessed (wrong) at 	printf(rti->curve_speed);
20:35:47  <andythenorth> nope
20:36:44  <andythenorth> I have deleted enough GetCurveSpeedLimit to think it's not just a caching issue
20:36:58  <Eddi|zuHause> first parameter must be a "format", like "%d"
20:37:00  <andythenorth> but I curious what value rti->curve_speed is returning
20:39:41  <andythenorth> %d gets me a crash D
20:39:48  <supermop_Home> hmm despite years or compositing drawings in photoshop and working with them .. i never really bothered to learn how smart objects work
20:40:16  <supermop_Home> here i was being like ' i wish PS had blocks like autocad'
20:42:19  <supermop_Home> oh. it actually doesn't work like that
20:43:00  * andythenorth closes 'my first adventure in C++'
20:43:18  <andythenorth> weird curve speed multiplier is weird
20:43:35  * andythenorth just wanted full speed banked curves on a high speed line
20:51:19  <andythenorth> Eddi|zuHause what's weird about it? :)
20:53:58  <Eddi|zuHause> andythenorth: thing about printf formats is, you need to know exactly what size the variable you're printing is
20:54:42  <andythenorth> makes sense
21:10:10  * andythenorth wonders if this->railtype is returning correct value
21:10:44  <andythenorth> nah must be
21:25:53  <andythenorth> ok so prop 11 is 10 which is 16
21:26:05  <supermop_Home> andythenorth what color do you want the hotel to be
21:26:16  <andythenorth> brick ish?
21:26:37  <supermop_Home> i was gonna do a bunch of variants or make it recolorable but i don't have the energy
21:27:27  * andythenorth trying to debug the hard way :D https://gist.github.com/andythenorth/2ce5927b281eb7c2deb162fedd44afa1
21:28:16  <supermop_Home> like this color? https://github.com/OpenTTD/OpenGFX/blob/master/sprites/png/houses/base-1536-1537-oldflats.png
21:28:38  <andythenorth> oh
21:29:15  <andythenorth> does this->railtype return train prop 05? :D
21:29:20  <andythenorth> please tell me it does
21:29:34  <andythenorth> HasPowerOnRail(this->railtype, GetRailType(this->tile)) checks current tile
21:30:55  *** WormnestAndroid has quit IRC
21:30:59  <andythenorth> curve speed checks GetRailTypeInfo(this->railtype)
21:31:22  *** WormnestAndroid has joined #openttd
21:39:52  <andythenorth> 		const RailtypeInfo *rti = GetRailTypeInfo(GetRailType(this->tile));
21:39:53  <andythenorth> works
21:39:55  <andythenorth> that a bug then?
21:40:02  <andythenorth> or something I misunderstan?
21:40:33  <andythenorth> line 353 https://github.com/OpenTTD/OpenTTD/blob/master/src/train_cmd.cpp#L353
21:44:27  <andythenorth> supermop_Home yes :)
21:46:01  <michi_cc> andythenorth: Are you still going on the curve speed?
21:46:23  <Samu> i made possible what he requests https://github.com/OpenTTD/OpenTTD/issues/8316#issuecomment-698878121
21:46:38  <Samu> but my code is horribad
21:48:26  <michi_cc> andythenorth: If you want to see any effect of curve speed at all, you need two 45-degree curves in the same direction and a train that is at least long enough to span both curves at once.
21:49:28  <andythenorth> michi_cc valid test case yes/no? https://grf.farm/images/curve_speed_prop_11_255.png
21:50:15  <andythenorth> I can see the effects fine if I patch OpenTTD :)
21:50:56  <andythenorth> I don't see how fetching the engine's railtype from prop 05 is going to have any effect when the railtype changes
21:50:59  <Samu> watch out! https://github.com/OpenTTD/OpenTTD/compare/master...SamuXarick:industry-sort-by-production-with-cargo-filter
21:51:01  <andythenorth> but I am guessing my way here
21:55:04  <michi_cc> I think the real problem/inconsistency is line 347 here. I get a max_speed of 168 there, which is inconsitent with the speed table in the wiki.
21:56:05  <michi_cc> But line 353 might also not do as intended.
21:56:42  <andythenorth> depends what we think the spec is :)
21:57:03  <andythenorth> newgrf spec says "This property sets the multiplier to the curve speed advantage which all trains running on this track type get. "
21:57:17  <andythenorth> I read that as 'engine curve speed will be fetched from current tile"
21:57:38  <andythenorth> but there may be other interpretations
21:59:55  *** WormnestAndroid has quit IRC
22:00:08  *** WormnestAndroid has joined #openttd
22:00:57  <michi_cc> Line 353 is a bug I think. Except some syntax changes, the railtype curve prop is from the initial elrail stuff, pre railtypes. Probably simply forgotten with railtypes.
22:01:11  <andythenorth> acceleration model might be same
22:01:28  <michi_cc> Well, you need to run realistic acceleration of course.
22:01:55  <michi_cc> I'd say the initial curve speed calculation doesn't make sense though, it is much too high.
22:03:19  <michi_cc> Okay, I take that back. Is is actually exactly as documented. I missed the * 2 in the newgrf wiki page. A curve with 5 tracks inbetween has a base curve speed of 168, making it completely irrelevant.
22:05:05  <andythenorth> acceleration model I mean railtype prop 15 :) https://newgrf-specs.tt-wiki.net/wiki/Action0/Railtypes#Acceleration_model_.2815.29
22:05:23  <andythenorth> spec doesn't say if it's to be for all trains on the railtype, or for the engine's railtype
22:05:49  <andythenorth> but L294 in train.h is engine only I think
22:06:25  <andythenorth> my local patch of appears to work for L353
22:06:27  <andythenorth> const RailtypeInfo *rti = GetRailTypeInfo(GetRailType(this->tile));
22:06:35  <andythenorth> but I really have no idea what I'm doing, total cargo-cult
22:06:49  <Samu> cyas goodnight
22:06:51  *** Samu has quit IRC
22:07:03  <supermop_Home> andythenorth how does brick recoloring work?
22:09:42  <michi_cc> Prop 15 might only be relevant if OTTD is set to original acceleration.
22:10:30  <andythenorth> supermop_Home no idea :)  Do you meanin ogfx?
22:10:36  <andythenorth> mean in *
22:13:21  <michi_cc> andythenorth: I would say that change for 353 should have always been this way. I think it was simply forgotten when doing NewGRF railtypes.
22:13:49  <andythenorth> +1
22:13:57  <andythenorth> I have a test grf
22:14:00  <andythenorth> works for me
22:14:28  <michi_cc> Make a PR :)
22:14:31  <andythenorth> I will try and break it tomorrow, then PR
22:17:11  * andythenorth wonders if a 'region' is just a list of towns
22:17:36  <andythenorth> too simple? :P
22:23:08  *** andythenorth has quit IRC
22:23:56  *** iSoSyS has joined #openttd
22:28:58  <DorpsGek> [OpenTTD/OpenTTD] JGRennison opened pull request #8464: Fix: Assert fail when using restart command after opening save/load GUI https://git.io/JLHJ8
22:52:36  <TrueBrain> Nice description in that PR :) and what an obscure bug :p that must have been a fun bug hunting session :D
22:54:55  *** iSoSyS has quit IRC
23:07:32  *** Wolf01 has quit IRC
23:13:37  *** sla_ro|master has quit IRC
23:17:12  <DorpsGek> [OpenTTD/OpenTTD] JGRennison opened issue #8465: Documentation: COMPILING.md does not describe how to make a non-debug build on non-Windows https://git.io/JLHTh
23:53:15  *** nielsm has quit IRC
23:56:53  <DorpsGek> [OpenTTD/OpenTTD] michicc approved pull request #8464: Fix: Assert fail when using restart command after opening save/load GUI https://git.io/JLHLZ
23:57:14  <DorpsGek> [OpenTTD/OpenTTD] michicc merged pull request #8464: Fix: Assert fail when using restart command after opening save/load GUI https://git.io/JLHJ8

Powered by YARRSTE version: svn-trunk