IRC logs for #openttd on OFTC at 2024-02-18
โด go to previous day
00:03:40 <peter1138[d]> Hmm, very minor...
00:05:22 <xarick> that is a large description
00:05:49 <xarick> time for bed, cyas goodnight
00:28:19 <peter1138[d]> Surprising, still a benefit. Maybe I should test a self-built master instead of nightly.
00:29:12 *** Wolf01 has quit IRC (Quit: Once again the world is quick to bury me.)
00:55:25 <peter1138[d]> Oh, disappointing. My build is just faster than the nightly build.
01:29:07 *** ajmiles has joined #openttd
01:29:07 <ajmiles> The Station List window is extremely slow in the nightly build I just found
01:30:27 <ajmiles> With no station list window
01:35:41 <_glx_> probably redraws too much
02:04:36 *** greeter has quit IRC (Ping timeout: 480 seconds)
02:05:07 *** greeter has joined #openttd
02:23:05 *** m1cr0man has quit IRC (Quit: G'luck)
02:23:24 *** m1cr0man has joined #openttd
02:24:58 *** m1cr0man has joined #openttd
02:48:25 *** _glados_ has joined #openttd
02:48:25 <_glados_> Any plans on porting ottd from gl to vulkan?
03:01:02 <dwfreed> probably not anytime soon
03:01:24 <dwfreed> and it would require something like moltenVK for macos
03:01:57 *** Wormnest has quit IRC (Quit: Leaving)
03:03:13 <dwfreed> and a whole separate thing for the wasm target
03:08:01 <dwfreed> Not to mention older GPUs don't support it
03:14:03 *** kale91 has quit IRC (Quit: User went offline on Discord a while ago)
03:14:20 *** gnu_jj_ has quit IRC (Ping timeout: 480 seconds)
03:32:16 <_glx_> another video driver is always possible without removing existing ones
03:32:45 <_glx_> we still have SDL and allegro
03:37:39 <merni> _glx_: Hmm, fireball when the plane has no fuel
04:05:15 *** debdog has quit IRC (Ping timeout: 480 seconds)
04:15:25 *** all_heil_lord_pepe has joined #openttd
04:15:25 <all_heil_lord_pepe> did we ever find out if ottd could add more company slots?
04:18:32 <all_heil_lord_pepe> hard limit of 255 players in a game but hard limited to 15 companies...
04:18:35 <all_heil_lord_pepe> :banditwhat:
04:18:50 <all_heil_lord_pepe> then again, the base game is 25 years old
04:19:03 <merni> Nah TTD is older than that
04:19:17 <_glx_> and we already increased the limit
04:19:33 <merni> _glx_: what was it before?
04:20:22 <all_heil_lord_pepe> I remember the company colors talk like years ago...
04:21:13 <all_heil_lord_pepe> its just the limit of 15 hurts more then the over sized player limit does
04:23:05 <all_heil_lord_pepe> time to make it 50, but we can't anymore ๐ฆ
04:24:18 <merni> Pull requests welcome :P
04:25:40 <_glx_> I don't want to imagine script debug window, it's already ugly enough with 15 (and I improved it I think)
04:26:13 <merni> Perhaps dropdown rather than buttons
07:33:51 *** HerzogDeXtEr has joined #openttd
08:03:37 <LordAro> iirc it isn't a technical issue to increase the number of companies, it's a lack of viable colours
08:03:47 <LordAro> or suitably distinct colours, certainly
08:06:14 *** SigHunter has joined #openttd
08:06:34 <merni> well, if you want a ton of companies, just accept the colours will not always be distinct?
08:06:51 <SigHunter> is there a way to have more "history" in budget window and all the graph windows? more years back
08:08:38 *** HerzogDeXtEr has quit IRC (Read error: Connection reset by peer)
08:10:36 *** D-HUND is now known as debdog
08:16:05 <_zephyris> LordAro: This is part of the reason I would like to do two company colours in more places - on signs, on base set infrastructure, etc.
08:25:25 <peter1138[d]> _glx_: Caused by #11530
08:35:38 <peter1138[d]> Definitely no technical issues there ๐
08:36:49 <peter1138[d]> I would put the lack of distinct company colours as waaaaay down there in the list, myself. ๐
08:37:18 <truebrain> I still like how it was not 64, or 100, but immediately jumped to 500 ๐
08:37:45 <peter1138[d]> Well, it's not far off 512 I guess.
08:37:51 <andythenorth> [marvin here] doesn't increasing the number of companies just increase the amount of player support requests about griefing? ๐
08:38:01 <andythenorth> or is griefing a finite resource?
08:38:01 <truebrain> more to the point, now you have to find space for 2 bytes, instead of 1, to store in the map array ๐
08:38:03 <peter1138[d]> But that means you need 9 bits of storage, which is somewhat awkward. 250 would make more sense.
08:39:21 <peter1138[d]> Should I unfix #11530?
08:40:35 <peter1138[d]> Hmm, instead of invalidating the window, maybe just mark it dirty, so it redraws without rebuilding.
08:46:09 <andythenorth> hmm devloloper here
08:46:57 <andythenorth> my Horse compile gets the spritesheet ID (to compose a filename) from a train object via an attribute
08:47:19 <andythenorth> but occasionally I want to delegate the spritesheet ID to another train, because they use the same sprites
08:47:42 <andythenorth> is 'delegate' the correct word, or is that a specific pattern in OO?
08:47:55 <andythenorth> (I know how to write the code, it's naming that's hard)
08:48:09 <peter1138[d]> Yes. Changing from no-rating to has-rating is already handled separately.
08:48:31 <merni> peter1138[d]: And also with 255 players max doing 500 companies doesn't really make sense...
08:49:32 <merni> Unless you assume that more than half of the players will never be concurrently online
08:49:40 <truebrain> no worries, they also raised the player max
08:51:06 <merni> how about 1023 for each, a neat 10 bytes :p
08:52:35 <Rubidium> though... if you increase the maximum number of companies by a factor X, you should also reduce the maximum number of vehicles, AI opcodes, etc by that same factor. The game runs fine if I have 1000 trains in my single company, but when there are a 1000 companies with only 100 trains each it's a slideshow... the game is broken!
08:53:12 <truebrain> pfff, why can't this game handle 100,000 trains? I mean, come on, how hard can it be
08:53:39 <merni> Surely AI can handle that
08:53:42 <merni> Or move it to the Cloud
08:54:29 <merni> Just let andy's MBP pick up the slack for everyone else
08:55:24 <Rubidium> this is one of those instances where cloud could actually help... if it just streams the images to the client, we can just multithread everything and not bother about desyncs. Joining the game would be so much easier as well, as the client version won't matter much anymore either
08:56:05 <Rubidium> the only caveat would be monetary I fear
08:56:06 <truebrain> make the server a VNC server, you say?
09:01:26 <peter1138[d]> "No more self-hosting, your server hosting subscription fee is โฌx per month..."
09:01:47 <truebrain> sounds like a sane move after 20 years
09:15:12 <peter1138[d]> Part of my relatively recent WidgetID change was to standardise the storage format of widget indices. In some places only a byte was used, which is not enough for that many companies...
09:20:07 <andythenorth> remove 4k^2 maps
09:20:15 <andythenorth> then we don't need more companies?
09:21:39 <peter1138[d]> Largest size, 512.
09:22:22 <andythenorth> do we really need more than 64 trains?
09:22:59 <andythenorth> I have at least 44k unused IDs in Horse
09:23:41 <andythenorth> nmlc info: Train items: 5556/65420
09:24:01 <andythenorth> only using 8% of the available IDs
09:24:07 <andythenorth> probably a sign of over-provision?
09:33:50 <reldred> we're supposed to throw out limitation not introduce more ๐
09:36:35 <reldred> disturbs me very sprites
10:45:12 *** tramman has joined #openttd
10:45:13 <xarick> I got a 86 MB savegame, a lzma:9 savegame, interested?
10:46:12 <xarick> I wonder why they keep getting bigger
10:46:26 <Rubidium> your gazillion vehicles
10:46:49 <xarick> yeah, but it's still using the best compression method
10:47:23 <dwfreed> compression isn't magic
10:48:18 <xarick> "someone" willing to investigate what's causing the save to be this big?
10:50:09 <dwfreed> I think Rubidium already answered that
10:51:02 <xarick> is there a way to see what's the size of each savegame chunk?
10:53:21 <Rubidium> there's probably a tool for that somewhere
10:57:03 <xarick> oh, the trend is reversing
10:58:17 <tramman> Hi everyone, is anybody familiar with the yapf for road vehicles and knows if it can detect and penalise if a station is full or not (like it would do for trains)?
11:00:18 <tramman> I am trying to debug why a tram will make a particular path decision, to try and enter a blocked drive-through road station, instead of taking a longer route to enter from the other side where it is not blocked.
11:04:48 *** SigHunter has joined #openttd
11:08:31 *** SigHunter has joined #openttd
11:14:39 <xarick> found a case where unbunch rules are not being enforced
11:15:17 <xarick> somewhere in CMD_INSERT_ORDER
11:35:17 <xarick> attempted to insert a depot order with unbunch
11:36:35 <xarick> line 821 is the culprit, not line 820
11:46:15 *** oftc is now known as Guest144
11:50:25 *** Westie has quit IRC (Ping timeout: 480 seconds)
11:53:40 *** Guest144 has quit IRC (Ping timeout: 480 seconds)
12:00:24 <xarick> can't AIs insert non-NON_STOP orders at all?
12:06:32 <xarick> nevermind, they can, my error
12:06:35 <_glx_> Implicit orders are just a weird thing for AIs
12:08:35 <xarick> I forget the orders are inserted before the index that is given
12:09:40 <xarick> i inserted 4 orders before 7
12:10:36 <xarick> 6 should fail and 3 should fail
12:13:45 <tramman> frosch123: thank you!
12:17:44 *** Eddi|zuHause has quit IRC ()
12:22:24 *** Eddi|zuHause has joined #openttd
12:26:27 <xarick> Oh, I see, it just defaults to STOP_EVERYWHERE <OrderNonStopFlags onsf = (OrderNonStopFlags)((order_flags & OF_NON_STOP_INTERMEDIATE) ? ONSF_NO_STOP_AT_INTERMEDIATE_STATIONS : ONSF_STOP_EVERYWHERE);>
12:27:23 <tramman> frosch123: Are you familiar with this code and can I pick your brain? This code reads to me like it looks at how many tiles of connected stations are occupied, but a single tram loading a full load order could block the entrance in that direction (ie if it entered the station last, and the other trams leave first) so whether they're occupied is irrelevant - no trams can enter. Do you think there is scope for adding a penalty for when
12:27:52 <_glx_> I think nobody is familiar with yapf ๐
12:29:36 <_jgr_> You don't really have to understand how YAPF works to be able to adjust the penalties
12:29:52 <_jgr_> That said the code is well written, it's not magic
12:31:04 <_jgr_> At present road stops don't track where within a particular road stop sequence the occupants are
12:32:41 <_jgr_> Averaged over time it doesn't matter that much
12:33:02 <tramman> There is the IsEntranceBusy function in roadstop_base.h which could be useful for the pf penalty
12:35:26 <_jgr_> This is for bay road stops so drive-through ones
12:36:12 <_jgr_> It's also not the same as whether the bay stop is full
12:53:48 <tramman> _jgr_: do you think I'd be able to get support to fix this if I tried? It seems trams/road vehicles are not all that popular.
12:55:18 <merni> If you submit a PR, most of the time devs will help with it
12:56:14 <tramman> Thanks. I'll take some time to ponder the solution. I'm a Python guy so it'll take me a while just to work out just where to start.
13:03:37 <_zephyris> Does this count as a bug? The shadow for combining diacritics is drawn over the character it's draw combined with. `ฤ` is a precomposed unicode character, `Cฬ` is made from `C` and the combining breve stymbol.
13:03:50 <merni> It does look quite weird
13:04:22 <merni> I think it'd be better if all shadows were behind all "real" graphics
13:04:48 <_glx_> shadows are drawn before the character
13:11:06 <peter1138[d]> A bug, expected by the design.
13:11:57 <tramman> Thanks for your help.
13:12:01 *** tramman has quit IRC (Quit: Page closed)
13:44:15 <_zephyris> peter1138[d]: You'll see the contextual substitution with a small caps C to get the correctly positioned diacritic... What a faff!!
13:46:54 <frosch123> DrawLayoutLine loops over the layout runs, and then alternates between shadow and foreground sprite for each glyph. can't we swap the loops?
13:48:47 <_glx_> would make sense to draw the full run shadow then the full run foreground
13:54:11 *** Parmesantree has joined #openttd
13:54:14 <_zephyris> You'll probably need my font for testing, in most the diacritics are further away from the character so probably won't overlay
13:56:48 <frosch123> we should remove the weird underline drawing somewhen
13:57:42 <_zephyris> This is the dev version, combining diacritics for the Latin alphabet should mostly (all?) have the same problem
13:59:30 *** Parmesantree has quit IRC (Quit: Leaving)
14:07:35 <frosch123> i see no difference yet, i may have choosen the wrong characters for testing
14:07:44 <frosch123> let's see how i can input those half-circle things
14:13:08 <frosch123> maybe i still have the wrong font
14:14:54 <frosch123> reversing order of shadow/foreground:
14:14:58 <frosch123> so i think my code is correct ๐
14:17:53 <truebrain> that moment you open up Discord and it is full with AAAAAAAAAAAAAAA
14:17:59 <truebrain> to realise it is just frosch123 being weird ๐
14:18:28 <frosch123> look closer, i did not paste a single "A"
14:20:25 <frosch123> oh true, looks like compose+ยฐ+A did not result in anything
14:20:57 <frosch123> it was supposed to be ร
14:22:13 <frosch123> hmm, i can't find a place where the ... truncation is drawn
14:23:20 <frosch123> ah, i blame the weird coop savegame, which named all stations with short letter/number names
14:23:41 <_zephyris> I think those are all characters which have precomposed glyphs, you need to find a combo that's not already in this set
14:24:16 <frosch123> oh, i explicitly only used precomposed ones :p
14:24:26 <_zephyris> Layouters probably replace the combo of a letter and a combining diacritic with the combined glyph automatically if possible
14:24:43 <_zephyris> frosch123: Ah, OK, that's why then!
14:26:42 <xarick> shouldn't this be 1 << 2
14:27:08 <xarick> order types are already confusing
14:27:43 <xarick> OLFB , the B stands for Bit, isn't it?
14:28:43 <frosch123> PR description is still incomplete ๐
14:28:51 <frosch123> still trying to create a useful screenshot
14:28:53 <truebrain> training an AI to do your work? ๐
14:31:20 <_glx_> xarick: doesn't really matter
14:33:59 <xarick> [2024-02-18 13:54:02] dbg: [script:0] Possible infinite loop in SetOrderFlags() detected
14:34:41 <xarick> trying to set unbunch order to an order that is already unbunch
14:35:45 <xarick> it should return true somewhere, and not infinite loop
14:35:54 <frosch123> pff, there are about 120 superscript combining thingies
14:36:32 <frosch123> hah, actually wrong, my editor fails to count them correctly
14:42:45 <frosch123> still no difference:
14:42:53 <frosch123> most of the diacritics are not drawn ๐
14:43:40 <frosch123> in case someone else wants to test: AฬAฬAฬAฬAฬAฬ
AฬAฬAฬAฬAฬAฬAฬAฬAฬAฬAฬAฬAฬAฬAฬAฬAฬAฬAฬฝAฬพAAAAAAAAAอAอAอAอAอAอAอAอAอAอAอ AอกAอฃAอคAอฅAอฆAองAAAAAAอญAอฎA
14:44:25 <truebrain> lot of that list are just A, it seems ๐
14:44:32 <truebrain> (in Discord, that is)
14:46:54 <frosch123> the combining-superscript-latin-small-letters are particulary funny
14:49:44 <_zephyris> frosch123: The one on the right is better, it fixes these ^
14:52:00 <xarick> need to decide if the combination of OF_SERVICE_IF_NEEDED with OF_UNBUNCH_IN_DEPOT are ValidOrderFlags
14:52:29 <frosch123> ah, so i was just blinded by too many As ๐
14:53:41 <xarick> OF_GOTO_NEAREST_DEPOT my bad
14:54:07 <frosch123> thanks, PR description finished
14:55:27 <_zephyris> frosch123: Thaaanks for taaaking aaa look aaaat this ๐
14:56:09 <frosch123> hmm, there's no A in "you're welcome"
14:56:19 <frosch123> but there is one in Truebraaaaain
14:57:18 <frosch123> oh actually.... _zephyris you aaare welcome ๐
15:00:51 <xarick> why the heck visual studio bugs out sometimes
15:01:00 <xarick> i can't add tab spaces
15:02:49 <xarick> seems like it's automatically formating when I press TAB
15:02:56 <xarick> instead of adding spaces
15:06:47 <blathijs> _zephyris: Nice post on Truetype fonts, good read! Also, it was featured on hacker news today :-)
15:11:08 <_zephyris> blathijs: Thank you!
15:23:39 <xarick> finally solved it was this the problem!
15:34:31 *** HerzogDeXtEr has joined #openttd
15:44:21 <Rubidium> anyone who wants to weigh in on #12113?
15:53:27 <frosch123> is it correct that, while custom currencies were saved in the savegame, the separator was not?
15:54:48 <frosch123> hmm, maybe only the selection of "custom currency" is saved
15:56:34 <Rubidium> yes, only that the custom currency is used is saved
16:03:38 <frosch123> who dares to branch? :p
16:04:21 <frosch123> hmm, i guess we need to wait for the next eints commit
16:14:05 <xarick> talltyler: Can I suggest instead of generating an error message when adding a 2nd unbunch order, set the new order with unbunch and remove unbunch from the other?
16:15:27 <xarick> cus looping over orders from an AI standpoint is boring
16:16:10 <_jgr_> The unbunch feature was not added for the convenience of AIs...
16:16:47 <xarick> I'd need to do way so much code to find the order that has the unbunch
16:17:46 <_jgr_> A loop with some ifs in it does not seem excessively arduous
16:28:17 <xarick> first it would need to detect the error message
16:32:51 <talltyler> Silently removing the first unbunching order is a bad user experience. Thatโs why it gives an error.
16:35:48 <_glx_> API should validate before issuing the command I think
16:39:32 <locosage> talltyler: giving an error is arguably even worse ux ๐
16:41:53 <locosage> i fixed a bunch of those stupid errors in cmclient but there are still some left
16:42:18 <locosage> like why the heck do I need to pick the right road stop type when removing it
16:45:37 <_glx_> xarick: if you use unbunch you need only one depot order
16:48:33 <_glx_> you forgot to add some files before commit I think
16:56:47 *** Flygon has quit IRC (Quit: A toaster's basically a soldering iron designed to toast bread)
17:00:27 <xarick> the Cmds are not enforcing the rules
17:01:57 *** m1cr0man has quit IRC (Quit: G'luck)
17:02:15 *** m1cr0man has joined #openttd
17:03:31 <xarick> this should not be the job of the AI API
17:05:37 *** m1cr0man has joined #openttd
17:08:32 *** Wormnest has joined #openttd
17:22:16 *** m1cr0man has quit IRC (Quit: G'luck)
17:22:33 *** m1cr0man has joined #openttd
17:23:57 <xarick> shouldn't the HasUnbunching order be in order_cmd.cpp
17:24:14 <xarick> it's where the HasDepotOrder is located
17:26:34 <xarick> perhaps the other way around, HasDepotOrder moved to vehicle.cpp
17:34:05 *** m1cr0man has quit IRC (Quit: G'luck)
17:34:23 *** m1cr0man has joined #openttd
17:35:45 <j_n> you know what, I think the sadness factor associated with the removal of share trading was outweighed by my love for the new smooth font
17:36:37 *** m1cr0man has joined #openttd
17:38:18 *** m1cr0man has joined #openttd
17:40:22 *** gelignite has joined #openttd
17:56:36 <debdog> I have just compiled beta3 and have a question: I like the option to change interface size. though the icons themselfes do not change size only the boxes surrounding them. are they supposed to?
17:57:56 <debdog> te new font seems greatt! (first impression)
18:02:49 <_zephyris> debdog: The icons only scale by factors of 2, so you'll see 1x scale icons at 1 to 1.75, 2x scale icons at 2 to 3.75 and 4x scale icons at 4 and higher.
18:04:18 <debdog> ahh, I see. yes that works. thanks _zephyris
18:07:34 <debdog> is there anything in particular that needs testing?
18:09:45 *** m1cr0man has quit IRC (Quit: G'luck)
18:10:03 *** m1cr0man has joined #openttd
18:17:42 *** m1cr0man has quit IRC (Quit: G'luck)
18:18:00 *** m1cr0man has joined #openttd
18:19:41 <xarick> dear talltyler , if I have a conditional order and a full load order at the same time... the error for unbunching is only going to accuse one of them.
18:21:28 <_glx_> because it can't check both at the same time
18:21:52 <_glx_> would be overkill as none of them is allowed anyway
18:22:01 <xarick> oh nevermind, this is an AI only issue
18:22:25 <_glx_> for the AI I think you can just use one error for all the strings
18:22:34 <xarick> wait, I got confused again
18:23:18 *** m1cr0man has quit IRC (Quit: G'luck)
18:23:35 *** m1cr0man has joined #openttd
18:24:12 <xarick> wasn't control+click on a depot going to add unbunch immediately?
18:24:23 <xarick> seems to be doing service at depot
18:25:52 *** m1cr0man has joined #openttd
18:30:13 <xarick> now I suspect it's going to unbunch with conditional and full load orders
18:31:11 *** m1cr0man has quit IRC (Quit: G'luck)
18:31:29 *** m1cr0man has joined #openttd
18:34:20 <_glx_> no, the command properly checks
18:35:03 <xarick> no, not that test. Try having full load or conditional order, then add + ctrl+click depot
18:35:04 *** m1cr0man has joined #openttd
18:35:11 <DorpsGek> - Update: Translations from eints (by translators)
18:35:49 <_glx_> ctrl+click on stops then ctrl+click on depot
18:36:19 <_glx_> but the other way errors
18:36:33 <_glx_> talltyler: missing checks ๐
18:36:41 <Rubidium> shall I do the thing?!?
18:37:04 <xarick> too many checks needed
18:38:00 <_glx_> not now rubidium, there's a bug ๐
18:38:48 <Rubidium> well... the number of bugs is gross anyway ;)
18:39:02 <_glx_> this one was added 2h ago ๐
18:42:27 *** m1cr0man has quit IRC (Quit: G'luck)
18:42:43 *** m1cr0man has joined #openttd
18:44:37 <talltyler> _glx_: Mind opening an issue? I am not at home to look at this right now.
18:48:59 <truebrain> There is always one more bug. But does it crash the game? ๐
18:54:06 <Rubidium> Eddi|zuHause: yes, or as Merriam-Webster calls it... "an aggregate of 12 dozen things"
18:56:28 <andythenorth> Horse compile: the list named `wagons_provided_by_other_rosters` what would you think it defines?
18:56:35 <andythenorth> GPT guessed correctly, but eh
19:01:36 <xarick> fool load + unbunch allowed
19:16:46 <_zephyris> Hmm, not sure consistency of selector draw order is a thread worth pulling at... Though I'm surprised those airport corners aren't behaving like ground sprite children...
19:17:08 *** m1cr0man has quit IRC (Quit: G'luck)
19:17:26 *** m1cr0man has joined #openttd
19:19:11 <locosage> with factory that's at least understandable as that's just ground sprite
19:19:57 <locosage> doesn't do that with bonky that has actualy building there
19:34:59 *** m1cr0man has quit IRC (Quit: G'luck)
19:35:17 *** m1cr0man has joined #openttd
19:36:11 *** m1cr0man has joined #openttd
19:42:54 <j_n> j_n: the new aggressive takeover feature actually isn't too bad
19:43:01 <frosch123> uhm, so, is the branch happening now? or are we indefinitely waiting for someone to fix something?
19:43:05 <j_n> I just miss being able to trade player company shares
19:43:46 <j_n> speaking of, would it be possible to modify the game such that player companies can be taken over as well?
19:45:28 <j_n> like that spiff OpenTTD Battle Royale
19:51:17 <locosage> it can almost be done with gamescript
19:51:27 <locosage> I think it just misses the api for company merging
19:51:51 <locosage> and, well, gui will be in the storybook ofc
19:53:22 <locosage> though in spiffs br they were not merged just deleted so may already be possible
19:55:17 <xarick> openttd battle royale, with companies trying to buy each other?
19:58:50 <Rubidium> frosch123: I guess so
19:59:37 <Rubidium> though I wonder whether I messed up something
20:01:00 <Rubidium> as there's a load of expected checks that don't seem to be starting
20:03:34 <frosch123> the branch itself should not start anything, should it?
20:04:15 <Rubidium> it's the PR that's messed up somehow, with old and new checks
20:04:50 <Rubidium> as if the old checks are still required for non-master in some configuration somewhere
20:06:40 <frosch123> i woudl try the "update branch" button
20:07:12 <frosch123> it seems like the branch-retarget requested new checks, but they declined because no code was changed
20:10:39 <frosch123> well, they are running now
20:11:09 <Rubidium> ... except the required ones...
20:11:22 <Rubidium> (barring the commit checker)
20:18:34 *** gelignite has quit IRC (Quit: Stay safe!)
20:19:33 *** m1cr0man has quit IRC (Quit: G'luck)
20:19:34 <Rubidium> I guess we need truebrain or maybe glx or LordAro to change some configuration somewhere I can't find/I'm not allowed to go to
20:19:51 *** m1cr0man has joined #openttd
20:20:00 <_glx_> I'll see, looks like some task name changed at some point
20:20:42 <wensimehrp> The latest nightly did not crash with AI companies and custom currency format _glx_
20:21:00 <truebrain> Rubidium: That is normal. We can't fix it till after branching, after which an admin needs to do a bit of magic ๐
20:21:25 <truebrain> _glx_: are you fixing it?
20:21:52 <_glx_> if I remember where to click ๐
20:22:25 <truebrain> The branch protection needs to be migrated to a rule protection
20:24:06 <truebrain> Guess extending the current ruleset is sufficient for now
20:24:40 <truebrain> Let me know if you get stuck ๐
20:25:51 <_glx_> oh I see, I'm used to the old stuff
20:27:58 <truebrain> Don't forget to remove the old branch protections
20:30:03 <frosch123> such magic :p since when is that ruleset option there?
20:30:15 <truebrain> Over a year now or so?
20:30:35 <truebrain> It fixes a lot of things you couldn't do with branch protections
20:30:48 <truebrain> Like making an exception for eints
20:31:17 <frosch123> 13.4 was 2023-07-29. was it not needed then?
20:31:48 <truebrain> No. It was still on the old system, as that was fine for those workflows
20:31:51 <_glx_> we renamed workflows since
20:32:15 <_glx_> but 13 was not affected
20:32:17 <frosch123> ok, so it was intentionally different for 13.x
20:32:59 <_glx_> but I guess release branch will still need it's own ruleset at some point
20:33:06 <truebrain> Why spend effort updating 13.x when it fixes itself with 14.x ๐
20:33:21 <truebrain> _glx_: It will. But a problem for then ๐
20:34:15 <truebrain> frosch123: Important to know workflows are per branch
20:34:47 <_glx_> truebrain: and it's so annoying to test release workflow ๐
20:35:01 <Rubidium> CodeQL is required in the 14 branch, but it's not running
20:35:51 <_glx_> oh it runs only on master and PR against master
20:36:28 <truebrain> Yeah, CodeQL can't run in branches in a nice way
20:36:37 <truebrain> It stores information per branch
20:36:48 <frosch123> truebrain: so "then" is "now" :p
20:36:51 <_glx_> so a new ruleset it will be
20:37:34 <truebrain> That CodeQL is mandatory is also new btw ๐
20:37:36 <_glx_> of course no "copy" button
20:37:53 <truebrain> They do have an export/import button; never tried it
20:38:11 <truebrain> Putting two browser windows side-to-side has always been quicker ๐
20:38:41 <_glx_> testing the export/import
20:40:45 <_glx_> I removed eints from release/*
20:40:58 <_glx_> it is not supposed to commit there
20:42:40 <_glx_> still would be nicer to have a "copy" button
20:44:33 <peter1138[d]> What have I broken today.
20:45:51 <xarick> extremelly complicated set of rules this unbunch is creating...
20:46:52 <xarick> if the vehicle has a service at nearest depot and i add an unbunch, is it supposed to error?
20:50:20 <Rubidium> hmm... the timing... Release #1000: Release 14.0-RC1
20:51:33 <truebrain> And just a reminder we have to disable asserts in the release branch at some point
20:51:40 <truebrain> Ideally before 14.0
20:51:49 <truebrain> (We forgot with 13.0)
20:51:56 <LordAro> and before we attempt 14.0.1
20:52:18 <xarick> ```GSOrder.AppendOrder(vehicle_begin, get_order_destination, GSOrder.OF_UNBUNCH_IN_DEPOT | GSOrder.OF_SERVICE_IF_NEEDED | GSOrder.OF_GOTO_NEAREST_DEPOT | GSOrder.OF_NON_STOP_INTERMEDIATE)```, all these flags can be combined
20:56:47 <Rubidium> lets hope someone looks at the 14 milestone before the actual release will be made :D
21:01:10 <xarick> oh, I was dealing with these issues
21:03:02 <xarick> there's the unique unbunch , the conditional order, the service at nearest, the full load, the stop at depot... it's very messy
21:03:55 <xarick> AIs can set an unimaginable combination of flags
21:04:05 <xarick> that the GUI interface can't
21:06:51 <_glx_> the main issue is CmdInsertOrder uses v->HasUnbunchingOrder() (which works, but it should also use some kind of HasConditionalOrder() and HasFullLoadOrder())
21:08:59 <xarick> and implicits constantly reseting the unbunch stats
21:09:19 <_glx_> implicit orders are bad
21:09:46 <_glx_> they also mess up cargo dist
21:10:25 <xarick> remove implicit orders is in order?
21:10:30 <_glx_> because the links can appear and disappear
21:10:47 <peter1138[d]> They only exist to make cdist work, no?
21:11:44 <_glx_> they were added because vehicle already stopped there without notice yes
21:12:39 <_glx_> so cargodist works, but I think the "randomness" of implicit orders (depending on vehicle paths) creates/deletes links
21:14:14 <_glx_> for trains it's most likely stable, but RVs can do weird trip around blocks
21:14:16 <Rubidium> @topic set 1 13.4, 14.0-RC1
21:14:16 *** DorpsGek changes topic to "13.4, 14.0-RC1 | Website: *.openttd.org (source: github, translator: translator, server list: servers, wiki: wiki) | Don't ask to ask, just ask | 'Latest' is not a valid version, 'Most recent' neither | English only"
21:15:02 <peter1138[d]> Back when RVs only had drive-in bays they didn't really use implicit orders, I guess.
21:15:18 <_glx_> add "service at nearest depot" and it can change the loop
21:16:14 <_glx_> yeah it's an effect of drive-through
21:16:41 <_glx_> but it was a thing for trains before
21:18:01 <_glx_> there's a reason why "new orders are non-stop" defaults to true ๐
21:18:26 <peter1138[d]> Yes, just to annoy me :p
21:19:19 <Rubidium> who can do the remaining post release things? I've waited for github, made a PR for the website and updated the IRC topic. I'm not on the social media, so can't do those
21:21:43 *** nielsm has quit IRC (Remote host closed the connection)
21:21:50 <peter1138[d]> Hmm, is 3 seconds to finish `stop_ai` reasonable...
21:22:16 <_glx_> 3s on the 4kยฒ with 15 of them ?
21:23:41 <peter1138[d]> It's nearly 20s in master (and it was over a minute before the disaster vehicle change)
21:24:39 <_glx_> won't be easy to find more improvements there
21:25:01 <xarick> only 3 seconds? that's awesome
21:25:35 <xarick> can't wait to see those results live
21:32:22 <xarick> stop in depot and unbunch can't be combined, right?
21:33:12 <xarick> there's no enforcement for that, but from GUI I see I can't do it, but from AI, I can combine these
21:40:27 <ajmiles> _glados_: Looking back at old messages, you said you got Vulkan and D3D12 working about a year ago?
21:41:53 <_glados_> Yea iโve had difficulty getting it working due to the drawing arch it makes it hard for me to get it to work
21:42:10 <_glados_> So thought to ask if anyone else has had a go too
21:43:20 <_glados_> Iโm still chipping at it but it may need a full renderer overhaul
21:44:14 <_glados_> I have not even tried with D3D12 yet
21:44:53 <xarick> that's a lot of action!
21:45:07 <ajmiles> What is it about 12 and Vulkan that would mean it couldn't be built in the same way as the GL renderer?
21:46:37 <_glados_> You canโt really do the bilting the game dose without ripping it all out and making rely on quad rendering
21:47:25 <_glados_> This game still uses pre shader gl making it harder to rework
21:47:57 <_glados_> At least from the time iโm had work on it
21:48:12 <ajmiles> Someone had a D3D11 driver up and running very non invasively. I was looking at their PR this evening
21:48:45 <_glados_> Iโve thrown out 5 attempts due the fact
21:49:44 <_glados_> ajmiles: The difference between dx11 and vulkan and dx12 are different in the way the api works
21:50:27 <_glados_> Dx12 you could port dx11 but it can still be a pain
21:52:52 <peter1138[d]> non-stop means "don't stop along the way"
21:55:35 <xarick> I am amazed the UI can print all kind of combinations
21:55:39 <ajmiles> _glados_: I know 11 and 12 pretty well, but I guess I'm just not sure if your plan is to offload more of the work onto the GPU than is currently handled by the GL implementation. When I started poking around it looks like there's still a lot of CPU blitting into GL resources going on
21:57:53 <_glados_> ajmiles: Thatโs this bit iโve had problems with too getting the gpu to do 100% of the work due to the way the games set up Iโm have difficulty figuring out how i should arch the code to future proof it
21:58:53 <_glados_> Also without it becoming a cesspit of spaghetti code
22:01:37 <_glados_> My full roadmap was to get vulkan, metal and dx12 working and drop cpu and opengl due to them becoming more and more deprecated year on year with the drivers from vendors letting them collect dust
22:02:26 <_zephyris> xarick: Surely the stop wait combo shouldn't be possible...
22:05:45 <ajmiles> _glados_: Yeah, I would have expected if you can figure out a way to offload the blitting to the GPU that you could bring opengl along for the ride and keep the low spec requirements in place
22:07:48 <ajmiles> They're lower level APIs, but I don't yet see what they bring to the table that OpenTTD would take advantage of
22:09:33 <ajmiles> I made a start on bringing up a 12 backend this evening, and hopefully through that process I'll get a better understanding of how the renderer is built
22:12:20 <peter1138[d]> OpenTTD renders, pixel-by-pixel, to a back buffer. The back buffer then gets renderer to the display with OpenGL.
22:12:58 <ajmiles> Based on my brief perusing, that was my understanding.
22:14:10 <ajmiles> And I'd go out on a limb and guess that the blitting is a big chunk of code that's not amenable to just "moving" to the GPU
22:16:04 <peter1138[d]> There are several blitters already, slightly different depending 8bpp or 32bpp, along with animation etc. And the OpenGL stuff uses a special 40bpp blitter.
22:16:13 <peter1138[d]> So it can be changed per driver.
22:17:20 <FLHerne> move the sprite sorter into a compute shader, so it can have even more obscure issues
22:17:23 <peter1138[d]> Each blitter uses its own internal representation of sprite data -- 8bpp doesn't need RGBA data for example.
22:18:07 <FLHerne> I've occasionally wondered how much stuff in OTTD /could/ be done on the GPU if
22:18:25 <FLHerne> *if someone was really determined to
22:19:07 <peter1138[d]> But one problem with actually using hardware for low-level drawing is we don't have models and texture atlases, we have 10,000 sprites of different sizes that are loaded (and unloaded) on-demand.
22:20:03 <ajmiles> That is the one area where potentially a bindless graphics API like 12/Vulkan could help, as there'd be no need to atlas anything. Just index into a giant heap of 10,000 sprites
22:20:30 <peter1138[d]> (10,000 varies depending on NewGRFs of course, the baseset is a few thousand.)
22:20:40 <FLHerne> grf callback evaluation feels like it could potentially be done by GPU compute (similar to how Dolphin uses compute shaders to emulate processors)
22:21:06 <peter1138[d]> How is the GPU going to query game state?
22:21:15 <_glx_> all grf stuff must happen at the same time on each clients
22:21:17 <FLHerne> obviously it would be more hassle to implement than it's worth
22:21:51 <peter1138[d]> Put all game data on the GPU and write a complex shader that renders it all by itself ๐
22:22:02 <FLHerne> upload it all to the GPU each tick, they have gigabytes of storage now :p
22:22:30 <peter1138[d]> Nah, implement gameplay in shaders too.
22:22:36 <peter1138[d]> Then only commands need to be uploaded.
22:23:05 <ajmiles> I'm imagining a world where the CPU's job is still to determine which sprites are visible and where, but the per-pixel loop is entirely offloaded
22:23:12 <peter1138[d]> Oh, not 3 seconds. 2.2 seconds.
22:23:35 <ajmiles> But to call myself poorly educated on how it works right now would be an understatement
22:24:15 <_jgr_> The code is all there, you can have a browse through it
22:25:04 <ajmiles> Yep, I'm in there already. I don't want to start asking questions before I've spent some time understanding what's there
22:25:12 <peter1138[d]> My OpenGL blitter from 2007... 17 years ago... did that.
22:25:44 <ajmiles> peter1138[d]: But the current one doesn't?
22:25:53 <peter1138[d]> No. it was impractical ๐
22:26:08 <ajmiles> Don't let little things like that stop you
22:26:37 <peter1138[d]> (It offloaded the per-pixel stuff, but it loaded every sprite into an individual texture.
22:26:49 <peter1138[d]> It was horribly slow.
22:27:37 <ajmiles> Isn't the loading of the sprites into textures a one-time cost on load?
22:27:54 <peter1138[d]> On load of what?
22:28:00 <ajmiles> On load of each sprite
22:28:01 <_glx_> there's a lot of sprites
22:28:37 <ajmiles> 10,000 textures doesn't seem like an insane number
22:28:59 <peter1138[d]> That's on the low end.
22:30:15 <ajmiles> But was it faster after the sprites had been loaded?
22:30:54 <peter1138[d]> I've got a config with 240,000 sprites currently, nice.
22:31:30 <peter1138[d]> No, but it was terrible OpenGL code. All immediate mode.
22:32:10 <_glx_> oh and EZ sprites are big ๐
22:42:38 *** _bouke_ has quit IRC (Quit: User went offline on Discord a while ago)
22:47:13 <peter1138[d]> Also, my opengl diffs are still there. After all these years. They won't apply of course ๐
22:50:17 <xarick> still have to do a cleanup
22:52:05 <truebrain> Awh, no image in the news post? Guess no Steam news post than ๐
23:09:34 *** Wolf01 has quit IRC (Quit: Once again the world is quick to bury me.)
23:14:40 *** keikoz has quit IRC (Ping timeout: 480 seconds)
23:36:01 *** m1cr0man has quit IRC (Quit: G'luck)
23:36:20 *** m1cr0man has joined #openttd
23:44:33 *** tokai|noir has joined #openttd
23:44:33 *** ChanServ sets mode: +v tokai|noir
23:51:26 *** tokai has quit IRC (Ping timeout: 480 seconds)
continue to next day โต
