Times are UTC Toggle Colours
00:19:32 *** nielsm has quit IRC 00:30:07 *** Flygon has joined #openttd 00:31:49 *** supermop_Home_ has joined #openttd 00:32:08 <supermop_Home_> yo Pikka 00:32:17 <Pikka> yoyo! 00:33:01 <supermop_Home_> hows it going down there? 00:33:16 <supermop_Home_> hopefully not too smokey where you are? 00:34:12 <Pikka> not too bad here. we're not getting the worst of it this far north... 00:52:19 *** Wormnest has quit IRC 01:06:40 <supermop_Home_> sounds pretty bad in the news we get here 01:10:34 <Pikka> it is 01:11:30 <Pikka> about once a week they get a 40 degree day and it kicks all the fires back up again... most of Victoria and NSW is at least under threat 01:14:23 <Pikka> 20+ people killed, hundreds of houses, millions of animals. good times and not at all climate change in action... 01:34:54 * Pikka bbl 01:34:55 *** Pikka has quit IRC 01:48:39 *** Progman has quit IRC 02:03:10 *** snail_UES_ has quit IRC 03:24:15 <floodious> it doesn't need a separate game thread, although that would be probably way more efficient due to multi-core processors it would need a ton of mutex stuff to be added to ensure it's thread-safe 03:25:08 <floodious> but the game loop might only take a short bit of time far less than 1ms, while each video frame is at least 33.333 ms, so if you're doing GUI updates every 1/10th ms that is a huge amount of unneeded processing overhead 03:25:45 <floodious> so therefore ANY GUI/video processing MUST happen no more frequently than 1/30*1000 ms 03:26:34 <floodious> the whole GUI related section should have "if (last_frame < frame_count) { last_frame = frame_count; ... } 03:26:56 <floodious> to ensure no graphical process occurs more than once per individual frame 03:28:30 <floodious> or a boolean can be used, set-only-if-clear on one side and clear-only-if-set on the other 03:29:55 <floodious> bool fresh_frame, draw() { if (!fresh_frame) fresh_frame = true; ... } 03:30:25 <floodious> UpdateWindows() { if (fresh_frame) { fresh_frame = false; ... } 03:32:03 <floodious> if they're the same thread that'll always be oscillating the state of the bool 03:33:33 <floodious> if you mean the video code uses v-sync or waits until at least 1/30*1000 ms has passed... that would severely impact the maximal performance of the gameloop, limiting it to no more than 30 cycles per second 03:34:22 <floodious> "fast forward" would only work by decreasing precision and jumping ahead in larger steps, still 30 cycles per second 03:36:04 <floodious> that would also directly tie framerate to game-time, such that lower framerates would slow down the passage of time, such that if for example it took longer to redraw the screen, gameplay would slow proportionately 03:36:43 <floodious> along with all related activities... which would explain the symptom of the cursor moving slowly when the gameloop takes too much time to process AI 03:38:16 <floodious> normally UI interaction is handled independent from processing functions like the gameloop, so the user interaction with the UI (real-time, user space) doesn't get negatively impacted as the CPU becomes bogged down doing game stuff 03:41:07 <floodious> normally you'd run the game-loop as core stuff, and between game cycles check if the frame-time has elapsed, then if so redraw and do all GUI update stuff (1/30*1000 ms) 03:41:38 <floodious> meanwhile the UI would be threaded to ensure stuff like the cursor position on screen isn't linked to processing load 03:42:27 <floodious> so the command "button clicked" would pass via its own thread, triggering mutex locks where needed to modify game-thread data... then the game/draw thread would process and update the screen 03:43:56 <floodious> to my knowledge most modern games worked that way since forever, since it wasn't possible to thread openGL or similar, all updates had to be single-threaded 03:44:37 <floodious> they still had independent timings for gameloop + redraw, and usually a UI thread separate from the game thread 03:45:10 <floodious> so you couldn't miss a button press or similar 03:47:28 <floodious> it's normally something like while (running) { while (gametime < realtime) { gameloop(); } redraw(); } 03:48:37 <floodious> the inner-loop (priority #1) is the core game functions and screen updates are secondary "in between" 03:52:09 <floodious> if gameloop() and redraw() both require 1 ms, but each game tick is 30 ms, redraw() will be called approximately 30 times per each real video frame (at 30 fps) 03:52:47 <floodious> 30 times for every single gameloop() call, which would total 31 ms, so gameloop() would happen twice in a row sometimes 03:57:24 *** D-HUND has joined #openttd 04:00:47 *** debdog has quit IRC 04:03:56 <floodious> fresh_frame is usually called "dirty" :) 04:19:26 *** glx has quit IRC 04:44:08 <floodious> cursor bug with win32_v.cpp is because DrawMouseCursor() is only called during idle, which is mutually exclusive with GameLoop() calls and ticks 04:44:22 <floodious> maybe 04:49:10 <floodious> nope, that's called from UpdateWindows() and the main loop idle 05:01:12 *** tokai|noir has joined #openttd 05:01:12 *** ChanServ sets mode: +v tokai|noir 05:08:09 *** tokai has quit IRC 05:21:53 <floodious> moving the DrawMouseCursor() call outside the gameloop tick check (with its own independent check at 16 ms) solves the cursor slowing, partially, but the main cause is that the heavy processing in the game loop isn't threaded, so during any single heavy function the cursor position is locked without updating 05:22:24 <floodious> threaded independently from UI, i mean 05:45:14 <dwfreed> separating game updates from graphics is not trivial; most games don't even bother with it, because it's easier to optimize the heavy processing 05:45:56 <floodious> it becomes a headache when stuff like AI is as heavy as in openttd, when the mouse cursor or UI interaction becomes so latent 05:46:16 <floodious> i'm not talking about game vs. graphics, i'm talking game vs. UI 05:46:24 <dwfreed> UI is graphics 05:46:27 <floodious> no 05:46:33 <floodious> UI is nothing to do with graphics 05:46:41 <floodious> UI is user interface, input from the user 05:46:48 <floodious> doesn't matter what's on screen 05:47:03 <floodious> stuff like the window message loop 05:47:20 <dwfreed> say input, then, not UI, because UI refers to what's on screen 05:47:35 <dwfreed> the buttons and the toolbars, etc 05:47:42 <floodious> right now that interferes with the gameloop, although it has priority, the gameloop is blocking on the window loop, so while a single heavy function is processing in gameloop(), UI is blocked completely 05:47:46 <floodious> that's unnatural 05:47:56 <floodious> UI refers to the window message loop, always 05:48:00 <floodious> GUI is what you are thinking 05:48:28 <dwfreed> either way, you're talking about user input, so just say that 05:48:32 <floodious> which is more honestly "graphical + user interface" 05:48:39 <floodious> UI = user interface = user input 05:49:40 <dwfreed> so why can't you use user input, so it's more clear what you're referring to, if they're all equal 05:49:54 <floodious> if it helps, assume I meant "U = user, I = input" 05:50:11 <floodious> if i mean graphics, I'll say "GUI" 05:50:48 <floodious> anyway even so, separating the UI message loop from the gameloop and redraw is hairy as it is 05:51:09 <dwfreed> which is why most games don't do it 05:51:29 <floodious> most games don't do so, since the gameloop doesn't normally do heavy processing in a single thread but launches additional threads for stuff like large file import/export and so on 05:51:54 <floodious> a lot of programs suffer from blocking the UI during processing, which sucks 05:52:21 <dwfreed> factorio doesn't, for example (which caused a huge issue when 0.17 first came out on macOS, because the message queue was receiving a ton of irrelevant messages) 05:56:57 <floodious> in this case the issue looks to be that the UpdateWindows() is synchronous with GameLoop(), so when heavy processing happens in UpdateWindows(), the game + UI + redraw all grind to a halt 05:57:34 <floodious> neither is tied to real graphical frame updates, they can happen freely between redraws as far as I can see 05:58:58 <floodious> haven't gotten to the graphical side yet 06:01:41 <floodious> I thought at first that limiting UpdateWindows() and making it asynchronous with GameLoop() and the UI window loop might help... obviously the source of the problem is the heavy processing itself, but it presents a symptom that reveals a larger design issue that brings to mind many other existing symptoms like cursor lag 06:27:35 <floodious> it seems all drawing is also single-threaded, only the OS level blit is threaded 06:31:18 <floodious> so this code is indeed bugged, but not in terms of "doesn't meet aims of design", rather the design was faulty to begin with 06:31:19 <floodious> hundredth_timer.SetInterval(3000); // Historical reason: 100 * MILLISECONDS_PER_TICK 06:31:33 <floodious> the 100th is of real-time, not game ticks 06:32:03 <floodious> but it's synchronous with game ticks and does not adapt to frame-rate 06:33:55 <floodious> question is, should the windows update every N game ticks, or every N milliseconds real-time, or some relationship to frames displayed (which is always synchronous with game ticks ATM, which is always synchronous with real-time) 06:34:14 <floodious> there is no scaling at all 06:37:32 *** Smedles has joined #openttd 07:23:12 *** snail_UES_ has joined #openttd 07:30:21 <floodious> I think in this case the 100th needs to be of game ticks, not the period of time a game tick _should_ take, but actually once every 100 successful ticks 07:31:07 <floodious> to achieve that, UpdateWindows() requires a tick count variable incremented once per actual game tick, regardless of how long that took or what the real-time clock is 07:31:53 <floodious> when the game-time slows, the portions of UpdateWindows() which rely on game-time will also slow proportionately 07:32:16 <floodious> which makes perfect sense for stuff like updating the town list to display changes in population 07:32:36 *** Progman has joined #openttd 07:34:53 <floodious> some clarification would be beneficial too, such as defining _realtime_tick is "real-time in milliseconds", nothing to do with "game-time" 07:35:38 <floodious> it happens to be incremented when GameLoop() executes, but is AFAIK just real-time ms 07:39:38 *** andythenorth has joined #openttd 07:39:40 <andythenorth> o/ 07:39:57 <floodious> you missed all my flooding the channel with ranting, hurray! 07:40:06 <floodious> congratulations! 07:42:52 <floodious> i'd change _realtime_tick to _realtime_ms 07:49:09 <floodious> or just fix the comment: The elapsed real time in ms, updated once per GameLoop() tick. 07:50:33 <floodious> unfortunately even that's hazy, since it's also forcibly updated from within modal loop(s?) 07:56:32 *** snail_UES_ has quit IRC 07:59:54 *** WormnestAndroid has quit IRC 08:00:16 *** WormnestAndroid has joined #openttd 08:06:26 *** sla_ro|master has joined #openttd 08:25:43 *** HerzogDeXtEr has joined #openttd 08:35:59 *** nielsm has joined #openttd 08:44:34 *** Smedles has quit IRC 08:46:16 *** Smedles has joined #openttd 09:01:54 <floodious> some heightmap progress: https://i.imgur.com/a6x8rz8.png (10k x 10k, 9 quads out of 24 total, still missing all additional river data, only rivers present are lower-right delta pair) 09:02:38 *** WormnestAndroid has quit IRC 09:02:50 *** WormnestAndroid has joined #openttd 09:10:20 *** Mazur has joined #openttd 09:14:00 <nielsm> morning 09:14:47 <andythenorth> moin nielsm 09:52:34 *** Wolf01 has joined #openttd 09:53:29 *** Lejving_ has joined #openttd 09:58:24 *** supermop_Home_ has quit IRC 09:59:00 *** Mazur has quit IRC 10:04:02 *** Lejving has quit IRC 10:04:02 *** Wolf01 has quit IRC 10:04:02 *** D-HUND has quit IRC 10:04:02 *** lpx has quit IRC 10:04:02 *** Osai has quit IRC 10:09:24 *** debdog has joined #openttd 10:09:56 *** Osai has joined #openttd 10:09:56 *** Wolf01 has joined #openttd 10:10:52 *** andythenorth has quit IRC 10:14:16 *** lpx has joined #openttd 10:14:58 <DorpsGek_III> [OpenTTD/OpenTTD] astetyn opened issue #7901: Train prefers service in depot over station https://git.io/Jeh7q 10:19:18 <DorpsGek_III> [OpenTTD/OpenTTD] nielsmh commented on issue #7901: Train prefers service in depot over station https://git.io/Jeh7q 10:27:51 <DorpsGek_III> [OpenTTD/OpenTTD] astetyn commented on issue #7901: Train prefers service in depot over station https://git.io/Jeh7q 10:34:58 <DorpsGek_III> [OpenTTD/OpenTTD] nielsmh commented on issue #7901: Train prefers service in depot over station https://git.io/Jeh7q 10:44:24 <DorpsGek_III> [OpenTTD/OpenTTD] astetyn commented on issue #7901: Train prefers service in depot over station https://git.io/Jeh7q 10:46:35 <michi_cc> nielsm: Changing the NTDDI_VERSION etc defines has no effect itself, but it means that the minimal SDK version for compiling increases (no problem there due to c++11 anyway) and that you can accidentally create an exe that only runs on newer windows. 10:59:05 *** Samu has joined #openttd 11:33:35 *** frosch123 has joined #openttd 11:48:06 *** zvxb has joined #openttd 11:59:56 *** Execthts has quit IRC 12:00:13 <Samu> hi 12:11:41 *** Exec has joined #openttd 13:23:31 *** NGC3982 has quit IRC 13:28:16 *** Flygon has quit IRC 13:52:53 *** andythenorth has joined #openttd 13:55:42 <andythenorth> yo 14:02:47 <nielsm> try out something: https://0x0.st/znGz.png 14:03:25 <nielsm> for comparison: https://0x0.st/znGK.png 14:03:34 <nielsm> (though different font, try to ignore that) 14:05:49 <nielsm> because that "Min ' ' ' ' Max" scale markings has been annoying me for a long time, it looks bad 14:24:05 *** glx has joined #openttd 14:24:05 *** ChanServ sets mode: +v glx 14:26:23 *** Mazur has joined #openttd 14:30:22 <DorpsGek_III> [OpenTTD/OpenTTD] nielsmh opened pull request #7902: Wedge volume control sliders https://git.io/Jejfp 14:32:21 <andythenorth> aliased edges bother me greatly 14:32:26 <andythenorth> goes it throw out limitation? 14:33:02 <nielsm> ? 14:33:13 <nielsm> making an AA fill will be problematic I think 14:33:29 <andythenorth> yes I agree :) 14:33:36 <andythenorth> are wedges widely used? 14:33:43 * andythenorth looking for examples to steal from 14:34:20 <nielsm> volume control from my music player: https://0x0.st/znDD.png 14:34:36 <andythenorth> oof https://f90.co.uk/assets/images/labs/mac-php-js-volume-control/desktop-home.jpg 14:34:57 <andythenorth> https://www.land-of-web.com/wp-content/uploads/2012/02/1324.jpg 14:35:45 <nielsm> hm this probably looks better: https://0x0.st/znDk.png 14:35:48 <andythenorth> let's see 14:35:52 <andythenorth> yes 14:35:59 <andythenorth> I just wondered about using vertical bars of increasing height 14:36:07 <andythenorth> probably more work than a triangle shape :D 14:36:41 * andythenorth photoshop 14:39:55 <andythenorth> basic improvement https://dev.openttdcoop.org/attachments/download/9595/volume-slider-1.png 14:42:41 <andythenorth> majority of UI controls I can find seem to be a bar, not a wedge, more space efficient 14:42:51 <andythenorth> I'm on the fence, the current one does suck 14:42:57 <LordAro> nielsm: yeah, just the one non-aliased edge looks better 14:43:10 <LordAro> though andy's improvement is better 14:43:40 <andythenorth> the min-max marker positions are the real issue? 14:43:58 <andythenorth> also it's non-discrete :D 14:44:20 <andythenorth> but the markers make it look like it should be discrete 14:44:52 <LordAro> a very basic improvement would be to remove the min-max strings 14:44:55 <LordAro> they don't add anything 14:45:15 <nielsm> https://0x0.st/znD5.png 14:46:11 <LordAro> looks blurry somehow 14:46:17 <andythenorth> mute and active speaker icons? o_O https://tr4.cbsistatic.com/hub/i/r/2016/10/05/a7dba7dd-32a0-4e48-aaec-ab97f219e753/resize/1200x/061ddf8281dfbdd21c7ac03e0381d40e/macsoundeckel092016.jpg 14:46:54 <andythenorth> oof the proportions of the window :) 14:47:13 <andythenorth> new jukebox? o_O 14:49:14 <nielsm> https://0x0.st/znDR.png 14:49:29 <LordAro> :+1: 14:49:54 <glx> yeah colour is better in this one 14:50:24 <nielsm> considering making a general DrawFramePolygon thing for this that selects shade of each outline depending on angle 14:50:29 <andythenorth> does it feel right to use? 14:50:37 <andythenorth> seems like it might not feel like it's in a track 14:51:39 <andythenorth> this was...unintuitive :P http://jsfiddle.net/onigetoc/j010vxc0/ 14:53:45 <DorpsGek_III> [OpenTTD/OpenTTD] nielsmh updated pull request #7902: Wedge volume control sliders https://git.io/Jejfp 14:54:14 <andythenorth> https://lyonsden.net/wordpress_s/wp-content/uploads/2019/05/IMG_20190504_143428-1024x768.jpg 14:54:21 <glx> andythenorth: and it's not fully sync 14:54:38 <nielsm> actually, my GfxFillPolygon function fails in a weird way with FILLRECT_CHECKER mode and I don't understand why 14:54:39 <andythenorth> https://image.shutterstock.com/image-vector/knob-button-volume-slider-bar-260nw-619693832.jpg 14:55:07 <andythenorth> let's see 14:55:26 <andythenorth> must be something in the ultimate UI source http://www.dasprogramm.co.uk/ 14:57:11 <andythenorth> still looks fresh, 60 years old http://www.dasprogramm.co.uk/shop/braun/view/50 14:57:48 <LordAro> andythenorth: nice 14:58:14 <LordAro> nothing really beats the look of audio equipment from that era 14:59:14 <peter1138> nielsm, bottom of wedge should be horizontal. 14:59:16 <andythenorth> nope 14:59:18 <peter1138> Oh. 14:59:22 <peter1138> The image changed. 14:59:39 <nielsm> and in RTL: https://0x0.st/znkz.png 14:59:41 <andythenorth> hmm all the RL audio gear has rotary knobs, but they're crap on screens 14:59:49 <peter1138> I had a late lunch. It was salad. With a couple of bao buns. 15:00:29 <LordAro> nielsm: i wonder whether the controls should be reversed in RTL 15:00:50 <LordAro> RTL languages aren't just "reverse everything" 15:00:51 <nielsm> 1x scale: https://0x0.st/znki.png 15:02:18 <nielsm> today's bike shed: volume sliders 15:02:19 <nielsm> :D 15:02:22 <peter1138> LordAro, no but if that's how the slider currently operates, the wedge needs to be correct :-) 15:04:59 <andythenorth> lol edition https://dev.openttdcoop.org/attachments/download/9596/volume-slider-1.png 15:05:21 <LordAro> andythenorth: :D 15:05:32 <peter1138> LGBTQ 15:05:35 * andythenorth back to trains 15:05:45 <andythenorth> peter1138: no blue or purple or pink 15:06:13 <nielsm> well that slider implies that more volume is greener 15:06:15 <nielsm> is that really true? 15:06:19 <andythenorth> we could do a nyan cat version 15:07:07 <peter1138> Bah at this Doom level. 15:08:29 <nielsm> and in TTD DOS: https://0x0.st/znkK.png 15:08:53 <nielsm> it has a "VU meter" indicating roughly how many notes are active in music playback atm 15:09:17 <peter1138> Has a slowly descending circular room with monsters spawning, nowhere to hide... 15:09:35 <peter1138> Are we missing the meter? Heh 15:09:55 <glx> we used to have it, but it was static IIRC 15:11:25 <nielsm> it would be very hard to implement with the current music driver model 15:11:26 <LordAro> it had been broken for a very long time 15:12:32 <glx> https://github.com/OpenTTD/OpenTTD/commit/ba7611ed131b0f99dae4ca974aa1cf9c6114b6f5#diff-1cb7ff4f0ed8c7e4020679ea03e670d6 15:13:13 <andythenorth> I miss that VU meter :) 15:13:29 <peter1138> Not too hard to add it back, then ;-) 15:13:33 <andythenorth> also the slider control tracks look better at that zoom level 15:13:51 <andythenorth> when I say 'I miss it', I haven't played the midi track for about 10 years :P 15:13:55 * andythenorth should declare 15:14:01 <nielsm> yeah the sprite font 1x gui sliders look fine 15:14:21 <nielsm> but it doesn't scale well to vector fonts or 2x gui 15:14:29 <andythenorth> nope 15:14:43 <andythenorth> I should scale my eyes, then switch back to 1x zoom 15:15:55 <andythenorth> just 18.99 https://www.amazon.co.uk/Professional-Headband-Magnifier-Magnifying-battery/dp/B01D86CQF4 15:22:58 <peter1138> Just use 640x480. 15:24:44 <andythenorth> let's see 15:25:50 <peter1138> 640x480 on a 14" screen, mind you. 15:26:31 <andythenorth> minimum monitor resolution I can do is 1024x640 15:26:34 <andythenorth> much easier to read 15:26:41 <andythenorth> can't fit much in tho :) 15:29:42 <andythenorth> photoshop at 1024x640 :P 15:29:47 <andythenorth> it's all just palettes 15:29:56 <andythenorth> no room for image 15:39:18 *** supermop_Home has joined #openttd 15:39:28 <supermop_Home> hi andy 15:39:53 <supermop_Home> ooops i left this game on all night unpaused 15:39:56 <andythenorth> yo 15:42:01 <supermop_Home> maybe i'll buy myself a rhino license this year 15:48:23 *** NGC3982 has joined #openttd 15:49:16 <milek7_> nielsm: why it would be hard? 15:49:23 <milek7_> can't just MxMixSamples write last sample to some global var? 15:49:45 <nielsm> not really when the music driver outputs to a hardware midi port 15:50:00 <nielsm> or when the music driver otherwise doesn't play through the same mixer as the rest 15:50:26 <nielsm> in fact, only the fluidsynth driver uses the game's mixer for output, everything else plays around it 15:51:25 <milek7_> huh, does anybody still have hardware midi? 15:51:34 <nielsm> me :) 15:53:44 <nielsm> a while ago someone also posted on the issue tracker about using extmidi with aplaymidi (which sends to a hardware port) having issues with skipping tracks causing hanging notes 15:54:08 <nielsm> (which is expected since extmidi just kills the process it spawned mercilessly) 15:56:00 <milek7_> how even extmidi works when music is in tar archive? 15:56:32 <nielsm> unpacks it I assume 15:56:44 <nielsm> similar to how the dos music decoder does 15:57:05 <nielsm> actually I don't think music in a tar archive is supported 15:57:06 <LordAro> in theory it could just read the file via offsets - tar is just a container after all 16:04:02 <frosch123> LordAro: rule of thumb for rtl: if the reversed thing looks weird to you, it's probably correct 16:04:18 <LordAro> frosch123: quite possibly 16:04:43 <LordAro> relatedly, i notice #6666 is still open 16:07:33 <frosch123> https://material.io/design/usability/bidirectionality.html <- that explicitly mentions the volume slider 16:09:00 <frosch123> LordAro: 7480 is merged though 16:09:40 <LordAro> the issue was apparently not fully fixed 16:47:44 <nielsm> bad ideas: https://wiki.openttd.org/User:Nielsmh/New_music_set_format 16:50:46 <nielsm> https://www.tt-forums.net/viewtopic.php?p=1228200#p1228200 wow hamachi, haven't heard that in a long time 16:51:08 <frosch123> cat is uncompressed wav/voc, isn't it? 17:00:32 *** Wormnest has joined #openttd 17:14:19 <andythenorth> so vehicle groups...and extended vehicle info / backstory thing? o_O 17:14:46 <andythenorth> or maybe the extended vehicle info / popup window thing is the only way to get to the variants? 17:14:48 <andythenorth> o_O 17:14:53 <nielsm> frosch123 not quite, it's just an archive file 17:15:05 <nielsm> that's most famous for containing sampled sound effects 17:15:17 <nielsm> but it also used for the music data in the DOS version 17:15:42 <frosch123> ah, so you want to store midi inside cat? 17:15:51 <nielsm> no, it _is_ stored inside cat :) 17:16:14 <nielsm> DOS TTD has gm.cat, adlib.cat, roland.cat containing music in various formats 17:16:41 <frosch123> ok, well my point was, i hope you do not want to store gigabytes of uncompressed cd audio 17:16:47 <nielsm> yeah no 17:17:48 <andythenorth> stream it! 17:17:56 <andythenorth> full circle, reverse engineer spotify! 17:18:19 <andythenorth> did Ludde actually build spotify, or just work there? 17:18:30 <nielsm> I want to add sampled music support at some point (have a WAV file proof of concept somewhere) but whether bananas would want to host music sets containing a gigabyte of flac files is another question :P 17:18:50 <andythenorth> sponsored edition :P 17:19:40 <LordAro> :D 17:19:47 <andythenorth> oh OpenTTD has scrolled to the N-most corner of the map and won't come out 17:19:48 <andythenorth> lolz 17:19:55 <andythenorth> I did change newgrfs in this game though 17:21:45 <DorpsGek_III> [OpenTTD/OpenTTD] nielsmh commented on pull request #7902: Wedge volume control sliders https://git.io/Jejkv 17:23:20 <LordAro> andythenorth: there are several things i might expect changing newgrfs to cause 17:23:33 <LordAro> affecting controls is not one of them 17:24:19 <andythenorth> it might be a bug reported before, I didn't look :) 17:24:24 <andythenorth> such diligence 17:24:35 <LordAro> sounds like stuck keyboard input 17:24:38 <LordAro> try pressing keys 17:26:53 <milek7_> 'Do not mirror media playback buttons and the media progress indicator as they refer to the direction of tape being played, not the direction of time. ' [https://material.io/design/usability/bidirectionality.html] 17:27:16 <andythenorth> nah it's some scroll issue 17:27:20 <andythenorth> I restarted, it's gone 17:28:31 <frosch123> milek7_: there was an older site which showed hardware vhs players with mirrored buttons 17:28:59 <andythenorth> oof 17:29:07 * andythenorth wonders about daylength 17:29:45 <frosch123> just wait until daylength is solved like subsidiaries 17:30:07 <andythenorth> looking if GS API has GSCheat 17:30:19 <andythenorth> might be looking wrong, can't see it 17:30:28 <andythenorth> GSDate is get, not set 17:30:30 <frosch123> it definitely has not 17:30:59 <andythenorth> I did have a patched client that reset the year on a tick-tock basis 17:31:01 <andythenorth> so 2:1 17:31:09 <andythenorth> but I lost the patch and Eddi claims it wasn't him 17:31:49 <andythenorth> I wonder if resetting every month would mess up newgrf less :P 17:32:39 <frosch123> maybe you can read up on leap seconds, and learn from those issues 17:32:40 <milek7_> it made X-axis on graphs wrong 17:34:13 <nielsm> okay checkering fixed https://0x0.st/zndk.png 17:34:59 <andythenorth> hmm 17:35:08 <andythenorth> nielsm: that's neat :) 17:35:16 * andythenorth has a cdist link that won't go away 17:35:35 <andythenorth> can I traverse the linkgraph somehow and sever the node? :P 17:35:54 * andythenorth imagines the savegame is not human readable 17:36:16 <andythenorth> I've been waiting about 50 years for cdist to learn there's no acceptance at the station it's sending stuff to 17:38:06 <LordAro> is the linkgraph saved? 17:40:13 <andythenorth> I assume so, as this link is persisting across restarts? 17:40:33 <andythenorth> oof 19fps 17:40:36 <andythenorth> 100% CPU 17:40:42 <andythenorth> this savegame might be dead 17:40:47 <FLHerne> andythenorth: Are you sure it doesn't actually exist? 17:40:56 <FLHerne> e.g. some train hiding in a depot, or refit orders 17:41:05 <andythenorth> there's a 'refit any available' at the pickup 17:41:15 <andythenorth> but that wasn't the cause 17:41:23 <FLHerne> Or locos with annoying small-amount-of-mail capacity :P 17:41:34 <andythenorth> I accidentally sent 1 train with Coal Tar wagon to the station 50 years ago 17:41:50 <andythenorth> I've since deleted that train, but the link persists because of 'refit any available' on the other trains 17:42:01 <andythenorth> it's not a bug, just annoying 17:42:11 <andythenorth> the fix would be to delete the route and rebuild it 17:42:52 <andythenorth> ok, 100 years of game, 133 trains, 37 RVs 77 ships 7 aircraft 17:43:01 <andythenorth> 20fps isn't really fun though, so might be time to stop 17:43:07 <andythenorth> I guess I broke it :) 17:45:19 <nielsm> okay looks like recolour and concave shapes both work: https://0x0.st/znd7.png 17:45:29 <andythenorth> :) 17:45:35 <andythenorth> going to do soviet flag etc? 17:45:40 <andythenorth> overlaid? 17:46:04 <nielsm> was just the first example I could think of that used recolour mode :P 17:46:26 * andythenorth wonders if FIRS is the cause of the fps issues 17:46:36 <andythenorth> it does a lot of stupid things 17:46:56 <nielsm> hey, I have a patch that can help diagnose that! 17:47:19 <nielsm> starface: https://0x0.st/zndC.png 17:47:25 <nielsm> (the code) 17:49:13 <andythenorth> the fps is pretty closely correlated with redrawing dirty blocks 17:49:19 <andythenorth> unless that's confirmation bias 17:49:36 <andythenorth> FIRS industries tend to have animation per tile, even if it's not doing much 17:49:41 <nielsm> yeah that's what I also kind of get when I try newgrf_profile on FIRS 3 17:49:43 <andythenorth> so 2-3 industries on screen kills fps 17:49:51 <nielsm> it spends a lot of time getting sprites for the tiles 17:49:53 <andythenorth> but also a busy train junction absolutely murders fps 17:50:08 <nielsm> some very deep callbacks 17:52:27 <DorpsGek_III> [OpenTTD/OpenTTD] nielsmh updated pull request #7902: Wedge volume control sliders https://git.io/Jejfp 17:53:09 <DorpsGek_III> [OpenTTD/OpenTTD] JGRennison opened pull request #7903: Fix: Assertion failure when post road-works cleanup removes all road pieces https://git.io/Jejkd 17:54:59 <andythenorth> hmm I could increase all the vehicle speeds to compensate for the fps 17:55:50 <andythenorth> @calc 87 * (1/0.6) 17:55:50 <DorpsGek> andythenorth: 145 17:55:56 <milek7_> variable length tick? 17:55:58 <andythenorth> 145mph train instead of 87mph 17:56:10 <andythenorth> oh but now it's 18fps 17:56:24 <andythenorth> @calc 18/34 17:56:24 <DorpsGek> andythenorth: 0.529411764706 17:56:35 <andythenorth> @calc 87 * (1/0.53) 17:56:35 <DorpsGek> andythenorth: 164.150943396 17:56:37 <andythenorth> hmm 17:58:05 <andythenorth> making everything transparent doesn't seem to help 17:58:10 <DorpsGek_III> [OpenTTD/OpenTTD] nielsmh approved pull request #7903: Fix: Assertion failure when post road-works cleanup removes all road pieces https://git.io/Jejkj 17:58:17 <andythenorth> is transparency applied after resolving all the sprites? 17:59:57 <nielsm> oh, no wonder I don't remember that setting (mod_road_rebuild) being there, it doesn't exist in the settings GUI 18:00:06 <nielsm> just a secret bonus feature 18:06:10 <nielsm> bonus-bonus feature I kind of want to make with this polygon filling function, later: replace some of the icon sprites used in text (close button X, other window caption buttons, the vehicle/transport mode icons) with vector shapes that can be rendered to a sprite of appropriate size for the selected font sizes 18:28:23 * andythenorth wonders about benchmarking same OpenTTD game on different OS / hardware 18:28:48 <andythenorth> not sure how we'd control for variation 18:30:07 <nielsm> hmm... maybe do something similar to "timedemo" in quake engine 18:30:47 <nielsm> enable "benchmarkgame" mode from console and give a number of ticks, the next savegame you load will disable interaction and run for that many ticks on fast forward 18:30:59 <nielsm> then go back to main menu and print the time taken in the console 18:31:16 <andythenorth> kind of wondering if I should switch to Windows 18:31:17 <nielsm> AI and GS should not be loaded in that mode either 18:31:31 <andythenorth> or if this is just crap hardware 18:33:29 <Samu> terron only thinks of crashing on my custom openttds :( 18:33:40 <Samu> have yet to have this crash on an official build 18:34:16 <LordAro> nielsm: isn't that basically how the ai regression tests work? 18:34:22 <LordAro> (except with the null video driver) 18:34:36 <nielsm> LordAro yeah :) 18:35:05 <LordAro> not sure if that runs on fast forward though 18:35:07 <nielsm> but for other benchmarking you probably do want to test the video output as well 18:35:17 <LordAro> mm 18:35:31 <nielsm> along with what happens when sprites need to be requested and so on 18:36:15 <andythenorth> https://dev.openttdcoop.org/attachments/download/9597/slow_on_macos.zip 18:36:21 <andythenorth> runs around 0.7x most of the time 18:36:30 <andythenorth> sometimes 0.5x 18:36:36 <andythenorth> occasionally 1x 18:36:45 <andythenorth> it's slow enough to no longer be fun, everything lags 18:37:09 <andythenorth> in an area with no trains / industry it's 1x trivially, so my system can run the game 18:38:01 <andythenorth> I'm running self-compiled nightly, I should try it in 1.10 beta 18:40:07 <Samu> im not reporting this anymore 18:43:14 <andythenorth> official beta is better fps 18:43:38 <floodious> did anyone look at that timing bug? 18:43:51 <floodious> i discovered the issue: there is no game tick reference in the game, at all 18:43:52 <floodious> zero 18:43:54 <LordAro> floodious: no one wrote anything on the issue, so no 18:44:22 <floodious> the only reference is real-time-ms, which happens to be "updated each game tick", but otherwise has nothing at all to do with game ticks 18:44:40 <floodious> so the solution: need to add a game-tick counter to be referenced to by code that needs to execute every N game ticks 18:45:10 <nielsm> you haven't looked hard enough 18:45:36 <floodious> and i suggested fixing the comment on the existing ms reference counter: _realtime_tick = The elapsed real time in ms, updated once per GameLoop() tick. 18:45:37 <nielsm> date_func.h has uint16 _tick_counter 18:45:46 <DorpsGek_III> [OpenTTD/OpenTTD] DorpsGek pushed 1 commits to master https://git.io/JejLJ 18:45:46 <DorpsGek_III> - Update: Translations from eints (by translators) 18:46:00 <floodious> who updates _tick_counter 18:46:06 <nielsm> the game loop 18:46:29 <floodious> so it's not available outside, but can be used in UpdateWindows() 18:46:39 *** Wormnest has quit IRC 18:47:01 <floodious> so solution: #1) fix comment on _realtime_tick #2) replace any code intended to execute N ticks with _tick_counter 18:47:21 <floodious> _realtime_tick has nothing to do with game time 18:47:38 <floodious> anything using it as a reference for elapsed in-game time will fail, and is bugged 18:48:40 <floodious> any arbitrary amount of ms can pass during a single tick 18:49:44 <nielsm> andythenorth: I'm able to run that game at 200+ fps 18:49:56 <andythenorth> ok 18:50:12 <andythenorth> do you have some huge CPU? 18:50:15 <nielsm> although I am missing the chips_objs.grf, and the iron horse version you included seems to be wrong 18:50:44 <nielsm> core i5-4460 3.2 ghz 18:50:48 <andythenorth> chips should be on bananas, and the horse has just been reload many times 18:51:58 <nielsm> nope chips_objs.grf is not on bananas it seems 18:52:14 <andythenorth> oh 18:52:18 *** jlx_ has joined #openttd 18:52:20 <andythenorth> that's odd :) 18:52:24 <andythenorth> is your build self-compiled? 18:52:50 <nielsm> yes 18:53:16 *** WormnestAndroid has quit IRC 18:53:27 *** WormnestAndroid has joined #openttd 18:53:30 <andythenorth> I am getting better results with the official binary, maybe I've got debug turned up 18:55:22 <andythenorth> how do I compile with NO_DEBUG_MESSAGES? 18:56:38 <andythenorth> -DNO_DEBUG_MESSAGES=1 18:56:39 <andythenorth> ? 19:02:35 <andythenorth> can't find NO_DEBUG_MESSAGES anywhere in the repo to crib from :) 19:05:04 <floodious> i'm able to reproduce the game slowdown with the version i have, displaying town directory 19:05:55 <floodious> the whole thing runs at slug pace, but by replacing _realtime_tick delta_ms with a new delta_ticks computed from _tick_counter, it doesn't exponentially spiral to a halt 19:06:43 <floodious> i'm only getting pulses where sorting the list takes 500ms + 19:07:13 <nielsm> it makes sense for the town directory to re-sort on game time and not real time, since towns' data change in game time and not real time 19:07:31 <floodious> yes, so i set it to 100 ticks, not 100*ms_per_tick 19:08:14 <floodious> since each tick atm is taking 25 ms, and rendering/sorting the town list is 500 ms++ 19:08:21 <floodious> so tick = ~525 ms 19:10:46 <andythenorth> nielsm: what fps do you get when you open train list in that save? 19:11:17 <andythenorth> also when did we gain a plot of the fps? :o 19:12:55 <floodious> displaying timing graphs: https://i.imgur.com/byCoSkq.png (looks like it claims 1032 ms pulses, i was reading averages) 19:14:54 <nielsm> https://0x0.st/znn5.jpg 19:16:17 <floodious> on a 2k map with 1500+ towns population 1.5 million? :) 19:17:02 <floodious> i misread that, pop = 3 mil 19:17:31 <nielsm> I'm just testing andy's save here 19:18:02 <floodious> could it be settings? 19:18:10 <andythenorth> https://dev.openttdcoop.org/attachments/download/9598/vehicle-window-windowshade-fps.m4v 19:18:25 <nielsm> no it's probably differences between the video output on windows and mac 19:19:14 <floodious> doesn't it use the same renderer (sse2 blit?) and only the bitmap blitter is actually different? 19:19:19 <nielsm> well okay shading/unshading shouldn't affect video output 19:19:51 <andythenorth> the mac performance is known to be very poor 19:20:44 <floodious> i know xcode is hell to work with because they're even more picky than gcc, and loaded with bugs in their c++ implementations 19:21:09 <floodious> but the underlying systems in my experience have performed near identically 19:21:19 <LordAro> last time i checked xcode uses clang... 19:21:55 <floodious> not just clang itself, but the other elements of their IDE with error detection and such failing or locking up on perfectly valid code 19:22:16 <nielsm> yeah though it's their own special version of clang 19:22:27 <nielsm> but afaik several of the clang main committers are employed at apple 19:22:48 <LordAro> apple is one of the founding "members" of clang 19:23:58 <nielsm> andythenorth: when you do that shade/unshade, do any of the game loop timings change, or just the rendering timing that you have the graph of up? 19:25:05 <andythenorth> possibly, I'll video 19:25:55 <nielsm> if it's just 2 ms extra in total but it causes fps to drop from 33-34 down to 16-17 then there's something weird with timing or time slices or vsync going on 19:26:41 <nielsm> i.e. it crosses some threshold that makes something decide to skip every second chance of processing a frame 19:33:23 <andythenorth> https://dev.openttdcoop.org/attachments/download/9599/vehicle-window-windowshade-fps-2.m4v 19:33:26 <andythenorth> inconclusive imho 19:36:42 <floodious> town dir: even with the 100 tick mod, sorting by name or rating is still getting sporadic peaks of 80 ms 19:38:05 <floodious> that's obviously not due to OnHundredthTick since i set the interval = 1e9 and it never gets called 19:38:14 *** HerzogDeXtEr has quit IRC 19:38:47 <floodious> population sort peaks at 8 ms instead 19:40:46 <floodious> nope, double-checked, it's OnHundredthTick 19:42:16 *** Arveen2 has quit IRC 19:43:39 <floodious> triple check: it isn't OnHundredthTick... wtf 19:53:12 <Samu> hi 19:53:14 <Samu> :p 19:57:42 <floodious> most sorting seems to be triggered by forcerebuild calls via changes to towns 19:58:40 <floodious> a limit could be imposed by marking a "rebuild needed" flag and only checking and actually rebuilding in the OnHundredthTick trigger 20:00:10 <nielsm> probably a good idea yes 20:00:28 <floodious> obviously the heavy lifting is mistakenly being directly applied elsewhere, somehow... i'm switching to debug since the compiler inlined too much stuff and breakpoints weren't working right 20:02:44 <floodious> it's triggered in OnPaint() too 20:03:18 <floodious> town_gui.cpp ln 951: if (this->towns.NeedRebuild()) this->BuildSortTownList(); 20:03:28 <floodious> so commenting that line out might solve it 20:04:48 <Samu> in 1.9.3 there's no issue 20:05:33 <floodious> the fact redraw triggers a rebuild is a severe bug 20:05:47 <floodious> so just commenting that ln 951 fixes it 20:06:01 <floodious> it draws the existing (old) list, and the rebuild happens on a timer 20:06:39 <floodious> the heavy pulses then only happen every 100 ticks, which i've also fixed the timebase (ticks, not realtime ms) 20:07:11 <Samu> line 951 is a } 20:07:29 <floodious> well, the if (this->towns.NeedRebuild()) this->BuildSortTownList(); 20:07:37 <floodious> in whatever revision, whatever line it moves to 20:07:39 <Samu> 949 20:08:27 <floodious> it improves redraw performance in normal situations since you're only wanting to redraw to fill that area on the screen, not "update" the list 20:09:15 <Samu> testing 20:10:15 <floodious> in my GUIs I use window buffers so such updates are fast blitter copies instead of manually redrawing into a single canvas bitmap, but with too many windows open that causes memory issues... modern OSes also use buffers in the hardware, since you have GPUs with several gigs and window buffers take 100s of megs at most generally 20:10:31 <floodious> that only matters when redraw is also expensive 20:11:09 <Samu> i suspect it's the query box 20:11:51 <floodious> what is? 20:12:55 <floodious> unchecking the query triggers a smaller spike (31%?) for me too, but that doesn't seem like a major issue ... it might make sense to also delay the rebuild from the query change too 20:13:20 <floodious> but that would introduce UI latency 20:13:26 <floodious> usually considered bad 20:14:00 <floodious> unchecking, unfocusing i mean 20:15:45 <Samu> gonna reroll to before https://github.com/OpenTTD/OpenTTD/pull/7621 20:15:48 <Samu> rebase 20:15:50 <nielsm> the ottd display model does work with dirty rectangles 20:16:12 <floodious> https://i.imgur.com/AjToOG2.png 20:16:19 <nielsm> when a window/widget is asked to repaint, it can check the _cur_dpi (afaik) for the dirty rectangle 20:17:02 <floodious> the issue is repaint was triggering heavy lifting (rebuilding / sorting the list), and since we have the existing old list that can just be redrawn anyway 20:17:23 <floodious> if the list wasn't yet built, that may be an issue 20:17:43 <floodious> but dirty rects wouldn't optimize away needing to re-fill the graphical content of the town directory window 20:18:08 <floodious> if something dirtied the rect, triggering the redraw 20:18:32 <floodious> window buffer could optimize away the redraw itself, making it a fast copyblit, but that's it 20:19:03 <nielsm> true 20:19:22 <nielsm> there isn't any good way to allocate a back buffer and render to instead 20:19:34 <nielsm> in fact that would require massive gymnastics 20:20:03 <floodious> i have a quite nice implementation, but yeah given the existing openttd structure, wouldn't want to jump in that 20:21:34 <nielsm> the best long term solution would probably be to scrap the entire current display pipeline and replace with something opengl or such, and maybe make every window be a texture on its own 20:21:42 <Samu> erm how do I rebase to a build in the past? 20:21:54 <Samu> somehow I can't do it again 20:22:20 <nielsm> how many commits do you want to put on top of it? 20:22:31 <Samu> 0 20:22:43 <nielsm> then it's not a rebase 20:22:45 <Samu> want to go to before https://github.com/OpenTTD/OpenTTD/commit/196d586849684e62aa9a40093f2a1ce60e1cd53f#diff-294725a20bc5c3ec869659c417143f65 20:23:03 <nielsm> if you just want to build an older version, use "git checkout revisionhash" 20:23:12 <Samu> ah, i see 20:24:27 <Samu> testing the commit before that 20:24:30 <Samu> see if it's slow 20:27:02 *** frosch123 has quit IRC 20:30:55 <Samu> nop, it's much faster 20:32:01 <Samu> there's the occasional spike, but much less noticeable 20:34:03 <Samu> how do i get out of this detached head mode? 20:34:24 <nielsm> checkout master 20:34:28 <nielsm> or whatever branch you want 20:36:16 *** mreow has joined #openttd 20:37:02 <mreow> hi. im using firs, i wonder, why cant i get farm supplies nor fruits to load in my train? 20:37:20 <mreow> do i have to supply the bulk terminal with something? 20:37:25 <Samu> oh snap, there was an easier way with visual studio 20:37:37 <mreow> (oops sorry if its dev chan) 20:37:46 <nielsm> mreow no, they produce without any input 20:37:47 <andythenorth> mreow: do you have wagons for those cargos? 20:37:56 <mreow> i think i do have 20:38:19 <mreow> i mean, it does indeed look like these wagons dont allow this cargo but huh 20:38:24 <andythenorth> hmm 20:38:29 <andythenorth> this keeps coming up on reddit 20:38:44 <mreow> oh i think why 20:39:08 <mreow> i didnt refit them 20:39:14 <mreow> i just bought the carts 20:39:16 <Samu> now with Commit 196d5868 20:39:18 <Samu> testing 20:39:27 <nielsm> mreow yeah that can do it 20:39:46 <mreow> i think that was that, thanks 20:39:51 <mreow> yep, totally :D 20:40:00 <nielsm> good news: in next version (will be 1.10) if you filter the purchase list by vehicles that carry a specific cargo, they auto-refit to that cargo on purchase 20:40:23 <nielsm> you can try 1.10 beta2 already now :) 20:40:32 <Samu> uggg, i found the faulty commit 20:41:10 <Samu> https://github.com/OpenTTD/OpenTTD/commit/196d586849684e62aa9a40093f2a1ce60e1cd53f 20:41:30 <mreow> im too lazy :D 20:41:32 <Samu> this causes all the lag in town directory 20:41:45 <floodious> mreow, the standard wagons can't carry non-standard cargo, and the system is a bit tricky to navigate because all the parts you need are more or less independent 20:42:20 <mreow> i mean, i had the wagons for that but i just didnt refit them properly; i bought them and left it like that 20:42:22 <floodious> to carry NARS cargo, you need a NARS compatible wagon/rolling stock set 20:42:51 <floodious> yep, refitting is a pain too, the orders happen backward if you use "refit at station" it needs to occur on a separate order before the loading order 20:43:24 <DorpsGek_III> [OpenTTD/OpenTTD] SamuXarick commented on issue #7899: Slow framerates with town list window https://git.io/JepK9 20:43:27 <floodious> on the same order "stop at station, refit to cargo, full load cargo" it refits last, so it'll sit and never load 20:43:59 <DorpsGek_III> [OpenTTD/OpenTTD] LordAro approved pull request #7903: Fix: Assertion failure when post road-works cleanup removes all road pieces https://git.io/JejqN 20:44:10 <DorpsGek_III> [OpenTTD/OpenTTD] LordAro merged pull request #7903: Fix: Assertion failure when post road-works cleanup removes all road pieces https://git.io/Jejkd 20:45:27 <mreow> oh, i didnt know you can do tricks like that 20:45:46 <floodious> sadly i've found in my limited experience it's 100% about tricks, never so simple as you think at first 20:47:15 <andythenorth> floodious: 'refit at station with full load' works fine 20:47:23 <andythenorth> any case where it doesn't is a bug 20:47:52 <floodious> i'd need to test it, but it never worked on a single order for me 20:48:18 <andythenorth> my orders always look like this https://dev.openttdcoop.org/attachments/download/9600/refit-orders.png 20:48:35 <floodious> possibly a bug in specific newgrfs 20:48:46 <andythenorth> the 'no loading' is required for cargodist btw 20:48:51 <andythenorth> in case the audience is wondering 20:48:57 <andythenorth> it prevents backlinks being created 20:50:23 <mreow> ho huh hmm 20:50:34 <DorpsGek_III> [OpenTTD/OpenTTD] LordAro commented on pull request #7902: Wedge volume control sliders https://git.io/JejmT 20:50:38 <floodious> very complicated for a sandbox game :) 20:51:07 <DorpsGek_III> [OpenTTD/OpenTTD] LordAro approved pull request #7900: Add: Highlight item under mouse in file browser https://git.io/JejmL 20:51:29 <DorpsGek_III> [OpenTTD/OpenTTD] LordAro merged pull request #7894: Fix #7587: Crash when loading saves with waypoints with invalid locations https://git.io/JexpT 20:51:30 <DorpsGek_III> [OpenTTD/OpenTTD] LordAro closed issue #7587: Loading old waypoints from savegame version 72 causes crash https://git.io/fjWZr 20:51:44 *** supermop_Home has quit IRC 20:51:47 <andythenorth> oof tech tree progression is hard 20:51:48 <DorpsGek_III> [OpenTTD/OpenTTD] LordAro merged pull request #7884: Fix #6667: Also recalculate bridge costs for 'spectated' AI companies https://git.io/JeA1Y 20:51:49 <DorpsGek_III> [OpenTTD/OpenTTD] LordAro closed issue #6667: Incorrect costs in bridge list after joining an AI company https://git.io/Jejmt 20:52:20 <DorpsGek_III> [OpenTTD/OpenTTD] LordAro merged pull request #7843: Industry directory cargo filtering https://git.io/Jei1a 20:53:04 *** supermop_Home has joined #openttd 20:53:32 <andythenorth> is there a hotkey for 'stop replacing vehicles'? 20:53:53 <andythenorth> clearing out auto-replace rules is the worst yak-shaving currently in the game 20:54:22 <floodious> did anyone adopt my tick timebase + redraw bug triggers town directory rebuild+resort changes? i'd need to create a github account to add my solution to the git comment thread or remember some existing account 20:54:52 <floodious> https://github.com/OpenTTD/OpenTTD/issues/7899 20:55:37 <LordAro> floodious: as we quite often have to tell Samu, anything said in irc is emphemeral - if it's not in an issue, it's going to get forgotten 20:55:43 <floodious> or should i go through the whole process of reporting that as a separate bug 20:56:06 <LordAro> i think it's probably a separate bug 20:56:19 <floodious> two infact, although they're all related to the same symptom 20:56:20 <LordAro> even if the fix for one might fix the other as well 20:56:36 <glx> floodious: I think the idea of really using ticks for tick stuff is good, but it should be said on github ;) 20:56:48 <floodious> the thread linked reported a symptom/cause which triggered the bugs i've fixed 20:56:53 <floodious> bah fine i'll make an account 20:58:48 <glx> oh and you can even open a PR if you have a fix :) 20:59:14 <floodious> if i learn how first 20:59:33 <floodious> git... ugggh 21:00:29 <glx> fork openttd to your github account, clone your fork to your machine, do your changes and commit them to a branch, push to github, open a pull request 21:00:58 <glx> first 2 steps needed only once ;) 21:01:46 <supermop_Home> andythenorth: how complex are the auto replace schemes you have going on at any given time? 21:04:40 <floodious> yes i know how to do the work itself, but how to actually get git working, successfully open firewall ports to make my version of git work correctly, successfully apply the patch to the proper branch and build a single, clean commit into a pull request is the real issue 21:04:46 <floodious> all that overhead = modern git tools 21:05:01 <nielsm> git can work over just outgoing https 21:05:06 <nielsm> or outgoing ssh 21:05:09 <floodious> i have 100% whitelist 21:05:15 <floodious> no connections not directly authorized 21:05:39 <floodious> the git toolchain has tens of different tools 21:05:52 <floodious> error reporting on a failure is a smug "something happened" 21:06:28 <nielsm> if you run git over ssh, it'll use the system ssh client and work through pipes 21:07:10 <floodious> i know... a week later after i get it all working, last time i tried to local clone the tree i ended up just grabbing the archive file since days later i couldn't get the git toolchain working 21:07:27 <floodious> anyway i'll just write an issue(s) to start 21:11:19 <andythenorth> supermop_Home: just Horse makes a lot of upgrades necessary :( 21:11:56 <supermop_Home> how often do you need to stop an upgrade? 21:12:37 <milek7_> floodious: i think all that problems are self-imposed ;) 21:12:52 <andythenorth> supermop_Home: when the list of old ones gets too long :) 21:13:25 <andythenorth> my current group has 12 old upgrades 21:13:26 <andythenorth> :P 21:15:11 <mreow> im curious, how much do you make in openttd in say, 1950-1960? if anyone plays in that period... like basically, first 10 starting years or something 21:17:08 <andythenorth> supermop_Home: should I? o_O https://en.wikipedia.org/wiki/Brighton_Belle 21:20:05 <floodious> milek7_, we should all be using whitelist-only, that's the only true secure method 21:20:09 *** sla_ro|master has quit IRC 21:20:18 <floodious> yes, certainly self imposed, but git is written by filthy non-secure methods 21:20:40 <floodious> it assumes a wild&free access to ports for network i/o 21:21:25 <milek7_> i prefer my system to not fight me trying to run anything 21:21:35 <LordAro> i'd be surprised if it used anything other than ssh/http as specified 21:21:38 <floodious> mreow, it's possible to get into millions quite easily, depending upon specific cargo, distances, running costs, etc 21:22:00 <mreow> oh, i clearly suck then 21:22:10 <floodious> nah, it depends so much on exact settings 21:22:18 <mreow> no breakage 21:22:32 <floodious> sometimes you can have only a few trains making millions, and the same trains with slightly different settings are in the red instead due to high running cost 21:22:50 <mreow> complex 21:23:02 <mreow> ive had million making lines much much latex 21:23:04 <mreow> later 21:23:19 <floodious> the game doesn't have even a simplified supply&demand economy, so cost vs. fees aren't balanced dynamically 21:24:51 <mreow> tho ive heard payments change over time? floodious 21:25:01 <floodious> normally for example people get mad that ordering some TV off amazon costs 0 to ship, but they fly the same distance themselves paying 0 even though they weight nearly the same, nearly same volume 21:25:36 <mreow> never heard of that tbh 21:25:44 <mreow> i mean, people complaining like that 21:26:05 <floodious> oh they do, there is a reason amazon's focus is on getting shipping costs as low as possible 21:26:27 <floodious> but that's real-world economics, which are far more complicated than the simple supply-side drive in ttd 21:27:19 <floodious> my point is for example grayhound bus service always made money by shipping packages, even if most people thought they were a passenger company, the passenger service never made enough on its own due to limited demand 21:27:50 <floodious> recently grayhound tried to redefine themselves as "a passenger company", and they went out of business in large areas of north america because of that 21:28:11 <floodious> the passenger service was run at a net negative, which attracted business to the profitable shipping parts 21:28:22 <floodious> by trying to turn a profit on passenger service, the whole company failed 21:28:57 <floodious> PHB optimization "everything must be a profit!" "cancel/fire the tech-support division!" 21:29:40 <mreow> im not really in american stuff 21:29:51 <floodious> i don't know any euro/asia examples 21:29:56 <mreow> i dont even think we've got amazon here lol 21:29:57 <FLHerne> mreow: The quick-win way to make all the money is to build airports in largeish cities at opposite corners of the map 21:30:00 <mreow> i mean, we've got warehouses 21:30:31 <floodious> mail in ttd pays high, so shipping mail long distances by plane usually makes you instant billions 21:30:45 <FLHerne> Set up buses or trains with "transfer and leave empty" orders at those airports and "no unloading" anywhere else 21:30:49 <FLHerne> Hey, infinite money 21:31:00 <mreow> wait lemme try that 21:31:10 <mreow> hah 21:31:17 <FLHerne> Of course, because it's easy and not really fun once you've one it once, most people don't bother 21:31:55 <floodious> yeah with a real supply/demand economy model, that would fail when your competitors drove passenger service profit to zero margins 21:32:23 <FLHerne> "Competitive" multiplayer servers usually have other metrics, like growing a single town or delivering a given amount of cargo 21:33:11 <FLHerne> And single-player tends to be either "historically accurate" or "just *how* complex can the signalling get?!" 21:33:16 <floodious> another major problem with ttd is the running cost computation isn't fuel-based, so you can climb super high mountains cheaply, it's almost always cheaper to go in a straight line than the long-way-round 21:33:18 <milek7_> i feel that game trying real to have realish economy mode would be too obtuse and boring 21:33:38 <floodious> just like real life! 21:33:54 <FLHerne> I mean, I think most players *do* start by trying to make lots of money 21:33:54 <floodious> where we spend all our time creating models in games to make them more like real life... 21:34:18 <FLHerne> And it's fun, until you've discovered all the ways to do it, and then it's too easy :P 21:34:34 <floodious> lol imagine writing a newgrf that created hobby programmers who you had to supply with ramen + mountain dew to create the openttd inside openttd inside openttd 21:35:24 <floodious> sometimes realistic models bring about a new appreciation for realities and encourage learning though, which some people find very fascinating while sand-box gaming is boring 21:35:27 <floodious> (myself) 21:37:50 <mreow> wut lol is that steam powered plane 21:38:17 <floodious> microsoft's flightsim on steam 21:38:34 <floodious> AKA steam-powered plane 21:38:42 <floodious> ms.steam-powered 21:38:48 <floodious> like ms.pacman 21:39:01 <milek7_> FSX refresh or something new? 21:40:24 <Samu> i found something! line 429 of town_cmd.cpp InvalidateWindowData(WC_TOWN_DIRECTORY, 0, 1); 21:40:39 <Samu> it sets data to 1 21:41:03 <Samu> switch(data) case TDIWD_FILTER_CHANGES: 21:41:08 <Samu> seems wrong 21:41:17 <Samu> there was no filter changes 21:41:41 <Samu> it's using the wrong invalidator, if I'm reading this correctly 21:41:44 *** WormnestAndroid has quit IRC 21:41:53 <floodious> yes i saw that when stepped through, but i have no idea how that's supposed to work 21:42:00 <floodious> it didn't seem to be working correctly 21:42:03 <glx> I guess it's a line from before the filter Samu, so quite possible 21:43:40 <DorpsGek_III> [OpenTTD/OpenTTD] floodious opened issue #7904: Tick-based UpdateWindows() calls use incorrect real-time ms https://git.io/Jejmx 21:44:08 <Samu> it should be calling this->towns.ForceResort(); 21:44:25 <Samu> but it's calling this->towns.ForceRebuild(); 21:44:43 <glx> let me check the code globally :) 21:48:04 <floodious> samu, so you're adopting my "comment out to fix" stuff? should i post an issue for it too? 21:48:22 <Samu> i wonder how many different "data" values are passed to towndirectory 21:48:41 <glx> Samu: ok I'm checking all calls and fixing where needed 21:51:24 <mreow> openttd is so hypnotising 21:57:06 <glx> Samu: https://github.com/OpenTTD/OpenTTD/compare/master...glx22:town_dir 22:01:31 *** Mazur has quit IRC 22:02:03 <DorpsGek_III> [OpenTTD/OpenTTD] floodious opened issue #7905: TownDirectoryWindow::OnPaint() triggers large (>50ms) redraw times https://git.io/JejYt 22:04:26 *** rtrdd has joined #openttd 22:07:03 *** zvxb has quit IRC 22:07:03 *** rtrdd has quit IRC 22:09:12 <supermop_Home> andythenorth: I still don't see any DVTs, 08s, etc in IH 2.3.0 22:09:24 <supermop_Home> what am i doing wrong here 22:21:21 <floodious> it might be a good idea to replace all the naive c-style uint values with something like a type-safe ticks_t or realtime_ms_t 22:21:23 <Samu> gonna test 22:21:33 <floodious> but that might be a large refactor 22:21:58 <floodious> also might require using structs and operators instead of base types 22:22:36 *** Pikka has joined #openttd 22:22:36 <floodious> since using tick_t = uint32; isn't type-safe, and i'm not aware c++11/etc has any force-type-safety feature for typedef/using 22:22:45 <LordAro> i was gonna say 22:22:57 <LordAro> using structs sounds tedious though 22:23:12 <floodious> it's a pain, why can't they implement a typesafe keyword 22:23:25 <floodious> c++20... 22:23:54 <floodious> the arguments have been "because that's redundant" "we should replace everything like enum class and make it inherently typesafe without the option" 22:24:00 *** WormnestAndroid has joined #openttd 22:24:01 <floodious> 20 years later 22:24:02 <LordAro> C++20 has already been finalised, i think :p 22:24:08 <floodious> i know, gah 22:24:36 <floodious> just add a keyword you buggers... if programmers are using variables named "typesafe" that should be their problem, what a dumb variable name 22:24:40 <LordAro> and i'm not aware of any existing proposal for type safety in that way, which makes C++23 rather unlikely as well 22:24:51 * LordAro hands floodious some _Bools 22:25:03 <glx> yeah and C++17 is still waiting for support ;) 22:25:04 * floodious hands back some ints x = -1 22:25:19 <floodious> _Bool x = -1 22:25:21 <floodious> yey 22:27:03 <Samu> glx, you didn't add a case TDIWD_FILTER_RESORT:, will it use default? 22:27:25 <LordAro> floodious: https://godbolt.org/z/ijtVSD i am a bit disappointed that there isn't even a warning 22:27:28 <glx> yeah it will go to default 22:27:35 <LordAro> Samu: that's how default works, yes 22:27:44 <Samu> ok 22:28:10 * floodious hands LordAro a typedef enum { true = 0, false, maybe } _Bool; 22:30:40 <Samu> glx [img]https://i.imgur.com/FHW1Bpd.png - problem solved! 22:31:28 <LordAro> problem improved, anyway 22:31:30 <DorpsGek_III> [OpenTTD/OpenTTD] glx22 opened pull request #7906: Fix #7899, 196d5868: don't trigger filter changes more than expected https://git.io/JejYP 22:34:02 <DorpsGek_III> [OpenTTD/OpenTTD] LordAro approved pull request #7906: Fix #7899, 196d5868: don't trigger filter changes more than expected https://git.io/JejY1 22:34:33 <andythenorth> supermop_Home: check the 'Joker' parameter? 22:34:37 <andythenorth> it's supposed to default to on 22:34:45 <andythenorth> Pikka bob 22:34:47 <glx> I guess some other windows have similar issue (magic values are bad ;) ) 22:34:59 <Pikka> bordig 22:35:07 <andythenorth> I was thinking 22:35:12 <andythenorth> NARS Horse 22:35:12 <Pikka> uhoh 22:35:19 <andythenorth> 1920-1990, and 5x daylength :P 22:35:27 <andythenorth> 4 generations 22:35:33 <andythenorth> :P 22:35:34 *** Samu has quit IRC 22:35:44 <Pikka> why daylength? 22:36:45 <andythenorth> longer game :) 22:37:20 <andythenorth> probably 1.5x would be enough :P 22:38:40 <DorpsGek_III> [OpenTTD/OpenTTD] JGRennison commented on issue #7905: TownDirectoryWindow::OnPaint() triggers large (>50ms) redraw times https://git.io/JejYt 22:41:15 <DorpsGek_III> [OpenTTD/OpenTTD] floodious commented on issue #7905: TownDirectoryWindow::OnPaint() triggers large (>50ms) redraw times https://git.io/JejYt 22:41:27 <Pikka> 4 generations... big steam, huge steam, F7s, GP38s? 22:42:23 <supermop_Home> andythenorth: i don't have such a parameter 22:42:34 <supermop_Home> just roster and capacity 22:46:22 <DorpsGek_III> [OpenTTD/OpenTTD] JGRennison commented on issue #7905: TownDirectoryWindow::OnPaint() triggers large (>50ms) redraw times https://git.io/JejYt 22:46:43 <supermop_Home> andythenorth https://imgur.com/a/fhE3DqR 22:46:44 *** WormnestAndroid has quit IRC 22:46:53 <DorpsGek_III> [OpenTTD/OpenTTD] floodious commented on issue #7905: TownDirectoryWindow::OnPaint() triggers large (>50ms) redraw times https://git.io/JejYt 22:48:03 <DorpsGek_III> [OpenTTD/OpenTTD] floodious commented on issue #7905: TownDirectoryWindow::OnPaint() triggers large (>50ms) redraw times https://git.io/JejYt 22:48:36 *** WormnestAndroid has joined #openttd 22:50:02 <DorpsGek_III> [OpenTTD/OpenTTD] LordAro commented on issue #7905: TownDirectoryWindow::OnPaint() triggers large (>50ms) redraw times https://git.io/JejYt 22:50:04 <DorpsGek_III> [OpenTTD/OpenTTD] nielsmh merged pull request #7900: Add: Highlight item under mouse in file browser https://git.io/Jepid 22:51:30 <DorpsGek_III> [OpenTTD/OpenTTD] LordAro merged pull request #7906: Fix #7899, 196d5868: don't trigger filter changes more than expected https://git.io/JejYP 22:51:30 <DorpsGek_III> [OpenTTD/OpenTTD] LordAro closed issue #7899: Slow framerates with town list window https://git.io/JepK9 22:51:54 <DorpsGek_III> [OpenTTD/OpenTTD] floodious commented on issue #7905: TownDirectoryWindow::OnPaint() triggers large (>50ms) redraw times https://git.io/JejYt 22:54:53 <DorpsGek_III> [OpenTTD/OpenTTD] JGRennison commented on issue #7905: TownDirectoryWindow::OnPaint() triggers large (>50ms) redraw times https://git.io/JejYt 22:55:17 *** mreow has quit IRC 22:56:31 <DorpsGek_III> [OpenTTD/OpenTTD] floodious commented on issue #7905: TownDirectoryWindow::OnPaint() triggers large (>50ms) redraw times https://git.io/JejYt 22:57:27 <andythenorth> supermop_Home: o_O https://dev.openttdcoop.org/attachments/download/9601/2-3-0.png 22:57:47 <andythenorth> Action 14 sometimes gets cached, what happens if you restart OpenTTD? 23:00:39 *** Progman has quit IRC 23:07:30 <DorpsGek_III> [OpenTTD/OpenTTD] LordAro opened pull request #7907: Fix e558aa8: Compiler warning about unused value https://git.io/JejOs 23:07:36 <andythenorth> Pikka: I read the post also :) 23:14:27 *** Wormnest has joined #openttd 23:14:47 <supermop_Home> andythenorth that's on bananas? 23:15:31 <andythenorth> supermop_Home: should be 23:15:40 <andythenorth> the roster name is a clue, that changed a long time ago 23:15:51 <andythenorth> somehow your OpenTTD is showing old values 23:16:00 <andythenorth> I don't know if that's my error or OpenTTD 23:19:32 <supermop_Home> check online content claims i have latest version 23:21:05 <andythenorth> screenshot suggests you do too 23:21:59 <DorpsGek_III> [OpenTTD/OpenTTD] floodious commented on issue #7905: TownDirectoryWindow::OnPaint() triggers large (>50ms) redraw times https://git.io/JejYt 23:22:04 <andythenorth> hmm 23:23:41 <DorpsGek_III> [OpenTTD/OpenTTD] glx22 approved pull request #7907: Fix e558aa8: Compiler warning about unused value https://git.io/JejOR 23:25:48 <andythenorth> supermop_Home: it doesn't help, but the roster name changed in 2016 https://github.com/andythenorth/iron-horse/commit/c03e5d0c5ba288f737a85992e3ad4cb6061dcab2 23:29:43 <andythenorth> I've definitely seen action 14 caching cause similar issues 23:29:51 *** nielsm has quit IRC 23:29:52 <andythenorth> but it shouldn't persist beyond a restart 23:31:23 <DorpsGek_III> [OpenTTD/OpenTTD] LordAro merged pull request #7907: Fix e558aa8: Compiler warning about unused value https://git.io/JejOs 23:35:11 <supermop_Home> ok 23:36:15 <andythenorth> sorry can't think what else to suggest :| 23:36:40 <supermop_Home> restarting ottd didn't do anything so i guess ill restart the computer 23:37:07 <andythenorth> ouch 23:37:33 <andythenorth> my 2.3.0 is from bananas 23:37:36 <andythenorth> I checked 23:43:10 *** zvxb has joined #openttd 23:45:00 <DorpsGek_III> [OpenTTD/OpenTTD] floodious commented on issue #7905: TownDirectoryWindow::OnPaint() triggers large (>50ms) redraw times https://git.io/JejYt 23:45:13 *** lpx has quit IRC 23:45:37 <supermop_Home> removing from active grfs and then re-adding fixed??? 23:46:11 <supermop_Home> roster name still 'my kingdom for a horse' tho 23:47:02 <andythenorth> oof 23:47:40 <andythenorth> it's probably because the parameter name and values haven't changed 23:47:46 <andythenorth> just the string for value 0 23:48:07 <andythenorth> but 4 years is a long time for OpenTTD to cache that :x 23:48:39 <supermop_Home> have plow and 08, no dvt 23:49:02 <supermop_Home> though it is 1985, maybe too early? 23:49:38 <supermop_Home> this computer is less than 4 years old 23:49:46 <supermop_Home> its about 18 month 23:51:46 <andythenorth> https://firs-test-1.s3.eu-west-2.amazonaws.com/iron-horse/docs/html/trains.html#driving_cab_pony_gen_5 23:51:55 * andythenorth should sleep 23:52:01 <andythenorth> reading about HP / ton though 23:52:02 <andythenorth> "MPH / 18.75* = HP (per ton); the HP requirement will increase roughly proportionally to the grade and speed." 23:52:12 <andythenorth> OpenTTD is pretty accurate for that 23:52:31 <andythenorth> @calc (5200/785) * 18.75 23:52:31 <DorpsGek> andythenorth: 124.203821656 23:52:53 <Pikka> andythenorth, o/ 23:52:57 <floodious> is it possible already with newgrf to dynamically compute running costs? 23:53:09 <floodious> like by summing fuel usage 23:53:12 <andythenorth> my 5200hp 785t train does 124mph on flat 23:53:21 <andythenorth> floodious: more or less yes 23:53:28 <andythenorth> it's been done 23:53:33 <floodious> must be hard to get it working, since most sets don't 23:53:49 <Pikka> floodious, it's really not worth doing anything too complex 23:54:01 <floodious> i've found most starting costs are way too high, i assume i can't figure out the intended application for the sets 23:54:01 <andythenorth> Pikka: I should have stopped in 1995 :D After that is a right pain in the arse 23:54:33 <Pikka> 1995 is "current day" for TTD ;) 23:54:43 *** lpx has joined #openttd 23:55:04 <andythenorth> the tech tree gets very broad :" 23:55:24 <glx> floodious: some mix of newgrfs can mess the costs too 23:55:24 <floodious> well base running cost = maintenance by age, then add (maintenance_rate*wear + fuel_rate*power) in a relatively simple approximation 23:55:26 <andythenorth> progression suggests faster trains, and more 'bigger' engines 23:55:38 <andythenorth> but existing trains don't need huge stats jumps 23:55:43 <andythenorth> to more models are implied :P 23:55:45 <Pikka> floodious, that's more or less what NARS2 did before 2.5 23:55:50 <floodious> hmm 23:55:56 <andythenorth> to / so /s 23:56:09 <Pikka> but it's such an inconsequential effect, and hard to communicate to the players 23:56:24 <Pikka> these days my trains just get 1/4 running costs when stationary 23:56:39 <floodious> is it? fuel costs were the main factor behind train route selection in the past, so grades more than 2 or 3 were the limit 23:57:05 <floodious> since efficiency is dropping at some exponential rate, there is an ideal HP output 23:57:21 <supermop_Home> wife's sewing machine has lost all feet but the zipper foot 23:57:24 <floodious> wear + energy cost = something like ^3 or even ^4 23:57:31 <supermop_Home> my sewing machine is 500 miles away 23:57:53 <supermop_Home> buy generic presser feet, or ship my better machine? 23:58:01 <supermop_Home> or buy an even better one 23:58:55 <floodious> i guess to estimate grade you'd need to min/max window over a distance traveled, then compute the height difference over that distance to estimate the grade (assume flat grade) 23:59:13 <floodious> fitting like that is tricky 23:59:23 <andythenorth> it just doesn't show up as useful in the game 23:59:49 <floodious> it would make climbing a mountain cost 1000x as much as going around