IRC logs for #openttd on OFTC at 2023-11-26
⏴ go to previous day
00:01:43 <peter1138> _glx_, oh, that's because I removed a cast because OpenTTD's Md5 doesn't need it.
00:02:09 <_glx_> yeah but there are 13 other warnings anyway
00:03:18 <peter1138> The "two" warnings are actually 1 warning from two builds, right?
00:04:28 <peter1138> Well, whatever, it's nicer without all that gumf
00:05:13 <peter1138> Hehe all the funny warnings about accepting a filename from the command line.
00:05:18 <peter1138> Yea... that's kinda the point.
00:05:43 <_glx_> these are not warnings, but errors from codeql
00:06:14 <_glx_> because it's not safe to thrust external data
00:06:16 <peter1138> They're still warnings, I am aware they're not compiler warnings.
00:06:24 <peter1138> Definitely don't thrust it.
00:07:06 <peter1138> Sorry but I'm not fine with adding warnings right now :D
00:08:15 <peter1138> And I ought to sleep before I stay up all night again.
00:13:01 <peter1138> I can't merge there so you might as well :-)
00:15:05 <_glx_> funny locally I get a "The contents of <filesystem> are available only with C++17 or later." warning
00:16:03 <_glx_> probably a VS2022 addition
00:17:05 <peter1138> No, I think -std=c++17 isn't specified.
00:18:21 <_glx_> yup cmake still says 11
00:18:45 <peter1138> Simple to fix. Sorry.
00:19:00 <peter1138> Er, but don't. It doesn't build, lol.
00:20:42 <_glx_> yeah internal compiler error
00:20:55 <peter1138> uint columns = (uint)max_element(sections.begin(),sections.end(), boost::lambda::bind(&vector<string>::size,boost::lambda::_1) < boost::lambda::bind(&vector<string>::size,boost::lambda::_2))->size();
00:21:08 <peter1138> That is not liked... and I have no idea what that is doing.
00:21:38 <peter1138> Sounds like I've become the grfcodec maintainer ;(
00:25:43 <_glx_> looks like a lambda pre c++11
00:26:04 <_glx_> which happened to still work with c++11
00:40:40 *** dale has quit IRC (Remote host closed the connection)
01:13:16 <_glx_> ok fixed the line, and c++17 works
01:29:35 *** Wolf01 has quit IRC (Quit: Once again the world is quick to bury me.)
02:36:19 <_glx_> BTW the boost::lambda stuff is equivalent to `uint columns = (uint)max_element(sections.begin(),sections.end(), [](auto a, auto b) { return a.size() < b.size(); })->size();`, but I removed the need to switch to c++17
03:17:00 *** Wormnest has quit IRC (Quit: Leaving)
03:18:10 *** debdog has quit IRC (Ping timeout: 480 seconds)
03:19:37 *** D-HUND is now known as debdog
06:50:40 *** tokai|noir has joined #openttd
06:50:41 *** ChanServ sets mode: +v tokai|noir
06:57:26 *** tokai has quit IRC (Ping timeout: 480 seconds)
07:41:57 *** kuhnovic has joined #openttd
07:41:57 <kuhnovic> talltyler: It definitely needs some heavy play testing. I've done that already with a couple of friends to work out the initial issues. But that's still the developer testing his own stuff, to some extent. It wouldn't hurt to have some extra pairs of eyes look at this 🙂
08:00:13 <rau117> kuhnovic: Is pre-compiled version aviable?
08:00:13 <rau117> If this is really important thing, then it worth making a post in Reddit/ottd website about needed help.
08:00:13 <rau117> __The main thing is not taking away the **only** ship advantage – no collision with other ships.__
08:05:57 <peter1138[d]> Oh.. filesystem wasn't even needed hah
08:10:31 <Eddi|zuHause> rau117: the main problem with this argument is that it makes no sense for ships to have this advantage in the first place.
08:13:36 <merni> but, fwiw, this patch preserves that advantage
08:22:34 <locosage> it makes sense for them to have at least some advantage, otherwise you may as well remove them from the game :p
08:23:20 <locosage> also, it's quite realistic, a lot of ships can use small canals without colliding, it's just that game scale can't represent that adequately
08:23:27 <rau117> Eddi|zuHause: Planes - simplicity and speed, buses - transfer from inside the city, trains - simply the best form of transport...
08:23:27 <rau117> What about ships? They are slow, not that spacious, and require expensive channels (3.75k per tile) to move deeper into the continent. But they can pass through each other to maintain high throughput. Without this, the ships will remain practically useless.
08:23:27 <rau117> For a more advanced game, of course. Not from the side of “beginners” or “realism” (for realism there is JGR and there is already a setting for collision).
08:35:53 <andythenorth> was if flat docks yet?
08:56:22 <Flygon> Having smaller "level" piers as opposed to bigger ones for rivers would be great hahaha.
08:58:41 *** HerzogDeXtEr has joined #openttd
09:23:50 <truebrain> hmm, that PR now also no longer tells the user when it ran out of memory during sprite-cache stuff, right?
09:26:07 <truebrain> the diff is a bit tricky to read 😄
09:26:13 <truebrain> due to GitHub's visualization
09:32:10 <truebrain> LordAro: #11488 should be closed either way, as it is a nonsense ticket 😛
09:32:19 <truebrain> worrying about virtual memory is a bit pointless 🙂
09:32:45 <_zephyris> andythenorth: I've never tried a flat dock implementation - is there one? Does it need sprites?
09:33:30 <truebrain> To reword it: #11488 is not a bug of any kind. But yes, #11495 seems to do the "feel free to change this" comment of mine 😛
09:34:35 <truebrain> _jgr_: I tried to discover myself what happens when allocations fail because the computer ran out of memory, but I have a hard time finding that out 😦
09:35:39 <truebrain> I think that will assert on the second sprite after the first fails to allocate?
09:39:10 <_jgr_> A program can have more virtual memory allocated than physical memory available
09:39:40 <_jgr_> Running out of memory all together typically means that one or more programs are killed outright
09:40:03 <andythenorth> _zephyris: no implementation 🙂
09:40:10 <truebrain> yes; that is what my comment in the PR was about; but now I was just more wondering: what actually happens? I was trying to follow the code, and I had a bit of a hard time
09:40:27 <truebrain> the question is not: should we do anything when it fails; it is about: I am trying to follow the code and I fail 😛
09:40:28 <_jgr_> It's the same as any other normal allocationusing malloc/new
09:40:54 <truebrain> it seems I have to add more context to my question, as it seems it is being overtaught 😄 (which I can understand btw)
09:41:07 <truebrain> I was looking at the Allocate function, and it sets the data to the allocation, and the size to the requested size
09:41:17 <truebrain> so I was like: those can, in theory, mismatch, and you don't check for allocation failure
09:41:21 <truebrain> so is that actually a problem?
09:41:48 <truebrain> as GetData and GetSize will disagree, basically
09:42:27 <_jgr_> If new fails, the program is killed
09:42:40 <truebrain> doesn't it return a nullptr?
09:43:07 <truebrain> owh, yeah, ofc, you need a `std::nothrow` for that to not happen
09:43:48 <_jgr_> In principle you could use that, but if you can't allocate a single small object then the game is up already
09:44:43 <truebrain> as I said, my question was much more splicitic in nature 😄
09:45:11 <truebrain> now I wonder if there isn't already a container in STL that does what SpriteDataBuffer does 😛
09:46:20 <truebrain> Java (yes, I have been writing Java, don't get me started) has a ByteBuffer
09:47:57 <jfs> std::vector<char> is guaranteed to be a contiguous slab of memory that can be reallocated...
09:51:27 <truebrain> did _zephyris actually fix river slopes being more visible in their direction?! 😮 😮
09:51:49 <truebrain> I guess that answers why #11492 is needed .. lol
09:52:51 <_jgr_> I'd always thought that vector was a bit odd for this sort of thing, seeing as it's inherently a resizable container with separate capacity and size
09:53:48 <jfs> true, if you resize a vector smaller it doesn't reallocate so might just keep using the same amount of memory
09:56:43 <_jgr_> I suppose there's shrink_to_fit for that
09:57:15 <truebrain> sounds like more code that can break; in that case your code is better 🙂
10:06:45 <truebrain> whole ticket about SDL fullscreen .. why do people run games in fullscreen? It rarely works 😛
10:06:54 <truebrain> (sorry, catching up with PRs and issues 😛 )
10:21:19 <truebrain> _jgr_: tnx for the `to_remove`, that really is much more clear 🙂
10:44:47 <lamarr> truebrain: huh? the vast majority of games I play work fine in fullscreen, I'd even say it's the general standard
10:54:34 <jfs> can we just remove fullscreen and tell people to resize/maximize the window to desktop size if they need to?
10:55:18 <Eddi|zuHause> have you ripped out a page from the "andy's arguments" book?
11:00:03 <Eddi|zuHause> the most problems i had with "fullscreen" in the past were due to changing resolution
11:01:11 <Eddi|zuHause> a problem that doesn't occur with borderless window, as it is naturally forced to the desktop resolution
11:09:41 <_zephyris> There is a maximise/restore bug on windows... If it starts as a non-maximised window, then maximise/restore behave nicely. If it starts maximised then restore doesn't change the window size.
11:10:46 <_zephyris> And annoyingly, at least on win10, going from a maximised window to a restored window increases titlebar size and window padding, so the window edges/corners go off-screen and you can't grab them to resize the window.
11:20:40 <truebrain> lamarr: Borderless fullscreen is much more common and much better in many ways. Changing resolutions of a screen is very troublesome, on all OSes, for many reasons. It is also a weird concept, that was only useful in the old days, where you would like to run a game fullscreen on a different resolution than your desktop resolution. It no longer makes actual sense
11:21:12 <truebrain> "back in my day", games had to run in 640x480 while your screen was already a wopping 800x600!
11:21:19 <truebrain> but these days that is all nonsense 😛
11:21:29 <truebrain> been willing to add borderless fullscreen for years, but never got to it 😛
11:21:53 <michi_cc[d]> Add background sounds of certain players getting out the pitchforks 🤣
11:22:21 <truebrain> it is funny how a lot of games have "Fullscreen", which in fact is implemented as borderless 😛
11:22:52 <truebrain> to avoid those pitchforks 😄
11:23:06 <michi_cc[d]> Most of them have variable-.sized GUI and content (i.e. rendered 3D) though.
11:23:28 <truebrain> yeah, that caught on nicely in the last few years
11:24:14 <_zephyris> I heard that this 3D thing has been catching on.
11:24:16 <michi_cc[d]> With this the actual resolutions really is mostly whatever.
11:25:37 <michi_cc[d]> Though of course personally I never play anything fullscreen, because I don't have enough desk space to allocate a full monitor to each and every application I run at the same time 😛
11:26:07 <truebrain> in the old days, you needed fullscreen as otherwise your GPU couldn't accelerate the game sufficiently
11:26:12 <truebrain> that too, hasn't been true in 10 years 🙂
11:26:40 <truebrain> it is funny how much things changed in the last decade or so
11:26:59 <truebrain> anyway, the only legit reason I know for OpenTTD to have a fullscreen is what you mentioned already: people on 4k wanting to play the game 😛
11:28:38 <Eddi|zuHause> i wonder why OSes haven't implemented window-specific zoom yet
11:29:23 <truebrain> I doubt a generic implementation of that is even possible
11:29:31 <truebrain> an OpenGL pane wouldn't know about that, for example
11:30:23 <michi_cc[d]> On modern Windows it should actually be possible as everything goes through dwm, including 3D content.
11:30:47 <truebrain> handling of subpixels would be awkward in that case
11:30:59 <truebrain> so it would only be able to do 2x, 4x, etc I guess?
11:31:08 <michi_cc[d]> Sure, any sub-pixel text rendering would probably look horrible 🙂
11:31:25 <truebrain> I think it would make for a very shitty experience 😛
11:31:34 <truebrain> (which might be the reason nobody does it 😄 )
11:35:59 <lamarr> truebrain: that's fine, I'm not a sticky for 'true' full screen ! I just want the window to take up the full screen space lol
11:36:26 <truebrain> yeah, just to be clear, in no way shape or form I am suggesting the bug isn't legit and shouldn't be fixed
11:36:34 <truebrain> I was just having fun of people still using fullscreen 🙂
11:38:21 <truebrain> Owh, the old days, where "multimonitor" in X11 just didn't exist ... it was just one big monitor, as far as X11 was concerned ..
11:38:25 <truebrain> you couldn't even maximize a window
11:40:37 <jfs> I don't remember if that's being done already, but imo at least in accelerated video drivers (OpenGL) selecting fullscreen should not use exclusive fullscreen, but just do desktop-sized window and scale the selected resolution to that
11:41:08 <truebrain> like, a borderless fullscreen you mean? 😛
11:41:26 <truebrain> truebrain: welcome to 10 minutes ago 🙂
11:42:01 <jfs> I'm just qualifying it a bit more, with the "when using an accelerated video output"
11:42:26 <truebrain> I was refering to the "if that's being done already" 🙂
11:42:42 <truebrain> we have two modes: exclusive full screen or windowed
11:44:22 <truebrain> plenty of places to still improve OpenTTD 😄
12:04:04 <peter1138[d]> Back now. Yes v2 to allow 32bpp in basesets
12:04:22 <peter1138[d]> Er, in our extra data, sorry
12:04:32 <truebrain> Something to add to the motivation, for future-us 🙂
12:04:54 <peter1138[d]> Yea, forgot to add that
12:05:29 <peter1138[d]> Also, vectors for a data buffer are good, it avoids messing with pointers at all.
12:06:06 <peter1138[d]> The only advantage of the unique_ptr approach is you don't waste time initializing the buffer
12:06:34 <peter1138[d]> I assumed that was the motivation in the sprite cache stuff.
12:06:35 <truebrain> also no storage container for capacity, I guess. Saves some bytes! 😛
12:06:53 <peter1138[d]> Well no, it's just built-in 🙂
12:07:21 <peter1138[d]> But you can just use a vector instead of that whole class, I think.
12:07:48 <truebrain> a vector stores both the capacity and current-size, not?
12:08:04 <truebrain> just curious btw, don't get what you mean with "built-in"
12:08:11 <peter1138[d]> Ah right, I see what you mean now
12:08:20 <truebrain> storage container is a poor choice of words
12:08:30 <truebrain> replace it with "variable"? Well, what-ever, that! 😛
12:26:33 <peter1138[d]> Is it sleep time yet?
12:32:48 <Eddi|zuHause> why is it that games that used to run fine half a year ago don't anymore?
12:32:52 <Eddi|zuHause> like... what even changed?
12:34:09 <peter1138> Do you mean don't run at all, or run but slower?
12:34:42 <_glx_> Same with subtitles, screen sizes increases, subtitles sizes are smaller ans smaller
12:35:31 <Eddi|zuHause> like in... it doesn't even start
12:35:51 <peter1138> Okay, then report a bug.
12:35:51 <truebrain> in general, life just progresses worse and worse 😛
12:36:17 <peter1138> Don't think it's expected and normal.
12:36:53 <peter1138> (Although I think there's a few revisions which were incompatible due to changing Linkgraph saveload a little.
12:37:09 <truebrain> is he even talking about OpenTTD?
12:37:11 <Eddi|zuHause> but report bugs to where? graphics driver? proton? any number of installed libraries?
12:37:27 <peter1138> I assumed it was OpenTTD savegames :o
12:37:27 <Eddi|zuHause> no, i'm talking about games in general
12:37:41 <truebrain> it is a sane assumption, but it is Eddi 😛 😄 ❤️
12:38:02 <Eddi|zuHause> why would anyone even assume "sane"? :p
12:39:17 <_zephyris> Is the chat about v2 container hashes going to change the hash?
12:40:16 <peter1138> _zephyris, the issue is OpenTTD's built system doesn't use the correct tool to calculate NewGRF hashes, so it miscalculates the hash for container v2 NewGRFs.
12:40:34 <peter1138> But it is just our build system that is wrong, not the tools or OpenTTD itself.
12:40:51 <peter1138> It was never an issue because our NewGRF has always been v1 :)
12:41:19 <_zephyris> I remember it being annoying to get 32bpp base sets working
12:42:11 <_zephyris> Ie. You have to use the nmlc reported hash, not the file hash
12:42:29 <peter1138> Yes, that's the same issue. But that is precisely why nmlc reports the hash.
12:43:09 <peter1138> It's by design, in v2 the hash does not cover the graphics themselves.
12:44:11 <peter1138> This means a 32bpp 4x extra zoom NewGRF can be considered compatible with a 8bpp 1x zoom NewGRF, as long as the actions-part of the NewGRF is the same.
12:45:35 <peter1138> _zephyris, there is a tool that comes with grfcodec called "grfid" that... apparently I wrote.
12:45:55 <peter1138> It was since updated to be able to calculate the md5 hash of v1 and v2 container NewGRFs.
12:46:03 <_zephyris> Hah, in the mists of time then 🙂
12:46:04 <peter1138> So if you need a separate tool to do it, use grfid.
12:46:27 <_zephyris> peter1138: Makes sense
12:46:28 <peter1138> I wrote it in ~ 2009, before v2 existed, and it could only get the grfid back then.
12:47:05 <peter1138> And the latest unreleased version of it uses standard C++ instead of hacking around windows and linux specifics :D
13:05:28 <talltyler> Uh Peter, #11435 doesn’t redraw properly yet 😄
13:05:48 <talltyler> There’s a to-do bullet in the description explaining what’s wrong 🙂
13:05:52 <peter1138> Oh, s the second commit wasn't it?
13:20:09 <peter1138> * [new ref] refs/pull/11435/head -> pr11435
13:20:29 <peter1138> Time to test... with timetables... which I don't normally use :D
13:22:47 <peter1138> timetable_gui.cpp:235 is suspicious.
13:24:10 <peter1138> (It's still building, I didn't get as far as running)
13:37:29 <peter1138> Awkward that we have signed and unsigned ticks.
13:38:42 <peter1138> Does andythenorth use timetables.
13:40:16 <peter1138> talltyler, yeah, "start_time" there changes about every 2 seconds, so...
13:47:15 <talltyler> Signed ticks is like an offset, TickDiff essentially
13:48:00 <peter1138> It's not odd, it's often considered bad-form to use unsigned where we think it shouldn't go negative.
13:48:10 <peter1138> Because often when calculations is needs to.
13:48:39 <talltyler> Yes, we need to be careful with the unsigned form. One of the reasons I gave it a separate type.
13:48:55 <peter1138> Anyway, using date_fract on that line is definitely the problem. That is rounding it to calendar days, which is 2 seconds.
13:49:08 <peter1138> Er, not rounding, aligning.
13:49:12 <talltyler> I’m actually considering making Ticks strongly defined like Date and Year, to avoid problems in the future
13:49:26 <talltyler> Oh interesting, I’ll take a look when I get home from my walk
14:04:21 *** Flygon has quit IRC (Quit: A toaster's basically a soldering iron designed to toast bread)
14:18:32 <peter1138> ./build/media/baseset/orig_extra/orig_extra.grf.hash
14:18:41 <peter1138> Ah, it writes it to the build folder :/
14:25:03 <peter1138> Oh right, the -E copy command just below also copies from build to src.
14:34:03 <talltyler> Hmm, now how do we align with full seconds and not use ticks...
14:34:42 <peter1138> Does it need to be aligned to full seconds?
14:35:03 <talltyler> It would be nice to be able to align vehicles
14:35:30 <peter1138> (I don't know what the alignment actually does)
14:35:49 <talltyler> Although, that would be when setting start dates and travel times, not displaying it
14:37:18 <talltyler> Oh, I wonder if the existing alignment is when we're timetabling in ticks, and travel/loading times can be in however many ticks the player wants
14:37:33 <talltyler> So that the date is correct
14:39:04 <talltyler> Let's build it and see if it works 🙂
14:46:10 <talltyler> Cool, it updates every second now, but the countdcwn goes...up??
14:46:43 <peter1138> Hmm, CI not running for 11492
14:47:18 *** virtualrandomnumber has joined #openttd
14:47:38 *** virtualrandomnumber has quit IRC ()
14:48:51 <peter1138> The way we use cmake's execute_process is a bit naughty :D
14:49:43 <andythenorth> peter1138: I use “wait 10 days” for loading pax vehicles
14:50:03 <peter1138> Yeah thanks. It was enough to load up your game and see timetable stuff happening :D
15:09:50 <peter1138> Removed the strip as well so the commit checker doesn't complain.
15:12:18 <_glx_> hmm and I should test locally before approve (CI doesn't validate grfcodec stuff)
15:14:47 <talltyler> Fixed! I also improved the timer to use ticks instead of seconds for the redraw interval, so it works in fast-forward. 🙂
15:15:57 <talltyler> Once that's merged, I get to start a really fun rebase of Real-Time Mode 😄
15:18:47 <peter1138> Redrawing based on ticks might want a lower limit though. Hmm.
15:19:17 <peter1138> (A minimum interval, that is)
15:25:47 <_glx_> custom targets are for manual runs
15:37:07 <_glx_> in some case custom targets are also part of the dependency tree, but not here
15:41:45 <_zephyris> Presumably I need to rebuild and update the river slopes PR to add the hashes?
15:42:26 <peter1138> Not yet, it's not merged yet :-)
15:43:05 <peter1138> But when you do, the .hash files will need to be included.
15:45:06 <andythenorth> peter1138: "timetable" because we don't have partial load order 😛
15:46:05 <peter1138> Implement partial loading by automatically adjusting the timetable, you say?
15:47:21 <andythenorth> hmm more Variants?
15:47:40 <peter1138> Add multiple parents?
15:48:20 <andythenorth> how about groups with dividers?
15:57:40 <talltyler> What lower limit? Less than a second?
15:58:04 <peter1138> I guess the lower limit is already the display refresh rate anyway, so not worth worring about.
16:00:44 <peter1138> _zephyris, now you can rebase and rebuild, and the game should be happy with the updated NewGRF.
16:01:40 <peter1138> (And include the changes to the .hash files in your commit.)
16:02:38 <_glx_> well include grf and hash 😉
16:02:51 <peter1138> GRF is already there :)
16:03:56 <_glx_> the good old time we had to not forget to generate script API and project files and include them in the commit
16:05:13 <_glx_> I think project files was the most often forgotten
16:19:04 <talltyler> Hopefully that fixes annotations 🙂
16:40:00 <peter1138> Uh, I wasn't saying it *should* be a vector...
16:52:03 <truebrain> Should this be a `Change`, as there is some functional difference? Nitpicking++, but still 🙂
16:55:11 <peter1138> truebrain, now the 'bug' will be too much memory fragmentation ;)
16:55:48 <truebrain> They know where to send PRs 😛
16:56:05 <peter1138> Especially with Iron Horse.
16:57:03 <truebrain> I am still not sure if allowing allocating all physical memory to spritecache is a good idea. The old approach to avoid it, can be kinda useful for people with low memory and little understanding what spritecache is and does
16:58:08 <truebrain> To be clear, the old implementation was silly. This PR is fine. We can always add later that we restrict the spritecache size
16:58:28 <peter1138> Do you think std::vector is the way to go, or std::unique_ptr + size_t?
16:58:30 <truebrain> I guess we just wait for reports on it (or not)
16:58:42 <peter1138> My comments on that were just comments, not actually requesting a specific direction to go in.
16:59:24 <_jgr_> Items are evicted from the sprite cache when it exceeds the configured limit, that is what the LRU tracking is about
16:59:28 <truebrain> peter1138: Same for me. I was just wondering out loud. Maybe we should benchmark it, what the footprint difference is, to make a call
16:59:39 <_jgr_> It's not unlimited memory use
16:59:53 <peter1138> _jgr_, the point is the configured limit was checked before, now it's not?
17:00:09 <peter1138> (i.e. if you configured it too high you'd get that message.)
17:00:25 <truebrain> _jgr_: Not my point. The old code checked if the limit configured didn't exceed physical memory * 60%
17:00:45 <truebrain> As a smaller cache isn't an actual problem, I guess
17:00:57 <peter1138> But as it is not a continuous allocation it is for use harder to check that.
17:01:16 <truebrain> We can just do a simple calculation
17:01:45 <truebrain> We already have code to get the physical memory
17:01:50 <peter1138> 16:19 < talltyler> Hopefully that fixes annotations 🙂
17:02:33 <truebrain> @JGR basically the old code prevented people on 1GB ram to set the setting to use 2GB and crash the game
17:02:44 <truebrain> It automatically made it smaller
17:03:23 <_jgr_> On a 64 bit OS, you quite could possibly allocate a 2GB buffer, so long as you never tried to write or page in all of it
17:03:29 <truebrain> But as I said, not really for this PR, just something for us to track, in my opinion
17:03:33 <_jgr_> With 1GB of physical RAM
17:03:56 <truebrain> No, allocation fails if it doesn't fit in your physical memory
17:05:16 <_jgr_> You need a bigger swap partition 😛
17:05:34 *** Wormnest has joined #openttd
17:05:47 <peter1138> I don't fancy having 128GB of swap myself.
17:06:07 <peter1138> It was okay with 128MB RAM.
17:06:19 <truebrain> _jgr_: Never said the current implementation makes sense 😛 but there is some merit 🙂
17:06:24 <LordAro> iirc there was an implicit min(.., 4G)
17:06:37 <LordAro> half the time you don't want swap at all nowadays
17:07:18 <_jgr_> Arguably it would be better to determine the limit automatically by sensible metric, instead of hoping the user will pick the right number (and not just go bigger number is better)
17:07:59 <peter1138> LordAro, is it safe to order from Wiggle...?
17:08:02 <truebrain> But let's cross that bridge if a user reports an issue with it 🙂
17:08:16 <peter1138> I'm not sure how they are still trading under administration.
17:08:58 <truebrain> _jgr_: I like that too; physical memory * 0.6 / 32bpp 😄
17:10:13 <peter1138> Pools. Pools could basically just be a std::vector of std::unique_ptr these days.
17:12:23 <talltyler> One step closer to making ticks strongdef and making a huge PR to fix all this stuff throughout the code
17:16:25 <talltyler> (I'm happy to make that first commit a separate PR if needed)
17:21:27 <LordAro> peter1138: seems fine
17:22:53 <peter1138> Interesting, building the baseset files can happen at the end of the build now. Oh well :)
17:30:20 <peter1138> (I've updated the text on that to include another rationale)
17:31:03 <talltyler> Oh, I saw the second rationale as I was coming to the same conclusion
17:33:24 <peter1138> One of my branches basically removes almost every SetMinimalSize().
17:33:51 <talltyler> Looking forward to reviewing it 🙂
17:33:59 <peter1138> Most of them are almost certainly just "copied & pasted" from when the original window layouts were fixed pixel layouts.
17:35:27 <peter1138> There are a few windows which are a bit odd w
17:35:32 <peter1138> ith no minimum size.
17:37:03 <peter1138> There are places where we've added widgets with different minimal sizes, but they're inside an NC_EQUALSIZE container.
17:37:22 <jfs> how dynamic can the window layouting be made, I wonder... the one thing that has always been troublesome for me is prose-like text that generally needs to be automatically broken to not produce ultra wide windows with single long lines. but where to break? something like "this window should not be wider than 1/3 the screen width, unless that means it would be taller than the screen", which might
17:37:22 <jfs> require several re-layouts to work out
17:37:50 <peter1138> jfs, this is now handled in a couple of places.
17:37:55 <peter1138> And yes, it requires 2 passes.
17:37:59 <LordAro> css layout engine when?
17:38:13 <peter1138> The main intro menu and the game options menu do it.
17:38:28 <peter1138> They rely on the rest of the window layout to produce a suitable starting point.
17:38:54 <peter1138> Once that is done, during OnResize() it knows the width it has to work with, so can calculate a height
17:40:01 <peter1138> That was the easiest solution without trying to bolt on a multi-pass system, I found.
17:40:34 <peter1138> So if your baseset is missing sprites, or your language is missing translations, that's using the OnResize() method.
17:42:45 <peter1138> Of course if the prose-like text is the main content of the window then there still won't really be a suitable width to start with.
17:43:33 <peter1138> One thing that might help is being able to specify a minimal width in relation to text rather than pixels.
17:44:09 <jfs> although there aren't all that many windows of that kind
17:44:28 <peter1138> The error window is the main one I can think of.
17:44:29 <jfs> the error messages and "quit? y/n" are the main ones I can think of, and then storybook
17:45:11 <jfs> I think for those in specific, going by some fraction of the total screen width might be reasonable
17:45:41 <jfs> ah yeah, there was the "server admins may be able to read this password" text
17:45:42 <peter1138> Story book's minimum is constrained but the 3 controls at the bottom.
17:45:53 <jfs> which I remember fighting a lot to make behave nicely
17:46:30 <peter1138> Anyway, removing SetMinimalSize() was the thing that revealed GetStringHeight(0) was totally broken :)
17:46:53 <peter1138> It trigged an OOM kill for me.
17:55:32 <jfs> ah, trying to make an infinite number of zero-width lines?
17:58:00 <peter1138> Hmm, Garmin Edge 1040... not bad.
18:17:03 <peter1138> Oof, rebase, don't merge :)
18:22:26 <talltyler> Okay, now it passes all the checks...and even works! 😄
18:28:12 <rau117> >>Requires a bump of original graphics grfs to use container version 2
18:28:12 <rau117> And will this... be built into the new version of the game, or will we have to do “something” with the the original_windows baseset?
18:30:36 <peter1138> It's not quite right, it's the container format of the GRF files that come with OpenTTD, not the original basesets.
18:37:25 <rau117> Okay, that's ±what I thought.
18:41:21 <_glx_> peter1138: and I think it's missing the new hash
18:41:45 <_zephyris> peter1138: YEah, I'm dumb
18:42:16 <_zephyris> Now I'm trying to work out how to revert a merge
18:42:47 <peter1138> interactive rebase, drop the merge commit?
18:43:52 <_zephyris> Probably shouldn't be trying to do this while holding baby... I'll do bedtime first!
18:43:53 <peter1138> Or create a branch off the original commit, delete the branch with the merge and rename the new branch to the old name.
18:47:19 <_glx_> oh and after the rebase, you'll need to rebuild to get the missing files
18:53:34 <_zephyris> Let's see if I do anything else dumb!
18:55:56 <peter1138> It's not dumb, it's doesn't need to do this regularly.
18:56:09 <peter1138> (Many projects are happy with merge commits)
18:56:18 <peter1138> Although actually, yeah, not rebuilding was a bit dumb ;)
19:04:55 <LordAro> peter1138: no changes in usage?
19:05:21 <peter1138> No, the usage change was already made a few PRs ago.
19:05:39 <peter1138> I... was lazy and didn't bother looking up the commit/PR, sorry!
19:06:39 <LordAro> more of a fix then? :)
19:06:47 <peter1138> Maybe. It's not broken per se.
19:08:10 <peter1138> Okay, updated the PR title, can change the message on squash.
19:08:56 <peter1138> I picked this up because I rebased my make-CargoID-a-strongtype branch, and this is exactly the sort of thing why it's a strong type :)
19:10:06 <andythenorth> cdist saturation calculation makes no sense 😄
19:10:30 <andythenorth> example train on an 'overloaded' route
19:32:53 <_zephyris> [please excuse my flailing while I try to work out what I'm doing]
19:43:22 <Rubidium> _glx_: that nullptr subtraction... what good fun... might even be that OpenTTD has UB in the similar code as it does not explicitly check the alignment of the data, and unaligned pointers are UB.
19:47:28 <peter1138> _zephyris, after building you need to add the two .grf.hash files to your commit.
19:48:14 <peter1138> If those are not updated then maybe grfid isn't working for you, but it should show an error at least if not.
19:51:34 *** gelignite has joined #openttd
19:53:04 <_zephyris> My issues are 100% git :)#
20:07:49 <peter1138> Is it okay to ignore invalid cargo in game?
20:08:42 <peter1138> Context is using range-iterator on _sorted_cargo_specs instead of looping from 0 to NUM_CARGO.
20:10:44 <peter1138> It can only be invalid in game if the player has changed NewGRFs that affect cargo types.
20:10:57 <peter1138> So it's probably undefined behaviour either way.
20:13:29 <peter1138> Hmm, I'm going with yes, considering I already made changes that do so :D
20:34:12 <_glx_> Rubidium: and grfcodec/nforenum coding style is so inconsistent
20:36:34 <Rubidium> it has a coding style? :D
20:36:39 <_glx_> only 3 warnings (x2 because clang is used by 2 targets) left in grfcodec, but they are a pain
20:37:29 <_glx_> the weird va_list stuff and the nullptr substraction
20:41:19 <_glx_> `__builtin_available()` is a nice invention, but it's annoying to use as you can't mix it with other conditions
20:41:57 <Rubidium> _glx_: smells like the va_list stuff doesn't like things like enums
20:42:27 <_glx_> yeah and the enum construction is another "funny" thing to follow
20:43:04 <_glx_> so good luck to use "find declaration" feature of the IDE
20:45:29 <_glx_> I think parts of the va_list stuff could be replaced with parameter pack
20:46:14 *** gelignite has quit IRC (Quit: Stay safe!)
20:47:03 <Rubidium> yeah, though that'l leave vIssueMessage
20:48:02 <Rubidium> although, if you change it to vIssueMessage(RenumMessageId message, int alen, int elen, ...) and use va_start on elen... it'll be fine (I think)
20:49:29 *** frosch123 has quit IRC (Quit: User went offline on Discord a while ago)
20:50:21 <Rubidium> might CheckLength be wrong? It doesn't do va_end when alen<elen (i.e. when it returns true)
20:50:27 <peter1138> Almost better to rewrite :o
20:51:08 <Rubidium> lets call rewriting "using nmlc" :D
20:51:21 <peter1138> That also needs a rewrite...
20:54:37 <_glx_> indeed CheckLength feels wrong
20:55:38 <_glx_> and all this stuff seems to be related to translatable error messages
20:59:58 <_zephyris> One day I may understand git
21:02:04 <andythenorth> peter1138[d]: was it random reverse? o_O
21:02:10 <andythenorth> or was it Archviles?
21:07:22 <peter1138> Currently, Marmite sausages.
21:18:35 <Eddi|zuHause> maybe git is like quantum mechanics. if someone says they understand it, they don't understand it.
21:25:26 *** nielsm has quit IRC (Ping timeout: 480 seconds)
21:32:18 <peter1138> `uint amount = ...; if (amount > 0) cargo_capacities[v->cargo_type] += amount;`
21:32:21 <peter1138> Good if-condition there ;)
21:32:55 <peter1138> I guess it saves on access to the array.
21:50:26 <_glx_> yeah casting the substraction should be cleaner
21:52:23 <peter1138> "sort of casting" :)
22:00:27 <andythenorth> ctrl-click to close *all* variant trees in buy menu?
22:37:25 <peter1138> I'm not sure how this works :/
22:38:05 <peter1138> Okay, so the pngs are copied to build at some point.
22:39:58 <_zephyris> Yeah, `CreateGrfCommand.cmake` does that, should be recursive for all `*.png`
22:40:32 <peter1138> Yes, it needs the project to be reconfigured.
22:40:38 <peter1138> That is a bug in the build system, I'm sure.
22:43:52 <_pruple> andythenorth: dutch socks?
22:48:25 *** Wolf01 has quit IRC (Quit: Once again the world is quick to bury me.)
22:48:32 <peter1138> Shall we argue on the exact shade to use? ;)
22:50:27 <_zephyris> There was logic to the shade selection... It's the same shading I use to closely mimic the original graphics temperate terrain slopes.
22:51:14 <Rubidium> peter1138: yes, I'd suggest U+1F60E
22:54:04 <talltyler> Peter: Any interest in re-reviewing #11435 now that I've fixed it? 🙂
22:55:55 <peter1138> There was the question of why switching to v2 makes the NewGRFs about 10% bigger, but... who cares ;)
22:56:25 <peter1138> Lots of small sprites I suppose.
23:06:26 <peter1138> Hmm, carbon saddle rails sounds breakable... little bits of plastic :o
23:31:01 <peter1138> Is it possible for current_order_time to be >= 2^31 ?
23:31:23 <peter1138> i.e. it will switch from a very large value to a negative value.
23:32:28 <peter1138> And if not, I wonder if it's okay to just change it from SLE_UINT32 to SLE_INT32, without a bump. Not sure on that one.
23:35:29 <peter1138> mmamammmmammamamaaamammma, just killed a light
23:40:35 <Rubidium> current_order_time is in ticks, right? So, that'd be about 79.5 thousand game years
23:40:53 *** HerzogDeXtEr has quit IRC (Read error: Connection reset by peer)
23:41:22 <_pruple> it's a very slow boat
23:41:40 <peter1138> There's a server that says it's been going for 82,422 years. That might be a lie.
23:42:21 <Rubidium> to be "correct" it should probably be the SLE_FILE_U32 | SL_VAR_I32
23:42:59 <_pruple> 1.3.3 will be 10 years old in 2 days!
23:45:00 <peter1138> Rubidium, which is what talltyler has done, but as a full-on savegame bump. But if we're doing a full bump for that should we also check the value is in range... Hmm.
23:45:43 <peter1138> I'm sure I'm definitely over thinking/over questioning this :p
23:47:30 <Rubidium> yes, kind of maybe... currently it doesn't prevent overflows
23:50:20 <Rubidium> and in the new one it doesn't check for overflows either, so it's equally "broken" in both cases
23:58:26 <talltyler> Don’t you have to do a savegame bump for that? I don’t know another way.
23:58:35 <talltyler> I am thoroughly unworried about it overflowing though
23:58:50 <talltyler> Which is why I originally did no saveload conversion
continue to next day ⏵
