Back to Home / #openttd / 2011 / 11 / Prev Day | Next Day
#openttd IRC Logs for 2011-11-04

---Logopened Fri Nov 04 00:00:54 2011
00:42-!-Kurimus [] has joined #openttd
01:18-!-mahmoud [] has quit [Quit: Quitte]
01:47-!-supermop_ [] has quit [Quit: supermop_]
01:52-!-Elukka [] has joined #openttd
01:56-!-Eddi|zuHause [] has quit [Remote host closed the connection]
01:56-!-Eddi|zuHause [] has joined #openttd
02:05<CIA-6>OpenTTD: rubidium * r23090 /trunk/src/landscape.cpp: -Codechange: use map accessors instead of directly accessing the map (mhl)
02:16-!-JVassie [~James@] has joined #openttd
02:31-!-Prof_Frink [] has quit [Ping timeout: 480 seconds]
03:03-!-Cybertinus [] has joined #openttd
03:12-!-andythenorth [] has joined #openttd
03:20-!-DabuYuTimeOut [DabuYu@] has joined #openttd
03:23<Terkhen>good morning
03:23-!-DabuYu [DabuYu@] has quit [Ping timeout: 480 seconds]
03:24-!-sla_ro|master [~slaco@] has joined #openttd
03:25-!-DayDreamer [] has joined #openttd
03:28-!-JVassie [~James@] has quit [Ping timeout: 480 seconds]
03:29-!-Zuu [] has joined #openttd
03:35-!-andythenorth [] has quit [Quit: andythenorth]
03:53-!-TWerkhoven [] has joined #openttd
03:53-!-kaparen [] has joined #openttd
03:53-!-Progman [] has joined #openttd
03:57<dihedral>i am surprised that # date -d "last month last month" actually works :-P
04:04-!-t4nk096 [] has joined #openttd
04:04-!-t4nk096 [] has quit []
04:09-!-pjpe [] has quit [Quit: ajax IRC Client]
04:14-!-Zuu [] has quit [Ping timeout: 480 seconds]
04:33-!-snack2 [] has joined #openttd
04:34-!-Celestar [~dax@] has joined #openttd
04:36<Rubidium>good morning Celestar
04:41<Celestar>hello there Rubidium
04:42<Qantourisc>I have trucks ... who are not always picking up goods
04:43<Qantourisc>a found it :p
04:44-!-DayDreamer [] has left #openttd []
04:45<Qantourisc>The downside of 64x64 stations :)
04:45<Qantourisc>you might pick the wrong station :p
04:49<Celestar>... the cancel button in the world generator does not like me >P
04:50<@planetmaker>Celestar: well. Worlds want to generated. Not canceled... ;-) And 'moin'
04:51<Rubidium>yeah, it might be a bit hard to actually click it
04:51<Rubidium>especially when the mouse jerks a bit
04:53<Celestar>moin moin
04:53<Celestar>the mouse is not jerking at all ...
05:00<Terkhen>for me it's almost impossible to click it :P
05:00<Terkhen>specially while generating rivers/industries
05:01<Eddi|zuHause>maybe add [Esc] as a hotkey?
05:01<@planetmaker>river generation on 2k^2 maps is.... lengthy :-)
05:01<Celestar>CTRL+C works well enough for me :P
05:02<V453000>what isnt lengthy on 2k^2 maps? :D
05:02<Terkhen>realizing that you will never fill the map up
05:03<Terkhen>at least for me, but I occasionally like them :P
05:04<@planetmaker>hehe :-)
05:04<V453000>if we are able to fit 1800 trains on 256x256, 2048x2048 might end up having insufficient limit :D :P
05:04<Celestar>the point is maybe not to fill it completely? :P
05:04<@planetmaker>r23086 needs NML integration...
05:05-!-Brianetta [] has joined #openttd
05:06<V453000>Celestar: why would you play a larger map then :|
05:06-!-Brianetta [] has quit []
05:06<Celestar>bigger distances? like having mountain ridges to cross?
05:06<Celestar>WITHOUT flattening the whole map to 1 at some point :P
05:07<V453000>bigger distances ... 512x512 provides quite distances already
05:07<@planetmaker> <-- I wonder whether that'll cut it...
05:07<V453000>no need to flatten :)
05:08<@peter1138>hmm, yeah, i can click on Abort
05:08<@peter1138>but it doesn't actually do anything
05:09<Celestar>not much, no :P
05:10<@Yexo>aborting map generation works fine for me
05:11<@peter1138>what driver?
05:12<@peter1138>(if it would somehow make a difference, heh)
05:12<Celestar>will you kill me if I say default? :P
05:12<@Yexo>no idea, I'll look
05:13<@peter1138>okay thing
05:13<@peter1138>really i guess i meant what os ;)
05:13<@peter1138>doesn't work for me on linux
05:13<@Yexo>ah, windows for me
05:16-!-aglenday [~Impatient@] has joined #openttd
05:18<@peter1138>it's not popping up the confirmation query
05:19<@Yexo>are you clicking on the button? the point of the mouse is still top-left, even with the changed image
05:19<@Yexo>it means you have to click with the "nothing" there to hit the button
05:20<Celestar>good, it's not me :P
05:20<@peter1138>yes, the cursor changes to the normal arrow
05:21<@planetmaker>hm... doesn't work for me at all :S
05:22<@planetmaker>or I clicked wrongly
05:23*Celestar resumes profiling
05:24-!-DDR_ [~chatzilla@] has quit [Quit: ChatZilla 0.9.87 [Firefox 7.0.1/20111008085652]]
05:32<@peter1138>well, i have no idea
05:34<Celestar>you are peter1138, how can you have no idea? :P
05:34<@peter1138>the query window is created
05:34<@peter1138>just not shown
05:47<Celestar>when running 1000 ticks with michi_cc's patch on my testmap, 25% of the CPU time is AfterLoadGame :>
05:47-!-frosch123 [] has joined #openttd
05:48<Eddi|zuHause>then run 10000?
05:48<Celestar>or subtract the 25% from the total run time :P
05:48<Eddi|zuHause>or make a savegame that doesn't need conversion?
05:49<Celestar>that's a good point tbh :P
05:49<Celestar>didn't think of that
05:49<@planetmaker>i.e. just save the game in the new version ;-)
05:50<Celestar>yeah, I figured that one out by myself :D
05:51<Celestar>saving a 2k by 2k map is just a pita
05:51<Eddi|zuHause>Celestar/michi_cc: when you rearrange map bits, can you incorporate the changes that the moreheightlevels patch needs?
05:53<Celestar>which are those?
05:53<@Yexo>8 bits for height instead of 4
05:54<Celestar>I don't see that as much of a problem, but it's michi's patch :P
05:54<MNIM>It would be nice to be able to have heightlevels below sea level.
05:55<Eddi|zuHause>MNIM: whole different thing.
05:55<Eddi|zuHause>MNIM: but that would be just an offset for the sealevel
05:55<MNIM>it would eliminate the need for a (rather hacky) chunnel patch
05:55<MNIM>exactly. That's why I brought it up, if you're going to rework heightlevels a bit
05:55<Eddi|zuHause>MNIM: actually there is an ancient patch for that
05:56<Eddi|zuHause>MNIM: that should not be mixed with more heightlevels
05:56<Eddi|zuHause>MNIM: it should be a completely separate patch
05:56<@planetmaker>yes. It's a different thing
06:02<Celestar>changing map_type.h is unfun
06:02<@peter1138>ah, the floods :D
06:02<@peter1138>heh yeah
06:02<Eddi|zuHause>Celestar: make -j12 speeds things up :)
06:03<Celestar>Eddi|zuHause: not more than -j4
06:04<Eddi|zuHause>you need more cores :)
06:04<Celestar>yeah, new laptop due in 3 months
06:04<@peter1138>where do i report an opengfx bug?
06:05<Eddi|zuHause> <-- clickable :)
06:05<Celestar>god. this is ugly :P
06:06<Celestar>my slope cache :D
06:07<@peter1138>guess i need to sign up :(
06:07<Celestar>plus I fscked it up
06:10<@peter1138>and i'm too lazy to sign up :p
06:12<Celestar>to sign up for what?
06:12<Celestar>maybe I should remote-compile ffs
06:14<@planetmaker>Celestar: DevZone
06:18<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)
06:18-!-hanf [] has joined #openttd
06:20<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
06:21-!-Brianetta [] has joined #openttd
06:21<@planetmaker>he. The more hightlevels patch queue seems meanwhile largely broken ;-)
06:22<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
06:23<Rubidium>and mostly silently
06:23*Celestar is done profiling michi_cc's map
06:23<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
06:25<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
06:26<CIA-6>OpenTTD: rubidium * r23096 /trunk/src/ (11 files): -Codechange: remove useless divisions and multiplications by TILE_HEIGHT for the snow line code
06:28<CIA-6>OpenTTD: rubidium * r23097 /trunk/src/ (5 files): -Codechange: remove pointless multiplications by TILE_HEIGHT from the bridge code
06:28<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
06:29<CIA-6>OpenTTD: rubidium * r23099 /trunk/src/ (landscape.cpp water_cmd.cpp): -Codechange: remove pointless multiplications by TILE_HEIGHT for the water/river code
06:30<CIA-6>OpenTTD: rubidium * r23100 /trunk/src/ (9 files): -Codechange: remove pointless multiplications by TILE_HEIGHT for the terraform code
06:31<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
06:31<CIA-6>OpenTTD: rubidium * r23102 /trunk/src/ (7 files): -Codechange: remove the remaining pointless multiplications by TILE_HEIGHT
06:32<CIA-6>OpenTTD: rubidium * r23103 /trunk/src/screenshot.cpp: -Codechange: replace TileHeight(x) * TILE_HEIGHT by TilePixelHeight(x)
06:33*dihedral has the feeling this commit spree will be going on for a bit ^^
06:35<Celestar>well michi_cc I have good news and bad news >P
06:37<dihedral>both news at the same time in an rss feed please
06:48-!-hanf [] has quit [Read error: Connection reset by peer]
06:48<frosch123>yay, hg pull --rebase went without conflicts \o/
06:50<Celestar>HasBit is zero based or 1 based?
06:52<frosch123>ottd is not programmed in fortran
07:01-!-sla_ro|master [~slaco@] has quit []
07:09<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
07:12<Celestar>Rubidium is refactoring half the codebase?
07:14<Eddi|zuHause>looks like :)
07:14<Eddi|zuHause>Rubidium: now do the same thing with DAY_TICKS :)
07:16<frosch123>do you want to play with daylength factor 38918.9189189 ?
07:17<frosch123>quite easy to play with the factor, but the date cheat does not work somehow
07:19<Eddi|zuHause>damn! :p
07:19<Eddi|zuHause>can we patch that? :p
07:20<Celestar>Rubidium: does that make the code faster? :D
07:23<Celestar>[SRC] Compiling newgrf_text.cpp
07:23<Celestar>/tmp/cc1wM1ZV.s: Assembler messages:
07:23<Celestar>/tmp/cc1wM1ZV.s: Fatal error: can't close newgrf_spritegroup.o: No space left on device
07:24<frosch123>delete some core files
07:27<Celestar>removing hiberfil.sys from backup directories helps, too
07:29<CIA-6>OpenTTD: rubidium * r23105 /trunk/src/saveload/ (signs_sl.cpp vehicle_sl.cpp): -Fix (r23104): Kenobi visited me ;)
07:29<Celestar>This is not the bit you are looking for
07:30<CIA-6>OpenTTD: rubidium * r23106 /trunk/src/ (26 files in 2 dirs): -Codechange: pass int* to GetTileSlope and friends
07:36<CIA-6>OpenTTD: rubidium * r23107 /trunk/src/ (12 files): -Codechange: let GetSlopePixelZ and TerraformTile tile type functions use int z as well
07:36<@peter1138>should i wait before recompiling? :p
07:36<Rubidium>nah, the CF doesn't either ;)
07:36<Rubidium>though there might be some spurious warnings now
07:37<@peter1138>/home/petern/ottd/trunk8/src/town_cmd.cpp:1938: warning: comparison between signed and unsigned integer expressions
07:37<@peter1138>/home/petern/ottd/trunk8/src/tunnelbridge_cmd.cpp:1343: warning: comparison between signed and unsigned integer expressions
07:37<@peter1138>trunk8 :D
07:37<@peter1138>yes, i number my working copies
07:37<@peter1138>that's why i can never find what i was working on :p
07:38<@peter1138>(my heightmap changes were in trunk2)
07:38<frosch123>yup, same for me
07:38<frosch123>trunkb does not compile for months
07:39<Eddi|zuHause>i think i once had a MiniIN3
07:39<Rubidium>pff... my naming system is so much better
07:40<Rubidium>clean, clean2, clean3
07:40<Rubidium>and none of them doesn't have no patch applied
07:40<Eddi|zuHause>i have a trunk2, trunk_clean and trunkx
07:40<Celestar>I currently don't have enough disk space for 8 checkouts :D
07:41<Eddi|zuHause>and a paxdest, paxdest2, paxdest3, cargodist and cargodist-old
07:43<Eddi|zuHause>and whatever "extra" is...
07:44<Eddi|zuHause>or better: "win"
07:50-!-Celestar_ [~dax@] has joined #openttd
07:50-!-Celestar is now known as Guest15778
07:50-!-Celestar_ is now known as Celestar
07:51-!-Guest15778 [~dax@] has quit [Ping timeout: 480 seconds]
07:52<CIA-6>OpenTTD: rubidium * r23108 /trunk/src/ (17 files): -Codechange: more uint -> int / byte -> int conversions for Z related variables
07:52<Celestar>meh my cache crashes somewhere
07:58<@planetmaker>I couldn't resist... :-P
07:58<TrueBrain>you are mean :P
08:05<Terkhen>I'm sure that they will not have any problems with updating it
08:07-!-DayDreamer [] has joined #openttd
08:08<@peter1138>did i ask how to profile a blitter?
08:09<@peter1138>oh, no, i was just going to try it instead
08:10<@peter1138>no, doesn't work :)
08:10<Eddi|zuHause>peter1138: use TIC/TOC?
08:15<z-MaTRiX>question (again)
08:16<z-MaTRiX>anyone did background-thread asynchronous backbuffer flip in SDL ?
08:17<Eddi|zuHause>sounds like the thing where you just say DoIt()
08:17<z-MaTRiX>like having 60fps screen refresh rate, and unlimited mainloop performance
08:18<z-MaTRiX>the waitvretrace is a huge performance impact for me ;/
08:19-!-TheMask96 [] has quit [Ping timeout: 480 seconds]
08:20<Celestar>how's that important?
08:20<Celestar>this isn't an FPS :P
08:22<frosch123>maybe he thinks ottd has a trivial game state, and most computational power is needed for drawing
08:22<z-MaTRiX>i'm writing a CNC controller software
08:22<z-MaTRiX>but you can make it in openttd, maybe it would speed up a bit, you only lose frames...
08:23<@planetmaker>so you want to live-cut in real-time the ottd landscape?
08:23-!-TheMask96 [] has joined #openttd
08:24<@peter1138>z-MaTRiX, don't use SDL_Flip
08:24<z-MaTRiX>what do i use?
08:24<@peter1138>something else
08:24<@peter1138>oh, but that will mean it's not vsynced any more
08:24<z-MaTRiX>but that draws the backbuffer to video screen
08:25<z-MaTRiX>yses, was thinking about putting SDL_Flip into a child thread
08:25<z-MaTRiX>i dont really care if it waits for vsync, but not in my mainloop
08:26<@peter1138>what else happens?
08:26<z-MaTRiX>nothing more
08:26<@peter1138>i guess you're doing stuff that you want to run as fast as possible?
08:26<z-MaTRiX>and video display is secondary
08:27<z-MaTRiX>was thiunking about pthread(), or one of the fork() things
08:28<@peter1138>separate threads, probably
08:28<z-MaTRiX>no, they can share things
08:28<@peter1138>threads can share things
08:30<@peter1138>depending on your data, you either use it as it, or lock it, or use a lockfree buffer to pass stuff around
08:30<@peter1138>*as it is
08:34<Celestar>bah foundations suck
08:34<@planetmaker>if you attach vacuum pumps: yes, sure
08:34<@planetmaker>or if you use too much material building them
08:35<z-MaTRiX>peter1138<< you think about mutex_lock right?
08:37<@peter1138>you can lock with that, yes
08:37<@peter1138>i mention nothing specific
08:37<@peter1138>Celestar, making foundations not implicit?
08:37<Celestar>peter1138: that would be great
08:37<Celestar>peter1138: at least from a coding point of view
08:37<@peter1138>also slower :S
08:38<@peter1138>actually maybe not
08:38<Celestar>it's not slower.
08:38<@peter1138>cos you wouldn't have to calculate it
08:38<Celestar>it is highly likely that it is faster
08:39<Celestar>at least with a caching the height of each corner in the map greatly improves the performance of GetTileSlope :P
08:40<Celestar>michi_cc: are you there?
08:41<@peter1138>why cache the height?
08:41<@peter1138>why not just store the slope?
08:41<Celestar>peter1138: that's what I'm just attempting to do
08:41<@peter1138>GetTileSlope(tile) { return _m[tile].slope; }
08:41<@peter1138>or somesuch
08:42<+michi_cc>Celestar: Yes
08:42<Celestar>I just miss to make it dirty somewhere...
08:42<@peter1138>"caching the height of each corner in the map" sounds different to "storing the slope" ;)
08:42<Celestar>peter1138: ok 'storing the slope' :P
08:42<Celestar>michi_cc: I was playing around with your patch ...
08:42<@peter1138>Celestar, why consider it a cache
08:42<@peter1138>make it authoritative
08:42<Celestar>peter1138: because that is not something I can do at lunchbreak :P
08:42<@peter1138>basically no difference tbh :)
08:43<Celestar>michi_cc: and the performance.
08:43<+michi_cc>Does it suck? :p
08:43<Celestar>michi_cc: no.
08:44<Celestar>michi_cc: well. I took a 512x512 map with > 1000 trains (some 10k vehicles).
08:44<Celestar>michi_cc: the CPU time went up by 11%
08:44<Celestar>michi_cc: then I took an empty 2k x 2k map.
08:44<Celestar>michi_cc: there the CPU time went up by a factor of two.
08:44<+michi_cc>It's called trees I guess :)
08:45<Celestar>michi_cc: nope.
08:45<Celestar>michi_cc: two bottlenecks seem to appear.
08:46<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)
08:46<+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 :)
08:46<Celestar>michi_cc: I'm at fast forward :P
08:46<Celestar>michi_cc: total game usage. not only the Tile Loop.
08:47<+michi_cc>GetTileSlope is probably the function that hurts the most from the more expensive tile lookup
08:47<Celestar>michi_cc: 2) TileLoopClearHelper
08:47<@planetmaker>I recall correctly that zero refit costs and the autorefit flag set means autorefit is done also w/o callback, right?
08:47<+michi_cc>planetmaker: yes
08:47<Celestar>michi_cc: finding the neighbours there. That can be cashed as well.
08:47<@planetmaker>sweet. No refit then anymore for pax / tourists :-)
08:48<Celestar>michi_cc: just need three "cache bits"
08:48<+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.
08:48<Celestar>michi_cc: ?
08:49<Celestar>michi_cc: IsTileType(TILE_ADDXY(tile, 1, 0), MP_CLEAR) && IsClearGround(TILE_ADDXY(tile, 1, 0), CLEAR_FIELDS)
08:49<Celestar>it really is this line.
08:49<Celestar>on empty maps.
08:50<Celestar>of course once you have 2k trains running about, the effect of the changed map array is minimal.
08:50<Celestar>(below 10%)
08:50<+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.
08:51<@peter1138> anyway, who cares if factor two means from 1% CPU to 2% CPU :)
08:51<Celestar>peter1138: it's from 50% to 100% if you will ...
08:52<Celestar>CPU time == total user time of the openttd process.
08:52<+michi_cc>This exacerbates things that were more expensive in the tile loop already with the old code
08:55<@planetmaker>isn't tree growth on a tile (except add 1st and deleting last) a nice thing which could be done separately?
08:55<@planetmaker>iirc it doesn't affect anything else exept looks
08:58<@peter1138>done separately where?
08:58<@peter1138>and you can pay to add trees
08:59<@peter1138>pay more in fact!
09:00<@peter1138>costs £15 for the first tree and £30 thereafter o_O
09:06<Celestar> 18.13 2.82 2.82 14782991 0.00 0.00 TileLoopClearHelper(unsigned int)
09:06<Celestar> 14.75 5.11 2.29 1000 0.00 0.01 RunTileLoop()
09:06<Celestar> 7.02 6.20 1.09 15383644 0.00 0.00 GetTileSlope(unsigned int, unsigned int*)
09:11<frosch123>planetmaker: trees also spawn trees in their neighbourhood afaik
09:15<@planetmaker>frosch123: yes, they do that. But it'd be a new tile
09:19<Noldo>what does the tree tile handling actually do?
09:20<Celestar>I don't see trees being the main problem up there.
09:21<frosch123>i mimics a hypercomplex realism, which is a total waste of computation power
09:21<CIA-6>OpenTTD: michi_cc * r23109 /trunk/src/economy.cpp: -Fix: Subtract auto-refit costs from the vehicle profit.
09:22-!-blotek [] has joined #openttd
09:25<Noldo>tree growth?
09:39<Celestar>putting the slope into the tile is a buttload of work
09:41<CIA-6>OpenTTD: rubidium * r23110 /trunk/src/ (6 files): -Codechange: let the flying altitude return ints are well
09:41*Celestar thinks he should base his stuff on top of michi's patch
09:41<Rubidium>Celestar: I think the major question is which slope to store. The one with or the one without foundations
09:45<Celestar>Rubidium: I'm wondering that too.
09:45<Celestar>Rubidium: or even both?
09:45<Celestar>one stored, one cached.
09:47<Rubidium>I'd just cache all
09:47<Celestar>or that.
09:47<Celestar>and deduce the foundations on game load?
09:47<Rubidium>no need to store something that can be relatively trivially computed
09:48<Celestar>the biggest question is when to recompute.
09:48<Rubidium>Celestar: well, whenever there is a need to
09:48<Celestar>on access, or on change :P
09:48<@peter1138>when heights change
09:48<Rubidium>on change
09:48<@peter1138>on change definitely
09:48<Celestar>should be easier.
09:48<@peter1138>if you do it on access, you need to test if it's valid or not
09:48<Celestar>because that only happens on SetTileHeight
09:48<Celestar>the base slope at least.
09:49<Celestar>the foundation changes whenever you build something on the tile. or the adjacent tiles.
09:49<@peter1138>with michi_cc's stuff, could you have MP_CLEAR, MP_FOUNDATION, MP_STUFF
09:49<@peter1138>or is that pointless?
09:49<Celestar>if we wanna have cliffs ....
09:50<Celestar>I don't quite see the help of MP_FOUNDATION
09:50<Celestar>or maybe, you have MP_FOUNDATION anyway for drawing the cliffs more easily.
09:50<@peter1138>cliffs don't need foundations
09:50<Celestar>but from a drawing point of view, it's the same :P
09:51<@peter1138>no, cos the surface doesn't need to be flat
09:51<Celestar>it doesn't have to be for foundations either?
09:51<@planetmaker>bah, awesome, michi_cc! It even refits to both cargos simultaneously for different wagons of the same type
09:51<@peter1138>true :p
09:51<@peter1138>but foundations are built upon the slope
09:51<@peter1138>can't explain :p
09:51<Celestar>this needs a plan :P
09:51<@planetmaker>cookie for you :-)
09:52<@peter1138>cliffs just need a height & slope
09:52<+michi_cc>Thanks :)
09:52<@peter1138>that doesn't help either
09:52<@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
09:53<@Yexo>on an empty 2048x2048 map, 5000 ticks took 15 seconds. After applying it went to 13 seconds
09:53<Celestar>Yexo: yes, it always was.
09:53<@Yexo>that patch basically uses 1 bit to store "do we nee dto check for fence updates at all"
09:53<@Yexo>if that bit is not set, directly return from TileLoopClearHelper
09:53<@Yexo>needs comments ofc, but otherwise it works
09:53<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
09:53<@planetmaker>it really adds a lot to the game :-)
09:53<Celestar>I agree with blathijs there.
09:54<Celestar>Yexo: I have a similar patch :)
09:54<Celestar>Yexo: just more .. hacky :P
09:54<@peter1138>that's what i was thinking :)
09:54<Celestar>Yexo: how much does your patch reduce that function itself?
09:54<+michi_cc>planetmaker: You want to write some instructions on the ottd wiki?
09:54<blathijs>though it does mean that there can be two "ground level" Tile* in a single tile, which might make other stuff more complicated
09:54<@Yexo>Celestar: no clue, I'm on windows currently
09:54<@Yexo>which means I can't use gprof
09:54<blathijs>e.g., when building a new track, you'd be building on the MP_FOUNDATION, not on the MP_CLEAR
09:55<Celestar>Yexo: I'll give it a shot
09:55<@planetmaker>michi_cc: you mean the player wiki?
09:55<@Yexo>that'd be great, thanks :)
09:55<@peter1138>blathijs, i just had that thought
09:55<@peter1138>maybe you'd have MP_FOUNDATION, MP_CLEAR, MP_RAIL
09:55<@planetmaker>I rather thought about writing a posting in the NewGRF dev section of the forums
09:55<@peter1138>foundation can be the base
09:55<Celestar>Yexo: what revision should I try, roughly?
09:55<@peter1138>no need for MP_CLEAR
09:55<Celestar>Yexo: of svn?
09:55<@planetmaker>as the actual usage depends a lot on how the newgrf uses it
09:56<blathijs>peter1138: The reason for having both would be that both have a different slope
09:56<@Yexo>it's a diff against r23108, but that's recent enough :p
09:56<+michi_cc>planetmaker: I won't stop you ;)
09:56<blathijs>peter1138: And swapping the order might make sense, but that drops the implicit z-ordering of the Tile*'s
09:56<Celestar>Yexo: even after Rubidium refactoring half the code? :P
09:56<Celestar>ah lol
09:56<Celestar>2 revs down
09:56<@peter1138>blathijs, MP_FOUNDATION could easily just store its top slope, but yeah, special cases again :S
09:57<Celestar>peter1138: blathijs: michi_cc: we should draw this somewhere :P
09:58<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
09:59<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.
10:00<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
10:00<Celestar>then some places might need cleaning up
10:01<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.)
10:05<Celestar>Yexo: time spent in TileLoopClearHelper is halved.
10:07<Celestar>Yexo: lemme run a longer test...
10:10<Celestar>10000 ticks
10:12<Celestar>how much threading do we have meanwhile O_o
10:12<Celestar>real 3m23.539s
10:12<Celestar>user 4m6.119s
10:12<+michi_cc>Nothing except savegame compression and blitting the back buffer to screen.
10:13<+michi_cc>So probably disable autosave in your openttd.cfg if you haven't alredy.
10:14<Celestar>what's the setting ffs :P
10:15<@planetmaker> <-- michi_cc
10:19-!-Prof_Frink [] has joined #openttd
10:21<Celestar>Yexo: that is weird.
10:21<Celestar>Yexo: TileLoopClearHelper is down from 22% to 8%
10:21<Celestar>Yexo: but user time is unchanged O_o
10:23-!-supermop [] has joined #openttd
10:25<Eddi|zuHause>michi_cc/planetmaker: what happens when the automatic refit changes vehicle length or somesuch?
10:25<+michi_cc>All hell breaks loose?
10:26<Celestar>Yexo: next culprit then is GetTileZ
10:26<+michi_cc>Hopefully set authors demonstrate some sense.
10:26<Celestar>Yexo: but storing the slope can solve that too.
10:26<Eddi|zuHause>michi_cc: i mean: are there measures to prevent that?
10:26<@Yexo>Celestar: I'm first going to do a radically different approach to the fences
10:27<Celestar>Yexo: hehe
10:27<+michi_cc>No, there aren't, just as there isn't a check against refitting to passengers in a truck stop.
10:28<Celestar>there is
10:28<Celestar>called "profit"
10:28<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
10:28<+michi_cc>I'm simply hoping set authors have at least a bit of sanity left and just don't implement that.
10:28<Eddi|zuHause>(i mean inside a depot now)
10:29<Celestar>back in a few
10:30<frosch123>yeah, heqs trams will probably fail with autorefit
10:31<Eddi|zuHause>frosch123: why? it should keep the subtype
10:31<frosch123>i don't think it does currently
10:31<+michi_cc>The CB result could be redefined as a signed integer if really needed.
10:32<Eddi|zuHause>i would imagine the same checks as while autoreplacing apply
10:32<+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.
10:32<Eddi|zuHause>while at it: that check was somehow missing on cloning
10:33-!-AndroUser [~androirc@] has joined #openttd
10:33<Eddi|zuHause>i.e. cloning of a vehicle didn't keep the subtype (last time i checked)
10:33<frosch123>planetmaker: bit 14, not 15 btw :)
10:34-!-Celestar is now known as Guest15791
10:34-!-AndroUser is now known as Celestar
10:34<@planetmaker>eh, yes. 0-based :-)
10:34<frosch123>michi_cc: do might want to call ConsistChanged with same_length = true
10:34<frosch123>(for trains)
10:34<Celestar>sucks on a touchscreen
10:35<frosch123>RoadVehUpdateCache for rv
10:37-!-Guest15791 [~dax@] has quit [Ping timeout: 480 seconds]
10:37<Celestar>yexo how different?
10:37<@Yexo>storing 4 fences in field tiles instead of storing the fences on the south border on clear and tree tiles
10:38<Celestar>sounds clever ;)
10:39<Celestar>this client sucks for irc
10:43<Celestar>so you have to check the neighboring tiles only on modification.
10:44<Celestar>GetTileZ wants something like that as well
10:44<+michi_cc>frosch123: something like ?
10:45<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
10:46<frosch123>michi_cc: maybe GetBestFittingSubType
10:46<frosch123>preserving the raw value of subtype makes no sense
10:47-!-Celestar [~androirc@] has quit [Quit: AndroIRC - Android IRC Client ( )]
10:48<+michi_cc>That function looks like it needs to be used very carefully if you have only a single vehicle
10:49-!-pjpe [] has joined #openttd
10:49<frosch123>i guess it needs splitting in the half
10:49<frosch123>you only need the second part
10:50<Eddi|zuHause>well, you could make that a requirement for autorefitting: the subtypes must match
10:50-!-Celestar [~androirc@] has joined #openttd
10:50<Eddi|zuHause>which should be the case for heqs trams
10:50*Rubidium wonders to what extent michi broke yacd with this autorefit at station ;)
10:51<Eddi|zuHause>Rubidium: that should be easy to fix, just add a link for all cargos, not just the currently refitted cargo
10:51<Celestar>is yacd active?
10:52<Eddi|zuHause>due to performance issues
10:52<@planetmaker>Eddi|zuHause: requiring the subtype to match imho is not really that useful...
10:52<Eddi|zuHause>planetmaker: why? you want to make sure that it does not autorefit from 4 wagons to 15 wagons
10:52<@planetmaker>why shouldn't i refit from oil (barrels) to lumber (furniture)
10:53<frosch123>michi_cc: + new_subtype = v->subtype; <- that should also be before the DC_QUERY_COST
10:53<Eddi|zuHause>planetmaker: i mean the subtype numbers, not the subtype strings
10:53<@peter1138>__ln__ :)
10:53<@planetmaker>yes. So?
10:53<@planetmaker>why would I need them to match between cargos?
10:54<@planetmaker>you do that via callback, I'd say
10:54<@planetmaker>I could as well have subtype 1 (cargo A) have 15 wagons and subtype 1 (cargo B) be 7 wagons
10:54<Eddi|zuHause>planetmaker: exactly, and that should be forbidden
10:55<frosch123>Eddi|zuHause: the refitcost callback can forbit autorefit depending on the subtype
10:55<Eddi|zuHause>planetmaker: because vehicles cannot _ever_ change length outside a depot
10:55<frosch123>so, everything can be done by the grf
10:55<Eddi|zuHause>frosch123: but it cannot suggest an alternate subtype
10:56<@planetmaker>the question is: will it try all subtypes for a cargo?
10:56<@planetmaker>It probably should
10:56<@planetmaker>starting with subtype1
10:56<frosch123>planetmaker: then it would not compare the texts, but leave all to the callback
10:56<Eddi|zuHause>starting with the current subtype, or with the subtype with the same name?
10:56<@planetmaker>frosch123: exactly
10:56<frosch123>which means you always have to use the callback if you have subtypes
10:56<+michi_cc>frosch123: best fitting subtype + length check for trains/rvs:
10:56<@planetmaker>which imho is better
10:57-!-kaparen [] has quit [Quit: ajax IRC Client]
10:59<+michi_cc>Rubidium: Why do you think I implemented a refit to any available cargo? ;)
10:59<frosch123>michi_cc: looks fine to me
10:59<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?
11:00<frosch123>remains whether that the refit-capacity callback shall be allowed to choose a different subtype
11:00<z-MaTRiX>if display is VERY slow, then mouse cursor hangs too
11:00<frosch123>but imo, something for later when needed
11:04<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.
11:04<CIA-6>OpenTTD: michi_cc * r23112 /trunk/src/ (6 files): -Codechange: Check if vehicle chain lengths stays constant when auto-refitting.
11:07<@planetmaker>z-MaTRiX: our days have 24h only and we have a RL. Patches to improve the game are always welcome
11:07<@planetmaker>we usually don't lack ideas of what could be better. We lack time
11:10<Rubidium>michi_cc: to have a better reason to not continue with yacd than "performance sucks"? :)
11:13<z-MaTRiX>planetmaker<< ok i see your point :)
11:13<z-MaTRiX>maybe i can finally help then ?
11:13<z-MaTRiX>in something
11:14<@planetmaker>of course. Feel free to give it a shot
11:14<@planetmaker>everyone improves those parts s/he takes joy in improving :-)
11:14<z-MaTRiX>right now i'm @ mutexland sightseeing
11:15-!-Celestar [~androirc@] has quit [Quit: AndroIRC - Android IRC Client ( )]
11:17-!-Zuu [] has joined #openttd
11:18-!-glx [glx@2a01:e35:2f59:c7c0:59e5:79d8:f03d:a513] has joined #openttd
11:18-!-mode/#openttd [+v glx] by ChanServ
11:45-!-Sigvatr [sig@] has joined #openttd
11:45<Sigvatr>do i need the original tt to use as graphics or can i play with some in development graphics sets?
11:45-!-pugi [] has joined #openttd
11:46<Sacro>Sigvatr: you don't need the original tt
11:46<Sacro>you could use the original ttd however, or there are free graphics sets
11:46<Sigvatr>are any free sets complete and not crap?
11:46<Sacro>complete, yes, crap however is subjective
11:47<__ln__>Sigvatr: if the quality doesn't satisfy you, you can make a better one yourself.
11:47<Sigvatr>i've never played tt at all before, will people get mad at me if i try to play multiplayer
11:47-!-snack2 [] has quit [Ping timeout: 480 seconds]
11:47<Sigvatr>well i used to make buildings in SCURK like 15 years ago so who knows
11:51<Sigvatr>what directory do i put opengfx-0.3.7 in
11:54<@Yexo>see openttd's readme.txt
11:55-!-snack2 [] has joined #openttd
11:55<Sigvatr>since i've never played tt at all before will i infuriate anyone if i play multiplayer the first time
11:57<@Yexo>I don't see why
11:58-!-Biolunar [mahdi@] has joined #openttd
11:58<Sigvatr>wow everything is so tiny on my 1920x1080 monitor
11:58<Sigvatr>like ants
12:15<@peter1138>depends on the size :p
12:16<Sigvatr>i have been playing my first multiplayer game for about 10 minutes
12:16<Sigvatr>but i couldn't do anything
12:16<Sigvatr>and everyone was trying to figure out why i couldn't build any roads
12:16<Sigvatr>turns out i was spectating
12:18<@planetmaker>but happens :-)
12:19<Eddi|zuHause>what's the relative difference in pixel size between 640x480 on 14" and 1920x1080 on 27"?
12:19-!-snack2 [] has quit [Ping timeout: 480 seconds]
12:20<V453000>would have to count it I guess :)
12:22-!-valhallasw [] has joined #openttd
12:22<@Yexo>isn't that simply 1.5?
12:23<@Yexo>(1920/640) / (27"/14") ?
12:23<Eddi|zuHause>because the ratio is different
12:23-!-DabuYuTimeOut [DabuYu@] has quit []
12:23<@Yexo>oh, right
12:23<V453000>count total amount of pixels of each screen and just divide it by 27 or 14?
12:24<Eddi|zuHause>14": ~57dpi, 27": ~82dpi
12:24-!-pugi [] has quit [Quit: I reject your reality and substitute my own]
12:25<Eddi|zuHause>around factor 0.7
12:25<@Yexo>so my 1.5 wasn't that far off :p
12:26<Eddi|zuHause>so everything is 30% smaller
12:29<Eddi|zuHause>"That will occur at roughly the time the much anticipated Keynesian fireworks begin..." <- anyone has a clue what that refers to?
12:30<Prof_Frink>Fireworks? Tomorrow.
12:32-!-|Jeroen| [] has joined #openttd
12:32-!-DayDreamer [] has left #openttd []
12:34<Eddi|zuHause>not exactly helpful :p
12:35<Qantourisc>How do you prevent a city from growing over your tracks ?
12:35<Qantourisc>more specifcly the ones of your tracks
12:38<Eddi|zuHause>what do you mean "over your tracks"?
12:38<Prof_Frink>Play TTO and build monorails. Or, more usefully, put something alongside your tracks that they can't cross.
12:38-!-sla_ro|master [~slaco@] has joined #openttd
12:38<Eddi|zuHause>don't need TTO for that. you can prevent road crossings by newgrf
12:39<Eddi|zuHause>e.g. the highspeed tracktypes in nutracks
12:39<V453000>which is pretty stupid tbh ... realism
12:39*Prof_Frink builds a rack for his nuts.
12:39<V453000>it is much better to prevent towns from build roads themselves
12:40<V453000>from building*
12:40<Prof_Frink>Or use the preset grids and match the road positions with signal spacing
12:41<Qantourisc>Prof_Frink: hmmm ok thanks
12:41*Rubidium wonders why nobody made a setting for disallowing towns to build roads
12:42<V453000>Rubidium: ? :d
12:43<Rubidium>well, everything that's being said here kinda implies that they is no such setting
12:44<Rubidium>or is it already too late for me?
12:44<V453000>kinda implies :)
12:44<V453000>not entirely :p
12:52<@peter1138>just place your signals sensibly :)
12:52<@peter1138>path signals, of course :p
12:52<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.
12:53<Zuu>So instead of matching road station location against the grid, it would match rail signs. :-)
12:53<b_jonas>the openttdcoop wiki also suggests an innovative way to stop towns from building level crossings over your rail
12:53<b_jonas>namely to build your rail track on sloped square with foundations
12:53<b_jonas>which can be made invisible if you have two tracks parallel
12:53<V453000>also a way :)
12:54<V453000>but in general you totally do not want towns to be able to build roads on their own
12:54<b_jonas>I can't find that on the wiki now for some reason
12:54<@peter1138>you don't?
12:54<V453000>it is in the tutorial savegame, not sure if anywhere else
12:54<@peter1138>i do
12:54<V453000>peter1138: why? You cannot control the game that way
12:54<V453000>towns you do not need to grow just grow .. why
12:54<@peter1138>i don't want to control the game that way
12:55<@peter1138>i don't like the grid layouts either
12:55<V453000>grid layouts suck indeed
12:55<V453000>how is that cosmetic look related though? :)
12:56<b_jonas>V453000++ indeed:
12:56<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
12:57<b_jonas>and I guess you could also build a sign just where the town wants to cross the road
12:57<b_jonas>or you can build a bridge for the town
12:58<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
12:59<b_jonas>I rather just build roads for the towns in advance
12:59<b_jonas>that's good for aesthetics, and also means I can always remove the roads if I need to
12:59<b_jonas>because I own them
12:59<@peter1138>i just transport stuff
13:00<+michi_cc>peter1138: What a novel idea :p
13:00<Prof_Frink>peter1138 is oldschool
13:01<V453000>oldschool can be respectable, carelessness not :p
13:05-!-mahmoud [] has joined #openttd
13:13-!-Devroush [] has joined #openttd
13:13-!-Alberth [] has joined #openttd
13:13-!-mode/#openttd [+o Alberth] by ChanServ
13:14-!-Neon [] has joined #openttd
13:15-!-KritiK [] has joined #openttd
13:21-!-kaparen [] has joined #openttd
13:23<Sigvatr>i can't join some games because of NEWGRF mismatch
13:23<Sigvatr>how do i fix that
13:23<@Yexo>click on nwegrf button and try to download the newgrfs
13:24<@Yexo>if not all of them are available in the online content system you'll ahve to look for them yourself
13:24<@Yexo>in which case: good luck
13:29-!-Devroush [] has quit [Ping timeout: 480 seconds]
13:33-!-Brianetta [] has quit [Remote host closed the connection]
13:37-!-pjpe [] has quit [Quit: ajax IRC Client]
13:51-!-pjpe [] has joined #openttd
14:02-!-Adambean [] has joined #openttd
14:03-!-Pulec [] has joined #openttd
14:05-!-Prof_Frink [] has quit [Ping timeout: 480 seconds]
14:15-!-Devroush [] has joined #openttd
14:16-!-Elukka [] has quit [Read error: Connection reset by peer]
14:16-!-Elukka [] has joined #openttd
14:21-!-pugi [] has joined #openttd
14:25-!-|Jeroen| [] has quit [Quit: oO]
14:38-!-Wolf01 [] has joined #openttd
14:40<__ln__>bonsoir Wolf01
14:41-!-Brianetta [] has joined #openttd
14:44-!-Chris_Booth [] has joined #openttd
14:44-!-Mucht [] has joined #openttd
14:45<CIA-6>OpenTTD: translators * r23113 /trunk/src/lang/ (6 files): (log message trimmed)
14:45<CIA-6>OpenTTD: -Update from WebTranslator v3.0:
14:45<CIA-6>OpenTTD: dutch - 17 changes by habell
14:45<CIA-6>OpenTTD: english_US - 17 changes by Rubidium
14:45<CIA-6>OpenTTD: finnish - 17 changes by jpx_
14:45<CIA-6>OpenTTD: french - 17 changes by glx
14:45<CIA-6>OpenTTD: german - 17 changes by planetmaker
14:58-!-aglenday [~Impatient@] has quit [Quit: Leaving]
15:09-!-JVassie [~James@] has joined #openttd
15:12-!-mahmoud [] has quit [Ping timeout: 480 seconds]
15:24-!-mahmoud [] has joined #openttd
15:26-!-andythenorth [] has joined #openttd
15:29-!-Chris_Booth [] has quit [Ping timeout: 480 seconds]
15:51-!-andythenorth [] has quit [Quit: andythenorth]
15:57-!-DOUK [] has joined #openttd
16:00-!-SamCat [] has joined #openttd
16:01-!-mahmoud [] has quit [Ping timeout: 480 seconds]
16:02-!-snack2 [] has joined #openttd
16:05<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!
16:06<SamCat>I usually don't have trouble keeping stations at a rating above 70%
16:06<@planetmaker>oil wells die
16:06<SamCat>so, you're saying that they just die because they die and I'm not actually doing anything wrong?
16:07-!-andythenorth [] has joined #openttd
16:07<SamCat>oh, okay...
16:07<@planetmaker>oil wells (in the default game) cannot increase production and only decrease it.
16:07<@planetmaker>Thus they'll eventually die
16:08<SamCat>no other industry is like that, though, right?
16:08<@planetmaker>you could use something like opengfx+industries which allows you to modify that behaviour
16:08<SamCat>ah! I will!
16:08<SamCat>that behavior makes 64x64 maps thoroughly unplayable
16:08<SamCat>at least when you're trying to do a freight game
16:09<@planetmaker>:-) 64^2 is a challange indeed
16:09<@planetmaker>but other industries should not do that. Unless I have a hole in my memory
16:10<SamCat>my last game, though, I was monitoring my oil well constantly and it was going up sometimes
16:10<SamCat>does it just tend downwards then?
16:11<SamCat>it was just going "oh look, we increased the production OH MY GOD 50% DOWN!"
16:12*andythenorth does read grf v8
16:13-!-TheMask96 [] has quit [Ping timeout: 480 seconds]
16:13<@Alberth>SamCat: the idea is that you gradually switch to oilrigs
16:13<Rubidium>SamCat: it probably went up with a very small amount without a news message
16:14<SamCat>ooooooh, oil rigs!
16:14<Rubidium>SamCat: that's because in a month the primary industries will produce 8 or 9 times, which explains those small fluctuations
16:14<SamCat>okay, that explains things then, thanks
16:15<SamCat>so much for my half-million-dollar mountain railroad >.<
16:15<andythenorth>are checks for water tiles now 'solved'?
16:15<andythenorth>e.g wrt detecting explicitly coast, river etc
16:17-!-TheMask96 [] has joined #openttd
16:19<andythenorth>could cb36 cargo capacity cb be 'solved' for grf v8?
16:19<andythenorth>or is that unrelated to a version bump?
16:19<SamCat>oil wells are never generated on a new map, are they?
16:19<andythenorth>seems like a behaviour change
16:22<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
16:22*andythenorth wonders about vehicle visual effect
16:23<SamCat>er, I meant oil rigs >.<
16:23<@Alberth>they are not created before 1960 iirc
16:23<SamCat>Alberth: Ah, that explains things. I almost always start my games in 1850
16:24<andythenorth>so cb10 for visual effect is being deprecated, and that will be added to cb36 for v8?
16:25*andythenorth will give €1 to the first person to guess what comes next...
16:25*Alberth writes a line at the #openttd channel
16:25-!-DayDreamer [] has joined #openttd
16:26<Rubidium>andythenorth: deprecation of callback 11?
16:26*andythenorth didn't think of that
16:26<@Alberth>Hmm, 1960 is not mentioned at our wiki
16:26*andythenorth had more control over visual effects in mind
16:27<andythenorth>probably by looping over a cb
16:27<andythenorth>but if cb36 is the new way for controlling visual effect, that might not be possible :(
16:27*andythenorth would be sad :(
16:28<@Alberth>shouldn't we try to reduce #cb calls?
16:28-!-DDR_ [~chatzilla@] has joined #openttd
16:29<andythenorth>it will be sad if ships can never have smoke
16:30<andythenorth>never / less likely /s
16:31<@peter1138>why less likely?
16:32<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?
16:32<andythenorth>or am I making an wrong assumption
16:33<@planetmaker>changing the property via cb36
16:33*andythenorth is assuming that cb36 explodes if we make it do too many things
16:33<@planetmaker>that can be done any time
16:34<andythenorth>in a backwards compatible way?
16:35<@planetmaker>how backward compatible?
16:35<@planetmaker>in grfv7 you can keep using cb10/11/12
16:36<b_jonas>callbacks can explode if you overuse them?
16:37<b_jonas>let's do that, you wanted graphical effects, an explosion is always a good idea for that
16:37<@peter1138>no. might get ever so slightly slower though.
16:37<SamCat>does anyone know if UKRS2 is compatible with FIRS?
16:40<@Alberth>SamCat: the readme states the set as compatible
16:40<@Alberth> line 117
16:40-!-TWerkhoven2 [] has joined #openttd
16:41-!-Chris_Booth [] has joined #openttd
16:41<SamCat>Alberth: Thanks, I don't know how I managed to miss that
16:41<@Alberth>you need to unpack the tar file to read it ?
16:42<SamCat>heh, yeah
16:47-!-TWerkhoven [] has quit [Ping timeout: 480 seconds]
16:49-!-Chris_Booth [] has quit [Ping timeout: 480 seconds]
16:53-!-blotek_ [] has joined #openttd
16:53-!-blotek [] has quit [Read error: Connection reset by peer]
16:56<frosch123>andythenorth: you have a good point in not deprecating the visual effect callback
16:56<frosch123> <- anyway, for you cb 36 capacity issue
17:03-!-mahmoud [] has joined #openttd
17:05<CIA-6>OpenTTD: michi_cc * r23114 /trunk/src/ (7 files): -Feature: [NewGRF] Ambient sound effect callback.
17:06-!-DOUK [] has quit [Ping timeout: 480 seconds]
17: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
17:08<andythenorth>or we have to introduce a new cb
17:08<andythenorth>it seems odd to deprecate one and introduce a new one
17:09<andythenorth>it makes the documentation at least confusing
17:10<andythenorth>frosch123: can I just trust that capacity fix works? :) I've read it, but it's too much for me to take in :)
17:10<andythenorth>or I can compile it...
17:10<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
17:11<frosch123>when the flag is set, the default capacity property always describes the capacity of a cargo with multiplier 0x100
17:12<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
17:12<@planetmaker>oh, that way round
17:12<@planetmaker>so the cargo sets volume and space?
17:12<frosch123>kind of
17:13<@planetmaker>that naming would make it maybe clearer :-)
17:13-!-Sigvatr [sig@] has quit []
17:14<frosch123>in other words, it makes the cets solution unneccessary and bad :p
17:18<andythenorth>so the vehicle sets capacity as weight?
17:18-!-Adambean [] has quit [Quit: Gone fishing]
17:18<andythenorth>and the grf defining cargo specifies how many units per t?
17:18<andythenorth>(or how many t per unit)
17:20<frosch123>vehicle sets capacity in tons of coal
17:21<frosch123>the cargo defines how many units of it match the weight/volume of that
17:22<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
17:24-!-DOUK [] has joined #openttd
17:24<andythenorth>frosch123: will it make your chart simpler to draw? :)
17:25<andythenorth>or worse? :)
17:25<frosch123>if i draw it in the same chart, it will become more complicated :p
17:25<andythenorth>can we have a new chart?
17:25<frosch123>need to check how the new chart looks like
17:26<frosch123>yeah, should be a new chart
17:26<andythenorth>option 1. use the simple chart. option 2. use the insane chart
17:26<andythenorth>I know the current chart was lots of work, but all it tells me is that I don't like the current situation :)
17:26<andythenorth>well not all, but that's my main conclusion
17:26<frosch123>it will be definitely a separate chart :)
17:28-!-supermop [] has quit [Remote host closed the connection]
17:28-!-supermop [] has joined #openttd
17:29-!-mahmoud [] has quit [Ping timeout: 480 seconds]
17:32-!-Alberth [] has left #openttd []
17:33<andythenorth>an awesome picture
17:33<andythenorth>also - vehicles-in-vehicles ;)
17:34<SamCat>Is the coach there for the truckers or something?
17:35<frosch123>according to the descripton, it is :p
17:36<valhallasw>andythenorth: now I want pictures of a train carrying trucks carrying model trains carrying trucks
17:36<valhallasw>ad infinitum :p
17:36<frosch123>looked like containers at first, so the passenger coach confused me
17:36<SamCat>*facepalms herself* there's a caption >.<
17:36<SamCat>Valhallasw: that would be awesome
17:37<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
17:37*andythenorth has a lego truck which has cargo of lego boxes....
17:37<andythenorth>in the box is the truck...
17:37<SamCat>but then I just realized that I have a laptop
17:37<SamCat>I'm such a dork >.<
17:37<andythenorth>iphone sucks
17:37<SamCat>heh, yeah
17:37<SamCat>and I have a laptop so I can play OpenTTD (which I very much prefer) on a bigger screen on the train!
17:37-!-Celestar [] has joined #openttd
17:38<frosch123>shit, that photo is from the future
17:39<frosch123>who wants to go with me to hungary, and watch that train in a week?
17:39<andythenorth>that would be good
17:39<frosch123>i assume it will drive there at 11:11
17:40<andythenorth>it's an 11 reccuring?
17:40<frosch123>Eddi|zuHause: oh, so dbset 0.9 is released in one week
17:40<andythenorth>my baby might come on 11:11:11
17:40<SamCat>congrats, Andythenorth
17:40<andythenorth>or it might come later
17:40<andythenorth>or earlier
17:40<andythenorth>who knows
17:41<andythenorth>the last one showed up early
17:41<SamCat>you could still have the birthday party on 11:11:11
17:41<SamCat>Rule of Cool applies to real life, too, you know!
17:42<@planetmaker>oh, another andy clone? :-)
17:45<andythenorth>you should see the current one
17:45<andythenorth>he's a train obsessive
17:45<andythenorth>he says 'choo choo' in his sleep
17:45<SamCat>ha! that's awesome
17:45<andythenorth>he's the I like trains kid:
17:45<andythenorth>he's only 19 months old
17:45<frosch123>better than obsessive about sawmills?
17:46<andythenorth>better than that yes
17:46<SamCat>sawmills are still pretty cool
17:46<andythenorth>better than obsessive about the correct lighting direction in a 17 year old game
17:46*andythenorth is fixing lighting in HEQS
17:47-!-Celestar [] has quit [Ping timeout: 480 seconds]
17:47<SamCat>you say 17 year old game like it's a bad thing
17:47<@planetmaker>he :-)
17:47<andythenorth>it's just a slightly odd obsession
17:48*andythenorth likes grf v8
17:48<andythenorth>means OpenTTD Is Clearly Not Dying ®
17:48<andythenorth>will the patch support grf v8? :o
17:49<@planetmaker>ask an active TTDP developer ;-)
17:51<SamCat><3 the pixel art, though
17:51<V453000>how many people do fit in that group pm? :d
17:55<frosch123>at least a non-negative number
17:56<SamCat>0 is a non-negative number...
17:58<SamCat>neither is i
17:58<SamCat>even though it kinda is!
17:58<SamCat>*cue spooky music*
18:02-!-mahmoud [] has joined #openttd
18:07-!-DOUK [] has quit [Ping timeout: 480 seconds]
18:09*andythenorth -> bed
18:09-!-andythenorth [] has quit [Quit: andythenorth]
18:09<@planetmaker>sleep well...
18:13<Rubidium>planetmaker: your timing seems to be a bit off today ;)
18:14<@planetmaker>yeah. time over-compensated it seems
18:14<@planetmaker>*time shift
18:16*Terkhen is a lazy translator
18:19-!-sla_ro|master [~slaco@] has quit [Ping timeout: 480 seconds]
18:25<Eddi|zuHause>planetmaker/frosch123: in there is missing explanation for the "T" part
18:27<frosch123>landscape class
18:27<frosch123>just like in the current format
18:27<Eddi|zuHause>i don't actually know the current format :)
18:27<frosch123>added :)
18:29<SamCat>I think I'm going to go take a nap
18:29<SamCat>thanks everyone for your help! <3
18:30-!-SamCat [] has left #openttd []
18:32<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)
18:34-!-pugi [] has quit [Quit: I reject your reality and substitute my own]
18:36-!-HerzogDeXtEr [] has joined #openttd
18:36-!-HerzogDeXtEr1 [] has quit [Read error: Connection reset by peer]
18:40-!-frosch123 [] has quit [Remote host closed the connection]
18:42<Terkhen>good night
18:43-!-Chris_Booth [] has joined #openttd
18:43-!-Mucht [] has quit [Remote host closed the connection]
18:44-!-Chris_Booth [] has quit []
18:49-!-Kurimus [] has quit []
18:49-!-Sigvatr [sig@] has joined #openttd
18:49<Sigvatr>is it possible to link your line to someone elses and send a train to crash into theirs
18:52<Sigvatr>i thought i was very clever
18:53<Sigvatr>are there ways of harming other people's business asides from competition?
18:54<Eddi|zuHause>the only legal way is to buy exclusive rights in a town
18:54-!-George|2 [~George@] has joined #openttd
18:54-!-George is now known as Guest15838
18:54-!-George|2 is now known as George
18:54-!-George|2 is "(unknown)" on (unknown)
18:54-!-Guest15838 [~George@] has quit [Ping timeout: 480 seconds]
18:55<Sigvatr>well i mean illegal too
18:55<Eddi|zuHause>there are no illegal ways.
18:58<Sigvatr>that would make the game much more fun
18:58<Eddi|zuHause>only if you are 12
18:58<Sigvatr>but i'm 25
18:59<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.
19:06-!-Progman [] has quit [Remote host closed the connection]
19:07-!-valhalla1w [~valhallas@] has joined #openttd
19:10-!-supermop [] has left #openttd []
19:13-!-Wolf01 [] has quit [Quit: Once again the world is quick to bury me.]
19:13-!-snack2 [] has quit []
19:14<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
19:14-!-valhallasw [] has quit [Ping timeout: 480 seconds]
19:20<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
19:21<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...
19:25-!-Elukka [] has quit []
19:40-!-DOUK [] has joined #openttd
19:42-!-Cybertinus [] has quit [Remote host closed the connection]
19:44-!-mahmoud [] has quit [Ping timeout: 480 seconds]
19:46-!-Devroush [] has quit []
19:47<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.
19:48<@planetmaker>good night
19:55-!-DayDreamer [] has quit [Read error: Connection reset by peer]
20:12-!-TWerkhoven2 [] has quit [Quit: He who can look into the future, has a brighter future to look into]
20:20*Zuu pulls his hair and figure out that he need to change some parts of how globals are stored + accessed in a mid-size program.
20:28-!-Rob110178 [] has joined #openttd
20:29<Rob110178>Hi all
20:35-!-KritiK [] has quit [Quit: Leaving]
20:38<Zuu>Hello Rob110178
20:59-!-Fuco [] has quit [Ping timeout: 480 seconds]
21:09-!-Pulec [] has quit []
21:16-!-Zuu [] has quit [Ping timeout: 480 seconds]
21:18-!-Prof_Frink [] has joined #openttd
21:19-!-valhalla1w [~valhallas@] has quit [Ping timeout: 480 seconds]
21:25-!-Neon [] has quit [Quit: Python is way too complicated... I prefer doing it quickly in C.]
21:33-!-supermop_ [] has joined #openttd
21:40-!-Biolunar [mahdi@] has quit [Quit: All your IRC are belong to us!]
21:52<Rob110178>For some reason signaling is still confusing the daylights out of me... Grrr
22:09-!-JVassie [~James@] has quit [Ping timeout: 480 seconds]
22:33-!-HerzogDeXtEr [] has quit [Read error: Connection reset by peer]
22:35-!-Sigvatr [sig@] has quit []
22:37-!-kaparen [] has quit [Quit: Leaving]
22:51-!-Brianetta [] has quit [Quit: Tschüß]
23:12-!-enr1x [] has joined #openttd
23:14-!-enr1x_ [] has quit [Ping timeout: 480 seconds]
23:24-!-Eddi|zuHause [] has quit [Remote host closed the connection]
23:25-!-Eddi|zuHause [] has joined #openttd
23:26-!-rhaeder [] has joined #openttd
23:31-!-rhaeder1 [] has quit [Ping timeout: 480 seconds]
23:44-!-glx [glx@2a01:e35:2f59:c7c0:59e5:79d8:f03d:a513] has quit [Quit: bye]
---Logclosed Sat Nov 05 00:00:53 2011