Back to Home / #openttd / 2008 / 08 / Prev Day | Next Day
#openttd IRC Logs for 2008-08-06

---Logopened Wed Aug 06 00:00:35 2008
00:01<CIA-5>OpenTTD: belugas * r14003 /trunk/src/ (cheat_gui.cpp industry_gui.cpp): -Codechange: Replace numbers with Colours enum opn some DrawArrowButtons calls
00:25-!-Gekz [] has quit [Ping timeout: 480 seconds]
00:35-!-nekx [] has joined #openttd
00:35-!-nkx [] has quit [Read error: Connection reset by peer]
00:53-!-Gekz [] has joined #openttd
00:54-!-Reemo [] has quit [Quit: - das Wiki rund um's Thema Lager und Logistik]
00:54-!-nekx [] has quit [Read error: Connection reset by peer]
00:54-!-nekx [] has joined #openttd
01:07-!-Eddi|zuHause [] has quit [Remote host closed the connection]
01:08-!-Eddi|zuHause [] has joined #openttd
01:13-!-nkx [] has joined #openttd
01:13-!-nekx [] has quit [Read error: Connection reset by peer]
01:25-!-ecke [~ecke@] has quit [Read error: Connection reset by peer]
01:29-!-nC[dek] [ng0L@] has joined #openttd
01:37-!-nekx [] has joined #openttd
01:37-!-nkx [] has quit [Read error: Connection reset by peer]
01:43-!-ecke [~ecke@] has joined #openttd
02:00-!-bleepy [] has joined #openttd
02:09-!-ecke [~ecke@] has quit [Ping timeout: 480 seconds]
02:10<nC[dek]>is it for developer to translate any game server?
02:10<Celestar>peter1138: up already? (=
02:10<Celestar>nC[dek]: ??
02:10<nC[dek]>just ask
02:12<Fennec>Your question is not clear to us.
02:12<Fennec>Are you inquiring whether it is possible for a developer to translate a portion of the application?
02:12<Celestar>nC[dek]: ERROR: cannot parse question
02:13<nC[dek]>i was wonder if are you guys working on translation such as game server?
02:13<Fennec>ah. :)
02:13<nC[dek]>(Translator: translator2, Gameservers: servers,
02:14<Celestar>Mihamix did the webtranslator
02:16<nC[dek]>i see
02:18<@peter1138>I still don't understand the question, heh
02:21<nC[dek]>peter1138: forget it :P
02:26<Celestar>LoadUnloadVehicle is the actual loading process
02:27<Celestar>VehiclePayment only determines the payment, but doesn't actually move the cargo
02:27<@peter1138>They have to 'match' though :o
02:27*Celestar goes cleaning up VehiclePayment
02:27<Celestar>yes, they don't currently this is what I'm fixing now
02:28-!-Sir-Bob [] has joined #openttd
02:32-!-Sir-Bob [] has quit []
02:35<Celestar>hence we have disagreement in the payments from what I can tell
02:40<@peter1138>What's the best way to clean up Window "delete this" mess?
02:46<Celestar>does it have anything to do with cargodest (=
02:48-!-ecke [~ecke@] has joined #openttd
02:51-!-nC[dek] [ng0L@] has quit []
02:52-!-Wolf01 [] has joined #openttd
03:02-!-nkx [] has joined #openttd
03:02-!-nekx [] has quit [Read error: Connection reset by peer]
03:07<Celestar>peter1138: doing some progress with the cleanup
03:10<CIA-5>OpenTTD: peter1138 * r14004 /trunk/src/ (player_gui.cpp widgets/dropdown.cpp widgets/dropdown_type.h):
03:10<CIA-5>OpenTTD: -Codechange: Clean of drop down lists.
03:10<CIA-5>OpenTTD: Move empty item drawing to base ListItem Draw() function.
03:10<CIA-5>OpenTTD: Remove String() from base class.
03:10<CIA-5>OpenTTD: Pass correct width to Draw().
03:10-!-Wolf01 [] has quit [Ping timeout: 480 seconds]
03:12-!-Wolf01 [] has joined #openttd
03:22-!-Marduuhin [] has quit [Ping timeout: 480 seconds]
03:23-!-Marduuhin [] has joined #openttd
03:28-!-Farden [] has joined #openttd
03:32-!-KillaloT [] has joined #openttd
03:33<Celestar>sometimes I don't get this debugger and/or compiler
03:40-!-TinoM [] has joined #openttd
03:45-!-Wolf01 [] has quit [Ping timeout: 480 seconds]
04:11-!-Zr40 [] has joined #openttd
04:18<@peter1138>Celestar, nearly done the sorting. Just need to add the GUI elements.
04:19<@peter1138>Although I've got work @ work to do...
04:20-!-bleepy [] has quit [Ping timeout: 480 seconds]
04:20-!-Sir-Bob [] has joined #openttd
04:21-!-Digitalfox [] has quit [Quit: Leaving]
04:21<Celestar>peter1138: awesome
04:21<Celestar>peter1138: I got work too, I'm done with the payment repair
04:21<Celestar>peter1138: pull and see if economy.cpp:VehiclePayment is more readable now (=
04:24<@peter1138>I'll check the repo.
04:24<@peter1138>Cannot pull as I've not committed my GUI changes yet.
04:25<Celestar>I see
04:26<@peter1138>Heh, acceptance changes invalidates the cache multiple times. I guess that will necessary when it is more specific.
04:27<@peter1138>Now checking the appropriate change ;)
04:28<@peter1138>payed -> paid ;)
04:28<@peter1138>That looks better.
04:29-!-lobster_MB [] has quit [Ping timeout: 480 seconds]
04:31<Celestar>I don't like some of the if-magic we have in the code
04:33<@peter1138>Which if-magic?
04:34-!-Vikthor [] has joined #openttd
04:34-!-lobster_MB [] has joined #openttd
04:38<Celestar>like the one I have replaced (=
04:40-!-Brianetta [] has joined #openttd
04:42<@peter1138>if (!cp->paid_for &&
04:42<@peter1138>- cp->source != last_visited &&
04:42<@peter1138>- (cp->target == st->index || cp->target == INVALID_STATION) &&
04:42<@peter1138>- HasBit(ge->acceptance_pickup, GoodsEntry::ACCEPTANCE) &&
04:42<@peter1138>- ((front_v->current_order.GetUnloadType() & OUFB_TRANSFER) == 0 )
04:42<@peter1138>Like that one you mean? :)
04:42<@peter1138>It is quite horrible.
04:44<@peter1138>What should we do with the small map view, regarding showing transport types?
04:45<@peter1138>We kind of want both cargo type and vehicle type toggles, but that'll complicate it a lot.
04:46<Brianetta>Use the colours from the payment graph map, and make the routes and stations in that colour
04:46<Brianetta>If there's more than one, borrow from Harry Beck
04:46<Celestar>Harry Beck?
04:49<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...
04:49<@peter1138>That's one possibility too...
04:50<Celestar>that's a good one, so we won't have any empty button
04:53<Eddi|zuHause>only problem is that you might want to filter for both, e.g. show the transport type of the passenger network only..
04:56<Celestar>peter1138'll find a solution, I'm optimistic
04:57<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
04:57<Celestar>and nettesting
05:01<Celestar>and some "todo" and "XXX" in the code
05:03-!-ecke1 [~ecke@] has joined #openttd
05:03-!-ecke [~ecke@] has quit [Read error: Connection reset by peer]
05:05<Celestar>and then we might be good to go :D
05:07-!-Sir-Bob [] has quit [Quit: ChatZilla 0.9.83 [Firefox 3.0.1/2008070208]]
05:11-!-Doorslammer [] has joined #openttd
05:13-!-Sir-Bob [] has joined #openttd
05:16-!-fonso [] has joined #openttd
05:16<Forked>good morning
05:18<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?
05:18-!-bleepy [] has joined #openttd
05:19-!-grumbel [] has joined #openttd
05:20<Celestar>currently, all the en-route packets are still delivered, but no new packets generated
05:20<Celestar>(which isn't too stupid anyway imho. I mean the people already bought their tickets)
05:20<Celestar>but then again, the power station you're delivering to is no longer there.
05:21<Celestar>we can also just discard the packets
05:23<Celestar>or deliver and get no payment
05:24<Noldo>generationg new target seems best IMO
05:26-!-grumbel [] has quit [Quit: Client exiting]
05:26<@peter1138>Make it a patch option for each cargo type!
05:26<@peter1138>You can never have enough options ;)
05:26<@peter1138>(Okay, maybe not :P)
05:27<Ammler>what would you do with the packets, if you remove the destination station?
05:28<Ammler>you could handle it like that
05:28<@peter1138>Isn't that exactly what was just mentioned?
05:29<@peter1138>Removing a station means its acceptance changes ;)
05:29<Ammler>well, if acceptance changes, you could still deliver it, but not, if the station disabpeard
05:29<Celestar>hm .. Ammler is raising a valid question
05:29<Celestar>because now, the cargopackets are just moved around forever
05:29<Celestar>well, actually not
05:30<Celestar>they're dumped at one station until they expire
05:30<Celestar>because UseVehicle will never return true
05:30<Celestar>which is pretty elegant (=
05:31<Celestar>because if the station becomes valid again, they're boarded again
05:31<Ammler>but that has a timeout?
05:31<@peter1138>That's undesirable.
05:32<@peter1138>The new station could belong to another player.
05:33<Celestar>peter1138: than they're not boarded (=
05:33<Celestar>I'm not sure whether the packet will expire at some station with a very right rating
05:33<blathijs>Can you actually take over a station from another player?
05:33<Celestar>high rating
05:34<Celestar>blathijs: no, not really
05:34<Celestar>but you can take over a station index from another player
05:34<Eddi|zuHause>i'd say select new destination
05:34<@peter1138>blathijs, reusing a station id, that's all.
05:35<Celestar>peter1138: which is no problem, in that case the orders to that station will have been removed
05:35<@peter1138>What about things like ECS/PBI where acceptance can change a lot...
05:35<Celestar>I'd almost say discard
05:35<Eddi|zuHause>discard is a bad idea, imho
05:36<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"
05:36<Ammler>sometimes, I built "excess"-transport from those lines, which tansport the cargo to an other station (coal from steel mill to power supply)
05:37<Celestar>we *could* find a nearby station
05:37<blathijs>I think realism is hardly relevant in this situation
05:37<Eddi|zuHause>for certain definitions of "nearby" ;)
05:37<Celestar>blathijs: so what's wrong about delivering the packets anyway?
05:38<blathijs>Celestar: But to a different "nearby" station you mean?
05:38<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
05:38<fonso>Would anyone like to discuss diagonal levelling ( or station capacities (
05:38<Celestar>hey fonso
05:38<Celestar>I like diagonal levelling
05:39<fonso>Did you try it?
05:39<Eddi|zuHause>this "deliver anyway" would kinda get in the way with that stockpiling idea of PBI/ECS
05:39<Celestar>someone beside me should review the code.
05:39<fonso>Well ... who?
05:39<Eddi|zuHause>because they are meant so that you can't just deliver everything there
05:39<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
05:40<blathijs>What is this PBI/ECS thing?
05:40<Eddi|zuHause>Celestar: no, only when the cargopacket is actually touced
05:40<Celestar>Eddi|zuHause: new packets are not generated if the acceptance goes off
05:40<Ammler>Eddi|zuHause: they will fill the stockpile at the station then
05:40<Eddi|zuHause>i.e. when it wants to decide that it gets loaded/unloaded, and finds that the desired target is not available anymore
05:41<Celestar>Ammler: nope, currently they're discarded at the final station
05:41<Ammler>(and need to wait until industry accept again or for transport ot an other industry)
05:41<Eddi|zuHause>blathijs: newgrf industries
05:42<Ammler>Celestar: if you set "unload"?
05:42<Ammler>or shouldn't that be used with cargo dest anymore?
05:43<Celestar>Ammler: it can.
05:44<Celestar>Ammler: but it just forces the vehicle to dump all cargo to the station, even if it would be better to remain onboard
05:44<Celestar>Ammler: if the cargo is destined for the station, it is delivered anyway
05:44<Ammler>but you say, they are discarded currenty, :-/
05:45<Eddi|zuHause>Ammler: when the acceptance changes, the stockpile is already full, so all subsequent cargo needs rerouting, until the stockpile reduces
05:45<Celestar>well, cargopackets are ALWAYS discarded at their final destinations
05:45<Celestar>delete cp; :)
05:45-!-Progman [] has joined #openttd
05:46<Celestar>without routing they're discarded as soon as they are unloaded at an accepting stations and the vehicle has the Transfer flag unset
05:46<Ammler>Eddi|zuHause: stockpile of the station...
05:47-!-Singaporekid [] has joined #openttd
05:48<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?
05:48<@peter1138>wouldn't *you* ;p
05:49<@peter1138>So unload anyway...
05:49<Ammler>but you might not get paid for it :-)
05:49<@peter1138>And the only make new destinations if the station is removed?
05:49<Celestar>we just need a decision
05:49<Celestar>what to do if 1) station doesn't accept cargo, and 2) station goes out-of-scope
05:50<@peter1138>Hmm, depends on why it has stopped accepting :o
05:50<@peter1138>Maybe we should make it a (single) configuration option after all...
05:51<@peter1138>a) pick new destination b) deliver anyway c) crash and burn
05:51<Ammler>can you detect, if the industry still is there?
05:52<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
05:52<fonso>n cargo destinations are finished. I'm more interested in the interaction with the newgrf system there.
05:52<Ammler>so you could see, if it is because of stockpile limits or if the industry disapeard)
05:56<Celestar>fonso: I think Rubidium peter1138 and Belugas are your best candidates
05:57<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
05:57<Celestar>Ammler: this should be done by different flags in the GoodsEntry
05:59<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.
06:01<Celestar>awar for an hour (=
06:01<Celestar>cu later
06:02-!-grumbel [] has joined #openttd
06:03<@peter1138>fonso, per cargo type?
06:03<fonso>that's one of the questions
06:03<fonso>I could do both
06:04<fonso>either define everything by cargo type or define only one limit for all cargo
06:04<@peter1138>Is it for pickup or dropoff?
06:05<fonso>ah no
06:05<fonso>I misunderstood
06:05<fonso>you can drop off cargo if the station is full, if the cargo is consumed immediately
06:05<fonso>but you can't transfer anything then
06:06<fonso>or "store" at the station
06:06-!-Roujin [] has joined #openttd
06:06<fonso>the main function however is limiting cargo delivered to the station by industries and houses
06:07<@peter1138>So it's for pickup.
06:10<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
06:10<@peter1138>Ah ha
06:11<@peter1138>See, we used to have the 4096 limit :D
06:11<@peter1138>But basically you want a larger station to have a larger limit.
06:12<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.
06:12<fonso>And yes, the limit is per tile.
06:15-!-Wolf01 [] has joined #openttd
06:15<fonso>"bus 10" is obviously bus2 in decimal
06:16<Wolf01>hello again... maybe now I'm here to stay
06:17-!-ben_goodger [] has quit [Ping timeout: 480 seconds]
06:18-!-ben_goodger [] has joined #openttd
06:29<Forked>urgh, is there any way to clear a reservation on a station track, without removing that piece of station?
06:30<Phantasm>Anyone have multiple CPUs and Windows? (Multiple cores alone does not count!)
06:31<Forked>just two cores :\
06:33<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?)
06:33<Eddi|zuHause>Forked: i'm afraid there is not
06:34-!-Singaporekid [] has quit [Quit: Leaving]
06:35-!-Wezz6400 [] has joined #openttd
06:37-!-Tommy [] has joined #openttd
06:41-!-Tommy [] has left #openttd []
06:43<@Bjarni><Phantasm> Anyone have multiple CPUs and Windows? (Multiple cores alone does not count!) <-- now what kind of question is that?
06:43<@Bjarni>I mean why would you care? :)
06:43<@Bjarni>(besides nobody replied)
06:44*Rubidium got multiple CPUs and Windows
06:44<Phantasm>Bjarni: There is one program (detecting physical core count) that needs to be tested on multiple CPUs.
06:44<Phantasm>Rubidium: Nice. Specs?
06:45<@Rubidium>one P-III Katmai 500, one P-M 1.6 GHz and Windows 3.11 on a floppy
06:45<planetmaker>ymmd, Rubidium :)
06:45<Phantasm>Rubidium: I don't see that being multiple CPUs on one comp.
06:46<Eddi|zuHause>that was not part of the question...
06:46<@Rubidium>you didn't specify that they needed to be in the same computer
06:46<Phantasm>It was apparent.
06:46<@Bjarni>no it wasn't
06:46<Eddi|zuHause>no, it was not.
06:46<@Rubidium>apparantly it was not
06:47<planetmaker>^ :) quibbling can be sooo nice... :)
06:47<Eddi|zuHause>it's an art... especially when mathmaticians are involved ;)
06:47-!-flowOver [] has joined #openttd
06:48<@Bjarni>you want two identical CPUs then?
06:48<@Bjarni>I have two 7,14 MHz 68000 CPUs and windows on another computer :P
06:49<@Rubidium>just run bochs on that machine and then install Windows 1.0
06:50*planetmaker wonders how Win 1.0 might have looked like. Much different than 2.7 ?
06:50<Eddi|zuHause>does windows 1.0 run in dosbox?
06:50<@Rubidium>Eddi|zuHause: might well be the case ;)
06:50<planetmaker>Eddi|zuHause: I'd give it a chance
06:51<@peter1138>Bah, my tool bar gui changes remove two window classes but only chops out 260 lines of code :(
06:51<Eddi|zuHause>i've only ever heard the statement "windows 1.0 even runs under windows"
06:51<@Bjarni>actually those two CPUs are in two different (yet identical) computers
06:51<@Bjarni>known as Amiga 500
06:51<@Rubidium>Bjarni: cluster them and run bochs on the cluster
06:52<Eddi|zuHause>anyone remembers the DosShell?
06:52<@Bjarni>I'm not sure if both still works
06:52<planetmaker>wow... even worse than 2.7 :)
06:53<@Rubidium>too bad they axed the support for Windows 1.0 6 and a half years ago
06:55<@Bjarni>there is no system 1 for mac
06:55<@Bjarni>they made it and before it shipped they found a fatal bug in it and made 1.0.1 instead
06:55<@Bjarni>so the first mac shipped with system 1.0.1
06:56<@Belugas>fonso, quick reading: diagonal patch, like concept, have not seen your work
06:56<@Belugas>sattion capacity, don't know, neither concept nr code
06:56<@Belugas>will try to give you time on it
06:57<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.
06:59<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.
07:00-!-Dred_furst [] has joined #openttd
07:00-!-curson [] has joined #openttd
07:01<fonso>My work on diagonal levelling is this patch:
07:02<blathijs>fonso: How will you handle the "station full" issue?
07:02-!-shodan [] has joined #openttd
07:03<fonso>cargo won't be accepted from industries, houses or trains wanting to store cargo anymore
07:03<fonso>it works well in the prototype:
07:03<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?
07:03<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
07:03<fonso>unloading and immediately disappearing is allowed even if the station is full
07:04<fonso>just staying at the station isn't allowed
07:04<Eddi|zuHause>fonso: does not help transferring
07:04<fonso>yes it does
07:04<blathijs>fonso: I saw the link, but I have no time for patch reviewing
07:04<fonso>a vehicle can pick up the goods another one has just unloaded and thus free some of the station
07:04<Eddi|zuHause>station is full, two busses A and B appear, people want to swap between A and B
07:04<blathijs>I do have time to do concept reviewing, though :-p
07:04<fonso>then another vehicle can unload som more
07:05<Eddi|zuHause>there is no way they can unload
07:05<fonso>it works,
07:05<fonso>try it
07:05<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
07:05<fonso>then it won't
07:05<@Rubidium>so if I set a transfer and leave empty order that means I can deadlock a station
07:06<Eddi|zuHause>really, i think station limits are not the solution
07:06<fonso>but only if there is no vehicle picking up the cargo you unload there
07:06<Eddi|zuHause>fonso: but a vehicle cannot pick anything up when it cannot unload first
07:06<@Rubidium>well, the bus is waiting behind the bus currently unloading
07:07<fonso>the bus with an unload order it can't fulfill will leave without unloading
07:07<Eddi|zuHause>exactly... which is wrong
07:07<Noldo>what is the goal of this patch anyway? Getting rid of station windows saying 99999999 passangers waiting?
07:07<@peter1138>Has it ever said 99999999?
07:08<fonso>this number is a bit high
07:08<Tefad>OVER 9000?! blasphemey
07:08<@Rubidium>fonso: so the unload order becomes pointless
07:08<Eddi|zuHause>you are curing a symptom
07:08<Eddi|zuHause>it does not solve anything
07:08<fonso>but 2000 for a bus stop is high enough to annoy me
07:08<@Rubidium>and so does the transfer order
07:08<Eddi|zuHause>only make it worse
07:08<fonso>becomes only pointless if your stations are too small
07:09-!-Zr40 [] has quit [Remote host closed the connection]
07:09<fonso>for storing lots of goods you should build big stations then
07:09<Eddi|zuHause>whatever limit you introduce, stations are always going to be "too small"
07:09<fonso>the limit is per tile, mind that
07:09<Eddi|zuHause>because for underserviced stations, generation always exceeds transport
07:10<blathijs>I do think that having some limit is a good idea
07:10<fonso>you can extend the station's limit by building additional station tiles
07:10<Noldo>you are just forcing people to build meaningless stationtiles
07:10<blathijs>Or at least having some way to model station size
07:10<Eddi|zuHause>yes, but adding a tile means only that the station is full at a higher level
07:10<Eddi|zuHause>it does not help transfers
07:10<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.
07:11<planetmaker>But that might even be solvable, if multistop is changed :)
07:11<fonso>and that's my main problem
07:11<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)
07:11<Eddi|zuHause>yes, but it is not the solution
07:11<fonso>but don't want a huge multistop for every stop a bus servers
07:11<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!
07:11<Eddi|zuHause>and "make the rate decrease" is the supposed effect of a station rating
07:11<Noldo>does station rating effect passanger generation?
07:11<Eddi|zuHause>but it does not adapt properly
07:12<fonso>a rating can be high if you have many small vehicles going to a station
07:12<fonso>and thus are not transporting many goods
07:13<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
07:13<Eddi|zuHause> <- read my comment here
07:13<Ammler>it would give the eyecandy stations sense, but it needs including grf support...
07:13<Eddi|zuHause>station rating needs to account for frequency of service and capacity of vehicles
07:14<planetmaker>a high amount of cargo waiting shouldn't matter, if the throughput is high.
07:14<Celestar>peter1138: I'll code the "reassign station" thingy now. If we deem required, we can still add more options later
07:14<planetmaker>maybe an idea to make rating dependant on the throughput of cargo divided by waiting cargo
07:14<Noldo>Eddi|zuHause: how about just flow in and out?
07:15<fonso>I'd be ok with a drop in station rating if the waiting cargo is too large in comparison to station size.
07:15<Eddi|zuHause>fonso: again, "station size" has absolutely no correlation to amount being transported
07:15<planetmaker>that's already effective implicitly.
07:15<fonso>and additionally perhaps a slower unloading on overcrowded stations?
07:15<planetmaker>Station size relates to amount of vehicles loading / unloading -> rating higher with many vehicles, one loading at all times.
07:16<fonso>planetmaker: that's exactly my problem. Station size should be visible as tiles occupied
07:16<Wolf01>mmmh MB now decided that also OTTD screenshots with TTRS and DBSet and ECS are illegal?
07:16<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.
07:17<fonso>planetmaker: what is your question?
07:17<planetmaker>station size is and was always visible...
07:18<Ammler>Wolf01: MB doesn't decide something, he just told you his opinion...
07:18<planetmaker>it effects rating in as larger stations handle better throughbut, ensure more frequent loading
07:18<fonso>but in an inadequate way
07:18<Celestar>why do I never get where the put const :P
07:18<Noldo>Celestar: :)
07:19<Celestar>especially in something like this:
07:19<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.
07:19<Celestar>std::list<CargoPacket *>::iterator it
07:19<planetmaker>fonso: that's, as I said, the only problem I see: bus stops in town centres :)
07:20<@Rubidium>const_iterator ?
07:20<planetmaker>You cannot send vehicles fast enough to get people transported away
07:20<fonso>hypothise a super fast loading bus
07:20<planetmaker>or trams, or whatever.
07:20<Noldo>fonso: why are the waiting passangers a problem?
07:20<Celestar>Rubidium: bah yeah
07:20<Celestar>Rubidium: can't do what I want
07:21<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
07:21<fonso>because I can't imagine 2000 passengers in a single bus stop.
07:21<planetmaker>but then, it's a matter of throughput of cargo.
07:21<planetmaker>fonso: Go to Victoria station, London or King's Cross, Sydney :)
07:21<fonso>you can also create that same situation with excessive transfers
07:22<Gekz>I love Town Hall in Sydney
07:22<@Rubidium>excessive transfers is what cargopackets is about
07:22<Gekz>it has about 20 entrances
07:22<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
07:22<Gekz>and it takes 20 minutes to get out of the Queen Victoria building
07:22<blathijs>This is also again related to the openttd scale problem, I guess
07:23<Wolf01>I think the max stockpile of a station should be 100*number of tiles
07:23<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.
07:23<@Bjarni>so it would take 4 tiles to "store" 350 passengers?
07:24<fonso>if you have a capacity of 100 per tile, yes
07:24<@Bjarni>I have seen that many on what would translate as a single tile station
07:24<Eddi|zuHause>100 per tile is a really harsh limit, considering that two transrapid wagons can handle 240 passengers...
07:24<@Bjarni>that platform was packed
07:24<fonso>you can set the limit higher
07:25<Eddi|zuHause>i am still strongly against that kind of limit
07:25<@Bjarni>why would we need that kind of limit anyway?
07:25<blathijs>fonso: I think we agree on the problem (or rather, the symptom), but not on the solution
07:25-!-Zr40 [] has joined #openttd
07:25<@Bjarni>you want it like SimuTrans handles this?
07:26<Celestar>what are we discussing peops?
07:26<fonso>How does simutrans do it?
07:26<Eddi|zuHause>Celestar: overful stations
07:26<fonso>Celestar: station capacities
07:26<@Bjarni>Celestar: cargo waiting at stations
07:26<blathijs>Celestar: Station capacities
07:26<@peter1138>Hmm, how do I get a diff out of hg over a set of commits?
07:26<@Bjarni>basically somebody considers it unrealistic to have 5000 people waiting at a bus stop
07:27<@peter1138>Never involve realism.
07:27<@Bjarni>peter1138: make a diff between your branch and trunk
07:27<Celestar>peter1138: we should put station capacities as a plugin-class to the Routing classes, how does that sound?
07:27<fonso>btw, I altered my proposal before: Slower unloading and lower ratings in relation to (number of cargo waiting)/(space available)
07:27<Forked>can we involve "silly"? :p
07:27<@Bjarni>I hope you started a branch of your own ;)
07:27<Gekz>peter1138: always involve realism
07:27<Celestar>peter1138: and have a flag that enables/disables it
07:27<Gekz>peter1138: having passenger destinations is realistic.
07:27<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.
07:27<Celestar>peter1138: so the rest of the code needen't worry
07:28<@Bjarni><Gekz> peter1138: having passenger destinations is realistic. <-- maybe but it mainly affects gameplay
07:28<@Bjarni>and we do care about gameplay
07:28<Gekz>and the amount of passengers on a tile doesnt
07:28<fonso>blathijs: And I would be ok with a solution based on ratings, but only solves half of the problem
07:28<@Bjarni>it does
07:28<Celestar>how about we limit per station type?
07:29<Celestar>like 200 for a bus stop
07:29<@Bjarni>but the question is if we would like this feature in gameplay
07:29<Celestar>1000 per platform on a train station ...
07:29<Gekz>Bjarni: make it a patch then
07:29<@peter1138>In my opinion, we need to produce less passengers, not limit the ones that are produced.
07:29<Gekz>Bjarni: because it can't hurt.
07:29<fonso>I'd make it grf-accessible
07:29<Noldo>Celestar: it punnishes good flow
07:29<Gekz>Bjarni: it would add another element of gameplay
07:29<Noldo>peter1138: agreed
07:29<Gekz>placing more busstops to allow more peeps.
07:29<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.
07:29<fonso>my proposal for that: slower unloading
07:30<@peter1138>More tiles results in a larger catchment area, which results in more passengers.
07:30<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
07:30<Eddi|zuHause>the limit prevents any transfers going on
07:31-!-Jan [] has joined #openttd
07:31<Jan>hello guys
07:31<Eddi|zuHause>another fischkopp!
07:31<@Bjarni>shut up
07:31<Jan>ah doch ein paar deutsche hier :)
07:31<fonso>Eddi|zuHause: slower unloading at overcrowded stations would solve that
07:31<@Bjarni>if we pretend we aren't here then he might think the channel is idle and stop talking :P
07:32<Jan>can one any help me ?
07:32<@Bjarni>that depends on what your problem is
07:32<Eddi|zuHause>the answer is: 42
07:32<@Bjarni>nobody here will give you more toilet paper
07:32<@Bjarni>imagine that... IRC from the bathroom because you are out of toilet paper :D
07:32<Jan>i cant found the download for a openttd linux server version 0.6.2. have anyone the link ?
07:33<blathijs>Jan: Which distro are you using? AFAIK we only support Debian directly currently
07:33<Jan>yeah debian i have it
07:33-!-Zahl [] has joined #openttd
07:33<@Bjarni>this is all we got
07:34<@Bjarni>either use a binary from that page or compile yourself
07:34<Jan>ahh n1 thx
07:34<blathijs>Jan: You should then just use the normal version, openttd can be started as dedicated server as well
07:34<blathijs>Jan: I'm still planning to create a seperate server package, but haven't got around to it yet
07:35<Ammler>Jan: I would suggest to compile it self, else you would need sdl and such...
07:37<Ammler>well, so you need gcc, what is better? :-)
07:38-!-flowOver [] has quit [Read error: Connection reset by peer]
07:38<Eddi|zuHause>Bjarni: ;)
07:40<@Bjarni>Eddi|zuHause sends me toilet poetry in German
07:41<@Bjarni><Biber> lol bist du ein arsch :D <-- then it makes sense that he is the one with access to the toilet paper
07:41-!-flowOver [] has joined #openttd
07:42<Celestar>dbg: [cargopacket] [Passengers] :Cargo is no longer accepted at <Prarnbury Heights>, rerouting to <Prarnbury Central>
07:42<Brianetta>german-bash has pop-up ads
07:43<Eddi|zuHause>really? i never noticed...
07:43<Brianetta>that sucks really hard, like a Dyson cleaner or a black hole.
07:43<@Bjarni>I never noticed either
07:44<@Bjarni>I guess it detects a British browser and spams it
07:44<Brianetta>It's all Javascript stuff
07:44*Brianetta is reading the sauce
07:44<Eddi|zuHause>there are banner ads between the quotes
07:44<Eddi|zuHause>but i never noticed a popup
07:44<Brianetta>Bjarni: If it was doing that, it'd be more productive of it to give me a non-German ad
07:45<Brianetta>Eddi|zuHause: It wasn't a separate window pop-up
07:45<Celestar>peter1138: pull
07:45<Brianetta>but a javascript div-over
07:45<@Bjarni>I hate those
07:45<Gekz>those are terrible
07:46<Brianetta> <script language="JavaScript">
07:46<Brianetta> var mirando_cache=Math.floor(Math.random()*1000000);
07:46<Brianetta> document.write('<scri'+'pt language="JavaScript" src="'+mirando_cache+'" ></scri'+'pt>');
07:46<Brianetta> </script>
07:46<Eddi|zuHause>las miranda den sevilla?
07:46<Brianetta>There she is.
07:47<Eddi|zuHause>it's another one of those simpson jokes that i have no idea of the english equivalent
07:47<Brianetta>That's a totally evil bit of Javascript
07:47<Eddi|zuHause>"scri'+'pt" is genious ;)
07:54-!-glx [] has joined #openttd
07:54-!-mode/#openttd [+v glx] by ChanServ
07:55-!-Roujin [] has quit [Ping timeout: 480 seconds]
07:55<Celestar>hey glx
07:56<+glx>hello :)
07:56<Celestar>did you have a chance to test anything?
07:57<Celestar>heh, there's a shitload of patches on the forum
07:57<Eddi|zuHause>how long did you not look there? :p
07:58<Eddi|zuHause>what worries me more than the amount of patches, is the amount of patch packs...
07:58<Eddi|zuHause>and with the increasing number of patch packs, the decreasing lifetime of them
07:59<+glx>I suggest to not read suggestion forum :)
07:59<@Bjarni>what worries me the most is the ideas on the forum
07:59<Eddi|zuHause>indeed ;)
07:59<@Bjarni>some of them are really wicked
07:59-!-Roujin [] has joined #openttd
08:00<@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
08:00<Celestar>yeah. right.
08:00<Forked>heh =)
08:00<Forked>"how hard can it be!?"
08:00<@Bjarni>and he was so sure of that fact that he didn't even have to search the forums first
08:00<Celestar>the reason why nobody did cold fusion yet is because no one thought of it yet
08:01<Celestar>some patches sound useful by their description :P
08:01<@Bjarni>except me
08:01<Celestar>haven't read the code
08:01<@Bjarni>that's why I have cold fusion running in the basement
08:01<@Bjarni>but it's a secret so don't tell anybody
08:01-!-welshdra-gone is now known as welshdragon
08:01<Celestar>glx: the OOP widgets. maybe configurable hotkeys ..
08:02<+glx>ha right
08:02<+glx>configurable hotkeys was full of code duplication last time I checked it
08:02<Celestar>didn't read it
08:02<Celestar>we should rewrite debug() completely
08:03<@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?
08:03<+glx>still no warnings for cargodest :)
08:03<Celestar>from stdio to iostream
08:03<Celestar>glx: cool
08:03<Celestar>glx: did you get my latest version?
08:03<Celestar>(16 minutes ago or so)
08:03<Celestar>wanna brute-test it (=
08:04<+glx>I always pull before compile
08:04<@Bjarni>maybe I should test it too
08:04<Celestar>Bjarni: yeah, maybe you should, dunno if anyone has tried on MacOS yet
08:04<Roujin>Celestar: here's two suggestions that i think are nice too:
08:04<Celestar>glx: the diagonal level tool sounds horrible helpful
08:04<Celestar>Roujin: checking
08:04-!-m_ax [] has joined #openttd
08:04<Eddi|zuHause> <- why has that not been integrated yet?
08:04<Roujin>i'm currently working on the first one (scroll in network window with arrow keys)
08:05<Roujin>nearly done
08:05<+glx>Celestar: yes but only in scenario editor I think
08:05<@Rubidium>Eddi|zuHause: ask Maedhros
08:05<Celestar>glx: why?
08:05<@peter1138>Hmm, I think this is working properly now.
08:05<Celestar>peter1138: what is?
08:07<+glx>Roujin: server window now has last use server
08:08<Eddi|zuHause>hm... is it me or does that attachment not provide a download link?
08:09<@peter1138>My toolbar gui rewrite...
08:09<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
08:09<Eddi|zuHause>yay, i got someone addicted :P
08:09<Roujin>but the other suggestion? being able to scroll with keys through the server list?
08:10<Roujin>nearly done with a patch for it - only commenting a bit now
08:10*hylje thought up a rudimentary contract concept to, among other things, replace subsidies
08:10<Ammler>why are there no stable linux releases?
08:11<Eddi|zuHause>Ammler: openttd is in many distribution repositories
08:11<Ammler>oh, thought of that, but only for clients...
08:12<Ammler>and debian hasn't such?
08:13<Eddi|zuHause>you can use the client as server
08:13<+glx>Ammler: it was too late for debian
08:13<Ammler>Eddi|zuHause: no, you need sdl then
08:16-!-nekx [] has joined #openttd
08:16-!-nkx [] has quit [Read error: Connection reset by peer]
08:18<Roujin>if you're interested,
08:18<Roujin>scroll with arrow keys in server list
08:18<Roujin>i'll put it on flyspray..
08:19<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)
08:19<Ammler>Eddi|zuHause: well, it was at least that way, as I compiled it last time, am I wrong?
08:20<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
08:21<Ammler>[14:20] <Eddi|zuHause> yes <-- strange, then I did something else wrong...
08:21<Eddi|zuHause>Ammler: ignore my last sentence ;)
08:23-!-nkx [] has joined #openttd
08:23-!-nekx [] has quit [Read error: Connection reset by peer]
08:23<Ammler>blathijs: can't you include a "testing" repo to stable debian?
08:23<blathijs>Ammler: I think that pulling openttd from testing should work just fine
08:24<blathijs>Ammler: Perhaps the dependencies also need to be pulled in, because of the way they are specified
08:24<+glx>Roujin: can't you store the selected index too ?
08:24<blathijs>Ammler: In that case, using the build from the website should work (I always build those on stable)
08:25<Ammler>blathijs: and those runs also without sdl?
08:26<+glx>they are not dedicated
08:29-!-Sir-Bob [] has quit [Ping timeout: 480 seconds]
08:34<Roujin>glx: hmmm the index could be stored, but then it would have to be recalculated when the list is resorted
08:35<+glx>the list will be probably less resorted than arrow keys pressed ;)
08:36-!-nkx [] has quit [Read error: Connection reset by peer]
08:37-!-nekx [] has joined #openttd
08:37<blathijs>Ammler: No, they are full builds so they need SDL
08:43<Celestar>peter1138: you got hg serve running at the moment?
08:44-!-Nev [] has joined #openttd
08:50-!-bleepy [] has quit [Ping timeout: 480 seconds]
08:55<Celestar>Macros == eeeeevil
08:58-!-ben_goodger [] has quit [Ping timeout: 480 seconds]
08:58<blathijs>Actually, Macros was quite a nice guy
08:59<blathijs>In Raymond E. Feist's books anyway :-p
08:59-!-ben_goodger [] has joined #openttd
09:03-!-dlunch [~dlunch@] has joined #openttd
09:03<Eddi|zuHause>hm... in the window class-ification, what happened to WP(.,.) stuff?
09:04<Celestar>peter1138: I'm trying to turing CDEBUG and RDEBUG into DEBUG through the classes
09:04<+glx>Eddi|zuHause: class members
09:05<Celestar>peter1138: it's HARD
09:05<Eddi|zuHause>glx: you mean WP(w, x) gets w->x?
09:06<Celestar>yay for C++
09:07-!-kais58 [vircuser@] has joined #openttd
09:09<Noldo>what does WP do anyway?
09:09<Noldo>or did
09:10<Celestar>WP == Window Property afaik
09:10-!-welshdragon [] has quit [Ping timeout: 480 seconds]
09:11<Celestar>can I tell the processor to ignore a certain line :S
09:12<Celestar>or just not to mangle it :S
09:12<Celestar>LEAVE IT ALONE! SHOO!
09:17<blathijs>You could undef the macro that is breaking the line (which I suspect is the problem?(
09:18<Celestar>because I have to redefine it afterwards
09:18<Eddi|zuHause>i definitely don't understand gui code :(
09:18-!-Roujin [] has quit [Ping timeout: 480 seconds]
09:20<blathijs>Celestar: #define OLD_FOO FOO; #undef FOO; do_stuff; #define FOO OLD_FOO
09:20<blathijs>Celestar: Won't that work? (Apart from being totally ugly)
09:21<@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
09:21<@Belugas>even comments are duplicated
09:21<fonso>some comments are duplicated on purpose, but where is actual code duplicated?
09:21<@Belugas>landscape.cpp and terraform_cmd.cpp
09:22<@Belugas>or maybe i'm blind...
09:22*fonso goes investigating
09:22<Celestar>blathijs: didn't work for some reason
09:22<@Belugas>but still, why duplication of comments ?
09:22*Celestar shakes his fist at DEBUG
09:23<blathijs>Celestar: What's the problem, exactly?
09:23*Belugas says hello at Celestar and put some boxing gloves on waving fists
09:24<Celestar>blathijs: in one of my header files, I wish to declare a method called DEBUG
09:24<blathijs>But DEBUG is also a macro with that name?
09:25<Celestar>yes :S
09:25<blathijs>Why not name it Debug or something? All-caps is weird for method names anyway.
09:25<@Belugas>do not use same casing :)
09:25<fonso>The comments have been moved around a bit and the code was much longer before.
09:25<blathijs>Even if you would succeed in declaring it, you would have the same issues everywhere you use the method I think?
09:25<fonso>Perhaps they don't make that much sense anymore
09:25<@SmatZ>Celestar: you have strange wishes :)
09:26<Celestar>SmatZ: yes .. I wish DEBUG to be a class
09:27<blathijs>Celestar: You just said you wanted it to be a method?
09:28-!-tokai [] has quit [Ping timeout: 480 seconds]
09:28<@Belugas>fonso, so the two codes are somewhat related, since they have the same comments?
09:29<@Belugas>blathijs, maybe it;s a class and a method, thus a constructor ? ;)
09:29<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 ;)
09:29<Celestar>I wish DEBUG was a class throughout the code, but also a method of RoutingBase_t
09:30-!-tokai [] has joined #openttd
09:30-!-mode/#openttd [+v tokai] by ChanServ
09:32-!-rortom [] has joined #openttd
09:32<blathijs>Celestar: Ah, you want DEBUG to be a class instead of a macro :-)
09:32<blathijs>Celestar: Still, why do you want to name the method DEBUG so badly?
09:33<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)
09:33<Celestar>yeah, I have already stopped wanting it
09:33<Celestar>all debug messages withing the routing system are now printed with Debug()
09:34<@Belugas>Celestar, why do you need two methods of message debugging?
09:34*Belugas fails to see the point
09:34<@Belugas>altough ,
09:35<Celestar>Belugas: because withing the routing system, I want to automagically add the cargo-type to the debug message
09:35<@Belugas>so maybe a wrapper?
09:35<@Belugas>around DEBUG, i mean
09:36<@SmatZ>DEBUG supports variable argument list
09:38<Celestar>Belugas: that's what I have now
09:38<Celestar>SmatZ: I don't want to add the cargotype manually to each and every debug message
09:38<Celestar>grep Debug src/routing.* | wc -l
09:39<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.
09:39<Celestar>fonso: you use the evil word
09:39<fonso>which one? Macro or callback ;)?
09:39-!-shodan [] has quit [Quit: Client Exiting]
09:40<Celestar>fonso: Macro
09:40<fonso>well then, we'll have to use a callback function ...
09:41<blathijs>Callback functions are not so nice from a performance perspective
09:41<blathijs>what code are we discussing?
09:41<Celestar>peter1138: pull again :)
09:42<Celestar>peter1138: the two "XXX" in routing.cpp .. why the XXX ?
09:42<@Belugas>fonso, no macro, that's waht we were against right from the start
09:42<@Belugas>and granted, the actions inside loop are different
09:42<fonso>where was that paste service?
09:43<blathijs>or pastebin. perhaps
09:43<@Belugas>fonso, maybe it wold be better off a structure holding the different values,
09:43<@Belugas>then a commun initialization
09:43<@Belugas>i think
09:43<fonso>I could do that
09:43<@Belugas>the values for the loop, i mean...
09:44<fonso>yes I know
09:44<fonso>ex, ey and so on
09:44<@Belugas>blathijs, it's the diagonal selection/leveling patch
09:44<@Belugas>fonso, exactly
09:45<blathijs>Belugas: I gathered that, but I was hoping for a link to code :-)
09:45<@Belugas>ho... sorry...
09:46<blathijs>Thanks :-)
09:48<fonso>Belugas: was that "wait" for me?
09:49<blathijs>fonso: This is the improved and unified version? Or where would be adding this macro or callback?
09:49<fonso>This piece of code shows up twice
09:49<@Belugas>fonso, "wait" was addressed to blathijs
09:50<blathijs>fonso: Ah, so this is "walk the tiles diagonally" code that is used twice. I see
09:50<blathijs>Those two "some action"s, are they similar, or completely different?
09:51<blathijs>You might want to consider putting them both into this loop with an if around them (inside the loop)
09:51-!-Roujin [] has joined #openttd
09:52*Celestar looks at his TODO list for cargopackets and is delighted
09:53<Noldo>Celestar: what is left?
09:53<Celestar>Noldo: biasing the destination generation not only by distance, but also by station size
09:53<Celestar>Noldo: but I need some way to determine the station size
09:53<Celestar>for passengers, it's easy. just count the amount of passengers in the coverage area
09:54<Celestar>but for cargo ...
09:54<Noldo>of that kind of size
09:54<Noldo>you need to ask the industry
09:56*Belugas is on an emergency call@work, thus not available
09:58<blathijs>fonso: I have this feeling that your looping code is either too complicated, or does something else than I think it does :-)
09:58<Celestar>Noldo: does that work for industries that accept input cargos?
09:58<fonso>I don't think it gets any simpler
09:58<fonso>Have you seen it before I cleaned it up?
09:59<blathijs>No :-)
09:59<blathijs>fonso: What is the code trying to do? Loop the tiles between (sx, sy) and (ex, ey) diagonally?
09:59<fonso>ok ...
10:00<fonso>the original code looped across the "simple" coordinates diagonally
10:00*orudge is poking through lots of old openttd things he has
10:00<@orudge>such as my original "new industries" version featuring Born_Acorn's desalination plant and oil power station
10:00<@orudge>and things like my original "bigger airport" patch, larger maps, cargo packets, new map array, and other such fun things
10:00<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
10:01<fonso>I simplified that by just running over all the coordinates twice and dividing more intelligently so that integer operations work in my favor
10:02-!-nkx [] has joined #openttd
10:02-!-nekx [] has quit [Read error: Connection reset by peer]
10:02<blathijs>It might also be that the variable names are slightly too short for me to understand what happens properly :-)
10:02<fonso>well that's easy to solve
10:02<blathijs>But AFAICS, either fx or fy is guaranteed to be between -1 and 1 (including), right?
10:03<@peter1138>Sorry Celestar, just got back from the dentist...
10:03<Celestar>peter1138: are you allright?
10:03<fonso>no, sfy and sfx are the signs
10:03<blathijs>fonso: Yes, but I think fx or fy is always small
10:03<blathijs>and the other is big
10:04<@peter1138>Celestar, er, need a wisdom tooth pulled on Monday :o
10:04<fonso>fx and fy are the "angle" in which you draw
10:04<fonso>so they might be quite large
10:04<fonso>they might be equal if you draw a square
10:05<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)
10:05<blathijs>The start and end point are diagonally connected, righ?
10:05<fonso>yes, but they may be far apart
10:06<@peter1138>Celestar, ah, the 'town effect' for valuables...
10:06<@orudge>heh, and the network branch, where the new networking was new
10:06<Noldo>how much did the old networking suck?
10:06<blathijs>fonso: Yes, but since the are diagonal, abs(dx) and abs(dy) cannot be much different
10:06<blathijs>fonso: one difference, really
10:06<@peter1138>Celestar, we need to find out what cargo behaves like valuables, as NewGRF does not have an attribute for that.
10:07<fonso>yes they can
10:07<fonso>you can draw any rectangle you like
10:07<fonso>dx and dy might be very different
10:07<@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.
10:08<blathijs>fonso: Than I'm probably completely missing the point of your patch :-P
10:08<fonso>for example dx=1 and dy=200 is ok
10:08<blathijs>And then it would insert a number of straight tracks and a single diagonal one, or something?
10:09<Celestar>peter1138: possible. yeah
10:09<Celestar>peter1138: we should maybe at a TownEffect?
10:09<fonso>on moment. I have to try the 1-200 thing in practice. It sounds strange
10:09<@peter1138>Celestar, yeah, we could try that too :)
10:10<@peter1138>Probably more reliable.
10:10<Eddi|zuHause>use templates ;)
10:10<Eddi|zuHause>hm... buffer :(
10:11<Celestar>Eddi|zuHause: ?
10:11<Eddi|zuHause>ignore that :(
10:11<Celestar>peter1138: you should pull. I'm mostly done
10:11<fonso>lets phrase it that way: it draws a diagonal rectangle with the beginning and end of your mousedrag as corners
10:11<Eddi|zuHause>buffer == not scrolled to the bottom of the chat
10:11<fonso>just like orthogonal, actually
10:11<@peter1138>I did.
10:12<Celestar>todo items 1a and 1b give me a headache
10:13<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)
10:13-!-Vikthor [] has quit [Quit: Leaving.]
10:16<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
10:16<fonso>If you like that I can do it that way
10:17<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)
10:17<fonso>But someone told my something along the lines of macros coming from hell itself ...
10:17<blathijs>I'm not sure if I like it, it's just that I can't easily imagine a better solution :-p
10:18<blathijs>But let's wait for a bit so Celestar can start protesting :-)
10:21*Belugas mumbles at stupid so-called technician who can't follow simple directives
10:22<@Belugas>fonso, maybe start by giving better names to variables?
10:22<Roujin>Belugas: oh dear, now you'll be haunted by users urging you to complete it :P
10:22<@Belugas>would help a tiny little bit...
10:22<fonso>ok, I'll do that first
10:23<@Belugas>Roujin, they will have to keep waiting, since it's VERTY far from been working ;)
10:23<@peter1138>blathijs, the problem is the original macro version was a very very nasty macro...
10:23<Roujin>did you decide to pick it up again?
10:23<@Belugas>pick it up?
10:24<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 ?
10:24<Roujin>continue work on it i mean (was that wrong?)
10:24<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
10:25<@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
10:25<@Belugas>i guess i'll resume work on it in a month
10:25<Roujin>that's always preferable ;) (not going insane)
10:25<@Belugas>evaluated time before colours-work-related finished
10:26<Roujin>that many places to enumify? or do you have some bigger plan regarding colors
10:27<@Belugas>no bigger plans
10:27<@Belugas>just understanding and commenting is good enough for now
10:27*Phantasm pokes Belugas for the fix. ;P
10:28<@Belugas>Phantasm, there is already a part that went into trunk recently
10:28<Phantasm>Oh.. How was the flood of messages fixed?
10:28<@Belugas>the open and closure news of industries that are now separated
10:29<@Belugas>it's not fixed as per say, but it's gong on the right way
10:29<Phantasm>Estimate on when will the whole thing be fine?
10:29<Celestar>blathijs: the tile loop can be done with and std::vector<Tile *> as well (=
10:29<@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
10:31<blathijs>Celestar: It sounds pretty inefficient to put all those tiles in vector first, while you can easily loop them directly
10:32<blathijs>Celestar: Having some sort of TileRectangleIterator might be useful, though
10:32<@Belugas>Roujin, so this is where i stand right now:
10:32<Celestar>blathijs: or rather map should be and std::vector
10:32*Belugas nods at blathijs
10:32<blathijs>Celestar: And then also TileDiagonalRectangleIterator
10:32<blathijs>(but with better names)
10:32<blathijs>Celestar: How would you be doing two-dimensional iteration then?
10:33<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
10:35<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
10:36-!-Singaporekid [] has joined #openttd
10:38-!-Jan [] has quit []
10:39<@Belugas>Phantasm, i'm very VERY V E R Y poor at making estimates
10:39<Phantasm>Belugas: Heh.
10:40<@Belugas>the last time i did one (at work), i busted the schedule by a big month
10:40<@Belugas>a month more, that is...
10:40<@Belugas>so, i could tell you by the end of teh year, but it wold be as good as "in spring 2009"
10:41<@Belugas>maybe if i did not start so many stuff at once :S
10:41<Eddi|zuHause>employ 2500 people to meet the easter deadline :p
10:44*Belugas hires Eddi|zuHause right away
10:44<Eddi|zuHause>how much do you pay? ;)
10:44*Belugas gives Eddi|zuHause the same salary he receives for working on OpenTTD ;)
10:44<Roujin>Belugas: there's some inconsistency between color and colour in some places
10:45<@Belugas>could be, Roujin, could very well be
10:45<Eddi|zuHause>i get payed thousands of hours of joy!
10:45<Roujin>also i see that you've merged TextColour and Colour - so some colours have two names now
10:46<Roujin>couldn't they just be removed then?
10:46<@Belugas>didn't the patch has the wip name on it?
10:46<@Belugas>not really now, Roujin, they still are addressing differnt values, for the most part
10:47<Celestar>blathijs: meanwhile, openttd is c++, arrays are evil (=
10:47-!-Doorslammer [] has quit []
10:47<@Belugas>open is C++ FLAVOURED, Celestar, not totally c++ ;)
10:47<SpComb>C++ is evil, OpenTTD is C++, OpenTTD is evil
10:47<Celestar>but it's going in that direction, isn't it?
10:47<@Belugas>think so, yes
10:47<@SmatZ>for me, no
10:47<blathijs>Celestar: Still, std::vector is not a suitable implementation for the tile storage, I think
10:48<Celestar>SpComb: I not really see what is evil about C++
10:48<Celestar>blathijs: why?
10:48<@Belugas>but not on a fiercefull-do-it-right-now-just=because-it-has-to-be-done mode
10:48<blathijs>Celestar: I'm not denying that slapping an STL-container like interface on the map array might be a good idea
10:48<Celestar>Belugas: that much is certain (=
10:48<blathijs>Celestar: It provides all kinds of fancy features that we don't need
10:49<blathijs>Celestar: otoh, if you just reserve the size you need, it might work out just fine I guess.
10:49<@Belugas>when it is required, or usefull, yes. Otherwise, why?
10:49*Belugas resumes work@work
10:49<Celestar>let me put it another way: what's the disadvantage of using std::vector to store the map
10:49<Celestar>Belugas: we're not changing anything at the moment. merely discussing
10:49<blathijs>Celestar: I was thinking in the performance corner, but I'm not sure that it really matters
10:49<Celestar>SpComb: C++ is usually evil when one tries to put C paradigms into C++
10:49<blathijs>Celestar: So you might be right :-)
10:49<Celestar>blathijs: std::vector is just as fast as an array or a pointer
10:50<Celestar>it's contingouos
10:50<Celestar>(spelling .. )
10:50<blathijs>Celestar: Yeah, only when changing it's size things can get slow
10:50<Celestar>blathijs: just like with realloc ..
10:50<blathijs>Celestar: Which we shouldn't be doing anyway :-)
10:50<@Belugas>Roujin, _string_colormap (table\palettes.h) needs to be adjusted to match usual colours
10:50*Belugas goes back @work
10:51<SpComb>Celestar: we're talking about the OpenTTD source code here, indeed :(
10:51<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)
10:51<Celestar>blathijs: however, you can make a Tile class (which we should be doing anyway) and write your own interators
10:52<Celestar>Tile_t::Rectiterator, Tile_t::Diamonditerator, Tile_t::Spiraliterator ...
10:52*SpComb averts his eyes
10:52<blathijs>Huh? Are iterators part of the element (Tile) ? Aren't they part of the container?
10:52<SpComb>I just have this irrational fear of C++
10:53<Celestar>SpComb: I used to as well until quite recently in fact
10:53<Celestar>after having coded the routing system, I feel quite the contrary
10:53<Celestar>SpComb: only real mistake you can make is to regard C++ and an extension to C
10:53<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?
10:53<Celestar>blathijs: of course.
10:54<Celestar>blathijs: but one isn't using arrays in C++
10:54<blathijs>huh? one what?
10:54<SpComb>Celestar: so OpenTTD's C++-flavoured sauce cod is a bad idea?
10:55<Celestar>SpComb: nope
10:55<Celestar>SpComb: just once you rework a component, stick it into a class
10:55<Celestar>SpComb: like we have done
10:55<Celestar>if I find a free .. minute .. I'll make a Tile class at some point
10:55<Roujin>what is the maximum number of values in a SmallVector<T, 32> ? 2^32?
10:56<Celestar>and get rid of the evil evil evil TileTypeProcs tables
10:57<Celestar>which is really nothing else than the attempt to produce an ABC with polymorphic pointers
10:57<Eddi|zuHause>we need some kind of "Wormhole" tile classes
10:57<Eddi|zuHause>for vehicles travelling in tunnels/on bridges
10:58<Eddi|zuHause>so all the tile changing functions can be called while "in wormhole"
10:58<@SmatZ>Roujin: the second number is size of block in what is memory allocated, static array would be better in that case :-P
10:58<blathijs>Celestar: There is more code in OpenTTD that's really polymorphism-in-C :-)
10:58<Eddi|zuHause>especially signal related
10:58<SpComb>imo, nothing wrong with "polymorphic" C code, as long as it's C code, and doesn't try and be anything else
11:00<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
11:00<SpComb>but I probably shouldn't really discuss C++ until I've actually learned it
11:01<Celestar>SpComb: google for "C++ FAQ lite" .. it's very good imho
11:01<Roujin>uint16 should be enough i guess..
11:08<Celestar>Roujin: unless I'm space constrained (i. e. have a large array of it), I use int.
11:08<Celestar>or unsigned int
11:08<SpComb>Celestar: and I counter you with
11:08<SpComb>note that I've read the FQA, but not the FAQ
11:10-!-m_ax [] has quit [Read error: Connection reset by peer]
11:12<Eddi|zuHause>what does "error: too many initializers for ‘const WindowDesc’" mean?
11:14<+glx>what it says :)
11:15<+glx>too many things between { and }
11:15<Eddi|zuHause>yay, it compiles ;)
11:16-!-svippery [] has joined #openttd
11:16-!-svippy [] has quit [Read error: Connection reset by peer]
11:20<Celestar>heh SpComb nice one. haven't read it yet
11:20-!-frosch123 [] has joined #openttd
11:30-!-AntB [] has joined #openttd
11:45<fonso>I renamed the variables for diagonal levelling:
11:45<fonso>Should I use a macro for diagonal tile walking?
11:46-!-nekx [] has joined #openttd
11:46-!-nkx [] has quit [Read error: Connection reset by peer]
11:48-!-rortom [] has quit []
11:52*Belugas reads
11:52<CIA-5>OpenTTD: smatz * r14005 /trunk/src/rail_cmd.cpp: -Codechange: minor coding style fix
11:57-!-nkx [] has joined #openttd
11:57-!-nekx [] has quit [Read error: Connection reset by peer]
11:57-!-AntB [] has quit [Ping timeout: 480 seconds]
11:57<@Belugas>feels better, fonso
11:57<@Belugas>as for the macro, i don't know
11:58<@Belugas>landscape.h, useless change
11:58<fonso>I can write a version with macro and see how that feels ...
11:58<@Belugas>yuo could :)
11:59<fonso>yes, landscape.h was accidental. I was preparing to put the macro there when someone called me back
11:59<@Belugas>in viewport.cpp, comment "// a_size, b_size describe a rectangle with rotated coordinates" should be "/*..*/" instead
12:00*fonso goes reading the coding style thread
12:00<@Belugas>a comment on its own line is always /**/
12:00<@Belugas>a comment at the end of a code like is //
12:01<@Belugas>a comment defining a struct/enum/whatever is ///<
12:01<fonso>ok, thanks
12:01-!-Purno [] has joined #openttd
12:02<@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
12:02<@Belugas>yeah. i know... picky..
12:02<Eddi|zuHause>comment for a function is /** */ (doxygen?)
12:03<fonso>that's all not difficult to repair
12:03<@Belugas>yes Eddi|zuHause
12:04-!-Progman [] has quit [Remote host closed the connection]
12:05<Yexo>fonso: why can't LOWER_AND_LEVEL and RAISE_AND_LEVEL not be diagonal?
12:05<fonso>in principle they can
12:05<fonso>but there is another patch that some people like which redefines the CTRL key for them
12:06<@Belugas>drag and draw?
12:06<fonso>it's called "advanced terraform"
12:06<fonso>that's the same
12:06<@Belugas>wonders how both can cohabit
12:06<@Belugas>co exist
12:06<Yexo>wasn't that patch also for flattening land?
12:06<fonso>there are a couble of ideas
12:06<fonso>Yexo: yes
12:06<Yexo>so it'd can't co exists anyway
12:07<fonso>uh, I have to look it up. It was complicated
12:09<Yexo>if you make p2 a bitmask (you have to change LEVEL_* for that), both patches could coexist
12:09<fonso>so, my proposal was to limit drag&draw to lower and raise and make it default behaviour for them
12:09<@Belugas>go Yexo go!
12:09*Belugas goes to lunch
12:10<fonso>the argument was that most people don't need area raise and lower as it's counter-intuitive anyway
12:10<fonso>You can actually lower land with raise and raise land with lower
12:10<dih> <- repeated desyncs
12:11<@SmatZ>dih: did you reproduce it?
12:12<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.
12:13<Roujin>you're free to take my patch and make something yourself out of it
12:13<Roujin>[18:06] <Yexo> so it'd can't co exists anyway
12:13<Roujin>[18:06] <fonso> uh, I have to look it up. It was complicated
12:13<Roujin>[18:08] <Yexo> if you make p2 a bitmask (you have to change LEVEL_* for that), both patches could coexist
12:13<Roujin>[18:08] <fonso> so, my proposal was to limit drag&draw to lower and raise and make it default behaviour for them
12:13<Roujin>[18:08] <@Belugas> go Yexo go!
12:13<Roujin>[18:09] * @Belugas goes to lunch
12:13<Yexo>fonso: I don't see why that is couterintuitive, if I just want to level some tiles for a railway for example
12:13<Roujin>sorry for that
12:15<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.
12:15<dih>SmatZ, see #openttdFairPlay
12:15<Yexo>or just a clientside patch setting setting what ctrl will do
12:15<fonso>or that
12:15<@SmatZ>dih: been there, done that :)
12:16<fonso>but that's the task of the patch adding the second option, I'd say
12:16<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
12:17<fonso>ok, bitmask for p2. I'll do it later today.
12:17<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
12:17<Roujin>putting the new version on flyspray..
12:19-!-Reemo [] has joined #openttd
12:22<Yexo>fonso: in DraggingDiagonal(), _thd.select_method == VPM_X_AND_Y can be moved out of the ||
12:22-!-nekx [] has joined #openttd
12:22-!-nkx [] has quit [Read error: Connection reset by peer]
12:29-!-Brianetta [] has quit [Quit: Tschüß]
12:29-!-nekx [] has quit [Read error: Connection reset by peer]
12:29-!-nekx [] has joined #openttd
12:32-!-fonso [] has left #openttd [Kopete 0.12.7 :]
12:32<Eddi|zuHause>argh... this can only be Belugas' fault...
12:33<@Belugas>yes, i agree
12:34-!-Wezz6400 [] has quit [Quit: bbl]
12:34<Eddi|zuHause>conflicts in a widget array ;)
12:39*peter1138 is here...
12:41<@peter1138>Hmm, is there any chance of adding a new target for MSVC?
12:41<@peter1138>One which defaults to not requiring DirectMusic :p
12:45<@peter1138>Ah, Celestar merged my changes :D
12:45<@peter1138>Looks like it still works ;)
12:46<@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?
12:46<@peter1138>The latter makes it easier to add sort types but is a bit over the top for just two sort types.
12:48<@peter1138>Tell me! :o
12:49*Belugas reads
12:50<@Belugas>the latter indeed
12:50<@Belugas>otherwise, it might ends up looking like cargo station sorting
12:50-!-nekx [] has quit [Read error: Connection reset by peer]
12:50<@Belugas>(if it's still there..)
12:50-!-nekx [] has joined #openttd
12:51<@Belugas>or filtering
12:58-!-Wezz6400 [] has joined #openttd
12:59-!-nkx [] has joined #openttd
12:59-!-nekx [] has quit [Read error: Connection reset by peer]
13:01-!-nekx [] has joined #openttd
13:01-!-nkx [] has quit [Read error: Connection reset by peer]
13:03-!-Singaporekid [] has quit [Quit: Leaving]
13:08<@peter1138>Gah, anyone familiar with OpenOffice calc?
13:09<@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...
13:13<frosch123>=TEXT(B2; "dd/mm/yyyy")
13:24-!-mikl [] has joined #openttd
13:35*peter1138 attempts to crash it.
13:37<Prof_Frink>peter1138: Drive an HST at it.
13:45<Eddi|zuHause> <- probably something for brianetta ;)
13:45<@peter1138>Celestar, pull ;)
13:56*Belugas wonders what aniation uses the "e" of ExtraPaletteValues
13:57*Belugas would eventually make a patch that will use fire animation and tranposed on "e" just to see waht will change
13:57<@Belugas>or somehting like that
14:03<@Belugas>brown to beige cycling
14:03<@Belugas>maybe someting in toyland, not sure
14:05<@Rubidium>SpComb: serious in what way?
14:06<SpComb>serious enough to have proper security vulnerabilities
14:06<SpComb>and/or security advisories
14:06<@Rubidium>that happens when they start reading the release notes
14:07<Ammler>new fs has a glitch, if I am logged in, date is replaced by my nick:
14:08<@Rubidium>if only the server would allow connecting from here
14:09<Ammler>sry, wrong link:
14:10<@peter1138>Still doesn't load, heh
14:10<@Rubidium>yeah, myimg is really doing proper copyright protection ;)
14:10<Ammler>was working well until now, :-(
14:11<@Rubidium>Ammler, then you broke it!
14:13<@Rubidium>works fine for me
14:14<@Rubidium>but I'll take a peek in the database
14:16<@Rubidium>seems like something went wrong during the upgrade for 3 users
14:17<@Rubidium>should be solved now
14:20<Ammler>he, I might know why
14:21<Ammler>I have prefixed my nick with a space to have all tasks from me in front, if I sort for authors :-)
14:21<Ammler>forgot, to rename it after
14:28-!-thgergo [] has left #openttd []
14:35<@Belugas>that is...
14:35<@Belugas>not worth it
14:36-!-mikl [] has quit [Quit: mikl]
14:36-!-Progman [] has joined #openttd
14:40-!-fonso [] has joined #openttd
14:44-!-Vessajono [] has quit [Quit: Changing server]
14:45<@peter1138>A is quite near the beginning...
14:46<hylje>" A" is closer
14:46<Eddi|zuHause>not if everyone else is called _ or [ or similar ;)
14:48<Prof_Frink>People like that should be shot.
14:49*Belugas agrees
14:49*orudge shoots Belugas
14:50*Rubidium reloads the last autosave of Belugas
14:50<@peter1138>I hope that's not a yearly autosave :o
14:50<+glx>Ammler: about FS, I guess you are using firefox
14:50<@peter1138>Or maybe he does... he'd be a bit younger :D
14:50<@Belugas>i have an autosave???
14:51-!-fonso is now known as [fonsinchen]
14:51<@Belugas>well... i guess I do, but he's not in school yet ^_^
14:51*[fonsinchen] is waiting to be shot
14:54<Ammler>glx: yes I do, it works now, btw.
14:55<Ammler>the space was still in front, so not the error...
14:57<+glx>firefox autofills the profile form with wrong data
14:57<CIA-5>OpenTTD: frosch * r14006 /trunk/src/vehicle_gui.cpp: -Codechange: Deduplicate some code.
15:00*Bjarni shoots [fonsinchen] for no apparent reason
15:00<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.
15:01-!-[fonsinchen] is now known as zombie-fonsinchen
15:01*hylje read the "de" as "re" as first
15:02<@Bjarni>that's how you create zombies
15:02<@Bjarni>let me show you that again
15:02*Bjarni shoots hylje for no apparent reason
15:02*hylje sees a pony zooming to the trajectory of the bullet and absorbing it
15:03*Bjarni zaps hylje with a tesla coil
15:03<hylje>you got that thing working?
15:03*Bjarni shoots hylje
15:04<hylje>that hurt!
15:04*zombie-fonsinchen gnawls on hyljes leg
15:04<hylje>help! help!
15:05<@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
15:06-!-kais58 [vircuser@] has quit [Read error: No route to host]
15:07*SpComb slaps hylje around a bit with a lame whale
15:08<@Belugas>hey! Leave the whales out of it, will you?
15:08*hylje parries with the help of a leek
15:08*Belugas pets the poor little whale
15:08*SpComb feeds zombie-fonsinchen into a C++ compiler
15:08-!-zombie-fonsinchen is now known as zombie^2-fonsinchen
15:09*SpComb disassembles zombie^2-fonsinchen and compares it against the origional
15:09-!-zombie^2-fonsinchen is now known as byte-salad
15:09*SpComb attempts to execute it
15:10-!-byte-salad [] has left #openttd [Kopete 0.12.7 :]
15:10<SpComb>that confused him
15:10-!-byte-salad [] has joined #openttd
15:10<hylje>that kinda implied a segfault
15:10*SpComb looks for the core dump
15:11<byte-salad>lesson learned: never execute a squared zombie
15:12*hylje hears a faint "braaaaains" from the general direction of SpComb
15:12<SpComb>myes, I'm reading the C++ FQA
15:12<SpComb>I was planning on doing a C++ course this semester
15:13*byte-salad refactors itself into human form
15:13-!-byte-salad is now known as fonsinchen
15:13<SpComb>I guess I'm still going to do it, but my attitude towards it is going to be kind of destructive
15:13<SpComb>trouble is, the course involves a long-term group project
15:13<SpComb>...writing code in C++
15:14<fonsinchen>iiggggh, humans!
15:15<@Belugas>yeah.. tell me about it...
15:15*Belugas shakes his head and dives
15:33-!-Purno [] has quit [Read error: Connection reset by peer]
15:36-!-Nev is now known as bleepy
15:46<@peter1138>436 lines removed, 224 lines added...
15:46-!-Roujin [] has quit [Quit: HydraIRC -> <- *I* use it, so it must be good!]
15:48<@peter1138>Hmm, whoops, it shows the 3rd road type :p
15:49<Eddi|zuHause>why was that never finished?
15:53-!-nkx [] has joined #openttd
15:53-!-nekx [] has quit [Read error: Connection reset by peer]
15:56<@Belugas>nice, peter1138:)
15:56-!-nkx [] has quit [Read error: Connection reset by peer]
15:56-!-nekx [] has joined #openttd
15:57<@peter1138>Belugas, you think so? Cool.
15:57<@peter1138>Part of the aim was to have more easily customizable menus.
15:59*Belugas is amused to see some of his comments and changes get deleted heheh... looks like you are good at cleaning his mess ;)
16:00<@Belugas>i worked a lot on the toolbar recently
16:00<@Belugas>mostly doing enums and such
16:00<@peter1138>Oh, did you?
16:00<@peter1138>The scenario map button is the only one that needed attention, I think.
16:03*Belugas nods
16:03<@Belugas>almost the only difference between the two toolbars
16:10-!-jni [] has quit [Remote host closed the connection]
16:10-!-jni [] has joined #openttd
16:11-!-nkx [] has joined #openttd
16:11-!-nekx [] has quit [Read error: Connection reset by peer]
16:13<CIA-5>OpenTTD: peter1138 * r14008 /trunk/src/newgrf_gui.cpp: -Fix (r14004): NewGRF preset drop down list not working
16:14<CIA-5>OpenTTD: peter1138 * r14009 /trunk/src/newgrf_gui.cpp: -Cleanup (r14008): Bad whitespace...
16:22-!-KritiK [] has joined #openttd
16:24-!-[com]buster [] has joined #openttd
16:24<Eddi|zuHause>when "speed" is 85, which unit is that?
16:25-!-Vikthor [] has joined #openttd
16:25<@Rubidium>depends on the vehicle type IIRC
16:27<Eddi|zuHause>it's in the rating calculation, nothing about vehicle types there
16:27<@Rubidium>and then in miles / 1.6 or miles / 3.2
16:28<Eddi|zuHause>and of course it has no comments ;)
16:28<@Rubidium>then it is the raw speed of the vehicle
16:28<frosch123>Eddi|zuHause: take a look at economy.cpp where it is assigned
16:28<@Rubidium>so for RVs and ships it yields more points per km/h than for trains
16:29<@Rubidium>hmm, or not
16:30<Eddi|zuHause>it only makes adjustments to RV
16:32<frosch123>'max_speed' has different units depending on vehicle type
16:32<frosch123>they should be those mentionen in newgrfspecs
16:32<Eddi|zuHause>that's the problem... the information is all over the place...
16:33<frosch123> <frosch123> they should be those mentionen in newgrfspecs <- except for aircraft
16:33-!-Zr40 [] has quit [Quit: Zr40]
16:33<frosch123>Eddi|zuHause: not everywhere, just economy.cpp, newgrf.cpp, roadveh_cmd.cpp, ship_cmd.cpp, aircraft_cmd.cpp and train_cmd.cpp
16:34<Eddi|zuHause>it's more than looking at a comment in station_base.h
16:35<frosch123>how long shall that comment be?
16:35<Eddi|zuHause>one line for each case...
16:36<Eddi|zuHause>or a hint where the information would be found
16:36*Rubidium assigns Eddi|zuHause to fix all documentation so we can document everything correctly
16:36<@Rubidium>cause apparantly fixing documentation when changing stuff is not enough
16:37<frosch123>also comments that refer to values defined in other placed are usally out of sync with the code
16:39-!-flowOver [] has quit [Read error: Connection reset by peer]
16:39<Eddi|zuHause>yes, i understand the dilemma ;)
16:42-!-nekx [] has joined #openttd
16:42-!-nkx [] has quit [Read error: Connection reset by peer]
16:43<Eddi|zuHause> ge->last_age = _cur_year - u->build_year; <- there is a possible overflow, last_age is a byte
16:48-!-frosch123 [] has quit [Remote host closed the connection]
16:51-!-welshdragon [] has joined #openttd
16:55<@peter1138>Oh well, night night.
16:56-!-SmatZ41 [] has joined #openttd
16:56-!-nekx [] has quit [Read error: Connection reset by peer]
16:56-!-nekx [] has joined #openttd
16:57<SmatZ41>unbelievable, free wifi hotspot here :-)
16:57<SmatZ41>thiugh I have to be outside and it's quite cold here :-P
16:57<@Belugas>mmh...FooBar did a good job on commenting action00for bridges, but he fucked up a little bit here and there...
16:57<@Belugas>hey SmatZ
16:58<SmatZ41>no place to land my notebook :-/
16:58-!-SmatZ41 [] has quit []
17:02-!-fonsinchen is now known as fonso
17:02-!-nekx [] has quit [Read error: Connection reset by peer]
17:03-!-nekx [] has joined #openttd
17:07-!-FauxFaux [] has joined #openttd
17:15-!-SmatZ41 [] has joined #openttd
17:15-!-Wezz6400_ [] has joined #openttd
17:15<SmatZ41>way too slow, 64kbps
17:16<SmatZ41>I don't understand how I could live with 28.8 modem for years..
17:18-!-fonso [] has left #openttd [Kopete 0.12.7 :]
17:21-!-Wolf01 is now known as Guest569
17:21-!-Wolfolo|AWAY [] has joined #openttd
17:21-!-Wolfolo|AWAY is now known as Wolf01
17:21-!-nekx [] has quit [Read error: Connection reset by peer]
17:22-!-nekx [] has joined #openttd
17:22-!-Wezz6400 [] has quit [Ping timeout: 480 seconds]
17:28-!-SmatZ41 [] has quit [Ping timeout: 480 seconds]
17:29-!-Guest569 [] has quit [Ping timeout: 480 seconds]
17:31-!-rortom [] has joined #openttd
17:32<@Belugas>bye guys
17:41<ln>bye girl
17:51-!-TinoM [] has quit [Quit: Verlassend]
17:53-!-nkx [] has joined #openttd
17:53-!-nekx [] has quit [Read error: Connection reset by peer]
17:54-!-[com]buster [] has quit [Quit: Operator, give me an exit]
18:09<CIA-5>OpenTTD: truebrain * r14010 /branches/noai/ (5 files in 2 dirs): [NoAI] -Add: added AIAirport::GetAirportType (Yexo)
18:40-!-ecke1 [~ecke@] has quit [Quit: ecke1]
18:43-!-sid3windr [] has joined #openttd
18:46<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... :)
18:47<@Bjarni>you want stereo vision?
18:47<sid3windr>no, a 2560x1024 world :)
18:47<rortom>i think multi monitor support
18:47<rortom>i want that too :\
18:47<sid3windr>I like to have some graphs open and such
18:47<rortom>its working under linux
18:48<rortom>but not under window
18:48<sid3windr>even just that would be awesome to put up on secondary monitor
18:48<TinoDidriksen>If you use windowed mode and make the resolution large enough, depending on OS setup, it would span across monitors?
18:48<@Bjarni>you are in luck
18:48<sid3windr>yeah, I guessed it would work under linux
18:48<@Bjarni>it's open source
18:48<sid3windr>TinoDidriksen: good point!
18:48<@Bjarni>you are able to code this yourself
18:48<rortom>haha :p
18:48<sid3windr>Bjarni: how cliché
18:48<@Bjarni>but true
18:48-!-Farden [] has quit [Quit: ( :: NoNameScript 4.2 :: )]
18:48<rortom>TinoDidriksen: it wont reach
18:48<sid3windr>except not really
18:49<ben_goodger>Bjarni: that's almost never a useful response. nobody ever asks for features who can write them by themselves
18:49<sid3windr>given the source code and a compiler, it does not automatically mean a person is able to do it.
18:49<@Bjarni>I'm not coding full screen support for multiple monitors for you
18:49<@Bjarni>it would be a huge task and I wouldn't know where to start :s
18:49<sid3windr>that's not what I asked either, or at least, not directly :)
18:49<sid3windr>I was just wondering if there was a place to "officially suggest" it
18:49<sid3windr>as I have no clue how to do it either
18:50<sid3windr>I saw the suggestion list in the wiki but it didn't look like someting I'd just go and edit right away
18:50<@Bjarni>we have a suggestion list on the wiki?
18:50<sid3windr>rortom: you can't get the windowed version large enough? or what do you mean with "it doesn't reach"
18:50<@Bjarni>never read it
18:50<@Bjarni>which makes me wonder how useful it is
18:50<sid3windr>not exactly "suggestion list"
18:50<sid3windr>rather stuff people are working on already
18:51<rortom>sid3windr: it fits for 1280x1024 for 1 monitor and 1/4 of the second, thats the max under windows for strange reasons
18:51<sid3windr>so "proper" way is to discuss it in the forum or something?
18:51<sid3windr>rortom: oh, that's a pity..
18:51<rortom>there must be a reason
18:51<@Bjarni>but you can alter a define somewhere to allow the window to be bigger
18:51<rortom>oh, thanks for the hint :D
18:52<rortom>*looking at the code*
18:52<@Bjarni>ludde added this define for some reason but he never told why
18:52<rortom>great ;)
18:53<@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
18:53<sid3windr>mmm. I was just wondering how openttd would look on the testmonitor we had at work for a short while
18:53<rortom>do you have any idea where i could find it?
18:53<@Rubidium>just use a sufficiently new version OpenTTD for that
18:53<sid3windr>I'll take a look at the source for that too
18:53<sid3windr>then find out how to compile it on windows.
18:53<@Rubidium>sid3windr: try a recent nightly first
18:53<@Bjarni>Rubidium: we got rid of that define?
18:53<sid3windr>okay, will do
18:55<rortom>*testig if the limitation is still there*
18:56-!-Digitalfox [] has joined #openttd
18:57*sid3windr will do that tomorrow, off to bed now
18:57<sid3windr>thanks for the tip :)
18:59<rortom>its working :D
18:59<rortom>thank you all :D
18:59*Rubidium wonders why nobody noticed it until I told I removed the limitation
19:00<@Bjarni>I would have if you had donated a monitor big enough for me to notice :P
19:00<@Rubidium>1920x1200 is more than enough for a laptop!
19:08-!-bleepy [] has quit [Ping timeout: 480 seconds]
19:10-!-Volley [~worf@] has joined #openttd
19:11-!-nekx [] has joined #openttd
19:11-!-nkx [] has quit [Read error: Connection reset by peer]
19:11-!-Wolf01 [] has quit [Quit: Once again the world is quick to bury me.]
19:12-!-Vikthor [] has quit [Quit: Leaving.]
19:22-!-Volley [~worf@] has quit [Remote host closed the connection]
19:29-!-Bjarni [] has quit [Quit: Leaving]
19:37-!-David [] has joined #openttd
19:37-!-David was kicked from #openttd by DorpsGek [Wrong channel. Retry in #openttdcoop.]
19:42-!-dlunch [~dlunch@] has quit [Ping timeout: 480 seconds]
19:44-!-Progman [] has quit [Remote host closed the connection]
19:50-!-rortom [] has quit []
19:59<ln>sid3windr: i've run OTTD in fullscreen on two monitors.
20:00-!-curson [] has quit [Quit: If everything seems to be going well, you have obviously overlooked something.]
20:05-!-spence [~Admins@] has joined #openttd
20:05<spence>We're Now Seeking For A New IRCop, For More Info Type /Server -m IRC.P2PChat.Net -j #Morpheus
20:05-!-spence [~Admins@] has left #openttd []
20:08-!-dlunch [~dlunch@] has joined #openttd
20:09-!-grumbel [] has quit [Quit: Client exiting]
20:10<ben_goodger>there's so little to do...
20:13-!-Wezz6400_ [] has quit [Quit: Zzz]
20:19-!-bleepy [] has joined #openttd
20:21-!-Rich [~Zephyris@] has quit [Quit: ChatZilla 0.9.83 [Firefox 3.0.1/2008070208]]
20:31<Eddi|zuHause>if you ever think there is nothing to do, go to the suggestions forum, pick a random thread, and start implementing what they request there :p
20:32-!-Eddi|zuHause [] has quit []
20:33-!-Eddi|zuHause [] has joined #openttd
20:35-!-KillaloT [] has quit [Quit: HydraIRC -> <- Go on, try it!]
20:49-!-elmex [] has quit [Remote host closed the connection]
20:51<ben_goodger>well, I can't actually write C
20:51<Fennec>C code. C code run. Run, code, run. plz?
20:52<ben_goodger>now, give me a python API and I'll be all over it :P
20:52<Fennec>bah :P
20:52<Eddi|zuHause>languages are all the same...
20:52*Fennec should stare at the openttd source some time :)
20:53<Fennec>Eddi|zuHause: ha! Try using anonymous closures in C and see where you get! :)
20:55*Fennec likes C anyway tho :)
20:56<Eddi|zuHause>i'm not quite sure what "anonymous closures" are right now, but the openttd code uses all kinds of concepts that were not even invented when C was defined
20:56<Fennec>earlier today I got to see the Perl debugger crash on some insane overloading semantics :P you never have to deal with those in C :)
20:57<Fennec>Eddi|zuHause: little things like, oh, $a = 4; my $b = sub { return $a; }; $a = 5; print $b->(); # prints 4
20:58<Fennec>(that's perl)
20:58<Fennec>great for metaprogramming.
21:00<Eddi|zuHause>what does the "my" do there?
21:01-!-Nev [] has joined #openttd
21:01<Fennec>yes. my creates a local variable. as opposed to local, which does not. yes, this is quite possibly the stupidest single thing in Perl. :P actually the first $a could have a 'my' on it to. but anyway.
21:02<Eddi|zuHause>i'm stil not sure what you are trying to tell me
21:04<Fennec>sub wrap_maker { my ($tag) = @_; return sub { my ($html) = @_; return "<$tag>$html</$tag>"; } my $bold = wrap_maker("b"); print $bold->("i am in bold"); # prints "<b>i am in bold</b>"
21:04<Fennec>I'm saying, in reference to <Eddi|zuHause> languages are all the same...
21:04<Fennec>that there's no trivial analogue to that in C.
21:06-!-nekx [] has quit [Read error: Connection reset by peer]
21:07-!-bleepy [] has quit [Ping timeout: 480 seconds]
21:07<Fennec>obviously, the same results can always be achieved, but they involve hanging on to more data structures instead of having the compiler implicitly hang on to them for you.
21:09<Eddi|zuHause>yes, but i expect someone that says "i can ONLY program in language XYZ" to be less theoretically sophistically and not very abusive of extreme language features
21:11<Fennec>heh. "abusive of extreme language features" ---> don't look up Test::Resub on CPAN, it'll scare ya :P
21:11<Eddi|zuHause>and that last line of yours can easily be done with C++-templates
21:12<Fennec>hmm? can it be done with said templates when I get my tag name and formatting metadata from user input or a database setting somewhere instead of at compile-time?
21:13<Eddi|zuHause>you can disable any argument by changing the requirements on the fly... that does not make it a good discussion style
21:13<Fennec>I mean, there's certainly ways to go about doing it (make yourself a new class which stores an appropriate interface and has an invocation technique). it's just an entirely different way of going about doing it.
21:14<Eddi|zuHause>and you're certainly not going to sell me perl...
21:14<Fennec>therefore, I simply contend, all languages are not the same.
21:15<Eddi|zuHause>they are, with a sufficient level of abstraction
21:15<Fennec>naah, I'd reccomend more Ruby-ish if you're doing something new and are otherwise interested in that direction I think.
21:15*Fennec shrugs.
21:16-!-Nev [] has quit [Ping timeout: 480 seconds]
21:16<Fennec>with a sufficient layer of abstraction, a fish and a banana are the same. :)
21:16<Fennec>but anywho ./~
21:16<Fennec>i like C too
21:16<Eddi|zuHause>yes, that is what i am saying
21:16<Eddi|zuHause>you can eat both
21:17<Eddi|zuHause>there is no inherent reason why you would say "i can only eat bananas"
21:18-!-KritiK [] has quit [Quit: Leaving]
21:19<@Belugas>what about : i have no teeth?
21:21<ben_goodger>or if you were a vegan.
21:21<Eddi|zuHause>i would actually believe you :p
21:21<ben_goodger>or a vegetarian, or if you were allergic to fish
21:22<Eddi|zuHause>and if you are allergic to C, you should probably stay far away from here ;)
21:22<Eddi|zuHause>otherwise you are just making up excuses not to try to learn it
21:23*Belugas was once allergic to C, but thanks to ttrs2, he got kinda cured...
21:24-!-welshdragon [] has quit [Quit: Leaving]
21:27-!-welshdragon [] has joined #openttd
21:28<CIA-5>OpenTTD: belugas * r14011 /trunk/src/graph_gui.cpp:
21:28<CIA-5>OpenTTD: -Codechange: not required to define an enum which was just the representation of another.
21:28<CIA-5>OpenTTD: If you want to customize it more easily, why not a simple const of said enum value?
21:28<Eddi|zuHause>anyway, a "bold=tag_factory('b')" is not a revolutionary programming pattern invented by perl...
21:56-!-Zahl [] has quit [Quit: (~_~]"]
21:56-!-welshdragon is now known as welshdra-gone
21:58-!-Dred_furst [] has quit [Quit: Leaving]
22:00<Yexo>is it just me or is bugs/svn/hg down?
22:00<@Belugas>Yexo, we gave TTD Dude the same answer :D
22:00<Yexo>I read it :)
22:01<Yexo>that should teach him to read hext time
22:01<@Belugas>bugs seems down
22:03<@Belugas>svn seems fine
22:04<@Belugas>maybe a momentary lapse of IP-whatever
22:04<@Belugas>no, bugs is really down
22:04<Yexo>I can use svn from the command line, but not the web interface
22:15<@Belugas>so it means the web services are down, but not the www one
22:15<@Belugas>i thiunk
22:15<@Belugas>looks like a job for TrueBrain that must be sleeping
22:16<Yexo>hg isn't accessable at all
22:22<@Belugas>sorry, nothing i can do :(
22:22<@Belugas>and damned... DoDrawString is a TINY little bit EVIL
22:23<@Belugas>now... time to sleep
22:23<@Belugas>good night
22:36-!-lobster_MB [] has quit [Ping timeout: 480 seconds]
22:36-!-glx [] has quit [Quit: bye]
---Logclosed Thu Aug 07 00:00:11 2008