IRC logs for #openttd on OFTC at 2024-12-27
⏴ go to previous day
02:38:01 *** Wormnest has quit IRC (Quit: Leaving)
03:23:00 *** gnu_jj_ has joined #openttd
03:26:06 *** gnu_jj has quit IRC (Ping timeout: 480 seconds)
03:29:58 *** godbed_ has joined #openttd
03:33:21 *** debdog has quit IRC (Ping timeout: 480 seconds)
03:33:26 *** D-HUND has quit IRC (Ping timeout: 480 seconds)
04:42:45 <DorpsGek> - Update: Translations from eints (by translators)
07:30:13 *** Webster has quit IRC (Ping timeout: 480 seconds)
07:35:51 *** XeryusTC has quit IRC (Ping timeout: 480 seconds)
07:40:38 *** tneo has quit IRC (Ping timeout: 480 seconds)
07:40:39 *** planetmaker has quit IRC (Ping timeout: 480 seconds)
07:41:36 *** Yexo has quit IRC (Ping timeout: 480 seconds)
07:41:36 *** Hazzard has quit IRC (Ping timeout: 480 seconds)
07:46:00 *** planetmaker has joined #openttd
07:46:00 *** ChanServ sets mode: +o planetmaker
07:47:07 *** Hazzard has joined #openttd
07:47:36 *** XeryusTC has joined #openttd
08:14:36 <andythenorth> so 'most popular' as a way to filter grfs then?
08:22:39 <truebrain> Website fails to publish, because we have a YAML entry: `version: 3.0`, to pin the Ruby version to use. However, as that is a float, it becomes `version: 3` and so it installs the latest from the 3 series, 3.4 .... sometimes I hate YAML
08:23:19 <truebrain> And no, Ruby 3.4 is not backwards compatible with Ruby 3.0; much like Python, they so not use semver
08:33:40 <Rubidium> truebrain: we're not really using semver either, so why should ruby?
08:34:13 <truebrain> Did I say they should? 🙂
08:38:47 <Rubidium> at least it's not such a big mess as Microsoft versioning (I think) ;)
08:45:52 <truebrain> owh, no, the publish ofc keeps failing, as it uses the main branch for its workflow
08:45:55 <truebrain> I was wondering why it failed
08:46:52 <truebrain> so we just do this, and hope that is fine
08:53:41 <truebrain> that was really confusing 😄
08:58:15 <truebrain> okay, that should bring everything back up-to-date for the website repo 🙂
09:02:29 <LordAro> well now i'm curious about what in ruby 3.4 isn't compatible
09:02:44 <truebrain> it was warning about that for ages
09:02:49 <truebrain> so it isn't a surprise 😛
09:05:19 <truebrain> I took no effort to check out the issue btw; I was mostly annoyed the pinning had failed us 🙂
10:25:01 <peter1138> andythenorth: Slop.
10:25:46 <merni> Is andy only asking for that because FIRS and Iron Horse would be high on that list? :P
10:30:23 <andythenorth> I've always been against it
10:30:54 <andythenorth> but pretty much every app store, TV streaming store, music store etc works on 'most popular'
10:30:58 <andythenorth> and the stock market 😛
10:31:21 <andythenorth> nobody wins any points for pointing out that it's self-reinforcing 😛
10:31:45 <andythenorth> then new players just go to reddit and get the list of most popular anyway
10:48:30 *** gavfish has joined #openttd
11:01:44 <florafex> they can just keep doing that forever. at least then sometimes people will come in and recommend other stuff instead
12:28:12 <xarick> who invented IsNeighborRoadTile in town_cmd.cpp?
12:28:23 <xarick> I wanna blame someone, kekeke, j/k
12:29:09 <xarick> Can't figure a way to make it performant and correct
12:30:53 <xarick> currently it is very performant but can at times go to the opposite side of the map
12:31:44 <xarick> or at least it asserts
12:32:05 <xarick> didn't really verify if it's really checking on a tile on the opposite border
12:35:56 <emperorjake> I was loading some old saves of mine and this one makes modern OpenTTD crash. It loads fine in version 0.5.3 though
12:39:17 <emperorjake> I was loading some old saves of mine and this one makes modern OpenTTD crash. It loads fine in version 0.5.3 though
12:40:16 <emperorjake> (reuploaded to make sure it was the correct one)
13:25:46 <_glx_> I get a different assert when loading the save
13:27:52 <peter1138> I fixed the assert I found, which is likely the one you found 🙂
13:28:35 <_glx_> guess you got path reservation assert too
13:28:43 <peter1138> Yeah, it's possible that their crash is caused by having NewGRFs configured, when there aren't any used by the game.
13:29:18 <peter1138> (Or at least, it's pre-NewGRF config saved in game)
13:41:01 <peter1138> The other assert is likely due to deleting a vehicle before the unit numbers are set up properly.
13:42:36 <peter1138> I guess the fix for that is to skip the ClrBit if used_bitmap is completely empty.
13:42:52 <peter1138> (Or fill the used_bitmap earlier)
13:45:25 <peter1138> Anyway, that one only happens because the NewGRF config is wrong.
13:49:32 <peter1138> AfterLoad gets more and more fragile.
13:50:08 <peter1138> Maybe it's time to think about slowing down saveload even more by storing map data in a more descriptive manner.
13:51:28 <michi_cc> Just make sure it is slower, uses more memory, and tanks compressibility, to make sure everybody is equally angered 😛
13:53:02 <peter1138> That's an idea. We can fill the unused parts with random data...
13:53:56 <peter1138> Main issue is that going forwards it becomes simpler, but you still need all the existing conversions, so actually you now have yet another thing to think about.
13:55:12 <michi_cc> And even then it would only help with the physical bit positions, but any kind of meaning change would still need conversion code.
13:56:23 <peter1138> Like changing to a more dynamic map array (locomotion-style).
13:57:04 <peter1138> Or whatever all the other "new map array" stuff does ;D
13:57:46 <michi_cc> Well, my new map stuff has a variying count of Tile's per TileIndex
13:58:38 <peter1138> I had a vague idea about "layers"
13:59:01 <michi_cc> But surprisingly enough, saveload code for all the parts I have done so far is surprisingly simple. If I ever get to the full Tile reorder, that would be one big break.
13:59:13 <peter1138> So you have a plain tile. On that you have a rail piece. On that you have a station piece. Above that you have a bridge piece, on that you have a signal piece...
14:00:02 <michi_cc> Well, the Tile structure I have in my mind would support layers. There's always an initial base ground tile with 0+ associated sub-tiles, and then you could have above and below layers, too.
14:00:06 <peter1138> Or a multi-owner road tile becomes a ground tile + road piece + tram piece + road stop piece.
14:00:21 *** reldred has joined #openttd
14:00:21 <reldred> <a:eyesshaking:833706919465058355>
14:00:33 <peter1138> By layers in mean layering "attributes".
14:00:47 <peter1138> Not necessarily different Z-layers, although that also fits in.
14:01:32 <reldred> Z layers has other challenges, but still interesting enough.
14:01:35 <peter1138> reldred: Sadly ideas don't mean code.
14:01:51 <michi_cc> Below-ground layers are a problem for GUI, but above ground is a lot simpler.
14:02:15 <reldred> Vertical Z level slicer scale.
14:02:16 <michi_cc> Well, I do have multiply branches of code in multiple stages of outdated-ness :p
14:04:02 <peter1138> Hmm, maybe I need to get a more powered USB HUB.
14:04:42 <peter1138> One of my USB-powered synths was misbehaving, but I did have multiple synths in the same hub...
14:06:32 <reldred> I do like that all my 3D printers are networked, running long USB cables or ferrying over sd cards is a bit horrible.
14:08:33 <peter1138> 16-port 90W? That might cope...
14:09:23 *** urdh has quit IRC (Quit: Boom!)
14:14:27 <_glx_> ok found an easy "please don't yell at us gcc 14"
14:26:11 <peter1138> Is the FileHandle one not fixed by `f = nullptr;` on line 179?
14:27:08 <peter1138> Although... should not be necessary.
14:28:05 <_glx_> ah didn't try that, at least for pools having a default initialisation of index doesn't work
14:29:23 <peter1138> Bit odd, that one is quite simple.
14:30:55 <_glx_> for pools default init overwrites index from placement new
14:31:51 <_glx_> of default init of f still warns
14:41:23 <peter1138> Sorry I meant the FileHandle one is quite simple.
14:41:42 <peter1138> The pools one does weird stuff with not using the standard allocator, and then in some cases the memory is reused.
14:42:42 <peter1138> What's the correct naming convention for parameters that end up shadowing member variables?
14:43:05 <_glx_> ```In destructor 'std::unique_ptr<_Tp, _Dp>::~unique_ptr() [with _Tp = _iobuf; _Dp = FileHandle::FileDeleter]',
14:43:05 <_glx_> inlined from 'FileHandle::~FileHandle()' at D:/developpement/GitHub/glx22/OpenTTD/src/fileio_type.h:158:7,
14:43:05 <_glx_> inlined from 'constexpr void std::_Optional_payload_base<_Tp>::_M_destroy() [with _Tp = FileHandle]' at H:/msys64/mingw64/include/c++/14.2.0/optional:283:35,
14:43:05 <_glx_> inlined from 'constexpr void std::_Optional_payload_base<_Tp>::_M_reset() [with _Tp = FileHandle]' at H:/msys64/mingw64/include/c++/14.2.0/optional:314:14,
14:43:05 <_glx_> inlined from 'constexpr void std::_Optional_payload_base<_Tp>::_M_reset() [with _Tp = FileHandle]' at H:/msys64/mingw64/include/c++/14.2.0/optional:311:7,
14:43:07 <_glx_> inlined from 'constexpr std::_Optional_payload<_Tp, false, _Copy, _Move>::~_Optional_payload() [with _Tp = FileHandle; bool _Copy = false; bool _Move = false]' at H:/msys64/mingw64/include/c++/14.2.0/optional:437:65,
14:43:07 <_glx_> inlined from 'constexpr std::_Optional_base<FileHandle, false, false>::~_Optional_base()' at H:/msys64/mingw64/include/c++/14.2.0/optional:508:12,
14:43:09 <_glx_> inlined from 'constexpr std::optional<FileHandle>::~optional()' at H:/msys64/mingw64/include/c++/14.2.0/optional:703:11,
14:43:09 <_glx_> inlined from 'virtual FileWriter::~FileWriter()' at D:/developpement/GitHub/glx22/OpenTTD/src/saveload/saveload.cpp:2295:2:
14:43:11 <_glx_> H:/msys64/mingw64/include/c++/14.2.0/bits/unique_ptr.h:397:19: warning: '((_iobuf**)this)[3]' may be used uninitialized [-Wmaybe-uninitialized]
14:43:11 <_glx_> 397 | if (__ptr != nullptr)
14:43:13 <_glx_> ``` that's with `std::unique_ptr<FILE, FileDeleter> f = nullptr;`
14:43:27 <peter1138> `FileHandle(FILE *f) : f(f) {}` works fine but -Wshadow does not want it.
14:43:53 <peter1138> Oh, so even if it is explicitly initialised (again) it still says it's may not be.
14:44:06 <_glx_> with have this constructor (in private)
14:44:24 <_glx_> it even asserts f is not null
14:45:06 <peter1138> Yeah, but that assert doesn't affect initialised/uninitialised.
14:45:54 <_glx_> probably doesn't like the indirect construction via static FileHandle::Open()
14:46:47 <_glx_> so it only sees deletion but never construction
14:49:36 <peter1138> std::optional<FileHandle> FileHandle::Open(const std::string &filename, const std::string &mode)
14:49:36 <peter1138> #if defined(_WIN32)
14:49:36 <peter1138> /* Windows also requires mode to be wchar_t. */
14:49:38 <peter1138> auto f = _wfopen(OTTD2FS(filename).c_str(), OTTD2FS(mode).c_str());
14:49:40 <peter1138> auto f = fopen(filename.c_str(), mode.c_str());
14:49:40 <peter1138> #endif /* _WIN32 */
14:49:42 <peter1138> std::optional<FileHandle> fh = std::nullopt;
14:49:42 <peter1138> if (f != nullptr) fh.emplace<FileHandle>(f);
14:49:46 <peter1138> I wonder if that does anything different.
14:50:08 <peter1138> Might not be allowed as the constructor is private.
16:16:02 <xarick> I tried to do smart code
16:23:33 *** Wormnest has joined #openttd
16:27:10 *** Flygon has quit IRC (Quit: A toaster's basically a soldering iron designed to toast bread)
16:35:42 *** Wormnest has quit IRC (Quit: Leaving)
16:57:02 <xarick> [SF#1099197] what is this?
17:27:14 <xarick> i remember sourceforge
17:33:21 *** blustik has joined #openttd
17:33:21 <blustik> Hello, I am going to try and port OpenTTD to iOS tonight. I don’t think it will be too hard. I’ll share my progress here.
17:35:01 <merni> Please don't do what the so called "port" that used to be on the apple app store did
17:35:35 <blustik> merni: I won’t. I like this game too much.
17:36:01 <merni> also aren't there some rules around GPL licenced stuff on there
17:37:11 <blustik> merni: Kinda. It probably won’t be on the AppStore. As of right now I’m thinking of having it be sideloadable and having there be a TestFlight.
17:37:31 <blustik> There are some gpl apps on the store rn such as Delta emulator and Folium.
17:38:12 <blustik> And it would be open source ofc
17:38:46 <blustik> merni: Thanks. Sdl can be weird
17:38:49 <merni> And just remember, you will have to maintain and update it forevermore :P
17:39:46 <blustik> merni: If my plan of attack works it will be easily upgradable.
17:40:02 <merni> lol I was only kidding anyway
17:40:36 <blustik> merni: Maybe I can even build in an updater
17:53:49 <andythenorth> how different is an iOS build from a macOS build?
17:55:00 <merni> Well you probably need all sorts of interface changes like with the android version to make it more playable on smaller screens controlled by fat fingers instead of a curso
17:56:06 <merni> Some way for all the functionality only available with Ctrl to be used
17:57:53 <_jgr_> Apple go out of their way to make iOS sideloading awkward and non-viable for normal users
17:59:26 <_jgr_> But it could still be an interesting technical exercise if you're into iOS development
17:59:44 <_jgr_> Certainly not a one-night job though...
18:10:37 <LordAro> "I don't think it will be too hard"
18:13:57 <LordAro> i would like to see a native android/ios version one day
18:14:14 <LordAro> but that requires lots of interface overhauls first
18:14:27 <LordAro> slightly fewer, now that peter has got scaling working "properly"
18:17:36 <peter1138> Whoever does it needs to separate "builds and runs" from "changes that make it nicer to use"
18:20:28 <LordAro> peter1138: when did you acquire this taste for luxuries?
18:35:05 <peter1138> Hmm, overloaded functions that no longer differ when you change an underlying type :/
18:35:11 <peter1138> And StrongType is a bit of a beast.
18:46:45 *** tokai|noir has joined #openttd
18:46:45 *** ChanServ sets mode: +v tokai|noir
18:53:36 *** tokai has quit IRC (Ping timeout: 480 seconds)
19:35:19 <peter1138> What happens if I make this a StrongType...
19:35:29 <peter1138> Ah yes... all the places that the type is ignored mess up :S
19:50:09 <johnfranklin[d]> > Travel guide for some city
19:50:09 <johnfranklin[d]> > Top attraction: “just 20 min drive from this city”
19:58:44 <xarick> and it will return TILE_INVALID instead of asserting
20:00:15 <xarick> How do I properly document that?
20:09:12 *** SigHunter has joined #openttd
20:17:36 <peter1138> Hmm, trying to use StrongType as a pool item index is not going well :p
20:28:45 <kuhnovic> Google is your friend
20:37:43 <andythenorth> GPT is your special friend
20:38:02 <xarick> it builds, so it's probably fine
20:38:35 <xarick> trying to copy rubidium's code style
20:50:48 <xarick> ```for (Direction dir : SetBitIterator<Direction>(_flood_from_dirs[slope_here])) {
20:50:48 <xarick> TileIndex dest = tile + dir;```
20:51:10 <xarick> i can add a Direction to a TileIndex with "+"
20:51:18 <xarick> and it calls the right function
20:52:32 <xarick> not sure why it doesn't work for TileOffset "non-C"
21:06:08 <blustik> LordAro: My goal is to get it to display tonight.
21:06:45 <blustik> andythenorth: It’s very different process.
22:02:08 *** keikoz has quit IRC (Ping timeout: 480 seconds)
22:26:55 <xarick> SetupFarmFieldFence is complicated
22:27:01 <xarick> my brain is not workin
22:28:57 <xarick> `uint8_t or_ = type;` what a weird variable name
22:31:36 <xarick> tile = Map::WrapToMap(tile); what does this do?
22:36:46 *** keikoz has quit IRC (Ping timeout: 480 seconds)
22:44:13 <xarick> bah, im getting crashes
22:51:30 <_zephyris> peter1138: This. There's a lot of scope to make the UI better for touch, from iPhones to touchscreen laptops...
22:54:50 <talltyler> Yes, and those are not specific to an iOS port. It would be nice to have some of that in regular OpenTTD, so it would be upstream for the Android port too
22:59:32 <xarick> something's broken, and i suspect it's me
23:02:22 <xarick> master seems fine, it's me
23:09:33 <peter1138> Hmm, this code is quite horribly complex :S
23:11:42 <xarick> directions can't be passed as references, because some code somewhere changes the value
23:12:26 <xarick> and I dont feel like looking for it
23:13:06 <truebrain> dynamic GUI? lua to config the GUI on runtime? 😛
23:13:16 <truebrain> I will see myself out now 🙂
23:16:19 <andythenorth> macromedia flash?
23:45:07 <peter1138> Hmm, what is this 24V AC adapter for...
23:45:15 <peter1138> I'm thinking Mikrotik router.
23:46:36 <peter1138> I should probably keep it away from all the 9V centre-negative adapters...
23:48:51 <_glx_> and put a big sticker on the device side plug
continue to next day ⏵
