Log for #openttd on 15th February 2021:
Times are UTC Toggle Colours
00:05:43  *** andythenorth has quit IRC
00:11:42  *** glx has quit IRC
00:36:08  *** HerzogDeXtEr has joined #openttd
00:46:09  *** Flygon has joined #openttd
02:10:18  *** Wuzzy2 has joined #openttd
02:10:55  *** Wuzzy has quit IRC
02:19:50  *** Wormnest has quit IRC
02:36:13  *** HerzogDeXtEr has quit IRC
03:32:20  *** debdog has joined #openttd
03:35:42  *** D-HUND has quit IRC
04:04:46  *** Wuzzy2 has quit IRC
04:38:47  *** supermop_Home has quit IRC
05:22:08  *** WormnestAndroid has quit IRC
05:24:00  *** WormnestAndroid has joined #openttd
07:19:15  *** snail_UES_ has quit IRC
07:30:25  *** andythenorth has joined #openttd
07:30:26  <andythenorth> moin
07:36:22  *** Wolf01 has joined #openttd
07:55:33  *** sla_ro|master has joined #openttd
08:06:35  *** HerzogDeXtEr has joined #openttd
08:24:08  *** heffer has quit IRC
08:24:21  *** heffer has joined #openttd
08:30:52  <LordAro> o/
08:37:33  <Wolf01> o/
09:05:56  *** jottyfan has joined #openttd
09:09:07  *** jottyfan has quit IRC
09:10:02  *** jottyfan has joined #openttd
09:26:00  *** jottyfan has quit IRC
09:40:45  *** Eddi|zuHause2 is now known as Eddi|zuHause
10:08:36  *** jottyfan has joined #openttd
11:08:50  *** Samu has joined #openttd
11:51:37  <DorpsGek> [OpenTTD/OpenTTD] orudge opened pull request #8675: Fix: [Actions] Use vcpkg to provide libpng on macOS
11:52:51  <DorpsGek> [OpenTTD/OpenTTD] LordAro approved pull request #8675: Fix: [Actions] Use vcpkg to provide libpng on macOS
12:04:20  *** virtualrandomnumber has joined #openttd
12:04:32  *** virtualrandomnumber has quit IRC
12:07:21  *** jottyfan has quit IRC
12:10:15  <DorpsGek> [OpenTTD/OpenTTD] orudge merged pull request #8675: Fix: [Actions] Use vcpkg to provide libpng on macOS
12:27:56  *** Samu has quit IRC
12:28:18  *** Samu has joined #openttd
12:28:38  <Samu> hi
12:38:46  <DorpsGek> [OpenTTD/OpenTTD] grossws commented on pull request #7851: Change: add support for next/previous railtype global hotkeys
12:55:58  <DorpsGek> [OpenTTD/OpenTTD] grossws updated pull request #7851: Change: add support for next/previous railtype global hotkeys
12:56:25  <DorpsGek> [OpenTTD/OpenTTD] grossws commented on pull request #7851: Change: add support for next/previous railtype global hotkeys
12:56:33  *** roadt__ has joined #openttd
13:03:29  *** roadt_ has quit IRC
13:05:27  *** WormnestAndroid has quit IRC
13:05:41  *** WormnestAndroid has joined #openttd
13:07:13  <_dp_> hm, I just found that HQ produces way less cargo than it was supposed to
13:07:57  <_dp_> or who the hell knows actually since it seems hq was supposed to produce as 256 pop house but houses weren't supposed to produce quadratic amounts
13:08:14  <_dp_> anyway, looks like CS bug so call in a feature :p
13:10:26  <_dp_> basically houses produce as population**2 but hq as 4*((population /4)**2) xD
13:11:23  <Eddi|zuHause> and where do you take the 256 figure from?
13:12:25  <_dp_>
13:12:40  <_dp_> comment was added later ofc but it seems to match the intention
13:18:21  <_dp_> though I've no idea how comments in r975 come to be
13:24:25  <Eddi|zuHause> so what was meant was that since it's 4 tiles, each tile adds 1/4th of the total, and the "wrong" part is the **2-ness of the formula
13:25:23  <Eddi|zuHause> but how does that compare to regular 2x2 houses?
13:26:58  <_dp_> regular houses only produce from one tile
13:27:35  <Eddi|zuHause> anyway, the whole thing seems fine, except it should apply the same linearization as was done with houses, and "amt = (amt + 1) >> 1" should do "/2" instead of ">>1"
13:28:01  <Eddi|zuHause> _dp_: are you sure? the tileloop will hit each tile of the 2x2 house at different points
13:28:27  <_dp_> pretty sure, one one part of house has population iirc
13:30:03  <_dp_> yeah, you can even inspect that in game
13:31:30  <_dp_> newgrf callback though gets called for each tile so everything is possible
13:32:27  <_dp_> * one one -> only one xD
13:33:51  *** sla_ro|master has quit IRC
13:34:36  <Eddi|zuHause> yeah, src/table/town_land.h lists the tiles individually with 3 tiles as 0 population
13:35:19  <Eddi|zuHause> but that's just a specific implementation detail of the original houses
13:35:24  <Eddi|zuHause> not a general spec thing
13:36:37  <Eddi|zuHause> so even without callback, newgrf houses can just set non-zero population for each house part
13:37:21  <_dp_> well, yeah, but it's kind of irrelevant here
13:37:41  <_dp_> I doubt hq was supposed to produce as 128+128 house or smth :p
13:38:09  <_dp_> well, 64x4 in this case
13:38:30  <Eddi|zuHause> well, if the formula had been linear in the first place, that would be equivalent
13:38:39  <_dp_> yep
13:38:52  <Eddi|zuHause> and possibly easier than trying to figure out which part of the HQ you hit
13:39:50  <Eddi|zuHause> "if (o->location.tile == tile)" <-- well, it might actually be easy enough :p
13:40:08  <_dp_> oh, and btw, recession does nothing to hq production except for the highest level one xD
13:40:28  <_dp_> because (1+1)/2 == 1
13:40:55  <Eddi|zuHause> why would lower levels only produce 1?
13:41:06  <_dp_> coz... math? :p
13:41:19  <_dp_> only highest have production of 2
13:41:31  <Eddi|zuHause> i think your math is off
13:41:54  <_dp_>
13:42:08  <_dp_> look carefully, amt is always <= 1 if level != 5
13:42:28  <_dp_> it only enters if on small numbers and then divides it to 0
13:42:58  <Eddi|zuHause> i think your math is off
13:43:10  <Eddi|zuHause> r is between 0 and 255
13:43:10  <_dp_> if (x<32) amt = x/32
13:43:20  <Eddi|zuHause> you check r against 256/4/6
13:43:36  <Eddi|zuHause> and then set amt = r/8/4
13:45:18  <Eddi|zuHause> actually, /5 because minimum level appears to be 1
13:45:48  <_dp_> whatever, even 256/4/2 is already 32 :p
13:48:06  <Eddi|zuHause> ok, that is a bit weird
13:53:18  <Eddi|zuHause> anyway, that's a side effect of passengers trickling in by individual tiles in general, instead of industries which deliver in large chunks
13:53:53  <Eddi|zuHause> nothing to really worry about
13:54:16  <Eddi|zuHause> just means in a recession people still need to go places :)
14:24:35  *** andythenorth has quit IRC
14:29:41  *** supermop_Home has joined #openttd
14:31:56  *** nielsm has joined #openttd
14:53:14  *** Wuzzy has joined #openttd
14:57:13  *** andythenorth has joined #openttd
15:03:09  <DorpsGek> [OpenTTD/OpenSFX] Wuzzy2 commented on pull request #19: Replace Mercurial code with Git code
15:05:23  <Wuzzy> OpenSFX PR awaiting review:
15:05:29  <Wuzzy> Spreaking of OpenSFX...
15:05:59  <Wuzzy> when #14 is merged, the official description of OpenSFX will change as well. however, it is translated (lang/ directory)
15:06:18  <Wuzzy> the question is... what to do with all the translations then?
15:11:35  <Eddi|zuHause> i think i said this yesterday: discard the translations, and announce at the forums that new ones are needed
15:16:41  <Eddi|zuHause> i don't think eints integration would be particularly desirable
15:28:13  *** Progman has joined #openttd
15:33:25  *** Flygon has quit IRC
15:34:07  <Wuzzy> yeah, i had the same idea. sounds the most reasonable
15:51:33  *** gelignite has joined #openttd
16:17:04  <Wolf01> So, yesterday I think I removed too much, but it shouldn't be a problem, the min .net version I still have installed is 4.6.1 and all the stuff seem to work fine, I just needed to update a project which referenced 4.5
16:18:38  <Wolf01> At least now I added ~20GB to the free space :P
16:20:19  *** glx has joined #openttd
16:20:19  *** ChanServ sets mode: +v glx
16:20:28  <Wolf01> Too bad I can't remove VS2017 too... 2019 doesn't support at all the windows mobile platform
16:23:57  *** Speeder has joined #openttd
16:26:06  <glx> for openttd both should work
16:29:32  <Wolf01> Oh damn... still errors even with VS2019... can't find embed.manifest
16:30:22  <glx> hmm current master ?
16:30:35  <Wolf01> No, I need to pull
16:31:14  <Wolf01> Btw, why cmake compiles on my user folder instead of using the other HDD with a lot of free space?
16:32:27  <glx> I guess you somehow did a clean/rebuild and use source from before 99448eedc (10 days ago)
16:32:46  <Wolf01> Yup
16:33:00  <glx> cmake defaults to user folder, but it's all configurable
16:33:11  <glx> via GUI or CMakeSettings.json
16:34:13  <glx> until you update source to recent, you can just restore  os/windows/openttd.manifest
16:34:31  <glx> cmake deletes it on clean due to a mistake
16:35:24  <Wolf01> Ok, it compiled now and started
16:36:36  <Wolf01> <glx> via GUI or CMakeSettings.json <- I found the folder path (which doesn't even exists) but no other configs related to the compile path
16:38:24  <glx> 'buildRoot' in json
16:38:28  *** gelignite has quit IRC
16:38:45  <glx> I set it to ${projectDir}/out/build/${name}
16:40:27  <Wolf01> Oh right, it's everything under "manage configurations" now
16:42:09  <glx> yeah and default configuration is debug
16:42:53  <Wolf01> Yes, I only have that one
16:43:41  <glx> you can clone it and change build type to RelWithDebInfo
16:44:00  <Wolf01> Nah, debug is fine for me :P
16:44:10  <glx> debug runs slow
16:44:42  <Wolf01> I don't need to benchmark the game, there is Samu for that :P
16:44:50  <glx> I have 17 configurations ;)
16:45:44  <glx> basic x64 and x86 (both debug and release), then another 4 using clang
16:46:28  <glx> mingw64 debug and release, arm64 debug and release
16:46:42  <glx> a debug x64 using vs2017 toolchain
16:47:06  <Wolf01> Not bad
16:47:18  <glx> and x64 non static debug and release
16:47:30  <glx> but I mostly use x64-debug
16:58:44  *** sla_ro|master has joined #openttd
17:02:51  *** smoke_fumus has joined #openttd
17:25:41  *** frosch123 has joined #openttd
17:33:10  *** gelignite has joined #openttd
17:36:50  *** Wormnest has joined #openttd
17:39:08  *** snail_UES_ has joined #openttd
18:01:50  *** Wormnest_ has joined #openttd
18:08:41  *** Wormnest has quit IRC
18:11:31  *** Wormnest has joined #openttd
18:15:33  *** Cursarion has quit IRC
18:17:37  *** Cursarion has joined #openttd
18:18:09  *** Wormnest_ has quit IRC
18:37:33  <andythenorth> yo
18:43:00  *** Wuzzy has quit IRC
18:47:00  *** Wormnest_ has joined #openttd
18:52:07  *** Wormnest has quit IRC
19:02:02  <DorpsGek> [OpenTTD/OpenTTD] DorpsGek pushed 1 commits to master
19:02:03  <DorpsGek>   - Update: Translations from eints (by translators)
20:17:08  <supermop_Home> yo
20:38:21  <Wolf01> o/
20:44:06  <DorpsGek> [OpenTTD/OpenTTD] Ufiby opened issue #8676: Unable to open the setting
20:45:36  <DorpsGek> [OpenTTD/OpenTTD] James103 commented on issue #8676: Unable to open the setting
20:46:25  <Wolf01> Yup, it asserts
20:46:37  <glx> let's check
20:47:53  <LordAro> must be a recent change
20:48:01  <LordAro> possibly the world gen reorganise?
20:48:02  <glx> probably yes
20:48:20  <glx> starting the exe to trigger it
20:49:05  <DorpsGek> [OpenTTD/OpenTTD] Ufiby commented on issue #8676: Unable to open the setting
20:51:11  <glx> confirmed assert
20:52:05  <glx> related to gui.zoom_min
20:52:15  <DorpsGek> [OpenTTD/OpenTTD] James103 commented on issue #8676: Unable to open the setting
20:54:46  <glx> let's add some breakpoints
20:59:22  <DorpsGek> [OpenTTD/OpenTTD] Ufiby commented on issue #8676: Unable to open the setting
20:59:34  <glx> oh setting changed name
21:03:01  <glx> ah no they moved
21:03:16  <glx> should not be an issue in theory
21:04:10  <Wolf01> Maybe it doesn't create the default?
21:04:25  <LordAro> be nicer if you could get something to warn/error at compile time
21:04:41  <Wolf01> Looking at the comments it doesn't work even with a fresh config
21:04:43  <glx> it doesn't find the setting
21:05:22  <FLHerne> Wolf01: I'm not sure if that comment is "I tried and it didn't work" or "I'm sure it won't work"
21:05:27  <LordAro> ^
21:05:50  <glx> I think I know which commit breaks, checking
21:05:59  <LordAro> it indeed makes no difference though
21:06:06  <DorpsGek> [OpenTTD/OpenTTD] James103 commented on issue #8676: Unable to open the setting
21:07:16  <glx> probably but I need to confirm
21:08:02  <LordAro> likely
21:08:33  <Wolf01> Il looks there is something weird on that setting
21:09:16  <Wolf01> Like $var in place of $name and missing $var parameter
21:09:26  <Wolf01> Oh different setting type
21:11:11  <glx> commit in itself looks good, other parts of the code except settings window work
21:11:42  <DorpsGek> [OpenTTD/OpenTTD] LordAro commented on issue #8676: Unable to open the setting
21:11:53  <andythenorth> nice issue title :)
21:12:27  <LordAro> andythenorth: settings causes accident!
21:12:35  <andythenorth> goes it throw out
21:13:34  <glx> f5555a6d2 works
21:14:55  <LordAro> so what's been forgotten?
21:15:09  <LordAro> what makes a setting "early load"?
21:16:56  <frosch123> "early load" are settings in misc_settings
21:17:03  <frosch123> they are loaded before grfscan
21:17:10  <frosch123> i.e. needed to display the basic intro screen
21:17:23  <frosch123> and probably bootstrap
21:17:46  <glx> confirmed it's a2c3197f424
21:18:49  <frosch123> the zoom settings are the first SDTC_ in misc_Settings
21:19:04  <frosch123> everything else in misc_setting are global variables outside the settings struct
21:19:50  <glx> yup seems they are not in _settings
21:20:03  <frosch123> ah, the crash is because there is no "name="
21:20:49  <frosch123> so much magic :p
21:21:15  <glx> well name is replaced by var in the macro
21:25:19  <glx> of course they are in _misc_settings[] now
21:25:33  <glx> and not in _settings[]
21:26:13  <frosch123> so none of misc_settings work in console or in the tree?
21:27:24  <glx> hmm something looks wrong in setting table
21:27:43  <glx> let's try a modification in .ini
21:28:07  <frosch123> i see in the debugger, that there is a "gui.zoom_min" in _misc_settings
21:28:32  <frosch123> but GetSettingFromName and friends only care about _settings
21:29:56  <frosch123> so neither console nor tree work for _misc_settings
21:30:14  <frosch123> and i have no idea whether they were intentionally left out :)
21:30:41  <glx> I think it's intentionnal, based on the settings in misc
21:32:53  <frosch123> this looks difficult to me :p
21:33:06  <frosch123> i would now try to merge _misc_settings into _settings
21:33:07  <frosch123> or similar
21:33:18  <glx> and it's the first non global put in misc
21:34:44  <glx> I wonder if it even save/load correctly from cfg
21:35:05  <frosch123> the ini load/save is the only place that uses _misc_settings
21:35:41  <frosch123> what would break if we move all _misc_settings into _settings as client settings?
21:35:50  <frosch123> and add some gui_flag or similar for the early-load
21:43:20  <frosch123> i think that's the best solution. other ideas?
21:43:48  <frosch123> remove misc_settings, put all of them into _settings. add some flag for early load
21:44:22  <frosch123> that way GetSettingFromName can return a index into _settings for them
21:44:41  <frosch123> and SetSettingValue and IConsoleSetSetting work
21:45:51  <frosch123> there are probably some traps with settings like "graphicsset", which have string data
21:45:58  <frosch123> i believe no other settings have string data
21:46:05  <glx> there's also _gameopt_settings with SC_ category while they are not in the settings window
21:47:12  <frosch123> i think we added SC_ to everything, no matter whether in tree or not
21:47:59  <frosch123> second suggestion: keep _misc_settings, but add an early-load flag to _settings nevertheless, and them move the zoom settings back to _settings
21:48:05  <frosch123> less risky
21:49:52  <glx> I'm quite sure the value in [gui] section are not loaded anyway, as misc_settings should read only [misc] section
21:54:36  *** Samu has quit IRC
21:55:05  <frosch123> no, "misc" is just the default for settings without a "." in their name
21:55:34  <glx> ah yes (looking at the code)
21:56:04  <frosch123> that's where i got the info from :p
21:56:41  <glx> yeah I was in the loading code when you mentioned the "."
22:01:20  <glx> second suggestion looks sane
22:02:32  <glx> and replacing basic_setting and other settings in HandleSettingDescs with a bool parameter in loading proc
22:03:06  <frosch123> do you remember a setting that requires late loading?
22:03:53  <frosch123> except for the obvious GRFLoadConfig, AILoadConfig and GameLoadConfig
22:05:53  <frosch123> so, third solution: load all _settings early?
22:06:05  <glx> looking at all LoadFromConfig() calls
22:06:34  <frosch123> those in 1755-1771 i understand
22:06:55  <frosch123> but no idea why HandleSettingDescs makes such a deal of loading some settings late
22:07:33  <glx> yeah I think it could always load all, except misc, unless at startup
22:08:22  <glx> as anyway they will be reloaded after grf scan
22:08:23  <frosch123> you probably are only allowed to load them once. but i think you can load all of them early
22:08:39  <frosch123> there are some comments about custom currency and other weird things
22:09:37  <glx> I see 3 calls, one in main (the early load), one after grf scan, and a last one for servers
22:10:06  <glx> so basically even the early load could load everything
22:12:24  <glx> it was probably some kind of optimisation to not reload multiple times the same thing
22:13:18  <frosch123> but does it need reloading? can HandleSettingDescs just only run for "minimal"?
22:19:21  <frosch123> night, and good luck :)
22:19:26  *** frosch123 has quit IRC
22:20:58  <michi_cc> Lots of changed lines for what should be the second suggestion:
22:21:43  <glx> oh I think we can always load them,
22:21:56  <glx> minimal or not
22:23:15  <glx> still compiling (and not tested yet) but should work
22:24:18  <glx> and probably all other !minimal settings could be always loaded too
22:24:18  <michi_cc> Probably. In the end, what bad is supposed to happen when loading an integer value twice?
22:25:19  <glx> in workflow I can see load minimal, scan newgrf, load other
22:25:44  <glx> and load other happen after each newgrf scan
22:26:40  <glx> so maybe we just need to take care to not overwrite these 2 gui. value, like we do for newgrf count
22:31:28  *** nielsm has quit IRC
22:32:00  <michi_cc> Do you expect the cfg value to change somehow? Otherwise overwriting an integer with itself is totally fine.
22:32:34  <glx> not the cfg, but if user changed the setting before downloading a newgrf
22:33:09  <glx> well it's like other settings in this case I guess
22:42:36  *** Wolf01 has quit IRC
22:45:35  <glx> oh config is always saved on setting change once at least a newgrf scan is done
22:45:47  <glx> so we should be safe
22:58:33  *** smoke_fumus has quit IRC
23:02:44  <glx> hmm it seems moving UpdateGUI() call in ottd_main after grf scan could be enough to not require early loading
23:03:34  <glx> but I guess it's before so the progress bar is properly scaled
23:05:20  <michi_cc> Yeah, if you do it then the grf scan bar will not be scaled and the title game zoom might jump after the scan.
23:09:15  *** HerzogDeXtEr has quit IRC
23:11:44  <DorpsGek> [OpenTTD/OpenTTD] glx22 opened pull request #8677: Fix #8676: Revert a2c3197f4 and unconditionally load settings "early"
23:12:54  *** sla_ro|master has quit IRC
23:13:42  <michi_cc> Just in case there is a problem with the load early: would keep the current beaviour I think.
23:17:54  <glx> I like your version too
23:18:41  *** Progman has quit IRC
23:20:03  <DorpsGek> [OpenTTD/OpenTTD] glx22 commented on pull request #8677: Fix #8676: Revert a2c3197f4 and unconditionally load settings "early"
23:22:34  *** gelignite has quit IRC
23:24:27  <DorpsGek> [OpenTTD/OpenTTD] michicc opened pull request #8678: Fix #8676: GUI-visible settings may not be part of misc settings.
23:24:35  <michi_cc> Well, I let somebody else battle this out :p
23:24:49  <glx> we provide options :)
23:25:00  <michi_cc> Also night :)
23:31:34  <DorpsGek> [OpenTTD/OpenTTD] glx22 commented on pull request #8678: Fix #8676: GUI-visible settings may not be part of misc settings.
23:49:23  *** azubieta has quit IRC
23:50:58  *** azubieta has joined #openttd
23:53:53  *** glx has quit IRC

Powered by YARRSTE version: svn-trunk