IRC logs for #openttd on OFTC at 2012-08-09
⏴ go to previous day
04:15:27 *** HerzogDeXtEr has joined #openttd
04:56:17 *** Eddi|zuHause has joined #openttd
05:23:07 * neofutur tuning parameters for his citybuilding server
05:30:24 *** telanus has joined #openttd
05:31:02 *** andythenorth has joined #openttd
05:48:19 *** sla_ro|master has joined #openttd
05:56:40 <planetmaker> on the other side of the atlantic right now, andythenorth? :-)
05:57:33 <andythenorth> my brain is still on last night
05:59:00 <planetmaker> mine is already on tomorrow ;-)
05:59:16 <planetmaker> holidays ahead! yippih
05:59:37 <Supercheese> Uni classes about to begin, more like
06:00:05 *** |Jeroen| has joined #openttd
06:00:08 <Supercheese> just around the corner
06:00:19 <planetmaker> woah, versity classes don't start before October here. Beginners courses in late September
06:04:18 <andythenorth> what a strange idea
06:15:08 <planetmaker> I know, very strange ;-)
06:21:39 *** LordPixaII has joined #openttd
06:38:10 *** LordPixaII has joined #openttd
07:04:32 *** LordPixaII has joined #openttd
07:42:02 *** Phazorx has joined #openttd
07:43:06 <Phazorx> got cargodest quetion - with opngfx data from 1.2.0 tip of git as of one hour ago complains about missing sprites, what else do i need for it to work?
07:43:53 *** andythenorth has left #openttd
07:46:42 *** valhallasw has joined #openttd
08:01:44 <Eddi|zuHause> you need a development version of OpenGFX
08:01:58 <Eddi|zuHause> since you use a development version of OpenTTD
08:05:52 *** TGYoshi has joined #openttd
08:06:31 <Phazorx> aha... coopers have it i take?
08:08:26 <Phazorx> 533 B/s - 11.7 KB of 3.3 MB, 1 hour left
08:09:39 <Eddi|zuHause> it's a non.critical error anyway. only some GUI sprites are affected, and they will be replaced by ?-Sprites
08:12:20 <Phazorx> oh... good to know... still DL speed sounds like an issue
08:13:58 <Ammler> good someone can tell me what is wrong :-)
08:20:04 <Phazorx> Ammler: heya, i can tell you how it looks like from this end
08:21:51 <Phazorx> and not anymore... wget fetched it just fine this time, before it was breaking after ~12K going down to few hundreds bps
08:38:07 <Ammler> Phazorx: possible, a broken network card could cause this?
08:40:03 <Ammler> wget also resumes automatically but e.g. with firefox, it sucks
08:40:19 <Phazorx> oh... you just fixed that or something?
08:40:45 <Ammler> no, we had some network issue yesterdayyesterday
08:41:09 <Phazorx> hmm... and apprently still having them?
08:41:44 <Ammler> yep, it comes and goes
08:42:00 <Phazorx> you got bonding emabled and multiple nics by any chance?
09:12:35 *** Rhamphoryncus has joined #openttd
09:25:06 *** telanus1 has joined #openttd
09:59:52 *** FLHerne has joined #openttd
10:26:34 *** drac_boy has joined #openttd
10:55:01 *** mahmoud has joined #openttd
11:29:43 <gynter> Hei, is there a recommended directory strugture for a NewGRF?
11:30:31 <gynter> Or everything except lang/ I can put where I like?
11:31:26 <Eddi|zuHause> but if you use an existing build system like the coop makefile, then you should stick to their directory structure
11:33:33 <gynter> but pnml/pnfo are some coop Makefile specific things? eg temlates?
11:34:43 <Eddi|zuHause> basically you run it through the C preprocessor before compiling with grfcodec/nmlc
11:36:50 <Phazorx> what are major/minor differences between cargodest and yacd?
11:37:16 <Ammler> Phazorx: you mean cargodist :-)
11:37:21 <mark> hi, I wish to make some corrections to the wiki. how do I get a login to the wiki?
11:42:03 <gynter> is it possible to mix both nml and nfo togehter in the same grf?
11:43:36 <planetmaker> in principle yes. But it's a pain. And there's little reason to combine it
11:45:02 <drac_boy> probably if someone wanted a nfo station into a nml grf otherwise?
11:45:09 <planetmaker> you can use nmlc to create nfo code which then combined by a pre-processor with other nfo code which then can be coded by grfcodec
11:45:12 <drac_boy> (from what I could tell of earlier talks)
11:45:56 <planetmaker> drac_boy: currently it makes no sense to write any part of a station grf in nml.
11:49:05 *** Zeknurn` has joined #openttd
11:52:26 *** Zeknurn` is now known as Zeknurn
12:06:36 <FLHerne> planetmaker: What if you wanted a combined station/object grf?
12:07:01 <Ammler> or use nfo for objects
12:08:02 <drac_boy> yeah no harm in more than one grf for a set as long as it is not something crazy like eg stationtile1.grf stationtile2.grf etc heap of 100+ grfs in one single set :p
12:08:11 <planetmaker> FLHerne: it's usually a very good idea to make two newgrfs if you touch two different (main) features
12:10:44 <drac_boy> FLHerne I have to ask as always, hows your progress coming along? heh :)
12:10:57 *** Devroush has joined #openttd
12:20:38 <FLHerne> drac_boy: Slowly. Got distracted trying to play Elite in DOSbox now :P
12:20:56 <FLHerne> Old games are so much harder :-(
12:21:03 <FLHerne> No menus to fiddle with
12:21:09 * drac_boy is still a bit busy with upcoming website and model train layout but wants to eventually finish that grf I had started before
12:26:54 <gynter> all images must be in png
12:31:25 <drac_boy> no idea I just use whatever I find comfortable
12:33:46 <TrueBrain> connect the dots? :)
12:34:17 <Ammler> but shouldn't security issues infect the system, not just openttd?
12:34:24 <planetmaker> gynter: with nmlc you can use many image formats; those which are supported by PIL. And those which support an 8bpp palette. png is "best" as it's both well compressed and easily viewable in a browser
12:34:33 <TrueBrain> Short description kinda tells you why it is a security issue Ammler :)
12:34:37 <planetmaker> gynter: with grfcodec you're constraint to png and pcx
12:35:00 <Ammler> TrueBrain: it tells that it does segfault openttd, thus my question
12:35:03 <gynter> planetmaker: thanks, that was the answer what I was looking for. Couldn't find it in the NML spec
12:35:18 <TrueBrain> short description says nothing about a segfault, does it?
12:35:48 <TrueBrain> in fact, only point 8 mentions it is a segfault
12:35:51 <TrueBrain> but it is not the important part
12:36:11 <Ammler> so it segfaults because of DOS?
12:36:23 <planetmaker> Ammler: because of invalid write
12:36:25 <TrueBrain> now you are just talking weird stuff :P
12:36:33 <TrueBrain> you are making it confusing
12:37:02 <Ammler> well, I have a bugreport on distro tracker and wonder, if I need to update the package or if I just can wait for final release
12:37:06 <TrueBrain> Ammler: if I can crash your apache remotely, how would you call that?
12:37:29 <Ammler> if you crash my openttd server, I wouldn't care
12:37:40 <TrueBrain> if I can crash your APACHE remotely, how would you call that?
12:37:46 <Ammler> and I would for sure not call it security issue, except it infects the system too
12:38:04 <TrueBrain> right, sorry I tried to help
12:38:13 <planetmaker> Ammler: if a 3rd party can from remote DOS your programmes... that *is* a security issue
12:38:25 <TrueBrain> planetmaker: he doesn't are
12:38:39 <Ammler> TrueBrain: that is not the same
12:38:51 <planetmaker> what is not the same?
12:39:18 <Ammler> if you can DOS a app, it is system issue, isn't?
12:39:31 <TrueBrain> you want to try it again, or do you keep dodging my questions?
12:39:37 <TrueBrain> else we are not going anywhere, and we can just stop talking
12:40:14 <planetmaker> Ammler: it's an issue of the application which can be DOSed
12:40:27 <planetmaker> In this case OpenTTD can be DOSed
12:40:39 <Ammler> but the DOS has also infect on the system
12:40:52 <planetmaker> it does. it crashes your server
12:40:55 <planetmaker> the openttd server
12:41:05 <planetmaker> I call that an issue. It can stop everyone playing.
12:41:15 <planetmaker> it's the same like people killing a www-server
12:41:45 <planetmaker> so a malicious person can kill every server there is out sthere
12:41:58 <planetmaker> by just connecting and doing the stuff as described
12:42:12 <Ammler> yes, I just wonder, if it hurts that much it needs an update or if I could wait for the final release
12:42:22 <planetmaker> that's up to you to decide
12:42:37 *** FlyingFoX has joined #openttd
12:43:03 <TrueBrain> but you don't care if people can crash your openttd server, so I guess you answered that yourself already
12:43:10 <planetmaker> Ammler: good service means to provide people with a security fix
12:43:23 <TrueBrain> (which is a very weird thing to say, as I would assume you would want to have your server in running order, but meh)
12:43:27 <planetmaker> so that malicious people cannot destroy your fun anymore
12:43:55 <Ammler> TrueBrain: yes, I wouldn't update my openttd because of it, but maybe I should update the distro package, that is my issue
12:44:12 <TrueBrain> you wouldn't update your server because it can be crashed?
12:44:15 <TrueBrain> you still run Apache 1.3?
12:44:18 <TrueBrain> I mean, come on ...
12:44:35 <Ammler> I wouldn't update because I don't run a server
12:44:43 <TrueBrain> @kban Ammler 300 this is enough
12:44:43 *** DorpsGek sets mode: +b *!~ammler@101.haydn.openttdcoop.org
12:44:44 *** Ammler was kicked by DorpsGek (this is enough)
12:44:49 <TrueBrain> I don't like trolls
12:49:43 *** DorpsGek sets mode: -b *!~ammler@101.haydn.openttdcoop.org
12:55:25 <TrueBrain> neofutur: atm I am not adding new mirrors, as I have to rewrite the system; do have a question for you: our server is at OVH too, but we have IPv6; you don't have it configured, or does it still need that professional paid package bla thingy doodle bla?
12:55:33 <TrueBrain> as we could really use an IPv6 enabled mirror :P
12:56:45 <TrueBrain> planetmaker: you remember how much traffic/month we had btw?
12:56:59 <orudge> TrueBrain: I could offer a de mirror (including IPv6) if we need more. We're mostly OK for EU mirrors though, I think. I'm hoping the US mirror can get IPv6 soon, the ISP just keeps saying "oh yes, we'll have it soon"... :p
12:57:17 <planetmaker> TrueBrain: where / what / when?
12:57:27 <TrueBrain> orudge: if the US mirror could be IPv6, would be great :)
12:57:33 <TrueBrain> planetmaker: OVH, traffic/month, now
12:57:43 <orudge> TrueBrain: well, when it is, I'll let you know :)
12:57:51 <TrueBrain> orudge: for EU based mirrors, I would love some more south and east in the EU :)
12:58:01 <TrueBrain> planetmaker: I mean, how much can we use
12:58:04 <planetmaker> you mean the contract? a few TB
12:58:06 <TrueBrain> my question was very unclear :D
12:58:21 <planetmaker> not sure exactly, I think 5TB
12:58:28 <TrueBrain> we are pushing more and more atm .. reached 0.5 TB a month last month, despite the mirrors :P
12:58:30 <orudge> OVH is generally 5TB or 10TB I think, then they'll slow you down to 10Mbps
12:59:12 <orudge> it's something like a euro per extra TB though
12:59:22 <planetmaker> hm, we do? the stats only tell 360GB
12:59:32 <TrueBrain> planetmaker: and the other 140GB was non-HTTP
13:00:02 <TrueBrain> orudge: yeah, I guess; just wanted to know how far we could grow before it becomes relevant :)
13:01:01 <TrueBrain> 150k BaNaNaS downloads in 3 days, lolz
13:01:24 <TrueBrain> it tells me ~150 GiB is done by mirrors in 3 days ... wuth?
13:01:54 <TrueBrain> it feels like a lie, so I am going to check that :)
13:03:16 <planetmaker> TrueBrain: is there somewhere actually a statistics with the non-http traffic?
13:03:28 <NGC3982> You guys need any help with that, btw?
13:03:37 * NGC3982 has a lonely gigabit connection he doesn't use.
13:03:56 <TrueBrain> depends on the coutnry NGC3982 ;) And I first need to fix the mirror system
13:04:12 <TrueBrain> its your personal connection?
13:04:17 <TrueBrain> as in: home connection
13:04:53 <NGC3982> Although, im not that familiar with hosting mirrors, but it's a personal connection that i use, but since i only use it rarely i can limit myself to 100Mbit and let the rest go to something else.. I guess.
13:04:56 <planetmaker> TrueBrain: there it also tells you that we got 15 TiB of monthly traffic for free ;-)
13:05:08 <NGC3982> It's a simple home connection.
13:05:09 <TrueBrain> planetmaker: ah, lolz, tnx :)
13:05:18 <TrueBrain> NGC3982: my advise, don't use it for mirroring etc
13:05:24 <TrueBrain> that is better spend on machines in a datacenter
13:05:36 <TrueBrain> you want to be able to reboot your computer etc
13:05:43 <TrueBrain> don't die under I/O etc
13:05:52 <NGC3982> Speaking of, im actually unsure what my linksys e3000 thinks about traffic like that.
13:06:32 <NGC3982> What am i talking about, i dont even have hardware that can support 100-120MB/s.
13:07:13 <TrueBrain> 3.7k BaNaNaS downloads initiated from the client yesterday
13:07:13 <NGC3982> Im am thinking about setting up some dedicated servers, though.
13:07:17 <TrueBrain> from 1.7k unique IPs
13:07:22 <TrueBrain> that is amasing ...
13:07:29 <NGC3982> Is that a record or something
13:07:43 <NGC3982> and with BaNaNas i guess you are refering to NewGRF downloads and such?
13:08:08 <NGC3982> Oh, even in-game online content downloads?
13:08:18 <TrueBrain> 2344 OpenTTD 1.2.1, 270 1.2.2-RC1, lolz
13:08:26 <TrueBrain> NGC3982: euh, yes? How else do you get those files?
13:08:35 <TrueBrain> you press Download, and it starts downloading? :)
13:08:38 <NGC3982> TrueBrain: I though you refered to the website statistics.
13:08:51 <TrueBrain> when you hit Download ingame
13:08:54 <TrueBrain> you make a HTTP POST call to our server
13:09:07 <TrueBrain> which replies a list with URLs to fetch
13:09:12 <TrueBrain> (which are either http:// or ottd:// )
13:09:14 <NGC3982> You guys built a big game. Cheers.
13:09:21 <TrueBrain> it got a bit out of hand :P
13:09:34 <NGC3982> TrueBrain: Is that really effective?
13:10:17 <NGC3982> Doesn't fetching http URL's basiclly mean fetching a file from a place from a place?
13:10:50 <NGC3982> Im just using silly puns
13:10:58 <TrueBrain> I am not awake enough for that :P
13:11:32 <TrueBrain> so, extrapolating on the data I have, it seems we use 2TB a month atm, of which 1.5TB ends up at our mirrors :P
13:11:38 * NGC3982 hands out Swedish Tunnbrd in celebration of BaNaNas statistics.
13:12:28 <TrueBrain> @calc 600000 / 24 / 60 / 60
13:12:28 <DorpsGek> TrueBrain: 6.94444444444
13:16:48 <TrueBrain> @calc 28878 / (787155 + 28878)
13:16:48 <DorpsGek> TrueBrain: 0.0353882747389
13:16:50 <TrueBrain> @calc 28878 / (787155 + 28878) * 100
13:16:50 <DorpsGek> TrueBrain: 3.53882747389
13:16:56 <TrueBrain> 3.5% of our traffic is over SSL
13:20:16 <TrueBrain> planetmaker: as you asked (and I was curious): in 3 days we received 2 GiB of data and send 50 GiB. 1.6 GiB of the incoming was for HTTP requests, the rest went mostly to ottd_content. Of the 50 GiB, most ofc is HTTP, but 2 important ones:
13:20:25 <TrueBrain> SVN used 1.5 GiB, and ottd_content used 12 GiB
13:20:35 <TrueBrain> so 12 GiB was used for old NewGRFs being downloaded
13:20:56 <planetmaker> interesting. Thanks :-)
13:21:04 <TrueBrain> the ottd_content is kinda odd tbh
13:21:59 <TrueBrain> but it clearly shows most bandwidth goes towards BaNaNaS services atm
13:22:11 <TrueBrain> I am scared with the upcoming 100+ MiB files :P
13:23:26 <planetmaker> yes... they'd get us into the critical range
13:23:38 <TrueBrain> it will push the system for sure :P
13:25:03 <TrueBrain> hmm .. I am pondering
13:25:11 <TrueBrain> maybe we should alter (or extend) our ToS with something like:
13:25:21 <TrueBrain> for files over 20 MiB, they will always be publically avaiable
13:25:45 <TrueBrain> (so not only the latest, but all)
13:26:28 <FLHerne> TrueBrain: How would that help?
13:26:30 <TrueBrain> I am a bit scared if such huge files won't push our ottd_content (which serves old content) too much
13:26:51 <TrueBrain> FLHerne: old content is served only by our own server, via a custom protocol
13:27:01 <TrueBrain> we cannot publish them on HTTP by our ToS
13:27:40 <TrueBrain> so if you have an old savegame, and press: download NewGRFs, it is very likely you won't hit any HTTP for them, and pull it out from our single server
13:28:13 <TrueBrain> this has always been fine, as the files are small
13:28:25 <TrueBrain> but of the 50 GiB in 3 days, 12 GiB already is for this old savegame support
13:28:30 <FLHerne> Surely you should just add that to your ToS anyway, to stop SAC etc breaking savegames? :P
13:28:55 <TrueBrain> its in our ToS, as several NewGRF authors want to be in control of their NewGRFs, which I respect
13:29:13 <TrueBrain> they feel having older NewGRFs on a public HTTP is asking for dumb users
13:29:55 <TrueBrain> but when files get big, 20+ MiB or so, it becomes a different problem :)
13:30:06 <FLHerne> Posting a NewGRF anyway is asking for dumb users :P
13:30:23 <NGC3982> Offering obsolete material publicly is a usually a bad choise for opensource stuff.
13:30:43 <TrueBrain> I did a trial by publishing it in an 'old' directory
13:30:44 <NGC3982> I remember myself as a teenager not understanding anything while trying to get software from sourgeforce
13:30:47 <TrueBrain> which you couldn't view
13:30:53 <TrueBrain> but some mirrors have ftp access
13:31:29 <NGC3982> TrueBrain: Well, of course you can make old material downloadable. I guess that is highly relevant in a developer perspective.
13:31:50 <NGC3982> Though, it feels like you really need to present it way, way back in line.
13:31:50 <TrueBrain> you can download it, just not by an easy click
13:32:05 <TrueBrain> which, sadly, includes not publishing via HTTP
13:32:12 <TrueBrain> as people browse mirrors and fail to understand ;)
13:32:16 <NGC3982> So dumb people don't have to join and wonder why FIRS 0.0.2 doesn't work.
13:32:29 <TrueBrain> as you see now, trying to get, say, FIRS 0.0.2 is hard
13:32:33 <TrueBrain> you ened a Savegame which used it
13:32:40 <TrueBrain> or know the exact details (grfid + md5)
13:32:53 <TrueBrain> but as soon as stuff is on an HTTP, people will download it
13:32:59 <TrueBrain> but that also means we cannot mirror them
13:33:02 <TrueBrain> which is a bitch for large files :p
13:34:07 * TrueBrain wonders if he can get some mirrors crazy enough to run a custom daemon :P
13:49:33 *** FLHerne has joined #openttd
14:47:01 <Eddi|zuHause> Message: NOT_REACHED triggered at line 1425 of /mnt/disk2/spiele/OpenTTD/trunk_clean/src/strings.cpp
14:47:07 <Eddi|zuHause> how the hell did i manage that?
14:48:14 *** valhallasw has joined #openttd
14:51:44 <Eddi|zuHause> in a FOR_ALL_VEHICLES_OF_TYPE, i put: SetDParam(0, eid); GetString(buffer, STR_VEHICLE_NAME, lastof(buffer));
14:52:08 <Eddi|zuHause> in a first run i get all empty strings, and after switching newgrfs, i get this crash
14:53:24 <TrueBrain> well, at least you now know how you managed it :D
14:53:42 <Eddi|zuHause> at least that was the last thing i changed :)
14:59:14 <neofutur> TrueBrain: just that I dont need ipv6, the server would probably be be dedibox / online.net/free.fr datacenter ( better peerings )
14:59:38 <neofutur> email me later when you need mirrors, my servers will probably still be there
15:00:13 <TrueBrain> we have too many mirrors close to AMS-IX :P
15:00:20 <TrueBrain> I want mirrors further away :D
15:00:39 <Eddi|zuHause> i guess i should use STR_ENGINE_NAME... *patsch*
15:00:49 <TrueBrain> lol @ Eddi|zuHause :D
15:02:07 <neofutur> or query me, i m always on oftc even if i m not always on #openttd
15:02:53 <TrueBrain> hmm .. my wishlist: IPv6 mirror, and one in Japan and Australia
15:02:59 <TrueBrain> who to bribe for that ...
15:03:17 <neofutur> eh servers are more expensive in austrealia and japan ;)
15:03:28 <TrueBrain> bandwidth mostly, rather expensive
15:03:31 <TrueBrain> like, really expensive :P
15:03:57 <TrueBrain> well, you would expect that peering would be cheap, so maybe we can only allow certain IP ranges to connect to those
15:04:05 <Eddi|zuHause> so bandwidth is cheaper TO australia than WITHIN australia?
15:04:25 <TrueBrain> TO is paid by all users an ISP has, most likely in the monthly cost
15:04:31 <TrueBrain> as dedicated server, you also have to pay for it
15:04:41 <TrueBrain> so that is a weird conclusion you make there :)
15:05:01 *** Prof_Frink has joined #openttd
15:05:32 * neofutur asking to a friend that have servers in japan
15:05:56 <TrueBrain> please do after I have the new mirror system working :P
15:06:00 <TrueBrain> no clue on any ETA on that ;)
15:07:09 <neofutur> TrueBrain: the friend is a friench friend having his company in japan, is there some kind of official mirror list with links to sponsors ?
15:07:25 <TrueBrain> on our webpage, ofcourse
15:07:33 <neofutur> or also on the main website ?
15:08:16 <TrueBrain> we don't have a mirror in FR
15:08:20 <TrueBrain> so that would be weird if it would say so
15:08:30 <neofutur> the OVH server is not in france ?
15:08:40 <neofutur> you told me you had servers at ovh ?
15:08:45 <TrueBrain> our main server is hosted by OVH, which is in France, yes
15:08:50 <TrueBrain> but it is not part of the mirror rotation
15:09:02 <TrueBrain> I am just complaining that we have too many mirrors around AMS-IX :P
15:09:27 <TrueBrain> (the main objective of the mirror network these days is to allow you to download the binaries faster :))
15:09:35 <TrueBrain> so, more peering == better
15:09:44 <neofutur> I moved most of my customers from ovh to dedibox those last years
15:10:02 <neofutur> dedibox have much better peerings, and other advantages
15:10:12 <TrueBrain> but they are in FR too, not?
15:10:26 <TrueBrain> so they won't have a peering to most Russian ISPs
15:10:29 <neofutur> dedibox/online.net is free.fr
15:10:36 <TrueBrain> or do ... what else do we have there .. ;)
15:10:36 <neofutur> one of the biggest ISPs in france
15:10:57 <TrueBrain> the reality is, that most ISPes in GB, DE, NL, FR all peer (excluding many other peers, ofc) in AMS-IX
15:10:59 <neofutur> as an ISO they have much more peerings than OVH
15:11:18 <TrueBrain> hmm, let me put this in another way
15:11:30 <TrueBrain> if an AS has many peerings, that doesn't always mean better latency
15:11:39 <TrueBrain> an AS with 4 peerings can serve many more ISPs better than one with 100
15:11:49 <TrueBrain> we have a few peering rings with many members
15:11:53 <TrueBrain> which are much better
15:11:59 <neofutur> well i m french and I live in Peru
15:12:10 <TrueBrain> and this is all fine and all, but my issue is: we have a lot of mirrors close to AMS-IX
15:12:12 <neofutur> I often have problems connecting my servers at ovh
15:12:14 <TrueBrain> they all kinds share the same peerings
15:12:23 <TrueBrain> one way or the other, give or take 1 hop
15:12:24 <neofutur> and need to first ssh to dedibox, then ssh to ovh from there
15:12:35 <neofutur> also, ovh is dropping too many dynamic ips
15:12:46 <TrueBrain> so I would really like servers more to the east etc
15:12:50 <TrueBrain> so we gain better connectivity there
15:13:03 <TrueBrain> Asia, Japan, Australia, Africa ..
15:13:14 <TrueBrain> those all go over transit atm
15:13:19 <TrueBrain> which means their latency is high
15:13:51 <neofutur> if you serve only fance and europe , ovh is good
15:13:59 <neofutur> for the rest of the world its pretty awful
15:14:09 <TrueBrain> I really don't care :)
15:14:15 <TrueBrain> it is of no relevance to OpenTTD :)
15:14:24 <TrueBrain> (not meaning to be rude, but it is not my point at all)
15:14:27 <TrueBrain> peerings are irrelevant
15:15:05 <TrueBrain> you seem to fail what I try to say at all :)
15:15:17 <TrueBrain> an ISP in FR won't have a direct peering to, say, Egypt
15:15:18 <neofutur> sorry, just telling you my experience and opinion concerning ovh
15:15:24 <neofutur> and why i moved from there
15:15:26 <TrueBrain> yes, but that is not important :)
15:15:34 <TrueBrain> we are not here to talk bad about one ISP or good about another :)
15:15:39 <TrueBrain> this is not the channel for that ;)
15:15:51 <neofutur> sorry, wont talk of this anymore
15:16:21 <neofutur> but we were initially speaking of a mirror for openttd
15:16:32 <neofutur> and mine would not be on ovh, telling you why
15:16:51 <NGC3982> TrueBrain: About the discussion we had before.
15:17:01 <NGC3982> TrueBrain: ..Do you need more mirrors?
15:17:14 <TrueBrain> we need more mirrors around the globe
15:17:29 <TrueBrain> like I am trying to point out: 80% of our mirrors are concentrated around AMS-IX
15:17:35 <NGC3982> Speaking of, how does the community pay for stuff like that?
15:17:36 <TrueBrain> which doesn't really help anymore at this point
15:17:50 <TrueBrain> we have, for example, only 1 mirror in the US
15:17:56 <TrueBrain> the whole US, goes to 1 single point
15:18:07 <TrueBrain> while in Europe there are 4 mirrors very close to eachother :P
15:18:15 <TrueBrain> NGC3982: the community doesn't pay for it
15:18:18 <TrueBrain> mirrors are all sponsored
15:18:24 <TrueBrain> (in the form of an ad on the page)
15:18:33 <TrueBrain> most current mirrors are servers who have bandwidth idle
15:18:37 <TrueBrain> which they pay for anyway
15:35:15 <Eddi|zuHause> which newgrf properties can i safely initialize to 0?
15:43:23 <TrueBrain> the second from the left *troll*
15:43:30 <Eddi|zuHause> apparently not the refit properties :)
15:47:01 <gynter> Does loading sprites from multiple graphic files takes more memory than using one file for multiple sprites (eg putting all rails to one png)?
15:47:19 <TrueBrain> I am still wondering why mirrors in other continents are so hard to get ...
15:47:26 <TrueBrain> maybe because most of our community is EU? I guess ..
15:52:15 *** Eddi|zuHause has joined #openttd
15:52:20 <Eddi|zuHause> gynter: no, the sprites are put in the grf, the pngs are irrelevant
15:54:02 <Eddi|zuHause> hm... NML up to 1.8GB memory usage (RES)
15:54:34 <gynter> so basically who cares how many png-s I have?
15:55:00 <Eddi|zuHause> gynter: right. pngs are only used during compiling of the grf
15:57:18 <Eddi|zuHause> and this feels longer than in the past...
15:57:30 <gynter> ah, okay, but when using same sprite alignment multiple times it's good to define a template? Does defining the template decreases memory usage and grf size?
15:58:20 <Eddi|zuHause> defining a template reduces your copy-pasting of code
15:58:43 <gynter> okay, thanks for the info
16:04:25 <Eddi|zuHause> blärghs... i should really convert CETS to NFO :p
16:04:48 <Eddi|zuHause> took like 15 minutes to compile...
16:07:16 <planetmaker> Eddi|zuHause: did you consider using the caching property of new(est) NML?
16:07:32 <planetmaker> the makefile doesn't yet support it. Or rather it simply needs updating of the nmlc parameters
16:07:46 <Eddi|zuHause> planetmaker: CETS doesn't use nmlc for graphics conversion
16:08:01 <Eddi|zuHause> planetmaker: this is purely reading the .nml and outputting the .nfo
16:08:04 <planetmaker> you mean nml->nfo->grfcodec ?
16:08:15 <planetmaker> right. You might consider trying nmlc with caching
16:08:23 <planetmaker> not sure whether it's faster, but might
16:08:43 <planetmaker> as only modified sprites need be re-encoded
16:08:43 <Eddi|zuHause> it doesn't matter
16:09:39 <Eddi|zuHause> it will not matter as long as the nml->nfo step already takes 15 minutes (which it did not used to... was 2 minutes before)
16:10:29 <Eddi|zuHause> planetmaker: the current bottleneck is parsing the nml file and keeping the tree in memory
16:11:08 <Eddi|zuHause> last month, when i compiled the last time
16:11:31 <planetmaker> you should talk to hirnundo with about that when he returns from his holidays
16:12:18 <V453000> nuts takes about 10-15 minutes to compile too :<
16:12:39 <planetmaker> V453000: also try to use caching
16:12:58 <planetmaker> some command line parameter... try nmlc --help :-)
16:13:12 <planetmaker> I don't know by heart either; I haven't implemented it yet either
16:13:37 <V453000> I need to update NML for that I guess
16:13:37 <gynter> nmlc is pure python right?
16:13:41 <planetmaker> but in essence it keeps in memory the sprites as they're needed in the grf. And only re-encodes them when changed
16:13:48 <planetmaker> yes, to about newest nightly
16:14:02 <neofutur> 18:41 < TrueBrain> I am still wondering why mirrors in other continents are so hard to get ...
16:14:25 <neofutur> imo, because servers and bandwidth are much more expensive there, nothing more
16:14:29 <planetmaker> NGC3982: you talked about ads / advertizement... care to frame me in?
16:15:13 <neofutur> few people have servers in japan or australia
16:15:25 <NGC3982> planetmaker: Id rather do that in PM, if that's ok with you?
16:18:14 <V453000> ok I see refittable_cargo_types is obsolete :z
16:19:27 <planetmaker> yes... the preferred way is to specify the cargos exactly which you allow refit
16:19:51 <planetmaker> and the general case by cargo class, if you want to skip specific cargo configuration
16:20:02 <V453000> I think I do that already
16:20:52 <planetmaker> there's two new properties cargo_allow_refit and cargo_disallow_refit which takes explicit cargo labels
16:21:24 <planetmaker> it's a bit of work to convert, sadly. But it frees you from dealing with cargo class changes for single cargos breaking your grf
16:21:33 <planetmaker> which happend sometimes in the past. Like for ECS and FIRS
16:30:29 *** frosch123 has joined #openttd
16:42:02 <Eddi|zuHause> planetmaker: the only sane way i know to fix it would be modularizing nml files
16:57:05 * neofutur meeding citybuilding player to test the citybuilding settings of his server
16:57:33 <planetmaker> Eddi|zuHause: that might be interesting. But... also very difficult
16:58:34 <Eddi|zuHause> planetmaker: the other thing that may help would be a memory-efficient parser implemented in C(++)
16:59:37 <Eddi|zuHause> ok, that sounds slightly better than last time: real 4m11.603s user 3m24.201s sys 0m6.334s
17:04:05 <Eddi|zuHause> now imagine we had 32bpp extra zoom files :)
17:07:15 <Eddi|zuHause> conceptual problem: the specs say articulated parts need weight zero, but how do you set the weight to zero if the articulated part is the same as the front vehicle?
17:09:47 <planetmaker> Eddi|zuHause: those 32bpp extra zoom files would be cached... would they lengthen encoding much then?
17:10:47 <Eddi|zuHause> but they definitely increase file size
17:16:54 <mikegrb> DELETE-0-BUVM-swap-7891630 vg1 -wi-ao 1.00T
17:17:35 <Eddi|zuHause> planetmaker: just cets r701 increased compile time by 35%
17:25:45 *** Alberth has joined #openttd
17:25:45 *** ChanServ sets mode: +o Alberth
17:33:53 *** Ciprian has joined #openttd
17:34:09 <Ciprian> Does anyone knows how can I delete deserts in the scenario mode?
17:34:22 <planetmaker> try ctrl+build desert
17:42:10 *** andythenorth has joined #openttd
17:45:32 <CIA-4> OpenTTD: translators * r24462 /trunk/src/lang/ (hungarian.txt portuguese.txt turkish.txt):
17:45:32 <CIA-4> OpenTTD: -Update from WebTranslator v3.0:
17:45:32 <CIA-4> OpenTTD: hungarian - 1 changes by IPG
17:45:32 <CIA-4> OpenTTD: portuguese - 18 changes by ricardoespsanto
17:45:32 <CIA-4> OpenTTD: turkish - 7 changes by otrkmen
18:22:48 *** Biolunar has joined #openttd
18:26:21 <Ciprian> Does anyone know how to use the ECS NewGRFs?
18:27:47 <Pinkbeast> What is the difficulty you are having, please?
18:29:40 <Ciprian> None of the NewGRFs is loading, except the Town GRF
18:29:52 <Ciprian> The error given is "Town GRF must be loaded first"
18:30:12 <Pinkbeast> Have you tried rearranging the order of the GRFs in the selection interface?
18:59:59 <Eddi|zuHause> hm... not sure if this is a "bug" or something, but the depot-size-estimation seems to call the sprite with cargo type "buy menu" (because there is no real vehicle yet), but then it will get the buy menu sprite which might not be the correct representation for the later "real" depot sprite
19:00:22 <Eddi|zuHause> this shows with the cropped FISH sprites
19:00:53 <andythenorth> am I not supposed to be providing some extra sprite for the depot?
19:01:03 <andythenorth> I wrote a ticket for it I think :P
19:01:14 <Eddi|zuHause> so FISH might need to check extra_callback_info1 in the buy menu chain
19:01:15 <andythenorth> more newgrf bureaucracy :P
19:01:55 <Eddi|zuHause> or alternatively in the "normal" chain
19:02:23 <Eddi|zuHause> checking for EIT_IN_DEPOT (or whatever the nml equivalent of that is)
19:02:53 <frosch123> Eddi|zuHause: yes, depot size estimation of ships/aircraft uses buy menu chain with EIT_IN_DEPOT
19:03:01 <frosch123> i think we even documented that
19:06:42 <Eddi|zuHause> andythenorth: so in the purchase-sprite-chain, you need to check extra_callback_info1, if 0x20: return cropped sprite, else return normal sprite
19:10:01 <Eddi|zuHause> on a related note: www.informatik.uni-halle.de/~krause/resize_purchase_list2.diff <-- now with left-aligning vehicles and separate handling of depot and purchase list sprites
19:11:05 <Eddi|zuHause> funnily the gui makes sure the sprite is never drawn outside of the window
19:14:16 *** Supercheese has joined #openttd
19:15:51 *** Supercheese has joined #openttd
19:23:38 *** drac_boy has joined #openttd
19:25:03 <andythenorth> Eddi|zuHause: can't test right now sorry :|
20:18:01 <nicfer> I want to create a map with sparse cities without town minimum distance patch... I think I'll need to use the scenario editor but that seems too fixed
20:18:31 <Yexo> you can specify a custom number of cities when randomly generating them
20:18:39 <Yexo> have you tried simply setting a very low number?
20:20:22 <nicfer> yes but towns tend to generate clumped together while the rest of the map is void
20:21:18 *** andythenorth has joined #openttd
20:21:32 <Eddi|zuHause> that is how randomness works...
20:22:18 <Eddi|zuHause> if you want more even distribution, you want _less_ randomness
20:23:22 <nicfer> with minimum town distance I get towns spread nicely without overflowing
20:23:48 *** Chris_Booth has joined #openttd
20:24:27 <nicfer> and I'm using a patchpack that doesn't have that patch, and I can't load pregenerated maps
20:25:08 <Alberth> generate one, look up the coordinates, and copy it in the SE ?
20:25:44 <Alberth> just clicking a few times yourself is easier probably
20:41:54 *** andythenorth has left #openttd
20:46:37 *** Zeknurn has joined #openttd
22:35:36 *** LordPixaII has joined #openttd
22:46:42 *** Zeknurn has joined #openttd
22:51:12 *** LordPixaII has joined #openttd
22:55:26 *** KingPixaIII has joined #openttd
22:56:12 *** michi_cc has joined #openttd
22:56:12 *** ChanServ sets mode: +v michi_cc
23:01:33 *** tokai|noir has joined #openttd
23:01:33 *** ChanServ sets mode: +v tokai|noir
23:02:46 *** drac_boy has joined #openttd
23:45:23 *** Supercheese has joined #openttd
continue to next day ⏵