IRC logs for #openttd on OFTC at 2010-04-13
⏴ go to previous day
00:34:09 *** welshdragon has joined #openttd
00:40:35 *** mrruben5 has joined #openttd
00:55:01 <amalloy> i have a brickworks right next to an engineers yard; they both want gravel, and the brickwork wants clay. i'm supplying gravel and clay, but all of the gravel goes to the engineers yard, so neither industry can produce anything. is there a way to fix this?
00:57:05 *** roboboy has joined #openttd
01:01:53 <amalloy> never mind. it looks like after a while the engineers get the idea and magically pass along the gravel
01:23:31 <Belugas> that is not yet my case :S
01:57:04 *** welshdragon is now known as welshdragon`
02:00:17 <Belugas> me too... barey alive, stil working like a bitchy bitch
02:01:35 <Belugas> customer "just" realized that debit is not working. the payment processor is not yet certified with the current frontend
02:01:57 <Belugas> so we're preparing to switchto another frontend
02:13:08 <Belugas> and you? what are you doing up? already at work
03:03:05 <Mazur> Hm, a bug? I'm trying to finance an Oil Refinery, but it won't let me construct one.
03:03:30 <Mazur> Claims it can only be built near the edge of the map.
03:25:48 <Cadde> I also direct the ^^^ to PeterT since he is in channel and have already compiled this once.
03:30:19 *** Rhamphoryncus has joined #openttd
04:29:49 <PeterT> Cadde: You download the source, apply the diff, then compile
04:29:59 <PeterT> You need a proper compiling enviornment
04:30:07 <Cadde> Yeah, the diff wont apply
04:30:39 <Cadde> Hmm...missing header for unified diff at line 22 of patch
04:30:39 <Cadde> The next patch looks like a unified diff to me...
04:30:39 <Cadde> can't find file to patch at input line 22
04:31:03 <PeterT> I don't think that's your problem, that sounds like a bad diff
04:31:04 <Cadde> I am calling with: patch -p1 -i"d:\Downloads\ProgSigs-9e27dcd1-r19541.diff" --verbose --dry-run -l -f
04:31:57 <Cadde> p1 because he has a/ and b/ directories aparently
04:32:43 <PeterT> line twenty-two is @@ -480,6 +483,7 @@ saveload/subsidy_sl.cpp
04:32:57 <Cadde> Yes, i have checked the source.list and it should match
04:33:07 <Cadde> But it doesn't. I am like wtf!
04:33:41 <PeterT> can you try just patch -p1 < ProgSigs-9e27dcd1-r19541.diff
04:33:51 <PeterT> With the diff in the same directory as the source please
04:34:21 <PeterT> way past my bedtime :-P
04:34:57 <Cadde> patching file source.list
04:34:57 <Cadde> Assertion failed: hunk, file ../patch-2.5.9-src/patch.c, line 354
04:35:42 <PeterT> that's a broken patch.exe
04:36:20 <Cadde> But i've tried with lots of different tools now
04:36:50 <Cadde> Is there a way to set -p1 for tortoise?
04:37:12 <PeterT> No, TortoiseSVN will only deal with SVN patches
04:38:01 <Cadde> Oh shit... remembered i need to do somthing with the .diff
04:38:50 <Cadde> patching file source.list
04:38:50 <Cadde> patching file src/command.cpp
04:38:50 <Cadde> patching file src/command_type.h
04:38:50 <Cadde> patching file src/lang/english.txt
04:38:50 <Cadde> patching file src/openttd.cpp
04:38:51 <Cadde> patching file src/pathfinder/yapf/yapf_costrail.hpp
04:38:51 <Cadde> The next patch would create the file src/programmable_signals.cpp,
04:38:51 * PeterT doesn't know a terinjokes
04:39:26 <Cadde> I've been reading up a lot on the different tools. Forgot to convert from lf to crlf
04:42:54 *** DaleStan has joined #openttd
04:43:54 *** DaleStan_ has joined #openttd
04:43:54 *** DaleStan is now known as Guest2334
04:43:55 *** DaleStan_ is now known as DaleStan
04:44:58 *** DaleStan_ has joined #openttd
04:44:58 *** DaleStan is now known as Guest2335
04:44:59 *** DaleStan_ is now known as DaleStan
05:25:31 *** SekiSelu has joined #openttd
05:29:08 *** roboboy has joined #openttd
05:38:55 *** planetmaker has joined #openttd
06:30:26 *** devilsadvocate has quit IRC
06:36:14 *** Cybertinus has joined #openttd
06:50:58 *** Polygon has joined #openttd
06:53:01 *** devilsadvocate has joined #openttd
06:54:03 *** XeryusTC2 has joined #openttd
06:54:39 *** dihedral has joined #openttd
07:25:48 *** Grelouk has joined #openttd
07:33:52 *** terinjokes has joined #openttd
07:36:35 *** XeryusTC2 has joined #openttd
07:36:56 *** dihedral has joined #openttd
07:53:24 *** ChoHag_ has joined #openttd
07:55:59 *** Phazorx has joined #openttd
08:00:01 *** _teeone has joined #openttd
08:01:45 *** _teeone is now known as teeone
09:09:17 *** Devroush has joined #openttd
09:14:57 *** planetmaker is now known as Guest2349
09:14:57 *** pm is now known as planetmaker
09:40:28 *** Terkhen has joined #openttd
09:54:51 *** Doorslammer has joined #openttd
10:17:14 *** lobstar has joined #openttd
10:33:25 *** Luukland has joined #openttd
10:35:35 *** Coco-Banana-Man has joined #openttd
11:03:12 *** Keyboard_Warrior has joined #openttd
11:04:58 *** KenjiE20 has joined #openttd
11:13:08 *** XeryusTC is now known as Guest2361
11:13:08 *** XeryusTC2 is now known as XeryusTC
11:21:13 *** devilsadvocate has quit IRC
11:26:51 *** DaleStan has joined #openttd
11:34:19 *** nighthawk_c_m has joined #openttd
11:36:13 *** ChanServ sets mode: +v tokai
11:50:24 *** welshdragon` is now known as welshdragon
11:56:53 *** devilsadvocate has joined #openttd
12:00:39 *** fjb is now known as Guest2366
12:02:53 *** Devroush has joined #openttd
12:26:12 *** DaleStan_ has joined #openttd
12:26:12 *** DaleStan is now known as Guest2369
12:26:12 *** DaleStan_ is now known as DaleStan
12:34:23 *** JakeGrimshaw has joined #openttd
12:36:00 *** DaleStan is now known as Guest2372
12:36:00 *** DaleStan_ has joined #openttd
12:36:00 *** DaleStan_ is now known as DaleStan
13:16:30 *** roboboy has joined #openttd
13:23:23 *** Keyboard_Warrior has quit IRC
13:31:51 *** Biolunar has joined #openttd
13:33:47 *** Dreamxtreme has joined #openttd
13:35:09 *** sunk is now known as sunkan
14:00:49 <XeryusTC> there is a minor bug in ottd's max vehicles code
14:01:48 <XeryusTC> if you create a vehicle with a number lower than the max_<vehicletype> setting it is allowed even though you already have max_<vehicletype> amount of vehicles
14:02:15 <Eddi|zuHause> you know where bugs go?
14:02:27 <XeryusTC> yes, but i'm too lazy to register :P
14:07:58 *** OsteHovel^PDA has joined #openttd
14:16:05 *** tinyboss has joined #openttd
14:30:06 *** lasershock has joined #openttd
14:39:40 *** Devedse has joined #openttd
14:42:35 *** JVassie has joined #openttd
14:46:30 *** Progman has joined #openttd
14:47:20 *** nighthawk_c_m has joined #openttd
15:03:38 *** Grelouk has joined #openttd
15:07:53 <Ammler> Is the suse user online? Official suse rpms are fixed now...
15:11:23 <Devedse> what is the advantage of not placing signals on every single tile?
15:12:56 <planetmaker> also: how do you place a signal every tile, if you want to build a junction (the most critical part of networks)?
15:13:27 <SmatZ> planetmaker: you can built just point-to -point tracks ;)
15:13:52 <SmatZ> actually, when I was new to TT, I used this stil
15:14:29 <planetmaker> well... but that's LOOONG ago in your stone-age TT-era ;-)
15:14:36 <Ammler> if you use tunnels or bridges, the signal gap should be that length
15:14:43 <Ammler> so trains keep constant flow
15:15:17 <Devedse> so like this signal, not signal, signal, not signa
15:15:19 <planetmaker> signal distance = size of largest gap due to junctions / tunnels / bridges / ...
15:15:39 <Ammler> well, that is the min possible gap :-)
15:15:54 <Devedse> what is the most used one :O
15:15:55 <Ammler> but then you need to double bridges
15:15:57 <planetmaker> it makes main line junctions interesting :-)
15:16:26 * Devedse just learned not to start with transporting passengers :(
15:16:38 <planetmaker> Devedse, the most used one seems to be *something*, but then most-used one probably is also a rectangular network with only p2p lines
15:17:07 <planetmaker> I use usually signal distance = 2
15:17:08 <Devedse> i like mainlines etc ;P
15:17:36 <planetmaker> but it implies BIG hubs
15:18:21 <Mazur> PLanetmakar: Does that also mean you only make 1 tile (3 tile, including heads) bridges and tunnels, then?
15:18:34 <planetmaker> Mazur, it doesn't.
15:18:49 <planetmaker> But I double / tripple / quadruple the lines in those cases
15:19:25 <Mazur> Length of tunnel/2 number of tunnels.
15:20:09 <Mazur> Have you ever played the map of the Netherlands like that?
15:20:10 <Devedse> does someone know a nice NON breakdown server?
15:20:21 <planetmaker> For Trainlength of 5: < 11 needs 2, 12 - 18 needs 3, 19 - 25 needs 4.
15:20:25 <Rubidium> Devedse: #openttdcoop stable
15:20:50 <planetmaker> Mazur, it depends upon the train length used.
15:21:32 <Mazur> Is all this somewhere in the Wiki? Like in a section "Sage advice from experienced players."?
15:21:57 <planetmaker> it's in our coop bot. Not sure whether or where it is in our wiki or blog
15:22:23 <planetmaker> I just asked our coop bot and pasted his answer here ;-)
15:22:25 *** frosch123 has joined #openttd
15:22:57 <Mazur> I'll ask it myself then and log it, for reference.
15:23:12 <planetmaker> it probably is *somewhere*
15:24:20 <Mazur> Btw the Dutch map is eminently playable to start with passengers. I made my first billion without any goods.
15:25:36 <planetmaker> I usually start two planes between two distant airports and then I start to build whatever I like ;-)
15:25:50 <planetmaker> except if I start 1880 or so.
15:25:54 <Mazur> Hm, I now have three browsers open with 9 openttd pages.
15:26:37 <Mazur> >Well, I've _read_ and bookmarked a few more.
15:27:03 <planetmaker> :-) My OpenTTD-related bookmarks have their own main category in my bookmarks list
15:27:20 <planetmaker> and they probably fill an entire screen just writing their titles
15:29:29 <planetmaker> but then among that list there are also bookmarks which are not quite obviously related to OpenTTD like some apple developer pages or mercurial howtos ;-)
15:30:00 <planetmaker> I consider it related, though ;-)
16:07:36 *** einKarl has joined #openttd
16:08:06 <SpComb> bug: OpenTTD is very laggy when played over the internet using SSH X-Forwarding
16:08:22 <Mazur> Seperate folder on my browser, too, in the visible part of the bookmarks.
16:09:27 <Eddi|zuHause> SpComb: bug: OpenTTD is very laggy without 2D hardware acceleration
16:11:17 <Eddi|zuHause> SpComb: 640x480, 8bpp, 33fps makes ~80mbit
16:11:34 <Mazur> Well, I've not planes yet, I've just set up an oil collection to a nearby sea-built refinery, a long goods shipline to a shore city, a coal run from an island to that same city and a passenger line there.
16:12:15 <SpComb> it does updates smarter than that
16:12:35 <Eddi|zuHause> SpComb: yes, but it is still a lot, even over LAN
16:12:50 <SpComb> probably bottlenecked by my WLAN
16:13:04 <SpComb> but latency is horrible, couldn't it just skip frames or something? :)
16:13:05 <Eddi|zuHause> 12mbit sounds like a wlan speed, yes
16:13:31 <Eddi|zuHause> SpComb: maybe SDL has special stuff for x-forwarding?
16:15:53 *** Phazorx has joined #openttd
16:16:36 <peter1138> oh, you're actually forwarding openttd's display over ssh? lol
16:16:40 <theholyduck> SpComb, ssh x forwarding
16:16:44 <theholyduck> is ESPECIALLY stupid
16:17:10 <theholyduck> vnc or something should be better
16:17:24 <theholyduck> hacking up something with synergy, ffmpeg and mplayer
16:17:29 <theholyduck> wouldnt be too hard
16:17:45 <theholyduck> would be just as real time
16:17:58 <Rubidium> won't "mpeg" make the signals less legible?
16:18:10 <theholyduck> Naw, ffmpeg + x264 in zero latency mode
16:18:15 <theholyduck> should give massive compression
16:18:18 <theholyduck> at real time speeds
16:18:20 <planetmaker> nah. It's actually a nice test for all those people who want to out-source all calculations to the server and just stream the image ;-)
16:18:35 <theholyduck> Rubidium, though to make this REALLY work,
16:18:50 <theholyduck> you need to hack up something more directly
16:18:56 <theholyduck> some x11 libraries
16:19:00 <theholyduck> and a custom frontend
16:19:22 <theholyduck> writing the code that glues them all together shouldnt be that complicated
16:19:43 <theholyduck> i think the x264 lead dev did something like this for low latency lan fps gaming
16:20:04 <theholyduck> Rubidium, massive compression at the same video quality level that is
16:22:00 <theholyduck> Rubidium, you can do lossless encoding sure
16:22:10 <theholyduck> but much more efficient is to just go for transparency
16:22:17 <theholyduck> the human eye and brain is far from perfect
16:22:27 <theholyduck> so you can at very low bitrates actually
16:22:35 <theholyduck> make something that looks lossless
16:22:46 <theholyduck> to the human eye, even with side by side comparisons to the actual lossless
16:23:38 <theholyduck> "No longer does 200ms seem out of reach. If anything, its now far more than we need. Because with tune zerolatency, single-frame VBV, and intra refresh, x264 can achieve end-to-end latency (not including transport) of under 10 milliseconds for an 800600 video stream. And its all open source."
16:23:43 <Rubidium> just make a proof-of-concept with all signal types and then we'll determine whether the block signals (pre, combo, exit) are still easily distinguishable
16:24:13 <theholyduck> Rubidium, hmm, intresting.
16:24:22 <Rubidium> even JPEG with low compression makes a mess of that
16:24:33 <theholyduck> Rubidium, sure, but h264 as a still image encoder
16:24:41 <theholyduck> is actually about 50% more efficient
16:24:51 <theholyduck> and since we have lan bandwidths
16:25:07 <Rubidium> just making the white a bit more yellow and the yellow a bit more white and you'll have a yellowish white/whitish yellow that you can't distinguish anymore
16:25:08 <theholyduck> we can use way more than jpeg levels of filesizes
16:25:20 <theholyduck> Rubidium, well, the BIGGEST problem there :P
16:25:23 <theholyduck> might be colorspaces
16:25:35 <theholyduck> on the other hand,
16:25:41 <theholyduck> openttd only uses 8bit colors anyway
16:25:47 <theholyduck> so its not really a problem
16:26:23 <peter1138> lossy compression is no doubt fine for an FPS game
16:26:36 <theholyduck> peter1138, lossy is amount of details though
16:26:37 <Rubidium> for video I'll believe you it isn't that noticable, but the same holds for photos and JPEG. Yet with OpenTTD JPEG makes it impossible to distinguish the signals
16:26:39 <theholyduck> colors are raly changed :P
16:26:40 <Eddi|zuHause> <theholyduck> the human eye and brain is far from perfect <-- that's a bad argument. JPEG and all related stuff cannot (by design) handle straight lines, so they are absolutely the wrong choice for anything computer generated
16:27:17 <Eddi|zuHause> you might get something better out of wavelet transformation, but most graphics cards don't have hardware acceleration for that
16:27:55 <theholyduck> Eddi|zuHause, protip
16:28:00 <theholyduck> wavelets are WAY more unsuited
16:28:03 <theholyduck> for straight lines
16:28:33 <Eddi|zuHause> there's worse than "absolutely unsuited"?
16:28:40 <theholyduck> take jpeg2k for instance
16:28:48 <theholyduck> its a wavelet format
16:28:53 <theholyduck> its way more computionally intensive than jpeg
16:28:59 <theholyduck> its larger filesizes than jpeg
16:29:16 <theholyduck> and it archives way higher PSNR than jpeg
16:29:24 <theholyduck> in actual human testing
16:29:35 <theholyduck> jpeg2k looks worse at the same filesizes
16:29:56 <theholyduck> as in, the next generation, wavelet format, actually looks worse to human eyes
16:30:17 <theholyduck> than the old, outdated dct format that is jpeg
16:30:33 <theholyduck> dct consitently outperforms wavelets across the board
16:30:52 <theholyduck> the only problem with dct formats is that they create "blockyness" in your images and videos
16:30:56 <theholyduck> so you have to deblock on display
16:34:25 <theholyduck> i'll just have to boot up my debian system to get some decent ffmpeg setup for x11grab
16:37:30 *** theholyduck has joined #openttd
16:38:26 <theholyduck> want me to test with opengfx or original?
16:39:00 <Eddi|zuHause> 's a matter of which pictures you use as sample
16:39:08 <theholyduck> i'll use a propper live cliop
16:39:14 <theholyduck> anything else would be cheating :P
16:39:21 <theholyduck> i'll encode a 20 sec sample or something
16:39:25 <Eddi|zuHause> JPEG is a brilliant choice for anything "natural" (photos, videos, etc.)
16:39:28 <theholyduck> and upload to mediafire :P
16:39:40 <theholyduck> png is great for low colors/computer stuff
16:39:42 <theholyduck> since its lossless
16:39:52 <Eddi|zuHause> theholyduck: but it's awful for anything screenshot-y
16:40:06 <theholyduck> Eddi|zuHause, png isnt
16:40:10 <theholyduck> png is great because its lossless
16:40:17 <theholyduck> sure this means it can be huge
16:40:25 <theholyduck> but no detail is lost
16:41:10 *** FloSoft has joined #openttd
16:45:13 <yuriks> what is theholyduck doing here?
16:50:09 <__ln__> @seen the_mac-owner_from_denmark
16:50:09 <DorpsGek> __ln__: I have not seen the_mac-owner_from_denmark.
16:55:49 *** theholyduck has joined #openttd
16:55:58 <theholyduck> working on eet, etc
16:57:16 <Rubidium> optipng doesn't do much on the PNGs OpenTTD's screenshot produces
16:57:59 <Rubidium> I've tried most of those tools and neither could improve it by more that 0.5%; actually zip compresses those files better than 7z/lzma
17:00:14 <Eddi|zuHause> theholyduck: btw. since openttd is 8bpp, png screenshots are usually smaller than jpeg screenshots
17:00:28 <theholyduck> Eddi|zuHause, yeah, didnt i say, png is great for low color stuff
17:00:39 <theholyduck> anime, manga, most computer related screenshots, etc
17:01:22 <Eddi|zuHause> so what we need is a lossless video codec optimised for fast processing, possibly png based
17:01:33 <theholyduck> Eddi|zuHause, no we dont :P
17:01:40 <theholyduck> lossless is overkill
17:01:54 <theholyduck> though, i'll see how large the x264 lossless encode of mine turns out
17:02:06 <Eddi|zuHause> no, openttd really needs lossless
17:03:00 <Eddi|zuHause> theholyduck: you get eye cancer from openttd jpeg-screenshots
17:04:28 <theholyduck> Eddi|zuHause, no, you only need VISUALLY lossless
17:04:34 <theholyduck> Eddi|zuHause, for images you might need lossless :P
17:04:36 <theholyduck> for video, you dont
17:05:00 <theholyduck> hmm, seems x11 grab is alot slower than i remember it being though
17:05:20 <theholyduck> i'm using my broken drivers.
17:05:28 <theholyduck> well then, the video will have to be lolnon smooth
17:05:40 <theholyduck> the problem we were looking at was colors anyway
17:05:50 <theholyduck> colors and simelarity
17:09:14 <theholyduck> well. as it turns out
17:09:50 <theholyduck> lossless 640x480 for 20 secs
17:10:00 <theholyduck> with the FAST x264 setting
17:10:24 <theholyduck> though, it was a almost entirely static image
17:10:27 <theholyduck> no trains or nothing :p
17:10:34 <theholyduck> just date changing
17:12:11 <theholyduck> with visually lossless settings, i lowered that to 230kB
17:14:15 <theholyduck> there, took a png screenshot of both
17:15:45 <theholyduck> now to upload them :p
17:15:55 <theholyduck> both single png screenshots saved by gimp.
17:15:59 <theholyduck> with highest compression on
17:16:05 <theholyduck> are larger than the 20 second video file
17:16:28 <theholyduck> either way, moving on
17:17:24 <theholyduck> infact, the "lossy" video clip
17:17:30 <theholyduck> is small enough to be playable on dual line isdn
17:18:44 <theholyduck> the lossy pic compresses alot worse with png due to added noise
17:18:49 <theholyduck> but i dare you to try and spot it :P
17:18:52 <theholyduck> Eddi|zuHause, Rubidium etc,etc
17:20:51 *** Dred_furst has joined #openttd
17:21:16 *** TheMask96 has joined #openttd
17:23:07 <theholyduck> Eddi|zuHause, so i figure with a bit of hacking, some non broken drivers, you coud play openttd, losslessly with x264 over the lan, and with invisible lossyness
17:23:09 <theholyduck> over the internet
17:23:16 <theholyduck> even if your internet was lolslow
17:24:39 <Eddi|zuHause> theholyduck: please, go ahead, fiddle the output pipe of the openttd graphics buffer into the x264 converter, as a "video driver" or something...
17:25:17 <theholyduck> Eddi|zuHause, can you even tell the difference between the lossy and the lossless?
17:25:20 *** fonsinchen has joined #openttd
17:25:35 <theholyduck> as i said, lossless video formats are overated provided the lossy encoding is good enough
17:25:45 <Eddi|zuHause> theholyduck: create a file src/video/x264_v.cpp
17:26:06 <theholyduck> Eddi|zuHause, heh, well i dont really see the use for it.
17:26:26 <theholyduck> i was just pointing out, that x forwarding is NOT the way to even try and play a game over a network
17:26:26 <Eddi|zuHause> theholyduck: lots of people wanted "recording" feature in the past...
17:27:42 <Eddi|zuHause> ("problem" is you can't handle any input this way...
17:29:42 <CIA-6> OpenTTD: frosch * r19616 /trunk/src/ (5 files): -Codechange: Increase transparency of 'Extract' by passing also the number of used bits.
17:30:01 <theholyduck> Eddi|zuHause, x11grab is a bit too "highlevel" to be fast aswell
17:30:21 <theholyduck> in reality, you want something more low level for the recording bit
17:30:32 <Eddi|zuHause> theholyduck: that's why you should hook directly into openttd's video output buffer
17:30:45 <theholyduck> Eddi|zuHause, heh :P
17:31:05 <theholyduck> Eddi|zuHause, the biggest problem with doing this though
17:31:10 *** Chillosophy has joined #openttd
17:31:32 <theholyduck> is that you would get open source puritans on your neck
17:31:37 <theholyduck> for not using theora
17:31:46 <theholyduck> ofcourse, theres 1 very good reason to not use theora
17:31:50 <theholyduck> as it turns out, its rubbish
17:31:51 <Eddi|zuHause> does that actually matter?
17:32:14 <theholyduck> last comparison i saw, to get the same video quality as x264 even in fast settings
17:32:24 <theholyduck> theora needed 400% of the bitrate
17:32:38 <theholyduck> and people are touting it "the future of internet video"
17:33:29 *** owenshep has joined #openttd
17:33:41 *** owenshep is now known as OwenS
17:34:56 <yuriks> theholyduck: is there even any difference in the pixel output of lossy and lossless versions?
17:35:21 <yuriks> theholyduck: and you sure lossless is actually lossless?
17:35:27 <yuriks> the icons look a bit mushy, but it may be just me
17:35:36 <theholyduck> yuriks, well, colorspace conversion
17:35:42 <theholyduck> the lossless is definitly lossless
17:35:48 <theholyduck> but its still yuv 420p
17:35:53 <theholyduck> and openttd is rgb
17:35:57 <theholyduck> so there is bound to be some loss :P
17:36:03 <yuriks> can't x264 encode rgb?
17:36:20 <frosch123> did dyou maybe confuse the filenames, my browser tells me the lossy file is twice as big as the other
17:36:32 <yuriks> frosch123: lossy is bigger because of noise
17:36:33 <CIA-6> OpenTTD: rubidium * r19617 /trunk/src/network/network.cpp:
17:36:33 <CIA-6> OpenTTD: -Fix [desync debug]: log the sync state only once per day, not multiple times when paused with _date_fract = 0
17:36:33 <CIA-6> OpenTTD: -Change [desync debug]: check the sync state from the command stream and make sure no unknown input is encountered
17:36:53 <theholyduck> yuriks, h264 is a yuv only format
17:37:05 <theholyduck> and it doesnt support yuv 422 or yuv 444 yet
17:37:23 <theholyduck> frosch123, it is :P
17:37:27 <frosch123> oh, i thought it was about png comression
17:37:39 <theholyduck> the lossy file is twice as big and then some
17:37:43 <theholyduck> because theres extra data noise
17:37:47 <theholyduck> in the lossy version
17:37:51 <theholyduck> the lossless version is clean
17:37:58 <yuriks> theholyduck: h264 only supports 4:2:0? yuck
17:38:10 <theholyduck> yuriks, not really
17:38:12 <theholyduck> its a VIDEO encoder
17:38:16 <theholyduck> almost all non pro video
17:38:23 <theholyduck> infact, all consumer stuff is :P
17:38:29 <yuriks> well, yeah, not really, but it's awful for pixel stuff =P
17:38:39 <yuriks> that's what I meant to mean
17:38:52 <theholyduck> yuriks, well 422 and 444 support is comming
17:38:58 <theholyduck> its in the gsoc project list
17:39:09 <theholyduck> its just not here yet
17:41:30 <Eddi|zuHause> the biggest problem with a "video" video driver is probably getting a (portable) way of creating a window for video playback that can give mouse and keyboard input as feedback
17:41:59 <Eddi|zuHause> piping the data into the video conversion library should be fairly trivial
17:45:14 <peter1138> custom protocol that tells the client what sprites to draw
17:45:20 <CIA-6> OpenTTD: translators * r19618 /trunk/src/lang/slovak.txt:
17:45:21 <CIA-6> OpenTTD: -Update from WebTranslator v3.0:
17:45:21 <CIA-6> OpenTTD: slovak - 6 changes by keso53
17:54:39 *** Hyronymus has joined #openttd
18:00:59 *** Plimmer has joined #openttd
18:05:33 *** Hyronymus has joined #openttd
18:06:53 *** ajmiles has joined #openttd
18:09:43 <Eddi|zuHause> peter1138: so basically a "thin client" that has all the grfs locally?
18:10:32 <Eddi|zuHause> that's basically a special case of multithreading
18:12:23 <Eddi|zuHause> it *could* work but there are some serious issues, as people will want to join a multiplayer server like that...
18:13:30 <Belugas> cannot use a blob as a calculate field
18:14:51 <SpComb> are you trying to do string manipulation on a blob field in a query?
18:15:20 <SpComb> blobs are for things like images; you're not supposed to touch their contents from within SQL
18:15:27 <SpComb> just opaque binary things
18:15:40 <Belugas> a query, indeed, with a blob field. adding stuff on the blob
18:15:47 <Belugas> not allowed by delphi
18:16:04 <Belugas> but not WITHIN the sql
18:16:31 <Belugas> and i CAN add stuff on a BLOB within SQL :)
18:16:36 <Belugas> but it's not what i need here
18:17:03 <Belugas> tweo type of blob: text (memo) and binary (images)
18:17:08 <Belugas> i am using the first one
18:17:12 <Belugas> in this case, at least
18:20:02 <SpComb> upgrade to something other than interbase/delphi? :
18:21:26 *** welshdragon has joined #openttd
18:25:39 *** Plimmer has joined #openttd
18:26:13 <Belugas> "hey boss! would you like to throw 10 years of coding through the window?"
18:26:40 <peter1138> not in the world of commercial software with huge investments in code, short deadlines and expensive accreditation
18:26:42 <SpComb> don't be so conservative
18:29:47 <Wolf01> Belugas, that's the same thing I said the last year after 2 months of porting the whole project from collections to objects with recursion and a lot of very useful functions
18:41:00 <CIA-6> OpenTTD: rubidium * r19619 /trunk/src/network/network.cpp: -Fix (r19618): [desync debug] inserting the "join" pause could cause a crash as some command data was not properly initialised
18:41:55 <frosch123> now translators already break the desync debugging :p
18:45:10 <Belugas> Wolf01, technically, it CAN be done, but it would require a very massive investment of time
18:45:27 <Belugas> we have ROUGHTLY more than a million lines of code
18:45:37 * andythenorth thinks about making something
18:45:40 <andythenorth> what shall I make?
18:46:10 <Belugas> SpComb, peter1138 knows what he's talking about, we're doing ROUGHLY the sme thing in ROUGHLY the same type of pressure/NOW environmemnt
18:47:00 <Wolf01> I'm starting to make something for my new Omnia 2
18:47:25 * andythenorth loses money when our colo is taken offline by fibre failures :(
18:48:51 <amalloy> where can i find an explanation of how PBS works? the wiki just says "reserve a path to a safe exit", and i'm not clear on what that means
18:49:24 <amalloy> does it actually mean exit signals, or any signal? does the whole block need to be cordoned off with path signals, or can just some of them be paths or what
18:50:06 <Hirundo> Basically, place a path signal wherever you'd want a train to wait
18:50:28 <SpComb> Belugas: did I tell you about the full OpenTTD rewrite in Python I started yesterday?
18:53:17 <amalloy> thanks. i'm reading that, and it looks perfect so far
18:54:33 <andythenorth> meh, I need to add four wagons to four identical trains with shared orders
18:54:52 <amalloy> oh, ha, apparently i was at the end already. i mostly get it now, i think. is there ever a scenario where i would want to put non-path signals inside of a path-delimited block?
18:55:44 <CIA-6> OpenTTD: rubidium * r19620 /trunk/src/network/ (network_command.cpp network_internal.h network_server.cpp):
18:55:44 <CIA-6> OpenTTD: -Fix: desync when a command is received and in the queue while a client starts
18:55:44 <CIA-6> OpenTTD: joining, i.e. save the game state. This can happen in two ways: with frame_freq
18:55:44 <CIA-6> OpenTTD: > 1 a command received in a previous frame might not be executed yet or when a
18:55:44 <CIA-6> OpenTTD: command is received in the same frame as the join but before the savegame is
18:55:45 <CIA-6> OpenTTD: made. In both cases the joining client would not get all commands to get in-sync
18:55:47 <CIA-6> OpenTTD: with the server (and the other clients).
18:56:17 <Wolf01> gah 1.5GB of SDK and other related things to download...
18:56:43 <fjb> andythenorth: Replacing or adding wagons with regular expressions would be fun, but a nightmare to program it.
18:56:56 *** XeryusTC has joined #openttd
18:57:40 <Belugas> enjoy the challenge, SpComb :)
18:59:29 <andythenorth> fjb: I've never learnt regex :o
18:59:50 <fonsinchen> Congratiulations rubidium. I guess this was a lot of work.
19:00:36 <Rubidium> thanks... but it doesn't seem to be the one that hit the ottdcoop stable server a few days ago
19:02:25 *** XeryusTC has joined #openttd
19:05:20 *** Hirundo has joined #openttd
19:06:29 *** Devedse has joined #openttd
19:09:58 *** ajmiles2 has joined #openttd
19:10:22 <CIA-6> OpenTTD: frosch * r19621 /trunk/src/ (aircraft_cmd.cpp roadveh_cmd.cpp ship_cmd.cpp train_cmd.cpp): -Codechange: Remove direct usage of magic 'p1's in build vehicle commands.
19:17:24 *** ajmiles3 has joined #openttd
19:22:13 * andythenorth plays the game instead of coding anything
19:22:56 <Eddi|zuHause> andythenorth: code pre-WWI german engines :)
19:22:57 <Wolf01> me too... it's really boring to stare at the download bars
19:26:38 <Rubidium> please don't link topics I don't read out of efficiency
19:29:35 *** Progman has joined #openttd
19:31:04 <CIA-6> OpenTTD: rubidium * r19622 /branches/1.0/src/network/ (4 files): (log message trimmed)
19:31:04 <CIA-6> OpenTTD: [1.0] -Backport from trunk:
19:31:04 <CIA-6> OpenTTD: - Fix: Desync when a command is received and in the queue while a client starts
19:31:04 <CIA-6> OpenTTD: joining, i.e. save the game state. This can happen in two ways: with frame_freq
19:31:04 <CIA-6> OpenTTD: > 1 a command received in a previous frame might not be executed yet or when a
19:31:05 <CIA-6> OpenTTD: command is received in the same frame as the join but before the savegame is
19:31:07 <CIA-6> OpenTTD: made. In both cases the joining client would not get all commands to get in-sync
19:34:35 *** Jolteon has joined #openttd
19:36:56 *** ajmiles has joined #openttd
19:46:51 *** Devroush|2 has joined #openttd
19:49:15 <andythenorth> To occupy oneself in amusement, sport, or other recreation: children playing with toys.
19:49:54 <Rubidium> but... you are "coding" a network
19:50:22 * andythenorth wonders if "play" is antonym or synonym for "code"
19:51:15 *** Progman has joined #openttd
19:51:40 <andythenorth> coding newgrf is a meta-game
19:51:46 <andythenorth> especially for industries
20:00:12 * andythenorth needs a decent narrow gauge set. 60 year old steam engines in 1980 don't cut it
20:00:18 <andythenorth> nice smoke though :P
20:01:25 <SekiSelu> Coding newgrf is a good way to go insane XD
20:05:25 <Belugas> i would not exactly say that
20:06:12 *** Adambean has joined #openttd
20:06:22 <SekiSelu> I'm trying to understand Action2, VarAction2, and VarAction2Advanced. I don't quite get how to tell the difference -.-
20:08:02 <Belugas> trying to understand the system with action2 is NOT really the easiest way :)
20:08:14 <SekiSelu> Action2 is what I need though :D
20:08:33 *** devilsadvocate has quit IRC
20:19:23 *** devilsadvocate has joined #openttd
20:49:15 * andythenorth needs more airports :|
21:00:47 <Belugas> YEAH!!! HOME!!!!! HERE WE GOOOOOO!!!!!!!!!1
21:05:47 *** Progman has joined #openttd
21:32:54 <CIA-6> OpenTTD: rubidium * r19623 /branches/1.0/ (11 files in 5 dirs):
21:32:54 <CIA-6> OpenTTD: [1.0] -Backport from trunk:
21:32:54 <CIA-6> OpenTTD: - Fix: Company related graphs were not updated correctly after changing the company colour [FS#3763] (r19615)
21:32:54 <CIA-6> OpenTTD: - Fix: Crash when opening a savegame with a waypoint from around 0.4.0 [FS#3756] (r19612)
21:32:54 <CIA-6> OpenTTD: - Fix: Presence of online content was not properly updated after download due to duplicate slashes in the path (r19600)
21:32:55 <CIA-6> OpenTTD: - Fix: [NewGRF] Setting industry prop 0x24 to 0 caused empty station names (r19590)
21:34:02 *** welshdragon has joined #openttd
21:40:36 <CIA-6> OpenTTD: rubidium * r19624 /branches/1.0/src/network/ (6 files in 2 dirs):
21:40:36 <CIA-6> OpenTTD: [1.0] -Backport from trunk:
21:40:36 <CIA-6> OpenTTD: - Fix: Possible invalid read when server moves client to spectators before he finishes joining [FS#3755] (r19613)
21:40:36 <CIA-6> OpenTTD: - Fix: Improve joining behaviour; kicking clients when entering passwords that was just cleared, 'connection lost' for people failing the password (r19610, r19609, r19608, r19607, r19606)
21:43:08 <Eddi|zuHause> hm... do i have to worry about "195 Hardware_ECC_Recovered 0x001a 100 100 000 Old_age Always - 47772712"?
22:08:57 *** Brianetta has joined #openttd
22:10:04 *** devilsadvocate has quit IRC
22:10:53 *** devilsadvocate has joined #openttd
22:15:42 *** Guest2349 is now known as pm
22:53:24 *** orudge- has joined #openttd
22:54:52 *** orudge- is now known as orudge
22:55:05 *** orudge- has joined #openttd
22:57:33 *** Eddi|zuHause has joined #openttd
23:16:50 *** SekiSelu has joined #openttd
23:20:50 *** welshdragon is now known as welshdragoon
23:23:28 *** welshdragon has joined #openttd
23:40:56 *** SekiSelu has joined #openttd
continue to next day ⏵
