Config
Log for #openttd on 9th November 2007:
Times are UTC Toggle Colours
00:00:07  <SmatZ> hmm I lost whole content of one of my chroot environment...
00:00:12  <SmatZ> I wonder how is that possible
00:00:30  <SmatZ> if I got mad and deleted contents of whole directory
00:00:36  <SmatZ> and I don't remember anything?
00:02:40  <SmatZ> ha
00:02:48  <SmatZ> I renamed the directory
00:03:31  *** Tefad [~tefad@c-71-63-10-8.hsd1.va.comcast.net] has quit [Remote host closed the connection]
00:03:41  *** Wolf01|AWAY is now known as Wolf01
00:03:46  *** Tefad [~tefad@c-71-63-10-8.hsd1.va.comcast.net] has joined #openttd
00:06:26  <Wolf01> 'night
00:06:29  *** Wolf01 [~wolf01@host203-233-dynamic.8-87-r.retail.telecomitalia.it] has quit [Quit: Once again the world is quick to bury me.]
00:06:39  <SmatZ> he is too quick for me to say bey
00:06:59  *** XeryusTC [~irc@cc480157-b.sneek1.fr.home.nl] has quit [Ping timeout: 480 seconds]
00:08:13  *** thgergo [~Administr@dsl51B78836.pool.t-online.hu] has left #openttd []
00:08:40  *** XeryusTC [~irc@cc480157-b.sneek1.fr.home.nl] has joined #openttd
00:14:32  *** stillunknown [~stillunkn@82-171-87-247.dsl.ip.tiscali.nl] has quit [Ping timeout: 480 seconds]
00:16:05  *** Vikthor [~Vikthor@212.24.150.226] has quit [Quit: Leaving.]
00:16:42  *** XeryusTC [~irc@cc480157-b.sneek1.fr.home.nl] has quit [Ping timeout: 480 seconds]
00:16:46  *** XeryusTC [~irc@cc480157-b.sneek1.fr.home.nl] has joined #openttd
00:22:37  *** Bjarni [~Bjarni@0x50c79a03.virnxx14.adsl-dhcp.tele.dk] has quit [Quit: Leaving]
00:30:03  *** Leviath [~thomas@z037133.its-s.tudelft.nl] has joined #openttd
00:30:03  *** LeviathNL [~thomas@z037133.its-s.tudelft.nl] has quit [Read error: Connection reset by peer]
00:54:41  <Smoovious> time to climb back in the truck for a few weeks...
00:54:42  <Smoovious> o/
00:55:55  <SmatZ> king of the road :)
00:55:57  *** Diabolic-Angel [~dia@xdsl-84-44-134-77.netcologne.de] has quit [Quit: leaving]
00:57:01  *** SmatZ [~smatz@a40-prg1-5-107.static.adsl.vol.cz] has quit [Remote host closed the connection]
01:01:07  *** G_ [~njones@202-154-149-26.ubs-dynamic.connections.net.nz] has joined #openttd
01:02:52  *** G [~njones@202-154-149-26.ubs-dynamic.connections.net.nz] has quit [Ping timeout: 480 seconds]
01:04:21  *** Maarten [~dutchusa@cpe-66-74-155-152.socal.res.rr.com] has quit []
01:06:45  *** Wezz6400 [~Wezz6400@145-118-108-106.fttx.bbned.nl] has quit [Quit: zzz]
01:10:14  <fjb> He really lives the transportation game. :-)
01:17:36  <Smoovious> when I have enuf money to buy my own truck and trailer, I'm going into business with the name "Smoovious Transport" just like in game. :D
01:18:14  * Smoovious poofs.
01:18:28  *** KritiK [~Maxim@78-106-178-64.broadband.corbina.ru] has quit [Quit: Leaving]
01:18:41  *** Smoovious [~imp486@c-71-205-140-67.hsd1.mi.comcast.net] has quit [Quit: Always code as if the guy who ends up maintaining your code is a psychopath who knows where you live.]
01:23:43  <fjb> :-)
01:31:27  *** Eddi|zuHause2 [~johekr@p54B77702.dip.t-dialin.net] has joined #openttd
01:36:14  <fjb> Is there a way to teach road vehicles not to drive through each other when overtaking?
01:36:31  *** Gonozal_VIII [user@cm56-182-132.liwest.at] has joined #openttd
01:36:57  <BigBB> lv4?
01:37:07  <Gonozal_VIII> hi
01:37:17  <BigBB> hi Gonozal_VIII
01:37:52  *** Eddi|zuHause [~johekr@p54B76178.dip.t-dialin.net] has quit [Ping timeout: 480 seconds]
01:38:00  <fjb> Yes. But it looks like the whole vehicles drive through each other, not just the parts that are longer than the bounding box.
01:38:02  *** smoovi [smoovi@e178195185.adsl.alicedsl.de] has quit [Ping timeout: 480 seconds]
01:38:07  <fjb> Moin Gonozal_VIII
01:39:36  <Gonozal_VIII> they did that only on bridges but i thought even that was fixed some days ago
01:40:29  <BigBB> fjb, I think this happen allway if a given amount of vehicles drives in each other. thats happen too vor original graphic (the last time I used that)
01:40:48  <BigBB> s/vor/for
01:42:33  <fjb> Hm, I will have a closer look, but I almost got an heart attack some days ago and wondered where the driver won hic licence.
01:42:55  <BigBB> in the lottery :)
01:45:05  <Gonozal_VIII> seem to keep their box distance on open road as well as in front of stations...
01:46:17  *** smoovi [smoovi@e178210021.adsl.alicedsl.de] has joined #openttd
01:46:43  <Gonozal_VIII> and tunnels suck in unlimited numbers of busses as usual
01:48:37  <BigBB> if a vehicle it will be make unvisible, not more ...
01:48:52  <BigBB> if a vehicle is in a tunnel ...
01:49:18  <Gonozal_VIII> ok now that's funny...
01:49:42  <BigBB> why?
01:49:44  <Gonozal_VIII> they stop on bridges.. but keep on moving closer together very slowly
01:50:05  <BigBB> stop?
01:50:19  <Gonozal_VIII> when i stop the first one manually
01:50:56  <Gonozal_VIII> the others behind it stop in normal distance... but they don't really stop, they keep moving very slowly
01:51:25  <Gonozal_VIII> now they're all stacked
01:51:58  <BigBB> you mean: if you stop a vehicle on brifge, all following will stop behind them. but if you stop a vehicle into a tunnel all vehicles behind them will overhauling them?
01:52:51  <Gonozal_VIII> no they will enter the tunnel... hundreds of them in a 2 tile tunnel
01:53:37  <BigBB> with and without NewGRFs?
01:54:02  <fjb> That is really funny.
01:54:29  <fjb> Maybe there is a parking lot in the tunnel. :-)
01:54:50  <Gonozal_VIII> they want to build something like that in my town :-)
01:54:59  <BigBB> with a NewGRF: okay. But in original version it's not right..
01:57:28  <Gonozal_VIII> 35 mps regal busses in a 3 tile tunnel
01:58:47  <Gonozal_VIII> tunnels have unlimited capacity... but i think that was the same in the original ttd
01:59:43  <Gonozal_VIII> but i can't really remember, that's too long ago
02:02:46  <Gonozal_VIII> but the bridge thing is new, they used to ignore stopped vehicles on the bridge and pass through, now they stop properly and then crawl on pixel by pixel until they are stacked
02:03:10  <Gonozal_VIII> also with and without newgrf
02:04:09  <BigBB> IIRC the bridge behavior was changed for the bridge-over-all patch
02:05:24  <Gonozal_VIII> i think it was around 112xx, not long ago
02:06:27  <Gonozal_VIII> oh, the stack moves on through the stopped vehicle after some time and moves on to the end of the bridge where it destacks
02:07:14  *** XeryusTC [~irc@cc480157-b.sneek1.fr.home.nl] has quit [Ping timeout: 480 seconds]
02:07:59  *** XeryusTC [~irc@cc480157-b.sneek1.fr.home.nl] has joined #openttd
02:08:52  <Gonozal_VIII> only realised that because i hit fast forward, takes some time
02:12:03  <fjb> That is really starnge.
02:12:08  <fjb> strange
02:16:01  *** Ammller [~Ammler@adsl-89-217-45-221.adslplus.ch] has quit [Remote host closed the connection]
02:16:07  *** XeryusTC [~irc@cc480157-b.sneek1.fr.home.nl] has quit [Ping timeout: 480 seconds]
02:17:11  *** XeryusTC [~irc@cc480157-b.sneek1.fr.home.nl] has joined #openttd
02:25:14  *** XeryusTC [~irc@cc480157-b.sneek1.fr.home.nl] has quit [Ping timeout: 480 seconds]
02:25:27  *** XeryusTC [~irc@cc480157-b.sneek1.fr.home.nl] has joined #openttd
02:29:17  *** huma [~huma@89.19.167.191] has quit []
02:43:35  <fjb> Good night.
02:43:45  <Gonozal_VIII> good night
02:43:54  *** fjb [~frank@p5485E8E8.dip.t-dialin.net] has quit [Quit: KVIrc 3.2.0 'Realia']
02:51:34  *** XeryusTC [~irc@cc480157-b.sneek1.fr.home.nl] has quit [Ping timeout: 480 seconds]
02:52:10  *** XeryusTC [~irc@cc480157-b.sneek1.fr.home.nl] has joined #openttd
03:05:20  *** smoovi [smoovi@e178210021.adsl.alicedsl.de] has quit [Quit: #idlerpg]
03:06:57  *** qfh [~qfh@static-ip-62-75-161-163.inaddr.intergenia.de] has quit [Server closed connection]
03:07:08  *** qfh [~qfh@static-ip-62-75-161-163.inaddr.intergenia.de] has joined #openttd
03:17:35  *** Gonozal_VIII [user@cm56-182-132.liwest.at] has quit [Remote host closed the connection]
03:18:39  *** XeryusTC [~irc@cc480157-b.sneek1.fr.home.nl] has quit [Remote host closed the connection]
03:18:47  *** XeryusTC [~irc@cc480157-b.sneek1.fr.home.nl] has joined #openttd
03:35:02  *** XeryusTC [~irc@cc480157-b.sneek1.fr.home.nl] has quit [Ping timeout: 480 seconds]
03:37:42  *** XeryusTC [~irc@cc480157-b.sneek1.fr.home.nl] has joined #openttd
03:46:53  *** glx [glx@bny93-6-82-245-156-124.fbx.proxad.net] has quit [Quit: bye]
03:53:27  *** michi_cc [8069564fbe@dude.icosahedron.de] has quit [Ping timeout: 480 seconds]
03:53:54  *** XeryusTC [~irc@cc480157-b.sneek1.fr.home.nl] has quit [Ping timeout: 480 seconds]
03:55:06  *** XeryusTC [~irc@cc480157-b.sneek1.fr.home.nl] has joined #openttd
04:13:15  *** michi_cc [6da616f902@dude.icosahedron.de] has joined #openttd
04:13:19  *** mode/#openttd [+v michi_cc] by ChanServ
04:20:52  *** Osai^2 [~Osai@pD9EB54B3.dip.t-dialin.net] has joined #openttd
04:24:07  *** ThePizzaKing [~jeff@c211-28-164-75.eburwd2.vic.optusnet.com.au] has joined #openttd
04:24:11  *** Osai^2 [~Osai@pD9EB54B3.dip.t-dialin.net] has quit []
04:27:24  *** Osai [~Osai@pD9EB66D2.dip.t-dialin.net] has quit [Ping timeout: 480 seconds]
04:32:32  *** RamboRonny [magic.powe@90-230-201-111-no37.tbcn.telia.com] has quit [Ping timeout: 480 seconds]
04:46:24  *** XeryusTC [~irc@cc480157-b.sneek1.fr.home.nl] has quit [Ping timeout: 480 seconds]
04:47:00  *** XeryusTC [~irc@cc480157-b.sneek1.fr.home.nl] has joined #openttd
04:47:23  *** BigBB [~BigBB@p5B0424FE.dip0.t-ipconnect.de] has quit [Quit: BigBB]
04:51:57  *** BigBB [~BigBB@p5B0424FE.dip0.t-ipconnect.de] has joined #openttd
05:28:04  *** mikk36|work [~mikk36@ntsrv.lakrito.ee] has joined #openttd
05:28:22  <mikk36|work> heh, 26k citizens in a non-helped city in desert :P
05:45:35  *** mikk36|w [~mikk36@ntsrv.lakrito.ee] has joined #openttd
05:49:52  *** slafs_ [slafs@slafs.org] has joined #openttd
05:49:56  *** wolfryu [~Wolfenste@dhcp-077-250-019-098.chello.nl] has joined #openttd
05:50:11  *** nfc_ [~nfc@88.195.110.105] has joined #openttd
05:50:16  *** Noldo_ [vheino@jumi.lut.fi] has joined #openttd
05:50:18  *** eQualize1 [~lauri@dyn15-194.dsl.spy.dnainternet.fi] has joined #openttd
05:50:30  *** Rubidium_ [~rubidium@rbijker.net] has joined #openttd
05:50:59  *** XeryusTC2 [~irc@cc480157-b.sneek1.fr.home.nl] has joined #openttd
05:52:15  *** dfox_ [~dfox@r5cv25.net.upc.cz] has joined #openttd
05:52:15  *** LeviathNL [~thomas@z037133.its-s.tudelft.nl] has joined #openttd
05:52:34  *** Flyinglord^ [~qfh@static-ip-62-75-161-163.inaddr.intergenia.de] has joined #openttd
05:53:10  *** tokai|ni [~tokai@p54B80FE4.dip0.t-ipconnect.de] has joined #openttd
05:53:33  *** Netsplit synthon.oftc.net <-> kilo.oftc.net quits: @Rubidium, XeryusTC, wolfy, mikk36|work, dfox, qfh, eQualizer, nfc, slafs, Leviath,  (+2 more, use /NETSPLIT to show all of them)
06:04:48  *** HerzogDeXtE1 [~dex@i59F7C091.versanet.de] has quit [Read error: Connection reset by peer]
06:13:54  *** BigBB_ [~BigBB@p5B041084.dip0.t-ipconnect.de] has joined #openttd
06:19:12  *** BigBB [~BigBB@p5B0424FE.dip0.t-ipconnect.de] has quit [Ping timeout: 480 seconds]
06:20:32  *** Unknown_Entity [~UnknownEn@dslb-084-063-031-050.pools.arcor-ip.net] has joined #openttd
06:32:45  <hylje> hi
06:35:13  <Unknown_Entity> hi hylje
06:35:17  <SpComb> Logs: http://spbot.marttila.de:8120/logs/oftc-ottd (old: http://zapotek.paivola.fi/~terom/logs/openttd )
06:35:17  <Unknown_Entity> !logs
06:37:16  *** Gekz [~gekko@CPE-121-217-203-4.nsw.bigpond.net.au] has joined #openttd
06:48:42  *** Diabolic-Angel [~dia@xdsl-81-173-179-171.netcologne.de] has joined #openttd
06:54:36  *** wolfryu is now known as Wolfensteijn
06:57:44  *** Frostregen_ [~sucks@dslb-084-058-182-130.pools.arcor-ip.net] has joined #openttd
07:03:57  *** Frostregen [SADDAM@dslb-084-058-181-039.pools.arcor-ip.net] has quit [Ping timeout: 480 seconds]
07:04:24  *** Frostregen_ is now known as Frostregen
07:09:25  *** Deathmaker [~Miranda@dslb-082-083-221-190.pools.arcor-ip.net] has joined #openttd
07:23:33  *** |Bastiaan| [~kvirc@77.60.199.137] has joined #openttd
07:34:03  *** TinoM [~Tino@i5387C48A.versanet.de] has joined #openttd
07:34:38  *** ludde [~ludde@ua-83-227-238-252.cust.bredbandsbolaget.se] has joined #openttd
07:48:01  *** Deathmaker [~Miranda@dslb-082-083-221-190.pools.arcor-ip.net] has quit [Read error: Connection reset by peer]
07:50:05  *** mikl [~mikl@0x57372ee2.mrbnqu1.broadband.tele.dk] has joined #openttd
07:50:27  *** Osai [~Osai@pD9EB4C72.dip.t-dialin.net] has joined #openttd
07:55:39  *** Sacro [~Sacro@adsl-87-102-80-216.karoo.KCOM.COM] has quit [Remote host closed the connection]
07:57:27  *** XeryusTC2 [~irc@cc480157-b.sneek1.fr.home.nl] has quit [Ping timeout: 480 seconds]
07:58:33  *** XeryusTC [~irc@cc480157-b.sneek1.fr.home.nl] has joined #openttd
08:02:57  *** Ammler [~Ammler@adsl-89-217-15-110.adslplus.ch] has joined #openttd
08:03:27  <Gekz> la la la la la la la lalalalala
08:06:52  *** Jello [Papa@S01060060080d1060.gv.shawcable.net] has quit [Ping timeout: 480 seconds]
08:20:47  *** Osai [~Osai@pD9EB4C72.dip.t-dialin.net] has quit [Quit: Osai]
08:25:01  *** Osai [~Osai@pD9EB4C72.dip.t-dialin.net] has joined #openttd
08:28:45  *** lolman is now known as John
08:29:02  *** John is now known as lolman
08:30:39  *** Jello [Papa@S01060060080d1060.gv.shawcable.net] has joined #openttd
08:50:59  *** Vikthor [~Vikthor@212.24.150.226] has joined #openttd
08:51:54  *** mikl [~mikl@0x57372ee2.mrbnqu1.broadband.tele.dk] has quit [Remote host closed the connection]
08:53:31  *** shodan [user@xerxes.foocode.net] has joined #openttd
08:55:12  *** orudge [orudge@pc.lan.owenrudge.net] has quit [Quit: Goodbye.]
09:02:40  *** orudge [orudge@pc.lan.owenrudge.net] has joined #openttd
09:02:43  *** mode/#openttd [+o orudge] by ChanServ
09:03:51  *** Sacro [~Sacro@adsl-87-102-80-216.karoo.KCOM.COM] has joined #openttd
09:04:49  <Sacro> 'ning
09:10:20  *** Osai [~Osai@pD9EB4C72.dip.t-dialin.net] has quit [Quit: Osai]
09:24:21  *** Purno [~Purno@5357D37C.cable.casema.nl] has joined #openttd
09:37:02  *** Eddi|zuHause2 [~johekr@p54B77702.dip.t-dialin.net] has quit [Ping timeout: 480 seconds]
09:40:35  *** Farden [~jk3farden@AMontsouris-156-1-155-167.w83-202.abo.wanadoo.fr] has joined #openttd
09:41:03  *** Eddi|zuHause2 [~johekr@p54B7720E.dip.t-dialin.net] has joined #openttd
09:47:21  *** Alltaken [~chatzilla@121-72-235-8.cable.telstraclear.net] has joined #openttd
09:49:46  <Gekz> nong.
09:53:22  *** Dark_Link^ [~glidegame@fw.dormnet.his.se] has quit [Read error: Connection reset by peer]
09:53:40  *** Dark_Link^ [~glidegame@fw.dormnet.his.se] has joined #openttd
10:08:19  *** mikl [~mikl@0x57372ee2.mrbnqu1.broadband.tele.dk] has joined #openttd
10:22:46  <Unknown_Entity> can anyone tell me what StartSpriteCombine() is doing and if it could be the cause of the strange SpriteIDs I still get?
10:23:24  *** stillunknown [~stillunkn@82-171-87-247.dsl.ip.tiscali.nl] has joined #openttd
10:41:07  *** MarkMc [~Ronnie@h64n1c1o1114.bredband.skanova.com] has joined #openttd
10:43:12  *** Zavior [~zavior@d195-237-7-209.elisa-laajakaista.fi] has joined #openttd
10:44:42  *** mikl [~mikl@0x57372ee2.mrbnqu1.broadband.tele.dk] has quit [Quit: Connection reset by Peer Gynt]
10:49:04  *** HerzogDeXtEr [~dex@i59F7C091.versanet.de] has joined #openttd
10:56:27  *** TinoM| [~Tino@i5387C48A.versanet.de] has joined #openttd
10:57:26  *** TinoM| [~Tino@i5387C48A.versanet.de] has quit []
10:57:46  *** MarkMc [~Ronnie@h64n1c1o1114.bredband.skanova.com] has quit [Quit: - nbs-irc 2.36 - www.nbs-irc.net -]
11:00:27  *** Unknown_Entity [~UnknownEn@dslb-084-063-031-050.pools.arcor-ip.net] has quit [Ping timeout: 480 seconds]
11:01:05  *** Deathmaker [~Miranda@dslb-082-083-232-052.pools.arcor-ip.net] has joined #openttd
11:07:01  *** BigBB [~BigBB@p5B041084.dip0.t-ipconnect.de] has joined #openttd
11:07:03  *** BigBB_ [~BigBB@p5B041084.dip0.t-ipconnect.de] has quit [Quit: BigBB_]
11:08:14  *** LordAzamath [~chatzilla@ip189.cab20.ltln.starman.ee] has joined #openttd
11:09:03  *** Unknown_Entity [~UnknownEn@dslb-084-063-083-151.pools.arcor-ip.net] has joined #openttd
11:16:52  *** Alltaken [~chatzilla@121-72-235-8.cable.telstraclear.net] has quit [Quit: ChatZilla 0.9.78.1 [Firefox 2.0.0.9/2007102514]]
11:17:52  *** Progman [~progman@p57A1E739.dip.t-dialin.net] has joined #openttd
11:21:01  <CIA-1> OpenTTD: truelight * r11395 /trunk/src/ (town_cmd.cpp tunnelbridge_cmd.cpp): -Fix: allow town-bridges to be build on slopes (Rafal Rzepecki)
11:21:38  *** Gonozal_VIII [~Gonozal_V@N779P023.adsl.highway.telekom.at] has joined #openttd
11:21:54  <Gonozal_VIII> hello all
11:22:30  <CIA-1> OpenTTD: truelight * r11396 /trunk/src/vehicle_gui.cpp: -Fix: GCC 3.3 doesn't like 'static bool inline', should of course be 'static inline bool' (SmatZ)
11:23:14  <TrueBrain> hi
11:23:41  <Gonozal_VIII> short question out of interest... how many bit/byte is a single map tile with all information?
11:24:02  <TrueBrain> the size of _m...
11:24:06  <TrueBrain> what would it be currently..
11:24:20  <TrueBrain> 8 + 8 +16 + 8 + 8 + 8 + 8 bits
11:24:32  <TrueBrain> (type_height + m1 .. m6, where m2 is 16 bit)
11:24:32  <Gonozal_VIII> thanks :-)
11:24:41  <TrueBrain> see src/map.h
11:25:23  *** LeviathNL [~thomas@z037133.its-s.tudelft.nl] has left #openttd [Leaving]
11:25:34  *** LeviathNL [~thomas@z037133.its-s.tudelft.nl] has joined #openttd
11:26:02  <Gonozal_VIII> does it really use that in ram/hd or more?
11:26:08  <LeviathNL> why is there also a m7 in /docs/landscape_grid.html ?
11:26:22  <TrueBrain> lol, LeviathNL, you are right
11:26:24  <TrueBrain> + 8 ;)
11:26:50  <TrueBrain> Gonozal_VIII: type_height + m1 .. m6 are 8 bytes in total, so it uses 8 bytes, and is stored as a single array
11:27:04  <TrueBrain> m7 is stored as an extended, using 1 byte, and stored in a seperate array
11:27:10  <TrueBrain> as maps are always word-aligned
11:27:24  <TrueBrain> I guess it is safe to say: 9 bytes * map-tiles
11:27:49  <Gonozal_VIII> ok thanks for that good answer
11:28:45  <Gonozal_VIII> i had an idea and wanted to know if it would make sense
11:29:04  <Gonozal_VIII> but i wouldn't be able to implement anything anyways
11:29:15  <Gonozal_VIII> at least not yet
11:29:32  <Unknown_Entity> is 184404916 a valid SpriteID? something similar is passed to ViewportDrawTileSprites() on a regular basis and crashes the game
11:29:54  *** ThePizzaKing [~jeff@c211-28-164-75.eburwd2.vic.optusnet.com.au] has quit [Quit: ThePizzaKing]
11:30:44  <TrueBrain> Unknown_Entity: it doesn't look like it, but who knwos what happens internally :p
11:30:45  <TrueBrain> hehe
11:33:30  <Gonozal_VIII> my idea was to assign each possible tile combination a single number, maybe 16 bit and have a db with those numbers as key and all necessary sprite, pathfinder, ground bla data in it
11:34:05  <Unknown_Entity> TrueBrain: i was hoping you could shed some light on my problem. if i simply ignore those spriteIDs this is what I get: http://img486.imageshack.us/my.php?image=day11wh5.png
11:34:20  <Unknown_Entity> so obviously some sprites are missing, mostly tiles
11:35:10  <Unknown_Entity> that screenshot is outdated by the way. depots are showing up correctly by now
11:35:25  <LeviathNL> DS-port :o?
11:35:51  <Unknown_Entity> LeviathNL: work in progress
11:36:31  <Unknown_Entity> LeviathNL: but it's kinda playable (except for missing sprites, some crashes and being unable to click some buttons due to resolution)
11:37:14  <LeviathNL> nice work!
11:37:57  <Gonozal_VIII> yes that's cool
11:40:58  <LeviathNL> Unknown_Entity, isnt the pointer to a spriteid passed to ViewportDrawTileSprites ?
11:41:04  <TrueBrain> Unknown_Entity: I really don't know why the tiles are garbaged..
11:41:45  *** skidd13 [~skidd13@p548A70A7.dip.t-dialin.net] has joined #openttd
11:41:46  <skidd13> Hi
11:41:53  <Gonozal_VIII> hi
11:42:50  <TrueBrain> morning skidd13
11:43:24  <skidd13> TrueBrain: This early over there? :D
11:43:31  *** HerzogDeXtE1 [~dex@i577B7274.versanet.de] has joined #openttd
11:43:32  <TrueBrain> 43 minutes past the morning
11:43:33  <TrueBrain> so yes
11:43:45  <Rubidium_> TrueBrain: it's safer to say that it's 10 bytes per map tile
11:43:54  <TrueBrain> Rubidium_: why?
11:44:00  <Rubidium_> all the overhead everywhere ;
11:44:06  <Gonozal_VIII> i'm up since 7:15...
11:44:09  *** eQualize1 [~lauri@dyn15-194.dsl.spy.dnainternet.fi] has quit [Ping timeout: 480 seconds]
11:44:22  *** tokai|ni [~tokai@p54B80FE4.dip0.t-ipconnect.de] has quit [Ping timeout: 480 seconds]
11:44:22  <TrueBrain> Rubidium_: which? I mean, extended is in an array... should use 1 byte per tile :)
11:44:44  <Gonozal_VIII> that's 29,5h :S should really go to sleep now...
11:44:51  <TrueBrain> night Gonozal_VIII
11:44:56  <Gonozal_VIII> night
11:45:16  *** Gonozal_VIII [~Gonozal_V@N779P023.adsl.highway.telekom.at] has quit [Remote host closed the connection]
11:46:13  *** tokai|ni [~tokai@p54B80E1A.dip0.t-ipconnect.de] has joined #openttd
11:47:04  <Rubidium_> TrueBrain: animated tiles one a busy map takes about that
11:47:36  <TrueBrain> Rubidium_: lol, true, but that isn't _m related ;)
11:50:03  <Rubidium_> Gonozal's idea wouldn't even work with 9 byte keys as there is quite a lot information stored in the variables of most buidlings
11:50:21  *** Rubidium_ is now known as Rubidium
11:50:24  *** HerzogDeXtEr [~dex@i59F7C091.versanet.de] has quit [Ping timeout: 480 seconds]
11:50:27  *** Unknown_Entity [~UnknownEn@dslb-084-063-083-151.pools.arcor-ip.net] has quit [Ping timeout: 480 seconds]
11:51:11  <skidd13> TrueBrain: The comments in the town bridge patch lie. It doesn't fit 100% into the layout. There is a unfrequent case where the target_dir does not fit to the source dir.
11:51:43  <TrueBrain> skidd13: how many out of the how many?
11:52:01  <LeviathNL> cd bin
11:52:07  <TrueBrain> #bin
11:52:36  <skidd13> TrueBrain: Hmm not that much.
11:52:37  *** Unknown_Entity [~UnknownEn@dslb-084-063-013-083.pools.arcor-ip.net] has joined #openttd
11:52:45  <SpComb> Logs: http://spbot.marttila.de:8120/logs/oftc-ottd (old: http://zapotek.paivola.fi/~terom/logs/openttd )
11:52:45  <Unknown_Entity> !logs
11:53:00  <TrueBrain> skidd13: so, it aint a real lie, just a lie in rare cases I guess ;)
11:53:07  <TrueBrain> is there a way to fix it to be 100%?
11:54:13  <TrueBrain> and is this by design, or a bug of target_dir
11:54:26  <skidd13> There should be, but I don't know one in the ballpark. ATM
11:55:32  <LeviathNL> TrueBrain, what do you think about my shore-generating patch?
11:56:27  <skidd13> This bug occured some times earlier. I think it's by design of the old algorith, but don't pin me down on that.
11:56:40  <TrueBrain> LeviathNL: I am unsure, I think I don't like it; I remember we fixed it the other way long ago :p
11:56:43  *** Stoffe [~mirc@h2n2fls308o838.telia.com] has quit [Quit: Peace and Protection 4.22.2]
11:57:00  <TrueBrain> skidd13: so, lets leave it like it is for now :)
11:57:21  <TrueBrain> LeviathNL: but I first need to lookup what happened in thehistory, to be sure what I like ;)
11:57:59  *** Gekz [~gekko@CPE-121-217-203-4.nsw.bigpond.net.au] has quit [Quit: KVIrc 3.2.6 Anomalies http://www.kvirc.net/]
12:11:42  <skidd13> TrueBrain: I just found a way to fix it... http://paste.openttd.org/285
12:13:01  <TrueBrain> skidd13: and it works? :)
12:14:11  <skidd13> It checks if the tile before the bridge has the RoadBit to the bridge set. So yes
12:17:02  *** Unknown_Entity [~UnknownEn@dslb-084-063-013-083.pools.arcor-ip.net] has quit [Ping timeout: 480 seconds]
12:18:29  <TrueBrain> skidd13: patch doesn't apply
12:19:20  <skidd13> TrueBrain: Hmm
12:19:28  <skidd13> What's the problem
12:19:40  <TrueBrain> not sure in fact...
12:19:46  <TrueBrain> Hunk #1 FAILED at 916.
12:19:46  <TrueBrain> patch unexpectedly ends in middle of line
12:19:48  <TrueBrain> might be pastebin
12:20:12  *** Diabolic-Angel [~dia@xdsl-81-173-179-171.netcologne.de] has quit [Ping timeout: 480 seconds]
12:20:20  <skidd13> yup
12:20:43  <TrueBrain> can you put it on a http? :p
12:21:38  <skidd13> TrueBrain: As I told you a few days ago nope :(
12:21:50  <TrueBrain> manual applying....
12:21:54  <skidd13> I've got no website
12:25:34  *** Unknown_Entity [~UnknownEn@dslb-084-063-058-010.pools.arcor-ip.net] has joined #openttd
12:31:33  *** LeviathNL [~thomas@z037133.its-s.tudelft.nl] has quit [Remote host closed the connection]
12:37:17  *** Diabolic-Angel [~dia@xdsl-84-44-224-109.netcologne.de] has joined #openttd
12:39:57  *** skidd13 is now known as Guest82
12:40:08  *** smoovi [smoovi@e178249077.adsl.alicedsl.de] has joined #openttd
12:40:11  *** skidd13 [~skidd13@p548A75C3.dip.t-dialin.net] has joined #openttd
12:42:13  <LordAzamath> Does anyone know...? When modeling with Blender, how many tiles is one elevation...I want to make bridge starts-ends, but how high should it be ? Thanks
12:42:47  <LordAzamath> I mean the bridge itself, how many tiles (BLender tiles) from ground
12:43:42  *** Guest82 [~skidd13@p548A70A7.dip.t-dialin.net] has quit [Ping timeout: 480 seconds]
12:50:22  <Rubidium> I think nobody knows
12:53:16  *** Osai [~Osai@pD9EB4C72.dip.t-dialin.net] has joined #openttd
12:55:04  *** LeviathNL [LeviathNL@wlan-145-94-219-45.wlan.tudelft.nl] has joined #openttd
12:55:21  *** lolman is now known as John
12:55:29  *** John is now known as lolman
12:56:29  *** Brianetta [~brian@82-39-52-234.cable.ubr03.benw.blueyonder.co.uk] has joined #openttd
12:56:39  *** Brianetta [~brian@82-39-52-234.cable.ubr03.benw.blueyonder.co.uk] has left #openttd []
12:58:13  *** Deathmaker [~Miranda@dslb-082-083-232-052.pools.arcor-ip.net] has quit [Read error: Connection reset by peer]
12:58:54  *** mikl [~mikl@0x57372ee2.mrbnqu1.broadband.tele.dk] has joined #openttd
13:06:16  *** Diabolic-Angel [~dia@xdsl-84-44-224-109.netcologne.de] has quit [Quit: leaving]
13:10:21  <mikk36|w> Rubidium, is there a reason why a specatator can't see available trains ?
13:11:11  <Rubidium> there probably is, whether it's a good one is something else
13:12:38  <mikk36|w> i'm missing it a lot when i'm not in a mood to play myself but rather just spec
13:12:52  <Ammler> mikk36|w: you can see the used set on the grf list and then  check the doc about it
13:12:54  *** eJoJ [~ejoj@89.10.29.107] has joined #openttd
13:13:03  *** Purno [~Purno@5357D37C.cable.casema.nl] has quit [Quit: Always remember you're unique, just like everyone else.]
13:13:48  <mikk36|w> Ammler, that's as straight way to do it as to go to a shop 1km away by a highway travelling 25km
13:14:09  <Ammler> :) indeed
13:14:55  <Ammler> and its also possible that there isn't a doc available
13:15:56  <mikk36|w> yup
13:22:11  <CIA-1> OpenTTD: truelight * r11397 /trunk/src/town_cmd.cpp: -Fix r11395: some minor fixes for better town-bridge results (and better comments) (skidd13 / TrueLight)
13:30:49  <Ammler> TrueBrain: was there ever a try to import/export patch/grf settings?
13:32:02  <Ammler> we are asked sometimes for the settings we are using on our servers, many would like to use it on a single player game
13:33:04  <Ammler> we can't publish our cfg because of the passwords...
13:35:52  <TrueBrain> then just remove the passwords
13:36:41  *** mikl [~mikl@0x57372ee2.mrbnqu1.broadband.tele.dk] has quit [Remote host closed the connection]
13:37:28  *** glx [glx@bny93-6-82-245-156-124.fbx.proxad.net] has joined #openttd
13:37:31  *** mode/#openttd [+v glx] by ChanServ
13:38:47  <skidd13> Ammler: If you've got a shell grep is your friend (to filter out stuff like passwords)
13:41:41  <Ammler> hmm, sometimes we have changed the settings while playing or play a scenario from someone...
13:42:25  <Ammler> hmm, but for first is indeed something with removing the password
13:51:38  *** SmatZ [~smatz@a40-prg1-5-107.static.adsl.vol.cz] has joined #openttd
13:53:13  <SmatZ> hi
13:53:53  <SmatZ> bbl
13:54:44  *** Vikthor [~Vikthor@212.24.150.226] has quit [Remote host closed the connection]
13:55:06  *** Vikthor [~Vikthor@212.24.150.226] has joined #openttd
13:55:15  *** dihedral [~dihedral@dslb-084-056-212-166.pools.arcor-ip.net] has joined #openttd
14:07:41  *** LeviathNL [LeviathNL@wlan-145-94-219-45.wlan.tudelft.nl] has quit []
14:15:43  *** Rafagd [~kvirc@BHE200150044021.res-com.wayinternet.com.br] has joined #openttd
14:18:02  *** dihedral [~dihedral@dslb-084-056-212-166.pools.arcor-ip.net] has quit [Ping timeout: 480 seconds]
14:27:32  <Unknown_Entity> can anyone explain viewport.cpp line 704 to me?
14:27:33  <Unknown_Entity> *vd->parent_list++ = ps;
14:27:45  <Unknown_Entity> are there parenthesis missing?
14:27:53  <Rubidium> nope
14:28:03  <Rubidium> write ps to vd->parent_list[0]
14:28:13  <Rubidium> and increment vd->parent_list afterwards
14:28:22  <Unknown_Entity> well that's the line which has a different result on DS and on Unix
14:29:01  <glx> blame your DS compiler
14:29:38  <Unknown_Entity> glx: i do! but doesn't solve the problem :(
14:30:22  <TrueBrain> Unknown_Entity: so, fix it by: *vd->parent_list = ps
14:30:26  <TrueBrain> vd->parent_list++;
14:30:28  <TrueBrain> (2 lines)
14:30:51  <TrueBrain> some old (weird) compilers to mix up the order of ++ and *...
14:31:31  <Unknown_Entity> yeah, i'm trying that at the moment (always takes an eternity to run the binary *g*)
14:32:18  <Unknown_Entity> argh. still the same problem :(
14:32:35  <TrueBrain> then it is something else ;)
14:32:57  *** egladil [~egladil@83.233.184.124] has quit [Ping timeout: 480 seconds]
14:33:03  *** Dephenom [~paul@91.186.11.8] has quit [Quit: Leaving]
14:33:16  <Unknown_Entity> after that line executes _cur_vd->first_tile->image is set to 184404944. on unix it's something sane. and i suspect that 184404944 is some random memory leak
14:33:32  *** Dephenom [~paul@91.186.11.8] has joined #openttd
14:33:36  <TrueBrain> or buffer overflow?
14:33:36  *** LeviathNL [~thomas@z037133.its-s.tudelft.nl] has joined #openttd
14:33:50  *** eQualizer [~lauri@dyn15-194.dsl.spy.dnainternet.fi] has joined #openttd
14:34:17  <Unknown_Entity> which buffer?
14:35:07  <TrueBrain> any
14:37:56  <Unknown_Entity> it's driving me nuts. XD everything else is running so smoothly now
14:38:13  <SmatZ> Unknown_Entity: you may verify that when it is initiated, it has a correct value... then you may set a data breakpoint to see when it is written to
14:39:10  <Unknown_Entity> SmatZ: i don't have a debugger. i'm doing that manually now...
14:39:21  <SmatZ> :-x
14:39:54  <SmatZ> don't you have even gdb?
14:41:01  <Unknown_Entity> there's a special emulator version with gdb support and you have to set up a stub to receive the debug data. it looked to complicated to bother with until now. *g*
14:44:34  <Eddi|zuHause2> a propos debugger... anyone know an integrated python debugger?
14:45:09  *** fjb [~frank@p5485EAB9.dip.t-dialin.net] has joined #openttd
14:45:14  <fjb> Moin
14:45:38  <Eddi|zuHause2> that better not be an automatted message...
14:47:56  <SpComb> Logs: http://spbot.marttila.de:8120/logs/oftc-ottd (old: http://zapotek.paivola.fi/~terom/logs/openttd )
14:47:56  <fjb> !logs
14:48:11  *** Wezz6400 [~Wezz6400@145-118-108-106.fttx.bbned.nl] has joined #openttd
14:48:36  *** Rafagd [~kvirc@BHE200150044021.res-com.wayinternet.com.br] has quit [Remote host closed the connection]
15:23:07  *** LeviathNL [~thomas@z037133.its-s.tudelft.nl] has quit [Ping timeout: 480 seconds]
15:23:24  *** Murray-Mint [murray@phobos.fatboylan.co.uk] has joined #openttd
15:23:37  *** SmatZ [~smatz@a40-prg1-5-107.static.adsl.vol.cz] has quit [Remote host closed the connection]
15:23:44  <Murray-Mint> Hi, what IP/port does the game connect to to advertise a game on the master server?
15:23:55  <Murray-Mint> Also, what IP/Port does the client connect to to get the master server list?
15:24:06  <TrueBrain> @openttd port
15:24:06  <DorpsGek> TrueBrain: OpenTTD uses TCP and UDP port 3979 for server <-> client communication and UDP port 3978 for masterserver (advertise) communication (outbound)
15:24:19  <Murray-Mint> Clever... :)
15:24:26  <Murray-Mint> What IP does the master server have?
15:24:39  <Murray-Mint> I'm at a (very) large LAN party, and I need to get the firewall rule added for it :)
15:27:33  <TrueBrain> master.openttd.org
15:27:46  <Murray-Mint> THank you very much!
15:27:49  <TrueBrain> np
15:32:49  <Unknown_Entity> lol, remember that I said that _cur_vd->first_tile->image is set to 184404944? I found out what that value is. 0xAFDC914. it's the adress where _cur_vd->first_tile->image is stored.
15:33:03  <Unknown_Entity> any ideas why it's behaving like that?
15:33:56  <TrueBrain> the compiler fucks up,or your debug line :)
15:34:53  <Unknown_Entity> very very strange. i'm beginning to dislike ds programming :P
15:35:44  *** skidd13 [~skidd13@p548A75C3.dip.t-dialin.net] has left #openttd [ZZZzzzz.]
15:44:31  <Murray-Mint> Superb, that's excellent help with the ports and IP, thank you very much :)
15:44:34  *** Murray-Mint [murray@phobos.fatboylan.co.uk] has quit []
15:58:07  *** Osai [~Osai@pD9EB4C72.dip.t-dialin.net] has quit [Quit: Osai]
15:58:15  *** LordAzamath [~chatzilla@ip189.cab20.ltln.starman.ee] has quit [Quit: ChatZilla 0.9.78.1 [Firefox 2.0.0.9/2007102514]]
16:00:19  *** [wtc7SG] [~utdoom@80.217.198.179] has joined #openttd
16:00:41  *** G [~njones@202-154-149-26.ubs-dynamic.connections.net.nz] has joined #openttd
16:02:27  *** G_ [~njones@202-154-149-26.ubs-dynamic.connections.net.nz] has quit [Ping timeout: 480 seconds]
16:04:38  *** skidd13 [~skidd13@p548A4F8B.dip.t-dialin.net] has joined #openttd
16:12:22  *** G [~njones@202-154-149-26.ubs-dynamic.connections.net.nz] has quit [Ping timeout: 480 seconds]
16:15:44  <Belugas> http://devs.openttd.org/~belugas/photos/office-no-coffee.PNG
16:15:55  <Belugas> so true :D
16:16:01  <Belugas> http://devs.openttd.org/~belugas/photos/dare_to_complain.PNG
16:16:12  <Belugas> my best one!
16:16:20  <glx> lol
16:17:14  *** |Jeroen| [~jeroen@d51A47061.access.telenet.be] has joined #openttd
16:19:44  <skidd13> LOL
16:24:53  <fjb> :-)
16:34:33  *** Unknown_Entity [~UnknownEn@dslb-084-063-058-010.pools.arcor-ip.net] has quit [Quit: giving up for today]
16:37:31  *** Grey [~Greyscale@86.160.172.101] has joined #openttd
16:37:32  *** Greyscale [~Greyscale@86.160.172.101] has quit [Read error: Connection reset by peer]
16:40:53  *** Gonozal_VIII [~Gonozal_V@N779P023.adsl.highway.telekom.at] has joined #openttd
16:58:03  *** svippery [~svip@cpe.atm2-0-78233.0x535a2072.boanxx18.customer.tele.dk] has quit [Remote host closed the connection]
17:01:13  *** svip [~svip@cpe.atm2-0-78233.0x535a2072.boanxx18.customer.tele.dk] has joined #openttd
17:05:17  *** skidd13 [~skidd13@p548A4F8B.dip.t-dialin.net] has left #openttd [ZZZzzzz.]
17:07:39  *** |Bastiaan| [~kvirc@77.60.199.137] has quit [Quit: KVIrc 3.2.6 Anomalies http://www.kvirc.net/]
17:11:29  *** egladil [~egladil@83.233.184.124] has joined #openttd
17:12:13  *** Wolf01 [~wolf01@host203-233-dynamic.8-87-r.retail.telecomitalia.it] has joined #openttd
17:12:21  <Wolf01> hello
17:12:31  <Gonozal_VIII> hi
17:13:52  *** SmatZ [~smatz@a40-prg1-5-107.static.adsl.vol.cz] has joined #openttd
17:15:44  <SmatZ> hello again :)
17:15:48  <SmatZ> back for a while...
17:29:59  *** Wezz6400 [~Wezz6400@145-118-108-106.fttx.bbned.nl] has quit [Quit: 2440457725]
17:32:59  *** lolman is now known as John
17:33:06  *** John is now known as lolman
17:33:24  <SmatZ> TrueBrain: I have just received email I am talking in my reply I didn't receive...
17:34:03  <SmatZ> so it is working, but sometimes with a little delay
17:43:57  *** XeryusTC [~irc@cc480157-b.sneek1.fr.home.nl] has quit [Ping timeout: 480 seconds]
17:44:08  <TrueBrain> SmatZ: too bad for you, you replied at the wrong thread
17:44:24  *** XeryusTC [~irc@cc480157-b.sneek1.fr.home.nl] has joined #openttd
17:48:22  <SmatZ> TrueBrain: ah sorry :-o
17:48:51  <TrueBrain> no problem, just don't do it again ;) And you can repost to the correct thread
17:48:51  <SmatZ> this concept is so complex
17:49:08  <SmatZ> I didn't want to, things happen...
17:49:17  <TrueBrain> get a real email client ;)
17:49:44  <Wolf01> "The nation's other strategic robots were quickly torn asunder by the Dajjal" what does mean "torn asunder"?
17:49:49  *** Diabolic-Angel [~dia@xdsl-84-44-211-10.netcologne.de] has joined #openttd
17:53:17  <Wolf01> TrueBrain there's a way to subscribe to patches where you replied orown patches only?
17:55:00  <Phazorx> .
17:57:06  <Gonozal_VIII> asunder is easy, what is "dajjal?
17:57:11  <Gonozal_VIII> "
17:57:58  <Belugas> with a capiatl D, it must be a name ;)
17:58:10  <Belugas> or a title, even
17:58:14  <TrueBrain> Wolf01: sorry, my english parser couldn't parse that sentence
17:58:47  <Gonozal_VIII> name wouldn't have "the" in front of it
17:58:48  <Wolf01> mine too :/
17:59:05  <Eddi|zuHause2> but a title would
17:59:14  <SmatZ> TrueBrain: is there a way to subscribe to notifications only for threads you started or your replied to?
17:59:18  <SmatZ> my parser got it
17:59:21  <Wolf01> the Dajjal is another robot
17:59:22  <Belugas> yup... like "the Master"
17:59:29  <TrueBrain> SmatZ: ah :) Wolf01: no
17:59:40  <TrueBrain> I am creating a small page that shows the emails per thread
17:59:43  <TrueBrain> including status and such
17:59:50  <TrueBrain> maybe I will add an email-field to it some day
18:00:02  <TrueBrain> but for now, I guess you have to make your client ignore other threads
18:00:23  <TrueBrain> SmatZ: tnx, now the patch is clean code-wise :)
18:00:30  <Gonozal_VIII> wiki says dajjal means anti-christ
18:00:47  <Wolf01> but, why not use a forum instead of a mailing list? forums work well for this kind of things
18:00:56  *** Wezz6400 [~Wezz6400@145-118-108-106.fttx.bbned.nl] has joined #openttd
18:01:01  <TrueBrain> Wolf01: nope, they work as bad as FS did
18:01:16  <TrueBrain> Wolf01: now I have a nice list of threads, which show me clearly where a new person replied, which I did't reply too, etc etc
18:01:20  <SmatZ> TrueBrain: :-) nice, but the worse side of this is that things that were not 'clean' I usually copied from other parts of the OTTD code...
18:01:22  <TrueBrain> that only maillist have
18:01:31  <SmatZ> I hope your parser will handle that :)
18:01:34  <TrueBrain> SmatZ: nobody ever said the current code is good :)
18:01:40  <TrueBrain> that is why we want to make it better ;)
18:01:57  <TrueBrain> so sadly enough, it isn't an excuse ;)
18:02:19  <SmatZ> TrueBrain: yes... also, there are now doxygen comments, C++ things and so on...
18:02:52  <TrueBrain> sometimes it is needed to go just a little bit outside your own patch to make the original code just a tiny bit better :)
18:03:08  <TrueBrain> see 11397, the bridge_length thingies weren't needed at all.. but while at it, well, why not ;)
18:03:38  <TrueBrain> Wolf01: btw, as you can see on the maillist activity, I think nobody had this quick replies on their patches ;) So I think a maillist is the right choice, from a developers point of view anyway :)
18:03:44  <SmatZ> :-)
18:04:13  <Wolf01> forum -> list of threads, forums show when there are new posts, offten forums show with a different icon the threads you replied to... mailing lists are difficult to understand for me, and the forums have the same function
18:04:21  <SmatZ> anyway, I was curious if changing it from uint32 to uint8 will make things faster, when "uint" is supposed to be the fastest data type
18:04:50  <TrueBrain> Wolf01: I disagree :)
18:05:02  <TrueBrain> SmatZ: 'uint' isn't, as we force it to be 32bit :)
18:05:05  <TrueBrain> (so on 64bit it isn't)
18:05:10  <TrueBrain> and compilers optimize that anyway
18:06:30  <SmatZ> TrueBrain: maybe... maybe it will use "movzx" and masks before comparison to fit in 8 bit, when it shouldn't be needed
18:06:45  <SmatZ> on amd64, the fastest data type is 32bit...
18:06:53  <Rubidium> TrueBrain: where do we force uint to be 32 bits?
18:06:58  <SmatZ> if you don't prove something else :)
18:07:22  <TrueBrain> Rubidium: I really hope we do :) (And I am sure we do)
18:07:24  <SmatZ> it doesn't need the REX prefix, and data need less cache
18:07:37  <Rubidium> TrueBrain: I'm kinda sure it doesn't
18:07:53  <SmatZ> but even 8bit integer will usually take 32bits of register/memory
18:08:02  <Rubidium>   typedef unsigned int uint;
18:08:04  <TrueBrain> stdafx.h:  typedef unsigned int uint32;
18:08:04  <TrueBrain> stdafx.h:  typedef unsigned int uint;
18:08:04  <TrueBrain> stdafx.h:  typedef unsigned int uint;
18:08:10  <TrueBrain> I am sure uint is 32bit :)
18:08:23  <TrueBrain> always and always and always
18:08:36  <SmatZ> on 16bit DOS, int was 16bit
18:08:47  <Rubidium> TrueBrain: int is not necessary 32 bits
18:08:48  <TrueBrain> SmatZ: yup
18:08:52  <TrueBrain> Rubidium: it is
18:08:59  <TrueBrain> look up.. well.. everywhere
18:09:03  <TrueBrain> even Windows agree
18:09:14  <TrueBrain> the only thing Windows doesn't agree on against Linux, is what 'long' should be
18:09:16  <TrueBrain> or was it 'long long'
18:09:20  <Rubidium> TrueBrain: how big is a short?
18:09:21  <TrueBrain> anyway, either one of the two is different
18:09:25  <TrueBrain> Rubidium: 16bit
18:11:09  <SmatZ> I have to go, bye
18:11:17  <TrueBrain> bye SmatZ :)
18:12:42  <TrueBrain> Rubidium: the main reason this was done, is because else porting became a bitch
18:14:04  <TrueBrain> not the best side, but I lost the one that had a nice table.. anyway: http://publib.boulder.ibm.com/infocenter/iseries/v5r4/index.jsp?topic=/rzaik/rzaikodbc64bitconsiderations.htm
18:14:38  <TrueBrain> 'int' is ALWAYS 32bit, 'long' MIGHT be 64bit (linux only)
18:14:45  <TrueBrain> (so, always avoid the usage of 'long' ;)
18:16:11  <TrueBrain> http://www.ibm.com/developerworks/library/l-port64.html <- that is more like it
18:16:30  <TrueBrain> anyway, nuff said
18:17:02  <Rubidium> TrueBrain, a DSP: can have short of 32 bits and can have an int of 24 bits
18:17:13  <TrueBrain> Rubidium: C should always correct for that
18:17:18  <Rubidium> NO
18:17:19  <TrueBrain> the C standard defines the above rules...
18:17:24  <Rubidium> no it does not
18:17:27  <TrueBrain> sorry, it really says that..
18:17:32  <Rubidium> TrueBrain: where?
18:17:33  <TrueBrain> the internal storage is hidden from the user
18:17:44  <TrueBrain> look up some standard
18:17:57  <TrueBrain> anyway, doesn't matter, OpenTTD 'uint' is 32bit on ALL suported platforms
18:18:00  <Rubidium> the C specs only says sizeof(char) <= sizeof(short) <= sizeof(int) <= sizeof(long)
18:18:01  <TrueBrain> either 32bit or 64bit systems
18:18:11  <TrueBrain> which breaks in your example, so ;)
18:18:21  *** Diabolic-Angel [~dia@xdsl-84-44-211-10.netcologne.de] has quit [Quit: leaving]
18:18:23  <Rubidium> no, it does not
18:18:27  <Rubidium> two different DSP procs
18:18:33  <TrueBrain> euh, you say short 32, int 24... I dunno, sounds not fitting ;)
18:18:40  <TrueBrain> anyway, who cares
18:18:46  <TrueBrain> uint is never 64bit
18:18:51  <Rubidium> some DSPs have short of 32 bits, some (other) have shorts of 24 bits
18:19:14  *** Diabolic-Angel [~dia@xdsl-84-44-233-136.netcologne.de] has joined #openttd
18:19:24  <TrueBrain> (or maybe a better statement: what ever size uint32, uint is in that size too)
18:19:37  <TrueBrain> so if you start talking nonsence like that, about DSP, you have a problem anyway in OpenTTD
18:19:39  <TrueBrain> as uint32 isn't 32bit
18:19:43  <TrueBrain> and uint16 isn't 16bit
18:19:49  <TrueBrain> and in fact, it would break saveload totally
18:20:35  <TrueBrain> so, evenso we don't force uint to be 32bit, for sure we do force it to be the same size as uint32
18:21:03  <Rubidium> no, it's just "luck" that noone makes a processor where unsigned int != uint32
18:21:14  <TrueBrain> hahaha, oh bo
18:21:15  <TrueBrain> y
18:21:16  <Rubidium> for an OS where OTTD runs on
18:21:18  <TrueBrain> dafx.h:  typedef unsigned int uint32;
18:21:23  <TrueBrain> unsigned int is ALWAYS uint32...
18:21:49  <Rubidium> TrueBrain: if that is the case, it must be in the C++ specifications
18:21:58  <TrueBrain> Rubidium: no, it is how we define it
18:22:05  <TrueBrain> uint32 is OpenTTD thingy
18:22:14  <TrueBrain> (okay, BEOS has it defined in the system-headers)
18:22:40  <Rubidium> TrueBrain: for windows it apparantly holds that unsigned int is uint32
18:22:53  <TrueBrain> for OpenTTD it holds that unsigned int is uint32...
18:23:12  <TrueBrain> stdafx.h:262 states that
18:23:42  <Rubidium> that is ONLY for Windows and OS2
18:23:47  <Rubidium> i.e. only for x86 processors
18:24:04  <TrueBrain> it is outside any #ifdef block
18:24:09  <TrueBrain> (okay, inside not BEOS)
18:24:22  <TrueBrain> and even more fun: assert_compile(sizeof(uint32) == 4);
18:24:54  <Rubidium> then someone did completely misalign the crap in stdafx.h
18:25:00  <TrueBrain> Rubidium: no, nobody ddid
18:25:02  <TrueBrain> you are just wrong
18:25:02  <TrueBrain> sorry
18:26:12  <TrueBrain> so it really is true, that on any system OpenTTD compiles successful, an uint is the same size as an uint32, is 32bit
18:27:45  <Rubidium> http://www.kuzbass.ru:8086/docs/isocpp/basic.html <- 3.9.1 only states their relative size. It does not state how large it is
18:28:01  <Rubidium> it even does not specify whether signed integers are 2 or 1 complement
18:28:23  <stillunknown> What kind of rendering backend is used for openttd?
18:28:35  <TrueBrain> Rubidium: you are correct, C specification don't specify it by detail
18:28:38  <TrueBrain> nevertheless, OpenTTD does
18:31:16  <Rubidium> it does not check it for BEOS
18:31:26  <TrueBrain> Rubidium: it does the check for sure
18:31:30  <TrueBrain> and the above rule still holds
18:31:51  <Rubidium> TrueBrain: where does it check that sizeof(unsigned int) for BEOS?
18:31:54  <TrueBrain> you really can try to find a way around it, but is it that hard to admit you were wrong and in OpenTTD uint32 == uint?
18:32:01  <TrueBrain> assert_compile(sizeof(uint32) == 4); <- about there...
18:32:09  <stillunknown> Why don't you just use a uint32_t or something like that?
18:32:10  <Rubidium> where do you define uint32?
18:32:19  <TrueBrain> oh, unsigned int, indeed, BEOS doesn't
18:32:22  <Rubidium> define uint32 for BEOS
18:32:26  <TrueBrain> but I am all this time talking about uint and uitn32
18:32:34  <TrueBrain> stillunknown: historical reasons I guess
18:32:56  <Rubidium> probably because MSVC doesn't have uint32_t
18:33:01  <Rubidium> (and friends)
18:33:07  <Belugas> [13:34] <stillunknown> Why don't you just use a uint32_t or something like that?  <--- not all compilers support that, iirc
18:33:10  <TrueBrain> Rubidium: for all I know/care, BEOS uses 64bit for shorts, and 16bit for unsigned int... uint16 is 16bit, and uint32 is 32bit
18:33:52  <Rubidium> then the thing you declared in the begin (that sizeof(uint) == sizeof(uint32)) does not hold for BEOS
18:34:13  <TrueBrain> haha, it still does :) But okay, we don't check on it
18:34:21  <TrueBrain> so concratulations, after a detour of minutes
18:34:24  <TrueBrain> you  finally found a way
18:34:27  <TrueBrain> so you don't have to admit you are wrong
18:34:39  <TrueBrain> and that all tnx to BEOS
18:34:43  <Rubidium> ;)
18:34:53  <TrueBrain> (sorry, but you can be stubber)
18:35:04  <Rubidium> oh yes I can ;)
18:35:13  <TrueBrain> feel proud? Sad...
18:35:37  <TrueBrain> "as Patrick Stout said to" <- why is typing my name that hard?! Idiots...
18:36:43  <TrueBrain> Rubidium: but can we settle on the fact that uint is always 32bit?
18:37:22  <Rubidium> no, we can settle on the fact that we do not explicitly force uint to be 32 bits
18:37:31  <TrueBrain> besides for BEOS, we do
18:37:34  <TrueBrain> should I add that for BEOS?
18:38:54  <Rubidium> when you do that, add a check for the way the signedness for signed integers is encoded ;)
18:39:02  <TrueBrain> we don't depend on that
18:39:08  <Rubidium> we don't?
18:39:10  <TrueBrain> as long as it is one or two complement
18:39:11  <TrueBrain> we are fine
18:39:33  *** Brianetta [~brian@82-39-52-234.cable.ubr03.benw.blueyonder.co.uk] has joined #openttd
18:39:47  *** BigBB [~BigBB@p5B041084.dip0.t-ipconnect.de] has quit [Quit: BigBB]
18:39:48  *** |Jeroen| [~jeroen@d51A47061.access.telenet.be] has quit [Quit: oO]
18:39:54  <TrueBrain> (as I am sure there aren't BCDs systems in the world with signed integer support)
18:41:00  *** Wezz6400 [~Wezz6400@145-118-108-106.fttx.bbned.nl] has quit [Quit: Have a nice weekend]
18:41:24  <Rubidium> one complement means (bitwise not) ~0 == 0
18:41:30  <TrueBrain> no -0 :p
18:42:02  <TrueBrain> there are btw even systems having the binary value 00000000 meaning -127 :p
18:42:05  <TrueBrain> makes you wonder....
18:42:33  <Rubidium> some CPUs convert -0 to 0, some don't; -0 == 0 is true on some, it isn't on others
18:43:36  <Rubidium> anyway... it's all hypothetical as there is (AFAIK) no really often used CPU with those characteristics
18:44:12  <TrueBrain> there (still) are one-complement systems
18:44:17  <TrueBrain> http://devs.openttd.org/~truelight/temp.patch
18:44:17  <TrueBrain> there
18:45:00  <Rubidium> true, but are they fast enough to even run OTTD?
18:45:11  <TrueBrain> so now you want to filter on that?
18:45:26  <TrueBrain> you don't want to state uint == uint32, but you do want to state one-complement isn't important? :p
18:46:16  <Rubidium> the uint/uint32 issue was hypothetical too
18:46:24  <TrueBrain> really?
18:46:44  <TrueBrain> most of us only care about reality ;)
18:46:52  *** Gonozal_VIII [~Gonozal_V@N779P023.adsl.highway.telekom.at] has quit [Ping timeout: 480 seconds]
18:47:39  <Rubidium> true, but ... not everything is applied mathematics either, there's theoretical mathematics too
18:47:48  <TrueBrain> so, should I apply this patch?
18:48:06  <TrueBrain> as I really like to say: uint == uint32
18:49:38  *** LeviathNL [~thomas@vdburgt.xs4all.nl] has joined #openttd
18:49:43  <Rubidium> don't think it's really necessary, just drop BEOS ;)
18:50:52  <TrueBrain> when was the last time someone compiled for BEOS?
18:50:55  <TrueBrain> who maintains BEOS anyway?
18:51:02  <Rubidium> nobody?
18:51:09  <TrueBrain> so I guess it is dropped :p
18:51:10  <Rubidium> 0.3.0?
18:51:55  <TrueBrain> so, uint == uint32?
18:52:41  *** [wtc7SG] [~utdoom@80.217.198.179] has quit []
19:02:40  *** Gonozal_VIII [~Gonozal_V@N779P008.adsl.highway.telekom.at] has joined #openttd
19:03:15  *** skidd13 [~skidd13@p548A509E.dip.t-dialin.net] has joined #openttd
19:05:40  <TrueBrain> hi skidd13
19:05:52  <TrueBrain> we welcome you in this warm channel of debates about nothing :)
19:05:54  <TrueBrain> (hehe)
19:06:48  <skidd13> Whats up in here?
19:06:53  *** Wolf01 is now known as Wolf01|AWAY
19:07:22  <TrueBrain> people :)
19:07:30  <TrueBrain> and currently, my food :)
19:07:31  <fjb> Hi skidd13, they were killing time by counting bits.
19:08:28  <skidd13> lol
19:08:28  <skidd13> crowd_bits = 0x00; // Stop wasting the time :P
19:09:03  <TrueBrain> I should be doing things, but I hate doing things
19:10:37  <skidd13> I'm off bowling. CU folks
19:10:41  *** skidd13 [~skidd13@p548A509E.dip.t-dialin.net] has left #openttd [ZZZzzzz.]
19:10:41  <TrueBrain> have fun!!
19:10:43  <TrueBrain> too late...
19:14:18  * Gonozal_VIII does things
19:15:08  <Gonozal_VIII> i made a screenshot of my best roro entry design :-)
19:17:28  <fjb> The station entry is usually not my problem.
19:17:43  <Gonozal_VIII> exit?
19:19:32  <Gonozal_VIII> i think that is the easiest part
19:22:11  <Gonozal_VIII> there hast to be at least a train length after the platforms before the merge but that shouldn't be a problem
19:23:48  <fjb> The problem is the connection betwenn the sttions. I hate to build this stupid overtaking sections. They never work like intended.
19:24:30  <fjb> Stration entry and exit are symetric in my networks.
19:25:05  <Gonozal_VIII> i try not to mix trains with different speeds
19:25:30  <Gonozal_VIII> http://gonozalviii.go.funpic.de/station.png <-- that's my entry
19:27:51  <fjb> I usually can harly avoid to mix trains aof different speeds. Or else I wouls have to terraform the whole world.
19:28:53  <Gonozal_VIII> i use dbsetxl, the wagon maxspeeds are pretty low, they reach their max speed fast
19:29:16  <fjb> I use it too.
19:29:30  <Gonozal_VIII> passengers are a different network...
19:30:30  <fjb> I just build some main lines an connect everything to them.
19:31:19  <fjb> Hm, where can I put a screenshot of my station design?
19:32:13  <Gonozal_VIII> i don't know, just used my webspace
19:32:45  <fjb> Myx webserver is down at the moment.
19:32:49  <fjb> My
19:33:09  <fjb> Hm, there is a srennshot section at the forum.
19:36:21  <Gonozal_VIII> i think i found a bug in my own picture^^ there should be an exit signal after the depot, not entry like i wrote
19:38:03  *** LeviathNL [~thomas@vdburgt.xs4all.nl] has quit [Quit: Leaving]
19:38:32  <Ammler> fjb: http://myimg.de
19:39:04  <fjb> Ammler: Thank you
19:39:50  <Ammler> different speed network is something I miss on coop servers
19:44:13  <Gonozal_VIII> in my experience split and merge again for overtaking causes more troubles than it solves
19:44:46  <TrueBrain> the speed-limit patch is nice, but indeed, it gives more network problems than it solves
19:45:42  <fjb> Here it is: http://www.myimg.de/?img=UniversalTransport16No1390d.png
19:45:59  <fjb> Wagon speed limits make the game more realistic.
19:46:10  <fjb> And the game is still easy enough.
19:46:17  <Gonozal_VIII> that's right
19:47:02  <Gonozal_VIII> and more use for rvs, as they are faster than some of the wagons
19:47:43  <Gonozal_VIII> like sand and limestome with ecs... max speed is 80 km/h
19:48:41  <fjb> Yes, but I think it is kind of a bug that there is only one wagon availlable for sand.
19:48:43  <Ammler> fjb: but you don't have many trains..., then it works
19:48:55  *** BiA|pavel-css [~pavel.g@48.140.broadband2.iol.cz] has joined #openttd
19:48:58  <Ammler> else you could block the station
19:49:22  <Ammler> if at same time 2 trains try to enter same plattform
19:49:29  <Gonozal_VIII> looks realistic but not very efficient
19:49:43  *** Zuu [~Leif@c-153c71d5.025-58-6e6b702.cust.bredbandsbolaget.se] has joined #openttd
19:49:51  <hylje> yes to road classes!
19:50:01  <fjb> I tested it. It is really efficient. Here is a more efficient version: http://www.myimg.de/?img=UniversalTransport16Nof572e.png
19:50:03  <hylje> from dodgy path to highway
19:50:56  <fjb> Ammler: two trains trying to enter the same platform can happen, but the timing must be very bad.
19:51:13  *** dihedral [~dihedral@dslb-084-056-212-166.pools.arcor-ip.net] has joined #openttd
19:51:58  <hylje> fjb: it's a small chance of deadlock by itself
19:52:15  <hylje> fjb: so it's not showing up in coop at least
19:53:00  <Gonozal_VIII> no not deadlock... there are no signals for a long discance, the trains would turn around after some time
19:53:15  <Gonozal_VIII> -c+t
19:53:34  <hylje> for that some time then
19:53:35  <fjb> I didn't have any deadlock with that design yet, even with many trains.
19:54:41  <Ammler> fjb: if this station type would be efficent, we would use it on our servers :P
19:54:59  <Gonozal_VIII> would be better with pbs
19:55:24  <Ammler> Gonozal_VIII: you will have more problems with pbs then, not less
19:55:31  <hylje> pbs makes stuff like that easier
19:55:35  <hylje> but not necessarily better
19:55:35  <fjb> It would be much better with better signlas. :-)
19:56:19  <Gonozal_VIII> btw why are there two combos before the station?
19:56:35  <Ammler> fjb: how do the inner 4 plattforms enter the depot?
19:56:40  <fjb> Yes, I will take a better screen shot.
19:57:17  <fjb> Ammler: They don't have a depot. But there are more depots at the entry and exit of the station.
19:57:19  <Ammler> only 2
19:57:33  <hylje> i heard something happened over at netherlands
19:57:43  <Gonozal_VIII> flood?
19:58:11  <Ammler> fjb: nice airport?
19:58:35  <Gonozal_VIII> but not nice crash^^
19:59:36  <fjb> The crash was not itended...
19:59:41  <Ammler> fjb: also that house on the left border, from which Set are they?
20:00:01  <fjb> Here you can see the signlas better: http://www.myimg.de/?img=UniversalTransport16No8e594.png
20:00:10  <Gonozal_VIII> ecs i think
20:00:12  <fjb> Ammler: which of the houses?
20:00:23  <fjb> Most are TTRS.
20:00:24  <Ammler> the big white one
20:00:34  <Ammler> never saw that
20:00:43  <Gonozal_VIII> small construction thing?
20:00:50  <Ammler> like a storage hall
20:01:06  <Gonozal_VIII> i think that's what it is
20:01:53  <fjb> Ah, yes, with the green roof. that is from ECS.
20:02:18  <Ammler> and the airport?
20:02:43  <Ammler> but generally nice looking style fjb
20:03:06  <Gonozal_VIII> i think i have almost the same grfs
20:03:49  <fjb> The airport is from the combined airport set. Should be at GRF crawler.
20:04:41  <fjb> I think most are using that grfs, maybe exchanging the uk set for ECS and DBset.
20:05:19  <fjb> I like it when the land is not just flat, I like it looking a bit like nature. :-)
20:05:34  <fjb> And I had a model railway, whne I was young...
20:06:15  <Gonozal_VIII> http://gonozalviii.go.funpic.de/grflist.txt
20:07:27  <Ammler> an225_gr.grf <-- aircraft?
20:07:33  <Gonozal_VIII> yes
20:07:38  *** BigBB [~BigBB@p5B0407F0.dip0.t-ipconnect.de] has joined #openttd
20:07:39  <Ammler> and how is ECS working?
20:07:53  <Ammler> most of them are still alpha
20:07:54  <Gonozal_VIII> can load everything
20:08:04  <Gonozal_VIII> it's set to anything but passengers
20:08:18  <Ammler> tourists?
20:08:25  <Gonozal_VIII> hmmm
20:08:30  <fjb> Most of ECS is working, and it is fun to use, even if many things are alpha. But it's all still new.
20:08:48  <Gonozal_VIII> i think that includes tourists... have to look
20:08:50  <fjb> Tourists are fine.
20:08:55  <Ammler> we never played ECS seriously yet
20:09:15  <dihedral> we should :-)
20:09:25  <Ammler> Gonozal_VIII: yes it has, they are in the town vector I guess
20:10:07  <Gonozal_VIII> yes can load tourists... that's not right...
20:10:14  <Gonozal_VIII> but minor problem
20:10:23  <Ammler> Gonozal_VIII: could you make a nice (and working) scenario for us?
20:10:57  <Gonozal_VIII> hmm i never made a scenario
20:11:06  <Ammler> :)
20:11:27  <Gonozal_VIII> only played random maps...
20:11:27  <dihedral> first time for everything :-)
20:12:10  <fjb> Here is one of the small harbours and a small private railway: http://www.myimg.de/?img=UniversalTransport25Noeeff6.png
20:13:18  <Gonozal_VIII> rÃŒsselbrÃŒcken^^ funny town name
20:13:26  <Gonozal_VIII> +s
20:13:42  <Ammler> hmm, fjb, the patch for better looking newwater seems to work well
20:14:00  <fjb> Yeah, some of the german town names in the game are really funny.
20:14:03  <Ammler> we have patched our member server with it
20:14:22  <dihedral> since when that Ammler ?
20:14:33  <Ammler> since about 2 hours
20:14:36  <dihedral> oh
20:14:36  <Ammler> :)
20:14:37  <dihedral> ok
20:14:39  <Gonozal_VIII> are there no signals at the harbour station?
20:14:39  <dihedral> :-P
20:14:53  <fjb> I didn't apply any path in that game. It's play r11386.
20:15:18  <dihedral> ...
20:15:20  <dihedral> hmmm
20:15:28  <fjb> No signals because there is only one track, used in both directions.
20:15:49  <Gonozal_VIII> but three platforms
20:16:08  <fjb> Yes, for trains waiting for their cargo.
20:16:39  <Gonozal_VIII> buuuut.. they don't enter without signals? or are there some hidden under the road bridge?
20:16:39  <Ammler> fjb: its better, I am not sure if it will be loadable in trunk later
20:17:20  <fjb> Oh, sorry, there is a signal in front of every platform of course. they are under the bridge.
20:18:09  <fjb> The only patch I'm experimenting with is the passenger destination patch. But that was another game.
20:18:42  <Gonozal_VIII> passenger destination will be nice when it's ready
20:19:05  <Gonozal_VIII> i've played several games with old versions
20:20:02  <TrueBrain> I am so bored! Oh boy oh boy
20:20:07  <TrueBrain> is the coop game any good lately?
20:20:20  <Gonozal_VIII> don't know
20:21:01  <fjb> TrueBrain: Start implementing PBS. :-)
20:21:56  <Ammler> hmm, we started a newcargo.grf game at the Member Zone, with the sharing patch
20:22:06  *** Peakki [antti@cs181247045.pp.htv.fi] has joined #openttd
20:22:20  <Gonozal_VIII> or a system where the trains are dumb and the switches do the path calculating (programmable)
20:22:34  <Belugas> [15:22] <TrueBrain> I am so bored! Oh boy oh boy  <--- I would gladly trade places :S
20:22:38  <Ammler> fish and chips, ahm beer
20:22:52  <Ammler> Belugas: he is just joking, I guess
20:22:54  <TrueBrain> Belugas: I should be doing.. well... alot
20:23:01  <TrueBrain> I just don't have anyone breathing down my neck to really do it
20:23:05  <TrueBrain> so... I don't do it :)
20:23:12  <Ammler> :)
20:23:14  <TrueBrain> Ammler: cool! Can I join? :)
20:23:22  <TrueBrain> fjb: I won't do PBS
20:23:55  <fjb> TrueBrain: Was just a thought...
20:24:00  <TrueBrain> fjb: I know
20:24:06  <TrueBrain> and if I knew I could do it, I would
20:24:08  <TrueBrain> but I know I can't :)
20:24:13  <Ammler> hmm, Truelight is the honorary member
20:24:17  <TrueBrain> Ammler: I know :)
20:24:19  <fjb> The next plain crash...
20:24:33  <Belugas> TrueBrain : http://bugs.openttd.org/task/1414
20:24:40  <Belugas> initiation to grf operations :D
20:25:00  <TrueBrain> newgrf... brr :)
20:25:16  <Gonozal_VIII> yes... i would never take a plane in the openttd world
20:25:55  <fjb> Why do they allway fall onto the airports. .-(
20:26:06  <Ammler> TrueBrain: if you like to take a look, you know our place...
20:26:24  <TrueBrain> Ammler: I wish :) I come from the time there wasn't a member server ;)
20:27:15  <Gonozal_VIII> chrisin has a patch for plane crash frequency... would be nice in trunk
20:27:33  <Eddi|zuHause2> fjb: most of the accidents happen on starting or landing
20:27:38  <fjb> Ammler: If you look closely, you can see some trams and some trucks from the long vehicles here: http://www.myimg.de/?img=UniversalTransport21Debec7c.png
20:27:43  <Ammler> ah, come on, I can remember how you complained about the new building style on the Werklose desync
20:28:06  <TrueBrain> Ammler: that was ment for me? As I hav eno idea what you are talking about :s
20:28:12  <fjb> Eddi|zuHause2: I know, that is real. I was only complaining because they were my airports... :-)
20:28:50  <Ammler> hmm, Mucht is ill and can't help...
20:29:07  <Ammler> TrueBrain: its about 14 months
20:29:08  <fjb> I don't mind those crashes, they are part of the game. But I have to colain if it happens to me.
20:29:22  <TrueBrain> Ammler: ah, my memory stops working after 2 months :)
20:31:02  * fjb loves trams.
20:31:35  <Gonozal_VIII> me too
20:32:10  <TrueBrain> here they drive against busses
20:32:13  <TrueBrain> less amuzing ;)
20:32:14  <Gonozal_VIII> which tramset do you use?
20:32:28  <fjb> The dutch tram set.
20:32:53  <fjb> The busses must not stop at the wrong place...
20:33:58  <Gonozal_VIII> ah i haven't yet looked at that, wasn't out when i tested trams
20:34:06  *** Dephenom [~paul@91.186.11.8] has quit [Quit: Leaving]
20:34:30  *** Dephenom [~paul@91.186.11.8] has joined #openttd
20:34:36  <Gonozal_VIII> i choose the serbian trams
20:34:54  <fjb> The dutch trams are articulated. :-)
20:35:20  <hylje> The dutch trams are overrated. :-)
20:36:04  <fjb> Maybe, but there is not much better out there yet. Other sets are only availlable to beta testers.
20:37:05  <fjb> The generic tram set has articulated trams, too. But I didn't like that set that much. It was too generic for my taste.
20:37:18  <Gonozal_VIII> hehe
20:37:54  <fjb> And I patched the dutch tram set to cooperate nicely with the long vehicles. :-)
20:40:12  <Gonozal_VIII> hmm the passenger numbers are very low... is that per vehicle part?
20:40:37  <Gonozal_VIII> ah yes ok
20:40:40  <fjb> Yes, per part.
20:41:04  <hylje> shouldnt articulated rvs show the full cap?
20:41:19  <hylje> because, well, one gets the full vehicle instead of a loco and cars
20:41:26  <hylje> (same with multiple part rail vehicles?)
20:42:22  <fjb> It shows the full capacity in the vehicle info, but not in the list of buyalble vehicles.
20:44:39  <Gonozal_VIII> it doesn't look very good in curves, they get seperated too far...
20:45:13  <fjb> But it looks far better than the long busses...
20:45:28  *** mikk36 [~mikk36@pc97.host5.starman.ee] has joined #openttd
20:45:31  <mikk36> hey :)
20:45:31  <Gonozal_VIII> ok that's true
20:45:34  <Gonozal_VIII> hi
20:45:52  <mikk36> is there any particular reason for openttd being so cpu-hungry in vista ?
20:45:53  <fjb> Hi mikk36
20:46:09  <Gonozal_VIII> yes, vista sucks
20:46:13  <fjb> Depends on the size of your cpu...
20:46:16  <Gonozal_VIII> imho
20:46:34  <mikk36> fjb, same cpu -> xp usage 1-2%, vista usage 60+%
20:47:01  <mikk36> A64 3200+
20:47:04  <fjb> Oh, strange. But I don't use Windows, so i'm no expert for that.
20:47:19  <mikk36> shouldn't be a slow cpu :)
20:47:29  * fjb uses the same cpu.
20:47:45  <TrueBrain> mikk36: I guess it isn't OpenTTD, but Vista ;)
20:48:05  <Gonozal_VIII> i think vista isn't really ready yet
20:48:19  <fjb> Only chirsin with the grass growing on tracks makes the game really slow with many trains.
20:48:24  <mikk36> i do have slightly less performance in vista (from 5 to 20%, but nowhere as close as with openttd)
20:48:57  <mikk36> openttd is just crazyly slow in vista
20:49:09  <fjb> OpenTTD is designed not vor Vista. :-)
20:49:19  <mikk36> 512x256 map moderately filled -> stable 100% cpu
20:49:31  <mikk36> that is about 100 trains
20:50:32  <fjb> Did you try the same save on XP?
20:52:44  <Gonozal_VIII> [21:37:53] fjb: And I patched the dutch tram set to cooperate nicely with the long vehicles. :-) <-- would you give me that version please?
20:54:31  <mikk36> fjb, a new game, about 10 trains, 50% cpu
20:55:00  *** BigBB [~BigBB@p5B0407F0.dip0.t-ipconnect.de] has quit [Remote host closed the connection]
20:55:39  *** BigBB [~BigBB@p5B0407F0.dip0.t-ipconnect.de] has joined #openttd
20:55:50  <Gonozal_VIII> switch on fast worward and look how long a year takes with the same save in xp and vista
20:56:01  <Gonozal_VIII> f
20:56:24  <mikk36> i don't have xp next to me
20:57:07  <dihedral> would it be possible for multi core systems to add a command line option, with which one could specify at least which core the game should use?
20:57:49  <dihedral> TrueBrain? ^ that line :-)
20:57:50  <fjb> Gonozal_VIII: Here is the diff to the .nfo in the grf. You have to use grfcodec and patch: http://www.tt-forums.net/download.php?id=80634
20:58:08  <TrueBrain> dihedral: no
20:58:11  <TrueBrain> now that was easy :)
20:58:17  <SmatZ> hi
20:58:19  <TrueBrain> you can control it in Windows I believe, via Task Manager
20:58:25  <TrueBrain> but it really is up to the OS in my opinion
20:58:32  <TrueBrain> hi SmatZ :) Nice to have you back!
20:58:38  <Ammler> how with linux?
20:58:41  <Gonozal_VIII> thanks fjb
20:58:53  <Ammler> (choose the core, I mean)
20:58:53  <fjb> Hi SmatZ
20:58:55  <TrueBrain> Ammler: as far as I know, it does a good job :)
20:59:06  <Ammler> you mean automatically.
20:59:11  <TrueBrain> yup
20:59:18  <SmatZ> hello TrueBrain, I am with my girlfriend for whole weekend, so no OTTD development... ;-)
20:59:19  <mikk36> in win: task manager -> set affinity
20:59:27  <TrueBrain> SmatZ: bah, girlfriends...
20:59:29  <SmatZ> hello fjb, have a nice friday!
20:59:33  <TrueBrain> mine always want to take me away from OTTD too :p
20:59:37  <SmatZ> :-D
20:59:51  <dihedral> TrueBrain: try reversing that
20:59:51  <SmatZ> yes, she is saying my name
20:59:56  <SmatZ> to stop typing here :-p
20:59:59  <fjb> SmatZ: Thank you. And be carefull what you are developping. :-)
21:00:05  <SmatZ> :-)
21:00:16  <TrueBrain> SmatZ: always when I continue to type things
21:00:19  <TrueBrain> she gets... well..
21:00:22  <TrueBrain> purchasive
21:00:24  <TrueBrain> in a good way ;)
21:00:34  <TrueBrain> always nice to end.. well... there are underaged children here ;)
21:01:04  <fjb> TrueBrain: just say busses and long vehicles. :-)
21:01:28  <TrueBrain> more: depot and long vehicle (both not plural)
21:01:49  <fjb> :-D
21:01:59  *** Soup [~Soup@66-230-114-105-dsl-rb1.nwc.acsalaska.net] has joined #openttd
21:02:14  <Soup> hi
21:02:21  <Ammler> welcome back Soup
21:02:39  <Soup> can  i play #openttdcoop
21:02:43  <TrueBrain> ....
21:02:47  <Soup> ?
21:02:54  <TrueBrain> Ammler: did I saw him asking what I thought he was asking?
21:02:58  <SmatZ> TrueBrain: hmmm maybe I could try that strategy ;-)
21:03:11  <TrueBrain> SmatZ: it only works N times ;)
21:03:12  <Ammler> Soup: how is your virus?
21:03:19  <dihedral> lol
21:03:21  <dihedral> classic
21:03:22  <Soup> broken
21:03:26  <Ammler> :)
21:03:37  <TrueBrain> can I play with my train?
21:03:49  * dihedral pats TrueBrain on the head
21:03:54  <dihedral> sure you can
21:04:03  <TrueBrain> people can ask such weird questions
21:04:20  <dihedral> in some cases it can however be amusing :-P
21:04:31  <Soup> * Soup hits himselft on a wall
21:05:01  <Soup> owww!!!!
21:05:13  *** bob27 [~Robert@adsl-75-36-11-95.dsl.bcvloh.sbcglobal.net] has joined #openttd
21:05:16  <Gonozal_VIII> you broke a virus?
21:05:22  <TrueBrain> or your train?
21:05:26  <dihedral> it got infected :-D
21:05:39  * dihedral also hits soup against a wall
21:05:51  <TrueBrain> that aint nice
21:05:59  <Gonozal_VIII> don't make a mess
21:06:01  <dihedral> i was being helpful
21:06:05  <dihedral> at least he does not have to do those things all by himself
21:06:22  *** SRCR [~Peter@a80-127-87-78.adsl.xs4all.nl] has joined #openttd
21:06:49  <Soup> o w w!
21:07:02  <TrueBrain> Soup: you are starting to annoy me
21:07:06  <TrueBrain> in general, it is a bad idea to annoy me
21:07:31  <SRCR> I have started a dedicated server but i would like to start a map in 1024*1024 where do i set that (I keep getting the 256*256)
21:07:46  <TrueBrain> SRCR: either start the game normally and change it via the GUI
21:07:48  <TrueBrain> or change openttd.cfg
21:07:51  <TrueBrain> see wiki page for more info
21:07:59  <Soup> yeah
21:08:06  <dihedral> TrueBrain: soup got himself banned from #openttdcoop, #openttdcoop.dev and #wwottdgd
21:08:20  <TrueBrain> dihedral: ah :) So it won't be long? :)
21:08:32  <TrueBrain> oh joy oh joy oh joy :) Am I looking forward to this :)
21:08:32  <dihedral> lol
21:08:39  <dihedral> we shall lose all that fun
21:08:42  <Gonozal_VIII> what did he do?
21:08:43  <dihedral> it's so amusing
21:08:50  <SRCR> thanks.. I'll have a look (In my case it's openttd.cfg) my server is non graphical
21:08:52  <TrueBrain> dihedral: so.. can I toy with him then?
21:08:58  <Ammler> Gonozal_VIII: nothing, his virus is doing all that
21:08:59  <TrueBrain> SRCR: good choice :)
21:09:02  <dihedral> or - TrueBrain: you could setup a honypot irc server, emulating certain nicks :-D
21:09:05  <TrueBrain> wiki page explains most things about openttd.cfg, SRCR
21:09:09  <TrueBrain> let us know when you need any more info
21:09:18  <Gonozal_VIII> aaah irc virus
21:09:26  <Soup> nope
21:09:33  <TrueBrain> dihedral: in fact, it is just a nice idea to do that
21:09:34  <dihedral> with a honeypot irc server, you'd at least get all the nice conversation
21:09:35  <TrueBrain> in general
21:09:37  <Ammler> a java virus
21:09:42  <Soup> no
21:09:44  <dihedral> lol
21:09:55  <Gonozal_VIII> virus
21:09:58  <Soup> no
21:10:01  <Gonozal_VIII> ^^
21:10:14  <TrueBrain> Average responce-length of Soup: 4 letters
21:10:14  <Soup> <> cracked egg
21:10:16  <TrueBrain> I am impressed
21:10:18  <TrueBrain> he can type!
21:10:18  * fjb rememberes Eliza.
21:10:26  *** bob27 [~Robert@adsl-75-36-11-95.dsl.bcvloh.sbcglobal.net] has left #openttd []
21:10:38  <dihedral> lol
21:10:45  <dihedral> this is just too great
21:10:51  <Soup> :)
21:10:57  <dihedral> no - not you
21:10:58  <dihedral> :-P
21:11:00  <TrueBrain> oh, the average just dropped to 3 letters
21:11:02  <Soup> :):):):)
21:11:06  <TrueBrain> hmm, now 4 again
21:11:08  <TrueBrain> stop doing that
21:11:10  * dihedral slaps Soup
21:11:11  <fjb> No letters anymore...
21:11:35  <Soup> i lauged  myselft
21:11:45  *** KritiK [~Maxim@78-106-156-108.broadband.corbina.ru] has joined #openttd
21:12:10  <dihedral> i bet that nick aint registered... :-P
21:12:16  <Eddi|zuHause2> we should talk german... words tend to get much longer there :)
21:12:21  <Soup> registerd
21:12:26  <dihedral> lol Eddi|zuHause2
21:12:31  <fjb> No problem.
21:12:50  <Gonozal_VIII> DonaudampfschifffahrtsgesellschaftskapitÀn :-)
21:12:58  <Soup> #openttdcoop.dev slaps german
21:13:06  <fjb> No, wrong.
21:13:11  <TrueBrain> Soup: here we only slap you
21:13:24  * dihedral points at soup and laughs
21:13:34  <fjb> OberweserdampfschifffahrtsgesellschaftskapitÀn
21:13:50  <dihedral> supercalifragilisticexpialidocious
21:13:50  <Eddi|zuHause2> OberweserdampfschifffahrtsgesellschaftskapitÀnsmÌtzenabzeichen
21:14:07  <Gonozal_VIII> RheinmaindonaukanaldampfschifffahrtsgesellschaftskapitÀn :P
21:14:16  <Belugas> these are real words????
21:14:20  <dihedral> yep
21:14:24  <hylje> three f:s?
21:14:26  <Soup> OMG
21:14:29  <Belugas> insane...
21:14:29  <dihedral> yep
21:14:31  <fjb> OberweserdampfschifffahrtsgesellschaftskapitÀnsmÌtzenabzeichenhersteller
21:14:35  <Soup> OMG
21:14:36  <dihedral> shiff < 2 f's
21:14:40  <Eddi|zuHause2> hylje: yes, since the 1996 spelling reforme
21:14:42  <dihedral> fahrt < one f
21:14:43  <Eddi|zuHause2> -e
21:14:52  <dihedral> shifffahrt
21:15:01  <fjb> Schiffahrt
21:15:01  <Gonozal_VIII> schifffahrt is 3 f
21:15:04  <Soup> ORUDGE SLAPS #OPENTTD
21:15:10  <fjb> Schifffahrt
21:15:16  <dihedral> votemute....
21:15:23  <Soup> ?
21:15:25  * dihedral votes for soup
21:15:34  <TrueBrain> @kick Soup enough
21:15:34  <DorpsGek> TrueBrain: Error: I need to be opped to kick someone.
21:15:36  <TrueBrain> grr
21:15:36  <fjb> aol
21:15:43  <TrueBrain> Belugas: can you +o DorpsGek?
21:15:57  *** mode/#openttd [+o DorpsGek] by Belugas
21:15:59  <TrueBrain> @kick Soup enough
21:15:59  *** Soup was kicked from #openttd by DorpsGek [enough]
21:15:59  <TrueBrain> tnx
21:16:08  *** Soup [~Soup@66-230-114-105-dsl-rb1.nwc.acsalaska.net] has joined #openttd
21:16:18  <Eddi|zuHause2> be wewwy quiet, i'm hunting wabbits
21:16:19  <fjb> It didn't help.
21:16:23  <Soup> end of the war
21:16:27  <Belugas> anything to help you, TrueBrain
21:16:33  <Soup> this borring
21:16:49  <TrueBrain> you know your way to the exit?
21:17:17  <Soup> nope
21:17:35  <TrueBrain> @op
21:17:38  *** mode/#openttd [+o TrueBrain] by DorpsGek
21:17:40  *** mode/#openttd [+b *!*@66-230-114-105-dsl-rb1.nwc.acsalaska.net] by TrueBrain
21:17:46  <TrueBrain> let me help you in the general direction
21:17:53  <fjb> Just follow DorpsGek
21:19:24  *** SRCR [~Peter@a80-127-87-78.adsl.xs4all.nl] has left #openttd []
21:21:08  *** Soup [~Soup@66-230-114-105-dsl-rb1.nwc.acsalaska.net] has quit [Quit:  HydraIRC -> http://www.hydrairc.com <- Po-ta-to, boil em, mash em, stick em in a stew.]
21:21:19  *** mode/#openttd [-b *!*@66-230-114-105-dsl-rb1.nwc.acsalaska.net] by TrueBrain
21:21:25  <TrueBrain> I didn't even had to kick him...
21:21:31  *** BiA|pavel-css [~pavel.g@48.140.broadband2.iol.cz] has quit []
21:22:20  <fjb> Strange guy...
21:22:24  <TrueBrain> you guys don't have to stop talking ;)
21:22:31  <Eddi|zuHause2> i'm sure you figure something out to satisfy your needs ;)
21:22:41  <TrueBrain> @kick Eddi|zuHause2 tnx for volunteering :)
21:22:41  *** Eddi|zuHause2 was kicked from #openttd by DorpsGek [tnx for volunteering :)]
21:22:48  *** Eddi|zuHause2 [~johekr@p54B7720E.dip.t-dialin.net] has joined #openttd
21:22:48  <TrueBrain> really, this becomes too easy.....
21:22:49  <TrueBrain> @deop
21:22:49  *** mode/#openttd [-o TrueBrain] by DorpsGek
21:23:10  <fjb> Where did Eddi go? :-)
21:23:21  * TrueBrain hugs Eddi|zuHause2 :)
21:23:23  <Eddi|zuHause2> i'm right here...
21:23:40  <fjb> Ah, ok, I didn't see you.
21:24:05  * fjb needs a nfo disassembler...
21:24:14  * fjb needs his dragon book.
21:24:43  <hylje> here be dragons
21:25:09  *** Soup [~Soup@66-230-114-105-dsl-rb1.nwc.acsalaska.net] has joined #openttd
21:25:25  <TrueBrain> Soup: this is the last time we are this nice
21:25:30  <TrueBrain> next time it really is a kick+ban
21:25:37  *** Farden123 [~jk3farden@AMontsouris-156-1-175-213.w83-202.abo.wanadoo.fr] has joined #openttd
21:25:38  <Soup> ok i see
21:25:49  <Gonozal_VIII> chase the dragon!
21:25:58  * hylje runs away
21:26:53  <Soup> slap me
21:27:03  <Gonozal_VIII> no?
21:27:22  <Soup> oh
21:27:37  <Eddi|zuHause2> this reminds me of the talk like pirate day
21:27:55  <Gonozal_VIII> the what?
21:28:24  * fjb found it: COMPILERS Principles, Techniques and Tools (c) 1986, 1987 by Bell Telephone Laboratories Inc.
21:28:36  <Soup> wow
21:29:19  <Eddi|zuHause2> Gonozal_VIII: http://qdb.us/67325
21:29:26  *** dihedral [~dihedral@dslb-084-056-212-166.pools.arcor-ip.net] has quit [Quit: ChatZilla 0.9.78.1 [Firefox 2.0.0.9/2007102514]]
21:30:35  *** G [~njones@202-154-147-204.ubs-dynamic.connections.net.nz] has joined #openttd
21:30:43  <fjb> Gonozal_VIII: Dragon book, not dragon smoke...
21:31:11  <Eddi|zuHause2> @seen Prof_Frink
21:31:12  <DorpsGek> Eddi|zuHause2: Prof_Frink was last seen in #openttd 1 day, 20 hours, 37 minutes, and 12 seconds ago: * Prof_Frink constrains Eddi|zuHause3 to the x-y plane
21:31:15  <Soup> how do i use distcc
21:31:31  <Eddi|zuHause2> read the wiki
21:31:33  <TrueBrain> ./configure --enable-distcc
21:31:39  <TrueBrain> and read some good distcc documentation
21:31:45  <Soup> ok
21:32:14  *** Farden [~jk3farden@AMontsouris-156-1-155-167.w83-202.abo.wanadoo.fr] has quit [Ping timeout: 480 seconds]
21:32:14  *** Farden123 is now known as Farden
21:32:24  <Soup> what os it works
21:32:30  <Ammler> hmm, what is distcc?
21:32:39  <TrueBrain> many, as long as it has a *nix prompt I guess
21:32:44  <TrueBrain> (so mingw for windows, and *nix)
21:32:48  <TrueBrain> Ammler: distribute CC
21:32:48  <Soup> ok
21:33:24  <Eddi|zuHause2> Ammler: like compile on multiple processors simultaneously
21:33:34  <TrueBrain> only not on one computer ;)
21:33:49  <Soup> distcc bineaes http://distcc.samba.org/binaries.html
21:33:56  <Eddi|zuHause2> nobody excluded that ;)
21:34:34  * Ammler is checking If suse does have that
21:34:47  <TrueBrain> Ammler: all linux distros do
21:34:52  <Soup> yup
21:35:08  <Soup> even cygwin
21:35:14  *** BigBB [~BigBB@p5B0407F0.dip0.t-ipconnect.de] has quit [Remote host closed the connection]
21:35:14  <Soup> has it
21:35:18  <fjb> One big OpenTTD game on a server farm? :-)
21:35:20  <Ammler> but its not a virus :P
21:35:29  <TrueBrain> fjb: euh, no
21:35:31  <Soup> wow
21:35:46  <Eddi|zuHause2> fjb: no, not DistTT :p
21:35:58  <Ammler> fjb: you also need to have the clients there then
21:36:08  <hylje> dttd
21:36:17  <fjb> :-)
21:36:30  <Ammler> we tried to run a client over ssh -x
21:36:35  <hylje> my far-future ttd clone/continuation will do just that
21:36:37  <Ammler> for wwottdgd
21:36:39  <fjb> What is is goot for then? Just compiling on the server farm?
21:37:27  <fjb> Ammler: how was the ssh forwarding working?
21:37:35  <Gonozal_VIII> ah truelight that reminds me of something about your server/client openttd... if every player is client and server at the same time with a part of the map on each pc, the max map size would be lots bigger
21:37:46  <Eddi|zuHause2> fjb: any multi-core computer can profit from that...
21:37:52  <Ammler> it seems x needs much more cpu then dedicated
21:38:01  <TrueBrain> Gonozal_VIII: there is more to it then just that ;)
21:38:11  <Ammler> server couldn't handle the game
21:38:15  <TrueBrain> Eddi|zuHause2: for local computer compilation, you have 'make -jN', not distcc
21:38:18  <hylje> TrueBrain: so you though of that too
21:38:32  <TrueBrain> hylje: I had various 'speeches' here and drafts about it
21:38:44  <Eddi|zuHause2> well, i don't have a multi-core ;)
21:38:52  <hylje> okay
21:39:03  <TrueBrain> hylje: I can talk 60 minutes long about the idea ;)
21:39:06  <TrueBrain> and the inpact
21:39:11  <TrueBrain> and ways to approach it :p
21:39:31  <Soup> a laptop and a single desktop is much faster than a laptop alone. wow
21:39:34  <hylje> i can picture that
21:39:55  *** TinoM [~Tino@i5387C48A.versanet.de] has quit [Quit: Verlassend]
21:39:58  <Soup> found at distcc site http://distcc.samba.org/
21:41:51  <fjb> make -jN also helps on single core.
21:42:42  <TrueBrain> fjb: not really, the default value is prefect (if you didn't change it ;))
21:43:20  * fjb only tried it with BSD make.
21:45:55  <Phazorx> disttt can be posisble if you do somewhat a portal system, then you can do geobased split between servers to localize area of responsibility
21:46:03  <Phazorx> like BigWorld does it
21:46:22  <Phazorx> or lower end implementations similar to WoW or UO/EQ
21:46:43  *** thgergo [~Administr@dsl51B7A140.pool.t-online.hu] has joined #openttd
21:46:43  <TrueBrain> Phazorx: all ideas are kind of impossible in the current design of OpenTTD
21:46:52  <hylje> yep
21:46:54  <Phazorx> of course
21:47:08  <Phazorx> any scale gain would requirw complete rewrite
21:47:50  <Phazorx> but only of network side of things if you go with portal idea
21:48:06  <Phazorx> but that will bump interserver communication to much higher level
21:48:20  <hylje> 1. python bindings for ottd
21:48:24  <hylje> 2. ???
21:48:31  <hylje> 3. profit!!
21:49:14  <Tefad> lies.
21:49:20  <TrueBrain> Phazorx: not really
21:49:23  <TrueBrain> just each object needs to gets a random-seed assigned
21:49:23  <TrueBrain> which in fact will slow down the process
21:49:29  <TrueBrain> hmm, my IRC lags 3 seconds..
21:49:29  <TrueBrain> Phazorx: you mean in the way that you can't see 2 regions at once?
21:49:32  <TrueBrain> hylje: you are weird ;)
21:50:36  *** BigBB [~BigBB@p5B0407F0.dip0.t-ipconnect.de] has joined #openttd
21:51:21  <TrueBrain> hylje: for what do you want python bindings?
21:51:42  <hylje> for.. well, doing stuff!
21:51:50  * Soup slaps Soup upside da head with a hairy goldfish
21:51:58  <Soup> oops
21:52:04  <Soup> owww
21:52:08  <fjb> Scripting some actions you would usually do manually over and over again.
21:52:09  <TrueBrain> hylje: now that clears it up ;)
21:52:15  <hylje> particularly using ottd gui stuffs for a new backend
21:52:28  <TrueBrain> hylje: hehe :) Good luck splitting off the GUI :)
21:52:35  <Soup> orudge say i
21:52:37  <TrueBrain> you can put on a webGUI ;)
21:52:41  <Soup> or slap
21:52:50  <TrueBrain> Soup: you are doing it again....
21:52:56  <Soup> jokeing
21:52:59  * Soup likes slapping people and randomly picks Soup to slap.
21:53:15  <hylje> TrueBrain: yeh, think one could start with modularizing stuff
21:53:36  <Gonozal_VIII> create your own channel, there you can slap yourself all you want
21:53:38  <TrueBrain> did you know that I considered last week writing the game in Python totally? :)
21:54:05  <TrueBrain> (via server/client model, even for localhost games)
21:55:47  <Soup> [12:53] <TrueBrain> did you know that I considered last week writing the game in Python totally? :) wow:O
21:55:49  <hylje> hehe
21:56:08  <Gonozal_VIII> with my tile number idea it would be only like 16 bit per map tile and much less traffic :-)^^
21:56:14  <hylje> that could help with thinking a design down up
21:56:22  <Sacro> @seen Bjarni
21:56:22  <DorpsGek> Sacro: Bjarni was last seen in #openttd 1 day, 1 hour, 10 minutes, and 11 seconds ago: <Bjarni> you are perfectly good at breaking the rules on your own
21:56:30  <TrueBrain> Gonozal_VIII: which 'traffic'?
21:56:42  <Gonozal_VIII> well between clients...
21:56:49  <TrueBrain> Gonozal_VIII: euh, no, that won't help
21:56:56  <Gonozal_VIII> why?
21:56:58  <TrueBrain> do you have any idea what is send between client?
21:57:07  <TrueBrain> the smallest amount of information thinkable :)
21:57:33  <Gonozal_VIII> only changes?
21:57:39  <TrueBrain> no, that would be VERY slow
21:57:42  <hylje> a whole lot of prediction and assumptions
21:57:48  <TrueBrain> each client does the gamelogic itself too
21:57:58  <TrueBrain> so, the only thing that is sent..... client actions! So, DoCommands
21:58:01  <Gonozal_VIII> yes that's how it is now
21:58:07  <TrueBrain> so, it only sends something if you build a rail
21:58:21  <TrueBrain> and not a lot, just that you want to build a rail, like a local client executed the command
21:58:25  <TrueBrain> you can't get smaller than that ;)
21:59:12  *** Osai [~Osai@pD9EB4C72.dip.t-dialin.net] has joined #openttd
21:59:18  <Gonozal_VIII> yes but if everything runs on the server or a part of the map at every client
21:59:32  <TrueBrain> ah, you mean it like that :)
21:59:41  <TrueBrain> each tick
21:59:47  <TrueBrain> I believe 1/8th of the map receives a 'tick'
21:59:50  <TrueBrain> (tiles)
21:59:51  <Soup> a banana
21:59:53  <TrueBrain> and most of the time, they change
21:59:54  <TrueBrain> @op
21:59:55  *** mode/#openttd [+o TrueBrain] by DorpsGek
21:59:58  *** mode/#openttd [+b Soup!*@*] by TrueBrain
21:59:58  *** Soup was kicked from #openttd by TrueBrain [Go kick]
22:00:09  <TrueBrain> stupid IRC client... why would it ban on the username? :s
22:00:25  <TrueBrain> anyway, Gonozal_VIII, by my calculations that would mean.. say you have a 128x128 map loaded:
22:00:29  <TrueBrain> @calc 128*128*2
22:00:29  <DorpsGek> TrueBrain: 32768
22:00:36  <TrueBrain> 32 kiB per tick...
22:00:40  <TrueBrain> @calc 128*128*2*30
22:00:40  <DorpsGek> TrueBrain: 983040
22:00:44  <TrueBrain> @calc 128*128*2*30/1024
22:00:44  <DorpsGek> TrueBrain: 960
22:00:54  <TrueBrain> 960 kiB per second...
22:01:05  <TrueBrain> or: 10 Mib/s....
22:01:18  <Gonozal_VIII> 1
22:01:20  *** [1]Soup [~Soup@66-230-114-105-dsl-rb1.nwc.acsalaska.net] has joined #openttd
22:01:24  <TrueBrain> no, B and b
22:01:31  <Gonozal_VIII> ah
22:01:36  *** mode/#openttd [+b *!*@*.nwc.acsalaska.net] by TrueBrain
22:01:36  *** [1]Soup was kicked from #openttd by TrueBrain [Go kick]
22:01:42  *** mode/#openttd [-b Soup!*@*] by TrueBrain
22:01:46  <TrueBrain> Gonozal_VIII: B = byte, b = bit
22:02:00  <hylje> good job banning a whole isp there
22:02:03  <hylje> :p
22:02:08  <TrueBrain> hylje: yeah, I fucked up again :p
22:02:13  <TrueBrain> my IRC client sucks for banning
22:02:22  *** mode/#openttd [+b *!*@66-230-114-105-dsl-rb1.nwc.acsalaska.net] by TrueBrain
22:02:25  *** mode/#openttd [-b *!*@*.nwc.acsalaska.net] by TrueBrain
22:02:33  <Gonozal_VIII> you only need the date for the part of the map on screen
22:02:35  <TrueBrain> on the other hand... the ISP deserves a ban, if they allow such users :p
22:02:37  <Gonozal_VIII> -e+a
22:02:45  <TrueBrain> Gonozal_VIII: then scrolling would be dead slow
22:02:49  <TrueBrain> (I refer to my WebTT :p)
22:03:00  <Gonozal_VIII> hehe
22:03:00  <TrueBrain> you need a surrounding to allow some kind of smooth scrolling
22:03:16  <TrueBrain> so, 128x128 I guess is the minimal setting for that
22:03:22  <TrueBrain> but even with 64x64
22:03:25  <TrueBrain> you talk about 2.5 Mib/s
22:03:39  <TrueBrain> (everything about 100 kib/s I am not even willing to consider :))
22:03:44  <TrueBrain> so, the other way around:
22:03:51  <TrueBrain> @calc 100000 / 16
22:03:51  <DorpsGek> TrueBrain: 6250
22:03:56  <TrueBrain> @calc sqrt(6250)
22:03:57  <DorpsGek> TrueBrain: 79.0569415042
22:04:04  <Gonozal_VIII> so how would your webtt work?
22:04:09  <TrueBrain> 3x3 map
22:04:41  <TrueBrain> Gonozal_VIII: currently, it caches a 32x32 map, which takes 1 second to send
22:04:51  <TrueBrain> euh, that is not true..
22:04:54  <TrueBrain> 5ms, server-load
22:04:55  <TrueBrain> but okay
22:05:07  <TrueBrain> each tile takes 20 bytes
22:05:30  <TrueBrain> anyway, WebTT can only exist if we disable the tileloop
22:05:31  *** sPooT [~spoot@spoot.xs4all.nl] has joined #openttd
22:05:31  <Gonozal_VIII> would be 2 bytes per tile with the tilenumberthing...
22:05:33  <TrueBrain> and most likely the trees
22:05:49  <TrueBrain> Gonozal_VIII: no, it has other reasons why it needs more data
22:05:56  <Gonozal_VIII> ok
22:06:04  <TrueBrain> browsers are character protocols :)
22:06:08  <TrueBrain> it needs real letters
22:06:16  <TrueBrain> and.. it needs context :)
22:06:25  <TrueBrain> so: UpdateTile(x, y, <yournumber>)
22:06:35  <TrueBrain> of course we can make it: U(x,y,<yournumber>)
22:06:38  <TrueBrain> still many chars ;)
22:07:16  <TrueBrain> anyway, for a normal client this approach can work
22:07:23  <TrueBrain> but current design of OpenTTD simply doesn't allow it
22:07:31  <TrueBrain> too much is going on :)
22:08:21  <Phazorx> TrueBrain: make your protocl on top of http
22:08:25  <Phazorx> can make it more compact
22:08:34  <hylje> :o
22:08:35  <Phazorx> headers are still huge tho
22:08:39  <TrueBrain> Phazorx: true, but it would mean you need to write that in Javascript ;)
22:08:49  <hylje> ajaxttd
22:08:55  <Phazorx> TrueBrain: you use JS already to reload
22:09:00  <TrueBrain> hylje: I showed that can be done ;)
22:09:08  <TrueBrain> Phazorx: but to decrypt such a data-stream...
22:09:09  <hylje> yes
22:09:46  <fjb> Help, the auto updating doesn't work for my road vehicles. :-( Do Ireally have to replace about 100 trucks by hand?
22:09:55  <TrueBrain> btw, Gonozal_VIII, how on earth can you pack a 9byte information packet to 2bytes?
22:09:58  <Phazorx> TrueBrain: clients can be slow :)
22:10:06  <TrueBrain> Phazorx: up to a limit ;)
22:10:18  <Phazorx> well
22:10:28  <Phazorx> you can make flshtt then
22:10:40  <Phazorx> and use free form packets on top of tcp
22:10:41  <Gonozal_VIII> well 2 bytes is about 65k numbers...
22:10:50  <Phazorx> well with some limitations of cource
22:11:02  <Gonozal_VIII> each possible tile in the game gets a unique number...
22:11:23  <Rubidium> Gonozal_VIII: how many unique numbers can you form with 9 bytes?
22:11:27  <TrueBrain> Gonozal_VIII: you mean each possible combination?
22:11:43  <TrueBrain> Phazorx: flshtt?
22:11:48  <Rubidium> as the number of possibilities is actually quite enormous
22:11:57  <Phazorx> flash
22:11:57  <TrueBrain> around 2^(9*8) I think ;)
22:12:11  <TrueBrain> which is about the number of tile combinations you need... as OpenTTD uses almost all bits
22:12:26  <TrueBrain> Phazorx: I hate flash! :)
22:12:38  <Gonozal_VIII> it wouldn't be that much
22:12:42  <Phazorx> TrueBrain: same here
22:12:47  <TrueBrain> Gonozal_VIII: I guess you need to get a math-class :)
22:12:53  <Phazorx> my last project was serverside for flash client
22:12:53  <TrueBrain> or a look at landscape.html
22:12:58  <Phazorx> so i hate it even more now
22:13:04  <TrueBrain> I always hated flash
22:13:10  <TrueBrain> mostly, because it takes for ever to load
22:13:14  <TrueBrain> and it is always annoying
22:13:15  <Phazorx> but you can use it only as middle man to faccilitate communication
22:13:30  <TrueBrain> that is ture
22:13:37  <Phazorx> like in hudden frame just to feed input/output buffer
22:13:41  <Phazorx> and maintain connection
22:13:50  <TrueBrain> a bit faking ;)
22:13:52  <Gonozal_VIII> the bytes are split into categorys.. it's 2^8 + 2^8 + 2^8 not 2^8 * 2^8
22:13:53  <TrueBrain> but even with the best protocol
22:14:00  <TrueBrain> I don't see how to make WebTT to work ;)
22:14:08  <TrueBrain> Gonozal_VIII: euh.... okay
22:14:33  <TrueBrain> but can I ask then, why we wouldn't be using your tile-number stuff already in the game?
22:14:44  <TrueBrain> I mean, that would be a very good idea, reduction of 4 times the memory footprint!
22:14:47  <TrueBrain> people would love that!
22:15:17  <Gonozal_VIII> because somebody would have to create the db with all possible tiles
22:15:35  <TrueBrain> oh, we would be able to fix that, with bit fiddling
22:15:38  <TrueBrain> but now just think for a moment
22:15:43  <TrueBrain> at any moment in the game
22:15:52  <TrueBrain> does it happen that m1 has data, but m2 is empty?
22:16:05  <TrueBrain> or, for your idea to work: m1 has data, and m2 .. m7 is empty?
22:16:08  <Rubidium> 18 types of slopes * 16 types of "groundlandscape * 8 types of treegrowth * 41 types of trees
22:16:18  <Rubidium> => more than 65536
22:16:32  <TrueBrain> Gonozal_VIII: take it from us, every bit in the _m array is used
22:16:34  <Rubidium> and that *only* for all possible tree layouts
22:16:35  <TrueBrain> in its best way
22:16:42  <TrueBrain> for each tile, most bits are used..
22:16:50  <TrueBrain> so no way on earth any DB will be able to reduce that ammount
22:16:52  <TrueBrain> -m
22:17:07  <TrueBrain> we _need_ all bits, and the combinations are endless... or rather: 2^(8*9)
22:17:17  <Rubidium> so good luck assigning all different tiles to 65536 unique ones, when the trees already make much more than 65536 unique tiles
22:17:18  <TrueBrain> no bit is left untouched, or unique
22:17:37  <Phazorx> Rubidium: a while ago i offered to store layers of map independantly, like landscape, obstacles, players items, eyecandies - separately
22:17:47  <Rubidium> TrueBrain: not completely true for visualisation (owner bits are not needed)
22:17:54  <Phazorx> hence you can have more optimizable map structures
22:17:58  <TrueBrain> Rubidium: fences! :)
22:18:13  <Gonozal_VIII> hmmmm
22:18:29  <Rubidium> Phazorx: how can adding more layers make it more space efficient?
22:18:42  <TrueBrain> we already are at max efficiency :)
22:18:55  <Phazorx> Rubidium: yeah would jave more limitted bit size
22:19:14  <Phazorx> heigh + slope is what, 6 bits only ?
22:19:16  <Rubidium> a layer for tree information, for example... can't be a linked list of something like that as that would take more memory than a simple array with that information
22:19:27  <Rubidium> slope isn't even stored
22:19:34  <Rubidium> height = 4 bits
22:19:36  <TrueBrain> is calculated on the fly, every request :s
22:19:43  <Phazorx> well even better then
22:19:51  <Gonozal_VIII> well it certainly wouldn't be more than 2^32 different tiles
22:20:10  <TrueBrain> Gonozal_VIII: sure, that is why we need 2^72 bits to store all the different possibilities
22:20:28  <Phazorx> so height is a layer of it;s own, then you have permament objects, client side fixtures, server side and client and serverside
22:20:43  <Phazorx> by client i mean things that player can built and by server - things that server can built
22:20:51  <Rubidium> let's see... how many different tiles can I make with a single industry...
22:21:17  <Phazorx> they are maintained differently - at different stages of different ticks
22:21:30  <Phazorx> operating on smaller data set should be beneficial at htese times
22:22:01  <TrueBrain> Gonozal_VIII: http://hg.openttd.org:8000/svn/trunk.hg/raw-file/9fbf09e31d86/docs/landscape_grid.html <- our bit usage
22:22:08  <Phazorx> also, such "bitmasks" are likely to be mroe compression friendly if separated since they have less variety - hence mroe compressable by nature
22:22:24  <TrueBrain> Gonozal_VIII: if you take road, it alone has 2^68 combinations that are possible on the tile
22:22:27  *** Vikthor [~Vikthor@212.24.150.226] has quit [Remote host closed the connection]
22:22:38  <Gonozal_VIII> O_o
22:22:50  <Rubidium> TrueBrain: that's too low ;), let me make a simple calculation about effective number of different tiles (sprite wise)
22:23:11  <TrueBrain> Rubidium: road-class has 2^68 combinations :)
22:23:19  <TrueBrain> euh
22:23:29  <TrueBrain> yes :)
22:23:45  <TrueBrain> industry 2^64
22:23:53  <TrueBrain> so, a tiny compression indeed is possible ;)
22:24:05  <TrueBrain> overlooking the table, I would say... 64bit..
22:24:34  <TrueBrain> Phazorx: basicly, you mean storing m1, m2, m3, ... seperatly
22:24:54  <Phazorx> TrueBrain: not sure what these are?
22:24:56  <Rubidium> we have NewGRF industries. That has 128 bytes of persistent storage that can be used for determining what sprite to draw, we have all kinds of cargo states (2*3 + 2*2) bytes, productions some bytes, ... in effect I have about 200 bytes of "entropy" to generate a sprite layout from to draw on a tile (and this is only a single industry tile)
22:24:59  <TrueBrain> Phazorx: see URL :)
22:25:23  <Rubidium> now try to pack 200 bytes of "entropy" into 4 bytes, i.e. compress 200 bytes of "random" data into 4 bytes
22:25:42  <Phazorx> TrueBrain: well to some degree
22:25:47  <TrueBrain> Rubidium: you only need 2^64 bits to store the industry, assuming the state of the game is the same for the rest
22:26:05  <Rubidium> I wish you good luck, and *IF* you succeeded...
22:26:11  <TrueBrain> (which in fact is what Gonozal_VIII talked about only.. we didn't even dare to talk about the information required outside the map ;))
22:26:49  <Eddi|zuHause2> <Gonozal_VIII> well 2 bytes is about 65k numbers... <- that is not even enough to give each tile on 2048x2048 a different number...
22:26:50  <Rubidium> well... *he* wanted to send the stuff to draw on a tile as a uint32 to the client
22:26:58  <Phazorx> a "farmland" would be a server side only thing, so it would go to same level as stonepiles and other things like that
22:27:02  <TrueBrain> Eddi|zuHause2: euh... wrong argu,ent :)
22:27:04  <TrueBrain> argument even
22:27:14  <TrueBrain> Eddi|zuHause2: if each tile on such map would look identical, you only need 1 number
22:27:19  <Rubidium> I just say that it is not possible when somebody really starts exploiting newindustries' capabilities
22:27:25  <TrueBrain> Phazorx: then how can a client draw it?
22:27:29  <Eddi|zuHause2> yeah, i know it is backwards ;)
22:27:43  <Phazorx> TrueBrain: by analyzing one by one each "affected layer"
22:27:48  <Phazorx> some dibale others
22:28:07  <TrueBrain> then nope, I don't follow you :)
22:28:14  <TrueBrain> I think what you mean is already done
22:28:16  <Phazorx> like if it is a "obstacle" tile - it can not be a tree or "server side emposed removble element"
22:28:17  <Eddi|zuHause2> but a less informed person would probably buy it ;)
22:28:19  <TrueBrain> but... I am not sure :)
22:28:30  <Rubidium> but then again, there are only about 4 million tiles on the map, but with animation you get a lot of new/different tiles which would gradually give you > 2 billion different tile stacks
22:28:38  <TrueBrain> Eddi|zuHause2: yeah.. still: bad argument :)
22:28:48  <Phazorx> TrueBrain: lemme erun through theoretical states of map generation
22:29:06  <Phazorx> say you have 2 main layers one controls heigh another owner
22:29:17  <Phazorx> so you only anlyze these at 1st
22:29:45  <Phazorx> heigh obviosly is what is now, owner is wether the tile is frre or player/server(town)
22:29:47  <Rubidium> Phazorx: what do you want to achieve with those "split" layers?
22:29:50  <Rubidium> more memory usage?
22:29:59  <Phazorx> less actualy
22:30:04  <Phazorx> and faster processing hopefully
22:30:05  <TrueBrain> Phazorx: m1 basicly contains the owner
22:30:07  <Rubidium> you can't get less
22:30:23  <Rubidium> as your "owner" layer can't be misused for other things
22:30:32  *** Progman [~progman@p57A1E739.dip.t-dialin.net] has quit [Quit: Progman]
22:30:35  <Rubidium> like happens currently with houses and industries
22:30:43  *** Progman [~progman@p57A1E739.dip.t-dialin.net] has joined #openttd
22:30:43  <Phazorx> that's actualy a point - things should ne be missuesed
22:30:47  <TrueBrain> Rubidium: the document says only with industry...
22:30:54  <Rubidium> so there you already wasted bytes
22:30:57  <Phazorx> owner should represent owner or abcence of thereof
22:31:02  <Phazorx> how ?
22:31:17  <Rubidium> because you have to store bytes that store no information
22:31:17  <Phazorx> height = 4 bits, owner - 1
22:31:22  <TrueBrain> Phazorx: really, believe us when we say: the map array is as efficient as it can get :)
22:31:38  <Rubidium> tile type industry -> ALWAYS OWNER_INDUSTRY, storing the owner means wasting space
22:31:41  *** Vikthor [~Vikthor@212.24.150.226] has joined #openttd
22:31:52  <Eddi|zuHause2> Phazorx: tiles that never can have any owner (industries) will still store the useless bits for the information that it does not have an owner
22:31:53  <Phazorx> TrueBrain/rubidium : lemme finish 1st
22:31:58  <Eddi|zuHause2> -> wasted bits
22:32:08  <TrueBrain> Phazorx: the floor is yours :)
22:32:55  <Phazorx> once again main thing 4+1 bytes that define height and presence of owner (where owner means = soemtihng built thre or just one tile terrain)
22:33:32  <Phazorx> so based on presence or abcence of owner bit it would either go into figuring out what is on that tile or where that tile belongs
22:33:39  <Gonozal_VIII> well... seems like there were some flaws in my theories
22:33:39  <Phazorx> say there is no owner set
22:34:07  <Rubidium> Phazorx: how are you going to store the owners of the tile physically?
22:34:20  <TrueBrain> Rubidium: he is 'trying' to go in the direction of Igor2's map idea, which infact was more efficient ;)
22:34:24  <Phazorx> Rubidium: next step
22:34:37  <Phazorx> 1st no owner -
22:34:44  <TrueBrain> Rubidium: that map was layered :)
22:34:54  <TrueBrain> as I remember, the profile showed good results :)
22:35:02  <Phazorx> that emans you should loo into things that are more feasible (popular 1st) leaving les spopular to later
22:35:13  <Phazorx> say tree is most popular things - you look into tre layer
22:35:25  <Phazorx> tyhat should have i dont know how many bits but say 8
22:35:29  <Rubidium> Phazorx: still.. how are you going to store the owner of the tiles that have an owner?
22:35:36  <Phazorx> if there is a tree - done
22:35:58  <Phazorx> Rubidium: i'm working from assumtion that number of things with owner is less than thigns w/o them
22:36:04  <Eddi|zuHause2> TrueBrain: then what happened to that idea?
22:36:10  <Phazorx> so there we go, alternative route where owner bit is set
22:36:13  <TrueBrain> Eddi|zuHause2: it involved an OpenTTD rewrite :)
22:36:39  <Rubidium> Phazorx: still... HOW are you going to store them... give me some datastructure type name (LinkedList, HashSet, Map, Array)?
22:36:47  <Eddi|zuHause2> TrueBrain: how much of that has been solved with map accessors meanwhile?
22:36:55  <TrueBrain> Eddi|zuHause2: none
22:37:57  <TrueBrain> Rubidium: do you remember the SVN of that project?
22:38:04  <Phazorx> Rubidium: i think hashset could be appropriate... say we bump company limit to more than 8 - you get 5, 6 or whatever is feasible bits for owner of a tile, but that is to be storred only for these tiles where owner would make sense
22:38:05  <TrueBrain> I can't seem to find it in the default libgpmi SVN repos...
22:38:15  <Gonozal_VIII> ah this is going to be in the direction of using less bits for more frequent tiles and more bits for tiles that are not used often
22:38:20  <Phazorx> owner check could/should be one of later stages
22:38:28  <Phazorx> after you figure out what is on that tile
22:38:30  <Eddi|zuHause2> hm... gpmi... that kind of rewrite ;)
22:38:38  <Phazorx> because there are many cases when you need just to display it
22:38:41  <Phazorx> and owner doesnt matter
22:38:46  <Phazorx> and can be safely ignored
22:38:46  <TrueBrain> Phazorx: your idea works, maybe not in the detail in what you describe, but okay, but not for owner. It is used too often ;)
22:39:01  <Rubidium> LinkedList -> sizeof(pointer) + sizeof(TileIndex) overhead per tile, HashSet -> sizeof(pointer) + sizeof(TileIndex) overhead per tile, Set -> sizeof(TileIndex) overhead per tile, array (tiles without owner as overhead)
22:39:17  <Phazorx> imho - TrueBrain: owner check is to be done only in case if client is modifying sometihng
22:39:35  <Rubidium> owner checks are also done on drawing
22:39:38  <Phazorx> which means it is "on click" rather than on tick/draw sprite
22:39:38  <TrueBrain> Phazorx: ah, for drawing only, yes, you are right, in the case the client didn't need the owner for gamelogic ;)
22:39:44  <Eddi|zuHause2> Phazorx: or when a vehicle is trying to enter a tile
22:39:51  <Phazorx> Eddi|zuHause2: event based
22:39:52  *** Peakki [antti@cs181247045.pp.htv.fi] has quit [Quit: LÀhdössÀ]
22:39:53  <Rubidium> and modifying "something" is what the whole game logic is about
22:40:28  <Eddi|zuHause2> Phazorx: yeah, but that happens multiple times a tick
22:40:33  <Phazorx> Rubidium: i'm trying to work in several different directions at same time
22:41:03  <Phazorx> optimizing datastructure for size, lookup speed and compressability
22:41:18  <Phazorx> memory size i'd actualy move to last spot
22:41:29  <Rubidium> write a paper about it and proof (mathematically) that is will yield a reduction in storeage space, speed and compressability. Then let it get peer reviewed and when that is done I'll look at it.
22:41:34  <Phazorx> it is importnat but is less important that speed seeing current game engine limitations
22:41:38  <TrueBrain> Rubidium: you did yourself....
22:41:51  <Rubidium> TrueBrain: I did what?
22:42:01  <TrueBrain> gave a proof-of-concept that Phazorx's idea works
22:42:14  <Rubidium> where? when?
22:42:17  <TrueBrain> GPMI
22:42:20  <TrueBrain> map-layer
22:42:21  <TrueBrain> profiles
22:42:37  <glx> libgpmi.org
22:42:50  <TrueBrain> glx: do you remember the SVN we used for that?
22:43:03  <Phazorx> and as far as owner goes - some lookups need to know wherether owner is set or not only so bit would be fine
22:43:26  <Rubidium> that's only about adding extra layers, which isn't significantly slower *but* uses more memory, which is exactly the opposite of what Phazorx is going to prove. Phazorx is going to prove it is going to be more space efficient *and* faster (the exact opposite of my proof-of-concept)
22:43:28  <Phazorx> and some activity can be limited by tipe of tile no matter what an owner is - again actul owner is ignored
22:43:48  <Phazorx> well i'm not sugegsting to do that on top
22:43:50  <TrueBrain> Rubidium: for owners for example, we established that it was needed to allocate the whole array at once
22:43:50  <Phazorx> but rather instead
22:43:56  <TrueBrain> for road pieces on the other hand, it wasn't
22:44:06  <TrueBrain> as < 2% of a map is road, I believe the stats said
22:44:09  <TrueBrain> then you DO make memory reduction
22:44:18  <glx> svn.libgpmi.org/svn/openttd
22:44:31  <TrueBrain> glx: I can't find it in there :(
22:44:49  <Rubidium> TrueBrain: at the cost of 4 bytes per tile, so net gain is 10%... *but* that assumes that the bytes are not used on any of the other tiles
22:44:51  <Phazorx> TrueBrain / Rubidium / glx i dont think that is exactly what i am suggesting
22:45:02  <TrueBrain> Phazorx: then you are wrong
22:45:03  <TrueBrain> hehe
22:45:21  <Phazorx> by definition - if i sugegst somthing other than whjat exists already i am wrong?
22:45:28  <TrueBrain> Phazorx: no :)
22:45:31  <Phazorx> i tihnk this discussion os over then :)
22:45:37  <Rubidium> take trees for example, those use say two bytes and are everywhere, so a new array -> net loss of quite some % due to the fact that you don't have trees everywhere
22:45:54  <glx> svn://svn.libgpmi.org/gpmi_openttd/trunk
22:45:55  <TrueBrain> Rubidium: you really don't remember the tests?
22:46:00  <Rubidium> and finally the conclusion became that using this method, though *much* cleaner, uses more memory
22:46:16  <TrueBrain> glx: I looked there sveral times..  Iam blind :p
22:46:22  <Phazorx> Rubidium: an object on tile if it is a tree - it can not be soemthign else, hence you will win on nost storing associated things
22:46:24  <Rubidium> TrueBrain: only vaguely
22:46:31  <TrueBrain> glx: no, that is the AI via GPMI
22:46:33  *** LeviathNL [~thomas@vdburgt.xs4all.nl] has joined #openttd
22:46:41  <TrueBrain> Rubidium: really, you were this when you started that
22:46:45  <TrueBrain> but after Igor2 showed some stats
22:46:48  <TrueBrain> and you 2 build a lot of code
22:46:53  <TrueBrain> it showed it really was AND faster AND more memory efficient
22:47:00  <glx> it's in extensions
22:47:01  <TrueBrain> as all those % together, did reduce the memory
22:47:08  <Phazorx> Rubidium: i suggest only some things to be bitmasks, especialy these that are not player controlled
22:47:11  <Rubidium> TrueBrain: it did NOT
22:47:20  <Rubidium> TrueBrain: you are really making things up now
22:47:49  <TrueBrain> no need to argue with statements like that
22:47:54  <TrueBrain> glx: can't find it :s
22:47:56  <TrueBrain> lol
22:48:04  <TrueBrain> this is annoying :) Not being able to find back an old project :)
22:48:06  <Rubidium> Phazorx: you are either not clear or totally not seeing my point
22:48:39  <Phazorx> Rubidium: i see you point of currently storing number of tiles * number of variations for most things
22:48:40  <TrueBrain> Rubidium: but for the record, I dislike people telling me I am making things up. You might want to calm down a bit.
22:49:05  <TrueBrain> glx: tilekit! :) :) :)
22:49:07  <Rubidium> you say you want to use the bits used for trees when a tile is not a tree for something different, right?
22:49:37  <Phazorx> i recognize that some of these features are based on "generic data area" element within these "number of variation"
22:50:09  <glx> TrueBrain: yes it's in gpmi_extensions
22:50:16  <Phazorx> i sugegst separating that to some generic levels where bit maps would work efficiecntly and someother not bitmap based stuctures
22:51:02  <Phazorx> i claim that it is possible to separate data based on usage type from "actiion validation" part of game logic engine
22:51:22  <TrueBrain> glx: tnx :)
22:51:31  <Rubidium> Phazorx: for what reason?
22:51:36  <Phazorx> at same time to use layer lookup order whoch woudl make "tile image generation" stage easier
22:52:03  <TrueBrain> glx: bah, the tests are already removed from that... do you maybe have an old old checkout?
22:52:11  <Phazorx> Rubidium: reason being posibility to implement dofferent optimization aproach other than geenric data area wthin map array
22:52:35  <glx> they used another repo to do the tests IIRC
22:52:44  <TrueBrain> glx: yeah... I remember that vaguely too
22:52:54  <TrueBrain> one that was owned by Rubidium I believe, and one by igor2
22:53:32  *** LeviathNL [~thomas@vdburgt.xs4all.nl] has quit [Remote host closed the connection]
22:53:38  <TrueBrain> hmm, my log-files don't go back that far
22:53:47  <Phazorx> Rubidium: i am very unfamilar with how data is stored right now, but i am familiar with common data analysys techniques as well as data storing theories
22:53:49  <Rubidium> I didn't own a SVN back then
22:53:51  *** csaba [~chatzilla@catv540316CB.pool.t-online.hu] has joined #openttd
22:53:57  *** LeviathNL [~thomas@vdburgt.xs4all.nl] has joined #openttd
22:54:20  <Rubidium> Phazorx: write a paper or something like that explaining exactly what you mean as IRC doesn't seem to be a right channel to explain it
22:54:25  <Phazorx> and i speak mroe based on theoretical posibility and most likely that would mean changing a lot of things and hence i am stepping on many toes :)
22:54:38  <Phazorx> well i might just do that
22:54:48  <glx> svn://igor2.peticio.hu/c_exp/xml_speed <-- this one maybe
22:55:00  <TrueBrain> no, that were XML speed checks
22:55:02  <Phazorx> however bouncing idea of heads of present company might be agood exercize as well
22:55:06  <TrueBrain> which showed libxml2 was VERY fast :p
22:55:24  *** Zuu [~Leif@c-153c71d5.025-58-6e6b702.cust.bredbandsbolaget.se] has quit [Quit: Leaving]
22:55:44  *** G_ [~njones@202-154-147-204.ubs-dynamic.connections.net.nz] has joined #openttd
22:55:59  <Phazorx> as i mentioned - i dont know how data is tored right now specificaly, and i also might miss something very obvious for a developer that is not obvious to an one who is not familiar with the project to necessary level
22:56:20  <TrueBrain> glx: I guess we have to ask igor2 tomorrow :) He can look on the local disk..
22:56:39  <glx> yep, I can't find more on my HD
22:57:32  *** G [~njones@202-154-147-204.ubs-dynamic.connections.net.nz] has quit [Ping timeout: 480 seconds]
22:57:46  <TrueBrain> glx: svn://igor2.peticio.hu/c_exp/ottd_map
22:57:47  <TrueBrain> :)
22:58:44  <Rubidium> TrueBrain: that was, AFAIK, the thing about the low backend of tile storing for different levels
22:58:45  <Phazorx> as far as industries go for example - it can be akeyed list, based on roster of "used tiles" linked to industry id
22:58:56  <Rubidium> i.e. that's from where 'geo' evolved
22:58:56  <TrueBrain> Rubidium: layers, exactly, yes :)
22:59:00  <TrueBrain> yup
22:59:10  <TrueBrain> which was, as far as I remember, more efficient in byte-storing
22:59:16  <glx> TrueBrain: I don't have it on my HD ;)
22:59:16  <Rubidium> but those layers are completely different types than the one Phazorx is talking about
22:59:18  <TrueBrain> (and more easier to use)
22:59:31  <Rubidium> as the layers of geo are 'z' layers
22:59:33  <TrueBrain> Rubidium: possible, as I said, I doubt what Phazorx is telling can be done, but something simular can be done
22:59:43  <TrueBrain> which in fact would reduce memory footprint
22:59:45  <TrueBrain> (and speed)
22:59:48  <TrueBrain> and is more flexible
22:59:53  <TrueBrain> that was the word I was looking for :)
23:00:23  <Rubidium> you "could" think about allocating memory per tile
23:00:23  <TrueBrain> Rubidium: am I still making things up?
23:00:41  <Rubidium> but then you have an overhead of at least 3 bytes per tile
23:01:01  <Rubidium> so the average (current) tile must "waste" at least 3 bytes
23:01:09  <TrueBrain> you talk about igor's idea?
23:01:34  <Rubidium> nah, GPMI's design was totally different
23:01:42  <Rubidium> at least geo's design
23:01:46  <TrueBrain> exactly. In that design, it was more efficient, not?
23:02:19  <Rubidium> no, *but* the most efficient it could get given the strict separation rules for GPMI.
23:02:39  <TrueBrain> what I remember, all the % together, it did use less memory..
23:02:54  *** thgerg1 [~Administr@dsl51B7A140.pool.t-online.hu] has joined #openttd
23:02:57  <TrueBrain> we assumed 16 layers (16 bits to indicate if the layer was active), and still it consumed less..
23:03:21  <TrueBrain> mostly because things like: only N% of the tiles use road
23:03:21  <Tefad> would 4bits not be enough?
23:03:23  *** Sionide- [sionide@cornflakes.imen.org.uk] has joined #openttd
23:03:24  *** G_ is now known as G
23:03:25  <Rubidium> you can make the current map less space efficient, but only at cost of processor times
23:03:26  *** Sionide [sionide@cornflakes.imen.org.uk] has quit [Read error: Connection reset by peer]
23:03:37  <Rubidium> s/less/more/
23:03:45  <TrueBrain> but Rubidium, anyway, am I still making things up?
23:03:58  *** thgergo [~Administr@dsl51B7A140.pool.t-online.hu] has quit [Read error: Connection reset by peer]
23:04:22  *** Sionide- is now known as Sionide
23:04:38  <Rubidium> that I made something that was both more space and memory efficient than OTTD's? Yes, that is not true
23:06:04  <Rubidium> s/memory/processor/
23:06:52  *** csaba [~chatzilla@catv540316CB.pool.t-online.hu] has quit [Quit: ChatZilla 0.9.78.1 [Firefox 2.0.0.9/2007102514]]
23:07:47  <Rubidium> you simply can't make something more space and processor efficient. I highly doubt you can even make it more processor efficient; probably, but at cost of memory as you start adding redundant information so GetTileOwner doesn't need to switch, or HasBridgeAbove doesn't need to switch
23:08:02  <Rubidium> only means that 2 bytes per tile need to be added
23:08:29  <TrueBrain> I am looking for this document: http://rubidium.student.utwente.nl/openttd/gpmi/gpmi_map.html
23:08:36  <TrueBrain> btw, Rubidium, for the record, you are very stubber today
23:08:41  <Rubidium> more memory efficient means "encrypting" everything more, which then needs decrypting, which takes time.
23:09:08  <Rubidium> TrueBrain: gone with the disk it was on
23:10:13  <Rubidium> the disk was totally broken; nothing could be saved and I didn't have much space for backups, so I didn't backup that.
23:16:43  <Tefad> encrypting or compressing?
23:16:59  <Tefad> i don't see how encrypting would save space as a general rule . .
23:17:19  <TrueBrain> Tefad: it depends how you define compresion, as it can be an encryption ;)
23:17:32  <Rubidium> it's more bitfucking etc, not real "compression"
23:17:44  <Rubidium> and the bitfucking makes it more cryptic
23:17:45  <Tefad> lossless compression is still compression
23:18:10  <TrueBrain> LZW is a nice encryption :)
23:18:18  <Tefad> you know you love shl and shr ; )
23:18:24  * Rubidium wonders whether removing duplicate files is called compression too
23:18:54  <Tefad> Rubidium: solid archive?
23:19:30  <Tefad> look at how well goodmerge compresses rom collections where there's slight variations amongst .. 5 or so files
23:19:46  <Tefad> 5 files down to less than the size of one : )
23:20:16  <Tefad> and compressing just one yields only a slightly smaller archive
23:20:28  <Tefad> LZW? LZO ftw.
23:21:41  <TrueBrain> I had to write my own LZW thingy a few days back, it amuzed me how much of a compression or encryption it could be :)
23:21:55  <TrueBrain> if you don't know how it is done, doubtful you will ever figure out :p
23:22:00  <Tefad> compression makes for a very very weak encryption
23:22:16  <TrueBrain> I agree :)
23:22:32  <Tefad> i wrote my own huffman codec in java
23:22:38  <Rubidium> ROT0 is the weakest I guess ;)
23:22:47  <Tefad> haar.
23:23:01  <Tefad> next would be ROT256 ; )
23:23:39  <Rubidium> depends on the amount that is going to be rotated
23:23:55  <Tefad> if you were really nuts, you'd write something that obfuscates into brainfuck code then compresses
23:24:04  <TrueBrain> Tefad: nuts, yes
23:24:55  <TrueBrain> a company gave 0,000 to who ever could decrypt a piece of text
23:25:02  <TrueBrain> it was like 20 A4 pages full I believe
23:25:12  <TrueBrain> they only didn't give the encryption method with it..
23:25:22  <TrueBrain> well... then I can come up with N ways, which you won't be able to crack, ever
23:25:37  <Tefad> onetime pad
23:25:38  <Tefad> done.
23:25:39  <Eddi|zuHause2> in theoretical computer science, "compression" means writing a universal turing machine, then writing a program on that machine that reproduces the original input
23:25:43  <TrueBrain> Tefad: exactly :)
23:25:59  <TrueBrain> so I was considering your brainfuck, how useful it would be... but if you know how it is done, I guess it is easy ;)
23:26:30  <TrueBrain> I like those 'demos', that are 64 KiB, and have a full 3D application
23:26:37  <TrueBrain> now that is compression
23:27:00  <Tefad> the produkkt
23:27:08  *** Farden [~jk3farden@AMontsouris-156-1-175-213.w83-202.abo.wanadoo.fr] has quit [Quit: ( www.nnscript.de :: NoNameScript 4.02 :: www.XLhost.de )]
23:27:27  <Tefad> not much compression as it is taking advantage of crafted random patterns as textures ; )
23:27:37  <TrueBrain> true true
23:27:46  <Tefad> but yeah, it's quite nuts : D
23:27:51  <TrueBrain> still, I wouldn't even know how to set up a 3D env in 64 KiB :p
23:28:30  <TrueBrain> hmmm.. I _can_ write Dune in my WebTT
23:28:32  <TrueBrain> lol
23:28:38  <TrueBrain> now that is something worth considering...
23:29:07  <Eddi|zuHause2> well, the trick about compression almost no possible combination of bits is actually used
23:30:08  *** KritiK [~Maxim@78-106-156-108.broadband.corbina.ru] has quit [Quit: Leaving]
23:30:21  <Tefad> those guys made a 3d FPS within 96KB
23:30:52  <TrueBrain> Tefad: I respect that a lot :)
23:31:27  <Eddi|zuHause2> on the other hand, almost no (finite) bitstream is actually compressible to something that is not in O(1) around the size of the original input
23:31:57  <Tefad> losslessly
23:33:14  <TrueBrain> Eddi|zuHause2: there were people from Japan claming to compress something on an incredible rate...
23:33:15  *** Osai [~Osai@pD9EB4C72.dip.t-dialin.net] has quit [Quit: Osai]
23:33:21  <TrueBrain> it was 200:1 I believe
23:33:27  <TrueBrain> on any data
23:33:43  <TrueBrain> well.. after their first statement that they did it, nobody ever read anytihng from them again
23:33:44  <TrueBrain> but still! :)
23:34:08  <SmatZ> textures, maps done as simple fractals
23:34:11  <Eddi|zuHause2> there were preople trying to patent algorithms that could compress any input string by 1 bit
23:34:21  <Eddi|zuHause2> and then repeating that step over and over again
23:34:50  <SmatZ> yes, I read about it rather often at comp.compression
23:35:14  <Eddi|zuHause2> they did not get very far either, i believe :p
23:35:16  <Tefad> unpossible ; )
23:35:25  <SmatZ> these people do not want to understand simple math proof...
23:35:36  <TrueBrain> it happens more often
23:35:59  <TrueBrain> it is funny, then you read something on slashdot, of which you think: impossible
23:36:04  <TrueBrain> than some days later they post it
23:36:10  <TrueBrain> or you read in an other magazine that it can't be done
23:36:44  <TrueBrain> (like some weeks back some guys thought they had found a way to accelerate a partical faster than light.... too bad for them they just made an other experiment to show quantum entanglement)
23:37:33  <Eddi|zuHause2> the mathmatical prove is almost trivially easy
23:37:46  <Eddi|zuHause2> if you have X possible strings of n bits
23:38:10  <Eddi|zuHause2> you only have X-1 possible strings of 0..n-1 bits
23:38:21  <Tefad> you cannot shring 1bit of data by one bit, then you no longer have data.
23:38:24  <Eddi|zuHause2> so at least 1 string you cannot compress
23:38:29  <Tefad> shrink anyway
23:39:03  * Rubidium wonders when you shrink that last bit twice by one bit
23:39:04  <TrueBrain> Eddi|zuHause2: if, and only if, all combinations are used, you are correct
23:39:08  <Phazorx> there are entropy based compression algos with "guess" based decompression
23:39:26  <Phazorx> compression takes forever but you get miracles
23:39:32  <Tefad> al la flac?
23:39:39  <Tefad> or no
23:39:42  <Phazorx> nope
23:39:59  <Phazorx> imagine a 2d array where you know summs of all rows
23:40:04  <Phazorx> and colums
23:40:10  <Tefad> like sudoku or something
23:40:20  <Phazorx> kinda reverse but ues
23:40:26  <TrueBrain> indeed takes for ever ;)
23:40:28  <Eddi|zuHause2> TrueBrain: yes, i said that before... compression only works because "almost no" strings are actually used
23:40:37  <Phazorx> so you know all sums and some arbitrary amount of cells and a math appratus that knows how to guess
23:40:43  <TrueBrain> Eddi|zuHause2: and with strings you mean bit-combinations?
23:40:43  <Phazorx> the rest which is not know
23:41:01  <Eddi|zuHause2> yes... but the used alphabet does not really matter
23:41:10  <TrueBrain> Phazorx: in fact, what Tefad said, reduce it to a Sudoku, and it even consumes less space ;)
23:41:15  <Eddi|zuHause2> (as long as you compress into the same alphabet)
23:41:24  <Phazorx> TrueBrain: that is very performance inefficient
23:41:30  <TrueBrain> Phazorx: yours isn't? :p
23:41:32  <TrueBrain> lol :)
23:41:36  <Phazorx> TrueBrain: same thing
23:41:42  <Phazorx> btu i tihnk that's where future is
23:41:51  <SmatZ> omg NO! I did svn revert in a wrong directory
23:41:53  *** thgerg1 [~Administr@dsl51B7A140.pool.t-online.hu] has quit [Read error: Connection reset by peer]
23:42:02  <TrueBrain> Phazorx: fun part: you can compress that matrix too
23:42:07  <TrueBrain> it gives an other reduction
23:42:12  <Phazorx> as number of dimetions grows - amoutn of data stored decreased exponentialy to the power
23:42:12  <Tefad> SmatZ: ohnoes, use your backup you made yesterday, right?
23:42:13  <TrueBrain> you can do it till a given N in matrix-size
23:42:30  <TrueBrain> SmatZ: that sucks.. tip: use Mercurial (hg)
23:42:38  <SmatZ> Tefad: well, maybe four hours lost :-/
23:42:45  <Eddi|zuHause2> i _always_ do a "svn diff > temp" before a "svn revert"
23:42:49  <Tefad> ah not so bad then
23:42:58  <TrueBrain> Phazorx: it in fact is a very nice compression way :)
23:43:04  <SmatZ> TrueBrain: I should use it...
23:43:09  <SmatZ> Eddi|zuHause2: yes, a good idea
23:43:18  <TrueBrain> the main trick is to leave as little information as possible, while keeping decompression as fast as possible
23:43:43  <TrueBrain> and the solution needs to be unique
23:43:55  <Phazorx> TrueBrain: you get better result if you start from many dimensions
23:44:15  <Phazorx> but i havent seen a decent "guessing" algo that can do it efficiently w/o cotrnering itself
23:44:28  <TrueBrain> I wonder, is there a math-proof to show what data you at least need to keep the solution unique?
23:44:46  <Phazorx> basicaly a copression would give you a slider between infity of time spend and infitly small size
23:44:49  <TrueBrain> btw, Phazorx, what are you in daily life?
23:44:59  <Eddi|zuHause2> Phazorx: the "optimal" compression is undecidable
23:45:01  <Phazorx> well, you dont need to keep it unique
23:45:15  <Tefad> profession?
23:45:15  <Phazorx> but you need to provide same amount of data for same algo to get same result
23:45:24  <TrueBrain> Phazorx: you do if you want to get the same result ;)
23:45:35  <Phazorx> TrueBrain: mope
23:45:40  <Phazorx> a solution is a branch
23:45:53  <Phazorx> you give it just enough hits to get to end of it
23:45:58  <Eddi|zuHause2> Phazorx: a compression _must_ be injective
23:46:03  <Phazorx> so basicaly you have an aswer for every fork
23:46:29  <Phazorx> and hope that number of hints outweights the block size
23:46:43  <TrueBrain> btw, Phazorx, what are you in daily life? (and yes, Tefad, I ment profession :))
23:46:44  <Phazorx> outweighst in yeld as in less than
23:46:46  <Eddi|zuHause2> you can not _ever_ have two different strings that get compressed to the same output
23:46:57  <Phazorx> system architect :)
23:47:09  <Phazorx> specializing in MMO solutions
23:47:11  <TrueBrain> age? :p
23:47:14  <Phazorx> 31
23:47:25  <TrueBrain> k :) At least gives an idea to what/who we are talking ;)
23:47:26  <TrueBrain> hehe :)
23:47:32  <Phazorx> sure :)
23:48:00  <TrueBrain> anyway, Phazorx, I don't see how it can work if the solution isn't unique
23:48:00  *** Diabolic-Angel [~dia@xdsl-84-44-233-136.netcologne.de] has quit [Quit: leaving]
23:48:30  <Phazorx> it is kinda tricky
23:48:43  <TrueBrain> it of course firstly depends on what you were compression exactly
23:48:50  <Phazorx> doesnt realy
23:48:50  <TrueBrain> I assumed a matrix created from the binary stream
23:49:08  <Phazorx> welli can envision it being something lie
23:49:10  <Phazorx> like:
23:49:24  <Phazorx> take a fast algo to compress a stram and loose uniformity
23:49:27  <Phazorx> anything will do
23:49:44  <Phazorx> as long as you dont get any chunks that all checksums are 0s
23:49:53  <Phazorx> so it gives you a starting point
23:50:04  <Phazorx> then say you want to take a cube of 256x256x256
23:50:28  <Phazorx> that's a bug chunk of info 16MB
23:50:36  *** BigBB [~BigBB@p5B0407F0.dip0.t-ipconnect.de] has quit [Remote host closed the connection]
23:50:45  <Phazorx> and then you make xor in evey row colum of all surfaces
23:50:56  <Phazorx> basicaly you get 256x3
23:51:17  <Phazorx> then pick a random cell in the cube as starting point
23:51:30  <Phazorx> and follw some algo to guess the rest
23:51:47  <Phazorx> when you guessed wrong - add another cell
23:51:50  <TrueBrain> that guessing really can take for ever...
23:51:55  <Phazorx> exactly
23:51:59  <TrueBrain> add an other cell?
23:52:02  <Phazorx> well no amount of combiantions is limitted
23:52:07  <TrueBrain> do you have a name for those kind of algorithms?
23:52:22  <Phazorx> there must be one, i called them entropy based ones :)
23:52:56  <Phazorx> came out of a discussion i had with some mathematitian specialising in N-dimantianal data systems and wavelets
23:53:21  <Phazorx> basicaly that would take numerical calculation aproach to another level
23:53:25  <TrueBrain> that 'guessing' means you need to guess 255 numbers
23:53:28  <TrueBrain> and how the XOR adds up..
23:53:42  <TrueBrain> how = hope
23:53:43  <Phazorx> well yes
23:53:49  <SmatZ> TrueBrain: girlfriend sleeping, patch updated :-p
23:53:54  <TrueBrain> SmatZ: hehehehehe :)
23:54:02  <Phazorx> guessing part is giving as little as possible "cells"
23:54:14  <Phazorx> to come to predefined full matrix
23:54:21  <Phazorx> if you lucky it can be one
23:54:22  <TrueBrain> but, that matrix, filled with data
23:54:32  <TrueBrain> should be equal to the starting point, right?
23:54:43  <TrueBrain> so, the amount of data inside the matrix, should result in an unique solution, right?
23:54:48  <Phazorx> i dont see any limitation on that part
23:54:59  <Phazorx> well with given dataset yes
23:55:02  <TrueBrain> as the content of the matrix is the input to the decoder of the original compression
23:55:09  <TrueBrain> k
23:55:12  <Phazorx> but a solutio to that math problem is a tree
23:55:16  <TrueBrain> so that is rather tricky, to make sure it is unique..
23:55:34  <Phazorx> worst scenario  = no math apparatus
23:55:38  <SmatZ> I can't let her sleep alone, night
23:55:39  *** SmatZ [~smatz@a40-prg1-5-107.static.adsl.vol.cz] has quit [Remote host closed the connection]
23:55:50  <TrueBrain> Phazorx: what if I 'guess' numbers and find an other solution
23:55:51  <Phazorx> so you do brute force to guess all cells
23:55:55  <TrueBrain> it will ... well.. break things ;)
23:56:07  <Phazorx> TrueBrain: that means you need to provide another "start cell"
23:56:13  <Phazorx> or an additional one most likely
23:56:13  <TrueBrain> but, how to do that?
23:56:18  <TrueBrain> I mean, after compression, I only get N things
23:56:21  <Phazorx> an intelegent guess
23:56:27  <TrueBrain> I can't request an other 'start cell'
23:56:32  <TrueBrain> I only have what I have
23:56:40  <Phazorx> well again 256x256x256
23:56:59  <Phazorx> in theory from knowing all checksumms and one specific cell
23:57:12  <Phazorx> is it possible to calculate all other cells
23:57:21  <TrueBrain> and is that really an unique solution?
23:57:22  <Phazorx> to some subset of values
23:57:26  <Phazorx> it isnt
23:57:31  <Phazorx> you get subsets
23:57:52  <Phazorx> but say 1st vaue on some of these subsets are these that you need
23:58:07  <Phazorx> so you need to inellegently guess another cell in additon to curent one
23:58:16  <Phazorx> that would gibve you even more right guesses
23:58:17  <Phazorx> and so on
23:58:31  <Phazorx> untill 1st element of all subests are match to starting data
23:58:36  <TrueBrain> hmm, I still don't completely see this, but okay ;)
23:59:07  <Phazorx> then you end up with N^M + K bytes
23:59:16  <Phazorx> err
23:59:23  <Phazorx> sorry yes
23:59:37  <Phazorx> N*M + K bytes that give you N^N data

Powered by YARRSTE version: svn-trunk