IRC logs for #openttd on OFTC at 2023-05-08
00:05:53 <Eddi|zuHause> are they reacting on tile reservations?
00:10:24 <DorpsGek> [OpenTTD/OpenTTD] PeterN opened pull request #10786: Feature: Add search filter and name text to build waypoint window.
00:10:41 <petern> I have no idea. I'm not drawing or using them.
00:12:48 <glx[d]> so CI with mingw in release build type is faster to build than debug, but it fails because many warnings are fired
00:40:24 *** Soni has quit IRC (Ping timeout: 480 seconds)
01:41:32 *** Soni has joined #openttd
02:26:02 *** Wormnest has quit IRC (Quit: Leaving)
03:01:43 *** D-HUND has joined #openttd
03:05:15 *** debdog has quit IRC (Ping timeout: 480 seconds)
03:09:40 <DorpsGek> [OpenTTD/OpenTTD] 2TallTyler dismissed a review for pull request #10783: Change: Harmonized tree placement window with other construction windows
03:26:36 *** D-HUND is now known as debdog
04:26:32 *** keikoz has joined #openttd
04:30:29 *** axet has joined #openttd
05:16:58 <axet> can we allow dedicated server to save threaded?
06:34:25 <axet> what minimum BogoMIPS required for openttd? I have 700 and it runs at 50% speed
07:02:06 *** WormnestAndroid has quit IRC (Read error: No route to host)
07:04:33 *** WormnestAndroid has joined #openttd
07:17:19 <petern> BogoMIPS, wow.
07:18:10 <petern> There is a good reason they are called "Bogo" MIPS.
07:21:03 <axet> better cpu score?
07:21:16 <axet> is here any?
07:21:50 *** Flygon has quit IRC (Quit: A toaster's basically a soldering iron designed to toast bread)
07:22:07 <petern> Benchmark results normally, preferably of a similar workload.
07:22:57 <axet> aha. i thought the same
07:23:40 <axet> i know here a lot. 7zip for example. but universial?
07:24:42 <petern> For the record, my original single-core 700MHz Raspberry Pi shows 697. My quad-core 1200MHz Raspberry Pi 3 shows up to 76. It is definitely not a single bit slower, let alone 10 times slower.
07:26:41 <petern> What map size are you using on that Pi?
07:26:57 <petern> I think you may have mentioned but I don't remember.
07:26:59 <axet> 1k 2k
07:27:03 <petern> Ahhh
07:27:20 <axet> less is boring
07:27:27 <petern> Yes. That is definitely far too big to run on an early Raspberry Pi.
07:27:50 <axet> ok bogomips is bad
07:27:57 <petern> And multithreaded saves won't particularly help because it's single core.
07:28:04 <axet> it helps
07:28:07 <axet> i rebuild it
07:28:28 <axet> BTW liking openttd on rpi1 took 5 hours and I killed it
07:28:56 <axet> just linking
07:29:04 <axet> single openttd bin
07:30:51 <petern> <>
07:30:52 <axet> without threaded saves - rpi1 lags for 6 seconds lza, with threaded saves (patch) it lags for 1 second and then game speed drops to 0.22x for 5 seconds
07:31:09 <axet> normal speed is 0.55x
07:31:48 <petern> The Pi 4 smashes the Pi 1, and its not exactly a power house itself.
07:31:53 <LordAro> i think you need to lower your expectations
07:32:49 <axet> 7z rpi1 gives 2691 score
07:33:06 <axet> 28495 or this number not sure
07:33:12 <axet> wait
07:34:43 <axet> rpi1 7z gives 166 rating
07:36:08 <LordAro> these are all very different numbers
07:37:22 <petern> Out of memory: Killed process 14448 (7z)
07:37:27 <petern> That went well :p
07:38:31 <axet> my first numbers from my laptop
07:38:52 <petern> You should run your server on your laptop.
07:39:04 <axet> 7z b gives 164/351 or total = 259
07:39:14 <axet> i sleep sometimes
07:39:42 <petern> ~ 610/1300 on my Pi 3, but it crashed before giving the total.
07:39:49 <axet> i guess 260 is 50% speed. we need 500 as '7z b' test.
07:40:12 <axet> try lower dict memory size
07:40:13 <petern> What you need is to run a smaller map on your Pi, or switch to a faster device.
07:42:24 <axet> rpi1 only pi i have
07:44:07 <axet> I guess my suggestion to have threaded saves on dedicated servers.
07:45:07 <axet> helps a lot
07:45:24 <axet> Raspberry Pi Model B Plus Rev 1.2
07:46:04 <petern> Earlier than my Pi 1.
07:46:13 <axet> :)
07:46:29 <axet> for anyone how need systemd services configuration:
07:46:35 <petern> Ah, of course, my server is only 9 years old, but the Pi 1 is now 11 years old.
07:47:10 <axet> and still crazy expensive
07:47:32 <axet> much easier buy 20 years old smartphone and it would be faster than pi
07:48:30 <pickpacket> I'm running my server on a RPi 3B+, but the connection is a bit iffy. I think it's because it's over wifi. I've been donated another 3B that I'll connect by cord and move the server to :)
07:49:51 <axet> how much CPU openttd uses on your rpi3?
07:50:10 <pickpacket> I don't want a RPi 4. They're pretty pricey, too weak to be a desktop, too beefy and power hungry to be anything else
07:50:16 <pickpacket> Not much
07:50:28 <axet> my bet 50%
07:51:02 <axet> do you have '7z b' results to share?
07:51:13 <pickpacket> It's set to pause when no client is connected
07:51:22 <petern> Ah for stations the class name is "Default station" and is also displayed as the name of the default station.
07:51:22 <pickpacket> 7z b?
07:51:32 <axet> 7z benchmark
07:51:41 <pickpacket> not sure how to get that
07:51:42 <petern> For waypoints the class name is "Waypoints" and... I think naming the default waypoint as "Waypoints" is wrong πŸ™‚
07:52:15 <axet> console command '7z b'
07:52:23 <axet> if you are using linux ofc
07:52:31 <pickpacket> of course I am ;)
07:52:35 <pickpacket> I can check later
07:53:11 <petern> It'll be around 600/1300 πŸ™‚
07:53:24 <pickpacket> and what does that mean? :D
07:53:56 <petern> Nothing by itself.
07:54:41 <axet> 600compressing MIPS and 1300 decompressing MIPS
07:54:53 <axet> and average below it
07:55:10 <axet> (600+1300)/2=950
07:55:17 <axet> 950 is the score
07:55:25 <axet> rpi1 gives 250
07:55:31 <petern> It's just a slightly better benchmark than "BogoMIPS", as long as you are interested in compression/decompression speeds.
07:55:32 <pickpacket> the 3B will be dedicated to just running the OpenTTD server for the foreseeable future. I have a 2B that I run gemini and http servers on, and a 1B+ that I run as a file server
07:56:48 <axet> that a lot of enegry wasted
07:57:37 <pickpacket> well. "A lot" is relative
07:58:01 <axet> relative is subjective
07:58:02 <pickpacket> It's not going to run at a higher clock rate than it needs
07:58:43 <pickpacket> my three servers in total probably use less energy than a 1CPU VM at any cloud provider
07:59:20 <axet> i think so
08:00:09 <pickpacket> If I see that the OpenTTD server takes up very little I'll move it to my 2B. Having the fileserver and the public-facing services separated to different servers is a security issue
08:00:49 <pickpacket> how much energy do you suppose is "wasted"?
08:01:42 <axet> of course I was joking
08:02:14 <pickpacket> oh. :D
08:02:55 <axet> rpi need a usb power cable 500ma
08:05:06 <pickpacket> I'm using common USB charger cables and adapters without any issues 🀷
08:08:14 <axet> Raspberry Pi 3 Model B consumes about 260 mA
08:08:14 <axet> Raspberry Pi 3 Model B+ consumes about 400 mA
08:08:23 <axet> 1.4W
08:08:29 <axet> 1-2W
08:10:04 <petern> My new benchmark: how fast is your OpenTTD compile after changing english.txt ...
08:13:36 <petern> I wonder how well an Orange Pi 5 will play, with up to 32GB RAM, that's quite a bit of headroom for serverythings.
08:13:53 <axet> price should be 10-15$
08:14:06 <petern> Even the Pi is nowhere near that now.
08:14:33 <axet> i wont pay 50-100$ per "tiny board"
08:20:37 <petern> Sure. Just manage your expections.
08:21:52 <axet> for 50 you can have a old / refurbished phone with battery, display and touchscreen. and it would be faster then RPI
08:22:26 <petern> And not suitable as a server.
08:22:44 <axet> install postmarket os
08:23:51 <andythenorth> moin
08:25:21 <petern> Hmm, have I broken this bit
08:25:58 <petern> Hah. Yes.
08:27:53 <petern> `==` is not `!=`
08:28:12 <andythenorth> yo, do we have {BLINK}?
08:28:15 <andythenorth>
08:28:20 <petern> {MARQUEE}
08:28:22 <andythenorth> "Variants: 4" is easily lost
08:28:38 <petern> Also, {REVEAL} for the Teletextness.
08:28:39 <andythenorth> (will actually be a list of colous)
08:28:44 <andythenorth> {SPOILER}
08:30:12 <andythenorth> tempted to make all wagons carry everything πŸ˜›
08:30:24 <andythenorth> do I really care about enforcing what player does?
08:31:08 <andythenorth> coal in milk tanker? why not?
08:31:15 <petern> It's almost like you need it to display the classes instead of types...
08:31:35 <petern> But they're not well defined with actual names.
08:31:45 <andythenorth> non-pourable countable bulk
08:33:35 <DorpsGek> [OpenTTD/OpenTTD] TrueBrain approved pull request #10778: Change: use precompiled headers to speed up compilation
08:40:42 <andythenorth>
08:40:42 <andythenorth> well, colour names eh
08:40:43 <TrueBrain> did I really write an unique UUID .. well, that is just silly
08:41:01 <andythenorth> it's like no other UUID
08:42:42 <DorpsGek> [OpenTTD/OpenTTD] mrmbernardi updated pull request #10755: Feature: Setting to disallow level crossings with competitors
08:42:44 <petern> Hmm, building/liking OpenTTD WSL seems faster than native.
08:44:03 *** gnomechomsky has joined #openttd
08:44:03 <gnomechomsky> mrmbernardiviaGitHub: does anyone want to review this one?
08:44:22 <petern> You've literally just opened it...
08:45:04 <gnomechomsky> Nah it's been open for a week
08:45:43 <petern> Oh, updated, sorry. Misread πŸ™‚
08:50:35 <petern> Hmm, pasting images into Discord is crashing it :/
08:51:07 <andythenorth> silly Discord
08:51:52 <petern> The Snipping Tool is crashing at the same time...
08:52:06 <gnomechomsky> micro$oft wind0ze
08:52:16 <TrueBrain> LordAro: duplicatey? Where? What?
08:52:25 <TrueBrain> you mean the blog post?
08:52:42 <petern> Hmm, possibly an issue when using WSL programs?
08:52:55 <petern> <>
08:53:44 <DorpsGek> [OpenTTD/OpenTTD] TrueBrain commented on pull request #10719: Feature: opt-in survey when exiting a game
08:54:16 <axet> can I change simulation rate? set it below 33.3?
08:54:33 <petern> Only by changing the source code.
08:55:37 <axet> i guess refresh_rate should affect dedicated server in that sense
08:55:44 <axet> i'll fix that
08:55:45 <LordAro> TrueBrain: the site structure as a whole
08:55:50 <LordAro> all the ruby etc
08:55:51 <DorpsGek> [OpenTTD/OpenTTD] TrueBrain commented on pull request #10719: Feature: opt-in survey when exiting a game
08:56:04 <TrueBrain> ah, yes, the illusive promise of andy to fix that πŸ˜› πŸ˜„
08:56:09 <LordAro> hehe
08:56:25 <andythenorth> what was I fixing?
08:56:35 <andythenorth> too busy making things {BLINK}
08:56:39 <DorpsGek> [OpenTTD/OpenTTD] PeterN updated pull request #10786: Feature: Add search filter and name text to build waypoint window.
08:56:45 <TrueBrain> HTML .. CSS .. you know, the usual πŸ™‚
08:56:50 <andythenorth> lol yes
08:57:06 <andythenorth> don't we have any junior contributors?
08:57:35 <andythenorth> we can probably just GPT it?
08:58:45 <DorpsGek> [OpenTTD/OpenTTD] PeterN commented on pull request #10786: Feature: Add search filter and name text to build waypoint window.
09:01:02 <petern> All the waypoints in GETS Waypoints are named "GETS Waypoints" because... the name was never shown so why bother naming them...?
09:01:15 <petern> (It's shown in the land area information window)
09:02:00 <DorpsGek> [OpenTTD/survey-web] TrueBrain merged pull request #1: Feature: informational part of the survey website
09:03:54 <gnomechomsky> andythenorth: You're looking for someone to make a low hanging fruit feature?
09:03:56 <gnomechomsky> I put my hand up
09:04:04 <gnomechomsky> I'm looking for more contributions
09:04:26 <gnomechomsky> Oh, the website
09:06:07 <TrueBrain> haha, see him run πŸ˜›
09:06:37 <TrueBrain> him? them! I was suppose to not assume anymore ... πŸ˜› Why is that so hard, you can wonder πŸ™‚
09:08:17 <DorpsGek> [OpenTTD/OpenTTD] TrueBrain commented on pull request #10719: Feature: opt-in survey when exiting a game
09:09:09 <petern> HTML/CSS is too much like my day-job, sorry.
09:09:32 <TrueBrain> no need to be sorry; we all are avoiding it πŸ˜›
09:09:54 <gnomechomsky> Okay, is there a repo for the website?
09:10:09 <gnomechomsky> The problem is I haven't done much web dev, so it would take a while for me to set up a dev environment
09:11:40 <petern> Hmm, maybe should update my MIDI looper.
09:11:45 <andythenorth> TrueBrain: there are 2 answers to that πŸ˜› (1) 'they / them' is a provision English has had for years and avoids all the drama (2) this community is not, afaik, very gender balanced πŸ˜›
09:12:33 <petern> And give it a GUI, instead of an ncurses UI.
09:12:46 <andythenorth> get GPT to do ti
09:13:49 <ag> petern: What is wrong with ncurses
09:13:51 <ag> ?
09:13:58 <ag> It looks simple
09:25:45 <Eddi|zuHause> andythenorth: well, the usual argument sounds like (2) is the result of not using (1)
09:25:47 <andythenorth> hmm python from GPT
09:25:48 <andythenorth> works
09:33:56 <DorpsGek> [OpenTTD/OpenTTD] TrueBrain updated pull request #10719: Feature: opt-in survey when exiting a game
09:34:46 <TrueBrain> right .. few things left to do .. waiting for the C++-ifying PRs to pass review, and figure out how to generate a key per release .. ALMOST there πŸ™‚
09:41:03 <DorpsGek> [OpenTTD/OpenTTD] TrueBrain updated pull request #10719: Feature: opt-in survey when exiting a game
09:41:09 <TrueBrain> maybe rebase against master ... avoids adding ... 52 extra commits πŸ˜›
09:41:38 <petern> I just used git svn clone. Been a while.
09:41:47 <TrueBrain> brrrrr
09:43:51 <andythenorth> list(foo.keys).index('bar')
09:43:52 <DorpsGek> [OpenTTD/OpenTTD] TrueBrain updated pull request #10719: Feature: opt-in survey when exiting a game
09:43:57 <andythenorth> sometimes python has pitfalls
09:44:01 <TrueBrain> hmm .. do I PR the adding of a JSON library separately, or make it part of that PR? Hmm ..
09:45:15 <andythenorth> GPT says `In any case, it's always a good idea to discuss your decision with your team and get their feedback before submitting your PR. This will help ensure that everyone is on the same page and that your changes are reviewed in the most effective way possible.`
09:45:28 <andythenorth> what a world
09:57:37 <andythenorth> err
09:57:47 <andythenorth> STORE_TEMP(
09:57:47 <andythenorth> switch_get_colour_name(101)
09:57:47 <andythenorth> | (switch_get_colour_name(16) << 16),
09:57:47 <andythenorth> 0x101
09:57:47 <andythenorth> ),
09:58:01 <andythenorth> what's the correct shift for results from a procedure?
09:58:13 <andythenorth> the result is a string(), don't know what range it's in
09:58:43 <andythenorth>
09:58:43 <andythenorth> but this is not the desired result πŸ˜›
09:58:46 <andythenorth> should be colour names
09:59:37 <Eddi|zuHause> possibly should &0xFFFF the procedure result
10:02:02 <andythenorth> is there some thing where only D0 strings can be returned or such?
10:03:13 <Eddi|zuHause> there's a translation between TTD strings and OTTD strings, you can only return strings that are part of this translation
10:05:07 <andythenorth> hmm
10:07:14 <andythenorth> ` STORE_TEMP(
10:07:14 <andythenorth> switch_get_colour_name(1) & 0xFFFF
10:07:14 <andythenorth> | ((switch_get_colour_name(16) & 0xFFFF) << 16),
10:07:14 <andythenorth> 0x101
10:07:14 <andythenorth> ),
10:07:15 <andythenorth> `
10:07:34 <andythenorth> doesn't work
10:12:58 <andythenorth> no idea what range these strings are in πŸ˜›
10:14:04 <andythenorth>
10:15:13 <andythenorth> storing the strings directly, not as the returned result of a procedure, works
10:19:14 <Eddi|zuHause> those are strings defined in your GRF?
10:19:49 <andythenorth> yup
10:20:17 <andythenorth> what size is a string?
10:20:26 <andythenorth> I wonder if 15 bit procedure results are again a problem
10:21:26 <Eddi|zuHause> doesn't it use the 32bit version of the result?
10:21:27 <andythenorth> string ID is word sized though?
10:21:37 <andythenorth> hmm
10:21:47 <andythenorth> I thought all procedure results were 15 bit?
10:21:53 <Eddi|zuHause> kinda
10:22:27 <andythenorth> there's a var I can get the 32 bit result from I believe
10:22:47 <Eddi|zuHause> yes, var1C
10:23:09 <andythenorth> syntax for using that inside a STORE_TEMP though 😦
10:23:11 <andythenorth> oof
10:23:36 <Eddi|zuHause> may be unreliable...
10:23:36 <andythenorth> I need to get the result, discard it, store 1C
10:23:50 <Eddi|zuHause> nml should probably do that by default
10:24:06 <andythenorth> I could do the store inside the procedure
10:24:15 <andythenorth> I'd have to parameterise the shift
10:24:56 <Eddi|zuHause> problem with that is you can't combine two strings in one register
10:25:47 <Eddi|zuHause> anyway, you can try adding "|0x8000"
10:25:50 <andythenorth> I could have two procedures
10:25:57 <andythenorth> one of which reads the existing register
10:26:11 <Eddi|zuHause> it's a write only register
10:26:17 <andythenorth> FFS
10:26:28 <andythenorth> where am I adding `|0x8000`
10:26:30 <andythenorth> ?
10:26:40 <Eddi|zuHause> where you added the &0xFFFF
10:29:05 <petern> Are you trying to use colour names?
10:29:48 <petern> Possibly you want a solution similar to <> and <>
10:30:19 <andythenorth>
10:30:19 <andythenorth> progress
10:30:27 <ag> ,,,,?
10:30:54 <andythenorth> unfortunately I also have custom names 😦
10:31:08 <Eddi|zuHause> so, back up...
10:32:00 <Eddi|zuHause> it works correctly if you replace switch_get_colour_name(xy) with string(STR_COLOUR_NAME_xy)?
10:32:29 <Eddi|zuHause> can you output raw number instead of string?
10:32:37 <Eddi|zuHause> for both of these
10:32:41 <andythenorth>
10:32:41 <andythenorth> this is telling
10:34:38 <Eddi|zuHause> yeah, those StringIDs are definitely wrong
10:35:21 <Eddi|zuHause> they should be in the 0xDxxx range
10:36:04 <Eddi|zuHause> it could be that nmlc is trying to be too intelligent...
10:36:26 <Eddi|zuHause> but can you go back and do what i asked?
10:40:16 <gnomechomsky> Can anyone help me with my clangd not working?
10:40:45 <gnomechomsky>
10:40:56 <gnomechomsky> I get a bunch of errors on every file and it starts with that unknown argument thing
10:41:18 <gnomechomsky> It's finding the build/compile_commands.json file
10:43:40 <gnomechomsky> ah, maybe I need to set CXX to clang
10:45:02 <andythenorth> strings are missing from the nml for reasons I don't understand
10:45:39 <andythenorth> STR_COLOUR_NAME_COLOUR_BLUE is in the lang file, but nml doesn't find it
10:45:55 <andythenorth> nvm user error
10:47:16 <andythenorth>
10:47:16 <andythenorth> Eddi|zuHause: storing string names directly works
10:48:03 <andythenorth> unfortunately they're not static per vehicle
10:48:12 <andythenorth> I need to switch some of them depending on player CC choice
10:48:17 <andythenorth> oh will that desync?
10:49:58 <andythenorth> ok so the strings are valid
10:49:59 <axet> patch allowing controlling dedicated server refresh rate using 'refresh_rate' [gui] setting. helps on low end platforms:
10:50:18 <andythenorth> and the "Unknown StringID" warnings are not currently triggering
10:50:58 <Eddi|zuHause> andythenorth: so can you output raw number instead of {STRING}?
10:51:02 <Eddi|zuHause> and compare?
10:51:42 <andythenorth> yup
10:52:09 <andythenorth> UNSIGNED_WORD?
10:52:13 <andythenorth> or SIGNED_WORD?
10:52:26 <Eddi|zuHause> unsigned
10:53:52 <andythenorth>
10:53:52 <andythenorth> ok the version storing string ID directly
10:54:49 <andythenorth> for the procedure return version, I'm still using `|0x8000` ?
10:54:54 <andythenorth> or just raw stringID?
10:55:07 <petern> axet: Can't you just change _game_speed?
10:56:02 <axet> petern: how? i mean here is no cfg option for that
10:56:19 <andythenorth>
10:56:19 <andythenorth> ok with no & or |
10:56:20 <Eddi|zuHause> andythenorth: leave the |0x8000 out for now
10:56:35 <andythenorth> hmm maybe the procedure is failing then
10:56:39 <andythenorth> that's just the input numbers
10:57:20 <andythenorth> yeah the procedure is not working as expected
10:58:09 <Eddi|zuHause> right, then it's probably using var1C, but that's the evaluation of the switch, not the switch result?
11:04:18 *** m3henry has joined #openttd
11:04:20 <andythenorth> is there just PEBKAC error in `switch_get_colour_name`?
11:05:08 <Eddi|zuHause> no, i think the logic is weird...
11:05:09 <glx[d]> In some cases you have to or the string range manually
11:05:50 <glx[d]> Nmlc doesn't always detect when results are strings
11:06:02 <glx[d]> So can't do the magic
11:06:27 <andythenorth> glx[d]: but the results returned here by the procedure are just the inputs
11:06:46 <andythenorth> in the last screenshot, I pass 0, 1, 16, 18, 19 to the procedure
11:06:48 <andythenorth> and I get those back
11:07:14 <andythenorth> it's like the varact2 is just returning the params...
11:07:51 <andythenorth> is 'string(FOO)' a valid return from a varact 2?
11:08:25 <m3henry> andythenorth: some of these wagons seem half full:
11:09:02 <andythenorth> they do don't they
11:09:10 <andythenorth> spritesheet bug probably
11:09:25 <Eddi|zuHause> andythenorth: just for fun, can you put "colour_num+10" in the calculation?
11:10:12 <andythenorth> I gave it a default return also
11:10:18 <andythenorth> made no difference
11:10:35 <andythenorth>
11:10:35 <andythenorth> + 10
11:10:48 <andythenorth> ok now we get the default return
11:10:52 <Eddi|zuHause> also, why are there two colour_num in there?
11:11:03 <andythenorth> parameterised procedure
11:11:08 <andythenorth> but I think it's wrong
11:11:26 <Eddi|zuHause> so, it's acutally returning things, not just returning the calculation. that's good
11:11:31 <andythenorth> yes
11:11:38 <andythenorth> so maybe string() isn't a valid return?
11:12:55 <Eddi|zuHause> maybe
11:13:18 <Eddi|zuHause> so, next try: add |0xDC00 where previously you had the |0x8000?
11:13:23 <andythenorth> it's always puzzling what can be returned as a result
11:13:32 <andythenorth> it's more than I expect, but not everything πŸ˜›
11:17:13 <andythenorth>
11:17:30 * andythenorth finds correct vehicle
11:17:54 <andythenorth>
11:17:55 <Eddi|zuHause> and can you turn back to string?
11:18:12 <andythenorth> yeah they're wrong πŸ™‚
11:19:09 <andythenorth> I still suspect the procedure
11:19:24 <andythenorth>
11:19:49 <Eddi|zuHause> try 0xD000 or 0xD800
11:21:09 <andythenorth>
11:21:09 <andythenorth> 0xD000 might be the one
11:21:31 <JGR> The procedure is not necessary when the argument is a constant, you can just write what string you want
11:21:42 <andythenorth> switches on company colour though πŸ™‚
11:21:50 <andythenorth> "not a constant" πŸ™‚
11:23:12 <Eddi|zuHause> there's probably an nmlc feature request in there, to handle this correctly
11:25:35 <andythenorth> thanks for the help πŸ™‚
11:25:36 <petern> ```openttd: ../src/gfx_layout_icu.cpp:498: virtual std::unique_ptr<const ICUParagraphLayout::Line> ICUParagraphLayout::NextLine(int): Assertion `run.length > new_partial_length' failed.```
11:25:37 <petern> Hmm
11:25:44 <petern> That seems awkward.
11:25:44 <andythenorth> let's see if I can get company colour now
11:31:57 <andythenorth>
11:31:57 <andythenorth> works
11:32:05 <andythenorth>
11:32:16 <andythenorth> hmm ideas
11:32:42 <JGR> What sort of colour is nightshade?
11:33:08 <andythenorth> black
11:33:12 <andythenorth> might just call it black
11:33:23 <andythenorth> but it's not really black, because then there's no contrast to show the vehicle shape
11:34:04 *** WormnestAndroid has quit IRC (Read error: Connection reset by peer)
11:34:15 *** WormnestAndroid has joined #openttd
11:34:31 <Eddi|zuHause> my association with nightshade is (typically poisonous) plants
11:34:36 <andythenorth>
11:34:36 <andythenorth> last row is nightshade
11:34:41 <andythenorth> could just be 'black' though
11:35:25 <Eddi|zuHause> don't see any black there
11:36:27 <andythenorth> this is why I didn't call it 'black'
11:37:19 <andythenorth>
11:37:19 <andythenorth> but it's probably close enough
11:38:06 <Eddi|zuHause> there are probably experts in colour names out there
11:40:43 <andythenorth> GPT
11:41:28 <andythenorth> GPT says "Charcoal"
11:41:34 <andythenorth> is the internationally recognisable term
11:42:00 <JGR> That will be fun when someone adds charcoal as a cargo that you can carry πŸ˜›
11:42:08 <andythenorth> yes won't it
11:42:10 <andythenorth> also graphite
11:42:11 <andythenorth> and slate
11:42:16 <andythenorth> other GPT suggestions
11:42:25 <andythenorth> midnight was another
11:43:11 *** WormnestAndroid has quit IRC (Remote host closed the connection)
11:43:20 *** WormnestAndroid has joined #openttd
11:46:22 <petern> Ah, capture by reference maybe harmful...
11:49:26 <TallTyler> I like nightshade, it’s fun
11:52:12 *** axet has quit IRC (Quit: Leaving.)
11:53:29 *** axet has joined #openttd
11:53:30 *** axet has quit IRC ()
11:55:33 *** WormnestAndroid has quit IRC (Read error: Connection reset by peer)
11:57:08 *** WormnestAndroid has joined #openttd
11:59:00 *** axet has joined #openttd
12:03:42 <petern> Is it lunch?
12:05:45 <TallTyler> Breakfast, actually
12:05:56 <petern> Funnily enough, yes.
12:06:46 <ag> Nope it's teatime
12:08:14 <LordAro> what a world we live in
12:16:53 <axet> should I create pull request restoring threaded save on dedicated server?
12:17:43 <axet>
12:17:58 <axet> help a lot on low end hardware
12:22:31 <LordAro> have you identified why the restriction was put there in the first place?
12:22:31 *** WormnestAndroid has quit IRC (Read error: Connection reset by peer)
12:22:36 <gnomechomsky> Can someone help me understand the build system? E.g. in this file: we are using uint which is defined in stdafx.h but stdafx.h is not included anywhere in this file. How does it work?
12:23:39 <gnomechomsky> Similar issue for assert()
12:23:44 <LordAro> gnomechomsky: cpp files are the ones that are actually compiled. as long as they include stdafx first (and they all do), the following headers pick up those definitions
12:23:58 *** WormnestAndroid has joined #openttd
12:24:15 <LordAro> #include literally just "pastes" the content into the file before it is compiled
12:24:29 <LordAro> (c++ modules not quite yet being a thing)
12:26:06 <gnomechomsky> LordAro: thanks. The reason it came up is because i get a bunch of errors in my editor when viewing the hpp files because of this
12:26:15 <gnomechomsky> what are you doing in your dev environment to avoid this?
12:26:23 <LordAro> yeah, i often get those too
12:26:33 <axet> LordAro no idea
12:26:39 <LordAro> it's not ideal
12:26:58 <LordAro> axet: git blame may help
12:28:05 <LordAro> (or it may not)
12:29:58 <gnomechomsky> LordAro: perhaps its possible to fix this by somehow generating compile_commands.json with entries for the header files that have -include stdafx.h
12:31:12 <LordAro> i don't think we have that sort of control over cmake
12:31:30 <LordAro> beyond adding a load more includes, but they tend to slow down compile time
12:32:30 <LordAro> you could of course add it temporarily to shut your editor up
12:33:23 <petern> Yeah those come and go as my editor sees different files. I don't worry about it much.
12:35:17 <LordAro> personally i'd prefer it if we could properly include headers within headers as they're needed rather than just cpp files, but i get why we don't
12:37:03 <axet> LordAro it does not explain why. looks like people keep updating old code so it become a de facto
12:42:53 <axet> it came back to a51cfd58b8b61cbe2aba3b7c2c56f903ac39594b 2005 year.
12:43:40 <axet> "The server is disabled from threaded-saving, but might be enabled in the future."
12:44:27 <axet> no explanation if this is an issue or author just precosious
12:47:33 <axet> i guess future has come :)
12:48:14 *** Citizen_Kane_23 has joined #openttd
12:48:14 <Citizen_Kane_23> Interesting
12:49:55 <LordAro> axet: seems so!
12:50:37 <axet> anyway we still have an cfg option which allows you to disable it. i guess it save to enable (it works on my machine for a day)
12:53:56 <JGR> I enabled threaded saving for network servers about 2 years ago and it hasn't seemed to cause any problems
12:54:45 <axet> I'll create pull request then. Please vote.
12:54:45 <gnomechomsky> LordAro: What's the reason you don't. They have header guards
13:00:42 <DorpsGek> [OpenTTD/OpenTTD] axet opened pull request #10787: Allow dedicated server to use threaded saves.
13:00:58 <axet> JGR ready
13:03:09 <LordAro> gnomechomsky: Β―\_(ツ)_/Β―
13:03:52 <petern> As Truebrain keeps saying, we should probably put STL things like vector etc in stdafx too.
13:05:44 <JGR> axet: I am not one of the people who can approve such things, but probably it is worth using the PR template and following the commit text formatting restrictions
13:07:34 <DorpsGek> [OpenTTD/OpenTTD] axet opened pull request #10788: Allow control dedicated server refresh rate.
13:10:34 <LordAro> axet: indeed, templates are there for a reason, please do not delete them
13:10:43 <LordAro> or you run the risk of it just being closed
13:11:41 <axet> did I delete something I should't
13:12:19 <LordAro> pull requests normally come with a template
13:12:25 <petern> The template you get when you open a pull request.
13:12:34 <petern> ```std::numeric_limits<ObjectClassID>::max()
13:12:34 <petern> OBJECT_CLASS_BEGIN```
13:12:39 <petern> Hmm, that seems wrong.
13:13:34 <petern> Possibly because it's an enum?
13:14:07 <axet> ah I should keep all those '*'? i read it and ansered in the text
13:14:13 <petern> ``````
13:14:16 <petern> er
13:14:39 <petern> The template has sections to keep at least.
13:15:03 <axet> okok
13:15:34 <petern> As an example: <>
13:15:41 *** nielsm has joined #openttd
13:19:11 <axet> fix that
13:27:25 <petern> Ah, std::underlying_type
13:27:50 <petern> But that doesn't work :/
13:41:34 <petern> Hmm, I guess int/uint shouldn't be used in Cmd.*()
14:01:49 <DorpsGek> [OpenTTD/OpenTTD] PeterN opened pull request #10789: Fix: Set up default station/waypoint classes properly.
14:05:36 <petern> Hmm, is there a way to prevent taking a pointer to something?
14:17:28 *** WormnestAndroid has quit IRC (Read error: Connection reset by peer)
14:18:24 *** WormnestAndroid has joined #openttd
14:19:53 <DorpsGek> [OpenTTD/OpenTTD] PeterN opened issue #10790: [Bug]: ICU Layouter crash
14:24:46 <LordAro> petern: no
14:24:59 <petern> That's what I read too πŸ™‚
14:25:50 <LordAro> i should get off the sofa and do something useful today
14:26:06 <LordAro> not least because my phone's about to run out of battery
14:26:40 <DorpsGek> [OpenTTD/OpenTTD] TrueBrain commented on pull request #10788: Allow control dedicated server refresh rate.
14:26:45 <DorpsGek> [OpenTTD/OpenTTD] TrueBrain closed pull request #10788: Allow control dedicated server refresh rate.
14:27:09 <TrueBrain> petern: managed to crash ICU? Nice πŸ˜„
14:27:37 <petern> No, just the new layouter. Sorry.
14:28:17 <DorpsGek> [OpenTTD/OpenTTD] TrueBrain commented on pull request #10787: Allow dedicated server to use threaded saves.
14:28:22 <TrueBrain> tomato tomato! πŸ˜›
14:28:44 <petern> `template <typename Tspec, typename Tid, Tid Tmax>
14:28:44 <petern> void NewGRFClass<Tspec, Tid, Tmax>::InsertDefaults()`
14:30:01 <petern> This feels awkward as the types are never specified, it just works by being kinda limited in scope.
14:30:30 <DorpsGek> [OpenTTD/OpenTTD] LordAro commented on pull request #10787: Allow dedicated server to use threaded saves.
14:31:02 <TrueBrain> petern: this is currently being worked on πŸ˜„
14:31:24 <TrueBrain> JGR: good you put that in the PR LordAro πŸ™‚
14:31:43 <TrueBrain> the PR sounds like: "I tried this one thingy thing", which is always a bit scary .. so many more ways to use similar functionality πŸ™‚
14:32:28 <DorpsGek> [OpenTTD/OpenTTD] PeterN commented on issue #10790: [Bug]: ICU Layouter crash
14:32:56 <TrueBrain> well, at least I can reproduce it petern ; let's see what is bothering the system πŸ™‚
14:33:12 <TrueBrain> and no, if it cannot find a linebreak, it will just find a glyph to break in between πŸ˜›
14:33:23 <axet> TrueBrain game is not 30ms tick constant. It depend on hardware. That issues I'm trying to solve. I'm not mixing two concepts. Same as when you showing simulation rate and fps on screen.
14:33:30 <petern> My experience of "works fine" is "works fine except for some things stop working but we got used to working around them"
14:33:59 <TrueBrain> axet: no, you are mixing a variable meant for the drawing-thread with the game-thread
14:34:02 <TrueBrain> that is just wrong
14:34:08 <TrueBrain> unrelated to any timing, hardware, etc etc
14:34:28 <TrueBrain> if your hardware is decent enough, the game runs on 27ms per tick; the screen refreshes at 60Hz
14:34:31 <TrueBrain> those two are disjunct
14:34:48 <TrueBrain> my screen refreshes even at 144Hz
14:34:52 <axet> TrueBrain Dedicated server does not use game-thread. Same when you are using single game - it is not mixed. It is only affecting dedicated mode
14:34:53 <TrueBrain> doesn't change a thing about the game logic
14:35:19 <axet> right. That I do not like. When refresh rate affecting the game speed.
14:35:25 <petern> @axet you are misusing an existing variable, just because it's not used for dedicated servers.
14:35:25 <axet> but it does!
14:35:41 <axet> ok. lets call it dedicated_refresh_rate
14:35:49 <axet> but they are very close
14:35:50 <TrueBrain> it is called `_game_speed`
14:36:00 <petern> I may have mentioned that one πŸ™‚
14:36:12 <axet> i want to separate game_speed and refresh rate
14:36:29 <glx[d]> they are separated
14:36:32 <axet> no
14:36:38 <axet> refresh rate == game speed
14:36:48 <TrueBrain> you refresh a screen; you don't refresh a game πŸ˜›
14:36:55 <axet> common
14:36:56 <petern> refresh_rate is the screen refresh.
14:37:01 <axet> ok
14:37:59 <TrueBrain> but as I explained in the PR, besides the mixing of things, it is bad design to make something possible with a dedicated server but not with a GUI server
14:38:01 <TrueBrain> we shouldn't do that
14:38:13 <TrueBrain> so what you actually describe is that you want to modify `_game_speed`
14:38:18 <axet> no
14:38:19 <TrueBrain> and .. well, yes, I wrote what I have to say about that in the PR πŸ™‚
14:38:31 <axet> i want game speed be inrelated with refresh rate
14:38:48 <petern> inrelated?
14:38:58 <axet> not corelated
14:39:01 <petern> Okay
14:39:02 <TrueBrain> this .. makes no sense, sorry πŸ˜›
14:39:09 <petern> game speed and refresh rate ARE unrelated.
14:39:55 <petern> In your PR, you have linked them together, making them related, but only for dedicated servers.
14:40:03 <LordAro> axet: TrueBrain has rewritten much of this game logic only in the last few weeks, and has worked on OTTD for (sorry) over 15 years. Arguing that he does not understand this isn't going to go well
14:40:03 <axet> you got to be joking. open About / Show refresh rate and tell me what you see at 'Simulation rate'
14:40:21 <LordAro> s/game logic/logic/
14:40:51 <TrueBrain> axet: you have two values there: simulation rate, and graphics frame rate
14:40:57 <TrueBrain> the latter is tight to `refresh_rate`
14:41:03 <axet> ok
14:41:11 <TrueBrain> the game will do its at most to get the `graphics frame rate` as close as possible to `refresh_rate`
14:41:12 <axet> i only speak about first one
14:41:24 <TrueBrain> on a dedicated server, that is (nearly) disabled and has no impact on the game
14:41:26 <petern> The first one is totally unrelated to refresh rate.
14:41:31 <TrueBrain> the simulation rate is defined by `_game_speed`
14:41:38 <TrueBrain> a value of 100 is ~37 frames/s
14:41:46 <glx[d]> refresh rate used to be linked to game speed, ending up with 30Hz drawing on 60Hz+ screens
14:41:51 <axet> 33.33
14:41:57 <TrueBrain> no, 37 in nightly
14:42:02 <TrueBrain> but that is not important for the story
14:42:05 <TrueBrain> you want to get that number lower
14:42:09 <TrueBrain> so you want to lower `_game_speed`
14:42:22 <TrueBrain> literally the job of `_game_speed` is the influence the simulation rate
14:42:29 <TrueBrain> fast-forward changes that value to something big
14:42:35 <axet> i don't. can we have game_speed inrelated of silulation rate?
14:42:46 <TrueBrain> why? that makes no sense ..
14:42:54 <axet> a lot of sense.
14:42:55 <TrueBrain> that variable's only job is to manage simulation rate
14:43:03 <TrueBrain> as much as `refresh_rate` is there to do graphics frame rate
14:43:10 <TrueBrain> why .... add another variable doing the same?
14:43:12 <axet> ok forget about refresh_rate.
14:43:53 <petern> Set _game_speed to 50, and the game will run at 50% normal speed, without touching anything else.
14:44:45 <petern> (The GUI representing FFWD might not understand what's going on though :-))
14:44:55 <axet> i guess openttd it hardcoded to become simulation rate == tick. modern games engines has those variables working independent. you can refresh 1 per second but that does not affect game speede
14:45:15 <petern>
14:45:29 <petern>
14:45:33 <TrueBrain> axet: huh?
14:45:36 <glx[d]> simulation is tick based
14:45:46 <glx[d]> that's the only way
14:45:48 <axet> right and wrong
14:45:54 <axet> that is not only way
14:45:59 <axet> you can make it independent
14:46:00 <petern> You are definitely wrong.
14:46:04 <axet> i'm right
14:46:09 <TrueBrain> what would be independent?
14:46:10 <LordAro> cute
14:46:21 <glx[d]> everything must happen in the same order on both server and clients
14:46:26 <axet> right
14:47:02 <TrueBrain> you keep mention things like "refresh once per second" .. refresh what?
14:47:11 <TrueBrain> a game-state is a game-state .. it doesn't require a refresh
14:47:29 <TrueBrain> take Factorio .. you have FPS and UPS ... we have simulation rate and graphics rate ..
14:47:43 <TrueBrain> take Counter Strike .. you have server-tick-speed and client-refresh-rate
14:47:47 <TrueBrain> they are all the same thing
14:48:05 <TrueBrain> so you have to understand we are a bit confused with what you are aiming at
14:48:56 <petern> Also, running OpenTTD WSL has the usual 'can't lock mouse pointer' issue.
14:49:01 <axet> I thinkg this is too late to change. OpenTTD stuck with tick rate. But that is not the only way to go.
14:49:12 <TrueBrain> so name a game that does it differently?
14:49:28 <DorpsGek> [OpenTTD/OpenTTD] rubidium42 merged pull request #10778: Change: use precompiled headers to speed up compilation
14:49:41 <petern> You are confused. Tick rate is not related to screen refresh rate.
14:49:45 <glx[d]> you need to remember everything comes from TTD
14:50:08 <glx[d]> and we did split simulation and drawing
14:50:10 <TrueBrain> no, don't make OpenTTD more special than it is πŸ™‚
14:50:21 <TrueBrain> like game-design 101 starts with: a game-tick
14:50:43 <TrueBrain> sometimes expressed in ms per tick, sometimes expressed in ticks per second
14:50:48 <TrueBrain> very few games are event-based
14:50:52 <TrueBrain> which is the other solution here
14:51:07 <TrueBrain> or actor-based, if you like
14:51:17 <TrueBrain> but even those often run on a ticker πŸ˜›
14:51:20 <axet> TrueBrain all games works that way. isn't? you have not tick, but ms time based!
14:51:22 <TrueBrain> might have to do that your CPU is a ticker πŸ˜„
14:51:40 <glx[d]> it's the same
14:51:55 <TrueBrain> yeah, okay, so you seem to confuse some thermology here πŸ™‚ A tick has a period. Our ticks are 27ms. So we are also ms based! πŸ™‚
14:52:08 <TrueBrain> we just represent it as `_game_speed`, which is a percentage of "normal"
14:52:14 <TrueBrain> that is just a choice
14:52:54 <axet> true. can you predict position of train knowing it's speed? no matter when you refresh game state, it know where it will be
14:53:11 <axet> you can refersh every second. or refresh every 10 ms.
14:53:13 <petern> There is no prediction.
14:53:17 <TrueBrain> we are a deterministic game; not a predictive πŸ™‚
14:53:37 <axet> ok maybe I'm wrong about that.
14:53:45 <axet> i guess i have to digg it out
14:54:07 <TrueBrain> deterministic, also often called lock-stepped
14:54:17 <TrueBrain> so you cannot skip game-frames
14:54:43 <glx[d]> everything is interlocked (main reason we can't use threads to speedup simulation calculation)
14:55:07 <glx[d]> as each decision can affect all other elements
14:55:20 <petern> What you are complaining about is a very real problem in some games -- that simulation rate is intrinsically tied to graphical refresh rate. And that is bad. But that is definitely not the case in OpenTTD.
14:55:30 <axet> right. i'm taking about skipping frames. isn't this possible with different game logic?
14:55:41 <TrueBrain> if you rewrite the whole game, sure πŸ™‚
14:55:45 <axet> ok
14:55:49 <TrueBrain> but within the concept of OpenTTD, no, that is not possible
14:55:50 <axet> that answes it
14:56:51 <TrueBrain> petern: funny, you are correct is it the MD5sum
14:56:58 <TrueBrain> just not that it fails to wrap it, but it does crash there πŸ˜„
14:57:28 <petern> Sometimes I have a vague clue what I'm dealing with πŸ˜‰
14:57:54 <TrueBrain> it tries to draw the MD5sum
14:57:59 <TrueBrain> but it is having another string in the buffer
14:58:04 <TrueBrain> so ... smells fishy πŸ˜›
14:58:12 <petern> Hmm, I guess I need to copy the correct baseset to my WSL install.
14:58:15 <petern> Ooh.
14:58:41 <TrueBrain> ah, no, wait
14:58:44 <glx[d]> just start and it will ask to download opengfx
14:58:46 <TrueBrain> I am just printing the string at the end of the buffer
14:58:56 <TrueBrain> brr, my other PR solves this nicely ..
14:58:57 <petern> glx[d]: I said correct.
14:59:25 <glx[d]> ah you can do that via windows explorer
15:00:04 <petern> Oh I know how, I'm just throwing non-sequiturs around.
15:00:48 <petern> GeorgeVB: were you able to make a test NewGRF for displaying force?
15:01:15 <petern> I have no idea how to write a NewGRF that uses textstack and things...
15:01:16 <andythenorth> sometimes...python black makes unreadable code
15:01:21 <andythenorth> but who am I to question it πŸ˜›
15:04:59 <andythenorth>
15:04:59 <andythenorth> I think "Variants:" makes it look like it's listing the choices you get if you open the nested tree
15:05:17 <andythenorth> "Colours (mixed):" ?
15:05:26 <petern> It wasn't a serious suggestion.
15:05:35 <andythenorth> it was worth trying
15:06:20 <andythenorth> fortunately I will be able to quickly see if my cargo is supported
15:06:21 <andythenorth> at a glance
15:06:23 <andythenorth> for any cargo
15:06:38 <petern> heh
15:06:45 <andythenorth>
15:07:08 <andythenorth> "Refittable to: 48 fine cargos you will recognise, such as Cast Iron, Tyres, and Zinc"
15:08:36 <glx[d]> maybe the ", " text colour could be different than cargo colour
15:08:48 <glx[d]> to not look like a huge orange block
15:08:54 <petern> It's at the point where showing the list is not useful.
15:09:12 <petern> And showing the anti-list is probably not much help either.
15:10:05 <glx[d]> "Refittable to: Please use cargo filter on the top of the window"
15:10:55 <andythenorth> "Refittable to: many things"
15:11:15 <andythenorth> if I just make wagons universal, I will get feature requests
15:11:21 <andythenorth> about fish in hoppers
15:11:25 <andythenorth> and not allowing it
15:12:03 <glx[d]> "Refittable to: what you can expect by the look of the wagon"
15:13:52 <DorpsGek> [OpenTTD/OpenTTD] TrueBrain commented on issue #10790: [Bug]: ICU Layouter crash
15:17:18 <TrueBrain> yeah, the docs clearly state the cluster should point to the character in the buffer ..
15:17:47 <TrueBrain> owh, I see ... I am silly ...
15:17:48 <FLHerne> andythenorth: you can put fish in hoppers, but it decays to zero value in a day :p
15:17:57 <FLHerne> clearly you should model this
15:18:00 <FLHerne> for Realism
15:18:51 <andythenorth> agree
15:20:42 <GeorgeVB> petern: I'll return home in the evening, currently not in town, and will try to make one
15:22:11 <DorpsGek> [OpenTTD/OpenTTD] TrueBrain opened pull request #10791: Fix: [ICU] crash when trying to break a non-breaking run
15:23:24 *** gelignite has joined #openttd
15:23:33 <TrueBrain> wel, that was easier than I expected πŸ™‚
15:24:06 *** gelignite has quit IRC (Read error: Connection reset by peer)
15:24:14 <petern> Yay
15:24:51 <TrueBrain> happy I put those asserts in place πŸ˜„
15:25:48 <TrueBrain> in other news ... today I build myself a mmwave sensor to detect activity in a room .. I also added a BME280 in there for measuring temperature .. I was like: this will be fine! But .. the mmwave operates at ~40 degrees .. this leaks through the wires to the BME .. so its temperature is off by a few degrees πŸ˜›
15:26:00 <TrueBrain> stupid wires
15:26:38 <DorpsGek> [OpenTTD/OpenTTD] rubidium42 updated pull request #10745: Codechange: use more C++ constructs in strgen
15:26:44 <DorpsGek> [OpenTTD/OpenTTD] PeterN approved pull request #10791: Fix: [ICU] crash when trying to break a non-breaking run
15:27:08 <TrueBrain> Rubidium: mind taking another look at ? I think I fixed all you mentioned πŸ™‚
15:27:27 <glx[d]> GeorgeVB: there's a standalone windows nmlc in the nml PR if it helps
15:28:30 <glx[d]> TrueBrain: make it wireless πŸ™‚
15:28:41 <TrueBrain> yeah .. I did ... which required wires .. the irony!
15:29:43 <petern> 40 degrees, I guess that's a few watts being used or so...
15:29:55 <glx[d]> hmm but having something at ~40Β°C in the room will be fun in summer
15:29:56 <TrueBrain> that is the odd thing .. it uses just 80mA on 5V
15:30:13 <TrueBrain> so I didn't actually expect it to get anywhere above 30 ..
15:30:25 <DorpsGek> [OpenTTD/OpenTTD] rubidium42 merged pull request #10780: Cleanup: Remove unnecessary hangar check.
15:31:45 <TrueBrain> it mostly is the mosfet that is the issue
15:31:55 <petern> Measured or per spec?
15:32:08 <TrueBrain> as it is directly connected to the power-wire (duh), which connects to the ESP, which leaks it through to the BME .. meh
15:32:09 <TrueBrain> measured
15:32:11 <TrueBrain> specs lie
15:32:12 <TrueBrain> all the time
15:32:16 <petern> Quite πŸ™‚
15:32:48 <TrueBrain> I have other sensors like that in my home, but I put the ESP to deep-sleep between measurements .. so there is no actual heat build-up
15:32:53 <TrueBrain> which solves that problem completely πŸ˜›
15:34:52 <TrueBrain> guess I just shouldn't combine these two sensors together πŸ˜›
15:35:05 <TrueBrain> or add a heat-sink .. hmmmmmm
15:35:18 <glx[d]> and a fan ?
15:35:27 <TrueBrain> no, they can only get dirty and break down
15:35:38 <TrueBrain> 40 degrees is nowhere near the max operating temp, so no need for active cooling
15:35:53 <petern> Would also cause more heat.
15:36:20 <TrueBrain> as for summer, it is 1W of heat it produces at most .. so yeah, my body does more πŸ˜›
15:36:32 <TrueBrain> (well, 0.4W, but you get the point :D)
15:36:44 <TallTyler> andythenorth: You joke, but maybe a way to solve this is to not provide a full list if there are more than N options refittable or non-refittable, where N is some sane number
15:37:19 <petern> Draw all the tiny cargo icons instead πŸ˜‰
15:37:28 <petern> It'll still be unusable, but take up less space.
15:37:39 <TallTyler> Draw the two-letter cargo acronyms; maybe even worse than icons
15:38:02 <glx[d]> too many cargos, use the filter before looking at wagon
15:38:59 <petern> If we need a list, possibly a custom tooltip that shows 1 cargo per line when hovered over the refittable to line.
15:39:16 <andythenorth> disclosure widget?
15:39:27 <andythenorth> many...[details]
15:39:43 <petern> Yeah
15:40:19 <TallTyler> Scrollbar?
15:40:33 <petern> On a separate window maybe.,
15:40:57 <DorpsGek> [OpenTTD/OpenTTD] rubidium42 approved pull request #10789: Fix: Set up default station/waypoint classes properly.
15:42:07 <DorpsGek> [OpenTTD/OpenTTD] PeterN merged pull request #10789: Fix: Set up default station/waypoint classes properly.
15:42:43 <glx[d]> a button, hidden by default, placed where the list would be if there's too many cargoes
15:44:06 <glx[d]> but might be hard to determine the position
15:44:59 <glx[d]> ah no, it's a single string
15:45:59 <glx[d]> when drawing STR_PURCHASE_INFO_REFITTABLE_TO we should have enough info to position and size the button
15:47:39 <petern> Yeah that's not how our widget system works πŸ™‚
15:47:57 <petern> Unless you mean a fake button. Which is fine but needs manual click detection etc.
15:48:18 <DorpsGek> [OpenTTD/OpenTTD] 2TallTyler commented on pull request #10787: Allow dedicated server to use threaded saves.
15:49:52 <DorpsGek> [OpenTTD/OpenTTD] rubidium42 commented on pull request #10787: Allow dedicated server to use threaded saves.
15:50:43 * Rubidium_ wonders who's going to suggest removing that specific assert is a good thing
15:50:59 <TrueBrain> it solves the issue! πŸ˜›
15:52:26 <petern> Hmm, if this mapping-by-pointer may be unsafe, I should probably disallow mapping by pointer in a all cases?
15:52:57 *** gelignite has joined #openttd
15:53:04 <glx[d]> hmm so joining during autosave on a dedicated server waits for autosave to finish ?
15:53:22 <glx[d]> then save again ?
15:54:00 <petern> If it's not threaded then the server will be unresponsive because it's saving, no?
15:55:06 <petern> How can I make `[statspec](StringID str) { statspec->name = str; }` shorter?
15:55:31 <TrueBrain> I remember long ago someone looked into the same, for autosave, and found out there was an issue when joining under certain conditions
15:55:38 <TrueBrain> basically, we should rewrite most of the server part πŸ˜›
15:55:40 *** HerzogDeXtEr has joined #openttd
15:55:42 <TrueBrain> so many silly and outdated concepts πŸ™‚
15:55:46 <petern> Hmm, actually there's no guarantee that statspec would still be valid there anyway. Bums.
15:56:24 <TrueBrain> did we ever solve that if 4 people want to join, it sends the map one by one?
15:56:28 <TrueBrain> instead of just sending it to all?
15:56:39 <TrueBrain> seems we did not
15:58:31 <glx[d]> yeah probably not solved
16:00:00 <axet> i guess _sl; has to be removed. globals.
16:00:18 <DorpsGek> [OpenTTD/OpenTTD] 2TallTyler opened pull request #10792: Change: Add padding to build vehicle text filter
16:00:59 <petern> SetPadding(2) is enough
16:01:37 <TallTyler> Ah, so it is πŸ™‚
16:01:47 <DorpsGek> [OpenTTD/OpenTTD] PeterN requested changes for pull request #10792: Change: Add padding to build vehicle text filter
16:02:09 <petern> Better place for it πŸ˜‰
16:02:26 <petern> I can take that one out of my branch that fixes those things :p
16:02:52 <TallTyler> I copied that all directly from the sign list
16:02:57 <TallTyler> What does SetFill() actually do?
16:03:12 <petern> Makes it fill available space, x then y.
16:03:46 <petern> But it bubbles up from the child widget.
16:04:35 <DorpsGek> [OpenTTD/OpenTTD] 2TallTyler updated pull request #10792: Change: Add padding to build vehicle text filter
16:04:41 <petern> It wouldn't do much harm there tbh, but it's not needed either.
16:05:08 <DorpsGek> [OpenTTD/OpenTTD] glx22 updated pull request #10785: Change: [Actions] Use -fuse-ld=lld for MinGW
16:05:14 <petern> There's also a bug in that window anyway.
16:05:25 <petern> If you fancy fixing it while you're there?
16:05:37 <TallTyler> Sure, what is it?
16:05:51 <petern> See the WWT_PANEL on line 65?
16:06:01 <petern> That isn't needed at all, it's overdrawn.
16:06:46 <TallTyler> Ah, the NWID_VERTICAL already contains the same elements
16:07:20 <petern> Not the same, they just overdraw it. If there was a WWT_EMPTY, the WWT_PANEL may be needed.
16:08:05 <petern> So we fill a whole panel, draw the bevels and then... draw the actual widgets on top.
16:08:21 <petern> Gob job this stuff is double-buffered.
16:09:27 <petern> <>
16:09:38 <DorpsGek> [OpenTTD/OpenTTD] 2TallTyler updated pull request #10792: Change: Add padding to build vehicle text filter
16:09:48 <petern> I went a bit further as I always do...
16:09:51 <DorpsGek> [OpenTTD/OpenTTD] rubidium42 commented on pull request #10776: Codechange: C++-ify the Layouter and related functions
16:09:54 <DorpsGek> [OpenTTD/OpenTTD] TrueBrain merged pull request #10791: Fix: [ICU] crash when trying to break a non-breaking run
16:09:57 <DorpsGek> [OpenTTD/OpenTTD] TrueBrain closed issue #10790: [Bug]: ICU Layouter crash
16:10:22 <petern> I'm not sure about the industry gui filter change though.
16:10:39 <TallTyler> Are you ditching the `Filter:` prefix entirely, or just in the FIOS GUI?
16:10:39 <petern> Adding the same padding would make the buttons next to it too tall, so I moved the filter onto its own line.
16:10:44 *** gelignite has quit IRC (Read error: Connection reset by peer)
16:10:52 <petern> Just in fios for now.
16:12:03 <TallTyler> Got a screenshot?
16:12:16 <DorpsGek> [OpenTTD/OpenTTD] JGRennison commented on pull request #10787: Allow dedicated server to use threaded saves.
16:12:25 <DorpsGek> [OpenTTD/OpenTTD] 2TallTyler dismissed a review for pull request #10792: Change: Add padding to build vehicle text filter
16:12:30 <petern> Nope, it's not my current branch either
16:12:55 <TallTyler> Not worth the build time then πŸ™‚
16:13:03 <glx[d]> `Filter:` prefix could be replaced with an icon
16:13:33 <glx[d]> and unified in all windows
16:13:46 <petern> That's confusing, the github change view make it look like you've added newlines between each container... but you haven't.
16:14:05 <petern> glx[d]: Yes, I didn't get as far as drawing an icon for it.
16:14:21 <petern> And also, that could be a flag of WWT_EDITBOX, so properly unified.
16:14:27 <glx[d]> andythenorth: we need a filter icon πŸ˜‰
16:14:58 <TallTyler> Just this, right?
16:15:16 <TallTyler> But fewer pixels
16:15:20 <glx[d]> yeah seems quite commonly used
16:15:24 <petern> Just that. GIANT.
16:15:49 <petern> The alternative is a magnifier for search, but filter is more appropriate I think.
16:16:00 <DorpsGek> [OpenTTD/OpenTTD] PeterN approved pull request #10792: Change: Add padding to build vehicle text filter
16:16:48 <DorpsGek> [OpenTTD/OpenTTD] TrueBrain commented on pull request #10776: Codechange: C++-ify the Layouter and related functions
16:21:47 *** Wolf01 has joined #openttd
16:24:35 <DorpsGek> [OpenTTD/OpenTTD] TrueBrain updated pull request #10776: Codechange: C++-ify the Layouter and related functions
16:25:48 *** gelignite has joined #openttd
16:26:04 <DorpsGek> [OpenTTD/OpenTTD] LordAro commented on pull request #10785: Change: [Actions] Use -fuse-ld=lld for MinGW
16:30:58 <m3henry> Is Mold not supported for MinGW?
16:33:20 <glx[d]> I tried, it's not available
16:41:05 <LordAro> curious how mingw x86 is that much faster than x64
16:47:39 <glx[d]> it's like that since precompiled headers
16:48:43 <glx[d]> <-- and mingw seems worse since the merge πŸ™‚
16:52:39 <petern> Hmm, managed to get 188 station classes... probably no need to increase the limit.
16:53:55 <petern> I have, however, got 468 waypoints loaded, which won't work in vanilla.
16:56:53 <DorpsGek> [OpenTTD/OpenTTD] rubidium42 approved pull request #10776: Codechange: C++-ify the Layouter and related functions
17:00:39 <TrueBrain> Tnx Rubidium πŸ™‚ stack pop, up to the next PR πŸ˜„
17:02:35 <DorpsGek> [OpenTTD/OpenTTD] rubidium42 updated pull request #10733: Codechange: use standard int types
17:06:14 <DorpsGek> [OpenTTD/OpenTTD] glx22 updated pull request #10785: Change: [Actions] Use -fuse-ld=lld for MinGW
17:06:44 <DorpsGek> [OpenTTD/OpenTTD] glx22 updated pull request #10785: Change: [Actions] Use -fuse-ld=lld for MinGW
17:14:34 <DorpsGek> [OpenTTD/OpenTTD] PeterN opened pull request #10793: Fix: Support more than 256 stations/waypoints/roadstops per class.
17:17:48 <TrueBrain> Change .. fix .. but sounds like a feature.. well done sir, well done πŸ˜‰
17:18:57 <DorpsGek> [OpenTTD/OpenTTD] glx22 commented on pull request #10793: Fix: Support more than 256 stations/waypoints/roadstops per class.
17:21:12 <DorpsGek> [OpenTTD/OpenTTD] PeterN updated pull request #10793: Fix: Support more than 256 stations/waypoints/roadstops per class.
17:21:33 <DorpsGek> [OpenTTD/OpenTTD] 2TallTyler merged pull request #10792: Change: Add padding to build vehicle text filter
17:21:47 <DorpsGek> [OpenTTD/OpenTTD] TrueBrain merged pull request #10776: Codechange: C++-ify the Layouter and related functions
17:21:51 <petern> Yeah, it was just a change in my branch, but then I decided to split this bit out and make it a proper fix πŸ˜‰
17:27:33 <andythenorth>
17:27:33 <andythenorth> does it matter that the name string doesn't include all the mixed colours?
17:27:38 <andythenorth> I just pick the first two from the list, for brevity
17:28:45 <andythenorth> I could use a name like "rustbelt" for these brown / grey / black combos, but eh, seems overkill
17:28:53 <petern> Are you suggesting that people will read?
17:29:00 <andythenorth> well no
17:29:20 <andythenorth>
17:29:20 <andythenorth> it's moot anyway πŸ˜›
17:30:00 <petern> It's amazing what a resizeable window lets you do.
17:30:42 <petern>
17:30:42 <petern> Android OpenTTD looks so weird.
17:30:55 <DorpsGek> [OpenTTD/OpenTTD] axet updated pull request #10787: Allow dedicated server to use threaded saves.
17:31:30 *** Inanna has joined #openttd
17:31:30 <Inanna> 😻😻
17:31:30 <Inanna>
17:31:30 <Inanna> all all
17:31:34 <DorpsGek> [OpenTTD/OpenTTD] axet commented on pull request #10787: Allow dedicated server to use threaded saves.
17:32:16 <DorpsGek> [OpenTTD/OpenTTD] TrueBrain updated pull request #10772: Codechange: replace C-style strings with C++-style strings in textfile
17:32:46 <TrueBrain> TallTyler: mind fixing the above post? πŸ˜›
17:33:44 <TrueBrain> right, that is better πŸ˜›
17:34:52 <DorpsGek> [OpenTTD/OpenTTD] PeterN commented on pull request #10787: Allow dedicated server to use threaded saves.
17:35:34 <andythenorth>
17:35:34 <andythenorth> I wonder if naming non-random wagons adds anything
17:36:09 <andythenorth> maybe
17:40:30 <TrueBrain> hmm .. that moment you spot a bug, but only the first time you do something .. the second time it works fine ... oh-oh
17:40:54 <petern> After merging?
17:41:02 <TrueBrain> didn't spot it before rebase
17:41:07 <TrueBrain> did the same thing many times πŸ˜›
17:41:36 <TrueBrain> I have my suspicion .... let's check πŸ˜„
17:42:03 <TrueBrain> he shoots and he scores!
17:42:12 <TrueBrain>
17:42:12 <TrueBrain> also:
17:42:17 <TrueBrain> that just looks weird πŸ˜„
17:43:05 <Eddi|zuHause> didn't i propose a readme link parser a few days ago?
17:43:22 <TrueBrain> I guess we should add an extra newline at the end or something?
17:43:25 <petern> By propose do you mean created a PR?
17:43:34 <Eddi|zuHause> no
17:43:42 <TrueBrain> (I am talking about the `reoositorv` instead of `repository`
17:44:53 <petern> I think it's just the last time.
17:44:54 <petern> ...
17:44:55 <petern> Last line.
17:45:00 <TrueBrain> it is
17:45:04 <petern> I guess something isn't taking account of padding πŸ™‚
17:45:11 <petern> I believe that's my department.
17:45:19 <Eddi|zuHause> needs extra spacing for stuff below the writing line?
17:45:35 <petern> Yeah, the tails are visible at the top when they shouldn't be.
17:45:37 <andythenorth> 6587 line python module, too long? πŸ˜›
17:45:45 <Eddi|zuHause> no
17:46:05 <Eddi|zuHause> this question can never be answered by the number of lines alone
17:46:39 <Eddi|zuHause> anyone who tries is probably talkin uninformed and counterproductive nonsense
17:47:00 <andythenorth> it's all one concern
17:49:19 <petern> Eddi|zuHause: No it's just drawn in the wrong place for some reason.
17:50:08 <Eddi|zuHause> toroidal wrapping!
17:51:13 <DorpsGek> [OpenTTD/OpenTTD] TrueBrain updated pull request #10772: Codechange: replace C-style strings with C++-style strings in textfile
17:56:00 <andythenorth>
17:56:00 <andythenorth> ach I'm going to call it Rustbelt
17:56:02 <andythenorth> or Granite πŸ˜›
17:56:07 <andythenorth> people can complain
17:56:23 <petern> Hmm, maybe it's an OpenGFX bug.
17:56:49 <petern> Heh, same without
17:57:23 <andythenorth> GPT suggests "Schist" or "Shale" as alternatives to "Rustbelt" πŸ˜›
17:57:29 <andythenorth> Schist seems easily misread
17:58:30 <petern> Yeah, it's a bug in the monospace font.
17:59:08 <petern> It's been designed with the baseline at 10 pixels from the top.
17:59:22 <petern> And the game is coded that the monospace font is 10 pixels high.
17:59:33 <DorpsGek> [OpenTTD/OpenTTD] rubidium42 approved pull request #10793: Fix: Support more than 256 stations/waypoints/roadstops per class.
17:59:33 <petern> So we could just change that height.
18:02:55 <petern> Hmm, problem is that makes the default size for truetype monospace too big.
18:05:45 <andythenorth>
18:05:45 <andythenorth> ok any synonyms for "Mixed"?
18:06:04 <andythenorth> the mix is "all the possible variant colours"
18:06:22 <andythenorth> I tried "Max Mix" because it might be visually pleasing letter shapes
18:06:24 <andythenorth> but it's weird
18:07:49 <andythenorth> "Assorted"?
18:08:04 <andythenorth> I tried "Full Send" but it's too YouTube
18:08:44 <andythenorth> GPT suggests "Super Shuffle" and "Turbo Jumble"
18:09:21 <Eddi|zuHause> that sounds all horrible
18:09:37 <DorpsGek> [OpenTTD/OpenTTD] PeterN merged pull request #10793: Fix: Support more than 256 stations/waypoints/roadstops per class.
18:12:14 <andythenorth> think it needs a qualifier
18:12:20 <andythenorth> it's most mixed of the available sets
18:13:10 <andythenorth> at some point, someone will add more columns to the buy menu, and render all this un-needed πŸ˜›
18:13:33 <andythenorth> if we have extensible columns, it will be excel-like dream that part of the playerbase dreams of
18:13:41 <andythenorth> maximum optimisation of each vehicle purchase
18:17:04 <petern> I guess I need grfcodec to fix this :p
18:18:24 <petern> [cmake] -- Found Grfcodec: /usr/bin/grfcodec
18:20:48 <petern> Ah, I remember x and y being reversed for one of the nfo columns, but seems that was fixed in an update.
18:22:22 <andythenorth> "Mixed" assortment, mixture, variety, array, mix, miscellany, random selection
18:22:37 <andythenorth> mishmash, hotchpotch, hodgepodge, ragbag, pot-pourri, jumble, mess, confusion, conglomeration, farrago, patchwork, hash
18:22:43 *** Gazmeister has joined #openttd
18:22:43 <Gazmeister> Variety sounds alright.
18:23:06 <Gazmeister> reminds me of the variety packs...
18:23:41 <andythenorth>
18:23:42 *** Wormnest has joined #openttd
18:30:02 <Citizen_Kane_23> I love it that Andy has put transformed Iron horse into a model set
18:32:00 <petern> This font is weird.
18:32:23 <petern> The upper-case characters are 7 pixels tall, the lower-case characters (without descenders) is 8 pixels tall.
18:37:52 <andythenorth>
18:37:52 <andythenorth> Citizen_Kane_23: intent was always this πŸ˜›
18:40:01 <DorpsGek> [OpenTTD/OpenTTD] PeterN opened pull request #10794: Fix: Incorrect y-position of monospace glyphs.
18:42:52 <DorpsGek> [OpenTTD/OpenTTD] TrueBrain approved pull request #10794: Fix: Incorrect y-position of monospace glyphs.
18:43:23 <TrueBrain> oh-oh, my Windows regressions timed out ...
18:43:25 <TrueBrain> oh-oh ...
18:43:58 <petern> Better try debugging πŸ˜‰
18:44:01 <TrueBrain> with a change that has no doing with the regression .. or so it seems
18:44:19 <andythenorth> pff ` nmlc ERROR: "generated/iron-horse.nml", line 279986: Unable to allocate ID for string, no more free IDs available (maximum is 1024)`
18:44:26 <andythenorth> every day, a new limit breached πŸ˜›
18:44:48 <petern> Only 1024 strings per NewGRF? Didn't that get increase recently, or is that the new limit...
18:45:06 <TrueBrain> `x64-Debug\cl : Command line warning D9025: overriding '/MTd' with '/MDd'`
18:45:09 <andythenorth> not sure πŸ™‚
18:45:10 <TrueBrain> like .. okay MSVC .. sure?
18:45:11 <andythenorth> `nmlc info: D0xx strings: 716/1024`
18:45:17 <andythenorth> was the previous version that compiled
18:45:23 <andythenorth> I've only added one parameter but eh
18:45:33 <andythenorth> limit goes sailing by πŸ˜›
18:46:07 <petern> Ah, general text is 0xD800 to 0x10000
18:46:22 <TrueBrain> `cannot dereference end string_view iterator`
18:46:25 <TrueBrain> okay ...
18:46:27 <petern> callback text is 0xD000 to 0xD800, but actually limited to 0x400 within that.
18:46:30 <petern> Stupid limits.
18:47:16 <TrueBrain> hmm .. what is the difference between `cbegin` and `begin`?
18:47:28 <TrueBrain> const
18:47:35 <TrueBrain> why can't do do const_begin?
18:47:51 <Eddi|zuHause> it's more letters!
18:47:55 <andythenorth> goes it throw out sprite limit?
18:48:08 <andythenorth> limitation disturbs me greatly
18:48:19 <TrueBrain> we know
18:49:57 <andythenorth> not understanding how composed strings are treated with respect to the limit πŸ˜›
18:50:00 <andythenorth> bit magical to me
18:51:26 <andythenorth> does each composition consume a string ID?
18:51:38 <andythenorth> and if so, is the text stack going to be the best bet?
18:52:33 <petern> New NewGRF version, remove all that gumpf with fitting string IDs into TTDPatch.
18:53:16 <petern> (Which is why the restrictions exist)
18:53:31 <michi_cc[d]> petern: Nobody wrote the NML support yet.
18:54:13 <michi_cc[d]> And if course if you need the larger string range in a callback result, you have to bounce it via a `{STRING}` and the text stack.
18:55:29 <andythenorth> STR_EMPTY not doing much there πŸ˜›
19:00:49 <andythenorth> I don't know how to extend NML for more strings πŸ™‚
19:01:11 <andythenorth> but the alternative is rewriting a lot of compound string handling to use the text stack
19:01:18 <andythenorth> which I might need to anyway, but eh
19:02:06 <DorpsGek> [OpenTTD/OpenTTD] TrueBrain updated pull request #10772: Codechange: replace C-style strings with C++-style strings in textfile
19:02:22 <TrueBrain> MSVC had a right to complaint .. it found 2 nasty bugs that clang did not notice .. funny πŸ™‚
19:02:30 <TrueBrain> MSVCs `std::string_view` is a lot more robust
19:02:45 *** WormnestAndroid has quit IRC (Remote host closed the connection)
19:02:45 *** WormnestAndroid has joined #openttd
19:06:48 <DorpsGek> [OpenTTD/OpenTTD] LordAro commented on pull request #10772: Codechange: replace C-style strings with C++-style strings in textfile
19:08:22 <DorpsGek> [OpenTTD/OpenTTD] TrueBrain commented on pull request #10772: Codechange: replace C-style strings with C++-style strings in textfile
19:09:39 <petern> When you have 468 waypoints, the filter is useful πŸ™‚
19:14:40 <DorpsGek> [OpenTTD/OpenTTD] nielsmh commented on pull request #10772: Codechange: replace C-style strings with C++-style strings in textfile
19:15:07 <DorpsGek> [OpenTTD/OpenTTD] PeterN updated pull request #10786: Feature: Add search filter and name text to build waypoint window.
19:17:32 <andythenorth> yeah ok so splitting vehicle name strings to handle different contexts ..... uses string IDs fast
19:17:35 <andythenorth> 700 vehicles
19:17:42 <andythenorth> or so
19:22:15 <glx[d]> TrueBrain: only issue is it opens a window and cause regression to timeout
19:22:42 <glx[d]> I though we disabled the window a long time ago
19:23:01 <TrueBrain> It is okay .. it was easy to debug and fix
19:23:30 <glx[d]> oh maybe since cmake ```#if defined(_MSC_VER)
19:23:30 <glx[d]> /* Don't show abort message as we will get the crashlog window anyway. */
19:23:30 <glx[d]> _set_abort_behavior(0, _WRITE_ABORT_MSG);
19:23:30 <glx[d]> #endif
19:23:30 <glx[d]> ``` has no effect on the CI
19:24:49 <glx[d]> hmm but it's using cl so the define should be there
19:26:45 <andythenorth> ok so I can't use the text stack for an action 0 property string, yes?
19:26:45 *** WormnestAndroid has quit IRC (Read error: Connection reset by peer)
19:26:58 <andythenorth> no varact2 chain...
19:27:12 <Eddi|zuHause> no
19:27:26 *** WormnestAndroid has joined #openttd
19:27:42 <Eddi|zuHause> but you can compose the string with the builtin NML system, and vary it by action6
19:29:13 <petern> Hmm, maybe I won't use GUIList for this anyway.
19:29:57 <andythenorth> Eddi|zuHause: nope
19:30:00 <andythenorth> ran out of strings
19:30:17 <andythenorth> the string limit is quite a hard limit on the number of vehicles
19:30:42 <andythenorth> 65k vehicle IDs, but far fewer strings available
19:34:14 <petern> Hmm, the station availability callback could make a station available only on Tuesdays, right?
19:34:22 <petern> (available for building)
19:35:33 <DorpsGek> [OpenTTD/OpenTTD] George-VB commented on pull request #10782: Add: NewGRF string code "9A 21" to display force from textstack.
19:36:03 *** gelignite has quit IRC (Quit: Stay safe!)
19:36:33 <GeorgeVB> glx22viaGitHub:
19:36:57 <petern> I'm just building #10782 locally to test it, thank you πŸ™‚
19:37:45 <GeorgeVB> petern: Hope new nmlc provides correct grf for {FORCE}
19:38:02 <andythenorth> if we can increase the string limit, can xUSSR be un-split?
19:39:04 <GeorgeVB> andythenorth: Technically yes.
19:39:04 <GeorgeVB> Do you see the profit for being it a single file?
19:39:21 <andythenorth> I have no opinion πŸ™‚
19:39:57 <glx[d]> if it accepted {FORCE} in the string it should be fine
19:40:28 <GeorgeVB> Yes, it did
19:40:37 <petern> 73% built πŸ˜‰
19:40:57 *** virtualrandomnumber has joined #openttd
19:41:32 *** virtualrandomnumber has quit IRC ()
19:42:56 <andythenorth> ok so what's needed for NML string limit? πŸ˜›
19:46:33 <DorpsGek> [OpenTTD/OpenTTD] PeterN commented on pull request #10782: Add: NewGRF string code "9A 21" to display force from textstack.
19:47:26 <glx[d]> seems fine
19:47:57 <petern> How do I use that? It's a wagon, but has Power & Max. TE...
19:48:16 <petern> Head Car. Duh.
19:48:41 <petern> Works fine, but the units are not what George is expecting πŸ™‚
19:48:57 <glx[d]> well it's using user preferred unit
19:49:01 <glx[d]> as it should
19:49:22 <petern> No, it says 12,000kN, but the actual built vehicle (3 parts) is 117kN
19:50:54 <petern> Probably entered the value in kgf values rather than kN.
19:51:16 <glx[d]> value must be the same as property
19:51:42 <petern> Well, the property is a coefficient, and calculated based on power & weight.
19:52:03 *** Flygon has joined #openttd
19:52:06 <petern> But yes, it probably needs documenting what the base units should be πŸ™‚
19:52:24 <petern> (Alternatively, the patch isn't working...)
19:53:14 <petern> static const Units _units_power[] = {
19:53:14 <petern> { { 1, 0}, STR_UNITS_POWER_IMPERIAL, 0 },
19:53:14 <petern> { {4153, 12}, STR_UNITS_POWER_METRIC, 0 },
19:53:14 <petern> { {6109, 13}, STR_UNITS_POWER_SI, 0 },
19:53:14 <petern> };
19:53:15 <petern> Hmmmmm
19:54:03 <glx[d]> unit in newgrf world is lbf it seems
19:54:21 <petern> Where?
19:55:06 <glx[d]> ah no it's hp
19:55:20 <petern> Force isn't in hp πŸ™‚
19:55:24 <andythenorth> pff, text stack time then πŸ™‚
20:00:17 <petern> SetDParam(3, gcache->cached_max_te / 1000);
20:00:19 <petern> Hmm
20:00:54 <GeorgeVB> Value in callback
20:00:54 <GeorgeVB> round((256 * (117.6) / (58.2)) * 10 / 98)
20:00:54 <GeorgeVB> Value in text stack
20:00:54 <GeorgeVB> round(117.6 * 10000 / 98)
20:01:33 <GeorgeVB> What should I use in text stack?
20:01:35 <petern> What are the sums you are doing? (And why/)
20:01:39 <glx[d]> ```static const Units _units_force[] = {
20:01:39 <glx[d]> { {3597, 4}, STR_UNITS_FORCE_IMPERIAL, 0 },
20:01:39 <glx[d]> { {3263, 5}, STR_UNITS_FORCE_METRIC, 0 },
20:01:39 <glx[d]> { { 1, 0}, STR_UNITS_FORCE_SI, 0 },
20:01:39 <glx[d]> };
20:02:21 <petern> Oh I was looking at power, oops πŸ™‚
20:02:46 <petern> Okay, force needs to be in kN.
20:03:03 <petern> The game internally calculates in N which is why it does /1000.
20:03:12 <GeorgeVB> how should it differ from the value in CB?
20:03:15 <petern> But this is a direct value, so should just be kN.
20:04:53 <petern> The callback returns a coefficient based on the engine's weight.
20:05:21 <GeorgeVB> so I need to multiply CB by weight?
20:06:34 <Eddi|zuHause> the TE property is effectively the friction coefficient
20:06:52 <petern> You either provide max TE directly in kN, or calculate it yourself using the same values you've set elsewhere.
20:07:03 <petern> But I don't see any advantage to doing that.
20:07:28 <glx[d]> callback is (TEreal / (Mass * g) * 255
20:08:13 <petern> You can plug numbers in to do it, but the numbers would be the same all the time for each engine.
20:08:18 <GeorgeVB> So I need to return 117.6?
20:08:31 <petern> It's rounded to nearest 1000s for whatever reason.
20:08:39 <petern> Hmm, actually
20:09:06 <petern> Perhaps returning "117600" would be more convenient.
20:09:08 <glx[d]> weight is in ton
20:09:28 <glx[d]> so there's a factor 1000 somewhere
20:09:54 <GeorgeVB> ED2T is 58.2 tons and has TE 117.6 kN
20:10:14 <petern> We never show decimals πŸ™‚
20:10:15 <glx[d]>
20:10:45 <petern> glx[d]: what i mean is we divide it by 1000 normally, and then the unit conversion displays it directly.
20:11:03 <petern> I wonder why we don't just pass it as it, and then let the unit conversion do the division.
20:11:10 *** HerzogDeXtEr has quit IRC (Read error: Connection reset by peer)
20:11:15 <petern> (And yes, I've been wondering about replacing all that bit-shifting nonsense with division)
20:12:42 <glx[d]> because acceleration calculation doesn't work with kN/t ?
20:13:34 <petern> I think you have the wrong end of the stick.
20:13:43 <petern> I'm only talking about the display side.
20:14:00 <petern> We convert from N to kN in the SetDParam()
20:14:27 <petern> Then the unit conversion converts from kN to lbf or kgf
20:14:50 <petern> I wonder why we don't pass it as N, and then let the unit conversion convert to kN, lbf or kgf.
20:18:59 <petern> It never mattered until now πŸ™‚
20:19:08 <DorpsGek> [OpenTTD/OpenTTD] George-VB commented on pull request #10782: Add: NewGRF string code "9A 21" to display force from textstack.
20:19:31 <petern> kN will work fine, but we might get more fine-grained values if we do all the conversion in the units side.
20:20:09 <petern> Given 117kN is 26,303 lbf.
20:20:31 <glx[d]> so {FORCE} expects kN, and internally openttd uses N
20:22:14 <petern> Yes... SetDParam(3, gcache->cached_max_te / 1000);
20:22:19 <glx[d]> would indeed makes sense to pass N and let conversion handle the kN step
20:22:52 <glx[d]> allowing decimal values maybe
20:24:56 <glx[d]> so 117600N doesn't become 117kN
20:25:42 <DorpsGek> [OpenTTD/OpenTTD] George-VB commented on pull request #10782: Add: NewGRF string code "9A 21" to display force from textstack.
20:29:40 <GeorgeVB> glx22viaGitHub: And when would it go to main?
20:35:17 *** axet has quit IRC (Quit: Leaving.)
20:38:03 <petern> When we decide how to do the units πŸ™‚
20:38:31 <petern> Hmm, value * multipler / divisor, or... just go value * multiplier where muliplier is a float...
20:39:08 <Eddi|zuHause> if we have a float multiplier, we need a precision limit
20:40:46 <glx[d]> if it's only used for display then using float should be fine
20:50:02 <petern> Uh
20:50:27 <Eddi|zuHause> yes, but for display you need to define the number of digits to display
20:51:09 <petern> Hmm, I see,, our imperial tons are US tons, not UK imperial tons...
20:51:29 <petern> 2240lb vs 2000lb
20:53:56 *** Wolf01 has quit IRC (Quit: Once again the world is quick to bury me.)
20:59:34 *** keikoz has quit IRC (Ping timeout: 480 seconds)
21:01:15 <andythenorth> oof not writing text stack for vehicle names tonight πŸ˜›
21:01:30 <andythenorth> there a 4 separate python methods to refactor for that πŸ˜›
21:09:06 <michi_cc[d]> So, philosophy question (seeing that it seems to be refactor everything time):
21:09:06 <michi_cc[d]> We have a `Vehicle` class and sub-classes that override some functions for specific vehicle types. Other vehicle-type specific functions are not OOP at all and handled by if/case.
21:10:09 <michi_cc[d]> If we assume now that there is a `Consist` class that has all the front vehicle stuff in it (like e.g. orders), would a similar class/sub-class structure like for vehicles be preferred over a few strategic if/switchs?
21:10:38 <andythenorth> you've been reading in Horse? πŸ˜›
21:15:57 *** nielsm has quit IRC (Ping timeout: 480 seconds)
21:22:48 <petern> Does it make shunting easier? πŸ˜‰
21:25:49 <andythenorth> when is shunting?
21:25:56 <andythenorth> v14?
21:26:40 <petern> Probably some old buggy patch from 10 years ago.
21:28:14 <andythenorth> svn
21:29:33 <petern> Well this is another rabbit hole...
21:37:27 <petern>
21:37:33 <petern> Not sure that gains much, but still :p
21:38:02 <andythenorth> what did we do now?
21:38:08 <andythenorth> decimal TE?
21:38:18 <petern> `@param round Whether to round the value or not.`
21:39:14 <andythenorth> why is everything just string handling now
21:39:15 <petern> Does that mean whether to round up/down instead of just floor? And why would it matter?
21:39:23 <andythenorth> it's been 2 weeks of string faff for me πŸ˜›
21:39:27 <andythenorth> no good pixels at all
21:39:48 <petern> Hmm, 79 vs 80 in display, I suppose.
21:39:54 <petern> Or vice versa...
21:40:35 <Eddi|zuHause> for display i'd always do proper rounding
21:41:26 <andythenorth>
21:41:26 <andythenorth> oops group liveries πŸ˜„
21:41:34 <andythenorth> it's not Red/Pink when built πŸ˜›
21:41:45 <petern> This is for display, It's explicitly here for a reason, and I suspects it's for "NewGRF spec doesn't allow speed to show as exactly X"
21:41:54 <petern> (59 -> 61) rings a bell
21:42:29 <Eddi|zuHause> we've tweaked the speed display a few times
21:44:27 <petern> andythenorth: random shades 1
21:44:52 <andythenorth> just name it "Simon" or something
21:45:06 <andythenorth> I am leaving it as company colour names πŸ˜›
21:45:12 <andythenorth> player can learn to cope
21:46:09 <petern> Shows as "117.7 kN" now. Hmm.
21:52:34 <andythenorth> such sleep
22:02:43 *** tokai|noir has joined #openttd
22:02:43 *** ChanServ sets mode: +v tokai|noir
22:09:49 *** tokai has quit IRC (Ping timeout: 480 seconds)
22:11:45 <petern> Well.
22:22:38 <DorpsGek> [OpenTTD/OpenTTD] PeterN opened pull request #10795: Change: Replace multiply/shift with single factor for units conversion.
22:24:43 <petern> πŸ€·β€β™€οΈ
22:29:11 <petern> Oops
22:29:12 <petern> Hmm
22:30:20 <glx[d]> michi_cc[d]: I found a branch from october 2021
22:33:23 <DorpsGek> [OpenTTD/OpenTTD] PeterN updated pull request #10795: Change: Replace multiply/shift with single factor for units conversion.
22:36:19 <michi_cc[d]> glx[d]: Yeah, that is the not very OOP part πŸ™‚ I was more thinking about things like e.g. the `CheckIfXXXNeedsService` functions, that are very similar but not identical for the vehicle types. If that should be part of a "consist", it either needs to do a switch on the type or mirror the `Vehicle`/`SpecializedVehicle` chain. The code in general seems to be unsure if inheritance is good or not.
22:37:01 <petern> Are you asking because you want to avoid OOP or want to move to OOP?
22:37:25 <glx[d]> codebase comes from C
22:37:51 <glx[d]> but inheritance is not an issue, we use it in some places
22:38:29 <michi_cc[d]> I haven't made up my mind yet. I'm just wondering if other people like the `Vehicle/SpecializedVehicle/GroundVehicle/etc` structure (including the curiously recurring template pattern) or not.
22:39:10 <DorpsGek> [OpenTTD/OpenTTD] PeterN commented on pull request #10794: Fix: Incorrect y-position of monospace glyphs.
22:39:35 <petern> I would rather see plain inheritance rather than templates everywhere tbh.
22:41:37 <glx[d]> SpecializedXXX templates are used for stations too
22:42:30 <petern> Also I'm curious about the value of our *GUIList stuff, seeing as it is basically a wrapper around std::vector now. There appears to be some kind of sorting/filtering extras going on with it, but they're not always used the same way.