IRC logs for #openttd on OFTC at 2023-04-26
01:29:06 *** debdog has joined #openttd
01:47:43 *** WormnestAndroid has quit IRC (Ping timeout: 480 seconds)
01:47:53 *** WormnestAndroid has joined #openttd
01:51:54 *** WormnestAndroid has quit IRC (Read error: Connection reset by peer)
01:51:56 *** WormnestAndroid has joined #openttd
02:02:04 *** herms has quit IRC (Quit: bye)
02:02:50 *** herms has joined #openttd
02:17:49 *** D-HUND has joined #openttd
02:21:06 *** debdog has quit IRC (Ping timeout: 480 seconds)
02:26:35 *** D-HUND is now known as debdog
02:33:26 *** Wormnest has quit IRC (Quit: Leaving)
03:42:33 *** keikoz has joined #openttd
03:50:29 *** Flygon has quit IRC (Read error: Connection reset by peer)
04:06:05 <pickpacket> dP: has that exploit of yours been patched yet?
05:09:21 *** TROILUS has joined #openttd
05:45:15 <DorpsGek> [OpenTTD/OpenTTD] PeterN merged pull request #10713: Codechange: Use vector instead of mallloc/free for Action 6 data.
05:46:11 <DorpsGek> [OpenTTD/OpenTTD] PeterN merged pull request #10669: Fix #10627: Houses subsitute specs should only be copied on first definition.
06:29:07 <DorpsGek> [OpenTTD/OpenTTD] PeterN approved pull request #10718: Cleanup: remnants of OTTD_PRINTF, str_fmt and vseprintf
07:29:26 <DorpsGek> [OpenTTD/OpenTTD] TrueBrain approved pull request #10717: Codechange: Define Date/Year/Month/Day within TimerGameCalendar class
07:29:37 <TrueBrain> still tempted to suggest making it an enum, so type-checking kicks in, but let's not do that today πŸ™‚
07:30:12 <petern> πŸ™‚
07:30:28 <TrueBrain> you just know with Economy Date, people will make mistakes
07:30:33 <TrueBrain> and get some weird-ass dates πŸ˜›
07:32:32 <LordAro> TallTyler got served
07:34:50 <petern> Those comments... they've never noticed that the title game is (usually) never a full playable game, just a mockup designed to stuff as much variety into the middle...
07:35:05 <LordAro> of course not
07:35:20 <TrueBrain> But ranting is always nicer than to be constructive
07:35:37 <LordAro> and there's the usual inflamatory comment from Rau too
07:36:30 <LordAro> oh, that's the one i linked, lol
07:36:43 <TrueBrain> yeah, I had to click to see the context of that comment
07:36:52 <TrueBrain> to find out there wasn't really any context to go with πŸ˜›
07:37:14 <petern> Had to turn the heating on, why so cold :/
07:37:53 <TrueBrain> yes, I was wondering the same this morning .. they say it will go below zero tonight .. it is almost May
07:37:56 <TrueBrain> fucking weather
07:44:52 <Eddi|zuHause> use protection
07:47:54 <TrueBrain> `'_strtoui64': is not a member of 'std'` .. wth MSVC ... this seems to be on a `std::strtoull` ..
07:49:53 <TrueBrain> I never like when I search for an error on a project, I get zero hits πŸ˜›
07:49:57 <TrueBrain> we can't be that special
07:52:26 <LordAro> uhoh
07:57:27 <Eddi|zuHause> for 2 days i'm now thinking about a suitible reply to that "you're always calling people dumb" post on the forum that won't get me banned...
07:57:47 <Eddi|zuHause>
08:00:34 <LordAro> two wrongs don't make a right, Eddi|zuHause ;)
08:02:02 <Eddi|zuHause> the thing is, a) he's calling this thing a "bug" when clearly someone very intentionally put this feature in. and changing a feature is a completely different discussion, and b) he's in the wrong section, because this is a vanilla feature, not a JGR feature...
08:03:48 <Eddi|zuHause> but saying either of this would just make him even more angry
08:04:09 <Eddi|zuHause> him, who proudly wears the badge of "worst behaved forum member"
08:04:28 <Eddi|zuHause> err, IRC member, whatever
08:06:36 <JGR> You could just not say anything at all, surely that is the easiest option
08:06:54 <Eddi|zuHause> i was thinking that same direction, yes
08:07:17 <Eddi|zuHause> but somebody is WRONG on the INTERNET...
08:19:50 <DorpsGek> [OpenTTD/OpenTTD] PeterN commented on issue #10698: [Bug]:
08:19:53 <DorpsGek> [OpenTTD/OpenTTD] PeterN closed issue #10698: [Bug]:
08:21:23 <DorpsGek> [OpenTTD/OpenTTD] PeterN commented on issue #10705: [Bug]: Assertion failed at line 4739 of D:\a\OpenTTD\OpenTTD\src\station_cmd.cpp: runtime > 0
08:21:26 <DorpsGek> [OpenTTD/OpenTTD] PeterN closed issue #10705: [Bug]: Assertion failed at line 4739 of D:\a\OpenTTD\OpenTTD\src\station_cmd.cpp: runtime > 0
08:25:17 <TrueBrain> okay, after a lot of digging ... out stdafx.h says: `# define strtoull _strtoui64`
08:25:33 <TrueBrain> the issue? The JSON library uses `std::strtoull` πŸ™‚
08:25:50 <TrueBrain> Macro's are the worst!
08:25:58 <petern> Yup
08:26:05 <TrueBrain> not actually sure how to resolve it ...
08:26:17 <TrueBrain> shouldn't `std::strtoull` do the right thing already?
08:27:55 <TrueBrain> always a bit lost with the endless long long long long long longer longeststststs
08:34:53 <TrueBrain> not sure what the difference is between `_strtoui64` and `strtoull` ..
08:37:14 <LordAro> mm, can't imagine there's a good reason for that define to exist these days
08:37:36 <TrueBrain> I am guessing mingw πŸ˜›
08:37:58 <LordAro> mingw 1.x, perhaps
08:38:08 <LordAro> mingw these days is fairly sane
08:38:17 <LordAro> for the most part
08:38:30 <TrueBrain> so I am going to remove that entry, and add `std::` explicit in the few places it is used
08:38:37 <TrueBrain> not sure why, that last part, but I just feel like it
08:39:04 <TrueBrain> ah, it is C++11 only
08:39:10 <TrueBrain> well, "only" ..
08:39:15 <TrueBrain> it is there since C++11
08:39:17 <TrueBrain> this code is from before πŸ˜„
08:40:04 <DorpsGek> [OpenTTD/OpenTTD] TrueBrain updated pull request #10719: Feature: opt-in survey when exiting a game
08:40:48 *** peter1138 has quit IRC (Read error: Connection reset by peer)
08:41:23 <DorpsGek> [OpenTTD/OpenTTD] TrueBrain updated pull request #10719: Feature: opt-in survey when exiting a game
08:41:57 <DorpsGek> [OpenTTD/OpenTTD] TrueBrain updated pull request #10719: Feature: opt-in survey when exiting a game
08:42:03 <TrueBrain> I will get there, don't worry πŸ™‚
08:42:05 *** peter1138 has joined #openttd
08:42:05 *** ChanServ sets mode: +o peter1138
08:50:15 <petern> Hmm
08:51:34 <TrueBrain> yes, hmm .. I know we output the OpenGL driver somewhere .. how do we do that ..
08:51:45 <TrueBrain> I used the code from the crashlog; that clearly isn't enough πŸ˜„
08:52:29 <petern> settings_gui.cpp shows it.
08:52:44 <Eddi|zuHause> there used to be some stuff in "openttd -h"
08:56:40 <TrueBrain> petern: yeah, that is from where I got that `VideoDriver::GetInstance()->GetInfoString()` should be the one
08:56:42 <TrueBrain> but it seems not .. hmm
08:56:48 <petern> Oh
08:57:18 <TrueBrain> owh, I am a potato
08:57:45 <TrueBrain> all other drivers are `GetName` .. too much copy/paste πŸ˜„
09:00:43 <TrueBrain> ` "video_info": "sdl (x11)"`
09:00:46 <TrueBrain> yeah, that is better πŸ™‚
09:03:03 <TrueBrain> <- updated with the latest JSON payload .. I think that should be enough for a first round πŸ™‚
09:09:35 <petern> Should all the savegame info be a in separate tree from system info?
09:10:00 <TrueBrain> hmm, would make a deeper tree
09:10:42 <TrueBrain> companies / game / grfs / settings in a `game` key, and the rest in an `info` key?
09:10:42 <petern> Might make it easier to classify the type of information though.
09:11:13 <petern> Something like that, yeah.
09:11:27 <TrueBrain> finding the right names for the keys has been an issue for this blob πŸ˜„
09:12:01 <petern> Use single letters to make it harder to parse by humans πŸ˜‰
09:15:15 <TrueBrain> same for settings right? πŸ˜„
09:15:56 <TrueBrain> okay, I changed it to be graceful towards libraries and secrets .. if you don't have the JSON library installed, OpenTTD will still compile .. but without survey support, ofc
09:16:12 <TrueBrain> and if you don't have the secret, you still send the survey, but it is marked clearly (for us on the backend) as a non-official build sending a survey
09:16:16 <TrueBrain> should be fine πŸ™‚
09:17:02 <TrueBrain> petern: gist updated, like this?
09:18:53 <petern> Exactly!
09:21:01 <TrueBrain> another update to include some AIs
09:21:32 <TrueBrain> look at that, even mingw compiled
09:21:33 <TrueBrain> nice πŸ™‚
09:21:48 <DorpsGek> [OpenTTD/OpenTTD] TrueBrain updated pull request #10719: Feature: opt-in survey when exiting a game
09:22:07 <TrueBrain> now for the backend ...... now that is a bit more tricky πŸ™‚
09:23:08 <TrueBrain> this blob is ~20KB in size
09:24:11 <TrueBrain> anyway, while I focus on the backend, could really use the help of someone adding the GUI parts for this PR πŸ™‚
09:31:11 <petern> If you really want a blob, use BJSON πŸ™‚
09:31:50 <TrueBrain> seems like more pain than it is worth πŸ˜›
09:32:18 <TrueBrain> compressing a single surveys makes it ~25% of the size .. compressing 100 surveys makes it 1% of the size πŸ˜„
09:32:24 <TrueBrain> you got to love all those settings .. so compressable πŸ˜„
09:34:19 <TrueBrain> if I do some math .. Steam says we have ~1000 active users, say, they leave a game 10 times a day, and 100% opt-in to the survey. That means we have 10k surveys per day, each 20KiB, making 200MiB of data a day. Or 6GiB of storage per month. Compression seems to be 1%, but let's say 10%. Means for every month we keep in storage it will cost us ~0.015 dollar.
09:34:37 <TrueBrain> Now there is also cost to store information, 10k surveys per day, so 300k stored surveys per month, which is ~1.5 dollar
09:34:52 <TrueBrain> retrieving them is irrelevant
09:35:08 <TrueBrain> so it means adding this survey stuff to OpenTTD would cost us ~2 dollar per month, give or take a few
09:35:28 <TrueBrain> seems well within the rounding error of our monthly bill πŸ˜›
09:35:56 <TrueBrain> and we can always rate-limit it, if there is a need to
09:49:08 <TrueBrain> hmm .. guess "RAM installed" would be a useful piece of data for us too .. as we tend to worry about that .. but no clue if that is easy to get πŸ™‚
09:49:56 <petern> <>
09:50:06 <petern> Probably written by an AI and broken.
09:56:43 <TrueBrain> meh; also means we need to figure out what MacOS does .. let's go without first πŸ™‚
09:56:51 <TrueBrain> maybe someone feels like adding that later πŸ™‚
09:57:29 <petern> Hmm, sysctl apparently.
09:57:56 <TrueBrain> lol, that feels like a hack πŸ˜„
09:58:30 <petern> Isn't it all?
09:58:39 <TrueBrain> well, I meant, via a string
09:58:41 <TrueBrain> that is just weird πŸ˜›
09:59:01 <petern> Seems to be an int64_t, not a string.
09:59:08 <petern> <> allegedly.
09:59:19 <petern> I do not do all my coding by copying stackoverflow, but...
09:59:23 <TrueBrain> was looking at your earlier URL: ` rc = sysctlbyname("vm.vmtotal", &vmt, &vmt_size, NULL, 0);`
09:59:29 <petern> Ahh
09:59:54 <TrueBrain> via a MIB seems more sensible πŸ™‚
10:00:22 <petern> Although that was just getting the data by name, not returning the data by string.
10:00:43 <TrueBrain> no, but it is weird to use strings there πŸ˜›
10:01:36 <TrueBrain> okay, I have an idea for the backend, which makes it a lot less complicated .. which I like πŸ™‚
10:02:36 <DorpsGek> [OpenTTD/OpenTTD] github-code-scanning[bot] commented on pull request #10719: Feature: opt-in survey when exiting a game
10:02:56 <TrueBrain> pfff, CodeQL ...
10:03:02 <TrueBrain> ratting me out I should make smaller functions
10:03:12 <TrueBrain> I already added scopes in the function .. which already was a clear sign πŸ˜„
10:14:14 *** gnomechomsky has joined #openttd
10:14:14 <gnomechomsky> Is there any guide to adding a setting?
10:14:28 <DorpsGek> [OpenTTD/OpenTTD] LordAro opened pull request #10720: Codechange: Use std::strto* variants everywhere
10:23:17 <DorpsGek> [OpenTTD/OpenTTD] TrueBrain approved pull request #10720: Codechange: Use std::strto* variants everywhere
10:23:26 <TrueBrain> gnomechomsky: yeah; avoid it if you can πŸ˜„ Why you ask?
10:24:31 <gnomechomsky> I can't start work right away, but I want to work on this
10:26:44 <petern> One of the functions to convert strings throws exceptions if it can't, but I think that's str::toul[l].
10:27:13 <petern> Weird to see a load of C++ wrappers around a C function though, heh.
10:27:16 <LordAro> gnomechomsky: there's no guide as such, best bet is to check the git logs for changes within src/table/settings/*
10:28:04 <LordAro> petern: std::stoull ?
10:28:10 <LordAro> or can i just not see your edits
10:28:23 <petern> Yes, that one. I didn't edit, just typod.
10:34:21 <Eddi|zuHause> gnomechomsky: generally a setting consists of 3 parts: the internal storage, the configuration of openttd.cfg and the display in the settings gui
10:35:34 <Eddi|zuHause> and then some added bits to handle savegame conversion in case a setting changes over time
10:48:41 *** Alkel_U3 has quit IRC (Quit: maintenance)
10:49:40 *** Alkel_U3 has joined #openttd
10:52:52 <gnomechomsky> Thanks guys
10:53:21 <glx[d]> <-- the 2 grfs are generated, didn't test them yet (nml output is often inefficient and that's very visible in the generated nfo)
10:54:06 <LordAro> sounds like potential improvements to nmlc :p
10:56:34 <glx[d]> And I can see a need for action 0C support
10:57:57 <petern> They're not really necessary are they?
10:58:45 <glx[d]> They can store copyright info inside the grf next to the usage
11:00:12 <petern> Ah, which bit ends up being inefficient? varaction chains?
11:00:15 <glx[d]> And give hints about the section in case grf is decompiles
11:00:40 <glx[d]> Action7 stuff
11:01:02 <petern> Hm, that's... fairly basic.
11:01:28 <glx[d]> Mostly uses at least 2 action0D even for simple cases
11:02:03 <petern> Weird.
11:02:19 <petern> Sets a parameter and then tests it, instead of just testing the original variable?
11:02:55 <glx[d]> Yes, because it only does 32bit tests
11:03:52 <glx[d]> Also it seems to never merge multiple action0A or action12
11:12:57 <TallTyler> TrueBrain: I’d like to do this, since typechecking is sort of the whole point of splitting the typedef by calendar type. I just don’t know how that works here. I’ve only used enums for simple consts. Care to elaborate? (Maybe in a gist?)
11:13:30 <TrueBrain> peter linked something like that yesterday
11:13:34 <TrueBrain> it is mostly just a hack
11:13:36 <TrueBrain> so meh πŸ˜›
11:14:02 <petern> It is yeah. Also should be separated from that PR anyway.
11:14:07 <DorpsGek> [OpenTTD/OpenTTD] 2TallTyler merged pull request #10717: Codechange: Define Date/Year/Month/Day within TimerGameCalendar class
11:14:35 <TallTyler> Hmm, I didn’t see that link
11:14:52 <TallTyler> Will have to search for it unless you still have it handy
11:15:45 <TallTyler> Ah, found it
11:16:36 <TallTyler> But we should not do that?
11:17:07 <TrueBrain> try it; see how it looks
11:17:11 <TrueBrain> just don't spend days on it πŸ˜›
11:17:18 <Eddi|zuHause> i don't think we had a conclusion on that :p
11:23:10 <pickpacket> Finally got around to donating!
11:23:17 <pickpacket> better late than never
11:23:45 <TrueBrain> <- lol, that is also a way of doing it πŸ˜„
11:24:18 <TrueBrain> just macro a struct around it πŸ™‚
11:24:28 <LordAro> gotta love some proper boost magic
11:24:37 <TrueBrain> it is not even -that- bad
11:24:51 <TrueBrain> it just creates a class with some explicit assignment and constructors
11:26:10 <TrueBrain> a macro rather similar might be useful for OpenTTD; as we have plenty of typedefs which we actually want to type-check, but don't currently πŸ˜„
11:27:10 <DorpsGek> [OpenTTD/OpenTTD] PeterN opened pull request #10721: Fix #10334: Store separate newgrf-safe version of date_of_last_service.
11:28:07 <TrueBrain> what is date-of-last-service used for?
11:28:29 <TrueBrain> as in, do NewGRFs just assume it is monotone?
11:29:28 <TrueBrain> as `TimerGameTick::counter / DAYS_PER_TICK` might be a better variable to use in that case?
11:29:31 <petern> They assume it is only changed in a depot, which allows them to change properties of vehicles that can only change in the depot.
11:30:00 <TrueBrain> (as that is completely independent of anything πŸ™‚
11:30:08 <petern> The only other time it can change is if you use the date cheat.
11:30:19 <petern> Previously that always worked because... asserts were not enabled in release.
11:30:24 *** WormnestAndroid has quit IRC (Read error: Connection reset by peer)
11:30:28 <TrueBrain> haha πŸ˜„
11:30:43 <LordAro> ha
11:30:49 <TrueBrain> well, especially looking at the economy PR, where I had some worries about this variable .. it seems that the TimerGameTick is actually what they expect?
11:30:53 *** WormnestAndroid has joined #openttd
11:30:54 <petern> Date of last service is also shown in the GUI, so just raw ticks doesn't seem right.
11:31:06 <TrueBrain> no, we can leave date-of-last-service as is
11:31:18 <TrueBrain> just instead of copying it to `date_of_last_service_newgrf`, you can base it of the TimerGameTick
11:31:27 <TrueBrain> that way, with the economy PR, this no longer needs addressing πŸ™‚
11:31:44 <TrueBrain> (the economy PR creates a new `date_of_last_service_economy`, for this exact same purpose :P)
11:32:15 <petern> It's not really a calendar/economy issue though, it's because the date cheat adjusts it so that engines carry on getting serviced.
11:32:38 <TrueBrain> yeah, so NewGRF doesn't care about the timer it is using, if I get you correct
11:32:46 <TrueBrain> so it should be TimerGameTick
11:33:33 <petern> Fair, so I need to fix this PR πŸ™‚
11:33:56 <TrueBrain> worded differently: if the calendar is frozen, I am guessing the NewGRF still wants this value to update, right?
11:34:08 <petern> And of course before #10717 was merged a moment ago we'd never have noticed πŸ™‚
11:34:24 <petern> Good point.
11:34:26 <TrueBrain> such useful changes πŸ˜„
11:34:27 <petern> Actually no.
11:34:36 <petern> They tend to want it to be calendar time.
11:34:53 <TrueBrain> so if the calendar is frozen in time, never changes, that value never gets updated?
11:34:59 <petern> Different properties depending on calendar, not gametick.
11:35:01 <petern> Yup
11:35:14 <TrueBrain> where is this used for?! It feels so weird ..
11:35:49 <petern> With variants, we'd now just say make it a new vehicle type πŸ™‚
11:35:56 <petern> But older NewGRFs exist.
11:36:10 <TrueBrain> so based on the date they make other choices?
11:36:14 <petern> Sure.
11:36:17 <TrueBrain> ugh
11:36:33 <TrueBrain> so okay, with cheating the date, the graphics all of a sudden change of a train, is what you mean?
11:36:41 <petern> Service date is something that is fairly static to base decisions on. It only changes at a defined time. Except when cheating...
11:36:54 <TrueBrain> okay, now I somewhat understand ..
11:36:57 <petern> Not so much graphics. The main issue is cargo capacity.
11:37:11 <TrueBrain> do I want to know what people did? πŸ˜›
11:37:12 <petern> Well, the issue in 10334 is πŸ™‚
11:37:36 <petern> If you service a vehicle after a certain date it changes the cargo capacity.
11:37:55 <TrueBrain> okay .. so yeah .. I get more what you mean now πŸ™‚
11:38:15 <petern> Thinking about it, in this case the issue is two pronged and may need another fix.
11:38:56 <petern> I think from reading 10334, the NewGRF returns 0 if the date is before some range. Which will probably break things anyway.
11:39:09 <petern> So might need to test that separately.
11:39:22 <TrueBrain> so they don't have another place to store what type of wagon they picked, capacity, etc, so they base it on the last-service-date ..
11:40:06 <petern> Not really, they actually want it to change based on time, and last-service date was the safeish way to do that.
11:40:29 <petern> You can't use current date for that because it changes all the time, of course πŸ™‚
11:40:36 <TrueBrain> yeah .. okay
11:40:50 <TrueBrain> what I would have expected, train in depot, decide capacity, store in vehicle, go go go
11:40:50 <petern> NewGRFs huh? Who designed this...
11:40:56 <TrueBrain> but I guess the "store in vehicle" doesn't exist
11:40:58 <petern> Yeah, we don't πŸ™‚
11:41:09 <TrueBrain> okay; so your PR makes sense
11:41:14 <TrueBrain> except for the "I didn't test this" part
11:41:20 <TrueBrain> would be nice if someone actually did test it πŸ˜›
11:42:07 <TrueBrain> petern: before `DAYS_TILL_ORIGINAL_BASE_YEAR` I guess? But that is why there is 4B, not? πŸ™‚
11:42:09 <petern> Should probably have not done it in my lunch break πŸ™‚
11:42:49 <DorpsGek> [OpenTTD/OpenTTD] TrueBrain commented on pull request #10721: Fix #10334: Store separate newgrf-safe version of date_of_last_service.
11:43:12 <petern> LOL I even looked but wrote the wrong one 😦
11:43:22 <TrueBrain> Snorry πŸ™‚
11:44:10 <petern> I think it'll need more to fix the one case anyway.
11:44:19 <petern> Not sure though.
11:44:22 <DorpsGek> [OpenTTD/OpenTTD] TrueBrain commented on pull request #10721: Fix #10334: Store separate newgrf-safe version of date_of_last_service.
11:45:28 <TrueBrain> code-wise it seems fine, so tempted to approve this at least, while you can fiddle with the other case πŸ™‚
11:45:56 <TrueBrain> I just wonder if there isn't a NewGRF author that use this to check how long a train is out of the depot
11:46:01 <TrueBrain> and will now break with your PR πŸ˜„
11:46:58 <TrueBrain> feels like one of those situations where it is always wrong, no matter what πŸ˜„
11:47:05 <petern> Only if the date is cheated.
11:47:11 <TrueBrain> yeah
11:47:23 <TrueBrain> so date-cheat now breaks one NewGRF, but another works fine
11:47:26 <TrueBrain> with your PR, that flips πŸ˜›
11:47:42 <TrueBrain> so I wonder if that means we will get a bugreport "soon" about the other case πŸ˜„
11:48:09 <petern> I think if it was to break it wouldn't be game-crashing though.
11:48:18 <TrueBrain> true
11:48:36 <petern> I don't really like storing the same value twice though, just in case somebody cheats.
11:49:07 <TrueBrain> well, with #10700 there will be 2 date-of-last-service anyway, one on the Calendar, one on Economy
11:49:18 <TrueBrain> as, well, GRFs want the first, and most of the game wants the latter
11:49:25 <TrueBrain> maybe your PR fits better after that PR?
11:50:16 <petern> Potentially.
11:50:39 <TrueBrain> ah, no, the game is 50/50 whether it is Economy or Calendar
11:50:48 <TrueBrain> I guess the main question is: if you cheat, should the GUI update to the new date?
11:50:55 <TrueBrain> as it was serviced on the date before cheat
11:50:58 <TrueBrain> so why change that? πŸ˜„
11:51:40 <petern> I know it's weird all over.
11:51:43 <petern> Just remove cheats πŸ˜‰
11:51:46 <TrueBrain> YES!
11:51:48 <TrueBrain> I will make a PR πŸ™‚
11:51:55 <TrueBrain> (lolz)
11:52:50 <TrueBrain> I think it would be cleanest: have the calendar-based date unchanging by cheat, and use it for NewGRF and GUI
11:53:12 <TrueBrain> have the economy-based date for things like: when to service
11:53:48 <TrueBrain> basically removing `ShiftDates` from `Vehicle` πŸ™‚
11:54:30 <petern> Ah ah. So in effect #10700 would "accidentally" fix #10334 anyway...
11:54:34 <TrueBrain> well, no, you still need it for economy, fucking max-year blabla
11:54:38 <pickpacket> What's a good IDE for working with the code?
11:54:52 <petern> VS Code.
11:54:53 <TrueBrain> not in its current state. But that is purely because TallTyler seems to not have updated `ShiftDates` πŸ˜„
11:55:16 <TallTyler> I may have forgotten or done that on purpose. Not sure right now.
11:55:33 <TrueBrain> TallTyler: you sadly need to, as economy also has a max-year .. so it will wrap at some point πŸ˜›
11:55:37 <DorpsGek> [OpenTTD/OpenTTD] LordAro opened pull request #10722: Change: [CMake] Automatically disable asserts when building an actual release
11:55:42 <TallTyler> But once we have calendar date split, date cheat should only affect that and economy date keeps on ticking no matter what the player does
11:55:55 <TrueBrain> well, yes, but again, expect for max-year πŸ˜„
11:56:02 <TrueBrain> so there is a minor nuance to that story πŸ™‚
11:56:08 <DorpsGek> [OpenTTD/OpenTTD] PeterN commented on pull request #10721: Fix #10334: Store separate newgrf-safe version of date_of_last_service.
11:56:18 <DorpsGek> [OpenTTD/OpenTTD] LordAro merged pull request #10720: Codechange: Use std::strto* variants everywhere
11:56:27 <TallTyler> In the final PR, when economy date hits max year it goes back by 700 to avoid having to hit last year again for a while. (Not my commit, but made sense to me)
11:56:42 <TallTyler> Is max date a problem anybody experiences or is it theoretical?
11:56:46 <TrueBrain> why not change it to 0, but yeah πŸ˜›
11:56:56 <TrueBrain> it is there because someone complained about it
11:57:30 <TrueBrain> `this->date_of_last_service + this->GetServiceInterval() >= TimerGameCalendar::date`
11:57:39 <TrueBrain> another way of avoiding the ShiftDate stuff, is to make that line more intelligent to wrapping
11:57:51 *** WormnestAndroid has quit IRC (Remote host closed the connection)
11:57:58 <TrueBrain> `TimerGameEconomy::date < this->date_of_last_service || this->date_of_last_service + this->GetServiceInterval() >= TimerGameEconomy::date`
11:57:59 *** WormnestAndroid has joined #openttd
11:58:00 <TrueBrain> or something πŸ™‚
11:58:10 <TrueBrain> meh, no, bad idea
11:58:28 <pickpacket> petern: any more resource friendly alternative? :P
11:58:39 <TrueBrain> notepad
11:58:41 <petern> vim
11:58:50 <TrueBrain> RESOURCE FRIENDLY, he said
11:58:55 <pickpacket> yeah...
11:59:08 <pickpacket> TrueBrain: notepad required wine too
11:59:08 <TrueBrain> so vim is out ... emacs too ... joe too .. nano: nah
11:59:09 <Eddi|zuHause> depends on what ressource :)
11:59:14 <TrueBrain> notepad is ... poehh ... on the limit
11:59:23 <TrueBrain> I think, you need to go back to punchcards
11:59:27 <pickpacket> nano is the smallest of those
11:59:36 <TrueBrain> that seems to be the best match for you
11:59:45 <TrueBrain> (in case it wasn't clear, I am being kinda sarcastic here :P)
11:59:47 <DorpsGek> [OpenTTD/OpenTTD] glx22 commented on pull request #10719: Feature: opt-in survey when exiting a game
11:59:59 <Eddi|zuHause> real programmers use sed :)
12:00:00 <LordAro> pickpacket: VSCode is more resource friendly than compiling the game itself :p
12:00:04 <pickpacket> is it nano that's small enough to fit in the L1 cache of most processors? Or is that another editor+
12:00:11 <pickpacket> LordAro: true dat
12:00:13 <LordAro> well, with a certain amount of multithreading
12:00:13 <TrueBrain> well said LordAro πŸ™‚ I was writing up some other comparisons πŸ˜›
12:00:29 <pickpacket> I have VSCode on my work comp. Might just use that
12:00:42 <Eddi|zuHause> really, you should use office 365...
12:00:55 <pickpacket> I mean, *someone* has to do something about the beard-less situation of the company managers
12:00:58 <Eddi|zuHause> because cloud is the future
12:01:38 <pickpacket> clouds are old news
12:01:52 <petern> Remember before nano, when we used pico, which came from pine...
12:02:03 <petern> So the joke about editors gaining email clients is kinda reversed.
12:02:59 <DorpsGek> [OpenTTD/OpenTTD] TrueBrain commented on pull request #10722: Change: [CMake] Automatically disable asserts when building an actual release
12:05:09 <pickpacket> maybe it'
12:05:18 <pickpacket> s pico that fits in the L1 cache?
12:05:27 <pickpacket> uh... i mean the L2 cache
12:05:31 <TrueBrain> LordAro: guess the PR also doesn't work with `.ottdrev` .. not sure that is an issue πŸ˜„
12:05:46 <petern> Alternative fix to 10334 - return build date instead of last service date to newgrf.
12:06:07 <LordAro> TrueBrain: ah yeah, that's true
12:06:08 <petern> The NewGRF won't do what the author wants, but it won't crash πŸ˜„
12:06:24 <TrueBrain> lol πŸ™‚ Is that how we solve problems now? πŸ˜›
12:06:25 <petern> Hmm, have I eaten?
12:06:32 <petern> Remove NewGRF? Yes.
12:06:44 <petern> Works for Google.
12:07:15 <petern> Built-in SIP client works for most people but some configurations cause issues? No problem, nobody has a built-in SIP client any more.
12:07:34 <TrueBrain> LordAro: I guess the main worry is, which you already expressed, what if you first go to a release tag, build it, change to master, and build it again in the same cmake build folder
12:07:47 <TrueBrain> which brings us back to the reason this is a setting πŸ˜„
12:08:04 <LordAro> i guess so
12:08:09 <LordAro> maybe it should be done in the CI instead?
12:08:19 <TrueBrain> owh, yeah, we can do that
12:08:56 <LordAro> would need to do the pre-release vs release check somewhere, but that might be cleaner
12:09:11 <TrueBrain> we can use FindVersion for that, I think
12:10:21 <TrueBrain> no clue what the `REV_MAJOR` and `REV_MINOR` are actually doing in the call
12:10:50 <TrueBrain> but yeah, we can call FindVersion with `GENERATE_OTTDREV`, and check `.ottdrev` if it is a stable build yes/no
12:11:10 <LordAro> i believe for the release builds we already have a .ottdrev
12:11:16 <LordAro> it builds from the source archive
12:11:32 <TrueBrain> good point
12:11:34 <TrueBrain> as there we call FindVersion
12:11:36 <TrueBrain> with `GENERATE_OTTDREV` πŸ˜„
12:13:29 <TrueBrain> ah, found where `REV_MAJOR` is used .. VSCode wasn't searching those files πŸ˜„
12:13:45 <Eddi|zuHause> <petern> Alternative fix to 10334 - return build date instead of last service date to newgrf. <-- how does that fix the underlying issue of newgrfs being able to crash the game?
12:13:59 <petern> Just this particular instance.
12:14:19 <petern> It's not a serious suggestion.
12:14:45 <DorpsGek> [OpenTTD/OpenTTD] TrueBrain commented on pull request #10719: Feature: opt-in survey when exiting a game
12:15:30 <TrueBrain> LordAro: sounds like a plan to do it in the CI; testing will be hardest ... good luck? (pro-tip: you can start a release-build from your fork by creating a tag against your commit)
12:17:17 <LordAro> mm
12:17:21 <LordAro> -DOPTION_USE_ASSERTS=$([ $IS_STABLE_TAG = '1' ] && echo "OFF" || echo "ON") \
12:17:25 <LordAro> too magic?
12:17:42 <TrueBrain> bash-ism πŸ˜›
12:18:28 <TrueBrain> `$(( if "${IS_STABLE_TAG}" -eq "1" ]; then echo "OFF"; else echo "ON"; fi ))`
12:18:32 <TrueBrain> bit less magic?
12:18:46 <TrueBrain> either way, please quote `IS_STABLE_TAG`, just in case it is empty for what-ever reason πŸ™‚
12:19:10 <TrueBrain> and yeah, my bash statement is broken, missing `[` and stuff πŸ˜›
12:20:14 <petern> Maybe it is better to just store capacity, then it doesn't matter about this thing, nor any other potential unhandled case.
12:21:06 <petern> Probably need to handle all variable properties if that is the way. I believe JGRPP does this.
12:21:17 <petern> I think I have an old branch for it :p
12:21:18 <Eddi|zuHause> i haven't really fully understood the problem, but it reads to me like improper caching, yes.
12:22:50 <petern> Hmm, 2021, not THAT old.
12:23:43 <Eddi|zuHause> if NewGRFs want to close the smoking compartments on tuesdays, it shouldn't be able to crash the game
12:23:49 <petern> I'll rebase and see what's missing. Immediately I see it only touches the *cache stuff, not cargo_cap.
12:27:23 <DorpsGek> [OpenTTD/OpenTTD] LordAro updated pull request #10722: Change: [CMake] Automatically disable asserts when building an actual release
12:27:23 *** WormnestAndroid has quit IRC (Read error: Connection reset by peer)
12:28:41 *** WormnestAndroid has joined #openttd
12:28:49 <TrueBrain> LordAro works quick
12:28:58 <LordAro> i should be eating lunch
12:29:05 <LordAro> actually, i should have eaten lunch
12:29:38 <petern> Oh cargo_cap is actually saved anyway, so no.
12:29:42 <LordAro> quite nice that you can just use bash for windows ci as well, was dreading having to rewrite that line in powershell
12:29:42 <TrueBrain> I assume you will test it on your fork LordAro? πŸ™‚
12:29:53 <petern> Different fix needed here.
12:29:56 <TrueBrain> LordAro: haha, yes, you and me both πŸ˜›
12:30:04 <LordAro> don't get such luxuries for gitlab
12:30:17 <LordAro> TrueBrain: you're going to make me, aren't you? i did already test the shell line itself...
12:30:32 <TrueBrain> Just a simple tag on your fork; couldn't be easier πŸ™‚
12:30:45 <TrueBrain> I have a lot of 99.9 releases on my fork over the years πŸ˜›
12:31:05 <TrueBrain> you can cancel it once you have seen the CMake do the right thing πŸ˜›
12:31:16 <petern> Hmm, and we already don't actually change the capacity if it's not allowed
12:32:18 <petern> I guess I need to try the savegame... later.
12:35:31 <DorpsGek> [OpenTTD/OpenTTD] TrueBrain updated pull request #10719: Feature: opt-in survey when exiting a game
12:36:12 <DorpsGek> [OpenTTD/OpenTTD] TrueBrain updated pull request #10719: Feature: opt-in survey when exiting a game
12:42:28 <DorpsGek> [OpenTTD/OpenTTD] TrueBrain opened pull request #10723: Change: [Actions] Use a custom name for matrix runs
12:42:32 <TrueBrain> been wanting to do ^^ for as long as I know that is possible πŸ˜„
12:43:04 <TrueBrain> does mean all current PRs won't pass CI after we merge it, but that is just a temporary issue πŸ˜„
12:46:17 <DorpsGek> [OpenTTD/OpenTTD] TrueBrain approved pull request #10722: Change: [CI] Automatically disable asserts when building a stable release
12:46:17 *** WormnestAndroid has quit IRC (Read error: Connection reset by peer)
12:46:46 <DorpsGek> [OpenTTD/OpenTTD] glx22 commented on pull request #10723: Change: [CI] Use a custom name for matrix runs
12:47:07 *** WormnestAndroid has joined #openttd
12:47:10 <DorpsGek> [OpenTTD/OpenTTD] TrueBrain updated pull request #10723: Change: [CI] Use a custom name for matrix runs
12:47:12 <TrueBrain> lol
12:47:13 <TrueBrain> CKANG
12:47:14 <TrueBrain> πŸ˜„
12:47:24 <glx[d]> and of course all the required checks won't pass
12:47:38 <TrueBrain> I can fix that πŸ™‚
12:48:02 <TrueBrain> it really is a lot better, the names like this πŸ˜„
12:49:39 <DorpsGek> [OpenTTD/OpenTTD] LordAro commented on pull request #10723: Change: [CI] Use a custom name for matrix runs
12:50:16 <DorpsGek> [OpenTTD/OpenTTD] TrueBrain updated pull request #10723: Change: [CI] Use a custom name for matrix runs
12:50:28 <TrueBrain> any more typos? πŸ˜›
12:51:43 <LordAro> TrueBrain: unrelated thought, could we perhaps build the macos jobs in parallel, then bundle them together post-build?
12:52:03 <TrueBrain> in theory, yes
12:52:11 <TrueBrain> just someone need to actually make that happen πŸ™‚
12:52:22 <DorpsGek> [OpenTTD/OpenTTD] glx22 commented on pull request #10722: Change: [CI] Automatically disable asserts when building a stable release
12:52:50 <LordAro> "cat: .ottdrev: No such file or directory"
12:52:51 <LordAro> bleh.
12:53:00 <LordAro> needs to be before build dir change, not after
12:53:25 <TrueBrain> and this is why we test πŸ˜„
12:53:36 <LordAro> such a novel idea
12:53:51 <TrueBrain> I know right!
12:55:13 <DorpsGek> [OpenTTD/OpenTTD] LordAro dismissed a review for pull request #10722: Change: [CI] Automatically disable asserts when building a stable release
12:55:16 <DorpsGek> [OpenTTD/OpenTTD] LordAro updated pull request #10722: Change: [CI] Automatically disable asserts when building a stable release
13:00:26 *** m3henry has joined #openttd
13:17:42 <orudge> LordAro: yes, in theory you could; I did look at that approach originally but it's a little more complex, as the two build processes aren't quite identical. If we want to try it, I can look at it again sometime.
13:19:26 <orudge> In other news, we seem to have received 4x the donation value in the first 4 months of this year compared to the same period last year. In fact, excluding 2021 which was higher, it's the highest since 2013, when we must have run a fundraiser.
13:20:28 <LordAro> neat
13:21:31 <orudge> We have overall been running at an annual loss since 2020 (due to now paying for AWS etc), but that's OK, as we still have funds for a year's expenses in the bank.
13:21:37 <orudge> Might need to run a fundraiser next year though :)
13:22:35 <TrueBrain> we finally seeing the bottom of this pit? About bloody time πŸ˜›
13:22:52 <orudge> Just about
13:24:00 <orudge> That said, we've had Β£830 of donations so far this year, and last year received a total of Β£872 donations all year, so if this trend continues, the money in the bank might last another 3 years :P
13:25:09 <DorpsGek> [OpenTTD/OpenTTD] orudge opened pull request #10724: Change: [Actions] Upgrade import-codesign-certs dependency in macOS build workflow
13:25:25 <TrueBrain> still amazes me, that without asking, people are this generous ..
13:25:39 <DorpsGek> [OpenTTD/OpenTTD] TrueBrain approved pull request #10724: Change: [Actions] Upgrade import-codesign-certs dependency in macOS build workflow
13:26:04 <LordAro> how much more generous were people in 2013 & 2021? :p
13:27:08 <orudge> We had a total of Β£2.2K in in 2021, and actually Β£2.2K in 2013 too
13:27:19 <petern> More big releases, but not too many to fatigue people πŸ˜‰
13:27:29 <orudge> Expenses in 2021 were Β£3.3K though, Β£3.2K last year
13:27:41 <orudge> Β£1.2K so far this year (but we prepaid Cloudflare for the year last month)
13:29:49 <orudge> The years like 2016 where we took in Β£1.1K but only spend Β£163, or 2011 where we only spent Β£75 (due to having a sponsored server from OVH) helped build up that balance
13:29:58 <orudge> but it is finally slowly depeleting
13:30:12 <TrueBrain> good; as it was getting a bit much πŸ˜„
13:30:27 <TrueBrain> after 14.0, I do hope to reduce the bill a bit, as than we can shift more to Cloudflare
13:30:35 <TrueBrain> but we will see how that goes πŸ™‚
13:33:12 <TrueBrain> seems at first I need to increase the balance a bit, with 5 dollar a month πŸ˜›
13:33:36 <TrueBrain> anyway, good to hear orudge; and I am still happy you are taking care of all of this πŸ™‚
13:36:48 <orudge> Sounds good
13:39:14 *** m3henry has quit IRC (Remote host closed the connection)
13:39:49 *** m3henry has joined #openttd
13:41:13 <petern>
13:41:13 <petern> Hmm, well that's a problem, not solved by anything to do with dates.
13:41:57 <TrueBrain> no capacity? Weird cargo-id? πŸ˜›
13:42:08 <petern> Weird cargo ID is why it crashes.
13:42:35 *** wao has joined #openttd
13:42:35 <wao> TallTyler: like the colors of the gray UI and stuff like that, maybe make it look more modern.
13:46:14 <petern> Easy to 'mod' the colours by changing source code.
13:46:37 *** nielsm has joined #openttd
13:47:20 <LordAro> hmm, mingw x86 failure
13:47:28 <LordAro> that shouldn't be anything to do with me...
13:47:54 *** m3henry has quit IRC (Ping timeout: 480 seconds)
13:52:58 <andythenorth> orudge: That’s very helpful to know, thanks πŸ™‚
13:53:32 <andythenorth> I think we could raise one-off funds easily if we needed to
13:54:28 <orudge> In the past folk have been very generous indeed (and still are)
13:54:39 <orudge> We certainly don't need anything just now, but will see how things are next year
13:57:43 <TrueBrain> and otherwise finally a reason to close shop? πŸ˜›
13:58:18 <TrueBrain> (bad joke, I know :D)
14:00:24 <orudge> I guess if I were to run away to the Bahamas with everything, I should have done it before we moved to AWS ;)
14:00:46 <TrueBrain> yes, bit late now πŸ™‚
14:10:53 <DorpsGek> [OpenTTD/OpenTTD] orudge merged pull request #10724: Change: [Actions] Upgrade import-codesign-certs dependency in macOS build workflow
14:14:32 <petern> Hmm, no, why is cargo_type wrong.
14:20:23 <wao> petern: I'll give it a shot ig, would be nice if something like that was added in game but yeah that works
14:24:37 <petern> Is it common for modern games to allow you change their interface colours?
14:26:23 <wao> i mean it depends but considering that open ttd has custom gfx the you can use it kind felt like you would be able to change that, maybe via the custom gfx
14:27:28 <LordAro> there are an awful lot of things with hardcoded colours
14:27:48 <LordAro> and that's to say nothing of trying to prevent people from making windows unreadable
14:28:37 <wao> LordAro: in openttd? or in everything like in general
14:30:22 <LordAro> well, i was talking about openttd specifically, but i imagine it applies in general too
14:36:40 <petern> "CSS" for nested widgets? πŸ˜„
14:38:08 <wao> LordAro: yeah
14:39:35 <LordAro> technically doable? sure. worth it? ehhh...
14:40:07 <TrueBrain> moving the GUI to WASM!
14:40:11 <TrueBrain> (I did look into that :P)
14:40:32 <pickpacket> TrueBrain, orudge: you talked about moving to CF. What are you moving there?
14:40:46 <petern> Hmm, cargo_type is only assigned during building a feature, or during refit. No NewGRF property can affect it. So cargo_type = 0xFF is weird.
14:46:25 <JGR> That likely indicates a locomotive with no cargo cargo
14:46:47 <petern> Its the wagons.
14:47:26 <dP> brake van?
14:48:00 <petern> Context is at 13:14 UTC.
14:48:25 <petern> Wrong time πŸ˜„
14:48:36 <petern> It's fron #10334.
14:54:52 <petern> Okay I mis-followed the flow.
14:56:27 <petern> So it's just the usual capacity < count issue. Hmm.
15:29:30 *** playback2396[m] has quit IRC ()
15:38:15 <petern>
15:38:15 <petern> One way to fix it :p
15:38:58 *** m3henry has joined #openttd
15:44:55 <m3henry> Can vehicle variants have different names?
15:48:01 <pickpacket> <-- The boats and the smaller part of the station on top of the hill are transferring cargo *to* the station for the trains at the 12-track part of the station to pick up. This is the best design I've been able to come up with, but the trains taking cargo just can't load and leave fast
15:48:01 <pickpacket> enough
15:48:14 <pickpacket> the available cargo just keeps rising
15:48:30 <TrueBrain> petern: Or just spill the cargo πŸ˜„ also: new disaster πŸ™‚
15:48:52 <m3henry> Actually pikka already answered that with Sunshine: yes
15:52:34 <petern> Yes, variants are basically completely separate engines, include name.
15:52:39 <m3henry> The follow on from that is then, Andythenorth: Would using variants to tidy up the variations on IH wagons in the buy menu be a reasonable idea?
15:52:55 <petern> He is using variants...
15:53:12 <m3henry> For engines and passenger/mail coaches
15:53:29 <petern> Variants basically exist for andythenorth.
15:56:18 <petern> TrueBrain: Yes, we could try just not deliberating asserting if newgrf makes it wrong.
15:57:29 <m3henry> I'm mentioning because the "Hopper, Rock Hopper, Mineral Wagon, Mineral Wagon, Mineral Wagon, Ore Dump wagon, Scrap Wagon, Hopper - Randomised, Mineral Wagon - Randomised & Bulk wagon - Randomised" all share the same stats, just differing in graphics.
15:57:53 <petern> Are you looking at Iron Horse 3?
15:57:56 <m3henry> yes
15:58:07 <petern> Then you know that it is using variants.
15:58:22 <m3henry> You seem to have missed my point?
15:58:28 <petern> So... using variants to tidy up variants is a bit of a thing to say πŸ™‚
15:59:08 <petern> Yes probably
15:59:54 <m3henry> The Engines, passenger wagons and such do indeed use variants to keep things tidy, however the freight wagons do not.
16:01:04 <petern> Ah, the released version, no.
16:01:38 <m3henry> Okay, so this is in a future version then.
16:02:14 <glx[d]> <-- using a prefilter to ignore sprite number and xpos/ypos, doesn't look too bad
16:03:40 <petern> All those action 0Ds though
16:04:05 <glx[d]> yeah nml is suboptimal πŸ™‚
16:09:20 <LordAro> what is 0D?
16:09:36 <glx[d]> `2842 * 8 05 97 FF 08 00 FF 00 00 ` <-- this obsession for extended bytes
16:10:32 <glx[d]> 0D is parameter stuff
16:12:20 *** gelignite has joined #openttd
16:18:26 <petern> Hmm, always expanding extended bytes?
16:19:27 <glx[d]> yes
16:19:47 <glx[d]> because it's "easier"
16:19:56 <glx[d]> I may change that
16:20:07 <Eddi|zuHause> someone didn't bother figuring out contracting extended bytes
16:21:01 <JGR> It's mainly to avoid making the action 6 offsets variable
16:22:20 <JGR> And in the big scheme of things saving 2 bytes is negligible compared to all the other overheads
16:22:44 <petern> Is action 6 still even used...
16:22:51 <glx[d]> a lot
16:22:58 <petern> Oh well.
16:23:53 <petern> Yeah, you'd need to somehow check that, and also check that the value won't go higher than 254 once applied. Hmm.
16:24:12 <petern> (Or just assume if action in 6 is in play that it will.
16:24:38 <JGR> You could just use the short form for when the value is a constant, which is the most common case
16:24:46 <glx[d]> but for some actions it should be fine
16:25:27 <dP> if you're counting every byte why even switch from nfo? 😜
16:25:29 <glx[d]> usually act6 is used on actD or varact2
16:26:38 <JGR> Writing directly in NFO will probably get you a smaller GRF file, but more likely than not it will be full of bugs
16:27:37 <glx[d]> the diff is not too bad, ~100 more sprites for openttd.grf and 38 more for orig_extra.grf
16:29:24 *** HerzogDeXtEr has joined #openttd
16:30:23 *** Flygon has joined #openttd
16:32:12 *** Wolf01 has joined #openttd
16:34:54 <glx[d]> <-- it's even doing useless stuff here
16:35:31 <glx[d]> oh no, now I see what it does
16:35:48 <glx[d]> it's crazy
16:36:24 <JGR> NML in general loves to output really long verbose sequences
16:36:53 <petern> What was the original intention of that block?
16:37:36 <petern> Oh it's the title πŸ™‚
16:39:01 <glx[d]> original grf was ```510 * 6 07 85 01 \70 3B F2
16:39:01 <glx[d]> 511 * 6 07 86 01 \70 04 F1```
16:46:22 <DorpsGek> [OpenTTD/OpenTTD] rubidium42 merged pull request #10718: Cleanup: remnants of OTTD_PRINTF, str_fmt and vseprintf
16:52:49 <glx[d]> also ```// param[127] = (param[131] & 255)
16:52:49 <glx[d]> 817 * 9 0D 7F \D& 83 FF \dx000000FF
16:52:49 <glx[d]> 818 * 9 09 7F 04 \7! \dx00000000 10``` vs ```804 * 6 07 83 01 \7! 00 5B```
16:54:39 <glx[d]> for a simple `if (climate == CLIMATE_TEMPERATE) {`
16:55:25 <glx[d]> and there are many of these
16:58:41 *** m3henry has quit IRC (Quit: m3henry)
16:59:56 *** m3henry has joined #openttd
17:00:32 *** m3henry has quit IRC ()
17:00:44 *** m3henry has joined #openttd
17:09:17 <DorpsGek> [OpenTTD/OpenTTD] rubidium42 updated pull request #10651: Change: Use cstdint instead of rolling our own types.
18:03:01 <DorpsGek> [OpenTTD/OpenTTD] TrueBrain approved pull request #10651: Change: Use cstdint instead of rolling our own types.
18:03:14 <TrueBrain> next up, replacing `byte` with `uint8`, or start replacing `uint8` with `uint8_t` when we touch code? πŸ˜›
18:03:53 <pickpacket> TrueBrain: what’s the difference between those last two?
18:04:02 <TrueBrain> `_t`
18:06:29 <pickpacket> πŸ˜›
18:07:20 <pickpacket> Does it matter if a ”byte” is a signed or unsigned 8-bit data type?
18:24:13 *** esselfe has quit IRC (Remote host closed the connection)
18:27:54 *** esselfe has joined #openttd
18:54:31 <glx[d]> You're not supposed to do math with bytes
18:59:25 <DorpsGek> [OpenTTD/OpenTTD] Kuhnovic updated pull request #10695: Fix #8177: Ships with max speed overflow to near-zero speed
19:11:29 <michi_cc[d]> TrueBrain: I've probably not read far enough yet, so this might be obsolete, but have you found `core\strong_typedef_type.hpp` yet?
19:13:39 <TrueBrain> in general I avoid `core/` as the plague, so no, I did not πŸ™‚
19:13:43 <TrueBrain> TallTyler: ^^ πŸ™‚
19:14:33 <TrueBrain> only `StrongIntegralTypedef` of that is used, and only once
19:14:34 <TrueBrain> lol
19:15:40 <michi_cc[d]> Yes, it was introduced to disamiguate TileIndex in the command overhaul.
19:16:12 <TrueBrain> well, seems we could use it too for Year / Month / Day πŸ™‚
19:16:27 <TrueBrain> bit of type-safety, especially when we have a Calendar Year and Economy Year, doesn't hurt anyone πŸ™‚
19:20:13 *** HerzogDeXtEr has quit IRC (Read error: Connection reset by peer)
19:35:30 *** gelignite has quit IRC (Quit: Stay safe!)
19:42:52 <glx[d]> hmm I have an issue with orig_extra.grf md5, md5sum output is different than what openttd computes
19:49:34 *** nielsm has quit IRC (Ping timeout: 480 seconds)
19:52:59 <FLHerne> grf md5s omit some part of the structure iirc
19:56:07 <glx[d]> indeed
20:01:03 <glx[d]> might be because nmlc uses grf format 2
20:03:40 <glx[d]> while the grfcodec command was defaulting to grf format 1 as it was not using -g
20:04:53 <glx[d]> that's annoying
20:05:57 *** Wormnest has joined #openttd
20:24:15 <glx[d]> ok found a way
20:58:49 <michi_cc[d]> Does NML accept action 5's (replacenew) with "invalid" sprite counts or unknown types? If not, doing changes that e.g. require new GUI sprites could get quite annoying.
21:05:36 <JGR> It depends which sprite block is being set
21:06:36 <JGR> Most of them accept a flexible number of sprites and/or a start offset, NML does support this
21:06:41 <petern> TrueBrain: Well I have a patch for that ..
21:09:02 <petern> michi_cc[d]: The tile/tileindex stuff seems to make it very hard to debug things
21:10:32 <DorpsGek> [OpenTTD/OpenTTD] glx22 opened pull request #10725: Codechange: [CMake] Switch GRF generation from NFO to NML
21:11:04 <glx[d]> NML accepts it, it just warns
21:12:06 <glx[d]> for unknown types it will error I think
21:12:44 <TrueBrain> I like the effort you took to avoid reviewing that Gentoo patch for grfcodec πŸ˜„
21:13:45 <petern> πŸ™‚
21:13:53 <glx[d]> grfcodec codestyle is a pain to read πŸ™‚
21:17:08 <petern> Very much so
21:18:03 <glx[d]> yeah trailing whitespaces, but only 2 nml files affected, not too bad considering the number
21:25:37 *** keikoz has quit IRC (Ping timeout: 480 seconds)
21:33:58 <DorpsGek> [OpenTTD/OpenTTD] glx22 updated pull request #10725: Codechange: [CMake] Switch GRF generation from NFO to NML
21:57:26 *** virtualrandomnumber has joined #openttd
21:57:58 *** virtualrandomnumber has quit IRC ()
21:58:31 *** nebulabc has quit IRC (Quit: must've rage quit Β―\_(ツ)_/Β―)
22:06:22 *** nebulabc has joined #openttd
22:26:56 *** Wolf01 has quit IRC (Quit: Once again the world is quick to bury me.)
22:42:46 *** WormnestAndroid has quit IRC (Remote host closed the connection)
22:45:26 *** WormnestAndroid has joined #openttd