IRC logs for #openttd on OFTC at 2023-05-09
⏴ go to previous day
01:26:03 *** WormnestAndroid has quit IRC (Remote host closed the connection)
01:26:10 *** WormnestAndroid has joined #openttd
02:34:14 *** Wormnest has quit IRC (Quit: Leaving)
03:04:15 *** debdog has quit IRC (Ping timeout: 480 seconds)
03:27:05 *** WormnestAndroid has quit IRC (Read error: Connection reset by peer)
03:28:43 *** WormnestAndroid has joined #openttd
04:45:04 <pickpacket> This is strange. I have autorenew enabled, set to renew vehicles 6 months before they expire, yet lots and lots of vehicles just aren't going to depots to get renewed.
05:07:40 <axet> sure. no longer avaiable
05:21:50 <pickpacket> but the asia star *is* still available, and if I manually order them to depot for service they get replaced
05:27:36 <axet> make sure they got to depot
05:39:24 <pickpacket> There are several depots along the way, they just don’t voluntarily enter them.
05:39:55 <axet> check if service enabled
05:40:14 <pickpacket> I have breakdowns set to none and automatic service set to none, but autoreplace is set to true
05:40:56 <pickpacket> having automatic service on when there are no breakdowns just causes unnecessary delays
05:41:35 <pickpacket> I was expecting autoreplace to override that, since it’s an independent setting
05:41:37 <axet> or you just trying to save money
05:42:19 <pickpacket> Well… I make more than £100m/year and have more than £5b in the bank. Money isn’t an issue
05:42:47 <axet> then let train rest every 6 months in depot
05:43:18 <pickpacket> That’ll just cause congestion by the depots
05:43:33 <axet> i guess it could b ea bug
05:44:36 <Rubidium_> the biggest pitfall with all autorenew/autoreplace is that vehicles look for depots like every day and up to a maximum pathfinder cost. And when a path reservation has been made beyond the junction to the depot, then it won't consider that depot anymore as it will continue its pathfinding at the end of the reservation
05:45:08 <Rubidium_> (though it'll count the pathfinder penalties up to the end of the reservation)
05:46:03 <Rubidium_> so if you have a siding of say 20 tiles, then it might not ever go there because it's pathfinder penalty is simply too high from the main line
05:48:28 <Rubidium_> all in all it's a massive cost-effort analysis. If you increase the maximum penalty, it will look further and it will be way more likely that it will take a branch that will not end at its original destination. To combat that, you would have to find the depot and then pathfind to its destination to see whether that'd work, which would be quite expensive
05:49:46 <Rubidium_> so... the problem can be solved if you throw enough CPU cycles at it, but people are already complaining that a single tick takes too long on their hardware ;)
05:52:02 <axet> yes my rpi only can run for 0.5 speed
05:58:00 <Rubidium_> maybe introducing a special conditional for orders so it can check "does this vehicle want to go to depot for service (including autorenew/autoreplace)", and then specify the depot to go to could largely solve the issue. Except ofcourse for situations where the depot you go to is very far from the previous stop, like just before then next station on the other side of the map; so it would somewhat force
05:58:06 <Rubidium_> you to put the depots soon after stations instead of before... although you could also be sneaky and add a waypoint just before the depot if/when there's only one route
06:09:40 <petern> It's possible to make it ignore the existing reservation. But presumably it follows it for a good reason.
06:10:23 <petern> Or just exclude the current reservation distance from the depot max distance
06:19:19 <andythenorth> goes it text stack for Horse vehicle names then?
06:19:29 <andythenorth> it's not hard, just fiddly, all the cases
06:19:50 <andythenorth> probably more 0xD000 fun
06:20:11 <pickpacket> I solve that by almost always having at least one depot directly on the line. Trains will never have to take a detour to reach that
06:20:54 <pickpacket> in this case they still don't go into depot to get replaced. Maybe that should be considered a bug?
06:24:20 <petern> "just" may be over simplifying it 🙂
06:24:54 <petern> First, try to find out if they are trying to go to depot at all...
06:30:00 <petern> Okay, how did you determine that?
06:32:36 <pickpacket> by looking at them and noticing that none of them is listing a depot as their next destination
06:32:42 <pickpacket> what did you have in mind?
06:37:24 <andythenorth> do they have any depots in the order list?
06:40:19 <pickpacket> Rubidium_, andythenorth: I have stations where the outgoing trains are split equally over two or more rails. I'd have to build a depot available from all of those tracks, which means that a train from one track needing service will cause stops and delays of trains on the other tracks too
06:40:47 <pickpacket> or is it possible to set an order that just says "go to any depot if needed"?
06:41:27 <petern> `if (Company::Get(v->owner)->settings.vehicle.servint_trains == 0 || !v->NeedsAutomaticServicing()) return;`
06:41:30 <andythenorth> dunno if it will solve the issue though
06:41:38 <petern> That one is weird... it's not possible to set servint_trains to 0.
06:49:48 <pickpacket> andythenorth: that'd do it I guess. I'll try it tonight when I get back home
06:54:43 <pickpacket> I hope that sort of setting doesn't make the trains go for service as if breakdowns were enabled, but only for replacement
07:19:52 <andythenorth> I think it will make them always visit a depot
07:20:17 <andythenorth> every time the order is encountered
07:21:49 *** m3henry has quit IRC (Quit: m3henry)
07:26:44 <axet> after year 2020+ game has no helicopters
07:32:41 <petern> Set engine never expire to true, or use a NewGRF that provides them.
07:33:23 <LordAro> and blame decisions made by CS in 1994
07:36:16 <LordAro> the default vehicles are, and always will be, defined by the original vehicles from TTD
07:36:34 <axet> ii guess we can add 1 helicopter
07:37:13 <LordAro> we're not going to, however
07:37:38 <axet> can we replace livestock with milk?
07:37:57 <LordAro> if you write a newgrf that does so, sure
07:38:06 <axet> this is barbaric eating living beings
07:46:28 <Rubidium_> YOU are the one transporting them to their death! If YOU do not transport them to the factory, they do not become food, so it is entirely your choice
07:49:27 <Rubidium_> but you probably shouldn't be transporting the grain/maize either, as there might be insects on them that are going to be eaten
07:51:07 <axet> slavery was funny 200 years ago
07:52:20 <pickpacket> axet: i agree that it's barbaric (although I eat meat myself -- can't blame me for consistency!). It's also very bad that coal and oil are prominent and pay well all through the game
07:52:26 <pickpacket> no green revolution there
07:53:20 <axet> this planet is not perfect. but at least we can stop eating THEM
07:54:07 <pickpacket> I'd love to make a NewGRF that over time makes coal and oil pay less over time and replace them with something else, but I don't know what that something else would be. Nor how to adjust their value over time
07:54:34 <axet> all will parish and love will be it
07:54:52 <pickpacket> axet: to be fair it is *a game*. Nobody's eating anyone for real
07:55:04 <pickpacket> there's a Soylent Green NewGRF
07:55:08 <LordAro> pickpacket: stop feeding (ha) the troll
07:56:11 <axet> treating living beings as stock makes me sick
07:57:10 <axet> common git drop master as branch
07:58:32 <pickpacket> as I said it's not actual real animals. Barely even pixels. And on top of that you can choose whether to transport them or not
07:59:37 <LordAro> pickpacket: stop feeding the troll-like behaviour
07:59:55 <LordAro> i predict they're going to antagonise everyone here and get banned shortly
08:00:02 <axet> how do you know axet is not a second pickpacket account?
08:01:39 <petern> Hmm, had free eggs delivered with milk yesterday, maybe omelette.
08:07:31 <andythenorth> for lunch though?
08:11:11 <pickpacket> andythenorth: I don't see why not!
08:14:07 <LordAro> andythenorth: you're an adult, you can do what you want!
08:21:12 <TrueBrain> No, there are still rules LordAro :p
08:21:29 <TrueBrain> At least, that is what the judge kept telling me
08:22:06 <axet> pickpacket i guess we can replace coal and oil with hydragen stations land and water based. like solar energy and wave energy
09:12:09 <petern> Oh balls, async methods can't have out parameters. Hmm.
09:13:37 <petern> TIL about "in" parameters, basically like const references in C++.
09:17:34 *** Flygon has quit IRC (Read error: Connection reset by peer)
09:18:58 <pickpacket> axet: but what would they generate?
09:20:09 <axet> coal mines become hydrogen solar plant. they will generate hydragen for transport. you transport it to the power plants.
09:21:13 <axet> oil rigs become hydrogen wave power plants. generate hydrogen
09:21:37 <petern> It's telling that we can't work out what to do without coal/oil chains even in a game :p
10:15:25 <andythenorth> if we had pipelines...
10:16:59 <Eddi|zuHause> realistic pipelines probably don't work well with the payment models
10:24:08 <Eddi|zuHause> effectively a pipeline would be a train which loops around, but only the car at a pumping station could be loaded, and only when the car is full the whole chain will move
10:24:35 <petern> Pipelines and conveyors?
10:25:29 <Eddi|zuHause> the difference between pipeline and conveyor would be that the conveyor can also move while empty
10:26:01 <petern> Only if you're thinking in terms of making them things vehicles run on.
10:52:54 *** D-HUND is now known as debdog
11:07:12 <andythenorth> "pipelines aren't gameplay" was a thing back in coop chat
11:07:46 <andythenorth> TBH pipelines can be done with trains, with compromises
11:27:31 <petern> Is providing a value like "100000" on the textstack simple or problematic?
11:34:06 <glx[d]> Depends if it's expecting a word or a dword
11:35:13 <glx[d]> And a register may contain two words, so sometimes you need a {SKIP} to introduce offset
11:45:38 <petern> I was thinking about this {FORCE} thing, and whether providing "100000" is harder than "100"
11:46:34 <petern> Or maybe NML just abstracts it anyway.
11:59:49 <petern> GtHub has having a moment right now.
12:19:31 <glx[d]> in nml side it's a pain to set string parameters 🙂
12:20:20 <glx[d]> registers are filled manually and author needs to do all shifting if needed
12:23:39 <glx[d]> anyway for {FORCE} do you expect a word or bigger ?
12:26:17 <glx[d]> hmm if we go for N instead of kN, I think it should be a dword
12:33:02 <petern> Yeah, if it's kN then word is fine, N definitely needs a dword.
12:33:13 <petern> I don't know if that's a problem though 🙂
12:38:17 <glx[d]> as we're adding a command we can easily go for a dword, but that require careful management on author side (though not worse than word already is)
12:49:11 <petern> It worked, but couldn't attach screenshots.
14:13:59 *** axet has quit IRC (Quit: Leaving.)
14:55:14 <petern> @Rubidium, I think that stuff is handled by ConvertKmhishSpeedToDisplaySpeed()
14:55:39 <petern> Where previously we probably passed Kmhish to the units conversion.
15:28:59 *** HerzogDeXtEr has joined #openttd
15:47:34 <glx[d]> ok did look at the code, and grf text stack handling is very simple on openttd side compared to newgrf side, openttd just merge the 6 registers' content into a byte array
15:55:18 <glx[d]> filling the registers on the newgrf is a real pain if you have args of different size
16:05:25 <Eddi|zuHause> we should just introduce a new PUSH_TEXT(value, size) command
16:06:50 <Eddi|zuHause> thing about grfspec is, you can't just rip out the old stupid stuff
16:10:27 <glx[d]> there's already PUSH_WORD
16:11:41 <glx[d]> but that's to inline values in the string
16:11:43 <JGR> Eddi|zuHause: You can deprecate old functionality and "remove" it when the GRF version is eventually bumped
16:13:11 <glx[d]> I'm just trying to imagine filling the registers with byte,dword,word,byte
16:13:36 *** Wormnest has joined #openttd
16:13:37 <glx[d]> so much anding, shifting, oring
16:20:58 *** gelignite has joined #openttd
16:21:15 <glx[d]> would be so much simpler to have an \2 operator to push the values
16:26:07 <petern> It seems to be a bit wet here...
16:26:39 <LordAro> oh yes, i should check forecast before trying to go out this evening
16:28:14 <Eddi|zuHause> JGR: i'm not seeing any benefit of that
16:29:48 <JGR> We're now on GRF version 8
16:30:03 <JGR> The various version bumps were not just done for fun
16:30:08 <glx[d]> previous version still needs to be supported
16:31:04 <JGR> That does not mean that every new feature needs to be simultaneously supported with every feature ever used in a previous GRF version
16:36:06 <Eddi|zuHause> sure... we can deprecate the current registers, but then we shouldn't introduce the new behaviour before the removal, because having both methods in parallel makes things more complicated... or we can just add a TTDPatch flag which method should be used, without needing a version bump
16:38:29 <JGR> TTDPatch flags are for signalling from OpenTTD to the GRF
16:38:39 <petern> What you are saying makes no sense 🙂
16:39:03 <JGR> There isn't any reverse signalling path in vanilla for "I would like to opt into X", except the version number
16:40:36 <glx[d]> I don't really see an issue with having registers way and another way in parallel, most likely they won't be used in the same varact2 chain
16:41:09 <JGR> How would the other way be signalled?
16:43:24 <Eddi|zuHause> i think i might have been confusing that with action0 flags which enable certain callbacks
16:43:49 <petern> Probably doesn't need to be signalled... just use the new way if you want to use the new way.
16:44:44 <Rubidium_> it allows the NewGRF to signal how to interpret the palette and what blitter it would like
16:46:31 <glx[d]> I think having new varact2 operators to push values on text stack, and on openttd side using them if any has been pushed else falling back to the registers way
16:47:08 <andythenorth> all you need is a python compile, help from 2 people here for an hour, and some code provided by GPT
16:47:14 <andythenorth> "Text stack is fine"
16:47:36 <glx[d]> and you're only doing it with words
16:47:49 <Eddi|zuHause> andythenorth: you're not (yet) mixing different sizes
16:48:03 <JGR> The print signed byte code is likely rarely used
16:48:54 <andythenorth> if you're manually writing the stack one case at a time, mixed sizes are fine
16:49:04 <JGR> You could make life easier by doing away with different size stack reads and making them all 32 bits
16:49:07 <andythenorth> if you have generic methods and templates
16:49:08 <Eddi|zuHause> JGR: why would that be helping the debate?
16:49:59 <Eddi|zuHause> JGR: you're still "breaking" the existing code, requiring the same compatibility measures,
16:50:45 <andythenorth> I thought we had a version system 😛
16:50:57 <JGR> Existing already written GRFs which already work still need to be able to work in future versions
16:51:07 <glx[d]> main issue is it's not a stack on newgrf side, it's just some abused registers
16:51:11 <andythenorth> or we issue deprecation notices
16:51:15 <JGR> Therefore, existing mechanisms need to be retained in some code path
16:51:20 <andythenorth> it's just pixel trains
16:51:26 <andythenorth> I know there will be drama, but eh
16:51:50 <Eddi|zuHause> JGR: but "just make everything the same size" fixes only part of the problem
16:52:14 <Eddi|zuHause> JGR: you're still required to manually address the registers, which a proper stack wouldn't
16:52:29 <Eddi|zuHause> JGR: and you're artificially limiting the amount of parameters
16:53:10 <Eddi|zuHause> so you're proposing a "solution" that doesn't solve it, yet is exactly as complicated
16:53:24 <JGR> You're completely missing the point of what I am saying
16:54:07 <JGR> Never mind, when there is some code to look at, I can be more concrete about what I am saying
16:59:41 <TrueBrain> we have too many draft PRs on the first page, lol 🙂
17:00:18 <TrueBrain> well, "too many" is an opinion, not sure it is bad; it is funny 😛
17:02:51 <TrueBrain> Ninja fixing what Makefile keeps doing wrong; nice 🙂
17:05:44 <Rubidium_> TrueBrain: yeah, yay rabbit holes, right?
17:07:35 <andythenorth> Horse text stack then?
17:07:40 <andythenorth> or WOT Blitz tanks?
17:14:40 <Rubidium_> axet: please come back when quake has implemented 2 million objects that get state changes every second and need to be kept up to date in sync between all clients. For something like quake, with maybe 10 parameters per player (location (x, y, z), movement vector (x, y, z), acceleration vector (x, y, z), player-id, health, weapon?) you can get away with extrapolating and every now and then just syncing
17:14:46 <Rubidium_> the whole game state. I doubt the game state will be significantly more than 1 kB, whereas you are complaining that copying the game state of OpenTTD takes too much time
17:15:23 <petern> fps-based ticks is exactly the opposite of what is needed 🙂
17:16:11 <axet> ok. but it been said ALL games using lockstep
17:16:29 <axet> BTW sv_fps = 20. which is 50ms
17:17:21 <axet> chaing sv_fps to 1 does not affect game speed
17:17:51 <axet> maybe 27 ms not the optimal
17:18:24 <petern> Not for your old Raspberry Pi, certainly.
17:18:26 <axet> lets say 40ms, 2000 / 40 = 50. day length can be 50
17:19:05 <petern> It's a Raspberry Pi 1, they are 10+ years old.
17:19:27 <axet> no fan based, a lot of dust
17:20:53 <andythenorth> but we used to run OpenTTD on old macs?
17:20:58 <glx[d]> 256x256 maps should run fine
17:25:40 <glx[d]> auto cancelling is so nice
17:29:51 <Rubidium_> you know you don't need to rebase for every commit? :D
17:38:49 <TrueBrain> Rubidium: your suggestion to avoid 2 copies is not as cut&dry without delving into the C-world again .. the replacing or \r and \n is a bit annoying in those regards, as it needs to be done before StrMakeValid
17:39:09 <TrueBrain> (which you can't do on a string-view, ofc)
17:40:32 <TallTyler> TrueBrain: Someday at your convenience (really no hurry) I could use your eyes on #10700 to maybe spot what I’ve done wrong that makes MinGW (but nothing else) fail regression. I’ve been staring at this stuff so long that I must be missing something obvious. 🙂
17:41:20 <TrueBrain> will check it out tomorrow 🙂
17:41:54 <TrueBrain> Rubidium: we need a `StrMakeValidInPlace` for std::string 😛
17:42:51 <Rubidium_> TrueBrain: I think changing StrMakeValid to have std::string_view as parameter is not much more than actually changing the type of the parameter. All StrMakeValid does it calling functions std::string_view also has
17:43:15 <TrueBrain> wouldn't avoid the copy however
17:43:32 <TrueBrain> I still need a copy for replacing \r and \t, and one for StrMakeValid 🙂
17:47:45 <TrueBrain> best I can come up with, without delving even deeper in the rabbithole 😛
17:53:01 <Rubidium_> oh... string_view is annoyingly only returning const referencing... that's a bummer
17:53:50 <TrueBrain> that is the whole idea, isn't it? 😄
17:54:35 <glx[d]> TallTyler: based on a quick reading of the log, it seems time is not the same, expenses and last month productions don't match
17:54:36 <Rubidium_> that's kinda true as well yes
17:55:29 <glx[d]> But I could try locally to check
18:10:53 <TrueBrain> you didn't even use my latest update 😛
18:11:02 <TrueBrain> but yeah, do we really want another option in StrMakeValid?
18:15:59 <TrueBrain> and ..... full recompile
18:16:03 <TrueBrain> well, at least it is now only 2 minutes
18:16:13 <Rubidium_> well... do we really want to "make the string valid" before "StrMakeValid"
18:16:40 <Rubidium_> I'm a bit bummed you got the same absolute improvement as I got from it
18:17:00 <Rubidium_> I would have loved your relative improvement though!
18:17:59 <TrueBrain> it was by far the bigger improvement of the two 😛
18:18:00 <Rubidium_> didn't help; they were worse for me
18:18:24 <TrueBrain> well, guess my 5GHz CPU and M.2s finally help out too
18:19:04 <TrueBrain> have yet to try my new AMD CPU in my server .. see how long it takes to build ..
18:19:08 <TrueBrain> anyway, I -think- I did that correctly
18:19:17 <TrueBrain> and tnx; I like that solution 🙂
18:19:41 * Rubidium_ remembers the clock drift days :D
18:20:16 <Rubidium_> oops... seems I left a small present for you
18:21:40 <TrueBrain> the one time I edit in vim
18:21:44 <TrueBrain> regretting is instantly
18:41:57 <pickpacket> petern: did something happen to discord?
18:44:43 <DorpsGek> - Update: Translations from eints (by translators)
18:58:18 <michi_cc[d]> Was there any conclusion for last night's discussion about a possible `SpecializedConsist` in contrast to some `switch`s? Otherwise I'm just going to throw some dice.
19:04:43 <petern> Object oriented would be nice.
19:07:27 <petern> I don't know exactly what you had in mind, but switches seems a bit wrong.
19:09:15 <michi_cc[d]> Okay, `SpecializedConsist` it is.
19:09:34 <michi_cc[d]> (Well, not literally, but like the `Vehicle` class stuff.)
19:13:34 <petern> What do you prefer? :p
19:21:41 <michi_cc[d]> The classes are a bit more work initially getting the saveload stuff proper, but probably the better solution for the long term.
19:24:42 <andythenorth> I know it's python and irrelevant to the context, but Horse trains are all subclasses of Consist and Vehicle
19:24:59 <andythenorth> with subclass methods, except where they're if or switch 😛
19:25:05 <andythenorth> or handled in the templating
19:25:16 <andythenorth> consistency is hard 😛
19:25:40 <petern> Hmm, why is my network no longer working...
19:25:54 <andythenorth> magnetic bees of course
19:29:40 *** gelignite has quit IRC (Quit: Stay safe!)
19:40:29 *** WormnestAndroid has quit IRC (Remote host closed the connection)
19:40:30 *** WormnestAndroid has joined #openttd
19:44:09 <petern> tcpdump is pretty shit
19:46:14 <petern> Chain FORWARD (policy DROP 18049 packets, 3376K bytes)
19:46:27 <petern> Docker decided to manage a firewall.
19:51:20 <glx[d]> TallTyler: at least I can confirm regression fails with mingw on my machine too
20:00:40 <petern> Huh, weird, my desktop just switched from night mode to daytime mode (more blue)
20:07:01 *** Markk has quit IRC (Remote host closed the connection)
20:20:11 *** axet has quit IRC (Quit: Leaving.)
20:28:41 <glx[d]> that explains why regression fails, but opens a lot more questions
20:29:49 <glx[d]> let's check with VS build
20:45:25 <michi_cc[d]> We don't have enough open PRs yet, let's add some more 😜
20:47:49 <michi_cc[d]> No, just some random cleanups.
20:55:11 <glx[d]> ok with VS build there's no weird finance window and script debug window works (only tested with #10700), building master with mingw to check if script debug window is fine
20:56:15 <TrueBrain> be advised: you reached your daily quote 😛
20:57:04 <michi_cc[d]> That's okay, it resets in an hour anyway 🙂
20:57:27 *** keikoz has quit IRC (Ping timeout: 480 seconds)
20:59:31 *** WormnestAndroid has quit IRC (Remote host closed the connection)
21:00:14 <TrueBrain> someone has been busy
21:00:32 *** WormnestAndroid has joined #openttd
21:01:31 <petern> Although there are some loops that could be replaced with std::reduce.
21:02:05 <petern> But std::reduce is actually a bit less clear because you need to use begin(), end() again, and a lambda function.
21:03:27 <michi_cc[d]> TrueBrain: I made some space 🙂
21:03:34 <TrueBrain> good; your quote is reset now 😛
21:03:41 <TrueBrain> silly petern , making all these PRs, but merging? 😛
21:04:12 <petern> It feels more legit if someone else merges 😉
21:04:23 <petern> Also I have been busy in rabbit holes.
21:05:01 <michi_cc[d]> You could rebase #10585 for more clearing out.
21:05:02 <petern> Like, the waypoint search filter was at the end of one rabbit hole, and then I started on revamping the station/object windows to do something similar, and hit another rabbit hole...
21:06:11 <petern> I could, but I'm still not sure if 10585 is even the right thing to do.
21:06:20 <petern> But okay, I'll rebase it.
21:07:07 <petern> (Ir probably compiles?)
21:07:34 <petern> Aww yes, my ownCloud works again now that forward is not set to deny ;D
21:09:07 <Rubidium_> removing 1 stredup... already at 43 kB of probably atomic change :(
21:09:47 *** HerzogDeXtEr has quit IRC (Read error: Connection reset by peer)
21:18:28 <glx[d]> ok in master script debug windows works fine for mingw, definitely something wrong in #10700
21:21:39 <petern> Oh, weird, I wonder how that compiled for me... and the CI.
21:23:39 <TrueBrain> glx[d]: possibly it compares economy with calendar or something silly
21:24:14 <glx[d]> dunno but finance window pops every day
21:24:57 <glx[d]> script debug window being empty is another weirdness
21:25:10 <glx[d]> really looks like memory corruption somewhere
21:25:48 <TrueBrain> what ever MSVC has for that 😛
21:50:23 <glx[d]> so annoying to need to run ctest at least once before being able to debug regression
22:03:10 *** ChanServ sets mode: +v tokai
22:09:14 *** Wolf01 has quit IRC (Quit: Once again the world is quick to bury me.)
22:10:02 *** tokai|noir has quit IRC (Ping timeout: 480 seconds)
22:10:39 <glx[d]> ah I need to update nml PR
22:17:45 <glx[d]> and updated the standalone build
22:25:24 *** nielsm has quit IRC (Ping timeout: 480 seconds)
22:28:08 <TrueBrain> lol; nice catch JGR 🙂
22:40:29 <glx[d]> oh might explain mingw behaviour
22:40:52 <petern> One of those "how did it ever work"
22:43:11 <TallTyler> Yeah, that’s a strange one. I feel pretty stupid right now. 😛
22:43:25 <TallTyler> But will fix that tomorrow and see if it resolves the issue!
22:43:53 <petern> I had a similar issue with interface-scaling that only affected emscriptem, so was hard to find.
22:45:02 <petern> I had managed to take references to things out of scope.
22:45:14 <glx[d]> trying clang64 env now, and it doesn't build
22:45:32 <glx[d]> ```llvm-rc: Error in VERSIONINFO statement (ID 1):
22:45:32 <glx[d]> FILEVERSION fields (20230507) does not fit in 16 bits.
22:45:57 <glx[d]> msvc is happy with that
22:48:26 <JGR> I caught it by using the undefined behaviour sanitiser, it flagged up an out of range bitshift for one of the month tests
22:48:56 <JGR> You can run that at the same time as the address sanitiser which is pretty handy
22:50:50 <petern> `FILEVERSION ${REV_MAJOR},${REV_MINOR},HIWORD(${REV_ISODATE}),LOWORD(${REV_ISODATE})` maybe?
22:50:59 <petern> Not the same value of course because it can't me...
22:51:22 <glx[d]> maybe something to add to the "GCC - Dedicated" CI target
23:01:47 <glx[d]> I like when execution doesn't match documentation `generated\ottdres.rc(80): error RC2104: undefined keyword or key name: HIWORD`
23:02:08 <glx[d]> but doc says `Therefore, if version is defined by the DWORD values dw1 and dw2, they need to appear in the FILEVERSION statement as follows: HIWORD(dw1), LOWORD(dw1), HIWORD(dw2), LOWORD(dw2).`
23:02:26 <petern> Yes, that is where I was it 🙂
23:30:59 *** gelignite has joined #openttd
23:31:01 *** gelignite has quit IRC (Remote host closed the connection)
continue to next day ⏵
