Times are UTC Toggle Colours
00:01:24 <MTsPony> Question, is there some file that dictates pathing for scripts? as soon as i copy my server to another folder in linux i get script errors 00:01:27 <MTsPony> bg: [script] dutch:121: warning: String name 'STR_CITYBUILDER_SS_TOWN2_NAME??' does not exist in master file 00:01:33 <MTsPony> script seems to work fine otherwise 00:24:45 <Eddi|zuHause> mixing / vs. \ maybe? 00:28:29 <NGC3982> \o/ 00:42:47 *** KritiK [~Maxim@0001264a.user.oftc.net] has quit [Quit: Leaving] 00:48:15 *** Hazzard [~quassel@c-67-174-253-44.hsd1.ca.comcast.net] has joined #openttd 00:55:32 <MTsPony> um. 00:56:10 <MTsPony> im not transitioning to windows :p 00:56:34 <MTsPony> is there anything indexed somewhere? like libs, scripts etc? 00:56:50 <MTsPony> or does the game just bluntly read all folders to see what exists? 00:57:05 <MTsPony> like grfs are indexed in openttd.cfg 01:01:10 <Eddi|zuHause> there is no index. on game startup, a number of folders (described in the readme) is scanned, most notably the current working directory and the ~/.openttd directory, and all script/grf/whatever files are detected 01:02:41 <Eddi|zuHause> what's in the openttd.cfg is not which grfs you have, but which ones should be activated in a new game 01:03:31 *** Flygon_ [~Flygon@147.18.214.218.sta.commander.net.au] has joined #openttd 01:03:47 <MTsPony> kk 01:09:57 *** Flygon [~Flygon@147.18.214.218.sta.commander.net.au] has quit [Ping timeout: 480 seconds] 01:26:32 *** pthagnar [~pthagnar@cpc7-pres17-2-0-cust28.18-3.cable.virginm.net] has quit [Quit: Leaving] 01:27:27 *** MJP [~mjp@hq.z77.fr] has quit [Ping timeout: 480 seconds] 01:28:03 *** SylvieLorxu [~sylvie@dhcp-077-251-165-191.chello.nl] has quit [Remote host closed the connection] 01:31:15 *** DDR [~kvirc@S010600254bbe4e1c.vc.shawcable.net] has joined #openttd 01:31:23 *** glx [~glx@000128ec.user.oftc.net] has quit [Quit: Bye] 02:09:01 *** strohi [~smoofi@cpe-10feedc22125.ip-pool.rftonline.net] has joined #openttd 02:09:48 *** strohalm [~smoofi@cpe-10feedc22125.ip-pool.rftonline.net] has quit [Read error: Connection reset by peer] 02:10:14 *** HerzogDeXtEr [~flex@88.130.168.148] has joined #openttd 02:38:03 *** tokai|noir [~tokai@00012860.user.oftc.net] has joined #openttd 02:38:06 *** mode/#openttd [+v tokai|noir] by ChanServ 02:42:40 *** tokai|mdlx [~tokai@port-92-195-29-131.dynamic.qsc.de] has quit [Read error: Operation timed out] 02:48:44 *** DDR [~kvirc@S010600254bbe4e1c.vc.shawcable.net] has quit [Read error: Connection reset by peer] 02:49:06 *** DDR [~kvirc@S010600254bbe4e1c.vc.shawcable.net] has joined #openttd 03:00:47 *** KWKdesign [~KWKdesign@pool-108-52-130-213.phlapa.fios.verizon.net] has quit [Ping timeout: 480 seconds] 03:01:16 *** KWKdesign [~KWKdesign@pool-108-52-130-213.phlapa.fios.verizon.net] has joined #openttd 04:02:54 *** retakker [~kater@port-92-193-7-91.dynamic.qsc.de] has joined #openttd 04:09:52 *** retakk [~kater@port-92-205-58-17.dynamic.qsc.de] has quit [Ping timeout: 480 seconds] 04:41:55 *** smb_ [~smb_@199.119.245.122] has quit [Read error: Connection reset by peer] 04:43:01 *** trendynick [~trendynic@188.26.254.160] has joined #openttd 04:56:01 *** Eddi|zuHause [~johekr@p5DC67F2A.dip0.t-ipconnect.de] has quit [] 04:56:16 *** Eddi|zuHause [~johekr@p57BD4F02.dip0.t-ipconnect.de] has joined #openttd 05:35:11 *** Smedles_ [~quassel@58.160.136.199] has joined #openttd 05:35:26 *** Smedles [~quassel@58.160.136.199] has quit [Read error: Connection reset by peer] 05:43:27 *** sla_ro|master [slamaster@89.137.74.191] has joined #openttd 05:45:58 *** Smedles [~quassel@58.160.136.199] has joined #openttd 05:48:07 *** Smedles_ [~quassel@58.160.136.199] has quit [Read error: Connection reset by peer] 06:04:17 *** DDR [~kvirc@S010600254bbe4e1c.vc.shawcable.net] has quit [Read error: Connection reset by peer] 06:08:23 *** Smedles [~quassel@58.160.136.199] has quit [Ping timeout: 480 seconds] 06:11:22 *** Smedles [~quassel@58.160.136.199] has joined #openttd 06:21:17 *** HerzogDeXtEr1 [~flex@88.130.162.197] has joined #openttd 06:24:57 *** Smedles [~quassel@58.160.136.199] has quit [Read error: Connection reset by peer] 06:28:03 *** HerzogDeXtEr [~flex@88.130.168.148] has quit [Ping timeout: 480 seconds] 06:34:58 *** Smedles [~quassel@58.160.136.199] has joined #openttd 06:43:58 *** Smedles [~quassel@58.160.136.199] has quit [Ping timeout: 480 seconds] 06:50:16 *** Yotson [~Yotson@2001:980:6ac8:1:5451:9a74:b196:815f] has joined #openttd 06:56:02 *** trendynick [~trendynic@188.26.254.160] has quit [Ping timeout: 480 seconds] 07:00:46 *** Smedles [~quassel@58.160.136.199] has joined #openttd 07:14:19 *** Yotson [~Yotson@2001:980:6ac8:1:5451:9a74:b196:815f] has quit [Quit: .] 07:24:37 *** pthagnar [~pthagnar@cpc7-pres17-2-0-cust28.18-3.cable.virginm.net] has joined #openttd 08:03:22 <V453000> I figured out the yeti animation-only rendering :) for a simple test case at least 08:08:23 *** Yotson [~Yotson@2001:980:6ac8:1:5451:9a74:b196:815f] has joined #openttd 08:09:15 *** kero [~keikoz@pha75-1-81-57-54-15.fbx.proxad.net] has joined #openttd 08:10:46 *** trendynick [~trendynic@188.26.254.160] has joined #openttd 08:12:06 *** HerzogDeXtEr1 [~flex@88.130.162.197] has quit [Quit: Leaving.] 08:24:07 *** kero [~keikoz@pha75-1-81-57-54-15.fbx.proxad.net] has quit [Ping timeout: 480 seconds] 08:26:02 *** luaduck_zzz [~luaduck@0001c465.user.oftc.net] has quit [Ping timeout: 480 seconds] 08:29:05 *** kero [~keikoz@pha75-1-81-57-54-15.fbx.proxad.net] has joined #openttd 08:33:12 *** Pereba [~UserNick@187.58.115.135] has quit [Quit: (-(-_(-_-)_-)-) ninjas inside. [www.adiirc.com]] 08:33:37 *** luaduck_zzz [~luaduck@0001c465.user.oftc.net] has joined #openttd 08:34:04 *** luaduck_zzz is now known as luaduck 08:37:19 *** retakker [~kater@port-92-193-7-91.dynamic.qsc.de] has quit [Quit: Leaving] 08:44:40 *** trendynick [~trendynic@188.26.254.160] has quit [Remote host closed the connection] 08:47:49 *** kero [~keikoz@pha75-1-81-57-54-15.fbx.proxad.net] has quit [Quit: kero] 08:55:18 *** MJP [~mjp@hq.z77.fr] has joined #openttd 09:21:15 *** sla_ro|master [slamaster@89.137.74.191] has quit [] 09:23:54 *** Tuhin [~Tuhin@fip31c146.banglalionwimax.com] has joined #openttd 10:04:12 *** shirish_ [~quassel@117.222.6.19] has joined #openttd 10:11:32 *** shirish [~quassel@0001358e.user.oftc.net] has quit [Ping timeout: 480 seconds] 10:15:57 *** KenjiE20 [kenjie20@46.246.119.109] has quit [Remote host closed the connection] 10:26:48 *** LSky` [LSky@5ED4B2EA.cm-7-5c.dynamic.ziggo.nl] has joined #openttd 10:34:33 *** kero [~keikoz@pha75-1-81-57-54-15.fbx.proxad.net] has joined #openttd 10:49:38 *** kero [~keikoz@pha75-1-81-57-54-15.fbx.proxad.net] has quit [Ping timeout: 480 seconds] 10:57:17 *** Brumi [~quassel@78-131-41-191.pool.digikabel.hu] has joined #openttd 10:58:18 *** kero [~keikoz@pha75-1-81-57-54-15.fbx.proxad.net] has joined #openttd 10:58:31 <LSky`> isnt this supposed to be in the scenario section of the forums? 10:58:32 <LSky`> http://www.tt-forums.net/viewtopic.php?f=67&t=70917 11:00:59 <V453000> probably 11:03:08 <planetmaker> yeah, you're right, LSky` . I'll move it 11:04:41 <planetmaker> hm... that's in the Transport Tycoon section only. That's... not idea. I guess I have another suggestion for Owen :P 11:04:44 <V453000> why did the 32bpp section get merged btw? :D 11:06:21 <planetmaker> V453000, pointless to have it separate. 11:06:29 <planetmaker> it's nothing special with regard to development processes 11:06:41 <planetmaker> and its existence triggered people to believe it is 11:06:51 <peter1138> It is for TTDP players :D 11:06:53 <V453000> :D 11:06:57 <planetmaker> :D 11:07:00 <V453000> :) 11:07:18 <V453000> it felt special! :( 11:07:50 <peter1138> I bet they still want PNGs 11:08:39 *** HerzogDeXtEr [~flex@88.130.162.197] has joined #openttd 11:08:45 <LordAro> you must admit, the "new" way is more complicated that the way it was done 11:09:31 <V453000> defining 32bpp additional_sprites was nothing special tbh 11:09:58 <planetmaker> LordAro, not really. It's actually easier 11:10:31 <planetmaker> no need to count sprite numbers etc. I just add it to a NewGRF and I'm done 11:10:39 <planetmaker> no special naming either 11:10:52 <planetmaker> no special in any respect 11:11:03 <LordAro> easier? before all they had to do was dump the pngs into a tar file (which caused enough issues, typically enough). true, they've got to number the sprites, but no writing NFO/NML 11:11:20 <planetmaker> LordAro, and all name them correctly. And re-name them when you changed the grf it referred to 11:11:33 <LordAro> and this was largely before nml, iirc 11:11:38 <planetmaker> so 32bpp development was a BIG PITA really 11:12:06 <LordAro> oh, definitely 11:12:10 <planetmaker> you needed an unmoving base. Which you usally don't have. Not even for the base set's extra grf 11:13:09 <V453000> yeti-base shall show them bastards! :P 11:13:21 *** Pereba [~UserNick@187.58.50.213] has joined #openttd 11:13:56 <planetmaker> yeah... especially V's NewGRFs are no base at all. Constantly changing :P 11:14:06 <V453000> :P changed that a lot recently 11:14:35 <LordAro> :p 11:14:48 <LordAro> and multi-hundred MB downloads :p 11:15:01 <V453000> eazy! 11:15:13 <V453000> hey, it is only 144 mb now :P 11:15:17 <V453000> zbase has 250 I believe 11:15:44 <LordAro> 250? was only 45 last i checked 11:15:57 <V453000> :D 11:16:02 <V453000> idk then 11:16:21 <V453000> I downloaded it just once and upon discovering how awful it is I never bothered again really 11:17:18 <peter1138> Don't forget about setting the offsets for all those PNGs whenever you changed one... 11:17:31 <peter1138> And of course it sucked for performance. 11:19:41 <peter1138> V453000, thought about making a 8bpp version? ;) 11:20:12 <peter1138> I wonder, did the system to allow users to only download the bits of a NewGRF they need get implemented? 11:20:52 <V453000> you mean 8bpp version of yeti? 11:21:08 <peter1138> Errr.... yes, you should know I was looking at the thread... 11:21:09 <V453000> it does define 8bpp sprites, just overwrites them with 32bpp 11:21:19 <planetmaker> peter1138, OpenTTD would support it. But there's no means to download it from bananas 11:21:22 <V453000> and there is nothing to really be interested in 11:21:40 <V453000> wat peter1138 :D 11:22:12 <V453000> k well now I see that you are looking at _the_ thread XD matterz it? 11:22:39 <V453000> regardless, making a lightweight version could be cute, but how/why 11:23:02 <peter1138> Dunno really :p 11:23:05 <V453000> + lightweight doesnt need to be 8bpp, 32bpp is fine if I remove extra zoom and animations 11:23:11 <planetmaker> V453000, OpenTTD considers NewGRFs equivalent when stripping them of anything which is not 8bpp 1x sprites 11:23:25 <V453000> O_O 11:23:25 <peter1138> Hmm, true, it's x4 zoom that bloats it. 11:23:41 <planetmaker> and in principle one can strip the 'big' newgrfs of those extra sprites they provide and offer stripped versions for download, e.g. to save bandwidth 11:23:42 <V453000> aha 11:23:55 <V453000> didnt have a clue about that 11:24:27 <planetmaker> while grf format and openttd support it, there's no such interface yet in the game or bananas to select only certain bit depth or maximum zoom level for the sprites 11:24:36 <planetmaker> for your downloads from bananas 11:24:37 <V453000> so theoretically I can have a lightweight 8bpp version on the devzone that people could use if they cannot download the big one? 11:24:38 *** kero [~keikoz@pha75-1-81-57-54-15.fbx.proxad.net] has quit [Ping timeout: 480 seconds] 11:24:48 <V453000> right 11:24:52 <peter1138> Theoretically. 11:24:52 <planetmaker> in theory, yes 11:24:59 <V453000> :D 11:25:11 <peter1138> Of course, what computer doesn't support 32bpp these days... 11:25:13 <V453000> well lets see how many people will have stone age connection and complain that they cant download it 11:25:14 <planetmaker> grfstrip (part of grfcodec) gets you that grf 11:25:31 <V453000> aha, very nice so I dont even have to have 2 versions of the code 11:25:35 <V453000> hm (: 11:25:41 <planetmaker> no, of course not. That's the point :) 11:26:18 <planetmaker> authors create the version packed with everything. And that result can be stripped-down to the bit depths and zoom levels requested by a user 11:26:33 <planetmaker> it just misses an interface so that it's actually used 11:26:36 <V453000> sounds reasonable 11:27:08 <planetmaker> there simply was no need so far either 11:27:19 <planetmaker> you might trigger that need :P 11:27:56 <V453000> Almost gives me a reason not to cheat on 8bpp images :D 11:28:01 <V453000> yeah I guess 11:28:13 <V453000> though lets see how successful my current masking method gets 11:28:19 <planetmaker> well.. cheat. Just do a cheap conversion 32bpp to 8bpp 11:28:31 <V453000> for most of the industries it reduces the size a ton 11:28:39 <V453000> I know, that is what I did :P 11:28:40 <Eddi|zuHause> try to avoid the magic blinking colours while doing that :p 11:28:45 <V453000> magix 11:28:46 <planetmaker> well then :) It's no cheat 11:29:06 <V453000> I rather meant missing animations in 8bpp yet loading that amount of sprites :P 11:29:16 <V453000> is 2048 sprites for 8bpp in such case 11:29:18 <V453000> per industry 11:29:50 <planetmaker> they don't eat disk size really. It's the 4x 32bpp sprites which do :) 11:30:10 <planetmaker> they're 4*4 = 16 times bigger :) 11:30:33 <V453000> I know :) 11:30:42 <V453000> especially if you load each of them twice XD 11:30:42 <Eddi|zuHause> but 2048 times the same sprite doesn't really help, as the compression is per-sprite only, not over the whole grf 11:30:52 <V453000> yes :) 11:31:03 <V453000> that is why it is a cheat Eddi :P 11:31:04 *** Supercheese [~Superchee@76.178.136.186] has quit [Read error: Connection reset by peer] 11:31:18 <V453000> cause the strip cant strip that 11:31:34 <V453000> but hell, NUTS has idk, 60 000 sprites and people can download it 11:31:36 *** Supercheese [~Superchee@76.178.136.186] has joined #openttd 11:31:40 <Eddi|zuHause> no 11:32:15 <Eddi|zuHause> CETS probably has more 11:32:31 <V453000> CETS has empty boxes, not sprites :D 11:32:34 <Eddi|zuHause> and it doesn't even have liveries and cargo grapics yet 11:32:47 <Eddi|zuHause> but the boxes are coloured meanwhile 11:32:51 <Eddi|zuHause> not green anymore 11:33:23 <V453000> XD 11:33:27 <V453000> congratulations 11:33:49 <V453000> you might want to start drawing Eddi :P 11:34:51 <peter1138> I don't know what he looks like. 11:35:18 <planetmaker> Eddi|zuHause, cargo graphics can be stolen from NUTS ;) 11:35:47 <Eddi|zuHause> NUTS doesn't have turning angles :p 11:35:48 <V453000> XD 11:35:51 <V453000> HAHA 11:35:52 <V453000> :D 11:35:56 <planetmaker> :) 11:36:12 <V453000> I completely forgot you want to draw even that 11:36:26 <Eddi|zuHause> also, square pigs don't fit in my wagons 11:36:46 <planetmaker> apply a coordinate transform on them and they might 11:36:52 <V453000> boxes arent square? :P 11:37:12 <planetmaker> in spherical coordinates: no :P 11:37:45 <peter1138> Why doesn't 3D OpenTTD exist yet? :p 11:38:07 <Eddi|zuHause> train fever is in beta stage 11:40:07 <planetmaker> isn't TTT something like 3D OpenTTD? 11:40:31 <V453000> nothing is like openttd as far as I know :P 11:40:35 <Eddi|zuHause> but that was never even properly released 11:40:40 <V453000> /me doesnt know very far though 11:41:33 <Eddi|zuHause> what was released was an early beta version, and then it died a painful legal death 11:42:09 <V453000> nice 11:48:02 *** Flygon [~Flygon@147.18.214.218.sta.commander.net.au] has joined #openttd 11:49:28 *** KWKdesign [~KWKdesign@pool-108-52-130-213.phlapa.fios.verizon.net] has quit [Read error: Operation timed out] 11:49:31 *** KWKdesign [~KWKdesign@pool-108-52-130-213.phlapa.fios.verizon.net] has joined #openttd 11:53:10 *** Flygon_ [~Flygon@147.18.214.218.sta.commander.net.au] has quit [Ping timeout: 480 seconds] 12:01:42 *** KWKdesign [~KWKdesign@pool-108-52-130-213.phlapa.fios.verizon.net] has quit [Read error: Operation timed out] 12:02:16 *** KWKdesign [~KWKdesign@pool-108-52-130-213.phlapa.fios.verizon.net] has joined #openttd 12:17:43 *** yorick [~yorick@ip51cd0513.speed.planet.nl] has joined #openttd 12:27:07 *** Flygon_ [~Flygon@147.18.214.218.sta.commander.net.au] has joined #openttd 12:32:52 *** Flygon [~Flygon@147.18.214.218.sta.commander.net.au] has quit [Read error: Operation timed out] 12:37:32 *** bugzee [~bugzee@75-106-22-229.cust.wildblue.net] has quit [Ping timeout: 480 seconds] 12:38:38 *** Hazzard_ [~quassel@c-67-174-253-44.hsd1.ca.comcast.net] has joined #openttd 12:39:08 *** bugzee [~bugzee@75-106-22-229.cust.wildblue.net] has joined #openttd 12:45:12 *** Hazzard [~quassel@c-67-174-253-44.hsd1.ca.comcast.net] has quit [Ping timeout: 480 seconds] 12:54:21 *** sla_ro|master [slamaster@89.137.74.191] has joined #openttd 13:09:40 *** APTX [~APTX@aptx.org] has joined #openttd 13:17:38 *** APTX_ [~APTX@aptx.org] has quit [Ping timeout: 480 seconds] 13:47:24 *** sla_ro|master [slamaster@89.137.74.191] has quit [] 13:49:26 *** LadyHawk [~LadyHawk@5ED3E068.cm-7-4d.dynamic.ziggo.nl] has joined #openttd 13:50:03 *** LadyHawk is now known as Guest3485 14:02:43 *** Tuhin [~Tuhin@fip31c146.banglalionwimax.com] has quit [Read error: Connection reset by peer] 14:03:45 *** Tuhin [~Tuhin@fip31c146.banglalionwimax.com] has joined #openttd 14:07:38 *** kero [~keikoz@pha75-1-81-57-54-15.fbx.proxad.net] has joined #openttd 14:17:35 *** KWKdesign [~KWKdesign@pool-108-52-130-213.phlapa.fios.verizon.net] has quit [Ping timeout: 480 seconds] 14:18:01 *** KWKdesign [~KWKdesign@pool-108-52-130-213.phlapa.fios.verizon.net] has joined #openttd 14:39:08 *** Brumi_ [~quassel@78-131-41-191.pool.digikabel.hu] has joined #openttd 14:42:58 *** Brumi [~quassel@78-131-41-191.pool.digikabel.hu] has quit [Ping timeout: 480 seconds] 15:14:18 *** Guest3485 [~LadyHawk@5ED3E068.cm-7-4d.dynamic.ziggo.nl] has quit [Quit: If at first you don't succeed, destroy all evidence that you tried] 15:22:43 *** SylvieLorxu [~sylvie@dhcp-077-251-165-191.chello.nl] has joined #openttd 15:23:50 *** sla_ro|master [slamaster@89.137.74.191] has joined #openttd 15:37:08 *** DDR [~kvirc@S010600254bbe4e1c.vc.shawcable.net] has joined #openttd 15:42:07 *** Pensacola [~quassel@h220216.upc-h.chello.nl] has joined #openttd 15:47:02 *** matthew [~matthew@cpc66203-derb15-2-0-cust161.8-3.cable.virginm.net] has joined #openttd 15:47:23 *** matthew is now known as Guest3500 15:47:46 *** Guest3500 [~matthew@cpc66203-derb15-2-0-cust161.8-3.cable.virginm.net] has quit [] 15:49:25 *** ZirconiumX [~matthew@cpc66203-derb15-2-0-cust161.8-3.cable.virginm.net] has joined #openttd 15:49:38 <ZirconiumX> Afternoon 15:50:54 *** montalvo [~montalvo@47.sub-70-211-71.myvzw.com] has joined #openttd 15:54:13 <LordAro> ohai 15:55:37 <ZirconiumX> How's it been? 15:56:05 <LordAro> not too bad 15:56:48 * ZirconiumX is slightly confused about how flyspray still has an open bug report for OpenTTD 0.4.7 15:57:05 <ZirconiumX> FS#127 16:00:02 *** TheMask96 [martijn@envy.vhost.ne2000.nl] has quit [Ping timeout: 480 seconds] 16:02:45 <LordAro> @fs 127 16:02:45 <DorpsGek> LordAro: http://bugs.openttd.org/task/127 16:03:01 <ZirconiumX> Ah, thank you 16:03:07 <LordAro> probably because it hasn't been fixed :P 16:03:29 <LordAro> and actually, it's a feature request, which are largely ignored anyway :p 16:03:36 <ZirconiumX> Or it's so old they simply don't care. 16:04:26 <LordAro> quite 16:04:30 <LordAro> that said 16:04:34 <LordAro> @fs 54 16:04:34 <DorpsGek> LordAro: http://bugs.openttd.org/task/54 16:04:45 <LordAro> was the oldest until a few months ago 16:04:51 *** TheMask96 [martijn@pride.vhost.ne2000.nl] has joined #openttd 16:24:55 <ZirconiumX> Back. 16:27:11 <ZirconiumX> I'm not entirely sure if there is much point to fs 127 16:29:16 <LordAro> probably not 16:29:35 <LordAro> probably not a lot of point to any <3000 16:29:36 <ZirconiumX> If only there was a way of voting to close an FS 16:31:49 <Eddi|zuHause> nobody of power ever listened to votes 16:33:21 <V453000> you cannot force anybody to do anything, not even votes can :P it is open source 16:36:56 <ZirconiumX> And also free software. 16:37:00 <Eddi|zuHause> you cannot make a particular horse drink, but of 100 horses, you can easily make a majority drink 16:37:23 <ZirconiumX> I suppose you'd end up with a Down's paradox. 16:37:39 <Eddi|zuHause> the first is called psychology and the second is called sociology 16:38:37 *** Klanticus [~quassel@179.154.136.250] has joined #openttd 16:38:58 <ZirconiumX> I suppose so. 16:39:28 <ZirconiumX> But having ancient FS bugs from 8 years ago does nothing useful. 16:39:56 <planetmaker> good evening 16:39:57 <ZirconiumX> *feature requests 16:40:05 <ZirconiumX> GE planetmaker 16:40:13 <Rubidium> though... the problem here is more that fixing things is less glamourous than making something fancy 16:40:30 <ZirconiumX> Has to be done though. 16:40:33 <V453000> hy 16:40:49 <Eddi|zuHause> that's why it's still open 16:41:22 <ZirconiumX> @fs 3764 16:41:23 <DorpsGek> ZirconiumX: http://bugs.openttd.org/task/3764 16:41:27 <Eddi|zuHause> because technically it is something that might be fixed at some point. if someone is really bored 16:41:31 <ZirconiumX> seems to be the oldest bug report. 17:02:26 *** Pol [~quassel@h220216.upc-h.chello.nl] has joined #openttd 17:08:22 *** Pensacola [~quassel@h220216.upc-h.chello.nl] has quit [Ping timeout: 480 seconds] 17:12:02 <Eddi|zuHause> k10temp-pci-00c3 temp1: +37.0°C <--- how do i find out where this sensor is? 17:12:15 <ZirconiumX> Not very easily 17:12:27 <ZirconiumX> Though I'd guess K10temp refers to the builtin processors 17:12:27 <Rubidium> lspci? 17:12:55 <Eddi|zuHause> Rubidium: that doesn't really tell me the physical location? 17:13:12 <Rubidium> might give you a clue 17:13:26 <ZirconiumX> Rubidium: can confirm this does not work 17:15:47 <ZirconiumX> Eddi|zuHause: https://www.kernel.org/doc/Documentation/hwmon/k10temp 17:16:07 <ZirconiumX> "This driver permits reading of the internal temperature sensor of AMD 17:16:09 <ZirconiumX> Family 10h/11h/12h/14h/15h/16h processors." 17:16:39 <Rubidium> apparantly it's a sensor within the CPU: https://bbs.archlinux.org/viewtopic.php?id=104723 17:17:10 <ZirconiumX> 18:11 < ZirconiumX> Though I'd guess K10temp refers to the builtin processors 17:24:00 <Eddi|zuHause> but that mens the cpu is 10-20°C colder than the rest of the computer 17:24:17 <LordAro> i could've sworn that temperature sensor referred to the GPU 17:24:32 <LordAro> do you have an AMD/ATI graphics card? 17:24:33 *** frosch123 [~frosch@frnk-4d01d2f4.pool.mediaWays.net] has joined #openttd 17:24:42 <Eddi|zuHause> gpu makes way more sense 17:24:53 <LordAro> (i have a similar sensor, but it shows up as 0°C :L ) 17:24:56 <LordAro> quak 17:25:05 <frosch123> hola 17:25:52 <planetmaker> o/ 17:25:55 <Eddi|zuHause> i also have it8720-isa-0228: temp1: +47.0°C, temp2: +48.0°C, temp3: +55.0°C 17:26:47 <Eddi|zuHause> those are apparently on the mainboard, but i have no clue where 17:27:46 <Eddi|zuHause> and yes, i have an ATI card. a builtin one that i don't use and a PCI-E one. 17:29:40 *** Pensacola [~quassel@h220216.upc-h.chello.nl] has joined #openttd 17:31:00 * LordAro got a new cpu cooler/fan recently. it's wonderful 17:31:22 <LordAro> quieter and colder 17:34:06 *** Pol [~quassel@h220216.upc-h.chello.nl] has quit [Read error: Operation timed out] 17:34:22 <Eddi|zuHause> there's pwm for making things quieter, but that usually makes it hotter :) 17:34:22 <frosch123> is there a system call to explode a computer? 17:35:53 <Rubidium> LordAro: why? k10temp is for AMD processors; https://www.kernel.org/doc/Documentation/hwmon/k10temp 17:36:31 *** KenjiE20 [kenjie20@irc.blinkenshell.org] has joined #openttd 17:36:33 <LordAro> Rubidium, i may well be misremembering, i'm away from my desktop at the moment 17:36:46 <frosch123> is it a feature that realisitic acceleration cannot handle 1 000 000 hp? :p 17:37:09 <Rubidium> Eddi|zuHause: read the indented part of the link I just gave to LordAro 17:37:59 <LordAro> certainly, the `sensors` reading for my graphics card shows up as 0°C 17:39:48 <Eddi|zuHause> so it's not an actual °C but a "if this reaches 70, you better get cover" 17:40:08 <Eddi|zuHause> why do they call it °C then? 17:40:43 <Rubidium> because sensors forces that postfix? 17:46:40 <DorpsGek> Commit by translators :: r26701 /trunk/src/lang (3 files) (2014-07-22 17:46:30 UTC) 17:46:41 <DorpsGek> -Update from WebTranslator v3.0: 17:46:42 <DorpsGek> traditional_chinese - 1 changes by siu238X 17:46:43 <DorpsGek> hungarian - 31 changes by Brumi 17:46:44 <DorpsGek> norwegian_bokmal - 1 changes by 17:46:45 <DorpsGek> polish - 4 changes by McZapkie 17:48:37 <frosch123> the yeti thread is interesting :) V uses a completely different tool chain than i would use, but the results works nevertheless :) 17:51:02 *** Pensacola [~quassel@h220216.upc-h.chello.nl] has quit [Remote host closed the connection] 17:56:02 *** Progman [~progman@p57A1BC9A.dip0.t-ipconnect.de] has joined #openttd 17:59:40 <planetmaker> yeah :) 18:13:48 <Rubidium> frosch123: FS#6067 smells like an overflow 18:19:12 *** LadyHawk [~LadyHawk@5ED3E068.cm-7-4d.dynamic.ziggo.nl] has joined #openttd 18:19:12 *** LadyHawk [~LadyHawk@5ED3E068.cm-7-4d.dynamic.ziggo.nl] has quit [] 18:19:20 <frosch123> yup, if not a desync on 64bit :p 18:19:45 <frosch123> but well, 100k hp is not particulary interesting 18:35:23 <Rubidium> won't it use the same int type? 18:35:38 <Rubidium> otherwise... we'd have much more desyncs I'd say 18:35:42 <frosch123> also for intermediate computations? 18:35:56 <peter1138> frosch123, http://en.wikipedia.org/wiki/W%C3%A4rtsil%C3%A4-Sulzer_RTA96-C 18:36:15 <peter1138> You might need some quite hefty track for that though... 18:36:47 <peter1138> (Or implement RA for ships...) 18:37:32 <Rubidium> isn't int 32 bits? 18:37:58 <Rubidium> the code's even littered with uint32 and byte 18:38:11 <frosch123> yes, but i have no idea what happens if you do "a * 1000 / 1000" 18:38:27 <frosch123> the result will be 32bit, but what about "a * 1000" ? 18:38:35 <Rubidium> max_te gets a max_te *= 10000 18:38:59 <frosch123> oh, i didn't look into details of the acceleration code 18:39:15 <frosch123> i only wondered in general whether those computations are not implementation specfic 18:42:32 <Rubidium> max value for 'power' = (sum of part powers) * 746 * 18 18:42:41 <Rubidium> @calc 2**31 / 161517 18:42:41 <DorpsGek> Rubidium: 13295.7128228 18:42:47 <Rubidium> @calc 746*18 18:42:47 <DorpsGek> Rubidium: 13428 18:43:03 <Rubidium> check... overflow! 18:44:04 <Rubidium> what's the theoretical maximum power? 18:44:32 <frosch123> 64k per vehicle, 128 vehicles, 128 articulated parts per vehicle 18:44:52 <frosch123> hmm, though i guess only the front part can add power 18:45:12 <frosch123> so only 128*64k :p 18:45:41 <Rubidium> there's a GetPower that prevents articulated parts 18:46:11 <Rubidium> and a GetPoweredPartPower which uses the VRF_POWERED_WAGON flag 18:46:20 <Rubidium> @calc 128*65535 18:46:20 <DorpsGek> Rubidium: 8388480 18:46:37 <Rubidium> that's not the 1 million the bug reporter is talking about 18:47:15 <Rubidium> I would've guessed (naively) at 64*2*8 * 64k 18:47:22 <Rubidium> @calc 62*2*8*65535 18:47:22 <DorpsGek> Rubidium: 65010720 18:47:46 <Rubidium> hmm... I'm stupid... 8.3 million > 1 million 18:47:58 *** ZirconiumX [~matthew@cpc66203-derb15-2-0-cust161.8-3.cable.virginm.net] has quit [Ping timeout: 480 seconds] 18:48:05 <Rubidium> anyhow... 128*128*64k < 2**31 18:48:28 <Rubidium> however, multiplying by 13428 doesn't fit 18:49:33 <frosch123> @calc log(13428 * 128 * 65536, 2) 18:49:33 <DorpsGek> frosch123: 36.7129568217 18:50:13 <frosch123> yeah, factor 64 too much 18:51:27 *** George|2 [~George@185.43.94.91] has joined #openttd 18:51:27 *** George is now known as Guest3525 18:51:27 *** George|2 is now known as George 18:53:32 <Rubidium> @calc 65535*128*746*18 18:53:32 <DorpsGek> Rubidium: 112640509440 18:54:56 <Eddi|zuHause> <frosch123> the result will be 32bit, but what about "a * 1000" ? <-- in C(++), int32*int32 = int32, which i find stupid, because every CPU on this planet outputs 64 bits... 18:55:22 <Eddi|zuHause> well, every USEFUL cpu 18:55:46 <frosch123> you do not consider mmx, sse, ... and friends useful? :p 18:57:03 *** Guest3525 [~George@185.43.94.91] has quit [Ping timeout: 480 seconds] 18:57:16 <Eddi|zuHause> NO! the world must forever be stuck with the i386 command set 19:06:20 *** oskari89 [oskari89@83-102-63-32.bb.dnainternet.fi] has joined #openttd 19:12:41 *** Wolf01 [~wolf01@0001288e.user.oftc.net] has joined #openttd 19:13:05 <Wolf01> hi hi 19:14:28 *** Hazzard_ [~quassel@c-67-174-253-44.hsd1.ca.comcast.net] has quit [Read error: Connection reset by peer] 19:15:20 <Rubidium> http://rbijker.net/openttd/fs6067.diff <- untested, but it's now more about the comments. Did I make gross mistakes somewhere? 19:16:00 <murr4y> https://www.kickstarter.com/projects/1759006687/man-from-earth-the-series 19:17:37 <frosch123> @calc log(65535*128*746,2) 19:17:38 <DorpsGek> frosch123: 32.5430098063 19:18:26 <frosch123> + int64 power = this->gcache.cached_power * 746; <- i guess that shuold be (int64)cached_power * 746ll 19:18:48 <Rubidium> one cast should be enough 19:19:16 <Rubidium> or the 746ll I'd say 19:20:50 <Rubidium> the patch definitely improves the performance of that train 19:22:32 <frosch123> area * this->gcache.cached_air_drag <- according to your comments that also exceeds int32 19:22:40 <frosch123> so i would expect it to need casts as well 19:23:32 <Rubidium> 28*~5000 doesn't, the speed**2 would make it overflow and I made speed int64 19:23:55 <Rubidium> so the ~100k gets promoted to int64 by speed 19:24:00 <frosch123> ok 19:30:48 *** Klanticus_ [~quassel@189.35.187.130] has joined #openttd 19:32:02 <Rubidium> oh, I reckon limiting the acceleration to int32 isn't a big problem, right? ;) 19:32:20 <frosch123> is it realistic? 19:33:13 <frosch123> how many seconds does it need to reach lightspeed at that acceleration? 19:33:34 <frosch123> i.e. when is the acceleration code not realistic enough? 19:35:00 *** Klanticus [~quassel@179.154.136.250] has quit [Ping timeout: 480 seconds] 19:36:12 <frosch123> i like how wiki liss approximate and "exact" values :p 19:36:17 <frosch123> *lists 19:37:20 <frosch123> we should use "planck length per planck time" to measure light speed 19:37:41 <frosch123> it's the most suitable one for a good approximation 19:39:29 *** b_jonas [~x@russell2.math.bme.hu] has joined #openttd 19:39:33 <planetmaker> totally. Gives us good reason to argue for vehicle quantum effects, too ;) 19:39:44 <b_jonas> hello 19:39:51 <planetmaker> hi 19:40:38 <planetmaker> though I learnt today that they're really planning to measure (and then actually define) current on a single-electron basis 19:41:31 <Rubidium> quantum effects smells like floating point to me (waveform functions and such) 19:41:49 <frosch123> yeah, quantum effects desync all the time 19:41:52 <planetmaker> nah. It boils it down to ints again, to yes or no :) 19:42:33 <frosch123> though maybe every client can simulate all potential desync states, so they are in sync again 19:42:40 <planetmaker> :) 19:46:16 <DorpsGek> Commit by rubidium :: r26702 /trunk/src (ground_vehicle.cpp ground_vehicle.hpp) (2014-07-22 19:46:10 UTC) 19:46:17 <DorpsGek> -Fix [FS#6067]: integer overflows in acceleration code causing either too low acceleration or too large acceleration 19:47:41 *** montalvo [~montalvo@47.sub-70-211-71.myvzw.com] has quit [Quit: Textual IRC Client: www.textualapp.com] 19:48:28 <Rubidium> why are journalist so dump? 19:49:07 <frosch123> else they wouldn't be journalists? 19:49:16 <frosch123> same about teachers 19:49:19 <frosch123> or ottd devs 19:50:24 <Rubidium> asking someone doing identification based on DNA (in case of the MH17) whether they'd do the identification for the non-Dutch victims too... 19:51:03 <Rubidium> (as if the victims have a tag with their nationality) 19:51:21 <planetmaker> they actually might have... in their wallets in their trousers 19:51:36 <frosch123> then you do not need the dna thingie 19:52:11 <planetmaker> yeah. And I wonder how someone would want to identify me by my DNA? They would have to break into my flat for comparison or so 19:52:20 <planetmaker> hopefully at least :P 19:52:25 *** George is now known as Guest3530 19:52:27 *** George [~George@185.43.94.91] has joined #openttd 19:52:34 <frosch123> planetmaker: siblings and nsa recordings 19:53:49 <Rubidium> planetmaker: I'd reckon the next of kin of you would be able to provide them with something 19:55:08 <frosch123> and in the worst case it may also be the key to what pieces belong to the same puzzle :/ 19:58:02 *** Guest3530 [~George@185.43.94.91] has quit [Ping timeout: 480 seconds] 20:02:37 *** Klanticus_ [~quassel@189.35.187.130] has quit [Remote host closed the connection] 20:06:38 *** Brumi_ [~quassel@78-131-41-191.pool.digikabel.hu] has quit [] 20:09:07 <michi_cc> Rubidium: Your commit changes the power factor from 746 to 74611, but I can't see any divisor changed to match. Sure this is right? 20:09:42 <frosch123> michi_cc: fix your font :p 20:11:13 <michi_cc> Ah, ll :) Well, seems the browser doesn't feature an intelligent font chooser. 20:18:58 <Rubidium> or color-coding C++ 20:22:13 *** Yotson [~Yotson@2001:980:6ac8:1:5451:9a74:b196:815f] has quit [Quit: .] 20:27:18 *** MJP [~mjp@hq.z77.fr] has quit [Ping timeout: 480 seconds] 21:08:26 *** FLHerne [~flh@dsl-217-155-24-22.zen.co.uk] has joined #openttd 21:14:38 *** sla_ro|master [slamaster@89.137.74.191] has quit [] 21:31:33 *** Progman [~progman@p57A1BC9A.dip0.t-ipconnect.de] has quit [Remote host closed the connection] 21:36:28 *** Brumi [~quassel@78-131-41-191.pool.digikabel.hu] has joined #openttd 21:37:12 *** pthagnar [~pthagnar@cpc7-pres17-2-0-cust28.18-3.cable.virginm.net] has quit [Quit: Leaving] 21:38:08 <NGC3982> Can someone remind me; Why arent we running OpenTTD servers of RPI's? 21:39:35 <frosch123> for the same reason why you do not run your cellphone with one 21:40:21 <FLHerne> NGC3982: Because Pis are aargh slow 21:40:58 <NGC3982> I fail to see how they lack the processing power for dedicated servers. 21:41:18 <NGC3982> Although, this has been discussed. I just can't remember why it wasn't the best of ideas. 21:41:20 <FLHerne> And if servers aren't CPU-limited (which they sometimes are on sane hardware, let alone Pentium-300 analogues) they're network-limited 21:41:34 <frosch123> what makes you think servers would need less power? 21:41:56 <FLHerne> And Pi networking is on the USB bus, and tends to cause total hangs in case of continuous max throughput 21:42:26 <FLHerne> The server uses as much CPU as the client, barring blitting 21:42:48 <MTsPony> try again with 15 companies and 1000+ trains and some CB script and 20/30 GRF's ;) 21:43:24 <MTsPony> even a i7 4.5GHz gets as high as 60-70% on the process (tho in a vm so there might be some overhead) 21:43:32 <frosch123> ah, true, gamescript even add to the power :p 21:43:51 <frosch123> though usually it is not much 21:44:01 <MTsPony> Usually :p 21:44:05 <frosch123> likely blitting is more than gs 21:44:15 <frosch123> MTsPony: they cannot really do much 21:44:31 <MTsPony> its another 5-10% of the cpu, on a 4K x 4K map with 'only' 100 cities/towns 21:44:38 <frosch123> if they want to do stuff, they have to run commands, which have strong limits 21:46:25 <MTsPony> still, 1000 ships, 1000 trains, some 1000 road vehs etc last time on my server, load is pretty bad ass, even on my intel compiled binary which already reduced cpu usage by a whole load lol 21:46:45 <MTsPony> with all the fancy tricks, resolution at 1,1, all fancy stuff off server side, load on corner of the map, etc etc 21:47:07 <frosch123> resolution shouldn't have any effect since 0.6 :p 21:47:12 <MTsPony> 4k x 4k map, pretty hefty :o way more then client side load :D 21:47:16 <MTsPony> meh probably not, 21:47:22 <MTsPony> did it anyway :p 21:47:35 <MTsPony> better safe then sorry 21:47:42 <MTsPony> bbiab 21:48:17 <frosch123> haha, you can always recognize the dutch guys 21:48:56 *** FLHerne [~flh@dsl-217-155-24-22.zen.co.uk] has quit [Read error: No route to host] 21:48:59 *** FLHerne [~flh@dsl-217-155-24-22.zen.co.uk] has joined #openttd 21:49:03 <MTsPony> -.- 21:49:23 <frosch123> only dutch guys do the then/than thing :) 21:51:03 <MTsPony> 'than' :p 21:51:11 <MTsPony> i thouht that was purely brittish :p 21:51:19 <MTsPony> thought* 21:54:22 <frosch123> night 21:54:27 *** frosch123 [~frosch@frnk-4d01d2f4.pool.mediaWays.net] has quit [Quit: be yourself, except: if you have the opportunity to be a unicorn, then be a unicorn] 21:57:53 <NGC3982> < FLHerne> The server uses as much CPU as the client, barring blitting 21:58:08 <NGC3982> Really? 21:58:23 <planetmaker> yes 21:58:28 <NGC3982> My i5 can't handle my own 4096^2 server i run on a P4 Ubuntu server. 21:58:34 <FLHerne> NGC3982: Well, and sprite-sorting and whatever 21:58:41 <NGC3982> What don't i understand. 22:06:30 *** oskari89 [oskari89@83-102-63-32.bb.dnainternet.fi] has quit [] 22:07:18 <NGC3982> I see. 22:07:18 <NGC3982> .. 22:09:04 <Wolf01> 'night 22:09:09 *** Wolf01 [~wolf01@0001288e.user.oftc.net] has quit [Quit: Once again the world is quick to bury me.] 22:18:46 <peter1138> Yeah, a Pi sucks for OpenTTD. 22:19:21 <NGC3982> Too bad. It would be optimal. 22:19:34 <peter1138> Something too slow would be optimal. Right. 22:20:02 <NGC3982> Of course you understand what i mean 22:20:14 <NGC3982> A small open source based system running a small open source based game. 22:21:22 <peter1138> Is Pi open source now? 22:21:33 <NGC3982> I guess the Pi itself is not 22:21:40 <peter1138> The graphics chipset was rather closed up previously. Maybe that's fixed. 22:21:44 <NGC3982> But everything about it is similar to everything about you guys. 22:21:47 <peter1138> Everything? 22:22:36 <peter1138> It's a small underpowered machine that runs Linux. There's loads of them around, called home routers. 22:22:52 <NGC3982> Are you comparing the Raspberry Pi to a router? 22:22:53 <peter1138> The Pi is quite a nice machine running RISC OS, though. 22:23:00 <peter1138> No, routers are generally more useful. 22:23:05 <NGC3982> I see. 22:23:06 <FLHerne> NGC3982: OTTD is quite a long way from 'small', in code or hw requirements 22:23:34 <NGC3982> I still don't understand the fact that the server uses the same amount of CPU as the client. 22:23:43 <NGC3982> Since that is not what i experience. 22:23:45 *** SylvieLorxu [~sylvie@dhcp-077-251-165-191.chello.nl] has quit [Remote host closed the connection] 22:23:47 <FLHerne> NGC3982: My router is faster than a first-gen Pi, and you can get ones with more RAM 22:23:47 <NGC3982> h 22:23:50 <peter1138> Because it has to do exactly the same processing as a client. 22:23:52 <NGC3982> FLHerne: Hehe. 22:24:13 <FLHerne> Also, it doesn't hang under network load (which would be daft in a router but is somehow acceptable if it's a hobby thing) 22:24:17 <peter1138> Routers generally have much faster networking than a Pi does. 22:24:28 <__ln__> someone said Pi is really good for very few other things besides playing video/media, and by a strange coincidence playing video/media is exactly what the chipset used by Pi is meant for. 22:25:01 <peter1138> Yes, but it's not very good for that, because the user interface to select your media is horribly slow. 22:25:07 <NGC3982> How come i can run my five (huge) servers with no issue on an old P4, and my i5 struggle with one of them? 22:25:36 <peter1138> What's the clockspeed of each? 22:26:05 <NGC3982> I do think my P4 is somewhere around 3GHz, and the i5 is a ..480M, perhaps? 22:26:09 <NGC3982> Ah. 22:26:12 *** bdavenport [~davenport@aeolus.mindlesstux.com] has quit [Ping timeout: 480 seconds] 22:26:23 <NGC3982> Wait, the P4 is single-core, i guess.. 22:26:36 <peter1138> What speed does a 480M run at? 22:26:45 <NGC3982> Per core? 22:26:47 <NGC3982> Let's see. 22:26:54 <peter1138> What speed. 22:27:03 <peter1138> M implies mobile, so probably quite slow. 22:27:08 <NGC3982> 2,66GHz, according to their website. 22:27:26 <NGC3982> But i have no idea how to translate that into "per core", since that seems to make a difference for OpenTTD. 22:27:40 <peter1138> No it doesn'.t 22:27:44 <peter1138> No it doesn't. 22:27:49 <peter1138> It's 2.66 GHz. 22:27:57 <peter1138> Each core can run at 2.66 GHz. 22:28:03 <NGC3982> Aha 22:28:15 <NGC3982> Well, that explains it. 22:29:20 <peter1138> It's possible your i5 is running in a power saving mode. 22:29:23 *** bdavenport [~davenport@aeolus.mindlesstux.com] has joined #openttd 22:30:24 <FLHerne> NGC3982: OTTD doesn't multithread very well (autosaving, linkgraph calculation - is rendering threaded?) 22:32:58 <peter1138> But an i5 at 2.66 GHz should easily compete with a P4 at 3 GHz, regardless of multiple cores. 22:37:42 <FLHerne> I don't think the IPC difference is that dramatic, and if his P4 is just running a headless server with no rendering and not much other overhead 22:45:09 *** LSky` [LSky@5ED4B2EA.cm-7-5c.dynamic.ziggo.nl] has quit [] 23:02:25 *** FLHerne [~flh@dsl-217-155-24-22.zen.co.uk] has quit [Quit: There's a real world out here!] 23:25:31 *** yorick [~yorick@ip51cd0513.speed.planet.nl] has quit [Remote host closed the connection] 23:27:46 *** Supercheese [~Superchee@76.178.136.186] has quit [Quit: Valete omnes] 23:32:15 *** DDR [~kvirc@S010600254bbe4e1c.vc.shawcable.net] has quit [Read error: Connection reset by peer] 23:59:27 *** Flygon [~Flygon@147.18.214.218.sta.commander.net.au] has joined #openttd