Log for #openttd on 8th August 2018:
Times are UTC Toggle Colours
00:55:20  *** Supercheese has quit IRC
01:09:35  *** Supercheese has joined #openttd
01:26:27  *** Smedles has quit IRC
01:30:49  *** chomwitt has quit IRC
02:00:03  *** glx has quit IRC
03:52:37  *** haudrauf has quit IRC
03:53:56  *** haudrauf has joined #openttd
04:07:24  *** Supercheese has quit IRC
04:07:47  *** Supercheese has joined #openttd
05:07:54  *** cHawk has quit IRC
05:11:44  *** snail_UES_ has quit IRC
05:21:06  *** peter1138 has joined #openttd
05:21:06  *** ChanServ sets mode: +o peter1138
05:29:31  *** andythenorth has joined #openttd
05:51:22  <DorpsGek_II> [OpenTTD/OpenTTD] LordAro commented on pull request #6881: Fix: Script/AI construction of rail track and waypoints
05:54:17  <peter1138> morning
05:59:14  <DorpsGek_II> [OpenTTD/OpenTTD] PeterN commented on pull request #6881: Fix: Script/AI construction of rail track and waypoints
06:02:00  *** andythenorth has quit IRC
06:02:26  <DorpsGek_II> [OpenTTD/OpenTTD] LordAro commented on pull request #6881: Fix: Script/AI construction of rail track and waypoints
06:10:27  *** andythenorth has joined #openttd
06:12:14  <andythenorth> moin
07:05:22  *** andythenorth has quit IRC
07:44:09  <planetmaker> <-- eh, we now add random stuff from random patch packs to the specs?
07:44:30  <planetmaker> I consider that a bit... unfortunate
07:56:37  <planetmaker> <- also here :|
08:02:38  *** Wolf01 has joined #openttd
08:19:56  <LordAro> i would suggest removing
08:23:47  *** andythenorth has joined #openttd
08:24:44  <planetmaker> yeah... having entries marked as "used in neither TTDP nor OTTD" is... kinda pointless.
08:27:06  <andythenorth> it does need a solution though
08:27:11  <andythenorth> patchpacks are the future
08:27:31  <planetmaker> but that is not the solution IMHO. Or it will be very quickly an utter clutter
08:27:34  <andythenorth> fragmenting the grfspec without a plan is unfortunate
08:28:08  <planetmaker> that is supposed to be OpenTTD's canonical specs. No point in having it feature the specs of every patch pack ever was and will be
08:28:21  <planetmaker> or better: ideas of what could be
08:28:29  *** Supercheese has quit IRC
08:28:37  <planetmaker> that's why frosch made the station thing on his own... and not there
08:29:06  <andythenorth> what options can we think of?
08:29:13  <andythenorth> other than a big table listing what implements what
08:29:13  <planetmaker> and are patch packs with everyone with its own specs really the future?
08:29:18  <andythenorth> kinda yes
08:29:27  <planetmaker> that will lead to fragmentation. And no grf working anymore
08:29:38  <planetmaker> I doubt it, seriously
08:29:58  <andythenorth> hmm
08:30:01  <andythenorth> dunno
08:30:12  <andythenorth> current vision is stable core + patchpacks
08:30:20  <planetmaker> they usually live as long as a single author contributes
08:30:49  <andythenorth> I think this hinges on the relationship of the content APIs to 'stable core'
08:30:51  <planetmaker> so they can do all the PP they want. But we cannot maintain every PP's specs there. Nor do we want that really, I think
08:30:58  <andythenorth> I don't want that no
08:31:03  <andythenorth> just to be clear
08:31:19  <andythenorth> I also doubt many people are going to fork nml
08:31:32  <planetmaker> I doubt it, too, yes
08:32:04  <andythenorth> so is this a spec definition problem, or just a docs problem?
08:32:09  <andythenorth> they are subtly different
08:33:12  <planetmaker> if we progress this path, the specs WILL become cluttered with cruft which make future development of the grf specs utterly more crappy and unconsistent than already necessary
08:33:25  <planetmaker> it's a docs problem for the PPs
08:33:27  <andythenorth> and that is a low baseline already :)
08:33:33  <planetmaker> but a specs problem for OpenTTD itself
08:34:04  <andythenorth> I have proposed moving away from wiki for API docs
08:34:09  <andythenorth> but frosch was very -1 to that
08:34:17  <andythenorth> NoGo isn't a wiki though
08:34:43  <planetmaker> yes... But generating that from in-source docs doesn't work as nicely as the wiki is now
08:35:08  <planetmaker> The wiki has so much more than a doc generator (easily) generates. That'd be a hell lot of work for very little benefit
08:35:17  <andythenorth> is there any difference between API spec and 'guides to newgrf'?
08:35:18  <planetmaker> or maybe even negative benefit
08:35:20  <andythenorth> wiki does both
08:35:44  <planetmaker> there likely is some. But it's a fluent transition in the wiki as-is.
08:36:28  <andythenorth> ok, well in that case, it's inevitable that PP-only features will be documented in wiki
08:36:37  <andythenorth> then it needs an editorial policy
08:37:14  <planetmaker> well. Depends on how you define the scope of that wiki. Whether it is supposed to be the canonical one. Or cover all the non-official fringes
08:37:31  <planetmaker> IMHO it's the canonical documentation. And not the fringe one.
08:38:14  <andythenorth> I have no argument against that :)
08:38:34  <planetmaker> we should ask frosch and alberth when they're here what they think
08:38:49  <planetmaker> can you try to remember to bring up that topic? :D
08:38:55  <andythenorth> I am guessing they hope someone else sorts it out :)
08:39:03  <planetmaker> yeah :P
08:39:15  <planetmaker> but it will deteriorate quickly, if we have this start pass
08:39:42  <planetmaker> the later, the worse
08:40:54  <peter1138> so...Urgh
08:46:59  <planetmaker> ^^
08:51:26  <peter1138> If spec additions don't go in the wiki, where should they go?
08:51:52  <planetmaker> the question is which spec additions?
08:52:08  <peter1138> How did TTDPatch feel when we started adding stuff?
08:52:39  <Wolf01> Ok, but we were one, not 16
08:52:50  <Wolf01> With 16 different specs
08:52:51  <peter1138> I think the fact that is it not official needs to be marked more clearly.
08:53:09  <LordAro> maybe a dedicated page for a particular patchpack?
08:53:14  <Wolf01> The problem is that we don't have anything like "is this grf feature supported?"
08:53:20  <planetmaker> the wiki will be worthless, when everyone adds his favourite properties, variables etc everywhere
08:53:22  <peter1138> I'm also torn. I do dislike it as well, but actually, we did the same :p
08:53:23  <LordAro> "this are the additions/changes/deletions for this version"
08:53:28  <LordAro> these*
08:54:02  <peter1138> For stations, what is 1A? I've never heard of it o_O Did I write it?
08:54:29  <LordAro> probably
08:54:32  <peter1138> (And I dislike 1B because it reinforces the stupid 8 tile limit)
08:55:19  <planetmaker> might be that frosch wrote 1A. But not sure
08:56:01  <peter1138> Lol at bridges. Got to use GRM. Haha.
08:56:14  <planetmaker> I never figured how GRM even works
08:56:28  <planetmaker> so I don't even know what that means :P
08:57:48  <peter1138> Use action D (IIRC) to reserve an ID, and then use action 6 to *modify the raw data* of the proceeding action, so that it uses the reserved IDs.
08:58:20  <peter1138> It is very much a kludge for the lack of dynamic ID allocation.
08:58:47  <planetmaker> sounds... pretty cruft and unnecessary
08:58:47  <peter1138> I guess bridges don't have action 1,2,3, so they came up with this hack :S
08:58:53  <planetmaker> for today's standard
08:58:54  <peter1138> planetmaker, it's very much ttdpatch-like.
08:59:09  <peter1138> I'd guess that NML doesn't use it, or at least doesn't expose it.
08:59:21  <planetmaker> NML doesn't yet do bridges. Nor stations :|
08:59:32  <planetmaker> and no, NML doesn't expose GRM
09:01:51  <peter1138> I guess we need the specs to be in git, so they can be forked and branches ;)
09:01:53  <peter1138> -s+d
09:02:37  <planetmaker> that's what andy also suggested. I recon it's a LOT of work to move that
09:03:27  <planetmaker> would make custom additions and changes more clear. And keep the canonical specs more tidy
09:08:17  <andythenorth> I am not really prepared to do the work to move specs to git :)
09:08:24  <andythenorth> so I can't really ask other people to do it :)
09:08:38  <peter1138> It was a joke.
09:09:10  <andythenorth> I wasn't :P
09:09:23  <andythenorth> but we'd need to be able to auto-generate, and that's not happening
09:09:32  <peter1138> planetmaker, yeah. "Unofficial" though.
09:10:49  <planetmaker> ok
09:40:07  <reldred> 'it's very much ttdpatch-like' you know, you're not wrong, but I still look back at the ttdpatch source absolutely amazed that whole fucking thing worked. And worked as well as it did for so long.
09:41:11  <reldred> from a purely academic point of view it was almost a work of art
09:43:12  <reldred> I do not miss working in asm though
09:44:51  <peter1138> I don't think it's a bad design for the limitations that were there.
09:45:42  <peter1138> It amazes me how you all managed to find the hooks and patch jumps etc in. It's black magic voodoo stuff, tbh.
09:50:21  <reldred> yeah, I really shouldn't comment too much on the guts of it since I never really committed a patch all on my onesies but josef helped me learn ida pro back in the day, figure out how the trains determine what tracks they're allowed to run on, etc.
09:50:51  <reldred> I wanted to repurpose maglev for like an urbna rail type thing
09:51:03  <reldred> and wanted to be able to hop off one set of tracks onto another
09:51:20  <reldred> But as a teenager seeing under the hood and learning that shit was unreal
09:51:29  <reldred> I never did become a programmer but learning that shit shaped my career
09:58:04  <SpComb> TTDPatch would have been pretty harecore
09:58:20  <SpComb> self-modifying x86 assembler
09:58:59  <reldred> It was nuts
09:59:23  <reldred> A lot of it was driven from paranoia over getting sued
09:59:38  <reldred> So it only ever attacked the executable when it unpacked to ram
09:59:58  <reldred> So many things would have been so much easier modifying the exe directly
10:01:25  <reldred> The sheer amount of time you'd spend just stepping through instruction by instruction in ida pro furiously scribbling notes just to figure out something simple, let alone how in the hell josef and oskar and everyone else figured out the really hard shit
10:02:12  <SpComb> experience
10:02:48  <reldred> Yeah no shit
10:02:59  <SpComb> I wonder if hand-written asm would be easier or harder to reverse-engineer than compiler-generated asm
10:03:34  <reldred> hmmm, once it goes through the linker it looks nothing like what you originally wrote
10:03:41  <reldred> well
10:03:44  <reldred> kinda does
10:03:46  <reldred> kinda doesnt
10:06:39  <reldred> and theyall behaved slightly differently, had additional features, etc
10:10:34  <reldred> oh neat, my plane is here, ttyal
10:12:53  *** chomwitt has joined #openttd
10:30:10  *** dvim has joined #openttd
11:15:57  *** andythenorth has quit IRC
11:17:12  *** andythenorth has joined #openttd
11:47:23  <Eddi|zuHause> <planetmaker> yeah... having entries marked as "used in neither TTDP nor OTTD" is... kinda pointless. <-- i disagree. the idea here is that TWO patcpacks are now offering this, and they need some coordination.
11:48:05  <Eddi|zuHause> mainly, the newgrf authors need some security that the things are not being reused for other stuff
11:48:24  <Eddi|zuHause> otherwise they will never develop newgrfs using these features
11:49:09  <planetmaker> and that's the point. That makes the specs... even worse to handle than they are now
11:49:52  <Eddi|zuHause> the specs are NOT for representing the current implementation of master
11:50:12  <planetmaker> I wouldn't want to give the guarantee that it's not re-defined. And yes, that is exactly what they DO
11:51:10  <Eddi|zuHause> the specs were always this separate cross-platform agreement between developers of different projects (TTDP, OTTD, NewGRFs)
11:51:19  <andythenorth> exciting times
11:51:27  <planetmaker> adding there random additions w/o any means to find out which apply to your current version you run - makes the specs worthless
11:52:01  <planetmaker> that was the case before. With the PPs that's not the case. Thus you'll get NewGRFs which - seeming randomly - don't work. W/o any means for a user to see why
11:52:10  <Eddi|zuHause> the detection whether the version provides this piece of specs is a problem, yes
11:52:55  <Eddi|zuHause> the versioning needs also a solution in master, because there is no incremental revision anymore
11:53:03  <planetmaker> And the point is to indeed document the specs for OpenTTD/master
11:53:10  <Eddi|zuHause> no
11:53:30  <planetmaker> if that's not the point, we can well skip it and abandon it.
11:53:35  <Eddi|zuHause> no
11:53:36  <andythenorth> my assumption was that the wiki documents TTDP as well?
11:53:41  <planetmaker> wishlists go to general wiki
11:53:42  <andythenorth> I know that's now almost dead
11:53:52  <Eddi|zuHause> it's not a wishlist
11:54:06  <Eddi|zuHause> it's still tracking what's actually implemented _somewhere_
11:54:13  <andythenorth> I always treated it as a document for a cross-platform API, which isn't 100% implemented on either platform
11:54:31  <andythenorth> maybe that was wrong, or needs to change
11:54:39  <Eddi|zuHause> i said in the JGR thread already, it CANNOT detoriate into a wishlist
11:55:01  <andythenorth> there's already a process for putting up wishlists
11:55:12  <andythenorth> e.g.
11:55:22  <Eddi|zuHause> but it must be lenient enough to handle this upcoming issue, that several patchpacs must coordinate their implementation of the same feature
11:55:33  <planetmaker> ^^ that's also implemented somewhere. So we add every branches fiddling there now?
11:55:38  <Eddi|zuHause> no
11:55:49  <Eddi|zuHause> that's a working proposal
11:55:52  <Eddi|zuHause> it's different
11:55:55  <planetmaker> "must coordinate". But what will happen that it's cluttered by bad design decisions
11:56:03  <andythenorth> this is a really hard problem :)
11:56:05  <Eddi|zuHause> it already is
11:56:16  <planetmaker> and that's why it has to continue?
11:56:34  <Eddi|zuHause> no
11:56:49  <planetmaker> "let's add 3 more bridge types".
11:56:59  <planetmaker> without making it a 1st-class feature. That's exactly that
11:57:35  <Eddi|zuHause> planetmaker: changing the number from 13 to 16 is a one-line patch, reworking the bridge feature is a year-long task
11:57:47  <Eddi|zuHause> planetmaker: they are not blocking each other
11:57:51  <Eddi|zuHause> why reject it?
11:58:09  <Eddi|zuHause> we're randomly deciding to up cargo numbers and railtype numbers here
11:58:20  <Eddi|zuHause> why make such a fuzz about a tiny change like that?
11:59:03  <Eddi|zuHause> i'd say you'd be quicker just backporting that same commit from JGR/NMF patchpacks
11:59:42  <planetmaker> that'd be adding bad to worse. As they are NOT implemented as the other 13.
11:59:49  <planetmaker> at least it's stated differently
12:01:09  <planetmaker> and why is the NRT "not implemented". But another patchpack is? What's the difference really between a patchpack and a "concept"?
12:01:12  <peter1138> Because the other 13 are hardcoded already.
12:01:22  <peter1138> I wouldn't want someone to hardcode an additional 3.
12:01:31  <planetmaker> ^^
12:02:00  <Eddi|zuHause> planetmaker: a patchpack is something different, because it's something semi-stable (ideally)
12:02:11  <Eddi|zuHause> planetmaker: a patch like NRT is still very fluid
12:02:29  <peter1138> Does this "town road" flag exist in NRT?
12:02:56  <Eddi|zuHause> dunno, we discussed it a bunch of times
12:03:38  <andythenorth> somewhere a repo knows
12:03:57  <peter1138> I know it was discussed yesterday but not if it exists.
12:04:01  <Eddi|zuHause> well, i've been proposing it from the very beginning
12:04:16  <Wolf01> <peter1138> Does this "town road" flag exist in NRT? <- yes, supermop provided a grf for that and I implemented it
12:04:21  <peter1138> Yay :D
12:06:12  <Wolf01> TODO: properly store the chosen town road, better algorythm to choose between the falgged roadtypes, handle the changing of the roadtype in different eras or when new flagged roadypes will be available
12:07:46  <Eddi|zuHause> you could provide a "global" callback so the newgrf can return a roadtype suggested for towns
12:08:06  <Eddi|zuHause> i believe we have this kind of stuff already somewhere
12:08:23  <Eddi|zuHause> for AI station selection or something
12:08:54  <peter1138> Someone will want to mix road types.
12:09:10  <peter1138> Hmm, as they do stations. Must be solvable.
12:09:12  <Wolf01> <Eddi|zuHause> you could provide a "global" callback so the newgrf can return a roadtype suggested for towns <- Wouldn't that mean that every town will have the same roadtype?
12:09:13  <Eddi|zuHause> yeah, last definition wins
12:09:33  <Eddi|zuHause> Wolf01: yes, why not?
12:09:54  <Eddi|zuHause> Wolf01: well, you can still decide when the town runs that callback
12:10:05  <peter1138> See, if you want just some towns to have an "old town" area that's still cobbled...
12:10:10  <peter1138> But not all towns.
12:10:19  <Wolf01> That could be handled with town zones
12:10:19  <peter1138> Is that a town choice or a newgrf choice?
12:10:58  <Eddi|zuHause> that's a question of whether the town runs an "upgrade existing roads" feature
12:11:07  <Wolf01> But what if in 1800 you want 50% of towns to have dirt road and other 50% cobble road?
12:11:22  <Wolf01> Maybe that could be decided by town size too
12:11:42  <Wolf01> Everything via newgrf, because the game doesn't know about dirt and cobble
12:12:02  <peter1138> How often do towns expand? Do you want a callback being called every time it does?
12:12:07  <Eddi|zuHause> add something to extra_callback_info1/2
12:12:37  <Eddi|zuHause> the newgrf could also check PARENT to get town info
12:12:42  <Wolf01> The callback to change type should be called only when new roadtypes become available
12:12:56  <Eddi|zuHause> i don't think it works that way
12:13:11  <Eddi|zuHause> the town should periodically run the callback, like once a year
12:13:20  <Eddi|zuHause> and store the result
12:13:21  <Wolf01> That too
12:13:37  <peter1138> And don't try to calculate it on load :D
12:13:48  <Eddi|zuHause> towns don't necessarily jump on every "new roadtype" hype :p
12:13:59  <Wolf01> Rainbow roads
12:15:02  <peter1138> You could, of course, do both. Yearly, and if a new roadtype is available.
12:15:28  <peter1138> That beats calling it every time.
12:15:59  <peter1138> But the thing is.
12:16:05  <peter1138> What's the return value?
12:16:15  <peter1138> "What road type to build" is pretty terrible idea.
12:16:31  <peter1138> There are zones.
12:16:32  <Eddi|zuHause> just a random thing i digged up:
12:16:36  <peter1138> dug
12:16:45  <Eddi|zuHause> digdug
12:16:59  <planetmaker> duck
12:17:51  <peter1138> City connections are vital I think but not directly related.
12:18:21  <peter1138> Roads are pretty expensive and should just exist, preferably in shitty slow windy form.
12:19:22  <Eddi|zuHause> like TF roads
12:21:13  <peter1138> Like what?
12:21:26  <Eddi|zuHause> at some point i thought city connections could be handled by a game script
12:21:30  <Eddi|zuHause> Transport Fever
12:21:36  <peter1138> Not played it.
12:21:58  <peter1138> Problem with game script is there's just one of them.
12:22:04  <Eddi|zuHause> yes
12:22:10  <peter1138> Which kinda makes sense for the purpose of what it is.
12:22:28  <peter1138> But removes flexibility.
12:23:50  <Eddi|zuHause> so the road connections would be a library, that game script authors would be encouraged to include. but you'd get dozens of requests that gamescript X should include them
12:24:00  <Eddi|zuHause> it's not a perfect solution
12:29:39  <Wolf01> Yeah, I fucked up C:S... citizens started to get sick and placed 1 more hospital, now I'm losing 00
12:33:50  <SpComb> sounds like your sewage is most likely spilling over into your water intake
12:34:06  <SpComb> check the pollution map
12:34:24  <SpComb> it causes rapid population decline :)
12:34:28  <Wolf01> Nah, the entire city is sick and I don't have any other problem than RAIN
12:34:52  <Wolf01> "city".. 2 roads
12:35:45  <Wolf01> Lost 20% of population so far and expenses are rampaging :(
12:38:56  <SpComb> no pollution issues?
12:39:48  <Wolf01> No
12:40:41  <Wolf01> Ok, maybe a bit the water...
12:43:31  <SpComb> your fresh water intake isn't supposed to be brown :P
12:43:50  <Wolf01> It wasn't before :P
12:45:14  <Eddi|zuHause> the water pump alters the water flow
12:46:20  <Eddi|zuHause> also, you can probably turn off the second hospital to save money
12:46:25  <Wolf01> I moved the water pump on the other edge of the map, upstream
12:46:52  <SpComb> yeah, toggle the hospital off and wait for it to fix itself
12:47:02  *** eirc has joined #openttd
12:47:23  <Wolf01> I did better, reloaded, moved the water source, no more pestilence
12:47:29  <SpComb> cheating!
12:47:39  <Eddi|zuHause> timetravel!
12:47:40  <SpComb> my first city survived its water poluttion episode :)
12:48:01  <Wolf01> :P
12:50:00  <Wolf01> How do I set the industry as "farms"? The districts tool seem to be the one, but I can't understand how to use it
12:50:26  <Eddi|zuHause> 1) you draw a district
12:50:41  <Eddi|zuHause> 2) in the district tool you have tabs, select the industry one
12:50:58  <Eddi|zuHause> 3) then you can select the industry focus "farms" and click on the district
12:51:28  <Wolf01> Oh, there it is
13:25:21  <Eddi|zuHause> coming back to the specs discussion: OpenTTD can happily live without the specs, the target audience for the specs is the newgrf authors. ideally, we would have some independent committee that prevents the specs from detoriating. but just because it isn't implemented in master is not an immediate reason to exclude something from the specs
13:27:06  <Eddi|zuHause> we do need a solution for the versioning, though
13:40:52  *** ToBeFree has joined #openttd
13:43:13  <Wolf01> Mmmh, is it possible to upgrade a T junction to a cloverleaf?
13:43:32  <Eddi|zuHause> junctions are made up of individual road sections
13:43:38  <Eddi|zuHause> they are not monolithic
13:44:34  <Eddi|zuHause> the builtin junctions never seem to really fit anywhere, though
13:44:38  <Eddi|zuHause> so i always build my own
13:44:47  <Eddi|zuHause> which is a bit fiddly
13:56:45  *** Alberth has joined #openttd
13:56:45  *** ChanServ sets mode: +o Alberth
13:56:54  <Alberth> hi hi
13:57:02  <andythenorth> lo
14:02:46  *** nielsm has joined #openttd
14:04:39  *** ToBeFree has quit IRC
14:13:09  <DorpsGek_II> [OpenTTD/OpenTTD] kika160 opened issue #6882: fatal application failure
14:14:49  <LordAro> 32bit windows...
14:15:09  <LordAro> place your bets on memory or icu
14:17:33  <nielsm> "hebrew.lng"
14:17:35  <nielsm> it's icu
14:18:26  <LordAro> ha, good spot
14:20:38  <nielsm> is there any timeline for 1.9 release yet?
14:21:06  <nielsm> if not I'd almost suggest releasing an 1.8.1 that just hasuniscribe for windows and fps-meter for performance debugging backported
14:21:13  <Eddi|zuHause> somewhere between "no" and "same as always"?
14:21:59  <Eddi|zuHause> i'd say yes to backporting the icu stuff, and no to the fps meter for a 1.8.1
14:22:20  <LordAro> frosch usually deals with these things
14:22:46  <LordAro> it'd probanly be a idea to work out how releases are going to work now that git is a thing
14:23:30  <Eddi|zuHause> first step would be getting a compile farm to run :p
14:32:56  <andythenorth> I could make the binaries locally? o_O
14:32:59  <andythenorth> oh wait, I can't :)
14:33:02  <andythenorth> they don't build
14:36:58  <LordAro> boo
14:46:07  <andythenorth> can I hack .configure?
14:46:12  <andythenorth> 'can I'
14:46:14  <andythenorth> 'can someone'
15:01:19  *** eirc has quit IRC
15:10:02  <LordAro> sure
15:10:44  <LordAro> the hack fix is to remove the if statement around flags
15:22:06  *** keoz has joined #openttd
15:50:34  *** Gustavo6046 has joined #openttd
15:50:36  <Gustavo6046> hey guys
15:50:38  <Gustavo6046>
15:50:40  <Gustavo6046> I am back!
15:52:17  <Gustavo6046> for a while
15:52:24  <Gustavo6046> got to go for school, bye
15:53:16  *** Gustavo6046 has quit IRC
15:57:07  *** Wormnest has joined #openttd
16:10:25  *** eirc has joined #openttd
16:25:47  *** chomwitt has quit IRC
16:36:58  *** dvim has quit IRC
16:42:59  *** frosch123 has joined #openttd
16:59:39  *** andythenorth has quit IRC
17:17:37  *** tokai has joined #openttd
17:17:37  *** ChanServ sets mode: +v tokai
17:24:37  *** tokai|noir has quit IRC
17:30:49  *** keoz has quit IRC
17:36:57  *** andythenorth has joined #openttd
17:37:34  <andythenorth> o/
17:39:40  <andythenorth> ok next errror
17:41:40  <frosch123> buy a new mac?
17:41:56  <andythenorth> I did
17:42:05  <Wolf01> Buy a non mac?
17:42:59  <andythenorth> well I could VM compile
17:43:10  <andythenorth> I could run whatever TB has that produces mac binaries
17:43:37  <frosch123> just add some -liconv in the right place
17:43:43  <lethosor> you're definitely doing a 64-bit build of everything, right?
17:44:16  <lethosor> (make sure you have libiconv installed as well)
17:46:06  <andythenorth> ooh new error
17:46:23  <andythenorth> nope, same error
17:48:49  <andythenorth> does libiconv need adding to the wiki as a dep?
17:49:00  <andythenorth> it's not currently listed
17:50:04  <andythenorth> I love an OS upgrade :(
17:50:06  <andythenorth> always such fun
17:52:41  <lethosor> are you building on 10.13? I wish I could help, but I built master on there yesterday and a few days before with no issues...
17:53:37  <andythenorth> 10.13.6
17:54:25  <lethosor> have you tried a clean build?
17:54:36  <Eddi|zuHause> i feel like missing iconv is something that should have been handled by configure, but this could be a side effect of your configure hacking
17:55:10  <Eddi|zuHause> like, it's running through wrong paths and setting wrong defines
17:55:43  <lethosor> iconv is in /usr/lib for me so it's likely not something that could be missing
17:56:32  <frosch123> iconv is pretty much a standard library
17:57:10  <frosch123> also, andy did have the header files, so it  is installed
17:57:25  <andythenorth> installing libiconv didn't change the error
17:57:44  <andythenorth> oh hang on
17:57:51  <andythenorth> I didn't follow the instructions right
17:57:53  <andythenorth> "This formula is keg-only, which means it was not symlinked into /usr/local,
17:57:54  <andythenorth> because macOS already provides this software and installing another version in
17:57:55  <andythenorth> parallel can cause all kinds of trouble."
17:57:56  <Eddi|zuHause> i recently had an issue where something woudln't link because i had a .so.1 file, but no symlink from .so to .so.1
17:58:03  <andythenorth> so that's telling me I should add it to my path
17:58:24  <andythenorth> so I need to edit .bash_profile to add libiconv?
17:58:31  <Eddi|zuHause> unlikely
17:58:45  <andythenorth> ok
17:58:51  <Eddi|zuHause> you've taken a bunch of wrong turns in your rabbit hole
17:58:55  <lethosor> andythenorth: ls /usr/lib/libiconv.dylib
17:59:35  <andythenorth> that returns /usr/lib/libiconv.dylib
17:59:54  <Eddi|zuHause> andythenorth: you might try setting LDFLAGS, maybe
18:00:24  <frosch123> there is also a configure option for iconv
18:00:24  <lethosor> you shouldn't have to do anything special for libs in /usr/lib
18:00:25  <Eddi|zuHause> but this is still several wrong turns deep
18:01:11  <lethosor> what does "file objs/release/os/unix/unix.o" say?
18:01:53  <andythenorth> objs/release/os/unix/unix.o: Mach-O 64-bit object x86_64
18:02:06  <andythenorth> is it plausible that hacking ./configure has left flags unset?
18:02:17  <Eddi|zuHause> very plausible
18:16:39  *** Progman has joined #openttd
18:38:36  <Eddi|zuHause> this video makes me very uncomfortable and nauseous
18:44:42  *** ToBeFree has joined #openttd
18:45:29  <andythenorth> oof yes
18:45:33  <andythenorth> and weird wide angle
18:58:29  <frosch123> there are way more bussed and trams than pedestrians
19:11:49  *** Alberth has left #openttd
19:20:37  <andythenorth> hmm
19:20:50  <andythenorth> lethosor: can you build current tip of OpenTTD?
19:20:57  <andythenorth> and what's your clang version? o_O
19:22:41  <lethosor> probably, because the only thing that changed when I pulled was src/lang/dutch.txt
19:23:01  <lethosor> Apple LLVM version 9.1.0 (clang-902.0.39.2) Target: x86_64-apple-darwin17.6.0
19:23:15  <lethosor> are you certain that you're using clang and not something else?
19:23:35  <andythenorth> I'm not certain no
19:23:38  <lethosor> (and yes, it built fine)
19:24:54  <andythenorth> curious
19:25:00  <andythenorth> deps from macports or brew?
19:25:16  <lethosor> try "touch src/engine.cpp && make engine.o VERBOSE=1"
19:25:21  <lethosor> (ignore the really long line)
19:25:36  <lethosor> I use homebrew but didn't have to install anything specifically for this
19:26:11  <andythenorth> that command generates warnings, no errors
19:26:46  <lethosor> ok, what's the compiler command?
19:27:06  <lethosor> "touch src/engine.cpp && make engine.o VERBOSE=1|grep engine.o" should give just that line
19:27:53  * andythenorth looking in the output
19:28:24  <lethosor> (really I just care about the program being run - you don't have to paste the whole thing with paths and all)
19:29:23  <andythenorth>
19:29:50  <lethosor> yeah, "g++" is probably no good. Try export CXX=clang++, export CC=clang, then rebuild
19:31:14  * andythenorth tries
19:32:21  <andythenorth> so was that using g++ as the default compiler? :o
19:32:27  <andythenorth> or do I misunderstand?
19:32:39  <lethosor> yes
19:32:51  <andythenorth> how would that happen on a mac clean from Apple?
19:33:05  <lethosor> because g++ is actually an alias for clang that behaves differently sometimes
19:33:09  <andythenorth> ok
19:33:16  <andythenorth> so that's why the errrors still report clang?
19:33:26  <lethosor> yeah
19:33:29  <andythenorth> hmm
19:33:51  <andythenorth> ok so with those exports
19:34:24  <andythenorth> - make now gets through the build where it was failing on economy.cpp (without ../configure being hacked)
19:34:29  <andythenorth> - but the linker failure still happens
19:34:38  <andythenorth> which is interesting
19:35:19  <lethosor> can you make VERBOSE=1 and send the linker command?
19:35:41  <andythenorth> I should twitch stream this and you can laugh at my lack of knowledge as I type
19:36:01  <lethosor> hey I don't really know what's going on either
19:36:50  <andythenorth>
19:37:16  <andythenorth> if I understood correctly :P
19:38:02  <lethosor> still the iconv errors? the command doesn't have -liconv - maybe add that manually?
19:38:40  <andythenorth> that was frosch123's suggestion too
19:41:20  <lethosor> oh, and it didn't work? Anyway, I tested building with "g++" (Apple's alias) and it worked, although I *think* I got more warnings than usual. I'm building with clang now and will compare linker commands once it's done
19:41:51  <andythenorth> -liconv will probably work, I just can't figure out how to add it :)
19:42:45  <lethosor> oh. well one (ugly) way is to copy the last command you sent (starting with clang++ -rdynamic) and add -liconv at the end
19:43:06  <lethosor> although that might require you to be in another folder
19:43:33  <frosch123> check config.lib and find a nice place with LDFLAGS
19:43:35  <michi_cc> LDFLGAS="-liconv" ./configure maybe?
19:43:56  <michi_cc> LDFLAGS that is
19:44:34  <lethosor> yeah, that's probably better than editing configure-related files again
19:46:54  <andythenorth> winner
19:46:58  <andythenorth> built
19:47:04  <andythenorth> let's try from clean to be sure
19:48:31  <andythenorth> so the issue is
19:48:40  <andythenorth> I need to be cast iron on the repro and fix
19:50:50  <lethosor> is my linker command - the only difference is -liconv close to the end
19:52:28  <andythenorth> how do I reset 'export CXX=clang++' so I can repro the original issue?
19:52:35  <lethosor> (also your libpng is 1.6.35 and mine is 1.6.34, heh)
19:52:43  <lethosor> unset CXX and unset CC should do it
19:52:57  <lethosor> alternatively you can export CC=gcc, export CXX=g++
19:54:19  <andythenorth> ta
19:56:37  <andythenorth> ok clean repro
20:02:54  <DorpsGek_II> [OpenTTD/OpenTTD] andythenorth commented on issue #6880: Compile fails on src/economy.cpp:702:20: error: expected expression
20:03:05  <andythenorth> thanks
20:09:10  <michi_cc> andythenorth: CC=clang CXX=clang++ LDFLAGS="-iconv" ./configure should work, too, and doesn't need cleanup.
20:10:11  <andythenorth> ta
20:10:13  <andythenorth> testing
20:10:23  <lethosor> true. I mean, it'll get cleaned up when you exit the shell in any case
20:16:11  <andythenorth> that one's not working
20:16:13  <andythenorth> not sure why
20:16:30  <andythenorth> linker error is back
20:17:09  <lethosor> -liconv, not -iconv (michi_cc)
20:20:46  <andythenorth> ta :)
20:21:40  *** glx has joined #openttd
20:21:40  *** ChanServ sets mode: +v glx
20:26:37  <michi_cc> Oops :)
20:34:51  <andythenorth> updated issue
20:34:54  <andythenorth> thx
20:54:44  <DorpsGek_II> [OpenTTD/OpenTTD] glx22 commented on issue #6882: fatal application failure
20:56:49  <glx> hebrew.lng + ICU, I guess it's easy to blame ICU
21:05:27  <andythenorth> nielsm: eh I have a working build now :)
21:05:31  <andythenorth> so nml is plausible again
21:06:29  <nielsm> yay
21:07:21  <nielsm> but gn now :)
21:07:34  *** Supercheese has joined #openttd
21:08:54  *** ToBeFree has quit IRC
21:10:27  * andythenorth also
21:10:28  *** andythenorth has left #openttd
21:15:22  *** nielsm has quit IRC
21:32:16  *** frosch123 has quit IRC
22:04:36  <Wolf01> 'night
22:04:39  *** Wolf01 has quit IRC
22:13:03  *** Progman has quit IRC
22:39:31  *** Wormnest has quit IRC
22:55:38  *** eirc has quit IRC
23:01:33  *** keoz has joined #openttd
23:38:22  *** Supercheese has quit IRC
23:48:12  *** HeyCitiz- has quit IRC

Powered by YARRSTE version: svn-trunk