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

Powered by YARRSTE version: svn-trunk