Back to Home / #openttd / 2008 / 06 / Prev Day | Next Day
#openttd IRC Logs for 2008-06-27

---Logopened Fri Jun 27 00:00:00 2008
00:25<ccfreak2k>I saw a Sim Airport or something at Best Buy about five years ago..
00:26<theEd>Airline Tycoon isn't bad, albeit rather limited as to what you can do
00:32<ccfreak2k>Maybe that was it.
00:41-!-ecke [~ecke@] has joined #openttd
01:07-!-a1270 [] has quit [Quit: a1270]
01:15-!-a1270 [] has joined #openttd
01:23<Eddi|zuHause2><Pikka> you have to close every window one at a time clicking on the x's :P <- i was under the impression in TT you could click on the main toolbar (where the money is displayed) to close all windows
01:23<Eddi|zuHause2>but that's a long time ago...
01:24<ccfreak2k>But it's soooo much effort to drag the cursor all the way over to the toolbar.
01:24<Eddi|zuHause2>the toolbar was organised differently in TT ;)
01:25<ccfreak2k>And screens were so much smaller, too.
01:26<Eddi|zuHause2>in TTD they moved the money out of the main toolbar, and added the status bar at the bottom
01:28-!-raimar2 [] has joined #openttd
01:30<Eddi|zuHause2>now that i think of it, the "close all windows" was probably a world editor feature
01:35-!-raimar3 [] has quit [Ping timeout: 480 seconds]
01:46-!-einKarl [] has joined #openttd
02:11-!-Osai`off is now known as Osai
02:15-!-Touqen [] has quit [Ping timeout: 480 seconds]
02:18-!-mikl [] has joined #openttd
02:22-!-Touqen [] has joined #openttd
02:25-!-curson [] has joined #openttd
02:46-!-GoneWacko [] has joined #openttd
02:50-!-dR3x4cK [] has joined #openttd
03:11-!-curson [] has quit [Quit: If everything seems to be going well, you have obviously overlooked something.]
03:19-!-elmex [] has joined #openttd
03:19-!-dR3x4cK [] has quit [Quit: dR3x4cK]
03:31-!-ecke1 [~ecke@] has joined #openttd
03:33-!-Eddi|zuHause2 [] has quit [Ping timeout: 480 seconds]
03:33-!-Eddi|zuHause [] has joined #openttd
03:36-!-Netsplit <-> quits: Andel, theEd, CIA-4, Logix, ecke, Ridayah_, Born_Acorn, De_Ghosty
03:38-!-Netsplit over, joins: CIA-4
03:39-!-theEd [] has joined #openttd
03:39-!-Born_Acorn [~bornacorn@] has joined #openttd
03:39-!-Andel [] has joined #openttd
03:39-!-Ridayah_ [] has joined #openttd
03:39-!-Logix [] has joined #openttd
03:39-!-De_Ghosty [] has joined #openttd
03:39-!-einKarl [] has quit [Remote host closed the connection]
03:40-!-ecke [~ecke@] has joined #openttd
03:40-!-Osai is now known as Osai`off
03:41-!-ecke1 [~ecke@] has quit [Read error: Connection reset by peer]
03:41-!-Osai`off is now known as Osai
03:42-!-Osai is now known as Osai`off
03:42-!-Rexxars [~rexxars@] has quit [Ping timeout: 480 seconds]
03:42-!-Gekz [] has joined #openttd
03:48-!-Zahl [] has joined #openttd
03:49-!-Rexxars [~rexxars@] has joined #openttd
03:53-!-Wezz6400 [] has joined #openttd
03:56-!-Doorslammer|BRSet [] has joined #openttd
04:01-!-GoneWacko [] has quit []
04:02-!-thgergo [] has joined #openttd
04:08-!-Netsplit <-> quits: Andel, theEd, Logix, Ridayah_, Born_Acorn, De_Ghosty
04:08-!-Netsplit over, joins: theEd, Born_Acorn, Andel, Ridayah_, Logix, De_Ghosty
04:14-!-Farden [] has joined #openttd
04:15-!-dlunch [~dlunch@] has quit [Ping timeout: 480 seconds]
04:16-!-Farden123 [] has joined #openttd
04:17-!-stillunknown [] has joined #openttd
04:36-!-dR3x4cK [~Miranda@] has joined #openttd
04:42-!-Phazorx [~opera@MS-151-113.dyn-ip.SPb.SkyLink.RU] has joined #openttd
04:43<Phazorx>pardon for stupid question but is it possible to bump max_trains on running game of relatively outdated save loaded in recebt rev?
04:46<@peter1138>patch option isn't it?
04:52-!-Farden123 [] has quit [Quit: ( :: NoNameScript 4.2 :: )]
04:52<Phazorx>yeah, but it's been a long whie since i played so i dont recall how exactly i do it
04:52<Phazorx>patch max_train = # ?
04:53<Phazorx>or patch vahicle.max_trains?
04:54<Phazorx>oh nevermind... syntax issue on m end, very dub, sorry
04:56-!-Rexxars [~rexxars@] has quit [Remote host closed the connection]
05:01-!-Rexxars [~rexxars@] has joined #openttd
05:06-!-TinoM [] has joined #openttd
05:13-!-Phazorx [~opera@MS-151-113.dyn-ip.SPb.SkyLink.RU] has left #openttd []
05:19<Gekz>NO U
05:19<Gekz>oh crap
05:19<Gekz>its the UTF8 example site!
05:21-!-ecke [~ecke@] has quit [Quit: ecke]
05:23-!-lobstar [~michielbi@] has joined #openttd
05:24<@peter1138>it's an IDN example site
05:27<Gekz>he's knows my scam
05:27<Gekz>how boring.
05:27-!-Zealotus [] has quit [Ping timeout: 480 seconds]
05:28-!-lobster [~michielbi@] has quit [Ping timeout: 480 seconds]
05:28<Eddi|zuHause>it doesn't work
05:29<Eddi|zuHause>it turns into all ??? when i try to open it
05:31<Gekz>Eddi|zuHause: make sure you have the right codepage
05:31-!-[com]buster [] has quit [Ping timeout: 480 seconds]
05:31-!-ecke [~ecke@] has joined #openttd
05:31<Eddi|zuHause>of course, i can read it
05:31<ln>it has nothing to do with UTF-8, and besides UTF-8 is mandatory over here anyway.
05:31<Eddi|zuHause>and i can also read it when i paste it into the address bar
05:32<Eddi|zuHause>but once i hit enter, it converts all to ???
05:32<Gekz>what browser
05:33<Eddi|zuHause>also when i hover over it in konversation the status bar says ???
05:43-!-ecke [~ecke@] has quit [Ping timeout: 480 seconds]
05:51<Ammler>Eddi|zuHause: www.gmü works?
05:55-!-ecke [~ecke@] has joined #openttd
06:08-!-Hendikins [~wolfoxout@] has joined #openttd
06:09-!-Zealotus [] has joined #openttd
06:24-!-Gekz [] has quit [Quit: leaving]
06:27-!-Gekz [] has joined #openttd
06:28-!-Gekz [] has left #openttd []
06:28-!-Gekz [] has joined #openttd
06:33-!-lobstar is now known as lobster
06:37-!-Progman [] has joined #openttd
06:40-!-yorick [] has joined #openttd
06:41-!-Gekz_ [] has joined #openttd
06:43-!-Andel [] has left #openttd []
06:44-!-Gekz [] has quit [Ping timeout: 480 seconds]
06:47-!-Gekz_ is now known as Gekz
06:52-!-Rexxars [~rexxars@] has quit [Ping timeout: 480 seconds]
06:52-!-[com]buster [] has joined #openttd
06:57-!-Gekz [] has quit [Quit: leaving]
07:01-!-Doorslammer|online [] has joined #openttd
07:01-!-Rexxars [~rexxars@] has joined #openttd
07:05-!-Doorslammer|BRSet [] has quit [Ping timeout: 480 seconds]
07:07-!-Doorslammer|online is now known as Doorslammer|BRSet
07:08-!-[com]buster [] has quit [Read error: Connection reset by peer]
07:08-!-[com]buster [] has joined #openttd
07:09-!-ecke [~ecke@] has quit [Quit: ecke]
07:11-!-Gekz [] has joined #openttd
07:36-!-yorick [] has quit [Quit: Poef!]
07:37-!-ecke [~ecke@] has joined #openttd
07:46-!-Zorn [] has joined #openttd
07:51-!-tokai [] has quit [Ping timeout: 480 seconds]
07:53-!-tokai [] has joined #openttd
07:53-!-mode/#openttd [+v tokai] by ChanServ
07:53-!-Zorni [] has quit [Ping timeout: 480 seconds]
07:54-!-Dred_furst [] has joined #openttd
08:05-!-Zahl [] has quit [Quit: (~_~]"]
08:07-!-Zahl [] has joined #openttd
08:12-!-Osai`off is now known as Osai
08:16-!-einKarl [] has joined #openttd
08:30-!-Mchl [] has joined #openttd
08:30<TiberiusTeng>now I'm thinking to challenge programmable signals ...
08:34<Noldo>What are programmable signals for?
08:35<TiberiusTeng>check the thread in development forum :)
08:36<TiberiusTeng>I just don't want to carve these kind of things everytime ...
08:40<Noldo>I'm a bit worried about making signals have features like: This tile can be only passed by vehicles with property X
08:40-!-glx [] has joined #openttd
08:40-!-mode/#openttd [+v glx] by ChanServ
08:41<TiberiusTeng>I don't want to do it this way actually ...
08:41<TiberiusTeng>It'll be better like, say, this signal will be red if signal X is red
08:41<TiberiusTeng>and leave pathfinders untouched
08:41<Noldo>yes that sounds more like something a signal would do
08:42<TiberiusTeng>I don't feel comfortable with penality-based flow control ... since they are relative, not 'absolute'
08:42-!-yorick [] has joined #openttd
08:43<TiberiusTeng>some trains would flow into unwanted regions, if the network is really crowded or you missed something while planning
08:43<Noldo>pathfinding should be more higher level
08:43<Noldo>maybe a separate local one for pbs
08:43<TiberiusTeng>but I do like permissive speed signals ... those slowing yellow signals for example :p
08:44<TiberiusTeng>PBS is wonderful but not stable enough IMO ...
08:45<Noldo>priorities is really something that needs more elegant solution than the current one
08:46-!-yorick [] has quit []
08:46-!-yorick [] has joined #openttd
08:47-!-Gekz [] has quit [Remote host closed the connection]
08:50-!-Sacro [Ben@adsl-87-102-119-5.karoo.KCOM.COM] has joined #openttd
08:51<planetmaker>hey, ho
08:51<yorick>listen what he says, ho
08:51-!-[com]buster [] has quit [Read error: Connection reset by peer]
08:51-!-[com]buster [] has joined #openttd
08:53<Sacro>land ho?
08:53<@peter1138>westward ho!
08:54<TiberiusTeng>Yapf is fascinating ... I can't find the way it reads railway signals ...
08:54<Sacro>TiberiusTeng: i don't think it does
08:55<Sacro>see what happens in rail_cmd.cpp
08:55<TiberiusTeng>it relies feedback by train?
08:55<TiberiusTeng>oh yes, thank you
08:56<TiberiusTeng>gotcha ...
09:01<TiberiusTeng>so ... are there anybody already doing this? programmable signals?
09:01<Noldo>TiberiusTeng: I have a feeling I've seen an implementation somewhere
09:02<TiberiusTeng>hmm ...
09:03<TiberiusTeng>actually I do want to 'script' signals myself ...... not using some weird GUI and counter-intuitive boolean expression trees ... :p
09:04<@Belugas>as far as i know, there is nobody who currently is working on it
09:05<@Belugas>and i wonder, how is it really interesting?
09:06<@Belugas>what is it that makes you go in that direction, apart "it's in Patch"
09:06<@Belugas>even if i know you don't want the same approach but still...
09:06<yorick>you can filter trains by speed, cargo
09:06<yorick>but that are the only advantages
09:06<TiberiusTeng>it could make openttdcoop load balancer much more cleaner ... perhaps as one or two signals only
09:07<yorick>so could pbs
09:07<TiberiusTeng>without those 'signal-propagating' tracks
09:07<TiberiusTeng>I think PBS can't be used to implement load balancers ...
09:08<planetmaker>^^ difficult, I'd say
09:08<TiberiusTeng>i.e. break a train on the sideline to wait until mainline traffic passed
09:08<planetmaker>maybe we miss experience, though :). And hello TiberiusTeng :)
09:08<TiberiusTeng>it's not realistic! (well, servicing a factory with 1000 trains isn't realistic ...)
09:09<TiberiusTeng>perhaps it can be simplified to 'linking two distant (non-adjacent) signals'
09:09<planetmaker>a train waiting on a SL for ML traffic to pass is IMO realistic.
09:09<planetmaker>Just consider a coal train having the ICE pass by and not slowing it down.
09:09<TiberiusTeng>I mean 'using tracks to propagate occupation info' part :p
09:10<planetmaker>he. Yeah, full ACK :)
09:11<Noldo>well, I still think signals should be on tile edges instead of tiles
09:11<TiberiusTeng>but I think it's better to come up a feasible signaling schematic, before trying to implement it ...
09:11<planetmaker>Noldo: too big a change.
09:11<TiberiusTeng>it's kind of historic relics :p
09:12<planetmaker>needs reworking of map array is what my guts feeling tells me. A not-so nice one
09:13<TiberiusTeng>we need a new GUI for 'programming' the signals; but the one/the logic used by TTDP is far too complex IMO, and its functions are partially overlapped with which OTTD waypoints provide ...
09:13<planetmaker>Putting the logic in the signals is more reasonable, though IMO.
09:14<planetmaker>keeping waypoints as just that: waypoints to re-route certain trains over certain tracks
09:14<TiberiusTeng>yep. but 'what' logic ? only depends on some distant signals, or fully supporting boolean expression, even scripting ?
09:15<yorick>I'd say something like the conditional orders
09:15<planetmaker>TiberiusTeng: even now they do have a logic like "pass" "not pass", "not pass, if following are all red", etc
09:15<planetmaker>I meant logic in a rather general sense
09:15<TiberiusTeng>oh yeah, presignals.
09:15<planetmaker>logic could also be "red for trains slower than 100kph"
09:16<Noldo>that's not signaling
09:16<yorick>yes it is
09:16<yorick>because the pathfinder would avoid it
09:16<yorick>UNLESS it has no other choice
09:16<yorick>means that the signals could jam
09:16<TiberiusTeng>... and stuck there. ouch
09:17<TiberiusTeng>that's where permissive/absolute signal differs
09:17<TiberiusTeng>I don't think making speed-limiting signals absolute would be a good idea in OTTD ...
09:18<Noldo>signal has to allow every train pass, the question it should answer is 'when'
09:18<yorick>yes, we should revive the yellow signals for permissive red
09:19<Noldo>and yes maybe something like how fast
09:20<TiberiusTeng>merely providing signal linking would be a huge improvement, I think ...
09:20<TiberiusTeng>basically doing what openttdcoop does, in a way that don't occupy map tiles
09:21<TiberiusTeng>link A to F, G, H, I, for example
09:21<TiberiusTeng>if any one of F, G, H, I is red, A will be red
09:22<planetmaker>TiberiusTeng: I'm sure if you open that box of the pandora, other signal programming features will come, too - though maybe later
09:22<planetmaker>despite that, it's a nice feature!
09:22<Sacro>i want yellow signals
09:23<TiberiusTeng>planetmaker, that's why I think it's better to plan ahead before coding :p
09:23<planetmaker>TiberiusTeng: I won't contradict there.
09:23<TiberiusTeng>a listbox that shows all linked signals, with a 'X' to delete either one, clicking the signal will highlight it with white/flashing red cursor, etc ...
09:23<planetmaker>And a good planing will give you ground for many ways to programme signals. Doesn't mean that all are implemented
09:24<TiberiusTeng>I think it's better to derive the feature set we need, by some use-cases ...
09:24<planetmaker>Sacro: depends upon what "yellow signal" means
09:25<Sacro>planetmaker: it isn't red
09:25<Sacro>or green
09:25-!-frosch123 [] has joined #openttd
09:25<TiberiusTeng>the yellow signal itself looks cool, but the problem is how to use it ;)
09:25<TiberiusTeng>actually I like the 'permissive red' idea
09:25<planetmaker>Well. I certainly would have a need for signals with speed or cargo-type restrictions...
09:26<TiberiusTeng>but I think I'll need to digest YAPP and original signaling code first ...
09:28<planetmaker>hm... yapp could / should be quite independent of signal logic in whatever sense.
09:28-!-De_Ghosty [] has quit [Ping timeout: 480 seconds]
09:28-!-De_Ghosty [] has joined #openttd
09:29<TiberiusTeng>I just don't want to broke things :P
09:30<planetmaker>hehe. But I think it's mostly important to not break things in trunk :)
09:30<TiberiusTeng>ahh yes :p
09:30<TiberiusTeng>reminds me of savegame compatibility.
09:30<planetmaker>evil issue... :S
09:31<TiberiusTeng>ok, double-click to remove NewGRFs in new newgrf window done. :D
09:31<planetmaker>oh, you're working on that? Nice!
09:31<TiberiusTeng>an one-liner, actually :P
09:32<planetmaker>doesn't matter :)
09:32<yorick>also got the dragdrop?
09:32<Eddi|zuHause><TiberiusTeng> the yellow signal itself looks cool, but the problem is how to use it ;) <- in germany, "presignal" means it can be green/green (= next "mainsignal" is green), green/yellow (= next mainsignal is green, but slower speed limit) or yellow/yellow (= next mainsignal is red, start stopping)
09:32<yorick>Roest was working on that
09:32<Eddi|zuHause>presignals are always 1km before the main signal
09:32<TiberiusTeng>dragdrop's used to rearrange newgrf orders for now
09:33<TiberiusTeng>adding/removing with double-clicking is faster
09:33<yorick>nice :)
09:33-!-Wold [] has joined #openttd
09:33<Ammler>TiberiusTeng: post it at FS
09:33<TiberiusTeng>I think he was trying to save the size of newgrf window, but didn't finished it
09:33<yorick>Ammler, AFAIK, the devs don't want it because it's too big
09:34<Ammler>yorick: that window can be smaller then the original
09:34<TiberiusTeng>I made it resizable earlier
09:34<yorick>yes, but can you resize it on a 320x240 device?
09:35<TiberiusTeng>seems I should find a way to get the initial size
09:35<TiberiusTeng>maybe one-liner, maybe not, I dunno
09:35<TiberiusTeng>how should I do it?
09:35<Ammler>yorick: it has the size of the welcome GUI
09:35<yorick>Ammler, that one's too big
09:35<yorick>it doesn't fit on the nds
09:37<TiberiusTeng>perhaps I should cap it with _screen.width/height ?
09:37<TiberiusTeng>but wait, the NDS screen is not entirely touch-sensitive
09:38<TiberiusTeng>and I would hate to enlarge the window every time on my 1680x1050
09:38<yorick>but you can swap the screens on the nds
09:41<TiberiusTeng>display the old one in NDS and the new one elsewhere? :p
09:42<yorick>could be
09:42<yorick>but openttd could run on other devices
09:42<+glx>IIRC the old one is already too big
09:42<yorick>glx: I said that
09:45-!-Sacro [Ben@adsl-87-102-119-5.karoo.KCOM.COM] has quit [Quit: Leaving]
09:45<yorick>088: error: invalid conversion from `NetworkClientInfo*' to `NetworkClientInfo*'
09:46<Eddi|zuHause>you are doing it wrong ;)
09:47<TiberiusTeng>anyway, resizing of the window is still strange ...
09:47<TiberiusTeng>sometimes OnResize() will get impossible values
09:51<+glx>yorick: isn't there a const somewhere in this message?
09:51-!-Sacro [~Sacro@adsl-87-102-119-5.karoo.KCOM.COM] has joined #openttd
09:51<yorick>not that I know of
09:52*yorick rereads message, ah, there :)
09:52<Ammler>TiberiusTeng: the width is ok
09:52<Ammler>min size is 305*200
09:53<Ammler>that would fit the NDS, wouldn't?
09:53-!-[com]buster [] has quit [Read error: Connection reset by peer]
09:53-!-[com]buster [] has joined #openttd
09:53<TiberiusTeng>no it wouldn't
09:53<TiberiusTeng>256 x 192
09:54<Ammler>oh, that small?
09:54<TiberiusTeng>and I think the bottom area could be smaller when resizing
09:54<TiberiusTeng>when resizing to a small size ...
09:55<Ammler>you could skip the info box
09:55<Ammler>just name and parameters.
09:55<Ammler>name isn't needed either.
09:59<TiberiusTeng>go home ...
09:59-!-TiberiusTeng [Tiberius@] has quit [Quit: Leaving]
10:00-!-grumbel [] has joined #openttd
10:08<Eddi|zuHause>in that picture above, the status fields are way too large, they should never exceed 1/3 of the window, maybe add additional scrollbars
10:09<Eddi|zuHause>and maybe the separator in the middle should be smaller
10:11-!-dR3x4cK [~Miranda@] has quit [Quit: dR3x4cK]
10:14-!-curson [] has joined #openttd
10:29-!-TiberiusTeng [] has joined #openttd
10:33<planetmaker>or arange for small screens the windows vertically than horizontally as now
10:38<TiberiusTeng>sounds tedious to implement :p
10:44-!-Osai is now known as Osai^Kendo
10:45-!-ben_goodger [] has joined #openttd
10:47-!-Osai^Kendo is now known as Osai^Kendo`off
10:49<Eddi|zuHause>have you read the logs?
10:52-!-dR3x4cK [] has joined #openttd
10:52-!-stillunknown [] has quit [Read error: Connection reset by peer]
10:53<yorick>should a company password window really be able to close it's parent on window overflow?
10:55-!-mikl [] has quit [Quit: Leaving...]
10:56-!-[com]buster [] has quit [Ping timeout: 480 seconds]
11:01<CIA-4>OpenTTD: frosch * r13645 /trunk/src/tgp.cpp: -Codechange: Convert a macro into an inlined member function.
11:06-!-dR3x4cK [] has quit [Ping timeout: 480 seconds]
11:09-!-dR3x4cK [] has joined #openttd
11:13-!-stillunknown [] has joined #openttd
11:13-!-fjb [] has joined #openttd
11:31-!-blathijs [] has quit [Read error: Connection reset by peer]
11:31-!-blathijs [] has joined #openttd
11:32-!-TheMask97 [] has joined #openttd
11:32-!-TheMask96 [] has quit [Read error: Connection reset by peer]
11:34-!-Lakie [~Lakie@] has joined #openttd
11:40-!-Mchl [] has quit []
11:41-!-Singaporekid [] has joined #openttd
11:45-!-Singaporekid [] has quit []
11:45-!-Singaporekid [] has joined #openttd
11:50<yorick>TiberiusTeng: I just tested the opengl blitter on another pc, it works nicely :)
11:51<TiberiusTeng>yorick, what's the graphics board that PC's using ?
11:51<yorick>only some scrolling artifacts if I use the fast scrolling
11:51<yorick>I'll test
11:51<TiberiusTeng>and ... did you tried panning when zoomed out 8x ?
11:51<yorick>only some artifacts when using shift-scroll
11:51<TiberiusTeng>was it laggy ?
11:52<yorick>not laggy at all
11:52<yorick>with trees on toyland enabled
11:52<yorick>GeForce 7600 GS
11:52<TiberiusTeng>what's shift-scroll ? never used this function before
11:52<TiberiusTeng>ahh, almost the same card as mine :)
11:53<yorick>try holding shift and then pressing the arrow keys
11:53<yorick>268435456 bytes (256 MB)
11:53<yorick>1280 x 1024 - 32 bit
11:53<yorick>96 dpi
11:53<TiberiusTeng>ok I see
11:54<TiberiusTeng>hope it helps in some extreme (?) situations :p
11:54<yorick>any tools I can use to see the fps?
11:54<yorick>screen is on 60 fps, btw
11:59<yorick>panning horizontally seems more laggy than vertically
12:03<TiberiusTeng>perhaps you need to force disable VSync in NV control panel
12:04<Doorslammer|BRSet>Quick Q guys
12:04<Doorslammer|BRSet>The light in TT
12:04<Doorslammer|BRSet>Which way does the light come from?
12:04<yorick>from a universal direction
12:04<Doorslammer|BRSet>Right to left or left to right?
12:04<yorick>try looking at shared
12:04<yorick>shades of planes
12:04<Doorslammer|BRSet>I dont exactly know what to look at
12:05<@Belugas>right to left
12:05<Doorslammer|BRSet>I think the majority of the BR Set is wrong :S
12:05<Doorslammer|BRSet>I thought so :O
12:05<Doorslammer|BRSet>Cheers guys
12:07<@Belugas>well... it's not totally right to left, to be exact
12:08<@Belugas>more like north-east to south-west
12:08<yorick>try looking at the shades the planes have
12:08<Eddi|zuHause>the slopes should be the best source ;)
12:08<@Belugas>am looking at the slopes :)
12:08-!-Doorslammer|BRSet is now known as Doorslammer
12:10-!-Logix [] has quit [Ping timeout: 480 seconds]
12:10-!-stillunknown [] has quit [Read error: Connection reset by peer]
12:11<@Belugas>and yes, the planes confirm the slopes...
12:11<@Belugas>luckily for planes
12:16<CIA-4>OpenTTD: belugas * r13646 /trunk/src/toolbar_gui.cpp: -Change: typos and miss-aligned enum values
12:18<Doorslammer>Cock, got it wrong
12:18*Doorslammer slaps Doorslammer around a bit with a large trout
12:18<@Belugas>poor trout :(
12:18<Doorslammer>Flip horizontal in Paint should cure things, yes?
12:20<yorick>not really, no
12:21<yorick>because paint sucks at sprites
12:21<Doorslammer>I dont think its that bad surely?
12:21<Doorslammer>Purno uses it all the time apparently
12:23<yorick>you get in the way with shadows
12:24<fjb>Apropos planes. How do I calculate where I can build an airport when the town cares about the noise? I don't understand the distance formula in the wiki.
12:24<Doorslammer>I dont follow
12:27-!-[com]buster [] has joined #openttd
12:28<@Belugas>fjb, it depends what you want to achieve
12:28<@Belugas>the close the airport is frm the town center, the more noise the town will perceive
12:28-!-Doorslammer is now known as Doorslammer|BRSet
12:29<@Belugas>from 0 to 8 tiles away (with regard of the closest tile from town center), the ful amount of the airport noise is used
12:29<@Belugas>the further you are, the more it decrease
12:29<fjb>How do I calculate how far away from the town I have to place the airport.
12:29<@Belugas>it depends
12:30<@Belugas>define youre definition of "how far awy"
12:30<@Belugas>waht dos it means for you?
12:30<fjb>How many tiles away.?
12:30<@Belugas>you can put the airport next to the town center if you will
12:30<@Belugas>or even 100 tiles away
12:31<@Belugas>what do you want to ACHIEVE
12:31<fjb>Say the town allow a noise level of 13, but I want to build an airport which generates a noise level of 17. Where di I have to place it?
12:32<@Belugas>what is your town's setting for tolerance?
12:32<Doorslammer|BRSet>Thanks, BTW
12:32<fjb>Ofcouse I want to build it as near to the center of the town as possible.
12:33<fjb>Is there a setting for tolerance? Or is the the general tolerance for building stations?
12:34<@Belugas>ingame, it's on the difficulty level, last entry
12:34<fjb>Ok, I will look at it in the console.
12:35<@Belugas>so, you need a noise reduction of 4
12:36<@Belugas>the formula is:
12:36<fjb>Oh, how do I open the ingame console? I was the key above the tab key. But that doesn't work right now.
12:37<fjb>The initial configfile hat a tolarance of 1, should be the medium setting.
12:37<@Belugas>8 tiles times (4<- general multiplier) + (town_council_tolerance)
12:37-!-yorick [] has quit [Quit: Poef!]
12:38<@Belugas>tis gives you a factor
12:39<@Belugas>ho... simpler...
12:39<@Belugas> /* The steps for measuring noise reduction are based on the "magical" (and arbitrary) 8 base distance
12:39<@Belugas> * adding the town_council_tolerance 4 times, as a way to graduate, depending of the tolerance.
12:39<@Belugas> * Basically, it says that the less tolerant a town is, the bigger the distance before
12:39<@Belugas> * an actual decrease can be granted */
12:39<@Belugas> /* now, we want to have the distance segmented using the distance judged bareable by town
12:39<@Belugas> * This will give us the coefficient of reduction the distance provides. */
12:39<@Belugas> /* If the noise reduction equals the airport noise itself, don't give it for free.
12:39<@Belugas> * Otherwise, simply reduce the airport's level. */
12:39<@Belugas>the comments are saying every thing you need
12:41<fjb>Hm, tolerace is 1. So 8 + 4 * 1 = 12.
12:44<fjb>My airport makes 4 for noise than the town tolerates (town: 13, airport: 17). Does that get included into the calculation somewhere? Or is there no difference if the airport make one level too much noise or of makes 4 level or even 20 level too much noise?
12:45<@Belugas>not really. what is important is the distance from town center. It gets divided by the amount you found ealier (12)
12:45<@Belugas>so each 12 tiles,
12:46<@Belugas>you will get one noise level reduction
12:46<@Belugas>so to answer your quwesiton with words, you will nned 48 tiles ( 12 * 4) to achieve tp place your 17 noise airport when the town ony allows for 13
12:47<fjb>Ah, thak you. So to get the 4 needed level I have to build the airport 48 tiles away from the center of the town.
12:48-!-stillunknown [] has joined #openttd
12:48<fjb>Nearest edge of the airport counts? And the center of the town is the tile with the town name? And the distance is the usual manhattan distance?
12:48<@Belugas>if it was a permissive town (=0), it would have been based on 8 instead of 12 (8+(4*0))
12:50-!-[alt]buster [] has joined #openttd
12:50<fjb>I guess I under stood it now. Hope I don't forget it. Not easy to find a place for a big airpoert. But I like that new noise based system.
12:51-!-[com]buster [] has quit [Read error: Connection reset by peer]
12:51-!-[alt]buster is now known as [com]buster
12:52<@Belugas>i do too
12:52<@Belugas>i'm just happy that it's finaly in trunk...
12:54<fjb>Now we need kind of some passenger destinations thing. Or the possibility to transport cargos bidirectional. My planned international airport will have to be far away for any house.
12:57<@Belugas>funny how frequently "we need" is used when talking about one person's desires ;)
12:57<@Belugas>[12:45] <fjb> Nearest edge of the airport counts? And the center of the town is the tile with the town name? And the distance is the usual manhattan distance? <-- yes to all these questions
12:58<fjb>I think I'm not the only one who thinks that transporting cargos in both directions without picking up the just delivered cargos would be desirable.
13:03<fjb>With that feature it would be possible to build an airport out of town where no houses are, the feed it with a railway, bus or tram line and take the arrived passengers to the town using that same line.
13:08<TiberiusTeng>I think I'll fix NewGRF window first, then actually start researching distant signal linking.
13:09<TiberiusTeng>since waypoints can already do many things that route restrictions / programmable signals in TTDP ...
13:14<Eddi|zuHause>fjb: first step: add a "destination station" entry to the cargo packet
13:15<Eddi|zuHause>fjb: fill that with random values, do not use the value for anything important, and check if it doesn't desync
13:16<fjb>I don't know if that is the right step. Do we really need destinations for every cargo? And how do you set that destination? Wouln't it be enough to prevent cargo packets from getting back to the station they just came from?
13:16<Eddi|zuHause>it's the first step: add the POSSIBILITY to have destinations
13:17<Eddi|zuHause>if you use them for every cargo is a completely different question
13:18<Eddi|zuHause>and yes, depending on difficulty options, potentially every cargo should have a destination
13:18<fjb>I tried the last passenger destinations patch. it is really hard to get started with a passenger only network with that patch enabled. You simply have not network to reach every possible destination at the beginning of the game.
13:19<Eddi|zuHause>that's a balance issue
13:19<Eddi|zuHause>push that very far back the queue of features ;)
13:20<Eddi|zuHause>it MUST NOT desync, that's the main problem of the last patch
13:20<fjb>Just adding features with a goal in mind doesn't look like the way to go.
13:20<Eddi|zuHause>it's called "step", not "just randomly add a feature"
13:21<@Belugas>i agree with Eddi|zuHause
13:22<fjb>Did the desyncs come from the destination or from finding the routes?
13:23<Eddi|zuHause>the desyncs came from not properly storing the information in the savegame
13:24-!-Prof_Frink [] has quit [Remote host closed the connection]
13:24-!-ProfFrink [] has joined #openttd
13:24-!-ProfFrink is now known as Prof_Frink
13:24-!-Wolf01 [] has joined #openttd
13:25<fjb>Hm, destinations for all cargos would change the srtyle of the game. Not that I would care, but other might. So is it worth it?
13:25<fjb>Hello Wolf01
13:26<Eddi|zuHause>i said OPTION, do you actually read?
13:26<fjb>I read. But what is an option good for if almost nobody uses it.
13:27<@Belugas>wasting executable size
13:27<Eddi|zuHause>what survey tells you that it would not be used?
13:27<fjb>I fear that it will really slow down the game, even if not enabled.
13:27-!-ecke [~ecke@] has quit [Quit: ecke]
13:28<Eddi|zuHause>and i would not want to manage two different sized cargo packages, depending if the option is used or not
13:28<Wolf01>forcing users is not the right way to do a thing, an option is really better, also if doing so the feature will be used only by some people
13:28<Wolf01>but at least you satisfied both who wanted the feature and who don't want it
13:29<fjb>Wolf01: Ofcourse it would have to be an option. But even then you get some overhead in the code when the feature is disabled.
13:29-!-Phoenix_the_II [] has joined #openttd
13:29<Eddi|zuHause>the main feature of cargo destinations would be to reduce the micromanagement needed for limited-acceptance-industries like PBI or ECS
13:30<Eddi|zuHause>because cargo would automatically be distributed between different such industries
13:30<fjb>ECS is a bit hard to handle. I don't know if that would be easier with the destination feature.
13:31<Eddi|zuHause>but that is not the question at all
13:31<@Belugas>automatic distribution...
13:31<Eddi|zuHause>the problem at hand are the game internals, the very foundation of the patch
13:31-!-[com]buster [] has quit [Read error: Connection reset by peer]
13:31<@Belugas>another tool to make the game easier
13:32<Wolf01> <fjb> [...]But even then you get some overhead in the code when the feature is disabled. <- I'm not really sure, but I think that a well written code might "fix" this
13:32<@Belugas>a button and see it work on itself!
13:32<Eddi|zuHause>Belugas: no, you still have to run the trains ;)
13:32-!-[com]buster [] has joined #openttd
13:32<@Belugas>wanna bet someone would come up with such an idea ?
13:33<Eddi|zuHause>there's a difference between "laziness" and "extensive micromanagement"
13:33<Wolf01>like the daylength, if you set it to 1, the game behave in the same way, if you set it > 1 you open the pandora's box
13:35<Eddi|zuHause>Belugas: be glad i didn't use the r-word ;)
13:36<Eddi|zuHause>businesses plan their transports based on supply and demand, and THEN ask the transport company to transport it
13:36<Wolf01>and I really know it well, I'm writing a software with a lot of flags and options which influence each others, so I must be sure that when I enable an option, all the others must work together the new one, but when I disable an option, this should not exist at all
13:37<fjb>Industries with stockpiling can change their mind a few times between loading a vehicle and the vehicle reaching the industry. I don't think that it can be used to distribute the cargos is respect to stockpiling.
13:38<Eddi|zuHause>very loosely related question: why don't wagons have any running cost?
13:38<Wolf01>yeah, good point
13:38<ccfreak2k>Because they would have maintenance costs instead.
13:38<Eddi|zuHause>(or change the running cost of the engine)
13:41<fjb>And making the new option play nicely together with all other options is not the biggest problem. Look at the amount of cargos that gets transportet. So even a small overhead will have an impact.
13:41<Wolf01>mmmh, since when I started the hotkeys patch I didn't read any suggestion, do this mean that I can continue my work?
13:42<Eddi|zuHause>fjb: don't talk about overhead before you implemented and profiled anything
13:43<Eddi|zuHause>Wolf01: several people already started hotkey patches, did you talk with them?
13:44<Wolf01>I never seen an hotkey patch, so I don't know who talk to
13:44<fjb>Eddi|zuHause: You should think about the balance betwenn code duplication and compiting overhead before you start to rewrite half of the game.
13:45<Eddi|zuHause>nobody said anything about a rewrite
13:45<Eddi|zuHause>i said: add a member to a struct, and then make sure it is properly storedd
13:46-!-Boyinblue0 [] has joined #openttd
13:46<CIA-4>OpenTTD: skidd13 * r13647 /trunk/src/ (6 files): -Codechange: replace MAX_UVALUE() for std types with the equivalent constant
13:52-!-TiberiusTeng [] has quit [Ping timeout: 480 seconds]
13:56-!-[com]buster [] has quit [Read error: Connection reset by peer]
13:57-!-Logix [] has joined #openttd
13:58<fjb>How about remembering which station a cargo packed has last seen. And a vehicle will not pick up that packet if the remembered station is in the vehicles order list?
13:59<eekee>that's my favoured option, if that counts for anything. I think it acheives quite a lot from a simple process
14:01<Eddi|zuHause>fjb: rembember what i said? add struct, check multiplayer compliance... there was nothing said about WHAT you write in the struct member!!
14:01-!-mikk36 [] has joined #openttd
14:02<Eddi|zuHause>and remembering last station will solve nothing, it will just push the problem to the next level (3 vehicles going in circles)
14:02<mikk36>q: what could be the problem when i i get error when starting up autopilot, stating that there's an error for math function, while executing expr (pow(2,[get_setting patches map_y])) ?
14:02<+glx>mikk36: using trunk?
14:02<Eddi|zuHause>mikk36: .cfg format has changed
14:03<Eddi|zuHause>several weeks ago
14:03<mikk36>no autopilot until someone has updated it ?
14:03<+glx>so autopilot needs to be updated for trunk
14:03<mikk36>ok then
14:04<Eddi|zuHause>[get_setting patches map_y] <- replace the "patches" there with the new group
14:04<Eddi|zuHause>and in the map_x line as well
14:04<+glx>and all get_setting lines indeed ;)
14:07<fjb>Eddi|zuHause: That will ofcourse be no automatic distribution system. You will still have to plan your routes. but it woul make bidirectinal traffic possible.
14:07<Eddi|zuHause>fjb: i understand what it dies
14:08<Eddi|zuHause>but i said it will not solve anything
14:08<Eddi|zuHause>scenario: 3 airports
14:08<Eddi|zuHause>plane 1: 1<->2
14:08<Eddi|zuHause>plane 2: 2<->3
14:08<Eddi|zuHause>plane 3: 1<->3
14:08<fjb>It will solve the no bidirectional distribution problem.
14:08<Eddi|zuHause>the passengers might go in circles indefinitely
14:09<Eddi|zuHause>because they get "catched" by a plane before they can enter the shuttle bus
14:09<fjb>Yes. When your network is not properly made you carry the passengers in circle. Just as you do tzoday.
14:09<Eddi|zuHause>it shifts the problem, does not solve it
14:09<Ammler>mikk36: do you need a patch for ap?
14:10<Eddi|zuHause>as thus i would definitely reject the "solution"
14:10-!-yorick [] has joined #openttd
14:11<fjb>You can always build unusual networks. And a feature is not no solution to a problem because it is not foolproof.
14:11<frosch123>Eddi|zuHause, fjb: You should better come up with a way, to determine which station a vehicle will visit next. Esp. when not using 'non-stop' orders.
14:11<Eddi|zuHause>fjb: planes connecting different airports is definitely not an "unusual" network
14:12<fjb>frosch123: That sounds like a loop through the orders list.
14:12<frosch123>when not using 'non-stop'?
14:12<Eddi|zuHause>fjb: trains need not have all stations they visit in the orders
14:12<fjb>Eddi|zuHause: A planed connection please, not just random connections without thinking.
14:13<Eddi|zuHause>you are talking rubbish
14:14<Eddi|zuHause>both frosch123's and my objections are valid reasons to reject your approach
14:14<fjb>frosch123: Hm, ok, because of that I said that vehicle should not pick up the packet if the station it last came from is anywhere on the orders list, not just the next station on the list.
14:14<Eddi|zuHause>fjb: that does not catch ring-traffic
14:15<Eddi|zuHause>and again, the station need not be in the order list AT ALL
14:15<fjb>Eddi|zuHause: That is what I wrote.
14:16<fjb>It still needs a well planes network then, no random network.
14:16<Eddi|zuHause>you mean "planned"
14:17*frosch123 came to the conclusion that there will never be way to predict the next station. Only working solution (I know of) would be to let the user specify for each order, which passengers are allowed to board. But who will be able to use such a system...
14:18<Eddi|zuHause>that's exactly what i mean, the approach is just not practical because it is too fixed on patching up a symptom, not the cause of the problem
14:18<fjb>frosch123: When thinking about it, you are right. That feature would have to be coupled to nonstop orders. I didn't think about that.
14:18<Eddi|zuHause>and no matter how many patches you stick on, there will always be wounds that are bigger than the patch
14:19<fjb>Eddi|zuHause: But I don't think your automatic distribution system will really solve anything. At least not the stockpiling difficulties.
14:20<Eddi|zuHause>fjb: that is not the goal at all
14:20<fjb>Eddi|zuHause: And it is big news to me that you can reject any new approach any new feature.
14:21<Eddi|zuHause>fjb: have you learned the magic of a CONDITIONAL clause yet?
14:22<fjb>Eddi|zuHause: So why did you add your selself then?
14:22<Eddi|zuHause>fjb: assume an implicit "if i was in the position of a dev"
14:23<Eddi|zuHause>fjb: and i already got at least one dev who backed me up on some of my statements and conclusions
14:24<frosch123>what? - I was going against both of you...
14:25<Eddi|zuHause>i was not talking about you ;)
14:25<frosch123>ah ok :) nevermind
14:26-!-Boyinblue0 [] has quit []
14:27<Eddi|zuHause>anyway, the last paxdest patch used a prediction about connection based on the order list, and then expanded these connections once stations were actually visited by a vehicle [under the assumption that the vehicle will at some point visit the station again]
14:27<@Belugas>who then?
14:28<Eddi|zuHause>the stations built up a number of possible connections and a statistic about how long the travel time there usually takes, and then made decisions what vehicles the passengers would take
14:29<fjb>Belugas: I fear he was talking about you.
14:29-!-Logix [] has quit [Ping timeout: 480 seconds]
14:29<Eddi|zuHause>[19:21] <Belugas> i agree with Eddi|zuHause <- proof ;)
14:30<Eddi|zuHause>[although the discussion went quite far since then]
14:31<@Belugas>that is what i wold call hijacking!
14:31<Eddi|zuHause>anyway, the problem at hand was storing any kind of station [whether past or future] in the cargo packet
14:31<Eddi|zuHause>once you get that feature stable, you can talk about what to do with it
14:31<@Belugas>[13:18] <Eddi|zuHause> it's called "step", not "just randomly add a feature"
14:31<@Belugas>[13:18] <@Belugas> yeah
14:31<@Belugas>[13:18] <@Belugas> i agree with Eddi|zuHause
14:31<Eddi|zuHause>everything else is just wild speculation
14:32<@Belugas>It won't give up
14:32<@Belugas>it wants me dead
14:32<@Belugas>and God damn this noise
14:32<@Belugas>inside my head
14:38-!-Singaporekid [] has quit [Quit: :o]
14:43-!-Doorslammer|BRSet [] has quit []
14:44-!-powell [] has joined #openttd
14:45-!-Wold [] has quit [Quit: Leaving]
14:51<@Belugas>i wonder...
14:52<@Belugas>maybe that cargo knowing its dstination may be solved looking at the other angle
14:53<@Belugas>if there is the POSSIBILITY for a cargo to move to more than two stations, then it might be possible to have some kind of a decent system
14:53<@Belugas>but that means an intelligence somewhere on the cargo management
15:07-!-Lakie [~Lakie@] has quit [Quit: bbml]
15:08-!-Brianetta [] has joined #openttd
15:09<mikk36>why is there so short message size limit ?
15:11<yorick>Belugas: the chat limit got decreased drastically somewhere between 0.6 and current trunk
15:13<@Belugas>by how much chars?
15:13<@Belugas>since when?
15:13<@Belugas>it's supposed to be 64 chars, i believe
15:14<yorick>I don't think it is
15:14<yorick>I'll check 0.6
15:15<planetmaker>it is 64 chars or so. But longer would be better. And it was longer before :), but got fixed
15:15<yorick>I can fit the alfabet in it 3 times
15:16<yorick>in 0.6
15:16<yorick>since when is decreasing limits called fixing?
15:16<Eddi|zuHause>afaik it was limited by the window width before, which is totally unrelated to the number of characters
15:17<@Belugas>since when imprecision drives everything?
15:17<yorick>but why did it have to be made this short?
15:18<mikk36>i neither
15:18<yorick>and 64 chars is really short
15:18<Eddi|zuHause>that's what you get when you have to go with the majority :p
15:19<eekee>argh 64 is impossible! I used an environment with a 255-char limit for a long time, that was harsh
15:19<yorick>like I can only fit a message in it that's exactly this lenght
15:19<mikk36>1 sentence per message is really short
15:19<Eddi|zuHause>provide a patch that adds a hook to split lines at word boundaries ;)
15:20<Eddi|zuHause>[not necessary ALL word boundaries]
15:20<yorick>juse I'd rather have a longer chat limit
15:20<yorick>because openttd does the linebreaking, no?
15:21<planetmaker>it's reasonable to have a limit so that a message where you fell asleep on your keyboard doesn't flush the whole chat.
15:22<Eddi|zuHause>you see, when you write a really long line that makes absolutely no sense but you want to not press enter inbetween it automatically figures out which word will overlap the line limit and split the line before that word, so you can safely type on and on and on and on till the dawn breaks and never get interrupted by any stupid line limit
15:22<yorick>irc also has a line limit somewhere
15:22<Eddi|zuHause>it adds line breaks on display, but not on sending
15:22<yorick>altho it was previously SHORTER than the openttd limit
15:22<Eddi|zuHause>and the send buffer is what limits the line length
15:22<Ammler>yorick: you can also see on our ps, that ottd can still handle longer lines, as it does with chat from IRC
15:23<planetmaker>a limit doesn't hurt as long as it's not limit to usual sentences :)
15:23<Eddi|zuHause>IRC has 512 characters limit afaik
15:23<planetmaker>and my usual sentences easily cover twice or three times as many characters as 64 :)
15:23<yorick>Ammler, yes, the actualy message is tranffered over a much longer char
15:23<yorick>I find it stupid that you can not write messages as long as the limit gui-wise
15:24<Ammler>the ingame chat is a bug, I assume and not feature :-)
15:24<yorick>it is ;(
15:24<planetmaker>rather both: buggy feature :P
15:25<Ammler>yorick: as network patcher, you should be able to fix it :P
15:25<planetmaker>but bug sounds so... wrong. Let's call it a feature with room for improvements :)
15:25<yorick>Ammler, I'm already looking into it
15:26<Eddi|zuHause>a feature with room for "features" :p
15:26<yorick>#define MAX_TEXT_MSG_LEN 1024
15:27<yorick>can I now kill the one who tought of that 64 gui-limit
15:27<yorick>@calc 1024/64
15:27<@DorpsGek>yorick: 16
15:27<yorick>you made the gui-chat limit actually 16 times smaller than it could be
15:27<yorick>congratulations :)
15:28<+glx><yorick> #define MAX_TEXT_MSG_LEN 1024 <-- and how does that fit in a packet?
15:29<yorick>glx, we have *tcp(
15:29<ben_goodger>glx: with an MTU of 1500 I'd expect it to fit quite nicely
15:29<+glx>yorick: and the 64 limit appeared with window classification
15:29<fjb>jumbo packets...
15:29<+glx>because all other text input are 64
15:31<yorick>glx: could you extend that text input limit?
15:32-!-Frostregen [] has joined #openttd
15:34<+glx>not easy
15:34<eekee>but it's daft for a chat window to have no longer length than name windows. It should be a different class, somehow :/
15:35<yorick>glx: yeah, it involves changing 2 numbers
15:36<+glx>yorick: but other text input should stay 64
15:36<eekee>can you subclass the general text input?
15:36*eekee is thinking in general OO terms, knows nothing of C++
15:37<yorick>glx: should they?
15:38<yorick>they should?
15:38-!-Frostregen [] has quit [Quit: und weg]
15:40<yorick>possibly make a var somewhere in the querystring struct that'd allow for changing the size?
15:42<yorick>hmmm no
15:43-!-Wolf01 is now known as Wolf01|AWAY
15:43<yorick>is there no way you could override edit_str_buf and orig_str_buf when initializing the NetworkChatWindow
15:44<yorick>InitializeTextBuffer(&this->text, this->edit_str_buf, lengthof(this->edit_str_buf), 0); <-- how about replacing that with InitializeTextBuffer(&this->text, this->edit_str_long_buf, lengthof(this->edit_str_long_buf), 0);?
15:46<+glx>and adding a buffer unused for most of text inputs?
15:46<+glx>memory waste
15:46<yorick>better idea?
15:48<yorick>but yes, adding a 1 kb per editbox is a memory waste :)
15:53<yorick>you could also define a whole new querystringbasewindow
15:55-!-Dred_furst [] has quit [Read error: Connection reset by peer]
15:55<+glx>yorick: it will take some time to make it in a clean way
15:57<eekee>wtf? how many edit boxes could anyone have open at once? How is 1KB a waste?
15:58<yorick>1024 chars
15:58<yorick>dunno if that's a big wast
15:58<yorick>and eekee, try 25
15:59<+glx>only one usable at a time
16:00<yorick>but the 25 buffers
16:02<eekee>25k instead of 1.6k. okaaay.. hmm, well, my PDA (that thing I carry in my pocket which has barely enough processing power to run a 128x128 map with ECS) has 64 megabytes of ram. 25k is 0.04% of that
16:03<yorick>if I calculated the memory usage of a char[1024] correctly
16:03<yorick>and I don't think I have, taking unicode into concideration
16:04<eekee>well double or quadruple my numbers if you like. 4 bytes per char comes to 0.15%
16:04<eekee>There is avoiding bloat, there is lightness and purity, and then there is extreme asceticism! ;)
16:04<eekee>Sorry if that was OTT
16:05<yorick>just an unused char[1024] for every editbox
16:05<yorick>you got 100kb at full
16:05<yorick>and 100kb on a 100MB-usage map is
16:05<@Belugas>let's all scrap trunk!! scrap code!!!
16:06<yorick>hmm...quite much, now I think about it
16:07<yorick>you're wasting 100kb for multiplayer you might not even want to use
16:07<eekee>yorick: 0.1%
16:07<@Belugas>hre, and there and why not even ther?? then, it's bloated every where!!!
16:07<eekee>yorick: dude, please stop encouraging pain for fractions of a percent
16:08<yorick>ok, then go at convincing that whale next door
16:08<yorick>the one that tries to believe he can rhyme
16:11<@Belugas>you know what the whale is going to do next?
16:11<eekee>bloat is like ecology. Worry produces a lot of ascetiscism and very little real gain
16:11<yorick>Belugas: whales have no feet
16:12-!-yorick was kicked from #openttd by Belugas [no, but they can click a mouse!]
16:12-!-yorick [] has joined #openttd
16:17-!-stillunknown [] has quit [Read error: Connection reset by peer]
16:17-!-Hendikins [~wolfoxout@] has quit [Quit: Any quit message, no matter how short, is a smart arse comment to those left behind]
16:18-!-KritiK [] has joined #openttd
16:18-!-stillunknown [] has joined #openttd
16:25<@Belugas>heheh just had a "bug" report at work
16:26<@Belugas>the Maestro card of my customer has beeen refused
16:26<@Belugas>the Maestro card of my customer has beeen refused
16:26<@Belugas>it is a debit, not a credit card
16:27<@Belugas>so use it as such!
16:27<yorick>wtf, I'm running tto in dosbox, and the cursor escapes the dosbox window :)
16:33<+glx>not surprising, it's not supported
16:34<ccfreak2k>Congratulations, you found a feature!
16:34<yorick>glx, yes, but should it assert?
16:34-!-Progman [] has quit [Remote host closed the connection]
16:35<+glx>better assert than crash later doing something else
16:35<yorick>Assertion failed!
16:35<yorick>File src/oldpool/h Line: 125
16:35<yorick>Expression: index < this->GetSize()
16:35<yorick>0.6 just crashes
16:35<yorick>trunk asserts
16:36<+glx>asserts are disabled for releases
16:36<yorick>that could help
16:36<yorick>can it not say "incompatible savegame"?
16:37*Ammler would like to see language files like grfs, just away from trunk.
16:37<yorick>ah, second failure: Station: failed loading savegame: too many Station
16:37<yorick>I built 3 stations :)
16:37<Ammler>it would make update so much faster...
16:37<+glx>openttd doesn't know TTO format
16:38<yorick>does it know ttd format?
16:38<yorick>and does ttd know tto format?
16:39<eekee>OTTD used to load TTD format, if I remember right
16:40<+glx>and it still loads it
16:49<ccfreak2k>"TTO save games not supported" would probably be the best way to handle it.
16:49<ccfreak2k>Assuming TTO saved games are different from TTD.
16:52-!-yorick [] has quit [Quit: HydraIRC -> <- Like it? Visit #hydrairc on EFNet]
16:52<@Belugas>ho yeah... a red box popup!!
16:53-!-curson [] has quit [Quit: If everything seems to be going well, you have obviously overlooked something.]
16:54*Belugas goes home
16:54<@Belugas>bye bye
16:54<Eddi|zuHause>ccfreak2k: the problem is to get to know the difference
16:58-!-Zeal [] has joined #openttd
16:58-!-Zealotus [] has quit [Read error: Connection reset by peer]
16:58-!-Osai^Kendo`off is now known as Osai
16:59<CIA-4>OpenTTD: frosch * r13648 /trunk/src/tgp.cpp: -Cleanup (r5303): Amplitudes should be amplitudes and not amplitudes/16.
17:56-!-jni_ [] has quit [Ping timeout: 480 seconds]
18:00-!-tokar [] has quit [Remote host closed the connection]
18:09-!-Zorni [] has joined #openttd
18:10<Eddi|zuHause>... that was a very random line do throw in the middle of an idle time ...
18:16<Touqen>trigeminal neuralgia
18:16-!-Zorn [] has quit [Ping timeout: 480 seconds]
18:17-!-Zorni [] has quit [Ping timeout: 480 seconds]
18:24-!-thgergo [] has quit [Quit: Leaving.]
18:38-!-Lakie [~Lakie@] has joined #openttd
18:58-!-frosch123 [] has quit [Remote host closed the connection]
19:11-!-Progman [] has joined #openttd
19:21-!-Wezz6400 [] has quit [Quit: Caught sigterm, terminating...]
19:22-!-Osai is now known as Osai`off
19:22-!-Touqen [] has quit [Ping timeout: 480 seconds]
19:28-!-Farden [] has quit [Quit: ( :: NoNameScript 4.2 :: )]
19:31-!-Brianetta [] has quit [Quit: Tschüß]
19:31-!-Touqen [] has joined #openttd
19:33-!-demon_ [] has joined #openttd
19:35-!-Zahl [] has quit [Quit: (~_~]"]
19:58-!-demon_ [] has quit []
20:11-!-stillunknown [] has quit [Ping timeout: 480 seconds]
20:12-!-Digitalfox [] has quit [Quit: Leaving]
20:16-!-Wolf01|AWAY is now known as Wolf01
20:16-!-Wolf01 [] has quit [Quit: Once again the world is quick to bury me.]
20:18-!-Progman [] has quit [Remote host closed the connection]
20:33-!-Eddi|zuHause2 [] has joined #openttd
20:37-!-Digitalfox [] has joined #openttd
20:40-!-Eddi|zuHause [] has quit [Ping timeout: 480 seconds]
20:42-!-thelastwaltz [] has joined #openttd
20:42-!-thelastwaltz [] has quit []
20:59-!-Gekz [] has joined #openttd
21:06-!-powell [] has quit [Quit: Leaving]
21:16-!-glx [] has quit [Quit: bye]
21:19<@Belugas>[16:52] <Eddi|zuHause> ccfreak2k: the problem is to get to know the difference <--- indeed. There is about not way to really know for sure.
21:19<@Belugas>that is why
21:19<Gekz>about not way?
21:19-!-KritiK [] has quit [Quit: Leaving]
21:20<@Belugas>ho... look at me! I'm a clown!!
21:54-!-Logix [] has joined #openttd
22:08-!-fjb [] has quit [Remote host closed the connection]
22:10-!-Lakie [~Lakie@] has quit [Quit: Night All./Quit Night All.]
22:14-!-dR3x4cK [] has quit [Quit: dR3x4cK]
22:18<ccfreak2k>"Can't clear this area..... Object in the way"
22:18<ccfreak2k>Well yes...
22:38-!-einKarl [] has quit [Remote host closed the connection]
22:59-!-grumbel [] has quit [Quit: Client exiting]
23:00-!-TinoM| [] has joined #openttd
23:03-!-elmex_ [] has joined #openttd
23:07-!-elmex [] has quit [Ping timeout: 480 seconds]
23:07-!-TinoM [] has quit [Ping timeout: 480 seconds]
23:07-!-elmex_ is now known as elmex
23:15-!-ecke [~ecke@] has joined #openttd
23:16-!-Logix [] has quit [Ping timeout: 480 seconds]
23:28-!-shodan [] has joined #openttd
23:31<ccfreak2k>Is there a patch/patch setting for allowing same industries next to each other?
23:32<Phantasm>Somewhere there is allow multiple industries of same type in town.
23:33<ccfreak2k>I switched that on already. :|
23:33<Phantasm>Anything else? ;P
23:34<ccfreak2k>Well, it didn't work.
23:34<Phantasm>It does work, but it doesn't mean you'll get 10 coal mines in each town.
23:35<ccfreak2k>Well that's what I meant.
23:35<Phantasm>It allows it, but the odds for getting multiple industries nearby are quite low.
23:35<Phantasm>Make a scenario if you want that.
23:36<ccfreak2k>Assertion failed.
23:37-!-curson [] has joined #openttd
23:37<ccfreak2k>openttd.cpp:142, expression: 0
---Logclosed Sat Jun 28 00:00:11 2008