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