Back to Home / #openttd / 2008 / 07 / Prev Day | Next Day
#openttd IRC Logs for 2008-07-31

---Logopened Thu Jul 31 00:00:44 2008
00:25<Celestar>morning
01:01<Celestar>peter1138: how's progress?
01:12-!-ecke [~ecke@213.195.202.130] has quit [Read error: Connection reset by peer]
01:13-!-ecke [~ecke@213.195.202.130] has joined #openttd
01:30-!-Gekz_ [~brendan@123-243-206-102.static.tpgi.com.au] has joined #openttd
01:31-!-ecke [~ecke@213.195.202.130] has quit [Read error: Connection reset by peer]
01:31-!-Gekz [~brendan@123-243-206-102.static.tpgi.com.au] has quit [Ping timeout: 480 seconds]
01:37<@peter1138>Hmm, well...
01:43<@peter1138>I made some progress. Cargo without destinations is now handled better.
01:47-!-Rexxars [~rexxars@85.19.218.24] has quit [Ping timeout: 480 seconds]
01:47-!-TinoM| [~Tino@i59F55DED.versanet.de] has quit [Quit: Verlassend]
01:47<CIA-5>OpenTTD: peter1138 * r13890 /trunk/src/transparency_gui.cpp:
01:47<CIA-5>OpenTTD: -Codechange: Simplify drawing of invisibilty buttons in the transparency gui --
01:47<CIA-5>OpenTTD: the real widgets above already have coordinates so there is no need to hardcode
01:47<CIA-5>OpenTTD: them again. As an added bonus the invisibility buttons now line up properly.
01:50-!-TinoM [~Tino@i59F55DED.versanet.de] has joined #openttd
01:52<@peter1138>SmatZ, whatever happened to using real widgets where possible?
02:00-!-bleepy [bleepy@5ad34870.bb.sky.com] has joined #openttd
02:00<ccfreak2k>The OpenGL blitter thread seems to have stopped dead.
02:16-!-ecke [~ecke@213.195.202.130] has joined #openttd
02:42-!-Ridayah [~ridayah@12-208-15-67.client.mchsi.com] has quit [Ping timeout: 480 seconds]
02:49<@peter1138>Celestar, ping?
02:59<Celestar>peter1138: pong
02:59<Celestar>peter1138: let me read through your changes first :D
03:00<@peter1138>I'm getting stuff not unloading sometimes :/
03:01<Celestar>peter1138: me too
03:01<Celestar>apparently
03:01<@peter1138>Of course, now I'm looking for it it doesn't happen :o
03:02<Celestar>other than that, do we get any more asserts and crap?
03:03<@peter1138>I've not had one for a while.
03:04<@peter1138>Hmm, non-gradual loading is totally busted.
03:05<@peter1138>Works if there's only one packet.
03:07<Celestar>peter1138: I'm pretty sorry, but I have little time today to work on it :(
03:07<Celestar>peter1138: maybe this afternoon
03:07<Celestar>but I'll keep a watch on changes :D
03:08<Celestar>peter1138: but I'll be online anyway, so just keep talking (=
03:08-!-mikl [~mikl@cpe.ge-0-2-0-812.0x50c774be.boanqu1.customer.tele.dk] has joined #openttd
03:11-!-fonso [~fonso@brln-d9bacf2b.pool.mediaWays.net] has joined #openttd
03:14<Celestar>peter1138: is it me or is the amount of passengers generated nothing short of insane? :P
03:14<@peter1138>It seems quite high, but we've not modified that, have we?
03:16<Celestar>not that I know of
03:17<Celestar>are we sure they're not multiplying? :P
03:18*peter1138 tidying stuff up.
03:19<@peter1138>I *think* that these are the same, except for performance and additional looping:
03:19<@peter1138>packets.remove(cp); it = packets.begin();
03:19<@peter1138>it = packets.erase(it);
03:19*peter1138 tests
03:20<Celestar>peter1138: when you remove and item from a container, the the iterator that points to the delete object becomes invalid
03:20<@peter1138>yes
03:20<Celestar>s/and/an
03:20<@peter1138>hence the "it = "
03:21<@peter1138>erase is also more efficient than remove
03:21<@peter1138>remove looks for the value in the list
03:21<@peter1138>erase already knows which entry to remove
03:21<@peter1138>and then returns the next entry
03:21<Celestar>but whe start from "begin", don't we?
03:21<Celestar>(in the first iteration I mean)
03:21<Celestar>er first version
03:21<@peter1138>yeah
03:22-!-Doorslammer [Doorslamme@PIPP-p-203-54-229-69.prem.tmns.net.au] has joined #openttd
03:22<@peter1138>Basically
03:22-!-GoneWacko [~foo@adsl-58.35.Static.ssp.fi] has joined #openttd
03:23<@peter1138>See my last commit.
03:23<Celestar>peter1138: aren't we usually removing the FIRST container of the list with that statement?
03:24<Celestar>er no
03:25<@peter1138>hmm, committed a debug message again ;)
03:25<Celestar>I concur with your changes (=
03:25<Celestar>peter1138: he.
03:25<@peter1138>10 lines gone, 2 lines added :D
03:26<Celestar>I have a "svn diff | grep fprintf && echo 'debug messages remaining'" script :P
03:26<@peter1138>hehe
03:28<Celestar>peter1138: about my helper functions in routing.cpp .. shouldn't we move them into the order class at some point?
03:28<@peter1138>Mmm, possibly should do.
03:28<Celestar>k .. will do
03:32<@peter1138>Gah, my PC's too fast
03:35<Ammler>good morning, nice topic :-)
03:39<Ammler>as you are working that hard on the cargo destinations, a small question for non-dest code about transfer: would it be possible to "mark" cargo, so not the vehicels with same orders do load it again?
03:40<Ammler>(i.e. airport<->city transfer)
03:40<@peter1138>who cares, it works properly with destinations... ;)
03:41<@peter1138>Or would do if these bugs were not there :o
03:44<Ammler>heh
03:45<fonso>new version of diagonal levelling and clearing without '°' and (uint)-1: http://www.tt-forums.net/download/file.php?id=95264
03:45<Celestar>fonso: nice :d
03:45<Celestar>:D
03:45<Celestar>I hope I manage to test it this afternoon ;)
03:48<Ammler>Celestar: peter1138: if you think the code is ready for MP testing, we would like to do it, that was one of the failing point of all old pax dest patches...
03:49<Celestar>Ammler: will take a few more changes. the unloading/loading not not yet work corretly
03:49<Celestar>correctly*
03:52<@peter1138>It is MP safe though ;)
03:53<@peter1138>It's odd. The vehicle will not unload properly for a few trips, and then suddenly it does. :o
03:55-!-fonso [~fonso@brln-d9bacf2b.pool.mediaWays.net] has left #openttd [Kopete 0.12.7 : http://kopete.kde.org]
03:56<Celestar>meh. changing order_base.h sucks too
03:59<@peter1138>Got it.
03:59<Celestar>you did? :D
04:00<Celestar>peter1138: can we fix that warning in economy.cpp:1440. We should put parenthesis around (a & b)
04:04<Celestar>HEM
04:05<Celestar>after moving the helps into the order class, I'm getting undeffed references :S
04:05<@peter1138>Hmm?
04:08<Celestar>meh
04:10<Celestar>peter1138: does it work now? :D
04:11<Celestar>peter1138: http://www.fvfischer.de/helpercleanup.diff <= can you have a look at this?
04:11<@peter1138>Seems to, however I'm sure it is not all correct yet.
04:11-!-fmauNekAway is now known as fmauNeko
04:12<@peter1138>Indeed, I'm right, it's not :D
04:18<Celestar>peter1138: heh. the payment is WAAAAYYY off sometimes
04:18<@peter1138>:o
04:18<@peter1138>I'm rewriting MoveTo :o
04:18<Celestar>or the display of it (=
04:19<@peter1138>Should all work now, heh
04:19*peter1138 tests first though
04:22*peter1138 sees
04:25-!-fmauNeko is now known as fmauNekAway
04:25*peter1138 tests again
04:40<@peter1138>Ah...
04:42<@peter1138>Maybe this time ;)
04:42<@peter1138>it = packets.erase(it);
04:42<@peter1138>then ++it
04:42<@peter1138>in the for
04:42<@peter1138>is not good :)
04:43<@peter1138>GOT THE BASTARD
04:45<Forked>victory!
04:46<@peter1138>Celestar: committed.
04:47<@peter1138>\o/
04:47<Celestar>wee :D
04:49<Celestar>peter1138: now for the cleanup? :D
04:54<Celestar>peter1138: we're not saving the cargodest yet, do we?
04:54<@peter1138>Nope.
04:54<@peter1138>Doesn't matter yet ;)
04:55<@peter1138>What with 'no destination' being handled sanely now.
04:56<@peter1138>However, let me add that.
04:56<Celestar>peter1138: just if we don't add it, we're not MP-save I'd say (=
04:57<@peter1138>Shh!
04:57*Celestar hides
04:58<@peter1138>There
04:59<@peter1138>So basically...
04:59<@peter1138>We just need to do proper destination selection in UpdateStationWaiting
05:00<@peter1138>Oh, and patch options ;)
05:00<@peter1138>One option or multiple, do you think?
05:01<@peter1138>Passenger: On/Off, Mail: On/Off, Valuables: On/Off, Cargo: On/Off or...
05:01<@peter1138>Destinations: Passengers/Passengers+Mail/etc/All
05:02<Kloopy>The latter makes much more sense
05:02<Kloopy>To me.
05:02<Kloopy>Not that you were asking. :P
05:02<@peter1138>Actually, I was asking.
05:02<Kloopy>Hehe
05:03<Celestar>peter1138: Passenger: Free, destinations, Mail: Free, destinations, Valuables/Gold: Free, maxacceptence, destinations, Other: Free, maxacceptance, destinations
05:03<Kloopy>Individual settings is over complicating it, I'd suggest. Having one option with varying levels of "difficulty" just seems more sensible.
05:03<Ammler>isn't it possible more generic (newcargos)
05:04<@peter1138>Ammler, i'd based it on the 'town effect' property, so passenger destinations would apply for both passengers and tourists, for example
05:04<Ammler>specially the tourists :-)
05:04<@peter1138>Celestar, what to do if a station is removed?
05:04<Ammler>ah :-)
05:05<@peter1138>Just update all packets with that destination as having no destination?
05:05<Celestar>peter1138: I'd say yes
05:05<Celestar>peter1138: or assign a new station randomly :)
05:05<Ammler>you do not have a branch at ottd for it, it seems?
05:05<Celestar>Ammler: nope, once it works, it'll go into trunk hopefully :D
05:05<Celestar>(together with YAPP :P)
05:06<Ammler>monster commit
05:06<@peter1138>Ammler, it's in hg, on my PC ;)
05:06<@peter1138>Right, Celestar's cleanup
05:06<Kloopy>They would (will) both be awesome additions. :)
05:07<Celestar>peter1138: let's hope I didn't mess something up in the cleanup :D
05:07<Celestar>peter1138: I'll go on cleaning the routing code
05:08<Celestar>Ammler: Kloopy we still don't have decided how to work with the boost inclusion
05:08<Kloopy>boost inclusion?
05:09<Celestar>Kloopy: our cargodest implementation depends on boost
05:10<@peter1138>Celestar, as long as you cut & pasted most of it it should be fine :D
05:10<Celestar>I did
05:10<Kloopy>..and what's boost? :)
05:10<Celestar>and took at the arguments
05:10<Celestar>Kloopy: google boost, first entry :P
05:10<@peter1138>GAH
05:10<@peter1138>That segmentation fault is still there :o
05:11<@peter1138>Am I missing an update?
05:11<Kloopy>Aha.. :)
05:11<Ammler>Celestar: boost is installed here per default...
05:11<Ammler>min c++ env.
05:11<@peter1138>print this
05:11<@peter1138>$5 = (const Order * const) 0xd7b6e0
05:11<Ammler>(at least, I never did it self :-)
05:11<@peter1138>print this->prev
05:11<@peter1138>$6 = (Order *) 0x69a9000069a9
05:12<Ammler>(version 1.33.1)
05:12<@peter1138>(not a valid pointer)
05:12<Celestar>peter1138: not that I know of
05:12<Celestar>I didn't get it yet
05:13<@peter1138>I got it from loading a large game
05:13<Celestar>peter1138: I see. I still wanna get off this ugly ugly buffersize variable somehow, or do we leave it there?
05:20-!-Progman [~progman@p57A1D1E3.dip.t-dialin.net] has joined #openttd
05:21<Celestar>peter1138: what is SmallVector and why are we using this instead of vector?
05:23<@peter1138>Originally performance and ability to specify allocation chunk size
05:24<@peter1138>And a custom allocation method suited for where it originally went
05:28*Celestar wonders whether the vehicle factors are taken into account
05:30*Celestar tests it
05:30-!-ecke [~ecke@213.195.202.130] has quit [Quit: ecke]
05:33-!-ecke [~ecke@213.195.202.130] has joined #openttd
05:35<ln>is there an A380 already?
05:36<blathijs>What's an A380?
05:36<blathijs>Airplane?
05:36<ln>yes, sir.
05:37<Celestar>ln: yes.
05:37<ln>but in OTTD?
05:37<@peter1138>There's probably a GRF file containing one.
05:37<Celestar>ln: yes.
05:37<Celestar>ln: AvAircraft 8 contains them
05:38<ln>hmm... sounds like something that one has to download and install separately.
05:38-!-KillaloT [~killalot@0x5738ccc3.rdnqu1.dynamic.dsl.tele.dk] has joined #openttd
05:39<@peter1138>Welcome to the world of add-on graphics.
05:39<Ammler>ln: never used GRFs yet?
05:39<ln>Ammler: sure, the tram grf.
05:40<ln>but I don't see why an A380 could not be integrated into the standard OTTD.
05:41<Ammler>trams aren't integrated too, just disbributed with it...
05:41<Ammler>!s/too/either/
05:42<Celestar>ln: if you get the authors permission to include it (=
05:43<Ammler>Celestar: not sure IF that would be enough :-)
05:44-!-Vikthor [~Vikthor@snat1.spoje.net] has joined #openttd
05:46<@peter1138>ln, because we don't change the default vehicles.
05:47<ln>peter1138: i'm not talking about changing but adding new.
05:48<@peter1138>We don't do that either. That would mess up savegames as IDs would change.
05:48<@peter1138>And, of course, because NewGRF is there to do that job.
05:48-!-fmauNekAway is now known as fmauNeko
05:49<ln>the design is not very extendable then.
05:49<Celestar>peter1138: shouldn't we .clear() the RoutingVectorList before populating it, just in case?
05:50<Celestar>peter1138: I'm just including that in my cleanup
05:50<Noldo>ln: which design?
05:50<ln>Noldo: design of OTTD.
05:52<Noldo>it is, through newgrf
05:53<Ammler>ln: you sound like someone, who just joined this channel :-)
05:53<@peter1138>Ammler, well, ln has never paid any attention to what goes on :)
05:54<@peter1138>Celestar, no, it's clean by default.
05:54<ln>peter1138: i have, but then i noticed it doesn't make any difference.
05:54<ln>of course i know adding any new small feature requires rewriting half of the game.
05:55<@peter1138>Celestar, oh... Actually we could do. And then cache the list in the window, or... something.
05:56<Celestar>peter1138: I se
05:56<Celestar>e
06:00<ln>http://users.utu.fi/lanurm/ottd/tramline2.png
06:06<ln>a conversation killer
06:08<Gekz_>nice.
06:15<SpComb>ln! Assembly!
06:18<ln>i'm not there. i was once.
06:24-!-Bjarni [~Bjarni@0x50a41670.virnxx14.dynamic.dsl.tele.dk] has joined #openttd
06:24-!-mode/#openttd [+o Bjarni] by ChanServ
06:25-!-fonso [~fonso@brln-d9bacf2b.pool.mediaWays.net] has joined #openttd
06:26<ln>King of Denmark!
06:27-!-Mucht [~Martin@chello080109200215.3.sc-graz.chello.at] has quit [Remote host closed the connection]
06:30-!-Brianetta [~brian@client-86-27-108-163.brnt.adsl.virgin.net] has joined #openttd
06:33<Celestar>peter1138: around?
06:35<@peter1138>Yes
06:36<Celestar>peter1138: what's on the todo-list next?
06:36<Celestar>peter1138: http://www.fvfischer.de/cleanup.diff <= some minor cleanups and cleaning of the debug levels
06:37<Celestar>peter1138: standby there's some crap in it
06:38-!-Mucht [~Martin@chello080109200215.3.sc-graz.chello.at] has joined #openttd
06:38<Celestar>peter1138: reload :D
06:40<Celestar>hm .. I'm stuck in an infinite loop somwhere
06:40<Celestar>in a very large savegame
06:40<@peter1138>:o
06:44<Celestar>hm .
06:44<Celestar>there's a station without a vertex or something :o
06:44<Celestar>293 stations, 292 caches
06:47<@peter1138>Hmm, how odd.
06:48<Celestar>apparently
06:48<Celestar>too much debug output for the time being :P
06:50<Celestar>segfault
06:50<Celestar>getting there :P
06:50<@peter1138>H
06:50<@peter1138>mm
06:51<@peter1138>I've got a save game with segfaults the moment it's unpaused ;)
06:51<Celestar>openttd: /home/vici/openttd-peter/src/routing.cpp:105: void Routing_t::AddRoute(const Order*, const Order*, VehicleType): Assertion `from->GetDestination() < num_vertices(RouteNetwork)' failed.
06:51-!-fmauNeko is now known as fmauNekAway
06:52-!-fmauNekAway is now known as fmauNeko
06:52<@peter1138>(gdb) print this->hopcache.size()
06:52<@peter1138>$6 = 465
06:52<@peter1138>(gdb) print from
06:52<@peter1138>$7 = 588
06:53*peter1138 ponders...
06:53<@peter1138>I'm guessing it's deleted stations
06:53<Celestar>peter1138: I'm just loading a savegame
06:54<Celestar>how are deleted stations there?!
06:54<@peter1138>Me too.
06:54<@peter1138>They aren't, but you'll have gaps between StationIDs
06:54<Celestar>I see
06:54<Celestar>let's see
06:55<Celestar>just pipe the debug output and grep for the Added vertices
06:55<@peter1138>(gdb) print this->hopcache.size()
06:55<@peter1138>$6 = 465
06:55<@peter1138>(gdb) print from
06:55<@peter1138>$7 = 588
06:55<@peter1138>errDEBUG(routing, 3, "Vertex %d added to routing network for <%s> %d", vtx, buffer, index);
06:56<Celestar>dbg: [routing] Vertex 291 added to routing network for 294
06:56<Celestar>got it
06:56<@peter1138>dbg: [routing] Vertex 464 added to routing network for <unknown destination> 769
06:56<@peter1138>hh
06:57<Celestar>peter1138: yeah we need to take the station name printing out again for add/remove vertex. it's already freed, resp. not yet allocated
06:58<@peter1138>,...,...VertexDescriptor vtx;
06:58<@peter1138>,...,...do {
06:58<@peter1138>,...,...,...vtx = add_vertex(RouteNetwork);
06:58<@peter1138>,...,...} while (vtx != index);
06:58<@peter1138>nasty hack :p
06:58<Celestar>peter1138: that's what I did now
06:58<Celestar>it's no hack
06:58<Celestar>they'll be empty and reused when a station is added
06:59<@peter1138>hopcache size is wrong too :o
06:59<Celestar>yeah
06:59<Celestar>peter1138: because when you add a vertex you have to add a hopcache/dirty entry for it ;)
06:59<Celestar>dbg: [routing] Vertex 172 added to routing network for 172
06:59<Celestar>dbg: [routing] Vertex 173 added for empty station. Continuing
06:59<Celestar>dbg: [routing] Vertex 174 added for empty station. Continuing
06:59<Celestar>dbg: [routing] Vertex 175 added for empty station. Continuing
06:59<Celestar>dbg: [routing] Vertex 176 added to routing network for 176
07:00<Celestar>peter1138: reload: http://www.fvfischer.de/cleanup.diff
07:00<Celestar>segfalt
07:00<Celestar>(gdb) p this
07:00<Celestar>$1 = (Cannot access memory at address 0x11
07:00<Celestar>:o
07:01<Celestar>BAH
07:01*Celestar rebuilds with debug 3
07:01<@peter1138>Your loop is wrong
07:01<@peter1138>Oh
07:01<@peter1138>No, you left a dirty.push_back in
07:01<@peter1138>Although that shouldn't actually break it, just add too many
07:03<@peter1138>Hmm
07:03<Celestar>then remove the superfluous one ;)
07:04-!-Alberth [~hat@a82-95-164-127.adsl.xs4all.nl] has joined #openttd
07:06<Celestar>(gdb) p order
07:06<Celestar>$4 = (Cannot access memory at address 0x11#
07:06<Celestar>?!
07:06<@peter1138>Still getting messed up orders? :o
07:06<Celestar>the address of the pointer is wrong?!
07:07<Celestar>p this->GetNextOrderCyclic()
07:07<@peter1138>See what i pasted 2 hours ago :p
07:07<Celestar>$7 = (Cannot access memory at address 0x11
07:07<Celestar>:o
07:08<Celestar>peter1138: what? :P
07:08<@peter1138>(gdb) print this
07:08<@peter1138>$1 = (const Order * const) 0xe914d8
07:08<@peter1138>(gdb) print this->prev
07:08<@peter1138>$2 = (Order *) 0x35ab000035ab
07:08<@peter1138>this->next is null
07:08<Celestar>er no
07:09<Celestar>p this->next
07:09<Celestar>$8 = (Cannot access memory at address 0x11
07:09<@peter1138>in my case
07:09<@peter1138>obviously
07:10<@peter1138>Hmm, where is order->prev set?
07:10<Celestar>er..
07:10<Celestar>&v->orders[v->cur_order_index]; is NOT part of v->orders in this case :o
07:10<@peter1138>v->cur_order_index is out of range?
07:11<Celestar>no
07:11-!-Ridayah [~ridayah@12-208-15-67.client.mchsi.com] has joined #openttd
07:11-!-LilDood [~IceChat7@cpc2-bolt5-0-0-cust370.manc.cable.ntl.com] has joined #openttd
07:11<Celestar>but v->orders[v->cur_order_index] prints TOTAL crap
07:11<Celestar>it doesn't point to an order
07:11-!-Wezz6400 [~Wezz6400@ndb.demon.nl] has joined #openttd
07:12<Celestar>well it points into the order pool apparently, but not onto the beginning of an order or something
07:12<@peter1138>Linked list, not array?
07:12<Celestar>p v->orders[v->cur_order_index].dest
07:12<Celestar>$22 = 55224
07:12<Celestar>p v->orders[v->cur_order_index].type
07:12<Celestar>$23 = 83 'S'
07:12<Celestar>this doesn't look like a clean order for me
07:12<Celestar>to me
07:13<Celestar>WTH
07:13<Celestar>v->orders[v->cur_order_index] doesn't point anywhere NEAR the Order pool
07:14<Celestar>oh yes it does, but ..
07:14<Celestar>peter1138: PASTE STORM
07:14<Celestar>(gdb) p v->orders
07:14<Celestar>$25 = (Order *) 0x8434618
07:14<Celestar>(gdb) p v->orders->next
07:14<Celestar>$26 = (Order *) 0x8444ec0
07:14<Celestar>(gdb) p v->orders->next->next
07:14<Celestar>$27 = (Order *) 0x8444ed8
07:14<Celestar>(gdb) p v->orders->next->next->next
07:14<Celestar>$28 = (Order *) 0x8444ef0
07:14<Celestar>(gdb) p v->orders->next->next->next->next
07:14<Celestar>$29 = (Order *) 0x8444f08
07:14<Celestar>(gdb) p v->orders->next->next->next->next->next
07:14<Celestar>$30 = (Cannot access memory at address 0x0
07:15<Celestar>(gdb) p (Order *)&(v->orders[v->cur_order_index].type)
07:15<@peter1138>as i said
07:15<Celestar>$31 = (Order *) 0x843467e
07:15-!-Zahl [~Zahl@g229214104.adsl.alicedsl.de] has joined #openttd
07:15<@peter1138>that's a linked list, not an array
07:15<Celestar>the operator[] for the Order is not working properly
07:15<Celestar>isn't the [] operator overloadded for pool items?
07:15<@peter1138>...
07:15<@peter1138>orders is a pointer to a pool item, not a pool item.
07:16<Celestar>...
07:16<Celestar>cur_order_index is NOT meant to be used to access pool elements
07:16<@peter1138>,...curr = v->orders;
07:16<@peter1138>,...for (int skip = 1; skip != v->cur_order_index; skip++) {
07:16<@peter1138>,...,...curr = curr->next;
07:16<@peter1138>,...}
07:16<@peter1138>sort of thing
07:17<Celestar>peter1138: nope GetVehicleOrder :)
07:17<@peter1138>Right
07:17<@peter1138>Maybe it'll work now ;)
07:17<Celestar>GetVehicleOrder(v, v->cur_order_index);
07:20<Celestar>peter1138: can you profile the thing with: http://www.fvfischer.de/MemberZone_08_Final.sav <= profiling doesn't work for me, and no, I don't get crashes at the moment
07:20*peter1138 is cleaning up things at the moment
07:21<Celestar>heh ok me too :P
07:22<Celestar>http://www.fvfischer.de/cleanup.diff <= here are some more things
07:24<Celestar>peter1138: we're good team, aren't we? ;)
07:24-!-fmauNeko is now known as fmauNekAway
07:24<@peter1138>Tell you what... hg is way better than an svn branch for this :)
07:25<Celestar>yeah
07:25<Celestar>apparently :)
07:25<@Bjarni>hg is actually pretty good for developing purposes
07:25<@Bjarni>specially if two people work on the same
07:26<@Bjarni>can I check a diff on the nightly build server before committing it?
07:26<@Bjarni>without too much hassle, that is ;)
07:28<Celestar>peter1138: nice cleanups, keepem comin
07:29<Celestar>peter1138: the question is: does it work yet? :D
07:30<Brianetta>Blast it, who decided that hashing the company passwords in RAM was funny? (-:
07:30<@Bjarni>not me
07:30<Celestar>Brianetta: ?
07:30<@Bjarni>but I would have liked to claim credit for that idea :)
07:30<Brianetta>Now I can't steal company passwords with a debugger
07:30<@peter1138>Haha
07:31<@Bjarni>:D
07:31<Brianetta>More to the point, I can't re-set those passwords after a reload
07:31<Noldo>Brianetta: re-set to what?
07:31<@Bjarni>isn't there an admin option to kill a password?
07:31<Brianetta>There never used to be
07:31<@Bjarni>or will it take the whole company away
07:31<@peter1138>We should add one
07:32<@peter1138>rcon command to remove or reset a company password
07:32<Brianetta>I could attach a debugger and replace the hash with a known one
07:32<Brianetta>Looks like MD5, I could peek into the source to check that
07:33<Brianetta>It's not like this isn't network safe (-:
07:33<Ammler>Brianetta: you could also use move patch
07:33<@Bjarni>wouldn't it be easier to just add a function to set a company password to something specific?
07:34<Brianetta>Bjarni: Actually, I'd rather remove the hash function and have a command that saved the passwords into a separate file, and loaded them from that file
07:34<@Rubidium>Brianetta: why aren't you able to reset the password using a debugger?
07:34<Ammler>but I didn't succeed to move the server itself :-)
07:34<Brianetta>So that the passwords aren't transmitted over the network loader, but *are* saved
07:35<Brianetta>Rubidium: They look like MD5s
07:35<Brianetta>The problem isn't replacing the password, it's saving it
07:35<@peter1138>Is it possible to save the hash and then reinstant that?
07:35<@Rubidium>save md5, overwrite md5 with saved md5
07:36<Brianetta>Probably, but I only ever dumped core before. Never poked the code.
07:36<Brianetta>Not while it was running
07:36<Brianetta>I'd get the passwords, and save them. Reload, then attach to each company in turn and set their password.
07:36<@peter1138>Celestar, I'm going out
07:36<Brianetta>All very clean.
07:36<@peter1138>So back later.
07:36<@peter1138>Feel free to work on destination choosing ;)
07:37<Celestar>peter1138: when will you be back? (=
07:44<ln>http://crap.teurasporsaat.org/?i=6529
07:45<@Bjarni>looks like Zimbabian dollars
07:45<@Rubidium>Brianetta: the idea was to store the passwords in the savegame after the hashing, it just never got implemented
07:45<@Bjarni>Mugabe managed to maintain an inflation of 10.000%
07:46<Ammler>http://bugs.openttd.org/task/2172 <-- converting dos grfs to windows would help
07:46<Ammler>would ottd need grfcodec to do that?
07:46<Ammler>no, doesn't
07:47<Ammler>or aren't the sprites differences that bad?
07:48<@Rubidium>there are more colours in the dos GRF
07:48<@Rubidium>which means mapping might cause strange looking buildings and such
07:48<Ammler>not only the colors, also some sprites are missing, afaik...
07:49<Ammler>but they aren't used anyway, I assume.
07:49<Ammler>Rubidium: changing ALL grfs from windows to dos?
07:50-!-Vikthor [~Vikthor@snat1.spoje.net] has quit [Read error: Connection reset by peer]
07:51<Ammler>are does windows missing colors used in the dos GRFs?
07:51<ln>Bjarni: the inflation is said to be 2 million per cent
07:51<Ammler>we would also have problems for the NewGRFs then, i.e. MB does make all GRFs with dos
07:52<@Bjarni>ln: the official number is 10.000% according to their own national bank
07:52<@Bjarni>but some people don't trust them
07:52<ln>ah, it's good to quote reliable sources.
07:52-!-shodan [user@ppp101-219.static.internode.on.net] has joined #openttd
07:52<@Bjarni>:)
07:53<@Rubidium>if you need to change prices several times a day due to inflation there's a big problem
07:56<Ammler>don't you switch to other currency then (Euro/$...)
07:56<@Bjarni>they did something else
07:56<Noldo>or cows
07:56<Ammler>:-)
07:57<@Bjarni>they made their own new currency
07:57<@Bjarni>1 = 10^10 of the old one
07:57<@Bjarni>or something like that
07:58<Noldo>how does that help if you need to do that again in 2 years
07:58<@Bjarni>that's easy
07:58<@Bjarni>don't think 2 years ahead
07:58<ln>who was captain kirk's first officer?
07:59<@Bjarni>wasn't Spock the tactical officer?
07:59<@Bjarni>I never really liked the TOS
07:59<@Bjarni>I think it's even worse than Enterprise
08:00<ln>i haven't watched too much of TOS either.
08:00<ln>i thought Spock was a science officer, but who knows.
08:00<@Bjarni>maybe he was :P
08:01<Celestar>Spock was first officer
08:01<ln>ok
08:01<@Bjarni>2265 – As lieutenant commander, named first officer and science officer under Capt. James T. Kirk aboard Enterprise; promoted to commander soon after
08:02-!-LilDood [~IceChat7@cpc2-bolt5-0-0-cust370.manc.cable.ntl.com] has quit [Quit: Few women admit their age. Few men act theirs.]
08:02<Celestar>he joined as science officer
08:03<Celestar>after the death of Cmdr. Mitchell, Spock assumed his position as XO
08:03*Celestar notices that he read/watched/played too much Star Trek
08:03<@Bjarni>played?
08:03<Celestar>there have been games
08:03<@Bjarni>cosplay? :P
08:04<Celestar>is there not a simple function to obtain the house population?
08:04<Celestar>Belugas: you must be the expert there (=
08:04*ln only has TNG, DS9 and Voyager + some of the movies on DVD
08:05<@Bjarni> <Celestar> is there not a simple function to obtain the house population? <-- get a tax collector to show up and then there is only one person in each house. If you donate money to the people (pay back taxes) then there are 255 people living in each building
08:06-!-Vikthor [~Vikthor@snat1.spoje.net] has joined #openttd
08:07-!-fmauNekAway is now known as fmauNeko
08:07<ln>away nicks are ok?
08:08<@Bjarni>not really
08:11-!-glx [glx@bny93-6-82-245-156-124.fbx.proxad.net] has joined #openttd
08:11-!-mode/#openttd [+v glx] by ChanServ
08:13<@Bjarni>interesting
08:13<@Bjarni>BBC news just sent me an email
08:13<@Bjarni>with a link about a story about a real UFO being found
08:13<@Bjarni>but the link isn't British at all
08:13<@Bjarni>and appears to want to execute a script
08:14<@Bjarni>anybody want to test it for me to figure out if it's safe to click?
08:15<Ammler>Bjarni: I can, I do not have windows here :P
08:15<@Bjarni>I see Ammler wants to click it
08:15<@Bjarni>actually I was joking
08:15<@Bjarni>nobody should click it
08:16<@Bjarni>they also sent me a mail (also claimed to be from BBC) with a link of photos of Mars
08:16<@Bjarni>same link
08:17<@Bjarni>ohh and funny videos
08:17<@Bjarni>In New York has landed UFO. Click to see video! <-- now this is a trustworthy mail :P
08:17<Ammler>hmm I do not find a dos graphics pack only.
08:18*Bjarni wonders if it was written using babelfish
08:18<Brianetta>Zimbabwe's inflation is being countered, in part, by having an expiry date printed on the bank notes.
08:19<Ammler>Bjarni: are you aware of the desync problems with current autoreplace?
08:19<@Bjarni>err
08:19<@Bjarni>sort of
08:19<Celestar>er ...
08:19*Celestar wonders whether destinations is desync-safe at the moment :P
08:20<@Bjarni>it's safe to assume that they can desync, hence they are desync-safe :P
08:20<Celestar>ok .. with a 600 vehicle, 250-station game with destinations enabled (for passengers), the CPU load on by box stays around 25% for openttd
08:20<@Bjarni>I know what's causing the desync and I have a half written fix for it
08:21<Celestar>I don't see any noticable difference between destinations enabled and disabled
08:21<@Bjarni>good
08:21<Celestar>now that's good
08:21<@Bjarni>I just said so ;)
08:21<Brianetta>You all rock.
08:21<Celestar>:D
08:22<Celestar>now I want yapp and cargodest in trunk ASAP (=
08:22<Brianetta>Makes me feel motivated.
08:22<Ammler>indeed
08:22<@Bjarni>actually I'm more into classical and calm music
08:22<@Bjarni>so I prefer not to rock xD
08:22<Ammler>you JAZZ
08:23*Brianetta fires up the Jazz Jukebox
08:23<Brianetta>Oooh
08:23<Brianetta>I discovered a USB B socket on my new midi piano
08:23<Brianetta>I think I can use the Roland GM2 hardware inside as a USB midi device
08:24<Brianetta>I might have to have a go at using it for OpenTTD
08:24<Kloopy>..whilst keeping it hooked up to the audio player so that you can see how nice your play style sounds. :)
08:27<Brianetta>http://www.roland.co.uk/digp_room_catdet.asp?ID=HPI6
08:27-!-Zahl_ [~Zahl@f051072254.adsl.alicedsl.de] has joined #openttd
08:27-!-Zahl [~Zahl@g229214104.adsl.alicedsl.de] has quit [Read error: Connection reset by peer]
08:27-!-Zahl_ is now known as Zahl
08:27<Brianetta>You know what makes this piano truly stand out as one where attention was paid to the design?
08:28<Brianetta>There's a headphone hook near the headphone jacks
08:28<Kloopy>How I misunderstood unix groups -all- this time?
08:29<Kloopy>I have a group called "ibe" and I'm part of it.
08:29<Brianetta>um?
08:29<Kloopy>The file I'm trying to edit is owned as www-data:ibe
08:29<Brianetta>ah
08:29<Brianetta>yeah
08:29<Kloopy>And it's chmodded 775
08:29<Kloopy>But I can't write to it.
08:32<Brianetta>type groups
08:32<Celestar>WTF?
08:32<Kloopy>Hm.
08:32<Brianetta>that'll tell you what groups you're currently in
08:32<Kloopy>This isn't the channel I thought it was. :)
08:32<Celestar>trunk/ actually needs more CPU than cargodest on the same game :o
08:32<Kloopy>:)
08:32<Kloopy>But still.
08:32<Kloopy>I am definitely in the "ibe" grou[.
08:32<Kloopy>:)
08:32<Noldo>Celestar: wwhat?
08:32<SmatZ>Celestar: do you use the same cflags?
08:33<SmatZ>debug, assert, ...
08:33<Celestar>SmatZ: same cflags
08:33<Alberth>Kloopy: 'echo "abc" >> thefile' should work
08:33<Kloopy>That's the thing, it doesn't.
08:33<Celestar>with a large resolution and fully zoomed out, I get around 38% with cargodest and 41% with trunk :P
08:33<Celestar>might be measuring difference
08:34<Celestar>long story short: it doesn't cost much
08:34<Celestar>not from a CPU cycle point of view
08:34<Celestar>it needs quite some memory
08:34<Brianetta>Kloopy: Is your filesystem full or read only?
08:35<Brianetta>Kloopy: Have you ever used the chattr command?
08:35<Kloopy>Neither.
08:35<Kloopy>Not on this server.
08:35<Brianetta>Time to mount your fs readonly and check it for errors...
08:35<Celestar>WTF?!
08:36<Celestar>it also needs less memory?!
08:36<Kloopy>Ah, shit... when I thought I'd logged out and in again to get my new group permissions, I'd logged out of the wrong machine.
08:36*Celestar copies of openttd.cpp
08:36*Celestar copies of openttd.cfg
08:36<Kloopy>:/
08:36*Kloopy tool.
08:36<Brianetta>Kloopy: Like I said, "groups" tells you what groups your currently logged in session is a member of.
08:36<Kloopy>I was doing "groups kloopy" and not really thinking about it.
08:36<Kloopy>:)
08:37<Kloopy>But yes, you were right. Thanks :D
08:38<Celestar>op with the same settings, CPU load on cargodest is slightly higher
08:38<Celestar>(41% vs 435)
08:38<Celestar>43%
08:38<Celestar>but we're leaking memory BADLY
08:38<Celestar>or no. we just generate a SHITLOAD of cargopackets
08:39<Noldo>:)
08:39<Brianetta>How big is a packet?
08:39<Brianetta>Is it one item?
08:39<Celestar>ok when the number of cargopcakets increases, the CPU load goes up as well
08:40<Celestar>a cargopacket? a few byes
08:40<Brianetta>I mean functionally, not really
08:40<Brianetta>Does it include all cargo from S to D?
08:40<Celestar>it includes all cargo from S to D
08:41<Brianetta>Or are there more than one packet for a given ware on a route?
08:41<Brianetta>right
08:41<Celestar>but only at station P or inside vehicle X
08:41<Noldo>in one location
08:42<Brianetta>So, the order of magnitude is n(stations)*n(stations -1)*n(vehicles) ?
08:42<Celestar>of the cargopackets? yeah that's about the maximum amount
08:42<Brianetta>and vehicles means each separate train wagon or rv or ship
08:43<Celestar>if the unifying of same cargopackets works
08:43<Celestar>which I haven't tested yet
08:43<Brianetta>150,000,000-ish packets on a game with a couple of hundred of everything
08:43<Celestar>well, yes, if every thing is connected to everything else and everything is full
08:43<Brianetta>I can see that causing som eload
08:43<Brianetta>(:
08:44<Brianetta>If I get some flash of inspiration wrt optimising that, I'll share
08:45<@Rubidium>Celestar: packet unifying used to work ;)
08:45<@Rubidium>but only when the origin and days in transport is the same
08:47<Brianetta>The journey income is only aclulated upon arrival, isn't it?
08:47<Brianetta>er
08:47<Brianetta>calculated
08:47<Celestar>Rubidium: why days in transport?
08:48<fonso>I can only point to my previous idea of statistical distribution here ...
08:48<Brianetta>fonso: That's a drawing board approach
08:48<Celestar>Rubidium: we're mostly linear in our functions, we should just do weighted average of the days in transport
08:49<Brianetta>That would work.
08:49<Brianetta>In fact, once in transit, only the destination and days in transit really matters
08:49<Brianetta>so you could combine start and days in transit
08:49<Brianetta>and average tem
08:49<Brianetta>well, you could even ignore start, once averaged in
08:50<Brianetta>It would just be cargo bound for D
08:50<Celestar>openttd: /home/vici/openttd-peter/src/spritecache.cpp:355: void CompactSpriteCache(): Assertion `i != _spritecache_items' failed.
08:50<Celestar>WTF?
08:50<Brianetta>only problem with that approach is that merging packets loses track of any "detour distance"
08:51<+glx>Celestar: update your repo
08:51<Celestar>glx: well it's peters repo, I'll havta wait for him. but is that fixed?
08:52<fonso>Another question: How is the difference corresponding to each click on an arrow in the configuration menu determined? I implemented a "max cargo per tile" setting as a uint and it always increases/decreases by 200, which is somewhat much for my taste... Of course you can click on the number and modify it manually, but I'd like the arrows to be useful.
08:52<+glx>Celestar: since r13869 it should be fixed
08:53<Alberth>Brianetta: Just an idea: When merging cargo x days and y days old, (x > y), couldn't you make a cargo packet of x days + some negative income?
08:54<Celestar>glx: k great
08:56<Celestar>Rubidium: packet unifying by average days in transit has a MAJOR impact on memory usage with destinations
08:56<Brianetta>Alberth: I'm not working on this patch. Also, there's a problem with any interrim loss of starting point
08:56<Brianetta>If you lose starting point info, then people could keep merging cargo all over the map, and potentially get a really exaggerated income at the end.
08:57<@Rubidium>which is exactly the thing that I solved when I made the cargo packets
08:57<Brianetta>yes
08:57<Celestar>Rubidium: hm?
08:57<Brianetta>the packet *requires* start, destination and days in transit.
08:57<Brianetta>Only days in transit could be merged and averaged safely.
08:58<Celestar>Rubidium: well, if we average it, we'll make a small mistake since dependence on days_in_transit is non-linear, but *shrugs*
08:58<Celestar>but at a benefit of 50% reduction in memory usage ...
08:59<Celestar>at least on large games
08:59<Brianetta>If you didn't mind doing it in a lossy fashion, you could merge the start points and destinations of all inter-town packets.
08:59<Celestar>since days_in_transit is almost NEVER the same
09:16<@Belugas>[08:01] <Celestar> Belugas: you must be the expert there (=<--- i thnk so, but i'm not sure.. been a while since i've played in that stuff
09:16<@Belugas>hello by the way
09:26<fonso>I don't understand how the amount of goods moved to a station from nearby industries is calculated in MoveGoodsToStation. Specifically in line 2907 and 2908 in station_cmd.cpp a certain amount of goods named "moved" is transferred to a station st1, but then a different amount "t" is subtracted from the goods available. Is that intended?
09:28-!-tokai [~tokai@p54B802A9.dip0.t-ipconnect.de] has quit [Ping timeout: 480 seconds]
09:29<Celestar>hey Belugas (=
09:29-!-tokai [~tokai@p54B8030E.dip0.t-ipconnect.de] has joined #openttd
09:29-!-mode/#openttd [+v tokai] by ChanServ
09:30<CIA-5>OpenTTD: smatz * r13891 /trunk/src/viewport.cpp: -Fix (r12547): one could click on waypoint and station signs even when they were invisible
09:30<Celestar>@openttd bugs
09:30<Celestar>(=
09:30<@DorpsGek>Celestar: Open Bugs: 41; Not assigned: 27; Closed this week: 12; Opened this week: 8
09:32-!-Rubidium [~Rubidium@rbijker.net] has quit [Remote host closed the connection]
09:32<Brianetta>when I press X to make building invisible, and then press X again to make them come back, my station signs stop being transparent.
09:33<Brianetta>This sucks.
09:39-!-Rubidium_ [~rubidium@sd511106a.adsl.wanadoo.nl] has joined #openttd
09:39-!-fmauNeko is now known as fmauNekAway
09:41<Ammler>Brianetta: you can lock them with ctrl
09:42<Ammler>ctrl-x for the transparency gui
09:42-!-Rubidium [~Rubidium@rbijker.net] has joined #openttd
09:42-!-mode/#openttd [+o Rubidium] by ChanServ
09:43-!-Rubidium_ [~rubidium@sd511106a.adsl.wanadoo.nl] has quit []
09:44<Brianetta>ah
09:45<CIA-5>OpenTTD: bjarni * r13892 /trunk/config.lib: -Fix (r13863): [configure] now the SDK selection for OSX sets the default value as intended
09:47-!-Mucht [~Martin@chello080109200215.3.sc-graz.chello.at] has quit [Quit: Konversation terminated!]
09:47-!-shodan [user@ppp101-219.static.internode.on.net] has quit [Quit: Client Exiting]
09:55-!-stillunknown [~stillunkn@82-136-225-75.ip.telfort.nl] has joined #openttd
09:58-!-ecke [~ecke@213.195.202.130] has quit [Quit: ecke]
10:00<CIA-5>OpenTTD: bjarni * r13893 /trunk/src/os/macosx/macos.mm: -Fix: [OSX] solved a deprecated warning specific to 10.5
10:04-!-Recimin [blabla@c-7ff1e455.98-2-64736c10.cust.bredbandsbolaget.se] has quit [Ping timeout: 480 seconds]
10:09-!-Recimin [blabla@c-7ff1e455.98-2-64736c10.cust.bredbandsbolaget.se] has joined #openttd
10:10-!-rortom [~rortom@p57B7C126.dip.t-dialin.net] has joined #openttd
10:11<dih>hello rortom
10:12-!-Bjarni [~Bjarni@0x50a41670.virnxx14.dynamic.dsl.tele.dk] has quit [Quit: Leaving]
10:12-!-Dred_furst [~Dred_furs@user-514d7e3a.l2.c2.dsl.pol.co.uk] has joined #openttd
10:13<rortom>hi
10:15<Celestar>WTH
10:15<Celestar>it works :o
10:16<hylje>unpossible
10:16<hylje>context please?
10:16<rortom>paxdest?
10:16<Celestar>yeah
10:16<rortom>:D
10:16<rortom>you guys are fast :)
10:17<Celestar>payments are somewhat badly computed methinks
10:18<Celestar>http://www.fvfischer.de/itworks.png
10:19<rortom>very nice work! :)
10:19<rortom>but it seriously needs another gui :/
10:20<Celestar>well, you can still have a less detailed output :D
10:20<Celestar>I'd possibly display the nexthop only
10:21<bowman>those icons with beds etc are part of paxdest?
10:21<@Belugas>beds are TTRS3
10:21<@Belugas>part of...
10:21<Celestar>part of
10:21<Yexo>nice work Celestar
10:21<bowman>uhu... they kinda clash stylewise
10:21<Yexo>do you have a patch somewhere so we can test?
10:21<Celestar>bowman: they're only visible when the buildings are not displayed
10:21<Celestar>Yexo: sure
10:21<bowman>mkay
10:22<Celestar>http://217.151.109.167:8000/ <= there, you need mercurial/hg however
10:22<Yexo>that's no problem :)
10:22<Kloopy>You'll need a big brain to be able to cope with working out all those routings, Celestar! :)
10:23<Celestar>I can'T believe that we did the whole thing (mostly) in less than a week :P
10:23<Celestar>Kloopy: it works nicely when you only think about nexthops
10:23<Celestar>:)
10:23<hylje>maybe a neat destination map (of connected stations) with beam strength indicating the fraction of people destined that way
10:23<bowman>hehe
10:23<Celestar>hylje: we have this partly already (=
10:23<hylje>indeed, hence suggesting that
10:23<Celestar>just the beam width is missing :P
10:23<rortom>i requests screenshots :)
10:23<Kloopy>So Celestar, cargo chooses a route to be taken rather than just a final destination?
10:24<hylje>no transfers
10:24<hylje>no intermediate stations
10:24<hylje>final destination
10:25<Celestar>rortom: http://www.fvfischer.de/screeny.png <= here is another screenshot of said map :)
10:26<Kloopy>That graph is cool! :)
10:26<Kloopy>the network graph.
10:26<Celestar>I have no chance whatsoever to get rid of all my passengers
10:26<Kloopy>Just needs buttons to turn various things on and off a bit like you can on the world map.
10:26<Kloopy>Oh, it does.
10:26<Kloopy>I really should check before I talk. :/
10:27<hylje>it just needs beam strength
10:28*Belugas listens to Peter Gabriel - Signal To Noise
10:28<Kloopy>Celestar: Is there any way to remove a station from a "network"? ie if I either accidentally send a train to the wrong station or I want to remove a station from my network for some reason?
10:28<rortom>wow, thats nice
10:28<rortom>and that in a week
10:28<rortom>astonishing
10:29<Celestar>Kloopy: the network depends on the orders that the vehicles have, not the stations the vehicles run into accidently
10:29<hylje>they just need some motivation
10:29<Kloopy>Awesome.
10:29<rortom>are the tree walk calculations threaded?
10:29<Kloopy>How often are the vehicle orders analysed to calculate networks?
10:29<Yexo>Celestar: any idea how you'll handle non-"non-stop" orders?
10:30<Celestar>Yexo: not at all up to now
10:30<Celestar>Yexo: Eddi|zuHause3 has suggested an autofill feature or something
10:31<Yexo>aha, effectively tranforing all "stop" orders to "non-stop"
10:32<Yexo>bah, cloning the repository takes long :p
10:32<CIA-5>OpenTTD: smatz * r13894 /trunk/ (Makefile.in configure): -Fix: bashisms in configure and Makefile.in
10:32<hylje>large repo is rather large
10:32<rortom>uhm
10:33<rortom>is paxdest only meant for passengers?
10:33<rortom>or should it be able to transport cargo as well?
10:33<Kloopy>I believe it will have a patch setting for all cargo.
10:33<hylje>all cargo eventually, but pax for now
10:34<rortom>that would greatly improve the gamepay if coupled with a new cost/price design
10:34<rortom>*gameplay
10:34<hylje>contracts
10:34<rortom>:D
10:34<Celestar>rortom: currently only passengers and mail. but I can/will be expanded to all cargo types
10:35<rortom>very nice :)
10:35<rortom>too bad i have no time to test/contribute :(
10:36<hylje>contracts could make the game much more versatile but on the other hand a lot less TTD
10:37<hylje>(versatility comes namely from the terms contracts can actually impose)
10:38<rortom>mhm
10:38<rortom>i think this would be optional, so the user decides? :)
10:38<hylje>that's a given
10:43-!-Alberth [~hat@a82-95-164-127.adsl.xs4all.nl] has quit [Quit: Leaving.]
10:43<CIA-5>OpenTTD: belugas * r13895 /trunk/src/music_gui.cpp:
10:43<CIA-5>OpenTTD: -Codechange: Replace numbers with Colours enum on music gui and on DrawFrameRect calls
10:43<CIA-5>OpenTTD: -Fix: a few misalignements
10:43-!-GoneWacko [~foo@adsl-58.35.Static.ssp.fi] has quit [Remote host closed the connection]
10:49<Celestar>oh dear
10:49<Celestar>you need insane amounts of buses for this :P
10:49<Gekz_>O.o
10:49<Gekz_>go to sleep
10:49<Gekz_>because I'm about to
10:49<Celestar>Yexo: did the checkout work?
10:50<Yexo>yep, but I needed to install boost, and have some problems installing that
10:53<Yexo>is there any environment variable I can set for the includedir?
10:54-!-tokai [~tokai@p54B8030E.dip0.t-ipconnect.de] has quit [Quit: icebears... take care of them!]
10:59<Eddi|zuHause3>hm... i have 10°C spare, anyone interested in buying them off me?
10:59<ln>_o/
10:59<Eddi|zuHause3>~~~
11:00-!-Purno [~Purno@5350931D.cable.casema.nl] has joined #openttd
11:01<Celestar>Yexo: what system are you on?
11:01<Celestar>Eddi|zuHause3: :P
11:02<Yexo>cygwin
11:03<Eddi|zuHause3>that should be the next trend on ebay... after WLAN cables and graphics card packaging...
11:03<Eddi|zuHause3>and air guitars...
11:03<Eddi|zuHause3>when having paxdest, the number of generated passengers needs to be reduced
11:04<Eddi|zuHause3>with an average of 3 rides per passengers, you can only handle 1/3 the amount of passengers with the same network
11:04<+glx>Eddi|zuHause3: what are graphics card packaging?
11:04<Eddi|zuHause3>glx: the box that the graphics card came in
11:05<+glx>they send empty boxes?
11:05<Eddi|zuHause3>yeah, and some idiots buy them as if there was a graphics card in :p
11:06<Celestar>http://www.fvfischer.de/cargodisplay.png
11:08<Eddi|zuHause3>how do they pack 50 people in such a tiny [but oversized] bus?
11:09<Gekz_>erm Celestar
11:09<Celestar>Eddi|zuHause3: you know that a normal city bus takes up to 120?
11:09<Celestar>Gekz_: ?
11:09<Gekz_>is that part of your passenger destinations trialling?
11:09<hylje>bogeyed buses here eat some 100 passengers
11:09<hylje>up to 250 for bi-articulated
11:09<Celestar>double-jointed buses up to 180
11:09<Celestar>Gekz_: yes
11:10<Eddi|zuHause3>that bus does not look like it has a bogey...
11:10<Gekz_>Celestar: will it be, well, less ugly
11:10<Gekz_>in the future
11:10<Celestar>Gekz_: what is ugly?
11:10<hylje>Eddi|zuHause3: the lack of a bogey doesn't magically cut its length and capacity in half
11:10<Gekz_>all the (en-routes)
11:10<Celestar>Gekz_: you can hide them (=
11:10<Celestar>this is for debugging you network
11:10<Gekz_>can they at least be organised.
11:10<Gekz_>?
11:10<Celestar>and our code
11:10<Celestar>they are. by cargo packet id (=
11:10<hylje>the bit-destinations might get dumped to a graph
11:11<Gekz_>Celestar: in the future, will it be more special?
11:11<hylje>if Celestar and others arse enough to do that
11:11<Celestar>Gekz_: I'm open for suggestions ...
11:11<Eddi|zuHause3>we should have speed limits in cities
11:11<Gekz_>Celestar: make buttons to sort alphabetically
11:11<Gekz_>and by most passengers
11:12<Celestar>Gekz_: will certainly not happen before the main part of cargodest is in trunk
11:12<Gekz_>Celestar: I know
11:12<Gekz_>I wasnt asking now
11:12<Celestar>Gekz_: next focus will be how it handles multiplayer
11:12<Gekz_>I was asking to put it in the back of your mind
11:12<Eddi|zuHause3>for a highly connected network, i expect the "from A to B" part to be almost unique
11:12<hylje>how about doing away with a big list shown by default and having that beam-strength map as the default
11:13<Eddi|zuHause3>means you'll get like 50 lines of different "from A to B" for such a bus
11:13<Gekz_>beam strength?
11:13<hylje>yeah, based loosely on the current network graph (station connections)
11:13-!-frosch123 [~frosch@frnk-590fee31.pool.einsundeins.de] has joined #openttd
11:13<Gekz_>I see,
11:13<hylje>the more people go there of all people, the bigger the beam between two stations
11:14<Celestar>Eddi|zuHause3: quite yes. however, passengers will be loaded grouped ;)
11:14<Celestar>they're also generated in groups
11:15<Celestar>I'm just pondering whether to generate them fractionally
11:15<Eddi|zuHause3>not for long distance busses, the driver will ask each one individually where he wants to go, and sell him a ticket :p
11:15<Celestar>and just display the integer ones
11:15<Eddi|zuHause3>Celestar: you mean the fractions will accumulate over time?
11:16<Celestar>Eddi|zuHause3: yes, but if you have [n pax to A] and [m pax to B], n will be loaded before m (in case they can both board by routing)
11:16<Eddi|zuHause3>and after 100 ticks you'll have a full passenger to that city on the other end of the map?
11:16<Celestar>Eddi|zuHause3: yes something like that
11:16<hylje>statistics work that way
11:16<Celestar>Eddi|zuHause3: but then fractionals ..
11:26<Eddi|zuHause3>hm... i have a really weird graphics bug... and i'm not sure if it has anything to do with my patches...
11:26<Eddi|zuHause3>i have a road with a catenary pylon...
11:28-!-svippy [~svip@0x50a5b150.boanxx18.dynamic.dsl.tele.dk] has joined #openttd
11:28-!-svippery [~svip@0x50a5b150.boanxx18.dynamic.dsl.tele.dk] has quit [Read error: Connection reset by peer]
11:28*Belugas works on a fraudulous use of a credit card at one of his customer's site :)
11:28<@Belugas>there's a guy who is going to have some REAL problems!
11:29<SmatZ>good :)
11:35-!-dragonhorseboy [4a396fef@67.207.141.120] has joined #openttd
11:35<dragonhorseboy>hey
11:39-!-skidd13 [~skidd13@p548A6A6D.dip.t-dialin.net] has joined #openttd
11:39-!-skidd13 [~skidd13@p548A6A6D.dip.t-dialin.net] has left #openttd []
11:39<dragonhorseboy>another quiet day here it would seem :p
11:42-!-dragonhorseboy [4a396fef@67.207.141.120] has left #openttd []
11:44<Ammler>just to be sure, converting a dos grf to win: grfcodec -dp1 dos.grf && grfcodec -ep2 win.grf ?
11:44<DaleStan>Nope.
11:45<DaleStan>-p has no effect for encoding.
11:45*Celestar wonders whether cargodest compiles with YPP :D
11:45<Celestar>yapp*
11:45<Ammler>oh, m then?
11:45<DaleStan>-m, yes. But only once, or you'll get it double-converted.
11:46<@Rubidium>Ammler: still doesn't magically change the dos checks in the grfs to windows checks
11:46<Celestar>peter1138: http://www.fvfischer.de/packetmerge.diff
11:47<@Rubidium>Celestar: nice way of resetting the days_in_transit when small amounts of packets get into a station at a time
11:47<Ammler>I had a little glitch as I tried the dos GRFs, btw.
11:48<Celestar>Rubidium: ?
11:48<Ammler>ottd looks for sample.cat but I had SAMPLE.CAT, so I needed to rename
11:48<Celestar>Rubidium: you mean rounding?
11:48<Yexo>cp->days_in_transit + cp->count <- should be *
11:49<Celestar>yeah
11:49<Celestar>already corrected :D
11:49<@Rubidium>Celestar: 1000 * 0 + 3 * 255 => 765 / 1003 => 0
11:50<Yexo>I have boost installed, the header files are under /usr/local/include/boost-1_35/boost, but I still get "boost/graph/adjacency_list.hpp: no such file or directoy"
11:50<Celestar>Rubidium: we should not use integers only :)
11:51<Celestar>Yexo: ./configure CFLAGS="-I/usr/local/include/boost-1_35"
11:51<Ammler>this is still correct for converting original dos to win? http://www.tt-forums.net/viewtopic.php?p=217375#p217375
11:53<Ammler>"TRG1.GRF: fails!" <-- still?
11:54<@Rubidium>well, try it
11:54<DaleStan>Ammler: There is no easy way to convert GRFs that contain recolour sprites. trg1r/TRG1 are two such grfs.
11:54<@Rubidium>I could never be bothered converting dos -> windows or the other way around
11:54<Ammler>pasky's patch isn't available anymore
11:55<Ammler>Rubidium: we had yesterday the first visitor with dos grfs :-)
11:55<Ammler>linking to windows graphics isn't the best solution :-)
11:56<Brianetta>Dos GRFs ahve different checksums. This will basically exclude DOS palleted players from windows games.
11:56<Ammler>Brianetta: no, that check does only for NewGRFs
11:56<DaleStan>pasky's patch isn't available anymore <-- Well, not available unless you know which revision to diff.
11:57<Ammler>I assume, that is already in?
11:57<DaleStan>I don't, by the way.
11:57-!-Wezz6400 [~Wezz6400@ndb.demon.nl] has quit [Quit: bbl, playing game that's incompatible with my irc client]
11:58<DaleStan>It is. And has been since 0.9.6 So maybe it's not in SVN after all.
11:59<Ammler>diff between dos and win original trg1: http://paste.openttd.org/38443
12:00<Ammler>I expected a bigger one :-)
12:01<Ammler>Brianetta: currently the client crashes, if you try to join with dos http://bugs.openttd.org/task/2172
12:05<Ammler>Rubidium: converting works, but the GUI is still pink
12:07<Eddi|zuHause3><peter1138> Destinations: Passengers/Passengers+Mail/etc/All <- i'd say something like "Passengers only/Mail only/All town based cargo [pax,mail,goods,food,...]/All cargo"
12:08<Celestar>heh
12:10<Celestar>ok who is willing to test paxdest in a network with yapp? :P
12:10<Yexo>Celestar: as soon as I get it compiling I'll try that
12:10<Celestar>Yexo: where's the problem?
12:10<Yexo>I get linking errors now ("undefined reference to '__assert'")
12:10<Celestar>http://www.fvfischer.de/nettest.diff <= here's the required diff
12:11<Ammler>Celestar: have you complete patch?
12:11<Celestar>Yexo: what distro are you on?
12:11<Yexo>cygwin
12:11<Celestar>Ammler: have I what?
12:11<Celestar>Yexo: I see
12:12<Ammler>a patch against trunk
12:12<Kloopy>Celestar: Is is multiplayer safe yet?
12:13<Celestar>Kloopy: this is one thing I'd like to find out (=
12:13<Ammler>we could setup a server if you like...
12:14-!-Dr_Jekyll [Dr_Jekyll@p57B0EBFB.dip.t-dialin.net] has joined #openttd
12:14<Kloopy>Because I have a group of friends who are ridiculously addicted to OTTD and play a few times a week at the moment.. I'll see if I can persuade them to try it out if we play tonight.
12:14<Kloopy>Which revision is that diff against?
12:14-!-rortom [~rortom@p57B7C126.dip.t-dialin.net] has quit []
12:15<Celestar>Kloopy: it's against the semi-official cargodest repo
12:15<Dr_Jekyll>hm...i think i'm blind...i'm looking for setting up the "General behaviour change parameter" for the ECS - but where to do this?
12:15<Kloopy>Ok
12:15<Celestar>Kloopy: you need mercurial/hg and get it from http://217.151.109.167:8000/
12:15<Celestar>Kloopy: my diff fixing one more thing about it and adds yapp :)
12:15<Kloopy>I'll have a play after hometime.
12:16<Kloopy>15 mins :D
12:16<Yexo>Dr_Jekyll: have you found the newgrf config window?
12:16<Dr_Jekyll>Yexo no?
12:16<Dr_Jekyll>i was looking in the .cfg file
12:16<Yexo>start openttd, in the main menu, "NewGRF Settings"
12:17<Yexo>or in the config file just put all parameters space seperated after the grf name
12:17*peter1138 returns
12:18<Dr_Jekyll>ahh thx ... so i can set them separately for each vesctor?
12:18<Ammler>Yexo: noaicomp server has mercurial installed btw. :-)
12:18<Yexo>nice :)
12:18<Yexo>so testing this is no problem then
12:19<@peter1138>Ah shit, I committed too much :p
12:20<Celestar>peter1138: got a sec?
12:20<Ammler>Yexo: Yexo
12:20<Yexo>yes?
12:20<Ammler>ah, :-)
12:20<Dr_Jekyll>ok maybe someone could help me with my second problem: i play the rcpp with ecs - why the roadvehs all went to the same slot at a station - even if there are free ones
12:20<Celestar>peter1138: http://www.fvfischer.de/packetmerge.diff <= have a look at this. If we don't do this, we produce cargopackets like there's no tomorrow on a large map
12:20<Ammler>you can setup a server, if you like...
12:20<Celestar>peter1138: if we do it, we get rounding errors and linearization errors
12:21<Yexo>Dr_Jekyll: queueing for road vehicles only works for normal road stops, not for drive-through ones
12:21<Yexo>Ammler: I'll maybe do so as soon as I have it running locally
12:21<Yexo>a new subdir like noai-svn?
12:21<Ammler>yeah
12:21<+glx><Yexo> I get linking errors now ("undefined reference to '__assert'") <-- mingw is picky with lib orders
12:22<Ammler>and port 82
12:22<Yexo>ok, thx Ammler
12:22<Dr_Jekyll>Yexo if i build two normal stations (and merge them) all the busses will hit only one station (the nearest to the start)
12:22<+glx>Yexo: what is LDFLAGS?
12:22<Yexo>glx: I didn't chagne LDFLAGS at all
12:22<@peter1138>Celestar, uh huh
12:22<Yexo>it's empty
12:22<Yexo>Dr_Jekyll: can you show a screenshot / savegame?
12:22<+glx>I mean the LDFLAGS created by configure
12:23<Yexo>LDFLAGS =
12:23<Celestar>peter1138: I also hardly manage to get rid of my passengers, but that can be dealt with later
12:23<Yexo>that's the line from objs/debug/Makefile
12:23<Dr_Jekyll>yexo sure... just a moment
12:23<+glx>Yexo: make VERBOSE:=1
12:23<+glx>paste the ld line
12:23<Ammler>Celestar: shouldn't we first test it without yapp?
12:23<Celestar>peter1138: about cargo generation? What's wrong with what we currently have? Why not just bias the random number generator a little by station size and distance, but basically give the same destination to all people generated in one scoop
12:24<Celestar>Ammler: as you wish.
12:24<Ammler>you think, it is that stable :-)
12:24<Celestar>Ammler: I'm just multiplaying cargodest and yapp
12:24<@peter1138>Celestar, well quite. They're generated in small enough chunks...
12:24<Yexo>glx: now it worked without any errors :S
12:25<Yexo>hmm, it did not
12:25<Ammler>Celestar: so you have already server running?
12:25<@peter1138>For the rounding issue, could we use your fixed point arithmetic there?
12:25<@peter1138>(It needs saving though)
12:26<@peter1138>I assume your maths is correct, heh
12:26<Yexo>glx: ottdres.o -lstdc++ -lws2_32 -lwinmm -lgdi32 -ldxguid -lole32 /lib/libz.a -o openttd.exe <- list items from the line
12:28<+glx>seems right (it's the same as trunk)
12:28<Celestar>peter1138: it is working fine
12:29<Celestar>peter1138: saving is a non-issue since we still use basic integer data types for in-memory or io. We're just interpreting them differently
12:29*glx gets the sources
12:29<Yexo>there are only a few functions with undefined reference: __assert, __stricmp, __wfopen, __waccess, _wunlink
12:30<@peter1138>Grrr, non-working ISP nameservers :(
12:30<Celestar>Ammler: I have a server running
12:30<Celestar>peter1138: use 129.187.45.233
12:31<Celestar>peter1138: and it works totally awesome
12:31<@peter1138>What does?
12:32<Celestar>peter1138: cargodest. in conjuction with yapp. on a network. I'm 15 years into the game, no desyncs
12:33<@Rubidium>part the game and rejoin ;)
12:33<Celestar>Rubidium: did so 3 times already
12:33<@Rubidium>nice
12:34<@peter1138>Rubidium, oh come on, we do know what we're doing... mostly ;)
12:34<Celestar>http://www.fvfischer.de/itrocks.png
12:34<@peter1138>Contrary to that other paxdest patch, we only add one member to the cargopacket structure in the savegame...
12:35<Celestar>peter1138: I've tried a 600-vehicle, 300 station map
12:35<Celestar>it works nice if we merge cargopackets by waittime
12:36<Celestar>if it doesn't the memory consumption grows insane quickly
12:36<@peter1138>*nod*
12:36<@peter1138>As prissi complained would happen when we introduced cargo packets.
12:36<Celestar>prissi?
12:36<@peter1138>Which is odd as fundamentally you still need to store all the same information...
12:36<Dr_Jekyll>Yexo http://exelor.de/traffic_jam.png
12:37<Celestar>with merging, we still need noticably more memory, but the cpu consumption doesn't change by any noticable level
12:37<@peter1138>Celestar, a Simutrans coder, and wrote a paxdest patch for OpenTTD based vaguely on that.
12:37<Celestar>Simutrans needs 128 bytes per tile
12:37<Celestar>..
12:37<@peter1138>Ouch.
12:38<Celestar>I've *tried* to generate a 1k x 1k map once
12:38*Celestar sighs "I want to play"
12:38<@peter1138>I last played it properly when it didn't have partial screen updates
12:39<@peter1138>So scrolling meant it redraw everything. Scrolling was slow.
12:39<Celestar>heh
12:39<Celestar>I currently have 2 clients running, each needs 1% CPU :P
12:39<@peter1138>Actually that was in 2005, just before Hackykid wrote PBS for OpenTTD...
12:39<Celestar>each needs 3% CPU, sorry
12:39<Celestar>and 7MB of memory
12:39<Celestar>and that's with CPU downclocked to 600MHz
12:40<Celestar>but then, it's only two dozen vehicles
12:40*peter1138 gets pile transport out
12:40<@peter1138>23% cpu
12:41<@peter1138>Although that's just started, so not many packets yet.
12:42<CIA-5>OpenTTD: belugas * r13896 /trunk/src/ (newgrf_gui.cpp order_gui.cpp osk_gui.cpp): -Codechange: Replace numbers with Colours enum on newgrf, order and osk guis
12:42<Yexo>Dr_Jekyll: that station looks ok, can you check in your config what the value of roadveh_queue is?
12:43<Celestar>peter1138: how big was Pile Transport?
12:43<Dr_Jekyll>Yexo roadveh_queue = true
12:43<Yexo>can you post a savegame?
12:44<Celestar>me?
12:44<Yexo>no, Dr_Jekyll
12:44<Celestar>oh
12:44<@peter1138>1024x1024 I think
12:44<Dr_Jekyll>yexo i tried already all pf with and without queuing - it's all the same
12:44-!-Doorslammer [Doorslamme@PIPP-p-203-54-229-69.prem.tmns.net.au] has quit []
12:44<@peter1138>Oh, DNS is working fine...
12:45<CIA-5>OpenTTD: belugas * r13897 /trunk/src/news_gui.cpp:
12:45<CIA-5>OpenTTD: -Codechange: Replace remaining numbers with Colours enum on news guis
12:45<CIA-5>OpenTTD: -Fix: a few misalignements
12:45<Yexo>and what happens if you delete only the station tile the vehicles are queuing for now?
12:45<@peter1138>I think there's some hg clones going on...
12:45<@peter1138>ssh is okay due to QoS...
12:45<@peter1138>and DNS is now okay cos i QoS'd that :D
12:45<@Belugas>so repetitive task...
12:45<@peter1138>http://svn.bucks.net/~petern/map6.png
12:45<@peter1138>^ route map from pile transport
12:45<Celestar>peter1138: gotta go.
12:46<Celestar>peter1138: It works nicely in the network with > 1 players (for 20 years now)
12:46<@peter1138>Belugas: Hope you liked my little clean up ;)
12:46<Celestar>peter1138: my fixed variable type is in the gamebalance branch, file fixedt.h (header-only implementation). it's very well documented.
12:46<Celestar>cu
12:46<@peter1138>Bye
12:47*Celestar smils
12:47<Celestar>es
12:47<@Belugas>loved it, to be honest :)
12:47<Dr_Jekyll>yexo then they use all the available slots but only for one time, the next truck which arrives will try to go to the nearest slot even it is full
12:47<@Belugas>just was not (and still am) on the "fix-this" mode :)
12:47<@Belugas>i'
12:47-!-XaT [~root@lan31-6-82-230-27-240.fbx.proxad.net] has joined #openttd
12:47<@Belugas>nothing
12:47<XaT>hello
12:48<SmatZ>hello
12:48<XaT>if someone have seen this before :
12:48<XaT>openttd: /srv/r13810-HFR_src/src/tile_map.h:135: Owner GetTileOwner(TileIndex): Assertion `!IsTileType(tile, MP_HOUSE)' failed.
12:48<Yexo>Dr_Jekyll: then I ask again, can you post a screenshot?
12:48<@peter1138>Belugas: "remaining colours"... Is that the last one then?
12:48<SmatZ>XaT: sure
12:48<SmatZ>very likely GRF bug
12:48<XaT>our server (special version : coop track sharing + pbs + daylenght) crash
12:48<Yexo>XaT: yes, are you using a trunk version or some patch?
12:48<XaT>yeah ;d
12:48<@Belugas>but am going to give those poor invisible buttons some real widgets
12:48<@peter1138>r13810-HFR_src doesn't sound like trunk
12:49<@Belugas>peter1138, yes , remainng on that file ^_^
12:49<XaT>we"v
12:49<@peter1138>Oh... :o
12:49<XaT>we've merged 3 patch into our version :o
12:49<SmatZ>err no GRF bug, that's a bit different problem :-x
12:49<Dr_Jekyll>Yexo http://exelor.de/traffic_jam2.png
12:49<XaT>erm?
12:49*peter1138 ponders syncing with trunk
12:49<@Belugas>peter1138, there are more colours enum to assign after that
12:49<SmatZ>XaT: I guess it is caused by track sharing...
12:50<Yexo>Dr_Jekyll: I see the problem, but without a savegame I can't have a closer look at it
12:50<@Belugas>like the drawframerect (i think it';s the name_
12:50<XaT>yeah fore sure
12:50<@peter1138>83 files updated, 2 files merged, 0 files removed, 0 files unresolved
12:50<@peter1138>That's good, right?
12:50<Dr_Jekyll>Yexo it has to be a problem with those patch packs - when i play a game from trunk it works correct
12:51-!-nicfer [~Administr@168.226.106.115] has joined #openttd
12:51<Yexo>aha, in that case go complain in the thread(s) from the patches you have
12:51<Dr_Jekyll>Yexo there is no quick solution? nothing for me to change to make it work? (and no i can't compile my own version ;)
12:51<XaT>i went to openttdcoop
12:51<Yexo>Dr_Jekyll: use a trunk version :p
12:52<Dr_Jekyll>*bg* thx yexo - helped me much with the parameters
12:52<Yexo>that, or get the patchpack author to fix it
12:52<Ammler>Celestar: you forgot to add the new files for your yapp patch
12:53<nicfer>Idea for the website: why don't make it a wiki?
12:53<nicfer>like Wormux's page
12:53<Yexo>because we don't want any random user editing the main website
12:54<nicfer>you can protect the main site and only make editable the manuals section
12:54-!-GoneWacko [GoneWacko@86-60-147-155-dyn-dsl.ssp.fi] has joined #openttd
12:54<Dr_Jekyll>is the author from the russian community patch pack in here? yexo told me i should get you to fix my problem *hide*
12:54-!-nicfer is now known as Mr_Hyde
12:54<Mr_Hyde>muhahahhahha
12:55*Dr_Jekyll says *upps*
12:56<Yexo>@seen smokey555
12:56<@DorpsGek>Yexo: I have not seen smokey555.
12:56<Yexo>@seen smoky555
12:56<@DorpsGek>Yexo: smoky555 was last seen in #openttd 2 weeks, 6 days, 6 hours, 23 minutes, and 54 seconds ago: <Smoky555> 53 patches...
12:56<Yexo>looks like he hasn't been here for a whiel
12:59-!-Mr_Hyde is now known as nicfer
13:00<nicfer>a wiki page would work if the main pages (portal, downloads, etc) are protected
13:01<Yexo>but if that's the case, what is the advantage of a wiki?
13:03<@Rubidium>but wiki's aren't quite dynamic enough
13:04<@Rubidium>I seriously don't want to change the wiki every few milliseconds for the server page etc.
13:04<dih>XaT ?
13:04-!-mikl [~mikl@cpe.ge-0-2-0-812.0x50c774be.boanqu1.customer.tele.dk] has quit [Ping timeout: 480 seconds]
13:07-!-Noetloj [~105Adam@5acb31ac.bb.sky.com] has joined #openttd
13:08<Noetloj>quote from the site: As there were quit some (not so small) fixes since 0.6.2-RC1 we are releasing a second release candidate,
13:08<Noetloj>Should be "Quite"
13:08<Noetloj>well, Q = q
13:08<ln>quite from the site?
13:08<Noetloj>...yeah, I think your eye sight is a bit fail.
13:09<SmatZ>hehe
13:10-!-Wolf01 [~wolf01@host41-160-dynamic.56-82-r.retail.telecomitalia.it] has joined #openttd
13:10<Wolf01>hello
13:11<SmatZ>hello Wolf01
13:14<+glx>Noetloj: I don't see any errors on the site
13:17-!-Klanticus [~Klanticus@189.35.184.72] has joined #openttd
13:17<CIA-5>OpenTTD: belugas * r13898 /trunk/src/ (player_gui.cpp rail_gui.cpp): -Codechange: Replace remaining numbers with Colours enum on players, roads and rails guis
13:18<@Belugas>mmh
13:19<CIA-5>OpenTTD: belugas * r13899 /trunk/src/road_gui.cpp:
13:19<CIA-5>OpenTTD: -Codechange: Replace numbers with Colours enum on roads gui.
13:19<CIA-5>OpenTTD: save command file before commiting :P
13:19-!-stillunknown [~stillunkn@82-136-225-75.ip.telfort.nl] has quit [Read error: Connection reset by peer]
13:23-!-Brianetta [~brian@client-86-27-108-163.brnt.adsl.virgin.net] has quit [Quit: Tschüß]
13:26-!-nicfer [~Administr@168.226.106.115] has left #openttd []
13:39<GoneWacko>bah, the TranslateXYToTileCoord function is confusing me
13:45-!-ARock [R.Rock@xdsl-87-79-208-226.netcologne.de] has joined #openttd
13:46-!-gregor_ [~gregor@xdsl-87-78-21-39.netcologne.de] has joined #openttd
13:46<CIA-5>OpenTTD: belugas * r13900 /trunk/src/ (4 files): -Codechange: Replace numbers with Colours enum on settings, smallmaps, stations and signs guis.
13:48-!-gregor_ [~gregor@xdsl-87-78-21-39.netcologne.de] has left #openttd []
13:50-!-Rexxars [~rexxars@62.113.133.253] has joined #openttd
13:54<GoneWacko>Apart from the zoom scaling and the bits where it does all the magic with the z-coordinates, I've recreated the function in python (for easy testing), yet the values I'm getting are definately not right. :[
13:54<GoneWacko>but if I assume being zoomed in all the way and flat land at Z=0 then I shouldn't need those bits anyway.
14:14-!-Zuu [~Zuu@c-fd4ee055.510-8-64736c10.cust.bredbandsbolaget.se] has joined #openttd
14:14<Ammler>Celestar: ?
14:14-!-Zuu is now known as Guest584
14:15-!-Guest584 is now known as Zuu
14:23<Zuu>I'm looking at adding a search function to the sign list box. I think I will implement it so that if you type "BBH01" in the box it will only show signs that contains the text you have written. My first though was to make a second list of signs (array of pointers) that only contains the signs that matches the search term. However looking at station list window it uses a class GUIList that contains capabilities of having multi
14:23<Zuu>ple (and selectable) sort functions. A way to go could be to try to add search/filter to that class. What do you think? - Also do you like having a search for the sign list?
14:25<Zuu>Some lame screenshots of it: http://www.tt-forums.net/viewtopic.php?f=32&t=38658
14:25<Zuu>(lame in the sense that I just don't draw the signs that don't match but don't comress the list)
14:30-!-fmauNekAway is now known as fmauNeko
14:32<Ammler>that filter could also be usefull for other lists
14:32<Wolf01>that's a nice feature, I don't make a so large use of signs that they need to be searched, but I think that it'll help on coop games
14:33<@peter1138>Zuu, well you could just modify the BuildSignsList method...
14:33<Zuu>Especially when there are various amount of white-spaces before signs. So therefor I think the sign-list is of most need for a search/filter.
14:34<Zuu>peter1138: Thanks for that hint.
14:34<Yexo>I'd like the same feature for other lists, such as the station / town list
14:34<Yexo>especially with lots of stations it'd be nice
14:35<@peter1138>Well, I'd say you're best off filtering as the list is built. No special extras in the base classes are needed for that, I think.
14:35<Wolf01>I'll add that feature for vehicles too, it should be useful to look for vehicles which can carry the searched cargo
14:35<@peter1138>FOR_ALL_SIGNS(si) *this->signs.Append() = si;
14:35<@peter1138>->
14:35<@peter1138>FOR_ALL_SIGNS(si) if (si matches filter) *this->signs.Append() = si;
14:35<Zuu>I will begin with the sign list though and move on from there.
14:36<@peter1138>*nod*
14:36<@peter1138>Did you find a solution for windows having no such thing as focus?
14:37<Zuu>Not enterly yet. I have though of how to solve it. I think I will hide the search box by default so users must enable it. Or we have to lock the arrow keys whenever a window with search is open.
14:38<Zuu>From code point of view it might be best to use a seperate window for searching as it need to be in the very begining of key-input proces. Or auto-rail will steal the a-key for example.
14:40<Zuu>Something like the on-screen-keyboard but for searching. Have not yet tested if OSK can be typed in. Might be possible to use it stright away. And have a hidden editbox that is passed as argument to OSK.
14:40-!-ARock [R.Rock@xdsl-87-79-208-226.netcologne.de] has quit []
14:42<Zuu>Doesn't look like the OSK takes input, or at least it seams to be after sign window in key-reading-sequence.
14:46-!-Wezz6400 [~Wezz6400@ndb.demon.nl] has joined #openttd
14:46<fonso>I implemented station capacities
14:46<fonso>but its a cheat
14:46<fonso>:(
14:47<fonso>You can build a station of very small capacity and then let large vehicles go there repeatedly.
14:47<fonso>Thus they won't be able to unload anything, but they'll still get transfer credits
14:47<Ammler>peter1138: is there really need to enable/disable cargo destination for different cargo types?
14:47<@peter1138>Yes.
14:48<fonso>Is anyone actually interested in station capacities?
14:48-!-LilDood [~IceChat7@cpc2-bolt5-0-0-cust370.manc.cable.ntl.com] has joined #openttd
14:48<SmatZ>fonso: maybe as GRF feature
14:49<@peter1138>fonso, ... what SmatZ said.
14:49<@peter1138>Yeah, if NewGRF will control it, probably with callbacks, then it's great.
14:49<fonso>even as GRF feature that would be a principal problem
14:50<@peter1138>Transfer credits aren't much use without the final destination.
14:50<fonso>eventually the people will get off the vehicle even at their origin station if you just drive in circles long enough
14:51<Ammler>peter1138: one little thing I just realized, if you use a dedicated airport as hub for a region, which doesn't self accept passengers, you will have passenger there all the time...
14:51<fonso>but you've ripped them off pretty well until then
14:52<Zuu> peter1138: Is there really a BuildSignsList? I fail to find it using grep in * or */* or */*/* also I looked at CmdRenameSign, there it simply set _sign_sort_dirty = true so that sign window later calls GlobalSortSignList() that sorts the list. - Stations have BuildStationList and is using GUIList. But Signs don't use GUIList and don't have a BuildSignsList function.
14:52<Yexo>hmm, I now get "/usr/include/boost-1_33_1/boost/config.hpp:35:33: /usr/include/boost-1_33_1/boost/boost/config/compiler/gcc.hpp: Too many levels of symbolic links"
14:52<Ammler>http://img11.myimg.de/cargodest0b6ad.png
14:53<Yexo>sorry, that was my fault
14:54<Eddi|zuHause3>symlink to itself?
14:54<Yexo>(why did I only see the error after posting it?)
14:54<Yexo>Eddi|zuHause3: yes ;)
14:54<Eddi|zuHause3>Ammler: so what is your problem?
14:55<Ammler>Eddi|zuHause3: the screen?
14:55<Ammler>you see there "...to 3Town" but 3Town doesn't accept pass
14:55<Yexo>woot, I have cargodest compiled now :)
14:56<Eddi|zuHause3>that's probably the random destination choosing not checking if the destination actually accepts the cargo
14:56<Ammler>as 3town is something like the airport for those 3 town in that region
14:56<Eddi|zuHause3>as i understand it, that part is very rudimentary
14:57<Ammler>well, it rocks (jazz) :-)
14:57<Eddi|zuHause3>it jazzs?
14:57<Ammler>yeah, celestar doesn't rock
14:58<Eddi|zuHause3>no, that was bjarni
14:58<Ammler>:-)
14:58<Ammler>indeed, sorry :-)
14:59<Eddi|zuHause3><Celestar> http://www.fvfischer.de/itrocks.png
14:59<Ammler>nice part is, you can use existing saves and they are "fast" converted to cargo dest...
15:00<Eddi|zuHause3>so... what magical incantation do i use to get started with mercurial?
15:01<Eddi|zuHause3>i mean after "yast -i mercurial"
15:01<Ammler>hg clone <url>
15:01<Ammler>that all :-)
15:02<Ammler>it seems like svn with update and revert
15:02<Eddi|zuHause3>can i add that to an existing checkout?
15:03-!-svippery [~svip@0x50a5b150.boanxx18.dynamic.dsl.tele.dk] has joined #openttd
15:03-!-svippy [~svip@0x50a5b150.boanxx18.dynamic.dsl.tele.dk] has quit [Read error: Connection reset by peer]
15:04<Ammler>http://www.ivy.fr/mercurial/ref/v1.0/ <-- helpful
15:05-!-Progman [~progman@p57A1D1E3.dip.t-dialin.net] has quit [Remote host closed the connection]
15:09-!-ecke [~ecke@21.161.broadband7.iol.cz] has joined #openttd
15:11<Eddi|zuHause3>it's taking forever...
15:14<Ammler>yep, it doesn't "just" download the files, the whole history, afaik
15:15<@Rubidium>oddly enough a hg repo with history is smaller than a svn checkout
15:16<Ammler>cargodest is 84MB here
15:18<Eddi|zuHause3>i should use the time to check where the old patch hooked that "reduce passenger numbers" option ;)
15:19<CIA-5>OpenTTD: smatz * r13901 /trunk/Makefile.src.in: -Fix: make sure REV_NR isn't empty, rev.cpp would fail to compile
15:23<Eddi|zuHause3>"/* first eventually reduce the number of passengers */" <- that sentence does not make sense...
15:23<Eddi|zuHause3>"first" and "eventually" are opposite things in my mind...
15:23-!-Klanticus_ [~Klanticus@189.35.184.72] has joined #openttd
15:23-!-stillunknown [~stillunkn@82-136-225-75.ip.telfort.nl] has joined #openttd
15:26<fonso>Well, here is station capacities: http://www.tt-forums.net/viewtopic.php?f=33&t=38712
15:26<@peter1138>Ammler, yes, destination selection is not in place yet. It is just random at the moment.
15:26<Eddi|zuHause3>this code is totally insane...
15:26<@peter1138>Eddi|zuHause3, that may also be because it's at the end of my ADSL line...
15:27<Eddi|zuHause3>peter1138: want to bet that my down bandwidth is lower than your up bandwidth? :p
15:28<@peter1138>My up is 448 kbit/s
15:28<Eddi|zuHause3>see ;)
15:28<Eddi|zuHause3>my down is 384 kbit/s ;)
15:28<@peter1138>Thank the Lord of QoS, I can still use SSH nicely ;)
15:28<@peter1138>Ouch...
15:28-!-Klanticus__ [~Klanticus@201-43-57-195.dsl.telesp.net.br] has joined #openttd
15:30-!-Klanticus [~Klanticus@189.35.184.72] has quit [Ping timeout: 480 seconds]
15:32<Ammler>I am also wondering,why so many complain about ECS closing, I run now 20 years a map without any problems there..
15:32-!-Klanticus_ [~Klanticus@189.35.184.72] has quit [Read error: Connection reset by peer]
15:33<Eddi|zuHause3>i can't run ECS maps...
15:33<Eddi|zuHause3>2kx2k with very few industries totally choke my system
15:34<Ammler>well, I play only with 256²
15:35<Eddi|zuHause3>problem appears to be, that the industry amount generated is per industry type, not over all industries, so when you have 20 industry types instead of 10, you get twice the amount of industries
15:35<Eddi|zuHause3>so you get way too many industries to start with...
15:35<Ammler>I have only 2 vectors loaded, that might be the problem then :-)
15:36<Ammler>is there a difference between tranfer and unload in cargodest?
15:37<Ammler>s
15:37<Eddi|zuHause3>transfer is useless
15:38<SmatZ>what about transfer credits?
15:38<SmatZ>or is it handled for unload, too?
15:38<Ammler>SmatZ: yep
15:38<Ammler>well, it looks like
15:38<Eddi|zuHause3>1 out of 3 hunks FAILED -- saving rejects to file src/misc_gui.cpp.rej :((
15:38<Ammler>I see green and yellow msg together :-)
15:38<@Rubidium>some's merging yapp?
15:39<SmatZ>in trunk?
15:39<Eddi|zuHause3>Rubidium: i tried to apply Celestar's patch to the paxdest thing
15:39<@peter1138>Where?
15:39<@Rubidium>nah, looks like Eddi|zuHause3's is doing that locally
15:39<@peter1138>Eddi|zuHause3, oh, my repo has been synced with trunk since then. Sorry.
15:40<@peter1138>You can try going back some revisions, but I have no idea how :)
15:40<SmatZ>hehe
15:40<Eddi|zuHause3>it's just some widget sizes, it appears
15:42<@peter1138>Ooh, a PM from SirkoZ.
15:42<@peter1138>Whoops, I hit the delete button :o
15:43-!-Purno [~Purno@5350931D.cable.casema.nl] has quit [Read error: Connection reset by peer]
15:43<Eddi|zuHause3>what's his problem?
15:45<fonso>Celestar: Do you have any more feedback for diagonal levelling and demolishing, yet? Or anyone else who might have had a look at it?
15:45-!-KillaloT [~killalot@0x5738ccc3.rdnqu1.dynamic.dsl.tele.dk] has quit [Read error: Connection reset by peer]
15:46<@Belugas>[15:39] <@peter1138> Ooh, a PM from SirkoZ. <--- poor you, i sympatize :)
15:46<Eddi|zuHause3>fonso: try not to push too much ;)
15:47-!-Brianetta [~brian@client-86-27-108-163.brnt.adsl.virgin.net] has joined #openttd
15:47<Eddi|zuHause3>hm... yapp new files... i don't really have a current yapp around...
15:47-!-Brianetta [~brian@client-86-27-108-163.brnt.adsl.virgin.net] has quit [Read error: Connection reset by peer]
15:48-!-KillaloT [~killalot@0x5738ccc3.rdnqu1.dynamic.dsl.tele.dk] has joined #openttd
15:48-!-Brianetta [~brian@client-86-27-108-163.brnt.adsl.virgin.net] has joined #openttd
15:48-!-welshdragon [~welshxcha@host86-137-37-42.range86-137.btcentralplus.com] has joined #openttd
15:51<Eddi|zuHause3>feature request: transfer credit should be x% less than the current value, to account for expected waiting times
15:51-!-Brianetta [~brian@client-86-27-108-163.brnt.adsl.virgin.net] has quit []
15:57<Ammler>are there any idea's how to handle the cargo destinations?
15:58<Ammler>how to distribute
15:58<Zuu>Is't "Sign* const *search_result;" a pointer to a const Sign* or is it the other way around?
15:58<@peter1138>There are ideas, yes.
16:01<Ammler>:-)
16:04-!-Klanticus__ [~Klanticus@201-43-57-195.dsl.telesp.net.br] has quit [Remote host closed the connection]
16:09<Eddi|zuHause3>Zuu: if you really need such a line, you are probably doing something very wrong
16:10<CIA-5>OpenTTD: smatz * r13902 /trunk/Makefile.src.in: -Fix (r13375): rev.cpp wasn't recreated when --revision was used and the 'modified' status of sources changed
16:13<Zuu>Eddi|zuHause3: I was wrong in that what I wanted is not typed as I wrote it. But it looks like _sign_sort is a dynamic array of const pointers.
16:13<Zuu>static const Sign **_sign_sort;
16:14<Zuu>So then I need to declare my search_result in a similar manner. (const Sign ** search_result;)
16:15<Zuu>Or I get cast error when I assign search_result[j] = _sign_sort[i]
16:32-!-TrueBrain [truelight@80.247.163.110] has joined #openttd
16:35<@peter1138>Zuu: _sign_sort does not exist any more.
16:35<Zuu>Not?
16:35<Zuu>So you have changed it recently?
16:36<Zuu>(last week)
16:36<@peter1138>Two days ago.
16:36-!-rortom [~rortom@p57B7C126.dip.t-dialin.net] has joined #openttd
16:36<Zuu>Oh.. well, some coding experience at least :)
16:36<TrueBrain>Expect web-related problems: DNS update in progress (can take up to an hour before it is at your client :))
16:37*Zuu detects no problems at openttd.org :(
16:37<Zuu>:p
16:38-!-Vikthor [~Vikthor@snat1.spoje.net] has quit [Ping timeout: 480 seconds]
16:38<TrueBrain>depends on which subdomain you are surfing :)
16:38<Zuu>only tried nightly.openttd.org
16:39-!-svippy [~svip@0x50a5b150.boanxx18.dynamic.dsl.tele.dk] has joined #openttd
16:39-!-svippery [~svip@0x50a5b150.boanxx18.dynamic.dsl.tele.dk] has quit [Read error: Connection reset by peer]
16:41<TrueBrain>and that is one of the few not changing this night :)
16:43<Zuu>hmm, wiki.openttd.org works, what's more to try? ;)
16:43<TrueBrain>svn.openttd.org? :p
16:43<@Belugas>svn, hg, blog,...
16:43<@Belugas>bugs
16:43<Zuu>Ok, that don't work.
16:43<@Belugas>boobs
16:43<@Belugas>mmh..
16:44<TrueBrain>like, nobody can commit currently ;)
16:44<@Belugas>never workd...
16:44<Prof_Frink>norks.openttd.org ?
16:44<@Belugas>boohooo....
16:44<@Belugas>kick.openttd.org
16:44<Prof_Frink>Belugas: http://www.owenrudge.net/various/n37108819_32387967_8981.jpg
16:44<Zuu>but bugs and hg works :)
16:44<@peter1138>!norks
16:44<TrueBrain>Zuu: then you already had the DNS update ;)
16:45-!-frosch123 [~frosch@frnk-590fee31.pool.einsundeins.de] has quit [Remote host closed the connection]
16:45<@Belugas>that's you Prof_Frink? shold go on a diet :)
16:45<Prof_Frink>No, that's orudge's norkular friend.
16:46<@Belugas>right...
16:46<@peter1138>Hmm, hg no longer redirects to port 8000...
16:47<Eddi|zuHause3>so... reducing passenger numbers... important...
16:47<TrueBrain>peter1138: one of the chances ;)
16:47<@peter1138>What is serving that?
16:48<Eddi|zuHause3>hm... some trains are leaving empty even though 1500 passengers are waiting...
16:54<SmatZ>peter1138: FS#2172 - kais58's problem was solved by switching to WIN grfs, but the fact that OTTD crashes with segfault isn't very nice...
16:54<@peter1138>That's not *solved*
16:54<@peter1138>That is a workaround.
16:54<SmatZ>peter1138: and the task isn't closed
16:56<@peter1138>Well that's something :p
16:57<TrueBrain>if you do it correctly, http://svn.openttd.org/ <- this should give one hell of an ugly page
16:57*peter1138 wonders if the station view should toggle between just cargo type, sources and destinations, and just destinations shown.
16:58<@peter1138>There's a bit too much information there currently.
16:58<@peter1138>TrueBrain, ugly? No, it's nice plain HTML :D
16:58<TrueBrain>peter1138: well, okay okay :p
16:58<TrueBrain>@op
16:58-!-mode/#openttd [+o TrueBrain] by DorpsGek
16:58<@peter1138>Although somewhat invalid HTML.
16:59-!-TrueBrain changed the topic of #openttd to: 0.6.1 | Website: *.openttd.org (Translator: translator2, Gameservers: servers, Nightly-builds: nightly, WIKI: wiki, Dev-docs: docs, Patches & Bug-reports: bugs, Revision log: vcs) | #openttd.notice for FS + SVN notices | UTF-8 please | No Unauthorised Bots | We Love YAPP
16:59<@TrueBrain>http://vcs.openttd.org/svn/ <- still I find that more readable :p
16:59<@peter1138>Oh, that's where it's hidden.
17:00<@TrueBrain>well, trac was long gone .. it is back since today :p
17:00<@peter1138>Are the performance problems fixed, or is it too soon to know?
17:00<@TrueBrain>too soon
17:00<@TrueBrain>but it feels fast :)
17:00<@TrueBrain>else you can always use:
17:01<@orudge>nice work on the cleanup, there
17:01<@TrueBrain>http://vcs.openttd.org/hg/
17:01<@TrueBrain>or
17:01*orudge is just reading the e-mail
17:01<@TrueBrain>http://vcs.openttd.org/git/
17:01<@orudge>hmm, so both hg and git are running on there?
17:01<rortom>peter1138: that calls for a station gui update ;)
17:01<@TrueBrain>orudge: 'running' is a big word, but they are readable from there :)
17:01<@orudge>heh
17:02<@TrueBrain>for the german people: https://secure.openttd.org/vcs/svn/
17:02<@orudge>ooh, and trac is back
17:02<@orudge>yay
17:02-!-KritiK [~Maxim@78-106-214-150.broadband.corbina.ru] has joined #openttd
17:02<@peter1138>Why German?
17:03<@TrueBrain>or sweden .. which country now can do random taps on people their connection? :)
17:03<rortom>haha :p
17:04<Wolf01>'night
17:04-!-Wolf01 [~wolf01@host41-160-dynamic.56-82-r.retail.telecomitalia.it] has quit [Quit: Once again the world is quick to bury me.]
17:05<Zuu>!logs
17:05<SpComb>Logs: http://zapotek.paivola.fi/~terom/logs/openttd
17:05<Eddi|zuHause3>that was indeed sweeden
17:05<Eddi|zuHause3>but i would not put it past the german government to follow that lead
17:06-!-Progman [~progman@p57A1D1E3.dip.t-dialin.net] has joined #openttd
17:06-!-TinoM [~Tino@i59F55DED.versanet.de] has quit [Quit: Verlassend]
17:06<Zuu>Eddi|zuHause3: Through they said they will only listen to non-swedish traffic and therefor normal people will not be affected :D
17:06<Zuu>non-swedish as not in swedish language
17:07<Eddi|zuHause3>like... english?
17:07<Zuu>for example
17:07<Eddi|zuHause3>like... right now? :p
17:07<Ammler>peter1138: how are stations handled which do not have vehicels in the orders?
17:07<Zuu>Yep
17:07*TrueBrain slaps CIA-5
17:07<CIA-5>OpenTTD: rubidium * r13903 /trunk/src/masm64.rules: -Fix: missing eol-style property.
17:07<Ammler>(not non-stop orders)
17:07<Eddi|zuHause3>Ammler: they are ignored
17:07<@TrueBrain>good boy, CIA-5
17:07<@peter1138>Ammler: Not.
17:08<Eddi|zuHause3>this is total shit... "Error: RPM failed: Command was killed by signal 11 (Segmentation fault)."
17:08<Eddi|zuHause3>and apparently nobody else in the world has this problem
17:09<Ammler>heh, now I see why there is need to have cargo dest controllable per type :-)
17:09<@TrueBrain>Eddi|zuHause3: check memory
17:09<@TrueBrain>:p
17:09<@Rubidium>heh, broken memory is my excuse line!
17:09<Eddi|zuHause3>TrueBrain: memory problems would harldy be limited to RPM
17:10-!-welshdragon [~welshxcha@host86-137-37-42.range86-137.btcentralplus.com] has quit [Ping timeout: 480 seconds]
17:10<@TrueBrain>Eddi|zuHause3: last time I had a tons of weird segfaults and random kills .. turned out memory was bad :p
17:10<@TrueBrain>took a while :)
17:10<@TrueBrain>so I scream to you: check memory ;)
17:10<Eddi|zuHause3>yes, but i do not have weird and random segfaults... it's only RPM... which is fine a few times, and suddenly segfaults
17:11<Eddi|zuHause3>and has no way of recovering unless you reboot
17:11<@peter1138>Gah, early eGRVTS vehicles really suck :o
17:11<@TrueBrain>well .. get a real distro :p
17:11<SmatZ>hehe
17:11<Ammler>peter1138: low cap?
17:11<Eddi|zuHause3>yeah yeah...
17:11<@peter1138>Yeah, 8 passengers at 15 mph does not help a network :)
17:12<Eddi|zuHause3>1800?
17:12<@peter1138>1926
17:12<Ammler>there is need for early houses too :-)
17:13<Eddi|zuHause3>pre-1900 economy must be totally different...
17:14<Ammler>Eddi|zuHause3: there are some nice suse channels..
17:14<Eddi|zuHause3>Ammler: where? i never found any fitting that description...
17:14<Ammler>freenode
17:14<Eddi|zuHause3>anyway... need to reboot...
17:15-!-rortom [~rortom@p57B7C126.dip.t-dialin.net] has quit []
17:17-!-Eddi|zuHause3 [~johekr@p54B771CF.dip.t-dialin.net] has quit [Remote host closed the connection]
17:21-!-Eddi|zuHause2 [~johekr@p54B76397.dip.t-dialin.net] has joined #openttd
17:21-!-welshdragon [~welshxcha@host86-137-37-42.range86-137.btcentralplus.com] has joined #openttd
17:27-!-welshdragon [~welshxcha@host86-137-37-42.range86-137.btcentralplus.com] has quit [Read error: Connection reset by peer]
17:27-!-welshdragon [~welshxcha@host86-137-37-42.range86-137.btcentralplus.com] has joined #openttd
17:32-!-curson [~curzon@79-68-37-51.dynamic.dsl.as9105.com] has joined #openttd
17:33-!-XaT [~root@lan31-6-82-230-27-240.fbx.proxad.net] has quit [Read error: No route to host]
17:35<Zuu>Will anyone get offended if I start a new thread in Dev Section about search in sign list or should I get a mod to move the existing thread in suggestions forum?
17:35<Yexo>just atart a new thread
17:36<Zuu>Ok
17:38<@TrueBrain>And a notice for everyone: git and hg repos are moved, and under a new URL. Either use: https://secure.openttd.org/git (or hg), or http://git.openttd.org (or hg), or git://git.openttd.org (not for hg)
17:40<@orudge>you should add cvs.openttd.org for completeness sake ;)
17:40<@orudge>and Microsoft SourceSafe! :p
17:40<@TrueBrain> grr @ orudge
17:40<@TrueBrain>I was about to type @kick orudge, but I am known to do it wrong, and really kick you :p
17:41<blathijs>Perhaps this is a nice opportunity to play with hg instead of git when I go fiddling around with mempools
17:41-!-mode/#openttd [-o orudge] by Rubidium
17:41<+orudge>:(
17:41<@Rubidium>yes... you've been punished ;)
17:41-!-mode/#openttd [+o orudge] by ChanServ
17:41<@orudge>:)
17:41<@TrueBrain>blathijs: sounds like a plan :)
17:41*orudge has been using git a fair bit for wine recently
17:41<@TrueBrain>git sucks, hg rules :)
17:41<@orudge>alas, it doesn't work so well on Windows
17:41<@TrueBrain>exactly :)
17:41<@orudge>and I do most of my OpenTTD-related things on Windows
17:41<@TrueBrain>I wonder if anyone noticed that on all new pages the OpenTTD icon is in their webbrowser ... :)
17:42<@orudge>not as such
17:42<@orudge>well, I didn't
17:42<@orudge>but then
17:42<Eddi|zuHause2>new mempools... that task existed before i came here
17:42<@orudge>it was always there for openttd.org itself, I think?
17:42<Eddi|zuHause2>that is over two and a half years ago...
17:42<@orudge>so I was probably just used to it being there for that :p
17:42<@TrueBrain>orudge: only for main-page :)
17:42<@orudge>heh, OK
17:43<@orudge>ah, and running lighttpd for vcs.openttd.org, good :)
17:43<@peter1138>$ hg pull
17:43<@peter1138>pulling from http://hg.openttd.org:8000/trunk.hg/
17:43<@peter1138>:o
17:43<@peter1138>how do i change that? :o
17:43<@TrueBrain>.hg/hgrc
17:44<@TrueBrain>orudge: all front-pages use lighttpd .. sadly enough a few pages are proxies to apache
17:44<@TrueBrain>(some just refused to work otherwise)
17:44<@orudge>I see
17:44<@peter1138>Ah, http://hg.openttd.org/openttd/trunk.hg/ :o
17:45<@peter1138>Hmm, slow...
17:45<@TrueBrain>it is slightly faster then the former method :p
17:45<@TrueBrain>but the first request is very slow :p
17:48-!-LilDood [~IceChat7@cpc2-bolt5-0-0-cust370.manc.cable.ntl.com] has quit [Quit: When the chips are down, well, the buffalo is empty]
17:50-!-Vikthor [~Vikthor@snat1.spoje.net] has joined #openttd
17:52<@peter1138>Well
17:52<@peter1138>I already had a checkout :p
17:52<@TrueBrain>I ment to the http :)
17:52<@peter1138>added 9513 changesets with 2455 changes to 1533 files (+1 heads)
17:52<@peter1138>:p
17:53<@TrueBrain>and yes, this version is a bit more .. .complete
17:53<@TrueBrain>with tnx to Rubidium for removing the .... 'branch' mistake ;)
17:53<@TrueBrain>lets state it just never happened :)
17:53<@peter1138>well, nini
17:54<@TrueBrain>night peter1138
18:01-!-clochette [~clochette@212-198-248-33.rev.numericable.fr] has joined #openttd
18:01-!-ecke [~ecke@21.161.broadband7.iol.cz] has quit [Quit: ecke]
18:03-!-clochette [~clochette@212-198-248-33.rev.numericable.fr] has quit []
18:21-!-fonso [~fonso@brln-d9bacf2b.pool.mediaWays.net] has quit [Quit: Kopete 0.12.7 : http://kopete.kde.org]
18:24-!-curson [~curzon@79-68-37-51.dynamic.dsl.as9105.com] has quit [Quit: If everything seems to be going well, you have obviously overlooked something.]
18:26<Ammler>TrueBrain: you should change your status, it is still retired :-)
18:27<@TrueBrain>I am still are, OpenTTD main development-wise
18:27-!-Bjarni [~Bjarni@0x50a41670.virnxx14.dynamic.dsl.tele.dk] has joined #openttd
18:27-!-mode/#openttd [+o Bjarni] by ChanServ
18:28<ln>Bjarni!
18:28<@Bjarni>hello
18:28<@TrueBrain>ln: you are happy to see him... why?
18:28<@Bjarni>finally home
18:28<@Bjarni>TrueBrain: I wondered about the same thing :/
18:28<@TrueBrain>glad we agree on that :)
18:28<@TrueBrain>hi btw :)
18:29<@Bjarni>hi TrueBrain
18:29<ln>TrueBrain: i could equally well be shocked to see him.
18:29<@TrueBrain>I was
18:29<@TrueBrain>:p
18:30<ln>or just surprised.
18:30<@TrueBrain>no, shocked
18:30<@TrueBrain>clearly
18:34-!-DJNekkid_ [~chatzilla@static217-26.adsl.no] has joined #openttd
18:34-!-DJNekkid_ is now known as DJNekkid
18:34<DJNekkid>hi all ...
18:34<DJNekkid>are there any known bugs in the color window?
18:34<@TrueBrain>gimp works pretty well here
18:34<DJNekkid>i mean ... the extended window, like monorail have it's own color and such
18:34<@TrueBrain>but I don't see what it has to do with OpenTTD :)
18:34<DJNekkid>hehe!
18:35<DJNekkid>well, i take it you didnt understand what i ment?
18:36<@TrueBrain>who would have guessed :)
18:36<@TrueBrain>'the color window'
18:36<@Rubidium>seems to work as it should work
18:36<@TrueBrain>how vague can one be :)
18:37<DJNekkid>even with newgrfs?
18:37<@Rubidium>yes
18:37<DJNekkid>hmm
18:39<welshdragon>what ports does openttd use?
18:40<Prof_Frink>Dover
18:40<Prof_Frink>Southampton
18:40-!-stillunknown [~stillunkn@82-136-225-75.ip.telfort.nl] has quit [Read error: Connection reset by peer]
18:40<@TrueBrain>@openttd ports
18:40<@DorpsGek>TrueBrain: OpenTTD uses TCP and UDP port 3979 for server <-> client communication and UDP port 3978 for masterserver (advertise) communication (outbound)
18:40<welshdragon>shush you
18:40<@TrueBrain>lol @ Prof_Frink :) Genious :)
18:40<Prof_Frink>I am.
18:41<@TrueBrain>and now it smells here
18:41<@TrueBrain>brr
18:41<SmatZ>hehe
18:41-!-olgagirl [~olgagirl@212-198-248-33.rev.numericable.fr] has joined #openttd
18:41<SmatZ>olga! girl!
18:41-!-Progman [~progman@p57A1D1E3.dip.t-dialin.net] has quit [Remote host closed the connection]
18:41<@TrueBrain>try PMing her :p
18:41<@TrueBrain>well, 'it'
18:41<SmatZ>hehe
18:41<@TrueBrain>really, if it leaves again in 2 minutes
18:41<@TrueBrain>you want to :)
18:41<DJNekkid>http://bildr.no/image/234062.jpeg
18:41<dih>hello :-)
18:41<welshdragon>actually, my bt homehub (no comments please) may have openttd saved as a preset
18:42<dih>HEY
18:42<DJNekkid>look at that one please
18:42*dih smiles from one ear to another
18:42<dih>nice to see you here TrueBrain
18:42<SmatZ>hello olgagirl
18:42<@TrueBrain>dih: who? where?
18:42<@TrueBrain>SmatZ: in a PM!
18:42-!-olgagirl [~olgagirl@212-198-248-33.rev.numericable.fr] has quit []
18:42<SmatZ>:'-(
18:42<SmatZ>too late
18:42<Prof_Frink>SmatZ: Now look wat you did
18:42<@TrueBrain>SmatZ: on an other IRC network I am on, we klined those addresses
18:42<SmatZ>sorry guys
18:42<@TrueBrain>they are 'scan' bots
18:43<@TrueBrain>REALLY annoying
18:43<SmatZ>what do they want?
18:43<@TrueBrain>you can have up to 100 a day ..
18:43<@TrueBrain>I suspect http://www.gogloom.com/
18:43<Prof_Frink>Aye, they pop up on blitzed too
18:43<SmatZ>TRUE CHAT
18:44<@TrueBrain>http://www.gogloom.com/OFTC/openttd/
18:44<SmatZ>looks... suspicious, TrueBrain :)
18:44<@TrueBrain>reason it is klined on most networks :)
18:44<@TrueBrain>really annoying
18:44-!-Lakie [~Lakie@80.247.163.109] has quit [Killed (NickServ (Too many failed password attempts.))]
18:44-!-Lakie [~Lakie@80.247.163.109] has joined #openttd
18:44<DJNekkid>TrueBrain: well if you need elaboration check this picture ... http://bildr.no/image/234062.jpeg it seems like the monorails dont get appropiate color
18:44<@TrueBrain>DJNekkid: wrong person :)
18:44<DJNekkid>oh :)
18:45<SmatZ>hehe
18:45<@TrueBrain>anyway, SmatZ, if you send a PM to those bots
18:45<@TrueBrain>it is fun
18:45<@TrueBrain>they talk back for 2 or 3 lines
18:45<@TrueBrain>clearly automated
18:45<@TrueBrain>very amuzing :)
18:45<@Rubidium>DJNekkid: looks like the trains have no company colour capability
18:45<SmatZ>:-)
18:45<welshdragon>thank you re: ports... my game kept desynching
18:46<DJNekkid>Rubidium: they are in magic blue and magic 2cc green
18:47<@Rubidium>then they're maybe dmus or emus
18:49<DJNekkid>nope, not that either
18:49<DJNekkid>well, a few are, but that is just for testing
18:50<DJNekkid>that helped tho
18:51<DJNekkid>but it didnt change on monorail trains
18:51<DJNekkid>or ... perhaps i need 19 32 ...
18:51<DJNekkid>sec
18:52<DJNekkid>yea
18:52<DJNekkid>that helped
18:55<CIA-5>OpenTTD: glx * r13904 /trunk/src/strings.cpp: -Fix (r13715): 'cast from/to pointer to/from integer of different size' warnings
18:58-!-unenana [~unenana@212-198-248-33.rev.numericable.fr] has joined #openttd
19:00-!-unenana [~unenana@212-198-248-33.rev.numericable.fr] has quit []
19:01-!-Zuu [~Zuu@c-fd4ee055.510-8-64736c10.cust.bredbandsbolaget.se] has quit [Quit: Leaving]
19:03-!-Bjarni [~Bjarni@0x50a41670.virnxx14.dynamic.dsl.tele.dk] has quit [Quit: Leaving]
19:07-!-bleepy [bleepy@5ad34870.bb.sky.com] has quit [Ping timeout: 480 seconds]
19:13-!-stillunknown [~stillunkn@82-136-225-75.ip.telfort.nl] has joined #openttd
19:16-!-Dred_furst [~Dred_furs@user-514d7e3a.l2.c2.dsl.pol.co.uk] has quit [Read error: Connection reset by peer]
19:18-!-stillunknown [~stillunkn@82-136-225-75.ip.telfort.nl] has quit [Quit: leaving]
19:19-!-stillunknown [~stillunkn@82-136-225-75.ip.telfort.nl] has joined #openttd
19:25*TrueBrain wondws why nobody notice it that bugs.openttd.org isn't working :p
19:25<@TrueBrain>do none of you look at that or something?
19:27<dih>http://nightly.openttd.org/devs/rev <- is there also a file that shows the current stable release?
19:28<@TrueBrain>there are more of such files
19:28<@TrueBrain>not sure where and how they are called
19:28<dih>that would be exactly the info i was after :-P
19:28<@TrueBrain>most likely
19:28<@TrueBrain>:)
19:28<SmatZ>$TOPIC[1]
19:29<dih>?
19:34<Eddi|zuHause2>svn ls tags | sort | tail -n 1
19:36<@TrueBrain>Eddi|zuHause2: not the latest stable ;0
19:36<@TrueBrain>svn ls tags | sort | grep -v RC | tail -n 1
19:36<@TrueBrain>might work better
19:36<Eddi|zuHause2>yeah, it might catch release candidates ;)
19:36<SmatZ>| grep -v beta |
19:36<@TrueBrain>grep -v "RC\|beta"
19:36<@TrueBrain>;)
19:36<SmatZ>:)
19:38<Eddi|zuHause2>next thing would be some magic with the rss-feed ;)
19:38<Ammler>or grep the readme in trunk
19:38<@TrueBrain>unwise :p
19:38<Eddi|zuHause2>bad idea :p
19:38<Ammler>:P
19:39<Eddi|zuHause2>chances are that a) the readme has not been touched since 0.6 branch or b) it is updated for 0.7 already
19:40<Ammler>it might still be a beta there :-)
19:41-!-GoneWacko [GoneWacko@86-60-147-155-dyn-dsl.ssp.fi] has quit []
19:42-!-Vikthor [~Vikthor@snat1.spoje.net] has quit [Quit: Leaving.]
19:59-!-stillunknown [~stillunkn@82-136-225-75.ip.telfort.nl] has quit [Ping timeout: 480 seconds]
20:06-!-shodan [user@ppp101-219.static.internode.on.net] has joined #openttd
20:06-!-jennyf [~jennyf@212-198-248-33.rev.numericable.fr] has joined #openttd
20:08-!-jennyf [~jennyf@212-198-248-33.rev.numericable.fr] has quit []
20:19-!-sandra_f [~sandra_f@212-198-248-33.rev.numericable.fr] has joined #openttd
20:21-!-sandra_f [~sandra_f@212-198-248-33.rev.numericable.fr] has quit []
20:27<@TrueBrain>SmatZ: you missed 2 of them :p
20:29<SmatZ>TrueBrain: oh no, 2 of what?
20:30<@TrueBrain>[02:06] --> jennyf has joined this channel (~jennyf@212-198-248-33.rev.numericable.fr).
20:30<@TrueBrain>[02:08] <-- jennyf has left this server.
20:30<@TrueBrain>[02:19] --> sandra_f has joined this channel (~sandra_f@212-198-248-33.rev.numericable.fr).
20:30<@TrueBrain>[02:21] <-- sandra_f has left this server.
20:30<SmatZ>ahhh :)
20:31<CIA-5>OpenTTD: translators * r13905 /trunk/src/lang/ (11 files): (log message trimmed)
20:31<CIA-5>OpenTTD: -Update: WebTranslator2 update to 2008-08-01 02:27:37
20:31<CIA-5>OpenTTD: brazilian_portuguese - 22 fixed by tucalipe (22)
20:31<CIA-5>OpenTTD: dutch - 9 fixed by habell (9)
20:31<CIA-5>OpenTTD: estonian - 4 fixed by kristjans (4)
20:31<CIA-5>OpenTTD: french - 5 fixed, 1 changed by glx (6)
20:31<CIA-5>OpenTTD: galician - 105 fixed, 206 changed by Condex (311)
20:32-!-Chrill [~chrischri@c80-216-64-31.bredband.comhem.se] has joined #openttd
20:33-!-svippy [~svip@0x50a5b150.boanxx18.dynamic.dsl.tele.dk] has quit [Read error: Connection reset by peer]
20:33-!-svippy [~svip@0x50a5b150.boanxx18.dynamic.dsl.tele.dk] has joined #openttd
20:34-!-Eddi|zuHause3 [~johekr@p54B77275.dip.t-dialin.net] has joined #openttd
20:37<CIA-5>OpenTTD: rubidium * r13906 /branches/0.6/src/lang/piglatin.txt: [0.6] -Fix: eol-style of piglatin is wrong making language backport scripts barf.
20:40-!-Eddi|zuHause2 [~johekr@p54B76397.dip.t-dialin.net] has quit [Ping timeout: 480 seconds]
20:41-!-olgagirl [~olgagirl@212-198-248-33.rev.numericable.fr] has joined #openttd
20:41<SmatZ>here is one!
20:42<@TrueBrain>PM it
20:42<@Rubidium>ban it!
20:42<@TrueBrain>@ban olgagirl
20:42-!-mode/#openttd [+o SmatZ] by Rubidium
20:42<@TrueBrain>stupid DorpsGek
20:42-!-KillaloT [~killalot@0x5738ccc3.rdnqu1.dynamic.dsl.tele.dk] has quit [Read error: Connection reset by peer]
20:43-!-mode/#openttd [+b olgagirl!*@*] by SmatZ
20:43<@SmatZ>mmm
20:43-!-mode/#openttd [+b spam!*@*] by SmatZ
20:43<Yexo>what's the matter with all those users from the same ip?
20:43-!-olgagirl was kicked from #openttd by SmatZ [spam]
20:43<@TrueBrain>it is a scanner
20:43<@TrueBrain>SmatZ: ban the IP
20:43<@SmatZ>[02:43:05] <olgagirl> camcult.com
20:43<@SmatZ>it looks like spam...
20:44-!-mode/#openttd [-b spam!*@*] by SmatZ
20:44-!-mode/#openttd [-b olgagirl!*@*] by SmatZ
20:44<@SmatZ>I am too nice to ban people
20:44<@SmatZ>though... those are not humans...
20:44-!-mode/#openttd [+b *!*@212-198-248-33.rev.numericable.fr] by TrueBrain
20:44<@TrueBrain>but I have no problems with it
20:44<@SmatZ>hehe
20:44<@SmatZ>hero TrueBrain
20:45<@SmatZ>http://paste.openttd.org/38686 :)
20:45<+glx>@ban *!*@212-198-248-33.rev.numericable.fr
20:45<@TrueBrain>glx: DorpsGek doesn't know banning :p
20:45<+glx>@op
20:45-!-mode/#openttd [+o glx] by DorpsGek
20:45<@TrueBrain>SmatZ: told you it was fun
20:46<ln>banna dig så hårt
20:46<@SmatZ>hehe
20:46<@SmatZ>like those ICQ bots...
20:47*glx should reinstall ICQ to see how many asked me to add them
20:47<@SmatZ>hehe
20:48<fmauNeko>USER PID PU %MEM VSZ RSS TTY STAT START TIME COMMAND
20:48<fmauNeko>root 1 0.0 0.0 864 328 ? Ss Jul31 0:01 init [5]
20:48<fmauNeko>root 2 0.0 0.0 0 0 ? S< Jul31 0:00 [kthreadd]
20:48<fmauNeko>root 3 0.0 0.0 0 0 ? S< Jul31 0:00 [migration/0]
20:48<fmauNeko>root 4 0.0 0.0 0 0 ? S< Jul31 0:05 [ksoftirqd/0]
20:48<fmauNeko>root 5 0.0 0.0 0 0 ? S< Jul31 0:00 [migration/1]
20:48<fmauNeko>root 6 0.0 0.0 0 0 ? S< Jul31 0:03 [ksoftirqd/1]
20:48<fmauNeko>root 7 0.7 0.0 0 0 ? S< Jul31 2:43 [events/0]
20:48<fmauNeko>root 8 0.0 0.0 0 0 ? S< Jul31 0:01 [events/1]
20:48-!-fmauNeko [~fmauNeko@thor.fmauneko.eu] has quit [Excess Flood]
20:49<@glx>nice one
20:49<@SmatZ>:_)
20:49-!-fmauNeko [~fmauNeko@thor.fmauneko.eu] has joined #openttd
20:50<fmauNeko>sry, i don't know what the hell done my irc client
20:50<ln>was that the first time fmauNeko ever said anything?
20:51<@TrueBrain>omg
20:51<@TrueBrain>in that case: welcome fmauNeko
20:51<fmauNeko>thx :)
20:52<fmauNeko>i was trying something on #openttd, but on another network (irc://localhost/)
20:52<@SmatZ>hehe
20:52<fmauNeko>and the client forgot the '| grep openttd'
20:55-!-svippery [~svip@0x50a5b150.boanxx18.dynamic.dsl.tele.dk] has joined #openttd
20:55-!-svippy [~svip@0x50a5b150.boanxx18.dynamic.dsl.tele.dk] has quit [Read error: Connection reset by peer]
20:56-!-Chrill [~chrischri@c80-216-64-31.bredband.comhem.se] has quit [Quit: scouting for sexy ass]
20:57-!-KritiK [~Maxim@78-106-214-150.broadband.corbina.ru] has quit [Quit: Leaving]
20:58-!-a1270 [~Cheese@24-117-51-112.cpe.cableone.net] has quit [Quit: a1270]
21:00-!-a1270 [~Cheese@24-117-51-112.cpe.cableone.net] has joined #openttd
21:03-!-fmauNeko is now known as fmauNekAway
21:09<ln>wrong
21:11*TrueBrain waves goodbye to this channel :) Have a good one!
21:11-!-TrueBrain [truelight@80.247.163.110] has left #openttd [So long and tnx for all the fish]
21:21-!-svippy [~svip@0x50a5b150.boanxx18.dynamic.dsl.tele.dk] has joined #openttd
21:21-!-svippery [~svip@0x50a5b150.boanxx18.dynamic.dsl.tele.dk] has quit [Read error: Connection reset by peer]
21:24-!-elmex [~elmex@e180066143.adsl.alicedsl.de] has quit [Remote host closed the connection]
21:30-!-Wezz6400 [~Wezz6400@ndb.demon.nl] has quit [Quit: Wezz6400]
21:47-!-tokai [~tokai@p54B8030E.dip0.t-ipconnect.de] has joined #openttd
21:48-!-mode/#openttd [+v tokai] by ChanServ
22:02-!-svippery [~svip@0x50a5b150.boanxx18.dynamic.dsl.tele.dk] has joined #openttd
22:02-!-svippy [~svip@0x50a5b150.boanxx18.dynamic.dsl.tele.dk] has quit [Read error: Connection reset by peer]
22:04-!-welshdragon is now known as welshdra-gone
22:04<Celestar>hm ..
22:04<Celestar>@who
22:05<@Rubidium>hello Celestar
22:05<Celestar>I'm just through TrueBrain's e-mail :)
22:05<Celestar>hey Rubidium (=
22:05<Celestar>that's an awful lot of work you guys went through didn't you?
22:05<@Rubidium>jup, but necessary
22:09<Celestar>there's just one problem :)
22:09<Celestar>it's minor tho :P
22:09<Celestar>I'm lacking secure.openttd.org's certificate
22:10<@glx>do you need one?
22:10<@Rubidium>import cacert as root certificate
22:10<@Rubidium>then it should work
22:10<Celestar>Rubidium: which cacert?
22:10<Celestar>where is it? ;)
22:10<@Rubidium>http://cacert.org/ <- that cacert
22:12<Celestar>O_o
22:12<Celestar>secure.openttd.org uses an invalid security certificate.
22:12<Celestar>that's what my ff3 spits out
22:14<@Rubidium>so you ssl configuration misses the cacert certificate
22:15<Celestar>firefox needed a restart after ca import O_o
22:16-!-Noetloj [~105Adam@5acb31ac.bb.sky.com] has quit [Quit: I lost my teddy, can I sleep with you instead? :(]
22:17-!-svippy [~svip@0x50a5b150.boanxx18.dynamic.dsl.tele.dk] has joined #openttd
22:17-!-svippery [~svip@0x50a5b150.boanxx18.dynamic.dsl.tele.dk] has quit [Read error: Connection reset by peer]
22:18<Celestar>kleopatra imported it nicely
22:18<Celestar>for secure mail access
22:19<Celestar>Rubidium: any idea what the retransmission settings are on that smtp daemon? The outgoing mails are apparently not getting through our greylisting filter
22:19<@Rubidium>no, but retransmission is not done quickly
22:20<@Rubidium>looks like it took an hour for SmatZ's greylist server
22:20-!-DJNekkid [~chatzilla@static217-26.adsl.no] has quit [Ping timeout: 480 seconds]
22:21<Celestar>ok
22:21<Celestar>I'll wait
22:21<Celestar>now if only peter1138 wouldn't shutdown his p00ter at night :P
22:26<Celestar>ok yapp + cargodest totally owns (=
22:26<@glx>I can't compile cargodest
22:26<@glx>makedepend seems to not like boost
22:28<Celestar>glx: makedepend?
22:29<Celestar>methinks we should include boost in the source tree as svn:externals
22:29<@glx>makedepend does the same as all [DEPS] line in 1 command
22:37<Celestar>I see
22:37<Celestar>hm ..
22:37<Celestar>I don't manage to desync yapp+cargodest (=
22:45<@glx>ok seems it doesn't like - in flags
22:45<Celestar>what flags?
22:46<@glx>-I/usr/local/include/boost-1_35
22:46<Celestar>eww
22:47<Celestar>is that your distro's default installation path?
22:47<@glx>I just did make install for boost
22:48<Celestar>heh
22:48<@glx>btw I fixed it by moving boost-1_35/boost to boost ;)
22:48<Celestar>maybe you want to adjust the prefix to something sane, apparently the default is crap :P
22:48<@glx>that way no need to extra -I
22:49<@glx>compiled :)
22:50-!-welshdra-gone [~welshxcha@host86-137-37-42.range86-137.btcentralplus.com] has quit [Quit: Leaving]
22:52<@glx>hmm strange it compiled it as console app
22:53<@glx>maybe a boost effect
22:55<@glx>hmm LDFLAGS is empty
22:58<Celestar>hm .. sometimes I make losses when delivering passengers :P
22:59<Celestar>wtf?
23:00<Celestar>I can build a trambit on a tile where another company already has one?
23:00<@glx>yes it's like a road
23:00<hylje>think you can build roadbits on other companies' roads too
23:00<Celestar>but it belongs to them then :P
23:07<@glx>ok LDFLAGS "problem" will be fixed with r13863
23:07*glx slaps Bjarni
23:07<Celestar>what happened?
23:08<@glx>he played with config.lib
23:08<@glx>@openttd commit 13863
23:08<@DorpsGek>glx: Commit by smatz :: r13863 trunk/config.lib (2008-07-28 23:10:26 UTC)
23:08<@DorpsGek>glx: -Fix (r13852): make the nightly compile again
23:08<Celestar>that wasn't bjarni (=
23:08<@glx>@openttd commit 13852
23:08<@DorpsGek>glx: Commit by bjarni :: r13852 /trunk (config.lib src/unix.cpp) (2008-07-27 20:43:21 UTC)
23:08<@DorpsGek>glx: -Fix (r13849): [OSX] fixed universal binary building without breaking anything this time
23:08<@glx>that was :)
23:09<@glx>anyway win32 compiles (just not static nor GUI mode)
23:10<Celestar>:(
23:11<@glx>not being GUI mode just means there's always a console window (even for release builds) so not important for now :)
23:11<@glx>but the non static part can be a problem
23:12<@glx>anyway it's fixed in trunk
23:12<@glx>it just need a sync
23:18<@glx>hmm mail wants to go to passenger stops
23:20<Celestar>yeah
23:20<Celestar>the destination generation doesn't take acceptance into account yet
23:20<Celestar>I'm planning to do that tomorrow morning
23:20<Celestar>(in about 4 hours :P)
23:26<@glx>the graph is always drawn on the map
23:27<Celestar>yeah
23:27<Celestar>afaik peter1138 is planning to add an individual button for it
23:28<@glx>sometimes station window is half refreshed
23:28<Celestar>you mean not really refreshed
23:28<Celestar>dunno what happens there
23:29<@glx>happens when a long string is replaced with a short one
23:29-!-svippy [~svip@0x50a5b150.boanxx18.dynamic.dsl.tele.dk] has quit [Read error: Connection reset by peer]
23:29-!-svippy [~svip@0x50a5b150.boanxx18.dynamic.dsl.tele.dk] has joined #openttd
23:30<@glx>anyway it seems to work well :)
23:30<Celestar>:D
23:31<@glx>my buses lose money but that's normal (very short trip in town)
23:32<Celestar>yeah but the payment is totally fux0red
23:33<@glx>and A-B, A-C, A-D bus lines are not optimal for money
23:34<@glx>as every passengers should transfer at A
23:38<Celestar>you should have a shitload of passengers by now :P
23:38<@glx>not that much
23:38<@glx>very small network
23:38<Celestar>just wait (=
23:39<@glx>but I added truck stop to all bus stop (for mail)
23:42<Celestar>still no desync \o(
23:43<@glx>hmm circular line doesn't work well
23:43<@glx>they don't take mail if it's not for the next station in the loop
23:44<Celestar>huh?
23:44<CIA-5>OpenTTD: belugas * r13907 /trunk/src/ (8 files in 2 dirs): -Codechange: Replace a number with Colours enum on DrawFrameRect usage
23:44<Celestar>they should, they just take the shortest route
23:45<@glx>my mail trucks all do A->B->C->D
23:45<@glx>there's mail in B for D or A but they never take it
23:45<Celestar>because they take other stuff?
23:46<@glx>no
23:46<@glx>they are empty
23:46<Celestar>heh .. show peter1138 or me (past-10:00) the savegame :)
23:47<@glx>I'll put the save on my dev space
23:48<Celestar>ok then you need to manually poke peter1138 or me to it (=
23:48<Celestar>or you give the debugging a try yourself
23:49<@glx>not now
23:49<@glx>I'm heading to my bed :)
23:49<Celestar>most the stuff is in cargopacket.cpp and routing.cpp/routing.h
23:50<Celestar>peter1138: I just noticed that there's a stray <map> include in routing.h .. we don't really need it anymore
23:50<Celestar>peter1138: it was just an attempt to make a manual vertex<->StationID mapping
23:51<@glx>Celestar: http://devs.openttd.org/~glx/mail_loop_bug.sav
23:53<Celestar>glx: standby looking
23:54<@glx>Tunston East is a good example
23:55<Celestar>glx: gotta recompile, wait (I still have yapp merged into it)
23:56<Celestar>I'm already with "n"
23:56<@glx>doesn't matter for trucks
23:56<Celestar>heh, but it can't load the savegame :P
23:56<Celestar>messed up the saveload revisions
23:56<@glx>of course
23:57<@glx>hmm already 6AM, I should go to sleep
23:57<Celestar>he 6am here too
23:57<Celestar>I'm going to work in an hour :P
23:57<Celestar>couldn't sleep this night
23:57<Celestar>(got about 3 hours)
23:57<@glx>heat?
23:57<Celestar>dunno
23:58<Celestar>I'm pretty heat-resistant normally
23:58-!-Netsplit resistance.oftc.net <-> charon.oftc.net quits: Yexo, jordi, Prof_Frink, Mark, fmauNekAway, planetmaker, Rexxars, tneo, jni, valhallasw, (+1 more, use /NETSPLIT to show all of them)
23:58<Celestar>up to 30°C in my sleeping room is a non-issue
23:58<@glx>then it's paxdest ;)
23:59<Celestar>yeah :D
23:59*Celestar looks at Tunston East
23:59*glx goes to sleep
---Logclosed Fri Aug 01 00:00:07 2008