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 https://github.com/OpenTTD/OpenTTD/pull/6881#issuecomment-411293372 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 https://github.com/OpenTTD/OpenTTD/pull/6881#issuecomment-411294747 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 https://github.com/OpenTTD/OpenTTD/pull/6881#issuecomment-411295505 06:10:27 *** andythenorth has joined #openttd 06:12:14 <andythenorth> moin 07:05:22 *** andythenorth has quit IRC 07:44:09 <planetmaker> https://newgrf-specs.tt-wiki.net/wiki/Action0/Bridges#cite_note-nmf-1 <-- 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> https://newgrf-specs.tt-wiki.net/wiki/Action0/Stations <- 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> http://nimb.ws/5YHXtP 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. https://wiki.openttd.org/Frosch/NotRoadTypes 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: https://www.tt-forums.net/viewtopic.php?p=878524#p878524 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 https://github.com/OpenTTD/OpenTTD/issues/6882 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 https://github.com/OpenTTD/OpenTTD/blob/master/config.lib#L1376 15:22:06 *** keoz has joined #openttd 15:50:34 *** Gustavo6046 has joined #openttd 15:50:36 <Gustavo6046> hey guys 15:50:38 <Gustavo6046> https://i.imgur.com/CP8QmfP.gifv 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 https://gist.github.com/andythenorth/f9c6502a915b1499805d71937c3312a1 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 https://wiki.openttd.org/Compiling_on_Mac_OS_X#Using_Homebrew 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 https://www.youtube.com/watch?v=1E_Hwjz_CMI 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> https://gist.github.com/andythenorth/d6fbfea85b53d059d69b59edd0e915a1 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> https://gist.github.com/andythenorth/2bc9029cecbf952a8476c61b8b4c3429 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 https://github.com/OpenTTD/OpenTTD/issues/6880 19:48:40 <andythenorth> I need to be cast iron on the repro and fix 19:50:50 <lethosor> https://gist.githubusercontent.com/lethosor/7e1c2c274dfed20f6462bafe56b86378/raw/06309d1042725b29ef9011e59ba95318567888c9/gistfile1.txt 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 https://github.com/OpenTTD/OpenTTD/issues/6880#issuecomment-411533866 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 https://github.com/OpenTTD/OpenTTD/issues/6882#issuecomment-411549000 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