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