Times are UTC Toggle Colours
01:34:48 *** yorick has quit IRC 03:16:07 *** Supercheese has joined #openttdcoop.devzone 03:33:49 *** gelignite has quit IRC 06:30:40 *** ODM has joined #openttdcoop.devzone 07:19:18 *** TheODM has joined #openttdcoop.devzone 07:22:50 *** ODM has quit IRC 07:34:51 *** Supercheese has quit IRC 09:37:40 *** Alberth has joined #openttdcoop.devzone 11:21:48 *** frosch123 has joined #openttdcoop.devzone 11:27:50 *** oskari89 has joined #openttdcoop.devzone 12:15:56 *** oskari89 has quit IRC 12:28:51 <DevZone> Project opengfx-mars build #38-push: SUCCESS in 2 min 21 sec: https://jenkins.openttdcoop.org/job/opengfx-mars/38/ 12:51:31 *** yorick has joined #openttdcoop.devzone 14:41:39 *** Hirundo has quit IRC 14:43:00 *** Hirundo has joined #openttdcoop.devzone 14:43:53 *** Rubidium has quit IRC 14:43:55 *** Rubidium has joined #openttdcoop.devzone 16:20:41 <DevZone> Project opengfx-mars build #39-test: SUCCESS in 2 min 12 sec: https://jenkins.openttdcoop.org/job/opengfx-mars/39/ 16:20:49 <DevZone> Project Townnames - German build #22-test: SUCCESS in 7.8 sec: https://jenkins.openttdcoop.org/job/german-townnames/22/ 16:20:50 <DevZone> Project NML - NewGRF Meta Language build #263-nightlies: SUCCESS in 3 min 3 sec: https://jenkins.openttdcoop.org/job/nml/263/ 16:48:55 <DevZone> Project Dutch Trainset build #88-push: SUCCESS in 1 min 21 sec: https://jenkins.openttdcoop.org/job/dutchtrains/88/ 16:49:06 <DevZone> Project FISH is ships build #169-push: SUCCESS in 1 min 28 sec: https://jenkins.openttdcoop.org/job/fish/169/ 16:50:41 <DevZone> Project Iron Horse build #688-push: SUCCESS in 1 min 46 sec: https://jenkins.openttdcoop.org/job/iron-horse/688/ 16:51:10 <DevZone> Project Dutch Road Furniture build #14-push: SUCCESS in 2 min 4 sec: https://jenkins.openttdcoop.org/job/dutchroadfurniture/14/ 16:51:11 <DevZone> Project Dutch Rail Furniture build #22-push: SUCCESS in 29 sec: https://jenkins.openttdcoop.org/job/dutchrailfurniture/22/ 16:51:41 <DevZone> Project 2ccts build #36-push: SUCCESS in 30 sec: https://jenkins.openttdcoop.org/job/2ccts/36/ 17:05:53 *** oskari89 has joined #openttdcoop.devzone 17:22:02 <DevZone> Project Japanese Buildings build #120-nightlies: SUCCESS in 16 sec: https://jenkins.openttdcoop.org/job/jpbuild/120/ 17:34:06 <DevZone> Project Finnish Rail Infrastructure - Rails build #234-nightlies: SUCCESS in 8 min 19 sec: https://jenkins.openttdcoop.org/job/frissrails/234/ 17:48:11 <DevZone> Project Iron Horse build #689-nightlies: SUCCESS in 1 min 21 sec: https://jenkins.openttdcoop.org/job/iron-horse/689/ 18:51:59 *** gelignite has joined #openttdcoop.devzone 19:49:35 <Alberth> planetmaker: it's a bit more quiet here, any idea about the state of opengfx mars, or how to get such an idea? 19:50:26 <planetmaker> I don't think anything really happend... only way I would know to check is hg log on main or sub projects 19:51:06 <planetmaker> I've a somewhat bad concience. I meant to do more than I actually did so far 19:52:46 <Alberth> well, I got into industries, and they seem somewhat done for a first version to me. There is the snowy stuff to do, but meh 19:53:05 <Alberth> so I wonder what to switch to 19:53:24 <Alberth> perhaps I should find sprites that are not used or so? 19:53:40 <planetmaker> right. snowy version might be something for after first release 19:55:10 <Alberth> there is also the issue of cargo that I don't know how to do, or rather, I'd like your opinion on it 19:55:14 <planetmaker> https://paste.openttdcoop.org/show/3136/ <-- do we have some bad alignment? 19:55:42 <Alberth> the industries have a cargo table, and I ran into another cargo table in the trains iirc 19:56:03 <Alberth> obviously, they should be shared, but if so, where? 19:57:37 <Alberth> in industries I'd be surprised, I used a computer program to find the areas, and checked all buildings for alignment, although not while being build 19:57:41 <planetmaker> I wondered about a place for commonly shared stuff, too. I didn't exactly find a good answer yet 19:58:22 <planetmaker> I wondered whether these snippets should go into the graphics dir / sub-repo. But that's somewhat wrong 19:58:48 <planetmaker> Or whether we should create a new shared code dir in the main repo? Or a new one? Or rename 'graphics' into shared? 19:59:26 <Alberth> I can see a number of options 1. define a place for it, and other take it from there 2. opengfx main repo 3. merge repos into 1 19:59:35 <Alberth> *others 20:00:56 <Alberth> 1 seems to be the simplest answer, but it may make stuff somewhat unfindable 20:02:13 <Alberth> another consideration is perhaps whether these newgrfs should be playable stand-alone, or always together? 20:02:17 <planetmaker> hm... slight preference: while it's somewhat 'wrong' it might be preferrable to put the shared code in a sub-dir in the graphics (sub)repo. 20:02:44 <Alberth> at least we know where to look for shared stuff then :) 20:02:54 <planetmaker> for that reason, yes 20:03:08 * Alberth is +1 for that 20:03:23 <planetmaker> as to the latter question: Personally I prefer to be able to use the NewGRFs in principle stand-alone 20:03:43 <planetmaker> even though they're strongly designed to be used alongside eachother 20:04:03 <planetmaker> (if they were not stand alone, there'd be no point to have different repos and NewGRFs i nthe first place) 20:04:26 <Alberth> k, it was not clear to me 20:05:21 <Alberth> http://www.tt-forums.net/viewtopic.php?f=29&t=70047 did you see this clash between manual industries and opengfx+industries? 20:05:22 <Webster> Title: Transport Tycoon Forums View topic - Manual Industries 2r5 with openGFX industries? (at www.tt-forums.net) 20:05:45 <Alberth> the latter doesn't have a check for manual industries, it seems; I briefly checked the code 20:06:57 <planetmaker> yes, I noticed. Seems indeed like a missing check 20:07:15 <planetmaker> actually opengfx+ industries has a feature (request) to add the manual industries feature to it 20:07:32 <Alberth> how predictable :p 20:08:55 <planetmaker> I think I added that feature request myself ages ago 20:08:59 <planetmaker> :) 20:09:41 <Alberth> I am also somewhat wondering what to do with nml in long term; the least amount of work would be to switch to python 3 20:10:13 <Alberth> adding partial compile, or rewrite to c++ can also be considered, but seem a lot more work 20:10:57 <planetmaker> mercurial is also struggling with the transition to python3 20:11:03 <planetmaker> mercurial devs themselves 20:11:50 <planetmaker> does python3 allow partial compile? 20:12:03 <planetmaker> or was that part of c++ suggestion? 20:12:39 <Alberth> partial compile of nml code I meant, probably through partially compliled nfo or so 20:13:19 *** Supercheese has joined #openttdcoop.devzone 20:13:36 <Alberth> although it may be a bit overkill; grfcodec seems fast enough 20:13:41 <Alberth> afaik 20:15:00 <Alberth> there is no such feature request in opengfx+industries :) 20:15:28 <planetmaker> http://dev.openttdcoop.org/issues/2624 20:16:00 <Alberth> oh, I am blind :) 20:17:08 <planetmaker> with NML future you raise an important question though, IMHO 20:17:24 <planetmaker> Both is not easy, but python2->python3 certainly is easier than a transition to c++ 20:17:47 <planetmaker> the question though is: what's 'better' in the long run? 20:18:02 <planetmaker> and can a transition python->c++ be a smooth one? 20:18:26 <planetmaker> I really dread a dead time with really no progression at all. All time spent only on conversion with nothing really gained 20:18:36 <planetmaker> (it's what killed netscape etc...) 20:20:25 <planetmaker> but it might open the door to a faster compiler. But... honestly, I do not feel competent enough to actually make that decision 20:21:00 <planetmaker> I really do feel incompetent when it comes to compiler development. I lack a lot of knowledge there 20:21:09 <Alberth> if I have to do it, I start from scratch in c++, building nml with the same functionality 20:21:38 <Alberth> the important thing is that we need the existing tool in the mean time 20:22:57 <planetmaker> NML won't vanish. What I can surely do is do the 'support' I did so far. Adding new properties and variables as they are added 20:23:05 <Alberth> obviously, you can use the python code to look how it can be done, but without deep understanding of newgrf, I will fail at a simple 1-to-1 conversion, if it's wrong, I wouldn't know where to look 20:23:10 <planetmaker> Fixing the occasional bug. Like also you and frosch do 20:24:03 <Alberth> thus I need to see and write each class from scratch, so I understand what they do, and how they work together 20:24:25 <planetmaker> Hm, yes 20:24:29 <Alberth> yeah, perhaps an experiment towards python 3 would be a good step 20:24:51 <planetmaker> would that make c++ easier? 20:25:13 <Alberth> not really, but it ensures we'll keep nml alive 20:25:22 <planetmaker> and is speed the only reason for c++? 20:25:39 <planetmaker> or is there something which slipped my mind or which I miss? 20:25:41 <Alberth> given that nml is too slow currently, yep 20:26:42 <Alberth> y3xo did an experiment to handle graphics by c++, but the overhead python -> c++ was too big 20:27:16 <planetmaker> I see 20:27:37 <Alberth> the alternative is of course to make partial compilable files with nml, and link them together 20:27:49 <Alberth> then you normally need to process only a few files 20:28:07 <planetmaker> that will impose quite some limitations on how you can write your code 20:28:29 <Alberth> depends on the back-end, which currently doesn't exist at all 20:28:42 *** oskari89 has quit IRC 20:29:04 <Alberth> hmm, and probably also you need external declarations in nml 20:29:13 <Alberth> that may defeat the entire purpose :p 20:29:18 <planetmaker> you mean to implement a kind of pre-processor step. Or compiling to object code which then only still needs linking? 20:30:14 <Alberth> the latter, but if you want to read only a few files, they need to have enough information to be processed, in particular info from files that are not read 20:30:30 <Alberth> so you need to declare such things 20:30:52 <Alberth> eg "spriteset foo;" meaning that "foo" points to a sprite set 20:30:58 <planetmaker> the problem I then always see is the action2 numbering 20:31:25 <frosch123> you can also go the nml->nfo in python, nfo->grf in c++ route 20:31:27 <planetmaker> you can't have global ones then. or you need additional syntax to delcare something global 20:31:55 <planetmaker> nmlc can already output nfo. That's a solved problem really? 20:31:57 <Alberth> frosch123: yes, if grfcodec is fast enough 20:32:01 <frosch123> iirc the only thing with that was the nml by default chooses the compression, but that is could be moved to the nfo->grf part as well 20:32:18 <planetmaker> ah 20:32:47 <frosch123> grfcodec may have ugly/magic/horrible code, but it is fast and works :) 20:33:11 <frosch123> "works" as in, there has been enough testing and fixing 20:33:18 <planetmaker> yup 20:33:43 <Alberth> that would make python fast enough ? 20:33:46 <frosch123> generally i think staying with python as much as possible is better than trying c++ 20:34:19 <Alberth> it's much less work at least :) 20:36:26 <frosch123> nfo may also be the wrong intermediate format 20:36:35 <planetmaker> so basically going back to what we had before: nml->nfo instead of nml->grf 20:36:45 <planetmaker> or something new 20:36:54 <frosch123> if we want to go towards partial compile, we may want some format with references to ids or so 20:37:20 <planetmaker> the IDs might be replaced in the final compile step, yes 20:37:30 <planetmaker> during linking 20:37:55 <frosch123> basically, resolve all switches during a partial compile, but keep the item names and cargo labels and such 20:38:27 <frosch123> and parameter names and such 20:38:52 <frosch123> yeah, basically resolve only the switches and leave the rest :p 20:39:26 <planetmaker> might do the trick 20:39:27 <Alberth> if grfcodec is fast enough, it may be overkill to do that 20:40:11 <frosch123> he :p i was refering to the case that "nml->nfo" is not fast enough 20:42:37 <Alberth> ah, ok 20:43:25 <frosch123> and if it really is needed we can speed up grfcodec a lot 20:43:39 <planetmaker> hm. Ok. So let's stay with python. Try at a python2->3 conversion. And try to split processing into two separate phases, so that in a 'linking' steps which allows partial compiles 20:43:42 <frosch123> it is currently quite slow with 32bpp because it has only one file opened at a time 20:43:50 <frosch123> so, it closes and reloads the same files all the time 20:44:03 <planetmaker> resolveing the switches might take already quite some time. 20:44:14 <frosch123> so, if you are really interested you could cache more graphics files, and even make the whole thing multithreaded 20:44:43 <Alberth> we should hire andy :p 20:45:38 <planetmaker> :) 20:45:48 <planetmaker> last multithready by him was a fork bomb :P 20:47:19 <planetmaker> but adding threading to especially graphics processing... 20:49:38 <Alberth> I am sure there are lots of things that can be improved :) 20:59:59 *** TheODM has quit IRC 21:40:18 *** Alberth has left #openttdcoop.devzone 21:45:36 *** gelignite has quit IRC 22:43:58 *** frosch123 has quit IRC