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

---Logopened Mon Jul 28 00:00:51 2008
00:30-!-a1270 [] has quit [Quit: a1270]
00:32-!-a1270 [] has joined #openttd
01:10-!-Ammler [] has joined #openttd
01:22-!-SpComb [] has joined #openttd
02:00-!-bleepy [] has joined #openttd
02:16<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.
02:28<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
02:29-!-Malawar [] has joined #openttd
02:31<Malawar>man, i'm having the hardest time figuring out signals; i've got a big loop of track ( screenshot: ), i put down a two-way signal on it and have one train going around but the signal is always red. :/
02:32<Celestar>Rubidium: peter1138: is the standard way to go in a member to use this-> or not to use this-> ?
02:33<Ammler>Malawar: you are joking... :-)
02:33<Malawar>i'm not :/
02:33*Malawar is a noob :(
02:33<@peter1138>Celestar, so far we've used this->
02:33<Celestar>peter1138: k
02:34<@peter1138>Except for YAPF.
02:34<Celestar>peter1138: k k
02:34<Ammler>Malawar: try a 2. signals
02:35<Celestar>peter1138: I'll be back in 10 minutes. gotta check our cluster cooling, apparently it has failed again :S
02:36<Malawar>i think i'm getting an understanding of how they work now :P
02:36*SpComb melts Celestar's cluster
02:37<@peter1138>Malawar: The train is on both sides of the signal, therefore it's red.
02:37<Malawar>yeah, I figured that out, but it didn't occur to me that another signal on the line would help :P
02:38<@peter1138>Hmm, if you figured that out then the second bit should be obvious.
02:43<@peter1138> :D
02:44<Celestar>what is that peter1138 ?
02:44<@peter1138>mercurial with your patch from last night applied
02:44<@peter1138>Although it looks totally different to :o
02:47-!-Gekz_ [] has joined #openttd
02:48-!-Gekz [] has quit [Ping timeout: 480 seconds]
02:54<Celestar>peter1138: I see :D
03:13-!-Nev [] has joined #openttd
03:15<Celestar>peter1138: so, what do you want me to do? :P
03:15-!-mikl [] has joined #openttd
03:16<@peter1138>Well... finish it? ;)
03:17<Noldo>how very Mortal Kombat
03:19-!-GoneWacko [] has joined #openttd
03:19-!-bleepy [] has quit [Ping timeout: 480 seconds]
03:20<Celestar>peter1138: I'll try to implement a pathfinder today (=
03:20<Celestar>peter1138: meh, I forgot to include the boost license with the diff :P
03:25<blathijs>Celestar: What kind of pathfinder?
03:25<blathijs>Celestar: On that goes through the order graph?
03:26<Celestar>blathijs: yes
03:26<Celestar>blathijs: to find paths for a packages
03:26<blathijs>Celestar: You might be able to reuse the AyStar code that NPF uses?
03:27<blathijs>Not sure what kind of route you are looking for? Shortest, or all routes?
03:27<Celestar>blathijs: shortest for the time being
03:27<blathijs>Celestar: You should be able to get away with writing just a handful of callbacks and have a working A* pathfinder
03:27<Celestar>blathijs: boost has the pathfinders implemented
03:27<Celestar>blathijs: you just need to call them
03:28<blathijs>Ah, that is probably even easier then :-
03:28-!-dih [] has joined #openttd
03:35*peter1138 smacks Celestar!
03:35<@peter1138>I've been trying to use EdgeIterator... when it should actually be OutEdgeIterator
03:38-!-Doorslammer [] has joined #openttd
03:41-!-plakkertjes [] has joined #openttd
03:42<Celestar>heh :P
03:43-!-TinoM [] has joined #openttd
03:44-!-mikl [] has quit [Ping timeout: 480 seconds]
03:46<Celestar>and peter1138 , I hope the doxygen stuff I wrote is any good. did you read it?
03:46<@peter1138>Uh... I saw it... does that count? ;)
03:46-!-Doorslammer|BRSet [] has joined #openttd
03:49<Celestar>well :P
03:49<Celestar>it depends on the question whether you want me to improve it or not
03:50-!-Doorslammer [] has quit [Ping timeout: 480 seconds]
03:54-!-dih [] has quit [Ping timeout: 480 seconds]
04:06<@peter1138>This network map is quite a mess :D
04:06<Celestar>peter1138: you mean like visually?
04:06<@peter1138>I've got it on the minimap
04:07<Celestar>show me show me show me
04:07<Noldo>me too me too metoo
04:07-!-Vikthor [] has joined #openttd
04:08<Lachie>do you slave SATA drives?
04:09<Celestar>no Lachie
04:09<Lachie>what dictates which HDD the boot record is on
04:09<Celestar>peter1138: nice one :D maybe we should have a separate view
04:10<Celestar>Lachie: the boot record is part of a partion...
04:10<@peter1138>Celestar: Definitely. This was just a quickie :D
04:10<Celestar>nice quickie. difficult?
04:10<Celestar>apart from my typedef-messup? :S
04:10<@peter1138>Lachie: Nothing dictates it. The BIOS can in theory boot from any of them.
04:10<@peter1138>Celestar: reload that hg URL :)
04:11<Celestar>Lachie: every partition can have a boot record. every disk DOES have an MBR
04:11<Lachie>alright then
04:11<@peter1138>There is some redundancy there as there are multiple paths between to vertices.
04:11<@peter1138>It just redraws them currently.
04:12-!-Doorslammer|BRSet is now known as Doorslammer
04:12<@peter1138>I really want to see this on my YAPP network :D
04:12*peter1138 ponders applying it.
04:13<@peter1138>Celestar: the intermediate SmallVector is unnecessary if some of the protected stuff is exposed.
04:18<Celestar>peter1138: nice nice :D
04:18-!-elmex [] has joined #openttd
04:22<@peter1138>I still haven't figured out how to export all this :o
04:22<@peter1138>HG EXPERT NEEDED
04:23<Celestar>the pathfinder did compile :D
04:24<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.
04:26<Celestar>or store it for each shared order list
04:26<Celestar>er .. no good :P
04:27<@peter1138>Only conflict with YAPP is in debug...
04:28<@peter1138>Which is easy to solve :D
04:28<@peter1138>So I will get my route map, woo
04:29<@peter1138>hehe, still looks a mess :D
04:29<@peter1138>ah yes, all the AI...
04:30<Celestar>we need a "remove_all_ais" console command :P
04:31<@peter1138>Nah, I'm just making it only show the local player's routes.
04:32<Celestar> \o/ The pathfinder does something
04:34<@peter1138>^ bit better looking
04:34<Celestar>you have some nice transfer network there in the middle haven't you?
04:34<Celestar>trams or something
04:35<@peter1138>no trams, just trains and busses
04:35<@peter1138>plus a couple of long truck routes
04:47-!-Gekz [] has joined #openttd
04:54*Celestar laughs
04:56<Gekz>omg. Opeth.
05:03<Celestar>peter1138: \o/
05:03<Celestar>peter1138: <= I'm nuts, am I not?
05:06<blathijs>Looks cool :-)
05:07<Noldo>if it works, we are happy
05:07<Celestar>it does
05:07<Celestar>TIC/TOC spits out time in microseconds right?
05:08-!-stillunknown [] has joined #openttd
05:08<Gekz>Celestar: is this evidence it works?
05:08<Celestar>Gekz: yes it is
05:08<Celestar>Gekz: it finds routes
05:08<Gekz>so when will we see passenger destination in svn?
05:09<Gekz>soon being a timeframe between now and next month.
05:09<Celestar>I *guess* we'll see some commits in that timeframe, but likely not yet a fully working system
05:09<Gekz>damn you people and demanding to do things right
05:10<Gekz>could be freeciv though
05:10<Gekz>taking 15 years to get to 2.0
05:10<Celestar>ok everyone I need a *LARGE* savegame
05:10<Celestar>from trunk
05:10<Celestar>(I only have yapp stuff)
05:11<Ammler>Celestar: coop archive
05:11-!-rortom [] has joined #openttd
05:12<Ammler>only trunk stuff there :-)
05:12<Celestar>Ammler: just browsing them
05:12*peter1138 returns
05:13<@peter1138>Celestar, no, TIC/TOC spits out number of cycles.
05:13<Celestar>peter1138: I see
05:13<Celestar>how much is 180k then? :P
05:14<@peter1138>Depends how often it is ;)
05:14<Celestar>each time I call the pathfinder (=
05:14<Celestar>on a reasonably large game
05:14<Celestar>(600 vehicles)
05:16-!-KillaloT [] has joined #openttd
05:18-!-Yexo [] has joined #openttd
05:19<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.
05:21<@peter1138>Well, it should be a lot simpler than map pathfinding.
05:22<Celestar>it grows with O(n log n) afaik, which is about as good as it gets.
05:24<Celestar>0.1ms is not bad, assuming we cache/store the data somehow any only recompute on need
05:25<Gekz>that's awesome
05:30-!-[1]plakkertjes [] has joined #openttd
05:33<@peter1138>Hmm, deleting a route doesn't seem to actually update the graph.
05:33<@peter1138>In RemoveRoute it just breaks if removing?
05:34<Celestar>peter1138: ?
05:34<@peter1138>DEBUG(routing, 4, "Found edge with index %d. Removing now", from->index);
05:35<@peter1138>Doesn't... do anything.
05:35<rortom>hi all
05:35<Celestar>er ..
05:35<rortom>peter1138: are you working IRL? :p
05:35<rortom>or 100% ottd? ;)
05:35<Celestar>I apparently have forgotten something :P
05:36<Celestar>peter1138: You don't have my latest version apparently :P
05:37-!-plakkertjes [] has quit [Ping timeout: 480 seconds]
05:37-!-[1]plakkertjes is now known as plakkertjes
05:37<Celestar>peter1138: I'll make a new diff for ye in a minute
05:38<@peter1138>rortom: I'm on holiday at the moment :D
05:38<@peter1138>Celestar... ahh :)
05:39<Celestar>peter1138: <= take this version for the time being
05:41<Celestar>peter1138: you can play around with ComputeRoutes() as well
05:41-!-Yexo_ [] has joined #openttd
05:41-!-Yexo is now known as Guest80
05:41-!-Yexo_ is now known as Yexo
05:43-!-Yexo [] has quit [Read error: Connection reset by peer]
05:43-!-Yexo_ [] has joined #openttd
05:43-!-Yexo_ is now known as Yexo
05:46<Celestar>can I pass a std::vector around by using a pointer?
05:47-!-Guest80 [] has quit [Ping timeout: 480 seconds]
05:47<@peter1138>You should, otherwise you end up copying its data around all the time.
05:48<Celestar>so std::vector<int> shit; foo(&shit) or foo(shit); ?
05:49<blathijs>Celestar: The latter will work if you make foo accept a reference
05:50<blathijs>and the former if you make foo accept a pointer, of course
05:53-!-Dred_furst [] has joined #openttd
05:53*peter1138 updates his hg
05:54*Celestar slaps himself with the save-before-compile-trout
05:55<@peter1138>Hmm, still not removed :o
05:56<Celestar>there IS a remove_edge there now, is there?
05:56-!-Progman [] has joined #openttd
05:57<@peter1138>I think it's first up.
05:58<@peter1138>I'm not actually removing orders
05:58<@peter1138>I'm adding orders, and hence a one path is split into two, but the original path is not being removed.
05:58<@peter1138>er, first up = higher up
06:00-!-Zahl [] has joined #openttd
06:01<Celestar>peter1138: you should see the route being removed if things are split
06:01-!-Vikthor [] has quit [Remote host closed the connection]
06:01<Celestar>(-d routing=7 is maximum at th emoment)
06:02<@peter1138>Yes, I just thought to try that ;)
06:03-!-Sir-Bob [] has joined #openttd
06:04<@peter1138>Okay, it says removing route, then i get a few lines of 'found edge with index 265. not removing'
06:05<Celestar>not good
06:05<Celestar>not good
06:05<Celestar>the edge should be there
06:05<Celestar>how big is that network?
06:06<@peter1138>however, i just tried it with a simple triangle
06:06<@peter1138>still happens
06:06<@peter1138>three hops
06:06<@peter1138>first set an order from 1 to 3
06:06<@peter1138>then add 2 between them in both directions
06:07<@peter1138>the route for 1 to 3 is definitely still there
06:07<@peter1138>hmm, if i remove the orders completely its still there :o
06:07-!-Mark [] has quit [Quit: HydraIRC -> <- Go on, try it!]
06:08-!-Roujin [] has joined #openttd
06:08<@peter1138>only disappears when the stations are removed
06:09<Celestar>peter1138: weird
06:09<Celestar>will you try or want me to give it a shot
06:09<@peter1138>Doing so now :)
06:10<Celestar>:) I assume the code is readable then :P
06:10<@peter1138>It's okay as long as gcc doesn't spit out a type error with a dozen lines to templates ;)
06:12<Celestar>peter1138: yeah I now that problem
06:12<Celestar>peter1138: record last week was something over 200 lines of templates
06:13<Celestar>peter1138: I especially love things contaning "> > > > > > >" at some point :P
06:13<Eddi|zuHause3>configure does not actually check for presence of boost yet?
06:13<@peter1138>Eddi|zuHause3, no
06:13<Celestar>Eddi|zuHause3: no, not yet
06:15<Eddi|zuHause3> <- ??
06:15<Celestar>peter1138: finding paths works nicely now
06:15<Celestar>Eddi|zuHause3: yes. welcome to gcc 4.3 :S
06:15<Celestar>Eddi|zuHause3: their own includes include their own deprecated headers
06:16<Eddi|zuHause3>funny ;)
06:16<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"
06:17<@peter1138>Celestar, by the way, I assume depot and waypoint orders are ignored?
06:17<@peter1138>Hmm, must be.
06:17<blathijs>Celestar: You are using an older boost version currently then?
06:18<@peter1138>I'm using whatever ubuntu had...
06:19<Celestar>blathijs: whatever ships with my distro
06:19<Celestar>peter1138: yes, only station orders are used.
06:19<Roujin>Eddi: have you seen the patch I posted at the thread about the yapf road vehicle addition?
06:20<Celestar>peter1138: I'm NOT doing a semantic analysis of the conditional orders however.
06:20<@peter1138>Indeed not
06:20<Celestar>dbg: [routing] The next hop going from <Grenbury Lakeside> to <Grenbury Branch> is via <Grenbury Valley>
06:21<Celestar>no cache yet
06:22<Celestar>we can still implement that later I guess
06:23-!-mikl [] has joined #openttd
06:24-!-Ammller [] has joined #openttd
06:24-!-Ammler [] has quit [Quit: Konversation terminated!]
06:25-!-Osai [] has joined #openttd
06:25-!-Ammller is now known as Ammler
06:25-!-SmatZ [] has joined #openttd
06:26-!-XeryusTC [] has joined #openttd
06:26-!-dih [] has joined #openttd
06:27-!-planetmaker [] has joined #openttd
06:27-!-planetmaker is now known as pm|away
06:27-!-tneo [] has joined #openttd
06:30<Eddi|zuHause3>hm... why does debug output not appear in the ingame console?
06:32<Eddi|zuHause3>dbg: [routing] Test passed. Adding route from Melbrück (213) to Chemnitz an der Donau (8). Index 788, Vehicle Type 0
06:33*SpComb renames his station to "foo (1337) to bar"
06:33<Celestar>Eddi|zuHause3: I'm not sure?
06:33<SpComb>english language injection vulnerability
06:34<@peter1138>Eddi|zuHause3: developer 3
06:34<@peter1138>or developer ... something
06:34<Celestar>peter1138: obtaining a route from a precomputed network is about 3-4 orders of magnitude faster (less than a microsecond here)
06:35<@peter1138>oh, 2 is enough
06:35<Celestar>peter1138: I'm not going to fully optimize this stuff now, but we should bear that in mind for later
06:35<@peter1138>Celestar, so worth doing.
06:36<Celestar>how many tiles are processed in the tile loop per frame?
06:36<@peter1138>Depends on the mapsize.
06:36<Celestar>well mapsize/what?
06:36<Celestar>was that 1280 ?
06:36<@peter1138>I think it's something like the whole map done once every 256 ticks. Possibly.
06:38<@peter1138>TILELOOP_SIZE is 16, square it you get 256.
06:39<@peter1138>So X * Y / 256 = number of tiles processed
06:39<Celestar>so for a 1k x 1k map, we have 4096 tiles processed
06:39<@peter1138>A lot.
06:39<Celestar>if 10% of these tiles are houses that generate mail and passengers, we have up to 820 cargopackets generated per tick
06:40<@peter1138>Does pathfinding need to be done for each of those at the start?
06:41<Celestar>only when there's a vehicle to board
06:41<@peter1138>Or do we pathfind when... yeah that
06:41<Celestar>so we can unify the cargopackets first
06:41<Celestar>(with same origin/destination)
06:41<Celestar>and save us a lot of time
06:41<@peter1138>I believe packets are already unified there
06:42<Celestar>but generally on a full 1k x 1k map, we can assume that we need about a million more cycles per tick
06:42<Celestar>with about 30 fps, we need about 30 MHz more :P
06:42<Celestar>not counting the cache updates
06:42<@peter1138>Well it's always optional for those with slow computers.
06:43-!-Brianetta [] has joined #openttd
06:43<Celestar>without cache, we can safely assume that we need about a whole additional core :P
06:44<@peter1138>Well... I have four ;)
06:44<@peter1138>But alas!
06:44<Celestar>well :)
06:44<Celestar>we're not going to multithread the route network today, ok peter1138 ? (=
06:45<Celestar>heh. I just tried three time to quit gdb with ":q"
06:46-!-Sir-Bob [] has quit [Ping timeout: 480 seconds]
06:47<Celestar>peter1138: <= with "Find the next hope" feature
06:47<Eddi|zuHause3>it could use a version number ;)
06:48-!-Wezz6400 [] has joined #openttd
06:48*Celestar slaps Eddi|zuHause3.0
06:55<Celestar>A vector can store a vector, right?
06:56<Celestar>like std::vector<std::vector<int>> hopcash; ?
06:57<Celestar>they did it?
06:57<Noldo>etch and a half tails
06:58<Eddi|zuHause3>,%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
06:59<@peter1138>Hmm, right...
06:59<@peter1138>This route deleting...
06:59<@peter1138>Is all cryptic ;)
06:59<Celestar>peter1138: if you're really really good. you get remove_edge_if() to work
06:59<Celestar>I've not yet managed to do so
07:01<@peter1138>That would avoid the need for the loop, right?
07:03<Eddi|zuHause3>why remove_edge_if()? couldn't you just build a multiple-edges-graph?
07:03<Eddi|zuHause3>or am i misunderstanding stuff ;)
07:04<Noldo>how does paxdest system influence station rating?
07:04<@peter1138>does it?
07:06<rortom>wanted to show you yesterday
07:07<Gekz>rortom: whats that
07:07<Roujin>rortom: are these displayed optionalß
07:07<Gekz>some kind of counter thing
07:07<Roujin>the window is kinda big like this, it should be optional to display this data
07:07<Celestar>peter1138: it would avoid the need for a loop and the if, because that's all inside the remove_edge_if
07:07<Noldo>Roujin: check the other picture
07:08<@peter1138>Roujin, you have to click on the stats button...
07:08<rortom>thats a feature patch im working on
07:08<rortom>to improve the station gui
07:08<Roujin>ah yes
07:09<Gekz>make it less fat
07:09<Gekz>cant the vehicles come up in a horizontal list first
07:09<Gekz>like 1 Train - 9 road vehicles - 1 Aircraft
07:09<rortom>yes, i wanted to do that as next
07:09<Roujin>still also the small version is bigger than how it's now
07:09<rortom>a bit
07:09<Gekz>that too
07:09<Gekz>random spacing
07:10<Gekz>kill it
07:10<rortom>as i added the accept field
07:10<rortom>yes ;)
07:10<Gekz>looks promising
07:10<rortom>its coded in some hours and is far from perfect :)
07:10<Gekz>make it mergable :P
07:10<Gekz>or i'll smack you
07:10<rortom>urgs :|
07:10<rortom>you will have to smack me :|
07:10<SmatZ>smack smack
07:11<Gekz>your work will be pointless
07:11<Gekz>clean code is good code
07:11<rortom>mh, what stats could be interesting also?
07:11<rortom>but getting things into trunk is like praying for god for a wonder ;)
07:11<Gekz>you could possibly make the stats box have buttons
07:11<rortom>for what purpose?
07:11<Gekz>such as transferred this year, passed this year
07:11<Gekz>so its not so fat
07:11<Gekz>displaying one part at a time
07:12<rortom>good idea
07:12<Gekz>or make the waiting: part dynamic if possible
07:12<Gekz>so if there's only one line, shrink it to one line
07:12<Gekz>and if its two, etc
07:12<rortom>thats what i also thought of
07:12<Roujin>[13:10] <rortom> but getting things into trunk is like praying for god for a wonder ;) <-- not really
07:12<Gekz>make it so it can only get bigger
07:12<Gekz>not smaller
07:12<Roujin>it's hard yes. but not impossible
07:12<Gekz>because if its fluctuating between 3 and 4 things
07:12<Gekz>you dont want it flickering
07:12<Gekz>you want it to stay at size 4
07:13<rortom>i will find a way ;)
07:13<rortom>mhm what stats could be done as well?
07:13<rortom>how long goods waited or such?
07:13<Roujin>that "supplies:" string in the station building window, that was done by me :P
07:13<rortom>well done :D
07:13<Roujin>so you see, it is possible to get something into trunk
07:14<Roujin>just keep the code clean, and don't do too much at a time.
07:14<@peter1138>Celestar, argh! A mass of template errors!
07:14-!-Forked [] has joined #openttd
07:14<Forked>yapp is really something :)
07:15<rortom>someone knows the m&b screensaver?
07:16<rortom>could work well with TTD's grf :)
07:17<Gekz>there is no OpenTTD screensave
07:17<Gekz>that would be awesome :D
07:18<Celestar>peter1138: yeah :S
07:18<Eddi|zuHause3>there have been at least two patches to make ottd a screensaver
07:18<rortom>Gekz: there is a screensaver
07:18<Celestar>peter1138: on the other hand, the cache is mostly written
07:18<Ammler>Eddi|zuHause3: something linuxish?
07:18<Gekz>I see.
07:18<Eddi|zuHause3>i think they were aimed at windows...
07:23<@peter1138>Argh, it's too hot outside.
07:27<Eddi|zuHause3>that's only 6 >s ;)
07:39<Celestar>peter1138: yeah. I'm really curious WHAT qualifiers are discarded :S
07:43<@peter1138>const, usually
07:43<Celestar>peter1138: yeah :S
07:43<Eddi|zuHause3>the route gui should probably have a filter for cargo type :p
07:44<Celestar>Eddi|zuHause3: the route network doesn't know about cargo types
07:44<Celestar>not even sure that is needed
07:45<Celestar>with a properly set up network
07:45<@peter1138>Well if you want more than passenger destinations then it is.
07: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)
07:45<Eddi|zuHause3>of course i would not want my steel to try to board a passenger train that happens to cross the station
07:46<Celestar>like Routing *Routing[CT_MAX];
07:46<@peter1138>Hmm, 32 routing tables? hh
07:46<Celestar>peter1138: I don't think it should be inside the graph
07:46<Eddi|zuHause3>yes, separate graphs seem reasonable
07:46-!-Roest [] has joined #openttd
07:47<Eddi|zuHause3>you'll have vehicles that take part in multiple graphs, though
07:47<Eddi|zuHause3>like mixed grain and cattle trains
07:47<blathijs>Celestar: Why not putting it inside a single graph?
07:47<Celestar>Eddi|zuHause3: vehicles don't take part in graphs at all. Orders do
07:47<Eddi|zuHause3>or passenger and mail trains
07:47<blathijs>Just ignore the edges for other cargo types when traversing
07:47<Celestar>blathijs: it will slow down pathfinding, because the pathfinder will have to read out the "cargotype" property for every single edge it traverses
07:48<blathijs>By using a mask for cargo types, you can probably save a lot of memory for multiple cargotype trains
07:48<Celestar>blathijs: remember that space is not an issue, speed is.
07:48<Eddi|zuHause3>as i said previously, i'd worry for speed more than memory
07:48<@peter1138>Dependds how important saving memory is over speed.
07:48<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
07:49<Celestar>peter1138: The graph takes O(Stations + Routes) elements.
07:49<Celestar>even with 1000 stations and 4000 routes, thats 5000 elements
07:49-!-planetmaker [] has joined #openttd
07:49<Celestar>with like 20 bytes per element, we have 100k
07:49<@peter1138>So by splitting them you 'waste' 1000 elements on stations each time
07:50<@peter1138>Seems reasonable.
07:50<Celestar>peter1138: yes, but the station elements are much smaller than the routes elements, since they don't not have properties
07:50<@peter1138>What you want is a graph that can reuse the station elements ;)
07:51<blathijs>ie, have a single list of vertices, but only duplicate the adjacency lists
07:51<Eddi|zuHause3>chances are, for each separate cargo network, only a small fraction of the stations are actually used
07:51<Celestar>blathijs: go rewrite the boost graph library :)
07:51<@peter1138>Celestar, well, we may end up doing that yet ;)
07:51<blathijs>Celestar: This is what I meant when I said "are you sure you want to use boost?" :-p
07:51<Celestar>peter1138: possibly (=
07:51<Celestar>blathijs: unless you come up with a better system, yes (=
07:52<Celestar>I still vote for first getting this to work with passengers.
07:52-!-planetmaker [] has quit []
07:52-!-pm|away is now known as planetmaker
07:52<Celestar>extended the thing via multiple graphs is really really really straightforward
07:52<Celestar>adding the cargotype as edge property is even more straightforward
07:53<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
07:53<Celestar>(except for an additional check-function for the dijkstra)
07:53<blathijs>But yeah, getting something working first, using boost, really sounds like the best way to go
07:53<@peter1138>Well... vertex list == station pool ;)
07:53<blathijs>peter1138: even better!
07:54<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 :-)
07:54<Celestar>peter1138: I _might_ have an idea about the remove_edge_if
07:55<@peter1138>Celestar, I've copied an example... and it doesn't work D:
07:55<@peter1138>But what's your idea?
07:55<Celestar>peter1138: which one .. the one with the "TruePredicate()" ? (=
07:55<Celestar>peter1138: I'm just checking it.sec
08:00<Celestar>peter1138: me failed. What's your example you have?
08:01<Celestar>peter1138: have you tried compiling it?
08:02<Eddi|zuHause3>,%2011.%20Jan%201972.png <- the existing version with the stations as squares looks cleaner, i think
08:02<Eddi|zuHause3>the nodes are more visible that way
08:10<Eddi|zuHause3>,%202.%20Okt%201940.png <- comparison [different network]
08:13<@peter1138>Mine was just a quick and dirty hack, you know :p
08:13<Eddi|zuHause3>yeah, sure ;)
08:13<Celestar>one that took like 25 lines of code (=
08:13<Celestar>peter1138: so is the edge removed or not?!
08:13-!-Yexo_ [] has joined #openttd
08:13-!-Yexo is now known as Guest92
08:13-!-Yexo_ is now known as Yexo
08:14<@peter1138>no... doesn't compile yet :p
08:15<Celestar>I mean with remove_edge and the loop
08:15<@peter1138>sometimes it does
08:15<@peter1138>but not always
08:17-!-thgergo [] has joined #openttd
08:18-!-glx [] has joined #openttd
08:18-!-mode/#openttd [+v glx] by ChanServ
08:19<Celestar>man how do I NOTICE that an edge is actually removed from the graph or not :S
08:20<@peter1138>Did you apply my minimap patch?
08:20<Celestar>no I didn't. There must be some way inthe debugger :P
08:20<Celestar>SOME way
08:20-!-Guest92 [] has quit [Ping timeout: 480 seconds]
08:21-!-Wezz6400 [] has quit [Ping timeout: 480 seconds]
08:22-!-Yexo_ [] has joined #openttd
08:22-!-Yexo is now known as Guest93
08:22-!-Yexo_ is now known as Yexo
08:24-!-Yexo_ [] has joined #openttd
08:24-!-Yexo [] has quit [Read error: Connection reset by peer]
08:25-!-Yexo [] has joined #openttd
08:25-!-Yexo_ [] has quit [Read error: Connection reset by peer]
08:25-!-DJNekkid [] has quit [Read error: Connection reset by peer]
08:26-!-DJNekkid_ [] has joined #openttd
08:26-!-DJNekkid_ is now known as DJNekkid
08:26-!-Yexo_ [] has joined #openttd
08:27-!-Guest93 [] has quit [Remote host closed the connection]
08:27-!-rortom [] has quit []
08:34-!-Yexo [] has quit [Ping timeout: 480 seconds]
08:34<Lachie>Celestar: may I?
08:35<Celestar>peter1138: error found
08:35<Celestar>peter1138: updating
08:38<Celestar>peter1138: <= should be working
08:40<Celestar>how does one download a diff from mercurial?!
08:41<Eddi|zuHause3>click on "raw" on the top of the page
08:41-!-Gekz [] has quit [Read error: Connection reset by peer]
08:42*peter1138 tests the relevant change
08:42<Celestar>peter1138: two changes (=
08:43<@peter1138>Works perfectly :D
08:43<@peter1138>Eddi|zuHause3, and I've updated the map with black edges ;)
08:44<Celestar>peter1138: it does? :D
08:44<Celestar>mesa good (=
08:44<@peter1138>The triangle test works, anyway ;)
08:45<Celestar>peter1138: good :P
08:45-!-welshdragon [] has joined #openttd
08:45-!-Wezz6400 [] has joined #openttd
08:46-!-Yexo_ [] has quit [Ping timeout: 480 seconds]
08:46-!-welshdragon [] has quit [Read error: Connection reset by peer]
08:46<@peter1138>Hmm, I got it confused by changing order types but I didn't apply all the patch.
08:46-!-welshdragon [] has joined #openttd
08:48<Celestar>peter1138: order types?
08:48<Celestar>peter1138: what order types?
08:48-!-GoneWacko [] has quit []
08:48<@peter1138>no load/no unload
08:49<@peter1138>but the rest of your patch has stuff relating to that
08:53<@peter1138>Yes, looks like it's fixed now.
08:53-!-Noetloj [] has joined #openttd
08:53<Celestar>heh :D
08:54<Celestar>noload/nounload/transfer shouldn't be used with destinations anyway imho
08:54-!-Vikthor [] has joined #openttd
08:54<@peter1138>it's possible to get it confused
08:54<Celestar>how ?
08:54<@peter1138>when switching from no load to no unload
08:55<Eddi|zuHause3>i really think those should both be allowed simultaneously...
08:55<Celestar>it's the same as "go via"
08:56<Eddi|zuHause3>no, it still stops
08:56<Celestar>but does nothing?
08:56<Celestar>the purpose being?
08:56<Eddi|zuHause3>but it can turn around or wait for timetables
08:57<Celestar>peter1138: I might have messed things up in the flags (routing.cpp:338 and such)
08:59<@peter1138>if you have no load on
08:59<@peter1138>then switch to no unloading
08:59<@peter1138>it doesn't see that it can now load
09:00<@peter1138>if you then toggle no load on and off it goes back to how it should be
09:00<Celestar>newload = (OrderLoadFlags)(newload & ~OLFB_NO_LOAD);
09:01<Celestar>this should do that, right?
09:06<Celestar>it's the wrong operator
09:07<Celestar>it should be ==s instead of !=s in the expression
09:07<Celestar>peter1138: change the two operators, and try again please
09:07<@peter1138>Doing so.
09:10<@peter1138>That seems better.
09:11-!-jordi [] has quit [Read error: Connection reset by peer]
09:11<Celestar>hm ...
09:12<Celestar>peter1138: I really really hope we can live without storing the RouteNetwork in the savegame. That'd save us a LOT of hassle
09:13<@peter1138>Well as long as these little niggles are sorted out it should be possible.
09:13<planetmaker>Celestar: how would a joining client then know about the current state?
09:13<@peter1138>The routing information is all there anyway.
09:13<@peter1138>Technically you could just rebuild from scratch every time it is changed...
09:14<Celestar>planetmaker: all the information we have is, as peter1138 sais, already in the order list.
09:14<Eddi|zuHause3>planetmaker: in the worst case, the cache is cleared and rebuilt on client join [like with yapf]
09:14<Celestar>planetmaker: the whole routenetwork does nothing else then reinterpreting the order data
09:14<@peter1138>Eddi|zuHause3: That never happened.
09:14<planetmaker>ok, thx. Sorry, if it was a stupid question :)
09:15<Eddi|zuHause3>peter1138: ?
09:15<@peter1138>There was never any invalidate-on-client-join system.
09:15-!-Belugas_Gone is now known as Belugas
09:15<dih>hello Belugas
09:16-!-jordi [] has joined #openttd
09:16<Celestar>planetmaker: there are no stupid questions (=
09:16<planetmaker>:) That's a dangerous statement, Celestar :P
09:17<@peter1138>Right, all my changes from Celestar are in hg, along with that improved display.
09:17<planetmaker>peter1138: that map looks interesting :). what does square size indicate?
09:17<Eddi|zuHause3>peter1138: are you sure? i thought i have read a commit like that
09:17<@peter1138>planetmaker, number of passengers waiting.
09:17<Celestar>peter1138: can I check out your stuff somehow?
09:18<@peter1138>planetmaker, almost exactly the same as that other paxdest patch.
09:18<planetmaker>ah, ok. wouldn't passenger throughput a better indicator?
09:18<@peter1138>Throughput is not an available statistic.
09:18<planetmaker>:) I know :P
09:18<Celestar>peter1138: I still have a passenger and train throughput patch
09:18<Celestar>peter1138: it's agaist revision 25 or something :P
09:19<@peter1138>Celestar: I think you can clone it with hg clone hg://restofurl
09:19<Celestar>with a nice GUI that lists the number of in, out and transfer items
09:19<@peter1138>But I don't know. It may be too large :)
09:19<Celestar>peter1138: will try
09:19<@peter1138>Or I can move my repository to a server on a fast connection.
09:19<Celestar>peter1138: what package is "hg" part of?
09:21-!-welshdragon [] has quit [Quit: Leaving]
09:21-!-welshdragon [] has joined #openttd
09:22-!-venus214 [] has joined #openttd
09:23-!-jordi [] has quit [Read error: Connection reset by peer]
09:24-!-jordi [] has joined #openttd
09:24<@peter1138>hmm, looks like buoys appear in the routemap
09:27<Celestar>peter1138: well, yes
09:27<Celestar>peter1138: somehow forgot them
09:27-!-tokai [] has quit [Ping timeout: 480 seconds]
09:28<venus214>hi.. any news about the diagonal level thing?
09:28-!-tokai [] has joined #openttd
09:28-!-mode/#openttd [+v tokai] by ChanServ
09:30<Ammler>venus214: did you play with 0.6 ?
09:30<Ammler>well, then you might think about something else :-)
09:31<Celestar>Ammler: he ment something else (=
09:31<Ammler>ah, the patch from roujin?
09:32<Celestar>peter1138: downloading
09:32<venus214>im talking about this -->
09: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.
09:39<Celestar>peter1138: <= removed buoy adding
09:43*peter1138 tests
09:45-!-jordi [] has quit [Read error: Connection reset by peer]
09:46-!-jordi [] has joined #openttd
09:47<Noetloj>Hey guys. Can anyone explain this?
09:47<Noetloj>building a oil refinery in sub-tropic, it errors with must be built ABOVE the >SNOW< line
09:47<@Belugas>hello all
09:47<Noetloj> sub-tropic?
09:47*Noetloj is confuzzled.
09:48<Celestar>should possibly read "cannot be built in desert"
09:48<Noetloj>Still a bug then :p
09:49<Noetloj>and Celestar: you're right.
09:49<Celestar>peter1138: is that better? (with the buoys)
09:49<Noetloj>I built it so that one tile is on the tropic ground.
09:49<Noetloj>it worked then
09:49<Noetloj>so it's a textual error for you guys to work out :p
09:51<Celestar>peter1138: coll
09:52<Celestar>peter1138: I gotta go in about 10 minutes. What should be our next steps?
09:52<@peter1138> < useful?
09:52<@peter1138>coloured lines instead of just white...
09:52<Celestar>colored by?
09:53<Celestar>I was wondering: display only for your company, and color by vehicle type?
09:53<@peter1138>That's double, but what if a route is served by more than one type?
09:53<Progman>coloring by company is imo useless unless you used sth. like the shared infrastructure patch
09:53<Celestar>peter1138: good question. parallel lines?
09:54<@peter1138>Hmm, actually I can handle that in ListAdjacancies.
09:54<@peter1138>Progman, probably
09:55<Eddi|zuHause3>the colouring could depend on the selected map view :)
09:55<Celestar>peter1138: will wondering what the next steps should be
09:55<@peter1138>Pathfinding works, doesn't it?
09:56<Celestar>peter1138: yes
09:56<Celestar>peter1138: use FindNextHop
09:56<Celestar>StationID Routing_t::FindNextHop(StationID from, StationID to);
09:56<Celestar>I haven't tested it too extensively yet
09:56<@peter1138>Then we need to add destinations (perhaps randomly for testing)
09:56<Eddi|zuHause3>if building and traversing the network works now, i'd say implement a (stupid) assignment of destinations for cargo
09:56-!-jordi [] has quit [Read error: Connection reset by peer]
09:56<@peter1138>and then code the transfers
09:57<@peter1138>Eddi|zuHause3, ding :D
09:57<Celestar>(-d routing=7 is helpful possibly)
09:57<Celestar>peter1138: randomly sounds great
09:57-!-bleepy [] has joined #openttd
09:57<Celestar>peter1138: the transfers will mostly reuse existing unloading code and Routing->StayOnBoard
09:58<Celestar>bool Routing_t::StayOnBoard(const Vehicle *v, StationID to);
09:58<Celestar>StayOnBoard basically replaces the whole transfer/unloading stuff.
09:59<Celestar>when people get off, unload if (ultimate destination == current destinations), else transfer
10:00<Progman>cargo doesn't get unloaded on buoyes, do they? there was such a bug in other paxdest patches ;)
10:00<Celestar>so we can use the entire codebase, just don't read the order flags, but ask Routing->Something.
10:00<@peter1138>Progman, we've covered that one ;)
10:00<Celestar>Progman: we've already prevented that (=
10:00-!-Gekz [] has joined #openttd
10:00<Celestar>thanks to peter1138
10:00<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?
10:01<Progman>venus214: the square tool
10:01<Progman>venus214: it is placed on the e-key (if you have the leveling toolbar open)
10:01<Celestar>peter1138: we first need a StationID to; member of the cargopackets apparently
10:02<@peter1138> < current player only, then
10:02<@peter1138>Celestar: yeah, that's easy
10:02-!-Gekz_ [] has quit [Ping timeout: 480 seconds]
10:03<venus214>Progman: but that isnt working if you want to do it diagonally or horizontally..
10:03-!-Nev [] has quit [Ping timeout: 480 seconds]
10:03<@peter1138>Celestar: In theory that's our only savegame change :D
10:03<Progman>no, it doesn't
10:03*peter1138 adds StationID target;
10:03<@peter1138>shorter than destination, longer than to.
10:04<Celestar>peter1138: well, there'll be some other, minor things
10:04<Celestar>peter1138: maybe for gui/statistics
10:04<venus214>are you planing ti implement this feature in the future? :)
10:04<Celestar>venus214: no, rather we're trying to implement it presently (=
10:04-!-Roujin [] has quit [Quit: Want to be different? Try HydraIRC -> <-]
10:04<@peter1138>I think venus214 is talking about diagonal terraforming.
10:05<Celestar>er ok
10:05<Celestar>YES! I need it! :P
10:05-!-jordi [] has joined #openttd
10:05<venus214>i need it too, so please implement it :)
10:05<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
10:06-!-grumbel [] has joined #openttd
10:06<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 ;)
10:07<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
10:07<Celestar>Eddi|zuHause3: much Much MUCH later
10:08<Celestar>I've gotta go
10:08<Celestar>cu tomorrow
10:08<Eddi|zuHause3>yes ;)
10:08<Celestar>peter1138: have fun
10:10<@peter1138>Eddi|zuHause3, yeah, that basically boils down to 'passengers should prefer not to change'
10:10<Eddi|zuHause3>peter1138: not entirely
10:11<Eddi|zuHause3>if they can get to the destination much faster by transferring inbetween, they should do that
10:12<@Belugas>but but but... it's not realistic!
10:12<@Belugas>i like it then :D
10:12<@peter1138>Eddi|zuHause3, the pathfinding supports costs and penalties...
10:12<Eddi|zuHause3>but i think that can be sufficiently handled by considering timetables
10:12<Eddi|zuHause3>you can calculate an ETA from the timetable
10:13<Eddi|zuHause3>yes, i kinda expected that :p
10:14<blathijs>That does mean that the cost of long distance train should decrease depending on it's ETA
10:14<blathijs>Which I'm afraid is quite some work (in terms of processing power)
10:14<Eddi|zuHause3>the ETA for each order entry can be cached in the timetable, i believe
10:15<blathijs>Yeah, that's probably true
10:15<Eddi|zuHause3>if you do not consider delays, this should only be updated once per visit of the station
10:15<Eddi|zuHause3>ETA = ETA+round trip time
10:16<blathijs>Which is quite acceptable
10:16<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
10:16-!-Roest [] has quit [Remote host closed the connection]
10:17<Progman>< Eddi|zuHause3> ETA = ETA+round trip time
10:17<Progman>sounds like reimplement TCP in openttd ;)
10:18<@Rubidium>it's more UDP
10:18<@Rubidium>there's no retransmission of passengers
10:18<blathijs>Rubidium: Since trains can get lost at any time? :-)
10:19<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.
10:19<Eddi|zuHause3>wait... they don't respawn when they were in a crash?
10:20<Eddi|zuHause3>blathijs: an edge is from an order, multiple vehicles can share the same order
10:20<Eddi|zuHause3>so each vehicle has a different ETA
10:20<blathijs>Oh, right
10:21<blathijs>I would say that when multiple vehicles share an order, there should be an edge for every vehicle
10:21-!-jordi [] has quit [Read error: Connection reset by peer]
10:21<Eddi|zuHause3>you'll have to discuss that with celestar ;)
10:22-!-jordi [] has joined #openttd
10:22*blathijs pokes Celestar for a bit
10:29<@peter1138>That would involve more edges.
10:30<Eddi|zuHause3>peter1138: you need to have support for parallel edges anyway, do a few more parallel edges really change anything?
10:31<@peter1138>Well, yes.
10:33<Eddi|zuHause3>well... i'll keep out of that discussion ;)
10:34<@peter1138>Say you have 20 trains on a shared order
10:34<@peter1138>You'll have 20 times more adjacancies
10:35<Eddi|zuHause3>that might indeed not be the most optimal solution ;)
10:35-!-DJNekkid [] has quit [Ping timeout: 480 seconds]
10:36<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]
10:36<Eddi|zuHause3>then that ETA can be stored on the edge
10:36<Eddi|zuHause3>somethin similar must already be done with the automatic vehicle spacing
10:37-!-jordi_ [] has joined #openttd
10:39-!-jordi [] has quit [Ping timeout: 480 seconds]
10:44<@peter1138>Eddi|zuHause3, we could just assume passengers are stupid and don't pick the best route? ;)
10:55-!-Yexo [] has joined #openttd
11:03-!-Purno [] has joined #openttd
11:04<@peter1138>LoadUnloadVehicle needs quite a lot of modification
11:04<@peter1138>On the other hand, I shall assume that the other paxdest patch managed it...
11:09*SpComb rewrites OpenTTD using pygame
11:15-!-GoneWacko [] has joined #openttd
11:18<Eddi|zuHause3>what are the chances of having a 4-lane road with embedded tram? [2 tiles wide]?
11:18<CIA-5>OpenTTD: smatz * r13858 /trunk/src/openttd.cpp: -Fix: buffer overflow for too long filename supplied as '-g' parameter
11:18-!-frosch123 [] has joined #openttd
11:27<Ammler>Eddi|zuHause3: if you build on oneway roads a tramtrack, you got only one
11:28<@peter1138>Eddi|zuHause3, slim.
11:31<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
11:34-!-GoneWacko [] has quit [Quit: leaving]
11:45<blathijs>Eddi|zuHause3: Storing the lowest ETA and updating that when the vehicle with that lowest ETA arrives sounds like a fine plan
11:45<blathijs>Eddi|zuHause3: Though currently, speed of a vehicle is also stored on an edge, but that can probably be replaced with ETA
12:00-!-Doorslammer [] has quit []
12:01-!-ecke [~ecke@] has joined #openttd
12:04-!-rortom [] has joined #openttd
12:05-!-welshdragon is now known as welshdra-gone
12:09-!-N1ghtCrawler [] has quit [Ping timeout: 480 seconds]
12:23-!-rortom [] has quit []
12:23-!-welshdra-gone is now known as welshdragon
12:34-!-Wezz6400 [] has quit [Ping timeout: 480 seconds]
12:45-!-grumbel [] has quit [Quit: Client exiting]
12:51-!-M4rk [] has joined #openttd
12:51-!-M4rk is now known as Mark
12:53-!-mikl [] has quit [Quit: Leaving...]
13:00-!-Wolf01 [] has joined #openttd
13:01<@Belugas>hello mister Wolf01
13:01-!-Wezz6400 [] has joined #openttd
13:02<Wolf01>hello chief Belugas
13:02<Wolf01>hi SmatZ
13:03<Wolf01>oh, UT3 time
13:10<Phantasm>Belugas: How is the fix going?
13:14<@Belugas>during holidays? NEVAR :)
13:19<@Belugas>but apart that, pretty much stalled on the same problems
13:21-!-Deathmaker [] has joined #openttd
13:33-!-GoneWacko [] has joined #openttd
13:37<@Belugas>Phantasm, don't give up hope :)
13:37<@Belugas>it will get solved
13:37<@Belugas>don't know when :)
13:37<@Belugas>nor how (currently) ;)
13:40<@peter1138>What needs solving?
13:41<@Belugas>how to deal with the enormous amount of news messages that will be generated
13:41<@Belugas>when the industries are going to be mass-created monthly
13:42<@Belugas>that and of course, the production changes, which are way more commun :)
13:43-!-Brianetta [] has quit [Quit: Tschüß]
13:45-!-nicfer [~Administr@] has joined #openttd
13:46-!-Klanticus [~Klanticus@] has joined #openttd
13:58-!-Zealotus [] has quit [Ping timeout: 480 seconds]
14:03<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
14:06<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]
14:08<blathijs>Eddi|zuHause3: Though speed and ETA are hard to compare
14:08<plakkertjes>why isnt there more than one intro screen
14:09<Eddi|zuHause3>blathijs: well, you could do something like air-distance/speed
14:09<blathijs>Eddi|zuHause3: what is this timetable thing? Is that explicit? Is that a current feature?
14:09<blathijs>Eddi|zuHause3: Yeah, true
14:09<Eddi|zuHause3>timetables are available from the order window, that has been in trunk for quite a while
14:10<blathijs>I haven't been actually playing openttd for years now, and missed it in here :-)
14:20-!-Zealotus [] has joined #openttd
14:21-!-Vikthor [] has quit [Quit: Leaving.]
14:24<Celestar>back for a few
14:25<Celestar>peter1138: how's progress
14:26<Eddi|zuHause3>we were discussing strategies how to use timetables for weighting of edges
14:30<Celestar>Eddi|zuHause3: not at all for the time being
14:30<Celestar>Eddi|zuHause3: the pathfinder doesn't take that into account yet.
14:30<Celestar>Eddi|zuHause3: currently only distance and number of hops, and I'm not even sure about the latter
14:30<Eddi|zuHause3>yeah, i'm talking 3 steps ahead :)
14:32-!-welshdragon [] has quit [Quit: Leaving]
14:33-!-fmauNekAway is now known as fmauNeko
14:34<fmauNeko>plop :)
14:35-!-Zuu [] has joined #openttd
14:37*Zuu waiting for a slow Centos computer to update it's pakages so he can install libsdl-devel ... :(
14:37-!-welshdragon [] has joined #openttd
14:38<Celestar>Eddi|zuHause3: take one step after the other
14:38<Celestar>Eddi|zuHause3: all the weighing is nothing else than writing a custom visitor function for the pathfinder
14:38<Eddi|zuHause3>yes, but it's useless to think about weights that you have to loop the entire map to calculate ;)
14:39<Eddi|zuHause3>so we were searching for variables that are easy to cache
14:40-!-welshdragon2` [] has joined #openttd
14:41<Eddi|zuHause3>but you should be thinking about the first step now, not about the third ;)
14:41-!-GoneWacko [] has quit [Quit: leaving]
14:41-!-welshdragon [] has quit [Read error: Connection reset by peer]
14:41-!-welshdragon2` is now known as welshdragon
14:42<Celestar>Eddi|zuHause3: it doesn't matter
14:43<Celestar>Eddi|zuHause3: the cache will only be rebuilt on order modification
14:43<Celestar>Eddi|zuHause3: so timetable, maximum speed are options
14:43<Celestar>Eddi|zuHause3: average travel times are not
14:43<Celestar>I'll be back in 30
14:43<Celestar>with the alter version
14:47<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]
14:48<Eddi|zuHause3>this data would be updated every time a vehicle arrives at a station
14:49<CIA-5>OpenTTD: truebrain * r13860 /branches/noai/bin/ai/regression/regression.txt: [NoAI] -Fix r13857: forgot to update regression :$
14:50<@peter1138>Celestar, I added random destinations but not much else. Decided to work on making the minimap show vehicle type
14:54-!-bowman [] has quit [Read error: Connection reset by peer]
14:54-!-bowman [] has joined #openttd
14:57<blathijs>Celestar: The above would result in passengers waiting a bit for faster train, if it arrives not too much later
14:57-!-tom0004 [~0004tom@] has joined #openttd
15:00<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)
15:04-!-Deathmaker [] has quit [Read error: Connection reset by peer]
15:05-!-GoneWacko [] has joined #openttd
15:06-!-Purno [] has quit [Read error: Connection reset by peer]
15:12-!-ARock [] has joined #openttd
15:15-!-plakkertjes [] has quit [Ping timeout: 480 seconds]
15:33-!-rortom [] has joined #openttd
15:34-!-nicfer [~Administr@] has left #openttd []
15:38<Celestar>peter1138: I've added stuff to determine whether a cargopacket should board/deboard
15:39<blathijs>Bit harsh to talk about passengers as "a cargopacket"
15:39-!-venus214 [] has quit []
15:39<blathijs>Those are real humans you're talking about, man!
15:40<Celestar>blathijs: in the airline business, they are sometimes called SLF
15:41<Celestar>which is short for "self loading freight"
15:52<Celestar>hm ...
15:53<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)
15:59<Eddi|zuHause3>static inline bar() { foo() }
16:00<Celestar>mh :S
16:00<Eddi|zuHause3>the least stupid that went through my mind...
16:00<Eddi|zuHause3>everything else includes pointer magic...
16:02<rortom>the c++ way would be to derivate the class and implement calling both methods?
16:03<Eddi|zuHause3>templates could work ;)
16:03<@Belugas>might be easier if the need was expressed in context :)
16:07-!-Dred_furst [] has quit [Read error: Connection reset by peer]
16:13<Celestar>well, just forget it, it was a rethorical question :P
16:15-!-mikl [] has joined #openttd
16:17<@peter1138>Hmm, this is not right :o
16:17<Celestar>peter1138: what is?
16:19<Celestar>peter1138: <= latest version
16:19<Celestar>peter1138: has a function that answers the question what do with a cargopacket and a vehicle (=
16:20<Celestar>do we have latexers among us?
16:20<Ammler>Celestar: Mucht
16:21<Mucht>yes here
16:21<Mucht>I am indeed
16:21<Celestar>Mucht: do you use bibtex?
16:21<Mucht>I'm writing my doctoral thesis
16:21<Mucht>impossible without bibtex ;-)
16:22<Celestar>Mucht: heh. I'm about 3 months away, but I have another problem
16:22<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?
16:22<Celestar>also, "edition" is not translated to the native language (in this case, ngerman)
16:23<Mucht>In fact, the bibliography should not be touched "by hand". there are many different bibliographystyles, which handle the layout
16:23<Mucht>I assume, for your second problem, there is a german bibliographystyle
16:24<Celestar>Mucht: yeah. but what style to use or how to modify the style. the documentation of bibtex frankly sucks
16:24<Mucht>actually, I do not recommend you to argue about such minor problems like edition instead of auflage
16:25<Mucht>such small problems lead to a huge ammount of work to fix with latex
16:25<Mucht>if you are writing your thesis in english, I recommend you to use edition, even for german books
16:25<Mucht>(I do so, actually)
16:25<Mucht>for your question about bibliographystyles...
16:26<Celestar>Mucht: it's not my thesis :P
16:26<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
16:27<Mucht>you can, off course, edit your own stylefile. Have a lot of fun with that ;-)
16:28<Mucht>you use jabref for bibtex editing?
16:29<Mucht>Celestar: <- there you got some 50 style examples
16:31<Celestar>Mucht: I certainly use bibtex
16:31<Celestar>er jabref
16:32<Celestar>we've got a departmental jabref database with 12000+ entries
16:32<Celestar>which is, OF COURSE, not stored as sql database, but as text file :S
16:32<Mucht>sounds interesting
16:32*Belugas goes home. see ya two more row
16:33-!-DaleStan_ [] has joined #openttd
16:33-!-DaleStan is now known as Guest139
16:33-!-DaleStan_ is now known as DaleStan
16:33<Celestar>peter1138: so are we going on tomorrow (but I only have an hour or so)
16:33<rortom>thanks for the bibtex styles :)
16:33<Mucht>Celestar: is it possible that you want to do an "Inbook" entry, for your question of how to display pages?
16:33<Mucht>np rortom ;-)
16:35<Celestar>Mucht: possible. apparently my jabref misses such a button.
16:35-!-ARock [] has quit []
16:35<Mucht>Celestar: no, thats an entry type
16:35<Celestar>Mucht: I know, but I get a choice when entering a new item
16:36-!-frosch123 [] has quit [Remote host closed the connection]
16:36<Celestar>thanks Mucht that's it afaik
16:36*Celestar finishes this and goes back to coding
16:36<Mucht>np Celestar
16:36<Celestar> std::vector<VertexDescriptor> dump; this->hopcache.push_back(dump);
16:36<Celestar>any idea to simplify this?
16:38<rortom>just the line?
16:38<Noldo>that's not even bad
16:38<Celestar>yeah, but dump is totally useless
16:39-!-Guest139 [] has quit [Ping timeout: 480 seconds]
16:42-!-Born_Acorn is now known as I_am_Born_Acorn
16:45-!-I_am_Born_Acorn is now known as Born_Acorn
16:46-!-Zahl [] has quit [Quit: (~_~]"]
16:46-!-Zuu [] has quit [Quit: Leaving]
16:48*peter1138 returns.
16:49<@peter1138>Just updated my repo with that last changes.
16:49*Prof_Frink smashes peter1138's return to the far corner of the court
16:49<Celestar>peter1138: <= latest version, some minor cleanups
16:49<Celestar>cu tomorrow
16:49<@peter1138>More? Bah! ;)
16:50<@peter1138>Okay, night night Celestar
16:51<@peter1138>Ah, just using this-> in a few places...
16:56-!-Wolf01 [] has quit [Quit: Once again the world is quick to bury me.]
16:58<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?
17:01<Eddi|zuHause3>peter1138 said he had a modification that assigns random destinations
17:02<Eddi|zuHause3>as your luck goes... the link just went out of my buffer :p
17:10<@peter1138>It assigns destinations, but it doesn't yet perform routing.
17:12-!-Wezz6400 [] has quit [Ping timeout: 480 seconds]
17:14<@peter1138>The route network for pile transport is a bit... mad.
17:15*Noetloj assigns peter1138 to the destination of /dev/null/
17:15<Noetloj>via /dev/ obviously.
17:15<Prof_Frink>silly Noetloj!
17:16<Prof_Frink>/dev/null is not a directory!
17:18<Noetloj>it still deletes things.
17:18<Noetloj>Lets just say I assigned him to the bin, he's dead now, end of.
17:19-!-grumbel [] has joined #openttd
17:23-!-Wezz6400 [] has joined #openttd
17:25-!-welshdragon [] has quit [Read error: Connection reset by peer]
17:25-!-welshdragon [] has joined #openttd
17:26-!-Brianetta [] has joined #openttd
17:26-!-Wezz6400 [] has quit []
17:37<@peter1138>Celestar, some issues with aircraft orders :o
17:38-!-GoneWacko [] has quit [Quit: Lost terminal]
17:41<@peter1138>Hmm, or any order.
17:44<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).
17:48<rortom>"train control patch"?
18:12<@peter1138>Hmm, shuffling orders around still breaks things :(
18:21<@peter1138>Ah ha.
18:21-!-bleepy [] has quit [Read error: Connection reset by peer]
18:21-!-bleepy [] has joined #openttd
18:22-!-a1270 [] has quit [Quit: a1270]
18:22-!-a1270 [] has joined #openttd
18:26-!-a1270 [] has quit []
18:27<@peter1138>Order insertion and removal going haywire :o
18:28<@peter1138>Dunno if it's the routing code or actual orders going wrong, though.
18:30-!-a1270 [] has joined #openttd
18:31-!-stillunknown [] has quit [Ping timeout: 480 seconds]
18:37-!-GoneWacko [] has joined #openttd
18:53-!-KillaloT [] has quit [Quit: HydraIRC -> <- IRC for those that like to be different]
18: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
19:01<Eddi|zuHause3>frosch had that same question, i believe
19:07-!-bleepy [] has quit [Ping timeout: 480 seconds]
19:10<CIA-5>OpenTTD: smatz * r13863 /trunk/config.lib: -Fix (r13852): make the nightly compile again
19:10-!-plakkertjes [] has joined #openttd
19:15-!-welshdragon [] has quit [Read error: Connection reset by peer]
19:15-!-welshdragon [] has joined #openttd
19:23-!-welshdragon [] has quit [Read error: Connection reset by peer]
19:23-!-welshdragon [] has joined #openttd
19:31-!-plakkertjes [] has quit [Ping timeout: 480 seconds]
19:35-!-welshdragon is now known as welshdra-gone
19:37<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.
19:40-!-fmauNeko is now known as fmauNekAway
19:41-!-fmauNekAway is now known as fmauNeko
19:52-!-DJNekkid_ [] has joined #openttd
19:52-!-DJNekkid_ is now known as DJNekkid
20:04-!-Dred_furst [] has joined #openttd
20:06-!-elmex [] has quit [Remote host closed the connection]
20:19-!-Brianetta [] has quit [Quit: Tschüß]
20:20-!-DaleStan is now known as Guest164
20:20-!-DaleStan [] has joined #openttd
20:25-!-Dred_furst [] has quit [Quit: Leaving]
20:25-!-Guest164 [] has quit [Ping timeout: 480 seconds]
20:26-!-Progman [] has quit [Remote host closed the connection]
20:34-!-Eddi|zuHause2 [] has joined #openttd
20:40-!-Eddi|zuHause3 [] has quit [Ping timeout: 480 seconds]
21:00-!-GoneWacko [] has quit []
21:02-!-Touqen_ [] has joined #openttd
21:04-!-Touqen [] has quit [Ping timeout: 480 seconds]
21:13-!-Klanticus [~Klanticus@] has quit [Remote host closed the connection]
21:47-!-grumbel [] has quit [Quit: Client exiting]
21:55-!-fmauNeko is now known as fmauNekAway
21:57-!-glx [] has quit [Quit: bye]
22:10-!-Noetloj [] has quit [Ping timeout: 480 seconds]
22:11-!-neli [micha@] has quit [Ping timeout: 480 seconds]
22:12-!-rortom [] has quit []
22:30-!-neli [micha@] has joined #openttd
22:48-!-Yexo [] has quit [Read error: Connection reset by peer]
22:48-!-Yexo_ [] has joined #openttd
23:00-!-TinoM| [] has joined #openttd
23:07-!-TinoM [] has quit [Ping timeout: 480 seconds]
23:34-!-DaleStan_ [] has joined #openttd
23:34-!-DaleStan is now known as Guest199
23:34-!-DaleStan_ is now known as DaleStan
23:39-!-bowman [] has quit [Read error: Connection reset by peer]
23:39-!-bowman [] has joined #openttd
23:41-!-Guest199 [] has quit [Ping timeout: 480 seconds]
---Logclosed Tue Jul 29 00:00:25 2008