Log for #openttd on 6th August 2008:
Times are UTC Toggle Colours
00:18:05  *** nekx [] has joined #openttd
00:18:06  *** nkx [] has quit [Read error: Connection reset by peer]
00:25:05  *** KritiK [] has quit [Quit: Leaving]
00:32:36  *** Zahl [] has quit [Read error: Connection reset by peer]
00:32:44  *** Zahl [] has joined #openttd
00:36:25  *** Eddi|zuHause [] has quit []
00:36:46  *** Eddi|zuHause [] has joined #openttd
00:37:03  *** nekx [] has quit [Read error: Connection reset by peer]
00:37:16  *** nekx [] has joined #openttd
00:39:17  *** Wezz6400 [] has quit [Quit: Zzz]
00:43:43  *** nkx [] has joined #openttd
00:43:44  *** nekx [] has quit [Read error: Connection reset by peer]
00:44:49  *** Chrill [] has joined #openttd
00:55:59  *** ben_goodger [] has quit [Ping timeout: 480 seconds]
00:56:29  *** ben_goodger [] has joined #openttd
01:02:06  *** Chrill [] has quit [Quit: Oh chrill is one sexy beast]
01:09:26  *** nicfer [~Administr@] 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` [] 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 [] has joined #openttd
01:18:31  *** nkx [] has quit [Read error: Connection reset by peer]
01:39:34  *** ecke [~ecke@] has quit [Read error: Connection reset by peer]
02:16:00  *** ecke [~ecke@] has joined #openttd
02:21:28  *** nekx [] has quit [Read error: Connection reset by peer]
02:21:38  *** nekx [] has joined #openttd
02:24:51  *** Zahl [] has quit [Ping timeout: 480 seconds]
02:39:15  *** Progman [] has quit [Remote host closed the connection]
02:58:31  *** glx [] has quit [Quit: bye]
03:02:44  *** elmex_ [] has joined #openttd
03:07:42  *** elmex [] has quit [Ping timeout: 480 seconds]
03:08:11  *** elmex_ is now known as elmex
03:25:04  *** nicfer [~Administr@] has left #openttd []
03:27:53  *** welshdragon is now known as welshdra-gone
03:38:27  *** nkx [] has joined #openttd
03:38:28  *** nekx [] 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 [] has quit [Ping timeout: 480 seconds]
04:35:17  *** nekx [] has joined #openttd
04:35:17  *** nkx [] has quit [Read error: Connection reset by peer]
04:53:42  *** Gekz [] has joined #openttd
04:54:12  *** Reemo [] has quit [Quit: - das Wiki rund um's Thema Lager und Logistik]
04:54:13  *** nekx [] has quit [Read error: Connection reset by peer]
04:54:17  *** nekx [] has joined #openttd
05:07:46  *** Eddi|zuHause [] has quit [Remote host closed the connection]
05:08:00  *** Eddi|zuHause [] has joined #openttd
05:13:21  *** nkx [] has joined #openttd
05:13:21  *** nekx [] has quit [Read error: Connection reset by peer]
05:25:48  *** ecke [~ecke@] has quit [Read error: Connection reset by peer]
05:29:18  *** nC[dek] [ng0L@] has joined #openttd
05:37:39  *** nekx [] has joined #openttd
05:37:39  *** nkx [] has quit [Read error: Connection reset by peer]
05:43:21  *** ecke [~ecke@] has joined #openttd
06:00:14  *** bleepy [] has joined #openttd
06:09:29  *** ecke [~ecke@] 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 [] has joined #openttd
06:32:09  *** Sir-Bob [] 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@] has joined #openttd
06:50:34  <peter1138> Nope.
06:51:04  *** nC[dek] [ng0L@] has quit []
06:52:37  *** Wolf01 [] has joined #openttd
06:53:02  <Wolf01> hello
07:02:49  *** nkx [] has joined #openttd
07:02:50  *** nekx [] 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 [] has quit [Ping timeout: 480 seconds]
07:12:27  *** Wolf01 [] has joined #openttd
07:22:58  *** Marduuhin [] has quit [Ping timeout: 480 seconds]
07:23:50  *** Marduuhin [] has joined #openttd
07:28:53  *** Farden [] has joined #openttd
07:32:18  *** KillaloT [] 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 [] has joined #openttd
07:45:29  *** Wolf01 [] has quit [Ping timeout: 480 seconds]
08:11:43  *** Zr40 [] 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 [] has quit [Ping timeout: 480 seconds]
08:20:50  *** Sir-Bob [] has joined #openttd
08:21:03  *** Digitalfox [] 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 [] 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 [] has joined #openttd
08:34:51  *** lobster_MB [] has joined #openttd
08:38:35  <Celestar> like the one I have replaced (=
08:40:47  *** Brianetta [] 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>
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@] has joined #openttd
09:03:39  *** ecke [~ecke@] 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 [] has quit [Quit: ChatZilla 0.9.83 [Firefox 3.0.1/2008070208]]
09:11:32  *** Doorslammer [] has joined #openttd
09:13:26  *** Sir-Bob [] has joined #openttd
09:16:24  *** fonso [] 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 [] has joined #openttd
09:19:06  *** grumbel [] 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 [] 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 ( or station capacities (
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>'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 [] 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 [] 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 ( and 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 [] 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 [] 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 [] 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 [] has quit [Ping timeout: 480 seconds]
10:18:57  *** ben_goodger [] 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 [] has quit [Quit: Leaving]
10:35:40  *** Wezz6400 [] has joined #openttd
10:37:48  *** Tommy [] has joined #openttd
10:41:06  *** Tommy [] 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 [] 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:
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 [] has joined #openttd
11:00:19  *** curson [] has joined #openttd
11:01:47  <fonso> My work on diagonal levelling is this patch:
11:02:30  <blathijs> fonso: How will you handle the "station full" issue?
11:02:30  *** shodan [] 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>
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 [] 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> <- 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 [] 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 [] 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 [] has joined #openttd
11:33:54  <Bjarni>
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 [] has quit [Read error: Connection reset by peer]
11:38:53  <Eddi|zuHause> Bjarni: ;)
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 [] 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>
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="'+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 [] has joined #openttd
11:54:09  *** mode/#openttd [+v glx] by ChanServ
11:55:52  *** Roujin [] 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 [] 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:
12:04:39  <Celestar> glx: the diagonal level tool sounds horrible helpful
12:04:42  <Celestar> Roujin: checking
12:04:44  *** m_ax [] has joined #openttd
12:04:49  <Eddi|zuHause> <- 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:
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 [] has joined #openttd
12:16:57  *** nkx [] has quit [Read error: Connection reset by peer]
12:18:28  <Roujin> if you're interested,
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 [] has joined #openttd
12:23:20  *** nekx [] 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 [] 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 [] has quit [Read error: Connection reset by peer]
12:37:09  *** nekx [] 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 [] has joined #openttd
12:50:56  *** bleepy [] has quit [Ping timeout: 480 seconds]
12:55:26  <Celestar> Macros == eeeeevil
12:58:31  *** ben_goodger [] 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 [] has joined #openttd
13:03:05  *** dlunch [~dlunch@] 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@] 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 [] 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 [] 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 [] 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 [] has joined #openttd
13:30:05  *** mode/#openttd [+v tokai] by ChanServ
13:32:07  *** rortom [] 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 [] 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>
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>
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 [] 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 [] has joined #openttd
14:02:21  *** nekx [] 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 [] 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
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:
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 [] has joined #openttd
14:38:23  *** Jan [] 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 [] 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
15:08:49  <SpComb> note that I've read the FQA, but not the FAQ
15:10:40  *** m_ax [] 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 [] has joined #openttd
15:16:54  *** svippy [] 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 [] has joined #openttd
15:30:34  *** AntB [] has joined #openttd
15:45:02  <fonso> I renamed the variables for diagonal levelling:
15:45:42  <fonso> Should I use a macro for diagonal tile walking?
15:46:27  *** nekx [] has joined #openttd
15:46:27  *** nkx [] has quit [Read error: Connection reset by peer]
15:48:34  *** rortom [] 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 [] has joined #openttd
15:57:06  *** nekx [] has quit [Read error: Connection reset by peer]
15:57:22  *** AntB [] 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 [] 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 [] 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> <- 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 [] 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 [] has joined #openttd
16:22:26  *** nkx [] has quit [Read error: Connection reset by peer]
16:25:05  <fonso> thanks
16:29:31  *** Brianetta [] has quit [Quit: TschÌß]
16:29:42  *** nekx [] has quit [Read error: Connection reset by peer]
16:29:55  *** nekx [] has joined #openttd
16:32:03  *** fonso [] has left #openttd [Kopete 0.12.7 :]
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 [] 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 [] has quit [Read error: Connection reset by peer]
16:50:53  <Belugas> (if it's still there..)
16:50:58  *** nekx [] has joined #openttd
16:51:00  <Belugas> or filtering
16:58:39  *** Wezz6400 [] has joined #openttd
16:59:35  *** nkx [] has joined #openttd
16:59:36  *** nekx [] has quit [Read error: Connection reset by peer]
17:01:49  *** nekx [] has joined #openttd
17:01:49  *** nkx [] has quit [Read error: Connection reset by peer]
17:03:59  *** Singaporekid [] 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 [] 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> <- 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> <-- 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:
18:08:36  <Rubidium> if only the server would allow connecting from here
18:09:47  <Ammler> sry, wrong link:
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>
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 [] 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 [] has quit [Quit: mikl]
18:36:51  *** Progman [] has joined #openttd
18:40:52  *** fonso [] has joined #openttd
18:44:51  *** Vessajono [] 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> <-- 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@] 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 [] has left #openttd [Kopete 0.12.7 :]
19:10:08  <SpComb> that confused him
19:10:14  *** byte-salad [] 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 [] has quit [Read error: Connection reset by peer]
19:36:27  *** Nev is now known as bleepy
19:46:04  <peter1138>
19:46:18  <peter1138> 436 lines removed, 224 lines added...
19:46:43  *** Roujin [] has quit [Quit:  HydraIRC -> <- *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 [] has joined #openttd
19:53:08  *** nekx [] has quit [Read error: Connection reset by peer]
19:56:15  <Belugas> nice, peter1138:)
19:56:17  *** nkx [] has quit [Read error: Connection reset by peer]
19:56:24  *** nekx [] 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 [] has quit [Remote host closed the connection]
20:10:18  *** jni [] has joined #openttd
20:11:14  *** nkx [] has joined #openttd
20:11:14  *** nekx [] 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 [] has joined #openttd
20:24:46  *** [com]buster [] has joined #openttd
20:24:55  <Eddi|zuHause> when "speed" is 85, which unit is that?
20:25:11  *** Vikthor [] 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 [] 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 [] has quit [Read error: Connection reset by peer]
20:39:44  <Eddi|zuHause> yes, i understand the dilemma ;)
20:42:52  *** nekx [] has joined #openttd
20:42:53  *** nkx [] 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 [] has quit [Remote host closed the connection]
20:51:32  *** welshdragon [] has joined #openttd
20:55:03  <peter1138> Oh well, night night.
20:56:34  *** SmatZ41 [] has joined #openttd
20:56:34  *** nekx [] has quit [Read error: Connection reset by peer]
20:56:41  *** nekx [] 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 [] has quit []
21:02:55  *** fonsinchen is now known as fonso
21:02:56  *** nekx [] has quit [Read error: Connection reset by peer]
21:03:07  *** nekx [] has joined #openttd
21:07:59  *** FauxFaux [] has joined #openttd
21:15:43  *** SmatZ41 [] has joined #openttd
21:15:45  <SmatZ41> hmm
21:15:53  *** Wezz6400_ [] 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 [] has left #openttd [Kopete 0.12.7 :]
21:21:56  *** Wolf01 is now known as Guest569
21:21:56  *** Wolfolo|AWAY [] has joined #openttd
21:21:56  *** Wolfolo|AWAY is now known as Wolf01
21:21:58  *** nekx [] has quit [Read error: Connection reset by peer]
21:22:10  *** nekx [] has joined #openttd
21:22:55  *** Wezz6400 [] has quit [Ping timeout: 480 seconds]
21:28:12  *** SmatZ41 [] has quit [Ping timeout: 480 seconds]
21:29:22  *** Guest569 [] has quit [Ping timeout: 480 seconds]
21:31:50  *** rortom [] has joined #openttd
21:32:33  <Belugas> bye guys
21:41:10  <ln> bye girl
21:51:58  *** TinoM [] has quit [Quit: Verlassend]
21:53:47  *** nkx [] has joined #openttd
21:53:47  *** nekx [] has quit [Read error: Connection reset by peer]
21:54:53  *** [com]buster [] 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@] has quit [Quit: ecke1]
22:43:24  *** sid3windr [] 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 [] has quit [Quit: ( :: NoNameScript 4.2 :: )]
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:
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 [] 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 [] has quit [Ping timeout: 480 seconds]
23:10:16  *** Volley [~worf@] has joined #openttd
23:11:33  *** nekx [] has joined #openttd
23:11:33  *** nkx [] has quit [Read error: Connection reset by peer]
23:11:46  <Wolf01> 'night
23:11:50  *** Wolf01 [] has quit [Quit: Once again the world is quick to bury me.]
23:12:18  *** Vikthor [] has quit [Quit: Leaving.]
23:22:34  *** Volley [~worf@] has quit [Remote host closed the connection]
23:29:59  *** Bjarni [] has quit [Quit: Leaving]
23:37:19  *** David [] 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@] has quit [Ping timeout: 480 seconds]
23:44:35  *** Progman [] has quit [Remote host closed the connection]
23:50:06  *** rortom [] has quit []
23:59:25  <ln> sid3windr: i've run OTTD in fullscreen on two monitors.

Powered by YARRSTE version: svn-trunk