IRC logs for #openttd on OFTC at 2023-08-28
β΄ go to previous day
00:14:10 *** agneli has quit IRC (Remote host closed the connection)
02:11:46 *** debdog has quit IRC (Ping timeout: 480 seconds)
02:21:16 *** Wormnest has quit IRC (Quit: Leaving)
02:27:45 *** D-HUND is now known as debdog
07:31:46 <andythenorth> hmm, could we add a fly-under, like an inverted bridge?
07:32:01 <andythenorth> it would save 1 tile at each compared to slope + tunnel + slope
07:34:20 <andythenorth> maybe they'd be too niche
07:41:58 <andythenorth> bridge is more space efficient, but can't bridge over stations etc
07:42:46 <_zephyris> andythenorth: Sounds like you just described a fun gameplay choice.
07:43:57 <andythenorth> I don't find the arbitrary limits very interesting
07:44:12 <andythenorth> but it hasn't bothered me enough to switch to JGRPP
07:45:51 <_zephyris> Perhaps, but for the 'crazy junction' and 'crowded map' type player the game is essentially a tile placement problem solving challenge, and removing choices makes that less fun.
07:46:26 <andythenorth> we'll see what the stats say, but I think those players all switched to JGRPP anyway π
07:46:38 <locosage> andythenorth: can do this
07:46:59 <andythenorth> but isn't all this solved already?
07:47:04 <andythenorth> build on tunnel entrances
07:47:07 <andythenorth> custom bridgeheads
07:49:11 <andythenorth> I could just build less densely
07:49:35 <andythenorth> it's not like I've filled the map π
07:53:25 <brickblock19280> andythenorth: Not possible in openttd for all I know
07:54:04 <andythenorth> must be possible in JGRPP?
07:56:04 <brickblock19280> I do which it was tho
07:56:23 <andythenorth> I feel like I have seen it
07:56:51 <brickblock19280> Jake Photoshoped it
07:57:31 <andythenorth> maybe it was only Patch
07:58:54 <andythenorth> oh JGRPP can build bridges over stations, which solves it differently
08:00:12 <emperorjake> Tracks over tunnel entrances was only ever a TTDP thing
08:00:48 <andythenorth> I can't get custom bridgeheads to work
08:01:26 <emperorjake> Enable the setting
08:05:50 <andythenorth> I thought custom bridgeheads let you build bridge anywhere?
08:18:30 <emperorjake> Bridge has to be built first
08:18:37 <emperorjake> then you can drag the rail across it
08:19:44 <andythenorth> I was holding ctrl
08:19:50 <andythenorth> in the expectation that would make it work
08:20:31 <andythenorth> that's remarkable
08:25:21 <andythenorth> every time I try JGRPP it requires explaining to me by the discord channels
08:25:47 <andythenorth> also I don't know how it works if I switch to making JGRPP-only grfs
08:25:47 <belajalilija> Auto separation is what got me into jgrpp
08:25:58 <andythenorth> I quite like having some of the most popular grfs
08:26:01 <belajalilija> Everything else is just a cherry on top
08:27:03 <brickblock19280> There isn't really a reason to make jgrpp exclusive grfs I use jgrpp but make regular grfs
08:27:18 <andythenorth> articulated ships
08:27:21 <andythenorth> bridges over stations
08:27:34 <brickblock19280> andythenorth: That wouldn't be the case if you played regularly
08:27:36 <andythenorth> extended object placement
08:28:31 <andythenorth> extra station names from industries
08:30:05 <brickblock19280> Isn't that vanilla?
08:30:56 <brickblock19280> I know jgrpp has a separate feature for more station names but it's not from industries
08:35:47 <emperorjake> andythenorth: Those don't require special GRFs, there's a setting to build bridges over any station tile
08:36:15 <emperorjake> but the option to officially support it is there
08:36:20 <brickblock19280> I thought that was for objects and that it worked regardless
08:36:48 <emperorjake> There's a special version of ISR on the forums that supports it
08:36:52 <andythenorth> relative scope for vehicles
08:37:06 <emperorjake> but nobody uses it because you can just override it anyway
08:37:30 <andythenorth> there are 3 reasons I haven't switched to JGRPP
08:38:05 <andythenorth> 1. to keep Mac support on vanilla, somebody has to be using vanilla on a Mac. And JGRPP depends on upstream supporting macOS.
08:38:17 <andythenorth> 2. every time I touch JGRPP new features, I break something
08:38:56 <andythenorth> 3. I don't like the idea of tying all the grfs to a patchpack maintained by only one person. When we had only one active maintainer for vanilla, that was a bad time.
08:39:44 <andythenorth> but the grf spec additions alone are starting to make it look compelling
09:05:11 <_jgr_> andythenorth: That's kind of the nature of experimental features
09:06:43 <_jgr_> andythenorth: Most of the GRF stuff I've added is intended to be used with feature detection, so you can fall back to just not using it on vanilla
09:08:44 <locosage> There is 1 reason I haven't switched to JGRPP
09:08:44 <locosage> 1. CityMania client π
09:17:54 <andythenorth> _jgr_: tends towards complicated π
09:18:06 <andythenorth> like when we used to have TTDP / OpenTTD support in one grf
10:22:08 *** virtualrandomnumber has joined #openttd
10:22:29 *** virtualrandomnumber has quit IRC ()
10:50:27 <truebrain> vcpkg broke Python3 again π¦
11:08:33 <truebrain> I am happy we cache vcpkg, as how often they broke python3 now, that is just annoying
11:16:31 <truebrain> what did you do? π
11:19:03 <peter1138> Nothing compares 2 u
11:19:20 <LordAro> well, my legs don't hurt
11:22:48 <Eddi|zuHause> don't stop me now
11:24:37 <truebrain> Im having such a good time, Im having a blast
11:25:56 <peter1138> So many cars queueing to get into the zoo
11:26:15 <truebrain> visiting family? (sorry, someone had to)
11:27:32 <peter1138> 3km of road either side just... queueing
11:29:24 <peter1138> We're all animals. And just like my real visits, mine was a flyby :p
11:54:41 <truebrain> I am really surprised how easily vcpkg breaks .. I don't think x64-linux is part of their testing framework π
11:55:27 <truebrain> in other news: building a rust application takes ~10 minutes ... I better be caching! π
11:55:49 <truebrain> (I need a tool on the CI to create symbol files .. which is a rust application .. so you install that, but it takes 10 minutes on GitHub π )
12:00:48 <truebrain> hmm .. also, breakpad doesn't work on windows-arm64 ..
12:00:57 <truebrain> guess I need to add the dbghelp.dll fallback after all
13:03:39 <truebrain> ugh ... fixed one vcpkg issue to run into the next ... the gitlab on freedesktop.org is not responding ..
13:08:37 <truebrain> well, tonight I have some PRs to fix some CI related things, including the failing of the current nightly π
13:08:44 <_glx_> sentry doc about symbols server is very nice
13:09:07 <_glx_> and I can see breakpad and symstore use the same path structure
13:10:34 <truebrain> yeah, their docs finally explained to me how things worked π
13:10:45 <_glx_> oh nobody told us nightly were broken
13:11:04 <truebrain> that is how the cookie crumbles π
13:11:10 <truebrain> I am testing a fix atm π Takes .. 20 minutes or so π
13:12:12 <truebrain> MacOS symbols and Windows symbols are looking good ... I just can't test Linux atm, as freedesktop decided to go on a journey without us π
13:15:51 <truebrain> currently still testing the last one, but at least I already wanted to PR it π
13:17:15 <truebrain> oof, searching for "gitlab freedesktop down" was a bad idea π
13:17:19 <truebrain> they are not having the best years π
13:17:30 *** HerzogDeXtEr has joined #openttd
13:19:30 <andythenorth> hmm generating CHIPS stations out of the FIRS compile?
13:19:33 <andythenorth> will I regret it
13:19:47 <andythenorth> I want sprite reuse
13:31:16 *** Kitrana has joined #openttd
14:16:58 *** Kitrana has quit IRC (Quit: Leaving.)
14:23:11 <truebrain> okay, my fix for Windows ARM64 works; so when approved, the nightly will succeed π
14:48:27 <peter1139> Hmm, awkward, there's no browser-source plugin in Debian's obs-studio.
14:48:40 <peter1139> Not that I particuarly *need* it but still...
14:57:02 *** gelignite has joined #openttd
15:57:54 *** Flygon has quit IRC (Quit: A toaster's basically a soldering iron designed to toast bread)
15:59:46 <peter1139> I wonder if andythenorth is near
15:59:50 <peter1139> Probably not by now
16:23:55 <peter1139> Map men map men map map map men men
16:25:58 <andythenorth> J0anJosepviaGitHub: I am elsewhere
16:26:17 <andythenorth> peter1139: I am elsewhere by now
16:26:26 <andythenorth> via the magic of the M4
16:26:36 <peter1139> The sigils of the motorway system.
16:30:00 <andythenorth> shades of Lotus Turbo Esprit
16:41:06 <andythenorth> ok will 11141 apply to JGRPP cleanly π
16:41:50 <andythenorth> oh I don't have upstream set as remote π
16:46:29 <truebrain> owh, the gitlab of freedesktop is back online .. quick, let's fill my local cache!
16:46:45 <_glx_> expected, JGRPP doesn't use same command system as vanilla
16:51:20 <andythenorth> quite a lot of conflicts
16:51:24 <andythenorth> ` both modified: src/date_type.h
16:51:24 <andythenorth> both modified: src/linkgraph/linkgraphjob.cpp
16:51:24 <andythenorth> both modified: src/linkgraph/linkgraphschedule.cpp
16:51:24 <andythenorth> both modified: src/saveload/saveload.h
16:51:24 <andythenorth> deleted by us: src/table/settings/linkgraph_settings.ini`
16:54:49 <truebrain> I made a PR for vcpkg ... their CI is already running for over 4 hours validating it .. and I thought out times were already nearly impossible to work with π
16:55:14 <_jgr_> andythenorth: When it's merged into vanilla, I'll merge it into my branch as well
16:55:51 <andythenorth> I was going to switch my savegame to JGRPP, but it depends on 11141 π
16:56:15 <andythenorth> going to switch the boat grf to JGRPP only
16:57:20 <andythenorth> do I need an nml fork?
17:00:16 <_jgr_> For multi-cargo ships, yes
17:00:40 <_jgr_> If there is dev interest I can look into upstreaming it
17:04:48 <_jgr_> andythenorth: Yes, that's it
17:05:09 <andythenorth> is there anything I should be aware of before I install this for my grf-dev env?
17:05:13 <andythenorth> should I isolate it?
17:05:23 <peter1139> Keep it in a separate branch :p
17:05:32 <andythenorth> git has this 'fork' thing π
17:05:48 <peter1139> Forking your own work is kinda weird, but okay.
17:08:34 <andythenorth> oh you mean the grf?
17:12:34 <peter1139> Hmm, GPU temp dropped from 57Β°C to 41Β°C by... turning the fans on :p
17:12:41 <peter1139> Of course, it sounds like a vacuum cleaner.
17:13:08 <truebrain> lol .. not modulated fans? π
17:13:09 <Eddi|zuHause> why would you do that?
17:14:43 <peter1139> The default is automatic, fans are off as it's idle.
17:15:17 <truebrain> My GPU runs 61 degrees when idle (fans off)
17:15:29 <truebrain> such a waste of energy
17:16:18 <Eddi|zuHause> my games are usually CPU heavy, not sure if i've ever had full load on my GPU
17:17:20 <Eddi|zuHause> currently my CPU is 60Β°C and GPU 55Β°C with customized fancontrol settings
17:23:33 <belajalilija> now get out of my head
17:23:47 <belajalilija> this annoys me enough lmaop
17:28:37 <alfagamma_0007> How does that annoy someone ?
17:29:47 <andythenorth> my makefile is tied to a specific nml
17:30:55 <_glx_> andythenorth: your makefile is tied to a specific system π
17:31:20 <andythenorth> it has to know the path to a specific nmlc
17:31:33 <andythenorth> I guess I teach it the jgrpp nmlc
17:32:26 <andythenorth> hmm I just did a bad thing
17:33:35 <andythenorth> copying a venv doesn't achieve much π
17:33:43 <andythenorth> all the shebang paths remain the same π
17:39:32 <peter1139> !pling was so much easier
17:39:59 <alfagamma_0007> There's a bit command for that?
17:40:19 <alfagamma_0007> I thought you had to visit pling on your own
17:43:04 <peter1139> I'm talking about RISC OS :D
17:48:59 *** Kitrana has joined #openttd
17:49:16 <andythenorth> nmlc regressions fail
17:49:53 <andythenorth> setuptools also fails, but that's...hardly unusual
17:50:56 <andythenorth> _jgr_: are failing tests expected?
17:51:52 <_jgr_> I'll update the file later
17:52:17 <andythenorth> `make -i` perhaps?
17:52:23 <andythenorth> I've never done that before
17:54:47 <_jgr_> NML is python, so you don't need to do any build step
17:56:15 <andythenorth> I have no clue how to install a python program π
17:56:27 <andythenorth> I always use make install to copy it to my venv
17:57:49 <_jgr_> I've aware of the idea of venvs but don't see why you'd need to use one of those
17:58:21 <_jgr_> You can just use a symlink if you build script expects it in PATH
17:59:12 <andythenorth> venvs provide isolation
17:59:17 <andythenorth> and different pythons
17:59:33 <andythenorth> the alternative is a lot path aliases for python311 python39 etc
18:01:00 <_jgr_> Scripts which depend on a particular point release of python doesn't sound like a good time
18:02:50 <peter1139> (Or rather, no not nice)
18:02:56 <truebrain> I always what make people throw away the PR template ..
18:03:00 <truebrain> "this must not be for me" π
18:03:41 <peter1139> Commit message style too. It's so hard to see how every single one (well, mostly) of our commit messages is formatted...
18:04:12 <truebrain> w00p, symbols are generated and saved π On average it is 60MiB in size, and includes most hints for most inline functions .. only exception, MacOS. That is only 30MiB for some reason
18:04:16 <andythenorth> _jgr_: OpenTTD isn't the only project I use python for, and large projects often require specific python versions
18:04:21 <andythenorth> due to pinned deps etc
18:04:35 <andythenorth> anyway ship time π
18:05:22 <peter1139> With that, each station uses an additional 9KB :D
18:05:25 <peter1139> I suppose it's not much.
18:05:46 <truebrain> I mostly things it needs a better motivation other than: I ran into a limit
18:05:52 <truebrain> as the next one is right around the corner
18:05:58 <truebrain> we can't keep on bumping the bits in the storage π
18:08:00 <andythenorth> arbitrary number of cargos?
18:08:50 <truebrain> hmm, fmt::format incapable of formatting `NewsReferenceType` for dedicated server, but works for others ... what include am I missing ...
18:09:07 <peter1139> typedef uint64_t CargoTypes;
18:09:07 <peter1139> typedef uint128_t CargoTypes;
18:09:09 <peter1139> static const CargoTypes ALL_CARGOTYPES = (CargoTypes)UINT64_MAX;
18:09:18 <andythenorth> just make it 65k
18:09:30 <_jgr_> 64 is already well into diminishing returns
18:09:33 <truebrain> they is new to coding; so I forgive most of the mistakes made π
18:09:45 <truebrain> the saveload is also not actually working etc π But that is all fixable
18:09:51 <truebrain> the principle issue is the biggest concern π
18:13:32 *** Wormnest has joined #openttd
18:19:36 <andythenorth> 65k seems to be the number where you have to be trying really hard to exceed it
18:19:49 <andythenorth> would require AI generation of assets or something
18:20:05 <truebrain> let's see if I worded it a bit nicely π
18:20:16 <truebrain> hard to explain: this is so much more complicated! π
18:20:42 <andythenorth> also at some point, cargos are a UI problem
18:21:04 <truebrain> I already think 63 is a number no sane human can comprehent π
18:21:13 <truebrain> a "because we can" is not always a good argument π
18:21:57 <andythenorth> I found 63 quite a nice number
18:22:03 <andythenorth> haven't really needed more
18:22:09 <andythenorth> how many cargos in minecraft though?
18:22:25 <truebrain> `"grfs": "crashed while gathering information",`
18:22:38 <truebrain> okay, this crash detection and recovery in crashlog handling works really well
18:24:00 <andythenorth> Seems minecraft has about 800 cargos. That sound correct? I've never played it really.
18:24:11 <truebrain> those are not "cargos"
18:24:25 <truebrain> not in any sense of the word
18:24:36 <truebrain> better compare it with Factorio, if you so want to π
18:24:59 <truebrain> comparing it to Minecraft feels like saying: but a dictionary also has NNN words π π π
18:25:33 <_jgr_> Ideally, it wouldn't be necessary for every single flow to need it's own cargo type
18:26:52 <andythenorth> anyway 65k or bust π
18:32:04 <peter1139> Well, I haven't played a game that benefitted from more than ~ 20 cargo types, tbh.
18:34:09 <truebrain> I have a hard time understanding how a human has to process the above list π Feels it is something that works for a very small group of players π (which is okay, ofc)
18:35:57 <peter1139> Power-crazed dev rejects every PR!
18:38:14 <DorpsGek> - Update: Translations from eints (by translators)
18:40:36 <LordAro> truebrain: if nothing else, seems like thst PR has revealed a couple of cases where constants could be defined in terms of another
18:40:59 <truebrain> so now I expect PRs from you to address those π
18:41:23 <peter1139> The perils of accidentally volunteering.
18:42:10 <truebrain> bit annoying diff, as a lot of functions moved; I wondered if I can make it easier to review, but haven't found it
18:43:09 <andythenorth> truebrain: start with Coal, keep going, same as original π
18:44:14 <truebrain> besides the moving functions, the diff is actually pretty small .. that is nice π
19:22:30 <truebrain> the f is also equally weird
19:22:56 <truebrain> that red banner on the blue screen
19:25:25 <andythenorth> is there a way to see each hold in vehicle info?
19:28:14 <peter1139> truebrain, yeah... that's... a style.
19:28:45 <truebrain> a horrible one, but to each their own π
19:31:12 <_jgr_> Probably someone had a whole lot of budget that needed to be spent somewhere π
19:32:20 <truebrain> on FF0000 vs 00FF00 ?
19:32:24 <truebrain> that person should be fired, honestly π
19:32:52 *** HerzogDeXtEr has quit IRC (Read error: Connection reset by peer)
19:33:43 <andythenorth> multipart ships don't persist refits across autoreplace, yes?
19:33:58 <andythenorth> similar issue to other articulated RVs?
19:35:10 <_jgr_> It's on my list of things to look at, but I haven't got round to it yet
19:35:37 <andythenorth> think trains have the same issue, it's why Horse only has one multi-cargo articulated vehicle
19:39:38 <andythenorth> if I don't guard that callback, vanilla openttd will just get `unknown callback` from the grf I guess?
19:41:43 <andythenorth> surprised, when I use other unknown callbacks I usually get a warning
19:42:49 <_jgr_> It's only properties and variables which cause a problem when used on versions of the game which don't know about them
19:43:02 <_jgr_> Unknown callbacks, just won't be called
19:44:48 <peter1139> You and your fictional warning messages...
19:45:55 <_jgr_> My NML branch inserts the relevant action 7/9s around anything which the standard spec would not be able to handle, so you shouldn't get any unreadable error messages if you load it in vanilla anyway
19:46:31 <_glx_> truebrain: and we complain about MinGW
19:46:47 <truebrain> yeah ..... we have a Dutch saying: "baas boven baas", which applies here
19:47:03 <andythenorth> peter1139: I think I live in a hallucination
19:51:57 *** gelignite has quit IRC (Quit: Stay safe!)
20:01:20 <_glx_> #11243 looks like it's fully coded via github
20:01:32 <truebrain> haha, yeah, I noticed the same π
20:01:37 <truebrain> maybe via Codespaces?
20:01:59 <truebrain> but also pretty sure it is untested π
20:03:12 <truebrain> but, let's encourage people to contribute, even if it isn't the best place to start π
20:03:39 <truebrain> I always remind myself that one of the first things I did (after making some changes to the faces) was adding "bigmap" support .. and got ... flamed? yeah, flamed for it π
20:03:52 <truebrain> took a lot of persistency, and in the end another developer to make a proper implementation π
20:05:46 <truebrain> lol, did you actually try? π
20:06:27 <truebrain> owh, uint128_t isn't even a type
20:06:34 <truebrain> okay, so the description is correct π
20:08:50 <truebrain> and finally, it seems I am building symbols for all platforms, and are close to publishing them .. now I just need to setup the actual place to publish them etc .. something for another day π
20:09:06 <truebrain> but the workflow struggles seem to be over
20:09:15 <truebrain> only took .. 12 attempts of 30+ minutes each π
20:09:29 <_glx_> please put both .sym and .pdb in it
20:10:08 *** Kitrana has quit IRC (Quit: Leaving.)
20:10:10 <truebrain> I will check; the pdb will be a bit challenging, as I am not sure how to get the right ID from it
20:10:16 <_glx_> they go in the same folder if I understant
20:10:28 <truebrain> we will have to experiment a bit π
20:10:32 <peter1139> truebrain, I assume they compiled it... I wonder what with.
20:10:57 <_glx_> I assumed they edited the files in github
20:10:59 <truebrain> it seems to be a purely GitHub browser-based commit
20:11:13 <truebrain> so it is a hypothetical π
20:12:41 <peter1139> > This commit was created on GitHub.com and signed with GitHubβs verified signature.
20:13:41 <truebrain> go big or go home π
20:16:54 <truebrain> we all started somewhere; starting here is a terrible place, but ...go big or go home π
20:17:20 <truebrain> and can this workflow finish already; I want to know if I am actually done figuring out how to get symbols out of executables π
20:17:37 <truebrain> still annoyed that the MacOS variant is 50% of the size of the others ... that is not a good sign for MacOS crashreports π
20:18:37 <truebrain> so this is ~300 MiB per release .. luckily enough, compression does a good job, as that is a lot of data to store per release π
20:19:38 <truebrain> it is about ~40 MiB after compression it seems. 1 GB costs $0.015 .. so .. every month we keep costs 1 dollarcent!
20:19:45 <truebrain> I like these prices π
20:20:27 <_glx_> IIRC on MacOS inline functions are not symbolized
20:21:16 <_glx_> clearly not AWS prices π
20:21:17 <truebrain> the Linux build knows about 3200 inline functions .. I expected more π
20:21:43 <truebrain> haha, yeah, no, not AWS prices. Cloudflare R2 is the only reason we can do this, to be clear. Their pricing model allows us to store symbols like this π
20:23:13 <peter1139> It'd be free on andythenorth's MBP.
20:24:20 <truebrain> our wiki, last week: 19GB transfer. 18.3GB of that is cached by cloudflare. Rest was served by us. lol. That is a nice reduction in traffic π
20:24:57 <truebrain> BaNaNaS last month, 1.2TB transfer. 512GB cached. Rest served by Cloudflare too, but not as fast as the cached result π
20:25:54 <truebrain> also, the wik i had 1.4M requests last week .. our main page 700k .. and BaNaNaS only 200k π
20:27:23 <truebrain> 90k unique visitors in a week on the wiki, Cloudflare says
20:31:33 <truebrain> hmm .. one downside of a symbol server ... very soon it is nearly impossible to say what hash belongs to what version π
20:31:45 <truebrain> I might want to store some additional information to allow for easier pruning π
20:31:57 <truebrain> (I will have to remove nightly symbols at some point π )
20:35:37 <truebrain> lol, you can also update the FILE location to point to, for example, github.com/OpenTTD/blabla, pointing to the exact file. Feels a bit excessive π
20:39:11 <_glx_> you can add a text file next to the symbol file
20:39:43 <truebrain> yup, something like that will be needed
20:39:59 <truebrain> I think I will embed the name in the filename .. it is cheaper to do a ListObjects than a GetObject in a bucket π
20:40:03 <truebrain> optimizing for silly things!
20:40:45 <truebrain> btw, you mentioned Sentry wrote a nice doc about Symbol Servers .. Mozilla also has very nice docs about their pipeline
20:41:11 <truebrain> including how their pipeline looks, what software it runs, and a lot they wrote (and open sourced) themselves
20:41:39 <truebrain> Mozilla is also the org pushing for the switch to Rust for analyzing, instead of the crazy weird google variant π
20:42:04 <truebrain> `Warning: No files were found with the provided path: symbols/*. No artifacts will be uploaded.` .... NOOOOOOOOOO
20:42:08 <truebrain> it was almost done ....
20:42:45 <_glx_> and 45 minutes wasted π
20:42:55 <truebrain> peter1139: hahahaha
20:43:43 <_glx_> I want to see the result for "beed in the field"
20:44:14 <_glx_> (I edited to "beef" for IRC people)
21:00:51 *** keikoz has quit IRC (Ping timeout: 480 seconds)
21:09:38 <andythenorth> my GS is using 10MB
21:11:38 <andythenorth> hmm can GS shrink a town?
21:11:51 <andythenorth> I guess it has bulldozer
21:27:19 <andythenorth> anyone see a way to assign a 'regional capital' to towns, that **isn't** just a basic rectangular grid using xy?
21:28:03 <andythenorth> IRL it would use things like rivers or mountain ranges as divisions, but that is waaaaaaay too hard
21:28:10 <truebrain> Good argument _glx_ ; so I will leave it on π tnx!
21:28:44 <andythenorth> some games use hexagonal grids, maybe there's an algorithm for xy for that
21:31:06 <_glx_> "newgrf_version": 503344484 <-- wouldn't hexadecimal a better choice for this one ?
21:32:27 <andythenorth> hmm maybe 1 in 8 towns are regional capitals, with a random distribution
21:32:38 <andythenorth> but some weighting to enforce a minimum distance between them
21:32:47 <andythenorth> then the rest of the towns just take the nearest capital
21:34:00 <truebrain> _glx_: Internally it is an integer .. only way to make it hex is to make it a string, I guess
21:35:35 <_glx_> yeah it's an integer but with the hex value it's easier to decipher `const uint32_t _openttd_newgrf_version = (${REV_MAJOR} + 16) << 24 | ${REV_MINOR} << 20 | ${REV_ISSTABLETAG} << 19 | 28004;`
21:35:40 <truebrain> (Hex isn't valid JSON btw)
21:36:37 <truebrain> Yeah, I understand how it is composed. But I can either store it as integer or as string. So that gives the question .. is a string actually better? π
21:36:50 <locosage> andythenorth: last time I tried I had to use a server company for that but maybe something changed since
21:43:03 <_glx_> but I don't think I ever really checked the `NewGRF ver` line in crash.log π
21:45:19 <truebrain> It has lost much of its value now we only use major/minor for it π
21:45:37 <truebrain> Bit I honestly don't know what is best.. hex as string, or integer .. pros and cons to both
21:46:37 <truebrain> Guess hex as string makes slightly more sense
21:46:56 <truebrain> NewGRF IDs are also hex as strings, for obvious reasons
22:10:00 *** Kitrana has joined #openttd
22:10:07 <_glx_> `_openttd_content_version` string might be more valuable
22:10:40 <_glx_> as it contains (almost) the same in an already readable form
22:20:56 *** Wolf01 has quit IRC (Quit: Once again the world is quick to bury me.)
22:45:24 *** Wormnest has quit IRC (Quit: Leaving)
continue to next day β΅