IRC logs for #openttd on OFTC at 2020-01-06
⏴ go to previous day
00:07:30 <DorpsGek_III> [OpenTTD/OpenTTD] LordAro opened pull request #7907: Fix e558aa8: Compiler warning about unused value https://git.io/JejOs
00:07:36 <andythenorth> Pikka: I read the post also :)
00:14:27 *** Wormnest has joined #openttd
00:14:47 <supermop_Home> andythenorth that's on bananas?
00:15:31 <andythenorth> supermop_Home: should be
00:15:40 <andythenorth> the roster name is a clue, that changed a long time ago
00:15:51 <andythenorth> somehow your OpenTTD is showing old values
00:16:00 <andythenorth> I don't know if that's my error or OpenTTD
00:19:32 <supermop_Home> check online content claims i have latest version
00:21:05 <andythenorth> screenshot suggests you do too
00:21:59 <DorpsGek_III> [OpenTTD/OpenTTD] floodious commented on issue #7905: TownDirectoryWindow::OnPaint() triggers large (>50ms) redraw times https://git.io/JejYt
00:23:41 <DorpsGek_III> [OpenTTD/OpenTTD] glx22 approved pull request #7907: Fix e558aa8: Compiler warning about unused value https://git.io/JejOR
00:29:44 <andythenorth> I've definitely seen action 14 caching cause similar issues
00:29:52 <andythenorth> but it shouldn't persist beyond a restart
00:31:23 <DorpsGek_III> [OpenTTD/OpenTTD] LordAro merged pull request #7907: Fix e558aa8: Compiler warning about unused value https://git.io/JejOs
00:36:15 <andythenorth> sorry can't think what else to suggest :|
00:36:40 <supermop_Home> restarting ottd didn't do anything so i guess ill restart the computer
00:37:33 <andythenorth> my 2.3.0 is from bananas
00:45:00 <DorpsGek_III> [OpenTTD/OpenTTD] floodious commented on issue #7905: TownDirectoryWindow::OnPaint() triggers large (>50ms) redraw times https://git.io/JejYt
00:45:37 <supermop_Home> removing from active grfs and then re-adding fixed???
00:46:11 <supermop_Home> roster name still 'my kingdom for a horse' tho
00:47:40 <andythenorth> it's probably because the parameter name and values haven't changed
00:47:46 <andythenorth> just the string for value 0
00:48:07 <andythenorth> but 4 years is a long time for OpenTTD to cache that :x
00:48:39 <supermop_Home> have plow and 08, no dvt
00:49:02 <supermop_Home> though it is 1985, maybe too early?
00:49:38 <supermop_Home> this computer is less than 4 years old
00:49:46 <supermop_Home> its about 18 month
00:52:01 <andythenorth> reading about HP / ton though
00:52:02 <andythenorth> "MPH / 18.75* = HP (per ton); the HP requirement will increase roughly proportionally to the grade and speed."
00:52:12 <andythenorth> OpenTTD is pretty accurate for that
00:52:31 <andythenorth> @calc (5200/785) * 18.75
00:52:31 <DorpsGek> andythenorth: 124.203821656
00:52:57 <floodious> is it possible already with newgrf to dynamically compute running costs?
00:53:09 <floodious> like by summing fuel usage
00:53:12 <andythenorth> my 5200hp 785t train does 124mph on flat
00:53:21 <andythenorth> floodious: more or less yes
00:53:33 <floodious> must be hard to get it working, since most sets don't
00:53:49 <Pikka> floodious, it's really not worth doing anything too complex
00:54:01 <floodious> i've found most starting costs are way too high, i assume i can't figure out the intended application for the sets
00:54:01 <andythenorth> Pikka: I should have stopped in 1995 :D After that is a right pain in the arse
00:54:33 <Pikka> 1995 is "current day" for TTD ;)
00:55:04 <andythenorth> the tech tree gets very broad :"
00:55:24 <glx> floodious: some mix of newgrfs can mess the costs too
00:55:24 <floodious> well base running cost = maintenance by age, then add (maintenance_rate*wear + fuel_rate*power) in a relatively simple approximation
00:55:26 <andythenorth> progression suggests faster trains, and more 'bigger' engines
00:55:38 <andythenorth> but existing trains don't need huge stats jumps
00:55:43 <andythenorth> to more models are implied :P
00:55:45 <Pikka> floodious, that's more or less what NARS2 did before 2.5
00:56:09 <Pikka> but it's such an inconsequential effect, and hard to communicate to the players
00:56:24 <Pikka> these days my trains just get 1/4 running costs when stationary
00:56:39 <floodious> is it? fuel costs were the main factor behind train route selection in the past, so grades more than 2 or 3 were the limit
00:57:05 <floodious> since efficiency is dropping at some exponential rate, there is an ideal HP output
00:57:21 <supermop_Home> wife's sewing machine has lost all feet but the zipper foot
00:57:24 <floodious> wear + energy cost = something like ^3 or even ^4
00:57:31 <supermop_Home> my sewing machine is 500 miles away
00:57:53 <supermop_Home> buy generic presser feet, or ship my better machine?
00:58:01 <supermop_Home> or buy an even better one
00:58:55 <floodious> i guess to estimate grade you'd need to min/max window over a distance traveled, then compute the height difference over that distance to estimate the grade (assume flat grade)
00:59:13 <floodious> fitting like that is tricky
00:59:23 <andythenorth> it just doesn't show up as useful in the game
00:59:49 <floodious> it would make climbing a mountain cost 1000x as much as going around
01:00:10 <floodious> and the train would wear out in the attempt
01: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.
01:00:52 <floodious> that's due to the poor landscapes
01:00:58 <floodious> i'm using real world heightmaps :)
01:01:06 <floodious> jumping over the peaks = cheaper
01: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
01:01:32 <andythenorth> shall I delete Horse gen 6 (202 stuff) ?
01:01:42 <floodious> the route is 10x longer finding a path along the 200 meter rise vs. 1800 meter peaks
01:01:53 <floodious> but the 10x longer makes it more expensive and slower!
01:02:00 <Pikka> if they're already done may as well leave them andy?
01:02:12 <andythenorth> I have 'balancing' issues :P
01:02:25 <andythenorth> due to power creep and bollocks :)
01:02:37 <andythenorth> or add one more train? :P
01:02:51 *** andythenorth has left #openttd
01:03:19 <floodious> they used switchbacks in the past to climb slopes maintaining < 3 grade or similar
01: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
01:04:30 <DorpsGek_III> [OpenTTD/OpenTTD] JGRennison commented on issue #7905: TownDirectoryWindow::OnPaint() triggers large (>50ms) redraw times https://git.io/JejYt
01:11:17 <DorpsGek_III> [OpenTTD/OpenTTD] floodious commented on issue #7905: TownDirectoryWindow::OnPaint() triggers large (>50ms) redraw times https://git.io/JejYt
01:14:45 <DorpsGek_III> [OpenTTD/OpenTTD] floodious commented on issue #7905: TownDirectoryWindow::OnPaint() triggers large (>50ms) redraw times https://git.io/JejYt
01:25:07 <DorpsGek_III> [OpenTTD/OpenTTD] floodious commented on issue #7905: TownDirectoryWindow::OnPaint() triggers large (>50ms) redraw times https://git.io/JejYt
01:33:31 <DorpsGek_III> [OpenTTD/OpenTTD] floodious commented on issue #7905: TownDirectoryWindow::OnPaint() triggers large (>50ms) redraw times https://git.io/JejYt
01:35:20 <DorpsGek_III> [OpenTTD/OpenTTD] JGRennison commented on issue #7905: TownDirectoryWindow::OnPaint() triggers large (>50ms) redraw times https://git.io/JejYt
01:37:07 <DorpsGek_III> [OpenTTD/OpenTTD] floodious commented on issue #7905: TownDirectoryWindow::OnPaint() triggers large (>50ms) redraw times https://git.io/JejYt
02:34:40 <DorpsGek_III> [OpenTTD/OpenTTD] floodious commented on issue #7905: TownDirectoryWindow::OnPaint() triggers large (>50ms) redraw times https://git.io/JejYt
02: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
02:57:54 *** snail_UES_ has joined #openttd
03:40:26 <FLHerne> floodious: Your comments seem a bit arrogant, really
03:41:40 <DorpsGek_III> [OpenTTD/OpenTTD] JGRennison commented on issue #7905: TownDirectoryWindow::OnPaint() triggers large (>50ms) redraw times https://git.io/JejYt
03:41:59 <FLHerne> The point of NeedsRebuild() is explicitly to invalidate the references; the design isn't "flawed" or a "pre-existing bug"
03:43:38 <FLHerne> Once that flag is set, the contents of the list are, semantically, no longer valid references
03:43:54 <FLHerne> They might as well be uninitialized
03:44:48 <FLHerne> (well, it's apparently flawed from a performance standpoint here, but it's functionally and semantically correct)
03: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
03:50:37 <FLHerne> Also, you keep explaining - at great length - things that everyone already knows
03:51:49 <DorpsGek_III> [OpenTTD/OpenTTD] floodious commented on issue #7905: TownDirectoryWindow::OnPaint() triggers large (>50ms) redraw times https://git.io/JejYt
03: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
03: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
03:55:09 <FLHerne> (incidentally, the "separate re-sort" flag idea sounds like a good solution to me)
04:04:05 <floodious> then the bug is setting that flag in the first place where it isn't actually needed
04:04:22 <floodious> why does it continue to work with a supposedly invalid list?
04: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
04:05:15 <floodious> it's like swatting a fly with a nuke from orbit
04:06:42 <floodious> this "brushing it off as not important" is what the source of these issues is rooted in to begin with
04:06:58 <floodious> letting that buzz around is like allowing wasps to build a nest in your source-tree
04:07:02 <floodious> suddenly you'd getting stung
04:07:50 <floodious> i know i'm saying things that are obvious, which is why they need be said
04:08:13 <floodious> i'm speaking from an architectural POV, where you build solid foundations
04:08:24 <floodious> excuses like "we can't multi-thread anyway because ..." are awful
04:08:39 <floodious> ... because you refuse to even take the first steps to ensure it becomes possible one day?
04:09:00 <floodious> "tossing your garbage here in the park is fine, nobody uses the bins anyway"
04:09:10 <floodious> well how did the park get so filthy to start?
04:23:46 *** ChanServ sets mode: +v tokai
04:35:52 <FLHerne> floodious: It doesn't continue to work with the list, it makes a new list when needed
04:36:54 <FLHerne> I assume you did try deleting some towns while testing that?
04: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
04:39:05 <FLHerne> Until a new town gets allocated or the pool is shrunk (not sure if that actually happens)
04:39:19 <FLHerne> But obviously you can't depend on that
04: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
04:45:09 <FLHerne> It "got so filthy to start" because SMP consumer processors /literally didn't exist/ when TTD was first written
04:46:03 <FLHerne> (or for some years afterward)
04:47:06 <floodious> nope, deleting a town is a valid thing
04:47:14 <floodious> i didn't bother testing it yet, but i assume it must assert or something
04:47:22 <floodious> if it doesn't that's an additional bug
04:47:39 <floodious> my point was the majority of triggers for the NeedsRebuild() are NOT that
04: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
04:48:01 <floodious> independent things yes, those are small steps
04:48:34 <floodious> aiming to make everything work without globals, with proper responsibility for allocation and deallocation, etc are all important
04: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"
04:48:57 <floodious> no, commenting the bug I reported, the OnPaint() function works
04:49:10 <floodious> why test a known valid case? the issue is all the invalid cases
04: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
04: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
04:50:01 <floodious> so that also needs a fix
04:50:13 <FLHerne> Your phrasing is very confusing
04:50:16 <floodious> making the NeedsRebuild() invalid, and can be deleted entirely
04:50:27 <floodious> it's never used in a valid way
04:50:36 <FLHerne> It's not /invalid/ to mark the list as dirty
04:50:46 <floodious> it's never used, so why have it? look at the result
04:51:11 <FLHerne> It's a defined behaviour that leads to the desired results
04:51:19 <floodious> that's fine, then it needs to be enforced
04:51:31 <FLHerne> Could it be done in a more-performant way? Sure
04: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
04: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
04:52:36 <FLHerne> Is it /worth doing/ in a more-performant way? Apparently (although it's worked like that for years without much complaint)
04:52:56 <floodious> it's true/false correctness
04:53:01 <floodious> it's currently false
04:53:14 <FLHerne> Ok, that's where you lose me
04:53:28 <FLHerne> In what way is the current code actually /wrong/
04:53:44 <FLHerne> Yes, it's using a sledgehammer to crack a nut
04:53:46 <floodious> it invalidates the list when only a single item is not valid
04:53:51 <FLHerne> Sledgehammers crack nuts
04:54:02 <FLHerne> No, the list is invalid, because a value in it is invalid
04:54:06 <floodious> sledgehammers smash nuts, shell and content
04:54:24 <floodious> the list isn't invalid in a majority of cases the flag is applied
04:54:31 <floodious> so it's applied invalidly
04:54:37 <FLHerne> It would also be correct to invalidate the list every time for no particular reason
04:54:46 <floodious> go ahead if you like
04:55:46 <floodious> it's bug-prone and wildly inaccurate
04: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
04:56:12 <FLHerne> I'm not saying the current behaviour is optimal, but claiming that it's "bug-prone" or "inaccurate" is just misleading
04:56:34 <floodious> show me the number of cases it's used validly, vs. invalid
04:56:38 <FLHerne> It's erring on the side of /correctness/ at the cost of performance
04:56:50 <floodious> no, a majority of applications are pure invalid
04:56:57 <floodious> it's plain bad programming
04: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
04:58:01 <floodious> it's not dirty at all
04:58:58 <floodious> it's fraud to operate a laundry and charge people for ten washes when one wash was enough
04:59:24 <floodious> or to be a cabbie and drive in circles or take the long way when business is slow
04:59:34 <FLHerne> The whole point of this is that the list sorting is now invalid, yes?
04:59:36 <floodious> that's plain fraud, bad programming, bad faith
04:59:46 <FLHerne> And that it's getting triggered more often that you'd expect
04:59:46 <floodious> no, the list is valid
04:59:52 <floodious> the sort gets updated once every 100 ticks
05:00:00 <floodious> OnPaint() should never trigger anything list-related
05:00:10 <floodious> it simply draws an existing list, or not
05:00:24 <FLHerne> ...except that isn't what it does
05:01:00 <FLHerne> The code not conforming to your idealized mental picture of how it should work isn't a bug
05:01:25 <floodious> a bug is performance against the intent by the author, but it depends how you define it
05:01:30 <floodious> i prefer the term "user-issue"
05:01:51 <floodious> but generally "issue" is considered to carry other meanings related to production process
05:02:09 <FLHerne> I don't see that "the sort gets updated once every 100 ticks" is a sane hill to die on anyway
05:02:32 <floodious> that's the intent of the code, unless you prove otherwise
05:02:44 <floodious> or show the design that is ideal
05:02:56 <floodious> the existing on100ticks() function was also bugged
05:03:08 <floodious> which is the intended trigger for re-sort and re-display of the window
05:03:33 <FLHerne> Hm, I'll agree that part is probably an actual bug
05: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)
05: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)
05: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
05:05:32 <floodious> so i wouldn't even care, it's just a symptom of a greater design flaw
05:05:42 <FLHerne> It's definitely not valid on deleting a town
05:06:32 <floodious> the list overall is, but i'd totally accept the overhead of "smashing a nut with a sledge" as you say
05:06:42 <floodious> just that 99.999% of the time, that's not the trigger source
05:06:55 <FLHerne> "abuse of the flags" is still nonsense
05:06:59 <floodious> it's pretty irrelevant, other than as an example case of the reason the flag existed to start
05:07:22 <floodious> it's the sole case where the list is genuinely invalid before the flag is set
05: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
05:08:34 <floodious> flag is generally a bit, boolean state
05:08:41 <floodious> you mean the integer?
05:08:46 <FLHerne> So, the "100 ticks" code is broken, because it assumes behaviour that doesn't exist
05:09:00 <floodious> what behavior doesn't exist?
05:09:20 <FLHerne> No, I mean NeedRebuild()
05:09:37 <floodious> it doesn't call that
05:10:23 <FLHerne> The list can need rebuilding either because the items have potentially changed order, or because they've changed existence, or both
05:10:30 <floodious> UpdateWindows() in window.cpp calls w->OnHundredthTick();
05:11:00 <floodious> why would you rebuild a list when it needs resorting?
05:11:28 <floodious> building = immediate, sorting = latent on a timer
05: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
05:12:35 <glx> basically the list is marked as rebuild by OnInvalidateWindowData(), then OnHundrethTick() handles it, unless an OnPaint() comes first
05:13:07 <floodious> It doesn't assume that
05:13:14 <floodious> fl; where are you getting this from?
05:13:44 <floodious> it merely triggers a rebuild every 100 ticks
05:13:51 <floodious> it assumes nothing, it's isolated from other components
05:14:06 <glx> that may rebuild if needed
05: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
05:14:40 <glx> that's why OnPaint() checks the need before calling to prevent useless resort
05:15:42 <floodious> void OnHundredthTick() override { this->BuildSortTownList(); this->SetDirty(); }
05:15:49 <floodious> seems to call it directly, does nothing with flags
05:16:08 <glx> BuildSortTownList() checks NeedRebuild()
05:16:25 <glx> and does sorting inconditionnaly
05:16:41 <FLHerne> floodious: But it doesn't actually accomplish its effect of doing it every 100 ticks
05: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
05:17:04 <FLHerne> floodious: Because of that
05:17:24 <floodious> why can't you accept that
05:17:30 <glx> no, rebuild flag is only set when a town has been removed
05:17:45 <floodious> there is no way to moderate the CPU consumption of the window unless it has limits on activity
05:17:58 <floodious> if you force such heavy lifting every frame update, every tick, there is no limit
05:18:18 <floodious> after you fixed it? my source is different
05:18:20 <floodious> there is only one flag
05:18:33 <floodious> it gets triggered sporadically due to updates to towns
05:18:37 <glx> yes there's only a rebuild flag
05:18:55 <glx> and other trigger are for sorting
05:19:00 <floodious> on a 2k map with 1 mil population, 1k towns, it triggers about every 4 or 8 ticks
05:19:25 <floodious> no, OnPaint() calls rebuild
05:19:43 <floodious> well, you just added the new sort flag, didn't you?
05:19:52 <floodious> i don't have the new code
05:20:45 <floodious> well it was definitely being called way more often than it should, no town was ever deleted
05:20:47 <glx> when filtering was added, the old calls were not updated and triggered an apply filter when a resort was expected
05:21:21 <floodious> you said you thought maybe the issue was the filter changing each time even though it wasn't intended
05: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
05:23:42 <glx> because the trigger was wrong and the filter string was empty it forced rebuild
05:23:53 <glx> but now it should be back to normal
05: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
05:24:38 <glx> did you check with the latest source ?
05:24:51 <floodious> i haven't updated from applied patches no, just using my own patches
05:25:06 <floodious> but my build works fine with those applied
05:25:46 <glx> because now OnPaint() should very rarely call BuildSortTownList()
05:25:59 <floodious> i have to check the commits to see if all three/four of the patches got applied already
05:27:04 <glx> and usually OnPaint() calls it only if paint happens before 100th ticks
05:29:00 <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
05: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
05:29:55 <floodious> since the rebuild ends up showing up in display profiling rather than other parts where it belongs
05:30:05 <FLHerne> Ok, I was wrong about where the bug was, partly because glx already fixed the actual cause :P
05:30:16 <floodious> yeah you're using the current rev?
05:30:26 <floodious> i'm talking before these fixes started to be applied
05:31:29 <FLHerne> That might explain some of the confusion
05:31:38 <floodious> sorry, i should have asked when you updated the source
05:31:57 <floodious> i haven't even looked closely at whether it was fully patched yet
05:32:17 <glx> usually we always talk about current version of the source :)
05:32:45 <floodious> well, it's weird saying "this isn't a bug" about a bug that just got patched :)
05:32:57 <floodious> it's a squashed bug, okay
05:33:19 <glx> the call from OnPaint() was not the real bug
05:33:34 <floodious> no it's just showing as part of the connection from source to symptom
05:33:56 <floodious> like "doc i have a cough!"
05:34:04 <floodious> "well it's your airway!"
05: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
05: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
05:37:31 <floodious> the blit to screen is, but the renderer is single-threaded with window message loop + gameloop + etc
05:37:49 <floodious> renderer = i mean actually copying bitmaps to the canvas
05:37:58 <floodious> the threaded part is the canvas copy to screeen
05:38:05 <glx> yes because every thing is related to the game state
05:38:12 <floodious> old c-style code :)
05:38:29 <floodious> when CPUs only had one core, and threads were what you stitched your shorts with
05:40:02 <glx> it comes from original asm
05:42:42 <glx> anyway I should be sleeping :)
05:54:35 *** Thedarkb-X40 has joined #openttd
06:00:57 *** HerzogDeXtEr has joined #openttd
06:01:03 <FLHerne> floodious: > well, it's weird saying "this isn't a bug" about a bug that just got patched :)
06:01:23 <FLHerne> I didn't realize it had got patched since the version of the source you were looking at
06:01:45 <DorpsGek_III> [OpenTTD/OpenTTD] floodious closed issue #7905: TownDirectoryWindow::OnPaint() triggers large (>50ms) redraw times https://git.io/JejYt
06:01:45 <DorpsGek_III> [OpenTTD/OpenTTD] floodious commented on issue #7905: TownDirectoryWindow::OnPaint() triggers large (>50ms) redraw times https://git.io/JejYt
06:02:07 <FLHerne> ...or recently at all
06:02:40 <FLHerne> Thus reaching a wrong conclusion while trying to understand where the issue being discussed actually came from
06: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"
06: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
06:06:29 <floodious> you're right that i'm hard to understand
08:00:12 *** Wormnest has joined #openttd
08:24:56 *** andythenorth has joined #openttd
08:28:44 <andythenorth> is it though? :)
08:46:14 <DorpsGek_III> [OpenTTD/OpenTTD] andythenorth commented on issue #7901: Train prefers service in depot over station https://git.io/Jeh7q
08:53:16 <FLHerne> andythenorth: It's not that
08:54:23 <FLHerne> The train gets to a signal, looks for a depot to service at
08:55:21 <FLHerne> When it sees a depot in range, it goes directly there, even if the route goes past its current order
08:56:04 * FLHerne vaguely remembers this being a pain, before getting completely fed up with breakdowns/servicing altogether
08:56:19 <FLHerne> It happens with autoreplace sometimes too
08:56:28 <andythenorth> seems like the correct answer would be hard to anticipate
08:56:45 <andythenorth> changing it leads to reports 'why does the train not go for servicing'
08: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?
09:00:02 <FLHerne> The train will still go to the same depot after it's visited the station
09:00:29 <FLHerne> Unless the depot is only accessible from some tracks, or there's no signal after the platforms
09:01:17 <FLHerne> But that's much more of a user error
09:11:10 <Eddi|zuHause> i'm not convinced it's a situation that should be adressed
09:12:13 <Eddi|zuHause> you can use "service at" orders to prevent the situation
09:29:27 *** tokai|noir has joined #openttd
09:29:27 *** ChanServ sets mode: +v tokai|noir
09:30:27 *** sla_ro|master has joined #openttd
10:01:31 <DorpsGek_III> [OpenTTD/OpenTTD] LordAro commented on issue #7905: TownDirectoryWindow::OnPaint() triggers large (>50ms) redraw times https://git.io/JejYt
12:44:45 <DorpsGek_III> [OpenTTD/OpenTTD] astetyn commented on issue #7901: Train prefers service in depot over station https://git.io/Jeh7q
13:06:25 <DorpsGek_III> [OpenTTD/OpenTTD] nielsmh commented on issue #7901: Train prefers service in depot over station https://git.io/Jeh7q
13:48:22 *** andythenorth has joined #openttd
14:27:22 *** snail_UES_ has joined #openttd
14:30:58 *** andythenorth has joined #openttd
16:00:31 *** HerzogDeXtEr has joined #openttd
16:19:52 <jlx_> Has anyone experience with 4096x4096 maps? Is this playable on a modern CPU if you have many train stations?
16:20:11 <jlx_> With an empty map, it seems to work well (except autosaves, they take 10 seconds)
16: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
16:33:04 <planetmaker> jlx_, it works, sure. Yet, of course, the overall limit for vehicles etc. is smaller
16: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
16:34:01 <planetmaker> I try to actually encourage people to try the somewhat funky map aspect ratios like 256 * 2048 or 256 * 4096.
16:34:21 <planetmaker> The feel for long distances is there, but the load on the computer much smaller due to reduced map size
16: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
16:34:43 <planetmaker> on my server I try to limit maps to 1M tiles generally
16:35:13 <planetmaker> so... 1000 x 1000, 500 x 2000, 250 x 4000 :)
16:36:06 <planetmaker> But as with all these things: your milage may vary. :)
16:36:17 <planetmaker> Try out and see whether it (still) suits you
16:36:18 *** andythenorth has joined #openttd
16:36:27 <jlx_> I also noticed that in 1830, there are still no trains... in what year do I need to start?
16:36:40 <nielsm> default vehicle set is designed for 1950 start
16:36:45 <jlx_> there's a message box saying 1899, but that sounds a bit late
16:36:46 <planetmaker> hehe. Well, default game w/o NewGRFs is supposed to start in ... 1950
16:36:51 <planetmaker> will work from 1930
16:37:13 <nielsm> you can get newgrfs that cover the full range of railroading history
16:37:18 <planetmaker> But w/o NewGRFs with early vehicles a date before 1930 is not a good idea
16:37:45 <planetmaker> (and also think about RV, ships and planes when thinking NewGRF vehicles)
16:39:19 <jlx_> is there a good NewGRF set with old European or American trains? (old = ~1850)
16:41:55 <nielsm> you pretty much have to be more specific than that: USA, canada, britain, germany, france, ...?
16:42:35 <nielsm> I think the gigantic 2cc Trains in NML also covers from around 1850 and it has from all over the world
16:42:49 <nielsm> (can be configured to enable/disable specific regions)
16:45:48 <planetmaker> indeed. There's a huge choice. UKRS, NARS, IronHorse, 2ccTrains, French, Czech come to my mind immediately. And there's more.
16:46:31 <Samu> i found a parameter not being used
16:46:56 <planetmaker> Add egrvs for vehicles. And SquidAteFish for ships. And avi8 for planes and you're set to go :)
16:48:03 <Samu> Trackdir trackdir isn't being used
16: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
16:52:12 <planetmaker> But no doubt... there's potential for clean-up :)
17:01:36 <FLHerne> jlx_: Early Rail + UKRS2 is good for starting ~1800
17:02:23 <FLHerne> Also "Town and Industry - UK Houses Early Mod"
17:02:46 <jlx_> Thanks for the recommendations, I'll try some of them out
17:02:53 <FLHerne> (much prettier than the default houses, and also keeps the population lower)
17:03:07 <jlx_> Do more NewGRFs for trains or stations make the game significantly slower?
17:03:12 <FLHerne> Oh, there's a Sailing Ships grf too
17:03:20 <planetmaker> SwedishHouses is actually my favourite. But... not for that early
17:03:23 *** Wormnest has joined #openttd
17: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
17:04:24 *** supermop_work_ has quit IRC
17:04:36 <FLHerne> I've had games with several thousand vehicles before, I wouldn't worry too much
17: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
17:05:39 *** supermop_work has joined #openttd
17:05:59 <planetmaker> 5k trains on 512^2 :)
17:06:16 <Borg> FLHerne: getto style junctions? ;)
17:06:35 <FLHerne> On a 512^2 map, you know the geography and where all the towns and most of the industries are
17:07:08 <FLHerne> So there's much more sense of place than having a huge map and just building lines between arbitrary places
17:07:32 <Borg> I like smaller maps too tho...
17:07:54 <Borg> its fun having dense rails build.. and trying to put station here and there..
17:08:18 <Borg> still having server up w/ game 2300+ year.. not feeling to finish it yet
17:12:03 <Samu> Cleanup: Remove unused parameter ?
17:12:15 <Samu> what commit message for this?
17:12:36 <planetmaker> yes, exactly like that @ smau
17:12:58 <planetmaker> ehm... ^^ @Samu. Sorry :)
17:24:13 <Samu> ready for PR, but it's probably gonna mess up the ship cache
17:25:59 <FLHerne> andythenorth: Did you change the cargo classes for Clay in FIRS 3?
17:26:12 <Samu> oh crap, NULL to nullptr, have to fix this
17:26:28 <FLHerne> It can't be carried in the UKRS2 steel opens or hoppers, which I don't remember being an issue before
17:29:04 <supermop_work> maybe andy is making proprietary grfs
17:48:27 *** Progman has joined #openttd
17:49:01 <Samu> wow the savegame highlight is such a welcome feature
17:50:21 <nielsm> it's a "you never knew how much you missed this" thing :P
18:02:19 <Samu> i wanna test ship collision avoidance against the pathfinder cache
18:06:40 <nielsm> well yes, the entire route is planned out beforehand
18:06:51 <nielsm> if anything they'll sail around where a ship was two months ago
18:11:16 <Samu> wasn't multidocks supposed to have a max 3 docking tiles per dock?
18: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
18:12:53 <nielsm> possibly even store the "reservation count" per direction
18: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
18:15:08 <nielsm> yes that's not handleable with that model
18: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
18:18:24 <nielsm> the issue here mainly being that checking for other vehicles ahead all the time might have a not insignificant cost
18:20:14 *** sla_ro|master has joined #openttd
18:28:48 <Samu> im unsure if I submit it
18:30:42 *** WormnestAndroid has quit IRC
18:32:04 *** WormnestAndroid has joined #openttd
18:32:58 <Samu> there's another one, lifetime profit, also not my work
18:35:22 <Samu> it's also missing AI functions
18:41:47 <Samu> i will wait for #7909 first
18:47:15 <Samu> AMD FX(tm)-8150 Eight-Core Processor
18:49:03 <Borg> hmm.. specs says it should have 8 cores indeed... maybe some windows update melted 4 others.. ;)
18:50:19 <Samu> that's AMD's Adrenaline Software stuff
18:50:36 <Samu> they themselves report that the 8 core cpu is a 4 core
18:56:49 *** supermop_work_ has joined #openttd
19:09:19 <Samu> it's using the a - b comparion and not a < b
19:12:00 *** frosch123 has joined #openttd
19: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
19:45:51 <DorpsGek_III> - Update: Translations from eints (by translators)
19:49:46 <Samu> but there's still missing NoAI functions
19:50:04 <Samu> I suppose they might come useful
19:51:43 <nielsm> it's not particularly difficult to add those
19:52:03 *** andythenorth has joined #openttd
19: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
19:52:43 <andythenorth> FLHerne: FIRS 3?
19: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
19:54:49 <frosch123> i wanted to say "it's andy's fault anyway"... but there is actually one line from me
19:55:56 <Samu> hmm some gui improvements are needed yet
19:56:04 <Samu> well, be back later ,dinner ready
19:56:08 <andythenorth> frosch123: you can default to that anyway
19:56:19 <andythenorth> 9 times out of 10 it's true and doesn't offend
19:56:26 <andythenorth> 1 time out of 10 it feels like the lolz failed :(
19:58:17 <andythenorth> so what shall we do today?
19:58:25 <andythenorth> endlessly rework the UK Horse?
20: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
20:03:00 <frosch123> can you rename the roster so it no longer references "uk"? problem solved
20:08:11 <supermop_work_> what should i do today andythenorth ?
20:09:55 <andythenorth> frosch123: "95 engines and 355 wagons inspired by British trains"
20:09:59 <andythenorth> "95 engines and 355 wagons inspired by trains" ?
20:11:15 <frosch123> "95 engines and 355 wagons for wet climate"
20:11:22 <supermop_work_> andythenorth: other than gantt chart
20:11:29 <andythenorth> ^ watch that video and report?
20:11:36 <andythenorth> the main character looks just like me
20: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
20:13:06 <andythenorth> this sounds like project management
20:13:19 <supermop_work_> that is technically my job
20:13:48 <frosch123> over the next two years? sound like you can just fill it in randomly
20:14:17 <supermop_work_> frosch123: i need to choose the right level of noise to make it not look random?
20:14:25 <DorpsGek_III> [OpenTTD/OpenTTD] JGRennison opened pull request #7911: Codechange: Remove std::function from Pool iteration wrapper https://git.io/JejKp
20:14:27 <frosch123> don't forget amf1 and amf2
20: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
20: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
20: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
20:34:34 <frosch123> LordAro: fyi, eints will remove the invalid strings next evening
20:35:46 * nielsm thinks about how to potentially do some GS industry control again
20:36:21 <nielsm> it's troublesome since there's two basic production level controls (classic and smooth) and then newgrf
20:37:11 <frosch123> remove smooth, then there are only two
20: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
20:38:04 <frosch123> i think the cheat already checks some level of is-this-a-newgrf-industry
20:38:04 <_dp_> nielsm, just add an option to stop production changes, will solve a lot of problems
20:38:50 <frosch123> i wondered about an "economy speed" setting in the past, which scales the number of random changes
20: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
20:39:01 <frosch123> except smooth economy is broken by design :)
20:39:32 <_dp_> frosch123, what's wrong with smooth economy?
20:39:38 <nielsm> so you can make a scenario where industries stay where the designer put them until a player begins interacting with them
20:39:44 <_dp_> except that's one setting that does billion of things
20: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
20:42:04 <frosch123> both makes production changes essentially pointless, better to leave them out then
20:42:49 <_dp_> not pointless, just less randomness
20:42:55 <frosch123> oh, and 3) it spams the news
20:43:12 <nielsm> ugh these header names... industry.h, industry_type.h, industrytype.h
20:43:18 <nielsm> struct Industry is in industry.h
20:43:33 <frosch123> original economy requires player action when something changes. smooth is just whatever
20:44:19 <frosch123> nielsm: it's somewhat consistent though :) there is no industry_base though
20:44:54 <_dp_> yeah, so original doesn't suit some playstyles and smooth just rewards goods setups in a long run
20:45:45 <_dp_> miroing industries is the last thing I want when I play
20:47:58 <andythenorth> the frosch123 econonomy newsletter :)
20:48:14 <andythenorth> I considered before having FIRS optionally listen to OpenTTD production change
20:48:19 <andythenorth> in addition to supplies
20:48:57 <andythenorth> but the suckiness of the economy makes it unappealing to work on :)
20:51:04 <frosch123> games need some unpredictable element, economy changes, breakdowns,... othewise they become clicker games
20:51:57 <frosch123> there is nothing more stupid than a factorio speedrun :)
20:52:44 <frosch123> someone made the comparision with color-by-numbers
20:53:06 <andythenorth> I think current FIRS is like building Lego
20:53:18 <andythenorth> and Steeltown economy is like building Lego Technic
20:53:44 <andythenorth> I'm quite happy with that gameplay, but there's no variation
20:53:50 <frosch123> oh, i watched someone rant about the current lego technic season :)
20:54:33 <andythenorth> FIRS (ignoring Extreme) tends to connect primaries, get supplies, boost primaries, connect secondaries, connect tertiaries, fund more primaries, repeat
20:55:09 <andythenorth> it's fine, but there's nothing for e.g. storybook gameplay on a small map (as a random example)
20:55:15 <frosch123> yep, playing firs on a flat map must be very boring
20:55:32 <andythenorth> Steeltown works because it's fricking hard fitting enough stations in :P
20:55:45 <andythenorth> but that will be solved by industry sub-layouts so eh :)
20:55:53 <andythenorth> mumble mumble economy
20:56:02 <frosch123> is that a reason against sublayouts? :p
20:57:01 <_dp_> for goal games randomness is not good if there is too much of it
20: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
20:57:57 <nielsm> well I managed to explain that OTTD speedruns that allow fast forward are meaningless
20:58:05 <nielsm> since that depends on machine speed :P
20:58:32 <Samu> JGR does some string magic which prevents translators from translating
20:59:39 <_dp_> even without fast-forward it's quite questionable
20:59:53 <Samu> avoids translators translating
20:59:56 <frosch123> _dp_: it involved playing the same map over and over again, while memorising/optimising the same factory over and over again
21: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
21:00:31 <frosch123> training to perform the same N-hour-click-sequence :)
21:00:47 <_dp_> frosch123, that's pretty much how any speedruns are
21:01:44 <_dp_> discovering new strategies and training hard to run them frame-perfect
21:02:12 <frosch123> nielsm: you can measure speedruns in realtime or in in-game time :) you either need to ban ff or pause :)
21:02:58 <nielsm> for ottd it makes sense to measure game time in ticks
21:03:27 <nielsm> actually we should change the _tick_counter to uint64
21:03:48 <nielsm> so you can get a real count of ticks elapsed since start of game
21:05:38 <frosch123> i missed a 0, but ok, 32bit ticks are already hard to reach
21:05:49 <_dp_> on citymania I measure times in game date, just converting them to look realtime-ish for display
21:06:36 <nielsm> problem with game date is that you can cheat it and it can reach max year
21:07:30 <_dp_> well we run servers so not a problem :p
21:10:05 <Samu> the new screenshot feature is kinda dumb, it screenshots itself :(
21:10:23 <_dp_> and doing anything to prevent cheating speedruns in singleplayer seems pretty pointless
21:10:47 <_dp_> it's a piece of cake to sneakily tweak an opensource game
21:11:01 <_dp_> and ppl cheat speedruns even in closed source ones
21:12:26 <floodious> i don't really see it as cheating, how would that be possible?
21: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
21:13:18 <nielsm> eh well, speedrunning is completing a specific goal under specific game conditions within as low a time as possible
21: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
21: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
21:14:44 <_dp_> floodious, that's called tool-assisted speedrun (TAS)
21:15:02 <floodious> it's not breaking rules of the game, it only improves the UI for that particular player
21:15:22 <nielsm> a difficult to detect ottd mod that could make speedrunning easier would be something like slightly increasing passenger production in towns
21: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
21: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"
21:16:05 <nielsm> yes but this is done in singleplayer mode
21:16:23 <nielsm> and there is no such thing as replay recording in ottd
21: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
21:17:34 <floodious> a very slimy thing to lie about, since cheating in a game is so backward to the purpose of the game
21:19:09 <_dp_> ui improvements are somewhat an issue even in mp
21:19:24 <_dp_> we just solve it by having an official patched client with everything xD
21:19:44 <Samu> current usage is now gone :p
21:19:51 <floodious> like use crypto signatures on the save game? :)\
21:20:27 <floodious> "the official MP version has this signature key, all games must be signed to be valid"
21:21:40 <andythenorth> shall we talk about horsepower-per-ton? o_O
21: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
21:21:46 *** sla_ro|master has joined #openttd
21:22:01 * andythenorth has been doing maths
21:22:12 <andythenorth> tech tree progression is interesting
21:22:43 <andythenorth> I think by late game it's reasonable to expect trains to accelerate to top speed in a reasonable tile distance
21:22:50 <andythenorth> and also that top speeds are relatively high
21:23:07 <andythenorth> it's also reasonable that wagon capacity increases
21:23:33 <andythenorth> vehicle weight is potato / potato, could go down (aluminium) or up (more air-conditioning)
21:24:38 <andythenorth> Horse trains that weigh 138t / tile, need 3720hp to do 87mph, and 4144hp to do 96mph
21:24:54 <andythenorth> so 400 hp bump to reach top speed in ~same tile distance
21:25:05 <andythenorth> but we also expect MOAR from progression
21:25:09 <DorpsGek_III> [OpenTTD/OpenTTD] floodious commented on issue #7905: TownDirectoryWindow::OnPaint() triggers large (>50ms) redraw times https://git.io/JejYt
21:25:12 <andythenorth> so STRONK engines
21:25:30 <andythenorth> but if the power bump is too much, it leaves the engine OP for existing routes
21:25:49 <andythenorth> this cause late game tech tree to need a lot of engines, where early game just needs a few
21:26:16 <andythenorth> TL;DR I should have done 5 generations in Horse, not 6 :P
21: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
21:27:26 <andythenorth> or I should do it in Horse docs, train stat tool!
21:27:47 <DorpsGek_III> [OpenTTD/OpenTTD] floodious commented on issue #7905: TownDirectoryWindow::OnPaint() triggers large (>50ms) redraw times https://git.io/JejYt
21:28:31 <Samu> hmm it looks rather bad :(
21:28:58 <Samu> the height of the line just before Profit this year
21:33:38 <Samu> oh boy, too much magic happening on resizes
21:36:55 <Samu> I'm not sure how to fix this
21:43:29 <Samu> ah, i think i figured it out
21:44:27 <Samu> nop, i didnt after all :(
21:50:18 <DorpsGek_III> [OpenTTD/OpenTTD] michicc commented on pull request #7911: Codechange: Remove std::function from Pool iteration wrapper https://git.io/JejXO
21: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
21:52:27 <Samu> didn't confirm after the fix
21: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)
21: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
21:53:45 <floodious> the town name and pop goes blank but it works, but that never gets removed in my older code
21:54:16 <floodious> only gets rebuilt from OnPaint(), so that would mean the On100thTick() is re-sorting an invalid list with a void entry
21:54:44 <floodious> anyway i'm out for now, not a biggie since OnPaint() does it anyway (...)
22:01:40 <DorpsGek_III> [OpenTTD/OpenTTD] JGRennison commented on pull request #7911: Codechange: Remove std::function from Pool iteration wrapper https://git.io/JejXX
22:03:06 <Samu> wondering where do I have to change to get this resize correctly
22:04:01 <Samu> so far I changed line 408 and 444, made it FONT_HEIGHT_NORMAL * 4
22:23:10 <DorpsGek_III> [OpenTTD/OpenTTD] nielsmh opened pull request #7912: Feature: Disallow industry production changes from GS https://git.io/Jej1Z
22:23:53 <_dp_> nielsm, isn't INDCTL_NO_PRODUCTION_CHANGE same as INDCTL_NO_PRODUCTION_DECREASE & INDCTL_NO_PRODUCTION_INCREASE ?
22:24:31 <nielsm> the first does not evaluate production change chances at all and skips the newgrf production change callback
22: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
22:25:26 <_dp_> nielsm, well, you could always check decrease & increase for early return
22:25:44 <_dp_> unless there is some usecase for callback to be called but ignored
22:26:20 <nielsm> the production change cb allows industies to post news messages too, without changing production
22:27:07 <nielsm> but, newgrf industries might even have their own internal production level variable that could ignore these flags entirely
22:27:39 <nielsm> even allowing them to change production levels based on the regular production callback
22:27:53 <nielsm> (just without showing news messages)
22:33:03 <_dp_> hm, I guess it's nice for consistency
22:42:16 <andythenorth> so can we graph engine stats?
22:42:29 <andythenorth> hp / engine weight
22:43:10 <andythenorth> plot speed for sample trailing loads on configurable grades
22:43:30 * andythenorth has added hp/speed to Horse docs, and it throws up a few things in tech tree
23:09:49 *** WormnestAndroid has quit IRC
23:10:12 *** WormnestAndroid has joined #openttd
23:14:22 <DorpsGek_III> [OpenTTD/OpenTTD] James103 commented on pull request #7912: Feature: Disallow industry production changes from GS https://git.io/JejMx
23:16:35 <Samu> this is more work than I anticipated
23:24:53 *** andythenorth has left #openttd
23: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
23:48:03 <LordAro> i always forget the order those need to be run in
23:48:08 <LordAro> Samu: feel free to PR it
23:50:28 <Samu> squirrel_export.vbs should have a "Done!" popup at the end of all tests
23:51:12 <glx> LordAro: generate then export ;)
23:51:43 <LordAro> Samu: it needs to be added to commit checker in some way
23:51:51 <LordAro> (or we need to hurry up with cmake)
23:52:19 <glx> I have a cmake fork adding it :)
23:54:12 <Samu> something so simple as adding a lifetime profit is already touching 21 files
23:55:14 <Samu> and I may be missing some places
continue to next day ⏵
