Log for #openttd on 5th January 2020:
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: (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
10:19:18  <DorpsGek_III> [OpenTTD/OpenTTD] nielsmh commented on issue #7901: Train prefers service in depot over station
10:27:51  <DorpsGek_III> [OpenTTD/OpenTTD] astetyn commented on issue #7901: Train prefers service in depot over station
10:34:58  <DorpsGek_III> [OpenTTD/OpenTTD] nielsmh commented on issue #7901: Train prefers service in depot over station
10:44:24  <DorpsGek_III> [OpenTTD/OpenTTD] astetyn commented on issue #7901: Train prefers service in depot over station
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:
14:03:25  <nielsm> for comparison:
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
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:
14:34:36  <andythenorth> oof
14:34:57  <andythenorth>
14:35:45  <nielsm> hm this probably looks better:
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
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>
14:46:11  <LordAro> looks blurry somehow
14:46:17  <andythenorth> mute and active speaker icons? o_O
14:46:54  <andythenorth> oof the proportions of the window :)
14:47:13  <andythenorth> new jukebox? o_O
14:49:14  <nielsm>
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
14:53:45  <DorpsGek_III> [OpenTTD/OpenTTD] nielsmh updated pull request #7902: Wedge volume control sliders
14:54:14  <andythenorth>
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>
14:55:07  <andythenorth> let's see
14:55:26  <andythenorth> must be something in the ultimate UI source
14:57:11  <andythenorth> still looks fresh, 60 years old
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:
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:
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
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:
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>
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
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> <- 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:
16:50:46  <nielsm>   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,, 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
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. ' []
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
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:
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:
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
17:53:09  <DorpsGek_III> [OpenTTD/OpenTTD] JGRennison opened pull request #7903: Fix: Assertion failure when post road-works cleanup removes all road pieces
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
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>
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
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: (looks like it claims 1032 ms pulses, i was reading averages)
19:14:54  <nielsm>
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>
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>
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
20:15:48  <Samu> rebase
20:15:50  <nielsm> the ottd display model does work with dirty rectangles
20:16:12  <floodious>
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
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>
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
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
20:44:10  <DorpsGek_III> [OpenTTD/OpenTTD] LordAro merged pull request #7903: Fix: Assertion failure when post road-works cleanup removes all road pieces
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
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
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
20:51:29  <DorpsGek_III> [OpenTTD/OpenTTD] LordAro merged pull request #7894: Fix #7587: Crash when loading saves with waypoints with invalid locations
20:51:30  <DorpsGek_III> [OpenTTD/OpenTTD] LordAro closed issue #7587: Loading old waypoints from savegame version 72 causes crash
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
20:51:49  <DorpsGek_III> [OpenTTD/OpenTTD] LordAro closed issue #6667: Incorrect costs in bridge list after joining an AI company
20:52:20  <DorpsGek_III> [OpenTTD/OpenTTD] LordAro merged pull request #7843: Industry directory cargo filtering
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>
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
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
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:
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
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: 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] - 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
22:34:02  <DorpsGek_III> [OpenTTD/OpenTTD] LordAro approved pull request #7906: Fix #7899, 196d5868: don't trigger filter changes more than expected
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
22:41:15  <DorpsGek_III> [OpenTTD/OpenTTD] floodious commented on issue #7905: TownDirectoryWindow::OnPaint() triggers large (>50ms) redraw times
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
22:46:43  <supermop_Home> andythenorth
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
22:48:03  <DorpsGek_III> [OpenTTD/OpenTTD] floodious commented on issue #7905: TownDirectoryWindow::OnPaint() triggers large (>50ms) redraw times
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
22:50:04  <DorpsGek_III> [OpenTTD/OpenTTD] nielsmh merged pull request #7900: Add: Highlight item under mouse in file browser
22:51:30  <DorpsGek_III> [OpenTTD/OpenTTD] LordAro merged pull request #7906: Fix #7899, 196d5868: don't trigger filter changes more than expected
22:51:30  <DorpsGek_III> [OpenTTD/OpenTTD] LordAro closed issue #7899: Slow framerates with town list window
22:51:54  <DorpsGek_III> [OpenTTD/OpenTTD] floodious commented on issue #7905: TownDirectoryWindow::OnPaint() triggers large (>50ms) redraw times
22:54:53  <DorpsGek_III> [OpenTTD/OpenTTD] JGRennison commented on issue #7905: TownDirectoryWindow::OnPaint() triggers large (>50ms) redraw times
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
22:57:27  <andythenorth> supermop_Home: o_O
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
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
23:22:04  <andythenorth> hmm
23:23:41  <DorpsGek_III> [OpenTTD/OpenTTD] glx22 approved pull request #7907: Fix e558aa8: Compiler warning about unused value
23:25:48  <andythenorth> supermop_Home: it doesn't help, but the roster name changed in 2016
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
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
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>
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

Powered by YARRSTE version: svn-trunk