Times are UTC Toggle Colours
00:03:58 <Maedhros> hmm, i think i prefer the second option, despite "someone" :) 00:04:23 <Maedhros> anyway, time to sleep. good night 00:07:43 <Digitalfox_Away> Good Night 00:09:42 *** dextro [~dextro@84.90.228.100] has left #openttd [Fui embora] 00:09:57 *** d3x7r0 [~dextro@84.90.228.100] has joined #openttd 00:11:02 *** d3x7r0 is now known as dextro 00:11:22 *** dextro [~dextro@84.90.228.100] has quit [] 00:12:19 *** Dextro [~dextro@84.90.228.100] has joined #openttd 00:12:22 <Rubidium_> KUDr: you missed (at least) r8002 in your manual sync 00:13:06 <BFM> Iphone looks like an expensive wank, but lucky for apple there's a lotta wankers out there. 00:17:11 <Nigel> exactly 00:17:30 <Nigel> i was commenting before, than my house is proudly iPod free 00:17:48 <KUDr> Rubidium_: hmm, will check it 00:17:52 <KUDr> thanks 00:18:00 <Nigel> i actually don't think there has been an iPod in the house 00:18:32 <BFM> OTher day on the bus, EVERYONE HAD AN IPOD :S 00:18:44 <BFM> I should have brought my 6 year old minidisc player, just to spite them 00:19:07 <pv2b> i saw this guy iwth a minidisc player a few years bakc in brussels 00:19:21 <pv2b> he had like 30 or so minidisc with him 00:19:21 <KUDr> Rubidium_: yes, i see, i didn't update any makefile stuff 00:19:38 <pv2b> it strikes me all of that would easilly fit on a modern hard disc based player probably even on a flash player. 00:20:13 <Nigel> BFM: thats what i do, everyone has white earbuds in their ears, so i pull out my cheap MP3 player, with black earbuds just to annoy them :P 00:20:46 <pv2b> white earbuds are for idiots who don't know better. 00:20:54 <pv2b> they sound like crap 00:23:44 *** tokai [~tokai@p54B84541.dip0.t-ipconnect.de] has quit [Ping timeout: 480 seconds] 00:24:44 <Nigel> haha, got a text message from the train network here "Due to a technical fault the [xx:xxam] [Eastern Line] train service from [Papakura] has been delayed by approx [xx] mins." 00:24:55 <CIA-1> KUDr * r8016 /branches/cpp/Makefile.lang.in: -Fix: (r8015) incomplete sync (thanks Rubidium) 00:25:54 <KUDr> gn all 00:26:03 <Nigel> and i think they just sent it to each subscriber twice ;) 00:26:58 <Eddi|zuHause2> hey... i am missing 11 trains 00:26:58 *** tokai [~tokai@p54B809BC.dip0.t-ipconnect.de] has joined #openttd 00:26:59 *** mode/#openttd [+v tokai] by ChanServ 00:27:15 <Eddi|zuHause2> i have a waypoint for each direction 00:27:23 <Eddi|zuHause2> one direction counted 215 trains last year 00:27:29 <Eddi|zuHause2> the other direction 204 00:27:33 *** Zahl [~SENFGURKE@p549F0B72.dip0.t-ipconnect.de] has quit [Ping timeout: 480 seconds] 00:27:51 <Eddi|zuHause2> i must have a wormhole or something 00:30:21 *** HMage [~HMage@85.21.179.41] has joined #openttd 00:32:34 *** Zahl [~SENFGURKE@p549F0B72.dip0.t-ipconnect.de] has joined #openttd 00:33:32 <orudge> Hm, Darkvater, remind me tomorrow about the OS/2 patch, I must sleep 00:38:04 *** Dextro [~dextro@84.90.228.100] has quit [Quit: Fui embora] 00:38:19 *** Zahl [~SENFGURKE@p549F0B72.dip0.t-ipconnect.de] has quit [Read error: Connection reset by peer] 00:38:25 *** Zahl [~SENFGURKE@p549F0B72.dip0.t-ipconnect.de] has joined #openttd 00:39:27 <CIA-1> glx * r8017 /branches/cpp/Makefile.lang.in" target="_blank">Makefile.lang.in: [cpp] -Fix r8015: revert unwanted Makefile.lang.in" target="_blank">Makefile.lang.in changes 00:40:37 *** Zahl [~SENFGURKE@p549F0B72.dip0.t-ipconnect.de] has quit [] 00:44:12 <Brianetta> Hey all you people who love to runs servers 00:44:27 <Brianetta> http://www.tt-forums.net/viewtopic.php?p=540215#540215 00:46:17 <setrodox> ah, nice, though i run private servers only atm 00:48:58 *** Bjarni [~Bjarni@0x50a46ac4.virnxx14.adsl-dhcp.tele.dk] has quit [Quit: Leaving] 00:52:56 <Brianetta> http://ppcis.org/standard/banner/62.117.66.190.png 00:53:04 <Brianetta> I *really* need to figure out my date routines 00:54:30 <Brianetta> un;ess, of course, the Russians are cheating the date back... 00:55:19 *** tokai [~tokai@p54B809BC.dip0.t-ipconnect.de] has quit [Ping timeout: 480 seconds] 00:58:08 *** tokai [~tokai@p54B80484.dip0.t-ipconnect.de] has joined #openttd 00:58:11 *** mode/#openttd [+v tokai] by ChanServ 01:10:51 <BFM> HAHAHA http://www.smbc-comics.com/index.php?db=comics&id=691#comic 01:13:57 *** hylje [hylje@194.187.214.214] has quit [Read error: Operation timed out] 01:16:47 *** tokai [~tokai@p54B80484.dip0.t-ipconnect.de] has quit [Ping timeout: 480 seconds] 01:16:50 *** Osai [~Osai@pD9EB6DBC.dip.t-dialin.net] has quit [Quit: Osai] 01:18:34 *** Vikthor [~Vikthor@snat2.arachne.cz] has quit [Quit: Leaving.] 01:22:34 *** hylje [hylje@194.187.214.214] has joined #openttd 01:23:12 *** tokai [~tokai@p54B84B11.dip0.t-ipconnect.de] has joined #openttd 01:23:15 *** mode/#openttd [+v tokai] by ChanServ 01:27:22 *** Triffid_Hunter [~Splat@funkmunch.net] has quit [Ping timeout: 480 seconds] 01:32:38 *** HMage [~HMage@85.21.179.41] has quit [Read error: Connection reset by peer] 01:35:13 *** HMage [~HMage@85.21.179.41] has joined #openttd 01:35:18 *** nairan [~maui_key@p5498F87C.dip.t-dialin.net] has quit [Ping timeout: 480 seconds] 01:37:32 *** Triffid_Hunter [~Splat@ppp214-242.static.internode.on.net] has joined #openttd 01:39:18 *** tokai [~tokai@p54B84B11.dip0.t-ipconnect.de] has quit [Ping timeout: 480 seconds] 01:42:22 *** tokai [~tokai@p54B84DF0.dip0.t-ipconnect.de] has joined #openttd 01:42:25 *** mode/#openttd [+v tokai] by ChanServ 01:57:35 *** setrodox [~setrodox@83-65-234-231.dynamic.xdsl-line.inode.at] has quit [Remote host closed the connection] 01:57:48 *** tokai [~tokai@p54B84DF0.dip0.t-ipconnect.de] has quit [Ping timeout: 480 seconds] 02:01:10 *** tokai [~tokai@p54B84983.dip0.t-ipconnect.de] has joined #openttd 02:01:11 *** mode/#openttd [+v tokai] by ChanServ 02:05:26 *** Digitalfox_Away [~chatzilla@bl8-41-217.dsl.telepac.pt] has quit [Quit: Bye Bye...] 02:05:31 *** Frostregen_ [~sucks@dslb-084-058-168-019.pools.arcor-ip.net] has joined #openttd 02:11:37 *** Frostregen [~sucks@dslb-084-058-135-190.pools.arcor-ip.net] has quit [Ping timeout: 480 seconds] 02:11:40 *** Frostregen_ is now known as Frostregen 02:22:23 *** tokai [~tokai@p54B84983.dip0.t-ipconnect.de] has quit [Ping timeout: 480 seconds] 02:24:51 *** tokai [~tokai@p54B8420E.dip0.t-ipconnect.de] has joined #openttd 02:24:54 *** mode/#openttd [+v tokai] by ChanServ 02:31:06 *** Eddi|zuHause3 [~johekr@p54B7651C.dip.t-dialin.net] has joined #openttd 02:37:31 *** Eddi|zuHause2 [~johekr@p54B7665B.dip.t-dialin.net] has quit [Ping timeout: 480 seconds] 02:52:34 *** PandaMojo [~chatzilla@ip72-197-231-130.sd.sd.cox.net] has joined #openttd 02:58:48 *** tokai [~tokai@p54B8420E.dip0.t-ipconnect.de] has quit [Ping timeout: 480 seconds] 03:03:16 *** tokai [~tokai@p54B83642.dip0.t-ipconnect.de] has joined #openttd 03:03:20 *** mode/#openttd [+v tokai] by ChanServ 03:21:57 *** glx [glx@bny93-6-82-245-156-124.fbx.proxad.net] has quit [Quit: bye] 03:22:23 *** McHawk [~hawk@p5489C589.dip.t-dialin.net] has quit [Ping timeout: 480 seconds] 03:27:42 *** nairan [~maui_key@p5498F8C4.dip.t-dialin.net] has joined #openttd 03:32:13 *** tokai [~tokai@p54B83642.dip0.t-ipconnect.de] has quit [Ping timeout: 480 seconds] 03:35:07 *** tokai [~tokai@p54B83019.dip0.t-ipconnect.de] has joined #openttd 03:35:11 *** mode/#openttd [+v tokai] by ChanServ 03:51:04 *** dp_ [~dp@p54B2FEA9.dip.t-dialin.net] has joined #openttd 03:58:04 *** dp [~dp@p54B2E431.dip.t-dialin.net] has quit [Ping timeout: 480 seconds] 03:58:05 *** roboboy [~Leo@c211-30-116-5.carlnfd2.nsw.optusnet.com.au] has quit [Read error: Connection reset by peer] 04:00:18 *** tokai [~tokai@p54B83019.dip0.t-ipconnect.de] has quit [Ping timeout: 480 seconds] 04:03:36 *** tokai [~tokai@p54B82BEC.dip0.t-ipconnect.de] has joined #openttd 04:03:39 *** mode/#openttd [+v tokai] by ChanServ 04:33:18 *** HMage [~HMage@85.21.179.41] has quit [Read error: Connection reset by peer] 04:38:17 *** tokai [~tokai@p54B82BEC.dip0.t-ipconnect.de] has quit [Ping timeout: 480 seconds] 04:40:46 *** tokai [~tokai@p54B821A4.dip0.t-ipconnect.de] has joined #openttd 04:40:49 *** mode/#openttd [+v tokai] by ChanServ 04:54:54 *** roboboy [~Leo@c211-30-116-5.carlnfd2.nsw.optusnet.com.au] has joined #openttd 05:00:27 <Sacro> !stats 05:00:29 <_42_> Sacro: http://devs.openttd.org/~truelight/stats/openttd.html 05:06:24 *** PandaMojo [~chatzilla@ip72-197-231-130.sd.sd.cox.net] has quit [Read error: Connection reset by peer] 05:08:31 *** PandaMojo [~chatzilla@ip72-197-231-130.sd.sd.cox.net] has joined #openttd 05:33:59 *** BFM [~chatzilla@CPE-138-130-140-81.nsw.bigpond.net.au] has quit [Quit: Chatzilla 0.9.77 [Firefox 1.5.0.9/2006120612]] 05:52:07 *** roboboy_ [~leo@c211-30-116-5.carlnfd2.nsw.optusnet.com.au] has joined #openttd 05:52:25 *** roboboy_ [~leo@c211-30-116-5.carlnfd2.nsw.optusnet.com.au] has quit [] 05:55:31 *** Sacro [~Ben@adsl-213-249-225-220.karoo.KCOM.COM] has quit [Read error: Connection reset by peer] 07:11:06 *** BurningFeetMan [~chatzilla@CPE-60-227-105-136.nsw.bigpond.net.au] has joined #openttd 07:18:06 *** Tron_ [~tron@p54A3EA89.dip.t-dialin.net] has quit [Ping timeout: 480 seconds] 07:28:23 *** BobingAbout [~BobingAbo@adsl-83-100-162-38.karoo.KCOM.COM] has joined #openttd 07:28:25 *** BobingAbout [~BobingAbo@adsl-83-100-162-38.karoo.KCOM.COM] has quit [] 07:37:38 *** roboboy [~Leo@c211-30-116-5.carlnfd2.nsw.optusnet.com.au] has quit [Read error: Connection reset by peer] 07:37:48 *** McHawk [~hawk@p5489C589.dip.t-dialin.net] has joined #openttd 07:48:21 *** Osai [~Osai@pD9EB6BB1.dip.t-dialin.net] has joined #openttd 07:54:03 *** PandaMojo_ [~chatzilla@ip72-197-231-130.sd.sd.cox.net] has joined #openttd 08:00:18 *** PandaMojo [~chatzilla@ip72-197-231-130.sd.sd.cox.net] has quit [Ping timeout: 480 seconds] 08:43:05 *** roboboy [~Leo@c211-30-116-5.carlnfd2.nsw.optusnet.com.au] has joined #openttd 08:45:52 *** Osai [~Osai@pD9EB6BB1.dip.t-dialin.net] has quit [Quit: Osai] 08:47:59 <Celestar> Brianetta: when will you restart your server? :) 08:48:26 <Brianetta> Celestar: 12 years' time 08:48:30 <Celestar> hm 08:48:41 <Celestar> !calc 12 * 365.25 * 2 08:48:42 <_42_> Celestar: 8766.00; 08:48:49 <Celestar> !calc 12 * 365.25 * 2 / 3600 08:48:50 <_42_> Celestar: 2.4350000000; 08:49:05 <Naksu> http://en.wikipedia.org/wiki/Caf%C3%A9_Europe <- i hope i'm not the only one who thinks this is stupid 08:49:39 <Brianetta> Naksu: Rest assured, you aren't 08:52:04 <Naksu> semla is a typical finnish sweet pastry? wtf? 08:52:12 <Naksu> it's not even finnish 08:54:36 <Naksu> http://en.wikipedia.org/wiki/Runeberg's_tart this would be a lot better 08:54:49 <Brianetta> Anybody here have an OpenTTD server running? 09:11:56 *** mikl [~mikl@tbv.faderhuset.org] has joined #openttd 09:12:32 <Darkvater> orudge: OS/2! 09:12:49 <Darkvater> morning 09:15:33 <peter1138> i see 09:15:43 <Darkvater> I figured out the still-existing news-crash.... 09:15:50 * Darkvater hatest that fifo-surrogate 09:15:55 <peter1138> "THAT" isn't the sanctioned way of upgrading GRFs 09:16:05 <peter1138> i mean, i never wrote the bit that changes stuff in game :P 09:16:28 <Darkvater> peter1138: the sanctioned way does not exist it seems :) 09:17:44 <peter1138> yeah, fuck em 09:17:51 <Darkvater> peter1138: we need to discuss unload vs transfer which, according to Celestar you broke 09:18:02 <peter1138> i did? 09:18:03 <peter1138> oh well 09:18:39 <peter1138> transfers always been broken 09:18:44 <Celestar> peter1138: pm pls 09:18:53 <Darkvater> I'll let you guys talk it out ;) 09:22:31 <peter1138> Darkvater: if you can think of a way to open a window during the saveload process, i can do the grf changing thing 09:22:50 <peter1138> the window system is reset when it reinitialises the intro game 09:23:40 <Darkvater> well I had a thinking and all I could come up with is global crappiness 09:23:49 <peter1138> right 09:23:59 <Darkvater> but even that is still highly vaporware 09:24:17 <peter1138> well, yeah, my thought was "globals" 09:24:17 <peter1138> heh 09:25:03 <peter1138> also i'd like an error message queue 09:25:17 <mikl> Eat globals and die(); 09:25:18 <Darkvater> as you say, there is no other way cause all the windows are reset 09:25:47 <Darkvater> o_O 09:25:50 <peter1138> maybe c++ migration can come up with a good idea 09:25:53 <Darkvater> the dollar dropped to 1.29 09:26:04 <Darkvater> from 1.33 about a week ago 09:32:39 <Celestar> talking about C++ migration ... 09:32:45 <Celestar> when? :P 09:33:36 <Darkvater> I've talked to KUDr and agreed that as soon as orudge gets the OS/2 patch done I'll apply it then merge 09:33:52 <Celestar> nice \o/ 09:33:53 <Darkvater> then we'll have at least 1 revision that works in trunk/ 09:33:54 <peter1138> hmm, it was synced? 09:34:01 <Celestar> peter1138: yes 09:34:25 * peter1138 times a full recompile :P 09:36:18 <peter1138> Darkvater: did i tell you benchmarked the "no" sprite limit patch? 09:36:33 <Darkvater> that you benchmarked it? 09:36:49 <peter1138> err 09:36:51 <peter1138> +i 09:36:52 <Darkvater> you had some confusing numbers but the last thing I heard was increase of spritecache to 2MB which really helped performance 09:36:58 <peter1138> yeah 09:37:07 <Darkvater> but do tell 09:37:18 <peter1138> the patch itself has little or no performance cost 09:37:26 <Darkvater> ...but... 09:37:27 <Darkvater> ? 09:37:29 <peter1138> which is nice 09:37:58 <peter1138> but the spritecache lru stuff takes longer with more sprites, obviously 09:38:05 <Darkvater> (last thing I heard was a performance drop of ~20% in GetSprite) 09:38:24 <peter1138> nah, that was the spritecache "pool" which is already in 09:38:45 <peter1138> it's nothing compared to blitting a sprite... 09:40:03 <peter1138> with a 2MB spritecache, i think we can afford to run the LRU check less often 09:40:36 <peter1138> anyway 09:40:40 <peter1138> i've got work to do :( 09:40:47 <Darkvater> *shock* 09:41:46 <Darkvater> the spritecache is still 1MB right? 09:41:57 <Celestar> what is the LRU ? 09:42:05 <Darkvater> Least Recently Used 09:42:13 <roboboy> peter1138 where did your server go on the list 09:43:16 <Celestar> guys, I've been looking around at servers 09:43:29 <Celestar> and we should disable road/rail collisions in network mode 09:43:48 <peter1138> why? 09:44:07 <peter1138> roboboy: no idea 09:44:14 <roboboy> ok 09:44:31 <roboboy> its not listed at openttd.org/servers.php for me either 09:44:34 <Darkvater> that's trying to fix a sympton, not the cause which is a bad algorithm for the crossings 09:45:08 <peter1138> roboboy: i know 09:45:11 <Celestar> peter1138: because people build depot+1 piece of rail to destroy other people's RVs 09:45:14 <roboboy> ok 09:45:23 <peter1138> i guessed that from "where did your server go on the list" 09:45:23 <Darkvater> Celestar: it's a part of the game 09:45:46 <Darkvater> if it's unwanted the server rules should state that and the admin kick violators 09:46:05 <peter1138> 6m51 user time 09:46:18 * peter1138 tests trunk 09:46:30 <Darkvater> is that build-time? 09:46:33 <peter1138> yeah 09:46:39 <peter1138> from make clean 09:46:44 <Darkvater> hee, dn't ever change openttd.h again 09:47:18 * peter1138 tries to figure out the advantage of compiling a c project as c++ 09:47:28 <peter1138> we get type safety which we have to work around with casts... 09:48:02 *** scia [~scia@AveloN.xs4all.nl] has joined #openttd 09:48:10 <Archieboy> Is it possible to create admin popups on violation? 09:48:30 *** Archieboy is now known as Giddorah 09:50:13 <Darkvater> no 09:50:44 <Darkvater> peter1138: I don't think the just-convert c++ has any advantages 09:51:03 <Darkvater> but that was not what the c++ part was supposed to stay at 09:52:55 <Giddorah> Really? It isn't? 09:53:16 <peter1138> bollocks 09:53:21 <peter1138> forgot to use time :P 09:53:34 <Darkvater> no cause the violations you speak of Giddorah are just game rules that you set up 09:53:41 <Darkvater> the game does not enforce it in any way 09:55:37 <Giddorah> Well... Can you set up the server so that destroying someone elses equipment isn't possible? Is there any admin tool to find out if someone is destroying an offline players lorrys/buses? I mean, other than having the news running (Does it even show deaths of other people's units?) 09:56:23 <Giddorah> Playing on a 2048x2048 with 8 companies, caring about your own company at the same time as you care about everyone elses is a bit tedious 09:56:42 <Celestar> what about the option of disallowing crashes between two companies? 09:56:54 <Giddorah> There is such an option? 09:57:00 <Celestar> no 09:57:04 <Giddorah> Hehe 09:57:08 <Celestar> but i was thinking about whether to implement one 09:57:30 <Giddorah> I think some kind of MP-Rules thingy when you create the server ought to turn out good 09:57:56 <Giddorah> Problem is that they will probably be hard to implement if you got to work on the network code and stuff 09:58:23 <Celestar> the network code is just low-level 09:58:33 <Celestar> building packets and sending them 09:58:41 <peter1138> let's disable level crossings 09:58:54 <peter1138> and also disable flooding 09:59:40 <Darkvater> Brianetta: any desyncs yet? 09:59:55 <peter1138> heh 09:59:56 <peter1138> 5m50 10:00:25 <Darkvater> the compile time is indeed disturbing... 10:00:51 <Giddorah> Takes 6 minutes to compile? 10:00:55 <Darkvater> hmm peter1138: didn't you say you would implement a grf-update mechanism? Eg it only checks grfid when loading game in SP? 10:01:21 <peter1138> i wanted to do the "open a window and fiddle" method 10:01:28 <peter1138> but i couldn't yet :P 10:01:34 <Giddorah> Oh oh oh! Is the drag-signal completion bug for corners fixed? 10:02:03 <Darkvater> I meant automatic upgrade 10:02:10 <peter1138> oh, no 10:02:42 <Darkvater> eg if it can't find the md5sum it looks for a grf with the same id 10:03:14 <peter1138> Giddorah: what bug? 10:09:04 *** Netsplit kinetic.oftc.net <-> charon.oftc.net quits: @Darkvater, Eddi|zuHause3, eQualizer, coronel, Triffid_Hunter, Ailure, McHawk, Frostregen, stillunknown, Prof_Frink, (+56 more, use /NETSPLIT to show all of them) 10:09:23 *** Sionide [sionide@cornflakes.imen.org.uk] has joined #openttd 10:09:29 *** Netsplit over, joins: scia, roboboy, Frostregen, Triffid_Hunter, mikk36[EST], Ailure, GoneWacko, tosse, Prof_Frink, XeryusTC (+10 more) 10:10:17 *** Netsplit over, joins: McHawk, +tokai, hylje, eQualizer, Mucht_, @Belugas_Gone, Born_Acorn, Smoovious, kampasky_, Naksu (+4 more) 10:10:56 *** Netsplit over, joins: Biff, CIA-1, xbddc, davos, qball, _42_, luckz, Eddi|zuHause3, dp_, BurningFeetMan (+19 more) 10:12:00 *** mode/#openttd [-o Maedhros] by ChanServ 10:12:35 *** nairan [~maui_key@p5498F8C4.dip.t-dialin.net] has joined #openttd 10:12:35 *** valhallasw [~valhallas@a62-251-30-68.adsl.xs4all.nl] has joined #openttd 10:13:19 <Giddorah> So, Darkvater, why the automatic grf-download? 10:13:26 <Giddorah> And what would trigger it? 10:13:34 <Giddorah> If it's only intended for sp? 10:13:41 <Darkvater> what? 10:13:55 <Darkvater> I'm not talking about automatic grf download 10:13:56 <peter1138> automatic upgrade != automatic download 10:14:26 <Giddorah> "... a grf-update mechanism?" 10:14:55 <peter1138> still nothing about downloads, heh 10:15:08 <Giddorah> U've lost me :P 10:15:24 <Darkvater> it is when you play your game with ukrs v3.0 then download v3.3 and the game uses 3.3 automatically if 3.3 is in the list and 3.0 is missing 10:15:29 <Darkvater> right now it refuses to load 10:15:30 <Giddorah> So... An automatic upgrade thingy without downloads 10:15:59 <Darkvater> peter1138: I think we can do that in AfterLoadGame > IsGoodGRFConfigList? 10:16:08 <Giddorah> Ooh... So you mean it automatically selects the grf-set with the highest version? 10:16:28 <Rubidium_> Darkvater: now what if you play with v3.0, remove that and replace it by v1.0? 10:16:55 <Giddorah> You just have to select "UKRS" in the grf list, and it'll choose the newest wether you have 10 different UKRS's installed? 10:17:42 <Darkvater> Rubidium_: if the GRFID matches it'll load 1.0 10:17:49 <Darkvater> but that's your own fault 10:18:00 <Darkvater> Giddorah: no 10:18:17 <Darkvater> because with grf files there is no notion of *new* or *old* 10:18:33 <Darkvater> if the GRFID matches then one is older than the other 10:19:01 <Darkvater> you only now that from the human comment in there which the author writes in any format he/she likes 10:19:05 <Darkvater> peter1138: right? 10:19:09 <Darkvater> don't wanna talk bullshit here ;p 10:19:27 <Giddorah> lol 10:19:57 <peter1138> i don't think there should be auto upgrade 10:20:11 <Giddorah> Well... Say it is like that... That the version number isn't actually something else but "cosmetics"... How would it check it, and why, and... Stuff 10:20:40 <peter1138> the only case where it can be possibly right is when there is only one matching grf id 10:20:44 <CIA-1> maedhros * r8018 /branches/newhouses/src/ (newgrf.c newgrf_house.c town.h town_cmd.c): 10:20:44 <CIA-1> [NewHouses] -Codechange: Make HOUSE_MAX the maximum number of houses rather 10:20:44 <CIA-1> than the highest house id, and introduce HOUSE_CLASS_MAX for classes. 10:21:10 <Giddorah> Good call :) 10:21:18 <Darkvater> peter1138: that's what I am talking about. In SP if the GRFID matches but MD5SUM doesn't still use that grf isntead of panicking 10:21:39 <peter1138> i'd rather have the manual gui :P 10:21:43 <Rubidium_> the only thing that would make sense to me is showing a dialog with: I could not find the GRF with ID X and MD5sum Y, which one should I replace it with? (and then a list) 10:21:50 <peter1138> Rubidium_: *ding* 10:21:51 <Giddorah> What good would it do? Wouldn't it be a cause for panicking clients? 10:21:59 *** Purno [~Purno@5351CF18.cable.casema.nl] has joined #openttd 10:22:04 <Rubidium_> peter1138: *dong* 10:22:15 <peter1138> keep that away 10:22:38 <Darkvater> hi Purno 10:22:49 <Purno> hi DV 10:22:54 <Darkvater> Rubidium_: good luck coding that in any sane way with the current framework 10:22:54 <Celestar> 256x256 feels really small these days 10:23:11 <Giddorah> Hehe 10:23:21 <Darkvater> peter1138: the manual GUI sucks cause you HAVE to load the game first with the original GRF's before you can change it 10:23:32 <Rubidium_> there is (currently) no sane way of doing that 10:23:32 <Darkvater> DaleStan would totally flip if it stayed that way; and rightly 10:23:34 <peter1138> Darkvater: no, manual gui before then game loads 10:23:38 <peter1138> we were just talking about it 10:23:44 <peter1138> -n 10:24:06 *** TinoM|Mobil [~tino@VPNPOOL01-0030.UNI-MUENSTER.DE] has joined #openttd 10:24:29 <Giddorah> But... With game loads in this convo... You mean before you generate/load a playable game, or you mean before the titlescreen? 10:24:41 <Giddorah> I haven't been peepin in the source yet 10:24:55 <peter1138> loading a savegame 10:25:02 <Giddorah> Alltho I've played TTD since 94... So this project interests me :P 10:25:24 <Giddorah> Okay 10:25:26 <Giddorah> Hmm 10:26:23 <peter1138> oi 10:26:32 <peter1138> no hmming unless you have my permission 10:27:04 <Darkvater> shall I kick? ^^ 10:27:16 <Giddorah> Haha 10:27:20 <Giddorah> Sorry :) 10:27:29 <Darkvater> sorry is not enough 10:27:31 <Darkvater> pay up! 10:27:35 <Giddorah> I'm a mumbler irl :S 10:30:03 <Darkvater> so press load > scan save for NGRF section and load that > present GUI if not 100% > load game for real with new list 10:30:55 <Darkvater> + fix up console / dedicated loading 10:33:22 <peter1138> heeeee 10:33:36 <peter1138> prescan savegames o_O 10:33:57 *** setrodox [~setrodox@83-65-234-231.dynamic.xdsl-line.inode.at] has joined #openttd 10:34:38 <Giddorah> Ahemm... Do you use the sourceforge project thingy? 10:35:19 <Darkvater> for downloads 10:36:59 <Darkvater> peter1138: well what else do you want to do? 10:37:05 *** scia [~scia@AveloN.xs4all.nl] has quit [Quit: Lost terminal] 10:37:35 <peter1138> nothing 10:37:42 <Darkvater> hehe 10:37:50 <peter1138> "dont' change grfs" :p 10:38:12 <Darkvater> I think I'll have to disagree with you on that ;p 10:38:57 <Darkvater> in my opinion the easiest solution would be 1. option to skip loading/activating GRF's and 2. autoupgrade 10:39:00 <Darkvater> both for SP only 10:39:24 <Darkvater> 1 would load the NGRF section just not activate the GRF files so you can change at will ingame 10:39:48 <CIA-1> rubidium * r8019 /trunk/config.lib: -Fix (r7759): if libfreetype was not found (and not forced to be used), the configure script aborted instead of marking it a 'not found'. 10:39:48 *** roboboy [~Leo@c211-30-116-5.carlnfd2.nsw.optusnet.com.au] has quit [Read error: Connection reset by peer] 10:42:01 <Brianetta> Darkvater: no (40 mins) 10:42:28 <Brianetta> Several "connections lost"ses 10:42:33 <Brianetta> but no desyncs 10:42:38 <Darkvater> interesting... (the no desync part) 10:42:51 <Brianetta> The lost connections were ISP related, I think 10:43:00 <Brianetta> since it was only me, and I also lost ssh 10:43:09 <Brianetta> although sutopilot could still talk to me via IRC 10:43:16 <Rubidium_> http://rubidium.student.utwente.nl/openttd/land_info_not_updated.diff or http://rubidium.student.utwente.nl/openttd/landinfo_segfault.diff ? 10:43:19 * Brianetta pats the autopilot 10:44:04 <Brianetta> You all saw my server info banner? 10:44:10 <Darkvater> horrible 10:44:12 <peter1138> hmm, so why has my server stopped advertising? 10:44:23 <Brianetta> ): 10:44:55 <Brianetta> Well, at least my banenr is the one that works (: 10:45:08 <Brianetta> except there's a bug in the date handling for 0.4.8 and older 10:45:29 <Brianetta> where the start date is fine, but the current date is usually a few hundred years too early 10:45:29 <Darkvater> Rubidium_: do both fix the same thing? 10:45:39 <Rubidium_> yes, but in a different manner 10:46:06 <Rubidium_> in the second one you'll still have 'small house' an empty tile owned by 'someone' 10:46:31 <Rubidium_> in the first one, on a redraw of the window, the information is fetched again 10:47:10 <Darkvater> best'd be to stringinizing the values so it's permanent but in any other case I would pick land_info_not_updated then 10:47:18 <peter1138> hmm 10:47:24 <peter1138> the ingame server list is a bit fucked 10:47:45 <peter1138> if you add a server manually and refresh, the ip disappears and subsequent refreshes say "Cannot resolve" 10:47:59 <peter1138> hmm, i'm using RC2 though 10:49:14 <Darkvater> http://www.tt-forums.net/viewtopic.php?t=29570 10:49:15 <Darkvater> whaa 10:49:24 <Darkvater> did that guy just put his own picture in there? 10:49:58 <valhallasw> Darkvater: I guess so. 10:50:14 <Darkvater> well at least he is a bit capable 10:50:27 <valhallasw> he knows how to resize his face 10:50:36 <Darkvater> there was a time when I got 'spammed' by some old guy to fix his problems 10:50:39 <Darkvater> TTD problems 10:50:40 <Celestar> ok what I do I need to send to a client to remove him. 10:50:51 <Nigel> Darkvater: thanks for correcting it ;) 10:50:58 <valhallasw> Celestar: erm, kick <client number> on the server? 10:51:05 <valhallasw> :+ 10:51:05 <Darkvater> he was sending me 1-2MB big bitmaps of his whole desktop just to show a 100x100 area 10:51:08 <Darkvater> Nigel: what? 10:52:06 <Nigel> about 'his problems' 10:52:18 <Darkvater> :) 10:52:26 *** tokai [~tokai@p54B821A4.dip0.t-ipconnect.de] has quit [Quit: icebears... take care of them!] 10:58:58 *** roboboy [~Leo@c211-30-116-5.carlnfd2.nsw.optusnet.com.au] has joined #openttd 10:59:04 <CIA-1> maedhros * r8020 /branches/newhouses/src/ (newgrf_house.c newgrf_house.h): [NewHouses] -Codechange: Rename ClassGRFIDMapping to HouseClassMapping, move it to newgrf_house.h and add some comments. 11:09:02 <Darkvater> < lunch 11:16:29 <Brianetta> My date interpretation code sucks 11:16:36 <Brianetta> All my dates are wrong, some more than others 11:20:08 <Nigel> hmmm, NewHouses look good (just been reading the forum threads) 11:27:54 <Celestar> Darkvater: we needa discuss merge order. 11:28:03 <Celestar> Darkvater: cpp, newhouses or newhouses, cpp :) 11:28:26 <Celestar> not sure about cbh, but it is temporarily halted 11:28:44 <Rubidium_> well, is newhouses finished? 11:28:53 <Celestar> don't know 11:29:08 <peter1138> no 11:29:15 <Celestar> ok how mucho is missing? :) 11:29:31 <peter1138> triggers and some bugs, iirc 11:29:36 <peter1138> dunno how necessary triggers are 11:29:44 <peter1138> i've not implemented them for stations yet either 11:30:11 <Celestar> peter1138: I'm not sure we need triggers before merging 11:30:36 <peter1138> depends what sort of problems not having them causes 11:31:18 <Celestar> this iPhone is soo cool 11:31:24 <Celestar> me wants one 11:32:16 <Rubidium_> I would at least see the merge of cpp happen in two different commits. One that renames the files and one that applies the diff between cpp and trunk (so we can actually see what happened and spot possible missed syncs) 11:32:17 <Nigel> Celestar: omg... 11:32:27 * Nigel beats up Celestar 11:32:35 <Celestar> Nigel: ? 11:32:40 <Celestar> Rubidium_: hm .. sounds like an idea 11:32:55 <Nigel> i just don't like the idea of the iPhone tbh 11:33:23 <Celestar> as long as it doesn't run Windows 11:33:26 <Nigel> too much to go wrong imo 11:33:26 <Celestar> or need Window 11:33:49 <Celestar> there's much more that can go wrong in a Boeing 777 11:34:06 <Celestar> yet we use it 11:34:51 <Nigel> true, but the loss of say, the master altimeter, doesn't cause the whole thing to die, i'd hate to think what could happen if some functionality was lost on one of those things 11:36:14 <Nigel> anyway, it's not like i'll be able to purchase one in the next 5 years 11:36:50 <Rubidium_> unless the altimeter is linked to the autopilot and the plane is going slowly downwards until it crashes 11:37:27 *** TinoM|Mobil [~tino@VPNPOOL01-0030.UNI-MUENSTER.DE] has quit [Ping timeout: 480 seconds] 11:37:53 <Nigel> Rubidium_: thats why they have backup mechanical altimeters as well as the master digital one/s 11:38:44 <Maedhros> i don't think newhouses is ready to be merged yet 11:38:57 <Maedhros> nearly, but not quite :) 11:39:01 *** Progman [~progman@p57A1E1C1.dip.t-dialin.net] has joined #openttd 11:39:14 <Nigel> Maedhros: thats why i just said "looks good" 11:39:27 <Rubidium_> oh, Celestar it would be nice to have the name changes done by a script, so it can be applied to the other branches (when needed) 11:42:41 <Brianetta> peter1138: Banner changed. Hopefully more legible - background is practically reduced to a watermark. 11:44:49 <peter1138> hmm 11:44:52 <peter1138> the blue's hard to read :P 11:44:59 <Brianetta> That's just you 11:45:07 <Brianetta> (: 11:45:15 <peter1138> dark blue on dark grey was never a good idea 11:45:31 <peter1138> i don't use the ttd theme either, heh 11:45:57 <Brianetta> Well, the "on dark grey" just came along later 11:46:09 <Brianetta> I still preferred the old one 11:46:12 <Nigel> Brianetta: got a link? 11:46:26 <peter1138> also 11:46:35 <Brianetta> I don't see any difficulty reading it, but I'm aesthetically challenged in the extreme - just look at my web sites. 11:46:37 <peter1138> maybe i'm the only user who doesn't have font smoothing enabled, heh 11:46:48 <Brianetta> font smoothing? 11:46:59 <peter1138> antialiasing as real people call it 11:47:04 <Brianetta> The image is antialiased, sure 11:47:21 <peter1138> the blue is definitely hard to read 11:47:22 <Brianetta> I doubt it's the same font as the one that the forum uses 11:47:32 <Brianetta> That black just happens to be ImageMagick's default 11:47:39 <Brianetta> Nigel: It's in my forum signature 11:47:56 <Brianetta> Nigel: Look in the OpenTTD General forum at the servers as signatures threads, there are lots of them 11:48:07 <peter1138> 46KB :/ 11:48:13 <peter1138> can you make it smaller? :P 11:48:22 <peter1138> the watermark doesn't help for that... 11:48:27 <Brianetta> Let me read the man page again 11:48:37 * peter1138 has an idea 11:48:42 * peter1138 add blocks it: P 11:48:53 <Brianetta> (: 11:49:18 <peter1138> -d 11:50:31 <Brianetta> It's the text 11:50:35 <Brianetta> The base image is half as big 11:52:17 * Brianetta checks compression level, etc 11:52:48 <peter1138> a solid background, aliased text, and 8bpp would make it a lot smaller ;) 11:53:37 <peter1138> heheh 11:53:45 <peter1138> back to the old NFO vs XML debate :p 11:54:20 <Nigel> Brianetta: it's okay, sadly the blue is a little too sharp 11:54:37 <Brianetta> The blue is "blue" 11:55:03 <Nigel> i know, but for tt-forums it's too sharp/peircing 11:55:50 *** tudor [~tudor@tomka.hu] has joined #openttd 11:56:06 <MiHaMiX> tudor: hi 11:56:10 <Nigel> it's like i perfer websites to be ever so slightly off-white instead of white 11:56:27 <tudor> hi 11:56:34 *** tudor is now known as picitlama 11:56:39 <Nigel> i can hardly read black text on white webpages anymore 11:56:55 <Brianetta> Sounds like you ned to use your contrast knob 11:57:07 <picitlama> Nigel: this is beacuse antialiasing works better now :) 11:58:26 <Nigel> Brianetta: i need to turn my laptops brightness down to the lowest possible to read black on white some of the time now 11:59:11 *** Digitalfox_Away [~chatzilla@bl8-41-217.dsl.telepac.pt] has joined #openttd 11:59:31 <Nigel> picitlama: and people wonder why i don't trust modern technology 12:00:10 <picitlama> Nigel: modern technology a good thing. Openttd, by example, a modern technology. 12:00:40 <Nigel> picitlama: OpenTTD is an exception to the rule yes 12:02:32 <BurningFeetMan> Modern Technology rocks my socks. 12:02:40 <picitlama> Torcs also a very nice productivity-destroyer. But what about cellphones? Saved a lots of lives and marriages. 12:02:42 <BurningFeetMan> Take Team Fortress 2 for example ^_^ 12:03:13 <BurningFeetMan> What about medical R&D... now imagine it with out the past 200 years of modern technology ^_^ 12:03:24 <picitlama> yes 12:03:37 <Brianetta> OK, the compresion level was boosted 12:03:43 *** BurningFeetMan [~chatzilla@CPE-60-227-105-136.nsw.bigpond.net.au] has quit [Quit: Chatzilla 0.9.77 [Firefox 1.5.0.9/2006120612]] 12:03:45 <Brianetta> It's lost 25% of its file length 12:03:51 <picitlama> and space travel. Nice to know about big spaces where no burokracy. 12:03:58 <MiHaMiX> picitlama: :D 12:04:32 *** TinoM| [~Tino@i5387DD5F.versanet.de] has joined #openttd 12:04:46 <picitlama> but i am not here for modern technology. I wanted to ask a question. 12:05:00 <Celestar> picitlama: yeah? 12:05:11 <MiHaMiX> picitlama: ask your question without prior questions :) 12:05:25 <Nigel> i kinda meant recent technology, but yeah 12:05:30 <picitlama> is there someone, who likes to play with 1024x1024 map, and the cities @ factories settings at "more" level? 12:05:46 <picitlama> MiHaMiX: yes, but i type slow in english :) 12:06:14 <Nigel> picitlama: yeah, i quite like that 12:06:23 <picitlama> i think when i switch these options to the upper level, te map becoma ridicoulos, factories and cities reaching into each other 12:06:37 <picitlama> Nigel: can you show me a developed screenshot? 12:07:49 <Nigel> i appologise but no 12:07:58 <Nigel> i reformatted as of yesturday 12:08:09 <Brianetta> I like the length, for really long routes, but I make the maps long and thin. I prefer fewer cities and more countryside. OpenTTD's cities grow so fast that there's often no countryside left by 2020 unless there are very few cities.. 12:08:20 <Nigel> havn't had the chance to restore yet 12:08:48 <Nigel> Brianetta: true that 12:09:22 <Celestar> Brianetta: ping me if you restart, k? :) 12:09:34 <Nigel> other problem is, i'd perfer playing multiplayer, but every time i connent, there doesn't seem to be a decent (don't get me wrong here) server, with free spaces 12:09:34 <picitlama> Brianetta: yes, thi is my problem also 12:09:39 <peter1138> uhhh 12:09:46 <peter1138> (tgdb) print cur_ticks 12:09:46 <peter1138> = 199704599 12:09:46 <peter1138> (tgdb) print next_tick 12:09:46 <peter1138> = 4294967292 12:09:50 <peter1138> that ... seems wrong 12:09:54 <picitlama> and i cant eradicate cities. tried :) 12:11:33 *** TinoM [~Tino@i5387EA13.versanet.de] has quit [Ping timeout: 480 seconds] 12:12:11 <Brianetta> Celestar: OK 12:12:30 <Celestar> Brianetta: is the game running at all presently? :P 12:12:48 <peter1138> ok 12:12:51 <Brianetta> Best way to avoid city growth is to smake sure that all the cities are above the snowline or in the desert. 12:12:56 <peter1138> so why did next_tick become -1? 12:13:05 <Brianetta> Celestar: No, there are no players 12:13:10 <Nigel> peter1138: overflow? 12:13:25 *** StarLite [~Star@StarLite.xs4all.nl] has joined #openttd 12:13:38 <Celestar> what is the problem with city growth? I like the urban areas 12:13:41 <Celestar> makes thing realistic 12:13:44 <peter1138> Celestar: it's too high 12:13:49 <Nigel> Celestar: i agree 12:13:52 <Brianetta> Celestar: There is still countryside 12:13:56 <Brianetta> in the real world 12:14:00 <Celestar> you cannot build 100km long straight lines anyway 12:14:13 <Celestar> peter1138: I agree, but some factor, but not by an order of magnitude... 12:14:17 <Brianetta> There should be fewer trees, too. They grow like the pox in OpenTTD. 12:14:24 <Celestar> Brianetta: yeah 12:14:34 <Celestar> peter1138: better plane speeds would be more important imho 12:14:40 <picitlama> http://gergely.tomka.hu/kep/uglycrowdedmap.png 12:14:42 <peter1138> except for the ones you plant yourself. they die off too soon ;p 12:14:48 <peter1138> Celestar: unrelated :P 12:14:51 <picitlama> and this is the most rarest distribution 12:14:58 <Celestar> peter1138: "more important" 12:15:17 <picitlama> Brianetta: trees not a real problem, ithink 12:16:55 <Brianetta> picitlama: They are when you're trying to plant some 12:17:12 <Brianetta> but the city occupies most of the land, and the reomaining 200 tiles have trees on 12:17:16 <Brianetta> and your rating is poor 12:17:24 <Brianetta> and you have no desire to bribe 12:18:09 <picitlama> Brianetta: hm, never played this long :) 12:19:07 <Brianetta> Celestar: roboboy is on the server, making time move. 12:20:03 <picitlama> where can i download scenarios? The .deb packages doesnt contains scenarios 12:20:33 <Celestar> \o/ 12:21:21 *** Progman [~progman@p57A1E1C1.dip.t-dialin.net] has quit [Remote host closed the connection] 12:23:02 <roboboy> i just lost connection 12:25:12 <roboboy> i fund countryside! 12:27:31 <Brianetta> the 4th of October, 2042 12:27:35 <Brianetta> the 5th of October, 2042 12:27:37 <Brianetta> look 12:27:39 <Brianetta> time passeth 12:27:49 <Celestar> niiice 12:27:54 <Brianetta> although my date function is probably a few days out 12:28:06 <Brianetta> and, on occasion, a few hundred years out 12:28:19 <Brianetta> especially with UDP protocol version < 3 12:30:03 <Celestar> ? 12:32:04 <Brianetta> ! 12:32:06 <Brianetta> it's true 12:32:12 <Brianetta> use my banner on a 0.4.8 server 12:32:26 <Celestar> who uses 0.4.8 ?? 12:32:27 <Brianetta> and it'll say "Started in 1980, now in 1842" or somethign 12:32:29 <Celestar> er wait 12:32:38 <Celestar> it's still the current release :P 12:34:41 <Brianetta> peter1138: Born_Acorn: Can I expect to see a license for the buff0rZ any time soon? I'm being pestered to include them 12:34:55 <Brianetta> Explicit permission will do, that's what I got from Pikka 12:36:04 <Darkvater> he, had a rather longishly lunch 12:36:12 <Brianetta> Lunch time? 12:36:17 <Brianetta> No wonde rI am hungry 12:36:26 <ln-> does 0.5.0 include newmap? 12:36:35 <Brianetta> ln-: What's newmap? 12:36:36 <peter1138> what is newmap? 12:36:46 <Brianetta> If you mean map accessor functions, yes (most of them) 12:37:01 <Celestar> ln-: newmap has not been started yet, so I guess no :P 12:37:27 <ln-> it was on the roadmap for 0.5, wasn't it... 12:37:46 <Brianetta> So was PBS, once 12:37:48 <Rubidium_> ln-: a roadmap made by wiki-users 12:37:57 <peter1138> only because of some guy's fantasy world 12:38:02 <peter1138> bocius or something 12:38:07 <peter1138> made a shed load of it up 12:39:39 *** Vikthor [~Vikthor@snat2.arachne.cz] has joined #openttd 12:40:03 <Brianetta> Looks like my date routines are now spot-on with 0.5.0 12:40:10 <Brianetta> I fixed the off-by-one error 12:40:29 <Brianetta> where a remainder of 31 days made it the 0th of February 12:40:43 <Brianetta> etc 12:41:06 <peter1138> heh 12:41:07 <Brianetta> but I still have some real weirdness with 0.4 (and older) dates 12:41:21 <Brianetta> I think it's a signed integer issue 12:41:27 <Brianetta> but Tcl doesn't type its integers 12:41:31 <Brianetta> They're just stringa 12:41:32 *** raimar2 [~hawk@p5489DB78.dip.t-dialin.net] has joined #openttd 12:42:00 * Brianetta has a brainwave 12:42:06 <Brianetta> I think I know where the issue might be... 12:42:07 <Darkvater> peter1138: nice counter (cur_tick/next_tick) 12:43:04 <peter1138> Darkvater: Rubidium_'s diagnosed it 12:43:57 <Darkvater> what was it? 12:44:08 *** Gorthdar [opera@chello089173007155.chello.sk] has joined #openttd 12:45:13 <Rubidium_> overflowing of cur_tick, but next_tick didn't overflow yet 12:46:05 * peter1138 wonders if it would've fixed itself in 49 days... 12:46:17 <peter1138> gruagh, i'm starving 12:46:37 *** McHawk [~hawk@p5489C589.dip.t-dialin.net] has quit [Read error: Operation timed out] 12:47:12 <Brianetta> It *is* a signed integer issue 12:48:26 <Brianetta> set current_date [expr ( $current_date + 0x10000 ) % 0x10000] 12:48:45 <Brianetta> I do love modulo arithmetic 12:48:54 <Darkvater> does the overflow of ticks have any impact? 12:49:06 <Darkvater> or your server needs to have been running for at least 49 days 12:49:21 <Rubidium_> uhm, in dedicated under unix it happens every 49 days 12:49:45 <Rubidium_> it being the wrap of ticks 12:50:01 <Darkvater> 49 game-days? or human-days? 12:50:07 <Rubidium_> human 12:50:07 <peter1138> human-days 12:50:14 <peter1138> since 1970 12:50:21 <peter1138> not since uptime or game start 12:50:36 <Darkvater> so peter has been running his server unchanged, uncrashed for 49 days? 12:50:44 <Rubidium_> no 12:50:49 <peter1138> read those two lines :P 12:51:07 <Rubidium_> the time wrap happens *every* 49 days 12:51:51 <peter1138> bah 12:51:58 <peter1138> bloody forums have marked everything as read 12:52:06 <roboboy> heh 12:52:13 <Rubidium_> as the dedicated server under unix uses the amount of milliseconds since 1970 to calculate the tickcount from 12:52:34 <roboboy> hey sometimes leave stuff marked even though ive read it 12:52:36 <peter1138> omg 12:53:45 <Rubidium_> anyway, http://rubidium.student.utwente.nl/openttd/dedicated-time-wrapping.diff should fix it 12:54:02 <Brianetta> http://ppcis.org/standard/banner/87.117.209.194-3981.png 12:54:04 <Rubidium_> and I have to leave now :) 12:54:06 <Brianetta> This date thing's nuts 12:54:23 <Darkvater> what is the impact of this wrapping-bug? 12:54:34 <peter1138> Darkvater: the server stops 12:54:46 <Darkvater> good, I like a pause now and then 12:54:59 <peter1138> because it'll wait 49 days for another tick to happen 12:55:07 <peter1138> usually it works, i guess 12:55:22 <roboboy> is that what happened when Brianetta's server hung? 12:55:29 <peter1138> possibly 12:55:35 <peter1138> it's why my server wasn't advertising 12:55:38 <peter1138> but the console is still responsive 12:56:18 <peter1138> fortunately i run my server under gdb 12:56:25 <Darkvater> Brianetta: why not use the function provided in the include/openttd.inc.php? 12:56:31 <peter1138> hmm, although you can attach anyway 12:56:35 <peter1138> Darkvater: cos it's tcl, not php 12:56:49 <Brianetta> Darkvater: Because it's written inphp 12:56:53 <peter1138> Brianetta is the last user of tcl left :) 12:57:04 <Darkvater> poor guy :) 12:57:14 <Brianetta> There's a strong and helpful Tcl community (: 12:57:27 <Brianetta> Well, I fixed the version 3 UDP date problem 12:57:45 <Brianetta> Signed 16 bit integer rolling negative, should have been unsigned 12:57:50 * roboboy likes Brianetta's backwards smilleys (: 12:58:00 <Brianetta> but this one with the #openttdcoop server.. 12:58:11 <Brianetta> roboboy: Upside down! 12:58:35 <Brianetta> http://ppcis.org/standard/banner/87.117.209.194-3980.png 12:58:37 <Brianetta> That one's fine 12:58:37 <Darkvater> he stole it from tron! 12:58:39 <Darkvater> ^^ 12:58:49 <Brianetta> http://ppcis.org/standard/banner/87.117.209.194-3981.png 12:58:52 <Brianetta> That one's boogered 12:59:10 <Brianetta> Darkvater: I've been smiling upside down since I started IRCing 12:59:16 <Brianetta> Back when smileys were new 12:59:21 <Brianetta> and there was no standard way around 12:59:37 <Brianetta> I grew used to this (-: in 1994 12:59:47 <Brianetta> and everybody else went :-o 13:00:05 <Darkvater> STEAL! 13:00:17 <roboboy> how do i do :D backwards 13:00:19 <Brianetta> I forgive you (: 13:00:26 <Brianetta> You don't 13:00:28 <roboboy> C|: 13:00:36 <roboboy> thats the best 13:00:44 <Brianetta> but D: is so good at expressing dismay that it makes up for it 13:00:54 <roboboy> G: 13:01:11 <peter1138> ]: 13:01:24 <Darkvater> is that a bull? 13:01:28 <Darkvater> ]:- 13:01:31 <Darkvater> mooooo 13:01:35 * roboboy patiently waits for the server to hit 2050 13:01:36 <Brianetta> -:[ ooom 13:01:46 <Darkvater> skinhead :O 13:01:57 <Brianetta> (:) 13:02:07 <Brianetta> (-:-) 13:03:11 <Darkvater> Rubidium_: about that patch, if cur_ticks wraps around, why do you assume it to be 0? 13:16:33 *** Naksu [naksu@anime.fi] has quit [Ping timeout: 480 seconds] 13:18:19 *** Naksu [naksu@anime.fi] has joined #openttd 13:18:57 *** Digitalfox_Away [~chatzilla@bl8-41-217.dsl.telepac.pt] has quit [Ping timeout: 480 seconds] 13:23:43 *** Rens2Sea [~Rens2Sea@213.211.185.168] has joined #openttd 13:24:41 *** Gorthdar [opera@chello089173007155.chello.sk] has left #openttd [] 13:35:51 *** TinoM [~Tino@i5387EC34.versanet.de] has joined #openttd 13:37:02 *** tokai [~tokai@p54B821A4.dip0.t-ipconnect.de] has joined #openttd 13:37:05 *** mode/#openttd [+v tokai] by ChanServ 13:38:11 *** Dextro [~dextro@84.90.228.100] has joined #openttd 13:39:17 *** Dextro [~dextro@84.90.228.100] has quit [Remote host closed the connection] 13:42:10 *** TinoM| [~Tino@i5387DD5F.versanet.de] has quit [Ping timeout: 480 seconds] 13:46:21 <roboboy> gnight 13:46:43 *** roboboy is now known as robobed 13:46:44 * Darkvater puts roboboy into bed and lulls him to sleep 13:48:22 *** glx [glx@bny93-6-82-245-156-124.fbx.proxad.net] has joined #openttd 13:48:25 *** mode/#openttd [+v glx] by ChanServ 13:48:47 <Darkvater> hi glx 13:48:52 <glx> hi 13:51:30 <Rubidium_> Darkvater: because 'next_tick + 30' would not necessarily overflow next_tick when cur_ticks has overflowed 13:51:53 <Darkvater> yes but we assume we want to go in steps of 30 ticks no? 13:52:09 <Darkvater> when cur_tick overflows it could be... 25 for example 13:52:27 <Darkvater> having next tick at 0+30 means the next eaction is only 5 ticks from now and not 30 13:53:04 <Rubidium_> true 13:53:59 <Rubidium_> ok, I've (somewhat) solved that issue, but... 13:54:01 <Darkvater> of course we can choose not to care about that 13:55:36 <Rubidium_> some scheduling not giving OTTD a slice every 30 milliseconds could make it appear slower (I think) 13:55:50 <Rubidium_> http://rubidium.student.utwente.nl/openttd/dedicated-time-wrapping.diff <- the new version 13:57:58 <Darkvater> doing gettime twice? 13:58:54 *** Belugas_Gone is now known as Belugas 13:59:07 <Darkvater> hi Belugas 13:59:56 <CIA-1> KUDr * r8021 /branches/cpp/src/ (oldpool.h thread.cpp): [cpp] - Fix: [OS/2] compiler warnings 14:00:21 <Rubidium_> the first one is used for the initialization of the values 14:00:36 <Rubidium_> the second one is in the 'gameloop' 14:01:00 <Darkvater> the first one is in dedicatedvideoloop no? 14:01:09 <Darkvater> or that's only executed once? 14:01:14 <Darkvater> hard to see from diff ;p 14:02:06 <Rubidium_> it's only executed once, as DedicatedVideoMainLoop is executed only once 14:03:43 <CIA-1> KUDr * r8022 /branches/cpp/src/gfxinit.cpp: [cpp] - Fix: [OS/2] compiler warnings (#2) 14:04:33 <Darkvater> ah 14:05:19 <CIA-1> KUDr * r8023 /branches/cpp/ (projects/openttd_vs80.vcproj src/gfxinit.cpp): [cpp] - Fix: (r8022) [OS/2] compiler warnings (#2) reposition 'const' 14:06:34 <Darkvater> looks better 14:10:30 <CIA-1> KUDr * r8024 /branches/cpp/projects/openttd_vs80.vcproj: [cpp] - Revert (r8023) unwanted project file change 14:10:48 <KUDr_wrk> correction of correction 14:13:11 <CIA-1> glx * r8025 /branches/cpp/src/network/network_udp.cpp: [cpp] -Fix:d:/developpement/ottd/cpp/src/network/network_udp.cpp:338: warning: enumeral and 14:15:42 <Darkvater> nice going :) 14:21:31 <Brianetta> http://ppcis.org/standard/screenshot.png 14:21:32 *** robobed [~Leo@c211-30-116-5.carlnfd2.nsw.optusnet.com.au] has quit [Read error: Connection reset by peer] 14:21:33 <Brianetta> Autoshot! 14:21:40 <Brianetta> Random server screenies (: 14:21:58 <Brianetta> I wonder if chat lines will appear there (: 14:22:06 <Darkvater> hehe 14:22:18 <Brianetta> I got the random scrollto working 14:22:27 <Darkvater> no chat it seems 14:22:35 <Brianetta> It assumes that map_x and map_y are correct, which requires care with saved games 14:22:48 <Darkvater> we're also about to remove your ability to make screenshots from the dedicated servers :) 14:22:55 <CIA-1> celestar * r8026 /trunk/src/economy.c: -Fix (r2441) When taking up cargo that is transferring, trains will now also have the virtual profit deducted. 14:23:13 <Brianetta> Darkvater: It's OK, it's only a bit of fun 14:23:21 <Brianetta> Not something I plan to include int he release any more 14:24:15 <Darkvater> Brianetta: how often is it refreshed? 14:24:27 <Brianetta> 450000 millis 14:24:30 <Brianetta> so, er 14:24:33 <Brianetta> wait 14:24:37 <Brianetta> might be a 0 out 14:24:42 <Darkvater> !calc 450 / 60 14:24:42 <_42_> Darkvater: 7.5000000000; 14:24:47 <Darkvater> every 8 mins? 14:25:05 <Brianetta> 450000 milliseconds 14:25:23 <Brianetta> I don't want to overload the server with such a pointless feature (: 14:25:33 <Darkvater> so every 8 mins 14:25:42 <Brianetta> 7:30ish 14:25:51 <Darkvater> 15:24 <@Darkvater> !calc 450 / 60 14:25:51 <Darkvater> 15:24 < _42_> Darkvater: 7.5000000000; 14:25:56 <Darkvater> :) 14:26:03 <Celestar> no ish 14:26:07 <Celestar> 7:30 14:26:21 <Brianetta> well, this assumes that the event loop's timer is accurate 14:26:26 <Brianetta> and that the copy is instantaneous 14:26:49 <Brianetta> It doesn't screenhot into the webspace 14:27:05 <Brianetta> it waits 3 seconds and then copies it with a shell script 14:27:22 <Brianetta> I separated that to a shell script so that I could change it without stopping the game 14:28:07 <Brianetta> Ooh, my auto-grf indicator on my page has worked 14:28:12 *** Digitalfox_Away [~chatzilla@bl7-176-107.dsl.telepac.pt] has joined #openttd 14:28:58 <Brianetta> I might keep this auto-scrollto 14:28:59 <SpComb> Logs: http://zapotek.paivola.fi/~terom/logs/openttd 14:28:59 <Digitalfox_Away> !logs 14:29:15 <Brianetta> even without screenshots, it does make the start place in the game unpredictable 14:29:20 <peter1138> *nod* 14:29:27 <Brianetta> which stops people spelling rude words in bought land on the opening screen (: 14:29:36 <peter1138> heh 14:30:32 <Darkvater> lol 14:31:14 <Brianetta> does scrollto care about out-of-bounds tile numbers? 14:31:21 <Brianetta> I never tried one 14:31:48 <Brianetta> heh, I just thought of simpler maths 14:32:06 <Darkvater> I think it just fails silently to scrollto 14:32:23 <Brianetta> instead of working out X and Y dimensions, then multiplying one by the other plus the one, then multiplying by random 14:32:42 <Brianetta> I can just add map_x and map_y, then raise 2 to that power, then multiply by random 14:32:47 <Darkvater> just pass it a number and % it by MapSize() 14:32:56 <Darkvater> random % MapSize() 14:33:10 <Brianetta> MapSize() isn't available form a Tcl script that has no binary interface 14:33:21 <Darkvater> make mapsize yoursel :) 14:33:33 <Brianetta> I will 14:33:36 <Darkvater> 1<<map_x * 1<<map_y 14:34:05 <peter1138> 1<<(map_x + map_y) 14:34:12 <peter1138> probably more efficient 14:34:49 <peter1138> not that's important 14:35:07 <peter1138> err 14:35:10 <peter1138> not that *it's* important 14:35:30 <orudge> Darkvater: just a fyi, I need to go into town, but once I'm back (hour or so) I'll get the OS/2 patch done 14:35:36 <Brianetta> proc mapsize {} {return [expr pow(2,([get_setting patches map_x] + [get_setting patches map_y]))]} 14:35:45 <Darkvater> well donnu if he can make it only compute once with tcl 14:36:02 <Darkvater> orudge: good, good :) 14:36:16 <Brianetta> I don't know if there's an easy shift 14:36:18 <Brianetta> There probably is 14:36:28 <orudge> Have I misinterpreted things, btw, or do I gather the C++ branch is being merged into trunk? 14:36:50 <peter1138> people appear to want to 14:36:57 <Brianetta> Is this C++ branch just C that compiles with g++, or is it actually C++? 14:37:34 <peter1138> the former 14:37:58 <Darkvater> Brianetta: gaaah your screenshot! 14:38:02 <Celestar> it's mostly still C 14:38:02 <Darkvater> horrible 14:38:05 <Darkvater> http://ppcis.org/standard/screenshot.png 14:38:28 <peter1138> hehe 14:38:54 <peter1138> pikka to the rescue :D 14:39:09 <peter1138> in the latest "use xml instead of newgrf" thread 14:39:29 <Darkvater> link! 14:40:09 <peter1138> http://www.tt-forums.net/viewtopic.php?t=29399&start=40 14:40:18 <Darkvater> thanks 14:40:24 <peter1138> and i had to type that, biatch :P 14:40:27 <Brianetta> I thought having the server announce in-game whenever a save completed would be cool 14:40:31 <Brianetta> but it's a bit spammy 14:40:41 <Brianetta> when it saves a copy every time somebody joins 14:40:52 <Brianetta> (the standard anti-vandalism technique) 14:43:01 <Darkvater> haha pikka; good one 14:43:16 <Darkvater> for more dramatic effect he should've included the NFO code that achieves this 14:45:42 *** Digitalfox_Away is now known as Digitalfox 14:46:10 <Rubidium_> ok, what about: http://rubidium.student.utwente.nl/openttd/video-timewrapping.diff (solves the same issue as in the dedicated video driver for all video drivers (though I wonder how many people run OTTD for more than 49 days)) 14:47:59 *** StarLite [~Star@StarLite.xs4all.nl] has quit [Read error: Connection reset by peer] 14:48:03 <setrodox> Rubidium_, the record i had with some friends were 60 days ;) 14:48:21 <Darkvater> Rubidium_: wouldn't be every other 49 day, not more than 49 days? 14:48:29 <Darkvater> as is the issue with the dedicated server? 14:49:22 <Rubidium_> uhm, for SDL it would be after 49 days (every 49 days), for dedicated it's every 49 days, for windows and OSX I don't know exactly what the tickcounter returns 14:51:12 <Darkvater> Retrieves the number of milliseconds that have elapsed since the system was started, up to 49.7 days. 14:51:31 <Darkvater> so windows is uptime 14:51:36 <Rubidium_> yup 14:52:07 <Rubidium_> then it can happen on long running windows systems too 14:52:17 <Darkvater> rofl 14:53:16 <setrodox> heh, i had to laugh at that sentence ^^ 14:53:25 <CIA-1> celestar * r8027 /trunk/src/command.c: 14:53:25 <CIA-1> -Fix (FS#486) If a pause command is issues, it will now pause the game even if 14:53:25 <CIA-1> shift is pressed instead of giving a cost estimate of 0. This fixes a problem 14:53:25 <CIA-1> where the server does not pause_on_join when the player on the interactive 14:53:25 <CIA-1> server has the shift button pressed. (Thanks to pvz for the report and the fix) 14:54:14 <peter1138> huh? 14:54:25 <peter1138> that's a luser problem 14:54:54 <peter1138> the problem is fixes is not really related 14:55:11 <Darkvater> nice ingrishc 14:55:15 <peter1138> *it 14:55:44 *** Progman [~progman@p57A1E1C1.dip.t-dialin.net] has joined #openttd 14:56:37 <peter1138> -Fix: replaced loo paper. this fixes a problem where my hands were stinky if i couldn't find the soap 14:57:08 <Brianetta> Celestar: That bug's a gem 14:57:16 <Rubidium_> Celestar: you could also have set CMD_SHOW_NO_ERROR when doing the CMD_NETWORK_COMMAND command 14:57:47 <Darkvater> peter1138: is it a user problem that I happen to press shift to get the estimate of a tunnel building and someone joins causing the server to *not* pause just because I was doing something else with shift? 14:58:25 <peter1138> well then i misunderstood the message 14:58:40 <peter1138> so i shall go away and hide 14:58:44 <peter1138> but yes 14:58:45 <Celestar> " This fixes a problem 14:58:46 <Celestar> 15:53 < CIA-1> where the server does not pause_on_join when the player on the interactive 14:58:49 <Celestar> 15:53 < CIA-1> server has the shift button pressed." 14:58:51 <peter1138> nobody should run non-dedicated servers ;p 14:58:55 <Celestar> I kind of hope that was clear 14:58:55 <Darkvater> :) 14:59:10 <peter1138> what about the "bug" that they can't rejoin the game when they go bust? heh 14:59:19 <Darkvater> MiHaMiX: ping 14:59:33 <peter1138> i was thinking it might be nice if you could join a server as a spectator, and then switch to a company without having to redownload the map 15:00:02 <PandaMojo_> peter1138: I like non-dedicated when I just want to play with my IRL friends :3 15:00:28 <CIA-1> rubidium * r8028 /trunk/src/video/ (cocoa_v.m dedicated_v.c sdl_v.c win32_v.c): -Fix: overflow of ticks was not handled properly, possibly resulting a non-reacting gameserver/gameclient. 15:02:20 <peter1138> backport :D 15:02:28 <peter1138> PandaMojo_: well i wasn't being serious :) 15:03:52 <CIA-1> rubidium * r8029 /trunk/src/configure: -Fix (7759): somehow the old configure script was not removed. 15:04:07 <peter1138> lol 15:06:20 <Eddi|zuHause3> <Celestar> what is the problem with city growth? I like the urban areas <- there should also exist villages that stay villages, even in 2020 15:08:08 <Celestar> Eddi|zuHause3: yes, different cities should have different growth 15:10:24 <peter1138> *nod* 15:10:37 <peter1138> like in ttdp (possibly ttd, i don't remember) 15:10:46 *** Purno [~Purno@5351CF18.cable.casema.nl] has quit [Read error: Connection reset by peer] 15:13:18 <Eddi|zuHause3> probably the current city growth AI should be totally ripped apart, and reconstructed from scratch 15:13:39 *** Purno [~Purno@5351CF18.cable.casema.nl] has joined #openttd 15:13:44 <Darkvater> wb Purno 15:13:50 <Purno> thx Darkvater 15:14:00 <Darkvater> you don't appreciate me :( 15:14:13 <Purno> there's not much enthusiasm for the topic yet, is there? 15:14:15 <Purno> eh? 15:14:36 <Celestar> what topic? 15:14:42 <Celestar> Eddi|zuHause3: it will be. by me. soon 15:14:44 <Purno> the scenario contest 15:14:48 <Darkvater> nothing :). DaleStan had a topic where he explained the guy not to use appreciations for 'thank you' 15:15:08 <Purno> eh? I don't get it 15:15:40 <Darkvater> basically it boiled down to that if you can't even bother to say 'thank you' and only say 'thx' when thanking someone you might as well not say it 15:15:50 <Darkvater> ^ I was just kidding 15:16:28 <DaleStan> ITYM "abbreviations" 15:16:32 <Eddi|zuHause3> what he meant to say was that you should call him "my lord" 15:19:25 <Celestar> Brianetta: current date? 15:20:02 <Purno> Darkvater , same thing for "wb" i guess 15:20:14 * Darkvater hides 15:21:23 <Darkvater> Purno: yes 15:21:54 <Purno> besides, I always help my friends if it's necessary 15:22:04 <Purno> typing out "thank you" sounds quite useless to me 15:22:28 <Purno> it's not like I'm übergreatful you said "wb Purno" 15:22:31 <Purno> TBH 15:22:35 <Darkvater> you aren't??? 15:22:38 <Darkvater> I'm appalled 15:22:45 <Purno> I do however like the fact you have asked me to organize that scenario thingy 15:23:05 <Purno> Darkvater , nopes, TBH, I am not 15:23:13 <Darkvater> hehe 15:23:20 <Purno> it's not like you did something big and important for me :P 15:23:23 <Darkvater> not too many submissions though 15:23:28 <Purno> yeah 15:23:32 <Purno> I hope it?l be more 15:23:40 <Purno> btw, will the scenarios in the previous version stay included? 15:23:47 <Darkvater> only that cornwall guy, with the map too blocky and missing St. Michael's Mount even! 15:23:52 <Darkvater> and yours 15:24:03 <Purno> I sent in to scenarios 15:24:10 <Purno> and the cornwall map is blocky indeed. 15:24:14 <Purno> two* 15:25:23 <Purno> but lets hope the best scenarios will come, as they need time to make 15:27:25 <Darkvater> yeah 15:29:27 *** Purno [~Purno@5351CF18.cable.casema.nl] has quit [Read error: Connection reset by peer] 15:30:37 *** Purno [~Purno@5351CF18.cable.casema.nl] has joined #openttd 15:34:55 <Rubidium_> Darkvater/Maedhros: http://rubidium.student.utwente.nl/openttd/landinfo_read_all_data_on_init.diff <- fix for that segfault on removal of town that makes all the strings on initialization of the window 15:37:27 <Maedhros> Rubidium_: nice :) 15:39:10 *** ufoun [~ha@b07-305a.kn.vutbr.cz] has joined #openttd 15:41:12 *** ufoun [~ha@b07-305a.kn.vutbr.cz] has quit [] 15:54:06 <peter1138> Darkvater: that thread's even better now 15:54:50 <peter1138> <Multicar> heh 15:55:03 <peter1138> someone who has no concept of XML, let alone NFO :) 15:55:43 <Eddi|zuHause3> XML is way too hyped 16:02:13 <Brianetta> A "copyright" flag doesn't contain enough information (: 16:02:31 <Brianetta> XML is all right, but it's best for report-style data 16:02:38 <Brianetta> like COBOL programmers are used to 16:02:55 <Brianetta> highly structured and sequential 16:03:24 <Eddi|zuHause3> i can't imagine newgrfs to be sequential 16:04:03 <Eddi|zuHause3> especially if they're supposed to be turing complete (minus memory limit) 16:06:34 <Eddi|zuHause3> besides, for programmers, XML is way too bloated, and non-programmers don't have enough overview 16:06:53 <Eddi|zuHause3> so whoever you are trying to please, XML won't manage that 16:07:09 <Brianetta> XML is a data language 16:07:24 <Brianetta> People see newgrfs as data packages 16:07:28 <Brianetta> when they are mods 16:07:37 <Eddi|zuHause3> exactly 16:07:43 <Brianetta> with executable code 16:08:02 <Brianetta> executable within an interpreter, rather than ona CPU, but executable nonetheless 16:09:41 <Brianetta> w00t! 16:09:51 <Brianetta> http://ppcis.org/standard/screenshot.png 16:10:51 <Eddi|zuHause3> maybe you should take screenshots of meaningful places (like town centers, or station signs 16:10:56 <Eddi|zuHause3> ) 16:11:15 *** GoneWacko [~gonewacko@c18041.upc-c.chello.nl] has quit [Ping timeout: 480 seconds] 16:13:12 <peter1138> Brianetta: i like this guys arbitrary tag names made up based on what pikka wrote... 16:13:42 <Brianetta> peter1138: Well, you know, he probably has this enormous hash in mind 16:13:59 <Brianetta> WHat he's proposing could work, but it wouldn't be better in any way. 16:19:42 * Smoovious rubs the sleep out of his eyes, looks at his game. 16:20:21 <Smoovious> hey guys... made it all the way through to the end of a networked game... not a single desync through the whole thing. :D 16:21:03 <Brianetta> Smoovious (: 16:21:38 <Smoovious> my thoughts exactly. :) 16:22:04 *** GoneWacko [~gonewacko@c18041.upc-c.chello.nl] has joined #openttd 16:22:27 <peter1138> wait... 16:22:29 <peter1138> "end" ? 16:22:35 <peter1138> what is an "end" ? 16:22:56 <Eddi|zuHause3> when the server crashes unrecoverably ;) 16:23:06 <Smoovious> Dec 29th 2040... I'm still connected to the server... my animations are still going so I'm not froze up... nothing is moving 16:23:16 <Smoovious> tho now that you mention it... 16:23:19 *** PandaMojo__ [~chatzilla@ip72-197-231-130.sd.sd.cox.net] has joined #openttd 16:23:21 *** PandaMojo__ is now known as PandaMojo 16:23:32 <Smoovious> there should be some kind of winning screen, shouldn't there? (I'm in 1st) 16:23:40 <peter1138> 2050 16:23:41 <peter1138> usually 16:23:46 <Smoovious> ahh 16:23:46 <peter1138> well, 2051 16:23:57 <peter1138> end at 2050 means end of 2050 16:24:02 <Smoovious> ok... you're right 16:24:08 <Smoovious> end-game is set to 2051. :( 16:24:25 <Smoovious> still tho... never got this far in a networked game yet 16:25:16 *** Sacro [~Ben@adsl-83-100-150-11.karoo.KCOM.COM] has joined #openttd 16:25:16 <Eddi|zuHause3> i always wanted to ask... why do we have a setting of "end year" but it cannot be modified? 16:25:58 <Smoovious> just lost my network connection. :( 16:26:10 <Smoovious> gonna find out if the host did it himself, or what 16:26:13 *** GoneWacko [~gonewacko@c18041.upc-c.chello.nl] has quit [Read error: Connection reset by peer] 16:26:56 *** GoneWacko [~gonewacko@c18041.upc-c.chello.nl] has joined #openttd 16:27:45 <Brianetta> Eddi: It can't? 16:28:18 *** PandaMojo_ [~chatzilla@ip72-197-231-130.sd.sd.cox.net] has quit [Ping timeout: 480 seconds] 16:29:03 <Digitalfox> Doesn't end year can only be changed in a network game? At least that's why i think you can't change it :) 16:29:28 <Smoovious> the server should be able to change it, but nobody else 16:31:03 <Eddi|zuHause3> i've never made server, but in SP it can't be changed 16:31:47 <CIA-1> rubidium * r8030 /trunk/src/misc_gui.c: -Fix: segmentation fault when removing a town in the scenario editor while having the query tool window open for one of the town's tiles. 16:31:55 *** GoneWack1 [~gonewacko@c18041.upc-c.chello.nl] has joined #openttd 16:32:20 <Brianetta> Rubidium_: Shouldn't that be backported to 0.5? 16:33:35 <Rubidium_> there are more patches that should be backported 16:34:29 <Rubidium_> and 8030 is one of them 16:36:15 *** GoneWacko [~gonewacko@c18041.upc-c.chello.nl] has quit [Ping timeout: 480 seconds] 16:36:15 *** GoneWack1 is now known as GoneWacko 16:37:48 <CIA-1> KUDr * r8031 /branches/cpp/ (11 files in 3 dirs): Sync with trunk (r8013:8029) 16:43:46 <Smoovious> ok... it appears that my end still thought I was connected to the server... it only disconnected, when I tried to do something that required sending what I did to the server, which then timed out and 'lost connection' 16:44:00 <Smoovious> but it didn't detect that I wasn't connected until that point 16:46:02 <MiHaMiX> Darkvater: pong 16:48:20 *** Chrill [~chrillech@c213-89-192-200.bredband.comhem.se] has joined #openttd 16:48:24 <Chrill> WAAAH 16:48:36 <Chrill> I need to ask a question concerning the Map Contest 16:48:49 <Chrill> Or, well, concerning .grf on a scenario 16:49:15 *** Celestar [~Jadzia_Da@galadriel.td.mw.tum.de] has quit [Read error: Connection reset by peer] 16:49:23 <Chrill> I haven't used any .grf for making the scenario in question, but they have been installed. Now I can't load the map on a clean OpenTTD. Is there a way to "clean" the scenario? 16:50:44 <Rubidium_> open the scenario in the 'unclean' version 16:51:16 <Chrill> well 16:51:26 <Rubidium_> click the wrench, then NewGRF settings, remove all grfs 16:51:33 <Chrill> well 16:51:35 <Rubidium_> and do not forget to click 'apply changes' 16:51:35 <Chrill> I did 16:51:45 <Chrill> But the scenario was made with them installed 16:52:03 <Chrill> And now I can't load scenario without, even though the .grfs in question wasn't used in the scenario 16:52:51 <Rubidium_> yes, so you have to remove them manually from the scenario (once) 16:52:56 <Chrill> well 16:52:59 <Rubidium_> do as I said and then save the scenario 16:53:04 <Chrill> ok.. 16:53:05 <Rubidium_> they should be removed 16:58:32 <Chrill> Thanks, it worked :D:D:D 16:59:32 *** Chrill [~chrillech@c213-89-192-200.bredband.comhem.se] has quit [Quit: An Eye for an eye makes the whole world blind] 17:02:35 *** Progman [~progman@p57A1E1C1.dip.t-dialin.net] has quit [Remote host closed the connection] 17:09:00 *** Digitalfox [~chatzilla@bl7-176-107.dsl.telepac.pt] has quit [Quit: Bye Bye...] 17:09:03 *** |Jeroen| [~jeroen@dD5772982.access.telenet.be] has joined #openttd 17:15:31 *** davos [~davos@217198148130-host.dependit.net] has quit [Ping timeout: 480 seconds] 17:23:40 <FlashFF> does anyone know if anyones ever worked on anything to do with implenenting mysql use into ottd? 17:24:14 <stillunknown> mysql for what? 17:24:20 <FlashFF> i am teh spell0r! 17:24:26 <FlashFF> logs and such 17:24:40 <FlashFF> real time statistic tracking 17:24:47 <FlashFF> that type of thing 17:25:03 <stillunknown> not that i'm aware of 17:25:18 <FlashFF> hmm 17:25:43 <FlashFF> that means i have to write it allll myself 17:25:49 <FlashFF> which soundds like a mighty amount of work 17:26:15 <stillunknown> have you searched the forum and bugtracker? 17:27:56 <FlashFF> bugtracker yes 17:27:58 <FlashFF> forum no 17:28:04 <FlashFF> forum scares me 17:29:01 <FlashFF> zomg someone stoled my idea 17:29:08 <FlashFF> last july 17:29:15 <FlashFF> lol 17:31:42 <peter1138> why would you "implement" mysql? 17:32:19 <FlashFF> funsies 17:32:26 <FlashFF> the q is, why wouldnt i? 17:33:13 <peter1138> well, what would you do with it? 17:33:17 <FlashFF> its a fast and flexible system works on many platforms and could open up endless statistic based possibilities 17:33:41 <peter1138> not to mention that mysql fucking sucks 17:33:44 <FlashFF> i persoally would have it keep a real time track of clients and a day to day overview of company progression on the server 17:34:19 <FlashFF> id also may a registered user section to allow people to become regs and feel more involved 17:34:30 <FlashFF> other games have similar systems so why not this one 17:35:08 <stillunknown> wasted effort maybe 17:37:41 <FlashFF> well i think itd be nice 17:37:51 <FlashFF> whether or not anyone else cared is beside the point 17:42:07 * Smoovious shakes his head. 17:42:36 <blathijs> When designed properly, it shouldn't even be too hard to implement 17:45:21 <stillunknown> blathijs: is an indexed memory pool rare? 17:46:12 *** DJ_Mirage [~sexybigge@biggetje.xs4all.nl] has joined #openttd 17:47:28 <blathijs> stillunknown: Haven't really done the homework, tbh. I just don't expect there will be anything easily available, at least in C that is flexible enough 17:48:16 <stillunknown> blathijs: memory pools seem mostly pointer driven 17:48:30 <stillunknown> just curious if they have a special name or something like that 17:48:41 <blathijs> Not that I know of :-) 17:49:24 <peter1138> indexed is fairly common 17:49:33 <peter1138> for example, the map stores indices, not pointers 17:50:36 <stillunknown> but the map i hardly dynamic memory allocation :-) 17:50:41 <stillunknown> *is hardly 17:51:03 <peter1138> how is that relevant 17:51:23 <peter1138> every GetStationByTile() uses a pool lookup by index 17:52:20 <peter1138> unless you're referring to something else, of course 17:52:30 <stillunknown> that's oldpool 17:52:37 <stillunknown> the map is not managed by oldpool 17:53:19 <Eddi|zuHause3> you mean you want to poolerize the entire map? 17:53:54 <stillunknown> I'm just thinking about the new map ideas KUDr had 17:54:46 <stillunknown> which would involve a pool for busy/large tiles 17:56:12 <CIA-1> KUDr * r8032 /branches/cpp/src/misc_gui.cpp: Sync with trunk (r8029:8031) 17:58:52 *** fcbarcelona [~fcbarcelo@82.198.125.154] has joined #openttd 17:59:52 *** fcbarcelona [~fcbarcelo@82.198.125.154] has quit [] 18:01:17 <Eddi|zuHause3> i'm not sure if i am up to date with the latest ideas 18:01:40 *** Digitalfox [~digitalfo@bl8-41-217.dsl.telepac.pt] has joined #openttd 18:02:35 <SpComb> Logs: http://zapotek.paivola.fi/~terom/logs/openttd 18:02:35 <Digitalfox> !logs 18:02:39 <Eddi|zuHause3> so you reduce the size of the current map to the really "important" values? (height, and maybe some basic rail layouts), and get any "extended" information from pool objects 18:03:19 <stillunknown> There were newmap plans, which involved a stacked tile approach. 18:03:56 <stillunknown> The basic tile would be 4 bytes, containing either basic things or an index to a large tile. 18:05:16 <stillunknown> The lack of of real bridges and tunnels is becoming problematic. 18:05:32 <Eddi|zuHause3> yeah, i understood that ;) 18:05:41 *** Wolf01 [~wolf01@host71-208-dynamic.58-82-r.retail.telecomitalia.it] has joined #openttd 18:05:54 <Eddi|zuHause3> i'm just concerned how that would affect performance 18:05:56 <Wolf01> ello 18:05:59 <peter1138> hello 18:06:57 <Eddi|zuHause3> one of the biiiig disadvantages of simutrans was, that every tile was handled as an object, so only after allocating half the map, and really extensive swapping, the game noticed that it ran out of memory 18:07:21 <Eddi|zuHause3> while in OTTD, you just allocate the big map, and it either works, or it doesn'T 18:07:22 <stillunknown> tiles in simutrans are supposedly huge 18:07:45 <Eddi|zuHause3> yes, but the problem is not really dependent on the actual size 18:07:50 *** glx|away [glx@bny93-6-82-245-156-124.fbx.proxad.net] has joined #openttd 18:08:35 <stillunknown> Eddi|zuHause3: your concern is valid, however, how else can extra tiles be dealt with? 18:09:20 <stillunknown> it's a waste of memory to allocate twice the needed tiles or something like that 18:09:25 <Eddi|zuHause3> i'm not saying it should be done differently, i'm saying it should be done carefully 18:09:59 <Eddi|zuHause3> like: how do you handle if you run out of memory midgame? 18:10:14 <Eddi|zuHause3> it should not just crash 18:10:22 <stillunknown> Eddi|zuHause3: dump a savegame and kill the game? 18:10:40 <stillunknown> if that's possible at all 18:10:47 *** GoneWacko [~gonewacko@c18041.upc-c.chello.nl] has quit [Ping timeout: 480 seconds] 18:10:56 <Eddi|zuHause3> no, because if you run out of memory, that does not mean you have no place to store anything left... 18:11:19 <stillunknown> the same would happen if you run out memory and you need an extra vehicle 18:11:22 <Eddi|zuHause3> supposedly, the pool is requesting large chunks of memory, depending on its current size 18:11:44 <Eddi|zuHause3> so if you expand the pool, and that fails, the pool is still not necessarily full 18:11:54 <Rubidium_> Eddi|zuHause3: the game can crash now too when it runs out of memory 18:12:02 <peter1138> you only expand the pool when it's ful... 18:12:03 <peter1138> +l 18:12:21 <CIA-1> KUDr * r8033 /trunk/src/ (310 files in 11 dirs): [cpp] - Prepare for merge from branches/cpp (all .c files renamed to .cpp) 18:13:22 <Eddi|zuHause3> ok, maybe i expressed myself incorrectly 18:13:35 <Eddi|zuHause3> if you want to e.g. double the pool size, and that fails 18:13:50 <Eddi|zuHause3> there may still be a lot of memory left to expand the pool 18:13:56 <stillunknown> you don't double a pool size, unless it was very small to begin with 18:13:57 <Eddi|zuHause3> without immediately crashing 18:14:23 <Eddi|zuHause3> you definitely want to expand the pool based on its current size 18:14:24 <stillunknown> you're talking about small amounts of memory 18:14:45 <Eddi|zuHause3> or you end up with expanding it hundreds of times in baby steps 18:15:26 <blathijs> keeping the step size equal does make things simpler 18:15:37 *** glx [glx@bny93-6-82-245-156-124.fbx.proxad.net] has quit [Ping timeout: 480 seconds] 18:15:37 <Eddi|zuHause3> anyway, if you can anticipate that you might soon run out of memory, you can warn the user in advance 18:15:49 *** glx|away is now known as glx 18:16:13 <blathijs> Currently, if you run out of memory, the current action will fail (such as building a vehicle) 18:16:25 <Eddi|zuHause3> blathijs: yes, but a 64x64 map might need much different pool steps than a 2048x2048 map 18:16:25 <blathijs> after that, other stuff will probably start failing too, though 18:16:43 <blathijs> Depends, vehicles are still vehicles... 18:16:53 <stillunknown> Eddi|zuHause3: a pool is probably expand in N elements of the size they are supposed to fit 18:17:13 <stillunknown> *expanded with 18:17:22 <peter1138> anticipating running out of memory is not really possible 18:18:00 *** Wolf01|AFK [~wolf01@host138-161-dynamic.56-82-r.retail.telecomitalia.it] has joined #openttd 18:18:00 *** Wolf01 [~wolf01@host71-208-dynamic.58-82-r.retail.telecomitalia.it] has quit [Killed (NickServ (GHOST command used by Wolf01|AFK))] 18:18:02 <stillunknown> blathijs: can you explain in semi-layman terms why your pool (too) has macros 18:18:57 <stillunknown> long macro's i mean 18:19:00 <blathijs> Because you want to write GetStation(10) instead of (Station*)GetItemFromPool(&_station_pool, 10) 18:19:06 *** pecisk [~pecisk@purvc-44-54.maksinets.lv] has joined #openttd 18:19:18 <blathijs> and more stuff like that 18:19:46 <Eddi|zuHause3> shouldn't that be possible with templates now? 18:19:46 <blathijs> the macro's are not complicated, you just want to have a number of accessors defined for each pool 18:20:06 <blathijs> Eddi|zuHause3: Yes, it wil probably be station_pool->Get(10) now 18:20:11 *** wolf02 [~wolf01@82.56.161.138] has joined #openttd 18:20:13 *** wolf02 is now known as Wolf01 18:20:28 <blathijs> that's why I held off dev on the pools the last two weeks (that and time issues :-) 18:20:59 <peter1138> #define GetStation(x) station_pool->Get(x) 18:21:00 <peter1138> heh 18:24:54 <CIA-1> rubidium * r8034 /trunk/src/ (aircraft_cmd.c aircraft_cmd.cpp): -Fix (r8033): aircraft_cmd.c was not renamed. 18:26:05 *** Wolf01|AFK [~wolf01@host138-161-dynamic.56-82-r.retail.telecomitalia.it] has quit [Ping timeout: 480 seconds] 18:26:12 <stillunknown> blathijs: so you will adapt your pools to c++? 18:26:28 <Smoovious> <Eddi|zuHause3> blathijs: yes, but a 64x64 map might need much different pool steps than a 2048x2048 map <--- once the map is generated, does it really have to increase much more? at that point, you are just adding bridge/road/track/vehicle/etc data 18:26:40 <blathijs> stillunknown: That was the plan, yes 18:26:50 <Eddi|zuHause3> Smoovious: houses? 18:27:03 <Smoovious> that's still a gradual thing tho 18:27:12 <Eddi|zuHause3> houses are exactly the biggest tiles 18:27:25 <Eddi|zuHause3> and cities grow fast, if you service them 18:27:29 <Smoovious> but it isn't going to increase 1Mb at a moment 18:27:47 <Smoovious> it is still gradual 18:28:01 <blathijs> Eddi|zuHause3: Coming to think of it, I don't think it should be a problem to increase puddle sizes at runtime with the new pools (ie, each block allocated will be bigger) 18:28:22 <blathijs> Perhaps base that on the time since the last memory allocation or something 18:29:01 <Smoovious> say you have 64k chunks of memory... if at some point, you don't have a full 64k chunk available, then reserve another... (much like how I do my food shopping... soon as I open the last unopened box of something, I replace it, so I always have an unopened/unused box available) 18:29:30 <Eddi|zuHause3> Smoovious: and if you throw a party? 18:29:38 <Eddi|zuHause3> you still have only 1 box of everything around? 18:29:57 *** setrodox [~setrodox@83-65-234-231.dynamic.xdsl-line.inode.at] has quit [Remote host closed the connection] 18:30:03 <Eddi|zuHause3> and you end up running to the next service station 20 times that night 18:30:04 <Smoovious> if I throw a party, I usually know I'm going to do so ahead of time, and plan accordingly... that is a handled exception to my normal usage 18:31:38 <Smoovious> the only time city growth isn't going to happen gradually, is during map generation, or scenario building... and you can anticipate for that... but during the normal course of a game, no city is just going to explode suddenly... 18:31:54 <blathijs> Smoovious: And if you can't allocate that extra block, go into panic mode :-) 18:31:55 <Eddi|zuHause3> and on the other side, a 64k chunk is probably bigger than anything you would ever need on a 64x64 map 18:32:17 <Smoovious> blathijs... if you can't allocate that extra block, then maybe it is time you replace that 486 with something more recent 18:32:29 *** helb [~helb@84.244.90.159] has quit [Remote host closed the connection] 18:32:51 <Smoovious> doesn't matter tho, Eddi|zuHause3... a 64k block is nothing, whatsoever, in relation to what today's computers have available... 18:33:02 <blathijs> Smoovious: I thougth you were proposing something to handle out-of-memory, but apparently not 18:33:07 <Eddi|zuHause3> well, maybe you are running 200 servers or something 18:33:20 *** helb [~helb@84.244.90.159] has joined #openttd 18:33:26 <blathijs> In that case: It doesn't make sense to have full blocks of unused allocated memory around 18:33:30 <blathijs> Memory allocation isn't shopping 18:33:34 <Smoovious> blathijs... no, wasn't proposing the point where you actually run out... but where you anticipate needing more before you get to that point 18:34:03 *** peter1138 is now known as Tron1138 18:34:31 *** Wolf01 is now known as Wolf01|AWAY 18:34:32 *** MiHaMiX is now known as Tron_XxX 18:34:37 <blathijs> Smoovious: It won't be less trouble to allocate memory in advance, so nothing is gained there 18:34:39 <Smoovious> they're both resources 18:34:42 *** Belugas is now known as Trongas 18:34:42 *** Tron1138 is now known as peter1138 18:34:46 <blathijs> aah 18:34:50 <blathijs> stop the renaming thing 18:34:50 *** Tron_XxX is now known as MiHaMiX 18:34:51 *** Trongas is now known as Belugas 18:35:00 <blathijs> slams hands against ears 18:35:07 <blathijs> You're driving me nuts! 18:35:09 <blathijs> ;-p 18:35:12 <blathijs> Ah.. 18:35:15 <blathijs> Where was I? 18:35:28 <Smoovious> except for perhaps, being able to warn the player it can't reserve any more memory and that he should save his game while he still can 18:35:33 <qball> blathijs: somewhere at being nuts 18:35:38 <Smoovious> or free up more 18:36:07 <Smoovious> instead of just crashing 18:36:08 <blathijs> Smoovious: True, but that won't really help (unless you will unfree all those unused blocks to save space to actually be able to save the game) 18:36:49 <blathijs> But you weren't proposing anything to help the out-of-memory case, you promised ;-p 18:38:15 <CIA-1> rubidium * r8035 /branches/cpp/ (27 files in 7 dirs): [cpp] -Fix: various (parts of) syncs were missed. 18:39:57 * blathijs is away for the night, cya later 18:40:57 *** Tron [~tron@p54A3E113.dip.t-dialin.net] has joined #openttd 18:41:43 *** Nigel [~nigel@202-154-144-120.ubs-dynamic.connections.net.nz] has quit [Quit: Lost terminal] 18:43:54 <CIA-1> rubidium * r8036 / (6 files in 2 dirs): [cpp] -Fix (8035): forgot to delete two files. 18:44:56 <CIA-1> rubidium * r8037 /trunk/projects/ (langs.vcproj langs_vs80.vcproj): -Fix (r7987): MSVC project files were not updated with respect to the addition of slovenian. 18:49:55 *** Wolf01|AWAY is now known as Wolf01 18:53:20 <Wolf01> :| all cpp... now i hope i can compile... and i must AGAIN port all the patches 18:53:21 *** KritiK [Maxim@ppp85-141-224-92.pppoe.mtu-net.ru] has joined #openttd 18:53:48 <stillunknown> Wolf01: the transfer isn't done yet 18:53:50 <MiHaMiX> Wolf01: wait for the merge :D 18:56:09 <raimar2> Rubidium_: 18:56:11 <raimar2> hawk@stone:~/ott/open> make 18:56:11 <raimar2> make[1]: Entering directory `/home/hawk/ott/open/objs/lang' 18:56:11 <raimar2> make[1]: *** No rule to make target `/home/hawk/ott/open/src/string.c', needed by `string.o'. Stop. 18:56:50 <Rubidium_> raimar2: very much known, as we're currently merging cpp in two stages 18:57:01 <CIA-1> rubidium * r8038 /trunk/ (190 files in 15 dirs): -Merge: the cpp branch. Effort of KUDr, Celestar, glx, Smoovius, stillunknown and pv2b. 18:57:11 <Darkvater> he 18:57:12 <Rubidium_> now it should work 18:57:14 *** Nigel [~nigel@202-154-144-120.ubs-dynamic.connections.net.nz] has joined #openttd 18:57:15 <Darkvater> just missed it :) 18:58:06 <raimar2> ahh 18:58:22 <raimar2> so what is/was the purpose of the cpp branch? 18:58:25 <raimar2> c++ support? 18:58:46 <KUDr> Java 18:59:02 *** fcbarcelona [~fcbarcelo@82.198.125.154] has joined #openttd 18:59:03 <PandaMojo> What!! Not pythong? Or ruby? 18:59:12 *** helb [~helb@84.244.90.159] has quit [Quit: Leaving] 18:59:36 <raimar2> make[1]: Entering directory `/home/hawk/ott/open/objs/release' 18:59:36 <raimar2> Makefile:211: warning: overriding commands for target `settings.o' 18:59:36 <raimar2> Makefile:207: warning: ignoring old commands for target `settings.o' 18:59:36 <raimar2> Makefile:211: warning: overriding commands for target `signs.o' 18:59:37 <raimar2> ... 18:59:46 <raimar2> [SRC] Compiling and Linking endian_check 18:59:46 <raimar2> [SRC] Testing endianness for target 18:59:46 <raimar2> [SRC] No such source-file: /home/hawk/ott/open/src/=======.[c|cpp|m|rc] 18:59:46 <raimar2> cc /home/hawk/ott/open/src/=======.o -o /home/hawk/ott/open/src/======= 18:59:46 <raimar2> cc: /home/hawk/ott/open/src/=======.o: No such file or directory 18:59:49 <raimar2> cc: no input files 18:59:51 *** helb [~helb@84.244.90.159] has joined #openttd 18:59:53 <raimar2> make[1]: *** [/home/hawk/ott/open/src/=======] Error 1 18:59:55 <Nigel> pastebin? 19:00:07 <KUDr> hmm 19:00:20 <CIA-1> miham * r8039 /trunk/src/lang/ (7 files in 2 dirs): (log message trimmed) 19:00:20 <CIA-1> WebTranslator2 update to 2007-01-10 19:58:43 19:00:20 <CIA-1> brazilian_portuguese - 15 changed by fukumori (15) 19:00:20 <CIA-1> danish - 23 changed by MiR (23) 19:00:20 <CIA-1> greek - 12 fixed by Kesnar (12) 19:00:22 <CIA-1> japanese - 282 fixed by ickoonite (282) 19:00:22 <CIA-1> slovenian - 1 changed by Necrolyte (1) 19:00:29 <glx> raimar2: it should reconfigure automatically before recompile 19:00:44 <raimar2> it did 19:00:51 <raimar2> no help 19:00:52 <peter1138> make clean might be required 19:01:46 <peter1138> actually 19:01:48 <raimar2> uhh sorry 19:01:52 <peter1138> that's a conflict line :) 19:01:53 <Eddi|zuHause3> raimar2: maybe conflicts? 19:02:01 <peter1138> revert away 19:02:02 <raimar2> the reason was that I had some custom changes 19:02:06 <raimar2> nono 19:02:19 <raimar2> I'm working on train support for trolly 19:02:56 <Rubidium_> never update without knowing what you are going to update, as it can really trash your patches 19:04:30 <Tron> mkdir -p lang 19:04:30 <Tron> cp -u /usr/home/tron/projekte/ottd/clean/src/lang/english.txt lang/english.txt 19:04:30 <Tron> cp: illegal option -- u 19:04:57 <raimar2> uhhh now I get nice c++ errors 19:05:39 <Wolf01> make[1]: *** No rule to make target `C:/msys/home/OpenTTD/trunk/src/window.c', needed by `window.d'. Stop. 19:06:09 <KUDr> here it works (g++) 19:06:51 <MiHaMiX> Tron: -u, --update 19:06:52 <MiHaMiX> copy only when the SOURCE file is newer than the destination file or when the destination file is missing 19:07:01 <Tron> MiHaMiX: it's a GNUism 19:07:28 <MiHaMiX> Tron: yes, as we consider ourselves modern people :) 19:07:39 <Rubidium_> Tron: is there an -u variant for BSD? 19:07:44 <Tron> hint: you are NOT funny 19:07:55 <Tron> Rubidium_: no 19:08:05 <MiHaMiX> Tron: hint: you don't have sense of humour, so it's not a surprise :) 19:08:31 <peter1138> is -u even needed? 19:08:44 <MiHaMiX> peter1138: not really, but that's not the point :D 19:08:52 <Tron> you being not funny is unrelated to me havin a sense of humour 19:09:19 <MiHaMiX> Tron: parse error on line 1 19:09:33 <Rubidium_> peter1138: otherwise it copies english.txt every time when it is unneeded, which causes a remake of table/strings.h 19:09:51 <Tron> it's not cp's job, there's test for this kind of thing 19:10:15 <Wolf01> how to configure without font stuff? 19:10:21 <Wolf01> --without-? 19:10:27 <Tron> [ foo -nt bar ] && cp ... 19:11:02 <Wolf01> np, found 19:11:07 <peter1138> Wolf01: if it doesn't automatically get disabled it's buggy 19:11:18 <peter1138> unless you've got it installed but just don't want it 19:11:51 <Rubidium_> peter1138: it should be automatically disabled now 19:11:57 <Darkvater> do I dare svn up? 19:12:05 <peter1138> not if you have local changes 19:12:39 <Darkvater> grr 19:12:48 <Eddi|zuHause3> <Rubidium_> peter1138: otherwise it copies english.txt every time when it is unneeded, which causes a remake of table/strings.h <- copying should not change the timestamp 19:12:59 <Darkvater> I'll wait some more then 19:13:14 <peter1138> wait for what? 19:13:18 <Darkvater> to svn up 19:13:26 <Darkvater> until I finish my debugging session 19:13:32 <peter1138> heh 19:13:38 <CIA-1> truelight * r8040 /trunk/ (configure source.list): [Configure] -Fix: for some reason, OS2 compiled unix.cpp, not os2.cpp 19:14:09 <Wolf01> ok, seem to compile 19:14:17 <Tron> Rubidium_: why is the -u there anyway? 19:14:29 <Wolf01> seem to run 19:14:30 <Rubidium_> otherwise it copies english.txt every time when it is unneeded, which causes a remake of table/strings.h 19:14:42 <peter1138> doesn't for me 19:14:49 <Tron> Rubidium_: do you understand how Makefiles work? 19:14:55 <Rubidium_> yes 19:15:06 <Tron> then read it 19:15:09 *** GoneWacko [~gonewacko@c18041.upc-c.chello.nl] has joined #openttd 19:15:37 <peter1138> the target is only made if it's needed 19:15:41 <Wolf01> patching is not possible... now i have only 8000 lines to patch manually 19:15:46 <peter1138> so.. 19:15:55 <peter1138> Wolf01: have fun. 19:16:19 <Tron> Wolf01: change the filenames in the diff 19:16:26 <Rubidium_> lang/english.txt: $(LANG_DIR)/english.txt <- (from Makefile) that copy is in here, why this executed when english.txt has not changed? 19:17:03 <peter1138> it's not for me 19:17:12 <raimar2> Wolf01: yes 19:17:48 <Rubidium_> peter1138: hmm, then my make(s) must be very broken 19:17:59 *** fcbarcelona [~fcbarcelo@82.198.125.154] has quit [Quit: Abandonando] 19:18:49 <Tron> nice, compiling only takes two and a half times as long as before 19:20:07 <Wolf01> doesn't work, i revert cpp changes with my patches 19:20:13 <Digitalfox> Tron: Maybe a some bug?? 19:20:19 <ln-> Tron: "than before" 19:20:29 <CIA-1> peter1138 * r8041 /trunk/src/newgrf.cpp: -Regression (r7564): [NewGRF] check_length should skip further processing if a length is too short, so give the function a return value 19:20:34 <KUDr> Tron: max 20% more 19:20:36 <ln-> +longer probably 19:20:55 <MiHaMiX> hm.. 19:20:55 <Tron> KUDr: no, 150% more 19:21:19 <KUDr> hmm, it must be something wrong on your side 19:21:21 <peter1138> takes about 20% more for me 19:21:22 <Tron> and that's a rather good value. i've seen about factor four 19:21:35 <Tron> KUDr: no, typical experience 19:21:45 <peter1138> up from 5m50 to 6m50 19:21:58 <Tron> 60 seconds -> 150 seconds 19:22:11 <peter1138> heh 19:22:14 <KUDr> Tron: yes, with boost library and g++ 19:22:25 <KUDr> not in this case 19:22:32 <peter1138> i need a faster pc in general :P 19:23:23 <Darkvater> what rev was cpp merge? 19:23:34 <Tron> 8038 19:23:47 <peter1138> 8038 19:23:52 <Darkvater> thx@all 19:23:58 <Darkvater> hmm 19:24:02 <stillunknown> 8032 was the last C working one 19:24:24 <peter1138> right, so, now we have C compiled as C++ 19:24:25 <Eddi|zuHause3> Wolf01: you just have to svn up to the revision before the .cpp rename, then svn diff, and in there, replace every .c with .cpp, then update to after the rename, and apply the modified diff 19:24:34 <peter1138> someone had better do some decent C++ work :P 19:24:37 <Tron> oh, and configure still tells me my C compiler doesn't exist 19:24:39 <MiHaMiX> Tron: compile farm worked 2 minutes longer than usually... so it was 17 minutes instead of 15, which is 13% longer 19:24:46 <Wolf01> eddi, i done so 19:25:17 * peter1138 makes a note to change some important header file in every commit just to make everyone have full recompiles 19:25:25 <KUDr> peter1138: it was pain to sync it so i am happy that it happened 19:25:29 <Darkvater> let's time this baby 19:25:30 <Wolf01> but i noticed that tortoise change more lines than the lines to patch 19:25:53 <Digitalfox> MiHaMiX: Compile farm only produced Morphos build 19:26:14 <MiHaMiX> Digitalfox: compile farm produced all builds 19:26:35 <MiHaMiX> Digitalfox: according to TL 19:26:39 <Digitalfox> MiHaMiX: at least not available in site 19:26:43 <Digitalfox> just morphos 19:26:54 *** HMage [~HMage@85.21.179.41] has joined #openttd 19:27:11 <MiHaMiX> Digitalfox: yes, but the files are there 19:27:21 <Digitalfox> MiHaMiX: you are right the files are there :) 19:27:28 <stillunknown> i went from 75 to 90 seconds 19:27:29 <Digitalfox> just not updated to the site 19:28:49 <Darkvater> what time do I need from time? 19:28:51 <Darkvater> real or user? 19:29:45 <peter1138> user 19:29:59 <peter1138> less dependent on what else is going on 19:32:12 *** tokai [~tokai@p54B821A4.dip0.t-ipconnect.de] has quit [Ping timeout: 480 seconds] 19:33:26 <peter1138> woah 19:33:30 <Darkvater> r8032: user 1m6.476s; r8041: user 1m21.713s 19:33:32 <Digitalfox> I just had a crash with windows nightly just by generating a map 19:33:48 <peter1138> what's all the stuff that moved to hal.h ? 19:33:56 <Darkvater> 24% slower 19:34:41 <KUDr> peter1138: all what is needed for video drivers 19:34:47 <Digitalfox> Hum.. I can't generate any map.. :\ 19:34:53 <KUDr> it is purpose of hal.h i guess 19:35:02 <peter1138> hal = hardware abstraction layer 19:35:21 <KUDr> yes, there was video stuff 19:35:45 <KUDr> if you want we can make another extra header for all video drivers abstraction 19:35:57 <KUDr> but hal.h was closest to it 19:36:00 <peter1138> cursors, and drawpixelinfo are distinctly not at the hal level 19:36:10 <peter1138> Rect... 19:36:21 <KUDr> so why they are required by drivers? 19:37:04 *** tokai [~tokai@p54B844E9.dip0.t-ipconnect.de] has joined #openttd 19:37:04 <KUDr> logically you are right 19:37:05 *** mode/#openttd [+v tokai] by ChanServ 19:37:17 * Digitalfox thinks he should wait that the great devs fix a bug where he can't play at all, not even savegames.. 19:37:20 <KUDr> huh tokai==morphos? 19:37:35 <KUDr> Digitalfox: here it works 19:37:45 <KUDr> what platform/compiler? 19:37:56 <Darkvater> I am with peter1138, hal.h only needs the stuff that are extern for the video drivers 19:37:59 <Darkvater> nothing else 19:38:10 <Digitalfox> How do i ativate de debug mode so i can create a crash file to send to you? 19:38:17 <KUDr> Darkvater: it is so now 19:38:24 <Digitalfox> Windows XP, nightly from compile farm 19:38:28 <Darkvater> so why does it have cursor/drawpixelinfo, etc.? 19:38:33 <Darkvater> Digitalfox: start with -d 19:38:34 <KUDr> i moved there only stuff required to compile cocoa driver 19:38:39 <Digitalfox> ok 19:38:47 <Darkvater> cocoa driver should include the headers it needs 19:38:52 <Darkvater> and not pollute hal.h 19:38:59 <Tron> Nov 07 16:39:27 <Tron> 11 seconds for dependencies, 61 seconds for compiling and linking 19:39:12 <KUDr> Darkvater: then it is not isolated 19:39:15 <Tron> that's even before fiddling with SDL_CONFIG and PNG_CONFIG 19:39:23 <Tron> which in turn 19:39:33 <KUDr> and there can't be any C++ specific things in those headers 19:39:44 <stillunknown> huh, you mean running ./configure takes 11 seconds? 19:39:44 <Tron> Nov 07 16:56:08 <Tron> yay, saves another 1.5 seconds here 19:39:44 <Tron> Nov 07 16:56:16 <Tron> about 8.5 seconds here now 19:39:57 <Darkvater> Tron: what are you talking about? 19:39:58 <CIA-1> orudge * r8042 /trunk/ (docs/Readme_OS2.txt src/os2.cpp src/stdafx.h): - Fix: OS/2 compilation with GCC (thanks to Paul Smedley and TrueBrain for their help) 19:40:04 <Tron> stillunknown: in november there was no configure 19:40:08 <Tron> Darkvater: compile time 19:40:36 <stillunknown> the ./configure is fast compared to some 19:40:55 <Tron> stillunknown: there was none at all, so this is totally beside the point 19:41:11 <Digitalfox> KUDr: It says MD5 of TRG1R.grf is Invalid.. I had apllied some newgrf 19:41:31 <Digitalfox> But with the last nighlty didn't had a problem 19:41:31 <peter1138> Tron: heh, configure was there, it just wasn't necessary 19:41:33 <stillunknown> nevertheless, you've got a strange or old system if it takes that long 19:41:41 <KUDr> TRG1R.grf - is this original? 19:41:52 <peter1138> yes 19:41:56 <Tron> stillunknown: what are you talking about? 19:42:05 <KUDr> so how it can have invalid md5? 19:42:12 <Tron> peter1138: and it's still broken here 19:42:16 <stillunknown> Tron: ./configure shouldn't take 11 seconds 19:42:24 <peter1138> KUDr: if it's not looking in the right file... say if it's not lowercasing it 19:42:24 <Tron> stillunknown: are you even reading what i write? 19:42:40 <Tron> stillunknown: the quoted line was from NOVEMBER, there WAS NO configure 19:42:42 <KUDr> peter1138: aha 19:42:54 <Digitalfox> KUDr: No with some newngrf, that i aplied from a newgrf exe file 19:42:57 <KUDr> because here it works fine 19:42:58 <Tron> stillunknown: it DIDN'T take 11 seconds, because IT WAS NON-EXISTENT 19:43:00 <tokai> KUDr: nope.. /me==osx atm. ;) 19:43:13 <stillunknown> Digitalfox: that explains it 19:43:21 <KUDr> aha 19:43:23 <Darkvater> Tron: dep-calculation was taking a long time for us, even after you shaved off big chunks off it 19:43:23 <Digitalfox> but, why does it complain now? 19:43:31 <stillunknown> it always has 19:43:39 <stillunknown> maybe you never noticed 19:43:39 <Tron> Darkvater: that's still totally beside the point 19:43:47 <Digitalfox> I mean until now it loaded always ok.. :\ 19:43:58 <Darkvater> it's not. Now it's almost instant, compared to the 20-some seconds it took before 19:44:14 <Tron> Darkvater: i experience a slowdown by at about factor 2. counting or not counting dependencies does not really matter 19:44:14 <KUDr> Digitalfox: so the old savegame with newgrfs is no longer loadable? 19:44:25 *** strep [~strep@195-50-215-68-dsl.krw.estpak.ee] has joined #openttd 19:44:27 <Tron> Darkvater: i'm just talking about raw time to compile 19:44:37 <Digitalfox> ok, but still got the crash in every time i try to create a map or load a game 19:44:40 <Digitalfox> no it isn't 19:44:58 <Tron> stillunknown: are you talking to me? 19:45:09 <stillunknown> Tron: not the last few lines 19:45:19 <stillunknown> sorry for confusion 19:45:31 <KUDr> Digitalfox: then you did something wrong 19:45:33 <Digitalfox> ok i used the -d command, and now for creating the dump crash file? 19:45:41 <Darkvater> you can't 19:46:16 * Digitalfox scraches the head a bit.. And go to wiki to see how to create a crash file 19:46:17 <KUDr> Digitalfox: try fresh checkout 19:46:25 <Digitalfox> KUDr: ok 19:48:53 <Digitalfox> KUDr: wiat a fresh instalation of nightly with no newgrf it work with no problems.. But i don't get it, before with newgrf it wotked ok, but now with newgrf it doesn't?? :\ 19:48:59 <Digitalfox> *with 19:49:14 <Digitalfox> *worked 19:49:20 *** strep [~strep@195-50-215-68-dsl.krw.estpak.ee] has left #openttd [Konversation terminated!] 19:49:40 <Darkvater> Digitalfox: you CAN'T create a crash file because the nightlies don't have code to create minidump files 19:49:52 <stillunknown> Digitalfox: which newgrf? 19:51:23 <Darkvater> WTF? 19:51:29 <Darkvater> KUDr: const Town* from = (const Town*)fr->from; 19:51:38 <Darkvater> you can't implicitly cast a pointer to const in C++? 19:52:15 <Digitalfox> stillunknown: various newgrf, from dbsetxl, newstations, etc... 19:52:17 <Brianetta> 19:52 <sarah_pilot> Pete has left the game (desync error) 19:52:33 <stillunknown> DIgitalfox: could you find out which is the problem? 19:52:42 <Digitalfox> yes i will try one by one 19:52:44 <KUDr> implicitly? cfom non const to const? yes 19:52:49 <KUDr> it should work 19:52:53 * Darkvater looks up code 19:53:11 <Brianetta> He hasn't re-desynced since joining 19:53:27 <Darkvater> ah sorry, it's a void* 19:53:32 <KUDr> Darkvater: yes, lot of cleanup will be needed now 19:54:12 <peter1138> /home/peter/ottd/trunk/src/ai/../hal.h:150: error: 'SpriteID' does not name a type 19:54:15 <peter1138> meh 19:54:19 <peter1138> shouldn't be in hal :P 19:54:35 <KUDr> Digitalfox: it sounds weird, here i can load old savegames with newgrfs 19:55:05 <KUDr> peter1138: /ai/../hal.h ? 19:55:12 <KUDr> it is ai hal? 19:55:22 <stillunknown> no 19:55:28 <stillunknown> .. is one level lower 19:55:33 <stillunknown> so src/hal.h 19:55:36 <peter1138> openttd.h includes hal.h 19:55:39 <KUDr> so it belongs to ai 19:57:54 <Digitalfox> KUDr: Ok i found it ... I use for some testing TTRS-3.01 for the new roads and depots.. I know it doesn't work properly with openttd witout being newhouses branch, but was testing it for roads and depots.. It makes now crash openttd.. 19:58:33 <KUDr> hmm 19:58:49 <KUDr> so you mean it is bug in openttd? 19:58:52 <Darkvater> hmm 19:58:59 <Darkvater> 219 _station_show_coverage = e->we.click.widget" target="_blank">we.click.widget - 16; 219 _station_show_coverage = (e->we.click.widget" target="_blank">we.click.widget != 16); 19:58:59 <KUDr> or in TTRS-3.01? 19:59:17 <Digitalfox> i don't know... I just know if load TTRS 3.01 with openttd it crashes.. Before it didn't.. :\ 19:59:29 <TinoM> (time make : user 0m18.530s 19:59:29 <TinoM> ) *G* 19:59:51 <KUDr> Darkvater: before there was '-' that produces also other values than 0 and 1 20:00:03 <KUDr> so it needed different formula 20:00:05 <Darkvater> KUDr: in airport_movement.h why do the directions need additional {}? 20:00:27 <KUDr> DirectionByte is a struct (for now) 20:00:28 <Darkvater> KUDr: I don't think it can produce anything else as the code only goes there when widget is 16 or when it is 17. But it's ok 20:00:49 <KUDr> Darkvater: yes, but compiler didn't know it 20:00:57 <KUDr> and complained 20:01:08 <Digitalfox> peter1138: TTRS-3.01 crashes openttd, can you take a look at it? 20:01:16 <KUDr> i wouldn't change it on my own 20:01:31 *** HMage [~HMage@85.21.179.41] has quit [Read error: Connection reset by peer] 20:01:37 <Darkvater> Digitalfox: ttrsv3 is NOT supported 20:01:43 <Darkvater> Digitalfox: try out the newhouses branch 20:01:57 <Digitalfox> Darkvater, ok but at least it shouldn't crash openttd.. 20:02:11 <Darkvater> use the newhouses branch 20:02:36 <KUDr> Digitalfox: 'not supported' means crash << new ISO standard 20:02:39 <Darkvater> 125 const ChunkHandler _depot_chunk_handlers[] = { 125 extern const ChunkHandler _depot_chunk_handlers[] = { 20:02:50 <Darkvater> why is 'extern' added? 20:03:00 <KUDr> Darkvater: find better solution please 20:03:07 <Digitalfox> Darkvater: ok.. It's just strange that one day before it didn't crash.. :) But i get the point ;) 20:03:09 <KUDr> i am not happy from it 20:03:10 <Darkvater> but the struct is defined right there 20:03:22 <KUDr> yes, but must be extern 20:03:31 <KUDr> and extern can't be initialized 20:03:33 * Darkvater is confused 20:03:59 <KUDr> only extern is visible for other modules 20:04:07 <Darkvater> in C++? 20:04:16 <KUDr> but in initialization you can't use it 20:04:24 <KUDr> i dunno 20:04:31 <KUDr> i am confused too 20:04:39 <Darkvater> so you're saying the keyword 'extern' has changed functionality with regards to C? 20:04:55 <KUDr> probably 20:04:56 <Darkvater> I always though 'extern' == import variable from other module 20:05:05 <Darkvater> s/variable/object/ 20:05:18 <KUDr> yes, but also export it if defined in this module 20:05:49 <Darkvater> ah 20:05:55 <KUDr> without this extern declaration it was not visible from outside -> unresolved external 20:06:07 <Darkvater> ugh... this is going to suck so much 20:06:13 <Darkvater> PlayerID* b = p->share_owners; 20:06:14 <Darkvater> PlayerByte* b = p->share_owners; 20:06:16 *** MeusH [~MeusH@host-ip18-138.crowley.pl] has joined #openttd 20:06:18 <Darkvater> :( 20:06:26 <KUDr> normally not since you normally have extern in header 20:06:26 <MeusH> hello 20:06:29 <KUDr> so only once 20:06:42 <KUDr> but not in this case 20:06:54 <KUDr> hello MeusH 20:07:09 <MeusH> hey KUDr 20:07:13 <MeusH> what are you developing? 20:07:17 <MeusH> hey caladan 20:07:42 <KUDr> MeusH: just relaxing after one week of big effort 20:08:02 <stillunknown> Darkvater: maybe you should make a todo list of things that are not so pretty now 20:08:08 <KUDr> and explaining my wife why i still have no time to talk to her 20:08:25 <stillunknown> go talk to her KUDr :-) 20:08:30 <KUDr> :) 20:08:31 <Darkvater> KUDr: go offline, we can moan and curse at C++ without you :) 20:08:45 <KUDr> hehe 20:08:51 <peter1138> KUDr 20:08:52 *** mikl [~mikl@tbv.faderhuset.org] has quit [Quit: In the end, all that matters is your relation with God...] 20:08:54 <peter1138> bridge->sprite_table = calloc(7, sizeof(*bridge->sprite_table)); 20:08:54 <KUDr> you can also when i am here 20:08:55 <peter1138> -> 20:08:58 <peter1138> CallocT(bridge->sprite_table, 7); 20:09:00 <peter1138> looks wrong to me 20:09:03 <Darkvater> do you want a helping hand? 20:09:17 <peter1138> &bridge->sprite_table, perhaps? 20:09:26 <KUDr> CallocT(&bridge->sprite_table, 7); 20:09:31 <KUDr> yes 20:09:33 <peter1138> ok 20:09:34 <KUDr> mistake 20:09:39 <Darkvater> isn't bridge->sprite_table a **? 20:09:40 <peter1138> that's Digitalfox's crash 20:09:41 <KUDr> i am very sorry 20:09:48 <KUDr> ohh 20:10:21 <Darkvater> I told ya this MallocT() etc is going to cause trouble :) 20:10:43 <KUDr> yes we agreed that it can be changed later 20:11:18 <CIA-1> rubidium * r8043 /trunk/src/video/cocoa_v.m: -Fix (8028): forgot setting a variable. 20:13:05 *** pecisk [~pecisk@purvc-44-54.maksinets.lv] has quit [Quit: J?iet prom] 20:13:24 *** HMage [~HMage@85.21.179.41] has joined #openttd 20:15:33 <Darkvater> but 20:15:42 <Darkvater> overall a very good job KUDr :D 20:15:51 <Darkvater> (so you hear something else from the constant btiching) 20:16:37 <stillunknown> KUDR: have fun, now you can explain your wife why you have time now :-) 20:19:07 <stillunknown> peter1138: i hope you're fixing that bug ;-) 20:19:26 <peter1138> what bug? 20:19:35 <peter1138> the CallocT? 20:20:04 <stillunknown> yes 20:20:06 <peter1138> ah 20:20:07 <peter1138> no 20:20:33 <peter1138> 1) i have source full of massive changes 2) other people could 20:21:09 <Darkvater> 274 return (int32)p1; 274 return -(int32)p1; 20:21:17 <Darkvater> does this sound like a bug to anyone? 20:21:27 <Darkvater> misc_cmd.cpp:274 20:21:45 <stillunknown> that sounds odd, to say the least 20:22:06 <Brianetta> Darkvater: Having massing desync issues now 20:22:12 <Darkvater> Brianetta: RC3? 20:22:24 <Darkvater> you shouldn't have cheered so soon :) 20:22:31 <Brianetta> yes 20:22:42 <Brianetta> poor edk265 is cursing his ISP 20:22:51 <Brianetta> he's not on long enough to explain what a desync is 20:23:09 <stillunknown> maybe change the entry message? 20:23:35 <Darkvater> ugh :s 20:23:35 <peter1138> Darkvater: some -10000000 are changed to 10000000 elsewhere 20:23:49 <Brianetta> I'm not desyncing 20:23:51 <Darkvater> why has a functional change been made? 20:23:59 <Darkvater> Brianetta: you're probably on since the beginning 20:24:05 <Brianetta> Darkvater: No 20:24:10 <Brianetta> I started tihs while I was at work 20:24:11 <Darkvater> or a longer time than most of us 20:24:18 <Brianetta> let me check 20:24:51 <Brianetta> 14:37 <sarah_pilot> Brianetta has joined the game 20:24:51 <Brianetta> 16:33 <sarah_pilot> Brianetta has joined the game 20:24:51 <Brianetta> 19:22 <sarah_pilot> Brianetta has joined the game 20:24:58 <Brianetta> Just under an hour 20:25:19 <stillunknown> Darkvater: which revs are you diffing? 20:25:35 <Darkvater> can you make a memdump? Not that I can do too much cause I'm on windows 20:25:57 <Darkvater> 8038 20:26:28 <glx> [21:21:16] <@Darkvater> 274 return (int32)p1; 274 return -(int32)p1;<-- this change is because you can't pass negative values to DoCommand() 20:26:29 *** GoneWacko [~gonewacko@c18041.upc-c.chello.nl] has quit [Quit: leaving] 20:26:40 <Brianetta> Darkvater: Memdump, how? 20:26:43 <Brianetta> It's a debug build 20:26:47 <Darkvater> no idea ;p 20:27:05 <Darkvater> glx: ? 20:27:16 <Darkvater> glx: it returns a negative vvalue now 20:27:29 <Brianetta> I needa kcore binary 20:27:30 <glx> it did before as p1 was negative 20:27:36 * Darkvater should probably look at the code 20:27:41 <glx> but now p1 is positive 20:28:07 <Darkvater> glx: so how does one know when to add or to subtract money from a player when return is always positive? 20:28:25 <Naksu> ... that's some horrible kludge 20:29:58 <Belugas> always negative! They always complain they have too much money! 20:30:01 <Darkvater> StringID str = IsValidPlayer(ci_to->client_playas) ? GetPlayer(ci_to->client_playas)->name_1 : (uint16)STR_NETWORK_SPECTATORS; 20:30:03 * Belugas hides 20:30:05 <Darkvater> ? 20:30:09 <Darkvater> I thought STR_ was StringID 20:30:10 <glx> !openttd Darkvater commit 7992 20:30:14 <_42_> Commit by celestar :: r7992 /branches/cpp/src/ (main_gui.cpp misc_cmd.cpp misc_gui.cpp) (2007-01-09 11:48:56 UTC) 20:30:16 <_42_> [cpp] - Change the coding of the money cheat. No longer pass a negative value to an unsigned variable and cast it around later on 20:30:46 <KUDr> Darkvater: STR_ were anonymous enums 20:30:57 <KUDr> now it is one big enum 20:31:10 <KUDr> but still not uint16 20:31:29 <peter1138> more enum hell 20:31:31 <peter1138> thanks c++ 20:31:48 <KUDr> thanks to C 20:32:02 <KUDr> otherwise it would not be done so 20:32:08 <KUDr> (probably) 20:32:41 <KUDr> name_1 would be enum 20:32:47 <KUDr> and then no cast needed 20:33:15 <Brianetta> What's GDB for dump core of running program? 20:34:57 <Brianetta> Darkvater: People aren't desyncing now 20:35:12 <peter1138> name_1 is a StringID 20:35:17 <peter1138> obviously 20:35:23 <Darkvater> Brianetta: o_O 20:35:36 <Brianetta> I attached gdb, it stopped, I detached it, and everything went fast for a few 20:35:41 <KUDr> but StringID is uint16 and STR_ is enum 20:35:44 *** pecisk [~pecisk@purvc-44-54.maksinets.lv] has joined #openttd 20:35:45 <peter1138> http://fuzzle.org/o/stringid.diff 20:35:45 <Brianetta> but nobody desynced 20:35:47 <peter1138> stupid diff 20:35:51 <Brianetta> or was disconnected 20:35:52 <KUDr> so we are assingning shits 20:35:55 <peter1138> shits 20:35:58 <Darkvater> KUDr: so how would it have been done in C++? 20:36:21 <KUDr> Darkvater: probably StringID should be enum 20:36:23 <Darkvater> peter1138: :O 20:36:28 <KUDr> or its shortened form 20:37:19 <Darkvater> that's a nice solution 20:38:11 <peter1138> now do that for SpriteIDs... 20:38:56 <Darkvater> doesn't a compiler have some upper limit for variable count? ;p 20:39:01 <peter1138> probably 20:39:06 <Brianetta> Darkvater: I can't figure out how to dump core, but my RC3 is unstripped and I have gdb, if you ever need to poke around it as it runs 20:39:23 <peter1138> also 20:39:29 <peter1138> that might allocate storage for each 20:39:40 <peter1138> so maybe a VARDEF (hahahaha0 20:39:52 <Darkvater> Brianetta: I would give it a try if it were windows, but gdb is pretty magic to me 20:39:58 *** GoneWacko [~gonewacko@c18041.upc-c.chello.nl] has joined #openttd 20:39:59 <peter1138> > gone 20:40:08 <Darkvater> I just thought you had a core last time Rubidium_ asked 20:40:13 <Brianetta> yeah, me too 20:40:17 <Darkvater> have a safe trip peter1138 :) 20:40:30 <Brianetta> Rubidium gave me some command to type 20:40:35 <Brianetta> but I have no logs 20:40:41 <Darkvater> in #openttd? 20:40:44 <KUDr> Darkvater: if you want STR_ to be not enum then 'static const StringID STR_xxx = 34567; 20:40:46 <Brianetta> yeah 20:41:00 <KUDr> static const is not variable 20:41:17 <KUDr> it doesn't allocate space for it 20:41:24 <KUDr> and it has no address 20:42:40 <Brianetta> You think connecting the debugger could have solved a desync issue? Doesn't seem right to me 20:43:19 <KUDr> Brianetta: 'debugger' means that it eliminates all bugs 20:43:23 *** HMage [~HMage@85.21.179.41] has quit [Read error: Connection reset by peer] 20:43:24 <hylje> :p 20:43:44 <Darkvater> Brianetta: I think he told you in PM cause there is no mentin of it 20:43:45 <Darkvater> only 20:44:48 <Darkvater> 12:34 < Rubidium_> ok, the stripped version is quite useless :( can you relink the binary and send the unstripped version? 20:44:51 <Darkvater> 12:35 < Brianetta> Can you tell me how? 20:44:54 <Darkvater> 12:38 < Brianetta> OK, chopped out the strip flag form Makefile and remade 20:45:49 <Darkvater> KUDr: he, funny that for C++ to work less painlessly with OTTD one should change all enums to static const :) 20:45:53 *** HMage [~HMage@85.21.179.41] has joined #openttd 20:46:47 <KUDr> Darkvater: what is wrong on enums? They are used commonly 20:46:57 <KUDr> only the g++ is too strict 20:47:18 <KUDr> we could tell him some flags to suppress it probably 20:47:25 <KUDr> but i dunno how 20:47:27 <Darkvater> it'd be probably easier to shut up g++ and use enum operations like we used to 20:47:40 <KUDr> yes 20:47:46 <HMage> read info on g++, there are some flags that make it less strict and more backwards-compatible with C 20:47:50 <KUDr> we can still do it 20:48:31 <KUDr> HMage: we should try it, yes 20:48:50 <KUDr> but i am too stupid for doing it 20:48:56 * HMage reinstalls visual studio 6 20:49:27 *** BobingAbout [~BobingAbo@adsl-83-100-162-38.karoo.KCOM.COM] has joined #openttd 20:49:32 *** BobingAbout [~BobingAbo@adsl-83-100-162-38.karoo.KCOM.COM] has quit [] 20:51:06 * Darkvater has no idea how to silence it 20:52:29 <KUDr> -Wblabla 20:52:33 <KUDr> ? 20:52:53 <Darkvater> hehe 20:52:57 <Darkvater> -Wshutup 20:53:03 <KUDr> yes! 20:54:50 *** |Jeroen| [~jeroen@dD5772982.access.telenet.be] has quit [Remote host closed the connection] 20:55:05 <HMage> what is the exact message, KUDr and what is the g++ version? 20:56:09 * HMage installs MSDN Library April 1999 20:56:40 <KUDr> HMage: i don't remember and various versions 20:57:00 <KUDr> many messages about conditional expressions 20:57:14 <KUDr> containing different types 20:57:33 <KUDr> 'enum' vs. another 'enum' 20:57:39 <HMage> you can always run g++ again and reroute error output to a file 20:57:41 <KUDr> or uint16 vs. enum 20:57:44 <KUDr> atc 20:57:46 <HMage> "make 2> errors.log" 20:58:19 <KUDr> i am running windows, but i can try it... 20:58:41 <KUDr> but now i am reading g++ docs 20:59:02 <caladan> dont know if windows has error output... 20:59:04 <HMage> I am asking this so I can help you 20:59:10 <caladan> i guess it will be stdout 20:59:14 <HMage> caladan: it has 20:59:20 <KUDr> HMage: ok, i'll try 20:59:23 <caladan> wow, im impressed :D 20:59:27 <HMage> it's pretty much posix there 20:59:34 <Darkvater> damn this diff is big 21:00:27 <HMage> caladan: that's why I like using standard libraries, they're even on windows. 21:00:57 <HMage> they're there* 21:00:58 <caladan> HMage: I didnt know Bill's really conforming to posix... 21:00:58 <Darkvater> it even has /dev/null 21:01:02 <Darkvater> but they call it 'nil' 21:01:08 <HMage> they call it 'nul' :) 21:01:16 <caladan> i've heard that deep in kernel there's even something like /dev/ :D 21:01:27 <Darkvater> HMage: eh yes 21:01:29 <HMage> deep in the kernel there are BSD sources 21:01:50 <HMage> there is BSD source code* 21:02:01 <hylje> yeah, like the whole IP stack 21:02:20 <KUDr> HMage: it generated file with no warnings but warnings were still dumped on console 21:02:31 <stillunknown> HMage: warning: comparison between 'enum<anonymous>' and 'enum<anonymous>' 21:02:36 <stillunknown> stuff like that 21:02:58 <Darkvater> KUDr: try 2> 21:03:13 <caladan> or maybe &> 21:03:20 <glx> caladan: no that fails :) 21:03:31 <Darkvater> I didn't know that you could have multiple enums with the same value in an enum 21:04:43 <KUDr> yes! 21:04:47 <KUDr> HMage: warning: enumeral and non-enumeral type in conditional expression 21:07:42 <KUDr> "The second and third operands have arithmetic or enumeration 21:07:42 <KUDr> type; the usual arithmetic conversions are performed to bring them to a 21:07:42 <KUDr> common type, and the result is of that type." 21:07:53 <KUDr> but it is not taken 21:08:09 <KUDr> shit g++ :) 21:08:48 <HMage> this warning is to prevent programming mistakes, other compilers just don't warn you 21:09:20 <HMage> use -Wno-enum-promotion 21:09:23 <HMage> to disable it 21:09:38 <Darkvater> isn't that just a proposal? 21:09:40 <KUDr> hmm 21:09:56 <Darkvater> from PR7651 on nabble.com? 21:10:24 *** BFM [~chatzilla@CPE-138-130-140-81.nsw.bigpond.net.au] has joined #openttd 21:11:02 <HMage> or just don't use -Wextra :) 21:11:07 <HMage> or -Wall, afair 21:11:26 <HMage> afair you use that* 21:11:56 <KUDr> hmm 21:15:51 <stillunknown> what's wrong with strongly typed enums (using a wrapper class)? 21:16:37 <KUDr> stillunknown: it is complication (wrapper) 21:17:06 <stillunknown> http://en.wikipedia.org/wiki/C++0x#.E2.80.9Cenum_class.E2.80.9D_.28Strongly_Typed_Enums.29 21:17:13 <stillunknown> ever tried something like this? 21:17:28 <Darkvater> whohoo done with diff :) 21:18:19 <KUDr> stillunknown: we use it 21:18:48 <KUDr> stillunknown: TinyEnumT<EnumType> 21:19:11 <stillunknown> i saw that, but it's like declaring it twice 21:19:19 <stillunknown> once an enum and once a wrapper 21:19:26 <stillunknown> iirc 21:20:21 <KUDr> yes, it is easier to work with enums 21:20:29 <KUDr> more convenient 21:20:31 <hylje> wrapper for a wrapper in a printed paper on a wooden table.. 21:20:47 <KUDr> don't forget that most of us are C developers 21:21:10 <KUDr> wrapper for a wrapper? 21:23:05 <stillunknown> KUDr: i'm thinking about a more permanent solution 21:23:18 <KUDr> stillunknown: ahh 21:23:20 <stillunknown> because enums are needed 21:23:30 <stillunknown> but this is not the pretty way 21:23:30 <KUDr> just enum would be ok i guess 21:24:16 <KUDr> 'enum class E: short' 21:24:27 <KUDr> hmm VC8 only? 21:24:59 <stillunknown> what do you mean? 21:25:50 <Darkvater> KUDr: yes it was VC8 yesterday :) 21:26:21 <KUDr> yes, but it is mentioned in http://en.wikipedia.org/wiki/C++0x#.E2.80.9Cenum_class.E2.80.9D_.28Strongly_Typed_Enums.29 21:26:55 <KUDr> so it is not only M$ thing 21:27:11 <Darkvater> probably C05? 21:27:16 <Darkvater> or whatever they're going to call it 21:27:33 <HMage> nevertheless, the range of compilers will be very thin 21:27:42 <Darkvater> don't know why this wasn't in the C++ spec right from the start 21:27:55 <Darkvater> if they get so anal about enums they should've fixed it 21:27:56 <KUDr> true 21:28:11 <KUDr> 'so anal' :) 21:28:13 <HMage> maybe it was too cpu intensive during compiling these days? 21:28:18 <Darkvater> and not require every programmer to go around it a zillion times just to get typesafe code 21:28:25 <Darkvater> HMage: lol 21:29:24 <HMage> but, well, isn't forcing to upgrade to a newest compiler version just because of enums is a little bit, er... anal too? 21:30:55 <Darkvater> I'm just saying they were stupid not to think of this 21:31:08 <Darkvater> when they started screwing around with enums 21:31:11 <HMage> I see 21:31:32 * HMage thinks, what the irony would that be - OpenTTD, a open source clone of a 1995-year game that requires 2005-year compiler 21:31:42 <HMage> an* 21:31:56 * Darkvater doesn't see the irony 21:32:06 <Darkvater> it would be ironic if it would only run on Vista 21:33:47 <HMage> Well, I started to use openttd about a year ago just because it ran on windows and stayed true to original TTD Deluxe, plus it had good tcp/ip client/server network gaming that ttdpatch didn't have back then 21:35:24 <HMage> anyway I'm babbling again, see you later 21:35:44 <Darkvater> hehe 21:35:45 <Darkvater> bye :) 21:36:33 *** HMage is now known as HMage`afk 21:37:05 *** MUcht [~Mucht@p57A0FB5F.dip.t-dialin.net] has joined #openttd 21:41:37 *** Mucht_ [~Mucht@p57A0E364.dip.t-dialin.net] has quit [Read error: Operation timed out] 21:44:26 *** Digitalfox [~digitalfo@bl8-41-217.dsl.telepac.pt] has quit [] 21:45:00 *** Digitalfox [~chatzilla@bl8-41-217.dsl.telepac.pt] has joined #openttd 21:45:06 <CIA-1> Darkvater * r8044 /trunk/src/ (heightmap.cpp newgrf.cpp): Regression (r8038): Crash on allocating bridge memory (peter1138) 21:46:04 *** HMage`afk [~HMage@85.21.179.41] has quit [Read error: Connection reset by peer] 21:49:50 <KUDr> Darkvater: we can also make MallocT to use reference to pointer instead of pointer to pointer. This would eliminate the need of '&' 21:50:06 <KUDr> would it be better? 21:50:37 <Darkvater> I have written up a little text about my questions for C++ 21:50:53 <Darkvater> and one of them included the question/option of not using references 21:51:21 <KUDr> questions to all developers to decide about style? 21:51:44 <Darkvater> imho it is really confusing to see foo(bar) and then have foo change the actual value of bar because it is passed by reference 21:51:48 <Darkvater> very alien to C 21:52:05 <Darkvater> we should/could discuss this tomorrow 21:52:06 <KUDr> true ;) 21:52:08 <caladan> I agree, it hides what really happens... 21:52:30 *** hylje [hylje@194.187.214.214] has quit [Read error: Operation timed out] 21:52:34 <KUDr> this is why i didn't use it (to have it more C like) 21:52:54 <Darkvater> I see all the C++ books writing about how good passing by reference is in that it hides the workings, but I say screw you I want to know and see what happens to my variable 21:53:15 <blathijs> 21:56 * HMage installs MSDN Library April 1999 <-- I have january 2000 lying here, if you want? 21:54:37 *** HMage [~HMage@85.21.179.41] has joined #openttd 21:54:49 <blathijs> 21:56 * HMage installs MSDN Library April 1999 <-- I have january 2000 lying here, if you want? 21:55:45 <HMage> blathijs: hmm 21:56:29 <HMage> blathijs: I want, but how? 21:56:58 <blathijs> Well, I got them by mail from some guy I didn't even know from America 21:57:03 <blathijs> (like, snail mail) 21:57:37 <blathijs> But I think we can think of something more 21-century-ish involving broadband connections 21:57:48 <HMage> bittorrent? 21:58:06 <blathijs> How about FTP? 21:59:12 <HMage> Only if you can set up an ftp server somehwere, because I don't have external IP (I'm behind provider's NAT) 21:59:23 <HMage> somewhere* 22:01:14 <caladan> wha't the size? 22:01:16 *** hylje [hylje@194.187.214.214] has joined #openttd 22:01:20 <caladan> what's* 22:04:08 *** Purno [~Purno@5351CF18.cable.casema.nl] has quit [Quit: Life is a game of pick-up-sticks, played by fucking lunatics.] 22:05:55 <blathijs> caladan: 4 CD's, but I have an FTP server myself. My workstation runs linux and is on a 100Mbit uplink :-) 22:06:07 <caladan> ah, ok :-) 22:06:20 *** Belugas is now known as Belugas_Gone 22:06:22 <caladan> so mine 256kb uplink would be any help anyway... :/ 22:06:34 <caladan> wouldn't* 22:09:13 <blathijs> Nope, but thanks for the offer anyway :-) 22:10:35 *** GoneWacko [~gonewacko@c18041.upc-c.chello.nl] has quit [Ping timeout: 480 seconds] 22:14:28 <blathijs> oeh, nice 22:14:37 <blathijs> I have tab completion for ./configure arguments 22:14:52 <blathijs> it seems bash executes ./configure --help to look them up or something :-S 22:14:58 *** pecisk [~pecisk@purvc-44-54.maksinets.lv] has quit [Quit: J?iet prom] 22:16:32 <Darkvater> bash_complete? 22:16:40 <Darkvater> yeah 22:16:46 <Darkvater> it also works for some makefiles 22:17:50 <blathijs> dunno, I uncommented something from a default debian install :-) 22:18:05 <blathijs> difference that makefiles can be guessed by _parsing_ them 22:18:17 <blathijs> I think it guessed configure's arguments by _running_ it 22:18:30 <qball> yeah bash/dash does that (and most shells) 22:18:55 <caladan> did anyone used fltk? 22:19:06 <caladan> *use 22:19:24 <blathijs> fltk? 22:19:27 <blathijs> (that's a no) 22:19:32 <caladan> rgr :D 22:19:37 *** PandaMojo__ [~chatzilla@ip72-197-231-130.sd.sd.cox.net] has joined #openttd 22:19:50 *** GoneWacko [~gonewacko@c18041.upc-c.chello.nl] has joined #openttd 22:22:52 <Biff> blathijs: i dunno how it works with configure, but bash autocompletion is quite coo 22:22:56 <Biff> cool 22:23:00 <Biff> try scp 22:23:07 <Biff> you can tab files on the remote host 22:23:17 <caladan> :> 22:23:21 <Biff> provided you dont need password 22:23:42 *** MeusH [~MeusH@host-ip18-138.crowley.pl] has quit [Read error: Connection reset by peer] 22:24:17 *** PandaMojo [~chatzilla@ip72-197-231-130.sd.sd.cox.net] has quit [Ping timeout: 480 seconds] 22:24:30 <blathijs> Biff: Yes, that's even more scary 22:24:30 *** PandaMojo__ is now known as PandaMojo 22:24:48 <blathijs> Biff: I tried that some years back, to a host that was standing behind 22:24:50 <blathijs> It didn 22:25:11 <Biff> dunno if it worked years ago, it works now 22:25:23 <blathijs> It didn't hit me what it was doing exactly until I realized that every press of "tab" would rattle the hard drive in the machine _behind_ me 22:25:39 <Biff> ah 22:25:41 <Biff> hehe 22:26:41 <Biff> ooh, someone fixed the tab thingy 22:28:07 <Biff> no wait 22:28:31 <Darkvater> ugh 22:28:40 <Darkvater> apply patches from before cpp is a bitch 22:28:52 <Biff> why? 22:28:52 <Darkvater> tortoisesvn even flat-out refuses this 22:29:08 <Biff> cant you just rename from c to cpp in the patch-file? 22:29:17 <Darkvater> Unknown file type on line X 22:29:19 <Darkvater> *crash* 22:29:31 *** Progman [~progman@p57A1E1C1.dip.t-dialin.net] has joined #openttd 22:29:46 <Darkvater> so I used gnu patch which had some failed hunks due to cpp magic :) 22:30:14 <Rubidium_> Darkvater: apply to the revision between the big rename and the cpp merge, then update :) 22:30:34 <Darkvater> it didn't like the rename either 22:30:40 <Darkvater> well gnu-patch did 22:30:50 <Darkvater> but tortoisemerge is just dumb 22:31:23 <Darkvater> I think I can forget automatic backporting to 0.5 since the source-file renames 22:31:51 <Rubidium_> yes 22:31:52 <Biff> oh, tortoise is eclipse? 22:32:01 <Biff> i thought it was a standalone program 22:32:04 <Rubidium_> unless it's only one file, then you can backport it by giving the full path 22:32:16 <Darkvater> Biff: eclip-what? 22:32:32 <Darkvater> Rubidium_: yeah; and how often is that? ;) 22:32:33 <Biff> oh never mind 22:32:36 * Darkvater hates eclipse 22:33:06 <Biff> i like it for java 22:33:15 <Darkvater> I hate it for everything 22:33:28 <Biff> everything else vim 22:33:29 <Biff> :P 22:33:32 <HMage> maybe bash doesn't parse or execute configure at all, some of the parameters are typical for configure (like bindir) 22:33:45 <Darkvater> Rubidium_: what did you tell Brianetta last time to how to make a core dump from gdb? 22:33:52 <Rubidium_> hmm... the masterserver_update suffers from merging the cpp branch 22:34:01 <Biff> and since /etc/bash_completion is closed source, we can never find out how it works 22:34:03 <Rubidium_> pff... hmm, lets get the logs for that :) 22:34:16 <Darkvater> I couldn't find it in th elogs 22:36:14 <Biff> only bad thing about bash_completion is that its real slow 22:36:29 <Rubidium_> ok, here it is: generate_core_file 22:37:09 <Darkvater> he 22:37:15 <Darkvater> no wonder I couldn't find it; you said it in PM 22:37:33 <Rubidium_> I didn't 22:37:44 <Darkvater> it's not in my #openttd.log file 22:37:56 <Darkvater> [tfarago@tin 23:36 ~] > grep -ni "generate_core" irclogs/#openttd.log 22:37:57 <Darkvater> 442854:23:36 < Rubidium_> ok, here it is: generate_core_file 22:38:07 <Rubidium_> oh, it is, generate-core-file :) 22:38:33 <CIA-1> maedhros * r8045 /branches/newhouses/ (65 files in 9 dirs): [NewHouses] -Sync with trunk r7961:8030 22:38:41 <Darkvater> better ;0 22:38:56 <Maedhros> now's the part i ask for help :) 22:39:29 <Darkvater> hehe 22:43:38 *** Rens2Sea [~Rens2Sea@213.211.185.168] has quit [] 22:45:03 *** PandaMojo__ [~chatzilla@ip72-197-231-130.sd.sd.cox.net] has joined #openttd 22:51:17 *** PandaMojo [~chatzilla@ip72-197-231-130.sd.sd.cox.net] has quit [Ping timeout: 480 seconds] 22:53:10 <Wolf01> 'night all 22:53:24 *** Wolf01 [~wolf01@82.56.161.138] has quit [] 23:11:58 *** Vikthor [~Vikthor@snat2.arachne.cz] has quit [Quit: Leaving.] 23:18:49 *** Progman [~progman@p57A1E1C1.dip.t-dialin.net] has quit [Remote host closed the connection] 23:19:45 *** caladan [~caladan@161-be2-6.acn.waw.pl] has quit [Quit: leaving] 23:26:12 <Maedhros> wtf?! http://www.tt-forums.net/viewtopic.php?p=540543#540543 23:27:07 *** Bjarni [~Bjarni@0x50a46ac4.virnxx14.adsl-dhcp.tele.dk] has joined #openttd 23:27:11 *** mode/#openttd [+o Bjarni] by ChanServ 23:30:35 <Darkvater> hi Bjarni 23:32:48 <Maedhros> g'night everyone 23:32:52 <Darkvater> gn 23:33:20 *** Nobody_from_Nowhere [~Nobody@d463cb71.datahighways.de] has joined #openttd 23:36:18 <Bjarni> hi Darkvater 23:36:57 <Bjarni> anything interesting happening? 23:37:02 <Darkvater> cpp got merged 23:37:26 <Bjarni> :D 23:37:29 <Bjarni> I hope 23:38:21 <Bjarni> we should reconfigure the svn mail thing to tell about major commits, but leave out the diff 23:38:40 <Bjarni> so people will know stuff like merging branches and so on 23:39:02 <Bjarni> right now the mails get too big and are not sent at all 23:39:06 <Darkvater> hehe TL is pretty allergic to mailman :) 23:39:48 <Bjarni> so that's why you hid the merge from me? 23:40:06 <Darkvater> I ain't hid no thing 23:42:17 *** KritiK [Maxim@ppp85-141-224-92.pppoe.mtu-net.ru] has quit [Quit: Leaving] 23:44:51 <CIA-1> glx * r8046 /branches/newhouses/ (404 files in 18 dirs): [newhouses] -Sync with trunk r8030:r8044 (doesn't link) 23:56:48 <Smoovious> hmm... I can't stay connected to a server now... just made some ships... 23:57:11 <Smoovious> and don't think it is just me, cuz I can't stay connected as an observer either 23:57:23 <Darkvater> desync? 23:57:47 <Darkvater> which server? 23:58:04 <Smoovious> !! #RC3# Connum's Testserver 23:58:09 <Darkvater> ip? 23:58:24 <Digitalfox> So what's the overal opinion about the merge of branch cpp?? Did it work out well in end or still some problems about c++ language? 23:58:28 <Smoovious> don't think it was a desync, like before... but that my end is hanging so long trying to do something, that I keep timing out 23:58:54 <Smoovious> IP 84.163.112.63:3979 23:58:55 <CIA-1> rubidium * r8047 /trunk/Makefile.lang.in: -Revert (8002): cp -u is not supported on all platforms. 23:59:32 <Darkvater> I'm in 23:59:53 <Smoovious> I get one step of animation, then it just hangs for a bit