Log for #openttdcoop.devzone on 29th July 2010:
Times are UTC Toggle Colours
00:08:32  *** KenjiE20 has quit IRC
00:30:43  *** Webster has joined #openttdcoop.devzone
01:07:09  *** Seberoth has quit IRC
02:01:41  *** welshdragon has quit IRC
02:17:40  *** welshdragon has joined #openttdcoop.devzone
07:01:09  *** ODM has joined #openttdcoop.devzone
08:14:31  *** welshdragon has quit IRC
08:15:19  *** welshdragon has joined #openttdcoop.devzone
08:37:26  *** Alberth has joined #openttdcoop.devzone
10:09:06  *** FooBar has joined #openttdcoop.devzone
10:09:40  <FooBar> andythenorth: I've been thinking about locating most processing industries only near towns
10:39:58  *** KenjiE20 has joined #openttdcoop.devzone
10:42:15  *** Seberoth has joined #openttdcoop.devzone
10:49:34  <Brot6> Metro Track Set - Feature #1159 (Closed): unsilence renum warning (foobar) @
10:49:34  <Brot6> Metro Track Set - Revision 31:ea5c5a718985: Backed out changeset: c82853399743 (foobar) @
10:49:34  <Brot6> Metro Track Set - Revision 32:d2d699206315: Merge (r23, r31): unsuppress renum warnings (closes #... (foobar) @
10:49:35  <Brot6> Metro Track Set - Feature #1159 (Closed): unsilence renum warning (foobar) @
10:52:47  *** ODM has quit IRC
11:02:00  *** Froix has joined #openttdcoop.devzone
11:02:37  <Froix> Hello World
11:03:20  <Yexo> hello Froix
11:03:31  <Froix> hey
11:03:44  <Froix> just registered. anything i need to know?
11:04:28  <Yexo> registered where? what do you want to do?
11:05:03  <Froix> here. i'm looking at this newgrf project hosting. I'm a little lost
11:05:10  <Yexo> ah, ok
11:05:33  <Yexo> are you going to make a newgrf yourself or are you interested in helping out any of the existing projects?
11:06:11  * FooBar searches
11:06:25  <FooBar> Shanghai maglev :)
11:08:35  <Froix> that one
11:08:37  <FooBar> Your name sounded familiar :)
11:08:37  <Froix> :)
11:08:37  <Froix> what's the first step?
11:08:37  <FooBar> oh, welcome!
11:08:37  <FooBar> almost forgot that
11:08:37  <Froix> thnks
11:08:37  <Froix> "create ticket for new project".. is that it?
11:08:37  <Yexo> yes, after that you'll have to wait for Ammler to actually create it
11:08:37  <Froix> oh ok. tnx
11:09:00  <Ammler> actually, every Manager can create a new project
11:09:32  <FooBar> I knew I could, but didn't know if that would undermine authority :D
11:09:39  <Ammler> I wouldn't think so :-)
11:09:44  <Yexo> you told me before I could, but I have no idea how
11:12:18  <Ammler> Froix: basically we just need a name for your project identifier, everything else can then be edited later
11:12:33  <Ammler> (from yourself)
11:13:05  <Ammler> you like to use existing project?
11:13:11  <Ammler> like swedishrails?
11:14:26  <Froix> use? how do u mean? copy format and all?
11:15:28  <Brot6> #openttdcoop - Membership #1160 (New): Shanghai Maglev Track Set (Froix) @
11:15:43  <FooBar> yes, basically copy the code and add your own graphics. If you like your own current code, you can also keep that
11:15:52  <Ammler> copy and replace the sprites, yes
11:17:25  <Ammler> "Shanghai-Maglev-Track-Set" is a bit long identifier, you like to use that or have you a shorter proposal?
11:17:38  <Ammler> this is used in the url and repo
11:18:01  <FooBar> I think it's even too long... 20 char maximum
11:18:10  <Ammler> indeed
11:18:26  <Froix> SMTS?
11:18:28  <Froix> ok?
11:18:39  <FooBar> that would work
11:19:19  <FooBar> but I'll leave the creation of the project to Ammler, otherwise things will get very confusing right now :)
11:19:40  <Ammler> done
11:20:10  <Ammler> <-- feel free to edit
11:20:19  <Ammler> the repo will be created soon
11:21:07  <Brot6> repository /home/ottdc/hg-repos/smts registered in Redmine with url /home/ottdc/hg-repos/smts
11:21:07  <Brot6> repository /home/ottdc/hg-repos/smts created
11:23:25  <FooBar> Ammler, things like below probably mean that I have to build grfcodec myself?
11:23:27  <FooBar> /usr/local/bin/grfcodec: 1: cannot create =@@�@8: Protocol error
11:23:28  <FooBar> /usr/local/bin/grfcodec: 1: ELF: not found
11:23:29  <FooBar> /usr/local/bin/grfcodec: 1: �/: Protocol error
11:23:32  <FooBar> /usr/local/bin/grfcodec: 3: R0: not found
11:23:34  <FooBar> /usr/local/bin/grfcodec: 3: U: not found
11:23:38  <FooBar> /usr/local/bin/grfcodec: 3: p�O�x9e=w
11:24:36  <Brot6> NewGRF Meta Language - Revision 594:2f40b67cda40: Doc: add some documentation for the builtin exp... (yexo) @
11:24:36  <Brot6> NewGRF Meta Language - Revision 595:c2f7950b0b69: Doc: document all functions in the Expression c... (yexo) @
11:24:36  <Brot6> #openttdcoop - Membership #1160 (Closed): Shanghai Maglev Track Set (Froix) @
11:24:36  <Brot6> #openttdcoop - Membership #1160 (Closed): Shanghai Maglev Track Set (Ammler) @
11:24:36  <Ammler> push a test (beta) release and then you could see, if it works
11:24:59  <Ammler> FooBar: where did you get it from?
11:25:10  <FooBar> oh, I was trying to install the new devzone grfcodec/nforenum on my local ubuntu
11:25:19  <Ammler> from?
11:25:27  <FooBar> bundles
11:25:37  <Ammler> the rpm?
11:25:42  <FooBar> but appearently linux != linux
11:25:50  <FooBar> yes, as the other appeared to be the source :)
11:26:09  <Yexo> you could also try to build it yourself
11:26:13  <FooBar> ubuntu is debian based
11:26:17  <Ammler> the rpm is 64bit variant
11:26:38  <FooBar> ah, there we go
11:26:38  *** Froix has quit IRC
11:26:46  <Ammler> the rpm is mainly just for our projects itself
11:27:01  <Ammler> as soon, as this get official, cf will compile those
11:27:13  <FooBar> ah, I misread the x86_64 for just x86
11:28:01  <Ammler> well, if wanted, I can publish the 32version too
11:28:29  <FooBar> silly linux world, did they really have to go for x86 and x86_64? on windows "we" just stick with x86 and x64 :P
11:28:31  <FooBar> I can try to build first
11:28:54  <FooBar> if that works, then other versions are fine when the project is "released"
11:29:36  <Ammler> you can view the spec file to see, what packages are needed to build
11:30:28  <FooBar> I'll start with renum, as that is most critical
11:30:58  <Ammler> yeah, grfcodec doesn't have any required updated, afaik
11:31:02  *** Froix has joined #openttdcoop.devzone
11:31:41  <Froix> sorry experiencing online problems
11:32:00  <Ammler> Froix: might be start
11:32:07  <Ammler> skip the parts about SSH
11:32:14  <FooBar> no problem, it's probably not your fault ;)
11:32:34  <Froix> probably ^^
11:32:43  <FooBar> :)
11:32:51  <Ammler> and feel free to ask here, nml might not be that newbie proof yet
11:32:54  <FooBar> What operating system are you using?
11:33:06  <Froix> windows xp
11:33:09  <Ammler> and planetmaker is on vacation, but others might also be able to help
11:33:17  <Froix> ok tnx
11:33:44  <FooBar> ah, I'm probably the guy to talk to for windows-specific problems, although I haven't tried NML yet...
11:34:28  <FooBar> it could be that the makefile doesn't work for you on XP, as it doesn't work for me on Win7 either
11:34:39  <FooBar> (if you intend to use that)
11:35:47  <Yexo> makefile does work fine here on xp (with cygwin)
11:35:49  <Ammler> @topic remove -1
11:35:59  <Ammler> @services op
11:36:00  *** ChanServ sets mode: +o Webster
11:36:03  <Ammler> @topic remove -1
11:36:07  *** Webster changes topic to "Talk about things hosted and developed on | Downloads log:"
11:36:24  <FooBar> Yexo: didn't work here with cygwin nor with mingw/msys
11:36:43  <FooBar> nor with what rubi recommended of which I forgot the name
11:37:02  <Ammler> that is a "mingw bundle"
11:38:03  <FooBar> with some sprinkles, but basically it is
11:38:15  <FooBar> The bundling might be the sprinkle :)
11:38:29  <Froix> be back to test it out laters
11:38:32  <Froix> tnx guys
11:38:38  <FooBar> you're welcome
11:38:47  *** Froix has quit IRC
11:38:48  * FooBar forgot what he was actually doing
11:39:09  <FooBar> oh yes, trying to compile renum
11:39:57  <Rubidium> FooBar: Windows actually uses Win32 and x64 in MSVC, and x86 + amd64 in Program Files
11:40:36  <Rubidium> also x86_64 is more similar to all the other architectures with 64 bits, e.g. sparc64, ppc64
11:40:54  <FooBar> although inconsistent, still less confusing than x86_64 if you ask me
11:41:00  <Rubidium> even then x64 and x86 aren't that distinctive, whereas x86 and x86_64 is
11:41:02  <FooBar> I know where it came from, but it's still confusing
11:41:28  <FooBar> but then reading properly helps a great deal :)
11:41:34  *** Alberth is now known as Guest193
11:41:34  *** Guest193 is now known as Guest194
11:42:01  <FooBar> Hi Guest194
11:42:17  * FooBar couldn't resist
11:42:57  <Rubidium> although I *agree* that x86 is a very bad name in itself, given 186 and 286 are 16 bits
11:43:17  <FooBar> yes, it should be more like 386+
11:43:22  <Rubidium> so lets propose to retroactively name x86 based architectures x86_16, x86_32 and x86_64
11:43:28  *** welshdragon has quit IRC
11:44:11  <FooBar> I could live with that, but then why not just 16bit, 32bit and 64bit
11:44:28  *** Alberth1 has joined #openttdcoop.devzone
11:44:30  <FooBar> that even saves a char and doesn't include having to hold the shift key for a while :D
11:44:34  <Rubidium> because you might not be quite using an x86-ish computer
11:44:34  <Ammler> because there is sparc, ppc and such
11:44:57  <Rubidium> ppc is a bad name as well, but we'll blame MS for that
11:45:13  <FooBar> you mean "pocket pc", right?
11:45:32  <Ammler> hmm, not power pc?
11:45:48  <Rubidium> as I said... it's a bad name
11:45:50  <FooBar> microsoft can hardly be blamed for power pc, I believe that was first...
11:46:25  <FooBar> anyhoe, I just got me boost
11:46:48  *** Guest194 has quit IRC
11:47:25  <Brot6> NewGRF Meta Language - Revision 596:fca204434dc3: Codechange; move class Assignment to ast/ (yexo) @
11:47:58  <FooBar> seems ubuntu doesn't come with g++...
11:48:25  <Ammler> you might be able to install pattern devel
11:49:24  <FooBar> it does something now...
11:49:43  <FooBar> some warnings...
11:49:44  <Ammler> gcc-c++
11:50:57  <FooBar> strings.cpp:376: warning: ignoring return value of ‘char* fgets(char*, int, FILE*)’, declared with attribute warn_unused_result
11:51:08  <FooBar> and then two more of those
11:51:38  <FooBar> there is a very large renum file created though :S
11:51:47  <FooBar> is that normal? 3.9 MB
11:52:15  <Ammler> not stripped
11:52:43  <FooBar> no, I just typed "make"
11:52:47  * FooBar tries again with make remake
11:52:57  <FooBar> no... make release
11:54:33  <Ammler> yes, make release might strip
11:56:03  <Ammler> else just run strip nforenum, if you care
11:56:45  <FooBar> 423 kB looks more like it
11:58:13  <Ammler> if you like, you can collect your compile warnings and post those on the tracker
11:58:54  <FooBar> do I have access to that tracker?
11:59:05  <FooBar> grfcodec spits more warnings...
12:00:30  <Ammler> yep, added the group Managers as Reporters
12:00:50  *** welshdragon has joined #openttdcoop.devzone
12:00:50  <FooBar> thanks!
12:01:07  *** welshdragon has quit IRC
12:03:04  <Ammler> also you might report WARNINGS which should be implemented
12:03:18  <FooBar> I'm getting upx first and try again. It appears I didn't have that
12:03:28  <Ammler> make UPX= release
12:03:39  <Ammler> "UPX is crap"
12:03:45  <FooBar> I don't think that caused extra warnings, but still
12:05:02  <FooBar> well, it might be crap, but "make release" wanted it...
12:05:18  <FooBar> and I wonder if it can get the filesize down
12:05:21  <FooBar> :)
12:05:38  <Ammler> but then you have a slower grfcodec instead :-P
12:07:18  <Ammler> it might not matter at all
12:09:41  <FooBar> I don't want slower :) It's already slow enough :D
12:20:35  <Brot6> NewGRF Meta Language - Revision 597:c82c5347d852: Add: code to convert ast/deactivate to nml-code (yexo) @
12:20:35  <Brot6> NewGRF Meta Language - Revision 598:c028146938dd: Add: code to convert ast/error to nml-code (yexo) @
12:22:22  <Brot6> NewGRF Meta Language - Revision 599:82bfb0b37d22: Codechange: move item_names from ... (yexo) @
12:45:16  *** Froix has joined #openttdcoop.devzone
12:52:56  <Froix> hey
12:55:00  <Froix> buzz buzz
12:55:09  *** welshdragon has joined #openttdcoop.devzone
12:57:12  <Brot6> SMTS - swedishrails.pnml (Froix) @
12:58:44  <FooBar> hi
12:59:28  <Froix> hey
12:59:58  <Froix> how can i test out the compiler here if it works for me
13:00:47  <FooBar> have you installed tortoisehg, mingw and msys?
13:00:55  <Ammler> well, you need to fill the repo
13:01:06  <FooBar> or alternatively, tortoisehg and cygwin?
13:01:42  <FooBar> yexo sais the compiling with cygwin works for him, so that might be recommended over mingw
13:02:03  <Froix> i have mingw. i'm not sure it's working though
13:02:31  <Froix> how do i fill the repo?
13:02:40  <FooBar> type, lets see, "grep --help" in a command line window (without the quotes)
13:02:41  <Ammler> first step is anyway to use the hg repo
13:02:50  <Yexo> are you going to write nfo code (ie use grfcodec / nforenum) or nml code?
13:03:14  <Froix> nfo for now
13:03:50  <Yexo> to start pick any nfo project at the devzone, clone that repository and try to build it
13:04:16  <Froix> ok
13:05:02  <FooBar> the "example newgrf project" might be a good start
13:05:18  <FooBar> hg clone
13:05:28  <Ammler> hmm...
13:05:49  <FooBar> as you can use that as a start for your own project as well (unless you want to start with a more complete project)
13:06:34  <FooBar> Ammler: link not good?
13:06:50  <Froix> i'm there. what next?
13:07:08  <FooBar> open a command window in that directory
13:07:09  <Ammler> try to build that grf
13:08:01  <FooBar> if you're in the correct directory, type "make" (again without quotes) and press enter
13:08:05  <Ammler> FooBar: all fine, I was thinking, he likes to branch ser and replace the sprites
13:08:37  <FooBar> Ammler: Seems he likes to use NFO for now, maybe branch metrotrackset in that case...
13:08:45  <Ammler> yes :-)
13:09:06  <Froix> i'm looking at a summary. is this the clone? i can make changes to this?
13:09:51  <Ammler> clone your repo
13:10:15  <Ammler> and copy the files from an other project
13:10:48  <Ammler> or clone another project, change it, and push to your repo
13:11:25  <FooBar> if you want a big head start, you can copy the metrotrackset project. It basically has all the nfo you need, you just change the graphics and then continue from there
13:20:48  <Ammler> might be a nice starter tut
13:20:50  <Webster> Title: Hg Init: a Mercurial tutorial by Joel Spolsky (at
13:27:09  <Froix> haha this is a whole new world to me
13:28:43  <Froix> I'm looking at the metrotracks code and it uses commands i'm not aware of
13:30:59  <Froix> sorry i'm a little slow. perhaps i'm better off writing nfo codes on my notepad
13:39:24  <FooBar> there are some codes in it that are picked up by the makefile
13:39:54  <FooBar> like including files (#include) and replacing values ({{VALUE}})
13:40:22  <FooBar> where you read #include, you /think/ the contents of the file specified
13:41:32  <FooBar> it all starts with metrotrk.pnfo
13:48:36  <Brot6> GRFCodec - Bug #1161 (New): Build warnings strings.cpp (foobar) @
13:51:03  <Brot6> GRFCodec - Bug #1161: Build warnings strings.cpp (foobar) @
13:51:04  <Brot6> NewGRF Meta Language - Revision 600:91e26f7a254b: Codechange: introduce FreeNumberList as a gener... (yexo) @
13:51:04  <Brot6> NewGRF Meta Language - Revision 601:feff534dac93: Codechange: use FreeNumberList for the free par... (yexo) @
13:51:04  <Brot6> NewGRF Meta Language - Revision 602:548751dcbefc: Codechange: use FreeNumberList to keep track of... (yexo) @
13:52:59  <Brot6> GRFCodec - Bug #1162 (New): Build warnings (foobar) @
13:54:14  <Brot6> GRFCodec - Bug #1161 (Closed): Build warnings strings.cpp (foobar) @
13:54:14  <Brot6> NFORenum - Bug #1163 (New): Build warnings (foobar) @
13:54:14  <Brot6> GRFCodec - Bug #1161 (Closed): Build warnings strings.cpp (foobar) @
14:06:10  <Brot6> NFORenum - Bug #1164 (New): colour string codes not allowed in textstrings for railtypes (foobar) @
14:06:11  <Brot6> NewGRF Meta Language - Revision 603:da35eff11785: Fix (r600): some empty lines had whitespace (yexo) @
14:13:43  <Brot6> NFORenum - Support #1165 (New): action3 railtypes default ID (foobar) @
14:30:32  <Brot6> Metro Track Set - Bug #1166 (Assigned): glitches in non-railtype ogfx bridges (foobar) @
14:30:32  <Brot6> Metro Track Set - Support #1167 (Assigned): test release (foobar) @
14:33:01  <FooBar> Ammler: for beta release, would 1.0.0-beta work as tag?
14:33:12  <Ammler> yes
14:33:21  <FooBar> ok, then expect a beta release ;)
14:33:29  <Yexo> better use beta1 or something like that
14:33:34  <Ammler> -+ and _
14:33:38  <Yexo> "1.0.0-beta1" of course
14:33:55  <Ammler> oh, and .
14:37:48  * FooBar rolls back
14:37:50  <Ammler> the ugly thing about is that 1.0.0-beta1 > 1.0.0
14:38:09  <Ammler> but that should bother you
14:38:12  <FooBar> I can do 0.9, I don't care
14:38:12  <Ammler> n't
14:38:39  <Ammler> it is just for packaging
14:38:56  <FooBar> well, this release is just for testing ;)
14:39:02  <Ammler> If I would make a rpm, I would change that to 1.0-beta1
14:39:16  <Ammler> 1.0-beta1 < 1.0.0
14:39:32  <Ammler> yeah, we don't package newgrfs yet
14:39:32  <FooBar> that is interesting, I like that
14:39:34  <Ammler> :-)
14:40:07  <Ammler> and for example openttd 1.0.2-RC1 is
14:40:51  <Ammler> or else I would need to make the real release
14:41:04  <FooBar> too many numbers ;)
14:41:43  <Ammler> yes, that is why "we" workaround with <old>.90
14:42:08  <Ammler> but ususally you don't package testings
14:42:30  <FooBar> true, but in this case you want a beta ;)
14:42:47  <Ammler> well
14:43:14  <Ammler> that was for checking if your set does build on the server,since you don't have nightly
14:43:40  <FooBar> exactly
14:44:01  <Ammler> you should still enable nightly as kind of regression test for nforenum and grfcodec :-P
14:44:43  <FooBar> I can, but I think after tomorrow there's not much regression as then "it's done"
14:44:54  <Ammler> that is the idea begind
14:44:58  <FooBar> then users have to find errors first
14:45:03  <Ammler> your set doesn't chagne, but renum and codec does
14:45:20  <Ammler> and so you have a good reference for tests
14:45:21  <FooBar> are you rebuilding with no changes to the set then?
14:45:30  <Ammler> yes, but not publish
14:45:43  <FooBar> ok, then I will enable nightly and not do a beta
14:46:21  <Ammler> there is nutracks, but that has a lot errors currently
14:46:57  <FooBar> I have two different warnings on metrotrackset with newest renum
14:47:18  <Ammler> yeah, you have posted those, I guess
14:47:26  <FooBar> yes, exactly
14:48:09  <FooBar> both might be considered "not a bug" though, but we'll see
14:49:26  <Brot6> Metro Track Set - Support #1167 (Closed): test release (foobar) @
14:49:26  <Brot6> Metro Track Set - Support #1167 (Closed): test release (foobar) @
14:49:31  <Ammler> there are still some string codes not working for description, like size
14:50:42  <Brot6> Metro Track Set - Revision 33:2bf053d6ccc2: Change: enable nightly compile (foobar) @
14:51:05  <FooBar> now to wait until it's actually "night" :P
14:51:43  <Ammler> yeah, but have early night :-)
14:52:27  <FooBar> true, maybe call it "eveningy" :P
14:53:27  <FooBar> haven't you talked about removing the word "nightly" and only keep r+number?
14:53:43  <FooBar> I remember something like that passing by, not the outcome though
14:53:53  <Ammler> well, the server ususally does nightly
14:54:06  <Ammler> but when you make custom builds, they shouldn't be called that
14:54:11  <FooBar> I don't mind really, just wondering
14:54:51  <Ammler> that was the idea behind, don't know, I guess, we didn't change that
14:55:53  <FooBar> I think the word "nightly" has a well-defined meaning in openttd world. People not using openttd nightly probably don't use newgrf nightly either
14:56:37  <Ammler> those people use bananas only
14:57:05  <Ammler> so if you upload a nightly to bananas, they might use it
14:57:19  <FooBar> true, but that doesn't happen too often
14:57:54  <Ammler> for unreleased sets maily
15:07:54  <Brot6> NewGRF Meta Language - Revision 604:bfbe3612b566: Codechange: introduce BaseAction, a base class ... (yexo) @
15:09:00  <Alberth1> \o/
15:12:50  *** Froix has quit IRC
15:14:27  <Rubidium> FooBar: would you be so kind as to disclose the "global" CFLAGS that are passed to gcc? Primarily because the warnings you report as a bug are as far as I can see of a CFLAG setting that is quite pedantic
15:15:13  <FooBar> happily, if I knew how to...
15:15:32  <Rubidium> FooBar: OpenTTD nightlies are silently being called openttd-trunk-rXYZ, not openttd-nightly-rXYZ :)
15:15:49  <FooBar> hmmm...indeed they are :)
15:16:03  * FooBar wonders why people still call them nightlies...
15:16:15  <FooBar> "trunkies" :P
15:16:20  <FooBar> anyhow, you were saying?
15:16:51  <Rubidium> probably because the frontpage says "download nightly" :)
15:17:13  <FooBar> lot of inconsistensies today...
15:17:28  <FooBar> anyways, I kept all settings default for both grfcodec and nforenum
15:17:36  <FooBar> just downloaded the source and built it
15:17:56  <FooBar> so CFLAGS is as the makefile defines them
15:18:26  <Rubidium> FooBar: what does export say?
15:18:30  <Ammler> "trunk" is the branch, so this ok, nightly scheduled
15:19:02  <Ammler> we could call ours default :-)
15:19:37  <FooBar> Rubidium: now you really have to help me: what do I do to have export tell me anything?
15:19:52  <Alberth1> type 'export'  :)
15:20:17  <Alberth1> and look for a line with CFLAGS
15:20:28  <Rubidium> open a console/terminal/command prompt and type export and do not forget pretting the "enter" key :)
15:20:47  <FooBar> thanks
15:21:00  <FooBar> the console I figured I had to use :)
15:21:08  <Ammler> if too much output add "| grep FLAG"
15:22:01  <FooBar> there's no such thing as CFLAGS
15:22:14  <FooBar> I'm in the dir with grfcodec
15:22:36  <Rubidium> excuse me
15:23:12  <FooBar> should I have built first?
15:23:28  <Rubidium> oh fracking frack... stupid morons at Ubuntu did it again... when are they fracking go to learn that making the compiler pedantic by default is going to make a lot of people annoyed?
15:26:49  <Rubidium> so now I have to fracking search for the stuff they actually changed so I can reproduce the issues
15:27:19  <FooBar> highlight me if I need to try something different
15:31:00  <Ammler> Rubidium: or set it a bit less pedantic in the Makefile?
15:32:00  <Rubidium> Ammler: yeah... good idea... what CFLAGS do I need for that?
15:32:17  <Ammler> ok, I see :-P
15:33:17  <Rubidium> I've got a rough idea of the passed CFLAGS though :), but need to be sure
15:40:38  <Rubidium> ofcourse the only "clear" place to find it is in the changes they make to the package sources...
15:42:25  <Ammler> don't you need to know that for OpenTTD anyway?
15:44:10  <Rubidium> not really because we're probably setting even more pedantic CFLAGS than Ubuntu
15:44:49  *** frosch123 has joined #openttdcoop.devzone
16:18:54  <Brot6> metrotrackset: update from  to r33 done (1 errors) -
16:20:21  <Brot6> nforenum: update from r406 to r407 done -
16:20:46  <Brot6> nml: compile of r604 failed -
16:20:54  <Brot6> Following repos didn't need a nightlies update: 2cctrainset (r573), 32bpp-extra (r36), airportsplus (r52), comic-houses (r71), firs (r1076), fish (r386), grfcodec (r178), heqs (r371), newgrf_makefile (r124), nutracks (r86), ogfxplus (ERROR r41), opengfx (r469), openmsx (r91), opensfx (r97), snowlinemod (r15), swedishrails (r140), worldairlinersset (r659)
16:22:21  <Brot6> 32bpp-extra: rebuild of r36 done (3584 errors) (Diffsize: 341) -
16:22:25  <Ammler> mäh, it isn't installed
16:26:39  <Brot6> nutracks: rebuild of r86 done (164 errors) (Diffsize: 243) -
16:27:08  <Brot6> ogfxplus: update from r40 to r41 done -
16:29:44  <Brot6> Following repos rebuilds successful without any difference to earlier nightlies builds: 2cctrainset (1 errors), airportsplus, comic-houses (3 errors), firs (5 errors), fish (1 errors), heqs, metrotrackset (1 errors), newgrf_makefile, opengfx, snowlinemod, worldairlinersset
16:32:59  <Brot6> NFORenum - Bug #1164 (Closed): colour string codes not allowed in textstrings for railtypes (foobar) @
16:32:59  <Brot6> NFORenum - Bug #1164 (Closed): colour string codes not allowed in textstrings for railtypes (yexo) @
16:32:59  <Brot6> NFORenum - Revision 408:2fffe87d5ccd: Fix [#1164]: colour string codes are allowed in railtype st... (yexo) @
16:35:10  <Alberth1> Ammler: ERROR directory does not seem to exist, is that why the url is broken?
16:35:33  <Alberth1> (of nml)
16:39:16  <Yexo> about I'm not sure what the best solution is
16:40:07  <Yexo> we could disable warning 100 completely for railtypes?
16:40:19  <Yexo> Rubidium / FooBar: any comments on that one?
16:40:33  <Yexo> or frosch123?
16:40:36  <FooBar> you're lucky, I just returned ;)
16:40:43  <Ammler> Alberth1: it doesn't install it either
16:41:41  <FooBar> I think disabling that warning for just railtypes might do the trick, as I don't see an other solution
16:41:43  <frosch123> imo it is wrong to use "icons" for the default
16:41:53  <frosch123> it should go to some fail-state
16:42:05  <frosch123> or everything will show the icons if we add more cases
16:42:17  <Yexo> the default isn't used for railtypes
16:42:35  <FooBar> I was about to say that: something that isn't defined, isn't shown
16:43:22  <FooBar> say if I don't define thie icons, it falls back to the default icons of the first railtype; it doesn't use <default>
16:43:29  <frosch123> my assumption is that ottd resolves the default if one of the cases is missing. if that is not the case, i guess default would only be used if we get callbacks
16:44:02  <Yexo> the default is read but ignored by openttd (newgrf.cpp:3919)
16:44:15  <Rubidium> Yexo: I've got no real clue about railtypes, so can't say anything useful about them; I'm working on the compile warnings though
16:44:24  <Yexo> ok
16:45:12  <FooBar> I can easily define a different default, but that would mean adding some pointless action2 that has no meaning and is never used
16:45:29  <Yexo> you can also give an invalid action2 id as default
16:45:34  <Yexo> but then you'd probably get another warning
16:45:37  <FooBar> :)
16:45:40  <FooBar> exactly
16:45:52  <Yexo> hmm, actually that might work
16:45:57  <Yexo> it is exactly what nml does :p
16:47:15  <FooBar> well, solving one error by displaying another is not really solving ;)
16:51:05  <frosch123> we should add some railtype callback to make use of the defaultcase :p
16:51:12  <frosch123> maybe railtype availability?
16:51:22  <Brot6> NewGRF Meta Language - Revision 605:2590d45d8107: Codechange: Reduce code duplication in the real... (Hirundo) @
16:53:22  <Brot6> Metro Track Set - Feature #1168 (New): snowy depot for railtypes (foobar) @
17:00:48  <FooBar> frosch123: that would be a good one. Pikka(?) already suggested an option to set when a railtype should be available on top of the engine availability
17:02:17  <frosch123> i am thinking about a callback which can check the date, and get some extra variables which tell stuff like: there are engines which can run on the rail, there are engines which cannot run on any other available track, ....
17:04:29  <FooBar> be my guest :)
17:05:51  <Brot6> GRFCodec - Revision 179:aed04cef5787: Fix: "format not a string literal" warnings (Rubidium) @
17:07:30  <Brot6> GRFCodec - Revision 180:b9b47515ea34: -Fix: comparison that is always true (Rubidium) @
17:40:23  *** frosch123 has quit IRC
17:40:38  <Brot6> GRFCodec - Revision 181:8364082c2756: Fix: more warnings about not passing string literals to printf (Rubidium) @
17:40:38  <Brot6> GRFCodec - Revision 182:fbdf71e0294b: -Fix: missing initializer warning (Rubidium) @
17:40:38  <Brot6> GRFCodec - Revision 183:2102c6089cb2: Fix: do not ignore return value of fread (Rubidium) @
17:40:39  <Brot6> GRFCodec - Revision 184:b25ed8af0593: Fix: do not ignore the return value of fscanf and fgets (Rubidium) @
17:42:52  <Brot6> GRFCodec - Revision 185:deba5f884f3f: Change: detect upx instead of making people disable it expl... (Rubidium) @
17:44:11  <Brot6> NFORenum - Revision 409:c16f41427808: Change: detect upx instead of making people disable it expl... (Rubidium) @
18:00:51  <Brot6> GRFCodec - Revision 186:2973c5d83c95: Fix: do not ignore the return value of fwrite (Rubidium) @
18:00:51  <Brot6> GRFCodec - Revision 187:655fd76fd42e: Change: add more (pedantic) compiler warnings (closes #1162) (Rubidium) @
18:00:51  <Brot6> GRFCodec - Bug #1162 (Closed): Build warnings (Rubidium) @
18:06:01  <Brot6> NFORenum - Revision 410:a80398c19576: Fix: "type qualifiers on function return type" warning (Rubidium) @
18:09:34  <Rubidium> FooBar: your compile issues should now be fixed, although I haven't thoroughly tested the changes yet
18:09:56  <FooBar> I'll try in a short while
18:10:58  <Brot6> NFORenum - Revision 411:6c448c48a81d: Fix: do not ignore the return value of fgets (Rubidium) @
18:10:58  <Brot6> NFORenum - Revision 412:11070125474a: Change: add more (pedantic) compiler warnings (closes #1163) (Rubidium) @
18:10:58  <Brot6> NFORenum - Bug #1163 (Closed): Build warnings (Rubidium) @
18:21:50  <FooBar> grfcodec builds without warning
18:22:54  <FooBar> and so does renum. Well done!
18:23:35  <andythenorth> evening
18:23:54  <FooBar> hi Andy
18:24:04  <FooBar> got my message from this morning?
18:25:42  <FooBar> about locating industries near towns
18:26:45  <andythenorth> I saw the one in the forums, not others
18:26:49  <andythenorth> was it pm or irc?
18:27:01  <FooBar> irc
18:27:09  <andythenorth> ah
18:27:20  <andythenorth> I have absolutely no idea how to see those messages sorry
18:27:23  <FooBar> "I've been thinking about locating most processing industries only near towns"
18:27:49  <andythenorth> it's an idea, but would have certain problems
18:27:50  <FooBar> well, it was just a highlight here in the channel, but I don't blame you for missing it
18:28:14  <FooBar> i think heavy industry should not be located near town, with pollution and everything
18:28:28  <andythenorth> my principal objections are....
18:28:38  <FooBar> but other processing industries, especially early ones should IMO
18:28:43  <FooBar> let's hear them :)
18:28:49  <andythenorth> (1) it annoys players in PBI (planetmaker has specifically asked for *not* doing this)
18:29:28  <andythenorth> (2) it makes gameplay harder.   Building routes in constrained spaces around towns becomes less fun after a bit
18:29:51  <andythenorth> (3) it might slow down industry generation
18:29:56  <andythenorth> however...
18:30:10  <andythenorth> ...some players have also requested it
18:30:24  <FooBar> (2) was a pro for me, but given that PBI /and/ ECS have it, it makes (1) a con for me as well...
18:30:39  <FooBar> i.e., we don't need to have what others have
18:31:09  <andythenorth> (A) it's already in place for Brewery, Bakery - using built-in methods
18:31:44  <andythenorth> (B) it would be quite easy to adapt clustering code so landscape generator places certain industries near town, but players can build anywhere
18:32:15  <andythenorth> FooBar: make a list of industries you think should locate near town?
18:33:01  <FooBar> allowing players to build anywhere is fine with me; actually preferred... you could simulate having to relocate an industry due to town growth...
18:33:15  <FooBar> ok, let's make a list. I'll add it as suggestion to the tracker
18:34:08  <andythenorth> I was also thinking of for certain industries enforcing min / max distances to other industry types
18:34:21  <andythenorth> e.g. an update of conflicting industry types, but more under our control
18:35:15  <FooBar> minimum distance is probably not necessary, except for clustering industries
18:35:37  <FooBar> wait...thats maximum...
18:35:44  * FooBar tries again
18:35:54  <FooBar> *maximum* distance is probably not necessary, except for clustering industries
18:37:48  <andythenorth> perhaps not
18:38:04  <andythenorth> depends if we want to be sure a resource isn't too far from a processor
18:38:29  <andythenorth> I've started a new game where fishing grounds are really too far from fishing harbours for example
18:39:12  <andythenorth> I think max distance might require a logical condition that was never met though!
18:42:51  <FooBar> well, maybe for specific cases, but generally I don't really care
18:44:11  <andythenorth> min distance is to prevent, e.g. gravel pit next to cement works
18:44:18  <andythenorth> arguably that's valid in RL
18:44:27  <andythenorth> so I'm not sure whether to prevent it or not
18:45:22  <Brot6> FIRS Industry Replacement Set - Feature #1169 (New): locate industries near town (foobar) @
18:45:28  <FooBar> well, its not useful for gameplay, as it's not profitable if things are next to each other
18:46:08  <andythenorth> it also causes some station pickup / dropoff issues because stations overlap both industries
18:46:10  <FooBar> well, that's the list in the link
18:46:18  <andythenorth> however about 6 tiles min distance might be enough
18:46:24  * andythenorth reads ticket
18:46:59  <FooBar> I limited it to /classic/ industries, modern industries needn't locate near towns
18:47:30  <FooBar> also the limitation could be lifted after a certain year
18:47:43  <andythenorth> can we play yes / no on these?
18:47:56  <Rubidium> maybe
18:48:03  <andythenorth> I've just updated the ticket btw - indicating the ones done
18:48:05  <FooBar> sure, but in my case all are "yes" :P
18:48:27  <andythenorth> blacksmith: yes
18:48:38  <andythenorth> dock yard: maybe
18:48:54  <andythenorth> actually yes
18:49:08  <Brot6> FIRS Industry Replacement Set - Feature #1169 (New): locate industries near town (foobar) @
18:49:10  <andythenorth> furniture factory: no imo
18:49:15  <andythenorth> dairy: no imo
18:49:42  <andythenorth> hmm
18:49:51  * FooBar has phonecall
18:49:55  <andythenorth> :)
18:50:29  <Brot6> FIRS Industry Replacement Set - Feature #1169 (New): locate industries near town (foobar) @
19:00:12  <Ammler> the problem with industires near town is, that "near town" doesn't change when a town grows, so you will have no free tiles on big cities anymore to build something
19:14:02  <FooBar> well, that took a while but I'm back
19:14:36  <Alberth1> that was also the case with subsidies, but that is solved
19:15:41  <FooBar> anyways, my basic reasoning for locating towns near those industries is that "back in the days" people lived close to their work, as they had no fast means of transportation. They may have used a bike, or otherwise went on foot
19:17:20  <FooBar> so the restriction could apply until, say, 1950. After that, when cities grow, industries can locate everywhere
19:22:19  <Ammler> or industries are able to clear houses to make space
19:28:50  <Alberth1> that does not help, as the user cannot build a station near it then
19:30:42  <andythenorth> FooBar: it would leave a lot of bare game land....and make for *very* crowded towns
19:31:06  <andythenorth> I'm not specifically against it, but I wouldn't apply it as much as you're proposing, for both gameplay and reality reasons :)
19:31:44  <FooBar> shall we continue the yes/no game and see where we get?
19:32:01  <FooBar> or maybe a yes game from your side if that are less industries :)
19:34:09  <FooBar> Or, for me those would be some sort of minimum:
19:34:11  <FooBar>     * bakery (done)
19:34:12  <FooBar>     * blacksmith
19:34:14  <FooBar>     * brewery (done)
19:34:15  <FooBar>     * dock yard
19:34:17  <FooBar>     * lumber yard
19:34:19  <FooBar>     * fishing harbour (done)
19:34:20  <FooBar>     * glass works
19:34:22  <FooBar>     * junk yard (done)
19:34:23  <FooBar>     * machine shop
19:34:26  <FooBar>     * marina
19:34:38  <FooBar> the in-town list still applies
19:37:21  <andythenorth> FooBar how many tiles is "in town"?
19:37:38  <FooBar> replace town building
19:38:15  <FooBar> those things are all one tile, maybe the supermarket 2 tiles
19:38:55  <FooBar> wait, the gas station is 2 tiles as well
19:40:33  <andythenorth> yes
19:40:39  <andythenorth> in-town all make sense
19:40:48  <andythenorth> how near is near-town?
19:42:09  <FooBar> 15 tiles or so I guess
19:43:24  <FooBar> from town edge, not from center
19:43:56  <andythenorth> dock yard: yes
19:44:01  <andythenorth> lumber yard: not sure
19:44:23  <andythenorth> glass works.  not sure.  Produces far should they be transported?
19:44:40  <FooBar> to other town also?
19:44:45  <andythenorth> hmm
19:44:47  <andythenorth> maybe
19:45:17  <FooBar> cargodist should help with that in due time
19:45:24  <andythenorth> machine shop: no strong feelings
19:45:26  <andythenorth> marina: yes
19:47:54  <FooBar> looking at cargo, lumber yard and machine shop are very similar, both only produce supplies
19:48:18  <andythenorth> yup
19:48:30  <andythenorth> lumber yard was added to balance machine ship
19:48:32  <andythenorth> shop /s
19:48:38  <andythenorth> machine shop was dominating the whole game
19:49:18  <FooBar> I used both in my recent game
19:49:40  <andythenorth> FooBar: exactly :)
19:52:55  * FooBar ponders if it's useful to cluster secondaries that produce the same thing, like an industrial parks
19:53:29  <andythenorth> it is if they produce same from different inputs
19:53:40  <andythenorth> I had a game with textile mill, foundry etc nearby
19:53:42  <FooBar> that's what I was looking at
19:53:44  <andythenorth> all producing goods
19:53:58  <andythenorth> in my game they happened to cluster like that anyway
19:54:07  <FooBar> for instance paper mill, plastics plant, flass works and metal foundry all produce goods+mnsp
19:54:22  <FooBar> that's glass works by the way :)
19:55:02  <FooBar> dairy/meatpacker/sugarrefinery
19:55:11  <andythenorth> it's a thought
19:55:16  <andythenorth> could be a random chance
19:55:29  <andythenorth> once the code is in place it's quite easy to fool around with clustering
19:55:34  <andythenorth> very boring to test though :P
19:55:51  <FooBar> not necessarily boring, just takes a very long time
19:56:01  <FooBar> i.e. play a game with it and see if it works :)
19:56:30  <FooBar> we could also employ the public for that: if a lot complain, it's no good
19:56:41  <andythenorth> it's quite easy to test clustering - don't need a test game :)  Just generate map lots of times :P
19:57:16  <FooBar> oh, that kind of testing :)
19:57:24  <FooBar> I thought like seeing if it's useful
19:58:24  <FooBar> still, using the public could work. For example, I don't test metrotrackset in TTDP, I just assume it works and I assume I will be notified if it doesn't :D
20:01:22  <andythenorth> I just assumed farm clustering would work :)  It did
20:02:01  <FooBar> :)
20:02:06  <FooBar> well, there you go
20:02:29  <andythenorth> FooBar: do you know how to implement the location restrictions for the industries you suggested?
20:02:40  <FooBar> I have no clue
20:02:53  <FooBar> I usually tend to suggest things without looking if it's possible
20:03:15  <andythenorth> it's close to easy
20:03:16  <FooBar> thinking out of the box ;)
20:03:22  <andythenorth> there are stubs in place for cb28 already
20:03:30  <andythenorth> there is location code for farms and mines already
20:03:49  <andythenorth> it is just a bit of work to adapt to the industries you suggested
20:03:58  <andythenorth> needs a bit of up-front design though
20:04:13  <andythenorth> want to implement it?
20:04:23  <FooBar> what do you mean by "up-front"?
20:05:10  <FooBar> I don't want to implement it /right now/, but it's something I could tend to in the near-distant future
20:05:39  <andythenorth> FooBar: 'up-front' as in, work out a couple of details first :)
20:05:51  <FooBar> ah ok, makes sense
20:07:25  <FooBar> I do also want to work on a few of my own projects first: reuse the code of metrotrackset for transrapidtrackset. For the latter I also intended to redo the graphics, but I don't fancy drawing at the moment, so that's a good thing (for FIRS)
20:07:47  <andythenorth> np with mr
20:07:48  <andythenorth> me /s
20:08:15  <FooBar> I also have some secret project in mind which involves a base graphics set and maybe one day work. Can't say anything about that yet though
20:09:16  <FooBar> dutch tram set is on hold, as that works reasonably flawless
20:09:45  <FooBar> besides, I rather have someone helping me with that: drawing additional vehicles :P
20:13:44  *** Alberth1 has left #openttdcoop.devzone
20:15:01  <FooBar> I think we'll should put the "locate near town" on ice. It's good to have discussed it, but I think there are more useful things to add first
20:15:08  <Brot6> FIRS Industry Replacement Set - Feature #1170 (New): clustering of certain industries (foobar) @
20:19:44  <Brot6> #openttdcoop - Revision 115:29c718d84f0c: [Compiler] Fix: different repo/distro version get diffe... (Ammler) @
20:19:44  <Brot6> #openttdcoop - Revision 116:00b8db94ff78: [Compiler] Add parameter -c to clean the chroot (Ammler) @
20:20:20  <Brot6> nml-test: compile of r584 failed -
20:29:39  *** frosch123 has joined #openttdcoop.devzone
20:35:17  <andythenorth> FooBar: a FIRS game starting in 1830 kind of sucks :)
20:42:01  <FooBar> why? vehicles too slow (or none at all)?
20:42:29  <FooBar> 1900 worked for me last time
20:42:46  <andythenorth> cargo chains...incomplete :)
20:43:00  <andythenorth> UKRS 2 vehicles quite inadequate capacity
20:43:02  <andythenorth> no ships :o
20:45:00  <FooBar> well, I guess some industries are still missing...
20:45:21  <andythenorth> blacksmith could be an easy add
20:46:28  <FooBar> how about adding missing industries as differently coloured boxes?
20:47:06  <FooBar> that way the chains are there, we could look at the economies
20:47:23  <andythenorth> yup
20:47:40  * andythenorth wonders whether to add it to this test game or not
20:47:47  <andythenorth> adding industries is ok
20:47:53  <andythenorth> changing existing ones is not :)
20:48:17  <FooBar> depends what you change really...
20:50:22  <FooBar> but I like the boxes idea. Worked fine for OpenGFX (but in a different way), should also work fine for FIRS as well
20:50:41  <andythenorth> yup
20:53:40  <Brot6> FIRS Industry Replacement Set - Feature #1171 (New): add missing industries as boxes (foobar) @
20:54:49  <andythenorth> I'd do the blacksmith now...but bedtime :)
20:55:52  <FooBar> ok, good night!
21:19:27  <Brot6> nml: update from r585 to r606 done -
21:20:23  <Brot6> NewGRF Meta Language - Revision 606:d994b61bfda8: Revert (r590): the buildsystem doesn't install ... (Ammler) @
21:22:07  *** frosch123 has quit IRC
21:22:09  <Brot6> swedishrails: compile of r140 failed -
21:22:49  <Ammler> Yexo:
21:22:52  <Ammler> any idea?
21:23:10  <Ammler>
21:23:21  <Yexo> that's the change yo ujust reverted, right?
21:23:24  <Ammler> wrong paste, this is for you ^
21:23:30  <Yexo> dunno, alberth committed in the first place
21:23:32  <Ammler> wrong paste, this is for you ^
21:23:47  <Yexo> working on it already :p
21:23:55  <Ammler> some lags :-)
21:24:06  <Yexo> something to do with my codechanges today :(
21:28:18  <Yexo> fixed
21:29:02  <Ammler> I guess, it is fine enough, using those packages for installation tests
21:29:27  <Ammler> I don't setup a testsuite for nml now, maybe with the release
21:29:30  <Brot6> NewGRF Meta Language - Revision 607:c82daae4d521: Fix (r602): FreeNumberList needs at least one s... (yexo) @
21:30:19  <Ammler> why didn't the regression test find it?
21:30:41  <Yexo> because the regression tests are not extensive enough yet
21:36:03  <Rubidium> Ammler: if you're running regression tests; could you put grfcodec and nforenum through its paces as well?
21:37:29  <Ammler> you mean in the nml test?
21:37:37  <Ammler> or when we setup a testsuite?
21:38:38  <Rubidium> nah, just a rebuild run :)
21:38:55  <Rubidium> I've done some changes all over the code that might backfire under some conditions
21:39:08  <Rubidium> and I rather have that tested before I'm going to do any further work
21:39:20  <Ammler> well, we rather should add the regression test to the packages, so they fail
21:40:24  <Rubidium> don't have enough NFO knowledge to actually get that done :)
21:40:41  <Ammler> using the nml tests?
21:41:46  <Yexo> using the nml tests for nforenum/grfcodec is not a good idea as nml only generates a subset of all valid nfo code
22:07:12  <Ammler> [18:29] <Brot6> Following repos rebuilds successful without any difference to earlier nightlies builds: 2cctrainset (1 errors), airportsplus, comic-houses (3 errors), firs (5 errors), fish (1 errors), heqs, metrotrackset (1 errors), newgrf_makefile, opengfx, snowlinemod, worldairlinersset <-- isn't this a good confirmation for you then?
22:09:19  <Rubidium> yeah, I'm doing OpenTTD stuff at the moment anyhow :)
22:50:39  *** Seberoth has quit IRC
23:03:21  <Brot6> Metro Track Set - Revision 36:4f02a0bcf83a: Feature: snowy ogfx sprites for railtypes (closes #1168) (foobar) @
23:03:21  <Brot6> Metro Track Set - Bug #1166 (Closed): glitches in non-railtype ogfx bridges (foobar) @
23:03:21  <Brot6> Metro Track Set - Feature #1168 (Closed): snowy ogfx sprites for railtypes (foobar) @
23:14:06  *** FooBar has quit IRC

Powered by YARRSTE version: svn-trunk