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