IRC logs for #openttd on OFTC at 2008-06-27
⏴ go to previous day
00:04:23 <Nite> idea - teh different "slots" i was about could exist via a building that you attach to a station (a goods depot or pax hall)
00:04:49 <Nite> you then cpould click that building to use this section of the station
00:06:12 <Nite> i even didnt understan why autoreplace needed an extra window
00:06:12 *** ChanServ sets mode: +o orudge
00:08:14 <eekee> yeah I had replace issues earlier. I see now how powerful the replace system is, but it's a bit of a pain having to go via the one main vehicles list instead of, say, a station's train list.
00:08:55 <eekee> also it's got a bug: the waggon removal option is global, so if you run 2 replacements at the same time, you can't have one with waggon removal and one without
00:09:45 <Nite> well this dont looks like bug to me
00:11:11 <Nite> i almost never use the groups, sorting or autogrouping by shared orders would have done it for me
00:11:49 <Nite> (i know you can add all trains sharing to a group a train is alredy in)
00:12:56 <Nite> ottd is at a stage hardly to learn it from scratch if not grown with it.
00:13:33 <eekee> you have to muck about finding one train of the ones you wantin the big list. Pointless
00:14:47 <SmatZ> autogrouping, and preferably with naming groups by destinations, would be useful
00:15:39 <Nite> well its not to hard to find a train (they have names/numbers if u noticed ;-P)
00:16:12 <Nite> but its still lot of click drag click - not really bad and not really good for me.
00:16:30 <eekee> oh it is. Not everyone can simply look at a list and pick out the entry they want
00:18:43 <Nite> ok autogroup by shared would be just fine
00:19:26 <Nite> guess i have to play a round of TTO then i would quickly stop to complain ;-)
00:20:34 <SmatZ> there is a function to add all shared vehicles to the same group
00:20:51 <SmatZ> and then add all shared vehicles
00:21:24 <Nite> true (i mentioned that above)
00:21:56 <eekee> SmatZ: just because all those steps are easy for you doesn't mean they are easy for everyone. ;)
00:21:59 <Nite> what we think about is to show trains grouped by shared orders (routes) withou tdoing anything.
00:22:20 <Nite> well erm - klicking a one button of course.
00:22:27 <SmatZ> eekee: I don't say they are easy, but it is easier than manually moving 50 vehicles from one group to another :)
00:23:30 <SmatZ> I have done a simple patch for that... but sure there is one at tt-forums, that is far advanced
00:23:49 <Nite> well there is "All trains" "Ungrouped trains" and there simply has to be a "grouped by shared orders" button in future
00:24:19 <eekee> why can't you just access vehicle replace from a station or shared order list?
00:24:39 <Nite> sure ok there are patches in ottd like sand on the beach you are right ...
00:24:57 <ccfreak2k> In the SVN builds, does "Go non-stop to <station> (full load any cargo)" mean that it will speed through any stations it goes through?
00:25:50 <ccfreak2k> This new orders GUI is confusing.
00:26:11 <Nite> if "ttdpatch compatible" is ON trains are in nonstop automatically ...
00:26:39 <Nite> sry but the orders gui looks like tto
00:27:23 <SmatZ> eekee: you would have to remember replace rules for each station / depot / shared orders group
00:27:26 <Nite> yeah the orders gui looks like tto
00:27:56 <ccfreak2k> never actually played the original.
00:28:09 <Pikka> no delete key in original D:
00:28:16 <SmatZ> [02:25:37] <ccfreak2k> In the SVN builds, does "Go non-stop to <station> (full load any cargo)" mean that it will speed through any stations it goes through? <== yes I would say
00:28:22 <SmatZ> it won't stop at intermediate stations
00:28:27 <Pikka> you have to close every window one at a time clicking on the x's :P
00:28:50 <SmatZ> difference between TTD and TTO? the DEL key! ;-)
00:29:14 <SmatZ> ccfreak2k: "Go via" won't stop at destination
00:29:16 <ccfreak2k> I thought the difference is 11.
00:29:40 <ccfreak2k> Because O - D = 11. :)
00:29:58 <Nite> ahhh ttd means (transport tycoon deletekey)
00:31:03 <Nite> i never played the "original deluxe" just the "original original"
00:33:05 *** Eddi|zuHause2 has joined #openttd
00:37:44 <ccfreak2k> Famous Original Ray's.
00:42:36 *** [alt]buster has joined #openttd
00:42:38 *** [alt]buster is now known as [com]buster
00:46:25 *** Digitalfox has joined #openttd
01:00:04 <Nite> was there wait for full load in tto?
01:04:23 *** [com]buster has joined #openttd
01:20:12 <Belugas> i don't know about TTO. But it os present in TTD. I would assume it was there too
01:20:39 <glx> in TTD it's a real full load
01:21:26 <Nite> ok and in tto i ossume it was one cargo full
01:22:15 <glx> I guess if it has full load it's a real one too
01:23:17 <Nite> im waiting for the 1/2 and quarter load in ottd trunk ;) as well as selecting real or unreal full load as an order
01:23:33 <SmatZ> I think Full Load was the same in TTD and TTO, that is Full Load All
01:24:08 <Nite> i guess it was full load one
01:24:45 <Nite> some massage from the subconcious
01:26:47 <CIA-4> OpenTTD: belugas * r13643 /trunk/src/toolbar_gui.cpp: -Codechange: Enumify some loosely related values been used in the toolbar resizing processes
01:30:37 <Belugas> for the last 2 years!
01:30:48 <Belugas> now... time for my fingers to have fun...
01:30:56 * Belugas goes back to guitar playing
01:46:13 *** [alt]buster has joined #openttd
01:46:15 *** [alt]buster is now known as [com]buster
01:59:40 <Belugas> Mogai - Dial.Revenge base track is recorded, as well as a little solo :D
01:59:51 <Belugas> now... some bridges to work on
02:00:25 <ccfreak2k> Q: Why is my train waiting at a signal, even if he has the all clear?
02:00:31 <ccfreak2k> A: The game is paused. :|
02:00:48 <Belugas> at least you now know the answer ;)
02:01:05 <Belugas> iirc, there even was a bug report becasue of that...
02:01:17 <Belugas> arhg... our interface is too hard to learn..
02:16:57 <ccfreak2k> The hilighting for YAPP on maglev rails isn't all that clear.
02:27:04 <CIA-4> OpenTTD: belugas * r13644 /trunk/src/toolbar_gui.cpp:
02:27:04 <CIA-4> OpenTTD: -Fix(r13643): compare an apple with an apple. MSVC seems to not care, but some other compilers do.
02:27:04 <CIA-4> OpenTTD: Thanks to glx :)
02:30:34 *** TiberiusTeng has joined #openttd
02:38:55 <ccfreak2k> It's too bad there's no mechanism to allow other companies to use your railroads.
02:39:12 <TiberiusTeng> infrastructure sharing patch
02:39:27 <ccfreak2k> There's a patch for everything, isn't there?
02:42:45 <Nite> merging companys would be cool
02:54:46 *** grumbel has joined #openttd
02:58:21 *** Digitalfox has joined #openttd
03:32:11 <Nite> anyone knowing of a really good airline managing sim?
04:25:28 <ccfreak2k> I saw a Sim Airport or something at Best Buy about five years ago..
04:26:26 <theEd> Airline Tycoon isn't bad, albeit rather limited as to what you can do
05:23:02 <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
05:23:07 <Eddi|zuHause2> but that's a long time ago...
05:24:25 <ccfreak2k> But it's soooo much effort to drag the cursor all the way over to the toolbar.
05:24:54 <Eddi|zuHause2> the toolbar was organised differently in TT ;)
05:25:12 <ccfreak2k> And screens were so much smaller, too.
05:26:06 <Eddi|zuHause2> in TTD they moved the money out of the main toolbar, and added the status bar at the bottom
05:28:52 *** raimar2 has joined #openttd
05:30:37 <Eddi|zuHause2> now that i think of it, the "close all windows" was probably a world editor feature
05:46:42 *** einKarl has joined #openttd
06:11:51 *** Osai`off is now known as Osai
06:46:05 *** GoneWacko has joined #openttd
06:50:48 *** dR3x4cK has joined #openttd
07:33:24 *** Eddi|zuHause has joined #openttd
07:39:28 *** Born_Acorn has joined #openttd
07:39:28 *** Ridayah_ has joined #openttd
07:39:28 *** De_Ghosty has joined #openttd
07:40:38 *** Osai is now known as Osai`off
07:41:11 *** Osai`off is now known as Osai
07:42:20 *** Osai is now known as Osai`off
07:49:14 *** Rexxars has joined #openttd
07:53:07 *** Wezz6400 has joined #openttd
07:56:14 *** Doorslammer|BRSet has joined #openttd
08:02:38 *** thgergo has joined #openttd
08:08:57 *** Born_Acorn has joined #openttd
08:08:57 *** Ridayah_ has joined #openttd
08:08:57 *** De_Ghosty has joined #openttd
08:16:27 *** Farden123 has joined #openttd
08:17:10 *** stillunknown has joined #openttd
08:36:22 *** dR3x4cK has joined #openttd
08:42:26 *** Phazorx has joined #openttd
08:43:13 <Phazorx> pardon for stupid question but is it possible to bump max_trains on running game of relatively outdated save loaded in recebt rev?
08:46:43 <peter1138> patch option isn't it?
08:52:27 <Phazorx> yeah, but it's been a long whie since i played so i dont recall how exactly i do it
08:52:34 <Phazorx> patch max_train = # ?
08:53:33 <Phazorx> or patch vahicle.max_trains?
08:54:01 <Phazorx> oh nevermind... syntax issue on m end, very dub, sorry
09:01:56 *** Rexxars has joined #openttd
09:19:29 <Gekz> its the UTF8 example site!
09:23:59 *** lobstar has joined #openttd
09:24:01 <peter1138> it's an IDN example site
09:29:11 <Eddi|zuHause> it turns into all ??? when i try to open it
09:31:05 <Gekz> Eddi|zuHause: make sure you have the right codepage
09:31:42 <Eddi|zuHause> of course, i can read it
09:31:54 <ln> it has nothing to do with UTF-8, and besides UTF-8 is mandatory over here anyway.
09:31:55 <Eddi|zuHause> and i can also read it when i paste it into the address bar
09:32:11 <Eddi|zuHause> but once i hit enter, it converts all to ???
09:33:14 <Eddi|zuHause> also when i hover over it in konversation the status bar says ???
09:51:53 <Ammler> Eddi|zuHause: www.gmür.org works?
10:08:23 *** Hendikins has joined #openttd
10:09:28 *** Zealotus has joined #openttd
10:33:12 *** lobstar is now known as lobster
10:37:25 *** Progman has joined #openttd
10:52:10 *** [com]buster has joined #openttd
11:01:15 *** Doorslammer|online has joined #openttd
11:01:38 *** Rexxars has joined #openttd
11:05:44 *** Doorslammer|BRSet has quit IRC
11:07:41 *** Doorslammer|online is now known as Doorslammer|BRSet
11:08:58 *** [com]buster has joined #openttd
11:53:02 *** ChanServ sets mode: +v tokai
11:54:46 *** Dred_furst has joined #openttd
12:12:03 *** Osai`off is now known as Osai
12:16:19 *** einKarl has joined #openttd
12:30:57 <TiberiusTeng> now I'm thinking to challenge programmable signals ...
12:34:20 <Noldo> What are programmable signals for?
12:35:42 <TiberiusTeng> check the thread in development forum :)
12:36:11 <TiberiusTeng> I just don't want to carve these kind of things everytime ...
12:40:17 <Noldo> I'm a bit worried about making signals have features like: This tile can be only passed by vehicles with property X
12:41:00 <TiberiusTeng> I don't want to do it this way actually ...
12:41:18 <TiberiusTeng> It'll be better like, say, this signal will be red if signal X is red
12:41:43 <TiberiusTeng> and leave pathfinders untouched
12:41:51 <Noldo> yes that sounds more like something a signal would do
12:42:24 <TiberiusTeng> I don't feel comfortable with penality-based flow control ... since they are relative, not 'absolute'
12:43:03 <TiberiusTeng> some trains would flow into unwanted regions, if the network is really crowded or you missed something while planning
12:43:26 <Noldo> pathfinding should be more higher level
12:43:42 <Noldo> maybe a separate local one for pbs
12:43:59 <TiberiusTeng> but I do like permissive speed signals ... those slowing yellow signals for example :p
12:44:56 <TiberiusTeng> PBS is wonderful but not stable enough IMO ...
12:45:36 <Noldo> priorities is really something that needs more elegant solution than the current one
12:51:31 <yorick> listen what he says, ho
12:51:46 *** [com]buster has joined #openttd
12:54:33 <TiberiusTeng> Yapf is fascinating ... I can't find the way it reads railway signals ...
12:54:45 <Sacro> TiberiusTeng: i don't think it does
12:55:05 <Sacro> see what happens in rail_cmd.cpp
12:55:09 <TiberiusTeng> it relies feedback by train?
12:55:15 <TiberiusTeng> oh yes, thank you
13:01:12 <TiberiusTeng> so ... are there anybody already doing this? programmable signals?
13:01:46 <Noldo> TiberiusTeng: I have a feeling I've seen an implementation somewhere
13:03:34 <TiberiusTeng> actually I do want to 'script' signals myself ...... not using some weird GUI and counter-intuitive boolean expression trees ... :p
13:04:21 <Belugas> as far as i know, there is nobody who currently is working on it
13:05:33 <Belugas> and i wonder, how is it really interesting?
13:06:01 <Belugas> what is it that makes you go in that direction, apart "it's in Patch"
13:06:16 <Belugas> even if i know you don't want the same approach but still...
13:06:27 <yorick> you can filter trains by speed, cargo
13:06:50 <yorick> but that are the only advantages
13:06:55 <TiberiusTeng> it could make openttdcoop load balancer much more cleaner ... perhaps as one or two signals only
13:07:23 <TiberiusTeng> without those 'signal-propagating' tracks
13:07:48 <TiberiusTeng> I think PBS can't be used to implement load balancers ...
13:08:06 <planetmaker> ^^ difficult, I'd say
13:08:12 <TiberiusTeng> i.e. break a train on the sideline to wait until mainline traffic passed
13:08:19 <planetmaker> maybe we miss experience, though :). And hello TiberiusTeng :)
13:08:44 <TiberiusTeng> it's not realistic! (well, servicing a factory with 1000 trains isn't realistic ...)
13:09:23 <TiberiusTeng> perhaps it can be simplified to 'linking two distant (non-adjacent) signals'
13:09:32 <planetmaker> a train waiting on a SL for ML traffic to pass is IMO realistic.
13:09:47 <planetmaker> Just consider a coal train having the ICE pass by and not slowing it down.
13:09:57 <TiberiusTeng> I mean 'using tracks to propagate occupation info' part :p
13:10:09 <planetmaker> he. Yeah, full ACK :)
13:11:08 <Noldo> well, I still think signals should be on tile edges instead of tiles
13:11:32 <TiberiusTeng> but I think it's better to come up a feasible signaling schematic, before trying to implement it ...
13:11:36 <planetmaker> Noldo: too big a change.
13:11:54 <TiberiusTeng> it's kind of historic relics :p
13:12:25 <planetmaker> needs reworking of map array is what my guts feeling tells me. A not-so nice one
13:13:17 <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 ...
13:13:51 <planetmaker> Putting the logic in the signals is more reasonable, though IMO.
13:14:15 <planetmaker> keeping waypoints as just that: waypoints to re-route certain trains over certain tracks
13:14:35 <TiberiusTeng> yep. but 'what' logic ? only depends on some distant signals, or fully supporting boolean expression, even scripting ?
13:15:09 <yorick> I'd say something like the conditional orders
13:15:13 <planetmaker> TiberiusTeng: even now they do have a logic like "pass" "not pass", "not pass, if following are all red", etc
13:15:27 <planetmaker> I meant logic in a rather general sense
13:15:32 <TiberiusTeng> oh yeah, presignals.
13:15:54 <planetmaker> logic could also be "red for trains slower than 100kph"
13:16:31 <yorick> because the pathfinder would avoid it
13:16:38 <yorick> UNLESS it has no other choice
13:16:44 <yorick> means that the signals could jam
13:16:46 <TiberiusTeng> ... and stuck there. ouch
13:17:27 <TiberiusTeng> that's where permissive/absolute signal differs
13:17:57 <TiberiusTeng> I don't think making speed-limiting signals absolute would be a good idea in OTTD ...
13:18:34 <Noldo> signal has to allow every train pass, the question it should answer is 'when'
13:18:34 <yorick> yes, we should revive the yellow signals for permissive red
13:19:11 <Noldo> and yes maybe something like how fast
13:20:03 <TiberiusTeng> merely providing signal linking would be a huge improvement, I think ...
13:20:33 <TiberiusTeng> basically doing what openttdcoop does, in a way that don't occupy map tiles
13:21:10 <TiberiusTeng> link A to F, G, H, I, for example
13:21:28 <TiberiusTeng> if any one of F, G, H, I is red, A will be red
13:22:42 <planetmaker> TiberiusTeng: I'm sure if you open that box of the pandora, other signal programming features will come, too - though maybe later
13:22:49 <planetmaker> despite that, it's a nice feature!
13:23:15 <TiberiusTeng> planetmaker, that's why I think it's better to plan ahead before coding :p
13:23:31 <planetmaker> TiberiusTeng: I won't contradict there.
13:23:53 <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 ...
13:23:59 <planetmaker> And a good planing will give you ground for many ways to programme signals. Doesn't mean that all are implemented
13:24:50 <TiberiusTeng> I think it's better to derive the feature set we need, by some use-cases ...
13:24:57 <planetmaker> Sacro: depends upon what "yellow signal" means
13:25:17 <Sacro> planetmaker: it isn't red
13:25:27 *** frosch123 has joined #openttd
13:25:32 <TiberiusTeng> the yellow signal itself looks cool, but the problem is how to use it ;)
13:25:48 <TiberiusTeng> actually I like the 'permissive red' idea
13:25:56 <planetmaker> Well. I certainly would have a need for signals with speed or cargo-type restrictions...
13:26:41 <TiberiusTeng> but I think I'll need to digest YAPP and original signaling code first ...
13:28:06 <planetmaker> hm... yapp could / should be quite independent of signal logic in whatever sense.
13:28:29 *** De_Ghosty has joined #openttd
13:29:36 <TiberiusTeng> I just don't want to broke things :P
13:30:01 <planetmaker> hehe. But I think it's mostly important to not break things in trunk :)
13:30:25 <TiberiusTeng> reminds me of savegame compatibility.
13:31:15 <TiberiusTeng> ok, double-click to remove NewGRFs in new newgrf window done. :D
13:31:40 <planetmaker> oh, you're working on that? Nice!
13:31:54 <TiberiusTeng> an one-liner, actually :P
13:32:09 <planetmaker> doesn't matter :)
13:32:12 <yorick> also got the dragdrop?
13:32:14 <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)
13:32:19 <yorick> Roest was working on that
13:32:24 <Eddi|zuHause> presignals are always 1km before the main signal
13:32:56 <TiberiusTeng> dragdrop's used to rearrange newgrf orders for now
13:33:12 <TiberiusTeng> adding/removing with double-clicking is faster
13:33:32 <Ammler> TiberiusTeng: post it at FS
13:33:54 <TiberiusTeng> I think he was trying to save the size of newgrf window, but didn't finished it
13:33:55 <yorick> Ammler, AFAIK, the devs don't want it because it's too big
13:34:17 <Ammler> yorick: that window can be smaller then the original
13:34:35 <TiberiusTeng> I made it resizable earlier
13:34:41 <yorick> yes, but can you resize it on a 320x240 device?
13:35:01 <TiberiusTeng> seems I should find a way to get the initial size
13:35:20 <TiberiusTeng> maybe one-liner, maybe not, I dunno
13:35:26 <TiberiusTeng> how should I do it?
13:35:38 <Ammler> yorick: it has the size of the welcome GUI
13:35:49 <yorick> Ammler, that one's too big
13:35:56 <yorick> it doesn't fit on the nds
13:37:38 <TiberiusTeng> perhaps I should cap it with _screen.width/height ?
13:37:51 <TiberiusTeng> but wait, the NDS screen is not entirely touch-sensitive
13:38:14 <TiberiusTeng> and I would hate to enlarge the window every time on my 1680x1050
13:38:28 <yorick> but you can swap the screens on the nds
13:41:05 <TiberiusTeng> display the old one in NDS and the new one elsewhere? :p
13:42:33 <yorick> but openttd could run on other devices
13:42:37 <glx> IIRC the old one is already too big
13:45:30 <yorick> 088: error: invalid conversion from `NetworkClientInfo*' to `NetworkClientInfo*'
13:46:00 <Eddi|zuHause> you are doing it wrong ;)
13:47:15 <TiberiusTeng> anyway, resizing of the window is still strange ...
13:47:55 <TiberiusTeng> sometimes OnResize() will get impossible values
13:51:17 <glx> yorick: isn't there a const somewhere in this message?
13:52:11 * yorick rereads message, ah, there :)
13:52:15 <Ammler> TiberiusTeng: the width is ok
13:53:09 <Ammler> that would fit the NDS, wouldn't?
13:53:35 *** [com]buster has joined #openttd
13:54:33 <TiberiusTeng> and I think the bottom area could be smaller when resizing
13:54:50 <TiberiusTeng> when resizing to a small size ...
13:55:09 <Ammler> you could skip the info box
13:55:17 <Ammler> just name and parameters.
13:55:35 <Ammler> name isn't needed either.
14:00:28 *** grumbel has joined #openttd
14:08:38 <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
14:09:36 <Eddi|zuHause> and maybe the separator in the middle should be smaller
14:29:23 *** TiberiusTeng has joined #openttd
14:33:16 <planetmaker> or arange for small screens the windows vertically than horizontally as now
14:38:40 <TiberiusTeng> sounds tedious to implement :p
14:44:14 *** Osai is now known as Osai^Kendo
14:45:20 *** ben_goodger has joined #openttd
14:47:34 *** Osai^Kendo is now known as Osai^Kendo`off
14:49:12 <Eddi|zuHause> have you read the logs?
14:52:43 *** dR3x4cK has joined #openttd
14:53:27 <yorick> should a company password window really be able to close it's parent on window overflow?
15:01:43 <CIA-4> OpenTTD: frosch * r13645 /trunk/src/tgp.cpp: -Codechange: Convert a macro into an inlined member function.
15:09:55 *** dR3x4cK has joined #openttd
15:13:14 *** stillunknown has joined #openttd
15:31:51 *** blathijs has joined #openttd
15:32:04 *** TheMask97 has joined #openttd
15:41:23 *** Singaporekid has joined #openttd
15:45:26 *** Singaporekid has joined #openttd
15:50:51 <yorick> TiberiusTeng: I just tested the opengl blitter on another pc, it works nicely :)
15:51:14 <TiberiusTeng> yorick, what's the graphics board that PC's using ?
15:51:20 <yorick> only some scrolling artifacts if I use the fast scrolling
15:51:35 <TiberiusTeng> and ... did you tried panning when zoomed out 8x ?
15:51:58 <yorick> only some artifacts when using shift-scroll
15:52:17 <yorick> with trees on toyland enabled
15:52:49 <TiberiusTeng> what's shift-scroll ? never used this function before
15:52:58 <TiberiusTeng> ahh, almost the same card as mine :)
15:53:04 <yorick> try holding shift and then pressing the arrow keys
15:53:06 <yorick> 268435456 bytes (256 MB)
15:54:13 <TiberiusTeng> hope it helps in some extreme (?) situations :p
15:54:30 <yorick> any tools I can use to see the fps?
15:54:57 <yorick> screen is on 60 fps, btw
15:59:43 <yorick> panning horizontally seems more laggy than vertically
16:03:18 <TiberiusTeng> perhaps you need to force disable VSync in NV control panel
16:04:12 <Doorslammer|BRSet> Quick Q guys
16:04:17 <Doorslammer|BRSet> The light in TT
16:04:26 <Doorslammer|BRSet> Which way does the light come from?
16:04:34 <yorick> from a universal direction
16:04:39 <Doorslammer|BRSet> Right to left or left to right?
16:04:58 <Doorslammer|BRSet> I dont exactly know what to look at
16:05:08 <Doorslammer|BRSet> I think the majority of the BR Set is wrong :S
16:05:14 <Doorslammer|BRSet> I thought so :O
16:05:20 <Doorslammer|BRSet> Cheers guys
16:07:24 <Belugas> well... it's not totally right to left, to be exact
16:08:01 <Belugas> more like north-east to south-west
16:08:12 <yorick> try looking at the shades the planes have
16:08:41 <Eddi|zuHause> the slopes should be the best source ;)
16:08:54 <Belugas> am looking at the slopes :)
16:08:57 *** Doorslammer|BRSet is now known as Doorslammer
16:11:24 <Belugas> and yes, the planes confirm the slopes...
16:16:58 <CIA-4> OpenTTD: belugas * r13646 /trunk/src/toolbar_gui.cpp: -Change: typos and miss-aligned enum values
16:18:31 <Doorslammer> Cock, got it wrong
16:18:37 * Doorslammer slaps Doorslammer around a bit with a large trout
16:18:58 <Doorslammer> Flip horizontal in Paint should cure things, yes?
16:21:12 <yorick> because paint sucks at sprites
16:21:38 <Doorslammer> I dont think its that bad surely?
16:21:52 <Doorslammer> Purno uses it all the time apparently
16:23:38 <yorick> you get in the way with shadows
16:24:29 <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.
16:27:39 *** [com]buster has joined #openttd
16:28:16 <Belugas> fjb, it depends what you want to achieve
16:28:38 <Belugas> the close the airport is frm the town center, the more noise the town will perceive
16:28:57 *** Doorslammer is now known as Doorslammer|BRSet
16:29:11 <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
16:29:25 <Belugas> the further you are, the more it decrease
16:29:33 <fjb> How do I calculate how far away from the town I have to place the airport.
16:30:00 <Belugas> define youre definition of "how far awy"
16:30:10 <Belugas> waht dos it means for you?
16:30:50 <Belugas> you can put the airport next to the town center if you will
16:30:55 <Belugas> or even 100 tiles away
16:31:11 <Belugas> what do you want to ACHIEVE
16:31:55 <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?
16:32:25 <Belugas> what is your town's setting for tolerance?
16:32:28 <Doorslammer|BRSet> Thanks, BTW
16:32:44 <fjb> Ofcouse I want to build it as near to the center of the town as possible.
16:33:56 <fjb> Is there a setting for tolerance? Or is the the general tolerance for building stations?
16:34:05 <Belugas> town_council_tolerance
16:34:35 <Belugas> ingame, it's on the difficulty level, last entry
16:34:59 <fjb> Ok, I will look at it in the console.
16:35:54 <Belugas> so, you need a noise reduction of 4
16:36:15 <fjb> Oh, how do I open the ingame console? I was the key above the tab key. But that doesn't work right now.
16:37:02 <fjb> The initial configfile hat a tolarance of 1, should be the medium setting.
16:37:38 <Belugas> 8 tiles times (4<- general multiplier) + (town_council_tolerance)
16:38:56 <Belugas> tis gives you a factor
16:39:13 <Belugas> /* The steps for measuring noise reduction are based on the "magical" (and arbitrary) 8 base distance
16:39:14 <Belugas> * adding the town_council_tolerance 4 times, as a way to graduate, depending of the tolerance.
16:39:14 <Belugas> * Basically, it says that the less tolerant a town is, the bigger the distance before
16:39:14 <Belugas> * an actual decrease can be granted */
16:39:22 <Belugas> /* now, we want to have the distance segmented using the distance judged bareable by town
16:39:22 <Belugas> * This will give us the coefficient of reduction the distance provides. */
16:39:28 <Belugas> /* If the noise reduction equals the airport noise itself, don't give it for free.
16:39:29 <Belugas> * Otherwise, simply reduce the airport's level. */
16:39:41 <Belugas> the comments are saying every thing you need
16:41:12 <fjb> Hm, tolerace is 1. So 8 + 4 * 1 = 12.
16:44:04 <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?
16:45:48 <Belugas> not really. what is important is the distance from town center. It gets divided by the amount you found ealier (12)
16:46:05 <Belugas> you will get one noise level reduction
16:46:57 <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
16:47:19 <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.
16:48:08 *** stillunknown has joined #openttd
16:48:23 <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?
16:48:59 <Belugas> if it was a permissive town (=0), it would have been based on 8 instead of 12 (8+(4*0))
16:50:17 *** [alt]buster has joined #openttd
16:50:18 <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.
16:51:15 *** [alt]buster is now known as [com]buster
16:52:25 <Belugas> i'm just happy that it's finaly in trunk...
16:54: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.
16:57:06 <Belugas> funny how frequently "we need" is used when talking about one person's desires ;)
16:57:39 <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
16:58:52 <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.
17:03:57 <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.
17:08:41 <TiberiusTeng> I think I'll fix NewGRF window first, then actually start researching distant signal linking.
17:09:16 <TiberiusTeng> since waypoints can already do many things that route restrictions / programmable signals in TTDP ...
17:14:09 <Eddi|zuHause> fjb: first step: add a "destination station" entry to the cargo packet
17:15:59 <Eddi|zuHause> fjb: fill that with random values, do not use the value for anything important, and check if it doesn't desync
17:16:27 <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?
17:16:54 <Eddi|zuHause> it's the first step: add the POSSIBILITY to have destinations
17:17:05 <Eddi|zuHause> if you use them for every cargo is a completely different question
17:18:13 <Eddi|zuHause> and yes, depending on difficulty options, potentially every cargo should have a destination
17:18:51 <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.
17:19:12 <Eddi|zuHause> that's a balance issue
17:19:27 <Eddi|zuHause> push that very far back the queue of features ;)
17:20:06 <Eddi|zuHause> it MUST NOT desync, that's the main problem of the last patch
17:20:22 <fjb> Just adding features with a goal in mind doesn't look like the way to go.
17:20:51 <Eddi|zuHause> it's called "step", not "just randomly add a feature"
17:21:08 <Belugas> i agree with Eddi|zuHause
17:22:51 <fjb> Did the desyncs come from the destination or from finding the routes?
17:23:31 <Eddi|zuHause> the desyncs came from not properly storing the information in the savegame
17:24:46 *** ProfFrink has joined #openttd
17:24:49 *** ProfFrink is now known as Prof_Frink
17:25:38 <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?
17:26:15 <Eddi|zuHause> i said OPTION, do you actually read?
17:26:54 <fjb> I read. But what is an option good for if almost nobody uses it.
17:27:12 <Belugas> wasting executable size
17:27:13 <Eddi|zuHause> what survey tells you that it would not be used?
17:27:27 <fjb> I fear that it will really slow down the game, even if not enabled.
17:28:01 <Eddi|zuHause> and i would not want to manage two different sized cargo packages, depending if the option is used or not
17:28:07 <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
17:28:41 <Wolf01> but at least you satisfied both who wanted the feature and who don't want it
17:29:09 <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.
17:29:09 *** Phoenix_the_II has joined #openttd
17:29:53 <Eddi|zuHause> the main feature of cargo destinations would be to reduce the micromanagement needed for limited-acceptance-industries like PBI or ECS
17:30:18 <Eddi|zuHause> because cargo would automatically be distributed between different such industries
17:30:57 <fjb> ECS is a bit hard to handle. I don't know if that would be easier with the destination feature.
17:31:10 <Eddi|zuHause> but that is not the question at all
17:31:37 <Belugas> automatic distribution...
17:31:55 <Eddi|zuHause> the problem at hand are the game internals, the very foundation of the patch
17:31:55 <Belugas> another tool to make the game easier
17:32:00 <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
17:32:07 <Belugas> a button and see it work on itself!
17:32:24 <Eddi|zuHause> Belugas: no, you still have to run the trains ;)
17:32:24 *** [com]buster has joined #openttd
17:32:53 <Belugas> wanna bet someone would come up with such an idea ?
17:33:42 <Eddi|zuHause> there's a difference between "laziness" and "extensive micromanagement"
17:33:46 <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
17:35:33 <Eddi|zuHause> Belugas: be glad i didn't use the r-word ;)
17:36:40 <Eddi|zuHause> businesses plan their transports based on supply and demand, and THEN ask the transport company to transport it
17:36:58 <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
17:37:30 <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.
17:38:15 <Eddi|zuHause> very loosely related question: why don't wagons have any running cost?
17:38:38 <ccfreak2k> Because they would have maintenance costs instead.
17:38:39 <Eddi|zuHause> (or change the running cost of the engine)
17:41:16 <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.
17:41:30 <Wolf01> mmmh, since when I started the hotkeys patch I didn't read any suggestion, do this mean that I can continue my work?
17:42:51 <Eddi|zuHause> fjb: don't talk about overhead before you implemented and profiled anything
17:43:25 <Eddi|zuHause> Wolf01: several people already started hotkey patches, did you talk with them?
17:44:14 <Wolf01> I never seen an hotkey patch, so I don't know who talk to
17:44:34 <fjb> Eddi|zuHause: You should think about the balance betwenn code duplication and compiting overhead before you start to rewrite half of the game.
17:45:07 <Eddi|zuHause> nobody said anything about a rewrite
17:45:25 <Eddi|zuHause> i said: add a member to a struct, and then make sure it is properly storedd
17:46:22 *** Boyinblue0 has joined #openttd
17:46:56 <CIA-4> OpenTTD: skidd13 * r13647 /trunk/src/ (6 files): -Codechange: replace MAX_UVALUE() for std types with the equivalent constant
17:58:17 <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?
17:59:55 <eekee> that's my favoured option, if that counts for anything. I think it acheives quite a lot from a simple process
18:01:19 <Eddi|zuHause> fjb: rembember what i said? add struct, check multiplayer compliance... there was nothing said about WHAT you write in the struct member!!
18:02:00 <Eddi|zuHause> and remembering last station will solve nothing, it will just push the problem to the next level (3 vehicles going in circles)
18:02:09 <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])) ?
18:02:56 <Eddi|zuHause> mikk36: .cfg format has changed
18:03:12 <Eddi|zuHause> several weeks ago
18:03:21 <mikk36> no autopilot until someone has updated it ?
18:03:34 <glx> so autopilot needs to be updated for trunk
18:04:02 <Eddi|zuHause> [get_setting patches map_y] <- replace the "patches" there with the new group
18:04:23 <Eddi|zuHause> and in the map_x line as well
18:04:46 <glx> and all get_setting lines indeed ;)
18:07:30 <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.
18:07:55 <Eddi|zuHause> fjb: i understand what it dies
18:08:10 <Eddi|zuHause> but i said it will not solve anything
18:08:21 <Eddi|zuHause> scenario: 3 airports
18:08:41 <fjb> It will solve the no bidirectional distribution problem.
18:08:55 <Eddi|zuHause> the passengers might go in circles indefinitely
18:09:09 <Eddi|zuHause> because they get "catched" by a plane before they can enter the shuttle bus
18:09:35 <fjb> Yes. When your network is not properly made you carry the passengers in circle. Just as you do tzoday.
18:09:41 <Eddi|zuHause> it shifts the problem, does not solve it
18:09:41 <Ammler> mikk36: do you need a patch for ap?
18:10:01 <Eddi|zuHause> as thus i would definitely reject the "solution"
18:11:16 <fjb> You can always build unusual networks. And a feature is not no solution to a problem because it is not foolproof.
18:11:17 <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.
18:11:57 <Eddi|zuHause> fjb: planes connecting different airports is definitely not an "unusual" network
18:12:11 <fjb> frosch123: That sounds like a loop through the orders list.
18:12:24 <frosch123> when not using 'non-stop'?
18:12:33 <Eddi|zuHause> fjb: trains need not have all stations they visit in the orders
18:12:46 <fjb> Eddi|zuHause: A planed connection please, not just random connections without thinking.
18:13:25 <Eddi|zuHause> you are talking rubbish
18:14:18 <Eddi|zuHause> both frosch123's and my objections are valid reasons to reject your approach
18:14:31 <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.
18:14:52 <Eddi|zuHause> fjb: that does not catch ring-traffic
18:15:28 <Eddi|zuHause> and again, the station need not be in the order list AT ALL
18:15:49 <fjb> Eddi|zuHause: That is what I wrote.
18:16:36 <fjb> It still needs a well planes network then, no random network.
18:16:54 <Eddi|zuHause> you mean "planned"
18:17:15 * 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...
18:18:10 <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
18:18:41 <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.
18:18:53 <Eddi|zuHause> and no matter how many patches you stick on, there will always be wounds that are bigger than the patch
18:19:57 <fjb> Eddi|zuHause: But I don't think your automatic distribution system will really solve anything. At least not the stockpiling difficulties.
18:20:34 <Eddi|zuHause> fjb: that is not the goal at all
18:20:48 <fjb> Eddi|zuHause: And it is big news to me that you can reject any new approach any new feature.
18:21:20 <Eddi|zuHause> fjb: have you learned the magic of a CONDITIONAL clause yet?
18:22:09 <fjb> Eddi|zuHause: So why did you add your selself then?
18:22:14 <Eddi|zuHause> fjb: assume an implicit "if i was in the position of a dev"
18:23:07 <Eddi|zuHause> fjb: and i already got at least one dev who backed me up on some of my statements and conclusions
18:24:35 <frosch123> what? - I was going against both of you...
18:25:00 <Eddi|zuHause> i was not talking about you ;)
18:27:16 <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]
18:28:53 <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
18:29:15 <fjb> Belugas: I fear he was talking about you.
18:29:52 <Eddi|zuHause> [19:21] <Belugas> i agree with Eddi|zuHause <- proof ;)
18:30:08 <Eddi|zuHause> [although the discussion went quite far since then]
18:31:02 <Belugas> that is what i wold call hijacking!
18:31:10 <Eddi|zuHause> anyway, the problem at hand was storing any kind of station [whether past or future] in the cargo packet
18:31:26 <Eddi|zuHause> once you get that feature stable, you can talk about what to do with it
18:31:28 <Belugas> [13:18] <Eddi|zuHause> it's called "step", not "just randomly add a feature"
18:31:29 <Belugas> [13:18] <@Belugas> yeah
18:31:29 <Belugas> [13:18] <@Belugas> i agree with Eddi|zuHause
18:31:36 <Eddi|zuHause> everything else is just wild speculation
18:32:07 <Belugas> and God damn this noise
18:43:20 *** Doorslammer|BRSet has quit IRC
18:52:14 <Belugas> maybe that cargo knowing its dstination may be solved looking at the other angle
18:53:27 <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
18:53:52 <Belugas> but that means an intelligence somewhere on the cargo management
19:08:30 *** Brianetta has joined #openttd
19:09:26 <mikk36> why is there so short message size limit ?
19:11:37 <yorick> Belugas: the chat limit got decreased drastically somewhere between 0.6 and current trunk
19:13:42 <Belugas> it's supposed to be 64 chars, i believe
19:15:31 <planetmaker> it is 64 chars or so. But longer would be better. And it was longer before :), but got fixed
19:15:56 <yorick> I can fit the alfabet in it 3 times
19:16:15 <yorick> since when is decreasing limits called fixing?
19:16:46 <Eddi|zuHause> afaik it was limited by the window width before, which is totally unrelated to the number of characters
19:17:00 <Belugas> since when imprecision drives everything?
19:17:20 <yorick> but why did it have to be made this short?
19:18:30 <yorick> and 64 chars is really short
19:18:51 <Eddi|zuHause> that's what you get when you have to go with the majority :p
19:19:03 <eekee> argh 64 is impossible! I used an environment with a 255-char limit for a long time, that was harsh
19:19:07 <yorick> like I can only fit a message in it that's exactly this lenght
19:19:20 <mikk36> 1 sentence per message is really short
19:19:50 <Eddi|zuHause> provide a patch that adds a hook to split lines at word boundaries ;)
19:20:10 <Eddi|zuHause> [not necessary ALL word boundaries]
19:20:41 <yorick> juse I'd rather have a longer chat limit
19:20:56 <yorick> because openttd does the linebreaking, no?
19:21:56 <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.
19:22:00 <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
19:22:36 <yorick> irc also has a line limit somewhere
19:22:42 <Eddi|zuHause> it adds line breaks on display, but not on sending
19:22:54 <yorick> altho it was previously SHORTER than the openttd limit
19:22:54 <Eddi|zuHause> and the send buffer is what limits the line length
19:22:55 <Ammler> yorick: you can also see on our ps, that ottd can still handle longer lines, as it does with chat from IRC
19:23:01 <planetmaker> a limit doesn't hurt as long as it's not limit to usual sentences :)
19:23:15 <Eddi|zuHause> IRC has 512 characters limit afaik
19:23:25 <planetmaker> and my usual sentences easily cover twice or three times as many characters as 64 :)
19:23:32 <yorick> Ammler, yes, the actualy message is tranffered over a much longer char
19:23:56 <yorick> I find it stupid that you can not write messages as long as the limit gui-wise
19:24:09 <Ammler> the ingame chat is a bug, I assume and not feature :-)
19:24:53 <planetmaker> rather both: buggy feature :P
19:25:24 <Ammler> yorick: as network patcher, you should be able to fix it :P
19:25:30 <planetmaker> but bug sounds so... wrong. Let's call it a feature with room for improvements :)
19:25:47 <yorick> Ammler, I'm already looking into it
19:26:15 <Eddi|zuHause> a feature with room for "features" :p
19:26:59 <yorick> #define MAX_TEXT_MSG_LEN 1024
19:27:10 <yorick> can I now kill the one who tought of that 64 gui-limit
19:27:32 <yorick> you made the gui-chat limit actually 16 times smaller than it could be
19:28:36 <glx> <yorick> #define MAX_TEXT_MSG_LEN 1024 <-- and how does that fit in a packet?
19:29:17 <ben_goodger> glx: with an MTU of 1500 I'd expect it to fit quite nicely
19:29:22 <glx> yorick: and the 64 limit appeared with window classification
19:29:51 <glx> because all other text input are 64
19:31:25 <yorick> glx: could you extend that text input limit?
19:32:23 *** Frostregen has joined #openttd
19:34:42 <eekee> but it's daft for a chat window to have no longer length than name windows. It should be a different class, somehow :/
19:35:46 <yorick> glx: yeah, it involves changing 2 numbers
19:36:10 <glx> yorick: but other text input should stay 64
19:36:35 <eekee> can you subclass the general text input?
19:36:50 * eekee is thinking in general OO terms, knows nothing of C++
19:40:41 <yorick> possibly make a var somewhere in the querystring struct that'd allow for changing the size?
19:43:18 *** Wolf01 is now known as Wolf01|AWAY
19:43:25 <yorick> is there no way you could override edit_str_buf and orig_str_buf when initializing the NetworkChatWindow
19:44:45 <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);?
19:46:11 <glx> and adding a buffer unused for most of text inputs?
19:48:18 <yorick> but yes, adding a 1 kb per editbox is a memory waste :)
19:53:43 <yorick> you could also define a whole new querystringbasewindow
19:55:49 <glx> yorick: it will take some time to make it in a clean way
19:57:36 <eekee> wtf? how many edit boxes could anyone have open at once? How is 1KB a waste?
19:58:28 <yorick> dunno if that's a big wast
19:59:38 <glx> only one usable at a time
20:02:24 <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
20:03:08 <yorick> if I calculated the memory usage of a char[1024] correctly
20:03:21 <yorick> and I don't think I have, taking unicode into concideration
20:04:04 <eekee> well double or quadruple my numbers if you like. 4 bytes per char comes to 0.15%
20:04:21 <eekee> There is avoiding bloat, there is lightness and purity, and then there is extreme asceticism! ;)
20:05:07 <yorick> just an unused char[1024] for every editbox
20:05:54 <yorick> and 100kb on a 100MB-usage map is
20:05:55 <Belugas> let's all scrap trunk!! scrap code!!!
20:06:42 <yorick> hmm...quite much, now I think about it
20:07:02 <yorick> you're wasting 100kb for multiplayer you might not even want to use
20:07:33 <Belugas> hre, and there and why not even ther?? then, it's bloated every where!!!
20:07:35 <eekee> yorick: dude, please stop encouraging pain for fractions of a percent
20:08:03 <yorick> ok, then go at convincing that whale next door
20:08:21 <yorick> the one that tries to believe he can rhyme
20:11:05 <Belugas> you know what the whale is going to do next?
20:11:12 <eekee> bloat is like ecology. Worry produces a lot of ascetiscism and very little real gain
20:11:32 <yorick> Belugas: whales have no feet
20:12:11 *** yorick was kicked by Belugas (no, but they can click a mouse!)
20:18:58 *** stillunknown has joined #openttd
20:25:38 <Belugas> heheh just had a "bug" report at work
20:26:08 <Belugas> the Maestro card of my customer has beeen refused
20:26:37 <Belugas> the Maestro card of my customer has beeen refused
20:26:49 <Belugas> it is a debit, not a credit card
20:27:19 <yorick> wtf, I'm running tto in dosbox, and the cursor escapes the dosbox window :)
20:33:38 <yorick> foundopenttdcrashonloadingttosavegame!
20:33:58 <glx> not surprising, it's not supported
20:34:18 <ccfreak2k> Congratulations, you found a feature!
20:34:30 <yorick> glx, yes, but should it assert?
20:35:06 <glx> better assert than crash later doing something else
20:35:19 <yorick> File src/oldpool/h Line: 125
20:35:19 <yorick> Expression: index < this->GetSize()
20:36:06 <glx> asserts are disabled for releases
20:36:37 <yorick> can it not say "incompatible savegame"?
20:37:10 * Ammler would like to see language files like grfs, just away from trunk.
20:37:18 <yorick> ah, second failure: Station: failed loading savegame: too many Station
20:37:50 <Ammler> it would make update so much faster...
20:37:52 <glx> openttd doesn't know TTO format
20:38:38 <yorick> does it know ttd format?
20:38:43 <yorick> and does ttd know tto format?
20:39:09 <eekee> OTTD used to load TTD format, if I remember right
20:49:24 <ccfreak2k> "TTO save games not supported" would probably be the best way to handle it.
20:49:32 <ccfreak2k> Assuming TTO saved games are different from TTD.
20:52:20 <Belugas> ho yeah... a red box popup!!
20:54:57 <Eddi|zuHause> ccfreak2k: the problem is to get to know the difference
20:58:53 *** Osai^Kendo`off is now known as Osai
20:59:48 <CIA-4> OpenTTD: frosch * r13648 /trunk/src/tgp.cpp: -Cleanup (r5303): Amplitudes should be amplitudes and not amplitudes/16.
22:10:03 <Eddi|zuHause> ... that was a very random line do throw in the middle of an idle time ...
23:11:09 *** Progman has joined #openttd
23:22:11 *** Osai is now known as Osai`off
continue to next day ⏵
