Times are UTC Toggle Colours
11:36:04 *** Alberth has joined #openttdcoop.devzone 11:45:58 <planetmaker> btw, Alberth http://dev.openttdcoop.org/issues/3739 might be something we can implement now :) 11:46:05 <planetmaker> in NML 11:47:37 <Alberth> oh, I wondered whether the link wasn't striked out, but it was another bug tracker :p 11:47:55 <planetmaker> :) 11:48:15 <V453000> would make a lot of sense :) 11:48:30 <planetmaker> it seems to work, but I didn't extensively test or check it. And I didn't exactly understand it yet - need to understand the underlaying NFO for that 11:48:49 <planetmaker> hehe, Alberth :) I wondered yesterday the same thing :) 11:52:29 <Alberth> a V would be happy probably :) hyhy btw 11:53:03 <Alberth> I don't understand what it actually does, it seems to switch to an extended action 1 form 11:53:40 <Alberth> tbh I would expect nml to use the old form if you don't have this need 11:54:00 <planetmaker> yes. And - as I understood frosch yesterday - to reference differently-sized sprite sheets in the same layout 11:54:03 <Alberth> also nicer for existing newgrfs 11:54:29 <planetmaker> thus make some things easier to write / with less boiler-plate 11:54:31 <Alberth> but perhaps there are limitations in how you can combine them? 11:54:47 <planetmaker> nml would simply always use extended action1 then 11:54:54 <planetmaker> no reason not to :) 11:55:05 <Alberth> md5 sum existing newgrfs? 11:55:20 <planetmaker> it would change the output of nml, yes 11:55:33 <planetmaker> but what about the md5sum of existing grfs? 11:57:32 <DevZone> Project Dutch Tramset build #41-push: FAILURE in 5 sec: https://jenkins.openttdcoop.org/job/dutchtramset/41/ 11:57:39 <Alberth> they would change, wouldn't they? 11:57:50 <Alberth> or is that not a problem? 11:58:09 *** Jasper has joined #openttdcoop.devzone 11:58:25 *** Jasper is now known as FooBar 11:58:36 <planetmaker> Alberth, it's not a problem. All we need to do is adopt our regression tests 11:58:54 <Alberth> kk 11:59:00 *** FooBar is now known as Guest3706 11:59:03 <planetmaker> and yes, a re-build of an existing grf would give a different result. But that's a common thing when changing NML, so nothing special 11:59:44 <Alberth> hi hi foobar / Guest3706. 11:59:47 <planetmaker> we never guarantee the output to remain constant between versions. We can't, even when we try :) 11:59:54 <Guest3706> hi Alberth 12:00:14 <planetmaker> hi hi :) 12:00:20 <Guest3706> I need to re-figure-out how to log in with my old name 12:00:26 <Guest3706> and what my password is 12:01:15 <planetmaker> :) you might have had an e-mail registered, then you can use that to reset pw 12:01:28 <planetmaker> if not... dunno :) ask in #oftc 12:01:47 <Alberth> probably read the faq first :) 12:02:52 <Alberth> omg, action1 keeps 'old' spritesets now, for each feature :) Nice if you want to figure out what you have defined at one point :p 12:03:36 <Alberth> ok, always using extended format looks like the way to go 12:06:30 *** Guest3706 is now known as FooBar2 12:06:39 <FooBar2> meh, I cannot be bothered 12:06:55 <Alberth> :) 12:07:24 <FooBar2> Anyways, planetmaker (or somebody) I was to ask if you could do this findversion.sh magic on the dutchtramset repo as well 12:07:55 <planetmaker> pull, FooBar2 ;) 12:08:02 <planetmaker> I committed and pushed that last evening :P 12:08:13 <planetmaker> when I saw that misery and no follow-up push :P 12:08:37 <planetmaker> (or was that another repo?) 12:08:58 <FooBar2> yes, thanks for that. I forgot, but it's also impossible to do from Windows 12:09:20 <FooBar2> Now I have updated the dutchtramset makefile as well, so that is going to need the same treatment 12:09:21 <planetmaker> might have been another. 12:09:37 <FooBar2> yes, that was dutchtrains last night 12:09:56 <planetmaker> there you go also for trams 12:10:15 <planetmaker> you don't use the VM approach anymore, eh? :) 12:10:16 <Alberth> who invented this trams-2cc? it's a bit of a boring name 12:10:18 <DevZone> Yippee, build fixed! 12:10:19 <DevZone> Project Dutch Tramset build #42-push: FIXED in 26 sec: https://jenkins.openttdcoop.org/job/dutchtramset/42/ 12:10:35 <FooBar2> planetmaker: thanks! 12:10:55 <planetmaker> you're welcome 12:10:57 <FooBar2> And yes, don't use the VM anymore. 12:11:35 <FooBar2> But I tried it again to chmod the file, but that proved impossible for a virtualbox mapped windows drive 12:12:11 <FooBar2> all file rights on that mapping are 770, chmod (from root) didn't change anything 12:12:45 <FooBar2> Alberth: that would be me. 2cctrams was forbidden according to the rules ("may not start with number") 12:13:15 <Alberth> kk 12:13:28 <Alberth> 2cc is the most distinguishing feature of the set? 12:13:41 <planetmaker> the rules are... pointless, I think. Not sure why redmine claims so, but it would work, as far as I know 12:14:48 <Alberth> planetmaker: not entirely, package management systems, or archiving systems may get hopelessly confused 12:15:05 <Alberth> they often work with name-versionnumber 12:15:14 <FooBar2> Alberth: the project isn't my idea, I'm just coding it :) 12:15:28 <FooBar2> name can be changed later, this is just the identifier 12:16:13 <Alberth> not sure you can that easily, these names get used as identification, not easy to change people's mind :) 12:16:31 *** yorick has joined #openttdcoop.devzone 12:18:45 <planetmaker> afk for a bit 12:18:51 *** FooBar2 is now known as FooBar 12:19:39 <FooBar> there, I fixed it 12:19:50 <FooBar> the nickname, that is 12:21:40 <FooBar> I'm surprised the registration still exists, after all this time 12:27:03 <Alberth> no other foobars on irc, apparently :) 12:27:27 <FooBar> I did get a change password email a while back though, I didn't ask for that 12:27:48 <FooBar> so I ignored it then 12:28:11 <FooBar> was useful though, so now I knew I had an email address registered :) 12:33:58 <Alberth> iirc if you don't use the name for a while, and another person wants it, they give the other person the name. That didn't happen thus :) 12:35:11 <FooBar> or they didn't change the email address, but that seems unlikely :P 12:40:53 <Alberth> :) 12:50:23 <DevZone> Project Dutch Tramset build #43-push: SUCCESS in 25 sec: https://jenkins.openttdcoop.org/job/dutchtramset/43/ 12:50:49 <DevZone> Project Dutch Tramset build #44-releases: SUCCESS in 25 sec: https://jenkins.openttdcoop.org/job/dutchtramset/44/ 12:51:10 <planetmaker> back :) 12:51:37 <planetmaker> FooBar, they never delete a nick at #oftc. Unless it's unused for > 6 months and someone wants to have it 12:52:28 <planetmaker> btw, FooBar, a change I plan to implement somewhen with devzone, but you might prepare for it 12:52:50 <FooBar> what is it? 12:52:51 <planetmaker> the .devzone/build/pull/enable and .devzone/build/releases/enable files 12:53:08 <planetmaker> they hadn't been observed for some time, but I plan to make use of them again 12:53:25 <FooBar> ah, that may actually explain something 12:53:26 <planetmaker> any project which hasn't them wouldn't build. Dunno whether you have them 12:53:43 <FooBar> I believe I have them in place everywhere, but I'll check that to be sure 12:54:07 <planetmaker> no ETA for that yet, but... I think this year ;) 12:54:12 <FooBar> is .devzone/build/nightlies/enable still used? 12:54:42 <FooBar> or is this completely replaced by push 12:54:46 <planetmaker> no file in .devzone/build is currently used. But I don't plan to make use of the nightlies anymore 12:54:59 <planetmaker> only push and releases. And the latest push is promoted once a day to nightly 12:55:44 <planetmaker> I might somewhen think of a "rebuild everything" build job, but not for now 12:55:52 <FooBar> ok, push doesn't create excessive server load? because I don't really need them, but nightlies would be nice 12:55:54 <planetmaker> it would break anyway on old projects 12:56:20 <planetmaker> there's few enough pushes that it really doesn't matter. And it gives feedback when people need it, when they work on it 12:56:23 <planetmaker> instead of once a day 12:56:34 <FooBar> that is true 12:56:44 <FooBar> especially when people like me update the makefile :P 12:56:58 <planetmaker> for instance 12:57:50 <planetmaker> also, you will be able to use the .devzone/build files to control whether you want a particular branch to be build. Every repository tip will now be build, so that might make sense with more branchy setups 12:59:30 <FooBar> I see I don't have the push file everywhere; I'll add those somewhen 13:00:01 <planetmaker> tbh, I'm not sure whether I'll trigger on the exact filename or simply on .devzone/build/*enable ;) 13:00:56 <planetmaker> http://devs.openttd.org/~planetmaker/patches/trigger.diff <-- that's my current approach, not yet live 13:01:25 <FooBar> in that case I'll wait, every project has at least some sort of .devzone/build/*enable 13:02:14 <planetmaker> ok :) Just thought I mention it while you're here. You're not around too often, sadly, I have to say :) 13:02:59 <FooBar> sadly I'm not working on newgrfs very actively the past months/years 13:03:13 <planetmaker> basically I'm unsure whether it makes sense to distinguish push and releases separately for buiding 13:03:14 <FooBar> that comes in waves, now there is a bigger wave so I thought I might come on here 13:03:20 <planetmaker> :) 13:04:00 <FooBar> it may make sense if you only would want releases, but I don't immediately see a use case 13:05:49 <planetmaker> yeah. That's exactly my problem, too :) 13:05:59 <FooBar> so I guess it would be fine if you have either both, or neither 13:06:47 <FooBar> sometimes it's better to have less (configuration) options 13:09:11 <planetmaker> yeah :) 13:12:21 <FooBar> there's this one game that has so many options they had to categorize them as not to overwhelm new players 13:12:37 <planetmaker> yeah, we know it :P 13:27:14 <Alberth> FooBar: if not str.isdigit(...) <-- what does the string contain if this holds? 13:27:55 <FooBar> this value comes from the database, so could hold anything 13:28:20 <FooBar> normally either Null or an integer, but with a faulty database it could be anything 13:29:27 <FooBar> but come to think of it I may have implemented that wrongly 13:30:37 <Alberth> http://paste.openttdcoop.org/show/3532/ in that case, your code is broken :) 13:31:14 <FooBar> I guess so 13:31:20 <FooBar> should be something like 13:31:27 <FooBar> str(v['vehicle_life']).isdigit() 13:31:48 <Alberth> kk 13:32:05 <FooBar> I'm used to PHP functions, that clearly shows here 13:32:25 <FooBar> where you'd go 13:32:35 <FooBar> if (is_numeric($val)) 13:34:13 <planetmaker> https://jenkins.openttdcoop.org/view/All/builds <-- btw, FooBar. That's about DevZone's activity 13:34:43 <Alberth> If it's always a string, that would help, but I guess you cannot rely on that 13:35:42 <FooBar> planetmaker: that's not too much, even days without anything happening. Building on all push wouldn't hurt I think. 13:36:00 <planetmaker> yeah :) 13:37:10 <FooBar> Alberth: I need to figure out how python handles data types from the database 13:37:48 <FooBar> in PHP everything you read from the database is a string, even integer data types, but with PHP's type conversion that doesn't matter 13:38:29 <Alberth> Never used data bases in anything serious, so no idea 13:38:30 <FooBar> it may be that python respects the data types from the database and that an integer field will be an integer in python 13:39:11 <Alberth> a data base still seems a bit overkill-ish to me, did you consider json? 13:39:42 <FooBar> didn't you make eints? surely that uses a database 13:40:01 <Alberth> https://docs.python.org/2.7/library/json.html?highlight=json#module-json 13:40:02 <Webster> Title: 18.2. json — JSON encoder and decoder Python v2.7.8 documentation (at docs.python.org) 13:40:18 <Alberth> I am quite sure it uses a flat xml file at the disk :p 13:40:33 <FooBar> :) 13:41:04 <Alberth> I know that WT3 uses a data base, and is slow on updating 13:41:12 <FooBar> I know json, but didn't consider it. 13:41:32 <FooBar> would need to make a gui to edit the contents 13:41:45 <Alberth> I guessed you need all strings of a project together always, so it seemed just as simple to just sequentially load everything from a file 13:42:23 <Alberth> which is quite hard to beat with almost anything; OSes are good at reading data sequentially :) 13:42:38 <Alberth> json is a standard, I would guess there are tools for it 13:42:43 <FooBar> true, but ask a json file "give me all liveries for this vehicle" 13:43:20 <FooBar> could be done, but needs more programming 13:43:24 <Alberth> you can have a list or dict of vehicles, and within that a list or dict of liveries 13:43:57 <Alberth> ie you can store the data in a non-flat way 13:44:44 <planetmaker> python has nice json handling libraries 13:44:45 <Alberth> just an alternative you can consider 13:45:25 <FooBar> I know, I'm not against it or anything, just against having to redo everything 13:45:28 <FooBar> maybe for next project 13:46:25 <FooBar> but I guess it would make sense to just store it in a python object then, like andy does 13:48:00 <FooBar> I do like databases though 13:50:17 <Alberth> that much was clear :) 13:51:12 <FooBar> :) 13:51:38 <planetmaker> :P 13:52:47 <FooBar> but thanks for finding that str.isdigit bug 13:57:46 <FooBar> cast as string is necessary though. Null database values are a NoneType in python 13:59:01 <FooBar> maybe I'll do if v == None instead 14:00:01 *** LSky` has joined #openttdcoop.devzone 14:03:06 <Alberth> is None :) 14:03:22 <Alberth> there was another bug I found somewhere 14:03:40 <Alberth> ok if I dump my findings in a public paste? 14:03:52 <Alberth> (ie the comments I have) 14:04:09 <FooBar> the code is already public, so go ahead 14:06:19 <Alberth> http://paste.openttdcoop.org/raw/3534/ 14:07:03 <Alberth> v['articulated'] = 'length: return ' + str(veh_lengths[0]) + ';' + "\n" 14:07:04 <Alberth> v['articulated'] = ' cargo_capacity: return ' + str(v['capacity'][0]) + ';' <-- this line overwrites the previous text 14:07:11 <Alberth> that was the other bug :) 14:07:26 <FooBar> thanks! I'll have a look 14:08:39 <Alberth> paste.o.o seems to have a little trouble getting the entire paste. 14:08:39 <Alberth> + >>> v.model_life # nice x.y access :) 14:08:39 <Alberth> + 0 14:08:39 <Alberth> + """ these are the last 3 lines you should have 14:08:47 <Alberth> otherwise get the raw version 14:09:29 <Alberth> quite nice for your first Python program :) 14:11:09 <FooBar> you linked the raw, so I have the three lines ;) 14:11:31 <FooBar> and thanks, I'm not entirely new to programming, just op Python 14:12:20 <FooBar> this list/tuple/dict stuff is still a bit of witchcraft to me. In PHP "we" just have an array and that's it 14:12:54 <FooBar> so that certainly is something to get used to 14:15:34 <Alberth> list/tuple is just a sequence of values, while dict is a hash table of key to value, which is bigger in storage. Also, you cannot iterate over the elements of a dict in a known order, the order may change at any time theoretically 14:16:31 <Alberth> a list can have varying number of elements, and you can change the elements like x[3] = 5 14:16:56 <Alberth> that makes a list unusable as key in a dict, which is why there are also tuples 14:17:11 <Alberth> fixed length, and cannot be changed once created 14:17:50 <Alberth> (the tuple that is, you can still mess up the internal value of the elements if they are mutable :) ) 14:18:03 <FooBar> yeah, I already found that annoying, hence the v = dict(v) :P 14:19:18 <Alberth> that's quite normal to do :) 14:19:28 <FooBar> oh ok :) 14:19:58 <Alberth> hmm, now I wonder whether namedtuples can be modified, let's check that :) 14:21:19 <FooBar> + # Wouldn't len(res_purgui) == len(res) - 2 (rather than == 2) ?? 14:21:50 <Alberth> hmm, it cannot :( sorry, but my last comment about namedtuples is less useful than I thought, you cannot add new fields to a named tuple 14:21:51 <FooBar> res_purgui contains purchase and gui sprite information. There should be always two 14:22:34 <FooBar> len(res_purgui) == len(res) - values['vehicleparts'] 14:22:45 <Alberth> oh, you're correct. 14:22:48 <FooBar> would work, but seems less useful because values['vehicleparts'] is already tested 14:23:24 <FooBar> I thought I'd explain that since you had questions yoursef 14:23:27 <Alberth> I got confused by your 'not' in the condition 14:24:34 <FooBar> the smelly thing about vehicle lengths: 14:25:00 <FooBar> different liveries could technically have different lengths, but that is not supported 14:25:28 <FooBar> therefore I keep the lengths from the first valid livery to use later for all liveries 14:27:03 <Alberth> shouldn't you test 'len(temp_vehicle_lengths) > 0' then? 14:28:19 <Alberth> now you are testing whether you have not found a valid solution previously, rather than having a valid solution now 14:28:50 <FooBar> temp_vehicle_lengths is filled for every livery, so if I test that the condition will be true for the second and further liveries as well 14:29:54 <Alberth> but now, temp_vehicle_lengths could be 0 entries a few time, and you generate code each time 14:30:26 <Alberth> I guess you should check both 14:31:00 <Alberth> is vehicle_lengths == [] a valid solution at the end? 14:31:28 <Alberth> if not, Python uses None in such a case, to denote it's not filled yet 14:32:31 <FooBar> temp_vehicle_lengths could be 0, but then the condition if len(res) == values['vehicleparts'] + 2 and len(res_purgui) == 2: will not be passed 14:33:08 <FooBar> maybe I should test len(res) earlier on 14:33:30 <FooBar> because if that fails, it doesn't make sense to do the other stuff 14:33:37 <Alberth> not if you only define a 'gui' and a 'purchase' thingie? 14:34:05 <FooBar> it shouldn't be allowed to define only a 'gui' and 'purchase' row 14:34:24 <FooBar> there always must be vehicle sprites defined as well 14:35:39 <Alberth> kk, so it fails on 'vehicleparts' not 0 thus 14:36:19 <Alberth> maybe assert len(res) > 2 ? 14:37:03 <FooBar> vehicleparts must always be larger than 0 14:38:33 <Alberth> if that's a fundamental property to the entire application, it would be ok 14:39:15 <planetmaker> it's fundamentally important, yes. length >= 1 14:39:22 <FooBar> yes, each vehicle must have at least length 1 :) 14:39:37 <planetmaker> and <= 8 :P 14:39:55 <FooBar> that I'm not sure 14:40:10 <FooBar> this is amount of articulated parts, not length of individual part 14:40:14 <FooBar> it's a bit confusing 14:41:08 <planetmaker> oh, sorry :) 14:41:23 <Alberth> 8 articulated parts sounds quite long :) 14:41:55 <FooBar> actually vehicle_lengths is a list that contains the lengths of the parts, such that the length of the list is the number of vehicle parts... 14:45:46 <Alberth> name sounds good to me :) 14:46:24 <FooBar> "+ # The 'return' code above for 'length' and 'capacity' looks identical, you may want to abstract that to a function." 14:46:36 <FooBar> I agree, just couldn't be bothered at the time :P 14:50:01 <FooBar> +def setup_prop(props, name, value): 14:50:10 <FooBar> nice and clean idea, I might steal that :) 15:03:35 <Alberth> :) 15:04:38 <Alberth> for name, default in OPTIONAL_PROPS: setup_props(v, name, default) 15:05:08 <Alberth> useful if you have more than about 3-4 :) 16:49:17 <DevZone> Project Dutch Trainset build #213-push: SUCCESS in 1 min 30 sec: https://jenkins.openttdcoop.org/job/dutchtrains/213/ 16:49:19 <DevZone> Project redfish build #29-push: SUCCESS in 1 min 55 sec: https://jenkins.openttdcoop.org/job/redfish/29/ 16:56:07 *** yorick has quit IRC 18:12:31 *** andythenorth has joined #openttdcoop.devzone 18:44:27 *** frosch123 has joined #openttdcoop.devzone 20:07:12 *** yorick has joined #openttdcoop.devzone 20:55:13 *** Alberth has left #openttdcoop.devzone 20:59:17 *** frosch123 has quit IRC 21:02:45 *** oskari89 has joined #openttdcoop.devzone 21:15:53 *** andythenorth has quit IRC 21:27:07 *** LSky` has quit IRC 22:15:58 *** FooBar has quit IRC 22:30:44 *** oskari89 has quit IRC 23:51:58 *** yorick has quit IRC