IRC logs for #openttd on OFTC at 2023-04-26
β΄ go to previous day
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: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: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
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:28 <TrueBrain> you just know with Economy Date, people will make mistakes
07:30:33 <TrueBrain> and get some weird-ass dates π
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: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: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: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...
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: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: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:38:08 <LordAro> mingw these days is fairly sane
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:15 <TrueBrain> it is there since C++11
08:39:17 <TrueBrain> this code is from before π
08:40:48 *** peter1138 has quit IRC (Read error: Connection reset by peer)
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: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: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: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:21:01 <TrueBrain> another update to include some AIs
09:21:32 <TrueBrain> look at that, even mingw compiled
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: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: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: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: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: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:23:26 <TrueBrain> gnomechomsky: yeah; avoid it if you can π Why you ask?
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: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: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: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:14:02 <petern> It is yeah. Also should be separated from that PR anyway.
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: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: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: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: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:26 <TrueBrain> such useful changes π
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: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: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: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: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:43:12 <petern> LOL I even looked but wrote the wrong one π¦
11:44:10 <petern> I think it'll need more to fix the one case anyway.
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: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: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: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:48 <TrueBrain> I will make a PR π
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: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: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: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:28 <pickpacket> petern: any more resource friendly alternative? :P
11:58:50 <TrueBrain> RESOURCE FRIENDLY, he said
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: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: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: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: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: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: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: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:21 <LordAro> -DOPTION_USE_ASSERTS=$([ $IS_STABLE_TAG = '1' ] && echo "OFF" || echo "ON") \
12:18:28 <TrueBrain> `$(( if "${IS_STABLE_TAG}" -eq "1" ]; then echo "OFF"; else echo "ON"; fi ))`
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 *** 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: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 *** WormnestAndroid has quit IRC (Read error: Connection reset by peer)
12:47:07 *** WormnestAndroid has joined #openttd
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: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:11 <TrueBrain> just someone need to actually make that happen π
12:52:50 <LordAro> "cat: .ottdrev: No such file or directory"
12:53:00 <LordAro> needs to be before build dir change, not after
12:53:25 <TrueBrain> and this is why we test π
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: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: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:25 <TrueBrain> still amazes me, that without asking, people are this generous ..
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:39:14 *** m3henry has quit IRC (Remote host closed the connection)
13:39:49 *** m3henry has joined #openttd
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> 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: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: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: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:48:00 <petern> Context is at 13:14 UTC.
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:58 *** m3henry has joined #openttd
15:44:55 <m3henry> Can vehicle variants have different names?
15:48:01 <pickpacket> https://lounge.warmedal.se/uploads/4912eed8f7cce962/image.png <-- 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: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: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: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:03:40 <petern> All those action 0Ds though
16:04:05 <glx[d]> yeah nml is suboptimal π
16:09:36 <glx[d]> `2842 * 8 05 97 FF 08 00 FF 00 00 ` <-- this obsession for extended bytes
16:12:20 *** gelignite has joined #openttd
16:18:26 <petern> Hmm, always expanding extended bytes?
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: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:35:31 <glx[d]> oh no, now I see what it does
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: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:44 *** m3henry has joined #openttd
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: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
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:14:33 <TrueBrain> only `StrongIntegralTypedef` of that is used, and only once
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
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:05:57 *** Wormnest has joined #openttd
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: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:53 <glx[d]> grfcodec codestyle is a pain to read π
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: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
continue to next day β΅
