Config
Log for #openttd on 3rd September 2021:
Times are UTC Toggle Colours
00:18:21  *** Alkel_U3 has quit IRC
00:22:59  *** Strom has quit IRC
00:31:38  *** Strom has joined #openttd
01:53:49  *** _aD has quit IRC
02:10:35  *** glx has quit IRC
02:28:18  *** Beer has quit IRC
02:30:24  *** debdog has joined #openttd
02:30:56  *** Wormnest has quit IRC
02:33:46  *** D-HUND has quit IRC
03:03:21  *** Tirili has quit IRC
03:26:59  *** Flygon has joined #openttd
05:40:57  *** andythenorth has joined #openttd
06:12:18  *** _11 has joined #openttd
06:42:33  *** andythenorth has quit IRC
07:15:12  *** jottyfan has joined #openttd
07:19:23  *** jottyfan has quit IRC
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
08:23:24  *** jeremy[m] has quit IRC
08:24:24  *** debdog has quit IRC
08:25:34  *** debdog has joined #openttd
08:33:03  *** robert[m]12 has joined #openttd
08:33:41  *** WormnestAndroid has quit IRC
08:33:54  *** WormnestAndroid has joined #openttd
08:34:19  *** jeremy[m] has joined #openttd
09:32:35  *** Feuersalamander has quit IRC
09:32:37  *** grossing has joined #openttd
09:55:37  *** WormnestAndroid has quit IRC
09:55:48  *** WormnestAndroid has joined #openttd
10:22:04  *** roadt_ has joined #openttd
10:28:59  *** roadt has quit IRC
11:00:14  *** Etua has joined #openttd
11:09:07  *** virtualrandomnumber has joined #openttd
11:09:59  *** virtualrandomnumber has quit IRC
12:14:44  *** glx has joined #openttd
12:14:44  *** ChanServ sets mode: +v glx
12:16:43  *** Samu has joined #openttd
12:40:47  *** jottyfan has joined #openttd
12:50:54  *** jottyfan has quit IRC
12:59:01  *** Etua has quit IRC
13:01:02  *** jottyfan has joined #openttd
13:15:44  *** nielsm has joined #openttd
13:29:06  *** iSoSyS has joined #openttd
13:31:20  *** iSoSyS has quit IRC
13:44:03  *** Gustavo6046_ has joined #openttd
13:44:14  *** Gustavo6046 has quit IRC
13:44:15  *** Gustavo6046_ is now known as Gustavo6046
14:11:20  *** _aD has joined #openttd
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
14:45:17  *** Etua has joined #openttd
15:22:53  *** Wormnest has joined #openttd
15:23:31  *** Flygon has quit IRC
15:25:06  <Samu> https://i.imgur.com/1TLevib.png and https://i.imgur.com/IVhS8v4.png
15:25:24  <Samu> my dream of 5000 vehicles is too slow still
15:50:11  *** HerzogDeXtEr has quit IRC
16:04:13  *** jottyfan has quit IRC
16:06:43  *** Progman has joined #openttd
16:16:42  <_aD> Samu: O_O
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
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
16:53:10  *** Wolf01 has joined #openttd
17:05:14  *** frosch123 has joined #openttd
17:16:43  <andythenorth> well
17:16:53  * andythenorth -> solitaire
17:29:20  *** jottyfan has quit IRC
17:37:17  <DorpsGek> [OpenTTD/BaNaNaS] JGRennison opened issue #105: Policy: Uploads which are not usable with main/trunk OpenTTD https://git.io/JufUD
17:38:37  <DorpsGek> [OpenTTD/OpenTTD] ldpl opened pull request #9536: Change: Deliver cargo to closest industry first https://git.io/JufUh
17:39:02  <DorpsGek> [OpenTTD/OpenTTD] ldpl updated pull request #9536: Change: Deliver cargo to closest industry first https://git.io/JufUh
18:09:16  <andythenorth> is it men's shed time?
18:14:59  *** Hirundo has quit IRC
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:22:44  <andythenorth> ah ah
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:27  <LordAro> yay
18:37:58  <TrueBrain> I just don't really know what JGRPP should send as "version"
18:38:03  <TrueBrain> 12.0 feels a bit weird :P
18:40:53  *** Tirili has joined #openttd
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:13  <TrueBrain> https://github.com/OpenTTD/OpenTTD/blob/master/src/network/network_content.cpp#L204 <- guess the easiest is to just add a "branch" name there. Define the variable in rev.cpp.in, like the version. Make it "vanilla" by default. JGRPP can define that to "jgrpp"
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:28  * andythenorth likes trains
18:45:36  <andythenorth> I would do ogfx
18:45:42  <andythenorth> but I am still doing work
18:46:10  <andythenorth> any chance of a ticket for the update here https://github.com/OpenTTD/OpenGFX/issues
18:46:13  <andythenorth> ?
18:46:19  <andythenorth> or is that admin overkill?
18:46:57  <LordAro> andythenorth: is #68 not to your liking?
18:47:51  <andythenorth> it's excellent
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:09  <frosch123> "branch string" is the same as in https://api.bananas.openttd.org/config/branches
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:35  <frosch123> the next one
18:54:45  <TrueBrain> what "next"? :)
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:38  <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:56:58  <TrueBrain> but I cannot
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:06  <LordAro> hehe
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:00:40  <LordAro> kinda
19:01:00  <TrueBrain> any reason to keep legacy version?
19:01:09  <TrueBrain> owh, crap, this protocol was not versionized
19:01:10  <TrueBrain> I forgot
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:04:35  <TrueBrain> I agree
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:00  <TrueBrain> :D
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:27  <LordAro> true
19:13:31  <LordAro> but i think that's a separate issue
19:13:38  <LordAro> possibly
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:31  <frosch123> for each branch
19:15:44  <TrueBrain> I like that
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:35:57  <frosch123> FLHerne: but feel free to PR https://github.com/OpenTTD/bananas-api/issues/23 :)
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:41:35  *** JGR has joined #openttd
19:42:20  <JGR> Hello
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
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
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  *** tokai has joined #openttd
20:14:23  *** ChanServ sets mode: +v tokai
20:15:47  <LordAro> yup
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:16:55  <Samu> ho
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
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
20:22:00  <LordAro> mhmm
20:25:01  <Samu> "Deliver cargo to the closest industry first" - I actually prefer to deliver cargo to all industries in range
20:25:40  <glx> only first 2 get stuff
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:12  <Samu> let me find
20:27:25  <andythenorth> I was told that could never work but eh
20:29:58  <Samu> https://github.com/SamuXarick/OpenTTD/commit/61889003e442ca5dde8092ddf50a5d3b9abbb260
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:45:55  <_dp_> *it
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:49:36  <Samu> can't push, why?  :(
20:50:43  <andythenorth> I didn't even notice it had changed
20:50:44  <andythenorth> :P
20:51:28  *** Gustavo6046_ has joined #openttd
20:53:08  <Samu> i can't push, don't know what this error is
20:53:09  <Samu> https://pastebin.com/raw/xt5r9Np8
20:53:14  <Samu> i want a force push
20:54:05  *** Gustavo6046 has quit IRC
20:54:05  *** Gustavo6046_ is now known as Gustavo6046
20:54:46  <Samu> nevermind, i guess it worked now
20:54:48  <Samu> https://github.com/OpenTTD/OpenTTD/compare/master...SamuXarick:distribute-cargo-to-multiple-industries?expand=1
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
21:30:21  *** Samu has quit IRC
21:35:41  *** Wolf01 has quit IRC
21:45:52  *** andythenorth has quit IRC
21:47:42  *** Wormnest has quit IRC
21:48:03  *** JGR has quit IRC
22:09:43  *** WormnestAndroid has quit IRC
22:10:43  *** WormnestAndroid has joined #openttd
22:35:34  *** gelignite has quit IRC
23:06:05  *** Progman_ has quit IRC
23:13:29  *** tokai|noir has joined #openttd
23:13:29  *** ChanServ sets mode: +v tokai|noir
23:20:25  *** tokai has quit IRC
23:26:05  *** tokai has joined #openttd
23:26:06  *** ChanServ sets mode: +v tokai
23:32:55  *** tokai|noir has quit IRC
23:42:01  *** sla_ro|master has quit IRC

Powered by YARRSTE version: svn-trunk