Log for #openttd on 6th January 2019:
Times are UTC Toggle Colours
00:00:39  *** Wolf01 has quit IRC
00:07:17  *** gelignite has quit IRC
01:07:17  *** Flygon has joined #openttd
01:14:55  *** Gja has quit IRC
01:19:47  *** wodencafe has quit IRC
01:23:16  *** Oroburos has joined #openttd
01:23:56  *** EnglandIsMyCity has joined #openttd
01:31:39  *** EnglandIsMyCity has quit IRC
01:33:30  *** Wormnest has quit IRC
01:40:35  *** wodencafe has joined #openttd
01:45:52  *** wodencafe has quit IRC
01:53:21  *** Progman has quit IRC
03:09:43  *** wodencafe has joined #openttd
03:32:43  <DorpsGek_II> [OpenTTD/OpenTTD] btzy commented on pull request #7005: Fix #7004: Redraw linkgraph overlay correctly after zoom
03:49:59  <Samu> omg, my AI is terribly slow now
03:50:58  <Samu> creating a list of vehicles by their unitnumber is horribly slow
04:00:23  <Samu> it's taking months for each list, bah
04:02:37  *** Oroburos has quit IRC
04:10:24  <Samu> how can I speed this up ?
04:10:28  <Samu>
04:17:13  <Samu> local vehicleList = Utils.VehicleUnitNumberList_Station(AIStation.GetStationID(this.m_stationFrom), AIVehicle.VT_ROAD);
04:17:20  <Samu> it's still executing this
04:17:39  <Samu> then there's valuators after, omg... i'm disappointed
04:17:45  <Samu> so much work for nothing
04:18:09  <Samu> unbearable speed, slower than a snail
04:18:50  <Samu> feels like I downgraded from a Core i7 to a calculator cpu
04:29:42  *** Samu has quit IRC
05:51:17  *** glx has quit IRC
06:49:00  *** synchris has joined #openttd
06:49:03  <DorpsGek_II> [OpenTTD/OpenTTD] michicc commented on pull request #7017: Add: Conditional order for max. reliability (patch by Cirdan, #6360)
07:31:47  *** sla_ro|master has joined #openttd
07:47:19  *** andythenorth has joined #openttd
07:51:52  *** Alberth has joined #openttd
07:51:52  *** ChanServ sets mode: +o Alberth
07:51:55  <Alberth> moin
07:56:46  <andythenorth> hi
08:27:45  *** nielsm has joined #openttd
08:29:05  <nielsm> morning
08:29:43  <andythenorth> moin
08:55:48  <TrueBrain> andythenorth: <- can you download the OSX artifact, and check if both the .zip and .dmg work? That the ingame version is correct (should have azure_release in it), etc? :D
08:58:39  <TrueBrain> reading michi_cc's comment, should we revert that commit Eddi|zuHause / planetmaker made last night?
08:58:40  <dwfreed> I can
09:01:41  <dwfreed> TrueBrain: os x .app doesn't execute unless lzo is installed in homebrew? is that normal?
09:01:59  <nielsm> TrueBrain either that, or make another commit that adds savegame fixups for the change
09:02:26  <dwfreed>   Library not loaded: /usr/local/opt/lzo/lib/liblzo2.2.dylib
09:02:26  <dwfreed>   Referenced from: /Volumes/VOLUME/
09:02:45  *** Borg has joined #openttd
09:03:36  <DorpsGek_II> [OpenTTD/OpenTTD] nielsmh commented on pull request #7017: Add: Conditional order for max. reliability (patch by Cirdan, #6360)
09:05:07  <TrueBrain> dwfreed: hmm .. lzo should be added static, so no, that is not expected behaviour
09:05:10  <dwfreed> it links against xz's liblzma, lzo, and libpng from homebrew, so in order to launch the .app, all 3 of those would have to be installed
09:05:35  <dwfreed> $ otool -L openttd | grep /usr/local
09:05:35  <dwfreed>     /usr/local/opt/xz/lib/liblzma.5.dylib (compatibility version 8.0.0, current version 8.4.0)
09:05:35  <dwfreed>     /usr/local/opt/lzo/lib/liblzo2.2.dylib (compatibility version 3.0.0, current version 3.0.0)
09:05:35  <dwfreed>     /usr/local/opt/libpng/lib/libpng16.16.dylib (compatibility version 52.0.0, current version 52.0.0)
09:06:23  <TrueBrain> nielsm: it fully depends on the timeline. Often it is easier to revert, fix, and recommit. As fixes tend to be forgotten :D But if you want to look into it, sounds perfect, tnx :)
09:06:48  <TrueBrain> okay, that is wrong; let me see why .. :)
09:06:50  <dwfreed> also the dmg has a space in the volume name
09:07:01  *** andythenorth is now known as Guest1823
09:07:01  *** andythenorth has joined #openttd
09:07:05  <andythenorth> ^^ this is my problem with taking other people's old patches and PRing them
09:07:10  <andythenorth> insufficient skin in the game :P
09:07:23  <TrueBrain> dwfreed: is that a bad thing?
09:07:29  <dwfreed> it's weird
09:07:41  <TrueBrain> andythenorth: also the comment: I did not test this, in the PR, didnt help :D
09:07:47  <dwfreed> and annoying to deal with when accessing the dmg from the terminal
09:08:05  <TrueBrain> dwfreed: would you mind making a fix for that via a PR? Running 'make bundle_dmg' creates a dmg file.
09:08:15  <TrueBrain> (from the source)
09:08:44  *** Guest1823 has quit IRC
09:08:52  <andythenorth> hmm
09:09:03  <dwfreed> oh
09:09:12  <andythenorth> TrueBrain: will the eventual download url be, or azure?
09:09:16  <dwfreed> the reason for the space is that the REV variable is not set
09:09:21  <TrueBrain> andythenorth:, ofc
09:09:24  <andythenorth> k
09:09:30  <andythenorth> gatekeeper reports the origin
09:09:34  <TrueBrain> REV variable not set?
09:09:52  <TrueBrain> clearly bundle_dmg hasnt run in months/years :D
09:10:03  <TrueBrain> okay, 'brew install' seems to not install static libraries
09:10:09  <TrueBrain> so it only creates the dynamic ones ..
09:10:27  <TrueBrain> what can I do about that .. hmm
09:10:30  <dwfreed>
09:10:39  <nielsm> TrueBrain huh it seemed to do when I tested
09:11:03  <dwfreed> brew has basically done away with build options
09:11:04  <TrueBrain> nielsm: it compiled; but did you check if it was dynamic or static?
09:11:11  <andythenorth> zip and dmg work for me btw
09:11:18  <dwfreed> and subsequently, optional static libs
09:11:25  <nielsm> as in, I made "lr -lR /usr > allthefiles.txt" downloaded that and looked through
09:11:26  <dwfreed> andythenorth: you probably have lzo installed in homebrew :)
09:11:28  <TrueBrain> andythenorth: because you have these dylibs installed, I assume :)
09:11:32  <nielsm> well, I didn't check that no
09:11:32  <andythenorth> ofc
09:11:44  <nielsm> the static lib files seemed to be present
09:11:56  <TrueBrain> nielsm: okay, that is good news; means the linker fucks up :D
09:12:27  <TrueBrain> okay, this is very hard to debug for me; would either of you ( andythenorth / dwfreed ) be willing to look into this? What we do is:
09:12:30  <TrueBrain> ./configure --enable-static
09:12:35  <TrueBrain> make -j2 bundle_dmg
09:12:49  <TrueBrain> (in combination with brew)
09:13:11  <dwfreed> I do see liblzma.a in xz's lib dir in homebrew
09:13:34  <dwfreed> libpng16.a also exists
09:14:04  <TrueBrain> possibly someone made a boo-boo in config.lib .. hmm
09:14:46  <nielsm> saved in 1.8: current master:
09:14:48  <nielsm> uh
09:14:53  <nielsm> 1.8 savegame:
09:15:00  <nielsm> master loads as:
09:15:21  <TrueBrain> so bugged :)
09:15:25  <TrueBrain> they jumped the gun ;)
09:15:34  <TrueBrain> okay, so we ask pkg-config to give the --static --libs
09:16:07  <TrueBrain> 		# OSX can't handle -static in LDFLAGS
09:16:07  <TrueBrain> 		if [ "$os" != "OSX" ]; then
09:16:07  <TrueBrain> 			LDFLAGS="$LDFLAGS -static"
09:16:07  <TrueBrain> 		fi
09:16:12  <TrueBrain> euhm ... sounds wrong?
09:16:30  <andythenorth> random conditional orders
09:16:52  <DorpsGek_II> [OpenTTD/OpenTTD] nielsmh commented on pull request #7017: Add: Conditional order for max. reliability (patch by Cirdan, #6360)
09:17:22  <nielsm> conditional disorders
09:17:59  <nielsm> at least it doesn't crash when reaching the nonsensical "Age (years) is false" order :)
09:20:31  <DorpsGek_II> [OpenTTD/OpenTTD] andythenorth commented on pull request #7018: Fix: Don't increase motion counter while train is waiting at non-path…
09:20:44  <nielsm> bump savegame version, or pretend nobody played the game since last bump?
09:20:51  <TrueBrain> I have an idea why static OSX is not working .. but I have to just try it
09:21:01  <TrueBrain> nielsm: I would say, bump
09:22:12  <nielsm> we're closing in at 1/256th of the max savegame version value!
09:22:18  <andythenorth> oof
09:22:20  <andythenorth> panic
09:22:25  <TrueBrain> dwfreed: funny, this REV is only used by OSX stuff. Guess someone forgot to rename it .. seems it should be VERSION now :)
09:23:31  <TrueBrain> indeed, someone did a partial search/replace :D
09:23:32  <TrueBrain> haha
09:26:40  *** Progman has joined #openttd
09:27:07  <TrueBrain> okay .. so that was the issue with static compiles:
09:27:08  <TrueBrain> 2019-01-06T09:26:40.1061370Z ld: library not found for -lcrt0.o
09:27:20  <TrueBrain> I think when switching to pkg-config, 'static' stopped working
09:27:27  <TrueBrain> but then it should have been broken for a longer time :D
09:29:45  <dwfreed> TrueBrain: what pkg-config file has that?
09:30:30  <TrueBrain> we used to detect libraries ourself, by looking in paths etc
09:30:36  <TrueBrain> now we just run: pkg-config liblzma --libs --static
09:30:44  <TrueBrain> but that --static, still returns -llzma
09:30:54  <TrueBrain> and as the dynamic variant also exists, it will pick that over the static
09:31:03  <TrueBrain> we need /usr/lib/liblzma.a
09:32:02  <TrueBrain> OSX, rightfully, doesn't support full static linking, as all OSX systems have a huge library-set. We just want these 3 to be static linked :D
09:33:55  <dwfreed>
09:34:24  <DorpsGek_II> [OpenTTD/OpenTTD] nielsmh opened pull request #7019: Fix #7017: Conditional orders enum updated without savegame version bump
09:35:16  <TrueBrain> or more importantly:
09:35:27  <TrueBrain> they have it documented :D
09:35:55  <TrueBrain> lets see if that really helps :)
09:35:55  *** Wolf01 has joined #openttd
09:36:12  <Wolf01> Moin
09:36:30  <TrueBrain> nice nielsm :D I wish I knew enough about the codebase to approve that, but .. "it looks good" :P
09:36:41  <TrueBrain> as that got us in this mess in the first place, I hope someone else gives a review soon :D
09:36:52  <dwfreed> what's documented there only works if there isn't a dylib next to a static archive
09:37:18  <TrueBrain> the title says something else?
09:37:27  <TrueBrain> it explicitly says it works if there is a dylib next to a static variant?
09:37:46  <TrueBrain> "Q:  How do I link against a static version of a library when a dynamic version exists on the system?"
09:37:49  <TrueBrain> what am I missing? :D
09:37:53  <TrueBrain> (honest question)
09:38:42  <dwfreed> "The best way to explicitly control the selection of which version of the library is linked against is to keep the static and dynamic versions of the library in different directories."
09:38:54  <TrueBrain> and that isn't the case?
09:38:57  <TrueBrain> (by default)
09:39:03  <TrueBrain> (so annoying I don't have an OSX system :D)
09:39:03  <dwfreed> not with homebrew libs, no
09:39:06  <TrueBrain> ugh
09:39:13  <dwfreed> because the dylib and the static archive are right next to each other
09:39:17  <TrueBrain> so .... we need a way to the .a file ..
09:39:29  <dwfreed> you can sed the pkg-config output
09:39:34  <TrueBrain> well, it sounded like the perfect solution ..... screw you QA :(
09:40:02  <nielsm> TrueBrain, hacks and assume homebrew always installs the .a file the same path?
09:40:04  <nielsm> :(/
09:40:05  <TrueBrain> very OSX specific ... pkg-config should solve that
09:40:23  <dwfreed> pkg-config just dumps text files to stdout
09:40:30  <dwfreed> with some dependency resolution
09:41:24  <dwfreed> but you can use the fact that homebrew makes a /usr/local/opt path for each package
09:41:33  <TrueBrain> hmm .. libpng is no longer marked as 'static capable' in pkg-config
09:41:33  <dwfreed> /usr/local/opt/xz/lib/liblzma.a
09:41:53  <TrueBrain> dwfreed: we used to do all this ourself; the whole idea of using pkg-config, that it is the same on all systems, and we don't have to do it ourself
09:42:06  <TrueBrain> if possible, I would really like to avoid making a special case for OSX :(
09:42:16  <TrueBrain> I can overrule it via ./configure options, I guess ..
09:42:23  <TrueBrain> but this is stupid
09:43:10  <nielsm> okay #7017 fix has finished checking :)
09:43:14  <nielsm> if someone will review it
09:43:32  <DorpsGek_II> [OpenTTD/OpenTTD] PeterN commented on pull request #7019: Fix #7017: Conditional orders enum updated without savegame version bump
09:43:33  <andythenorth> TrueBrain: I buy us a mac? :P
09:44:16  <TrueBrain> oeh, what I can do ... is just ... remove the dylib on the host
09:44:20  <TrueBrain> that would force him :D
09:44:23  <TrueBrain> yes yes
09:44:36  <TrueBrain> dwfreed: what is the folder structure of homebrew?
09:44:48  <TrueBrain> everything is always in /usr/local/opt/<package>/lib/ ?
09:45:38  <DorpsGek_II> [OpenTTD/OpenTTD] nielsmh commented on pull request #7019: Fix #7017: Conditional orders enum updated without savegame version bump
09:46:30  <nielsm> TrueBrain I think it symlinks all the installed brews into /usr/local/lib
09:47:40  <dwfreed> /usr/local/lib/lib<foo>.a does exist
09:48:04  <TrueBrain> okay ... so let me guess this then ..
09:48:09  <dwfreed> /usr/local/opt/package/lib/lib<foo>.a helps ensure you still get the file if brew decides to make that package keg-only
09:48:18  <TrueBrain> no, I am reversing the issue :D
09:48:23  <TrueBrain>       rm /usr/local/lib/*.dylib
09:48:29  <dwfreed> eww
09:48:31  <nielsm> lol
09:48:35  <nielsm> that works too!
09:48:44  <dwfreed> just don't do that in the makefile
09:48:45  <nielsm> awk the .pc files?
09:48:47  <DorpsGek_II> [OpenTTD/OpenTTD] PeterN commented on pull request #7019: Fix #7017: Conditional orders enum updated without savegame version bump
09:48:47  <TrueBrain> and means I dont have to fiddle with the result from pkg-config
09:49:03  <TrueBrain> nielsm: that would be the other solution
09:49:12  <TrueBrain> mine sounds more future-proof :D
09:49:25  <dwfreed> parsing .pc files is a minefield
09:49:31  <dwfreed> they're sort of bash
09:49:39  <dwfreed> but also not
09:49:52  <TrueBrain> we should switch to cmake one day or the other
09:49:56  <TrueBrain> I hope cmake does have this solved
09:50:03  <TrueBrain> (cmake profiles tend to be better of quality)
09:50:04  <dwfreed> doubt it
09:50:09  <DorpsGek_II> [OpenTTD/OpenTTD] nielsmh commented on pull request #7019: Fix #7017: Conditional orders enum updated without savegame version bump
09:54:28  <TrueBrain> dwfreed: <- would you mind checking if it worked? :D
09:54:38  <TrueBrain> binary size is slightly larger
09:56:25  <TrueBrain> hmm, I think libpng and lzma are still dylib
09:59:29  <dwfreed> yes, it still linked against liblzma and libpng as dylib
09:59:49  <DorpsGek_II> [OpenTTD/OpenTTD] nielsmh updated pull request #7019: Fix #7017: Conditional orders enum updated without savegame version bump
09:59:49  <dwfreed> find /usr/local -name '*.dylib' -delete
10:00:01  <TrueBrain> turns out, that if you remove too many dylibs, other things break :D
10:00:08  <TrueBrain> git no longer works :P
10:00:17  <dwfreed> yes
10:01:10  <DorpsGek_II> [OpenTTD/OpenTTD] nielsmh commented on pull request #7019: Fix #7017: Conditional orders enum updated without savegame version bump
10:02:55  <TrueBrain> I never understood how Apple saw this working .. or homebrew for that matter
10:03:02  <TrueBrain> force everyone to install the libraries via brew too? :P
10:04:19  <nielsm> if apple supplied a better tool for copying in dylink dependencies to an .app package and fixing the install_names that would be fine too, imo
10:04:34  <TrueBrain> I agree
10:04:39  <TrueBrain> same for Windows btw .. shipping dlls is a nightmare
10:05:06  <nielsm> well at least windows dlls don't come with a hidden field telling the exact installed path they're supposed to be at
10:05:25  <TrueBrain> fair
10:05:29  <nielsm> causing apps to throw "not found" loader errors for libs that obviously exist
10:05:37  *** gelignite has joined #openttd
10:09:18  <andythenorth> I improved the testing notes on this if anyone wants to review it :P
10:09:28  <dwfreed> you can use install_name_tool to edit that path
10:09:34  <dwfreed> and bundle the dylibs in the .app
10:09:52  <TrueBrain> I expect a PR! :D
10:10:50  <nielsm> dwfreed yes you can, and it's terribly annoying to do
10:10:57  <nielsm> I wrote scripts to do that many years ago
10:11:11  <nielsm>
10:13:00  <TrueBrain> dwfreed:
10:13:02  <TrueBrain> give that a spin plz
10:13:08  <TrueBrain> ended up with:
10:13:09  <TrueBrain>       rm /usr/local/Cellar/lzo/*/lib/*.dylib
10:13:09  <TrueBrain>       rm /usr/local/Cellar/xz/*/lib/*.dylib
10:13:09  <TrueBrain>       rm /usr/local/Cellar/libpng/*/lib/*.dylib
10:13:12  <TrueBrain> seems to work?
10:13:55  <dwfreed> will work at least until more homebrew libs are added, anyway
10:14:09  <dwfreed> also would be nice if pipelines allowed downloading the artifacts for a single job
10:14:20  <TrueBrain> I can :P
10:14:25  <TrueBrain> but artifacts are temporary
10:14:26  <TrueBrain> so no worries
10:14:54  <TrueBrain> (its really weird, I can just download a single artifact .. for some reason you need to be lgged in to do that .. weirdness :P)
10:15:11  <TrueBrain> but I will publish these on a decent CDN, so you can just download a single file :)
10:16:46  <nielsm> wow that was annoying, tracking that old script through five or more moves/renames
10:20:05  <TrueBrain> reminds me I have to publish checksums too
10:20:14  <Alberth> obviously Apple expects you to be a good user and not mess with libraries and programs of your own
10:21:36  <nielsm> the other day I heard that even internally at apple's devtools team, they don't have access to any better build hardware than everyone else
10:21:41  <andythenorth> Apple just expects you to keep buying
10:21:45  <nielsm> they have to make do with trashcans working as servers etc
10:21:46  <andythenorth> that is all nowadays
10:22:01  <andythenorth> it's like that joke where Jeff Bezos wishes someone a nice day
10:22:13  <Alberth> yep, trying to stop people from replacing batteries themselves, so they buy a new device
10:22:14  <nielsm> and they have to take them out at full price of the internal budget
10:22:39  <andythenorth> that must be motivating
10:23:01  <andythenorth> all is not well in the Spaceship
10:23:02  <nielsm> anyone for reviewing again? :D
10:23:18  <nielsm> if it can get merged now there won't be any revisions between issue introduced and fixed
10:23:21  <andythenorth> :D
10:24:05  <Alberth> and then you hope you never end up at that point while bisecting :)
10:24:18  <andythenorth> currently Apple are very frustrating :|
10:24:27  <andythenorth> putting aside people who would never buy Apple anyway
10:24:34  <andythenorth> the stuff is *nearly* brilliant
10:24:45  <andythenorth> but *nearly* isn't good enough at the price
10:25:19  * andythenorth back to PRs
10:26:39  <andythenorth> nielsm: not sure how to move this one forward
10:26:50  <nielsm> andythenorth yeah...
10:27:01  <nielsm> I guess I'll have to scrap some of the ideas
10:27:31  <andythenorth> it's quite unwieldy to test, is the problem
10:27:45  <andythenorth> even playtesting, it's open to quite subjective bias
10:27:50  <nielsm> yes
10:27:57  <andythenorth> and playtesting is multiple hours of commitment
10:28:09  <andythenorth> and there are multiple climates etc :P
10:29:00  <andythenorth> I'd say feature flag
10:29:07  <andythenorth> but do we ever remove the damn things?
10:29:18  <andythenorth> or do they just sit there introducing combinatorial problems?
10:29:47  <nielsm> part of the problem is also that the original quadratic production overwhelms you, but linear feels like either fine at the low end but too little at the high end, or too much at the low end and fine at the high end
10:31:12  <nielsm> I think what I want is something with a curve less agressively growing than pop^2 but still more than linear
10:31:24  <andythenorth> my proposal: fix the obvious defect
10:31:41  <andythenorth> quadratic is obviously just a mistake, no?
10:32:27  <dwfreed> TrueBrain: dmg works; version reported is "20190106-azure_release-g1e4c9ecf"
10:32:27  <andythenorth> if we put that in trunk I can play test it and give opinions
10:33:10  <andythenorth> I can play test it in a PR, but eh, I am already managing so many local patches :P
10:33:14  <andythenorth> I get lost
10:35:42  <TrueBrain> dwfreed: SWEET!
10:35:44  <TrueBrain> thank you :)
10:36:04  <dwfreed> nielsm: use something less than 2 for the exponent?
10:36:23  <nielsm> dwfreed problem is that it's not _written_ as an exponent :)
10:37:20  <nielsm> the original algorithm has quadratic growth because it's a linear chance of generation (on house pop) for cargo being generated at all, and the generated amount is a linear dice roll for amount
10:37:33  <nielsm> which ends up producing a pop*pop distribution
10:37:55  <andythenorth> Earthling medium looks like the best starting point
10:38:11  <dwfreed> TrueBrain: zip file is the same result
10:38:17  <Alberth> roll a die for amount / 2 ?
10:38:22  <TrueBrain> cool; so we have working MacOSX binaries :D
10:38:30  <TrueBrain> means I only have deb-based systems left to figure out
10:38:33  <TrueBrain> and add checksums :D
10:38:57  <dwfreed> TrueBrain: and neither link against any homebrew libs
10:39:04  <TrueBrain> cool :D
10:39:20  <andythenorth> TrueBrain: :o \o/
10:39:32  <nielsm> conceptually I like my own binomial version the best, since it basically says "each person in this house has a 1:2 chance of making a trip"
10:39:40  <andythenorth> ok
10:39:43  <andythenorth> well let's try that
10:39:47  <DorpsGek_II> [OpenTTD/OpenTTD] PeterN approved pull request #7019: Fix #7017: Conditional orders enum updated without savegame version bump
10:40:02  <andythenorth> nielsm: I think there are too many factors like newgrf, cdist etc to perfect it
10:40:12  <andythenorth> I think we just present this as iterative
10:40:18  <nielsm> town houses also have a cargo_production callback :)
10:40:32  <nielsm> which if present ignores this algorithm choice entirely
10:40:43  <andythenorth> I would like to see something that works with smaller towns
10:40:47  <andythenorth> which are currently too hard
10:40:51  <nielsm> yeah
10:40:55  <andythenorth> I suspect cities can be fixed in content
10:40:58  <nielsm> small towns produce too little and large produce too much
10:41:04  <andythenorth> e.g. the problem with cities is density
10:41:11  <andythenorth> space for stations vs. pax produced
10:41:18  <andythenorth> that is fixable by adjusting buildings
10:41:21  <dwfreed> launching openttd brings back memories of rollercoaster tycoon as a kid (iirc, TTD and RCT have the same developer)
10:41:33  <andythenorth> Chris Sawyer
10:41:39  <dwfreed> yep, that's the one
10:42:30  <nielsm> maybe the real solution would be to have smaller town cargo gen but stations have larger catchment area
10:42:31  <andythenorth> nielsm: we need a bleeding edge openttd :P
10:42:42  <nielsm> andythenorth isn't that JGRPP?
10:42:44  <nielsm> :(
10:42:54  <andythenorth> well JGRPP has won forums yes
10:43:08  <andythenorth> I think something else won reddit
10:43:21  <dwfreed> TrueBrain: next up, make an installer that can download opengfx for you
10:43:35  <TrueBrain> dwfreed: I await your Pull Request with open arms :)
10:43:45  <dwfreed> :P
10:43:54  <TrueBrain> seriously; you now set expectations :)
10:43:58  <nielsm> ottd on windows can download opengfx on first boot, doesn't that work on any other platforms?
10:44:29  <dwfreed> the mac app bombed when I opened it because there were no graphics
10:44:55  <dwfreed> (I have never actually played openttd before, I just happened to have a mac and be around when TrueBrain asked for mac testers)
10:45:25  <DorpsGek_II> [OpenTTD/OpenTTD] nielsmh merged pull request #7019: Fix #7017: Conditional orders enum updated without savegame version bump
10:45:58  <TrueBrain> oeh, Azure Pipelines YAML supports templates .. interesting ..
10:46:23  <TrueBrain> dwfreed: and yet idling in this channel :D But it is very much appreciated :)
10:46:27  <TrueBrain> now get addicted to OpenTTD :P
10:46:59  <dwfreed> TrueBrain: I'm a network operator; I came here because somebody reported this channel was getting spammed
10:47:13  <TrueBrain> ah :)
10:47:15  <TrueBrain> did you fix it? :D
10:47:17  <dwfreed> I have triggers that automatically kill on certain keywords
10:47:33  <TrueBrain> are we still in +R I wonder ..
10:47:38  <nielsm> nope
10:47:40  <dwfreed> this channel is +s
10:47:42  <nielsm> +s fixed it
10:47:45  <TrueBrain> lolz
10:47:49  <TrueBrain> that is another way of fixing it :)
10:47:52  <andythenorth> dwfreed: well thanks for the help :)
10:47:56  <dwfreed> also that botnet stopped just before christmas
10:47:57  <andythenorth> from a mac user
10:47:57  <TrueBrain> +R was rather annoying
10:48:26  <TrueBrain> I cannot believe they target OFTC to get people to go to freenode .. I mean ... I dont understand that :(
10:48:42  <dwfreed> i'm curious, what's the difference between opengfx 0.5.2 and 0.5.4, and why isn't 0.5.4 the version available from the main website?
10:49:16  <andythenorth>
10:49:25  <andythenorth> mostly just translations
10:49:32  <andythenorth> and possibly nobody released it :P
10:49:56  <TrueBrain> only on BaNaNaS most likely .. we have to CI/CD that stuff :D
10:52:40  <TrueBrain> dwfreed: basically, I am guessing someone published 0.5.4 in the ingame content service, but didn't publish it on the website; these are currently two systems, and they tend to desync :D
10:53:03  <dwfreed> nope, it's not in the ingame content system either
10:53:28  <dwfreed> (also when I click select upgrades, it selects opengfx to downgrade it)
10:53:51  <TrueBrain> so even more lazyness :D
10:54:10  <dwfreed> I found 0.5.4 from
10:54:41  <TrueBrain> hmm .. OSX users: md5sum, sha1sum, sha256sum .. which do you have available, and you happen to know by which brew package if not?
10:54:46  <TrueBrain> md5sum == md5 -r I guess
10:54:47  <dwfreed> shasum
10:54:53  <dwfreed> or use openssl
10:54:55  <nielsm> bbl
10:55:02  <TrueBrain> hmm .. shasum is installed?
10:55:23  <dwfreed> might be in brew
10:55:35  <andythenorth> I have one in /usr/bin
10:55:41  <TrueBrain> shasum often cannot do md5
10:55:44  <dwfreed> yeah, same, apparently
10:55:56  <dwfreed> don't do md5 anyway
10:56:04  <dwfreed> but openssl dgst can do them all
10:56:08  <TrueBrain> yeah .. it might be time to drop md5 indeed :)
10:56:37  <andythenorth> I don't have the others listed
10:56:41  <andythenorth> I do have openssl obvs
10:57:35  <TrueBrain> the output is only slightly different from coreutils
10:57:50  <dwfreed> openssl dgst -r -md5 -hex file
10:58:03  <dwfreed> that outputs the format coreutils expects
10:58:05  <TrueBrain> I get a * in front of the filename
10:58:09  <TrueBrain> no clue why
10:58:15  <dwfreed> that's actually a flag indicator
10:58:17  <TrueBrain> what does * mean ..
10:58:23  <dwfreed> * and space have slightly different meanings
10:58:35  <dwfreed> which is why coreutils md5sum outputs 2 spaces instead of 1
10:58:41  <TrueBrain> lol .. never knew there could be flags :D
10:59:01  <dwfreed> ('*' for binary, ' ' for text or where binary is insignificant)
10:59:21  <dwfreed> openssl errs on the side of not deciding if binary mode is insignificant
11:01:06  <TrueBrain> tnx :)
11:01:13  <TrueBrain> the wonders of tools :D
11:02:59  *** nielsm has quit IRC
11:04:17  <andythenorth> eh so I'm not seeing this on the binaries
11:04:27  <andythenorth> but I don't know how to cause macOS to retrigger the warning
11:04:33  <andythenorth> I don't think it shows it every time
11:05:55  <TrueBrain> andythenorth: we are only going to produce 64bit binaries
11:06:02  <TrueBrain> so that should be fixed when we make binaries again
11:06:09  <andythenorth> it is fixed
11:06:16  <andythenorth> the binary you made today is 64bit
11:06:33  <TrueBrain> so when that is officially done
11:06:36  <TrueBrain> that ticket can be closed :)
11:16:14  <DorpsGek_II> [OpenTTD/OpenTTD] andythenorth commented on issue #6978: Current (1.8.0) macOS binaries out-of-date (deprecation warning because of 32bit on start)
11:23:54  <DorpsGek_II> [OpenTTD/OpenTTD] TrueBrain commented on issue #6978: Current (1.8.0) macOS binaries out-of-date (deprecation warning because of 32bit on start)
11:23:55  <DorpsGek_II> [OpenTTD/OpenTTD] TrueBrain closed issue #6978: Current (1.8.0) macOS binaries out-of-date (deprecation warning because of 32bit on start)
11:24:21  <DorpsGek_II> [OpenTTD/OpenTTD] TrueBrain commented on issue #6916: Re-implement building binaries via compile farm
11:24:37  <TrueBrain> sorry andythenorth, after reading it again, I was like: keeping this ticket alive is silly :D
11:24:55  <andythenorth> good
11:25:00  <andythenorth> less future admin
11:25:02  *** gelignite has quit IRC
11:26:20  <TrueBrain> I split up the pipeline in many small pieces .. starting a job now takes a lot longer :P
11:26:25  <TrueBrain> guess it is fetching all the pieces
11:27:50  *** gelignite has joined #openttd
11:44:30  *** ChanServ sets mode: +v Alberth
11:44:30  *** ChanServ sets mode: +v peter1138
11:44:30  *** ChanServ sets mode: +v planetmaker
11:44:55  <TrueBrain> wb ChanServ
11:49:03  <dwfreed> fixed a bug and improved some things :)
11:50:21  <TrueBrain> \o/ :D
11:50:44  <TrueBrain> okay, Azure Pipelines templates made the pipeline a lot more readable :D
11:53:00  <andythenorth> :)
11:53:10  <andythenorth> can it fix my sprite generator too?
11:53:13  <andythenorth> it's all pipelines
11:55:11  <TrueBrain> yes!
11:55:13  <TrueBrain> I AM SURE OF IT
12:03:47  *** gelignite has quit IRC
12:31:05  <DorpsGek_II> [OpenTTD/OpenTTD] TrueBrain opened pull request #7020:  Add: [AzurePipeline] introducing a release pipeline
12:32:52  <LordAro> exciting
12:33:16  <DorpsGek_II> [OpenTTD/OpenTTD] TrueBrain updated pull request #7020:  Add: [AzurePipeline] introducing a release pipeline
12:33:20  <TrueBrain> still no clue why the deb-builds fail :(
12:34:07  <dwfreed> TrueBrain: link to failing build log?
12:35:02  <TrueBrain> <- and linux-debian-..-amd64 (or ubuntu)
12:35:10  <TrueBrain> something about lzo2 and fPIC
12:36:02  *** Flygon has quit IRC
12:37:24  <DorpsGek_II> [OpenTTD/OpenTTD] TrueBrain commented on pull request #7020:  Add: [AzurePipeline] introducing a release pipeline
12:37:41  <dwfreed> TrueBrain: that build succeeded, just the artifact publishing failed
12:38:18  <TrueBrain> then you are checking the wrong build result :D
12:38:33  <TrueBrain> sorry, I dont have a more up-to-date failure, as .. I stopped looking into it, as I dont understand what is going wrong :D
12:38:41  <TrueBrain> Linux linux-ubuntu-xenial-amd64-gcc
12:38:46  <TrueBrain> click Build
12:38:52  <TrueBrain> 2019-01-05T19:32:19.5571987Z /usr/bin/ld: /usr/lib/gcc/x86_64-linux-gnu/5/../../../x86_64-linux-gnu/liblzo2.a(lzo_util.o): relocation R_X86_64_32 against `.rodata' can not be used when making a shared object; recompile with -fPIC
12:38:52  <TrueBrain> 2019-01-05T19:32:19.5574721Z /usr/lib/gcc/x86_64-linux-gnu/5/../../../x86_64-linux-gnu/liblzo2.a: error adding symbols: Bad value
12:39:09  <dwfreed> I looked at the debian stretch one
12:39:33  <TrueBrain> the i386 do work; only the amd64 fail :(
12:39:43  <TrueBrain> (and the generic works too, which is based on the same distro ..)
12:39:51  <TrueBrain> but with fakeroot, something goes wrong
12:42:15  <dwfreed> debian stretch amd64 worked
12:42:56  <TrueBrain> even worse
12:43:06  <TrueBrain> as the jessie failed :D
12:43:08  <dwfreed> but jessie and both ubuntu amd64 failed
12:43:09  <TrueBrain> I AM SO CONFUSED :D
12:43:19  <TrueBrain> at least my PR works
12:45:06  <dwfreed> TrueBrain: I'm not sure the build deps are right? it's linking against the static lzo2 library
12:45:16  <dwfreed> 2019-01-05T19:32:52.2395651Z /usr/bin/ld: /usr/lib/gcc/x86_64-linux-gnu/7/../../../x86_64-linux-gnu/liblzo2.a(lzo_util.o): relocation R_X86_64_32 against `.rodata' can not be used when making a PIE object; recompile with -fPIC
12:45:33  <dwfreed> note that says "liblzo2.a"
12:45:54  <TrueBrain> yeah; that should be fine not?
12:46:05  <TrueBrain> I believe the deb files also create a static-ish OpenTTD
12:46:14  <dwfreed> they shouldn't be
12:46:15  <TrueBrain> not sure .. I never wrote the debian files, nor maintained them :P
12:46:20  <TrueBrain> I know .... very little about it
12:46:34  <LordAro> i'd be surprised if deb OTTD was static
12:46:36  <TrueBrain> <- this is running the build
12:46:50  <TrueBrain> based on this base image:
12:47:40  <TrueBrain> it used to work (this setup too)
12:47:41  <LordAro> ...weird
12:47:57  <TrueBrain> the last line can be the problem for sure
12:48:11  <TrueBrain> both fixes .. *shrug*
12:48:34  <dwfreed> you really shouldn't squash changes
12:48:45  <TrueBrain> squash what changes?
12:48:48  <dwfreed> it makes it really hard to figure out the reason for a change
12:48:48  <LordAro> i've never known anything else be an issue like that
12:49:04  <TrueBrain> LordAro: these things come from systems written 15 years ago .. :P
12:49:19  <LordAro> well, i imagine that issue has long been fixed :p
12:49:27  <LordAro> probably the case for the icu files as well, tbh
12:49:31  <TrueBrain> as this was never open source, nobody ever did anything with it :P
12:49:33  <LordAro> dwfreed: i don't think it was ever separate commits
12:49:50  <TrueBrain> dwfreed: what you see in that repository, is about the smallest pieces of commits wehave
12:50:52  <TrueBrain> I also really need someone to look at the generic-linux variant
12:51:00  <TrueBrain> it is now based on debian stretch, and only ICU is static
12:51:11  <TrueBrain> I cannot imagine that the result is useful for a large group
12:51:29  <TrueBrain> so I seriously wonder if we should build it .. and if so, if this is the best base for it
12:51:44  <LordAro> it's worth pointing out that if "generic linux" is built with debian stretch, it won't work for anything older, due to glibc version fun
12:51:51  <TrueBrain> exactly
12:51:57  <dwfreed> most likely, anyway
12:52:00  <TrueBrain> so how useful is it
12:52:05  <dwfreed> which means centos is out entirely
12:52:21  <LordAro> mm
12:52:32  <dwfreed> running it on fedora could be hit or miss
12:52:32  <milek7> glibc version hacks:
12:52:40  <LordAro> dwfreed: we have to build our stuff at work with centos5, for... reasons...
12:52:51  <LordAro> milek7: hey i recognise that :p
12:53:21  <TrueBrain> I would love to have a docker that generates a more ... suitable generic linux binary
12:54:08  <dwfreed> LordAro: *stab*
12:54:32  <TrueBrain> so if any of you would like to look into it, would be awesome :D
12:54:42  <TrueBrain> I am now testing a build without those "OpenTTD fix-up" lines
12:54:46  <TrueBrain> see if that works
12:55:00  <TrueBrain> takes a bit of time :D (lol .. ~2 hours)
12:55:47  <dwfreed> link to build?
12:56:07  <TrueBrain> locally, so no
12:56:13  <dwfreed> boo
12:56:57  <TrueBrain> currently I do not have a way to publish these images without immediately pushing them to production :P
12:58:12  <dwfreed> forks
12:58:22  <TrueBrain> on docker hub? :D
12:58:26  <TrueBrain> owh, I wish it was that easy :P
12:58:31  <dwfreed> and abusing parameters
12:59:05  <TrueBrain> but by all means, feel free to contribute :)
13:02:16  <TrueBrain> (this one-man-show would love to be less of a one-man-show)
13:11:00  <andythenorth> :|
13:19:27  <Eddi|zuHause> said the person who was yesterday like "WAAAH, TOO MANY CONTRIBUTIONS!"
13:20:19  <TrueBrain> Eddi|zuHause: that was funny yesterday, in context, with the sarcasme; not sure it floats now as well as it did yesterday ;)
13:20:51  <Eddi|zuHause> PS: i don't see how i could contribute to "debian build is failing for obscure reasons"
13:21:11  <TrueBrain> good thing there are more people here than just us two :D
13:21:31  <Eddi|zuHause> yeah, this project would be fucked :p
13:41:31  *** andythenorth has quit IRC
13:41:52  *** andythenorth has joined #openttd
13:52:57  <TrueBrain> okay, found why the symlinks were needed: /usr/bin/ld: cannot find -lsiculx
13:53:02  <TrueBrain> and 3 more of those
13:53:10  <dwfreed> fix that to not use the s
13:53:24  <LordAro> ^ would be the better solution
13:54:03  <TrueBrain> I am guessing that is what pkgconfig reports
13:54:14  *** andythenorth has quit IRC
13:54:53  <TrueBrain> yeah, we compile with --static-icu
13:55:00  <TrueBrain> that is why it wants to find siculx
13:55:04  <TrueBrain> which .. isnt there
13:55:09  <TrueBrain> but it works if you just us iculx
13:55:11  <TrueBrain> ugh
13:55:39  <LordAro> tbf, there is a `.. | sed s/-licu/-lsicu/g` in config.lib
13:55:53  <LordAro> wanna bet those files haven't existed for years?
13:56:20  <TrueBrain> so remove those lines in config.lib?
13:56:39  <LordAro> probably
13:57:08  <LordAro> line 1790ish
13:57:51  <TrueBrain> lets see if that helps
14:00:16  <TrueBrain> okay, compiles without it
14:00:51  <TrueBrain> and that leaves a dynamic link to icu
14:00:52  <TrueBrain> lolz
14:00:56  <TrueBrain> so .. that is not really helping :D
14:01:15  <TrueBrain> guess that is why the sicu is done
14:01:22  <TrueBrain> as of those, there are no .so
14:01:25  <TrueBrain> basically, the same issue as OSX :)
14:01:28  <LordAro> hrm, ok
14:01:43  <TrueBrain> I will leave the symlink in for now
14:01:55  <TrueBrain> ah, same reason that liblzo2 was done, I am guessing
14:01:59  <TrueBrain> to make it static, instead of dynamic
14:02:04  <TrueBrain> for generic builds, that is a good question
14:02:28  <TrueBrain> right ... I think I just don't publish generic linux binaries for now
14:02:34  <TrueBrain> we need someone to figure out how to do that correctly and properly
14:02:44  <TrueBrain> sounds good?
14:05:57  *** Progman has quit IRC
14:07:04  *** nielsm has joined #openttd
14:09:41  <Eddi|zuHause> <TrueBrain> andythenorth: also the comment: I did not test this, in the PR, didnt help :D <-- i don't think i would have come up with testing savegame compatibility, even if i did test it. plus the original ticket already had a "i tested it" comment
14:10:07  <TrueBrain> Eddi|zuHause: I agree, I doubt I would even noticed this issue
14:10:35  <TrueBrain> I am a bit annoyed regression did not pick this up, but I couldnt think up a way it would
14:11:26  <Eddi|zuHause> regression savegame would have to be bumped to current version with each savegame bump
14:14:49  <Eddi|zuHause> but also, the regression savegame needs to have an order list
14:15:19  <Eddi|zuHause> so we need to come up with a savegame that contains one of each object
14:15:45  <nielsm>  <- should I be anal about commit messages here?
14:15:48  <Eddi|zuHause> so how do we judge which parts are covered by the savegame?
14:16:07  <nielsm> the first one "road vehicles" surely can't be tiles, "road stations" can
14:16:23  <nielsm> and the last one I think should be "Docs: Fix spelling in comments"
14:17:26  <Eddi|zuHause> can you fix them yourself without the author's involvement?
14:17:44  <TrueBrain> I would request those changes; he is making more PRs, so having good commit messages surely helps in the future too
14:17:56  <TrueBrain> LordAro: turns out, liblzo2 isn't detected via pkg-config; that is why things are so weird there
14:21:26  <Eddi|zuHause> maybe we should just put a bunch of random real world savegames into the regression test?
14:21:33  <DorpsGek_II> [OpenTTD/OpenTTD] nielsmh requested changes for pull request #7009: Improve pathfinder behaviour for finding road depots (fix #7001; see #6410, #6928, #6929)
14:21:49  <Eddi|zuHause> by people who have different playstyles, to push up the coverage
14:22:14  <nielsm> Eddi|zuHause, and then have a GS or AI script check that various things are as expected after load?
14:22:15  <LordAro> TrueBrain: isn't, or wasn't? :p
14:22:22  <TrueBrain> both
14:22:31  <TrueBrain> there is no pkg-config for lzo2 :P
14:22:55  <LordAro> there is for me...
14:23:32  <TrueBrain> not on Debian
14:23:52  <Eddi|zuHause> nielsm: yeah, something like that. output as many random stats as you can, and compare with previous run
14:24:24  <TrueBrain> LordAro: and config.lib doesn't use it
14:24:34  <LordAro> TrueBrain: so it doesn't, how odd. mingw & arch have one
14:24:42  <TrueBrain> Linux ... pfft
14:24:44  <LordAro> TrueBrain: yeah, i remember there being a special case for it
14:25:00  <TrueBrain> I am trying now to make a full static linux build
14:25:03  <TrueBrain> just EVERYTHING in it
14:25:06  <TrueBrain> see what that does :P
14:26:40  <TrueBrain> fails to link .. ofc it does ..
14:26:41  <TrueBrain> lol
14:27:17  <TrueBrain> I would like to say I am surprised .. I am not :D
14:27:21  <TrueBrain> this really is just a mess
14:27:36  <LordAro> did i hear someone say cmake?
14:27:42  <TrueBrain> yeah ..
14:27:49  <TrueBrain> so no generic linux binaries for the time being
14:27:50  <TrueBrain> fuck this
14:28:18  <LordAro> can you not just build with an older distro?
14:28:22  <dwfreed> meson
14:28:43  <TrueBrain> LordAro: no clue; also really tired of trying to figure this out
14:28:53  <TrueBrain> please, feel free to pick it up :)
14:28:56  <dwfreed> LordAro: the issue is 1) you still need to make the build static; or 2) you have to deal with SONAME changes
14:29:56  <TrueBrain> owh, right, I am missing Source and Docs tarballs for releases
14:29:57  <TrueBrain> forgot about those
14:30:21  <LordAro> dwfreed: true
14:30:36  <dwfreed> something something meson
14:30:41  <DorpsGek_II> [OpenTTD/OpenTTD] TrueBrain commented on pull request #7020:  Add: [AzurePipeline] introducing a release pipeline
14:30:42  <DorpsGek_II> [OpenTTD/OpenTTD] TrueBrain closed pull request #7020:  Add: [AzurePipeline] introducing a release pipeline
14:30:59  <LordAro> dwfreed: you're welcome to try :p
14:31:21  <DorpsGek_II> [OpenTTD/OpenTTD] msikma commented on pull request #6986: Allow the center tile to always get a house when playing with 3x3/Better
14:32:26  <TrueBrain> how ... did we do docs tarballs
14:32:27  <TrueBrain> hmm
14:40:56  <DorpsGek_II> [OpenTTD/OpenTTD] J0anJosep updated pull request #7009: Improve pathfinder behaviour for finding road depots (fix #7001; see #6410, #6928, #6929)
14:40:58  <DorpsGek_II> [OpenTTD/OpenTTD] J0anJosep dismissed a review for pull request #7009: Improve pathfinder behaviour for finding road depots (fix #7001; see #6410, #6928, #6929)
14:41:54  <DorpsGek_II> [OpenTTD/OpenTTD] nielsmh approved pull request #7009: Improve pathfinder behaviour for finding road depots (fix #7001; see #6410, #6928, #6929)
14:45:18  <TrueBrain> hmm .. how do I move all the files in another folder, including hidden files?
14:45:22  <TrueBrain> mv * new_folder/
14:45:27  <TrueBrain> of course does't work for hidden files
14:46:25  <nielsm> 'find' non recursive?
14:47:49  <DorpsGek_II> [OpenTTD/OpenTTD] nielsmh commented on issue #6981: Ubuntu 16.04, compile warning for squirrel.cpp
14:47:50  <DorpsGek_II> [OpenTTD/OpenTTD] nielsmh closed issue #6981: Ubuntu 16.04, compile warning for squirrel.cpp
14:50:01  *** Samu has joined #openttd
14:51:33  <TrueBrain> nielsm: that could work
14:51:33  <TrueBrain> find . -maxdepth 1 -not name . -not -name openttd-$(Build.BuildNumber) -exec mv {} openttd-$(Build.BuildNumber)/ \;
14:51:35  <TrueBrain> lol
14:52:46  <LordAro> mv ./* ./.* new_folder
14:53:13  <LordAro> oh wait, that tries to move ..
14:53:27  <TrueBrain> :D
14:53:53  <LordAro> ./.[!.]*
14:53:55  <LordAro> much better.
14:54:19  <Samu> This means you need to rebase before this Pull Request will pass its checks.
14:54:29  <Samu> i'm getting this in several of my prs
14:54:41  <TrueBrain> LordAro: not really, but yes :P I like the find more in that case :D
14:54:55  <Samu> how do i rebase if i have nothing to change?
14:55:16  <LordAro> Samu: same as normal, except don't make any changes :p
14:55:27  <Eddi|zuHause> <TrueBrain> hmm .. how do I move all the files in another folder, including hidden files? <-- wouldn't it be easier to go up one folder and rename the existing one?
14:55:37  <LordAro> (assuming interactive rebase, leave all the commits as 'pick')
14:55:51  <LordAro> (though you can just leave out the interactive -i flag anyway)
14:56:31  <Samu> git rebase
14:56:41  <Samu> just that?
14:56:49  <TrueBrain> Eddi|zuHause: I dont know that name of tha tfolder. I tried that first, becomes a lot of lines too :D
14:56:51  <Samu> no, git rebase origin/master'
14:56:54  <Samu> meh i forgot
14:56:56  <LordAro> Samu: that's the one
14:57:04  <Samu> oki, gonna try
14:57:06  <LordAro> Samu: remember to fetch first
14:57:13  <LordAro> so that master is up to date
14:58:00  <Samu> fetch? uhm, what
14:58:39  <LordAro> just run `git fetch origin`
14:58:51  <LordAro> it updates your copies of the remote branches
14:59:41  <Samu> oh, i think github desktop does that when i switch branches automatically
14:59:48  <Samu> not sure if it's the same
14:59:53  <TrueBrain> yippie, source tarball works :) Now I need to add another docker to create the doxygen stuff .. but that is for another day :P
15:00:14  <LordAro> Samu: quite possibly
15:01:24  <Samu> Patric Stout has recently spammed my email :)
15:01:45  <Eddi|zuHause> TrueBrain: does "ls -A" help?
15:02:19  <Eddi|zuHause> it's like "ls -a", except it skips . and ..
15:05:30  <Eddi|zuHause> something like "ls -A | awk BEGIN { system('md newfolder') } { system('mv  newfolder') }
15:05:34  <Eddi|zuHause> modulo awk syntax
15:05:51  <TrueBrain> I like my find better :P
15:06:13  <TrueBrain> but tnx :D Glad I am not the only one who finds this non-trivial :P
15:06:56  <Eddi|zuHause> these kinds of tasks are rare enough for me to just open a filebrowser and do this with the mouse...
15:06:59  <LordAro> mv `pwd` `pwd/../new_folder
15:07:06  <LordAro> except with the missing backtick
15:07:08  <TrueBrain> Eddi|zuHause: hard to script in a pipeline :D
15:07:18  <TrueBrain> LordAro: you cannot move your current folder :)
15:07:21  <TrueBrain> you lock yourself :P
15:07:30  <DorpsGek_II> [OpenTTD/OpenTTD] nielsmh opened issue #7021: Version names truncated after move to git
15:07:55  <LordAro> F=`pwd` cd ..; mv ...; cd new_folder
15:08:16  <TrueBrain> nielsm: related to ?
15:08:18  <LordAro> nielsm: wasn't there already an issue for that?
15:08:30  <LordAro> yes
15:08:51  <Eddi|zuHause> TrueBrain: the "beauty" of my awk is that you can create the folder after you made the list of all files, so you don't have to make stretches to exclude that again
15:09:12  <Eddi|zuHause> though i suppose there might be a way to do that in find too
15:09:19  <DorpsGek_II> [OpenTTD/OpenTTD] LordAro commented on issue #5326: NETWORK_REVISION_LENGTH causing "String too long for destination buffer" git branch with length > 8
15:09:20  <DorpsGek_II> [OpenTTD/OpenTTD] LordAro closed issue #5326: NETWORK_REVISION_LENGTH causing "String too long for destination buffer" git branch with length > 8
15:09:26  <LordAro> fixed.
15:09:36  <TrueBrain> :D
15:09:46  <LordAro> technically the wrong way round, but technical details were better
15:12:57  <Eddi|zuHause> why not cut out a bit in the middle to fit the existing size?
15:13:16  <Eddi|zuHause> or even at the beginning
15:13:30  <Eddi|zuHause> the hash bit in the end should be the most different usually
15:16:38  <Eddi|zuHause> is that string displayed anywhere?
15:16:47  <Eddi|zuHause> serverlist?
15:17:56  *** Wormnest has joined #openttd
15:20:57  <nielsm> TrueBrain, oh, there was... I just couldn't find it again
15:21:02  <Samu> I don't understand this comment
15:21:38  <Samu> how would I detect wether a ship would be using such tiles? impossible
15:22:55  <Samu> unless i run the pathfinder for every ship and see if they run into them? that's madness
15:23:46  <nielsm> yeah that's not reasonable
15:24:08  <nielsm> otherwise you'd need to store per water tile when it was last visited by a ship
15:24:28  <nielsm> and e.g. prevent clearing it if it was sailed on recently
15:25:18  <Samu> so it's possible?
15:25:21  <TrueBrain> wow, Doxygen gives tons of warnings :D
15:25:54  <Samu> well there's a solution i didn't think of
15:26:32  <DorpsGek_II> [OpenTTD/OpenTTD] Eddi-z commented on issue #7021: Version names truncated after move to git
15:27:40  <Samu> Quote Reply crashes my browser, plz fix
15:28:13  <Samu> can't reply to him
15:28:49  <Eddi|zuHause> or how about we make a "long" version string (displayed in the main menu, logfiles and whatnot) and a "short" version string (for network purposes)?
15:29:03  <Eddi|zuHause> where the "short" string is guaranteed to fit into the buffer
15:29:13  <Eddi|zuHause> by the build system
15:30:49  <Eddi|zuHause> "short" meaning strip the unimportant bits like "openttd" and "branchname", and just "1.9.0-alpha5" or "gXYZABC"
15:30:54  <TrueBrain> not a bad idea; 15 chars is too short to have a decent hash where collision is unlikely
15:31:02  <TrueBrain> but if you extend to 32 chars
15:31:04  <TrueBrain> you should be fine
15:31:19  <TrueBrain> I like your idea to just hash what-ever the version is
15:31:26  <TrueBrain> means it won't ever matter again
15:31:30  <TrueBrain> debugging is a bit harder, but meh
15:31:44  <Eddi|zuHause> the hash is fine, if it's not used for display purposes
15:31:51  <TrueBrain> exactly
15:31:55  <DorpsGek_II> [OpenTTD/OpenTTD] nielsmh commented on issue #7021: Version names truncated after move to git
15:32:06  <TrueBrain> in conflict, it is a bit difficult to show why it is a conflict
15:32:50  <TrueBrain> anyway, the UDP packet is also used for server listing
15:32:58  <nielsm> or backport the JGRPP thing where multiplayer games can have more newgrfs?
15:33:03  <nielsm> I'm not sure what exactly it does
15:33:27  <Eddi|zuHause> probably send out multiple packages?
15:33:31  <TrueBrain> the whole MS protocol needs rework btw, so that cn be part of it
15:36:11  *** andythenorth has joined #openttd
15:42:26  <Samu> i can't Quote Reply
15:42:28  <Samu> bah
15:42:46  <TrueBrain> there are 12 jobs in front of you in the queue .. lolz ..
15:44:27  <DorpsGek_II> [OpenTTD/OpenTTD] nielsmh commented on pull request #6998: Feature #4115: default company colour setting
15:45:47  <Samu> question, can you Quote Reply on odisseus reply?
15:45:57  <Samu> it crashes me browser
15:46:15  <nielsm> yes, works fine for me
15:46:19  <Samu> damn Edge
15:46:51  <nielsm> I'd suggest just using @odisseus in the reply to highlight him
15:46:52  <LordAro> just... reply?
15:47:06  <Samu> ok
15:47:41  <andythenorth> oof are we still doing 'my first security' in forums? :P
15:47:43  <andythenorth> yup
15:47:48  <DorpsGek_II> [OpenTTD/OpenTTD] nielsmh closed issue #7001: YAPF can't find road depot, but NPF can
15:47:49  <DorpsGek_II> [OpenTTD/OpenTTD] nielsmh merged pull request #7009: Improve pathfinder behaviour for finding road depots (fix #7001; see #6410, #6928, #6929)
15:47:58  <Eddi|zuHause> andythenorth: ?
15:48:06  <andythenorth> that thread Eddi|zuHause
15:48:18  *** glx has joined #openttd
15:48:18  *** ChanServ sets mode: +v glx
15:49:38  <DorpsGek_II> [OpenTTD/OpenTTD] andythenorth commented on pull request #6998: Feature #4115: default company colour setting
15:50:40  <DorpsGek_II> [OpenTTD/OpenTTD] SamuXarick commented on pull request #6931: Change: Prevent town growth from blocking ships
15:50:44  <DorpsGek_II> [OpenTTD/OpenTTD] glx22 opened pull request #7022: Add: generate_widget.vbs to allow script_window.hpp enums generation …
15:51:55  <Samu> the <names> were cut off
15:52:02  <Samu> for some reason
15:52:07  <Samu> i copied irc chat
15:52:40  <Samu> i'm starting to hate
15:52:40  <nielsm> I edited your comment to kinda fix that then ;)
15:53:26  <Samu> thx
15:59:22  <DorpsGek_II> [OpenTTD/OpenTTD] andythenorth commented on pull request #6998: Feature #4115: default company colour setting
16:00:31  <Borg> guys.. is there a way that user can execute GS script?
16:00:43  <Borg> or request execution.. or set some flag?
16:01:03  <DorpsGek_II> [OpenTTD/OpenTTD] andythenorth commented on pull request #6931: Change: Prevent town growth from blocking ships
16:01:15  <nielsm> as far as I know, game scripts have to be there from the beginning of the game, and they only run on the server
16:01:41  <Borg> yeah, they run on the server..
16:01:52  <andythenorth> well it also runs locally in SP, to be strict
16:01:57  <Borg> but I thinking if.. GS can get some data from company.. that is user selectable
16:02:06  <Borg> like.. some flags.... variable..
16:02:08  <andythenorth> there is GS communication via signs
16:02:13  <andythenorth> Zuu did it
16:02:17  <Borg> hmm right..
16:02:28  <Borg> can I communicate by chat?
16:03:02  <andythenorth> with GS?
16:03:03  <andythenorth> nope
16:03:07  <Borg> ok..
16:03:11  <andythenorth> chatbot GS interface? o_O
16:04:28  <Borg> no.. I have some weird ideas.. for fun..
16:04:38  <Borg> like... devident payments... via GS
16:05:24  <Samu>
16:05:39  <Samu> it benefits AIs :(
16:05:52  <Samu> and those long server games
16:05:54  *** Gja has joined #openttd
16:06:03  <Samu> where ppl build their stuff then leave for 10 hours
16:06:42  <andythenorth> let's play
16:06:53  <andythenorth> the game is 'save this outdated patch from the bonfire'
16:07:00  <andythenorth> what is this even for?
16:07:40  <nielsm> if a train takes 2 hours to go from A to B and back
16:07:48  <nielsm> and is declared to be more than 2 hours late
16:07:58  <nielsm> then it may just as well have been said to have skipped a cycle
16:08:26  <nielsm> so you can subtract 2 hours from the lateness
16:08:53  <Samu> what if I make it into a game setting?
16:10:30  <Samu> lost ships (blocked by town growth) are also heavy on cpu
16:10:38  <Samu> i think it's a benefit
16:11:02  <DorpsGek_II> [OpenTTD/OpenTTD] andythenorth commented on issue #5981: Unify appearance and position of location buttons (wanted contributions-list)
16:11:19  <DorpsGek_II> [OpenTTD/OpenTTD] andythenorth commented on issue #5981: Unify appearance and position of location buttons (wanted contributions-list)
16:12:54  <andythenorth> the better check would be the width of uninterrupted water
16:13:04  <andythenorth> in some kind of shaped search
16:13:07  <andythenorth> but that's faff
16:14:51  <andythenorth> that's what FIRS does, to prevent blocking ship routes with industries
16:15:18  <nielsm> checking for one or more entirely water tiles next by might be enough
16:15:18  <Samu> faff? must check
16:16:08  <Samu> new english word never heard before :p
16:16:51  <Samu> where is that code in firs, might copy paste from it
16:17:01  <dwfreed> "An overcomplicated task, especially one perceived as a waste of time."
16:17:04  <andythenorth> it uses the FF water tile
16:17:14  <andythenorth> you can't reuse it
16:17:32  <andythenorth> you'll have to do a directional tile search
16:19:53  *** Gabda has joined #openttd
16:22:57  <Samu> where
16:23:33  <DorpsGek_II> [OpenTTD/OpenTTD] nielsmh commented on pull request #6931: Change: Prevent town growth from blocking ships
16:24:09  <andythenorth>
16:24:11  <andythenorth> 255
16:24:16  <andythenorth> is tile 0xFF
16:24:27  <andythenorth> but that's not available to towns afaik
16:24:46  <andythenorth> it's a completely different concept
16:25:04  <nielsm> yeah it's a special rule in the industry build routine
16:25:10  <Samu> all of them
16:25:18  <andythenorth> nope
16:25:24  <andythenorth> just 4
16:25:29  <andythenorth> and 5
16:25:43  <andythenorth> 4 will block
16:25:48  <andythenorth> 5 might block a ship in the corner
16:25:55  <andythenorth> the rest should be permitted
16:26:06  <nielsm> I want cities to build on 1, 2, 3, and 6, because anything else looks like wasted space
16:26:16  <andythenorth> +1
16:26:47  <Samu> ok, so i need to check if the tile breaks the connection from the tile entry to the tile exit
16:26:48  <DorpsGek_II> [OpenTTD/OpenTTD] glx22 opened pull request #7023: Use some consistency for project dependencies determination
16:27:04  <Samu> but there are certain fat buildings
16:27:11  <Samu> that actually use all
16:27:16  <Samu> the water
16:27:19  <Samu> i think marketplace
16:27:22  <Samu> is one of them
16:29:17  <Samu> unless that was fixed recently, not sure
16:29:20  <nielsm> but I agree with andythenorth, it's too much work and too much complexity to protect players from their own stupidity
16:29:21  <Samu> vev
16:29:24  <nielsm> players and AI alike
16:29:25  <Samu> brb
16:29:32  <andythenorth> to make this worthwhile
16:29:34  <andythenorth> you also have to
16:29:44  <andythenorth> - prevent industries building on half slopes (including newgrf)
16:29:48  <andythenorth> - prevent players doing it
16:30:08  <andythenorth> - prevent players terraforming to the same effect
16:30:11  <nielsm> you can't prevent players from sabotaging others' ships this way anyway
16:30:18  <andythenorth> - prevent AIs building
16:30:23  <andythenorth> - prevent AIs terraforming
16:30:35  <andythenorth> it's literally boiling the ocean
16:31:46  <Samu> i kinda did that already
16:31:55  <Samu> in another patch
16:32:09  <andythenorth> need to prevent anything build on coasts
16:32:15  <andythenorth> e.g. FIRS industries etc
16:32:24  <andythenorth> need to prevent bridges over diagonal channels
16:32:24  <Samu> sec, let me find
16:32:39  <andythenorth> need to prevent canals on water
16:32:44  <andythenorth> need to prevent water objects
16:32:54  <andythenorth> need to prevent terraforming
16:32:54  <Samu>
16:33:43  <andythenorth> I'm not being mean, I just can't see this succeeding
16:33:48  <Samu> it's not exactly the same, but tries to prevent imminent ship getting stuck when building
16:33:54  <Samu> something
16:33:56  <andythenorth> anyway, I've said all I can say on it
16:33:59  <Samu> like all that u said
16:34:05  <milek7> hm, maybe i could pr my old patch for raising companies limit to 240?
16:34:09  <milek7> though maybe it is better to just extend tile size, instead of weird bitpacking used in patch
16:35:10  <Wolf01> andythenorth: pause a bit and help me, I need to make 2 stage reduction gearbox for a turntable, I was thinking about 2 epicyclic gearboxes but I don't understand how to connect it :P
16:35:27  <Samu> and by stuck, I mean deadlocked, sandwiched between two industries with no way to send it anywhere else
16:35:41  <Samu> or 2 other things, not just industries
16:36:10  <andythenorth> Wolf01: epicyclics - what are you using for the ring gear?
16:36:16  <andythenorth> I'd probably just google tbh :)
16:36:23  <andythenorth> mechanisms aren't my strength
16:36:43  <Wolf01> Old style turntables, the ones with the teeth inside
16:37:19  <andythenorth> I'd be inclined to go big :P
16:37:46  <Wolf01> I need to put that ON the arm, not at the base :P
16:38:42  <andythenorth> hmm
16:38:48  <andythenorth> go big
16:41:56  *** Gabda_ has joined #openttd
16:48:02  <Samu> brb, checking which buildings build on the entire water
16:49:17  <andythenorth> none should do that
16:49:31  <andythenorth> it should be invalid
16:50:34  <Samu> i wondered if that was a bug
16:50:49  <Samu> and if it was fixed meanwhile
16:51:13  *** andythenorth has left #openttd
16:55:01  *** Progman has joined #openttd
16:58:44  <DorpsGek_II> [OpenTTD/OpenTTD] LordAro commented on pull request #7023: Use some consistency for project dependencies determination
17:07:26  <Samu> I don't see it happening, well, I must have seen it wrong maybe
17:08:41  <DorpsGek_II> [OpenTTD/OpenTTD] pi1985 opened pull request #7024: Rail fences in snow or desert
17:16:00  *** frosch123 has joined #openttd
17:21:30  <Samu> well I'm gonna assume I either saw it wrong or it was fixed
17:21:37  <Eddi|zuHause> that diff is a bit large for such a simple feature?
17:21:47  <Samu> that means, it eases what i'm doing
17:22:23  <LordAro> an frosch123
17:22:24  <LordAro> quak
17:23:23  <Samu> still i'm gonna use an assert
17:23:35  <Samu> just for confirmation
17:24:21  <DorpsGek_II> [OpenTTD/OpenTTD] Eddi-z commented on pull request #7024: Rail fences in snow or desert
17:25:25  <LordAro> Eddi|zuHause: pretty sure it doesn't require a savegame bump either
17:25:54  <Eddi|zuHause> i'll leave complaining about the commit message for a later stage
17:26:21  <LordAro> maybe they'll work it out from the CI failure
17:26:24  <LordAro> you never know
17:26:44  <Eddi|zuHause> i don't understand what the CI failure is about
17:27:12  <nielsm> I disagree with that change on the principle that it must be intentional fences are not placed in desert/snow, and it's been like that since the original game
17:27:20  <LordAro> also that
17:27:35  <Eddi|zuHause> i would have suggested a setting
17:28:01  <Eddi|zuHause> but i wouldn't know where to put that, in the already cluttered and inconsistent gui
17:29:33  <nielsm> could go all the way and make railway fences a newgrf feature, with the newgrf controlling where they can appear
17:30:27  <LordAro> i have no issues with leaving it as part of the game
17:30:43  <Eddi|zuHause> nielsm: at the very least, it's probably not useful to have the fences constantly appear and disappear with varying snowline
17:39:58  <nielsm> TrueBrain: the commit checker failure here has really bad diagnostics:
17:40:41  <nielsm> as in, all the docker progress reporting is included as part of the error text
17:59:44  *** Progman has quit IRC
18:01:33  *** andythenorth has joined #openttd
18:05:15  <Samu> Merge remote-tracking branch 'upstream/master' into prevent-town-grow…
18:05:23  <Samu> is this something I should have done?
18:05:30  <glx> probably never triggered during testing nielsm
18:05:31  <Samu> what happens if I push now?
18:05:55  <Samu> I've got 109 changes ahead or whatever
18:06:03  <nielsm> if you push you'll have a merge commit
18:06:14  <glx> I think you should have use rebase
18:06:33  <nielsm> whether that's acceptable depends on whether the PR is intended to be squashed or rebased onto master
18:06:58  <Samu> not sure what to do, so let's push to see what happens
18:07:11  <DorpsGek_II> [OpenTTD/OpenTTD] SamuXarick updated pull request #6931: Change: Prevent town growth from blocking ships
18:07:23  <glx> but merge commits in a PR just add useless stuff for review I think
18:09:43  <glx> at least it's a clean merge :)
18:12:02  <glx> you can do "git rebase -i HEAD^" to drop the empty merge commit
18:12:25  <Samu> ok let me try
18:13:24  <glx> it will open an editor with something like "pick ... Merge remote..." on first line
18:14:02  <glx> replace pick with drop, save, close editor and follow the instruction on command line
18:14:15  <Samu> uhm, no i dont have that
18:14:34  <TrueBrain> nielsm: I welcome any PR to fix that :)
18:14:51  <glx> it's command line stuff
18:15:09  <Samu>
18:15:24  <Samu> got a whole lot of changes, maybe the 109 changes?
18:15:31  <Samu> didn't count
18:16:57  <Samu> the newest change is at the bottom
18:16:59  <Samu> it's
18:17:09  <Samu> pick effb7da5b Doc: Fix spelling in comments.
18:17:27  <glx> but HEAD^ should show only the top commit
18:17:27  <Samu> yeah, i'm not sure what i've done
18:17:53  <nielsm> when you have a merge commit HEAD^ is ambigious, since HEAD has two parents
18:18:05  <glx> ah
18:18:30  <TrueBrain> always rebase against upstream/master
18:18:39  <TrueBrain> if you follow that rule, you will be fine in 99.99% of the cases :)
18:18:48  <TrueBrain> (just don't forget to fetch it once in a while :D)
18:19:03  <nielsm> I'd say move the branch pointer locally to the previous end of branch commit, then checkout the branch again
18:21:28  <Samu> # Rebase 2d58ff2ac..6d44581b7 onto 2d58ff2ac (108 commands)
18:21:50  <Samu> explain me what to do step by step :p im noob in command line stuff
18:23:14  *** gelignite has joined #openttd
18:23:39  <nielsm> delete everything in the file, save, exit the editor, and do something different :)
18:23:51  <nielsm> that rebase you've started is not going to get any useful result
18:24:14  <DorpsGek_II> [OpenTTD/OpenTTD] pi1985 commented on pull request #7024: Rail fences in snow or desert
18:25:13  <Gabda_> I think if you checkout your commit, make a new branch, and rebase that to the master, you will be OK
18:26:18  <Gabda_> in this case you will rebase that one commit you made
18:27:30  <andythenorth> are rail fences not solved in newgrf?
18:28:24  <andythenorth> seems not
18:28:44  <Eddi|zuHause> no
18:29:35  <peter1138> hi
18:29:41  <DorpsGek_II> [OpenTTD/OpenTTD] andythenorth commented on pull request #7024: Rail fences in snow or desert
18:29:49  <andythenorth> lo peter1138
18:31:09  <peter1138> Hmm, need to make a Lego display cabinet. I'm thinking of using that sticky tape stuff.
18:33:22  <andythenorth> duck tape? o_O
18:36:30  <peter1138> Nah the stuff with Lego studs.
19:08:06  <DorpsGek_II> [OpenTTD/OpenTTD] SamuXarick updated pull request #6931: Change: Prevent town growth from blocking ships
19:11:58  <frosch123> andythenorth: <- more context
19:12:43  <frosch123> oh, you found it yourself :)
19:12:57  <andythenorth> I read all issues yesterday :)
19:13:13  <andythenorth> I PR-ed yours :P
19:13:20  <andythenorth> can you review yourself? o_O
19:13:41  <frosch123> yes, i got like 300 mails
19:13:57  <andythenorth> I got 300 highlights here :(
19:14:13  <frosch123> andythenorth: if i were convinced of my patch, i would have committed it back then :)
19:14:16  <TrueBrain> right, this means LordAro no longer has any excuse, right?
19:14:40  <LordAro> uwot
19:14:51  * andythenorth wonders how many of the patches solve things worth solving
19:15:00  <andythenorth> rhetorical question
19:16:26  <TrueBrain> boo, LordAro has no auto-invite on his IRC
19:17:33  <andythenorth> boo
19:17:55  <TrueBrain> and I guess gratz LordAro and blablabla
19:18:51  <LordAro> nothing for me to merge :(
19:19:01  <TrueBrain> that is fully in your own control to fix :D
19:19:07  <nielsm> LordAro this one :)
19:19:52  <Xaroth> o7 LordAro
19:20:57  <andythenorth> once we publish nightlies, we can let code quality slip, right?
19:21:02  <andythenorth> because the players test it?
19:21:04  <andythenorth> o_O
19:21:06  <LordAro> ofc
19:21:18  <TrueBrain> so nothing changes, right?
19:21:24  <andythenorth> says TrueBrain
19:21:28  <andythenorth> must be true
19:21:34  <TrueBrain> haters gotta hate hate hate hate
19:21:41  <Samu> thx Gabda
19:21:42  <andythenorth> how much longer can I hide from Horse?
19:21:46  <andythenorth> this sprite generator :(
19:22:04  <DorpsGek_II> [OpenTTD/OpenTTD] frosch123 commented on pull request #6990: Fix: Correct display of industry requires/produces in Build Industry window
19:23:42  <frosch123> oh, the issue is the cargo suffix, right?
19:24:29  <nielsm> yes
19:26:09  <nielsm> and that the cargos sort-of have a specific order for industries
19:26:25  <nielsm> while for CARGO_LIST they are in "system order"
19:26:35  <frosch123> alphabetic
19:26:47  <nielsm> I guess that's what FOR_ALL_SORTED_CARGOSPECS means yes
19:27:18  <DorpsGek_II> [OpenTTD/OpenTTD] LordAro commented on pull request #6990: Fix: Correct display of industry requires/produces in Build Industry window
19:33:48  <TrueBrain> so, source bundle, docs bundle, windows bundles, macos bundles .. guess I just need to test out if anightly is produced correctly
19:34:09  <andythenorth> then cookies
19:34:57  <LordAro> TrueBrain: did you get exes working?
19:35:52  <TrueBrain> yes
19:35:57  <TrueBrain> but only for stable releases
19:36:01  <TrueBrain> so not for nightlies
19:36:08  <TrueBrain> nightlies were called: openttd-trunk-r12345
19:36:10  <TrueBrain> that is silly now
19:36:20  <TrueBrain> is it okay to just name them: openttd-g123134 ?
19:36:28  <TrueBrain> or do we want openttd-master-g1231231
19:36:39  <TrueBrain> (with the ingame version being either just 'g1231451' or 'master-g123131'?
19:36:46  <TrueBrain> or .. 'nightly'?
19:37:13  <LordAro> "openttd" seems redundant
19:37:25  <Alberth> it's always master, wouldn't it?
19:37:32  <LordAro> oh, filenames, rather than versions?
19:38:02  <TrueBrain> the main prefix is always openttd- :D
19:38:02  <nielsm> for nightlies use date instead of git revision
19:38:07  <Alberth> or it would be a special version, like cargo-dist  ?
19:38:21  <nielsm> so you have a sortable number in the filename
19:38:32  <TrueBrain> special versions are currently opetntd-custom-<date>-<branch>-<gitversion>
19:38:50  <TrueBrain> nielsm: with or without a nightly/master prefix?
19:38:55  <LordAro> for nightlies, i'd say openttd-nightly-YYYYMMDD
19:39:02  <nielsm> +1
19:39:05  <nielsm> to LordAro
19:39:21  <TrueBrain> and ingame ngihtly-YYYYMMDD ?
19:39:36  <LordAro> yeah
19:39:37  <nielsm>
19:39:42  <nielsm> is how it displays for me right now
19:39:44  <nielsm> which is fine imo
19:39:53  <LordAro> hide git hashes from the end user as much as possible
19:39:58  <TrueBrain> nielsm: not really clear it is a nightly :)
19:40:45  <LordAro> "nightly" should probably be a special case, so that patchpacks/forks can easily override
19:41:06  <DorpsGek_II> [OpenTTD/OpenTTD] Gabda87 opened pull request #7025: Add #6887: Option to show zone inside local authority boundary of towns
19:41:15  <DorpsGek_II> [OpenTTD/OpenTTD] nielsmh updated pull request #6990: Fix: Correct display of industry requires/produces in Build Industry window
19:41:38  <TrueBrain> I am also fine with how it is now ingame
19:41:40  <frosch123> LordAro: TrueBrain: i think the filename should be similar to what ottd shows ingame
19:41:41  <TrueBrain> like what nielsm showed
19:41:44  <frosch123> so no "nightly" imo
19:41:58  <TrueBrain> frosch123: that still leaves the option to show nightly- ingame :D
19:42:09  <frosch123> i would not know how to detect that
19:42:14  <TrueBrain> our filename has always been, not saying we should keep that: openttd-<type>-<find-version-result>
19:42:22  <frosch123> currently it shows the branch, but skips "master"
19:42:25  <TrueBrain> where type is 'custom' for anything weird
19:42:29  <TrueBrain> or 'trunk' for nightlies
19:42:31  <Gabda_> it is really hard to find a place for a new button
19:42:40  <nielsm> well, what if someone makes a branch for time-of-day and calls it "nightly" ? :D
19:43:12  <LordAro> lol
19:43:15  <TrueBrain> guess it also depends how we want to deal with patchpacks etc
19:43:34  <TrueBrain> I think it is more clear if ingame it reads: nightly-20190106
19:43:50  <TrueBrain> frosch123: btw, detection is not super important; I can overwrite anything
19:43:53  <TrueBrain> (during building of the nightlies)
19:44:05  <TrueBrain> findversion doesnt have to do it. findversion has to work when you checkout the source yourself :P
19:44:05  <LordAro> i think ingame nightly-YYYYMMDD works
19:44:25  <milek7> it will be confusing with multiple builds per day
19:44:32  <TrueBrain> there is only 1 nightly
19:44:33  <TrueBrain> one
19:44:35  <TrueBrain> and exactly one
19:44:37  <TrueBrain> never 2
19:44:37  <TrueBrain> 1
19:44:39  <TrueBrain> :D
19:44:41  <milek7> hm
19:44:44  <milek7> ok
19:44:50  <TrueBrain> (hence, nightly :D)
19:45:38  <Samu> nightly_2019-01-06
19:46:00  <nielsm> well, what if we get hit by a huge meteor and the atmosphere is filled with particles and nobody on the surface sees the sun again for several months or years, do we build nightlies during that long night?
19:46:14  <TrueBrain> nielsm: yes
19:46:24  <TrueBrain> but I am good with a word like 'master' too
19:46:27  <Xaroth> nielsm: I thought Samu was the pessimist?
19:46:30  <TrueBrain> just .. we always called it 'nightly'
19:46:53  <DorpsGek_II> [OpenTTD/OpenTTD] Gabda87 commented on pull request #7025: Add #6887: Option to show zone inside local authority boundary of towns
19:46:59  <TrueBrain> that would mean that if you compile a branch yourself, you get: 20190106-my_branch-g12313. IF you compile master yourself, you get 20190106-g123452. If we create the nightly, you get: nightly-20190106, and if we create a release, you get 1.9.0-beta1
19:47:06  <TrueBrain> all prefixed with 'openttd'
19:47:11  <TrueBrain> (in filename, not version)
19:47:35  <TrueBrain> not sure how patchpacks would fit in that, btw
19:47:40  <LordAro> TrueBrain: sounds good to me
19:47:53  <TrueBrain> pr-6696-20190106
19:47:55  <TrueBrain> works in that schema too
19:47:58  <TrueBrain> scheme?
19:47:59  <TrueBrain> what-ever
19:48:12  <LordAro> TrueBrain: in my mind, patchpacks (assuming they want to) would use the same mechanism as nightlies, so jgrpp-20190106
19:48:15  <TrueBrain> pr-6696-g1231312 is better, I guess
19:48:36  <TrueBrain> LordAro: that is a good idea
19:48:51  <Samu> no dates?
19:48:56  <TrueBrain> hmm .. so 'nightly' .. 'core'? 'official'? 'main'? 'upstream'?
19:49:27  <Samu> master
19:49:34  <LordAro> i like nightly better
19:49:55  <TrueBrain> we want to give room to patchpacks to grow bigger, was the idea not?
19:49:58  <Samu> nightly-master-insertdate?
19:50:12  <Samu> nightly-someoneelse-insertdate
19:50:26  <Samu> core-master-insertdate meh
19:50:56  <Samu> or just do it svn style
19:50:59  <LordAro> TrueBrain: hmm, maybe "core"
19:51:08  <Alberth> vanilla
19:51:11  <TrueBrain> oeh
19:51:16  <TrueBrain> that is much better Alberth
19:51:28  *** synchris has quit IRC
19:51:31  <frosch123> TrueBrain: whenever i joined coops nightly server, i compiled myself
19:51:52  <frosch123> so, custom compile should match the nightly :)
19:51:59  <TrueBrain> okay, fair enough
19:52:01  <LordAro> that's a good point
19:52:06  <frosch123> or there will be incompatible servers with nightly and custom
19:52:11  <Alberth> base
19:52:24  <frosch123> either "master" or ""
19:52:39  <TrueBrain> well, I guess that comes down to "network version" vs "version shown in gui" again
19:52:49  <TrueBrain> but ... hmm ..
19:52:59  <TrueBrain> with the current, it is difficult for a patchpack to work in the same flow
19:53:29  <LordAro> making "network version" separate would probably lead to people hacking client/server versions a bit more readily, which isn't something we'd want to incourage
19:54:02  <frosch123> TrueBrain: jgr uses "jgrpp" as branch
19:54:13  <LordAro> encourage*
19:54:25  <TrueBrain> so we force all forks into a branch?
19:54:29  <TrueBrain> (its fine by me btw)
19:54:38  <TrueBrain> just trying to get a sense on what I should do here :D
19:55:06  <Samu> what is the max characters allowed?
19:55:27  <frosch123> i think every "fork" that continues to sync with "master" uses a branch name
19:55:39  <TrueBrain> so .. frosch123, to hook back to your original plan, possibly it is good if we call 'master' something like 'vanilla'?
19:55:48  <frosch123> only if you abandon the origin you would make yourself master
19:55:53  <TrueBrain> 20190106-vanilla-g123131
19:56:23  <LordAro> i'm not a huge fan of "vanilla"
19:56:25  <Samu> if by master, you mean what's on github OpenTTD/OpenTTD, just say OpenTTD?
19:56:44  <TrueBrain> or we can leave 'master' in there
19:56:54  <TrueBrain> would make it a bit easier on my side, as then it would just be: openttd-<findversion>
19:56:55  <TrueBrain> always
19:56:58  <TrueBrain> (also for releases)
19:57:11  <TrueBrain> patchpacks, nightlies, etc, they all have the same form
19:57:24  <TrueBrain> only stable releases would be different
19:57:27  <frosch123> i definitely prefer openttd-<findversion>
19:57:32  <frosch123> you can change findversion though :)
19:57:33  <LordAro> ^
19:57:35  <TrueBrain> exactly :)
19:57:49  <TrueBrain> so I guess it would be fine by me if we just remove the special case for 'master'?
19:58:07  <DorpsGek_II> [OpenTTD/OpenTTD] Milek7 commented on pull request #7025: Add #6887: Option to show zone inside local authority boundary of towns
19:58:19  <LordAro> shame we don't get the date somewhere in it
19:58:25  <LordAro> maybe replace master with the date?
19:58:38  <LordAro> so openttd-YYYYMMDD-<hash>
19:58:39  <TrueBrain> findversion now does: date-branch-hash
19:58:47  <TrueBrain> but for master it is: date-hash
19:58:57  *** Borg has quit IRC
19:59:04  <TrueBrain> which I dislike on the CDN, as they are files without a clear origin :)
19:59:08  <Samu> i like teh branch name in it when i'm building 500 openttd.exes
19:59:26  <Samu> at least I know what this "openttd.exe" is about
19:59:55  <frosch123> make it "master" then, remove the 2 lines from findversion
19:59:59  <DorpsGek_II> [OpenTTD/OpenTTD] nielsmh commented on pull request #7025: Add #6887: Option to show zone inside local authority boundary of towns
20:00:05  <frosch123> "vanilla" just adds more confusion
20:00:06  <TrueBrain> I guess that is by far the easiest form :P
20:00:09  <TrueBrain> yeah, fair
20:00:27  <TrueBrain> so any patchpack, if they want to use our CDN, will have to do their work in a branch, which is totally sensible
20:00:41  <nielsm> openttd is just openttd, a fork/patchpack is not quite openttd and needs a suffix or different name
20:01:11  <TrueBrain> nielsm: you think a branch-name is not sufficient?
20:01:50  <nielsm> you can call it "vanilla" in prose to more clearly distinguish master from a patchpack, but the format name should just be "openttd"
20:02:16  <TrueBrain> either you havent read up, or I totally lost you :D Sorry :)
20:02:30  <Samu> didn't you use a M suffix for stuff different than the master?
20:02:32  <nielsm> "openttd-jgr-DATE-REVID" would be a fine name for JGRPP
20:02:36  <TrueBrain> current suggestion: VERSION being: <date>-<branch>-<githash> (for ALL branches)
20:02:41  <TrueBrain> filename prefix of openttd-
20:03:17  <TrueBrain> we can change it into <branch>-<date>-<githash>, all the same to me :)
20:03:40  <DorpsGek_II> [OpenTTD/OpenTTD] telk5093 commented on pull request #6983: Feature: Town name filtering
20:03:41  <DorpsGek_II> [OpenTTD/OpenTTD] telk5093 closed pull request #6983: Feature: Town name filtering
20:03:46  <nielsm> yeah I did just spend 15 minutes with face buried in a mobile game ;)
20:03:58  <TrueBrain> :D LIKE A BOZZ
20:05:43  <Samu> <branch>-<githash>
20:05:47  <Samu> is date important?
20:06:23  <TrueBrain> from my point of view (just as SysOp), removing the 2 special-case lines of master in, is sufficient for me
20:06:57  <nielsm> displaying "master" as branch name is also good by me
20:06:59  <TrueBrain> as that would make the resulting binaries traceable, and the code simple, which is all I really care about :)
20:07:11  <nielsm> imo it's pretty clear in meaning what "the master version" is
20:07:13  <TrueBrain> so lets go with that for now; we can change things always later if we like :P
20:07:53  <Alberth> likely the next compile farm :)
20:08:01  <TrueBrain> :D
20:08:18  <TrueBrain> openttd-<findversion> .. now that removes some code to detect 'custom' branches etc :D
20:08:33  <Alberth> nice
20:09:19  <andythenorth> in the future the CF will be AI
20:09:25  <DorpsGek_II> [OpenTTD/OpenTTD] nielsmh commented on pull request #7025: Add #6887: Option to show zone inside local authority boundary of towns
20:09:28  <andythenorth> so we won't need to do *anything*
20:10:32  <nielsm> get a squirrel to crack that nut yes
20:10:35  <nielsm> ...
20:12:40  <DorpsGek_II> [OpenTTD/OpenTTD] Gabda87 commented on pull request #7025: Add #6887: Option to show zone inside local authority boundary of towns
20:13:44  *** Wormnest has quit IRC
20:17:46  *** Gabda_ has quit IRC
20:20:51  <TrueBrain> okay, tnx all, this should work fine now :)
20:21:13  <TrueBrain> last thing to add, nice-to-have, is tag-compiling
20:21:16  <TrueBrain> but that can wait a few weeks
20:21:24  <TrueBrain> not sure how we are going to do tags with git :)
20:23:36  <Eddi|zuHause> do we do branching on the main repo?
20:24:26  <andythenorth> it would be odd not to
20:24:42  <nielsm> I asume it's going to be something like, make the 1.9 branch, prepare the release in that, make the 1.9.0 tag when it's ready, build
20:24:56  <nielsm> and if 1.9.1 becomes necessary, build more commits onto the 1.9 branch and tag 1.9.1 when that's ready
20:25:09  <TrueBrain> so a release-branch like subversion
20:25:09  <DorpsGek_II> [OpenTTD/OpenTTD] Milek7 commented on pull request #7025: Add #6887: Option to show zone inside local authority boundary of towns
20:25:11  <TrueBrain> sounds good to me
20:25:21  <andythenorth> seems easiest to continue as we are
20:25:24  <LordAro> indeed
20:25:31  <andythenorth> at work we have dev branches and tag from master
20:25:36  <LordAro> cherry-pick into the release branch much as before
20:25:37  <andythenorth> but it's not better, just different
20:25:46  <TrueBrain> means the only difference will be a flag in the release-pipeline (to build .exe and .deb yes/no .. as they only work on tags :D)
20:28:57  *** wodencafe has quit IRC
20:39:39  <glx> btw it was already possible to fake network version
20:40:50  <nielsm> making a build presenting as another version wouldn't be hard
20:41:01  <nielsm> but you'd probably run into desyncs with anything that matters
20:41:12  <andythenorth> oof
20:41:28  <glx> it's easy, many patched server do it to allow clean release builds to connect
20:41:49  <glx> but usually they know their changes don't touch the game engine
20:43:34  <glx> and you have norev clients able to connect to any norev servers ;)
20:43:52  <glx> (build from source without VCS)
20:44:39  <andythenorth> electric engines in purchase menu: pantographs up or down?
20:44:41  <andythenorth> Eddi|zuHause: ^
20:44:57  <glx> down, there's no catenary ;)
20:45:23  <Eddi|zuHause> uhm... either one is fine
20:45:25  <andythenorth> there is in the depot
20:45:33  <andythenorth> but not in the 'available trains' list :P
20:45:41  <Eddi|zuHause> there are some depots which don't have catenary
20:46:21  <andythenorth> ok down it is
20:46:25  <andythenorth> up just looks fiddly
20:49:17  *** Gja has quit IRC
20:57:23  *** wodencafe has joined #openttd
21:05:18  <nielsm> if you were selling me engines with pantograph up I'd think I was buying broken items
21:06:05  *** Gabda has quit IRC
21:10:47  *** Alberth has left #openttd
21:13:44  <andythenorth> sprite layers work in purchase list?
21:15:06  *** sla_ro|master has quit IRC
21:18:48  <DorpsGek_II> [OpenTTD/OpenTTD] Gabda87 commented on pull request #7025: Add #6887: Option to show zone inside local authority boundary of towns
21:20:26  <glx> hmm I rapidly tried to run, seems to still work but it converts CRLF to LF and of course git detects it
21:21:30  <glx> but it also created some new files
21:21:50  <glx> maybe someone forgot to run the script some time ago
21:22:20  <Samu> me
21:22:22  <Samu> ?
21:22:29  <LordAro> how interesting
21:23:49  <Samu> is it the airportmonthlycost?
21:23:53  <Samu> or whatever
21:24:10  <frosch123> andythenorth: yes, also on mouse cursor
21:24:31  <LordAro> Samu: that wouldn't create new files
21:24:38  <andythenorth> thx
21:31:27  <glx> ok it generated squirrel exports for
21:38:46  *** Progman has joined #openttd
21:38:49  <glx> but the script has been run many times after the introduction of this file, unless all changes where made manually
21:39:22  <glx> so I don't know if the script is broken, or if it's because I'm on windows
21:48:12  <andythenorth> bed
21:48:13  *** andythenorth has left #openttd
21:50:22  <Samu> glx
21:50:33  <Samu> i edited manually one of the files that is said not to edit manually
21:50:53  <Samu> actually 2 files
21:51:15  <glx> not related to it :)
21:51:15  <frosch123> glx: there should be no exports for script_info
21:51:21  <Samu> src/script/api/ai/ai_airport.hpp.sq
21:51:29  <Samu> src/script/api/game/game_airport.hpp.sq
21:51:32  <frosch123> those functions should be provided by the script, not by ottd
21:51:58  <glx> so the script doesn't too much on my side
21:52:00  <frosch123> does ottd even link when those exports are generated?
21:52:18  <glx> not tried
21:53:27  <glx> compilation fails
21:53:49  <Samu> now that think of it, I didn't include a test in the regression ai
21:53:54  <Samu> was it required?
21:54:21  <glx> suggest many tests are not in regression
21:55:50  <LordAro> tests are decidedly not complete, for sure
21:56:20  <frosch123> hmm, squirrel_Export has special cases for script_controller und script_object
21:56:26  <frosch123> but where is info_docs?`
21:58:21  <frosch123> oi, contains "svn add" and properties :p
21:58:56  <LordAro> src/3rdparty/squirrel/squirrel/sqfuncstate.cpp:88:60: warning: format '%d' expects argument of type 'int', but argument 2 has type 'SQInteger {aka long long int}' [-Wformat=]
21:58:59  <LordAro> hmm.
21:59:18  <LordAro> there's still a fair bit of svn cleanup that could be done
21:59:24  <LordAro> all the $Id$ headers, for instance
21:59:42  *** gelignite has quit IRC
22:04:23  <DorpsGek_II> [OpenTTD/OpenTTD] Milek7 commented on pull request #7025: Add #6887: Option to show zone inside local authority boundary of towns
22:10:17  <Samu> who's a bit wise operator expert :p
22:10:22  <Samu> assert(water_track == TRACK_BIT_UPPER || water_track == TRACK_BIT_LOWER || water_track == TRACK_BIT_LEFT || water_track == TRACK_BIT_RIGHT);
22:10:35  <Samu> any means to simplify code with bit wise
22:11:34  <LordAro> isn't that all the possible track bits?
22:11:42  <Samu> water_track must be one of those, but not all of them
22:11:48  <Samu> or more than one of them
22:11:55  <LordAro> oh, i see
22:12:16  <glx> it allows all in this assert
22:12:43  <LordAro> glx: i think Samu means not TRACK_BIT_UPPER & TRACK_BIT_LOWER, e.g.
22:12:47  <Samu> i mean it can't be TRACK_BIT_UPPER | TRACK_BIT_LOWER
22:12:53  <LordAro> er, ^
22:13:03  <glx> the assert says it can ;)
22:13:15  <Samu> erm really? :(
22:13:32  <milek7> no
22:13:47  <glx> hmm I'm stupid
22:14:17  <glx> indeed only one is allowed
22:14:57  <Samu> so, no bit wise magic can be done here?
22:15:15  <Samu> was trying to avoid repeating 'water_track =='
22:15:16  <LordAro> not without significant magic, i suspect
22:17:53  <Samu> I'm ensuring that fat houses, 2x2 or 2x1 don't build on tiles with more water tracks than those
22:18:07  <LordAro> gcc looks to be able to optimise it anyway
22:18:16  <frosch123> hmm, adding include guards to script_info_docs makes it generate the sq wrappers...
22:18:29  <frosch123> this looks like accidentially correct :p
22:19:04  <LordAro> Samu: is an excellent page to read through, if you want some fun
22:19:13  <LordAro> it's also mildly terrifying
22:21:28  <frosch123> hmm, actually, another "\n" at the end is sufficient to generate docs
22:22:09  <glx> ok so it's related to \r\n
22:22:27  <frosch123> i suggest we change :)
22:22:36  *** HerzogDeXtEr has quit IRC
22:22:44  <LordAro> also add checks to commit checker :>
22:24:03  <milek7> it can be obfuscated a bit
22:24:07  <milek7> __builtin_popcount(water_track) == 1
22:24:14  <milek7> ;D (sadly generated code is much worse)
22:24:26  <frosch123> glx: <- does that work?
22:34:24  <glx> 174 modified files, but only really modified, seems good
22:34:38  <glx> (stupid line endings ;) )
22:41:47  <Samu> oops, can't use assert like that, fat house checking must fail, not assert, I'm doing this wrong
22:56:43  *** frosch123 has quit IRC
22:58:33  <Samu> you were right, it doesn't build houses on tiles that are fully water
22:58:33  *** Wolf01 has quit IRC
22:58:44  <Samu> just confirmed inside the code
22:58:58  <Samu> even for fat houses
22:59:37  <Samu> unless it does that when upgrading from a small house to a fat house
23:17:49  *** nielsm has quit IRC
23:41:34  *** Progman has quit IRC
23:54:45  <DorpsGek_II> [OpenTTD/OpenTTD] gregcarlin commented on pull request #7003: Feature #6918: Add option to adjust font size separately from GUI size.
23:58:18  <DorpsGek_II> [OpenTTD/OpenTTD] LordAro commented on pull request #7003: Feature #6918: Add option to adjust font size separately from GUI size.

Powered by YARRSTE version: svn-trunk