Log for #openttd on 4th November 2011:
Times are UTC Toggle Colours
00:04:34  *** welshdragon [] has joined #openttd
00:07:30  *** Progman [] has quit [Remote host closed the connection]
00:19:02  *** George|2 [~George@] 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 [] has quit [Quit: He who can look into the future, has a brighter future to look into]
00:25:32  *** Guest15747 [~George@] 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 [] 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 [] has quit [Quit: TschÌß]
01:08:46  <frosch123> night
01:08:50  *** frosch123 [] 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 [] 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 [] has quit [Quit: ajax IRC Client]
01:28:21  *** pjpe [] 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 [] has quit [Ping timeout: 480 seconds]
03:25:51  *** rhaeder1 [] has joined #openttd
03:30:26  *** rhaeder [] has quit [Ping timeout: 480 seconds]
04:41:53  *** Kurimus [] has joined #openttd
05:17:39  *** mahmoud [] has quit [Quit: Quitte]
05:46:40  *** supermop_ [] has quit [Quit: supermop_]
05:51:59  *** Elukka [] has joined #openttd
05:55:39  *** Eddi|zuHause [] has quit [Remote host closed the connection]
05:56:04  *** Eddi|zuHause [] 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@] has joined #openttd
06:24:45  <dihedral> greetings
06:30:58  *** Prof_Frink [] has quit [Ping timeout: 480 seconds]
07:02:44  *** Cybertinus [] has joined #openttd
07:11:54  *** andythenorth [] has joined #openttd
07:20:21  *** DabuYuTimeOut [DabuYu@] has joined #openttd
07:23:00  <Terkhen> good morning
07:23:31  *** DabuYu [DabuYu@] has quit [Ping timeout: 480 seconds]
07:23:48  *** sla_ro|master [~slaco@] has joined #openttd
07:25:10  *** DayDreamer [] has joined #openttd
07:27:45  *** JVassie [~James@] has quit [Ping timeout: 480 seconds]
07:28:45  *** Zuu [] has joined #openttd
07:33:50  <planetmaker> moin
07:33:53  <dihedral> :-)
07:34:41  *** andythenorth [] has quit [Quit: andythenorth]
07:52:48  *** TWerkhoven [] has joined #openttd
07:53:05  *** kaparen [] has joined #openttd
07:53:16  *** Progman [] has joined #openttd
07:56:59  <dihedral> i am surprised that # date -d "last month last month" actually works :-P
08:03:48  *** t4nk096 [] has joined #openttd
08:04:02  *** t4nk096 [] has quit []
08:09:22  *** pjpe [] has quit [Quit: ajax IRC Client]
08:13:38  *** Zuu [] has quit [Ping timeout: 480 seconds]
08:32:59  *** snack2 [] has joined #openttd
08:33:43  *** Celestar [~dax@] 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 [] 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 [] has joined #openttd
09:05:51  <V453000> Celestar: why would you play a larger map then :|
09:06:16  *** Brianetta [] 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> <-- 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@] 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@] 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 [] 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>
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>
10:04:43  <Eddi|zuHause> <-- 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 [] 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 [] 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 [] 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@] 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@] 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@] 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... :-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 [] 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 [] 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 [] 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 [] 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 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> <-- michi_cc
14:19:05  *** Prof_Frink [] 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 [] 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@] 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@] 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 ?
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__>
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@] has quit [Quit: AndroIRC - Android IRC Client ( )]
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 [] 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@] 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:
14:56:30  <planetmaker> which imho is better
14:56:57  *** kaparen [] has quit [Quit: 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@] has quit [Quit: AndroIRC - Android IRC Client ( )]
15:17:03  *** Zuu [] 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@] 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 [] 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>
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 [] 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 [] 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@] 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 [] has quit [Ping timeout: 480 seconds]
16:19:52  <V453000> would have to count it I guess :)
16:22:05  *** valhallasw [] 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@] 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 [] 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| [] has joined #openttd
16:32:09  *** DayDreamer [] 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@] 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:
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 [] has joined #openttd
17:12:48  *** Devroush [] has joined #openttd
17:13:23  *** Alberth [] has joined #openttd
17:13:26  *** mode/#openttd [+o Alberth] by ChanServ
17:13:36  *** Neon [] has joined #openttd
17:14:56  *** KritiK [] has joined #openttd
17:21:29  *** kaparen [] 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 [] has quit [Ping timeout: 480 seconds]
17:33:27  *** Brianetta [] has quit [Remote host closed the connection]
17:36:37  *** pjpe [] has quit [Quit: ajax IRC Client]
17:50:48  *** pjpe [] has joined #openttd
18:02:02  *** Adambean [] has joined #openttd
18:02:55  *** Pulec [] has joined #openttd
18:05:18  *** Prof_Frink [] has quit [Ping timeout: 480 seconds]
18:15:33  *** Devroush [] has joined #openttd
18:15:36  *** Elukka [] has quit [Read error: Connection reset by peer]
18:16:04  *** Elukka [] has joined #openttd
18:20:37  *** pugi [] has joined #openttd
18:25:10  *** |Jeroen| [] has quit [Quit: oO]
18:38:18  *** Wolf01 [] has joined #openttd
18:39:12  <Wolf01> hello
18:39:54  <__ln__> bonsoir Wolf01
18:39:55  <Alberth> hi
18:41:21  *** Brianetta [] has joined #openttd
18:43:55  *** Chris_Booth [] has joined #openttd
18:44:07  *** Mucht [] 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@] has quit [Quit: Leaving]
19:09:23  *** JVassie [~James@] has joined #openttd
19:11:38  *** mahmoud [] has quit [Ping timeout: 480 seconds]
19:24:09  *** mahmoud [] has joined #openttd
19:26:06  *** andythenorth [] has joined #openttd
19:28:42  *** Chris_Booth [] has quit [Ping timeout: 480 seconds]
19:50:44  *** andythenorth [] has quit [Quit: andythenorth]
19:57:21  *** DOUK [] has joined #openttd
19:59:59  *** SamCat [] has joined #openttd
20:00:20  <SamCat> Hello
20:01:21  *** mahmoud [] has quit [Ping timeout: 480 seconds]
20:01:36  *** snack2 [] 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 [] 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 [] 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 [] 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 [] 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@] 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>  line 117
20:40:33  *** TWerkhoven2 [] has joined #openttd
20:40:45  *** Chris_Booth [] 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 [] has quit [Ping timeout: 480 seconds]
20:48:53  *** Chris_Booth [] has quit [Ping timeout: 480 seconds]
20:52:44  *** blotek_ [] has joined #openttd
20:52:44  *** blotek [] 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> <- anyway, for you cb 36 capacity issue
21:02:33  *** mahmoud [] 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 [] 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@] 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 [] 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 [] 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 [] has quit [Remote host closed the connection]
21:27:55  *** supermop [] has joined #openttd
21:28:57  *** mahmoud [] has quit [Ping timeout: 480 seconds]
21:32:01  *** Alberth [] has left #openttd []
21:32:02  <andythenorth>
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 [] 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:
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 [] 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 [] has joined #openttd
22:07:02  *** DOUK [] has quit [Ping timeout: 480 seconds]
22:09:17  * andythenorth -> bed
22:09:20  *** andythenorth [] 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@] has quit [Ping timeout: 480 seconds]
22:19:35  <planetmaker> hehe
22:25:24  <Eddi|zuHause> planetmaker/frosch123: in 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 [] 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 [] has quit [Quit: I reject your reality and substitute my own]
22:36:19  *** HerzogDeXtEr [] has joined #openttd
22:36:19  *** HerzogDeXtEr1 [] has quit [Read error: Connection reset by peer]
22:40:06  *** frosch123 [] has quit [Remote host closed the connection]
22:41:54  <Terkhen> good night
22:42:48  *** Chris_Booth [] has joined #openttd
22:43:01  *** Mucht [] has quit [Remote host closed the connection]
22:43:57  *** Chris_Booth [] has quit []
22:48:51  *** Kurimus [] has quit []
22:48:53  *** Sigvatr [sig@] 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@] 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@] 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 [] has quit [Remote host closed the connection]
23:07:10  *** valhalla1w [~valhallas@] has joined #openttd
23:10:14  *** supermop [] has left #openttd []
23:13:04  <Wolf01> 'night
23:13:07  *** Wolf01 [] has quit [Quit: Once again the world is quick to bury me.]
23:13:11  *** snack2 [] 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 [] 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 [] has quit []
23:39:57  *** DOUK [] has joined #openttd
23:42:19  *** Cybertinus [] has quit [Remote host closed the connection]
23:44:11  *** mahmoud [] has quit [Ping timeout: 480 seconds]
23:46:31  *** Devroush [] 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 [] has quit [Read error: Connection reset by peer]

Powered by YARRSTE version: svn-trunk