Times are UTC Toggle Colours
00:04:34 *** welshdragon [~welshdrag@client-86-31-238-229.oxfd.adsl.virginmedia.com] has joined #openttd 00:07:30 *** Progman [~progman@p57A1B8E4.dip.t-dialin.net] has quit [Remote host closed the connection] 00:19:02 *** George|2 [~George@212.113.107.39] has joined #openttd 00:19:03 *** George is now known as Guest15747 00:19:03 *** George|2 is now known as George 00:21:37 *** TWerkhoven [~twerkhove@cpc14-linl7-2-0-cust28.sgyl.cable.virginmedia.com] has quit [Quit: He who can look into the future, has a brighter future to look into] 00:25:32 *** Guest15747 [~George@212.113.107.39] has quit [Ping timeout: 480 seconds] 00:31:53 <michi_cc> Secret surprise feature incoming! 8) 00:34:44 <CIA-6> OpenTTD: michi_cc * r23086 /trunk/src/ (newgrf_callbacks.h vehicle_cmd.cpp): -Feature: [NewGRF] Callback to change refit cost depending on old and new cargo type. 00:38:31 <CIA-6> OpenTTD: michi_cc * r23087 /trunk/src/ (7 files): -Feature: Auto-refitting of vehicles during loading at a station when the vehicle allows it. 00:38:35 <CIA-6> OpenTTD: michi_cc * r23088 /trunk/src/order_gui.cpp: -Change: Extend the train order GUI with space for a forth button. 00:38:39 <CIA-6> OpenTTD: michi_cc * r23089 /trunk/src/ (lang/english.txt order_gui.cpp vehicle_gui.cpp vehicle_gui.h): -Add: Allow specifying refits for go-to station orders. 00:40:24 <planetmaker> we should update the PublicServer in 20 hours 00:41:58 <frosch123> and release a new ogfx+ in that time? :p 00:46:01 *** KritiK [~Maxim@95-27-24-206.broadband.corbina.ru] has quit [Quit: Leaving] 00:46:15 <planetmaker> no, I won't manage, I'm afraid. It's weekend for a birthday party in another town ... 00:46:47 <frosch123> well, but it there some set with zero refit costs? 00:47:13 <planetmaker> I don't think so 00:47:19 <planetmaker> though... not sure 00:47:23 <planetmaker> might even be 00:48:05 <frosch123> fish has no refit costs 00:48:14 <supermop_> heqs doesnt charge you to refit last time i checked 00:48:46 <frosch123> so, all andy sets :p 00:49:30 <planetmaker> :-) 00:50:54 <supermop_> i think egrvts is the same 00:52:51 <michi_cc> frosch123: I don't think there's a set that already sets the new misc flag 00:53:03 <frosch123> good point :) 01:00:09 *** Brianetta [~brian@188-220-91-30.zone11.bethere.co.uk] has quit [Quit: TschÃŒÃ] 01:08:46 <frosch123> night 01:08:50 *** frosch123 [~frosch@frnk-590f7839.pool.mediaWays.net] has quit [Remote host closed the connection] 01:09:20 <planetmaker> sounds like a good plan. Good night also from here 01:09:49 <supermop_> later 01:12:55 *** glx [glx@2a01:e35:2f59:c7c0:1dc7:46c9:a51b:34e8] has quit [Quit: bye] 01:20:23 *** welshdragon [~welshdrag@client-86-31-238-229.oxfd.adsl.virginmedia.com] has left #openttd [Leaving] 01:22:30 <peter1138> it's not me :D 01:23:45 <peter1138> discrepancy in palette animation. yum. 01:28:15 *** pjpe [ade6a119@ircip2.mibbit.com] has quit [Quit: http://www.mibbit.com ajax IRC Client] 01:28:21 *** pjpe [ade6a119@ircip4.mibbit.com] has joined #openttd 01:32:31 <z-MaTRiX> i wrote 2 SDL example programs, 1 with double_buffer and 1 only specifying fullscreen, the double_buffer one takes 12 seconds, the fullscreen takes 13 seconds, is this because i dont have hadrware accelerated drivers now? 01:33:36 <z-MaTRiX> (only filling whole screen with pixel values using for loops) 01:47:52 <z-MaTRiX> hmm i think vertical retrace is always waited for 01:49:57 <z-MaTRiX> anybody know how to turn off SDL vertical retrace synchronization? 01:57:20 <peter1138> using SDL_Flip? 02:03:51 <peter1138> heh 02:03:54 <peter1138> /* DO NOT CHANGE TO HWSURFACE, IT DOES NOT WORK */ 02:04:01 <peter1138> that always amused me 02:04:10 <peter1138> i wonder what does not work 02:04:17 <peter1138> seems to work perfectly fine for me :) 02:10:12 <z-MaTRiX> :) 02:10:19 <z-MaTRiX> well hwsurface works for me too 02:34:21 *** blotek [~blotek@adfu213.neoplus.adsl.tpnet.pl] has quit [Ping timeout: 480 seconds] 03:25:51 *** rhaeder1 [~quix0r@dslb-188-109-242-197.pools.arcor-ip.net] has joined #openttd 03:30:26 *** rhaeder [~quix0r@dslb-094-221-145-019.pools.arcor-ip.net] has quit [Ping timeout: 480 seconds] 04:41:53 *** Kurimus [~stabbity@dsl-tkubrasgw3-fe93dd00-34.dhcp.inet.fi] has joined #openttd 05:17:39 *** mahmoud [~KEM@ALyon-158-1-31-22.w90-29.abo.wanadoo.fr] has quit [Quit: Quitte] 05:46:40 *** supermop_ [~daniel_er@cpe-67-243-25-39.nyc.res.rr.com] has quit [Quit: supermop_] 05:51:59 *** Elukka [Elukka@89-166-103-135.bb.dnainternet.fi] has joined #openttd 05:55:39 *** Eddi|zuHause [~johekr@p54B73DF3.dip.t-dialin.net] has quit [Remote host closed the connection] 05:56:04 *** Eddi|zuHause [~johekr@p54B739BF.dip.t-dialin.net] has joined #openttd 06:04:50 <CIA-6> OpenTTD: rubidium * r23090 /trunk/src/landscape.cpp: -Codechange: use map accessors instead of directly accessing the map (mhl) 06:16:30 *** JVassie [~James@2.27.86.104] has joined #openttd 06:24:45 <dihedral> greetings 06:30:58 *** Prof_Frink [~proffrink@5e0a9627.bb.sky.com] has quit [Ping timeout: 480 seconds] 07:02:44 *** Cybertinus [~Cybertinu@tunnel3304.ipv6.xs4all.nl] has joined #openttd 07:11:54 *** andythenorth [~Andy@cpc15-aztw25-2-0-cust3.aztw.cable.virginmedia.com] has joined #openttd 07:20:21 *** DabuYuTimeOut [DabuYu@128.250.79.189] has joined #openttd 07:23:00 <Terkhen> good morning 07:23:31 *** DabuYu [DabuYu@128.250.79.189] has quit [Ping timeout: 480 seconds] 07:23:48 *** sla_ro|master [~slaco@95.76.27.160] has joined #openttd 07:25:10 *** DayDreamer [~DayDreame@ip-86-49-59-25.net.upcbroadband.cz] has joined #openttd 07:27:45 *** JVassie [~James@2.27.86.104] has quit [Ping timeout: 480 seconds] 07:28:45 *** Zuu [~Zuu@h-114-141.a98.priv.bahnhof.se] has joined #openttd 07:33:50 <planetmaker> moin 07:33:53 <dihedral> :-) 07:34:41 *** andythenorth [~Andy@cpc15-aztw25-2-0-cust3.aztw.cable.virginmedia.com] has quit [Quit: andythenorth] 07:52:48 *** TWerkhoven [~twerkhove@cpc14-linl7-2-0-cust28.sgyl.cable.virginmedia.com] has joined #openttd 07:53:05 *** kaparen [c0b06a72@ircip4.mibbit.com] has joined #openttd 07:53:16 *** Progman [~progman@p57A1ABB1.dip.t-dialin.net] has joined #openttd 07:56:59 <dihedral> i am surprised that # date -d "last month last month" actually works :-P 08:03:48 *** t4nk096 [~56313b19@webuser.thegrebs.com] has joined #openttd 08:04:02 *** t4nk096 [~56313b19@webuser.thegrebs.com] has quit [] 08:09:22 *** pjpe [ade6a119@ircip4.mibbit.com] has quit [Quit: http://www.mibbit.com ajax IRC Client] 08:13:38 *** Zuu [~Zuu@h-114-141.a98.priv.bahnhof.se] has quit [Ping timeout: 480 seconds] 08:32:59 *** snack2 [~nn@dsl-prvbrasgw1-fe05dc00-37.dhcp.inet.fi] has joined #openttd 08:33:43 *** Celestar [~dax@82.113.99.34] has joined #openttd 08:33:58 <Celestar> \o 08:36:00 <Rubidium> good morning Celestar 08:41:18 <Celestar> hello there Rubidium 08:42:29 <Qantourisc> I have trucks ... who are not always picking up goods 08:43:08 <Qantourisc> a found it :p 08:44:07 *** DayDreamer [~DayDreame@ip-86-49-59-25.net.upcbroadband.cz] has left #openttd [] 08:44:52 <Qantourisc> The downside of 64x64 stations :) 08:44:57 <Qantourisc> you might pick the wrong station :p 08:49:05 <Celestar> ... the cancel button in the world generator does not like me >P 08:49:35 <Qantourisc> :p 08:50:28 <planetmaker> Celestar: well. Worlds want to generated. Not canceled... ;-) And 'moin' 08:50:57 <Rubidium> yeah, it might be a bit hard to actually click it 08:51:02 <Rubidium> especially when the mouse jerks a bit 08:53:03 <Celestar> moin moin 08:53:18 <Celestar> the mouse is not jerking at all ... 08:59:38 <Terkhen> for me it's almost impossible to click it :P 08:59:51 <Terkhen> specially while generating rivers/industries 09:01:22 <Eddi|zuHause> maybe add [Esc] as a hotkey? 09:01:22 <Celestar> yes 09:01:31 <planetmaker> river generation on 2k^2 maps is.... lengthy :-) 09:01:35 <Celestar> CTRL+C works well enough for me :P 09:02:01 <V453000> what isnt lengthy on 2k^2 maps? :D 09:02:23 <Terkhen> realizing that you will never fill the map up 09:02:51 <Terkhen> at least for me, but I occasionally like them :P 09:03:28 <Celestar> lol 09:03:42 <planetmaker> hehe :-) 09:03:51 <V453000> if we are able to fit 1800 trains on 256x256, 2048x2048 might end up having insufficient limit :D :P 09:04:21 <Celestar> erm. 09:04:29 <Celestar> the point is maybe not to fill it completely? :P 09:04:34 <planetmaker> r23086 needs NML integration... 09:05:19 *** Brianetta [~brian@188-220-91-30.zone11.bethere.co.uk] has joined #openttd 09:05:51 <V453000> Celestar: why would you play a larger map then :| 09:06:16 *** Brianetta [~brian@188-220-91-30.zone11.bethere.co.uk] has quit [] 09:06:16 <Celestar> bigger distances? like having mountain ridges to cross? 09:06:28 <Celestar> WITHOUT flattening the whole map to 1 at some point :P 09:07:11 <V453000> bigger distances ... 512x512 provides quite distances already 09:07:20 <planetmaker> http://devs.openttd.org/~planetmaker/patches/index.php?source=nml_autorefit.diff <-- I wonder whether that'll cut it... 09:07:20 <V453000> no need to flatten :) 09:08:11 <peter1138> hmm, yeah, i can click on Abort 09:08:16 <peter1138> but it doesn't actually do anything 09:09:27 <Celestar> not much, no :P 09:09:39 <Yexo> aborting map generation works fine for me 09:11:27 <peter1138> what driver? 09:11:47 <peter1138> (if it would somehow make a difference, heh) 09:12:20 <Celestar> will you kill me if I say default? :P 09:12:20 <Yexo> no idea, I'll look 09:12:45 <peter1138> okay thing 09:12:53 <peter1138> *fine* 09:13:06 <peter1138> really i guess i meant what os ;) 09:13:13 <Celestar> linux 09:13:16 <Celestar> 3.0 09:13:16 <peter1138> doesn't work for me on linux 09:13:25 <Yexo> ah, windows for me 09:15:56 *** aglenday [~Impatient@59.167.161.74] has joined #openttd 09:17:40 <peter1138> hmm 09:17:47 <peter1138> it's not popping up the confirmation query 09:19:13 <Yexo> are you clicking on the button? the point of the mouse is still top-left, even with the changed image 09:19:22 <Yexo> it means you have to click with the "nothing" there to hit the button 09:20:01 <Celestar> good, it's not me :P 09:20:02 <peter1138> yes, the cursor changes to the normal arrow 09:21:33 <planetmaker> hm... doesn't work for me at all :S 09:21:44 <planetmaker> or I clicked wrongly 09:22:36 * Celestar resumes profiling 09:23:45 *** DDR_ [~chatzilla@142.179.78.88] has quit [Quit: ChatZilla 0.9.87 [Firefox 7.0.1/20111008085652]] 09:32:27 <peter1138> well, i have no idea 09:33:39 <Celestar> you are peter1138, how can you have no idea? :P 09:34:21 <peter1138> the query window is created 09:34:24 <peter1138> just not shown 09:34:25 <peter1138> hmm 09:46:44 <Celestar> hm. 09:47:02 <Celestar> when running 1000 ticks with michi_cc's patch on my testmap, 25% of the CPU time is AfterLoadGame :> 09:47:16 *** frosch123 [~frosch@frnk-590fdc91.pool.mediaWays.net] has joined #openttd 09:47:36 <Eddi|zuHause> then run 10000? 09:47:50 <Celestar> or subtract the 25% from the total run time :P 09:48:31 <Eddi|zuHause> or make a savegame that doesn't need conversion? 09:48:39 <Celestar> oh. 09:48:44 <Celestar> that's a good point tbh :P 09:48:54 <peter1138> :) 09:48:58 <planetmaker> :-) 09:49:12 <Celestar> didn't think of that 09:49:16 <planetmaker> i.e. just save the game in the new version ;-) 09:49:42 <Celestar> yeah, I figured that one out by myself :D 09:51:14 <Celestar> saving a 2k by 2k map is just a pita 09:51:35 <Eddi|zuHause> Celestar/michi_cc: when you rearrange map bits, can you incorporate the changes that the moreheightlevels patch needs? 09:53:05 <Celestar> which are those? 09:53:19 <Yexo> 8 bits for height instead of 4 09:53:31 <Eddi|zuHause> http://www.tt-forums.net/viewtopic.php?f=33&t=40844 09:54:19 <Celestar> I don't see that as much of a problem, but it's michi's patch :P 09:54:28 <MNIM> It would be nice to be able to have heightlevels below sea level. 09:54:47 <Eddi|zuHause> MNIM: whole different thing. 09:55:01 <Eddi|zuHause> MNIM: but that would be just an offset for the sealevel 09:55:02 <MNIM> it would eliminate the need for a (rather hacky) chunnel patch 09:55:29 <MNIM> exactly. That's why I brought it up, if you're going to rework heightlevels a bit 09:55:30 <Eddi|zuHause> MNIM: actually there is an ancient patch for that 09:55:56 <Eddi|zuHause> MNIM: that should not be mixed with more heightlevels 09:56:09 <Eddi|zuHause> MNIM: it should be a completely separate patch 09:56:13 <planetmaker> yes. It's a different thing 10:01:49 <Celestar> changing map_type.h is unfun 10:01:53 <peter1138> ah, the floods :D 10:01:57 <peter1138> heh yeah 10:02:28 <Eddi|zuHause> Celestar: make -j12 speeds things up :) 10:03:25 <Celestar> Eddi|zuHause: not more than -j4 10:03:43 <Eddi|zuHause> you need more cores :) 10:03:56 <Celestar> yeah, new laptop due in 3 months 10:04:04 <peter1138> where do i report an opengfx bug? 10:04:15 <Yexo> dev.openttdcoop.org/projects/opengfx 10:04:43 <Eddi|zuHause> http://dev.openttdcoop.org/projects/opengfx <-- clickable :) 10:05:34 <Celestar> god. this is ugly :P 10:06:19 <peter1138> ? 10:06:32 <Celestar> my slope cache :D 10:06:38 <peter1138> heh 10:06:42 <peter1138> hmm 10:06:48 <peter1138> guess i need to sign up :( 10:07:05 <Celestar> plus I fscked it up 10:10:22 <peter1138> and i'm too lazy to sign up :p 10:11:06 <planetmaker> :-( 10:12:13 <Celestar> to sign up for what? 10:12:31 <Celestar> maybe I should remote-compile ffs 10:13:41 <planetmaker> Celestar: DevZone 10:13:43 <Celestar> ah 10:17:52 <CIA-6> OpenTTD: rubidium * r23091 /trunk/src/ (52 files in 5 dirs): -Codechange: rename some Get*Z functions to Get*PixelZ functions if they return the Z in pixels (like TilePixelHeight) 10:18:13 *** hanf [~Klaus@host-89-240-248-221.as13285.net] has joined #openttd 10:20:02 <CIA-6> OpenTTD: rubidium * r23092 /trunk/src/ (7 files): -Codechange: create a non-pixel version of some of the Get*PixelZ functions, and let Get*PixelZ wrap around the new function (multiplying the Z by TILE_HEIGHT) just like TileHeight and TilePixelHeight 10:20:50 *** Brianetta [~brian@188-220-91-30.zone11.bethere.co.uk] has joined #openttd 10:21:19 <planetmaker> he. The more hightlevels patch queue seems meanwhile largely broken ;-) 10:22:05 <CIA-6> OpenTTD: rubidium * r23093 /trunk/src/ (18 files in 4 dirs): -Codechange: add a default NULL for the Z of GetTileSlope and use it 10:22:56 <Rubidium> and mostly silently 10:22:56 * Celestar is done profiling michi_cc's map 10:23:25 <CIA-6> OpenTTD: rubidium * r23094 /trunk/src/ (landscape.h road.cpp road_cmd.cpp town_cmd.cpp water_cmd.cpp): -Codechange: add a default NULL to GetFoundationSlope and use it 10:25:11 <CIA-6> OpenTTD: rubidium * r23095 /trunk/src/ai/api/ (ai_tile.cpp ai_tunnel.cpp): -Codechange: remove useless divisions/multiplications by TILE_HEIGHT for the AI API code 10:25:36 <CIA-6> OpenTTD: rubidium * r23096 /trunk/src/ (11 files): -Codechange: remove useless divisions and multiplications by TILE_HEIGHT for the snow line code 10:27:58 <CIA-6> OpenTTD: rubidium * r23097 /trunk/src/ (5 files): -Codechange: remove pointless multiplications by TILE_HEIGHT from the bridge code 10:28:09 <CIA-6> OpenTTD: rubidium * r23098 /trunk/src/ (terraform_cmd.cpp tunnel_map.cpp tunnelbridge_cmd.cpp): -Codechange: remove pointless multiplications by TILE_HEIGHT from the tunnel code 10:29:04 <CIA-6> OpenTTD: rubidium * r23099 /trunk/src/ (landscape.cpp water_cmd.cpp): -Codechange: remove pointless multiplications by TILE_HEIGHT for the water/river code 10:29:48 <CIA-6> OpenTTD: rubidium * r23100 /trunk/src/ (9 files): -Codechange: remove pointless multiplications by TILE_HEIGHT for the terraform code 10:30:50 <CIA-6> OpenTTD: rubidium * r23101 /trunk/src/ (object_cmd.cpp station_cmd.cpp town_cmd.cpp): -Codechange: remove pointless multiplications by TILE_HEIGHT from the station/object building code 10:31:24 <CIA-6> OpenTTD: rubidium * r23102 /trunk/src/ (7 files): -Codechange: remove the remaining pointless multiplications by TILE_HEIGHT 10:32:03 <CIA-6> OpenTTD: rubidium * r23103 /trunk/src/screenshot.cpp: -Codechange: replace TileHeight(x) * TILE_HEIGHT by TilePixelHeight(x) 10:33:08 * dihedral has the feeling this commit spree will be going on for a bit ^^ 10:35:26 <Celestar> well michi_cc I have good news and bad news >P 10:36:38 <dihedral> both news at the same time in an rss feed please 10:36:47 <Celestar> rofl 10:47:56 *** hanf [~Klaus@host-89-240-248-221.as13285.net] has quit [Read error: Connection reset by peer] 10:48:11 <frosch123> yay, hg pull --rebase went without conflicts \o/ 10:50:12 <Celestar> HasBit is zero based or 1 based? 10:51:01 <Rubidium> zero 10:51:35 <Celestar> tx 10:52:30 <frosch123> ottd is not programmed in fortran 10:53:17 <Celestar> lol 10:53:21 <Celestar> touche 11:01:26 *** sla_ro|master [~slaco@95.76.27.160] has quit [] 11:08:49 <CIA-6> OpenTTD: rubidium * r23104 /trunk/src/ (9 files in 2 dirs): -Codechange: prepare the vehicle/sign z for some further changes to reduce casting 11:11:56 <Celestar> Rubidium is refactoring half the codebase? 11:13:53 <Eddi|zuHause> looks like :) 11:14:30 <Eddi|zuHause> Rubidium: now do the same thing with DAY_TICKS :) 11:16:15 <frosch123> do you want to play with daylength factor 38918.9189189 ? 11:16:51 <frosch123> quite easy to play with the factor, but the date cheat does not work somehow 11:18:52 <Eddi|zuHause> damn! :p 11:19:03 <Eddi|zuHause> can we patch that? :p 11:20:31 <Celestar> Rubidium: does that make the code faster? :D 11:23:31 <Celestar> wtf 11:23:31 <Celestar> [SRC] Compiling newgrf_text.cpp 11:23:32 <Celestar> /tmp/cc1wM1ZV.s: Assembler messages: 11:23:32 <Celestar> /tmp/cc1wM1ZV.s: Fatal error: can't close newgrf_spritegroup.o: No space left on device 11:23:34 <Celestar> rofl 11:24:04 <frosch123> delete some core files 11:26:33 <Celestar> hm. 11:26:46 <Celestar> removing hiberfil.sys from backup directories helps, too 11:28:48 <CIA-6> OpenTTD: rubidium * r23105 /trunk/src/saveload/ (signs_sl.cpp vehicle_sl.cpp): -Fix (r23104): Kenobi visited me ;) 11:29:11 <Celestar> This is not the bit you are looking for 11:30:14 <CIA-6> OpenTTD: rubidium * r23106 /trunk/src/ (26 files in 2 dirs): -Codechange: pass int* to GetTileSlope and friends 11:35:48 <CIA-6> OpenTTD: rubidium * r23107 /trunk/src/ (12 files): -Codechange: let GetSlopePixelZ and TerraformTile tile type functions use int z as well 11:36:05 <peter1138> should i wait before recompiling? :p 11:36:20 <Rubidium> nah, the CF doesn't either ;) 11:36:33 <Rubidium> though there might be some spurious warnings now 11:36:47 <peter1138> /home/petern/ottd/trunk8/src/town_cmd.cpp:1938: warning: comparison between signed and unsigned integer expressions 11:36:50 <peter1138> /home/petern/ottd/trunk8/src/tunnelbridge_cmd.cpp:1343: warning: comparison between signed and unsigned integer expressions 11:37:17 <peter1138> trunk8 :D 11:37:27 <peter1138> yes, i number my working copies 11:37:35 <peter1138> that's why i can never find what i was working on :p 11:37:42 <Celestar> rofl 11:37:56 <peter1138> (my heightmap changes were in trunk2) 11:37:58 <frosch123> yup, same for me 11:38:03 <frosch123> trunkb does not compile for months 11:39:20 <Eddi|zuHause> i think i once had a MiniIN3 11:39:28 <Rubidium> pff... my naming system is so much better 11:39:38 <Rubidium> clean, clean2, clean3 11:39:42 <peter1138> :D 11:39:43 <frosch123> :p 11:39:58 <Rubidium> and none of them doesn't have no patch applied 11:40:18 <Eddi|zuHause> i have a trunk2, trunk_clean and trunkx 11:40:23 <Celestar> I currently don't have enough disk space for 8 checkouts :D 11:41:06 <Eddi|zuHause> and a paxdest, paxdest2, paxdest3, cargodist and cargodist-old 11:41:19 <Celestar> rofl 11:42:53 <Eddi|zuHause> and whatever "extra" is... 11:43:51 <Eddi|zuHause> or better: "win" 11:49:41 *** Celestar_ [~dax@82.113.121.75] has joined #openttd 11:49:50 *** Celestar is now known as Guest15778 11:49:50 *** Celestar_ is now known as Celestar 11:49:53 <Celestar> pfft 11:51:29 *** Guest15778 [~dax@82.113.99.34] has quit [Ping timeout: 480 seconds] 11:51:57 <CIA-6> OpenTTD: rubidium * r23108 /trunk/src/ (17 files): -Codechange: more uint -> int / byte -> int conversions for Z related variables 11:52:02 <Celestar> meh my cache crashes somewhere 11:57:46 <planetmaker> I couldn't resist... http://www.tt-forums.net/viewtopic.php?p=978590#p978590 :-P 11:58:24 <TrueBrain> you are mean :P 11:58:49 <Celestar> rofl 12:05:30 <Terkhen> I'm sure that they will not have any problems with updating it 12:07:35 *** DayDreamer [~DayDreame@ip-86-49-59-25.net.upcbroadband.cz] has joined #openttd 12:08:30 <peter1138> did i ask how to profile a blitter? 12:08:57 <peter1138> oh, no, i was just going to try it instead 12:09:47 <peter1138> no, doesn't work :) 12:10:11 <Eddi|zuHause> peter1138: use TIC/TOC? 12:15:06 <z-MaTRiX> hi 12:15:16 <z-MaTRiX> question (again) 12:15:55 <z-MaTRiX> anyone did background-thread asynchronous backbuffer flip in SDL ? 12:17:19 <Eddi|zuHause> sounds like the thing where you just say DoIt() 12:17:24 <z-MaTRiX> like having 60fps screen refresh rate, and unlimited mainloop performance 12:18:22 <z-MaTRiX> the waitvretrace is a huge performance impact for me ;/ 12:19:07 *** TheMask96 [~martijn@pride.vhost.ne2000.nl] has quit [Ping timeout: 480 seconds] 12:20:09 <Celestar> how's that important? 12:20:14 <Celestar> this isn't an FPS :P 12:21:35 <frosch123> maybe he thinks ottd has a trivial game state, and most computational power is needed for drawing 12:21:56 <z-MaTRiX> i'm writing a CNC controller software 12:22:27 <z-MaTRiX> but you can make it in openttd, maybe it would speed up a bit, you only lose frames... 12:22:54 <planetmaker> so you want to live-cut in real-time the ottd landscape? 12:23:04 *** TheMask96 [~martijn@envy.vhost.ne2000.nl] has joined #openttd 12:23:46 <peter1138> z-MaTRiX, don't use SDL_Flip 12:23:54 <z-MaTRiX> what do i use? 12:23:55 <z-MaTRiX> :) 12:24:05 <peter1138> something else 12:24:09 <z-MaTRiX> ;/ 12:24:17 <peter1138> oh, but that will mean it's not vsynced any more 12:24:19 <z-MaTRiX> but that draws the backbuffer to video screen 12:24:52 <z-MaTRiX> yses, was thinking about putting SDL_Flip into a child thread 12:25:12 <z-MaTRiX> i dont really care if it waits for vsync, but not in my mainloop 12:25:38 <peter1138> what else happens? 12:25:50 <z-MaTRiX> nothing more 12:25:54 <peter1138> i guess you're doing stuff that you want to run as fast as possible? 12:25:59 <z-MaTRiX> yes 12:26:08 <z-MaTRiX> and video display is secondary 12:27:07 <z-MaTRiX> was thiunking about pthread(), or one of the fork() things 12:27:49 <peter1138> separate threads, probably 12:28:08 <z-MaTRiX> no, they can share things 12:28:17 <peter1138> threads can share things 12:30:08 <peter1138> depending on your data, you either use it as it, or lock it, or use a lockfree buffer to pass stuff around 12:30:24 <peter1138> *as it is 12:33:37 <Celestar> bah foundations suck 12:34:21 <planetmaker> if you attach vacuum pumps: yes, sure 12:34:32 <planetmaker> or if you use too much material building them 12:34:59 <z-MaTRiX> peter1138<< you think about mutex_lock right? 12:36:38 <peter1138> you can lock with that, yes 12:36:47 <peter1138> i mention nothing specific 12:37:06 <peter1138> Celestar, making foundations not implicit? 12:37:23 <Celestar> peter1138: that would be great 12:37:29 <Celestar> peter1138: at least from a coding point of view 12:37:33 <peter1138> also slower :S 12:37:40 <peter1138> actually maybe not 12:37:49 <Celestar> it's not slower. 12:37:50 <peter1138> cos you wouldn't have to calculate it 12:37:57 <Celestar> it is highly likely that it is faster 12:38:50 <Celestar> at least with a caching the height of each corner in the map greatly improves the performance of GetTileSlope :P 12:40:14 <Celestar> michi_cc: are you there? 12:40:46 <peter1138> why cache the height? 12:40:54 <peter1138> why not just store the slope? 12:41:10 <Celestar> peter1138: that's what I'm just attempting to do 12:41:24 <peter1138> GetTileSlope(tile) { return _m[tile].slope; } 12:41:26 <peter1138> or somesuch 12:41:30 <Celestar> exactly. 12:41:35 <michi_cc> Celestar: Yes 12:41:47 <Celestar> I just miss to make it dirty somewhere... 12:41:47 <peter1138> "caching the height of each corner in the map" sounds different to "storing the slope" ;) 12:41:57 <Celestar> peter1138: ok 'storing the slope' :P 12:42:07 <Celestar> michi_cc: I was playing around with your patch ... 12:42:11 <peter1138> Celestar, why consider it a cache 12:42:18 <peter1138> make it authoritative 12:42:31 <Celestar> peter1138: because that is not something I can do at lunchbreak :P 12:42:33 <peter1138> basically no difference tbh :) 12:42:48 <Celestar> michi_cc: and the performance. 12:43:16 <michi_cc> Does it suck? :p 12:43:23 <Celestar> michi_cc: no. 12:43:38 <Celestar> michi_cc: well. I took a 512x512 map with > 1000 trains (some 10k vehicles). 12:43:48 <Celestar> michi_cc: the CPU time went up by 11% 12:44:06 <Celestar> michi_cc: then I took an empty 2k x 2k map. 12:44:13 <Celestar> michi_cc: there the CPU time went up by a factor of two. 12:44:32 <michi_cc> It's called trees I guess :) 12:44:38 <Celestar> michi_cc: nope. 12:44:53 <Celestar> michi_cc: two bottlenecks seem to appear. 12:45:39 <Celestar> michi_cc: 1) Finding the height of the adjacent tile in GetTileSlope. However, the tile slope can be cached in the tile. Or even stored in the tile directly to allow cliffs (and get rid of implicit foundations) 12:46:06 <michi_cc> It's the absolute increase that's much more interesting anyway, who cares if factor two means from 1% CPU to 2% CPU :) 12:46:22 <Celestar> michi_cc: I'm at fast forward :P 12:46:32 <Celestar> michi_cc: total game usage. not only the Tile Loop. 12:46:45 <michi_cc> GetTileSlope is probably the function that hurts the most from the more expensive tile lookup 12:46:50 <Celestar> michi_cc: 2) TileLoopClearHelper 12:47:04 <planetmaker> I recall correctly that zero refit costs and the autorefit flag set means autorefit is done also w/o callback, right? 12:47:12 <michi_cc> planetmaker: yes 12:47:13 <Celestar> michi_cc: finding the neighbours there. That can be cashed as well. 12:47:24 <planetmaker> sweet. No refit then anymore for pax / tourists :-) 12:47:36 <Celestar> michi_cc: just need three "cache bits" 12:48:17 <michi_cc> #2 is basically a problem because I split MP_TREE into MP_CLEAR + MP_TREE. That's not necessarily a good idea in the long run, but MP_TREE was the easiest target try the concept on. 12:48:34 <Celestar> michi_cc: ? 12:48:59 <Celestar> michi_cc: IsTileType(TILE_ADDXY(tile, 1, 0), MP_CLEAR) && IsClearGround(TILE_ADDXY(tile, 1, 0), CLEAR_FIELDS) 12:49:06 <Celestar> it really is this line. 12:49:24 <Celestar> on empty maps. 12:49:47 <Celestar> of course once you have 2k trains running about, the effect of the changed map array is minimal. 12:49:51 <Celestar> (below 10%) 12:50:33 <michi_cc> The tile loop on an empty map (with trees) is relatively a lot more expensive because all the tree tiles now consist of MP_CLEAR + MP_TREE, which implies two calls the the tile loop handle per tile index. 12:50:41 <peter1138> anyway, who cares if factor two means from 1% CPU to 2% CPU :) 12:51:23 <Celestar> peter1138: it's from 50% to 100% if you will ... 12:51:36 <Celestar> CPU time == total user time of the openttd process. 12:51:48 <michi_cc> This exacerbates things that were more expensive in the tile loop already with the old code 12:54:47 <planetmaker> isn't tree growth on a tile (except add 1st and deleting last) a nice thing which could be done separately? 12:55:15 <planetmaker> iirc it doesn't affect anything else exept looks 12:57:59 <peter1138> done separately where? 12:58:27 <peter1138> and you can pay to add trees 12:59:26 <peter1138> pay more in fact! 12:59:38 <peter1138> costs £15 for the first tree and £30 thereafter o_O 13:02:08 <Celestar> hm. 13:05:40 <Celestar> 18.13 2.82 2.82 14782991 0.00 0.00 TileLoopClearHelper(unsigned int) 13:05:43 <Celestar> 14.75 5.11 2.29 1000 0.00 0.01 RunTileLoop() 13:05:46 <Celestar> 7.02 6.20 1.09 15383644 0.00 0.00 GetTileSlope(unsigned int, unsigned int*) 13:11:25 <frosch123> planetmaker: trees also spawn trees in their neighbourhood afaik 13:15:13 <planetmaker> frosch123: yes, they do that. But it'd be a new tile 13:19:23 <Noldo> what does the tree tile handling actually do? 13:20:27 <Celestar> I don't see trees being the main problem up there. 13:20:37 <frosch123> i mimics a hypercomplex realism, which is a total waste of computation power 13:21:02 <CIA-6> OpenTTD: michi_cc * r23109 /trunk/src/economy.cpp: -Fix: Subtract auto-refit costs from the vehicle profit. 13:21:03 <frosch123> *it 13:21:37 *** blotek [~blotek@dey190.neoplus.adsl.tpnet.pl] has joined #openttd 13:24:51 <Noldo> tree growth? 13:38:33 <Celestar> bah 13:39:05 <Celestar> putting the slope into the tile is a buttload of work 13:40:37 <CIA-6> OpenTTD: rubidium * r23110 /trunk/src/ (6 files): -Codechange: let the flying altitude return ints are well 13:40:53 * Celestar thinks he should base his stuff on top of michi's patch 13:41:33 <Rubidium> Celestar: I think the major question is which slope to store. The one with or the one without foundations 13:45:01 <Celestar> Rubidium: I'm wondering that too. 13:45:08 <Celestar> Rubidium: or even both? 13:45:20 <Celestar> one stored, one cached. 13:46:39 <Rubidium> I'd just cache all 13:46:48 <Celestar> or that. 13:47:00 <Celestar> and deduce the foundations on game load? 13:47:00 <Rubidium> no need to store something that can be relatively trivially computed 13:47:27 <Celestar> yeah. 13:47:41 <Celestar> the biggest question is when to recompute. 13:47:42 <Rubidium> Celestar: well, whenever there is a need to 13:47:47 <Celestar> on access, or on change :P 13:47:52 <peter1138> when heights change 13:47:54 <Rubidium> on change 13:48:04 <peter1138> on change definitely 13:48:09 <Celestar> should be easier. 13:48:15 <peter1138> if you do it on access, you need to test if it's valid or not 13:48:18 <Celestar> because that only happens on SetTileHeight 13:48:34 <Celestar> the base slope at least. 13:48:49 <Celestar> the foundation changes whenever you build something on the tile. or the adjacent tiles. 13:49:04 <peter1138> with michi_cc's stuff, could you have MP_CLEAR, MP_FOUNDATION, MP_STUFF 13:49:18 <Celestar> well. 13:49:25 <peter1138> or is that pointless? 13:49:25 <Celestar> if we wanna have cliffs .... 13:49:36 <Celestar> I don't quite see the help of MP_FOUNDATION 13:49:53 <Celestar> or maybe, you have MP_FOUNDATION anyway for drawing the cliffs more easily. 13:50:08 <peter1138> cliffs don't need foundations 13:50:22 <Celestar> but from a drawing point of view, it's the same :P 13:50:37 <peter1138> no, cos the surface doesn't need to be flat 13:50:59 <Celestar> it doesn't have to be for foundations either? 13:51:03 <planetmaker> bah, awesome, michi_cc! It even refits to both cargos simultaneously for different wagons of the same type 13:51:05 <peter1138> true :p 13:51:12 <peter1138> but foundations are built upon the slope 13:51:23 <peter1138> hmm 13:51:26 <Celestar> hm. 13:51:26 <peter1138> can't explain :p 13:51:30 <Celestar> this needs a plan :P 13:51:31 <planetmaker> cookie for you :-) 13:51:48 <peter1138> cliffs just need a height & slope 13:51:50 <michi_cc> Thanks :) 13:52:04 <peter1138> bah 13:52:07 <peter1138> that doesn't help either 13:52:09 <peter1138> hmm 13:52:13 <Yexo> <Celestar> 18.13 2.82 2.82 14782991 0.00 0.00 TileLoopClearHelper(unsigned int) <- turns out that's already a bottleneck in trunk 13:52:35 <Yexo> on an empty 2048x2048 map, 5000 ticks took 15 seconds. After applying http://devs.openttd.org/~yexo/tileloopclearhelper.diff it went to 13 seconds 13:52:39 <Celestar> Yexo: yes, it always was. 13:52:59 <Yexo> that patch basically uses 1 bit to store "do we nee dto check for fence updates at all" 13:53:08 <Yexo> if that bit is not set, directly return from TileLoopClearHelper 13:53:21 <Yexo> needs comments ofc, but otherwise it works 13:53:22 <blathijs> Having MP_CLEAR, MP_FOUNDATION, MP_STUFF is the most clean way to do foundations, I'd say. Nice and explicit, not needing so much special casing in the code 13:53:29 <planetmaker> it really adds a lot to the game :-) 13:53:32 <Celestar> I agree with blathijs there. 13:53:41 <Celestar> Yexo: I have a similar patch :) 13:53:51 <Celestar> Yexo: just more .. hacky :P 13:53:54 <peter1138> that's what i was thinking :) 13:54:03 <Celestar> Yexo: how much does your patch reduce that function itself? 13:54:03 <michi_cc> planetmaker: You want to write some instructions on the ottd wiki? 13:54:09 <blathijs> though it does mean that there can be two "ground level" Tile* in a single tile, which might make other stuff more complicated 13:54:22 <Yexo> Celestar: no clue, I'm on windows currently 13:54:31 <Yexo> which means I can't use gprof 13:54:32 <blathijs> e.g., when building a new track, you'd be building on the MP_FOUNDATION, not on the MP_CLEAR 13:54:34 <peter1138> hmm 13:54:36 <Celestar> Yexo: I'll give it a shot 13:54:42 <planetmaker> michi_cc: you mean the player wiki? 13:54:42 <Yexo> that'd be great, thanks :) 13:54:46 <peter1138> blathijs, i just had that thought 13:54:48 <michi_cc> Yes 13:54:58 <peter1138> maybe you'd have MP_FOUNDATION, MP_CLEAR, MP_RAIL 13:55:04 <planetmaker> I rather thought about writing a posting in the NewGRF dev section of the forums 13:55:05 <peter1138> foundation can be the base 13:55:08 <Celestar> Yexo: what revision should I try, roughly? 13:55:10 <peter1138> no need for MP_CLEAR 13:55:13 <Yexo> head 13:55:19 <peter1138> hmm 13:55:27 <Celestar> Yexo: of svn? 13:55:30 <Yexo> yes 13:55:33 <planetmaker> as the actual usage depends a lot on how the newgrf uses it 13:55:34 <Celestar> cool 13:55:43 <blathijs> peter1138: The reason for having both would be that both have a different slope 13:55:48 <Yexo> it's a diff against r23108, but that's recent enough :p 13:55:52 <michi_cc> planetmaker: I won't stop you ;) 13:56:01 <blathijs> peter1138: And swapping the order might make sense, but that drops the implicit z-ordering of the Tile*'s 13:56:10 <Celestar> Yexo: even after Rubidium refactoring half the code? :P 13:56:17 <Celestar> ah lol 13:56:18 <Celestar> 2 revs down 13:56:24 <peter1138> blathijs, MP_FOUNDATION could easily just store its top slope, but yeah, special cases again :S 13:56:51 <Celestar> peter1138: blathijs: michi_cc: we should draw this somewhere :P 13:58:34 <blathijs> peter1138: I think the "problem" here is that storing things explicitely removes special cases, but different parts of the code look at the map in different wasy 13:59:14 <blathijs> peter1138: e.g., landscaping would need the slope of the actual ground, track building would need the slope of the foundation, or the ground when there is no foundation, drawing would just need the tiles in z-order, etc. 13:59:58 <blathijs> So I'm afraid that whatever method you use for storing, you'll get clean code for some of these views, and end up with special cases in others 14:00:31 <Celestar> then some places might need cleaning up 14:00:44 <blathijs> unless you go out of your way providing all kinds of abstractions (like, for each tile storing both the "ground" tile as well as the "surface" tiloe as well as the "lowest" tile, etc.) 14:05:07 <Celestar> Yexo: time spent in TileLoopClearHelper is halved. 14:05:25 <Yexo> thanks 14:07:07 <Celestar> Yexo: lemme run a longer test... 14:10:28 <Celestar> 10000 ticks 14:11:45 <Celestar> how much threading do we have meanwhile O_o 14:11:51 <Celestar> real 3m23.539s 14:11:51 <Celestar> user 4m6.119s 14:12:26 <michi_cc> Nothing except savegame compression and blitting the back buffer to screen. 14:13:06 <michi_cc> So probably disable autosave in your openttd.cfg if you haven't alredy. 14:14:16 <Celestar> what's the setting ffs :P 14:14:46 <planetmaker> http://www.tt-forums.net/viewtopic.php?f=26&t=57264 <-- michi_cc 14:19:05 *** Prof_Frink [~proffrink@5e0a9627.bb.sky.com] has joined #openttd 14:20:45 <Celestar> Yexo: that is weird. 14:20:56 <Celestar> Yexo: TileLoopClearHelper is down from 22% to 8% 14:21:02 <Celestar> Yexo: but user time is unchanged O_o 14:22:43 *** supermop [~daniel_er@rrcs-72-43-171-87.nyc.biz.rr.com] has joined #openttd 14:24:55 <Eddi|zuHause> michi_cc/planetmaker: what happens when the automatic refit changes vehicle length or somesuch? 14:25:29 <michi_cc> All hell breaks loose? 14:25:42 <Celestar> Yexo: next culprit then is GetTileZ 14:25:57 <michi_cc> Hopefully set authors demonstrate some sense. 14:26:01 <Celestar> Yexo: but storing the slope can solve that too. 14:26:01 <Eddi|zuHause> michi_cc: i mean: are there measures to prevent that? 14:26:04 <Yexo> Celestar: I'm first going to do a radically different approach to the fences 14:27:00 <Celestar> Yexo: hehe 14:27:22 <michi_cc> No, there aren't, just as there isn't a check against refitting to passengers in a truck stop. 14:27:31 <Celestar> lol 14:27:35 <Celestar> there is 14:27:39 <Celestar> called "profit" 14:28:04 <Eddi|zuHause> michi_cc: other thing: imagine cargo subtype refitting like "14 wagons" to "12 wagons", it might be useful to return negative refit cost then 14:28:05 <michi_cc> I'm simply hoping set authors have at least a bit of sanity left and just don't implement that. 14:28:30 <Eddi|zuHause> (i mean inside a depot now) 14:28:54 <Celestar> back in a few 14:30:30 <frosch123> yeah, heqs trams will probably fail with autorefit 14:30:46 <Belugas> hello 14:30:55 <Eddi|zuHause> frosch123: why? it should keep the subtype 14:31:10 <frosch123> i don't think it does currently 14:31:29 <michi_cc> The CB result could be redefined as a signed integer if really needed. 14:31:47 <Eddi|zuHause> i would imagine the same checks as while autoreplacing apply 14:32:03 <michi_cc> Hmm, that's a bug actually. I guess a CT_AUTO_REFIT should use the subtype of the vehicle and not the one of the refit order. 14:32:04 <Eddi|zuHause> while at it: that check was somehow missing on cloning 14:32:37 *** AndroUser [~androirc@82.113.121.75] has joined #openttd 14:32:37 <Eddi|zuHause> i.e. cloning of a vehicle didn't keep the subtype (last time i checked) 14:33:20 <frosch123> planetmaker: bit 14, not 15 btw :) 14:33:54 *** Celestar is now known as Guest15791 14:33:55 *** AndroUser is now known as Celestar 14:33:59 <planetmaker> eh, yes. 0-based :-) 14:33:59 <frosch123> michi_cc: do might want to call ConsistChanged with same_length = true 14:34:05 <frosch123> *you 14:34:19 <frosch123> (for trains) 14:34:22 <Celestar> sucks on a touchscreen 14:35:13 <frosch123> RoadVehUpdateCache for rv 14:36:57 *** Guest15791 [~dax@82.113.121.75] has quit [Ping timeout: 480 seconds] 14:37:01 <Celestar> yexo how different? 14:37:29 <Yexo> storing 4 fences in field tiles instead of storing the fences on the south border on clear and tree tiles 14:38:11 <Celestar> sounds clever ;) 14:38:39 <Celestar> this client sucks for irc 14:43:23 <Celestar> so you have to check the neighboring tiles only on modification. 14:44:15 <Celestar> GetTileZ wants something like that as well 14:44:30 <michi_cc> frosch123: something like http://paste.openttdcoop.org/show/706/ ? 14:44:52 <Eddi|zuHause> [04.11.2011 13:34] <planetmaker> or if you use too much material building them <-- you spent too much time near the LHC protesters? :p 14:45:06 <planetmaker> :-P 14:45:26 <Celestar> lol 14:45:44 <__ln__> https://lkml.org/lkml/2011/11/3/110 14:46:00 <frosch123> michi_cc: maybe GetBestFittingSubType 14:46:18 <frosch123> preserving the raw value of subtype makes no sense 14:46:27 <Celestar> brb 14:46:36 *** Celestar [~androirc@82.113.121.75] has quit [Quit: AndroIRC - Android IRC Client ( http://www.androirc.com )] 14:48:11 <michi_cc> That function looks like it needs to be used very carefully if you have only a single vehicle 14:49:04 *** pjpe [ade6a119@ircip1.mibbit.com] has joined #openttd 14:49:21 <frosch123> i guess it needs splitting in the half 14:49:27 <frosch123> you only need the second part 14:49:36 <Eddi|zuHause> well, you could make that a requirement for autorefitting: the subtypes must match 14:49:45 *** Celestar [~androirc@82.113.121.75] has joined #openttd 14:50:05 <Eddi|zuHause> which should be the case for heqs trams 14:50:16 * Rubidium wonders to what extent michi broke yacd with this autorefit at station ;) 14:50:40 <planetmaker> :-P 14:51:02 <Eddi|zuHause> Rubidium: that should be easy to fix, just add a link for all cargos, not just the currently refitted cargo 14:51:23 <Celestar> is yacd active? 14:51:37 <Eddi|zuHause> stalled 14:51:44 <Eddi|zuHause> due to performance issues 14:51:49 <planetmaker> Eddi|zuHause: requiring the subtype to match imho is not really that useful... 14:52:21 <Eddi|zuHause> planetmaker: why? you want to make sure that it does not autorefit from 4 wagons to 15 wagons 14:52:31 <planetmaker> why shouldn't i refit from oil (barrels) to lumber (furniture) 14:52:40 <frosch123> michi_cc: + new_subtype = v->subtype; <- that should also be before the DC_QUERY_COST 14:52:57 <Eddi|zuHause> planetmaker: i mean the subtype numbers, not the subtype strings 14:53:12 <peter1138> __ln__ :) 14:53:13 <planetmaker> yes. So? 14:53:25 <planetmaker> why would I need them to match between cargos? 14:53:43 <planetmaker> you do that via callback, I'd say 14:54:09 <planetmaker> I could as well have subtype 1 (cargo A) have 15 wagons and subtype 1 (cargo B) be 7 wagons 14:54:31 <Eddi|zuHause> planetmaker: exactly, and that should be forbidden 14:54:46 <planetmaker> why? 14:55:01 <frosch123> Eddi|zuHause: the refitcost callback can forbit autorefit depending on the subtype 14:55:02 <Eddi|zuHause> planetmaker: because vehicles cannot _ever_ change length outside a depot 14:55:10 <frosch123> so, everything can be done by the grf 14:55:18 <Eddi|zuHause> frosch123: but it cannot suggest an alternate subtype 14:55:45 <planetmaker> the question is: will it try all subtypes for a cargo? 14:55:48 <planetmaker> It probably should 14:55:57 <planetmaker> starting with subtype1 14:56:11 <frosch123> planetmaker: then it would not compare the texts, but leave all to the callback 14:56:17 <Eddi|zuHause> starting with the current subtype, or with the subtype with the same name? 14:56:20 <planetmaker> frosch123: exactly 14:56:28 <frosch123> which means you always have to use the callback if you have subtypes 14:56:29 <michi_cc> frosch123: best fitting subtype + length check for trains/rvs: http://paste.openttdcoop.org/show/707/ 14:56:30 <planetmaker> which imho is better 14:56:57 *** kaparen [c0b06a72@ircip4.mibbit.com] has quit [Quit: http://www.mibbit.com ajax IRC Client] 14:58:29 <z-MaTRiX> btw 14:58:47 <michi_cc> Rubidium: Why do you think I implemented a refit to any available cargo? ;) 14:59:06 <frosch123> michi_cc: looks fine to me 14:59:30 <z-MaTRiX> none of you guys were thinking about eliminating the need of waiting for display/network and other things that cause all input devices to lock until done? 14:59:55 <frosch123> remains whether that the refit-capacity callback shall be allowed to choose a different subtype 15:00:02 <z-MaTRiX> if display is VERY slow, then mouse cursor hangs too 15:00:05 <frosch123> but imo, something for later when needed 15:04:01 <CIA-6> OpenTTD: michi_cc * r23111 /trunk/src/ (economy.cpp vehicle_func.h vehicle_gui.cpp): -Fix: Keep subtype when automatically choosing the cargo for auto-refitting. 15:04:05 <CIA-6> OpenTTD: michi_cc * r23112 /trunk/src/ (6 files): -Codechange: Check if vehicle chain lengths stays constant when auto-refitting. 15:06:53 <planetmaker> z-MaTRiX: our days have 24h only and we have a RL. Patches to improve the game are always welcome 15:07:16 <planetmaker> we usually don't lack ideas of what could be better. We lack time 15:10:21 <Rubidium> michi_cc: to have a better reason to not continue with yacd than "performance sucks"? :) 15:13:03 <z-MaTRiX> planetmaker<< ok i see your point :) 15:13:17 <z-MaTRiX> maybe i can finally help then ? 15:13:21 <z-MaTRiX> in something 15:13:41 <planetmaker> of course. Feel free to give it a shot 15:13:58 <planetmaker> everyone improves those parts s/he takes joy in improving :-) 15:14:27 <z-MaTRiX> right now i'm @ mutexland sightseeing 15:15:06 *** Celestar [~androirc@82.113.121.75] has quit [Quit: AndroIRC - Android IRC Client ( http://www.androirc.com )] 15:17:03 *** Zuu [~Zuu@h-114-141.a98.priv.bahnhof.se] has joined #openttd 15:17:48 *** glx [glx@2a01:e35:2f59:c7c0:59e5:79d8:f03d:a513] has joined #openttd 15:17:51 *** mode/#openttd [+v glx] by ChanServ 15:44:43 *** Sigvatr [sig@42.241.117.155] has joined #openttd 15:44:46 <Sigvatr> hello 15:45:09 <Sigvatr> do i need the original tt to use as graphics or can i play with some in development graphics sets? 15:45:16 *** pugi [~pugi@dyndsl-091-096-062-026.ewe-ip-backbone.de] has joined #openttd 15:45:45 <Sacro> Sigvatr: you don't need the original tt 15:45:56 <Sigvatr> ok 15:45:56 <Sacro> you could use the original ttd however, or there are free graphics sets 15:46:09 <Sigvatr> are any free sets complete and not crap? 15:46:13 <Sacro> http://bundles.openttdcoop.org/opengfx/releases/ 15:46:24 <Sacro> complete, yes, crap however is subjective 15:46:58 <__ln__> Sigvatr: if the quality doesn't satisfy you, you can make a better one yourself. 15:46:59 <Sigvatr> i've never played tt at all before, will people get mad at me if i try to play multiplayer 15:47:02 *** snack2 [~nn@dsl-prvbrasgw1-fe05dc00-37.dhcp.inet.fi] has quit [Ping timeout: 480 seconds] 15:47:22 <Sigvatr> well i used to make buildings in SCURK like 15 years ago so who knows 15:51:14 <Sigvatr> what directory do i put opengfx-0.3.7 in 15:54:21 <Yexo> see openttd's readme.txt 15:55:24 *** snack2 [~nn@dsl-prvbrasgw1-fe05dc00-37.dhcp.inet.fi] has joined #openttd 15:55:33 <Sigvatr> since i've never played tt at all before will i infuriate anyone if i play multiplayer the first time 15:56:36 <Yexo> I don't see why 15:57:38 *** Biolunar [mahdi@77.8.61.113] has joined #openttd 15:58:08 <Sigvatr> wow everything is so tiny on my 1920x1080 monitor 15:58:11 <Sigvatr> like ants 16:14:38 <peter1138> depends on the size :p 16:15:58 <Sigvatr> i have been playing my first multiplayer game for about 10 minutes 16:16:03 <Sigvatr> but i couldn't do anything 16:16:11 <Sigvatr> and everyone was trying to figure out why i couldn't build any roads 16:16:13 <Sigvatr> turns out i was spectating 16:17:14 <planetmaker> lol 16:17:42 <planetmaker> but happens :-) 16:19:24 <Eddi|zuHause> what's the relative difference in pixel size between 640x480 on 14" and 1920x1080 on 27"? 16:19:28 *** snack2 [~nn@dsl-prvbrasgw1-fe05dc00-37.dhcp.inet.fi] has quit [Ping timeout: 480 seconds] 16:19:52 <V453000> would have to count it I guess :) 16:22:05 *** valhallasw [~valhallas@vpn91.ext.espci.fr] has joined #openttd 16:22:21 <Yexo> isn't that simply 1.5? 16:22:47 <Yexo> (1920/640) / (27"/14") ? 16:22:57 <Eddi|zuHause> no 16:22:59 <peter1138> no 16:23:04 <Eddi|zuHause> because the ratio is different 16:23:10 *** DabuYuTimeOut [DabuYu@128.250.79.189] has quit [] 16:23:13 <Yexo> oh, right 16:23:34 <V453000> count total amount of pixels of each screen and just divide it by 27 or 14? 16:23:47 <Eddi|zuHause> 14": ~57dpi, 27": ~82dpi 16:23:54 *** pugi [~pugi@dyndsl-091-096-062-026.ewe-ip-backbone.de] has quit [Quit: I reject your reality and substitute my own] 16:24:51 <Eddi|zuHause> around factor 0.7 16:25:13 <Yexo> so my 1.5 wasn't that far off :p 16:26:19 <Eddi|zuHause> so everything is 30% smaller 16:28:46 <Eddi|zuHause> "That will occur at roughly the time the much anticipated Keynesian fireworks begin..." <- anyone has a clue what that refers to? 16:30:09 <Prof_Frink> Fireworks? Tomorrow. 16:31:43 *** |Jeroen| [~jeroen@d5152B25B.access.telenet.be] has joined #openttd 16:32:09 *** DayDreamer [~DayDreame@ip-86-49-59-25.net.upcbroadband.cz] has left #openttd [] 16:34:21 <Eddi|zuHause> not exactly helpful :p 16:34:39 <Qantourisc> How do you prevent a city from growing over your tracks ? 16:34:49 <Qantourisc> more specifcly the ones of your tracks 16:37:37 <Eddi|zuHause> what do you mean "over your tracks"? 16:37:49 <Prof_Frink> Play TTO and build monorails. Or, more usefully, put something alongside your tracks that they can't cross. 16:38:00 *** sla_ro|master [~slaco@95.76.27.160] has joined #openttd 16:38:27 <Eddi|zuHause> don't need TTO for that. you can prevent road crossings by newgrf 16:38:50 <Eddi|zuHause> e.g. the highspeed tracktypes in nutracks 16:39:17 <V453000> which is pretty stupid tbh ... realism 16:39:24 * Prof_Frink builds a rack for his nuts. 16:39:25 <V453000> it is much better to prevent towns from build roads themselves 16:39:41 <V453000> from building* 16:40:32 <Prof_Frink> Or use the preset grids and match the road positions with signal spacing 16:40:57 <Qantourisc> Prof_Frink: hmmm ok thanks 16:41:11 * Rubidium wonders why nobody made a setting for disallowing towns to build roads 16:41:40 <V453000> Rubidium: ? :d 16:42:58 <Rubidium> well, everything that's being said here kinda implies that they is no such setting 16:43:47 <Rubidium> or is it already too late for me? 16:44:01 <V453000> kinda implies :) 16:44:04 <V453000> not entirely :p 16:52:12 <peter1138> just place your signals sensibly :) 16:52:20 <peter1138> path signals, of course :p 16:52:22 <Zuu> Prof_Frink: That's something an AI could do quite easily as eg. a road AI need to take care about the grid size to not cut of the town grid with a road station. 16:52:50 <Zuu> So instead of matching road station location against the grid, it would match rail signs. :-) 16:52:58 <b_jonas> the openttdcoop wiki also suggests an innovative way to stop towns from building level crossings over your rail 16:53:06 <Zuu> s/signs/signals/ 16:53:19 <b_jonas> namely to build your rail track on sloped square with foundations 16:53:28 <b_jonas> which can be made invisible if you have two tracks parallel 16:53:30 <V453000> also a way :) 16:53:46 <V453000> but in general you totally do not want towns to be able to build roads on their own 16:53:48 <b_jonas> I can't find that on the wiki now for some reason 16:53:59 <peter1138> you don't? 16:54:00 <V453000> it is in the tutorial savegame, not sure if anywhere else 16:54:01 <peter1138> i do 16:54:16 <V453000> peter1138: why? You cannot control the game that way 16:54:26 <V453000> towns you do not need to grow just grow .. why 16:54:28 <Prof_Frink> Exactly. 16:54:32 <peter1138> i don't want to control the game that way 16:54:46 <peter1138> i don't like the grid layouts either 16:54:54 <V453000> grid layouts suck indeed 16:55:16 <V453000> how is that cosmetic look related though? :) 16:55:55 <b_jonas> V453000++ indeed: http://wiki.openttdcoop.org/Tutorial_Savegame_Mainline#1.3_Anti-Roadcross-Trackpart 16:56:19 <b_jonas> well, I usually just try to be in good standing with every town I'm near so I can remove any road crossing they build 16:56:42 <b_jonas> and I guess you could also build a sign just where the town wants to cross the road 16:57:07 <b_jonas> or you can build a bridge for the town 16:58:15 <V453000> if I play a cargo based game, I do not want cities to grow. If I play a passenger based game, I want towns to grow but I want to make the roads so that they fit the train city network well, otherwise towns just screw it up. So cutting rights of the towns is the way for me :P 16:58:47 <b_jonas> I rather just build roads for the towns in advance 16:59:08 <b_jonas> that's good for aesthetics, and also means I can always remove the roads if I need to 16:59:12 <b_jonas> because I own them 16:59:19 <peter1138> i just transport stuff 16:59:49 <michi_cc> peter1138: What a novel idea :p 17:00:29 <Prof_Frink> peter1138 is oldschool 17:00:52 <V453000> oldschool can be respectable, carelessness not :p 17:05:05 *** mahmoud [~KEM@ALyon-158-1-31-22.w90-29.abo.wanadoo.fr] has joined #openttd 17:12:48 *** Devroush [~dennis@ip-213-49-110-4.dsl.scarlet.be] has joined #openttd 17:13:23 *** Alberth [~hat@a82-95-164-127.adsl.xs4all.nl] has joined #openttd 17:13:26 *** mode/#openttd [+o Alberth] by ChanServ 17:13:36 *** Neon [~Neon@dslb-094-219-016-094.pools.arcor-ip.net] has joined #openttd 17:14:56 *** KritiK [~Maxim@95-25-61-201.broadband.corbina.ru] has joined #openttd 17:21:29 *** kaparen [~aabbcc@c-b063e455.94-17-64736c10.cust.bredbandsbolaget.se] has joined #openttd 17:23:18 <Sigvatr> i can't join some games because of NEWGRF mismatch 17:23:20 <Sigvatr> how do i fix that 17:23:33 <Yexo> click on nwegrf button and try to download the newgrfs 17:23:48 <Yexo> if not all of them are available in the online content system you'll ahve to look for them yourself 17:23:51 <Yexo> in which case: good luck 17:28:58 *** Devroush [~dennis@ip-213-49-110-4.dsl.scarlet.be] has quit [Ping timeout: 480 seconds] 17:33:27 *** Brianetta [~brian@188-220-91-30.zone11.bethere.co.uk] has quit [Remote host closed the connection] 17:36:37 *** pjpe [ade6a119@ircip1.mibbit.com] has quit [Quit: http://www.mibbit.com ajax IRC Client] 17:50:48 *** pjpe [ade6a119@ircip1.mibbit.com] has joined #openttd 18:02:02 *** Adambean [AdamR@82.hosts.reece-eu.net] has joined #openttd 18:02:55 *** Pulec [~pulec@static-cl093181068250.unet.cz] has joined #openttd 18:05:18 *** Prof_Frink [~proffrink@5e0a9627.bb.sky.com] has quit [Ping timeout: 480 seconds] 18:15:33 *** Devroush [~dennis@178-119-153-135.access.telenet.be] has joined #openttd 18:15:36 *** Elukka [Elukka@89-166-103-135.bb.dnainternet.fi] has quit [Read error: Connection reset by peer] 18:16:04 *** Elukka [Elukka@89-166-103-135.bb.dnainternet.fi] has joined #openttd 18:20:37 *** pugi [~pugi@dyndsl-091-096-062-026.ewe-ip-backbone.de] has joined #openttd 18:25:10 *** |Jeroen| [~jeroen@d5152B25B.access.telenet.be] has quit [Quit: oO] 18:38:18 *** Wolf01 [~wolf01@host48-239-dynamic.16-79-r.retail.telecomitalia.it] has joined #openttd 18:39:12 <Wolf01> hello 18:39:54 <__ln__> bonsoir Wolf01 18:39:55 <Alberth> hi 18:41:21 *** Brianetta [~brian@188-220-91-30.zone11.bethere.co.uk] has joined #openttd 18:43:55 *** Chris_Booth [~chatzilla@client-82-31-14-195.midd.adsl.virginmedia.com] has joined #openttd 18:44:07 *** Mucht [~Martin@chello084115143107.3.graz.surfer.at] has joined #openttd 18:45:05 <CIA-6> OpenTTD: translators * r23113 /trunk/src/lang/ (6 files): (log message trimmed) 18:45:05 <CIA-6> OpenTTD: -Update from WebTranslator v3.0: 18:45:05 <CIA-6> OpenTTD: dutch - 17 changes by habell 18:45:05 <CIA-6> OpenTTD: english_US - 17 changes by Rubidium 18:45:05 <CIA-6> OpenTTD: finnish - 17 changes by jpx_ 18:45:06 <CIA-6> OpenTTD: french - 17 changes by glx 18:45:06 <CIA-6> OpenTTD: german - 17 changes by planetmaker 18:45:34 <Chris_Booth> evening 18:58:06 *** aglenday [~Impatient@59.167.161.74] has quit [Quit: Leaving] 19:09:23 *** JVassie [~James@2.27.86.104] has joined #openttd 19:11:38 *** mahmoud [~KEM@ALyon-158-1-31-22.w90-29.abo.wanadoo.fr] has quit [Ping timeout: 480 seconds] 19:24:09 *** mahmoud [~KEM@ALyon-158-1-128-217.w90-29.abo.wanadoo.fr] has joined #openttd 19:26:06 *** andythenorth [~Andy@cpc15-aztw25-2-0-cust3.aztw.cable.virginmedia.com] has joined #openttd 19:28:42 *** Chris_Booth [~chatzilla@client-82-31-14-195.midd.adsl.virginmedia.com] has quit [Ping timeout: 480 seconds] 19:50:44 *** andythenorth [~Andy@cpc15-aztw25-2-0-cust3.aztw.cable.virginmedia.com] has quit [Quit: andythenorth] 19:57:21 *** DOUK [~KEM@ALyon-158-1-37-117.w90-29.abo.wanadoo.fr] has joined #openttd 19:59:59 *** SamCat [~Samantha@c-67-188-95-34.hsd1.ca.comcast.net] has joined #openttd 20:00:20 <SamCat> Hello 20:01:21 *** mahmoud [~KEM@ALyon-158-1-128-217.w90-29.abo.wanadoo.fr] has quit [Ping timeout: 480 seconds] 20:01:36 *** snack2 [~nn@dsl-prvbrasgw1-fe05dc00-37.dhcp.inet.fi] has joined #openttd 20:02:59 <Rubidium> evening 20:05:16 <SamCat> I need help keeping industries alive. I've been doing everything I can to keep the station ratings high but certain industries, namely oil, just seem to thoroughly hate me to the point where a well connected to a highly rated station might up and die on me for reasons I can't figure out! 20:05:47 <SamCat> I usually don't have trouble keeping stations at a rating above 70% 20:05:56 <planetmaker> oil wells die 20:06:18 <SamCat> so, you're saying that they just die because they die and I'm not actually doing anything wrong? 20:06:37 *** andythenorth [~Andy@cpc15-aztw25-2-0-cust3.aztw.cable.virginmedia.com] has joined #openttd 20:07:03 <planetmaker> yes 20:07:08 <SamCat> oh, okay... 20:07:26 <planetmaker> oil wells (in the default game) cannot increase production and only decrease it. 20:07:31 <planetmaker> Thus they'll eventually die 20:07:38 <SamCat> oh... 20:07:51 <SamCat> no other industry is like that, though, right? 20:07:51 <planetmaker> you could use something like opengfx+industries which allows you to modify that behaviour 20:08:08 <SamCat> ah! I will! 20:08:20 <SamCat> that behavior makes 64x64 maps thoroughly unplayable 20:08:29 <SamCat> at least when you're trying to do a freight game 20:09:07 <planetmaker> :-) 64^2 is a challange indeed 20:09:32 <planetmaker> but other industries should not do that. Unless I have a hole in my memory 20:09:51 <SamCat> okay 20:10:02 <SamCat> my last game, though, I was monitoring my oil well constantly and it was going up sometimes 20:10:09 <SamCat> does it just tend downwards then? 20:10:40 <SamCat> it was just going "oh look, we increased the production OH MY GOD 50% DOWN!" 20:11:55 * andythenorth does read grf v8 20:12:51 *** TheMask96 [~martijn@envy.vhost.ne2000.nl] has quit [Ping timeout: 480 seconds] 20:13:04 <Alberth> SamCat: the idea is that you gradually switch to oilrigs 20:13:15 <Rubidium> SamCat: it probably went up with a very small amount without a news message 20:13:42 <SamCat> ooooooh, oil rigs! 20:13:54 <Rubidium> SamCat: that's because in a month the primary industries will produce 8 or 9 times, which explains those small fluctuations 20:14:12 <SamCat> okay, that explains things then, thanks 20:14:41 <SamCat> so much for my half-million-dollar mountain railroad >.< 20:14:54 <andythenorth> are checks for water tiles now 'solved'? 20:15:17 <andythenorth> e.g wrt detecting explicitly coast, river etc 20:16:55 *** TheMask96 [~martijn@sloth.vhost.ne2000.nl] has joined #openttd 20:19:04 <andythenorth> could cb36 cargo capacity cb be 'solved' for grf v8? 20:19:16 <andythenorth> or is that unrelated to a version bump? 20:19:19 <SamCat> oil wells are never generated on a new map, are they? 20:19:20 <andythenorth> seems like a behaviour change 20:21:54 <Rubidium> SamCat: oil wells are generated when starting a new map, but you must start the game before a particular date I don't know by heart 20:22:30 * andythenorth wonders about vehicle visual effect 20:22:46 <SamCat> er, I meant oil rigs >.< 20:23:10 <Alberth> they are not created before 1960 iirc 20:23:31 <SamCat> Alberth: Ah, that explains things. I almost always start my games in 1850 20:24:16 <andythenorth> so cb10 for visual effect is being deprecated, and that will be added to cb36 for v8? 20:24:38 * andythenorth will give â¬1 to the first person to guess what comes next... 20:25:15 * Alberth writes a line at the #openttd channel 20:25:20 *** DayDreamer [~DayDreame@ip-86-49-59-25.net.upcbroadband.cz] has joined #openttd 20:25:58 <Rubidium> andythenorth: deprecation of callback 11? 20:26:05 <andythenorth> ooh 20:26:12 * andythenorth didn't think of that 20:26:15 <Alberth> Hmm, 1960 is not mentioned at our wiki 20:26:32 * andythenorth had more control over visual effects in mind 20:26:44 <andythenorth> probably by looping over a cb 20:27:04 <andythenorth> but if cb36 is the new way for controlling visual effect, that might not be possible :( 20:27:11 * andythenorth would be sad :( 20:27:40 <Alberth> shouldn't we try to reduce #cb calls? 20:28:21 *** DDR_ [~chatzilla@142.179.78.88] has joined #openttd 20:29:21 <andythenorth> it will be sad if ships can never have smoke 20:29:54 <peter1138> never? 20:30:20 <andythenorth> never 20:30:30 <andythenorth> never / less likely /s 20:30:37 <peter1138> why less likely? 20:32:08 <andythenorth> we're not likely to move visual effect to cb36 for v8, remove cb10, then add some new cb for extended visual effect control? 20:32:16 <andythenorth> or am I making an wrong assumption 20:32:18 <andythenorth> ? 20:32:40 <planetmaker> changing the property via cb36 20:32:43 * andythenorth is assuming that cb36 explodes if we make it do too many things 20:32:46 <planetmaker> that can be done any time 20:33:40 <andythenorth> in a backwards compatible way? 20:35:02 <planetmaker> how backward compatible? 20:35:15 <planetmaker> in grfv7 you can keep using cb10/11/12 20:36:19 <b_jonas> callbacks can explode if you overuse them? 20:36:55 <b_jonas> let's do that, you wanted graphical effects, an explosion is always a good idea for that 20:36:58 <peter1138> no. might get ever so slightly slower though. 20:37:29 <SamCat> does anyone know if UKRS2 is compatible with FIRS? 20:39:48 <Alberth> SamCat: the readme states the set as compatible 20:40:06 <Alberth> http://dev.openttdcoop.org/projects/firs/repository/entry/docs/readme.ptxt line 117 20:40:33 *** TWerkhoven2 [~twerkhove@cpc14-linl7-2-0-cust28.sgyl.cable.virginmedia.com] has joined #openttd 20:40:45 *** Chris_Booth [~chatzilla@client-82-31-14-195.midd.adsl.virginmedia.com] has joined #openttd 20:40:52 <SamCat> Alberth: Thanks, I don't know how I managed to miss that 20:41:22 <Alberth> you need to unpack the tar file to read it ? 20:42:14 <SamCat> heh, yeah 20:47:23 *** TWerkhoven [~twerkhove@cpc14-linl7-2-0-cust28.sgyl.cable.virginmedia.com] has quit [Ping timeout: 480 seconds] 20:48:53 *** Chris_Booth [~chatzilla@client-82-31-14-195.midd.adsl.virginmedia.com] has quit [Ping timeout: 480 seconds] 20:52:44 *** blotek_ [~blotek@dey190.neoplus.adsl.tpnet.pl] has joined #openttd 20:52:44 *** blotek [~blotek@dey190.neoplus.adsl.tpnet.pl] has quit [Read error: Connection reset by peer] 20:56:11 <frosch123> andythenorth: you have a good point in not deprecating the visual effect callback 20:56:23 <frosch123> http://devs.openttd.org/~frosch/diffs/capacitymultipliers.diff <- anyway, for you cb 36 capacity issue 21:02:33 *** mahmoud [~KEM@ALyon-158-1-70-213.w90-29.abo.wanadoo.fr] has joined #openttd 21:04:44 <CIA-6> OpenTTD: michi_cc * r23114 /trunk/src/ (7 files): -Feature: [NewGRF] Ambient sound effect callback. 21:06:21 *** DOUK [~KEM@ALyon-158-1-37-117.w90-29.abo.wanadoo.fr] has quit [Ping timeout: 480 seconds] 21:08:08 <andythenorth> planetmaker: backward compatible, as in - backward compatibility will block us extending visual effect support until grf v9 if we don't do it now 21:08:13 <andythenorth> or we have to introduce a new cb 21:08:27 <andythenorth> it seems odd to deprecate one and introduce a new one 21:08:34 <andythenorth> it makes the documentation at least confusing 21:09:57 <andythenorth> frosch123: can I just trust that capacity fix works? :) I've read it, but it's too much for me to take in :) 21:10:17 <andythenorth> or I can compile it... 21:10:32 <frosch123> it moves the 1 cargo = 2 goods = 2 mailbags = 4 passengers into the cargospec, adds a cargo property, and finally calls cb 15 also in purchase list 21:11:02 <andythenorth> :) 21:11:03 <frosch123> when the flag is set, the default capacity property always describes the capacity of a cargo with multiplier 0x100 21:11:41 <frosch123> so, when a vehicle grf does only use cb36, and not 15; then the capacity is controlled by the industry grf defining the cargos 21:12:04 <planetmaker> oh, that way round 21:12:24 <planetmaker> so the cargo sets volume and space? 21:12:32 <frosch123> kind of 21:12:46 <planetmaker> that naming would make it maybe clearer :-) 21:13:01 *** Sigvatr [sig@42.241.117.155] has quit [] 21:13:14 <planetmaker> hm... 21:13:48 <frosch123> in other words, it makes the cets solution unneccessary and bad :p 21:17:54 <andythenorth> so the vehicle sets capacity as weight? 21:18:07 *** Adambean [AdamR@82.hosts.reece-eu.net] has quit [Quit: Gone fishing] 21:18:12 <andythenorth> and the grf defining cargo specifies how many units per t? 21:18:16 <andythenorth> (or how many t per unit) 21:20:32 <frosch123> vehicle sets capacity in tons of coal 21:20:59 <frosch123> the cargo defines how many units of it match the weight/volume of that 21:22:26 <frosch123> there is also a weight per unit of cargo property. but that is only used for the weight of the loaded vehicle, not for the capacity 21:24:19 *** DOUK [~KEM@ALyon-158-1-16-208.w90-29.abo.wanadoo.fr] has joined #openttd 21:24:32 <andythenorth> frosch123: will it make your chart simpler to draw? :) 21:24:35 <andythenorth> or worse? :) 21:25:15 <frosch123> if i draw it in the same chart, it will become more complicated :p 21:25:26 <andythenorth> can we have a new chart? 21:25:27 <frosch123> need to check how the new chart looks like 21:25:37 <frosch123> yeah, should be a new chart 21:25:41 <andythenorth> option 1. use the simple chart. option 2. use the insane chart 21:26:01 <andythenorth> I know the current chart was lots of work, but all it tells me is that I don't like the current situation :) 21:26:13 <andythenorth> well not all, but that's my main conclusion 21:26:22 <frosch123> it will be definitely a separate chart :) 21:27:44 *** supermop [~daniel_er@rrcs-72-43-171-87.nyc.biz.rr.com] has quit [Remote host closed the connection] 21:27:55 *** supermop [~daniel_er@rrcs-72-43-171-87.nyc.biz.rr.com] has joined #openttd 21:28:57 *** mahmoud [~KEM@ALyon-158-1-70-213.w90-29.abo.wanadoo.fr] has quit [Ping timeout: 480 seconds] 21:32:01 *** Alberth [~hat@a82-95-164-127.adsl.xs4all.nl] has left #openttd [] 21:32:02 <andythenorth> http://www.railpictures.net/viewphoto.php?id=379965&nseq=42 21:33:04 <andythenorth> an awesome picture 21:33:15 <andythenorth> also - vehicles-in-vehicles ;) 21:34:29 <SamCat> Is the coach there for the truckers or something? 21:35:04 <frosch123> according to the descripton, it is :p 21:35:33 <valhallasw> andythenorth: now I want pictures of a train carrying trucks carrying model trains carrying trucks 21:35:36 <valhallasw> ad infinitum :p 21:35:41 <frosch123> looked like containers at first, so the passenger coach confused me 21:35:42 <SamCat> *facepalms herself* there's a caption >.< 21:36:12 <SamCat> Valhallasw: that would be awesome 21:36:36 <SamCat> I heard that SimuTrans has an iPhone app now which makes me really tempted to get an iPhone so I can play with trains while ON a train 21:36:36 * andythenorth has a lego truck which has cargo of lego boxes.... 21:36:42 <andythenorth> in the box is the truck... 21:36:45 <SamCat> but then I just realized that I have a laptop 21:36:49 <SamCat> I'm such a dork >.< 21:36:50 <andythenorth> iphone sucks 21:37:10 <SamCat> heh, yeah 21:37:28 <SamCat> and I have a laptop so I can play OpenTTD (which I very much prefer) on a bigger screen on the train! 21:37:32 *** Celestar [~dax@dslb-188-099-119-082.pools.arcor-ip.net] has joined #openttd 21:38:16 <frosch123> shit, that photo is from the future 21:38:46 <frosch123> who wants to go with me to hungary, and watch that train in a week? 21:39:19 <andythenorth> that would be good 21:39:23 <frosch123> i assume it will drive there at 11:11 21:39:47 <andythenorth> it's an 11 reccuring? 21:39:47 <frosch123> Eddi|zuHause: oh, so dbset 0.9 is released in one week 21:40:01 <andythenorth> my baby might come on 11:11:11 21:40:04 <andythenorth> maybe 21:40:20 <SamCat> congrats, Andythenorth 21:40:29 <andythenorth> or it might come later 21:40:31 <andythenorth> or earlier 21:40:33 <andythenorth> who knows 21:40:39 <andythenorth> the last one showed up early 21:40:44 <SamCat> you could still have the birthday party on 11:11:11 21:40:56 <SamCat> Rule of Cool applies to real life, too, you know! 21:41:47 <planetmaker> oh, another andy clone? :-) 21:44:34 <andythenorth> you should see the current one 21:44:38 <andythenorth> he's a train obsessive 21:44:51 <SamCat> yeah? 21:44:55 <andythenorth> he says 'choo choo' in his sleep 21:45:03 <SamCat> ha! that's awesome 21:45:12 <andythenorth> he's the I like trains kid: http://www.youtube.com/watch?v=hHkKJfcBXcw 21:45:18 <andythenorth> he's only 19 months old 21:45:28 <frosch123> better than obsessive about sawmills? 21:45:55 <andythenorth> better than that yes 21:46:04 <V453000> OMG 21:46:09 <SamCat> sawmills are still pretty cool 21:46:25 <andythenorth> better than obsessive about the correct lighting direction in a 17 year old game 21:46:31 * andythenorth is fixing lighting in HEQS 21:46:40 *** Celestar [~dax@dslb-188-099-119-082.pools.arcor-ip.net] has quit [Ping timeout: 480 seconds] 21:46:55 <SamCat> you say 17 year old game like it's a bad thing 21:47:17 <planetmaker> he :-) 21:47:26 <andythenorth> it's just a slightly odd obsession 21:47:38 * andythenorth likes grf v8 21:47:48 <andythenorth> means OpenTTD Is Clearly Not Dying ® 21:48:01 <andythenorth> will the patch support grf v8? :o 21:48:44 <planetmaker> ask an active TTDP developer ;-) 21:50:16 <peter1138> teehee 21:50:49 <SamCat> <3 the pixel art, though 21:50:53 <V453000> how many people do fit in that group pm? :d 21:54:48 <frosch123> at least a non-negative number 21:56:13 <V453000> :D 21:56:27 <SamCat> 0 is a non-negative number... 21:57:52 <SamCat> neither is i 21:57:57 <SamCat> even though it kinda is! 21:58:02 <SamCat> *cue spooky music* 22:02:33 *** mahmoud [~KEM@ALyon-158-1-35-111.w90-29.abo.wanadoo.fr] has joined #openttd 22:07:02 *** DOUK [~KEM@ALyon-158-1-16-208.w90-29.abo.wanadoo.fr] has quit [Ping timeout: 480 seconds] 22:09:17 * andythenorth -> bed 22:09:20 *** andythenorth [~Andy@cpc15-aztw25-2-0-cust3.aztw.cable.virginmedia.com] has quit [Quit: andythenorth] 22:09:24 <planetmaker> sleep well... 22:13:07 <Rubidium> planetmaker: your timing seems to be a bit off today ;) 22:13:37 <planetmaker> yeah. time over-compensated it seems 22:13:44 <planetmaker> *time shift 22:15:33 <Terkhen> hi 22:15:58 <SamCat> Hi! 22:16:27 * Terkhen is a lazy translator 22:17:35 <SamCat> heh 22:19:25 *** sla_ro|master [~slaco@95.76.27.160] has quit [Ping timeout: 480 seconds] 22:19:35 <planetmaker> hehe 22:25:24 <Eddi|zuHause> planetmaker/frosch123: in https://secure.openttd.org/wiki/Frosch/GRF_Version_8#Callback_144 there is missing explanation for the "T" part 22:26:48 <frosch123> landscape class 22:26:57 <frosch123> just like in the current format 22:27:14 <Eddi|zuHause> i don't actually know the current format :) 22:27:24 <frosch123> added :) 22:28:57 <SamCat> I think I'm going to go take a nap 22:29:03 <SamCat> thanks everyone for your help! <3 22:29:36 *** SamCat [~Samantha@c-67-188-95-34.hsd1.ca.comcast.net] has left #openttd [] 22:31:57 <CIA-6> OpenTTD: rubidium * r23115 /trunk/src/network/ (network_admin.cpp network_admin.h): -Fix [FS#4813]: allow accessing the server's client info as well in the admin network (dihedral) 22:34:16 *** pugi [~pugi@dyndsl-091-096-062-026.ewe-ip-backbone.de] has quit [Quit: I reject your reality and substitute my own] 22:36:19 *** HerzogDeXtEr [~Flex@i59F6AE24.versanet.de] has joined #openttd 22:36:19 *** HerzogDeXtEr1 [~Flex@i59F6B4F4.versanet.de] has quit [Read error: Connection reset by peer] 22:40:06 *** frosch123 [~frosch@frnk-590fdc91.pool.mediaWays.net] has quit [Remote host closed the connection] 22:41:54 <Terkhen> good night 22:42:48 *** Chris_Booth [~chatzilla@client-82-31-14-195.midd.adsl.virginmedia.com] has joined #openttd 22:43:01 *** Mucht [~Martin@chello084115143107.3.graz.surfer.at] has quit [Remote host closed the connection] 22:43:57 *** Chris_Booth [~chatzilla@client-82-31-14-195.midd.adsl.virginmedia.com] has quit [] 22:48:51 *** Kurimus [~stabbity@dsl-tkubrasgw3-fe93dd00-34.dhcp.inet.fi] has quit [] 22:48:53 *** Sigvatr [sig@42.241.98.11] has joined #openttd 22:48:54 <Sigvatr> hey 22:49:03 <Sigvatr> is it possible to link your line to someone elses and send a train to crash into theirs 22:51:26 <Eddi|zuHause> no 22:52:12 <Sigvatr> damn 22:52:17 <Sigvatr> i thought i was very clever 22:52:35 <Sigvatr> are there ways of harming other people's business asides from competition? 22:54:06 <Eddi|zuHause> the only legal way is to buy exclusive rights in a town 22:54:12 *** George|2 [~George@212.113.107.39] has joined #openttd 22:54:13 *** George is now known as Guest15838 22:54:13 *** George|2 is now known as George 22:54:21 *** Guest15838 [~George@212.113.107.39] has quit [Ping timeout: 480 seconds] 22:54:35 <Sigvatr> well i mean illegal too 22:54:50 <Eddi|zuHause> there are no illegal ways. 22:58:02 <Sigvatr> what 22:58:05 <Sigvatr> that would make the game much more fun 22:58:18 <Eddi|zuHause> only if you are 12 22:58:28 <Sigvatr> but i'm 25 22:59:26 <CIA-6> OpenTTD: michi_cc * r23116 /trunk/src/ (tree_cmd.cpp water_cmd.cpp): -Fix (r23114): Ambient sound effect callback was called for unsupported tile types. 23:06:29 *** Progman [~progman@p57A1ABB1.dip.t-dialin.net] has quit [Remote host closed the connection] 23:07:10 *** valhalla1w [~valhallas@193.52.24.37] has joined #openttd 23:10:14 *** supermop [~daniel_er@rrcs-72-43-171-87.nyc.biz.rr.com] has left #openttd [] 23:13:04 <Wolf01> 'night 23:13:07 *** Wolf01 [~wolf01@host48-239-dynamic.16-79-r.retail.telecomitalia.it] has quit [Quit: Once again the world is quick to bury me.] 23:13:11 *** snack2 [~nn@dsl-prvbrasgw1-fe05dc00-37.dhcp.inet.fi] has quit [] 23:13:59 <CIA-6> OpenTTD: yexo * r23117 /trunk/ (bin/ai/regression/regression.txt src/script/squirrel.cpp): -Fix: [NoAI] calling require() to include a file gave you 100.000 opcodes for free 23:14:10 *** valhallasw [~valhallas@vpn91.ext.espci.fr] has quit [Ping timeout: 480 seconds] 23:19:52 <CIA-6> OpenTTD: rubidium * r23118 /trunk/ (10 files in 4 dirs): -Feature: [NoAI] Allow AIs to query the amount of remaining operations for the current tick 23:21:25 <Eddi|zuHause> <frosch123> in other words, it makes the cets solution unneccessary and bad :p <-- i didn't like the solution either, but someone pushed me towards it... 23:24:58 *** Elukka [Elukka@89-166-103-135.bb.dnainternet.fi] has quit [] 23:39:57 *** DOUK [~KEM@ALyon-158-1-107-162.w90-29.abo.wanadoo.fr] has joined #openttd 23:42:19 *** Cybertinus [~Cybertinu@tunnel3304.ipv6.xs4all.nl] has quit [Remote host closed the connection] 23:44:11 *** mahmoud [~KEM@ALyon-158-1-35-111.w90-29.abo.wanadoo.fr] has quit [Ping timeout: 480 seconds] 23:46:31 *** Devroush [~dennis@178-119-153-135.access.telenet.be] has quit [] 23:46:35 <CIA-6> OpenTTD: michi_cc * r23119 /trunk/src/ (3 files in 2 dirs): -Fix: [Win32] Don't show a crash/assertion message box for a GUI-less video driver. 23:48:20 <planetmaker> good night 23:55:04 *** DayDreamer [~DayDreame@ip-86-49-59-25.net.upcbroadband.cz] has quit [Read error: Connection reset by peer]