Log for #openttdcoop.devzone on 18th March 2010:
Times are UTC Toggle Colours
00:01:53  *** Yexo has quit IRC
00:05:19  *** Yexo has joined #openttdcoop.devzone
00:05:53  <Webster> Latest update from devactivity: OpenGFX - Feature #839: 4737-4742: Fizzy drink factory <>
00:07:28  *** KenjiE20 has quit IRC
00:22:19  <Webster> Latest update from devactivity: FIRS Industry Replacement Set - Revision 656: Change: slightly improved closing code for Power St... <>
04:02:26  <Webster> Latest update from devactivity: OpenSFX - Revision 78: -Update: base set translations for Polish, Romanian, Slovak, Serbian and T... <> || OpenMSX - Revision 28: -Update: base set translations for Polish, Romanian, Slovak, Serbian and T... <> || OpenGFX - Revision 367: -Update: base set translations for Polish, Romanian, Slovak, Serbian and ... <> || Redmine - Revision 3442: Adds an helper for displaying the 'checked' image. <> || Redmine - Revision 3441: Do not query the database for project level on projects list. <> || Redmine - Revision 3440: Accept issue links inside brackets (#4418). <>
07:40:49  *** ODM has joined #openttdcoop.devzone
10:39:13  *** ODM has quit IRC
11:14:12  *** KenjiE20 has joined #openttdcoop.devzone
12:06:21  <andythenorth> templating dilemma: code that should be reused by multiple other templates....
12:06:57  <andythenorth> but nesting too many templates fails on readability (and makes action 2 ID collisions likely)
12:11:15  <Ammler> macros?
12:12:01  <Ammler> hmm, aren't you a python guru?
12:12:14  <Ammler> you could could make a python template enigne :-P
12:13:15  <Ammler> maybe it is even possible to reuse existing engines?
12:19:09  <andythenorth> Ammler: I am far from a Python guru :)
12:19:24  <andythenorth> I am more like a man with a wooden spoon trying to fix a swiss watch
12:21:25  <Ammler> maybe it is time to checkout drupal :-)
13:03:30  <Ammler>
13:03:31  <Webster> Title: pyratemp (at
13:07:14  <Ammler> or
13:07:15  <Webster> Title: Cheetah - The Python-Powered Template Engine (at
14:31:33  <andythenorth> Ammler: think you can persuade pm to support that engine alongside the CPP?? :)
14:32:47  <Ammler> which one?
14:33:24  <andythenorth> cheetah I guess
14:33:28  <Ammler> Cheetah looks quite powerful but big
14:33:34  <andythenorth> not sure which is better
14:33:40  <Ammler> pyratemp is simple
14:34:01  <Ammler> but uses <!-- --> for loops
14:34:40  <andythenorth> hmmm....actually I would be worried about having too many template systems in one project
14:35:07  <andythenorth> already I'm worried that noone else will ever be able to work on FIRS
14:36:09  <Ammler> well, IMO, that would be easier with a template engine, than with the UGLY cpp hacks we use...
14:38:03  <andythenorth> you may well be right
14:38:38  <Ammler> and replacing \bVALUE with VALUE should be possible...
14:41:37  <Ammler> also replacing cpp with python might be an option
14:48:49  <andythenorth> I wouldn't mind making whatever changes are necessary to FIRS
14:49:00  <andythenorth> could be something to test once I have a 0.1 release done
14:49:57  <Ammler> <-- once suggested here
14:49:58  <Webster> Title: SCons: A software construction tool (at
14:53:27  <Rubidium> Ammler: and that makes it any better?
14:54:05  <Ammler> you said it self, cpp isn't a template engine :-P
14:54:11  <Rubidium> having to install some vague python templating engine I've never heard of isn't very promising
14:54:23  <Rubidium> and how do you install it on Windows?
14:54:40  <Ammler> install what on Windows?
14:54:42  <Rubidium> and that scons... yet another dependency?
14:55:17  <Ammler> you have python already because of hg
14:56:02  <Rubidium> but not the templating engine you're talking about
14:56:08  <Ammler> I would include the template engine to the repo
14:56:32  <Ammler> like you did with squirrel
14:57:54  <Ammler> for example openmsx already depends on python and blathjis didn't complain about.
14:58:00  <Rubidium> you need modifications to the template engine? Because that's the only reason why squirrel is in OpenTTD's repository. You might have noticed that I removed the copy of lzo and that we don't ship copies of many other libs
14:58:47  <Ammler> the simple engine is 50kb, so that shouldn't really hurt
14:59:08  <Yexo> Ammler: it does hurt, if you include it then you'll have to keep it up to date too
14:59:22  <Yexo> while if you don't include it the user is responsible for keeping the library up to date
14:59:33  <Ammler> Yexo: so including is easier
14:59:47  <Yexo> not really
15:00:05  <Yexo> if a security bugfix comes out I either have to overwrite the copy in my checkout or wait until you update
15:01:34  <Rubidium> and blathijs would need to remove that 'convenience copy' from the source package before uploading and use the package from the repository (so would all packagers)
15:01:47  <Ammler> why?
15:01:57  <Ammler> if it is GPL
15:03:14  <Ammler> or MIT-like
15:03:55  <Rubidium> Ammler: from Debian's packaging policy
15:03:57  <Rubidium> If the included code is already in the Debian archive in the form of a library, the Debian packaging should ensure that packages reference the libraries already in Debian and the convenience copy is not used.
15:04:10  <Rubidium> If the included code is not already in Debian, it should be packaged separately as a prerequisite if possible.
15:05:03  <Ammler> and squirrel isn't already around somehow?
15:05:54  <Ammler> Rubidium: I guess you "overcomplicate" that template things...
15:06:10  <Rubidium> squirrel is the exception that proves the rule; our squirrel is heavily modified and tied into OpenTTD. No amount of upstream changes would change that, except breaking everything else that depends on Squirrel
15:07:09  <Ammler> well, if no such engine, what you suggest then to use?
15:07:51  <Ammler> even more cpp hacks so nobody else will ever understand the code anymore?
15:08:53  <Ammler> and cpp is also a requirement, btw.
15:09:08  <Rubidium> well, that's a bit the problem; you need to find some middle ground where people interested in compiling it can fairly easily do so and developers can work with the cod
15:09:12  <Rubidium> +e
15:09:33  <Ammler> isn't that middle way some kind of template engine?
15:11:21  <Rubidium> now call me crazy, but I think that a template engine written specifically for NFO would be better, instead of for "this" NFO
15:12:49  <Ammler> Rubidium: I fully agree, but someone "would" need to do that.
15:13:03  <Rubidium> i.e. something that can most of the hard work and even figure out what the minimum OpenTTD/TTDPatch version should be
15:13:23  <Rubidium> hell, even tell whether it's TTDP compatible or have TTDP compatability features
15:13:29  <Ammler> something like Eddi once started :-)
15:16:14  <Rubidium> and probably you'll outgrow the templating engine you think about using some time too
15:16:34  <Rubidium> because you can't make complex templates for action2 or so
15:18:05  <Ammler> I think, for a start it should be possible to replace \bVALUE with \b99
15:19:40  <Rubidium> I wonder whether such a template engine can do that
15:19:53  <Rubidium> s/such a/that python/
15:20:19  <Rubidium> how would you use the \bVALUE anyway?
15:20:40  <Ammler>
15:20:42  <Webster> Title: pyratemp (at
15:22:41  <Ammler> [16:20] <Rubidium> how would you use the \bVALUE anyway? <-- if VALUE < x then do a else do b
15:24:39  <Rubidium> hmm, looking at pyratemp...
15:25:27  <Rubidium> you're basically going to write a python program to emit your source code. Some parts of that will go through a fancy regexp to replace some stuff, the rest is pure python code.
15:26:19  <Ammler> yes, what did you expect?
15:26:39  <Rubidium> something more declarative instead of imperative
15:26:51  <Ammler> that might Cheetha
15:26:58  <Rubidium> I doubt it
15:27:38  <Ammler> but to make a nfo template engine, that simple thing should be easier start...
15:30:51  <Ammler> also a difference is, that engine is only needed for building...
15:31:17  <Ammler> so nothing to do with your debian splitting quote above...
15:31:23  <andythenorth> hmm
15:31:40  <andythenorth> every time this is discussed 'complaex varaction 2' comes up.
15:31:49  <andythenorth> that's a straw man arugment
15:31:59  <andythenorth> there's no need to template away varaction 2.
15:32:06  <Ammler> andythenorth: yes, if you make such a engine, you should start there :-)
15:32:26  <andythenorth> start *with* templating varaction 2, or by ignoring varaction 2?
15:32:45  <Rubidium> andythenorth: true, but "printf-ing" varaction 2 in a piece of python code doesn't look nice nor really maintainable
15:33:08  <Ammler> well, all the make nfo coding easier scripts started with Action0, which is quite simple...
15:33:30  <andythenorth> so we either need a full python-> newgrf compiler, or just the dumb templating we currently have
15:33:44  <andythenorth> hmm
15:33:55  <andythenorth> how did we get onto this again?  Did I start it?
15:34:10  <Ammler> that is as old as nfo coding :-P
15:34:19  <Rubidium> no, you need something that reads your meta-nfo that can define some templates and "compiles" everything to NFO; a generic tool for all NFO
15:35:31  <Ammler> basically cpp with loops and and able to replace MARKER without spaces.
15:35:32  <Rubidium> so basically a more powerful "cpp"
15:36:22  <andythenorth> the only problem I have with CPP is when I want to define a variable, but sometimes it needs to be byte, sometimes word, sometimes dword.  far as we know, that can't be done cleanly
15:36:33  <andythenorth> otherwise CPP works well
15:37:36  * andythenorth goes to write some more nfo :)  
15:37:53  <Ammler> Rubidium: and scons I just mentioned in case we use something pythonish, so we could remove teh dependency for cpp
15:38:42  * andythenorth thinks of some useful things that could be done with python templating
15:38:52  <andythenorth> can cpp do simple maths
15:38:54  <andythenorth> ?
15:38:56  <Ammler> no
15:39:07  <Ammler> it can't more as we use already
15:39:43  <Ammler> we are already quite a lot over what cpp is for...
15:40:35  <Ammler> cpp is mainly to prepare the source for different plattforms...
15:41:18  <andythenorth> I am thinking of things like, say vehicle sprites, where there might be 400 lines of "foo/bar.pcx 10 0 3 9 etc"
15:41:35  <andythenorth> and they all have consistent y spacing
15:41:54  <andythenorth> a python template engine could generate that automatically
15:42:24  <andythenorth> but generated code normally fails on readability :)
15:42:35  <Ammler> or makes it even more readable
15:43:03  <andythenorth> the readability of those kind of sprites is mostly unimportant anyway
15:43:29  <andythenorth> I always end up using mass find and replace on them (which sometimes introduces errors)
15:44:06  <Ammler> if a == x, do b else c is IMO more readable than 0 * 0 07 00 01 = 02 00 00
15:44:30  <andythenorth> Ammler: it is, but that's quite a lot of abstraction.
15:44:36  <andythenorth> possibly more than is ever going to happen
15:45:32  <andythenorth> I am in two minds on this.  Stupid nfo mistakes by me make my coding *really* slow
15:45:41  <andythenorth> I can *never* do complex stuff like bit shifts without help
15:46:03  <andythenorth> but the rest of the time nfo is very efficient, especially now we use the cpp stuff
15:46:50  <Ammler> and you make a lot less misstakes or you error the whole
15:47:00  <andythenorth> all the documentation is orientated towards current nfo
15:47:09  <Ammler> for example you missalign all houses or none
15:47:34  <andythenorth> right now there's no need to keep an abstracted language in step with two different game engines
15:47:49  <andythenorth> there's no higher level language that might have bugs in it
15:48:03  <andythenorth> so I'm in two minds.
15:48:21  <Ammler> why does it matter, if there are 2 game engines?
15:49:01  <andythenorth> you're right, it doesn't actually.  It's just more communication overhead - more people have to talk if we want a change to newgrf spec.  The TTDP guys, OTTD guys, the template language guys...
15:49:25  <andythenorth> If there was a better way, I'd take it...It's taken me a whole day to write industry code that would be twenty minutes in python on a bad day
15:49:29  <Ammler> the template language guys don't have to talk
15:49:36  <Ammler> they just have to follow the spec
15:49:55  <andythenorth> true
15:50:07  <Ammler> like nforenum
15:51:32  <Ammler> shouldn't it be possible to modify grfcodec/nforenum to make a higher nfo language?
15:52:07  <Ammler> or grf2html
15:52:50  <andythenorth> I have a completely alternative suggestion for improving newgrf coding
15:53:04  <andythenorth> some kind of sane debugger
15:53:35  <andythenorth> It's *really* insane currently
15:54:11  <andythenorth> Every time I write industry code the first thing I have to do is write gui output the show me value of registers, persistent storage, cb results etc
15:54:19  <andythenorth> it's nuts
15:54:36  <Ammler> I guess, ttdpatch has that
15:54:40  <andythenorth> really?
15:54:46  <Ammler> yes, really
15:55:07  <andythenorth> Rubidium: is some kind of newgrf debug even within the realms of possibility?
15:55:16  <Ammler>
15:57:49  <andythenorth> Ammler: I mean something more like this (but without pretty formatting)
15:57:50  <andythenorth>
15:58:04  <andythenorth> it would just print values of:
15:58:08  <andythenorth> registers
15:58:10  <andythenorth> persistent storage
15:58:15  <andythenorth> action 0 properties
15:58:26  <andythenorth> including which cbs are enabled etc
15:58:32  <andythenorth> that would be a *major* improvement
15:58:56  <andythenorth> same could be done for vehicles
15:59:14  <Yexo> andythenorth: I think that wouldn't be hard to write, but just a lot of work to cover all places where it's useful
15:59:43  <andythenorth> It would be incredibly valuable.  That version took me a day to figure out in nfo, and it's a lot of work to modify because the text stack is fiddly
15:59:59  <Ammler> andythenorth: and it would fine to print those things to console?
15:59:59  <andythenorth> I don't need full logging etc
16:00:00  <Yexo> when I have to debug a grf I use a debug build of openttd, set breakpoints at the places where the callbacks are run and then step through the code
16:00:22  <Hirundo> andythenorth: Have you tried using the debug messages, or do they fail to provide the info you need?
16:00:50  <andythenorth> Hirundo: what do I do to turn them on?
16:00:57  <Ammler> -d grf=9
16:01:00  <Yexo> debug_level grf=9 in the console
16:01:08  <Yexo> or start with the flag Ammler gave
16:01:24  <Hirundo> 'developer 2' makes output appear in the console
16:02:28  <andythenorth> what output should I expect to see?  I get nothing for either of those two console commands
16:02:45  <Yexo> no output directly after the command
16:02:52  <Yexo> but you'll get more output when the grf is used
16:02:54  <Ammler> Hirundo: the thing you once talked about (templating), was that something you working on or just hypotetical?
16:03:01  <Yexo> although there isn't much output from callbacks, if any at all
16:03:28  <andythenorth> Yexo: does it output just errors?
16:03:37  <Yexo> no, also a lot of other information
16:03:42  <Hirundo> Ammler: It's currently a lot of vapor :)
16:03:46  <andythenorth> hmm
16:03:48  <Yexo> it'll print all action 0C comments for example
16:03:52  <andythenorth> I'm doing something wrong then
16:04:03  <Yexo> andythenorth: try reloading the savegame
16:05:02  <andythenorth> Yexo: now I get something
16:05:15  <andythenorth> how do I scroll the console?
16:05:25  <andythenorth> found it
16:05:27  <Yexo> shift+arrow keys
16:05:44  <andythenorth> how do I scroll the console faster :P
16:05:46  <andythenorth> nvm
16:06:12  <Ammler> andythenorth: I wouldn't use the ingame console...
16:06:27  <andythenorth> Ammler: what would you recommend?
16:06:29  <Ammler> start openttd from console and you have the output there
16:07:20  <Ammler> (as you don't use windows)
16:07:59  <andythenorth> How do I start ottd from the console?
16:08:07  <Ammler> ./openttd -d grf=9
16:08:24  <andythenorth> how do I escape spaces in the console
16:08:30  <Ammler> \
16:08:38  <Yexo> andythenorth: is this the type of output you need?
16:08:40  <Webster> Title: Transport Tycoon Forums • View topic - grfdebug.log parsing tool (Updated 2007/04/14 @06:25 GMT) (at
16:08:44  <Ammler> or just use <tab>
16:09:00  <andythenorth> Ammler: don't think I can figure it out
16:09:57  <Ammler> andythenorth: ask pm when he is around...
16:10:00  <andythenorth> Yexo: no.  that kind of debug is no help :)  It's too noisy....and way too hard to figure out which industry / vehicle etc the output applies to
16:10:09  <andythenorth> I need something visual
16:10:20  <andythenorth> Any of you use firebug to edit html?
16:10:29  <andythenorth> or more often, css
16:10:33  <Yexo> yes, have done in the past at least
16:10:43  <andythenorth> something like that, only obviously less capable
16:10:53  <andythenorth> I don't need to edit, just view
16:11:15  <Yexo> is a limit to the last callback run ok?
16:11:23  <Ammler> well, edit might then be a small step ;-)
16:11:29  <andythenorth> Yexo: yes
16:11:32  <andythenorth> probably
16:11:34  <andythenorth> anything helps
16:12:55  <andythenorth> it's more like 'inspect' than 'debug'
16:18:54  <andythenorth> a 'reload grfs' button or console command would also be mighty useful.
16:19:07  <Ammler> simply reapply?
16:19:11  <Rubidium> just press apply?
16:19:13  <Yexo> I think clicking apply in the newgrf window does that
16:19:17  <Ammler> :-)
16:19:22  <Ammler> confirmed
16:19:43  <Ammler> don't expect update of text Action8 but else it should work fine.
16:20:41  <andythenorth> apply is fine.  frosch gave me a little patch that pins the newgrf window as well (useful).  but with those big industry debug windows open I run out of screen (I often have to have the map or news window open as well)
16:25:23  * andythenorth yay, after 15 mins, confirmation I *am* setting the register correctly
16:26:25  <andythenorth> approx 3 mins waiting for make, 5mins finding my own silly mistakes, 6 mins running the game for enough months, 1 min writing code :o
16:27:57  *** Doorslammer has joined #openttdcoop.devzone
16:28:16  <Rubidium> make takes 3 minutes?
16:29:26  <Rubidium> takes like 30 times less here
16:31:05  <Doorslammer> 18 seconds?
16:31:21  <Rubidium> !calc 3*60/30
16:31:24  <Rubidium> @calc 3*60/30
16:31:24  <Webster> Rubidium: 6
16:31:43  <Doorslammer> Oh
16:32:23  <Doorslammer> See, if I designed the Titanic, it would have survived with its triple strength hull
16:32:38  <Doorslammer> Not that I would have done it on purpose mind youy
16:33:22  <andythenorth> Rubidium: FIRS make is 22s here, run it 8 or 9 times....adds up :)
16:37:51  <Rubidium> amazing that a compile run to determine nothing has changed takes 2 times as long firs than for OpenTTD
16:42:11  <Rubidium> ah... interesting... on a hg repository FIRS and OpenTTD take equally long
16:42:25  <Rubidium> so HG causes at least 25% of the slowness
16:42:30  <Rubidium> and that is with hot caches
16:42:58  <Ammler> or the dependency check does crawl .hg but doesn't .svn?
16:43:29  <Ammler> is that needed anyway?
16:44:05  <Ammler> or why else can that be longer?
16:45:22  <Rubidium> andythenorth: I've just looked at OpenTTD's findversion for the comparison
16:45:30  <Rubidium> 0.1 vs 1.6 seconds
16:46:14  <andythenorth> any speed up would be appreciated :)  it has been the source of whining this week.  make used to take 11s for FIRS
16:46:24  <andythenorth> you'd think 11s doesn't matter, right?
16:46:46  <andythenorth> fricking irritating :)
16:48:50  <Ammler> IMO, it doesn't make sense to run the dependency check before building, if it needs longer than building the whole thing
16:49:07  <Ammler> it could be renamed to something like validate or so
16:49:15  <Ammler> which you could run before push
16:49:40  <Rubidium> Ammler: that gets forgotten very easily
16:49:53  <Ammler> yes, I know :-)
16:49:59  <Ammler> like adding a file
16:50:27  <Rubidium> but you only need to rerun the dependency check if any of the files from the previous dependency check or the makefile have changed, i.e. their modification date is later than the .dep file's modification date
16:50:55  <Rubidium> though, that would still mean that the dependency thing is ran most of the time
16:52:19  <Ammler> hmm, you don't need to validate before push
16:52:27  <Ammler> just if you get an error on building...
16:54:12  <Ammler> or the "push check" should also clone the repo fresh, that might be an idea.
16:56:34  * andythenorth writes some more nfo to display values in the industry window :|  
17:11:38  *** frosch123 has joined #openttdcoop.devzone
17:15:31  <Yexo> andythenorth: no idea how useful this is, but this displays the first N values from the persistant storage in the industry window:
17:17:26  <andythenorth> Yexo: compiling now...
17:24:55  <andythenorth> Yexo: *so* useful.  can it print the number for each storage register?
17:25:09  <DJNekkid> jesus christ im tierd!
17:25:18  <Yexo> andythenorth: yes, the change the num_psa_to_show constant to 32
17:25:25  <Yexo> but then the industry window might become a bit too big
17:27:30  <andythenorth> Yexo: sorry, I meant a label showing the register number, to cut out the counting :)
17:27:39  <Yexo> ah :)
17:28:38  *** Seberoth has joined #openttdcoop.devzone
17:28:47  <Yexo> will show all 32 values in 4 columns
17:28:56  <Yexo> row 1 contains values 0-3, row 2 values 4-7 etc.
17:29:09  <Yexo> each row is prefixed by "first number:  "
17:34:30  <andythenorth> Yexo:
17:34:55  <Yexo> andythenorth: add "0, " before that j*4
17:35:32  <andythenorth> before all of them?
17:35:45  <andythenorth> oh no I see
17:35:46  <Yexo> only before the first one
17:36:13  <andythenorth> so I modify the local I have to remove and reapply the patch?
17:36:21  <andythenorth> or do I just compile?
17:37:58  <Yexo> you just modify the source file (src/industry_gui.cpp) and then recompile
17:38:19  <Yexo> I've updated the patch, so you could also remove it, then download the new version and apply that
17:38:44  <andythenorth> I'll do that
17:44:19  <andythenorth> Yexo: that's awesome
17:49:58  *** openttnoob has joined #openttdcoop.devzone
17:52:25  <openttnoob> To install ottd do I need to make a new folder and toss opengfx/opensfx in it then install ottd in the same folder
17:53:14  <Yexo> openttnoob: #openttd is the general openttd channel
17:53:22  <openttnoob> alright
17:53:30  <Ammler> thanks Yexo :-)
17:53:32  *** ODM has joined #openttdcoop.devzone
17:54:13  <Ammler> openttnoob: also "noob" in the nick isn't very helpful ;-)
17:55:06  <DJNekkid> openttnoob: your best choice is to use the win32/64 installer, there you can select to add OpenGFX/SFX/Music :)
17:56:31  <Ammler> DJNekkid: psst, he can read that from the readme :-P
17:57:15  <Rubidium> Ammler: which readme? :)
17:57:20  *** openttnoob has quit IRC
17:57:32  <Ammler> Rubidium: maybe twice
17:57:47  <Ammler> once in openttd and once in opengfx
17:58:24  <Ammler> the other 2 readmes I don't know well
18:17:08  <andythenorth> Yexo: I tried a little bit of formatting (white for values, and some additional space between columns)
18:17:08  <andythenorth>
18:18:08  <Yexo> the formatting will break anyway when the number are larger
18:18:36  <andythenorth> yep, I have some with word-sized values, I saw that
18:18:54  <andythenorth> so there's no point trying to line them up.
18:19:14  <andythenorth> It just needed a little bit more space between values so they can be distinguished easily
18:19:29  <Yexo> lining them up would be a lot more work
18:19:34  <andythenorth> no need
18:20:07  <Ammler> oh, andythenorth, might it be possible to make a grf just with that closing part for default industries?
18:20:19  <andythenorth> Ammler: brb to that!
18:20:53  <andythenorth> Yexo I don't want to jump ahead too far, but it would be massively useful to have this as an advanced setting in trunk
18:21:12  <andythenorth> also if it showed the action 0 values
18:21:24  <Yexo> which action 0 values do you need?
18:21:33  <andythenorth> Yexo: pretty much all of them would be useful :)
18:21:48  <andythenorth> I would be happy to help work on this, it's a better use of time than trying to do it in nfo
18:21:52  <Yexo> but you set those values in your newgrf
18:22:53  <Yexo> I understand the need for the psersistant storage values, but the action 0 values are set by the newgrf and can't change
18:22:53  <andythenorth> I mean the value of the action 0 properties at each industry
18:23:07  <andythenorth> Oh I see your point :)
18:23:28  <andythenorth> Let me think why I need that...
18:24:16  <andythenorth> You're quite right, it would be stupid to show those.
18:24:54  <andythenorth> It would be very useful to expand the action 0 props that are bit maps, so the special flags and cb flags: show enabled/disabled
18:24:58  <andythenorth> They are a really common source of error for newgrf coding
18:25:51  <andythenorth> industry prop 1A, 21 and 22 for example
18:37:18  *** frosch123 has quit IRC
18:50:57  <Webster> Latest update from devactivity: World Airliners Set - Revision 635: Major Formatting to new Coding Table <>
19:01:41  <Yexo> andythenorth: /
19:08:35  <andythenorth> Yexo: compiling now :)
19:09:57  <andythenorth> Yexo: /Users/andy/Documents/workspace/OTTD/trunk/src/industry_gui.cpp: In member function ‘int IndustryViewWindow::DrawInfo(uint, uint, uint)’:
19:10:06  <andythenorth> hmm
19:10:16  <andythenorth>
19:10:47  <Yexo> int j -> uint j to fix it, but that warning is harmless
19:12:06  <Ammler> andythenorth: also try after make to run ./bin/openttd
19:12:13  <Ammler> then you know, if it works "unbundled"
19:12:28  <Yexo> or just do "make run" instead of make
19:13:00  <andythenorth> Yexo: the cb stuff is frankly even more awesome
19:13:23  <andythenorth> This should be in trunk as an advanced option or a enabled by console :)
19:14:27  <Yexo> not in this form, this is just a quick hack that works
19:14:38  <andythenorth> understood :)
19:14:48  <andythenorth> but probably worth posting in the development thread
19:15:12  <andythenorth> this would be so useful to nfo coders...especially if extended to vehicles
19:16:16  <Yexo> extending it to vehicles is a bit more work
19:16:27  <andythenorth> obviously, step at a time?  :)
19:16:36  <Yexo> once newgrf airports gets in trunk I want to write a better callback debugging tool anywy
19:17:21  <Ammler> or a nice howto, how to wrok with gdb
19:17:47  <andythenorth> fwiw I'm very into simple visual tools....proper debuggers, break points etc. just don't fit my coding mindset :o
19:18:44  <andythenorth> I always prefer debugging in game.  It's a habit from flash coding days where the debugger sucks (or used to).
19:18:56  <andythenorth> I don't want yet another tool open, I have enough
19:19:15  <andythenorth> I know this is wrong, but hey, I seem to get results :)
19:19:50  <Yexo> andythenorth: with that tool I ment a window in openttd
19:20:00  <Yexo> but one that also shows all information about the last callback
19:20:25  <andythenorth> for a specific industry / vehicle? or globally for the whole game?
19:20:41  <Yexo> per industry / vehicle / airport
19:20:45  <andythenorth> yup
19:20:48  <andythenorth> that would make sense
19:23:27  <andythenorth> I think this sort of thing is a much better use of time than chasing the rainbow of a high level newgrf language :)
19:24:41  <Ammler> it shouldn't block each other
19:25:18  <andythenorth> Ammler: of course, but there's only a certain amount of time :)
19:25:18  <Ammler> also not really related task imo
19:25:35  <andythenorth> hmmm
19:26:07  <Ammler> well, I could have 1000 of free houses, wouldn't help to get a debugger :-)
19:26:07  * andythenorth would really like to finish this power station code, it's been 3 days :o
19:26:15  <Ammler> hours*
19:27:27  <Ammler> openttd code is even more cryptic than the Makefile specially about newgrfs
19:29:35  <andythenorth> Ammler: nonsense :)
19:29:42  <andythenorth> you could help format strings etc
19:30:18  <andythenorth> you could test
19:33:34  <Ammler> well, subjective of course :-)
19:35:01  *** Doorslammer has quit IRC
19:36:44  <andythenorth> I don't find openttd code too bad to read.  It's the only C++ I've ever seen so I don't know what's good and bad though
19:38:34  <Ammler> Rubidium: you could close #3375, it isn't WIP anymore
19:39:21  <Ammler> btw. also Fedora does patch the desktop file, so that isn't a suse only issue.
19:40:00  <Ammler> andythenorth: I didn't say it is bad c++
20:20:02  *** Seberoth has quit IRC
20:20:17  *** Seberoth has joined #openttdcoop.devzone
20:39:49  <Webster> Latest update from devactivity: Nutracks - Revision 53: Add: Strings to the NG-tracks <> || Nutracks - Revision 52: Add: Narrow Guage Tracks, But no GFX yet. Snail is on that <>
20:44:26  <DJNekkid> i didnt crash now did i?
20:56:47  <Ammler> crashed what?
20:56:52  <Ammler> :-)
21:11:48  <DJNekkid> my connecdtion
21:11:58  <DJNekkid> this pc is connected via calb
21:12:00  <DJNekkid> e
21:12:03  <DJNekkid> cable even
21:12:37  <DJNekkid> but the connections on the wireless computers seem to be a tad ba
21:26:32  *** frosch123 has joined #openttdcoop.devzone
21:46:50  *** ODM has quit IRC
21:47:12  *** ODM has joined #openttdcoop.devzone
21:58:02  <Webster> Latest update from devactivity: OpenGFX - Feature #839: 4737-4742: Fizzy drink factory <> || FIRS Industry Replacement Set - Revision 657: Change: improved industry closure code for Power St... <>
22:13:59  <Webster> Latest update from devactivity: FIRS Industry Replacement Set - Bug #843 (New): Station showing empty string near junk yard <> || OpenGFX - Revision 368: Change [#820]: splitted arctic <>
22:22:23  *** frosch123 has quit IRC
22:25:54  <andythenorth> Ammler: you had a question about closure code for default industries?
22:29:09  *** ODM has quit IRC
22:29:10  <Webster> Latest update from devactivity: FIRS Industry Replacement Set - Feature #844 (New): Refinements to industry closure code <>
22:46:31  <Ammler> andythenorth: it might be an idea to make a dedicated version of that closure nfo for the default industries only
22:46:41  <Ammler> specially for power plant.
23:02:15  <Webster> Latest update from devactivity: OpenGFX - Revision 369: Change [#820]: splitted tropical <>

Powered by YARRSTE version: svn-trunk