IRC logs for #openttd on OFTC at 2023-12-25
โด go to previous day
00:03:01 <talltyler> The dropdown has grown on me ๐
00:04:26 <emperorjake> It's certainly more consistent with all the other dropdowns
00:04:54 <talltyler> Unused strings, aww
00:05:49 <emperorjake> Does "real time" mean it's synced to your computer clock?
00:07:22 <talltyler> Nope. Itโs game ticks. Very neatly, one day in OpenTTD is two seconds long ๐
00:11:03 <truebrain> Emscripten via mobile is very small ๐
00:13:16 <peter1138> Real-time does somewhat imply... real... time...
00:13:29 <peter1138> So maybe there's some better terminology.
00:13:41 <talltyler> Real-time units ๐
00:13:49 <talltyler> Suggestions welcome ๐
00:34:53 <peter1138[d]> I'm probably dumb, but that tooltip doesn't really helpfully explain things.
00:42:50 * peter1138 ponders byte alignment.
00:48:09 <talltyler> Itโs a hard concept to explain. I welcome suggestions. ๐
00:51:02 <talltyler> Maybe jfs has thought about it ๐
00:51:51 *** Wolf01 has quit IRC (Quit: Once again the world is quick to bury me.)
01:07:17 <truebrain> So real time is syncd with your computer clock, just with an offset, not?
01:07:45 <truebrain> A minute in the real world is a minute of those real time thingies
01:09:47 <truebrain> In Linux land that is btw often called wallclock
01:10:00 <truebrain> As in, the clock on your wall tells the same amount of progression of time
01:11:13 <truebrain> (Mind you, wallclock is time since start of your machine, so rather similar to this, only since start of game instead of machine)
01:11:51 <truebrain> `Calendar-based` vs `Wallclock-based`?
01:14:48 *** gelignite has quit IRC (Quit: Stay safe!)
01:17:07 <truebrain> "With wallclock time units, a traditional year is represented as a cycle of 12 minutes."
01:17:48 <truebrain> "Every 12 minutes a new year is entered"
01:18:33 <truebrain> "With wallclock time units, a new year starts every 12 minutes", to phrase it a bit better
01:20:08 <truebrain> Or some combination of all that ๐
01:23:51 *** rau117 has quit IRC (Quit: User went offline on Discord a while ago)
01:42:32 <talltyler> It only matches your computer clock if OpenTTD is not running slowly. Wentbourne for example would quickly fall behind the computerโs clock.
01:43:08 <talltyler> Wall clock is also a JGRPP feature, and I donโt want there to be any confusion because there is no similarity between the two features.
01:43:26 <peter1138> I don't think it's very important to mention the game running slower than intended.
01:44:55 <talltyler> I stole some of the text from nielsmhโฆforget exactly where he wrote it ๐
01:46:12 <talltyler> Anyway, my 885 km train ride is nearing its end so I will pick this up later this week ๐
03:39:41 *** Wormnest has quit IRC (Quit: Leaving)
03:46:51 *** debdog has quit IRC (Ping timeout: 480 seconds)
04:22:43 <johnfranklin> How to make findversion.sh work?
06:02:08 <merni> re 11341, might be bikeshedding but why are the dropdowns on the right bigger than the ones on the left?
07:30:53 *** tokai|noir has joined #openttd
07:30:54 *** ChanServ sets mode: +v tokai|noir
07:37:40 *** tokai has quit IRC (Ping timeout: 480 seconds)
07:55:43 <reldred> That temperate grass does work surprisingly well in tropics, and has the advantage that you already have desert transition sprites, only issue is tropic to rainforest transition
08:27:32 <peter1138[d]> Because theres a different number of rows. There needs to be a spacer.
08:30:42 <LordAro> johnfranklin: it's a shell script that's only used as part of the linux build system
08:30:48 <LordAro> also, it was removed about 4 years ago
08:36:16 <peter1138[d]> Merry Christmas. ๐
08:36:35 <peter1138[d]> It's dry until midday. Bike ride?
09:11:56 <peter1138[d]> This will completely mess with zephyrus cc delta stuff
09:25:56 <_zephyris> That's not Christmassy colours!
09:26:21 <peter1138[d]> I just downloaded a train set to test with... and then by the time I got to the newgrf settings forgot what it was ๐ฆ
09:28:55 <peter1138[d]> I think you need more than 2cc for christmas colours ๐
09:33:54 <emperorjake> That would be my Christmas wish come true
09:34:12 <peter1138[d]> More than 2cc? ๐ฎ
09:40:36 <emperorjake> The rgb patch I mean ๐
09:40:42 <Rubidium> seems like you can get almost any number of christmas colours, so only two christmas colours seems fine to me
09:52:12 <peter1138[d]> 1280 bytes of recolour sprite.
09:54:02 <locosage> how do you make 8 colors out of 1?
09:54:18 <locosage> it's probably good to match lightness ratios of default CCs
09:55:27 <peter1138[d]> The default CCs don't have the same 'lightness ratios'.
09:55:38 <peter1138[d]> I went with "contast"
09:55:51 <locosage> well, take some average I guess
09:56:55 <johnfranklin> LordAro: I did some manual findversion...
09:57:01 <peter1138[d]> Why would I fix it?
10:00:13 <truebrain> talltyler: The usage is different, but the concept/result is pretty similar, isn't it? So is there really much hurt in using the word in a different context but with similar vibe? We can't always avoid a conflict like that anyway.
10:02:52 <locosage> peter1138[d]: acutally, how does it even work if user choses one of the default colours, does it use old cc palette or just generates a new set of somewhat similar colours?
10:03:27 <peter1138[d]> I uses the normal cc palette.
10:03:57 <truebrain> truebrain: From what I can tell, JGRPP uses wallclock to show the system time, and you would use wallclock to show the delta of it. Seems very similar to me ๐
10:05:09 <truebrain> btw, wall-clock normally refers to the delta, so one could argue JGRPP is ugin the wrong definition here ๐ But that is very much not all that relevant ๐
10:08:27 <locosage> peter1138[d]: I'm trying to solve the opposite problem right now - turn a certain hue into cc colors
10:08:49 <locosage> and with rgb patch I'd expect to get back the same colour if I pick that hue for company color
10:08:57 <locosage> but if I optimize it for current cc I won't
10:09:25 <locosage> because of different logic of picking shades
10:10:28 <peter1138[d]> You should use 0xC6 to 0xCD for your CC parts.
10:10:41 <locosage> also, all sprites are designed to work with current CC colors, so if you pick shades differently they won't look as good
10:10:43 <peter1138[d]> Anything else looks flat.
10:11:45 <locosage> first column is cc colors and brightness levels
10:11:47 <peter1138[d]> Happy days. zBase does not.
10:12:40 <locosage> using only one makes gradients smooth
10:12:55 <peter1138[d]> Smooth but bland & flat.
10:13:31 <andythenorth> peter1138[d]: Such Neon Horse
10:13:52 <andythenorth> Synthwave mod for OpenTTD
10:15:33 <locosage> peter1138[d]: depends on how you do it. after all, your rgb cc patch does exactly the same - turns one color into many
10:16:41 <locosage> though I guess it does have more way of changing colors than just AdjustBrightness
10:18:38 <peter1138[d]> If I had more bits I could control hue shift, maybe I will reduce the bits allocated to RGB.
10:20:04 <locosage> yeah, 16 bit rgb is more than enough
10:20:21 <peter1138[d]> It's 18 bit a the moment anyway.
10:21:01 <locosage> iirc there even was 16bpp blitter on android xD
10:23:06 <locosage> 18 bit is kinda awkward, at least 16 is somewhat of a standard
10:23:47 <peter1138[d]> This is completely unrelated to how it's displayed, it's the internal format for how it's passed around and stored.
10:25:05 <locosage> well, it's always about how it's stored.
10:25:12 <locosage> it's not like there are any 18-bit types :p
10:25:27 <peter1138[d]> Wow you are a fucking genius.
10:36:16 <LordAro> johnfranklin: well i certainly thought we got rid of it
10:36:37 <truebrain> we did; it is now fully in CMake
10:41:58 <jfs> talltyler: dunno, something like this?
10:41:58 <jfs> > Select the timekeeping-units of the game. This cannot be changed later. Calendar-based is the classic OpenTTD experience. In Wallclock-based time, one classic month instead becomes one minute of real time, but there is still also a classic calendar. The classic calendar is always used for vehicle introduction dates and such, but in Wallclock-based timekeeping you can change how fast the calendar
10:41:58 <jfs> progresses relative to the real-time units.
10:42:35 <jfs> I think it's important to point out that it's the prerequisite for being able to change the game speed/"daylength"
10:42:43 <alfagamma7> Openttd should add the day length factor setting in vanilla as well
10:42:55 <alfagamma7> by default it can remain disabled
10:43:37 <peter1138[d]> I would remove "vehicle"
10:43:52 <peter1138[d]> houses, industries, stations etc have introduction dates too.
10:44:02 <merni> jfs: I think "classic openttd experience" needs to be clarified a bit -- new players who haven't been playing for years wouldn't know what that is
10:44:08 <truebrain> jfs: I like the "timekeeping" wording ๐
10:45:19 <merni> and "one classic month instead becomes on minute of real time" kind of clashes with "you can change how fast the calendar progresses relative to the real time units" if you don't understand the feature already
10:45:32 <merni> the first implies that 1 calendar month = 1 minute
10:45:56 <peter1138[d]> Hmm, my contrast detection is a bit too much now.
10:46:14 <truebrain> `one minute of real time, but` <- to nitpick, the `but` introduces a contradiction, but that isn't there. I suggest closing the sentence, and removing `but`. So `one minute of real time. There is still also ..`
10:47:43 <merni> I think a simpler way would be instead of stating " one classic month instead becomes one minute of real time" would be to overview what things use "real time" units
10:48:13 <merni> such as industry and town production, cargo payment, running costs, etc
10:48:27 <truebrain> the list is long, and doesn't fit in a tooltip ๐
10:49:26 <jfs> > > Select the timekeeping-units of the game. This cannot be changed later. Calendar-based is the classic OpenTTD experience, with a year consisting of 12 months, and each month having 28-31 days. In Wallclock-based time, vehicle movement, cargo production, and financials are instead based on one-minute increments, which is about as long as a 30 day month takes in Calendar-based mode. In either
10:49:26 <jfs> mode there is always a classic calendar, which is used for introduction dates and such, but in Wallclock-based timekeeping you can change how fast the calendar progresses relative to the real-time units.
10:49:29 <merni> It doesn't need to be exhaustive
10:49:57 <truebrain> jfs: nice, even better ๐
10:50:04 *** gelignite has joined #openttd
10:50:07 <merni> Is there a possibility of line-breaks in tooltips?
10:50:31 <truebrain> `{}` should do that
10:50:36 <merni> > Select the timekeeping-units of the game. This cannot be changed later.
10:50:36 <merni> > Calendar-based is the classic OpenTTD experience, with a year consisting of 12 months, and each month having 28-31 days.
10:50:36 <merni> > In Wallclock-based time, vehicle movement, cargo production, and financials are instead based on one-minute increments, which is about as long as a 30 day month takes in Calendar-based mode.
10:50:36 <jfs> alfagamma7: and btw this is exactly what is being worked on here
10:50:38 <merni> > In either mode there is always a classic calendar, which is used for introduction dates and such, but in Wallclock-based timekeeping you can change how fast the calendar progresses relative to the real-time units.
10:50:39 <merni> would perhaps be better
10:50:56 <alfagamma7> Maybe add that option to settings rather than where that is now currently
10:50:58 <merni> Well not "exactly" as NotDayLength is somewhat different from jgrpp's daylength
10:51:19 <alfagamma7> Most new players won't understand how daylength works
10:51:19 <truebrain> merni: cc talltyler , so he can find it back easier ๐
10:52:18 <jfs> I wonder if we should add an explicit reference to a documentation/manual for this?
10:52:36 <truebrain> you can click on a tooltip
10:52:37 <alfagamma7> It would be better
10:52:40 <truebrain> so that is a bit of a shame
10:52:48 <alfagamma7> but who reads the manual anyway
10:52:49 <truebrain> but we could add a section about it in the new help window ofc, and reference there
10:52:56 <merni> "For more details, see the OpenTTD wiki"?
10:53:11 <merni> Or wherever the docs are
10:53:21 <truebrain> or, we could make the dropdown a tiny bit smaller, and add a newly created "(i)" button behind it, that gets you there
10:53:36 <alfagamma7> Also maybe update the manpage for openttd as well
10:53:41 <truebrain> but given how complex OpenTTD is anyway, I am sure people figure it out ๐
10:53:46 <alfagamma7> again, jjust suggesting
10:53:58 <merni> alfagamma7: Who uses a man page for a graphical game ๐
10:54:18 <alfagamma7> I just did once or twice
10:54:24 <jfs> dunno maybe someone running a multiplayer server on a headless linux machine?
10:55:05 <peter1138[d]> Hmm, 32bpp-to-8bpp support for rgb-cc? ๐ฎ
10:55:23 <truebrain> merni: yeah, no, it is not going in that "man" file ๐
10:55:32 <truebrain> we have other means for that ๐
10:55:57 <merni> Not for daylength but in general if someone wants to update the openttd manpage
10:59:00 <truebrain> right, put this all on GitHub too, to keep things together ๐
11:02:39 <truebrain> jfs: to pick your brain from an old-ish PR: in your social presence PR, you loads the first DLL that returns a positive result, and skip all others. What was the thought behind that?
11:06:23 <xarick> ll give me an option to disable smoke
11:06:42 <peter1138[d]> Smoke "vehicles" don't appear in your vehicle lists.
11:06:59 <xarick> but the list needs to be created
11:07:09 <xarick> and it iterates over them
11:08:31 <xarick> I meant to say, they're tested to check if they belong to a certain type of vehicle
11:08:43 <xarick> the more vehicles needed to check, the slower it becomes
11:10:36 <merni> xarick: so...disable realistic smoke?
11:11:25 <xarick> disabled realistic smoke is original smoke, not really disabled but better
11:11:37 <peter1138[d]> They are filtered out before they ever get to squirrel, so you are not iterating them in squirrel-land.
11:12:14 <xarick> hmm last time I checked that, they had to be checked for vehicle type
11:12:17 <merni> xarick: lmao better because it has a marginally lower impact on your scripts designed to abuse game features
11:12:30 <_jgr_> truebrain: It's not related to the system time in my branch. I don't think that there's a need to explicitly distinguish them in the wording as they look quite different anyway
11:13:02 <truebrain> It is used for timetables not? To show when trains arrived and left?
11:13:26 <truebrain> you show that as a delta, or what is the representation? (sorry, too lazy to look for it myself .. I do appoligize ๐ )
11:14:04 <merni> timetables show times in a 24-hour clock format and waiting/running times in minutes (if the relevant options are enabled)
11:14:11 <peter1138[d]> Hmm, ScriptVehicleList could probably benefit from the vehicle type filter.
11:14:21 <peter1138[d]> But effect vehicles never appear in the list.
11:14:38 <peter1138[d]> Bonus fun, smoke from power stations is an effect vehicle.
11:14:50 <peter1138[d]> (Which is why you had that viewport wonkyness)
11:14:51 <truebrain> merni: owh, so it is an actual wallclock? Sorry _jgr_ , I was mislead by some information in that case
11:15:15 <peter1138[d]> That UI needs Excel :p
11:15:53 <merni> hm, 20 minute delay for a night train, not bad
11:16:21 <truebrain> but in that case, our definitions of wallclock are identical, not?
11:16:24 <xarick> why mix minutes and ticks, It's so weird for me
11:16:27 <truebrain> a timedelta based on the clock on your wall?
11:16:49 <merni> xarick: Idk I just hit automate + autoseparate and forget about it
11:17:10 <_jgr_> By default, remainder ticks aren't shown
11:18:13 <_jgr_> The minutes used for timetabling are a configurable number of ticks, not real life minutes
11:18:32 <truebrain> aahhhh .. that I did not read from the code
11:19:04 <_jgr_> The model railway people want to do clock face / 24 hour timetables, but without taking a real life day for them
11:19:24 <xarick> when I see a "minute" and a "tick" in the same sentence, my mind can't compute
11:19:26 <truebrain> haha, okay, I can imagine that being the case ๐
11:19:50 <truebrain> but okay, even then, the concepts are the same; for daylength it would just be a fixed ratio
11:19:59 <truebrain> where for timetable it is a changable ratio, I guess?
11:20:45 <truebrain> maybe I am approaching this wrong: _jgr_ do you see any issue if we use Wallclock in the wording for the daylength work talltyler is working on?
11:21:34 <xarick> maybe the tick needs to be renamed? millisecond?
11:22:18 <_jgr_> truebrain: I don't see any problem, users should be able to get it
11:22:36 <truebrain> I should just have asked that to start with; sorry for me filling in blanks for something I know too little about ๐ Tnx ๐
11:22:43 <merni> xarick: as jgr said by default those are not even shown so it doesn't matter. Those who are nitpicky enough to show it should be able to deal with the onfusion, rather than using a name like "second" which doesn't correspond to 1/60 of a minute
11:23:03 <truebrain> peter1138[d]: w00p!
11:23:09 <truebrain> fixing 15 year old "TODOs" like a boss
11:23:31 <truebrain> owh, I was meaning to look up who created the TODO, because it wouldn't surprise me if I did ๐
11:24:17 <peter1138> Actually it's 17 years old. Oops.
11:24:28 <peter1138> Rubidium fixed the spelling 15 years ago.
11:24:52 <truebrain> the days you could make commits with TODOs in them ๐
11:25:02 <peter1138> Did we really have 32bpp in 2006!?
11:25:16 <truebrain> even before we had IPv6 support, yes
11:25:42 <peter1138> I guess it pre-dates 32bpp NewGRFs.
11:25:58 <peter1138> We used to load from individual PNGs, and it was terrible :D
11:26:30 <truebrain> I love that commit message ๐
11:27:21 <truebrain> peter1138: owh yes, that we had for a while ..
11:27:27 <truebrain> I think it was a bit of a chicken-egg issue
11:28:41 <peter1138> Weirdly, I think it was me that removed PNG support, but I don't think grf container v2 was anything to do with me, and that allowed 32bpp NewGRFs... so... confused.
11:29:04 <peter1138> But it was long ago, so more likely it was someone else and I'm misremembering :)
11:29:12 <truebrain> wasn't v2 mostly about us thinking people would ship 8bpp and 32bpp variants of their GRF? ๐
11:30:03 <peter1138> Sort of, but it also allowed larger data chunks for 32bpp extra zoom.
11:30:21 <peter1138> Old format limited sprites to 255 pixels high.
11:31:54 <truebrain> I am now wondering what was first .. 32bpp or the blitters
11:32:09 <truebrain> it used to be an absolute mess, where we did blittering ..
11:32:58 <peter1138> > Also, why is it only supporting transparent remaps and not regular remaps? Or is that part of some other PR?
11:33:28 <truebrain> lol, adding a PNG loader for sprites was a footnote in a commit .. lol
11:34:59 <truebrain> `OpenTTD has 32bpp support. This means: OpenTTD still is 8bpp, but it has the
11:34:59 <truebrain> posibility to override the graphics with 32bpp. This means that it isn't a
11:34:59 <truebrain> replacement of grf or newgrf, but simply an addition. If you want to use 32bpp
11:34:59 <truebrain> graphics of a newgrf, you do need the newgrf itself too (with 8bpp graphics).`
11:35:04 <truebrain> I was so cute back in 2007 ๐
11:35:53 <jfs> truebrain: I don't remember tbh, I think the idea was to load and call everything that's detected but to keep things simple I might have initially have made it only run a single one?
11:36:18 <truebrain> jfs: okay, good, I was hoping that. Not that I was missing something else here ๐ Tnx!
11:36:29 <truebrain> `An other thing that OpenTTD needs in your png, is 2 tEXt chunks: x_offs and
11:36:29 <truebrain> y_offs. This to define the x- and y-offset, of course.`
11:36:32 <truebrain> that is just cute too ๐
11:36:44 <truebrain> I really really really did not want to touch GRFs ๐
11:36:50 <truebrain> even back then, I did not understand any of it ๐
11:37:28 <truebrain> not me, I can tell you that ๐
11:38:32 <truebrain> okay, that was a fun trip down memory lane .. time for food ๐
11:39:19 <xarick> peter1138[d]: I Searched the "script\api" files for `for (const Vehicle *v : Vehicle::Iterate()) {` and I get 7 matches. This loop is called very often in the context of an AI, and `Vehicle` contains a list of every vehicle, effect, smoke, and even vehicles from other companies. There should be a way to improve this loop so that it doesn't have to get through those sure to be filtered vehicles,
11:39:19 <xarick> maybe split it into different sub-types of lists, I was thinking one per vehicle type or company?
11:40:18 <peter1138[d]> Yes but it's not executed by Squirrel, so doesn't kill performance like filtering in Squirrel would do.
11:40:21 <xarick> basically, reduce the amount of iterations needed
11:40:25 <xarick> to improve performance
11:40:37 <truebrain> first benchmark it is a performance issue
11:40:47 <truebrain> you are creating a solution, then finding a problem
11:40:48 <peter1138[d]> The game loops through every vehicle every tick itself anyway.
11:40:52 <_glx_> Iterate() has a filtering version
11:41:14 <truebrain> first see if it is actually a problem
11:41:42 <_glx_> But getting the full list is not visible in performance most likely
11:41:45 <xarick> it is, why would I be complaining if it wasn't
11:41:51 <truebrain> because you do that?
11:42:06 <_glx_> Filtering it in squirrel on the other hand
11:42:09 <merni> is it an issue like airport noise overflowing is an issue :p
11:42:20 <xarick> I have tested the speed of scripts and by just disabled breakdowns, I get an increase in performance
11:42:29 <xarick> so I know it's the vehicle lists
11:43:05 <truebrain> I guess we need a new statement for this .. "flamegraph or go home"? ๐
11:44:44 <truebrain> I wonder when there will be a twitter rant that "flamegraph" is not a political correct word to use
11:46:05 <peter1138[d]> Let's find out how many comments I broke ๐
11:46:57 <peter1138[d]> It's a draft ๐
11:47:31 <truebrain> I still can't get over the smallness of the actual change
11:48:00 <truebrain> and there is goo under my mouse which makes my mouse move less good, and I can't seem to fix it ๐ฆ
11:48:04 <peter1138[d]> AdjustBrightness being there is wrong, too.
11:48:32 <peter1138[d]> There's another copy in the 32bpp blitters so it can probably be combined and stuffed into palette.cpp/.h
11:48:59 <peter1138[d]> There's crumbs on my mousemat which is doing the same :/
11:52:55 <xarick> I almost forgot I had this
12:02:10 <locosage> peter1138: what's so hilarious about it?
12:02:22 <locosage> isn't that what 11602 does now that I found it?
12:03:02 <merni> what does 11602 have to do with remaps
12:03:22 <merni> > This PR implements simple nearest-neighbour conversion of sprites from 32bpp to indexed 8bpp, along with a little bit of hackery to detect dummy sprites used to satisfy nml's requirement for 8bpp normal zoom sprites.
12:03:38 <locosage> if I'm reading it right it allows to remap 32bpp sprites
12:03:51 <locosage> I mean reading code, ofc there is not a word in the description :p
12:04:25 <peter1138[d]> Absolutely no words.
12:04:35 <peter1138[d]> Completely stripped the template and everything.
12:04:53 <peter1138[d]> #11602 converts 32bpp graphics to work with 8bpp mode blitters.
12:05:22 <locosage> it adds m layer and remaps work of that
12:05:41 <locosage> well, populates, whatever
12:05:43 <peter1138[d]> m layer is palette index.
12:06:34 <peter1138[d]> It converts 32bpp graphics to 8bpp palette index. It does not really do anything with remaps, but does do a bit of special handling for the company CC palette index range.
12:07:56 <peter1138[d]> locosage: #11616 does not do anything with normal recolour maps because they were already implemented 17 years ago. only transparency recolour remaps were ignored.
12:07:57 <locosage> that's exactly how I did remaps in cmclient, just populated m layer
12:09:30 <andythenorth> Nobody uses the Squirrel APIs anyway, right? So perf. doesnโt matter? ๐
12:09:53 <peter1138[d]> So I convert a 32bpp rgba value to a palette index, that does not mean I am touching remaps.
12:10:22 <locosage> it may not have been intentional but for me it looks like you changed how remaps work
12:10:54 <peter1138[d]> In 11602 or 11616?
12:11:01 <peter1138[d]> 11602 does not change how remaps work.
12:12:12 <peter1138[d]> And 11616 also does not change how normal remaps work, it adds a new mode specifically for one case of remaps.
12:13:38 <peter1138[d]> Hmm, I should get these palette index constants in sooner or later ๐
12:14:44 <peter1138[d]> truebrain is quicker than code-ql, let's just truebrain as a CI task ๐
12:15:25 <locosage> hm, making a newgrf to test recolors is gonna be a bit of a pain...
12:18:31 <xarick> I see there has been some changes to groups from 9 months ago.
12:18:37 <xarick> Need to check what they do
12:22:22 <Eddi|zuHause> truebrAIn. the clues were there all along.
12:28:43 <peter1138[d]> This also does not change how colour remaps work.
12:31:07 <andythenorth> Do we get to repaint individual vehicles yet?
12:31:33 <andythenorth> Hmm player programmable per vehicle colour rules?
12:39:41 <locosage> with how often I make newgrfs recently I need to make an alias to put them into ~/.openttd xD
12:41:04 <peter1138[d]> ~/.local/share/openttd/newgrf
12:43:48 <locosage> I have it in .openttd
12:48:21 <reldred> andythenorth: Also, in unrelated news, chips3 good,
12:48:42 <LordAro> are enums normally plural?
12:48:47 <peter1138[d]> Ah, every compiler except my own complains ๐
12:49:18 <andythenorth> reldred: Is that the nml port?
12:49:38 <peter1138> LordAro, no but I have another change that addresses that as part of my rgb-cc changes (Colour exists for rgba values)
12:50:32 <reldred> andythenorth: I dunno, whichever one you posted on โere a few weeks back
12:50:59 <peter1138> This one is from that change set, but with this rewrite I'm splitting it up into smaller logical parts that stand by themselves.
12:55:17 <truebrain> LordAro: ahum ... `static_cast<>` ๐ We are not C!
12:55:55 <truebrain> `these 4 random colours are the base colour` ... those colours aren't random at all! ๐
12:56:31 <truebrain> (not your comment, but I just thought it was funny)
13:12:53 <andythenorth> reldred: Foundations are broken in my local version, not sure if I posted that one or not ๐
13:22:56 <reldred> andythenorth: At least some of the foundations worked on my side
13:34:38 <locosage> ok, I didn't notice the checks in #11602 that make it only affect 8bpp blitters
13:35:01 <locosage> but I was right that it affects remaps so the result in 8bpp is different from 32bpp
13:35:14 <locosage> even if that is still better than no image at all
13:36:38 <locosage> without remap works as expected I guess
13:42:10 <locosage> locosage: also it's debatable which result is actually the right one
13:43:28 <locosage> as 32bpp simply ignore remaps if there is no mask
13:45:26 <locosage> both options are kinda useful for different cases
13:45:28 <truebrain> that moment you realise you have to actually start working on Windows itself to test things, because your Steam and Discord don't run in your WSL ... I wonder if I can work around that ....
13:49:41 *** Flygon has quit IRC (Quit: A toaster's basically a soldering iron designed to toast bread)
13:54:13 <xarick> wow, you created a VehicleList
13:59:50 <locosage> posted the same thing with testing newgrf
14:01:42 <xarick> oh, it does not do what I thought
14:06:31 <xarick> `typedef std::vector<const Vehicle *> VehicleList;` versus `typedef std::set<VehicleID> VehicleIDList;`Not exactly the same thing, but I wonder if I can reuse it from 10890 on 10548
14:07:45 <truebrain> `error: C++ designated initializers only available with โ-std=c++20โ or โ-std=gnu++20โ` ... tempting ....
14:08:23 <xarick> std::vector vs std::set?
14:19:12 *** virtualrandomnumber has joined #openttd
14:19:30 *** virtualrandomnumber has quit IRC ()
14:19:52 <Rubidium> xarick: that choice depends on your needs and wishes
14:20:58 <xarick> tried reading an article, and I'm not sure of the use cases
14:25:41 <xarick> something something, and then I read... "iterating over a vector is faster."
14:27:14 <locosage> if all you do with it is iterating then sure ;)
14:27:21 <Rubidium> I'd say std::vector is the default, and if you need specific different behaviour or you're running into performance issues you might consider something else
14:29:54 <Rubidium> though... if iterating means looking for the existence of some element, then a std::set or std::unordered_set is likely a better choice
14:31:22 <Rubidium> and if you really do not know... just start with a std::vector and mention it in the PR that you're unsure so there's something more substantial for others to base their decision on
14:32:55 <xarick> oh snap, I started with std::set
14:33:03 <xarick> ok, gonna try change to std::vector
14:33:07 <Rubidium> not to mention that with caches there is a balance that needs to be found between doing something "cheap" (updating the cache) many times a second and doing something "expensive" once every few seconds
14:35:31 <Rubidium> so fine you reduce the time for some AI that takes 100ms by 99%, but if every new/removed vehicle costs 1ms by that, then with a big map that improvement for the AI call will quickly be overtaken by the cost for new/removed vehicles (e.g. effect vehicles)
14:36:34 <xarick> those vehicles aren't added to groups, doesn't seem to apply
14:38:22 <xarick> there is insert and remove access to this list, how often they happen is... in a AI environment, constantly
14:38:56 <xarick> like... how many times AI can execute commands per tick
14:39:55 <xarick> 74 per AI for 15 AIs for the worst case I guess
14:40:44 <xarick> they're usually not constantly adding or removing vehicles, but when they do, it's usually en masses
14:42:31 <xarick> wait, 1 DoCommand per tick, so... 15 max?
14:43:52 <xarick> unless AsyncMode shennanigans, but only the GS has access to that mode for now
14:47:16 <xarick> what's the erase equivalent for std::vector?
14:49:32 <xarick> oh snap, I need to iterate the entire vector to find the element I want to remove?
14:57:37 <xarick> find': is not a member of 'std::vector
15:10:07 <xarick> `Group::Get(v->group_id)->statistics.vehicle_list.find(v->index)`
15:10:07 <xarick> std::vector equivalent:
15:10:07 <xarick> `std::find(Group::Get(v->group_id)->statistics.vehicle_list.begin(), Group::Get(v->group_id)->statistics.vehicle_list.end(), v)`
15:10:19 <peter1138[d]> locosage: It being for 8bpp is entirely the point of it.
15:10:49 <peter1138[d]> And course the remaps in 8bpp mode are different from in 32bpp mode.
15:11:36 <peter1138[d]> It's limited by the palette, of course.
15:12:34 <locosage> but it remaps things that 32bpp blitter doesn't
15:12:57 <locosage> so it's not just being limited by palette
15:13:01 <locosage> it does extra things
15:14:41 <peter1138[d]> The only special handling is assuming that CC palette indexes will be remapped as company colours.
15:15:38 <peter1138[d]> Otherwise everything uses a normal 8bpp palette index, but there are some special remaps that it's not really possible to take care of.
15:18:31 <peter1138[d]> At the sprite loading stage you have no idea what remaps are going to be used -- and if you wanted to cope with them all you'd need to have multiple encodings of the same sprite.
15:19:28 <peter1138[d]> Single company colour remap is common enough, and important enough, to have special handling.
15:20:42 <locosage> I'm not even talking about stuff that has m layer
15:20:58 <locosage> that pr remaps sprites without M while 32bpp doesn't
15:22:04 <peter1138[d]> Obviously, it HAS to remap 32bpp to palette indexes, that's the entire pointl.
15:22:31 <locosage> but it doesn't HAVE to apply remap to them afterwards
15:22:51 <peter1138[d]> Okay. What remap is being applied?
15:23:23 <locosage> I just used news remap (803) as objects don't seem to allow custom remaps
15:23:44 <peter1138[d]> I don't understand.
15:23:51 <peter1138[d]> You applied the news remap?
15:24:06 <peter1138[d]> Isn't that you applying the remap, not my code?
15:24:13 *** gelignite has quit IRC (Quit: Stay safe!)
15:24:25 <locosage> that grf uses 32bpp sprite with news remap
15:24:41 <locosage> 32bpp doesn't apply remap to the pixels with m== 0
15:25:52 <peter1138[d]> You are conflating about 5 million different tings.
15:26:34 <locosage> what different things? I even attached the grf that does exactly that
15:27:33 <truebrain> jfs: can you give me permissions in the Discord OpenTTD Team to make new applications? ๐
15:28:39 <peter1138[d]> That isn't my patch applying a remap
15:28:42 <peter1138[d]> That's you applying a remap
15:29:14 <locosage> your patch makes openttd code apply it
15:29:26 <locosage> only on 8bpp blitter
15:29:36 <jfs> truebrain: 15 minutes and I can look at it
15:30:39 <peter1138[d]> Arguably that's an issue with 32bpp mode, but it depends on the remap.
15:30:51 <peter1138[d]> There is no way to handle all different remaps correctly.
15:31:09 <peter1138[d]> CC remaps only map 8 colours
15:32:09 <peter1138[d]> IIRC the news remap is meant to make everything monochrome, so technically it should be applied to 32bpp pixels too, but that's not how remaps are implemented (except for the transparency remap which is special-cased)
15:32:39 <locosage> arguments could be made both ways for 32bpp remaps
15:32:49 <locosage> news remap should ofc remap everything
15:33:19 <locosage> but if it's smth like train sprite with only lights in m layer and some remap it shouldn't remap everything yellow in the image
15:33:42 <peter1138[d]> And this is the crux of the matter. That is nothing to do with 32bpp-to-8bpp.
15:34:06 <peter1138[d]> 32bpp-to-8bpp can't handle all random remaps possible, so it tries to handle simple CC remapping at least.
15:34:32 <locosage> indexed color remapping is a topic I'm not even touching
15:34:38 <locosage> I'm talking rgb remap only
15:34:51 <locosage> and 8bpp make different choice compared to 32
15:35:23 <locosage> which one is more correct idk, but it's different
15:35:59 <peter1138[d]> Well, frankly, big fucking deal.
15:36:25 <locosage> well, frankly whole 8bpp blitter is pointless :p
15:36:25 <jfs> truebrain: can you check now?
15:37:02 <peter1138[d]> One of those is more usable than the other
15:37:26 <peter1138[d]> locosage: great, then stop interjecting with bullshit
15:37:53 <locosage> the heck is your problem?
15:38:00 <locosage> I just pointed out an issue with your pr
15:38:06 <locosage> you can chose to ignore it
15:45:55 <jfs> truebrain: random idea for art assets that could be used: OpenGFX images of a bus or loco in all the company colors, set based on the actual company color the player is currently in, and maybe some other image that can be used if the player is spectating
15:46:16 <truebrain> let's first get the basics done ๐
15:46:21 <truebrain> but I like the way you think ๐
15:46:28 <truebrain> it is shocking how few games integrate with Discord btw, hard to find other examples
15:49:31 <peter1138[d]> Okay, so static_cast<Colours>(x)
15:49:52 <peter1138[d]> Problem with that is you can still force things that shouldn't happen.
15:50:01 <jfs> truebrain: looks like maybe OpenRCT2 does? one used here seems to have some kind of rich presence from that right now
15:50:56 <truebrain> peter1138[d]: what do you mean, "force"?
15:51:45 <peter1138[d]> Well, it's a cast, they're often used for forcing one type to another ๐
15:51:55 <truebrain> isn't the `Colour(n)` doing the same?
15:52:26 <truebrain> from what I remember from C++, it is just a shorthand for the `static_cast`
15:52:36 <truebrain> I am btw fine with either form; just not with the `(Colour)n` form ๐
15:54:15 <truebrain> you got to "love" C++ ๐
15:56:50 <truebrain> jfs: random fun "fact": latest Discord SDK doesn't compile with C++17 .. it is missing an include for `cstdint` .. lol? ๐
15:57:11 <peter1138[d]> Ah, okay, so Colours(n) is the same as (Colours)n, but it's just C++ style instead of C-style.
15:57:42 <peter1138[d]> So, can I do Colours(n)? LordAro pointed it out as a problem, but it's... neater than static_cast<Colours>(n), no?
15:57:56 <truebrain> peter1138[d]: seems so; so whether you use `Colours(n)` or `static_cast<Colours>(n)`, I don't care ๐ Up to LordAro ๐
15:58:34 <truebrain> I like the first as it is shorter, and more readable
15:58:45 <truebrain> I don't like it, as it implies there is some validation going on (there isn't)
15:59:23 <peter1138[d]> So potentially the second is more explicit that it is just a cast...
15:59:47 <truebrain> what colour shall we paint this bikeshed
16:00:07 <peter1138[d]> Careful, you wouldn't want some other piece of code to be remapping it.
16:00:36 <truebrain> the transparent colours of a plague?
16:01:09 <jfs> truebrain: are you looking at the GameSDK or the older Discord-RPC?
16:01:30 <jfs> as far as I remember, the GameSDK is not very GPL friendly
16:01:34 <truebrain> it contains `#include <stdint.h>` .. has to be `cstdint` ๐
16:01:52 <truebrain> the whole point of us making this social presence platform is to allow non-GPL-friendly plugins ๐
16:02:42 <jfs> yeah, but the Discord-RPC one can be GPL compatible, as far as I remember, and be included in the package
16:03:50 <peter1138[d]> Squirrel implementation? ๐
16:03:57 <jfs> which is very useful since the general consent seems to be that if your dynamic plugin platform only has plugins of non-compatible licenses then some angry people might use it as an excuse to call it out as just an excuse to circumvent the idea of GPL
16:04:04 <peter1138[d]> Hmm, maybe I should make a function that takes a integer, validates it, and returns a Colours.
16:04:17 <peter1138[d]> Then we know it IS validated, and there's only one cast.
16:04:44 <truebrain> jfs: but it is ๐
16:04:51 <truebrain> but as we are the license holders, we can do so
16:05:05 <truebrain> either way, I am not against having a few GPL-licensed plugins ๐
16:05:40 <truebrain> I wonder what license GOG is
16:06:00 <peter1138[d]> Yeah, I think you might need to create your own GPL social platform to allow that ๐
16:06:27 <jfs> well, the Discord-RPC library is MIT license, and the GameSDK is closed source with only headers available
16:06:29 <peter1138[d]> Or hook into Gaim.
16:06:40 <jfs> and Discord-RPC is arguably _easier_ to use too
16:07:03 <jfs> yeah but it's not clear if they ever intend to remove support for it
16:07:40 <jfs> I think the library is deprecated, but the protocol it implements is not
16:09:05 <truebrain> for some reason I expected the GOG SDK to be some form of Open Source
16:09:09 <truebrain> but I can only find binaries
16:09:44 <truebrain> anyway, first let's get it to work, after let's battle with licenses etc ๐
16:10:16 <peter1138[d]> GOG stuff is meant to be DRM-free but that doesn't mean they understand Open Source.
16:10:30 <jfs> this one using Discord-RPC did definitely work last I touched it tho
16:10:52 <jfs> and I had it actually setting presence on discord
16:10:58 <truebrain> you sure you used Discord RPC?
16:11:03 <truebrain> as it reads like you used Discord Game SDK
16:11:07 <truebrain> given the readme tells me that ๐
16:11:23 <truebrain> (and I copy pasted some code from that today, with the Discord Game SDK)
16:17:07 <jfs> I had it on a separate branch
16:18:41 <truebrain> lol, steam needs 32bit libc .. ugh
16:21:35 <truebrain> and segfaults in WSL .. awwwhhh
16:32:38 <xarick> > ... and adds again the same vehicle to vehicle_list
16:32:48 <xarick> the items must be unique
16:34:03 <jfs> yes that's the defining property of a set
16:38:00 <truebrain> hmmm .. not being able to launch Steam under WSL2 makes development more difficult ...
16:38:11 <truebrain> something segfaults, but I have no clue what ๐
16:38:33 <truebrain> as in, `steamwebhelper[141264]: segfault at 39 ip 00007f64d7512aa4 sp 00007ffd36b826a0 error 6 in libcef.so[7f64d73fb000+7770000]` is all I got ๐
16:39:58 <LordAro> peter1138[d]: looks a bit too like a constructor to me, seems confusing
16:46:10 <truebrain> it is meant to look like a constructor; nothing actually wrong with that, is there? You are constructing an enum from an integer?
16:46:11 <peter1138[d]> (And, in a way, it is kind of constructing, but actually not...)
16:46:15 <truebrain> if it would be a class, nobody would mind ๐
16:47:07 <truebrain> okay, it seems it is crashing because it tries GPU support, but .. people keep saying: disable GPU support in the settings ... but I can't get into the settings, ffs! ๐
16:59:56 <andythenorth> Flat Christmas Docks?
17:16:07 <peter1138[d]> I think I addressed everything other than `Colours(n)` vs `static_cast<Colours>(n)`.
17:17:31 <xarick> I tried to use std::vector
17:18:01 <merni> Maybe you should read the error message :p
17:18:20 <xarick> It was the train_cmd.cpp which is a mess
17:18:21 <merni> Also really silly how MS still has Abort/Retry/Ignore on its error messages
17:19:21 <xarick> it was attempting to remove a non-existant vehicle from the std::vector list
17:19:44 <xarick> this works with std::set, no complaints, but std::vector gets angry
17:20:28 <xarick> I could check if the item exists beforehand
17:20:38 <xarick> but that just complicates the code, hmm
17:21:43 <peter1138[d]> You need a slightly different iterator loop if you intend to erase from it while iterating.
17:21:53 <peter1138[d]> There's plenty of those in the code.
17:23:24 <xarick> it's not running a loop, it just wants to remove an item from the list
17:23:33 <peter1138[d]> Usually you'll find a for loop with `/* nothing */` as the 3rd 'parameter'
17:24:20 <xarick> train_cmd.cpp passes a RemoveVehicleGroup somethin from group with no real vehicle, but a wagon, which aren't accounted for
17:24:53 <peter1138[d]> wagons shouldn't have a group.
17:26:18 <xarick> i think the wagon is the head
17:26:49 <xarick> and when attaching an engine in front, it does some move vehicle stuff, and that does a call to remove group
17:28:18 <peter1138[d]> wagons can't be head vehicles.
17:28:30 <peter1138[d]> (Only inside depots)
17:28:45 <xarick> well, it is happening in a depot
17:30:18 <peter1138[d]> There's no "RemoveVehicleGroup" in vanilla, so...
17:33:32 <xarick> my bad, let me be a bit more specific: there is a call to `GroupStatistics::CountVehicle` from `CmdMoveRailVehicle`
17:33:58 <xarick> happens when i build a wagon, and next I build an engine
17:35:20 <xarick> it doesn't care if it's wagon
17:35:28 <xarick> it just updates the counter
17:37:19 <xarick> and the code I added, tries to remove that "wagon" from a std::vector
17:37:30 <xarick> but wagons aren't accounted for
17:37:53 <xarick> they're not added to the list in the first place, so they're not there
17:38:19 <xarick> std::vector doesn't like it and errors out, but now I'm trying something
17:41:55 <peter1138[d]> CountVehicle shouldn't be called for empty wagons, they should not be marked as FrontEngine.
17:46:54 <xarick> `if (std::find(stats.vehicle_list.begin(), stats.vehicle_list.end(), v) != stats.vehicle_list.end()) stats.vehicle_list.erase(std::find(stats.vehicle_list.begin(), stats.vehicle_list.end(), v));`
17:46:54 <xarick> `stats.vehicle_list.erase(v->index);`
17:47:15 <peter1138[d]> Store the result of std::find.
17:47:44 <peter1138[d]> auto it = std::find(...); if (it != ...end()) { erase(it); }
17:48:15 <peter1138[d]> You are searching for the list twice. As you were complaining about performance, that's probably important.
17:49:56 <peter1138[d]> Oof, this vinyl is a bit crackly.
17:52:22 <xarick> ` it = std::find(stats.vehicle_list.begin(), stats.vehicle_list.end(), v);
17:52:22 <xarick> last = stats.vehicle_list.end();
17:52:22 <xarick> if (it != last) stats.vehicle_list.erase(it);`
17:52:56 <xarick> maybe last should be placed before it
17:53:16 <_glx_> no need to store end() (it's not recommended anyway)
17:54:43 <xarick> not recommended? hmm something goes wrong?
17:55:28 <peter1138[d]> There's no need. Just do `if (it != stats.vehicle_list.end())`
17:56:22 <_glx_> last will most likely be invalidated by erase() (need to check the spec though)
18:16:11 <xarick> now I'm ready to compare who's faster. std::set vs std::vector
18:16:27 <xarick> also, one more question
18:17:59 <xarick> `if (it_all == stats_all.vehicle_list.end()) stats_all.vehicle_list.push_back(v);` the `v` is an entire structure or class, but I only need to extract v->index in reality
18:18:13 <xarick> can v be a pointer or so? I'm not sure
18:19:29 <xarick> I don't really need to cache the entire vehicle properties
18:20:33 <peter1138[d]> v is normally a pointer.
18:46:34 <xarick> yep, std::vector is faster!
18:47:56 <xarick> gonna have dinner, I'm letting this run in fast forward meanwhile, will come back to see if it still stands
18:52:51 <peter1138[d]> So what you're saying is we need to penalise scripts that repeatedly create lists?
19:00:33 <peter1138[d]> Hmm, so actually I renamed Colour, but not Colours. yet.
19:01:39 <peter1138[d]> I wonder what it should be. They're used mostly for interface colours and company colours, but also houses and industry colours.
19:04:53 <truebrain> right, what was I doing? Ah, yes, getting Steam to work on WSL ..
19:07:27 <truebrain> ah, someone made a Docker where things "just work"
19:07:46 <truebrain> now can I run that on the host system, so OpenTTD can talk to it ..
19:10:21 <truebrain> seems I cannot, sad
19:14:26 <truebrain> at least by accident I fixed again that I have OpenGL working in WSL2 ๐
19:19:48 <truebrain> `../../third_party/tcmalloc/chromium/src/tcmalloc.cc:337] Attempt to free invalid pointer 0x2322b60 `
19:19:53 <truebrain> that feels like a problem
19:37:29 <locosage> AdjustBrightness doesn't really have much leverage in saturation huh
19:37:41 <locosage> surprising that is even has some actually
19:41:34 <xarick> well, std::vector still leads, gonna try a different test
19:56:14 <peter1138[d]> Adding things for that gets 'dangerously' close to GRF climates ;p
20:01:50 <truebrain> if I let Steam start steam, it crashes on, what I think, my GPU driver .. if I start it manually, it uses a software driver that doesn't create a window ... annoying ๐
20:03:04 <xarick> std::vector on the right, std::set on the center, test with real AIs
20:03:47 <xarick> not sure what NoNoCAB is doing that is tanking performance, doesn't look like it's related with lists
20:04:09 <xarick> AIAI greatly benefits from group vehicle lists though
20:06:04 <locosage> even for two colors it takes forever to calculate full saturation-value rectangle
20:08:46 <locosage> only has some saturation leverage in darker colors...
20:29:37 <truebrain> ugh, I guess I really do need to setup a Windows VSCode to work on .. can't get Steam to work in WSL ๐ฆ Sad
20:31:59 <truebrain> like a compiler wouldn't optimize that ๐
20:34:54 <Rubidium> xarick: well, the first thing is that you ought to compare the same version, except for the changes you want to test. As now there're way to many variables. Also, is sorted-ness of VehicleIDs required? If not, then std::unordered_set might be better over std::set
20:35:33 <Rubidium> and obviously comparing the exact same time frame will also help with comparisons
20:35:33 <xarick> doesn't require to be sorted, no
20:35:44 <xarick> let me try unordered set
20:37:54 <peter1138[d]> truebrain: i know right... but someone must have profiled it to explicitly write that...
20:38:08 <truebrain> you can always hope someone actually did ๐
20:39:14 <truebrain> owh, I don't even have MSVC installed on this machine
20:39:17 <truebrain> this is going to take some time ๐ฆ
20:39:28 <Rubidium> and they profiled that like a decade ago? :D
20:39:56 <truebrain> I just have a really hard time to believe a compiler, especially in 2023, wouldn't take care of it ๐
20:40:05 <truebrain> but it is also not relevant.. consistency is more important, so your PR is right ๐
20:40:25 <Rubidium> oh, even one-and-a-half decade ago. Yay 50% safety margins ;D
20:40:25 <peter1138[d]> Indeed, probably not. But as it's already there, as you say ๐
20:40:43 <peter1138[d]> We probably clobbered performance a lot over that time ๐
20:42:08 <truebrain> owh, right, vcpkg is integrated in MSVC these days .. let's see if we can also actually make use of that
20:43:32 <locosage> somehow it kind of works...
20:46:15 <truebrain> why is it not worth it?
20:48:24 <_glx_> vcpkg included in MSVC install supports only manifest mode, and if you use manifest mode (vcpkg.json exists), all targets must use manifest mode
20:48:40 <truebrain> still not see the issue?
20:49:25 <_glx_> for linux CI we only need one package, but for release we need more than one package
20:49:35 <truebrain> Linux doesn't care about vcpkg.json
20:49:48 <truebrain> how? It is not like we use MSVC for it?
20:50:12 <_glx_> we use `vcpkg install` for breakpad
20:50:40 <truebrain> but even for Linux, we can make the vcpkg.json looks correct, not?
20:50:45 <_glx_> and it detects the .json "error: In manifest mode, `vcpkg install` does not support individual package arguments."
20:51:13 <truebrain> so we use the vcpkg.json for Linux too?
20:51:18 <truebrain> sounds a lot easier for .. everyone?
20:51:22 <truebrain> there is something you are not sharing ๐
20:52:02 <_glx_> and many more libs in release workflow
20:52:33 <truebrain> I guess I have to try it myself to find out what you are actually trying to say ๐ As I am not getting the issue ๐
20:52:55 <truebrain> first the endless question: so I opened my project as a CMake project .. now what ...
20:53:01 <truebrain> once again the freaking build button is not there
20:56:02 <truebrain> hmm ... it says "untrusted", but doesn't tell me how to make that go away
20:58:39 <truebrain> ugh, guess opening from a WSL location just makes MSVC go BRRRRRRRRGGGSDFSFSQT#wergargaeboem
21:00:07 <_glx_> oh opening from WSL in MSVC should be as slow as accessing NTFS from WSL
21:00:17 <truebrain> there are 4 files in this folder
21:03:56 <_glx_> so manifest mode looks like a good idea, but not very practical in our workflows
21:04:35 <truebrain> we can always remove the files on the CI
21:04:45 <truebrain> but I think the value it adds to our Windows developers far outweights any drawback it might have
21:05:50 <truebrain> one can even argue if it is a problem to use vcpkg on Linux for all dependencies
21:06:03 <truebrain> we only use the non-vcpkg ones to check we can be compiled on Ubuntu with most common libraries from Ubuntu
21:06:11 <xarick> my AI got a weird error. m_bridgeTiles = []; it's always an array even in its lowest form.
21:06:32 <xarick> append should work on it
21:08:27 <_glx_> I don't see m_bridgeTiles in the debug log
21:09:50 <truebrain> hmm, no symlinks on Windows ofc .. hmmm
21:10:35 <truebrain> let's play the game: how often will I forget to copy this file!
21:11:18 <_glx_> symlinks exist, they are called junctions, and a pain to manage ๐
21:11:27 <truebrain> like I said ... ๐
21:12:20 <truebrain> okay, so if you want to use the integrated vcpkg, even if you do it manually, from within MSVC, you need to have a manifest
21:12:22 <truebrain> interesting approach ๐
21:13:15 <_glx_> yeah integrated vcpkg doesn't support command line mode
21:13:45 <truebrain> it has everything in there, silly enough ..
21:14:37 <_glx_> it was "fun" when I had to reinstall MSVC and it came with its own vcpkg
21:14:57 <_glx_> suddenly it couldn't find my installed packages
21:15:59 <_glx_> and the integrated vcpkg also overrides existing VCPKG_ROOT
21:18:24 <truebrain> so I created a vcpkg.json, but now it tells me: EVERYTHING INSTALLED
21:18:38 <truebrain> it is bacause the default triplet is not "static", lol
21:21:01 <truebrain> that is a bit of a shame, that you can't influence that by some config file
21:21:58 <truebrain> you linked your PR, yes
21:22:25 <_glx_> platform stuff is very verbose (and that's only for windows
21:22:34 <truebrain> that is not a bad thing
21:23:29 <truebrain> for debugging, do we actually care if it is static or not?
21:25:37 <_glx_> static is important for release, but for local stuff it's fine without it
21:25:56 <truebrain> so we can just remove that from the `vcpkg.json`, and it mostly works out-of-the-box
21:27:05 <truebrain> ugh, breakpad still broken?
21:27:09 <xarick> I got a `m_bridgeTiles = null;` but this is in another class, in `class RoadRoute extends RoadRouteManager`. the `m_bridgeTiles = [];` is in `class RoadBuildManager {`. that's the one it's complaining about. `class RoadRouteManager {` orders RoadBuildManager to build a route. Once the route is built, `m_bridgeTiles` is passed over to `RoadRoute`
21:27:44 <xarick> is it because arrays are special creatures?
21:27:53 <truebrain> hmm, their ticket claims they fixed it .. but I guess after the last release
21:28:10 <_glx_> breakpad should be fine
21:28:17 <truebrain> not with their last release
21:29:21 <truebrain> `Imported target "PNG::PNG" includes non-existent path` .. lol
21:29:30 <truebrain> switching between static and non-static made things go boom ๐
21:29:31 <xarick> I'm fairly certain when a route fails to be built, m_bridgeTiles starts a new array, it doesn't clear the current one at all.
21:29:33 <truebrain> I should be a tester ...
21:30:33 <xarick> that RoadBuildManager is still a puzzle to me
21:30:42 <xarick> it's code I inherited from the original author
21:31:22 <_glx_> looks like `m_bridgeTiles` is a global var, so you need to be careful
21:32:21 <xarick> I really don't understand classes, or class extends other class, how is this compounded
21:32:42 <_glx_> that's object programming 101
21:32:56 <xarick> maybe using the same variable name is a mistake
21:33:01 <xarick> in 2 different classes
21:33:08 <xarick> that are extended or whatever to each other
21:33:53 <_glx_> if class A defines some_var and class B extends A, then they both have the same some_var
21:35:58 <xarick> I never had this error in my entire time I developed ludiaiafterfix
21:37:20 <peter1138[d]> Nice, so the recolour sprites' "00" unused byte... is actually the number of entries in the recolour sprite -- except it's a byte, so 256 = 0
21:37:38 <peter1138[d]> There are 3 recolour sprites with only 16 entries, and the value there is... 16.
21:39:10 <truebrain> _glx_: okay, now done fiddling with it, the `vcpkg.json` does make getting MSVC up and running 20 times easier .. so there is value in getting this to work ๐
21:39:58 <_glx_> first configure can be a little slow because it has to build the deps
21:41:05 <truebrain> I did have to add `"builtin-baseline": "94cf042e6b7713913a3b3150f3ca3d0f4550f7c4"` and change it to just be `windows &`, as the `static` filter is a bit silly ๐
21:43:15 <_glx_> I tried without anything in platform (it works)
21:43:32 <_glx_> but I only tested locally on windows
21:43:56 *** nielsm has quit IRC (Ping timeout: 480 seconds)
21:44:07 <truebrain> we just need to check how to do this on the CI Linux .. and I think just removing the file is easiest ๐
21:44:19 <truebrain> anyway, sidetracked, stack pop, first what I was actually doing .. Steam bla ..
21:46:52 <truebrain> in Steam, we can translate the Rich Presence text
21:46:55 <truebrain> so it is local to the user
21:54:16 <xarick> class B = RoadRoute. class A = RoadRouteManager. class C = RoadBuildManager. Class A doesn't define m_bridgeTiles. Class B defines m_bridgeTiles = null, but it has a constructor. Class C defines m_bridgeTiles = [] and is the only one that uses append. A asks C to build a route. C appends bridges to m_bridgeTiles. Once the route is fully constructed, C calls B which passes over C m_bridgeTiles to B
21:54:16 <xarick> m_bridgeTiles via constructor. B is now done and goes back to A, which tells B to clear variables, which means it redefines B m_bridgeTiles = [].
21:57:38 <xarick> class B extends class A. class C doesn't extend. class A doesn't extend.
22:01:01 <xarick> I need to clarify something
22:01:18 <truebrain> `dbg: [misc] Failed to load library '(..)\OpenTTD\out\build\x64-Debug\social_presence\social-steam.dll': The specified module could not be found.` Owh Windows .. why is converting paths always so difficult with you
22:03:29 <truebrain> amazing, it cannot find a module that is there
22:05:49 <_glx_> explains why we prefer static builds ๐
22:05:52 <truebrain> okay, using the DllLoader wrapper is a dead-end anyway .. it is just not useful enough ๐ฆ
22:05:56 <truebrain> no no, this has nothing to do with vcpkg
22:06:23 <_glx_> DllLoader works fine for system libs
22:06:47 <_glx_> maybe it needs some love for others
22:07:10 <truebrain> it always releases the library
22:07:14 <truebrain> in this case, that is not what we want ๐
22:11:08 <_glx_> I think it skips all path before the dll filename then it use the search order
22:11:43 <truebrain> I ruled that out a while ago by putting it in the cwd; still no dice ๐
22:11:54 <truebrain> DllMain is there, functions are exported .. hmm ..
22:11:59 <truebrain> this is always so much easier on Linux ๐
22:12:54 <_glx_> DllLoader releases the lib when object is destroyed IIRC
22:13:06 <truebrain> that is why I am not using it
22:13:38 <xarick> `typedef std::unordered_set<const VehicleID> VehicleIDList;` vs
22:13:38 <xarick> `typedef std::unordered_set<VehicleID> VehicleIDList;`
22:13:38 <xarick> is the `const` gonna help with performance
22:14:53 <truebrain> now Windows Defender things openttd.exe is a Trojan
22:15:10 <truebrain> owh, it corrected itself, and took it back
22:15:12 <truebrain> without telling the user
22:15:17 <truebrain> so first it is like: OMG TROJAN OMG OMG
22:15:20 <truebrain> the it is like: nothing to see here
22:16:05 <xarick> _jgr_: hmm also another question. Which is will end up faster, `VehicleID` or `Vehicle`
22:18:23 <_glx_> and really the performance issue is most likely not there
22:18:43 <Rubidium> though VehicleID is probably faster due to its smaller size, but if it requires a lookup of the Vehicle* from the VehicleID the performance gain might already have been lost
22:20:17 <peter1138> VehicleID is 32 bit, so not that much smaller :)
22:20:22 <_glx_> ideally scripts wouls generate vehicle lists on startup, then update them via events
22:20:44 <peter1138> Keeping lists in sync is a pain, even outside of scripting.
22:21:10 <_glx_> yeah but recreating lists multiple times per tick is worse
22:21:27 <truebrain> okay, so it does find the DLL, it just fails to load it or something .. but unclear .. hmm ..
22:22:23 <_glx_> and GetLastError() doesn't tell the real cause ?
22:22:26 <truebrain> MSVC even tells me the DLL opened fine ..
22:22:41 <truebrain> even that it loaded the symbols fine
22:24:01 <_glx_> could be `If the specified module is a DLL that is not already loaded for the calling process, the system calls the DLL's DllMain function with the DLL_PROCESS_ATTACH value. If DllMain returns TRUE, LoadLibrary returns a handle to the module. If DllMain returns FALSE, the system unloads the DLL from the process address space and LoadLibrary returns NULL. It is not safe to call LoadLibrary from
22:24:01 <_glx_> DllMain. For more information, see the Remarks section in DllMain.`
22:24:04 <truebrain> owh, I am a peanut, lolz
22:24:11 <truebrain> here again, Linux is just more clear
22:24:31 <truebrain> _glx_: no, as I mentioned, I have a DllMain
22:26:41 <truebrain> anyway, I did forget to also move the `steam_api.dll`
22:26:44 <truebrain> so that for sure would have been an issue
22:26:55 <truebrain> but still it fails .. ugh .. GIVE ME BETTER ERRORS
22:27:37 <truebrain> ah, dll-name is weird
22:28:06 <truebrain> they are all "steam_api.dll", but not the win64 .. there it is "steam_api64.dll" ๐
22:28:42 <_glx_> will be simpler in january
22:28:53 <truebrain> they won't change their names ๐ฆ
22:31:01 <_glx_> oh right win10 is not 64bit only
22:31:17 <truebrain> it is, but it is a name they gave to the file
22:31:27 <truebrain> nobody is going to magically change that name on the first of january ๐
22:31:52 <_glx_> no, win10 has x86 version too
22:32:07 <truebrain> win7 is the last 32bit, they claim?
22:34:04 <_glx_> win10 supports 32bit CPU
22:34:17 <_glx_> win11 requires 64bit CPU
22:34:57 <truebrain> hmmm ... can you see your own rich presence in steam, is now the question ...
22:35:11 <truebrain> `dbg: [misc] Social presence plugin 'social-steam.dll' loaded: Steam Social Presence v1.0.0`
22:35:14 <truebrain> that at least is working
22:35:32 <truebrain> I do need to find out how I can hint where it can find the steam DLL, but that is a problem for another day
22:36:43 <truebrain> this is why I wanted to run it on WSL, so I can see myself .. hmmm
22:37:51 <truebrain> okay, if it would work, it would show up .. it doesn't ๐
22:41:25 <_glx_> there is SetDllDirectory (or AddDllDirectory and LoadLibraryEx with LOAD_LIBRARY_SEARCH_USER_DIRS if more than one dir need to be added to search path for a given lib)
22:46:18 <truebrain> _glx_: just to check, on Steam it doesn't show me as `In menu`, right?
22:46:58 <truebrain> hmmmm .. so at least I see the same thing
22:53:40 <LordAro> you can of course still run 32bit programs on win11 64bit
22:55:53 <truebrain> hmm .. I don't get the Steam SDK .. I had similar issues with Discord .. takes a while to understand what they are actually expecting, and when
23:09:49 <truebrain> ha, now it works ๐ I had to put my Steam client in a mode it is allowed to do this while not launching the game via Steam itself ๐
23:11:48 <truebrain> look at that ... okay ... that works .. now time to clean things up ๐
23:23:30 <xarick> I dropped 13.4 from the test
23:23:41 <xarick> we already know it's slow
23:24:07 <xarick> in its place, we got std::unordered_set<VehicleID>
23:25:38 *** Wolf01 has quit IRC (Quit: Once again the world is quick to bury me.)
23:28:13 <xarick> is there any other std container I could try that is faster than std::vector
23:29:15 *** keikoz has quit IRC (Ping timeout: 480 seconds)
23:35:11 <Rubidium> std::array is arguably faster than std::vector, but that won't help you much
23:38:58 <xarick> thx, I'll take a look at std::array tomorrow
23:55:14 <truebrain> you never know what they actually try to do
23:55:17 <truebrain> and often it is the wrong thing
continue to next day โต
