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