IRC logs for #openttd on OFTC at 2017-06-24
⏴ go to previous day
00:06:19 *** tokai|noir has joined #openttd
00:06:19 *** ChanServ sets mode: +v tokai|noir
00:14:58 *** Speedy` has joined #openttd
00:15:14 *** Speedy` is now known as Speedy
02:51:33 *** HerzogDeXtEr1 has joined #openttd
06:30:25 *** cosmobird has joined #openttd
07:07:11 *** JacobD88 has joined #openttd
08:09:32 *** sla_ro|master has joined #openttd
08:41:50 *** chomwitt has joined #openttd
09:22:20 *** Biolunar has joined #openttd
09:49:33 *** sim-al2 is now known as Guest3210
09:49:34 *** sim-al2 has joined #openttd
11:07:35 *** sim-al2 is now known as Guest3221
11:07:36 *** sim-al2 has joined #openttd
11:15:14 *** Progman has joined #openttd
11:19:40 *** synchris has joined #openttd
11:57:04 *** Wormnest has joined #openttd
11:58:26 *** andythenorth has joined #openttd
12:26:12 *** Alberth has joined #openttd
12:26:12 *** ChanServ sets mode: +o Alberth
12:28:56 *** FLHerne has joined #openttd
12:34:30 <andythenorth> this readme is daft
12:34:36 <andythenorth> what should I do about it?
12:34:50 <andythenorth> FIRS has two disconnected sets of docs
12:35:47 <Wolf01> I think you are overdoing it
12:35:59 <andythenorth> the readme is by other people
12:36:07 <andythenorth> I don’t like to just delete their work
12:37:14 <andythenorth> move the readme contents into the ‘get started’ page?
12:37:18 <andythenorth> or just delete most of it?
12:37:22 *** gelignite has joined #openttd
12:40:31 <Wolf01> The vehicle set support section is nice but I don't think it really belongs to the readme, maybe that one could be moved to the online docs and you can just keave there the first 3 sentences
12:40:49 <andythenorth> I think the list of sets is misleading
12:40:53 <andythenorth> it’s always out of date
12:41:12 <Wolf01> That too, it requires maintenance
12:43:30 <Wolf01> "you need a vehicle set that supports the FIRS cargos. Any vehicle set with proper Cargo Classes support should do that by default. The OpenTTD vehicles will not be able to transport all FIRS cargos." should be sufficient, let players figure out what they need... maybe a topic in the forum and some curators is a better idea
12:44:34 <Alberth> I'd support the idea of merging them
12:45:23 <andythenorth> I think it’s the right choice
12:45:35 <andythenorth> also…a smarter bananas could statically analyse vehicles
12:45:44 <andythenorth> to determine which industry sets are supported :P
12:46:08 <Alberth> I like the vehicle list tbh, you could keep it, and start with a generic sentence like Wolf suggests, making the list more of an set of examples
12:46:47 <Alberth> the generic rule "none are compatible" is simpler
12:47:13 <Alberth> you could list the counter-examples, which is close to the empty set :)
12:47:41 <Alberth> and bananas doesn't activate multiple grfs in ones game :p
12:48:41 <Alberth> I do miss a few words about economies though, which exist, perhaps what they aim for, or recommendations how to start playing firs, or even how to play an economy
12:49:15 <andythenorth> in the readme, or can I do that in the docs?
12:49:30 <Alberth> I'd merge everything into the html version
12:49:33 <andythenorth> ‘get started’ doesn’t mention them properly
12:49:47 <Alberth> especially since you distribute that :)
12:49:49 <andythenorth> I will rebuild the docs
12:50:13 <andythenorth> I don’t distribute the docs any more, bananas refuses them :P
12:50:20 <andythenorth> but they’re on bundles so eh
12:50:41 <andythenorth> I guess mostly people have a connection these days
12:51:19 <andythenorth> vehicle compatibiltiy should be a wiki page
12:51:23 <andythenorth> with someone like Kamnet
12:51:24 <Alberth> the readme is either minimal, pointing to docs, or full, as in, generated from html, or from the same source as html
12:54:00 <Alberth> could be duplicate-ish though
12:57:22 <Alberth> you get a face when you open a company window for changing the savegame pre-fix, but that's the only time I ever see a face :)
12:59:28 <Wolf01> Yeah, it should also automatically load your preset instead of manually clicking on the button :|
12:59:50 <Wolf01> That always pissed me off
13:01:52 <andythenorth> do I need the conflict Error Codes from the readme?
13:02:51 <Wolf01> The online docs should have everything, leaving them in the readme might help for a fast reference
13:03:43 <andythenorth> I wonder if they’re of any use at all?
13:03:56 <andythenorth> they can go on the code reference page I guess
13:04:50 <Wolf01> Or you might explain better the error in the game and completely remove them from the readme
13:06:43 <Alberth> code has a text explaining it afaik
13:07:31 <Alberth> you could move it to a harmless place like some comment in the code if it's not there already
13:07:52 <Alberth> unless it has external use, but I'd say it's limited at best
13:08:17 *** frosch123 has joined #openttd
13:08:45 <Alberth> we just split the channel to make room for new users :p
13:09:00 *** andythenorth has joined #openttd
13:09:00 *** tycoondemon has joined #openttd
13:09:00 *** ToBeFree has joined #openttd
13:09:00 *** ^Spike^ has joined #openttd
13:09:00 *** Hirundo has joined #openttd
13:09:00 *** peter1138 has joined #openttd
13:09:00 *** Webster has joined #openttd
13:09:00 *** ericnoan has joined #openttd
13:09:00 *** LongyanG has joined #openttd
13:09:25 <andythenorth> E00, E01, E02, and E04 have lang strings
13:09:33 <Alberth> (13:07:51) Alberth: unless it has external use, but I'd say it's limited at best
13:09:51 <andythenorth> E03 and W01 do not have lang strings, not sure if / where they are used
13:10:01 <andythenorth> I can’t imagine anyone looking these up in the docs
13:10:51 <Alberth> it's useless technical babble :p
13:11:09 *** ChanServ sets mode: +o orudge
13:11:10 *** ChanServ sets mode: +o peter1138
13:12:43 <andythenorth> but the world tends to commodity
13:12:53 <andythenorth> someone else has solved docs better than I ever will
13:13:01 <andythenorth> no slideshow though
13:13:11 <Alberth> no buttons to select things
13:13:30 <Alberth> no resizable flow charts
13:13:50 <Alberth> keep own docs sounds like a good thing :)
13:18:09 <andythenorth> ha the repo version is really very wrong
13:18:33 * andythenorth wonders why that is
13:20:07 <andythenorth> autocomplete eh?
13:24:11 <andythenorth> Alberth: bin/hg-info - what’s the difference between REPO_REVISION and REPO_VERSION?
13:24:18 <andythenorth> I am reading it, but can’t follow :)
13:26:43 <frosch123> 5653 is today when using the days since 2000-01-01 version theme
13:26:59 <frosch123> oh, wait ,it isn'T, it's today, but two years ago?
13:28:41 <Alberth> --num-id --version <-- first is revision (ie a number), second is version description (like firs0.3)
13:29:17 <Alberth> firs doesn't use date, except through devzone afaik
13:30:04 <frosch123> so, just coincidence?
13:30:13 <Alberth> although "version" may include a revision number too
13:31:09 <Alberth> not sure what happened with the number system; I have older firses with higher numbers, so something changed somewhen algo
13:31:57 <andythenorth> devzone hg has totally different revisions
13:32:22 <Alberth> how can that be, you have a clone of that, right?
13:32:30 <andythenorth> my local build of 5707 gives me 5707 in the readme
13:32:54 * andythenorth checks it’s not keyboard-chair error
13:35:18 <andythenorth> hash is cd08980bdc8722089dcff849bdb5328d0e32ab94
13:35:39 * andythenorth totally confused
13:35:46 <andythenorth> devzone hash is cd08980bdc87
13:36:14 <Alberth> hg log -r 5b5cd4d3e9bc8a9e5866f97870c748388a5cb398
13:36:14 <Alberth> changeset: 5706:5b5cd4d3e9bc
13:37:04 <andythenorth> cd08980bdc8722089dcff849bdb5328d0e32ab94 is 5707
13:37:11 <andythenorth> and jenkins tries to build cd08980bdc8722089dcff849bdb5328d0e32ab94
13:37:24 <andythenorth> the content of the repor is correct
13:37:34 <andythenorth> but the revision number is mangled
13:37:48 <andythenorth> is the revision number not bound to the hash?
13:38:12 <Alberth> it's an incremental number local to a repo
13:38:17 <andythenorth> ok so maybe bundles has a special repo
13:38:40 <Alberth> different repos have different incremental numbers, unless you explicitly keep them in sync
13:38:56 <Alberth> which is what you expect to happen if you pull
13:38:57 <Eddi|zuHause> revision numbers can mismatch if you have branches that were not pushed
13:39:13 <andythenorth> that means using the revision numbers anywhere is a daft strategy
13:39:21 <andythenorth> should be using hashes
13:39:31 * andythenorth is unsure how to fix this
13:40:00 <Eddi|zuHause> hashes are not incremental
13:40:27 <andythenorth> but there is no valid incremental revision number
13:40:29 <Alberth> this is what the dates since 2K are about, days are incremental
13:40:45 <andythenorth> but they tend to not be unique
13:40:51 <andythenorth> multiple revisions on same day
13:41:19 <Alberth> wasn't a revision or so added as well?
13:41:45 <Alberth> we did something with BB too in that direction, not sure what exactly
13:41:46 <andythenorth> my objection was that they conflate with the hg revisions, at least for me
13:42:04 <andythenorth> coincidentally FIRS got revisions very close to days since 2K
13:42:10 <andythenorth> which was totally confusing
13:42:54 <Eddi|zuHause> well, you could try hours since 2010 :p
13:43:09 <andythenorth> should I manually set the revision on every commit?
13:43:29 <Alberth> that'd be stupid, imho
13:43:30 <andythenorth> could just update a Makefile property every time I commit
13:43:48 <Eddi|zuHause> that sounds very stupid
13:44:25 <andythenorth> there are any non-stupid ideas? :)
13:44:37 <andythenorth> in projects using git, we just publish the hash
13:44:43 * andythenorth has run across this before
13:44:43 <Eddi|zuHause> well, you could make a commit hook, but you'd still have all the nonsense clutter in the repo
13:44:58 <Eddi|zuHause> and it'll clash when someone else pushes to the repo
13:45:14 <Alberth> hash if you don't care about incremental versioning, or date-ish
13:45:34 <andythenorth> I think it’s better to not care
13:45:44 <Alberth> with or without hash to make it unique
13:46:07 <Alberth> and you can go down to minutes or so, which is likely unique enough
13:46:15 <Alberth> seconds if you're paranoid
13:46:39 <Eddi|zuHause> you run out of bits quickly, then
13:46:54 <Alberth> who said anything about bits?
13:47:32 <Alberth> using GMT is better :p
13:47:38 <Eddi|zuHause> that is fine for a string, but i thought we were talking about newgrf versioning
13:47:49 <Eddi|zuHause> which is something like 16bit?
13:49:03 <Alberth> hmm, you'd need to do that manually, I think
13:51:08 <Alberth> you don't want a new version every second, so some tool to store and query the newest version?
13:52:16 <Eddi|zuHause> you don't want to tag every revision
13:52:38 <Eddi|zuHause> also, in hg, tags are also revisions
13:54:09 <andythenorth> remarkably hard problem eh :)
13:54:13 <andythenorth> seems simple isn’t
13:54:20 <andythenorth> dvcs with mutable history
13:54:27 <andythenorth> numeric revisions can’t be trusted
13:55:31 <Eddi|zuHause> i still think numeric revisions are fine, as long as the published versions all come from the same repo
13:55:43 <Eddi|zuHause> you just can't compare your local revisions with the public ones
13:56:51 <andythenorth> so it’s a configuration problem, rather than a computational problem?
13:57:23 <andythenorth> we did clock synchronisation in my philosophy degree :P
13:57:26 <andythenorth> as a non-solvable
13:58:18 <andythenorth> so I need to delete some revisions, so I get to same number as bundles?
13:58:35 <andythenorth> @calc 5707 - 5653
14:00:19 <andythenorth> do ‘hg strip’ on commits 0-53?
14:02:15 <Eddi|zuHause> easier to just delete your local repo and re-clone
14:02:53 <andythenorth> but that wouldn’t work
14:03:06 <andythenorth> I have same revisions as remote
14:03:12 <andythenorth> bundles has some special provision
14:04:03 <andythenorth> and bundles isn’t afaik maintained
14:05:24 <Alberth> bundles must be missing something
14:05:35 <frosch123> date is fine for nightlies
14:06:10 <Eddi|zuHause> but not for hotfix-releases
14:06:31 <frosch123> yeah, not for andy :p
14:06:34 <Alberth> or for referring to a revision
14:07:35 <andythenorth> I think Eddi is right, it’s just a configuration problem
14:07:52 <andythenorth> there is no rationale for bundles being out of sync with devzone
14:08:05 <andythenorth> but I deliberately don’t have ssh access to either
14:08:29 <andythenorth> and afaik, nobody maintains bundles now, since pm + Amml*r went away
14:12:35 <frosch123> oh, bundles and devzone are out of sync?
14:12:46 <frosch123> i guess that's then because of only cloning the default branch?
14:14:33 <Eddi|zuHause> that is pretty much what i said, it's missing some branches
14:15:39 <frosch123> i assumed it was just andy and devzone being out of sync
14:15:54 *** gelignite_ has joined #openttd
14:16:00 <Eddi|zuHause> yeah, he wasn't very clear about that
14:36:08 <andythenorth> I conflated devzone and bundles
14:36:13 *** gelignite has joined #openttd
14:38:00 <Eddi|zuHause> i suppose it's difficult to switch hg to count ancestors instead of commits?
14:39:33 <Eddi|zuHause> that would solve the incrementality, but potentially cause larger jumps if you merge branches. and parallel branches may have the same number
14:40:14 <frosch123> andythenorth: i create a new checkout on bundles
14:40:20 <frosch123> they are in sync now
14:40:28 <frosch123> something with the 0.3 branch
14:40:34 <frosch123> which isn't even a head anymore
14:41:00 <planetmaker> Eddi|zuHause, ancestors can be counted
14:41:08 <planetmaker> hello everyone :)
14:41:36 <planetmaker> (at least if my memory serves me well, then they can)
14:43:22 <Eddi|zuHause> planetmaker: care to dig that up?
14:43:29 <planetmaker> looking right now
14:46:43 <frosch123> hg log -f --template '{rev}\n' | wc :p
15:09:56 *** andythenorth has left #openttd
15:10:09 <planetmaker> hg log -r0::tip -T"{rev}: {latesttag}-r{changessincelatesttag}\n" is not exactly that
15:10:51 <planetmaker> I think the number of commits in a branch (consecutive commits sind r0) is not easily available. Indeed you'll need wc -l
15:11:18 <planetmaker> what's the actual problem you try to solve, Eddi|zuHause ?
15:11:48 *** TrueBrain-Bot has joined #openttd
15:12:10 <planetmaker> devzone actually mostly builds tip on default branch... with other branches... it probably can get confused
15:12:11 <Eddi|zuHause> planetmaker: andy needs a revision count that is consistent across different repos, and "number of days since 2000" doesn't work
15:12:38 <planetmaker> {latesttag}-r{changessincelatesttag} should be consistent
15:13:05 <planetmaker> maybe not r, but {latesttag}-build{changessincelatesttag}
15:15:21 <planetmaker> but... what means "accross different repos"? "days since 2000" is consistent, not?
15:17:26 <planetmaker> why isn't it consistent?
15:27:11 <frosch123> planetmaker: it's consistent, but andy tends to push more than once per day :p
15:27:27 <frosch123> currently firs uses local revision, which is not consistent
16:26:13 <Eddi|zuHause> planetmaker: "days since 2000" is monotonous, but not strictly monotonous, so when you have build on push, and push twice, you get two different builds with the same number
16:26:42 <Eddi|zuHause> planetmaker: and local revision is not good, because you get the same build with two different numbers
16:27:20 <Eddi|zuHause> planetmaker: but the tree structure is always the same, even if you remove some branches. so number of ancestors is better than either of these other variants
16:27:52 *** Alberth has joined #openttd
16:27:52 *** ChanServ sets mode: +o Alberth
16:29:29 <Eddi|zuHause> so #ancestors+branch name should be unique enough to cause the least amount of confusion
16:34:54 <Alberth> is that something you can easily convert to a commit hash?
16:35:06 <Alberth> would work in git, I think, but in hg?
16:35:52 <Eddi|zuHause> the commit already has a hash
16:35:57 <Eddi|zuHause> that's not the problem
16:37:21 <Eddi|zuHause> the branch name would be only in the filename/grf name/grf description, but you need the incremental numerical value to decide which one is newer
16:38:28 <Eddi|zuHause> that information is used by openttd to show only the "newest" grf for selection, and to decide whether two builds are "compatible"
16:42:55 <Alberth> ah, right, you never use the number to get a commit. Smart idea
16:45:06 <LordAro> revision counts are basically dead these days
16:45:30 <LordAro> most software i've come across just uses latest.release.number.shorthash
16:46:40 <Eddi|zuHause> LordAro: that still requires some central authority to issue the "release.number"
16:47:20 <Eddi|zuHause> LordAro: but we need something automatic
16:47:49 <LordAro> but things generally have stable releases, just use the last one of those?
16:48:16 <LordAro> it's not monotonic though, of course
16:48:24 <Eddi|zuHause> we're still talking about andy here... "stable" doesn't quite fit :p
16:49:14 <Eddi|zuHause> LordAro: we want something that handles two (or more) consecutive test builds
16:49:49 <Eddi|zuHause> it doesn't matter whether the last release was called 1.2 or 5.23
16:51:18 <supermop_home> do I need the developer setting on to get the sprite offset thing?
16:51:22 <LordAro> what's wrong with just taking the latest (timewise) commit?
16:52:01 <LordAro> no need for counting revisions
17:23:50 <Eddi|zuHause> LordAro: what do you mean?
17:24:18 <Eddi|zuHause> LordAro: the same commit may have different numbers on different checkouts, that is the problem
17:25:57 <planetmaker> Eddi|zuHause, so yes... hg log -r. -T"{latesttag}-b{changessincelatesttag}\n" probably would give you a unique enough version
17:26:22 <planetmaker> and even tell you what possibly know version it might resemble most closely
17:40:37 <LordAro> Eddi|zuHause: different numbers, sure, but the hash would be the same
17:40:54 <LordAro> rather, why do you need a monotonic counter from the repo?
17:41:01 <Eddi|zuHause> LordAro: but the hash is useless, because you cannot sort by hash
17:41:09 <LordAro> why do you need to sort?
17:41:33 <LordAro> Alberth: gist related poke :]
17:41:43 <Eddi|zuHause> LordAro: to see at a glance which one is newer
17:41:59 <LordAro> commits have timestamps attached to them
17:42:12 <Eddi|zuHause> timestamps don't fit in 16 bits
17:42:53 <LordAro> i thought this was CI related?
17:43:00 <Eddi|zuHause> because 10 years ago someone thought 16 bit ought to be enough for everyone?
17:43:45 <LordAro> continuous integration
17:43:49 <LordAro> but i mean build related
17:44:09 <Eddi|zuHause> this is about OpenTTD's handling of newgrf versions
17:44:16 *** sla_ro|master has joined #openttd
17:44:55 <Eddi|zuHause> action 14 has a 16-bit version number, and openttd uses this to only display the "newest" version, and whether two versions are "compatible"
17:45:47 <Eddi|zuHause> historically, the common NewGRF Makefile used the revision number for that value
17:46:05 <planetmaker> Eddi|zuHause, if it's about the NewGRF version reported to OpenTTD... does one really need several in a single day? :)
17:46:10 <Eddi|zuHause> later, this was replaced by "days since 2000", because revision number was unreliable
17:46:13 <LordAro> so you're wanting to automatically push an experimental(?) grf to bananas on build?
17:46:25 <Eddi|zuHause> planetmaker: apparently, yes.
17:46:53 <planetmaker> outch. Ok. For *that* my suggestion doesn't work either... because you cannot squeeze the tag letters into the 16 bits.
17:47:26 <planetmaker> unless you age-sort the tags, too, and squeeze them in the... dunno... 8 bits? And then you're stucke when you're over 256 tags ;)
17:47:43 <Eddi|zuHause> LordAro: not necessarily as far as bananas, but if you keep builds around for longer on public space like openttdcoop devzone
17:47:51 <planetmaker> or... ok, 10 tag bits, and 6... for in between. Doesn't work either
17:48:33 <LordAro> days since 2000 concatenated with number of commits today?
17:48:57 <Eddi|zuHause> LordAro: specifically, Andy has build-on-push enabled, and sometimes does more than one push per day
17:49:48 <Alberth> not publish at bananas, but on devzone, yes
17:51:21 <planetmaker> lord aro's idea: days since 2000 and counting commits per day... that sounds feasible
17:51:49 <Eddi|zuHause> planetmaker: well, maybe each tag could get a specific number that is added to the commits-since-last-tag
17:52:00 <LordAro> that said, it's ultimately not any different to counting the number of commits
17:52:09 <frosch123> number of commits in branch sounds more reasonable to me then
17:52:14 <Eddi|zuHause> planetmaker: you only have to adjust that table each time you add a tag
17:52:38 <Eddi|zuHause> which could be done by a commit hook
17:54:51 <Eddi|zuHause> so, if you store for each tag the number of commits in the chain to the root, then tag-value+commits-since-tag would be the value that i proposed in the first place
17:58:52 *** TheMask96 has joined #openttd
18:08:25 *** FLHerne has joined #openttd
18:10:35 <planetmaker> Eddi|zuHause, you can easily assign a value to the tag by sorting them by age. That's unique and doesn't need storage. And the commits since the tag is also unique. But(!) you can then still have two commits which get an identical value: commit a tag. And then have from there branch into two equally long heads
18:11:28 <planetmaker> which was actually why I didn't choose this method in the first place, iirc: it doesn't ensure uniqueness - and is in some way less intuitive than days-since-2000
18:11:39 <Eddi|zuHause> now there's two separate problems in there
18:12:01 <Eddi|zuHause> one is, before you commit a tag, and after you commit a tag, these numbers should also be incremental
18:12:12 <Eddi|zuHause> the other one is, if you do two branches
18:13:10 <Eddi|zuHause> how big the branches problem is is really dependent on how much you actually use branches
18:14:01 <Eddi|zuHause> the tag problem is why i suggested storing the number that that tag would have relative to the previous tag
18:14:46 <Eddi|zuHause> say, you make 100 commits, tag that as 1.0, then the next commit should have the number 101 (value of tag 1.0 + 1 commit since tag)
18:15:18 <Eddi|zuHause> something along these lines
18:26:21 <Alberth> allocate a block of grfids as "experimental for everybody", and assign numbers from that block?
18:26:50 <Alberth> add bit "this grf is not compatible with any other grf with the same id ?
18:27:13 <Eddi|zuHause> that sounds terrible
18:27:14 *** Wormnest has joined #openttd
18:27:38 <Alberth> you want an upgrade path from experimental stuff?
18:27:41 <Eddi|zuHause> how would you test whether your test build is compatible with your previous test build?
18:27:57 <Eddi|zuHause> or with your previous release?
18:28:07 <Alberth> why would it need to be compatible with other test-builds?
18:28:23 <Alberth> previous release, ok, don't use that bit
18:28:29 <Eddi|zuHause> why would you deliberately destroy compatibility?
18:29:02 <Alberth> we seem to be running into problems with the number of allocatable numbers, this is one way to make room
18:29:38 <Eddi|zuHause> i don't think that is a solution for any problem that we're trying to solve
18:30:20 <Alberth> if two grfs are not compatible with anything, their order is non-relevant
18:30:50 <Alberth> as long as we can point out which one it is, which you can do in text in the grf
18:30:52 <Eddi|zuHause> this is the "i solve all problem of humanity by killing all humans" solution
18:31:10 <Alberth> no, I leave all releases alone
18:31:30 <Eddi|zuHause> statistically, there aren't all that many releases
18:31:50 <Eddi|zuHause> every interesting thing happens with non-releases
18:32:10 <Alberth> sure, but you don't need an upgrade path there, imho
18:57:34 <Eddi|zuHause> sometimes youtube is a bit strange... it suggests me minecraft videos that are 5 seconds long and have 6 views?
18:57:57 <Eddi|zuHause> by a channel that has 4 subscribers
18:58:12 <frosch123> well, as long as you are one of them
19:00:03 <Eddi|zuHause> well, maybe if you round the 5 seconds to 6 seconds (youtube is a bit weird with that), and consider that it was uploaded 6 hours ago... that makes it 666?
19:06:15 <Alberth> you have seen too many videos, so it's desperately trying to give you something new :p
19:19:00 *** andythenorth has joined #openttd
19:25:35 *** sim-al2 has joined #openttd
19:25:35 *** Tharbakim has joined #openttd
19:25:35 *** fiatjaf has joined #openttd
19:25:35 *** innocenat has joined #openttd
19:25:35 *** supermop_home has joined #openttd
19:25:35 *** techmagus has joined #openttd
19:25:35 *** mikegrb has joined #openttd
19:26:11 *** greeter has joined #openttd
19:26:11 *** mindlesstux has joined #openttd
19:26:11 *** quiznilo has joined #openttd
19:26:11 *** Warrigal has joined #openttd
19:26:11 *** supermop has joined #openttd
19:26:11 *** ccfreak2k has joined #openttd
19:29:55 <Alberth> ie, it's not LATEST very long :p
19:31:36 <andythenorth> tags are quite infrequent :)
19:31:55 <andythenorth> the logs didn’t seem to conclude anything, unless I missed it?
19:32:44 <Alberth> hmm, also, ../release/.., tricky
19:32:50 <andythenorth> all I can see is ‘this is hard’
19:33:38 <Alberth> I haven't follow the discussion entirely, but I didn't see any conclusion or agreement
19:33:56 <andythenorth> might be easiest to leave it ‘as is'
19:34:14 <andythenorth> just means bundles will produce ‘broken’ grfs
19:34:39 <Alberth> depending on how you look at it :p
19:34:55 <Alberth> it uses commit count at default
19:35:11 <Alberth> your repo just uses different numbers
19:35:37 <Alberth> so add a hash somewhere you can find it :)
19:38:05 <andythenorth> the min. compatible version in action 14 will be quite broken :)
19:38:16 <andythenorth> broken savegames
19:38:51 <andythenorth> but does *anyone* ever get it from bundles?
19:41:00 <Alberth> but I never upgrade firs in a running game
19:41:27 <andythenorth> I wonder if I could just omit the action 14 check
19:41:36 <andythenorth> as it’s not going to be useful
19:42:05 <Alberth> despite disagreement from Eddi, I still think making experimental grfs incompatible with any other version is fine
19:43:39 <andythenorth> which is a shame
19:45:14 *** smoke_fumus has joined #openttd
19:45:42 <Alberth> that \d is a 16 bit numbers?
19:46:06 <Alberth> why can't it be something bigger, say a full time-stamp
19:49:01 <andythenorth> historical reasons, I assume :)
19:49:14 <andythenorth> also the time stamp is no solution
19:49:22 <andythenorth> because that’s not stable
19:49:43 <andythenorth> I am 99% certain this is non-solvable, at least without serious complication
19:50:23 <andythenorth> oh does hg have the timestamp as well as the hash?
19:50:26 * andythenorth overlooking that
19:50:42 <frosch123> well, for now bundles is in sync again
19:52:37 <frosch123> oi, it does a complete checkout every time
19:52:57 <frosch123> so i need to change something in the build script
19:53:58 <andythenorth> are the build scripts version-controlled?
19:54:03 <andythenorth> I can’t find them in devzone
19:54:03 <Alberth> even git has time-stamps :p
19:54:22 <frosch123> andythenorth: some are, but not every project uses the same
19:54:31 <andythenorth> I usually just look that up from the hash Alberth :P
19:54:43 <andythenorth> not usually trying to determine compatibility based on the rev :P
20:01:46 <frosch123> firs config was different from other projects
20:01:57 <andythenorth> firs always has to be special eh :P
20:02:17 <frosch123> the "template" is named "eints-test" :p
20:02:41 <frosch123> so, likely only projects newer than eints are somewhat similar
20:04:23 <planetmaker> the build scripts are version controlled, yes. Either in the firs repo. Or in the devzone repo
20:05:10 <frosch123> planetmaker: the issue here is that jenkins only cloned the branch which were to be compiled
20:05:10 <planetmaker> the devzone has a separate repo... called 'misc' in the hg.o.o instance
20:05:26 <frosch123> i "fixed" that by pulling manuially in ther working dir
20:05:35 <frosch123> but firs was configured to delete the working dir every time
20:05:39 <planetmaker> aye, I think it does that, yes. I think the reason is that cloning everything with zbase was a bad idea
20:06:01 <frosch123> anyway, the build scripts actually do not affect the clone
20:06:14 <planetmaker> or rather slug or whatever v's things were called
20:06:48 <planetmaker> yes... the portion which is cloned is not controlled by the build scripts
20:06:57 <frosch123> the first one from jenkins, the second one from jenkins_build
20:07:15 <frosch123> the jenkins one has "--rev default"
20:07:24 <frosch123> the second one won't fix local revision numbers
20:07:53 <planetmaker> probably your guess as to the reasons is right... not sure
20:08:00 <andythenorth> frosch123: accurate now ;)
20:08:24 <frosch123> andythenorth: it's no definite fix
20:08:34 <frosch123> it will break again if someone reinstalls devzone or something
20:08:43 <frosch123> but likely lasts a few years :p
20:08:50 <planetmaker> what did you do to fix it?
20:09:10 <andythenorth> script to check hash and rev number against devzone repo?
20:09:22 <andythenorth> devzone is legitimate to consider canonical origin
20:09:32 <andythenorth> fail jenkins if bundles and devzone diverge?
20:09:41 <frosch123> planetmaker: i disabled jenkins deleteing the working dir (which was enabled for firs, but not in the template), and then made a manual clone in the working dir
20:10:04 <frosch123> so now it works until someone deletes the working dir again, or until andy makes a branch
20:10:15 <planetmaker> I guess... that was done due to some previous FIRS build issues...
20:10:25 <planetmaker> always doing its special things
20:10:33 <frosch123> the build script contains a purge, so it should be fine
20:10:50 <planetmaker> you would think, yes
20:11:16 <planetmaker> but I've seen that leave traces behind, still
20:12:30 <planetmaker> does it use purge --all -dirs ?
20:14:10 <frosch123> "hg purge --all" unless there is some magic .cache dir in .devzone
20:14:29 <frosch123> please adjust jenkins_build.sh if that is not good enough :)
20:15:29 <frosch123> according to docs "--dirs" would be wrong
20:15:36 <frosch123> since that would *only* delete directories
20:25:27 *** Thomas[m]2 has joined #openttd
20:26:40 *** FLHerne has joined #openttd
20:27:36 *** Extrems has joined #openttd
20:38:41 *** andythenorth has joined #openttd
20:53:43 *** dustinm` has joined #openttd
21:06:09 *** Belugas has joined #openttd
21:06:09 *** ChanServ sets mode: +o Belugas
21:08:35 *** Maarten has joined #openttd
21:12:49 *** Smedles has joined #openttd
21:49:28 *** quiznilo has joined #openttd
22:33:23 <andythenorth> I don’t like all this ‘my first newgrf’ crap :P
22:34:15 <andythenorth> I look at that page, and I’m thinking ‘wtf is FIRS'
22:34:20 <andythenorth> also ‘why 80 industries'
22:35:12 <Wolf01> 1. Switch point 1 with the "get started"
22:36:11 <Wolf01> Also... get started...
22:36:18 <andythenorth> “New to newgrfs?” “How did you find FIRS docs then?"
22:36:31 <andythenorth> it’s only linked via forums, and via in-game content
22:37:09 <Wolf01> I would make the point 7 as FIRS presentation
22:37:21 <andythenorth> glad you said that
22:40:21 <andythenorth> ach conflict detection, it’s so boring
22:55:30 <andythenorth> and found a bug :P
23:02:56 *** andythenorth has left #openttd
23:28:22 *** circ-user-s74z0 has joined #openttd
23:52:30 <Wolf01> Shit... I think I failed the lazy bastard objective :(
23:56:49 *** JacobD88 has joined #openttd
continue to next day ⏵