Times are UTC Toggle Colours
00:10:26 *** guru3 [~guru3@000128ea.user.oftc.net] has quit [Read error: Connection reset by peer] 00:10:39 *** guru3 [~guru3@000128ea.user.oftc.net] has joined #openttd 00:20:50 *** George is now known as Guest1717 00:20:52 *** George [~George@185.43.94.91] has joined #openttd 00:26:28 *** Guest1717 [~George@185.43.94.91] has quit [Ping timeout: 480 seconds] 00:34:13 *** MJP [~mjp@hq.z77.fr] has quit [Ping timeout: 480 seconds] 00:51:09 *** DDR [~kvirc@S010600254bbe4e1c.vc.shawcable.net] has joined #openttd 00:51:34 *** MTsPony [~marctraid@008-086-128-083.dynamic.caiway.nl] has quit [] 00:52:09 *** MTsPony [~marctraid@008-086-128-083.dynamic.caiway.nl] has joined #openttd 00:59:28 *** KWKdesign [~KWKdesign@pool-108-52-130-213.phlapa.fios.verizon.net] has quit [Ping timeout: 480 seconds] 01:33:45 *** Jerik [~Jerik@c-68-80-55-194.hsd1.pa.comcast.net] has joined #openttd 01:34:41 *** JerikTelorian [~Jerik@c-68-80-55-194.hsd1.pa.comcast.net] has joined #openttd 01:50:40 *** glx is now known as Guest1728 01:50:40 *** glx [~glx@000128ec.user.oftc.net] has joined #openttd 01:50:43 *** mode/#openttd [+v glx] by ChanServ 01:56:45 *** Guest1728 [~glx@000128ec.user.oftc.net] has quit [Ping timeout: 480 seconds] 02:12:03 *** bdavenport [~davenport@aeolus.mindlesstux.com] has joined #openttd 02:12:27 *** glx [~glx@000128ec.user.oftc.net] has quit [Quit: Bye] 02:14:11 *** bdavenport [~davenport@aeolus.mindlesstux.com] has quit [] 02:19:03 *** luaduck is now known as luaduck_zzz 02:21:47 *** George is now known as Guest1732 02:21:49 *** George [~George@185.43.94.91] has joined #openttd 02:22:43 *** KWKdesign [~KWKdesign@216.155.131.74] has joined #openttd 02:27:00 *** Guest1732 [~George@185.43.94.91] has quit [Ping timeout: 480 seconds] 02:38:04 *** George is now known as Guest1734 02:38:06 *** George [~George@185.43.94.91] has joined #openttd 02:43:28 *** Guest1734 [~George@185.43.94.91] has quit [Ping timeout: 480 seconds] 02:44:32 *** guru3_ [~guru3@90-230-86-71-no225.tbcn.telia.com] has joined #openttd 02:45:18 *** guru3 [~guru3@000128ea.user.oftc.net] has quit [Read error: Connection reset by peer] 03:02:09 *** HerzogDeXtEr [~flex@i59F6C2F9.versanet.de] has quit [Read error: Connection reset by peer] 03:25:34 *** George is now known as Guest1741 03:25:36 *** George [~George@185.43.94.91] has joined #openttd 03:26:14 *** sla_ro|master [slamaster@89.137.74.191] has joined #openttd 03:30:53 *** Guest1741 [~George@185.43.94.91] has quit [Ping timeout: 480 seconds] 03:35:46 *** Hazzard_ [~quassel@c-67-174-253-44.hsd1.ca.comcast.net] has joined #openttd 03:36:05 *** pthug [~pthagnar@cpc7-pres17-2-0-cust28.18-3.cable.virginm.net] has quit [Quit: Leaving] 03:42:12 *** tokai|mdlx [~tokai@port-92-195-167-168.dynamic.qsc.de] has joined #openttd 03:42:23 *** tokai|noir [~tokai@00012860.user.oftc.net] has quit [Ping timeout: 480 seconds] 03:42:28 *** Hazzard [~quassel@c-67-174-253-44.hsd1.ca.comcast.net] has quit [Ping timeout: 480 seconds] 03:55:29 *** tokai [~tokai@00012860.user.oftc.net] has joined #openttd 03:55:32 *** mode/#openttd [+v tokai] by ChanServ 03:56:20 *** George is now known as Guest1746 03:56:22 *** George [~George@185.43.94.91] has joined #openttd 03:56:22 *** tokai|mdlx [~tokai@port-92-195-167-168.dynamic.qsc.de] has quit [Ping timeout: 480 seconds] 03:58:25 *** tokai|mdlx [~tokai@port-92-195-28-53.dynamic.qsc.de] has joined #openttd 04:01:53 *** Guest1746 [~George@185.43.94.91] has quit [Ping timeout: 480 seconds] 04:03:53 *** tokai [~tokai@00012860.user.oftc.net] has quit [Ping timeout: 480 seconds] 04:20:38 *** jrambo [~jrambo@178-222-93-92.dynamic.isp.telekom.rs] has joined #openttd 04:24:03 *** KWKdesign [~KWKdesign@216.155.131.74] has quit [Read error: Connection reset by peer] 04:24:28 *** KWKdesign [~KWKdesign@216.155.131.74] has joined #openttd 04:25:22 *** tokai|mdlx [~tokai@port-92-195-28-53.dynamic.qsc.de] has quit [Ping timeout: 480 seconds] 04:29:34 *** tokai [~tokai@00012860.user.oftc.net] has joined #openttd 04:29:37 *** mode/#openttd [+v tokai] by ChanServ 04:38:22 *** tokai [~tokai@00012860.user.oftc.net] has quit [Ping timeout: 480 seconds] 04:42:34 *** tokai [~tokai@00012860.user.oftc.net] has joined #openttd 04:42:37 *** mode/#openttd [+v tokai] by ChanServ 04:43:21 *** George|2 [~George@185.43.94.91] has joined #openttd 04:43:21 *** George is now known as Guest1752 04:43:21 *** George|2 is now known as George 04:47:18 *** Guest1752 [~George@185.43.94.91] has quit [Ping timeout: 480 seconds] 04:53:12 *** sla_ro|master [slamaster@89.137.74.191] has quit [] 04:53:12 *** DDR [~kvirc@S010600254bbe4e1c.vc.shawcable.net] has quit [Read error: Connection reset by peer] 04:56:02 *** Eddi|zuHause [~johekr@p5DC67110.dip0.t-ipconnect.de] has quit [] 04:56:16 *** Eddi|zuHause [~johekr@p57BD471D.dip0.t-ipconnect.de] has joined #openttd 05:14:19 *** George is now known as Guest1757 05:14:21 *** George [~George@185.43.94.91] has joined #openttd 05:19:40 *** Guest1757 [~George@185.43.94.91] has quit [Ping timeout: 480 seconds] 05:33:08 *** George|2 [~George@185.43.94.91] has joined #openttd 05:33:08 *** George is now known as Guest1761 05:33:08 *** George|2 is now known as George 05:35:58 *** Guest1761 [~George@185.43.94.91] has quit [Ping timeout: 480 seconds] 05:53:10 *** tokai|mdlx [~tokai@port-92-195-101-57.dynamic.qsc.de] has joined #openttd 05:56:33 *** tokai|noir [~tokai@00012860.user.oftc.net] has joined #openttd 05:56:36 *** mode/#openttd [+v tokai|noir] by ChanServ 05:57:22 *** tokai [~tokai@00012860.user.oftc.net] has quit [Ping timeout: 480 seconds] 06:01:52 *** Hazzard_ [~quassel@c-67-174-253-44.hsd1.ca.comcast.net] has quit [Ping timeout: 480 seconds] 06:02:22 *** tokai|mdlx [~tokai@port-92-195-101-57.dynamic.qsc.de] has quit [Ping timeout: 480 seconds] 06:22:46 *** tokai [~tokai@00012860.user.oftc.net] has joined #openttd 06:22:49 *** mode/#openttd [+v tokai] by ChanServ 06:24:52 *** tokai|noir [~tokai@00012860.user.oftc.net] has quit [Ping timeout: 480 seconds] 06:25:26 *** chrswk [~chrswk@213.188.55.189] has joined #openttd 06:25:52 *** tokai|mdlx [~tokai@port-92-195-3-214.dynamic.qsc.de] has joined #openttd 06:32:03 *** tokai [~tokai@00012860.user.oftc.net] has quit [Ping timeout: 480 seconds] 06:35:44 *** George|2 [~George@185.43.94.91] has joined #openttd 06:35:44 *** George is now known as Guest1770 06:35:44 *** George|2 is now known as George 06:38:42 *** tokai|mdlx [~tokai@port-92-195-3-214.dynamic.qsc.de] has quit [Ping timeout: 480 seconds] 06:39:43 *** Guest1770 [~George@185.43.94.91] has quit [Ping timeout: 480 seconds] 06:43:38 *** tokai [~tokai@00012860.user.oftc.net] has joined #openttd 06:43:41 *** mode/#openttd [+v tokai] by ChanServ 06:44:48 *** Nothing4You [N4Y@Nothing4You.w.tf-w.tf] has quit [Ping timeout: 480 seconds] 06:48:09 *** Nothing4You [N4Y@Nothing4You.w.tf-w.tf] has joined #openttd 06:48:55 *** jonty-comp [~jonty@000128f3.user.oftc.net] has quit [Read error: Connection reset by peer] 06:49:41 *** Flygon_ [~Flygon@147.18.214.218.sta.commander.net.au] has quit [Read error: Connection reset by peer] 06:52:25 *** jonty-comp [~jonty@000128f3.user.oftc.net] has joined #openttd 06:53:53 *** tneo [~tneo@188.cimarosa.openttdcoop.org] has quit [Ping timeout: 480 seconds] 06:54:46 *** tneo [~tneo@188.cimarosa.openttdcoop.org] has joined #openttd 06:54:48 *** Osai^2 [~Osai@188.cimarosa.openttdcoop.org] has quit [Ping timeout: 480 seconds] 06:54:48 *** Yexo [~Yexo@188.cimarosa.openttdcoop.org] has quit [Ping timeout: 480 seconds] 06:55:16 *** Yexo [~Yexo@188.cimarosa.openttdcoop.org] has joined #openttd 06:55:16 *** Osai [~Osai@188.cimarosa.openttdcoop.org] has joined #openttd 07:00:16 *** Flygon [~Flygon@147.18.214.218.sta.commander.net.au] has joined #openttd 07:01:13 *** Myhorta [~Myhorta@00018fad.user.oftc.net] has joined #openttd 07:21:16 *** JerikTelorian [~Jerik@c-68-80-55-194.hsd1.pa.comcast.net] has quit [Read error: Connection reset by peer] 07:21:16 *** Jerik [~Jerik@c-68-80-55-194.hsd1.pa.comcast.net] has quit [Read error: Connection reset by peer] 07:25:33 *** Myhorta [~Myhorta@00018fad.user.oftc.net] has quit [Ping timeout: 480 seconds] 07:28:07 *** Myhorta [~Myhorta@00018fad.user.oftc.net] has joined #openttd 07:30:08 *** Myhorta [~Myhorta@00018fad.user.oftc.net] has quit [] 07:36:57 <planetmaker> moin 08:01:07 *** guru3_ is now known as guru3 08:03:50 *** DigitalFox [~DigitalFo@bl17-61-74.dsl.telepac.pt] has joined #openttd 08:03:58 <DigitalFox> morning :) 08:04:13 <DigitalFox> Ok this is driving nuts and I need help... 08:04:15 <planetmaker> o/ 08:04:17 <V453000> mooin 08:04:30 <DigitalFox> I'm compiling zbase in nml 08:04:35 <DigitalFox> no errors 08:04:41 <planetmaker> I also heard that nuts trains usually are driving. Except when using wetrail ;) 08:04:43 <DigitalFox> i change the md5 of zbase 08:05:00 <DigitalFox> i start openttd and it says it's corrupt :\ 08:05:27 <DigitalFox> no graphics are missing, sprites corruption, just like any nnormal game 08:05:27 <planetmaker> DigitalFox, the "md5sum" in the zbase.obg is not a real md5sum but the value obtained by grfid -m 08:05:48 <planetmaker> grfid is part of the grfcodec package 08:06:17 <DigitalFox> ok, so I get md5 value from there? 08:06:43 <planetmaker> grfid is a programme. Which will give you the value 08:07:11 <DigitalFox> I'm doing a fun project, merging zbase + biggui + 32 ez build :o 08:07:22 <planetmaker> how did you compile zbase, btw? If you call make, it should automatically (try to) call grfid. 08:07:40 <DigitalFox> I'm in Windows ;) 08:07:41 <planetmaker> and thus properly re-generate zbase.obg 08:08:16 <planetmaker> well, the build process does not lend itself well to windows 08:08:28 <planetmaker> the makefile explains what you got to do. Step by step :P 08:08:40 <DigitalFox> Well it's more time consuming, but it's working :) 08:10:41 <DigitalFox> So licenses? A bit mess hum? I mean if I would like to share my project with someone on the forum, how sharable are the the sprites from EZ? I'm asking because I know most artists left or are "piss*d" over png loading :\ 08:11:03 <planetmaker> all "md5sums" for grfs are md5sums only over the pseudosprite part. Thus grfid programme is kinda a 'must have' 08:11:17 <planetmaker> zbase has absolutely no license mess. Nice and clean gpl v2 08:11:37 <DigitalFox> planetmaker: trying grfid right now, major thank you! 08:12:31 <planetmaker> basically everything on devzone has no license mess. Every project ships with a license file and makes clear as to how and under which conditions it can be shared 08:13:37 <DigitalFox> yeah zbase and biggui fine, but EZ? I'm really not sure what to do after I'm done, it's coming great, the best of the 3 worlds in my eyes, we'll see :) 08:13:43 <DigitalFox> Again thank you planetmaker :) 08:14:07 <planetmaker> what is "EZ"? Zoom levels are nothing special really. Just bigger sprites 08:14:38 <DigitalFox> http://dev.openttdcoop.org/projects/32bpp-ez-build/ 08:15:46 <planetmaker> interesting. The license part 2 is not covered by the terms of usage of the DevZone ;) 08:17:17 <planetmaker> I agree, that is a total mess there 08:18:54 <DigitalFox> yeah + the fact I hate licenses, I mean I know they are required but just pain the ass :\ 08:19:16 <planetmaker> DigitalFox, no licenses basically means it applies what is listed in section2 of *that* copying file 08:19:38 <planetmaker> i.e.: you may do nothing. No copying, no distribution, no modification 08:20:24 <planetmaker> a license *always* means: "here, I give you more rights than you would have without this license" 08:22:09 <peter1138> "Before release 1.2.0 of OpenTTD, an official patch to OpenTTD named "Extra zoom" existed" 08:22:15 <peter1138> "official patch" 08:22:31 <peter1138> What makes a patch official? 08:24:23 <DigitalFox> Oh man I thought you guys were aware of that project, I didn't mean to "raise" questions about it. The sprites are really amazing, many but not all are finished ofcourse, nor are there so many like Zbase. 08:25:17 <planetmaker> it's one of those projects which try to 'rescue' the 32bpp sprites which existed before zoom sprites entered NewGRFs. That usually fails as people did not license their files 08:25:26 <planetmaker> Thus no-one may (re-)use them 08:25:37 <planetmaker> like that very project you linked obviously... 08:25:53 <DigitalFox> And why I refereed the licenses fiasco ;) 08:26:14 <DigitalFox> I jump in search of 32bpp sprites from coop to http://jupix.info/openttd/gfxdev-repo/index.php?act=browse 08:26:27 <planetmaker> thus I always say: make it gpl v2. That's like OpenTTD. And all will be fine, if everyone used it 08:26:45 <planetmaker> yeah. That path lies pain. License pain 08:27:09 <planetmaker> those sprites you found in the 32bpp-ez-project are taken from there, if not all, then at least in parts 08:29:46 <DigitalFox> But I think given most artists just abandon ship and never return or respond to contacts, that until notification most of the sprites publicly shared on TT Forums should be used, ofcourse if anyone complaints they should immediately removed and full credits given. Cause then "shit" like this happens... You amazing art, stuck in a repo that no ones use or most are even aware... 08:30:01 <DigitalFox> *You have 08:31:01 <DigitalFox> If they shared the art in public with the intention of being used by everyone then why not use it? 08:31:25 <V453000> because they did not state that intention in a license file 08:31:26 <V453000> simple 08:32:23 <DigitalFox> But V453000 I understand what you're saying, but doesn't it make little sense to share even the source on public and then no one can use it? 08:32:51 <peter1138> The consequences of being a dick about licensing your work... 08:33:12 <V453000> sadly it is a thing to easily forget about, especially back in those times when people did not care about licencing as a whole, but yes, this is the result 08:33:13 <blathijs> That's how copyright law works, though. 08:33:19 <peter1138> What's the timespan for public domain these days? 08:33:25 <V453000> 70yrs? 08:33:55 <blathijs> In the old days of US copyright you had to include "All rights reserved" to assert your copyright AFAIU, but that has since then be changed to be automatic (as it should be, I think) 08:34:03 <peter1138> Another problem with those sprites is generally it's just sprites, no source. Editing them to actually make it all work as a coherent set is going to be impossible. 08:34:24 <peter1138> Patchwork spritesets look terrible... 08:34:27 <V453000> + that 08:35:00 <peter1138> Big trick with 32bpp: you still need a palette. 08:35:09 <peter1138> Just, not in the 8bpp sense. 08:35:40 <V453000> myeah, or rendering with the same/similar materials and same light settings 08:36:09 <peter1138> Same thing really, your materials are your palette. 08:36:36 <V453000> not exactly but yeah :) 08:43:38 <planetmaker> 70 years past death of creator 08:43:43 <V453000> AHA 08:43:45 <V453000> :D 08:43:59 <V453000> so even if you kill them quickly you will still have to wait :P 08:44:29 <V453000> tleast you can spend the first XX years of waiting in jail 08:44:34 <V453000> good time killer 08:46:42 <planetmaker> well. In principle you can draw 32bpp just fine. 32bpp does not imply rendering :) 08:47:03 <peter1138> planetmaker, "or" ;) 08:47:24 <V453000> well sure :) 08:48:00 <peter1138> Line-art OpenTTD... 08:49:54 <peter1138> http://www.rabbleboy.com/wp-content/uploads/2014/02/Eboy-ville-pixel-art-Cologne.png 08:49:57 <peter1138> heh 08:50:22 <V453000> exactly the kind of pixel art I find wtf 08:51:32 <V453000> also am not sure if it is compatible with the size of x1 vehicles in openttd :P 08:51:43 <peter1138> :D 08:53:16 <peter1138> http://static.fjcdn.com/large/pictures/88/ea/88eaab_4469884.jpg 08:53:17 <peter1138> Ehhhh 08:54:07 <DigitalFox> For someone like me that didn't sleep, that previous image on my 27" screen just melted my eyes 08:54:17 <V453000> thats better :D 08:55:16 <planetmaker> https://plus.google.com/u/0/photos/113825442692250582467/albums/5848557196477543889?sqi=107993743924374455416&sqsi=54384611-2fe7-4cc2-b36a-6c41e923b5c4 08:56:17 <V453000> :) 08:56:34 <V453000> is that openttd sizes? 08:57:19 <planetmaker> sadly not directly 192px 08:57:25 <planetmaker> instead of 64/128/256 08:57:41 <DigitalFox> planetmaker: GRFid did the trick. Now I can go to bed dreaming with offsets :o 08:58:39 <planetmaker> V453000, but maybe I talk to him (again). He's the guy I got the sprites for the comic houses from. So... maybe :) 08:58:44 <planetmaker> More time needed, though .( 08:58:49 <V453000> : D 09:33:48 *** MJP [~mjp@hq.z77.fr] has joined #openttd 09:37:20 *** Yotson [~Yotson@2001:980:6ac8:1:c9e3:31c1:9fa6:48e6] has joined #openttd 09:45:20 <DigitalFox> Alright, thanks guys. bye! 09:45:39 *** DigitalFox [~DigitalFo@bl17-61-74.dsl.telepac.pt] has quit [Quit: ChatZilla 0.9.90.1 [Firefox 30.0/20140605174243]] 10:37:27 *** Kurimus [~stabbity@dsl-tkubrasgw2-54f816-197.dhcp.inet.fi] has quit [] 10:47:53 *** TheMask96 [martijn@pride.vhost.ne2000.nl] has quit [Ping timeout: 480 seconds] 10:51:06 *** Myhorta [~Myhorta@00018fad.user.oftc.net] has joined #openttd 10:52:22 *** TheMask96 [martijn@gluttony.vhost.ne2000.nl] has joined #openttd 11:21:30 <peter1138> Hmm, fail2ban can be handy... and can also be a pain in the bum... 11:22:12 <V453000> bum bum 11:23:33 *** tokai|mdlx [~tokai@port-92-195-24-230.dynamic.qsc.de] has joined #openttd 11:26:43 *** tokai [~tokai@00012860.user.oftc.net] has quit [Ping timeout: 480 seconds] 11:26:58 *** pthagnar [~pthagnar@cpc7-pres17-2-0-cust28.18-3.cable.virginm.net] has joined #openttd 11:31:06 *** Supercheese [~Superchee@76.178.136.186] has quit [Read error: Connection reset by peer] 11:31:37 *** Supercheese [~Superchee@76.178.136.186] has joined #openttd 11:36:17 *** xintron [~xintron@2a02:c200:0:10:2:1:5488:1] has joined #openttd 11:37:03 <xintron> I have a vague memory of it being possible to disable aircrafts on a server but can't seem to find it in the settings (wiki) or any information about it. Is it possible? 11:37:16 *** tokai|noir [~tokai@00012860.user.oftc.net] has joined #openttd 11:37:19 *** mode/#openttd [+v tokai|noir] by ChanServ 11:42:02 <Taede> set max_aircraft to 0 11:42:08 <Taede> using rcon 11:42:12 <Taede> set 11:43:13 *** tokai|mdlx [~tokai@port-92-195-24-230.dynamic.qsc.de] has quit [Ping timeout: 480 seconds] 11:46:46 <xintron> Ah, that's right yeah. 11:46:47 <xintron> Thanks! 11:51:54 *** KWKdesign [~KWKdesign@216.155.131.74] has quit [Read error: Connection reset by peer] 11:52:28 *** KWKdesign [~KWKdesign@216.155.131.74] has joined #openttd 11:53:15 *** yorick [~yorick@ip51cd0513.speed.planet.nl] has joined #openttd 12:03:05 *** KWKdesign [~KWKdesign@216.155.131.74] has quit [Read error: Connection reset by peer] 12:03:16 *** KWKdesign [~KWKdesign@216.155.131.74] has joined #openttd 13:23:48 *** Myhorta [~Myhorta@00018fad.user.oftc.net] has quit [Ping timeout: 480 seconds] 13:27:25 *** Myhorta [~Myhorta@00018fad.user.oftc.net] has joined #openttd 13:28:20 <xintron> Isn't there a config "generator" online as well somewhere? :) 13:30:29 <Taede> used to be, not sure if it still works 13:30:55 <xintron> Is the normal way to go about it to start a game locally, copy the config and then put it on the server? 13:31:23 <Taede> normal is subjective 13:31:43 <Taede> personally, i'd create a map (config newgrf et all), save, then transfer the savegame to the server 13:32:57 *** xT2 [~ST2@118.107.136.95.rev.vodafone.pt] has joined #openttd 13:33:44 <MTsPony> is there a known problem when running multiple (differerent) openttd.exe's in the same folder and all use the same datasets and config? 13:34:20 <xintron> Taede, hrmm.. couldn't find the "max_aircraft" in the advanced settings. Maybe that's only available to set directly in the config file (or rcon)? 13:37:00 <Taede> MTsPony, they'll all try to listen on the same port, so only the first will work 13:37:22 <Taede> the 2nd and after will refuse to run (assuming dedicated) telling the port is already in use afaik 13:37:47 <MTsPony> i ment client wise 13:37:53 <MTsPony> kinda 13:38:58 *** ST2 [~ST2@118.107.136.95.rev.vodafone.pt] has quit [Ping timeout: 480 seconds] 13:38:58 *** xT2 is now known as ST2 13:39:04 <Taede> xintron, adv settings -> vehicles shows it for me 13:39:18 <Taede> make sure you have 'all setting stypes' selected 13:40:01 <xintron> Taede, Oh, how did I manage to not see that? :S 13:40:04 <xintron> Thanks :) 13:43:22 <planetmaker> xintron, also the adv. settings have a search box :) 13:44:35 <planetmaker> MTsPony, they might try to create a savegame concurrently. Maybe even the same filename. Not sure whether that's an issue and if so how it would manifest 13:44:57 <MTsPony> kk thx 13:45:36 <MTsPony> another Q, what would cause it to crash if you turn on full,anmations? lol 13:46:05 <MTsPony> could that be sprite cache related? 13:46:20 <planetmaker> the crash.log would maybe tell you? 13:46:31 <planetmaker> you know, this is not a quiz channel 13:47:23 <planetmaker> where we guess how you possibly could create a crash under not fully described circumstances, software versions and settings 13:48:31 <planetmaker> if you have actual crash data, that's something way more interesting 13:49:03 <planetmaker> especially if you can describe a way so that anyone can reproduce it 13:50:03 *** HerzogDeXtEr [~flex@i59F6D352.versanet.de] has joined #openttd 13:50:59 <MTsPony> odd. it only does it when i use a specific openttd.cfg 13:51:10 <MTsPony> so i guess that knda solves the problem 13:51:30 <planetmaker> not really. Would be interesting to see what causes it to crash 13:51:49 <planetmaker> it's a workaround at best ;) 13:52:16 *** luaduck_zzz is now known as luaduck 13:53:48 <MTsPony> well 13:53:55 <MTsPony> what file do u,want to,check? 13:54:11 <MTsPony> sorrymabout the crappy typing im on a tabletn:p 13:54:55 <planetmaker> those which openttd tells you to communicate: crash* 13:55:30 <planetmaker> or do you use an iPad or android version? 13:55:52 <MTsPony> ipad, im connected to my desktop tho,with remote desktop 13:56:08 <MTsPony> were talking desktop version, r26335 to br exact 13:57:13 <MTsPony> im always getting these spritecache errors tho 13:57:29 <MTsPony> i tried increasing to 256 or 512 it still gives me the same :/ 13:57:49 <Diablo-D3> wait, openttd crashes? 13:57:50 <Diablo-D3> bullshit 14:02:14 <MTsPony> ok lets forget all what happenee here, fresh question, ane somethint which happens on all cersions of openttd. whats this 'out of memory' warning about, failed to allocate etc spritecache, reduced to xxx mb 14:02:46 <MTsPony> trying to increase it gives the same error. 14:02:52 <MTsPony> i got plenty of memory 14:03:09 <MTsPony> and im just usin 8bpp anim blitter 14:04:04 <planetmaker> lol. It's just that: too little memory 14:06:30 <MTsPony> really now. 14:06:40 <MTsPony> i have 4-5gb of free mem. 14:09:42 <Diablo-D3> heh 14:09:43 <Diablo-D3> I have 14:09:54 <Diablo-D3> about 29.5gb of free mem 14:10:33 <MTsPony> lol. 14:11:05 <MTsPony> either way it should not fail while trying to allocate 512mb or 1gb for spritecache 14:11:14 <Diablo-D3> 31030064 14:11:16 <Diablo-D3> bytes :D 14:12:05 <planetmaker> you realize that you err by a factor of 1000, Diablo-D3 ? 14:12:58 <Diablo-D3> er, maybe thats kb 14:13:14 <Diablo-D3> yeah free does kb 14:15:27 <Xaroth|Work> or just free -m for mb 14:17:58 <Diablo-D3> or -g apparently 14:18:04 <Diablo-D3> I dont remember those flags existing 14:18:08 <Diablo-D3> dear god how old am I =/ 14:21:39 <planetmaker> 13? 14:22:30 <Diablo-D3> old enough to remember when free didnt have fancy flags like that 14:25:15 *** Hazzard [~quassel@c-67-174-253-44.hsd1.ca.comcast.net] has joined #openttd 14:55:30 *** Myhorta [~Myhorta@00018fad.user.oftc.net] has quit [Ping timeout: 480 seconds] 15:27:46 *** chrswk [~chrswk@213.188.55.189] has quit [Read error: Connection reset by peer] 15:43:15 *** TheMask96 [martijn@gluttony.vhost.ne2000.nl] has quit [Ping timeout: 480 seconds] 15:43:45 <xintron> Why are graphics needed to run a dedicated server? 15:44:09 *** TheMask96 [martijn@wrath.vhost.ne2000.nl] has joined #openttd 15:44:24 <xintron> And can the server run one set and the clients whatever they please? 15:44:28 <planetmaker> xintron, the grfs contain more than graphics. e.g. some height map snippets for map creation 15:44:48 <planetmaker> and yes, doesn't matter who uses which base set 15:45:05 <xintron> Ok, that makes sense. Thanks! 15:47:17 *** KWKdesign [~KWKdesign@216.155.131.74] has quit [Read error: Operation timed out] 15:47:53 *** KWKdesign [~KWKdesign@216.155.131.74] has joined #openttd 15:47:57 *** Progman [~progman@p57A1B7A2.dip0.t-ipconnect.de] has joined #openttd 15:58:21 <Eddi|zuHause> man i raised my highscore from 150k to 170k, but still no 16384 :( 16:13:07 *** Kurimus [~stabbity@dsl-tkubrasgw2-54f816-197.dhcp.inet.fi] has joined #openttd 16:29:38 *** Stimrol [~Stimrol@46-239-219-51.tal.is] has quit [Ping timeout: 480 seconds] 16:30:34 *** Stimrol [~Stimrol@46-239-219-51.tal.is] has joined #openttd 16:59:48 *** efess [~Efess@c-24-61-64-170.hsd1.ct.comcast.net] has quit [Read error: Operation timed out] 17:09:05 *** Netsplit magnet.oftc.net <-> resistance.oftc.net quits: tparker, eQualizer, Extrems, Ttech, Eddi|zuHause, @Belugas, Xaroth, @orudge, Xaroth|Work, jonty-comp, (+34 more, use /NETSPLIT to show all of them) 17:10:41 *** Netsplit over, joins: Sacro, jonty-comp, lobster, @orudge, dyrim, Xaroth|Work, Vadtec, ccfreak2k, davidstrauss_, eQualizer (+34 more) 17:18:16 *** Alberth [~hat@2001:981:c6c5:1:be5f:f4ff:feac:e11] has joined #openttd 17:18:20 *** mode/#openttd [+o Alberth] by ChanServ 17:34:55 *** Myhorta [~Myhorta@00018fad.user.oftc.net] has joined #openttd 17:36:22 *** Wolf01 [~wolf01@0001288e.user.oftc.net] has joined #openttd 17:36:41 *** Midnightmyth [~quassel@93-167-84-102-static.dk.customer.tdc.net] has joined #openttd 17:36:50 <Wolf01> hello 17:37:28 <Eddi|zuHause> you destroyed the green! 17:37:36 <Wolf01> :( 17:37:54 <Alberth> luckily, eddi is green :) 17:38:08 <Eddi|zuHause> moderately :p 17:39:51 <planetmaker> alberth is greener than turquoise Eddi|zuHause ;) 17:40:09 <Alberth> oh :) 17:40:17 <Eddi|zuHause> Alberth is clearly red 17:40:18 <planetmaker> hi hi :) 17:40:38 * Alberth feels very green, does that count? 17:42:01 <planetmaker> http://devs.openttd.org/~planetmaker/patches/green.png ;) 17:42:14 <planetmaker> feeling green counts, too, yes 17:42:15 *** tycoondemon [~ashnohoe@ip503d7ac1.speed.planet.nl] has quit [] 17:43:37 <planetmaker> luckily and strangely enough, the colours are nicely persistent :) 17:44:18 *** frosch123 [~frosch@frnk-4d00d083.pool.mediaWays.net] has joined #openttd 17:44:40 <planetmaker> now yellow joined ;) quak :) 17:44:58 <Alberth> hai yellow :) 17:44:59 <frosch123> yellow? green! 17:45:08 <Alberth> blue here! 17:45:24 <frosch123> your clients are wrong 17:45:33 *** Haube [~michi@37-4-140-17-dynip.superkabel.de] has joined #openttd 17:45:35 <DorpsGek> Commit by translators :: r26681 /trunk/src/lang (gaelic.txt polish.txt) (2014-07-09 17:45:26 UTC) 17:45:35 <planetmaker> your colour perception is! ;) 17:45:36 <DorpsGek> -Update from WebTranslator v3.0: 17:45:37 <DorpsGek> polish - 48 changes by Kilian 17:45:38 <DorpsGek> gaelic - 4 changes by GunChleoc 17:46:06 <Alberth> tbh as long as everybody has a different colour, I am happy 17:46:26 <planetmaker> yeah :) 17:49:51 *** oskari89 [oskari89@83-102-63-32.bb.dnainternet.fi] has joined #openttd 17:50:21 <Alberth> oskari89 never says anything, no idea what his colour is 17:50:28 <planetmaker> where did you find juanjo's patches yesterday, frosch123 ? 17:52:03 <oskari89> Never says anything? :) 17:52:10 <frosch123> planetmaker: flyspray 17:52:11 <Rubidium> pff... it's all one shade of grey 17:52:26 <frosch123> opened 2 days ago 17:52:50 <planetmaker> oh. I thought elsewhere as there was no FS# 17:53:06 <planetmaker> missed it on FS 17:53:16 <frosch123> yeah, missed the fs :) 17:53:29 <frosch123> but there was nothing interesting in the task either, except the bare patches 17:53:31 <Alberth> hi oskari89 :) 17:53:38 *** MJP [~mjp@hq.z77.fr] has quit [Read error: Connection reset by peer] 17:53:50 <frosch123> but bugs the fs reference is important, so you get the test case in the future :) 17:53:59 <oskari89> hi Alberth :) 17:54:18 <planetmaker> yeah, no worries :) 17:54:40 <planetmaker> just curious whether you found a new secret patch source :) 17:54:58 <frosch123> shall i link you to some? :p 17:55:21 <planetmaker> :D 17:55:24 <Alberth> all those are definitely not the secret one :p 17:55:47 <frosch123> he, it's quite a secret what i bookmarked 17:56:52 *** andythenorth [~Andy@cpc10-aztw26-2-0-cust867.18-1.cable.virginm.net] has joined #openttd 17:59:17 <planetmaker> frosch123, that's what you want to believe 17:59:31 <andythenorth> o/ 17:59:36 <andythenorth> whatever you believe, snopes it 17:59:38 <andythenorth> just in case 17:59:42 <planetmaker> Shall I ask the National Storage Association for the backup? 18:00:16 *** MJP [~mjp@hq.z77.fr] has joined #openttd 18:00:32 <planetmaker> \o 18:04:13 *** DigitalFox [~DigitalFo@bl17-61-74.dsl.telepac.pt] has joined #openttd 18:04:33 <DigitalFox> Hi :) 18:04:42 <andythenorth> are we making anything? 18:05:25 <andythenorth> oops http://www.railpictures.net/viewphoto.php?id=488739&nseq=1 18:05:31 <Alberth> conversation at least, and probably tea 18:06:37 <andythenorth> consists? 18:06:38 <andythenorth> faster nml? 18:06:42 <andythenorth> Squid? 18:06:43 <Alberth> it looks like a few toy trains, so small, compared to the mountain 18:06:45 <andythenorth> a new GS? 18:07:15 * Alberth takes #2 18:07:33 <Alberth> but it's not going anywhere fast I suspect 18:07:39 <andythenorth> wondered about that 18:08:09 <andythenorth> Iâm not very +1 to continuing my hacky speed up approach 18:08:13 <andythenorth> more -1 18:08:19 <andythenorth> as it requires a patched nml 18:08:32 <andythenorth> but it did look promising 18:08:38 <Alberth> we have one forked nml, you can add another one :p 18:09:59 <Alberth> I started a conversation last sunday morning in #openttdcoop.devzone, but that didn't end in anything useful either 18:10:22 <andythenorth> no logs there :) 18:10:23 <Alberth> other than V getting happy about his yetis :) 18:11:17 <Alberth> andythenorth: oh??? look what I found then! http://webster.openttdcoop.org/index.php?channel=openttdcoop.devzone&date=1404604800 18:11:26 <andythenorth> :o 18:12:00 <andythenorth> oh deep clones :) 18:12:01 <andythenorth> I see 18:14:08 <andythenorth> did you get anywhere with faster parser? 18:16:01 <Alberth> I wrote a faster scanner, and scanning is now reduced to 8 seconds with FIRS 18:16:09 <andythenorth> previously was? 18:16:14 <Alberth> parsing takes 16 seconds 18:16:20 <Alberth> scanning was 30 iirc 18:16:45 <Alberth> it does 1.6E06 python calls in that 8 seconds 18:17:11 <Alberth> total execution time is 1:17 iirc 18:17:18 <andythenorth> I wonder how acceptable my crazy âextend global constantsâ patch is? 18:17:49 <Alberth> thus, if you manage to completely drop scanning and parsing, you'll end up just below the 1:00 18:18:11 <andythenorth> if I also only compile changed files... 18:18:33 *** Mrucux7 [~oftc-webi@adcz50.neoplus.adsl.tpnet.pl] has joined #openttd 18:18:34 <andythenorth> there are 62 industries... 18:18:37 <Alberth> then any scanning and parsing is fine, I think 18:19:02 <andythenorth> Iâd rather solve the tractable problem than wait for the perfect solution 18:19:10 <andythenorth> but I donât know if my approach sucks :) 18:19:33 <andythenorth> compiling 1 industry not 62 suggests up to 62x improvement - overhead of setup 18:20:22 <Alberth> yep, which means a few seconds 18:20:31 <Alberth> rather than just < 1:00 18:21:07 <andythenorth> so I have been manually pushing constants into json, and then extending global_constants 18:21:13 <andythenorth> which seems wrong but works 18:21:15 <Alberth> only minor issue is the total lack of underlying tools and file format 18:21:55 <Alberth> not to mention that nml is not designed for partial translation 18:22:12 <andythenorth> I am treating translation separately 18:22:22 <andythenorth> admittedly it is 100% unsolved :P 18:24:53 <DigitalFox> So I'm changing the faces sprites to 32bpp (not all are yet changed). Here's what I'm getting now: http://s28.postimg.org/lx1ng7ial/Faces_Wrong.png and here's how it should look like: http://s10.postimg.org/e28aqfl09/Faces_Right.png 18:24:55 <DigitalFox> My code: 18:24:57 <DigitalFox> base_graphics spr805( 805, "sprites/gui/small_gui.png") { [ 354, 1000, 92, 119, 0, 0] } 18:24:58 <DigitalFox> alternative_sprites(spr805, ZOOM_LEVEL_NORMAL, BIT_DEPTH_32BPP, "sprites/gui/faces/805_z1.png") { [0, 0, 134, 125, 0, 0] } 18:25:00 <DigitalFox> 134, 125 is the real dimension of the png. Original PNG: http://s28.postimg.org/rfhok3dcp/805_z1.png 18:25:01 <DigitalFox> So where am I messing this up? It's huge :o 18:27:57 <frosch123> ZOOM_LEVEL_NORMAL? 18:30:09 <frosch123> i have no idea what weird zoom level your original sprite is 18:30:51 <planetmaker> Alberth, you mean the conversation which essence (in my words) was that the expression parser written in C/C++ probably would speed up things but is nearly as much work as a complete re-write? 18:31:52 <Alberth> s/expression parser/expression handling rewriting/ probably, but close enough :) 18:31:55 <andythenorth> it also reduces the pool of maintainers imo 18:31:59 <andythenorth> maybe not 18:32:05 <planetmaker> sorry, you're right, yes 18:32:25 *** Mrucux7 [~oftc-webi@adcz50.neoplus.adsl.tpnet.pl] has quit [Quit: Page closed] 18:33:39 <planetmaker> I was not sure what conclusion to draw. I only see two alternatives, both not exactly satisfactorily: 18:34:10 <planetmaker> a) keep it in principle like it is. Maybe work towards some better modularized code in that respect. But that won't give us any speed gain 18:34:21 <planetmaker> b) basically rewrite NML in C. Oh well... 18:35:13 <Alberth> c) rewrite nml in python is also an option, but arguably not better than b) 18:35:37 <andythenorth> same work, slower? 18:35:37 <Alberth> although it's finished much sooner probably :) 18:35:53 <Alberth> you can write Python more quickly 18:36:05 <andythenorth> whatever the implementation, partial compiles will always be faster? Do we think? 18:36:20 <Rubidium> what part of NML is the real bottleneck? 18:36:33 <Rubidium> is it the parsing/making the AST, or is it something else? 18:37:05 *** jinks [~jinks@172.245.35.67] has quit [Quit: ZNC - http://znc.in] 18:37:06 <Alberth> Rubidium: expression tree reduction, it seems; if you ignore parsing 18:38:00 <Alberth> (scanner in C 8 seconds, parsing in Python 16 seconds, expression.reduce lots of small calls in the order of 1.5-2 seconds 18:38:03 *** jinks [~jinks@172.245.35.67] has joined #openttd 18:38:19 <Alberth> total 1:10-1:15 or so 18:38:38 <Alberth> and a HUGE amount of memory used 18:39:01 <Alberth> which is perhaps the deep-copying of the expressions while reducing them 18:39:06 <planetmaker> Alberth, would it get better maybe, if the deep cloning would be replaced by references? 18:39:13 <planetmaker> s/cloning/copying/ 18:39:39 <Alberth> planetmaker: it would probably, as you also reduce garbage collection stuff 18:39:54 <Rubidium> so try that approach ;) 18:39:59 <planetmaker> hm :) 18:39:59 <Alberth> however, you must be sure the shared objects are not modified 18:40:10 <planetmaker> which is the tricky bit here 18:40:34 <Rubidium> why can't shared objects be reduced? 18:40:39 <Alberth> to establish that with 100% certainty, it is 18:40:57 <Rubidium> shouldn't reducing yield the same? 18:41:17 <Alberth> Rubidium: you can, but you should not do in-place modifications in them, or you crate havoc with the other uses 18:41:42 <Alberth> which is not easy to establish whether or not that happens in the code 18:42:03 <Alberth> as far as I know, at least 18:42:13 <Rubidium> also, why so many calls to reduce. Isn't it needed just once? 18:42:54 <Alberth> it's a recursive method, over all nodes in the expressions 18:43:07 <Alberth> as most of nml is expressions, that a lot of calls 18:43:37 <Alberth> also, the compiler constructs rewrites as expressions, and reduces those 18:45:03 <Alberth> https://dev.openttdcoop.org/projects/nml/repository/entry/nml/actions/action0properties.py#L236 for example 18:45:10 *** Chrill [Chrill@c83-255-31-85.bredband.comhem.se] has joined #openttd 18:46:23 <Alberth> ie it uses expression as basic notion instead of "number" 18:46:24 <Rubidium> can't you cache everything that has been reduced? An then prevent a second attempt? 18:47:00 <Alberth> while the code may make in-place modifications? 18:47:51 <Rubidium> don't know... I'm just throwing stupid ideas in the air. Maybe one sticks 18:48:12 <Rubidium> the .reduce() does return some expression, right? 18:48:49 <Alberth> it makes deep copies. Either because there is a reason like in-place modification, or because deep-copying seemed like a good idea at the time, I don't know which one 18:49:03 <Alberth> .reduce returns an expression indeed 18:49:35 <Alberth> which is eventually translated to a sequence of actions 18:50:05 <Rubidium> then you don't need to do the reduce in the cargolist function, if... and only if you just run reduce once at the end of everything. At that moment you'd just create one clone/deep copy of the initial AST 18:50:48 <Alberth> you do need to do it; it reduces to see what case it has, and how to rewrite 18:51:54 <Rubidium> so then it is to be considered "constant", and it should *never* be reduced again. In that case you could simply mark the expression instance as such and just return 'this' for reduce 18:51:55 <Alberth> but tbh I don't have a clue what it is computing. I can read the Python code and see what it does, but I have no clue why 18:52:16 *** Supercheese [~Superchee@76.178.136.186] has quit [Quit: Valete omnes] 18:52:30 <Alberth> ConstantNumeric does exactly that 18:52:31 *** Pereba [~UserNick@179.180.222.76] has joined #openttd 18:52:57 <frosch123> what does it need to change the deep-copy into a shallow-copy? 18:53:08 <frosch123> is it something one can try to see what breaks? 18:53:26 <frosch123> is it 10 lines or 1000 lines? :p 18:54:13 <Alberth> hard to say, you'd need to check every if case, and see whether a new value is created or whether the old value is kept 18:54:38 <Rubidium> hmm... deep copy of an expression. Does that mean that the complete subtree is cloned? 18:54:41 <Alberth> so it may be a few lines in the end, but you need to check every "new" call 18:55:05 <Alberth> Rubidium: yes, recursively, bottom up 18:55:54 *** efess [~Efess@c-24-61-64-170.hsd1.ct.comcast.net] has joined #openttd 18:55:55 <Alberth> https://dev.openttdcoop.org/projects/nml/repository/entry/nml/expression/binop.py#L72 <-- at every binary operator: first step, reduce the childs 18:56:19 <Rubidium> so that's quite O(2^n)-ish; it doubles in amount of work for every extra level in the AST 18:56:47 <Alberth> very much so 18:57:25 <Alberth> the walk in itself is not that bad, if you would not actually create a new node on the way back 18:58:13 <Alberth> although if you examine a node, do a rewrite by adding a few nodes, and call .reduce again... :) 18:58:30 <Alberth> heaps and heaps of time that you can save there :p 18:58:54 <Rubidium> is the AST really a tree, or is it rather a DAG (I hope there's no recursion allowed) 18:59:27 <Rubidium> i.e. is a helper function cloned or referenced? 19:00:19 <Alberth> don't know the answer to that 19:00:44 <Rubidium> if it is referenced, then I can imagine using deep copies. Otherwise (in the pure AST case) those deep copies are just pointless 19:01:02 <Alberth> parser doesn't hand out the same object twice, as the position is different each time 19:02:31 <Alberth> indeed, the question is thus how to decide what case we have 19:03:11 <Alberth> it's not simple to find all write operations to a class 19:03:38 <Alberth> at many points, it's not even clear what object types are possible there 19:03:50 <Rubidium> https://dev.openttdcoop.org/projects/nml/repository/entry/nml/expression/functioncall.py#L384 <- what?!? 19:04:10 <Alberth> :D 19:04:24 <planetmaker> :) 19:04:33 <planetmaker> snowlinemod 19:04:33 <Alberth> wanted a sinus snowline curve, anyone? :D 19:04:43 * planetmaker whistles 19:04:48 *** Myhorta [~Myhorta@00018fad.user.oftc.net] has quit [Ping timeout: 480 seconds] 19:04:58 <Alberth> oh, I guessed right, apparently :) 19:05:34 <Alberth> I can also imagine uses for that in the multi-angle sprites of eddi 19:08:02 <Alberth> but from a compiler point of view, it's a harmless constant 19:09:11 <Rubidium> yeah 19:09:16 <Rubidium> it just amazed me though 19:10:36 <Rubidium> but... then I have a suggestion for NML, especially needed by V453000: random(<min>,<max>). For a compiler point of view it is just a harmless constant, but you can make NUTS really nuts 19:10:58 <planetmaker> :P 19:11:01 <Rubidium> my English is crap today 19:11:04 <frosch123> compile time randomness? :p 19:12:20 <planetmaker> here's the compile-time random const number: 42 19:13:24 <Rubidium> planetmaker: rather 4 -> http://xkcd.com/221/ 19:13:35 <frosch123> hmm, rb was faster 19:13:48 <planetmaker> or that :) 19:14:12 <Alberth> part of the problem is perhaps also the cpp pre-processing 19:14:29 <planetmaker> in what way, Alberth ? 19:14:40 <planetmaker> that it adds several types of comment lines? 19:14:41 <Alberth> you cannot do calculations in cpp, so expressions get expanded fully, and thrown into nml 19:15:01 <Alberth> at every point where the value is needed 19:15:22 <planetmaker> ok, but... how is that a cpp preprocessing problem? You mean, cpp should just place it there as constant? 19:15:36 <Alberth> so nml has to perform the same reduction many times 19:15:41 <planetmaker> had I no cpp or other pre-processor I'd also write it such. Just preceeding it by like 19:15:48 <planetmaker> global_var1 = 4 19:15:55 <planetmaker> global_var2 = 1950 19:15:56 <frosch123> where does firs copy those constants? 19:16:21 <frosch123> where does it have constant expressions in macros? 19:16:39 <frosch123> (non-trivial expressions, that is) 19:18:25 <andythenorth> hmm Alberth where are those in FIRS? 19:18:30 *** Chrill [Chrill@c83-255-31-85.bredband.comhem.se] has left #openttd [] 19:19:06 <Alberth> it's all expressions or part of expressions, that you see twice or more often 19:19:46 <Alberth> if you'd write that manually, you would do the computation one time, and re-use the stored result 19:20:09 <Alberth> tbh I don't know if nml does such reductions 19:20:22 <planetmaker> hide_sprite: (climate != CLIMATE_TROPIC) || ((climate == CLIMATE_TROPIC) && (nearby_tile_terrain_type(0, 0) == TILETYPE_DESERT)) || ((climate == CLIMATE_TROPIC) && (nearby_tile_terrain_type(0, 0) == TILETYPE_NORMAL) && ((nearby_tile_terrain_type( 1, 0) != TILETYPE_DESERT) && (nearby_tile_terrain_type(-1, 0) != TILETYPE_DESERT) && (nearby_tile_terrain_type( 0, 1) != TILETYPE_DESERT) && (nearby_tile_terrain_type( 0,-1) != T 19:20:22 <planetmaker> ILETYPE_DESERT) ) ); 19:20:47 <andythenorth> thatâs one of the more simple ones :P 19:20:47 <planetmaker> that's mostly inserted by a cpp macro, I recon. Coming from a template with a few parameters 19:21:00 <Alberth> at the very least it parses and reduces the same expressions over and over again 19:21:09 <andythenorth> and over and over 19:21:22 <Alberth> if you want to eliminate double calculations, that's more work 19:21:35 <andythenorth> doesnât nfo have some way to share varaction 2? 19:21:43 * andythenorth ponders 19:22:01 <frosch123> there is nothing in that expresion, that could be evaluated with a preprocessor 19:22:16 <Alberth> maybe nml is wrong? 19:22:37 <andythenorth> http://newgrf-specs.tt-wiki.net/wiki/VarAction2Advanced procedures.... 19:22:43 <Alberth> I don't know enough of the target language to see other solutions 19:22:47 <planetmaker> ah... the nml I look at is already the output of gcc. So... 19:22:54 <andythenorth> all the terrain crap could be one procedure, instead of repeated in every spritelayout... 19:23:16 <frosch123> i thought you meant stuff like "2 * 3 + 5" 19:23:30 <frosch123> but in above example, there are variables in every node 19:23:37 <Alberth> that too, but it doesn't happen much, probably :) 19:23:42 <frosch123> so, nothing that can be evaluated at compile time 19:24:34 <Alberth> if you throw that into nml enough times, it will also be slow, but it takes more work :) 19:24:44 <planetmaker> switch (FEAT_INDUSTRIES, SELF, THIS_ID(check_availability), current_date) { 19:24:44 <planetmaker> date(THIS_MIN_YEAR,1,1) .. date(THIS_MAX_YEAR,12,31): THIS_ID(available_game_mode); 19:24:44 <planetmaker> return CB_RESULT_IND_NO_CONSTRUCTION; 19:24:44 <planetmaker> } 19:25:55 <Alberth> you wouldn't want to build anything before the start of the world nor after it! :D 19:26:00 *** Brumi [~quassel@78-131-41-191.pool.digikabel.hu] has joined #openttd 19:26:06 <planetmaker> yep :P 19:26:38 <planetmaker> the constant defined indeed make that check *slightly* pointless 19:26:40 <Alberth> I do wonder why the name of the switch etc is in the parameter list instead of in front of it 19:27:08 <Alberth> ie THIS_ID(check_availability) = switch ( ...) 19:27:35 <Alberth> this is mostly just wasting openttd time rather than nml time 19:27:44 <andythenorth> all of that CPP could be fixed by me (convert to python templates) 19:27:44 <planetmaker> hm? 19:27:58 <andythenorth> Iâve been leaving it alone, on the basis âit ainât broke" 19:28:39 <Alberth> technically it ain't, it just a big 13MB pile of stuff to work through 19:28:50 <andythenorth> changing things = new bugs 19:28:58 <andythenorth> especially on a slow compile :P 19:29:17 <planetmaker> the check for availability between 0 and 5000000 also shows there might be cases with bit rot ;) 19:29:19 <Alberth> and whether this is caused by bad use of cpp or nml lacking some feature, I don't know 19:30:00 <andythenorth> it is a blunt use of CPP imo 19:30:09 <Alberth> planetmaker: such things happen when you introduce a concept like availability over time 19:30:22 <Alberth> you get new edge cases where the check is not useful 19:30:42 <planetmaker> of course, I know :) 19:30:59 <Alberth> and you never find them unless you read the generated code :) 19:31:13 <planetmaker> hard to avoid, if you want to spare time programming and not special-case everything 19:31:36 <Alberth> yep 19:31:43 <andythenorth> it was a mass conversion from nfo too 19:32:03 <andythenorth> historical raisins 19:32:25 <planetmaker> oh, there's nothing left of that origin, I think 19:32:39 <Alberth> I am not sure whether this is a cause for the slow compile, it looks like duplicate work, but no idea if it really is, or whether you can even avoid it 19:32:51 <planetmaker> it really has been re-written completely in NML. And now partily in pynml :) 19:34:43 <Alberth> obviously, if you can cache reductions, you can detect such duplicates too 19:35:01 <planetmaker> more memory usage :) 19:35:37 <Alberth> if you make every expression and sub-expression unique, yes 19:36:18 *** Yotson [~Yotson@2001:980:6ac8:1:c9e3:31c1:9fa6:48e6] has quit [Quit: .] 19:36:21 <Alberth> I don't believe you manage that in a real newgrf :) 19:38:23 <Alberth> every sprite at a different position :p 19:39:40 *** DigitalFox [~DigitalFo@bl17-61-74.dsl.telepac.pt] has left #openttd [] 19:40:15 <planetmaker> hm :) 19:40:25 <planetmaker> I don't want to try for any non-trivial NewGRF 19:41:26 <Alberth> it would be very unique, every engine its own stats + rules :p 19:43:18 *** KWKdesign [~KWKdesign@216.155.131.74] has quit [Read error: Operation timed out] 19:43:54 *** KWKdesign [~KWKdesign@108.61.152.243] has joined #openttd 19:44:41 <Alberth> so in practice, it'll work out, what you gain on less expression duplicates against more cache + detection data 19:52:04 <andythenorth> so for string IDs 19:52:21 <andythenorth> - look in a cache file for the string ID, if not present, assign new random ID 19:52:25 <andythenorth> - cache ID in cache file 19:52:41 <andythenorth> - on exit of compile, garbage collect any dead strings (check the output) 19:52:42 <andythenorth> ?? 19:53:14 *** glx [~glx@000128ec.user.oftc.net] has joined #openttd 19:53:17 *** mode/#openttd [+v glx] by ChanServ 20:01:31 *** Myhorta [~Myhorta@00018fad.user.oftc.net] has joined #openttd 20:01:53 <Alberth> just give every string a number? you know what strings you have don't you? 20:03:00 <andythenorth> I do yes 20:03:06 <andythenorth> so I can see two routes 20:03:26 <andythenorth> have nmlc cache known strings for a grf (similar to the sprite cache we already have) 20:03:32 <andythenorth> or I can pass in string IDs manually 20:03:38 <andythenorth> either seems fine 20:08:50 <Rubidium> how would you handle strings being removed (not sure how it currently handles sprites are not used anymore) 20:09:33 <andythenorth> walk the output somehow, look for dead strings in the cache (not used in the output) 20:09:44 <andythenorth> (the linked output) 20:09:47 <andythenorth> seems clunky 20:10:08 <andythenorth> or just wait until we run out of IDs, then explode 20:10:16 <andythenorth> let the user delete the cache file :P 20:12:25 <frosch123> make the id a checksum of the string, and hope that no two match :p 20:15:25 <andythenorth> ha 20:15:30 <andythenorth> "what could go wrong?â 20:16:14 <andythenorth> currently IDs are random 20:16:20 <andythenorth> I donât see much harm in caching them 20:17:42 *** tycoondemon [~ashnohoe@ip503d7ac1.speed.planet.nl] has joined #openttd 20:20:16 * andythenorth -> bed 20:20:19 <andythenorth> bye 20:20:37 *** Aristide [~quassel@tok69-5-82-235-150-75.fbx.proxad.net] has joined #openttd 20:21:00 *** andythenorth [~Andy@cpc10-aztw26-2-0-cust867.18-1.cable.virginm.net] has quit [Quit: andythenorth] 20:44:59 *** Progman [~progman@p57A1B7A2.dip0.t-ipconnect.de] has quit [Remote host closed the connection] 21:05:46 *** Alberth [~hat@2001:981:c6c5:1:be5f:f4ff:feac:e11] has left #openttd [] 21:13:33 <Rubidium> got to love dumping a huge load of numbers into discussions about things "rarely" happening in real life 21:17:12 <frosch123> so, you are visiting rome? 21:17:56 <Rubidium> nope... been there... twice ;) 21:21:07 <frosch123> i assume not for that route though :p 21:23:14 <Rubidium> I once kinda considered taking the Moscow route from Berlin to Amsterdam 21:23:31 <Rubidium> but the layover was way way too long 21:30:27 *** tokai|mdlx [~tokai@port-92-195-0-5.dynamic.qsc.de] has joined #openttd 21:34:50 *** tokai|noir [~tokai@00012860.user.oftc.net] has quit [Ping timeout: 480 seconds] 21:42:05 <frosch123> night 21:42:08 *** frosch123 [~frosch@frnk-4d00d083.pool.mediaWays.net] has quit [Quit: be yourself, except: if you have the opportunity to be a unicorn, then be a unicorn] 21:44:40 *** silenz [~silenz@h88-206-139-26.vokby.se] has joined #openttd 21:44:50 *** silenz [~silenz@h88-206-139-26.vokby.se] has left #openttd [] 21:58:13 *** Aristide [~quassel@tok69-5-82-235-150-75.fbx.proxad.net] has quit [Remote host closed the connection] 22:10:03 *** Haube [~michi@37-4-140-17-dynip.superkabel.de] has quit [Ping timeout: 480 seconds] 22:22:54 *** oskari89 [oskari89@83-102-63-32.bb.dnainternet.fi] has quit [] 22:27:34 <Wolf01> 'night 22:27:37 *** Wolf01 [~wolf01@0001288e.user.oftc.net] has quit [Quit: Once again the world is quick to bury me.] 22:33:38 *** Brumi [~quassel@78-131-41-191.pool.digikabel.hu] has quit [] 22:38:57 *** Pereba [~UserNick@179.180.222.76] has quit [Quit: AdiIRC is updating to v1.9.3 Beta Build (2014/07/08) 64 Bit] 22:39:16 *** Pereba [~UserNick@179.180.222.76] has joined #openttd 22:47:34 *** Myhorta [~Myhorta@00018fad.user.oftc.net] has quit [Remote host closed the connection] 22:49:20 *** Midnightmyth [~quassel@93-167-84-102-static.dk.customer.tdc.net] has quit [Ping timeout: 480 seconds] 23:19:38 *** MTsPony [~marctraid@008-086-128-083.dynamic.caiway.nl] has quit [] 23:21:09 *** HerzogDeXtEr [~flex@i59F6D352.versanet.de] has quit [Quit: Leaving.] 23:54:01 *** Supercheese [~Superchee@76.178.136.186] has joined #openttd 23:59:46 *** yorick [~yorick@ip51cd0513.speed.planet.nl] has quit [Remote host closed the connection]