Back to Home / #openttd / 2018 / 08 / Prev Day | Next Day
#openttd IRC Logs for 2018-08-08

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