IRC logs for #openttd on OFTC at 2025-02-09
⏴ go to previous day
00:13:27 *** kuka_lie has quit IRC (Quit: Lost terminal)
00:22:14 <_glx_> I don't understand the `if (s == p)` block
00:25:57 <peter1138> That might be a left-over from later changes in my global parameters changes which add the concept of an empty parameter.
00:26:56 <_glx_> yeah probably for empty params
00:28:44 <_glx_> after more reading I see what is done, skip current RS and set `s`, look for next RS and set `p`, so the parameter data is between `s` and `p`
00:31:05 <peter1138> Hmm, and the game_script parameter is also unnecessary right now.
00:32:02 <_glx_> it is, as GS are only allowed to reference their strings
00:32:37 <peter1138> It's unnecessary because the path that calls it for non-gamescript strings doesn't exist yet.
00:33:29 <_glx_> there's still `if (game_script && id >= TAB_SIZE_GAMESCRIPT) {` near entry point
00:34:13 <_glx_> yeah it's not needed for now
00:41:22 <_glx_> `SCC_ENCODED_RESERVED` is not used either
00:46:45 <_glx_> but I know it will be used to split markers between GS and internal, and that way you skip another savegame conversion
00:47:46 <peter1138> Yes, these IDs need to be stable.
00:49:46 <yiffgirl> is there a vector [ie, math vector, not c++ vector] type in openttd?
00:51:25 <yiffgirl> i'm doing something to trees that needs vector maths
00:52:46 <yiffgirl> it'd be silly to make my own implementation if something already exists
00:53:23 <yiffgirl> oh you were talking to peter lol nvm
00:53:31 <peter1138> I read recently that the person who came up with the std::vector name regrets it because... yeah...
00:56:42 <_glx_> yiffgirl: no I was asking you, don't worry 🙂
00:57:04 <yiffgirl> peter1138: yeah, i'm working on something that obsoletes that pr.
00:57:25 <_glx_> anyway, there's probably existing libs for math vectors
00:57:46 <peter1138> I noticed since I fixed the over-population of trees on high maps that the diamond formations are noticable again (just like they were on lower maps.)
00:58:18 <peter1138> Probably but it depends what operations are needed. A generic one is likely to be full of non-integer map, maybe.
00:58:48 <_glx_> yeah that can be an issue
01:03:44 <yiffgirl> yiffgirl: here's the prototype, the idea is to generate tree groups inside these blob shapes instead of the diamond
01:24:28 <peter1138> Rebase time I guess.
01:54:15 <peter1138> (Still more splitting to do)
01:54:31 <peter1138> In fact I was starting to when I realised that encoded strings have problems.
02:29:42 *** gelignite is now known as Guest8512
02:29:45 *** gelignite has joined #openttd
02:37:04 *** Guest8512 has quit IRC (Ping timeout: 480 seconds)
02:53:38 *** Wormnest has quit IRC (Quit: Leaving)
03:53:31 *** Zathras has joined #openttd
03:56:39 *** D-HUND has quit IRC (Ping timeout: 480 seconds)
03:56:54 *** debdog has quit IRC (Ping timeout: 480 seconds)
04:40:53 <DorpsGek> - Update: Translations from eints (by translators)
07:05:49 *** HerzogDeXtEr has joined #openttd
08:09:23 <andythenorth> python @property methods are wrong, cheating, and show the class/module design is flawed?
08:42:59 * andythenorth probably just a reddit opinion
08:43:11 <andythenorth> oof failed at coffee
09:01:42 <_zephyris> All scripting is cheating, calculate it by hand
09:02:19 <_zephyris> Voronoi is annoying.
09:02:28 <_zephyris> Hard to debug Delaunay triangulation
09:03:39 <andythenorth> anyway apparently getter/setter is needless complexity and shows the decline of intellect in programming
09:03:56 <andythenorth> opinion -> ignore
09:04:26 <_zephyris> Probably something about being pythonic
09:05:23 <andythenorth> I was reading about Delaunay yesterday, but TBH, I get the principle, but couldn't implement 😛
09:07:07 <_zephyris> I'm thinking of rivers on centre to centre lines, mountain ridges on cell edges, tectonics
09:07:37 <andythenorth> I was thinking about voroni for trees after reading recent PRs
09:07:57 <_zephyris> Quicker way to make clusters?
09:12:55 <andythenorth> ok so voroni somewhat defines valleys
09:13:12 <andythenorth> or valley potentiality?
09:15:04 <_zephyris> I'm hoping mountain ridges can tend to be parallel to tectonic plate edges, leaving valleys
09:17:18 <_zephyris> Pipe dream, but lots of ideas
09:18:05 <_zephyris> Apalachians give a really nice real world example
09:25:32 <_zephyris> Hmm, need to remember some vector maths
09:30:43 *** kuka_lie has joined #openttd
09:34:22 <_zephyris> Allow endorheic basins?
09:37:29 <_zephyris> Does filling endorheic basins to the lowest exit point cheaply simulate erosion?
09:47:03 <truebrain> `squirrel_helper.hpp:105:25: error: missing 'typename' prior to dependent type name 'T::BaseType'`
09:47:09 <truebrain> did I break something, or is it already broken ...
09:48:09 <truebrain> no, master is broken 🙂
09:48:45 <truebrain> but CI uses same clang version as I do
09:49:59 <truebrain> how ... is that possible? Lol 😄
09:50:13 <Rubidium> not quite exactly the same version of clang?
09:50:23 <truebrain> major, minor and patch are the same
09:50:28 <truebrain> I sure hope that means it is the exact same 😛
09:50:34 <truebrain> especially given it uses the same Ubuntu base layer
09:51:59 <Rubidium> when using the same version with the same distro (version), then that's definitely odd
09:52:12 <truebrain> I also really do not understand the error itself
09:52:15 <truebrain> so that is not helping either 😄
09:52:23 <truebrain> something to do with `ConvertibleThroughBase`
09:54:30 <truebrain> ah, okay, some parts are compiled with clang 15 .. I guess this build-folder has become a bit odd 😛
09:55:54 <truebrain> okay, that was just really odd ... CMake reported 18, but the CMakeCache still said 15
10:13:41 *** nielsm has quit IRC (Ping timeout: 480 seconds)
10:23:30 <truebrain> why on earth is GitHub having such difficulty showing a proper diff of the compat files ... lol
10:24:40 <truebrain> owh, ofc, I also renamed them, and it isn't noticing that
10:33:31 <truebrain> added a commit for readability 🙂
10:33:41 *** reldred has quit IRC (Quit: User went offline on Discord a while ago)
10:34:31 <xarick> i used compat_15 for "extra stuff"
10:43:35 <truebrain> well, that was fun. My C++ is very rusty 😄
10:43:51 <truebrain> I should write more of it 😛
10:47:49 <truebrain> Rubidium: nice, tnx 🙂 I did look for a `constexpr` variant, but couldn't find it 😛
10:47:53 <peter1138[d]> Sorry, it was github being silly.
10:48:46 <truebrain> No worries; I noticed I found it hard to explain what the old code does, let alone what the new one does 😛 So I have been practicing explaining this PR, and I still find it difficult 😛
10:48:46 <peter1138[d]> I don't think splitting it into two commits is useful, as things won't work in the middle.
10:49:09 <truebrain> I wrote that the first commit is purely for review
10:49:12 <truebrain> it will be squashed
10:49:21 <truebrain> but it makes the second commit easier to read/validate
10:49:24 <peter1138[d]> Yeah but you can't expect other people (me) to read...
10:49:31 <truebrain> I tried to help you!
10:49:38 <truebrain> Just read the full diff 😛
10:49:41 <peter1138[d]> I should try to help myself.
10:49:52 <xarick> what if I have a script using version 15...
10:50:18 <xarick> where will my extras be put at?
10:53:07 <andythenorth> _zephyris: sounds like Lake Geneva 🙂
10:57:13 <xarick> let me actually test truebrain's stuff
11:00:48 <truebrain> `*std::prev(api_versions.end())` .. is there anything that isn't as ugly as that to find the last entry in an `initializer_list`?
11:02:33 <truebrain> owh, I can fix that differently
11:03:50 <Rubidium> or chicken out and use std::vector ;)
11:05:15 <truebrain> haha, I had the same thinking Rb 🙂 I will change them 😛
11:07:08 <truebrain> it works with `initializer_list`
11:07:18 <truebrain> but I can do either if you so like; I really can't remember the nuances of those structs anymore 😛
11:08:34 <peter1138> I kinda dislike having the list at all tbh. Another place to forget to change. But it's necessary with your change.
11:08:46 <truebrain> it was already necessary
11:09:03 <truebrain> and it has been part of our release instructions for many years 😛
11:12:32 <xarick> why am I on the ignore list
11:14:45 <peter1138> Right, I added more info in motivatio/description of #13499
11:15:42 <peter1138> My unit test is not ideal though, it almost needs a unit test to unit test it.
11:17:46 <peter1138> I did have the output strings as raw strings with \u codes embedded in it, but then I couldn't be sure I'd typed all the numbers correctly, and of course it then can't use the SCC_ constants.
11:18:48 <truebrain> run a fuzzer over it? 😄
11:19:35 <xarick> stupid reply as always
11:19:48 <xarick> it's impossible to argue against this guy
11:23:52 <truebrain> okay, enough bikeshedding from my side 😛 I forgot how I can spend ages on making the corners slightly more pretty 🙂
11:25:51 <Rubidium> well... you can put the 'new' constants in the XXInfo sheds ;)
11:26:32 <truebrain> You mean renaming `AI_API_VERSIONS` to `AIInfo::ApiVersions`?
11:27:08 <xarick> I prefer @Rubidium's approach
11:27:24 <xarick> but of course TrueBrain will have his way anyway...
11:28:44 <xarothbrook> Have you tried renaming yourself to "Marvin"? That usually helps.
11:29:15 <truebrain> Rubidium: much better 😄 I don't like YELLING IN VARIABLE NAMES 😄
11:31:44 <truebrain> peter1138: I guess that depends a bit .. but the current compat files do what you suggest. They upgrade from 0.7 all the way to 15.
11:32:05 <peter1138> No, they upgrade from 0.7 directly to 15.
11:32:16 <truebrain> That is what I said, not?
11:32:22 <truebrain> where do you read a difference?
11:32:48 <peter1138> "0.7 -> 15" vs "0.7 -> 1.0 -> 1.1 -> 1.2 -> xxx -> 14 -> 15"
11:32:58 <truebrain> but so hwo the current compat files are composed
11:33:05 <truebrain> they actually do 0.7 -> 1.0 -> 1.2 -> ...
11:33:11 <truebrain> that is why Rb started with the chaining thing
11:33:21 <truebrain> well, originally he did it with many if-statements
11:34:49 <michi_cc> xarick: You implement support for a `openttd.nut` and don't missuse compatibility scripts.
11:36:06 <truebrain> peter1138: that is basically what set this whole thing off, that when you add something to `compat_14.nut`, you copy/paste that same blob to all the other files, at the bottom. So in essence what we are doing, is first upgrading 0.7 to 1.0, then to 1.1, then to 1.2, etc. This PR just makes that more visible, in that sense
11:36:20 <truebrain> not saying that is the right approach btw; just indicating what (in my opinion :D) was already happening
11:36:46 <truebrain> from a development point of view that also makes the most sense to me. When you are making a breaking change, you only want to worry how to get version 14 to version 15
11:36:48 <peter1138> My point is that the the changes in the 0.7 are changing *from* 0.7
11:36:50 <truebrain> not how to get version 0.7 to version 15
11:37:31 <peter1138> They are not converting *to* 1.0, because we're on 15 :D
11:37:37 <xarick> I'll let the dust settle on this issue...
11:37:43 <truebrain> it used to be: `compat_14.nut` defines changes from 14 to latest. My PR redefines it to: `compat_14.nut` defines the changes from 13 to 14.
11:37:56 <peter1138> Yes, that's the bit I am disagreeing with.
11:38:24 <truebrain> Do you have a better suggestion? As in, is it a naming issue, or is it a fundemental: `compat_0.7` should upgrade itself to 15?
11:38:29 <peter1138> I'm not sure I am making sense even to myself.
11:38:47 <truebrain> But yes, it has to be stated: I totally redefine what `compat_NNN` is doing
11:39:00 <peter1138> compat_0.7.nut makes 0.7 files compatible with 15.
11:39:02 <truebrain> I make it more like AfterLoad, basically 😛
11:39:19 <peter1138> (Yes, it has to include all the other compat files along the way to do that.)
11:39:27 <truebrain> The current system does that, yes
11:39:42 <peter1138> With your change, compat_1.0.nut, makes 0.7 files compatible with 15.
11:40:04 <truebrain> My PR makes `compat_1.0` upgrade 0.7 to 1.0, and nothing else
11:40:12 <truebrain> it is unrelated to 15
11:40:22 <truebrain> once we branch, those files become read-only
11:40:24 <peter1138> We don't make it compatible to 1.0
11:40:41 <truebrain> we inject these compat scripts into the API
11:40:46 <truebrain> so they think they talk with 0.7
11:40:49 <truebrain> but actually they talk with 1.0
11:40:54 <truebrain> and after injecting 1.0 -> 1.1, etc
11:41:13 <truebrain> euh, `scripts into the API` -> `scripts into the AI`
11:41:36 <peter1138> Basically I agree with the game loading all the scripts sequentially. Just not the naming change because the naming change implies something that isn't really true.
11:41:49 <truebrain> what naming change do you refer to?
11:42:17 <truebrain> these are times I normally walk to someones desk, as that is easier than chat 😄
11:42:44 <peter1138> The "from 0.7" becomes "to 1.0" change.
11:43:28 <truebrain> so if I name `compat_1.0.nut` `compat_0.7.nut` it works for you? Is that what you mean?
11:44:24 <truebrain> (trying to figure out if it is the naming, or the content of the file, basically 😄 )
11:44:36 <peter1138> Basically yes. We are making 0.7 scripts compatible with 15. We are not interested in making 0.7 compatible 1.0, then compatible with 1.1 (because internal API changes don't work that way)
11:45:05 <truebrain> But to go from 0.7, we have to do something for version 1.0, 1.1, 1.2, etc, right?
11:46:12 <peter1138> No, a script for 0.7 is interested in API changes between 1.0 and 15.
11:46:41 <peter1138> But not for functions introduced between those versions. Lawks, confusing myself now :D
11:47:11 <truebrain> How we designed the system, a script designed for 0.7 will have access to the API of 15, it just doesn't know about it
11:47:15 <truebrain> as it was designed for 0.7
11:47:22 <truebrain> that is just an odd quirk in the way we designed this
11:47:36 <truebrain> we also don't protect nor validate for this, mind you
11:47:44 <truebrain> so you can just say you use 0.7, and use a function from 15
11:47:45 <truebrain> that will just work
11:48:52 <peter1138> I think I just think "from 0.7" makes more sense than "to 1.0"
11:49:02 <truebrain> It is "from 0.7 to 1.0"
11:49:10 <truebrain> from a development perspective, that makes a lot of sense btw
11:49:16 <truebrain> as it is now: "from 14 to 15" you only have to worry about
11:49:22 <truebrain> you do not have to care about any older version
11:49:27 <truebrain> as they are already 14 compatible at that point
11:49:50 <truebrain> "from 0.7 to 15", means it might be that you have to do something different then "from 14 to 15" .. it gets a bit muddy
11:50:00 <peter1138> Okay, well, basically I disagree.
11:50:24 <peter1138> truebrain, in fact, it is possible for an API to change, and then change again, so that the compatibility is different.
11:50:32 <peter1138> But I think we always tried to avoid that.
11:50:46 <truebrain> that would in theory be possible; we just never had that case in 10+ years now 😛
11:51:30 <peter1138> I'll leave it to others, I just prefer the from-naming instead of the to-naming.
11:52:07 <truebrain> With "from-naming" you mean "0.7 to 15", and with "to-naming" you mean "0.7 to 1.0", right?
11:52:26 *** SigHunter has joined #openttd
11:53:06 <peter1138> Open-ended tbh, so that "compat_0.7.nut" is for making 0.7 scripts compatible.
11:53:27 <truebrain> so you want one script where you can see all the things that are being fixed?
11:53:47 <truebrain> and it is now a concattenation of multiple scripts, basically?
11:54:01 <peter1138> No, absolutely not, that's what we already have. Just "compat_1.0.nut" being for 0.7 scripts is... confusing to me.
11:54:23 <peter1138> A 0.7 doesn't care that the next version is 1.0
11:54:53 <peter1138> Let's say, maybe the next version will actually be version 16, because 15 is a rude number.
11:55:18 <peter1138> Okay, nope, I've completely lost my train of thought on that one.
11:55:23 <truebrain> That is perfectly fine 😄 I guess a better name would be `scripts_older_than_1.0.nut` instead of `compat_1.0.nut` 🙂
11:55:26 <peter1138> I'm gonna go fix #13499 :)
11:55:51 <truebrain> And tnx for the conversation; I myself have a hard time making this clear, so I kinda appreciate the run-through 🙂
11:56:53 <truebrain> `This file contains fixes to the API for AIs going from version 0.7 to 1.0` is just poorly worded, looking back on this conversation. Let's see ..
11:57:06 <peter1138> My opinion: wait for frosch123 to barge in with his view which will almost certainly be correct and way above my pay-grade.
11:57:15 <truebrain> haha, you are not wrong 😄
11:59:45 <truebrain> `Inject API changes to keep AIs older than 1.1 compatible with the 1.1 API.` .. does that comment improve anything? 😄
12:00:13 <peter1138> No because we aren't making them compatible with the 1.1 API.
12:00:16 <frosch123> What? You expect people of my paygrade to read so much backlog?
12:00:22 <peter1138> We're making them compatible with the 15 API.
12:00:32 <truebrain> no no, that script really makes it compatible with the 1.1 API
12:00:37 <truebrain> a later scripts makes it compatible with 1.2 API
12:00:51 <truebrain> that script does not make it compatible with the 15 API
12:00:55 <peter1138> truebrain, they don't.
12:07:59 <frosch123> I wonder about looping the Api versions in the code. Does chaining the upgrades really work in all cases, or are there exceptions?
12:08:12 <truebrain> so far there never has been an exception
12:08:21 <truebrain> which kinda makes sense, as that would mean we really fucked up something hard 😛
12:08:36 <truebrain> (if a 13->15 migration can't go 13->14->15, something is really smelly)
12:09:49 <peter1138> Bah, I want an arpeggiator that leaves my root chord note alone :S
12:10:03 <frosch123> Don't you have to run them in reverse order?
12:10:47 <truebrain> we do 0.7->1.0->1.1->etc, already in the current scripts. Which, I guess, make sense. Going from old to new
12:11:05 <peter1138> If you are doing intermediate steps, yes.
12:11:10 <frosch123> If the api renames A -> B -> C. You can't define A as B, because it does not exist anymore
12:11:29 <truebrain> frosch123: as long as someone later defines B as C, it works fine
12:11:29 <peter1138> But our scripts have always jumped from old to current.
12:11:34 <truebrain> Squirrel isn't a compiled language 🙂
12:12:00 <peter1138> This is part of why I'm bike-shedding the name change :D
12:12:10 <frosch123> But it still executes from top to bottom
12:12:26 <truebrain> so far that has always worked
12:12:38 <truebrain> but that has to do with the way we write the code
12:12:55 <truebrain> `AITile.A <- function(tile)` is always valid
12:12:56 <peter1138> The compat_0.7.nut script doesn't make it compatible with 1.0, it makes it compatible with 15.
12:13:03 <truebrain> and if that calls `B()`, which is defined a bit lower, that is fine
12:13:32 <truebrain> so what we figured out, that all our compat scripts follow that order: 0.7 -> 1.0 -> 1.1 -> 1.2 -> ..
12:13:37 <peter1138> But, indeed, if the scripts are executed in reverse order, then it is possible to write the compat scripts in a way that would have been, if compatibility was always done that way, be compatible with intermediate versions too.
12:13:38 <truebrain> and that has worked, as it turns out 🙂
12:14:45 <peter1138> I'm trying to find an example in the API changes where it was change from one to another, and then later changed to something else.
12:15:28 <frosch123> There are also renames like GSBridge.GetBridgeID <- GSBridge.GetBridgeType;
12:17:47 <truebrain> yeah, so in those cases it would error out
12:18:18 <truebrain> the order of this execution has been another talk btw 😛
12:18:19 <peter1138> With the naming change, I'm going to try rephrasing it.
12:18:26 <peter1138> We are not making a 0.7 script compatible with 1.0
12:18:36 <peter1138> We are making the current API compatible with 0.7 scripts.
12:18:52 <truebrain> We inject code in the AI to make our API similar to what 0.7 is expecting, yes
12:19:07 <peter1138> Heheh twisting my phrasing against me :D
12:19:16 <truebrain> did I? Unintentionally
12:19:51 <peter1138> This is why I think the existing compat_0.7.nut naming for compatibility with 0.7 makes sense.
12:19:53 <truebrain> What weirds me out constantly about all this, that we inject code in the AI to do stuff 😄
12:20:00 <peter1138> We are making it compatible for 0.7
12:20:24 <peter1138> We aren't upgrading anything 1.0, then 1.1, then 1.2, etc.
12:20:32 <truebrain> okay, I think I finally understand your point 😄
12:20:37 <truebrain> took me long enough 😛
12:20:48 <truebrain> You are right, we change the API the AI is seeing
12:21:06 <truebrain> and although we haven't run into it, by accident it seems our current compat scripts work
12:21:13 <truebrain> but we indeed should reverse it
12:21:24 <peter1138> Also frosch's point of reversing the script load, 15 -> 14 -> 13, etc, makes that...
12:21:30 <truebrain> We should be downgrading our API
12:21:46 <truebrain> so compat_14.nut downgrades 15 -> 14
12:21:47 <peter1138> It's not by accident, it's because we have to change every compat file to make it match the current API.
12:22:02 <truebrain> well, by accident, as in, we haven't had a case where A -> B -> C happens
12:22:04 <peter1138> Precisely because there's no chaining.
12:22:12 <truebrain> as people just kept throwing their changes at the bottom of the file
12:22:22 <truebrain> so people were coding 13 -> 14 -> 15, in that sense
12:22:29 <peter1138> I'm convinved I'm pretty sure there's one case where an API change
12:22:48 <peter1138> I'm convinved there's one case where an API change was changed to a different change at some point. But I can't find it.
12:22:51 <peter1138> So I'm making it up.
12:23:06 <truebrain> or they worked around it in some other magically way
12:23:31 <truebrain> As this has been confusing us for the last hour+, so I am sure that whoever worked on it would be confused too 😄
12:23:34 <peter1138> Nah, what usually happens: It doesn't work, I'll work around it and not tell anyone.
12:23:49 <peter1138> "That's surely intentional"
12:23:59 <truebrain> okay, so if my PR would redefine: `compat_14.nut` downgrades API 15 to API 14
12:24:00 <truebrain> would that make sense to you?
12:24:10 <peter1138> A bit like "There's no API to do this, therefore it's just not possible"
12:24:30 <truebrain> (and so for 0.7 it would change all the files up to `compat_0.7.nut`)
12:25:43 <peter1138> You mean chain, not change?
12:25:57 <peter1138> Yes, chain all the files, in reverse.
12:26:00 <truebrain> as you put it: clearly written by a non-native speaker 😛
12:26:06 <truebrain> (refering to `Content downloading` :D)
12:26:10 <truebrain> it made me giggle so hard 😄
12:26:21 <truebrain> as you are absolutely write, it was clearly written by a non-native speaker 😛
12:27:07 <truebrain> anyway, we were right: frosch123 just makes a single statement and things are much more clear 😄 Reversing the list makes total sense, and it indeed makes things a lot more clear to explain too 🙂
12:27:55 <truebrain> `This file inject code to make the API downgrade from 1.0 to 0.7.` that works, right?
12:28:25 <xarick> OpenTTD the way I like! Spectator slot in single player + 15 AIs + variable max opcodes + league tables + slow valuate for no crashing
12:46:58 <truebrain> okay, that makes the description of the PR also far less painful 🙂
12:47:02 <truebrain> let me know if this is any beter peter 🙂
12:51:53 <truebrain> I like the removal of `compat_15.nut`. As we stated a few days ago, it is so weird to have `[0.7, 15]` in that folder 😄
12:52:35 <peter1138> Yeah, I was mistaken because I thought the API compatibility was invoked by scripts including the appropriate compat file.
12:52:49 <frosch123> When is it readded? Beta or branch?
12:52:51 <peter1138> (Which probably would have worked...)
12:53:01 <truebrain> frosch123: branch; when heading for 16, 15 is added, I would say
12:53:08 <truebrain> I need to update those docs 😄
12:53:19 <peter1138> Branch, we already have one beta 15 out.
12:53:29 <truebrain> owh, the docs are fine as it is
12:53:31 <peter1138> We probably forgot that we did, mind you.
12:53:36 <frosch123> Ok, so same time as before? Just delayed by one version
12:53:54 <truebrain> so we no longer ship an always-empty file with our releases 😄
12:55:29 <frosch123> I am sure there is some obscure VCS , which cannot deal with empty files, like others cannot deal with empty dirs
12:56:18 <peter1138> It's not actually empty, it just has a comment and nothing else.
12:56:51 <truebrain> peter1138: haha, true 🙂
12:57:27 <truebrain> tldr, for `std::span` we need C++26, it seems. But my understanding might be wrong.
12:59:05 <peter1138> We use std::span all over the place.
12:59:17 <truebrain> but not when converting from a `std::initializer_list` it seems
12:59:25 <peter1138> (Just make it's std::span<const ...>)
12:59:44 <frosch123> Does std::array work?
13:00:23 <truebrain> owh, `std::span<const ...` does the trick!
13:00:27 <truebrain> I tried so many variations of a span 😛
13:01:56 <truebrain> `const string_view` .. looks weird 😄
13:02:23 <truebrain> also why I didn't try it 😄
13:09:22 <truebrain> I like that when I now read `compat_14.nut` and see `AIBridge.GetBridgeID <- AIBridge.GetBridgeType;`, I understand what was in 14 and what was in 15 😛
13:14:07 <truebrain> should we also rename the button on the main menu from `Check Online Content` to just `Online Content`?
13:14:28 <peter1138> Hmm. Probably make sense.
13:15:27 <peter1138> We don't have e.g. "Change Settings"
13:15:52 <truebrain> it is also just a filler word, the `Check`. It doesn't add value
13:16:14 <truebrain> "Go To Highscore Table"
13:16:19 <truebrain> "Open Help & Manuals" 😛
13:28:34 <truebrain> it might fail utterly, but ... we will only find that out in production, I am afraid 😛
13:38:42 <truebrain> Rubidium: ugh, `INVALID_COMPANY`, ugh 😛
13:39:13 <truebrain> should we instead assert if the value is `Invalid` while running `ToCompanyID()` and friends?
13:39:18 <truebrain> or is that also pushing it for this PR?
13:40:47 *** gelignite is now known as Guest8568
13:40:50 *** gelignite has joined #openttd
13:41:44 <peter1138> Does #13504 need testing against a bunch of scripts?
13:42:39 <truebrain> peter1138: I tested it against all AIs I have on disk. But it could use some more eyes.
13:42:47 <truebrain> I especially tested 0.7 AIs
13:42:58 <truebrain> as I would reason they are the most likely to crash 😄
13:47:06 *** Guest8568 has quit IRC (Ping timeout: 480 seconds)
13:49:11 <truebrain> Rubidium: about #13402, ELI5: why is `PoolID` not a `StrongTypeDef`, but its own custom strong type def? (mostly curious, for my own understanding)
13:52:54 <Rubidium> truebrain: because StrongTypedef default initializes, or in laymans terms: *all* PoolItem::index will be 0 as we set them before the constructor of the PoolItem is run, and with default initialisation the constructor will make it a nice zero
13:53:50 <truebrain> and I guess that is not something we want to address in the StrongTypedef? 🙂
13:55:08 <truebrain> one more question: is `End()` suppose to be inclusive or exclusive? As in, is `End()` a valid ID to use or not?
13:55:35 <Rubidium> exclusive, just like std::end
13:56:23 <truebrain> I am very happy you put this in multiple commits 🙂
13:57:01 <truebrain> lol @ OrderBackup .. I guess your PR also fixes bugs 😛 (it allowed for the ID to be 256 it seems, while the type is `uint8_t` :D)
13:58:36 <Rubidium> pff... I just got scared that my 'work: needs rebase' PR messed things up. Everything seemed to be 'work: needs rebase', but I had it sorted on most recently changed. So they were all old PRs that came up
13:58:57 <truebrain> works as intended 😄
13:59:08 <truebrain> I forgot that changing the label also causes that
13:59:17 <truebrain> that might annoy you really quick
14:02:23 <truebrain> guess this is also the beginning of removing `INVALID_NNN` stuff? As it can now be deduced from the type?
14:02:27 <truebrain> that would be such a happy day 🙂
14:02:51 <Rubidium> yes, but that'll be a mass rename PR once everything's done :D
14:03:16 <truebrain> also curious we have so many differences between `End` and `Invalid` that are really small ..
14:04:59 <truebrain> 74 `needs rebase` PRs 😄
14:05:04 <Rubidium> probably because 64k seems nicer in a developer's eyes? And it allows you some leeway to add magic numbers, like GroupID has
14:05:32 <truebrain> kinda want to make the "needs rebase" label look a bit different from the other "work" labels
14:06:20 <Rubidium> although 65280 (0xFF00) would probably leave you with enough spare magic numbers
14:06:36 <truebrain> okay, are there more PRs I dare to review ...
14:07:59 <truebrain> `while (Utf8StringLength(x) > limit) removeOneUtf8CharFromBack(x))` .. wauw .. yes, that is also a special way of doing that 😄
14:08:58 <LordAro> 64k ought to be enough for anybody
14:09:21 <truebrain> Rubidium: I didn't want to fully bias my reviews towards you! Peter also has nice PRs! 😛 😛
14:10:06 <peter1138> Rubidium's need more attention because he's better at reviewing mine than I am at reviewing his.
14:10:55 <yiffgirl> hm, my blobs seem to only be generating a single quarter. that's a puzzle.
14:11:11 <truebrain> That sentence is a puzzle too 😄
14:13:40 <peter1138> Hmm, so the font gamma thing only appears to really be an issue with OpenTTD Sans.
14:14:04 <peter1138> Which suggests it's not something we should tweak in code, but I have no idea how/if it's possible to tweak the font itself.
14:15:00 <xarick> I got 6 work: needs rebases
14:15:19 <xarick> surprised it's not more
14:15:36 <truebrain> ask the creator of OpenTTD Sans? 😄
14:18:24 <peter1138> Yeah, he was hoping the font-gamma stuff would fix it.
14:18:32 <peter1138> But I think it's a hack.
14:19:05 <peter1138> (Especially as it would need to be per font)
14:22:04 <truebrain> that are all the PRs from you I dare to review Rubidium. The rest hurt my head too much 😦 Not your fault btw 🙂
14:22:32 <LordAro> truebrain: how about all the other PRs? :p
14:22:37 <peter1138> Some of it is working out which PR is at the bottom of the dependency chain.
14:32:02 <truebrain> okay, #13462 is cool
14:33:47 <Rubidium> wow... it's a really productive afternoon today!
14:34:30 <LordAro> still got 127 open PRs :p
14:34:43 <truebrain> and who's fault is that?!
14:34:45 <LordAro> 7 bits of PRs, if you will
14:36:01 <truebrain> #13467 feels a bit weird, but I can't put my finger on it ..
14:36:26 <LordAro> it's fixing a problem that only exists for whatever they're doing
14:37:00 <LordAro> due to whatever other changes they're making *
14:37:35 <truebrain> That might describe the tingling sensation I have 😛
14:37:56 <xarick> the number of CTests increased to 72
14:41:21 <peter1138> Damn, working out which script compat changes should actually be in which file looks complex
14:42:12 <truebrain> bah, LordAro beat me to it 😛 Fine 🙂
14:42:13 <peter1138> I mean you've done the hard work :)
14:42:34 <truebrain> owh, that was simple: just remove from compat_0.7 what was in compat_0.9, etc 😛
14:42:43 <truebrain> but doing it is easier than reviewing it
14:42:55 <peter1138> Yeah, that's probably the case.
14:45:12 <peter1138> Hmm, "Unhandled event"
14:46:36 <peter1138> Okay, that happens already :D
14:47:03 <truebrain> AIs tend to produce a lot of errors, sadly 🙂 Even on the version they were created for 😛
14:47:35 <LordAro> maybe we should do a Windows and add compatibility for individual AIs :p
14:47:49 <truebrain> Will you be the maintainer of that project? 😄
14:48:15 <peter1138> The cargo class changes made me wonder about doing that for NewGRFs.
14:48:23 <LordAro> i don't think there's /many/ distinct issues
14:49:07 <peter1138> I like how lots of the files are basically empty now :)
14:49:23 <truebrain> and tnx peter1138 🙂
14:50:20 <xarick> merging 13504 will be conflicting with about 20 of mine
14:50:58 <LordAro> it do be like that sometimes
14:51:01 <peter1138> It will make script changes much easier to implement.
14:56:05 <peter1138> 310/598. I need more cores.
14:59:16 <Rubidium> peter1138, I hope that isn't your branchcount increasing... it was at around 500 a few weeks ago, wasn't it?
15:00:06 <LordAro> the goal isn't to have as many branches as compilation units :p
15:01:24 <peter1138> Cool, the EncodedString stuff is now safer :D
15:01:49 <truebrain> `Allow manually building town houses: None` .. that wording really tripped me off 😛
15:02:15 <truebrain> I do like the feature itself .. I should have put that in the PR 🙂
15:06:41 <_glx_> Nice, now I'll be able to do compat stuff for ScriptDate
15:07:14 <_glx_> (I did wait to not have to redo it multiple times)
15:09:40 <truebrain> Rubidium: talking about labels, what I always miss, is that I can see which PRs I gave a review, but haven't seen an update yet
15:09:53 <truebrain> as those are more likely to not be important to look at again 😄
15:14:09 <peter1138> Oh, massive list of template errors with Windows on #13285 now :S
15:15:13 <truebrain> Drop Windows, you say?
15:15:36 <truebrain> so I have been willing to clean up our includes a bit for a while now ... but how do we want our includes to be?
15:15:41 <truebrain> should a header be able to compile on its own?
15:15:55 <truebrain> or should they be mostly without includes, and let the implementation file get the right headers?
15:16:19 <truebrain> `stdafx.h` are in no header, but many do need it, as an example of why I ask
15:16:28 *** Wormnest has joined #openttd
15:16:52 <Rubidium> truebrain: maybe with 'request changes' you can see that when changes have been made?
15:17:16 <LordAro> truebrain: if headers are not able to compile on their own things become a lot more order dependent in the cpp files
15:17:19 <truebrain> Rubidium: sadly, you cannot. At least, I never found out how. It just stays as "request changes" till the person asking the change has removed the flag or approved it
15:17:40 <truebrain> LordAro: with the exception of `stdafx.h` or something?
15:27:27 <truebrain> I am not the only one that has this ... urge 😛
15:30:36 <LordAro> truebrain: now i'm playing with clang-format to see if i can get it to sort includes and not do anything else
15:33:32 <peter1138> Oh yes, headers should include the things they need, otherwise it's a pain. Refactoring tools don't like it, etc.
15:34:07 <truebrain> turns out this was an issue at Google too
15:34:11 <truebrain> which created the tool I just linked 😄
15:34:14 <frosch123> An easy way to check whether headers are self contained, is to put them first in associated cpp file
15:35:05 <frosch123> So order_cmd.cpp should include at front: stdafx, order_type, order_base
15:35:44 <truebrain> that is one step. The other is to minimize the includes in header-files
15:35:51 <truebrain> we tend to include things that are .. not the right includes
15:35:57 <truebrain> but just because it includes somewhere down the stream the right one
15:36:00 <truebrain> it magically works 😛
15:37:31 <LordAro> seems the answer is 'no'
15:37:43 <LordAro> i did get include sorting working though
15:37:43 <truebrain> ```../src/openttd.h should remove these lines:
15:37:43 <truebrain> - #include <chrono> // lines 14-14```
15:37:56 <peter1138> Ah, I think these errors are "std::string_view::iterator is char *" with clang, but not with MSVC.
15:38:27 <truebrain> wow, that tool is pretty ... clear, in what should be where
15:39:35 <truebrain> it is a very strong opinion 😄
15:40:25 <peter1138> Yeah, part of it is working out if what's in header files need to be adjusted too.
15:41:01 <peter1138> (And I guess the tool ignores stdafx.h)
15:41:09 <truebrain> this tool seems to do exactly that too. It actually understands code, basically. It hooks into clang 🙂
15:41:11 <talltyler> Ugh, new computer doesn’t like interactive rebase. My path to Notepad++ is giving a “bad address” error 😦
15:42:09 <peter1138> Okay, what did I do wrong with 13509... I'm sure it compiled here :S
15:42:49 <truebrain> talltyler: "bad address" sounds really scary 😛
15:43:36 <frosch123> truebrain: Be careful around the SSE blitters. They use macros to modify include files
15:43:50 <truebrain> Yeah, and we also have #ifdefs etc
15:46:26 <peter1138> Did Rb's BitSet .Any() / .None() get merged yet?
15:48:19 <truebrain> hmm, seems that tool has no way of understanding what our `stdafx.h` is about 🙂
15:49:06 <truebrain> ah, no, more to the point, we never include stdlib.h or assert.h 😄
15:49:26 <Rubidium> we likely include cassert/cstdlib
15:50:06 <Rubidium> and I'm seeing quite some risks with including bits/ and sys/
15:51:16 <truebrain> okay, got him to understand stdafx.h as such; just it doesn't put it on top of the list. I cannot blame it for not doing that 😄
15:53:31 <peter1138> Apparently I just hadn't finished it. Oops.
15:53:51 <xarick> I have conflicting PRs of my own
15:54:03 <truebrain> and the reviewer clearly also didn't notice! Not sure what is worse 😄
15:54:15 <peter1138> A rare case of committing instead of stashing leading to problems.
15:54:24 <peter1138> truebrain, you wouldn't know (until the CI finished)
15:54:59 <truebrain> what is the most difficult thing to check for with `Test`, whether it should negate or not
15:56:24 <peter1138> Yes -- but also that is one of the reasons for doing it, because these raw masks are hard to read.
15:59:04 <peter1138> Yeah, tbh, the mix of masking and direct comparisons for this one has got me all mixed up here.
15:59:12 <peter1138> Like, that's the code, but the's the *intention*
15:59:26 <truebrain> it is really confusing to read 😄
15:59:35 <truebrain> but except for the last comment,it also doesn't seem to be broken
15:59:42 <truebrain> so feel free to postpone that to when-ever 😛
16:00:01 <peter1138> Well, I'm glad I'm testing you :D
16:00:07 <peter1138> But I wish I wasn't.
16:00:34 <truebrain> these changes are so difficult .. your eyes spin really quick 🙂 That is why we do reviews 🙂
16:03:17 <peter1138> Yeah, some of these seem like "lazy tests"
16:04:25 <peter1138> == Palette really means something like ".Test(Palette) && !.Test(RGB)"
16:06:08 <truebrain> that is fine for now, but I wanted to be sure 😛
16:07:21 <peter1138> No, it's good, *I'm* trying to be sure :)
16:07:52 <truebrain> E_CODE_TOO_CONFUSING
16:08:20 <peter1138> So "!= Palette" means it could have Palette set, just not by itself.
16:16:07 <peter1138> These equality tests would also break if more flags are added.
16:20:19 <peter1138> Right, so RGB and Palette are not exclusive, e.g. 32bpp sprites with company colour.
16:21:17 <ahyangyi> And palette with alpha also works?
16:21:50 <truebrain> I think none of the code should read `==` or `!=` when it is a BitSet. But I doubt we can overload the operator to `= delete` to show when that breaks 😛
16:21:58 <ahyangyi> I'm currently using such a combination, though I'm not sure if grf-py secretly fixes it up
16:22:06 <ahyangyi> anyways the combo seems to work
16:23:07 <peter1138> truebrain, I'll... have a look :)
16:23:24 <truebrain> SIDE QUEST UNLOCKED 🙂
16:23:42 <talltyler> Okay, so how do I properly use enum class in settings? I'm trying to copy #13429, but blindly copying isn't working without understanding what I'm doing. 🙂
16:23:55 <talltyler> (Still getting errors, probably missing something)
16:23:57 <LordAro> pretty sure you can do `= delete` on operators
16:24:11 <peter1138> bool operator ==(const EnumType other) = delete;
16:24:12 <truebrain> that was not in question LordAro 🙂
16:24:25 <truebrain> whether that doesn't give thousands of more issues .... is 😛
16:24:41 <LordAro> i've come to the conclusion that clang-format is a buggy mess
16:25:03 <LordAro> for some reason all /* */ comments are getting all indentation removed
16:25:11 <peter1138> There's a reason I turned off its header-autoformatter.
16:25:19 <truebrain> there are one too many settings 🙂
16:25:29 <truebrain> and often the settings are .. weirdly described 😛
16:25:49 <LordAro> i've looked at every setting that mentions 'comment'
16:25:50 <talltyler> Are you talking about clang-format or OpenTTD? 😛
16:25:58 <peter1138> Erm, clang, you are drunk.
16:26:18 <peter1138> if (end_segment_reason != EndSegmentReasons{}) { ---> no known conversion from 'EndSegmentReasons' (aka 'EnumBitSet<EndSegmentReason, unsigned short>') to 'const EnumType' (aka 'const EndSegmentReason') for 1st argument
16:26:46 <peter1138> Both sides are EndSegmentReasons...
16:28:54 <LordAro> ah there we go, clang-format-19 doesn't do silly things with comments
16:32:20 <talltyler> peter1138: Does enum class work in settings, besides your setting flags? I'm just getting errors.
16:34:23 <talltyler> I'm not sure I'm reading the error properly, but it seems that the `SDT_VAR` macro is choking on it with `'<function-style-cast>': cannot convert from 'initializer list' to 'SettingVariant'`
16:34:42 <talltyler> (the error is in `settings.h`, which is generated)
16:35:30 <talltyler> I've run into this before, so unless you've made it possible recently...
16:36:01 <talltyler> I know setting flags are enum class now, but those are handled slightly differently it seems
16:36:02 <peter1138> The settings stuff is all (u)int32_t internally.
16:36:24 <peter1138> We handle x.base(), but enums need to_underlying(x) instead.
16:37:03 <peter1138> Okay, I can delete `== EnumType` as long as I add `== EnumBitSet`
16:37:22 <truebrain> might be worth it, to prevent issues like this PR shows
16:37:22 <peter1138> The presence of `<=> EnumBitSet` isn't enough.
16:37:28 <truebrain> where the code just becomes unclear in its intentions
16:38:46 <talltyler> All the enums I'm seeing in `settings_type.h` are values, not bit flags
16:38:52 <talltyler> If that makes a difference
16:39:06 <talltyler> You are talking above my level of understanding 🙂
16:41:06 <truebrain> did you also test it? 😛
16:41:12 <yiffgirl> oh my god, i'm a fool.
16:41:12 <yiffgirl> `M_PI_2` isn't pi times 2.
16:41:27 <truebrain> yiffgirl: lol. That is evil 😄
16:42:03 <peter1138> truebrain, I compiled it, that's the same thing yes? ;D
16:42:16 <truebrain> also please check if it actually works 😛 😛 Silly goose 🙂
16:42:23 <peter1138> (It's still compiling here because I rebased to reorder things)
16:42:24 <truebrain> code-wise it looks good to me at least
16:42:25 <ahyangyi> I am also annoyed by the definition `τ = 2π`.
16:42:40 <ahyangyi> The shapes of the Greek letters doesn't agree with it.
16:42:59 <ahyangyi> Looks like `2τ = π` makes more sense for the shapes.
16:43:10 <peter1138> lol, it fails later one :(
16:44:30 <talltyler> Yes, good wording 🙂
16:45:24 <peter1138> Sod it, I'm going to do the simple one first. Ensure it compiles.
16:45:33 <peter1138> And then fiddle about with the equality tests later.
16:45:38 <truebrain> talltyler: I did a ninja edit, and also added "Manual" in front of the sentence 😛
16:45:42 <truebrain> not sure that is a good change 🙂
16:46:08 <truebrain> I thought maybe otherwise people might get confused that there won't be any town house placements or something silly
16:46:19 <talltyler> I think "manual" is unneccesary, how would a player place something automatically
16:46:50 <talltyler> I think "placing individual houses" makes sense
16:47:00 <truebrain> Then keep it the way it is 😄
16:47:11 <talltyler> Done, I already closed VS and am headed to the grocery store 🙂
16:47:37 <truebrain> but yeah, this wording makes the PR easier to read for sure 🙂
16:47:49 <talltyler> Will rebase #13270 when I get home, but feel free to review that if you're inspired 😛
16:49:38 <truebrain> it looks good; one more question, but otherwise I am fine with it 🙂
16:50:19 <truebrain> funny, this include-optimize-tool rather has `struct Rect` than including the header-file
16:50:25 <truebrain> it does safe on compile-time
16:53:26 <yiffgirl> TrueBrainviaGitHub: misread this as placing horses. i must be tired.
16:53:44 <truebrain> Placing horses would be fun too 🙂
16:54:51 <peter1138> Okay, this patch does not break zBase... unfortunately.
16:55:56 <peter1138> Crap, I meant to self-review again.
16:57:04 <peter1138> Okay, looks better to me.
16:58:48 <truebrain> so our include-path is a bit weird
16:58:58 <truebrain> it allows for both `#include "../blitter/factory.hpp"` and `#include "blitter/factory.hpp"`
16:59:07 <truebrain> as the `src` is in the path too
16:59:23 <peter1138> Yes, this has bugged me too :)
16:59:51 <truebrain> so we can pick .. do we want ".." or do we want no ".." 😛
17:00:15 <peter1138> I prefer the path to make sense. We do .. in most places where it's needed.
17:00:37 <truebrain> I agree. so we should basically remove "src" from the include path
17:00:44 <truebrain> as that would force that 😄
17:01:58 <truebrain> okay, only thing I don't like, is that this tool also resolves `<SDL.h>` into the ton of smaller includes behind it
17:02:02 <truebrain> I don't care for that
17:02:26 <peter1138> No option to treat <> differently from ""?
17:02:37 <truebrain> haven't found it yet
17:02:40 <truebrain> doesn't mean it isn't there 😄
17:03:14 <xarick> okay let's see if I understand the new compat stuff
17:03:34 <peter1138> And, getting ahead of ourselves here: is there a way to make a CI job of it to prevent adding code that needs to be cleaned up later...
17:04:55 <xarick> ScriptBaseStation didn't exist in 0.7, only from 1.0 onwards. I have a compatibility function that changes something related to ScriptBaseStation in 15. Where do I put this function?
17:05:06 <truebrain> that is what this tool allows
17:05:12 <truebrain> the tricky part is, it hooks into clang
17:05:19 <truebrain> and it requires the correct defines etc
17:05:28 <truebrain> so we need to run it for all 3 platforms to get an accurate view of them
17:05:35 <truebrain> so I am not sure this can actually work, with all our defines 😛
17:06:41 <peter1138> Ah, each set will have a different result of headers, yeah.
17:11:44 <xarick> I can't quite point the finger, but something feels wrong
17:12:13 <xarick> 0.7 should have no access to this compat
17:13:19 <peter1138> I understand your logic, but to follow that same logic, we should prevent scripts using 0.7 compatibility from accessing ALL API that was added after it.
17:13:24 <peter1138> And we have never done that.
17:14:26 <peter1138> And I suspect that doing that would break plenty of scripts that started using newer API calls without updating their compatibility level.
17:15:44 <xarick> ```AIBaseStation.IsValidBaseStation <- function(station_id)
17:15:44 <xarick> return AIStation.IsValidStation(station_id) || AIWaypoint.IsValidWaypoint(station_id);
17:15:44 <xarick> is this is even going to compile? I guess it will
17:16:08 <xarick> we're currently in a version that has AIBaseStation
17:16:30 <xarick> 0.7 compat or not, guess it won't matter
17:22:50 <truebrain> okay ... it seems I can fix most oddities with this tool relatively easy .. now to find out a way how to deal with the ifdefs 😄
18:14:43 <talltyler> For anyone wondering, the "needs rebase" bot seems to remove the label properly 🙂
18:15:08 <talltyler> I have not read enough scrollback to know if that was still a question
18:16:08 <truebrain> tnx for addressing all my concerns 🙂 It makes it for me at least easier to understand feature 😄
18:16:24 <truebrain> I didn't actually test it btw; I assumed you did 😛
18:18:40 <talltyler> Thanks for the reviews! 😄
18:20:59 <truebrain> that was less painful than anticipated
18:23:50 <peter1138> macos ruins it again.
18:28:33 <yiffgirl> solitary trees disabled for demonstration purposes
18:29:52 <xarick> yiffgirl: oh, you're the tree guy with 2 PR's?
18:33:19 <truebrain> This time it was Windows 😛
18:34:07 <Rubidium> next time just wait a few minutes for at least one compile of each target has run :D
18:34:28 <truebrain> no, I expect this time you already approve it Rubidium, just so it can fail on ... MSYS! 😛
18:34:29 <peter1138> Someone else should approve it on the third time.
18:37:52 <peter1138> Two non-refactoring merges in a day?!
18:38:42 <peter1138> Still, nobody can complain about refactors that make things better.
18:40:06 <andythenorth> my diff of nml output against the non-refactored branch is .... worrying 😛
18:40:11 <peter1138> I guess we could argue about names instead?
18:40:19 <truebrain> really avoid `protect` as variablename talltyler 😄 It reads really odd in C++ 😛
18:40:19 <andythenorth> didn't we win that game?
18:40:24 <andythenorth> you said we had no credits left
18:43:23 <peter1138> > (yes, dest_tile is IndustryID here)
18:43:30 <peter1138> The comment knew what I was thinking.
18:44:49 * peter1138 checks up on the latest kernel drama.
18:45:03 <truebrain> still people bla-bla-ing about Rust?
18:45:35 <johnfranklin> What is on earth Rust?
18:46:38 <peter1138> They mostly moved on to how the email-based workflow is a pain, or something.
18:47:11 <talltyler> Yeah, “protected” is the word in GRF spec, but every form of it is a special word to computers 😛
18:47:25 <truebrain> so avoid it like the plague in variable names etc 😛
18:47:39 <truebrain> we had the same conversation with `completed`, or what did you use in the other PR 😛
18:47:39 <xarick> hmm rubidium made some ScriptCompany changes that left me confused
18:47:55 <talltyler> Oh that’s what you meant
18:48:17 <talltyler> So `house_protected` would be okay?
18:48:54 <truebrain> at least it is more descriptive
18:49:20 <truebrain> personally I like things like `is_protected` more
18:51:09 <truebrain> owh, the NewGRF stuff also calls it that
18:51:23 <truebrain> so yeah, I would go with `is_protected`, or even `building_is_protected`, but that might be a bit lengthy 😛
18:52:16 <xarick> `::CompanyID ScriptObject::GetCompany()`
18:55:58 <frosch123> johnfranklin: The most influential programming language of this decade
18:56:51 <talltyler> It is weird, you are correct
18:57:04 <andythenorth> are we porting to Rust yet? 😛
18:57:20 <truebrain> so I would suggest to either get that PR fixed up and in first, or comment there to change the strings you introduce, or something 😛
18:58:01 <talltyler> I think just not mentioning AIs would probably be fine
18:58:24 <talltyler> The main point is to prevent towns from upgrading the houses
19:01:56 <truebrain> debugging via CI, as, why not!
19:02:53 <peter1138> Well, at least it's not just me...
19:02:53 <LordAro> andythenorth: you first
19:04:37 *** kuka_lie has quit IRC (Quit: leaving)
19:08:42 <johnfranklin> frosch123: it seems to be new stuff, but in my stereotype, newer stuff are more likely to be less geek, less free, and higher device requirement
19:33:27 <andythenorth> I remember how much the perl people hated python
19:33:31 <andythenorth> and the VB people
19:33:44 <andythenorth> and the shell pipe people
19:34:35 <talltyler> Somebody made a boo-boo today 😛
19:37:37 <peter1138> Any attempt to bisect?
19:38:02 <talltyler> Not by me, I have chores to do 🙂
19:39:03 <talltyler> Maybe something related to the company changes?
19:39:09 <yiffgirl> i rebased on master and suddenly am getting a billion compile errors in places i never even touched
19:40:26 <peter1138> What compiler & version?
19:43:15 <yiffgirl> how do i check? i see msbuild in the terminal output.
19:43:15 <yiffgirl> i've been doing `cmake --build .` in `/build`
19:44:23 <truebrain> talltyler: town_can_upgrade, that is lovely descriptive, nice 🙂
19:44:35 <talltyler> Your wording inspired me, thanks for that 🙂
19:47:53 <talltyler> I thought I found all the question marks, oops
19:47:55 *** Flygon has quit IRC (Read error: Connection reset by peer)
19:49:10 <xarick> rebasing this final PR is complicated
19:49:17 <talltyler> lol, couldn't find the question mark text... because I still had master checked out
19:51:41 <peter1138> That's used quite a bit :o
19:52:38 <peter1138> Sadly std::numeric_limits has an annoying "feature" where by it returns 0 if it's not supported. Instead of just, you know, failing to compile.
19:56:35 <talltyler> Hmm, I should edit PR title too 🙂
20:06:40 <truebrain> assuming you still tested this latest version 🙂
20:09:53 <talltyler> I did. Thanks for the reviews! ❤️
20:10:25 <talltyler> I am excited to see what GRF authors do with manually-placed houses 🙂
20:11:43 <yiffgirl> yiffgirl: looks like... `Microsoft (R) C/C++ Optimizing Compiler Version 19.38.33135`. does that help? peter1138[d]
20:11:52 <peter1138> I think GRF authors can't do much with it... but players can, right?
20:12:43 <peter1138> GRF authors will just carry on making everything an object...
20:13:06 <talltyler> GRF authors could create houses that have a 0% probability of spawning, intended for players to place
20:14:07 <talltyler> Thank goodness there's a search bar in the house picker, I bet it'll get out of hand quickly
20:14:23 <_glx_> yiffgirl: usually first thing to try is clear cmake cache
20:17:23 *** tionstav has joined #openttd
20:17:23 <tionstav> talltyler: Give the towers an actual chance of spawning, I should.
20:17:51 <yiffgirl> _glx_: ran `cmake --build . --target clean`, no change.
20:18:12 <_glx_> that's not clearing the cache 🙂
20:18:35 <_glx_> delete build dir and run cmake from start
20:18:52 <_zephyris> talltyler: Already deleted my Full English houses as objects branch...
20:19:35 <_glx_> it's `project | clear cache and reconfigure` in VS
20:20:07 <talltyler> I still want your OpenGFX 2 landscape object sets on Bananas 😄
20:20:38 <talltyler> Placeable rocks, transmitters, etc., that perfectly match the base set are very nice
20:21:55 <yiffgirl> hmm, looks like it's all in enum_type.hpp
20:22:20 <_zephyris> talltyler: I was kinda waiting till I'd done some terrain tiles as objects...
20:22:54 <_zephyris> Otoh, newgrf terrain tiles 😉
20:29:05 <talltyler> It would be cool to have some sloped retaining walls that match the base set foundations. Whenever I play in an eye-candy game, 90% of my decorative tiles are this retaining wall, and the rocky terrain.
20:29:47 <Rubidium> peter1138: for 13513 I'm thinking of adding the bitset::set without parameters (sets all bits) and bitset::all to check whether all are set. Seems the simplest solution to me
20:30:44 <talltyler> It would also be lovely for them to work as shore tiles, since neither of the aforementioned tiles do. And these subsitutes don't look nearly as good...
20:30:45 <peter1138> note: candidate constructor (the implicit copy constructor) not viable: cannot bind base class object of type 'BaseBitSet<CompanyMask, Owner, unsigned short>' to derived class reference 'const CompanyMask &' for 1st argument
20:30:50 <peter1138> Yeah, this one isn't working :D
20:31:37 <peter1138> It's annoying that it doesn't fail to build with numeric_limits :(
20:32:22 <peter1138> talltyler, surely JGRPP has all that...
20:33:57 <_zephyris> talltyler: Nice idea
20:44:53 <talltyler> peter1138: I know you're joking, but the main eyecandy tool in JGRPP is using trackless rail for diagonal ground tiles
20:46:21 <talltyler> You may also notice retaining walls on diagonal tracks near the center of the image. You may gasp at the abuse of sprite overlaps, but you'd be mistaken. Those are SIGNALS. 🥲
20:48:13 <talltyler> There are a lot of objects in this game (I placed many of them) 🙂
20:48:33 <talltyler> Squiggles in the mountains are nearly all rocks
20:50:27 <talltyler> There's a name I have seen in a while! Hello! 🙂
20:50:43 <jfs> random fact: days are possibly longer in Transport Tycoon (original), I just timed a whole year to be 18m15s (approx) in real time
20:50:54 <jfs> longer as in more ticks per day
20:51:15 <peter1138> talltyler, I know about the signal abuse as well...
20:51:15 <talltyler> I knew we ruined something 😛
20:51:18 <jfs> which would also explain why industries in TTO generally produce more cargo per month than in TTD
20:51:40 <talltyler> Do the production intervals line up with months any better in TTO?
20:51:57 <jfs> I haven't checked that, don't have any debugging tools for TTO at all
20:54:41 <jfs> also I love the look of the monorail in TTO, have anyone recreated that for OTTD?
20:55:24 <talltyler> The bridges are a particularly nice touch 🙂
20:56:17 <jfs> yeah the completely clean bridges, just a floating track, look so elegant
20:57:20 <jfs> xarick: would actually match with 1 day = 3 seconds in TTO, with the timing I got
20:58:23 <jfs> brb forking for my new patchpack OpenTTO (jk)
20:58:24 <Rubidium> what the... how does 13514 work for me?!?
20:59:11 <peter1138> > This branch is out-of-date with the base branch
21:00:24 <talltyler> You can use the industry cargo scale and minutes per year to adjust OpenTTD to match, except for vehicle movement and running costs 🙂
21:00:54 <xarick> wallclock: 18 minutes per year, problem solve?
21:01:18 <Rubidium> no literally, make && ./openttd -g starts a working version of OpenTTD for me with #13514 (at fix-13514^ make && ./openttd -g starts a version without vehicles)
21:02:24 <peter1138> Oh I thought you meant the compile-failure.
21:02:52 <_glx_> ah that's why I don't have any vehicles in 1970
21:02:57 <Rubidium> yes, the compile failure does not happen for me
21:03:16 <Rubidium> and github does not magically rebase
21:04:00 <peter1138> Something cached maybe.
21:05:08 <peter1138> (make clean && make)
21:05:59 <yiffgirl> i ended up just pushing it as is
21:09:00 <xarick> @glx there are some conditional orders related to time, let me find them
21:09:14 <xarick> i suppose you're aware
21:09:48 <yiffgirl> ha, i think the operator- i left in is unused
21:11:07 <_glx_> xarick: I search for all `ScriptDate::Date`
21:11:41 <xarick> i think frosch had a collection of all methods involving time
21:12:54 <LordAro> well there's a reason for using std::begin instead of .begin()
21:13:26 <_glx_> yes but I touched only ScriptDate, not the stuff using Age or similar
21:13:32 <truebrain> LordAro: first time for everything 😄
21:14:38 <xarick> ScriptOrder.OrderCondition.OC_AGE
21:15:20 <_glx_> yes and I didn't touch that at all
21:15:31 <_glx_> it's independant of ScriptDate
21:16:08 *** Wormnest has quit IRC (Quit: Leaving)
21:16:12 <xarick> gonna test it, once the vehicle availability is fixed
21:17:38 <_glx_> my code doesn't affect orders at all
21:18:22 *** gelignite has quit IRC (Quit: Stay safe!)
21:18:28 <_glx_> looking at order doc it feels painful to use 🙂
21:21:00 <xarick> SetOrderCompareValue it's this one
21:21:38 <_glx_> yes and it's not a date
21:24:45 <yiffgirl> here's the output i'm getting from cmake
21:27:58 <yiffgirl> thank you for looking at the pr peter! i'll get to fixing these
21:28:38 <ufiby> jfs: My project is going according to plan U&ReRMM32bpp 😛
21:32:56 <xarick> meanwhile NoCAB is trying to beat AdmiralAI
21:33:52 <xarick> wormnest: NoNoCAB's underwhelming performance 😦
21:34:47 <xarick> it was expected to match or surpass NoCAB
21:37:10 <_glx_> @su maybe see if there's an update for VS, I have `Compilateur d'optimisation Microsoft (R) C/C++ version 19.42.34436 pour x64`
21:37:37 <peter1138> LordAro, one thing I liked about std::ranges was being able to avoid using either std::begin() or .begin() :)
21:38:09 <peter1138> Ah, so the solution is to use a French compiler.
21:46:11 <xarick> so WormAI stops at 2500 airports 😦
21:46:54 <xarick> these self-imposed limitations... why
21:47:14 *** coobies has joined #openttd
21:47:14 <coobies> It says why, "for the current aircraft limit"
21:47:34 <coobies> So it wants to have at least 2 aircraft per airport
21:47:59 <coobies> How many should it have? Probably more than that, tbh, so if anything the limit is higher than necessary
21:49:41 <peter1138> Everything to max with xarick.
21:52:58 <xarick> are Order Flags already gone through `.Test` thingy?
21:53:34 <peter1138> yiffgirl, maybe you need to refresh the page before reading my comments again :)
21:54:32 <xarick> okay, my unbunch stuff still fine then
21:55:41 <andythenorth> probably naptime?
21:58:49 <andythenorth> involuntary napping though
22:02:13 <johnfranklin> Why is petern black and white now?
22:05:14 <yiffgirl> @ peter: should i use a `std::array` or plain old `BlobHarmonic[4]`?
22:05:31 <yiffgirl> johnfranklin: evil mode
22:07:30 *** reldred has joined #openttd
22:07:30 <reldred> heaven forbid a dude change up their style
22:10:47 <yiffgirl> i don't think anyone was complaining
22:12:55 <belajalilija> reldred: change bad reee
22:15:34 *** Wolf01 has quit IRC (Quit: Once again the world is quick to bury me.)
22:18:19 <xarick> is this one exposed to AIs?
22:20:30 <andythenorth> definitely naptime
22:20:37 <_glx_> they don't have AIDate.GetSystemTime()
22:20:56 <peter1138> Hmm, WindowNumber's "automatically convert to any other type" operator is causing me "fun" :(
22:21:10 <xarick> default: NOT_REACHED(); for DT_SYSTEM :/
22:21:54 <peter1138> I tried making it ConvertibleThroughBase but no luchk.
22:24:03 <xarick> nevermind, can't be reached
22:24:55 <_glx_> working with instances is so unsafe
22:27:06 <xarick> btw `DATE_INVALID = ::EconomyTime::INVALID_DATE.base(), ///< A value representing an invalid date.`
22:27:30 <xarick> you use date invalid for calendartime
22:27:54 <_glx_> `print(economy_date - this);` happily handles `this` as a `ScriptDate` even if it is a `Regression` instance (ie an `AIController`)
22:28:54 *** keikoz has quit IRC (Ping timeout: 480 seconds)
22:32:09 <xarick> probably fine, I don't know
22:33:32 <xarick> > Template class for time constants shared by both Calendar and Economy time
22:33:39 <xarick> okay, it's fine after all
22:34:02 <xarick> ::EconomyTime isn't very neutral wording but
22:35:47 <peter1138> _glx_, any way to do it without the object... (I'm guessing no.)
22:35:56 <peter1138> (Pointer-to-object)
22:40:02 <_glx_> well the issue is present everywhere, not only for ScriptDate
22:41:19 <xarick> is this similar to how Lists are built?
22:41:35 <xarick> are you still able to store dates in a list btw
22:42:30 <_glx_> not directly I think, might need to use GetValue()
22:42:44 <_glx_> lists only accept numbers
22:43:17 <peter1138> List elements are... a bit more complex, IIRC.
22:48:42 <_glx_> like `GSTown.SetName(i, this);` crashes openttd, because `this` (`GSController`) is happily casted to `Text*`
22:49:48 <_glx_> guess we should use `typetag` but squirrel doc is so unhelpful
22:54:47 <xarick> actually a bad image the first one
22:57:15 <_glx_> yeah it returns an GSDate now, and that's not valid
22:58:30 <_glx_> as I said, I didn't really test
22:59:23 <peter1138> Might be easier to just have different functions, return SQInteger and let the script make sure it doesn't mix them up.
22:59:41 <_glx_> it's fine for API 14 because compat wrappers
23:00:59 <_glx_> anyway instance handling needs to be made safer in master
23:05:03 *** nielsm has quit IRC (Ping timeout: 480 seconds)
23:42:18 *** HerzogDeXtEr has quit IRC (Read error: Connection reset by peer)
continue to next day ⏵
