IRC logs for #openttd on OFTC at 2023-04-15
00:02:03 <DorpsGek> [OpenTTD/OpenTTD] ldpl commented on pull request #10596: Change: Increase max cargo age and let min cargo payment approach zero.
00:15:23 *** HerzogDeXtEr has quit IRC (Read error: Connection reset by peer)
00:37:14 <DorpsGek> [OpenTTD/OpenTTD] glx22 commented on pull request #10613: Codechange: Refactor timetable GUI
00:45:06 *** Wormnest_ has joined #openttd
00:45:20 *** Wormnest has quit IRC (Read error: Connection reset by peer)
01:19:15 <DorpsGek> [OpenTTD/OpenTTD] TheMowgliMan opened issue #10656: [Bug]: (Not really a bug) Playstyle incompatibility with #10596
01:34:41 *** Wormnest_ has quit IRC (Quit: Leaving)
02:00:30 <DorpsGek> [OpenTTD/OpenTTD] Andrew350 commented on pull request #10606: Feature: Setting to scale cargo production of towns and industries
02:47:36 *** D-HUND has joined #openttd
02:50:54 *** debdog has quit IRC (Ping timeout: 480 seconds)
03:11:55 <DorpsGek> [OpenTTD/OpenTTD] Andrew350 commented on issue #10656: [Bug]: (Not really a bug) Playstyle incompatibility with #10596
03:47:18 *** keikoz has joined #openttd
06:04:04 <FIREDR4GON> yes I was able to get it compiled, but it gets hanged sometimes, like in the attached running exe when i try to modify the inflation setting before starting a new game, so i am trying to work around it. I am working on the issue number ( Maximum initial loan amount does not match Game Settings #8932 )
06:04:34 <FIREDR4GON> TrueBrain
06:18:36 <Eddi|zuHause> maximum loan amount scales with inflation
06:19:08 <Eddi|zuHause> and since the inflation is no longer fixed at 0 at game start, it will be different depending on start year
06:28:04 <DorpsGek> [OpenTTD/OpenTTD] Eddi-z commented on issue #8932: Maximum initial loan amount does not match Game Settings
06:31:07 <DorpsGek> [OpenTTD/OpenTTD] ShlokJswl commented on issue #8932: Maximum initial loan amount does not match Game Settings
06:44:36 <FIREDR4GON> Hi general query, does it make sense to work on fixing this issue or is it like it will most likely not be resolved?
06:56:16 *** nielsm has joined #openttd
07:07:05 <LordAro> it's still something that needs fixing
07:07:26 <LordAro> judt imoortant thst you understand the context of the issue and the angle that may be required for fixing it
07:07:58 <LordAro> just important that* stupid phone keyboard
07:10:30 *** HerzogDeXtEr has joined #openttd
07:15:17 <FIREDR4GON> Do you have any thoughts regarding how to proceed for fixing this? currently I have been revolving around the RecomputePrices() function in economy.cpp
07:25:10 <Rubidium_> I wonder if explaining what happens in the help text is enough, as I doubt messing with the economy is going to end well on the other end
07:25:43 <LordAro> personally i would turn the setting into a percentage, i.e. 200% of starting money etc
07:36:43 <petern> Well I overslept... Bit late for the ride that left over an hour ago...
08:08:37 <Eddi|zuHause> you're the opposite of me then... i haven't slept all night, yet i'm weirdly awake
08:08:46 <Eddi|zuHause> i even managed to go shopping for food
08:10:10 <petern> I am still tired and struggling to move around, weird.
08:14:00 <Eddi|zuHause> that's the usual me...
08:19:46 <LordAro> petern: oops
08:20:05 <LordAro> petern: early start though?
08:20:21 <petern> Normal stuff for us
08:20:42 <LordAro> fair
08:21:06 <petern> Although I did then also miss the later 9am start. Hmm
08:21:14 <petern> I think I'm just not in the mood today as well.
08:25:00 <LordAro> :(
08:25:06 <DorpsGek> [OpenTTD/OpenTTD] LordAro updated pull request #10626: Codechange: Remove alloca usages
08:25:27 *** sla_ro|master has joined #openttd
08:26:25 <DorpsGek> [OpenTTD/OpenTTD] LordAro commented on pull request #10623: Remove: Settings for NPF & YAPF
08:27:24 <DorpsGek> [OpenTTD/OpenTTD] LordAro dismissed a review for pull request #10623: Remove: Settings for NPF & YAPF
08:27:27 <DorpsGek> [OpenTTD/OpenTTD] LordAro updated pull request #10623: Remove: Settings for NPF & YAPF
08:28:35 *** MarkoMarko has joined #openttd
08:28:35 <MarkoMarko> Does anyone know how to calculate the coordinates of a tile?
08:28:35 <MarkoMarko> I have the following data:
08:28:35 <MarkoMarko> mapSizeX: 256, mapSizeY: 1024.
08:28:35 <MarkoMarko> p1: 1869545481
08:28:35 <MarkoMarko> p2: 1869545472
08:28:37 <MarkoMarko> tile: 3388997632
08:28:37 <MarkoMarko> As far as I understand it, the 'tile' variable also includes the height.
08:30:21 <Eddi|zuHause> @base 10 16 3388997632
08:30:21 <DorpsGek> Eddi|zuHause: CA000000
08:30:55 <Rubidium_> tile doesn't contain height, though if I were to guess you that doesn't look like data for a command (at least not in that format with those values)
08:31:54 <Eddi|zuHause> to get coordinates of a tile, you need a TileIndex
08:32:07 <Rubidium_> on the other hand, the way commands are sent over the network has been changed before version 13. So code that worked for network packets of 12 and before does not work anymore
08:32:15 <MarkoMarko> I get this from adminPackets.SERVER_CMD_LOGGING
08:32:47 <Eddi|zuHause> @base 10 16 1869545481
08:32:47 <DorpsGek> Eddi|zuHause: 6F6F0009
08:33:10 <Eddi|zuHause> you might be missing an endianness swap
08:33:35 <Eddi|zuHause> @base 10 16 1869545472
08:33:35 <DorpsGek> Eddi|zuHause: 6F6F0000
08:34:19 <Rubidium_> in 13 OpenTTD doesn't send p1/p2/tile anymore, but something else
08:35:15 <MarkoMarko> It's weird, but I got it on version 13.1 through the admin port.
08:35:53 <LordAro> which library are you using? there are no official libraries and whatever you're using probably hasn't been updated for 13
08:38:33 <MarkoMarko> Я використовую node-libOpenttdAdmin, але там не було парсера для SERVER_CMD_LOGGING. Я дописав його самостійно. Він виглядає так:
08:38:33 <MarkoMarko> ```c++
08:38:33 <MarkoMarko> module.exports.cmdlogging = function(binaryparser, cb){
08:38:33 <MarkoMarko> binaryparser.into('cmdlogging', function(){
08:38:34 <MarkoMarko> this
08:38:35 <MarkoMarko> .word32le('clientId')
08:38:35 <MarkoMarko> .word8('companyId')
08:38:37 <MarkoMarko> .word16le('commandId')
08:38:37 <MarkoMarko> .word32le('p1')
08:38:39 <MarkoMarko> .word32le('p2')
08:38:39 <MarkoMarko> .word32le('tile')
08:38:41 <MarkoMarko> .scan('text', zeroterm())
08:38:41 <MarkoMarko> .tap(function(vars){ vars.text = vars.text.toString();})
08:38:43 <MarkoMarko> .word32le('frame')
08:38:43 <MarkoMarko> .tap(function(cmdlogging){
08:38:45 <MarkoMarko> cb(cmdlogging);
08:38:45 <MarkoMarko> });
08:38:47 <MarkoMarko> });
08:38:47 <MarkoMarko> };
08:39:35 <MarkoMarko> I use node-libOpenttdAdmin, but there was no parser for SERVER_CMD_LOGGING. I added it myself. It looks like this:
08:39:35 <MarkoMarko> ```c++
08:39:35 <MarkoMarko> module.exports.cmdlogging = function(binaryparser, cb){
08:39:35 <MarkoMarko> binaryparser.into('cmdlogging', function(){
08:39:35 <MarkoMarko> this
08:39:35 <MarkoMarko> .word32le('clientId')
08:39:35 <MarkoMarko> .word8('companyId')
08:39:37 <MarkoMarko> .word16le('commandId')
08:39:37 <MarkoMarko> .word32le('p1')
08:39:39 <MarkoMarko> .word32le('p2')
08:39:39 <MarkoMarko> .word32le('tile')
08:39:41 <MarkoMarko> .scan('text', zeroterm())
08:39:41 <MarkoMarko> .tap(function(vars){ vars.text = vars.text.toString();})
08:39:43 <MarkoMarko> .word32le('frame')
08:39:43 <MarkoMarko> .tap(function(cmdlogging){
08:39:45 <MarkoMarko> cb(cmdlogging);
08:39:45 <MarkoMarko> });
08:39:47 <MarkoMarko> });
08:39:47 <MarkoMarko> };
08:40:12 *** nielsm has quit IRC (Ping timeout: 480 seconds)
08:43:02 <Eddi|zuHause> maybe next time don't try to paste 20 lines
08:43:21 <LordAro> i'd imagine it looks better on discord
08:43:48 <LordAro> still, it's quite readable
08:44:21 <MarkoMarko> I'm sorry, I realized later that you weren't in discord.
08:44:57 <MarkoMarko> Thanks for the answers, I'll try it on version <13 later.
08:45:39 <LordAro> but yeah, the "answer" is that p1/p2/tile don't exist anymore, they've been replaced with command-specific variables
08:46:12 <LordAro> one of the disadvantages of the new command system is that those are not documented anywhere, nor is there any attempt to keep them compatible
08:46:39 <MarkoMarko> Thank you for the information.
08:46:52 <DorpsGek> [OpenTTD/OpenTTD] EmperorJake commented on pull request #10623: Remove: Settings for NPF & YAPF
08:49:36 <LordAro> e.g. CMD_BUILD_VEHICLE ( ) eventually links through to
08:54:18 <DorpsGek> [OpenTTD/OpenTTD] rubidium42 opened pull request #10657: Fix: update some network documentation to match the new command system
08:55:03 <LordAro> i've no idea how it would be achieved, but maybe there should be an admin command that dumps the format of all commands
08:58:04 <DorpsGek> [OpenTTD/OpenTTD] LordAro approved pull request #10657: Fix: Update some network documentation to match the new command system
09:00:06 <petern> Maybe the API should be replaced with a non-binary method?
09:00:17 *** keikoz has quit IRC ()
09:01:15 <Rubidium_> s/replac/expand/
09:03:04 <DorpsGek> [OpenTTD/OpenTTD] TrueBrain commented on pull request #10623: Remove: Settings for NPF & YAPF
09:04:38 <TrueBrain> I always liked `boost::hana`, as they have a way to make a templated variable into an actual `std::string`, so you can have JSON outputs based on template variables names
09:04:57 <TrueBrain> how they do it, you really don't want to know, but it is funny as hell 🙂
09:05:47 <TrueBrain> reflection in C++, it is weird 😛
09:06:08 <petern> None of this kit is surface mount, but even the through-hole components are way tinier than when I studied electronics engineering at college.
09:06:39 <petern> Oh wait, that was nearly 30 years ago. Oh no.
09:08:11 <DorpsGek> [OpenTTD/OpenTTD] TrueBrain commented on pull request #10655: Change: base autosaves intervals on real time (instead of game time)
09:08:22 <TrueBrain> we are getting old 😛
09:09:22 <petern> I suppose that is better than not getting old.
09:09:31 <TrueBrain> depends on your goals in life
09:10:14 <DorpsGek> [OpenTTD/OpenTTD] rubidium42 merged pull request #10657: Fix: Update some network documentation to match the new command system
09:10:55 <DorpsGek> [OpenTTD/OpenTTD] rubidium42 opened pull request #10658: Codechange: Replace some p1/p2 parameter names with better named ones
09:12:29 <petern> Haha, I keep lifting up my magnifier lens to inspect it, then realising that I need that still
09:12:35 <TrueBrain> hmm .. so why is VSCode integration with OpenTTD not working .. it keeps complaining about include-files not working ..
09:12:38 <MarkoMarko> I checked it on 12.2 and it does return different data. On the same tile, it returns 28527. I will try other methods to find the coordinates of the player commands. Thank you again.
09:13:45 <MarkoMarko> FLHerne: the information is outdated 🥺
09:14:51 <DorpsGek> [OpenTTD/OpenTTD] Eddi-z commented on pull request #10623: Remove: Settings for NPF & YAPF
09:15:30 <petern> MarkoMarko: The admin port method is the right way, just the data has changed and no documentation updated.
09:16:59 <Rubidium_> ... not updated in the 13 branch ;)
09:17:35 <Eddi|zuHause> @base 10 16 28527
09:17:35 <DorpsGek> Eddi|zuHause: 6F6F
09:20:26 <DorpsGek> [OpenTTD/OpenTTD] TrueBrain updated pull request #10647: Codechange: introduce a framework for all our timers
09:20:30 <DorpsGek> [OpenTTD/OpenTTD] TrueBrain commented on pull request #10647: Codechange: introduce a framework for all our timers
09:21:26 <DorpsGek> [OpenTTD/OpenTTD] TrueBrain updated pull request #10647: Codechange: introduce a framework for all our timers
09:21:53 *** keikoz has joined #openttd
09:22:14 <MarkoMarko> petern: Updated the message. Added more specifics. 🙂
09:22:23 <petern> Hmm, does VS Code's GitHub plugin allow me to force-pull...
09:22:52 <petern> Yeah I noticed. TBH I think edit should be left for typos rather than changing meaning 😉
09:24:00 <TrueBrain> Rewriting history, one sentence at the time!
09:26:20 <petern> Meh, I deleted the branch and re-checked out. Silly UIs
09:26:36 <TrueBrain> luckily we have `git reflog` 🙂
09:27:06 <DorpsGek> [OpenTTD/OpenTTD] TrueBrain approved pull request #10658: Codechange: Replace some p1/p2 parameter names with better names
09:27:49 <petern> Hmm, cppcheck still complains, although it's const it's not a const reference. Maybe it thinks a copy is made.
09:28:12 <TrueBrain> in my PR?
09:28:19 <petern> You can't really pass everything around by reference!
09:28:20 <TrueBrain> TPeriod is copied; as they are trivial objects
09:28:20 <petern> Yeah
09:28:32 <TrueBrain> not sure why it would those by reference .. I could do that
09:28:40 <TrueBrain> but .. sending an uint32 as reference always feels a bit silly
09:29:00 <TrueBrain> pretty sure the optimizer takes care of it anyway 😄
09:29:09 <petern> I think because it's a template type it doesn't know it's just an uint32?
09:29:40 <TrueBrain> sometimes it is a struct with 2 enums
09:29:41 <petern> Right, more soldering
09:29:47 <TrueBrain> but even there .. seems weird to send it by reference
09:30:11 <TrueBrain> I think I have too much faith in compiler optimizations 😄
09:31:09 <petern> To be honest passing these by reference seems to be "human thinks he knows better" but it is a tool suggesting it, heh
09:31:24 <TrueBrain> I am fine either way; want me to change them? 🙂
09:31:28 <DorpsGek> [OpenTTD/OpenTTD] LordAro commented on pull request #10658: Codechange: Replace some p1/p2 parameter names with better names
09:33:01 <LordAro> TrueBrain: profiling!
09:33:07 <TrueBrain> (and how do I run cppcheck in my VSCode)
09:33:13 <LordAro> premature optimisation, root of all evil, etc etc
09:33:21 <petern> I use the flylint extension.
09:33:40 <petern> It supports other analyzers too, clang and cspell. I turned off cspell as it's irrelevant 😄
09:33:52 <TrueBrain> I have another extension checking my spelling 😄
09:34:20 <petern> It's not always reliable, it doesn't necessarily analyse the whole project, but sometimes tries to.
09:34:32 <petern> But it is possible to trigger analysis for the open files.
09:34:45 <petern> Which is a lot quicker anyway 😄
09:36:18 <petern> Hmm, 4 resistors left, and they're all different values.
09:36:25 <petern> I am very slow at this 😄
09:36:55 *** qwebirc82739 has joined #openttd
09:37:09 <TrueBrain> funny, by reference results in 1 assembly line more than without, according to godbolt 😛
09:37:37 <Eddi|zuHause> is that a relevant metric?
09:37:52 <LordAro> not on its own
09:37:54 *** qwebirc82739 has quit IRC ()
09:38:22 <petern> In the context of "tool suggests this because it's better", it is a little
09:38:27 <TrueBrain> ha, without &, the compiler decides to move the object
09:38:35 <TrueBrain> which makes sense, as the TPeriod is always used as a constant
09:38:47 <LordAro> const value then?
09:39:13 <TrueBrain> the assembly line more is resolving of the pointer back to the value
09:39:23 <TrueBrain> so with reference, it makes the object, stores the pointer, resolves the pointer
09:39:34 <TrueBrain> with value, it makes the object, and shoves it right in the class
09:39:41 <TrueBrain> and that is without optimization 😄
09:39:57 <DorpsGek> [OpenTTD/OpenTTD] EmperorJake commented on pull request #10623: Remove: Settings for NPF & YAPF
09:40:11 <LordAro> profiling without optimisation isn't worth anything...
09:40:21 <petern> So without seems better?
09:40:21 <TrueBrain> with optimisation it removes the statements 😛
09:40:48 <petern> I imagine it depends on the size of the object as well, which the analyzer can't know, but the compiler does.
09:41:10 <TrueBrain> yeah, they really are simple objects
09:41:15 <LordAro> depends how deeply the analyzer hooks into clang :p
09:41:16 <TrueBrain> that is why it surprises me somewhat
09:41:18 <petern> Possibly with optimization it all looks the same.
09:41:41 <TrueBrain> I am 99% sure that by-value or by-reference make no actual difference in the resulting binary (assuming any form of optimization)
09:41:48 <TrueBrain> as the parameter is filled with a constant
09:42:02 <TrueBrain> so there is no copy being made
09:42:10 <TrueBrain> none of this matters btw; just curious what compilers do 🙂
09:42:15 <petern> Yeah
09:42:39 <petern> It's not relevant to performance, we're not constructing 1000s of these every tick....
09:43:17 <TrueBrain> I see a lot of code with `uint32_t &` in other codebases, and it always makes me wonder: why?
09:43:34 <LordAro> out params :p
09:43:39 <TrueBrain> no, for in-params 😛
09:43:41 <DorpsGek> [OpenTTD/OpenTTD] rubidium42 commented on pull request #10658: Codechange: Replace some p1/p2 parameter names with better names
09:43:51 <TrueBrain> but basically they make everything a by-reference, and let the compiler deal with it
09:44:15 <DorpsGek> [OpenTTD/OpenTTD] LordAro commented on pull request #10658: Codechange: Replace some p1/p2 parameter names with better names
09:44:21 <TrueBrain> anyway, seems in our usage by-value is fine; but again, I have no issue upgrading it to by-reference, your call 🙂
09:45:32 <TrueBrain> LordAro: for PF settings, it somehow feels it would be better if we make settings like: "Allow trains to passthrough open platforms"; to make settings that are actually understandable by users
09:45:52 <TrueBrain> (instead of depending on users to understand how PF penalties work :P)
09:46:06 <LordAro> TrueBrain: i was just thinking that
09:46:10 <LordAro> and making it PF agnostic
09:46:23 <TrueBrain> much more user-friendly
09:46:28 <TrueBrain> user-centric, even
09:47:36 <TrueBrain> for me that doesn't have to be done in that PR, but can be done in a follow-up; I am sure there are more of those kind of settings to be created, but we just have to collect them over time
09:49:48 <DorpsGek> [OpenTTD/OpenTTD] LordAro commented on pull request #10647: Codechange: introduce a framework for all our timers
09:50:34 <TrueBrain> LordAro: huh? That is so far from what I see ... I cannot believe that 😛
09:51:02 <TrueBrain> especially as with `-vnull` you disable the Window system, which this PR impacts most
09:51:54 <LordAro> don't think disabling the video driver disables the in game window system...
09:52:02 <TrueBrain> it does, most part
09:52:49 <TrueBrain> the `mainloop` is rather different 😛
09:53:00 <TrueBrain> owh, no, it is dedicated server that bypasses most
09:53:09 <TrueBrain> but not null-driver? Okay .. another room to make the null-driver faster
09:53:32 <LordAro> heh
09:54:05 <LordAro> bit harder to test with the actual video drivers...
09:54:05 <TrueBrain> but what you record is, what, 20% slowdown? I find that hard to believe .. hmm .. how to dig into this deeper .. let's see ..
09:54:40 <TrueBrain> yeah, that is why I used the framerate window
09:55:00 <TrueBrain> which showed the exact same framerate on fast-forward .. like, up to the first decimal point
09:55:40 <TrueBrain> the question is .. can I repeat your findings ..
09:55:55 <TrueBrain> as I would want to know which parts causes this
09:56:16 <LordAro> i'll see if i can get an actual profile out
09:56:34 <LordAro> the simulation rate in the framerate window is jumping about all over the place
09:57:01 <petern> It does that 🙂
09:57:06 <TrueBrain> not on an empty map 🙂
09:57:28 <TrueBrain> load a 64x64 map and see what it does 🙂
09:57:28 <LordAro> no, definitely slower
09:57:45 <LordAro> wentbourne goes from x0.67 to x0.55
09:57:48 <TrueBrain> yeah, of that I am 100% sure there was no impact on my machine
09:57:49 <LordAro> ish.
09:58:15 <TrueBrain> are you 100% sure you build the revisions you claimed?
09:58:21 <TrueBrain> not that #10607 is in one, and not in the other?
09:58:31 <LordAro> just confirming
09:58:34 <TrueBrain> just to rule that out 😛
09:58:37 <LordAro> but the commits i used were from --version output
09:58:40 <TrueBrain> duplicating your findings btw 🙂
09:59:26 <TrueBrain> running `perf` in WSL has a penalty, it seems 😛
09:59:31 <DorpsGek> [OpenTTD/OpenTTD] rubidium42 commented on pull request #10658: Codechange: Replace some p1/p2 parameter names with better names
10:00:29 <DorpsGek> [OpenTTD/OpenTTD] LordAro commented on pull request #10658: Codechange: Replace some p1/p2 parameter names with better names
10:02:04 <TrueBrain> recompiling always takes so long 😛
10:02:16 <LordAro> ikr
10:02:31 <LordAro> try doing it with just 4 cores
10:02:55 <TrueBrain> I have such a hard time believing my PR could make such an impact on performance 😛 Either it is something silly, or I am missing something
10:04:45 <LordAro> ah crap hang on
10:04:51 <TrueBrain> okay, on debug, my branch is slightly faster .. now for RelWithDebInfo ... takes so long 😛
10:04:53 <LordAro> it still scans newgrfs
10:04:58 <LordAro> need -QQ
10:05:20 <LordAro> wait, no, it's still doing that even with -QQ
10:05:45 <TrueBrain> add `-c empty/empty.cfg`
10:05:47 <TrueBrain> should prevent that
10:06:22 <LordAro> no, still picking up stuff in ~/.local
10:06:25 <LordAro> (according to strace)
10:06:56 <TrueBrain> I am sure I fixed that? Hmm, never checked strace .. but the scanner shouldn't pick them up anymore ..
10:07:02 <TrueBrain> or am I just getting old and forgetting shit 😄
10:07:24 <TrueBrain> but yes, `-QQ` should prevent them from loading anyway
10:07:27 <LordAro> well OTTD itself is definitely still reading the files
10:08:15 <TrueBrain> or make it `-QQQQQQQQQQQQQQQ`
10:08:18 <TrueBrain> to be absolutely sure 😛
10:08:54 <TrueBrain> or is it `-Q -Q`? I don't know, I didn't add it 😛
10:09:29 <TrueBrain> code suggest that `-QQQ` makes `DoScan` never execute
10:09:44 <LordAro> nope
10:10:25 <TrueBrain> it still loads the baseset btw .. it just shouldn't scan for NewGRFs?
10:10:37 <TrueBrain> when my compile is done, I can confirm if it works or not 😛
10:10:52 <LordAro>
10:10:55 <TrueBrain> works here, `-QQQ` skips all scanning
10:11:10 <TrueBrain> yes, those are AIs etc, I guess
10:11:44 <LordAro> nope
10:12:10 <TrueBrain> fileio.cpp, line 421
10:12:17 <TrueBrain> the only one pringint that "Scanning for" line
10:12:29 <LordAro>
10:12:31 <TrueBrain> is not the NewGRF scanner, but it is the tar-scanner
10:12:46 <TrueBrain> it is just a glob over the folders
10:13:25 <TrueBrain> so yeah, seems it always does that .. we never made anything to avoid it doing that 🙂
10:13:51 <TrueBrain> but the actual GRF files shouldn't be loaded
10:13:57 <LordAro> that does seem to be the case
10:14:04 <TrueBrain> it just opens the tar, to inspect what is in there
10:14:19 <TrueBrain> ah, `-X` was the argument I was thinking about
10:14:32 <TrueBrain> you want to add that, and move your baseset to a local place
10:14:39 <TrueBrain> (so in `empty/baseset` or something)
10:14:41 <LordAro> the fact that it scans directories multiple times isn't all that helpful
10:14:43 <LordAro> aha
10:14:50 <michi_cc[d]> Okay, my turn to be mean today.
10:14:54 <DorpsGek> [OpenTTD/OpenTTD] michicc commented on issue #10656: [Bug]: (Not really a bug) Playstyle incompatibility with #10596
10:14:57 <DorpsGek> [OpenTTD/OpenTTD] michicc closed issue #10656: [Bug]: (Not really a bug) Playstyle incompatibility with #10596
10:16:29 <TrueBrain> I mostly wonder if they actually played the game with these changes, or are theocrafting it
10:16:36 <TrueBrain> I want telemetry 😄
10:17:05 <Eddi|zuHause> i skimmed the issue and it looked like theorycrafting
10:17:12 <DorpsGek> [OpenTTD/OpenTTD] LordAro commented on issue #10656: [Bug]: (Not really a bug) Playstyle incompatibility with #10596
10:17:16 <LordAro> that was my thought too
10:17:35 <TrueBrain> okay, with `-X` it is doing what you want LordAro
10:17:44 <TrueBrain> `-QQQ -x -c .. -X` ...
10:17:48 <TrueBrain> getting a bit out of hand 😛
10:18:17 <TrueBrain> well, `-QQQ` no longer is needed, I guess
10:19:24 <TrueBrain> okay, finally have a clean and changed release build .. let's see if I can reproduce your results
10:19:29 <LordAro> i'm sure i had a "nullgfx" or something somewhere
10:19:33 <LordAro> can't find it
10:20:21 <TrueBrain> and I cannot ..
10:20:34 <TrueBrain> 28.9B instructions with my PR, 28.8B instructions with master
10:20:43 <TrueBrain> that is nowhere near your results ..
10:21:17 <TrueBrain> what scares me most, is that you need 220B instructions to do the same as I can do in 28.9B instructions 😦
10:21:40 <TrueBrain> I hope it is the NewGRF scanner or something
10:25:12 <DorpsGek> [OpenTTD/OpenTTD] TrueBrain commented on pull request #10647: Codechange: introduce a framework for all our timers
10:26:43 <LordAro> TrueBrain: those numbers are indeed surprisingly different
10:26:47 <LordAro> what CPU have you got?
10:27:02 <TrueBrain> i7-8700K
10:27:20 <DorpsGek> [OpenTTD/OpenTTD] Kuhnovic updated pull request #10543: Feature: Region-based pathfinder for ships
10:27:21 <TrueBrain> so that shouldn't be a factor 8 in amount of instructions 😄
10:27:35 <LordAro> wouldn't have thought so...
10:27:54 <TrueBrain> but yeah, please redo your test with -X, and let's hope it was just NewGRF scanning
10:28:08 <LordAro> doing so now, but it's not looking good...
10:28:46 <TrueBrain> just to confirm linking took forever? (as in, it was a release build? :P)
10:28:56 <LordAro> yes :)
10:28:57 <TrueBrain> sorry for the double-checking, but we have to find out what is so different here 🙂
10:29:47 <TrueBrain> what if we run `time ./openttd -X -c empty/empty.cfg -x -snull -mnull -vnull:ticks=30000 -g ../media/baseset/opntitle.dat` a few times?
10:30:39 <TrueBrain> lot of noise 😛
10:30:48 <TrueBrain> ranges from 3.6s to 4.6s on master for me ..
10:30:54 <TrueBrain> guess it is time to actual profile 🙂
10:31:18 <LordAro> rock solid 2.95s master, 3.53s PR
10:31:23 <DorpsGek> [OpenTTD/OpenTTD] LordAro commented on pull request #10647: Codechange: introduce a framework for all our timers
10:31:37 <TrueBrain> so what is so different ..
10:31:44 <TrueBrain> what compiler? Just to check one more thing
10:32:52 <LordAro> g++ 12.2.1
10:33:03 <TrueBrain> 11.3 here
10:33:13 <TrueBrain> I have 12 installed, so let me try that
10:33:21 <TrueBrain> 12.1.0, but okay
10:34:20 <Eddi|zuHause> anyone remember when we supported gcc 2.95 or something?
10:34:36 <LordAro> ah crap
10:34:41 <LordAro> master has -DNDEBUG
10:34:53 <TrueBrain> ....... DUDE
10:34:54 <LordAro> oh no
10:34:57 <LordAro> ignore me
10:34:59 <LordAro> they both do
10:35:07 <TrueBrain> 😄 Both asserts on?
10:35:29 <LordAro> ...though master has it defined twice in the compile command, PR only once
10:35:31 <TrueBrain> can't believe we draw with the null-driver ... that is a silly thing to fix 😛
10:35:42 <LordAro> there's something funny going on, i'm going to regenerate both
10:35:47 <TrueBrain> please do
10:35:54 <TrueBrain> looking at kcachegrind in the meantime, see if I can spot anything
10:36:12 <TrueBrain> 60% of CPU time is in UpdateWindows
10:36:14 <TrueBrain> on the null-driver
10:36:15 <TrueBrain> 😄
10:36:29 <TrueBrain> 50% is DrawDirtyBlocks
10:36:37 <TrueBrain> yes, redraw that empty screen, please do!
10:37:16 <TrueBrain> the first mention of timers is at 0.23% total CPU usage
10:37:46 <TrueBrain> so yeah, after your rebuild etc, please run a profile, and see what is going on
10:38:03 <Eddi|zuHause> wasn't there some usecase so you can still make screenshots with the null driver?
10:38:30 <TrueBrain> same as with dedicated servers
10:38:58 <TrueBrain> LordAro: most I can see is that my pick for `std::set` is hurting performance, as it spends a lot of time in there (relatively speaking)
10:39:00 * LordAro starts picking out parts for a 5800x3D machine while waiting for compile
10:39:16 <TrueBrain> I picked `std::set` to get free sorting 😛
10:39:37 <TrueBrain> performance-wise, `std::vector` might be better .. but at 0.23% .. meh? 😄
10:41:18 <TrueBrain> wauw, 2.6% CPU is in SwitchToMode
10:41:27 <TrueBrain> ah, loading of the savegame, duh
10:41:50 <TrueBrain> owh, it also makes auto-saves, it seems
10:42:01 <TrueBrain> we need my PR to fix that 😛
10:42:48 <TrueBrain> the `TimerGameCalendar` took 0.01% CPU here; that is in line what I would expect .. such rare events
10:42:55 <LordAro> i noticed the autosaves
10:43:55 <TrueBrain> kcachegrind is showing me that the timers are behaving exactly how I would expect them too; hopefully your rebuild makes your computer sane again too, but otherwise I would love to see a profile 🙂
10:45:20 <TrueBrain> and for shit and giggles, I am going to enable `_network_dedicated` in the null-driver, see what that does for the speed 😛
10:45:26 <TrueBrain> first, LUNCH TIME!
10:47:27 <LordAro> i'm still quite tempted by one of the new Intel GPUs
10:47:50 <LordAro> they're quite cheap given their performance
10:48:58 <TrueBrain> They are just so expensive
10:49:09 <LordAro> oh, absolutely
10:49:20 <LordAro> just compared to the amd/nvidia equivalents
10:49:26 <TrueBrain> I would like a new AMD CPU, purely as that would make compiling faster
10:49:43 <TrueBrain> And I would like an Nvidia GPU, purely for AI related work
10:49:48 <DorpsGek> [OpenTTD/OpenTTD] TheMowgliMan commented on issue #10656: [Bug]: (Not really a bug) Playstyle incompatibility with #10596
10:50:05 <TrueBrain> But, out of a job, so no expensive shit for me for now 😄
10:50:34 <LordAro> oh no
10:51:02 <TrueBrain> By my own choice, no worries. But a tad annoying for these kind of things :d
10:51:33 <DorpsGek> [OpenTTD/OpenTTD] LordAro commented on pull request #10647: Codechange: introduce a framework for all our timers
10:51:37 <DorpsGek> [OpenTTD/OpenTTD] TheMowgliMan commented on issue #10656: [Bug]: (Not really a bug) Playstyle incompatibility with #10596
10:52:31 <TrueBrain> So it was your local setup?
10:52:36 <LordAro> apparently so
10:52:41 <TrueBrain> Phew
10:52:44 <LordAro> no idea what, as that compile has been nuked from existence
10:52:49 <LordAro> ah well
10:52:57 <TrueBrain> It is a lot faster now
10:53:02 <TrueBrain> So that is odd
10:53:15 <TrueBrain> Owh no
10:53:18 <TrueBrain> It is not
10:53:27 <TrueBrain> Weren't asserts disabled on one?
10:53:34 <TrueBrain> Seems the most logic reason
10:54:01 <LordAro> it's possible that whenever i configured the master build i disabled asserts as well
10:54:11 <LordAro> that was a while ago
10:55:01 <TrueBrain> Sounds reasonable
10:55:14 <LordAro> i'm going to generate a profile anyway, just for the lolz
10:55:14 <TrueBrain> Still, what a difference a CPU has on instructions executed
10:55:25 <LordAro> yeah, that is still surprising
10:55:32 <LordAro> unless it's WSL fudging with the results
11:03:58 <TrueBrain> did all my testing on WSL, seems fine
11:04:04 <TrueBrain> owh, you didn't ofc
11:04:05 <TrueBrain> haha, sorry 😛
11:04:17 <TrueBrain> not sure how `perf` measures .. it might be
11:04:34 <LordAro> those numbers come from the kernel afaik
11:04:36 <TrueBrain> haha, did you just hide all the comments? That is also a way 😄
11:04:40 <LordAro> :D
11:06:04 <LordAro> got the profile out for master
11:06:10 <LordAro> nothing too surprising there
11:06:17 <DorpsGek> [OpenTTD/OpenTTD] TrueBrain commented on pull request #10647: Codechange: introduce a framework for all our timers
11:06:28 <LordAro> Utf8Decode being called 37 million times is a bit fun
11:06:33 <TrueBrain> haha
11:06:36 <TrueBrain> nothing surprising indeed 😄
11:07:03 <DorpsGek> [OpenTTD/OpenTTD] Kuhnovic updated pull request #10543: Feature: Region-based pathfinder for ships
11:07:10 <LordAro> that's a bit more interesting - FormatGenericCurrency is about 6% of runtime
11:07:31 <TrueBrain> okay, wit dedicated server setting on, `UpdateWindows` takes 50% instead of 60%
11:07:35 <TrueBrain> so not that much difference
11:08:30 <TrueBrain> `FormatGenericCurrency` is 0.38% here
11:08:46 <TrueBrain> well, to be fair, I run with 3000 ticks, otherwise it took so long
11:09:05 <LordAro> 6% is inclusive of all calls within it
11:09:06 <TrueBrain> LordAro: that with a release or debug build?
11:09:12 <LordAro> most of which seems to be the printf
11:09:23 <LordAro> seprintf*
11:09:28 <LordAro> same release build
11:09:33 <TrueBrain> same here .. but seprintf doesn't even show up 😛
11:09:45 <TrueBrain> only in FormatNumber it does
11:10:24 <TrueBrain> what a weird difference in results ..
11:10:41 <TrueBrain> on what map did you do it?
11:10:44 <TrueBrain> I forgot to ask that 😛
11:10:45 <LordAro> opntitle
11:10:56 <TrueBrain> can you run that for 3000 ticks; how often is FormatGenericCurrency called?
11:11:13 <TrueBrain> just to make sure valgrind didn't fuck up the creating of my profile 😄
11:11:48 <TrueBrain> owh, also relevant: how did you make your profile?
11:13:23 <TrueBrain> cool, didn't know callgrind had `--dump-before`, which is interesting .. splits up your profile in parts
11:13:54 <TrueBrain> so you can say: when-ever a game is loaded, make a new part, basically
11:14:16 <LordAro> TrueBrain:
11:14:31 <LordAro> oh, that's the 30000 one
11:14:35 <LordAro>
11:14:57 <LordAro> callgrind with the same commandline as before, then pipe it into gprof2dot
11:15:08 <LordAro>
11:15:16 <TrueBrain> FormatGenericCurrency doesn't show up?
11:16:09 <LordAro> yes that's curious
11:16:15 <LordAro> the one i was looking at before was generating from master
11:16:22 <LordAro> the above links are from your branch
11:18:38 <TrueBrain> okay, but my profile is the same, so that is good 🙂
11:18:41 <TrueBrain> means WSL isn't the issue 😛
11:18:48 <LordAro> master
11:19:51 <TrueBrain> I don't get FormatGenericCurrency .. or kcachegrind is showing the results different 😄
11:20:20 <LordAro> too small to show up or something
11:20:23 <TrueBrain> owh, it is a 30k run .. okay, let me run that 🙂
11:20:38 <LordAro> i don't get it in the runs on your branch either
11:20:39 <TrueBrain> just takes for-ever 😛
11:21:14 <TrueBrain> lol; and there should be no difference in those regards what so ever 😛
11:21:27 <LordAro> yeah...
11:22:15 <LordAro> something weird happening, FormatString called 45k times with your branch, 1.2 million with master
11:24:15 <TrueBrain> running 30k ticks takes FOR EVER
11:24:17 <TrueBrain> holy crap ..
11:25:39 <LordAro> looks like it's CompanyFinancesWindow::OnPaint
11:25:47 <LordAro> doesn't appear in my profile for your branch...
11:25:58 <LordAro> (which would follow from the FormatGenericCurrency stuff)
11:26:15 <LordAro> but they're both 30k profiles, so it should have appeared regardless...
11:26:26 <TrueBrain> my 30k profile is still generating ...
11:26:37 <LordAro> does take a few minutes :p
11:26:44 <TrueBrain> "a few"
11:26:48 <TrueBrain> more than 10 times a 3k
11:27:03 <TrueBrain> there we go
11:27:10 <TrueBrain> indeed, master is 8%
11:27:19 <TrueBrain> wauw ... why did that change so much .. interesting ...
11:27:53 <TrueBrain> did I accidentally fix a bug?
11:27:58 <LordAro> did OnPaint timer get changed somehow?
11:28:24 <LordAro> or did you stop the finances window from appearing at year end? :p
11:28:39 <TrueBrain> try it yourself; it really shows up 🙂
11:28:41 <TrueBrain> and looks fine
11:30:44 <LordAro> indeed so
11:30:47 <LordAro> curious.
11:30:48 <TrueBrain> the main difference between master and my PR is that on master it updates every 27ms, and with my PR every 30ms
11:31:05 <LordAro> that wouldn't have that much effect...
11:31:21 <TrueBrain> 10% more calls, so no
11:31:24 *** WormnestAndroid has quit IRC (Remote host closed the connection)
11:31:28 *** WormnestAndroid has joined #openttd
11:31:55 *** D-HUND is now known as debdog
11:32:43 <TrueBrain> so it basically is the call to DrawPrice
11:34:23 <TrueBrain> ha, no, I know
11:34:31 <TrueBrain> it is a "bug" in the null-driver that I now accidentially fixed
11:34:38 <TrueBrain> the null-driver runs UpdateWindows for every tick
11:34:44 <TrueBrain> where the other drivers run it on your refresh-rate
11:34:48 <TrueBrain> OnHunderthTick was tick-based
11:34:51 <TrueBrain> it is now time-based
11:35:22 <TrueBrain> or not? Hmm .. something like this, I suspect
11:35:46 <LordAro> that might make sense
11:35:56 <TrueBrain> I am waiting on my second profile so I can actually compare 😛
11:36:52 <DorpsGek> [OpenTTD/OpenTTD] Kuhnovic updated pull request #10543: Feature: Region-based pathfinder for ships
11:38:48 <TrueBrain> no, I am wrong
11:38:56 <TrueBrain> on the profile from my PR I also see the same function popping up now
11:39:34 <TrueBrain> so the behaviour is unchanged; but I guess this means you found a huge performance issue in the company finance window 😛
11:40:27 <TrueBrain> it doesn't show up with 3k ofc, as the finance window hasn't opened (long enough) yet
11:40:33 <TrueBrain> so with 30k, it is open long enough for it to matter
11:40:48 <TrueBrain> but in both cases, ~8.5% total CPU here
11:41:55 <TrueBrain> in all cases, nothing wrong with my PR 😛
11:42:30 <LordAro> fair nuff
11:42:43 <LordAro> strange that it doesn't appear on my other profile though
11:42:50 <TrueBrain> you ran it for 30k too?
11:43:11 <TrueBrain> yeah, I really have "timer" in this profile, so I know I did that right 😄
11:44:25 <LordAro> s9c was 30k, yeah
11:44:37 <LordAro> oh, derp, both others were 3000
11:44:48 <LordAro> carry on
11:44:50 <TrueBrain> 🙂
11:45:09 <TrueBrain> can't believe DrawPrice takes so much CPU time .. that is crazy 🙂
11:45:22 <TrueBrain> why does it redraw to often, I wonder
11:47:14 <petern> Uh, 200 tiles at 5mph... that was never useful...
11:47:26 <petern> See also "why did the industry shutdown?"
11:48:43 <TrueBrain> LordAro: it seems that the window is in an unlucky place, and needs to be redrawn every time
11:49:03 <LordAro> yeah
11:49:13 <LordAro> still feel like we can improve the performance of FormatNumber though
11:49:26 <TrueBrain> true .. but also it shouldn't redraw that often 😛
11:49:38 <TrueBrain> RedrawScreenRect -> DrawOverlappedWindow -> CompanyFinancesWindow::OnPaint
11:49:48 <TrueBrain> happens ... almost every tick
11:49:58 <LordAro> ah
11:50:07 <LordAro> even so, the numbers within it change often enough
11:50:15 <TrueBrain> not -that- often
11:50:45 <TrueBrain> but yeah, DrawPrice is just silly slow
11:50:57 <TrueBrain> called 500k times, takes 10% CPU
11:51:19 <TrueBrain> anyway, all this means the PR is okay? 😛
11:53:25 <LordAro> yes :)
11:53:46 <TrueBrain> nice 😄
11:55:50 <TrueBrain> guess that means someone should hit that approve button too 😛
11:57:53 <DorpsGek> [OpenTTD/OpenTTD] PeterN approved pull request #10647: Codechange: introduce a framework for all our timers
11:58:57 <TrueBrain> bam
11:58:59 <DorpsGek> [OpenTTD/OpenTTD] TrueBrain merged pull request #10647: Codechange: introduce a framework for all our timers
11:59:30 <DorpsGek> [OpenTTD/OpenTTD] TrueBrain updated pull request #10655: Change: base autosaves intervals on real time (instead of game time)
12:00:24 <DorpsGek> [OpenTTD/OpenTTD] TrueBrain updated pull request #10653: Change: replace per-AI "start_date" with a global "competitors_interval"
12:01:28 <TrueBrain> tnx both, for all the feedback etc 🙂
12:06:42 <petern> TrueBrain: Is that just for the status bar cash value?
12:07:05 <petern> Hmm, where did I put my multimeter...
12:24:49 <TallTyler> TrueBrain: I’m just scrolling through everything that happened when I was asleep, but I like this idea a lot. Maybe you could put that in the PR so it doesn’t get lost. 😄
12:25:02 <TrueBrain> petern: no, finance window 🙂
12:26:06 <TrueBrain> TallTyler: everything is in the PRs; but this is an open question to LordAro, whether he wants to merge the PF setting removal as-is, and make a new PR to add some human-centric settings, or do that in the same PR 🙂
12:38:19 *** Flygon has joined #openttd
12:38:53 <LordAro> probably best do it in the same PR
12:39:23 <LordAro> so i was fiddling around with fmt for purposes of rewriting FormatNumber... only to find myself needing to upgrade fmt
12:39:41 <LordAro> having done that, i find that it's deprecated implicit conversion of enum types
12:39:50 <LordAro> meaning that i have to go around adding format_as functions everywhere
12:48:54 <TrueBrain> oof
12:49:43 <TrueBrain> what does `format_as` do? You define that per enum to print out the name or something?
12:50:16 <LordAro> auto format_as(film f) { return fmt::underlying(f); }
12:50:21 <LordAro> from their docs
12:50:56 <TrueBrain> why not make a single template that does that for all enums?
12:51:02 <TrueBrain> feels a bit pointless to define that per enum
12:51:22 <TrueBrain> personally I btw absolutely love magic_enum, where you can print the name of the enum
12:51:25 <TrueBrain> instead of the value
12:51:30 <LordAro> how can i do that for "all enums" ?
12:51:31 <TrueBrain> for print statements most of the time so much better
12:51:37 <TrueBrain> a template 🙂
12:52:02 <TrueBrain> too bad I no longer have access to the codebase of my last job .. I did exactly that there 🙂
12:52:21 <LordAro> a template, yes, but i don't want to define it for "all types"...
12:52:36 <petern> Oh yeah, finance window is mad.
12:52:38 <TrueBrain> no, you can make it work only for enums 🙂
12:52:49 <TrueBrain> let me remember how ...
12:53:05 <TrueBrain> the trick is to use `std::is_enum` 🙂
12:53:43 <LordAro> well, that'd do it
12:53:50 <LordAro> but where do i put that template?
12:53:57 <LordAro> stdafx & include fmt in everything?
12:54:01 <TrueBrain> in an fmt wrapper, if we have that
12:54:04 <TrueBrain> otherwise stdafx 😛
12:54:25 <frosch> TallTyler: do you happen to know how to report discord dm spam bots?
12:55:12 <TrueBrain> LordAro: it start with using `magic_enum::enum_name(<enum value>)`, so for example for `Color::RED` that returns `RED`
12:55:21 <TrueBrain> which is just so much more useful in debug statements than its actual value
12:55:54 <LordAro> TrueBrain: indeed so!
12:56:07 <LordAro> presume it adds a boatload of strings to the binary though
12:56:18 <TrueBrain> yeah ..... boo-fucking-hoo 😛
12:56:30 <TrueBrain> next, it was something with `typename std::enable_if<std::is_enum<T>::value>::type>`
12:56:41 <TrueBrain> which means the specialization only happens when it is an enum
12:56:54 <LordAro> lol
12:57:13 <TrueBrain> SFINAE at work 😛
12:57:31 <TrueBrain> but once you done that, you can print enums from everywhere in your code, and it "just works"
12:57:39 <TrueBrain> I absolutely loved it; saves so much time
12:58:26 <TrueBrain> what I don't know, if/how that integrates with fmt .. as I used boost, which already had template specialization done
12:58:37 <petern> Hmm, it works, but one of the LEDs on the 8x8 matrix flickers. Hmm...
12:58:48 <TrueBrain> turn it off petern 😛
12:58:54 <petern> I tried :p
12:59:29 <frosch> lordaro: i think the plan was to remove {fmt} again, when we switch to c++20. so we should not use features which are not c++20
13:00:47 <petern> Remove fmt? Oh, I had patches that use it...
13:00:55 <petern> git branch -D ;D
13:01:57 <frosch> the fmt lib we use, and the one in c++20 probably differ in some details
13:02:07 <frosch> just like old boost stuff defers from c++11
13:02:30 <LordAro> aw :(
13:02:33 <petern> Ah so it's a stop-gap.
13:02:36 <frosch> if you need to update the fmt lib to get some feature, it sounds like it would not be part of c++20
13:02:50 <petern> Right, has the world ended yet?
13:02:57 <frosch> it did in 2012
13:03:00 <LordAro> indeed not
13:03:08 <LordAro> i was wanting fmt::group_digits
13:04:52 <DorpsGek> [OpenTTD/OpenTTD] TrueBrain commented on pull request #10614: WIP: scale out TileLoop, to speed up bigger maps
13:04:55 <DorpsGek> [OpenTTD/OpenTTD] TrueBrain closed pull request #10614: WIP: scale out TileLoop, to speed up bigger maps
13:06:21 <petern> Oh... that pixel of the matrix is used to indicate sync. Oops 😄
13:06:37 <DorpsGek> [OpenTTD/OpenTTD] TrueBrain commented on pull request #10606: Feature: Setting to scale cargo production of towns and industries
13:06:43 <TrueBrain> so it is suppose to flicker!
13:07:09 <petern> Yeah, I didn't have a sync cable connected so didn't know
13:09:53 <TallTyler> frosch: If it came from this server, I can ban them from here — just DM me a screenshot of the post showing their username for the moderation log. As far as reporting to Discord itself, I think you need to report it as spam from your DM inbox.
13:10:53 <frosch> thanks, but I am actually not that sure. some user dm'ed me immediately after join, but they have been active before, so no new account
13:11:17 <DorpsGek> [OpenTTD/OpenTTD] TrueBrain commented on pull request #10606: Feature: Setting to scale cargo production of towns and industries
13:11:45 <DorpsGek> [OpenTTD/OpenTTD] rubidium42 merged pull request #10658: Codechange: Replace some p1/p2 parameter names with better names
13:16:55 <DorpsGek> [OpenTTD/OpenTTD] TrueBrain commented on pull request #10606: Feature: Setting to scale cargo production of towns and industries
13:19:09 <DorpsGek> [OpenTTD/OpenTTD] TrueBrain commented on pull request #10606: Feature: Setting to scale cargo production of towns and industries
13:19:29 <petern> Was it MainLine45?
13:19:56 <frosch> yes
13:20:11 <petern> Guessed because they DMed me too.
13:20:29 <petern> I don't think it's a bot.
13:24:19 <DorpsGek> [OpenTTD/OpenTTD] TrueBrain commented on issue #10646: [Bug]: Console Doesn't Close on multiplayer games
13:25:11 <DorpsGek> [OpenTTD/OpenTTD] TrueBrain commented on issue #10645: [Bug]: Japanese characters are garbled.
13:25:14 <DorpsGek> [OpenTTD/OpenTTD] TrueBrain closed issue #10645: [Bug]: Japanese characters are garbled.
13:28:37 <DorpsGek> [OpenTTD/OpenTTD] Kuhnovic updated pull request #10543: Feature: Region-based pathfinder for ships
13:30:16 <TrueBrain> hihi, that bug is funny 😄 Could have been us 😛 Well, except we don't use FP
13:39:32 <DorpsGek> [OpenTTD/OpenTTD] TrueBrain commented on issue #10656: [Bug]: (Not really a bug) Playstyle incompatibility with #10596
13:40:39 <TrueBrain> It is funny to me, the `a 20-year-old game that tries to remain true to it's roots` is exactly the reason the PR is a good idea; it remains true to the idea cargo payment should keep on decreasing 🙂
13:41:08 <TrueBrain> (sorry, was doing a michi_cc, and reading up on what was actually going on :P)
13:41:47 <TrueBrain> People seem to confuse "remains true to" with "has to be bug-compatible with" 🙂 Would make for a horrible game, if we went for the latter (in my opinion)
13:43:03 <TrueBrain> reminder me of the bug that if you build a tunnel long enough, you gained a lot of money 😄
13:43:10 <TrueBrain> was the best way to get your starter capital ..
13:43:30 <TrueBrain> and that brings us back to the spacebar-as-heater XKCD, I know I know 😛
13:45:01 <TrueBrain> frosch: did you ever finished your WASM blog entry?
13:45:53 <frosch> yes, in my head
13:46:05 <TrueBrain> haha, no, that means you are done with it 😛
13:46:09 <TrueBrain> that is something different 😄
13:46:54 <TrueBrain> mostly curious about the summary of your opinion on it 🙂
13:47:02 <petern> FWIW, "save game compatibility" to me means that we make sure the savegame is loadable and not left in an unusable broken state, not that the savegame continues behaving exactly the same.
13:47:06 <frosch> TrueBrain: the problem is rather, that people want ottd to stay true to the first version they played, which may have been ottd 0.5, 1.0, 1.5 or 1.10
13:47:26 <petern> i.e. "you removed this setting, it's no longer compatible" is junk
13:47:32 <TrueBrain> with enough settings, YOU CAN! (please don't)
13:48:13 <frosch> i can't even count the number of people who refer to opengfx as the "original graphics" 🙂
13:48:59 <petern> Yeah but they're also "pixel graphics" because screens don't use pixels these days?
13:56:28 <DorpsGek> [OpenTTD/OpenTTD] frosch123 commented on pull request #10623: Remove: Settings for NPF & YAPF
13:57:32 <TrueBrain> I was doing a lot of typing for frosch to reply in the same thread .. scared me for a bit 😄
13:57:36 <TrueBrain> but it was just a small remark 😛
13:58:01 <DorpsGek> [OpenTTD/OpenTTD] TrueBrain approved pull request #10623: Remove: Settings for NPF & YAPF
13:58:04 <TrueBrain> still going to do this, but LordAro will understand 🙂
13:59:25 <frosch> oh, you will have to ask lordaro for a pinky promise then :p
13:59:39 <TrueBrain> I trust him 🙂
13:59:59 <TrueBrain> btw frosch , do you have a summary of your WASM opinion? Or any plans of finalizing them? 😛
14:00:14 <TrueBrain> I am just being lazy, trying to avoid making my own opinion
14:01:53 <TrueBrain> owh, keeping `rail_firstred_twoway_eol` is like really super easy .. good 😄
14:02:53 <peter1138> It's on by default these days for whatever reason, does it matter if it's always on?
14:03:14 <petern> Yikes, that was the wrong window!
14:03:25 <TrueBrain> haha, I was about to make some funny comments about it, but I will shut up now 🙂
14:03:45 <frosch> well, there were some considerations on what scripts can run on server-only, in-sync on all machines, and client-only for gui, and how they would store and change state. but my main heureka was: to have callbacks and variables compatible/extensible in future, callbacks should have no parameters and no results, and instead call api methods to get/set individual parameters or results
14:04:26 <TrueBrain> so they just receive events, and act on that, basically?
14:04:35 <TrueBrain> (as a callback with no parameter nor result is just an event)
14:05:17 <frosch> no, that's not what i mean 🙂 it's difficult to explain it in short 🙂
14:05:27 <TrueBrain> so write a blog post! 😛 😄
14:05:28 <TrueBrain> hihi
14:05:38 <frosch> maybe i can make a small example instead
14:06:20 <TrueBrain> please do 🙂
14:07:04 <TrueBrain> the main reason I am poking about this now, is that I kinda fancy what these new timers give: a way to subscribe to events, and act on that. It decouples the code a lot
14:07:23 <TrueBrain> so that brings us to the next question: can we actually push that a bit further, and in some idiotic world, have all economy related stuff in their own module
14:07:47 <TrueBrain> which means: events happen, that module uses an API to read/write the behaviour it wants
14:08:01 <TrueBrain> as that would be an ideal decoupling, and make things a lot more readable/maintenable
14:08:09 *** gelignite has joined #openttd
14:08:38 <TrueBrain> The Window system is pretty much there already; just needs a bit more decoupling to not have an `OnClick` function, but a subscription to click events on specific widgets, for example
14:08:51 <TrueBrain> so yeah, curious where your blog on WASM ended up 😛
14:09:39 <TrueBrain> (I am off for a few hours; so take your time to make an example 😛 😛 😛 :P)
14:12:05 *** CharlieAtlasff03k64 has joined #openttd
14:12:05 <CharlieAtlasff03k64> What is WASM? I keep thinking you are saying WASD, but you are saying to to many times to be a typo.
14:13:39 <frosch> the thing that makes ottd run in a browser, but may also make browser-like things run inside ottd?
14:20:01 <CharlieAtlasff03k64> Oh, interesting.
14:20:24 <CharlieAtlasff03k64> Which one is the goal? I assume running it in a browser?
14:21:40 <frosch> no, that was achieved 5 years ago
14:25:43 <DorpsGek> [OpenTTD/OpenTTD] TheMowgliMan commented on issue #10656: [Bug]: (Not really a bug) Playstyle incompatibility with #10596
14:47:59 *** Wormnest has joined #openttd
14:50:39 <DorpsGek> [OpenTTD/OpenTTD] Kuhnovic updated pull request #10543: Feature: Region-based pathfinder for ships
14:50:50 <frosch> TrueBrain:
14:58:01 <frosch> time for shopping
15:08:32 <Kuhnovic> Alright, I marked my ship pathfinder as ready to be reviewed. It still is a little rough around the edges but it needs a high level evaluation first, and I expect there will be quite a bit of discussion. I want to avoid polishing a turd ;).
15:11:58 <LordAro> Kuhnovic: it's such a good thing i'd almost just merge it and worry about bugs later
15:12:04 <LordAro> almost :p
15:12:09 <DorpsGek> [OpenTTD/OpenTTD] PeterN commented on discussion #10632: OpenTTD Opt-In Automated Survey - Feedback wanted
15:12:35 <petern> Any use for timers in it? 😉
15:12:49 <petern> Hmm, should I put knobs on these pots.
15:13:19 <Kuhnovic> Sounds like you need to get some NE555's petern
15:13:39 <petern> For a proper DIY synth build?
15:14:08 <petern>
15:14:20 <petern> Ew it embeds!
15:15:40 <Kuhnovic> Haha nice! I'm more of a analog guitar FX guy myself, but I do enjoy projects like those!
15:35:55 <DorpsGek> [OpenTTD/OpenTTD] rubidium42 approved pull request #10626: Codechange: Remove alloca usages
15:44:08 <DorpsGek> [OpenTTD/OpenTTD] rubidium42 approved pull request #10627: Change: Use vectors for loading NewGRF specs.
15:44:47 <Rubidium_> now which one of those is going first? As it's definitely going to conflict with the other one
15:49:20 <petern> Which do you prefer, resize() then iterate, or reserve() and push_back...?
15:49:52 <petern> (Latter is probably preferable for large objects, not much difference with bytes :))
15:54:43 <LordAro> petern: i don't like "uninitialised" data in my vectors
15:54:52 <LordAro> even if it is immediately removed
15:54:53 <Rubidium_> I'd go with reserve (saves one initialisation) and emplace_back (saves a copy)
15:55:16 <petern> Okay, then 10626 gets merged first 🙂
15:57:04 <DorpsGek> [OpenTTD/OpenTTD] PeterN merged pull request #10626: Codechange: Remove alloca usages
15:57:06 <LordAro> :)
15:59:08 <petern> I need to update my town name one too as that cheats with resize.
16:02:30 <petern> Hmm, I think resize() for the second commit of 10627 is reasonable, that's a vector of pointers, and due to the way they are fill it's possible there will be gaps anyway.
16:03:02 <petern> The whole reason they are pointers is because they can be undefined.
16:07:10 <petern> Yeah the more I think about it, the more reserve() is correct -- it works the same even if you miss out the reserve.
16:07:27 <petern> er... correct is not the right word.
16:12:56 <petern> Well, we do use resize all over the place but it'll do 😄
16:26:58 *** Wormnest has quit IRC (Ping timeout: 480 seconds)
16:34:07 <DorpsGek> [OpenTTD/OpenTTD] PeterN updated pull request #10631: Codechange: Use std:: features for NewGRF town names.
16:41:26 *** nielsm has joined #openttd
16:53:06 *** Wormnest has joined #openttd
16:58:27 *** tokai has quit IRC (Quit: c('~' )o)
17:03:22 <petern> Hmm, for loading savegames it isn't clear cut, as you need to create an "uninitialized" object, fill it, then push that.
17:54:53 *** Wormnest has quit IRC (Ping timeout: 480 seconds)
18:01:17 *** nebulabc has quit IRC (Quit: No Ping reply in 210 seconds.)
18:03:00 *** nebulabc has joined #openttd
18:03:16 *** Wormnest has joined #openttd
18:06:27 *** nebulabc has quit IRC (Remote host closed the connection)
18:07:28 *** nebulabc has joined #openttd
18:22:16 *** virtualrandomnumber has joined #openttd
18:28:47 *** virtualrandomnumber has quit IRC (Quit: virtualrandomnumber)
18:30:10 <DorpsGek> [OpenTTD/OpenTTD] rubidium42 commented on pull request #10006: Make modifier keys configurable and split Ctrl into remove and function.
18:38:13 <dP> Rubidium, any suggestions for alt problem though? I know it's a bit of an issue but there are only so many modifier keys
18:38:49 <dP> in general there needs to be some ui solution to show estimation and free the modifier key but that's way out of scope of that pr
18:39:56 <DorpsGek> [OpenTTD/OpenTTD] DorpsGek pushed 1 commits to master
18:39:57 <DorpsGek> - Update: Translations from eints (by translators)
18:43:58 *** Wormnest has quit IRC (Ping timeout: 480 seconds)
19:00:05 <LordAro> right, one of my whatsapp groups is busy imploding, so i'm back
19:08:55 *** nielsm has quit IRC (Remote host closed the connection)
19:12:33 *** Wormnest has joined #openttd
19:19:06 <TrueBrain> frosch: I am at variant 1, and pissing my pants
19:19:18 <TrueBrain> what an awesome way of writing 🙂
19:19:34 <Rubidium_> dP: if I knew, I would have suggested that in the PR but sadly I don't
19:20:56 <Rubidium_> I will say that I'm a bit sad that they have taken Alt for moving windows as that means the key's essentially useless in the application
19:22:20 <frosch> i tried to represent the community equally
19:22:37 <TrueBrain> frosch: okay, tnx for the write-up. So that is pretty compatible with an event-subscribe system. Mostly useful for me to know NewGRF conforms to that just fine too 🙂
19:22:57 <TrueBrain> now I want to make my hands dirty on how WASM is executed exactly, as I don't actually understand that part all to well yet 🙂
19:24:12 <frosch> i checked multiple wasm interpreters, most were actually unusable...
19:24:34 <frosch> several were apache licensed, wtf...
19:24:46 <TrueBrain> what is your issue with an apache license?
19:24:58 <frosch> it's gpl incompatible afaik
19:25:15 <TrueBrain> most licenses are, if we include it .. but linking against is a different story 😛
19:29:05 <TrueBrain> but yeah, in general apache license is just annoying
19:30:42 <TrueBrain> LLVM is Apache 2.0, so most derived work is too ... and WASM and LLVM are tight friends 🙂
19:31:49 <TrueBrain> haha, but LLVM has an exception clause if you combine your work with GPLv2 🙂
19:32:45 <TrueBrain> `.. if a court of competent jurisdiction determines that ..` 😄
19:32:56 <petern> Hmm, std::unique_ptr and... .get()
19:33:15 <petern> It's fine, right?
19:33:23 <TrueBrain> basically, GPLv2 wins over the Apache 2.0 license if you combine your GPLv2 software with any parts of LLVM 🙂
19:33:27 <TrueBrain> funny ... licenses ....
19:33:42 <TrueBrain> petern: isn't `get()` implied in many cases of usage? 🙂
19:33:50 <TrueBrain> `->` does it for you, in most cases 😛
19:51:48 <glx[d]> yesterday I had some thinking after some strings were merged then split again due to colour handling in #10613, and could be useful in some cases
19:55:57 <LordAro> glx[d]: i'm tempted to say that there should be no colour codes in the language files at all
19:56:04 <LordAro> probably not font sizes either
19:56:33 <LordAro> why should the languages get to decide what colour things are?
19:57:15 <LordAro> if a string needs to vary colour for a word/substring, it should probably be a stringid parameter to that string (but frankly it probably shouldn't)
19:57:39 <Eddi|zuHause> LordAro: problem is, the language must decide where the colour changes are, in case words get switched around and stuff
19:58:17 <dP> glx[d]: would be kind of handy for gamescripts even though it's doable already by just nesting strings
19:58:37 <LordAro> Eddi|zuHause: yeah, hence any possibility of that and it should be a parameter instead
19:58:43 <glx[d]> I used a GS to test it 😉
19:58:56 <dP> exposing colour ids is kind of questionable idea though
19:59:41 <Eddi|zuHause> LordAro: but for example, a string makes a "NOT" coloured for emphasis, then a french string must make a "NE" and a "PAS" tht other colour, in two separate locations
20:00:08 <glx[d]> with push and pop 😉
20:00:31 <glx[d]> push red NE pop ... push red PAS pop
20:01:22 <LordAro> e.g. why not set the string itself as black, then velocity & type parameters as blue
20:01:25 <glx[d]> all strings are light blue by default
20:01:56 <petern> Cos you need velocity and other things in different colours elsewhere
20:02:04 <LordAro> yeah, but they're parameters
20:02:10 <LordAro> the code sets the parameters much the same way
20:02:45 <petern> SetDParam(0, v->GetMaxSpeed(), LightBlue);
20:02:49 <petern> Hmm
20:02:56 <LordAro> yeah
20:03:03 <LordAro> and/or font size
20:03:35 <LordAro> i assume there are no strings where the font size varies within a single string though
20:03:59 <glx[d]> font size is used for font check
20:04:19 <glx[d]> (doesn't work very well because fallback is weird)
20:04:39 <Eddi|zuHause> a thing i can imagine, we have these {STRINGn} codes which are forbidden in languages other than english, what if we similarly replace all explicit colour codes with {COLOUR}, and allow repeating or flipping with {COLOUR:0} {COLOUR:1} etc?
20:04:45 *** Wormnest has quit IRC (Ping timeout: 480 seconds)
20:08:25 <glx[d]> dP: only the 16 useful values from the enum are exposed
20:09:23 <glx[d]> and it's just to simplify GS authors life as the parameter value is a number in 0-16 range
20:09:51 <glx[d]> easier to use an enum than the number itself
20:11:42 <glx[d]> btw enum could be simply named Colour, and TC_ prefix can be removed too, as the usage will be GSText.TC_RED anyway
20:12:47 <dP> but RGB text! xD
20:13:05 <dP> but, anyway, they're already exposed
20:13:23 <dP> as company colours at the very least
20:13:33 <glx[d]> not the same colours
20:13:35 <glx[d]> IIRC
20:14:33 <dP> hm, yeah, they're different
20:14:35 <dP> "fun"
20:15:13 <petern> RGB colours is a thing in my branch... 😄
20:15:53 <petern> But also, only for company colours, so doesn't affect the 17 text colours.
20:16:58 <dP> glx[d]: text colours too: <>
20:18:02 <glx[d]> oh didn't though they could be in GSWindow
20:27:10 <petern> Yay, it built.
20:27:15 <petern> It doesn't run, but it built.
20:29:20 <petern> Ah, [hid + 1] is not the same as [hid + i]
20:32:57 <glx[d]> it's the same at least once 😉
20:37:03 <petern> It's never the same, because it always crashes the first time 🙂
20:37:16 <petern> Hmm, +175-295. Not too bad, but not amazing.
20:47:35 <DorpsGek> [OpenTTD/OpenTTD] PeterN dismissed a review for pull request #10627: Change: Use vectors for loading NewGRF specs.
20:47:38 <DorpsGek> [OpenTTD/OpenTTD] PeterN updated pull request #10627: Change: Use vectors for loading NewGRF specs.
20:48:44 *** Wormnest has joined #openttd
20:57:54 *** keikoz has quit IRC (Ping timeout: 480 seconds)
21:14:32 <DorpsGek> [OpenTTD/OpenTTD] rubidium42 approved pull request #10627: Change: Use vectors for loading NewGRF specs.
21:41:28 *** Wormnest has quit IRC (Ping timeout: 480 seconds)
22:09:57 *** Wormnest has joined #openttd
22:12:31 *** sla_ro|master has quit IRC ()
22:13:44 *** sla_ro|master has joined #openttd
22:54:20 *** irsyadano has joined #openttd
22:54:53 <irsyadano> hi!
22:56:05 *** irsyadano has quit IRC ()
23:00:00 <DorpsGek> [OpenTTD/OpenTTD] Eddi-z commented on pull request #10623: Remove: Settings for NPF & YAPF
23:02:40 *** Wormnest has quit IRC (Ping timeout: 480 seconds)
23:21:40 *** sla_ro|master has quit IRC ()
23:33:40 *** gelignite has quit IRC (Quit: Stay safe!)
23:42:46 <DorpsGek> [OpenTTD/OpenTTD] Eddi-z commented on issue #10652: [Bug]: Transfer income does not add to cash
23:45:41 *** Wormnest has joined #openttd
23:58:10 *** Flygon has quit IRC (Quit: A toaster's basically a soldering iron designed to toast bread)