Log for #openttdcoop.devzone on 31st May 2011:
Times are UTC Toggle Colours
00:12:34  *** KenjiE20 has quit IRC
05:43:34  <planetmaker> <-- if you feel like, Terkhen add some shots of what you find the nicest places or notable things ;-)
05:43:35  <Webster> Title: Transport Tycoon Forums View topic - pm's random screenshots (at
06:47:57  <Terkhen> ok :)
06:54:08  *** ODM has joined #openttdcoop.devzone
07:07:33  <Terkhen> you did not upload the savegame :P
07:14:47  <planetmaker> I left that for you :-P
07:14:57  <planetmaker> But good point
10:39:41  *** KenjiE20 has joined #openttdcoop.devzone
11:32:53  *** Lakie has joined #openttdcoop.devzone
11:34:18  *** Aineko has joined #openttdcoop.devzone
11:35:53  <Aineko> hi, can someone help me with compiling openttd? i'd like to have both the 32bpp-ez as well as the clipboard-features.
11:37:02  <Aineko> i tried downloading the sources for 32bpp-ez, applying the clipboard-patch (worked for the normal openttd sources) and compile, but i get errors compiling ai/api/ai_rail.cpp
11:39:06  <Yexo> Aineko: "I get errors" is too vague, please pastebin the complete error message
11:39:23  <Yexo> also: did you get any warnings/errors when applying the patch?
11:42:01  <Aineko> i get some failed HUNKS while patching, probably why compiling fails lateron
11:42:17  <Yexo> yep, you'll need to fix that first
11:42:46  <Aineko> any hints on how to do that?
11:42:59  <planetmaker> that's a genuine programming task
11:43:10  <Aineko> okay, then i guess that's not for me ;)
11:43:14  <planetmaker> and needs the knowledge of what the patch tries for fix where and how
11:43:16  <Yexo> look at which files failed, read the *.rej files that are created and read those
11:43:29  <planetmaker> ^ that might help
11:43:33  <Yexo> to fix it properly you need at least some programming knowledge
11:43:53  <planetmaker> :-) It was my way into OpenTTD programming ;-)
11:44:33  <Aineko> well' i have been dabbling in perl programming, but honestly, i think i rather decide between higher resolution graphics and copy/pasting than dive into open-ttd programming ;)
11:44:41  <planetmaker> But I had good and patient teachers ;-)
11:45:09  <planetmaker> and still have ;-)
11:45:18  <Aineko> yeah, that helps a lot :)
11:45:32  <planetmaker> will say: the other devs ;-)
11:46:11  <Aineko> oh btw, is there a subversion or mercurial download for the 32bpp-ez version of openttd?
11:46:19  <planetmaker> mercurial
11:46:39  <planetmaker>
11:47:19  <planetmaker> hm...
11:47:24  <Aineko> nice, thank you :)
11:48:34  <planetmaker> I might be wrong, that might be only the graphics
11:48:52  <planetmaker> <-- maybe that's the right one as mercurial queue against trunk
11:51:47  <Aineko> i think i know now why the copy/paste-patch doesn't work with 32bpp-ez: it's based on r22441, while 32bpp-ez seems to be based on r21891
11:52:53  <planetmaker> that's not a principle problem. Do both apply to trunk themselves? A patch can get outdated...
11:53:45  <Yexo> the newest copy/paste patch is _very_ intrusive
11:53:56  <planetmaker> he
11:54:20  <planetmaker> I didn't look at any c&p patch for well over a year, I gues, if not two
11:55:01  <Aineko> well, the readme for copy/paste said to get svn-version 22441, apply patch, then try to update and compile if no conflicts occur. so would it be possible (in principle) to get openttd r21891, apply ez-patch, update to 22441, apply copy/paste-patch and then update & compile?
11:56:57  <Yexo> it might work, but most likely not
11:57:17  <Yexo> I think the problem in this case is that both ez-patch and copy/paste try to modify some of the same parts of the code
11:59:24  <Aineko> okay, i guess ill just get the high-res graphics and get rid of the copy/pasting. it's just for my lazyness anyway ;)
12:03:23  <Aineko> anyway, thanks for your help and have a nice day :)
12:04:32  *** Aineko has left #openttdcoop.devzone
13:38:07  <Ammler> do we need private tracker?
13:38:56  <Ammler> I need to decide if we shall stay on Redmine (1.2) or switch to ChiliProject (2.0)
13:41:50  <planetmaker> what is a private tracker?
13:42:09  <planetmaker> and what other things are to be considered for that decision?
13:42:20  <planetmaker> (what is chilliproject?)
13:43:08  <Ammler> ChiliProject is a Fork of some devs not happy with JPL
13:43:17  <Ammler> the owner of redmine)
13:44:47  <planetmaker> ah, that's why it looks so similar :-)
13:45:23  <Ammler> basically all redmine devs who were on IRC founded ChiliProject
13:45:57  <Ammler> so #redmine is completely empty of knowledge
13:48:03  <planetmaker> he
13:48:14  <planetmaker> this network? or freenode?
13:48:46  <Ammler> freenode :-)
13:49:22  <Ammler> redmine 1.2 is basically chiliproject 2.0
13:49:36  <planetmaker> well, I'd not do the switch before there's an actual 2.0
13:49:45  <Ammler> they do happily transplant changes
13:50:09  <Ammler> planetmaker: I guess, we never run a stable version
13:50:21  <planetmaker> that's what I'd do, transplanting changes. Handy thing ;-)
13:50:35  <Ammler> currently we are at redmine something before 1.2
13:51:48  <planetmaker> on the other hand: if it's mostly transplanting changes... why then switch?
13:54:05  <Ammler> well, as we are a IRC community
13:54:13  <Ammler> I might switch to the "IRC Redmine" :-)
13:54:58  <Ammler> but one of the main devs on redmine did very nice work for mercurial, so this is what stops me
13:57:37  <planetmaker> there seem to be two active devs for redmine?
13:58:01  <Ammler> yep, the rest is on ChiliProject now
13:58:41  <Ammler> JPL doesn't accept other opinions
13:59:15  <Ammler> ChiliProject is more "community based2
14:05:14  <planetmaker> well, not like there were many commits of others since November... Also not prior to the fork
14:05:38  <Ammler> rm or cp?
14:17:26  <Terkhen> hmm... nml does not build for me
14:17:39  <Terkhen> setuptools is a package?
14:19:46  <Terkhen> ok, found it :)
14:23:03  <Ammler> Terkhen: you are the only one building nml, that is why we never found setup issues before the compiler does
14:23:26  <Terkhen> can I use it without doing ./ build?
14:23:28  <Brot6> NewGRF Meta Language - Bug #2692 (New): Not possible to use variables inside basecost blocks (Terkhen) @
14:23:41  <Ammler> most here simply symlink nmlc to ~/bin
14:23:49  <Terkhen> but don't you need to generate nmlc first?
14:23:49  <planetmaker> redmine
14:24:10  <Ammler> hmm, did "he" remove the old wrapper?
14:24:25  <planetmaker> Terkhen: nmlc is a script. It's not really generated
14:24:38  <planetmaker> I hope it's still there
14:24:45  <Ammler> yes, nmlc on the root
14:24:49  <planetmaker> good
14:24:54  <Ammler> the script does generate bin/nmlc
14:24:56  <Ammler> for the setup
14:25:50  <Ammler> planetmaker: it does generate a nmlc depending on your system
14:25:58  <Ammler> that is the new buildout feature
14:26:37  <planetmaker> hm, I see. But good to know I do not have to use it ;-) - it would end my ease of updating NML ;-)
14:27:45  <Ammler> planetmaker: well, I assume, you could also symlink bin/nmlc without the need to rebuild everytime
14:28:06  <Ammler> no sure, thought
14:29:43  <planetmaker> good idea or bad idea: define in OpenGFX+Trains all engines and wagons as a new ID, and disabling the default IDs?
14:30:19  <planetmaker> The advantage over the current situation (some are overridden by the new, changed specs) is that it would totally be possible to add the set to any existing game without breaking anything
14:30:34  <Terkhen> then you should probably update the instructions I used to set up nml :)
14:30:59  <planetmaker> hm?
14:31:09  <Ammler> Terkhen: those might still be valid for common users
14:31:26  <Terkhen> I learned to do ./ build and sudo ./ install somewhere, if there is an alternate way of using nmlc then it should be in the docs too
14:31:51  <Terkhen> specially if it is way simpler and does not require root permissions
14:32:50  *** frosch123 has joined #openttdcoop.devzone
14:32:55  <Ammler> Terkhen: it is common way to run python apps
14:33:09  <Ammler> some use, some run it directly
14:33:41  <Ammler> it is just important to symlink, not copy the nmlc
14:33:49  <Ammler> as python needs to find the modules
14:34:04  <Terkhen> what I say is that both ways of using it should be documented
14:34:24  <Ammler> usually you document the common way :-)
14:34:44  <Ammler> and the other way you find on irc channels :-P
14:35:44  <Ammler> but feel free to extend the docs, I am sure, nml devs don't mind
14:36:28  <Yexo> <planetmaker> good idea or bad idea: define in OpenGFX+Trains all engines and wagons as a new ID, and disabling the default IDs? <- not useful at all
14:36:34  <Yexo> vehicle IDs are remapped anyway
14:36:48  <planetmaker> hu?
14:37:06  <planetmaker> so... it gets a new (internal) ID anyway, yes
14:37:15  <Yexo> if the "multiple newgrf vehicle sets" setting is enabled, it doesn't matter if you pick id 5 or id 200
14:37:21  <Yexo> it'll function exactly the same
14:37:30  <planetmaker> even if id5 is already there?
14:37:35  <planetmaker> on the map, built?
14:37:41  <Yexo> the ids are grf-local
14:38:17  <Yexo> oh, it matters if there is no newgrf vehicle set loaded at all and you add opengfx+trains
14:38:55  <planetmaker> yes, that's what I mean. But then... probably it's not worth the trouble. I'd loose also many translations
14:39:13  <planetmaker> which I now have for free :-)
14:39:31  <Ammler> depends on override
14:39:43  <Terkhen> you can't reference those OpenTTD strings from a NewGRF?
14:40:12  <planetmaker> Terkhen: maybe. But now I don't have to bother about an engine name at all :-)
14:40:15  <Ammler> planetmaker: when would that make sense?
14:40:36  <planetmaker> Ammler: when you started and suddenly notice "oh damn". But then... noobs cannot add the set then anymore anyway
14:40:40  <planetmaker> And others would know
14:41:11  <planetmaker> hm... ach, easy way. Keep the default IDs :-)
14:41:26  <Ammler> it is silly to use ogfx+ and default
14:41:38  <planetmaker> One big thing to worry about less. Yes, it is
14:41:47  <planetmaker> (silly)
14:42:22  <Ammler> you would need to make it optional even more work
14:42:42  <planetmaker> what optional?
14:42:53  <Ammler> I would not like to have default and ogfx+
14:43:14  <planetmaker> well, that's no extra work, and it would not need options.
14:43:36  <planetmaker> simply setting climate availability to 0 for all default won#t hurt existing ones.
14:43:47  <Ammler> then it is even more stupid
14:43:54  <Ammler> (not just silly) :-)
14:44:33  <planetmaker> as said: the advantage would be an existing turbo train would not cause a crash when adding ogfx+trains
14:45:04  <Ammler> why does that crash?
14:45:47  <Ammler> that should indeed not crash :-)
14:46:09  <Ammler> as teh name sais, it should be possible to extend opengfx
14:46:20  <Ammler> not change
14:47:40  <Ammler> sounds more like a bug, isn't ogfx+ turbo train the same?
14:51:08  <planetmaker> it has 7/8 length
14:52:30  <Ammler> I think that is compeltely another point
14:53:01  <Yexo> it is not, that is a reason it will crash
14:53:20  <Ammler> Yexo: yes, I meant another point to think about changing id
14:53:56  <Ammler> I am still a bit confused, why it does override default
14:54:14  <Yexo> any newgrf sets override the default set
14:55:42  <Ammler> Yexo: that could be changed, couldn't?
14:55:46  <Ammler> any reason for that?
14:56:24  <planetmaker> hm... possible change: just copy the stats, and set climate availability to 0 for the default? Or does that break with the fact that default vehicles usually can be modified by several newgrfs consecutively?
14:58:03  <Ammler> planetmaker: you mean multiple newgrfs change the same default vehicle?
14:58:12  <planetmaker> yes
14:58:19  <planetmaker> that's allowed, done and feasible
14:58:27  <Ammler> example?
14:58:38  <planetmaker> old wagons new cargos?
14:58:45  <planetmaker> and opengfx+trains ;-)
14:58:46  <Ammler> yes, one grf overrides default
14:58:56  <Ammler> another one grf overrides default
14:59:02  <planetmaker> last one wins
14:59:10  <planetmaker> for those properties it defines
14:59:16  <Ammler> yep, but that would still work
15:00:39  <Ammler> well adding newgrfs to a running save with existing vehicels is anyway another category than simply update a scenario
15:01:03  <planetmaker> yes.
15:01:35  <Ammler> you could wait until someone reports it as bug :-)
15:01:52  <planetmaker> Well, good that we talked about it. It helped me a lot to decide to not bother about this not supported border case ;-)
15:02:56  <Ammler> rather allow static newgrfs with gui
15:03:38  <Ammler> and allow disabling/chaning parameters static newgrfs if you join a server with static newgrfs loaded
15:05:22  <Ammler> that would also fix the lack of the settings gui if you join a server :-)
15:06:24  *** XeryusTC2 is now known as XeryusTC
17:18:27  <Brot6> ogfx-industries: update from r108 to r110 done -
17:18:45  <Brot6> ogfx-trees: update from r48 to r49 done -
17:18:54  <Brot6> Following repos didn't need a nightlies update: 2cctrainset (r750), 32bpp-extra (r40), ai-admiralai (r75), ai-aroai (r39), ailib-common (r21), ailib-direction (r17), ailib-list (r32), ailib-string (r29), ailib-tile (r16), airportsplus (r92), basecosts (r25), belarusiantowns (r8), bros (r52), chips (r141), comic-houses (r71), firs (r1996), fish (ERROR r649), frenchtowns (r6), german-townnames (r34), grfcodec (r829), grfpack (r279), heqs
17:18:54  <Brot6> (r605), indonesiantowns (r41), manindu (r7), metrotrackset (r56), narvs (r37), newgrf_makefile (ERROR r293), nml (r1360), nutracks (r201), ogfx-landscape (r68), ogfx-rv (r107), ogfx-rv.clone (r103), ogfx-trains (r241), opengfx (r673), openmsx (r97), opensfx (r97), smts (r19), snowlinemod (r49), spanishtowns (r10), sub-landscape (ERROR r66), sub-opengfx (ERROR r666), swedishrails (r202), swisstowns (r22), transrapidtrackset (r15),
17:18:56  <Brot6> ttdviewer (r34), ttrs (r36), worldairlinersset (r672)
17:19:33  <Brot6> newgrf_makefile: compile of r293 still failed (#2656) -
17:20:06  <Brot6> sub-landscape: compile of r66 still failed (#2616) -
17:20:57  <Brot6> sub-opengfx: compile of r666 still failed (#2586) -
18:22:01  *** andythenorth has joined #openttdcoop.devzone
18:23:04  *** andythenorth has left #openttdcoop.devzone
18:24:03  *** andythenorth has joined #openttdcoop.devzone
20:20:23  <Brot6> NewGRF Meta Language - Bug #2692 (Closed): Not possible to use variables inside basecost blocks (Terkhen) @
20:20:24  <Brot6> NewGRF Meta Language - Revision 1361:5cba12f33b49: Fix #2692: Consider global constants/variables... (Hirundo) @
20:20:24  <Brot6> NewGRF Meta Language - Bug #2692 (Closed): Not possible to use variables inside basecost blocks (Hirundo) @
20:20:41  <Terkhen> great, thanks :)
20:23:02  * Hirundo uncovered more nastiness in the process
20:28:17  <Hirundo> When outputting named parameters as nml, param numbers >64 are used directly
20:29:05  <Yexo> yep
20:29:42  <Yexo> nml output is broken in a few more places ;(
20:30:10  <Yexo> main problem there is that it's not entirely clear when the nml output should happen: before or after preprocessing
20:30:32  <planetmaker> hello :-)
20:30:36  <Hirundo> I'd say after
20:30:40  <Yexo> I'd say before :)
20:30:44  <planetmaker> I guess this is a problem which is release-critical, eh?
20:30:58  <Yexo> the action2 problem is, and that's worse
20:31:03  <planetmaker> Because I'd like to nudge you to make an initial release :-)
20:31:08  <planetmaker> but yes
20:31:26  <Yexo> on the other hand maybe we should just release with the action2 thing as known bug
20:31:32  <Yexo> as that might take a while yet to fix
20:31:49  <planetmaker> you mean the one with the airports, or which?
20:31:51  <Yexo> Hirundo: reduce() removes a lot of information
20:31:53  <Yexo> planetmaker: yes
20:32:05  <planetmaker> it's not directly a bug, I think. It's just an additional limitation
20:32:19  <Yexo> part of the information it removes is the names of parameters and variables (the latter in switch-blocks)
20:32:52  <Yexo> planetmaker: the tilelayouts blocks are sometimes reordered, which is definitely a bug when they use parameter values
20:33:19  <planetmaker> ho, hm. That one.
20:35:35  <Hirundo> I'm fine with releasing tbh, if we wait till all issues are ironed out we won't have a release before christmas
20:36:29  <Yexo> either of you want to write a simple readme file?
20:36:32  <Rubidium> Hirundo: pff... there are still so many Christmasses to come, so why can't it be before a Christmas?
20:36:59  <Yexo> I'm first going to fix #2663
20:36:59  <Brot6> Yexo: #2663 is "NewGRF Meta Language - Bug #2663: animation callback names are inconsistent - #openttdcoop Development Zone"
20:37:21  <Hirundo> There are no Christmasses after 2012
20:37:47  * Hirundo ponders Christ-mass as a new unit of mass to replace the kg
20:53:41  *** ODM has quit IRC
21:02:02  *** Lakie has quit IRC
21:13:58  <Brot6> NewGRF Meta Language - Revision 1362:fb81d50ae902: Change #2663: rename some animation callback n... (yexo) @
21:15:08  <Yexo> planetmaker / Terkhen: nml r1362 broke ogfx-industries, testing the other ogfx-* repos right now
21:15:30  <Terkhen> hmm... ok, I'll check that
21:16:07  <Yexo> and ogfx-rv takes a looooooooooooooong time to build
21:16:14  <Yexo> with lots of gimp warnings
21:16:23  <Terkhen> yes
21:16:48  <Terkhen> maybe we should keep generated pngs on the repo and only generate them on some cases
21:17:06  <Yexo> ogfx-landscape is broken too
21:17:18  <Yexo> ogfx-rv, ogfx-trains and ogfx-trees are fine
21:17:32  <Terkhen> thanks, I'll fix ogfx-industries :)
21:22:54  <planetmaker> thanks.
21:23:29  <Brot6> OpenGFX+ Airports - Revision 93:c37effe0fb37: Fix: rename callbacks changed in nml r1362 (yexo) @
21:25:10  *** andythenorth has left #openttdcoop.devzone
21:28:45  <Brot6> OpenGFX+ Landscape - Revision 69:dc88b566c1aa: Fix: rename callbacks changed in nml r1362 (yexo) @
21:30:22  <planetmaker> oh, thanks, yexo
21:36:32  <Brot6> OpenGFX+ Industries - Revision 111:00f71ab9def2: Fix: Compilation failed due to callback name cha... (Terkhen) @
21:45:32  *** frosch123 has quit IRC
21:48:20  <Brot6> NewGRF Meta Language - Bug #2663 (Closed): animation callback names are inconsistent (yexo) @
21:48:20  <Brot6> NewGRF Meta Language - Bug #2663 (Closed): animation callback names are inconsistent (yexo) @
22:02:59  *** KenjiE20 has quit IRC

Powered by YARRSTE version: svn-trunk