IRC logs for #openttd on OFTC at 2023-05-05
⏴ go to previous day
01:54:02 *** Wormnest has quit IRC (Quit: Leaving)
02:11:06 *** debdog has quit IRC (Ping timeout: 480 seconds)
03:45:04 *** andythenorth has quit IRC (Remote host closed the connection)
03:45:04 *** bigyihsuan has quit IRC (Remote host closed the connection)
03:45:04 *** dP has quit IRC (Remote host closed the connection)
03:45:04 *** Brickblock1 has quit IRC (Remote host closed the connection)
03:45:04 *** DorpsGek_v has quit IRC (Remote host closed the connection)
03:45:04 *** michi_cc[d] has quit IRC (Remote host closed the connection)
03:45:04 *** glx[d] has quit IRC (Remote host closed the connection)
03:45:04 *** EmperorJake has quit IRC (Remote host closed the connection)
03:45:04 *** JobbeDeluxe has quit IRC (Remote host closed the connection)
03:45:04 *** GeorgeVB has quit IRC (Remote host closed the connection)
03:45:04 *** TallTyler has quit IRC (Remote host closed the connection)
03:45:04 *** kamnet has quit IRC (Remote host closed the connection)
03:45:04 *** Quantum has quit IRC (Remote host closed the connection)
03:45:04 *** JGR has quit IRC (Remote host closed the connection)
03:45:04 *** TrueBrain has quit IRC (Remote host closed the connection)
03:45:04 *** jfs- has quit IRC (Remote host closed the connection)
03:45:04 *** gnomechomsky has quit IRC (Remote host closed the connection)
03:45:04 *** petern has quit IRC (Remote host closed the connection)
03:45:04 *** frosch has quit IRC (Remote host closed the connection)
03:45:04 *** SicIuvatIreSubUmbras has quit IRC (Remote host closed the connection)
03:45:10 *** DorpsGek_v has joined #openttd
05:28:03 *** WormnestAndroid has quit IRC (Read error: Connection reset by peer)
05:28:53 *** WormnestAndroid has joined #openttd
05:34:10 *** WormnestAndroid has quit IRC (Read error: Connection reset by peer)
05:34:13 *** WormnestAndroid has joined #openttd
06:02:16 *** TrueBrain has joined #openttd
06:02:16 <TrueBrain> meh; GitHub finally had a decent code-search, but they shut it down .. and now you have to use this crappy interface again 😦
06:02:22 <TrueBrain> impossible to find code snippets this way .. sad
06:10:26 <petern> Hmm, so vector etc in stdafx? Works for me.
06:10:57 <TrueBrain> `When you create a new project in Visual Studio, a precompiled header file named pch.h is added to the project. (In Visual Studio 2017 and earlier, the file was called stdafx.h.) The purpose of the file is to speed up the build process. Any stable header files, for example Standard Library headers such as <vector>, should be included here.`
06:11:19 <TrueBrain> mostly works with Rubidium's pull-request to add that to CMake 🙂
06:18:16 <petern> `settingsgen : warning : Cannot find template SDTC_SSTR`
06:18:49 <TrueBrain> yeah, at the top of each template you need to copy those lines
06:19:06 <TrueBrain> at least, I hope that isn't in master 🙂
06:19:17 <petern> network_private_settings.ini is missing it.
06:19:28 <TrueBrain> huh? I even tested that it worked ...
06:20:07 <petern> Odd because that's not new. I wonder why I'm seeing it now.
06:20:30 <TrueBrain> the reviewer did a bad job 😛
06:21:21 <TrueBrain> but why didn't the build fail ..
06:21:36 <petern> Oh right, you removed SDTC_SSTR in that commit 🙂
06:23:14 <TrueBrain> wow, why didn't we squash all those "remove STR.." commits? 😄
06:23:23 *** andythenorth has joined #openttd
06:24:58 <petern> Too early to think sensibly I guess.
06:25:31 <TrueBrain> 😄 It is too bad our CI takes so long, but I have learnt to love to only allow squashing .. it resolves the issue of people doing 10 things in a single PR 😛
06:25:32 <petern> You could rewrite history 😛
06:25:38 <TrueBrain> nah, it is fine; it just looks funny 🙂
06:27:00 <TrueBrain> what I don't like about the GitHub interface, but do understand, that if you rebase a PR once, from then on, all other PRs are also defaulted to rebase .. like: NO, that was the EXCEPTION.
06:27:09 <TrueBrain> so often it takes me a few PRs before I found the squash button again 😛
06:28:51 <TrueBrain> at least the force-push history alone is entertaining 😄 But auto-preview-deployments now work 🙂
06:29:32 <TrueBrain> sorry, but that reply was too easy to pass on 🙂
06:29:57 <TrueBrain> I would think it throws a warning, which is picked up by our annotation, preventing merging of the PR ..
06:30:19 <andythenorth> TrueBrain: I will look at it later today 🙂
06:30:48 <TrueBrain> ah, the annotation didn't pick it up, as it uses a slightly wrong syntax
06:31:01 <TrueBrain> I am just surprised it is a warning in settingsgen
06:31:04 <TrueBrain> shouldn't it just be an error?
06:31:12 <TrueBrain> I mean, it feels really bad
06:31:52 <petern> Yes, I'm just going to use FatalError() I think.
06:32:05 <TrueBrain> you picking it up? Great 🙂 Tnx 🙂
06:32:08 <petern> The main thing is it continues instead of using exiting with status 1.
06:32:23 <TrueBrain> it really should exit with a non-zero status
06:32:29 <TrueBrain> like: SOMETHING MAJOR IS BREAKING 😛
06:36:11 <petern> [build] Generating table/settings.h
06:36:11 <petern> [build] settingsgen: FATAL: Cannot find template SDTC_SSTR
06:41:07 <petern> This should fail, until 10765 is merged.
06:41:49 <TrueBrain> would approve, but you need to rebase anyway 😛
06:42:40 <petern> Good proof that it does the job tho!
06:43:25 <petern> MinGW is still the slowest to fail 😄
06:44:59 <TrueBrain> that PR to make Rubidium happy 😄
06:45:32 <Eddi|zuHause> yes, only Rubidium is affected by that :p
06:45:51 <Rubidium_> TrueBrain: that PR made me almost fall out of my chair
06:45:57 <TrueBrain> I thought I used the server-indicated value, but I remember why it is hard-coded: it is nearly impossible for the Discord side to calculate the header-size, and nearly impossible for the IRC side to break it up over multiple lines .. so I guess we just have to do with this solution 🙂
06:46:08 <Rubidium_> "line too long (130 > 120 characters)" :D
06:46:18 <TrueBrain> owh, lazy programmer being punished
06:47:13 <TrueBrain> the irony is high, I know 😛
07:01:14 <petern> andythenorth: Moar objects, no excuses.
07:06:36 <petern> andythenorth: also you got more random bits, although thinking about it, maybe I should have set the top 8 bits during saveload.
07:07:09 <TrueBrain> Rubidium: IRC specs say the message length should be 512; so the 470 should have fitted too .. I dunno, I gave up on understanding this stuff 😛
07:09:26 <TrueBrain> rebase rebase rebase rebase rebase rebase
07:10:25 <petern> Oh no, I used github's rebase and my commit is no longer verified, how will you know it was really me...
07:10:39 <TrueBrain> yeah .. zero fucks were given 😛
07:16:02 <andythenorth> petern: think grf is 100% complete now 😛
07:16:33 <TrueBrain> to IRC: we will be right back! 😄
07:16:39 <andythenorth> also > 255 action 2 IDs? 😛
07:17:02 *** D-HUND is now known as debdog
07:17:07 <andythenorth> with 16 random bits, I might be able to run out of synchronous varact 2 IDs 🙂
07:18:44 <Rubidium_> TrueBrain: IRC spec messages are the messages the client sends, so me typing "Hi" results in something like "PRIVMSG #openttd: Hi" to the server and ":Rubidium_ PRIVMSG #openttd: Hi" to the client (or maybe even ":someone@somewhere PRIVMSG #openttd: Hi"). That will already take a chunk out of the alotted 512 bytes for that message
07:19:17 <TrueBrain> yup; so I took 40 chars for that ... but it depends on the hostmask ... and more unpredictable shit ..
07:19:21 <TrueBrain> like I said: I gave up on it 😛
07:19:58 <andythenorth> are we matrix bridged? 😛
07:20:09 <TrueBrain> fuck Matrix; they need to get their shit together
07:20:17 <TrueBrain> their IRC bridge is just the worst
07:20:31 <petern> Er, since the switch to git, what's the standard way to specific which "revision" something appears in, on the NewGRF specs?
07:21:41 *** TrueBrain has quit IRC (Remote host closed the connection)
07:21:41 *** petern has quit IRC (Remote host closed the connection)
07:21:41 *** DorpsGek_v has quit IRC (Remote host closed the connection)
07:21:41 *** andythenorth has quit IRC (Remote host closed the connection)
07:21:56 *** DorpsGek_v has joined #openttd
07:22:07 *** TrueBrain has joined #openttd
07:22:07 <TrueBrain> right, and we should be back (on IRC) 🙂
07:22:27 <petern> I have no idea how to see what value that ends up as 🙂
07:22:58 <TrueBrain> for next release, `14 << 24 | 0 << 20 || 1 << 19 || 28004` 😛
07:23:03 <TrueBrain> but not sure that is actually helping 😄
07:23:24 <petern> "Since r13482" was fairly easy to understand.
07:23:43 <petern> "Since PR#10701" doesn't work 😄
07:23:47 <TrueBrain> basically, how I read that variable, we don't do "in between" any more
07:23:49 <petern> Yeah, 14.0 would work I guess.
07:23:50 <TrueBrain> either 13.1 or 14.0
07:24:20 <TrueBrain> atm we are heading for 14.0, so I guess that alread yworks
07:24:25 <petern> "Since OpenTTD 14.0, each ID is an extended byte for all features."
07:24:29 <TrueBrain> `30 << 24 | 28004` would be the current number
07:24:53 <TrueBrain> but yeah, the 28004 is now frozen .. we could have replaced it with "amount of commits" I guess ..
07:25:14 <TrueBrain> but yeah, communicating in 14.0 sounds better 😄
07:25:26 <TrueBrain> since PR#10701 sounds ... not useful to most authors 😛
07:25:54 <TrueBrain> hmm .. I am hungry .. guess I should go to a store
07:28:42 <petern> Exactly, it doesn't work at all.
07:33:12 *** Flygon has quit IRC (Quit: A toaster's basically a soldering iron designed to toast bread)
08:01:30 <petern> Can we use `std::views::iota` yet? 😉
08:04:29 <TrueBrain> Wash your mouth! We aren't that modern over here! :p
08:07:44 *** osvaldo[m] has quit IRC (Quit: Client limit exceeded: 20000)
08:16:14 <Rubidium_> I rather have std::unreachable()
08:17:28 <TrueBrain> C++23 .. even worse! :p
08:17:49 <Rubidium_> smaller stdafx is better stdafx :D
08:19:05 <Eddi|zuHause> in all these years, i never actuall asked this question outloud: what does stdafx even stand for?
08:21:04 <Rubidium_> AFX stands for "application framework extensions", AKA MFC
08:22:52 <Rubidium_> from back in the old days, when you started a MSVC UI project it was based on MFC. It added stdafx.h as standard precompiled header header, so... we should probably rename stdafx.h to pch.h
08:24:32 <petern> Is there anything in the project files that makes it precompiled?
08:25:10 <Eddi|zuHause> best word ever :)
08:26:50 <petern> Is it something that was in our original VS project files that got lost over the years, or did VS magically assume...
08:28:35 <Rubidium_> in 0.4 it was disabled in the configuration of the MSVC project
08:30:57 <Rubidium_> in 0.3.4 it seems to have been enabled though
08:31:57 <petern> Interesting, so it was not accidentally lost, but deliberate long before even the first makefile rewrite.
08:37:11 <Rubidium_> though after almost 18 years it might be worth to reconsider
08:38:01 <petern> Yeah, "no more troubles" is a bit vague. If PCH doesn't work right, then it's probably a build system issue...
08:38:24 <TrueBrain> Pretty sure they improved it over the last 18 years 🙂
08:39:06 <petern> Although yeah, there are incorrect paths that were fixed at the same time.
08:40:19 <petern> I can't approve that PR as it's in the wrong repo 😄
08:45:00 <Eddi|zuHause> how did anyone approve this commit when it does 3 things at once? :p
08:46:40 <Rubidium_> petern: well, it depends on the ClampTo PR. If that's merged, I'll properly PR this
08:52:37 *** phil[m] has quit IRC (Quit: Client limit exceeded: 20000)
09:21:01 *** TROILUS has left #openttd (Leave)
09:21:13 <petern> Ah you undid the don't-allow-it stuff.
09:40:15 <petern> (Yes I should have started a review but here we are :p)
10:05:42 <petern> Most of the changes in that first commit are related to my question about iota earlier 🙂
10:06:16 <petern> Eh, some of, not most of.
10:11:27 <Rubidium_> the iterating through the scroll positions?
10:28:53 <axet> can we have lzo compression levels for save games? my rpi struggle with autosaves
10:39:03 <petern> Don't think so, we already only using lzo1x-1, which is the faster but least compressed.
10:43:27 <glx> You can set the compression type in openttd.cfg
10:44:06 *** glx is now known as Guest573
10:44:07 *** Guest573 is now known as glx[d]
10:44:10 <axet> oh. i tried booth none and lzo, server stuck for 5 seconds
10:44:28 <axet> i guess it can be btrfs compression i just realized
10:45:11 <petern> Turn off autosaves or reduce the frequency. Use a smaller map. Stop using disk compression... many options.
10:45:32 <petern> Disk compression on a low performance rpi seems like asking for trouble tbh.
10:47:27 <glx[d]> Disk compression might not be a good idea with flash memory anyway
10:47:58 <Eddi|zuHause> and compressing already compressed files doesn't do much anyway
11:00:00 <petern> Yay, VS Code just crashed again.
11:00:28 <petern> And a new default theme. Thanks.
11:06:26 <Rubidium_> might it not be the compression, but the fact that it needs to essentially copy everything before it can start with the actual compression? And if it's "low" on memory and needs to page out to a disk with disk compression, then... yeah... you're screwed royally. Both in performance and longevity of your hardware. So maybe adding more memory helps?
11:15:31 <petern> Yes, that's what I was hinting at with smaller map. You can't readily add memory to a Raspberry Pi.
11:21:54 <petern> The compression runs in a separate thread so wouldn't hang the game anyway, so it has to be the game is just too large for the hardware.
11:28:32 <petern> It's a shame that STL settled on size_t for container sizes.
11:30:16 <Rubidium_> what would you have likes?
11:35:15 <petern> Something that doesn't need casting everything to be useful.
11:44:35 <glx[d]> And size_t depends on hardware
11:48:07 <petern> I think I've got a nice solution 🙂
11:54:44 <petern> ```uint max = static_cast<uint>(std::min<size_t>(this->vscroll->GetPosition() + this->vscroll->GetCapacity(), this->groups.size()));
11:54:44 <petern> for (uint i = this->vscroll->GetPosition(); i < max; ++i) {
11:54:44 <petern> const Group *g = this->groups[i];```
11:54:52 <petern> ```for (const auto *g : this->vscroll->Iterate(this->groups)) {```
11:56:50 <petern> Eh, not quite the right 🙂
11:59:08 <petern> Should be &g of course.
12:06:38 <petern> I seem to remember I had an scrollbar-iterator patch before, not sure if it was the same as this.
12:12:08 <Rubidium_> changing the uint max and i to size_t already solves the majority of the issues
12:12:37 <glx[d]> it's GUI, size_t is fine there
12:12:40 <petern> Yeah but in my code I change scrollbar to int because unsigned is harmful.
12:13:06 <Rubidium_> then it is indeed a PITA
12:13:24 <petern> Well doing it this way with iterators solves needing to care.
12:13:29 <petern> So I'm heading towards that first.
12:13:42 <petern> There are still places where indices are used though.
12:13:53 <glx[d]> size_t is an issue only for anything related to game mechanics
12:23:37 <petern> size_t is an issue when you use things like -1 to mean "not selected", or do a bit of comparison with something that's signed...
12:24:32 <glx[d]> std::optional for selected ?
12:25:34 <LordAro> std::optional<petern>
12:36:05 <axet> how can I change map settings on dedicated server?
12:37:04 <axet> list_settings does not show what I want to change. In particular I want to change Enironment/Industries/Oil Rig distance: 32
12:38:38 <petern> There isn't an "oil rig" distance.
12:39:07 <axet> to be exact: Maximum distance from edge for Oil industries
12:39:10 <axet> it is == oil_refinery_limit?
12:39:19 <petern> It is oil_refinery_limit, yes.
12:57:39 *** WormnestAndroid has quit IRC (Remote host closed the connection)
12:57:47 *** WormnestAndroid has joined #openttd
13:21:33 <Eddi|zuHause> does that setting still have a silly range where on a 2048^2 map you can't increase it beyond 64?
13:22:44 <petern> The silly range is what use a 2048+ map.
13:23:36 <Eddi|zuHause> i think the largest map i actually played was 1024x2048 with very sparse towns, but even on that i connected only half the towns
13:25:21 <Eddi|zuHause> but there are map setups like "no water around edges" or "really a lot of water around a small island" where the setting doesn't do anything useful
13:33:06 *** Kuhnovic has joined #openttd
13:33:06 <Kuhnovic> Does anyone know if newgrf parameters are always loaded in the same order, or can their order be random?
13:33:35 <Eddi|zuHause> how do you mean?
13:34:33 <petern> parameters have a specific position.
13:35:24 *** nielsm has quit IRC (Ping timeout: 480 seconds)
13:38:04 <JGR> A NewGRF can look at its parameters in whatever order it wants, it's just a list of values
13:40:57 <Kuhnovic> I'm adding a new ship speed with a higher limit. Both the "legacy" speed and the new speed write to ShipVehicleInfo's max_speed variable. I want to make sure that the legacy speed never overwrites any previously parsed new speed when the newgrf is loaded.
13:41:39 <petern> Oh you mean action 0 properties.
13:42:02 <Eddi|zuHause> the grf is processed from top to bottom, so what comes later overwrites the first
13:42:11 <Kuhnovic> I guess 😛 I'm new to this newgrf stuff
13:42:20 <petern> No, there's no specific order that they have to follow, but in general if there is a legacy and a new way, the GRF has to used the new way last.
13:42:40 <petern> BUT! If it uses the new way at all (without skipping) then it won't work at all.
13:43:05 <JGR> Are you trying to write this GRF in NFO?
13:43:12 <petern> So basically you can probably just rely on the NewGRF doing the right thing.
13:43:23 <Kuhnovic> Not writing the GRF, I'm writing code that's handing the GRFs
13:44:24 <JGR> You're adding a new property then?
13:45:12 <JGR> Just writing to max_speed in whatever order the GRF uses the properties should be fine
13:45:47 <Kuhnovic> Alright, then I'll do that. Thanks!
13:59:35 <Kuhnovic> petern: This brings back horrible memories of nasty bugs that were caused by vector.size() - 1 and similar code.
14:00:05 <JGR> The integer promotion rules in C/C++ are just rubbish in general
14:00:07 <petern> That is precisely why I am trying to clear up some thigns 🙂
14:00:44 <JGR> But I suppose we're stuck with them 😛
14:01:07 <Kuhnovic> Hehe, the words "compatibility" and "legacy" come to mind
14:01:15 <petern> It's now considered by many to be a flaw in stl that unsigned types were used.
14:01:24 <Kuhnovic> Yup, I'm one of those many
14:01:50 <petern> And why I'm reluctant to just cast things to size_t to make the warnings go away.
14:02:02 <Kuhnovic> And more fundamentally, I'm also against using dedicated types to indicate "this thing can never me lower than 0". What's next, "This thing can only contain odd numbers"?
14:02:39 <petern> Hmm, my scrollbar iterator does not work directly on our pools though. Bum.
14:02:45 <JGR> The trouble with signed types is that you can accidentally run into ridiculous issues with signed overflow UB
14:03:15 <petern> The trouble with unsigned types is that you can accidentally run into ridiculous issues with unsigned overflow UB
14:04:08 <petern> With unsigned you can argue it's "implicit" because going "below" 0 ends up being higher than e.g. your size value.
14:05:19 <JGR> Unsigned overflow is defined behaviour not UB
14:06:00 <petern> Yes I know it's not the same I was just being flippant of course.
14:07:54 <Kuhnovic> Maybe not undefined behavior... but certainly unexpected behavior
14:24:30 <petern> One thing I miss from range-for is the ability to easily get the next element before the next iteration.
14:25:03 <petern> And hardcoded into the way the face is encoded into savegames.
14:26:30 <petern> I think I might get shot if I do `auto *next = (&item + 1); bool continues = next != &*list.end()` ... if it even works.
14:28:03 <petern> nml compiles it into a grf file.
14:28:07 <pickpacket> I'm trying to figure out how to add more appearance options to manager faces.
14:28:27 <petern> The grf file contains all the sprites in a specific order.
14:29:13 <pickpacket> as individual files, or one file and saved offset values+
14:30:28 <pickpacket> somewhere in the code that grf file and the individual sprites are read, after all :)
14:31:28 <petern> Well it comes as 4 separate files (iirc) but it's not individual files.
14:31:55 <Rubidium_> just design a NewGRF action thingy to configure how the faces should look and what options there should be. That's probably way better maintainable in the long run than attempting to hack stuff into the current system
14:32:21 <pickpacket> Rubidium_: replace the current options rather than adding more?
14:33:13 <pickpacket> that would also mean that if you create a face and save it, then activate this newgrf and loads the face up it would look different
14:35:24 *** TallTyler has joined #openttd
14:35:24 <TallTyler> You’re not supposed to add newgrfs to a running game, so I wouldn’t really worry about that
14:35:37 <TallTyler> It’s possible but not recommended, so we need not support it
14:36:08 <TallTyler> (Not saying we should break it, of course, but some harmless unexpected behavior like faces looking different is fine)
14:36:20 <pickpacket> no, but I might create a face I always like to use for my games and then activate this newgrf for a multiplayer game and suddenly my manager face not only looks completely different -- I can't even recreate it
14:36:46 <petern> Yeah, if you want custom faces for a multiple game, you'll need something other than NewGRF really.
14:36:48 <Rubidium_> pickpacket: use a NewGRF action to add more options. If you/the server owner wants extra faces, they load a NewGRF. What kinds of faces... that's up to the person that made the "faces" NewGRF
14:37:45 <pickpacket> Rubidium_: that makes sense... I'll have to figure out what kind of action or thingy to use for that
14:38:57 <pickpacket> I'd very much rather make a NewGRF for it than change the source code :D
14:40:38 <petern> "Use a NewGRF action" in this instance means "define a NewGRF action and add it to the source code"
14:41:20 <pickpacket> and then add that to nml, I presume
14:42:04 <petern> And then find you can only use custom faces provided by the NewGRFs that the server uses.
14:43:25 <pickpacket> yeah... and the question is how to handle the case where I might want to have one saved face with one newgrf, another without newgrfs, and another with another newgrf, etc
14:43:34 <pickpacket> well, one of the questions
14:44:06 <pickpacket> on the plus side someone might make a "Super Hero Manager Faces" NewGRF
14:45:04 <pickpacket> I dunno... maybe just adding more options in the source code is the better choice...
14:48:08 <pickpacket> would I have to make changes in the save file format too if I do that?
14:49:22 <axet> depends what you will do
14:51:04 <pickpacket> If there's some weird limitation like "there are only 2 different glasses and one option to be without, therefore the glasses field only needs 2 bits in the save file" and I add five more glasses...
14:52:52 <Eddi|zuHause> well, you'll be the expert in face-saveload in 10 minutes :p
14:53:25 <pickpacket> Can't say that this sounds like a tempting venture
14:53:36 <pickpacket> ... all I wanted was a beard...
14:54:11 <Eddi|zuHause> there's basically 2 scenarios it could be: it could be one uint8/16/32 for each face part, or it could all be bitstuffed into one value
14:54:50 <pickpacket> I have a suspicion it's the latter
14:55:10 <TallTyler> I suspect it’s bitstuffed, since the saved value is one big number and 0 is the default face
14:55:15 <pickpacket> because of course it would be the most annoying option 😂
14:55:28 <glx[d]> easier to just do an actionA (replace sprite) newgrf, it can be static,
14:55:50 <TallTyler> You just don’t get a beard button, it has to be called something else
14:55:54 <JGR> One of the "moustache" options has a beard
14:56:22 <pickpacket> TallTyler: I was thinking that the "moustache" button could be renamed to "facial hair"
14:56:28 <Eddi|zuHause> i could see an action5 for additional face parts :)
14:57:15 <TallTyler> If you do full NewGRF support you could theoretically have custom layers with their own buttons
14:58:02 <TallTyler> Full character creator mode 😛
14:58:35 <pickpacket> a bunch of sliders for sizes and colours etc
14:59:08 *** andythenorth has joined #openttd
14:59:08 <andythenorth> just get midjourney to do it 😛
15:02:51 <pickpacket> I thought this would more or less be a matter of drawing some more sprites.Now it sounds more like a 40+ hours project :(
15:03:35 <TallTyler> It can be as complex as you want it to be 🙂
15:04:37 <TallTyler> I do see a lot of potential for going all the way. People seem to love custom character creation for some reason, and favorite face is now chosen by default
15:05:02 *** HerzogDeXtEr has joined #openttd
15:05:24 <Eddi|zuHause> well... actionA wouldn't take 40+ hours, you just have to sacrifice some of the existing moustaches
15:06:17 <pickpacket> What I'd *like* to do is to add more options to the game, but it looks like that possibly involves backwards incompatible changes to save files
15:06:40 <andythenorth> base set hack is quick and easy
15:07:39 <TallTyler> No, save files are fine. That’s why we have afterload.cpp, to take care of converting old save games when things change format 🙂
15:08:25 <Eddi|zuHause> pickpacket: well, savegame changes are "simple", just decide a new fromat, and then add a conversion to afterload
15:08:58 <Eddi|zuHause> definitely not 40+ hours
15:09:05 <TallTyler> Keep in mind that adding new hardcoded graphics is relatively uncommon. Stuff like UI icons, rivers, drive-through road stations…not sure what you else
15:09:42 <Eddi|zuHause> well, the list of action5s is slightly longer than that
15:10:00 <TallTyler> I don’t know what an action5 is 😛
15:10:35 <TallTyler> My NFO knowledge is “it’s GRF hard mode” and nothing else
15:10:35 <Eddi|zuHause> actionA = replace original static graphics, action5= additional static graphics that aren't in the original
15:11:15 <Eddi|zuHause> icons, rivers and stuff are action5
15:15:53 <Eddi|zuHause> other "important" actions are 0 for vehicle properties, 1/2/3 for adding new vehicles, 4 for translations, and 6/7/9/D for control flow
15:17:07 <FLHerne> s/vehicle/<all kinds of stuff>/ ?
15:17:23 <Eddi|zuHause> well, a free definition of "vehicle"
15:17:48 <Eddi|zuHause> in some way, industries and houses could be "vehicles" :p
15:17:53 <FLHerne> if railtypes and industry tiles are vehicles that's a very free definition indeed :p
15:18:04 <FLHerne> I know /my/ house is a vehicle but that's hardly the norm
15:19:24 <Eddi|zuHause> "don't worry about it" *handwave* :)
15:32:08 <pickpacket> Adding more hardcoded alternatives and possibly changing the save file format might be viable solution then 🤔
15:33:42 <pickpacket> Making it a full-fledged character creator would be pretty cool, though
15:33:44 <JGR> You wouldn't strictly have to bump the savegame version to add more face related fields
15:35:29 <JGR> The new table format is designed to support adding more fields which versions which don't know about it can ignore
15:57:56 <glx[d]> so many code duplication in scanners just because AIInfo and GameInfo casts
16:25:08 <Eddi|zuHause> the whole AI/GS system is 99% duplication
17:36:08 <andythenorth> petern: I only have 17 unfinished projects, so shall we do grf docks?
17:37:46 <petern> More than 255 flat docks per NewGRF?
17:38:51 <andythenorth> flat dock labels?
17:39:02 <andythenorth> flat dock docking compatibility standards for ships?
17:39:09 <andythenorth> and a standardised scheme for them?
17:42:01 *** Brickblock1 has joined #openttd
17:42:33 <petern> Testing for compilation errors on platforms that care more about signed/unsigned and int/size_t and shizzle than mine 😄
17:53:01 <Eddi|zuHause> andythenorth: do you have any finished projects? :p
17:53:45 <glx[d]> at least failure is consistent with all compilers
17:54:12 <glx[d]> except mingw is super slow to reach the failure point
17:57:39 <andythenorth> Eddi|zuHause: HEQS
17:57:58 <petern> Is it really finished though.
17:58:35 <andythenorth> “Define finished”
18:08:26 <andythenorth> dice finished? 😛
18:09:16 <Brickblock1> they look really nice
18:11:21 <andythenorth> the placement is shocking
18:14:09 <petern> fios lists are annoying, the filter doesn't filter the list like most other windows.
18:15:38 <petern> Hmm, build list is broken 😄
18:21:52 <Eddi|zuHause> the dice should show random numbers :p
18:23:21 <Eddi|zuHause> (maybe the different number of possible results?)
18:24:05 *** Wormnest has joined #openttd
18:24:10 <Eddi|zuHause> nobody will realize that's what it means :)
18:30:30 <petern> Okay, how do I run CTest in debug correctly...
18:30:44 <petern> I've got it to launch but it complains about language packs, so I assume it's in the wrong path 😄
18:32:17 <petern> Ah, it now launches the game but without the regression test... useful.
18:42:26 <DorpsGek> - Update: Translations from eints (by translators)
19:44:34 *** gelignite has joined #openttd
19:55:59 <petern> "The savegame has an AI by the name 'regression', version 1 which is no longer available.
19:57:06 <petern> I don't really know what I'm doing with regression tests. It runs from CTest but something about paths is wrong when I run the commands directly.
20:16:55 *** axet has quit IRC (Quit: Leaving.)
20:19:02 <andythenorth> what if there was a string code to insert a colour indicator sprite?
20:20:31 <TrueBrain> petern: I had the same issue in Windows, couldn't figure it out. WSL runs fine
20:20:49 <petern> I've not got WSL working.
20:21:04 <petern> As in, not set up for compiling/debug OpenTTD in VS Code.
20:21:14 <TrueBrain> Yeah, I mean more it is something Windows specific it seems
20:22:29 <petern> It's finding all the content in my homedir, which seems wrong for regression testing.
20:23:12 <petern> And of course -X means it doesn't find a baseset 😄
20:23:13 <Eddi|zuHause> andythenorth: there's a "custom" range in unicode, you could put your sprite as a glyph in that range, and then use text colour?
20:23:35 <Eddi|zuHause> andythenorth: the game puts the train/bus/plane/ship glyphs in that range
20:24:00 <petern> Text colours aren't the same as company colours.
20:24:24 <andythenorth> I assume glyphs are monochrome?
20:24:43 <Eddi|zuHause> technically bichrome... background, shadow, and text
20:26:05 <Eddi|zuHause> and you need 4 sprites per glyph, small/medium/large/mono font
20:27:55 <petern> ffs, if TrueBrain can't work it out how am I going to...
20:33:37 *** gelignite has quit IRC (Quit: Stay safe!)
20:36:16 <TrueBrain> I know far less about Windows than most of you, so ... fix it :p
20:36:55 <petern> I don't get how it works directly from CTest, but then I can't debug that 😄
20:42:55 <andythenorth> TrueBrain: I didn't review survey website text sorry 😛
20:43:27 <petern> ```CMake Warning at cmake/InstallAndPackage.cmake:204 (message):
20:43:27 <petern> Unknown Linux distribution 'debian' from /etc/os-release found for
20:43:27 <petern> packaging; can only pack to a txz. Please consider creating a Pull Request
20:43:27 <petern> to add support for this distribution.```
20:43:33 <petern> Yeah we probably don't actually want that?
20:43:35 <TrueBrain> andythenorth: No worries.
20:44:03 <petern> ffs, vs code wsl tries to run cmake.exe from windows :p
20:44:16 <TrueBrain> petern: Ironically, it is because we do a case sensitive compare 😄
20:45:59 <petern> So WSL VS Code uses the same settings file as Windows VS Code, and it's all wrong.
21:00:51 <petern> `for (int i = this->vscroll->GetPosition(); this->vscroll->End(); i++) {`
21:00:56 <petern> Spot the stupid mistake.
21:03:04 <Rubidium_> I see it. Good luck for that loop to ever end
21:03:49 <petern> Another reason I prefer the range-for 🙂
21:05:49 <petern> There'll still be errors of course...
21:06:51 <petern> I think that logdata needs to be changed 🙂
21:08:32 *** keikoz has quit IRC (Ping timeout: 480 seconds)
21:10:23 <Rubidium_> I've got a patch for that :D
21:10:34 <Rubidium_> not sure if it's the change you're looking for though
21:11:01 <TrueBrain> Rubidium is infected with the peter virus.. ohoh
21:12:00 <andythenorth> did we have an offset to move the text around?
21:12:18 <Rubidium_> though deque might be an even better solution
21:13:46 <petern> deque made sense to me.
21:14:07 <andythenorth> removed in OpenTTD 😄
21:14:13 <andythenorth> X Y offsets for string
21:14:30 <petern> We can scrap all the meta data and just store text & type.
21:15:24 <petern> And with any luck my scrollbar code can just iterate it
21:16:07 <Rubidium_> yeah, that's the better solution in the long run. My main goal was to go from stredup char* to std::string
21:16:42 <petern> Phew, green tick from Windows now 😉
21:24:51 <petern> Someone liked magic numbers 🙂
21:28:48 <petern> Hmm, testing now, if this works...
21:37:27 <petern> Just a bit of dependency hell
21:41:13 *** GeorgeVB has joined #openttd
21:41:13 <GeorgeVB> Is it possible to use OTTD strings in a GRF?
21:41:13 <GeorgeVB> Like STR_UNITS_FORCE_METRIC for example?
21:41:13 <GeorgeVB> nmlc ERROR: "xussr-emu.nml", line 10612: Substring "STR_UNITS_POWER_METRIC" does not exist
21:41:13 <GeorgeVB> just referring them by name is not legal from NMLC POV. Is there some other way to do it?
21:55:33 *** Wormnest has quit IRC (Ping timeout: 480 seconds)
21:55:40 <Eddi|zuHause> you can only use things like {POWER} to add units
21:56:22 <Eddi|zuHause> (if you push an appropriate value to the stack)
21:57:26 <Eddi|zuHause> there is some very limited range of TTD string IDs that are translated, but i don't know if you can use them for display, or only change them through action4
21:59:13 <Eddi|zuHause> the main problem is, the OTTD string IDs aren't guaranteed to stay the same across versions
22:00:07 <petern> Balls, it's just not possible to keep the types nicely partitioned and then spread them around :/
22:00:54 <Eddi|zuHause> why do i think of marmelade?
22:02:34 *** ChanServ sets mode: +v tokai
22:08:23 *** WormnestAndroid has quit IRC (Ping timeout: 480 seconds)
22:08:52 *** WormnestAndroid has joined #openttd
22:09:24 *** tokai|noir has quit IRC (Ping timeout: 480 seconds)
22:11:17 <glx[d]> "project": "CMakeLists.txt",
22:11:17 <glx[d]> "projectTarget": "openttd.exe",
22:11:17 <glx[d]> "name": "openttd.exe (regression)",
22:11:19 <glx[d]> "regression/regression.cfg",
22:11:21 <glx[d]> "ai/regression/test.sav",
22:11:27 <glx[d]> that's what I use to debug regression
22:17:04 *** WormnestAndroid has quit IRC (Read error: Connection reset by peer)
22:19:07 *** WormnestAndroid has joined #openttd
22:30:17 <petern> Okay, so not launched via CTest.
22:30:42 <petern> Using that launch set up it still does not find the correct files for regression test.
22:32:20 <Eddi|zuHause> why can't it be as easy as "make regression"?
22:32:49 <Eddi|zuHause> things have a tendency to get more complicated without getting better
22:33:55 <glx[d]> make regression runs ctest
22:35:54 <petern> I can run the regression no problem. I can't debug the regression.
22:35:54 <glx[d]> petern: with working dir being the build dir ?
22:36:19 *** Wormnest has joined #openttd
22:37:33 <Eddi|zuHause> once upon a time there were different directories for release and debug builds... no clue how that works nowadays
22:38:18 <petern> Okay, so log_data was a `void *` which meant nothing cared about types.
22:38:24 <Eddi|zuHause> and the lang files get put in the correct one?
22:38:41 <petern> lang files are in build/
22:39:05 <petern> `cd build; ./RelWithDebugInfo/openttd.exe` just works.
22:40:08 <petern> But providing `-c regression/regression.cfg` stops that from working, but only when I run it myself. CTest manages to execute it fine...
22:40:27 <glx[d]> lang files are next to the exe for me
22:40:53 <petern> Hah, so even Windows does it diferently.
22:41:53 <glx[d]> it's just "open directory" mode for VS, debug and release are in their own subdir
22:44:49 <glx[d]> I didn't set the macos stuff in it, it's part of the default targets even if I can't use it
22:47:27 <glx[d]> oh and I just noticed a mistake for the release targets
22:50:33 <petern> If a -c is used, then it doesn't add current working directory to the path list.
22:50:58 *** WormnestAndroid has quit IRC (Ping timeout: 480 seconds)
22:51:00 *** WormnestAndroid has joined #openttd
22:51:40 <petern> This... doesn't explain how CTest works normally, though...
22:52:25 <glx[d]> but _searchpaths[SP_BINARY_DIR] = tmp; should do it later
22:52:57 <glx[d]> working dir is only used to create content_download and friends
22:53:06 <petern> My binary is under build/RelWithDebInfo/
22:53:52 <petern> That's how CMake with MSVC configures it.
22:54:45 <glx[d]> I think since VS supports CMake the sln way is rarely checked
22:55:54 <TrueBrain> petern: So that is why it fails to find language files ... how annoying
22:55:54 <petern> VS Code doesn't do anything with .sln.
22:56:14 <TrueBrain> (Had same issue with MSVC and CMake)
22:57:45 <glx[d]> maybe an extra search dir for cwd but readonly
22:58:29 <petern> There must be something else though, as it does work when I run ctest without debugging.
22:59:05 <glx[d]> ctest copies the exe to build/regression_<regressionname>.exe
22:59:39 <glx[d]> to be able to switch it to console mode
23:00:32 <glx[d]> ```if(EDITBIN_EXECUTABLE)
23:00:32 <glx[d]> execute_process(COMMAND ${CMAKE_COMMAND} -E copy ${OPENTTD_EXECUTABLE} regression_${REGRESSION_TEST}.exe)
23:00:32 <glx[d]> set(OPENTTD_EXECUTABLE "regression_${REGRESSION_TEST}.exe")
23:00:32 <glx[d]> execute_process(COMMAND ${EDITBIN_EXECUTABLE} /nologo /subsystem:console ${OPENTTD_EXECUTABLE})
23:01:18 <petern> Yes,... I'm now thinking that copies from build/RelWithDebInfo/openttd.exe to build/regression_regression.exe
23:01:25 *** WormnestAndroid has quit IRC (Read error: Connection reset by peer)
23:01:29 <TrueBrain> Linux does the same as Windows btw, with paths. Only the binary is always in the root of the build folder
23:01:34 <petern> But only if Editbin is available.
23:01:43 <petern> That's not quite the same then 🙂
23:01:57 <TrueBrain> So that is why it isn't an issue there
23:02:10 <TrueBrain> But -c on linux too ignores cwd
23:03:04 <petern> Ah but it uses the bindir.
23:03:47 <glx[d]> yes and windows also uses bindir, which is not build dir in your case
23:03:58 *** WormnestAndroid has joined #openttd
23:04:05 *** Wolf01 has quit IRC (Quit: Once again the world is quick to bury me.)
23:10:12 *** michi_cc[d] has joined #openttd
23:10:12 <michi_cc[d]> I haven't really tried to debug the regression itself, but for everything else using VS with a cmake-generated sln file works fine.
23:10:41 <petern> Is it just me using VS Code on Windows then...
23:12:36 <glx[d]> debugging regression is very rare, but now we know why it doesn't work for some
23:13:41 <petern> PS E:\src\OpenTTD\build> cp .\RelWithDebInfo\openttd.exe .
23:13:41 <petern> PS E:\src\OpenTTD\build> .\openttd.exe -x -c .\regression\regression.cfg -g .\ai\regression\test.sav -d script=2 -d misc=9 -QQ
23:13:43 <glx[d]> same issue would happen for any use of `-c` anyway, not specific to regression debugging
23:17:13 <petern> btw, given a c-string that could contain \n mid-way, how best to turn that into a std::string that ends just before the \n.
23:19:58 <glx[d]> find(_first_of) and substr ?
23:21:53 <petern> oh please... `static const size_t npos = -1;`
23:22:48 <glx[d]> well npos can be any "invalid" value
23:23:17 <petern> Just all my moaning about signed vs unsigned earlier and then this!
23:23:35 <petern> `line.text.erase(line.text.find('\n'), std::string::npos);` seems it might be the way.
23:26:36 <petern> Probably have to check that it exists first. Oh well.
23:28:34 *** Wormnest has quit IRC (Ping timeout: 480 seconds)
23:28:57 <glx[d]> ah yes it will throw if not found
23:54:39 *** Wormnest has joined #openttd
continue to next day ⏵
