IRC logs for #openttd on OFTC at 2009-03-03
⏴ go to previous day
00:16:55 *** NightKhaos has joined #openttd
00:23:19 <Belugas> [17:35] <energetic> Hmm, a submitted bug was closed before I could answer decently.... <--- when it is due to be closed, it is time to close it. sorry... but that's life
00:33:17 *** Eddi|zuHause has joined #openttd
00:47:23 *** NightKhaos has joined #openttd
00:51:55 *** HansAffe has joined #openttd
01:33:58 *** KenjiE20|LT has joined #openttd
02:18:42 *** goodger has joined #openttd
02:57:36 *** goodger has joined #openttd
03:12:16 *** TinoDidriksen has joined #openttd
03:34:40 *** goodger has joined #openttd
03:42:32 *** TinoDidriksen has joined #openttd
04:26:29 *** goodger has joined #openttd
04:38:23 *** goodger has joined #openttd
04:53:39 *** amixppc has joined #openttd
05:09:43 *** [com]buster has joined #openttd
05:09:46 *** [com]buster is now known as Combuster
05:33:34 <De_Ghosty> the tree gowing thing is awsome
05:33:40 <De_Ghosty> when you just make a giant map
06:33:19 *** tkjacobsen has joined #openttd
06:52:16 *** sigmund_ has joined #openttd
06:59:41 *** DaleStan has joined #openttd
07:11:37 *** [com]buster has joined #openttd
07:11:40 *** [com]buster is now known as Combuster
07:16:44 *** PhoenixII has joined #openttd
07:16:44 *** Phoenix_the_II has quit IRC
07:32:31 *** pleeby is now known as bleepy
07:35:20 *** bleepy is now known as Guest365
07:35:20 *** pleeby is now known as bleepy
07:58:13 *** stuffcorpse has joined #openttd
08:03:41 *** stuffcorpse has joined #openttd
08:09:11 *** stuffcorpse has joined #openttd
08:19:38 *** Timitry has joined #openttd
08:25:10 *** Vikthor has joined #openttd
08:49:57 <Arsonide> Apparently there are some high resolution graphics for this somewhere
08:50:18 <Arsonide> But I'm not familiar with the terminology you guys use...so I'm not even sure what I'm looking for.
08:57:38 <Eddi|zuHause> possibly you mean "32bpp extra zoom levels", but they are not supported in the official version
09:00:38 <Arsonide> They're gorgeous though
09:00:46 *** [com]buster has joined #openttd
09:06:23 <Arsonide> I assume using new graphics isn't allowed in multiplayer games?
09:06:41 *** [com]buster is now known as Combuster
09:12:54 <Arsonide> In most games using modified files in multiplayer is prohibited. I guess it would affect this game less though.
09:13:03 <Arsonide> I was asking if it was or not
09:14:05 <Forked> modified files != newgrf I belive.. modified is probably "I changed the source code to cheat"?
09:16:12 <Arsonide> And newgrf is the term you use for these 32bpp extra zoom level graphics?
09:26:34 *** pleeby is now known as bleepy
09:29:37 *** bleepy is now known as Guest370
09:29:37 *** pleeby is now known as bleepy
09:40:19 <planetmaker> hm... would it be possible to add a direct download link to the tars currently availble on Bananas?
09:42:06 *** bleepy is now known as Guest371
09:42:06 *** pleeby is now known as bleepy
09:45:53 <Forked> or you could have tried: /me e l l o .
09:46:18 <[wito]> I accidentally my nick. :P
09:47:12 <[wito]> anyway, has anyone had any success with express lines, e.g. to an airport, where the trains only load (and don't unload) on the way to the gathering point?
09:53:33 *** Progman has joined #openttd
09:57:20 <Timitry> Just use normal load + no unloading orders for the normal stations, and transfer orders at the airport
10:01:50 <[wito]> given stations A B C and airport D
10:02:09 <[wito]> with those orders, wouldn't that lead to loading at A, unloading and loading at B, etc. until transfer at D?
10:02:34 <[wito]> What I want is passengers from A, B and C delivered at D
10:02:47 <[wito]> without passengers from A at B or from B at C
10:02:50 <Eddi|zuHause> no, because you tell it to "not unload" at B
10:03:05 <[wito]> there is a no unloading order?
10:03:28 <Eddi|zuHause> yes, in 0.7.0, in the dropdown with "full load"
10:06:40 <[wito]> Also, am I understanding the documentation correctly in that station_spread is safe for huge values as long as you are using YAPF?
10:09:17 <Eddi|zuHause> cargo delivery from houses to stations is probably the most influental part with station spread
10:09:44 <Eddi|zuHause> passengers? mail?
10:10:02 * energetic checks definition of cargo....
10:10:10 <energetic> thought it was cargo==goods
10:10:44 <Eddi|zuHause> anyway, if you have a halfway modern computer, you should not have any real problems with station spreaD
10:11:06 <energetic> err my bad cargo=payload != goods
10:12:00 <Eddi|zuHause> i have no idea what a payload is
10:12:20 <energetic> great :) we be learning both something today ;)
10:13:15 <energetic> i was hoping on a scret trick to generate goods out of houses there
10:13:28 <Eddi|zuHause> you are misinterpreting my sentencethen
10:13:52 <energetic> no, i was using the wrong definition of cargo ;)
10:14:21 <Eddi|zuHause> i meant the other sentence
10:22:54 *** Combuster has joined #openttd
10:23:02 <[wito]> 0.7.0b1 is quite a lift from 0.6.3 ^_^
10:23:31 <[wito]> Now, if I could just figure out how PBS works, I might be able to build me some bypass tracks and express lanes!
10:23:57 <Noldo> put signals on safe waiting positions
10:24:11 <energetic> i hate typing in the wrong window
10:24:19 *** maristo has joined #openttd
10:27:05 <planetmaker> Now, if I could just figure out how PBS works, I might be able to build me some bypass tracks and express lanes!
10:27:06 <planetmaker> [11:23] <Noldo> put signals on safe waiting positions <-- there and only there :)
10:28:18 * planetmaker remembers several thread where people had problems with exactly that concept, ignoring the "not there" ;)
10:28:51 *** Progman_ has joined #openttd
10:29:35 *** bleepy is now known as Guest374
10:29:35 *** pleeby is now known as bleepy
10:29:39 <Ammler> station_spread warning is obsolete ;-)
10:30:42 <planetmaker> wrt speed probably not. Though I don't care :P
10:30:44 <Ammler> (hmm, scroll down next time)
10:34:37 *** Progman_ is now known as Progman
10:35:13 <Ammler> yeah, you need around 3 pbs lines to replace a good old signal line :-)
10:37:40 *** Progman has joined #openttd
10:39:47 *** Singaporekid has joined #openttd
10:40:01 <[wito]> it appears my junction of choice (the cloverleaf) sort of breaks down with YAPP
10:40:30 <[wito]> that could be because the inner tracks aren't long enough, tho', and thus gives no safe waiting positions. :/
10:41:00 <Timitry> and use the SECOND cloverleaf!
10:44:21 <Ammler> Timitry: you should let trains using your junctions ;-)
10:44:22 <petern> cool, someone who can spell it ;)
10:45:55 <Eddi|zuHause> Timitry: why does it say "3 way" on the heading but then show "4 way" pictures?
10:50:16 <Eddi|zuHause> i hate the opengfx rails...
10:50:46 <Eddi|zuHause> they are too dark, and they look like rendered/anti-aliased without proper hinting, so everything gets somehow fuzzy
10:54:13 <Eddi|zuHause> on the contrary, the existence of this "bad" track prevents designing a proper track graphic
10:54:21 <Ammler> did someone already make bad experience with path_backoff_interval = 1 ?
10:55:13 <Ammler> Eddi|zuHause: it tells the train, how long it should wait to search for a new path
10:55:15 <Eddi|zuHause> Noldo: as in "we already have this one, we should focus on missing sprites first"
10:55:34 <Noldo> Eddi|zuHause: that's just delaying
10:56:06 <Ammler> which we think is very high
10:57:05 <petern> it's there for a reason, though
10:57:30 <Singaporekid> Is anyone still using IE6?
10:57:42 <Ammler> hmm, someone changed it on a 2k trains map
10:57:45 <Eddi|zuHause> it is the time to wait to retry reserving a path after one reservation failed, right?
10:57:51 <Ammler> he didn't see a difference
10:57:56 <Timitry> petern: "argh, junction examples :(" <--- still better than the crap currently on the wiki, and it's not for advanced players, anyway, and those are tutorials that might help new players to develop their own junctions
10:58:30 <Ammler> Eddi|zuHause: yes, that was one of the reasons for some to not like pbs on fast tracks.
10:58:32 <Timitry> Eddi|zuHause: "why does it say "3 way" on the heading but then show "4 way" pictures?" ---> Copied the 3-way page, it's now fixed, thanks
10:59:19 <Ammler> with "1", they behave like the ususal signals
11:05:06 <[wito]> YAPP is going to take some getting used to
11:09:15 *** maristo has joined #openttd
11:09:29 <Eddi|zuHause> a few general rules of thumb with YAPP: 1) forget everything you know about signals, 2) replace entry signals with one-way signals, 3) replace two-way-exit signals with two-way path signals facing the station, remove one-way-exit signals, 4) less is more in many cases
11:10:00 <[wito]> Eddi|zuHause: the first one is the toughest to get your head around. :P
11:10:40 <Ammler> Eddi|zuHause: 2way signals on terminus stations are just eye-candy
11:11:02 <Eddi|zuHause> yes, but i like eye candy ;)
11:11:11 <[wito]> Ammler: that's only true with YAPP, no?
11:11:19 <[wito]> With YAPF it's still sensible, innit?
11:11:45 <Ammler> " a few general rules of thumb with YAPP"
11:11:49 <[wito]> anyway, Ammler, got a 4-track terminus that demonstrates good YAPP usage? ;)
11:12:57 <Ammler> "we" do not work with templates ;-)
11:13:03 <Eddi|zuHause> before: www.informatik.uni-halle.de/~krause/Ravenswald%20Transport,%2029.%20Dez%201955.png
11:13:05 *** wollollo has joined #openttd
11:13:14 <Timitry> just to give you an idea, of course
11:13:20 <Eddi|zuHause> after: www.informatik.uni-halle.de/~krause/Ravenswald%20Transport,%201.%20Jul%201981.png
11:14:49 <[wito]> Re: #Advanced_Terminus
11:15:39 <Ammler> if you add safe waiting, you have also to double the line
11:16:06 <dihedral> else you lose a part of the game ^^
11:17:10 <Ammler> safe waiting is like removing a signal on a line
11:17:35 <Eddi|zuHause> a terminus station of mine: www.informatik.uni-halle.de/~krause/Ravenswald%20Transport,%2018.%20Dez%201982.png
11:18:53 <Ammler> Eddi|zuHause: do you try to build "junctions" only at stations?
11:19:06 *** welshdragon has left #openttd
11:20:14 <Eddi|zuHause> except this one: www.informatik.uni-halle.de/~krause/Ravenswald%20Transport,%2021.%20Sep%201956.png
11:20:31 <Eddi|zuHause> was a "very few towns" game, so there was no way to place a station near there ;)
11:21:00 <Ammler> I really enjoyed the first cargodest game with celestar, as we tried to build also that style
11:21:01 <dihedral> Eddi|zuHause: that's a nice one
11:21:14 <Ammler> it is not very liked in coop zone.
11:21:34 <[wito]> these stations and such makes my networks look almost childish in comparison. :(
11:22:24 <dihedral> just takes time wito
11:22:30 <Ammler> [wito]: it isn't the 1. game from Eddi|zuHause ;-)
11:25:36 <Ammler> dbg: [sprite] Ignoring 1200 unused extra bytes from the sprite from /nars2w at position 2325874
11:26:27 <Ammler> does it help to report such things to pikka?
11:32:26 <Ammler> hmm, there is a bugfix release between...
11:33:14 *** bleepy is now known as Guest379
11:33:14 *** pleeby is now known as bleepy
11:37:53 *** bleepy is now known as Guest381
11:37:53 *** pleeby is now known as bleepy
11:41:48 <[wito]> mail and goods are only "cash cows", ya?
11:41:54 <[wito]> or do they affect town growth?
11:42:48 <Eddi|zuHause> no, they affect town growth like any other transport service
11:44:43 *** Combuster has joined #openttd
11:46:47 <[wito]> are you saying that iron ore delivered to a city steel mill will affect growth=?
11:47:28 <Eddi|zuHause> (if you want a "realism" argument there: the steel mill provides jobs, so it attracts its workers to move into the town)
11:47:58 <[wito]> actually, steel mills accept passengers from the get-go, for whatever reason
11:48:05 *** HerzogDeXtEr has joined #openttd
11:48:15 <Eddi|zuHause> that is unrelated ;)
11:48:26 <[wito]> so I guess Power Station would be a better example. :)
11:48:31 <Eddi|zuHause> and you never heard of the famous soylent green steel?
11:49:10 <Zahl> hmm... could faulty newgrfs cause memleaks?
11:49:57 <Eddi|zuHause> Zahl: no, grfs have only limited storage space
11:55:00 <Zahl> Eddi|zuHause: which os are you running?
11:55:11 <Eddi|zuHause> why does that matter?
11:55:31 <dihedral> depending on the os, towns grow faster
11:55:58 <dihedral> + you get grf's for windows *w.grf which do not run on linux or mac :-D
11:56:10 <Zahl> well someone has to tell me its either normal that the game constantly uses more mem (about 8k per second with a big game) or tell me its my computer :P
11:56:58 <Rubidium> Zahl: as long as I can't reproduce it, I can't fix it
11:56:59 <dihedral> are you just missing mem or can you see that it is openttd?
11:57:19 <Zahl> Rubidium: i can send you my savegame... but as you already said, it might be a windows issue
11:57:28 <Zahl> dihedral: i can watch it in the taskmanager
11:57:52 <dihedral> well - if Rubidium looked at it ;-)
11:57:58 <Zahl> dihedral: it starts at ~30Meg and goes up to like 200 if i leave it running long enough
11:58:00 <Rubidium> the information the task manager shows can be misleading
11:58:46 <dihedral> Zahl: it's not the savegame!
11:58:56 <dihedral> oh - wait - you run a patched client?
11:59:19 <Zahl> dihedral: yes, but also happens in the trunk version
11:59:29 <Zahl> and the only think that i modifies is pretty much ticks per day
11:59:44 <Ammler> isn't it just that every cargo packet produce mem?
11:59:47 <dihedral> yes but? on a new game it also happensin trunk?
12:00:24 <Ammler> so you might have a lot waiting cargos :-)
12:00:52 <Zahl> dihedral: seems so, but i did not play a recent version with that many trains.. but anyways... loading this savegame in the trunk version should not behave like that anyway shoud it?
12:01:29 <dihedral> you play a patched client
12:01:29 <dihedral> totally not interesting
12:01:55 <dihedral> and you got Rubidiums opinion on it already - you should valuethat
12:02:21 <dihedral> rather than running around to everybody else who dares to engage in the conversation
12:02:25 <Zahl> well it will take me some time to get a savegame as big as that one in trunk but i'll try :-O
12:03:25 <dihedral> then you could download a sav from openttdcoop games
12:03:48 <Ammler> Zahl: your save works with trunk
12:03:53 <planetmaker> indeed. E.g. get #131. It's only 600 or so, but 600 vehicles, too
12:06:12 <Eddi|zuHause> i only know "no ma'am"
12:06:18 <dihedral> Zahl: works steady and fine for me
12:06:44 <dihedral> but i am on a mac, so if that should be a win issue i dont know
12:07:00 <dihedral> if the issue is related to win - you just lost ^^
12:07:51 <dihedral> and that is a clean version of OpenTTD
12:10:43 <Zahl> well i got a ottdcoop game now, same thing with recent trunk version...
12:11:13 <Zahl> i'll leave it running for an hour or so
12:11:14 <Rubidium> Zahl: even a normal game without newgrfs and/or vehicles causes the same behaviour?
12:11:14 <dihedral> unpatched game i hope
12:11:21 <Zahl> to see it it stays like that in the ling run
12:11:58 <Zahl> Rubidium: problem is i don't have a bug game with a recent clean trunk version... it will take me some time to achieve that, but i will try ;)
12:12:00 <Ammler> how long does it take to have "the effect"?
12:12:03 <dihedral> Zahl: what os (exactly)
12:12:35 <dihedral> then i should be able to reproduce that when i get home
12:12:46 <dihedral> and i will not use any patches
12:12:53 <dihedral> if you patch your game that is your own fault ^^
12:13:27 <Zahl> yeah i know, this is why i'm not starting a big "zomg this game has memleakz" thread in the forums ;)
12:14:01 <dihedral> but you file a bug report!!!!
12:14:14 <dihedral> at least in the forums we could bash you right now :-P
12:14:39 <dihedral> i loaded the map in clean trunk and it's fine
12:14:53 <dihedral> what rev are you playing when you say 'clean trunk'
12:14:57 <Eddi|zuHause> hm... sometimes, when i used my volume keys, kmix eats all my keyboard input :(
12:15:31 <Zahl> and i admit i don't know the source too well, but i just wonder: would it actually be possible that some stupid stuff a patch does gets into a savegame and causes a memleak even in the trunk version?
12:15:52 <Ammler> hmm, at least, that is what the gamelog says
12:16:09 <Zahl> recent nightly just downloaded from the website
12:16:13 <dihedral> Ammler: that could have been the patched version
12:17:12 <Ammler> and 15591 is my rev at last
12:18:13 <Ammler> [13:15] <Zahl> and i admit i don't know the source too well, but i just wonder: would it actually be possible that some stupid stuff a patch does gets into a savegame and causes a memleak even in the trunk version? <-- good question, I guess, that is the reason for the gamelog
12:18:50 <dihedral> what on earth does he mean with a patch getting into the savegame?
12:18:51 <Ammler> I assume, if a save ever is touched by a M-rev, you can drop it as bug report.
12:19:40 <Zahl_> dihedral: i mean that some bug gets into the savegame
12:20:09 <Zahl_> and that if you load this savegame in a clean trunk version, it causes this behavior, whereas a clean savegame would not
12:20:37 <Zahl_> just technically speaking
12:20:52 <dihedral> and it's a game you added and removed grf's from
12:21:04 <dihedral> you really think anybody wants to support that?
12:21:10 <Rubidium> I see no reason why it couldn't happen, but it seems unlikely
12:22:02 <dihedral> and cheated the landscape?
12:22:17 <planetmaker> Zahl: Rubidium: patched versions can introduce things like unowned stations and stuff...
12:23:58 <planetmaker> I seem to remember some mega cool person complaining about funny behaviour of his map made with such patches...
12:24:15 <planetmaker> or is just my memory faulty?
12:24:37 <dihedral> patched games just are the users own silly fault
12:24:39 <planetmaker> oh... and I didn't see a "n't" in Rubi's answer :P
12:24:51 <dihedral> complaining about them is like - totally stupid
12:25:53 <HerzogDeXtEr> the original landscape generator isnt working, it crashs openttd 0.7.0-beta1
12:25:58 <planetmaker> dihedral: certainly depends upon the patch. A daylength game which doesn't save and change anything else... but then you never know :)
12:26:07 <planetmaker> HerzogDeXtEr: afaik it's fixed in trunk
12:26:15 <Zahl_> dihedral: like i said, i'm still trying different things etc, i do not claim the game is buggy (yet ;))
12:26:36 <dihedral> you are asking for support ^^
12:26:41 <dihedral> or at least you are costing ^^
12:26:57 <Zahl> i know, but you do not have to give support if you don't want ;)
12:26:59 <dihedral> and trying to claim a game is butty with a patched game is just as stupid ;-)
12:27:10 <HerzogDeXtEr> is there still the problem that all indutries are dying on very big maps?
12:27:36 *** Brokkoli has joined #openttd
12:28:01 <planetmaker> dihedral: the revision of the assert fix :)
12:28:14 <dihedral> are you looking for @openttd commit 15111
12:28:51 <Eddi|zuHause> i really wonder why the so called "junction wikis" never mention this style of junction...
12:28:52 <Eddi|zuHause> www.informatik.uni-halle.de/~krause/Klein%20Elsmuenster%20Transport,%2023.%20Maer%201942.png
12:28:55 <Zahl> dihedral: so i guess if it also happens in a ottdcoop savegame it is not a valid argument either because of newgrf? so i should start a clean game with trunk...
12:29:17 <Eddi|zuHause> www.informatik.uni-halle.de/~krause/Klein%20Elsmuenster%20Transport,%2026.%20Feb%201934.png
12:29:49 <dihedral> Zahl: clean trunk is the best thing to use if you want to find / report a bug
12:30:09 <Zahl> ok.. might take some time :-D
12:30:10 *** KenjiE20 has joined #openttd
12:30:11 <planetmaker> Zahl: if the thing is related to use of newgrf, of course you cannot test it w/o newgrf :)
12:30:25 <planetmaker> but if it isn't - a testgame w/o is far better.
12:30:43 <planetmaker> Zahl: run an AI test game. They build fast and w/o you doing anything :P
12:30:58 <Zahl> but then it could also be caused by ai
12:31:03 <dihedral> planetmaker: afaik ai's leak
12:31:04 <Ammler> Zahl: if you use a save, type "gamelog" in the console to check if there isn't a midified version.
12:31:07 <dihedral> or at lest squirrel does
12:31:17 <planetmaker> dihedral: ok, then that rules out use of them
12:31:23 <Ammler> also possible coop games are from a modified one.
12:31:51 <dihedral> + coop games are usually crammed with newgrf's
12:32:13 <planetmaker> dihedral: depends on dfinition of "crammed wiht" :P
12:32:27 <planetmaker> But yeah, I usually add all station grfs I can get :)
12:34:03 <petern> write a patch to remove the unnecessary station class limit!
12:34:06 <planetmaker> Eddi|zuHause: what bridges did you use?
12:34:27 <Eddi|zuHause> hm, i think that was the cantilever replacement set
12:34:37 <planetmaker> petern: even though I didn't find any limit there :) Adding them only defers the decision which to use to ingame :)
12:34:39 <Eddi|zuHause> and the brick viaduct
12:34:54 <planetmaker> ah, brick viaduct might be what I wondered about
12:35:17 <Rubidium> dihedral: AFAIK squirrel doesn't leak anymore, but given the way you said it: could you give me the game where it leaks?
12:35:26 <petern> if you go over the limit they'll just end up in the default class
12:36:03 <petern> it is 32 as that was the limit on dropdowns when it was made
12:36:42 <planetmaker> ah... :) That explains why I sometimes have more than the default station in the first entry?
12:36:53 <planetmaker> I always assumed that it was a grf modifying that.
12:37:17 <Eddi|zuHause> the buffers grf adds to the default station
12:37:38 <planetmaker> yes. But I once at least had more :)
12:38:23 <Ammler> are there more then 32 station grfs?
12:38:26 <planetmaker> 32 different stations is sufficient though.
12:38:44 <dihedral> Rubidium: i have rather large other leak issues on the vps
12:39:00 <dihedral> it's kinda linked to openttd, but i cannot follow up on the vps
12:39:15 <dihedral> however, whenever openttd dies, i have an extra 600MB of free mem
12:39:17 <Ammler> hmm, same grf could have more classes
12:40:11 *** Yeggstry has joined #openttd
12:41:06 <dihedral> i wish i could find out where the issue was and how it was caused, but i cannot, i dont even get to see the issue within the vps
12:42:21 <planetmaker> dihedral: hm... last time I ran openttd for a day, it also had 570MB of virtual memory reserved. But only 28 resident...
12:43:07 <Rubidium> dihedral: so it can also be that openttd got killed, then another process in another VPS got more memory, wasted that too, got killed and then you looked how much memory was free
12:43:39 <Rubidium> planetmaker: virtual memory includes stuff like opened 'files'
12:44:39 <planetmaker> what files does it open? Beside newgrfs?
12:44:53 <planetmaker> hm... screenshots it made?
12:45:07 <Rubidium> the binary, the libraries, tars, network sockets
12:45:20 <Rubidium> video (if not-dedicated)
12:45:44 <planetmaker> yes. It was my client I had running the whole day to take a screenshot every 2 ingame months
12:46:27 <planetmaker> and I didn't watch memory over time. So it was just a confirmation on the total amount :) - I guess the virtual memory will after termination also be freed :)
12:46:46 <Rubidium> and randomised memory allocation causes such things to
12:47:05 <planetmaker> can you reccomend a tool to log the memory usage over time?
12:47:22 <planetmaker> Then it's easy for me to run tests throughout the day(s)
12:47:23 <Rubidium> no, but valgrind'll tell whether it leaks
12:47:59 <Noldo> how does the original mapgen use the sprites it needs?
12:48:05 <planetmaker> that's a test which doesn't require the programme to run, right? I've no idea about valgrind...
12:48:24 <Rubidium> Noldo: you'll have to find out yourself
12:55:56 <dihedral> Rubidium: it's a dedicated server, and i went through the issues with TB
12:56:02 <dihedral> and yes, it runs in shared mem
12:56:12 <dihedral> and i can watch the shared mem rise
12:56:19 <dihedral> and i can predict when the app gets killed
12:56:24 <dihedral> it's been going on for over a month
12:56:32 <dihedral> however, this does not happen if it's not running in the vps
13:06:32 *** Combuster has joined #openttd
13:07:44 <Forked> using that to guide the mouse pointer looks sort of painful
13:08:06 *** stillunknown has joined #openttd
13:11:43 <planetmaker> nice :) But seems like it's lacking a bit of interface comfort :)
13:12:56 <Forked> what OS on that phone?
13:13:17 <petern> it can go OFF THE SCREEN
13:13:21 <petern> who thought that was a good idea, eh?
13:14:38 <[wito]> time for a YAPP experiment!
13:38:31 *** welshdragon has joined #openttd
13:46:27 <dihedral> Japa: that looks like tiles in a kitchen
13:46:52 <planetmaker> could be ground tiles for a toyland replacement
13:47:17 <dihedral> that would be lot nicer too ^^
13:48:30 *** maristo has joined #openttd
13:52:48 *** Yeggstry is now known as Yeggs-away
13:54:39 *** wollollo has joined #openttd
14:05:06 <|Japa|> so I was trying to start replicating it by memory
14:05:56 <|Japa|> also, it's my first attempt at making a GRF
14:22:37 <petern> no need to do it as a grf
14:22:58 <petern> i did a ground sprite similar to that, but no more
14:27:22 <Eddi|zuHause> can/should 32bpp sets be handled with .obg files?
14:28:44 <Eddi|zuHause> imho it should. allows people to switch from the default graphics to 32bpp graphics the same way as to opengfx graphics.
14:29:26 <Eddi|zuHause> also allows to show a message window like "openttd must be started in 32bpp mode to support these graphics, the changes will be in effect on the next restart"
14:42:31 <planetmaker> Rubidium: with respect to translation and 1,000 € vs. 1.000 € vs. 10,00.00 €... There's a number of strings which go like "{BLUE}{COMMA}"-
14:42:55 <planetmaker> doesn't the {COMMA} denote how the number is spaced for bigger numbers?
14:43:39 <planetmaker> So far I have no idea on the use of that {COMMA} - I assumed to replace it by {DOT}
14:44:01 <planetmaker> (and wanted to test that tonight) :)
14:44:10 *** NukeBuster has joined #openttd
14:44:35 <planetmaker> So... no easy way for a translator to fix that?
14:45:02 *** [1]KenjiE20 has joined #openttd
14:45:39 *** KenjiE20 is now known as Guest399
14:45:39 *** [1]KenjiE20 is now known as KenjiE20
14:45:46 <Rubidium> as I said... whether commas, dots or spaces are used isn't a language decision
14:47:53 <Eddi|zuHause> planetmaker: {CURRENCY} != {COMMA}
14:48:16 * planetmaker should have done a stfw before :P
14:48:27 <Eddi|zuHause> as for the Language-{COMMA}-Separator, i had a patch for that.
14:48:35 <Ammler> and currency is a local setting, not language :P
14:48:40 <Rubidium> as I said... whether commas, dots or spaces are used isn't a language decision
14:50:52 <Eddi|zuHause> yeah, languages cannot override currency settings.
14:53:05 <planetmaker> hm... ok, so not translatable change then :)
14:53:06 <[wito]> speaking of currency settings
14:53:20 <[wito]> is the #{sep}### format hard-coded?
14:53:31 *** wollollo has joined #openttd
14:53:36 <[wito]> because some currencies should have groups of 4, not 3
14:54:46 <Rubidium> and then JPY isn't the hard one to support; the Indian format'll be the hard one
14:55:02 <[wito]> how is the indian one?
14:56:35 <Rubidium> 1,000 1,00,000 1,00,00,000 1,000,00,000 (or that's what I understand from wikipedia)
14:56:38 <[wito]> but actually, the separator concern would apply to all numbers in the Japanese translation
14:58:19 <Eddi|zuHause> Rubidium: so alternating groups of 2 and 3?
14:58:31 <Ammler> Eddi|zuHause: your patch would need something like a 2. base language, so you could make language files for de_CH and use de as base, but don't need to replace all strings.
14:58:49 <Eddi|zuHause> Ammler: yes, we discussed that already ;)
14:59:14 <Eddi|zuHause> possibly add a "##fallback" pragma?
14:59:15 <Ammler> oh, indded, might be :-)
14:59:39 <[wito]> so changing number formats in translation a no-go on the whole?
15:00:05 <Rubidium> haven't I said that like a three times already?
15:00:28 <[wito]> or actually, I kept subtly rephrasing the question. ;)
15:00:32 <Rubidium> Eddi|zuHause: I don't know how the indian numbering actually works
15:03:19 <Rubidium> comma is used at levels of thousand (1000), lakh (100 000) and crore (10 000 000) which would suggest at 3, 5, 7, 10, 12, 14, ...
15:05:30 <Rubidium> but then the wiki seems very inconsistent to me
15:11:28 <Belugas> comic pack... too bad it cannot be used somewhat :(
15:14:40 <dihedral> what is it lisenced under?
15:15:17 <Rubidium> other pages seem to suggest that indian is last group of 3, groups before that of 2
15:15:49 <Eddi|zuHause> do the indians themselves even know?
15:15:52 <planetmaker> Belugas: yeah... :S that'd be a nice look :)
15:15:53 <Rubidium> chinese/japanese seem to want to add their 10 000/100 000 000 etc. characters in between
15:16:37 <Rubidium> so you'd get something like 2 million 345 thousand 678
15:17:09 <|Japa|> ohh, what'd I miss here?
15:17:35 <Eddi|zuHause> well, more like "2M345k678" i presume, since they would be "1-character-words"
15:17:42 <dihedral> Rubidium, nobody else missed that ^^
15:18:05 <|Japa|> we talking languiages?
15:18:38 <Eddi|zuHause> not languages, numbering formats
15:18:46 <|Japa|> so for the possibility of having Rs. 10,00,00,00,000 ?
15:20:33 <petern> if you ... really wanted
15:21:24 <|Japa|> I'd learn to program, yeagh
15:21:24 <dihedral> planetmaker, as for crashed planes: "bei dem unfal gab es {num} tote und ein paar zwerquetschte" ^^
15:22:00 <planetmaker> dihedral: you're a registered translator :P
15:22:20 <dihedral> i was makeing a joke, not wanting to force it into the strings
15:23:03 <Eddi|zuHause> that was actually funny ;)
15:24:46 *** Mortomes has joined #openttd
15:25:19 <|Japa|> dihedral, if I can't even manage to download the source, it doesn't bode well for my chances of sucess at anything programming wise
15:26:19 *** stuffcorpse has joined #openttd
15:29:04 <Rubidium> not being able to download a tarball sounds like a serious offense to me
15:29:29 <|Japa|> well, not gettin SVN to work right, anyways
15:29:43 *** Swallow has joined #openttd
15:32:55 <Belugas> planetmaker, it would look so much better than all those photorealistic packages ;)
15:33:08 <nicfer> I'm wondering - would be too many work to rewrite industries like towns?
15:34:22 <nicfer> that would be, if you destroy a tile (like houses in towns) it gets rebuilt in a nearby place
15:35:47 <planetmaker> Belugas: well... not necessarily better IMO. But it would IMO be THE replacement for toyland :)
15:35:55 <planetmaker> And then really look nice.
15:36:11 <planetmaker> And it's something very unique in its own. Nice style
15:39:01 <Eddi|zuHause> nicfer: yes, that would be too much work
15:39:55 <Eddi|zuHause> comic as 32bpp replacement for toyland... interesting idea
15:40:12 <Belugas> planetmaker, it would be better. not just for toyland
15:40:23 <Belugas> photorealism makes the game loos part of his ...
15:40:29 <Eddi|zuHause> but the images i have seen from the comic set might be too much based on "real" building to suit as toyland replacement
15:41:23 <planetmaker> Belugas: well... :) I like both styles. Variety's the spice of life ;)
15:41:32 <Eddi|zuHause> i agree with belugas, photorealistic breaks the game style. besides, some of the perspective-trickeries get really apparent with pseudo-photorealism (e.g. the shortened wagons)
15:41:54 <Eddi|zuHause> (or other scale "misalignments"
15:44:32 <[wito]> Rubidium: re japanese number format: japanese only usually adds the characters when the number is written as a word
15:44:38 <[wito]> (like you would on a check)
15:45:18 <[wito]> when they write as numbers they write 1.0000.0000
15:47:20 <Eddi|zuHause> how does that work anyway? in latin-based alphabets, this "word" writing of numbers on checks was introduced as a measurement to avoid cheating (e.g. replacing digits, or adding digits) because you can replace the words less easily by just writing over them
15:48:20 *** stuffcorpse has joined #openttd
15:48:22 *** TrueBrain has joined #openttd
15:48:28 <TrueBrain> hello lovely people
15:49:36 <Eddi|zuHause> hm, in germany that works differently...
15:49:44 <Eddi|zuHause> one person says "Prost ihr Säcke"
15:49:50 *** bleepy is now known as Guest408
15:49:51 *** pleeby is now known as bleepy
15:49:57 <Eddi|zuHause> and the others reply accordingly "Prost du Sack" :p
15:50:17 <TrueBrain> Eddi|zuHause: nobody cares about german people
15:50:47 <Eddi|zuHause> that might be true, but the two statements are totally uncorrelated :p
15:52:17 *** bleepy is now known as Guest409
15:52:17 *** pleeby is now known as bleepy
15:53:30 <TrueBrain> every 6 months I order for the same amount of money a new HD ... a few years back that was 160 GB ... now it is 1 TB ... weird times ..
15:54:56 <TrueBrain> Yexo: I redirected some user to you with a NoAI related question
15:55:01 <TrueBrain> didn't feel like reading what he was asking :p
15:55:23 <Yexo> that's fine, but I haven't seen any question yet
15:58:20 *** bleepy is now known as Guest410
15:58:20 *** pleeby is now known as bleepy
16:01:05 *** bleepy is now known as Guest412
16:01:05 *** pleeby is now known as bleepy
16:01:21 <TrueBrain> bleepy: would you mind either staying or leaving?
16:03:09 <Rubidium> seems like he likes leaving
16:03:31 <TrueBrain> that I gathered, yes
16:03:36 <TrueBrain> thank you for that clearification ;)
16:03:59 <TrueBrain> hmm .. my C application fails to download at 100 mbit/sec :(
16:05:17 *** tkjacobsen has joined #openttd
16:06:15 <Rubidium> read in bigger blocks?
16:06:21 <Rubidium> write in bigger blocks?
16:07:00 <TrueBrain> and I guess I need to increase the sendbuffer of the socket yes :)
16:07:59 <Eddi|zuHause> anyone lingually and musically educated enough to explain to me how to translate the musical intervals ("Prime", "Oktave", "{große|kleine} {Sekunde|Terz|Sexte|Septime}" and "[verminderte|übermäßige] {Quarte|Quinte}") into english?
16:08:21 *** wollollo has joined #openttd
16:08:45 <glx> Eddi|zuHause: I can translate some of them into french ;)
16:10:02 <planetmaker> Eddi|zuHause: ^ :P
16:10:08 *** goodger has joined #openttd
16:11:01 <nicfer> release dates suck, and is one of the motives because some games are ruined
16:11:11 <nicfer> example, duke nukem forever
16:12:46 <Firzen> How to solve a new grf conflict?
16:12:50 <Eddi|zuHause> err... i don't think this "example" fits your statement
16:12:57 <Eddi|zuHause> Firzen: deactivate one.
16:13:02 <Firzen> Do the clients need to download the grf files manually?
16:13:37 <Eddi|zuHause> Firzen: if the GRFs are not available on the content server, they have to be downloaded manually
16:13:59 <Eddi|zuHause> an established quasi-standard for that is the Coop-GRFPack
16:14:27 <Eddi|zuHause> which should contain about 98% of the GRFs found on servers
16:15:08 <Brokkoli> but at least about 80% *g*
16:15:21 <TrueBrain> nobody likes a smartass
16:15:45 <Eddi|zuHause> 93,6% of all statistics are made up on the spot.
16:16:33 <planetmaker> that's no good way, if you want people join your server. You need a central grf repository for that
16:17:19 <Rubidium> Eddi|zuHause: no 0% of all statistics are made up on the spot
16:17:25 <planetmaker> well... bananas is one. And the coop grfpack is the predecessor with some grfs more
16:17:32 <Brokkoli> if you want people to join your server, only use bananas grfs
16:17:40 *** ChanServ sets mode: +v tokai
16:17:41 <planetmaker> which cannot or won't be uploaded to bananas.
16:17:51 <planetmaker> We won't include bananas content anymore, though
16:18:02 <Eddi|zuHause> Rubidium: well, basically, that is a direct lemma of "Do not trust a statistics that you did not fake yourself"
16:18:14 <planetmaker> Brokkoli: why should we? It's much work to update.
16:18:29 <planetmaker> And bananas is usually more up to date.
16:18:31 <Brokkoli> and i think its worth the work
16:18:37 <planetmaker> Brokkoli: you did it already several times, eh?
16:18:58 <TrueBrain> I see this channel gained an other know-it-all
16:19:13 * planetmaker wonders how people aways see things other people do as "not much work"...
16:19:27 <Ammler> we we only delete grfs from the pack anymore, I hope ;-)
16:19:31 <Brokkoli> ok sorry i havn't meant it that way
16:20:32 <Rubidium> planetmaker: is it much work for them? No, then it's not much work
16:20:34 <planetmaker> main reason is: bananas is up to date.
16:20:47 <Eddi|zuHause> Ammler: if you can convice MB to put the DBSet 0.9 on bananas ;)
16:21:00 <planetmaker> Eddi|zuHause: I'll definitely give it a try :)
16:21:32 <planetmaker> But then, I think, it was easier, if bananas allowed to download the grfs via webinterface
16:21:39 <planetmaker> That way also TTDP users could use it.
16:21:48 <Eddi|zuHause> i wouldn't hope for a near release of another newships grf
16:21:57 <TrueBrain> planetmaker: or TTDP could use the open protocol to make an ingame thingy too! :)
16:22:09 <Brokkoli> ok not a new but the old one.. for the "bananas-only" users
16:22:09 <glx> TrueBrain: I'm following your howto crosscompile for mac, works quite well (I already have i686-apple-darwin9)
16:22:10 <Rubidium> planetmaker: nothing prevents them from implementing the protocol
16:22:20 <planetmaker> That'd be the nicer solution, certainly :)
16:22:28 <TrueBrain> glx: yeah ... when I write documentation, it mostly adds up ;)
16:22:36 <TrueBrain> nice to see there is still interest in that ;)
16:22:44 <Ammler> don't think there will be big new feature for ttdp anymore.
16:23:27 <TrueBrain> then why bother at all ;)
16:23:46 <glx> TrueBrain: it's more like we have a weird problem with osx 10.3.9 nightlies (and we don't know yet what cause it) ;)
16:23:54 <Ammler> well, but something for the server admins would be nice.
16:24:08 <TrueBrain> and by the lack of a certain person to produce any binary for 10.3.9 .. I guess it isn't going anywhere either ;)
16:24:12 <Eddi|zuHause> OpenTTD would not be where it is now if it did not have TTDPatch to lead it (feature-wise)
16:24:16 <planetmaker> TrueBrain: dedicated servers :)
16:24:34 <TrueBrain> Eddi|zuHause: and visa versa ;)
16:24:48 <planetmaker> And it would make grf authors more comfortable, I think, as their work is then available from _one_ place, even without a client
16:25:37 <glx> TrueBrain: yeah, that's why we need another way to try things ;)
16:25:42 <planetmaker> "it's not much work to implement a download of the tars" :P
16:25:51 <glx> btw I have a 10.3.9 pearpc VM
16:25:55 <Ammler> TrueBrain: currently, you have to load a save local and transfer the content to the server...
16:25:56 <TrueBrain> glx: creating your own i686-apple-darwin9 most likely won't really help
16:26:03 <Rubidium> TTDP seems to be killing itself by not making a new release and thus having people disregard it as they downloaded the stable and can't get many things working
16:26:15 <TrueBrain> glx: the problem might be in the fact it is darwin9 .. you might also want to try darwin8, although there shouldn't be any difference :)
16:26:22 <planetmaker> Rubidium: might be, yeah
16:26:51 <TrueBrain> Ammler: then I wonder how I download AIs via my dedicated server
16:26:58 <glx> but the weird thing is it stopped working without any changes
16:27:02 <TrueBrain> I guess it is my imagination that those files get where they should go ...
16:27:15 <Eddi|zuHause> so i am not the only one who finds it weird that they started 2.6.alphas before finishing a 2.5 release?
16:27:23 <TrueBrain> glx: well, that might be only perspective :) No 'registered' changes ;)
16:27:41 <TrueBrain> I think it is a relocation error .. might be the binary size, might be the blocksize ..
16:28:28 <TrueBrain> glx: but having a VM to test on, might greatly help solving the problem ;)
16:28:49 <Ammler> TrueBrain: workaround was to download all, indeed.
16:29:24 <Ammler> but that might fail, if a older version is needed.
16:29:44 <TrueBrain> 'a server' and 'older version needed' doesn't combine
16:30:02 <TrueBrain> as even as client you can't download an 'older' version (unless you join an already running server with an older version)
16:30:59 <TrueBrain> glx: anyway, good luck ;) I hope you can find something .. let me know if you need anything :)
16:31:14 <Eddi|zuHause> you can, if you e.g. run a 0.7.x server and 0.8-nightly, some grfs might be flagged as "requires 0.8-nightly", while an older version of that grf might be available for 0.7.x
16:31:17 <TrueBrain> (I would btw start with compiling OpenTTD under 10.3.9 natively, see if that fixes theproblem ;))
16:31:37 <Eddi|zuHause> so if you run both servers with the same data-directory
16:31:45 <TrueBrain> Eddi|zuHause: a non-issue for the situation Ammler created
16:32:16 *** const86 has joined #openttd
16:32:42 <Eddi|zuHause> maybe you accidently updated, and want to roll back to the older version, because you did not like the changes?
16:33:16 <Ammler> that is even not possible for the uploader ihimself
16:33:36 <TrueBrain> Eddi|zuHause: and having a method to download via the websites solves that ... how? :p
16:33:52 <Eddi|zuHause> hm... that might be a point ;)
16:34:09 <Ammler> if you load the save, it outputs the grfid and md5sum
16:36:48 <planetmaker> [17:33] <TrueBrain> Eddi|zuHause: and having a method to download via the websites solves that ... how? :p <-- that's two completely different issues
16:37:02 <TrueBrain> planetmaker: we were talking about that, right?
16:37:14 <TrueBrain> Ammler started wining about something to me, so I can only conclude it was related to that :p
16:37:26 <planetmaker> yes, we were talking about web download at least initially :)
16:37:41 <TrueBrain> at least I am not going mental ;)
16:37:55 <planetmaker> Ammler's issue is indeed another.
16:38:02 <planetmaker> But it's a valid one IMO, too :)
16:38:20 <TrueBrain> so wine to who ever you need to wine about that
16:38:26 <planetmaker> it's very tricky to get the needed grfs of a savegame to a dedicated server
16:39:34 <Ammler> is the source available?
16:39:52 <TrueBrain> don't you just love people
16:39:55 <TrueBrain> 'is the internet down'
16:41:08 <Eddi|zuHause> TrueBrain: "the whole internet?"
16:41:26 <Eddi|zuHause> TrueBrain: i had such a discussion a few days ago
16:42:06 <Rubidium> yup, googling google breaks the internet, which is a small black box
16:42:10 <Eddi|zuHause> well, a meta-discussion, as in "what do you respond when someone asks this kind of question"
16:42:28 <TrueBrain> Rubidium: with a light on top of it!
16:42:42 <TrueBrain> Eddi|zuHause: in the same line of questions: what is the black hole?
16:42:47 <planetmaker> Eddi|zuHause: I think he has a serious issue with understanding how these signals are meant to work and how he can use them to create exactly what he wants.
16:42:50 <TrueBrain> (mind the 'the', not 'a')
16:43:17 <Eddi|zuHause> TrueBrain: i'd relay that question to planetmaker ;)
16:43:18 <Rubidium> TrueBrain: the part of you that talks shit ;)
16:43:23 <Eddi|zuHause> he's the expert ;)
16:44:37 <TrueBrain> hmm .. Xen seems to drop my IO performance with 50% ...
16:44:55 <TrueBrain> I need to add I am downloading at 100 mbit/sec .. so IO delays are very noticable ;)
16:50:19 *** Illegal_Alien has joined #openttd
16:57:19 <Brokkoli> i've got an idea about a new "pbs signal" there are now pbs and pbs-one-way... sometimes i'd need a thing which acts as a pbs-one-way from one side - blocking the way back - but from the othere side there should not be a valid stopping position.. so it's no signal at all... just kinda "oneway-sign" for tracks
16:58:03 <Eddi|zuHause> wow, a completely new never-heard suggestion! how rare is that!
16:58:33 <planetmaker> lol @ Eddi|zuHause & Brokkoli
16:58:41 <planetmaker> Brokkoli: play the game, test the signals and find out
16:58:58 <planetmaker> or look into the wiki
16:58:59 <Brokkoli> there is no signal like that
16:59:18 <planetmaker> have you played with path signals actually?
16:59:25 <Eddi|zuHause> no, there is not, and i don't think there will be
17:00:08 <Brokkoli> sometimes i got problems with trains turning around.. and going the wrong way.. because there is nothing like that
17:00:14 <planetmaker> you cannot block one way and at the same time allow passing through from that side
17:00:31 <Eddi|zuHause> the two remaining signal types are kinda-reserved for "advance" (yellow) path signals
17:00:35 <planetmaker> Turning trains is another issue. Change wait_on_pbs_signal = 255
17:00:40 <planetmaker> or something like that
17:01:01 <Brokkoli> but sometimes turning is ok
17:01:08 <Eddi|zuHause> planetmaker: i think you are missing the point
17:01:13 *** TrueBrain has left #openttd
17:01:31 <Brokkoli> i'll create a screenshot
17:02:52 <planetmaker> Eddi|zuHause: oh... I think, I get it now. Just a "no entry" sign.
17:02:58 <planetmaker> right, Brokkoli ?
17:03:47 <Eddi|zuHause> yes. i think they might be kinda useful on certain complex switch-blocks
17:03:57 <Brokkoli> the red line is a valid parking position
17:04:07 <Brokkoli> but the blue signal is not ok there
17:04:30 <Brokkoli> - but when i don't have it there trains could turn around and go the dotted line
17:04:43 <Brokkoli> so it sould be only a no-entry
17:07:14 <petern> i prefer to not let my trains turn around
17:07:36 <Brokkoli> me too, but by default they will do
17:07:38 *** Vikthor has joined #openttd
17:08:03 <Brokkoli> and its a server setting, not a client setting.. so i cannot avoid it
17:08:16 <Eddi|zuHause> i'd prefer my trains would throw a message instead of turning around when they are stuck
17:08:34 <Eddi|zuHause> but nobody listens to me
17:14:45 <[wito]> am I the only one who uses LHD? ;)
17:18:11 <Eddi|zuHause> <Belugas> what? <- exactly. ;)
17:18:42 <petern> [wito], no, all sensible people do
17:18:56 <Rubidium> but it isn't the right side of the road
17:23:02 *** |Jeroen| has joined #openttd
17:28:36 *** [com]buster has joined #openttd
17:30:18 <[wito]> Rubidium: of course it isn't
17:30:23 <|Japa|> I've had a problem with PBS sometimes
17:30:31 <|Japa|> I get trains playing leapfrog
17:30:39 <|Japa|> is there a way to avoid that?
17:31:05 <[wito]> |Japa|: I hope I won't get quieted for telling you this;
17:31:39 <[wito]> but real track configurations are generally a N-S track and a S-N track with a central two-way track
17:32:03 <Eddi|zuHause> |Japa|: not reliably
17:32:26 <[wito]> The two-way two-track configuration is simply not a realistic approach to building railways
17:32:47 <[wito]> This extends to roads as well;
17:32:55 <Eddi|zuHause> [wito]: it is, but the signalling system is not able to handle it very well
17:33:44 <Eddi|zuHause> [wito]: many german double track lines are refited for "Gleiswechselbetrieb" (i.e. operating both rails in both directions)
17:34:31 <[wito]> Well, at present rail conductors are often somewhat more intelligent even than YAPP. ;)
17:34:36 *** [com]buster is now known as Combuster
17:34:38 <|Japa|> well, the line I travel on a lot here in india has 4 tracks on it
17:35:11 <[wito]> I assume that cycles 3-1, 2-2, 1-3?
17:35:23 *** frosch123 has joined #openttd
17:35:26 <Eddi|zuHause> the problem is you cannot reliably tell the slow trains to not attempt overtaking
17:36:14 <|Japa|> I guess I have to test with different distances between crossovers
17:36:43 <Eddi|zuHause> (also, realistically, the slow train will go on the "wrong" track, you can't model that properly either)
17:37:43 <|Japa|> I wonder if there's a good way to handle trains of different speeds on the same track
17:38:02 <Eddi|zuHause> |Japa|: i have given up on attempting a bi-directional double track. they are usually too crowded in either direction, that overtaking is simply not possible, and if overtaking is possible, the wrong train attempts the overtake
17:38:05 <[wito]> I've been doing a bit of testing with that
17:38:27 <[wito]> that's what I'm going to test now
17:38:55 <Eddi|zuHause> what i have done meanwhile is having freight trains split to a secondary track near intermediate stations, and forcing them to wait there, while any faster train behind them will overtake
17:39:25 <|Japa|> specially with cargodest, it makes sense to have local and express trains
17:40:15 <Ammler> 3 lines where only the middle one is bidirectional works well
17:40:39 <Eddi|zuHause> yes, i have done this for a really overcrowded line
17:41:08 <[wito]> Ammler: I take it that works best when you use VA crossovers instead of XX ones, ya?
17:41:20 <nicfer> lmao, my antivirus is detecting that explorer.exe (a system's task!) is trying to create a file called autorun.inf
17:41:42 *** Progman has joined #openttd
17:42:01 <Eddi|zuHause> www.informatik.uni-halle.de/~krause/Cottbus%20Transport,%2029.%20Mai%201930.png <- for example this stations, the freight trains will be scheduled to wait on the siding even if they have nothing to load/unload at the station, to allow faster passenger trains to overtake them
17:42:05 <|Japa|> you's be surprised how many viruses names themselves explorer.exe
17:42:19 <Ammler> [wito]: not sure, what you mean
17:43:09 <[wito]> Ammler: on a N-S track: N-branch, N-merge, S-branch, S-merge ....
17:43:13 <nicfer> that app is in the directory c:\windows
17:45:00 <Ammler> Eddi|zuHause: are all signals pbs there?
17:46:39 <[wito]> Ammler: I don't like X. :P
17:46:54 <[wito]> It causes my trains to do these silly 90 deg maneuvers at all times. .P
17:47:08 <Eddi|zuHause> [wito]: you can turn off 90° curves
17:48:13 <[wito]> does that work with YAPF?
17:48:21 <[wito]> I thought that required NPF
17:48:54 <Eddi|zuHause> cool... i still have the build for this paxdest savegame! :p
17:50:25 <planetmaker> Eddi|zuHause: we need the advance signals :)
17:50:47 <Ammler> [wito]: I guess, at least NPF
17:51:01 <Ammler> yapf is a little bit more :-)
17:52:20 <[wito]> I thought (because of the name) that YAPF was something else entirely
17:52:35 <[wito]> but if YAPF is more like NPF++, I guess it would work. ^_^
17:52:41 <Yexo> it is, but it also supports that setting
17:53:07 <Eddi|zuHause> www.informatik.uni-halle.de/~krause/Klein%20Elsmuenster%20Transport,%2023.%20Maer%201942.png <- my triple-track section
17:53:43 <[wito]> turns out that specific aspect has been clarified in the 0.7.0 patch interface
17:53:58 <[wito]> instead of (Requires NPF) it says (Not with NTP)
17:54:17 <[wito]> don't know why I haven't tried turning it on before, tho'. :P
17:54:27 <[wito]> sillynoob is silly. :P
17:57:06 <Eddi|zuHause> come back when sillynoob has run out of silly
17:58:40 <Eddi|zuHause> www.informatik.uni-halle.de/~krause/Klein%20Elsmuenster%20Transport,%202.%20Jan%201942.png <- PS: this is why triple-tracking that section was necessary
17:59:39 <Eddi|zuHause> PPS: don't try to scroll on a screenshott
18:00:34 <[wito]> Eddi|zuHause: that's surprisingly hard
18:00:45 <[wito]> What's even harder is not holding tab when images are loading slowly. ;)
18:01:07 <Eddi|zuHause> well, i don't have that reflex
18:03:18 *** Swallow has joined #openttd
18:05:33 <petern> and the unpause button does not work :(
18:06:41 <Eddi|zuHause> hm... this game has serious daily hiccups... it's basically unplayable...
18:11:14 *** Swallow has joined #openttd
18:12:07 *** pavel1269 has joined #openttd
18:12:39 <[wito]> in the german station names, I see a lot of Gbh
18:14:32 <Eddi|zuHause> "Güterbahnhof" as in "Cargo station"
18:15:41 <Eddi|zuHause> compare to "Hbf" (Hauptbahnhof -> Main station), "Pbf" (Personenbahnhof -> Passenger station), "Rbf" (Rangierbahnhof -> Shunting station)
18:16:35 <[wito]> so is that a manual renaming convention, or is that part of the language files (a.la. Mines, Forest in English)?
18:16:53 *** pavel1269 has joined #openttd
18:24:01 <[wito]> how, by the way, does the 'Distant Joining of Stations' work?
18:25:21 <[wito]> "When in doubt: CTRL key."
18:26:21 <petern> aka "hidden feature" key
18:27:37 <frosch123> Eddi|zuHause: How did you cheat in your alpine game to make the town grow?
18:27:59 <Eddi|zuHause> i have no idea, it just did...
18:28:37 <Eddi|zuHause> or i remember wrongly and the town actually was below the snow line sometimes...
18:30:15 <Eddi|zuHause> i have a trunk-loadable version of that game somewhere... (only changes back then were daylength, station catchment radius and middle stop, i believe)
18:30:52 <Eddi|zuHause> (later i added yapp, and maybe a few other patches)
18:32:06 <Ammler> frosch123: since when doesn't a town grow in apline?
18:32:51 <Ammler> well, maybe we have only arctic games, need to check...
18:34:56 <Ammler> yeah, the games I had in mind, were before newindustries
18:35:03 *** sigmund has joined #openttd
18:35:25 <Ammler> might be possible, Eddi|zuHause started that game before too :-)
18:36:09 <Eddi|zuHause> i started it with an early version of newindustries, afair
18:36:25 <Eddi|zuHause> it went on a rather long time
18:36:50 <Eddi|zuHause> now... i am sure i uploaded the savegame before... but where...
18:38:10 <Eddi|zuHause> www.informatik.uni-halle.de/~krause/Regenswald%20Transport,%202.%20Apr%201970.sav <- might require right-click and save as
18:40:05 <frosch123> that is a different game
18:40:29 <Zahl> dihedral: starting 1k-trains-in-clean-trunk project now, wish me luck (whatever that means here :p)
18:40:31 <Eddi|zuHause> starts with R, too ;)
18:40:37 <CIA-1> OpenTTD: translators * r15602 /trunk/src/lang/ (7 files in 2 dirs): (log message trimmed)
18:40:37 <CIA-1> OpenTTD: -Update: WebTranslator2 update to 2009-03-03 18:40:15
18:40:37 <CIA-1> OpenTTD: brazilian_portuguese - 1 fixed by tucalipe (1)
18:40:37 <CIA-1> OpenTTD: dutch - 1 fixed by habell (1)
18:40:37 <CIA-1> OpenTTD: german - 1 fixed, 12 changed by planetmaker (13)
18:40:39 <CIA-1> OpenTTD: hungarian - 1 fixed by alyr (1)
18:40:39 <CIA-1> OpenTTD: indonesian - 1 fixed by fanioz (1)
18:41:16 <Eddi|zuHause> www.informatik.uni-halle.de/~krause/Ravenswald%20Transport,%202.%20Jan%201972.sav
18:41:41 <Eddi|zuHause> matches the regexp "R.*wald" :p
18:42:01 <Eddi|zuHause> nobody reads the middle of a word ;)
18:43:06 <frosch123> i have only a compatible grf
18:43:11 <Eddi|zuHause> i mean, i did, but afaik not when i started that game...
18:44:17 <Eddi|zuHause> i edited the introduction dates for the oil wagons for a later game
18:44:19 <planetmaker> full-moon hacker Eddi|zuHause :P
18:45:02 <Eddi|zuHause> i don't remember doing anything else with the dbset
18:45:07 *** Yeggs-away is now known as Yeggstry
18:45:33 <Ammler> he needed to test his compiler ;-)
18:46:00 <frosch123> Eddi|zuHause: the town is not above the snowline for the whole year :)
18:46:36 <Eddi|zuHause> i have a savegame of july, where the town appears to be exactly on the snow line
18:48:12 <Eddi|zuHause> it says "requires food" there
18:49:13 <frosch123> that is said when the town is above summer snowline
18:51:39 <Eddi|zuHause> i have towns way below the snow line that say that
18:52:00 <frosch123> ok, started a new scenario with a town definitely above snow line, and it also grows
18:52:06 <frosch123> at least when funded
18:55:56 <frosch123> ah, yes, funding building circumvents the food/water test
18:56:44 <db48x> maybe that's what you're spending your money on
18:56:56 <Eddi|zuHause> yeah, but afair i funded buildings only once
18:58:27 *** Powerek38 has joined #openttd
18:59:41 <Powerek38> is there any vehicles that enables to carry products from new industries (like fruit, oil seeds etc.) by road? I've found it possible only by rail so far...
18:59:53 <Eddi|zuHause> i'm always amazed about how many connection stubs i have spread around the whole network...
19:00:15 <[wito]> Powerek38: I think there's an RV refit NewGRF
19:00:24 <Eddi|zuHause> Powerek38: yeah, for example the german road vehicle set
19:00:53 <Eddi|zuHause> it adds lots of trams, and busses, and it makes the regular trucks carry new cargos
19:01:07 <Belugas> plus, of course, it's german.
19:01:26 <Eddi|zuHause> there is also pikka's "hovs" set, but afair that one is unfinished
19:01:47 <Powerek38> Eddi|zuHause: ok, I'll check whether I've already downloaded and added that German set
19:02:03 <Ammler> Powerek38: there are a lot just check grfcrawler
19:03:09 <Ammler> (dunno, if there is a rv set not supporting new cargos)
19:03:10 <glx> eGRVTS should be able to transport thet too
19:03:42 <Ammler> (would at least be harder to find ;-)
19:07:15 <Powerek38> ok, thanks a lot :)
19:10:12 <Belugas> funny... another example of "i dowloaded it all, but i do not know what it's used for"
19:11:26 <Aali> obviously, more grfs = bigger e-penis
19:11:54 <Belugas> and as usual, more on something == less on other...
19:12:20 <Belugas> by the way, i'm pretty stupid!
19:32:07 *** smeding has joined #openttd
19:36:51 *** stillunknown has joined #openttd
19:38:58 *** SHRIKEE has joined #openttd
19:41:14 <batti5> Announcement: The First version of Romanian Train Set has been relased, v0.1
19:43:15 *** Alberth has joined #openttd
19:47:45 *** NightKhaos has joined #openttd
19:49:06 *** goodger has joined #openttd
19:52:36 *** Combuster has joined #openttd
19:52:46 *** NightKhaos has joined #openttd
19:54:57 *** Progman has joined #openttd
19:58:52 *** Hirundo has joined #openttd
19:59:41 *** Hirundo is now known as Swallow
20:14:05 *** BobbySixkiller has joined #openttd
20:27:31 *** Mortomes has joined #openttd
20:34:10 <CIA-1> OpenTTD: rubidium * r15603 /trunk/src/ (core/alloc_type.hpp gfx.cpp): -Fix [FS#2696]: crash when using an extraordinarily large sprite as cursor.
20:34:13 *** wollollo has joined #openttd
20:35:09 <Zuu> Hmm, now thats a neat bug, using an extraordinary lange cursor sprite. :-)
20:37:24 <Belugas> like... protect the bugs.openttd.org from noobs who try their best to overpopulate it
20:37:55 <Rubidium> yeah, cursors in excess of 128x128 pixels (8bpp) or 64x64 pixels (32bpp)
20:38:02 <Rubidium> like the aircraft of OpenGFX
20:38:52 *** Mortomes has joined #openttd
20:44:41 *** goodger has joined #openttd
20:46:19 *** DaleStan has joined #openttd
20:53:37 *** Combuster has joined #openttd
20:54:13 *** genclay has joined #openttd
21:18:37 *** ChanServ sets mode: +o Bjarni
21:44:01 *** MrFrans has joined #openttd
22:00:14 *** [com]buster has joined #openttd
22:04:38 *** [com]buster is now known as Combuster
22:06:14 *** Brianetta has joined #openttd
22:25:31 *** Rexxars has joined #openttd
22:33:04 *** Dred_furst has joined #openttd
22:37:28 *** Dred_furst` has joined #openttd
22:46:22 <CIA-1> OpenTTD: rubidium * r15604 /trunk/src/town_cmd.cpp: -Fix [FS#2661]: towns would only build houses where the grid would not be, even when they aren't allowed to build roads and the user 'implements' another layout.
22:50:05 *** valhalla1w has joined #openttd
22:58:16 *** Nite_Owl has joined #openttd
23:13:20 <Cutter> why is it impossible to build diagonal rails on slopes?
23:15:46 <Eddi|zuHause> there are a few design problems before even starting to implement those
23:16:45 <Eddi|zuHause> like the connection between sloped diagonal rails and level rails, because the "cut" must be orthogonal to the diagonal rails, but the tile border is not
23:17:27 <Eddi|zuHause> also, diagonal slopes are steeper than normal ones
23:19:22 *** Dred_furst has joined #openttd
23:19:44 <Brokkoli> ah now i understand shich slopes you mean ;)
23:20:39 <Cutter> what about one rail half sloped half levelled?
23:21:10 <Cutter> so the connection doesn't have to be in the middle of a cell
23:25:06 *** Ralphis has joined #openttd
23:26:54 <Eddi|zuHause> then you need at least 3 adjacent tiles for a complete slope, so you need tile-sets that cannot be split
23:27:09 <Eddi|zuHause> currently, each rail tile is handled individually
23:27:48 <Eddi|zuHause> so you need additional (program) infrastructure to handle multi-tile-rails
23:29:49 <Eddi|zuHause> which might be cool, because similar infrastructure could be used for wider road curves, two tile wide highways, it could be used as a basis for newgrf road stations
23:30:06 <Eddi|zuHause> but it is a hell lot of work, and it must be designed properly
23:30:09 <Bjarni> diagonal slopes will need quite a lot of coding. I guess Eddi|zuHause pointed out one major issue with the multi tile tracks
23:30:31 <Bjarni> but also slope handling for acceleration is hardcoded for one tile
23:31:03 <Bjarni> in fact quite a lot of stuff is hardcoded for the current use
23:31:24 <Bjarni> if this were easy to add, then it would have been done a long time ago ;)
23:32:02 <Bjarni> like signals in tunnels. If it were as easy as some people imagine then it would have been added years ago
23:34:02 <Bjarni> also regarding different grades of slopes: if it should be of any use then we would need a better resolution of height. Say we want half of the grade, then we would need a tile border that's say 3 and 1/2 over sea level, but we can only accept 3 or 4 in the current design
23:35:40 <Bjarni> <Cutter> so the connection doesn't have to be in the middle of a cell <-- currently all rail code is hardcoded to have the rails in the middle of a tile border. I guess it would be messy to change that
23:35:51 <Eddi|zuHause> the multi-tile-issue gets even worse, since they are actually multi-half-tile (people WILL demand to put two rails in parallel)
23:36:39 <Bjarni> I wouldn't mind the result, but recoding to allow this would be like starting over
23:38:23 <Bjarni> I think ludde started coding 9 years ago. It goes without saying that changing something fundamental is hard at this time
23:38:34 <Bjarni> also it would waste a lot of the time already spent coding
23:39:45 <RS-SM> by the way, what engine is it, or is it some horrible custom make
23:40:57 *** ChanServ sets mode: +v tokai
23:43:51 <Eddi|zuHause> whatever you mean by "horrible", the "TT engine" was created by Chris Sawyer by himself
23:47:05 <SmatZ> RS-SM: what is bad about using "custom" engines? do you have any idea what engine could be used?
23:47:18 <RS-SM> no, I don't mind custom engines
23:47:24 <RS-SM> Its just from hearing all the code talk
23:47:35 <RS-SM> this game seems like it has 2 cores
23:49:30 <RS-SM> 2 core parts, since it acts like a early 90s DOS game, yet the modern hacks like that underground rail thing someone showed off
23:49:38 <Eddi|zuHause> you mean there would be less code-talk if it was a "non-custom-engine" (whatever that is)?
23:50:09 <Eddi|zuHause> yeah, if only that "someone" would continue developing that :p
23:50:53 <Cutter> has openttd been rewritten from scratch?
23:51:25 <SmatZ> RS-SM: I don't think there's something "modern" about it...
23:51:34 <Cutter> or is it based on Chris Sawyer's code?
23:51:47 <RS-SM> II'mt trying to say cutter
23:53:19 <Eddi|zuHause> Cutter: it was disassembled
23:53:29 <Eddi|zuHause> and then rewritten in C
23:54:34 <Nite_Owl> I thought it was C+ or did that come later
23:54:51 <Eddi|zuHause> that was done later
23:55:20 <Eddi|zuHause> large parts of the code are still C, which is just compiled as C++
23:58:22 <petern> should there be some universal game engine or somethiing? :o
23:58:52 <Aali> we should be using the crysis engine
23:59:11 <Aali> you'll need one modern computer per train, but thats fine
23:59:22 <Eddi|zuHause> PS: ohloh says it would take 40 person years (i.e. 4 years with a 10 person team) and 2.2 Mio $ to rewrite openttd from scratch
23:59:58 <Brokkoli> Chris Sawyer himself didn't need that time...
continue to next day ⏵
