Times are UTC Toggle Colours
00:50:40 *** Webster has joined #openttdcoop.devzone 00:50:48 *** Lakie has quit IRC 00:50:49 *** KenjiE20 has quit IRC 07:23:29 *** andythenorth_ has joined #openttdcoop.devzone 07:33:52 *** andythenorth_ has quit IRC 08:00:38 *** ODM has joined #openttdcoop.devzone 08:02:01 *** andythenorth_ has joined #openttdcoop.devzone 08:10:03 *** andythenorth_ has quit IRC 08:40:18 *** Guest1374 has quit IRC 08:40:18 *** planetmaker has quit IRC 08:40:18 *** Hirundo has quit IRC 08:40:18 *** Terkhen has quit IRC 08:40:18 *** tneo has quit IRC 08:40:18 *** Ammler has quit IRC 08:46:06 *** Hirundo has joined #openttdcoop.devzone 08:46:08 *** Ammler has joined #openttdcoop.devzone 08:47:08 *** Terkhen has joined #openttdcoop.devzone 08:48:06 *** planetmaker has joined #openttdcoop.devzone 08:48:27 *** planetmaker is now known as Guest1600 08:49:06 *** V453000 has joined #openttdcoop.devzone 08:51:09 *** tneo has joined #openttdcoop.devzone 08:55:42 *** V453000 is now known as Guest1602 09:01:08 <Brot6> Unable to connect to http://dev.openttdcoop.org/sys/: execution expired 09:44:32 *** Guest1600 is now known as planetmaker 10:43:23 <Brot6> #openttdcoop - New Server (Ammler) @ http://dev.openttdcoop.org/news/50 10:57:00 <dihedral> congrats :-) 10:57:11 <dihedral> Ammler, planetmaker: you guys want a mirror to share the bandwidth? 11:05:26 <Rubidium> I think they don't need something for the bandwidth just yet 11:05:53 <Rubidium> they've got 2.5 times more than OpenTTD has (ignoring OpenTTD's mirrors) 11:07:11 <Terkhen> congratulations :) 11:09:32 <dihedral> Rubidium, why do you not move to hetzner with openttd? 11:09:44 <dihedral> is it because TrueBrain is near the DC? 11:10:52 <Rubidium> it's because migration takes a lot of time, which neither TrueBrain nor I had around the time the previous contract period ended 11:12:26 <dihedral> i have a bunch of spare time the first 6 months of next year 11:13:03 <planetmaker> thank you Ammler :-) 11:15:51 <Rubidium> dihedral: the contract ends at the end of the summer vacation, so it requires time in that period 11:15:52 <dihedral> in case i may be of help 11:16:46 <dihedral> it requires to be up and running before the contract ends 11:17:07 <Rubidium> yes, but 9 months double fees is somewhat excessive 11:17:12 <planetmaker> quite 11:18:07 <dihedral> but 2 to 3 months should be feasable 11:18:17 <Rubidium> yes, definitely 11:18:24 <Rubidium> but that's fater your 6 months :) 11:18:49 <Rubidium> I also intend to go with Debian Squeeze 11:19:07 <dihedral> really? 11:19:15 <Rubidium> and we need to think of a new/better way to run the compile farm 11:19:23 <Rubidium> dihedral: why not? 11:20:10 <dihedral> personally it would not be my first choice :P 11:20:19 <planetmaker> Well. I'd do it two-stage: a) port the thing and then b) in a testing environment test / write a new CF 11:20:38 <planetmaker> which thus could be considered somewhat independent tasks 11:21:08 <Rubidium> planetmaker: that's the tricky part, we have the idea to go from virtualbox to xen-domains or something 11:21:08 <dihedral> i would first try to find an existing cf system 11:21:27 <planetmaker> one for each? 11:21:56 <Rubidium> planetmaker: basically yes 11:22:20 <planetmaker> hm... yes. I see that it needs the server there first :-) 11:22:47 <Rubidium> though it's only an idea, nothing has been really tried yet due to time constraints 11:23:07 <planetmaker> But still one could first port VMs as now and in parallel / after that create the xen-domains for the individual CF tasks 11:23:31 <Rubidium> dihedral: we did search for existing ones quite often, never found one that matched our needs 11:24:02 *** KenjiE20 has joined #openttdcoop.devzone 11:24:12 <dihedral> hmmm 11:24:47 <Rubidium> e.g. we don't fancy ~10 targets to do a git clone of the cargodist repository as that's like 100 MiB each 11:25:20 <Rubidium> likewise keeping those clones it troublesome as there are quite a number of different compiled systems 11:25:40 <Rubidium> so we (need to) copy tar-ed repositories 11:25:43 <dihedral> i remember setting up hudson once to build openttd 11:26:42 <Rubidium> then we're using/running/having 3 or 4 different targets per virtual machine 11:29:34 <Rubidium> even then, those COTS compile farms require network connection which (for security purposes) we don't give the builders 11:44:44 <dihedral> you have a compile farm which you offer to other projects also, correct? 11:45:03 <dihedral> but do you do 'teamwork' with others who also have some sort of compile farm? 11:45:26 <dihedral> that way you could distribute over various servers and have some sort of joint CF 11:45:37 <dihedral> reducing cost, increasing effectiveness 11:46:51 <planetmaker> the only true gain I'd see there, if OpenTTD would get access to OS/2, Solaris, FreeBSD and OSX compilation 11:49:56 <Rubidium> solaris and freebsd is just adding the compile farms 11:50:51 <Rubidium> and the other projects are ttdpatch, open[gs]fx dependencies and "patch packs" 11:51:49 <Rubidium> so we're providing compile farm for others, but don't use the compile farm of others 11:53:15 <Rubidium> (with adding the compile farms I mean adding a virtual machine that compiles for those platforms) 11:53:44 <planetmaker> sure :-) 11:53:45 <Rubidium> problem with Solaris/*BSD is that there are very little users 11:54:04 <Rubidium> so the effort outweighs the costs 11:54:13 <planetmaker> so we would not notice problems. Yes, probably 11:54:38 <Rubidium> for OS/2 that's even more so; it somewhat runs in some virtualisation environment, but it's extremely tricky to set up 11:54:50 <Rubidium> leave alone getting it to mount some share 11:55:18 <Rubidium> and OSX is also easy, *if* Apple wouldn't be so godsmacked pedantic 11:58:12 <Rubidium> and it wouldn't be a big problem if they provided a hdiutil for Linux, even proprietary 11:58:29 <planetmaker> isn't hdiutil used now? 11:58:51 <Rubidium> no, we're making zip files, not dmg files 11:59:03 <Rubidium> and the only dmg files I could make are uncompressed 11:59:18 <planetmaker> hm, I seem to recall downloading dmg... 11:59:38 <Rubidium> planetmaker: that's pre 0.6.3 11:59:40 <dihedral> the thing with some other already existing build system, it's easily extendable 11:59:52 <Rubidium> when $Bjarni still compiled the releases 11:59:54 <dihedral> i.e. planetmaker could start an instance on his mac at home 12:00:06 <planetmaker> dihedral, that's not reliable enough 12:00:46 <dihedral> it's less work ;-) 12:00:58 <dihedral> and stays within the realms of official developers ^^ 12:01:08 <planetmaker> I'm not convinced about 'less work' 12:01:15 <dihedral> and you'd get the job from the master server anyway 12:01:25 <dihedral> i am :-P 12:01:37 <Rubidium> so if planetmaker is on a business trip with his laptop there are not OSX builds? 12:01:44 <Rubidium> so we can't do a release? 12:01:47 <dihedral> but merely because i spend about 2 - 3 weeks looking at various build systems 12:01:55 <dihedral> such as teamcity, bamboo, hudson, .... 12:02:13 <dihedral> Rubidium, iirc planetmaker has an imac? 12:02:22 <planetmaker> IIRC I do have a macbook 12:02:33 <Rubidium> so we get complaints about OSX missing in the nightlies and various other things such as 32bpp-ez and cargodist, or whatever other patch pack we intend to support 12:02:34 <dihedral> ah - i thought you had a desktop setup ^^ 12:03:13 <dihedral> well - it was at least something to demonstrate the picture 12:03:22 <dihedral> it would be easy to setup, distributable, etc. 12:03:22 <planetmaker> I should ask andy where he'd donate one of his (older) machines 12:03:30 <planetmaker> He seems to get every now and then one 12:03:42 <dihedral> with a joint effort of multiple projects, someone could get a mac server, someone else could ... 12:03:54 <Rubidium> dihedral: the point is, you're suggesting to run the compile farm the way it ran many years ago 12:04:25 <Rubidium> which was a big fiasco and triggered TrueBrain and MiHaMiX to build a centralised one (running a library of a Hungarian university) 12:04:42 <Rubidium> that one used only cross-compiling 12:05:02 <Rubidium> and only for the nightlies 12:05:05 <dihedral> what caused the fiasco? 12:05:19 <Rubidium> computers not being reliably online 12:05:23 <Rubidium> network issues 12:05:54 <Rubidium> running the latest and greatest version of $x, so it didn't work on most other user's systems 12:06:38 <dihedral> there are build systems that can be configured (on the master) to the extend of which library to use 12:06:53 <dihedral> i know you will not like a java system, but from what i have seen they work decently well 12:07:11 <dihedral> and some have a huge community and good support 12:07:28 <Rubidium> dihedral: until they update the compiler which makes java7 class files and it doesn't work anymore in java6 12:07:54 <Rubidium> or rather, when they upgrade their system and they get gcc 4.6 as default compiler 12:08:17 <Rubidium> and the people are all missing the related gcc 4.6 library 12:08:47 <dihedral> iirc it's possible to define with which compiler your source is to be compiled 12:08:55 <dihedral> else it makes little to no sense 12:09:03 <Ammler> he, we didn't complete the move 12:09:17 <Rubidium> yes, which fails nicely when for some reason the upgrade removes that compiler 12:09:19 <Ammler> I just prepared the vms and setup some scripts to mirror 12:09:57 <dihedral> the build systems do not always rely on the system installed libraries 12:10:19 <dihedral> in some cases they are capable of keeping their own stuff 12:11:05 <dihedral> i had a hudson setup in which i said i want all java compilers from version x to y available 12:11:18 <dihedral> and they were installed in subdirectories of the hudson environment 12:11:27 <dihedral> not where they'd be installed normally 12:11:59 <dihedral> so updating the os itself, or the java compiler had not effect on the libs / compiler the build environment used to work with 12:12:31 <dihedral> that was merely my experience 12:12:40 <Rubidium> java is relatively easy 12:13:05 <dihedral> until you have dependencies to stuff like struts, log4j, spring, ... 12:13:21 <dihedral> eps. to various versions 12:13:52 <dihedral> i would have to try it with various C/C++ projects 12:18:39 <Rubidium> in any case, I rather have a single place for all the compile farms as that reduces maintainance and communication quite significantly 12:19:47 <dihedral> hehe - rent an xserver and run the vm's in that :-D 12:20:14 <Rubidium> dihedral: yeah, prices starting at? 12:20:51 <dihedral> hehe 12:21:42 <Rubidium> ah, colocating a mac mini from 49 dollar a month 12:21:53 <Rubidium> you have to provide your own mac mini though 12:22:25 <dihedral> that should be possible ^^ 12:22:28 <Rubidium> otherwise... 119 dollar a month with the cheapest mac mini 12:22:38 <Rubidium> or only 499 dollar a month for a xserve 12:22:58 <dihedral> sum it up, it's probably cheaper to buy one second hand and then colocate it 12:23:11 <dihedral> however you have the downside of there bing no hardware support 12:23:47 <Ammler> oh, is mac support back? 12:24:01 <planetmaker> no(t yet) 12:24:06 <Ammler> :-D 12:25:31 <Rubidium> dihedral: still, it's 40 euro a month extra to what we pay already (given the mac is *free*). Which would then be over 40% of OpenTTD's expenses, for a mere 5% of the (pre 1.0) users 12:26:15 <Ammler> oh btw. an additional function for pm on the contact page: Basesets Maintainer 12:26:45 <dihedral> that for sure is true 12:26:58 <dihedral> wait - what do you currently pay for that server? 12:27:33 <dihedral> and Ammler: how long does it take to compile openttd on that server ? 12:27:36 <Rubidium> less than 60 euros a month 12:27:42 <Ammler> on our? 12:27:49 <dihedral> :-) 12:27:58 <dihedral> on the i7 server 12:28:01 <dihedral> yes 12:28:06 <planetmaker> faster ;-) 12:28:10 <Ammler> Rubidium: but that is because you have sponsoring? 12:28:18 <dihedral> time make -j5 and time -j9 ? 12:28:21 <dihedral> eh 12:28:25 <dihedral> time make -j9 ^^ 12:28:33 <dihedral> hetzner is cheaper :-P 12:28:47 <Ammler> I made that once, around 2mins 12:28:52 <Rubidium> Ammler: yep 12:28:56 <planetmaker> we were there yesterday. And pointless as long as the current contract runs 12:29:00 <dihedral> perhaps they let you get out of the contract early if you continue advertising them until the end of the contract ^^ 12:29:26 <dihedral> shame - take me about 29 seconds :-D 12:29:51 <planetmaker> --with-ccache ? 12:29:54 <dihedral> nope ^^ 12:30:16 <Ammler> I might have never done it on the native maschine with all the cores 12:30:17 <dihedral> vm running in a dual quad core system 12:31:42 <dihedral> cheap hosting for the amount of ram and cpu power i get ^^ 12:39:29 <Rubidium> in any case, let us first see what kind of service/stability Hetzner provides. Then when the leaseweb thing is near its end we can consider moving 12:39:56 <Rubidium> as I rather do not want to do that now as I've got no idea of my free time in the near future 12:40:08 <Rubidium> and I know that TrueBrain doesn't have that much 12:40:18 <dihedral> i had my share of contact with hetzner work wise 12:40:25 <dihedral> had to take care of a bunch of servers there 12:40:28 <dihedral> around 20 12:40:43 <dihedral> ranging from old servers to any of the EQ offers they have 12:41:28 <dihedral> the only thing i do not like is their silly Flex Pack you have to 'order' in order to get a RAID controller or an IP subnet, etc. 12:41:33 <dihedral> which costs 15 EUR / month 12:42:09 <dihedral> and then getting a subnet is still only usable on that one server and not across all servers you own there 12:42:25 <dihedral> ip's are bound to the mac address :-( 12:42:33 <dihedral> grrr 12:43:01 <Rubidium> well, we definitely want a few (at least 3) ip addresses 12:43:25 <Rubidium> and preferably not in the same range :) 12:43:33 <dihedral> you get 4 ipv4 addresses and a /64 range of ipv6 12:43:47 <planetmaker> Rubidium, not the same range is 1€ / month and IP address. Up to 4 12:44:02 <dihedral> are those 4 not 'included'? 12:44:07 <Ammler> yeah, we were lucky 12:44:14 <Ammler> that changed lately 12:44:20 * Rubidium is off doing some groceries though :) 12:44:20 <dihedral> grrr 12:44:26 <dihedral> enjoy :-) 12:44:32 <planetmaker> good luck ;-) 12:45:10 <planetmaker> IPv4 get more expensive - there'll be none left next summer ;-) 12:45:28 <dihedral> apparently, yes 12:45:37 <dihedral> i am glad i have my 8 :-P 12:45:49 <dihedral> got them at no extra cost ^^ 12:47:41 <Ammler> real 0m54.045s 12:47:43 <Ammler> user 2m43.614s 12:48:04 <Ammler> building on kvm kde with 2 cpus of 8 12:48:32 <planetmaker> it's approx 1/6 of my compile time (real) 12:48:35 <planetmaker> user is not that bad 12:48:58 <Ammler> why is there such a big difference? 12:49:38 <dihedral> if you have 2 cores, try a -j3 ;-) 12:49:57 <Ammler> well, it is 4 12:50:05 <Ammler> used j5 12:50:28 <planetmaker> oh, on that machine you could indeed use -j8 or so :-) 12:50:29 <dihedral> and you have 8 cores (with HT) not 8 cpus ^^ 12:50:30 <planetmaker> would be faster 12:50:42 <dihedral> planetmaker, if the vm has access to those cores, yes 12:50:48 <dihedral> else not 12:51:03 <dihedral> and i assume Ammler means 2 cores of 8 12:51:17 <dihedral> and i am not convinced HT does that much difference 12:51:21 <Ammler> hmm, 2 cpu sockets and 2 cores/socket 12:51:26 <Ammler> I read it wrongly 12:51:32 <Ammler> for vm it is 4 12:51:44 <dihedral> Ammler, i thought you had an i7 12:52:08 <dihedral> which means you have 4 cores with HyperThreading enabled (at Hetzner that is standard) 12:52:10 <Ammler> yes, but I won't build on the host 12:52:18 <planetmaker> :-) 12:52:23 <dihedral> so the vm is configured 2 cpu's? 12:52:29 <dihedral> why not 1 cpu with 4 cores? 12:52:29 <Ammler> no, 4 12:52:42 <dihedral> confused ^^ 12:52:44 <Ammler> does that matter? 12:52:58 <Ammler> 2 sockets, 2 cores/socket -> 4 cores 12:53:09 <dihedral> depends what the hypervisor does out of it 12:53:13 <Ammler> that is how a vps is configured 12:53:31 <Ammler> well, cat /proc/cpuinfo does tell 4 12:53:40 <dihedral> 4 what ^^ 12:54:04 <Ammler> cpus 12:54:22 <Ammler> what else? 12:56:21 <Ammler> http://paste.pocoo.org/show/284958/ 12:56:23 <Webster> Title: Paste #284958 | LodgeIt! (at paste.pocoo.org) 12:57:33 <dihedral> Ammler, that clearly shows 2 cpu's with 2 cores each 12:57:37 <dihedral> not 4 cpu's ^^ 12:57:50 <Ammler> difference? 12:57:59 <dihedral> hint: processor -> physical_id 12:58:13 <dihedral> + core id 12:58:18 <dihedral> siblings 12:58:22 <dihedral> ... 12:58:37 <Ammler> yes, but does it make a difference on the result? 12:58:41 <planetmaker> the difference is shared vs. not shared cache, address pipes, ... or so 12:58:55 <Ammler> I mean, it is virtual anyway 12:59:06 <Ammler> (kvm) 12:59:37 <Ammler> I could give it more cpus than I have 13:00:12 <dihedral> i am not sure where the difference lies in the hypervisor 13:00:25 <dihedral> however, if only one cpu is present, i'd personally only give the vm one cpu 13:00:43 <dihedral> merely to avoid any possible hick hack 13:00:59 <dihedral> and vise versa 13:01:21 <dihedral> if i have a 2 cpu system with 2 cores each, i'd not give the vm 4 cores on a single cpu 13:01:49 <dihedral> if the hypervisor handles it decently - fine, if it does not, i'd consider it too much overhead 13:03:39 <Ammler> http://paste.pocoo.org/show/284961/ 13:03:40 <Webster> Title: Paste #284961 | LodgeIt! (at paste.pocoo.org) 13:03:47 <Ammler> hypervisor ^ 13:07:18 <planetmaker> it clearly shows that the CPU is nearly sleeping ;-) 13:07:44 <planetmaker> model name... 2.67GHz vs. cpu MHz 1600 ;-) 13:08:11 <Ammler> proxmox tells 2% usage 13:08:36 <Ammler> and I run a kde vm since I went to the military 13:08:52 <Ammler> which for example runs the irc stuff 13:09:30 <Ammler> with nx, this is quite cool 13:10:00 <dihedral> but the systems are pretty much ideling - which for example all vm hosters bet on 13:10:14 <dihedral> else they could not provide a vm at such low cost ^^ 13:10:27 <Ammler> yep, cpu is mostly no issue, just memory 13:10:27 <dihedral> which is my virtualisation makes so much sense 13:10:28 <planetmaker> ^ :-) 13:10:33 <planetmaker> They just need lots of ram 13:10:48 <dihedral> but if you try to emulate something that the host does not have, you will quickly see that it will use more cpu ^^ 13:10:57 <Ammler> for gameservers, it is best to buy vps, imo 13:11:00 <dihedral> i.e. try to emulate some motorola cpu :-P 13:11:08 <planetmaker> :-P 13:11:12 <dihedral> not for shootemups 13:11:16 <planetmaker> emulate CRAY 13:11:29 <planetmaker> on a VPS 13:11:30 <planetmaker> :-P 13:11:31 <dihedral> the vm's are not fast enough to provide what a decent css server needs, e.g. 13:11:42 <Ammler> dihedral: openttd is a typical vps game 13:11:47 <Ammler> no memory, but lots of cpu 13:11:50 <dihedral> openttd is special :-P 13:12:05 <dihedral> css will be nasty in a vm 13:12:16 <dihedral> simply because the vm does not get that number of cycles 13:12:31 <dihedral> to sanely run a css server at tick 100 13:12:31 <Ammler> planetmaker: has plans "to sell" good openttd servers ;-) 13:12:37 <planetmaker> :-D 13:12:43 <dihedral> hmm :-S 13:12:48 <dihedral> yet even more servers ^^ 13:13:04 <dihedral> $_$ <- pm's expression? :-P 13:13:14 <planetmaker> ^^ :-P 13:13:44 <planetmaker> Honestly I forgot about that completely. Nor is it something I want to do with too much effort 13:13:54 <Ammler> the most cpu usage game on our archive runs with around 30% on our new server 13:14:02 <planetmaker> But when there comes yet again another "how do I .." - it's easy to say "rent for 10€/month" ;-) 13:14:07 <planetmaker> when it's a simple cp -r ;-) 13:14:07 <Ammler> the ps isn't able to handle it 13:14:25 <planetmaker> hm. Should we move PS, too? 13:14:30 <planetmaker> Later? 13:14:34 <Ammler> not really 13:14:41 <planetmaker> good :-) 13:14:43 <Ammler> the clients needs to be able to join 13:21:55 <dihedral> if you do not mind the 10 eur and want good cpu stuff, and if you do not mind the vm, calnotopia is quite fun ^^ 13:22:03 <dihedral> they do not restrict cpu's across the different vm types 13:22:24 <dihedral> so every vm gets the same access to all 8 cores 13:22:38 <dihedral> and they are truely 8 cores, not 4 cores with HT ^^ 13:22:39 <planetmaker> dihedral, I wouldn't buy or rent anything extra for that. I'd only rent out as many of those such that our server can nicely handle 13:22:57 <planetmaker> It'd be just to rip of those who need it :-P 13:23:02 <dihedral> lol 13:23:19 <dihedral> what if one decides to include 100 ships per company? :-P 13:23:30 <Ammler> I wouldn't care 13:23:33 <planetmaker> then they shall do that 13:23:44 <Ammler> as it runs on it's own cpu 13:24:58 <planetmaker> dihedral, I got that 'idea' when there were - some time ago - users asking for OpenTTD game servers. 13:25:36 <planetmaker> given ap+ back then - or maybe in the future the admin interface - it's easy as pie to configure and setup them 13:28:56 <dihedral> i have a close to working java process handler for openttd games :-P 13:29:05 <dihedral> spawns openttd servers :-P 13:29:14 <dihedral> can quick and start them 13:29:27 <dihedral> can also read stdout and stderr ^^ 13:33:02 <planetmaker> the other idea already back then was that those slackers would then help finance the server - also not a bad thing ;-) 13:34:20 <Ammler> I would like automatic setup server based on the openttd branches 13:34:29 <Ammler> like is2 and cargodist 13:34:42 <Ammler> h2h... 13:34:56 <planetmaker> yeah :-) 13:35:21 <Terkhen> but they will expect you to keep them updated 13:35:21 <planetmaker> more important: it needs a web upload to savegames and config 13:35:33 <Ammler> yep, "automatic" :-) 13:35:37 <planetmaker> Terkhen, that's not really difficult 13:35:59 <Ammler> yes, that is modified "autonightly" 13:36:08 <Terkhen> no, just rather tedious 13:36:10 <planetmaker> I'd first start with stables 13:36:21 <planetmaker> and testing releases only 13:36:27 <planetmaker> autonightly maybe, too 13:36:55 <planetmaker> but nothing else, unless it has a well-defined binary source, too. Like cargodist / h2h 13:37:34 <Ammler> yep, svn/hg/git url 13:37:35 <planetmaker> Terkhen, but indeed. That's one of the reasons why I didn't really follow that path so far 13:37:51 <planetmaker> it needs to be easy as pie to maintain 13:38:07 <Ammler> again "automatic", nothing else 13:43:21 <dihedral> autonightly was simple ^^ 13:47:07 * planetmaker ponders some more about shunting trains 13:48:48 * planetmaker considers easter eggs like high-speed train only available on maps with bigger x direction and in April only :-P 13:49:03 <planetmaker> Hm or only on 64x64? 13:51:11 <planetmaker> February 29 :-) 13:51:43 <Rubidium> when Easter and Pentecost are in the same weekend 13:52:12 <planetmaker> :-) 13:56:02 *** Levi has joined #openttdcoop.devzone 13:58:49 <Terkhen> are you planning to add wagons that do something else besides transporting cargo? 13:59:42 *** Levi has left #openttdcoop.devzone 14:04:59 <planetmaker> I might. I've graphics for a nice tender by DanMacK 14:05:15 <dihedral> planetmaker, i love eastereggs :-) 14:05:17 <planetmaker> I'm pondering what to do with it exactly. Possibly giving some additional power to an engine 14:06:02 <planetmaker> And I just realized, even if I implemented shunting, it'd then be the passenger wagon which fumes the steam - and not the engine :S 14:06:11 <Ammler> lol, highspeed train only available on 64 map? 14:06:16 <planetmaker> ^ 14:06:29 <planetmaker> there you need faster trains in order to make money ;-) 14:06:54 <Terkhen> hmm... as long as it is not something too complicated... 14:07:27 <planetmaker> Terkhen, I won't add anything which will make default usage impossible. 14:07:39 <planetmaker> Except that players will need to get accustomed to refitting 14:07:43 <planetmaker> But that can't be avoided 14:07:52 <planetmaker> when we want ECS / FIRS compatibility 14:07:54 <Terkhen> yes, I don't think it would be possible to avoid that either 14:08:21 <planetmaker> nor do I want to impose restrictions on the current behaviour. We want to improve it. Not restrict ;-) 14:08:44 <planetmaker> So I'm thinking of having the tender defined as a slightly powered wagon w/o capacity or so 14:12:21 <planetmaker> Alternatively I'm thinking of adding a parameter. Mostly as I'm toying with the shunting idea - which means I have to impose some restrictions. 14:29:38 <Terkhen> if it is not something too intrusive, I don't think that a parameter is required 14:30:34 <planetmaker> If :-) I'm not sure yet 14:35:46 *** SmatZ has joined #openttdcoop.devzone 14:53:16 *** Hirundo_ has joined #openttdcoop.devzone 14:58:48 <Hirundo_> Ammler / planetmaker: Is there a known problem with the bouncer 14:59:03 <Ammler> we moved 14:59:14 <Ammler> you might not have used the host bnc.openttdcoop.org? 14:59:30 <Ammler> Hirundo_: ^ 15:00:01 <Ammler> or irc.openttdcoop.org 15:00:36 <Ammler> but you should use bnc.openttdcoop.org as that is what is official 15:00:49 <planetmaker> Hirundo_, not really - you used bnc.openttdcoop.org before afaik? 15:00:54 <Ammler> (since almost a year) 15:00:57 *** Hirundo is now known as Jasper 15:00:58 <planetmaker> But the physical host changed 15:01:14 <planetmaker> it's not salieri anymore but 101.haydn 15:01:19 *** Jasper is now known as Hirundo 15:01:27 <planetmaker> thus if you configured anything depending on that it fails 15:01:38 <planetmaker> But your accunt is there and active and didn't change 15:01:57 <Hirundo_> works now, thanks 15:02:02 <planetmaker> :-) 15:02:03 <Ammler> yes, I synced before the switch, also the whole buffer and away should be there 15:02:11 <planetmaker> :-) 15:02:18 *** Hirundo has left #openttdcoop.devzone 15:02:31 *** Hirundo_ has left #openttdcoop.devzone 15:02:37 *** Hirundo has joined #openttdcoop.devzone 15:02:41 <planetmaker> :-) 15:12:57 *** Lakie has joined #openttdcoop.devzone 15:34:26 *** frosch123 has joined #openttdcoop.devzone 17:10:54 <Brot6> nml: update from r973 to r975 done - http://bundles.openttdcoop.org/nml/nightlies/r975 17:19:20 <Brot6> airportsplus: update from r64 to r65 done - http://bundles.openttdcoop.org/airportsplus/nightlies/r65 17:19:55 <Brot6> Following repos didn't need a nightlies update: 2cctrainset (r635), 32bpp-extra (r39), ai-admiralai (r71), basecosts (r22), belarusiantowns (r7), comic-houses (r71), firs (r1483), fish (r415), frenchtowns (r4), grfcodec (r785), heqs (r479), indonesiantowns (r38), manindu (r5), metrotrackset (r56), newgrf_makefile (r220), nml (r975), nutracks (r117), ogfx-trains (r86), ogfx-trees (r41), opengfx (r554), openmsx (r97), opensfx (r97), smts 17:19:55 <Brot6> (r19), snowlinemod (r45), swedishrails (r187), swisstowns (r21), transrapidtrackset (r15), ttdviewer (r26), ttrs (r23), worldairlinersset (r667) 17:23:24 *** thgergo has joined #openttdcoop.devzone 18:03:25 <Brot6> OpenGFX+ Road Vehicles - Revision 23:451b642ffec4: Update: Names of a few values due to changes i... (Terkhen) @ http://dev.openttdcoop.org/projects/ogfx-rv/repository/revisions/451b642ffec4 18:06:14 <Ammler> enable nightly building? ^ 18:07:28 <Ammler> echo "nml" > .devzone/build/type && touch .devzone/build/nightlies/enable && touch .devzone/build/releases/enable 18:07:38 <Terkhen> not yet, it should build but I spotted a few errors... the bulk trucks don't appear in the buy list anymore and I don't know why 18:10:03 <Hirundo> Yexo: how does alt_sprites work? 18:10:24 <Yexo> the syntax? 18:12:39 <Yexo> alternative_sprites(<name_of_[replace|spriteset+fontglyph]_block>, <zoom_level_constant>, <optional filename>) { <same as other real sprite lists> } 18:13:04 <Hirundo> does it need anything in the code to make it reference to a sprite set correctly? 18:14:03 <Yexo> the block_name parameter of real_sprite.parse_sprite_list 18:15:24 <Hirundo> action5.py: real_sprite.parse_sprite_list(replaces.sprite_list, replaces.pcx, block_name = replace.name) <- spot the error 18:15:43 <Yexo> replace vs replaces 18:16:33 * Hirundo hands cookie 18:17:57 <Hirundo> hmm.... are alt_sprites blocks skipable? 18:19:08 <Yexo> yes 18:19:32 <Yexo> at least, RealSpriteAction seems to support it (skip_action7/9 return true) 18:20:07 <Yexo> I didn't read the *alt_* part 18:20:30 <Yexo> yes, they are, but it's not useful in any way 18:20:38 <Yexo> they're always used, even inside an if-block 18:27:42 <planetmaker> http://devs.openttd.org/~planetmaker/patches/ogfx-trains-nightly.tar <-- Terkhen for a train like the arctic wills 2-8-2 with passenger wagons it might make sense to have a parameter :-) 18:27:51 <planetmaker> (once that is more than the hack it is now) 18:28:27 <planetmaker> (have it run back and forth a short piece of track :-) ) 18:31:11 <Terkhen> the different sprites will be used when it has passenger wagons? 18:31:32 <planetmaker> only that engine and the passenger wagon behave special, yes 18:31:41 <planetmaker> no other overrides yet programmed 18:32:09 <planetmaker> other wagons will break it horribly, I guess 18:32:42 <Terkhen> what would be the behaviour in that case? 18:33:03 <planetmaker> when moving backward with the engines in the rear it'd make sense to limit the speed 18:33:24 <planetmaker> but that should not be the default behaviour 18:33:32 <planetmaker> But it would definitely be a nice goody :-) 18:33:50 <planetmaker> well. WAY more than a goody. It'll be much work ;-) 18:34:10 <Terkhen> yes... sounds like a lot of work 18:34:59 <planetmaker> http://pastebin.com/k1hyMjrg <-- if you're interested 18:36:11 <planetmaker> but the more I look at this, I *think* that a proper solution would be an additional engine flag like 2cc or MU which reads like NO_REVERSE. 18:36:25 <planetmaker> When the lead engine has it set, the train is not turned on an EOL situation 18:37:43 <Terkhen> hmmm... never used those flags, I'm still doing only simple things 18:37:57 <Hirundo> So the 'lead engine' is actually the last vehicle in the train? 18:39:19 *** Alberth has joined #openttdcoop.devzone 18:42:06 <planetmaker> Terkhen: what I do is basically a livery override 18:42:33 <Terkhen> IIRC that was a change of graphics under certain conditions, right? 18:42:35 <planetmaker> and in the reversed state, I draw pax wagons for the engine(s) and engine graphics for the last wagon(s) 18:42:42 <planetmaker> yes 18:43:08 <planetmaker> it allows to use for a certain wagon other graphics when used with an engine 18:43:28 <planetmaker> and I do the same with the engine (w/o) livery override, directly via varaction2 chain 18:43:58 <planetmaker> both use - at least in NML - the same graphics definitions, though. Just the if-then-else is inverted 18:44:20 <Terkhen> then it is quite similar to what we are already doing for cargos in wagons/trucks 18:44:34 <Terkhen> I suppose PARENT refers to the first engine of the consist 19:10:23 <Brot6> 32bpp-ez-patches: update from r21072 to r21076 done - http://bundles.openttdcoop.org/32bpp-ez-patches/testing/r21076 19:19:08 <Brot6> clientpatches: update from r21072 to r21076 done - http://bundles.openttdcoop.org/clientpatches/testing/r21076 19:20:22 <Brot6> serverpatches: compile of r21076 still failed (#1658) - http://bundles.openttdcoop.org/serverpatches/testing/ERROR/r21076 19:28:26 <Brot6> NewGRF Meta Language - Feature Request #1327: allow more than 255 names (Alberth) @ http://dev.openttdcoop.org/issues/1327#change-4493 19:35:09 <planetmaker> [19:44] <Terkhen> I suppose PARENT refers to the first engine of the consist <-- that's the lead engine, yes 19:51:13 *** OwenS has joined #openttdcoop.devzone 20:04:26 <Yexo> planetmaker: a link to file:// is not very useful for other people: http://www.tt-forums.net/viewtopic.php?p=911361#p911361 20:04:28 <Webster> Title: Transport Tycoon Forums • View topic - FIRS Industry Replacement Set - Development & Translations (at www.tt-forums.net) 20:04:52 <planetmaker> indeed. Thanks 20:18:50 <Ammler> Alberth: he :-) 20:19:04 <Alberth> good evening :) 20:19:10 <Ammler> thanks for the mail :-P 20:19:33 <Alberth> you must be reading your mail much more often than me :p 20:19:57 <Ammler> I will test it but I can't close tickets for nml 20:20:11 <Alberth> I have not heard any other problems about the town names 20:20:34 <Alberth> except somebody trying to have more names than possible by NFO 20:20:59 <Ammler> I am not sure anymore, I thought, you changed something after I reopened 20:21:22 <Ammler> and we agreed it is fine 20:21:30 <Alberth> I did, the chances were messed up 20:21:45 <Ammler> but it is already again long ago 20:22:13 <Alberth> somebody asked for a long pause :p 20:22:25 <Alberth> I can also close the issue now, if you like 20:23:20 <Ammler> well, I guess, what I would like is not doable 20:23:38 <Ammler> the randomizer can't handle it 20:24:24 <Ammler> I thought, I can make one category with all towns and if someone generates a small map, the "big" cities would be taken first 20:25:21 <Ammler> I "implemented" that with 2 categories before, "Swiss" and "Swiss (extreme)" 20:25:49 <Ammler> where Swiss had only around 150 entries 20:25:51 *** frosch123 has quit IRC 20:26:13 <Alberth> you had an option to switch between them? 20:26:30 <Ammler> yep, well I made 2 20:26:42 <Ammler> the extreme was both parts 20:27:23 <Ammler> the problem is that if you use too high probabilities, the generator gets soon out of names 20:28:38 <Alberth> yes, the dense towns and a large map needs about 2500 names 20:29:04 <Ammler> I have the feeling, that openttd first generates a name, if that name is already taken, it doesn't regenerate 20:29:08 <Alberth> which is doable if you have parts that are randomly combined, but not as a long list 20:29:16 <Ammler> it just skipes that town and tries the next 20:29:41 <Alberth> I would not be surprised if that happens 20:30:36 <Ammler> but anyway, it takes quite a long time to generate a map with 2k names 20:31:03 <Ammler> and I have no idea, how to count the names, it is just "feeling" 20:31:48 <Ammler> the sice of the slide bar is a good indicator :-) 20:31:52 <Ammler> size* 20:32:23 <Alberth> doesn't it print some number? 20:32:31 <Ammler> where? 20:33:03 <Ammler> if the map generates it does show how many are tried to generate 20:33:11 <Ammler> but not how many you finally got 20:34:27 <Alberth> oh, such a number. No you don't get it, unless you count the #entries in the town directory :) 20:34:54 <Ammler> yeah, I guess it with help of the slide bar 20:35:10 <Ammler> it was quite bad before I reopened 20:35:24 <Ammler> and now it is better but not as good as my nfo grf 20:36:18 <Ammler> but I consider that as a issue of openttd, not nml 20:36:43 <Alberth> that's because nml generates a different layout of the names, I guess? 20:37:03 <Ammler> I don't split anymore 20:37:53 <Ammler> as said, not nml issue 20:38:05 <Alberth> so just close the issue then? 20:38:13 <Ammler> yep :-) 20:38:15 <Ammler> fine with me 20:38:35 <Ammler> I can only delete the issue :-P 20:38:36 <Alberth> ok, thanks for testing and the feedback 20:39:31 <Ammler> thanks for the nml, it is much easier 20:40:24 <Brot6> NewGRF Meta Language - Feature Request #1327 (Closed): allow more than 255 names (Alberth) @ http://dev.openttdcoop.org/issues/1327#change-4494 20:40:33 <Alberth> I mostly did some side-things, not the core :) 20:40:46 <Ammler> hmm 20:41:48 <Ammler> a question about min_compatible_version, I have set it to 0, does that mean, if I generate a map with r22, and someone uses r2, he don't need to update? 20:42:17 <Yexo> it doesn't work in that direction, only the other way around 20:42:24 <Ammler> ok, fine 20:42:53 <Yexo> if it worked both ways you could as well not change the version at all 20:43:12 <Alberth> or better, not have versions :) 20:43:24 <Ammler> that's not possible :-P 20:43:30 <Ammler> (with nml) 20:52:19 <planetmaker> you can set both to 0 20:52:30 <planetmaker> which is in essence the same as no version 20:53:25 <Alberth> Yexo: as it is going with nml is not working for me. Too much frustration. I have decided to stop dev there for now 20:54:44 <Yexo> sad to hear, but I understand your reason 20:54:51 *** andythenorth_ has joined #openttdcoop.devzone 20:54:53 <andythenorth_> evening 20:55:42 <Yexo> I hope we can clean up the code good enough so you might consider rejoining at a later date 20:56:15 * Alberth hopes so too 20:57:41 * planetmaker hands Alberth a fortune cookie 21:00:41 <Hirundo> sad, though not unexpected news 21:04:24 *** seberoth has quit IRC 21:05:10 *** dihedral has quit IRC 21:11:32 <Alberth> good night 21:11:37 <Terkhen> night Alberth 21:12:01 <planetmaker> good night Alberth 21:12:17 *** Alberth has left #openttdcoop.devzone 21:13:12 <andythenorth_> what did I miss :o 21:19:24 <Hirundo> <Alberth>as it is going with nml is not working for me. Too much frustration. I have decided to stop dev there for now 21:23:03 <andythenorth_> :| 21:23:35 <planetmaker> yeah :-( 21:25:06 <Hirundo> both documentation and code style are *cough* sub-optimal in some/most places 21:26:11 <andythenorth_> how close to 'done' is it? 21:27:02 <planetmaker> My personal guess is a few months still. But I might err and probably depends on RL 21:27:16 <planetmaker> but rather less then more 21:27:25 <Yexo> depends on what you call "done" 21:27:35 <planetmaker> I find it hard to judge the difficulty of the remaining tasks 21:27:41 <planetmaker> Yexo: 'done' = first release 21:28:00 <Yexo> if it's the 0.1 release: that won't necesarily have support for all features 21:28:15 <Yexo> for example stations 21:28:20 <planetmaker> it doesn't need that. But possibly a consolidated syntax 21:28:37 <planetmaker> Not sure how majore the changes are you consider 21:28:51 <Yexo> as much as possible before 0.1 21:29:01 <planetmaker> yes 21:29:39 <Hirundo> #1695 is mostly done 21:29:39 <Brot6> Hirundo: #1695 is http://dev.openttdcoop.org/issues/show/1695 "NewGRF Meta Language - Feature Request #1695: sprite block restructuring - #openttdcoop Development Zone" 21:34:23 <andythenorth_> in terms of 'done', I'm thinking of the types of grfs that can be produced... 21:34:28 <andythenorth_> railtypes? 21:34:33 <planetmaker> yes 21:34:35 <Yexo> see swedishrails :) 21:34:45 <Yexo> vehicles: yes 21:34:46 <Brot6> NewGRF Meta Language - Revision 976:f92fd0ac8174: Fix (r931): industry production flags is not a ... (yexo) @ http://dev.openttdcoop.org/projects/nml/repository/revisions/f92fd0ac8174 21:34:46 <Brot6> NewGRF Meta Language - Code Review #1447 (Closed): revise and unify usage of bitmasks and lists (yexo) @ http://dev.openttdcoop.org/issues/1447#change-4495 21:34:51 <planetmaker> first NML newgrf to have reached maturity :-) 21:34:56 <Yexo> industry: probably, but haven't personally tested that yet 21:35:08 <planetmaker> airports 21:35:15 <planetmaker> objects 21:35:18 <planetmaker> somewhat 21:35:21 <Yexo> townnames :p 21:35:26 <planetmaker> :-) 21:35:33 <planetmaker> base costs 21:35:45 <Yexo> snowline mod 21:35:55 <andythenorth_> so nml would be viable for a new RV set? 21:35:59 <Hirundo> only major deficiencies would be stations and houses, I think 21:36:01 <planetmaker> or general variables in general, generally speaking 21:36:02 <Yexo> definitely 21:37:07 <Yexo> Hirundo: does "#1695 mostly done" include that you already broke all existing grfs that used spritesets/spritegroups? 21:37:07 <Brot6> Yexo: Hirundo: #1695 is http://dev.openttdcoop.org/issues/show/1695 "NewGRF Meta Language - Feature Request #1695: sprite block restructuring - #openttdcoop Development Zone" 21:37:08 <planetmaker> missing features is not dramatic. 21:37:49 <Hirundo> Yexo: mostly done means that spriteblocks have no meaning, and a warning is emitted if you use them 21:38:05 <Yexo> ok 21:38:18 <Hirundo> The feature of sprite sets / groups is derived from their links, I want to do some more testing with that first 21:38:39 <Yexo> r976 accidentally contains the incomplete patch for #1740, so it's currently broken 21:38:54 <Yexo> will fix that as soon as I can, until than keep at r975 or ignore any errors 21:39:53 <Ammler> just make regression test fail :-) 21:40:13 <Yexo> it already does 21:40:15 <Ammler> and the CF won't try with newer version 21:40:33 <Ammler> @logs 21:40:33 <Webster> Logs: http://hyru.ath.cx:60080/~kenji/ottdcoop/ 21:41:14 <Ammler> ah 975 was today nightly 21:41:34 <Ammler> hmm 21:43:29 <planetmaker> good regression tests are not that easy to come by... 21:44:06 <Rubidium> actually, most nml bug reports could/should be turned into regression tests :) 21:44:16 <planetmaker> yes 21:44:34 <Rubidium> though I know that's a lot of boring work 21:44:40 <planetmaker> I came to that conclusion yesterday, too ;-) 21:44:41 <Rubidium> and gets easily forgotten 21:45:03 <planetmaker> when the animation failed due to a nasty type ;-) 21:45:06 <planetmaker> *typo 21:45:39 *** dihedral has joined #openttdcoop.devzone 21:49:56 *** dih has joined #openttdcoop.devzone 21:50:12 *** dihedral has quit IRC 22:01:18 <Yexo> planetmaker: 3rd argument for error can now be a literal string 22:01:32 <planetmaker> \o/ :-) 22:01:36 <Yexo> the syntax for a normal string changed from only the string-id to "string(string-id)" 22:01:56 <Yexo> now I'm wondering about the second parameter 22:02:17 <Brot6> NewGRF Meta Language - Revision 977:dace9bf156ac: Change: the 3rd argument to error(...) can now ... (yexo) @ http://dev.openttdcoop.org/projects/nml/repository/revisions/dace9bf156ac 22:02:42 <Yexo> using string(STR_XXX) there too for custom strings seems more consistent 22:03:03 <planetmaker> the parameters? yes 22:03:28 <Yexo> error(NOTICE, USED_WITH, STR_REGRESSION_CARE); 22:03:28 <Yexo> <- old syntax 22:03:37 <Yexo> error(NOTICE, USED_WITH, string(STR_REGRESSION_CARE)); 22:03:37 <Yexo> <- new syntax 22:04:02 <Yexo> error(FATAL, STR_REGRESSION_ERROR, STR_ANSWER, 14, param[1] + 12 * param[2]); <- what about this case? Should "STR_REGRESSION_ERROR" also be changed to "string(STR_REGRESSION_ERROR)" ? 22:06:37 <planetmaker> would be consistent, yes 22:06:55 <planetmaker> not 100% sure, though 22:09:28 <planetmaker> I'm off to bed. Good night 22:10:17 <Yexo> gn planetmaker 22:19:51 <Brot6> NewGRF Meta Language - Revision 978:6f7b23b721b3: Change #1740: second parameter to error now als... (yexo) @ http://dev.openttdcoop.org/projects/nml/repository/revisions/6f7b23b721b3 22:19:51 <Brot6> NewGRF Meta Language - Bug #1740 (Closed): error with error(...) (yexo) @ http://dev.openttdcoop.org/issues/1740#change-4496 22:28:21 *** andythenorth_ has quit IRC 23:10:38 *** ODM has quit IRC 23:25:22 <dih> hehe - this will blow off his roof :-P 23:26:44 <Brot6> Grapes - Revision 0:4ba57b06fbea: Grapes SPI - working PluginManager including Annotations (dih) @ http://dev.openttdcoop.org/projects/grapes/repository/revisions/4ba57b06fbea