IRC logs for #openttd on OFTC at 2021-09-03
⏴ go to previous day
00:18:21 *** Alkel_U3 has quit IRC (Quit: maintenance)
01:53:49 *** _aD has quit IRC (Quit: leaving)
02:28:18 *** Beer has quit IRC (Remote host closed the connection)
02:30:56 *** Wormnest has quit IRC (Quit: Leaving)
02:33:46 *** D-HUND has quit IRC (Ping timeout: 480 seconds)
03:03:21 *** Tirili has quit IRC (Quit: Leaving)
05:40:57 *** andythenorth has joined #openttd
06:42:33 *** andythenorth has quit IRC (Quit: andythenorth)
07:15:12 *** jottyfan has joined #openttd
07:47:58 *** andythenorth has joined #openttd
08:11:21 *** sla_ro|master has joined #openttd
08:23:24 *** robert[m]12 has quit IRC (Ping timeout: 480 seconds)
08:23:24 *** jeremy[m] has quit IRC (Ping timeout: 480 seconds)
08:24:24 *** debdog has quit IRC (Quit: No Ping reply in 180 seconds.)
08:33:03 *** robert[m]12 has joined #openttd
08:33:41 *** WormnestAndroid has quit IRC (Remote host closed the connection)
08:33:54 *** WormnestAndroid has joined #openttd
08:34:19 *** jeremy[m] has joined #openttd
09:32:35 *** Feuersalamander has quit IRC (Remote host closed the connection)
09:32:37 *** grossing has joined #openttd
09:55:37 *** WormnestAndroid has quit IRC (Remote host closed the connection)
09:55:48 *** WormnestAndroid has joined #openttd
10:28:59 *** roadt has quit IRC (Ping timeout: 480 seconds)
11:09:06 *** virtualrandomnumber has joined #openttd
11:09:59 *** virtualrandomnumber has quit IRC ()
12:40:47 *** jottyfan has joined #openttd
12:50:54 *** jottyfan has quit IRC (Quit: jottyfan)
12:59:01 *** Etua has quit IRC (Quit: Etua)
13:01:02 *** jottyfan has joined #openttd
13:44:03 *** Gustavo6046_ has joined #openttd
13:44:14 *** Gustavo6046 has quit IRC ()
13:44:15 *** Gustavo6046_ is now known as Gustavo6046
14:12:28 *** gelignite has joined #openttd
14:23:34 *** Gustavo6046 has quit IRC ()
14:23:35 *** Gustavo6046 has joined #openttd
14:25:01 *** andythenorth has quit IRC (Quit: andythenorth)
15:22:53 *** Wormnest has joined #openttd
15:23:31 *** Flygon has quit IRC (Quit: A toaster's basically a soldering iron designed to toast bread)
15:25:24 <Samu> my dream of 5000 vehicles is too slow still
15:50:11 *** HerzogDeXtEr has quit IRC (Read error: Connection reset by peer)
16:04:13 *** jottyfan has quit IRC (Quit: jottyfan)
16:06:43 *** Progman has joined #openttd
16:17:02 <_aD> I finally converted a friend to using Silly town names. Mission accomplished.
16:17:09 <_aD> It was "Evilbottom" that sealed the deal.
16:29:58 *** andythenorth has joined #openttd
16:35:30 <DorpsGek> [OpenTTD/OpenTTD] JGRennison opened issue #9535: [Bug]: Poor performance opening "Check Online Content" window due to O(N^3) behaviour https://git.io/JuvbC
16:44:24 <LordAro> those functions are very strange
16:46:17 *** Etua has quit IRC (Quit: Etua)
16:47:58 <FLHerne> _aD: upgrading is usually a mistake
16:48:12 <FLHerne> Just build a new and better network from scratch
16:49:59 <_aD> FLHerne: I did. I have now had to cheat to the tune of £100m. Hahha.
16:50:30 <_aD> FIRS + Medium infrastructure costs ate through my £490m far more quickly than I expected. In fact I thought I had effectively infinite money...
16:52:29 *** jottyfan has joined #openttd
17:05:14 *** frosch123 has joined #openttd
17:29:20 *** jottyfan has quit IRC (Quit: jottyfan)
17:37:17 <DorpsGek> [OpenTTD/BaNaNaS] JGRennison opened issue #105: Policy: Uploads which are not usable with main/trunk OpenTTD https://git.io/JufUD
18:09:16 <andythenorth> is it men's shed time?
18:14:59 *** Hirundo has quit IRC (Ping timeout: 480 seconds)
18:15:56 *** Hirundo has joined #openttd
18:16:50 <andythenorth> how is coop bouncer working?
18:17:04 <andythenorth> coop is down no?
18:17:45 <DorpsGek> [OpenTTD/BaNaNaS] frosch123 commented on issue #105: Policy: Uploads which are not usable with main/trunk OpenTTD https://git.io/JufUD
18:18:38 <frosch123> andythenorth: just proves that it is a software issue, no hardware issue
18:18:47 <frosch123> 90% of the VMs crashed, the server did not burn down
18:24:01 <frosch123> devzone server is as stable as my router :)
18:30:10 <TrueBrain> nice writing frosch123
18:30:31 <frosch123> any opinion on my last sentence?
18:32:24 <frosch123> it would give a clear indication how to "tag" content for jgrpp in the upload
18:32:46 <frosch123> bananas-server could "or" the versions for compatibilty, or something
18:36:11 <DorpsGek> [OpenTTD/BaNaNaS] TrueBrain commented on issue #105: Policy: Uploads which are not usable with main/trunk OpenTTD https://git.io/JufUD
18:36:50 <TrueBrain> yeah, absolutely, we should do that. I think we were kinda waiting for someone to ask first
18:36:56 <TrueBrain> but now the question is asked, yeah, lets do it
18:37:07 <TrueBrain> I also think a protocol change will be trivial
18:37:58 <TrueBrain> I just don't really know what JGRPP should send as "version"
18:38:02 <TrueBrain> 12.0 feels a bit weird :P
18:41:36 <TrueBrain> and I have no clue what JGRPP uses as newgrf-version currently
18:43:46 <andythenorth> discord will know :P
18:43:51 <andythenorth> where JGR resides :P
18:44:21 <TrueBrain> andythenorth: I am testing my summoning powers
18:44:58 <TrueBrain> "Blazing fast, silky smooth, positive adjectives performance when opening the check online content window" <- haha, okay, that made me smile :D
18:45:42 <andythenorth> but I am still doing work
18:46:19 <andythenorth> or is that admin overkill?
18:46:57 <LordAro> andythenorth: is #68 not to your liking?
18:47:55 <andythenorth> pls send new eyes
18:49:10 <frosch123> TrueBrain: jgrpp uses the same "newgrf-versions" as the vanilla version from last sync/merge
18:49:31 <LordAro> andythenorth: also OpenTTD#9031
18:49:32 <frosch123> there are separate "branch versions" for newgrf as well
18:49:34 <TrueBrain> that will be confusing to users, as they will enter jgrpp >= 0.42.0
18:49:41 <LordAro> (which also requires some OGFX changes)
18:49:53 <frosch123> so jgrpp can have its own newgrf version, no need to abuse the vanilla one
18:50:51 <TrueBrain> so he just needs to find a good way to encode "0.42.3" into the dword, I guess :P
18:51:03 <TrueBrain> or, maybe, we shouldn't use a dword for it to the bananas-server, but a string
18:51:07 <TrueBrain> might just be easier
18:51:08 <frosch123> ah, so the api would need a mapping from jgrpp version to vanilla version. i don't think that will happen :p
18:51:45 <TrueBrain> as we now use the _openttd_newgrf_version for it
18:51:57 <TrueBrain> but .. that is not really needed, as we don't do anything with that
18:52:04 <TrueBrain> we deduce the major/minor/patch from it
18:52:21 <TrueBrain> so using _openttd_revision as string might just solve this as well
18:52:25 <frosch123> TrueBrain: we could add a list of string-pairs at the end of PACKET_CONTENT_CLIENT_INFO_LIST should
18:52:51 <frosch123> <type> <legacy newgrf version> (<branch string> <version string>)*
18:53:00 <TrueBrain> hmm, no, my idea is stupid, as that doesn't work for nightlies
18:53:29 <TrueBrain> yeah, protocol wise that is fine by me
18:53:36 <frosch123> "version string" not sure :p
18:53:38 <TrueBrain> I just realised "version string" is more difficult
18:54:02 <frosch123> there is already some version-sorting logic on the server page
18:54:16 <frosch123> maybe the same logic can compare string versions of branches
18:54:23 <TrueBrain> my issues is nightlies :)
18:54:30 <TrueBrain> what version does that represent
18:54:47 <frosch123> current nightly is 12.0, after branch it will be 13.0
18:54:58 <TrueBrain> there is no list in bananas-server about any thing version related
18:55:02 <TrueBrain> as .. we kept forget to update that :P
18:55:03 <LordAro> why not make it always "next" ?
18:55:24 <TrueBrain> so the client needs to send this information :)
18:55:31 <TrueBrain> meaning _openttd_revision doesn't cut it
18:55:52 <LordAro> i.e. if your scenario depends on something in current nightlies, it's on you if you don't update the version after 12.0 is actually released
18:56:23 <LordAro> treat all nightlies, regardless of age, as newer than any release
18:56:28 <TrueBrain> users now already upload content with >= 12.0
18:56:33 <frosch123> i don't understand the problem you see. vanilla would send <type> <legacy version> "offical" "12.0"
18:56:34 <TrueBrain> as they use something from the nightly
18:56:37 <TrueBrain> not sure that "next" is a good thing
18:56:45 <TrueBrain> frosch123: on a protocol level, no issue
18:56:50 <TrueBrain> I was thinking where this "12.0" lives in the code
18:56:56 <TrueBrain> I was thinking of using _openttd_revision
18:57:09 <TrueBrain> so .. another hard-coded global?
18:57:11 <LordAro> _openttd_previous_release
18:58:26 <frosch123> it's "next" release :)
18:58:56 <LordAro> build system doesn't know whether the next release is 12.1 or 13.0 :p
18:59:03 <TrueBrain> yet-another-hardcoded-string .. bah :P
18:59:11 <frosch123> but yes, a new "const char _openttd_content_branch[] = "12.0";"
18:59:29 <frosch123> LordAro: _openttd_newgrf_version already contains the numbers
18:59:32 <TrueBrain> LordAro: because of our branches, we kinda do ;)
18:59:35 <frosch123> just not as nice string
19:01:00 <TrueBrain> any reason to keep legacy version?
19:01:09 <TrueBrain> owh, crap, this protocol was not versionized
19:01:38 <frosch123> the server has to keep it, the client can set it to "TRUE"
19:02:31 <frosch123> "andy" or "lord" also works
19:02:39 * frosch123 is lucky to not have a 4 letter name
19:02:47 <TrueBrain> just bull we forgot to add version in the protocol
19:02:53 <TrueBrain> happy I didn't forget for GC :)
19:04:08 <frosch123> if you really want to get rid of the legacy-version, you can add a new package id
19:04:22 <frosch123> but i think keeping the dummy-version is less messy
19:05:44 <DorpsGek> [OpenTTD/BaNaNaS] TrueBrain commented on issue #105: Policy: Uploads which are not usable with main/trunk OpenTTD https://git.io/JufUD
19:06:45 <TrueBrain> let me know if I made a boo-boo in translation from IRC to text :P
19:09:17 <frosch123> bananas logic will be funny :p if they enter no version restrictions, it's compatible with everything. if they restrict it to "jgrpp >= 0.42.2", it will be unavailable for "official"
19:09:53 <frosch123> if they enter "offical >= 12.0", what happens with "jgrpp"?
19:09:59 <TrueBrain> or more fun: if you say official > 12.0, it might be JGRPP 0.43.0, for example :P
19:10:10 <_dp_> would be nice if that could also be used for "branch" and version of compatible clients like cmclient or android build
19:11:39 <TrueBrain> frosch123: guess we should send the "features available" instead of a version :P Solves *everything* :P
19:12:26 <TrueBrain> maybe in bananas-frontend-web it should be a dropdown .. you either limit "official" or you limit "jgrpp" .. dunno
19:12:28 <TrueBrain> bit tricky indeed :)
19:12:36 <LordAro> _dp_: i don't follow how that would be relevant? if the client is compatible, it can't add new things
19:12:48 <frosch123> jgrpp would send both (official, 12.0) , (jgrpp, 0.42.2), so it is fine
19:13:13 <_dp_> LordAro, it's not directly relevant but it's a nice info to know for a server
19:13:23 <_dp_> LordAro, for debugging purposes at the very least
19:13:31 <LordAro> but i think that's a separate issue
19:13:38 <frosch123> so, if you enter any version in bananas, it will be unavailable for all unlisted
19:13:54 <frosch123> and clients have to send all branches they understand
19:14:11 <TrueBrain> not sure this will be very clear to uploaders
19:14:25 <TrueBrain> as "official" behaves differently from the others, from their perspective
19:14:29 <TrueBrain> also not sure that is any issue :)
19:15:09 <frosch123> we can also add checkboxes in addition to the editboxes
19:15:25 <frosch123> so you can explicitly enter "does not work with any version", "works with all version", "works with specific version"
19:15:57 <frosch123> i think the API is fine. we just need someone to improve the GUI :p
19:16:01 <TrueBrain> and a note for "official" that "jgrpp" als implies "official" or something
19:16:42 <frosch123> ah, so a "same as 'offical'" option :p
19:21:37 <TrueBrain> seems easy enough; and as 12.0 is changing plenty on network level, we might as well do this too
19:27:13 <glx> extending the packet looks good, empty list being compatible with old clients
19:29:12 <TrueBrain> guess this is also a good time to migrate bananas-server to the new py-protocol :)
19:34:24 <FLHerne> TrueBrain: adopt JGR's extended savegame format with tagged, sometimes optional, features, and then use the same feature list in BaNaNaS
19:35:11 <frosch123> FLHerne: that may work for scenarios, but not for newgrf or gs
19:36:03 <frosch123> it would be a start
19:36:16 <FLHerne> frosch123: Nearly any feature that a grf might depend on should also be in the savegame, surely
19:36:30 <FLHerne> after all, grf state is stored in the savegame?
19:36:50 <FLHerne> I suppose GS API might not necessarily be
19:41:07 <nielsm> GRF is stateless except for the specific permanent registers (on towns, industries, not sure about vehicles?), which indeed are part of the savegame
19:41:31 <nielsm> how much GS (and AI) saves depends entirely on the script author
19:42:24 <glx> only name and version are always stored dor GS and AI
19:42:38 <JGR> Thanks for your replies on the Bananas issue, that's very helpful :)
19:52:13 <DorpsGek> [OpenTTD/OpenTTD] ldpl commented on issue #6503: Abnormalities in train subtile coordinates when reversing at the end of line https://git.io/fhZIc
19:54:59 <DorpsGek> [OpenTTD/BaNaNaS] JGRennison commented on issue #105: Policy: Uploads which are not usable with main/trunk OpenTTD https://git.io/JufUD
20:07:37 <DorpsGek> [OpenTTD/OpenTTD] LordAro commented on issue #6503: Abnormalities in train subtile coordinates when reversing at the end of line https://git.io/fhZIc
20:09:40 *** Gustavo6046 has quit IRC (Ping timeout: 480 seconds)
20:10:19 <_dp_> LordAro, yeah, I also thought of it, though 8/8 vehicles don't crash into water
20:12:11 *** frosch123 has quit IRC (Quit: be yourself, except: if you have the opportunity to be a unicorn, then be a unicorn)
20:12:12 *** Gustavo6046 has joined #openttd
20:13:12 <_dp_> may even be related to some weird signal bugs/crashes
20:13:24 *** Progman_ has joined #openttd
20:13:33 <_dp_> vehicle movement is quite wonky in general
20:14:23 *** ChanServ sets mode: +v tokai
20:16:10 <LordAro> there's also the Samu PR somewhere that "corrects" road vehicle movement
20:16:36 <LordAro> ('"corrects"' because no one's really sure what it actually does)
20:17:11 <glx> it equalises the number of turn steps IIRC
20:17:34 *** Gustavo6046 has quit IRC ()
20:18:18 *** Gustavo6046 has joined #openttd
20:18:40 *** Progman has quit IRC (Ping timeout: 480 seconds)
20:19:52 <_dp_> movement logic should just not depend on subtile coords imo
20:20:02 <_dp_> right now it mixes logic with visuals resulting in a mess
20:21:29 *** tokai|noir has quit IRC (Ping timeout: 480 seconds)
20:25:01 <Samu> "Deliver cargo to the closest industry first" - I actually prefer to deliver cargo to all industries in range
20:25:44 <_dp_> Samu, that was never the case afaik
20:26:15 <Samu> i had a PR that would make it deliver cargo randomly distributing piece by piece
20:26:37 <_dp_> it's basically only good for firs
20:26:55 <_dp_> and even that's kinda questionable
20:27:25 <andythenorth> I was told that could never work but eh
20:31:32 <Samu> a bit outdated, maybe i'll rebase
20:33:37 <_dp_> Samu, I can't think of any case where that would be a desirable behaviour
20:38:38 <FLHerne> definitely FIRS supplies
20:38:52 <FLHerne> but doing it by default for all industries seems bad
20:39:19 <FLHerne> or at least likely to break players' holy Workflows
20:39:49 <_dp_> FLHerne, so if you rarely deliver a bit of supplies to multiple industries you prefer them to go to waste rather than boost one?
20:40:40 <FLHerne> It's quite hard to have not enough supplies in FIRS :p
20:40:59 <FLHerne> distributing them evenly and constantly is the hard part
20:41:16 <FLHerne> and this would help with that
20:42:04 <_dp_> one carousel can easily distibute everything evenly
20:42:17 <_dp_> if one can figure out where they actually go from stations :p
20:45:34 <_dp_> anyway, goal of that PR is to bring it back to how it was, not invent a perfect solution
20:45:47 <_dp_> as it was clearly better than now and players were more or less used to id
20:47:05 <glx> yes the closest is easier to understand from a player pov
20:47:51 <glx> index just feels random because it's an internal value unknown for the player
20:48:06 <Samu> just rebased, conflicts solved
20:50:43 <andythenorth> I didn't even notice it had changed
20:51:28 *** Gustavo6046_ has joined #openttd
20:53:08 <Samu> i can't push, don't know what this error is
20:54:05 *** Gustavo6046 has quit IRC (Ping timeout: 480 seconds)
20:54:05 *** Gustavo6046_ is now known as Gustavo6046
20:54:46 <Samu> nevermind, i guess it worked now
20:55:01 <Samu> how do i delete the other?
20:56:36 <Samu> i deleted via website, hope it's sufficient
20:59:42 <Samu> still works, just tested, all industries receive their share
21:15:45 *** nielsm has quit IRC (Ping timeout: 480 seconds)
21:30:21 *** Samu has quit IRC (Ping timeout: 480 seconds)
21:35:41 *** Wolf01 has quit IRC (Quit: Once again the world is quick to bury me.)
21:45:52 *** andythenorth has quit IRC (Quit: andythenorth)
21:47:42 *** Wormnest has quit IRC (Ping timeout: 480 seconds)
21:48:03 *** JGR has quit IRC (Quit: Leaving)
22:09:43 *** WormnestAndroid has quit IRC (Ping timeout: 480 seconds)
22:10:43 *** WormnestAndroid has joined #openttd
22:35:34 *** gelignite has quit IRC (Quit: Stay safe!)
23:06:05 *** Progman_ has quit IRC (Remote host closed the connection)
23:13:29 *** tokai|noir has joined #openttd
23:13:29 *** ChanServ sets mode: +v tokai|noir
23:20:25 *** tokai has quit IRC (Ping timeout: 480 seconds)
23:26:05 *** ChanServ sets mode: +v tokai
23:32:55 *** tokai|noir has quit IRC (Ping timeout: 480 seconds)
23:42:01 *** sla_ro|master has quit IRC ()
continue to next day ⏵
