IRC logs for #openttd on OFTC at 2024-02-25
⏴ go to previous day
01:03:04 *** Flygon has quit IRC (Quit: A toaster's basically a soldering iron designed to toast bread)
02:31:28 *** gelignite has quit IRC (Quit: Stay safe!)
02:46:45 *** Leopold___ has joined #openttd
02:48:25 *** herms has quit IRC (Ping timeout: 480 seconds)
02:51:46 *** Leopold_ has quit IRC (Ping timeout: 480 seconds)
02:56:44 *** Leopold___ has quit IRC (Remote host closed the connection)
03:03:35 *** Leopold_ has joined #openttd
03:18:03 *** Wormnest has quit IRC (Quit: Leaving)
03:19:21 *** Leopold_ has quit IRC (Remote host closed the connection)
03:20:35 *** Leopold has joined #openttd
03:44:20 *** Leopold has quit IRC (Read error: Connection reset by peer)
03:45:06 *** Leopold has joined #openttd
03:57:35 *** debdog has quit IRC (Ping timeout: 480 seconds)
04:03:20 *** gnu_jj_ has quit IRC (Ping timeout: 480 seconds)
04:15:09 *** Leopold has quit IRC (Remote host closed the connection)
04:16:31 <wallabra> i didnt think itd work
04:17:34 *** Leopold_ has joined #openttd
04:18:50 <wallabra> probably incurred taxes
04:30:05 *** Leopold_ has quit IRC (Remote host closed the connection)
04:33:02 *** Leopold_ has joined #openttd
04:43:14 *** Leopold_ has joined #openttd
05:19:13 *** Leopold_ has quit IRC (Remote host closed the connection)
05:21:01 *** Leopold has joined #openttd
05:47:22 *** Leopold has quit IRC (Remote host closed the connection)
05:48:24 *** Leopold has joined #openttd
06:58:02 *** Leopold__ has joined #openttd
06:58:37 *** Leopold has quit IRC (Remote host closed the connection)
07:03:54 *** Leopold__ has quit IRC (Remote host closed the connection)
07:10:28 *** Leopold has joined #openttd
07:23:58 *** Leopold has quit IRC (Remote host closed the connection)
07:24:03 *** Leopold has joined #openttd
07:47:14 *** Leopold has quit IRC (Remote host closed the connection)
07:49:55 *** Leopold_ has joined #openttd
08:06:15 <ajmiles> Hah, I didn't notice the railway track is invisible
08:07:21 <ajmiles> The only type I don't support properly yet is TRANSPARENT_REMAP when the remapped value is 0, because it looks like that involves a search through the palette for the closest colour
08:08:00 <ajmiles> Although I don't think that's why the railway track is invisible, as I'm making that case magenta right now
08:08:43 <ajmiles> Colour newspapers seem to be working
08:10:05 *** Leopold___ has joined #openttd
08:10:47 *** Leopold_ has quit IRC (Remote host closed the connection)
08:12:45 <truebrain> The struggles of implementing a driver for our graphics 😄 don't you just love it? So many things and bits and exceptions 🙂
08:13:53 <ajmiles> It's gone much easier than I expected, I'll say that
08:14:55 <truebrain> Haha, not sure that makes it better 😛
08:15:40 <ajmiles> Is it normal to get these spammed out all the time?
08:18:02 <truebrain> I don't use MSVC, but scripts do use exceptions in some places in their normal flow
08:20:25 <truebrain> Ah, yes, it says ScriptSuspend. That is thrown every command an AI does, to suspend the AI till the next tick
08:21:06 <truebrain> If it is normal that these are logged like that, no clue. They are correctly captured and handled 😛
08:23:13 <ajmiles> I just turned off printing exception messages 😄
08:35:04 *** Leopold___ has quit IRC (Remote host closed the connection)
08:36:10 *** Leopold has joined #openttd
08:37:41 <peter1138> Still cold, -1°C again. All the layers and watching for ice 😮
08:37:59 <peter1138> I should ride my trike instead but I can't keep up on that.
08:47:14 <truebrain> hmm, here it is a lot warmer
08:49:13 *** Leopold has quit IRC (Read error: Connection reset by peer)
08:50:16 *** Leopold has joined #openttd
09:04:10 *** Leopold has quit IRC (Remote host closed the connection)
09:11:03 *** Leopold has joined #openttd
09:18:33 *** chucky76 has joined #openttd
09:18:33 <chucky76> Hi, we got some troubles with RC1. In fact it looks like the protocol of admin interface has been changed. I have take a look at commits but nothing found yet. Anybody knows about it? Where can I find the changing?
09:23:21 *** Leopold has quit IRC (Remote host closed the connection)
09:25:17 <chucky76> oh, thank you for the fast response.
09:25:20 <rau117> rubidium42viaGitHub: Hmmmmmm... What about adding a hotkey to increase/decrease interface size? Ctrl + [=] / Ctrl + [-]
09:25:20 <rau117> At least this won't make things worse, and it will also be consistent with the behavior of other applications. The same browsers for example... or Factorio.
09:27:05 *** Leopold_ has joined #openttd
09:48:26 *** gelignite has joined #openttd
10:11:31 *** herms has quit IRC (Ping timeout: 480 seconds)
10:22:23 *** Leopold_ has quit IRC (Remote host closed the connection)
10:22:54 *** Leopold has joined #openttd
10:31:58 *** Leopold has quit IRC (Remote host closed the connection)
10:32:58 *** Leopold has joined #openttd
10:38:14 <andythenorth> so what's the maximum ID for articulated parts? Can't find it in the grf wiki
10:38:35 *** Leopold has quit IRC (Remote host closed the connection)
10:39:42 *** Leopold has joined #openttd
10:47:11 *** Leopold has quit IRC (Remote host closed the connection)
10:47:56 <michi_cc[d]> From the callback 16 page: "Bit 0 to 13 define the ID of the vehicle to add". 2 ^ 14 = 16384
10:48:14 *** Leopold has joined #openttd
11:13:01 <xarick> I wanna do something like FindClosestPreciseShipDepot vs the other methods
11:13:29 <xarick> to see how much it diverges from the old yapf code
11:18:27 <xarick> oh, uh... old yapf had no closest ship depot
11:20:43 *** ahyangyi has quit IRC (Quit: User went offline on Discord a while ago)
11:21:22 <xarick> meanwhile, I'm testing 10000 instances of FindClosestDepot to see how much divergence there is between Kuhnovic's method and Xarick's method with unrestricted distance
11:22:01 <xarick> ~89% of the time we found the same depot, the other ~10% we didn't
11:23:55 <xarick> but I need a method to find the most accurate version of this
11:34:07 *** gelignite has quit IRC (Quit: Stay safe!)
11:41:56 *** Leopold__ has joined #openttd
11:42:21 *** Leopold has quit IRC (Remote host closed the connection)
11:43:17 <Eddi|zuHause> and what do we learn from that statistic? sometimes there are equal pathfinding solutions, and only unrelated implementation details determine which one is chosen
11:44:41 <Eddi|zuHause> (ignoring the obvious "one algorithm is incorrect" result)
11:45:48 <peter1138> xarick: Nice, useful stat to measure 🙂
11:46:22 <peter1138> Also shows where unit-testing can be useful.
11:55:43 <xarick> there is no old yapf method for closest ship depot, but there was my old version of it before Water Regions were a thing
12:11:14 <xarick> FindPreciseDepot code :p
12:13:24 <xarick> waiting now for 10000 FindClosestDepot calls
12:17:20 <xarick> it would be more accurate if I add back the rest
12:17:39 <xarick> so tempted to add it back ...
12:37:01 <peter1138> Ah, forgot to change the commit message :/
12:48:05 *** Leopold__ has quit IRC (Remote host closed the connection)
12:50:20 *** Leopold_ has joined #openttd
13:06:57 *** Leopold_ has quit IRC (Remote host closed the connection)
13:07:27 <ajmiles> What does the threading model for OpenTTD look like? I've seen mentions around the codebase of needing to be careful about calling certain things on certain threads, so it sounds like there's more than one at least!
13:08:33 *** Leopold has joined #openttd
13:09:56 <Eddi|zuHause> most of the game logic must run in a single thread, for determinism reasons. things that run in a separate thread include: gui updates, savegame compression, cargodist, AIs
13:12:08 <michi_cc[d]> Some of the drawing, too.
13:20:58 <Eddi|zuHause> well, you could try to untangle the game logic data dependencies to try to split it into several threads, but that is a garganutan task
13:27:28 <truebrain> ajmiles: mainly for what you are doing: there is a drawing thread and a game thread. They cannot be active both at the same time. The drawing thread should never change the game state. The game thread is also doing "drawing" related tasks, like sorting of sprites, preparing the viewport, etc. So the naming is somewhat misleading.
13:28:52 <ajmiles> It looks like the work that's taking real time (issuing 1000s of graphics API calls) in the Video Driver is on the Main Thread
13:29:05 <truebrain> on the drawing thread, yes
13:29:11 <ajmiles> I have a task that could pretty easily be multithreaded (recording of those commands)
13:29:11 <truebrain> whether that is the main thread or not, strongly depends on OS and driver
13:29:33 <truebrain> most of the video driver is executed in the drawing thread
13:30:38 <truebrain> you can in theory spawn threads from the drawing thread to use more cores; just make sure they are joined before the drawing thread is released 🙂
13:31:05 <truebrain> when the game thread starts, you have no longer any guarantee of any access to the game state, including palette information etc
13:31:39 <truebrain> (which means you would need to copy all the information, which most of the time negates any advantages of creating extra threads for drawing)
13:32:09 <ajmiles> I think I've probably gathered everything I need by the time Paint comes around
13:34:24 <truebrain> a few years ago I started this splitsing up into different threads, but you find all kind of things that secretly exchanges information between game and drawing
13:34:39 <truebrain> so it is a slow progress, but an ongoing one 🙂
13:35:53 <truebrain> (as example, sprite sorting should be possible in the drawing thread, but there are a few annoying parts that still expect it to be done in the game thread 😛 )
13:36:54 <peter1138> Z-buffer could be good.
13:38:49 <truebrain> the first problem is splitting the code that does the sorting; that allows for other ways to do the sorting 🙂
13:39:04 <truebrain> JGRPP already makes this part multi-threaded; just haven't checked how 🙂
13:40:09 <truebrain> but you find out things like a global to track the current viewport that is being drawn, which is accessed in more than one place .. those lovely things. That code is not C++ yet, to say the least 😄
13:50:01 <merni> I am not sure that dock is even accessible
13:51:46 <merni> Hm, no, that's not the issue
13:52:18 <merni> occasionally more ships seem to join the dance too
13:52:45 *** Leopold___ has joined #openttd
13:52:53 <merni> kuhnovic: , is it intended that ships go in circles without declaring themselves lost?
13:52:56 *** Leopold has quit IRC (Remote host closed the connection)
13:53:14 <truebrain> are they actually lost? 😄
13:55:02 <merni> Well, they seem to have a perfectly good path to their destination, and yet go in circles in one spot
13:55:18 <truebrain> I would argue, that makes them not lost, just queued 🙂
13:55:41 <truebrain> doesn't make it not a bug, mind you
13:55:42 <merni> They are not queueing outside the dock though
13:56:10 <truebrain> maybe they are queued on the edge of a region or something?
13:56:41 <truebrain> that the local pathfinder says: nah, dock is not available
13:56:49 <truebrain> so they stick around on the edge? I dunno, just guessing
13:56:58 <truebrain> either way, it would explain why they are not lost 🙂 Just circling 😉
14:00:00 <andythenorth> oof, ran out of varact2 IDs 😐
14:00:07 <merni> Anyway it looks pretty funny
14:02:26 <merni> does that ship PF debug drawing still exist? If so how do I trigger it?
14:08:30 <ajmiles> Fixed a bug in the GPU blitter that means it now runs on AMD GPUs and not just NVIDIA ones. And even better, the AMD GPU I'm running it on is the most potato integrated AMD GPU money can buy. It has only one Workgroup Processor and the game is still rendering at ~30Hz at 4K before I've done anything to optimise it
14:09:07 <truebrain> 30Hz? That is not a lot 😄
14:10:50 <ajmiles> This integrated GPU is 500 gigaflops peak. So about on par with a discrete desktop GPU from ~2008
14:11:03 <truebrain> I think the 8bpp handles 60Hz on that with ease 😛
14:11:46 <Eddi|zuHause> "but this game is from 1994" :p
14:11:46 <truebrain> I can't believe there was a time we thought 30Hz was good .. I now have 165Hz screens, and pretty happy with that 😛 So funny how that goes 😄
14:12:19 <ajmiles> There's plenty to do with it, I'm not concerned. There's a barrier between every Dispatch now which means the machine is probably at least 10x underutilised
14:13:22 <Rubidium> just load one of Xarick's test saves and even with 165 Hz it will feel like a few Hz at most
14:13:36 <ajmiles> Late-game OpenTTD is not exactly a frame-drop free experience when you decide to *crazy* things like move the camera or zoom out
14:13:39 <truebrain> you mistake fps with ups 😛
14:13:55 <truebrain> ajmiles: just never zoom out! NEVAH 😛
14:14:02 <ajmiles> What about scrolling?!
14:15:29 <xarick> gonna try revert some changes
14:15:37 <ajmiles> Oh wait, I had the debug-layer and GPU-based validation enabled. That would not have helped.
14:15:50 <kuhnovic> merni: Not behind a computer right now, but can you check if it's the same as #8022? Are the ships trying to find a depot to service?
14:16:09 <xarick> they are heading to a dock
14:16:16 <kuhnovic> The debug drawing was removed, I do have it in a patch somewhere
14:16:31 <xarick> they're not flagged as "lost"
14:17:07 <kuhnovic> I'll try to find some time to look at it today
14:17:10 <xarick> the path is valid, even though it's doing circles
14:17:37 <ajmiles> Right, actually turn off all the debug stuff and it's ~75Hz on my 75Hz display.
14:20:13 <ajmiles> And 3ms is being spent by DXGI doing a copy from my AMD integrate GPU to the discrete NVIDIA GPU to which the monitor is attached.
14:22:59 <Eddi|zuHause> a long time ago i made it a habit to always pause before zooming out
14:26:17 <ajmiles> The main menu has railway, but my game does not. I wonder why
14:27:04 <ajmiles> I wonder if this is because these sprites have RGB
14:27:28 <ajmiles> Missing on the UI too
14:31:43 *** janciothor has joined #openttd
14:31:43 <janciothor> you produce these locomotives like cookies in a bakery, 🥞 🧇 😁 it's just a pity they don't have the same size scale as GETS. 😔
14:35:06 <xarick> right around the edges...
14:35:39 *** D-HUND is now known as debdog
14:36:26 <xarick> when it's on the bottom side, best path is going back to the right side, when it gets there, best path is going back to the down side
14:49:04 <ajmiles> It turns out if you take a GPU-accelerated blitter and then run it on the CPU using WARP - performance is not great. :tapstemple:
14:51:05 <merni> the two parallel canals confuse it?
14:53:26 <xarick> still investigating, I notice both paths have the same number of regions towards destination: five
14:53:43 <xarick> could this be a matter of costs?
14:54:15 <merni> I have only a very high-level idea of how the ship PF works :p
15:01:14 <merni> Hmm, cannot reproduce #12175
15:03:52 <xarick> well, looks like the problem is not here...
15:05:18 <xarick> seems to me it's the low level pathfinder that has a different opinion on what's the best path
15:05:28 <merni> Hm I was thinking "wtf happened to the option to shift+click to choose which depot to send to"... that's a JGRPP feature
15:07:09 <xarick> let me check what the low lvl pf says
15:07:56 <truebrain> merni: lol ... DOH 🙂
15:18:23 <xarick> high lvl pf and low lvl pf are in disagreement
15:19:53 <xarick> I wonder how Kunhovic gonna deal with this
15:22:40 <xarick> is_intermediate_destination = true, yeah, this seems to be the culprit
15:23:49 <xarick> region 53, 151 is the intermediate region
15:25:08 <xarick> the center tile of 53, 151 is grass
15:25:43 <xarick> i don't know, seems... weird to pf to a non water tile
15:25:59 <xarick> but it worked 99.99% of the time so far
15:26:35 *** Leopold___ has quit IRC (Remote host closed the connection)
15:27:42 *** Leopold_ has joined #openttd
15:32:02 <xarick> 54, 151 is the other intermediate region when the ship is on the other region, heh...
15:33:05 <xarick> the center tile of that region is probably a road or a house
15:37:24 *** Leopold__ has joined #openttd
15:38:17 *** Leopold_ has quit IRC (Ping timeout: 480 seconds)
15:39:46 <xarick> time for some paint skills
15:43:52 *** Leopold__ has quit IRC (Remote host closed the connection)
15:49:02 *** Leopold_ has joined #openttd
15:51:32 *** Leopold_ has quit IRC (Remote host closed the connection)
15:54:27 *** Leopold_ has joined #openttd
15:55:35 <xarick> what do you think of my painting skills?
15:56:47 <andythenorth> hi hi, asking for a friend
15:56:54 <andythenorth> if an nml file has 934146 lines
15:57:07 <andythenorth> and nmlc hits the concurrent varact2 ID limit
15:57:23 <andythenorth> how do I help my friend find out the cause?
15:58:09 <andythenorth> we know which vehicle triggers the error, but it's not particularly a special newly added switch chain, and it worked in a previous version
15:58:36 <andythenorth> which suggests a cause arising from other recent changes
15:58:49 *** Wormnest has joined #openttd
16:03:08 <xarick> xarick: When the ship enters the region at 54, 153, follow the yellow numbers. The intermediate region given by the high level pf is number 5, it tells the the low level pf to pathfind to the center tile of region 54, 151, forcing the ship to turn back to 55, 153, but...
16:03:08 <xarick> ... when the ship enters the region at 55, 153, follow the cyan numbers. The intermediate region given by the high level pf is number 5, it tells the the low level pf to pathfind to the center tile of region 53, 151, forcing the ship to turn back to 54, 153, repeat...
16:04:31 <xarick> perhaps a solution would be....
16:04:43 <xarick> restrict path right off the bat?
16:05:16 <xarick> considering the high level pathfinder gives the exact path, this would solve the problem
16:05:55 <kuhnovic> So it essentially keeps pinging back and forth?
16:07:41 <xarick> it's a mix of unfortunate intermediate region dictating the low lvl pf where to go
16:08:27 <xarick> it doesn't fail on the first attempt, so there's no path restricted to a corridor
16:08:30 <kuhnovic> I was afraid this could happen. Restricting the "region corridor" is indeed a way to prevent this. But it does lead to less optimal paths. That's the whole reason why I chose to restrict only as a last resort.
16:10:25 <andythenorth> I think I've just learnt about O(n) or something, the hard way
16:11:12 <merni> andythenorth: I would tell the friend the cause is having an NML file with a million lines
16:11:22 <andythenorth> in 2 lines, I've managed to make a python function take 35s that previously took about 1s
16:12:11 <kuhnovic> xarick: no time to dig into it now, but i'll try to have a look tonight. Thanks for looking into this.
16:15:08 *** Leopold_ has quit IRC (Remote host closed the connection)
16:16:33 *** Leopold_ has joined #openttd
16:18:37 <truebrain> kuhnovic: Doesn't the ship PF cache the route for a few tiles? That mostly resolves these problems fine 🙂
16:18:51 <truebrain> Once it is over the threshold, it won't go back
16:22:08 <andythenorth> hmm this is bizarre, I have a python loop that gets much faster if I time it 😛
16:22:13 <andythenorth> do we suspect PEBKAC?
16:22:34 <truebrain> Stop writing silly code? 😛
16:23:04 <truebrain> Or don't load the "only fast if you measure me" module 😛
16:23:29 <kuhnovic> Only until it reaches a new region
16:28:54 <Eddi|zuHause> i thought that module is an industry standard?
16:29:27 <andythenorth> whatever I did has stopped
16:31:01 <andythenorth> but the varact 2 IDs still run out 😛
16:31:09 <andythenorth> now I have to read 1m lines 😛
16:31:35 <Eddi|zuHause> that can usually be solved by clever reordering
16:31:55 <andythenorth> yeah that's what I tried
16:32:05 <Eddi|zuHause> unless you have crazy interdependencies
16:32:05 <andythenorth> think I've found the cause though, a switch with 220 items
16:32:38 <Eddi|zuHause> you might want to split that, then :)
16:36:07 <andythenorth> hmm this is a case for per-vehicle storage
16:36:26 <andythenorth> I have to work out a set of passenger coaches by checking all their IDs in a switch
16:36:38 <andythenorth> would be better to check a register
16:38:27 <xarick> just tested restricted corridor, it fixed the issue
16:39:02 <xarick> on the other hand, makes pf'ing even faster
16:43:29 <Eddi|zuHause> andythenorth: and the existing bit thingie doesn't work for that?
16:43:54 <andythenorth> no, because it's almost unusable
16:44:01 <andythenorth> we have covered this before 🙂
16:44:30 <Eddi|zuHause> you can check "are all of the vehicles passenger cars", or "are any of the vehicles passenger cars" with 1 bit each
16:44:46 <andythenorth> can't check the preceeding vehicle with it
16:44:52 <andythenorth> it's the most lolz grf feature I think
16:45:17 *** klote[d] has joined #openttd
16:45:18 <andythenorth> it's so almost useful, but was probably added for one specific TTDP case, I imagine in DB Set
16:45:28 <andythenorth> probably vital that it works like it does
16:45:45 <klote[d]> Hello i need some help understanding how to edit NewGRF.
16:46:01 <Eddi|zuHause> i don't think dbset uses it, i vaguely remember discussing it with george, but it already existed then
16:46:21 <klote[d]> Im trying to decompile a newgrf but i get error offset to large in sprite 0!
16:46:29 *** Leopold_ has quit IRC (Remote host closed the connection)
16:46:47 <klote[d]> Im a total noob in this dont really know where to start. and ChatGPT isnt really helping me either 😛
16:46:48 <Eddi|zuHause> which newgrf, and which version of grfcodec?
16:47:21 <klote[d]> the grfcodec that is from 2016 availible from the website
16:47:48 <klote[d]> 45555453-European_Train_Set-2022.08.28
16:47:59 <Eddi|zuHause> i'd be more worried if you said a version from 2008
16:48:16 <klote[d]> trying to edit this one i want to change the train prices and year it brings the trains
16:48:27 <klote[d]> maybe add different trains from another newgrf
16:48:48 *** Leopold has joined #openttd
16:49:36 <andythenorth> GPT only makes lies about grf
16:49:44 <andythenorth> I like GPT, but it is bad at grf
16:50:05 <klote[d]> any chance some one could explain the basics to me
16:50:05 <ajmiles> truebrain: peter1138 OK, getting awesome look numbers from the profiler for this zoomed out stress test. I loaded the same save game, zoomed out to the same place, brought up the frame rate dialog and then waggled the camera and watched the frame rate. I compared the Nightly Steam build and compared it to my local build. Is there anything about these numbers that could be misleading me or does
16:50:05 <ajmiles> this seem pretty great?
16:50:19 <Eddi|zuHause> GPT in general only makes lies, that sometimes happen to be true.
16:50:22 <klote[d]> maybe do a voice call
16:51:00 <klote[d]> I really want that train set to be compatible with FIRS industry
16:51:08 <klote[d]> i have my own server
16:53:00 <Eddi|zuHause> there recently was a discussion about technically valid grfs that grfcodec fails to handle, can you check the recent PRs, whether that applies to your grf?
16:53:51 <Eddi|zuHause> on the github repo, "PRs" are suggested changes
16:54:40 <klote[d]> So the GRFCodec that is on the OpenTTD website should be able to handle it?
16:55:59 <Eddi|zuHause> like you said, the website offers a version from 2016, that is a pretty long time ago. while grfcodec doesn't change often, it does change.
16:57:05 <klote[d]> that ones newer i think
16:57:22 <klote[d]> But it doesnt contain .exe and i have no clue how to complile that
17:00:52 <klote[d]> Hmm ok so i need visual basic to compile that and use the command make...
17:03:24 <klote[d]> chatgpt is helping somewhat lol
17:09:48 <andythenorth> hmm I think Horse has simply consumed all varact 2 now 😛
17:10:31 <peter1138> Yes, but it's ancient 🙂
17:10:32 <andythenorth> I think I hit local minima on the tradeoff with procedures using varact 2 vs. compile time
17:10:50 <merni> Euh... I guess we don't have CI for grfcodec?
17:10:52 <klote[d]> merni: Yeah but thats 2016 one that gives me a decompile error
17:11:26 <peter1138> We do but it doesn't to nightlies, and we just haven't done a release in years.
17:11:35 <merni> Maybe someone should :P
17:11:39 <klote[d]> Would be nice if they could update it
17:12:05 <klote[d]> im going to "try" to compile it...
17:12:19 <klote[d]> with the help of a payed gpt 4.0 advice 😛
17:12:57 <merni> I would not advise that. Hallucination is no subsitute for truth :P
17:13:19 <klote[d]> michi_cc[d]: No im a total noob
17:14:32 <klote[d]> Wouldnt this mean id have to rebuild the NewGRF?
17:14:39 <klote[d]> or can i edit existing?
17:15:08 <klote[d]> To decode a GRF file into YAGL, run the following command:
17:15:55 <michi_cc[d]> Don't bother with grfcodec then. A decompiled NewGRF will look like this:
17:16:31 *** brickblock19280 has joined #openttd
17:16:31 <brickblock19280> Might as well write raw grf
17:16:46 <klote[d]> i want to use those sprites and train sets T-T
17:17:10 <michi_cc[d]> YAGL is supposed to allow decompilation/compilation is a somewhat human readable format, but I haven't personally used it, so no idea how the current state of it really is.
17:17:16 <brickblock19280> Decompiling will give you the sprites which you could code again in nml
17:17:42 <brickblock19280> I think yagl is the best currently
17:17:57 <klote[d]> Yeah seems like it also specifically meant for FIRS
17:18:35 <michi_cc[d]> Always better to directly use that instead of trying some decompilation.
17:22:12 <klote[d]> Yeah google translate
17:23:51 <klote[d]> That one says i need to have python 3 and NML
17:24:23 <klote[d]> can i just use YAGL instead?
17:25:36 <locosage> it's likely much easier to understand korean than any sort of decompiled grf xD
17:33:21 <Eddi|zuHause> they say korean is the easiest writing system
17:33:56 *** gelignite has joined #openttd
17:34:09 *** Leopold has quit IRC (Remote host closed the connection)
17:35:18 <klote[d]> oh wow im looking at what truebrain is making
17:35:29 <klote[d]> browserbased NewGRF creation tool
17:35:52 *** Leopold_ has joined #openttd
17:48:08 <klote[d]> this is going way over my head lol
17:48:25 *** Leopold_ has quit IRC (Remote host closed the connection)
17:48:30 <klote[d]> Think im just going to stick with the availible ones
17:48:45 <klote[d]> Unless some one is willing to make something for me.
17:50:08 *** Leopold_ has joined #openttd
17:53:29 *** Leopold_ has quit IRC (Remote host closed the connection)
17:59:01 <LordAro> peter1138: legs are pain
18:12:49 <andythenorth> wonder if we could analyse the varact 2 useage somehow
18:13:21 <andythenorth> Horse is now so complicated, I can't manually analyse what might be consuming the IDs 😛
18:22:40 <xarick> all that added complexity I had only yields 6 more accurate results out of 10k 😦
18:35:33 <DorpsGek> - Update: Translations from eints (by translators)
18:37:31 <xarick> nevermind, it's correct
18:38:12 *** Leopold_ has joined #openttd
18:52:07 <_glx_> andythenorth: 220 different choices ?
18:53:53 <_glx_> split it, that way each subset can reuse IDs of other subsets
18:55:19 <_glx_> 10 switches of 22 choices needs less IDs than 1 switch of 220 choices
18:56:10 <_glx_> well 10+1 because you need a prefilter
18:59:06 <kuhnovic> xarick: And this is why I prefer K.I.S.S. solutions 🙂
19:00:08 <_glx_> yup simple is easier to follow too
19:02:35 <kuhnovic> "Make it easy for the next guy to fix... especially since the next guy is probably you"
19:13:03 *** Leopold_ has quit IRC (Remote host closed the connection)
19:13:51 <kuhnovic> xarick: I can confirm that restricting the PF search fixes #12176. I'm going to see if I can come up with a solution that's a little nicer than "just restrict it", as that will lead to noticeably worse paths in many cases. If I can't come up with anything then always restricting it will be the fix for now, and then a better solution can be found later.
19:15:50 <andythenorth> _glx_: yup I should, but it's not seeming to be the cause of the current ID expiry
19:15:54 *** Leopold_ has joined #openttd
19:16:11 <andythenorth> I reduced the number of items in it significantly, to no effect
19:19:34 <truebrain> ajmiles: Until you implemented everything, comparing is not all that useful ofc 🙂 only when there is feature parity it is worth talking about actual numbers 🙂 anyway, weren't you doing Vulkan? A D3D driver has already been done a few years ago, you can find that somewhere as a closed PR. Just as a "so you know" 🙂
19:19:56 <andythenorth> ok I've commented some switches out until Horse compiles 😛
19:19:59 <andythenorth> `nmlc info: Concurrent spritegroups: 255/256 ("generated/iron-horse.nml", line 352010)`
19:20:13 <peter1138> There you go, the problem is on line 352,010.
19:21:04 <peter1138> I guess action 2 ID 255 is valid? 😦
19:22:27 <andythenorth> 255 is fine, this compiles
19:22:40 <andythenorth> but only if I comment out a bunch of stuff 🙂
19:22:50 <peter1138> No, I mean in terms of increasing act 2 IDs.
19:23:30 <andythenorth> not some kind of reserved value for extended byte or something?
19:24:17 <frosch123> just move some switches before line 352010 further down, or some switches after line 352010 further up
19:24:41 <truebrain> or stop making 1 gigantic GRF, and split it up! 😛
19:25:09 <frosch123> that won't help, he will just get 4 grfs which do not compile
19:25:29 <truebrain> repeat repeat repeat 😛
19:25:34 <truebrain> 256 GRFs that won't compile!
19:26:15 <frosch123> if anyone would automate grf generation and grfid assignment, and actually consume all 4B grfids on bananas, it would be andy
19:27:51 <truebrain> klote[d]: sadly don't really have the time to work on TrueGRF, so it is in a bit of a limbo state. It should load however. It is just very limited in capability .. time as a resource, it is such a problem 🙂
19:28:19 <peter1138> 1 NewGRF file per variant.
19:36:19 *** Leopold_ has quit IRC (Remote host closed the connection)
19:44:53 <xarick> nice, more than 64k stations in a list possible now
19:50:11 <xarick> alright, I'm dropping the complexity
19:50:33 <kuhnovic> Hehe, some things are just not worth it
19:51:06 <truebrain> kuhnovic: ghehe; well, that explains why it is bouncing around at least 🙂 Wouldn't it be easier to just extend that cache a bit? As otherwise you will always end up in these edge-cases, unless your estimation function is spot-on (which it isn't, like, ever 😛 )
19:54:50 <kuhnovic> The problem is that the high level path can change completely if the next PF call is done from a region that's not on the current high level path. Not likely to happen, but it does happen as we now see. I'm now playing around with extending-the-cache-to-the-next-region-in-the-high-level-path. This still allows the low level PF to deviate and find a more optimal path, but it always has to lead back
19:54:50 <kuhnovic> to a region that's on the high-level-path.
19:56:09 <truebrain> that often is the only way around these issues, in my experience 🙂 Just remember +1 (or even +2), to avoid things going: OWH WAIT, THIS IS QUICKER 😛
19:57:13 <truebrain> in my younger years I wanted to write a perfect estimation function .. I found out that hard way that is very unlikely 😛
19:57:40 <ajmiles> truebrain: If you're talking about the D3D11 one, that was no different to the OpenGL one, it didn't blit anything, it just drew one quad at the end of the frame to combine dst/anim?
19:57:51 <kuhnovic> Hehe yeah you learn over time, often the hard way 😛
19:58:11 <truebrain> ajmiles: yup; just making sure you are aware 🙂
19:58:53 <ajmiles> Yeah, apart from being able to run on platforms where only D3D is available, I'm not sure how interesting that is
19:59:14 <truebrain> as by closure reason, for us, it is not interesting. Just more technical debt to maintain
20:01:40 <ajmiles> 32bpp I got working a few hours ago, and all the remap stuff is implemented (AFAIK) identically (with one small difference atm). The biggest miss that's left that I know of right now is the world map - I'm not sure how that draw
20:02:13 <ajmiles> I'm guessing that's either a ton of SetPixel or DrawLine
20:02:35 <truebrain> that would sound like OpenTTD 😛 But I don't know 🙂
20:03:11 <peter1138> Yeah, lots of SetPixel calls... and it doesn't pay any attention to interface scale.
20:03:33 <truebrain> pfff, interface scale is for those with too much money anyway 😛
20:11:56 <ajmiles> It's a nice change of pace working on a codebase that's relatively easy to understand and doesn't take 20 minutes to compile
20:13:26 <_zephyris> The small map doesn't scale with UI?? Uh oh, I feel a rabbit hole.
20:16:28 <ajmiles> Another one ticked off the list - probably...
20:17:01 <ajmiles> The fact that it's all SetPixel calls is definitely something. That entire Window was black without it being implemented
20:21:12 <ajmiles> Alright. Thick lines now so everyone can see their operating profit go to the moon
20:23:30 <ajmiles> Does anything other than the blitter actually need the sprite 'data' kept around after the sprite is loaded? Assuming my blitter goes off and creates GPU textures for these things, could there be a mode where the original data is deleted to save memory? Or does the gameplay logic rely on know sprite colour for some purpose?
20:25:46 <Rubidium> I'm not sure whether it still exists/is used, but some sprites were used to generate the game map
20:27:27 <truebrain> peter1138: I lack context to understand your reply there 😄
20:29:17 <peter1138> Changing the return type of the scrollbar functions caused lots of issues originally.
20:29:52 <truebrain> Rubidium: there is currently no compiler that considers an `int` 64bit as far as I know, and given the issued we had with the 16 -> 32, I doubt that ever happens 😛 so your reply confuses me a lot, and sounds more academic than practical 🙂
20:30:11 <peter1138> It still does, but that function I mentioned, along with preferring the use of iterators, got rid of a bit of that.
20:30:27 <truebrain> Ah! That is the context I was missing 😄
20:31:00 <truebrain> Honestly, I would expect these functions to be size_t 😛
20:31:30 *** gelignite has quit IRC (Quit: Stay safe!)
20:31:50 <peter1138> Some things are easier with signed values.
20:32:07 <truebrain> Anyway, as far as I know, `int` vs `int32_t` is purely implicit vs explicit with 32+bit compilers, and that was what my comment was about
20:33:36 <peter1138> (Part of the reason I did #12151 was that it was less intrusive, being so close to a release.)
20:33:53 <peter1138> ((Given the age of #8006))
20:34:16 <peter1138> But yes, it is a hack.
20:34:23 <truebrain> 8006 was more that the given developer went through all kinds of motions with the approach.. it has seen many forms 😛
20:34:53 <peter1138> Unsigned causes most of the issues, which is why size_t isn't suitable.
20:35:12 <peter1138> And int64_t is fairly excessive.
20:35:35 <peter1138> `using StorageType = int32_t;`
20:35:47 <peter1138> Then just one place to change it.
20:35:59 <truebrain> anyway, I don't really care about the size; I was purely asking: do we like `int` there, or should we go to `int32_t`, to be more clear about the datasize to everyone
20:36:02 <peter1138> Yeah, ssize_t is not standard, iirc.
20:36:14 <truebrain> but the reply I got I don't actually understand ..
20:36:21 <truebrain> which is a me-problem 🙂
20:36:55 <peter1138> The reply seems to be about changing the whole code-base to replace (u)int with specific (u)intXX_t version.
20:37:05 <truebrain> yeah, and I explicitly was not talking about that 😛
20:41:30 <truebrain> also curious about your take on that peter1138 , as we have had more of these discussions over the last few months 🙂
20:43:32 <truebrain> owh, lol `int` is even 16bit on LP32 .. lolz
20:43:43 <truebrain> I forgot about this whole int changing size debacle we had in the past 😛
20:46:49 <xarick> Error: *** b/src/pathfinder/yapf/yapf_ship.cpp:394: Trailing whitespace: ' '
20:47:54 <andythenorth> frosch123: Horse is already split into 3 grfs 😛
20:48:01 <andythenorth> ...which now won't compile 😛
20:50:02 <xarick> gotta edit my beautiful written post 😦
20:55:45 <peter1138> Funny that you made that random change... that's something I fixed years ago.
20:59:04 <xarick> post edited, it's much simpler
20:59:29 <truebrain> what would really have been helpful, if `int` wasn't defined as "at least NN bytes" 😛
21:01:09 <truebrain> ghehe peter1138 , that wasn't my code 🙂
21:01:20 *** Leopold_ has joined #openttd
21:01:30 <andythenorth> /me commenting things out and counting action 2s
21:01:35 <xarick> +362 lines -81, is that more palatable?
21:01:36 <andythenorth> goes it throw out?
21:01:45 <truebrain> so your comment still stands 🙂 Just in the wrong place 😉
21:02:03 <Rubidium> peter1138: what's wrong about EngineID? It's autoreplace_gui.cpp that explicitly casts to that before passing it to DrawEngineList
21:02:05 <peter1138> Is it in the PR too?
21:02:19 <kuhnovic> xarick: It's not the size, it's what you do with it 😉
21:02:20 <truebrain> I just replaced `int` with `int32_t`; the rest is all Rb 🙂
21:02:34 <peter1138> Autoreplace_gui is wrong then.
21:02:51 <peter1138> I guess I saw it before and didn't fix it then.
21:03:34 <xarick> there is no more teleport pathfind at the last region, and there are no more two attempts, just one
21:03:53 <xarick> and there is no more distance manhattan as last resort
21:04:17 <truebrain> You don't even have a patch for that?! 😮
21:04:39 <peter1138> Honestly, I remember seeing it before.
21:04:40 <xarick> that last one will hurt NPF
21:05:21 <kuhnovic> As long as it doesn't completely destroy NPF performance of course
21:05:50 <kuhnovic> Oh man, running a 4K scenario is no fun in debug mode. Especially with debug drawing...
21:05:50 <xarick> it won't find nearest depot as often as it used to
21:06:36 <xarick> not that it actually had any code to find it to begin with, it was just feeded the destination
21:06:58 <xarick> now it has to work for it
21:07:03 *** Leopold_ has quit IRC (Remote host closed the connection)
21:08:08 *** Leopold_ has joined #openttd
21:12:10 <kuhnovic> I was kinda wondering why you're bother to change NPF at all. I tend to just focus on YAPF and leave NPF for what it is.
21:12:45 <truebrain> Rubidium: not sure what you mean with `GetRowFromWidget` and comparing to `INT32_MAX` .. you PR changes an `uint16_t` to an `int` .. so it if would compare to an `INT32_MAX`, it would already be broken? What am I missing what you are seeing?
21:13:34 <truebrain> owh, I see what you refer to, but that is already very weird code, lolz ...
21:13:39 <truebrain> ``` uint pos = w->GetRowFromWidget(clickpos, widget, padding, line_height);
21:13:39 <truebrain> if (pos != INT_MAX) pos += this->GetPosition();```
21:13:43 <truebrain> that is just ...... wuth?
21:14:35 <Rubidium> yes it is, but that function defines INT_MAX to be returned and now you compare against INT32_MAX
21:14:50 <truebrain> so would you be fine with int32_t if I change that function to not return int, but int32_t?
21:14:54 <Rubidium> that it used to implicitly cast int to uint is another "issue"
21:15:22 <truebrain> ah, no, that is a completely rabbithole, lolz
21:15:29 <truebrain> ugh, past-us has been so sloppy in so many places 😄
21:16:24 <Rubidium> solved peter1138's EngineID 'issue', I think
21:16:57 <peter1138> Github is on a go slow for me.
21:18:09 <truebrain> and thatone has annoyed me a lot over the last few months 😛
21:18:50 <peter1138> Github does not want to show me that last push.
21:24:11 <truebrain> the sloppiness of how we pass along ints to uints and back when it comes to scrolling 😄 This will take a while to untangle 🙂
21:24:32 <truebrain> `PlaylistAdd` takes an `size_t`, but it can be `INT_MAX` 😛
21:25:11 <truebrain> also explains the many forms 8006 took 🙂
21:25:52 <peter1138> Is std::span(first, last) valid, or does it always need std::span(first, count)...
21:26:14 <truebrain> cppreference says only the second form exists
21:26:31 <peter1138> So I'm confused as to why the first form compiles and appears to run.
21:26:41 <truebrain> silent cast from pointer to size_t? 😒
21:27:04 <truebrain> owh, no, I was reading wrong
21:27:11 <truebrain> (first, last) is in the docs
21:27:33 <Rubidium> huh? Where on cppreference does it state only the second form exists?
21:27:49 <truebrain> bit too late there Rb 😛
21:27:51 <_glx_> our custom span was only (first, count) but std::span has both
21:29:06 <peter1138> I find the documentation for std::span is a bit otbuse.
21:29:27 <truebrain> What threw me off, is that it is `It first, End last` 😛
21:29:35 <truebrain> but the description lower is a bit better
21:29:37 *** Leopold_ has quit IRC (Write error: connection closed)
21:29:49 <truebrain> `Constructs a span that is a view over the range [first, last); the resulting span has data() == std::to_address(first) and size() == last-first. `
21:30:05 <peter1138> It is weird, if I look into the headers it's all templates and if constexpr...
21:30:52 <truebrain> hmm, it is `[first, last)`, mind the `)`, which isn't a `]` .. somehow my brain has issues with calling that `last`, as it is the one after last 😛
21:31:22 <truebrain> "You are the last in the line", meaning you aren't part of the line
21:33:38 <peter1138> Ah, I think it was fixed in my scrollbar iterator branch, which was... waiting for std::span.
21:33:44 <peter1138> However, that is a big patch.
21:33:50 <ajmiles> Ah I need to find somewhere with dashed lines...
21:34:00 <peter1138> And also std::span does not work with anything other than vectors or arrays, which is a bit pants.
21:34:21 <truebrain> like what doesn't it work with that you want it to work with?
21:36:10 <truebrain> odd, I thought std::span didn't care about the type. Annoying 😦
21:37:29 <truebrain> funny how much nicer that looks 😄
21:37:31 <peter1138> Ouch. I just stabbed myself in the cheek with my thumb.
21:38:40 <peter1138> Probably the first loop (the one that uses std::span()) could use a algorithm of some sort, but my brain isn't working for that yet :p
21:39:43 <xarick> the npf comment is misleading too 😦
21:40:05 <peter1138> Annoying thing about that code: it's possible to omit the `*` before `this->vscroll[side]` and... it still compiles.
21:41:25 <_jgr_> peter1138: The previous custom span wouldn't work with those either
21:41:27 <truebrain> peter1138: so why not make it `const Scrollbar sb`? 🙂
21:41:46 <_jgr_> Neither of them use contiguous spans
21:41:52 <peter1138> _jgr_: I'm aware, which is why I hadn't already used our custom span 🙂
21:42:12 <peter1138> truebrain: And pass a copy of it? Hmm.
21:42:27 <truebrain> did not check how big that struct is 😛
21:43:24 <peter1138> It has 5 member variables. It's not huge but also not nothing.
21:43:34 <truebrain> yeah. that is a bit big 🙂
21:44:29 <xarick> dear ppl fixing Scrollbar limits: I plan to have 1 million stations, make sure the list can list 1 million stations, kekeke
21:45:21 <peter1138> We should use int20_t then, so the limit is less than 1 million.
21:46:33 <peter1138> Have fun rearranging the map array to support more than 65535 stations though 🙂
21:46:49 <truebrain> I read the other day someone is reviving newmap
21:48:21 <kuhnovic> xarick: if you feel like it, a bit of AI torture testing #12181 wouldn't hurt 😇
21:49:07 <peter1138> 1044k instead of, say, 1M.
21:49:27 <kuhnovic> "Motivation: Buoy" seems like a weak argument nowadays
21:50:02 <peter1138> But also, 1M stations... that sounds like a recipe for another load of pool iteration performance enhancements :p
21:50:47 <kuhnovic> I thought you liked a challenge 😛 ?
21:53:27 <peter1138> I still need to somehow create a savegame with more orders than vehicles... Hmm.
21:53:49 <truebrain> haha, that is a nice solution peter1138 (in 12178); and yes, if we want to backport this, it should be kept as small as possible 😄
21:55:34 <peter1138> Later, rather than checking for INT_MAX or INT32_MAX, we can check for `Scrollbar::out_of_range` or something a bit more standard and it makes it clear what is going on.
21:55:50 <truebrain> more C++-ification!
21:56:32 <peter1138> Well, I like the iterator approach as well.
21:57:11 <peter1138> Like in #12180 which I need to look at because it has a red X 😦
21:57:59 <truebrain> I am a bit surprised, but I guess I shouldn't, why no compiler warns about our random int -> uint conversions 😛
21:58:06 <peter1138> > no viable constructor or deduction guide for deduction of template arguments of 'span'
21:59:48 <truebrain> always that one target 😦
22:00:22 <Rubidium> I'll await #12180 before continueing on #12178
22:01:26 <truebrain> back to the old way of working! BECAUSE THAT WORKS 😛
22:01:31 <peter1138> `std::span(first, extent)` might have worked but I can't be bothered to check.
22:02:44 <peter1138> It's still iterators as least 😄
22:03:47 <peter1138> Maybe I should make a function of the first/last bit as I have a feeling that's useful elsewhere.
22:14:26 <klote[d]> truebrain: Ah thats a bummer... things like this would make Developing new content or adjusting existing content so much more accessable to people
22:14:38 <truebrain> it is why I started the project 🙂
22:15:20 <truebrain> it is only a lot, and I mean: a lot, of work 🙂
22:15:31 <klote[d]> Yeah i understand lol
22:16:11 *** nielsm has quit IRC (Ping timeout: 480 seconds)
22:19:02 *** keikoz has quit IRC (Ping timeout: 480 seconds)
22:19:04 <klote[d]> Has any one tried making a API connection with things like APIgtp
22:27:34 <andythenorth> failed to rearrange my action 2s so far 😛
22:28:11 <peter1138> More code but reusable.
22:30:11 <truebrain> peter1138: looks fine to me. Isn't there some C++ syntax for the `GetIterators`, I only wonder?
22:30:39 <andythenorth> ach 62 global switches handling sets of colours
22:30:44 <andythenorth> wonder how much they're the cause of the issue
22:31:33 <andythenorth> not a quick one to test 😦
22:31:43 <peter1138> Possibly ranges, but that is too new.
22:31:55 <peter1138> But yeah, my knowledge here is lacking.
22:32:37 <peter1138> There's probably some extra modern C++ stuff that will ensure that container is actually a container...
22:32:58 *** Wolf01 has quit IRC (Quit: Once again the world is quick to bury me.)
22:33:04 <truebrain> and also making it std::span compatible etc? 😛
22:34:00 <andythenorth> ach the 62 colour sets all resolve via one global switch, so those are fine
22:36:02 <peter1138> Well you can pass first, last to std::span.
22:36:15 <truebrain> MacOS told you "no" earlier 😛
22:36:35 <peter1138> `std::span(first, std::distance(first, last))` probably works
22:36:55 <truebrain> but that is weird ... C++20 says (first, last) should also work 😛
22:36:59 <truebrain> given some constraints on last
22:37:27 <peter1138> In this case it's fine, I didn't actually need a span.
22:37:39 <truebrain> still weird, that we are actually C++20 😛
22:37:49 <truebrain> from C++11 to C++20 in how many years? 😄
22:42:49 <andythenorth> pfff....another expected candiate for high varact 2 use...makes no difference 😛
22:42:56 <andythenorth> hard to know what nmlc is doing behind my back 🙂
22:43:27 <andythenorth> turning off bits of the grf...or re-ordering it...doesn't yield much
22:43:38 <andythenorth> nmlc must be quite good at optimising varact 2 use?
22:49:02 *** Leopold_ has joined #openttd
22:49:56 <andythenorth> oof rearranging articulated parts callback squeaks in
22:50:06 <xarick> back, ok let's torture 12181
22:50:10 <andythenorth> so the thing that was failing to compile now works, with 252 / 256 IDs
22:50:47 <andythenorth> I had a big graphics chain switch in between the callbacks block and the varact 2 handling the articulated parts
22:56:18 <andythenorth> 222 / 256 if I turn off some stuff
22:59:47 *** Leopold_ has quit IRC (Remote host closed the connection)
22:59:49 <andythenorth> ok found a switch I can shard 😄
22:59:52 *** Leopold_ has joined #openttd
22:59:57 <andythenorth> always nice to spend a few hours unpicking this stuff
23:13:33 <xarick> my excelent debugging skills!
23:14:01 <xarick> so it happens more often than 0.01% apparently
23:16:54 <xarick> I need a bigger sample, gonna try 1 million
23:25:59 <xarick> but which of these would result in a ship doing circles?
23:26:36 <xarick> how would I conveniently test this case without visually inspecting
23:28:20 <xarick> i have so many ships, even 1 million is too little
23:44:46 *** ChanServ sets mode: +v tokai
23:50:43 <xarick> okay, im off to bed, goodnight
23:51:25 *** tokai|noir has quit IRC (Ping timeout: 480 seconds)
continue to next day ⏵
