IRC logs for #openttd on OFTC at 2023-12-29
⏴ go to previous day
04:04:06 *** debdog has quit IRC (Ping timeout: 480 seconds)
04:07:01 *** Wormnest has quit IRC (Quit: Leaving)
07:30:57 *** tokai|noir has joined #openttd
07:30:57 *** ChanServ sets mode: +v tokai|noir
07:37:51 *** tokai has quit IRC (Ping timeout: 480 seconds)
07:43:02 <reldred> _glx_: I'm having some extremely smoothbrained moments right now, I wiped vscode and reinstalled clean, only installed cmake and cmake tools extension, did a fresh clone of openttd, and this is what it looks like:
08:10:54 <andythenorth> reldred: High on my list for “let’s crowdfund this person some therapy”
08:18:46 <emperorjake> I see NewCC got a mention. Believe me, if I could have changed the names of the colours, I would have. The original version even came with a patch but it wasn't worth the effort
08:19:51 <emperorjake> and I've been thinking of attempting a rewrite of NewCC with individually selectable colours by parameter, but if this gets merged I'll be spared the trouble
08:20:47 <reldred> _glx_: Okay so, I figured out finally how to get vcpkg integrated, but no idea why my list of kits looks different than yours
08:34:06 <peter1138[d]> But now, cycling.
08:34:37 <reldred> I need to get out on my bmx, start learning how to bloody ride again
08:34:39 <andythenorth> probably more weather than cycling, looking at my outdoors
08:36:51 *** luk3Z[m] has quit IRC (Quit: Client limit exceeded: 20000)
08:45:48 <reldred> peter1138[d]: that's not cycling
08:52:53 <locosage> hm, apparently helipad is action5 "gui" range
08:56:28 <locosage> also, what's the point of action5 when actionA works for new sprites too?
08:57:25 <locosage> I guess it came first judging by the number
08:57:41 <locosage> So better question would be can I just ignore action5 and use actionA instead?
09:02:37 <locosage> it's much simpler to just use sprite number than trying to navigate those partially undocumented action5 ranges
09:15:06 <_jgr_> Action A is only sensible to use for TTD-era sprite IDs which never change, or GRM
09:16:11 <locosage> so you mean extra sprite ids can change?
09:16:36 <locosage> why does actionA even allow to replace them then?
09:17:36 <Rubidium> see it rather that it doesn't specifically disallow to replace them
09:19:14 <Rubidium> but look at the specs, and you'll see that there are quite a few action5s with a number of sprites that has changed through the versions. Each change to num-sprites will likely have renumbered a number of other sprites
09:19:37 <_jgr_> There are GRFs which use action A with whatever number they got from the sprite aligner window, and these break whenever a new release comes out
09:20:35 <locosage> I'm not surprised, it's not even mentioned in spec that it can break
09:23:17 <Rubidium> though, did they follow the method on how to get the sprite number in the specification?
09:27:13 <Rubidium> looking up the sprite number in trg1.pcx
09:27:32 <Rubidium> any action 5 sprite number is not in there
09:28:22 <locosage> well, it's worded more like a suggestion
09:28:46 <locosage> you can also find them in sprite aligner :p
09:31:51 <Rubidium> but is the sprite aligner mentioned in the specification?
09:34:18 <Rubidium> ah well, I hope the specifications are better now ;)
09:46:15 <truebrain> brrr, NetworkContent has some weird code 😛 Some functions .. "grew a bit" 😄
09:48:36 <truebrain> the easy way to make it thread-safe is by copying the download in a temporary buffer, and put that on the queue .. but that adds yet-another-copy
09:48:43 <xarick> I keep stumbling on the special handling of aircraft and non-leading train engines, wagons or articulated engines, can't do the shift to vehicle_lists as often as I hoped
09:48:59 <truebrain> a better way would be to move the "write to disk" part in the callback, and do the GUI communication via a queue
09:49:04 <truebrain> but boy .. that code .. is something special 😄
10:00:31 <jfs> Remember that the standard library also has promise/future classes, which are quite useful for job queue kinds of things
10:00:33 <locosage> Rubidium: yeah, looks better now
10:00:48 <locosage> though I think actionA should just ignore sprites over the base range
10:01:00 <locosage> better to break grf in development than on next release
10:01:22 <jfs> The one thing that promise/future does not really support is partial results
10:04:30 <truebrain> had to double-check if Windows is actually creating a new thread for downloads, but it actually does
10:05:39 <truebrain> now the question .. am I going to untangle the network-content stuff, or am I going to just fix the other race-conditions .. hmmmmmmmm
10:05:47 <truebrain> untangling can introduce unrelated bugs
10:05:58 <truebrain> but working around it just causes more memory overhead for no actual good reason
10:06:21 <xarick> It changes the rules a little bit... I think that check in engine preview accounts for engines that are attached as wagons where the main front vehicle is not a wagon itself. But with this change, those wagon leading vehicles won't be accounted for.
10:07:00 <xarick> meaning that, engines that are attached to those wagons, are skipped
10:07:33 <truebrain> for WinHttp we already create a buffer and free it, for every chunk .. so WinHttp already isn't zero-copy .. bit weird, but okay
10:15:44 <xarick> too many compromises for my liking...
10:59:46 <truebrain> okay, 3 mutexes later, and it is working 😛 Let's see if this can be done a tiny bit less ... mutexy 😄
11:00:18 <reldred> god I don't even know what a mutex is, I only just learnt tonight how to chain ternary operators 😛
11:00:31 <truebrain> you learnt something bad, I see 😛
11:00:46 <reldred> Admittedly it was just for NML 😛
11:04:05 <andythenorth> chaining ternary is evil 😛
11:04:07 <andythenorth> especially in nml
11:09:13 <jfs> truebrain: atomic int for progress reporting and a future for delivering the final result? I haven't looked at your current code
11:09:31 <truebrain> you do understand that you are now just blabbing random words, right? 😄
11:10:07 <xarick> can I still use codechange if I'm changing the rules a little bit?
11:10:10 <truebrain> I do appreciate you want to help; but that is not a problem I am solving 🙂 The complexity of HTTP handling is more .. complex 🙂
11:11:50 <xarick> okay, I better start to be explicit. Describe in the commit message what I compromised...
11:14:00 <reldred> andythenorth: too bad I dun did it 😛
11:14:48 <truebrain> lolz, I now have Windows acting lovely weird when I cancel downloads .. works fine on Linux, but boy, on Windows it does something funky 😛
11:16:45 <truebrain> ah, there we go .. yeah, that was a bit silly of me 🙂 Not actually failing the connection 😛
11:24:31 <_zephyris> Aww, I was hoping that using the unicode private range entries for train/lorry/bus/etc. would give nice icons in savegame names...
11:25:29 <jfs> that might be an OS limitation, not sure
11:26:01 <jfs> on the other hand, the filename is definitely not composed of question marks...
11:27:37 <truebrain> _zephyris: Pushing the boundaries! 😄
11:30:24 <truebrain> ```==58794== Conditional jump or move depends on uninitialised value(s)
11:30:24 <truebrain> ==58794== at 0x11CC50D: NPFShipCheckReverse(Ship const*, Trackdir*) (npf.cpp:1234)```
11:35:17 <xarick> Is this good english enough?
11:35:17 <xarick> > Change: Iterate group vehicle lists for DisasterTick_Ufo and DisasterTick_Big_Ufo
11:35:17 <xarick> > As a compromise, the result of this change differs from the original. The iteration order changed from lowest to highest vehicle index to lowest to highest company index plus the order at which each vehicle was added to each list regardless of their index.
11:36:44 <xarick> so the resulting picked vehicle that the ufo will destroye will be another
11:41:18 <Rubidium> _zephyris: I think it's the fact that StrMakeValid under normal circumstances does not allow control codes, which are (also) in the private unicode range. Potentially adding `, SVS_ALLOW_CONTROL_CODE` to the StrMakeValid call in fios.cpp:328 will make it appear
11:42:43 <Rubidium> xarick: that commit message makes all my desync-spidey senses tickle enormously
11:43:35 <xarick> well, it's what I think it does
11:44:37 <xarick> std::vector, adding and removing from a list
11:44:44 <_glx_> reldred: My list is different because I already had CMakePresets.json
11:45:13 <xarick> my goodness, these embeds in discord are sometimes lame
11:46:46 <reldred> _glx_: All good. I got it to build in the end. Just as a sidenote, how do I do the old 'make install' that throws everything into an output folder?
11:47:16 <truebrain> `Build` -> `Install OpenTTD` ? 😄
11:54:56 <jfs> ugh all those raw buffers in the network code makes me uncomfortable
11:55:11 <jfs> why do we still not have a ByteBuffer class or similar?
11:56:02 <jfs> which can then be wrapped in a std::unique_ptr, or even just itself have unique_ptr semantics (in that it can only be moved and not copied, except perhaps via an explicit copy constructor which creates a new buffer)
11:57:51 <Rubidium> because nobody put the effort in to change it?
12:04:12 <xarick> hmm nielsm, looks like you found a bug... I'm bad at logic
12:07:00 <xarick> these neutral stations can't ask for a list of road vehicles nor trains
12:07:38 <xarick> unless somehow some bad function can pass that
12:08:39 <xarick> oil rigs are only expected to ask for a list of aircraft and ships
12:11:08 <xarick> if (vli.vtype != VEH_AIRCRAFT && vli.vtype != VEH_SHIP) when this is true, it is garanteed that the station owner is from a real company, and not neutral
12:11:19 <xarick> yep, it's correct after all
12:12:27 <xarick> maybe i should add an assert somewhere there?
12:15:19 <jfs> but what if at some point neutral stations with other transport types are added to the game? then someone has to remember to adjust that part of the code
12:15:42 <jfs> isn't it simpler to just check "if the station is neutral owner then always check vehicles from all companies"
12:19:02 <xarick> I was looking for performance.... getting a list of vehicles going to a station is very much core for an AI
12:19:27 <xarick> let me think what I can do
12:19:27 <truebrain> lol @ codeQL .. you are not wrong, but .. really? 😄
12:20:36 <jfs> xarick: the case of of neutral stations is rare though so it's unlikely to be the one tipping the scales
12:21:22 <xarick> oh but this is in the gui part... my bad
12:21:29 <xarick> it's not in the script part
12:24:59 <xarick> can asserts return true?
12:25:59 <xarick> if (vli.vtype != VEH_AIRCRAFT && vli.vtype != VEH_SHIP && assert(vli.company != OWNER_NONE) && vli.company != c->index) continue; it doesn't work 😦
12:26:13 <truebrain> how to tell you don't know what an `assert` does without telling you don't know 🙂
12:28:15 <xarick> I don't understand yet how these purple functions work
12:30:28 <xarick> if (vli.vtype != VEH_AIRCRAFT && vli.vtype != VEH_SHIP) assert(vli.company != OWNER_NONE);
12:30:33 <Rubidium> xarick: why did you make me remember the old station algorithm implementation?
12:31:24 <xarick> on a build with disabled asserts, is the condition still tested?
12:32:12 <xarick> what will the compiler do here?
12:35:08 <truebrain> hmm .. we can't make a dynamic list of widgets, can we? All custom draw if you want that, if I remember correctly ..
12:36:24 <truebrain> `Reason: Floating point exception`
12:36:39 <truebrain> didn't know we did floating points in windows 🙂
12:37:24 <truebrain> `num_rows = r.Height() / row_height;`
12:37:32 <truebrain> I guess division by zero 😄
12:40:08 <peter1138[d]> locosage: Yes, it's not that it allows them, it just doesn't specifically disallow them. Yet.
12:40:31 <peter1138[d]> Yes, you can create a dynamic list of widgets.
12:40:50 <truebrain> all examples I found have a fixed length on first opening
12:40:53 <truebrain> you have an example?
12:41:10 <peter1138[d]> Nope, there's no code that does it 😉
12:41:19 <truebrain> ....... you are of no use to me! 😛 😛
12:41:39 <peter1138[d]> What's the intention?
12:41:44 <truebrain> for these social plugins
12:41:50 <truebrain> I want to show in the Options menu which are loaded
12:41:54 <truebrain> and what state they are in
12:42:08 <truebrain> and possibly in the future a dropdown for each
12:42:09 <andythenorth> peter1138[d]: Flat Socials
12:42:22 <peter1138[d]> Okay, so for everything else that is downloadable like that we just list in a WWT_MATRIX.
12:42:35 <truebrain> yeah, but a WWT_MATRIX means I need to do all the stuff myself 😛
12:42:50 <truebrain> and especially as I want a dropdown on each line .. I was not looking forward to that 😛
12:43:15 <peter1138[d]> You might be able to use NWID_MATRIX.
12:43:35 <peter1138[d]> Normally we just have a single panel inside them, but maybe a container with more widgets inside that would work.
12:44:11 <peter1138[d]> Hmm, probably not actually, dropdowns need widget IDs and anything inside a NWID_MATRIX doesn't have one.
12:44:31 <peter1138[d]> Okay, so there are several places where we dynamically create widgets.
12:44:55 <peter1138[d]> You could use that, and then if you need to add/remove them just reinitialize the window.
12:45:01 <truebrain> yeah, but all "on-open", right? So I have to rebuild the window when it changes?
12:45:52 <peter1138[d]> But I don't see a particular reason why you couldn't add to a container dynamically to be honest. But nothing does that currently.
12:46:13 <truebrain> I will fiddle a bit, see what I can come up with
12:46:17 <truebrain> just so you can laugh and make it better 😛
12:47:14 <peter1138[d]> I know how much you love UI code 🙂
12:47:44 <truebrain> it has gotten a lot better lately
12:47:48 <truebrain> still a drag to recompile every change
12:49:59 <truebrain> owh, I found a bit of an example of what I am sort-of after: NewGRFDisplay
12:52:02 <peter1138[d]> There's some for creating company buttons.
12:52:11 <peter1138[d]> The NewGRF one is a full-on custom widget.
12:52:27 <truebrain> yeah, but it tells me how to embed a widget-list 🙂
12:52:38 <peter1138[d]> Hmm, did I actually PR my changes to widgets?
12:52:47 <peter1138[d]> If it's a still a linked list, I didn't.
12:53:21 <peter1138[d]> I have a changeset that changes it to `std::vector<std::unique_ptr<>>`, which would make dynamic layouts a lot easier
12:53:46 <truebrain> `NWidgetFunction` returns `NWidgetBase *`
12:54:13 <truebrain> so I was just looking how to chain those 🙂
12:54:38 <peter1138[d]> Hmm, object::colour is actually 2CC merged into a byte.
12:55:50 <peter1138[d]> Objects can have 2CC. Companies can have 2CC. But company-owned objects only get 1CC.
12:56:36 <truebrain> yippie, I can make N frames now .. okay ... now to set properties on them ...
12:58:23 <peter1138[d]> Oh maybe that's only conversion.
12:59:34 <truebrain> hmm ... can I also make the index dynamic ... hmmm
13:00:12 <peter1138[d]> Only on init setup currently.
13:00:30 <peter1138[d]> I also have a patch that simplifies how that is set up.
13:00:38 <truebrain> hurry up with those patches already 😛
13:07:00 <peter1138[d]> Typical peter-"I have a patch for that"-1138.
13:07:42 <truebrain> the `SetDParamStr` mostly, is a bit .. well .. it is something 😛
13:07:44 <_glx_> Isn't it "I have a branch" now?
13:08:49 <truebrain> I can use `SetStringParameters` btw to make it a bit nicer; but that is just "making it nicer"
13:08:51 <peter1138[d]> truebrain: as a proof-of-concept, probably. Of course a container already has a (linked-list lol) list of widgets.
13:09:15 <truebrain> the only thing is that I never actually draw the vertical, but .. I guess it doesn't draw anything anyway 😛
13:09:48 <peter1138[d]> Tbh making custom widgets is probably better than shoving it all in the window handler like we normally do
13:12:13 <peter1138[d]> Ok, let's find it.
13:12:35 <truebrain> hmm, `SetStringParameters` is always called on the Window itself .. which makes sense
13:12:47 <peter1138[d]> It's called by the leaf widget, yes.
13:12:49 <truebrain> but that makes for weird code, parts of it in the Window, parts in the Widget ..
13:13:02 <truebrain> can I delegate it to a widget back .. hmm ..
13:15:50 <truebrain> I want to get the pointer of the NWidgetFunction from the Window .. is that possible? 😄
13:16:13 <truebrain> (sorry for all the weird questions, and me wanting something that is not "common" 😛 )
13:17:03 <peter1138[d]> The NWidgetFunction is in the WindowDesc, not the Window.
13:17:21 <truebrain> yeah, but it is somewhere in the chain in the Window widgets 😛
13:17:29 <truebrain> but I guess that is a bit to weird to find it like that
13:17:30 <peter1138[d]> That's not the function itself.
13:17:42 <truebrain> no, I want a pointer to the instance
13:17:44 <peter1138[d]> The widgets contain the result of the function.
13:18:05 <peter1138[d]> If you want to get instance that was made, then it's this->GetWidget<Whatever>(index)
13:18:21 <truebrain> the issue is ... NWidgetFunction doesn't accept an index 😛
13:18:47 <truebrain> wait, I can assign one ofc
13:18:56 <peter1138[d]> You assign it, yes 🙂
13:19:13 <truebrain> hmm .. how do I do that .. hmm
13:19:15 <peter1138[d]> Oof, must be in my wsl patches. Been a while.
13:20:32 <truebrain> `NWidgetVertical` has no `SetIndex` .. awh
13:21:46 <truebrain> on leafs only, I guess?
13:21:51 *** D-HUND is now known as debdog
13:23:00 <peter1138[d]> You can look at at the network content window does it.
13:23:24 <peter1138[d]> (Or was it the server list... can't remember)
13:23:33 <peter1138[d]> One of them has a custom widget with an index.
13:23:43 <truebrain> that will be a fun ... search 😛
13:24:36 <truebrain> I do not know what I am looking for, nor where exactly to find it, so I can't find anything that seems related 😦
13:24:51 <peter1138[d]> Search for nested_array
13:24:58 <peter1138[d]> widget.cpp has a lot
13:25:11 <peter1138[d]> w->nested_array[this->index] = this;
13:25:28 <peter1138[d]> just set "this->index" to be whatever you want.
13:25:40 <peter1138[d]> WID_something preferably 🙂
13:25:54 <peter1138[d]> No need to actually have an index member.
13:26:46 <_glx_> possibly not reusing existing index 😉
13:26:50 <truebrain> okay, so next challenge is to have a Window pointer available at some point for me to do that 😄
13:27:05 <truebrain> `SetupSmallestSize` is used for that
13:29:55 <truebrain> shockingly, that seems to work 🙂
13:31:48 <truebrain> next challenge .. `SetStringParameters` is also called in `SetupSmallestSize` ... which has a lot of code in `NWidgetVertical`, so I can't do the trick I was doing there .. hmmmm
13:33:13 <peter1138[d]> Okay, a few merge conflicts, let's see if I got it right.
13:33:36 <truebrain> I could do a bitmask on the index, to know which iteration I have, but that seems like a bad solution ...
13:33:43 <truebrain> is there somewhere else I can hide information ... hmm
13:34:32 <peter1138[d]> It's your own widget, can't you just keep it in there?
13:34:46 <truebrain> my widget repeats other widgets N times
13:35:01 <truebrain> my widget is a NWidgetVertical, so things get stacked nicely below each other
13:35:18 <truebrain> but NWidgetVertical::SetupSmallestSize is a complicated function .. and I need to track its iteration over the children to do what I want ..
13:35:53 <peter1138[d]> Your children need unique indexes for that to work properly.
13:36:03 <truebrain> exactly; was hoping to avoid that 🙂
13:36:21 <truebrain> I guess I can make `SetupSmallestSize` work on dummy data ...
13:38:12 <truebrain> yeah, that will work fine .. just to calculate size, so that is not an issue
13:40:53 <peter1138[d]> Nice, the 'new' widget tree unit-test caught a run-time error with this changeset.
13:41:17 <peter1138[d]> Accessing a variable after it's been std::move'd
13:42:00 <peter1138[d]> Compile time asserts are better.
13:42:51 <andythenorth> when can we drag trains between depots?
13:43:17 <_jgr_> You just need to build some rails connecting them 🙂
13:43:21 <peter1138[d]> Teleportation eh?
13:45:14 <peter1138[d]> Oof, I hit 180bpm on one hill today. I guess I am still alive after all 🙂
13:45:48 <peter1138[d]> Heh, because this uses std::unique_ptr, it also solves the issue that JGR solved the other day 🙂
13:47:06 <xarick> this check is still wrong...
13:49:27 <xarick> no, the check nielsm pointed out
13:49:49 <xarick> it's just me being unable to understand logic
13:49:59 <xarick> && and || and == and !=
13:54:01 <truebrain> ignore the `English (UK)` part, but ... it is doing something 😄
13:54:41 <xarick> `if (!(vli.company == c->index || (vli.company == OWNER_NONE && (vli.vtype == VEH_AIRCRAFT || vli.vtype == VEH_SHIP)))) continue;`
13:54:41 <xarick> I think this is what I want. Now I need to make it "readable"
13:56:32 <xarick> gonna ask bing chat, I can't think right when it's about logic
13:56:45 <truebrain> peter1138[d]: does `FillNestedArray` need to have `NWidgetBase **array`? 😄
13:58:29 <truebrain> so the thing was actually initialized twice .. that is so weird ..
13:58:34 <truebrain> I assume you tested this for all types? 😛
13:58:51 <peter1138[d]> Not twice, there were just two ways to do it.
13:59:15 <peter1138[d]> I think I remember reading once that it was "faster" one way, but I didn't see anything in the code for that comment, so...
13:59:31 <peter1138[d]> And honestly, initializing windows is not performance critical 🙂
14:01:37 <truebrain> lol, I will be adding two (!) custom widgets! Owh my!
14:05:13 <locosage> where are all the runway sprites used? all airports seem to just use 2646
14:06:15 <locosage> also opengfx2 has rotated runway sprites for some reason...
14:08:25 <locosage> oh, city airport uses the whole range...
14:08:59 <truebrain> owh meh, when I use two widgets, I do have to use a global to communicate which iteration the first is .... ugh .....
14:09:37 <peter1138[d]> Is one a child of the other?
14:09:38 <talltyler> truebrain: New tab! Does the survey opt-in belong in the same category, perhaps?
14:09:42 <truebrain> or do I? Hmm .. no, I do not ... waiiittttt
14:09:51 <truebrain> talltyler: I do not think so
14:10:32 <peter1138[d]> It's not a social-presence thing.
14:10:48 <truebrain> meh; no, I do need a global for construction .. hmm ...
14:10:56 <truebrain> what I was trying to do, and maybe I just shouldn't
14:11:03 <truebrain> was group the plugins together per social platform
14:11:08 <truebrain> so the Steam, Discord, etc
14:11:15 <truebrain> and below that the N plugins that are available for that type
14:11:18 <truebrain> there should be only one
14:11:20 <truebrain> but .. well .. you know
14:11:29 <truebrain> but maybe I should just stick with a single list
14:12:02 <peter1138[d]> Why would there be multiple plugins for a type?
14:12:08 <truebrain> because people are stupid?
14:12:12 <truebrain> just as a general rule 😛
14:12:21 <truebrain> and they will put 2 steam plugins in that folder
14:12:29 <truebrain> the second is denied, as there is already one loaded
14:12:32 <truebrain> but you know ....... 😄
14:13:16 <_glx_> hmm just hide the denied, like GS/AI
14:13:43 <truebrain> I do not want to hide them; I want to show that they aren't being loaded
14:13:47 <truebrain> I just wanted to gruup them ..
14:13:55 <peter1138[d]> Okay, I need to think on a better name than "nested_array"
14:13:55 <truebrain> I am pushing this UI stuff 😛
14:14:16 <truebrain> that at least is how I translated it internally 😛
14:14:19 <peter1138[d]> It is indexed widgets.
14:14:29 <truebrain> it is the map from index to widget
14:14:33 <peter1138[d]> Oddly enough, this change uses std::map 🙂
14:15:18 <peter1138[d]> But, because iteration, I still refer to it as nested_array hehe.
14:15:33 <peter1138[d]> (iteration in development, not iterators)
14:15:38 <truebrain> widget_index_map? 😛
14:16:58 <peter1138[d]> Yeah, avoiding the type name in the variable name is always good 🙂
14:17:27 <truebrain> okay .. now to make a single row of information ... let's see ...
14:19:01 <peter1138[d]> Hmm, is it a widget index or a widget id...
14:19:22 <peter1138[d]> But we call it widget->index 🙂
14:19:47 <truebrain> id is short for index 😛 (or identifier 😄 )
14:19:48 <_glx_> yeah like VehicleID and friends
14:20:10 <peter1138[d]> id is "identifier" normally 😉
14:20:48 <_glx_> it's a unique identifier which happens to be the index in an array
14:22:13 <peter1138[d]> There's no array 😉
14:22:14 <truebrain> calling it ID might help people understand it is not just a random number 😛
14:23:39 <truebrain> lol @ CodeQL .. you are cute
14:23:56 <_glx_> all the `WID_` can be understood as WIDGET or WidgetID 🙂
14:25:13 <peter1138[d]> I didn't randomly add comments to an existing function!
14:25:24 <truebrain> so ignore and merge! 🙂
14:26:24 <truebrain> hmm ... all my labels are "..." ... guess they are too small 😛
14:28:09 <truebrain> ah, no, simply forgot to forward the right `SetStringParameters` .. "oops" 🙂
14:29:16 <merni> peter, any chance you could PR that patch which line-breaks the station name in the buy station window? :
14:31:50 <truebrain> hmm .. I expected that after 11640 I had to move my assign-line to `FillNestedArray` .. but that is never called on my widget
14:32:28 <truebrain> because .... I was too quick with `git fetch` after I saw the merge
14:32:32 <truebrain> ffs 😛 What a day ...
14:34:00 <peter1138[d]> merni: One stale forgotten changeset at a time 😉
14:35:57 <truebrain> at least I have the information correct now 😛
14:36:12 <truebrain> now to make it pretty !
14:36:29 <peter1138[d]> Oh that's suddenly different 🙂
14:37:26 <truebrain> hmmm ... `SetDParamStr` takes a pointer .. so I need to keep the memory alive .. hmm ...
14:38:38 <peter1138[d]> Is this for setting size, or drawing it?
14:38:43 <_glx_> hmm one steam says discord
14:39:15 <peter1138[d]> One thing I did that simplified dropdowns is to just store strings instead of dealing with storing parameters etc.
14:39:21 <truebrain> peter1138[d]: drawing; going to put it in a WWT_FRAME .. owh, wait, I can use the string system for that
14:39:46 <truebrain> _glx_: sharp eye ... let me find out why ...
14:39:49 <peter1138[d]> Hmm, but probably that works because no drop down list lives past language changes.
14:41:44 <truebrain> hmmm ... this is far from working how I expected it to work 😛
14:43:32 <xarick> `if ((vli.company != c->index && (vli.company != OWNER_NONE || (vli.vtype != VEH_AIRCRAFT && vli.vtype != VEH_SHIP)))) continue;` I just realized nielsm is too smart
14:44:28 <xarick> this can be simply put liek this: `if (vli.company != c->index && vli.company != OWNER_NONE) continue;`
14:45:40 <truebrain> hmmm .. Draw() is called in a different way than I expected ... meh
14:48:28 <xarick> if it is a neutral station, it is garanteed to never be of train and road veh, because those stations don't (yet) exist, thus making the vtype checks redundant
14:50:22 <xarick> but once they exist (eventually), the checks would be erroneous. At that time it would be okay to have all companies iterate over those veh types
14:50:58 <jfs> you could otherwise check what facilities the station has and only iterate over the vehicle types appropriate for those facilities
14:51:55 <jfs> although, of course, that would mean that if you have lorries going to a station and demolish the last loading bay for them then although they still have the station in their orders, they would not show in the list
14:52:35 <xarick> neutral station signs poof imediately, the station is gone instantly, doesn't linger
14:54:15 <xarick> I focused too much on vtype... 😦
14:54:19 <xarick> that was my wrongdoing
14:55:00 <truebrain> lol .. I just spend 10 minutes to find out I was overwriting strings when searching for the longest string
14:55:04 <truebrain> that ... is not helpful
14:55:46 <truebrain> I did a `string &longest`, as I wanted a reference
14:55:54 <truebrain> but ... I should have used a `string *longest` 😛
14:59:59 <peter1138[d]> Hmm, normally we just store the longest length, not the longest string.
15:00:29 <truebrain> I didn't want to store it either .. I just suck at programming 😄
15:00:51 <truebrain> I intended to find the string that was longest, but I just assigned it to the first entry in the list 😛
15:01:17 <peter1138[d]> Dimension dim; dim = maxdim(dim, GetStringBoundingBox(xxx));
15:01:47 <peter1138[d]> (But if you want multi-line strings that doesn't work)
15:02:05 <truebrain> that "xxx" I was fetching 😛
15:02:28 <peter1138[d]> Programming is hard.
15:02:47 <peter1138[d]> We should just use some kind of blueprint system that lets us link boxes together.
15:03:37 <jfs> xarick: your general weakness when programming seems to be that you focus strongly on single, specific cases, and possibly over-optimize for those. it can be a strength sometimes, but one of the common traits of experienced programmers is considering the larger picture of how the parts of the program interact and which parts can be written in general ways that handle the largest number of cases
15:03:37 <jfs> my best advice for you would be to try, when you think of a solution to something, to also spend some more time to think about how that solution can perhaps be modified to work for more cases, or ideally every case, instead of using narrow conditions for when to do things.
15:04:32 <jfs> (I hope you can take this as genuine advise, I am not trying to be mean and I apologize if it comes off like that)
15:04:46 <peter1138[d]> 215km to go to reach next target. 100% sure I will not reach that in 2 days.
15:05:29 <peter1138[d]> 16 files changed, 137 insertions(+), 199 deletions(-)
15:05:33 <peter1138[d]> Hmm, less is more.
15:10:50 <truebrain> okay ... string-system question ... I have a string `STR_JUST_STRING`, where the first param is normally something like "success", "failed", etc. There is on, which contains a parameter again .. so it is `{RAW_STRING} not running` .. how do I address that `RAW_STRING` .. is that `{1:RAW_STRING}`, and then `SetDParam` to 1?
15:11:26 <truebrain> no, that crashes the game 😛
15:12:51 <xarick> my mental gymnastics failed to see this could be much more simple. If only I had tried to start from the station owner... but I focused on vtype because that was the main thing these cached lists are about, groups are per vehicle type. I didn't even consider trying the other way around
15:13:45 <Rubidium> you probably need STR_JUST_STRING1, and when you want a raw string SetDParam(0, STR_JUST_RAW_STRING); SetDParamStr(1, myRawString)
15:15:03 <truebrain> Rubidium: Thank you! Would not have tried that iteration, but works as advertised 😄
15:18:27 <truebrain> now for some dropdowns .. but it is getting there 🙂
15:19:39 <peter1138[d]> Do you base off NWidgetVertical? Needs some SetPIP() space to separate the frames 🙂
15:19:50 <truebrain> yeah, was just looking for that ..
15:19:53 <truebrain> not sure why it isn't working 😄
15:20:34 <truebrain> no need to be a dick and proof that fact by being a dick to someone else their work?
15:20:48 <peter1138[d]> It needs to be in your function rather than the widget desc array.
15:21:04 <truebrain> peter1138[d]: hmm, yeah, that is why it isn't working 😄
15:21:53 <xarick> I thought OpenTTD was supposed to be clean of those features
15:22:35 <peter1138[d]> Unclean! Unclean!
15:22:54 <truebrain> next we remove Multiplayer ... way too social
15:23:59 *** Wormnest has joined #openttd
15:24:54 <truebrain> right ... tonight we try out if a dropdown also works in this method ... will be fun if it does 😄
15:25:33 <xarick> once steam, or discord, etc... become less relevant, these integrated features... remain 😦
15:26:41 <_jgr_> If not steam/discord it'd be something else, the idea of being "social" isn't going to go out of fashion any time soon
15:27:12 <peter1138[d]> tt-forums presence.
15:27:17 <andythenorth> forgot to use .copy()
15:30:22 <xarick> just hoping it doesn't become integral part of the game, or at least allow versions without it. I consider these kind of features as "bloat"
15:30:36 <peter1138[d]> Do you understand the concept of plugins?
15:30:49 <xarick> ah, ok, then that's ok
15:31:12 <merni> Maybe you ought to read the very detailed PR description before assuming things :p
15:32:31 *** truyul1943[m] has quit IRC (Quit: Client limit exceeded: 20000)
15:34:11 <andythenorth> so much fear in the world eh
15:34:15 <peter1138[d]> My enter key strikes agian.
15:34:53 <talltyler> Uncleanliness is how plagues spread 😉
15:38:22 <peter1138[d]> Slaps with a large trout integration.
15:39:01 <talltyler> How many plugins can one load? Does it need a scrollbar?
15:39:13 <talltyler> (If that many plugins even exist at any point)
15:39:20 <talltyler> (But future-proofing etc)
15:39:25 <peter1138[d]> I still have *that* patch somewhere...
15:39:35 <Eddi|zuHause> 640k plugins ought to be enough for anyone :p
15:39:45 <merni> Who needs future-proofing, just extend the window to be as long as necessary!
15:40:12 <peter1138[d]> It did used to be too big 😄
15:40:15 <talltyler> That’s what all windows do by default 😉
15:40:48 <talltyler> Yes, the current Options menu in 13.4 is too tall for my monitor on 2x scale. But now that’s fixed with tabs 😄
15:41:41 <peter1138[d]> I get confused when I go back to 13.4 🙂
15:42:32 <talltyler> I never see 13.4 because I don’t play OpenTTD 😛
15:43:07 <talltyler> (Partially true, I mostly play JGRPP with friends and haven’t touched single-player OpenTTD in months)
15:44:00 <talltyler> Blame kale91 for setting up such nice servers 😉
15:44:39 <kale91> You can blame me for this
15:49:29 <merni> Is this really a "feature" and not a codechange?
15:54:40 <xarick> feature seemed to be the appropriate word
15:54:49 <merni> Feature has to be visible to the user, iirc
15:55:06 <merni> this is not boring software!
15:56:28 <xarick> GroupStatistics gain a new member. It's not exactly a code change, something is being added to it
15:56:50 <merni> addition/deletion is also a change
15:57:40 <merni> > Codechange, Cleanup: Changes without intentional change of behaviour from user-point-of-view.
16:08:34 <truebrain> Unused static function
16:09:40 <_glx_> nice more deletion in the diff
16:10:09 <truebrain> CodeQL is so smart 🙂
16:11:58 <peter1138[d]> Why is it unused/unreachable...
16:25:37 <peter1138[d]> CodeQL is just lying 😮
16:26:33 <xarick> Codechange feels wrong, maybe Add?
16:27:31 <xarick> from user-point-of-view... well does time matter?
16:27:39 <xarick> taking less time to do the same stuff
16:32:56 <LordAro> if users cannot interact with it, it's a codechange
16:33:22 <LordAro> "Make OTTD 5 billion percent faster" would still be a Codechange
16:33:41 <LordAro> well, really significant stuff is probably a codechange
16:34:27 <xarick> I'm inclined to use Add
16:35:03 <merni> Might be worth seeing how Add has been used in other places
16:35:23 <merni> > "Feature" for user-point-of-view stuff, "Add" for other.
16:35:23 <merni> seems to be somewhat confusing
16:35:52 <_jgr_> A very modest cache is not not really or feature or something worth mentioning in a changelog
16:36:19 <peter1138[d]> It's his life's work and you're calling it modest! 😄
16:38:06 <xarick> I'm going to change to Add
16:38:31 <jfs> "Change" could also be relevant, since this might affect the ordering of vehicles/processing in some instances
16:39:13 <jfs> but it doesn't really "add" something, it does not create new APIs for Squirrel scripts
16:39:29 <peter1138[d]> Yeah, I'd go with Change.
16:39:48 <peter1138[d]> Codechange is more restructuring without much in the way of side-effects.
16:40:10 <peter1138[d]> (in my interpretation :))
16:43:38 <_glx_> I see it the same, codechange is implementation detail without effect on gameplay
16:56:45 *** kstar892[m] has quit IRC (Quit: Client limit exceeded: 20000)
17:06:11 <xarick> "Change" is a safe-bet
17:09:16 <peter1138[d]> Ctrl click company colour variations
17:09:46 <peter1138[d]> Shift click to estimate your variants
17:18:22 *** Flygon has quit IRC (Quit: A toaster's basically a soldering iron designed to toast bread)
17:23:17 <xarick> back to yesterday's problem... the const removal
17:23:49 <xarick> or switching to VehicleID which doesn't use const
17:25:54 <xarick> better rerun these TICC/TOCC tests again now that I know how to disable asserts
18:00:41 *** gelignite has joined #openttd
18:07:09 <truebrain> _jgr_: deployed to production!
18:07:32 <truebrain> let me know when you build a binary with the key in it, and when you are expecting surveys to arrive on the backend; I will check if they actually do 🙂
18:08:15 <truebrain> also the cherry-on-top for me, to show the instructions were clear enough 😛
18:12:40 <truebrain> the create-survey-key just 404d .. hmm
18:13:00 <truebrain> owh, your action shows why 😛
18:20:13 <_jgr_> The instructions seemed to imply that the private key needed to be base64 encoded again before it was pasted into the github actions secret, but it just needed the PEM file pasting as is
18:20:36 <truebrain> ah; yeah ... mind updating the docs to be more clear there?
18:21:31 <xarick> ` for (const VehicleID vehicle_id : stats.vehicle_list) {
18:21:31 <xarick> Train *t = Train::From(Vehicle::Get(vehicle_id));`
18:21:31 <xarick> using VehicleID didn't make it much better
18:28:46 <truebrain> _jgr_: no, the docs were just plain wrong 😄
18:33:10 <truebrain> peter1138[d]: mostly why I ask, is that you give the WidgetLookup as a reference to the function to update .. so why that? Why not updated `widget_lookup` directly?
18:33:18 <truebrain> (it was already like that, which I already didn't really understand 😄 )
18:33:51 <truebrain> basically, why `FillWidgetLookup(WidgetLookup &widget_lookup)` and not `FillWidgetLookup()`
18:34:19 <truebrain> or `FillWidgetLookup(Window &w)` , if it is on widgets 😛
18:35:29 <peter1138[d]> Yeah, FillWidgetLookup is on NWidgetBase, and widget_lookup is on Window.
18:36:35 <truebrain> I could understand it more if that variable was private, but okay; was already weird, so what-ever 😛
18:37:01 <peter1138[d]> I can change it to take Window *
18:37:19 <truebrain> was more wondering if there was a fundamental reason; but I guess there is not 😛
18:37:30 <truebrain> so the argument is "small scoped information" vs "just give the whole object"
18:37:36 <truebrain> I can't be arshed 😛
18:37:40 <peter1138[d]> No, it's just that's how it already was, so...
18:39:05 <DorpsGek> - Update: Translations from eints (by translators)
18:40:43 <_glx_> oh the doxygen stuff not being near the function feels so weird
18:41:21 <truebrain> okay, my dropdowns really do need an unique id it seems .. can't do the same tricks I did with drawing 😛
18:42:26 <truebrain> I want a `userdata` in the widget! 😄
18:42:54 <truebrain> bit weird, to add it for one window 🙂
18:43:30 <peter1138[d]> Lots of things could be nicer if they were widget members instead of done via Window events.
18:43:49 <truebrain> from what I can tell, it is not far from making that possible
18:44:07 <truebrain> mostly what I noticed that instead of `w->`, you want "first widget in tree that handles this"
18:44:24 <truebrain> basically, delegates 😄
18:45:59 <peter1138[d]> Merged before I get sidetracked and rewrite a ton of other stuff :p
18:46:39 <truebrain> lol @ OnClick of GameOptionsWindow ... if there was a click and it is not in one of these other widgets? It MUST be a dropdown then 😛
18:46:54 <peter1138[d]> Yes, that's very weird 🙂
18:47:00 <truebrain> especially as it is far from true 😛
18:47:01 <peter1138[d]> There's not even that many dropdowns in that window.
18:47:34 <peter1138[d]> I think originally it was just dropdowns and a button.
18:50:14 <truebrain> okay, on OnClick I really can't tell which of the plugin-dropdowns is being clicked
18:50:33 <truebrain> I guess I could use `pt` to find that .. but that is getting a bit meh
18:50:52 <truebrain> so I need to hide some information somewhere 😄
18:52:09 <peter1138[d]> You should be able to set up automatic widget ids quite easily now.
18:52:12 <truebrain> should we add an assert or something that if you register the same ID twice in the lookup, you notice?
18:52:37 <truebrain> peter1138[d]: hmm, smart idea. I can do that, I think
18:57:38 <_glx_> oh nice, we used to get the biggest index but never actually used it ?
18:58:34 <peter1138[d]> To allocate an array with CallocT.
18:59:33 <truebrain> ` SQGSWindow.DefSQConst(engine, ScriptWindow:://, "//");`
18:59:37 <truebrain> wth did it generate there ... lol
19:00:01 <truebrain> script doesn't ignore comments in that list 🙂
19:00:31 <truebrain> it does ignore `/* */` comments
19:02:39 <truebrain> okay, prepared the code for the widget-index to be dynamic for dropdowns, but now how do I rewrite the dropdown index .. hmm
19:04:11 <xarick> how do I terminate a rebase with conflicts and accept it as it stands without rolling back to the state before the rebase began?
19:04:55 <peter1138[d]> One way is to create a new branch at the current state.
19:05:17 <peter1138[d]> Then you can abort and you still have it as a branch. There's probably other ways.
19:06:17 <jfs> if you have the rebase in progress then you `git add` the files that are marked as conflicts (whether you have resolved them or not) and then `git rebase --continue`
19:06:53 <jfs> of course it might conflict further if you have more commits after the first one that made conflicts, and you'd have to do the same for every following instance
19:11:58 <truebrain> hmm ... okay, I can't figure out a clean way to reassign WIDs 😛
19:12:12 <truebrain> I tried to do it in the `FillWidgetLookup`, which kinda works, but it doesn't update its own reference
19:12:28 <truebrain> which is a bit problemetic .. but I do have the pointer
19:12:31 <truebrain> so maybe I should just cast it
19:14:53 <truebrain> ```reinterpret_cast<NWidgetLeaf *>(widget_lookup[WID_GO_SOCIAL_PLUGIN_DROPDOWN])->index = WID_GO_SOCIAL_PLUGIN_DROPDOWN + index;
19:14:53 <truebrain> widget_lookup[WID_GO_SOCIAL_PLUGIN_DROPDOWN + index] = widget_lookup[WID_GO_SOCIAL_PLUGIN_DROPDOWN];```
19:15:04 <truebrain> that weirdly enough just works 😛
19:15:49 <peter1138[d]> Mapping multiple IDs to the same widget instance?
19:16:17 <truebrain> the definition uses the same ID; this moves them to different IDs 🙂
19:16:32 <peter1138[d]> Hmm, the first line looks odd, but...
19:16:39 <truebrain> open for better suggestions 🙂
19:18:00 <peter1138[d]> You are looking it up by index... and then change its index.
19:19:02 <peter1138[d]> `this->GetWidget<NwidgetLeaf>(WID_GO_SOCIAL_PLUGIN_DROPDOWN)->index = ...`, but I guess you are not in the context of the Window here.
19:19:59 <truebrain> you didn't want to give me a `Window *` 😛
19:20:38 <peter1138[d]> I did I could change it 🙂
19:21:08 <truebrain> hmm .. I am now starting to doubt if dropdowns here is actually a good idea ..
19:21:17 <truebrain> I wanted to use it, so you could disable integrations ingame too
19:21:22 <truebrain> but .. not sure that actually makes sense
19:21:34 <truebrain> in the future, we might want to use it to limit what a plugin receive .. generic information or specific
19:21:41 <truebrain> but there too ... not sure it actually makes sense 😛
19:21:49 <truebrain> if you install the plugin .. you kinda want to use it
19:21:54 <truebrain> otherwise ... don't install it?
19:22:39 <truebrain> maybe start small and simple ... and just don't allow toggles .. hmm, I guess
19:30:12 <truebrain> sufficient? or does it need more?
19:30:40 <truebrain> changed the text to `no plugins to add with social platforms installed`
19:31:28 <peter1138[d]> Looks fine to me.
19:31:44 <peter1138[d]> But... "how do you install one"?
19:31:58 <truebrain> some day via BaNaNaS
19:32:02 <truebrain> that day is just not today
19:32:16 <jfs> mention it in the readme file and say it's fine for now
19:32:54 <truebrain> yeah, need to figure out where the plugins show up on the website too
19:34:22 <truebrain> jfs: I am thinking of naming it `social_integration` instead of social presence
19:34:30 <truebrain> do you have any feel for one way or the other?
19:34:45 <jfs> nah it's probably a better name tbh
19:43:44 <rau117> truebrain: Hmm... A separate button for something that may not be installed? Maybe re-arrange the buttons in a 2x2 grid, in case the translation turns out to be too long
19:46:19 <rau117> rau117: In addition to “no social plugins”, write where players can get them, or just make this button inactive
19:46:20 <peter1138[d]> 2x2 for a row of tabs seems a bad idea.
19:48:34 <rau117> although the tab-buttons themselves will not be such a big problem in French... The settings window itself can be disgustingly long (=
19:49:11 <truebrain> hiding those `()` in that case is annoyingly difficult 😛
19:51:17 <truebrain> lol @ those orange dots constantly 😛
19:57:31 <truebrain> tnx for the help today peter1138[d] ; I think it is a good first step 🙂
19:59:40 <andythenorth> Such modern features 🙂
20:05:00 <Eddi|zuHause> what's the overlap between modern features and BAD FEATURES?
20:05:14 <truebrain> _jgr_: so I saw a survey coming in that was significantly bigger than normal .. it is one from JGRPP 😛 Mostly bigger because of a lot of NewGRFs 😄 But it is marked as "verified", so signing etc works 🙂 One minor thing, the version is `jgrpp-0.56.1-He62c7f60`; I guess that is because this was not an official release?
20:06:16 <Eddi|zuHause> why H? wasn't that letter previously used to distinguish different versioning systems?
20:06:27 <_jgr_> I built the most recent commit, rather than the last release
20:06:46 <truebrain> well, the last commit has yet another hash 😛
20:07:09 <truebrain> there is no commit `e62c7f60` in your repo 😒
20:07:58 <truebrain> the Release build also says it should be `jgrpp-0.56.1` .. so now I am not even sure what that postfix is exactly 😄
20:08:48 <_jgr_> The H suffix is for when the version script doesn't have access to the git info for some reason, but the source doesn't match the release version info
20:09:19 <_jgr_> Probably because of the delete VCS part of the release workflow
20:09:35 <_jgr_> The actual releases won't have this
20:09:47 <truebrain> okay; just so you know, for surveys you create a key for `jgrpp-0.56.1`, but as you don't send that as version, it thinks someone is being a bit nasty 😛
20:09:54 <truebrain> good; all I wanted to know 🙂
20:10:19 <truebrain> `"linkgraph.distribution_per_cargo[61]": "128",`
20:10:51 <truebrain> results look sane; at least my initial parser understands it
20:11:26 <LordAro> truebrain: nice (re socials)
20:11:58 <truebrain> almost done, it seems ... need to add them to the crashlog, so we know they were there when crashing, and need to make a GOG plugin .. other than that, I think, this is about all we need
20:12:28 <truebrain> maybe a `reload all plugins` button .. might be useful, I guess
20:13:04 <LordAro> i guess there's nothing we can do about plugins infinite looping (or just being slow) or just plain crashing?
20:14:38 <LordAro> we'd need coroutine stuff, i guess
20:14:51 <truebrain> I did consider doing this in WASM for the sandboxing
20:15:05 <truebrain> but it didn't actually solve anything 😛 As we integrate with a SteamSDK, which might also crash / loop
20:15:53 *** Eddi|zuHause2 has joined #openttd
20:16:21 <LordAro> should probably test crashlog when crashing within plugin, as well as them just being mentioned
20:16:41 <truebrain> I wouldn't know why it wouldn't produce a crashlog, but will test 🙂
20:16:52 <truebrain> I do need to publish the symbols on our symbol server, so we can trace them 😛
20:19:12 <_glx_> intel and amd drivers can trigger crashlog 😉
20:19:46 *** Eddi|zuHause has quit IRC (Ping timeout: 480 seconds)
20:19:56 <_glx_> I don't see why it would different for plugins
20:20:36 <truebrain> doesnt hurt to test 🙂
20:22:49 *** Eddi|zuHause2 is now known as Eddi|zuHause
20:23:12 <Eddi|zuHause> weird, that's at least the second time in a few weeks that internet disappeared for a few minutes
20:26:20 <truebrain> long switch case, lolz
20:26:30 <truebrain> not wrong, but also ... how we do UIs 😛
20:48:09 <xarick> when you have 3 vehicles, what variable do you use for the 3rd?
20:49:11 *** nielsm has quit IRC (Ping timeout: 480 seconds)
20:49:11 <peter1138[d]> My environment always complains about these single letter variable names 🙂
20:49:14 <xarick> it's the disaster big ufo code that requires me for a 3rd
20:50:08 <jfs> Then use a descriptive name instead
20:50:30 <xarick> I would, but it's so temporary
20:51:03 <jfs> Like ufo_vehicle, shadow_vehicle, target_vehicle
20:52:09 <jfs> Variable names are for readability, just because they have a short life time doesn't mean they must have a short name
20:53:07 <xarick> v = the ufo vehicle, u = the RoadVehicle to destroy, derived from w, which is a Vehicle
20:54:47 <xarick> renaming u to target means I need to rename all other instances of u in that function for consistency
20:56:49 <jfs> That could be a neat standalone Codechange commit
20:58:12 <xarick> hmm, i do a new PR for it, or just a new commit in the same PR?
21:01:24 <peter1138[d]> New PR, because your PRs tend to go.. off-piste.
21:07:16 <andythenorth> It’s important to use single letter variable names, for performance reasons
21:08:38 <andythenorth> * in some js implementations in 2000
21:09:51 *** virtualrandomnumber has joined #openttd
21:10:05 *** virtualrandomnumber has quit IRC ()
21:21:48 <andythenorth> literally more bytes to move?
21:32:25 <LordAro> peter1138[d]: aren't rabbit holes great?
21:38:44 <xarick> ops, i removed a const where i shouldn't
21:40:26 <Eddi|zuHause> we need to bring back "DEFINT A-Z" :p
21:41:08 <Eddi|zuHause> don't tell me i mistyped a name, just make a new variable instead
21:42:04 <peter1138> ON ERROR RESUME NEXT
21:43:57 <andythenorth> try: foo except: pass
21:44:16 <andythenorth> hmm Horse `Sprites complete for 803 consists; incomplete for 10 consists; 98%`
21:44:31 <peter1138[d]> Solution: Add more consists.
21:55:37 <xarick> I have a problem with the const removal
21:56:54 <xarick> `stats.vehicle_list.push_back(const_cast<Vehicle *>(v));` is this okay? If it's not, I gotta remove the const from `/* static */ void GroupStatistics::CountVehicle(const Vehicle *v, int delta)` and everywhere this propragates
21:59:05 <xarick> and I'm kind of worried it would also means losing performance
22:04:02 <peter1138[d]> Check annotations, hmm.
22:04:29 <peter1138[d]> const vs non-const does not affect performance.
22:06:28 <peter1138[d]> Ah of course, different enums :/
22:09:24 <Eddi|zuHause> const is a compiler constraint, has nothing to do with performance
22:13:20 *** keikoz has quit IRC (Ping timeout: 480 seconds)
22:21:43 <jfs> Eddi|zuHause: It might allow the compiler to do more optimizations in some cases, though.
22:23:17 <truebrain> That gap was not there last I touched ... 😛
22:24:07 <peter1138[d]> Hmm, is that the textfile window....
22:30:27 *** Wormnest has quit IRC (Ping timeout: 480 seconds)
23:02:47 *** Wormnest has joined #openttd
23:16:00 <peter1138[d]> #11643 seems to be another victim of removing ReInitAllWindows() from LoadStringWIdthTable()
23:16:05 *** gelignite has quit IRC (Quit: Stay safe!)
23:18:54 <peter1138[d]> Yeah, the call CheckForMissingGlyphs() in TextfileWindow::LoadText() did way more than just check for missing glyphs 😉
23:29:14 <Eddi|zuHause> jfs: yes, but that's worrying about performance on the wrong level.
23:32:48 <truebrain> peter1138[d]: Haha, I remember it did. It amazed me how much things broke when I removed that function
23:47:09 <xarick> can I check if an item is in a std::vector with if (vehicle_list[item] != nullptr) or some equivalent to nullptr?
23:54:09 <peter1138[d]> So, bug hidden by side-effects of other functions... fun.
23:55:26 <_glx_> no if you try to access non existing index it's an error
23:57:03 *** Wormnest has quit IRC (Ping timeout: 480 seconds)
23:58:02 <_glx_> actually "Accessing a nonexistent element through this operator is undefined behavior"
23:59:45 *** Wolf01 has quit IRC (Quit: Once again the world is quick to bury me.)
continue to next day ⏵
