IRC logs for #openttd on OFTC at 2013-07-17
⏴ go to previous day
00:07:03 *** SamanthaD has joined #openttd
00:56:54 *** Supercheese has joined #openttd
01:01:29 *** Midnightmyth has joined #openttd
01:45:17 *** montalvo has joined #openttd
01:53:13 *** montalvo has joined #openttd
03:19:45 *** roboboy has joined #openttd
03:55:18 *** SamanthaD has joined #openttd
04:07:53 <Supercheese> "Shooters must use shotguns, 12-gauge or smaller, firing lead, steel or depleted uranium ammunition..."
04:08:04 <Supercheese> Where on earth would anyone get depleted uranium?!
04:11:18 <SamanthaD> Supercheese: out of a nuclear reactor I imagine
04:19:16 <Supercheese> I would be very surprised if there were depleted uranium shotgun shells
04:21:42 <Supercheese> Well dang, there are
04:22:54 <SamanthaD> I don't know why anyone in their right mind would USE them
04:23:03 <SamanthaD> well... they're heavier than lead but...
04:23:09 <SamanthaD> seriously, they'll ruin your shotgun >.>
04:23:41 <SamanthaD> course... there's other (obvious) reasons why they should ban DU in ammo
04:36:14 <Supercheese> Then again, it mostly appears to be an April fool's joke
04:38:27 <SamanthaD> still... the idea of idiots spraying around DU all over the place is worrying
04:39:45 <SamanthaD> Ugh... I need to learn CPP
04:40:32 <Supercheese> Chill's PatchPack is old :P
04:41:03 <SamanthaD> so is the patch I'm trying to apply
04:41:10 <SamanthaD> hence... why I need a crash course in C++
04:42:24 *** supermop has joined #openttd
04:56:17 *** Eddi|zuHause has joined #openttd
04:59:24 *** HerzogDeXtEr has joined #openttd
05:16:54 <SamanthaD> WOOT! let's see if this compiles :3
05:17:05 <SamanthaD> what fun when modifying code blindly >.<
05:17:23 <Supercheese> "Let's comment this out, see what happens"
05:17:31 <SamanthaD> oh right... comments...
05:17:40 <SamanthaD> I just went ape with backspace :p
05:18:12 <SamanthaD> I've always got `svn revert` if I need it ;)
05:18:26 <SamanthaD> and I kept the .mine and .theirs files
05:18:58 <SamanthaD> most of the errors seemed to just be line numbers getting messed up
05:19:38 <SamanthaD> but yeah, I'm not a C++ programmer and this is the first time I've looked at OpenTTD code so...
05:20:56 <SamanthaD> once I worked out some of the basic syntax things started to make sense
05:21:25 <SamanthaD> when I first looked at it I thought that the -> operator was something akin to a bind operator or a pipe
05:21:42 <SamanthaD> and I went "OH GOD SPAGHETTI CODE!" *dies*
05:26:23 <SamanthaD> woot! It just compiled the file that I sorta coin-flipped on the revision
05:32:44 <Supercheese> Any edits, or just raw source?
05:37:30 <SamanthaD> I didn't do any coding but... I had to pay homage to the svn gods
05:38:03 <SamanthaD> I patched the STS_V60_r24032.diff patch into current
05:38:08 <SamanthaD> dunno if I did a very good job though
05:38:12 <SamanthaD> it seems to be running...
05:38:35 <SamanthaD> and it seems to do what it's supposed to do but...
06:06:21 <SamanthaD> blah... the patch doesn't work as well as I thought it might have
06:44:58 *** Midnightmyth has joined #openttd
06:47:47 *** Devroush has joined #openttd
06:57:17 *** roboboy has joined #openttd
07:33:29 *** sla_ro|master has joined #openttd
07:58:13 <Supercheese> Good lord, some terrifying lightning strikes here
07:58:30 <Supercheese> I'm glad all our power lines and such are underground
07:59:32 <SamanthaD> if the lightning is bad enough I just open the breakers
08:00:19 <Supercheese> I'll probably shut down soon, just to be safe
08:01:12 <SamanthaD> when the storms come I switch to battery :3
08:01:15 <roboboy> I wonder how hard it is to hack a png so that it uses a different TT palette than the one it uses
08:02:20 <roboboy> am off to whatch the news
08:06:59 * Supercheese advises the use of the /me command next time ;)
08:07:19 <SamanthaD> I just deleted all my saves and other OpenTTD data and my custom patched binary 'cuz I thought it was glitching
08:07:33 <SamanthaD> apparently it wasn't OpenTTD that was glitching
08:08:10 <SamanthaD> apparently a problem with the OS where if you look at it crosseyed (as in, put the slightest load on it) it crawls to a halt
08:08:14 <SamanthaD> but... I think I fixed it
08:08:38 <SamanthaD> it did a good imitation of a memory leak though :p
08:08:57 * SamanthaD waits for it to recompile <.<
08:24:02 <SamanthaD> I'm actually really impressed at how lean the OpenTTD codebase is
08:33:30 * SamanthaD is sleepy. Night everyone.
09:10:25 *** kais58__6 has joined #openttd
09:21:10 *** kais58__6 is now known as kais58|AFK
09:37:59 *** Midnightmyth has joined #openttd
09:43:11 *** MatrixCL has joined #openttd
09:45:06 <__ln__> is anyone aware of any protocol for reading timestamp from a realtime clock connected to a serial port?
09:55:10 *** kais58|AFK is now known as kais58__6
10:15:37 <Xaroth|Work> __ln__: man 4 rtc like ?
10:18:32 <__ln__> hmm, that would seem to ignore the details of how the rtc is actually accessed.
10:19:34 <__ln__> what i'm looking for is something like "i send XYZ to a serial port and get the current timestamp in a certain format".
10:19:48 <__ln__> but it's possible such protocol does not exist.
10:20:14 <Eddi|zuHause> i'd expect that to be in the documentation of the clock
10:20:27 <Xaroth|Work> iirc most real-time-clocks send the data in a regular interval
10:20:33 <Xaroth|Work> but I've not had -tha-t much experience with them
10:22:23 <Eddi|zuHause> which is the format used by "radio clocks"
10:22:39 <blathijs> DCF-77 is the actual over-the-air protocol, right?
10:22:53 <Eddi|zuHause> basically, every second you transmit one bit
10:23:16 <blathijs> __ln__: I think there's the NMEA protocol for GPS devices which also includes an accurate time
10:23:29 <blathijs> Eddi|zuHause: Yeah, with short and long bursts of low amplitude
10:23:42 * blathijs built a DCF receiver from scratch once :-)
10:24:29 <Eddi|zuHause> i just read up on it when i was reverse-engineering a timestamp format. which then turned out to be excel-float-thingie
10:26:57 <__ln__> my use case would be building an rtc that connects to a pc through arduino. if it used a commonly known protocol, perhaps software for reading the time would already exist for various OSes.
10:30:03 <Eddi|zuHause> well, besides DCF-77 the only time-related thing i know is NTP
10:32:26 <__ln__> the problem with DCF-77 is that it doesn't work too well over here.
10:37:16 <Xaroth|Work> byte scanning to get the information
10:37:31 <Xaroth|Work> elaborate way of not looking at the admin port/nogo tbqfh :P
10:38:26 <Xaroth|Work> that about sums up my reaction when I saw it
10:42:35 *** sla_ro|master has joined #openttd
11:32:19 *** TheMask96 has joined #openttd
11:35:35 *** sla_ro|master has joined #openttd
11:57:22 *** Tom_Soft has joined #openttd
12:45:02 *** sla_ro|master has joined #openttd
13:02:18 *** Born_Acorn has joined #openttd
13:29:41 *** Alberth has joined #openttd
13:29:41 *** ChanServ sets mode: +o Alberth
15:31:24 *** HerzogDeXtEr has joined #openttd
15:44:08 *** Ristovski has joined #openttd
15:50:51 *** TheMask96 has joined #openttd
16:00:21 *** LordAro has joined #openttd
16:20:05 *** Progman has joined #openttd
16:29:29 *** George|2 has joined #openttd
16:29:29 *** George is now known as Guest122
16:29:30 *** George|2 is now known as George
16:29:37 *** scshunt has joined #openttd
16:41:37 *** frosch123 has joined #openttd
17:06:07 *** kais58__6 has joined #openttd
17:10:50 *** kais58__6 is now known as kais58|AFK
17:32:25 *** mindlesstux has joined #openttd
17:41:45 *** gelignite has joined #openttd
17:45:51 <DorpsGek> Commit by translators :: r25616 /trunk/src/lang (6 files) (2013-07-17 17:45:39 UTC)
17:45:52 <DorpsGek> -Update from WebTranslator v3.0:
17:45:53 <DorpsGek> french - 3 changes by MagicBuzz
17:45:54 <DorpsGek> german - 1 changes by Jogio
17:45:55 <DorpsGek> japanese - 10 changes by guppy
17:45:56 <DorpsGek> korean - 1 changes by junho2813
17:45:57 <DorpsGek> polish - 31 changes by p0358
17:45:58 <DorpsGek> turkish - 6 changes by wakeup
18:08:45 <Rubidium> FS#4934 keeps bugging me
18:09:25 <Rubidium> I really wonder whether the "problem" can be solved at all
18:10:17 <Rubidium> mostly because we can't do the old vs new image check anymore, which means more UpdateVehicleViewport calls which iterates over all windows to mark them dirty
18:10:51 <Rubidium> at least in my simple test it became slower with caching than without
18:11:20 <frosch123> maybe a client-side flag in the vehicle, which says whether it is visible in any viewport?
18:11:58 <Rubidium> would that require doing the same 'in a viewport' check every movement?
18:12:04 <frosch123> set by the viewport when drawing the vehicle, and cleared every 256 frames or so
18:13:02 <frosch123> the goal would be that the flag is not set when a vehicle is definitely not in a viewport
18:13:08 <frosch123> and set if it is maybe in a viewport
18:13:20 <frosch123> (i.e. not considering overlapping windows etc)
18:13:25 <Rubidium> but then you can't clear it
18:13:45 <frosch123> clear it for all vehciles every few seconds
18:14:07 <frosch123> and set it during viewport drawing if the vehicle is nearby the viewport bounds
18:14:22 <Rubidium> at least, if at frame 256 it's cleared it won't be reset (set to true) until there is a reason to draw that part of the image. Since the vehicle is not "in the viewport", that part won't be dirtied
18:14:54 <Rubidium> and as a result the vehicle moves without updating the screen
18:15:00 <Rubidium> even though in the viewport
18:15:37 <frosch123> hmm, ok, so we need to check all viewports every few ticks wrt. what vehicles are visible and set/clear the flag
18:15:46 <frosch123> independent of redrawing
18:16:27 <Rubidium> which makes it kinda pointless
18:16:51 <frosch123> well, it would not resolve any viewport diryting or sprite reslving
18:16:57 <frosch123> it would only use the position hash
18:17:20 <Rubidium> also, since the previous sprite (ID) is not checked against the new one, it will dirty and thus redraw more often than needed
18:18:26 <frosch123> ok, then let's call GetImage for all vehicles in parallel using 4 threads :p
18:18:56 <frosch123> only need to get rid of global temporary registers
18:19:27 *** zeknurn has joined #openttd
18:37:20 <DorpsGek> Commit by rubidium :: r25617 /trunk/src (timetable_cmd.cpp timetable_gui.cpp) (2013-07-17 18:37:13 UTC)
18:37:21 <DorpsGek> -Fix [FS#5655] (r25377): crash when Ctrl+clicking the start date button in timetable window without any orders
18:56:32 *** ntoskrnl has joined #openttd
19:26:47 *** sla_ro|master has joined #openttd
19:41:27 *** sla_ro|master has joined #openttd
19:44:14 *** jamesgo_ has joined #openttd
19:44:19 *** joho^_^ has joined #openttd
19:44:38 *** SpComb^_ has joined #openttd
19:44:47 *** Tulitomaatti has joined #openttd
19:47:09 *** EyeMWing has joined #openttd
19:47:09 *** Kurimus has joined #openttd
19:47:25 *** Terkhen has joined #openttd
19:47:25 *** ChanServ sets mode: +o Terkhen
19:49:41 *** oskari89 has joined #openttd
19:51:45 *** sla_ro|master has joined #openttd
20:26:48 *** Djohaal has joined #openttd
20:51:22 *** SamanthaD has joined #openttd
21:06:32 *** Prof_Frink has joined #openttd
21:23:31 <SamanthaD> Is there some weird reason why it's impossible to mix third rails and normal tracks on the same diagonal?! O.O
21:26:25 <SamanthaD> Oh... I get it. You can't mix monorail/maglev and normal tracks and the NewGRFs that provide third rail hack it in via those features
21:26:40 *** sla_ro|master has joined #openttd
21:26:58 <Rubidium> nobody ever implemented support for more than one rail type per tile
21:27:18 <SamanthaD> You can mix rails and rails with cataneries though
21:27:41 <Rubidium> a tile is either with or without catenary
21:27:49 <SamanthaD> but I just did it...
21:28:05 <Rubidium> some clever-ish drawing routings omit drawing catenary for those very short bits
21:29:03 <SamanthaD> hmm... my electric trains still won't go down it
21:29:42 <Rubidium> just build normal rail, then electrified tracks below/next to it, and then remove the electrified rail. You'll see that some that used to be unelectrified has become electrified
21:30:05 <Rubidium> and those tiles where that happened are exactly the tiles where you added a tile with catenary
21:30:28 <Rubidium> if electric trains don't go over it, there's probably a piece of catenary missing
21:32:18 <SamanthaD> Huh... you're right
21:32:23 <SamanthaD> OH! yeah, I get it now
21:32:44 <SamanthaD> because only half of the "not electrified" track is electrified
21:37:03 *** sla_ro|master has joined #openttd
21:40:14 *** sla_ro|master has joined #openttd
22:05:58 *** tokai|noir has joined #openttd
22:05:58 *** ChanServ sets mode: +v tokai|noir
23:17:21 *** DorpsGek has joined #openttd
23:17:21 *** ChanServ sets mode: +o DorpsGek
23:34:26 *** MatrixCL has joined #openttd
continue to next day ⏵