Times are UTC Toggle Colours
00:18:05 *** nekx [~asd@x1-6-00-18-39-d3-e9-f6.k899.webspeed.dk] has joined #openttd 00:18:06 *** nkx [~asd@x1-6-00-18-39-d3-e9-f6.k899.webspeed.dk] has quit [Read error: Connection reset by peer] 00:25:05 *** KritiK [~Maxim@78-106-156-221.broadband.corbina.ru] has quit [Quit: Leaving] 00:32:36 *** Zahl [~Zahl@g226207107.adsl.alicedsl.de] has quit [Read error: Connection reset by peer] 00:32:44 *** Zahl [~Zahl@g226207107.adsl.alicedsl.de] has joined #openttd 00:36:25 *** Eddi|zuHause [~johekr@p54B77876.dip.t-dialin.net] has quit [] 00:36:46 *** Eddi|zuHause [~johekr@p54B77D53.dip.t-dialin.net] has joined #openttd 00:37:03 *** nekx [~asd@x1-6-00-18-39-d3-e9-f6.k899.webspeed.dk] has quit [Read error: Connection reset by peer] 00:37:16 *** nekx [~asd@x1-6-00-18-39-d3-e9-f6.k899.webspeed.dk] has joined #openttd 00:39:17 *** Wezz6400 [~Wezz6400@ndb.demon.nl] has quit [Quit: Zzz] 00:43:43 *** nkx [~asd@x1-6-00-18-39-d3-e9-f6.k899.webspeed.dk] has joined #openttd 00:43:44 *** nekx [~asd@x1-6-00-18-39-d3-e9-f6.k899.webspeed.dk] has quit [Read error: Connection reset by peer] 00:44:49 *** Chrill [~chrischri@c80-216-64-31.bredband.comhem.se] has joined #openttd 00:55:59 *** ben_goodger [~ben@host81-153-29-228.range81-153.btcentralplus.com] has quit [Ping timeout: 480 seconds] 00:56:29 *** ben_goodger [~ben@host81-153-29-228.range81-153.btcentralplus.com] has joined #openttd 01:02:06 *** Chrill [~chrischri@c80-216-64-31.bredband.comhem.se] has quit [Quit: Oh chrill is one sexy beast] 01:09:26 *** nicfer [~Administr@168.226.104.186] has joined #openttd 01:09:56 <nicfer> any hints on how to make openttd more addictive? 01:12:19 <SmatZ> it can be more addictive_ 01:12:20 <SmatZ> ? 01:14:06 *** Dred_furst` [~Dred_furs@user-5440e40a.wfd80a.dsl.pol.co.uk] has quit [Read error: Connection reset by peer] 01:15:05 <nicfer> I mean, I lose my interest after some minutes 01:16:19 <Yexo> start playing with paxdest 01:18:31 *** nekx [~asd@x1-6-00-18-39-d3-e9-f6.k899.webspeed.dk] has joined #openttd 01:18:31 *** nkx [~asd@x1-6-00-18-39-d3-e9-f6.k899.webspeed.dk] has quit [Read error: Connection reset by peer] 01:39:34 *** ecke [~ecke@213.195.202.130] has quit [Read error: Connection reset by peer] 02:16:00 *** ecke [~ecke@213.195.202.130] has joined #openttd 02:21:28 *** nekx [~asd@x1-6-00-18-39-d3-e9-f6.k899.webspeed.dk] has quit [Read error: Connection reset by peer] 02:21:38 *** nekx [~asd@x1-6-00-18-39-d3-e9-f6.k899.webspeed.dk] has joined #openttd 02:24:51 *** Zahl [~Zahl@g226207107.adsl.alicedsl.de] has quit [Ping timeout: 480 seconds] 02:39:15 *** Progman [~progman@p57A1D6AF.dip.t-dialin.net] has quit [Remote host closed the connection] 02:58:31 *** glx [glx@bny93-6-82-245-156-124.fbx.proxad.net] has quit [Quit: bye] 03:02:44 *** elmex_ [~elmex@e180064253.adsl.alicedsl.de] has joined #openttd 03:07:42 *** elmex [~elmex@e180067181.adsl.alicedsl.de] has quit [Ping timeout: 480 seconds] 03:08:11 *** elmex_ is now known as elmex 03:25:04 *** nicfer [~Administr@168.226.104.186] has left #openttd [] 03:27:53 *** welshdragon is now known as welshdra-gone 03:38:27 *** nkx [~asd@x1-6-00-18-39-d3-e9-f6.k899.webspeed.dk] has joined #openttd 03:38:28 *** nekx [~asd@x1-6-00-18-39-d3-e9-f6.k899.webspeed.dk] has quit [Read error: Connection reset by peer] 04:01:34 <CIA-5> OpenTTD: belugas * r14003 /trunk/src/ (cheat_gui.cpp industry_gui.cpp): -Codechange: Replace numbers with Colours enum opn some DrawArrowButtons calls 04:25:24 *** Gekz [~brendan@123-243-206-102.static.tpgi.com.au] has quit [Ping timeout: 480 seconds] 04:35:17 *** nekx [~asd@x1-6-00-18-39-d3-e9-f6.k899.webspeed.dk] has joined #openttd 04:35:17 *** nkx [~asd@x1-6-00-18-39-d3-e9-f6.k899.webspeed.dk] has quit [Read error: Connection reset by peer] 04:53:42 *** Gekz [~brendan@123-243-206-102.static.tpgi.com.au] has joined #openttd 04:54:12 *** Reemo [Dr_Jekyll@p57B0D8A6.dip.t-dialin.net] has quit [Quit: http://www.lagerwiki.de - das Wiki rund um's Thema Lager und Logistik] 04:54:13 *** nekx [~asd@x1-6-00-18-39-d3-e9-f6.k899.webspeed.dk] has quit [Read error: Connection reset by peer] 04:54:17 *** nekx [~asd@x1-6-00-18-39-d3-e9-f6.k899.webspeed.dk] has joined #openttd 05:07:46 *** Eddi|zuHause [~johekr@p54B77D53.dip.t-dialin.net] has quit [Remote host closed the connection] 05:08:00 *** Eddi|zuHause [~johekr@p54B77D53.dip.t-dialin.net] has joined #openttd 05:13:21 *** nkx [~asd@x1-6-00-18-39-d3-e9-f6.k899.webspeed.dk] has joined #openttd 05:13:21 *** nekx [~asd@x1-6-00-18-39-d3-e9-f6.k899.webspeed.dk] has quit [Read error: Connection reset by peer] 05:25:48 *** ecke [~ecke@213.195.202.130] has quit [Read error: Connection reset by peer] 05:29:18 *** nC[dek] [ng0L@203.176.141.173] has joined #openttd 05:37:39 *** nekx [~asd@x1-6-00-18-39-d3-e9-f6.k899.webspeed.dk] has joined #openttd 05:37:39 *** nkx [~asd@x1-6-00-18-39-d3-e9-f6.k899.webspeed.dk] has quit [Read error: Connection reset by peer] 05:43:21 *** ecke [~ecke@213.195.202.130] has joined #openttd 06:00:14 *** bleepy [TheForce@5ad00eba.bb.sky.com] has joined #openttd 06:09:29 *** ecke [~ecke@213.195.202.130] has quit [Ping timeout: 480 seconds] 06:09:49 <Celestar> morning 06:10:08 <peter1138> Hi 06:10:12 <nC[dek]> hi 06:10:26 <nC[dek]> is it for developer to translate any game server? 06:10:39 <Celestar> peter1138: up already? (= 06:10:44 <Celestar> nC[dek]: ?? 06:10:54 <nC[dek]> just ask 06:12:00 <Fennec> Your question is not clear to us. 06:12:26 <Fennec> Are you inquiring whether it is possible for a developer to translate a portion of the application? 06:12:51 <Celestar> nC[dek]: ERROR: cannot parse question 06:13:07 <nC[dek]> i was wonder if are you guys working on translation such as game server? 06:13:18 <Fennec> ah. :) 06:13:27 <nC[dek]> (Translator: translator2, Gameservers: servers, 06:14:34 <Celestar> Mihamix did the webtranslator 06:16:23 <nC[dek]> i see 06:18:06 <peter1138> I still don't understand the question, heh 06:21:53 <nC[dek]> peter1138: forget it :P 06:24:04 <Celestar> bah 06:26:46 <Celestar> aha 06:26:55 <Celestar> LoadUnloadVehicle is the actual loading process 06:27:09 <Celestar> VehiclePayment only determines the payment, but doesn't actually move the cargo 06:27:19 <peter1138> yes 06:27:35 <peter1138> They have to 'match' though :o 06:27:37 * Celestar goes cleaning up VehiclePayment 06:27:47 <Celestar> yes, they don't currently this is what I'm fixing now 06:28:14 *** Sir-Bob [~chatzilla@c122-107-227-146.eburwd5.vic.optusnet.com.au] has joined #openttd 06:32:09 *** Sir-Bob [~chatzilla@c122-107-227-146.eburwd5.vic.optusnet.com.au] has quit [] 06:35:50 <Celestar> hence we have disagreement in the payments from what I can tell 06:40:06 <peter1138> Hmm 06:40:15 <peter1138> What's the best way to clean up Window "delete this" mess? 06:46:46 <Celestar> dunno 06:46:55 <Celestar> does it have anything to do with cargodest (= 06:48:04 *** ecke [~ecke@213.195.202.130] has joined #openttd 06:50:34 <peter1138> Nope. 06:51:04 *** nC[dek] [ng0L@203.176.141.173] has quit [] 06:52:37 *** Wolf01 [~wolf01@host90-235-dynamic.2-87-r.retail.telecomitalia.it] has joined #openttd 06:53:02 <Wolf01> hello 07:02:49 *** nkx [~asd@x1-6-00-18-39-d3-e9-f6.k899.webspeed.dk] has joined #openttd 07:02:50 *** nekx [~asd@x1-6-00-18-39-d3-e9-f6.k899.webspeed.dk] has quit [Read error: Connection reset by peer] 07:07:21 <Celestar> peter1138: doing some progress with the cleanup 07:10:54 <CIA-5> OpenTTD: peter1138 * r14004 /trunk/src/ (player_gui.cpp widgets/dropdown.cpp widgets/dropdown_type.h): 07:10:54 <CIA-5> OpenTTD: -Codechange: Clean of drop down lists. 07:10:54 <CIA-5> OpenTTD: Move empty item drawing to base ListItem Draw() function. 07:10:54 <CIA-5> OpenTTD: Remove String() from base class. 07:10:54 <CIA-5> OpenTTD: Pass correct width to Draw(). 07:10:57 *** Wolf01 [~wolf01@host90-235-dynamic.2-87-r.retail.telecomitalia.it] has quit [Ping timeout: 480 seconds] 07:12:27 *** Wolf01 [~wolf01@host83-234-dynamic.14-87-r.retail.telecomitalia.it] has joined #openttd 07:22:58 *** Marduuhin [~mardo4@84.86.191.90.dyn.estpak.ee] has quit [Ping timeout: 480 seconds] 07:23:50 *** Marduuhin [~mardo4@84.86.191.90.dyn.estpak.ee] has joined #openttd 07:28:53 *** Farden [~jk3farden@ram94-7-82-232-189-236.fbx.proxad.net] has joined #openttd 07:32:18 *** KillaloT [~killalot@0x5738cc9a.rdnqu1.dynamic.dsl.tele.dk] has joined #openttd 07:33:54 <Celestar> sometimes I don't get this debugger and/or compiler 07:36:26 <TinoDidriksen> Which? 07:36:53 <Celestar> gcc/gdb 07:36:56 <Celestar> :P 07:40:13 *** TinoM [~Tino@i59F56D13.versanet.de] has joined #openttd 07:45:29 *** Wolf01 [~wolf01@host83-234-dynamic.14-87-r.retail.telecomitalia.it] has quit [Ping timeout: 480 seconds] 08:11:43 *** Zr40 [~zr40@120-12-ftth.onsnetstudenten.nl] has joined #openttd 08:18:13 <peter1138> Celestar, nearly done the sorting. Just need to add the GUI elements. 08:19:50 <peter1138> Although I've got work @ work to do... 08:20:36 *** bleepy [TheForce@5ad00eba.bb.sky.com] has quit [Ping timeout: 480 seconds] 08:20:50 *** Sir-Bob [~chatzilla@c122-107-227-146.eburwd5.vic.optusnet.com.au] has joined #openttd 08:21:03 *** Digitalfox [~Digitalfo@bl10-221-158.dsl.telepac.pt] has quit [Quit: Leaving] 08:21:29 <Celestar> peter1138: awesome 08:21:39 <Celestar> peter1138: I got work too, I'm done with the payment repair 08:21:58 <Celestar> peter1138: pull and see if economy.cpp:VehiclePayment is more readable now (= 08:24:29 <peter1138> I'll check the repo. 08:24:40 <peter1138> Cannot pull as I've not committed my GUI changes yet. 08:25:18 <Celestar> I see 08:26:55 <peter1138> Heh, acceptance changes invalidates the cache multiple times. I guess that will necessary when it is more specific. 08:27:06 <peter1138> Now checking the appropriate change ;) 08:28:16 <peter1138> payed -> paid ;) 08:28:28 <peter1138> That looks better. 08:29:25 *** lobster_MB [~michielbr@5350C1D1.cable.casema.nl] has quit [Ping timeout: 480 seconds] 08:31:24 <Celestar> good 08:31:35 <Celestar> I don't like some of the if-magic we have in the code 08:33:57 <peter1138> Which if-magic? 08:34:43 *** Vikthor [~Vikthor@snat1.spoje.net] has joined #openttd 08:34:51 *** lobster_MB [~michielbr@5350C1D1.cable.casema.nl] has joined #openttd 08:38:35 <Celestar> like the one I have replaced (= 08:40:47 *** Brianetta [~brian@client-86-27-108-163.brnt.adsl.virgin.net] has joined #openttd 08:42:28 <peter1138> if (!cp->paid_for && 08:42:28 <peter1138> - cp->source != last_visited && 08:42:28 <peter1138> - (cp->target == st->index || cp->target == INVALID_STATION) && 08:42:28 <peter1138> - HasBit(ge->acceptance_pickup, GoodsEntry::ACCEPTANCE) && 08:42:31 <peter1138> - ((front_v->current_order.GetUnloadType() & OUFB_TRANSFER) == 0 ) 08:42:34 <peter1138> Like that one you mean? :) 08:42:45 <peter1138> It is quite horrible. 08:42:50 <Celestar> yes 08:44:37 <peter1138> What should we do with the small map view, regarding showing transport types? 08:45:26 <peter1138> We kind of want both cargo type and vehicle type toggles, but that'll complicate it a lot. 08:46:07 <Brianetta> Use the colours from the payment graph map, and make the routes and stations in that colour 08:46:14 <Brianetta> If there's more than one, borrow from Harry Beck 08:46:36 <Celestar> Harry Beck? 08:46:43 <Brianetta> http://en.wikipedia.org/wiki/Harry_Beck_(graphic_designer) 08:49:17 <Eddi|zuHause> simply add two buttons to the lower right, one that shows the network regarding to cargo, and one that shows the network regarding to transport type... 08:49:29 <peter1138> That's one possibility too... 08:50:15 <Celestar> that's a good one, so we won't have any empty button 08:53:20 <Eddi|zuHause> only problem is that you might want to filter for both, e.g. show the transport type of the passenger network only.. 08:56:11 <Celestar> hm 08:56:12 <Celestar> true 08:56:21 <Celestar> peter1138'll find a solution, I'm optimistic 08:57:12 <Celestar> we're mostly done with the TODO list if the GUI comes. Most important aspect then is the biasing of the PRNG on station size 08:57:23 <Celestar> and nettesting 09:01:33 <Celestar> and some "todo" and "XXX" in the code 09:03:38 *** ecke1 [~ecke@213.195.202.130] has joined #openttd 09:03:39 *** ecke [~ecke@213.195.202.130] has quit [Read error: Connection reset by peer] 09:05:33 <Celestar> and then we might be good to go :D 09:07:55 *** Sir-Bob [~chatzilla@c122-107-227-146.eburwd5.vic.optusnet.com.au] has quit [Quit: ChatZilla 0.9.83 [Firefox 3.0.1/2008070208]] 09:11:32 *** Doorslammer [Doorslamme@PIPP-p-203-54-115-243.prem.tmns.net.au] has joined #openttd 09:13:26 *** Sir-Bob [~chatzilla@c122-107-227-146.eburwd5.vic.optusnet.com.au] has joined #openttd 09:16:24 *** fonso [~fonso@brln-d9bacd6d.pool.mediaWays.net] has joined #openttd 09:16:53 <Forked> good morning 09:18:06 <Doorslammer> ;) 09:18:12 <fonso> moi 09:18:32 <Celestar> peter1138: when the acceptance changes, shall we deliver anyway (I mean all enroute packets), shall we generate new destinations, or shall we deliver to origin? 09:18:35 *** bleepy [bleepy@5ad51a5d.bb.sky.com] has joined #openttd 09:19:06 *** grumbel [~grumbel@i577AE64A.versanet.de] has joined #openttd 09:20:15 <Celestar> currently, all the en-route packets are still delivered, but no new packets generated 09:20:32 <Celestar> (which isn't too stupid anyway imho. I mean the people already bought their tickets) 09:20:46 <Celestar> but then again, the power station you're delivering to is no longer there. 09:21:11 <Celestar> we can also just discard the packets 09:23:13 <Celestar> or deliver and get no payment 09:23:14 <Celestar> (= 09:24:39 <Noldo> generationg new target seems best IMO 09:26:20 *** grumbel [~grumbel@i577AE64A.versanet.de] has quit [Quit: Client exiting] 09:26:30 <peter1138> Make it a patch option for each cargo type! 09:26:38 <peter1138> You can never have enough options ;) 09:26:43 <peter1138> (Okay, maybe not :P) 09:27:53 <Ammler> what would you do with the packets, if you remove the destination station? 09:28:02 <Ammler> you could handle it like that 09:28:43 <peter1138> Isn't that exactly what was just mentioned? 09:29:04 <peter1138> Removing a station means its acceptance changes ;) 09:29:41 <Ammler> well, if acceptance changes, you could still deliver it, but not, if the station disabpeard 09:29:41 <Celestar> hm .. Ammler is raising a valid question 09:29:55 <Celestar> because now, the cargopackets are just moved around forever 09:29:59 <Celestar> well, actually not 09:30:10 <Celestar> they're dumped at one station until they expire 09:30:20 <Celestar> because UseVehicle will never return true 09:30:58 <Celestar> which is pretty elegant (= 09:31:17 <Celestar> because if the station becomes valid again, they're boarded again 09:31:57 <Ammler> but that has a timeout? 09:31:58 <peter1138> That's undesirable. 09:32:09 <peter1138> The new station could belong to another player. 09:33:27 <Celestar> peter1138: than they're not boarded (= 09:33:29 <Celestar> then* 09:33:53 <Celestar> I'm not sure whether the packet will expire at some station with a very right rating 09:33:55 <blathijs> Can you actually take over a station from another player? 09:33:56 <Celestar> high rating 09:34:00 <Celestar> blathijs: no, not really 09:34:18 <Celestar> but you can take over a station index from another player 09:34:34 <Eddi|zuHause> i'd say select new destination 09:34:40 <peter1138> blathijs, reusing a station id, that's all. 09:35:06 <Celestar> peter1138: which is no problem, in that case the orders to that station will have been removed 09:35:14 <peter1138> What about things like ECS/PBI where acceptance can change a lot... 09:35:41 <Celestar> I'd almost say discard 09:35:58 <Eddi|zuHause> discard is a bad idea, imho 09:36:43 <Celestar> think about it: You buy a train ticket to Backwater Boonies. Company tells you that they cannot bring you to Backwater Boonies, what do you do? "Oh no problem, I'll go Tokyo instead" 09:36:56 <Ammler> sometimes, I built "excess"-transport from those lines, which tansport the cargo to an other station (coal from steel mill to power supply) 09:37:01 <Celestar> we *could* find a nearby station 09:37:17 <blathijs> I think realism is hardly relevant in this situation 09:37:25 <Eddi|zuHause> for certain definitions of "nearby" ;) 09:37:37 <Celestar> blathijs: so what's wrong about delivering the packets anyway? 09:38:03 <blathijs> Celestar: But to a different "nearby" station you mean? 09:38:18 <Eddi|zuHause> no, really, if company A gets 500t of coal delivered, and company A gets bankrupt, the coal does not just get thrown away 09:38:32 <fonso> Would anyone like to discuss diagonal levelling (http://www.tt-forums.net/viewtopic.php?f=33&t=38148) or station capacities (http://www.tt-forums.net/viewtopic.php?f=33&t=38712)? 09:38:44 <Celestar> hey fonso 09:38:48 <fonso> hi 09:38:54 <Celestar> I like diagonal levelling 09:39:07 <fonso> Did you try it? 09:39:11 <Eddi|zuHause> this "deliver anyway" would kinda get in the way with that stockpiling idea of PBI/ECS 09:39:14 <Celestar> someone beside me should review the code. 09:39:38 <fonso> Well ... who? 09:39:39 <Eddi|zuHause> because they are meant so that you can't just deliver everything there 09:39:54 <Celestar> Eddi|zuHause: ok if the acceptance changes, we'd need to loop through every damn cargopacket on the map. That means all vehicles and all stations 09:40:09 <blathijs> What is this PBI/ECS thing? 09:40:14 <Eddi|zuHause> Celestar: no, only when the cargopacket is actually touced 09:40:19 <Eddi|zuHause> +h 09:40:29 <Celestar> Eddi|zuHause: new packets are not generated if the acceptance goes off 09:40:34 <Ammler> Eddi|zuHause: they will fill the stockpile at the station then 09:40:52 <Eddi|zuHause> i.e. when it wants to decide that it gets loaded/unloaded, and finds that the desired target is not available anymore 09:41:04 <Celestar> Ammler: nope, currently they're discarded at the final station 09:41:14 <Ammler> (and need to wait until industry accept again or for transport ot an other industry) 09:41:24 <Eddi|zuHause> blathijs: newgrf industries 09:42:02 <Eddi|zuHause> http://users.tt-forums.net/pikka/wiki/index.php/Pikka's_Basic_Industries 09:42:09 <Ammler> Celestar: if you set "unload"? 09:42:55 <Ammler> or shouldn't that be used with cargo dest anymore? 09:43:41 <Celestar> Ammler: it can. 09:44:01 <Celestar> Ammler: but it just forces the vehicle to dump all cargo to the station, even if it would be better to remain onboard 09:44:15 <Celestar> Ammler: if the cargo is destined for the station, it is delivered anyway 09:44:54 <Ammler> but you say, they are discarded currenty, :-/ 09:45:11 <Eddi|zuHause> Ammler: when the acceptance changes, the stockpile is already full, so all subsequent cargo needs rerouting, until the stockpile reduces 09:45:15 <Celestar> well, cargopackets are ALWAYS discarded at their final destinations 09:45:21 <Celestar> delete cp; :) 09:45:54 *** Progman [~progman@p57A1E2BF.dip.t-dialin.net] has joined #openttd 09:46:01 <Celestar> without routing they're discarded as soon as they are unloaded at an accepting stations and the vehicle has the Transfer flag unset 09:46:11 <Ammler> Eddi|zuHause: stockpile of the station... 09:47:57 *** Singaporekid [~notme@cm53.epsilon123.maxonline.com.sg] has joined #openttd 09:48:07 <Ammler> inustry a buys you to transport cargo from a to b, in the meantime b doesn't need it anymore, you would unload it there anyway, wouldn't? 09:48:30 <peter1138> wouldn't *you* ;p 09:49:11 <peter1138> So unload anyway... 09:49:12 <Ammler> but you might not get paid for it :-) 09:49:21 <peter1138> And the only make new destinations if the station is removed? 09:49:24 <peter1138> +n 09:49:26 <Celestar> we just need a decision 09:49:41 <Celestar> what to do if 1) station doesn't accept cargo, and 2) station goes out-of-scope 09:50:15 <peter1138> Hmm, depends on why it has stopped accepting :o 09:50:51 <peter1138> Maybe we should make it a (single) configuration option after all... 09:51:09 <peter1138> a) pick new destination b) deliver anyway c) crash and burn 09:51:45 <Ammler> can you detect, if the industry still is there? 09:52:30 <fonso> I see you're all pretty busy with cargo destinations and I appreciate that. However I'd really like some feedback on the above mentioned patches (http://www.tt-forums.net/viewtopic.php?f=33&t=38712 and http://www.tt-forums.net/viewtopic.php?f=33&t=38148). If you find the time and are interested, please review the code and/or functionality and post a comment in the respective threads. I know that station capacities interfer with cargo destina 09:52:30 <fonso> n cargo destinations are finished. I'm more interested in the interaction with the newgrf system there. 09:52:35 <Ammler> so you could see, if it is because of stockpile limits or if the industry disapeard) 09:56:40 <Celestar> fonso: I think Rubidium peter1138 and Belugas are your best candidates 09:57:11 <Celestar> fonso: however, you might put the station capacity on hold for a bit. It might be much easier and cleaner to implement with cargo destinations 09:57:30 <Celestar> Ammler: this should be done by different flags in the GoodsEntry 09:59:12 <fonso> Rubidium, peter1138 and Belugas, I'm looking at you ;). And station capacities is on hold. I'd like to discuss the desired functionality there, not the details. 10:01:07 <Celestar> awar for an hour (= 10:01:09 <Celestar> away 10:01:12 <Celestar> cu later 10:02:59 *** grumbel [~grumbel@i577AE64A.versanet.de] has joined #openttd 10:03:38 <peter1138> fonso, per cargo type? 10:03:51 <fonso> that's one of the questions 10:03:59 <fonso> I could do both 10:04:22 <fonso> either define everything by cargo type or define only one limit for all cargo 10:04:49 <peter1138> Is it for pickup or dropoff? 10:05:00 <fonso> Both 10:05:08 <fonso> ah no 10:05:12 <fonso> I misunderstood 10:05:39 <fonso> you can drop off cargo if the station is full, if the cargo is consumed immediately 10:05:49 <fonso> but you can't transfer anything then 10:06:05 <fonso> or "store" at the station 10:06:47 *** Roujin [~Roujin@mnch-5d85e906.pool.einsundeins.de] has joined #openttd 10:06:55 <fonso> the main function however is limiting cargo delivered to the station by industries and houses 10:07:36 <peter1138> Hm 10:07:42 <peter1138> So it's for pickup. 10:08:38 <peter1138> Limiting... 10:10:20 <fonso> I don't know if you got that right. A vehicle can still pick up goods at the station at the same rate as without station capacities. But the amount of goods stored at the station at any time is limited 10:10:55 <peter1138> Ah ha 10:11:01 <peter1138> See, we used to have the 4096 limit :D 10:11:28 <peter1138> But basically you want a larger station to have a larger limit. 10:12:31 <fonso> So if you got a bus stop with a capacity of 10 people and one bus is loading while another is unloading they transfer at roughly the same rate as before even if their capacity is larger than 10: 10 people get off bus1, station is full, 10 people get on bus 10, station is empty, 10 people get off bus1 and so on. 10:12:38 <fonso> And yes, the limit is per tile. 10:15:17 *** Wolf01 [~wolf01@host98-181-dynamic.15-87-r.retail.telecomitalia.it] has joined #openttd 10:15:28 <fonso> "bus 10" is obviously bus2 in decimal 10:15:33 <fonso> ;) 10:16:15 <Wolf01> hello again... maybe now I'm here to stay 10:17:46 *** ben_goodger [~ben@host81-153-29-228.range81-153.btcentralplus.com] has quit [Ping timeout: 480 seconds] 10:18:57 *** ben_goodger [~ben@host81-153-29-228.range81-153.btcentralplus.com] has joined #openttd 10:29:45 <peter1138> Gah... 10:29:47 <Forked> urgh, is there any way to clear a reservation on a station track, without removing that piece of station? 10:30:42 <Phantasm> Anyone have multiple CPUs and Windows? (Multiple cores alone does not count!) 10:31:02 <Forked> just two cores :\ 10:33:15 <Forked> hm, funky.. when removing a station track using the drag&drop feature, and that station having roof above it .. the roof get's cut right above the track next to it that it was sharing it with (did that make any sense?) 10:33:50 <Eddi|zuHause> Forked: i'm afraid there is not 10:34:02 *** Singaporekid [~notme@cm53.epsilon123.maxonline.com.sg] has quit [Quit: Leaving] 10:35:40 *** Wezz6400 [~Wezz6400@ndb.demon.nl] has joined #openttd 10:37:48 *** Tommy [~tommy@de2-as11411.alshamil.net.ae] has joined #openttd 10:41:06 *** Tommy [~tommy@de2-as11411.alshamil.net.ae] has left #openttd [] 10:43:07 <Bjarni> <Phantasm> Anyone have multiple CPUs and Windows? (Multiple cores alone does not count!) <-- now what kind of question is that? 10:43:15 <Bjarni> I mean why would you care? :) 10:43:25 <Bjarni> (besides nobody replied) 10:44:10 * Rubidium got multiple CPUs and Windows 10:44:24 <Phantasm> Bjarni: There is one program (detecting physical core count) that needs to be tested on multiple CPUs. 10:44:29 <Phantasm> Rubidium: Nice. Specs? 10:45:04 <Rubidium> one P-III Katmai 500, one P-M 1.6 GHz and Windows 3.11 on a floppy 10:45:36 <planetmaker> :P 10:45:44 <planetmaker> ymmd, Rubidium :) 10:45:55 <Phantasm> Rubidium: I don't see that being multiple CPUs on one comp. 10:46:19 <Eddi|zuHause> that was not part of the question... 10:46:26 <Rubidium> you didn't specify that they needed to be in the same computer 10:46:34 <Phantasm> ... 10:46:36 <Phantasm> It was apparent. 10:46:44 <Bjarni> no it wasn't 10:46:46 <Eddi|zuHause> no, it was not. 10:46:58 <Rubidium> apparantly it was not 10:47:00 <planetmaker> ^ :) quibbling can be sooo nice... :) 10:47:31 <Eddi|zuHause> it's an art... especially when mathmaticians are involved ;) 10:47:42 *** flowOver [~J@S01060016e65abad7.gv.shawcable.net] has joined #openttd 10:48:15 <Bjarni> you want two identical CPUs then? 10:48:39 <Bjarni> I have two 7,14 MHz 68000 CPUs and windows on another computer :P 10:49:25 <dih> ;-) 10:49:35 <Rubidium> just run bochs on that machine and then install Windows 1.0 10:50:00 * planetmaker wonders how Win 1.0 might have looked like. Much different than 2.7 ? 10:50:07 <Eddi|zuHause> does windows 1.0 run in dosbox? 10:50:27 <Rubidium> Eddi|zuHause: might well be the case ;) 10:50:46 <Rubidium> planetmaker: http://en.wikipedia.org/wiki/Image:Windows1.0.png 10:50:49 <planetmaker> Eddi|zuHause: I'd give it a chance 10:51:01 <peter1138> Bah, my tool bar gui changes remove two window classes but only chops out 260 lines of code :( 10:51:25 <Eddi|zuHause> i've only ever heard the statement "windows 1.0 even runs under windows" 10:51:38 <Bjarni> actually those two CPUs are in two different (yet identical) computers 10:51:44 <Bjarni> known as Amiga 500 10:51:53 <Rubidium> Bjarni: cluster them and run bochs on the cluster 10:52:02 <Bjarni> :) 10:52:12 <Eddi|zuHause> anyone remembers the DosShell? 10:52:14 <Bjarni> I'm not sure if both still works 10:52:24 <planetmaker> wow... even worse than 2.7 :) 10:53:10 <Rubidium> too bad they axed the support for Windows 1.0 6 and a half years ago 10:53:20 <planetmaker> :) 10:55:14 <Bjarni> there is no system 1 for mac 10:55:33 <Bjarni> they made it and before it shipped they found a fatal bug in it and made 1.0.1 instead 10:55:43 <Bjarni> so the first mac shipped with system 1.0.1 10:56:16 <Gekz> lol 10:56:34 <Belugas> fonso, quick reading: diagonal patch, like concept, have not seen your work 10:56:51 <Belugas> sattion capacity, don't know, neither concept nr code 10:56:56 <Belugas> will try to give you time on it 10:57:42 <fonso> diagonal levelling: press ctrl while levelling and you don't level an orthogonal rectangle but a diagonal one. Makes building diagonal rails less painful. 10:59:56 <fonso> station capacities: My main problem is that there are bus stops with 2000 people in them. I want to make the amount of cargo you can store on a station related to the number of tiles it comprises. 11:00:16 *** Dred_furst [~Dred_furs@user-5440e40a.wfd80a.dsl.pol.co.uk] has joined #openttd 11:00:19 *** curson [~curzon@79-68-120-205.dynamic.dsl.as9105.com] has joined #openttd 11:01:47 <fonso> My work on diagonal levelling is this patch: http://www.tt-forums.net/download/file.php?id=95264 11:02:30 <blathijs> fonso: How will you handle the "station full" issue? 11:02:30 *** shodan [user@ppp101-219.static.internode.on.net] has joined #openttd 11:03:00 <fonso> cargo won't be accepted from industries, houses or trains wanting to store cargo anymore 11:03:07 <fonso> it works well in the prototype: 11:03:16 <blathijs> fonso: I guess that new cargo will just stop to appear when a station is full, but how to handle cargo (mainly passengers) that want to unload at a full station? 11:03:28 <fonso> http://www.tt-forums.net/download/file.php?id=95287 11:03:31 <Eddi|zuHause> imho the station stockpile issu should better be handled by not generating excess cargo that cannot be transported, not by capping it on some arbitrary "size" value 11:03:55 <fonso> unloading and immediately disappearing is allowed even if the station is full 11:04:05 <fonso> just staying at the station isn't allowed 11:04:13 <Eddi|zuHause> fonso: does not help transferring 11:04:20 <fonso> yes it does 11:04:43 <blathijs> fonso: I saw the link, but I have no time for patch reviewing 11:04:44 <fonso> a vehicle can pick up the goods another one has just unloaded and thus free some of the station 11:04:56 <Eddi|zuHause> station is full, two busses A and B appear, people want to swap between A and B 11:04:57 <blathijs> I do have time to do concept reviewing, though :-p 11:04:59 <fonso> then another vehicle can unload som more 11:05:02 <Eddi|zuHause> there is no way they can unload 11:05:11 <fonso> it works, 11:05:15 <fonso> try it 11:05:47 <blathijs> fonso: If the station is full with cargo that does not want to get on either bus A or B, it won't work I expect 11:05:55 <fonso> then it won't 11:05:56 <Rubidium> so if I set a transfer and leave empty order that means I can deadlock a station 11:06:03 <fonso> yes 11:06:21 <Eddi|zuHause> really, i think station limits are not the solution 11:06:22 <fonso> but only if there is no vehicle picking up the cargo you unload there 11:06:43 <Eddi|zuHause> fonso: but a vehicle cannot pick anything up when it cannot unload first 11:06:52 <Rubidium> well, the bus is waiting behind the bus currently unloading 11:07:17 <fonso> the bus with an unload order it can't fulfill will leave without unloading 11:07:35 <Eddi|zuHause> exactly... which is wrong 11:07:40 <Noldo> what is the goal of this patch anyway? Getting rid of station windows saying 99999999 passangers waiting? 11:07:40 <fonso> why? 11:07:47 <fonso> yes 11:07:59 <peter1138> Has it ever said 99999999? 11:08:10 <fonso> this number is a bit high 11:08:11 <Tefad> OVER 9000?! blasphemey 11:08:13 <Rubidium> fonso: so the unload order becomes pointless 11:08:15 <Eddi|zuHause> you are curing a symptom 11:08:22 <Eddi|zuHause> it does not solve anything 11:08:23 <fonso> but 2000 for a bus stop is high enough to annoy me 11:08:24 <Rubidium> and so does the transfer order 11:08:26 <Eddi|zuHause> only make it worse 11:08:54 <fonso> becomes only pointless if your stations are too small 11:09:10 *** Zr40 [~zr40@120-12-ftth.onsnetstudenten.nl] has quit [Remote host closed the connection] 11:09:14 <fonso> for storing lots of goods you should build big stations then 11:09:30 <Eddi|zuHause> whatever limit you introduce, stations are always going to be "too small" 11:09:47 <fonso> the limit is per tile, mind that 11:09:54 <Eddi|zuHause> because for underserviced stations, generation always exceeds transport 11:10:01 <blathijs> I do think that having some limit is a good idea 11:10:04 <fonso> you can extend the station's limit by building additional station tiles 11:10:10 <Noldo> you are just forcing people to build meaningless stationtiles 11:10:15 <blathijs> Or at least having some way to model station size 11:10:21 <Eddi|zuHause> yes, but adding a tile means only that the station is full at a higher level 11:10:26 <Eddi|zuHause> it does not help transfers 11:10:47 <planetmaker> the only place where production of cargo is excessive is PAX in town centres. You cannot get them away quickly enough using trams or busses. 11:11:01 <planetmaker> But that might even be solvable, if multistop is changed :) 11:11:06 <fonso> and that's my main problem 11:11:21 <blathijs> though perhaps a hard limit is not the way to go. How about only stopping the generation of new cargo at the station when the station is full? (Or make the rate decrease when the station gets fuller) 11:11:22 <Eddi|zuHause> yes, but it is not the solution 11:11:39 <fonso> but don't want a huge multistop for every stop a bus servers 11:11:41 <Kloopy> But that's like real life... when I used to catch the bus home from school, sometimes I would have to wait for the 2nd or 3rd bus because there just weren;t enough of them to get everyone home... and the bus station was always full! 11:11:48 <Eddi|zuHause> and "make the rate decrease" is the supposed effect of a station rating 11:11:53 <Noldo> does station rating effect passanger generation? 11:11:56 <Eddi|zuHause> but it does not adapt properly 11:12:22 <fonso> a rating can be high if you have many small vehicles going to a station 11:12:37 <fonso> and thus are not transporting many goods 11:13:17 <Eddi|zuHause> exactly 11:13:18 <blathijs> Perhaps going through the ratings is a better solution then: Make the rating drop if cargo remains at a station for long, and/or when a station is overfull 11:13:27 <Eddi|zuHause> http://www.tt-forums.net/viewtopic.php?p=714926#p714926 <- read my comment here 11:13:36 <Ammler> it would give the eyecandy stations sense, but it needs including grf support... 11:13:45 <Eddi|zuHause> station rating needs to account for frequency of service and capacity of vehicles 11:14:00 <planetmaker> a high amount of cargo waiting shouldn't matter, if the throughput is high. 11:14:21 <Celestar> peter1138: I'll code the "reassign station" thingy now. If we deem required, we can still add more options later 11:14:24 <planetmaker> maybe an idea to make rating dependant on the throughput of cargo divided by waiting cargo 11:14:57 <Noldo> Eddi|zuHause: how about just flow in and out? 11:15:01 <fonso> I'd be ok with a drop in station rating if the waiting cargo is too large in comparison to station size. 11:15:32 <Eddi|zuHause> fonso: again, "station size" has absolutely no correlation to amount being transported 11:15:33 <planetmaker> that's already effective implicitly. 11:15:34 <fonso> and additionally perhaps a slower unloading on overcrowded stations? 11:15:55 <planetmaker> Station size relates to amount of vehicles loading / unloading -> rating higher with many vehicles, one loading at all times. 11:16:30 <fonso> planetmaker: that's exactly my problem. Station size should be visible as tiles occupied 11:16:44 <Wolf01> mmmh MB now decided that also OTTD screenshots with TTRS and DBSet and ECS are illegal? 11:16:45 <planetmaker> eh? 11:16:45 <blathijs> Eddi|zuHause: Ok, I think I agree that the correct solution to this problem is improving the rating system. I do think that the station's size might be a factor in the rating system, though. 11:17:29 <fonso> planetmaker: what is your question? 11:17:53 <planetmaker> station size is and was always visible... 11:18:06 <Ammler> Wolf01: MB doesn't decide something, he just told you his opinion... 11:18:19 <Celestar> BAH 11:18:21 <planetmaker> it effects rating in as larger stations handle better throughbut, ensure more frequent loading 11:18:23 <fonso> but in an inadequate way 11:18:26 <Celestar> why do I never get where the put const :P 11:18:37 <Noldo> Celestar: :) 11:19:18 <Celestar> especially in something like this: 11:19:32 <fonso> planetmaker: If you're fine with bus stops having 2000 passengers waiting if only enough buses are serving it, we're far apart indeed. 11:19:54 <Celestar> std::list<CargoPacket *>::iterator it 11:19:59 <planetmaker> fonso: that's, as I said, the only problem I see: bus stops in town centres :) 11:20:11 <Rubidium> const_iterator ? 11:20:12 <planetmaker> You cannot send vehicles fast enough to get people transported away 11:20:27 <fonso> hypothise a super fast loading bus 11:20:29 <planetmaker> or trams, or whatever. 11:20:46 <Noldo> fonso: why are the waiting passangers a problem? 11:20:52 <Celestar> Rubidium: bah yeah 11:20:57 <Celestar> Rubidium: can't do what I want 11:21:01 <Eddi|zuHause> fonso: it will implicitly have an effect, because you cannot handle enough busses with a 1-tile station, so the station has to be big enough for other reasons than an artifical hard-limit 11:21:07 <fonso> because I can't imagine 2000 passengers in a single bus stop. 11:21:14 <planetmaker> but then, it's a matter of throughput of cargo. 11:21:41 <planetmaker> fonso: Go to Victoria station, London or King's Cross, Sydney :) 11:21:50 <Gekz> why 11:21:54 <fonso> you can also create that same situation with excessive transfers 11:22:10 <Gekz> lol 11:22:14 <Gekz> I love Town Hall in Sydney 11:22:17 <Rubidium> excessive transfers is what cargopackets is about 11:22:20 <Gekz> it has about 20 entrances 11:22:25 <planetmaker> indeed, a trick which I use sometimes when routes are not done, but towns need service: just pick up people and drop them in the middle of nowhere :P 11:22:31 <Gekz> and it takes 20 minutes to get out of the Queen Victoria building 11:22:59 <blathijs> This is also again related to the openttd scale problem, I guess 11:23:02 <Wolf01> I think the max stockpile of a station should be 100*number of tiles 11:23:37 <fonso> now if everyone agrees that you should be able to dump 2000 passengers on a bus stop in the middle of nowhere I will stop argueing about it and find something else to do. 11:23:49 <Bjarni> so it would take 4 tiles to "store" 350 passengers? 11:24:04 <Gekz> lol 11:24:05 <fonso> if you have a capacity of 100 per tile, yes 11:24:06 <Gekz> nice. 11:24:30 <Bjarni> I have seen that many on what would translate as a single tile station 11:24:31 <Eddi|zuHause> 100 per tile is a really harsh limit, considering that two transrapid wagons can handle 240 passengers... 11:24:41 <Bjarni> that platform was packed 11:24:48 <fonso> you can set the limit higher 11:25:14 <Eddi|zuHause> i am still strongly against that kind of limit 11:25:31 <Bjarni> why would we need that kind of limit anyway? 11:25:31 <blathijs> fonso: I think we agree on the problem (or rather, the symptom), but not on the solution 11:25:41 *** Zr40 [~zr40@120-12-ftth.onsnetstudenten.nl] has joined #openttd 11:25:59 <Bjarni> you want it like SimuTrans handles this? 11:26:05 <Celestar> what are we discussing peops? 11:26:12 <fonso> How does simutrans do it? 11:26:20 <Eddi|zuHause> Celestar: overful stations 11:26:20 <fonso> Celestar: station capacities 11:26:21 <Bjarni> Celestar: cargo waiting at stations 11:26:22 <blathijs> Celestar: Station capacities 11:26:25 <blathijs> haha 11:26:28 <peter1138> Hmm, how do I get a diff out of hg over a set of commits? 11:26:42 <Bjarni> basically somebody considers it unrealistic to have 5000 people waiting at a bus stop 11:27:15 <peter1138> Never involve realism. 11:27:25 <Bjarni> peter1138: make a diff between your branch and trunk 11:27:30 <Celestar> peter1138: we should put station capacities as a plugin-class to the Routing classes, how does that sound? 11:27:31 <fonso> btw, I altered my proposal before: Slower unloading and lower ratings in relation to (number of cargo waiting)/(space available) 11:27:32 <Forked> can we involve "silly"? :p 11:27:33 <Bjarni> I hope you started a branch of your own ;) 11:27:34 <Gekz> peter1138: always involve realism 11:27:43 <Celestar> peter1138: and have a flag that enables/disables it 11:27:46 <Gekz> peter1138: having passenger destinations is realistic. 11:27:49 <blathijs> Celestar: The summary is that having a huge amount of cargo at a small station should not happen, but the question is how to solve it. fonso has created a patch that simply limits the capacity of a station, but that creates some weirdnes wrt transfers and unloading. Eddi|zuHause suggests that the cause of this problem is a broken ratings system, and that fixing that is the solution. 11:27:49 <Celestar> peter1138: so the rest of the code needen't worry 11:28:08 <Bjarni> <Gekz> peter1138: having passenger destinations is realistic. <-- maybe but it mainly affects gameplay 11:28:31 <Bjarni> and we do care about gameplay 11:28:33 <Gekz> and the amount of passengers on a tile doesnt 11:28:35 <Gekz> § 11:28:36 <Gekz> ?* 11:28:47 <Celestar> well. 11:28:50 <fonso> blathijs: And I would be ok with a solution based on ratings, but only solves half of the problem 11:28:51 <Bjarni> it does 11:28:55 <Celestar> how about we limit per station type? 11:29:01 <Celestar> like 200 for a bus stop 11:29:06 <Bjarni> but the question is if we would like this feature in gameplay 11:29:10 <Celestar> 1000 per platform on a train station ... 11:29:15 <Gekz> Bjarni: make it a patch then 11:29:18 <peter1138> In my opinion, we need to produce less passengers, not limit the ones that are produced. 11:29:19 <Gekz> Bjarni: because it can't hurt. 11:29:21 <fonso> I'd make it grf-accessible 11:29:23 <Noldo> Celestar: it punnishes good flow 11:29:29 <Gekz> Bjarni: it would add another element of gameplay 11:29:33 <Noldo> peter1138: agreed 11:29:37 <Gekz> placing more busstops to allow more peeps. 11:29:41 <blathijs> fonso: True, when tweaking station ratings, you can still use a single-tile station to stockpile 1000s of passengers that are en-route to somewhere else. Good point. 11:29:58 <fonso> my proposal for that: slower unloading 11:30:00 <peter1138> More tiles results in a larger catchment area, which results in more passengers. 11:30:08 <Eddi|zuHause> Celestar: the problem is transfers [paxdest]. suppose you have a bus stop that is full with 200 passengers, and you have two full busses appearing with 40 passengers each, no passenge has final destination at that stop, but some want to switch between the busses 11:30:55 <Eddi|zuHause> the limit prevents any transfers going on 11:31:00 *** Jan [~j.schuler@p549168CA.dip.t-dialin.net] has joined #openttd 11:31:06 <Jan> moin 11:31:23 <Jan> hello guys 11:31:24 <Eddi|zuHause> another fischkopp! 11:31:36 <Bjarni> shut up 11:31:44 <Jan> ah doch ein paar deutsche hier :) 11:31:48 <fonso> Eddi|zuHause: slower unloading at overcrowded stations would solve that 11:31:57 <Bjarni> if we pretend we aren't here then he might think the channel is idle and stop talking :P 11:32:01 <Jan> can one any help me ? 11:32:11 <Bjarni> that depends on what your problem is 11:32:18 <Eddi|zuHause> the answer is: 42 11:32:37 <Bjarni> nobody here will give you more toilet paper 11:32:54 <Bjarni> imagine that... IRC from the bathroom because you are out of toilet paper :D 11:32:54 <Jan> i cant found the download for a openttd linux server version 0.6.2. have anyone the link ? 11:33:27 <blathijs> Jan: Which distro are you using? AFAIK we only support Debian directly currently 11:33:43 <Jan> yeah debian i have it 11:33:46 *** Zahl [~Zahl@g226197240.adsl.alicedsl.de] has joined #openttd 11:33:54 <Bjarni> http://sourceforge.net/project/showfiles.php?group_id=103924&package_id=111717&release_id=617243 11:33:57 <Bjarni> this is all we got 11:34:06 <Bjarni> either use a binary from that page or compile yourself 11:34:08 <Jan> ahh n1 thx 11:34:09 <blathijs> Jan: You should then just use the normal version, openttd can be started as dedicated server as well 11:34:51 <blathijs> Jan: I'm still planning to create a seperate server package, but haven't got around to it yet 11:35:50 <Ammler> Jan: I would suggest to compile it self, else you would need sdl and such... 11:37:40 <Ammler> well, so you need gcc, what is better? :-) 11:38:46 *** flowOver [~J@S01060016e65abad7.gv.shawcable.net] has quit [Read error: Connection reset by peer] 11:38:53 <Eddi|zuHause> Bjarni: http://www.german-bash.org/197258 ;) 11:39:51 <Bjarni> o_O 11:40:08 <Bjarni> Eddi|zuHause sends me toilet poetry in German 11:41:24 <Bjarni> <Biber> lol bist du ein arsch :D <-- then it makes sense that he is the one with access to the toilet paper 11:41:28 *** flowOver [~J@S01060016e65abad7.gv.shawcable.net] has joined #openttd 11:42:40 <Eddi|zuHause> :P 11:42:46 <Celestar> dbg: [cargopacket] [Passengers] :Cargo is no longer accepted at <Prarnbury Heights>, rerouting to <Prarnbury Central> 11:42:49 <Celestar> WEE! 11:42:54 <Brianetta> german-bash has pop-up ads 11:43:08 <Eddi|zuHause> really? i never noticed... 11:43:12 <Brianetta> that sucks really hard, like a Dyson cleaner or a black hole. 11:43:40 <Bjarni> I never noticed either 11:44:02 <Bjarni> I guess it detects a British browser and spams it 11:44:12 <Brianetta> It's all Javascript stuff 11:44:18 * Brianetta is reading the sauce 11:44:42 <Eddi|zuHause> there are banner ads between the quotes 11:44:51 <Eddi|zuHause> but i never noticed a popup 11:44:57 <Brianetta> Bjarni: If it was doing that, it'd be more productive of it to give me a non-German ad 11:45:11 <Bjarni> right 11:45:12 <Brianetta> Eddi|zuHause: It wasn't a separate window pop-up 11:45:14 <Celestar> peter1138: pull 11:45:22 <Brianetta> but a javascript div-over 11:45:36 <Bjarni> I hate those 11:45:43 <Gekz> those are terrible 11:45:46 <Eddi|zuHause> indeed 11:45:48 <Brianetta> get.miranda.de 11:46:08 <Brianetta> <script language="JavaScript"> 11:46:08 <Brianetta> var mirando_cache=Math.floor(Math.random()*1000000); 11:46:08 <Brianetta> document.write('<scri'+'pt language="JavaScript" src="http://liefer.mirando.de/insert/2375/'+mirando_cache+'" ></scri'+'pt>'); 11:46:08 <Brianetta> </script> 11:46:10 <Eddi|zuHause> las miranda den sevilla? 11:46:11 <Brianetta> There she is. 11:46:25 <Brianetta> mirando 11:47:09 <Eddi|zuHause> it's another one of those simpson jokes that i have no idea of the english equivalent 11:47:12 <Brianetta> That's a totally evil bit of Javascript 11:47:57 <Eddi|zuHause> "scri'+'pt" is genious ;) 11:54:06 *** glx [glx@bny93-6-82-245-156-124.fbx.proxad.net] has joined #openttd 11:54:09 *** mode/#openttd [+v glx] by ChanServ 11:55:52 *** Roujin [~Roujin@mnch-5d85e906.pool.einsundeins.de] has quit [Ping timeout: 480 seconds] 11:55:56 <Celestar> hey glx 11:56:16 <glx> hello :) 11:56:37 <Celestar> did you have a chance to test anything? 11:57:26 <Celestar> heh, there's a shitload of patches on the forum 11:57:53 <Eddi|zuHause> how long did you not look there? :p 11:58:16 <Eddi|zuHause> what worries me more than the amount of patches, is the amount of patch packs... 11:58:56 <Eddi|zuHause> and with the increasing number of patch packs, the decreasing lifetime of them 11:59:00 <glx> I suggest to not read suggestion forum :) 11:59:08 <Bjarni> what worries me the most is the ideas on the forum 11:59:11 <Eddi|zuHause> indeed ;) 11:59:18 <Bjarni> some of them are really wicked 11:59:47 *** Roujin [~Roujin@mnch-5d85e906.pool.einsundeins.de] has joined #openttd 12:00:03 <Bjarni> at one time somebody got the idea of signals on bridges and he was sure that the reason why it wasn't possible yet would be that nobody else had gotten that idea yet 12:00:14 <Celestar> hah 12:00:17 <Celestar> yeah. right. 12:00:19 <Forked> heh =) 12:00:29 <Forked> "how hard can it be!?" 12:00:29 <Bjarni> and he was so sure of that fact that he didn't even have to search the forums first 12:00:41 <Celestar> the reason why nobody did cold fusion yet is because no one thought of it yet 12:00:42 <Celestar> .. 12:01:00 <Bjarni> yeah 12:01:01 <Celestar> some patches sound useful by their description :P 12:01:03 <Bjarni> except me 12:01:06 <Celestar> haven't read the code 12:01:11 <glx> like? 12:01:11 <Bjarni> that's why I have cold fusion running in the basement 12:01:18 <Bjarni> but it's a secret so don't tell anybody 12:01:41 *** welshdra-gone is now known as welshdragon 12:01:52 <Celestar> glx: the OOP widgets. maybe configurable hotkeys .. 12:02:00 <glx> ha right 12:02:25 <glx> configurable hotkeys was full of code duplication last time I checked it 12:02:33 <Celestar> didn't read it 12:02:38 <Celestar> bah 12:02:46 <Celestar> we should rewrite debug() completely 12:03:01 <Bjarni> why? 12:03:22 <Bjarni> I mean do you have an idea on how it cam be rewritten into something so much better that it's worth the time? 12:03:24 <glx> still no warnings for cargodest :) 12:03:31 <Celestar> from stdio to iostream 12:03:38 <Celestar> glx: cool 12:03:42 <Celestar> glx: did you get my latest version? 12:03:48 <Celestar> (16 minutes ago or so) 12:03:51 <glx> yes 12:03:54 <Celestar> cool 12:03:58 <Celestar> wanna brute-test it (= 12:04:01 <glx> I always pull before compile 12:04:04 <Bjarni> maybe I should test it too 12:04:16 <Celestar> Bjarni: yeah, maybe you should, dunno if anyone has tried on MacOS yet 12:04:23 <Roujin> Celestar: here's two suggestions that i think are nice too: http://www.tt-forums.net/viewtopic.php?f=32&t=38801&p=715145#p715145 12:04:39 <Celestar> glx: the diagonal level tool sounds horrible helpful 12:04:42 <Celestar> Roujin: checking 12:04:44 *** m_ax [~chatzilla@pjbolton.force9.co.uk] has joined #openttd 12:04:49 <Eddi|zuHause> http://www.tt-forums.net/viewtopic.php?f=29&t=37166 <- why has that not been integrated yet? 12:04:56 <Roujin> i'm currently working on the first one (scroll in network window with arrow keys) 12:05:04 <Roujin> nearly done 12:05:09 <glx> Celestar: yes but only in scenario editor I think 12:05:20 <Rubidium> Eddi|zuHause: ask Maedhros 12:05:37 <Celestar> glx: why? 12:05:44 <peter1138> Hmm, I think this is working properly now. 12:05:52 <Celestar> peter1138: what is? 12:07:09 <glx> Roujin: server window now has last use server 12:08:24 <Eddi|zuHause> hm... is it me or does that attachment not provide a download link? 12:08:47 <fonso> rofl: http://www.german-bash.org/221 12:09:06 <peter1138> My toolbar gui rewrite... 12:09:11 <Roujin> glx: how's that related to those suggestions? okay, it lessens the need on displaying the current server during the game, that's true 12:09:25 <Eddi|zuHause> yay, i got someone addicted :P 12:09:27 <Roujin> but the other suggestion? being able to scroll with keys through the server list? 12:10:27 <Roujin> nearly done with a patch for it - only commenting a bit now 12:10:45 * hylje thought up a rudimentary contract concept to, among other things, replace subsidies 12:10:46 <Ammler> why are there no stable linux releases? 12:11:19 <Eddi|zuHause> Ammler: openttd is in many distribution repositories 12:11:52 <Ammler> oh, thought of that, but only for clients... 12:12:15 <Ammler> and debian hasn't such? 12:13:06 <Eddi|zuHause> you can use the client as server 12:13:43 <glx> Ammler: it was too late for debian 12:13:58 <Ammler> Eddi|zuHause: no, you need sdl then 12:16:21 <Eddi|zuHause> so? 12:16:57 *** nekx [~asd@x1-6-00-18-39-d3-e9-f6.k899.webspeed.dk] has joined #openttd 12:16:57 *** nkx [~asd@x1-6-00-18-39-d3-e9-f6.k899.webspeed.dk] has quit [Read error: Connection reset by peer] 12:18:28 <Roujin> if you're interested, http://paste.openttd.org/41657 12:18:37 <Roujin> scroll with arrow keys in server list 12:18:59 <Roujin> i'll put it on flyspray.. 12:19:45 <blathijs> Ammler: openttd is not in Debian/stable because it has only been in Debian for around a year (way after the release of Etch anyway) 12:19:46 <Ammler> Eddi|zuHause: well, it was at least that way, as I compiled it last time, am I wrong? 12:20:04 <blathijs> Ammler: At least 0.6.1 should be in the next stable, and we're hoping to weasle 0.6.2 in as well 12:20:10 <Eddi|zuHause> yes 12:21:11 <Ammler> [14:20] <Eddi|zuHause> yes <-- strange, then I did something else wrong... 12:21:53 <Eddi|zuHause> Ammler: ignore my last sentence ;) 12:23:19 *** nkx [~asd@x1-6-00-18-39-d3-e9-f6.k899.webspeed.dk] has joined #openttd 12:23:20 *** nekx [~asd@x1-6-00-18-39-d3-e9-f6.k899.webspeed.dk] has quit [Read error: Connection reset by peer] 12:23:23 <Ammler> blathijs: can't you include a "testing" repo to stable debian? 12:23:50 <blathijs> Ammler: I think that pulling openttd from testing should work just fine 12:24:11 <blathijs> Ammler: Perhaps the dependencies also need to be pulled in, because of the way they are specified 12:24:22 <glx> Roujin: can't you store the selected index too ? 12:24:27 <blathijs> Ammler: In that case, using the build from the website should work (I always build those on stable) 12:25:50 <Ammler> blathijs: and those runs also without sdl? 12:26:39 <glx> they are not dedicated 12:29:12 *** Sir-Bob [~chatzilla@c122-107-227-146.eburwd5.vic.optusnet.com.au] has quit [Ping timeout: 480 seconds] 12:34:40 <Roujin> glx: hmmm the index could be stored, but then it would have to be recalculated when the list is resorted 12:35:23 <glx> the list will be probably less resorted than arrow keys pressed ;) 12:36:59 *** nkx [~asd@x1-6-00-18-39-d3-e9-f6.k899.webspeed.dk] has quit [Read error: Connection reset by peer] 12:37:09 *** nekx [~asd@x1-6-00-18-39-d3-e9-f6.k899.webspeed.dk] has joined #openttd 12:37:42 <blathijs> Ammler: No, they are full builds so they need SDL 12:43:08 <Celestar> peter1138: you got hg serve running at the moment? 12:44:44 *** Nev [bleepy@5ad1d1af.bb.sky.com] has joined #openttd 12:50:56 *** bleepy [bleepy@5ad51a5d.bb.sky.com] has quit [Ping timeout: 480 seconds] 12:55:26 <Celestar> Macros == eeeeevil 12:58:31 *** ben_goodger [~ben@host81-153-29-228.range81-153.btcentralplus.com] has quit [Ping timeout: 480 seconds] 12:58:56 <blathijs> Actually, Macros was quite a nice guy 12:59:06 <blathijs> In Raymond E. Feist's books anyway :-p 12:59:40 *** ben_goodger [~ben@host81-153-29-228.range81-153.btcentralplus.com] has joined #openttd 13:03:05 *** dlunch [~dlunch@121.185.116.137] has joined #openttd 13:03:29 <Eddi|zuHause> hm... in the window class-ification, what happened to WP(.,.) stuff? 13:04:09 <Celestar> peter1138: I'm trying to turing CDEBUG and RDEBUG into DEBUG through the classes 13:04:16 <glx> Eddi|zuHause: class members 13:05:30 <Celestar> peter1138: it's HARD 13:05:50 <Eddi|zuHause> glx: you mean WP(w, x) gets w->x? 13:06:02 <glx> yes 13:06:37 <Celestar> yay for C++ 13:07:18 *** kais58 [vircuser@78.151.65.240] has joined #openttd 13:09:17 <Noldo> what does WP do anyway? 13:09:29 <Noldo> or did 13:10:20 <Celestar> WP == Window Property afaik 13:10:33 *** welshdragon [~vista@host86-137-66-208.range86-137.btcentralplus.com] has quit [Ping timeout: 480 seconds] 13:11:17 <Celestar> :S 13:11:27 <Celestar> can I tell the processor to ignore a certain line :S 13:12:28 <Celestar> or just not to mangle it :S 13:12:36 <Celestar> LEAVE IT ALONE! SHOO! 13:17:30 <blathijs> You could undef the macro that is breaking the line (which I suspect is the problem?( 13:17:33 <blathijs> s/(/) 13:18:27 <Celestar> because I have to redefine it afterwards 13:18:32 <Eddi|zuHause> i definitely don't understand gui code :( 13:18:51 *** Roujin [~Roujin@mnch-5d85e906.pool.einsundeins.de] has quit [Ping timeout: 480 seconds] 13:20:23 <blathijs> Celestar: #define OLD_FOO FOO; #undef FOO; do_stuff; #define FOO OLD_FOO 13:20:32 <blathijs> Celestar: Won't that work? (Apart from being totally ugly) 13:21:14 <Belugas> fonso, i'm reading the diagonal patch. Code style problems here and there (nothing show-stopping). but i wonder a bit about the code duplications 13:21:23 <Belugas> even comments are duplicated 13:21:53 <fonso> some comments are duplicated on purpose, but where is actual code duplicated? 13:21:55 <Belugas> landscape.cpp and terraform_cmd.cpp 13:22:27 <Belugas> or maybe i'm blind... 13:22:29 * fonso goes investigating 13:22:38 <Celestar> blathijs: didn't work for some reason 13:22:42 <Belugas> but still, why duplication of comments ? 13:22:43 * Celestar shakes his fist at DEBUG 13:23:15 <blathijs> Celestar: What's the problem, exactly? 13:23:16 * Belugas says hello at Celestar and put some boxing gloves on waving fists 13:24:08 <Celestar> hehe 13:24:33 <Celestar> blathijs: in one of my header files, I wish to declare a method called DEBUG 13:24:59 <blathijs> But DEBUG is also a macro with that name? 13:25:02 <Celestar> yes :S 13:25:19 <blathijs> Why not name it Debug or something? All-caps is weird for method names anyway. 13:25:23 <Belugas> do not use same casing :) 13:25:30 <fonso> The comments have been moved around a bit and the code was much longer before. 13:25:36 <blathijs> Even if you would succeed in declaring it, you would have the same issues everywhere you use the method I think? 13:25:40 <Noldo> DeBuG 13:25:45 <fonso> Perhaps they don't make that much sense anymore 13:25:49 <SmatZ> Celestar: you have strange wishes :) 13:26:37 <Celestar> SmatZ: yes .. I wish DEBUG to be a class 13:27:09 <Noldo> why? 13:27:21 <blathijs> Celestar: You just said you wanted it to be a method? 13:28:29 <Celestar> yes 13:28:41 *** tokai [~tokai@p54B803F7.dip0.t-ipconnect.de] has quit [Ping timeout: 480 seconds] 13:28:42 <Belugas> fonso, so the two codes are somewhat related, since they have the same comments? 13:28:46 <blathijs> -ENOUNDERSTAND 13:29:12 <Belugas> blathijs, maybe it;s a class and a method, thus a constructor ? ;) 13:29:31 <Noldo> ooh! 13:29:47 <fonso> I assume you mean the comments with "45 degrees blabla". Then yes, naturally they're somewhat related since that's the essence of diagonal levelling ;) 13:29:56 <Celestar> I wish DEBUG was a class throughout the code, but also a method of RoutingBase_t 13:30:03 *** tokai [~tokai@p54B810D7.dip0.t-ipconnect.de] has joined #openttd 13:30:05 *** mode/#openttd [+v tokai] by ChanServ 13:32:07 *** rortom [~rortom@p57B7C667.dip.t-dialin.net] has joined #openttd 13:32:15 <blathijs> Celestar: Ah, you want DEBUG to be a class instead of a macro :-) 13:32:36 <blathijs> Celestar: Still, why do you want to name the method DEBUG so badly? 13:33:19 <blathijs> The simplest solution by far is to stop wanting that, but you seem to have a very good reason to want it anyway (which you didn't share with us so far) 13:33:27 <Celestar> yeah, I have already stopped wanting it 13:33:39 <Celestar> all debug messages withing the routing system are now printed with Debug() 13:34:40 <Belugas> Celestar, why do you need two methods of message debugging? 13:34:45 * Belugas fails to see the point 13:34:49 <Belugas> altough , 13:35:01 <Celestar> Belugas: because withing the routing system, I want to automagically add the cargo-type to the debug message 13:35:31 <Belugas> mmh... 13:35:41 <Belugas> so maybe a wrapper? 13:35:50 <Belugas> around DEBUG, i mean 13:36:19 <SmatZ> DEBUG supports variable argument list 13:38:12 <Celestar> Belugas: that's what I have now 13:38:38 <Celestar> SmatZ: I don't want to add the cargotype manually to each and every debug message 13:38:57 <Celestar> grep Debug src/routing.* | wc -l 13:38:59 <Celestar> 67 13:39:03 <fonso> Belugas: you're probably right. The two loops which are started with those identical comments " fx, fy form a diagonal coordinate system. ..." do the same thing. However the actions taken inside the loops are quite different. I could solve this with a macro or a with a callback. 13:39:17 <Celestar> fonso: you use the evil word 13:39:43 <fonso> which one? Macro or callback ;)? 13:39:52 *** shodan [user@ppp101-219.static.internode.on.net] has quit [Quit: Client Exiting] 13:40:23 <Celestar> fonso: Macro 13:40:49 <fonso> well then, we'll have to use a callback function ... 13:41:31 <blathijs> Callback functions are not so nice from a performance perspective 13:41:35 <blathijs> what code are we discussing? 13:41:50 <Celestar> peter1138: pull again :) 13:42:16 <Celestar> peter1138: the two "XXX" in routing.cpp .. why the XXX ? 13:42:29 <Belugas> fonso, no macro, that's waht we were against right from the start 13:42:45 <Belugas> and granted, the actions inside loop are different 13:42:50 <fonso> where was that paste service? 13:42:58 <blathijs> paste.openttd.org 13:43:11 <blathijs> or pastebin. perhaps 13:43:22 <Belugas> fonso, maybe it wold be better off a structure holding the different values, 13:43:30 <Belugas> then a commun initialization 13:43:35 <Belugas> function 13:43:38 <Belugas> i think 13:43:55 <fonso> I could do that 13:43:55 <Belugas> the values for the loop, i mean... 13:44:01 <fonso> yes I know 13:44:06 <fonso> ex, ey and so on 13:44:23 <Belugas> blathijs, it's the diagonal selection/leveling patch 13:44:27 <Belugas> fonso, exactly 13:45:41 <blathijs> Belugas: I gathered that, but I was hoping for a link to code :-) 13:45:48 <Belugas> ho... sorry... 13:45:50 <Belugas> wait 13:46:28 <fonso> http://paste.openttd.org/41677 13:46:42 <blathijs> Thanks :-) 13:48:53 <fonso> Belugas: was that "wait" for me? 13:49:10 <blathijs> fonso: This is the improved and unified version? Or where would be adding this macro or callback? 13:49:24 <Belugas> NEITHER! 13:49:27 <fonso> This piece of code shows up twice 13:49:37 <Belugas> fonso, "wait" was addressed to blathijs 13:50:33 <blathijs> fonso: Ah, so this is "walk the tiles diagonally" code that is used twice. I see 13:50:53 <blathijs> Those two "some action"s, are they similar, or completely different? 13:51:11 <blathijs> You might want to consider putting them both into this loop with an if around them (inside the loop) 13:51:15 *** Roujin [~Roujin@mnch-5d85e906.pool.einsundeins.de] has joined #openttd 13:52:30 * Celestar looks at his TODO list for cargopackets and is delighted 13:52:59 <fonso> different 13:53:12 <Noldo> Celestar: what is left? 13:53:34 <Celestar> Noldo: biasing the destination generation not only by distance, but also by station size 13:53:44 <Celestar> Noldo: but I need some way to determine the station size 13:53:58 <Celestar> for passengers, it's easy. just count the amount of passengers in the coverage area 13:54:02 <Celestar> but for cargo ... 13:54:12 <Noldo> of that kind of size 13:54:23 <Noldo> you need to ask the industry 13:56:34 * Belugas is on an emergency call@work, thus not available 13:58:21 <blathijs> fonso: I have this feeling that your looping code is either too complicated, or does something else than I think it does :-) 13:58:32 <Celestar> Noldo: does that work for industries that accept input cargos? 13:58:46 <fonso> I don't think it gets any simpler 13:58:57 <fonso> Have you seen it before I cleaned it up? 13:59:10 <blathijs> No :-) 13:59:32 <blathijs> fonso: What is the code trying to do? Loop the tiles between (sx, sy) and (ex, ey) diagonally? 13:59:40 <fonso> ok ... 14:00:08 <fonso> the original code looped across the "simple" coordinates diagonally 14:00:17 * orudge is poking through lots of old openttd things he has 14:00:29 <orudge> such as my original "new industries" version featuring Born_Acorn's desalination plant and oil power station 14:00:58 <orudge> and things like my original "bigger airport" patch, larger maps, cargo packets, new map array, and other such fun things 14:00:59 <fonso> Then it went through an if-else-tree to determine if this was the first or the second time around and accordingly filled the "black" squares 14:01:41 <fonso> I simplified that by just running over all the coordinates twice and dividing more intelligently so that integer operations work in my favor 14:02:21 *** nkx [~asd@x1-6-00-18-39-d3-e9-f6.k899.webspeed.dk] has joined #openttd 14:02:21 *** nekx [~asd@x1-6-00-18-39-d3-e9-f6.k899.webspeed.dk] has quit [Read error: Connection reset by peer] 14:02:25 <blathijs> It might also be that the variable names are slightly too short for me to understand what happens properly :-) 14:02:47 <fonso> well that's easy to solve 14:02:49 <blathijs> But AFAICS, either fx or fy is guaranteed to be between -1 and 1 (including), right? 14:02:54 <peter1138> Hi 14:03:03 <peter1138> Sorry Celestar, just got back from the dentist... 14:03:11 <Celestar> peter1138: are you allright? 14:03:18 <fonso> no, sfy and sfx are the signs 14:03:44 <blathijs> fonso: Yes, but I think fx or fy is always small 14:03:49 <blathijs> and the other is big 14:04:20 <peter1138> Celestar, er, need a wisdom tooth pulled on Monday :o 14:04:24 <fonso> fx and fy are the "angle" in which you draw 14:04:33 <fonso> so they might be quite large 14:04:52 <fonso> they might be equal if you draw a square 14:05:18 <blathijs> fonso: Or rather, you're rotating the coordinate system, so either fx or fy must be small (since the endpoint and starting point will lie close together on at least one of the diagonal axis) 14:05:35 <blathijs> The start and end point are diagonally connected, righ? 14:05:48 <fonso> yes, but they may be far apart 14:06:00 <peter1138> Celestar, ah, the 'town effect' for valuables... 14:06:02 <orudge> heh, and the network branch, where the new networking was new 14:06:34 <Noldo> how much did the old networking suck? 14:06:41 <blathijs> fonso: Yes, but since the are diagonal, abs(dx) and abs(dy) cannot be much different 14:06:48 <blathijs> fonso: one difference, really 14:06:59 <peter1138> Celestar, we need to find out what cargo behaves like valuables, as NewGRF does not have an attribute for that. 14:07:04 <fonso> yes they can 14:07:23 <fonso> you can draw any rectangle you like 14:07:38 <fonso> dx and dy might be very different 14:07:52 <peter1138> Celestar, I'm thinking of making the attribute up after the GRFs are loaded; if it has no 'town effect' and there is an industry that both produces and accepts the same cargo, that would be behaving like valuables. I think. 14:08:11 <blathijs> fonso: Than I'm probably completely missing the point of your patch :-P 14:08:12 <fonso> for example dx=1 and dy=200 is ok 14:08:31 <blathijs> And then it would insert a number of straight tracks and a single diagonal one, or something? 14:09:35 <Celestar> peter1138: possible. yeah 14:09:42 <Celestar> peter1138: we should maybe at a TownEffect? 14:09:44 <fonso> on moment. I have to try the 1-200 thing in practice. It sounds strange 14:09:55 <peter1138> Celestar, yeah, we could try that too :) 14:10:06 <peter1138> Probably more reliable. 14:10:27 <Eddi|zuHause> use templates ;) 14:10:48 <Eddi|zuHause> hm... buffer :( 14:11:04 <Celestar> Eddi|zuHause: ? 14:11:05 <Celestar> buffer? 14:11:12 <Eddi|zuHause> ignore that :( 14:11:16 <Celestar> peter1138: you should pull. I'm mostly done 14:11:25 <fonso> lets phrase it that way: it draws a diagonal rectangle with the beginning and end of your mousedrag as corners 14:11:32 <Eddi|zuHause> buffer == not scrolled to the bottom of the chat 14:11:44 <fonso> just like orthogonal, actually 14:11:56 <peter1138> I did. 14:12:09 <Celestar> cool 14:12:15 <Celestar> now. 14:12:46 <Celestar> todo items 1a and 1b give me a headache 14:13:18 <blathijs> fonso: Ah! I had assumed a diagonal line, which is a rectangle with width 1 (hence the maximum of 1 for either fx or fy) 14:13:24 *** Vikthor [~Vikthor@snat1.spoje.net] has quit [Quit: Leaving.] 14:16:35 <blathijs> fonso: Actually, using a macro would make sense, since it would be analogous to the BEGIN/END_TILE_LOOP we have now for looping over a normal square 14:16:56 <fonso> If you like that I can do it that way 14:17:25 <blathijs> I think using a callback might impose a unacceptable performance cost when you wipe large areas (which isn't too fast already I think) 14:17:28 <fonso> But someone told my something along the lines of macros coming from hell itself ... 14:17:47 <blathijs> I'm not sure if I like it, it's just that I can't easily imagine a better solution :-p 14:18:03 <blathijs> But let's wait for a bit so Celestar can start protesting :-) 14:21:44 * Belugas mumbles at stupid so-called technician who can't follow simple directives 14:22:16 <Belugas> fonso, maybe start by giving better names to variables? 14:22:16 <Roujin> Belugas: oh dear, now you'll be haunted by users urging you to complete it :P http://www.tt-forums.net/viewtopic.php?p=715245#p715245 14:22:27 <Belugas> would help a tiny little bit... 14:22:39 <fonso> ok, I'll do that first 14:23:00 <Belugas> Roujin, they will have to keep waiting, since it's VERTY far from been working ;) 14:23:06 <peter1138> blathijs, the problem is the original macro version was a very very nasty macro... 14:23:22 <Roujin> did you decide to pick it up again? 14:23:33 <Belugas> pick it up? 14:24:05 <blathijs> fonso: I think you should not be using x and y for the variables in the diagonal coordinate space. Perhaps call those axis a and b or something ? 14:24:19 <Roujin> continue work on it i mean (was that wrong?) 14:24:40 <fonso> ok 14:24:57 <blathijs> fonso: Perhaps add some simple functions to hide the translation between the coordinate systems as well, not sure if that is really needed or helpful, though 14:25:23 <Belugas> Roujin: well... it's still "playable", just that i got a bit pissed off by not been able to make any progress, so i decided to let it rest for a while before going insane 14:25:36 <Belugas> i guess i'll resume work on it in a month 14:25:57 <Roujin> that's always preferable ;) (not going insane) 14:25:58 <Belugas> evaluated time before colours-work-related finished 14:26:45 <Roujin> that many places to enumify? or do you have some bigger plan regarding colors 14:27:11 <Belugas> no bigger plans 14:27:23 <Belugas> just understanding and commenting is good enough for now 14:27:35 * Phantasm pokes Belugas for the fix. ;P 14:28:37 <Belugas> Phantasm, there is already a part that went into trunk recently 14:28:52 <Phantasm> Oh.. How was the flood of messages fixed? 14:28:59 <Belugas> the open and closure news of industries that are now separated 14:29:15 <Belugas> it's not fixed as per say, but it's gong on the right way 14:29:20 <Phantasm> Yup. 14:29:34 <Phantasm> Estimate on when will the whole thing be fine? 14:29:48 <Celestar> blathijs: the tile loop can be done with and std::vector<Tile *> as well (= 14:29:48 <Belugas> and while i was doing that part, i realized how messy the colours of the guis are been treated, so i decided to give it a shot 14:31:42 <blathijs> Celestar: It sounds pretty inefficient to put all those tiles in vector first, while you can easily loop them directly 14:32:02 <blathijs> Celestar: Having some sort of TileRectangleIterator might be useful, though 14:32:03 <Belugas> Roujin, so this is where i stand right now: http://devs.openttd.org/~belugas/patches/Colours-home-wip.patch 14:32:11 <Celestar> blathijs: or rather map should be and std::vector 14:32:15 * Belugas nods at blathijs 14:32:37 <blathijs> Celestar: And then also TileDiagonalRectangleIterator 14:32:40 <blathijs> (but with better names) 14:32:59 <blathijs> Celestar: How would you be doing two-dimensional iteration then? 14:33:40 <blathijs> Celestar: If the map was a std::vector (which sounds like a terrible plan) you would still need specialized iterators to loop over a rectangle area 14:35:50 <Eddi|zuHause> <Celestar> Noldo: but I need some way to determine the station size <- imho, you should leave that up to a newgrf industry callback [possibly also useful for AI]. for default industries you can treat them all equally 14:36:22 *** Singaporekid [~notme@cm53.epsilon123.maxonline.com.sg] has joined #openttd 14:38:23 *** Jan [~j.schuler@p549168CA.dip.t-dialin.net] has quit [] 14:39:33 <Belugas> Phantasm, i'm very VERY V E R Y poor at making estimates 14:39:45 <Phantasm> Belugas: Heh. 14:40:09 <Belugas> the last time i did one (at work), i busted the schedule by a big month 14:40:14 <Belugas> a month more, that is... 14:40:48 <Belugas> so, i could tell you by the end of teh year, but it wold be as good as "in spring 2009" 14:40:49 <Belugas> :) 14:41:08 <Belugas> mmh... 14:41:20 <Belugas> maybe if i did not start so many stuff at once :S 14:41:39 <Eddi|zuHause> employ 2500 people to meet the easter deadline :p 14:44:05 * Belugas hires Eddi|zuHause right away 14:44:34 <Eddi|zuHause> how much do you pay? ;) 14:44:49 * Belugas gives Eddi|zuHause the same salary he receives for working on OpenTTD ;) 14:44:51 <Roujin> Belugas: there's some inconsistency between color and colour in some places 14:45:10 <Belugas> could be, Roujin, could very well be 14:45:21 <Eddi|zuHause> i get payed thousands of hours of joy! 14:45:24 <Eddi|zuHause> \o/ 14:45:40 <Roujin> also i see that you've merged TextColour and Colour - so some colours have two names now 14:45:52 <Belugas> heheh 14:46:03 <Roujin> couldn't they just be removed then? 14:46:04 <Belugas> didn't the patch has the wip name on it? 14:46:35 <Belugas> not really now, Roujin, they still are addressing differnt values, for the most part 14:46:36 <Celestar> back 14:47:00 <Celestar> blathijs: meanwhile, openttd is c++, arrays are evil (= 14:47:03 *** Doorslammer [Doorslamme@PIPP-p-203-54-115-243.prem.tmns.net.au] has quit [] 14:47:32 <Belugas> open is C++ FLAVOURED, Celestar, not totally c++ ;) 14:47:38 <Celestar> true 14:47:43 <SpComb> C++ is evil, OpenTTD is C++, OpenTTD is evil 14:47:43 <Celestar> but it's going in that direction, isn't it? 14:47:53 <Belugas> think so, yes 14:47:55 <SmatZ> for me, no 14:47:58 <blathijs> Celestar: Still, std::vector is not a suitable implementation for the tile storage, I think 14:48:03 <Celestar> SpComb: I not really see what is evil about C++ 14:48:05 <Celestar> blathijs: why? 14:48:22 <Belugas> but not on a fiercefull-do-it-right-now-just=because-it-has-to-be-done mode 14:48:33 <blathijs> Celestar: I'm not denying that slapping an STL-container like interface on the map array might be a good idea 14:48:35 <Celestar> Belugas: that much is certain (= 14:48:47 <blathijs> Celestar: It provides all kinds of fancy features that we don't need 14:49:01 <blathijs> Celestar: otoh, if you just reserve the size you need, it might work out just fine I guess. 14:49:05 <Belugas> when it is required, or usefull, yes. Otherwise, why? 14:49:14 * Belugas resumes work@work 14:49:15 <Celestar> let me put it another way: what's the disadvantage of using std::vector to store the map 14:49:28 <Celestar> Belugas: we're not changing anything at the moment. merely discussing 14:49:37 <blathijs> Celestar: I was thinking in the performance corner, but I'm not sure that it really matters 14:49:47 <Celestar> SpComb: C++ is usually evil when one tries to put C paradigms into C++ 14:49:49 <blathijs> Celestar: So you might be right :-) 14:49:58 <Celestar> blathijs: std::vector is just as fast as an array or a pointer 14:50:07 <Celestar> it's contingouos 14:50:11 <Celestar> (spelling .. ) 14:50:19 <blathijs> Celestar: Yeah, only when changing it's size things can get slow 14:50:27 <Celestar> blathijs: just like with realloc .. 14:50:31 <blathijs> Celestar: Which we shouldn't be doing anyway :-) 14:50:35 <blathijs> yup 14:50:38 <Belugas> Roujin, _string_colormap (table\palettes.h) needs to be adjusted to match usual colours 14:50:44 * Belugas goes back @work 14:51:03 <SpComb> Celestar: we're talking about the OpenTTD source code here, indeed :( 14:51:30 <blathijs> Celestar: Still, it wouldn't really help with the problem at hand, since the iterator you get from std::vector is only useful for iterating in one direction (not in the other, nor in a rectangle) 14:51:57 <Celestar> blathijs: however, you can make a Tile class (which we should be doing anyway) and write your own interators 14:52:34 <Celestar> Tile_t::Rectiterator, Tile_t::Diamonditerator, Tile_t::Spiraliterator ... 14:52:42 * SpComb averts his eyes 14:52:51 <blathijs> Huh? Are iterators part of the element (Tile) ? Aren't they part of the container? 14:52:57 <SpComb> I just have this irrational fear of C++ 14:53:09 <Celestar> SpComb: I used to as well until quite recently in fact 14:53:21 <Celestar> after having coded the routing system, I feel quite the contrary 14:53:34 <Celestar> SpComb: only real mistake you can make is to regard C++ and an extension to C 14:53:42 <blathijs> Celestar: Also, you don't need a std::vector backend to have thos iterators, right? They can be standalone classes (with a common superclass probably) that operate on the existing map array? 14:53:56 <Celestar> blathijs: of course. 14:54:04 <Celestar> blathijs: but one isn't using arrays in C++ 14:54:05 <Celestar> (= 14:54:40 <blathijs> huh? one what? 14:54:52 <SpComb> Celestar: so OpenTTD's C++-flavoured sauce cod is a bad idea? 14:55:05 <Celestar> SpComb: nope 14:55:22 <Celestar> SpComb: just once you rework a component, stick it into a class 14:55:26 <Celestar> SpComb: like we have done 14:55:42 <Celestar> if I find a free .. minute .. I'll make a Tile class at some point 14:55:54 <Roujin> what is the maximum number of values in a SmallVector<T, 32> ? 2^32? 14:56:15 <Celestar> and get rid of the evil evil evil TileTypeProcs tables 14:57:21 <Celestar> which is really nothing else than the attempt to produce an ABC with polymorphic pointers 14:57:33 <Eddi|zuHause> we need some kind of "Wormhole" tile classes 14:57:46 <Eddi|zuHause> for vehicles travelling in tunnels/on bridges 14:58:15 <Eddi|zuHause> so all the tile changing functions can be called while "in wormhole" 14:58:17 <SmatZ> Roujin: the second number is size of block in what is memory allocated, static array would be better in that case :-P 14:58:17 <blathijs> Celestar: There is more code in OpenTTD that's really polymorphism-in-C :-) 14:58:20 <Eddi|zuHause> especially signal related 14:58:38 <Roujin> aah 14:58:54 <SpComb> imo, nothing wrong with "polymorphic" C code, as long as it's C code, and doesn't try and be anything else 14:59:45 <peter1138> Hm 15:00:15 <Roujin> I was wondering what kind of variable I should use to store the number of a server.. to be safe that it's never too big 15:00:21 <SpComb> but I probably shouldn't really discuss C++ until I've actually learned it 15:01:01 <Celestar> SpComb: google for "C++ FAQ lite" .. it's very good imho 15:01:11 <Roujin> uint16 should be enough i guess.. 15:08:28 <Celestar> Roujin: unless I'm space constrained (i. e. have a large array of it), I use int. 15:08:32 <Celestar> or unsigned int 15:08:43 <SpComb> Celestar: and I counter you with http://yosefk.com/c++fqa/ 15:08:49 <SpComb> note that I've read the FQA, but not the FAQ 15:10:40 *** m_ax [~chatzilla@pjbolton.force9.co.uk] has quit [Read error: Connection reset by peer] 15:12:25 <Eddi|zuHause> what does "error: too many initializers for âconst WindowDescâ" mean? 15:14:44 <glx> what it says :) 15:15:09 <glx> too many things between { and } 15:15:41 <Eddi|zuHause> yay, it compiles ;) 15:16:54 *** svippery [~svip@0x50a5b150.boanxx18.dynamic.dsl.tele.dk] has joined #openttd 15:16:54 *** svippy [~svip@0x50a5b150.boanxx18.dynamic.dsl.tele.dk] has quit [Read error: Connection reset by peer] 15:20:18 <Celestar> heh SpComb nice one. haven't read it yet 15:20:52 *** frosch123 [~frosch@frnk-590fcfe3.pool.einsundeins.de] has joined #openttd 15:30:34 *** AntB [~AntB-UK@host86-155-38-0.range86-155.btcentralplus.com] has joined #openttd 15:45:02 <fonso> I renamed the variables for diagonal levelling: http://www.tt-forums.net/download/file.php?id=95767 15:45:42 <fonso> Should I use a macro for diagonal tile walking? 15:46:27 *** nekx [~asd@x1-6-00-18-39-d3-e9-f6.k899.webspeed.dk] has joined #openttd 15:46:27 *** nkx [~asd@x1-6-00-18-39-d3-e9-f6.k899.webspeed.dk] has quit [Read error: Connection reset by peer] 15:48:34 *** rortom [~rortom@p57B7C667.dip.t-dialin.net] has quit [] 15:52:06 * Belugas reads 15:52:19 <CIA-5> OpenTTD: smatz * r14005 /trunk/src/rail_cmd.cpp: -Codechange: minor coding style fix 15:57:06 *** nkx [~asd@x1-6-00-18-39-d3-e9-f6.k899.webspeed.dk] has joined #openttd 15:57:06 *** nekx [~asd@x1-6-00-18-39-d3-e9-f6.k899.webspeed.dk] has quit [Read error: Connection reset by peer] 15:57:22 *** AntB [~AntB-UK@host86-155-38-0.range86-155.btcentralplus.com] has quit [Ping timeout: 480 seconds] 15:57:38 <Belugas> feels better, fonso 15:57:47 <Belugas> as for the macro, i don't know 15:58:07 <Belugas> landscape.h, useless change 15:58:08 <fonso> I can write a version with macro and see how that feels ... 15:58:48 <Belugas> yuo could :) 15:59:02 <fonso> yes, landscape.h was accidental. I was preparing to put the macro there when someone called me back 15:59:40 <Belugas> in viewport.cpp, comment "// a_size, b_size describe a rectangle with rotated coordinates" should be "/*..*/" instead 16:00:17 * fonso goes reading the coding style thread 16:00:35 <Belugas> a comment on its own line is always /**/ 16:00:45 <Belugas> a comment at the end of a code like is // 16:01:00 <Belugas> a comment defining a struct/enum/whatever is ///< 16:01:08 <fonso> ok, thanks 16:01:52 *** Purno [~Purno@5350931D.cable.casema.nl] has joined #openttd 16:02:12 <Belugas> terraform_cmd.cpp, the comment for p2 should not references the values used. ust naming the enum and refering to it would be good enough, i think 16:02:22 <Belugas> yeah. i know... picky.. 16:02:51 <Eddi|zuHause> comment for a function is /** */ (doxygen?) 16:03:04 <fonso> that's all not difficult to repair 16:03:15 <Belugas> yes Eddi|zuHause 16:04:45 *** Progman [~progman@p57A1E2BF.dip.t-dialin.net] has quit [Remote host closed the connection] 16:05:16 <Yexo> fonso: why can't LOWER_AND_LEVEL and RAISE_AND_LEVEL not be diagonal? 16:05:38 <fonso> in principle they can 16:05:58 <fonso> but there is another patch that some people like which redefines the CTRL key for them 16:06:12 <Belugas> drag and draw? 16:06:12 <fonso> it's called "advanced terraform" 16:06:15 <fonso> yes 16:06:22 <fonso> that's the same 16:06:25 <Belugas> wonders how both can cohabit 16:06:31 <Belugas> co exist 16:06:32 <Yexo> wasn't that patch also for flattening land? 16:06:36 <fonso> there are a couble of ideas 16:06:41 <fonso> Yexo: yes 16:06:49 <Yexo> so it'd can't co exists anyway 16:07:16 <fonso> uh, I have to look it up. It was complicated 16:09:03 <Yexo> if you make p2 a bitmask (you have to change LEVEL_* for that), both patches could coexist 16:09:12 <fonso> so, my proposal was to limit drag&draw to lower and raise and make it default behaviour for them 16:09:18 <Belugas> go Yexo go! 16:09:28 * Belugas goes to lunch 16:10:17 <fonso> the argument was that most people don't need area raise and lower as it's counter-intuitive anyway 16:10:33 <fonso> You can actually lower land with raise and raise land with lower 16:10:57 <dih> http://pub.dihedral.de/openttd/savegames/r14001/r14001_20080806-180001.sav <- repeated desyncs 16:11:27 <SmatZ> dih: did you reproduce it? 16:12:46 <fonso> and a levelling drag&draw is counterintuitive, too, since you're not really levelling a consecutive patch land. You're only levelling single tiles. 16:13:15 <Roujin> you're free to take my patch and make something yourself out of it 16:13:32 <Roujin> [18:06] <Yexo> so it'd can't co exists anyway 16:13:32 <Roujin> [18:06] <fonso> uh, I have to look it up. It was complicated 16:13:32 <Roujin> [18:08] <Yexo> if you make p2 a bitmask (you have to change LEVEL_* for that), both patches could coexist 16:13:32 <Roujin> [18:08] <fonso> so, my proposal was to limit drag&draw to lower and raise and make it default behaviour for them 16:13:32 <Roujin> [18:08] <@Belugas> go Yexo go! 16:13:34 <Roujin> [18:09] * @Belugas goes to lunch 16:13:35 <Roujin> oops 16:13:45 <Yexo> fonso: I don't see why that is couterintuitive, if I just want to level some tiles for a railway for example 16:13:48 <Roujin> sorry for that 16:15:02 <fonso> So, if we want to have drag&draw as well as diagonal and orthogonal levelling we need a second modifier key or some gui widget for it. 16:15:19 <dih> SmatZ, see #openttdFairPlay 16:15:27 <Yexo> or just a clientside patch setting setting what ctrl will do 16:15:36 <fonso> or that 16:15:59 <SmatZ> dih: been there, done that :) 16:16:12 <fonso> but that's the task of the patch adding the second option, I'd say 16:16:31 <Yexo> but imo you shouldn't worry about that now, as that is a different patch. If you just make p2 a bitmask you leave the option open for both to coexist, without needing to implement that patch option right now 16:17:09 <fonso> ok, bitmask for p2. I'll do it later today. 16:17:21 <Roujin> glx, are you still there? I've followed your suggestion saving the position of the selected server instead of searching through the list every time 16:17:31 <Roujin> putting the new version on flyspray.. 16:19:21 *** Reemo [Dr_Jekyll@p57B0ED12.dip.t-dialin.net] has joined #openttd 16:22:19 <Yexo> fonso: in DraggingDiagonal(), _thd.select_method == VPM_X_AND_Y can be moved out of the || 16:22:25 *** nekx [~asd@x1-6-00-18-39-d3-e9-f6.k899.webspeed.dk] has joined #openttd 16:22:26 *** nkx [~asd@x1-6-00-18-39-d3-e9-f6.k899.webspeed.dk] has quit [Read error: Connection reset by peer] 16:25:05 <fonso> thanks 16:29:31 *** Brianetta [~brian@client-86-27-108-163.brnt.adsl.virgin.net] has quit [Quit: TschÃŒÃ] 16:29:42 *** nekx [~asd@x1-6-00-18-39-d3-e9-f6.k899.webspeed.dk] has quit [Read error: Connection reset by peer] 16:29:55 *** nekx [~asd@x1-6-00-18-39-d3-e9-f6.k899.webspeed.dk] has joined #openttd 16:32:03 *** fonso [~fonso@brln-d9bacd6d.pool.mediaWays.net] has left #openttd [Kopete 0.12.7 : http://kopete.kde.org] 16:32:50 <Eddi|zuHause> argh... this can only be Belugas' fault... 16:33:22 <Belugas> yes, i agree 16:33:29 <Belugas> **whatever** 16:33:38 <Belugas> what??? 16:34:42 *** Wezz6400 [~Wezz6400@ndb.demon.nl] has quit [Quit: bbl] 16:34:54 <Eddi|zuHause> conflicts in a widget array ;) 16:35:04 <Belugas> youhou!! 16:39:21 * peter1138 is here... 16:41:30 <peter1138> Hmm, is there any chance of adding a new target for MSVC? 16:41:48 <peter1138> One which defaults to not requiring DirectMusic :p 16:42:23 <glx> hehe 16:45:34 <peter1138> Ah, Celestar merged my changes :D 16:45:42 <peter1138> Looks like it still works ;) 16:46:23 <peter1138> What's preferred for sorting, one three state button for each sort type, or a sort direction two state button and a drop down list? 16:46:53 <peter1138> The latter makes it easier to add sort types but is a bit over the top for just two sort types. 16:48:17 <peter1138> Tell me! :o 16:49:47 * Belugas reads 16:49:55 <Belugas> slurrp 16:50:23 <Belugas> the latter indeed 16:50:41 <Belugas> otherwise, it might ends up looking like cargo station sorting 16:50:46 *** nekx [~asd@x1-6-00-18-39-d3-e9-f6.k899.webspeed.dk] has quit [Read error: Connection reset by peer] 16:50:53 <Belugas> (if it's still there..) 16:50:58 *** nekx [~asd@x1-6-00-18-39-d3-e9-f6.k899.webspeed.dk] has joined #openttd 16:51:00 <Belugas> or filtering 16:58:39 *** Wezz6400 [~Wezz6400@ndb.demon.nl] has joined #openttd 16:59:35 *** nkx [~asd@x1-6-00-18-39-d3-e9-f6.k899.webspeed.dk] has joined #openttd 16:59:36 *** nekx [~asd@x1-6-00-18-39-d3-e9-f6.k899.webspeed.dk] has quit [Read error: Connection reset by peer] 17:01:49 *** nekx [~asd@x1-6-00-18-39-d3-e9-f6.k899.webspeed.dk] has joined #openttd 17:01:49 *** nkx [~asd@x1-6-00-18-39-d3-e9-f6.k899.webspeed.dk] has quit [Read error: Connection reset by peer] 17:03:59 *** Singaporekid [~notme@cm53.epsilon123.maxonline.com.sg] has quit [Quit: Leaving] 17:08:34 <peter1138> Gah, anyone familiar with OpenOffice calc? 17:09:04 <peter1138> I have a date field which I want to concatenate() into a string... but OpenOffice carefully converts the formatted date output to an integer... 17:13:43 <frosch123> =TEXT(B2; "dd/mm/yyyy") 17:20:09 <peter1138> Thanks 17:24:18 *** mikl [~mikl@cpe.ge-0-2-0-812.0x50c774be.boanqu1.customer.tele.dk] has joined #openttd 17:35:06 * peter1138 attempts to crash it. 17:37:36 <Prof_Frink> peter1138: Drive an HST at it. 17:45:41 <Eddi|zuHause> http://www.tt-forums.net/viewtopic.php?f=29&t=37166&p=715316#p715316 <- probably something for brianetta ;) 17:45:54 <peter1138> Celestar, pull ;) 17:56:30 * Belugas wonders what aniation uses the "e" of ExtraPaletteValues 17:57:44 * Belugas would eventually make a patch that will use fire animation and tranposed on "e" just to see waht will change 17:57:49 <Belugas> or somehting like that 18:03:46 <Belugas> brown to beige cycling 18:03:55 <Belugas> maybe someting in toyland, not sure 18:05:02 <SpComb> http://bugs.gentoo.org/show_bug.cgi?id=233929 <-- OpenTTD - THIS IS SERIOUS BUSINESS 18:05:29 <Rubidium> SpComb: serious in what way? 18:06:03 <SpComb> serious enough to have proper security vulnerabilities 18:06:30 <SpComb> and/or security advisories 18:06:33 <Rubidium> that happens when they start reading the release notes 18:07:39 <Ammler> new fs has a glitch, if I am logged in, date is replaced by my nick: http://img13.myimg.de/fsbug38df0.png 18:08:36 <Rubidium> if only the server would allow connecting from here 18:09:47 <Ammler> sry, wrong link: http://www.myimg.de/?img=fsbug38df0.png 18:10:06 <peter1138> Still doesn't load, heh 18:10:32 <Rubidium> yeah, myimg is really doing proper copyright protection ;) 18:10:56 <Ammler> was working well until now, :-( 18:11:13 <Rubidium> Ammler, then you broke it! 18:12:24 <Ammler> http://bugs.openttd.org/task/2199/getfile/3162/fsbug.png 18:12:27 <Ammler> better? 18:13:37 <Rubidium> works fine for me 18:14:03 <Rubidium> but I'll take a peek in the database 18:16:52 <Rubidium> seems like something went wrong during the upgrade for 3 users 18:17:04 <Rubidium> should be solved now 18:20:41 <Ammler> he, I might know why 18:21:18 <Ammler> I have prefixed my nick with a space to have all tasks from me in front, if I sort for authors :-) 18:21:40 <Ammler> forgot, to rename it after 18:28:03 *** thgergo [~thgergo@members.openttdcoop.org] has left #openttd [] 18:35:46 <Belugas> that is... 18:35:51 <Belugas> pfffff 18:35:56 <Belugas> not worth it 18:36:40 *** mikl [~mikl@cpe.ge-0-2-0-812.0x50c774be.boanqu1.customer.tele.dk] has quit [Quit: mikl] 18:36:51 *** Progman [~progman@p57A1E2BF.dip.t-dialin.net] has joined #openttd 18:40:52 *** fonso [~fonso@brln-d9bacd6d.pool.mediaWays.net] has joined #openttd 18:44:51 *** Vessajono [vessajono@nikita.tnnet.fi] has quit [Quit: Changing server] 18:45:23 <peter1138> A is quite near the beginning... 18:46:04 <hylje> " A" is closer 18:46:25 <Eddi|zuHause> not if everyone else is called _ or [ or similar ;) 18:48:31 <Prof_Frink> People like that should be shot. 18:49:27 * Belugas agrees 18:49:33 * orudge shoots Belugas 18:50:08 * Rubidium reloads the last autosave of Belugas 18:50:26 <peter1138> I hope that's not a yearly autosave :o 18:50:28 <glx> Ammler: about FS, I guess you are using firefox 18:50:40 <peter1138> Or maybe he does... he'd be a bit younger :D 18:50:47 <Belugas> i have an autosave??? 18:51:16 *** fonso is now known as [fonsinchen] 18:51:28 <Belugas> well... i guess I do, but he's not in school yet ^_^ 18:51:31 * [fonsinchen] is waiting to be shot 18:54:07 <Ammler> glx: yes I do, it works now, btw. 18:55:03 <Ammler> the space was still in front, so not the error... 18:57:18 <glx> firefox autofills the profile form with wrong data 18:57:50 <CIA-5> OpenTTD: frosch * r14006 /trunk/src/vehicle_gui.cpp: -Codechange: Deduplicate some code. 19:00:21 * Bjarni shoots [fonsinchen] for no apparent reason 19:00:43 <CIA-5> OpenTTD: frosch * r14007 /trunk/src/ (order_gui.cpp vehicle_gui.cpp): -Fix [FS#2098]: Notify vehicle windows when their internal state is botched up from outside. 19:01:05 *** [fonsinchen] is now known as zombie-fonsinchen 19:01:09 * hylje read the "de" as "re" as first 19:02:07 <Bjarni> that's how you create zombies 19:02:14 <Bjarni> let me show you that again 19:02:23 * Bjarni shoots hylje for no apparent reason 19:02:52 * hylje sees a pony zooming to the trajectory of the bullet and absorbing it 19:03:38 * Bjarni zaps hylje with a tesla coil 19:03:46 <hylje> ow 19:03:56 <hylje> you got that thing working? 19:03:58 * Bjarni shoots hylje 19:04:09 <hylje> that hurt! 19:04:24 * zombie-fonsinchen gnawls on hyljes leg 19:04:42 <hylje> help! help! 19:05:21 <Bjarni> http://uk.youtube.com/watch?v=3ff_AXVlo9U <-- I think if you can do this you can do more or less everything you want if you put enough time and money into it 19:06:55 *** kais58 [vircuser@78.151.65.240] has quit [Read error: No route to host] 19:07:46 * SpComb slaps hylje around a bit with a lame whale 19:08:08 <Belugas> hey! Leave the whales out of it, will you? 19:08:13 * hylje parries with the help of a leek 19:08:19 * Belugas pets the poor little whale 19:08:20 * SpComb feeds zombie-fonsinchen into a C++ compiler 19:08:36 *** zombie-fonsinchen is now known as zombie^2-fonsinchen 19:09:00 * SpComb disassembles zombie^2-fonsinchen and compares it against the origional 19:09:14 *** zombie^2-fonsinchen is now known as byte-salad 19:09:22 <SpComb> omnomnom 19:09:38 * SpComb attempts to execute it 19:10:03 *** byte-salad [~fonso@brln-d9bacd6d.pool.mediaWays.net] has left #openttd [Kopete 0.12.7 : http://kopete.kde.org] 19:10:08 <SpComb> that confused him 19:10:14 *** byte-salad [~fonso@brln-d9bacd6d.pool.mediaWays.net] has joined #openttd 19:10:26 <hylje> that kinda implied a segfault 19:10:58 * SpComb looks for the core dump 19:11:15 <byte-salad> lesson learned: never execute a squared zombie 19:12:17 * hylje hears a faint "braaaaains" from the general direction of SpComb 19:12:35 <SpComb> myes, I'm reading the C++ FQA 19:12:57 <SpComb> I was planning on doing a C++ course this semester 19:13:09 * byte-salad refactors itself into human form 19:13:14 *** byte-salad is now known as fonsinchen 19:13:24 <SpComb> I guess I'm still going to do it, but my attitude towards it is going to be kind of destructive 19:13:43 <SpComb> trouble is, the course involves a long-term group project 19:13:47 <SpComb> ...writing code in C++ 19:13:48 <SpComb> ugh 19:14:23 <hylje> ew 19:14:45 <fonsinchen> iiggggh, humans! 19:15:26 <Belugas> yeah.. tell me about it... 19:15:41 * Belugas shakes his head and dives 19:23:33 <peter1138> BACK! 19:33:14 *** Purno [~Purno@5350931D.cable.casema.nl] has quit [Read error: Connection reset by peer] 19:36:27 *** Nev is now known as bleepy 19:46:04 <peter1138> http://svn.bucks.net/~petern/toolbar-dropdown.diff 19:46:18 <peter1138> 436 lines removed, 224 lines added... 19:46:43 *** Roujin [~Roujin@mnch-5d85e906.pool.einsundeins.de] has quit [Quit: HydraIRC -> http://www.hydrairc.com <- *I* use it, so it must be good!] 19:48:19 <peter1138> Hmm, whoops, it shows the 3rd road type :p 19:49:32 <Eddi|zuHause> why was that never finished? 19:53:07 *** nkx [~asd@x1-6-00-18-39-d3-e9-f6.k899.webspeed.dk] has joined #openttd 19:53:08 *** nekx [~asd@x1-6-00-18-39-d3-e9-f6.k899.webspeed.dk] has quit [Read error: Connection reset by peer] 19:56:15 <Belugas> nice, peter1138:) 19:56:17 *** nkx [~asd@x1-6-00-18-39-d3-e9-f6.k899.webspeed.dk] has quit [Read error: Connection reset by peer] 19:56:24 *** nekx [~asd@x1-6-00-18-39-d3-e9-f6.k899.webspeed.dk] has joined #openttd 19:57:39 <peter1138> Belugas, you think so? Cool. 19:57:56 <peter1138> Part of the aim was to have more easily customizable menus. 19:59:36 * Belugas is amused to see some of his comments and changes get deleted heheh... looks like you are good at cleaning his mess ;) 19:59:52 <peter1138> Hmm? 20:00:08 <Belugas> i worked a lot on the toolbar recently 20:00:16 <Belugas> mostly doing enums and such 20:00:17 <peter1138> Oh, did you? 20:00:20 <peter1138> Ah... 20:00:35 <peter1138> The scenario map button is the only one that needed attention, I think. 20:03:34 * Belugas nods 20:03:57 <Belugas> almost the only difference between the two toolbars 20:10:05 *** jni [~geetee@cs181040004.pp.htv.fi] has quit [Remote host closed the connection] 20:10:18 *** jni [~geetee@cs181040004.pp.htv.fi] has joined #openttd 20:11:14 *** nkx [~asd@x1-6-00-18-39-d3-e9-f6.k899.webspeed.dk] has joined #openttd 20:11:14 *** nekx [~asd@x1-6-00-18-39-d3-e9-f6.k899.webspeed.dk] has quit [Read error: Connection reset by peer] 20:13:09 <CIA-5> OpenTTD: peter1138 * r14008 /trunk/src/newgrf_gui.cpp: -Fix (r14004): NewGRF preset drop down list not working 20:14:33 <peter1138> TRUEBRAIN OH WHERE ART THOUGH 20:14:33 <CIA-5> OpenTTD: peter1138 * r14009 /trunk/src/newgrf_gui.cpp: -Cleanup (r14008): Bad whitespace... 20:22:40 *** KritiK [~Maxim@78-106-212-191.broadband.corbina.ru] has joined #openttd 20:24:46 *** [com]buster [~eternal@cust-03-55bf402e.adsl.scarlet.nl] has joined #openttd 20:24:55 <Eddi|zuHause> when "speed" is 85, which unit is that? 20:25:11 *** Vikthor [~Vikthor@snat1.spoje.net] has joined #openttd 20:25:52 <Rubidium> depends on the vehicle type IIRC 20:27:03 <Eddi|zuHause> it's in the rating calculation, nothing about vehicle types there 20:27:04 <Rubidium> and then in miles / 1.6 or miles / 3.2 20:27:35 <Eddi|zuHause> GoodsEntry::last_speed 20:28:08 <Eddi|zuHause> and of course it has no comments ;) 20:28:31 <Rubidium> then it is the raw speed of the vehicle 20:28:49 <frosch123> Eddi|zuHause: take a look at economy.cpp where it is assigned 20:28:51 <Rubidium> so for RVs and ships it yields more points per km/h than for trains 20:29:19 <Rubidium> hmm, or not 20:30:38 <Eddi|zuHause> it only makes adjustments to RV 20:32:03 <frosch123> 'max_speed' has different units depending on vehicle type 20:32:27 <frosch123> they should be those mentionen in newgrfspecs 20:32:48 <Eddi|zuHause> that's the problem... the information is all over the place... 20:33:04 <frosch123> <frosch123> they should be those mentionen in newgrfspecs <- except for aircraft 20:33:14 *** Zr40 [~zr40@120-12-ftth.onsnetstudenten.nl] has quit [Quit: Zr40] 20:33:40 <frosch123> Eddi|zuHause: not everywhere, just economy.cpp, newgrf.cpp, roadveh_cmd.cpp, ship_cmd.cpp, aircraft_cmd.cpp and train_cmd.cpp 20:34:26 <Eddi|zuHause> it's more than looking at a comment in station_base.h 20:35:03 <frosch123> how long shall that comment be? 20:35:58 <Eddi|zuHause> one line for each case... 20:36:19 <Eddi|zuHause> or a hint where the information would be found 20:36:23 * Rubidium assigns Eddi|zuHause to fix all documentation so we can document everything correctly 20:36:54 <Rubidium> cause apparantly fixing documentation when changing stuff is not enough 20:37:42 <frosch123> also comments that refer to values defined in other placed are usally out of sync with the code 20:39:35 *** flowOver [~J@S01060016e65abad7.gv.shawcable.net] has quit [Read error: Connection reset by peer] 20:39:44 <Eddi|zuHause> yes, i understand the dilemma ;) 20:42:52 *** nekx [~asd@x1-6-00-18-39-d3-e9-f6.k899.webspeed.dk] has joined #openttd 20:42:53 *** nkx [~asd@x1-6-00-18-39-d3-e9-f6.k899.webspeed.dk] has quit [Read error: Connection reset by peer] 20:43:45 <Eddi|zuHause> ge->last_age = _cur_year - u->build_year; <- there is a possible overflow, last_age is a byte 20:48:08 *** frosch123 [~frosch@frnk-590fcfe3.pool.einsundeins.de] has quit [Remote host closed the connection] 20:51:32 *** welshdragon [~vista@host86-137-66-208.range86-137.btcentralplus.com] has joined #openttd 20:55:03 <peter1138> Oh well, night night. 20:56:34 *** SmatZ41 [~Miranda@217-134-158-212.bluetone.cz] has joined #openttd 20:56:34 *** nekx [~asd@x1-6-00-18-39-d3-e9-f6.k899.webspeed.dk] has quit [Read error: Connection reset by peer] 20:56:41 *** nekx [~asd@x1-6-00-18-39-d3-e9-f6.k899.webspeed.dk] has joined #openttd 20:56:49 <SmatZ41> hello 20:57:19 <SmatZ41> unbelievable, free wifi hotspot here :-) 20:57:41 <SmatZ41> thiugh I have to be outside and it's quite cold here :-P 20:57:44 <Belugas> mmh...FooBar did a good job on commenting action00for bridges, but he fucked up a little bit here and there... 20:57:47 <Belugas> hey SmatZ 20:58:09 <SmatZ41> no place to land my notebook :-/ 20:58:57 *** SmatZ41 [~Miranda@217-134-158-212.bluetone.cz] has quit [] 21:02:55 *** fonsinchen is now known as fonso 21:02:56 *** nekx [~asd@x1-6-00-18-39-d3-e9-f6.k899.webspeed.dk] has quit [Read error: Connection reset by peer] 21:03:07 *** nekx [~asd@x1-6-00-18-39-d3-e9-f6.k899.webspeed.dk] has joined #openttd 21:07:59 *** FauxFaux [~faux@compsoc.sunion.warwick.ac.uk] has joined #openttd 21:15:43 *** SmatZ41 [~Miranda@217-134-158-212.bluetone.cz] has joined #openttd 21:15:45 <SmatZ41> hmm 21:15:53 *** Wezz6400_ [~Wezz6400@ndb.demon.nl] has joined #openttd 21:15:53 <SmatZ41> way too slow, 64kbps 21:16:13 <SmatZ41> I don't understand how I could live with 28.8 modem for years.. 21:18:15 *** fonso [~fonso@brln-d9bacd6d.pool.mediaWays.net] has left #openttd [Kopete 0.12.7 : http://kopete.kde.org] 21:21:56 *** Wolf01 is now known as Guest569 21:21:56 *** Wolfolo|AWAY [~wolf01@host98-181-dynamic.15-87-r.retail.telecomitalia.it] has joined #openttd 21:21:56 *** Wolfolo|AWAY is now known as Wolf01 21:21:58 *** nekx [~asd@x1-6-00-18-39-d3-e9-f6.k899.webspeed.dk] has quit [Read error: Connection reset by peer] 21:22:10 *** nekx [~asd@x1-6-00-18-39-d3-e9-f6.k899.webspeed.dk] has joined #openttd 21:22:55 *** Wezz6400 [~Wezz6400@ndb.demon.nl] has quit [Ping timeout: 480 seconds] 21:28:12 *** SmatZ41 [~Miranda@217-134-158-212.bluetone.cz] has quit [Ping timeout: 480 seconds] 21:29:22 *** Guest569 [~wolf01@host98-181-dynamic.15-87-r.retail.telecomitalia.it] has quit [Ping timeout: 480 seconds] 21:31:50 *** rortom [~rortom@p57B7C667.dip.t-dialin.net] has joined #openttd 21:32:33 <Belugas> bye guys 21:41:10 <ln> bye girl 21:51:58 *** TinoM [~Tino@i59F56D13.versanet.de] has quit [Quit: Verlassend] 21:53:47 *** nkx [~asd@x1-6-00-18-39-d3-e9-f6.k899.webspeed.dk] has joined #openttd 21:53:47 *** nekx [~asd@x1-6-00-18-39-d3-e9-f6.k899.webspeed.dk] has quit [Read error: Connection reset by peer] 21:54:53 *** [com]buster [~eternal@cust-03-55bf402e.adsl.scarlet.nl] has quit [Quit: Operator, give me an exit] 22:09:12 <CIA-5> OpenTTD: truebrain * r14010 /branches/noai/ (5 files in 2 dirs): [NoAI] -Add: added AIAirport::GetAirportType (Yexo) 22:40:19 *** ecke1 [~ecke@213.195.202.130] has quit [Quit: ecke1] 22:43:24 *** sid3windr [luser@bastard-operator.from-hell.be] has joined #openttd 22:46:39 <sid3windr> heya - been browsing through the forums and such, I was wondering about a (perhaps silly) feature, multiple monitor support ? It would be awesome if openttd could run across both my monitors... :) 22:47:11 <Bjarni> you want stereo vision? 22:47:45 <sid3windr> no, a 2560x1024 world :) 22:47:47 <rortom> i think multi monitor support 22:47:53 <rortom> i want that too :\ 22:47:57 <sid3windr> I like to have some graphs open and such 22:47:57 <rortom> its working under linux 22:48:03 <rortom> but not under window 22:48:05 <sid3windr> even just that would be awesome to put up on secondary monitor 22:48:18 <TinoDidriksen> If you use windowed mode and make the resolution large enough, depending on OS setup, it would span across monitors? 22:48:22 <Bjarni> you are in luck 22:48:22 <sid3windr> yeah, I guessed it would work under linux 22:48:26 <Bjarni> it's open source 22:48:30 <sid3windr> TinoDidriksen: good point! 22:48:32 <Bjarni> you are able to code this yourself 22:48:36 <rortom> haha :p 22:48:39 <sid3windr> Bjarni: how cliché 22:48:49 <Bjarni> but true 22:48:52 *** Farden [~jk3farden@ram94-7-82-232-189-236.fbx.proxad.net] has quit [Quit: ( www.nnscript.com :: NoNameScript 4.2 :: www.regroup-esports.com )] 22:48:53 <rortom> TinoDidriksen: it wont reach 22:48:53 <sid3windr> except not really 22:48:55 <sid3windr> :) 22:49:10 <ben_goodger> Bjarni: that's almost never a useful response. nobody ever asks for features who can write them by themselves 22:49:13 <sid3windr> given the source code and a compiler, it does not automatically mean a person is able to do it. 22:49:15 <Bjarni> I'm not coding full screen support for multiple monitors for you 22:49:27 <Bjarni> it would be a huge task and I wouldn't know where to start :s 22:49:30 <sid3windr> that's not what I asked either, or at least, not directly :) 22:49:39 <sid3windr> I was just wondering if there was a place to "officially suggest" it 22:49:54 <sid3windr> as I have no clue how to do it either 22:50:10 <sid3windr> I saw the suggestion list in the wiki but it didn't look like someting I'd just go and edit right away 22:50:27 <Bjarni> we have a suggestion list on the wiki? 22:50:33 <sid3windr> rortom: you can't get the windowed version large enough? or what do you mean with "it doesn't reach" 22:50:34 <Bjarni> hehe 22:50:37 <Bjarni> never read it 22:50:47 <Bjarni> which makes me wonder how useful it is 22:50:48 <sid3windr> Bjarni: http://wiki.openttd.org/index.php/Requested_features 22:50:52 <sid3windr> not exactly "suggestion list" 22:50:59 <sid3windr> rather stuff people are working on already 22:51:08 <rortom> sid3windr: it fits for 1280x1024 for 1 monitor and 1/4 of the second, thats the max under windows for strange reasons 22:51:13 <sid3windr> so "proper" way is to discuss it in the forum or something? 22:51:24 <sid3windr> rortom: oh, that's a pity.. 22:51:27 <rortom> yes 22:51:36 <rortom> there must be a reason 22:51:43 <Bjarni> but you can alter a define somewhere to allow the window to be bigger 22:51:56 <rortom> oh, thanks for the hint :D 22:52:04 <sid3windr> :) 22:52:07 <rortom> *looking at the code* 22:52:09 <Bjarni> ludde added this define for some reason but he never told why 22:52:23 <rortom> oh 22:52:28 <rortom> great ;) 22:53:00 <Bjarni> some people have tried to increase it and it appeared to work but officially we don't know if it will have any sideeffects 22:53:00 <sid3windr> mmm. I was just wondering how openttd would look on the testmonitor we had at work for a short while 22:53:04 <rortom> do you have any idea where i could find it? 22:53:24 <sid3windr> (3840x2560) 22:53:29 <Rubidium> just use a sufficiently new version OpenTTD for that 22:53:35 <sid3windr> I'll take a look at the source for that too 22:53:45 <sid3windr> then find out how to compile it on windows. 22:53:49 <Rubidium> sid3windr: try a recent nightly first 22:53:54 <Bjarni> Rubidium: we got rid of that define? 22:53:55 <sid3windr> okay, will do 22:55:58 <rortom> *testig if the limitation is still there* 22:56:43 *** Digitalfox [~Digitalfo@bl10-221-158.dsl.telepac.pt] has joined #openttd 22:57:09 * sid3windr will do that tomorrow, off to bed now 22:57:16 <sid3windr> thanks for the tip :) 22:59:08 <rortom> yay 22:59:09 <rortom> :D 22:59:12 <rortom> its working :D 22:59:16 <rortom> thank you all :D 22:59:46 * Rubidium wonders why nobody noticed it until I told I removed the limitation 23:00:27 <Bjarni> I would have if you had donated a monitor big enough for me to notice :P 23:00:41 <Rubidium> tss... 23:00:50 <Rubidium> 1920x1200 is more than enough for a laptop! 23:08:01 *** bleepy [bleepy@5ad1d1af.bb.sky.com] has quit [Ping timeout: 480 seconds] 23:10:16 *** Volley [~worf@84.119.55.244] has joined #openttd 23:11:33 *** nekx [~asd@x1-6-00-18-39-d3-e9-f6.k899.webspeed.dk] has joined #openttd 23:11:33 *** nkx [~asd@x1-6-00-18-39-d3-e9-f6.k899.webspeed.dk] has quit [Read error: Connection reset by peer] 23:11:46 <Wolf01> 'night 23:11:50 *** Wolf01 [~wolf01@host98-181-dynamic.15-87-r.retail.telecomitalia.it] has quit [Quit: Once again the world is quick to bury me.] 23:12:18 *** Vikthor [~Vikthor@snat1.spoje.net] has quit [Quit: Leaving.] 23:22:34 *** Volley [~worf@84.119.55.244] has quit [Remote host closed the connection] 23:29:59 *** Bjarni [~Bjarni@0x50a46ad5.virnxx14.dynamic.dsl.tele.dk] has quit [Quit: Leaving] 23:37:19 *** David [~David@cpe-72-231-156-14.nycap.res.rr.com] has joined #openttd 23:37:24 <David> !playercount 23:37:25 *** David was kicked from #openttd by DorpsGek [Wrong channel. Retry in #openttdcoop.] 23:42:12 *** dlunch [~dlunch@121.185.116.137] has quit [Ping timeout: 480 seconds] 23:44:35 *** Progman [~progman@p57A1E2BF.dip.t-dialin.net] has quit [Remote host closed the connection] 23:50:06 *** rortom [~rortom@p57B7C667.dip.t-dialin.net] has quit [] 23:59:25 <ln> sid3windr: i've run OTTD in fullscreen on two monitors.