IRC logs for #openttd on OFTC at 2011-09-04
⏴ go to previous day
00:08:17 *** Theos is now known as Guest8568
00:16:50 *** Rubidium has joined #openttd
00:21:57 *** intermundi has joined #openttd
00:22:18 *** JVassie has joined #openttd
00:52:40 *** notsure has joined #openttd
01:47:58 *** Guest8568 is now known as theos
02:25:45 *** rhaeder1 has joined #openttd
04:36:43 <pjpe> newgrf set i have ever seen
04:46:26 <pjpe> you have to build track the length of the map just to get up to speed
04:49:01 <Terkhen> wasn't that fixed already?
04:49:47 <pjpe> if it didn't take a long time then all you have is a very expensive people blender on rails
04:49:54 <Terkhen> it makes sense realism-wise, not game-wise :)
04:53:14 <pjpe> i also like how there's no bridge fast enough
04:53:23 <pjpe> so you can have this train that you can miss in the blink of an eye
04:53:28 <pjpe> and then oops slows done from a bridge
04:55:43 <Terkhen> that reminds me something
04:55:58 <Terkhen> do they slowdown on tunnels too?
04:56:20 *** Eddi|zuHause has joined #openttd
04:57:21 <Terkhen> codewise they should not
04:57:38 <Terkhen> unless they still have air drag :P
04:59:10 <pjpe> runs just as fast as normally
06:04:54 *** Kurimus has joined #openttd
06:33:43 *** TWerkhoven has joined #openttd
07:35:41 *** sla_ro|master has joined #openttd
07:37:21 *** douknoukem has joined #openttd
07:39:52 *** Hyronymus has joined #openttd
07:46:02 *** Belugas has joined #openttd
07:46:02 *** ChanServ sets mode: +o Belugas
07:56:14 *** Markavian` has joined #openttd
08:02:04 <Hyronymus> does anyone know if/how you can link to a paragraph on a wikipage rather than to the wiki page itself
08:02:42 <Yexo> if it's in the table of contents you can use that link
08:03:29 <Yexo> I don't think it's possible in that case
08:18:21 <Zuu> It might be possible still. It could be that it creates the hash-links anyways. You could open the source view in your browser and look for <a> tags with a name/id given.
08:19:32 *** Alberth has joined #openttd
08:19:32 *** ChanServ sets mode: +o Alberth
08:19:40 <Zuu> Or just follow the pattern of those hash-links from a page with a TOC and see if the hash-string has any relation to the paragraph.
08:20:43 <Zuu> .. or you edit the page and add enough sections to cause a TOC to appear in the preview.
08:24:47 *** AussieScreens has joined #openttd
08:26:58 <AussieScreens> you playing OpenTTD?
08:28:55 <krinn> AussieScreens, see the channel name and topic ?
08:29:42 * Alberth wonders what the topic says about playing OpenTTD
08:31:15 * krinn don't know he never read it
08:32:17 *** douknoukem has joined #openttd
08:47:22 *** Progman has joined #openttd
08:51:23 *** Cybertinus has joined #openttd
08:51:47 *** frosch123 has joined #openttd
08:54:35 *** Dilandau has joined #openttd
08:55:32 * Alberth ponders where Dorpsgek is
08:55:35 *** Dilandau has joined #openttd
08:55:48 <Alberth> Dilandau: wrong channel
08:58:07 * planetmaker wonders how to detect liblzma without using pkg-config
08:58:24 * LA wonders what the heck did he just say
08:58:26 <Alberth> try to link against it :)
08:58:52 <Alberth> afaik that's what the autotools do
08:59:00 <Alberth> autoconf in particular
08:59:17 <planetmaker> as pkg-config is currently an implicit dependency. Without pkg-config liblzma cannot be detected
09:00:22 <Alberth> figuring out build deps is always a mess
09:00:52 <Alberth> autotools doa quite decent job, but are a mess themselves
09:03:39 *** andythenorth has joined #openttd
09:04:23 <frosch123> i would suggest that using liblzma without pkg-config should not be supported by ottd :p
09:05:04 <frosch123> because it is exactly the point of pkg-config to deal with such things
09:05:11 <planetmaker> would be easiest, though
09:05:31 <Alberth> you should be able to manually state where the lib is as fallback (which I think is the case)
09:06:24 <CIA-2> OpenTTD: frosch * r22888 /trunk/src/town.h: -Doc: Doxygenize Town struct. (adf88)
09:06:57 <planetmaker> well, the usual place. But forcing --with-lzma doesn't cut it
09:07:27 <Alberth> planetmaker: I'd expect that you need to state a path as well
09:08:43 <planetmaker> probably. But specifying the default path seems a bit superfluous
09:09:31 <Alberth> there is something like a default path in unix? :o
09:10:06 <planetmaker> well. /usr/lib /usr/local/lib
09:10:21 <planetmaker> whatever is in your path :-)
09:13:43 <krinn> not for 64bits distros, that prefer use /usr/lib32(64)
09:14:25 <krinn> i think /etc/ld.so.conf is where you'll find your lib path
09:16:38 <frosch123> planetmaker: i would expect "./configure --with-lzma=lzma" to just work
09:17:50 <planetmaker> yeah, but then it still complains about missing pkg-config
09:18:10 <frosch123> hmm, yes, it does not seem to be the link option
09:18:17 <frosch123> but the phg-config thingie itself
09:18:38 *** JVassie has joined #openttd
09:19:22 <frosch123> with-lzma seems to do something different than with-zlib and with-lzo2
09:22:32 <frosch123> with-png does the same though
09:23:31 <frosch123> so, at least the comment is wrong :p
09:23:31 <planetmaker> zlib, lzo2 use a simple library detection. While lzma and pnglib use an individual one
09:24:21 <frosch123> it should be echo " --with-liblzma[=pkg-config liblzma] enables liblzma support"
09:27:30 <andythenorth> are pipelines done yet?
09:33:12 <Eddi|zuHause> andythenorth: do them as station tiles
09:33:54 <andythenorth> that's done already in that case :)
09:33:54 <planetmaker> they exist as station tiles. Or as newobjects
09:35:31 * planetmaker installs pkg-config
09:35:43 <planetmaker> with a whole tree of deps... :S
09:36:24 <andythenorth> stations as pipelines doesn't really count though :P
09:38:14 <frosch123> looks like you joined the wrong channel :p
09:39:10 <planetmaker> frosch123: if I understood it correctly it's part of the cross-compilation toolchain to build openttd for osx on a linux box
09:39:29 <Terkhen> planetmaker: I had to install a lot of stupid stuff just to detect liblzma with MinGW :)
09:40:47 <Tatsh> a lot of headers were 'stolen' from my mac
09:44:41 <Eddi|zuHause> sometimes i _really_ wonder about the intelligence of people... "how do i make trains turn around in stations" - "enable turn around in stations in difficulty options" - "that doesn't answer my question"
09:46:21 <krinn> technically you've answer to "howto make trains turnaround in station" and not "how do i make..." :)
09:47:07 *** SmatZ- is now known as SmatZ
09:48:19 <krinn> but i suppose that was the answer anyone would expect than a "build rails around it"
09:58:03 * Zuu found out one can work around the online content crash by going ot the NewGRF window and click to update just the NewGRFs from there as the bug is AI-related.
09:59:34 * Eddi|zuHause always uses online content from the newgrf window
10:00:09 *** andythenorth has left #openttd
11:10:09 *** HerzogDeXtEr1 has joined #openttd
11:28:45 <CIA-2> OpenTTD: planetmaker * r22889 /trunk/src/string_func.h: -Fix [FS#4751]: [OSX] MacOSX 10.7 knows already about strndup (leecbaker)
11:29:27 *** Wolfsherz has joined #openttd
11:41:24 <peter1138> grammar well you do
11:42:15 <SpComb> planetmaker knows already about grammar
11:43:50 <Eddi|zuHause> very german the grammar is
11:46:42 *** z-MaTRiX has joined #openttd
11:48:29 <z-MaTRiX> į see only name resolution is broken now
11:50:14 <appe> what's the CIA-2 all about
11:54:37 <Eddi|zuHause> appe: the CIA monitors this channel, didn't you know?
11:55:29 <appe> Eddi|zuHause: well, you do have extensive knowledge about train networks and places with high densities of people
11:55:47 <appe> might be valuable in a *cough* al quaeda situation.
11:56:09 <planetmaker> now that you discovered it... better hide quite well
11:57:22 *** andythenorth has joined #openttd
12:21:11 * planetmaker needs more VMs... to run several OSX in parallel without reboot
12:34:21 *** SirSquidness has joined #openttd
12:37:10 *** z-MaTRiX has joined #openttd
12:54:18 *** Adambean has joined #openttd
12:57:57 *** Chris_Booth[ph] has joined #openttd
13:08:28 *** Chris_Booth[ph] has quit IRC
13:09:25 <Tatsh> planetmaker, gcc targetting Darwin/OS X latest available (publicly) now builds on linux
13:09:45 <Tatsh> it's funky but everything including C++ works now
13:13:14 *** Devroush has joined #openttd
13:22:44 *** KritiK_ has joined #openttd
13:26:27 <planetmaker> good news, Tatsh :-)
13:26:53 <planetmaker> please make a careful documentation and patches, thus that I could build all that myself :-)
13:27:10 *** KritiK_ is now known as KritiK
13:27:24 <planetmaker> from the official sources, with your patches and the description of how to achieve the result :-)
13:28:21 <planetmaker> if you could provide a walk-through that way, it'd be _really_ great
13:28:31 <krinn> else you'll have to ssh to everyone and build it yourself :)
13:28:33 <planetmaker> For us - but I guess other projects could profit from that then, too
13:31:38 <planetmaker> (I know, careful documentation sucks, but that's the way it really will be helpful. Pulling from modified, personal repositories is not something I want to do when building a compile farm)
13:31:53 <planetmaker> sorry to say, but that's too risky ;-)
13:32:44 <Tatsh> well, google originally did this with toolwhip (probably after seeing the old docs for this) so they could automate chrome builds without needing macs
13:33:07 <planetmaker> yup, I looked at it when you pasted the link the other day
13:33:42 <Tatsh> i'm interested in distcc for either gentoo prefix or macports on my mac
13:34:25 <planetmaker> well, as said: please document what you do. And make changes available as patches. That's the most helpful form IMHO
13:37:38 <planetmaker> it makes it easy / easier to follow your steps :-)
13:38:20 <planetmaker> pulling a whole repo, analysing what is different to the default repos (which version?) is considerably more work
13:38:31 <planetmaker> while you all know that relatively easily
13:42:11 <planetmaker> Tatsh: and I really would like to be able to follow your steps... it might make it considerably easier to get maybe some 2nd OSX compiler done which targets the newer OSX versions
13:44:05 <Tatsh> i am doing that planetmaker
13:44:12 <Tatsh> it's hackish at the moment but almost there
13:44:46 <Tatsh> what's not up to date is ld64 but a person who maintains binutils-apple (cctools) for gentoo is helping me out there; he has patches for Darwin but they should be useful on Linux; then we'll have a fully up-to-date toolchain
13:45:16 *** Zuu is now known as Guest8685
13:45:33 <Tatsh> i figured out the best solution for ranlib; just copy libtool.c to ranlib.c, set libtool to ALWAYS run as ranlib in that file, add it to targets
13:46:09 <Tatsh> gcc version 4.2.1 (Apple Inc. build 5666) (dot 3)
13:46:12 <Tatsh> latest version built on linux
14:12:02 <Zuu> The next OpenGFX+ Airports release looks promising. 4 views for most airports.
14:12:25 <planetmaker> zeroeight did marvelous work there
14:12:47 <planetmaker> I just wonder whether I simply should release it ;-)
14:13:47 <Zuu> It would be cool to include a screenshot in the release post. Although it will probably trigger more reports of the online content problem.
14:56:51 *** sla_ro|master has joined #openttd
15:01:05 *** Wolfsherz has joined #openttd
15:04:06 <CIA-2> OpenTTD: frosch * r22890 /branches/1.1/ (6 files in 4 dirs): [1.1] -Prepare: 1.1.3-RC1
15:05:34 <planetmaker> hm, system startup on 10.7 is considerably faster... esp. given that all apps are re-instated to their previous state
15:06:10 <planetmaker> and that even when comparing booting from usb vs. internal hdd
15:07:42 <CIA-2> OpenTTD: frosch * r22891 /tags/1.1.3-RC1/ (. src/os/windows/ottdres.rc.in src/rev.cpp.in): -Release 1.1.3-RC1
15:44:42 *** valhallasw has joined #openttd
15:54:07 <Alberth> How do you save a palette in gimp?
15:56:42 <Eddi|zuHause> in some obscure side menu
15:59:36 <Eddi|zuHause> hm... can't find it either
16:00:03 <Ammler> Alberth: you mean export?
16:02:40 <Ammler> palette window -> edit palette -> save
16:03:07 <Alberth> I clicked that, but nothing happens
16:04:01 <frosch123> @topic set 1 1.1.2, 1.1.3-RC1
16:04:01 *** DorpsGek changes topic to "1.1.2, 1.1.3-RC1 | Website: *.openttd.org (translator: translator, server list: servers, wiki: wiki, patches & bug-reports: bugs, revision log: vcs, release info: finger) | Don't ask to ask, just ask | 'Latest' is not a valid version | English only"
16:05:44 <Alberth> I'll find another way to get that data :/ thanks for confirming it is not easy :)
16:05:45 <Ammler> Alberth: anyway, the palettes are either in ~/.gimp*/palettes or /usr/share/gimp/...
16:06:23 <Ammler> you can copy the path at least
16:07:25 <Ammler> I did quite easy as I made the palettes files for the devzone
16:09:22 * Alberth needs some dinner first
16:10:13 <Eddi|zuHause> hm... the NML topic's "documentation" link is outdated...
16:12:24 <Ammler> does it not give a hint to the new place?
16:12:42 *** Chris_Booth[ph] has joined #openttd
16:13:00 <Eddi|zuHause> Ammler: yes, but it has wrong mime type, so it doesn't open in browser
16:15:59 <Ammler> I quess, that is because Hirundo made some other windows things :-)
16:17:04 <Ammler> or the update to hg 1.9.2?
16:29:53 *** Chris_Booth[ph] has quit IRC
16:34:57 *** andythenorth has joined #openttd
16:42:53 *** sla_ro|vista has joined #openttd
16:57:22 *** ProfFrink has joined #openttd
17:03:23 *** ProfFrink is now known as Prof_Frink
17:04:25 *** Biolunar has joined #openttd
17:10:16 *** douknoukem has joined #openttd
17:24:07 *** csaba2 is now known as csaba
17:27:46 *** JVassie has joined #openttd
17:29:37 *** douknoukem has joined #openttd
17:45:18 <CIA-2> OpenTTD: translators * r22892 /trunk/src/lang/ (arabic_egypt.txt belarusian.txt czech.txt korean.txt):
17:45:18 <CIA-2> OpenTTD: -Update from WebTranslator v3.0:
17:45:18 <CIA-2> OpenTTD: arabic_egypt - 41 changes by kasakg
17:45:18 <CIA-2> OpenTTD: belarusian - 3 changes by Wowanxm
17:45:18 <CIA-2> OpenTTD: czech - 7 changes by TheLamer
17:45:20 <CIA-2> OpenTTD: korean - 3 changes by junho2813
17:49:33 <CIA-2> OpenTTD: planetmaker * r22893 /trunk/src/ (5 files in 2 dirs):
17:49:33 <CIA-2> OpenTTD: -Fix [FS#4744]: [OSX] Compilation on OSX 10.7 was broken (based on patch by leecbaker)
17:49:33 <CIA-2> OpenTTD: -Add: [OSX] Support for fullscreen mode when compiled against SDK 10.7. Otherwise fullscreen mode is disabled when OpenTTD is run on OSX Lion
17:51:15 <pjpe> i never tried openttd fullscreen on a mac
17:51:22 <pjpe> does it do it like every other fullscreen program
17:51:26 <pjpe> and not let you tab away?
17:52:20 <pjpe> something will lock up in fullscreen mode
17:52:29 <planetmaker> hm, I didn't test that. Might actually be different when you compile it now on Lion
17:52:29 <pjpe> wait a few hours and hope it fixes itself?
17:52:31 <__ln__> there was a patch to make it apple-tabable, but...
17:53:11 <__ln__> how is the Lion fullscreen done then?
17:53:27 <pjpe> it just maximizes the window and gets rid of the topbar
17:53:31 <planetmaker> Now I'm looking forward whether the binaries of the CF actually work ;-)
17:53:36 <pjpe> and puts it in it's own space
17:54:15 <planetmaker> but somehow a proper fullscreen support also for the other versions has to be found. The one on 10.7 is quite elegant, though
17:54:16 *** Zuu is now known as Guest8734
17:54:17 <__ln__> pjpe: is that some Lionish full-screen-apps stuff or something normal?
17:54:54 <pjpe> they just did it that way in lion
17:54:56 <golden> i need the Al's for Open TTd 1.1.1
17:55:59 <frosch123> download them using the ingame content download
17:56:04 <__ln__> using the windowed mode code for fullscreen as well is the solution for at least 10.4..10.6, probably also 10.3 and 10.7
17:56:47 <planetmaker> that's what it does now, if natively compiled
17:56:58 <planetmaker> and indeed, I think it can be used for the other versions as well
17:57:08 <golden> jst did that thank yoou
17:58:09 <__ln__> i have run openttd in apple-tabable fullscreen years ago, on 10.4
17:58:25 <golden> and the trains cnt get the latest one's y???
17:59:08 <planetmaker> and where did that go, __ln__?
17:59:20 <planetmaker> fell prey to Bjani-ism? ;-)
18:00:21 <__ln__> planetmaker: it was never in svn, it was a patch. the patch was rejected by Bjarni, because he considered the drawing to be too slow compared to the old approach.
18:00:58 <__ln__> most of the patch was much later applied to svn by egladil, but not the fullscreen part.
18:01:24 <golden> ok so i cnt get them???
18:02:35 <planetmaker> golden: you might want to put your question in a clearer way. And without leet-speak I have to say
18:03:43 <__ln__> search for "bool fullscreen" though
18:04:07 <golden> my bad when i get to the 2035 years i get the electric engens but i cnt buy them
18:04:23 <pjpe> new revision works perfectly in fullscreen
18:04:32 <pjpe> aside from the graphical glitch you get when you resize the window
18:04:45 <Terkhen> golden: you can only build them on electrified depots
18:04:54 <planetmaker> pjpe: you mean transiently funny colours?
18:05:08 <pjpe> then it goes back to normal
18:05:14 <pjpe> just like when you normally resize
18:05:16 <planetmaker> only during resize. I guess that's ok
18:05:43 <golden> ok so i hv to convert the railways???
18:05:57 <Terkhen> regarding future questions: please search in the wiki first
18:09:27 *** andythenorth has joined #openttd
18:09:30 <Terkhen> no, yacd is too outdated
18:09:46 <planetmaker> foobar made a somewhat updated version
18:10:00 <Terkhen> maybe I should code something
18:10:31 <planetmaker> new and cool features?
18:10:49 <andythenorth> "every day is a feature day"
18:11:20 <andythenorth> Terkhen: newgrf code, or real code?
18:11:31 <andythenorth> I missed the rest of the conversation :P
18:11:40 <Terkhen> I don't mind as long as it entertains me
18:12:12 <andythenorth> there are multiple FIRS 'to-do' items :P
18:12:52 <andythenorth> fences are an easy one
18:13:04 <andythenorth> or adapting tile layouts to use the 'ground detail' tiles I've started
18:13:06 <Terkhen> hmmm... are you sure of that? :P
18:13:25 <andythenorth> adapting tile layouts would be nice
18:15:16 *** sla_ro|master has joined #openttd
18:15:44 <Terkhen> I don't find the related task
18:16:06 <planetmaker> might have none ;-)
18:17:45 <Alberth> that is arrangable :p
18:18:56 <andythenorth> Terkhen: there's no ticket yet :)
18:20:13 <andythenorth> Terkhen: I can describe what's needed :)
18:21:35 <andythenorth> each tile layout should have a ground tile, a ground overlay, and n building tiles
18:21:44 <andythenorth> the ground overlays haven't existed before generally
18:22:05 <andythenorth> they'll have the "don't make transparent" bit set
18:23:46 <Terkhen> what is the use of the ground overlay? snow?
18:24:06 <andythenorth> gardens, black areas for basements etc
18:25:19 <Terkhen> so 1) modify snow template
18:25:32 <andythenorth> I made recent commits to the grain mill to provide the graphics + rearrange sprites
18:25:46 <Terkhen> it should not need much changes IMO
18:30:35 <Terkhen> GROUND_OVERLAY_CONDITIONAL(sprite, condition)
18:30:41 <Terkhen> GROUND_OVERLAY(sprite)
18:31:15 *** ProfFrink has joined #openttd
18:33:03 <planetmaker> hm... builder's yard already uses conditional ground, Terkhen
18:33:26 <planetmaker> with the overlays. Dunno what andy drew recently ;-)
18:36:49 <George> Hi. Is there a NML->NFO translator/compilator?
18:37:32 <Eddi|zuHause> you can decompile the nml output with grfcodec?
18:37:35 *** ProfFrink is now known as Prof_Frink
18:37:52 <Eddi|zuHause> nmlc has an --nfo option
18:38:23 <planetmaker> makes sometimes for interesting code :-)
18:41:09 <andythenorth> planetmaker: I split ground detail out for each tile
18:41:19 <andythenorth> (only the brick grain mill is done so far)
18:49:42 <Terkhen> which one is the correct example? grain mill or builders yard?
18:50:13 <planetmaker> grain mill was done by andy ;-)
18:50:20 <planetmaker> builder's yard by me
18:50:31 <planetmaker> you can now outplay us two :-P
18:51:05 <planetmaker> possibly there might even be a 3rd option which is better
18:51:26 <planetmaker> the only important thing is that the industry's ground sprites are drawn on top of the default ground sprites
18:51:42 <planetmaker> that allows for improved ground awareness (just adding details to default ground)
18:51:59 <planetmaker> which is especially important for snow, as TTD snow and OpenGFX snow look quite a bit different
18:56:07 *** z-MaTRiX has joined #openttd
19:06:57 <andythenorth> Terkhen: I didn't code anything for it yet
19:07:13 <andythenorth> I just figured out the spritesheet layouts
19:07:39 <andythenorth> this gets the separate ground snow planetmaker wanted, as well as black 'foundation' areas for buildings
19:08:27 <andythenorth> it likely means reslicing some industries, and adjusting offsets
19:09:27 <planetmaker> andythenorth: the rotor of the wind grain mill could be a separate sprite
19:09:38 <planetmaker> though... probably it doesn't matter really
19:10:31 <andythenorth> if the windmill needs graphics edited ever again, it would be better to separate rotor
19:26:07 <Terkhen> planetmaker: GROUNDSPRITE_SWITCH on builders yard stores a sprite in var_default_ground, but I can't find any uses of that var later
19:28:28 <Terkhen> besides that, the only conditional code I see is the addition of the spriteset_ground_snow sprite to the SPRITELAYOUT_NORMAL_SNOW template, in the way I originally intended when I coded that template
19:29:24 <Terkhen> in the grain mill, there are modifications to the spritesets, but spritelayouts are not touched
19:29:38 <Terkhen> so... I don't know what you want me to do :)
19:30:46 <andythenorth> Terkhen: yes I modified the spritesets and offsets
19:31:00 <andythenorth> but modifying the advanced tile layout is beyond me currently
19:31:09 <andythenorth> so the new ground detail graphics are unused
19:31:23 <andythenorth> and iirc, the newly added sprites have no action 1
19:31:33 <andythenorth> the spritesets are numbered, so I didn't want to touch those
19:31:50 <andythenorth> it means refactoring them :(
19:31:59 <planetmaker> Terkhen: if it uses it all as you intended... fine :-)
19:32:30 <Terkhen> ground sprite, usually set by GROUNDSPRITE_SWITCH
19:32:40 <Terkhen> ground sprite overlay, that may be present or not
19:33:06 <Terkhen> andythenorth: I numbered the spritesets without paying any attention to their contents
19:33:20 <Terkhen> as their contents did not matter to the nml conversion
19:33:35 <Terkhen> they probably should get better names, but the thing was tedious enough already :P
19:34:10 <Terkhen> so regarding spritesets: rename when they are modified only, I think
19:34:38 <Terkhen> is that list I mentioned correct?
19:35:51 <andythenorth> Terkhen: yes. Ground sprite, ground sprite overlay, n buildings
19:37:09 <Terkhen> talking about tedious things... that means changing all the spritelayout templates :)
19:37:24 <Terkhen> I'll probably code it and after that... replace as needed
19:40:07 <andythenorth> the templates are the reason I didn't do it :)
19:40:12 <andythenorth> I don't understand them yet
19:41:16 <Terkhen> with this they are going to get more complicated
19:41:31 <Terkhen> the current ones are simple
19:42:44 <Terkhen> oh, I found where the ground var is loaded
19:42:55 *** Biolunar has joined #openttd
19:43:55 <Terkhen> planetmaker: why keep the different SNOW, DESERT, NORMAL templates when var_default_ground contains the correct sprite already?
19:45:00 <Terkhen> either use the old templates if the industry is not using var_default_ground, or create a new one
19:45:25 <Terkhen> also, var_default_ground might not be zero for other industries
19:46:27 <Terkhen> quite confusing; even if var_default_ground has a value, the snow/desert sprite will be drawn over it, rendering it useless
19:47:06 <Terkhen> planetmaker: industries using var_default_ground still rely on the SPRITELAYOUT_NORMAL_DESERT_SNOW_BEGIN templates to set snow/desert sprites?
19:50:16 <andythenorth> I updated Glass Works spritesheet for ground detail as well
19:51:54 <planetmaker> Terkhen: yes. Using that template allows to provide climate-specific overlay sprites
19:52:09 <planetmaker> If that is not needed, you could replace that by the one-overlay sprite thingy
19:52:21 <planetmaker> i.e. skip the climate distinction
19:53:03 <planetmaker> e.g. for snow it makes still sense as tracks probably are drawn as icy tracks instead of dirty ones or so
19:53:19 <planetmaker> one might use the same tracks, though for the other terrain types
19:53:22 <Terkhen> but that template is not made for overlays :P
19:53:41 <Terkhen> the childsprites are hacked groundsprites
19:54:34 <Terkhen> SPRITELAYOUT_NORMAL_DESERT_SNOW(spritelayout_name, ground_sprite_normal, ground_sprite_desert, ground_sprite_snow, building_spriteset, building_zextent) <--- ground_sprite_normal is the sprite to use when there is no snow, ground_sprite_desert is the sprite to use when the tile is desert and so on
19:54:47 <Terkhen> for overlays... I would do it differently
19:54:51 <Terkhen> let me write some xample code
20:00:44 <Terkhen> what I mean is: the original template is prepared for ground sprites only, and you are "abusing" it to set the overlays (although your use is less hacky than the intended use)
20:00:46 <__ln__> does anyone know english?
20:01:23 <__ln__> what kind of a pilot is an "advance pilot"? (nb: not advanced)
20:02:12 *** TWerkhoven[l] has joined #openttd
20:02:32 <planetmaker> Terkhen: agreed, my use is a bit hacked in and your suggestion looks cleaner
20:03:04 <planetmaker> Feel free to implemente a clean solution. My hack has been used only in aluminum plant and builder's yard so far
20:03:06 <Terkhen> I was lost because I was assuming that the template still received sprites, not sprite overlays :)
20:03:28 <planetmaker> I wanted to make it as little intrusive as possible
20:03:55 <Terkhen> where is FENCE_NE defined?
20:04:05 <z-MaTRiX> į think looks does not have anything to do with usefulness
20:04:06 <planetmaker> in the fences file
20:04:49 <planetmaker> templates/fences.pnml
20:05:33 <Terkhen> ok, so they are buildings
20:05:36 <planetmaker> actually... sorry, in templates/tile_fences.pnml
20:05:42 <planetmaker> yes, they're buildings
20:05:44 <Terkhen> then that could be used in the new format too
20:08:43 <Terkhen> everything in the "spritelayout_templates" file would be deprecated code after this
20:08:55 <Terkhen> should I create the new things on a different file?
20:09:51 <planetmaker> Keeps single concepts in a single file
20:10:26 <planetmaker> spritelayouts_groundaware.pnml?
20:11:22 <planetmaker> or spritelayouts_ground_overlays. But might not be as descriptive as the 1st
20:16:21 *** TWerkhoven[l] has joined #openttd
20:17:00 <andythenorth> /me adds ground sprites for brewery
20:19:06 <Terkhen> make a task with a list of the industries that need coding regarding overlays
20:20:18 <andythenorth> nah, I'll do it now
20:20:30 <andythenorth> meanwhile I have white pixels and can't defeat them
20:21:05 <andythenorth> there are no crops in the action 1
20:21:24 <andythenorth> there's some magic somewhere?
20:21:42 <andythenorth> or this isn't an action 1?
20:21:51 <Terkhen> I don't know what is that :P
20:22:12 <Terkhen> there will be unconditional ground sprite overlays? (overlays that are always drawn)
20:22:24 <Terkhen> for me those are spriteset blocks :P
20:23:00 <Terkhen> I remember something about cropping in nml constants
20:23:11 <andythenorth> error in the graphics
20:23:34 <Terkhen> so... some overlays will always be drawn? or all of them are conditional?
20:24:01 <andythenorth> ground overlays will vary according to climate
20:24:14 <Terkhen> ok, conditional then :)
20:25:36 <Terkhen> planetmaker: what is the use of spriteset_empty in the builders yard? I can't see it used anywhere
20:26:37 <planetmaker> Terkhen: shouldn't the overlays not be conditional but an adv. spritelayout?
20:26:47 <planetmaker> or at least one climate-specific one?
20:27:17 <Terkhen> they are part of an advanced spritelayout
20:28:04 <planetmaker> what about sprite: ground_overlay_sprite(climate_condition);
20:28:51 <planetmaker> thus not requiring a separate childsprite for each climate
20:29:29 <Terkhen> "normal" also has an overlay?
20:29:52 <planetmaker> every climate has an overlay
20:30:03 <planetmaker> like: always draw the default ground. And only modify it
20:30:15 <Terkhen> that was my question :)
20:30:19 <planetmaker> (sometimes modification can be "draw concrete all over")
20:30:22 <Terkhen> then we need unconditional ground sprite overlays
20:30:47 <Terkhen> GROUND_SPRITE_OVERLAY(overlay_spriteset(climate_condition))
20:31:10 <Terkhen> as the unconditional have a condition :P
20:32:07 <Terkhen> but the actual use will be something like:
20:32:23 <planetmaker> often it will be sufficient to use snow yes/no
20:32:28 <Terkhen> GROUND_SPRITE_OVERLAY(overlay_spriteset((terrain_type == TILETYPE_DESERT) + 2 * (terrain_type == TILETYPE_SNOW)))
20:33:25 <Terkhen> that returns 0 if the tile is not desert or snow, 1 if it is desert and 2 if it is snow
20:33:31 <Terkhen> maybe there is a simpler way to do it :)
20:33:51 <Terkhen> I just copied the condition from the current spritelayout template code
20:34:03 <planetmaker> well... the ground awareness variables can be re-used
20:34:12 <Hirundo> is terrain_type / 2 simple (though hacky) enough?
20:34:12 <planetmaker> they're still valid
20:35:20 <Terkhen> I don't know the "real" values of terrain_type beyond the abstraction, so for me it is simple and hacky :)
20:35:24 <Terkhen> planetmaker: where are those variables?
20:36:46 <planetmaker> in defines.pnml: var_default_ground: spriteID of default ground tile
20:37:03 <planetmaker> and created in templates/tile_ground_sprite.pnml
20:37:17 <planetmaker> it could actually store some more intermediate info, if helpful
20:37:24 <Terkhen> screw FIRS, someone is willing to pay me $$$ for coding industries :O
20:37:28 <planetmaker> it creates that info anyway
20:37:41 <Terkhen> planetmaker: thanks, let me check :)
20:38:08 <planetmaker> you could add just a storage parameter for the condition and store the appropriate values
20:38:15 <planetmaker> easy an no double checks
20:38:54 <andythenorth> Terkhen: don't forget FIRS is currently branched :O
20:38:59 <planetmaker> but the next free temporary variable is 13 :-P
20:39:00 <andythenorth> this should go in trunk
20:39:11 <pjpe> should yapf on boats be harder on the cpu than original pathfinding
20:39:25 <planetmaker> hm... actually might be
20:39:27 <pjpe> the guy who runs the server i play on says putting on yapf for boats always makes it unplayable after a while
20:39:56 <andythenorth> planetmaker: there are currently 0.7.0 and default branches
20:40:04 <planetmaker> I missed that :-)
20:40:15 <planetmaker> then we should only work on default
20:40:16 <DorpsGek> Terkhen: Commit by smatz :: r22352 /trunk/src (lang/english.txt table/settings.ini) (2011-04-19 18:47:36 UTC)
20:40:17 <DorpsGek> Terkhen: -Change: make YAPF the default pathfinder for ships, don't discourage players from using it
20:40:22 <planetmaker> and backport to 0.7 when needed
20:40:34 <Terkhen> so in theory YAPF is better for ships, after that revision
20:40:41 <planetmaker> thus not in 1.1.x
20:41:00 <Terkhen> how can I check if I'm currently on 0.7.0 or in trunk?
20:41:12 <planetmaker> tells you also the branch
20:41:29 <andythenorth> hg tip fails to tell me branch
20:41:36 <planetmaker> (hg tip only, if not default)
20:42:15 <Terkhen> planetmaker: do you mean creating a new variable?
20:42:25 <Yexo> planetmaker: hg tip doesn't work
20:42:35 <planetmaker> Terkhen: might make sense than checking for all possible ground sprites
20:42:36 <Yexo> it shows you the most recent revision in the repo
20:42:51 *** Progman has joined #openttd
20:42:51 <planetmaker> but saving that var can be done among those checks
20:42:57 <Terkhen> but there is a problem
20:43:01 <planetmaker> additionally to writing the groundsprite
20:43:07 <Terkhen> what value should be used for each climate?
20:43:41 <Terkhen> if we use for example (normal, snow, desert), industries that have normal and desert overlays but not snow have a "hole"
20:43:57 <planetmaker> yes. That's where we need the spriteset_empty ;-)
20:44:11 <planetmaker> we need to duplicate
20:44:25 <Terkhen> right now everything is already duplicated
20:44:33 <andythenorth> this sounds way complicated
20:44:50 <andythenorth> why is it complicated?
20:45:08 <planetmaker> well. In principle it's easy, if we always provide ground sprites for normal, desert, snow, tropical
20:45:12 <andythenorth> the layout is almost the same as the reference layout frosch gave for advanced action 2 tiles
20:45:13 <Terkhen> nml takes away a lot of complications, but it is still based on those crazy specs :P
20:45:17 <planetmaker> and just duplicate the real sprites where needed
20:45:33 <Zuu_> Hmm, spent 1-2 hours to cleanup my airport patch queue so that it now uses unix line endings only - got it to work as before - just to find out its soon time to go to bed and no time to implement new stuff :-p
20:45:41 <planetmaker> it gives us most flexibility while maintaining the same code everywhere
20:46:12 <Zuu_> Although I have made some useful work - integrated the AIAirportTypeList code into the same patch queue as the other changes. :-)
20:46:36 <Pinkbeast> Zuu> Wait, why isn't changing the line endings a simple matter of your regexp tool of choice?
20:46:39 <Zuu_> Decided to put it at the bottom and not at the top as otherwise I would move around the AirportType data types too much.
20:47:12 <Zuu_> Because SVN have checkd out files with windows line endings for me
20:47:23 * andythenorth is still confused :)
20:47:32 <Zuu_> Now I use hg only and no svn-hg mixture and get it with unix line endings everywhere.
20:47:33 <andythenorth> I guess I haven't read the templates :P
20:47:45 <planetmaker> Terkhen: andythenorth: after all adding 4 (or however many distinctions we want) ground sprites per unique groundsprite set won't kil us
20:47:47 <Terkhen> the new ones are not committed :)
20:48:08 <Terkhen> andythenorth: the new ones are going to be simpler actually
20:48:24 <planetmaker> it'd maybe add a couple of unnecessary sprites, but that's of no importance really. Don't you agree?
20:48:26 <Terkhen> planetmaker: 4-plicate all spritesets :)
20:48:37 <Zuu_> Pinkbeast: Also there is two handy tools for just changing a file: unix2dos and dos2unix.
20:48:53 <Zuu_> It can probably accept glob params to specify multiple files.
20:49:02 <planetmaker> Terkhen: only the groundsprite sets.
20:49:12 * krinn still wonder why ms add that extra char at end
20:49:23 <Terkhen> all spritesets used in a given spritelayout must have the same size
20:49:36 <Terkhen> specs limitation, still not circumvented by nml
20:49:39 <planetmaker> what about slope awareness then?
20:49:44 <andythenorth> how about the old method? :P
20:49:50 <Terkhen> andythenorth: what old method?
20:50:06 <andythenorth> #define the graphics filename
20:50:12 <andythenorth> repeat the template
20:50:21 <andythenorth> not really the right route now
20:50:27 <planetmaker> that misses the point ;-)
20:50:32 <Terkhen> what's the difference? they are mostly the same thing
20:50:33 <Zuu> krinn: To annoy programmers when they got patches that remove all lines in a file and then add them all again with a small change *somewhere* :-)
20:50:41 <Terkhen> #include templates get parameters via define
20:50:53 <Terkhen> these templates get parameters via TEMPLATE_NAME(param1, param2, ...
20:51:03 <Terkhen> besides that they do mostly the same thing
20:51:03 * krinn think Zuu shouldn't hit the "save" button
20:52:16 <Zuu> Well, if files are unix-only line feeds it doesn't screw up.
20:52:24 <krinn> :) you should add the tool to your commit script (if you have one) to convert the end chars
20:52:48 <planetmaker> Zuu: use sed on all files and replace \n\r by \n. Done :-)
20:52:55 <planetmaker> or easier dos2unix *
20:53:05 <planetmaker> available also for mingw
20:53:18 <Zuu> My biggest problem related to wrong line endings is however that squirrel_generate.sh updates *all* ai_*.hpp.sq files with a different line ending.
20:53:19 <Yexo> does sed actually work on the end-of-line chars?
20:53:36 <planetmaker> yes, you can make it work with eol
20:53:43 <Zuu> But it is now all solved :-)
20:53:49 <planetmaker> it's not a biginner's course in sed, though
20:54:22 <Terkhen> I don't know the best way to do the templates, I'll leave them be for today
20:54:23 <planetmaker> I did once multi-line sed replace, but I forgot how :-)
20:54:42 * Pinkbeast never learned sed/awkery, I learned Perl first :-)
20:54:48 <Zuu> planetmaker: or just make sure hg check out files without converting them to windows style and stick to that :-)
20:55:05 <andythenorth> Terkhen: you have at least made me feel better about it
20:55:14 <andythenorth> currently I am lost
20:55:32 <Zuu> but indeed the dos2unix and vice verca is usefull
20:55:38 <planetmaker> pure NML is where there are few caps, andythenorth ;-)
20:55:47 <Terkhen> andythenorth: regarding the templates themselves or the way we are using them?
20:55:59 <planetmaker> nml caps are only constants and never followed by a () term
20:56:07 <andythenorth> Terkhen you know how you feel when you look at FIRS nfo?
20:57:46 <Terkhen> I understood FIRS pnfo templates, not a single word of the rest
20:58:07 <andythenorth> looks like magic
20:58:42 <pjpe> what are the default construction costs for the default railtypes
20:58:49 <pjpe> or where could i find those
20:58:49 <Yexo> andythenorth: the current problem FIRS code has that's it's very advanced
20:59:03 <Yexo> it was already when it was NFO code, and it became even more so with proper support for groundtiles and the fences
20:59:19 <Eddi|zuHause> hm... whatever i just commited to CETS, i won't get to test it for a while... pretty busy time coming up
20:59:21 <Yexo> pjpe: start a new game without newgrfs and test?
20:59:38 <andythenorth> the good thing is that we've added ~3 people who can maintain FIRS, and lost 1
21:00:50 <krinn> 2528 for a rail on my current game
21:01:18 <planetmaker> and now change the difficulty settings, krinn ;-)
21:02:00 <krinn> planetmaker, will never do that! i love my easy settings
21:02:09 <Eddi|zuHause> krinn: with inflation the price is practically meaningless
21:02:44 <krinn> i said "in my current game" :)
21:04:06 <planetmaker> sounds good. Good night from here, too
21:13:16 <pjpe> how would i do a parameter to control costs in a rail type grf?
21:13:22 <pjpe> can i use an expression in the construction cost field?
21:15:34 *** douknoukem has joined #openttd
21:17:17 * Zuu wonders when *someone* will implement generic lists where each data type that can be viewed in lists has a list of attributes that can be included in the list. OpenTTD would ship with default columns, but the ability to select which columns to include. Even more cool if one can add columns based on an expression using item attributes. :-)
21:19:06 <Zuu> But then someone will tell me that OpenTTD is not VISUM or Excel :-p
21:26:39 * krinn has been lost after the 2 list word
21:28:29 <krinn> lol loosing faith here, just looked at my ai building rails stations and a train, just to see the industry closing
21:29:03 <Eddi|zuHause> FIRS doesn't have industry closure
21:29:14 <krinn> pathfinding took really too much time, i should look one day at the settings
21:46:53 *** TrueBrain has joined #openttd
22:59:20 *** SirSquidness has joined #openttd
23:30:38 <Eddi|zuHause> hm... are action2-ids extended bytes?
23:56:32 <Eddi|zuHause> that's probably a trap i'm running straight into... :)
23:57:27 <Yexo> aren't you writing nml code?
23:57:52 <Yexo> so you're not dealing with action2-ids at all
23:58:22 <Yexo> yes, but action2-ids can be reused
23:58:49 <Eddi|zuHause> unless the decision trees are too complex
23:59:02 <Yexo> consider actions A, B, C, D. A can have the same id as X long as it's not referenced after X (by X is fine)
23:59:19 <Yexo> sure, but they'll have to be _very_ complex before you run into that problem
23:59:55 <Eddi|zuHause> i've not even scratched the surface of what i actually want to do
continue to next day ⏵
