Back to Home / #openttd / 2009 / 09 / Prev Day | Next Day
#openttd IRC Logs for 2009-09-03

---Logopened Thu Sep 03 00:00:36 2009
01:08-!-Mks [] has quit []
01:19-!-nicfer [~Usuario@] has joined #openttd
01:43-!-MizardX- [] has joined #openttd
01:43-!-MizardX [] has quit [Read error: Connection reset by peer]
01:44-!-MizardX- is now known as MizardX
01:59-!-TheMask96 [] has quit [Ping timeout: 480 seconds]
02:04-!-stuffcorpse [~stuffcorp@] has quit [Remote host closed the connection]
02:05-!-TheMask96 [] has joined #openttd
02:09-!-stuffcorpse [~stuffcorp@] has joined #openttd
02:12-!-Cybertinus [] has joined #openttd
02:28-!-Azrael- [] has joined #openttd
02:33-!-nicfer [~Usuario@] has quit [Read error: Connection reset by peer]
02:41-!-Progman [] has joined #openttd
02:44-!-Progman [] has quit [Remote host closed the connection]
02:56-!-Terkhen [] has joined #openttd
02:56<Terkhen>good morning
03:01-!-Azrael- [] has quit [Read error: Connection reset by peer]
03:16<Xaroth> <<< wrong, but funny as hell :P
03:17<Tefad>wtf poor cdrom
03:17-!-cipi97 [~cipik97@] has joined #openttd
03:18<Tefad>"thanks ssh eject bash"
03:21-!-Cybertinus [] has quit [Ping timeout: 480 seconds]
03:26-!-Cybertinus [] has joined #openttd
03:31-!-Farden [] has joined #openttd
03:43-!-Cybertinus is now known as Guest1207
03:43-!-Guest1207 [] has quit [Ping timeout: 480 seconds]
03:51<cipi97>Hello everybody
04:10-!-Doorslammer [] has joined #openttd
04:13-!-sdafsdf [] has joined #openttd
04:13-!-LadyHawk [] has quit [Read error: Connection reset by peer]
04:14-!-sdafsdf is now known as LadyHawk
04:17-!-Phoenix_the_II [] has quit [Read error: Connection reset by peer]
04:18-!-Phoenix_the_II [] has joined #openttd
04:30<TrueBrain>the interface voor vmware-server is SO BAD
04:30<TrueBrain>I already dislike the vSphere Client blabla
04:30<TrueBrain>but this is not any better
04:33-!-Pikka [~user@] has joined #openttd
04:41-!-reldred1 [~reldred@] has joined #openttd
04:42<TrueBrain>bah, original OSX install CD gives a kernel stack error (because of the missing VT-x, in that case)
04:42-!-sdafsdf [] has joined #openttd
04:42-!-LadyHawk [] has quit [Read error: Connection reset by peer]
04:42-!-sdafsdf is now known as LadyHawk
04:45-!-Pikka [~user@] has quit [Ping timeout: 480 seconds]
04:46-!-Kodak [] has quit [Ping timeout: 480 seconds]
04:54-!-Chris_Booth [] has joined #openttd
05:07<CIA-1>OpenTTD: rubidium * r17399 /trunk/src/window_gui.h: -Fix (r17365): if scrollbar has more capacity than elements clicking on the "scroll down" button asserted (esminis)
05:09-!-Mks [] has joined #openttd
05:23-!-TrogDoor [] has joined #openttd
05:23-!-fjb [] has joined #openttd
05:28-!-Doorslammer [] has quit [Ping timeout: 480 seconds]
05:44-!-TrogDoor is now known as Doorslammer
05:45-!-tokai|mdlx [] has quit [Ping timeout: 480 seconds]
05:47-!-tokai|mdlx [] has joined #openttd
05:49-!-Coco-Banana-Man [] has joined #openttd
05:51-!-Zuu [] has joined #openttd
05:59-!-Chris_Booth [] has quit [Ping timeout: 480 seconds]
06:03-!-Fast2 [] has joined #openttd
06:06<@Rubidium>planetmaker: what does return on OSX (does it actually compile?)
06:08<TrueBrain>Rubidium: just know that on OSX the kernel version isn't that much of an indicator, with all this OSX86 stuff
06:08<@Rubidium>TrueBrain: let us first figure out what it actually prints :)
06:09<@Rubidium>who was using a *BSD in here?
06:09<TrueBrain>Rubidium: well, I can predict if it outputs something, what it would be :) And I just give you an eearly warning :)
06:09<TrueBrain>normally a 9.5.0 kernel means 10.5.5 for example, and 9.7.0 means 10.5.7 .. but with this voodoo kernel, that is all lost and wrong :'(
06:11-!-Polygon [] has joined #openttd
06:11<@Rubidium>hmm, doesn't work on solaris :(
06:12<TrueBrain>what? Why does solaris break uname? :(
06:13<@Rubidium>oh, solaris just returns something different
06:14<@Rubidium>on uname
06:14<@Rubidium>return 1 on success instead of 0 (as per linux man)
06:15-!-Exl [] has joined #openttd
06:15<@Rubidium>bsd claims to return 0 on success too
06:15-!-Zahl [] has joined #openttd
06:18-!-reldred1 [~reldred@] has left #openttd []
06:18<@Rubidium>TrueBrain: anyhow, what does gestalt return for the voodoo kernels?
06:20<TrueBrain>no idea; I just noticed that the version of voodoo-kernels are equal to the vanilla ones, but do things completely different
06:23<planetmaker>Rubidium, I cannot test right now (will tonight). But to my understanding, if you want a OS-detection on mac there's the way I provided in the patch or another which uses the Cocoa framework to query for the version (which then returns the reported OS version. A query for the machine is also somewhere availble in that framework, but it didn't look as detailed as what I found
06:24<@Rubidium>planetmaker: yeah, but that code looked complicated
06:24<planetmaker>the version detection as in the patch now seems an established way.
06:25<planetmaker>I found references to this in various places dealing with that problem.
06:25<planetmaker>or similar implementations
06:25<planetmaker>the cpu detection is a different matter in that respect.
06:25<planetmaker>there must be some way which apple uses itself when calling the "this machine" thing.
06:25<planetmaker>but I couldn't establish what they use there themselves.
06:26<@Rubidium>prolly some cpuid
06:26<planetmaker>might be, yes. But then it should be in the header files / the API documented *somewhere*
06:26<TrueBrain>planetmaker: not everything is documented ;)
06:27<planetmaker>should != is. I know :S
06:28<@Rubidium>planetmaker: cpuid is just some assembly code (so it won't show in the API)
06:28<planetmaker>isn't that something combined from cpu family, cpu type and cpu subversion?
06:30<TrueBrain>do we want to know anything else but the OS version and PPC/x86/x86_64 for OSX?
06:30*fjb is using FreeBSD.
06:30<TrueBrain>the exact CPU type might not be that interesting
06:30<planetmaker>or even only the two variables cputyp, cpusubtype, which are reported by NXGetLocalArchInfo()
06:30<@Rubidium>fjb: what does return? (Does it compile?)
06:30<fjb>I try.
06:31<planetmaker>TrueBrain, Rubidium the query whether big / little endian is used is another part of the struct archinfo
06:31<planetmaker>which I use to query (as last resort) the cpu type
06:31<planetmaker>that'd be easy to include
06:31<planetmaker>and return
06:31<@Rubidium>planetmaker: you can also use gestalt to get PPC/Intel
06:31<TrueBrain>I don't mean BE/LE perse, I mean more the family type
06:31<TrueBrain>(as that also shows 32bit vs 64bit
06:32<SmatZ>wouldn't it fail when running 32bit OS on 64bit CPU?
06:33<SmatZ>or even 64bit OS, but 32bit OTTD?
06:33<TrueBrain>SmatZ: good point, OSX is even more weird in that .. you can run 64bit apps on a 32bit OS :p
06:33<fjb>Compiles and says:
06:33<fjb>OS: FreeBSD
06:33<fjb>OS release: 7.2-RELEASE
06:33<fjb>OS version: FreeBSD 7.2-RELEASE #0: Mon Jun 8 22:09:42 CEST 2009
06:33<fjb>Machine: i386
06:33<TrueBrain>but I believe most of the functions returns the value of the current applications
06:34<planetmaker> <-- on this linux machine it doesn't report the distribution
06:34<TrueBrain>planetmaker: it rarely does :(
06:35-!-Exl [] has left #openttd []
06:35<@Rubidium>planetmaker: looks as expected :)
06:36<SmatZ>test.c:9: warning: implicit declaration of function ‘strerror’
06:36<fjb>I should learn to use pastebin:
06:36<@Rubidium>Gentoo header mutilation?
06:37<TrueBrain>fjb: why is that root@ in there? :p
06:37<fjb>And it compiles without any warning under FreeBSD.
06:37<SmatZ>according to man, strerror is declared in string.h
06:37<fjb>TrueBrain: The kernel was compiled by root.
06:37<TrueBrain>why does that not sound too secure .... :p
06:37<SmatZ>and according to C99 specs too
06:39<fjb>TrueBrain: I see no security risk in copiling the kernel as root. In fackt only root has the rights to write where the kernel sources are stored and the kernel gets compiled.
06:39-!-KritiK [] has joined #openttd
06:39<@Rubidium>so now 'only' Windows is the odd one
06:39<TrueBrain>fjb: what I meant more is that the information is freely available for all local users
06:40<TrueBrain>Rubidium: doens't mingw have a layer for it? :p
06:40*Zuu groans about unresolved external symbols
06:40<fjb>TrueBrain: You mean the information that a user "root" exists on a UNIX type of machine?
06:40<TrueBrain>fjb: no, username, hostname, directory
06:40<Zuu>(in a non-OpenTTD project)
06:40<TrueBrain>I don't see any need for that information to keep in the kernel version
06:41<TrueBrain>(that might have to do I compile kernels on an isolated system and copy them to all production servers)
06:42<fjb>TrueBrain: Only the hostname will differ on any FreeBSD machine. And you can see if one of that differs. That is a strong hint for an unusual setup or even an manipulation.
06:43<fjb>TrueBrain: With the compile location compiled in you could always test if the running kernel is really the one that you made on the isolated system.
06:44<TrueBrain>fjb: there are much easier methods for that
06:45<fjb>TrueBrain: I don't see many easier ways than the output of uname.
06:45<TrueBrain>fjb: well, the info is just useless. It is easy to fake, and doesn't contribute in any way
06:45<TrueBrain>but okay, useless discusion
06:46<fjb>And I see really no security risk in disclosing that information.
06:50<TrueBrain>why oh why does VMWare refuse to load the bootloader of an external HD :(
06:50<CIA-1>OpenTTD: rubidium * r17400 /trunk/src/graph_gui.cpp: -Fix [FS#3172] (r17380): total line of performance rating was calculated wrong
06:56<TrueBrain>almost 17500 ...
06:57<@DorpsGek>SmatZ: Commit by rubidium :: r16384 /trunk/src (10 files in 2 dirs) (2009-05-22 18:56:25 UTC)
06:57<@DorpsGek>SmatZ: -Codechange: move u.effect to EffectVehicle
06:58<CIA-1>OpenTTD: rubidium * r17401 /trunk/src/order_gui.cpp: -Fix [FS#3171] (r17384): order deletion didn't (correctly) update the order window
07:00<@Rubidium>TrueBrain: not sure, but if mingw does MSVC still doesn't have said layer
07:00<TrueBrain>true, but it was just an amuzing thought I was having :)
07:00<@Rubidium>could find references of cygwin having said API though
07:00<TrueBrain>could or couldn't?
07:01-!-KenjiE20 [~KenjiE20@] has joined #openttd
07:01<TrueBrain>Just checking ;)
07:01<TrueBrain>doesn't cygwin emulate everything *nix like? (or so they claim)
07:02<@Rubidium>well, more or less :)
07:04-!-Yexo [] has joined #openttd
07:04<Yexo>good afternoon
07:04<TrueBrain>hello Yexo :)
07:07-!-sdafsdf [] has joined #openttd
07:07-!-LadyHawk [] has quit [Read error: Connection reset by peer]
07:07-!-sdafsdf is now known as LadyHawk
07:09-!-LadyHawk [] has quit []
07:11-!-LadyHawk [] has joined #openttd
07:12<planetmaker>g'day Yexo :-)
07:12-!-R0b0t1 [] has quit [Remote host closed the connection]
07:13<planetmaker>I prepared a list of "funny turnings" places on some airports. I submitted it as a bug to Flyspray in the form of three screenshots with signs in the places.
07:15<Yexo>yeah, thanks :)
07:15<planetmaker>the signs are always a bit above the tile they describe... like signs usually are :-)
07:16<@Rubidium>the metropolitan airport is a big mess :(
07:18-!-tdev [] has joined #openttd
07:19-!-Fast2 [] has quit [Ping timeout: 480 seconds]
07:23<Ammler>indeed, that airport is less effective than the city airport.
07:32<CIA-1>OpenTTD: Yexo * r17402 /trunk/src/script/squirrel.cpp: -Fix (r16425): During every save a few slots on the squirrel stack were leaked
07:33<De_Ghosty>!dl win32
07:34*planetmaker senses a very close skidding by a kick ;-)
07:34<TrueBrain>where is glx ...
07:35-!-De_Ghosty was kicked from #openttd by DorpsGek [Wrong channel. Retry in #openttdcoop. (sorry about the delay)]
07:35-!-De_Ghosty [] has joined #openttd
07:35-!-Fast2 [] has joined #openttd
07:45-!-LadyHawk [] has quit [Quit: [24/8][22:50:18] <@DaZeD> when they invent that device to bitchslap peeps over TCP/IP... I'm SO pre-ordering]
07:47-!-LadyHawk [] has joined #openttd
07:48<CIA-1>OpenTTD: rubidium * r17403 /trunk/src/3rdparty/squirrel/squirrel/ (squtils.h sqvm.cpp):
07:48<CIA-1>OpenTTD: -Fix [Squirrel]: guard against squirrel stack overflows; if assert is enabled
07:48<CIA-1>OpenTTD: assert (catch possible overflow bugs in nightlies/RCs), otherwise just increase
07:48<CIA-1>OpenTTD: the stack's size (don't get into invalid reads/writes in releases)
07:53-!-glx [glx@2a01:e35:2f59:c7c0:314d:5847:b654:a5ee] has joined #openttd
07:53-!-mode/#openttd [+v glx] by ChanServ
07:53<TrueBrain>howdie glx :)
07:54<TrueBrain>VMWare doens't allow any way to boot past that one point ...
07:54<Yexo>planetmaker: about the aircraft turn in the main menu: I can't fix that, the state is already set
07:54<Yexo>please note that it only happens for the first 2 planes that arrive
07:55<Noldo>the bug is in the savegame?
07:56<CIA-1>OpenTTD: rubidium * r17404 /trunk/src/ (company_cmd.cpp graph_gui.cpp): -Change (r17379): silence gcc warning caused by inlining of a virtual function
07:57<Yexo>not really, every aircraft stores the index of the airport node it's heading towards
07:57-!-Kodak [] has joined #openttd
07:57<Yexo>a few revs ago I added 3 entry points for several airports, but planes already flying in old savegames will still go to the original entry point
08:00<planetmaker>Yexo, uh?
08:00<Yexo>planetmaker: run the title game a little longer, only the first 2 aircraft will bounce
08:00<planetmaker>so... in flight it already knows which entry point it goes to?
08:01<planetmaker>ok. thanks :-)
08:01<planetmaker>I propose to update the title game then by just distributing a version which ran for a bit longer :-)
08:01<Noldo>planetmaker: or just hack it!
08:01<planetmaker>Noldo, boring. Then rather what I prepared as title game ;-)
08:04-!-Fast2 [] has quit [Ping timeout: 480 seconds]
08:08-!-Phoenix_the_II [] has quit [Read error: Connection reset by peer]
08:08-!-Phoenix_the_II [] has joined #openttd
08:09<Ammler>planetmaker: some "devs" misuse the title game as "old-save-game" compatibilty test.
08:11<CIA-1>OpenTTD: yexo * r17405 /trunk/src/ (aircraft.h aircraft_cmd.cpp saveload/vehicle_sl.cpp): -Fix (r100): aircraft shouldn't be allowed to make turns bigger then 45 degrees while in flight
08:12<Ammler>yexo, also any chance to "fix" the income "bug" when using 1/1 speed?
08:13<Yexo>not in any recent future by me
08:13<Yexo>assuming that 'bug' is 'game is unbalanced, aircraft earn too much'
08:14<Ammler>yeah, that is why I used " ;-)
08:15<Ammler>one possibilty is to rise the loading time
08:16<Yexo>you can do that with a newgrf ;)
08:16<Ammler>yeah, I did
08:17<Ammler>but I guess, I wasn't successful from same reason, you don't like to fix that in trunk.
08:18<Ammler>my idea was to make runnings costs *4 and loading time *4
08:18<Ammler>but then, it could happen, that early small trains aren't able to make any profit.
08:19<Zuu>Since 1/4 is default, how is changing to 1/1 casuing planes becomming (more) unbalanced a bug?
08:19<Ammler>and rising loading time, you need to do that for every single vehicle, it isn't just changing basecost, so very complicated for supporting other newgrfs.
08:20<Ammler>Zuu: "
08:21<Yexo>Ammler: I don't like to change it in trunk because it's only a tiny part of the bigger problem "game balance"
08:21<Ammler>Zuu: you could say, the "feature" got unfished to trunk...
08:22<Zuu>The feature of faster planes was unfinished because faster planes should be slower to load? - Now that doesn't really make sense!
08:22<Ammler>Zuu: nvm.
08:22<Ammler>I am kinda sure, you are aware of the issue :-P
08:23<Zuu>Or is the unloading time increased because people become more seasick on faster planes? ;-)
08:29-!-Progman [] has joined #openttd
08:31<planetmaker>he :-) fix(r100) - like that, yexo :-)
08:33<planetmaker>Ammler, I'm aware of title game = old save test game.
08:33<Yexo>planetmaker: thanks :)
08:33<Yexo>but it means I have to fix the airport holding stack positions again :(
08:34<planetmaker>he... most things aren't free, are they? ;-)
08:34<Yexo>hello z-MaTRiX
08:34<Ammler>Yexo: why do you fix those things, shouldn't that be replaced by your NoAir branch ;-)
08:34<planetmaker>Ammler, the only way to "fix" this issue is to actually create a legacy repository with test cases for OpenTTD
08:35<Yexo>Ammler: for now I leave the airports in that branch intact
08:35<planetmaker>Might not be a bad idea anyway :-)
08:35<Yexo>I'm not sure if I'll be moving all existing airports to newgrf
08:35<Yexo>seems like a lot of wasted time
08:36<planetmaker>There'd be no good reason to do so anyway IMO
08:36<planetmaker>except maybe code cleanup ;-)
08:36<Yexo>and even if I do that, having the airports fixed now means I can just take the fixed version then and convert it
08:37<Yexo>planetmaker: can you test if this fixes the second problem of FS#3169 (the turn in the city airport?)
08:37<planetmaker>but then: some default airports have to remain. Or the air traffic would become impossible.
08:37<Yexo>planetmaker: moving to newgrf might also mean "moving to openttd(w).grf"
08:37<Ammler>like noai, pm.
08:38<Ammler>or that :-)
08:38<planetmaker>Yexo, that'd be ok, yes. But there need to remain default airports :-)
08:38<planetmaker>as there's also, always a default train station and bus station etc pp
08:38<Yexo>of course, otherwise old savegames can't be loaded
08:39<planetmaker>indeed also true.
08:39<Ammler>planetmaker: the nfo is in openttd.grf
08:39<Yexo>@seen pikka
08:39<@DorpsGek>Yexo: pikka was last seen in #openttd 12 hours, 32 minutes, and 35 seconds ago: <Pikka> seeya
08:39<Yexo>ok, not today
08:39<Ammler>hmm, how does opengfx know about changes in openttd.grf?
08:40<planetmaker>Yexo, I have to stave off you, too. I'll only be able to test at home tonight
08:40<Yexo>that's no problem
08:40<Ammler>Rubidium: shouldn't openttd.grf be loaded always?
08:40<Yexo>I'll try to fix the other problems too and give you one diff to test then :)
08:41<planetmaker>One diff to find them, one diff to bind them, one diff to fix them all? ;-)
08:41<Ammler>he, did we ever test, what happens, if the base set uses a incomplete extra grf?
08:41<@Rubidium>openttd[dw].grf shouldn't be used for game data
08:42<@Rubidium>esp. not airports because you can't be sure all parties have exactly the same loaded
08:42<planetmaker>they're only window decorations and buttons etc ?
08:42-!-Progman [] has quit [Remote host closed the connection]
08:43<Ammler>no, water features, waypoints
08:43<Ammler>or is that all opengfx, only?
08:43<planetmaker>water is afair in _extra
08:44<Ammler> <-- those aren't game data?
08:45<@Rubidium>what's game data of that?
08:45<Ammler>where do you make the boarder between?
08:45<@Rubidium>they're all graphics minus the 2cc colour mapping
08:45<Ammler>rivers, aquaducts, shore etc.
08:45<+glx>graphics only
08:45<@Rubidium>but without the graphics it should work, minus the big fat question marks you'll see if it ain't loaded
08:46<+glx>you can't have townnames in openttd.grf for example
08:46<Ammler>ah, ok, I see.
08:46<Ammler>maybe we should split opengfx in those too.
08:49-!-goodger [] has quit [Remote host closed the connection]
08:54-!-Fuco [~dota.keys@] has joined #openttd
09:18-!-sdafsdf [] has joined #openttd
09:21-!-LadyHawk [] has quit [Ping timeout: 480 seconds]
09:21-!-sdafsdf is now known as LadyHawk
09:23-!-[1]Mark is now known as Mark
09:34-!-Cybert1nus [] has joined #openttd
09:37-!-Pikka [PikkaBird@] has joined #openttd
09:45-!-Pikkaa [PikkaBird@] has joined #openttd
09:47<Pikkaa>how do's, chaps
09:48<Yexo>hello pikka :)
09:48<Yexo> <- your airport
09:49<Pikkaa>ooh :)
09:49<Yexo>few comments: Airport prop 9 needs byte with rotation before the actual tile table (directly after the byte count)
09:49<Pikkaa>hello, I was just reading the log
09:49<Yexo>you don't set prop 18
09:49<Yexo>and the node table is commented out
09:49<Pikkaa>it is?
09:50<Pikkaa>I thought I fixed that
09:50-!-Pikka [PikkaBird@] has quit [Ping timeout: 480 seconds]
09:50<Pikkaa>renum must have commented it out again
09:50<Noldo>it's so tiny!
09:50-!-Pikkaa is now known as Pikka
09:50*Rubidium wonders about airports on a hill :)
09:51<Yexo>and your in-flight nodes ahve a hight of 256, while the normal holding stack height is 150
09:51<Yexo>Rubidium: should work fine
09:51<Pikka>I couldn't remember what the normal maximum altitude was :)
09:52<Pikka>Airport prop 9 needs byte with rotation before the actual tile table <- prop 0B?
09:52<Pikka>and I do set property 18, it's after the node table :)
09:52-!-MizardX [] has quit [Read error: Connection reset by peer]
09:52<Yexo>no, sorry, prop 0A
09:52<Yexo>the tile layout one
09:53-!-MizardX [] has joined #openttd
09:53<Pikka>okay, where does the rotation byte go?
09:53<Yexo>rotation 0 = north, 2 = east, 4 = south, and 8 = west
09:53<Yexo>directly after the byte count
09:54<Yexo>it's 0A 01 (1 layout) \Dbyte_count \brotation
09:54<Yexo>28 * 48 00 0D 01 01 00 0A 01 \b37 00 00 00 <- after that
09:55<Yexo>maybe that's why renum commented out the node table
09:56<Pikka>I doubt it... D:
09:56<Pikka>okay, that's fixed... compiling
09:56-!-Kodak [] has quit [Ping timeout: 480 seconds]
09:56<@Rubidium>Yexo: I'd like to see courchevel airport then :)
09:57<Yexo>hehe :)
09:57<@Rubidium>525 m runway, 18.5% gradient
09:57<Pikka>rubidium : it could be done :P
09:59<Pikka>oh wait, I see why it broke :P
09:59<Pikka>it doesn't like negative numbers in escape sequences >_>;
10:07<Pikka>yexo: for the updated nfo, and I pm'd you the grf
10:07<Yexo>thanks :)
10:07*Yexo goes testing it ingame
10:12<Yexo>as soon as an airport enters the state machine it enters an infinite loop
10:15<Pikka>that's not good :)
10:15<Yexo>pos = 9, state = 20
10:16<Pikka>pos = node?
10:16-!-green-devil [] has joined #openttd
10:16<Yexo>but most likely it's because my implementatino is incomplete
10:16<Yexo>and also var 10/11 are not implemented according to spec :(
10:17<Pikka>*nods* ah
10:17<Pikka>all it checks at that node is the iteration count in var 11, so...
10:17<Yexo>iteration count = high byte, not high nibble of var 11
10:18*Yexo fixes
10:20-!-Terkhen [] has quit [Quit: ...]
10:21-!-Phoenix_the_II [] has quit [Read error: Connection reset by peer]
10:21-!-Phoenix_the_II [] has joined #openttd
10:22<Yexo>Pikka: you're testing var 11, while that's documented as "current rail tool type (for station callbacks) "
10:23<Yexo>what is var 11 in the spec is var 18 in my implementation (extra callback info 2)
10:23<Pikka>oops. want me to change that?
10:23<Yexo>I think var 18 is better
10:23<@Rubidium>oh... got to love when looking for MSVC API stuff regarding OpenTTD code that the actual code shows up before something useful in the google search
10:26<Yexo>oh, and I need to implement type 82 for airport varaction 2
10:27<Yexo>new loop: node 11 state 20 (decimal)
10:27<Pikka>decimal node 11? node 0B?
10:28<Yexo>node 0B yes
10:28<Pikka>oops, I missed an 11 -> 18
10:28<Pikka>redownload :)
10:29<Yexo>next loop: node 0D state 24
10:30-!-green-devil [] has left #openttd []
10:30<Pikka>hmm, node D, more complex...
10:31<Pikka>this does some 7C stuff, that's all implemented?
10:31<Yexo>aha, no
10:31<Yexo>will fix that
10:32<@Rubidium>that ought to be copy-paste-ish :)
10:33<Yexo>case 0x7C: return st->psa.Get(parameter); <- that was all :)
10:34<Yexo>Pikka: it always returns 0x0118
10:34<Yexo>can you update the nfo on the wiki so I can have a look at that?
10:34-!-Progman [] has joined #openttd
10:36-!-Phoenix_the_II [] has quit [Read error: Connection reset by peer]
10:36<Pikka>it is updated
10:36-!-Phoenix_the_II [] has joined #openttd
10:36<Pikka>I have a "7D" in there for some reason.. typo :D
10:37<Pikka>redownload D;
10:40-!-Fuco [~dota.keys@] has quit [Ping timeout: 480 seconds]
10:41<@Belugas>hihihih i can just imagine the guys "Ho. there is a link for a new grf! Cool!!!---grab ---- load-- not work booooo!"
10:41<@Belugas>date to report bug!
10:41*Belugas goes back in hybernation
10:41<@Belugas>is it y or i?
10:44<planetmaker>Belugas, it's "i" ;-)
10:45<planetmaker>from latin, hiber
10:45<planetmaker>= winter
10:45<Eddi|zuHause><Yexo> next loop: node 0D state 24 <-- you should probably build some advanced FSM-Debug features for future GRF developers ;)
10:46<Yexo>Eddi|zuHause: indeed :)
10:46<Yexo>but for now loops are as likely because of my (lack of) implementation as because of a newgrf
10:46<planetmaker>:-) sounds sensible, yes
10:47<planetmaker>(referring to needed fsm debug tool)
10:47<Yexo>stepping through the code in debug mode == nice debugger :)
10:47-!-cipi97 [~cipik97@] has quit [Ping timeout: 480 seconds]
10:47<Pikka>btw, I have a plane-related request for trunk, if it's not been done already ;) callback 36 for aircraft capacity
10:50<Yexo>for that you'll probably need frosch
10:51<Pikka>k :)
10:52<fjb>Why does the factory close down when the first train supplying it just came in sight? :-(
10:53<@Rubidium>because the company went bankrupt
10:54<fjb>They are stupid to do that in that moment of history.
10:54<Yexo>Pikka: I was under the impression that action 2 IDs needed to be unique per feature, but in your newgrf that clearly isn't the case
10:55-!-Fuco [~dota.keys@] has joined #openttd
10:55<Yexo>so if that isn't true, what varaction2 will be chosen if 2 of them have the same ID?
10:55<Yexo>simply the last defined one before the reference?
10:56<Pikka>the "next" one, reading from the bottom
10:56<Yexo>yes, ok :)
10:56<Pikka>if they need to be unique per feature, you'd run out of 'em pretty quick ;)
10:57<Yexo>that was what I was afraid of
10:57<Yexo>I was already wondering why that didn't happen ;)
11:04<Yexo>Pikka: can you explain sprite 44? To me it reads like an advanced varaction2 with as operator DF, but that isn't in the list of defined operators
11:05<Yexo>oops, sprite 45
11:06<Pikka>7C 01 is var 7C
11:06<Yexo>I got that
11:06<Pikka>60 is advanced + shift-and-add-divide
11:06<Pikka>DF is the and
11:06<Pikka>20 is the add, \b1 is the divide
11:06<Yexo>ah, the and
11:07<Pikka>\2sto is the operator
11:07<Yexo>0E \2s or \2sto (a) var7D[val2] = val1, result = val1 <- is that correct?
11:07<Yexo>it lists var 7D, not var 7C
11:08<Pikka>crap ^^;
11:09<Pikka>yeah, I should use 10 instead of \2sto, my bad
11:09*Yexo is happy this was not a problem of his implementation :)
11:10<Pikka>DaleStan: can we have an escape code for operator 10? \2stp, perhaps?
11:10*Pikka changes to 10s
11:10<@Rubidium>Yexo: be happy he can't complain that it works in TTDP but doesn't work in OTTD :)
11:10-!-ctibor [~quassel@] has quit [Ping timeout: 480 seconds]
11:10<planetmaker>haha :-)
11:11<Pikka>there, grf updated
11:11-!-tux_mark_5 [] has joined #openttd
11:15-!-Nickman87 [] has joined #openttd
11:19<Yexo>Pikka: you're still using var 11 instead of var 18 in sprites 43 and above
11:21<Pikka>fixed :o
11:22<Yexo>the aircraft is now flying in circles above the airport
11:23<Yexo>shouldn't it land?
11:23<Pikka>probably! :P
11:23<Pikka>but circles is a start :P
11:24<Yexo>true :)
11:24<Pikka>lessee.. node 0D...
11:24<@Rubidium>so it's still in an infinite loop; I thought you fixed that ;)
11:25<Pikka>umm.. I assume the airport is initialised with its persistent data = 00000000? :o
11:25<Yexo>Pikka: yes
11:25<Pikka>then it's sprite 46...
11:26<Yexo>7c[1] == 0x20
11:26<@Rubidium>hmm, you're using the persistent data for locking purposes? Have you thought how to unlock when a crashed aircraft is cleared?
11:27<Yexo>Rubidium: run the callback with a parameter that the aircraft crashed?
11:27<Pikka>rubidium: I haven't thought about crashes yet. I assume the airport will have to be told that an aircraft has been cleared somehow, regardless of what system is used?
11:27<Pikka>or we could just remove crashes altogether ;)
11:27-!-tokai|mdlx [] has quit [Ping timeout: 480 seconds]
11:28<Yexo>Pikka: it's not a problem of clearing the aircraft, it's a problem of how to reset the correct bits in the persistent data
11:28<Yexo>only the newgrf can do that
11:29<Pikka>yes, then. the aircraft runs the callback when it is removed...
11:30<Pikka>hmm @ 7c[1] == 0x20 ... it thinks there's already an aircraft approaching the runway.
11:30<Pikka>oh, wait
11:30<Pikka>I see
11:31<Pikka>it sets the approach flag later in the chain
11:31<Pikka>I guess it needs an iteration check before checking the flags :o
11:31<Pikka>and will need them a few more places.. this'll take a minute. :]
11:32<Yexo>what about sprite 41?
11:32<Yexo>shouldn't the and byte be 0F, not FF?
11:32<Pikka>I fixed some of those, missed that one, thanks :)
11:33-!-tokai [] has joined #openttd
11:33-!-mode/#openttd [+v tokai] by ChanServ
11:34-!-Lakie [~Lakie@] has joined #openttd
11:38<Pikka>... crap. okay, that was all the wrong way around.
11:38*Pikka starts again
11:41-!-Kodak [] has joined #openttd
11:45<Pikka>okay, I'm sure I've missed something
11:47<Pikka>grf updated
11:48*Pikka waits for the distant sounds of explosions
11:49<_ln>what is the policy with headlights in Germany?
11:49<Doorslammer>Headlights must be present
11:50-!-stuffcorpse [~stuffcorp@] has quit [Quit: leaving]
11:50<Doorslammer>Oh, and working
11:50-!-Mucht [] has joined #openttd
11:50<_ln>Doorslammer: your hostname implies that you drive on the wrong side of the road, so can i believe you?
11:51<Doorslammer>I have no idea how you derived that one
11:51<Doorslammer>But yes, you may believe me ;)
11:52<Yexo>Pikka: it makes some very strange turns during/after landing
11:52<Yexo>and then openttd crashes when it tries to load
11:53<Pikka>very strange, eh? :D
11:53-!-nicfer [~Usuario@] has joined #openttd
11:54<Yexo>the plane is loading :)
11:54<_ln>is there someone who has a german driving license?
11:55<Pikka>what will it do after loading? D:
11:55<Yexo>in front of the hangar, faced south-west
11:55<Pikka>sounds about right :)
11:55<Yexo>for some reason it won't stop loading
11:55<Pikka>ah :o
11:55<Yexo>pressing go-to-depot worked
11:55<Yexo>but it won't leave the depot either
11:56<Doorslammer>Pfff, that will be the standby passengers going missing
11:56<planetmaker>_ln, what about those?
11:57<Yexo>Pikka: if I build a vehicle in the hangar of your airport, then order it to go to anothe rairport it starts loading in front of the hangar
11:57<_ln>planetmaker: when is it mandatory to use headlights? is it optional sometimes? is it forbidden sometimes?
11:58<planetmaker>_ln, headlights = turning on the lights as you would in the night? Or is it some other meaning which eludes me?
11:58<_ln>planetmaker: yes, turning on the lights of the car to the same setting you could use in the night.
11:58<Pikka>Yexo, what's the var 10? it should be 03 if it wants to go to another airport
11:58<Pikka>if it's 00, it will load
11:59<planetmaker>you may drive always with light switched on. You have to, if light conditions require it. E.g. in the night or in tunnels.
11:59<Doorslammer>Normally, headlights are optional in the day and mandatory at obvious times are they not?
11:59<Doorslammer>Maybe in rain they are mandatory?
11:59<planetmaker>or possibly when heavy rain comes down.
11:59<planetmaker>but no hard condition
11:59<Doorslammer>Its the foglights that are no no if conditions dont ask for them
12:00<Doorslammer>Try telling that to anyone in a Hyundai though
12:00<Eddi|zuHause>_ln: the general rule is that you may only do it when you can't possibly disturb someone ahead of you, and only outside of towns/villages
12:00<planetmaker>visibility < 100m or they must be off
12:00-!-Belugas [~belugas@] has quit [Read error: Connection reset by peer]
12:00<_ln>Eddi|zuHause: i'm not talking about the long distance lights though
12:00<Eddi|zuHause>oh, then i misunderstood you
12:01<Doorslammer>You mean dipped headlights?
12:01<Yexo>Pikka: that is the problem indeed
12:01<Eddi|zuHause>_ln: you must have them on during the night, and you have to have them on during the day in the winter months, although that rule is currently in a transition state where it is not enforced yet
12:02<planetmaker>Eddi|zuHause, you may have them switched on whenever you like. There's no rule about having them on.
12:02<planetmaker>Only for motor cycles. they have to. Always
12:02<_ln>the vast majority of cars on the Autobahn did have at least some lights on during daytime.
12:02<Eddi|zuHause>"may" != "have to"
12:03<planetmaker>Actually, I'm required to switch them on, if I drive with a state-owned vehicle
12:03<Doorslammer>_In: Some cars also have what you call "marker/day lights"
12:03<planetmaker>whatever the time of day may be
12:03<planetmaker>Eddi|zuHause, I'm well aware of that difference
12:03<Doorslammer>Which aren't headlights per say, but do stay on permanently
12:03-!-Belugas [~belugas@] has joined #openttd
12:03-!-mode/#openttd [+o Belugas] by ChanServ
12:04<Eddi|zuHause>_ln: the new cars have switches that automatically turn off the lights when you get out of the car, so it's easier to just have them always switched on
12:04<_ln>in finland the rule is quite simple; you always need to use lights.
12:04<Eddi|zuHause>a few years ago, you would have been shouted at when you have lights on during the day
12:04<Yexo>Pikka: after taking off the aircraft flies in circles instead of leaving the statemachine
12:04<Doorslammer>If you happen to own a crapload of 30 year old bunkys that tend not to tell you when headlights are on...
12:04<Eddi|zuHause>but since they introduced the new regulations about winter, it has got more and more common
12:04<Doorslammer>Remember to switch them off
12:05-!-stuffcorpse [~stuffcorp@] has joined #openttd
12:05<_ln>i have the impression that in some european country (perhaps spain?) it would be forbidden to use lights during the day, but can someone confirm this true or false?
12:06<Doorslammer>I would have thought that false
12:06<Eddi|zuHause>i have never heard of such a thing
12:06<Pikka>var 18 again (sorry, I meant 18 before, not 10)
12:07<Pikka>sprites 52-54...
12:07<_ln>at least on Gran Canaria there was always a traffic sign after a tunnel with an image of headlights, and a '?' next to it. that doesn't of course prove anything.
12:07-!-pavel1269 [] has joined #openttd
12:08<Eddi|zuHause>_ln: these are all over the place, also in germany
12:09<Doorslammer>I would consider headlights in a tunnel most useful
12:09<Doorslammer>Considering I wouldnt be able to see my speedo in the dark
12:10<_ln>there are cars whose lights are always on (regardless of the position of the switch), so yes it would be a little tricky if those were illegal in some EU countries.
12:10<Yexo>Pikka: sorry, it was a problem in my code
12:10<Doorslammer>I still doubt there is a EU country with that as illegal
12:11<Doorslammer>There is one thing concerning headlights in the EU
12:11<Eddi|zuHause>_ln: in the military, the rule was that lights always have to be turned on (that was about 9 years ago)
12:11<Doorslammer>UK cars must have some sort of adjustment to theirs if they are to operate in EU
12:11<Doorslammer>And vice versa if EU cars go into UK
12:12<Doorslammer>I believe its to do with the differences of which side you sit on and the angle they have to be in respective countries
12:12<Eddi|zuHause>yes, because right-side lights shine to the right, and left-side lights shine to the left. if you go on the wrong side, you disturb the people approaching you
12:13<_ln>Doorslammer: last time i checked, UK was part of EU.
12:13<Doorslammer>Continental cars, then
12:14-!-frosch123 [] has joined #openttd
12:16-!-goodger [] has joined #openttd
12:19-!-Aankhen`` [~foo@] has joined #openttd
12:24-!-Progman [] has quit [Remote host closed the connection]
12:28<Yexo>Pikka: your airport works :-D
12:29<Pikka>with multiple aircraft? :P
12:29<Yexo>haven't tested that et
12:29<Yexo>I'm compiling a release build now so you can test it yourself :)
12:30<Pikka>great :D
12:30<Doorslammer>Oh? An aerodrome you say?
12:31<Pikka>don't say nuffink!
12:32<Doorslammer>Silence it is, then
12:33-!-HerzogDeXtEr [~Flex@] has joined #openttd
12:34<Pikka>shhh ;)
12:35<Yexo> <- there you go
12:37<Pikka>cheers :)
12:38<Yexo>it doesn't work with multiple aircraft
12:38-!-HerzogDeXtEr [~Flex@] has quit [Read error: Connection reset by peer]
12:38<Yexo>I have 3 airports loading at the same loading bay
12:38<Pikka>my fault, I'm sure :)
12:38<Pikka>I'll play with it, see what I can do
12:39<Yexo>there is some (not much) debug output at debug level grv=2
12:39<Yexo>is there a specific reason you're using 7C[01] instead of 7C[00]?
12:40-!-HerzogDeXtEr1 [~Flex@] has quit [Ping timeout: 480 seconds]
12:40-!-HerzogDeXtEr [~Flex@] has joined #openttd
12:40-!-glx [glx@2a01:e35:2f59:c7c0:314d:5847:b654:a5ee] has quit [Quit: bye]
12:41<Pikka>hah.. interesting
12:41<Pikka>I must have a few of the node coordinates wrong ;)
12:42<Pikka>or.. hmm
12:42<Pikka>I think it may be following the helicopter nodes.. perhaps I have something the wrong way around :)
12:43-!-|Jeroen| [] has joined #openttd
12:43<Yexo>no, that's probably my fault
12:43<Yexo>Type 82 within the callback gets the variables of the aircraft which triggered the callback. <- that's not implemented yet
12:44<Pikka>oh, right
12:44<Yexo>trying to access any type 82 variable will return 0
12:44<Pikka>okay, it's something to work on, anyway. thanks! :D
12:45<Pikka>ooh, it crashed :)
12:45<Yexo>doesn't really surprise me
12:46-!-Terkhen [kvirc@] has joined #openttd
12:47<Yexo>hello Terkhen
12:47<Zuu>Hello Terkhen
12:48<Terkhen>for better or worse, I just finished my exams
12:48-!-Mega [~Mega@] has joined #openttd
12:48<frosch123>for today? for this month? for this year? for life?
12:48<Ammler> <-- bug or feature?
12:49<frosch123>Ammler: the colour?
12:49-!-Pikka is now known as Pikka|afk
12:49<Ammler>I removed the raods, after some time, the town build it again.
12:50<Terkhen>for this year :P
12:51-!-glx [glx@2a01:e35:2f59:c7c0:30a3:4987:8aa5:d71d] has joined #openttd
12:51-!-mode/#openttd [+v glx] by ChanServ
12:51<Yexo>frosch123: for the newgrf airport state machine callback I'd like var 82/86/8A to return vehicle variables, but I can't figure out how to call VehicleGetVariable from within AirportGetVariable
12:51<Yexo>should I make a new ResolverObject?
12:52-!-Mega [~Mega@] has left #openttd []
12:52<frosch123>i guess you are the first with a non-trivial related object :)
12:52-!-tokai [] has quit [Ping timeout: 480 seconds]
12:54-!-goodger [] has quit [Ping timeout: 480 seconds]
12:55-!-tokai [] has joined #openttd
12:55-!-mode/#openttd [+v tokai] by ChanServ
12:55<DaleStan><Pikka|afk> can we have an escape code for operator 10? \2stp, perhaps? <-- Immediately, assuming your copies of renum and grfcodec output "// Escapes:" lines. Just take grfcodec's version, find the second "2+" in the line of "2+ 2- 2< 2> ..." and change it to 2stp, 2psto, or whatever.
12:57<frosch123>Yexo: I guess split VehicleGetVariable into two functions with a new one taking a vehicle, a variable and - hmm - "info_view" :s
12:58<DaleStan>With NFORenum's version, again change the second "2+", but there's only one line.
12:58<planetmaker>you asked for a test :-)
12:59<Yexo>frosch123: if possible the 'info_view' should be available too (assuming info_view == vehicle is not build yet)
12:59<frosch123>ah, for deciding whether a vehicle can be built?
13:02<frosch123>hmm, i have no good idea currently. maybe just trash the union and make everything always present
13:02<Pikka|afk>thanks DaleStan
13:03<DaleStan>But since you're the only one to request a specific escape, there's a pretty good chance it'll go in soon.
13:04<frosch123>hmm, or does ResolverObject generally need splitting into current/related? e.g. grffile, psa etc. might also suddenly make sense for the related object
13:04<planetmaker>Rubidium: using string.h it compiles with this result:
13:05<Yexo>frosch123: maybe creating a new ResolverObject is the best option, then calling NewVehicleResolver before VehicleGetVariable
13:05<planetmaker>The version certainly is not satisfactorily
13:06<frosch123>Yexo: if you want easy syncing it might be a good temporary solution. but on the long run i don't like it :)
13:07<Yexo>I agree on that, but I'm still going for that solution now because it's a) easy to code and b) easy to sync
13:07<frosch123>e.g. stuff like "last_value" are unique
13:07<frosch123>hehe, yeah, better go with a separate object for now :)
13:09-!-Pikka|afk is now known as Pikka
13:28-!-Azrael- [] has joined #openttd
13:31<Pikka>I took out the helicopter stuff and now planes get stuck on the runway when they land. :) and it's definitely not getting the speedclamp/movement state stuff right... :/
13:31<Pikka>I may have to go back and think my logic through from the start
13:31<Pikka>get planes moving correctly first, then do the blocking...
13:34-!-Terkhen [kvirc@] has quit [Quit: ...]
13:36-!-z-MaTRiX [] has quit [Quit: rehashing]
13:45<@Belugas>hehehe... looks like Pikka willnow be able to answer the question "How about making airports block-like user-buildable?" ;)
13:45<CIA-1>OpenTTD: translators * r17406 /trunk/src/lang/hungarian.txt:
13:45<CIA-1>OpenTTD: -Update from WebTranslator v3.0:
13:45<CIA-1>OpenTTD: hungarian - 2 changes by alyr
13:45<Pikka>the answer? make a grf! :D
13:45<Pikka>that's user-buildable, right? ;)
13:47<@Belugas>according to most users, grfs are evil . They want buttons to push and tiles to drop
13:48<pavel1269>yeah :P
13:48<@Belugas>pavel1269, that does not mean i agree with that point of view ;)
13:49<@Belugas>to me, grfs are the proper way to go
13:49<pavel1269>for me, grf is the way to change already implemented things, not add new ones ...
13:50<@Belugas>everything else is either incredibly difficult to do, either frustrating for the poor souls who will complain that their beloved airports lock up tight, or either too lazy to actually build one
13:50<pavel1269>but still, grfs are evil :P
13:50<@Belugas>there you are wrong, my dear
13:50<DaleStan>pavel1269: We are changing already implemented things. The current airports are already implemented.
13:50<@Belugas>if they are already implemented, it means that somehow along the way, it has to be added ;)
13:51<pavel1269>yeah, and you are creating new ones, with your own state machine or however it is called, okay ... :-)
13:51<pavel1269>with this, i dont have a problem ;-)
13:51-!-Zahl_ [] has joined #openttd
13:51<@Belugas>and if they are "evil", how come averyone is actively trying to find the lastest?
13:52-!-tdev [] has quit [Quit: Leaving]
13:52<@Belugas>it's just that people are not ready to dwelve into that complexity. thus... evil...
13:53<DaleStan>As Someone once said: it seems to me that most of the opposition to NFO in OTTD is either (a) "I didn't design it so it must be crap" or (b) "I have no idea how it works so it must be crap"
13:54<Eddi|zuHause>imho, the state machine thing can be extended to modular airports, but these would never be as efficient as a handcrafted full-airport state machine
13:54<Eddi|zuHause>there are of course a few problems that go with this
13:55<Eddi|zuHause>and some of this stuff will have to be addressed when going for newgrf bus/tram stations
13:55<Yexo>DaleStan: to make nforenum think var 7C is valid for feature 0D, is adding "\x7C\x84\x0F" just before the "\x80\x80" line in _dat2v enough?
13:56<DaleStan>Assuming it's the correct 80 80, yes.
13:56-!-Doorslammer [] has quit [Quit: I'll get you next episode, Inspector Gadget! NEXT EPISODE!]
13:56<Yexo>ok, thanks
13:57<DaleStan>By the way, "feature 08" was co-opted for town variables.
13:58-!-Grelouk [] has joined #openttd
13:58-!-Zahl [] has quit [Ping timeout: 480 seconds]
13:58-!-Zahl_ is now known as Zahl
13:58<@Belugas>yup yup yup
13:59<Yexo>how is that related? Iwas talking about feature 0D
13:59<Yexo>or I don't understand what you want to say
13:59<Grelouk>I have a problem with the usa scenario, someone can help me ?
13:59<Yexo>hello Grelouk
14:00<DaleStan>Well, if type 82/86/8A will reference town variables, then the first byte of the feature 0D section should be \x08
14:00<Yexo>but only if you state your problem
14:00<Grelouk>I can build, but i can't buy any transport
14:01<Yexo>DaleStan: isn't the first byte the feature number?
14:02<Yexo>Grelouk: what year are you in?
14:02<Eddi|zuHause>Grelouk: then you have the wrong starting year, or no vehicle set which does not support early start
14:02<Yexo>that's your problem, strart in a later year
14:02<Yexo>or use the cheat menu to go forwards in time
14:03<Eddi|zuHause>Grelouk: for a USA scenario, you could use US-based vehicle sets, e.g. NARS
14:03<Grelouk>Which is the year i'll have vehicles ?
14:04<Yexo>with default vehicle set 1925 iirc
14:04<Eddi|zuHause>the first default vehicle comes 1925ish, but i'd recommend not starting before 1950
14:04-!-nicfer [~Usuario@] has quit [Read error: Connection reset by peer]
14:04-!-snorre_ [] has joined #openttd
14:06-!-snorre [] has quit [Ping timeout: 480 seconds]
14:09-!-Azrael- [] has quit [Ping timeout: 480 seconds]
14:10<Grelouk>Ok thx :)
14:12<DaleStan><Yexo> isn't the first byte the feature number? <-- No, it's number of related feature.
14:12<@Rubidium>planetmaker: you should've redownloaded the new test.c (that fixed your compile error)
14:13<@Rubidium>planetmaker: though the result looks useable (although some people may go nuts)
14:13<Yexo>DaleStan: I see now, thanks
14:13<Grelouk>Some maps are really hug
14:15<@Belugas>and we love to hug them too :)
14:18<Eddi|zuHause>the insane part is, that the USA map is not based on a heightmap :p
14:23<@Belugas>nope, indeed... it's based on a ninemap
14:30<Eddi|zuHause>you're misplacing "h"s again ;)
14:31<Eddi|zuHause>i have excellent news, my engine finished its first round without stopping
14:32<Eddi|zuHause>there are a few problematic strips of track left, where it gets no power, though
14:34-!-Terkhen [] has joined #openttd
14:36<Yexo>DaleStan: is there an explanation somewhere about the format of _dat2v? As far as I understand it now it's (per var) 1 byte var number, 1 byte size and for 60+ vars 1 byte max parameter value
14:36-!-PhoenixII [] has joined #openttd
14:36-!-Phoenix_the_II [] has quit [Read error: Connection reset by peer]
14:37-!-ecke [~ecke@] has joined #openttd
14:38<Yexo>then the list is terminated with 2 bytes, last one is always \x80 and the first byte is the maximum 80+ var? (one past the end most likely)
14:39-!-cipi97 [~cipik97@] has joined #openttd
14:39<DaleStan>Yexo: I don't remember the format for the 2-byte terminator (I'm going to read the code in a bit) but otherwise correct.
14:42<Yexo>so what does "\x43\x83" mean? to me it reads like var 43 with a 3-byte/extended byte return value
14:43<Yexo>the wiki lists var 32 for industry tiles as double word, so I'd expect "\x43\x84" there
14:43<DaleStan>OK. The terminator is either "\x<past-the-end-80x-var>\x80", or, if <past-the-end-80x-var> is 100h, "\xFF\xF0".
14:44<DaleStan>\x83 means (portions of) the low three bytes are defined; i.e. the entire high byte is reserved.
14:45<Yexo>thanks again :)
14:47-!-tdev [] has joined #openttd
14:53-!-Splex [~splex@] has quit [Remote host closed the connection]
14:54-!-Splex [~splex@] has joined #openttd
14:58-!-Brianetta [] has joined #openttd
14:58<Yexo>DaleStan: nforenum misses support for callback 14D (or don't you include openttd-only callbacks)?
14:59-!-|Jeroen| [] has quit [Quit: oO]
15:02-!-oskari89 [] has joined #openttd
15:03-!-cipi97 [~cipik97@] has quit [Read error: Connection reset by peer]
15:03-!-cipi97 [~cipik97@] has joined #openttd
15:04-!-TheMask96 [] has quit [Ping timeout: 480 seconds]
15:10-!-TheMask96 [] has joined #openttd
15:17-!-Progman [] has joined #openttd
15:17-!-cipi97 [~cipik97@] has left #openttd []
15:23-!-Chruker [] has joined #openttd
15:26-!-PhoenixII [] has quit [Read error: Connection reset by peer]
15:26-!-Phoenix_the_II [] has joined #openttd
15:27<Yexo>Pikka: <- updated, nforenum now works on your grf without errors (only warnings left are 100 and 172)
15:29<Pikka>ta :)
15:30<@Belugas>congrats Yexo :) Now, can you do the same with my pinpad's code?
15:31<Yexo>hehe :)
15:35<fjb>When will Cargodist forget about a no longer serviced route?
15:38<Yexo>frosch123: I've implemented it like this
15:40-!-Aankhen`` [~foo@] has quit [Quit: BRB]
15:40-!-Aankhen`` [~foo@] has joined #openttd
15:42<frosch123>if it works :) but some vars will assert due to the INVALID_ENGINE
15:42<Yexo>currently that never happens (there always is a vehicle
15:42<Yexo>as soon as I introduce a callback where v can be NULL I'll fix that by adding engine_type to the airport-part of the union
15:53-!-Brianett1 [] has joined #openttd
15:59-!-Brianetta [] has quit [Ping timeout: 480 seconds]
16:02-!-Azrael- [] has joined #openttd
16:03<CIA-1>OpenTTD: glx * r17407 /trunk/projects/ (version_vs80.vcproj version_vs90.vcproj): -Fix (r17336): version_vs?0.vcproj not updated to new path
16:03-!-HerzogDeXtEr [~Flex@] has quit [Read error: Connection reset by peer]
16:04<CIA-1>OpenTTD: glx * r17408 /trunk/src/os/windows/ ( win32.cpp): -Codechange: remove unused win32 stuff
16:06-!-Fast2 [] has joined #openttd
16:06<_ln>@seen Bjarni
16:06<@DorpsGek>_ln: Bjarni was last seen in #openttd 6 weeks, 2 days, 20 hours, 17 minutes, and 26 seconds ago: <Bjarni> as long as it doesn't happen every 5th minute
16:06<Chruker>@seen DorpsGek
16:06<@DorpsGek>Chruker: I have not seen DorpsGek.
16:07<Yexo>Pikka: did you already chose a format for the airport real action 2?
16:08-!-Brianett1 is now known as Brianetta
16:10<Pikka>I just used the tile format... although it's far more than it needs
16:10<Yexo>is a single double-word ok?
16:11<Yexo>format the same as the groundsprite
16:12-!-Aankhen`` [~foo@] has quit []
16:13<Yexo>can you update your grf with that? So I can test the implementation
16:14<Pikka>so instead of 02 0D FF 00 00 80 00 80 00 80 00 80 00 00 10 10 10 ...
16:15<Pikka>02 0D FF 00 00 80 00 ?
16:15<pavel1269>guys, you are crazy ... :-)
16:15<Yexo>Pikka: that looks correct
16:15<@Belugas>no.. they are evil
16:15<Katt>I see people programming with hex-codes.
16:15<Katt>That's hardcore.
16:16<@Belugas>and if it was in delphi? would that be softporn?
16:16<Pikka>no idea if it's the format you wanted though. put the exact format on the wiki page? :)
16:17<Yexo>after it works :)
16:19<Katt>Hmm.. Why does the mapsized jump from 256 to 512 and then straight to 1024? No 768?
16:19<Yexo>Katt: multiples of 2
16:19<Katt>Yeah. No way around it? Ideal mapsize would be 768x1024
16:20<Katt>Biased of course
16:20<Yexo>there are lots of ways around that, but none of them are fast
16:20-!-stuffcorpse [~stuffcorp@] has quit [Ping timeout: 480 seconds]
16:21<Katt>No easy sourcecode-rewrite? Like one handly line? :)
16:22<pavel1269>lol ... Katt: ... under image "real programmers write in binary .. " wouldnt be funny if you wouldnt post that ... :-)
16:24<@Belugas>Katt, it is so for a matter of safety, speed, ease of programming and others. it's not a simple will to bugger users
16:27<frosch123>[22:16] <Pikka> 02 0D FF 00 00 80 00 ? <- may i suggest to do it like
16:29<Yexo>sounds like a good idea
16:31<Pikka>there, updated
16:33-!-Nickman87 [] has quit [Ping timeout: 480 seconds]
16:34<planetmaker>Rubidium: I honestly don't think that the version reported by test.c is... nice.
16:35<@Rubidium>it's not there for the user
16:35<planetmaker>8.11.1 doesn't really relate to much of a version number. Or can you translate them into actual OS?
16:35<planetmaker>and the others?
16:35<planetmaker>is there some kind of translation table?
16:38<planetmaker>but Darwin != Mac OS X. And that might actually make a difference
16:39<planetmaker>if I read that correctly
16:39-!-stuffcorpse [~stuffcorp@] has joined #openttd
16:39<@Rubidium>it's the kernel
16:40<@Rubidium>although all other offsprings of darwin are pretty much dead by now
16:41<planetmaker>night frosch123
16:41<@Rubidium>night frosch123
16:41-!-frosch123 [] has quit [Remote host closed the connection]
16:41<@Rubidium>woohoo :)
16:41<@Rubidium>(usually you're not in time to say night to him before he leaves)
16:42<planetmaker>hehe :-) quite quick that guy, yes
16:42<planetmaker>Rubidium: the other problem with test.c is the CPU type.
16:43<planetmaker>That's only slightly better than the current one.
16:43<planetmaker>i386 is... very generic for todays processors.
16:43<@Rubidium>yes, but for bug reports it doesn't quite matter; x86 = x86
16:43<@Rubidium>and ppc != x86
16:44<planetmaker>concerning the kernel: I think both can be combined: a easy one-line call to query the version reported by MacOSX with your lines querying the kernel version
16:44<@Rubidium>whether you're using a 686 of Octocore Core 1839 X3914123 doesn't matter
16:44<planetmaker>if i386 is fine enough, then well.
16:45<@Rubidium>anyhow, if a bug would be CPU related anything OSX returns is likely not fine grained enough
16:46<@Rubidium>cause then also the stepping is important
16:47<Yexo>Pikka: new build that supports accessing aircraft varaibles via 82/86/8A and it shows a preview in the build airport window
16:48<planetmaker>Rubidium: cpu type and cpu subtype?
16:48<planetmaker>shouldn't that contain exactly that information?
16:48<@Rubidium>planetmaker: got the API specs for the call you intend to do?
16:48<planetmaker>I'm searching it
16:48<planetmaker>missed the bookmark...
16:50-!-Entane [] has joined #openttd
16:51<@Rubidium>planetmaker: the types as in ?
16:55<@Rubidium>oh... found something in machine.h
16:56<@Rubidium> <- not quite useable I guess
16:56-!-Chris_Booth [] has joined #openttd
16:56<@Belugas>#Machine, Machine Messaya... The Mindless search for a higher Controller
16:56<@Belugas>and... BYE BYE!!!!
16:56<@Rubidium>night Belugas
16:56<@Belugas>good night and all those pleasant wishes :D
16:57<Terkhen>good night
16:57<@Rubidium>anyhow, using that is going to be more of a nightmare because one needs the latest and greatest sdk to figure out what the number means (and it isn't quite clear whether it's 64 or 32 bits)
16:59-!-tux_mark_5 [] has quit [Quit: KVIrc Insomnia 4.0.0, revision: , sources date: 20090115, built on: 2009/03/07 00:45:02 UTC]
17:01*Rubidium actually wonders what OSX is going to return for OSX86 and such which don't run one of the types specified in the specs
17:02<_ln>does that matter as OS X support will be dropped?
17:03-!-pavel1269 [] has quit [Remote host closed the connection]
17:04<Sacro>can't drop OSX support
17:07<_ln>Sacro: no active mac developer, and both TrueBrain and Rubidium hate OS X from the bottom of their hearts, so.... unless they are very masochistic, it's inevitable.
17:07-!-Azrael- [] has quit [Ping timeout: 480 seconds]
17:08-!-Mega [~Mega@] has joined #openttd
17:09-!-Mega [~Mega@] has left #openttd []
17:09<+glx>_ln: it's not we hate it, it's the other way :)
17:10<_ln>it hates you?
17:10<+glx>it refuses to work in our VMs
17:10<planetmaker>Rubidium: machine.h is outdated in a way. It returns also only i386
17:10<planetmaker>(sorry, RL, telephone
17:10<Sacro>_ln: what about me? :P
17:10<Sacro>I have Macs
17:10<Sacro>so a vested interest
17:10<@Rubidium>planetmaker: you're probably looking at an *old* machine.h
17:10<Sacro>anda working OSX86 setup
17:11<planetmaker>Rubidium: I looked at the one on my computer. And it doesn't know my CPU...
17:11<_ln>Sacro: but do you have the skill to implement missing stuff?
17:11<Sacro>depends what is missing I guess
17:11<_ln>glx: could be because it's not meant to run in a VM.
17:11<planetmaker>and the one part of the 10.4 SDK ... hm... maybe. I was still doing something wrong when I tested that
17:11<_ln>Sacro: it's listed in some bug report.
17:11<Sacro>glx: I think the only VM you can use is KVM with patched QEmu
17:12<+glx>Sacro: vmware can too, but it needs the right CPU
17:12<+glx>and mine is not one of them
17:12<+glx>though I have a working 10.4.8 VM
17:12<+glx>slow, but working
17:12<Eddi|zuHause><_ln> [...] unless [TrueBrain is] very masochistic [...] <- i'm not quite sure about that one ;)
17:13<Sacro>i have the right cpu
17:14-!-Polygon [] has quit [Quit: Flieht, ihr Narren!]
17:14-!-oskari89 [] has quit [Quit: Utm A½ - Aja 35]
17:16-!-Grelouk [] has quit [Read error: Connection reset by peer]
17:17-!-Farden [] has quit [Read error: Connection reset by peer]
17:20<Zuu>maybe macohistic? ;-)
17:21-!-R0b0t1 [] has joined #openttd
17:22-!-Chris_Booth is now known as Guest1270
17:22-!-Chris_Booth [] has joined #openttd
17:24-!-Chris_Booth [] has quit []
17:25-!-Terkhen [] has quit [Quit: ...]
17:25-!-Phoenix_the_II [] has quit [Read error: Connection reset by peer]
17:25-!-Phoenix_the_II [] has joined #openttd
17:25-!-Guest1270 [] has quit [Ping timeout: 480 seconds]
17:29<TrueBrain> [23:07] <_ln> Sacro: no active mac developer, and both TrueBrain and Rubidium hate OS X from the bottom of their hearts, so.... unless they are very masochistic, it's inevitable. <- He! I don't hate OSX! I just hate the way to install it! When you have it running, it is nice! :)
17:29<TrueBrain>[23:12] <Eddi|zuHause> <_ln> [...] unless [TrueBrain is] very masochistic [...] <- i'm not quite sure about that one ;) <- me neither, will let you know :p
17:30<TrueBrain>to all others: WASSUP!!!
17:34<@Rubidium>the internet
17:34<TrueBrain>the toilet
17:34<Xaroth>the sky
17:37<TrueBrain>I love this game :)
17:39-!-Entane [] has quit [Ping timeout: 480 seconds]
17:41-!-Entane [] has joined #openttd
17:46-!-Cybert1nus [] has quit [Remote host closed the connection]
17:50-!-Cybertinus [] has joined #openttd
17:52-!-Yexo_ [] has joined #openttd
17:52-!-Yexo is now known as Guest1272
17:52-!-Yexo_ is now known as Yexo
17:56<CIA-1>OpenTTD: rubidium * r17409 /trunk/ (5 files in 3 dirs): -Codechange: split the crash log and other windows 'glue' code
17:58-!-nicfer [~Usuario@] has joined #openttd
17:59-!-Guest1272 [] has quit [Ping timeout: 480 seconds]
18:01-!-Cybertinus [] has quit [Remote host closed the connection]
18:01-!-Chruker [] has quit [Ping timeout: 480 seconds]
18:03-!-thingwath [~thingie@] has quit [Remote host closed the connection]
18:06-!-PhoenixII [] has joined #openttd
18:06-!-Phoenix_the_II [] has quit [Read error: Connection reset by peer]
18:08-!-thingwath [~thingie@] has joined #openttd
18:09-!-TritonMan [] has joined #openttd
18:10<TritonMan>I have a question about sound under linux if there's anyone around interested in giving me some advice...
18:12<TritonMan>Ok, I guess I'll post on the forum instead
18:12-!-TritonMan [] has quit []
18:13<Eddi|zuHause>yeah. you do that.
18:13<Xaroth>impatient little bugger
18:14-!-Dreamxtreme [] has quit [Quit: ChatZilla 0.9.85 [Firefox 3.5.2/20090729225027]]
18:27-!-Aankhen`` [~foo@] has joined #openttd
18:27<Aankhen``>Is there any way to customize the MP chat? Reduce its size, configure how long before messages are removed, etc.?
18:28<Yexo>you can change the size in openttd.cfg
18:28<Yexo>network_chat_box_width / network_chat_box_height
18:28<Yexo>or ingame with "set network_chat_box_height newvalue"
18:28<Aankhen``>Thanks, I see all the chat variables there.
18:28<Aankhen``>That should take care of it.
18:28<Aankhen``>Thanks again!
18:29<Aankhen``>(Note to self: look in CFG before asking.)
18:29-!-Aankhen`` [~foo@] has quit []
18:32<CIA-1>OpenTTD: rubidium * r17410 /trunk/src/ (os/windows/crashlog_win.cpp os/windows/win32.cpp stdafx.h): -Codechange: use the same define for determining whether windows does crash reports instead of using several that aren't necessarily equal
18:34-!-Muddy [] has quit [Ping timeout: 480 seconds]
18:38-!-Muddy [] has joined #openttd
18:40-!-Rubidium [] has quit [Ping timeout: 480 seconds]
18:40-!-jonty-comp [] has quit [Ping timeout: 480 seconds]
18:46-!-_Muddy [] has joined #openttd
18:48-!-Muddy [] has quit [Ping timeout: 480 seconds]
18:54<Yexo>whoohoo :-D
18:54<Yexo>my small airport newgrf works :)
18:56<CIA-1>OpenTTD: rubidium * r17411 /trunk/src/ai/api/ai_map.hpp: -Codechange: silence an ICC compile warning
18:58<Eddi|zuHause>if the default airports are not movedd into newgrf, the newgrfs should have the ability to disable the default airports
18:59<Eddi|zuHause>this option was annoyingly forgotten with newgrf stations :(
19:01<Yexo>agreed :)
19:01<Yexo>but I have no idea how to define a sane property for that
19:01-!-Lakie [~Lakie@] has quit [Remote host closed the connection]
19:02<Ammler>Eddi|zuHause: what the issue with just not using it?
19:02-!-Lakie [~Lakie@] has joined #openttd
19:02-!-Rubidium [] has joined #openttd
19:02-!-mode/#openttd [+o Rubidium] by ChanServ
19:02-!-jonty-comp [] has joined #openttd
19:03<Ammler>and why isn't it possible to add that now?
19:03<Yexo>Ammler: when using a newgrf like the one I created (same graphics as small airport, but with rotations) it makes no sense to leave the normal airport available
19:03<Yexo>even more because you can't change the default airports
19:03<Yexo>and codewise it's easy to add, but I don't know how to expose it to newgrf
19:04<Ammler>Yexo: don't think, you should
19:04<Yexo>I could add a single-byte property to the action 0, but I have no idea if that's the best way
19:04<Ammler>or how will you support saves with default airport?
19:04<Yexo>hmm? In case there is a default airport it was obviously not disabled by a newgrf
19:05<Ammler>you might you just hide it from gui
19:05<Yexo>that'e the only thing I'll be doing anyway
19:05<Yexo>and making sure even with a modified client you still can't buy it of course
19:06<Ammler>if you do, you could to the same with all station types, also rails, so eddi isn't annyed anymore ;-)
19:06<Yexo>if anyone wants to test:
19:07<Ammler>the airports, which were available with the newports branch
19:07<Ammler>are they gone with it too?
19:07<Ammler>or were there no new graphics?
19:08<Yexo>the newports branch is still available if you know were to look
19:08<Ammler>yeah, but the grfs weren't in the repo. were they?
19:08<Yexo>the newgrfs for that branch won't load at all, they are not even close to useable
19:08<Ammler>well, I am more wondering about the graphics, the nfo could be rewritten. ;-)
19:08<Yexo>I have no idea if there were many new graphics, but they are useless anyway because we obviously don't have permission to redistribute them
19:09<Ammler>we != I
19:09<Yexo>I ment everything created by rickh
19:09<Yexo>he made it quite clear he didn't want his stuff distributed anymore
19:10-!-HerzogDeXtEr [~Flex@] has joined #openttd
19:10<Ammler>well, if it is code only., no need anyway.
19:10<Ammler>but if there are also graphics, it might be worth to ask again :-)
19:11<Ammler>time does solve such things quite well.
19:11<@Rubidium>knowing what comes from who solves problems too
19:11<@Rubidium>e.g. (AFAIK) the graphics are made by skidd13
19:12<Yexo> <- that seems to contain a lot of airport graphics
19:12<Ammler>skidd13 is/was a dev
19:13-!-goodger [] has joined #openttd
19:14<Ammler>and fake airport grf might be another alternative
19:15<Yexo>but both have no/custom licences
19:16<DaleStan><Yexo> he made it quite clear he didn't want his stuff distributed anymore <-- If it was committed to svn, it's reasonable to assume that it was -- and therefore is -- GPL.
19:16<Yexo>DaleStan: the problem is that his newgrfs never were committed, at least I don't think so
19:16<Yexo>maybe an older version at some point
19:16<DaleStan>Oh. That's a different issue, then.
19:16<Ammler>richk just used default airport graphics.
19:18<Ammler> <-- possible?
19:18<Yexo>those graphics are usefull, at least if they are properly licences
19:20<Ammler>locked threads :-)
19:21<Ammler>usually not worth to read.
19:23<@Rubidium>Ammler: there's no reason why that isn't possible (I can't think of one at least)
19:24<Ammler>I meant the horizontal runway
19:24<Yexo>I see no reason why that's not possible
19:31-!-tdev [] has quit [Quit: Leaving]
19:32<Ammler>Yexo: rotating airport will need a newgrf or is it possible to rotate default airport too?
19:32<Yexo>currently there is no way to rotate the default airports (other then by creating a new tile layout in the code)
19:32-!-Eddi|zuHause [] has quit []
19:33-!-Eddi|zuHause [] has joined #openttd
19:33<Yexo>but that basically only needs a nice way for a newgrf to specify that it's only adding a tilelayout for an existing airport instead of defining a new one
19:33<Yexo>all code can handle rotations of the default airports
19:34<Ammler>you mean switch x<->y?
19:34<Yexo>yes, so 4 rotations total
19:35<Ammler>that sounds quite awesome.
19:36<Yexo> <- small airport with 2 rotations
19:36<Yexo>adding another tile layout in prop A is the only thing needed for another rotation (sprite 34)
19:43-!-dfox [] has quit [Remote host closed the connection]
19:58-!-Zuu [] has quit [Quit: Leaving]
20:03-!-Brianetta [] has quit [Quit: Tschüß]
20:06-!-KritiK [] has quit [Quit: Leaving]
20:11-!-Progman [] has quit [Remote host closed the connection]
20:15-!-KenjiE20 [~KenjiE20@] has quit [Quit: WeeChat 0.3.0-rc3]
20:18-!-ecke [~ecke@] has quit [Quit: ecke]
20:19-!-Fuco [~dota.keys@] has quit [Ping timeout: 480 seconds]
20:27-!-Fast2 [] has quit [Ping timeout: 480 seconds]
20:45-!-Pikka [PikkaBird@] has quit []
20:49-!-PeterT [] has joined #openttd
20:50-!-dfox [] has joined #openttd
21:00-!-ecke [~ecke@] has joined #openttd
21:07<PeterT>@seen PeterT
21:07<@DorpsGek>PeterT: PeterT was last seen in #openttd 2 days, 4 hours, 34 minutes, and 33 seconds ago: <PeterT> goodbye all
21:16-!-z-MaTRiX [] has joined #openttd
21:16-!-PeterT [] has quit [Quit: Goodbye]
21:22-!-Coco-Banana-Man [] has quit [Ping timeout: 480 seconds]
21:33-!-fjb_ [] has joined #openttd
21:37-!-Sacro [~ben@] has quit [Quit: Reconnecting]
21:37-!-Sacro [~ben@] has joined #openttd
21:40-!-Zahl [] has quit [Quit: *schiel*]
21:40-!-fjb [] has quit [Ping timeout: 480 seconds]
21:51-!-ecke [~ecke@] has quit [Quit: ecke]
22:02-!-fjb_ is now known as fjb
22:27-!-PhoenixII [] has quit [Read error: Connection reset by peer]
22:27-!-Phoenix_the_II [] has joined #openttd
22:35-!-tosse_ [] has joined #openttd
22:42-!-tosse [] has quit [Ping timeout: 480 seconds]
22:47-!-glx [glx@2a01:e35:2f59:c7c0:30a3:4987:8aa5:d71d] has quit [Quit: bye]
22:49-!-eisenhowerz [] has joined #openttd
22:49-!-eisenhowerz [] has left #openttd [Leaving]
23:01-!-Lakie [~Lakie@] has quit [Quit: Sleep.]
23:09-!-TinoDidriksen [] has quit [Ping timeout: 480 seconds]
23:12-!-PeterT [] has joined #openttd
23:13-!-TinoDidriksen [] has joined #openttd
23:35-!-PeterT [] has quit [Quit: Goodbye]
23:39-!-TinoDidriksen [] has quit [Ping timeout: 480 seconds]
23:42-!-Phoenix_the_II [] has quit [Read error: Connection reset by peer]
23:42-!-Phoenix_the_II [] has joined #openttd
23:43-!-TinoDidriksen [] has joined #openttd
23:56-!-R0b0t1 [] has quit [Remote host closed the connection]
---Logclosed Fri Sep 04 00:00:36 2009