Config
Log for #openttd on 6th January 2020:
Times are UTC Toggle Colours
00:00:10  <floodious> and the train would wear out in the attempt
00:00:32  <Pikka> floodious, all of this sounds like a lot of work for the grf author, and the end result will just be that the already optimal gameplay - straight, flat lines from one side of the map to the other - gets an even bigger advantage over other designs, making the game boring.
00:00:52  <floodious> that's due to the poor landscapes
00:00:52  <andythenorth> midnight
00:00:55  <andythenorth> I am a pumpkin
00:00:58  <floodious> i'm using real world heightmaps :)
00:01:06  <floodious> jumping over the peaks = cheaper
00:01:12  <supermop_Home> cannot really justify having 2-3 sewing machines in a tiny manhattan apartment unless i run a sweatshop out of it
00:01:28  * Pikka to the shops
00:01:32  <andythenorth> shall I delete Horse gen 6 (202 stuff) ?
00:01:33  <andythenorth> https://firs-test-1.s3.eu-west-2.amazonaws.com/iron-horse/docs/html/tech_tree_table.html
00:01:41  <floodious> the route is 10x longer finding a path along the 200 meter rise vs. 1800 meter peaks
00:01:53  <floodious> but the 10x longer makes it more expensive and slower!
00:02:00  <Pikka> if they're already done may as well leave them andy?
00:02:12  <andythenorth> I have 'balancing' issues :P
00:02:25  <andythenorth> due to power creep and bollocks :)
00:02:28  <Pikka> do it then ;)
00:02:34  * Pikka bbl
00:02:37  <andythenorth> or add one more train? :P
00:02:39  * andythenorth bed
00:02:42  <Pikka> goodnight
00:02:48  *** Pikka has quit IRC
00:02:51  <andythenorth> bye
00:02:51  *** andythenorth has left #openttd
00:03:19  <floodious> they used switchbacks in the past to climb slopes maintaining < 3 grade or similar
00:03:59  <floodious> totally impractical in ttd, since switchback corner costs the same as each single upward step, so the straight line beats it on power and distance
00:04:30  <DorpsGek_III> [OpenTTD/OpenTTD] JGRennison commented on issue #7905: TownDirectoryWindow::OnPaint() triggers large (>50ms) redraw times https://git.io/JejYt
00:11:16  <DorpsGek_III> [OpenTTD/OpenTTD] floodious commented on issue #7905: TownDirectoryWindow::OnPaint() triggers large (>50ms) redraw times https://git.io/JejYt
00:14:45  <DorpsGek_III> [OpenTTD/OpenTTD] floodious commented on issue #7905: TownDirectoryWindow::OnPaint() triggers large (>50ms) redraw times https://git.io/JejYt
00:24:29  *** Wolf01 has quit IRC
00:25:07  <DorpsGek_III> [OpenTTD/OpenTTD] floodious commented on issue #7905: TownDirectoryWindow::OnPaint() triggers large (>50ms) redraw times https://git.io/JejYt
00:33:30  <DorpsGek_III> [OpenTTD/OpenTTD] floodious commented on issue #7905: TownDirectoryWindow::OnPaint() triggers large (>50ms) redraw times https://git.io/JejYt
00:35:20  <DorpsGek_III> [OpenTTD/OpenTTD] JGRennison commented on issue #7905: TownDirectoryWindow::OnPaint() triggers large (>50ms) redraw times https://git.io/JejYt
00:37:07  <DorpsGek_III> [OpenTTD/OpenTTD] floodious commented on issue #7905: TownDirectoryWindow::OnPaint() triggers large (>50ms) redraw times https://git.io/JejYt
00:47:02  *** Flygon has joined #openttd
00:58:24  *** syr has quit IRC
00:58:53  *** syr has joined #openttd
01:34:40  <DorpsGek_III> [OpenTTD/OpenTTD] floodious commented on issue #7905: TownDirectoryWindow::OnPaint() triggers large (>50ms) redraw times https://git.io/JejYt
01:49:01  <DorpsGek_III> [OpenTTD/OpenTTD] James103 opened issue #7908: "Show the NewGRF name in the build vehicle window" is missing the "On/Off" display. https://git.io/JejGm
01:57:54  *** snail_UES_ has joined #openttd
01:59:08  <floodious> https://en.wikipedia.org/wiki/Heh_(god)
02:03:37  *** Wormnest has quit IRC
02:40:26  <FLHerne> floodious: Your comments seem a bit arrogant, really
02:41:40  <DorpsGek_III> [OpenTTD/OpenTTD] JGRennison commented on issue #7905: TownDirectoryWindow::OnPaint() triggers large (>50ms) redraw times https://git.io/JejYt
02:41:59  <FLHerne> The point of NeedsRebuild() is explicitly to invalidate the references; the design isn't "flawed" or a "pre-existing bug"
02:43:38  <FLHerne> Once that flag is set, the contents of the list are, semantically, no longer valid references
02:43:54  <FLHerne> They might as well be uninitialized
02:44:48  <FLHerne> (well, it's apparently flawed from a performance standpoint here, but it's functionally and semantically correct)
02:48:05  <FLHerne> It's quite a common pattern in C code; assuming that the "C++ 'OOP' textbook way" is the only valid one will only lead to grief in many codebases
02:50:37  <FLHerne> Also, you keep explaining - at great length - things that everyone already knows
02:51:49  <DorpsGek_III> [OpenTTD/OpenTTD] floodious commented on issue #7905: TownDirectoryWindow::OnPaint() triggers large (>50ms) redraw times https://git.io/JejYt
02:52:40  <FLHerne> Most of the time, that seems to be because you don't understand what /they're/ trying to explain, and misinterpreting it as something naive
02:53:56  <FLHerne> I'm very sure JGR understands how rarely towns are removed. His objection isn't about the performance of that, it's about being pragmatic in not generating code churn when it's not necessary
02:55:09  <FLHerne> (incidentally, the "separate re-sort" flag idea sounds like a good solution to me)
03:03:56  <floodious> yes
03:04:05  <floodious> then the bug is setting that flag in the first place where it isn't actually needed
03:04:22  <floodious> why does it continue to work with a supposedly invalid list?
03:05:02  <floodious> maybe it works incorrectly, but that would be handled by simply removing the invalid values... doing a bulk repopulate of the whole list is a lot of overhead
03:05:15  <floodious> it's like swatting a fly with a nuke from orbit
03:06:42  <floodious> this "brushing it off as not important" is what the source of these issues is rooted in to begin with
03:06:58  <floodious> letting that buzz around is like allowing wasps to build a nest in your source-tree
03:07:02  <floodious> suddenly you'd getting stung
03:07:50  <floodious> i know i'm saying things that are obvious, which is why they need be said
03:08:13  <floodious> i'm speaking from an architectural POV, where you build solid foundations
03:08:24  <floodious> excuses like "we can't multi-thread anyway because ..." are awful
03:08:39  <floodious> ... because you refuse to even take the first steps to ensure it becomes possible one day?
03:09:00  <floodious> "tossing your garbage here in the park is fine, nobody uses the bins anyway"
03:09:10  <floodious> well how did the park get so filthy to start?
03:23:46  *** tokai has joined #openttd
03:23:46  *** ChanServ sets mode: +v tokai
03:30:39  *** tokai|noir has quit IRC
03:35:52  <FLHerne> floodious: It doesn't continue to work with the list, it makes a new list when needed
03:36:16  <FLHerne> Oh, misparse, sorry
03:36:54  <FLHerne> I assume you did try deleting some towns while testing that?
03:38:34  <FLHerne> My guess is that, since towns are allocated as part of a pool, the released memory is very likely to still exist and retain its contents
03:39:05  <FLHerne> Until a new town gets allocated or the pool is shrunk (not sure if that actually happens)
03:39:19  <FLHerne> But obviously you can't depend on that
03:44:33  <FLHerne> Re. the other stuff -- how many large, old production codebases have you worked on? They're always like that. Going about rewriting arbitrary stuff because it doesn't fit the latest design fad tends to create more problems than it solves
03:45:09  <FLHerne> It "got so filthy to start" because SMP consumer processors /literally didn't exist/ when TTD was first written
03:46:03  <FLHerne> (or for some years afterward)
03:47:06  <floodious> nope, deleting a town is a valid thing
03:47:14  <floodious> i didn't bother testing it yet, but i assume it must assert or something
03:47:22  <floodious> if it doesn't that's an additional bug
03:47:39  <floodious> my point was the majority of triggers for the NeedsRebuild() are NOT that
03:47:44  <FLHerne> There are parts of OTTD that use threads, like Cargodist, because that does a big pile of work and was written after they existed
03:48:01  <floodious> independent things yes, those are small steps
03:48:34  <floodious> aiming to make everything work without globals, with proper responsibility for allocation and deallocation, etc are all important
03:48:36  <FLHerne> Ok, then "> why does it continue to work with a supposedly invalid list?" is answered by "because you didn't test the situation where that breaks"
03:48:57  <floodious> no, commenting the bug I reported, the OnPaint() function works
03:49:10  <floodious> why test a known valid case? the issue is all the invalid cases
03:49:31  <floodious> if the valid case is the only trigger that makes sense, all other triggers need to be eliminated by a new flag
03:49:54  <floodious> but, the existing case also isn't valid since the only invalidated item on the list is the single deleted item, not the whole pool
03:50:01  <floodious> so that also needs a fix
03:50:13  <FLHerne> Your phrasing is very confusing
03:50:16  <floodious> making the NeedsRebuild() invalid, and can be deleted entirely
03:50:27  <floodious> it's never used in a valid way
03:50:35  <FLHerne> It's not /invalid/ to mark the list as dirty
03:50:46  <floodious> it's never used, so why have it? look at the result
03:50:49  <floodious> it got abused
03:51:11  <FLHerne> It's a defined behaviour that leads to the desired results
03:51:19  <floodious> that's fine, then it needs to be enforced
03:51:31  <FLHerne> Could it be done in a more-performant way? Sure
03:51:43  <floodious> but at the moment, to my knowledge it's never used anywhere in the existing code, and there is no known reason the pool would ever become invalidated
03:52:06  <floodious> perhaps for future cases like moving a window context "across worlds", like running two game instances at once and moving the window between them
03:52:36  <FLHerne> Is it /worth doing/ in a more-performant way? Apparently (although it's worked like that for years without much complaint)
03:52:51  <floodious> it's not a "value"
03:52:56  <floodious> it's true/false correctness
03:53:01  <floodious> it's currently false
03:53:14  <FLHerne> Ok, that's where you lose me
03:53:28  <FLHerne> In what way is the current code actually /wrong/
03:53:29  <FLHerne> ?
03:53:44  <FLHerne> Yes, it's using a sledgehammer to crack a nut
03:53:46  <floodious> it invalidates the list when only a single item is not valid
03:53:51  <FLHerne> Sledgehammers crack nuts
03:53:51  <floodious> the list is valid
03:54:02  <FLHerne> No, the list is invalid, because a value in it is invalid
03:54:06  <floodious> sledgehammers smash nuts, shell and content
03:54:24  <floodious> the list isn't invalid in a majority of cases the flag is applied
03:54:31  <floodious> so it's applied invalidly
03:54:37  <FLHerne> It would also be correct to invalidate the list every time for no particular reason
03:54:46  <floodious> go ahead if you like
03:55:46  <floodious> it's bug-prone and wildly inaccurate
03:56:02  <floodious> if you can't understand why that's an issue, you're not a programmer i want working on anything i use
03:56:04  *** D-HUND has joined #openttd
03:56:11  <FLHerne> I'm not saying the current behaviour is optimal, but claiming that it's "bug-prone" or "inaccurate" is just misleading
03:56:20  <floodious> how so?
03:56:22  <floodious> prove it.
03:56:34  <floodious> show me the number of cases it's used validly, vs. invalid
03:56:38  <FLHerne> It's erring on the side of /correctness/ at the cost of performance
03:56:39  *** snail_UES_ has quit IRC
03:56:45  <FLHerne> I keep saying this
03:56:50  <floodious> no, a majority of applications are pure invalid
03:56:57  <floodious> it's plain bad programming
03:57:52  <FLHerne> It's not invalid to mark something as dirty, if it happens not to be dirty in the way you care about
03:58:01  <floodious> it's not dirty at all
03:58:58  <floodious> it's fraud to operate a laundry and charge people for ten washes when one wash was enough
03:59:24  <floodious> or to be a cabbie and drive in circles or take the long way when business is slow
03:59:31  *** debdog has quit IRC
03:59:34  <FLHerne> The whole point of this is that the list sorting is now invalid, yes?
03:59:36  <floodious> that's plain fraud, bad programming, bad faith
03:59:46  <FLHerne> And that it's getting triggered more often that you'd expect
03:59:46  <floodious> no, the list is valid
03:59:52  <floodious> the sort gets updated once every 100 ticks
04:00:00  <floodious> OnPaint() should never trigger anything list-related
04:00:01  <floodious> period.
04:00:10  <floodious> it simply draws an existing list, or not
04:00:24  <FLHerne> ...except that isn't what it does
04:00:28  <floodious> that's the bug!
04:01:00  <FLHerne> The code not conforming to your idealized mental picture of how it should work isn't a bug
04:01:25  <floodious> a bug is performance against the intent by the author, but it depends how you define it
04:01:30  <floodious> i prefer the term "user-issue"
04:01:51  <floodious> but generally "issue" is considered to carry other meanings related to production process
04:02:09  <FLHerne> I don't see that "the sort gets updated once every 100 ticks" is a sane hill to die on anyway
04:02:32  <floodious> that's the intent of the code, unless you prove otherwise
04:02:44  <floodious> or show the design that is ideal
04:02:56  <floodious> the existing on100ticks() function was also bugged
04:03:08  <floodious> which is the intended trigger for re-sort and  re-display of the window
04:03:33  <FLHerne> Hm, I'll agree that part is probably an actual bug
04:04:04  <floodious> OnPaint() is used to fill a dirty rect on screen, which is supposed to use data according to current state (last update), not force an update which might trigger a double-update in the same tick (redundant, wasted)
04:04:49  <floodious> so the other bug I posted is that OnPaint() can mis-trigger a repopulation of the list due to abuse of the flags, which assumes the list is invalid when it is not (merely flagged for update on next 100th tick)
04:05:19  <floodious> while it's arguable that it's valid on deleting a town, there are as you said more optimum methods to achieve it, it is pure UI triggered, not automatic
04:05:32  <floodious> so i wouldn't even care, it's just a symptom of a greater design flaw
04:05:42  <FLHerne> It's definitely not valid on deleting a town
04:06:32  <floodious> the list overall is, but i'd totally accept the overhead of "smashing a nut with a sledge" as you say
04:06:42  <floodious> just that 99.999% of the time, that's not the trigger source
04:06:55  <FLHerne> "abuse of the flags" is still nonsense
04:06:59  <floodious> it's pretty irrelevant, other than as an example case of the reason the flag existed to start
04:07:22  <floodious> it's the sole case where the list is genuinely invalid before the flag is set
04:07:45  <FLHerne> There's one relevant flag, that happens to include more events than either you or (apparently) whoever came up with the "100 ticks" thing expect
04:08:34  <floodious> flag is generally a bit, boolean state
04:08:41  <floodious> you mean the integer?
04:08:46  <FLHerne> So, the "100 ticks" code is broken, because it assumes behaviour that doesn't exist
04:09:00  <floodious> what behavior doesn't exist?
04:09:20  <FLHerne> No, I mean NeedRebuild()
04:09:37  <floodious> it doesn't call that
04:10:23  <FLHerne> The list can need rebuilding either because the items have potentially changed order, or because they've changed existence, or both
04:10:30  <floodious> UpdateWindows() in window.cpp calls w->OnHundredthTick();
04:11:00  <floodious> why would you rebuild a list when it needs resorting?
04:11:28  <floodious> building = immediate, sorting = latent on a timer
04:12:16  <FLHerne> OnHundredthTick() is ~broken because it assumes NeedRebuild() is rarely triggered, which isn't true when many towns exist because the population changes
04:12:35  <glx> basically the list is marked as rebuild by OnInvalidateWindowData(), then OnHundrethTick() handles it, unless an OnPaint() comes first
04:13:07  <floodious> It doesn't assume that
04:13:14  <floodious> fl; where are you getting this from?
04:13:44  <floodious> it merely triggers a rebuild every 100 ticks
04:13:51  <floodious> it assumes nothing, it's isolated from other components
04:13:56  <glx> no it triggers a resort
04:14:02  <floodious> well, okay
04:14:06  <glx> that may rebuild if needed
04:14:36  <floodious> i'm still trying to find the code, but it's definitely isolated from other assumptions and doesn't know about other portions of the system to make decisions at that point
04:14:40  <glx> that's why OnPaint() checks the need before calling to prevent useless resort
04:15:42  <floodious> void OnHundredthTick() override	{	this->BuildSortTownList(); this->SetDirty(); }
04:15:49  <floodious> seems to call it directly, does nothing with flags
04:16:04  <FLHerne> floodious: Yes
04:16:08  <glx> BuildSortTownList() checks NeedRebuild()
04:16:25  <glx> and does sorting inconditionnaly
04:16:41  <FLHerne> floodious: But it doesn't actually accomplish its effect of doing it every 100 ticks
04:16:44  <floodious> OnPaint checks the flag and triggers only when needed, but the trigger also comes from any update to any portion of any town, such as population changes or adding/changing houses regardless of sort more
04:16:46  <floodious> sort mode
04:17:04  <FLHerne> floodious: Because of that
04:17:09  <floodious> that's the bug!
04:17:24  <floodious> why can't you accept that
04:17:30  <glx> no, rebuild flag is only set when a town has been removed
04:17:45  <floodious> there is no way to moderate the CPU consumption of the window unless it has limits on activity
04:17:54  <glx> or created
04:17:58  <floodious> if you force such heavy lifting every frame update, every tick, there is no limit
04:18:02  <glx> https://github.com/OpenTTD/OpenTTD/pull/7906/files
04:18:18  <floodious> after you fixed it? my source is different
04:18:20  <floodious> there is only one flag
04:18:33  <floodious> it gets triggered sporadically due to updates to towns
04:18:37  <glx> yes there's only a rebuild flag
04:18:55  <glx> and other trigger are for sorting
04:19:00  <floodious> on a 2k map with 1 mil population, 1k towns, it triggers about every 4 or 8 ticks
04:19:15  <glx> but not a full rebuild
04:19:25  <floodious> no, OnPaint() calls rebuild
04:19:33  <glx> it shouldn't
04:19:43  <floodious> well, you just added the new sort flag, didn't you?
04:19:52  <floodious> i don't have the new code
04:19:57  <glx> no I fixed a bug
04:20:45  <floodious> well it was definitely being called way more often than it should, no town was ever deleted
04:20:47  <glx> when filtering was added, the old calls were not updated and triggered an apply filter when a resort was expected
04:21:21  <floodious> you said you thought maybe the issue was the filter changing each time even though it wasn't intended
04:23:11  <floodious> so that's the source of the trigger for the bug from town growth or changes, which got fed into OnPaint(), which then triggered rebuild/resort
04:23:16  <glx> https://github.com/OpenTTD/OpenTTD/blob/5b52f25902dad09e2f237ce798e9873a4ac42f4f/src/town_gui.cpp#L989
04:23:42  <glx> because the trigger was wrong and the filter string was empty it forced rebuild
04:23:53  <glx> but now it should be back to normal
04:24:07  <floodious> It should be possible to run huge maps with millions population and thousands of towns now with the list open, and only have it redraw the list (repopulate/resort) every 100 ticks max with all fixes applied
04:24:38  <glx> did you check with the latest source ?
04:24:51  <floodious> i haven't updated from applied patches no, just using my own patches
04:25:06  <floodious> but my build works fine with those applied
04:25:46  <glx> because now OnPaint() should very rarely call BuildSortTownList()
04:25:59  <floodious> i have to check the commits to see if all three/four of the patches got applied already
04:26:03  <floodious> yep
04:27:04  <glx> and usually OnPaint() calls it only if paint happens before 100th ticks
04:28:23  <floodious> right yes
04:29:01  <glx> a rebuild is a very rare event, and it doesn't happen in a game as town are never added or removed in game
04:29:27  <floodious> that's 99% of the way there, just the fact that the OnPaint() actually triggers the rebuild is the only remaining issue, but it's non-critical for sure
04:29:55  <floodious> since the rebuild ends up showing up in display profiling rather than other parts where it belongs
04:30:05  <FLHerne> Ok, I was wrong about where the bug was, partly because glx already fixed the actual cause :P
04:30:16  <floodious> yeah you're using the current rev?
04:30:20  <FLHerne> Yeah
04:30:26  <floodious> i'm talking before these fixes started to be applied
04:31:29  <FLHerne> That might explain some of the confusion
04:31:38  <floodious> sorry, i should have asked when you updated the source
04:31:57  <floodious> i haven't even looked closely at whether it was fully patched yet
04:32:17  <glx> usually we always talk about current version of the source :)
04:32:45  <floodious> well, it's weird saying "this isn't a bug" about a bug that just got patched :)
04:32:57  <floodious> it's a squashed bug, okay
04:33:19  <glx> the call from OnPaint() was not the real bug
04:33:34  <floodious> no it's just showing as part of the connection from source to symptom
04:33:56  <floodious> like "doc i have a cough!"
04:34:04  <floodious> "well it's your airway!"
04:34:07  <floodious> duh
04:35:11  <floodious> still, it's a work-around for OnPaint() to be cleaning up dangling references and triggering huge redraw latencies in rare conditions... solving that will be more tricky
04:36:39  <floodious> if all the renderer was threaded at some point that would affect framerates by glitching/locking the screen on rare instances where a town was deleted
04:37:06  <glx> drawing is threaded
04:37:31  <floodious> the blit to screen is, but the renderer is single-threaded with window message loop + gameloop + etc
04:37:49  <floodious> renderer = i mean actually copying bitmaps to the canvas
04:37:58  <floodious> the threaded part is the canvas copy to screeen
04:38:05  <glx> yes because every thing is related to the game state
04:38:12  <floodious> old c-style code :)
04:38:29  <floodious> when CPUs only had one core, and threads were what you stitched your shorts with
04:40:02  <glx> it comes from original asm
04:42:42  <glx> anyway I should be sleeping :)
04:42:43  <glx> bye
04:42:48  <floodious> have a good one
04:43:09  *** glx has quit IRC
04:54:34  *** Thedarkb-X40 has joined #openttd
05:00:57  *** HerzogDeXtEr has joined #openttd
05:01:03  <FLHerne> floodious: >  well, it's weird saying "this isn't a bug" about a bug that just got patched :)
05:01:23  <FLHerne> I didn't realize it had got patched since the version of the source you were looking at
05:01:45  <DorpsGek_III> [OpenTTD/OpenTTD] floodious closed issue #7905: TownDirectoryWindow::OnPaint() triggers large (>50ms) redraw times https://git.io/JejYt
05:01:45  <DorpsGek_III> [OpenTTD/OpenTTD] floodious commented on issue #7905: TownDirectoryWindow::OnPaint() triggers large (>50ms) redraw times https://git.io/JejYt
05:02:07  <FLHerne> ...or recently at all
05:02:40  <FLHerne> Thus reaching a wrong conclusion while trying to understand where the issue being discussed actually came from
05:04:04  *** supermop_Home has quit IRC
05:05:05  <floodious> that's honestly on reason i dislike git, since i could tell you the hash or whatever if i could find it, but it's not as simple as "r5122"
05:05:11  <floodious> one reason
05:06:23  <floodious> if i'd known glx already made the pull request and everything and confirmed it fixed it, i'd have just said that right away and been able to explain more clearly
05:06:29  <floodious> you're right that i'm hard to understand
05:37:02  *** Ttech has quit IRC
05:39:00  *** Ttech has joined #openttd
06:03:14  *** zvxb has quit IRC
06:07:43  *** HerzogDeXtEr has quit IRC
07:00:12  *** Wormnest has joined #openttd
07:24:56  *** andythenorth has joined #openttd
07:28:44  <andythenorth> is it though? :)
07:36:16  <andythenorth> no it isn't
07:46:14  <DorpsGek_III> [OpenTTD/OpenTTD] andythenorth commented on issue #7901: Train prefers service in depot over station https://git.io/Jeh7q
07:53:16  <FLHerne> andythenorth: It's not that
07:54:23  <FLHerne> The train gets to a signal, looks for a depot to service at
07:55:21  <FLHerne> When it sees a depot in range, it goes directly there, even if the route goes past its current order
07:56:04  * FLHerne vaguely remembers this being a pain, before getting completely fed up with breakdowns/servicing altogether
07:56:19  <FLHerne> It happens with autoreplace sometimes too
07:56:28  <andythenorth> seems like the correct answer would be hard to anticipate
07:56:45  <andythenorth> changing it leads to reports 'why does the train not go for servicing'
07:59:39  <FLHerne> I think the correct answer is, having found a path to a depot, simply forget about it if that path goes through the destination?
08:00:02  <FLHerne> The train will still go to the same depot after it's visited the station
08:00:29  <FLHerne> Unless the depot is only accessible from some tracks, or there's no signal after the platforms
08:01:17  <FLHerne> But that's much more of a user error
08:11:10  <Eddi|zuHause> i'm not convinced it's a situation that should be adressed
08:12:13  <Eddi|zuHause> you can use "service at" orders to prevent the situation
08:19:19  *** Wormnest has quit IRC
08:23:25  <DorpsGek_III> [OpenTTD/OpenTTD] nielsmh commented on pull request #7902: Wedge volume control sliders https://git.io/Jejls
08:29:27  *** tokai|noir has joined #openttd
08:29:27  *** ChanServ sets mode: +v tokai|noir
08:30:27  *** sla_ro|master has joined #openttd
08:34:48  <andythenorth> hmm
08:36:09  *** tokai has quit IRC
09:01:31  <DorpsGek_III> [OpenTTD/OpenTTD] LordAro commented on issue #7905: TownDirectoryWindow::OnPaint() triggers large (>50ms) redraw times https://git.io/JejYt
09:48:27  *** andythenorth has quit IRC
11:44:45  <DorpsGek_III> [OpenTTD/OpenTTD] astetyn commented on issue #7901: Train prefers service in depot over station https://git.io/Jeh7q
12:06:25  <DorpsGek_III> [OpenTTD/OpenTTD] nielsmh commented on issue #7901: Train prefers service in depot over station https://git.io/Jeh7q
12:07:46  *** Pikka has joined #openttd
12:46:27  *** Pikka has quit IRC
12:48:22  *** andythenorth has joined #openttd
12:59:45  *** zvxb has joined #openttd
13:24:04  *** andythenorth has quit IRC
13:25:52  *** Arveen has joined #openttd
13:27:22  *** snail_UES_ has joined #openttd
13:30:58  *** andythenorth has joined #openttd
13:35:48  *** andythenorth has quit IRC
14:03:59  *** snail_UES_ has quit IRC
14:20:24  *** sla_ro|master has quit IRC
14:34:07  *** Borg has joined #openttd
14:38:32  *** Samu has joined #openttd
14:39:08  <Samu> hi
14:46:41  *** Flygon has quit IRC
14:48:27  *** nielsm has joined #openttd
15:00:31  *** HerzogDeXtEr has joined #openttd
15:09:03  *** Wolf01 has joined #openttd
15:19:52  <jlx_> Has anyone experience with 4096x4096 maps? Is this playable on a modern CPU if you have many train stations?
15:20:11  <jlx_> With an empty map, it seems to work well (except autosaves, they take 10 seconds)
15:33:02  <nielsm> if you fill out a 2048 or 2096 map with the same density of towns and industries that you would a 256 sized map it won't be enjoyable
15:33:04  <planetmaker> jlx_, it works, sure. Yet, of course, the overall limit for vehicles etc. is smaller
15:33:15  <nielsm> 2048 or 4096 *
15:33:33  <planetmaker> as, of course, more computation goes into the map which then is not available for vehicles etc. It's not a hard limit ofc, just a "feels sluggish" one
15:34:01  <planetmaker> I try to actually encourage people to try the somewhat funky map aspect ratios like 256 * 2048 or 256 * 4096.
15:34:21  <planetmaker> The feel for long distances is there, but the load on the computer much smaller due to reduced map size
15:34:41  <nielsm> also vehicle speeds and the speed the calendar advances at means that many long routes won't be viable from a "profit per year per vehicle" perspective
15:34:43  <planetmaker> on my server I try to limit maps to 1M tiles generally
15:35:13  <planetmaker> so... 1000 x 1000, 500 x 2000, 250 x 4000 :)
15:36:05  <jlx_> ok, thanks
15:36:06  <planetmaker> But as with all these things: your milage may vary. :)
15:36:17  <planetmaker> Try out and see whether it (still) suits you
15:36:18  *** andythenorth has joined #openttd
15:36:27  <jlx_> I also noticed that in 1830, there are still no trains... in what year do I need to start?
15:36:40  <nielsm> default vehicle set is designed for 1950 start
15:36:44  <jlx_> there's a message box saying 1899, but that sounds a bit late
15:36:46  <planetmaker> hehe. Well, default game w/o NewGRFs is supposed to start in ... 1950
15:36:51  <planetmaker> will work from 1930
15:37:13  <nielsm> you can get newgrfs that cover the full range of railroading history
15:37:18  <planetmaker> But w/o NewGRFs with early vehicles a date before 1930 is not a good idea
15:37:45  <planetmaker> (and also think about RV, ships and planes when thinking NewGRF vehicles)
15:39:19  <jlx_> is there a good NewGRF set with old European or American trains? (old = ~1850)
15:41:15  <nielsm> yes, several :)
15:41:55  <nielsm> you pretty much have to be more specific than that: USA, canada, britain, germany, france, ...?
15:42:35  <nielsm> I think the gigantic 2cc Trains in NML also covers from around 1850 and it has from all over the world
15:42:49  <nielsm> (can be configured to enable/disable specific regions)
15:45:48  <planetmaker> indeed. There's a huge choice. UKRS, NARS, IronHorse, 2ccTrains, French, Czech come to my mind immediately. And there's more.
15:46:31  <Samu> i found a parameter not being used
15:46:56  <planetmaker> Add egrvs for vehicles. And SquidAteFish for ships. And avi8 for planes and you're set to go :)
15:47:48  <Samu> https://github.com/OpenTTD/OpenTTD/blob/master/src/ship_cmd.cpp#L507
15:48:03  <Samu> Trackdir trackdir isn't being used
15:50:30  <planetmaker> @Samu: I *think* it follows the other pathfinder-related functions or used it maybe once. Actually... it could be used for traffic separation areas :D
15:52:12  <planetmaker> But no doubt... there's potential for clean-up :)
16:01:36  <FLHerne> jlx_: Early Rail + UKRS2 is good for starting ~1800
16:02:23  <FLHerne> Also "Town and Industry - UK Houses Early Mod"
16:02:46  <jlx_> Thanks for the recommendations, I'll try some of them out
16:02:53  <FLHerne> (much prettier than the default houses, and also keeps the population lower)
16:03:07  <jlx_> Do more NewGRFs for trains or stations make the game significantly slower?
16:03:12  <FLHerne> Oh, there's a Sailing Ships grf too
16:03:17  <FLHerne> Generally not
16:03:20  <planetmaker> SwedishHouses is actually my favourite. But... not for that early
16:03:23  *** Wormnest has joined #openttd
16:04:16  <planetmaker> The speed impact of NewGRFs on the game speed is not big, usually. Occasional exceptions apply, but... mostly that's industries which can do all kind of weired stuff
16:04:24  *** supermop_work_ has quit IRC
16:04:36  <FLHerne> I've had games with several thousand vehicles before, I wouldn't worry too much
16:05:15  <FLHerne> General note - IME, it's much more fun to create a small map and actually fill it than poke around the edges of a 4096^2 one
16:05:25  <planetmaker> let's say: most games here are border-line playable, but still playable: https://wiki.openttdcoop.org/PublicServer:Archive_-_Hall_of_Fame
16:05:39  *** supermop_work has joined #openttd
16:05:59  <planetmaker> 5k trains on 512^2 :)
16:06:16  <Borg> FLHerne: getto style junctions? ;)
16:06:35  <FLHerne> On a 512^2 map, you know the geography and where all the towns and most of the industries are
16:07:08  <FLHerne> So there's much more sense of place than having a huge map and just building lines between arbitrary places
16:07:12  <FLHerne> Borg: Not my style
16:07:24  <Borg> ah ok...
16:07:32  <Borg> I like smaller maps too tho...
16:07:54  <Borg> its fun having dense rails build.. and trying to put station here and there..
16:08:18  <Borg> still having server up w/ game 2300+ year.. not feeling to finish it yet
16:12:03  <Samu> Cleanup: Remove unused parameter ?
16:12:14  <Samu> what commit message for this?
16:12:36  <planetmaker> yes, exactly like that @ smau
16:12:58  <planetmaker> ehm... ^^ @Samu. Sorry :)
16:13:52  <Samu> https://github.com/OpenTTD/OpenTTD/commit/6ca637b8c149efe2cb8ccffccbfd98530f633d58#diff-fa888affc2f63e5d03e59e88c34d30f3R524
16:13:55  <Samu> it used to be used
16:14:01  <Samu> so it was a bad cleanup
16:17:10  <DorpsGek_III> [OpenTTD/OpenTTD] SamuXarick opened pull request #7909: Cleanup: Remove unused parameter https://git.io/JejaK
16:23:42  <Samu> i have a patch by hackalittlebit https://www.tt-forums.net/viewtopic.php?f=33&t=42758&p=1202210&hilit=ship+collision+avoidance#p1202210
16:24:13  <Samu> ready for PR, but it's probably gonna mess up the ship cache
16:25:59  <FLHerne> andythenorth: Did you change the cargo classes for Clay in FIRS 3?
16:26:12  <Samu> oh crap, NULL to nullptr, have to fix this
16:26:28  <FLHerne> It can't be carried in the UKRS2 steel opens or hoppers, which I don't remember being an issue before
16:26:51  <FLHerne> (I have 3.0.12)
16:29:04  <supermop_work> maybe andy is making proprietary grfs
16:48:27  *** Progman has joined #openttd
16:49:01  <Samu> wow the savegame highlight is such a welcome feature
16:50:21  <nielsm> it's a "you never knew how much you missed this" thing :P
17:02:19  <Samu> i wanna test ship collision avoidance against the pathfinder cache
17:06:13  <Samu> wow im impressed
17:06:18  <Samu> doesn't affect much
17:06:21  <Samu> if anything
17:06:40  <nielsm> well yes, the entire route is planned out beforehand
17:06:51  <nielsm> if anything they'll sail around where a ship was two months ago
17:11:16  <Samu> wasn't multidocks supposed to have a max 3 docking tiles per dock?
17:11:19  <DorpsGek_III> [OpenTTD/OpenTTD] nielsmh updated pull request #7902: Wedge volume control sliders https://git.io/Jejfp
17:12:31  <nielsm> if you wanted good collision avoidance with path caching for ships, you'd need to store (probably in the map array) how many ships have planned to sail through a particular tile, and apply a slight penalty to passing through tiles something else wants to pass
17:12:53  <nielsm> possibly even store the "reservation count" per direction
17:13:25  <nielsm> such that ships going the same direction don't avoid using the same tiles, but going opposite directions avoid using the same tiles
17:14:15  <Samu> but breakdowns exist
17:15:08  <nielsm> yes that's not handleable with that model
17:17:49  <nielsm> I don't know how much it would affect performance, but what you then could do was check on entering a new tile whether two tiles (or so)  the cached path contains a ship that is broken down or slower than this one, and if there is a broken/slow ship then try to break up the cached path to a point slightly ahead of the "obstacle" and find a new path that avoids it
17:18:24  <nielsm> the issue here mainly being that checking for other vehicles ahead all the time might have a not insignificant cost
17:20:14  *** sla_ro|master has joined #openttd
17:28:48  <Samu> im unsure if I submit it
17:28:51  <Samu> pr
17:29:02  <Samu> it's not my work :(
17:30:42  *** WormnestAndroid has quit IRC
17:32:04  *** WormnestAndroid has joined #openttd
17:32:58  <Samu> there's another one, lifetime profit, also not my work
17:35:22  <Samu> it's also missing AI functions
17:38:42  <Samu> https://github.com/OpenTTD/OpenTTD/compare/master...SamuXarick:ship-collision-avoidance?expand=1
17:38:46  <Samu> PR or no PR?
17:38:52  <Samu> how do I decide
17:39:49  <Borg> by fair dice roll ;)
17:41:47  <Samu> i will wait for #7909 first
17:45:56  <Samu> lol @ AMD
17:46:25  <Samu> [img]https://i.imgur.com/0jf0aza.png
17:46:30  <Samu> look at CPU
17:47:15  <Samu> CPU
17:47:15  <Samu> AMD FX(tm)-8150 Eight-Core Processor
17:47:15  <Samu> 4 Cores
17:48:24  <Borg> OS?
17:48:30  <Samu> windows 10
17:48:44  *** uuuppz has joined #openttd
17:49:03  <Borg> hmm.. specs says it should have 8 cores indeed... maybe some windows update melted 4 others.. ;)
17:50:19  <Samu> that's AMD's Adrenaline Software stuff
17:50:36  <Samu> they themselves report that the 8 core cpu is a 4 core
17:50:50  <Borg> ah.. ok..
17:56:49  *** supermop_work_ has joined #openttd
17:56:49  *** supermop_work has quit IRC
18:08:53  <Samu> hmm lifetime profit :(
18:09:19  <Samu> it's using the a - b comparion and not a < b
18:09:25  <Samu> old patch :(
18:12:00  *** frosch123 has joined #openttd
18:20:07  *** andythenorth has quit IRC
18:22:17  <DorpsGek_III> [OpenTTD/OpenTTD] frosch123 commented on issue #7908: "Show the NewGRF name in the build vehicle window" is missing the "On/Off" display. https://git.io/JejGm
18:45:51  <DorpsGek_III> [OpenTTD/OpenTTD] DorpsGek pushed 1 commits to master https://git.io/Jejoj
18:45:51  <DorpsGek_III>   - Update: Translations from eints (by translators)
18:49:18  <Samu> copying some tricks from https://github.com/JGRennison/OpenTTD-patches/commit/6d99162df9c68562893a3755664ca092c77899d5
18:49:23  <Samu> for the lifetime profit
18:49:46  <Samu> but there's still missing NoAI functions
18:50:04  <Samu> I suppose they might come useful
18:51:43  <nielsm> it's not particularly difficult to add those
18:51:43  <nielsm> https://github.com/OpenTTD/OpenTTD/pull/7353/commits/e89783f8a1045df8f4f01c2400968f9a9cea6931
18:52:03  *** andythenorth has joined #openttd
18:52:20  <DorpsGek_III> [OpenTTD/OpenTTD] stormcone opened pull request #7910: Fix #7908, b524f1a: "Show the NewGRF name in the build vehicle window… https://git.io/JejKt
18:52:43  <andythenorth> FLHerne: FIRS 3?
18:52:46  <andythenorth> I'll look
18:53:04  <DorpsGek_III> [OpenTTD/OpenTTD] nielsmh approved pull request #7910: Fix #7908, b524f1a: "Show the NewGRF name in the build vehicle window… https://git.io/JejKq
18:53:52  <andythenorth> how does github blame work then? :) https://github.com/andythenorth/firs/blame/master/src/cargos/clay.py#L11
18:54:25  <andythenorth> FLHerne: https://github.com/andythenorth/firs/commit/a6d95327c7639a2467053757482c601225f92a3a ? o_O
18:54:49  <frosch123> i wanted to say "it's andy's fault anyway"... but there is actually one line from me
18:55:56  <Samu> hmm some gui improvements are needed yet
18:56:04  <Samu> well, be back later ,dinner ready
18:56:08  <andythenorth> frosch123: you can default to that anyway
18:56:19  <andythenorth> 9 times out of 10 it's true and doesn't offend
18:56:26  <andythenorth> 1 time out of 10 it feels like the lolz failed :(
18:58:17  <andythenorth> so what shall we do today?
18:58:25  <andythenorth> endlessly rework the UK Horse?
19:01:43  <DorpsGek_III> [OpenTTD/OpenTTD] ldpl commented on issue #7869: The human-readable name of a cargo type can't be queried by AI/GS. https://git.io/Jed7d
19:03:00  <frosch123> can you rename the roster so it no longer references "uk"? problem solved
19:08:11  <supermop_work_> what should i do today andythenorth ?
19:09:29  <andythenorth> gantt chartws
19:09:31  <andythenorth> charts *
19:09:55  <andythenorth> frosch123: "95 engines and 355 wagons inspired by British trains"
19:09:59  <andythenorth> "95 engines and 355 wagons inspired by trains" ?
19:11:15  <frosch123> "95 engines and 355 wagons for wet climate"
19:11:21  <andythenorth> https://www.youtube.com/watch?v=vyItidbjxLM
19:11:22  <supermop_work_> andythenorth: other than gantt chart
19:11:29  <andythenorth> ^ watch that video and report?
19:11:36  <andythenorth> the main character looks just like me
19:12:30  <supermop_work_> my actual work today is to figure out which chunks of weeks over the next two years i will need to put 40-60% of my or a coworkers hours on this think
19:13:06  <andythenorth> this sounds like project management
19:13:19  <supermop_work_> that is technically my job
19:13:48  <frosch123> over the next two years? sound like you can just fill it in randomly
19:13:50  <andythenorth> I like trains
19:14:17  <supermop_work_> frosch123: i need to choose the right level of noise to make it not look random?
19:14:25  <DorpsGek_III> [OpenTTD/OpenTTD] JGRennison opened pull request #7911: Codechange: Remove std::function from Pool iteration wrapper https://git.io/JejKp
19:14:27  <frosch123> don't forget amf1 and amf2
19:14:47  <supermop_work_> also at least some of the times i am working on it should ideally overlap with when the contractor needs answers
19:22:45  <DorpsGek_III> [OpenTTD/OpenTTD] LordAro merged pull request #7910: Fix #7908, b524f1a: "Show the NewGRF name in the build vehicle window… https://git.io/JejKt
19:22:46  <DorpsGek_III> [OpenTTD/OpenTTD] LordAro closed issue #7908: "Show the NewGRF name in the build vehicle window" is missing the "On/Off" display. https://git.io/JejGm
19:34:34  <frosch123> LordAro: fyi, eints will remove the invalid strings next evening
19:35:42  <LordAro> very good
19:35:46  * nielsm thinks about how to potentially do some GS industry control again
19:36:21  <nielsm> it's troublesome since there's two basic production level controls (classic and smooth) and then newgrf
19:37:11  <frosch123> remove smooth, then there are only two
19:37:17  <nielsm> maybe the safest way to start out is to have a flag GS can set "production level frozen" which prevents all attempts at changing production level
19:38:04  <frosch123> i think the cheat already checks some level of is-this-a-newgrf-industry
19:38:04  <_dp_> nielsm, just add an option to stop production changes, will solve a lot of problems
19:38:50  <frosch123> i wondered about an "economy speed" setting in the past, which scales the number of random changes
19:39:01  <nielsm> dp yeah the main thing I'm after initially is actually just a way to freeze industries until someone starts servicing them
19:39:01  <frosch123> except smooth economy is broken by design :)
19:39:32  <_dp_> frosch123, what's wrong with smooth economy?
19:39:37  <nielsm> so you can make a scenario where industries stay where the designer put them until a player begins interacting with them
19:39:44  <_dp_> except that's one setting that does billion of things
19:41:20  <frosch123> 1) for production changes it does not pick one industry, but always picks all. so no randomness. 2) it changes production every month by small amounts, which average out to some gaussian distribution, so basically no randomness
19:42:04  <frosch123> both makes production changes essentially pointless, better to leave them out then
19:42:49  <_dp_> not pointless, just less randomness
19:42:52  <_dp_> which is good imo
19:42:55  <frosch123> oh, and 3) it spams the news
19:43:12  <nielsm> ugh these header names... industry.h, industry_type.h, industrytype.h
19:43:18  <nielsm> struct Industry is in industry.h
19:43:33  <frosch123> original economy requires player action when something changes. smooth is just whatever
19:44:19  <frosch123> nielsm: it's somewhat consistent though :) there is no industry_base though
19:44:54  <_dp_> yeah, so original doesn't suit some playstyles and smooth just rewards goods setups in a long run
19:45:45  <_dp_> miroing industries is the last thing I want when I play
19:47:42  <andythenorth> oof
19:47:58  <andythenorth> the frosch123 econonomy newsletter :)
19:48:14  <andythenorth> I considered before having FIRS optionally listen to OpenTTD production change
19:48:19  <andythenorth> in addition to supplies
19:48:57  <andythenorth> but the suckiness of the economy makes it unappealing to work on :)
19:51:04  <frosch123> games need some unpredictable element, economy changes, breakdowns,... othewise they become clicker games
19:51:57  <frosch123> there is nothing more stupid than a factorio speedrun :)
19:52:44  <frosch123> someone made the comparision with color-by-numbers
19:53:06  <andythenorth> I think current FIRS is like building Lego
19:53:18  <andythenorth> and Steeltown economy is like building Lego Technic
19:53:44  <andythenorth> I'm quite happy with that gameplay, but there's no variation
19:53:50  <frosch123> oh, i watched someone rant about the current lego technic season :)
19:53:54  <andythenorth> that happens
19:54:33  <andythenorth> FIRS (ignoring Extreme) tends to connect primaries, get supplies, boost primaries, connect secondaries, connect tertiaries, fund more primaries, repeat
19:55:09  <andythenorth> it's fine, but there's nothing for e.g. storybook gameplay on a small map (as a random example)
19:55:15  <frosch123> yep, playing firs on a flat map must be very boring
19:55:32  <andythenorth> Steeltown works because it's fricking hard fitting enough stations in :P
19:55:45  <andythenorth> but that will be solved by industry sub-layouts so eh :)
19:55:53  <andythenorth> mumble mumble economy
19:56:02  <frosch123> is that a reason against sublayouts? :p
19:56:40  <andythenorth> not a good one
19:57:01  <_dp_> for goal games randomness is not good if there is too much of it
19:57:29  <_dp_> also idk what's wrong with factorio speedruns but sure it can't be worse than openttd ones (on default settings) :p
19:57:57  <nielsm> well I managed to explain that OTTD speedruns that allow fast forward are meaningless
19:58:05  <nielsm> since that depends on machine speed :P
19:58:32  <Samu> JGR does some string magic which prevents translators from translating
19:59:39  <_dp_> even without fast-forward it's quite questionable
19:59:53  <Samu> avoids translators translating
19:59:56  <frosch123> _dp_: it involved playing the same map over and over again, while memorising/optimising the same factory over and over again
20:00:16  <_dp_> goal games are very alike speedruns but that takes a heavily patched server to make them reasonable and even that's far from ideal
20:00:31  <frosch123> training to perform the same N-hour-click-sequence :)
20:00:47  <_dp_> frosch123, that's pretty much how any speedruns are
20:01:44  <_dp_> discovering new strategies and training hard to run them frame-perfect
20:02:07  <andythenorth> ballet
20:02:12  <frosch123> nielsm: you can measure speedruns in realtime or in in-game time :) you either need to ban ff or pause :)
20:02:59  <nielsm> for ottd it makes sense to measure game time in ticks
20:03:09  *** iSoSyS has joined #openttd
20:03:27  <nielsm> actually we should change the _tick_counter to uint64
20:03:32  <nielsm> instead of uint16
20:03:48  <nielsm> so you can get a real count of ticks elapsed since start of game
20:05:04  <frosch123> @calc 3600/0.3*24
20:05:04  <DorpsGek> frosch123: 288000
20:05:38  <frosch123> i missed a 0, but ok, 32bit ticks are already hard to reach
20:05:48  <_dp_> on citymania I measure times in game date, just converting them to look realtime-ish for display
20:06:36  <nielsm> problem with game date is that you can cheat it and it can reach max year
20:07:30  <_dp_> well we run servers so not a problem :p
20:08:46  <Samu> https://i.imgur.com/jg3uiph.png lifetime profit for groups, shall I do it too?
20:09:01  <Samu> i guess so
20:10:05  <Samu> the new screenshot feature is kinda dumb, it screenshots itself :(
20:10:23  <_dp_> and doing anything to prevent cheating speedruns in singleplayer seems pretty pointless
20:10:47  <_dp_> it's a piece of cake to sneakily tweak an opensource game
20:11:01  <_dp_> and ppl cheat speedruns even in closed source ones
20:12:26  <floodious> i don't really see it as cheating, how would that be possible?
20:12:44  *** HerzogDeXtEr has quit IRC
20:12:50  <floodious> i mean sure, if the opponent can do things like give themselves money or create things that aren't actually possible with a normal game
20:13:18  <nielsm> eh well, speedrunning is completing a specific goal under specific game conditions within as low a time as possible
20:13:33  <nielsm> if you're playing a different version of the game from everyone else and claim you are not then it's cheating
20:13:38  <floodious> but if they're only using mega-supercomputers like converting their bitcoin rig to compute AI and build rail lines, that seems fine, they're being unsportsmanlike but not technically breaking rules
20:14:44  <_dp_> floodious, that's called tool-assisted speedrun (TAS)
20:14:50  <floodious> i know :)
20:15:02  <floodious> it's not breaking rules of the game, it only improves the UI for that particular player
20:15:22  <nielsm> a difficult to detect ottd mod that could make speedrunning easier would be something like slightly increasing passenger production in towns
20:15:25  <floodious> so the complaint is pure: it's unsportsmanlike to have an advantage of a better UI that isn't a dinky mouse+keyboard from the 1970s
20:15:50  <floodious> that would be breaking game rules, and could be detected by other systems running the same computations saying "wait, that's not right"
20:16:06  <nielsm> yes but this is done in singleplayer mode
20:16:15  <floodious> ah
20:16:23  <nielsm> and there is no such thing as replay recording in ottd
20:16:44  <floodious> then you just have to trust your single-player match opponent to be sportsmanlike, as in any board game or whatever where they can just pull extra cards from the deck and lie
20:16:50  <floodious> like D&D
20:17:34  <floodious> a very slimy thing to lie about, since cheating in a game is so backward to the purpose of the game
20:19:09  <_dp_> ui improvements are somewhat an issue even in mp
20:19:24  <_dp_> we just solve it by having an official patched client with everything xD
20:19:38  <Samu> oops, i broke the gui
20:19:44  <Samu> current usage is now gone :p
20:19:51  <floodious> like use crypto signatures on the save game? :)\
20:20:00  *** sla_ro|master has quit IRC
20:20:27  <floodious> "the official MP version has this signature key, all games must be signed to be valid"
20:21:40  <andythenorth> shall we talk about horsepower-per-ton? o_O
20:21:43  <floodious> always possible to work around, people do the weirdest things to cheat... in tao, if cheating lets you win, only a fool does not cheat
20:21:45  *** sla_ro|master has joined #openttd
20:22:01  * andythenorth has been doing maths
20:22:12  <andythenorth> tech tree progression is interesting
20:22:43  <andythenorth> I think by late game it's reasonable to expect trains to accelerate to top speed in a reasonable tile distance
20:22:50  <andythenorth> and also that top speeds are relatively high
20:23:07  <andythenorth> it's also reasonable that wagon capacity increases
20:23:33  <andythenorth> vehicle weight is potato / potato, could go down (aluminium) or up (more air-conditioning)
20:23:35  <Wolf01> Hmmm, tech tree
20:24:38  <andythenorth> Horse trains that weigh 138t / tile, need 3720hp to do 87mph, and 4144hp to do 96mph
20:24:54  <andythenorth> so 400 hp bump to reach top speed in ~same tile distance
20:25:05  <andythenorth> but we also expect MOAR from progression
20:25:09  <DorpsGek_III> [OpenTTD/OpenTTD] floodious commented on issue #7905: TownDirectoryWindow::OnPaint() triggers large (>50ms) redraw times https://git.io/JejYt
20:25:12  <andythenorth> so STRONK engines
20:25:30  <andythenorth> but if the power bump is too much, it leaves the engine OP for existing routes
20:25:38  <Samu> https://i.imgur.com/CTmpiCf.png - how does it look?
20:25:49  <andythenorth> this cause late game tech tree to need a lot of engines, where early game just needs a few
20:25:57  * andythenorth end of message
20:26:16  <andythenorth> TL;DR I should have done 5 generations in Horse, not 6 :P
20:26:50  *** sla_ro|master has quit IRC
20:27:02  <andythenorth> also maybe the game should turn HP / ton into a useful value, or a chart of trailing load vs. acceleration or speed
20:27:26  <andythenorth> or I should do it in Horse docs, train stat tool!
20:27:27  <andythenorth> oof
20:27:47  <DorpsGek_III> [OpenTTD/OpenTTD] floodious commented on issue #7905: TownDirectoryWindow::OnPaint() triggers large (>50ms) redraw times https://git.io/JejYt
20:28:31  <Samu> hmm it looks rather bad :(
20:28:58  <Samu> the height of the line just before Profit this year
20:29:01  <Samu> is big
20:29:04  <Samu> how to fix
20:33:37  <Samu> oh boy, too much magic happening on resizes
20:33:42  <Samu> for this window
20:36:55  <Samu> I'm not sure how to fix this
20:37:04  <Samu> any tips
20:43:29  <Samu> ah, i think i figured it out
20:44:27  <Samu> nop, i didnt after all :(
20:50:18  <DorpsGek_III> [OpenTTD/OpenTTD] michicc commented on pull request #7911: Codechange: Remove std::function from Pool iteration wrapper https://git.io/JejXO
20:51:14  <floodious> samu; when you and glx were looking at the town directory issues, did you confirm the list rebuilds from the per-100-ticks trigger? it doesn't seem to here with the old code, i'll need to check the latest to confirm
20:52:27  <Samu> didn't confirm after the fix
20:52:36  <floodious> might be an additional bug buried under a bug, where since OnPaint() triggered the list rebuild when marked invalid, On100thTick didn't need to and it was mistakenly left out (only re-sorts)
20:53:26  <floodious> easy to test, just comment out the OnPaint() line, go into scenario editor, create random towns on a small map and open the directory, then delete one town
20:53:45  <floodious> the town name and pop goes blank but it works, but that never gets removed in my older code
20:54:16  <floodious> only gets rebuilt from OnPaint(), so that would mean the On100thTick() is re-sorting an invalid list with a void entry
20:54:44  <floodious> anyway i'm out for now, not a biggie since OnPaint() does it anyway (...)
20:55:27  * floodious goes out
21:01:40  <DorpsGek_III> [OpenTTD/OpenTTD] JGRennison commented on pull request #7911: Codechange: Remove std::function from Pool iteration wrapper https://git.io/JejXX
21:02:35  <Samu> I'm staring at this code https://github.com/OpenTTD/OpenTTD/blob/master/src/group_gui.cpp#L391-L448
21:03:06  <Samu> wondering where do I have to change to get this resize correctly
21:03:52  *** frosch123 has quit IRC
21:04:01  <Samu> so far I changed line 408 and 444, made it FONT_HEIGHT_NORMAL * 4
21:06:47  <Samu> https://i.imgur.com/CTmpiCf.png - line before profit this year looks fat! and there's some weird line below train 7 (if it existed)
21:06:58  <Samu> what do I do?
21:20:04  <nielsm> https://github.com/OpenTTD/OpenTTD/commit/3e2312065ec521030f94c64faf079859d62e5729
21:23:10  <DorpsGek_III> [OpenTTD/OpenTTD] nielsmh opened pull request #7912: Feature: Disallow industry production changes from GS https://git.io/Jej1Z
21:23:53  <_dp_> nielsm, isn't INDCTL_NO_PRODUCTION_CHANGE same as INDCTL_NO_PRODUCTION_DECREASE & INDCTL_NO_PRODUCTION_INCREASE ?
21:24:08  <nielsm> dp not quite
21:24:31  <nielsm> the first does not evaluate production change chances at all and skips the newgrf production change callback
21:24:51  <nielsm> the latter two do perform the dice rolls and call the production change callback, but ignores the result if it's down/up
21:25:26  <_dp_> nielsm, well, you could always check decrease & increase for early return
21:25:44  <_dp_> unless there is some usecase for callback to be called but ignored
21:26:20  <nielsm> the production change cb allows industies to post news messages too, without changing production
21:27:07  <nielsm> but, newgrf industries might even have their own internal production level variable that could ignore these flags entirely
21:27:39  <nielsm> even allowing them to change production levels based on the regular production callback
21:27:53  <nielsm> (just without showing news messages)
21:31:43  *** glx has joined #openttd
21:31:43  *** ChanServ sets mode: +v glx
21:33:03  <_dp_> hm, I guess it's nice for consistency
21:33:07  <_dp_> quite confising tho
21:34:55  *** Progman has quit IRC
21:42:16  <andythenorth> so can we graph engine stats?
21:42:20  <andythenorth> hp / speed
21:42:29  <andythenorth> hp / engine weight
21:42:42  *** Thedarkb-X40 has quit IRC
21:43:10  <andythenorth> plot speed for sample trailing loads on configurable grades
21:43:30  * andythenorth has added hp/speed to Horse docs, and it throws up a few things in tech tree
21:50:36  *** Borg has quit IRC
21:53:31  *** nielsm has quit IRC
22:05:29  *** Wolf01 has quit IRC
22:09:49  *** WormnestAndroid has quit IRC
22:10:12  *** WormnestAndroid has joined #openttd
22:14:22  <DorpsGek_III> [OpenTTD/OpenTTD] James103 commented on pull request #7912: Feature: Disallow industry production changes from GS https://git.io/JejMx
22:16:34  <Samu> this is more work than I anticipated
22:16:38  <Samu> damn gui's
22:24:53  *** andythenorth has left #openttd
22:38:52  <Samu> when i was running generate_widget/squirrel_export, SQGSWindow.DefSQConst(engine, ScriptWindow::WID_SC_TAKE_MINIMAP,                       "WID_SC_TAKE_MINIMAP"); was created which is not related to my work
22:38:58  <Samu> somebody forgot it
22:43:32  *** Wormnest has quit IRC
22:47:46  <LordAro> oh no
22:48:03  <LordAro> i always forget the order those need to be run in
22:48:08  <LordAro> Samu: feel free to PR it
22:50:28  <Samu> squirrel_export.vbs should have a "Done!" popup at the end of all tests
22:50:34  <Samu> for window mode
22:51:12  <glx> LordAro: generate then export ;)
22:51:43  <LordAro> Samu: it needs to be added to commit checker in some way
22:51:51  <LordAro> (or we need to hurry up with cmake)
22:52:19  <glx> I have a cmake fork adding it :)
22:54:12  <Samu> something so simple as adding a lifetime profit is already touching 21 files
22:55:14  <Samu> and I may be missing some places
22:58:16  *** Pikka has joined #openttd
23:01:16  <Samu> regression main.nut doesn't have tests for group profit last year
23:01:30  <Samu> i guess it doesn't need a lifetime either?
23:02:44  <LordAro> Samu: regression tests miss a lot of things
23:02:56  <LordAro> you could add them ;)
23:03:02  <Samu> oh boo :(
23:06:04  <Samu> somebody explain GetGroupProfitLastYear? seems to be a cache
23:06:13  <Samu> do i need one for lifetimeprofit?
23:11:42  <peter1138> So, uh... https://archive.org/details/simusex
23:19:44  <LordAro> "I went on the internet last week, and I found this!"
23:19:49  <LordAro> PR_CONNECT_RESET_ERROR tho
23:20:31  <DorpsGek_III> [OpenTTD/OpenTTD] LordAro approved pull request #7909: Cleanup: Remove unused parameter https://git.io/JejyS
23:20:42  <DorpsGek_III> [OpenTTD/OpenTTD] LordAro merged pull request #7909: Cleanup: Remove unused parameter https://git.io/JejaK
23:29:06  <DorpsGek_III> [OpenTTD/OpenTTD] LordAro commented on pull request #7902: Wedge volume control sliders https://git.io/JejSf
23:31:27  *** WormnestAndroid has quit IRC
23:31:31  *** Flygon has joined #openttd
23:32:15  *** WormnestAndroid has joined #openttd
23:35:09  <Samu> dont forget the widget, i got to go sleep, no time today
23:35:15  <Samu> cyas
23:35:25  <DorpsGek_III> [OpenTTD/OpenTTD] glx22 requested changes for pull request #7911: Codechange: Remove std::function from Pool iteration wrapper https://git.io/JejSc
23:35:37  *** Samu has quit IRC

Powered by YARRSTE version: svn-trunk