IRC logs for #openttd on OFTC at 2023-05-08
⏴ go to previous day
00:05:53 <Eddi|zuHause> are they reacting on tile reservations?
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)
02:26:02 *** Wormnest has quit IRC (Quit: Leaving)
03:05:15 *** debdog has quit IRC (Ping timeout: 480 seconds)
03:26:36 *** D-HUND is now known as debdog
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:18:10 <petern> There is a good reason they are called "Bogo" MIPS.
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: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:27:27 <petern> Yes. That is definitely far too big to run on an early Raspberry Pi.
07:27:57 <petern> And multithreaded saves won't particularly help because it's single core.
07:28:28 <axet> BTW liking openttd on rpi1 took 5 hours and I killed it
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: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: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: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: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:44:07 <axet> I guess my suggestion to have threaded saves on dedicated servers.
07:45:24 <axet> Raspberry Pi Model B Plus Rev 1.2
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: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: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:23 <axet> if you are using linux ofc
07:53:11 <petern> It'll be around 600/1300 🙂
07:53:24 <pickpacket> and what does that mean? :D
07:54:41 <axet> 600compressing MIPS and 1300 decompressing MIPS
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: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
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: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: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: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:25:21 <petern> Hmm, have I broken this bit
08:28:12 <andythenorth> yo, do we have {BLINK}?
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: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: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: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: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: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:45 <LordAro> TrueBrain: the site structure as a whole
08:56:04 <TrueBrain> ah, yes, the illusive promise of andy to fix that 😛 😄
08:56:25 <andythenorth> what was I fixing?
08:56:35 <andythenorth> too busy making things {BLINK}
08:56:45 <TrueBrain> HTML .. CSS .. you know, the usual 🙂
08:57:06 <andythenorth> don't we have any junior contributors?
08:57:35 <andythenorth> we can probably just GPT it?
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: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: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: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: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: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: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:43:51 <andythenorth> list(foo.keys).index('bar')
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:57:47 <andythenorth> switch_get_colour_name(101)
09:57:47 <andythenorth> | (switch_get_colour_name(16) << 16),
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> 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:07:14 <andythenorth> switch_get_colour_name(1) & 0xFFFF
10:07:14 <andythenorth> | ((switch_get_colour_name(16) & 0xFFFF) << 16),
10:12:58 <andythenorth> no idea what range these strings are in 😛
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: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:47 <andythenorth> I thought all procedure results were 15 bit?
10:22:27 <andythenorth> there's a var I can get the 32 bit result from I believe
10:23:09 <andythenorth> syntax for using that inside a STORE_TEMP though 😦
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:28 <andythenorth> where am I adding `|0x8000`
10:26:40 <Eddi|zuHause> where you added the &0xFFFF
10:29:05 <petern> Are you trying to use colour names?
10:30:54 <andythenorth> unfortunately I also have custom names 😦
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: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: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: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: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: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> 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: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: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: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: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:38 <andythenorth> so maybe string() isn't a valid return?
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:30 * andythenorth finds correct vehicle
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:49 <Eddi|zuHause> try 0xD000 or 0xD800
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:44 <andythenorth> let's see if I can get company colour now
11:32:42 <JGR> What sort of colour is nightshade?
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> 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> but it's probably close enough
11:38:06 <Eddi|zuHause> there are probably experts in colour names out there
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: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:55:33 *** WormnestAndroid has quit IRC (Read error: Connection reset by peer)
11:57:08 *** WormnestAndroid has joined #openttd
12:05:45 <TallTyler> Breakfast, actually
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: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: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:58 <LordAro> axet: git blame may help
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: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: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: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: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:39 <petern> The template has sections to keep at least.
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: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: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:27:09 <TrueBrain> petern: managed to crash ICU? Nice 😄
14:27:37 <petern> No, just the new layouter. Sorry.
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: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: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: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:41 <axet> ok. lets call it dedicated_refresh_rate
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:38 <axet> refresh rate == game speed
14:36:48 <TrueBrain> you refresh a screen; you don't refresh a game 😛
14:36:56 <petern> refresh_rate is the screen refresh.
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: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: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: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: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: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: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:36 <glx[d]> simulation is tick based
14:45:59 <axet> you can make it independent
14:46:00 <petern> You are definitely wrong.
14:46:09 <TrueBrain> what would be independent?
14:46:21 <glx[d]> everything must happen in the same order on both server and clients
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: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: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:49 <TrueBrain> but within the concept of OpenTTD, no, that is not possible
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: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> 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: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: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:20:42 <GeorgeVB> petern: I'll return home in the evening, currently not in town, and will try to make one
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: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: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:31:45 <TrueBrain> it mostly is the mosfet that is the issue
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: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: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:40:33 <petern> On a separate window maybe.,
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: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: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:58:31 <glx[d]> yeah probably not solved
16:00:00 <axet> i guess _sl; has to be removed. globals.
16:00:59 <petern> SetPadding(2) is enough
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:41 <petern> It wouldn't do much harm there tbh, but it's not needed either.
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: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:48 <petern> I went a bit further as I always do...
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: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:15:20 <glx[d]> yeah seems quite commonly used
16:15:49 <petern> The alternative is a magnifier for search, but filter is more appropriate I think.
16:25:48 *** gelignite has joined #openttd
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: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.
17:00:39 <TrueBrain> Tnx Rubidium 🙂 stack pop, up to the next PR 😄
17:17:48 <TrueBrain> Change .. fix .. but sounds like a feature.. well done sir, well done 😉
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> 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:20 <andythenorth> it's moot anyway 😛
17:30:00 <petern> It's amazing what a resizeable window lets you do.
17:30:42 <petern> Android OpenTTD looks so weird.
17:32:46 <TrueBrain> TallTyler: mind fixing the above post? 😛
17:33:44 <TrueBrain> right, that is better 😛
17:35:34 <andythenorth> I wonder if naming non-random wagons adds anything
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: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: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:42 <TrueBrain> (I am talking about the `reoositorv` instead of `repository`
17:44:53 <petern> I think it's just the last time.
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: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:56:00 <andythenorth> ach I'm going to call it Rustbelt
17:56:07 <andythenorth> people can complain
17:56:23 <petern> Hmm, maybe it's an OpenGFX bug.
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 <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> 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: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: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: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:23 <petern> The upper-case characters are 7 pixels tall, the lower-case characters (without descenders) is 8 pixels tall.
18:37:52 <andythenorth> Citizen_Kane_23: intent was always this 😛
18:43:23 <TrueBrain> oh-oh, my Windows regressions timed out ...
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: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:27 <petern> callback text is 0xD000 to 0xD800, but actually limited to 0x400 within that.
18:47:16 <TrueBrain> hmm .. what is the difference between `cbegin` and `begin`?
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: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:23 <andythenorth> `string(STR_NAME_CONSIST_COMPOUND_THREE, string(STR_NAME_SUFFIX_CRYO_TANK_CAR), string(STR_PARENTHESES, string(STR_NAME_SUFFIX_MEDIUM)), string(STR_EMPTY))`
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: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:09:39 <petern> When you have 468 waypoints, the filter is useful 🙂
19:17:32 <andythenorth> yeah ok so splitting vehicle name strings to handle different contexts ..... uses string IDs fast
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]> ``` 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: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:36:03 *** gelignite has quit IRC (Quit: Stay safe!)
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: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:47:57 <petern> How do I use that? It's a wagon, but has Power & Max. TE...
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: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: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:54:03 <glx[d]> unit in newgrf world is lbf it seems
19:55:24 <andythenorth> pff, text stack time then 🙂
20:00:17 <petern> SetDParam(3, gcache->cached_max_te / 1000);
20:00:54 <GeorgeVB> round((256 * (117.6) / (58.2)) * 10 / 98)
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: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:09:06 <petern> Perhaps returning "117600" would be more convenient.
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: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: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: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: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: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 train.py 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:26:40 <petern> Probably some old buggy patch from 10 years ago.
21:29:33 <petern> Well this is another rabbit hole...
21:37:33 <petern> Not sure that gains much, but still :p
21:38:02 <andythenorth> what did we do now?
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:40:35 <Eddi|zuHause> for display i'd always do proper rounding
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.
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: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: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: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.
continue to next day ⏵
