IRC logs for #openttd on OFTC at 2019-12-05
⏴ go to previous day
00:11:12 <milek7_> argh, as if opengl didn't have enough quirks
00:11:17 <milek7_> opengl es add some more..
00:12:47 <FLHerne> Yeah, GLES is like GL, but you get to shout "wait, I can't use THAT EITHER?!" at your monitor every half-hour
00:13:05 <FLHerne> And the drivers are all buggier
00:14:15 <milek7_> it is not even a subset of desktop gl
00:14:18 <milek7_> for some features it is not possible to write one codepath compatible with both..
00:16:18 <FLHerne> milek7_: I think most desktop drivers implement GL_ARB_ES3_1_COMPATIBILITY
00:16:56 <FLHerne> Well, it's a required feature in GL4.5, so everything supporting that has it by default
00:16:56 <LordAro> i think GL3 is a reasonable minimum at this point
00:17:18 *** supermop_work has joined #openttd
00:18:03 <FLHerne> Oh, GL4.1 mandates ES2 compat, and GL4.2 has ES3.0 compat
00:18:13 <milek7_> yes, but it requires 4.5..
00:18:22 <FLHerne> Of course, ES2 is horrible
00:19:06 <milek7_> i would like to use 4.5, but there is still many users of older versions
00:19:39 <milek7_> e.g. DSA is only in 4.5
00:20:01 <FLHerne> milek7_: It's only /required/ in 4.5, but many of the drivers for older hardware implement it as an extension
00:20:07 <milek7_> (there's earlier DSA as extension.. but it is different)
00:20:25 <FLHerne> e.g. this laptop I'm typing on only supports GL3.3, but exposes GL_ARB_ES3_2_compatibility
00:22:16 <FLHerne> I don't know what four years have done to that number
00:29:19 *** WormnestAndroid has quit IRC
00:31:06 *** WormnestAndroid has joined #openttd
01:04:02 *** Thedarkb-X40 has joined #openttd
02:16:00 <DorpsGek_III_> [OpenTTD/website] James103 opened issue #112: Suggestion: Make author and date added always publicly visible on bananas.openttd.org https://git.io/JeDiD
02:20:52 <DorpsGek_III_> [OpenTTD/website] James103 commented on issue #89: Obsolete form for adding Newgrf to bananas.openttd.org https://git.io/fjCeD
02:27:42 *** Smedles has joined #openttd
04:06:11 *** snail_UES_ has joined #openttd
04:37:35 *** supermop_work has joined #openttd
04:44:35 *** y2kboy23 has joined #openttd
05:12:46 *** supermop_work has joined #openttd
05:17:58 *** supermop_work has joined #openttd
05:40:06 *** Wormnest_ has joined #openttd
05:50:04 *** WormnestAndroid has quit IRC
05:51:33 *** WormnestAndroid has joined #openttd
06:07:44 *** WormnestAndroid has quit IRC
06:08:40 *** WormnestAndroid has joined #openttd
06:20:25 *** Smedles has joined #openttd
07:41:01 *** Flipp3rrr has joined #openttd
08:49:20 <DorpsGek_III_> [OpenTTD/website] LordAro commented on issue #112: Suggestion: Make author and date added always publicly visible on bananas.openttd.org https://git.io/JeDiD
08:49:54 <DorpsGek_III_> [OpenTTD/website] LordAro commented on issue #89: Obsolete form for adding Newgrf to bananas.openttd.org https://git.io/fjCeD
12:04:15 *** andythenorth has joined #openttd
12:20:07 *** andythenorth has joined #openttd
12:31:03 *** andythenorth has joined #openttd
12:37:12 *** supermop_work has joined #openttd
12:50:29 <nielsm> hmm, big challenge with this NoCalendar idea might be linkgraph/timetables
12:53:54 <andythenorth> frigging timetables :)
13:38:06 *** tokai|noir has joined #openttd
13:38:06 *** ChanServ sets mode: +v tokai|noir
13:48:34 <nielsm> and lots of complexities with service interval (and presentation of that) too
13:53:32 * andythenorth tries to picture it all
13:54:09 <andythenorth> can this ever work, without the pre-requisite of decoupling all cyclical actions from the calendar datetime?
13:59:38 <andythenorth> what else works on days, besides servicing, timetables
14:00:05 <andythenorth> anything in newgrf that works by comparing datetimes
14:30:29 *** snail_UES_ has joined #openttd
14:45:40 <Eddi|zuHause> that's exactly the kind of problem that made any previous daylength patch fail
15:24:06 *** supermop_work has joined #openttd
15:31:59 <Sacro> Don't mock my daylength patch :(
15:33:28 <andythenorth> when I see the word 'sacro' now I just associate it with back pain :P
15:33:59 <andythenorth> Eddi|zuHause: so we're back at 'daylength can never work'?
15:47:00 <Eddi|zuHause> andythenorth: no, but it needs a kind of sophisticated and thorough approach that is really unlikely to emerge in a hobby project
15:47:49 <Eddi|zuHause> (not that it would be any more likely in a professional project, with deadlines and such)
15:50:19 <andythenorth> what a funny position to be boxed into
15:50:36 <andythenorth> * players use daylength to address issues they percieve as real and important
15:50:48 <andythenorth> * daylength "just works" in JGR
15:50:56 <andythenorth> * daylength can never work in the real world
15:51:16 <andythenorth> fallacies are strange and interesting
16:00:02 <DorpsGek> planetmaker: OpenTTD uses TCP and UDP port 3979 for server <-> client communication, UDP port 3978 for masterserver (advertise) communication (outbound), and TCP port 3978 for content service, a.k.a. BaNaNaS (outbound)
16:00:02 *** WormnestAndroid has quit IRC
16:03:36 <supermop_work> andythenorth: who says it 'just works'?
16:03:55 <andythenorth> same as before, vocal posters on forums or reddit
16:04:05 <andythenorth> likely a handful of posters
16:04:42 <planetmaker> the difference between "works for my use case" and "works for everyone and in every corner case"
16:05:17 <planetmaker> Also... can be done without accomodating everyone's needs... after all it's *adding* something, defaults remain
16:05:20 <andythenorth> I used to play with multiple newgrf sets enabled :P
16:05:29 <andythenorth> until it doesn't
16:05:42 <planetmaker> in which case it's the newgrfs faults. not openttds :) :P
16:05:51 <andythenorth> I think it was my fault tbh
16:06:04 <planetmaker> also: it's not exactly a requirement that existing newgrfs behave nicely with all daylength settings.
16:06:24 <planetmaker> It's absolutely ok to expose some variables for newgrfs to take into account daylength
16:06:53 <planetmaker> it's just a question of default settings. And adopting NewGRFs / OpenTTD settings, if they don't suit you. Like always
16:07:06 <planetmaker> there's no no-config solution which is good for everyone. There cannot be
16:08:03 <andythenorth> I might just solve this myself
16:21:04 *** WormnestAndroid has joined #openttd
16:33:53 *** Wormnest_ has joined #openttd
16:43:43 <Eddi|zuHause> <andythenorth> * daylength "just works" in JGR
16:43:44 <Eddi|zuHause> <andythenorth> * daylength can never work in the real world
16:43:46 <Eddi|zuHause> there's a difference between "works for me", "works for a general audience" and "is sustainable/maintainable"
16:44:38 <Eddi|zuHause> that difference is usually something like "takes 3 hours to implement" and "takes 3 months to implement"
16:52:57 <FLHerne> andythenorth: The people for whom it doesn't "just work" stop using and suggesting it :P
16:55:05 <andythenorth> so we see a form of confirmation bias
16:55:59 <andythenorth> I can't leave problems like this alone, it's like picking a scab :P
16:56:23 <andythenorth> anyway, how shall I implement the parameter solution in newgrfs?
16:56:31 <andythenorth> 'length of each generation'?
16:56:34 <andythenorth> 'scaling factor'?
16:57:03 <FLHerne> andythenorth: "Length of generation" is pointless and won't make anyone happy
16:57:21 <andythenorth> pikka has solved this, where's the link :P
16:57:31 *** supermop_work has joined #openttd
16:57:39 <FLHerne> The people who care about 'realism' want specific in-game dates, regardless of whether that makes any practical difference ;-)
16:57:54 <FLHerne> Production scaling factor is probably the useful one
16:58:45 <FLHerne> Either in vanilla as an alternative to that misuse of 'daylength', or to correct for it when people use daylength for intro dates and don't want an effective reduction in cargo
17:01:40 <FLHerne> I remember seeing that, it's still wrong :P
17:04:24 *** WormnestAndroid has quit IRC
17:04:42 <milek7_> i have git branch with my changes on top of earlier PR. PR was merged but squashed, and now i want to rebase only my commits onto tip of master
17:04:51 <milek7_> is it possible to rebase it automatically, or i have to cherry-pick manually?
17:04:54 *** pina[m] has joined #openttd
17:08:32 <andythenorth> we just need an "it's always 1965" button
17:18:57 <milek7_> ok, `git rebase --onto master last_commit_on_squashed_pr my_branch` did it
17:24:40 <nielsm> andythenorth: yeah that's basically what I'm trying to do, but maybe I'm doing it the wrong way around
17:25:23 * andythenorth wonders how many places the month-year is shown :P
17:25:26 <andythenorth> and if we can hide them all
17:25:40 <andythenorth> I could invent 12 fake month names
17:25:54 <andythenorth> and we could just cycle them, whilst not incremementing the year
17:31:14 <planetmaker> January, Jabuary, February, Mebruary, March, Aprirch, April, Maypril, May, ...
17:41:37 <planetmaker> Currently it's quite typical Nocember weather
17:42:29 <planetmaker> quite a bit colder than in Octember
17:44:04 <andythenorth> fake months, and it's always 1965
17:44:21 <Eddi|zuHause> andythenorth: use the month names from the french revolution?
17:45:12 <andythenorth> we should have done levels
17:46:23 <planetmaker> hm... Hartung, Hornung, Lenzing, Ostermond, Maien, Brachet, Heuet, Ernting, Herbstmond, Gilbhard, Nebelung und Julmond?
17:46:44 <Sacro> Nebelung sounds painful
17:46:55 *** sla_ro|master has joined #openttd
17:47:01 <andythenorth> level 7: you get the Chaney Jubilee
17:47:01 <planetmaker> translates to foggy-month
17:47:14 <planetmaker> or misty-month. whatever
17:52:27 <supermop_work> 13 month calendar?
17:52:37 <andythenorth> 28 month calendar
17:52:47 <andythenorth> maybe that's the serious solution :P
17:53:37 <supermop_work> i always find it hard to believe that people at kodak were actually using this
17:55:32 <andythenorth> how many months per year: '256'
17:56:00 <andythenorth> solves everything no?
17:56:15 <andythenorth> all 'per month' 'every x days' keep working
17:56:28 <andythenorth> vehicle intro *year* is unaffected
17:56:31 <planetmaker> hm... 2*12=28? :P
17:56:47 <andythenorth> arbitrary numbers :P
17:56:53 <andythenorth> newgrf keeps working
17:56:59 <andythenorth> except for seasonal snowline :(
17:57:04 <planetmaker> except yearly expenses etc :P
17:57:15 <andythenorth> my idea is dead, it will break seasonal snowline
17:57:19 <planetmaker> except introduction dates
17:57:35 <andythenorth> intro dates would be fine
17:58:42 <planetmaker> well, solution really is *day* length :)
17:58:57 <Eddi|zuHause> andythenorth: i've no clue what problem you're trying to solve, but it's almost certainly not one anyone who uses daylength would be looking for
17:58:58 <planetmaker> which can be ticks/day
17:59:31 <andythenorth> yes, but we've established that daylength is impossible Eddi|zuHause
17:59:35 <andythenorth> so what might satisfice?
17:59:53 <andythenorth> we've also established that daylength in JGR satisfices, even though it's known not to work
18:00:01 <planetmaker> and includes to adopt monthly, yearly, and "tick"ly callbacks by whatever scaling deemed appropriate for whatever function
18:00:37 <planetmaker> making the scaling configurable basically solves it... everyone can set the things to bug where they want :P
18:00:43 <andythenorth> the perceived problem is solved - comprehensively - by a non-working solution
18:00:57 <andythenorth> so what can we do equivalently, given that nobody is prepared to just merge the non-working solution
18:01:14 <andythenorth> JGR has won because of daylength, the forums and reddit are quite clear
18:01:38 <andythenorth> they don't complain about daylength not working, they are adamant it works
18:02:00 <Eddi|zuHause> andythenorth: any gameplay that is currently tied to a recurring cycle, must be reviewed and explicitly tied to a "tick" or a "day" cycle
18:02:38 *** WormnestAndroid has joined #openttd
18:02:43 <supermop_work> Eddi|zuHause: andy is just being willfully difficult again?
18:02:46 <Eddi|zuHause> andythenorth: only after that is done, you can reliably add a setting for daylength
18:02:47 <planetmaker> andythenorth, the people who play JGR - often for daylength reasons - are satisfied with it. Doesn't mean others who want a daylength want that daylength. Sample bias at its best
18:03:17 <andythenorth> they're not reporting that though?
18:03:27 <Eddi|zuHause> andythenorth: they're never reporting that.
18:03:44 <andythenorth> squeaky wheel gets the oil
18:03:44 <Eddi|zuHause> andythenorth: look at any mention of "well tested" in the logs/forum
18:04:00 <andythenorth> supermop_work nah I just want it solved
18:04:26 <planetmaker> why should I report anything about something I haven't really tried? Or what I know is designed to work for some way but not generally? It's measured by different standards
18:04:34 <andythenorth> and nothing gets solved by attempting to use a solution that has already been defined as unworkable
18:04:39 <andythenorth> it needs an oblique approach
18:05:25 <Eddi|zuHause> andythenorth: dunno, the "do nothing" approach seems to be working fine for the last 14-ish years
18:05:35 <jgr_> My patchpack is not about daylength, it really isn't that big an issue in the big scheme of things
18:05:38 <planetmaker> it is an excellent test field. But it is not expected to solve every problem
18:06:27 <planetmaker> I'm not claiming it is, jgr_ :) But it *is* a playground for people who love daylength - at least in the form implemented
18:06:48 <planetmaker> doesn't say all use it :)
18:07:58 <planetmaker> and ofc those who don't use it... don't report any opinion on it either
18:08:59 * andythenorth wonders about a timeless mode
18:09:09 <planetmaker> same thing, same problems
18:09:18 <nielsm> you still need to keep _some_ form of time
18:09:20 <andythenorth> FIRS mostly ignores any dates, because industry transitions just do not work
18:09:30 <andythenorth> years / dates /s
18:09:36 <planetmaker> they work for default oil
18:09:44 <andythenorth> FIRS has some stupid legacy stuff like date-sensitive graphics
18:09:48 <FLHerne> supermop_work: Yeah, definitely
18:10:06 <FLHerne> planetmaker: Everyone hates them for default oil ;-)
18:10:09 <planetmaker> I don't consider date-sensitive graphics "stupid legacy"
18:10:25 <nielsm> at the timescale (speed) TT plays at, more than one or two industry transitions don't really make sense
18:10:48 <planetmaker> FLHerne, agreed, it's not the feature I'm looking for in default industries... it's annoying :P
18:10:49 <FLHerne> That's something where daylength might actually allow for different mechanics
18:10:50 <nielsm> and the oil wells => oil platforms transition made somewhat more sense in TTO when its 1930 start than the TTD 1950 start
18:11:13 * andythenorth wonders about deleting 5 of the 6 generations in Iron Horse
18:11:30 <andythenorth> it would be much smaller grf, saves bandwidth + compile time
18:11:32 <FLHerne> andythenorth: Personally, the most tempting things in JGRPP have nothing to do with daylength
18:11:58 <nielsm> andythenorth: define a railtype for each generation then you can just build a depot for just the generation you want to play with
18:12:03 <planetmaker> nielsm, yes. And it highly depends on how one wants to play. Actually the transition is probably more fun, when you have slower time. It comes too quickly
18:12:37 <FLHerne> andythenorth: Signal routing restrictions, bridges over stations and template-based train replacement are all much nicer to me
18:12:37 <planetmaker> hehe... the day when OpenTTD is bandwidth limited will still need to come.
18:13:16 <FLHerne> andythenorth: I *still* think you're getting hung up on daylength out of all proportion to its actual impact ;-)
18:13:38 <FLHerne> Not that it's not worth discussing
18:14:01 <jgr_> Trying to simultaneously solve all time scaling issues for all users is a non-starter
18:14:16 <FLHerne> But this "JGR has won because..." and "everyone has switched to because..." is counterfactual hyperbole
18:14:43 <andythenorth> I'm talking about a handful of very vocal users
18:14:49 <andythenorth> for which daylength is the primary benefit
18:15:02 <jgr_> The existing economy, time and scaling is entirely arbitary and it is OK for modifications to also be arbitrary
18:16:54 <Eddi|zuHause> wtf does Lutris exist for? i've never clicked on a lutris install script, and had the resulting game actually run properly
18:17:53 <Eddi|zuHause> andythenorth: the problem with including daylength into the main game is the part of the audience which is NOT this vocal core group
18:18:42 <andythenorth> I don't know about serving the apparent needs of people who aren't asking for anything
18:18:48 <FLHerne> Eddi|zuHause: Well, if it's optional...
18:18:48 <andythenorth> not sure how we'd discover those
18:18:50 <Eddi|zuHause> andythenorth: so, step 1 of including a daylength patch is "make sure, nothing changes for people who don't want daylength", and step 2 is "make sure it works for people who have no clue they want daylength, but randomly enable it anyway"
18:18:55 <andythenorth> we can anticipate needs ourselves of course
18:19:04 <andythenorth> that's a valid design approach
18:19:41 <Eddi|zuHause> andythenorth: the needs of the vocal minority is satisfied with JGR-PP existing
18:20:11 <FLHerne> Just checking before I try doing it: in NML, is there any particular reason why the various operators aren't just subclasses of BinOp?
18:20:35 <Eddi|zuHause> FLHerne: no clue, i wasn't involved with the design of that
18:21:18 <andythenorth> Eddi|zuHause: they're not, they need the industry grfs patched
18:21:33 <FLHerne> There's all sorts of behaviour `if isinstance(op, nmlop.ADD): ... elif isinstance(op, nmlop.SUB): ...` that would be much nicer if they just implemented it themselves
18:22:15 <Eddi|zuHause> andythenorth: so you're saying the existing implementation doesn't actually implement the requirements? then what would be solved by merging the existing implementation?
18:22:27 <andythenorth> nobody is going to merge that
18:22:39 <andythenorth> the oblique solution is needed
18:22:39 <FLHerne> andythenorth: If they want industry grfs patched to counteract the current effect, then that's because they don't want that kind of meh Eddi just said it
18:22:42 <Eddi|zuHause> then what's the fuzz about?
18:23:10 <andythenorth> finding a solution o/c
18:23:35 <jgr_> I don't see why industry GRFs should need to be patched
18:23:50 <andythenorth> production is too low
18:23:50 <jgr_> Making that a requirement would make the feature dead before it ever got off the ground
18:25:50 <andythenorth> anyway, I think I'll end up doing what I was going to do all along :P
18:26:00 <andythenorth> which is add configurable intro dates to all my vehicle grfs
18:26:25 <andythenorth> nobody has been able to identify a better alternative
18:27:06 <jgr_> For me at least, vehicle into dates are a non-issue as I usually start the game when all that finished anyhow
18:27:51 *** lastmikoi_ has joined #openttd
18:28:03 *** lastmikoi_ is now known as lastmikoi
18:29:26 <FLHerne> andythenorth: configurable production + existing daylength is much closer to players' demands than configurable intro dates + vanilla
18:30:11 <FLHerne> The "daylength for low production!" people are mostly happy with existing daylength
18:30:32 <planetmaker> well. configurable production + configurable daylength (which exists, right?)
18:30:38 <andythenorth> the intro dates aren't to solve daylength
18:30:46 <FLHerne> The "daylength for realism!" people, when not intersecting the above, wouldn't be satisfied with different intro dates because they aren't realistic :P
18:30:46 <jgr_> Configurable production doesn't exist, as far as I am aware
18:30:48 <andythenorth> and if they don't solve daylength, I won't explain them as such
18:30:53 <andythenorth> this was helpful
18:31:19 <andythenorth> I think I'll just copy Pikka's 'generation lock' feature
18:31:24 <planetmaker> xxx for realism is a thing which does not fly with any feature in OpenTTD :P
18:31:41 <FLHerne> jgr_: I mean, if andy patches his grfs, patching FIRS to add configurable production (as per that thread) would make people happier than patching the vehicle dates
18:31:55 <FLHerne> planetmaker: You'd be surprised?
18:32:13 <FLHerne> There's, like, UKRS2+ and WAS and BROS or whatever its successor is
18:32:19 <FLHerne> And the entire screenshot subforum
18:32:25 <FLHerne> And all of my savegames
18:32:32 <planetmaker> yes... but realistically speaking, it's not realistic :)
18:32:51 <planetmaker> it's just graphics which somewhat resemble to look like real vehicles
18:33:06 <planetmaker> but their acceleration is strange as time and distance is strange
18:33:14 <FLHerne> planetmaker: It's weird how suspension of disbelief can stretch to cover everything being isometric pixels, but not intricate details of vehicle types :P
18:33:42 <jgr_> Comparing stuff from openttdcoop to much of the screenshot, it is easy to see which is intended to approximate realism
18:33:43 <planetmaker> they even change length when they drive -- or // or \\ or ||
18:34:23 <FLHerne> AAUI, the majority of the "slower intro dates" demand is specifically to play with all of the odd variants in the "comprehensive [country] trainset" grfs
18:34:30 <planetmaker> well, coop certainly does not go for realism on its servers. Usually.
18:34:38 <FLHerne> Which is why andy's proposed solution doesn't solve anything
18:34:41 <planetmaker> and yes @FLHerne . And I can very well understand that
18:35:10 <andythenorth> what I haven't figured out is how to do progression with a generation lock
18:35:15 <FLHerne> The people wanting it are people like, say, me, and I don't play IH much anyway for the reasons we discussed a few weeks ago
18:35:19 <planetmaker> (some) people want a slow game and go through the 1920s, 1930s such that they can actually enjoy the vehicles without them being obsolete after 30 minutes of real time gameplay
18:35:29 <planetmaker> (or whatever years it is)
18:36:00 <andythenorth> planetmaker: that's why I was thinking of a configurable generation length
18:36:03 <andythenorth> or generation lock
18:36:14 *** HerzogDeXtEr has joined #openttd
18:36:32 <andythenorth> I supposed 'vehicles never expire' doesn't solve it?
18:36:48 <andythenorth> also Iron Horse is completely incompatible with 'vehicles never expire' :P
18:36:53 <planetmaker> yes... that somewhat would solve it. But not idealy. Dates are all wrong etc. Realism means then to have approx. the correct date displayed
18:37:21 <planetmaker> if you don't care about date, I do as jgr said: start after all vehicles are present, and buy whatever suits me
18:37:36 <planetmaker> be that slow and early or fast and late
18:38:30 <andythenorth> I don't care about the date
18:38:43 <planetmaker> then daylength is a non-issue for you
18:38:49 <andythenorth> this discussion shows I can just discount daylength
18:38:53 <planetmaker> just play with vehicles never expire and all is fine
18:38:53 <andythenorth> it's of no relevance
18:39:06 <andythenorth> Iron Horse is incompatible with 'never expire' :)
18:39:16 <planetmaker> contact the author and complain :P
18:39:24 <andythenorth> I could just patch the grf locally :P
18:39:25 <planetmaker> I'm sure you got the contact ;)
18:39:34 <andythenorth> version 2.5: only vehicles for 1960 are included
18:39:42 <andythenorth> version 2.6: I got bored, now I'm playing 1870
18:39:58 <planetmaker> hm... t(pi)... variable time with loops
18:40:16 <andythenorth> maybe I should split Iron Horse into multiple grfs
18:40:21 <andythenorth> 1 per generation
18:42:17 <Eddi|zuHause> (i think we had that discussion already)
18:42:50 <andythenorth> I considered 1 grf per roster alternately
18:42:55 <andythenorth> not sure which way to cut it up
18:43:23 <andythenorth> I wish we could package multiple grfs into a single installable wrapper
18:44:47 <nielsm> 3 settings per generation, "enabled", "year introduced", "year expires"
18:45:01 <andythenorth> that works for a single-roster grf
18:45:23 <andythenorth> it collapses when there's a choice between 'British-ish trains', 'American-ish trains'
18:45:31 <andythenorth> which have different tech trees
18:45:44 <andythenorth> this points to splitting Iron Horse by roster
18:55:57 *** Progman has joined #openttd
19:00:04 <Eddi|zuHause> (no, this points to the approach chosen not being the correct solution either)
19:00:39 <jgr_> Unfortunately there is no singular "correct" solution
19:03:15 <Eddi|zuHause> i always wanted a series of "game scale" options, of which daylength would be a part
19:03:19 <Wolf01> I can't understand how IH would be incompatible with never expires
19:03:44 <Eddi|zuHause> Wolf01: that's a case of "andy uses words differently than normal people"
19:04:11 <Eddi|zuHause> Wolf01: what he (probably) means is "the purchase list gets too long for my taste"
19:04:50 <Eddi|zuHause> we already have a game scale option: plane speed
19:04:51 <Wolf01> Hide vehicles then, you can do it,,,
19:05:41 <Wolf01> Yes, I thought to port it to other vehicles too when I made the last daylength attempt
19:06:11 <Eddi|zuHause> other options could be: production rates, decay speed (ratings, reliability), ...
19:08:27 <Wolf01> If we make everything parametric and then pass a multiplier/divider, wouldn't it set the entire game pace as one could want?
19:08:46 <jgr_> It would be easy to end up adding a lot of knobs which users then don't know what to do with
19:09:04 <Wolf01> No, just one, you speed up or slow down, everything
19:09:35 <Eddi|zuHause> the problem with too few knobs is you get endless arguing what the knob should do or shouldn't do
19:09:52 <Wolf01> If you really want you can bury the settings on the config file like PBS ones, but on the options you only have one master value
19:09:56 <Eddi|zuHause> which has happened to almost every daylength patch so far
19:10:45 <planetmaker> definitely not as part of the basic settings :P
19:10:47 <Eddi|zuHause> i see no problem with having several settings, as long as each has a clear domain and a clear description
19:11:21 <Wolf01> The main problem is that if you configure the game in a way the economy doesn't scale up with speed it's your fault
19:11:33 <Eddi|zuHause> oh, we also have another game scale setting already: cargo weight multiplier
19:12:03 <planetmaker> summary settings might be exposed in UI. But the detailed scaling might be cfg-only
19:12:36 <Eddi|zuHause> i see no point in hiding the settings in cfg. you do that for things which would be dangerous to change for uninformed people
19:12:37 <jgr_> The problem with cfg-only detail settings is that non-default values are rarely if ever tested
19:13:12 <planetmaker> then make it UI :)
19:13:22 <jgr_> It is easy to crash OpenTTD by careless changing of some the signal pathfinder penalty settings, for example
19:14:04 <Wolf01> If you want to fine-tune something you should know wath you are doing
19:14:37 <Eddi|zuHause> Wolf01: maybe, but that doesn't really apply here
19:14:54 <Wolf01> And not samu-setting end scale values to see what happens
19:15:55 <Eddi|zuHause> a propos end-scale: some daylength patches were known for overflowing tick counters and stuff
19:19:19 <Eddi|zuHause> which is another of those elaborate under-the-hood stuffs, that's escalating the problem from "3 hours" to "3 months"
19:20:16 <jgr_> At least for my implementation, the most cumbersome part was timetables, followed by making various fields wider
19:21:39 *** sla_ro|master has joined #openttd
19:22:31 <jgr_> Including the NewGRF layer in this would probably push timescaled well beyond 3 months though
19:24:13 <jgr_> For the existing daylength patches, not involving the NewGRF layer is probably a bigger design influence than what people thought the knob should do
19:35:35 <Eddi|zuHause> jgr_: i can imagine. however, andy's actionism is more like a boss entering the room shouting "why isn't anything done yet", which doesn't help anyone who might actually be working on it
19:38:28 *** Eddi|zuHause has joined #openttd
19:39:05 *** frosch123 has joined #openttd
19:49:29 *** Eddi|zuHause2 has joined #openttd
19:52:38 *** andythenorth has joined #openttd
19:55:55 <Wolf01> So, what's your excuse now?
19:56:41 <andythenorth> what was the question?
19:57:04 <Wolf01> <Wolf01> I can't understand how IH would be incompatible with never expires
19:57:14 <andythenorth> oh way too many vehicles
19:57:26 <andythenorth> like a stupid number
19:57:55 <andythenorth> partly because the game runs too fast
19:58:41 <andythenorth> yeah way too many, I could just delete 50% of them
19:59:07 <Wolf01> Make a setting "only the vehicles I play often"
19:59:50 <Wolf01> Is it finished or there are still dummy graphics on some vehicles?
20:00:03 <andythenorth> the released version 100% of sprites are complete
20:00:09 <andythenorth> some cargos are very generic
20:01:19 <Wolf01> Is there a setting to filter out the wagon sizes?
20:01:51 <frosch123> add a setting: roaster size, 25%, 50%, 75%, 100% of vehicles are introduced, rest is skipped, randomised by game seed
20:02:17 <frosch123> Wolf01: players can already hide individual vehicles from purchase list
20:02:17 <andythenorth> frosch123: I seriously considered random roster :P
20:02:33 <Wolf01> I would always use one size, medium or large, I doubt to use small ones if not on early ages
20:02:57 <andythenorth> I tested a parameter for that
20:03:05 <andythenorth> forums said 'no need' but
20:03:14 <andythenorth> if you play test Horse and want it, I'll add it
20:03:18 <Wolf01> <andythenorth> Wolf01: you started all this <- I know, I'm one of the top activists for daylength
20:03:29 <andythenorth> "wagons: all | smallest | medium | largest"
20:03:32 *** supermop_work has joined #openttd
20:07:32 *** Eddi|zuHause2 is now known as Eddi|zuHause
20:07:38 <Eddi|zuHause> <andythenorth> 2018 <-- more like 2006? :p
20:10:05 <andythenorth> I didn't look that far back :)
20:13:10 <andythenorth> Eddi|zuHause: see if you can find the patch you wrote that resets the year on a tick-tock :P
20:13:16 <andythenorth> you denied all knowledge last time
20:13:38 <Eddi|zuHause> andythenorth: i'm fairly convinced i had no involvement in that
20:13:47 <andythenorth> I can't find it in logs
20:13:55 <andythenorth> there's an equivalent patch in forums
20:16:13 <andythenorth> if game progression was 50% of current rate, I could maybe cut out 50% of Iron Horse :P
20:16:33 <andythenorth> and remove the fairly small tedious stats progression steps
20:17:25 <Eddi|zuHause> not quite following your logic
20:21:52 <andythenorth> there is a decent length of game which is about 80 years, approximately
20:22:19 <andythenorth> in real-world clock time
20:22:23 <andythenorth> and because realism, that requires new trains every 30 years or so
20:22:27 <andythenorth> which imposes a lot of generations
20:22:46 <andythenorth> and the desire to use early or late stage tech extends that either end
20:24:45 <andythenorth> to play for the same number of hours IRL, and have the in-game year advance at half the rate
20:24:58 <andythenorth> means that fewer generations are needed
20:25:05 <andythenorth> which means fewer fine-grained stat increases
20:30:21 <Eddi|zuHause> still not making any sense
20:30:56 <nielsm> fewer generations means longer between generation changes, slower game year advance means same number of game years take longer real time
20:31:14 <nielsm> combining them means four times as long real time between generations
20:32:15 <Eddi|zuHause> but... those things are completely orthogonal?
20:33:05 <Eddi|zuHause> why would a change in one area facilitate/nececitate/enable the other?
20:33:50 <andythenorth> playing for the same amount of RL time
20:33:56 <andythenorth> game year advances 1930-2010
20:34:08 <andythenorth> the first option requires many more trains
20:35:41 <Eddi|zuHause> but, you're now splitting your audience into people who want 1930-1970 or 1970-2010, each demanding a logical game progression
20:36:06 <Eddi|zuHause> of early, mid and late game
20:38:11 <nielsm> well then what even defines a set of currently available vehicles etc. as being early/mid/late game?
20:38:38 <andythenorth> my grfs currently cover 1860-2030 and it's too much
20:38:59 <andythenorth> I do 1860 because Dan MacK really wanted 1860 start
20:39:07 <andythenorth> and I go to 2030 because it was requested
20:39:18 <andythenorth> but it would be better to do 1930-2030 and that be all
20:39:27 <Eddi|zuHause> andythenorth: there's no reason why these requests would disappear with daylength available
20:39:29 <andythenorth> maybe I should just do that, Eddi|zuHause is correct
20:39:36 <frosch123> should newgrf phone home to report which vehicles are used? :p
20:41:37 <Eddi|zuHause> andythenorth: in CETS i have parameters for each era (pre-1920, 1920-50, 1950-1990, post-1990), which you can enable and disable at will
20:41:59 <Eddi|zuHause> andythenorth: and the last enabled era will have expanded model life
20:42:34 <Eddi|zuHause> while each era will still have some progression within it
20:43:03 <Eddi|zuHause> problem is, almost nobody will set these parameters
20:43:34 <Eddi|zuHause> and i have too many options for each era (what you would call rosters)
20:43:50 <Eddi|zuHause> too many to pick a default
20:44:18 <andythenorth> does that give Wolf01 infinite steam era?
20:45:19 <Eddi|zuHause> no, as you would have to duplicate that for all other vehicles, buildings, whatever
20:49:57 <andythenorth> yes but I can....
20:53:11 <andythenorth> I can do ships, trains, RVs, all with same parameter
20:58:41 <andythenorth> maybe not planes :P
21:01:33 <andythenorth> how long does Train Fever run?
21:04:19 <nielsm> 1850 to 2020 or there about
21:04:52 <nielsm> but I don't recall exactly how fast in-game year passes
21:05:06 <nielsm> (it's also hard to judge with the poor performance that game has in general)
21:11:03 *** arikover has joined #openttd
21:11:29 <andythenorth> ok so nielsm have you concluded the NoCalendar is too hard?
21:11:32 <andythenorth> or just a lot of work?
21:22:37 <Wolf01> I think I'm too much tired to do anything
21:28:06 <andythenorth> so we concluded....
21:28:15 <andythenorth> * daylength is possible just a lot of work?
21:28:19 <andythenorth> * Iron Horse is too big
21:28:30 <andythenorth> * confirmation bias exists
21:30:16 <frosch123> * there is not one ottd to rule them all
21:30:47 <andythenorth> that's in the game goals :D
21:32:18 <andythenorth> shall I do a company colour version of these wagons, as separate IDs?
21:32:25 <andythenorth> I've run out of ctrl-click bits for them :P
21:32:33 <andythenorth> it's a short supply :P
21:33:22 <frosch123> you can turn iron horse into a lock picking game
21:33:54 <frosch123> player has to flip 2nd, 5th, 7th vehicle to unlock some special sprite
21:34:25 <andythenorth> I was considering modifier vehicles
21:34:29 <andythenorth> did V do that already?
21:34:34 <frosch123> have you considered implementing regearing by flipping n vehicles? with only 4 wagons you can get 16 regearing modes
21:34:37 <andythenorth> like a vehicle to set the livery, which goes invisible
21:34:59 <andythenorth> not sure I can check flip with offsets?
21:35:04 <Wolf01> The short ones look like copy-pasted bits of the long ones... oh wait, they are :P
21:35:14 <andythenorth> Wolf01: funny that :P
21:35:21 <andythenorth> I have now pretty much drawn
21:35:22 <frosch123> you can't in cb36, but you do not need cb36 for livery
21:35:30 <andythenorth> do for regearing though?
21:35:52 <andythenorth> I have now pretty much drawn all the OO trains I had as a child
21:35:57 <andythenorth> and all the ones I wanted in the catalogue
21:36:01 <andythenorth> so life goals are complete
21:36:04 <frosch123> yeah, too bad, regearing wont work :)
21:36:56 <andythenorth> regearing, change main engine, derate engine for reliability, change traction motors, add or remove ballast weight
21:37:02 <andythenorth> change springs for maximum speed
21:37:12 <andythenorth> isolate or enable carriage electric supply
21:38:13 <andythenorth> remind me, why aren't liveries (subtypes) a good idea?
21:38:42 <frosch123> for your purpose cargo subtypes are the ideal solution
21:39:22 <andythenorth> I must use them!
21:39:54 <andythenorth> I particularly like how they work with consist of mixed vehicles
21:39:54 <nielsm> but they don't work with auto-refit, right?
21:39:56 <frosch123> their downsides apply to the alternatives as well, but they were no concern to you
21:40:23 <andythenorth> when a consist has different vehicles with multiple subtypes, the menu is so...usable :)
21:41:34 <frosch123> nielsm: ottd is quite smart with matching subtypes, a lot of stuff actually works
21:42:08 *** Smedles has joined #openttd
21:44:07 <nielsm> I should go sleep, night
21:45:38 <andythenorth> frosch123: how about a magic hotkey to toggle 1CC / 2CC? o_O
21:46:05 <andythenorth> if enough silly things are said, one might stick :P
21:46:18 <frosch123> just use palette animation
21:46:54 <frosch123> even V didn't animate the rainbow on the slugs, so you can beat him to that
21:48:56 <andythenorth> taste the rainbow
21:49:18 <andythenorth> user-selectable palette cycle :P
21:52:45 <Wolf01> Make engine front change color depending on current speed
21:53:09 * andythenorth wonders what var 47 is for
21:53:29 <andythenorth> oh not 47, F2, I misread wiki
21:53:40 * andythenorth wonders what var F2 is for
21:55:19 <andythenorth> oh callback 36 can write prop 25?
21:55:23 <andythenorth> so trains have perm. storage?
21:59:07 <andythenorth> only readable with var 42, not ideal :)
21:59:51 <Eddi|zuHause> (i feel we had this discussion already)
21:59:57 <frosch123> F2 is the persistent storage that is written when selecting a cargo subtype
22:00:36 <frosch123> i have never seen a convincing usecase for prop 25
22:01:32 <andythenorth> it's a weird prop
22:02:06 <andythenorth> anyway, I wanted to set prop 25 when flipping the vehicle, but nvm :)
22:32:43 *** Smedles has joined #openttd
22:42:28 *** Smedles has joined #openttd
23:23:54 *** andythenorth has left #openttd
23:30:01 <FLHerne> What exactly does nml STORE_TEMP() do [and what's the address range] ?
23:30:19 <FLHerne> (plan B as always is 'read the source', but might as well ask
23:33:38 <frosch123> you give it a register and a value
23:33:46 <frosch123> it stores the value in the register
23:33:54 <frosch123> you use that to pass values between switches
23:34:20 <frosch123> and to insert parameters into production callbacks and sprite layouts
23:34:55 <frosch123> address range is 0 to 127 iirc
23:35:23 <frosch123> the other half is used by nml to store temporary values in nested expressiosn
23:36:52 <frosch123> you can compare them to stack variables in other languages
23:37:09 <FLHerne> Oh, the "other half" bit was the thing I missed, I think
23:38:12 <frosch123> when you run nml it outputs some statistics at the end
23:38:29 <frosch123> one of those tells you how many temporary registers were used to generate expressions
23:40:39 <frosch123> they are used to store the results of (...) while evaluating the next (...)
23:41:01 <frosch123> "free" as in, you have nothing to do for it? :p
23:42:32 <FLHerne> Was just reading that
23:43:19 <FLHerne> Are they separate from the parameters that actionD reads/writes?
23:43:24 <frosch123> registers 100-10F are write-only registers for large callback results
23:43:44 <frosch123> yes, actiond is like "static const"
23:43:55 <frosch123> only done during initialisation and then constant
23:44:05 <glx> static but not always conts
23:44:15 <frosch123> action2 registers are stack variables. only valid during callbacks, discarded after each callback
23:44:17 <FLHerne> I thought so, but "used by nml to store temporary values in nested expressions" sounds like the actionD chains that nml creates to do that
23:45:05 <glx> some nml action D could be done directly in action 2
23:45:49 <frosch123> yes, nml also needs actiond registers for "temporary" values, but technically they are "static"
23:46:41 <frosch123> ok, let's say actiond is like "consteval"
23:46:59 <glx> most of the time I see action D then action 6 for something that could be implemented in the varact2
23:47:07 <frosch123> so, actiond is preferred over action2 whenever possible, since it is only evaluated once
23:47:21 <frosch123> glx: that's optimisation
23:47:32 <glx> but I guess it's also easier to handle param access in only one way :)
23:51:26 *** andythenorth has joined #openttd
23:54:08 * andythenorth draws some pixels
23:54:11 <andythenorth> expended far too many silly words today :)
23:55:38 <FLHerne> andythenorth: "one grf per roster" sounds like a very good idea
23:55:57 <andythenorth> there is a logic to it
23:56:00 <FLHerne> andythenorth: If nothing else, because a surprisingly high proportion of players don't know about grf parameters
23:56:02 <andythenorth> causes some naming issues :P
23:57:08 <andythenorth> wonder if I can compile multiple from one repo
continue to next day ⏵
