Config
Log for #openttd on 14th March 2025:
Times are UTC Toggle Colours
00:14:23  *** WormnestAndroid has quit IRC
00:14:25  *** WormnestAndroid has joined #openttd
00:29:28  *** knolle_ has joined #openttd
00:31:27  *** knolle has quit IRC
00:31:27  *** knolle_ is now known as knolle
01:40:27  *** reldred has joined #openttd
01:40:27  <reldred> https://cdn.discordapp.com/attachments/1008473233844097104/1349920077591478292/image.png?ex=67d4da8a&is=67d3890a&hm=38f29264d47aabf70c5d9d8fab9af04a19c985d5ae34b480cb21c6004ca7d482&
01:40:28  <reldred> Quick question, who remembers where fence drawing logic happens? I want to make an option to use the original TTD fence logic. I'll primarily be targetting JGRPP with this, but if there's interest in having it in OpenTTD I'll consider writing the PR for both.
01:44:54  <_glx_> probably https://github.com/OpenTTD/OpenTTD/blob/master/src/rail_cmd.cpp#L2009
01:58:17  <reldred> Awesome, thanks, I’ll have a poke at that tonight
01:59:10  <reldred> The old logic works better for full width ballast track sets, and for some of the fake grass shenanigans some of the sets are doing with fence sprites.
02:03:24  *** Wormnest has quit IRC
02:19:48  <talltyler> Why did it change, and when? Was it in TTD or OpenTTD?
02:28:15  <reldred> It's an OpenTTD change, not sure when it changed. The above is TTDPatch.
02:52:49  <emperorjake> https://cdn.discordapp.com/attachments/1008473233844097104/1349938288936616027/image.png?ex=67d4eb80&is=67d39a00&hm=001c8459b78edd627f2089fd2abffd4281b74c5b9ca0e5f1765f4f6477366e48&
02:52:49  <emperorjake> 0.7.3 still has the old behaviour
02:54:50  <talltyler> So there’s precedent to change it back, no setting required 😛
03:05:38  <emperorjake> I found it https://github.com/OpenTTD/OpenTTD/issues/5145
03:07:07  <emperorjake> https://github.com/OpenTTD/OpenTTD/commit/a34dabce9c6d5e58ea9bd24d3d1b50772776a978
03:08:37  *** debdog has joined #openttd
03:12:01  *** D-HUND has quit IRC
03:30:44  <belajalilija> talltyler: are you sure? people could be up in arms over the change to railway fence placement, it might break the game
03:30:54  <belajalilija> might even be literally unplayable
03:34:01  <emperorjake> It won't break the game, if you read the forum thread it says it's savegame safe in both directions
03:34:21  *** geizeskrank has quit IRC
03:34:50  <belajalilija> sarcasm shouldnt be lost on an australian
03:37:53  *** geizeskrank has joined #openttd
03:39:09  <emperorjake> Yeah well, autism and sarcasm don't always mix 😛
03:39:56  <emperorjake> Back on topic, I find it interesting how like 2 people deicded the fences were better this way, and decided to change it from the original game and it's been this way for 13 years
03:50:35  <reldred> It's pissed me off for a while but not enough to do anything about it
03:51:19  <reldred> Look I'm in favor of a straight up reversion, but those sorta changes are a hard sell, for JGRPP I'll do it as an option, and then we'll wait and see what the Council decides.
04:01:03  *** greeter has joined #openttd
04:07:01  <reldred> Hmm, there's a bit going on in that commit, I'm not sure that reverting it is at all sensible, what I think I need to look into is making the new code emulate the old fence placement. Either way, I'll have a poke around it this weekend. I need to sit down and look at what the code looks like in 2025 first and see exactly what I'm dealing with.
04:13:09  <reldred> the new code also does some stuff I'd like to keep, I'll need to think about this some more.
04:36:58  *** florafex has joined #openttd
04:36:58  <florafex> emperorjake: damn, i assumed it mustve always been like that because of how bad it looks in some places lol
04:43:36  <DorpsGek> [OpenTTD/OpenTTD] eints-sy2025-03-14T05:43:33  <DorpsGek> [OpenTTD/OpenTTD] Release workflow was not successful https://github.com/OpenTTD/OpenTTD/actions/runs/13850438052
07:31:06  <truebrain> Sad
07:34:03  <_zephyris> emperorjake: There's some great ancient history, couldn't believe that random manager faces have been totally bugged for the last 18 years!
07:45:16  *** SigHunter has quit IRC
07:48:00  *** SigHunter has joined #openttd
08:02:50  *** HerzogDeXtEr has joined #openttd
08:04:36  <DorpsGek> [OpenTTD/OpenTTD] LordAro commented on pull request #13806: Codefix: uninitialized variables in fmt https://github.com/OpenTTD/OpenTTD/pull/13806#pullrequestreview-2684658053
08:17:25  <peter1138> Interesting, I think they posted pictures of the desired old behaviour, but not what the current behaviour looks like?
08:17:32  <peter1138> (Fences)
08:20:22  <reldred> Hmm?
08:21:20  <reldred> I mean I presume everyone here knows what fences in ottd look like currently.
08:21:48  <LordAro> devs don't play the game
08:22:15  <peter1138> I think I just find it easier to understand with more detail of, e.g. "this is what it looks like now" and "this is what it could look",
08:22:16  <LordAro> iirc the improvements were related to more complicated junctions than just a single intersection
08:22:43  <LordAro> the old method often added "pointless" fence triangles
08:22:47  <LordAro> iirc.
08:24:26  <reldred> Yes, but those pointless fence triangles are going to be useful for some jp+ tracks features. Anyway, I have what I need, I’m going to prototype a patch this weekend and I’ll see if it achieves the desired effect.
08:24:53  <LordAro> huh?
08:25:42  <peter1138> Railtype-specific fence placement?
08:26:46  <reldred> peter1138: Might be useful, but let me prototype something first and take some pretty pictures, then we’ll be in a better position to chin wag about it.
08:27:19  <peter1138> (Also, apparently I had full-detail turned off, so indeed, I'm not acutely aware of how fences behave in some conditions.
08:27:22  <peter1138> )
08:29:33  <reldred> Yeah, fences in the dark old days used to hug rails a lot tighter than they do now. For most rail sets and most people, perfectly fine, less silly looking triangles of fences, etc.
08:30:40  <reldred> But with full 8 directions pixel perfectly aligned fences in modern track sets we can do some cool stuff, like a grass overlay for instance. It’s kinda hard to explain with words, I’ll need to take some screenshots to explain it better but I’m in bed with a headache atm
08:30:44  <reldred> :widdle_goblin:
08:31:50  <reldred> But there’s some features of the new fence logic I would want to keep, as the new logic takes owned stations and some other bits and bobs into account that the original logic didn’t.
08:32:40  <reldred> Gimme a few hours and I’ll drag my carcass infront of the screen and make some pictures.
08:34:08  <peter1138> See, you just need to write a patch and to get the game to produce the pictures.
08:34:14  <peter1138> -and
08:36:19  <reldred> I didn’t say I wasn’t going to do that 😛
08:41:58  <peter1138> What do you mean you don't have a patch for that...
08:55:21  *** mindlesstux has quit IRC
08:56:13  *** mindlesstux has joined #openttd
08:57:49  <reldred> It’s a notional patch
08:58:01  <reldred> I have a notion of the patch I’m going to write
08:59:18  <_zephyris> I'm on the fence about fences
08:59:36  <reldred> I’m not
08:59:44  <reldred> Staunchly pro-fence.
09:01:15  <DorpsGek> [OpenTTD/OpenTTD] PeterN merged pull request #13808: Codechange: Use EnumBitSet for EdgeUpdateMode. https://github.com/OpenTTD/OpenTTD/pull/13808
09:03:31  *** Fl2025-03-14T20:53:21  <_glx_> many main quest were side quested
20:57:11  <DorpsGek> [OpenTTD/OpenTTD] PeterN opened pull request #13819: Codechange: Use EnumBitSet for AdminUpdateFrequency. https://github.com/OpenTTD/OpenTTD/pull/13819
21:01:49  *** tokai|noir has joined #openttd
21:01:49  *** ChanServ sets mode: +v tokai|noir
21:04:44  <DorpsGek> [OpenTTD/OpenTTD] PeterN opened pull request #13820: Codechange: Use more default initialisation instead of MemSetT. https://github.com/OpenTTD/OpenTTD/pull/13820
21:07:24  <DorpsGek> [OpenTTD/OpenTTD] rubidium42 approved pull request #13820: Codechange: Use more default initialisation instead of MemSetT. https://github.com/OpenTTD/OpenTTD/pull/13820#pullrequestreview-2686840407
21:08:50  *** tokai has quit IRC
21:09:41  <peter1138> Well. Seems like it'll be cold tomorrow :(
21:09:45  <andythenorth> OOF
21:18:20  <kuhnovic> _zephyris: So close haha
21:22:33  *** WormnestAndroid has joined #openttd
21:23:47  <peter1138> That's actually a thing from original TTD.
21:58:40  *** HerzogDeXtEr has quit IRC
22:00:08  <xarick> Our president is a populist kek... https://www.youtube.com/watch?v=pS22yZBYL7o
22:04:14  <xarick> too much youtube for today
22:11:37  *** ajmiles has joined #openttd
22:11:37  <ajmiles> I'm thinking about picking up my 'GPU Renderer' again, I've still got it parked in a fork for now. What would be really useful for understanding what material difference it makes to performance is an example of a very large "late-game" OpenTTD save game that would typically make a lower end machine struggle.
22:11:37  <ajmiles> Are there any publicly available examples of very large / late-game saves with which to test performance?
22:12:44  <xarick> I'm attempting to create a save with 75000 trains
22:13:00  <xarick> but graphics will be the least of the problems
22:14:00  <ajmiles> My hope is that moving all the work of blitting off of the CPU frees up time to do all the things that make that sort of late-game save slow.
22:14:50  <frosch123> For rendering performance, just use the scenario editor to create a huge town. Then zoom out and scroll
22:14:59  <ajmiles> More zoomed out views seemed to struggle the most when I was playing around with it last year
22:16:39  <frosch123> Rendering is most significant,  if you use simple graphics like default houses. Any real game with vehicles or newgrf  would grow in non-rendering tasks instead
22:17:28  <ajmiles> What is it about newgrf that causes non-rendering to scale quicker?
22:20:06  <frosch123> Newgrf take a significant amount of time to decide what to actually draw on a tile. While this could be multithreaded in theory, the current implementation still has global state, which forces single threading
22:23:41  <frosch123> Maybe we could try out `thread_local` storage classes, but I never saw them in any production code, so not sure about their gotchas. It's c++, so there are some for sure :p
22:24:36  <peter1138> There's that persistent storage patch somewhich which might've helped.
22:25:05  <peter1138> Some... where.
22:26:49  <_glx_> we use `thread_local` once (for windows crashlog)
22:31:06  <DorpsGek> [OpenTTD/OpenTTD] rubidium42 opened pull request #13821: Codefix: do not use an invalid iterator https://github.com/OpenTTD/OpenTTD/pull/13821
22:34:44  *** WormnestAndroid has quit IRC
22:34:48  *** WormnestAndroid has joined #openttd
22:35:31  <xarick> https://cdn.discordapp.com/attachments/1008473233844097104/1350235925950759106/Unnamed_4h_23m.png?ex=67d600b2&is=67d4af32&hm=8446c49f944081203b248fce8fc144b905b1c044dc0b6ed9d25b0d548a715bed&
22:35:31  <xarick> nice, but it was with 250k ops
22:36:04  <frosch123> Ideally temporary and fake-persistent

Powered by YARRSTE version: svn-trunk