IRC logs for #openttd on OFTC at 2021-07-08
⏴ go to previous day
00:05:41 *** tokai|noir has joined #openttd
00:05:41 *** ChanServ sets mode: +v tokai|noir
00:12:30 *** tokai has quit IRC (Ping timeout: 480 seconds)
00:22:01 <DorpsGek> [OpenTTD/OpenTTD] glx22 opened pull request #9418: Codechange: Don't explicitly unset _generating_world outside of genworld.cpp https://git.io/Jc96s
00:22:39 <glx> doesn't fix anything, but I prefer this way
00:23:56 <Eddi|zuHause> nobody ever worked on completely removing all those global variables and do proper encapsulation?
00:24:38 <glx> not easy, _generating_world is somehow abused in some places
00:25:31 <glx> to fake world generation while not really generating
01:21:52 *** WormnestAndroid has joined #openttd
02:09:09 *** ChanServ sets mode: +v tokai
02:16:00 *** tokai|noir has quit IRC (Ping timeout: 480 seconds)
02:46:18 *** godbed has quit IRC (Ping timeout: 480 seconds)
03:12:34 *** Gustavo6046 has quit IRC (Remote host closed the connection)
03:13:16 *** Gustavo6046 has joined #openttd
03:16:26 *** Gustavo6046 has quit IRC ()
03:18:42 *** Gustavo6046 has joined #openttd
04:14:10 *** tokai|noir has joined #openttd
04:14:10 *** ChanServ sets mode: +v tokai|noir
04:20:55 *** tokai has quit IRC (Ping timeout: 480 seconds)
04:23:35 *** andythenorth has joined #openttd
04:29:29 *** Wuzzy has quit IRC (Quit: Wuzzy)
05:28:16 *** andythenorth has quit IRC (Quit: andythenorth)
05:35:36 *** andythenorth has joined #openttd
07:17:39 *** ChanServ sets mode: +v tokai
07:24:25 *** tokai|noir has quit IRC (Ping timeout: 480 seconds)
07:37:57 <TrueBrain> lol, nightly still fails :P
07:38:44 <TrueBrain> OpenTTD has grown too big for it, time to remove some functionality :P
07:46:30 <TrueBrain> still cannot believe "static const std::string" does a malloc on startup .. I just assumed it would optimize that
07:51:25 <Eddi|zuHause> my thought would go in the direction of a buffer overflow mitigation where addresses are randomized
07:59:43 *** WormnestAndroid has quit IRC (Ping timeout: 480 seconds)
08:05:41 <TrueBrain> removing a bunch of settings does solve the MacOS build again
08:06:08 <TrueBrain> I would guess building does work on people with more memory in their system
08:09:22 *** andythenorth has quit IRC (Quit: andythenorth)
08:09:40 <Eddi|zuHause> whenever i run out of ram the first thing i try is add swap
08:10:34 <TrueBrain> lol, the "strace" of MacOS ("dtruss") doesn't work because of system protections
08:10:36 <TrueBrain> that is ... useful?
08:27:34 *** WormnestAndroid has joined #openttd
08:35:52 <orudge> TrueBrain: FWIW, it fails on my MacBook Pro with 16GB RAM
08:36:09 <TrueBrain> tnx, I was curious about that, so that is much appreciated
08:36:45 <TrueBrain> I do not really know how we can further zoom in to the real issue here .. "too many settings" is the obvious answer
08:37:00 <TrueBrain> but I do not understand conceptually why having a static const list of items is ever an issue :P
08:42:47 <DorpsGek> [OpenTTD/OpenTTD] LordAro commented on pull request #9418: Codechange: Don't explicitly unset _generating_world outside of genworld.cpp https://git.io/JcHAZ
08:45:01 <LordAro> TrueBrain: compilers have limitations :p
08:45:28 <TrueBrain> LordAro: not sure how that zooms in on the actual problem ;)
08:46:12 <Eddi|zuHause> have you tried filing it as a compiler bug? :)
08:46:34 <LordAro> we had a cpp file at work that failed to compile with (iirc) -ggdb3 due to having "too many sections"
08:48:10 <Eddi|zuHause> "limitation disturbs me very memory. goes it throw out limitation?"
08:55:14 <LordAro> Has anyone really been far even as decided to use even go want to do look more like?
08:58:19 <TrueBrain> should we call an ambulance? Seems you are having a stroke :s
09:02:08 *** D-HUND is now known as debdog
09:06:28 *** kgarza_ has joined #openttd
09:13:58 *** kgarza has quit IRC (Ping timeout: 480 seconds)
09:48:37 <TrueBrain> yippie, finally managed to integrate master-server and game-coordinator, so they both show the full list of all servers
09:49:06 <TrueBrain> for some reason only my client thinks he can join the server ... while the versions mismatch :P
09:49:14 <TrueBrain> guess something is not validating revisions correctly now :)
10:02:29 <Samu> this last commit, spanish_mx translations seems to be wrong
10:02:53 <Samu> I read some english in some of the strings
10:04:03 <LordAro> looks like they forgot to delete the original english
10:04:11 <LordAro> translator will pick it up when they notice
10:07:58 <DorpsGek> [OpenTTD/OpenTTD] TrueBrain opened pull request #9419: Fix 9e32c618: network revision was always empty https://git.io/JcQY3
10:08:41 <TrueBrain> I just blame Rubidium , okay? Not like I did the review or anything :D
10:11:21 <Eddi|zuHause> rule #1: always have someone else to blame :p
10:11:57 <Rubidium> yeah, why didn't the build check find that?
10:14:15 <Rubidium> and why doesn't lgtm warn about it?
10:22:32 <DorpsGek> [OpenTTD/OpenTTD] LordAro approved pull request #9419: Fix 9e32c618: network revision was always empty https://git.io/JcQsW
10:23:26 *** tokai|noir has joined #openttd
10:23:26 *** ChanServ sets mode: +v tokai|noir
10:29:19 <DorpsGek> [OpenTTD/OpenTTD] TrueBrain merged pull request #9419: Fix 9e32c618: network revision was always empty https://git.io/JcQY3
10:30:20 *** tokai has quit IRC (Ping timeout: 480 seconds)
10:36:59 *** kgarza__ has joined #openttd
10:43:57 *** kgarza_ has quit IRC (Ping timeout: 480 seconds)
10:55:52 <TrueBrain> Rubidium: all I hear are excuses :P :P :P :P
10:56:24 <TrueBrain> if I remember correctly this was a last minute change :) And clearly neither of us really tested it :P What can I say .. :D
11:21:06 <Samu> retesting my AI in a 512x512 map, with the new townManager code rework, really building routes, and autosaving monthly
11:21:26 <Samu> I no longer expect "too long to save"
11:48:35 <Belu> hi, anyone knows how to disable this missing option in the latest version ? Deliver cargo to a station only when there is a demand, so that the passengers cargo etc can be already be available on the station so the first train / truck / ship etc, so the first vehicle don't loose time in vane ?
11:55:01 <glx> It's doable via console or in config file belu
11:56:17 <Belu> the console I saw in the help menu, but no ideea how and what command to use
11:57:29 <Belu> I did this manually in the openttd.cfg - (selectgoods = <true|false>)
11:57:45 <Belu> set to false and nothing changed
11:57:55 <glx> The command is 'set order.selectgoods'
11:58:12 <glx> Config doesn't apply to save games
11:58:33 <Belu> where do i find all these commands ?
12:03:13 <glx> But the setting list is very long and I don't think it's on the wiki
12:03:13 <Belu> did not found these commands on that page set order.selectgoods
12:03:26 <Belu> so it's not a complete list...
12:03:36 <LordAro> it's an argument to the 'set' command
12:03:49 <LordAro> but it's probably not a complete list anyway
12:04:07 <Belu> ok so what do i have to write in the console to disable the Deliver cargo to a station only when there is a demand
12:05:18 <LordAro> `set order.selectgoods` to show what it is already
12:05:30 <LordAro> then `set order.selectgoods true` to set it
12:05:36 <LordAro> (or false, depending what the desired option actually is
12:06:39 <Belu> I've been searching these things all over google and forums but no success, so if there isn't a full webpage specifying all these, the user can think there is no more option, and can go back a couple of versions older
12:06:54 <LordAro> they're hidden for a reason
12:06:57 <glx> Argument to 'set' is easy to find when looking at openttd.cfg
12:07:04 <Belu> why was removed this option from v 0.4.7 in the first place ?
12:07:28 <Belu> newer not always the better
12:07:36 <glx> It's not removed, but the default is weird
12:08:13 <Belu> it is removed as long it's unfindable in the user interface menu
12:08:19 <glx> We have too many settings, so some are hidden
12:08:29 <Belu> in the old version there is a button configure patches
12:09:09 <Belu> people do have 24 inch monitors these days and scrolls, so don't understand why the need to dumb down user interfaces
12:09:36 <LordAro> the settings window is far, far beyond fitting on a 24 inch monitor
12:10:07 <Belu> the laziness of putting the options i assume
12:10:23 <glx> BTW I disagree for some of the hidden settings, but most of them are hidden for a good reason
12:10:37 <Belu> not to be user personalizable
12:10:46 <Belu> same as windows 10 not to be update disabled
12:10:59 <Belu> so people have mandatory updates same as NWO
12:11:11 <LordAro> settings are hard to maintain, as many can interact and break the game in completely unforeseen ways
12:11:37 <LordAro> therefore, we've started to try to remove / hide settings where possible, when literally 99.99% of players never touch them
12:11:47 <LordAro> and certainly avoid adding new ones
12:11:53 <Belu> i was touching that option
12:12:25 <glx> It's a one time set option usually
12:12:35 <LordAro> glx: no no, we're just lazy
12:13:09 <glx> We should maybe change its default to true
12:14:03 <LordAro> very few players micromanage to the extent that they care about the first arrival not picking up any cargo (if not full load)
12:15:08 <LordAro> though the station window could do with a "supplies" line, like it does when creating the station
12:15:54 <LordAro> as bug reports go, "game has changed in the last 15 years" isn't a great one
12:19:07 *** WormnestAndroid has quit IRC (Ping timeout: 480 seconds)
12:19:52 *** glx is now known as Guest192
12:19:52 *** ChanServ sets mode: +v glx_
12:20:15 *** Guest192 has quit IRC (Quit: Quit)
12:21:15 *** WormnestAndroid has joined #openttd
12:23:18 <Timberwolf> I find it fascinating nobody has ever gone back and done that kind of openttdcoop "what works and what doesn't when you have 2000 trains" thing for all the changes in the last 15 years or so.
12:23:55 <TrueBrain> Lol, that user was funny :D
12:24:07 <glx> easy, the game is too slow to run with 2000 trains ;)
12:24:19 <Timberwolf> So much of the ideas and designs since then are actually myths or misinterpretations of what's actually going on.
12:25:40 <TrueBrain> BTW, I always assumed those settings are hidden because we still need/want to support savegames that have them on a different value but nobody should do that for new games :p
12:25:57 <LordAro> that's often the case
12:26:39 <glx> many are dangerous to modify (like pf stuff)
12:27:04 <TrueBrain> Those pf settings should die in a burning fire
12:27:14 <TrueBrain> Nothing good ever comes from changing them :p
12:28:01 <TrueBrain> Possible MacOS builds if we remove them >:D
12:28:12 *** snail_UES_ has joined #openttd
12:28:19 <Venemo> Whoah, that guy was pretty rude
12:28:25 <Timberwolf> I think there's a wiki page somewhere saying something along the lines of, "these settings were arrived at after great pain, don't change any of them"
12:29:14 <glx> TrueBrain: maybe we should enclose settings static array in some InitSettings() function so it's no longer in global scope
12:32:26 <TrueBrain> Will try that out later today, as I can reproduce the issue via VMWare :)
12:32:44 <glx> ah finally able to reproduce it :)
12:33:12 <TrueBrain> I could all this time, that is why I knew solving the GCC issues solved the MacOS issue
12:33:25 <TrueBrain> Just it is very painful to use the VM :p
12:33:46 <glx> and as slow as building a release outside the VM
12:34:41 *** snail_UES_ has quit IRC (Quit: snail_UES_)
12:35:13 <TrueBrain> Still, the pf settings ... there are like 50 of those .. like.. why?!
12:35:26 <TrueBrain> And still some values are hardcoded :p
12:35:34 <LordAro> turn them into constants, the compiler will be able to optimise better
12:35:39 <LordAro> make YAPF even faster!
12:35:57 <TrueBrain> I personally think that is the right thing to do
12:36:08 <TrueBrain> But some users will have broken savegames because of it
12:45:45 <Samu> reached 100 years without crashing
12:46:07 <Samu> that's about 26% of allowed time, awesome
12:48:49 <Samu> new goal, reach 5k rvs, 5k ships, 5k aircraft
12:51:30 <peter1138> Oh, we haven't fixed that yet.
12:54:26 <Samu> autosaves are 45 MB's each
12:54:46 <Samu> now i have a SSD, rip endurance
12:55:41 <Samu> question, is it possible to multithread lzma saves?
12:55:50 <Samu> single thread is kinda slow
12:56:27 <peter1138> Just perform multiple saves at once.
12:56:28 <glx> saving is threaded (the writing to disk part)
12:57:03 <Samu> i mean compressing using all threads available
12:57:11 <Samu> i got 16 now with this cpu
12:57:11 <NGC3982> how is openttd on m1:s?
12:57:26 <glx> not compilable NGC3982 ;)
12:57:41 <glx> (but applies to x86_64 too)
12:58:22 <Samu> i suspect im gonna run out of station ids
12:58:33 <Samu> between buoys, docks, airports, road stations
12:59:44 <NGC3982> glx: what applies to x86_64?
13:00:03 <Samu> probably not as a single AI running, but if there are 15 AIs... i suspect it will reach
13:00:03 <glx> failing to build for MacOS
13:00:04 <LordAro> NGC3982: macOS gcc is currently falling on its face when trying to compile OTTD in general
13:00:24 <LordAro> not our fault, technically speaking
13:02:48 <NGC3982> will openttd fix it, or will you wait for macos to ..mend itself?
13:03:14 <LordAro> we're working on potential solutions
13:03:16 <glx> we will try to work around (again)
13:03:19 <LordAro> well, we have done, twice already
13:03:22 <LordAro> but will continue to do so
13:04:07 <glx> LTO is very slow, and we don't have the hardware ;)
13:09:38 <peter1138> Well I guess that's a reason not to get a Mac then.
13:10:14 <glx> decided to time the release build with wsl (-j6): ~30m
13:11:01 <LordAro> could just disable LTO for macOS :p
13:17:01 <glx> Samu: ~2000 stations tiles/airport, you're far from 64000 real stations
13:19:17 <glx> I don't think you use 60 buoys per ship ;)
13:22:00 <Samu> @calc (218 + 186) * 2 + (372 / 2) + 664
13:22:28 <Samu> @calc (218 + 186) * 2 + 372 + 664
13:23:15 *** WormnestAndroid has quit IRC (Ping timeout: 480 seconds)
13:24:08 *** WormnestAndroid has joined #openttd
13:38:03 <Samu> hmm the AI occasionally get "Couldn't build the aircraft"
13:39:02 <Samu> maybe i should improve my Loan feature
13:40:36 <Samu> i have enough money in the test command, but not when buying it in the exec command
13:40:53 <Samu> and running costs of other vehicles getting in the way
13:41:49 <glx> yup test and exec are 1 frame appart
13:42:03 <glx> or more, depending on your code
13:46:44 <Samu> i wish there was an "auto-loan on demand" command. I did this in the ai code, but apparently it's flawed due to being frame aparts
13:48:41 <NGC3982> i tried that with my bank but for some reason they didnt follow
13:55:18 <Samu> yay, AI started building statues
14:09:07 <glx> and with const auto &GetSettingsTable() ?
14:09:25 <LordAro> function static variables aren't really any different to global variables, from a compiler perspective, i would think?
14:09:48 <TrueBrain> LordAro: at least in godbolt it renders different assembly
14:10:30 <glx> it should have less tracking to do if they are scoped, even if they are still "global"
14:11:15 <LordAro> depends quite why it's failing, might be completely unrelated to global variables
14:11:35 <TrueBrain> it still feels related to what GCC was complaining about, which was "too many variables to track"
14:11:47 <TrueBrain> it was hitting a few millions (!) variables it was tracking
14:12:28 <TrueBrain> glx: "auto" is a bit difficult, as the function is in a header ;)
14:13:01 <glx> hmm but the header is used only in one place, so maybe it can be static
14:14:07 <glx> but my idea is to return a reference
14:14:19 <TrueBrain> how would a reference differ from an span?
14:14:34 <TrueBrain> (SettingTable is a span)
14:15:17 <TrueBrain> if anything is going to help a compiler, is the fact the table itself is never used anymore; only spans pointing to it :)
14:16:12 <TrueBrain> removing a bunch of settings does fix the issue still btw
14:17:39 <TrueBrain> for example, removing all "pf" settings does the trick :P
14:18:46 <TrueBrain> just a random example ;)
14:18:48 <Samu> so, this is why you're against adding settings
14:19:13 <glx> now we already have to many settings :)
14:19:26 <glx> but now we also have a good excuse :)
14:20:20 <glx> (and a missing "o" somewhere)
14:23:46 <TrueBrain> I still think it is weird that the assembly show the dtor of these kind of tables, but it is dead code
14:23:52 <TrueBrain> there is nothing jumping into the block
14:27:45 <TrueBrain> even with -O3, code that is unreachable is still there
14:29:04 <TrueBrain> it is marked as "cold", so it does know it is very unlikely that it will be executed
14:29:08 *** WormnestAndroid has quit IRC (Ping timeout: 480 seconds)
14:29:14 <TrueBrain> but given there is no jump label .. I would argue it is impossible it is executed :D
14:29:30 *** WormnestAndroid has joined #openttd
14:35:04 <Samu> hmm 77k ops for saving atm, it's getting scary
14:35:19 <Samu> guess i'll have to optimize other parts of the code
14:48:36 *** virtualrandomnumber has joined #openttd
14:48:47 *** virtualrandomnumber has quit IRC ()
14:53:12 *** gelignite has joined #openttd
14:56:26 <TrueBrain> luckily enough for us I made possible that we can change the order of settings, so that is in fact possible .. but that change currently fails as the saveload doesn't know about the extra tables ;)
14:56:40 <TrueBrain> at least it compiles
14:58:47 <peter1138> Is it not merged yet?
14:59:02 <TrueBrain> hence: luckily for us
14:59:25 <TrueBrain> yes, the URL I linked doesn't work correctly
14:59:41 <TrueBrain> because .. the saveload doesn't know about the extra table yet :P
14:59:50 <glx> TrueBrain: GetSettingSaveLoadByPrefix() may have some issues, as pf is removed from it's list
15:00:07 <TrueBrain> that function is basically: GiveMeTheLinkGraphSettingsNOWWWWWWW
15:00:55 <TrueBrain> peter1138: "that change" was referring to the link, not the saveload header stuff :D Stupid English language and its unclear references :P
15:03:49 <TrueBrain> right, now saveload does work (reload if you like) ... see if MacOS still compiles happily ..
15:05:00 <TrueBrain> still works .. okay, so this seems to be a solution ..
15:06:26 <TrueBrain> the good thing is that I have been willing to do this for a while now, but I couldn't find a good motivation to do so :P
15:06:43 <peter1138> Do our Mac users not experience this issue?
15:07:01 <peter1138> Or does no dev use Mac any more. Hmm.
15:07:13 <TrueBrain> peter1138: well, we never really had a dev that used a Mac
15:07:20 <TrueBrain> just one that made the game work on a Mac via VMWare :P
15:07:21 <glx> and mac users don't build
15:07:30 <TrueBrain> but as mister o confirmed earlier today, he cannot build master either :)
15:07:30 <peter1138> So I should buy a MacBook Air?
15:08:05 <TrueBrain> glx: nice solution :)
15:08:20 <peter1138> £999 for 256GB SSD, £1249 for 512GB SSD, that is some super-inflated pricing...
15:08:54 <TrueBrain> okay, the function trick is not needed, after some additional testing
15:08:58 <TrueBrain> the splitting alone seems sufficient
15:09:21 <peter1138> Oh, just noticed from 7 to 8 core GPU too. Whatever a GPU core means in this world. My RTX2080ti has " a few " more.
15:09:24 <TrueBrain> right, after dinner I will make a proper PR for it ..
15:09:46 <TrueBrain> will split some more settings into their own table while at it
15:10:00 <glx> ideally we should not use tables, but not easy for settings (auto registering won't work as there's multiple tables)
15:11:54 <TrueBrain> assembly wise, your approach also still adds dtor calls (that are not reachable)
15:12:13 <TrueBrain> still no clue why it does that :P
15:12:15 <peter1138> Oh gods, an extra 8GB RAM is £200 !?!
15:12:28 <TrueBrain> haha, it seems peter1138 never looked at Mac prices before :D
15:12:52 <glx> dtor calls make sense, as the objects are constructed
15:12:52 <LordAro> soldering RAM chips onto the MB costs money
15:13:20 <peter1138> I thought the 16GB upgrade for my little server was too much, that was about £60 for the full 16GB.
15:13:40 <glx> but yeah they will be destroyed at exit anyway
15:13:43 <TrueBrain> glx: sure, but never destructed. Which it does figure out, as it marks the sections as "cold" (unlikely to be called)
15:13:50 <TrueBrain> but for some reason it doesn't notice that it is NEVER called :)
15:15:11 <Rubidium> although... maybe remove them from Setting and get them from SaveLoad instead (if they're the same)
15:15:33 <TrueBrain> Rubidium: remember that as one of my first solutions when we started this whole stuff? :)
15:15:51 <TrueBrain> but for example the "std::shared_ptr<SaveLoadHandler> handler" also adds a dtor
15:15:54 <TrueBrain> creating a very similar issue
15:16:12 <TrueBrain> I think that splitting of the settings table is more useful at this point in time
15:16:39 <Rubidium> what I remember was passing string_view to the constructors but the type in the object still being string
15:16:46 <LordAro> splitting settings.ini into mildly more logical groups would be nice, for sure
15:16:55 <TrueBrain> my very first version made the type a std::string_view too Rubidium :)
15:16:55 <LordAro> it is impossible to find anything in it right now
15:16:57 <TrueBrain> but you were against that :P
15:19:12 <TrueBrain> from what I understand currently, we either have to make sure SaveLoad / SettingDesc is a "constexpr", or we need to split up the settings table
15:19:24 <TrueBrain> (changing std::string into std::string_view allows the table to be a constexpr, to be clear)
15:19:46 <TrueBrain> I think the splitting is the more practical solution, seen that it works
15:20:10 <TrueBrain> "fun" fact, I tried splitting the settings table before, but it wasn't working .. only the splitting of the files Rubidium did earlier allows it to work ..
15:20:21 <TrueBrain> so many small things combined seems to result in a fix for MacOS :P It is funny :)
15:21:05 <Rubidium> hmm, guess my memory sucks then...
15:21:19 <TrueBrain> we still like you for who you are anyway :)
15:22:55 <TrueBrain> what does C++20 solve in all of this? :)
15:23:14 <Rubidium> constexpr std::string and std::vector
15:23:27 <TrueBrain> that wasn't implemented in any compiler yet, was it?
15:24:19 <Rubidium> I doubt all this splitting up things really helps in the long term. After all, it is the LTO step that breaks right? So I'm not seeing how splitting things reduces the amount of stuff the LTO optimization step needs to keep track of
15:24:51 <TrueBrain> so ..... what can I say :)
15:26:01 <TrueBrain> constexpr std::string is only supported by MSVC still
15:26:25 <TrueBrain> anyway, splitting of settings is a good thing either way, and if that solves MacOS for now ... at least that might mean we get a nightly again :D
15:27:35 <glx> and a logical grouping for when you need to find xxx.yyy setting in the big INI file
15:27:48 <TrueBrain> yeah, I have a draft for it .. I might have gone overboard a bit
15:27:53 <TrueBrain> but I ended up with 10 settings-files
15:28:07 <LordAro> if it's less than 1 ini per setting, then it's probably fine
15:28:26 <TrueBrain> things like: linkgraph, gui, news_display, pathfinder, script, ...
15:28:38 <TrueBrain> basically the logic group they are already in :P
15:29:02 <glx> yeah they are in the config file anyway :)
15:29:14 <TrueBrain> but okay, dinner first .. PR after :D
15:32:24 <Samu> 89451 ops used to save, so close to the limit
15:44:58 *** Progman has joined #openttd
15:55:31 <glx> can't find a way to keep #var Rubidium?
15:55:35 *** gelignite has quit IRC (Quit: Stay safe!)
15:56:05 <Samu> 93718 ops needed to save, im afraid i wont reach 5000ships
16:00:55 <Rubidium> glx: maybe; first step is to see whether this might work, before investing a lot of work into something that's not worth it
16:04:34 <TrueBrain> Rubidium: no, haven't had my dinner yet ... making it takes for ever for some reason :P
16:04:40 <TrueBrain> but MacOS builds with your PR
16:04:52 <TrueBrain> (once again confirming we are just doing too many ctor/dtor stuff :P)
16:05:46 <Rubidium> glx: though it might be a PITA when there are settings with a different #var than their name
16:06:41 <Rubidium> as that would mean savegame mayhem, which would be quite annoying
16:07:57 <glx> ah yes empty name is an exception
16:11:28 *** WormnestAndroid has quit IRC (Ping timeout: 480 seconds)
16:31:57 <Rubidium> there are two savegame fields that are troublesome... gui.sg_full_load_any and gui.sg_new_nonstop
16:34:28 <Rubidium> they are already stored as that in the savegame, whereas the name from SaveLoad would include '_settings_client.'. The ten others are no problem, as they are only transient during loading old savegames
16:34:52 <Rubidium> so renaming them won't harm anybody
16:39:11 <Rubidium> though practically they do not even need to be renamed...
16:41:17 *** Progman has quit IRC (Remote host closed the connection)
17:06:46 <Samu> btw, the reload command works in a strange way
17:07:14 <Samu> i load a game x, then i save a little later
17:07:27 <Samu> when i type reload, it loads the little later game, and not x
17:07:40 <Samu> is that how's it supposed to work?
17:08:54 <glx> hmm I think it uses a global variable for the name, and it's shared between save and load
17:09:10 <glx> so on reload it uses whatever is in the global
17:10:02 <DorpsGek> [OpenTTD/OpenTTD] TrueBrain opened pull request #9420: Fix: reduce the amount of debug messages on -dsl=2 https://git.io/Jc7EA
17:10:23 <glx> yup it uses _file_to_saveload
17:13:31 <DorpsGek> [OpenTTD/OpenTTD] glx22 approved pull request #9420: Fix: reduce the amount of debug messages on -dsl=2 https://git.io/Jc7uK
17:14:09 <DorpsGek> [OpenTTD/OpenTTD] TrueBrain opened pull request #9421: Codechange: split settings.ini over several files https://git.io/Jc7uM
17:14:38 *** andythenorth has joined #openttd
17:15:24 <TrueBrain> let's confirm it actually also address the MacOS issue .... yeah, it does \o/ :D
17:15:30 <glx> TrueBrain: "senisible" ? (in commit detailled message)
17:15:58 <TrueBrain> you don't think that is senisible? :P :P
17:16:08 <DorpsGek> [OpenTTD/OpenTTD] TrueBrain updated pull request #9421: Codechange: split settings.ini over several files https://git.io/Jc7uM
17:18:33 <TrueBrain> it is nice how you slowly see this setting-stuff being untangled by all kinds of small PRs over the last few weeks :) Really nice :)
17:19:13 <TrueBrain> in theory I could now very easily make that you can save presets to a separate file, and allow loading it in too.
17:21:34 <DorpsGek> [OpenTTD/OpenTTD] TrueBrain updated pull request #9421: Codechange: split settings.ini over several files https://git.io/Jc7uM
17:22:37 <TrueBrain> (as all those settings should now be in "world_settings" ;) )
17:24:43 *** snail_UES_ has joined #openttd
17:24:51 <glx> may I suggest to rename GetSettingSaveLoadByPrefix() ?
17:29:53 <TrueBrain> you can suggest ANYTHING :P
17:31:04 <DorpsGek> [OpenTTD/OpenTTD] TrueBrain merged pull request #9420: Fix: reduce the amount of debug messages on -dsl=2 https://git.io/Jc7EA
17:31:45 <DorpsGek> [OpenTTD/OpenTTD] TrueBrain updated pull request #9421: Codechange: split settings.ini over several files https://git.io/Jc7uM
17:34:25 *** Flygon has quit IRC (Quit: A toaster's basically a soldering iron designed to toast bread)
17:35:42 <DorpsGek> [OpenTTD/OpenTTD] rubidium42 opened pull request #9422: Codechange: roughly half number of strings for settings https://git.io/Jc7ao
17:36:00 <Rubidium> sadly that conflicts with #9421 ;(
17:37:41 <TrueBrain> yeah ... and I think you can resolve your conflict easier, for some reason :P
17:37:48 <TrueBrain> so I would appreciate it the lower number goes first :P
17:46:03 <Samu> 'arrays' use less ops for saving than 'tables'
17:46:39 *** yeoldetoast has quit IRC (Quit: My Mac Mini has gone to sleep. ZZZzzz…)
17:50:37 <DorpsGek> [OpenTTD/master-server] TrueBrain opened pull request #35: Feature: redis support as database backend https://git.io/Jc7rO
17:51:10 <DorpsGek> [OpenTTD/game-coordinator] TrueBrain opened pull request #5: Add: small tweaks so the Game Coordinator understands Master Server data https://git.io/Jc7rW
17:51:28 *** snail_UES_ has quit IRC (Quit: snail_UES_)
17:51:46 <TrueBrain> still need to do a lot of worst-case testing, but that I will do this weekend :)
17:58:40 <Samu> strange, i can load a a table as if it were an array? squirrel is weird at times
18:00:58 <DorpsGek> [OpenTTD/game-coordinator] TrueBrain updated pull request #5: Add: small tweaks so the Game Coordinator understands Master Server data https://git.io/Jc7rW
18:12:06 *** snail_UES_ has joined #openttd
18:21:10 *** Progman has joined #openttd
18:47:01 <DorpsGek> [OpenTTD/OpenTTD] rubidium42 commented on pull request #9421: Codechange: split settings.ini over several files https://git.io/Jc7yW
18:50:38 *** WormnestAndroid has joined #openttd
18:52:00 <DorpsGek> - Update: Translations from eints (by translators)
18:53:08 <Samu> reduced from 99600 ops to 89200 ops by changing some tables into arrays
19:01:34 <DorpsGek> [OpenTTD/OpenTTD] TrueBrain commented on pull request #9421: Codechange: split settings.ini over several files https://git.io/Jc79B
19:02:18 *** gelignite has joined #openttd
19:02:23 <DorpsGek> [OpenTTD/OpenTTD] TrueBrain updated pull request #9421: Codechange: split settings.ini over several files https://git.io/Jc7uM
19:02:48 *** WormnestAndroid has quit IRC (Ping timeout: 480 seconds)
19:03:08 *** WormnestAndroid has joined #openttd
19:07:21 <TrueBrain> and what colour shall we paint the shed today :D
19:17:40 <glx> don't look at squirrel 3 doc, it's not compatible with squirrel 2
19:19:01 <Rubidium> TrueBrain: transparent?
19:19:49 <TrueBrain> pretty sure that is not considered a colour ;)
19:23:14 <peter1138> LordAro, turns out that 20-30 psi on a road tyre wasn't optimal. Perhaps I should check more often :D
19:24:02 <peter1138> Chunky 35mm touring tyres, so they can cope, but...
19:25:47 <andythenorth> I think my tyres are about that right now
19:26:31 <andythenorth> I hit the rims going up kerbs right now
19:26:39 <andythenorth> pinch flat just waiting to happen
19:48:45 *** nielsm has quit IRC (Ping timeout: 480 seconds)
19:58:12 *** jottyfan has joined #openttd
20:02:57 <TrueBrain> Would be nice to get this done soon, as rebasing this PR is not much fun ...
20:07:23 *** WormnestAndroid has quit IRC (Ping timeout: 480 seconds)
20:10:13 *** WormnestAndroid has joined #openttd
20:15:22 <Samu> how do I iterate a table?
20:18:04 <Samu> i wanna iterate the 'keys' in a table
20:20:33 <Samu> and if I can't, I'm doomed, can't make this save stuff simpler
20:28:42 <glx> an array doesn't have keys
20:29:19 <glx> but you can access by index from 0 to (number of elements - 1)
20:30:29 <Samu> resorting to an array again, hmm
20:31:51 <glx> but to iterate you have foreach
20:32:09 <Samu> foreach works in tables?
20:32:34 <glx> " Executes a statement for every element contained in an array, table, class, string or generator. If exp is a generator it will be resumed every iteration as long as it is alive; the value will be the result of 'resume' and the index the sequence number of the iteration starting from 0. "
20:34:08 *** gelignite has quit IRC (Quit: Stay safe!)
20:47:46 <Samu> it actually gets the 'key' index
20:48:08 <Samu> it's not a sequence starting from 0
20:48:45 <Samu> im going to use the 'key' index to store town IDs
20:56:23 *** andythenorth has quit IRC (Quit: andythenorth)
21:02:35 *** HerzogDeXtEr has joined #openttd
21:07:33 *** andythenorth has joined #openttd
21:08:46 *** Samu has quit IRC (Quit: Leaving)
21:10:11 *** Gustavo6046_ has joined #openttd
21:15:09 *** Gustavo6046 has quit IRC (Ping timeout: 480 seconds)
21:15:09 *** Gustavo6046_ is now known as Gustavo6046
21:43:40 *** WormnestAndroid has quit IRC (Ping timeout: 480 seconds)
22:01:19 *** Wolf01 has quit IRC (Quit: Once again the world is quick to bury me.)
22:20:11 *** andythenorth has quit IRC (Quit: andythenorth)
22:25:43 *** HerzogDeXtEr has quit IRC (Read error: Connection reset by peer)
22:35:17 *** glx is now known as Guest247
22:41:40 *** Guest247 has quit IRC (Ping timeout: 480 seconds)
22:53:54 *** WormnestAndroid has joined #openttd
23:08:46 *** Progman has quit IRC (Remote host closed the connection)
23:18:17 *** WormnestAndroid has quit IRC (Ping timeout: 480 seconds)
23:18:42 *** WormnestAndroid has joined #openttd
23:55:38 *** WormnestAndroid has quit IRC (Ping timeout: 480 seconds)
23:58:30 *** Wuzzy has quit IRC (Quit: Wuzzy)
continue to next day ⏵
![https://i.imgur.com/dwGEtYt.png[/img]](https://i.imgur.com/dwGEtYt.png%5B/img%5D){kind=link}
