Log for #openttdcoop.devzone on 5th August 2011:
Times are UTC Toggle Colours
01:18:37  *** Terkhen has quit IRC
01:19:04  *** Terkhen has joined #openttdcoop.devzone
01:31:38  <Brot6> Central European Train Set - Feature #2763: track classes / railtype support (Eddi) @
04:36:57  *** andythenorth has joined #openttdcoop.devzone
07:34:35  *** andythenorth is now known as Guest4810
07:34:36  *** andythenorth has joined #openttdcoop.devzone
07:35:27  *** andythenorth is now known as Guest4811
07:35:27  *** andythenorth has joined #openttdcoop.devzone
07:36:24  *** andythenorth is now known as Guest4812
07:36:25  *** andythenorth has joined #openttdcoop.devzone
07:37:42  *** andythenorth is now known as Guest4813
07:37:42  *** andythenorth has joined #openttdcoop.devzone
08:24:19  *** bodis has joined #openttdcoop.devzone
09:54:49  *** andythenorth has quit IRC
10:52:04  <Brot6> NewGRF Meta Language - Revision 1572:aeed6f6d6d80: Add: Helper functions + documentation about 1c... (Hirundo) @
11:02:36  *** FooBar has joined #openttdcoop.devzone
11:13:53  <Brot6> Central European Train Set - Feature #2763: track classes / railtype support (michi_cc) @
11:22:36  <Brot6> OpenGFX+ Landscape - Revision 72:f0cda355467f: Codechange: Make use of the new callback syntax fo... (planetmaker) @
11:31:33  <Brot6> OpenGFX+ Landscape - Revision 73:e4262aa8fedd: Codechange: Make use of the new callback syntax fo... (planetmaker) @
12:01:16  <planetmaker> <-- does that somewhat make sense, Hirundo ?
12:23:27  <Brot6> OpenGFX - Code Review #2103 (Closed): Redrawn Sampson U52 (foobar) @
12:23:27  <Brot6> OpenGFX - Revision 694:0d10d3b29070: Feature (closes #2103): revised Sampson U52 airplane (DanMacK) (foobar) @
12:24:39  <planetmaker> hm... NML complains about parameters not yet supported for sprite layouts, but it does accept LOAD_TEMP(...) in it
12:25:39  <Hirundo> indeed, parameters work in the syntax but nowhere else
12:27:03  <planetmaker> what will happen, if I use  LOAD_TEMP(0) in the layout?
12:27:11  <planetmaker> it accepts that
12:27:35  <planetmaker> and if it's the same as in the previous switch expression (is it?) then it's equivalent
12:27:50  <Hirundo> yes
12:28:02  <Hirundo> perhaps even putting an array in the layout will work
12:28:08  <Hirundo> or perhaps not ... :)
12:28:18  <planetmaker>
12:28:32  <planetmaker> ^ so you think that'll work (it compiles ok)?
12:28:45  <planetmaker> it'd reduce some cpp preprocessing A LOT
12:29:34  <Hirundo> There's a copy paste error, slope 23 is handled twice
12:29:40  <planetmaker> oh, thanks :-)
12:29:45  <Hirundo> there are constants for those slopes now, btw
12:30:12  <Hirundo> Apart from that it should work, this is what ASL are designed for :P
12:30:12  <planetmaker> hm, also true :-)
12:30:26  <planetmaker> yep, but there's so far no single example anywhere.
12:30:29  <planetmaker> And ... I need it
12:30:57  <planetmaker> So I'll tidy it up a bit and I guess it can act as example in NML docs, too
12:31:16  *** andythenorth has joined #openttdcoop.devzone
12:31:26  <Hirundo> Is it a fully functional object?
12:31:42  <planetmaker> yes
12:31:51  <planetmaker> it's the re-implementation of company land
12:32:02  <Hirundo> great :)
12:32:21  <planetmaker> check out existing opengfx+landscape - it has that already. But... the old way
12:32:28  <planetmaker> and this cuts code by 50% or so
12:32:59  <planetmaker> and eventually it'll allow me to use fences rather than colour borders ;-)
12:33:20  <planetmaker> and I need it for FIRS ;-)
12:33:24  <andythenorth> mmm
12:33:25  <andythenorth> FIRS
12:33:48  <planetmaker> so that I now figured out adv. tile layouts in NML... it shall reduce FIRS' code size, too ;-)
12:34:13  <andythenorth> awesomes
12:34:15  <planetmaker> <-- andythenorth , that's how it works
12:34:33  <planetmaker> it's an object, but... tile layout-wise it's the same as industries
12:34:39  <andythenorth> the previous nfo+cpp method was 'correct' from a simplicity p.o.v. but verbose
12:34:39  <planetmaker> s/tile/sprite/g
12:36:02  <Hirundo> why are there 3 sprites in the layout?
12:36:31  <planetmaker> the colour border only shows in transparent view and is in normal view again superimposed by the ground sprite
12:36:42  <planetmaker> thus: ground -> border -> ground
12:36:43  <planetmaker> ;-)
12:37:09  <planetmaker> might be a bit stupid...
12:37:39  <planetmaker> one could checkout transparency directly, I guess. But this way it has the side-effect that there's an automatic colour translation to transparency as well which darkens the ground tiles
12:37:40  <Brot6> OpenGFX - Code Review #2104 (Closed): New Sprites for Bakewell Cotswald LB-3 (foobar) @
12:37:40  <Brot6> OpenGFX - Revision 695:e17fbd94f600: Feature (closes #2104): revised Bakewell Cotswald LB-3 airpl... (foobar) @
12:37:47  <Hirundo> I'm not sure if there's another way
12:38:25  <Hirundo> IIRC, access to transparency info is not in OpenTTD for anti-desync reasons
12:38:58  <planetmaker> indeed, it must not be there
12:39:30  <planetmaker> well, even, if. This method works quite well for me :-)
12:39:35  <Hirundo> Such things would need documentation, though
12:39:41  <Hirundo> (comments)
12:40:37  <planetmaker> :-)
12:40:43  <planetmaker> you're probably right
12:41:45  <Hirundo> I found that it really helps, btw, to maintain a list of missing / incorrect stuff (often documentation) as you go
12:42:55  <andythenorth> planetmaker: that tile code - I can't read nml yet, but I'm convinced it's simpler :)
12:42:59  <Hirundo> It makes for easy and useful commits afterwards
12:44:18  <planetmaker> Hirundo, of course. You don't have to convince me of the usefulness of documentation. But it needs sometimes a prod - as it's not always obvious when one just wrote something
12:44:36  <planetmaker> So: thank you :-)
12:49:42  <planetmaker> Hirundo, if I don't define the temp variables like I do in the paste with the purchase branch: what will be the result of LOAD_TEMP(...) ?
12:49:44  <planetmaker> 0?
12:49:51  <planetmaker> or rather undefined?
12:50:16  <Hirundo> in principle undefined, although they're zeroed by openttd to prevent desyncs
12:51:01  <planetmaker> I guess I must not rely on that then
12:51:39  <Hirundo> no, certainly not in example code :)
12:51:50  <planetmaker> :-)
12:56:18  <Brot6> OpenGFX - Revision 696:2eb2fe897d6e: Feature (closes #2105): revised Coleman Count airplane (DanM... (foobar) @
12:56:18  <Brot6> OpenGFX - Code Review #2105 (Closed): New Coleman Count Sprite (foobar) @
13:09:38  <Brot6> OpenGFX - Code Review #2106 (Closed): New Sprites for Yate Haugan (foobar) @
13:09:38  <Brot6> OpenGFX - Revision 697:cf9d66744012: Feature (closes #2106): revised Yate Haugan airplane (DanMacK) (foobar) @
13:11:06  <planetmaker> <-- Hirundo does it work that way for you?
13:11:56  <planetmaker> I'd only remove the copyright header and add a lang file and a grf declaration and then add it as example
13:12:15  <planetmaker> (and cut a few relevant code lines into the docs, too)
13:15:06  <Hirundo> planetmaker: I don't really get the transparency darkening, why is that useful?
13:15:29  <Hirundo> Normal ground sprites aren't recoloured either in transparent mode
13:15:43  <planetmaker> well, it's an object after all
13:15:48  <planetmaker> we want to see it clearly :-)
13:17:13  <planetmaker> also it's the only way I found really to show the normal tile (thus an invisible object) when I draw the ground tile as last sprite (again)
13:17:20  <planetmaker> I want it to be invisible without transparency
13:17:32  <planetmaker> invisible as in "looks like all other terrain"
13:17:50  <planetmaker> I could still add trees and stuff as a random thingy ;-)
13:17:58  <planetmaker> but that's for later.. and not the example :-P
13:18:43  <planetmaker> hm... check adjacent tiles... and choose random look according to that ;-)
13:19:07  <Hirundo> so in transparent mode, you get to see the cc frame, but with the transparent recolouring applied
13:19:26  <planetmaker> yes
13:19:42  <planetmaker> applies to the overlying groundtile
13:19:49  <planetmaker> thus the whole thing just gets a bit darker
13:20:13  <planetmaker> just check it out ingame... grab it from bananas and buy company land :-)
13:20:26  <planetmaker> well... build object-company land ;-)
13:20:35  <planetmaker> I unfortunately cannot change the real company land
13:22:03  <Hirundo> the NML looks fine, can't test w/o graphics though
13:22:40  <planetmaker> Hirundo, it's a bananified newgrf
13:22:49  <planetmaker> this is just a codechange :-)
13:23:38  <planetmaker> otherwise grab ogfx+landscape and replace the company_land.pnml file with the paste
13:24:12  <planetmaker> hm.. . banananified... I start to like that word :-P
13:24:58  <planetmaker> <-- that should surely have it ;-)
13:30:03  <Brot6> NewGRF Meta Language - Feature Request #2929 (New): More detailed error location (Eddi) @
13:38:14  <Brot6> OpenGFX+ Landscape - Revision 74:62976f4016ab: Codechange: Use advanced sprite layout for the com... (planetmaker) @
14:00:14  <Brot6> NewGRF Meta Language - Revision 1573:11cbe9be4c07: Add: Example for NewObject (planetmaker) @
14:00:59  *** andythenorth has quit IRC
14:17:32  *** andythenorth has joined #openttdcoop.devzone
14:20:21  <Brot6> NewGRF Meta Language - Revision 1574:e4e7f8150793: Doc: Add a brief example on parameter and vari... (planetmaker) @
14:35:48  <Brot6> OpenGFX - Revision 698:818a4020ebe2: Doc: update credits for rail vehicles (foobar) @
14:35:48  <Brot6> OpenGFX - Revision 699:63ce08d49cfe: Codechange: rename some more files to clarify their status (foobar) @
14:40:47  <planetmaker> FooBar, the gfx filenames which end in _88 indicate that those are vehicles with 8/8 length - and have 8 views
14:41:16  <FooBar> yes, I figured something like that
14:41:39  <planetmaker> I just thought I mention it :-)
14:41:46  <FooBar> thanks :)
14:41:56  <FooBar> I only renamed the files that I added recently and gave a bad name
14:42:12  <planetmaker> yeah, no worries
14:43:03  <FooBar> by the way, is there a script or something that can tell which versioned files are not used by the source any more
14:43:50  <FooBar> I'm thinking of removing png files that aren't used any more. If you for some reason want the old version, you can update to an older revision
14:44:14  <planetmaker> the answer is a clear 'yes' and 'no' concurrently
14:44:22  <planetmaker> IIRC I have such script at home
14:44:36  <planetmaker> there are a number of unused png files meanwhile
14:44:48  <FooBar> I figured it involves somehow comparing the dep check to the list of files that are in the repo
14:45:01  <planetmaker> hg st -A to all png files
14:45:14  <planetmaker> which are included in the dep check. yes
14:45:37  <planetmaker> remind me tomorrow or so again, should I forget
14:45:49  <planetmaker> I won't have time today to search for it
14:45:55  <FooBar> ok, that is fine
14:46:03  <FooBar> I'll try to remember it :P
14:46:52  <Hirundo> planetmaker: You did a bit too much copy and paste in the header comment :)
14:47:54  * planetmaker looks
14:48:51  <Hirundo> "In this case a train is coded, other vehicle types work in a similar fashion." <- really ;) ?
14:49:11  <planetmaker> hm... I recall editing that out...
14:51:50  <Hirundo> it's still there on the 2nd line
14:53:07  <Hirundo> Is the fact that GROUNDSPRITE_NORMAL+x can be used for slope sprites documented anywhere?
14:53:08  <planetmaker> yeah, I see that :S
14:53:29  <planetmaker> you mean... the parameter usage in spritelayouts?
14:53:39  <planetmaker> it's now documented in that section ;-)
14:54:11  <planetmaker> the commit following the example grf
14:55:50  <Hirundo> I mean that GROUNDSPRITE_NORMAL is documented to be the normal ground sprite
14:56:02  <Brot6> OpenGFX - Code Review #2108 (Closed): New Sprites for FFPDart (foobar) @
14:56:02  <Brot6> OpenGFX - Revision 700:8ad39bd21525: Feature (closes #2108): revised FFP Dart etc. airplane (DanM... (foobar) @
14:56:30  <Hirundo> but GROUNDSPRITE_NORMAL+1 is afaik not documented to be the ground sprite for SLOPE_X
14:57:47  <Hirundo> hmm... we need SlopeToSpriteOffset(slope) in NML
15:00:29  <planetmaker> :-)
15:00:36  <planetmaker> That might be a nice function indeed
15:00:45  <planetmaker> and immediately obsoletes the code I wrote today :-P
15:01:09  <Brot6> NewGRF Meta Language - Revision 1575:28b704c24751: Fix: Remove trailing white spaces and fix some... (planetmaker) @
15:03:07  <Brot6> OpenGFX - Code Review #2109 (Closed): New Sprites for Bakewell Luckett LB-8, Yate Aerospace YAe46 (foobar) @
15:03:07  <Brot6> OpenGFX - Revision 701:a449d837da51: Doc: update credits for aircraft (closes #2109) (foobar) @
15:05:19  <planetmaker> :-) Nice to see this progress, FooBar :-)
15:05:43  <FooBar> It's the least I can do
15:06:02  <FooBar> Well, the least I can do is nothing, but DanMacK's sprites have been sitting there for over half a year
15:06:43  <planetmaker> yes... did you check for CC problems?
15:07:07  <FooBar> yes and no
15:07:20  <planetmaker> and I was hesitant due to mixed feedback. But... actually I'm quite glad to have it move this direction :-)
15:07:34  <FooBar> I check each plane ingame, but unfortunately the game gave me blue as company colour and I didn't notice that
15:07:56  <FooBar> I did check the trains though and had to run a "blue to cc" action a couple of time
15:08:02  <planetmaker> :-) That's how the train sprite errors ended up in OpenGFX which you fixed earlier ;-)
15:08:16  <planetmaker> ^^ exactly those
15:08:26  * FooBar changes company colour
15:08:57  <FooBar> the airplanes seem to be ok in the purchase menu
15:09:10  <FooBar> now to buy them and let them fly around a bit
15:09:11  <Brot6> Central European Train Set - Revision 119:23c2b0238d7e: use gfx template for 8lu vehicle (Eddi) @
15:09:11  <Brot6> Central European Train Set - Revision 120:f2c8a5651e5a: always round up in template calculations (Eddi) @
15:09:11  <Brot6> Central European Train Set - Revision 121:393dbadb2e8b: use gfx template for 6lu vehicle (Eddi) @
15:09:13  <Brot6> Central European Train Set - Revision 122:d0a02db5bc26: use gfx template for 4lu vehicle (Eddi) @
15:09:17  <Brot6> Central European Train Set - Revision 123:46adf2bbb931: use gfx template for 10lu vehicle (Eddi) @
15:09:21  <Brot6> Central European Train Set - Revision 124:a1741672bd5f: use gfx template for 12lu vehicle (Eddi) @
15:09:25  <Brot6> Central European Train Set - Revision 125:7dc0cd791c15: use gfx template for 16lu vehicle (Eddi) @
15:09:49  <planetmaker> hm... I have a few test games... at home :-P
15:10:01  * planetmaker goes home
15:10:45  <FooBar> it's not too much work to check the planes. Many different planes, but a lot use the same sprites
15:11:17  <FooBar> I did have to replace a lot of pure white occasions
15:11:39  <planetmaker> yes... that was also necessary indeed
15:11:50  <planetmaker> What needs checking and is a bit of a bitch is the alignment
15:12:12  <planetmaker> That they still land properly on the runway, don't overshoot each direction and stop properly at the gates
15:12:16  <FooBar> I've found that offset = round.down(-size/2)
15:12:23  <planetmaker> that's what I found, too
15:12:26  <FooBar> puts the planes dead center in the bounding box
15:12:29  <planetmaker> at least as guide
15:13:01  <FooBar> Thing is that bounding boxes don't follow the center of the runway and taxiways though
15:13:42  <Brot6> Central European Train Set - Revision 126:48ea92628810: remove unused code (Eddi) @
15:13:54  <planetmaker> Well... that's what the offsets are for, aren't they?
15:14:10  <FooBar> yes and no
15:14:33  <FooBar> if the game draws the vehicle in the wrong place, should that be fixed in the game or should the bounding boxes be modified?
15:15:08  <FooBar> bounding boxes = offsets
15:15:45  <FooBar> I'd leave them in the center of the bounding box at this point and await NewAirports
15:16:06  <planetmaker> :-)
15:16:16  <FooBar> maybe that will draw the sprites in a different position and then you can do the fix all over again
15:16:44  <FooBar> I wonder what original ttd did actually...
15:17:36  <FooBar> Either way, once all planes are aligned in their box they can be mass shifted a bit lower where necessary, with the same modifications for each plane
15:19:02  <planetmaker> I'm not sure... IMHO the (virtual) centre of mass might be the thing to move on the centre of tiles and not the centre of the sprites - though it often is about the same - but it varies a bit between different views
15:21:56  <FooBar> TTD appears to be aligned pretty much the same, in general only 1 px lower
15:23:42  <FooBar> it's probably fine if I do that as well. Seems to be ok for the purchase menu as well
15:24:07  <planetmaker> well, yes then
15:31:48  *** Lakie has joined #openttdcoop.devzone
15:34:47  *** bodis has quit IRC
15:37:42  <Brot6> OpenGFX - Code Review #2110 (Closed): Sprites for Darwin 200,400,500,600, Airtaxi A21,A31,A32,A33 (foobar) @
15:37:42  <Brot6> OpenGFX - Revision 702:84c25600ade3: Feature (closes #2110): revised Darwin 200 etc. airplane (Da... (foobar) @
15:48:54  <Brot6> OpenGFX - Code Review #2111 (Closed): New Sprites for Bakewell Luckett LB10,LB11, Guru Galaxy (foobar) @
15:48:54  <Brot6> OpenGFX - Revision 703:52466a3ebd7c: Feature (closes #2111): revised Bakewell Luckett LB-10 etc. ... (foobar) @
16:06:37  <Brot6> OpenGFX - Revision 704:07fc3f7f7db9: Fix: improve alignment of renewed aircraft (foobar) @
16:14:09  <Brot6> OpenGFX - Code Review #2117: New Rotor Sprite for Helicopters (foobar) @
16:15:06  *** frosch123 has joined #openttdcoop.devzone
16:16:56  <Brot6> OpenGFX - Feature Request #2052: New Icon in Transparency Options (foobar) @
16:19:53  <planetmaker> FooBar: seems that I've lost the script or never wrote it as script
16:20:06  <FooBar> heh :)
16:20:10  <planetmaker> but... it should be feasible to reinvent it
16:21:15  <FooBar> well, take your time, as it isn't crucial or something
16:21:27  <FooBar> but it would be nice to clean up the repo at some point in the future
16:23:20  <Brot6> OpenGFX - Bug #2687: SH'8P' emits smoke in front of the engine (foobar) @
16:29:33  <FooBar> hmm, these train templates are too confusing
16:29:58  <planetmaker> can I help you?
16:30:05  <FooBar> maybe
16:30:22  <FooBar> I'm looking for a template suitable for these:
16:30:28  <FooBar> we might or might not already have that
16:30:51  <FooBar> from the looks of it it's one of the pikka templates
16:32:33  <FooBar> well, it's the pikka 7/8 template but with the _ views one pixel wider
16:32:39  <planetmaker> we should have it as NML template
16:35:15  <planetmaker> yes: sprites/nml/templates/tmpl_trains.nml
16:35:28  <FooBar> which one is it then?
16:36:01  <FooBar> there's a 29 px template, but it doesn't say it's the pikka one
16:36:38  <FooBar> also it's based on something with just too much parameters to tell what it does without involving math and such :P
16:36:46  <planetmaker> oh... 28px full lenth pikka style..
16:37:16  <Ammler> FooBar: please check the target version of #2537
16:37:16  <Brot6> Ammler: FooBar: #2537 is "OpenGFX - Bug #2537: Graphical glitch at Depot entrance - #openttdcoop Development Zone"
16:37:28  <planetmaker> that's for the 29px from DanMacK
16:37:35  <Ammler> and the description of that version :-)
16:38:20  <Ammler> (closing was invalid invalid)
16:38:31  <FooBar> Ammler: I know, but it's clear that this just cannot be fixed; no need to keep it open
16:38:49  <Ammler> how you know?
16:39:11  <FooBar> read frosch's comment and then try to figure out a solution
16:39:17  <Ammler> you think, the other "OpenTTD" issues are rather fixeable?
16:39:26  <FooBar> some may be
16:39:53  <Ammler> well, imo, it does not hurt to keep tickets open when they have a version applied
16:41:04  <Ammler> then we should reject all OpenTTD tickets and remove that version, I thought, it was a good idea :-)
16:41:05  <FooBar> in my view it doesn't hurt closing things that cannot be fixed anyhow ;)
16:41:19  <FooBar> the idea is good, I'm all for that
16:41:33  <Ammler> well, if you then close such tickets, it is useless :-)
16:41:56  <FooBar> e.g. the medium font height is a nice reminder to wait for an openttd fix
16:42:24  <FooBar> but something that fundamentally cannot be fixed in either needn't be open IMP
16:42:28  <FooBar> =IMO
16:42:35  <Ammler> there was a time, devs said, it is impossible to have more as 8 clients :-)
16:43:08  <planetmaker> Ammler: but this particular issue can never be fixed by OpenGFX
16:43:12  <Ammler> don't take devs words as final ;-)
16:43:32  <planetmaker> it could be added to known-bugs or readme
16:44:06  <planetmaker> but a circular sprite drawing dependency is something a base set never can solve.
16:44:28  <planetmaker> Either it's solved in OpenTTD itself - fine. Or not solved there. In either case OpenGFX needs not do anything
16:44:33  <FooBar> it's just mathematically impossible to fix
16:44:36  <Ammler> planetmaker: that is the versino "OpenTTD" for
16:44:45  <planetmaker> ah
16:44:45  <FooBar> it cannot be fixed in OpenTTD either
16:44:54  <planetmaker> FooBar: that need not be true
16:45:09  <FooBar> I'm quite convinced that it is, hence the close ;)
16:45:40  <Ammler> well, I just thought, you weren't aware about my idea to that version
16:45:54  <FooBar> But it's fine if you want to reopen, but then just not as bug but as feature request or support or something
16:46:09  <Ammler> nah, it's fine
16:46:10  <FooBar> bugs should be fixed as quickly as possible or be rejected if unfixable
16:46:41  <Ammler> some bugs needs work on openttd side, that is simply a fact
16:46:49  <Ammler> or features
16:47:18  <FooBar> sure, but those are not unfixable
16:48:07  <FooBar> anyways, dinner :)
16:48:07  <Ammler> nothing is unfixeable
16:48:10  <planetmaker> FooBar: but Ammler is right: 'not fixable' then needs documentation in readme or known bugs
16:48:24  <planetmaker> Otherwise it has to be considered resolved ;-)
16:48:27  <Ammler> or at least that ^
16:48:35  <FooBar> rejected ;)
16:48:47  <FooBar> but as I've said, I'm fine with reopen
16:48:48  <Ammler> yeah, reject would be better in that case
16:48:56  <FooBar> I don't mind admitting a mistake ;)
16:48:58  <planetmaker> well... this should be rather in OpenTTD's known bugs, but...
16:49:19  <Ammler> but moving something to an "undated" version is the same, imo
16:49:21  <planetmaker> closing it is sending it into nirvana, so that people will not even think about solving it
16:49:36  <Ammler> it is like a list for "known-bugs"
16:51:49  <Ammler> <-- they keep listed here, also closed
16:52:18  <Ammler> so closing/rejecting is fine, I won't reopn
16:52:43  <planetmaker> :-)
16:52:56  <planetmaker> actually having such list of "base sets need XY" is quite good
16:53:15  <planetmaker> that's the most important thing in that list
16:53:35  <planetmaker> and now: have a good evening. I'm off :-)
16:56:45  <Ammler> oh
16:56:48  <Ammler> mäh
16:58:41  <planetmaker> no, I'm not annoyed :-)
16:59:08  <planetmaker> I really just was about to head out
16:59:25  <Ammler> ah, my oh mäh was because of me :-P
17:06:33  <Ammler> #2116 is also a ticket which could need a special version
17:06:33  <Brot6> Ammler: #2116 is "OpenGFX - Bug #2116: wind direction - #openttdcoop Development Zone"
17:07:00  <Ammler> or we move it to OpenTTD too, and check how original does it
17:08:01  <Ammler> andythenorth: you know, how wind directions are in original?
17:08:50  <Ammler> are those the same for every object like airport wind sock, power plant and oil rig?
17:10:19  <Brot6> nml: update from r1567 to r1575 done -
17:11:18  <Brot6> OpenGFX - Code Review #2004 (Closed): Toyland ships (Ammler) @
17:14:33  <Brot6> OpenGFX - Feature #1470 (Rejected): use custom_tags.txt on both types (nml and nfo) (Ammler) @
17:19:29  <Brot6> opengfx: update from r693 to r704 done -
17:22:22  <Brot6> cets: update from r114 to r126 done (436 warnings) -
17:24:27  <Brot6> ogfx-landscape: update from r71 to r74 done -
17:25:18  <Brot6> swedishrails: update from r203 to r204 done -
17:25:39  <Brot6> Following repos didn't need a nightlies update: ogfx-trains (r245), narvs (r37), bros (r52), ogfx-industries (r122), firs (r2233), ailib-tile (r16), foobarstramtracks (r23), transrapidtrackset (r28), 2cctrainset (r750), ailib-list (r32), opensfx (r97), ttdviewer (r34), worldairlinersset (r672), heqs (r611), openmsx (r97), basecosts (r25), nutracks (r202), nml (r1575), 32bpp-extra (r40), manindu (r7), newgrf_makefile (r305),
17:25:39  <Brot6> ailib-direction (r17), ailib-common (r21), snowlinemod (r49), dutchtramset (r87), ai-admiralai (r75), swisstowns (r22), metrotrackset (r56), spanishtowns (r10), frenchtowns (r6), grfpack (r279), ogfx-rv (r107), fish (r683), ttrs (r36), ogfx-trees (r51), grfcodec (r832), ai-aroai (r39), german-townnames (r34), smts (r19), chips (r143), belarusiantowns (r8), indonesiantowns (r41), ailib-string (r29), airportsplus (r107), comic-houses (r71)
17:27:09  <Brot6> narvs: compile of r37 still failed (#2789) -
17:42:30  <Brot6> Following repos rebuilds successful without any difference to earlier nightlies builds: ogfx-trains (Diffsize: 2319), ogfx-industries, firs (37 warnings), foobarstramtracks, manindu (Diffsize: 2), newgrf_makefile, dutchtramset, swisstowns, spanishtowns (Diffsize: 2), frenchtowns, ogfx-rv (Diffsize: 4775), german-townnames (Diffsize: 1), belarusiantowns (Diffsize: 30), indonesiantowns (1 warnings) (Diffsize: 1), airportsplus (2 warnings)
17:42:30  <Brot6> (Diffsize: 30186)
17:54:43  *** andythenorth has quit IRC
18:00:12  <V453000> uh, is there some secret how to run openttd under linux? I unpacked the archive in home/openttd and when I click the exe, nothing happens
18:00:30  <FooBar> Don't try to run a windows executable on linux
18:00:52  <V453000> I downloaded linux version of openttd if I remember correctly
18:01:07  <FooBar> that shouldn't have an exe
18:01:24  <FooBar> just openttd with no extenstion
18:01:49  <Ammler> do first a yum install openttd
18:01:56  <Ammler> to solve the dependencies
18:02:04  <Ammler> then start openttd in the console
18:02:06  *** andythenorth has joined #openttdcoop.devzone
18:02:22  <V453000> Ammler: that works, I just cant get the trunk to work
18:02:27  <V453000> FooBar: yes, without extension :)
18:02:43  <Ammler> again, start it with console
18:02:45  <FooBar> hmmm, then it's not an exe file, but let me try here
18:02:53  <FooBar> it might be missing the base files
18:03:33  <Terkhen> V453000: if it fails without *any* errors, then it can't find the base graphics
18:03:42  <Terkhen> the error is supposedly going to the console :P
18:03:42  <Ammler> yes, openttd might not find the system base sets
18:03:47  <V453000> oh
18:03:50  <V453000> :D
18:03:54  <V453000> :D
18:04:02  * V453000 goes dig himself
18:04:04  <V453000> thanks :P
18:04:41  *** andythenorth has quit IRC
18:05:44  <Ammler> ln -s /path/to/system/basesets /usr/local/share/games/openttd/data/sytem
18:06:28  <Ammler> openttd really should get shareddir to work :-)
18:06:43  <Ammler> or I should check, if it is working in the meantime
18:07:52  <FooBar> V453000: I just tried here and if it doesn't do anything it's indeed the base files missing. Once you have those doubleclicking to start will work fine.
18:08:12  <V453000> yes, unraring :)
18:08:25  <Ammler> rar :-o
18:08:38  <V453000> I packed it once under windows back in the day
18:08:51  <Ammler> you have the files already
18:09:13  <V453000> I do not want my eyes burnt by opengfx
18:09:28  <Ammler> ah, I see :-)
18:10:19  <V453000> yeyy, worky
19:05:17  <Brot6> clientpatches: update from r22717 to r22720 done (6 warnings) -
19:08:52  <Rubidium> Ammler: you need even more directories where OpenTTD wants to search in?
19:09:40  <Ammler> Rubidium: no, I would use shared dir and install the data to the default openttd location
19:10:13  <Ammler> well, looking in the default linux location wouldn't hurt
19:10:16  <Brot6> openttd-vehiclevars: update from r22717 to r22720 done -
19:10:31  <Ammler> it is one or two more
19:10:47  <Ammler> how much would that delay the already long startup?
19:11:07  <Ammler> 0.0000001%
19:12:31  <Rubidium> Ammler: it already has a shared directory. Why can't you use that?
19:12:34  <Ammler> hmm, shareddir is indeed useless, as you would need to use that on the local builds
19:13:21  <Ammler> Rubidium: I said, I need to check if that is fixed in the meantime, last time I used it it didn't work and it has a note that it works with osx only
19:13:45  <Brot6> OpenGFX - Bug #2687: SH'8P' emits smoke in front of the engine (foobar) @
19:13:45  <Brot6> OpenGFX - Revision 705:1dba75fb6a13: Feature (closes #2075): temperate locomotives resized to 28p... (foobar) @
19:13:45  <Brot6> OpenGFX - Code Review #2075 (Closed): Temperate Locomotives Resized to 28px (foobar) @
19:14:37  <Ammler> /usr/share[/games]/openttd/data results in 2 more paths to look
19:14:45  <Ammler> or are you aware of another linux path?
19:14:47  <FooBar> ~/.openttd works here as shared dir
19:14:57  <Ammler> FooBar: that isn't shared dir
19:15:07  <Ammler> that is personaldir afaik
19:15:09  <FooBar> shared between different openttd installs
19:15:10  <Brot6> serverpatches: update from r22717 to r22720 done (10 warnings) -
19:15:21  <FooBar> but I'm starting to think that's not what you want :P
19:15:32  <FooBar> you want shared for all users?
19:15:45  <Ammler> FooBar: I mean the dir who is called shareddir or similar in the readme
19:16:24  <Ammler> officially supported on osx only, but I have a kind of lack of current development
19:16:57  <Ammler> but anyway, also shareddir wouldn't help, except the default config would use it
19:17:20  <Brot6> 32bpp-ez-patches: compile of r22720 still failed (#2446) -
19:17:21  <Rubidium> Ammler: Linux does not have a concept of shared but user writable directory
19:17:25  <Ammler> Rubidium: at least V453000 proved it as a lack
19:18:16  <Ammler> Rubidium: well, you know what I mean, openttd does not read to write to
19:18:29  <Ammler> the issue is just for startup
19:18:31  <Rubidium> likewise, Linux and Windows have no concept of Application Bundle. Does that mean that they those builds are flawed?
19:18:49  <Rubidium> and Windows and OSX have no Installation Directory. Are they flawed?
19:18:59  <Ammler> Rubidium: you can call it like you want, just fix this flaw :-P
19:19:06  <Rubidium> it is no flaw
19:19:28  <Rubidium> there is no 'shared' user writable directory in the FHS
19:19:39  <Ammler> it is a issue, you install openttd package which works, but when I download nightly from openttd, it doesn't
19:20:16  <Ammler> Rubidium: I already said, it does not need to use that shareddir, that would be just a workaround
19:20:44  <Ammler> currently I make a symlink
19:20:54  *** andythenorth has joined #openttdcoop.devzone
19:21:00  <Rubidium> there is no standard, thus nothing to follow
19:21:12  <Rubidium> ofcourse, I could say /tmp as shared directory
19:21:18  <Ammler> where would /usr/share[/games]/openttd/data not work?
19:21:21  <Rubidium> but I doubt that e.g. Debian will install the files in there
19:21:54  <Ammler> at least on all rpm distros
19:22:09  <Ammler> so basically 2 paths to check
19:22:32  <Ammler> again, what you think is the delay time?
19:22:39  <Rubidium> it's negligable
19:22:47  <Rubidium> but that is not my point!
19:22:51  <Ammler> :-)
19:23:01  <Rubidium> my point is that there is no such directory
19:23:07  <Rubidium> you say /usr/share/games...
19:23:17  <Ammler> well, what else?
19:23:33  <Rubidium> FHS mentions /usr/games
19:23:36  <Ammler> games needs to be optional
19:23:43  <Rubidium> it also mentions /usr/lib/games
19:23:54  <Ammler> I am not aware of a distro using that
19:24:06  <Ammler> but also if there are 10 possibilites, would it delay the startup?
19:24:20  <Rubidium> it would be utterly pointless
19:24:25  <Ammler> why?
19:24:25  *** andythenorth has quit IRC
19:24:40  <Rubidium> or you fancy adding a very long list to the readme of places where it might be looking for files?
19:25:01  <Ammler> you don't need to add that to the readme, that's the point
19:25:46  <Rubidium> so we get questions like: I removed X from all directories mentioned in the readme, but it still shows up. What have I done wrong?
19:25:54  <Ammler> currently you should add a note, why openttd nightly doesn't work on Linux
19:26:35  *** andythenorth has joined #openttdcoop.devzone
19:27:21  <Ammler> Rubidium: again, we speak about locations openttd should look for data, not where openttd should save data
19:27:24  <Rubidium> because it's to be install into /usr/local
19:27:31  <Brot6> OpenGFX - Support #2687: SH'8P' emits smoke in front of the engine (foobar) @
19:27:31  <Brot6> OpenGFX - Support #2687: SH'8P' emits smoke in front of the engine (foobar) @
19:27:34  <Rubidium> as to not to influence e.g. distro installs
19:28:01  <Ammler> it is just about getting the baseset for startup
19:28:03  *** andythenorth has quit IRC
19:28:22  *** andythenorth has joined #openttdcoop.devzone
19:28:31  <Ammler> andythenorth: setup new ibook?
19:28:37  *** andythenorth has quit IRC
19:29:03  *** andythenorth has joined #openttdcoop.devzone
19:29:16  <Rubidium> Ammler: if you come up with something the Gentoo guys can live with, we might consider it
19:29:38  <Ammler> why should a distro care about?
19:29:48  <Ammler> again, it is just for reading
19:29:57  <Ammler> I guess, you don't like that :-)
19:30:02  *** andythenorth has quit IRC
19:30:08  <Rubidium> because I don't want pedantic Gentoo bug reports
19:30:16  <Rubidium> they are annoying to deal with
19:30:17  <Ammler> what could they report?
19:30:19  *** andythenorth has joined #openttdcoop.devzone
19:30:33  <Ammler> as there is nothing in the readme :-)
19:30:37  <Rubidium> they reported that we pass CFLAGS to the C++ compiler
19:30:45  <Rubidium> and went totally beserk on that
19:31:13  <Ammler> nobody will know about that feature
19:31:20  <Ammler> :-)
19:31:29  <Ammler> openttd just works
19:32:11  <Ammler> well, I guess also if it mentioned in the readme, ti wouldn't hurt
19:32:20  <Ammler> as it just for reading
19:32:44  <Ammler> like you do already
19:33:40  <Ammler> "The installation directory" is already readable only, isn't?
19:34:39  <Ammler> which is btw. wrong in the readme
19:34:42  <Rubidium> not per definition
19:34:54  <Ammler> it misses a local
19:35:14  <Ammler> and on the rpm distros, games is not used
19:35:21  <Rubidium> it depends on how it's configured
19:35:34  *** andythenorth has quit IRC
19:35:35  <Ammler> well, I would have expected default
19:35:43  <Ammler> which is /usr/local...
19:35:50  *** andythenorth has joined #openttdcoop.devzone
19:36:10  <Rubidium> it's more often not there, at least in distros such as Debian and Ubuntu
19:36:11  <Ammler> hmm, what path do the openttd nightlies use?
19:36:29  <Rubidium> which are arguably more used than the nightlies or the generic binaries
19:36:38  <Rubidium> Ammler: whatever the default from configure is
19:37:09  <Ammler> so this is the path of openttd nightlies
19:38:04  <Rubidium> if that's the case, then yes
19:38:40  <Rubidium> oh, and IIRC: if 'shared' exists, it'll try to place the highscore there
19:39:12  <Ammler> yeah, we agreed, shared dir is bad idea
19:39:33  <Ammler> I would "extend" the install paths
19:39:58  <Ammler> where it doesn't write something
19:40:23  <Rubidium> the readme does not guarantee that
19:40:29  <Rubidium> and neither does OpenTTD
19:40:47  <Ammler> well, it doesn't need to guarantee, it simply can't
19:40:51  <Brot6> GRFCodec - Revision 833:423c64a32ec9: Fix action 14 palette checking on BE machines (Rubidium) @
19:41:06  <Ammler> else it would be big secuirty flaw :-)
19:41:13  <Ammler> but not necessary of openttd
19:42:18  <Ammler> wasn't there once a feature request to not let openttd start as root?
20:26:25  <V453000> hm
20:26:42  <V453000> I guess I will have to run linux as a vm
20:26:44  *** frosch123 has quit IRC
20:26:57  <V453000> as it seems to be quite unfriendly with photoshop
20:26:59  <V453000> and I hate gimp
20:27:24  <andythenorth> my photoshop is broken :(
20:27:41  <andythenorth> this is very bad news for FISH eaters
20:27:55  <V453000> how could you break it?
20:28:16  <andythenorth> moved to a different OS
20:28:28  <V453000> oh :)
20:28:32  <andythenorth> and photoshop is £400
20:29:27  <Rubidium> just virtualise the previous OS
20:29:27  <Ammler> V453000: you could run ps on linux
20:29:44  <andythenorth> Rubidium: that might actually work :o
20:30:12  <Rubidium> unless you're running Steve's OS, then it likely won't work unless you perform shitloads of trickery
20:30:15  <V453000> Ammler: wine says it encounters some yet unreported error x.x
20:30:24  <Ammler> V453000: you hate gimp like you hate ogfx :-)
20:30:29  <Ammler> it is really runny
20:30:32  <Ammler> funny*
20:30:32  <Rubidium> s/are/were/
20:30:49  <V453000> Ammler: no, gimp at least does not pretend to be better
20:31:04  <Ammler> V453000: it does not need it
20:31:12  <Rubidium> yes, OGFX toyland is worse than original ;)
20:31:16  <Ammler> you need around 1% of ps, and that is all covered
20:31:47  <Ammler> but I am sure, for you gimp is never better :-)
20:32:06  <Ammler> you wouldn't give it a chance
20:32:18  <V453000> Rubidium: opengfx toyland is a total unoriginal shit, ttd is a graphical masterpiece, yet eyehurting but possible to get used to it ... I for one get much more eyehurt from pixel drawing than looking at toylan
20:32:19  <V453000> d
20:32:38  <V453000> Ammler: I was using gimp for about 4 months
20:32:39  <Ammler> guys like andythenorth work with it daily, so that is understandable, you are just funny :-P
20:34:25  <andythenorth> Rubidium: we owe you some feedback on payment rates
20:35:20  <Ammler> V453000: and also you can still setup vm on linux to run some windows apps
20:35:32  <V453000> I guess
20:35:36  <Ammler> yum install virtualbox
20:36:04  * Rubidium fears he has to pay with his life
20:36:51  <V453000> Ammler: did not find it
20:38:31  <Ammler> then you might need to install it like on windows
20:38:45  <V453000> already did
20:38:57  * andythenorth is too sleepy to do anything 
20:39:08  <andythenorth> went to sleep at 1am
20:39:14  <andythenorth> got up at 5.15am
20:39:17  <andythenorth> :P
20:39:31  <Ammler> V453000: just to hear here how adobe cheated on andythenorth should teach not to use it
20:39:34  <V453000> but I suppose I will just screw linux and get back to windows, and eventually try to run linux virtually
20:40:00  <andythenorth> Ammler: blame apple :P
20:40:04  <Ammler> V453000: I am not surprised :-)
20:40:07  <V453000> Ammler: do you really think czech people buy adobe stuff?
20:40:26  <andythenorth> here is my review for Transformers 3:
20:40:28  <andythenorth> "Boom"
20:40:42  <V453000> :D is that a review or a story in total? :D
20:41:47  <Ammler> well, it is sad, that nml still needs gcc
20:42:15  <V453000> gcc?
20:42:24  <Ammler> the reason, you need linux
20:42:24  <V453000> andythenorth: how do you code? using windows or linux?
20:42:33  <Ammler> neither
20:42:42  <V453000> oh mac
20:43:24  <Ammler> windows is os to develop, I guess you know that already
20:43:28  <Ammler> no*
20:43:34  <V453000> I do
20:44:25  <V453000> but im not getting rid of programs like after effects, photoshop or corel draw
20:44:41  <V453000> so I guess I will just leave linux for coding
20:44:54  <V453000> and draw in windows
20:45:02  *** bodis has joined #openttdcoop.devzone
20:45:13  <Ammler> that is how foobar works
20:46:01  <V453000> yes, probably the best solution
20:46:13  <FooBar> yes, I use photoshop, notepad++ and hg on Windows and only run make in Linux
20:47:02  <V453000> I guess I will do the same :<
20:47:12  <FooBar> well, you have my guide ;)
20:47:17  <Ammler> FooBar: you should learn python and make nml preprocessor :-)
20:47:32  <FooBar> no, I shouldn't learn python :P
20:47:58  <Ammler> setup linux just for make :-D
20:48:00  * andythenorth should learn nml
20:48:01  <andythenorth> :P
20:48:09  <andythenorth> python is fun
20:48:12  <andythenorth> is nml fun?
20:48:18  <V453000> btw is it possible that linux stresses my computer more than w7 in doing-nothing mode?
20:48:29  <andythenorth> run top and find out
20:48:33  <andythenorth> top -u might help
20:48:51  <FooBar> gcc isn't the problem on Windows, it's sed and the like that are very inefficient on Windows; takes ages
20:49:12  * andythenorth ponders 8GB
20:49:20  <andythenorth> £40
20:49:23  <V453000> well, good night :)
20:49:33  <andythenorth> someone else can have my 2x2GB sticks
20:49:47  <FooBar> andythenorth: NML is more fun than NFO. Hardly needs comments, as most of the code is clear by itself (if you use proper names for spritesets/groups etc.
20:49:59  <andythenorth> NFO is a game though
20:50:16  <andythenorth> writing correct NFO is approximately equal to playing Mario or such
20:50:28  <andythenorth> there *is* a correct solution, but you have to find it :P
20:50:31  <Ammler> V453000: linux does never nothing
20:51:00  <Ammler> well, not never :-)
20:51:31  <FooBar> you still need the NML manual to look things up, so that part of the game still exists
21:01:13  *** bodis has quit IRC
21:12:11  <andythenorth> bye
21:12:11  *** andythenorth has left #openttdcoop.devzone
21:24:57  *** Lakie has quit IRC
22:24:12  *** orudge has quit IRC
22:24:12  *** Sylf has quit IRC
22:24:12  *** Rubidium has quit IRC
22:25:53  *** FooBar has quit IRC
22:26:52  *** Sylf has joined #openttdcoop.devzone
22:27:26  *** orudge has joined #openttdcoop.devzone
22:34:46  *** ChanServ changes topic to "Talk about things hosted and developed on | Downloads log: | Sandbox passwords are the same as the usernames"
22:43:50  *** Rubidium has joined #openttdcoop.devzone

Powered by YARRSTE version: svn-trunk