IRC logs for #openttd on OFTC at 2010-04-30
⏴ go to previous day
01:11:18 *** rhaeder has joined #openttd
01:11:32 *** mynetdude has joined #openttd
01:11:50 <mynetdude> is there any way in the cfg or in console to override how long bridges can be?
01:12:12 <PeterT> set long_bridges on or off, I think
01:12:17 <mynetdude> can it be unlimited lengths?
01:12:31 <PeterT> If I recall correctly...
01:15:03 <Eddi|zuHause> depending on your value of "unlimited", i believe the limit is bigger than the size of a standard map ;)
01:15:58 <mynetdude> 100 tiles max on long bridges my map is 1024x768
01:16:12 <mynetdude> default is 16 tiles
01:16:24 <mynetdude> I want to create bridges over 400 tiles long
01:17:19 <mynetdude> no worries there are work arounds
01:18:26 <glx> you want to bridge over water?
01:19:57 <mynetdude> long ways over water
01:20:07 <mynetdude> well over land/water combo
01:20:26 <glx> you can still build small islands ;)
01:20:27 <mynetdude> trying to minimize track sloping as much as possible
01:20:50 <glx> when done correctly there are no slopes
01:21:44 <mynetdude> well the elevation has to be the same between two points
01:21:49 <mynetdude> in order ot not have slopes
01:22:23 <mynetdude> I created a "sort of" switchback in one of my maps, switchbacks have slopes which wasn't too bad
02:00:39 *** JVassie has joined #openttd
02:20:17 *** ChanServ sets mode: +v tokai
03:29:27 *** robotboy has joined #openttd
04:45:44 *** woldemar has joined #openttd
04:56:22 *** Eddi|zuHause has joined #openttd
05:30:23 *** Prof_Frink has joined #openttd
05:37:03 *** theholyduck has joined #openttd
06:33:11 <dih> who was the author (and what was the real title) of that 'building a language' talk?
06:34:20 <dih> i think it was a link Rubidium or TrueBrain posted
06:56:45 <dih> does anybody know of a way to find out which applications memory is actaully in swap?
07:01:49 <dih> and by which col would i tell it's using swap?
07:04:19 <Ammler> is the swap used by app?
07:05:44 <dih> we have a few servers and on 3 of them, nearly all ram is used, + a good 2GB of swap
07:06:02 <dih> and i'd like to find out what that is!
07:06:15 <Rubidium> first look at RSS (the real amount of used memory)
07:06:25 <Rubidium> but that doesn't tell anything about swap
07:06:50 <Rubidium> furthermore... how much memory is used for buffers/cache?
07:07:16 <planetmaker> dih: the state keyword to ps might help
07:07:54 <planetmaker> The state is given by a sequence of characters, for example, ``RWNA''. The first character indicates
07:07:55 <planetmaker> the run state of the process: (...)
07:07:57 <planetmaker> W The process is swapped out.
07:08:22 *** einKarl has joined #openttd
07:08:30 <dih> yesterday the amount of 'free' ram was below 40 MB
07:09:05 <Rubidium> so a little over 4 GB for applications and a little under 2 GB used for caches
07:09:52 <dih> thing that bugs me though, is that 2GB are in ram
07:10:06 <dih> and if i knew what that was, i might be a bit more ok with that
07:10:12 <dih> planetmaker: i'll give it a shot
07:10:45 <peter1138> total used free shared buffers cached
07:10:45 <peter1138> Mem: 4091844 4026512 65332 0 422880 3072176
07:10:45 <peter1138> -/+ buffers/cache: 531456 3560388
07:10:45 <peter1138> Swap: 3911672 816 3910856
07:11:14 <Rubidium> what is so bad about (unused) application data being moved to swap?
07:11:33 <peter1138> everything, when you don't understand why :)
07:11:56 <peter1138> clearly swap is the best place for it in dih's case
07:12:01 <dih> i cannot imagine it being 'unused' - i can rather imagine it being put there as there was no other option!
07:12:23 <peter1138> if it was in ram, then you wouldn't have anywhere near the buffers/cache size, and it would be slow
07:12:27 *** Alberth has joined #openttd
07:12:31 <dih> and my normal assumption would be, that caches are dropped before stuff is moved into swap
07:12:43 <peter1138> if it was used, again, it wouldn't be swapped out with that much buffers/cache available
07:14:21 <Rubidium> dih: wrong assumption then... it'll move pages that are idle to swap to make space for caches; it's faster to get those unused pages back from swap than to get an IO storm trying to read all the files you want to read
07:14:51 <dih> well, at least that is good to know
07:16:12 <dih> planetmaker: W paging (not valid since the 2.6.xx kernel)
07:16:56 <peter1138> you can show it with top
07:17:33 <peter1138> although it mayn't be accurate
07:17:44 <dih> i can show it in top? per application?
07:17:49 <peter1138> cos i have a process showing at 71MB in swap, but only 816KB of swap used :P
07:18:02 <peter1138> yeah, press f then toggle swap
07:18:28 <peter1138> it's just show virt - res
07:18:39 <peter1138> which isn't actually swap
07:19:02 <peter1138> it should work in your case though
07:19:57 <dih> it shows every httpd process with swap ^^
07:22:24 <peter1138> yeah, but that might still be lying
07:23:43 <dih> the sys aint got 400GB of swap :-D
07:24:11 <dih> 20 threads showing that amount of swap to each of them :-P
07:25:08 <dih> my collegue was hoping memcached was being swapped
07:25:20 <dih> and they configured it to use 2GB
07:25:42 *** KloBass has joined #openttd
07:27:54 <dih> that would mean arount 50% of RAM goes to memcache - 1GB used for caches ...
07:28:42 <peter1138> your paste shows that you have 2GB of buffers/caches
07:28:43 <dih> what is the average iowait on openttd.org?
07:28:49 <peter1138> so memcached isn't using 2GB RAM
07:29:31 <peter1138> PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ SWAP COMMAND
07:29:34 <peter1138> 17775 petern 20 0 149g 1984 304 R 99 0.1 0:10.42 149g h
07:29:42 <peter1138> yeah, 149GB swap ;)
07:30:01 <Rubidium> dih: absolutely no clue
07:30:13 <dih> none the less, thanks ;-)
07:30:22 <peter1138> just demonstrating how that swap field lies
07:30:44 <dih> top showed about 500m for memcached
07:30:53 <dih> and i guess that would be a lie too
07:31:15 <dih> but it was also showing 45% MEM being used for that process
07:31:16 <peter1138> have you decided it doesn't matter yet?
07:31:40 <peter1138> having memory for large buffers/cache is important
07:31:45 <peter1138> actual swap used, not important
07:31:49 <dih> it sucks, if you have to wait about 2 seconds on the live server for a uncached webpage
07:31:54 <dih> and less than 1 on the dev server
07:32:12 <peter1138> right, but that 2 seconds is nothing to do with your swap
07:32:12 <dih> i dislike the fact that we have over 10% iowait average
07:32:44 <dih> and over 50% on the db servers
07:33:01 <dih> db servers are quad core iirc
07:33:10 <dih> managed hosting - it sucks!
07:33:20 <dih> i hate it - why on earth did this company ever do that!
07:33:31 <peter1138> faster cpus == harddrives slower, relatively == %age higher
07:34:02 <Alberth> exactly my thoughts :)
07:34:10 <Rubidium> dih: oh, ...%wa? nearly 0 at the moment
07:34:29 <dih> the dev server is a vm :-P
07:34:49 <peter1138> "managed" hosting doesn't say anything about what the hardware is
07:34:58 <peter1138> could be an old IDE drive ;p
07:35:15 <dih> peter1138: it says that i cannot manage it myself
07:35:36 <dih> every config change i want, i need to request in a ticket :-S
07:35:49 <peter1138> that's so they know what's going on
07:36:02 <dih> they are so abso-fucking-stupid
07:36:09 <peter1138> you can't have two sets of admins managing things with different ideas on how to do so
07:36:59 <dih> you would not believe what a pain it is, to ask them to do something!
07:37:12 <Rubidium> dih: now it's roughtly 20% with a peak at 50%... guess what I did
07:38:22 <Rubidium> nah, just started a compile farm run... 3 VMs starting an OS simultaniously
07:38:22 <dih> tell me, Rubidium, what did you do?
07:38:37 <Rubidium> now they're all compiling it's back at <1%
07:39:11 <Rubidium> still ~20% idle (yay for using only 3 cores for the CF)
07:40:08 <Rubidium> for some odd reason the load jumped up a little over 3 "points" too (from ~0.15)
07:40:34 <dih> munin shows some interesting stats ^^
07:48:37 <Alberth> wild guess: pages being swapped in or out?
07:51:16 <Alberth> You should read a book that explains the design and implementation of the kernel
07:51:59 <Alberth> Don't know whether it exists for a Linux kernel. I know for a fact that it exists for the BSD kernel.
07:52:53 <dih> i am just not used to haveing stuff in swap ^^
07:57:36 *** Progman has joined #openttd
08:01:44 <DorpsGek> dih: Yexo was last seen in #openttd 6 days, 15 hours, 47 minutes, and 47 seconds ago: <Yexo> the self scope of the object you clicked on
08:13:29 *** robotboy has joined #openttd
08:16:04 <Rubidium> it's morning already?
08:19:43 *** Cybertinus has joined #openttd
08:26:28 <Terkhen> good question... I feel as tired as I was when I went to sleep
09:07:36 *** HerzogDeXtEr1 has joined #openttd
09:13:33 *** r0b0tb0y has joined #openttd
09:30:38 *** HerzogDeXtEr has joined #openttd
10:13:38 *** robotboy has joined #openttd
10:32:00 *** theholyduck has joined #openttd
10:35:20 *** KenjiE20 has joined #openttd
10:53:19 *** robotboy has joined #openttd
10:54:34 *** George is now known as Guest1836
11:19:30 *** Chruker has joined #openttd
11:52:59 *** r0b0tb0y has joined #openttd
11:54:09 <dune> do anyone know a place to download a copypaste-patch that doesent need to be compiled and works with openttd 1.0 (im a lazy windows user) :p
11:55:18 <planetmaker> to my knowledge such place does not exist
11:57:41 <dune> i guess i jaut have to try compiling then.. :s
11:59:06 <peter1138> it's a patch to the source code, it needs to be compiled...
11:59:11 <peter1138> or you find a binary
12:02:05 <dune> i guess i just wait for a binary.
12:02:45 <planetmaker> for a non-supported patch that'll be quite long, I assume
12:04:04 <dune> bah :p thx for beeing so optimistic ^^
12:05:26 <dune> downloading TortoiseSVN then..
12:05:57 <berndj> is there a nice place where building openttd is documented? i tried once but got stuck when it wanted all sorts of weird tools like "renum" (but apparently NOT the "renum" you get from apt-get install renum)
12:07:14 *** Devroush has joined #openttd
12:10:20 <planetmaker> berndj, (nfo)renum is not required for OpenTTD
12:10:31 <planetmaker> it's a tool to build (new)grf
12:11:40 <planetmaker> that's the requirements listed
12:11:49 <planetmaker> a compiler should ship with your linux by default
12:12:02 <Ammler> there is no other renum than nforenum, afaik
12:14:26 <berndj> planetmaker, i think it was while i was trying to build opengfx
12:14:43 <planetmaker> berndj, yes, it's a requirement for OpenGFX, sure
12:14:53 <planetmaker> that's a bundle of grfs.
12:35:02 *** JostVice has joined #openttd
12:55:05 *** Progman has joined #openttd
13:04:32 *** r0b0tb0y has joined #openttd
13:06:26 <Jupix> do the wood & steel wagons share the same cc mask?
13:06:57 <planetmaker> they are different sprites
13:07:50 *** fonsinchen has joined #openttd
13:28:27 *** FauxFaux_ has joined #openttd
13:29:57 *** Belugas has joined #openttd
13:29:57 *** ChanServ sets mode: +o Belugas
14:04:17 *** RDL1 is now known as Jolteon
14:04:36 *** robotboy has joined #openttd
15:04:44 *** r0b0tb0y has joined #openttd
15:36:59 *** michi_cc has joined #openttd
15:36:59 *** ChanServ sets mode: +v michi_cc
15:49:47 *** Grelouk has joined #openttd
15:49:57 *** Devroush has joined #openttd
15:56:04 *** |Jeroen| has joined #openttd
16:04:49 *** robotboy has joined #openttd
16:07:42 <Eddi|zuHause> ... hm, apparently tomorrow is a big star trek marathon...
16:08:02 <Eddi|zuHause> like 15 TOS episodes and 3 movies...
16:08:48 *** Keyboard_Warrior has joined #openttd
16:10:20 *** Coco-Banana-Man has joined #openttd
16:14:04 <tokai> Eddi|zuHause: Are people really that bored to watch that?
16:14:46 <Eddi|zuHause> i have no idea... just noticed this while skimming the EPG
16:15:28 <Eddi|zuHause> plus, everybody outside the target group of star trek is drunk and fighting with the police anyway :p
16:17:53 <Eddi|zuHause> court in berlin rules that throwing an empty beer bottle or a stone at the police is not an assault with a weapon
16:25:35 <tokai> Eddi|zuHause: Sounds almost like an invitation to do so. :)
16:25:57 <Alberth> tomorrow is your chance :)
16:26:51 <Alberth> assuming you are not bored enough to watch ST tomorrow :p
16:32:11 *** last_evolution has joined #openttd
16:42:22 *** last_evolution has quit IRC
16:50:47 *** michi_cc has joined #openttd
16:50:47 *** ChanServ sets mode: +v michi_cc
16:54:27 *** Wizzleby has joined #openttd
17:05:04 *** Keyboard_Warrior is now known as theholyduck
17:18:01 *** theholyduck has joined #openttd
17:23:49 *** andythenorth has joined #openttd
17:44:04 *** Progman has joined #openttd
17:45:47 <CIA-6> OpenTTD: translators * r19740 /trunk/src/lang/ (5 files in 2 dirs):
17:45:47 <CIA-6> OpenTTD: -Update from WebTranslator v3.0:
17:45:47 <CIA-6> OpenTTD: traditional_chinese - 16 changes by josesun
17:45:47 <CIA-6> OpenTTD: hungarian - 26 changes by IPG
17:45:47 <CIA-6> OpenTTD: indonesian - 18 changes by prof
17:45:49 <CIA-6> OpenTTD: irish - 640 changes by tem
17:45:49 <CIA-6> OpenTTD: luxembourgish - 1 changes by Phreeze
17:52:38 *** frosch123 has joined #openttd
17:54:28 *** theholyduck has joined #openttd
17:58:33 * andythenorth wonders about patching stations so they act like depots
17:59:14 <andythenorth> not so much for train building, but for servicing, and above all, refitting
17:59:22 <andythenorth> train / vehicles /s
18:00:29 <Alberth> it would get done instantly? then it seems a lot of work for little gain imho.
18:01:08 <andythenorth> might add a whole new dimension to routing though
18:01:29 <andythenorth> go to A, unload, refit, go to B, run empty to C, refit again etc
18:02:20 <Alberth> oh, it is a station as well. yes, that would make a difference.
18:02:41 <Alberth> although I wonder how many people do refitting in their orders
18:02:48 <andythenorth> I find it a bit weird that refitting by orders is possible but nobody bothers
18:03:09 <andythenorth> I think it's because (a) it costs too much in some newgrfs (b) it's a hassle routing to depots
18:05:10 <Alberth> I cannot even come up with a useful example to have more than one cargo at the same network get combined in that way.
18:06:07 <Rubidium> Alberth: steel+town station <-> factory station
18:06:55 <andythenorth> it's standard routing behaviour in railroad tycoon
18:06:59 <Alberth> what about the cargo ratios?
18:07:28 <Rubidium> less steel per wagon than goods, so if you don't full load at the factory it'd work quite well
18:07:34 <frosch123> you cannot properly use "full load" ad the steel station
18:07:57 <frosch123> so unless you have really lot of production, the rating dropps to much
18:08:08 <andythenorth> aslo there would be a problem getting the load if the industry processes instantly
18:08:13 <Alberth> nor at factories that don't do instant production
18:09:20 <andythenorth> well it would be more realistic :P
18:09:55 <Alberth> in reality, somebody from the factory gives you a call "today we have no more cargo for you" :)
18:10:20 <andythenorth> setting % load amounts would be useful?
18:10:49 <Alberth> that only reduces the problem, it does not eliminate it, I think
18:11:23 <Alberth> ie I have to make a good estimate of the percentage
18:11:55 <Alberth> we would need something like 'no cargo for x ticks' -> leave.
18:12:13 <andythenorth> perhaps 'stations are like depots' is a bad idea :)
18:12:22 <andythenorth> but % cargo loaded might not be
18:12:38 <Alberth> perhaps refit orders is a bad idea :)
18:12:59 <andythenorth> seems a bit silly to be running empty ships around the place
18:13:28 <andythenorth> and same for freight aircraft
18:13:57 <Alberth> can we make a container?
18:14:08 <andythenorth> Eddi|zuHause suggested it
18:14:11 *** Devroush has joined #openttd
18:14:34 <andythenorth> I can't even begin to see how it would work :o
18:15:04 <Alberth> a factory that takes a cargo and produces a container, and a factory^(-1) would be one option.
18:15:39 <Alberth> more advanced is to literally store cargo in the container in the sense that you still know what went in when unpacking.
18:17:51 <andythenorth> so vehicles could handle multiple cargos inside 'containers'
18:18:27 <andythenorth> and containers wouldn't have to be 20' or 40' TEU steel containers? They could just be a 'box' with certain class and capacity?
18:18:49 <Alberth> well, container is a well-known standardized transport medium for ships and aircraft (though the containers are different :p )
18:19:20 <Alberth> if you generalize the idea, probably yes.
18:19:23 <andythenorth> I am trying to understand if this works pre 1950s :) e.g. with wooden crates
18:19:52 <Alberth> I didn't claim it would work for '50s vehicles too ;)
18:20:46 <Alberth> all packet delivery companies basically do the same, except the containers have no uniform size.
18:23:20 <andythenorth> Is it technically possible?
18:23:29 <andythenorth> I kind of like the idea
18:26:11 <frosch123> to cite a common suggestion: allow building warehouses at the station which keep the rating up as long as they are not filled
18:28:54 *** [com]buster has joined #openttd
18:30:13 <Alberth> 'have a warehouse, but don't use it' :p
18:30:33 *** ajmiles has joined #openttd
18:31:23 <Alberth> whether it is technically possible, I don't know. Probably not atm, or you must be able to do it in newgrf entirely.
18:32:52 <Alberth> if you start shuffling here, it may be better to make a bigger step, and remove the '1 cargo only' limitation.
18:33:01 <Alberth> but that is also just a wild suggestion :p
18:33:42 <andythenorth> I liked the 'refit at stations' idea because (unlike many ideas) it is about transportation and logistics
18:33:59 <andythenorth> back loads and efficient routing are important for transport companies
18:33:59 <frosch123> i guess cb 145 could be extended, if it were stationpart specific or so...
18:34:10 <frosch123> what do you mean with '1 cargo only'?
18:34:50 *** Rhamphoryncus has joined #openttd
18:35:17 <frosch123> andythenorth: why does it make a big difference for you to send the train to a depot between unload and load?
18:35:21 <Alberth> there is not a '1 cargo only' limit for vehicles?
18:35:59 <frosch123> not for trains, and not for articulated road vehicles
18:36:16 <frosch123> but they are hard to handle as you cannot refit individual parts
18:36:42 <Alberth> in newgrf, or is it a gui problem?
18:37:41 <frosch123> at gui mostly, though newgrf likely rely on being refitted the homogeneous
18:38:38 <frosch123> e.g. vehicle might look different for different cargos, which will look very wrong if the parts are directly connected
18:39:39 <frosch123> however for trains you can detach wagons, refit them at some other engine, and reattach them (though grfs might refuse that). but not for orders :)
18:40:33 <frosch123> (though you can likely revert the refitting if the newgrf rejects reattaching
18:40:49 * Alberth envisions a depot/station where the train gets split and coupled again
18:41:53 *** last_evolution has joined #openttd
18:42:37 * Rubidium wonders whether Alberth ever read the suggestions forum/feature requests on the tracker
18:44:42 <Alberth> those texts mention 'realism', and start at the point where I am wondering about feasibility
18:45:04 <frosch123> Alberth: if you can envision a gui for refitting some wagons only manually in depot and per order :)
18:45:43 <andythenorth> frosch123: maybe I should try playing a game using 'refit in depot' again. I dunno, it just seems annoying though
18:46:00 <frosch123> to refit articulated parts differently we would likely need some vehicle flag allowing that
18:47:15 <frosch123> hmm, otoh, maybe andy, maybe the vehicle refuses to stop a second time at the same station
18:55:21 *** Polygon has joined #openttd
19:22:17 <TrueBrain> why do OpenTTD people want to invite me on their facebook?
19:23:29 <ccfreak2k> Because you are a true brain?
19:23:51 <PeterT> are you looking for a serious answer?
19:27:10 <Alberth> you are their last hope :p
19:28:57 <Alberth> oh sorry, that was LinkedIn :)
19:29:30 <frosch123> are you talking about that old stupid mail, or is someone trying it again?
19:29:45 <TrueBrain> LinkedIn is on my ignore list
19:29:51 <TrueBrain> but the facebook one was new
19:31:47 <frosch123> hmm, maybe i should ignore the forward from openttd. iirc i never received a serious one.
19:32:28 <TrueBrain> I have 2 to 3 mails a week which require my attention
19:33:10 <frosch123> poor you :) i only get scam and those stupid "why are you not in my social network"-stuff :(
19:33:56 <TrueBrain> we should trace those people and punish them
19:35:37 <Alberth> The 'others' row in the financial overview window seems like a good candidate
19:36:57 <Alberth> sure, 50% other costs as a first warning
19:37:16 <Alberth> (of your bank balance at max loan)
19:40:31 *** Born_Acorn has joined #openttd
19:52:01 *** fonsinchen has joined #openttd
20:01:31 <Turgid> What do the colored dots next to each vehicle mean, in the vehicle list?
20:02:10 <Turgid> What's the difference between a grey dot and a green dot?
20:02:29 <Turgid> I mean obviously green is more, but what's the cutoff?
20:02:39 <frosch123> grey means the engine is not old enough to be considered for profit calcuation
20:09:52 <andythenorth> so would 'containers' be a cargo? (some kind of containing the actual cargo?)
20:10:06 <andythenorth> or would it be a magic refit to the actual cargo?
20:10:30 <andythenorth> oops 'some kind of *wrapper* containing the actual cargo'
20:11:32 <andythenorth> the idea Alberth was pondering
20:12:04 * andythenorth can't visualise how it works in gameplay
20:12:35 <Alberth> (08:16:13 PM) Alberth: can we make a container? <-- I just asked a question :)
20:12:52 <andythenorth> ah, but what is a container?
20:13:06 <andythenorth> or....how do players use a container?
20:13:29 <andythenorth> some industries produce goods pre-packaged in 'containers'? Seems a bit sucky
20:14:00 <Alberth> I bet many industries in China do that
20:14:39 <andythenorth> if we have the concept of a generic container, it seems silly to exclude cargos like chemicals
20:14:48 <Alberth> for eg ships it makes sense to have them as a cargo
20:14:58 * frosch123 can think of three solutions, one more useless than the other :) 1. draw containers on the vehicle and refit to whatever you want. 2. add container-compatible cargo class to restrict refitting. 3. add container cargo and let the player make sure that containers from food plant are not transported to the vehicle factory
20:15:04 <andythenorth> a special station tile that 'containerises' cargos?
20:15:06 * theholyduck was reading with 1 eye half open
20:15:10 <theholyduck> and thought you were talking about video formats
20:15:30 <Alberth> at OpenTTD, with andythenorth ?
20:15:40 <theholyduck> Alberth, well i hang in like 8 multimedia channels
20:15:41 <andythenorth> frosch123: I think this might be more the concept of generic containers than ISO containers (steel boxes)?
20:15:45 <theholyduck> i forgot what channel i was looking at
20:15:52 <theholyduck> and when people start spouting the word container and player
20:15:59 <theholyduck> i think multimedia
20:16:16 <andythenorth> I can draw containers & figure out generic refitting, but I am thinking of something that works for box cars, gondolas, delivery vans etc
20:16:45 <andythenorth> the point is to allow mixed cargos on vehicles that don't currently allow that
20:17:03 <Alberth> the question seems to be where does packing/unpacking take place?
20:17:10 <frosch123> so, basically ships, right?
20:18:39 <andythenorth> I would like to be able to run general merchandise trains back and forth between cities
20:18:49 <Alberth> for some cases, you want to do it at a station/dock
20:18:59 <andythenorth> but this idea could produce a huge problem for actually routing the cargo
20:19:20 <Alberth> but if you want to transport the containers as-is, that should also be an option without explicit visit to some factory
20:19:36 <andythenorth> special station tile...
20:20:04 <Alberth> it is a form of 'station facilities'
20:20:11 <frosch123> hmm. actually you could turn the cargotype of a vehicle into a bitmask to accept multiple cargos, and store the actualy cargotype in the cargopacket
20:20:44 <andythenorth> so I have 'containers' of chemicals waiting at location A. Train arrives with empty wagons for 'containers', next destination is B. But B doesn't accept chemicals, I want to route those to C.
20:20:46 <andythenorth> this is a problem
20:21:00 <frosch123> so you could refit a boxcar to carry 30 crates of food, goods or other stuff in any ratio
20:21:38 <frosch123> or you could refit a ship to carry any cargo with "container-compatible"-cargoclass in any ratio at the same time
20:21:54 <andythenorth> I think it's worthwhile, but the routing problem troubles me
20:22:02 <Alberth> the simpler case of transporting a container from a dock to a city, and have it there unfold to 'goods' or so is already a problem
20:22:15 <Alberth> ie and not unfold at the dock
20:22:42 <andythenorth> so this has multiple problems :)
20:22:49 <andythenorth> well maybe it's an interesting problem
20:22:56 <frosch123> so you would need to specify in the orders which cargotypes to load/unload
20:23:06 <andythenorth> or have cargo dist routing packets
20:23:21 <Alberth> what if we always pack/unpack at stations? we can simply repack to a container if needed.
20:23:43 <frosch123> Alberth: but it would always reload all types
20:23:59 <andythenorth> it's the same problem as has existed for years with transfers
20:24:22 * andythenorth just loves building two stations for passenger transfer systems (one drop, one pickup)
20:24:28 <frosch123> but as i understand andy he wants to collect food and goods at A, drive to B, unload food, drive to C, and unload goods there
20:24:48 <andythenorth> frosch123: not specifically
20:25:04 <Alberth> you'd need a bitset of allowed cargoes in a container
20:25:08 <andythenorth> go to A, load steel, go to B, unload steel, go to C load scrap metal, go to A would do me
20:26:32 <Alberth> always automatic unpacking at stations prevent problems where you need to know where the container is going to at the moment you create it
20:27:16 <Alberth> (ie I cannot combine steel and goods, because at the other end, it gets loaded to different destinations)
20:27:48 <andythenorth> seems to me that 'containers' are just vehicles that refit to whatever is waiting?
20:28:00 <andythenorth> (limited by their refit classes etc)
20:28:30 <Alberth> in a sense, except they accept all possible size combinations.
20:28:42 <frosch123> andythenorth: i guess rather load different types of cargo in the same vehicle
20:29:07 <andythenorth> for the ship/plane case different types is way better
20:29:20 <andythenorth> for the truck / boxcar case, 'magic' refit is ok
20:29:22 <frosch123> hmm, the ratio could be limited by the "load amount"
20:30:27 <andythenorth> so the orders would specify possible refits & ratios?
20:30:45 <frosch123> i guess extending the vehicle variables and cargopackets would be no problem. but maybe extending the (packet) order struct and the gui :s
20:31:30 <frosch123> andythenorth: maybe the order could say "load any of a, b and c" resp. "unload all of a, b and c"
20:32:11 <frosch123> though you get into trouble if you want to unload cargo a, transfer cargo b, unload c only when accepted, and keep d :p
20:32:45 <andythenorth> otherwise a good idea though frosch123
20:32:53 <andythenorth> I can think of real cases for it
20:33:22 <andythenorth> it might make timetabling interesting for general freight trains / ships
20:34:17 <andythenorth> picking up farm cargos. Delivering food and goods to towns
20:34:21 <frosch123> well, you could also send such a train to a industry, unload it, and let it wait timetabled to load the produced cargo or so...
20:35:12 <andythenorth> run food from one town, pickup goods, run them back
20:35:23 <Alberth> what if we have several load/unload orders underneath each other at the same station and we do them all together?
20:35:53 <frosch123> but well, i guess you need to restrict it to only some cargos. it might be too easy if you can transport any cargo in universal wagons
20:36:05 <Alberth> I was thinking that too
20:36:07 <andythenorth> has to be by class at minimum
20:36:24 <frosch123> Alberth: sounds fine, you could also put conditional orders inbetween them
20:36:37 <frosch123> but you would still need to add a cargo type
20:38:14 * andythenorth feels like he needs a diagram :P we've discussed quite a few ideas above
20:43:16 *** michi_cc has joined #openttd
20:43:16 *** ChanServ sets mode: +v michi_cc
21:01:36 <CIA-6> OpenTTD: rubidium * r19741 /branches/1.0/ (14 files in 7 dirs):
21:01:36 <CIA-6> OpenTTD: [1.0] -Backport from trunk:
21:01:36 <CIA-6> OpenTTD: - Fix: Crash when using restart via rcon (r19722)
21:01:36 <CIA-6> OpenTTD: - Fix: Leaking a file descriptor [FS#3785] (r19695)
21:01:36 <CIA-6> OpenTTD: - Fix: Crash when the music/graphics metadata files were unreadable [FS#3774] (r19674)
21:08:17 <Eddi|zuHause> release in an hour?
21:14:18 <Alberth> KouDy: do you get paid to lose connection and spam the channel with a commercial?
21:14:51 <Rubidium> Alberth: no, hydrairc is just an extremely annoying IRC client
21:15:31 <Alberth> ah, they build it into the software. How clever
21:24:55 <CIA-6> OpenTTD: rubidium * r19742 /tags/1.0.1/ (9 files in 4 dirs): -Release: 1.0.1
21:25:57 <Rubidium> ~40-45 minutes till binaries
21:28:24 <dih> those smell good too when put in the oven :-P
21:28:55 <TrueBrain> I wonder what would happen if I turn up the heat of these ovens
21:28:58 <TrueBrain> would they burn the binaries?
21:29:26 <TrueBrain> sounds like a new release method :)
21:29:33 <Alberth> nah, you just get garbled bits, and fried cpus :)
21:29:56 <TrueBrain> the latter is what worries me :p
21:30:01 <Eddi|zuHause> Spoilin' nice fish. Give it to us raw and w-r-r-riggling
21:32:16 <Alberth> Eddi|zuHause: that's available by cloning
21:33:58 *** theholyduck has joined #openttd
21:44:30 *** Progman has joined #openttd
21:47:05 *** Nite_Owl has joined #openttd
22:12:44 *** Coco-Banana-Man has quit IRC
22:20:47 <Rubidium> Wizzleby: not sure how much you care about the Gentoo package, but I've got the feeling bug#317911 is caused by Gentoo importing a broken libsdl patch from Debian
22:26:19 * frosch123 masked media-libs/libsdl 1.2.14-r2
22:26:46 <frosch123> and yes, r1 and r2 differ exactly in that debian patch
22:27:28 <Wizzleby> hmm. well I can't fix that myself, but I can make sure the bug goes to the right people who can
22:29:36 *** Brianetta has joined #openttd
22:33:52 <Wizzleby> wrt the openttd gentoo package, I sort of picked it up when 1.0.0 was in beta. games herd was not interested in it till it hit releae, but people wanted it. Not being a dev myself, I took it upon myself to maintain it in an overlay. The main ebuild for openttd needed (and still does) some work though
22:35:19 <Rubidium> TrueBrain: I hope the server can take two releases on a day :)
22:37:18 <Wizzleby> mostly stuff that I need to ask you folks about: like iconv, whether it is needed or not under linux. The configure script skips checking for it on a linux host, but can be overridden (which the previous maintainer decided to allow for with an iconv USE flag). Some users have had bugs with this setup and certain versions of glibc, where iconv pops up errors to stderr about being unable to read convert some character or another
22:37:18 <Wizzleby> in some file that happened to be in the dir where they ran openttd
22:38:36 <Rubidium> gentoo is the origin of the configure part that actually allows iconv to be selected for linux
22:39:15 <Rubidium> I am not aware of ANY other linux distribution ever even asking about iconv
22:39:50 <glx> why use iconv when you can use utf-8 natively ;)
22:40:07 <Wizzleby> huh. Kind of ironic that I'm here now then, asking what point it could possibly have
22:41:24 * Wizzleby only started with gentoo within the past year, so, really knows nothing about what whoever was the maintainer for openttd was thinking
22:41:49 <Rubidium> neither do I know what they are/were thinking
22:41:53 <Wizzleby> glx: that's what I was wondering about it
22:42:17 <Rubidium> but I seem to remember something about non-ascii/non-utf8 filenames
22:45:15 <Wizzleby> Rubidium: it does not appear to have an explicit maintainer these days. not many folks in the games herd, though I did find the bug where the patch was added, initially in the portage tree, and I recognize the guy and can ask him
22:45:31 <Wizzleby> s:the guy:the guy who attached the patch to the bug:
22:50:02 <Wizzleby> it seems that the original maintainers for openttd retired as gentoo devs around 2008
22:51:57 <Rubidium> anyhow, my amount of trust in the Gentoo games/security maintainer is *very* low
22:56:30 *** GEORGE_W_BUSH has joined #openttd
22:56:53 <GEORGE_W_BUSH> anyone want to play lol
22:56:59 <Wizzleby> Rubidium: wrt the games herd, its only 4 people large these days, and with a high load of packages, many of them very troublesome to maintain. As far as herds go, I think it needs some love, and work. I can't speak wrt the QA/security team as I am not yet familiar with many of them
22:59:54 <Rubidium> Wizzleby: security... they make CVE entries for unexploitable bugs yet fail to see the real exploits, they kinda fail to adequately handle exploits (0.7.5 is after 4.5 months STILL not marked stable leaving a known network exploitable OpenTTD) and they manage to make incorrect CVE entries (telling it's fixed in some version when it clearly isn't)
23:01:50 <Rubidium> Debian, that doesn't have security support, has released a fixed/patched version to their stable version (though via a point release which meant waiting for a month)
23:02:20 <Rubidium> (it doesn't have security support for OpenTTD as it was in non-free at that time)
23:03:37 <Rubidium> Fedora pushed a new version within reasonable time to their stable releases
23:03:40 <Wizzleby> Rubidium: I can acknowledge those as issues (ones I would consider serious too). Best I can give you as a response is that as I complete the process of becoming a dev myself (and with an eventual goal of getting into the applicable teams for security and QA) that I'll do my best to address those shortcomings
23:03:50 <Wizzleby> For whatever that's worth
23:04:15 <theholyduck> Rubidium, my trust in gentoo maintainers
23:04:29 <Wizzleby> I can also try and poke people in the immediate future about getting 0.7.3 masked for removal
23:04:42 <theholyduck> a good 40% of all the package problems i encounter in my days of linux support
23:04:44 <theholyduck> are gentoo related
23:04:50 <theholyduck> with most of the rest being ubuntu and its bastard children
23:05:21 <Rubidium> Wizzleby: FYI, 1.0.1 has a bunch of security fixes too
23:06:06 <Rubidium> theholyduck: ghehe... Ubuntu... with pulseaudio and also poor security support (I even fracking made a patch for each of their versions; never going to do that again)
23:06:09 <theholyduck> gentoo is infact the only distro i know that refuses to remove a package because its unmaintained
23:06:30 <theholyduck> they have given the reason
23:06:38 <theholyduck> "we wont remove this package because nobody maintains i"
23:07:05 <theholyduck> stuff like that make me want to stab in the night
23:07:20 <Wizzleby> Rubidium: I'm preparing 1.0.1 in overlay currently, will see about filing an expedited security stable bug wrt it
23:07:27 <theholyduck> Rubidium, well the 1 principle advantage of ubuntu, is that while they have alot of package issues
23:07:29 <Sacro> Rubidium: arch-nullsfk has gone
23:07:33 <theholyduck> i can point an ubuntu user at a forum post
23:07:37 <theholyduck> and 9 times out of 10
23:07:43 <theholyduck> they can copy paste the instructions to fix the problem
23:07:55 <theholyduck> trying to talk a gentoo user through compiling packages by hand to fix their broken distro ones
23:08:25 <theholyduck> is like trying to do dancing on stilts with rollerblades on the end
23:08:33 <Wizzleby> theholyduck: for a long time, there was no team in gentoo whose focus was to remove dead packages. There is now though
23:08:38 <theholyduck> its all going to end in tears and broken pelvis
23:10:03 <theholyduck> Wizzleby, the worst thing about gentoo problems though, are the users that come to you for help.
23:10:33 <theholyduck> heck, the rise in populairty of gentoo is why i stopped general linux support and dedicated myself to multimedia
23:11:44 * theholyduck shakes his fists at gentoo
23:11:58 <Wizzleby> theholyduck: I must be lucky, so far the support I've done with it hasn't been among my worst tech support experiences
23:12:20 <theholyduck> Wizzleby, also, you occationally see the completely nonsescial
23:12:24 <theholyduck> a couple of years back
23:12:39 <theholyduck> i was trying to figure out why this guys mplayer wasnt showing .ass subtitles
23:13:00 <theholyduck> and after hours of poking around, it turns out that back then, to enable libass in mplayer
23:13:04 <Rubidium> because he didn't have the ARSE useflag
23:13:08 <theholyduck> you hadd to USE = SRT
23:13:17 <theholyduck> wich makes marginal sense at best
23:13:32 <theholyduck> they fixed that relativly recently though
23:14:07 <theholyduck> but still, mislabeled useflags like that, or mandatory deps marked as optional
23:14:44 <peter1138> fuck the mother fucker!
23:15:20 <peter1138> sorry, just watched tim minchin's pope song
23:15:28 *** ChanServ sets mode: +v glx_
23:15:39 <Wizzleby> well, for my purposes I enjoy it too much to discard it, and so would rather actually help fix the issues.
23:16:01 <Rubidium> peter1138: wouldn't that be "fuck the altar boy fucker"?
23:16:17 <theholyduck> i'd rather they ditched it and invented/implemented a from source packagemanager that worked consitently
23:16:26 <peter1138> not the pope himself, heh
23:16:30 <theholyduck> then only let people who proven they understand the concept of maintaining packages
23:16:53 <theholyduck> also, dont provide step by step instalation instructions
23:17:10 <theholyduck> that way you can loose all those tiresom former ubuntu users talking about how much amazing they learned from gentoo
23:17:12 *** glx is now known as Guest1926
23:17:19 <theholyduck> and "BUILDING YOUR SYSTAM FROM SCRATCH!
23:17:34 <theholyduck> now that is a distro i'd approve of
23:17:58 <Rubidium> got bored around libc
23:18:09 <theholyduck> Rubidium, well, the most tiring gentoo user are the ones talking about how amazing gentoo is that lets you install by hand, etc,etc
23:18:14 <theholyduck> and all the other things every distro lets you
23:19:14 <theholyduck> actually, i should write a debian sid installer system and guide for the "l33t h4cker" who wants a completely optimized, built from scratch system they configured by hand themself, more gentoo buzzwords here.
23:19:29 <theholyduck> just to prove a point
23:19:45 <Wizzleby> I did LFS before, it was.. tedious, but a fun experience
23:20:35 <theholyduck> the one thing i actually genuinly should do
23:20:37 <Wizzleby> theholyduck: the funny thing about points, is that even if you prove them, it is no guaruntee others 'get' the point ;)
23:20:57 <theholyduck> is finish up my debian/ubuntu package manager addon
23:21:25 <Rubidium> theholyduck: does that support adding patches to the kernel package? As doing that is kinda non-trivial
23:21:25 <theholyduck> a couple of years back i wrote a basic compile from source packagemanager in bash to integrate with apt
23:21:48 <theholyduck> mostly for making automated mplayer/ffmpeg builds
23:22:14 <theholyduck> i should finish that up, and release it as apt-duck or something
23:22:37 <theholyduck> becuase unlike almost every other script i write, it was actually useful and usable
23:22:58 <Rubidium> peter1138: sounds like a song to run on the airport at the moment an American delegation and the pope arrive
23:24:29 <theholyduck> essentially, it was portage but instead of the tedious useflags, it used a ncurses based system walking you through major and minor configure options
23:25:50 <fjb> Sounds a bit like FreeBSD's ports system.
23:26:03 <theholyduck> fjb, well techincally i essentially ripped it off lunar linux
23:26:27 <OwenS> Isn't there a prebuilt dpkg tool for building sdebs into debs?
23:26:43 <theholyduck> OwenS, well the point wasnt using sdebs :P
23:26:50 <Rubidium> yeah, but that doesn't configure your packages
23:26:54 <theholyduck> but svn's, gits, up to date snapshots
23:27:05 <theholyduck> or experimental features
23:27:17 <theholyduck> for mplayer i offered mplayer svn, mplayer uau, git
23:27:21 <theholyduck> both with and without ffmpeg-mt
23:27:32 <theholyduck> *mplayer from uau's git
23:27:46 <theholyduck> ffmpeg had latest stable or latest svn
23:28:29 <theholyduck> essentially, letting you pick the exact version and type of package you wanted for what
23:29:05 <theholyduck> simelarly the system could have been extended to say, specifying svn revisions of a package you want
23:29:09 <theholyduck> if you wanted a specific revision
23:30:14 <theholyduck> the real beauty of it though, is that it was still a debian sid system for all the underlying packages, and the compile time stuff was essentially for special software with special needs
23:31:11 <OwenS> I wonder... are Debian/Ubuntu shipping mplayer with vdpau support these days?
23:33:54 <OwenS> Haha... A bug in the Kubuntu distribution upgrade app: It appends text where the cursor is
23:34:01 <theholyduck> due to a mplayer hackaround
23:34:16 <Rubidium> OwenS: I remember seeing that while starting some video
23:34:17 <theholyduck> ubuntu refuses to upgrade mplayer
23:34:20 <theholyduck> because mplayer doesnt do releases
23:34:35 <theholyduck> the mplayer devs convinced some debian devs
23:34:39 <theholyduck> of taking a svn snapshot
23:34:43 <theholyduck> and calling it mplayer 1.0 rc3
23:34:48 <theholyduck> its not ACTUALLY a release,
23:34:50 <Rubidium> not doing releases is (IMO) stupid
23:35:09 <Rubidium> I was wondering what vpdau actually was
23:35:11 <theholyduck> next ubuntu release rolls around
23:35:18 <theholyduck> and ubuntu imports the debian svn snapshot
23:35:24 <theholyduck> and gets vdpau, etc,etc
23:35:28 <OwenS> Rubidium: Video Display and Presentation API for Unix :)
23:35:33 <theholyduck> then intrestingly,
23:35:44 <theholyduck> labels their svn releases
23:35:56 <OwenS> nVIDIA's standard for video decode. Also supported by S3. ATi invented their own XVBA. Intel has VAAPI. Its a mess
23:35:57 <theholyduck> but the only existing mplayer release is still rc2 :P
23:36:17 <theholyduck> OwenS, well vaapi is supposed to be able to do both xvba and vdpau
23:36:29 <theholyduck> as in, be a wrapper
23:36:39 <theholyduck> mplayer has almost no devs
23:36:40 <OwenS> theholyduck: sure. But note there are no native working VAAPI drivers XD
23:36:43 <theholyduck> and the few devs it does have
23:36:47 <theholyduck> are all busy writing code
23:36:51 <theholyduck> fixing stuff, adding new features
23:37:00 <theholyduck> theres nobody who feels like doing feature freezes
23:37:04 <theholyduck> bugfixes on olde releases, etc
23:37:09 <theholyduck> theres no manpower for it
23:37:44 <theholyduck> essentially, they dont do releases because they're so few people, that produce quite alot of new code
23:37:54 <theholyduck> that theres no manpower to try and make releases
23:38:03 <theholyduck> its a purely practical decission
23:38:28 <theholyduck> mplayer svn is still generally quite stable
23:38:44 <theholyduck> so theres no real reason not to just compile from it
23:40:08 <theholyduck> ffmpeg effectivly does no releases either
23:40:15 <theholyduck> they've done one in the last. what..
23:40:23 <theholyduck> well a bit less maybe
23:40:41 <__ln___> someone's having a monologue here it seems....
23:41:36 <Rubidium> so if you can't be bothered to make a release branch, just tag some relatively stable svn version on a bi-monthly basis
23:42:28 <Rubidium> as the current method of "releasing" means that people who do not intimately know how stable it roughly is will randomly pick something and give that to users
23:42:42 <Rubidium> or just stay with the last released (ancient) versions
23:42:45 <OwenS> At the very least tag a couple of weeks before a Ubuntu release goes final :p
23:42:51 <theholyduck> Rubidium, well the problem with that approach,
23:42:59 <OwenS> That provides a) A regular schedule b) Gets the package out
23:43:03 <theholyduck> Rubidium, is that generally, the moment anyone comes having problems
23:43:11 <theholyduck> its either fixed in the latest svn
23:43:20 <theholyduck> or atleast, needs to be tested in it
23:43:36 <theholyduck> and ubuntu users use the same packages for half a year ++
23:43:47 <Rubidium> OwenS: better a couple of weeks after the Ubuntu release so it actually has the time to propagate from Debian to Ubuntu and such
23:44:12 <theholyduck> OwenS, 6 months is alot in multimedia :p
23:44:20 <theholyduck> especially with some of the newer stuff going on
23:44:24 <theholyduck> 6 months is an eternity
23:44:24 <Rubidium> they close the import quite early
23:44:25 <OwenS> I was kinda hoping that by making "proper" releases Ubuntu would actually pick them up :p
23:44:37 <OwenS> Rather than indirecting through Debian
23:44:37 <theholyduck> OwenS, they might not
23:44:45 <theholyduck> it took them a year to go from 1.0rc1 to 1.0rc2
23:44:49 <theholyduck> after rc2 was released
23:45:01 <theholyduck> ubuntu = SLOW on the uptake
23:45:41 <Rubidium> well, maybe 2.5, but they used Debian testing
23:45:51 <Rubidium> which means another 10 days to migrate from unstable to testing
23:45:53 <OwenS> Rubidium: Its an LTS release
23:46:08 <theholyduck> well, as an example
23:46:11 <Rubidium> with a MASSIVE snafu just days before the release
23:46:14 <theholyduck> in the last 6 months,
23:46:24 <theholyduck> open source multimedia software .
23:46:38 <theholyduck> has gotten weighted p frame support via x264
23:46:46 <theholyduck> giving large bonuses in video compression
23:47:04 <theholyduck> support for end to end latency encoding of a couple of millisecond for streaming applications
23:47:11 <Rubidium> OwenS: Karmic stopped importing 4 months (25-06) before the release (29-10)
23:47:14 <theholyduck> bluray authoring support
23:47:33 <theholyduck> the ability to adapt streaming quality on the fly.
23:47:41 <theholyduck> true vfr encoding
23:47:56 <theholyduck> OwenS, 6 months means a whole gigant load of improvements
23:48:10 <theholyduck> updating your multimedia software once a month is allready too little
23:48:12 <OwenS> theholyduck: Sure. But it would be better than we have now
23:48:25 <theholyduck> OwenS, well what we have now is ubuntu running so uselessly outdated
23:48:34 <OwenS> And the mplayer install on my HTPC is 6 months old...
23:48:34 <theholyduck> we just link them to a svn compilation guide and say
23:48:42 <theholyduck> "it works on the svn"
23:48:57 <theholyduck> if the version is only a couple of months
23:49:01 <theholyduck> instead of a couple of years old
23:49:10 <theholyduck> they might not be incentivized to use a good version
23:49:33 <Rubidium> theholyduck: so basically you're giving people a very good incentive to not use mplayer
23:49:42 <theholyduck> Rubidium, essentially sure.
23:50:00 <theholyduck> but all the other players are slower, support less stuff, have worse demuxers, have no video filters and dubious subtitle renderers
23:50:04 <theholyduck> its mplayer or bust essentially
23:50:17 <OwenS> "dubious subtitle renderers"? Thats a complement to mplayer?
23:50:24 <OwenS> Which doesn't even know how to position SSA subtitles?!
23:50:31 <theholyduck> OwenS, it does now
23:50:36 <theholyduck> libass was patched in the last 6 months
23:50:44 <theholyduck> making it on par with visfilter
23:50:58 <theholyduck> as in, reproduces everything as vsfilter does
23:51:05 <theholyduck> all the bugs of vsfilter people abuse aswell
23:51:07 <OwenS> Great. Now I just need to figure out what magic options I need to provide to build mplayer on Solaris...
23:51:15 <theholyduck> and its alot faster than vsfilter aswell
23:51:31 <theholyduck> infact, mplayer now has the best ass renderer around
23:51:41 <theholyduck> since its just as good as the standard, and way faster
23:52:15 <OwenS> Also: Why is the vobsub renderer making my subtitles transparent? -_-
23:52:21 <theholyduck> OwenS, i think it involves atleast 3 sheep.
23:52:30 <theholyduck> OwenS, mplayer default, i'm not quite sure myself
23:52:34 <theholyduck> you can change it if you want to
23:52:54 <theholyduck> its marginally less ugly than gigant yellow vobsubs though
23:53:12 <OwenS> If the vobsubs are yellow... I have some which are green or other colours, and therefore disappear
23:53:36 <theholyduck> theres probably an option to make it obey the orignal flags
23:53:44 <theholyduck> honestly, the mplayer manual is like 8k lines
23:53:50 <theholyduck> i'm not familiar with the vobsub section
23:54:09 <OwenS> I'm not familiar with any of it really. Except for the bits I had to fiddle with to enable vdpau :p
23:54:18 * OwenS hugs 8400GS (And nVIDIA's awesome Solaris drivers)
23:54:44 <theholyduck> the biggest advantage of vdpau over xv
23:54:53 <theholyduck> isnt actually speed of decoding/display
23:55:12 <theholyduck> but the ability to do stuff to the video after hardware scaling
23:55:32 <OwenS> In my case, its actually the ability to decode the video in the first place
23:55:38 <OwenS> My HTPC runs on an Atom ;-)
23:55:44 <theholyduck> with xv you have to render the subtitles before hardware scaling takes effect
23:55:53 <theholyduck> so if your video is dvd res
23:56:09 <theholyduck> and you got a gigant 1080p or beyond monitor
23:56:21 <theholyduck> even if the subtitles are softsubs, with xv, they'll be blured due to scaling
23:56:40 <theholyduck> with vdpau, you can scale the video, bring it back, overlay the subtitles
23:56:44 <theholyduck> and send to monitor
23:56:54 <theholyduck> so even if the video is blury
23:56:55 <theholyduck> atleast your subtitles are crystal clear
23:56:57 <OwenS> In my case, some stuff gets scaled up, some down, since my TV is 1360x768
23:57:25 <theholyduck> OwenS, either way, vdpau lets you render subtitles at native res
23:59:08 <theholyduck> i'm going to miss xv when its gone
23:59:17 <OwenS> The only issue I have with my Atom HTPC is when idiots encode 720p MPEG-4 ASP...
23:59:26 <theholyduck> its one of the few places of almost 100% compitability with everything
23:59:47 <theholyduck> especially in relation to xorg
23:59:59 <theholyduck> almost every graphic card produced since the middle of the 90's ish
continue to next day ⏵
