Log for #openttdcoop.devzone on 2nd November 2010:
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 execution expired
09:44:32  *** Guest1600 is now known as planetmaker
10:43:23  <Brot6> #openttdcoop - New Server (Ammler) @
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>
12:56:23  <Webster> Title: Paste #284958 | LodgeIt! (at
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>
13:03:40  <Webster> Title: Paste #284961 | LodgeIt! (at
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
14:59:30  <Ammler> Hirundo_: ^
15:00:01  <Ammler> or
15:00:36  <Ammler> but you should use as that is what is official
15:00:49  <planetmaker> Hirundo_, not really - you used 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 -
17:19:20  <Brot6> airportsplus: update from r64 to r65 done -
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) @
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> real_sprite.parse_sprite_list(replaces.sprite_list, replaces.pcx, block_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> <-- 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> <-- 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 -
19:19:08  <Brot6> clientpatches: update from r21072 to r21076 done -
19:20:22  <Brot6> serverpatches: compile of r21076 still failed (#1658) -
19:28:26  <Brot6> NewGRF Meta Language - Feature Request #1327: allow more than 255 names (Alberth) @
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:
20:04:28  <Webster> Title: Transport Tycoon Forums • View topic - FIRS Industry Replacement Set - Development & Translations (at
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) @
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 "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) @
21:34:46  <Brot6> NewGRF Meta Language - Code Review #1447 (Closed): revise and unify usage of bitmasks and lists (yexo) @
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 "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:
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) @
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>  <- 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) @
22:19:51  <Brot6> NewGRF Meta Language - Bug #1740 (Closed): error with error(...) (yexo) @
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) @

Powered by YARRSTE version: svn-trunk