IRC logs for #openttd on OFTC at 2019-09-07
⏴ go to previous day
00:12:28 *** Thedarkb has joined #openttd
00:25:26 *** tokai|noir has joined #openttd
00:25:26 *** ChanServ sets mode: +v tokai|noir
00:37:59 <LordAro> thoughts/complaints appreciated
01:18:33 *** WormnestAndroid has quit IRC
01:19:05 *** WormnestAndroid has joined #openttd
01:34:43 <ToBeFree> "Option to show local authority boundary of towns (#7025)" oooooh nice.
01:47:45 <LordAro> i still think the option is a bit hidden, but eh
02:10:48 *** Thedarkb has joined #openttd
02:16:34 <Eddi|zuHause> someone should have finished #7000
03:11:18 <Eddi|zuHause> LordAro: should a released feature contain the word "experimental"?
07:56:25 *** WormnestAndroid has quit IRC
08:10:27 *** WormnestAndroid has joined #openttd
08:25:12 *** andythenorth has joined #openttd
08:55:27 *** sla_ro|master has joined #openttd
09:20:21 * andythenorth so much shipping container variety
09:21:31 <andythenorth> much automation incoming :P
09:39:45 <nielsm> hmm shouldn't there be a "game ends and highscore is recorded" setting that lets you configure either "100 years after starting year" or a specific year?
09:40:23 <nielsm> (that's a suggestion not a question)
09:40:49 *** raizumaraiz has joined #openttd
09:41:01 <nielsm> and if you set the ending year to something before the actual start year there just isn't an end condition
09:41:19 <andythenorth> I do find the highscore screen weird when it appears
09:41:23 <andythenorth> it's very arbitrary
09:41:24 <nielsm> or I suppose there could also be an explicit "never" setting
09:44:16 <andythenorth> 100 years after game start makes most sense to me :P
09:44:28 <nielsm> yeah that should be the default
09:44:54 <andythenorth> I'm not sure it needs to be better than that
09:44:56 <nielsm> TTO also ran 1930-2030
09:45:04 <andythenorth> it's not like the high-score system is actually valid :)
09:45:13 <nielsm> well maybe you want to run a game from 1840 to 2040
09:45:15 <andythenorth> I did win it once, using the known exploits
09:45:32 <andythenorth> my 9 year old keeps asking when we're going to fix it :P
09:45:59 <nielsm> well I also have the WIP still-in-ideas-phase patch for making the score calculation controlled by GS
09:46:32 <andythenorth> high-score-script :D
09:47:01 <nielsm> it could allow for some much more interesting scoring options :)
09:47:07 <nielsm> like variety of trains used :P
09:47:24 <nielsm> quality of industry service provided
09:47:52 <andythenorth> achievements unlocked :P
09:48:06 <andythenorth> does it merge high score and story book?
09:48:06 <LordAro> Eddi|zuHause: maybe not, but that is ultimately what it is
09:48:16 <andythenorth> or are they separate concerns?
09:48:43 <nielsm> they'd still be separate concerns
09:48:48 * andythenorth did make some commits to Busy Bee GS, but GS is really hard to work with
09:48:59 <andythenorth> which is probably why we have very few
09:49:01 <nielsm> but does the storybook have a "progress bar" element? if not perhaps it should
09:49:40 <nielsm> perhaps even an element that mirrors a scoring part
09:51:00 * andythenorth looks what was hard
09:51:58 <andythenorth> oh yes, I remember
09:52:05 <andythenorth> "andythenorth is not a programmer" :P
09:52:42 <andythenorth> that was the limiting factor
09:55:09 *** Maarten has joined #openttd
09:55:14 *** Progman has joined #openttd
10:21:09 <nielsm> set up an AI that just runs the same (cheap/free) command on a loop?
10:21:49 <LordAro> #7188 is the original issue
10:21:58 <LordAro> samu probably knows how to reproduce it :p
10:22:24 <nielsm> the original report seems to be "sometimes this happens when reloading an ai"
10:25:05 <DorpsGek_III> [OpenTTD/OpenTTD] nielsmh approved pull request #7720: Add: [DorpsGek] also announce comments on commits https://git.io/fjjHB
10:26:37 <nielsm> need to reboot for a visual studio update >_>
10:29:15 <nielsm> at least rebooting is relatively quick
10:37:00 <DorpsGek_III> [OpenTTD/OpenTTD] LordAro merged pull request #7720: Add: [DorpsGek] also announce comments on commits https://git.io/fjhdC
10:43:24 <Samu> hmm i'm trying to understand why do I build more mail routes than pass routes
10:48:53 <LordAro> can you provide a list of steps to reproduce #7188?
10:50:47 <LordAro> hmm, you did write a list on the original issue
10:51:04 <LordAro> nielsm: have you tried those steps?
10:52:00 <nielsm> LordAro they seem pretty "do this and pray it triggers the bug" as it's somewhat a race condition
10:52:46 <nielsm> I'm thinking if the diagnosis is right, that it's an AI getting reloaded while waiting for a command return, and the command return then being delivered to a different instance, you can make an AI that triggers it reliably on every reload
10:52:56 <nielsm> if you just make the AI a tight loop of commands
10:53:21 <Samu> oh, i can't test network stuff here anymore
10:53:45 <Samu> it's a bug with the reload, only happens in network games
10:54:56 <DorpsGek_III> [OpenTTD/OpenTTD] ldpl commented on pull request #7719: Add: Allow GameScript to demolish without a company https://git.io/fjjHy
10:55:49 <Samu> best way to cause it is to have many AIs running, very fast speed and 250k max ops
10:57:34 <Samu> nielsm description is correct
10:58:06 <Samu> it's cause the commands were delayed by the network by a frame
11:05:24 <Samu> the answer to the command of the previous instance goes to the new instance, causing the crash
11:15:24 <nielsm> hmm... just doing commands in a tight loop doesn't seem to trigger it
11:15:42 <nielsm> (and then reloading it while it's running)
11:25:42 <Samu> how many ais are running there?
11:25:55 <nielsm> one, and it shouldn't matter how many
11:26:21 <nielsm> not by the issue description
11:26:35 *** HerzogDeXtEr has joined #openttd
11:26:42 <Samu> it's about queueing of network commands
11:26:44 <nielsm> whether an AI can execute a command and will have to wait until next tick for the result is not affected by number of active AIs
11:26:58 <Samu> needs more stuff to be queued to crash
11:27:23 <nielsm> every company has a queue length of exactly one
11:27:44 <nielsm> and every tick the server executes every command received
11:28:11 <Samu> it sometimes is delayed by 1 more tick, it's when that happens that it can cause the crash
11:29:11 <Samu> or am I seeing this wrong?
11:29:29 <Samu> but you're not getting the crash :(
11:29:31 <nielsm> commands are executed at most one per company per tick
11:29:57 <nielsm> AI scripts are suspended when they submit a command and wait for the command to complete
11:30:09 <nielsm> they can't "batch" commands
11:30:47 <nielsm> I have a game with max right now
11:31:02 <Samu> i don't even see you hitting the reload button
11:31:03 <nielsm> max ops 100,000 (hundred thousand)
11:31:23 <nielsm> because that was just to show how silly my test AI was
11:32:32 <nielsm> that's what you're suggestion to repro, right?
11:33:19 <Samu> click reload incessantly
11:33:58 <Samu> let me see if i can cause a crash here
11:34:16 <nielsm> okay after several hundred clicks on reload it did trigger
11:34:37 <nielsm> the game was basically unresponsive from AIs doing their initial setup
11:35:07 <nielsm> it's not a good way to repro an issue, I want a reliable way to repro it
11:35:15 <nielsm> one that triggers on first try every time
11:36:33 <nielsm> otherwise you're in the situation "well couldn't repro it again" and it was purely by chance, not because the attempted fix actually worked
11:39:01 <Samu> that's the bug I was reporting :)
11:39:59 <Samu> can't reliably reproduce it :(
11:40:14 <Samu> but it's how it can happen
11:43:04 <Samu> i'm about 85% certain it's related to frame frequency, something about network frames being delayed
11:45:53 <Samu> the company is cleared, but the commands that are queued aren't
11:46:12 <Samu> queued or delayed, whatever it is
11:46:14 <nielsm> "the commands" is your misunderstanding
11:46:17 <nielsm> there is never more than one
11:51:01 <Samu> gameloop can process the next tick while network_frame can be delayed
11:51:11 <Samu> i need to find it in the code, brb
11:56:23 <Samu> NetworkExecuteLocalCommandQueue is right before StateGameLoop
11:57:27 <nielsm> each company can have submitted at most one command per tick
11:57:51 <nielsm> and each client can only proceed to next tick once it has received confirmation from the server about the last one finishing
11:58:57 <nielsm> anyway the bug reproduces using your steps _without_ having a second client connected
11:59:01 <nielsm> it's enough having just the server
12:05:40 <Samu> #7188 was reporting two other bugs
12:06:41 <Samu> I remember one of them was fixed
12:07:07 <Samu> better re-read 7188, brb
12:08:03 <Samu> ya, it's #7190 that should be mentioned
12:09:12 <nielsm> #7190 is not a bug report it's a PR
12:10:04 <Samu> server crash reported in 7188 is the reload crash
12:11:22 <Samu> glx should know more about the issue
12:11:46 <nielsm> yes, his fix looks very correct
12:12:05 <nielsm> I'm trying to figure out a way to reliably reproduce the assert so the fix can be reliably tested
12:13:26 <Samu> I also proposed a bad fix
12:14:14 <Samu> the new instance is receiving the callback
12:14:26 <Samu> that was issued by the bankrupted instance
12:14:44 <Samu> because.. bla bla network packets delayed etc..
12:15:18 <Samu> _local_wait_queue or _local_execution_queue, it's one of them
12:15:21 <nielsm> it can reproduce with only a server, no clients needed
12:15:35 <nielsm> no delays on network because there is no network transmission involved
12:23:03 *** frosch123 has joined #openttd
12:31:58 *** WormnestAndroid has quit IRC
12:56:08 *** WormnestAndroid has joined #openttd
13:14:16 *** raizumaraiz has joined #openttd
13:24:08 <michi_cc> nielsm: Did you try a higher frame_freq setting to get more command delay?
13:27:35 <nielsm> hm I don't know that setting
13:29:42 <nielsm> but does it affect AI players?
13:29:56 <nielsm> don't those run in lock-step with the server?
13:32:37 <michi_cc> Not sure actually if frame_freq just delays on sending to the clients or already at the execution stage.
13:34:09 <nielsm> all of this would be easier to understand if AIs were handled as separate clients running as their own threads or processes :/
13:37:17 <Eddi|zuHause> that would involve them running a copy of the game, with full simulation?
13:38:03 <Eddi|zuHause> while that would make for a cleaner interface, it has some serious performance impact...
13:38:17 <nielsm> unless some fancy CoW of the game state with the server could be set up
13:38:21 <nielsm> but that would be fragile too
13:41:55 <Eddi|zuHause> but, have i understood this core issue right, that we're dealing with data that is not properly cleared on restart, and gets sent to an AI that was not expecting any data?
13:42:54 <nielsm> the engine attempts to resume an AI that was not suspended, because the AI that previously occupied its slot had submitted a command and was waiting for the result, but was then terminated/restarted in the meantime
13:43:58 <nielsm> glx's fix looks entirely correct, but I stubbornly want a way to reliably reproduce the issue :)
13:44:01 <Eddi|zuHause> well, two obvious approaches to that problem would be: actually clear the data properly, or add some instance-ID, so the data gets sent nowhere
13:44:25 <andythenorth> all the local cats have adopted my hot tub
13:44:30 <andythenorth> on it, not in it :P
13:45:27 <Eddi|zuHause> cats prefer places that are elevated and warm
13:45:35 <frosch123> nielsm: use a gs that pauses the game and runs a command that is forbidden in pause
13:45:58 <frosch123> that deadlocks the gs forever, waiting for the command to finish
13:46:34 <Eddi|zuHause> frosch123: that sounds wrong, that command should return with a failure?
13:46:39 <nielsm> but a separate issue :D
13:46:46 <andythenorth> hmm intermodal containers aren't 'vehicles', right? :P
13:46:55 * andythenorth organising filesystem
13:47:00 <Eddi|zuHause> andythenorth: not currently :p
13:47:01 <frosch123> weren't you looking for a method to make the gs hang in suspended state?
13:48:39 <frosch123> Eddi|zuHause: feel free to make a PR for #5283
13:49:05 <nielsm> more like looking for a reliably way to catch an AI with one leg through the door to the next tick and then getting reloaded
13:50:30 <Eddi|zuHause> nielsm: have the AI make some debug output right before the command?
13:51:59 <frosch123> Eddi|zuHause: it is even labeled as "good first issue"
13:52:23 <Eddi|zuHause> frosch123: too bad it's not my first issue
13:57:02 <andythenorth> intermodal_container_combos is quite a chunky variable name :P
13:59:49 <andythenorth> iso_box_combos? :P
14:01:40 <Eddi|zuHause> sounds like you have a "wrong" approach to naming things
14:01:57 <andythenorth> I tend to name them what they are :P
14:02:17 <andythenorth> I did have an employee who named things 'a', 'b' etc, for optimisation
14:02:36 <Eddi|zuHause> that's what an obfuscator is for
14:10:26 * andythenorth back to making long variables :P
14:15:26 <michi_cc> andythenorth: Could you check/commit my comment on #7721 please? You shouldn't notice any difference (unless I made a mistake), it's just for old OSX versions which I'd like to keep compatible where possible without undue effort.
14:16:30 <michi_cc> Other than that, it seems sRGB is the winner (i.e. what the current PR does)?
14:16:43 <DorpsGek_III> [OpenTTD/OpenTTD] andythenorth updated pull request #7721: Fix: change Quartz driver colorSpace handling to address certain macO… https://git.io/fjhNm
14:16:52 <andythenorth> the sRGB looks very wrong on my screen
14:17:03 <andythenorth> but it seems about 50:50 that other OSes do the same 'wrong'
14:17:14 <nielsm> I suspect that has to do with calibration
14:17:35 <andythenorth> colour handling is a nest of variations
14:18:10 <andythenorth> I committed that change, do I need to squash a commit now?
14:18:29 <nielsm> we can squash it during merge
14:21:04 <andythenorth> afaict, my opinion is irrelevant
14:21:22 <andythenorth> there is only one RGB colorspace available according to Apple
14:22:34 <nielsm> basically sRGB "must" be correct, since it was designed to be a standardisation of what displays and RAMDACs were already doing
14:23:55 <andythenorth> I guess over time I'll get used to it
14:23:59 <andythenorth> it's really washed out though
14:25:02 <andythenorth> kCGColorSpaceGenericRGB is no better
14:25:08 <nielsm> but then screenshots aren't really the way to compare either, I think, you'd need photos of two displays side by side
14:25:28 <nielsm> the GenericRGB seems to be wrong gamma
14:25:57 <andythenorth> I am side-by-siding master and the patch
14:26:17 <andythenorth> trying to get it to appear same on different screens is boiling the ocean :)
14:27:31 <DorpsGek_III> [OpenTTD/OpenTTD] andythenorth commented on issue #7644: Mysteriously poor performance on macOS https://git.io/fjii3
14:28:47 <andythenorth> setting kCGColorSpaceDisplayP3 works for me
14:29:36 <nielsm> make it a setting on the video driver? :/
14:30:13 <nielsm> "video=cocoa:cs=srgb" "video=cocoa:cs=p3" "video=cocoa:cs=generic"
14:30:23 <DorpsGek_III> [OpenTTD/OpenTTD] andythenorth commented on issue #7644: Mysteriously poor performance on macOS https://git.io/fjii3
14:30:38 <andythenorth> screenshots ^ :P
14:30:51 *** supermop_Home_ has joined #openttd
14:32:47 <andythenorth> kCGColorSpaceDisplayP3 is much slower
14:33:47 <andythenorth> I could reset the DOS palette, and write a transform to move all base set sprites?
14:57:17 *** kiwitree has joined #openttd
14:58:02 <milek7> what happens when you take screenshot of P3 on mac? does it get correctly converted to sRGB for png image?
15:14:53 <andythenorth> the embedded color profile in the PNG is P3
15:15:20 <andythenorth> but comparing across systems via screenshot is...problematic
16:02:18 *** Wormnest has joined #openttd
16:24:21 *** snail_UES_ has joined #openttd
17:10:48 *** WormnestAndroid has quit IRC
17:11:46 *** WormnestAndroid has joined #openttd
17:17:52 <supermop_Home_> I guess I should stop listening to house music from 1997 and go do something with my day
17:19:48 *** WormnestAndroid has quit IRC
17:20:22 *** WormnestAndroid has joined #openttd
17:24:16 <Samu> or just this: Leftfield Song of Life Lemon Interupt Mix
17:32:25 <supermop_Home_> i was listening to Ecuador! by sash
17:32:28 *** WormnestAndroid has quit IRC
17:34:37 *** WormnestAndroid has joined #openttd
17:36:13 <Samu> Sasha is not Sash i think
17:38:45 <Samu> nop, Sasha is a DJ from UK
17:41:48 *** andythenorth has joined #openttd
17:43:02 <Samu> by Sash! I like Encore Une Fois, Adelante
17:48:25 <andythenorth> ha, I need to write my own spritesorter :D
17:48:29 <andythenorth> usually I cheat and use masks
17:48:35 <andythenorth> this will be an adventure
17:49:33 <andythenorth> we going to write our own? o_O
17:49:37 <nielsm> there's also a deviceRGBColorSpace and extendedSRGBColorSpace
17:50:15 <andythenorth> it's puzzling why some of the included spaces have the performance issue, and some don't
17:50:41 <andythenorth> many guesses are possible, maybe some are hardware accelerated and some are not :P
17:53:26 *** Wormnest has joined #openttd
17:56:17 <nielsm> andythenorth: try commenting out the CGColorSpaceCreateWithName line entirely, so the QZ_GetCorrectColorSpace function drops down to the CGColorSpaceCreateDeviceRGB line instead
17:56:38 <nielsm> since CGColorSpaceCreateDeviceRGB specifies that it makes a colorspace that does zero conversions
17:56:54 <nielsm> just sends the pixel data as-supplied to the display
17:58:44 <nielsm> and I really have a suspicion that's exactly what we want
17:58:57 *** andythenorth is now known as Guest2021
17:59:17 *** andythenorth has joined #openttd
17:59:26 <andythenorth> I commented out the entire conditional check
17:59:32 <andythenorth> and the compile killed my mac dead
17:59:35 <andythenorth> that's unexpected
18:01:00 <nielsm> as in, just running 'make' killed it?
18:01:11 <andythenorth> as in, I use 'make run'
18:01:18 <andythenorth> and when it ran, the mac turned off
18:02:12 <nielsm> you could also replace the NULL initialisation on line 111 with a CGColorSpaceCreateDeviceRGB() call
18:02:24 *** andythenorth has joined #openttd
18:02:28 <nielsm> you could also replace the NULL initialisation on line 111 with a CGColorSpaceCreateDeviceRGB() call
18:02:40 <andythenorth> I just tried running it again :D
18:02:45 <michi_cc> Hmm, so getting Windows to render the output as sRGB is easy, but if using 32bpp output, my frame output time jumps from <1ms to 25ms. It is much better when using real 8bpp output.
18:02:47 <andythenorth> didn't turn off, but kicked my user
18:03:39 <LordAro> istr there's some code somewhere to force blitter type for OSX, has that been considered?
18:03:59 <nielsm> LordAro that won't really help I think
18:04:07 <michi_cc> LordAro: On anyting recent, its 32bpp or black.
18:04:24 <LordAro> yeah, i think it was forcing to a 32bpp blitter
18:04:28 <nielsm> and the sustainable solution is probably still to use opengl/metal/whatever
18:04:32 <andythenorth> "sessionlogoutd[1224]: DEAD_PROCESS: 99 console" looks suspicious
18:04:42 <andythenorth> and then it seems to overwhelm the event logger
18:04:49 <LordAro> nielsm: i think you're probably right
18:04:55 <LordAro> michi_cc: how far did your branch get? :p
18:04:57 <andythenorth> "diagnosticd[831]: Stream client PID: 816 - Dropped 5263 of 1012151 messages because streaming client could not keep up with the datastream."
18:05:11 <nielsm> how cursed is that code
18:05:32 <andythenorth> that's the most cursed I've ever seen
18:06:19 <andythenorth> so the trigger is no setting the colorspace
18:08:31 <andythenorth> the log is quite interesting
18:10:13 <andythenorth> hmm, I need to restart, the crash handling has crashed and is very unhappy
18:12:16 <nielsm> so while everyone's gathered, does anyone have anything against making a 1.9.3 release, and/or the changeset I'm suggesting?
18:13:12 *** andythenorth has joined #openttd
18:13:47 <nielsm> glx: that script command handling patch, do you have any better test case for it?
18:14:25 <glx> I think it's more easy if the server is very slow
18:15:13 <glx> maybe using a 2048² map with many vehicles
18:15:24 <LordAro> Samu does like those sort of maps
18:16:31 <glx> it's really related to the time taken by a tick
18:16:51 <glx> as the callback is called 1 tick after the command
18:22:50 <DorpsGek_III> [OpenTTD/OpenTTD] nielsmh approved pull request #7701: Fix #7188: check the validity of command callback for scripts https://git.io/fjjNx
18:37:04 <DorpsGek_III> [OpenTTD/OpenTTD] LordAro merged pull request #7701: Fix #7188: check the validity of command callback for scripts https://git.io/fjFqb
18:42:44 <nielsm> hmm I think we should maybe not have merged #7701 actually
18:42:56 <nielsm> it seems most AIs just get stuck now
18:44:09 <nielsm> that's what I get for approving a patch without testing it
18:49:52 <nielsm> huh, but if the AIs stop executing at some point how come the regression tests complete then
18:51:00 <nielsm> because they run in singleplayer maybe?
18:51:06 <glx> regression is singleplayer
18:55:50 <LordAro> glx: mind if i fixup the ClientID stuff for #7681 ?
18:55:53 <michi_cc> ^^ For the record, unless somebody has some performance insight.
19:07:52 <nielsm> dbg: [script] SetLastCommand company=01 tile=000000 p1=00000000 p2=00000000 cmd=102
19:07:52 <nielsm> dbg: [script] CheckLastCommand company=01 tile=000000 p1=00000000 p2=00000000 cmd=358
19:07:54 <glx> ok I see what's wrong in #7701
19:08:03 <nielsm> okay becuase I don't yet :D
19:08:08 <glx> I forgot flags could be added
19:08:30 <nielsm> ah the cmd value includes flags
19:16:03 <glx> but I fail to see where it's added yet
19:17:33 <nielsm> maybe the debug level should be increased on those prints
19:17:39 <nielsm> it's extremely spammy :)
19:17:58 <LordAro> ah crap, i broke the PR
19:21:11 <LordAro> glx: i also have a branch called 'warnings' :)
19:21:25 *** gelignite has joined #openttd
19:21:30 <LordAro> always fun to learn some new git syntax though
19:22:18 *** WormnestAndroid has quit IRC
19:22:35 *** WormnestAndroid has joined #openttd
19:23:10 <DorpsGek_III> [OpenTTD/OpenTTD] nielsmh opened pull request #7725: Fix b3fd7879: Ignore command flags when verifying script commands https://git.io/fjjAQ
19:25:15 <glx> cp->cmd |= CMD_NETWORK_COMMAND; DoCommandP(cp, cp->my_cmd);
19:25:49 <glx> NetworkExecuteLocalCommandQueue() adds the flag
19:26:32 <nielsm> I still think the easiest is just to mask out the flags for the verification and do it solely on the command id
19:35:46 <DorpsGek_III> [OpenTTD/OpenTTD] glx22 approved pull request #7725: Fix b3fd7879: Ignore command flags when verifying script commands https://git.io/fjjAj
19:38:09 <DorpsGek_III> [OpenTTD/OpenTTD] nielsmh commented on pull request #7701: Fix #7188: check the validity of command callback for scripts https://git.io/fjjxU
19:38:16 <DorpsGek_III> [OpenTTD/OpenTTD] nielsmh merged pull request #7725: Fix b3fd7879: Ignore command flags when verifying script commands https://git.io/fjjAQ
19:39:43 <LordAro> anyone feel like reviewing (& merging) #7681 & #7630 ? :p
19:41:08 <nielsm> woo cherry-pick failing because of nullptr/NULL differences!
19:41:17 <nielsm> always enjoy a little manual merging
19:55:32 <glx> the last build for #7630 is not available, a rebase just to trigger a new build would be nice
19:56:55 <glx> and then maybe just merge #7681 in #7630
20:04:00 * andythenorth likes better things :)
20:14:35 <LordAro> i note OGFX needs another release
20:20:05 <LordAro> i don't think there's anything newer, nothing on bananas, anyway
20:35:39 <frosch123> i think some of the nrt sprites were even drawn for ogfx style
21:02:52 <andythenorth> all sprites are drawn afaik
21:02:59 <andythenorth> they're in openttd.grf
21:03:11 <andythenorth> unless someone redrew more in ogfx style?
21:04:46 <frosch123> cursors and stuff were drawn in both styles
21:13:04 *** sla_ro|master has joined #openttd
21:25:52 *** snail_UES_ has joined #openttd
21:26:28 <frosch123> will anyone finish nrt before 1.10?
21:27:04 <nielsm> correctness police lol
21:27:33 <frosch123> it's hard to define correctness, if there isn't even a spec
21:28:02 <frosch123> although "implementation defined" may be a spec :p
21:30:24 <LordAro> frosch123: NRT itself is done...?
21:30:31 <nielsm> some of the Add should be Feature IMO
21:30:34 <LordAro> unless you're referring to NML and other things
21:30:41 <LordAro> feel free to review :)
21:31:09 <supermop_Home_> can roads have more town flags yet?
21:31:18 <supermop_Home_> should i touch my roads again?
21:31:29 <frosch123> LordAro: i have honestly no idea what nrt is. only thing i know that the spec from january 2016 does not refelct at all what was merged
21:32:03 <frosch123> if someone would have to update opengfx, they would have to reverse engineer nrt first
21:32:04 <supermop_Home_> frosch123 i too have no idea what it actually is and if there are new better features i should support
21:32:15 <supermop_Home_> but my old grfs seem to work with it
21:32:17 <frosch123> openttd.grf got new sprites which are not documented whatsoever
21:32:20 <frosch123> i would bet, some are even unused
21:33:47 <andythenorth> there is a PR in the NML repo
21:34:44 <nielsm> thexa4: technically there's nothing wrong with your PR, it's just nobody have taken the time to review it yet
21:35:05 <nielsm> as it probably requires a bunch of testing including writing scripts using the feature
21:35:21 <thexa4> no problem, just wanted to make sure I didn't miss anything. I have a script that uses the feature, will add a link to the PR.
21:36:37 <michi_cc> andythenorth: Is the contents of #7721 fine now or do you want to change anything? Please note that you have to reword/squash the second commit to make the commit checker give a green light.
21:36:43 <DorpsGek_III> [OpenTTD/OpenTTD] thexa4 commented on pull request #7719: Add: Allow GameScript to demolish without a company https://git.io/fjjhW
21:37:41 <andythenorth> I don't think there's a better solution to 7721
21:37:53 <andythenorth> on my screen, it results in a very muddy washed-out OpenTTD
21:38:03 <andythenorth> but at least the fps isn't 12
21:38:38 <nielsm> andythenorth: you never managed to get a device-dependent colorspace to work/not crash?
21:40:16 <andythenorth> I didn't get it to work
21:40:30 <andythenorth> I am not sure how
21:40:35 <andythenorth> but it could be added later
21:40:46 <andythenorth> depends on whether the fps benefit is worth the degraded appearance
21:41:15 <andythenorth> I'd probably commit and see how much complaints there are
21:41:31 <LordAro> "looks bad/different" is better than "barely runs"
21:42:50 <andythenorth> the commit needs squashed
21:42:59 <andythenorth> but I am playing multi-player tanks right now in a team :P
21:46:20 <DorpsGek_III> [OpenTTD/OpenTTD] andythenorth updated pull request #7721: Fix: change Quartz driver colorSpace handling to address certain macO… https://git.io/fjhNm
21:49:14 <DorpsGek_III> [OpenTTD/OpenTTD] andythenorth updated pull request #7721: Fix: change Quartz driver colorSpace handling to address certain macO… https://git.io/fjhNm
21:49:19 <andythenorth> maybe this one works
21:51:43 <DorpsGek_III> [OpenTTD/OpenTTD] LordAro approved pull request #7721: Fix: change Quartz driver colorSpace handling to address certain macO… https://git.io/fjjh2
21:57:09 <andythenorth> does that include michi's change?
21:57:29 <andythenorth> it's 100% possible I haven't squashed correctly
22:00:14 <DorpsGek_III> [OpenTTD/OpenTTD] LordAro approved pull request #7719: Add: Allow GameScript to demolish without a company https://git.io/fjjhw
22:09:20 <DorpsGek_III> [OpenTTD/OpenTTD] nielsmh merged pull request #7721: Fix: change Quartz driver colorSpace handling to address certain macO… https://git.io/fjhNm
22:15:10 <nielsm> that should be everything required for 1.9.3
22:15:44 <LordAro> bring the dates forward by a day and release it tonight?
22:16:35 <nielsm> I think I'd like to have a set of builds from the buildbot for smoke testing before doing a real release
22:17:22 <LordAro> we could call it... "candidate for release"
22:18:38 <Samu> I'm falling asleep already :|
22:23:54 <Samu> I still don't understand why my AI has a preference for mail routes
22:24:25 <Samu> maybe Im requesting too much passenger production from towns
22:43:30 *** rubenwardy has joined #openttd
22:44:56 <nielsm> the MT-32 versions are distinct from the FM synth and General MIDI ones!
22:45:15 <nielsm> not just because of the different synth, it's actually unique midi data
22:50:22 <DorpsGek_III> [OpenTTD/OpenTTD] j-pet opened pull request #7727: Fix: Use natural sort when sorting the file list. https://git.io/fjjjC
23:03:51 <nielsm> I'm probably doing something wrong in labeling in all the auxillary files also containing version information, if this is to be an RC
23:04:35 <LordAro> probably doesn't matter too much...
23:16:58 <glx> maybe debian stuff needs more
23:21:45 <glx> I think I need to check previous tags :)
23:29:56 <nielsm> that should really be everything done
23:38:23 <nielsm> preparing a newspost atm
23:38:44 <glx> another review would be nice, just to be sure
23:40:36 <LordAro> do translations need updating?
23:40:49 <LordAro> or leave that til actual release?
23:42:22 <nielsm> if someone knows how to merge translations please do so
23:42:30 <nielsm> it can probably wait until actual release
23:42:40 <glx> someone used to have a script
23:43:30 <LordAro> frosch123 has done it in the past...
23:44:42 <LordAro> should be added to the wiki page either way :p
23:48:07 <frosch123> can't remember whether there were corner cases where it failed
23:56:32 <nielsm> can someone else review/merge the RC and then tag it? I can't stay up for much longer
continue to next day ⏵
