Config
Log for #openttd on 28th July 2008:
Times are UTC Toggle Colours
05:22:03  *** SpComb [terom@zapotek.paivola.fi] has joined #openttd
06:00:16  *** bleepy [bleepy@5ad00eb3.bb.sky.com] has joined #openttd
06:16:49  <CIA-5> OpenTTD: peter1138 * r13855 /trunk/src/newgrf_cargo.cpp: -Fix [FS#2157]: Cargo type lookup was incorrect for GRFv7 files without a translation table.
06:25:12  <Celestar> morning
06:26:15  <peter1138> Hi
06:28:09  <Celestar> peter1138: I'm modifying some things about the routenetwork still, mainly moving order-related helper functions into the order class. If you have questions, just shoot away and I'll add them to the documentation
06:29:23  *** Malawar [~Malawar@97-83-117-160.dhcp.trcy.mi.charter.com] has joined #openttd
06:31:39  <Malawar> man, i'm having the hardest time figuring out signals; i've got a big loop of track ( screenshot: http://filebin.malawar.net/files/omgsignals.png ), i put down a two-way signal on it and have one train going around but the signal is always red. :/
06:32:32  <Celestar> Rubidium: peter1138: is the standard way to go in a member to use this-> or not to use this-> ?
06:33:14  <Ammler> Malawar: you are joking... :-)
06:33:22  <Malawar> i'm not :/
06:33:37  * Malawar is a noob :(
06:33:48  <peter1138> Celestar, so far we've used this->
06:33:59  <Celestar> peter1138: k
06:34:00  <peter1138> Except for YAPF.
06:34:04  <Celestar> peter1138: k k
06:34:08  <Ammler> Malawar: try a 2. signals
06:34:11  <Ammler> -s
06:35:34  <Celestar> peter1138: I'll be back in 10 minutes. gotta check our cluster cooling, apparently it has failed again :S
06:36:05  <Malawar> hm
06:36:12  <Malawar> i think i'm getting an understanding of how they work now :P
06:36:27  * SpComb melts Celestar's cluster
06:37:10  <peter1138> Malawar: The train is on both sides of the signal, therefore it's red.
06:37:38  <Malawar> yeah, I figured that out, but it didn't occur to me that another signal on the line would help :P
06:38:06  <peter1138> Hmm, if you figured that out then the second bit should be obvious.
06:43:01  <peter1138> http://217.151.109.167:8000 :D
06:44:18  <Celestar> what is that peter1138 ?
06:44:36  <peter1138> mercurial with your patch from last night applied
06:44:52  <peter1138> Although it looks totally different to hg.openttd.org :o
06:47:09  *** Gekz_ [~brendan@123-243-206-102.static.tpgi.com.au] has joined #openttd
06:48:49  *** Gekz [~brendan@123-243-206-102.static.tpgi.com.au] has quit [Ping timeout: 480 seconds]
06:54:18  <Celestar> peter1138: I see :D
07:13:05  *** Nev [bleepy@5ad456b0.bb.sky.com] has joined #openttd
07:15:23  <Celestar> peter1138: so, what do you want me to do? :P
07:15:51  *** mikl [~mikl@cpe.ge-0-2-0-812.0x50c774be.boanqu1.customer.tele.dk] has joined #openttd
07:16:26  <peter1138> Well... finish it? ;)
07:17:00  <Noldo> how very Mortal Kombat
07:19:09  *** GoneWacko [~foo@adsl-58.35.Static.ssp.fi] has joined #openttd
07:19:21  *** bleepy [bleepy@5ad00eb3.bb.sky.com] has quit [Ping timeout: 480 seconds]
07:20:21  <Celestar> peter1138: I'll try to implement a pathfinder today (=
07:20:37  <Celestar> peter1138: meh, I forgot to include the boost license with the diff :P
07:25:06  <blathijs> Celestar: What kind of pathfinder?
07:25:23  <blathijs> Celestar: On that goes through the order graph?
07:26:04  <Celestar> blathijs: yes
07:26:13  <Celestar> blathijs: to find paths for a packages
07:26:46  <blathijs> Celestar: You might be able to reuse the AyStar code that NPF uses?
07:27:16  <blathijs> Not sure what kind of route you are looking for? Shortest, or all routes?
07:27:45  <Celestar> blathijs: shortest for the time being
07:27:50  <Celestar> blathijs: boost has the pathfinders implemented
07:27:50  <blathijs> Celestar: You should be able to get away with writing just a handful of callbacks and have a working A* pathfinder
07:27:57  <Celestar> blathijs: you just need to call them
07:28:08  <blathijs> Ah, that is probably even easier then :-
07:28:10  <blathijs> )
07:28:25  <blathijs> bbl
07:28:38  *** dih [~dih@dslb-092-074-241-170.pools.arcor-ip.net] has joined #openttd
07:35:25  * peter1138 smacks Celestar!
07:35:40  <peter1138> I've been trying to use EdgeIterator... when it should actually be OutEdgeIterator
07:38:47  *** Doorslammer [Doorslamme@PIPP-p-144-134-197-144.prem.tmns.net.au] has joined #openttd
07:41:55  *** plakkertjes [~plakkertj@ip51cc357e.adsl-surfen.hetnet.nl] has joined #openttd
07:42:08  <Celestar> heh :P
07:43:49  *** TinoM [~Tino@i59F57342.versanet.de] has joined #openttd
07:44:21  *** mikl [~mikl@cpe.ge-0-2-0-812.0x50c774be.boanqu1.customer.tele.dk] has quit [Ping timeout: 480 seconds]
07:46:13  <Celestar> and peter1138 , I hope the doxygen stuff I wrote is any good. did you read it?
07:46:41  <peter1138> Uh... I saw it... does that count? ;)
07:46:54  *** Doorslammer|BRSet [Doorslamme@PIPP-p-203-54-115-94.prem.tmns.net.au] has joined #openttd
07:49:45  <Celestar> well :P
07:49:53  <Celestar> it depends on the question whether you want me to improve it or not
07:50:58  *** Doorslammer [Doorslamme@PIPP-p-144-134-197-144.prem.tmns.net.au] has quit [Ping timeout: 480 seconds]
07:54:21  *** dih [~dih@dslb-092-074-241-170.pools.arcor-ip.net] has quit [Ping timeout: 480 seconds]
08:05:58  <peter1138> Haha
08:06:17  <peter1138> This network map is quite a mess :D
08:06:47  <Celestar> peter1138: you mean like visually?
08:06:51  <peter1138> Yes.
08:06:58  <peter1138> I've got it on the minimap
08:07:03  <Celestar> show me show me show me
08:07:23  <Noldo> me too me too metoo
08:07:47  *** Vikthor [~Vikthor@snat1.spoje.net] has joined #openttd
08:08:29  <peter1138> http://svn.bucks.net/~petern/map.png
08:08:58  <Lachie> do you slave SATA drives?
08:09:03  <peter1138> No.
08:09:32  <Celestar> no Lachie
08:09:39  <Lachie> what dictates which HDD the boot record is on
08:09:47  <Celestar> peter1138: nice one :D maybe we should have a separate view
08:09:52  <Lachie> http://svn.bucks.net/~petern/map.png
08:10:04  <Celestar> Lachie: the boot record is part of a partion...
08:10:07  <peter1138> Celestar: Definitely. This was just a quickie :D
08:10:16  <Celestar> nice quickie. difficult?
08:10:23  <Celestar> apart from my typedef-messup? :S
08:10:36  <peter1138> Lachie: Nothing dictates it. The BIOS can in theory boot from any of them.
08:10:56  <peter1138> Celestar: reload that hg URL :)
08:11:05  <Celestar> Lachie: every partition can have a boot record. every disk DOES have an MBR
08:11:09  <Lachie> alright then
08:11:42  <peter1138> There is some redundancy there as there are multiple paths between to vertices.
08:11:51  <peter1138> It just redraws them currently.
08:12:27  *** Doorslammer|BRSet is now known as Doorslammer
08:12:43  <peter1138> I really want to see this on my YAPP network :D
08:12:47  * peter1138 ponders applying it.
08:13:56  <peter1138> Celestar: the intermediate SmallVector is unnecessary if some of the protected stuff is exposed.
08:18:39  <Celestar> peter1138: nice nice :D
08:18:53  *** elmex [~elmex@e180065203.adsl.alicedsl.de] has joined #openttd
08:22:21  <peter1138> I still haven't figured out how to export all this :o
08:22:25  <peter1138> HG EXPERT NEEDED
08:23:47  <Celestar> heh
08:23:54  <Celestar> the pathfinder did compile :D
08:24:33  <Celestar> peter1138: we have the option of storing the best paths for each station/vertex, and only recompute them on order system modification. That way we don't need to run the pathfinder every time a cargopacket is created.
08:24:53  <peter1138> Hmm
08:26:24  <Celestar> or store it for each shared order list
08:26:28  <Celestar> er .. no good :P
08:27:25  <peter1138> Hmm
08:27:37  <peter1138> Only conflict with YAPP is in debug...
08:28:31  <peter1138> Which is easy to solve :D
08:28:41  <peter1138> So I will get my route map, woo
08:29:16  <peter1138> hehe, still looks a mess :D
08:29:20  <peter1138> ah yes, all the AI...
08:30:25  <Celestar> HAH
08:30:35  <Celestar> we need a "remove_all_ais" console command :P
08:31:20  <peter1138> Nah, I'm just making it only show the local player's routes.
08:32:41  <Celestar>  \o/ The pathfinder does something
08:34:12  <peter1138> http://svn.bucks.net/~petern/map2.png
08:34:20  <peter1138> ^ bit better looking
08:34:46  <Celestar> you have some nice transfer network there in the middle haven't you?
08:34:49  <Celestar> trams or something
08:35:45  <peter1138> no trams, just trains and busses
08:35:55  <peter1138> plus a couple of long truck routes
08:47:20  *** Gekz [~brendan@123-243-206-102.static.tpgi.com.au] has joined #openttd
08:54:57  * Celestar laughs
08:56:32  <Gekz> omg. Opeth.
08:59:56  <Celestar> er?
09:03:37  <Celestar> peter1138: \o/
09:03:45  <Celestar> peter1138: http://pastebin.com/m54fa8d90 <= I'm nuts, am I not?
09:06:03  <blathijs> Looks cool :-)
09:07:40  <Noldo> if it works, we are happy
09:07:50  <Celestar> it does
09:07:58  <Celestar> TIC/TOC spits out time in microseconds right?
09:08:00  *** stillunknown [~stillunkn@82-136-225-75.ip.telfort.nl] has joined #openttd
09:08:27  <Gekz> Celestar: is this evidence it works?
09:08:42  <Celestar> Gekz: yes it is
09:08:47  <Gekz> Nice.
09:08:50  <Celestar> Gekz: it finds routes
09:08:55  <Gekz> so when will we see passenger destination in svn?
09:08:56  <Gekz> soon?
09:09:05  <Gekz> soon being a timeframe between now and next month.
09:09:24  <Celestar> I *guess* we'll see some commits in that timeframe, but likely not yet a fully working system
09:09:55  <Gekz> damn you people and demanding to do things right
09:09:56  <Gekz> :P
09:10:01  <Gekz> could be freeciv though
09:10:07  <Gekz> taking 15 years to get to 2.0
09:10:09  <Gekz> :D
09:10:18  <Celestar> hehe
09:10:26  <Celestar> ok everyone I need a *LARGE* savegame
09:10:29  <Celestar> from trunk
09:10:35  <Celestar> (I only have yapp stuff)
09:11:30  <Ammler> Celestar: coop archive
09:11:57  *** rortom [~rortom@p57B7FFBF.dip.t-dialin.net] has joined #openttd
09:12:04  <Ammler> only trunk stuff there :-)
09:12:31  <Celestar> Ammler: just browsing them
09:12:38  * peter1138 returns
09:13:33  <peter1138> Celestar, no, TIC/TOC spits out number of cycles.
09:13:40  <Celestar> peter1138: I see
09:13:46  <Celestar> how much is 180k then? :P
09:14:01  <peter1138> Depends how often it is ;)
09:14:12  <Celestar> each time I call the pathfinder (=
09:14:17  <Celestar> on a reasonably large game
09:14:54  <Celestar> (600 vehicles)
09:16:20  *** KillaloT [~killalot@0x5738cc83.ge-1-1-0-1100.alnqu1.ip.tele.dk] has joined #openttd
09:18:59  *** Yexo [~Yexo@32-88-ftth.onsneteindhoven.nl] has joined #openttd
09:19:57  <Celestar> peter1138: if this is CPU cycles, I need a tenth of a millisecond for finding ALL possible destinations from a source station on my box.
09:21:39  <peter1138> Well, it should be a lot simpler than map pathfinding.
09:22:18  <Celestar> it grows with O(n log n) afaik, which is about as good as it gets.
09:24:57  <Celestar> 0.1ms is not bad, assuming we cache/store the data somehow any only recompute on need
09:25:27  <Gekz> that's awesome
09:25:27  <Gekz> :D
09:30:58  *** [1]plakkertjes [~plakkertj@ip51cc357e.adsl-surfen.hetnet.nl] has joined #openttd
09:33:11  <peter1138> Hmm, deleting a route doesn't seem to actually update the graph.
09:33:24  <Gekz> lol.
09:33:47  <peter1138> In RemoveRoute it just breaks if removing?
09:34:44  <Celestar> peter1138: ?
09:34:54  <peter1138> DEBUG(routing, 4, "Found edge with index %d. Removing now", from->index);
09:34:56  <peter1138> break;
09:35:04  <peter1138> Doesn't... do anything.
09:35:10  <rortom> hi all
09:35:18  <Celestar> er ..
09:35:21  <rortom> peter1138: are you working IRL? :p
09:35:26  <rortom> or 100% ottd? ;)
09:35:44  <Celestar> I apparently have forgotten something :P
09:36:28  <Celestar> peter1138: You don't have my latest version apparently :P
09:37:00  *** plakkertjes [~plakkertj@ip51cc357e.adsl-surfen.hetnet.nl] has quit [Ping timeout: 480 seconds]
09:37:00  *** [1]plakkertjes is now known as plakkertjes
09:37:24  <Celestar> peter1138: I'll make a new diff for ye in a minute
09:38:03  <peter1138> rortom: I'm on holiday at the moment :D
09:38:10  <peter1138> Celestar... ahh :)
09:39:18  <Celestar> peter1138: http://www.fvfischer.de/routenetwork_pathfind.diff <= take this version for the time being
09:41:09  <Celestar> peter1138: you can play around with ComputeRoutes() as well
09:41:11  *** Yexo_ [~Yexo@dhcp-077-250-220-139.chello.nl] has joined #openttd
09:41:25  *** Yexo is now known as Guest80
09:41:26  *** Yexo_ is now known as Yexo
09:43:03  *** Yexo [~Yexo@dhcp-077-250-220-139.chello.nl] has quit [Read error: Connection reset by peer]
09:43:07  *** Yexo_ [~Yexo@dhcp-077-250-220-139.chello.nl] has joined #openttd
09:43:29  *** Yexo_ is now known as Yexo
09:46:50  <Celestar> can I pass a std::vector around by using a pointer?
09:47:11  <peter1138> Yes
09:47:16  <Celestar> cool
09:47:22  *** Guest80 [~Yexo@32-88-ftth.onsneteindhoven.nl] has quit [Ping timeout: 480 seconds]
09:47:31  <peter1138> You should, otherwise you end up copying its data around all the time.
09:48:57  <Celestar> so std::vector<int> shit; foo(&shit) or foo(shit); ?
09:49:35  <blathijs> Celestar: The latter will work if you make foo accept a reference
09:50:08  <Celestar> k
09:50:33  <blathijs> and the former if you make foo accept a pointer, of course
09:53:02  *** Dred_furst [~Dred_furs@user-514d7e3a.l2.c2.dsl.pol.co.uk] has joined #openttd
09:53:48  * peter1138 updates his hg
09:54:13  * Celestar slaps himself with the save-before-compile-trout
09:54:18  <peter1138> hehe
09:55:23  <peter1138> Hmm, still not removed :o
09:55:35  <Celestar> WTF?
09:56:14  <Celestar> there IS a remove_edge there now, is there?
09:56:20  *** Progman [~progman@p57A1F1D2.dip.t-dialin.net] has joined #openttd
09:56:31  <peter1138> Yes,
09:57:54  <peter1138> Hmmmmmm
09:57:59  <peter1138> I think it's first up.
09:58:08  <peter1138> I'm not actually removing orders
09:58:31  <peter1138> I'm adding orders, and hence a one path is split into two, but the original path is not being removed.
09:58:39  <peter1138> er, first up = higher up
10:00:19  *** Zahl [~Zahl@g227018138.adsl.alicedsl.de] has joined #openttd
10:01:12  <Celestar> peter1138: you should see the route being removed if things are split
10:01:12  *** Vikthor [~Vikthor@snat1.spoje.net] has quit [Remote host closed the connection]
10:01:17  <peter1138> Hmm
10:01:23  <Celestar> (-d routing=7 is maximum at th emoment)
10:02:02  <peter1138> Yes, I just thought to try that ;)
10:03:14  *** Sir-Bob [~chatzilla@c122-107-227-146.eburwd5.vic.optusnet.com.au] has joined #openttd
10:04:01  <peter1138> Okay, it says removing route, then i get a few lines of 'found edge with index 265. not removing'
10:05:17  <Celestar> not good
10:05:31  <Celestar> not good
10:05:41  <Celestar> the edge should be there
10:05:47  <Celestar> how big is that network?
10:06:02  <peter1138> fairly
10:06:11  <peter1138> however, i just tried it with a simple triangle
10:06:13  <peter1138> still happens
10:06:28  <peter1138> three hops
10:06:38  <peter1138> first set an order from 1 to 3
10:06:48  <peter1138> then add 2 between them in both directions
10:07:09  <peter1138> the route for 1 to 3 is definitely still there
10:07:35  <peter1138> hmm, if i remove the orders completely its still there :o
10:07:53  *** Mark [~M4rk@5351EE62.cable.casema.nl] has quit [Quit:  HydraIRC -> http://www.hydrairc.com <- Go on, try it!]
10:08:01  *** Roujin [~Roujin@p54973501.dip0.t-ipconnect.de] has joined #openttd
10:08:13  <peter1138> only disappears when the stations are removed
10:09:02  <Celestar> peter1138: weird
10:09:10  <Celestar> will you try or want me to give it a shot
10:09:30  <peter1138> Doing so now :)
10:10:07  <Celestar> :) I assume the code is readable then :P
10:10:42  <peter1138> It's okay as long as gcc doesn't spit out a type error with a dozen lines to templates ;)
10:10:57  <blathijs> hehe
10:12:17  <peter1138> Hmm
10:12:40  <Celestar> peter1138: yeah I now that problem
10:12:51  <Celestar> peter1138: record last week was something over 200 lines of templates
10:13:11  <Celestar> peter1138: I especially love things contaning "> > > > > > >" at some point :P
10:13:17  <Eddi|zuHause3> configure does not actually check for presence of boost yet?
10:13:21  <peter1138> :)
10:13:32  <peter1138> Eddi|zuHause3, no
10:13:52  <Celestar> Eddi|zuHause3: no, not yet
10:15:23  <Eddi|zuHause3> http://paste.openttd.org/37178 <- ??
10:15:24  <Celestar> peter1138: finding paths works nicely now
10:15:43  <Celestar> Eddi|zuHause3: yes. welcome to gcc 4.3 :S
10:15:56  <Celestar> Eddi|zuHause3: their own includes include their own deprecated headers
10:16:25  <Eddi|zuHause3> funny ;)
10:16:36  <Celestar> Eddi|zuHause3: I'll try to move to a new boost version at some point to solve the error. for now just use ./configure CFLAGS="-Wno-deprecated"
10:17:22  <peter1138> Celestar, by the way, I assume depot and waypoint orders are ignored?
10:17:31  <peter1138> Hmm, must be.
10:17:41  <blathijs> Celestar: You are using an older boost version currently then?
10:18:11  <peter1138> I'm using whatever ubuntu had...
10:19:26  <Celestar> blathijs: whatever ships with my distro
10:19:34  <Celestar> peter1138: yes, only station orders are used.
10:19:34  <Roujin> Eddi: have you seen the patch I posted at the thread about the yapf road vehicle addition?
10:20:02  <Celestar> peter1138: I'm NOT doing a semantic analysis of the conditional orders however.
10:20:12  <peter1138> Indeed not
10:20:17  <Celestar> dbg: [routing] The next hop going from <Grenbury Lakeside> to <Grenbury Branch> is via <Grenbury Valley>
10:20:25  <Celestar> \o/
10:20:42  <peter1138> :D
10:21:58  <Celestar> no cache yet
10:22:05  <Celestar> we can still implement that later I guess
10:23:51  *** mikl [~mikl@cpe.ge-0-2-0-812.0x50c774be.boanqu1.customer.tele.dk] has joined #openttd
10:24:41  *** Ammller [~Ammler@members.openttdcoop.org] has joined #openttd
10:24:55  *** Ammler [~Ammler@adsl-89-217-13-46.adslplus.ch] has quit [Quit: Konversation terminated!]
10:25:00  *** Osai [~Osai@members.openttdcoop.org] has joined #openttd
10:25:25  *** Ammller is now known as Ammler
10:25:39  *** SmatZ [~SmatZ@members.openttdcoop.org] has joined #openttd
10:26:00  *** XeryusTC [~XeryusTC@members.openttdcoop.org] has joined #openttd
10:26:39  *** dih [~dih@members.openttdcoop.org] has joined #openttd
10:27:00  *** planetmaker [~pm@members.openttdcoop.org] has joined #openttd
10:27:28  *** planetmaker is now known as pm|away
10:27:59  *** tneo [~tneo@members.openttdcoop.org] has joined #openttd
10:30:53  <Eddi|zuHause3> hm... why does debug output not appear in the ingame console?
10:32:47  <Eddi|zuHause3> dbg: [routing] Test passed. Adding route from MelbrÃŒck (213) to Chemnitz an der Donau (8). Index 788, Vehicle Type 0
10:32:53  <Eddi|zuHause3> \o/
10:33:34  * SpComb renames his station to "foo (1337) to bar"
10:33:56  <Celestar> Eddi|zuHause3: I'm not sure?
10:33:57  <SpComb> english language injection vulnerability
10:34:11  <peter1138> Eddi|zuHause3: developer 3
10:34:14  <peter1138> or developer ... something
10:34:56  <Celestar> peter1138: obtaining a route from a precomputed network is about 3-4 orders of magnitude faster (less than a microsecond here)
10:35:04  <peter1138> oh, 2 is enough
10:35:13  <Celestar> peter1138: I'm not going to fully optimize this stuff now, but we should bear that in mind for later
10:35:18  <peter1138> Celestar, so worth doing.
10:36:10  <Celestar> how many tiles are processed in the tile loop per frame?
10:36:21  <peter1138> Depends on the mapsize.
10:36:34  <Celestar> well mapsize/what?
10:36:39  <Celestar> was that 1280 ?
10:36:48  <peter1138> I think it's something like the whole map done once every 256 ticks. Possibly.
10:38:19  <peter1138> Hmm
10:38:36  <Celestar> BAH
10:38:40  <Celestar> RunTileLoop
10:38:43  <peter1138> Yeah
10:38:58  <peter1138> TILELOOP_SIZE is 16, square it you get 256.
10:39:07  <Celestar> yeah
10:39:07  <peter1138> So X * Y / 256 = number of tiles processed
10:39:29  <Celestar> so for a 1k x 1k map, we have 4096 tiles processed
10:39:37  <peter1138> A lot.
10:39:55  <Celestar> if 10% of these tiles are houses that generate mail and passengers, we have up to 820 cargopackets generated per tick
10:40:23  <peter1138> Yup.
10:40:40  <peter1138> Does pathfinding need to be done for each of those at the start?
10:40:46  <Celestar> nope.
10:41:00  <Celestar> only when there's a vehicle to board
10:41:05  <peter1138> Or do we pathfind when... yeah that
10:41:18  <Celestar> so we can unify the cargopackets first
10:41:23  <Celestar> (with same origin/destination)
10:41:28  <Celestar> and save us a lot of time
10:41:59  <peter1138> I believe packets are already unified there
10:42:13  <Celestar> but generally on a full 1k x 1k map, we can assume that we need about a million more cycles per tick
10:42:31  <Celestar> with about 30 fps, we need about 30 MHz more :P
10:42:42  <peter1138> :D
10:42:53  <Celestar> not counting the cache updates
10:42:53  <peter1138> Well it's always optional for those with slow computers.
10:43:08  *** Brianetta [~brian@client-86-27-108-163.brnt.adsl.virgin.net] has joined #openttd
10:43:54  <Celestar> without cache, we can safely assume that we need about a whole additional core :P
10:44:10  <peter1138> Well... I have four ;)
10:44:16  <peter1138> But alas!
10:44:35  <Celestar> well :)
10:44:54  <Celestar> we're not going to multithread the route network today, ok peter1138 ? (=
10:45:18  <Celestar> heh. I just tried three time to quit gdb with ":q"
10:46:03  *** Sir-Bob [~chatzilla@c122-107-227-146.eburwd5.vic.optusnet.com.au] has quit [Ping timeout: 480 seconds]
10:47:04  <Celestar> peter1138: http://www.fvfischer.de/routenetwork_pathfind.diff <= with "Find the next hope" feature
10:47:12  <Celestar> hop*
10:47:46  <Eddi|zuHause3> it could use a version number ;)
10:48:12  *** Wezz6400 [~Wezz6400@ndb.demon.nl] has joined #openttd
10:48:21  * Celestar slaps Eddi|zuHause3.0
10:48:39  <Eddi|zuHause3> :p
10:55:56  <Celestar> A vector can store a vector, right?
10:56:28  <Celestar> like std::vector<std::vector<int>> hopcash; ?
10:56:31  <Celestar> cache*
10:56:46  <ln> wtf³: http://www.debian.org/News/2008/20080726
10:57:03  <Celestar> heh
10:57:05  <Celestar> they did it?
10:57:21  <Noldo> etch and a half tails
10:58:34  <peter1138> cool
10:58:45  <Eddi|zuHause3> www.informatik.uni-halle.de/~krause/Ravenswald%20Transport,%202.%20Jan%201972.sav <- test game, if you want... about a half connected 2kx1k map (~250 trains) and a few trams. most trains with non-nonstop orders should have all their stations assigned
10:59:17  <peter1138> Hmm, right...
10:59:21  <peter1138> This route deleting...
10:59:24  <peter1138> Is all cryptic ;)
10:59:51  <Celestar> peter1138: if you're really really good. you get remove_edge_if() to work
10:59:52  <Celestar> :)
10:59:57  <Celestar> I've not yet managed to do so
11:00:01  <peter1138> Okay
11:01:40  <peter1138> That would avoid the need for the loop, right?
11:03:03  <Eddi|zuHause3> why remove_edge_if()? couldn't you just build a multiple-edges-graph?
11:03:20  <peter1138> Huh?
11:03:31  <Eddi|zuHause3> or am i misunderstanding stuff ;)
11:04:28  <Noldo> how does paxdest system influence station rating?
11:04:42  <peter1138> does it?
11:06:44  <rortom> peter1138: http://modclub.rigsofrods.com/thomas/test1.png
11:06:47  <rortom> http://modclub.rigsofrods.com/thomas/test2.png
11:06:57  <rortom> wanted to show you yesterday
11:07:28  <Gekz> rortom: whats that
11:07:30  <Roujin> rortom: are these displayed optionalß
11:07:30  <Roujin> ?
11:07:31  <Gekz> some kind of counter thing
11:07:46  <Roujin> the window is kinda big like this, it should be optional to display this data
11:07:54  <Celestar> peter1138: it would avoid the need for a loop and the if, because that's all inside the remove_edge_if
11:07:58  <Noldo> Roujin: check the other picture
11:08:03  <peter1138> Roujin, you have to click on the stats button...
11:08:28  <rortom> yup
11:08:40  <rortom> thats a feature patch im working on
11:08:51  <rortom> to improve the station gui
11:08:56  <Roujin> ah yes
11:08:58  <Gekz> nice.
11:09:02  <Gekz> make it less fat
11:09:22  <Gekz> cant the vehicles come up in a horizontal list first
11:09:28  <rortom> yes
11:09:31  <Gekz> like 1 Train - 9 road vehicles - 1 Aircraft
11:09:44  <rortom> yes, i wanted to do that as next
11:09:45  <Roujin> still also the small version is bigger than how it's now
11:09:56  <rortom> a bit
11:09:58  <Gekz> that too
11:09:59  <Gekz> random spacing
11:10:01  <Gekz> kill it
11:10:03  <Gekz> !!
11:10:05  <rortom> as i added the accept field
11:10:06  <Gekz> lol
11:10:09  <rortom> yes ;)
11:10:18  <Gekz> otherwise
11:10:20  <Gekz> looks promising
11:10:20  <rortom> its coded in some hours and is far from perfect :)
11:10:23  <Gekz> make it mergable :P
11:10:29  <Gekz> or i'll smack you
11:10:34  <rortom> urgs :|
11:10:41  <rortom> you will have to smack me :|
11:10:44  <rortom> :p
11:10:47  <SmatZ> smack smack
11:11:01  <Gekz> otherwise
11:11:05  <Gekz> your work will be pointless
11:11:11  <Gekz> clean code is good code
11:11:11  <rortom> mh, what stats could be interesting also?
11:11:13  <rortom> yes
11:11:31  <rortom> but getting things into trunk is like praying for god for a wonder ;)
11:11:32  <Gekz> you could possibly make the stats box have buttons
11:11:48  <rortom> for what purpose?
11:11:50  <Gekz> such as transferred this year, passed this year
11:11:53  <Gekz> so its not so fat
11:11:56  <Gekz> displaying one part at a time
11:12:03  <rortom> good idea
11:12:06  <Gekz> or make the waiting: part dynamic if possible
11:12:11  <Gekz> so if there's only one line, shrink it to one line
11:12:13  <Gekz> and if its two, etc
11:12:25  <rortom> thats what i also thought of
11:12:28  <Gekz> but
11:12:28  <Roujin> [13:10] <rortom> but getting things into trunk is like praying for god for a wonder ;) <-- not really
11:12:32  <Gekz> make it so it can only get bigger
11:12:34  <Gekz> not smaller
11:12:40  <Roujin> it's hard yes. but not impossible
11:12:41  <Gekz> because if its fluctuating between 3 and 4 things
11:12:45  <Gekz> you dont want it flickering
11:12:49  <Gekz> you want it to stay at size 4
11:13:05  <rortom> i will find a way ;)
11:13:14  <rortom> mhm what stats could be done as well?
11:13:23  <rortom> how long goods waited or such?
11:13:24  <Roujin> that "supplies:" string in the station building window, that was done by me :P
11:13:38  <rortom> well done :D
11:13:42  <Roujin> so you see, it is possible to get something into trunk
11:14:04  <Roujin> just keep the code clean, and don't do too much at a time.
11:14:12  <peter1138> Celestar, argh! A mass of template errors!
11:14:24  <rortom> yes
11:14:44  *** Forked [kjs@termstua.com] has joined #openttd
11:14:50  <Forked> yapp is really something :)
11:15:50  <rortom> someone knows the m&b screensaver?
11:15:54  <rortom> m&m
11:16:19  <rortom> http://www.mm-eisenbahn.de/index_e.htm
11:16:34  <rortom> could work well with TTD's grf :)
11:17:43  <Gekz> omfdg
11:17:47  <Gekz> there is no OpenTTD screensave
11:17:49  <Gekz> r
11:17:52  <Gekz> that would be awesome :D
11:18:04  <Celestar> peter1138: yeah :S
11:18:12  <Eddi|zuHause3> there have been at least two patches to make ottd a screensaver
11:18:14  <rortom> Gekz: there is a screensaver
11:18:17  <Celestar> peter1138: on the other hand, the cache is mostly written
11:18:30  <Ammler> Eddi|zuHause3: something linuxish?
11:18:36  <Gekz> I see.
11:18:53  <Eddi|zuHause3> i think they were aimed at windows...
11:23:35  <peter1138> Argh, it's too hot outside.
11:27:09  <peter1138> http://paste.openttd.org/37217
11:27:58  <Eddi|zuHause3> that's only 6 >s ;)
11:39:17  <Celestar> peter1138: yeah. I'm really curious WHAT qualifiers are discarded :S
11:43:16  <peter1138> const, usually
11:43:51  <Celestar> peter1138: yeah :S
11:43:56  <Eddi|zuHause3> the route gui should probably have a filter for cargo type :p
11:44:08  <Celestar> Eddi|zuHause3: the route network doesn't know about cargo types
11:44:09  <Celestar> (yet)
11:44:43  <Celestar> not even sure that is needed
11:45:09  <Celestar> with a properly set up network
11:45:10  <peter1138> Well if you want more than passenger destinations then it is.
11:45:45  <Celestar> peter1138: will be hellish, unless we make a really indepedent graph for each cargo type (which is not really much of a problem)
11:45:56  <Eddi|zuHause3> of course i would not want my steel to try to board a passenger train that happens to cross the station
11:46:08  <Celestar> like Routing *Routing[CT_MAX];
11:46:20  <peter1138> Hmm, 32 routing tables? hh
11:46:23  <Celestar> peter1138: I don't think it should be inside the graph
11:46:39  <Eddi|zuHause3> yes, separate graphs seem reasonable
11:46:55  *** Roest [~ralph@p54B9D5DC.dip.t-dialin.net] has joined #openttd
11:47:07  <Eddi|zuHause3> you'll have vehicles that take part in multiple graphs, though
11:47:18  <Eddi|zuHause3> like mixed grain and cattle trains
11:47:22  <blathijs> Celestar: Why not putting it inside a single graph?
11:47:24  <Celestar> Eddi|zuHause3: vehicles don't take part in graphs at all. Orders do
11:47:27  <Eddi|zuHause3> or passenger and mail trains
11:47:34  <Roest> hi
11:47:37  <blathijs> Just ignore the edges for other cargo types when traversing
11:47:57  <Celestar> blathijs: it will slow down pathfinding, because the pathfinder will have to read out the "cargotype" property for every single edge it traverses
11:48:00  <blathijs> By using a mask for cargo types, you can probably save a lot of memory for multiple cargotype trains
11:48:36  <Celestar> blathijs: remember that space is not an issue, speed is.
11:48:41  <Eddi|zuHause3> as i said previously, i'd worry for speed more than memory
11:48:41  <peter1138> Dependds how important saving memory is over speed.
11:48:50  <blathijs> Yeah, that is true. If you will always look at just a single cargo type, multiple graphs vs single graph is only a memory vs speed tradeoff
11:49:05  <Celestar> peter1138: The graph takes O(Stations + Routes) elements.
11:49:15  <Celestar> even with 1000 stations and 4000 routes, thats 5000 elements
11:49:34  <Celestar> with like 20 bytes per element, we have 100k
11:49:34  *** planetmaker [~chatzilla@devera.geophys.nat.tu-bs.de] has joined #openttd
11:49:50  <peter1138> So by splitting them you 'waste' 1000 elements on stations each time
11:50:08  <peter1138> Seems reasonable.
11:50:12  <Celestar> peter1138: yes, but the station elements are much smaller than the routes elements, since they don't not have properties
11:50:36  <peter1138> What you want is a graph that can reuse the station elements ;)
11:51:04  <blathijs> ie, have a single list of vertices, but only duplicate the adjacency lists
11:51:12  <Eddi|zuHause3> chances are, for each separate cargo network, only a small fraction of the stations are actually used
11:51:18  <Celestar> blathijs: go rewrite the boost graph library :)
11:51:33  <peter1138> Celestar, well, we may end up doing that yet ;)
11:51:42  <blathijs> Celestar: This is what I meant when I said "are you sure you want to use boost?" :-p
11:51:45  <Celestar> peter1138: possibly (=
11:51:55  <Celestar> blathijs: unless you come up with a better system, yes (=
11:52:17  <Celestar> I still vote for first getting this to work with passengers.
11:52:24  <peter1138> Certainly.
11:52:31  *** planetmaker [~chatzilla@devera.geophys.nat.tu-bs.de] has quit []
11:52:38  *** pm|away is now known as planetmaker
11:52:40  <Celestar> extended the thing via multiple graphs is really really really straightforward
11:52:51  <Celestar> adding the cargotype as edge property is even more straightforward
11:53:09  <blathijs> I just designed a better system for you! Splitting vertex lists and adjacency lists would be the most optimal solution (even close to optimal memory-wise when most trains only have a single cargo type) :-p
11:53:09  <Celestar> (except for an additional check-function for the dijkstra)
11:53:37  <blathijs> But yeah, getting something working first, using boost, really sounds like the best way to go
11:53:40  <peter1138> Well... vertex list == station pool ;)
11:53:51  <blathijs> peter1138: even better!
11:54:43  <blathijs> With a graph list from scratch, we wouldn't be arguing about this crap right now, but Celestar would still be fiddling around with design :-)
11:54:49  <Celestar> peter1138: I _might_ have an idea about the remove_edge_if
11:55:06  <peter1138> Celestar, I've copied an example... and it doesn't work D:
11:55:22  <peter1138> But what's your idea?
11:55:23  <Celestar> peter1138: which one .. the one with the "TruePredicate()" ? (=
11:55:36  <Celestar> peter1138: I'm just checking it.sec
11:55:38  <peter1138> name_equals_predicate
12:00:01  <Celestar> peter1138: me failed. What's your example you have?
12:00:09  <peter1138> http://www.boost.org/doc/libs/1_35_0/libs/graph/example/modify_graph.cpp
12:01:36  <Celestar> peter1138: have you tried compiling it?
12:02:03  <Eddi|zuHause3> www.informatik.uni-halle.de/~krause/Ravenswald%20Transport,%2011.%20Jan%201972.png <- the existing version with the stations as squares looks cleaner, i think
12:02:18  <Eddi|zuHause3> the nodes are more visible that way
12:10:46  <Eddi|zuHause3> www.informatik.uni-halle.de/~krause/Klein%20Elsmuenster%20Transport,%202.%20Okt%201940.png <- comparison [different network]
12:13:07  <peter1138> Mine was just a quick and dirty hack, you know :p
12:13:19  <Eddi|zuHause3> yeah, sure ;)
12:13:22  <Celestar> one that took like 25 lines of code (=
12:13:31  <Celestar> peter1138: so is the edge removed or not?!
12:13:36  *** Yexo_ [~Yexo@32-88-ftth.onsneteindhoven.nl] has joined #openttd
12:13:40  *** Yexo is now known as Guest92
12:13:40  *** Yexo_ is now known as Yexo
12:14:28  <peter1138> no... doesn't compile yet :p
12:15:31  <Celestar> I mean with remove_edge and the loop
12:15:47  <peter1138> oh
12:15:47  <peter1138> no
12:15:52  <peter1138> sometimes it does
12:15:56  <peter1138> but not always
12:16:55  <Celestar> huh?
12:17:50  *** thgergo [~thgergo@members.openttdcoop.org] has joined #openttd
12:17:53  <peter1138> Quite.
12:18:23  *** glx [glx@bny93-6-82-245-156-124.fbx.proxad.net] has joined #openttd
12:18:23  *** mode/#openttd [+v glx] by ChanServ
12:19:41  <Celestar> man how do I NOTICE that an edge is actually removed from the graph or not :S
12:20:11  <peter1138> Did you apply my minimap patch?
12:20:30  <Celestar> no I didn't. There must be some way inthe debugger :P
12:20:42  <Celestar> SOME way
12:20:48  *** Guest92 [~Yexo@dhcp-077-250-220-139.chello.nl] has quit [Ping timeout: 480 seconds]
12:21:42  *** Wezz6400 [~Wezz6400@ndb.demon.nl] has quit [Ping timeout: 480 seconds]
12:22:26  *** Yexo_ [~Yexo@dhcp-077-250-220-139.chello.nl] has joined #openttd
12:22:28  *** Yexo is now known as Guest93
12:22:28  *** Yexo_ is now known as Yexo
12:24:10  *** Yexo_ [~Yexo@dhcp-077-250-220-139.chello.nl] has joined #openttd
12:24:21  *** Yexo [~Yexo@dhcp-077-250-220-139.chello.nl] has quit [Read error: Connection reset by peer]
12:25:59  *** Yexo [~Yexo@dhcp-077-250-220-139.chello.nl] has joined #openttd
12:25:59  *** Yexo_ [~Yexo@dhcp-077-250-220-139.chello.nl] has quit [Read error: Connection reset by peer]
12:25:59  *** DJNekkid [~chatzilla@static217-26.adsl.no] has quit [Read error: Connection reset by peer]
12:26:02  *** DJNekkid_ [~chatzilla@static217-26.adsl.no] has joined #openttd
12:26:05  *** DJNekkid_ is now known as DJNekkid
12:26:21  *** Yexo_ [~Yexo@32-88-ftth.onsneteindhoven.nl] has joined #openttd
12:27:06  *** Guest93 [~Yexo@32-88-ftth.onsneteindhoven.nl] has quit [Remote host closed the connection]
12:27:46  *** rortom [~rortom@p57B7FFBF.dip.t-dialin.net] has quit []
12:33:29  <Celestar> FUCK
12:34:00  *** Yexo [~Yexo@dhcp-077-250-220-139.chello.nl] has quit [Ping timeout: 480 seconds]
12:34:15  <blathijs> Hm?
12:34:15  <Lachie> Celestar: may I?
12:34:26  <blathijs> :-)
12:35:47  <Celestar> peter1138: error found
12:35:51  <Celestar> peter1138: updating
12:38:04  <Celestar> peter1138: http://www.fvfischer.de/routenetwork_pathfind.diff <= should be working
12:40:00  <Celestar> how does one download a diff from mercurial?!
12:41:52  <Eddi|zuHause3> click on "raw" on the top of the page
12:41:52  *** Gekz [~brendan@123-243-206-102.static.tpgi.com.au] has quit [Read error: Connection reset by peer]
12:42:34  * peter1138 tests the relevant change
12:42:46  <Celestar> peter1138: two changes (=
12:43:09  <Celestar> GNAH
12:43:28  <peter1138> Works perfectly :D
12:43:42  <peter1138> Eddi|zuHause3, and I've updated the map with black edges ;)
12:44:00  <Celestar> peter1138: it does? :D
12:44:01  <Celestar> WOOOO
12:44:08  <Celestar> mesa good (=
12:44:26  <peter1138> The triangle test works, anyway ;)
12:45:32  <Celestar> peter1138: good :P
12:45:34  *** welshdragon [~welshxcha@host86-130-180-82.range86-130.btcentralplus.com] has joined #openttd
12:45:34  *** Wezz6400 [~Wezz6400@ndb.demon.nl] has joined #openttd
12:46:00  *** Yexo_ [~Yexo@32-88-ftth.onsneteindhoven.nl] has quit [Ping timeout: 480 seconds]
12:46:05  *** welshdragon [~welshxcha@host86-130-180-82.range86-130.btcentralplus.com] has quit [Read error: Connection reset by peer]
12:46:08  <peter1138> Hmm, I got it confused by changing order types but I didn't apply all the patch.
12:46:24  *** welshdragon [~welshxcha@host86-130-180-82.range86-130.btcentralplus.com] has joined #openttd
12:48:13  <Celestar> peter1138: order types?
12:48:19  <Celestar> peter1138: what order types?
12:48:54  *** GoneWacko [~foo@adsl-58.35.Static.ssp.fi] has quit []
12:48:58  <peter1138> no load/no unload
12:49:06  <peter1138> but the rest of your patch has stuff relating to that
12:53:23  <peter1138> Yes, looks like it's fixed now.
12:53:34  *** Noetloj [~105Adam@5ad2f51e.bb.sky.com] has joined #openttd
12:53:54  <Celestar> heh :D
12:54:19  <Celestar> noload/nounload/transfer shouldn't be used with destinations anyway imho
12:54:22  <peter1138> Hmmmm
12:54:32  *** Vikthor [~Vikthor@snat1.spoje.net] has joined #openttd
12:54:35  <peter1138> yeah
12:54:40  <peter1138> it's possible to get it confused
12:54:49  <Celestar> how ?
12:54:50  <peter1138> when switching from no load to no unload
12:55:16  <Celestar> directly?
12:55:39  <Eddi|zuHause3> i really think those should both be allowed simultaneously...
12:55:52  <Celestar> it's the same as "go via"
12:56:10  <Eddi|zuHause3> no, it still stops
12:56:16  <Celestar> but does nothing?
12:56:22  <Eddi|zuHause3> exactly...
12:56:36  <Celestar> the purpose being?
12:56:36  <Eddi|zuHause3> but it can turn around or wait for timetables
12:57:12  <Celestar> peter1138: I might have messed things up in the flags (routing.cpp:338 and such)
12:59:15  <peter1138> yeah
12:59:18  <peter1138> if you have no load on
12:59:24  <peter1138> then switch to no unloading
12:59:42  <peter1138> it doesn't see that it can now load
13:00:24  <peter1138> if you then toggle no load on and off it goes back to how it should be
13:00:56  <Celestar> newload = (OrderLoadFlags)(newload & ~OLFB_NO_LOAD);
13:01:00  <Celestar> this should do that, right?
13:05:24  <peter1138> WHere?
13:06:00  <Celestar> 365
13:06:44  <Celestar> FUQQ
13:06:47  <Celestar> it's the wrong operator
13:07:08  <Celestar> it should be ==s instead of !=s in the expression
13:07:26  <Celestar> peter1138: change the two operators, and try again please
13:07:37  <peter1138> Doing so.
13:10:20  <peter1138> That seems better.
13:10:51  <Celestar> awesome
13:11:00  *** jordi [~jordi@115.Red-213-96-69.staticIP.rima-tde.net] has quit [Read error: Connection reset by peer]
13:11:12  <Celestar> hm ...
13:12:38  <Celestar> peter1138: I really really hope we can live without storing the RouteNetwork in the savegame. That'd save us a LOT of hassle
13:13:03  <peter1138> Well as long as these little niggles are sorted out it should be possible.
13:13:06  <planetmaker> Celestar: how would a joining client then know about the current state?
13:13:12  <peter1138> The routing information is all there anyway.
13:13:25  <peter1138> Technically you could just rebuild from scratch every time it is changed...
13:14:28  <Celestar> planetmaker: all the information we have is, as peter1138 sais, already in the order list.
13:14:32  <Eddi|zuHause3> planetmaker: in the worst case, the cache is cleared and rebuilt on client join [like with yapf]
13:14:45  <Celestar> planetmaker: the whole routenetwork does nothing else then reinterpreting the order data
13:14:49  <peter1138> Eddi|zuHause3: That never happened.
13:14:55  <planetmaker> ok, thx. Sorry, if it was a stupid question :)
13:15:12  <Eddi|zuHause3> peter1138: ?
13:15:26  <peter1138> There was never any invalidate-on-client-join system.
13:15:32  <peter1138> http://svn.bucks.net/~petern/map3.png
13:15:44  *** Belugas_Gone is now known as Belugas
13:15:57  <dih> hello Belugas
13:16:14  *** jordi [~jordi@115.Red-213-96-69.staticIP.rima-tde.net] has joined #openttd
13:16:34  <Celestar> planetmaker: there are no stupid questions (=
13:16:50  <planetmaker> :) That's a dangerous statement, Celestar :P
13:17:13  <peter1138> Right, all my changes from Celestar are in hg, along with that improved display.
13:17:31  <planetmaker> peter1138: that map looks interesting :). what does square size indicate?
13:17:33  <Eddi|zuHause3> peter1138: are you sure? i thought i have read a commit like that
13:17:52  <peter1138> planetmaker, number of passengers waiting.
13:17:56  <Celestar> peter1138: can I check out your stuff somehow?
13:18:06  <peter1138> planetmaker, almost exactly the same as that other paxdest patch.
13:18:09  <planetmaker> ah, ok. wouldn't passenger throughput a better indicator?
13:18:20  <peter1138> Throughput is not an available statistic.
13:18:30  <planetmaker> :) I know :P
13:18:34  <Celestar> peter1138: I still have a passenger and train throughput patch
13:18:45  <Celestar> peter1138: it's agaist revision 25 or something :P
13:19:04  <peter1138> Celestar: I think you can clone it with hg clone hg://restofurl
13:19:06  <Celestar> with a nice GUI that lists the number of in, out and transfer items
13:19:11  <peter1138> But I don't know. It may be too large :)
13:19:11  <Celestar> peter1138: will try
13:19:41  <peter1138> Or I can move my repository to a server on a fast connection.
13:19:42  <Celestar> peter1138: what package is "hg" part of?
13:19:47  <peter1138> mercurial
13:21:08  *** welshdragon [~welshxcha@host86-130-180-82.range86-130.btcentralplus.com] has quit [Quit: Leaving]
13:21:27  *** welshdragon [~welshxcha@host86-130-180-82.range86-130.btcentralplus.com] has joined #openttd
13:22:48  *** venus214 [~guesswho@p5B205A0E.dip.t-dialin.net] has joined #openttd
13:23:39  *** jordi [~jordi@115.Red-213-96-69.staticIP.rima-tde.net] has quit [Read error: Connection reset by peer]
13:24:10  *** jordi [~jordi@115.Red-213-96-69.staticIP.rima-tde.net] has joined #openttd
13:24:46  <peter1138> hmm, looks like buoys appear in the routemap
13:27:04  <Celestar> peter1138: well, yes
13:27:08  <Celestar> peter1138: somehow forgot them
13:27:16  *** tokai [~tokai@p54B84082.dip0.t-ipconnect.de] has quit [Ping timeout: 480 seconds]
13:27:24  <peter1138> :)
13:28:41  <venus214> hi.. any news about the diagonal level thing?
13:28:48  *** tokai [~tokai@p54B8029A.dip0.t-ipconnect.de] has joined #openttd
13:28:49  *** mode/#openttd [+v tokai] by ChanServ
13:30:08  <Ammler> venus214: did you play with 0.6 ?
13:30:37  <venus214> yes
13:30:55  <Ammler> well, then you might think about something else :-)
13:31:00  <Celestar> Ammler: he ment something else (=
13:31:36  <Ammler> ah, the patch from roujin?
13:32:09  <Celestar> peter1138: downloading
13:32:28  <venus214> im talking about this --> http://www.tt-forums.net/viewtopic.php?t=19311
13:37:37  <CIA-5> OpenTTD: truebrain * r13856 /branches/noai/src/ai/api/ (ai_controller.cpp ai_object.cpp ai_object.hpp): [NoAI] -Add: protect against DoCommands in constructor / Save / Load. Returns 'false', and issues warning.
13:39:54  <Celestar> peter1138: http://www.fvfischer.de/routenetwork_pathfind.diff <= removed buoy adding
13:43:18  * peter1138 tests
13:44:15  <peter1138> :D
13:45:38  *** jordi [~jordi@115.Red-213-96-69.staticIP.rima-tde.net] has quit [Read error: Connection reset by peer]
13:46:23  *** jordi [~jordi@115.Red-213-96-69.staticIP.rima-tde.net] has joined #openttd
13:47:31  <Noetloj> Hey guys. Can anyone explain this? http://easytohide.info/imagehost/images/p0htnixyt5h29kobur7p.png
13:47:48  <Noetloj> building a oil refinery in sub-tropic, it errors with must be built ABOVE the >SNOW< line
13:47:48  <Belugas> hello all
13:47:51  <Noetloj> ...in sub-tropic?
13:47:54  <Noetloj> ...snow?
13:47:57  * Noetloj is confuzzled.
13:48:03  <Noldo> nice
13:48:21  <Celestar> should possibly read "cannot be built in desert"
13:48:42  <Noetloj> hmm.
13:48:47  <Noetloj> Still a bug then :p
13:48:54  <peter1138> :D
13:49:16  <Noetloj> and Celestar: you're right.
13:49:18  <Celestar> peter1138: is that better? (with the buoys)
13:49:26  <Noetloj> I built it so that one tile is on the tropic ground.
13:49:28  <Noetloj> it worked then
13:49:35  <Noetloj> so it's a textual error for you guys to work out :p
13:50:27  <peter1138> Yes
13:51:44  <Celestar> peter1138: coll
13:51:46  <Celestar> cool*
13:52:01  <Celestar> peter1138: I gotta go in about 10 minutes. What should be our next steps?
13:52:15  <peter1138> http://svn.bucks.net/~petern/map4.png < useful?
13:52:25  <peter1138> coloured lines instead of just white...
13:52:37  <Celestar> colored by?
13:52:41  <peter1138> company
13:53:12  <Celestar> I was wondering: display only for your company, and color by vehicle type?
13:53:33  <peter1138> That's double, but what if a route is served by more than one type?
13:53:47  <Progman> coloring by company is imo useless unless you used sth. like the shared infrastructure patch
13:53:59  <Celestar> peter1138: good question. parallel lines?
13:54:04  <peter1138> Hmm, actually I can handle that in ListAdjacancies.
13:54:48  <peter1138> Progman, probably
13:55:32  <Eddi|zuHause3> the colouring could depend on the selected map view :)
13:55:44  <Celestar> peter1138: will wondering what the next steps should be
13:55:56  <peter1138> Pathfinding works, doesn't it?
13:56:01  <Celestar> peter1138: yes
13:56:10  <Celestar> peter1138: use FindNextHop
13:56:32  <Celestar> StationID Routing_t::FindNextHop(StationID from, StationID to);
13:56:45  <Celestar> I haven't tested it too extensively yet
13:56:48  <peter1138> Then we need to add destinations (perhaps randomly for testing)
13:56:51  <Eddi|zuHause3> if building and traversing the network works now, i'd say implement a (stupid) assignment of destinations for cargo
13:56:55  *** jordi [~jordi@115.Red-213-96-69.staticIP.rima-tde.net] has quit [Read error: Connection reset by peer]
13:56:55  <peter1138> and then code the transfers
13:57:04  <peter1138> Eddi|zuHause3, ding :D
13:57:04  <Celestar> (-d routing=7 is helpful possibly)
13:57:13  <Celestar> peter1138: randomly sounds great
13:57:27  *** bleepy [bleepy@5ad00e8d.bb.sky.com] has joined #openttd
13:57:51  <Celestar> peter1138: the transfers will mostly reuse existing unloading code and Routing->StayOnBoard
13:58:04  <Celestar> bool Routing_t::StayOnBoard(const Vehicle *v, StationID to);
13:58:57  <Celestar> StayOnBoard basically replaces the whole transfer/unloading stuff.
13:59:26  <Celestar> when people get off, unload if (ultimate destination == current destinations), else transfer
14:00:15  <peter1138> *nod*
14:00:23  <Progman> cargo doesn't get unloaded on buoyes, do they? there was such a bug in other paxdest patches ;)
14:00:31  <Celestar> so we can use the entire codebase, just don't read the order flags, but ask Routing->Something.
14:00:34  <peter1138> Progman, we've covered that one ;)
14:00:36  <Celestar> Progman: we've already prevented that (=
14:00:40  *** Gekz [~brendan@123-243-206-102.static.tpgi.com.au] has joined #openttd
14:00:48  <Celestar> thanks to peter1138
14:00:53  <venus214> hmm, isnt there an easier way to lower the land if you want to go through a mountain than clicking on every single square with the lower land tool?
14:01:18  <Progman> venus214: the square tool
14:01:43  <Progman> venus214: it is placed on the e-key (if you have the leveling toolbar open)
14:01:50  <Celestar> peter1138: we first need a StationID to; member of the cargopackets apparently
14:02:10  <peter1138> http://svn.bucks.net/~petern/map5.png < current player only, then
14:02:14  <Progman> venus214: http://wiki.openttd.org/index.php/Landscaping#What_do_all_those_buttons_do.3F
14:02:25  <peter1138> Celestar: yeah, that's easy
14:02:37  *** Gekz_ [~brendan@123-243-206-102.static.tpgi.com.au] has quit [Ping timeout: 480 seconds]
14:03:03  <venus214> Progman: but that isnt working if you want to do it diagonally or horizontally..
14:03:10  *** Nev [bleepy@5ad456b0.bb.sky.com] has quit [Ping timeout: 480 seconds]
14:03:15  <peter1138> Celestar: In theory that's our only savegame change :D
14:03:16  <Progman> no, it doesn't
14:03:49  * peter1138 adds StationID target;
14:03:58  <peter1138> shorter than destination, longer than to.
14:04:09  <Celestar> peter1138: well, there'll be some other, minor things
14:04:23  <Celestar> peter1138: maybe for gui/statistics
14:04:27  <venus214> are you planing ti implement this feature in the future? :)
14:04:41  <Celestar> venus214: no, rather we're trying to implement it presently (=
14:04:41  *** Roujin [~Roujin@p54973501.dip0.t-ipconnect.de] has quit [Quit:  Want to be different? Try HydraIRC -> http://www.hydrairc.com <-]
14:04:55  <peter1138> I think venus214 is talking about diagonal terraforming.
14:05:00  <Celestar> er ok
14:05:03  <Celestar> YES! I need it! :P
14:05:04  *** jordi [~jordi@115.Red-213-96-69.staticIP.rima-tde.net] has joined #openttd
14:05:22  <venus214> i need it too, so please implement it :)
14:05:56  <Eddi|zuHause3> well, there might be necessity to store stuff when you want to weight certain edges by timetable, expected capacity, and expected time of arrival
14:06:05  *** grumbel [~grumbel@i577AEE52.versanet.de] has joined #openttd
14:06:39  <CIA-5> OpenTTD: truebrain * r13857 /branches/noai/src/settings.cpp: [NoAI] -Fix: reduce the default number of opcodes per suspend, as the AIs for the tournament took for ever to run ;)
14:07:44  <Eddi|zuHause3> so when the long distance train arrives only very rarely, they do not all wait for it (and then cannot board it because it's full), but instead take the local train
14:07:56  <Celestar> Eddi|zuHause3: much Much MUCH later
14:08:05  <Celestar> I've gotta go
14:08:09  <Celestar> cu tomorrow
14:08:11  <Eddi|zuHause3> yes ;)
14:08:17  <Celestar> peter1138: have fun
14:08:46  <peter1138> Bye
14:10:14  <peter1138> Eddi|zuHause3, yeah, that basically boils down to 'passengers should prefer not to change'
14:10:35  <Eddi|zuHause3> peter1138: not entirely
14:11:34  <Eddi|zuHause3> if they can get to the destination much faster by transferring inbetween, they should do that
14:12:03  <Belugas> but but but... it's not realistic!
14:12:10  <Belugas> i like it then :D
14:12:23  <peter1138> Eddi|zuHause3, the pathfinding supports costs and penalties...
14:12:23  <Eddi|zuHause3> but i think that can be sufficiently handled by considering timetables
14:12:50  <Eddi|zuHause3> you can calculate an ETA from the timetable
14:13:40  <Eddi|zuHause3> yes, i kinda expected that :p
14:14:08  <blathijs> That does mean that the cost of long distance train should decrease depending on it's ETA
14:14:32  <blathijs> Which I'm afraid is quite some work (in terms of processing power)
14:14:55  <Eddi|zuHause3> the ETA for each order entry can be cached in the timetable, i believe
14:15:48  <blathijs> Yeah, that's probably true
14:15:50  <Eddi|zuHause3> if you do not consider delays, this should only be updated once per visit of the station
14:15:58  <Eddi|zuHause3> ETA = ETA+round trip time
14:16:03  <blathijs> Which is quite acceptable
14:16:47  <Eddi|zuHause3> then for deciding the weight of a connection, you have to loop the vehicles assigned to the order list, and check for the lowest ETA
14:16:56  *** Roest [~ralph@p54B9D5DC.dip.t-dialin.net] has quit [Remote host closed the connection]
14:17:20  <Progman> < Eddi|zuHause3> ETA = ETA+round trip time
14:17:29  <Progman> sounds like reimplement TCP in openttd ;)
14:18:33  <Rubidium> it's more UDP
14:18:47  <Rubidium> there's no retransmission of passengers
14:18:51  <blathijs> Rubidium: Since trains can get lost at any time? :-)
14:18:55  <blathijs> hehe
14:19:23  <blathijs> Eddi|zuHause3: That can be done more efficient, since when you consider an edge in pathfinding, you can just use the ETA as an extra cost I think.
14:19:31  <Eddi|zuHause3> wait... they don't respawn when they were in a crash?
14:20:15  <Eddi|zuHause3> blathijs: an edge is from an order, multiple vehicles can share the same order
14:20:27  <Eddi|zuHause3> so each vehicle has a different ETA
14:20:42  <blathijs> Oh, right
14:20:48  <blathijs> Hmm
14:21:08  <blathijs> I would say that when multiple vehicles share an order, there should be an edge for every vehicle
14:21:38  *** jordi [~jordi@115.Red-213-96-69.staticIP.rima-tde.net] has quit [Read error: Connection reset by peer]
14:21:40  <Eddi|zuHause3> you'll have to discuss that with celestar ;)
14:22:05  *** jordi [~jordi@115.Red-213-96-69.staticIP.rima-tde.net] has joined #openttd
14:22:49  * blathijs pokes Celestar for a bit
14:29:30  <peter1138> Hmm
14:29:36  <peter1138> That would involve more edges.
14:30:37  <Eddi|zuHause3> peter1138: you need to have support for parallel edges anyway, do a few more parallel edges really change anything?
14:31:23  <peter1138> Well, yes.
14:33:33  <Eddi|zuHause3> well... i'll keep out of that discussion ;)
14:34:10  <peter1138> Say you have 20 trains on a shared order
14:34:22  <peter1138> You'll have 20 times more adjacancies
14:35:00  <Eddi|zuHause3> that might indeed not be the most optimal solution ;)
14:35:08  *** DJNekkid [~chatzilla@static217-26.adsl.no] has quit [Ping timeout: 480 seconds]
14:36:10  <Eddi|zuHause3> but i think finding the next lowest ETA should be only necessary when a vehicle arrives at a station [or a timetable is changed]
14:36:26  <Eddi|zuHause3> then that ETA can be stored on the edge
14:36:54  <Eddi|zuHause3> somethin similar must already be done with the automatic vehicle spacing
14:37:28  *** jordi_ [~jordi@115.Red-213-96-69.staticIP.rima-tde.net] has joined #openttd
14:39:07  *** jordi [~jordi@115.Red-213-96-69.staticIP.rima-tde.net] has quit [Ping timeout: 480 seconds]
14:44:09  <peter1138> Eddi|zuHause3, we could just assume passengers are stupid and don't pick the best route? ;)
14:44:26  <Eddi|zuHause3> err...
14:55:46  *** Yexo [~Yexo@32-88-ftth.onsneteindhoven.nl] has joined #openttd
15:03:29  *** Purno [~Purno@5350931D.cable.casema.nl] has joined #openttd
15:03:33  <peter1138> Hm
15:04:02  <peter1138> LoadUnloadVehicle needs quite a lot of modification
15:04:29  <peter1138> On the other hand, I shall assume that the other paxdest patch managed it...
15:09:06  * SpComb rewrites OpenTTD using pygame
15:15:09  *** GoneWacko [~gonewacko@adsl-58.35.Static.ssp.fi] has joined #openttd
15:18:01  <Eddi|zuHause3> what are the chances of having a 4-lane road with embedded tram? [2 tiles wide]?
15:18:20  <CIA-5> OpenTTD: smatz * r13858 /trunk/src/openttd.cpp: -Fix: buffer overflow for too long filename supplied as '-g' parameter
15:18:30  *** frosch123 [~frosch@frnk-590fdba9.pool.einsundeins.de] has joined #openttd
15:27:29  <Ammler> Eddi|zuHause3: if you build on oneway roads a tramtrack, you got only one
15:27:48  <Ammler> "spur"
15:28:09  <peter1138> Eddi|zuHause3, slim.
15:31:24  <CIA-5> OpenTTD: smatz * r13859 /trunk/src/ (fios.cpp fios.h openttd.cpp): -Fix: loading of TTD(Patch) savegames from the command line didn't work
15:34:58  *** GoneWacko [~gonewacko@adsl-58.35.Static.ssp.fi] has quit [Quit: leaving]
15:45:06  <blathijs> Eddi|zuHause3: Storing the lowest ETA and updating that when the vehicle with that lowest ETA arrives sounds like a fine plan
15:45:27  <blathijs> Eddi|zuHause3: Though currently, speed of a vehicle is also stored on an edge, but that can probably be replaced with ETA
16:00:46  *** Doorslammer [Doorslamme@PIPP-p-203-54-115-94.prem.tmns.net.au] has quit []
16:01:44  *** ecke [~ecke@213.195.202.130] has joined #openttd
16:04:08  *** rortom [~rortom@p57B7DCE7.dip.t-dialin.net] has joined #openttd
16:05:03  *** welshdragon is now known as welshdra-gone
16:09:30  *** N1ghtCrawler [~n1ghtcraw@c-5596e155.124-1-64736c11.cust.bredbandsbolaget.se] has quit [Ping timeout: 480 seconds]
16:23:17  *** rortom [~rortom@p57B7DCE7.dip.t-dialin.net] has quit []
16:23:44  *** welshdra-gone is now known as welshdragon
16:34:27  *** Wezz6400 [~Wezz6400@ndb.demon.nl] has quit [Ping timeout: 480 seconds]
16:45:57  *** grumbel [~grumbel@i577AEE52.versanet.de] has quit [Quit: Client exiting]
16:51:34  *** M4rk [~M4rk@5351EE2E.cable.casema.nl] has joined #openttd
16:51:39  *** M4rk is now known as Mark
16:53:14  *** mikl [~mikl@cpe.ge-0-2-0-812.0x50c774be.boanqu1.customer.tele.dk] has quit [Quit: Leaving...]
17:00:37  *** Wolf01 [~wolf01@host107-16-dynamic.5-87-r.retail.telecomitalia.it] has joined #openttd
17:00:41  <Wolf01> hello
17:01:13  <Belugas> hello mister Wolf01
17:01:35  <SmatZ> hello
17:01:50  *** Wezz6400 [~Wezz6400@ndb.demon.nl] has joined #openttd
17:02:33  <Wolf01> hello chief Belugas
17:02:43  <Wolf01> hi SmatZ
17:03:12  <Wolf01> oh, UT3 time
17:10:09  <Phantasm> Belugas: How is the fix going?
17:14:24  <Belugas> during holidays?  NEVAR :)
17:15:04  <Phantasm> Hah.
17:19:01  <Belugas> but apart that, pretty much stalled on the same problems
17:19:05  <Belugas> unfortunately
17:21:24  *** Deathmaker [~Miranda@a89-182-129-160.net-htp.de] has joined #openttd
17:33:37  *** GoneWacko [~gonewacko@86-60-159-216-dyn-dsl.ssp.fi] has joined #openttd
17:37:10  <Belugas> Phantasm, don't give up hope :)
17:37:15  <Belugas> it will get solved
17:37:17  <Belugas> just...
17:37:24  <Belugas> don't know when :)
17:37:34  <Belugas> nor how (currently) ;)
17:40:12  <peter1138> What needs solving?
17:41:25  <Belugas> how to deal with the enormous amount of news messages that will be generated
17:41:48  <Belugas> when the industries are going to be mass-created monthly
17:42:08  <peter1138> Hehe
17:42:44  <Belugas> that and of course, the production changes, which are way more commun :)
17:43:34  *** Brianetta [~brian@client-86-27-108-163.brnt.adsl.virgin.net] has quit [Quit: TschÌß]
17:45:14  *** nicfer [~Administr@168.226.106.132] has joined #openttd
17:46:23  *** Klanticus [~Klanticus@189.35.184.72] has joined #openttd
17:58:51  *** Zealotus [~Ping@78-69-54-150-no70.tbcn.telia.com] has quit [Ping timeout: 480 seconds]
18:03:14  <Eddi|zuHause3> <blathijs> Eddi|zuHause3: Though currently, speed of a vehicle is also stored on an edge, but that can probably be replaced with ETA <- speed could be used if a timetable is not specified
18:06:27  <Eddi|zuHause3> <Belugas> how to deal with the enormous amount of news messages that will be generated <- how about this: a player can choose if he wants detailed reports or a summary message, and when clicking on the summary message, it cycles through all the relevant places [like a subsidy message cycles between start and end point]
18:08:28  <blathijs> Eddi|zuHause3: Though speed and ETA are hard to compare
18:08:32  <plakkertjes> why isnt there more than one intro screen
18:08:34  <plakkertjes> grr
18:09:19  <Eddi|zuHause3> blathijs: well, you could do something like air-distance/speed
18:09:22  <blathijs> Eddi|zuHause3: what is this timetable thing? Is that explicit? Is that a current feature?
18:09:31  <blathijs> Eddi|zuHause3: Yeah, true
18:09:50  <Eddi|zuHause3> timetables are available from the order window, that has been in trunk for quite a while
18:10:37  <blathijs> I haven't been actually playing openttd for years now, and missed it in here :-)
18:20:12  <peter1138> Hmm
18:20:37  *** Zealotus [~Ping@78-69-54-150-no70.tbcn.telia.com] has joined #openttd
18:21:24  *** Vikthor [~Vikthor@snat1.spoje.net] has quit [Quit: Leaving.]
18:24:24  <Celestar> back for a few
18:25:21  <Celestar> peter1138: how's progress
18:26:24  <Prof_Frink> overrated.
18:26:37  <Eddi|zuHause3> we were discussing strategies how to use timetables for weighting of edges
18:30:25  <Celestar> Eddi|zuHause3: not at all for the time being
18:30:36  <Celestar> Eddi|zuHause3: the pathfinder doesn't take that into account yet.
18:30:53  <Celestar> Eddi|zuHause3: currently only distance and number of hops, and I'm not even sure about the latter
18:30:56  <Eddi|zuHause3> yeah, i'm talking 3 steps ahead :)
18:32:32  *** welshdragon [~welshxcha@host86-130-180-82.range86-130.btcentralplus.com] has quit [Quit: Leaving]
18:33:49  *** fmauNekAway is now known as fmauNeko
18:34:43  <fmauNeko> plop :)
18:35:36  *** Zuu [~Zuu@c-964fe055.510-8-64736c10.cust.bredbandsbolaget.se] has joined #openttd
18:37:14  * Zuu waiting for a slow Centos computer to update it's pakages so he can install libsdl-devel ... :(
18:37:26  *** welshdragon [~welshxcha@host86-130-180-82.range86-130.btcentralplus.com] has joined #openttd
18:38:06  <Celestar> Eddi|zuHause3: take one step after the other
18:38:21  <Celestar> Eddi|zuHause3: all the weighing is nothing else than writing a custom visitor function for the pathfinder
18:38:57  <Eddi|zuHause3> yes, but it's useless to think about weights that you have to loop the entire map to calculate ;)
18:39:16  <Eddi|zuHause3> so we were searching for variables that are easy to cache
18:40:34  *** welshdragon2` [~welshxcha@host86-130-180-82.range86-130.btcentralplus.com] has joined #openttd
18:41:08  *** GoneWacko [~gonewacko@86-60-159-216-dyn-dsl.ssp.fi] has quit [Quit: leaving]
18:41:08  <Eddi|zuHause3> but you should be thinking about the first step now, not about the third ;)
18:41:12  *** welshdragon [~welshxcha@host86-130-180-82.range86-130.btcentralplus.com] has quit [Read error: Connection reset by peer]
18:41:23  *** welshdragon2` is now known as welshdragon
18:42:48  <Celestar> Eddi|zuHause3: it doesn't matter
18:43:02  <Celestar> Eddi|zuHause3: the cache will only be rebuilt on order modification
18:43:13  <Celestar> Eddi|zuHause3: so timetable, maximum speed are options
18:43:19  <Celestar> Eddi|zuHause3: average travel times are not
18:43:29  <Eddi|zuHause3> yes
18:43:39  <Celestar> I'll be back in 30
18:43:43  <Celestar> with the alter version
18:43:46  <Celestar> latest*
18:47:50  <Eddi|zuHause3> the idea was for each vehicle to calculate an ETA for each order entry, when the vehicle stops at a station, it's own ETA gets increased by round trip time, and the ETA of the order entry gets set to the ETA of the next vehicle in the order list [automatic vehicle spacing has already a way to determine the order of vehicles]
18:48:56  <Eddi|zuHause3> this data would be updated every time a vehicle arrives at a station
18:49:26  <CIA-5> OpenTTD: truebrain * r13860 /branches/noai/bin/ai/regression/regression.txt: [NoAI] -Fix r13857: forgot to update regression :$
18:50:49  <peter1138> Celestar, I added random destinations but not much else. Decided to work on making the minimap show vehicle type
18:54:41  *** bowman [johanf@81-226-229-179-no59.tbcn.telia.com] has quit [Read error: Connection reset by peer]
18:54:45  *** bowman [johanf@81-226-229-179-no59.tbcn.telia.com] has joined #openttd
18:57:29  <blathijs> Celestar: The above would result in passengers waiting a bit for faster train, if it arrives not too much later
18:57:42  *** tom0004 [~0004tom@92.3.230.82] has joined #openttd
19:00:29  <CIA-5> OpenTTD: truebrain * r13861 /branches/noai/src/squirrel_std.cpp: [NoAI] -Fix: require() doesn't like '/' on Windows when loading from a tar .. so fix that :) (tnx Zutty, tnx Yexo)
19:04:45  *** Deathmaker [~Miranda@a89-182-129-160.net-htp.de] has quit [Read error: Connection reset by peer]
19:05:27  *** GoneWacko [~gonewacko@86-60-159-216-dyn-dsl.ssp.fi] has joined #openttd
19:06:45  *** Purno [~Purno@5350931D.cable.casema.nl] has quit [Read error: Connection reset by peer]
19:12:41  *** ARock [R.Rock@xdsl-87-78-212-139.netcologne.de] has joined #openttd
19:15:50  *** plakkertjes [~plakkertj@ip51cc357e.adsl-surfen.hetnet.nl] has quit [Ping timeout: 480 seconds]
19:33:26  *** rortom [~rortom@p57B7DCE7.dip.t-dialin.net] has joined #openttd
19:34:54  *** nicfer [~Administr@168.226.106.132] has left #openttd []
19:38:58  <Celestar> peter1138: I've added stuff to determine whether a cargopacket should board/deboard
19:39:39  <blathijs> Bit harsh to talk about passengers as "a cargopacket"
19:39:49  *** venus214 [~guesswho@p5B205A0E.dip.t-dialin.net] has quit []
19:39:53  <blathijs> Those are real humans you're talking about, man!
19:40:55  <Celestar> blathijs: in the airline business, they are sometimes called SLF
19:41:59  <Celestar> which is short for "self loading freight"
19:42:47  <blathijs> *grin*
19:44:44  <welshdragon> lol
19:52:37  <Celestar> hm ...
19:53:12  <Celestar> I have a function called foo, is there a c++ to enable it to be called as bar aswell (and with c++ way I don't mean #define bar foo)
19:59:52  <Eddi|zuHause3> static inline bar() { foo() }
20:00:24  <Celestar> mh :S
20:00:36  <Eddi|zuHause3> the least stupid that went through my mind...
20:00:56  <Eddi|zuHause3> everything else includes pointer magic...
20:01:55  <rortom> mhm
20:02:13  <rortom> the c++ way would be to derivate the class and implement calling both methods?
20:02:33  <Celestar> :P
20:03:08  <Eddi|zuHause3> templates could work ;)
20:03:20  <Belugas> might be easier if the need was expressed in context :)
20:07:58  *** Dred_furst [~Dred_furs@user-514d7e3a.l2.c2.dsl.pol.co.uk] has quit [Read error: Connection reset by peer]
20:13:04  <Celestar> well, just forget it, it was a rethorical question :P
20:15:05  *** mikl [~mikl@0304ds2-ba.0.fullrate.dk] has joined #openttd
20:17:22  <peter1138> Hmm, this is not right :o
20:17:56  <Celestar> peter1138: what is?
20:19:42  <Celestar> peter1138: http://www.fvfischer.de/routenetwork_pathfind.diff <= latest version
20:19:59  <Celestar> peter1138: has a function that answers the question what do with a cargopacket and a vehicle (=
20:20:33  <Celestar> do we have latexers among us?
20:20:56  <Ammler> Celestar: Mucht
20:21:05  <Mucht> yes here
20:21:11  <Mucht> I am indeed
20:21:15  <Ammler> :-)
20:21:38  <Celestar> Mucht: do you use bibtex?
20:21:44  <Mucht> sure
20:21:51  <Mucht> I'm writing my doctoral thesis
20:21:59  <Mucht> impossible without bibtex ;-)
20:22:11  <Celestar> Mucht: heh. I'm about 3 months away, but I have another problem
20:22:13  <Celestar> I have a book in my references. in bibliography, I'd like the page numbers (which are in the bibtex code) to appear. How do I need to proceed?
20:22:40  <Celestar> also, "edition" is not translated to the native language (in this case, ngerman)
20:23:25  <Mucht> In fact, the bibliography should not be touched "by hand". there are many different bibliographystyles, which handle the layout
20:23:52  <Mucht> I assume, for your second problem, there is a german bibliographystyle
20:24:05  <Celestar> Mucht: yeah. but what style to use or how to modify the style. the documentation of bibtex frankly sucks
20:24:56  <Mucht> actually, I do not recommend you to argue about such minor problems like edition instead of auflage
20:25:14  <Mucht> such small problems lead to a huge ammount of work to fix with latex
20:25:30  <Mucht> if you are writing your thesis in english, I recommend you to use edition, even for german books
20:25:35  <Mucht> (I do so, actually)
20:25:45  <Mucht> for your question about bibliographystyles...
20:26:35  <Celestar> Mucht: it's not my thesis :P
20:26:44  <Mucht> there are douzens of styles around. Actually, most journals define their own stylefile. Its best to ask your collegues which style is common on your department
20:27:48  <Mucht> you can, off course, edit your own stylefile. Have a lot of fun with that ;-)
20:28:24  <Mucht> you use jabref for bibtex editing?
20:29:57  <Mucht> Celestar: http://www.cs.stir.ac.uk/~kjt/software/latex/showbst.html <- there you got some 50 style examples
20:31:37  <Celestar> Mucht: I certainly use bibtex
20:31:42  <Celestar> er jabref
20:32:03  <Celestar> we've got a departmental jabref database with 12000+ entries
20:32:19  <Celestar> which is, OF COURSE, not stored as sql database, but as text file :S
20:32:44  <Mucht> sounds interesting
20:32:53  * Belugas goes home. see ya two more row
20:33:08  *** DaleStan_ [~Dale@pool-71-120-109-218.ipslin.dsl-w.verizon.net] has joined #openttd
20:33:09  *** DaleStan is now known as Guest139
20:33:09  *** DaleStan_ is now known as DaleStan
20:33:37  <Celestar> peter1138: so are we going on tomorrow (but I only have an hour or so)
20:33:44  <rortom> thanks for the bibtex styles :)
20:33:44  <Mucht> Celestar: is it possible that you want to do an "Inbook" entry, for your question of how to display pages?
20:33:55  <Mucht> np rortom ;-)
20:35:12  <Celestar> Mucht: possible. apparently my jabref misses such a button.
20:35:17  *** ARock [R.Rock@xdsl-87-78-212-139.netcologne.de] has quit []
20:35:30  <Mucht> Celestar: no, thats an entry type
20:35:55  <Celestar> Mucht: I know, but I get a choice when entering a new item
20:36:17  *** frosch123 [~frosch@frnk-590fdba9.pool.einsundeins.de] has quit [Remote host closed the connection]
20:36:30  <Celestar> oooh
20:36:34  <Celestar> thanks Mucht that's it afaik
20:36:42  * Celestar finishes this and goes back to coding
20:36:48  <Mucht> np Celestar
20:36:52  <Celestar>  std::vector<VertexDescriptor> dump; this->hopcache.push_back(dump);
20:36:56  <Celestar> any idea to simplify this?
20:38:16  <rortom> just the line?
20:38:28  <Noldo> that's not even bad
20:38:47  <Celestar> yeah, but dump is totally useless
20:39:19  *** Guest139 [~Dale@pool-71-120-109-218.ipslin.dsl-w.verizon.net] has quit [Ping timeout: 480 seconds]
20:42:50  *** Born_Acorn is now known as I_am_Born_Acorn
20:45:58  *** I_am_Born_Acorn is now known as Born_Acorn
20:46:15  *** Zahl [~Zahl@g227018138.adsl.alicedsl.de] has quit [Quit: (~_~]"]
20:46:54  *** Zuu [~Zuu@c-964fe055.510-8-64736c10.cust.bredbandsbolaget.se] has quit [Quit: Leaving]
20:48:47  * peter1138 returns.
20:49:15  <peter1138> Just updated my repo with that last changes.
20:49:17  * Prof_Frink smashes peter1138's return to the far corner of the court
20:49:50  <Celestar> peter1138: http://www.fvfischer.de/routenetwork_pathfind.diff <= latest version, some minor cleanups
20:49:54  <Celestar> cu tomorrow
20:49:59  <peter1138> More? Bah! ;)
20:50:04  <peter1138> Okay, night night Celestar
20:51:29  <peter1138> Ah, just using this-> in a few places...
20:56:19  <Wolf01> 'night
20:56:22  *** Wolf01 [~wolf01@host107-16-dynamic.5-87-r.retail.telecomitalia.it] has quit [Quit: Once again the world is quick to bury me.]
20:58:41  <Progman> Celestar: does the patch something do already? I tested it, runs with -d routing=7 and see some debug messages but are the cargo already routed somehow?
21:01:45  <Eddi|zuHause3> peter1138 said he had a modification that assigns random destinations
21:02:53  <Eddi|zuHause3> as your luck goes... the link just went out of my buffer :p
21:10:16  <peter1138> It assigns destinations, but it doesn't yet perform routing.
21:12:13  *** Wezz6400 [~Wezz6400@ndb.demon.nl] has quit [Ping timeout: 480 seconds]
21:14:36  <peter1138> Haha
21:14:49  <peter1138> The route network for pile transport is a bit... mad.
21:15:19  <Rubidium> extrapile?
21:15:21  * Noetloj assigns peter1138 to the destination of /dev/null/
21:15:35  <Noetloj> via /dev/ obviously.
21:15:58  <Prof_Frink> silly Noetloj!
21:16:06  <Prof_Frink> /dev/null is not a directory!
21:18:34  <Noetloj> pssh.
21:18:36  <Noetloj> it still deletes things.
21:18:52  <Noetloj> Lets just say I assigned him to the bin, he's dead now, end of.
21:18:57  <Noetloj> Settled?
21:19:29  *** grumbel [~grumbel@i577B8A02.versanet.de] has joined #openttd
21:23:21  *** Wezz6400 [~Wezz6400@ndb.demon.nl] has joined #openttd
21:25:40  *** welshdragon [~welshxcha@host86-130-180-82.range86-130.btcentralplus.com] has quit [Read error: Connection reset by peer]
21:25:59  *** welshdragon [~welshxcha@host86-130-180-82.range86-130.btcentralplus.com] has joined #openttd
21:26:02  *** Brianetta [~brian@client-86-27-108-163.brnt.adsl.virgin.net] has joined #openttd
21:26:04  *** Wezz6400 [~Wezz6400@ndb.demon.nl] has quit []
21:37:47  <peter1138> Celestar, some issues with aircraft orders :o
21:38:37  *** GoneWacko [~gonewacko@86-60-159-216-dyn-dsl.ssp.fi] has quit [Quit: Lost terminal]
21:41:00  <peter1138> Hmm, or any order.
21:44:47  <CIA-5> OpenTTD: glx * r13862 /branches/noai/src/squirrel.cpp: [NoAI] -Fix: don't display caught exceptions in AIDebug window. Note: try-catch block will catch runtime errors as exception, but this is not caused by this commit (it was already the case).
21:46:09  <Brianetta> peter1138: http://www.tt-forums.net/viewtopic.php?f=33&t=36107&p=712440#p712440
21:48:02  <rortom> "train control patch"?
21:49:14  <Brianetta> (-:
22:12:12  <peter1138> Hmm, shuffling orders around still breaks things :(
22:21:27  <peter1138> Ah ha.
22:21:28  *** bleepy [bleepy@5ad00e8d.bb.sky.com] has quit [Read error: Connection reset by peer]
22:21:35  *** bleepy [bleepy@5ad456a9.bb.sky.com] has joined #openttd
22:22:02  *** a1270 [~Cheese@24-117-51-112.cpe.cableone.net] has quit [Quit: a1270]
22:22:55  *** a1270 [~Cheese@24-117-51-112.cpe.cableone.net] has joined #openttd
22:26:38  *** a1270 [~Cheese@24-117-51-112.cpe.cableone.net] has quit []
22:27:57  <peter1138> Order insertion and removal going haywire :o
22:28:09  <peter1138> Dunno if it's the routing code or actual orders going wrong, though.
22:28:11  <peter1138> nini
22:30:10  *** a1270 [~Cheese@24-117-51-112.cpe.cableone.net] has joined #openttd
22:31:31  *** stillunknown [~stillunkn@82-136-225-75.ip.telfort.nl] has quit [Ping timeout: 480 seconds]
22:37:53  *** GoneWacko [GoneWacko@86-60-147-155-dyn-dsl.ssp.fi] has joined #openttd
22:53:19  *** KillaloT [~killalot@0x5738cc83.ge-1-1-0-1100.alnqu1.ip.tele.dk] has quit [Quit:  HydraIRC -> http://www.hydrairc.com <- IRC for those that like to be different]
22:59:59  <Rubidium> peter1138: are there any reasons why the if (!IsArticulatedVehicle(u)) { (train_cmd.cpp) is needed? TTDP seems to the code in there also for articulated vehicles according to FS#2167
23:01:59  <Eddi|zuHause3> frosch had that same question, i believe
23:07:36  *** bleepy [bleepy@5ad456a9.bb.sky.com] has quit [Ping timeout: 480 seconds]
23:10:44  <CIA-5> OpenTTD: smatz * r13863 /trunk/config.lib: -Fix (r13852): make the nightly compile again
23:10:56  *** plakkertjes [~plakkertj@ip51cc357e.adsl-surfen.hetnet.nl] has joined #openttd
23:15:00  *** welshdragon [~welshxcha@host86-130-180-82.range86-130.btcentralplus.com] has quit [Read error: Connection reset by peer]
23:15:18  *** welshdragon [~welshxcha@host86-130-180-82.range86-130.btcentralplus.com] has joined #openttd
23:23:40  *** welshdragon [~welshxcha@host86-130-180-82.range86-130.btcentralplus.com] has quit [Read error: Connection reset by peer]
23:23:44  *** welshdragon [~welshxcha@host86-130-180-82.range86-130.btcentralplus.com] has joined #openttd
23:31:01  *** plakkertjes [~plakkertj@ip51cc357e.adsl-surfen.hetnet.nl] has quit [Ping timeout: 480 seconds]
23:35:27  *** welshdragon is now known as welshdra-gone
23:37:33  <CIA-5> OpenTTD: belugas * r13864 /trunk/src/industry_cmd.cpp: -Feature(FS #2164): All industry creations are now generating a news event, even those funded by a real player.
23:40:26  *** fmauNeko is now known as fmauNekAway
23:41:16  *** fmauNekAway is now known as fmauNeko
23:52:07  *** DJNekkid_ [~chatzilla@static217-26.adsl.no] has joined #openttd
23:52:10  *** DJNekkid_ is now known as DJNekkid

Powered by YARRSTE version: svn-trunk