IRC logs for #openttd on OFTC at 2023-12-31
00:02:00 <DorpsGek> [OpenTTD/OpenTTD] PeterN commented on pull request #11654: Codechange: Use vector and unique_ptr for nested widget tree.
00:04:56 <DorpsGek> [OpenTTD/OpenTTD] LordAro commented on pull request #11654: Codechange: Use vector and unique_ptr for nested widget tree.
00:05:38 *** Wolf01 has quit IRC (Quit: Once again the world is quick to bury me.)
00:07:31 <truebrain> well, I tried to decode the motivation/description of #10548 .. I have no clue what that PR is suppose to do ๐Ÿ˜› I hope one of you is following it ๐Ÿ˜„
00:09:34 <peter1138[d]> I think the purpose is groups cache vehicle lists.
00:14:14 <_glx_> the original idea was to cache vehicles in groups then use that to speed up ScriptVehicleList creation
00:14:35 <_glx_> but as always it kinda diverged
00:14:47 <truebrain> the motivation/description seems to have little overlap with the actual content
00:15:00 <truebrain> it also makes the code rather tricky to read ..
00:15:48 <peter1138[d]> You're... actually reading it?
00:15:49 <truebrain> and it makes me seriously wonder why it would be faster to iterate all vehicles of all companies, versus just all vehicles
00:16:00 <truebrain> owh; I am sure.
00:20:05 <truebrain> gives me the idea that this can also be solved by (finally?) splitsing player-vehicles from all the other things, like disasters etc? ๐Ÿ˜›
00:20:14 <peter1138[d]> the last commit is funny
00:20:56 <peter1138[d]> iterating group_all[vtype].vehicle_list, then testing the type, and adding it do the stats.
00:21:11 <peter1138[d]> Instead of just using vehicle_list.size()
00:21:43 <_glx_> some people like loops ๐Ÿ™‚
00:21:45 <peter1138[d]> (road vehicles need handling but not the rest)
00:22:16 <peter1138[d]> It does use .size() later mind you.
00:24:06 <peter1138[d]> truebrain: "other things" are miniscule compared to player vehicles.
00:24:22 <truebrain> owh, and I guess this only loops all primary vehicles?
00:24:30 <truebrain> guessing here
00:24:33 <truebrain> as it isn't described
00:24:54 <_glx_> the cache is updated with group statistics
00:25:17 <truebrain> yeah, that sentence makes no sense to me ๐Ÿ˜› What does statistics have to do with anything iterating? ๐Ÿ˜„
00:27:43 <peter1138[d]> I think it's because he was struggling with group list performance originally. GroupStatistics has a Count() method that is passed a Vehicle *, so I guess one thing led to another...
00:30:28 <DorpsGek> [OpenTTD/OpenTTD] PeterN updated pull request #11654: Codechange: Use vector and unique_ptr for nested widget tree.
00:31:11 <peter1138[d]> I dunno ๐Ÿ˜ฎ
00:31:18 <peter1138[d]> I still have the last version...
00:31:36 <truebrain> peter1138[d]: ah; well, okay then. I guess.
00:32:34 <peter1138[d]> So now this system, uses all your memory to keep a list of vehicles, so that it doesn't need to check a couple of conditions in other loops.
00:37:50 <truebrain> and makes for very unreadable code ๐Ÿ˜ฆ
00:38:04 <peter1138[d]> Yes
00:38:57 <talltyler> It seems to be a solution in search of a problem, at least to me
00:39:38 <talltyler> The test cases that it improves are unlikely to happen in real gameplay
00:39:42 <_glx_> BTW a cache mechanism for ScriptVehicleList would be nice (because some AIs like to create many identical lists in a single tick to filter them)
00:40:53 <_glx_> but the test cases use worst case scenario
00:41:07 <_glx_> which is not very representative
00:42:25 <truebrain> _glx_: Stimulating bad behavior also seems like a poor choice ๐Ÿ˜„
00:42:50 *** admeliora has joined #openttd
00:42:50 <admeliora> Caching is nice till it's not
00:43:34 <admeliora> Unless we're talking about stack cache and locality at that case obviously the optimizations almost always help
00:44:01 <peter1138[d]> Increase instruction cost of creating lists so that scripts that do it too often get paused more frequently...
00:44:23 <admeliora> Pausing is bad
00:44:49 <_glx_> they already are pause for each command
00:44:54 <admeliora> There's reason why sleep like functions are used for very niche situations
00:45:59 <truebrain> Did we already apply filters on vehiclelist? Like type? Company? Primary yes/no?
00:46:08 <truebrain> Or does the script need to do that?
00:46:25 <_glx_> we have some filtering per company
00:46:31 <_glx_> but not per type
00:46:47 <truebrain> As I am guessing that is why many lists are made?
00:46:55 <admeliora> Idk the codebase of ottd, but good step forward in optimization is usually complete refactor using more modern approaches, but that's quite huge ordeal :widdle_goblin:
00:47:17 <truebrain> Meh; I would have to look at an actual AI to add value to this conversation ๐Ÿ˜›
00:47:22 <_glx_>
00:47:46 <_glx_> I guess we could add some type filtering here
00:48:05 <admeliora> Actually speaking of features. How much do y'all think it would be nice to be able to do contracts for other companies ?
00:48:08 <_glx_> reducing valuate call just to filter for type
00:48:09 <truebrain> But okay.. solution -> problem situation indeed
00:51:58 <admeliora> I might do prototype but idk how good the filtering will be
00:52:05 <_glx_> I can imagine how an AI handling all types of vehicles in sequence would need to create AIVehicleList + Valuate 4 times
00:52:17 <admeliora> Immediately on top of my head probably is_same would be used idk
00:53:14 <_glx_> while a simple AIVehicleList_Type would get the reduced dataset directly
00:53:19 <DorpsGek> [OpenTTD/OpenTTD] PeterN opened pull request #11660: Fix: Calculation of initial engine age was inaccurate.
00:54:17 <_glx_> but often AI authors work around limitations instead asking for API improvements
00:54:22 <admeliora> Does AI rn cause perf issues ?
00:54:27 <admeliora> Just curious
00:54:58 <_glx_> they can, some API calls can be expensive and uninterruptable
00:55:28 <admeliora> _glx_: Reminds me of old-school C devs that abused UB's to do super whack solutions to even more whack problems
00:55:30 <_glx_> everything else we limit the opcodes
00:55:35 <truebrain> _glx_: Or maybe we should look into an ability to stack filters, instead a new type every time. Dunno
00:56:20 <_glx_> like creation with integrated valuate ?
00:56:26 <truebrain> Was a reason we didn't before
00:56:27 <admeliora> _glx_: I see so you're basically having whole VM inside ottd if I get it right
00:56:34 <truebrain> _glx_: Yeah
00:57:09 <_jgr_> Squirrel lists are rather expensive, so having fewer lists or lists with fewer elements is generally good news
00:57:47 <admeliora> Depends on how lists are handled really
00:58:05 <admeliora> If you're having good algo even ridiculous sets aren't issue really
00:58:36 <admeliora> But I agree it's less of a load obv
00:59:19 <_glx_> it's all in <> ๐Ÿ™‚
01:00:58 <_glx_> and yes it's complicated because it needs to interface with squirrel
01:01:09 <admeliora> Oh great I thought that it would be part of some overcomplicated parser
01:01:14 <DorpsGek> [OpenTTD/OpenTTD] github-advanced-security[bot] commented on pull request #11654: Codechange: Use vector and unique_ptr for nested widget tree.
01:01:16 <admeliora> I might take a look
01:01:21 <admeliora> And try
01:01:41 <_jgr_> The issue is the storage format, not really the algorithm
01:02:59 <admeliora> Idk I don't think you're using the advantage of cache locality with the Algo enough but could be just me not being initiated to the whole codebase
01:03:39 <admeliora> Perhaps some of the lists could be transposed as well
01:04:19 <admeliora> As I said I'll give it good read and then I'll try some ideas on local obv
01:05:42 <reldred> Just keep in mind this code base turns, what, twenty? very soon...
01:05:56 <_glx_> maybe not for AIs ๐Ÿ™‚
01:06:03 <reldred> that said, I know shit about fuck so I can't judge ๐Ÿ˜›
01:06:24 <admeliora> reldred: Yeah I know but for it's age it looks pretty dam good
01:06:37 <admeliora> Seen very ugly old codebases
01:06:37 <reldred> Lot of very very very dedicated people over the years
01:06:43 <_glx_> 15 years ๐Ÿ™‚
01:07:19 <_glx_> admeliora: we are strict on coding style ๐Ÿ™‚
01:07:39 <admeliora> Style doesn't necessarily guarantee time-proof code
01:08:00 <admeliora> But this one stood the test of time at least from the small section of what I saw
02:39:12 *** Flygon has joined #openttd
03:58:25 *** debdog has joined #openttd
04:01:54 *** D-HUND has quit IRC (Ping timeout: 480 seconds)
04:18:58 <alfagamma7> reldred: Damn that's old
04:22:10 <reldred> Original transport tycoon came out 29 years ago ๐Ÿ˜›
04:22:31 <reldred> Get off my lawn you damn kids
04:44:35 <emperorjake>
04:44:35 <emperorjake> I just passed my 17th anniversary of playing
04:44:49 <emperorjake> My first saves from 2006
04:45:31 *** keikoz has joined #openttd
04:57:00 <johnfranklin> How can a 2007 game with 8MB size? I think back then there were even no 2048^2 maps.
04:57:35 <reldred> Sure there were. Big maps was super super early days in OpenTTD
04:57:59 <reldred> They got big maps before they had path signals Iโ€™m pretty sure.
05:47:32 <johnfranklin> How long to travel from Adelaide to Sydney by train? Do planes beat trains on this route?
05:50:41 <admeliora> reldred: :widdle_goblin:
05:50:59 <johnfranklin> Oh, just found to be very long...
06:19:57 <lamarr> johnfranklin: All interstate routes are beaten by plane, Syd - Melb is 1:30hr by plane, 12+hr by train.
06:23:07 <lamarr> Might be different for some regional locations though, I know Brisbane and Western Australia have some higher speed railways.
06:36:05 <reldred> johnfranklin: Ahahahahahahahahahahahahahahahahahahahah
07:20:10 <emperorjake> *breathes in* Hahahahhahahahahahahahaha
07:23:08 <alfagamma7> Is this some joke that's too Aussie for me to understand?
07:27:28 <reldred> Australia big
07:27:32 <reldred> Train slow
07:30:52 *** tokai|noir has joined #openttd
07:30:52 *** ChanServ sets mode: +v tokai|noir
07:37:45 *** tokai has quit IRC (Ping timeout: 480 seconds)
07:42:31 <lamarr> train so so slow :(
07:43:03 <alfagamma7> Can relate
07:44:22 <alfagamma7> It takes 2 days straight to travel between Delhi and Kolkata
08:18:44 <DorpsGek> [OpenTTD/OpenTTD] rubidium42 commented on pull request #11660: Fix: Calculation of initial engine age was inaccurate.
08:20:27 *** Wolf01 has joined #openttd
08:23:38 <DorpsGek> [OpenTTD/OpenTTD] PeterN commented on pull request #11660: Fix: Calculation of initial engine age was inaccurate.
08:32:43 <DorpsGek> [OpenTTD/OpenTTD] PeterN updated pull request #11660: Fix: Calculation of initial engine age was inaccurate.
08:56:23 <DorpsGek> [OpenTTD/OpenTTD] PeterN updated pull request #11654: Codechange: Use vector and unique_ptr for nested widget tree.
08:59:36 <DorpsGek> [OpenTTD/OpenTTD] rubidium42 approved pull request #11660: Fix: Calculation of initial engine age was inaccurate.
09:02:24 <andythenorth> hmm
09:02:34 <andythenorth> powered wagons in grf
09:02:45 <andythenorth> maybe there's a better way than doing it via varact2
09:03:33 <andythenorth> what is this property?
09:04:27 <andythenorth> oh relies on livery override
09:04:30 <andythenorth> what is that?
09:04:58 <peter1138[d]> More coffee?
09:05:16 <peter1138[d]> That is livery overrides.
09:05:49 <andythenorth> I have zero coffee, so any amount would be infinitely better
09:05:59 <andythenorth> although IRL, negative amounts aren't going to work
09:06:01 <peter1138[d]> It was the original way to have different graphics/callbacks on a wagon depending on which engine type it is attached to.
09:06:27 <andythenorth> hmm
09:06:37 <andythenorth> never used it ๐Ÿ™‚
09:06:55 <andythenorth>
09:06:55 <andythenorth> just made lots of vehicles with IDs ๐Ÿ™‚
09:07:09 <peter1138[d]> We noticed ๐Ÿ™‚
09:07:22 <reldred> though you wrote "IED's" for a moment there
09:07:22 <peter1138[d]> They are another "we don't have many IDs" work around, to be honest.
09:07:45 <andythenorth> oh
09:07:48 <andythenorth> I see ๐Ÿ™‚
09:07:50 <peter1138[d]> DBSetXL from 2005 uses it a lot, which shows its age.
09:08:00 <reldred> dark old days TTDPatch technology
09:08:18 <andythenorth> I have a case which is really fiddly and probably shouldn't be attempted
09:08:25 <andythenorth> powered wagons, but bi-mode
09:08:34 <andythenorth> so they should delegate the power value to the engine
09:08:57 <andythenorth> but doing that in varact 2 is .... not easy
09:08:57 <peter1138[d]> Does your kid's gaming PC have a case which is really fiddly and probably shouldn't be attempted?
09:09:16 <andythenorth> no, actually the case is probably worth at least 10% of the purchase price
09:09:25 <peter1138[d]> Fancy.
09:09:32 <andythenorth> it's not badly made
09:09:41 <peter1138[d]> By delegate, do you mean you want to add power to the lead engine?
09:10:30 <andythenorth> each coach should have power (IRL they're all powered with diesel engines + a powerline on the train to the pantograph car for AC tracks)
09:10:59 <andythenorth> for most Horse units, player just adds as many as they want
09:11:10 <andythenorth> they're all engines, not wagons
09:11:24 <andythenorth> but these have dual-head cabs, so more engines can't be added
09:11:31 <DorpsGek> [OpenTTD/OpenTTD] PeterN commented on pull request #11654: Codechange: Use vector and unique_ptr for nested widget tree.
09:11:53 <andythenorth> really the problem is the dual-head part ๐Ÿ˜›
09:12:29 <peter1138[d]> You could do it the DBSetXL way. Have "MORE" and "STOP" wagons ๐Ÿ˜„
09:12:45 <andythenorth> I don't want to get the grf from bananas and look at that ๐Ÿ™‚
09:13:23 <peter1138[d]> Just as well as you can't.
09:29:10 *** nielsm has joined #openttd
09:29:35 *** keikoz has quit IRC (Ping timeout: 480 seconds)
09:38:34 <peter1138[d]> Okay so factory pattern version is not viable ๐Ÿ˜ฆ
09:43:45 <andythenorth> hmm
09:43:54 <andythenorth>
09:43:54 <andythenorth> could do these as not dual-head
09:44:14 <andythenorth> just two-unit articulated, then magically change the sprites if attached after the engine
09:46:45 <andythenorth>
09:46:45 <andythenorth> ha the compile made a nearly-correct buy menu sprite ๐Ÿ˜›
09:56:56 <xarick> - is it possible for a vehicle be a primary vehicle if it's not the first?
09:58:56 <jfs> currently, no
09:59:20 <jfs> if a "driving backwards" patch is ever implemented, that might change
09:59:50 <xarick> interesting
10:01:28 <xarick> anyway this function is CheckCaches(), probably not a good idea to iterate from the group veh lists
10:02:52 <xarick> or my own cache check stuff needs to be moved before this
10:02:55 <peter1138[d]> Checking a cache from your own cache? No.
10:05:20 <xarick> okay, guess I'll leave it
10:19:30 <andythenorth> Another gaming PC arrived
10:19:34 <andythenorth> Itโ€™s lol
10:19:59 <xarick> - I found a "not really a bug". Aircraft shadows are checked for orders
10:20:22 <andythenorth> This one has RAM coolers with LEDs on
10:21:51 <andythenorth> FFS canโ€™t boot Windows without a network connection. But it wonโ€™t join our wifi and canโ€™t configure the wifi adaptor without booting Windows
10:23:02 <xarick> as long as shadows and rotors can't be given orders, this is fine
10:23:31 <xarick> it would be funny though, seeing the rotors sudenly go their own way
10:23:35 <jfs> there's supposed to be a way to make win11 continue the initial setup without an internet connection, but it requires pressing a secret key combination and entering some command
10:24:07 <andythenorth> Thethered to a phone
10:24:38 <andythenorth> Now itโ€™s downloading multi-gigabyte update over the phone connection
10:24:59 <andythenorth> Thatโ€™s his data allowance used up ๐Ÿ˜›
10:25:42 <andythenorth> This is lol
10:31:02 <andythenorth> Hmm Windows Settings has very limited options for Wifi adaptors?
10:31:51 <andythenorth> Why do I need to be logged in to use Edge?
10:32:03 <reldred> You don't
10:32:22 <reldred> But yeah, it wants you to. Same as Chrome and Firefox I guess.
10:32:56 <andythenorth> Why do I have to accept cookies to use Edge? ๐Ÿ˜›
10:33:08 <andythenorth> I need off-topic ๐Ÿซค
10:33:37 <andythenorth> Ok so we have to attach wifi antennas to the PC
10:33:38 <xarick> can wagons have orders? I wonder if a IsPrimaryVehicle check is missing there
10:33:51 *** keikoz has joined #openttd
10:34:42 <andythenorth> Lol why no antenna in the case? I get that external antennas are more flexible, but this is lol
10:35:32 <andythenorth> Basically gaming PCs are 80% of the cost goes on a mid-range GPU, most of the rest is LEDs
10:35:47 <peter1138[d]> Step 1: Don't use Edge or Chrome.
10:35:59 <peter1138[d]> No, wagons cannot have orders.
10:36:12 <belajalilija> firefox gang
10:36:18 <andythenorth> Need Edge to get other browsers ๐Ÿ˜›
10:36:30 <andythenorth> Orโ€ฆ.curl? ๐Ÿ˜›
10:36:44 <belajalilija>
10:36:44 <belajalilija> andythenorth:
10:37:14 <andythenorth> This PC was around ยฃ1100 and has a nicer case than the other one, this child is better at research
10:37:52 <xarick> how much is that in euros?
10:38:10 <DorpsGek> [OpenTTD/OpenTTD] PeterN updated pull request #11654: Codechange: Use vector and unique_ptr for nested widget tree.
10:38:13 <DorpsGek> [OpenTTD/OpenTTD] TrueBrain updated pull request #11639: Fix: race-conditions in GUI updates when downloading HTTP files
10:38:33 <belajalilija> xarick: probably like 1250
10:38:46 <xarick> sounds like a good mid range pc for the price
10:39:23 <andythenorth> I haven't bought a PC for about 20 years, we just used to buy the cheapest Dell that had a real CPU, not a Celeron
10:39:31 <andythenorth> usually about ยฃ300
10:39:53 <xarick> I mean, for gaming, it's typical of a mid range
10:40:14 <belajalilija> my friend build a pc for me in 2015 for like ยฃ1500, ive upgraded it since
10:40:27 <xarick> high end is usually > โ‚ฌ1800+
10:40:28 <belajalilija> 128GB of ram now, new motherboard, new cpu
10:40:47 <truebrain> time to check how much peter1138[d] destroyed my GUI patch ๐Ÿ˜› ๐Ÿ˜›
10:40:52 <truebrain> see if I can use the little new tricks ๐Ÿ™‚
10:40:54 <belajalilija> still using a gtx 980
10:41:08 <peter1138[d]> ๐Ÿ˜ฆ
10:41:13 <truebrain> it is a good thing!
10:41:17 <truebrain> my hacks were .. hacky ๐Ÿ™‚
10:41:18 <dwfreed> is it really an upgrade if you've ship of theseus'ed it
10:41:38 <dwfreed> (as far as windows is concerned, the motherboard is the ship)
10:42:24 <belajalilija> dwfreed: dont you mean trigger's broomed it
10:42:27 <truebrain> it is weird .. building with clang is faster, but valgrind doesn't like clangs binaries ๐Ÿ˜ฆ
10:42:44 <peter1138[d]> Odd.
10:43:03 <dwfreed> belajalilija: same thing
10:43:13 <belajalilija> i know, mine is just funnier
10:43:26 <belajalilija> but yeah, ive not had to reinstall windows so in my little mind it is just an upgrade
10:43:40 <peter1138[d]> I gave up with widget factory pattern as MSVC doesn't let me make std::make_unique a friend.
10:43:49 <xarick> also wondering, is it okay to remove orders of disaster vehicles when a station is removed?
10:43:54 <belajalilija> HDD, SSD, power supply, disk drive and gpu are all the same xd
10:44:00 <xarick> what kind of orders do they have, to begin with?
10:44:36 <belajalilija> disk drive is ripped from a windows vista machine :coolgay:
10:47:36 <truebrain> peter1138[d]: hmm, I remember that issue from when I tried to do similar shit
10:47:38 <truebrain> it was annoying ๐Ÿ˜›
10:47:42 <andythenorth> _me doing pointless comparisons of Apple GPUs vs. GeForce 3060"
10:47:48 <peter1138[d]> clang and gcc lets me!
10:47:57 <truebrain> but wasn't there a trick to do it anyway ...
10:48:03 <truebrain> ugh, brain, grey mass, searching ...
10:48:03 <peter1138[d]> I could still do it but without the protected constructor, but.
10:48:40 <truebrain> do you have a diff of what you tried to do? ๐Ÿ˜„
10:49:16 <truebrain> ah, on that PR, found it ๐Ÿ˜›
10:50:05 <truebrain> haha, a few jobs ago, I had to use `::Create()` over a ctor, as you can't template a bloody ctor. Still can't believe you cannot ๐Ÿ˜ฆ
10:51:21 <truebrain> okay, never saw such friend statements before; that looks cute ๐Ÿ™‚
10:52:25 <truebrain> why would you need a friend to access properties of your own class?
10:53:01 <peter1138[d]> std::make_unique is not a member of the class.
10:53:20 <truebrain> for shit and giggles, you can try to build MSVC without the friend statement ๐Ÿ˜›
10:53:52 <peter1138[d]> Yeah... but if it requires compiler specialisation I'm going to do it ๐Ÿ™‚
10:54:04 <truebrain> +not?
10:54:34 <truebrain> ๐Ÿ˜„
10:54:35 <peter1138[d]> Oops.
10:54:53 <peter1138[d]> Anyway, the "solution" is to `std::unique_ptr<T>(new T())` which is... urgh.
10:54:54 <truebrain> from what I remember of make_unique, is that it isn't actually something. It is just a fancy typecast. And I wouldn't be surprised if MSVC sees it as such
10:55:09 <truebrain> wouldn't even surprise me if MSVC implements it as a macro ๐Ÿ˜›
10:55:14 <andythenorth> every single page load on requires cookies to be accepted
10:55:20 * andythenorth me some issues today
10:55:42 <truebrain> anyway, it is what it is peter1138[d] ; we can't have it all! ๐Ÿ™‚
10:56:48 <andythenorth> ok, while I await the next PC-related interruption, what grf thing was I doing?
10:56:54 <andythenorth> Flat Dual-Head Wagons?
10:57:01 <andythenorth> or Dualhead?
10:57:14 <peter1138[d]> The other way is to keep the constructor public but add a private type as an argument, which can only be used within the type.
10:57:41 <DorpsGek> [OpenTTD/OpenTTD] TrueBrain commented on pull request #11654: Codechange: Use vector and unique_ptr for nested widget tree.
10:57:55 <andythenorth> anyone know why most major games are not available on non-Windows platforms?
10:57:58 <truebrain> peter1138[d]: what problem are you trying to solve? (sorry, missed that part ๐Ÿ˜› )
10:58:09 <andythenorth> the games my kids want to play are not available on Steam Deck or Xbox
10:58:20 <DorpsGek> [OpenTTD/OpenTTD] PeterN commented on pull request #11654: Codechange: Use vector and unique_ptr for nested widget tree.
10:58:20 <andythenorth> seems frigging weird TBH
10:58:54 <andythenorth> "don't try Mac gaming" I am used to, but the point of buying Xbox was access to major titles
10:59:35 <peter1138[d]> truebrain: "std::make_unique" everywhere, and also widgets on stack instead of heap.
11:00:07 <peter1138[d]> I thought I'd try it and if it's not too much work, do that. But it turns out it is ๐Ÿ™‚
11:00:11 <truebrain> hihi, happy I am not the only one with a dislike for `std::make_unique` everywhere ๐Ÿ˜›
11:00:55 <peter1138[d]> With the factory pattern I can change the return type of ::Create instead of changing every new NWidget...
11:01:01 <peter1138[d]> But never mind ๐Ÿ™‚
11:01:16 <truebrain> and you want the ctor non-public to avoid people using it, I guess
11:01:18 <truebrain> yeah .. meh
11:01:38 <andythenorth> maybe I should implement my own version of dual-head
11:01:39 <peter1138[d]> Factory pattern without the private constructor is pointless because you then get confused as to which to use.
11:01:49 <truebrain> I agree
11:01:56 <truebrain> something to give a try another day, I would say ๐Ÿ™‚
11:03:01 <peter1138[d]> Yup. It looked neat because I could change to "auto x = NWidgget...::Create()" in one commit, without changing it to unique_ptrs, and then the unique_ptr change is smaller.
11:03:04 <peter1138[d]> But hey
11:03:13 <peter1138[d]> Widgget ๐Ÿ˜„
11:03:31 <DorpsGek> [OpenTTD/OpenTTD] PeterN updated pull request #11654: Codechange: Use vector and unique_ptr for nested widget tree.
11:03:37 <peter1138[d]> That empty destructor now gone ๐Ÿ˜„
11:03:42 <truebrain> \o/
11:03:59 <truebrain> sadly, I can't judge if LordAro's comments are processed, but I couldn't find anything else weird ๐Ÿ™‚
11:06:19 <truebrain> okay .. social integration PR is nearly done. Now I just need to go over the plugins to make their workflows happy .. signing binaries and stuff .. the boring work
11:06:51 <truebrain>
11:06:51 <truebrain> Now also in the survey/crashlog
11:07:07 <truebrain> state number to name you say? Sure!
11:07:17 <andythenorth> that font is awesome
11:08:16 <truebrain> That is because I am awesome!
11:08:33 <DorpsGek> [OpenTTD/OpenTTD] PeterN commented on pull request #11654: Codechange: Use vector and unique_ptr for nested widget tree.
11:08:58 <DorpsGek> [OpenTTD/OpenTTD] PeterN commented on pull request #11654: Codechange: Use vector and unique_ptr for nested widget tree.
11:10:09 <peter1138[d]> Oops, I load the const auto as well.
11:10:13 <peter1138[d]> *lost
11:12:00 <DorpsGek> [OpenTTD/OpenTTD] SamuXarick opened pull request #11661: Fix: When a station is removed, remove orders only from primary vehicles
11:13:10 <DorpsGek> [OpenTTD/OpenTTD] TrueBrain commented on pull request #11628: Feature: Plugin framework for Social Integration with Steam, Discord, GOG, etc
11:15:45 <DorpsGek> [OpenTTD/OpenTTD] TrueBrain commented on pull request #11628: Feature: Plugin framework for Social Integration with Steam, Discord, GOG, etc
11:16:10 <DorpsGek> [OpenTTD/OpenTTD] PeterN updated pull request #11654: Codechange: Use vector and unique_ptr for nested widget tree.
11:16:58 <DorpsGek> [OpenTTD/OpenTTD] PeterN commented on pull request #11654: Codechange: Use vector and unique_ptr for nested widget tree.
11:18:36 <DorpsGek> [OpenTTD/OpenTTD] TrueBrain commented on pull request #11628: Feature: Plugin framework for Social Integration with Steam, Discord, GOG, etc
11:19:07 <truebrain> the endless "const std::string &" vs "std::string_view" ๐Ÿ˜„
11:19:53 <truebrain> `bool Window::SetFocusedWidget(WidgetID): Assertion "widget != nullptr" failed.`
11:19:54 <truebrain> oops? ๐Ÿ˜„
11:20:46 <peter1138[d]> I think string_view is kinda preferable, but... they're not entirely compatible.
11:21:43 <truebrain> hmm ... I click a widget that doesn't exist, it seems
11:22:16 <peter1138[d]> That was what prompted the const WidgetID index.
11:22:57 <peter1138[d]> But still, if you use an index that isn't in widget_lookup it'll fail.
11:23:00 <truebrain> the index is 49, which is higher than there are WID entries ..
11:23:20 <truebrain> ah, no, it is `WID_GO_SOCIAL_PLUGIN_STATE`
11:23:26 <truebrain> which does exist
11:23:35 <peter1138[d]> Previously it would have passed through okay because it's higher, but if it was not higher it would have asserted not nullptr as it does now.
11:24:40 <peter1138[d]> Your FillWidgetLookup only adds WID_GO_SOCIAL_PLUGINS.
11:25:02 <truebrain> owh, my parent call is gone ๐Ÿ˜ฎ
11:25:04 <peter1138[d]> you probably want to call the base FillWidgetLookup()
11:25:19 <truebrain> it used to be there, I swear!
11:25:21 <peter1138[d]> NWidgetVertical::FillWidetLookup()
11:25:24 <truebrain> rebase going wrong ๐Ÿ˜›
11:25:28 <truebrain> tnx ๐Ÿ™‚
11:25:30 <peter1138[d]> Happens ;D
11:25:42 <truebrain> yeah, that is better ๐Ÿ™‚
11:25:50 <peter1138[d]> Technically that's a this-> too, but we kinda forget about that all over the place.
11:25:55 <truebrain> but now the labels are misaligned all of a sudden .. that looks weird .. let's see .. what did I do wrong ...
11:26:20 <truebrain> ah, yes, ofc it doesn't align; it has no reason to align
11:26:44 <truebrain> text-align right should solve that
11:27:19 <truebrain> how do I do that .. eeuuuhhhhhhhh
11:27:23 *** ahyangyi has quit IRC (Quit: User went offline on Discord a while ago)
11:27:30 <peter1138[d]> SetAlignment()
11:27:39 <truebrain> Tnx ๐Ÿ™‚
11:28:31 <truebrain>
11:28:32 <truebrain> much better ๐Ÿ˜„
11:29:32 <truebrain> now to find the development section on our wiki
11:29:38 <truebrain> the main page Development doesn't link (anymore) ๐Ÿ˜›
11:30:19 <truebrain> I sometimes seriously wonder about the quality of our wiki .. nobody seems to be actually maintaining it ๐Ÿ˜ฆ
11:31:41 <truebrain> hmm .. NewGRF, NoAI, NoGo .. and "Social Integration" ..
11:31:45 <truebrain> I am getting old ๐Ÿ˜›
11:36:31 <truebrain>
11:36:31 <truebrain> Best page EVAH
11:37:39 <peter1138[d]> NoLife?
11:37:53 <truebrain> haha
11:37:55 <truebrain> it is not bad ๐Ÿ˜„
11:38:12 <truebrain> oeh, I have an excellent reason not to use string_view
11:38:17 <truebrain> strings need to be nul-terminated
11:39:32 <truebrain> the part where they are slightly different in usage ๐Ÿ˜›
11:40:36 <DorpsGek> [OpenTTD/OpenTTD] TrueBrain commented on pull request #11628: Feature: Plugin framework for Social Integration with Steam, Discord, GOG, etc
11:41:06 <DorpsGek> [OpenTTD/OpenTTD] rubidium42 commented on pull request #11654: Codechange: Use vector and unique_ptr for nested widget tree.
11:41:29 <truebrain> now the only question remaning ... what information to send to the plugin for now. Map-size .. climate .. anything else? ๐Ÿ˜„
11:41:32 <truebrain> well, lunch first, ofc
11:42:54 <xarick> RemoveOrderFromAllVehicles could get a few more information passed to it so that it wouldn't have to iterate all vehicles and their orders... hmm
11:43:57 <xarick> as it stands it's just brute forcing search ๐Ÿ™‚
11:45:14 <peter1138[d]> Oh ffs, I lost more changed than I realised ๐Ÿ˜ฆ
11:50:22 <Rubidium> xarick: there is probably a much better solution to your problem of not iterating all vehicles... consists! Or storing information associated with the whole consist (train, aircraft, etc) like vehicle number/name and its orders, in a separate object. Then you only need to iterate the objects that can actually have orders etc.
11:52:06 <Rubidium> it'll likely work better than trying to cache stuff, as vehicle objects get smaller and thus become friendlier to the (CPU) caches, and when iterating the consists you also get a smaller object improve its (CPU) cache friendliness. And even better, it'll likely save a bit of actual memory use
11:54:25 <Rubidium> truebrain: I wonder if we should call social integration "nosi" ;)
11:54:47 <truebrain> Haha
11:54:49 <xarick> "noplug"
12:01:14 <Rubidium> xarick: what's the play on words with that; I'm not really getting it. Though maybe you missed mine; nosi is a homonyn (in my head) with nosy/nosey
12:01:55 <xarick> I'm trying to figure if I can extrapolate the owner of DestinationID with the type of order given, but airports/hangars are tricky to detect without knowing the vehicle type... I wanted to avoid doing a full vehicle iteration.
12:05:26 <xarick> with the owner, I could limit the search to vehicles of one company
12:05:30 <andythenorth> consists ๐Ÿ™‚
12:05:44 <peter1138[d]> Someoneโ„ข was working on that.
12:06:59 * andythenorth Horse world
12:07:23 <andythenorth> Horse vehicles are Consists, made of units which are Vehicles
12:07:38 <andythenorth> somewhere I got my terminology twisted ๐Ÿ˜›
12:08:19 <andythenorth> eh, some weather here, my windows are rattling
12:08:45 <DorpsGek> [OpenTTD/OpenTTD] rubidium42 commented on pull request #11628: Feature: Plugin framework for Social Integration with Steam, Discord, GOG, etc
12:11:18 <Rubidium> xarick: or maybe you can just pass the vehicle the order is in to the place where you need that information?!? I think you're too focused on one solution, and by that losing significantly better solution
12:16:35 <DorpsGek> [OpenTTD/OpenTTD] TrueBrain updated pull request #11628: Feature: Plugin framework for Social Integration with Steam, Discord, GOG, etc
12:16:52 <truebrain> that PR is now ready for review; I think ๐Ÿ™‚
12:20:49 <xarick> there can be no implicit orders to oil rigs, right?
12:21:21 <peter1138[d]> You never know.
12:22:13 <xarick> right... the future proofing
12:23:51 <peter1138[d]> Urgh, I thought I had a solution using std::reverse, but it turns out if I do that I need to run other loops the other direction instead.
12:25:37 <xarick> oh... buoys
12:25:56 <xarick> i really have to think of all special cases
12:27:21 <DorpsGek> [OpenTTD/OpenTTD] PeterN updated pull request #11654: Codechange: Use vector and unique_ptr for nested widget tree.
12:29:19 <DorpsGek> [OpenTTD/OpenTTD] PeterN commented on pull request #11654: Codechange: Use vector and unique_ptr for nested widget tree.
12:29:50 <DorpsGek> [OpenTTD/OpenTTD] TrueBrain commented on pull request #11661: Fix: When a station is removed, remove orders only from primary vehicles
12:30:30 <DorpsGek> [OpenTTD/OpenTTD] PeterN commented on pull request #11654: Codechange: Use vector and unique_ptr for nested widget tree.
12:33:12 <truebrain> 1 line of code, so many questions
12:33:21 <truebrain> okay ... signing of MacOS binaries
12:33:22 <truebrain> eeeuuuhhh
12:33:27 <truebrain> do I want to do that today? Not sure
12:43:20 <jfs> Rubidium: or just UnSocial
12:44:07 <jfs> instead of a "nosi" pun that might be harder to get
12:47:54 <DorpsGek> [OpenTTD/OpenTTD] nielsmh commented on pull request #11628: Feature: Plugin framework for Social Integration with Steam, Discord, GOG, etc
13:04:02 <truebrain> right, lets see if the same work to create symbols for an executable works for a library ... especially Windows is a bit weird in how to do that ๐Ÿ˜›
13:05:17 <truebrain> it didn't error first-try .. that is at least promising ๐Ÿ™‚
13:05:41 <_glx_> when building a dll it should provide the pdb too
13:05:47 <truebrain> it does
13:05:50 <truebrain> but Windows is just weird
13:05:58 <truebrain> you also need to store the executable
13:06:00 <truebrain> as only platform
13:06:03 <truebrain> in a weird folder ..
13:06:27 <_glx_> ah yes of course, but it follows the same rules as exe
13:06:28 <truebrain> and sometimes it is openttd.exe, sometimes openttd.sym
13:06:30 <truebrain> it is .. weird
13:07:21 <truebrain> it seems to work .. shocking
13:07:28 <truebrain> now just, do I push these to GitHub or not ..
13:07:44 <truebrain> guess that is completely unneeded given they will end up on the symbol server
13:08:13 <_glx_> now need with symbol server
13:08:50 <truebrain> do I need to sign the DLL, I wonder
13:08:55 <truebrain> it seems to work fine without signing
13:08:58 <truebrain> but .. it might help?
13:08:58 <_glx_> probably
13:09:21 <truebrain> signing on Windows is not the easiest
13:09:26 <truebrain> and it does expire in a few months ๐Ÿ˜›
13:09:30 <truebrain> orudge: any updates on that front?
13:09:58 <_glx_> signing on macos seems worse
13:10:14 <truebrain> on Windows I need to make CMake changes too
13:10:18 <truebrain> on Mac at least it is all in the workflow
13:10:33 <truebrain> on Windows we have an `os/windows/sign.bat`
13:11:05 <truebrain> I wonder on Mac if I can just start signing another binary .. or if you need to do something first before you can
13:12:07 <truebrain> owh, for Mac we only sign the dmg
13:12:16 <truebrain> I doubt I can just sign a dylib in the same way
13:13:28 <truebrain> owh, I can just sign it; and not notarize, it seems
13:17:16 <truebrain> seems we need to add "Allow Unsigned Executable Memory Entitlement"
13:17:21 <truebrain> before MacOS can load a plugin
13:17:56 <truebrain> ah, no, the text was only misleading
13:18:54 *** gelignite has joined #openttd
13:19:09 <andythenorth> lol my BaseException failed because I am trying to concatenate None with string
13:19:15 <andythenorth> errors in the error catcher ๐Ÿ˜ฆ
13:19:26 <truebrain> poor exception
13:19:31 <truebrain> part of inception now
13:19:55 <xarick> oh ๐Ÿ˜ฆ
13:20:11 <xarick> station, waypoint, depot
13:20:16 <xarick> airport replacement
13:20:25 <xarick> it would alongate the commit message ๐Ÿ˜
13:20:58 <andythenorth> oops, subclass instantation works better if I don't omit **kwargs from `super().__init__()`
13:21:05 <andythenorth> silly errors ๐Ÿ˜„
13:21:39 <truebrain> okay, I just don't understand how MacOS wants us to notarize these dylibs ๐Ÿ˜›
13:21:42 <truebrain> or if we even have to
13:21:49 <truebrain> they are not part of a bundle
13:21:55 <truebrain> which seems to make MacOS a bit unhappy
13:21:58 <truebrain> I can understand that, tbh ๐Ÿ˜›
13:22:25 <andythenorth> oof can I help? rubber duck?
13:22:41 <truebrain> it is just all a bit unclear
13:22:47 <truebrain> it might be sufficient if we just sign it .. I dunno
13:23:39 <xarick> gotta stop using adjectives, adverbs
13:24:16 <truebrain> `This security-hardening feature prevents a program from loading frameworks, plug-ins, or libraries unless theyโ€™re either signed by Apple or signed with the same Team ID as the main executable.`
13:24:19 <truebrain> okay, that at least is promising
13:24:27 <truebrain> just the library will not be part of the notarization
13:24:35 <truebrain> so I am unsure what Gatekeeper is going to think of it
13:26:19 <truebrain> I also wonder if we should sign the SteamSDK .. as I am guessing that would be an issue too ..
13:26:27 <truebrain> owh well, I guess the only way we are going to find out, is by trying it ๐Ÿ˜›
13:26:42 <andythenorth> ๐Ÿ™‚
13:28:23 <truebrain> which requires me to make a binary of this PR that is signed .. just to see what happens when you try to load a library that way .. meh
13:28:25 <truebrain> for another day ๐Ÿ™‚
13:37:28 <xarick> there are more orders than vehicles.
13:38:02 <xarick> i remember my AIs reaching the order limit once, it was fixed by expanding the pool of orders
13:38:08 <xarick> so that I am sure
13:39:55 <xarick> also buoys....
13:42:26 <xarick> buoys eat stations and orders
13:44:52 <georgevb> Not sure is it a right place to ask, but a question about Bananas
13:45:03 <georgevb> I get {'regions': ['Longer than maximum length 10.']} error
13:45:38 <georgevb> But xUSSR is related to more that 10 regions now
13:45:59 <georgevb> Can this limit be raisen to 20?
13:49:13 <andythenorth> do we prefer ``` if len(self.units) > 1:
13:49:13 <andythenorth> return True
13:49:13 <andythenorth> elif self.is_randomised_wagon_type or self.is_caboose:
13:49:13 <andythenorth> return True
13:49:13 <andythenorth> else:
13:49:14 <andythenorth> return False
13:49:36 <andythenorth> or ```if len(self.units) > 1:
13:49:36 <andythenorth> return True
13:49:36 <andythenorth> if self.is_randomised_wagon_type or self.is_caboose:
13:49:36 <andythenorth> return True
13:49:36 <andythenorth> return False
13:50:04 <andythenorth> I prefer the second, but I suspect I'm wrong
13:54:44 <truebrain> georgevb: Not really. It is better to pick the region above the one you are picking in those cases
13:55:41 <Eddi|zuHause> no UI list should have more than 7 entries
13:57:06 <_jgr_> I think that ship sailed long ago ๐Ÿ˜›
13:58:25 <georgevb> USSR consisted of 15 republics, I can't change that
13:58:25 <georgevb>
13:59:40 <georgevb> truebrain: How can I choose 10 of them?
14:00:24 <truebrain> that is an ethical debate I leave up to you. My suggestion is to pick an overarching region instead. But that is a choice you have to make
14:00:59 <truebrain> sadly, in any system, there is always a limit, and one someone always reaches
14:02:11 <DorpsGek> [OpenTTD/OpenTTD] SamuXarick updated pull request #11661: Change: Only remove orders from primary vehicles
14:02:39 <rau117> truebrain: Is the limit of 10 really that important? Can it be increased to let's say 16, not 20.
14:02:39 <rau117> *Increasing virtual limit a little easier than choosing โ€œwho is worthy of mentionโ€*
14:03:01 <truebrain> Pick any limit, and someone will be: can it be a bit higher pretty please?
14:03:15 <truebrain> for all kinds of technical reasons, this limit is set to 10
14:03:17 <truebrain> sadly, that is it
14:03:43 <DorpsGek> [OpenTTD/OpenTTD] PeterN opened pull request #11662: Change: Don't allow station/roadstop/object picker text to extend width.
14:10:06 <DorpsGek> [OpenTTD/OpenTTD] SamuXarick commented on pull request #11661: Change: Only remove orders from primary vehicles
14:12:24 <andythenorth> did we give trains permanent storage yet?
14:23:40 <Rubidium> rau117: I think 10 is already quite a big number of regions; if it's really that many regions, isn't there some overarching region? Take the TRAXX, should I list all 14 countries? Or is Europe, Middle East, South Africa also a reasonable set of regions? It's about giving an idea where the vehicle's used.
14:26:04 <Rubidium> and yes, I know it's using a current list of countries/regions, so it's missing countries that existed in the past, but also countries that'll exist in the future. The regions, on the other hand, are less likely to change over time
14:27:13 <locosage> andythenorth: nope, last time I though about it I came to a conclusion that it would require changing how persistent storage works a bit
14:28:57 <locosage> because using current persistent storage is a huge waste of memory and adding another way to do the storage isn't great in general
14:36:15 <peter1138[d]> 1KiB per vehicle is a lot.
14:36:34 <peter1138[d]> You could got 16 slots so it's only 64 byte per vehicle, but then someone would say 16 isn't enough.
14:37:30 <andythenorth> whatever use case I have for it right now, it's probably wrong ๐Ÿ˜›
14:37:47 <andythenorth> something to do with powered wagons, dual head, and changing power by railtype
14:37:54 <andythenorth> BAD FEATURE ^ 2
14:41:02 <xarick> question, do Implicit orders show up in the OrderList?
14:41:13 <peter1138[d]> Yes.
14:41:23 <locosage> technically, persistent array pretty much never changes size after initialization
14:41:31 <xarick> okay, that sure helps things
14:41:32 <locosage> only if there was an easy way to know what that size is
14:41:47 <locosage> by size I mean max used index
14:43:16 <locosage> simplest way would be to just add action0 property that lets grf just tell what size it needs
14:43:37 <locosage> and if it exceeds it game can just reallocate
14:44:20 <locosage> but it's probably possible to figure it out with static analysis too
14:44:50 <locosage> _jgr_: did you do some persistent array size optimizations in your branch by any chance?
14:47:03 <locosage> peter1138[d]: as a temporary solution it's pretty viable actually
14:47:49 <locosage> if someone makes a better array size management later there won't be any spec changes
14:50:19 <peter1138[d]> How much persistent storage does one need, anyway...
14:50:55 <locosage> the more the merrier xD
14:51:01 <peter1138[d]> Oh you know what.
14:51:10 <locosage> very much depends on what you're trying to do with it
14:51:14 <peter1138[d]> When I wrote my persistent storage patch, it just uses a pointer.
14:51:26 <peter1138[d]> So if the vehicle doesn't use storage, it doesn't waste space on it.
14:54:13 <_jgr_> locosage: Nothing significant, that I can remember. I can have a look later
14:56:59 *** keikoz has quit IRC ()
15:00:58 <locosage> on a totally unrelated note I just realized tree shading would need to allow newgrfs to provide their own recolours
15:01:20 <locosage> because what's barely visible in opengfx makes u&ratt trees totally black
15:01:36 <locosage> one more use for luts ;)
15:01:50 <peter1138[d]> Trees are not on the ground surface anyway, so don't need to be shaded with the ground.
15:02:39 <_zephyris> ... And newgrfs can reserve sprites for use as recolour sprites.
15:02:46 <locosage> yeah, ideally tree shading would need to be more smart than just shading as ground
15:07:05 <_zephyris> Arguably it should darken based on local tree density...
15:10:03 <locosage> it's some combination of nearby slopes and trees
15:13:12 <DorpsGek> [OpenTTD/OpenTTD] rubidium42 commented on pull request #11662: Change: Don't allow station/roadstop/object picker text to extend width.
15:16:30 <_jgr_> Using the palette for tree shading makes the shading too strong
15:17:20 <DorpsGek> [OpenTTD/OpenTTD] rubidium42 approved pull request #11656: Fix #11337: Station blocked/pylon/wire bits with CBID_STATION_TILE_LAYOUT
15:17:35 <_jgr_> It's more pragmatic to do it in 32bpp space
15:18:56 <DorpsGek> [OpenTTD/OpenTTD] 2TallTyler commented on pull request #11662: Change: Don't allow station/roadstop/object picker text to extend width.
15:22:20 <xarick> this looks confusing. I wonder if it's correct. `id | (INVALID_VEH_ORDER_ID << 8)` is the same as `(INVALID_VEH_ORDER_ID << 8) | id`. The other side decouples the data as: `from = GB(data, 0, 8); to = GB(data, 8, 8);`. It's passing the same value on both lines. Is someone playing tricks?
15:25:30 <locosage> _jgr_: depends on your recolour sprites
15:29:06 <DorpsGek> [OpenTTD/OpenTTD] rubidium42 approved pull request #11654: Codechange: Use vector and unique_ptr for nested widget tree.
15:29:53 <Rubidium> xarick: that indeed looks a bit duplicate
15:30:46 <xarick> I tried to follow it
15:31:31 <xarick> looks like it doesn't need the repetition
15:31:37 <xarick> unsure yet
15:33:24 <xarick> if the order is highlighted (selected), the first passage removes the selection and the second passage does nothing
15:33:43 <xarick> vscroll is updated also on the first passage
15:33:51 <xarick> unless timetable requires it
15:33:57 <xarick> let me check timetable gui
15:34:00 <DorpsGek> [OpenTTD/OpenTTD] PeterN merged pull request #11654: Codechange: Use vector and unique_ptr for nested widget tree.
15:34:47 <peter1138[d]>
15:34:47 <peter1138[d]> Scrollbar-as-container not going so well ๐Ÿ˜„
15:35:20 <truebrain> details details
15:36:11 <xarick> wow, looks like it has depth
15:37:05 *** keikoz has joined #openttd
15:39:56 <peter1138[d]> Aww, disappointingly it works now.
15:40:32 <peter1138[d]> Of course this does not fix everything to use GetParentWidget().
15:41:03 <peter1138[d]> Although I do wonder if the approach should be slightly different.
15:42:34 <Rubidium> xarick: it definitely smells, but I'm not sure whether one of the lines should be removed or the second line should be `INVALID_VEH_ORDER_ID | (id << 8)`
15:42:42 <peter1138[d]> This won't support both horizontal and vertical scrollbars -- one will be a child of the other and then you get scrolling issues, probably.
15:43:16 <peter1138[d]> And if it's some grid layout then they aren't parent widgets any more. Hmm.
15:43:31 <peter1138[d]> GetSiblingWidget? ๐Ÿ˜ฎ
15:45:19 <peter1138[d]>
15:45:19 <peter1138[d]> fun
15:45:27 <peter1138[d]> (Yes, the unit tests fail)
15:47:12 <truebrain> does feel like an improvement ๐Ÿ˜›
15:47:36 <DorpsGek> [OpenTTD/OpenTTD] PeterN merged pull request #11660: Fix: Calculation of initial engine age was inaccurate.
15:48:38 <peter1138[d]> I wonder if instead of scrollbar widgets, I should make a scrollable-container, and that has both vertical and horizontal scrollbars depending on the content.
15:49:08 <peter1138[d]> Might even work.
15:56:37 <xarick>
15:56:40 <DorpsGek> [OpenTTD/OpenTTD] 2TallTyler commented on pull request #11656: Fix #11337: Station blocked/pylon/wire bits with CBID_STATION_TILE_LAYOUT
15:57:06 *** Wormnest has joined #openttd
16:11:48 <xarick> OrderList might be a good solution ๐Ÿ™‚
16:12:17 <xarick> no need for my cache
16:12:27 <xarick> ` for (const OrderList *order_list : OrderList::Iterate()) {
16:12:27 <xarick> for (Vehicle *v = order_list->GetFirstSharedVehicle(); v != nullptr; v = v->NextShared()) {`
16:13:04 <xarick> and the rest is the same code
16:13:28 <xarick> there are less orderlists than there are vehicles
16:14:07 <xarick> OrderList vs Order
16:14:50 <xarick> vehicles without orders have no orderlist
16:14:58 <xarick> less stuff to iterate
16:16:26 <DorpsGek> [OpenTTD/OpenTTD] PeterN commented on pull request #11662: Change: Don't allow station/roadstop/object picker text to extend width.
16:16:59 <xarick> now all I need is to TICC/TOCC this to see if there are gainz
16:17:58 <DorpsGek> [OpenTTD/OpenTTD] PeterN updated pull request #11662: Change: Don't allow station/roadstop/object picker text to extend width.
16:19:46 <xarick> the function could be renamed...
16:20:10 <xarick> RemoveOrderFromAllOrderLists, hueehehe
16:20:11 <DorpsGek> [OpenTTD/OpenTTD] PeterN commented on pull request #11656: Fix #11337: Station blocked/pylon/wire bits with CBID_STATION_TILE_LAYOUT
16:23:58 <DorpsGek> [OpenTTD/OpenTTD] PeterN commented on pull request #11662: Change: Don't allow station/roadstop/object picker text to extend width.
16:28:09 <DorpsGek> [OpenTTD/OpenTTD] 2TallTyler commented on pull request #11662: Change: Don't allow station/roadstop/object picker text to extend width.
16:28:54 <talltyler> Alternatively, we could make the maximum class name string shorter and force NewGRF authors to use shorter namesโ€ฆbut that would never work. ๐Ÿ˜›
16:31:26 <merni> The truncation should be fine if the full thing is displayed somewhere else
16:31:37 <merni> that's why I suggested window title
16:35:28 <merni> Forcing authors to use shorter names would have been nice but now there are already so many GRFs around that don't, and forcibly cutting them off would mean loss of potentially important info
16:38:42 <peter1138[d]> Authors can update their grfs.
16:39:40 <merni> There are plenty of unmaintained grfs though
16:40:04 <DorpsGek> [OpenTTD/OpenTTD] merni-ns commented on pull request #11662: Change: Don't allow station/roadstop/object picker text to extend width.
16:41:50 <peter1138[d]>
16:41:58 <peter1138[d]> (Ignore the dodgy widget to the right :))
16:42:34 <peter1138[d]> But I wonder if we should start segmenting the window panels.
16:43:11 <peter1138[d]>
16:43:11 <peter1138[d]> Kinda like we do for the waypoint window, although there's a lot less on there.
16:43:39 <andythenorth> Segmented Variants?
16:44:15 <merni> peter1138[d]: I continue to think that this makes the class list unnecessarily prominent
16:44:34 <peter1138[d]> Same.
16:45:19 <peter1138[d]> Hmm, and the search is useless as andythenorth always says ๐Ÿ˜„
16:45:28 <peter1138[d]> Maybe I should dig out another old patch and combine them.
16:45:45 <merni> improving the search sounds like another PR
16:45:50 <peter1138[d]> Sure.
16:46:14 <peter1138[d]> Okay... how about doing what I originally did -- make the full class name appear as a tooltip.
16:46:21 <merni> is the problem that the search only covers station classes and not individual stations?
16:46:31 <peter1138[d]> So it's there when you are looking for it, but otherwise not prominent.
16:46:36 <merni> peter1138[d]: Hm yeah that makes sense
16:46:45 <peter1138[d]> Yes. I have a patch that searches names instead.
16:46:50 <DorpsGek> [OpenTTD/OpenTTD] glx22 opened pull request #11663: Add: [Script] Optional filter parameter to ScriptVehicleList constructor
16:46:58 <peter1138[d]> A bit like the waypoint window.
16:47:00 <merni> "instead" or "also"? Both would be very nice
16:47:02 <peter1138[d]> But that doesn't have classes at all.
16:47:14 <peter1138[d]> Can't remember ๐Ÿ˜„
16:47:36 <merni> Either would be an improvement from the present
16:47:38 <peter1138[d]> Waypoint window is funny, authors never bothered to name their waypoints.
16:47:45 <locosage> thanks, chatgpt...
16:47:45 <locosage> # Perform slicing operation
16:47:45 <locosage> sliced_data = original_data[:, :, :3]
16:47:45 <locosage> # Reconstruct the original data in the same memory location
16:47:45 <locosage> original_data[:, :, :3] = sliced_data```
16:47:49 <peter1138[d]> *some
16:48:09 <merni> Some station sets also do that and have all their stations as "Default station"
16:48:20 <merni> or maybe the version of the Hungarian set I'm using is buggy idk
16:48:41 <merni> But seems to be much more ocmmon with waypoints yeah
16:48:50 <peter1138[d]> At least one set is VERY SHOUTY.
16:54:26 <peter1138[d]>
16:55:40 <talltyler> I donโ€™t think thatโ€™s a satisfactory solution
16:55:55 <talltyler> At least not by itself
16:57:11 <talltyler> I think changing the filter to filter station names instead of class names could make the class names less relevant, but currently the class name is a primary way of finding what you want
16:58:54 <talltyler> I dunno, this and the object gui are really tricky. On the multiplayer games I play on, the object class list is so long that the scrollbar handle is too small to click ๐Ÿซฃ
16:59:30 <merni> that is a regular problem with the vehicle purchase list for me
16:59:38 <merni> but at least that has effective search
17:00:33 <peter1138[d]>
17:00:33 <peter1138[d]> Such old interface
17:00:38 <talltyler> Actually, what if we had nested (collapsible) class lists? So much Auz stuff is fake-nested already, although Iโ€™m unclear if upping the object-per-GRF limit will change that pattern
17:00:44 <rau117> peter1138[d]: Hmmโ€ฆ How about providing the ability to separate names? One shortened for the list (possibly even with a hard-coded limit), and the second full, for tooltip, and make the filter work for both.
17:01:08 <peter1138[d]> No because that doesn't help already existing NewGRFs.
17:01:54 <rau117> It will not affect existing ones, but will provide an opportunity for new.
17:02:17 <merni> talltyler: Could that be done as one "folder" per GRF? I guess different GRFs can put things into the same class code...
17:02:50 <peter1138[d]> Doesn't help with the width.
17:03:05 <merni> Also, Auz objects are fake nested; I haven't seen that for stations or maybe I don't have the latest version
17:03:16 <merni> peter1138[d]: yep
17:03:30 <merni> For the width I personally think either tooltip or window title are the best options
17:04:01 <talltyler> True, that would only solve heightโ€ฆ got distracted by a different problem ๐Ÿ˜›
17:04:24 <merni> Unless making both the class list and the preview list expand when widening the window is possible...
17:04:53 <rau117> peter1138[d]: Does the design mean that the list of stations will always be in this form, or will it expand as with the newgrf window?
17:07:58 <DorpsGek> [OpenTTD/OpenTTD] SamuXarick updated pull request #11661: Change: Only remove orders from primary vehicles
17:08:05 <peter1138[d]> Two layouts and a size-toggle button, let the player decide ๐Ÿ˜ฎ
17:08:44 <rau117>
17:08:44 <rau117> peter1138[d]: This one? Eh, I just wanted to suggest (=
17:08:51 <andythenorth> Variant Tree ๐Ÿ˜›
17:09:08 <merni> no variants here
17:09:09 <peter1138[d]> Maintaining two widget layouts for each window would be a pain.
17:09:32 <talltyler> What if we:
17:09:32 <talltyler> 1. Improved the filter to filter station names instead of class names
17:09:32 <talltyler> 2. Changed the class list to a dropdown, spanning the entire window width but only taking up one line height when closed. Basically, like the cargo filter in the vehicle buy menu.
17:10:03 <merni> I feel like the height isn't the problem that's trying to be solved here but the width
17:10:10 <talltyler> Both are a problem
17:10:20 <merni> emphasis on "here"
17:10:47 <talltyler> But spanning the class list across the window makes it too tall, so if you make it shorter it might work there
17:11:09 <merni> the dropdown when opened might become too tall and need its own scrollbar
17:11:17 <peter1138[d]> Station class icons?!
17:11:23 <peter1138[d]> (Nope)
17:11:29 <merni> or otherwise block big parts of the screen
17:11:38 <talltyler> peter1138[d]: This, but with a Class: [class name] dropdown instead of the whole list
17:11:56 <talltyler> The dropdown would get a scrollbar, but dropdowns already do that
17:12:01 <peter1138[d]> That's already a feature of dropdowns, yeah.
17:12:09 <peter1138[d]> And they disappear when you select.
17:12:32 <peter1138[d]> Okay, so... undo years-old change from dropdown to matrix. I wonder if I can svn-revert that ๐Ÿ˜‰
17:12:58 <merni> but how big do they get before they get a scrollbar? do they try to stretch to the bottom of the screen?
17:13:01 <talltyler> Matrix, thatโ€™s what the list is called? (Takes notes as Iโ€™m still learning our widget system ๐Ÿ™‚ )
17:13:22 <peter1138[d]> It's a WWT_MATRIX.
17:13:26 <merni> And there are two different kinds of matrix which are different :pain:
17:13:29 <peter1138[d]> Not to be confused with an NWID_MATRIX.
17:13:32 <rau117> It seems to me that the dropdown list will be super-inconvenient if the set of stations contains many categories. To switch, you will need to not just click on pre-existing list, but open the dropdown list and find something inside it.
17:13:45 <rau117> talltyler: โ†‘โ†‘
17:13:58 <merni> Yes, dropdown feels like a step back in terms of usability to me
17:14:20 <merni> to browse through station classes you need to click twice each time you change class instead of once
17:15:06 <talltyler> I think improving the filter is a key part of that, but yes โ€” I think the proposed change would make it easier to find what youโ€™re looking for and harder to just browse everything available
17:15:17 <talltyler> That said, the default dropdown could be All
17:15:33 <talltyler> So you would see everything available, like scrolling through the waypoint picker
17:15:59 <DorpsGek> [OpenTTD/OpenTTD] PeterN updated pull request #11662: Change: Don't allow station/roadstop/object picker text to extend width.
17:16:07 <merni> talltyler: Improving the filter and dropdown-ifying the class list are independent, though
17:16:11 <andythenorth> I never enjoy switching category
17:16:17 <peter1138[d]> Well, I'm leaving it as that because everyone has opinions, and frankly I can't be arsed.
17:16:21 <merni> you can make it easier to find what you're looking for *and* not harder to browse
17:16:45 <andythenorth> Hmm filters? ๐Ÿ™‚
17:17:09 <talltyler> But I want a blue bikeshed, why wonโ€™t you paint it for me? ๐Ÿ˜›
17:18:26 <talltyler> I am not tied to a dropdown, I just donโ€™t see a better way to see the whole class name without taking up a ton of space
17:18:35 <peter1138[d]> Separate windows.
17:18:40 <peter1138[d]> Station builder.
17:18:43 <peter1138[d]> Station class window
17:18:43 <talltyler> I am intrigued ๐Ÿ™‚
17:18:52 <peter1138[d]> Station preview window.
17:19:07 <peter1138[d]> Resize however you want.
17:19:15 <peter1138[d]> Hide/keep open however you want.
17:19:35 <peter1138[d]> Also probably awkward to code, but they.
17:19:35 <merni> that feels kinda complicated to use
17:20:07 <merni> whose idea was it to give newgrf authors strings of unlimited length :p
17:20:08 <peter1138[d]> Then you need window-glueing so you can treat it as one window like now. FML.
17:20:23 <peter1138[d]> It was meant to be just the width of the widget.
17:20:30 <peter1138[d]> Then we made widgets resize to fit text.
17:21:03 <talltyler> I like the idea, although it sounds like youโ€™ve found a big rabbithole for yourself to actually implement it ๐Ÿ˜›
17:21:15 <rau117> peter1138[d]: But still, what about this? Combined with the current design and resize button, this looks like the most compromise solution.
17:21:15 <rau117> And if this will be more familiar and/or convenient for players, but painful for developers... maybe it's worth going through with that pain.
17:22:03 <peter1138[d]> Wow
17:22:48 <talltyler> We could just {TINYFONT} the class name to squeeze it all in ๐Ÿ˜›
17:22:51 <truebrain> merni: Because if you give less they will ask for more. See earlier today ๐Ÿ˜›
17:23:27 <peter1138[d]> `font small "OpenTTD-Sans.ttf" 20` sucks to be a UI designer.
17:23:34 <merni> rau117: Both this option and the one proposed in the PR seem equally "familiar", and the convenience is debatable -- either you want to see the entire class name on the screen or you want to see more station previews
17:24:13 <rau117>
17:24:13 <rau117> talltyler: well, it can be not so tiny as expectedโ€ฆ
17:24:13 <rau117> please don't lock small font size to 8 (=
17:24:34 <talltyler> merni: This you? ๐Ÿ˜› ๐Ÿ˜›
17:24:34 <talltyler>
17:24:41 <peter1138[d]> See, they ruin the UI by using bad font sizes... ๐Ÿ˜‰
17:24:43 <merni> truebrain: It was mostly joking lol, especially with different languages a hard length limit woul be most problematic
17:25:11 <truebrain> Pretty sure I wasn't serious either ๐Ÿ™‚
17:25:12 <merni> talltyler: The problem there is GRF authors have unlimited strings but players can't edit those without losing most of them
17:25:20 <peter1138[d]> small font size is 6 anyway. so no need to lock it to 8.
17:25:26 <talltyler> Oh I know, Iโ€™m joking
17:25:55 <LordAro> peter1138[d]: can the item list have tooltips?
17:26:09 <peter1138[d]> Which item list?
17:26:11 <merni> peter1138[d]: LordAro: yes
17:26:21 <LordAro> the list of item classes
17:26:28 <merni> peter already shared a screenshot with that :)
17:26:31 <peter1138[d]> Oh. Yes.
17:26:43 <LordAro> so you did
17:27:18 <LordAro> seems a reasonable solution to me
17:27:28 <LordAro> it'd be nice if both parts of the window resized, but...
17:28:26 <merni> well, also with that the preview list can only be widened in discrete amounts (the size of one square) but the class list can be resized continuously
17:28:51 <merni> so how would it decide to resize the preview list? or is that already handled somehow?
17:30:02 <rau117>
17:30:02 <rau117> peter1138[d]: maybe I just have bad eyesightโ€ฆ
17:30:02 <rau117> *(yes, yes, it looks much better on sprite font)*
17:30:38 <peter1138[d]> I just can't imagine what the Interface Scale slider is fot...
17:31:03 <peter1138[d]> Now we've moved on from "you're playing the game wrong" to "you're scaling the game wrong" ๐Ÿ˜„
17:31:21 <alfagamma7> I always forget that you can now fiddle with the config files via the in game console
17:31:25 <alfagamma7> Oof
17:31:34 <truebrain> "Now"?
17:31:35 <alfagamma7> I use 14
17:31:35 <merni> The font command was always a thing, I think?
17:31:48 <truebrain> 15 years still classifies as "now" .. jnteresting
17:31:53 <alfagamma7> Ah yes
17:32:05 <alfagamma7> Just plain ignorance then
17:32:10 <truebrain> ๐Ÿ˜„
17:32:15 <truebrain> New for you ๐Ÿ˜‰
17:32:21 <alfagamma7> True
17:32:46 <locosage> font command is like 13.0 or smth
17:32:50 <peter1138[d]> Window layouts look so bad at 1x interface face but larger fonts.
17:32:54 <truebrain> I don't like the colour of your names btw .. totally unrelated
17:33:12 <truebrain> You look grey-out
17:33:26 <alfagamma7> Ask Kale for that
17:33:33 <rau117> peter1138[d]: This is 1x, *purely for example.*
17:33:33 <rau117> I usually play on x1.25 - perfect ratio, the font does not become bold, and the buttons become acceptable small
17:33:34 <alfagamma7> He made the new roles
17:34:08 <DorpsGek> [OpenTTD/OpenTTD] 2TallTyler commented on pull request #11663: Add: [Script] Optional filter parameter to ScriptVehicleList constructor
17:34:14 <alfagamma7> I am using zeph's ttf files now which are great
17:34:25 <merni> I don't actually play on the jgr server so I theoretically don't need to be grey but I like looking at the nice things people are doing there :)
17:34:44 <truebrain> Moderator! We have a spy! ๐Ÿ˜›
17:35:20 <alfagamma7> Literally 80% of people with the jgr server roles just do that
17:35:23 <alfagamma7> Like me
17:35:43 <alfagamma7> I occasionally log in as spectator on the servers
17:36:45 <truebrain> More spies .. the servers are full of them it seems!
17:37:03 <truebrain> I am going to file a complaint, like a true Karen that I am
17:37:14 <alfagamma7> Yeah, right.....
17:37:18 <merni> TrueKaren
17:38:53 <talltyler> Wait until you find out that I know nothing about the screenshot competition but Olionkey wanted my name to be green ๐Ÿ˜›
17:40:33 <Rubidium> could be my eyes, but you all look gray to me...
17:40:57 <merni> That's what you get for using a better chat platform :p
17:41:09 <truebrain> Rubidium: And you sound like a bot to me ๐Ÿ˜›
17:41:14 <alfagamma7> Meh IRC is good
17:41:24 <locosage> 2CC for discord names when?
17:42:31 <alfagamma7> OpenTTD should package the ttf files made by zeph as default from 14.0
17:42:33 <Rubidium> truebrain: I am occasionally considered be a bit bot ;D
17:42:50 <truebrain> Aren't all Dutch people? ๐Ÿ˜›
17:47:52 <xarick>
17:47:52 <xarick> Top left - master
17:47:52 <xarick> Top right - group vehicle list
17:47:52 <xarick> Bottom left - PR 11661 - IsPrimaryVehicle
17:47:52 <xarick> Bottom right - OrderList
17:48:13 <xarick> I am astounded IsPrimaryVehicle turned to be bad
17:49:17 <rau117> *hmmm... is it possible to make some kind of interface for the wallpaper engine?*
17:49:41 <truebrain> xarick: That kinda happens when you are looking for a problem, instead of solving actual problems ๐Ÿ˜‰
17:50:23 <truebrain> There is nothing broken with that function, and it is not used enough to form performance issues. So leaving it alone is often the best choice
17:51:58 <DorpsGek> [OpenTTD/OpenTTD] SamuXarick closed pull request #11661: Change: Only remove orders from primary vehicles
17:53:34 <merni> rau117: What's a wallpaper engine?
17:53:50 <DorpsGek> [OpenTTD/OpenTTD] glx22 opened pull request #11664: Fix: Missing invalidations on gui.ai_developer_tools change
17:55:08 <alfagamma7> merni: The background thing
17:55:30 <merni> You mean the title screen?
17:55:38 <merni> That game isn't meant to be played :p
17:57:25 <xarick> OrderList looks to be slightly, just slightly faster than master
17:57:33 <xarick> but I guess it doesn't matter much
18:01:33 <DorpsGek> [OpenTTD/OpenTTD] glx22 commented on pull request #11663: Add: [Script] Optional filter parameter to ScriptVehicleList constructor
18:01:58 <DorpsGek> [OpenTTD/OpenTTD] glx22 updated pull request #11663: Add: [Script] Optional filter parameter to ScriptVehicleList constructor
18:10:00 <DorpsGek> [OpenTTD/OpenTTD] SamuXarick commented on pull request #11661: Change: Only remove orders from primary vehicles
18:22:56 <peter1138[d]> Well.
18:25:17 <merni> It's full of water
18:33:42 <alfagamma7> Happy New Year from India, folks
18:38:25 <DorpsGek> [OpenTTD/OpenTTD] eints-sync[bot] pushed 1 commits to master
18:38:26 <DorpsGek> - Update: Translations from eints (by translators)
18:41:11 <peter1138[d]>
18:41:11 <peter1138[d]> lol
18:42:03 <LordAro> i mean, could be worse
18:42:57 <locosage> that's actualy a good direction to go imo
18:43:09 <locosage> separate the whole visuals selection from station size
18:43:36 <peter1138[d]> Preview side still to be split.
18:43:46 <peter1138[d]> But this is a "mock up", as in, working code...
18:44:04 <locosage> make main window small and flat and only open type selection when needed
18:44:37 <peter1138[d]> Main builder window becomes basically the non-newstations version.
18:45:17 <peter1138[d]> And the preview window becomes basically the waypoint window.
18:45:35 <peter1138[d]> If I was clever I'd make it use the same code.
18:46:28 <peter1138[d]> And then do it all over again for the roadstop and object GUIs.
18:46:48 <peter1138[d]> Not sure I can genericise this :/
18:47:25 <peter1138[d]> Actually I'm sure I can.
18:47:42 <locosage>
18:47:42 <locosage> smth like this
18:47:44 <peter1138[d]> The class window is basically like a dropdown but persistent.
18:48:03 <peter1138[d]> Heresy
18:48:58 <andythenorth> can we have multiple instances of the window? ๐Ÿ˜›
18:49:15 <andythenorth> like depots buy menus ๐Ÿ˜›
18:49:55 *** Flygon has quit IRC (Remote host closed the connection)
18:56:40 <xarick> hmm, buoys aren't deleted anymore when a company bankrupts?
18:57:07 <xarick> was is always like that? I forgot
18:58:15 <xarick> I remember something about it. If the buoy is no longer in use after a bankrupt, it would get removed.
18:59:47 <DorpsGek> [OpenTTD/OpenTTD] rubidium42 approved pull request #11664: Fix: Missing invalidations on gui.ai_developer_tools change
19:01:43 <DorpsGek> [OpenTTD/OpenTTD] rubidium42 approved pull request #11663: Add: [Script] Optional filter parameter to ScriptVehicleList constructor
19:16:56 <DorpsGek> [OpenTTD/OpenTTD] georgeabr opened pull request #11665: Update romanian.txt - fix spelling and correct word form.
19:20:41 <DorpsGek> [OpenTTD/OpenTTD] georgeabr opened issue #11666: [Bug]: Fix Romanian translation of some strings/words
19:28:26 <truebrain> Bugs after the solution; that is new ๐Ÿ˜„
19:30:01 <DorpsGek> [OpenTTD/OpenTTD] nielsmh closed issue #11666: [Bug]: Fix Romanian translation of some strings/words
19:30:04 <DorpsGek> [OpenTTD/OpenTTD] nielsmh commented on issue #11666: [Bug]: Fix Romanian translation of some strings/words
19:30:07 <DorpsGek> [OpenTTD/OpenTTD] glx22 commented on pull request #11665: Update romanian.txt - fix spelling and correct word form.
19:30:36 <DorpsGek> [OpenTTD/OpenTTD] nielsmh closed pull request #11665: Update romanian.txt - fix spelling and correct word form.
19:31:31 <truebrain> Lot of changes to make in the tool however ...
19:32:10 <truebrain> But the change is a bit odd .. means another translator made this mistake 800 times ... but then again, I don't understand these languages anyway ๐Ÿ˜„
19:33:46 <jfs> I wonder if it has something to do with available glyphs in the bitmap font?
19:36:15 <jfs> no that can't be it actually, because some instances of those characters are using the (allegedly) right form
19:37:40 <peter1138[d]> Huh.,.. this works ๐Ÿ˜ฎ
19:38:01 <peter1138[d]> Generic window with callbacks to get the data.
19:38:08 <DorpsGek> [OpenTTD/OpenTTD] nielsmh reopened pull request #11665: Update romanian.txt - fix spelling and correct word form.
19:38:19 <peter1138[d]> Means I can use the same window.
19:38:24 <_zephyris> Having just made a font, comma and cedilla used to be viewed as stylistic alternates. Separate unicode codes have now been added, but aren't in the Latin extended A range that most fonts cover.
19:38:44 <peter1138[d]> Assuming split station builder stuff is desirable.
19:38:58 <_zephyris>
19:40:03 <DorpsGek> [OpenTTD/OpenTTD] nielsmh commented on pull request #11665: Update romanian.txt - fix spelling and correct word form.
19:43:49 <_zephyris> Just checked, it's in Latin extended B. A few characters in that range are provided in the current sprite font, but not the T/S comma (yet).
19:44:15 <jfs> the character also not being in a Windows ANSI codepage could also be an explanation, from when OpenTTD still officially supported Windows9x
19:46:19 <_zephyris> The old age of the translations suggest that the cedilla variant was more typographically accepted at the time.
19:47:25 <peter1138[d]> What's the glyph id?
19:48:43 <peter1138[d]> Or rather, unicode codepoint.
19:48:52 <Rubidium> well... Romanian got added in 2004 with a few thousand lines. Vista is from 2006, so likely OS is Windows XP. Reading T-comma's wikipedia: "n Windows XP, most of the fonts including Arial Unicode MS render T-cedilla as T-comma because T-cedilla was not believed to be used in any language." So yeah, you couldn't differentiate T-comma and T-cedilla, so it sounds quite plausible that a lot is wrong
19:49:13 <Rubidium> U+021A/U+021B
19:49:32 <Rubidium> T-comma capital and small letters respectively
19:50:27 <peter1138[d]> 015E is in 1466 fonts, 0218 is in 1129 fonts.
19:50:29 <Rubidium> S-comma is U+028 and U+029
19:50:46 <Rubidium> oops, S-comma is U+0218 and U+0219
19:51:12 <peter1138[d]> Ah, upper & lowercase.
19:51:37 <Rubidium> oh, and S-comma was not supported in Windows XP, except for some extension pack
19:52:07 <peter1138[d]> Similar for the T.
19:52:23 <peter1138[d]> "Not supported" for what?
19:52:49 <peter1138[d]> So the "old" versions are in slightly more fonts, but it's not a huge difference.
19:53:44 <peter1138[d]> Okay, class picker now uses a class with virtual functions for info instead of 3 function pointers...
19:54:16 <peter1138[d]> Next, preview picker.
19:54:48 <peter1138[d]> Or make it work for the other windows first. Hmm.
19:56:03 <Rubidium> peter1138[d]: I just paraphrased what was on Wikipedia, so... [citation needed] and I guess none of the fonts had it
20:01:33 *** Wormnest has quit IRC (Ping timeout: 480 seconds)
20:03:47 <peter1138[d]>
20:03:47 <peter1138[d]> Such generic windows.
20:04:09 <xarick>
20:04:09 <xarick> wow, gains!
20:04:33 <peter1138[d]> Is that like upgrading from Ultegra to Dura-ace?
20:06:03 <xarick> let's bankrupt a company
20:06:54 <xarick>
20:06:54 <xarick> keks! It has no vehicles
20:07:24 <xarick> there are still 13 other companies, btw
20:10:41 <xarick>
20:10:41 <xarick> bankrupting a company in master
20:13:11 *** Execthts has quit IRC (Quit: File:///)
20:13:26 *** Exec has joined #openttd
20:15:11 <xarick> it's nice that vehicles are deleted first
20:15:43 <_jgr_> You don't seem to be having much luck with level crossings...
20:19:05 <truebrain> Optimising bankruptcy... because that happens so many times a tick *trollface*
20:20:32 <xarick> he burden was shifted however, to deleting vehicles from the group
20:21:15 <locosage> it is good to reduce mp lag
20:21:25 <locosage> though I'v no idea if bankrupcy causes any
20:21:49 <truebrain> I once made a function 10 times as fast .. it was called once every 5 minutes. The game is now 0.0001% faster. A tale as old as developers ๐Ÿ™‚
20:22:44 <xarick> let me time the whole bankrupt process instead
20:22:51 <xarick> not just 1 part
20:33:33 <xarick>
20:33:35 <jfs> truebrain: my best genuine optimization this year though was at work, where I modified an SQL stored procedure from clearing and refilling a table to instead do a merge operation, cutting the running time by 20% and having the database generate 70+ GB less transaction log per hour
20:33:35 <jfs> (the backup team people were quite happy about the latter part)
20:35:50 <LordAro> peter1138[d]: such troll
20:39:15 <xarick>
20:39:43 <peter1138[d]> Moi?
20:39:43 <xarick> nice, but honestly I didn't expect this much of a difference, I wonder why
20:40:34 *** Wormnest has joined #openttd
20:45:00 <xarick> I'm suspicious, this is too good of a gain...
20:45:26 <xarick> I was only expecting gains in the order of 4000 us...
20:46:13 <truebrain> jfs: Nice! Now that is an optimization worth it ๐Ÿ™‚
20:47:16 <xarick> oh, right... the other function is called once per station, so it's 4000 less per station, I see now
20:47:26 <truebrain> @nielsm Did you also get a bonus because of it?
20:49:26 <xarick> 4000 and decreasing, the lesser the number of vehicles in the remaining companies
20:52:29 <xarick> I could optimise it a bit further, if I handle buoys and oil rigs as special cases
21:04:01 <xarick> waypoints with a owner
21:04:06 <xarick> are only trains
21:04:13 <xarick> moar optimizations ๐Ÿ™‚
21:06:04 <jfs> truebrain: no we don't really do that for singular tasks like that... also I work in public sector and the rules around pay and bonuses are rather stiff
21:06:24 <truebrain> Sad ... ๐Ÿ˜›
21:10:22 <peter1138[d]> Oops, I send the class id and the type id via InvalidateData()
21:10:40 <Rubidium> for work I made some export one to two orders of magnitude faster (many hours to minutes), not because it was asked... but because I was debugging an issue with the export and making it faster *really* helps. Especially when they were really simple tricks to make things faster
21:11:17 <peter1138[d]> I think I need `int data` to be `void *userdata`
21:16:05 <truebrain> That userdata ๐Ÿ˜„
21:20:16 <xarick>
21:20:52 <xarick> looking for a proficient dude with && || != == expertize
21:21:43 <peter1138[d]> Ah the old complex logical operators...
21:23:03 <xarick> let's see what bing chat comes up with
21:24:12 <Rubidium> I guess George Boole would be proficient ;)
21:24:41 <Rubidium> and/or Augustus De Morgan
21:25:01 <peter1138[d]> de Morgan would not be not rolling in his grave.
21:25:07 <xarick> bing chat disappointed me this time
21:25:44 <truebrain> Rubidium: Ouija board with you? ๐Ÿ˜„
21:32:08 <peter1138[d]>
21:32:08 <peter1138[d]> eh?
21:32:24 <truebrain> Lol
21:34:13 <xarick> thanks Bing... not sure if I trust it
21:35:22 <xarick> my questions are noob-like
21:35:28 <xarick> probably influences how it answers
21:42:10 <peter1138[d]>
21:42:10 <peter1138[d]> "mock up"
21:44:37 <peter1138[d]>
21:44:37 <peter1138[d]> fully loaded eh
21:47:47 <peter1138[d]> Hmm, maybe go one step further and make custom widgets
21:57:11 <xarick> bing failed
21:57:54 <xarick> the condition it gave me doesn't match the result
21:59:10 <xarick> or was I who failed... oh boy
22:06:48 <xarick> funny, it's a bug
22:06:57 <xarick> i removed a waypoint
22:07:05 <xarick> yet it passes me as a station
22:07:18 <xarick> why
22:09:06 <xarick> nevermind, I did actually removed a station, not a waypoint, I am so lost
22:16:40 <xarick> yep, it was bing who failed, the original 3 conditions work
22:18:58 <peter1138[d]> It was you who failed, expect a language model to be something it's not.
22:19:01 <DorpsGek> [OpenTTD/OpenTTD] JGRennison commented on pull request #11656: Fix #11337: Station blocked/pylon/wire bits with CBID_STATION_TILE_LAYOUT
22:24:16 *** thelounge345 has quit IRC (Quit: Ping timeout (120 seconds))
22:24:22 *** thelounge345 has joined #openttd
22:33:00 <xarick> ScriptVehicleList_Station might be further optimized as well
22:33:47 <xarick> so much I have to do... and so slow I am at it
22:44:41 <andythenorth> hmm such Horse compile editing
22:46:17 *** Wormnest has quit IRC (Ping timeout: 480 seconds)
22:46:30 <peter1138[d]> Hmm, objects window is a bit weird :S
22:47:09 <DorpsGek> [OpenTTD/OpenTTD] SamuXarick updated pull request #10548: Change: Groups cache vehicle lists
22:47:48 <xarick> oh crap, TICC TOCC wasn't removed ๐Ÿ™‚
22:50:26 *** tokai|noir has quit IRC (Quit: c('~' )o)
22:53:17 <xarick>
22:55:12 <xarick> it performed worse :/
22:56:00 <xarick> alright, I'll remove the special checks
22:57:46 <xarick> yeah, i doubt any of these ais used rail waypoints, it was the only way this could gain performance
22:57:58 <xarick> neutral stations aren't removed
22:58:03 <xarick> on bankrupt, so no dice
22:58:11 <xarick> nor buoys
23:01:06 <Wolf01> Happy new year (GMT+1)!
23:02:27 <DorpsGek> [OpenTTD/OpenTTD] SamuXarick updated pull request #10548: Change: Groups cache vehicle lists
23:03:18 <peter1138[d]>
23:03:18 <peter1138[d]> oops
23:03:56 <jfs> happy new year
23:10:22 <andythenorth> ๐Ÿ™‚
23:11:38 <peter1138[d]> Well this is awkward.
23:15:13 <peter1138[d]> The windows get placed on top of each other. Hmm.
23:15:38 <andythenorth> 'tile'
23:15:43 <andythenorth> window manager ๐Ÿ˜›
23:16:31 <peter1138[d]> Well we do already have that.
23:24:54 <andythenorth> is it naptime?
23:25:04 <peter1138[d]> Not yet.
23:27:12 *** Wormnest has joined #openttd
23:31:06 <DorpsGek> [OpenTTD/OpenTTD] 2TallTyler merged pull request #11656: Fix #11337: Station blocked/pylon/wire bits with CBID_STATION_TILE_LAYOUT
23:31:27 <DorpsGek> [OpenTTD/OpenTTD] 2TallTyler commented on pull request #11656: Fix #11337: Station blocked/pylon/wire bits with CBID_STATION_TILE_LAYOUT
23:42:34 <_glx_> happy new year
23:43:13 <DorpsGek> [OpenTTD/OpenTTD] glx22 merged pull request #11664: Fix: Missing invalidations on gui.ai_developer_tools change
23:56:59 <truebrain> Indeed: happy new year all ๐Ÿ™‚