Times are UTC Toggle Colours
00:12:34 *** KenjiE20 has quit IRC 05:43:34 <planetmaker> http://www.tt-forums.net/viewtopic.php?f=47&t=54895 <-- 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 www.tt-forums.net) 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> http://dev.openttdcoop.org/projects/32bpp 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> http://dev.openttdcoop.org/projects/32bpp-ez-patches/repository <-- 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 ./setup.py build? 14:23:28 <Brot6> NewGRF Meta Language - Bug #2692 (New): Not possible to use variables inside basecost blocks (Terkhen) @ http://dev.openttdcoop.org/issues/2692 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 ./setup.py build and sudo ./setup.py 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 setup.py, 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 - http://bundles.openttdcoop.org/ogfx-industries/nightlies/r110 17:18:45 <Brot6> ogfx-trees: update from r48 to r49 done - http://bundles.openttdcoop.org/ogfx-trees/nightlies/r49 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) - http://bundles.openttdcoop.org/newgrf_makefile/nightlies/ERROR/r293 17:20:06 <Brot6> sub-landscape: compile of r66 still failed (#2616) - http://bundles.openttdcoop.org/sub-landscape/nightlies/ERROR/r66 17:20:57 <Brot6> sub-opengfx: compile of r666 still failed (#2586) - http://bundles.openttdcoop.org/sub-opengfx/nightlies/ERROR/r666 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) @ http://dev.openttdcoop.org/issues/2692 20:20:24 <Brot6> NewGRF Meta Language - Revision 1361:5cba12f33b49: Fix #2692: Consider global constants/variables... (Hirundo) @ http://dev.openttdcoop.org/projects/nml/repository/revisions/5cba12f33b49 20:20:24 <Brot6> NewGRF Meta Language - Bug #2692 (Closed): Not possible to use variables inside basecost blocks (Hirundo) @ http://dev.openttdcoop.org/issues/2692#change-6774 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 http://dev.openttdcoop.org/issues/show/2663 "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) @ http://dev.openttdcoop.org/projects/nml/repository/revisions/fb81d50ae902 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:15:43 <Yexo> s/INDTILE_CB_ANIM_STARTSTOP/INDTILE_CB_ANIM_CONTROL 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) @ http://dev.openttdcoop.org/projects/airportsplus/repository/revisions/c37effe0fb37 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) @ http://dev.openttdcoop.org/projects/ogfx-landscape/repository/revisions/dc88b566c1aa 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) @ http://dev.openttdcoop.org/projects/ogfx-industries/repository/revisions/00f71ab9def2 21:45:32 *** frosch123 has quit IRC 21:48:20 <Brot6> NewGRF Meta Language - Bug #2663 (Closed): animation callback names are inconsistent (yexo) @ http://dev.openttdcoop.org/issues/2663 21:48:20 <Brot6> NewGRF Meta Language - Bug #2663 (Closed): animation callback names are inconsistent (yexo) @ http://dev.openttdcoop.org/issues/2663#change-6775 22:02:59 *** KenjiE20 has quit IRC