IRC logs for #openttd on OFTC at 2019-03-10
⏴ go to previous day
00:00:34 <DorpsGek_II> [OpenTTD/CompileFarm] glx22 commented on issue #29: Commit checker always expect origin/master, even for non master PRs https://git.io/fhh6n
00:02:50 <DorpsGek_II> [OpenTTD/OpenTTD] glx22 commented on pull request #7354: Fix: [AzurePipelines] don't assume master as target branch when rebas… https://git.io/fhh6C
00:02:51 <DorpsGek_II> [OpenTTD/CompileFarm] TrueBrain commented on issue #29: Commit checker always expect origin/master, even for non master PRs https://git.io/fhh6W
00:02:59 <Wolf01> LordAro: I read they are tweeaking the terrain because of many bugs, so maybe they broke it more
00:03:24 <TrueBrain> glx: I think in fact that rebase should be skipped if that variable is not set
00:03:27 <TrueBrain> now I think about it some more
00:03:38 <TrueBrain> as that means it is checking a branch itself .. rebasing that is kinda weird :P
00:03:42 <TrueBrain> only PRs should be rebased, I think
00:04:12 <glx> indeed, if we build a branch we usually build head
00:04:31 <DorpsGek_II> [OpenTTD/OpenTTD] TrueBrain dismissed a review for pull request #7346: Fix: rebase to 1.9 branch for backport PRs https://git.io/fhh0N
00:04:44 <TrueBrain> so yeah, that at least is an easy fix :)
00:05:05 <TrueBrain> while at it glx, please change: git rebase origin/$SYSTEM_PULLREQUEST_TARGETBRANCH
00:05:08 <TrueBrain> into: git rebase origin/${SYSTEM_PULLREQUEST_TARGETBRANCH}
00:05:12 <TrueBrain> always pretty please escape variables :)
00:05:21 <TrueBrain> or how ever you want to call that :P
00:08:28 *** andythenorth has left #openttd
00:08:32 <TrueBrain> glx: if you need help with the Docker stuff, also in understanding etc, let me know!
00:08:43 <DorpsGek_II> [OpenTTD/OpenTTD] nielsmh requested changes for pull request #7352: Feature: Railtype flags to allow/disallow 90 degree curves. https://git.io/fhh6a
00:09:44 <TrueBrain> lol; so we went from a debate about 90 degress yes/no for ships, to allow NewGRFs to set it for trains :D I like this :)
00:10:14 <glx> well if it's an env var I think it should be as simple as using ${SYSTEM_PULLREQUEST_TARGETBRANCH} in docker shell scripts
00:10:33 <glx> we the existence checks of course
00:10:37 <TrueBrain> glx: yeah; just please name it differentl in Docker, and you will be fine indeed :)
00:10:50 <TrueBrain> just TARGET_BRANCH or something :P
00:11:31 <glx> I think I should do it for bash task, as I used an undocumented variable that may not exist in future
00:11:45 <TrueBrain> what do you mean, sorry?
00:12:59 <glx> in #7354 I assumed SYSTEM_PULLREQUEST_TARGETBRANCH was present (well I checked with 'env' first), but it's probably better to explicitely set a var
00:13:35 <TrueBrain> for 7354 etc it is fine
00:13:40 <TrueBrain> as it is Azure Pipelines specific
00:13:46 <TrueBrain> and they defined it exists for a PR
00:13:57 <TrueBrain> so in my opinion, no need to map it again, or something
00:13:58 <LordAro> Wolf01: also, this cube/pyramid/obelisk thing is almost entirely encased in rock
00:14:07 <TrueBrain> (as the bash is already executed in the context of Azure Pipelines)
00:14:20 <TrueBrain> for the Dockers how-ever it is different, as they are not always executed in the context of Azure Pipelines :)
00:14:38 <LordAro> Wolf01: am doing so, but slow
00:14:57 <Wolf01> I'm still trying to activate the nearest one... it requires a LOT of power
00:15:28 <LordAro> not too much... 1 medium + 2 small does well enough for me
00:15:33 <LordAro> i just connect my rover up
00:17:07 <peter1138> Anyone fancy touching that? :/
00:20:35 <DorpsGek_II> [OpenTTD/OpenTTD] michicc commented on pull request #7352: Feature: Railtype flags to allow/disallow 90 degree curves. https://git.io/fhh6S
00:20:51 <DorpsGek_II> [OpenTTD/OpenTTD] michicc updated pull request #7352: Feature: Railtype flags to allow/disallow 90 degree curves. https://git.io/fhhrp
00:20:52 <DorpsGek_II> [OpenTTD/OpenTTD] michicc dismissed a review for pull request #7352: Feature: Railtype flags to allow/disallow 90 degree curves. https://git.io/fhhKy
00:23:44 <peter1138> Hmm, wonder if we can do per-character font-fallback rather than all-or-nothing.
00:31:51 <peter1138> Hmm, updating that Catchment_area thing is awkward, as it'll be 1.10 changes, and 1.9 isn't released yet :p
00:44:56 <DorpsGek_II> [OpenTTD/OpenTTD] glx22 opened pull request #7355: Fix e4cc06f67: [AzurePipelines] rebase only for PRs https://git.io/fhhiU
00:46:27 <TrueBrain> that works as well I guess :D
00:46:43 <DorpsGek_II> [OpenTTD/OpenTTD] TrueBrain approved pull request #7355: Fix e4cc06f67: [AzurePipelines] rebase only for PRs https://git.io/fhhiT
00:47:06 <peter1138> Not what you were thinking of?
00:47:18 <TrueBrain> my solution was worse :P
00:47:27 <glx> I first tried with if [ -n ..]
00:47:42 <glx> but why run the task at all ? ;)
00:48:57 <glx> hmm I should include the env stuff for the docker while at it
00:50:06 <glx> or not, because it's a fix, not an addition
01:03:02 <DorpsGek_II> [OpenTTD/OpenTTD] glx22 merged pull request #7355: Fix e4cc06f67: [AzurePipelines] rebase only for PRs https://git.io/fhhiU
01:05:21 *** supermop_Home__ has joined #openttd
01:06:15 <glx> it displays 'Rebase to $(System.PullRequest.TargetBranch)' but not important as the task is skipped
01:07:21 <TrueBrain> we will fix that some day :)
01:07:38 <glx> the important part was to restore master builds
01:08:33 <glx> possible fix is to put the condition on the template call
01:09:05 <TrueBrain> no; templates are resolved on startup
01:09:09 <TrueBrain> they cannot access runtime variables
01:09:13 <TrueBrain> I found that out the hard way :D
01:09:31 <peter1138> "Rebase to target branch"
01:11:15 <TrueBrain> glx: those are parameters
01:11:29 <TrueBrain> you can resolve the full template without knowing anything about what is being build
01:11:34 <glx> yes I was just reading too fast
01:11:36 <TrueBrain> (that is in fact exactly what it does :D)
01:12:21 <TrueBrain> took me only a week to figure out how they did it :P
01:25:11 *** Thedarkb-T60 has joined #openttd
01:28:09 <glx> hmm the rebase part for commit checker won't be enough, there's also the hooks call
01:28:36 <glx> HOOKS_DIR=/git-hooks GIT_DIR=.git /git-hooks/check-commits.sh origin/master..HEAD
01:28:47 <glx> on release/1.9 that will fail
01:29:21 <glx> it's ci-commit-checker yes
01:30:17 <glx> the PR part is easy, we'll have ${TARGET_BRANCH}
01:30:50 <glx> but the non PR needs a git call to get the branch I guess
01:31:02 <TrueBrain> I think there is a variable too if it is not a PR
01:31:28 <TrueBrain> Build.SourceBranchName
01:31:47 <TrueBrain> but ... origin/master..HEAD is 0
01:31:53 <TrueBrain> so ... we can also just skip it for non-PRs :P
01:32:00 <TrueBrain> like .. the whole docker run
01:32:26 <glx> but a squash can change the commit
01:32:38 <TrueBrain> how to know what was changed?
01:32:46 <TrueBrain> currently it is not relaly working, I am guessing
01:32:50 <TrueBrain> so what ever you do, it accept it
01:33:13 <glx> yes currently it's mostly a compile check after merge
01:33:33 <TrueBrain> and isnt that enough?
01:33:39 <TrueBrain> as you cannot fix a commit message after merge anyway
01:33:44 <TrueBrain> so .. failing on that is .. rather silly :D
01:34:03 <TrueBrain> so I am also fine if you just skip this docker on non-PR
01:34:06 <TrueBrain> but that is just my 2 cents :)
01:34:14 <glx> and I guess nightly doesn't run commit checker anyway
01:34:55 <TrueBrain> indeed. releases != CI, no CI targets are executed during building of any release
01:34:59 <TrueBrain> (not even regression is called)
01:35:31 <TrueBrain> still needs the TARGET_BRANCH stuff for 1.9
01:35:41 <TrueBrain> but it makes it a tiny bit easier I guess :)
01:40:08 <glx> hmm skipping the docker won't be easy as all dockers are started by template
01:40:34 <glx> but skipping the checks inside the docker is simple
01:40:36 <TrueBrain> copy it, and condition it, I guess
01:41:39 <supermop_Home__> Europeans are pretty active for how late it is over there?
01:42:00 <TrueBrain> you don't pay my subscription! :P
01:42:18 <TrueBrain> glx: I think doing it in the docker is the wrong approach; it might seem it did his job, but didn't, or something
01:57:22 <TrueBrain> right, off to get some sleep; nn!
02:04:34 <DorpsGek_II> [OpenTTD/CompileFarm] glx22 opened pull request #30: Fix #29: don't assume master as target branch https://git.io/fhhiQ
02:05:04 <DorpsGek_II> [OpenTTD/OpenTTD] glx22 opened pull request #7356: Fix: [AzurePipelines] run commit checker only for PRs and pass it the… https://git.io/fhhi7
02:18:19 <TrueBrain> Nice work glx! if this work, ship it! (cant approve from mobile .. sorry :( )
02:19:33 <glx> I made an error in yaml but I don't find any clear doc
02:21:15 <glx> "Specify each name-value pair on a new line." I tried the usual "name: value" but that doesn't work
02:22:36 <TrueBrain> did you check Docker@1?
02:22:47 <TrueBrain> version might be important
02:26:16 <glx> tl.getDelimitedInput("envVars", "\n").forEach(envVar => {
02:26:16 <glx> command.arg(["-e", envVar]);
02:26:28 <glx> it's the format, not the version :)
02:27:06 <TrueBrain> so yeah .. 'key=value'
02:27:26 <TrueBrain> they should have done that properly
02:27:34 <TrueBrain> or add an example to the docs
02:29:17 <DorpsGek_II> [OpenTTD/OpenTTD] glx22 updated pull request #7356: Fix: [AzurePipelines] run commit checker only for PRs and pass it the… https://git.io/fhhi7
02:32:38 <glx> [command]/usr/bin/docker run -e TARGET_BRANCH=master --rm -v /home/vsts/work/1/s:/home/vsts/work/1/s -w /home/vsts/work/1/s openttd/compile-farm-ci:commit-checker
02:33:48 <glx> but the CompileFarm change is not really testable before it goes live
02:47:30 <DorpsGek_II> [OpenTTD/OpenTTD] glx22 updated pull request #7356: Fix: [AzurePipelines] run commit checker only for PRs and pass it the… https://git.io/fhhi7
02:52:14 <DorpsGek_II> [OpenTTD/OpenTTD] glx22 dismissed a review for pull request #7346: Fix: rebase to 1.9 branch for backport PRs https://git.io/fhhK2
02:53:31 *** Supercheese has joined #openttd
02:58:06 <DorpsGek_II> [OpenTTD/OpenTTD] glx22 commented on pull request #7346: Fix: rebase to 1.9 branch for backport PRs https://git.io/fhhP2
02:58:55 <peter1138> Makes the list a bit taller though.
02:59:03 <peter1138> Maybe it should crop. Hmm.
02:59:09 <glx> how does it look with font zoom ?
03:05:02 <Samu_> just installed cinebench r20 and it's all blurry
03:05:34 <Samu_> can't believe this is only available from microsoft store
03:07:45 <Samu_> rail icons in the list is actually a good idea
03:08:42 <Samu_> 1093 for my cpu, cool, time to uninstall
03:09:08 <peter1138> ^ some authors are lazy :(
03:09:30 <peter1138> That narrow gauge is the same gauge...
03:11:45 <glx> yes same icons for all types, almost useless in this case
03:26:03 *** Supercheese has joined #openttd
03:41:38 <peter1138> So should I approve this one? 7356...
03:41:45 <peter1138> Last time I approved I got it wrong :p
03:44:54 <Samu_> DeliverGoodsToIndustry conflicting again
03:50:08 <DorpsGek_II> [OpenTTD/OpenTTD] PeterN approved pull request #7356: Fix: [AzurePipelines] run commit checker only for PRs and pass it the… https://git.io/fhhXG
03:51:08 <Samu_> for (Industry *ind : st->industries_near) {
03:51:23 <Samu_> never seen a for like this before
03:51:30 <peter1138> C++11 iterator syntaxc
03:53:03 <peter1138> It's short-hand for `for (IndustryList::iterator it = st->industries_near.begin(); it != st->industries_near.end(); ++it) { Industry *ind = *it;`
03:56:51 *** octernion has joined #openttd
03:58:06 <peter1138> Only into the loop.
03:58:12 <peter1138> It does the same thing.
03:59:37 <Samu_> where is the neutral station check?
04:00:28 <Samu_> how come? what happened, i missed something
04:00:31 <peter1138> If it's neutral, st->industries_near will only contain the associated industry.
04:00:46 <peter1138> And vice-versa, ind->stations_near will only contain the neutral station.
04:01:23 <peter1138> Yeah, it was kinda merged in the wrong order, but I only realised that afterwards.
04:02:31 <peter1138> Oh, in your conflicts, I guess.
04:04:49 <peter1138> Bah, I wish github supported PR dependencies.
04:08:32 <DorpsGek_II> [OpenTTD/OpenTTD] SamuXarick updated pull request #7184: Feature: Distribute cargo to multiple stations or industries https://git.io/fh9lr
04:12:43 <Samu_> the order of _cargo_delivery_destinations.Include(ind);
04:13:06 <Samu_> i think i better do this in another way
04:13:39 <peter1138> Super build failure.
04:13:51 *** Wormnest has joined #openttd
04:14:12 <peter1138> Did you rebase and commit without even compiling it? o_O
04:14:57 <Samu_> failing somewhere else now :(
04:16:02 <Samu_> Severity Code Description Project File Line Suppression State
04:16:02 <Samu_> Error (active) E0135 class "std::set<Station *, StationCompare, std::allocator<Station *>>" has no member "Include" openttd D:\OpenTTD\OpenTTD GitHub\OpenTTD\src\station_cmd.cpp 3918
04:16:39 <Samu_> this was working yesterday
04:18:29 <peter1138> It's changed from a SmallVector to a std::set
04:18:54 <peter1138> You can replace .Include() with .insert()
04:19:21 <peter1138> m3henry is going to hate me :(
04:21:21 <peter1138> Begin -> begin, End -> end, Length -> size
04:22:33 <peter1138> StationList used_stations.
04:22:50 <peter1138> Not going to work as a StationList now. Hmm.
04:23:07 <peter1138> SmallVector<Station*, 4> used_stations; would work BUT
04:23:16 <peter1138> std::vector<Station *> used_stations would be better.
04:26:45 <Samu_> QSortT doesn't like some stuff
04:32:24 <Samu_> i'm lost, I have no idea what to do
04:35:06 *** Thedarkb1-T60 has joined #openttd
04:37:16 <Samu_> IndustryList also giving me trouble
04:38:01 <Samu_> binary '[': 'const IndustryList' does not define this operator or a conversion to a type acceptable to the predefined operator
04:38:21 <Samu_> Industry *ind = st->industries_near[RandomRange(st->industries_near.size())];
04:38:26 <Samu_> does not like the randomrange
04:39:45 <peter1138> It's not the RandomRange, it's the [ ]
04:40:21 <DorpsGek_II> [OpenTTD/OpenTTD] Berbe commented on pull request #7348: Fix: IniLoadFile::LoadFromDisk seems to expect filename, BaseMedia<Tbase_set>::AddFile provides fullpath https://git.io/fhhXd
04:41:15 <Samu_> SmallIndustryList still works
04:44:02 *** Beerbelott has left #openttd
04:48:07 *** Thedarkb1-T60 has joined #openttd
04:48:14 <Samu_> I cannot sort stations?
04:48:23 <Samu_> can't iterate backwards either?
04:48:44 <Samu_> it was good while it lasted
04:51:54 <DorpsGek_II> [OpenTTD/OpenTTD] SamuXarick commented on pull request #7184: Feature: Distribute cargo to multiple stations or industries https://git.io/fhh1f
04:52:37 *** tokai|noir has joined #openttd
04:52:37 *** ChanServ sets mode: +v tokai|noir
06:19:11 <Samu_> will post tomorrow, too late now
07:04:55 *** supermop_Home__ has quit IRC
07:37:20 *** Maarten has joined #openttd
07:48:31 *** sla_ro|master has joined #openttd
08:03:20 *** Laedek_ has joined #openttd
08:05:46 *** Gustavo6046 has joined #openttd
08:07:59 *** octernion has joined #openttd
08:17:18 *** Alberth has joined #openttd
08:17:18 *** ChanServ sets mode: +o Alberth
08:34:06 *** andythenorth has joined #openttd
08:41:12 <DorpsGek_II> [OpenTTD/OpenTTD] nielsmh dismissed a review for pull request #7352: Feature: Railtype flags to allow/disallow 90 degree curves. https://git.io/fhh6a
08:46:02 * andythenorth wonders where FIRS 'leftover cargo' originates
08:48:02 <andythenorth> <!--! Account for cargo 'wasted' in output calc (due to integer division discarding fractional values) - keep it for next production cycle -->
08:51:16 <andythenorth> seems it basically stores "waiting cargo mod 8"
08:51:22 <andythenorth> with some extra considerations
08:54:26 *** Maarten has joined #openttd
08:55:28 <andythenorth> let's do some maths
08:55:38 <andythenorth> deliver 12t of coal
08:55:50 <andythenorth> industry produces output at 2/8 of input
08:56:12 <andythenorth> why muck about with 'leftover'?
08:56:33 <andythenorth> is there a minimum distributed amount?
08:57:09 <andythenorth> I could go and see if the old nml code is any more clear on this
08:58:22 <Alberth> most likely, someone had the idea that you'd have to convert all input to output eventually
08:58:40 <Alberth> that ends in keeping the remaining last cargo naturally
08:59:34 <andythenorth> as long as you comment every byte, it's 100% readable :P
09:01:17 <Alberth> mostly the need to remember all the numbers, and tedious searching for typos in them, probably
09:02:23 <Alberth> there seems to be some middle ground here, one extreme is nfo, the other extreme is nml and beyond
09:02:58 <Alberth> m4nfo is more in the middle ground, some higher level concepts, but you still need to combine them yourself to make it work
09:03:23 <Alberth> ie one line in your nfo could be one statement, for example
09:03:45 <andythenorth> "//!! not really sure what is going on with A9, seems to duplicate AA - AC section of chain?"
09:03:51 <peter1138> I think andythenorth would find nml simpler if he was actually writing nml, not whatever the weird meta language on top.
09:04:18 <Alberth> nml scales badly to larger grfs is the problem perhaps
09:04:19 <andythenorth> I would find the overall project much harder, but you're correct
09:04:42 <andythenorth> it means (1) I don't know nml very well (2) I have complicated templates which are very hard to read
09:05:01 <andythenorth> also (3) I'm using python to template a language that is python-ish in places, but also not
09:05:08 <andythenorth> so it's brainfart a lot
09:05:51 <Alberth> may I suggest you try my py-xpd macro language, it's designed as a much simpler cpp pre-processor
09:06:25 <andythenorth> where's the repo? o_O
09:07:00 <andythenorth> also parts of FIRS repo from 10 years ago suggest that 'leftover cargo' is to prevent cargo being left in the stockpile
09:07:12 * andythenorth wonders how many units it''s worth saving though
09:07:38 <Alberth> also based on python instead of having to install the mingw-or-whatever toolchain on windows for cpp
09:08:02 <andythenorth> I don't miss those days
09:08:31 <andythenorth> how do macro languages do loops?
09:08:31 <Alberth> for C and c++ it works, because the macros are small if you're a sane programmer
09:09:18 <Alberth> mostly not, or by recursion
09:09:22 * andythenorth might be having a trip to src/industry_cmd.cpp next
09:09:32 <andythenorth> there must be a reason for pissing about with cargo amounts < 8
09:09:38 <andythenorth> we wouldn't have just invented it
09:10:19 <andythenorth> what's the smallest amount OpenTTD can move to a station?
09:10:28 <Alberth> default industries might just have been coded like that
09:11:06 <Alberth> I would hope it's 1 unit of cargo
09:11:13 <andythenorth> indspec->minimal_cargo
09:12:27 <DorpsGek_II> [OpenTTD/OpenTTD] PeterN approved pull request #7352: Feature: Railtype flags to allow/disallow 90 degree curves. https://git.io/fhhyI
09:12:49 <DorpsGek_II> [OpenTTD/OpenTTD] PeterN merged pull request #7352: Feature: Railtype flags to allow/disallow 90 degree curves. https://git.io/fhhrp
09:13:03 <Alberth> isn't that the minimum to avoid closure?
09:14:09 <andythenorth> self.min_cargo_distr = '5' # just use the most common value from default OTTD industries, this property needs set but has little use
09:14:31 <peter1138> LordAro, I can technically as andythenorth opened the PR, but all the commits are by me now.
09:14:50 <andythenorth> the production code makes no reference to min_cargo_distr, it does something different
09:15:55 <andythenorth> afaict, FIRS tries to minimally produce 8 units, and save any cargo that would result in < 8 for next production run
09:16:02 <andythenorth> very diligent, but really?
09:17:11 <andythenorth> I might sack all this crap in favour of a simple loop
09:17:15 <andythenorth> then await bug reports
09:18:02 <LordAro> peter1138: guess someone else should actually look over it :p
09:18:11 <peter1138> Yeah, I'll merge if someone approves
09:18:34 <andythenorth> is it breakfast time?
09:19:45 *** gelignite has joined #openttd
09:21:21 <peter1138> It was, I ate mine.
09:21:48 <peter1138> Two turkey 'rashers' and an egg on a potato farl. Very protein.
09:22:39 <andythenorth> currently the biggest problem with FIRS is WoT Blitz
09:23:21 <peter1138> Hmm, couldn've done it as a half-English, damn. Added beans, sosigs, mushrooms and onion. No black pudding or hash browns though.
09:23:47 <peter1138> So I ought to go cycling today, but it's very windy.
09:24:22 <peter1138> Yeah, wind 25 gusting to 46.
09:26:26 <peter1138> ^ needs anything more for those two flags?
09:27:19 <peter1138> ^ needs fixing for 1.10 :/
09:29:05 <peter1138> Bah, wiki password not working.
09:30:29 <andythenorth> turn it off and on again
09:39:11 <peter1138> So when does github gain PR dependencies?
09:39:23 <peter1138> I have one that depends on #7357.
09:40:56 <peter1138> Originally a patch I wrote for r18931.
09:51:42 <DorpsGek_II> [OpenTTD/CompileFarm] TrueBrain approved pull request #30: Fix #29: don't assume master as target branch https://git.io/fhhyK
09:51:50 <DorpsGek_II> [OpenTTD/CompileFarm] TrueBrain merged pull request #30: Fix #29: don't assume master as target branch https://git.io/fhhiQ
09:51:51 <DorpsGek_II> [OpenTTD/CompileFarm] TrueBrain closed issue #29: Commit checker always expect origin/master, even for non master PRs https://git.io/fhhn4
09:52:13 <LordAro> peter1138: not going cycling today, just not feeling it :(
09:52:24 <peter1138> Same. Too windy & gusty.
09:52:42 <peter1138> I couldn't open the backdoor just now o_O
09:54:12 <LordAro> heh, nice. i don't have that excuse (yet) though...
09:57:28 <nielsm> merge ALL the patches YOLO!
09:58:08 <nielsm> well, only if you assume someone is going to try a GS written for 1.9.0 final on 1.9.0-rc1
09:58:43 <TrueBrain> I guess. In my mind, RC means feature freeze
09:58:52 <TrueBrain> so adding things becomes a bit sketchy
09:59:03 <TrueBrain> but more to the point in this case, is that it requires a change both in master and the release branch
09:59:10 <TrueBrain> (comments for example need fixing)
09:59:18 <TrueBrain> it becomes a bit dodgy
10:00:22 <DorpsGek_II> [OpenTTD/OpenTTD] TrueBrain commented on pull request #7336: Add: AI API for vehicle group colours https://git.io/fhhyD
10:01:03 <peter1138> If it wasn't for the documentation, yeah, it's a quick thing.
10:01:11 *** Progman has joined #openttd
10:01:51 <peter1138> Anyway, I think it was flagged just to discuss it, not actually do it.
10:02:42 <TrueBrain> hence my question: should we? :D
10:02:47 <TrueBrain> as I was wondering the pros and cons :)
10:03:12 <peter1138> It's also a very minor feature addition that most AI authors will never use.
10:03:24 <TrueBrain> guess we have to balance it per PR, honestly
10:03:38 <peter1138> I wouldn't bother backporting that one, personally.
10:03:39 <TrueBrain> the amount of work to 'correct' history vs the added value :D
10:04:10 <TrueBrain> well, your call; you are the author of the PR here :)
10:04:21 <peter1138> I am, but I didn't flag it as backport.
10:04:36 <LordAro> given it's "fixing" an oversight in the original PR, i don't mind too much
10:04:44 <LordAro> but i wouldn't want anything more than that, for sure
10:04:53 <TrueBrain> meh, glx's change breaks .. bah
10:04:58 <TrueBrain> I was sure it was going to work
10:05:50 <TrueBrain> LordAro: I think the question was not as much if we mind, more the amount of work required to make it correct vs the benefit :)
10:06:08 <TrueBrain> I guess another way of putting it: is anyone going to do the legwork for it, and do we consider that time well spend :)
10:07:48 <TrueBrain> "error: malformed object name origin/$(System.PullRequest.TargetBranch)"
10:08:44 <TrueBrain> sometimes it doesn't resolve variables .. sometimes it does
10:10:30 <peter1138> Hmm, let's try this SDL 2 again.
10:12:59 <peter1138> Hmm 8bpp mode is *slow*
10:13:48 <peter1138> Must've been what was on screen
10:13:50 <DorpsGek_II> [OpenTTD/OpenTTD] TrueBrain commented on pull request #7336: Add: AI API for vehicle group colours https://git.io/fhhyb
10:14:50 <peter1138> I think it's a slippery slope. As you say, feature freeze.
10:15:05 <nielsm> why even bother with 1.9?
10:15:10 <TrueBrain> all documentation suggests the YAML should be fine; but why is the variable not resolved :(
10:15:43 <TrueBrain> nielsm: because otherwise you never release anything :D
10:16:03 <andythenorth> 1.9 is already old news
10:16:20 <peter1138> Release early, release often.
10:16:21 <TrueBrain> and given the current long cycles OpenTTD uses, it always has been that after a release is branched, tons of new shit hit the 'trunk' :) Guess that is fact of life :P
10:16:30 <andythenorth> that's how it works
10:16:41 <peter1138> For so many years development had been stagnant.
10:16:45 <andythenorth> and 'stable' will alway contain bugs that are fixed in trunk
10:16:50 <peter1138> It's just picked up a bit in the last year.
10:16:51 <andythenorth> and there is always a temptation to backport
10:17:03 <andythenorth> release 3 times a year
10:17:10 <peter1138> It's now at the point where a 3 or 4 month release is feasible.
10:17:15 <peter1138> Assuming it continues.
10:17:24 <TrueBrain> we just need to automate the process a bit more, but yeah
10:17:31 <andythenorth> well, it will slow down while we rewrite all the content APIs :P
10:17:32 <peter1138> We've had releases where the only savegame bump was for the new version.
10:17:38 <andythenorth> and the content authoring tools
10:17:52 <andythenorth> and we need a new website
10:18:02 <peter1138> April 2020 for 1.10 would be a mistake, certainly :)
10:18:22 <andythenorth> school holidays start
10:18:44 <TrueBrain> you want enough time to collect feedback on the biggest changes, even if only by a small portion of the population
10:19:06 <TrueBrain> or you want to switch to a CI/CD delivery, as in: feature hits 'stable' tomorrow :P
10:19:14 <TrueBrain> but that requires auto-updating :P
10:20:13 <andythenorth> also, CI/CD makes it very hard to ever remove/break anything
10:20:27 <andythenorth> major versions are a chance to kill old stuff
10:20:47 <peter1138> I think that's a bit extreme :-)
10:21:24 <TrueBrain> why is Azure not resolving this variable :(
10:28:18 <peter1138> Ah, loads of them are closed, phew.
10:29:30 <DorpsGek_II> [OpenTTD/OpenTTD] PeterN opened pull request #7358: Add: Construction type icons to rail and road construction drop down lists. https://git.io/fhhSU
10:30:08 <peter1138> Ok, I've "just" realised why our vertical centering based on FONT_HEIGHT_NORMAL looks a bit wrong sometimes...
10:33:29 <DorpsGek_II> [OpenTTD/OpenTTD] TrueBrain dismissed a review for pull request #7356: Fix: [AzurePipelines] run commit checker only for PRs and pass it the… https://git.io/fhhXG
10:33:30 <DorpsGek_II> [OpenTTD/OpenTTD] TrueBrain updated pull request #7356: Fix: [AzurePipelines] run commit checker only for PRs and pass it the… https://git.io/fhhi7
10:34:37 <peter1138> nielsm, probably ought to wait til we're at least close to doing a 1.10-beta.
10:35:52 <LordAro> i've never been a fan of projects that update the changelog for every commit
10:36:03 <TrueBrain> "##[error]error: malformed object name origin/${SYSTEM_PULLREQUEST_TARGETBRANCH}" <- PFFFTTT, so what is the right way of doing this .. :(
10:36:25 <LordAro> TrueBrain: is it $SYSTEM_PULLREQUEST_TARGETBRANCH ? :p
10:36:35 <TrueBrain> pretty sure that is not it :)
10:36:47 <peter1138> LordAro, I used to do that back in the day. Monodevelop would automatically update the changelog with commit message.
10:37:11 <peter1138> LordAro, it was a fucking horrible pain in the arse to merge anything, as it ALWAYS conflicted on the stupid stupid changelog file.
10:37:19 <peter1138> And it only ever said the same as the commit message anyway.
10:37:55 <TrueBrain> and autogenerate changelogs from there
10:38:27 <TrueBrain> would be terrible for OpenTTD itself btw
10:38:32 <TrueBrain> we suck at commit messages :D
10:38:39 <peter1138> We kinda do that, but...
10:39:01 <TrueBrain> well, such autogeneration might fix us sucking :D
10:40:02 <TrueBrain> "/usr/bin/docker run -e TARGET_BRANCH=${SYSTEM_PULLREQUEST_TARGETBRANCH} .."
10:40:03 <peter1138> It does look a bit weird.
10:40:06 <TrueBrain> that should work, not?
10:40:28 <TrueBrain> it is very computer-ish talk :)
10:40:34 <LordAro> TrueBrain: it'll get expanded before docker sees it, if that's what you want
10:40:53 <TrueBrain> LordAro: well .. it doesn't .. which is what I find odd
10:40:54 <peter1138> What will be expanding it?
10:41:00 <TrueBrain> but I would expect it should
10:44:00 <DorpsGek_II> [OpenTTD/OpenTTD] TrueBrain updated pull request #7356: Fix: [AzurePipelines] run commit checker only for PRs and pass it the… https://git.io/fhhi7
10:44:27 <peter1138> You're using $( ) elsewhere, not ${ }
10:44:41 <TrueBrain> ${} for bash env resolving
10:44:47 <TrueBrain> $() for Azure Pipeline resolving
10:45:15 <TrueBrain> I am now just blindly guessing solutions :D
10:45:29 <peter1138> Hmm, right, so you'd expect bash to be resolving it to "" if it was blank, rather than leaving it as is.
10:45:50 <TrueBrain> AP can be a bit .. funky
10:46:07 <TrueBrain> "/usr/bin/docker run -e 'TARGET_BRANCH=master'"
10:46:45 <LordAro> mm, probably being expanded too early in the ...pipeline
10:47:04 <TrueBrain> now I hope Docker understands '' :P
10:47:46 <DorpsGek_II> [OpenTTD/OpenTTD] TrueBrain updated pull request #7346: Fix: rebase to 1.9 branch for backport PRs https://git.io/fhhnO
10:48:06 <TrueBrain> lets check if that fixes 1.9 ..
10:48:30 <andythenorth> LordAro: by 'very hard' I mean giving player the choice to stay on old major version, to keep old behaviour
10:48:36 <andythenorth> if they're really attached to it
10:48:42 <andythenorth> auto-updater breaks that
10:49:27 <TrueBrain> hmm .. reminds me I still havent got a reply back from them
10:50:24 <TrueBrain> nope, Docker doesn't like the '
10:50:34 <peter1138> Is it possible to use git clone --depth to prevent it having to clone 120MB of repo every time?
10:51:11 <DorpsGek_II> [OpenTTD/OpenTTD] TrueBrain updated pull request #7356: Fix: [AzurePipelines] run commit checker only for PRs and pass it the… https://git.io/fhhi7
10:51:20 <LordAro> or maybe \${foo} or something
10:51:20 <peter1138> why would it not like that? o_O
10:51:29 <TrueBrain> LordAro: no, Docker is not even seeing the env variable
10:51:41 <TrueBrain> well, I think it made the whole thing a single env variable tbh :D
10:52:14 <peter1138> /usr/bin/docker run -e 'TARGET_BRANCH=release/1.9' < that doesn't look wrong to me. Hmm.
10:52:21 <TrueBrain> peter1138: yeah .. but honestly, they should just allow to have those shadow repositories .. what is it called ..
10:52:37 <TrueBrain> you can have a local clone
10:52:41 <TrueBrain> so it only checks out what is new
10:52:47 <TrueBrain> we used that on Jenkins etc
10:52:51 <TrueBrain> but .. AP doesn't offer that YET
10:53:14 <TrueBrain> "/usr/bin/docker run -e TARGET_BRANCH='master'"
10:53:17 <TrueBrain> okay, that is looking better
10:53:36 <TrueBrain> "##[error]error: malformed object name origin/'master'"
10:53:51 <TrueBrain> @kick TrueBrain spam
10:53:51 *** TrueBrain was kicked by DorpsGek (spam)
10:54:04 *** TrueBrain has joined #openttd
10:54:12 <LordAro> i'm glad i wasn't the only one thinking it
10:54:13 <TrueBrain> I deserved that, sorry TrueBrain
10:54:59 <TrueBrain> ah, it doesn't use a shell
10:55:04 <TrueBrain> so the parameters are given as-is
10:55:19 <TrueBrain> so to resolve the variable .. I need to use quotes ... which Docker doesn't udnerstand :D Lovely!
10:55:36 <TrueBrain> so in reality it was doing docker run -e \'BLA=bla\'
10:55:41 <TrueBrain> and is now doing docker run -e BLA=\'bla\'
10:55:46 <TrueBrain> (if executed from shell)
10:56:30 <TrueBrain> to quote or not to quote, that is the question :D
10:57:42 <TrueBrain> and I kinda don't want to solve this in the Docker itself, as that feels really silly
10:59:23 <DorpsGek_II> [OpenTTD/OpenTTD] TrueBrain updated pull request #7356: Fix: [AzurePipelines] run commit checker only for PRs and pass it the… https://git.io/fhhi7
11:01:15 <peter1138> Hmm, confused by settings.
11:02:31 <Eddi|zuHause> <andythenorth> why muck about with 'leftover'? <-- because whole countries were thrown into economic crisis when they didn't account for rounding errors
11:02:40 <DorpsGek_II> [OpenTTD/OpenTTD] TrueBrain updated pull request #7356: Fix: [AzurePipelines] run commit checker only for PRs and pass it the… https://git.io/fhhi7
11:03:20 <andythenorth> Eddi|zuHause: ok, I'll write code that wastes the leftover
11:03:37 <andythenorth> and then you can send me a PR to store the remainder, using mod 8 or something
11:03:48 <peter1138> (const void*)(size_t)(def)
11:03:58 <peter1138> That is... what? o_O
11:05:05 <DorpsGek_II> [OpenTTD/OpenTTD] TrueBrain updated pull request #7346: Fix: rebase to 1.9 branch for backport PRs https://git.io/fhhnO
11:05:07 <andythenorth> hmm, FIRS PRs o_O
11:05:14 <andythenorth> maybe I can just be the project manager?
11:05:31 <TrueBrain> lol; we won't hear the end of it if you are only the pm :P
11:05:41 <andythenorth> we don't have enough project management
11:05:45 <andythenorth> that's why nothing ever gets done
11:05:57 <TrueBrain> "self organizing groups"
11:06:22 <andythenorth> it's all lolz, all of it
11:06:23 <Eddi|zuHause> andythenorth: that's because the so-called "project manager" obsesses about a strange line with mod 8 that he doesn't understand
11:06:47 <Eddi|zuHause> instead of "someone probably thought a lot about this, just keep it around and stop worrying"
11:06:50 <andythenorth> Eddi|zuHause: who is the project manager right now?
11:07:08 <TrueBrain> okay .. this code works
11:07:14 <TrueBrain> not happy with how it looks, but it does work
11:07:21 <Eddi|zuHause> andythenorth: rule of thumb: if you have to ask that question, it's probably yourself :p
11:07:22 <andythenorth> I'm just going to delete the modulus, I suspect it doesn't work anyway
11:07:34 <andythenorth> and I'm not scaling 'it doesn't work' to 8 cargos
11:07:54 <Eddi|zuHause> what makes you think it doesn't work?
11:08:21 <andythenorth> so it's not clear what 'work' would mean
11:08:24 <Eddi|zuHause> how are those things related?
11:08:37 <andythenorth> if we don't know what 'correct' is, how can we know if it works?
11:08:44 <andythenorth> therefore -> doesn't work
11:08:51 <andythenorth> you may pick holes in that logic
11:08:54 <Eddi|zuHause> that's just because you don't know what mod does
11:09:25 <andythenorth> I know what mod does
11:09:32 <andythenorth> I don't know what the FIRS code is doing
11:09:35 <peter1138> Hmm, value clamping for uint32s is wrong as well.
11:09:42 <andythenorth> this is all a bit Popper / Berlin school
11:09:46 <Eddi|zuHause> are you sure? i'm fairly convinced i had to explain it to you multiple times in the past :p
11:10:41 <andythenorth> ok we'll go with your argument then
11:11:46 <Eddi|zuHause> that looks like a perfectly fine formula to me
11:12:34 <andythenorth> yes but is it correct? o_O
11:12:46 <DorpsGek_II> [OpenTTD/OpenTTD] TrueBrain updated pull request #7356: Fix: [AzurePipelines] run commit checker only for PRs and pass it the… https://git.io/fhhi7
11:13:12 <andythenorth> it seems to just be loading leftover cargo from storage, then storing it back
11:13:23 <Eddi|zuHause> difficult to say with your huge variable names
11:13:54 <andythenorth> I'll use 'a' and 'b' next time :P
11:14:26 <andythenorth> L33 loads leftover_cargo_1 from perm storage, does mod on it, then stores the result to leftover_cargo_1
11:14:44 <Eddi|zuHause> let's start at what l24 does
11:15:02 <andythenorth> 78 would be better
11:15:13 <andythenorth> why is waiting cargo being stored to leftover_cargo_1?
11:15:22 <andythenorth> these are stupid variable names
11:16:09 <DorpsGek_II> [OpenTTD/OpenTTD] TrueBrain updated pull request #7356: Fix: [AzurePipelines] run commit checker only for PRs and pass it the… https://git.io/fhhi7
11:16:14 <TrueBrain> sorry for all the spam .... imagine glx's mailbox
11:17:09 <Eddi|zuHause> out of 100 emails in the past 2 months, 95 are openttd github
11:17:29 <andythenorth> oof GTG, kids football
11:17:38 <andythenorth> anyway I accept Eddi|zuHause is right
11:17:48 <andythenorth> but also I stand by my point, this code is unreadable ;P
11:17:52 <andythenorth> and needs deleted
11:18:00 <LordAro> Eddi|zuHause: 95 emails is a tuesday for me, currently
11:18:12 <LordAro> should probably unwatch the repo or something :p
11:18:23 <DorpsGek_II> [OpenTTD/OpenTTD] TrueBrain updated pull request #7346: Fix: rebase to 1.9 branch for backport PRs https://git.io/fhhnO
11:18:33 <Eddi|zuHause> i should move them to a subfolder
11:18:36 <TrueBrain> I unwatched it a while ago :P
11:18:44 <Eddi|zuHause> and maybe mark them as auto-read
11:18:45 <TrueBrain> I am with frosch, I want a filter on certain labels :P
11:19:01 <TrueBrain> okay ... this seems to work ..
11:20:02 <Eddi|zuHause> i mostly react on the channel notifications, so the email notification is just noise coming in 5 minutes late
11:20:16 <Eddi|zuHause> but i don't watch the channel all the time, and in those cases the email is more useful
11:20:56 <TrueBrain> I like that DorpsGek_II is giving me a feed of everything it said .. so I can look back in PR notifications there :P
11:21:34 <Eddi|zuHause> i don't have access to that :p
11:21:39 <TrueBrain> okay, come one, work .. work ... please work ........
11:21:45 <TrueBrain> doesn't #openttd.notice also show this? I think it does
11:21:48 <TrueBrain> it should, at least
11:22:11 <Eddi|zuHause> it probably would, but i have no real use for that...
11:23:28 <LordAro> TrueBrain: will do, nearly at the bottom of NRT
11:24:57 <DorpsGek_II> [OpenTTD/OpenTTD] michicc approved pull request #7358: Add: Construction type icons to rail and road construction drop down lists. https://git.io/fhh9Y
11:26:03 <DorpsGek_II> [OpenTTD/OpenTTD] TrueBrain updated pull request #7356: Fix: [AzurePipelines] run commit checker only for PRs and pass it the… https://git.io/fhhi7
11:26:18 <TrueBrain> almost forgot to document why this solution is in place ...
11:26:26 <TrueBrain> more lines of comments now than the real change :D
11:26:46 <LordAro> those are the best changes
11:27:14 <LordAro> bonus points if it's a rant about a 3rd party system or colleague
11:27:54 <DorpsGek_II> [OpenTTD/OpenTTD] TrueBrain commented on pull request #7356: Fix: [AzurePipelines] run commit checker only for PRs and pass it the… https://git.io/fhh9l
11:28:07 <TrueBrain> rants go in commit messages
11:28:11 <TrueBrain> comments should be factial
11:29:02 <TrueBrain> We once removed a comment that said something in the lines of: # Because of our idiot colleague we have this; not because it is correct, but because he is a moron that doesn't want to listen
11:29:09 <TrueBrain> that was not really ... helping anyone to have that around :P
11:29:21 <TrueBrain> especially as he was called out by name in the same comment :D
11:29:43 <LordAro> oh, of course, that's a "what" comment, not a "why" comment :p
11:29:54 <TrueBrain> it is also a why, in this case :D
11:30:24 <LordAro> if it explains why they're an idiot, i'd look more favourably on it :p
11:30:48 <TrueBrain> because he is a moron, duh :)
11:30:58 <LordAro> in the context of the code :p
11:31:00 *** olivier has joined #openttd
11:31:38 <TrueBrain> do we keep the label "backport" if it is backported, or do we add another label to indicate it is, or do we remove it?
11:31:40 <DorpsGek_II> [OpenTTD/OpenTTD] PeterN merged pull request #7358: Add: Construction type icons to rail and road construction drop down lists. https://git.io/fhhSU
11:31:58 <peter1138> TrueBrain, if it's done, remove it, I think.
11:32:00 <LordAro> TrueBrain: probably should be "to backport", and removed when it is
11:32:23 <TrueBrain> I can understand if people want to know that it is backproted
11:32:31 <peter1138> I suppose it is easy enough to filter on "backport" and "is open"
11:32:45 <peter1138> So could just leave it indeed.
11:32:47 <TrueBrain> but that is the issue .. backports are not open
11:33:00 <peter1138> Right but it's still a backport.
11:33:07 <LordAro> backported commit should reference the PR, right?
11:33:19 <LordAro> so you'll see it in the issue
11:33:21 <TrueBrain> yeah, but you want to quickly see what we still need to backport
11:33:26 <TrueBrain> not click them ALL to see that :)
11:33:28 <peter1138> Ok, so then remove it.
11:33:52 <TrueBrain> and I can udnerstand people dont want to go through everyPR to see if we forgot to backport one
11:33:56 <TrueBrain> so keeping it can be useful :D
11:34:03 <TrueBrain> (hence my question :P)
11:34:13 <TrueBrain> "to backport" and "backported" labels?
11:36:40 <TrueBrain> lets try that for now, and see what it brings us .. removing stuff is always easier :)
11:36:57 <peter1138> I will need to update it I guess :)
11:38:24 <TrueBrain> with these PRs, I will miss the days of SVN .. NoAI was 40+ commits .. that was such a lovely MERGE moment :D (as it showed 40+ commit lines on IRC). Now it will be just a single entry ...
11:39:24 <LordAro> clearly you should make DorpsGek_II watch for individual commits to master :p
11:39:28 <Eddi|zuHause> maybe instead of "X merged pull request" you should list the commits added to master? :p
11:39:33 <TrueBrain> LordAro: people voted against that :(
11:39:34 <LordAro> we miss on translator updates because of that as well
11:39:53 <TrueBrain> hmm . .that is indeed true
11:40:50 <TrueBrain> and now I have a reminder
11:41:00 <DorpsGek_II> [OpenTTD/OpenTTD] LordAro commented on pull request #7356: Fix: [AzurePipelines] run commit checker only for PRs and pass it the… https://git.io/fhh95
11:41:37 <DorpsGek_II> [OpenTTD/OpenTTD] TrueBrain commented on pull request #7356: Fix: [AzurePipelines] run commit checker only for PRs and pass it the… https://git.io/fhh9d
11:42:25 <DorpsGek_II> [OpenTTD/OpenTTD] LordAro approved pull request #7356: Fix: [AzurePipelines] run commit checker only for PRs and pass it the… https://git.io/fhh9F
11:42:56 <DorpsGek_II> [OpenTTD/OpenTTD] LordAro merged pull request #7356: Fix: [AzurePipelines] run commit checker only for PRs and pass it the… https://git.io/fhhi7
11:43:19 <LordAro> TrueBrain: you get no credit :p
11:43:28 <TrueBrain> yeah, because you merged :(
11:45:45 <peter1138> LordAro, i'll have to see what I can do about splitting.
11:46:03 <LordAro> yeah, i can't imagine it'll be all that easy
11:46:03 <peter1138> It was done as a big lump because the original was full of fixes and merges.
11:46:26 <TrueBrain> this is my suggestion for backports ^^
11:47:18 <DorpsGek_II> [OpenTTD/OpenTTD] TrueBrain commented on pull request #7346: Fix: rebase to 1.9 branch for backport PRs https://git.io/fhh9x
11:47:19 <DorpsGek_II> [OpenTTD/OpenTTD] TrueBrain closed pull request #7346: Fix: rebase to 1.9 branch for backport PRs https://git.io/fhhnO
11:48:23 <TrueBrain> smart, the closes; I wanted to do that manually, but this is easier :P
11:49:40 <DorpsGek_II> [OpenTTD/OpenTTD] LordAro dismissed a review for pull request #6926: Change: Allow dock to be constructed in more locations https://git.io/fhuHI
11:49:41 <TrueBrain> wish you could control labels like that :D
11:49:51 <LordAro> that would be very nice :)
11:51:10 <TrueBrain> there are btw bots that do backporting for you, once in a while, if there are no conflicts
11:51:18 <TrueBrain> but .. one step at the time :D
11:55:01 <TrueBrain> yippie, all green :D It works! \o/
11:55:25 <TrueBrain> so do we want a PR per backport, or these bulk versions?
11:55:49 *** andythenorth_ has joined #openttd
11:56:38 <nielsm> I suppose bulk PRs are fine at least for low-risk things
11:57:08 <TrueBrain> the no-conflict cherry-picks
11:58:38 <peter1138> ^ I notice that repo doesn't require approval.
11:58:51 <TrueBrain> I mentioned that a few times already yes
11:58:55 <TrueBrain> seems nobody cares enough to fix it :)
11:59:04 <peter1138> I don't have rights to fix it :p
11:59:33 <peter1138> (I'm not asking for rights)
11:59:57 <TrueBrain> people creating these repos should also take care of these administrative things, in my opinion
12:00:08 <TrueBrain> as others cannot smell if they wanted to set it up like this or not
12:00:17 <TrueBrain> but last time I asked, I got some contradicting answers :D
12:01:04 <DorpsGek_II> [OpenTTD/OpenTTD] LordAro commented on pull request #7086: Change #6173: Update SDL driver to use SDL 2.0 https://git.io/fhhHU
12:01:11 <andythenorth_> just kick the repo out of the org?
12:01:28 <andythenorth_> if it doesn’t conform to standards?
12:01:34 <TrueBrain> we have standards?!
12:01:56 <LordAro> /kick TrueBrain standards enforcement
12:02:05 <peter1138> andythenorth_, wtf?
12:02:44 <TrueBrain> peter1138: I guess NML is also missing some form of CI :)
12:03:05 <TrueBrain> so yeah .. that needs a bit more attention :)
12:03:19 <LordAro> i think pm wanted to hook it up to ottdc jenkins
12:03:33 <andythenorth_> frosch or pm already did it
12:03:41 <TrueBrain> it is not reporting back
12:04:02 <TrueBrain> (case and point, the last PR that just came by :D)
12:04:14 <TrueBrain> but okay, I am sure they are on it :)
12:04:20 <andythenorth_> can’t be fucked to search coop on my 4” phone
12:04:51 <TrueBrain> last we talked, I believe we agreed that they would ask for help if needed, etc :) So I am sure it is in good hands, just takes time :)
12:05:24 <TrueBrain> I just hope someone is also taking care of OpenGFX etc :)
12:05:36 <andythenorth_> edit content in game
12:05:40 <TrueBrain> owh, they are stalled on import errors :(
12:05:52 <peter1138> TrueBrain, yup, needs the hg repo to be "fixed"
12:06:10 <TrueBrain> all imports I managed so far, failed via GitHub
12:06:14 <TrueBrain> I all did them manually in the end
12:06:36 <andythenorth_> 2 of mine worked, rest did not
12:07:13 <andythenorth_> also what can we delete? :p
12:07:26 * andythenorth_ has itchy fingers for a bonfire
12:08:09 <TrueBrain> andythenorth_: STEP AWAY FROM THE KEYBOARD
12:08:18 <andythenorth_> it’s piece of glass
12:08:44 <peter1138> Deleting stuff you are bored with is not useful.
12:08:55 <peter1138> You are not going to bugger off to simuscape or something :p
12:09:10 <andythenorth_> delete simuscape!
12:09:58 <peter1138> TrueBrain, if 7302 made it to 1.9, yes.
12:10:02 <andythenorth_> what I really like is the stalebot
12:10:35 <peter1138> Yes it saves you from having to make a decision.
12:10:54 <peter1138> And it means people don't blame you for closing their bug.
12:11:16 <TrueBrain> yup; blaming machines always does wonders :)
12:11:34 <andythenorth_> hmm I have 20 pairs of the same type of nike trainers, in different colours. delete some of those?
12:11:59 <andythenorth_> I deleted lots of old/dead plants in my garden 2 weeks ago
12:12:04 <TrueBrain> okay, I like this .. easy to spot what needs consideration of backporting
12:13:01 <andythenorth_> hmm so NRT is shipped?
12:13:08 <andythenorth_> I should make a grf
12:13:09 <peter1138> No, I'm working on it.
12:13:22 <peter1138> Review popped up some changes.
12:13:39 <andythenorth_> did I open a PR for nml?
12:13:40 <peter1138> Including the suggestion to split it. Splorfl.
12:13:53 <peter1138> I think 16-in-16-out is a PR?
12:13:55 <andythenorth_> sporfl is a good word
12:14:22 <andythenorth_> need to do an nml nrt pr
12:14:41 <andythenorth_> my branch is a disaster of merges probly
12:17:01 <DorpsGek_II> [OpenTTD/OpenTTD] PeterN commented on pull request #7349: Fix: Show industry name in Land Area Information window for oil-rig type stations instead of just 'Oil Rig' https://git.io/fhhHs
12:17:12 <andythenorth_> based on an old import I did of nml
12:18:17 <andythenorth_> so is HEQS going into Road Hog or not?
12:18:19 <TrueBrain> peter1138: did not know, removed the label immediately :P
12:22:03 <andythenorth_> hmm not bulldozers though eh
12:25:12 *** remmalj[m] has joined #openttd
12:45:03 <peter1138> I was going to check the specs on that comment ^
12:45:10 <peter1138> But, uh, there are no official specs yet.
12:46:08 <nielsm> I wonder if the newgrf specs (at least what ottd understands) shouldn't be part of documentation inside the repository
12:46:14 <nielsm> instead of on an external wiki
12:47:30 <michi_cc> Back then ttdpatch had some life signs, but I guess that reason is no more.
12:48:51 <nielsm> good, that misfeature is closed now
12:49:33 <nielsm> (it was never a bug that track in desert/snow did not have fences)
12:50:20 <nielsm> (otoh, maybe fences should not be _removed_ if the ground changes below the track, due to changing snow line, or water appearing nearby)
12:50:58 <TrueBrain> and tomorrow the issue related will be marked as stale ;)
12:52:15 *** HerzogDeXtEr has joined #openttd
12:54:27 <Eddi|zuHause> nielsm: but what if the openttd specs and the "official" (neutral) specs diverge?
12:55:17 <nielsm> the specs in ottd repos would be the official description of what ottd supports
12:56:07 <Eddi|zuHause> there was a discussion recently about whether the grf specs should include things that are only supported in patch packs (but are stable enough)
12:56:17 *** lapav[m] has joined #openttd
12:56:54 <Eddi|zuHause> nielsm: there are a bunch of things in the specs that openttd doesn't support
12:57:14 <Eddi|zuHause> nielsm: "only document what's implemented" is maybe not the best idea
12:57:47 <Eddi|zuHause> the specs are more than that.
12:57:57 <nielsm> "reserved, not supported by ottd, may cause your data to fail loading"
13:01:57 <peter1138> Yeah, the specs were of course designed by ttdpatch and we just implemented them.
13:02:04 <planetmaker> fences in snow or desert a mis-feature? Hm
13:02:32 <peter1138> Problem with documentation in the repo is... what format? And what about images? Maintain history?
13:02:44 <peter1138> It's already a pain in the bum keeping landscape*html up to date.
13:03:30 <planetmaker> re (newgrf) docs: the current tt-wiki is quite a good place - especially as it documents more than OpenTTD alone
13:03:42 <planetmaker> and it is maintained by more people than those who know git-foo
13:04:07 <peter1138> 11:48 < nielsm> good, that misfeature is closed now
13:04:09 <planetmaker> re-creating the level of detail it currently offers inside an OpenTTD repo would be a hell of a work
13:04:15 <peter1138> I also disagree that it's a misfeature.
13:04:27 <peter1138> I don't know about the specific implementation though.
13:04:33 <planetmaker> that looked messy
13:05:01 <peter1138> I would say, yes, don't move the docs.
13:05:05 <nielsm> desert and snow were never supposed to have fences
13:06:09 <peter1138> I don't follow that argument.
13:06:18 <peter1138> Features shouldn't be added because they weren't there originally?
13:07:20 <peter1138> I would say if it was to be added it would be newgrf-provided only :p
13:07:54 <nielsm> I'd be fine with it as a newgrf thing
13:08:10 <peter1138> I'd hope the code would be much smaller in that case :p
13:08:20 *** andythenorth has joined #openttd
13:08:51 <peter1138> Ok, default setting does not work.
13:09:09 <peter1138> It made the title save load as temperate.
13:09:32 <peter1138> I guess there's a bug there :D
13:13:31 *** Thedarkb-T60 has joined #openttd
13:18:29 <peter1138> Setting vehicle.max_trains (0 < 6400 < 5000) -> new 500
13:18:37 <peter1138> Old code would've clamped that to 5000.
13:18:46 <peter1138> New code sets it to the default 500.
13:21:22 <peter1138> I just remembered, the framerate regression made it to 1.9 :(
13:21:48 <LordAro> framerate regression?
13:21:49 <peter1138> The one where lots of vehicles causes the performanceaccumulator to use up a good chunk of CPU itself
13:22:40 <peter1138> Could be. Has been reported to cause slowdowns on systems where accumulator is not slow.
13:23:00 <peter1138> I'm not sure why it would be slow or not slow on some systems.
13:23:27 <peter1138> 'Problem' is it changes the order of vehicle processing.
13:23:37 <peter1138> Dunno if that's actually an issue.
13:32:09 <peter1138> Interesting settings get loaded just by clicking on the name in the load game list.
13:34:53 <andythenorth> can we store a table of industry closures?
13:34:58 <andythenorth> newgrf accessible?
13:35:10 <peter1138> Oh. My newgame settings got changed. This is suboptimal :/
13:35:29 <peter1138> andythenorth, sounds like a gamescript thing ;)
13:36:03 <Alberth> it would be if game scripts could actually control opening and closing of industries, imho
13:36:42 <andythenorth> the standard answer is "newgrf can't have a global view, use GS"
13:36:48 <andythenorth> and when anyone asks "how?"
13:36:59 <andythenorth> the standard answer is "GS can't know anything about newgrf industry, nor control it"
13:36:59 <peter1138> I was, of course, being facetious.
13:37:25 <andythenorth> it came up because I've disabled FIRS closure handling temporarily to get 16-cargos working
13:37:34 <andythenorth> and can I be arsed to restore it later? :P
13:37:43 <peter1138> I'm not sure what such a system would look like.
13:37:49 <peter1138> (table of industry closures)
13:37:55 <andythenorth> table of industries closes, with type and date
13:38:11 <peter1138> Yeah but how would you look at that from newgrf?
13:38:22 <andythenorth> *and* it tracks industries marked for closure so far this month
13:38:30 <andythenorth> you look at it from monthly and random cb
13:38:33 <andythenorth> I'll find the numbers
13:38:54 <peter1138> You can't easily do loops can you?
13:39:39 <andythenorth> just give it a var to query the table, with some useful bitmasked info
13:39:50 <andythenorth> maybe pass an industry ID
13:40:08 <peter1138> Urgh, regression testing.
13:40:28 <andythenorth> returns last date of closure for that ID
13:40:37 <andythenorth> maybe a stack so you can walk down the closures, picking off 'next'
13:40:55 <andythenorth> might still be crap, dunno
13:41:02 <andythenorth> maybe we should just fix OpenTTD
13:41:35 <peter1138> pass an industry ID how?
13:42:10 * andythenorth looks up the industry map count var
13:42:59 <andythenorth> it was a random idea, might be better to decide what's wrong with closures first :P
13:43:12 <andythenorth> frosch always says to let newgrf spec ripen a bit before changing
13:43:27 <andythenorth> I don't get attached to specific ideas
13:43:33 <andythenorth> except depot-flip for liveries :(
13:43:45 <andythenorth> maybe I should learn C++ and code that
13:44:19 <peter1138> Setting difficulty.max_loan changed from 100000 < 2000000000 < 500000 to 300000
13:44:31 <peter1138> So regression test save has a very weird max_load setting.
13:44:59 <peter1138> In master it gets clamped to 500000, in my branch it gets reset to the default 300000...
13:45:01 <TrueBrain> doesnt close PRs :o
13:45:28 <peter1138> Also that was a bloody strong gust of wind.
13:45:35 <peter1138> I should check my fence is still standing.
13:50:10 <peter1138> Hmm, weird, prices are different too.
13:56:49 <andythenorth> I wish my templater could unpack vars in a loop like python can :P
13:57:25 <peter1138> Hmm, maybe it should clamp unless it's a SGF_MULTISTRING.
13:57:39 <peter1138> But that's fairly arbitrary.
13:58:29 <andythenorth> will this 30W USB-C charger work with my 65W laptop? :P
14:02:19 <Alberth> I could add something loopy to py-xpd
14:03:07 <Alberth> also, the git-tag thing is broken, I need to fix that
14:03:19 <andythenorth> TrueBrain had opinions on git rev
14:03:55 <andythenorth> don't make me go to the logs :(
14:04:01 <TrueBrain> I only asked what version you wanted to give your FIRS
14:04:08 <andythenorth> the best version!
14:04:12 <TrueBrain> either 'git describe --tags' or 'git rev-list HEAD --count'
14:04:19 <TrueBrain> one is based on tag, commit since tags, etc
14:04:25 <TrueBrain> the other the amount of commits EVER in that branch
14:04:26 * andythenorth seriously considers writing a table of colours, and using those
14:04:52 <TrueBrain> where I can understand that the latter helps in NewGRF versioning when uploading to BaNaNaS (as it is ever increasing)
14:05:05 <Alberth> I picked tags, currently, more stable if you mess with commits and branches
14:05:15 <andythenorth> I wonder if we could end run this
14:05:16 <TrueBrain> that only works if you dont want a single integer :)
14:05:26 <andythenorth> why does OpenTTD compatibility need to be a number, incrementing?
14:05:38 <Alberth> major << x | minor << y | build << z
14:05:47 <peter1138> JGR has a feature-test system, instead.
14:05:53 <TrueBrain> that only works if tags are semvers :D (but fair assumption)
14:06:23 <Alberth> currently single numbers are semvers
14:06:31 <andythenorth> we don't allow changing newgrfs on savegames anyway, right?
14:06:37 <andythenorth> so what's this feature even for?
14:06:52 * andythenorth just checking we don't gold plate a nothing feature :)
14:07:00 <Alberth> compatibility, you get a save game with a grf you don't have the right version
14:07:51 *** frosch123 has joined #openttd
14:08:54 <Alberth> otherwise you'd have to define compatibility over multi-number versions
14:10:30 <andythenorth> so bumping the action 14 is a manual action anyway
14:10:45 <andythenorth> and there are two reasons to want a rev from the repo
14:10:50 <peter1138> Should I scrap my nrt changes and try from the original branch again?
14:11:12 <andythenorth> 1. quick way to automatically get a value for action 14 to compare
14:11:12 <peter1138> I'm going with no here :p
14:11:25 <andythenorth> 2. get a rev for use in filename, directory listing etc
14:11:54 <andythenorth> nobody sent me the rebase memo, it's banned at work
14:12:06 <andythenorth> and Wolf uses a windows gui client for git that merges automatically
14:12:23 <andythenorth> still, at least we got progress towards just using git, eh?
14:12:46 <peter1138> I'm just trying to look at history to find out why something is changed.
14:12:51 <andythenorth> history is horrid
14:13:16 <andythenorth> ok so I could just manually bump a rev for action 14
14:13:47 <andythenorth> it won't increment for push builds, but does that matter?
14:25:10 <Alberth> as long as you can distinguish dev-builds from release-builds, not really imho
14:27:01 *** olmvnec[m] has joined #openttd
14:27:30 <andythenorth> in most cases I can think of for (2), there should be a timestamp available
14:27:31 <TrueBrain> commits in release/1.9 are being rejected ..
14:27:35 <TrueBrain> it should not run the commit-checker :D
14:27:41 <andythenorth> e.g. push build listings etc should have a build date
14:27:50 <andythenorth> filesystem files should have date metadata
14:28:00 <andythenorth> no need to sort based on revs
14:28:43 <andythenorth> oof Alberth I have to confess I still haven't tried your module :)
14:28:58 <peter1138> "Service helicopters at helipads automatically"
14:29:06 <peter1138> Hmm... I thought that got removed.
14:29:15 <glx> seems the condition doesn't work
14:29:25 <Alberth> tried to fix the next-dev thing, but realized it interferes with release numbers :(
14:29:46 <andythenorth> how did I solve this at work?
14:30:14 <Alberth> time-stamp would be the useful thing, but how to squeeze that into a 32 bit number?
14:30:14 <andythenorth> yeah, untagged versions are named as 'last tag + hash'
14:30:20 <andythenorth> so just git describe basically
14:30:23 <andythenorth> e.g. 3.5.7-148-g0daa8a1c
14:30:31 <TrueBrain> glx: indeed, that doesn't work; neither for master
14:30:52 <glx> that was not testable while in PR
14:30:58 <nielsm> peter1138: I think we just agreed to pretend that "service at helipad" setting is always off
14:31:02 <Alberth> very unstable if you squash commits
14:31:19 <Alberth> which may happen in dev builds
14:31:32 <andythenorth> if used like this, the hash is just there to disambiguate between builds imho
14:31:40 <TrueBrain> glx: ah, the 'tag' is not resolved when the template is resolved
14:31:43 <peter1138> var = order.serviceathelipad
14:31:47 <TrueBrain> the Tag parameter is $(Build.JobName)
14:31:49 <TrueBrain> not 'commit-checker'
14:31:52 <andythenorth> occasionally e.g. openttd gets confused about which of the many FIRS to load
14:31:58 <glx> at least the fallback to master works
14:32:04 <andythenorth> so I check the rev in newgrf at that point if changes aren't showing
14:32:34 <andythenorth> but for normal use, the annotated semver tag would seem to be reliable enough
14:32:49 <andythenorth> maybe action 14 could just use the semver tags also
14:32:54 <peter1138> version = `date +%s`
14:32:54 <andythenorth> and the newgrf version in game
14:33:10 <Alberth> I have arrived at just using 1.2.3.4 style numbers, with the last number: 0=release, >0=dev build
14:34:17 <Alberth> peter: yep, would be so nice if openttd and newgrf could handle such strings as version number
14:34:23 <planetmaker> <andythenorth> so what's this feature even for? <-- so that OpenTTD offers you the latest and greatest of a single NewGRF in the selection dialogue - unless you specificially enabled "newgrf_show_old_versions"
14:34:46 <andythenorth> at least for annotated semver tags
14:35:06 <planetmaker> offer from the files you have on your local HDD
14:35:13 <andythenorth> Alberth: so x.y.z.a
14:35:40 <Alberth> yeah, or x.y.a probably, if you want just 2 values for a release
14:36:23 <TrueBrain> andythenorth: so you suggest we track in BaNaNaS which version is newer, and use that instead? :P
14:36:46 <andythenorth> but why have two versioning systems?
14:36:48 <Alberth> so you may want x.a ?
14:36:52 <andythenorth> I never did understand why we have two
14:37:12 <planetmaker> for newgrfs there only ever was one
14:37:26 <planetmaker> but.. not newgrf version of openttd
14:37:27 <andythenorth> not in my newgrds
14:37:35 <TrueBrain> andythenorth because someone once considered NewGRFs the center of the world? :D
14:37:41 <andythenorth> my newgrfs have had two versions since the action 14 was added?
14:37:48 <andythenorth> I never understood why
14:37:52 <planetmaker> that was you (and many other authors) who introduced on their own their own versioning scheme with more than one number
14:37:52 <andythenorth> I just cargo cult it around
14:38:06 <planetmaker> that many others include me, too, ofc
14:38:11 <andythenorth> yes, we were told to use semver!
14:38:15 <andythenorth> semver is the future! etc
14:38:20 <andythenorth> and then this other system too
14:38:38 <andythenorth> semver is weird anyway
14:38:40 <planetmaker> it's just what we tell users. But... so... just use x.y.z --> xyz
14:38:52 <planetmaker> simple mapping. pad a few 0s in between. Nice
14:39:34 <Alberth> would work, but makes discussing compatibility more complicated
14:40:03 <Alberth> or 3.2.1 which is compatible with 3.2 etc
14:40:13 <andythenorth> it doesn't work like that though
14:40:24 <andythenorth> no guaranteee that 3.2.2 is compatible with 3.2.1
14:40:30 <andythenorth> or 3.4 compatible with 3.3
14:40:49 <planetmaker> That is always the newgrf author's fault
14:41:00 <Alberth> planetmaker: does that increment if version numbers > 9??
14:41:35 <planetmaker> Alberth, there's a failure point, if a semver goes >9 or >99 (whether you pad with 0s or not)
14:41:43 <Alberth> 1.10 -> 1010, 2.0 -> 200
14:42:06 <planetmaker> that's why I rather suggest 1.9.0 -> 10900 and not 190
14:43:16 <planetmaker> problem remaining: versions for nightly builds
14:43:27 <planetmaker> that is actually where it really matters most
14:43:39 <planetmaker> so maybe add another 2 or 3 trailing digits for the nightly rev
14:43:50 <planetmaker> which counts commits since last tag or so
14:43:57 <planetmaker> just linear counting
14:44:04 <andythenorth> according to semver, FIRS should be on about version 350
14:44:24 <TrueBrain> stop breaking things :P
14:44:28 <andythenorth> strictly applying semver to newgrf just makes no sense
14:44:34 <andythenorth> semver is a bit of a turkey anyway
14:45:15 <TrueBrain> strict semver is only useful for APIs and libraries (which is also an API :P)
14:45:38 <andythenorth> applying them to content (savegames) is weird
14:45:49 <TrueBrain> just redefine it a bit :)
14:45:50 <peter1138> planetmaker, do we want to require approvals for things like nml repo?
14:46:04 <planetmaker> peter1138, you mean for PRs?
14:46:51 <planetmaker> generally I'd say yes. But grant direct commit rights to some? I'd not want automatic PR integration from <random folks>
14:47:16 <peter1138> Pretty sure PR integretion is never from random folk
14:47:20 <Alberth> 32bit, so 9 digits available
14:47:23 <planetmaker> Doesn't hurt me, if I make a PR and accept my own :P
14:47:52 <planetmaker> Alberth, yes... so like 1.9.0-dev234 would be like 109000234
14:48:05 <peter1138> Just depends if we want to run it like openttd-git or openttd-svn
14:48:07 <planetmaker> which is actually similar to the NewGRF version OpenTTD's NewGRF API offers
14:48:37 <planetmaker> peter1138, I prefer to keep workflows similar. Less friction IMHO
14:48:45 <Alberth> I wonder if major would need > 9
14:49:05 <planetmaker> Alberth, for NewGRF: yes. thinking of andy :P
14:49:31 <andythenorth> when it gets to 9, just declare it awful, and start a new project
14:49:47 <andythenorth> FISH is on about version 9, but I restarted it 3 times
14:49:49 <Alberth> 1.9.0-dev234 would be 010900234 btw
14:49:54 <andythenorth> av9 is a gag on av8 :D
14:50:20 <andythenorth> how do we derive the dev version? From git rev count?
14:50:22 <planetmaker> yes... but leading 0s are easily optimized away... as long as there's still bit-space to add, when they become needed
14:50:32 <planetmaker> andythenorth, I'd say 'yes'
14:50:39 <Alberth> that gives you one more digit for development builds
14:50:54 <andythenorth> so 4.0.0 is just 4000000
14:50:59 <planetmaker> 9999 dev builds between two releases should suffice, should it?
14:51:09 <planetmaker> if not... you're doing it wrong [TM]
14:51:21 <peter1138> andythenorth does a lot of that ;)
14:51:35 <planetmaker> 4.0.0 -> 400000000
14:51:37 <peter1138> You keep saying so!
14:51:42 <andythenorth> progress requires certain amounts of destruction
14:51:51 <planetmaker> you say that a lot, too :P
14:51:52 <Alberth> 4 00 00 0000 lots of zeroes :)
14:52:06 <andythenorth> so how would it handle alpha, beta, RC releases?
14:52:09 <planetmaker> it's not so much for human digestion. Yet still to understand
14:52:24 <Alberth> but perhaps project-decided, rev count or tags
14:52:59 <andythenorth> shall we make action 14 understand dev versions?
14:53:03 <Alberth> alpha: dev > 8000, beta: dev > 9000, RC: dev > 9900
14:53:30 <planetmaker> alpha... isn't that rather dev >= 0?
14:54:05 <andythenorth> what if we design this from Bananas POV instead of newgrf author? o_O
14:54:13 <Alberth> in my mind it's a pre-release, not some random development version, but it's a project decision probably
14:54:16 <andythenorth> we need a way to distribute nightly / alpha / beta / RC
14:56:07 <planetmaker> ok, I always considered alphas random dev versions while betas were already something to test for very eager people
14:56:55 <planetmaker> anyway, that's complete side-tracking
14:57:30 <planetmaker> andythenorth, how would bananas POV differ from newgrf author? (bananas has not POV. Maybe users have :P )
14:58:25 <andythenorth> the users I have in mind are developers, or other people who might turn on 'show unreleased content' for bananas
14:58:38 <andythenorth> specifically it would help with bug reports, and with developing newgrf spec
14:59:35 <planetmaker> so... like ... openttd offers 'nightly', 'testing' and 'stable' branches for download?
14:59:44 <andythenorth> maybe frosch123 solved all this already in bananas2? o_O
14:59:47 <planetmaker> on steam you can specifically opt-in to dev versions of programmes
15:00:41 *** Thedarkb-T60 has joined #openttd
15:02:58 <peter1138> How does one reply to that without being sarcastic as heck?
15:03:16 <planetmaker> peter1138, by replying not at all
15:04:01 <TrueBrain> lol; okay, that was entertaining :)
15:04:29 <TrueBrain> why listen to advise you get .. it is easier to ignore :D
15:05:07 <planetmaker> though... just found a possible answer :P
15:05:55 <planetmaker> I think his problem might be differently than he thinks
15:08:00 <andythenorth> I always get spanked by openttd.cfg
15:08:09 <andythenorth> I often have 3 or 4 OpenTTDs open
15:10:54 <Alberth> I make copies of openttd.cfg in each bin directory, and link downloaded content directoy to the ~/.openttd/content_download so it's shared
15:11:43 <TrueBrain> glx: sorry for commenting on things that were already there .. :D
15:12:04 <planetmaker> <Alberth> I make copies of openttd.cfg in each bin directory, and link downloaded content directoy to the ~/.openttd/content_download so it's shared <-- so do I. Especially on the servers
15:12:38 <planetmaker> locally... the content_download and cfg in ~/.openttd is shared anyway when nothing local is present
15:12:46 <Alberth> in the file name, we could indeed replace "dev" by "alpha/beta/rc"-ish
15:14:00 <Alberth> without the link, it doesn't find downloaded content iirc, or it doesn't put it there or so, was a long time ago
15:14:50 *** supermop_Home_ has joined #openttd
15:15:07 <glx> or should we wait the next backport batch ?
15:15:11 <DorpsGek_II> [OpenTTD/OpenTTD] nikolas updated pull request #7086: Change #6173: Update SDL driver to use SDL 2.0 https://git.io/fhamZ
15:15:30 <TrueBrain> nah, fix it asap :)
15:15:34 <TrueBrain> but that is one hard to read statement :P
15:15:45 <TrueBrain> double spaces before or()
15:16:16 <planetmaker> indeed, Alberth . but what about the newgrf version?
15:16:22 <TrueBrain> glx: please add a comment what it is doing :) But yeah, looks fine to me
15:16:24 <planetmaker> just count it up normally?
15:16:35 <planetmaker> in the scheme as discussed above?
15:16:47 <Alberth> as we discussed, 9 digit number?
15:17:38 <andythenorth> nielsm: to confirm the produce syntax here https://0x0.st/zHBc.txt "TOYS: LOAD_PERM(4)" could equally well be temp register, or a var?
15:17:55 <planetmaker> it's a bit difficult as 1.9.0 -> 10900 0000 < 10900 0234 = 1.9.0-betaX
15:17:59 <Alberth> likely with some guide for numbering alphas, betas, and rcs
15:18:39 <andythenorth> bake semver parsing into action 14 :P
15:18:40 <nielsm> andythenorth: probably yes, if you put an expression that isn't a pure load from a single register, nmlc generates an whatever intermediate varaction2s required to put that into a temp register
15:19:29 <Alberth> release has 9999 as dev number?
15:19:38 <Alberth> looks very weird though
15:19:55 <planetmaker> basically that's what openttd did, though. adding a 'released' bit
15:20:25 <planetmaker> so that the announced newgrf version of releases was always bigger than dev versions
15:20:59 <andythenorth> oof YAGNI strikes FIRS
15:21:09 <DorpsGek_II> [OpenTTD/OpenTTD] glx22 opened pull request #7360: Fix: [AzurePipelines] run commit checker only for PRs https://git.io/fhh7z
15:21:38 <Alberth> but newgrfversion is not used in filenames etc, so should be fine?
15:21:52 <DorpsGek_II> [OpenTTD/OpenTTD] TrueBrain commented on pull request #7360: Fix: [AzurePipelines] run commit checker only for PRs https://git.io/fhh7g
15:22:07 <Alberth> except it should bark for dev9999
15:23:16 <DorpsGek_II> [OpenTTD/OpenTTD] glx22 updated pull request #7360: Fix: [AzurePipelines] run commit checker only for PRs https://git.io/fhh7z
15:23:29 <Alberth> other option is to do development against the current release, and increment major, minor, of sub-minor on release
15:23:40 <planetmaker> what happens between 1.9.0-beta1 and 1.9.0-beta2?
15:23:44 <DorpsGek_II> [OpenTTD/OpenTTD] TrueBrain approved pull request #7360: Fix: [AzurePipelines] run commit checker only for PRs https://git.io/fhh7V
15:23:58 <planetmaker> and -rc1 ... rc3?
15:24:11 <planetmaker> it's all 1.9.0-dev9999 then. drat
15:24:15 <Alberth> what can happen between beta1 and beta2?
15:24:22 <planetmaker> just a few additional commits
15:25:22 <Alberth> number is still the dev number, so I would suggest you have beta9100, beta9200 etc
15:25:31 <andythenorth> recent Iron Horse alphas have been dramatically game breaking
15:25:42 <planetmaker> ah. sorry, yes, got myself confused
15:25:56 <Alberth> unless +9000 is implied by "beta"
15:26:27 *** Thedarkb-X40 has joined #openttd
15:26:56 <andythenorth> at least 9000 :P
15:27:29 <Alberth> start at 9990 for extra challenge :p
15:27:52 * andythenorth ponders arithmetic
15:28:01 <TrueBrain> glx: we are already 95 commits in cmake branch :P
15:28:07 <TrueBrain> rebasing is annoying :D
15:34:21 <TrueBrain> glx: I will be pushing a rebase soon; I have not really tested it that well, so possibly things somewhat break. This is also a force push that I will be doing for it
15:34:45 <glx> I have no pending stuff locally so it should be ok :)
15:35:14 <DorpsGek_II> [OpenTTD/OpenTTD] TrueBrain updated pull request #7270: Introduce CMake (and removing all other project-related code) https://git.io/fhbqc
15:35:22 <TrueBrain> lets see how much I broke :P
15:35:25 <DorpsGek_II> [OpenTTD/OpenTTD] glx22 merged pull request #7360: Fix: [AzurePipelines] run commit checker only for PRs https://git.io/fhh7z
15:36:36 <TrueBrain> over time, we should look into skipping it completely, I think
15:36:42 <TrueBrain> this is a silly waste of CPU time :P
15:36:44 <TrueBrain> but .. not that important
15:39:11 <andythenorth> not sure why FIRS mucks about tracking boost from each cargo
15:39:21 <andythenorth> 8 coal = 2 steel
15:39:26 <andythenorth> 8 iron = 2 steel
15:39:48 <andythenorth> 8 coal = 4 steel if iron also delivered
15:39:56 <andythenorth> 8 iron = 4 steel if coal also delivered
15:40:04 *** Beerbelott has joined #openttd
15:40:15 <andythenorth> the idea works great, the FIRS code for it is weird
15:41:14 <andythenorth> LOAD_TEMP(${var_received_timely_2}) * ${industry.get_boost(2,1,economy)}
15:41:25 <DorpsGek_II> [OpenTTD/OpenTTD] nikolas commented on pull request #7086: Change #6173: Update SDL driver to use SDL 2.0 https://git.io/fhh71
15:44:15 <TrueBrain> "*** First line of message must match: '<keyword>( #<issue>| <commit>(, (<keyword> #<issue>|<commit>))*)?: ([<section])? <Details>'" <- doesnt mention WHICH commit failed :D
15:45:46 <TrueBrain> hmm, none appear to be wrong
15:46:11 * andythenorth sends TB flowers
15:46:20 <TrueBrain> and a small violin?
15:46:48 <andythenorth> I had a nice time talking to someone in Blitz yesterday
15:46:54 <andythenorth> he killed me, so I said 'Lol'
15:47:02 <andythenorth> then he spent ages DMing me 'cry cry'
15:47:22 <andythenorth> then he said 'I know how to deal with trolls like you sending me messages'
15:47:32 <andythenorth> but he started the conversation in DM :(
15:47:55 <andythenorth> Blitz is an idiot magnet, unless all MMOG are this way?
15:48:08 <TrueBrain> you should have been there :P
15:48:40 <andythenorth> so bananas 2 then?
15:50:22 <peter1138> I don't have the will-power to think about splitting it up.
15:51:06 <peter1138> Maybe the language changes
16:00:30 <andythenorth> eh the original PR twice said 'one big block'
16:01:58 <peter1138> That is pretty huge
16:04:03 <peter1138> Hmm, strange. I've just found a load more comments from LordAro that github didn't show me before o_O
16:04:25 <LordAro> was it the "show hidden conversations" button?
16:04:51 <glx> TrueBrain: I think one of my latest commits had an incorrect message
16:05:36 <glx> TrueBrain: indeed the one before the rebase
16:05:51 <glx> CodeChange should be Codechange
16:07:02 <TrueBrain> hmm .. I hope I did not remove any of yours commits glx
16:07:07 <TrueBrain> (in the earlier rebase)
16:07:50 <TrueBrain> can you check your local copy?
16:08:07 <andythenorth> sometimes nml wants string literals, and sometimes not :P
16:08:58 <nielsm> needs lisp/ruby style symbol quoting
16:09:50 <DorpsGek_II> [OpenTTD/OpenTTD] TrueBrain updated pull request #7270: Introduce CMake (and removing all other project-related code) https://git.io/fhbqc
16:09:54 <TrueBrain> fixes the commit message error :P
16:10:14 <TrueBrain> okay .. I think all the commits are still in there, but please check glx if you can :)
16:12:01 *** synchris has joined #openttd
16:12:03 *** octernion has joined #openttd
16:15:16 <Eddi|zuHause> <andythenorth> "IORE" and IORE <-- the difference there is when it needs the label, or the position in the CTT
16:15:32 <Eddi|zuHause> andythenorth: it will also be different in NFO
16:23:12 <glx> TrueBrain: no missing commits it seems
16:23:52 <glx> but rebasing my branches will be fun
16:24:19 <glx> I get conflicts in the very old commits
16:24:38 <TrueBrain> as the work you are based on is unchanged
16:25:12 <glx> probably the way I'm rebasing is wrong
16:25:15 <TrueBrain> otherwise cherry-pick your work on top of cmake branch
16:31:38 <peter1138> Now I'm done, unless there are more hidden comments :p
16:42:55 <andythenorth> compiles, haven't tested it actually works yet
16:43:07 <andythenorth> merge 16-cargo PR? :P
16:43:15 <peter1138> Is it rude to take someone's commits in another... branch... and make a PR of them?
16:43:46 <planetmaker> a matter of personal perspective. Attribute it and it's legally fine ;)
16:44:56 <michi_cc> If you pick them properly (i.e. let git keep author information), why not?
16:45:15 <peter1138> I did have to edit it quite a lot as well, heh.
16:45:17 <michi_cc> After all, they where published under GPL.
16:45:36 <peter1138> I kept the author, but actually it's kinda not in places. heh.
16:47:30 <michi_cc> I've done more than one "(inspired by/based on patch from XXX)" svn commit and nobody complained.
16:48:03 <michi_cc> Which "inspired" meant original patch was utter crap and "based on" meant at least one line survived :p
16:52:28 <DorpsGek_II> [OpenTTD/OpenTTD] PeterN opened pull request #7361: Change: Use default value for invalid settings instead of clamping to min or max value. https://git.io/fhhdL
16:54:13 <DorpsGek_II> [OpenTTD/OpenTTD] nikolas updated pull request #7086: Change #6173: Update SDL driver to use SDL 2.0 https://git.io/fhamZ
16:56:28 <peter1138> You know, now that I'm getting to write the PR description, I can't see the point of it :p
16:58:14 *** Wormnest has joined #openttd
16:58:33 <DorpsGek_II> [OpenTTD/OpenTTD] PeterN opened pull request #7362: Feature: Reverse train at waypoint orders (jgr) https://git.io/fhhd3
16:59:07 <glx> hmm doesn't #7361 breaks settings change in GUI, or console ?
16:59:56 <DorpsGek_II> [OpenTTD/OpenTTD] TrueBrain opened pull request #7363: Lot of small codefixes related to configure https://git.io/fhhdG
16:59:57 <andythenorth> reverse train at waypoint is quite lolz :)
17:00:08 <andythenorth> tempted to find an arbitrary pointless use for that :)
17:00:16 <peter1138> andythenorth, it is.
17:00:26 <andythenorth> I was going to say just use a balloon track
17:00:31 <Eddi|zuHause> it would be useful for shunting :p
17:00:33 <peter1138> it's like trying to do shunting or something.
17:00:36 <andythenorth> but could make switchbacks go up hills
17:00:45 <andythenorth> without risking pathfinder confusion
17:01:02 <peter1138> glx, I don't think so?
17:01:03 <andythenorth> we need more stuff that's lolz
17:01:10 <Eddi|zuHause> i once had a track layout with a waypoint in a siding to reverse
17:01:12 <andythenorth> and less stuff that's making model trains
17:01:19 <andythenorth> I have model trains in the loft already
17:01:21 <peter1138> glx, it definitely breaks some things.
17:01:39 <andythenorth> also, one of the best things to do with model trains is crash them :P
17:01:55 <peter1138> andythenorth, i think reversing at waypoints is a model-trains feature, tbh.
17:01:57 <TrueBrain> glx: can you check if #7363 works on MingW and MSVC, and that project file generation results in the same after that PR? (some things I cannot test here, because I have a space in my folder .....)
17:02:10 <planetmaker> I sometimes wonder whether we should sketch-up a design for OpenTTD 2.0 which removes LOTS of old cruft, maybe all. And with a clean design of APIs etc
17:02:14 <andythenorth> how about more lols?
17:02:31 <planetmaker> sure, taking time to design it. But then actually taking the parts we need and filling in those we don't like
17:02:32 <Eddi|zuHause> #7361 might solve an issue i had once (or maybe that was solved meanwhile), where i had an invalid textual setting in the .cfg, and it would init to 0 instead of default
17:03:10 <andythenorth> planetmaker: the idea always appeals
17:03:18 <andythenorth> do big rewrites succeed though?
17:03:30 <andythenorth> or do they get stuck in spec war hell? o_O
17:03:36 <Eddi|zuHause> planetmaker: but what is openttd if it's not backwards compatible with original TTD?
17:03:53 <peter1138> Clean design of API? Which API?
17:04:02 <DorpsGek_II> [OpenTTD/OpenTTD] TrueBrain updated pull request #7363: Lot of small codefixes related to configure https://git.io/fhhdG
17:04:02 <planetmaker> newgrfs? game scripts, ai
17:04:18 <TrueBrain> glx: oops, I should try tings myself before I ask; lalala :D (it works now on Linux :P)
17:05:38 <peter1138> Eddi|zuHause, I think the issue there is if you don't change the setting, it'll leave it as the invalid setting for next time.
17:06:00 <Eddi|zuHause> peter1138: that's part of the issue, but not the actual problem
17:06:28 <peter1138> Changing NewGRF... not really feasible.
17:06:47 <peter1138> You'd either reimplement what we've got, or make pretty much every existing addon not work.
17:06:49 <planetmaker> need not be... entirely
17:07:06 <planetmaker> yes, you'd do that. I know
17:07:23 <Eddi|zuHause> planetmaker: throwing away two decades of community work is hardly a good idea
17:07:29 <peter1138> And I'm sorry if the resolver design is bad, it was developed in our pre-C++ days.
17:07:48 <TrueBrain> we once started to rewrite every file, to be more sane .. it never went anywhere :P
17:08:02 <peter1138> Wait, that one was a success.
17:08:06 <TrueBrain> turns out that rewriting for rewriting was a terrible idea :(
17:08:16 <planetmaker> point is, we NEVER deprecate anything. And that is adding up. More and more. Making any progress exponentially more difficult
17:08:25 <TrueBrain> we about to remove OPF! :D
17:08:32 <peter1138> Progress on what though?
17:08:44 <peter1138> Progress is more about developer interest.
17:09:51 <peter1138> Also, savegame compatibility.
17:10:40 <peter1138> And I still think of AI/GS as a new API :p
17:10:54 <peter1138> It's still missing things that authors want.
17:11:03 <andythenorth> ouch, I always forget how to view perm storage in newgrf debug window
17:11:06 <planetmaker> And NewGRFs became a giant mess
17:11:15 <peter1138> But for some reason authors never seem to be able to specify what they want to be able to beyond "can't do that"
17:11:27 <DorpsGek_II> [OpenTTD/nml] andythenorth commented on pull request #15: Industries: support 16 cargos in / 16 cargos out https://git.io/fhhdg
17:11:52 <peter1138> Ad-hoc extenions, yes.
17:11:55 <andythenorth> nielsm: ^ that _might_ be a FIRS bug, but I'm inclined to say it's nml initially
17:13:00 <peter1138> I'm willing to take NewGRF being "a giant mess" and keep 15 years of addons.
17:13:23 <andythenorth> the mess doesn't bother me, just the PITA of working with newgrf to extend it
17:13:33 <andythenorth> I kinda like the mess
17:13:51 <peter1138> I don't really understand.
17:14:27 <peter1138> NewGRF gives us a defined, if sightly odd, way of doing things.
17:14:46 <peter1138> There's a few bits of cruft due to backwards compatability.
17:14:55 <Eddi|zuHause> i don't see what big feature is blocked that needs "throw away the current newgrf spec and make a new one"
17:14:58 <peter1138> Like CB36 duplicating some earlier callbacks.
17:15:03 <peter1138> Eddi|zuHause, exactly.
17:15:40 <andythenorth> I kind of enjoy most of it, it's like a building that's evolved
17:15:47 <andythenorth> but then sometimes you look in the cellar
17:15:50 <Eddi|zuHause> keeping old stuff around CAN block new development, but it doesn automatically have to.
17:15:53 <andythenorth> and there are many spiders
17:16:17 <peter1138> vehicle refitting is pretty simple if you don't try to abuse it for livery-bullshit.
17:16:47 <andythenorth> no really, it's not, because cargo units
17:16:56 <andythenorth> the problem with killing spiders is
17:16:57 <andythenorth> data:image/jpeg;base64,/9j/4AAQSkZJRgABAQAAAQABAAD/2wCEAAkGBxMQEhUSEhMWFRUVFRcVGBcXFxUYGBgYFxYWFhgYGBgYHSogGBolHhUYITIhJykrMC4uFx8zODMtNygtLisBCgoKDg0OGxAQGysmICUvLzIyNzUtMC0rLy0vLS0tLS0tLS8tLS0vLS8tLi0tLS8tLS0tLy0tLS0tLS0tLS0tLf/AABEIAMMBAwMBIgACEQEDEQH/xAAbAAABBQEBAAAAAAAAAAAAAAAAAQMEBQYCB//EAEUQAAIBAgQDBgMECAQFAwUAAAECEQADBBIhMQVBUQYTImFxgTKRoRRCUrEjYnKCksHR8AczosIVU7LS8RZDYyREc6Oz/8QAGwEAAQUBAQAAAAAAAAAAAAAAA
17:16:58 <andythenorth> ECAwQFBgf/xAAwEQACAgEDAgMIAgMAAwAAAAAAAQIDEQQhMRJBBRNRImFxgaGx0fAywRSR4QYjQv/aAAwDAQACEQMRAD8AoqjY/Zf2v9rVJqNeCsPFet24Y6MDOkrvI3BmrGqsjCp9XfYnqWZoi0U8lhCJGJskdRJH50CwhMDEWT1Et/Wuf8yP6ma/mRI1xZBHXT56VcGoJw6n/wB+z829akWLhckA22IJELc10O8EbU7zI45I5STYr2FOpUT1Gh+Y1rnuYIlmKhhmUnccxm3/APFShaQWSDYIuAGGCBjmmQQyEnp86i38QqgyYIB+IFdfep67pL+MvqQTjGSeUbbGdm8JaRrhtmFBJgydOgPOsHjMYua4FUpkZSFbcAMujRoDsdOTCtRi+J3b7BxpbeLeQEmFksxaJE
17:16:59 <peter1138> I quite dislike the "this is old and hard, we should drop it and start something new" mentality.
17:17:00 <andythenorth> BPIHz1ocZhw2JfNqDcURqP8A27bbjzVflWisxi5S9GZFL65qK7neJxeY27eRQQJzDMJGvhEqOkkdYrunMdh1ADAahlAMsfiYKdz0Jpqp/BJqWnePU0L9O6ZdLeRaKKStkhFopKKAClopKAFpKKWgBKWimrl9V0ZgJ6kUmQHaSeXOi2C5ypq0xoJ1PIDm3lIAGpIGtWFzhLW71rDlbZN5XeSTnlATHeDntsIEkQRVS/WwqeOWRztUXgr6WusTYa02Vwd4kiDJ1CtyB00I0MacwOasV2Rsj1Rew+MlJZQlLWb4xdz3T0QZR67k/PT2q54UpFpJJJIJ1k6EkjfyIqCrVqy6VaXHctWaaVdUbG/5EuiiirZWCiiigAoomiqkuWINClFIKUVCNINhJIMDVRrlUkxGxIMfEafO
17:17:00 <planetmaker> peter1138, the problem is, that one doesn't need to implement "I want CB X" cry. But solve the actual problem
17:17:01 <andythenorth> 7zO05iPyNc4f7n7Dachqv1/oKk1BCuEo7oIsjnDdGce4P5ikOHbk/zUH8iKk1yWimy0dD5iiTzZruRGwzafCYED4l06aTFdA3V2Le1wn/rFcnFtE5cs7SrneY2G+hqVicHibSi5cQKhjX4is/jAbQcqo206KLxJ4/3/ZJCyySzHD/0RGusCJXU6AlLf5oQa4bEMGzZCTMyrtoYgSMz+Q2qRdwzPu689k6iObUzYuEko9wKM0Kcn4TMHxb6T/erI1UJ4U5YFasznpX78x25jrjCCtzcH4A2xBHJeldLi2ich9CrqfbQj609nH/OtH2I/wBxpp8ZDKso8kA5CfDJgEiOvn16Vf0saKfZqtay/T8oWyU5vMiXSUtFbhAJS0lLQAUlLRQAUlVnEeNW7QIzSw5anXzqnv4jEv
17:17:03 <peter1138> THanks andythenorth
17:17:03 <andythenorth> GyhwCNRkAy5iSdpjWJqtbq6quWLhmmxj5bbt0Un6Vi8j3THPQHRiBOx0B586teM8BxVpFbMbiuC3hJzASAsqTOoIPvFQuFYy4q3GVCyhQHOUkCTAzEEZdzr5Vl2a2vUtdL9ncnVeIt9zXdhrmJsBu7wmYuFPjuohygTIBElTMzz0q04lj8V9qwzPhVW6ve92ouqwcMkMC0DLAg+dMdkOOHGKmGz2+8C5lzJcVgfibJcDGIJOkagcxVu9q/fezcui1auYd7haXYLcCNkdkbIQFlD5gESBzpSi3uZ7g1LLj6+vp8SFxrE4y4hL4ADKpObvUMKNSG6rpMeUiCAaqcY3dC5zydd5yhoPuYnyrecQsX3tsgtKcwAOW4CMpPi+ILymvOe16XbJyXUKtdZrkSh8AYkfCx55R7Gr
17:17:03 *** andythenorth was kicked by DorpsGek (TrueBrain)
17:17:05 <Eddi|zuHause> the cargo unit thing is a mess
17:17:07 <planetmaker> or sometimes even not
17:17:35 <peter1138> planetmaker, so in that case, what actual problem?
17:17:49 <TrueBrain> *flexes his response time*
17:18:02 <planetmaker> it often is more abstract than "I want X"
17:18:04 <peter1138> CB is a means to achieve something, it's not the problem itself.
17:18:10 *** andythenorth has joined #openttd
17:18:22 <TrueBrain> and thank you for the image
17:18:24 <andythenorth> HTH does 'copy image address' in Chrome get me that?
17:18:26 <planetmaker> so the CB might not be the best response to fix the problem.
17:18:31 <andythenorth> and crash my irc client in a loop
17:18:36 <TrueBrain> you said: copy image, I think :P
17:18:40 <planetmaker> whether it is, that is *our* repsonsibility. Which we often do not fulfill
17:18:45 <andythenorth> well that's what trying to kill spiders gets us
17:18:46 <peter1138> Can you give me an example of something "you want"?
17:18:51 <planetmaker> we just add another patch, enlarging the newgrf mess
17:19:46 <planetmaker> general-purpose stations to which I can assign facilities like rails, truck stop, airport capability (runway,...) or whatever
17:20:05 <Eddi|zuHause> that is not blocked by the newgrf specs at all
17:20:21 <andythenorth> it's blocked by the historical inertia around how newgrf is developed
17:20:25 <peter1138> Yeah, that's actually blocked by the architecture of TTD.
17:20:35 <andythenorth> I think that's what frustrates frosch, that incremental patches are added
17:20:41 <andythenorth> when sometimes a whole new layer might be better
17:20:55 <andythenorth> frosch123 can tell me if I'm wrong though
17:20:56 <peter1138> Okay, I'm basically being told I need to stop developing features.
17:21:08 <Eddi|zuHause> ... which is nonsense
17:21:19 <planetmaker> no, you are not, peter1138
17:21:33 <peter1138> We have loads of features being added that are completely unrelated to NewGRFs.
17:21:34 <planetmaker> Basically the complaint is "there is no vision on where we want to go"
17:21:44 <planetmaker> "developer interest" like your stated it, is no vision
17:21:51 <planetmaker> it's death-bit-by-bit
17:22:02 <Eddi|zuHause> planetmaker: but we don't get a vision by saying "we throw out all old stuff and start from scratch"
17:22:13 <planetmaker> or stagnation as many devs pull it in many directions, adding many patches here and there, making it all-over unmaintainable
17:23:05 <planetmaker> sure we don't get a vision by that, Eddi|zuHause. But letting backward compatibility etc, the details go, and getting an idea of what would be nice overall, design, UI,... would help formulate goals
17:23:06 <Eddi|zuHause> planetmaker: that argument is too general to be convincing
17:23:35 <planetmaker> when you have a vision of what you want to build, then you can start from where we are now, and change things step by step
17:23:44 <planetmaker> and do the bigger rewrites where they are needed
17:23:51 <Eddi|zuHause> planetmaker: it was almost definitely stagnant a year ago. not anymore.
17:23:52 <andythenorth> is there a way to debug an actual sprite in a compiled grf?
17:23:53 <peter1138> planetmaker, so what IS your vision, other than removing stuff which is working in the name of making a new vision?
17:24:02 <andythenorth> given a sprite number, can I just grfcodec -d ?
17:24:06 <andythenorth> and read the bytes
17:24:19 <Eddi|zuHause> planetmaker: because someone came by with a vision "we need a better collaboration tool"
17:24:32 <planetmaker> which gave us github
17:24:35 <peter1138> Because at the moment it still feels like you're telling me everything I do is pointless and we should be ripping it out.
17:24:50 <planetmaker> no, you misunderstand me, peter1138 . I try not say that
17:24:51 <Eddi|zuHause> planetmaker: but you just complain now, without providing an alternative
17:25:00 <Eddi|zuHause> planetmaker: that is not the same thing
17:25:10 <peter1138> You say newgrf needs to be stopped.
17:25:17 <planetmaker> I'm trying to say that we should beside the day-to-day "I want this" discuss more of where we want to go
17:25:25 <peter1138> Everything added to it is just an adhoc patch, adding to the mess.
17:25:26 <planetmaker> nope, peter1138, I did not say that
17:25:38 <Eddi|zuHause> yes, you very much said that.
17:25:40 <planetmaker> I said that, yes. But both are not identical statements
17:25:57 <andythenorth> 3346 * 19 02 0A FC 02 03 1F 80 0F 81 23 82 03 34 83 07 84 3E 85 86 'probably fine'
17:25:59 <planetmaker> "not working on it anymore" != "every addition makes a rewrite more difficult"
17:26:25 <peter1138> A rewrite has never been on the cards.
17:26:48 <Eddi|zuHause> that also is nonsense, as "a rewrite" has zero dependency on the amount of cruft already there...
17:27:06 <planetmaker> well, clearly you have no vision other than "just lets add this and that". Or what do *you* like to have OpenTTD be like in 10 years?
17:27:26 <Eddi|zuHause> well, clearly you don't have that either.
17:27:33 <peter1138> I don't know what YOU like to have OpenTTD to be like
17:27:42 <planetmaker> and that's why I'm saying it would help to get one
17:27:44 <peter1138> Other than no addons because we removed it all.
17:27:51 <planetmaker> I don't say that, peter1138
17:27:56 <planetmaker> you're red-herringing there
17:28:36 <peter1138> You want a rewrite because newgrf is crufty and crusty.
17:28:46 <planetmaker> I'm saying we should make the add-on apis easier to maintain
17:29:06 <planetmaker> they're complicated on both sides, in openttd and externally
17:29:14 <Eddi|zuHause> maybe, but not by "we invalidate all existing GRFs"
17:29:16 <planetmaker> duplicating parts,
17:29:17 <TrueBrain> I think, if I can interrupt, that planetmaker was using a solution to create a vision: a world where OpenTTD is a framework on which many functionalities are plugged in
17:29:30 <TrueBrain> I think he is simply asking if we can work by vision, instead of by day-to-day
17:29:39 <planetmaker> thank you TrueBrain !
17:29:41 <TrueBrain> sadly, that is exactly what my day job is, so I get that :P
17:29:45 <Eddi|zuHause> there is no "instead"
17:29:47 <peter1138> Okay, provide a vision.
17:30:01 <TrueBrain> I think it is interesting to note, that OpenTTD never had a real vision. We always went from big project to big project
17:30:08 <TrueBrain> so I am always a bit on the fence if we need one
17:30:10 <Eddi|zuHause> we can work day-to-day, or have a vision AND work day-to-day
17:30:14 <TrueBrain> we need big projects, that is for sure :)
17:30:19 <Eddi|zuHause> have a vision alone gets us nowhere
17:30:35 <planetmaker> TrueBrain, I think we had one till 1.0: recreate TTD and have it fully playable on its own
17:30:40 <peter1138> I also think you're are overstating the "mess"
17:30:48 <TrueBrain> (when I joined OpenTTD .. it was "big maps" .. "makefile rewrite" .. "network rewrite" .. "TGP" .. "NoAI" .. "GS" .. lost track of OpenTTD after that :P)
17:31:00 <peter1138> Now it's makefile rewrite...
17:31:01 <planetmaker> peter1138, so stations are completeley different than all the rest. So are bridges
17:31:14 <DorpsGek_II> [OpenTTD/OpenTTD] michicc commented on pull request #7363: Lot of small codefixes related to configure https://git.io/fhhdb
17:31:21 <peter1138> planetmaker, bridges have never been extended by newgrf.
17:31:23 <TrueBrain> planetmaker: that 1.0 is indeed fair :) That was also the reason we named it 1.0, if my memory serves me well :)
17:31:35 <planetmaker> TrueBrain, yes, that's what I recall, too
17:31:43 <peter1138> planetmaker, so that's a perfect place to start with a vision of "not newgrf mess"
17:32:06 <planetmaker> frosch123, has written about that quite nice summary already...
17:32:23 <Eddi|zuHause> "unify the station spec with the industry/object/whatever spec" is a perfectly fine goal
17:32:44 <Eddi|zuHause> frosch123 has had a "newgrf utopia" for years now.
17:32:49 <DorpsGek_II> [OpenTTD/OpenTTD] michicc commented on pull request #7363: Lot of small codefixes related to configure https://git.io/fhhdh
17:32:52 <peter1138> Yeah, stations are different because that's the spec :/
17:33:06 <peter1138> We could drop the old spec, and then... piss off everyone using them.
17:33:21 <peter1138> And it's only the tile layouts that are different.
17:33:32 <Eddi|zuHause> .. or we could make a new spec and call that GRFv9
17:33:46 <Eddi|zuHause> but we won't get around keeping "the old cruft" there
17:34:00 <planetmaker> we could, for instance, deprecate v6-
17:34:45 <Eddi|zuHause> no part of the code that handles the v6-specific stuff blocks any of the NewGRF Utopia features
17:35:09 <Eddi|zuHause> and a vision is useless, if you're not day-to-day-working towards that vision
17:35:39 <DorpsGek_II> [OpenTTD/OpenTTD] TrueBrain commented on pull request #7363: Lot of small codefixes related to configure https://git.io/fhhFU
17:36:08 <andythenorth> from the code I've seen in OpenTTD, the cruft there doesn't block much
17:36:14 <planetmaker> I don't find the graphics now, but frosch made a nice graph for refitting vehicles. That also would need unifying so that you don't have to learn it anew to differ between trains, rv, ships and planes
17:36:21 <andythenorth> it's in the toolchain and the wiki that the cruft hurts
17:36:34 <planetmaker> you're right there, andythenorth
17:36:37 <andythenorth> I don't think the cost of the C++ is the problem, based on limited evidence
17:36:48 <planetmaker> in newgrf.cpp it's mostly more code lines which live independently
17:37:14 <Eddi|zuHause> planetmaker: vehicle refitting is also not helped a single bit by ripping out the old code
17:37:17 <planetmaker> so yes, I concede, in OpenTTD that might remain, in the toolchains... it's less urgent to remain being able to still compile grfv6 or so
17:37:43 <planetmaker> as one of the biggest shortcomings is indeed the newgrf compilers...
17:37:54 <peter1138> So in nmlc we decided on removing the old pre-16-in-16-out cargo stuff.
17:38:08 <peter1138> And yet we were also told we need to keep compatibility.
17:38:48 <Eddi|zuHause> that went back and forth a bit. it's like different people have different visions...
17:38:53 <peter1138> Eddi|zuHause, quite.
17:39:00 <peter1138> planetmaker, you didn't what?
17:39:09 <nielsm> new ttd needs to work with old grf, but new nmlc only needs to produce modern grf?
17:39:24 <nielsm> imo a difference in production and consumption side
17:39:26 <planetmaker> nielsm, that's how I can live quite well
17:39:32 <peter1138> nielsm, but nmlc needs to compile old nml
17:39:52 <planetmaker> it's not like I can compile openttd 0.5 any longer. Unless I downgrade everything to 10 years back or so
17:39:56 <peter1138> I can't remember who was stating one thing and who was stating the opposite.
17:39:59 <DorpsGek_II> [OpenTTD/OpenTTD] TrueBrain updated pull request #7363: Lot of small codefixes related to configure https://git.io/fhhdG
17:40:16 <nielsm> for an nml project, there's very few consumers (just the developers), it's easy to coordinate with everyone to upgrade the project code to work with a new nml
17:40:23 <planetmaker> I always advocated to have nml only produce latest grf specs. It always had that stance before
17:40:35 <TrueBrain> bump major, go go :)
17:40:44 <nielsm> for a finished newgrf there's potentially thousands of consumers, it's near impossible to get everyone to (want to) upgrade
17:40:52 <planetmaker> and keeping a legacy version for a year to allow authors to transition existing code bases to new syntax
17:41:12 <Eddi|zuHause> planetmaker: there's still a difference between "produce new output" and "process existing input"
17:41:33 <DorpsGek_II> [OpenTTD/OpenTTD] TrueBrain updated pull request #7363: Lot of small codefixes related to configure https://git.io/fhhdG
17:41:42 <glx> use the old compiler if you want to parse old code
17:42:00 <nielsm> for a much larger project, Rust language seems to have done okay despite having breaking changes every so often
17:42:12 <planetmaker> Eddi|zuHause, we had that argument and I agreed
17:42:15 <Eddi|zuHause> i'd say in case of the 16-in-out, the code needed to process the old input (but produce the new output) is maybe 10loc
17:42:23 <nielsm> (though I admit not following it, just going by rumours here)
17:42:50 <planetmaker> ok, seems we don't
17:43:01 <Eddi|zuHause> you need to weigh carefully whether cutting those 10LOC are more important than having half a dozen people rewrite their GRFs
17:43:31 <Eddi|zuHause> planetmaker: i'm talking about nmlc here
17:43:32 <planetmaker> it's not much work for any author. And they have time
17:43:46 <peter1138> If they're still around.
17:44:03 <planetmaker> if not, it's unmaintained code. An existing NewGRF is not harmed, if nml changes
17:44:09 <andythenorth> it's quite meta this conversation :P
17:44:17 <andythenorth> meanwhile, in trying to actually get 16-cargos done
17:44:21 <peter1138> andythenorth, it's certainly not a vision.
17:44:26 <andythenorth> I do like a meta conversation
17:44:28 <peter1138> But we don't have one.
17:44:34 <peter1138> Our vision is to have a vision.
17:44:35 <andythenorth> I'm not even trolling
17:44:44 <andythenorth> but I only have today to try and make this 16-cargo business work
17:44:46 <peter1138> Meanwhile, stop everything because it's harder to have a vision.
17:44:47 <planetmaker> that's a way to kill any conversation, peter1138
17:45:03 <peter1138> planetmaker, it's a fruitless conversation.
17:45:08 <DorpsGek_II> [OpenTTD/OpenTTD] michicc commented on pull request #7363: Lot of small codefixes related to configure https://git.io/fhhFt
17:45:13 <andythenorth> so what's wrong with this?
17:45:14 <planetmaker> I totally disagree
17:45:14 <andythenorth> 3346 * 19 02 0A FC 02 03 1F 80 0F 81 23 82 03 34 83 07 84 3E 85 86
17:45:18 <andythenorth> why is it an invalid sprite?
17:45:20 <Eddi|zuHause> planetmaker: so, where is your advice to andythenorth to convert his existing grf to the new syntax?
17:45:31 <andythenorth> that's exactly what planetmaker advised
17:45:39 <peter1138> We've spent 45 minutes discussing and not doing anything.
17:45:41 <andythenorth> and that's exactly what I'm trying to do
17:45:43 <frosch123> Eddi|zuHause: andy does not use nml, so is not affected by any nml change
17:46:00 <Eddi|zuHause> frosch123: that is not quite correct :p
17:46:03 <planetmaker> just change a few lines in the nml-writer
17:46:09 * andythenorth plays blitz while we figure this out
17:46:18 <andythenorth> meanwhile, those bytes aren't valid, and I have NFI
17:46:18 <peter1138> andythenorth, what is the "sprite" mean to mbe?
17:46:21 <planetmaker> it has a production template anyway...
17:46:32 <peter1138> What produced the bytes?
17:46:39 <planetmaker> I don't even know the intended syntax
17:46:40 <Eddi|zuHause> andythenorth: it would help if you explained what the bytes meant
17:46:51 <andythenorth> isn't it obvious?
17:46:56 <andythenorth> it's sprite 3346
17:47:42 <peter1138> action 02 (varaction) feature 0a (industries)
17:48:15 <peter1138> What's the error you get with that sequence?
17:49:01 <glx> TrueBrain: ran generate and generate.vbs, no changes
17:49:06 <Eddi|zuHause> the 02 seems to be wrong
17:49:32 <Eddi|zuHause> expecting "type" here (81/85/89)
17:49:34 <glx> TrueBrain: and mingw builds and runs
17:50:26 <peter1138> depending on feature. apparnetly.
17:50:43 <Eddi|zuHause> oh, so it's a normal action2 not a varaction2?
17:51:28 <peter1138> Yeah, special production callback.
17:51:40 <andythenorth> so 86 looks like an odd value for last byte
17:51:47 <peter1138> planetmaker smirks as everything we talk about now proves his point :p
17:52:16 <peter1138> andythenorth, what generated this, if it's invalid?
17:52:24 <andythenorth> nml from that PR
17:52:35 <andythenorth> but I don't know if I'm using it correctly
17:53:05 <andythenorth> and reading the parser, which I gave up
17:53:28 <planetmaker> I have no reason to smirk. But yes, it kinda does prove my point
17:53:51 <Eddi|zuHause> andythenorth: so the last 86 seems to be the <again> entry
17:54:00 <Eddi|zuHause> andythenorth: not seeing anything fundamentally wrong with that
17:54:07 <Eddi|zuHause> without understanding what it does.
17:55:25 <andythenorth> are the register numbers valid?
17:55:47 <andythenorth> reading the bytes, it all looks correct
17:55:58 <andythenorth> is my openttd broken?
17:56:09 <Eddi|zuHause> what are registers >80?
17:57:25 <peter1138> andythenorth, if you look in the NewGRF settings window, it should tell you more about the error.
17:57:43 <DorpsGek_II> [OpenTTD/OpenTTD] JGRennison commented on pull request #7362: Feature: Reverse train at waypoint orders (jgr) https://git.io/fhhFg
17:58:58 <andythenorth> Fatal: Invalid industry production callback
17:59:23 <DorpsGek_II> [OpenTTD/OpenTTD] PeterN commented on pull request #7362: Feature: Reverse train at waypoint orders (jgr) https://git.io/fhhFa
17:59:38 <peter1138> error->data should ahve more info
17:59:58 <andythenorth> if only grfs were easy to share :P
18:00:46 <andythenorth> oh fuck off GH, no .tar allowed
18:01:05 *** snail_UES_ has joined #openttd
18:02:08 <DorpsGek_II> [OpenTTD/OpenTTD] Eddi-z commented on pull request #7362: Feature: Reverse train at waypoint orders (jgr) https://git.io/fhhFr
18:04:17 <peter1138> version 1. Yeah, that's not working :p
18:04:47 <andythenorth> new FIRS is version 1 :)
18:05:50 <andythenorth> I might just leave it on version 1 always
18:05:59 <Eddi|zuHause> that sounds like a horrible idea
18:07:16 <andythenorth> let's try changing the nml and see what happens
18:07:25 <peter1138> duplicate input cargo
18:07:50 <peter1138> I think the error string is wrong.
18:08:04 <peter1138> 2:RAW_STRING provides the error data 1:RAW_STRING is the grf name.
18:08:09 <Eddi|zuHause> i'm sure the patch was well-tested :p
18:09:34 <peter1138> ndex 0 - rawcargo 31, cargo 10
18:09:34 <peter1138> index 1 - rawcargo 15, cargo 255
18:09:34 <peter1138> index 2 - rawcargo 35, cargo 255
18:09:55 <andythenorth> Eddi|zuHause: you were absent during the last hour? o_O
18:09:57 <andythenorth> that's the testing :)
18:10:11 <peter1138> So 0F and 23 resolve to the same mapped cargo id (i.e. not mapped)
18:10:33 <Eddi|zuHause> andythenorth: there was this nonsense discussion in the last hour, that i'd rather pretend never happened
18:10:51 <peter1138> Your cargo type 0F and 23 and not mapped in the game.
18:11:04 <andythenorth> let's try hard-coding them
18:11:35 <peter1138> How many cargo types are you expecting here?
18:11:37 <andythenorth> I think it's a FIRS bug in that case
18:11:38 <Eddi|zuHause> andythenorth: you need a different produce block for every economy, it seems
18:11:49 <andythenorth> I suspect there are broken cargos in play
18:12:20 <peter1138> Eddi|zuHause, yes, because this is a result telling openttd where to find the values.
18:12:38 <peter1138> (It's not input for the newgrf to do something with)
18:12:53 <andythenorth> ok, so I have broken cargos, but they're compiling fine
18:13:03 <peter1138> How many cargo types should there be?
18:13:05 <DorpsGek_II> [OpenTTD/OpenTTD] glx22 updated pull request #7270: Introduce CMake (and removing all other project-related code) https://git.io/fhbqc
18:13:13 <andythenorth> they're not triggering any FIRS asserts, nor docs asserts, nor nml asserts :P
18:13:46 <andythenorth> if I try a different industry, it loads
18:13:53 <peter1138> But there can only be 64 cargo types tops.
18:15:21 <Eddi|zuHause> andythenorth: the way i understand the situation: each economy defines a subset of the cargo types. the produce block may only reference cargos that are in this current subset
18:15:56 <Eddi|zuHause> you're breaking that rule
18:16:09 <Eddi|zuHause> that's why openttd complains
18:16:56 <andythenorth> yep, looks like that's not wrapped
18:16:59 <Eddi|zuHause> andythenorth: what peter1138 was asking was, how many cargos are in the subset
18:17:13 <nielsm> hmm, the produce action2 in grf refers to cargo by its cargotable index, iirc
18:17:38 <Eddi|zuHause> nielsm: yes, but the cargotable can have more cargos in it, not all of them must be valid
18:17:58 <andythenorth> ok, so the old produce block never needed to reference cargos
18:18:02 <andythenorth> it was just position based
18:18:11 <andythenorth> so there's nothing to wrap it in a conditional
18:18:22 <nielsm> meaning different industries that followed the same rules but with different cargos, could share the same produce blocks
18:18:34 <Eddi|zuHause> it wasn't necessary before, but it's necessary now
18:18:36 <andythenorth> can I action 7 a produce block?
18:19:20 <peter1138> any action2 chain should be able to be broken up.
18:19:22 <Eddi|zuHause> you could have the produce block be referenced by a switch?
18:19:38 <Eddi|zuHause> iirc there was a giant warning about skipping action 2s
18:19:51 <Eddi|zuHause> advising to skip the action3 instead
18:20:05 <peter1138> Well I don't know anything. I have no vision.
18:20:36 <peter1138> nielsm, the error->data has a text message which is useful for diagnosis, but this is never output.
18:20:55 <andythenorth> nmlc ERROR: "generated/firs.nml", line 6061: produce-block may not appear inside a conditional block.
18:21:07 <andythenorth> yeah, I recall this, some blocks can't be conditional
18:21:18 <peter1138> nielsm, could be the STR_NEWGRF_ERROR_INDPROD_CALLBACK string refers to wrong parameters.
18:22:29 <andythenorth> nielsm: I am going to spend the rest of the day trying to fit myself onto one box of that grid
18:23:02 <Eddi|zuHause> andythenorth: try the switch idea?
18:23:30 <Eddi|zuHause> switch(economy) { 1: produce1; 2: produce2; ... }?
18:23:31 <andythenorth> I don't understand how to do that?
18:23:47 <andythenorth> or rather Eddi|zuHause I don't understand how that helps
18:23:48 <nielsm> hmm, I wonder if the produce cb should be changed to only resolve the actual cargo on call (or on first call maybe?)
18:24:06 <nielsm> so it's not an error to have a produce cb referencing a cargo that doesn't exist
18:24:15 <nielsm> only an error to use it
18:24:16 <Eddi|zuHause> andythenorth: do you have the nml code for the produce block?
18:24:20 <andythenorth> yes about to paste
18:24:28 <Eddi|zuHause> andythenorth: and the related industry
18:24:30 <peter1138> nielsm, it is pretty odd that this is checked on load, to be honest.
18:24:44 <andythenorth> I will paste more in a minute
18:24:58 <Eddi|zuHause> andythenorth: the location where "blast_furnace_simple_produce_0" is used
18:25:00 <andythenorth> children making electric helicopters here, which have sharp edges
18:25:05 <andythenorth> and are flying around the room
18:25:10 <andythenorth> one person bleeding already
18:25:24 <peter1138> nielsm, i'm worried this may end up being something that needs a backport.
18:25:37 <DorpsGek_II> [OpenTTD/OpenTTD] SamuXarick updated pull request #7184: Feature: Distribute cargo to multiple stations or industries https://git.io/fh9lr
18:26:06 <nielsm> I'm looking at the newgrf code now
18:26:17 <Samu> this was the most complex rebase I've ever experienced
18:26:24 <peter1138> I guess if you skip it it's okay,b ut....
18:26:38 <peter1138> Samu, yeah, some rebases are rewrites.
18:26:51 <nielsm> but it's difficult to concentrate with a bird insisting on tooting in weird rhythms all the time
18:27:34 <peter1138> Samu, well... thats, er... one way to do it...
18:27:35 <andythenorth> you don't need the action 0 or action 3, the entry point is blast_furnace_produce
18:28:11 <andythenorth> I've included the not-allowed-by-nml action 7s
18:28:16 <andythenorth> I can drop those if it helps
18:28:36 <peter1138> Yeah you are switching on economy, that looks like it should be correct.
18:28:43 <Eddi|zuHause> andythenorth: ok, so it's already guarded by economy switch
18:28:48 <peter1138> As nielsm says, it's a loading error.
18:28:59 <andythenorth> the problem is resolving cargo labels no?
18:29:04 <Eddi|zuHause> so openttd is complaining about the content of an action2 that shouldn't be executed
18:29:15 <Eddi|zuHause> which seems to be a bug in the patch
18:29:40 <peter1138> Should be simple to fix.
18:29:56 <peter1138> Accept invalid cargo mappings.
18:30:29 <Eddi|zuHause> accept invalid mappings in the loading phase, but complain in the execution
18:30:54 <peter1138> So if it's 0xFF when actually running it, then it's an error.
18:31:08 <peter1138> The mapping doesn't need to be moved.
18:31:56 <peter1138> It may be desirable to make loading give an invalid callback result rather than one that looks valid but isn't.
18:32:05 <peter1138> But either case would be checked in the same place, I guess.
18:32:40 <nielsm> ugh, this is annoying... I can either resolve the actual CargoIDs every time the cb is executed
18:32:45 <Eddi|zuHause> weather looking like "better not go outside"
18:32:48 <peter1138> nielsm, it's fine where they are
18:33:09 <nielsm> or I can do some ugly caching that will involve either const_cast or mutable
18:33:13 <peter1138> if (cargo_index < 0 ) continue;
18:33:20 <peter1138> I don't think cargo_index < 0 is possible.
18:33:41 <peter1138> if it is, it already handles the case correctly.
18:34:05 <peter1138> if (cargo == CT_INVALID) return -1;
18:34:29 <peter1138> So the only bit missing is reporting an error if cargo_index < 0 there.
18:35:45 <nielsm> okay I was misunderstanding the problem then
18:35:54 <nielsm> I thought the grf was failing to load at all
18:36:04 <nielsm> but it's just malfunctioning?
18:36:15 <peter1138> Shall I make a PR for andythenorth to test?
18:36:29 <nielsm> if you have a better overview than me then yes please
18:38:48 <Samu> oops, some stuff needs fixing yet
18:39:35 <andythenorth> just put a patch on FS?
18:40:01 <DorpsGek_II> [OpenTTD/OpenTTD] PeterN opened pull request #7364: Fix e66cec8f86: Permit loading of industry production callback with invalid cargo type. https://git.io/fhhbB
18:40:16 <peter1138> That branch name though.
18:41:37 <peter1138> So the bit missing now is to pop up an error if it skips a cargo type.
18:41:39 <nielsm> hmm, I'd rather keep those if blocks
18:41:41 <peter1138> Or maybe that's valid?
18:41:48 <nielsm> but add a condition to them, cargo != CT_INVALID
18:42:10 <nielsm> it's okay to resolve multiple invalid cargoes, but it's not okay to resolve the same type multiplem times
18:42:32 <peter1138> Okay, I'll tweak it. Meanwhile andythenorth can test the rest of his production code.
18:43:20 <peter1138> nielsm, did you understand about the error->data message?
18:43:47 <peter1138> Currently it shows the grf name in quotes.
18:44:06 <peter1138> I wonder if that is not the intention, and perhaps it should show the error->data message instead?
18:44:10 <andythenorth> ok peter1138 that now loads the grf
18:44:44 <peter1138> andythenorth, yup, I know that. I don't know enough about your mechanics to acvtually test production :)
18:44:48 <DorpsGek_II> [OpenTTD/OpenTTD] andythenorth commented on pull request #7364: Fix e66cec8f86: Permit loading of industry production callback with invalid cargo type. https://git.io/fhhb0
18:45:19 <andythenorth> I'm a ways off anything working
18:45:31 <andythenorth> FIRS stuck rigidly to assumptions of 3 in, 2 out, because YAGNI
18:46:36 <nielsm> peter1138: nope, GRFError is weird to me
18:46:46 <andythenorth> is there a way to give a list as args to make?
18:46:51 <DorpsGek_II> [OpenTTD/OpenTTD] PeterN updated pull request #7364: Fix e66cec8f86: Permit loading of industry production callback with invalid cargo type. https://git.io/fhhbB
18:46:57 <andythenorth> I can pass a single industry name and it will compile only that
18:47:02 <DorpsGek_II> [OpenTTD/OpenTTD] SamuXarick updated pull request #7184: Feature: Distribute cargo to multiple stations or industries https://git.io/fh9lr
18:47:03 <andythenorth> but I can't pass multiple
18:47:36 <peter1138> nielsm, so now it permits CT_INVALID but otherwise checks duplicates.
18:48:01 <peter1138> I hope that some "economy" setting doesn't result in the same cargo ID for different mappings. I should not.
18:48:42 <andythenorth> peter1138: wouldn't that imply changing the cargo ID?
18:48:44 <Samu> shouldn't this Include be done after ensuring that at least 1 amount is moved?
18:49:43 <andythenorth> or does it go via the CTT?
18:49:45 <Samu> uint amount = min(num_pieces, 0xFFFFU - ind->incoming_cargo_waiting[cargo_index]); can make amount == 0
18:49:55 <andythenorth> I mean, who'd change the cargo ID? :P Except me
18:50:20 <peter1138> andythenorth, it's all via the CTT. Not using the CTT would be an early-version GRF.
18:50:37 <andythenorth> there was something once about multiple CTTs
18:50:44 <andythenorth> it was a little drama
18:50:50 <peter1138> There are lots of CTTs.
18:50:58 <peter1138> They're unique to each loaded NewGRF.
18:51:04 <andythenorth> this was multiple in same grf
18:51:19 <andythenorth> adapting the CTT to different vehicle sets
18:51:23 <peter1138> Samu, I don't think it can be.
18:51:58 <Samu> why include an industry to the list if it receives 0?
18:52:16 <planetmaker> it might get something later?
18:52:19 <peter1138> Samu, prove to me that it can receive 0 at that point.
18:52:55 <Samu> incoming_cargo_waiting could be a stockpile
18:53:50 <nielsm> peter1138, I think it can reach that line even if ind->incoming_cargo_waiting[cargo_index] == 0xFFFF
18:54:10 <nielsm> so the second arg to min would become zero
18:55:27 <nielsm> question is, should be industry count as having received a delivery (of zero) if its stockpile is full?
18:55:28 <peter1138> And the problem is it will trigger production when it should not have done.
18:55:36 <peter1138> nielsm, probably not.
18:56:46 <peter1138> Samu, i guess this is just a case of explaining the problem clearly :p
18:57:18 <peter1138> andythenorth, I updated the PR if you want to retry it.
18:57:47 <nielsm> the PR looks correct, I'll approve it if andythenorth can confirm it works
18:58:21 <peter1138> I guess this is an edge-case due to andythenorth implementing multiple "economies" on one NewGRF.
18:58:25 <peter1138> But it would be nice to backport it.
18:58:46 <nielsm> imo 1.9.0 ought to work with upcoming FIRS :)
18:59:04 *** buggeas40d[m] has joined #openttd
18:59:11 <andythenorth> but upcoming FIRS is more like 1.12 or something
18:59:15 <andythenorth> takes a long time, FIRSing
18:59:27 <peter1138> Urgh, I need to update all the strings too :/
18:59:45 <peter1138> Apparently it's snowing.
18:59:52 <DorpsGek_II> [OpenTTD/OpenTTD] andythenorth commented on pull request #7364: Fix e66cec8f86: Permit loading of industry production callback with invalid cargo type. https://git.io/fhhb6
19:00:46 <andythenorth> so passing shell args as a list? o_O
19:02:58 <DorpsGek_II> [OpenTTD/OpenTTD] PeterN updated pull request #7364: Fix e66cec8f86: Permit loading of industry production callback with invalid cargo type. https://git.io/fhhbB
19:03:48 <peter1138> So, one remaining issue.
19:04:00 <peter1138> It's an error to use this broken production callback, but that's not enforced.
19:04:20 <nielsm> if it has invalid cargos? I guess yeah
19:04:37 <peter1138> Hmm, there's an "ErrorUnknownCallbackResult()"
19:04:42 <peter1138> It's not quite unknown :p
19:05:30 <peter1138> Is it an invalid result, though.
19:05:35 <peter1138> * Record that a NewGRF returned an unknown/invalid callback result.
19:05:35 <nielsm> ShowErrorMessage(STR_NEWGRF_BUGGY, STR_NEWGRF_BUGGY_something_new_with_invalid_cargos, WL_ERROR);
19:05:52 <Samu> so, "should the industry count as having received a delivery (of zero) if its stockpile is full?"
19:06:08 <nielsm> it's not really, just make the cb do nothing (and not loop) and show an error
19:06:32 <nielsm> maybe even add a new flag on the IndustryProductionSpriteGroup to indicate it's invalid
19:06:36 <Samu> need an answer to solve this dilema on my PR
19:06:55 <nielsm> like maybe a false 'version' number (255)
19:07:05 <peter1138> nielsm, so change the loading AGAIN :D
19:07:13 <peter1138> flag the error on load
19:07:15 <nielsm> if any of the cargos resolve to CT_INVALID during loading
19:07:18 <peter1138> and if it's used, ignore it.
19:08:06 *** yoltid[m] has joined #openttd
19:08:12 <nielsm> during loading: if (cargo == CT_INVALID) group->version == 255;
19:08:30 <nielsm> during execution: if (group->version == 255) { show_error(); return; }
19:08:54 <nielsm> one = too many in first line
19:11:30 *** yur3shmukcik[m] has joined #openttd
19:13:05 <peter1138> Hmm, I wonder, it may already have looped, and therefore produced cargo.
19:13:10 <Samu> this feels wrong, I can't reject an industry and count it as the same time
19:13:43 <nielsm> hmm yeah it could return different prod cbs on multiple loops
19:13:59 <peter1138> I think it doesn't matter.
19:14:19 <nielsm> you'd need something to capture a "backtrace" of the cb chain then
19:14:51 <peter1138> I'm happy to accept this as an edge case that the NewGRF author should have taken care of.
19:19:41 <peter1138> TrueBrain, that is exactly what I typed :/
19:22:47 <peter1138> nielsm, be interesting to see if I get the warning popup :-)
19:24:28 <Samu> a dock is receiving engineering supplies
19:24:47 <peter1138> it's probably not that one.
19:25:16 <peter1138> Yeah that was a cockup :/
19:25:53 <peter1138> andythenorth, I can't test this any further as there's no way to trigger production.
19:26:08 <nielsm> hmm? but the industries that produce engineering supplies don't have attached stations
19:26:12 <andythenorth> yeah I have quite a lot to do
19:26:18 <nielsm> so those _should_ arrive at player stations
19:26:36 <Samu> when hovering it, engineering supplies is not listed
19:26:45 <Samu> but once placed, engineering supplies become listed
19:26:52 <peter1138> Can you give me a savegame?
19:27:01 <andythenorth> if I stop playing Blitz every 10 mins, I can probably get 16-cargo FIRS working tonight
19:27:28 <nielsm> oh, you meant "accepts engineering supplies" not "receives them"
19:27:53 <peter1138> Hmm, is it just the text that's wrong?
19:28:22 <peter1138> Right, might not be producing.
19:28:58 <Samu> the dock should not accept Engineering supplies
19:29:10 <Samu> dock is also joined with a bus station
19:29:11 <peter1138> It may be that it doesn't and it's only the text there that's wrong.
19:29:26 <peter1138> But I'm speculating without that savegame.
19:30:13 <peter1138> At least this isn't anything that needs backporting :)
19:30:27 <Samu> ugh, need to test on master :)
19:31:42 <Samu> gonna try rebuilding the bus station
19:32:24 <peter1138> fluidsynth: warning: Failed to pin the sample data to RAM; swapping is possible.
19:32:38 <peter1138> I don't have music playing, but I guess it still initializes it.
19:32:39 <nielsm> it always gives me that warning
19:32:54 <nielsm> yeah it starts the music driver on boot
19:33:13 <nielsm> I'm not sure what to do to allow pinning, or even just silence the warning
19:34:18 <Samu> it seems to happen only because I loaded an old savegame?
19:34:27 <andythenorth> is Samu our QA expert now? :)
19:34:48 <peter1138> Samu, acceptance is saved.
19:34:51 <planetmaker> doing not the worst job one can do
19:34:59 <Samu> well, i'm gonna provide the old save then
19:35:18 <peter1138> Samu, if the game is unpaused, does the acceptance update?
19:35:25 <michi_cc> At least if you are in something Debian-based I guess.
19:35:48 <peter1138> Yeah, if it's memlock then you basically need to ignore the warning.
19:35:48 <Samu> i think not, gonna retry
19:36:07 <peter1138> There may be a flag to tell fluidsynth to not try.
19:38:22 *** supermop_Home_ has quit IRC
19:38:49 <Samu> i can't reproduce the bug, ... sorry, i have no idea why
19:39:20 <Samu> maybe my master is not up to date ye
19:41:10 <Samu> it's one of the last 23 commits
19:41:23 <peter1138> Don't bother trying to find out which one.
19:41:30 <peter1138> Just send me the save.
19:42:50 <Samu> forgot to disable setting
19:44:17 <Samu> there is no bug, just me doing my tests wrong
19:46:03 <Samu> yeah, game was paused first time I spotted it
19:47:16 <peter1138> Well, you might not expect that acceptance is not updated instantly.
19:47:19 <DorpsGek_II> [OpenTTD/OpenTTD] nielsmh opened pull request #7365: Fix: Fluidsynth should not try to lock sample data in memory https://git.io/fhhNw
19:47:22 <peter1138> And in fact, maybe it should be.
19:49:24 <glx> finally finished to rebase all my cmake branches
19:50:02 <peter1138> Hm, I wonder if acceptance needs to be updated after all the catchment is updated, or at the same time.
19:56:10 <DorpsGek_II> [OpenTTD/OpenTTD] LordAro commented on pull request #7363: Lot of small codefixes related to configure https://git.io/fhhNb
19:58:35 *** Thedarkb1-T60 has joined #openttd
19:59:06 <andythenorth> I look forward to rewriting FIRS in nml2 :D
20:01:31 <TrueBrain> LordAro: I kept the lower case, as I18N looks weird
20:01:34 <TrueBrain> but sure, what-ever you want :P
20:04:00 <andythenorth> produce block seems to be working btw
20:04:19 <andythenorth> FIRS code is not finished, I just made it produce 100 units per prod cb run
20:04:33 <andythenorth> amounts look kinda correct
20:08:04 <peter1138> Just prepared veg for my dinner.
20:08:10 <peter1138> Been here so long I hadn't noticed the time.
20:08:21 <DorpsGek_II> [OpenTTD/OpenTTD] TrueBrain updated pull request #7363: Lot of small codefixes related to configure https://git.io/fhhdG
20:08:30 <peter1138> Samu, I'm glad it wasn't a real bug, don't worry about it :)
20:09:02 <peter1138> Samu, with the (unpushed) catchment visualization patch it's trivial to see if it is correct.
20:09:38 <peter1138> With neutral stations, catchment for the station is only the industry, no surrounding tiles at all.
20:10:07 <DorpsGek_II> [OpenTTD/OpenTTD] TrueBrain commented on pull request #7363: Lot of small codefixes related to configure https://git.io/fhhAc
20:10:41 <nielsm> I think we need a "catchment"/"influence area" button graphic that can be used in both station windows and in town windows
20:10:48 <nielsm> to see catchment and town LA zones
20:11:47 <peter1138> I have it, keeping it to myself ;)
20:13:41 <DorpsGek_II> [OpenTTD/OpenTTD] SamuXarick commented on pull request #7184: Feature: Distribute cargo to multiple stations or industries https://git.io/fhhAl
20:15:35 <andythenorth> 52s to compile FIRS
20:16:14 <nielsm> yeah a newgrf linker would be nice :)
20:17:17 <andythenorth> how many times can I write to a register in one switch?
20:17:23 <andythenorth> no idea what nml does with that internally
20:17:30 <nielsm> one that consumes multiple objects and combine to one object, adjusting sprite numbers and references
20:18:05 <nielsm> and another that takes an object and some string data and produces strings sprites and fixes up string ids in the object
20:18:21 <andythenorth> the value is 100 in all cases
20:18:50 <andythenorth> I wonder if registers are updated immediate, or if there's some flushing?
20:19:01 <nielsm> hmm that ought to produce a chain of multiple varaction2 afaik?
20:19:08 <andythenorth> that's what I assumed
20:19:25 <andythenorth> am I just being thick? Is the syntax correct?
20:20:25 <nielsm> the last step is STORE_PERM(100, 10)
20:20:33 <nielsm> which overwrites anything previously stored in perm 10
20:20:47 <DorpsGek_II> [OpenTTD/OpenTTD] JGRennison updated pull request #7081: Change: [Linkgraph] Pause the game when linkgraph jobs lag (#6470) https://git.io/fh2Pg
20:21:10 <andythenorth> because nfo works upwards, I sometimes forget that nml is sensible :P
20:21:24 <andythenorth> I taught my brain to do logic backwards for action 2 chains
20:22:16 <andythenorth> I am reading that switch and expanding it to advanced varact 2 :P
20:22:19 <andythenorth> but nml does that for me
20:23:36 <peter1138> nielsm, comment on the PR :p
20:24:01 <DorpsGek_II> [OpenTTD/OpenTTD] nielsmh commented on pull request #7081: Change: [Linkgraph] Pause the game when linkgraph jobs lag (#6470) https://git.io/fhhAz
20:24:10 <peter1138> Okay, do I need to protect this error message to stop it being spammy?
20:24:50 <nielsm> nah, annoy anyone using a buggy grf
20:25:15 <peter1138> I kinda need a buggy test GRF to test it ;)
20:28:12 <DorpsGek_II> [OpenTTD/OpenTTD] PeterN updated pull request #7364: Fix e66cec8f86: Permit loading of industry production callback with invalid cargo type. https://git.io/fhhbB
20:29:26 <DorpsGek_II> [OpenTTD/OpenTTD] PeterN commented on pull request #7365: Fix: Fluidsynth should not try to lock sample data in memory https://git.io/fhhAo
20:29:29 <DorpsGek_II> [OpenTTD/OpenTTD] JGRennison updated pull request #7081: Change: [Linkgraph] Pause the game when linkgraph jobs lag (#6470) https://git.io/fh2Pg
20:31:08 <DorpsGek_II> [OpenTTD/OpenTTD] nielsmh commented on pull request #7364: Fix e66cec8f86: Permit loading of industry production callback with invalid cargo type. https://git.io/fhhAi
20:31:12 <DorpsGek_II> [OpenTTD/OpenTTD] JGRennison commented on pull request #7081: Change: [Linkgraph] Pause the game when linkgraph jobs lag (#6470) https://git.io/fhhAP
20:31:25 <peter1138> checking fluidsynth... not found
20:31:30 <peter1138> Yeah, maybe we need to fix that.
20:31:35 <peter1138> CI does not check fluidsynth.
20:31:53 <peter1138> Hmm, I wonder if the release build includes it.
20:32:29 *** supermop_Home_ has joined #openttd
20:32:46 <supermop_Home_> no pipes on flat cars andy
20:33:17 <andythenorth> supermop_Home_: needs cargo drawn
20:33:22 <peter1138> Indeed, no fluidsynth in releases./
20:33:25 <andythenorth> want to contributify supermop_Home_ ?
20:34:33 <andythenorth> then they're automatically applied in Horse, Hog, Sam
20:34:44 <nielsm> I think libfluidsynth will only work well if it has a system-wide (or maybe user-wide) configuration file specifying a sample bank
20:35:27 <supermop_Home_> andythenorth can take the pipes i drew for my nrt RVs
20:36:05 <andythenorth> there's some in CHIPS as well
20:37:50 *** Maarten has joined #openttd
20:43:01 <peter1138> nielsm, just means it passes CI even if the code is wrong ;)
20:49:43 <LordAro> TrueBrain: it's like xkcd - "xkcd" is preferred, but where necessary "XKCD" is better than "Xkcd"
20:50:08 <TrueBrain> LordAro: it is nothing like that, but I like your thinking :D
20:50:38 <TrueBrain> (xkcd is not a combination of 2 words :P)
20:56:06 <andythenorth> oof integer maths strikes again
20:56:08 <andythenorth> really andythenorth
20:56:56 <andythenorth> so many parentheses here :P
20:58:29 *** gelignite has joined #openttd
21:01:13 <andythenorth> nielsm: ultimately this new produce cb is so much a better format
21:01:23 <andythenorth> the final FIRS code is no shorter, but much cleaner
21:03:07 <Eddi|zuHause> <andythenorth> this was multiple in same grf <-- NFO allows that, but NML doesn't.
21:03:47 <Eddi|zuHause> but nowadays there's no need for that
21:04:36 <andythenorth> so am I going to preserve leftover cargo then?
21:04:42 <Eddi|zuHause> as the refit lists now properly handle higher numbers of CTT entries
21:04:53 * andythenorth changes the subject abruptly :)
21:05:03 <Eddi|zuHause> andythenorth: i see no reason not to.
21:05:18 <andythenorth> me neither, apart from working out the calculation
21:05:23 <andythenorth> I'll finish this soon and pushi
21:05:57 <Eddi|zuHause> why "work out the calculation"? you have a reason to change it from the existing one?
21:06:59 <andythenorth> I've adjusted how the production is calculated
21:07:04 <andythenorth> should be same final result
21:08:11 <andythenorth> nml ternary, second value is if true, third is false?
21:08:16 <andythenorth> first is condition?
21:08:46 <Eddi|zuHause> andythenorth: i haven't confirmed that that's what your calculation does, but it should work roughly like this: you have a calculation o=a/b, which is subject to rounding error. so you save the remainder as it to o'=a%b. then in the next round you can incorporate the remainder again, so it becomes o=(a+o')/b, and o'=(a+o')%b
21:09:01 <andythenorth> yes that's roughly what it does
21:13:22 <Alberth> cond ? true-value : false-value indeed
21:13:36 <peter1138> Mmm, medium-rare lamb fillet steak..
21:14:15 <peter1138> Somewhat a different beast from the lamb chops cooked to a desert-like dryness that mum used to cook...
21:15:25 <andythenorth> lamb is not like lamb when I was a kid
21:17:07 <peter1138> 1 hour to prepare. 5 minutes to eat.
21:17:24 <peter1138> Well, the lamb was only 10 minutes.
21:17:35 <peter1138> Not a long slow roast for that.
21:17:51 <peter1138> nielsm, are you fixing #7365?
21:19:23 <andythenorth> newgrf debug window displays register values
21:19:28 <andythenorth> option to set them? o_O
21:21:52 <andythenorth> imagine the cheating possibilities :)
21:22:16 <DorpsGek_II> [OpenTTD/OpenTTD] nielsmh updated pull request #7365: Fix: Fluidsynth should not try to lock sample data in memory https://git.io/fhhNw
21:29:07 <andythenorth> oof my code fails
21:29:15 <andythenorth> so close, so far
21:37:11 <peter1138> nielsm, made zero difference :(
21:38:30 <peter1138> Tried moving it before new_fluid_synth() and still no dice.
21:42:01 <TrueBrain> wait, you are talking with more people besides us?! :(
21:49:18 <peter1138> fluidsynth code could do with some comments :p
21:55:25 <andythenorth> oof does anyone know if FIRS secondary closure code works?
21:55:34 <andythenorth> I never use it, so eh
21:56:17 <nielsm> it sounds unfun from the description so I never enabled it
21:58:08 <peter1138> Oh forget it, the test is confusing with negatives all over the plac :/
21:59:43 *** planetmaker is now known as Guest2960
21:59:59 <peter1138> nielsm, I'm getting a FLUID_FAILED return value.
22:00:29 <peter1138> All thoses ghosts...
22:00:52 *** planetmaker has joined #openttd
22:00:52 *** ChanServ sets mode: +o planetmaker
22:01:10 <nielsm> peter1138 any idea if it's parameter not found, or something else?
22:01:19 <peter1138> Difficult to see :(
22:06:37 *** ^Spike^ has joined #openttd
22:06:51 *** Webster has joined #openttd
22:07:20 *** XeryusTC has joined #openttd
22:07:22 *** V453000 has joined #openttd
22:07:22 *** Terkhen has joined #openttd
22:07:22 *** ChanServ sets mode: +o Terkhen
22:08:12 *** planetma- has joined #openttd
22:08:42 *** Hazzard has joined #openttd
22:09:22 *** Hirundo has joined #openttd
22:09:22 *** fonsinchen has joined #openttd
22:12:35 *** planetmaker is now known as Guest2961
22:12:35 *** planetma- is now known as planetmaker
22:13:53 *** Supercheese has joined #openttd
22:14:59 *** octernion has joined #openttd
22:21:47 *** tops[m] has joined #openttd
22:27:46 <peter1138> THe code uses WITH_SSE.
22:27:49 <DorpsGek_II> [OpenTTD/OpenTTD] michicc requested changes for pull request #7081: Change: [Linkgraph] Pause the game when linkgraph jobs lag (#6470) https://git.io/fhhh5
22:30:43 <Eddi|zuHause> andythenorth: if you actually coded in a readable language...
22:30:55 <peter1138> Eddi|zuHause, like NML?
22:31:04 <andythenorth> what, an xhtml templating language is inappropriate for templating nml? :P
22:31:20 <michi_cc> nielsm: Where you or TB doing a DOS build?
22:31:29 <andythenorth> strictly I think the old code was flawed, as it paid no attention to min_cargo_distr afaict
22:31:34 <andythenorth> but I might make min_cargo_distr 1
22:31:37 <TrueBrain> michi_cc: I am :) Tomorrow I hope to make it in a docker :P
22:31:41 <andythenorth> NFI what min_cargo_distr does :P
22:31:57 <glx> peter1138: hmm in cmake branch USE_SSE defines WITH_SSE IIRC
22:32:11 <michi_cc> Does the used compiler come with proper C++11 <thread> and <mutex> headers?
22:32:38 <glx> well SSE_FOUND defines WITH_SSE
22:32:43 <michi_cc> Or put it differently, is a WITHOUT_THREADS options still needed even with a C++11 compiler?
22:32:46 <TrueBrain> michi_cc: docker run --rm -it -u0:0 -v"`pwd`":/source anibali/djgpp
22:33:08 <peter1138> Are threads a thing on DOS?
22:33:47 <michi_cc> C++11 requires a thread type, but I don't know if it requires it to do anything
22:33:55 <peter1138> Ah yes, makes sense.
22:34:02 <andythenorth> I'm sure I only added leftover cargo because I made some stupid tiny vehicles in HEQS
22:34:16 <andythenorth> and nothing got produced
22:37:21 <DorpsGek_II> [OpenTTD/OpenTTD] nikolas commented on pull request #7086: Change #6173: Update SDL driver to use SDL 2.0 https://git.io/fhhjJ
22:37:25 <Eddi|zuHause> andythenorth: if you want to store the remainder per input (or output) cargo type, then the template must know which position in the produce callback it is in
22:37:41 *** fiddeldibu[m] has joined #openttd
22:39:12 <andythenorth> L50 or so Eddi|zuHause
22:39:57 <andythenorth> in fact L10 is irrelevant, we can just clear all the cargo from stockpile and keep in register
22:40:31 <andythenorth> but around L50, need to calulate the remainder cargo and put that in a perm register
22:41:05 <andythenorth> I can do the template; it's the calculation of remainder I don't understand
22:43:29 <andythenorth> I'm unclear of the problem definition tbh
22:45:25 *** Webster has joined #openttd
22:47:40 *** Wormnest has joined #openttd
23:12:07 *** Thedarkb-T60 has joined #openttd
23:13:36 <peter1138> Hmm, WATERCLASS_DOCK?
23:16:41 <andythenorth> hmm all my industries are closing :(
23:17:12 <andythenorth> but then again, I disabled the closure control :P
23:17:24 <peter1138> Well, multiple docks, but...
23:17:36 <andythenorth> multiple Airports?
23:17:58 <peter1138> It's inefficient, because it checks for a dock... every tile...
23:18:00 <andythenorth> wow, default industry closure behaviour is horrid
23:18:20 <andythenorth> after 5 years my map starts getting emptied
23:18:45 <peter1138> Yeah, you've made it too easy?
23:18:47 <andythenorth> oh but new industries get built :o
23:19:00 <peter1138> That's a thing, yes.
23:19:06 <andythenorth> yeah I wish I could just tweak the default closure
23:19:11 <michi_cc> Bad DJGPP, pretends to support C++11, ships with a <thread> header, but doesn't even define std::thread.
23:19:15 <andythenorth> instead of having to prevent it, with nothing to over-ride
23:19:37 <andythenorth> maybe I can rethink closure
23:20:17 <michi_cc> So, either no DOS, useless thread_*.cpp files or #ifdefs in various places.
23:20:24 <andythenorth> why should an industry close? o_O
23:20:55 <peter1138> Not being supplied.
23:21:05 <peter1138> Burned down in a fire.
23:21:16 <peter1138> Boycotted by right-wing anti-SJW thugs.
23:22:27 <andythenorth> what if it was just unlucky?
23:22:42 <andythenorth> 'sorry this industry just closed'
23:23:06 <LordAro> and, for balance, Boycotted by left-wing SJW thugs
23:23:27 <LordAro> oh no, i said the 'b' word
23:23:41 <andythenorth> maybe I just make the old FIRS behaviour come back
23:23:51 <andythenorth> and do something better in v9000
23:24:09 <peter1138> Oh, I can't add a waterclass :(
23:24:21 <peter1138> It's only 2 bits and all 4 values are used.
23:26:13 <peter1138> Or scrap this idea...
23:27:16 *** Wormnest has joined #openttd
23:28:00 <Eddi|zuHause> what's the new water class for?
23:28:29 <Eddi|zuHause> iirc there's usually bit 7 available...
23:28:59 <peter1138> I think I don't want a water class, tbh.
23:29:06 <peter1138> I might just want to use bit 7 by itself.
23:29:26 <peter1138> I need a way to mark tiles as being a docking tile.
23:29:48 <peter1138> Alternatively, I could try making a specific station tile for it.
23:30:18 *** snail_UES_ has joined #openttd
23:30:20 <Samu> i had a pr that got closed about that
23:30:23 <andythenorth> and can I set it to 1, not 5
23:32:14 <peter1138> andythenorth, not legacy. It is literally what it says it is.
23:32:22 <Samu> let me search from my list of closed prs
23:32:46 <peter1138> That will take a while, there's a lot of them.
23:33:10 <Samu> got 49 closed pr's dayum
23:33:17 <andythenorth> trying to envisage a reason for distributing 5 units instead of 1 :P
23:33:25 <andythenorth> FIRS is set to 5 currently
23:34:52 <peter1138> fruit/rubber plantations default to 15
23:35:05 <peter1138> cotton candy factory is 30
23:35:49 <peter1138> Samu, that looks wholly not like what I'm doing.
23:36:17 <andythenorth> wonder if that's supposed to simulate slow production cycle
23:36:23 <andythenorth> when prod. multiplier is low
23:36:45 <andythenorth> anyway, I set it to 1, see if it kills kittens
23:37:58 <nielsm> as I understand, the amount of cargo returned in each individual prod cb during one loop doesn't really matter, only the sum across the entire loop
23:38:17 <nielsm> so if you can return all the cargo in fewer loop steps, you have better performance
23:38:33 <Samu> The produced cargo will be distributed to stations only after it exceeds this amount.
23:38:59 *** Thedarkb-T60 has joined #openttd
23:39:36 <Samu> lets say you deliver 2 wood to a sawmill
23:39:53 <Samu> it won't produce 2 goods right away, only when it gets 5 wood
23:41:15 <Samu> if you deliver 2 wood, then later on, 3 wood , it will then transform the wood into 5 goods
23:42:13 <andythenorth> and when it's primary?
23:42:58 <Samu> if it produces really low values, i guess it will wait for the next production cycle
23:43:51 <Samu> it will "stockpile" until it meets a min of 5
23:44:02 <TrueBrain> michi_cc: so we are dropping DOS you say? :P Saves me from creating a docker :)
23:44:59 <TrueBrain> if we drop DOS btw, we can also drop ENABLE_NETWORK stuff :P
23:45:26 <TrueBrain> lot of exceptions for a single target .. but meh
23:45:52 <michi_cc> Depends... stubbing in a dummy std::thread isn't that hard if we really wanted to.
23:47:31 <nielsm> I think i've seen some #ifdef guards for threads...
23:47:47 <michi_cc> But before that can happen, OTTD needs quite some cleanup. We do stuff like acquiring a mutex on the main thread and releasing it on another thread, which, surprise, surprise, makes nice STL asserts.
23:48:11 <TrueBrain> I smell a new project :)
23:49:30 <michi_cc> nielsm: Ideally all our custom thread_* something files could vanish, but if a platform doesn't even define the classes, we'd still need #ifdef's or a custom wrapper class.
23:50:09 <DorpsGek_II> [OpenTTD/OpenTTD] PeterN approved pull request #7363: Lot of small codefixes related to configure https://git.io/fhjeT
23:50:23 <peter1138> ^ I mean, it worked for me :p
23:50:39 * LordAro looks at irc, sees DorpsGek_II message
23:50:52 * LordAro 's phone buzzes, "ooh, an email"
23:51:01 <LordAro> it is of course, the same message
23:51:03 <peter1138> Don't worry, we've not merged NRT yet.
23:52:47 <andythenorth> 'ooh an email' I think never
23:52:53 <andythenorth> I dread the damn things
23:53:08 *** Thedarkb1-T60 has joined #openttd
23:54:31 <LordAro> oh sure, it was perhaps more of a "what's my phone buzzing about"
23:54:41 <peter1138> So if I wanted, instead, to make docking tiles be actual station tiles, I'd have to take account of slopes and... things in the way :/
23:55:31 <peter1138> Samu's so called 3rd tile, which may current be something other than plain water.
23:56:19 <peter1138> It's simple to add a 3rd tile that is actually a station tile.
23:56:37 <peter1138> But not so simple to convert old savegames.
23:57:52 <peter1138> I could cheat and use a bit that's free in every tile type
23:59:32 <Samu> "this savegame cannot be converted. load aborted"
continue to next day ⏵
