IRC logs for #openttd on OFTC at 2024-03-10
โด go to previous day
00:06:44 *** aperezdc has joined #openttd
00:11:21 *** lapingvino has joined #openttd
00:11:21 <lapingvino> who is doing the font work? I speak 11 languages and have a bit of Fontforge experience, maybe I can help a bit to improve non-English support/how accents look etc. Loving the inclusion in version 14, but it feels a bit off so far if I can be fully honest xD
00:13:10 <lapingvino> that said, I'm not really sure with the constraints of the game if/what kind of improvements can be made xD e.g. my immediate reaction is to the interaction between uppercase letters and diacritics... and you will need to make some compromises there however you go about it...
01:33:21 <peter1138> Well that is a deliberate design choice anyway due to the constraints.
03:42:01 *** D-HUND has quit IRC (Ping timeout: 480 seconds)
03:47:06 *** gnu_jj_ has quit IRC (Ping timeout: 480 seconds)
04:30:43 *** HerzogDeXtEr has quit IRC (Read error: Connection reset by peer)
04:34:49 *** Leopold__ has joined #openttd
04:39:32 *** Leopold__ has quit IRC (Remote host closed the connection)
04:39:40 *** Leopold__ has joined #openttd
04:40:44 <DorpsGek> - Update: Translations from eints (by translators)
04:41:45 *** Leopold_ has quit IRC (Ping timeout: 480 seconds)
05:12:04 *** Leopold__ has quit IRC (Remote host closed the connection)
05:12:10 *** Leopold has joined #openttd
06:31:40 <kuhnovic> JGRennisonviaGitHub: Hmm, maybe #12117 wasn't such a good idea after all. The change itself makes sense, but code using YAPF has been made with the assumption that such a case never happens...
07:57:54 <truebrain> Good thing it is not marked for backport ๐
08:25:01 *** Leopold__ has joined #openttd
08:27:46 *** Leopold has quit IRC (Remote host closed the connection)
08:33:13 <truebrain> curious if the auto-merge kicks in if I change what is required ๐
08:34:31 <truebrain> I made it so no older PRs need rebasing; both variants are accepted
08:45:14 <kuhnovic> truebrain: Yeah I'm quite happy about that hehe
08:45:42 <truebrain> gives you a bit of time to figure out what is the next best step ๐
08:48:29 <truebrain> never actually looked at how slow CodeQL is in compiling, but boy, it is slow ๐
08:49:27 <_zephyris> Me! There is scope for improvements, but there are lots constraints because of the line height... Thr git is the place for bug reports, design proposals, etc.
08:49:44 <_zephyris> lapingvino: Oops, lost the reply!
08:49:47 <kuhnovic> To revert or not to revert. That is the question.
08:50:03 <truebrain> indeed; might be good to look into why it actually doesn't work as you expect
08:50:08 <truebrain> just to have a feel for it
08:50:28 <lapingvino> _zephyris: thanks for the ping!
08:50:46 <lapingvino> yeah I know... it's a complicated thing to do right xD
08:51:02 <lapingvino> which software do you use yourself? ๐
08:51:54 <kuhnovic> Yeah I need to take a closer look. I would like to keep my yapf changes if possible, because they make for a more correct A* implementation. TBC!
08:52:34 <truebrain> yeah, having a more common implementation helps the next-you ๐
08:53:07 <truebrain> okay, there is a CodeQL for macos .. so that at least is something .. let's see if it is any faster ๐
08:53:18 <_zephyris> lapingvino: Fontforge, glyph design in inkscape
08:53:36 <lapingvino> cool, so we are on the same toolset either way ๐
08:57:32 <lapingvino> part of it is just that with my autistic detail view things kinda look off xD but for a first release this is really good ๐
09:03:33 <_zephyris> That's great. The best suggestions come with an svg attached ๐
09:07:43 <_zephyris> Oh, and make sure you look at the dev version on github, there's lots of recent changes to make combining diacritics work
09:08:34 <truebrain> lolz, I do not think MacOS will be faster for CodeQL .. in fact, pretty much the reverse ๐
09:18:57 <peter1138> Yes, you better have one ready.
09:19:07 <merni> I don't drink it anyway
09:19:17 <merni> Well, maybe like five times a year
09:21:13 *** gelignite has joined #openttd
09:42:27 <andythenorth> I have run out of coffee
09:44:36 <andythenorth> `libc++abi: terminating with uncaught exception of type NSException
09:44:36 <andythenorth> Something went seriously wrong when creating the crash log. Aborting.`
09:45:06 <andythenorth> `2024-03-10 09:44:17.826 openttd[11343:92009] *** Terminating app due to uncaught exception 'NSInternalInconsistencyException', reason: 'NSWindow drag regions should only be invalidated on the Main Thread!'`
09:45:25 <truebrain> if only you created a bug report about that .. owh wait, you already did!
09:45:46 <nanapipirara> The transmitter tower's ground sprite is always grassy. Even if it's in the middel of the desert or snow.
09:46:17 <andythenorth> must have been my other personality
09:46:22 <nanapipirara> (It looks especially ugly in BonkyGFX, but it's also a bit weird with normal graphics)
09:46:41 <andythenorth> anyway, looks like I crashed something in YAPF
09:50:15 <_jgr_> It's the same issue I opened last night, #12250
09:50:20 <andythenorth> oh yes, it repros ๐
09:50:34 <andythenorth> same crash, same point in the savegame
09:51:52 <michi_cc> kuhnovic: And that is why we make people dev. So they can clean up by themselves ๐
10:19:41 <truebrain> lol, MacOS doesn't want to run x64 binaries for me anymore on the CI .. what did I do wrong ....
10:21:01 <truebrain> `clang: error: invalid arch name '-arch x86_x64'`
10:21:04 <truebrain> seems I just can't type
10:22:20 *** Leopold__ has quit IRC (Remote host closed the connection)
10:28:48 <truebrain> that should almost double the amount of PRs we can process in an hour
10:30:14 *** HerzogDeXtEr has joined #openttd
10:31:43 *** Leopold_ has joined #openttd
10:34:41 <truebrain> grr @ Rubidium .. #12252 just disproved one of my arguments ๐
10:36:47 <kuhnovic> michi_cc: I see. You guys tricked me into becoming one ๐
10:38:54 <peter1138> For that PF issue, I would try to find a proper clean solution instead of reverting. Revert would be the solution if it was needed for the release of 14, but I don't think it is.
10:41:47 <kuhnovic> Yes that's what I want as well. It's not in 14, so no panic revert is needed.
10:45:15 <peter1138> Do we care about bugs in MSVC 2019 though?
10:45:19 <truebrain> It is very unclear to me why we actually still run MSVC 2019 ๐
10:46:44 * andythenorth figuring out how to reverse an articulated consist in nml :P
10:46:48 <michi_cc> I vote to just get rid of it.
10:47:04 <andythenorth> (not going to change vehicle lengths to suit....yet)
10:48:44 <andythenorth> my comp sci. dissertation will be about breadth vs depth of nml action 3 -> action 2 -> action 1 chains in the Iron Horse mod for OpenTTD
10:49:08 <andythenorth> exponential vs linear growth
10:50:46 <truebrain> let the voting commense ๐
10:52:38 <peter1138> Hmm, `std::optional<std::vector<>>` and `x.has_value()` or `std::vector<>` and `!x.empty()`?
10:53:02 <truebrain> do you want to know if the vector exists, or if it is empty?
10:54:02 <truebrain> why do I bother writing words in PR descriptions ๐
10:57:49 <truebrain> meh; GitHub workflow failures don't mention for what PR it failed
11:03:37 <peter1138> Yeah, is an empty string invalid, or just an empty string. Similar for this vector.
11:03:56 <truebrain> without context, we can't answer the question for you ๐
11:04:05 <truebrain> true / false / undefined or true / false ๐
11:04:24 <truebrain> sometimes you do want to know whether the string is empty, or just not set ๐
11:04:34 <peter1138> const char *s = "";
11:04:47 <peter1138> s is not nullptr, but it is empty. It's a valid, (but short) string.
11:05:21 <peter1138> std::string, otoh, cannot differentiate that.
11:05:22 <michi_cc> Is there a need to do different things for undefined and empty? If no, I'd prefer just using the vector (just by personal preference).
11:09:18 <peter1138> Argh, I wish pmidi would take a named MIDI port.
11:09:47 <peter1138> Alsa allocates MIDI port numbers first-come first-served.
11:10:01 <peter1138> So they change depending on the order of USB evaluation.
11:13:29 <truebrain> changed some permissions on DorpsGek, but it seems it still works, pfew ๐
11:24:39 <xarick> but no fix for scripts
11:25:36 <xarick> tell me how much you hate AIs without telling me how much you hate AIs
11:28:11 <peter1138> Maybe I should expose ByteReader ... move it out of newgrf.cpp
11:28:42 <truebrain> maybe I should lunch. Hmm.
11:37:53 <LordAro> peter1138: i'm curious where you would need the distinction between no-vector and empty-vector
11:38:06 <LordAro> peter1138: also rain today :(
11:50:12 <xarick> dang it, there's always 600 file to compile every day
11:53:32 <peter1138> LordAro, "data couldn't be read" vs "data was read but it's empty"
11:56:09 <peter1138> truebrain: Might be breakfast time.
12:01:10 <xarick> ::Vehicle::Get(vehicle_id)->max_age.base();, uhm... there's no direct conversion?
12:02:26 <xarick> GetAgeLeft max-age - age
12:03:14 <xarick> but "age" could be calendar age or economy age
12:07:01 <xarick> dear TimeLord, I need a "max_economy_age"
12:07:52 <xarick> or some equivalency that could make GetAgeLeft work
12:09:44 <_jgr_> xarick: max_age, age, and therefore the result of GetAgeLeft are in calendar time, therefore no conversions are needed
12:10:05 <_jgr_> You can look in struct Vehicle, or other equivalent structs to find these things out
12:12:44 <xarick> there's AITimeMode to set what kind of time the AI uses
12:13:06 <xarick> they should work for these functions
12:13:28 <xarick> i mean, get different times depending on the mode choice
12:14:03 <xarick> I have a use case for both modes
12:14:58 <xarick> i for example want to know how old my vehicles have been running on on a route, for this one I prefer economy mode
12:15:17 <_jgr_> The result of GetAgeLeft is a relative value, not a date. AITimeMode only changes the return values from AIDate
12:18:47 <LordAro> 18.8G resilvered, 0.49% done, 1 days 03:59:35 to go
12:21:38 <xarick> economy_age missing for newgrf_vehicle, i thnk
12:23:17 <xarick> oh, newgrf_engine i guess
12:29:36 <xarick> now all I need is a v->economy_max_age ^_^
12:33:03 <truebrain> let's see if it actually works ... announcing nightly failures, that is ๐
12:49:36 <truebrain> 14.0 will tell us how much memory is actually in that computer ๐
12:52:17 <truebrain> I like that Trivial is with a capital T
12:52:21 <truebrain> sounds important ๐
12:53:15 <kuhnovic> Trivial cases tend to be quite important ๐
12:54:08 <kuhnovic> But since I've now had issues with both the ship and rail PF's, it's probably a good idea to take a look at the RV / Air implementations too ๐...
12:54:44 *** DorpsGek has joined #openttd
12:54:44 *** ChanServ sets mode: +o DorpsGek
12:54:44 <truebrain> oof, so many self-approving people wanting to become translators these days
13:00:52 <truebrain> _glx_: do you have an idea why with #12257, I can't seem to load the symbols from our symbol server with MSVC? Is that a "me" problem?
13:02:04 <_glx_> it's a 13.4 build, the symbols are not in the server
13:02:20 <truebrain> I forgot we added it that recently
13:02:39 <_glx_> I have the required stuff locally, will decode
13:02:41 <truebrain> the executable ID should have told me; it is older than the first entry ๐
13:02:58 <truebrain> I doubt there is anything useful in that dmp, but was curious if we could see the map-size
13:04:29 <truebrain> okay, manually downloading pdb allowed me to decode it indeed ๐
13:04:35 <truebrain> owh, the blitter already runs out of memory, lolz
13:05:12 <_glx_> yeah just looked at crash log, it doesn't even seem to go past loading intro game
13:05:31 <truebrain> so now I am really curious to how much GB of RAM that "not so old" machine has ๐
13:05:32 <_glx_> empty gamelog, date is 0
13:10:20 <truebrain> a 1920x1009 screen, for which the animation buffer is being allocated, which fails. Buffer is just 4MB, so that isn't the issue ofc, but okay ๐
13:11:37 <truebrain> Rubidium: no, we are not also going to remove MSVC 2022 support ๐ ๐ (giggling at the next build failure you trigger)
13:12:41 <Rubidium> question #1 would be: is that special casing for MSVC needed/necessary?
13:13:12 <truebrain> solution #1: replace the `::` with `.`? ๐
13:13:50 <truebrain> both the MSVC and the non-MSVC are weird lines of code to me
13:13:52 <Rubidium> that would probably solve it, yet... though the question kinda remains. Why this special magic?
13:14:11 <truebrain> why not just assert? Or FatalBlabla?
13:14:23 <truebrain> or `Debug(misc, 0, ..`
13:14:55 <truebrain> maybe in the old days, this happened often enough that it shouldn't crash the game or something
13:15:03 <truebrain> but these days, I would say, let it crash and burn ๐
13:15:55 <truebrain> owh, it is even unused in non-debug
13:16:01 <truebrain> okay, I give up on understanding these lines ๐
13:17:39 <_glx_> if it was not debug only I could understand, as in non debug there's no console window by default
13:18:29 <_glx_> but it's debug only so it's easy to see debug lines in the background
13:19:14 <truebrain> and an `assert(x >= MAP_X)` would do the same .. historical reasons, I am sure
13:22:56 <_glx_> not sure if PR description would have been filled properly, if we had it ๐
13:23:11 <truebrain> he couldn't even do commit messages, so no
13:24:01 <truebrain> okay, so a PR to speed up CodeQL by a bit, and one to speed up PRs in general by a lot. Today is a good day for our CI improvements ๐
13:24:49 <peter1138> Change for change sake?
13:25:04 <truebrain> aren't all changes like that?
13:27:50 <Rubidium> hmm... went with the assert, but that makes the std::source_location information redundant... I should think before doing sometimes...
13:30:17 <truebrain> Rubidium: so even less code will remain? \o/ ๐
13:31:00 <truebrain> I now wonder whether we should add unit-tests for this, to offset the "lines removed" ๐
13:31:36 <truebrain> can unit-tests check if an assert triggers, I now wonder? ๐
13:31:45 <truebrain> okay, I will stop wondering ๐
13:32:21 <Rubidium> well, you could consider this the mother of all tests... instead of testing a function, it tests all callers of a function
13:34:58 <peter1138> RIP debug builds ๐
13:39:34 <Rubidium> I guess I'll have to approach those changes in a different order to make it amenable for merging
13:47:02 <peter1138> TBH I reckon that #8907 is fixed by the new fonts.
13:47:53 <peter1138> The original issue is actually caused by OpenGFX, which does definitelky deviate with the small font. It is not so much of an issue with the original TTD baseset.
13:49:08 <_zephyris> Yeah, in that sense it's not a bug
13:49:39 <_zephyris> The issue is the descenders
13:51:40 <_zephyris> Cyrillic capitals break too, full height with descender
13:52:20 <_zephyris> Cedillas and ogonek are problematic too
13:52:44 <peter1138> In "theory" we could have two versions of the fonts, one with TTD-geometry, and another with relaxed geometry that fits ascenders and descenders.
13:52:57 <peter1138> But that's a whole extra lot of work.
13:54:00 <_zephyris> Yeah. IMO the "real fix" is adding 1px descender to the metrics - 5px ascender, 1px descender, 6px ascent.
13:55:07 <_zephyris> Easy enough for TTF - change default font size to 7px, and leave the font metrics problem to me!
13:57:03 <_zephyris> Oh, I see what you mean, maintaining parallel versions is a faff.
14:01:37 <truebrain> I forgot how weirdly TileIndexDiff is encoded .. I just ... ๐
14:13:47 <truebrain> why drag me into this? I was about to approve the PR ๐ฆ
14:16:56 <truebrain> and you now better review + approve this PR LordAro ๐
14:28:41 <xarick> there's even a Frozen time mode ๐
14:29:43 <xarick> what do I return with GetAge in this case?
14:30:15 <peter1138> It still has an age.
14:32:43 <xarick> how do vehicles age when frozen ๐ 3 time modes
14:33:54 <_zephyris> Date is frozen, not time
14:34:58 <xarick> _settings_game.economy.minutes_per_calendar_year becomes 0
14:36:56 <LordAro> what problem are you trying to solve?
14:37:27 <LordAro> vehicle ages are, presumably, always 0
14:37:53 <andythenorth> "too many visual effects" ๐
14:38:17 <xarick> I'm trying to make scripts, especially those before 14, to use economy time for getage, getageleft, and friends
14:38:56 <xarick> and then those in 14 to have 2 different (or 3 with frozen) return values
14:39:09 <xarick> depending on AITimeMode()
14:39:27 <xarick> but conversion is difficult
14:41:38 <xarick> I don't think it's even correct to assume the old AIs want EconomyDate all the time for these functions
14:42:52 <xarick> there's currently a mix usage of AIDate with AIVehicle.GetAge, this results in broken behaviour
15:10:52 <xarick> how to convert intro date to ... something expectable, I don't even know
15:11:28 <xarick> ScriptEngine::GetDesignDate
15:13:56 <xarick> wallclock mode starts as 0001-01-01
15:14:14 <xarick> if an engine design date is before that... how the heck do I convert
15:44:39 <rau117> idk, seems like bug to me
15:49:59 <xarick> GetCurrentDate being 760...
15:52:18 <rau117> rau117: I donโt know whether to post this as a suggestion or as a bug.
15:52:18 <rau117> Even the *beloved path signals* menu looks completely wrong โ 80% useless "convert signalโ button is way too wide than the actual pbs buttons, needless to say about unfortunate block-signalsโฆ
15:53:03 <merni> The first one certainly looks like a bug to me
15:54:53 <peter1138> Not actually a bug, but perhaps less than ideal layout.
16:05:54 <peter1138> If you use the standard font at the standard size it looks fine.
16:06:32 <peter1138> Oh, and the standard signals. Yeah, your signals are very narrow.
16:07:47 <locosage> Buttons should probably be capped to the min size of standard signals
16:08:05 <rau117> peter1138: Yes, with standard signals everything *looks* pretty nice (still, general inconvenience of thin buttons is here)
16:08:20 <locosage> Get way too thin otherwise
16:08:34 <rau117> however, there may be... such a situation
16:10:22 <_glx_> yeti semaphore are so cute ๐
16:10:52 <peter1138> Okay, let's download 182MB of badly coded NewGRF...
16:11:41 <_glx_> clearly looks like grf is "lying" about sprite sizes
16:11:53 <peter1138> Yeti doesn't give me those signals. Hmm.
16:12:21 <peter1138> Oh I downloaded "Yeti Extended..." oops.
16:13:52 <rau117> โvery narrowโ 8bpp signals from PURR
16:13:52 <rau117> โvery wideโ 32bpp from NUTS
16:14:02 <locosage> By "lying" you mean not cropping them to the size?
16:15:35 <locosage> Though signals are probably not the case in some places grf is forced to disable crop and iirc crop is a global argument in nml
16:16:05 <rau117> okey, a more โnormalโ set of signals that also gives a similar effect โ Dutch signals
16:24:53 <_glx_> peter1138: seems to be NUTS actually
16:25:39 *** Wormnest has joined #openttd
16:41:17 <xarick> otherwise... many scripts logic will fall apart when Wallclock mode is used
16:42:10 <xarick> impossible to deduce what the authors intend their behaviour to be
16:49:22 <xarick> I actually wanted to test some AIs with longer days, avoiding new engines being introduced so quickly, but alas... it's not working
16:54:37 <rau117> peter1138: Yeah, cool!
16:54:37 <rau117> The separator performs its main function ofโฆ separation, and the wide buttons are more convenient to aim.
17:11:21 <peter1138> Giant buttons because the two on the right no longer fill.
17:12:22 <talltyler> If any buttons are giant, those work ๐
17:32:19 <merni> peter1138: Can't that window be only as wide as necessary?
17:45:50 <talltyler> The title text determines its width
17:49:08 <peter1138> So basically 1) It's too narrow (current master), and 2) It's too wide (with my changes). Gotcha.
17:51:13 <peter1138> peter1138: I assume Merni was refering to this one.
17:51:40 <peter1138> Oh, no, I missed the quote part.
17:51:52 <peter1138> Yeah, the width is determined by the caption at this point.
17:52:05 <peter1138> "Signals" might be enough.
19:03:12 *** Flygon has quit IRC (Quit: A toaster's basically a soldering iron designed to toast bread)
19:10:30 <talltyler> Such announcement spam
19:10:47 <talltyler> Up to four entries, though!
19:12:45 <peter1138> Geoff Marshall posted a video so nothing can be done right now.
19:14:45 <truebrain> __karma: hard to say; can be one of those tickets that takes 2 minutes or 2 months ๐ Would be a case of tracing down where the window is build, and tracing back where it is called
19:17:05 <talltyler> Currently, the `Default` button reads from the .ini file, where only one value is possible. It needs to set a different value based on the service interval units. I suspect one approach would be to add a default-value callback, like frosch added for title and help strings in https://github.com/OpenTTD/OpenTTD/pull/11906
19:17:38 <truebrain> not sure that special casing a single setting is a good thing, tbh
19:17:51 <truebrain> having a single setting having multiple units depending on something else ... that already is very icky
19:18:16 <truebrain> can't we just pick a unit, and remove the rest? ๐
19:21:50 <truebrain> talltyler: given there is already `val_cb`, I agree that having a default callback might just as well work
19:21:59 <truebrain> still a very odd settings in the bunch of settings that we ahve ๐
19:22:20 <peter1138> I did wonder if we should have separate settings depending on the mode.
19:23:27 <talltyler> Aw, I missed the total destruction of the game ๐
19:23:32 <truebrain> my issues with these kind of settings ... if we have difficulty programming it, just imagine how difficult it is for the user to understand ๐
19:23:42 <talltyler> Oh yes, it's a hot mess
19:24:06 <peter1138> Bonnie Tyler's Total Destruction of the Game?
19:24:38 <talltyler> I wish I still could still pin posts ๐
19:25:40 <peter1138> Ooof, there's a passive-aggressive pin from me. Shameful :/
19:26:31 <talltyler> I no longer have pin powers ๐
19:26:45 <truebrain> sad; I wonder if we just shouldn't have pin powers in this channel .. would make sense ๐
19:27:23 <talltyler> I will ask in dev chat so it doesn't get buried here
19:28:30 *** matusguy_ has joined #openttd
19:29:03 *** matusguy_ is now known as matusguy-station
19:32:16 <truebrain> You have a patch for it? ๐
19:33:07 <peter1138> But I'd imagine it would work something like a virtual depot that gets moved from one location to another.
19:33:24 <talltyler> Infinite capacity ferry? I love it.
19:33:30 <truebrain> 1 bus fits on a huge container ship ๐
19:34:01 <peter1138> Doesn't need to be infinite, but doesn't not need to be either.
19:34:30 <peter1138> Eurostar carrying lorries under a sea tunnel...
19:34:35 <talltyler> If youโre implementing mobile depots, I guess you could allow any combination of vehicles
19:34:43 <truebrain> just imagine the complexity of getting the pathfinder code right here ๐
19:34:44 <peter1138> But yeah. Quite difficult.
19:34:59 <talltyler> Trains on planes, planes on boatsโฆ
19:35:03 <truebrain> but also, perspective really is a problem ๐
19:35:34 <talltyler> Can you put a ferry onto another vehicle and nest them? Like a boat carrying a train carrying a truck?
19:35:46 <truebrain> carrying a plane? ๐
19:36:37 <talltyler> Really one conceptual problem is how the child vehicle enters the parent. It just enters a station tile at the shared station and despawns?
19:37:01 <talltyler> Oh, I guess shared multi-tile depots might work too
19:37:06 <peter1138> I would say "hidden" rather than "despawn".
19:37:16 <truebrain> Or you get "ports", and also build shared infrastructure while you are at it
19:38:28 <talltyler> If weโre doing shared infrastructure between modes, a generic approach that would allow moveable bridges as a subclass would be nice
19:38:40 <truebrain> moveable bridges? wth?
19:38:41 <talltyler> Since we are in dreamland here ๐
19:38:50 <truebrain> what is next, movable tunnels?
19:38:52 <peter1138> I'm not sure where that comes in ๐
19:38:56 <matusguy-station> yea i was confused at movable bridges too
19:39:43 <peter1138> What's next, Howl's Moving Castle?
19:39:47 <talltyler> I was thinking that shared infrastructure requires a new category of things
19:40:06 <talltyler> But we do it with stations so maybe not
19:40:14 <truebrain> shadowsword: anyway, to answer a bit more concrete: this would touch pathfinders, vehicle movement code, some solution for a vehicle to follow another vehicle (like "depots" as peter1138 describes it), not to mention the perspective issues (graphical), and "how do orders work" (from a functional perspective) .. this would be a huge project, with many "but but but but" questions ๐
19:40:32 <matusguy-station> what's next? movable trucks? Oh wait.
19:41:02 <talltyler> Moveable bridges are probably an order of magnitude easier than vehicle ferries, tbh
19:41:18 <truebrain> I still have no clue what you actually mean with "moveable bridges"
19:41:23 <talltyler> So only 15 on a scale of 1-10 ๐
19:42:36 <peter1138> So completely unrelated.
19:42:37 <truebrain> I was more thinking about
19:42:51 <truebrain> as that, in context, makes more sense ๐
19:43:02 <truebrain> ferries ... these things ... ๐
19:43:23 <truebrain> anyway, for your moveable bridges, you first need ship-height to be a thing
19:43:44 <truebrain> "Can't go into this port, as the bridge is too low"
19:43:50 <truebrain> owh, then we also needs flexible water-height
19:44:03 <truebrain> now I am in dreamland ๐
19:46:26 <Eddi|zuHause> ships enter and exit ports depending on tide flow?
19:46:52 <Rubidium> then you implement a swing bridge and... a few seconds after opening the PR they want turntables
19:47:22 <Eddi|zuHause> you can do that, with objects that have state machines *cough* :p
19:50:18 <truebrain> do we need to call someone?
19:51:31 <peter1138> But objects can't transport anything.
19:51:48 <andythenorth> truebrain: it's ok, I can assert for myself
19:51:51 <andythenorth> but thanks for checking
19:52:01 <xarick> One error string for all 5 unbunch errors?
19:52:05 <peter1138> The original purpose of "objects" was for "unmoveable" tiles.
19:52:08 <andythenorth> flat moving objects?
19:52:25 <peter1138> Transmitters and lighthouses. To get in your way.
19:52:32 <andythenorth> we could to road-railer stuff with mutation depots
20:10:21 <Eddi|zuHause> well, from my perspective, objects were a solution to "non-track stations can't be put on all types of slopes"
20:26:28 <andythenorth> hmm build has changed recently?
20:26:41 <andythenorth> `src/stdafx.h:74:10: fatal error: 'source_location' file not found
20:26:41 <andythenorth> #include <source_location>
20:27:08 <andythenorth> some vckpg I need?
20:27:18 <peter1138> There are definitely no commits during the day.
20:27:30 <truebrain> Newer XCode is what you need
20:28:07 <andythenorth> hmm my cmake is broken also
20:28:15 <andythenorth> macOS updates probably
20:28:38 <truebrain> That error you see is a commit introduced today in OpenTTD
20:29:35 <andythenorth> XCode 15 isn't available for my device
20:29:46 <andythenorth> wheels in wheels ๐
20:30:29 <truebrain> You don't have an M1? ๐ฎ
20:30:38 <andythenorth> I don't have macOS 14+
20:31:20 <andythenorth> recent macOS versions have been quite breaking
20:31:23 <peter1138> We've obsoleted andy.
20:31:44 <peter1138> Who'd've thought a developement environment needs a specific version of the OS...
20:32:03 <truebrain> It is Apple, nothing is surprising anymore
20:32:14 <andythenorth> I am several OS major versions behind
20:32:30 <peter1138> Hmm, 15.2 should work on 13.5.
20:32:35 <peter1138> Just 15.3 needs 14.
20:32:36 <matusguy-station> apple do be like that
20:32:38 <andythenorth> yeah I'm on 12 something
20:32:56 <andythenorth> they changed the UI button colours and I couldn't update without mental preparation
20:33:05 <peter1138> Is that similar to a Windows user still being on Windows 7?
20:33:32 <andythenorth> ok, I guess I download official OpenTTD binaries
20:33:46 <truebrain> Like the rest of the plebs
20:33:52 <peter1138> We'll probably find out they need macOS 14 too ๐
20:34:30 <peter1138> I'm glad I switched back to Linux... my OS hasn't been forcing adverts and AI on me at all.
20:35:08 <peter1138> Although VS Code updates have been trying.
20:42:50 <xarick> how do I get a list of Commands with extra error strings? Need to know how it's being used
20:43:54 <_glx_> it's not used too often I think
20:45:34 <_glx_> most of the time it will be INVALID_STRING_ID
20:46:24 <xarick> AIs already have error category, now they're getting a 3rd layer
20:47:06 <_glx_> it would be similar to GetLastError()
20:49:35 <_glx_> anyway if you look at errors, you'll see we try to merge similar errors to ease AI coding
20:50:01 <_glx_> `ERR_VEHICLE_IN_THE_WAY, // [STR_ERROR_TRAIN_IN_THE_WAY, STR_ERROR_ROAD_VEHICLE_IN_THE_WAY, STR_ERROR_SHIP_IN_THE_WAY, STR_ERROR_AIRCRAFT_IN_THE_WAY]`
20:50:30 <_glx_> or ` ERR_AREA_NOT_CLEAR, // [STR_ERROR_BUILDING_MUST_BE_DEMOLISHED, STR_ERROR_MUST_DEMOLISH_BRIDGE_FIRST, STR_ERROR_MUST_DEMOLISH_RAILROAD, STR_ERROR_MUST_DEMOLISH_AIRPORT_FIRST, STR_ERROR_MUST_DEMOLISH_CARGO_TRAM_STATION_FIRST, STR_ERROR_MUST_DEMOLISH_TRUCK_STATION_FIRST, STR_ERROR_MUST_DEMOLISH_PASSENGER_TRAM_STATION_FIRST,
20:50:30 <_glx_> STR_ERROR_MUST_DEMOLISH_BUS_STATION_FIRST, STR_ERROR_BUOY_IN_THE_WAY, STR_ERROR_MUST_DEMOLISH_DOCK_FIRST, STR_ERROR_GENERIC_OBJECT_IN_THE_WAY, STR_ERROR_COMPANY_HEADQUARTERS_IN, STR_ERROR_OBJECT_IN_THE_WAY, STR_ERROR_MUST_REMOVE_ROAD_FIRST, STR_ERROR_MUST_REMOVE_RAILROAD_TRACK, STR_ERROR_MUST_DEMOLISH_BRIDGE_FIRST, STR_ERROR_MUST_DEMOLISH_TUNNEL_FIRST, STR_ERROR_EXCAVATION_WOULD_DAMAGE]`
20:50:57 <xarick> 1 unbunch error for all 5
20:51:43 <_glx_> for me a "can't set order" should be enough
20:52:09 *** Wormnest has quit IRC (Ping timeout: 480 seconds)
21:21:31 *** Wormnest has joined #openttd
21:24:50 <xarick> what are those \ character there for?
21:25:02 <xarick> how do I know how many spaces I need?
21:28:24 <_glx_> `Whenever backslash (\) appears at the end of a line (immediately followed by zero or more whitespace characters other than new-line followed by(since C++23) the newline character), these characters are deleted, combining two physical source lines into one logical source line. This is a single-pass operation; a line ending in two backslashes followed by an empty line does not combine three lines
21:28:31 <Eddi|zuHause> the \ characters are "escape" symbols. in this case, they "escape" the line break, so the next line gets treated as a continuation of the current line
21:28:56 <Eddi|zuHause> normally, a "#define" ends at the end of the line
21:30:26 <Eddi|zuHause> the number of spaces, like everywhere, is irrelevant. only important is that the \ character is the last character on the line.
21:47:27 <andythenorth> how do I reduce the industry cargo displays to 0 decimal places?
21:47:34 <andythenorth> I looked in units settings
21:47:51 *** keikoz has quit IRC (Ping timeout: 480 seconds)
21:49:57 <peter1138> Sounds like a bug that's since been fixed?
21:51:29 <andythenorth> yeah, I have RC1
22:06:24 *** gelignite has quit IRC (Quit: Stay safe!)
22:17:27 <xarick> do a regression test for the extra error
22:17:46 <xarick> what kind of action I need to perform?
22:17:51 *** nielsm has quit IRC (Ping timeout: 480 seconds)
22:21:03 <xarick> so much for streamlining the error message, and then add an extra message ๐
22:24:31 <xarick> what the heck is this... LOL
22:29:23 <xarick> why not use string operations
22:29:44 <xarick> add extra string but as string on string or so
22:30:20 <xarick> extra error message wasn't necessary imo
22:33:47 <xarick> where is the ...vehicle can't go to that station being set at?
22:36:08 <xarick> Command<CMD_INSERT_ORDER>::Post(STR_ERROR_CAN_T_INSERT_NEW_ORDER
22:54:16 <xarick> I have no way to test the extra error
22:54:27 <xarick> would require me to also add more errors
23:17:35 *** matusguy-station has quit IRC (Remote host closed the connection)
23:26:17 <xarick> `ScriptObject::Command<CMD_INSERT_ORDER>::Do(0, vehicle_id, order_pos, order);`
23:26:17 <xarick> they don't have a ::Post
23:39:53 <xarick> talltyler: An AI is adding a depot unbunch order, it fails with:
23:39:53 <xarick> CommandCost(STR_ERROR_CAN_T_ADD_ORDER, STR_ERROR_UNBUNCHING_ONLY_ONE_ALLOWED);
23:39:53 <xarick> Resulting message is actually this:
23:39:53 <xarick> {WHITE}... vehicle can't go to that station
23:39:53 <xarick> {WHITE}... can only have one unbunching order
23:40:10 <xarick> there is no POST message
23:42:06 <xarick> does it really require a 2 string error return?
continue to next day โต