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 <http://dev.openttdcoop.org/issues/839#change-2268> 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... <http://dev.openttdcoop.org/projects/firs/repository/revisions/656> 04:02:26 <Webster> Latest update from devactivity: OpenSFX - Revision 78: -Update: base set translations for Polish, Romanian, Slovak, Serbian and T... <http://dev.openttdcoop.org/projects/opensfx/repository/revisions/78> || OpenMSX - Revision 28: -Update: base set translations for Polish, Romanian, Slovak, Serbian and T... <http://dev.openttdcoop.org/projects/openmsx/repository/revisions/28> || OpenGFX - Revision 367: -Update: base set translations for Polish, Romanian, Slovak, Serbian and ... <http://dev.openttdcoop.org/projects/opengfx/repository/revisions/367> || Redmine - Revision 3442: Adds an helper for displaying the 'checked' image. <http://dev.openttdcoop.org/projects/redmine/repository/revisions/3442> || Redmine - Revision 3441: Do not query the database for project level on projects list. <http://dev.openttdcoop.org/projects/redmine/repository/revisions/3441> || Redmine - Revision 3440: Accept issue links inside brackets (#4418). <http://dev.openttdcoop.org/projects/redmine/repository/revisions/3440> 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> http://www.simple-is-better.org/template/pyratemp.html 13:03:31 <Webster> Title: pyratemp (at www.simple-is-better.org) 13:07:14 <Ammler> or http://www.cheetahtemplate.org/ 13:07:15 <Webster> Title: Cheetah - The Python-Powered Template Engine (at www.cheetahtemplate.org) 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> http://www.scons.org/ <-- once suggested here 14:49:58 <Webster> Title: SCons: A software construction tool (at www.scons.org) 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> http://www.simple-is-better.org/template/pyratemp.html#quickstart 15:20:42 <Webster> Title: pyratemp (at www.simple-is-better.org) 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> http://wiki.ttdpatch.net/tiki-index.php?page=DebuggingGRFCode 15:57:49 <andythenorth> Ammler: I mean something more like this (but without pretty formatting) 15:57:50 <andythenorth> http://tt-foundry.com/misc/debug.png 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? http://www.tt-forums.net/viewtopic.php?p=573250#573250 16:08:40 <Webster> Title: Transport Tycoon Forums • View topic - grfdebug.log parsing tool (Updated 2007/04/14 @06:25 GMT) (at www.tt-forums.net) 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: http://devs.openttd.org/~yexo/show_industry_psa.diff 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> http://devs.openttd.org/~yexo/show_industry_psa2.diff 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: http://paste.openttd.org/225294 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 diff...do 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> http://tt-foundry.com/misc/debug_yexo.png 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 <http://dev.openttdcoop.org/projects/worldairlineset/repository/revisions/635> 19:01:41 <Yexo> andythenorth: http://devs.openttd.org/~yexo/cb_in_industry_window.png / http://devs.openttd.org/~yexo/show_industry_psa3.diff 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> http://paste.openttd.org/225295 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, but...one 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 <http://dev.openttdcoop.org/projects/nutracks/repository/revisions/53> || Nutracks - Revision 52: Add: Narrow Guage Tracks, But no GFX yet. Snail is on that <http://dev.openttdcoop.org/projects/nutracks/repository/revisions/52> 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 <http://dev.openttdcoop.org/issues/839#change-2269> || FIRS Industry Replacement Set - Revision 657: Change: improved industry closure code for Power St... <http://dev.openttdcoop.org/projects/firs/repository/revisions/657> 22:13:59 <Webster> Latest update from devactivity: FIRS Industry Replacement Set - Bug #843 (New): Station showing empty string near junk yard <http://dev.openttdcoop.org/issues/843> || OpenGFX - Revision 368: Change [#820]: splitted arctic <http://dev.openttdcoop.org/projects/opengfx/repository/revisions/368> 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 <http://dev.openttdcoop.org/issues/844> 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 <http://dev.openttdcoop.org/projects/opengfx/repository/revisions/369>