Log for #openttdcoop.devzone on 17th July 2010:
Times are UTC Toggle Colours
00:15:21  <Brot6> #openttdcoop Client Patch Pack - Revision 4:b30804bc8d1f: r20146: StationGUI conflict resolved (Ammler) @
00:20:21  <Ammler> redmine has a nice diff viewer
00:40:18  *** KenjiE20 has quit IRC
02:18:55  *** Frankr has quit IRC
05:36:37  <Brot6> NewGRF Meta Language - Revision 559:8e20dfdecb0f: Add: Variable 4A for vehicles (current_railtype) (planetmaker) @
05:55:04  <planetmaker> andy, yes. You still have to clone your repo to the devzone
05:55:50  <planetmaker> hg clone ukrs2-addons ssh://
05:56:00  <planetmaker> ^ andythenorth
06:08:21  <andythenorth> planetmaker:
06:09:20  <planetmaker> I assume you already have an existing local repo in ukrs2-addons?
06:09:46  <andythenorth> yup
06:09:49  <planetmaker> i.e. you ran already hg init? Ok
06:09:50  <andythenorth> well I created one
06:09:52  <andythenorth> let me check
06:10:05  <andythenorth> yep repo exists
06:10:09  <planetmaker> hg tip should tell you something. ok
06:12:05  <planetmaker> uhm. From which dir did you run that clone command then?
06:13:24  <planetmaker> you need to clone the repo from its parent dir
06:14:17  <planetmaker> e.g. ~/ottd/grfdev/sailships> cd ..
06:14:19  <planetmaker> ~/ottd/grfdev> hg clone sailships ssh://
06:14:27  <planetmaker> which worked for me
06:18:05  <andythenorth> planetmaker: maybe I don't have an ssh key for ottdc?
06:18:28  <andythenorth> I thought I did though - think I can use sftp to move files
06:18:58  <planetmaker> I do think you have, that's the usual key. Let me check
06:19:26  <andythenorth> does redmine also try to create the repo on the server?
06:20:15  <planetmaker> it did not. You need to clone your existing repo to the server
06:20:31  <planetmaker> I *thought* Ammler changed that, but no ukrs2-repo exists
06:20:48  <planetmaker> I can manually create on there. Then you could clone the empty repo
06:21:39  <andythenorth> k
06:23:25  <planetmaker> created
06:23:39  <planetmaker> you can now clone that empty one using the usual paths
06:25:18  <planetmaker> hg clone ssh:// ukrs2-addons
06:27:14  <andythenorth> planetmaker: should I put the .hgignore file under version control?
06:27:42  <planetmaker> not a bad idea to do
06:44:38  <Brot6> UKRS 2 Add-ons - Revision 0:9ad23a59f7b6: Add: folder for exports (inc. existing contents) (andythenorth) @
06:44:38  <Brot6> UKRS 2 Add-ons - Revision 1:f173fb2f1c74: Add: folder for psds (inc. existing contents) (andythenorth) @
06:44:38  <Brot6> UKRS 2 Add-ons - Revision 2:27fdc5de4694: Add: .hgignore file (andythenorth) @
06:47:47  *** Alberth has joined #openttdcoop.devzone
07:44:41  <Brot6> UKRS 2 Add-ons - Revision 3:436c40a63b5f: Add: export for Tippler (andythenorth) @
07:44:41  <Brot6> UKRS 2 Add-ons - Revision 4:9b467bf9e898: Change: additional liveries for Tippler (andythenorth) @
09:57:45  <Ammler> planetmaker: what didn't work?
09:58:27  <Ammler> or what shall I have changed?
09:59:25  <Ammler> <planetmaker> [07:55:04] andy, yes. You still have to clone your repo to the devzone <-- wrong
10:00:03  <Ammler> since the repo will be created automatically on the server, you need to pull/push
10:01:49  <Ammler> andythenorth: just create a repo, add Module Repository and you are fine
10:02:01  <Ammler> s/repo/project/
10:04:19  *** Seberoth has joined #openttdcoop.devzone
10:12:20  *** Seberoth has quit IRC
10:13:09  <planetmaker> Ammler: but there was no such dir created when we did that
10:13:27  <Ammler> you did activate Module Repository?
10:13:29  <planetmaker> I was waiting for brot's acknowledgement of that
10:13:31  <planetmaker> yes, it was
10:13:44  <planetmaker> look at the ukrs2-addons
10:13:52  <planetmaker> or is any setting wrong there?
10:14:07  *** Seberoth has joined #openttdcoop.devzone
10:14:41  <Ammler> well, ukrs has already defined a repo, so redmine can't create something anymore
10:15:17  <Brot6> repository /home/ottdc/hg-repos/lets-test registered in Redmine with url /home/ottdc/hg-repos/lets-test
10:15:17  <Brot6> repository /home/ottdc/hg-repos/lets-test created
10:15:40  <Ammler> this script runs every 7minutes
10:15:56  <Ammler> so maybe you were just not patient enough?
10:16:58  <Ammler> please create again a project, so we see, if you did it right
10:18:05  <Ammler> worked as expected
10:19:13  <Ammler> my guess is that you either didn't activate Module Repo
10:19:23  <Ammler> or if you did, you defined the repo manually
10:20:17  *** KenjiE20 has joined #openttdcoop.devzone
10:27:03  <planetmaker> [12:15]	<Ammler>	this script runs every 7minutes <-- that might then well have been
10:27:29  <planetmaker> I defined it manually. After I didn't see it
10:28:29  <Ammler> /home/ottdc/compiler/
10:52:50  *** frosch123 has joined #openttdcoop.devzone
11:35:04  <Ammler>  <-- :-o
11:35:06  <Webster> Title: Transport Tycoon Forums • View topic - [8bpp] Graphics Replacement Project - OpenGFX (at
11:38:24  <Rubidium> oh noes... a bug! Who would've expected that?
11:40:37  <Ammler> well, I updated that last time :'-(
11:41:28  <Ammler> this is also in the release, so I am a bit sceptic :-)
11:44:00  <Ammler> it looks so ugly, how can that be unrecognized such a long time
11:49:39  <planetmaker> hm, if you updated it... how is it then still present?
11:50:32  <Brot6> OpenGFX - Bug #1107 (New): Glitches on houses (Ammler) @
11:53:09  <Ammler> looks like a template bug
11:54:17  <planetmaker> the sprite alignment tool will tell you :-)
11:54:44  <Ammler> never used it :-)
11:54:57  <planetmaker> about time to :-)
11:55:08  <Ammler> indeed, there is a wiki page about?
11:55:51  <Ammler> that would be worth a bugfix release, though
11:57:35  <Ammler> testing if -c has this effect
12:14:23  <Ammler> Could not open "nforenum" specified on the command line. <-- wtf?
12:17:31  <Ammler> yes, -c has influence
12:21:53  <Ammler> feature request for sprite aligner: disable a sprite
12:23:29  <Ammler> hmm, can be done with ctrl-x
12:32:02  <Brot6> NewGRF Meta Language - Feature #964: Complete the list of action0 properties and varaction2 varia... (Hirundo) @
12:32:38  <Ammler> IMO, -c is broken with 1px
12:33:32  <Ammler> in both ways, x and y
12:33:54  <Ammler> it changes 31 to 30 and 0 to 1
12:34:55  <Ammler> hmm
12:35:45  <planetmaker> oh
12:35:49  <planetmaker> nasty
12:35:52  <Ammler> it isn't
12:36:00  <Ammler> :-)
12:36:26  <planetmaker> :-)
12:39:44  <Ammler> actually, thanks to -c, my alignment fault got more viewable
12:40:24  <Ammler> and last release was made without -c, that is why it wasn't that obvious
12:42:33  <Ammler> thanks to template, it is a easy fix
12:42:59  <planetmaker> make sure nothing lese gets worse what uses the template
12:43:03  <planetmaker> might happen...
12:43:12  <planetmaker> templates *can* be a two-edged sword
12:43:28  <Ammler> not logical
12:43:50  <Ammler> in this case
12:44:18  <Ammler> I just move one left, one right
12:47:33  <Ammler> well, I commit my bugfix
12:53:17  <Brot6> OpenGFX - Bug #1107 (Closed): Glitches on houses (Ammler) @
12:53:17  <Brot6> OpenGFX - Revision 467:b5e8ad81df62: Fix #1107: macros for houses were slightly misaligned. thank... (Ammler) @
12:53:17  <Brot6> OpenGFX - Bug #1107 (Closed): Glitches on houses (Ammler) @
13:10:55  <Hirundo> such gems of brilliancy exist in the newgrf spec...
13:11:20  <Hirundo> set bit 31 of a station ground sprite to use an action1 sprite instead of a ttd sprite
13:11:35  <Hirundo> set bit 31 of a building sprite to do the exact opposite of the above :S
13:13:01  <Alberth> they are doing a good job at trying to be as unpredictable as possible :)
13:15:12  <Hirundo> Only demigods like MB should be able to understand nfo
13:16:59  <Hirundo> Mere mortals should not defile the temples of nfo and asm... </sarcasm>
13:18:20  * planetmaker hugs Hirundo
13:18:39  <planetmaker> look at r20164 and compare that with variable FE for vehicles ;-)
13:19:29  <planetmaker> or compare the properties which define the vehicle stats... no, they cannot have the same number
13:21:01  <planetmaker> *r20165
13:22:20  <planetmaker> hm... though... hm... it's not exactly the same
13:23:56  <planetmaker> and I don't understand the difference really which michi_cc makes... :
13:24:56  <planetmaker> both is called 'has_power'. But the new one doesn't care whether the vehicle has power on that railtype
13:25:18  <Alberth> planetmaker: I thought you fixed the name of the nml tool. Why is the issue still open?
13:25:36  <planetmaker> hm. It should be closed
13:25:49  <planetmaker> Probably I used the wrong 'keyword' in the commit message
13:26:42  <Alberth> nothing like a bit of AC/DC to wake up the neighbours :D
13:26:52  <planetmaker> closed
13:26:57  <planetmaker> :-D
13:27:02  <Alberth> ok, thank you
13:27:12  <Brot6> NewGRF Meta Language - Patch #1040: name of the main script (planetmaker) @
13:27:12  <Brot6> NewGRF Meta Language - Patch #1040 (Closed): name of the main script (planetmaker) @
13:53:20  <Hirundo> I think I understand the principle of newstations now
13:53:23  <Hirundo>
13:55:49  <Hirundo> Now, to think of a nice abstraction......
13:56:07  <planetmaker> nice...
13:56:38  <planetmaker> include airport tiles in that. They're like industry tiles afaik
13:56:57  <planetmaker> (and already implemented in nml)
13:57:12  <Hirundo> airport and object tiles are industry tiles, yes
14:09:52  <Hirundo> It's a pity that there isn
14:10:16  <Hirundo> 't a bitmask of present (waiting) cargo types available for stations
14:10:39  <Hirundo> (apostrophe and enter are too close together)
15:16:57  <planetmaker> frosch123: re fs 3957: can I do without var FE then?
15:17:23  <planetmaker> I'm wondering whether both need to be exposed to the user in NML
15:19:10  <frosch123> The values of the flags in FE can be deduced from 4A and your own action0 stuff.
15:19:52  <frosch123> FE is also a bit weird currently, it is not really newrailtypes aware
15:20:30  <planetmaker> hm...
15:20:50  <planetmaker> :-D "_new_railtypes" ? ;-)
15:21:04  <frosch123> <- does that make sense?
15:22:55  <planetmaker> hm... I think so
15:23:40  <planetmaker> there's no point to return "powered" directly as the author sets it anyway, right?
15:24:21  <frosch123> you can get it by oring bit 5 and 6
15:24:29  <frosch123> if you need it :)
15:25:15  <planetmaker> well. Sure. But that's why I'm asking: if the basic 'properties' are "powered" and "has_power" it'd make more sense to work with those
15:25:38  <planetmaker> where has_power is the same as bit5
15:26:02  <frosch123> but that changes the behaviour?
15:26:08  <planetmaker> yes, I know
15:26:32  <planetmaker> Not overwriting existing behaviour. But possibly using bit 7 for that or so
15:26:43  <frosch123> i guess ttdp swaps those bits when crossing electric<->normal rail
15:27:19  <frosch123> adding new stuff to 80+ variables is ttdp stuff :)
15:27:52  <planetmaker> :-)
15:28:03  <planetmaker> then bit2 of var 4A :-P
15:28:10  <planetmaker> bit9
15:28:19  <frosch123> var4a shall be about railtypes only
15:28:39  <frosch123> e.g. we wondered about exposing the "has_catenary" flag
15:28:39  <planetmaker> makes sense :-)
15:29:19  <planetmaker> that makes sense for pantograph things. But then... has_power is better there
15:29:44  <planetmaker> hm... though it'd allow for dual-powered engines then
15:29:57  <frosch123> likely, but it is all about the weirdness of poweredness grfauthor will come up with :p
15:30:52  <planetmaker> over-rated ;-)
15:31:33  <planetmaker> But I'll argue differently, if I'd write a train newgrf, probably :-P
15:32:19  <planetmaker> Though... newgrf bridges would be personally higher prioritized than further train features
15:32:25  <planetmaker> same with road types
15:32:42  <planetmaker> and new fields :-P
15:34:41  <planetmaker> back to topic: var FE changes look sensible to me
15:35:42  <planetmaker> now I'd just like good catchy names for those two bits so that they can get a proper name in nml
15:35:52  <planetmaker> and also for bit8 of var 4A.
15:36:26  <planetmaker> that one actually knows by the name what they do... I fail to come up with something which is not as long as this whole sentence I'm writing here blabla
15:36:52  <frosch123> potentially_powered, powered, not_powered
15:37:19  <planetmaker> :-) sounds not bad :-)
15:40:47  <Brot6> #openttdcoop Client Patch Pack - Revision 5:9005c0c54950: Fix: guard for trunk StationGUI was mis... (Ammler) @
15:52:03  <Ammler> <-- how comes, those offsets are so out?
15:52:13  <Ammler> don't you use -c for firs?
15:54:45  <Ammler> tile sprites ususally have -31 0
15:56:55  <frosch123> 0->-54 is no surprise, it is no flat tile
15:57:51  <Rubidium> and the -31 -> -22 isn't that odd as it's not a full tile wide either
15:58:52  <Rubidium> just take a look at the left top and the amount of pixels that is right of the tile's edge
15:58:56  <Ammler> oh indeed
15:59:09  <Ammler> 0 is for flats
16:00:05  <Ammler> Rubidium: you think, is worth a release?
16:01:30  <Rubidium> you're better of fixing some more bugs first
16:01:47  <Rubidium> (we're not releasing a new version for each bugfix either)
16:03:01  <Ammler> #1073 could maybe also be "fixed" by openttd?
16:03:20  <Ammler> not that I like to blame you :-P
16:03:44  <frosch123> does it happen with non-sprite fonts?
16:04:26  <Ammler> frosch123: any progress on the income-etc. issue
16:04:30  <Ammler> icon*
16:04:57  <frosch123> i am waiting for someone to draw a broken coin
16:06:10  <Ammler> fixed #942 :-)
16:07:19  <Ammler> Rubidium: I meant, because of the upcoming openttd release
16:07:46  <Rubidium> you don't have to release each time OpenTTD releases
16:07:57  <Rubidium> there's no new sprites or something
16:12:42  <Ammler> nvm, it is just quite ugly since I know it :-)
16:17:20  <Brot6> OpenGFX - Bug #658: no company colour for building (Ammler) @
16:19:36  <Brot6> heqs: update from r354 to r355 done (1 errors) -
16:20:49  <Brot6> newgrf_makefile: update from r123 to r124 done -
16:21:00  <Ammler> <-- what does cause those bridge glitches?
16:22:20  <Rubidium> what glitch?
16:22:25  <Brot6> nml: update from r555 to r559 done -
16:23:48  <Brot6> ogfxplus: update from r39 to r40 done -
16:24:48  <frosch123> looks like the rearpart is missing. iirc it should be included in the bridgefloor sprite
16:24:59  <Ammler> <-- bridges without backwall
16:25:16  <Rubidium> then what frosch123 said; probably wrong order of sprites or something
16:25:55  <frosch123> i do not see a spriteorder problem. to me it looks like the backwall was just not drawn :)
16:25:57  <Brot6> opengfx: update from r466 to r467 done -
16:26:32  <frosch123> Ammler: what are the sourcesprites of that bridge?
16:27:18  <Brot6> OpenGFX - Bug #379 (Closed): OPEN TTD title misaligned (Ammler) @
16:27:37  <Brot6> swedishrails: update from r139 to r140 done -
16:27:39  <Brot6> Following repos didn't need a nightlies update: 2cctrainset (r573), 32bpp-extra (r36), airportsplus (r52), bros (r12), comic-houses (r70), firs (r1074), fish (r386), grfcodec (r169), nforenum (r377), nmts (r16), nutracks (r86), openmsx (r90), opensfx (r96), snowlinemod (r15), worldairlinersset (r655)
16:30:31  <Brot6> OpenGFX - Bug #605 (Closed): make bundle in a subdir (Ammler) @
16:30:31  <Brot6> OpenGFX - Bug #658: no company colour for building (planetmaker) @
16:31:31  <Ammler> planetmaker: I would move that to a "feature" then
16:32:05  <planetmaker> Whatever
16:32:23  <planetmaker> Bug or feature... it's quite close by in that case :-)
16:34:01  <Ammler> planetmaker: also #878 looks like a issue with narrow gauge, can you reproduce with opengfx only?
16:35:00  <frosch123> ah, so the narrow gauge sets replaces those sprites
16:35:36  <frosch123> then it is not a bug of ogfx, just the narrow gauge set does not use railoverlays, but replaces the bridgesprites
16:36:40  <planetmaker> oh... if that's the case... yes. I was not aware when I posted that that there's a rail grf active. And a bad one :-P
16:36:45  <frosch123> now that you mention it, you can even recognise the start of the usual tubular birdge on the left of the bridge
16:38:01  <Ammler> feel free to reject the ticket :-)
16:38:09  <planetmaker> :-)
16:38:20  <planetmaker> we should ban non-railtypes rail newgrfs ;-)
16:39:10  <Ammler> I guess, then there is no fixeable bug left
16:39:29  <Ammler>
16:39:29  <planetmaker> :-)
16:40:49  <planetmaker> issue 922 can be closed, too?
16:40:56  <planetmaker>
16:41:10  <Brot6> OpenGFX - Bug #878 (Rejected): bridges without backwall? (planetmaker) @
16:43:30  <Brot6> OpenGFX - Feature #922 (Closed): menu bar: save/load and statistics (Ammler) @
16:43:53  <planetmaker> hm... #840 would be VERY nice... :S
16:44:27  <planetmaker> what about #903? Hm...
16:44:59  <Ammler> #840 is alternative, no real improvement, why you think, it is so important?
16:45:19  <Ammler> maybe it should become a newgrf
16:45:57  <Ammler> we use mb pantographs now?
16:46:38  <Ammler> oh
16:46:41  <Ammler> drive on left
16:47:00  <Ammler> we could Action9 those?
16:48:42  <Ammler> 3B	signalsontrafficside
16:48:58  <Ammler> do the ttdp flags all work in openttd too?
16:50:57  <frosch123> that one works
16:51:46  <Ammler> or var 86
16:52:01  <frosch123> usually all of them work, but some are a bit tricky, like the ttdp monorail/maglev/electic flags
16:52:32  <frosch123> var 86 and signalontrafficside are two different things
16:52:41  <Ammler> what does the flag?
16:53:07  <frosch123> var 86 defines the roaddriving side
16:53:17  <frosch123> the flag inverts that for signals
16:53:29  <frosch123> so to get the signalside you need both :p
16:53:41  <frosch123> else it would be too easy
16:53:47  <Ammler> :-P
16:54:14  <Ammler> well, here (CH), cars drive right, trains left
16:54:16  <frosch123> 	bool side = (_settings_game.vehicle.road_side != 0) &&; <- hmm, maybe i am wrong
16:54:21  <frosch123> it is even more weird
16:55:40  <frosch123> is that a ttdp or only a ottd fail?
16:56:23  <Ammler> @man road_side
16:56:25  <Webster> Search results - OpenTTD -
16:56:56  <Ammler> 0=left, 1=right?
16:58:23  <frosch123> 	Road traffic side: bit 4 clear=left, set=right
16:58:26  <Ammler> [18:58] <PublicServer> Ammler: vehicle.road_side = 1
16:58:28  <Ammler> [18:58] <PublicServer> Ammler: construction.signal_side = on
16:58:59  <Ammler> if signal_side would be off, the signals would be left of tracks?
16:59:18  <frosch123> hmm, let me guess: in ttd signal were always on the left, independent of driving side?
16:59:36  <frosch123> Ammler: that's what i am wondering :)
16:59:45  <frosch123> i thought they would be opposite or so
17:00:26  <Ammler> in openttd, it is that way
17:00:34  <Ammler> off=left, on=right
17:01:40  <Ammler> so CH settings is road_side=1 and signal_side=off
17:01:47  <Ammler> de uses on
17:03:05  <Ammler> then your formula seems correct
17:04:16  <frosch123> well, just another deprecated useless ttd-compatibility setting...
17:06:09  <Ammler> :-)
17:06:29  <Ammler> yes, there should be a simple rail_side
17:07:04  <Rubidium> it would "still" be another way of writing the current thing down
17:08:10  <Ammler> now, road and rail is linked, which is a bit silly
17:08:37  <Ammler> hmm, maybe that is just the view from CH :-)
17:09:06  <frosch123> well, you cannot configure road on left, and signals on right :)
17:09:17  <Ammler> of course you can
17:09:32  <frosch123> i can?
17:09:43  <Ammler> maybe you can't, I can :-)
17:10:55  <Ammler> He, I can't either :-P
17:11:17  <frosch123> there are two ways to archieve road on left and signals on left :)
17:11:46  <Ammler> I would consider that as bug
17:12:13  <Ammler> do you care, what ttdp does?
17:12:28  <frosch123> that is what i wondered :) and then concluded that it is designed to behave as "another deprecated useless ttd-compatibility setting"
17:13:03  <Ammler> now, I see, why
17:13:48  <Ammler> ttdp might be more realistic related
17:13:57  <Ammler> maybe there is no such situation on the world?
17:14:39  <Ammler> hmm, also trains could drive right but still have signals left
17:18:51  <frosch123> looks like ttdp enfoces "signals on drive side" on when using newsignals ...
17:28:53  *** welshdragon has quit IRC
17:45:23  <Brot6> UKRS 2 Add-ons - Revision 7:5850188b6402: Feature: lumber load sprites for speedlink open wagon (andythenorth) @
17:45:23  <Brot6> UKRS 2 Add-ons - Revision 8:f3c91b3b241f: Feature: wood load sprites for speedlink open wagon (andythenorth) @
17:45:24  <Brot6> UKRS 2 Add-ons - Revision 9:28a125e186de: Feature: metal load sprites for speedlink open wagon (andythenorth) @
17:45:25  <Brot6> UKRS 2 Add-ons - Revision 10:5eb3d8457e68: Change: reworked layout for tipplers (andythenorth) @
17:45:31  <Brot6> UKRS 2 Add-ons - Revision 11:2eaea80dc5db: Feature: load sprites for Tippler (andythenorth) @
17:45:35  <Brot6> UKRS 2 Add-ons - Revision 12:60676f8de7b9: Fix: scrap wagon interior shading was wrong (andythenorth) @
17:45:39  <Brot6> UKRS 2 Add-ons - Revision 13:fb9478175fa6: Change: export Tippler sprites (andythenorth) @
17:45:43  <Brot6> UKRS 2 Add-ons - Revision 14:4464473b0177: Change: export Speedlink open sprites (andythenorth) @
17:55:07  *** welshdragon has joined #openttdcoop.devzone
17:56:24  <planetmaker> [18:58]	<frosch123>	 Road traffic side: bit 4 clear=left, set=right  <-- that one works for road traffic for sure
17:56:50  <frosch123> noone questioned that :)
17:57:06  <Ammler> construction.signal_side is the switch in question :-)
17:57:34  <frosch123> actually everything works as intended, just you might question the intentions :)
17:58:00  <planetmaker> hehehe :-)
17:58:03  <Rubidium> all hail Chris and his wise intentions! :)
19:44:54  <Brot6> UKRS 2 Add-ons - Revision 15:990e94637c5e: Add: license file (andythenorth) @
19:50:36  <Ammler> andythenorth: he, did pikka agree to use gpl?
19:51:17  <Ammler> would rock :-)
19:59:46  <planetmaker> Ammler: it's 'only' his sprites
19:59:51  <planetmaker> not the whole thing
20:01:55  <Ammler> hmm, the category newgrf might be wrong place?
20:02:07  <Ammler> then*
20:03:17  <Ammler> maybe we should create a project andythenorth, where he can manage such projects?
20:04:14  <Ammler> planetmaker: also feel free to update the frontpage :-)
20:04:27  <Ammler> <-- Favorites
20:09:30  *** Alberth has left #openttdcoop.devzone
20:10:08  <planetmaker> :-)
20:13:56  <planetmaker> you mean like that? ;-)
20:14:57  <Ammler> yeah :-)
21:30:49  <Brot6> #openttdcoop Client Patch Pack - Revision 6:15045c6a6ee5: Added tag 1.0 for changeset e34ecad2e248 (Ammler) @
21:50:39  <Rubidium> planetmaker: can you reproduce grfcodec's version.h issue?
21:50:59  <Rubidium> as it's quite impossible to trigger it as far as I can see
21:51:35  <Rubidium> grfcodec.o.d says that grfcodec.o depends on version.h, so make has to make version.h before it can even start compiling
21:52:56  <Rubidium> unless you've enabled NO_MAKEFILE_DEP ofcourse
21:58:21  <Brot6> GRFCodec - Bug #1097: version.h is not built automatically (race condition?) (Rubidium) @
22:02:29  <planetmaker> Rubidium: that was what I got after a fresh clone of the repos
22:04:41  <Brot6> GRFCodec - Revision 170:a8ef224ee34c: Add #1096: support for finding boost out of the box when in... (Rubidium) @
22:04:42  <Rubidium> then you might have NO_MAKEFILE_DEP set globally or so
22:04:51  <Rubidium> what does grfcodec.o.d say?
22:05:39  <Rubidium> s/say/contain/
22:08:22  <Brot6> GRFCodec - Bug #1097: version.h is not built automatically (race condition?) (planetmaker) @
22:09:29  <planetmaker> grfcodec.o: getopt.h pcxfile.h typesize.h file.h sprites.h \
22:09:31  <planetmaker>   pcxsprit.h ttdpal.h grfcomm.h info.h nfosprite.h allocarray.h error.h \
22:09:32  <planetmaker>   version.h conv.h
22:09:45  <Brot6> NFORenum - Revision 378:0035c82a941e: Add #1098: support for finding boost out of the box when in... (Rubidium) @
22:09:45  <Brot6> NFORenum - Bug #1098 (Closed): building on OSX can fail (boost path) (Rubidium) @
22:10:49  <Rubidium> planetmaker: seriously... your make is broken
22:11:15  <Rubidium> or NO_MAKEFILE_DEP is defined, but then the .o.d files would not be created
22:11:16  <planetmaker> that's make 3.81
22:11:33  <planetmaker> *gnu make
22:11:59  <Brot6> GRFCodec - Bug #1096 (Closed): building on OSX can fail (boost path) (Rubidium) @
22:12:59  <Rubidium> okay, make mrproper && hg st -i | xargs rm && make -d (output of the last)
22:15:34  <Ammler> hg purge -a
22:18:04  <planetmaker> <-- Rubidium
22:18:23  <Brot6> GRFCodec - Bug #1097: version.h is not built automatically (race condition?) (planetmaker) @
22:23:51  <Rubidium> planetmaker: that log really tells me that it hasn't added version.h to grfcodec.o.d
22:23:57  <Rubidium> and for me it adds it
22:25:13  <Rubidium> is there a version.h in /usr/include ?
22:25:51  <planetmaker> yes
22:26:18  <Rubidium> then GCC is being *stupid*
22:27:06  <Rubidium> as it thinks "version.h" is the one from /usr/include and doesn't add it to the dependencies
22:27:20  <planetmaker> hm... *now* after this run version.h is NOT in grfcodec.o.d
22:27:35  <planetmaker> but yeah
22:27:37  <Rubidium> yes, because you didn't create version.h yet
22:27:56  <planetmaker> let's see what happens, if I rename version.h in /usr/include
22:29:39  <planetmaker> now grfcodec.o.d contains it
22:30:55  <planetmaker> peculiar
22:31:23  <planetmaker> but a good find
22:33:04  <Rubidium> <- does that help?
22:38:23  <planetmaker> Yes, that helps
22:41:04  <Brot6> GRFCodec - Revision 171:f8e9a3e763cd: Fix #1097: on some installations a version.h exists in /usr... (Rubidium) @
22:41:04  <Brot6> GRFCodec - Bug #1097 (Closed): version.h is not built automatically (race condition?) (Rubidium) @
22:42:27  <Brot6> NFORenum - Revision 379:1fde6f8f8768: Fix: on some installations a version.h exists in /usr/inclu... (Rubidium) @
22:45:16  <planetmaker> and it's "only" version.h from another game's sdk...
22:45:33  <planetmaker> stupid stupid... never use generic names ;-)
22:46:14  *** Frankr has joined #openttdcoop.devzone
22:48:31  * Rubidium wonders whether hg archive can be tricked to inject a modified file
22:49:35  *** Seberoth2 has joined #openttdcoop.devzone
22:52:32  <Ammler> well, you could use a patch :-)
22:52:47  *** Seberoth2 has quit IRC
22:52:56  <Ammler> hg qpush ; hg archive ; hg qpop
22:54:15  <Ammler> well, since hg only has a .hg in root, it is also easy to use conventional packers
22:57:24  *** Seberoth has quit IRC
23:05:25  <Brot6> NFORenum - Revision 380:dbc4e5f98b8e: Change: use .tar.gz for the source archive (Rubidium) @
23:05:25  <Brot6> GRFCodec - Revision 172:ced0b9d35d64: Change: use .tar.gz for the source archive (Rubidium) @
23:07:31  <Brot6> GRFCodec - Code Review #1095 (Closed): .tgz -> tar.gz (Rubidium) @
23:27:04  <Brot6> GRFCodec - Revision 173:c0dff86bab61: Change: make source bundling preserve the versioning (Rubidium) @
23:29:14  <Brot6> NFORenum - Revision 381:1722fb9798aa: Change: make source bundling preserve the versioning (Rubidium) @
23:29:14  <Brot6> GRFCodec - Feature #1082 (Closed): Makefile target bundle_src (Rubidium) @
23:29:32  * Rubidium hopes everything still works :)
23:43:28  *** KenjiE20 has quit IRC

Powered by YARRSTE version: svn-trunk