IRC logs for #openttd on OFTC at 2025-01-14
⏴ go to previous day
00:39:45 <goddess_ishtar> huh openttd source is surprisingly small
01:20:44 <goddess_ishtar> where can I find `unofficial-breakpad`
01:21:59 <goddess_ishtar> okay I know a screenshot of the warning isn't helpful
01:22:26 <goddess_ishtar> I'm on Arch Linux, and I *thought* that just grabbing `google-breakpad` off the AUR would have worked, so apparently not
01:22:39 <peter1138> You do not need it.
01:22:46 <goddess_ishtar> I have never messed around with cmake before so I'm kinda out of my depth
01:23:12 <goddess_ishtar> isn't it for error reporting
01:23:55 <_glx_> cmake yells but it should finish fine
01:46:09 *** wallabra has quit IRC (Ping timeout: 480 seconds)
01:58:37 *** wallabra has joined #openttd
02:15:24 *** Wormnest has quit IRC (Quit: Leaving)
03:36:29 *** debdog has quit IRC (Ping timeout: 480 seconds)
03:57:41 *** gnu_jj_ has joined #openttd
04:01:11 *** gnu_jj has quit IRC (Ping timeout: 480 seconds)
06:09:34 *** keikoz has quit IRC (Ping timeout: 480 seconds)
06:53:12 *** D-HUND is now known as debdog
07:09:42 <_zephyris> Comment on the bug report asking what newgrf they were using...
08:24:23 <pickpacket> andythenorth: $250k a year... If I made that much I'd be set for life in a handful of years
08:24:54 <andythenorth> Not at San Francisco rents apparently
08:25:16 <andythenorth> And even in the US the tax would be a chunk
08:25:22 <pickpacket> Yeah, well. That sounds like a they problem
08:25:47 <pickpacket> I have around 2/3 of my salary left after tax
08:26:18 <pickpacket> Oh shit! I lied! I would make €65 if I worked full time, but I only work 80%
08:27:12 <andythenorth> Hmm US income tax rates really are low
08:29:55 *** Extrems has quit IRC (Ping timeout: 480 seconds)
08:32:06 <merni> They also have state income taxes
08:32:49 <merni> and maybe some even more local ones?
08:32:58 <andythenorth> found a calculator
08:33:16 <andythenorth> so $250k USD gross in California is about $156k net
08:34:01 *** Extrems has joined #openttd
08:34:12 <merni> though that is still an incredibly high salary even post tax 😆
08:34:49 <andythenorth> the tax in the UK is actually quite close
08:35:17 <andythenorth> £205k GBP -> £127k net
08:36:11 <merni> cost of living might be lower too
08:36:18 <merni> especially if you consider healthcare
08:40:32 <andythenorth> hmm total compensation gets complicated
08:40:48 <andythenorth> ok, back to train game
08:41:02 <pickpacket> andythenorth: TRAIN GAME!!!
08:41:26 <pickpacket> Whenever I'm playing OpenTTD it's a training session
08:46:28 <pickpacket> two of them? Weird
09:00:18 *** Tirili has quit IRC (Remote host closed the connection)
09:11:44 *** Speedy` has quit IRC (Read error: Connection reset by peer)
09:13:27 *** Speedy` has joined #openttd
09:27:31 <LordAro> nice work pickpacket :)
09:27:39 *** mindlesstux has joined #openttd
09:32:37 *** mindlesstux has quit IRC ()
09:33:36 *** mindlesstux has joined #openttd
09:43:59 *** akimoto has joined #openttd
09:56:43 <xarick> oh noes, a new script event
09:57:03 <xarick> aka 10 conflicts for my PRs
10:11:25 <pickpacket> xarick: why so many conflicts for that?
10:22:37 <Rubidium> to be honest I already had five files with conflicts
10:26:29 <xarick> AIAI has a weird feature
10:26:45 <xarick> which makes it constantly change president's faces all the time
10:26:56 <xarick> but I think it's a bug
10:27:11 <xarick> at least it's not the name
10:27:16 <peter1138> Something about the NewsReference PR doesn't sit well somehow. MAybe it's the storage of pointers, but we do that elsewhere anyway, so I don't know.
10:36:00 <xarick> just counted, 10 PRs with conflicts
10:42:50 <xarick> oh crap, vcpkg tools failing
10:45:01 <LordAro> looks fairly self explanatory
10:54:02 <xarick> vcpkgTools.xml - why is it looking for a file that doesn't exist?
10:57:03 <LordAro> well it probably doesn't know it doesn't exist
10:58:25 <xarick> time to reinstall vcpkg or something
11:01:27 <xarick> re-cloned, problem solved
11:22:34 <xarick> even the company itself gets the event that it changed own's name
11:23:55 <xarick> it could exclude sending the event to itself
11:24:22 <xarick> I guess you have your reasonings
11:25:33 *** akimoto has quit IRC (Remote host closed the connection)
11:25:57 <Rubidium> the GS and human players could change your name, and you might be interested in that happening
11:49:03 <xarick> eww conflicts in the regression result
11:49:25 <peter1138> That's simple. Ignore them and regenerate it.
11:50:24 <_zephyris> Lol, thought I got away with that one
11:50:57 <_zephyris> Font sizes and east asian scripts are on my mind
11:51:19 <_zephyris> Turns out the search box and message box are different things
11:51:35 <peter1138> ChillRoundF matchhes perfectly.
11:53:02 <peter1138> But the fallback font search doesn't know this and chooses something ugly instead.
12:02:24 <pickpacket> xarick: run "make regression" and you'll get a new regression output file to replace the old with
12:28:43 <xarick> lunch break, 6/10 rebased
12:28:44 <frosch123> Hmm maybe the last comment should have went into the ottd pr
12:40:14 <peter1138> Making the size itself variable seems like it would make the action 6 offsets even more fragile than they are.
12:40:36 <peter1138> Also harder for people writing plain NFO.
12:45:30 <peter1138> One of the reasons for ditching extended bytes is because NML always expands to 3 bytes anyway (as action 6 might need to modify the value)
12:46:26 <peter1138> (That is the main major incompatibility, but actually a clearly visible incompatibility is, in my mind, better than a subtle incompatibility that isn't noticed.)
12:53:00 <peter1138> JGRPP presumably has a complete existing solution already for this
13:06:38 <peter1138> Hmm, annoying, bought an album via Bandcamp and it didn't arrive, but I kinda forgot about it because you get a digital download too.
13:13:04 <_jgr_> I used an extended byte length prefix for mine, but that's no good given you want to get rid of extended bytes
13:16:04 <peter1138> Also implies that no property can be longer than 64KiB
13:17:48 <peter1138> Did you prefix every instance of the property or have separate descriptor that applies to all?
13:18:06 <_jgr_> I struggle to think of a case where a property that size would be needed
13:19:49 <_jgr_> The length prefix comes before each instance of the property data
13:20:46 <_jgr_> There is a descriptor to map properties in the first place, but that doesn't include length information, property data is not necessarily all the same length for the same property
13:26:29 <peter1138> Descriptors could allow that though, if one of the size values means the size has to be read for the property instance.
13:28:02 <peter1138> "Let's just use text files"
13:29:11 <andythenorth> [was it lunch yet?]
13:29:37 <peter1138> Today Only Maybe Lunch?
13:30:13 <andythenorth> for the record, TOML is a bad format
13:30:33 <peter1138> As is NFO and the binary GRF format.
13:30:38 <andythenorth> not a terrible format, and it's been adopted as some official python thing, but it's unsuitable for lang 😛
13:30:50 <andythenorth> we use .po files in work stuff
13:30:59 <andythenorth> some gettext thing or something, dunno
13:31:00 <peter1138> It is, or at least was, fairly compact.
13:31:20 <peter1138> I don't think gettext helps with GRF properties.
13:31:43 <andythenorth> oh you mean for the whole format, not just strings?
13:31:47 <andythenorth> wasn't it going to be xml?
13:32:05 <andythenorth> what did TrueGRF use? Some RPN format in json?
13:32:08 <_glx_> gettext has flaws too I think
13:34:07 <peter1138> Discussions about GRFv9 are about the whole thing, not translations.
13:34:46 <peter1138> IMHO external translation should just be an uncompiled text format.
13:35:05 <_glx_> Yeah simpler for everyone
13:35:09 <peter1138> In the usual layout that everyone knows.
13:35:33 <peter1138> I've done an NML patch to create the 'static' StringIDs.
13:35:41 <peter1138> Hmm, "StringID" is not the right term :)
13:35:49 <peter1138> Static string codes.
13:36:17 <_glx_> IIRC nmlc keeps a list of IDs somewhere
13:36:22 <peter1138> Sadly it means that the GRF needs to support it.
13:36:58 <peter1138> Unless we also allow translations by internal IDs used within the GRF.
13:36:59 <andythenorth> just tuna, from a can
13:37:15 <peter1138> (Which are subject to change, but for an ancient NewGRF that isn't a problem.)
13:37:59 <_glx_> MD5 of GRF on top of translation file ?
13:40:25 <peter1138> Step 1) Create an in-game UI that will list all the strings provided by the NewGRF, and allow them to be changed/added for a different language.
13:40:42 <peter1138> Step 2) Allow that interface to write out a file of all the local translation changes.
13:41:05 <peter1138> Step 3) Detect and read that file when loading the NewGRF.
13:41:39 <peter1138> Step 4) Optionally allow sharing the via to others, maybe via bananas.
13:41:56 <peter1138> So far I have got to Step 0.
13:42:10 <peter1138> It's a side-quest I shouldn't really be looking at :p
13:42:46 <xarick> I have 29 open PR's, please merge me
13:43:35 <xarick> back to my river stuff
13:43:46 <LordAro> stop opening new ones
13:44:06 <LordAro> i hope you've addressed the feedback you have got
13:44:15 <LordAro> (i know it's lacking in many of them)
13:44:30 <_glx_> and don't open PR until the work is fully done
13:44:32 <peter1138> _glx_, #13310 needs an update now :)
13:47:54 <peter1138> pickpacket, it's tea time.
13:53:37 <xarick> I only have 2 PRs with changes requested
13:53:47 <xarick> but they're a misunderstanding
14:12:43 <andythenorth> I did try to limit open PRs
14:12:52 <andythenorth> my view is that 'too many' is a burden on a project
14:13:01 <andythenorth> but failed that side quest
14:13:32 <peter1138> Does our saveload format save the size of each variable for each instance, or a descriptor?
14:13:54 <peter1138> I could close some PRs
14:15:35 <peter1138> e.g. nobody is interested in automatic 8bpp-compatibility for 32bpp sprites.
14:21:19 *** kuka_lie has joined #openttd
14:22:28 <Rubidium> peter1138: it stores some description, and those fields that have a variable size do store their size per instance (not the further type specification)
14:34:46 <peter1138> Having a descriptor for the fixed sized which only needs to be one action (or something else) that says "feature 04 property 08 is 4 bytes" and "feature 04, property 09 is variable, read a (d)word for the size" might might work. It avoids adding variable-size fields and complicated gamma-encoding, and avoids having to fill batch of byte-properties with a (d)word size of each byte.
14:35:27 <peter1138> If the descriptor size doesn't match the expected size the property can be ignored.
14:37:38 <peter1138> And if there's a descriptor, perhaps the property numbers can be set via the descriptor to: "feature 04, property "class id", num = 08, size = 4", "feature 04, property "sprite layout" num = 09, size = variable"
14:42:44 <Rubidium> you might even just dump a complete action-property-description-table in the NewGRF regardless of whether you use the properties. If it exists, then OpenTTD can skip unknown properties, otherwise it can't
14:45:39 <Rubidium> might the nfo-renum data tables be something that'd be a good start?
14:47:08 <peter1138> Hmm, unfortunately NML has 'virtual' properties so it's not a 1:1 mapping to descriptor.
14:48:08 <peter1138> nfo-renum... somewhere to look.
14:50:38 <frosch123> Is pukka the only nforenum user?
14:51:23 <frosch123> I don't think m4nfo users need it either
14:58:59 <frosch123> I also do not expect anyone updating m4nfo for grfv9
14:59:40 *** yozora3 has joined #openttd
14:59:40 <yozora3> Any chance we could change or improve the logic behind roadtypes level_crossing_status?
14:59:40 <yozora3> It's currently 0 for every tile, even if there are no crossings
14:59:44 <frosch123> So the only one having to count action0 sizes would be pikka
15:00:24 <LordAro> yozora3: sounds like a bug
15:00:25 <frosch123> Everyone else uses a compiler like nmlc or pygrf
15:01:14 <peter1138> Roadtypes are a bug.
15:01:17 <yozora3> Gonna open an issue then
15:01:30 <peter1138> It's just how the spec is... specced.
15:01:35 <andythenorth> peter1138: we're a bug
15:02:03 <peter1138> Yes but if it's a spec bug then it's not an OpenTTD bug per-se.
15:02:18 <peter1138> I don't think there's an issue tracker for spec bugs though.
15:02:42 <frosch123> It's 1 for closed crossings. What would you expect otherwise?
15:03:30 <LordAro> presumably a tri value
15:03:53 <yozora3> I expect a some ability to check whether tile is crossing or not
15:04:08 <frosch123> Why? Crossing sprites are separate already
15:04:35 <yozora3> to hide road's track_overlay for example
15:05:03 *** Flygon has quit IRC (Read error: Connection reset by peer)
15:07:24 <frosch123> Ah, I see. The crossing sprites are only separated for railtypes. Not for roadtypes
15:08:12 <peter1138> ROTSG_reserved2, ///< Placeholder, if we need specific level crossing sprites.
15:09:47 <frosch123> I guess we can change the variable to return FF for non-crossings. I don't expect that to break existing Grfs
15:11:02 <peter1138> I do. They will check bit 0, and that will be set if it's 0xFF.
15:11:53 <peter1138> Hmm, NML returns the whole byte actually.
15:13:00 <peter1138> But it'll still go wrong if the NewGRF only checks for 0, and leaves the blocked status for the default result.
15:13:06 <yozora3> bit 0 would still exist for crossings as far as I undertand, but checking if bit is 0 is nothing but meaningless for non crossing tiles
15:15:11 <yozora3> with 0 check it's impossible to change anything from the default road state, as default has always had 0 in it already
15:16:22 <yozora3> So I don't think it can break any grfs
15:18:06 <peter1138> GRFv9 doesn't change anything about variables.
15:22:22 <xarick> Help. What am I doing wrong here?
15:23:48 <LordAro> lambdas that capture variables cannot be passed as function pointers
15:26:07 <peter1138> Okay, so property descriptors implicitly have (at least) 1 downvote.
15:27:40 <andythenorth> the word soup machine
15:27:56 <LordAro> it's sort of not wrong though
15:28:08 <LordAro> but there are ways if you try hard enough
15:28:41 <andythenorth> it suggested some implementations
15:40:50 *** virtualrandomnumber has joined #openttd
15:41:01 <xarick> too bad, I was hoping to get rid of struct River_UserData
15:41:38 *** virtualrandomnumber has quit IRC ()
15:41:53 <truebrain> LordAro: You are wrong. It will result in errors. ChatGPT said so.
15:42:40 <truebrain> ChatGPT is the law of the land, didn't you hear? 🙂
15:42:51 <truebrain> or, by proxy, andy is!
15:43:13 <LordAro> that's a point, maybe i can use chatgpt to generate this build system documentation i've been tasked with writing
15:43:36 <truebrain> "maybe I can"; I am sure you can!
15:43:41 <truebrain> will it make sense? WHO KNOWS!
15:44:42 <LordAro> the issue contains both "detail how the [extremely complex] build system works" and "please tell me how to fix every possible build problem i may encounter when trying to use old versions"
15:44:54 <LordAro> i am having trouble reconciling this
15:45:09 <truebrain> train an LLM to answer the second part
15:45:19 <truebrain> spend the next 3 months on that
15:45:49 <truebrain> boo, you are no fun!
15:46:40 <truebrain> related, an cleaning robot discovered that the best way to keep a room clean is to ensure the human can't enter. To project that to your story: just ensure nobody uses the old versions, and you can skip that part of the ticket
15:46:45 <truebrain> ensuring that can be done in several ways
15:46:54 <truebrain> including locking out of all humans to the build system
15:47:06 <talltyler> Cleaning robot is Skynet v0.1?
15:47:24 <LordAro> unfortunately old versions have to be supported for up to 10 years
15:47:24 <truebrain> talltyler: no, it doesn't have general intelligence;
15:47:35 <truebrain> it is just what happens if you optimize a cleaning robot often enough
15:47:40 <truebrain> it will figure out how to keep the door closed
15:47:50 <talltyler> It doesn’t need general intelligence, just to decide that humans are a risk worth eliminating
15:48:04 <truebrain> "a risk worth eliminating"
15:48:08 <truebrain> that is just perfect to put on my wall
15:48:29 <talltyler> Sometimes I think I would make a good Skynet
15:48:41 <talltyler> Only when I’m feeling particularly pessimistic though
15:48:57 <LordAro> what a chilling sentence that is
15:49:24 <truebrain> "good Skynet" .. that is what they call a pleonasm I think? 🙂
15:49:34 <truebrain> or rather a tautology?
15:49:37 <truebrain> I always mix them up 😛
15:50:56 <truebrain> (I am trying to imply that every Skynet is "good"; but I am sure I failed 😛 )
15:51:02 <talltyler> I’ve never mixed those up because I’ve never seen the word “pleonasm” before 😛
15:51:15 <truebrain> ah, yes, that would be pleonasm 🙂
15:51:29 <truebrain> "burning fire" or "white snow" are the best examples
15:52:19 <truebrain> other examples include: "Weird LordAro", "Nice 2TallTyler", "Scary xarothbrook"
15:53:02 *** xarothbrook has joined #openttd
15:53:02 <xarothbrook> I don't often get pinged here
15:53:15 <xarothbrook> but when it is, it's always that weird truebrain dude taking the piss at me 😛
15:53:30 <truebrain> And nothing you can do about it. MWHAHAHAHAHA
15:54:27 <truebrain> okay, time for me to be somewhere not here; was fun taking the piss out of you Xaroth 🙂
16:03:07 *** gelignite has joined #openttd
16:04:10 <LordAro> something just happened
16:08:58 <peter1138> Did I `rm -r` all my PRs, branches and stashes?
16:20:07 *** gelignite has quit IRC (Quit: Stay safe!)
16:20:18 <xarothbrook> LordAro: The origin story of an evil mastermind.
16:21:25 <xarothbrook> Though at this point I think he's both pinky AND the brain
16:21:33 <LordAro> that seems reasonable
16:25:19 <andythenorth> did we get a diagnosis for him yet?
16:33:12 <ufiby> I think it's necessary to add level crossing for road and tram types. For example, crossing a level at an intersection. And more sprites, there is a base road under the intersection of the level.
16:33:25 <andythenorth> pickpacket: just anyone
16:34:33 <pickpacket> andythenorth: if it helps I've been diagnosed with different things several times. Most of them temporary
16:34:45 <andythenorth> we have a winner
16:36:59 <peter1138> I have any condition it's git-stash-itis.
16:37:29 <peter1138> Although I'm getting better, I only have 520 right now.
16:37:56 <merni> I never really understood git stash
17:24:50 *** kaomoneus has quit IRC (Quit: User went offline on Discord a while ago)
17:26:14 <kuhnovic> I miss mercurial with the patches extention, we used to use it at work. But git stash is pretty neat too.
17:34:50 <xarick> kuhnovic, wanna review some pr's?
17:38:57 <xarick> PRs for kuhnovic: #10544, #12156, #12206, #12303, #13047
17:48:00 <kuhnovic> Not at the moment, I've been sick for a week and my head is not really capable of anything code-related right now
17:48:30 <kuhnovic> But I know I've been slacking. I will have a look when I feel better.
17:56:00 <xarick> finally a partial built river in sub-tropical!
17:56:57 <xarick> remember how rivers are built: it starts from the end point to the spring
17:58:41 <xarick> the spring was initially 10110260, but it could not build past 10167802 in this case
18:01:20 <xarick> took me 4 hours to get a case
18:14:19 <xarick> hard to explain what happened
18:20:16 *** gelignite has joined #openttd
18:22:17 <xarick> green lines is what it built
18:22:27 <xarick> red lines is what it failed to build
18:23:42 <xarick> I suspect "too many open nodes"
18:24:10 <xarick> it had to do a big detour
18:25:49 *** Wormnest has joined #openttd
18:26:05 <xarick> funny that at a later point, one other river connected to it right ahead, giving the impression there was no broken point
18:40:11 <_zephyris> peter1138: 🎵 take one down and pass it around, 518 ~~bottles of beer on the wall~~ stashes in the repo to go 🎵
18:40:27 <_zephyris> I now have a love-hate relationship with make
18:46:06 <xarick> I didn't expect CircularTileSearch overhead to be so impactful...
18:47:47 *** tokai|noir has joined #openttd
18:47:47 *** ChanServ sets mode: +v tokai|noir
18:51:33 <xarick> this is how the partial river would look like had no other river connect to it by RNG
18:52:27 <xarick> your thoughts talltyler
18:53:04 <xarick> that's a partial-built river: good feature?
18:54:39 *** tokai has quit IRC (Ping timeout: 480 seconds)
19:42:22 <andythenorth> Eddi had a breadth-first river generator that produced, at least in selected cases, very nice looking river trees
19:44:39 <xarick> this one is a mix of breadth-first + aystar
19:46:49 *** gelignite has quit IRC (Quit: Stay safe!)
19:47:48 <xarick> breadth-first part finds the begin and end points
19:48:11 <xarick> aystar connects the points
19:49:14 <xarick> anyway, I think I'm onto something
19:49:35 <xarick> that artificial limit of 10000 nodes
19:49:57 <xarick> may be the reason we see less rivers now
19:52:22 *** kaomoneus9104 has quit IRC (Quit: User went offline on Discord a while ago)
19:52:29 <xarick> ``` /* AyStar callback for getting the cost of the current node. */
19:52:29 <xarick> finder.CalculateG = [](AyStar *, AyStarNode *, PathNode *) {
19:52:29 <xarick> return 1 + static_cast<int32_t>(RandomRange(_settings_game.game_creation.river_route_random));
19:52:29 <xarick> };``` this randomization certainly reinforces the need for more nodes
19:52:50 <talltyler> No, wide rivers shouldn’t just start like that. River systems start narrow.
19:57:53 <peter1138> Something tells me I better activate my prayer capsule.
19:59:57 <xarick> I need a way to count how often rivers are cancelled because of the max search nodes limit
20:00:44 <xarick> I suspect this value is not that low
20:08:26 <peter1138> Hmm, properties for 27 items without size, 133 byte action0, with size as a word, 187 bytes.
20:09:05 <peter1138> This property is variably sized, although the first value is the number of elements
20:24:31 <xarick> > [2025-01-14 20:23:59] dbg: [misc:0] _aystar_status_found_end_node: 7218
20:24:31 <xarick> > [2025-01-14 20:23:59] dbg: [misc:0] _aystar_status_empty_open_list: 0
20:24:31 <xarick> > [2025-01-14 20:23:59] dbg: [misc:0] _aystar_status_limit_reached: 2
20:24:31 <xarick> > [2025-01-14 20:23:59] dbg: [misc:0] _aystar_status_count: 7220
20:26:59 <andythenorth> hmm new MBP might arrive tomorrow
20:27:05 <andythenorth> hopefully that will improve our infra
20:27:37 <peter1138> Just replace everything with a link to JGRPP
20:29:53 <xarick> let me enable small rivers
20:32:46 <LordAro> peter1138: something i've wondered about is an "automated" method of rebasing some/all stashes
20:33:10 <LordAro> (which would obviously then remove on empty)
20:33:13 <peter1138> This mainly needs me to weed out the ones which are now irrelevant.
20:33:30 <peter1138> And often not because they are applied, but because we came up with a better way.
20:34:08 <LordAro> or perhaps just something that flags that it no longer applies cleanly
20:35:37 <xarick> > [2025-01-14 20:33:51] dbg: [misc:0] _aystar_status_found_end_node: 33066
20:35:37 <xarick> > [2025-01-14 20:33:51] dbg: [misc:0] _aystar_status_empty_open_list: 0
20:35:37 <xarick> > [2025-01-14 20:33:51] dbg: [misc:0] _aystar_status_limit_reached: 18
20:35:37 <xarick> > [2025-01-14 20:33:51] dbg: [misc:0] _aystar_status_count: 33084
20:35:37 <xarick> Out of those 18 rivers that were cancelled, 1 ended being partially built
20:37:39 <xarick> this is so difficult to debug, there's so many layers here
20:43:55 <peter1138> andythenorth, will it improve Reddit, which appears to be down.
20:44:25 <andythenorth> also I hope it's known that 'xyz JGRPP' is no different to all the 'FIRS is terrible and breaks the game' chat
20:44:36 <andythenorth> I suspect some readers think it's a serious matter
20:45:27 <_jgr_> Reddit seems to be all fine here
20:45:43 <_jgr_> (Well, the site is working, not sure all the redditors are fine)
20:46:20 <andythenorth> I feel that 'community not found' could be amplified to more contexts
20:46:46 <andythenorth> anyway, 14 cores is more than 10
20:46:57 <andythenorth> so maybe Iron Horse will compile in less than 1 minute
20:48:39 <andythenorth> will see what reality is compared to geekbench results 😛
20:48:46 <_glx_> oh nmlc will still use one core
20:49:14 <andythenorth> but the makefile has some paralellisation
20:49:29 <andythenorth> and the graphics processing
20:49:37 <andythenorth> and the single core should be a bit faster
20:50:12 <andythenorth> nmlc for Horse is slow enough that sharding the parse step across a thread pool might be worth it
20:50:17 <andythenorth> but I doubt it's simple
20:50:48 <andythenorth> Assigning Action2 registers ... 14.4 s
20:51:08 <andythenorth> wonder how much assigning registers scales non linearly
20:51:21 <andythenorth> if it has to recurse to find free IDs, it might be quite brutal
21:16:59 <_glx_> andythenorth: finding a free ID is easy (it's a pop() from the array of available IDs)
21:18:20 <peter1138> Rewrite NML in Rust?
21:19:46 <peter1138> Rewrite NewGRF into a VM?
21:28:50 *** bigyihsuan has joined #openttd
21:28:51 *** notluke2578 has quit IRC (Read error: Connection reset by peer)
21:28:51 *** brickblock19280 has quit IRC (Write error: connection closed)
21:28:51 *** peter1138[d] has quit IRC (Write error: connection closed)
21:28:51 *** goddess_ishtar has quit IRC (Write error: connection closed)
21:28:51 *** _tweez has quit IRC (Write error: connection closed)
21:28:51 *** duckfullstop has quit IRC (Write error: connection closed)
21:28:51 *** ian01223 has quit IRC (Write error: connection closed)
21:28:51 *** emperorjake has quit IRC (Write error: connection closed)
21:28:51 *** _zephyris has quit IRC (Write error: connection closed)
21:28:51 *** frosch123 has quit IRC (Write error: connection closed)
21:28:51 *** ahyangyi has quit IRC (Write error: connection closed)
21:28:51 *** DorpsGek_vi has quit IRC (Write error: connection closed)
21:28:51 *** merni has quit IRC (Read error: Connection reset by peer)
21:28:51 *** xarothbrook has quit IRC (Read error: Connection reset by peer)
21:28:51 *** liquidsnake0123 has quit IRC (Read error: Connection reset by peer)
21:28:51 *** mnhebi has quit IRC (Read error: Connection reset by peer)
21:28:51 *** belajalilija has quit IRC (Read error: Connection reset by peer)
21:28:51 *** johnfranklin has quit IRC (Write error: connection closed)
21:28:51 *** xarick has quit IRC (Write error: connection closed)
21:28:51 *** yozora3 has quit IRC (Remote host closed the connection)
21:28:51 *** bohaska has quit IRC (Remote host closed the connection)
21:28:51 *** talltyler has quit IRC (Remote host closed the connection)
21:28:51 *** bigyihsuan has quit IRC (Write error: connection closed)
21:28:51 *** florafex has quit IRC (Write error: connection closed)
21:28:51 *** kurzov has quit IRC (Write error: connection closed)
21:28:51 *** tabytac has quit IRC (Write error: connection closed)
21:28:51 *** truebrain has quit IRC (Write error: connection closed)
21:28:51 *** andythenorth has quit IRC (Write error: connection closed)
21:28:51 *** _glx_ has quit IRC (Write error: connection closed)
21:28:51 *** efessel has quit IRC (Read error: Connection reset by peer)
21:28:51 *** ufiby has quit IRC (Read error: Connection reset by peer)
21:28:51 *** telk5093 has quit IRC (Read error: Connection reset by peer)
21:28:51 *** triq55 has quit IRC (Read error: Connection reset by peer)
21:28:51 *** kuhnovic has quit IRC (Read error: Connection reset by peer)
21:28:51 *** _jgr_ has quit IRC (Read error: Connection reset by peer)
21:28:51 *** wensimehrp has quit IRC (Read error: Connection reset by peer)
21:28:51 *** michi_cc has quit IRC (Write error: connection closed)
21:29:10 *** DorpsGek_vi has joined #openttd
21:29:18 <xarick> that is a partial built river, because the pathfinder failed to connect the next segment
21:29:50 <peter1138> We lost him for a minute there.
21:29:51 *** bigyihsuan has joined #openttd
21:29:51 <bigyihsuan> bigyihsuan: like i make heightmaps with world machine, which lets me carve out river channels into the heightmap, and what usually happens is the game ignores the valley and instead veers up the bank instead when generating rivers
21:31:23 <peter1138> Didn't WASM turn out to be a complete pain to do anything with?
21:31:32 <peter1138> (Also, WASM within WASM...)
21:32:42 <xarick> what do they look like, do you have a heightmap I can see
21:33:57 <bigyihsuan> xarick: those are from this heightmap
21:34:44 <xarick> oh, I think I understand
21:35:04 <peter1138> River generation has no concept that you want rivers to flow through valleys in a heightmap.
21:35:20 <xarick> the neighbour checking doesn't weight in whether there's valleys around
21:35:39 <xarick> that should make it quite an expensive check, I could try do something
21:35:58 <peter1138> Step 1) What is a valley.
21:36:38 <xarick> there's FindSpring that kinda does that
21:36:45 <xarick> but it's just for the starting point
21:37:14 <xarick> replicating that for every neighbour check... ew...
21:38:30 *** truebrain has joined #openttd
21:38:30 <truebrain> peter1138: WASM works fine for me; it is very easy to integrate into anything, tbh. I have patches to add WASM to OpenTTD 😄
21:39:48 <truebrain> for example for terrain generation. Works rather well. Main issue is that it isn't mature enough yet. For example, to have terrain generation fast, you need to compile the WASM bytecode to something native, so execution is a lot faster (you can execute it like a VM, or execute it by compile to native). But this compiling isn't as mature yet as I would like, or it makes our binary A LOT bigger
21:39:48 <truebrain> (basically, it adds the clang compiler 😛 )
21:40:13 <bigyihsuan> here's a heightmap with more examples (the last image isn't an example of what i'm talking about, and it looks good and is what i'd like to see more of)
21:41:04 <bigyihsuan> xarick: expensive check i can see, but it's not like rivers will be generating through gameplay
21:41:19 <peter1138> Yeah, I had some native 'modules' for building terrain generators, but didn't get as far as allowing custom pipelines.
21:41:22 <bigyihsuan> like, river gen is a one-per-world kind of thing
21:41:58 <peter1138> Mainly because it's still very limited, and proper perlin is quite a bit slower than tgp.
21:43:59 <peter1138> Oof, I don't like the things that exports tbh.
21:44:08 *** nielsm has quit IRC (Ping timeout: 480 seconds)
21:44:17 <truebrain> You don't like what, sorry?
21:45:19 <truebrain> Still not sure what you refer to 🙂
21:45:19 <peter1138> But that's probably worse...
21:45:51 <peter1138> To me things like "MakeClear" and "IncreaseGenerationWorldProgress" are internal parts of OpenTTD.
21:46:23 <peter1138> Also I'm not sure what's what there, which bit is native and which bits are wasm.
21:46:34 <truebrain> Owh, this is just a proof-of-concept
21:46:39 <truebrain> I just copied most of tgp.cpp
21:46:45 <truebrain> and for some weird reason, it does MakeClear calls
21:46:49 <truebrain> they do not belong there 😛
21:47:18 <truebrain> if we would be to use WASM, you need, much like Squirrel, define your API between the two worlds
21:47:28 <truebrain> and MakeClear towards a terrain generator should not be part of that 😄
21:47:38 <truebrain> but don't let that distract from the PoC itself 🙂
21:47:47 <peter1138> Okay, so we are agreed there then. The API you exposed there was only for a quick POC.
21:47:58 <truebrain> lot more things that should be nicer 🙂
21:48:12 <peter1138> What languages are support though? Writing NewGRFs in c++ isn't going to flyu :D
21:48:29 <truebrain> There are 3 main languages that can export to WASM atm: tinygo, C++, and Rust
21:48:37 <truebrain> all other languages are a bit "meh" atm
21:48:56 <truebrain> using WASM for NewGRF also presents another issue: NewGRF is now incredibly fast, as it is tightly integrated with OpenTTD
21:49:03 <truebrain> any other solution would slow it down, most likely noticeable
21:49:34 <peter1138> Well, with the GRFv9 stuff we're looking at how it's loaded.
21:50:12 <peter1138> I suppose a WASM NewGRF definition API would be basically impossible to introspect.
21:50:15 <truebrain> anyway, this WASM was with wasm-micro-runtime. I also tried a few other WASM engines back in 2003. A lot has changed in many of those .. I might have to revisit them all 😄
21:50:22 <peter1138> 2003? That's going back a bit.
21:50:48 <truebrain> and introspect you want to do, you have to do on the border of the two worlds
21:50:59 <truebrain> so I imagine it would be as painful as NewGRFs currently are 😄
21:51:04 <peter1138> Like with NewGRF you can scan the file to find out whats in it.
21:51:26 <peter1138> With WASM you'd have to run it, and that would need a full (or mocking) implementation.
21:51:27 <truebrain> owh, that kind of introspect
21:51:38 <truebrain> no, in WASM you can leave behind a lot of information too
21:51:55 <truebrain> those `__attribute__` markers at the top, for example (in `tgp_wasm.cpp`)
21:52:04 *** kuka_lie has quit IRC (Quit: Lost terminal)
21:52:27 <peter1138> Not quite what I'm meaning.
21:52:30 <truebrain> so you don't actually have to run it to get information from it; but you need to define before hand what information you would like to get 🙂
21:52:36 <peter1138> NML allows authors to do silly things.
21:52:50 <peter1138> Such that it will happily create massive long switch changes with temporary registers and stuff.
21:53:04 <peter1138> And then authors complain its slow to compile.
21:53:10 <truebrain> for NewGRF, I don't think WASM is a good fit, mostly because you can't really compile Python to WASM (yes, you can, but it will be a 30MB WASM file, as it contains the full Python interperter)
21:53:45 <truebrain> It would more likely be a new design, if you want to make that work
21:54:03 <truebrain> it will also not deal very happily with the 15-bit variables and stuff 😄
21:54:25 <truebrain> at least, I think it would be horribly slow
21:54:28 <peter1138> Making GRFv9 more future-proof that the existing seems to be quite futile.
21:54:31 <truebrain> (compared to NewGRF)
21:54:48 <peter1138> *than the existing specs
21:56:10 <truebrain> but although WASM isn't a good fit (in my head) for NewGRF, it might be for stuff like terrain generation. It just needs to mature a bit more 😛
21:56:26 <peter1138> Like making properties self-descriptive is a bit of a bodge that might help some parsers, or forward compatibility, but that's only properties, not the other bits.
21:57:05 <peter1138> I could dig out my terrain gen bits again.
21:57:38 <truebrain> yeah, the savegame changes really helped with external tooling reading our savegames
21:57:43 <peter1138> But because it was still perlin-based, it doesn't offer much improvement.
21:57:47 <truebrain> anything similar to NewGRF would greatly help for that too
21:59:21 <truebrain> finding it in one of your, what, 400 stashes? 😛 😛
21:59:45 <peter1138> How the complete spec works means that self-describing everything is kinda impossible.
21:59:58 <truebrain> yeah ... NewGRF is a bit annoying in those regards 😄
22:00:47 <truebrain> I sometimes do wonder if it would be possible to redesign NewGRF with all the modern knowledge we have. But then I realise it will take years to build that. So meh. 😄
22:02:56 <peter1138> How to "describe" that an Action 01 reads 1 byte feature, 1 byte number of things to change, and 1 byte of the number of sprites for each thing.
22:03:16 <peter1138> Except if that last byte is a particular value, then actually you need to read another 2 bytes to get the number of sprites for each thing.
22:04:17 <peter1138> Oh, and if the number of things to change was 0, then instead you need to read another 1 byte (but it could also be 0xFF to read another 2 bytes) for the index of the first thing to change, and the same again for the number of sets again.
22:04:43 <truebrain> one thing I learnt with TrueGRF, that writing a NewGRF is challenging 😄
22:05:11 <peter1138> So the spec can list all this stuff, and it works.
22:05:26 <peter1138> But there's no way it can be self-describing.
22:05:43 <truebrain> You would need to change the syntax completely, I guess
22:05:57 <truebrain> which is .... not a goal that feels reachable 😄
22:07:30 <peter1138> We don't yet have concensus on how or if properties can be self-described. And "self-described" here is basically telling a read how much data there is so that if they don't understand it they can skip it.
22:08:33 <peter1138> And like saveload self-description, if it doesn't match OpenTTD's expectations it's not going to magically work anyway
22:08:45 *** Wormnest has quit IRC (Ping timeout: 480 seconds)
22:09:15 <truebrain> No, features don't magically appear , sadly 😦
22:09:36 <peter1138> If you can't fully understand a NewGRF then it'll either just not work, or behave differently from intended.
22:09:48 <truebrain> Readers don't always have to fully understand intent
22:09:56 <truebrain> it might also just be looking for something specific
22:09:59 <peter1138> So property size is only really useful for external readers.
22:10:02 <truebrain> Not the OpenTTD reader, mind you 🙂
22:10:11 *** frosch123 has joined #openttd
22:10:11 <frosch123> Wrt perlin: in some other project I used Opensimplex noise, which was slower but nicer
22:10:32 <peter1138> It's really what you do with the noise that matters.
22:10:32 <truebrain> the saveload stuff too: it does not directly benefit OpenTTD, but it does anyone who wants to work with a savegame for what-ever reason
22:10:58 <peter1138> The way we use it is just a plain heightmap that will always look like a perlin noise heightmap.
22:11:02 <frosch123> peter1138: It also allows increasing property sizes
22:11:03 <truebrain> (although it does benefit OpenTTD over versions a bit: it can finally skip settings etc it doesn't know 😛 )
22:11:16 <peter1138> With smaller maps it's just about okay, with large maps it's clearly obviously insufficient.
22:11:47 <peter1138> frosch123, only for fixed-size properties I guess.
22:11:55 <truebrain> anyway, time to get some sleep for me; tomorrow another long day! I hate long days ......
22:12:00 <peter1138> Which is limited in scope.
22:12:50 <peter1138> For list-based properties you just get the complete property size, not the layout of the list.
22:13:03 <frosch123> Yes. For fixed size properties, the size essentially becomes part of the property ID
22:16:48 <_glx_> for most properties it should be possible to encode size in bit 6 et 7 of property ID
22:16:52 <peter1138> Hmm, I guess switching from 32KiB chunks to (probably) 512 byte chunks isn't particularly a problem.
22:17:47 <peter1138> _glx_, that would make running out of property numbers a real concern.
22:18:47 <peter1138> For rail vehicles there'd only be 12 properties left.
22:19:14 <_glx_> yeah 63 total might be short
22:20:19 <peter1138> Anyway, I clearly misinterpreted frosch123's size idea originally.
22:20:46 <peter1138> The size is not repeated for each instance of a property, as it comes before the property number.
22:20:53 *** andythenorth has joined #openttd
22:20:54 <andythenorth> I looked away for just 2 minutes 😛
22:20:58 <andythenorth> at 20.50 uk time
22:21:17 <peter1138> For multiple instances of a variably sized property, I don't know how that is meant to work.
22:21:30 <xarick> I fancy a PR just with this, yay or nay?
22:22:20 <andythenorth> oof don't search noise function images if you have the holes pattern phobia 😛
22:22:24 <andythenorth> that I can't spell
22:22:34 <andythenorth> I might have a phobia of unspellable phobias
22:22:49 <xarick> but then NoPath wouldn't be used
22:24:00 <andythenorth> ok is it naptime?
22:24:49 <peter1138> So property 2B (cargo aging) for 3 instances could be "02 2B \w5 \w5 \w5"
22:25:15 <peter1138> Poperty 2C (cargo include list) for 3 instances would be "xx 2C ... something else ..." :p
22:25:48 <peter1138> "00 0C <value len> value <value len> value <value len> value" perhaps.
22:26:57 <andythenorth> ^ that's the PBS delay, which I don't *think *is affected by changing `path_backoff_interval` but I don't trust my test
22:27:09 <andythenorth> shared as a curiosity mostly
22:27:43 <peter1138> Unless we decide that the feature of setting the value for different instances in one action is no longer supported. (Difficult with existing NewGRFs doing it)
22:28:13 <peter1138> You should set milliseconds per tick to 1000 or something :p
22:28:55 <peter1138> Do we just give power a boost or something? :p
22:29:19 <xarick> the blue train on the left proceeded first than the blue train on the right
22:29:34 <xarick> is this what I should be paying attention to?
22:29:40 <peter1138> xarick, your Nopath change feels like changing random things because you haven't understood it.
22:29:55 <peter1138> (I certainly don't understand WHY you would weant to change it)
22:30:20 <xarick> > [2025-01-14 22:22:49] dbg: [misc:0] _aystar_status_found_end_node: 33167
22:30:20 <xarick> > [2025-01-14 22:22:49] dbg: [misc:0] _aystar_status_empty_open_list: 0
22:30:20 <xarick> > [2025-01-14 22:22:49] dbg: [misc:0] _aystar_status_limit_reached: 35
22:30:20 <xarick> > [2025-01-14 22:22:49] dbg: [misc:0] _aystar_status_count: 33202
22:30:29 <xarick> makes my debugging skills better
22:30:33 <andythenorth> the blue train on block gets a clear signal before the blue train on pbs
22:30:34 <_glx_> prop 2C has the number of values as first number
22:30:49 <andythenorth> frame-by-frame, the preceeding red trains are out of sync by ~1 frame
22:31:03 <peter1138> _glx_, yes but that's not the size of the property.
22:31:07 <andythenorth> I didn't know that not all vehicles move on every tick (I assume that's the cause)
22:31:17 <peter1138> It's part of the value.
22:31:27 <andythenorth> but that lack of sync doesn't appear to explain the PBS delay
22:31:45 <_glx_> the description could say size is in begining of the value
22:31:48 <andythenorth> probably just `path_backoff_interval` and maybe OpenTTD isn' t reading my config
22:32:02 <_glx_> for this kind of properties
22:32:23 <peter1138> And the number of elements isn't the same as the size of the elements in bytes.
22:32:41 <peter1138> It basically needs a sub-description
22:33:32 *** Tirili has quit IRC (Quit: Leaving)
22:33:33 <peter1138> andythenorth, if the speed is less than something then it will not appear to move, only its sub-sub-tile position will change.
22:34:06 <peter1138> Not all vehicles move on every tick because they might be going slower than you can "see".
22:34:31 <peter1138> (Being able to see this sub-sub-tile position would be nice for 4x extra zoom...)
22:34:57 <peter1138> But in terms of things like position hashes and collisions, that sub-sub-tile change doesn't exist.
22:35:33 <_glx_> just need to create a format able to describe B, B*, W, D, B n\*B
22:36:30 <peter1138> And OpenTTD needs to understand up to GRFv8 as well.
22:36:51 <peter1138> So it needs some kind of "if not GRFv9, pretend we read this description for this property"
22:36:55 <_glx_> the hardest part will be V
22:38:07 <_glx_> some are B n*B, there's a B n*(B W)
22:38:09 <peter1138> And then every single action needs to be self-describing.
22:40:57 <peter1138> Industry production multiplier is i=B o=B followed by i*o*(W)
22:41:27 <peter1138> And part of my change was getting rid of extended bytees to make things simpler.
22:41:32 <peter1138> This definitely does the opposite.
22:42:08 <peter1138> NFO writers will not bother I guess.
22:42:29 <peter1138> This is kinda why I prefer the idea of a separate descriptor block.
22:42:51 *** Wolf01 has quit IRC (Quit: Once again the world is quick to bury me.)
22:43:14 <peter1138> (Although that doesn't work too well for variable size structures, other than "this is the complete size")
22:44:25 <_glx_> eheh and I just had the station layouts crossing my mind
22:44:33 <peter1138> Yes, industry layouts too.
22:45:00 <_glx_> but industry layouts are in a single action 2
22:45:11 <peter1138> Property 0A says differently.
22:45:37 <peter1138> (Industry layouts, not industry tile layouts)
22:46:07 <_glx_> station tile layouts are properties though
22:46:37 <peter1138> Yes, but other than being tile layouts it's not particularly unique.
22:49:37 <_glx_> at least industry prop A size is easy to determine, the full interpretation is complex though
22:50:17 <peter1138> It's variably-sized data with a terminator, the property descriptor is basically "a binary blob".
22:50:31 *** keikoz has quit IRC (Ping timeout: 480 seconds)
22:50:34 <peter1138> And that is the same for station tile layouts.
22:50:47 <peter1138> So it's not that special still.
22:51:31 <_glx_> station prop 09/1A need full parsing to know the size
22:52:09 <_glx_> as depending on flags it may need more bytes
22:53:00 <peter1138> I don't understand. If we're defining the layout, we know the full still.
22:53:32 <peter1138> And if the format change includes the size for each property instance, then the size will be known.
22:53:41 <_glx_> industry 0A has `D size The size of the whole definition, excluding numlayouts and size` so it's possible to ignore its parsing
22:54:07 <peter1138> Unless because you know what property 0A looks like.
22:54:41 <peter1138> All the lists of labels include a size.
22:54:55 <peter1138> But you only know it's a size because it's part of the spec, not part of the property description.
22:55:37 <peter1138> In all cases these variably sized properties need to be described as a binary blob of size X bytes.
22:56:07 <peter1138> So that the reader doesn't have to know that there's a DWord because it's property 0A
22:58:53 <peter1138> Anyway, this tells me that a descriptor that says "this is a list of X-size elements" isn't all that useful, because with the list in industry prop 0A, the elements within the list are variably sized.
23:00:13 <peter1138> Doing these clearly needs one of those grammar definitions that nobody really understands ;)
23:01:24 <peter1138> Hmm, maybe not that, I don't understand...
23:07:53 <_glx_> yeah something like that could work
23:08:55 <peter1138> So for property 0A, we need to say "it's variable size", then list the property number, then include the size, then process the list.
23:09:59 <peter1138> The layout can change depending on the grf version, or the existing size stays as it, and it's wrapped up as a binary blob with another size.
23:11:22 <peter1138> WIth frosch's patch the size includes the property num, which I think is not right when you consider multiple instances being set in one action 0.
23:15:57 <peter1138> Also for compatibility with GRFv9, we need to know the property number to "inject" the property size, so the order needs to be <prop-num> <size>, not <size> <prop-num>
23:16:35 <xarick> suggestion: set _settingname_ to also display default value
23:17:36 <xarick> or i'm using the wrong command
23:26:44 <xarick> `finder.max_search_nodes = 1000 * DistanceManhattan(begin, end);`
23:26:44 <xarick> > [2025-01-14 23:25:15] dbg: [misc:0] _aystar_status_found_end_node: 33234
23:26:44 <xarick> > [2025-01-14 23:25:15] dbg: [misc:0] _aystar_status_empty_open_list: 0
23:26:44 <xarick> > [2025-01-14 23:25:15] dbg: [misc:0] _aystar_status_limit_reached: 0
23:26:44 <xarick> > [2025-01-14 23:25:15] dbg: [misc:0] _aystar_status_count: 33234
23:29:55 <xarick> it is already hard to generate a good perlin for rivers of length 1020, and then to have the aystar to also fail due to limit reached 😦
continue to next day ⏵
