IRC logs for #openttd on OFTC at 2020-12-29
⏴ go to previous day
00:57:48 *** glx has quit IRC (Ping timeout: 480 seconds)
01:04:02 *** WormnestAndroid has quit IRC (Remote host closed the connection)
01:04:16 *** WormnestAndroid has joined #openttd
01:12:50 *** WormnestAndroid has quit IRC (Remote host closed the connection)
01:13:04 *** WormnestAndroid has joined #openttd
01:14:48 *** WormnestAndroid has quit IRC (Remote host closed the connection)
01:16:52 *** WormnestAndroid has joined #openttd
01:18:21 *** Progman has quit IRC (Remote host closed the connection)
01:29:14 *** gelignite has quit IRC (Quit: Stay safe! Stay at home! Stop the chain reaction!)
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 (Quit: Leaving)
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
02:07:31 *** Wormnest has quit IRC (Quit: Leaving)
03:29:53 *** D-HUND has quit IRC (Ping timeout: 480 seconds)
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 (Ping timeout: 480 seconds)
06:57:29 *** sla_ro|master has joined #openttd
07:33:48 *** andythenorth has joined #openttd
08:19:43 *** Compu has quit IRC (Remote host closed the connection)
08:44:41 *** Compu has quit IRC (Remote host closed the connection)
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: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:49:26 <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 (Remote host closed the connection)
10:48:36 *** WormnestAndroid has joined #openttd
10:50:29 *** Progman has joined #openttd
11:13:11 *** DasPoseidon has quit IRC (Remote host closed the connection)
11:15:05 *** DasPoseidon has joined #openttd
11:31:49 *** J0anJosep has joined #openttd
11:34:19 *** gelignite has joined #openttd
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: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: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:37:35 <andythenorth> ok I just write them, without pitching 'why' too much, can add that later
12:38:27 *** duckfullstop has quit IRC (Ping timeout: 480 seconds)
12:42:48 *** Progman has quit IRC (Remote host closed the connection)
12:47:32 *** Eddi|zuHause has left #openttd (Konversation terminated!)
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: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: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: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: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: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: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: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: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: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: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: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: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: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 (Quit: DasPoseidon)
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: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: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: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: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:44:39 <Eddi|zuHause> as that's the one that conflicts with #7000
14:49:02 <TrueBrain> 5485416597 it says here
14:49:06 <TrueBrain> you are us that is correct?
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: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: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: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:42 *** andythenorth has quit IRC (Ping timeout: 480 seconds)
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 (Quit: A toaster's basically a soldering iron designed to toast bread)
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:53 <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:32 <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: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: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:22:05 <andythenorth_> so....can I generate a GS from a python compile :P
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:46 <LordAro> something like that probably shouldn't die
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: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: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: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:37:52 <andythenorth_> I found SetCargoGoal(), is that the built in?
16:38:15 <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:43:21 * 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
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: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: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:32 <andythenorth_> but transporting more is usually a malus currently, as town is already choked
17:35:13 <Timberwolf> Maybe if the vehicle distributor was input-limited based on the population of its nearest town?
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: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: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: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:42:00 *** rptr_ has quit IRC (Quit: Leaving)
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 (Ping timeout: 480 seconds)
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: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: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: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: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: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: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:54:33 <andythenorth_> "uh the planet just exploded sir"
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: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:24 <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:36 <andythenorth_> and then I spend 26 years trying to recover
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:15 <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: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: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: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: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: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: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: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: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:17:16 <andythenorth_> I realised after I wrote them, my requirements are self-satire :(
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:48 <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: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: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: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:30:15 <TooTallTyler> Thus negating the grf / base game issue over who gets to close industries
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:42 <snail_UES_> an index like a number? or a label?
18:34:00 <Eddi|zuHause> a number, position in your railtype translation table
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: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: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: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: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 (Quit: Page closed)
18:44:07 <andythenorth> so stack the checks
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: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:45 <andythenorth> Iron Horse doesn't work with NuTracks for example
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:51:06 <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: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: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: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 <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: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:51 <andythenorth> it's something about being able to redesign existing train grfs or something
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:56 <andythenorth> like cargo aging
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:42 <TrueBrain> if you want the original hg, that is possible too; this was just easier :)
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: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:25 <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:12 <Eddi|zuHause> with var 0x63 you have to only state NAAN
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: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: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: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: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: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: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: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:33 <andythenorth> lot of 12 values for props
19:48:35 <TrueBrain> TERMINATE TERMINATE
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:31 <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: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: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: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:45 <Eddi|zuHause> i've already told you to try those :p
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: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:08 *** Eddi|zuHause has quit IRC (Ping timeout: 480 seconds)
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: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: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: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:58 <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 (Read error: Connection reset by peer)
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:45 <andythenorth> Eddi|zuHause in concept, or implementation?
20:22:47 <Eddi|zuHause> we should rip it out and reimplement it
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:28:16 <andythenorth> too limiting too place them on 45 degree only
20:28:26 <andythenorth> don't use them otherwise
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: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:29 * 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:45 <andythenorth> I guessed (wrong) at printf(rti->curve_speed);
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
21:10:10 * andythenorth wonders if this->railtype is returning correct value
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:37 <supermop_Home> i was gonna do a bunch of variants or make it recolorable but i don't have the energy
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 (Ping timeout: 480 seconds)
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:55 <andythenorth> that a bug then?
21:40:02 <andythenorth> or something I misunderstan?
21:44:27 <andythenorth> supermop_Home yes :)
21:46:01 <michi_cc> andythenorth: Are you still going on the curve speed?
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: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: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 (Ping timeout: 480 seconds)
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: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:51 *** Samu has quit IRC (Quit: Leaving)
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: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:57 <andythenorth> I have a test grf
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:23:08 *** andythenorth has quit IRC (Quit: andythenorth)
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
23:07:32 *** Wolf01 has quit IRC (Quit: Once again the world is quick to bury me.)
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 (Ping timeout: 480 seconds)
23:56:52 <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
continue to next day ⏵
![https://i.imgur.com/8iKiGr1.png[/img]](https://i.imgur.com/8iKiGr1.png%5B/img%5D){kind=link}
