IRC logs for #openttd on OFTC at 2008-07-28
⏴ go to previous day
00:32:32 <ln> gah, finnish news sources are reporting that the Qantas 747 "lost several kilometers of altitude" because of the hole.
00:33:38 <Tefad> the dive was in response to the cabin depressurizing
00:33:52 *** Eddi|zuHause3 has joined #openttd
00:33:59 <ln> indeed, a response by the pilot(s).
00:35:03 <ln> but the wording in the news suggests the plane just fell several kilometers by itself because of the hole.
00:36:43 <ln> is this idiotism present in the news in other countries?
00:37:33 <ln> somehow i think it originates from the first article by e.g. BBC, where a random passenger said something about losing altitude.
00:40:14 <Rubidium> ln: idiotism can be found in all news
00:41:00 <Rubidium> like the "fact" that there is no CO2 in the air next to a big burning building
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: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 has joined #openttd
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:48 <peter1138> Celestar, so far we've used this->
06:34:08 <Ammler> Malawar: try a 2. signals
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: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:37 <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:44:18 <Celestar> what is that peter1138 ?
06:44:35 <peter1138> mercurial with your patch from last night applied
06:44:52 <peter1138> Although it looks totally different to hg.openttd.org :o
07:15:23 <Celestar> peter1138: so, what do you want me to do? :P
07:16:26 <peter1138> Well... finish it? ;)
07:19:09 *** GoneWacko has joined #openttd
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: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:15 <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 <blathijs> Celestar: You should be able to get away with writing just a handful of callbacks and have a working A* pathfinder
07:27:50 <Celestar> blathijs: boost has the pathfinders implemented
07:27:57 <Celestar> blathijs: you just need to call them
07:28:08 <blathijs> Ah, that is probably even easier then :-
07:35:39 <peter1138> I've been trying to use EdgeIterator... when it should actually be OutEdgeIterator
07:38:47 *** Doorslammer has joined #openttd
07:41:55 *** plakkertjes has joined #openttd
07:46:14 <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 has joined #openttd
07:49:53 <Celestar> it depends on the question whether you want me to improve it or not
08:06:17 <peter1138> This network map is quite a mess :D
08:06:47 <Celestar> peter1138: you mean like visually?
08:06:58 <peter1138> I've got it on the minimap
08:07:03 <Celestar> show me show me show me
08:07:47 *** Vikthor has joined #openttd
08:08:58 <Lachie> do you slave SATA drives?
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: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: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:22:21 <peter1138> I still haven't figured out how to export all this :o
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:26:24 <Celestar> or store it for each shared order list
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: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:20 <peter1138> ^ bit better looking
08:34:46 <Celestar> you have some nice transfer network there in the middle haven't you?
08:35:45 <peter1138> no trams, just trains and busses
08:35:55 <peter1138> plus a couple of long truck routes
09:07:40 <Noldo> if it works, we are happy
09:07:58 <Celestar> TIC/TOC spits out time in microseconds right?
09:08:00 *** stillunknown has joined #openttd
09:08:27 <Gekz> Celestar: is this evidence it works?
09:08:51 <Celestar> Gekz: it finds routes
09:08:55 <Gekz> so when will we see passenger destination in svn?
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:10:07 <Gekz> taking 15 years to get to 2.0
09:10:26 <Celestar> ok everyone I need a *LARGE* savegame
09:10:35 <Celestar> (I only have yapp stuff)
09:11:30 <Ammler> Celestar: coop archive
09:12:04 <Ammler> only trunk stuff there :-)
09:12:31 <Celestar> Ammler: just browsing them
09:13:33 <peter1138> Celestar, no, TIC/TOC spits out number of cycles.
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:16:20 *** KillaloT 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:19 <Celestar> it grows with O(n log n) afaik, which is about as good as it gets.
09:24:58 <Celestar> 0.1ms is not bad, assuming we cache/store the data somehow any only recompute on need
09:30:58 *** [1]plakkertjes has joined #openttd
09:33:10 <peter1138> Hmm, deleting a route doesn't seem to actually update the graph.
09:33:47 <peter1138> In RemoveRoute it just breaks if removing?
09:34:54 <peter1138> DEBUG(routing, 4, "Found edge with index %d. Removing now", from->index);
09:35:04 <peter1138> Doesn't... do anything.
09:35:21 <rortom> peter1138: are you working IRL? :p
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 *** [1]plakkertjes is now known as plakkertjes
09:37:25 <Celestar> peter1138: I'll make a new diff for ye in a minute
09:38:02 <peter1138> rortom: I'm on holiday at the moment :D
09:41:10 <Celestar> peter1138: you can play around with ComputeRoutes() as well
09:41:25 *** Yexo is now known as Guest80
09:46:50 <Celestar> can I pass a std::vector around by using a pointer?
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:33 <blathijs> and the former if you make foo accept a pointer, of course
09:53:02 *** Dred_furst has joined #openttd
09:54:13 * Celestar slaps himself with the save-before-compile-trout
09:55:23 <peter1138> Hmm, still not removed :o
09:56:14 <Celestar> there IS a remove_edge there now, is there?
09:56:20 *** Progman has joined #openttd
09:57:59 <peter1138> I think it's first up.
09:58:07 <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:01:12 <Celestar> peter1138: you should see the route being removed if things are split
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 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:41 <Celestar> the edge should be there
10:05:47 <Celestar> how big is that network?
10:06:11 <peter1138> however, i just tried it with a simple triangle
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:34 <peter1138> hmm, if i remove the orders completely its still there :o
10:08:13 <peter1138> only disappears when the stations are removed
10:09:11 <Celestar> will you try or want me to give it a shot
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:12:41 <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:52 <Celestar> Eddi|zuHause3: no, not yet
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: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: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:18 <Celestar> dbg: [routing] The next hop going from <Grenbury Lakeside> to <Grenbury Branch> is via <Grenbury Valley>
10:22:05 <Celestar> we can still implement that later I guess
10:24:41 *** Ammller has joined #openttd
10:25:25 *** Ammller is now known as Ammler
10:26:00 *** XeryusTC has joined #openttd
10:27:00 *** planetmaker has joined #openttd
10:27:28 *** planetmaker is now known as pm|away
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:33:35 * 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: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:48 <peter1138> I think it's something like the whole map done once every 256 ticks. Possibly.
10:38:58 <peter1138> TILELOOP_SIZE is 16, square it you get 256.
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: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:40 <peter1138> Does pathfinding need to be done for each of those at the start?
10:41:00 <Celestar> only when there's a vehicle to board
10:41:04 <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:53 <peter1138> Well it's always optional for those with slow computers.
10:42:53 <Celestar> not counting the cache updates
10:43:08 *** Brianetta 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: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:47:46 <Eddi|zuHause3> it could use a version number ;)
10:48:12 *** Wezz6400 has joined #openttd
10:48:21 * Celestar slaps Eddi|zuHause3.0
10:55:56 <Celestar> A vector can store a vector, right?
10:56:28 <Celestar> like std::vector<std::vector<int>> hopcash; ?
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:21 <peter1138> This route deleting...
10:59:51 <Celestar> peter1138: if you're really really good. you get remove_edge_if() to work
10:59:57 <Celestar> I've not yet managed to do so
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:31 <Eddi|zuHause3> or am i misunderstanding stuff ;)
11:04:28 <Noldo> how does paxdest system influence station rating?
11:06:57 <rortom> wanted to show you yesterday
11:07:30 <Roujin> rortom: are these displayed optional
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:55 <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:40 <rortom> thats a feature patch im working on
11:08:51 <rortom> to improve the station gui
11:09:22 <Gekz> cant the vehicles come up in a horizontal list first
11:09:31 <Gekz> like 1 Train - 9 road vehicles - 1 Aircraft
11:09:45 <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:10:05 <rortom> as i added the accept field
11:10:20 <rortom> its coded in some hours and is far from perfect :)
11:10:41 <rortom> you will have to smack me :|
11:11:05 <Gekz> your work will be pointless
11:11:11 <rortom> mh, what stats could be interesting also?
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:50 <Gekz> such as transferred this year, passed this year
11:11:56 <Gekz> displaying one part at a time
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:25 <rortom> thats what i also thought of
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: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: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: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:50 <Forked> yapp is really something :)
11:15:50 <rortom> someone knows the m&b screensaver?
11:16:34 <rortom> could work well with TTD's grf :)
11:17:47 <Gekz> there is no OpenTTD screensave
11:17:52 <Gekz> that would be awesome :D
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:53 <Eddi|zuHause3> i think they were aimed at windows...
11:23:35 <peter1138> Argh, it's too hot outside.
11:27:58 <Eddi|zuHause3> that's only 6 >s ;)
11:39:18 <Celestar> peter1138: yeah. I'm really curious WHAT qualifiers are discarded :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: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:24 <Celestar> peter1138: I don't think it should be inside the graph
11:46:39 <Eddi|zuHause3> yes, separate graphs seem reasonable
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: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:49 <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:16 <Celestar> even with 1000 stations and 4000 routes, thats 5000 elements
11:49:34 *** planetmaker has joined #openttd
11:49:34 <Celestar> with like 20 bytes per element, we have 100k
11:49:50 <peter1138> So by splitting them you 'waste' 1000 elements on stations each time
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:18 <Celestar> I still vote for first getting this to work with passengers.
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:52 <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:10 <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:01:37 <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:22 <Celestar> one that took like 25 lines of code (=
12:13:31 <Celestar> peter1138: so is the edge removed or not?!
12:13:40 *** Yexo is now known as Guest92
12:14:28 <peter1138> no... doesn't compile yet :p
12:15:31 <Celestar> I mean with remove_edge and the loop
12:17:50 *** thgergo has joined #openttd
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:22:28 *** Yexo is now known as Guest93
12:26:02 *** DJNekkid_ has joined #openttd
12:26:05 *** DJNekkid_ is now known as DJNekkid
12:35:48 <Celestar> peter1138: error found
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:42:34 * peter1138 tests the relevant change
12:42:46 <Celestar> peter1138: two changes (=
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:26 <peter1138> The triangle test works, anyway ;)
12:45:34 *** welshdragon has joined #openttd
12:45:34 *** Wezz6400 has joined #openttd
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 has joined #openttd
12:48:13 <Celestar> peter1138: order types?
12:48:19 <Celestar> peter1138: what order types?
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 has joined #openttd
12:54:19 <Celestar> noload/nounload/transfer shouldn't be used with destinations anyway imho
12:54:32 *** Vikthor has joined #openttd
12:54:40 <peter1138> it's possible to get it confused
12:54:50 <peter1138> when switching from no load to no unload
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:36 <Eddi|zuHause3> but it can turn around or wait for timetables
12:57:13 <Celestar> peter1138: I might have messed things up in the flags (routing.cpp:338 and such)
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: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: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:29 <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:46 <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:26 <peter1138> There was never any invalidate-on-client-join system.
13:15:44 *** Belugas_Gone is now known as Belugas
13:16:34 <Celestar> planetmaker: there are no stupid questions (=
13:16:50 <planetmaker> :) That's a dangerous statement, Celestar :P
13:17:12 <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: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: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:21:27 *** welshdragon has joined #openttd
13:22:48 *** venus214 has joined #openttd
13:24:45 <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:28:41 <venus214> hi.. any news about the diagonal level thing?
13:28:48 *** ChanServ sets mode: +v tokai
13:30:08 <Ammler> venus214: did you play with 0.6 ?
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: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:47:48 <Noetloj> building a oil refinery in sub-tropic, it errors with must be built ABOVE the >SNOW< line
13:48:21 <Celestar> should possibly read "cannot be built in desert"
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:36 <Noetloj> so it's a textual error for you guys to work out :p
13:52:01 <Celestar> peter1138: I gotta go in about 10 minutes. What should be our next steps?
13:52:25 <peter1138> coloured lines instead of just white...
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: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:10 <Celestar> peter1138: use FindNextHop
13:56:33 <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 <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: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: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: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:25 <peter1138> Celestar: yeah, that's easy
14:03:03 <venus214> Progman: but that isnt working if you want to do it diagonally or horizontally..
14:03:15 <peter1138> Celestar: In theory that's our only savegame change :D
14:03:48 * peter1138 adds StationID target;
14:03:58 <peter1138> shorter than destination, longer than to.
14:04:10 <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:55 <peter1138> I think venus214 is talking about diagonal terraforming.
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 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: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: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:07 <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:17:20 <Progman> < Eddi|zuHause3> ETA = ETA+round trip time
14:17:29 <Progman> sounds like reimplement TCP in openttd ;)
14:18:46 <Rubidium> there's no retransmission of passengers
14:18:51 <blathijs> Rubidium: Since trains can get lost at any time? :-)
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:21:08 <blathijs> I would say that when multiple vehicles share an order, there should be an edge for every vehicle
14:21:40 <Eddi|zuHause3> you'll have to discuss that with celestar ;)
14:22:49 * blathijs pokes Celestar for a bit
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: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: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:44:09 <peter1138> Eddi|zuHause3, we could just assume passengers are stupid and don't pick the best route? ;)
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 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 has joined #openttd
15:27:29 <Ammler> Eddi|zuHause3: if you build on oneway roads a tramtrack, you got only one
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: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:26 <blathijs> Eddi|zuHause3: Though currently, speed of a vehicle is also stored on an edge, but that can probably be replaced with ETA
16:05:03 *** welshdragon is now known as welshdra-gone
16:23:44 *** welshdra-gone is now known as welshdragon
17:01:50 *** Wezz6400 has joined #openttd
17:10:09 <Phantasm> Belugas: How is the fix going?
17:14:24 <Belugas> during holidays? NEVAR :)
17:19:01 <Belugas> but apart that, pretty much stalled on the same problems
17:21:24 *** Deathmaker has joined #openttd
17:33:37 *** GoneWacko has joined #openttd
17:37:10 <Belugas> Phantasm, don't give up hope :)
17:37:34 <Belugas> nor how (currently) ;)
17:40:11 <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:44 <Belugas> that and of course, the production changes, which are way more commun :)
17:46:23 *** Klanticus has joined #openttd
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:33 <plakkertjes> why isnt there more than one intro screen
18:09:19 <Eddi|zuHause3> blathijs: well, you could do something like air-distance/speed
18:09:21 <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:37 *** Zealotus has joined #openttd
18:25:21 <Celestar> peter1138: how's progress
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:54 <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:33:49 *** fmauNekAway is now known as fmauNeko
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 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` has joined #openttd
18:41:08 <Eddi|zuHause3> but you should be thinking about the first step now, not about the third ;)
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:43 <Celestar> with the alter version
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: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 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:05:27 *** GoneWacko has joined #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: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: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:36 <Eddi|zuHause3> the least stupid that went through my mind...
20:00:56 <Eddi|zuHause3> everything else includes pointer magic...
20:02:13 <rortom> the c++ way would be to derivate the class and implement calling both methods?
20:03:08 <Eddi|zuHause3> templates could work ;)
20:03:20 <Belugas> might be easier if the need was expressed in context :)
20:13:04 <Celestar> well, just forget it, it was a rethorical question :P
20:17:22 <peter1138> Hmm, this is not right :o
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:21:38 <Celestar> Mucht: do you use bibtex?
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:14 <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: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:31:37 <Celestar> Mucht: I certainly use bibtex
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:53 * Belugas goes home. see ya two more row
20:33:08 *** DaleStan_ 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:35:12 <Celestar> Mucht: possible. apparently my jabref misses such a button.
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:34 <Celestar> thanks Mucht that's it afaik
20:36:43 * Celestar finishes this and goes back to coding
20:36:52 <Celestar> std::vector<VertexDescriptor> dump; this->hopcache.push_back(dump);
20:36:56 <Celestar> any idea to simplify this?
20:38:48 <Celestar> yeah, but dump is totally useless
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: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:50:04 <peter1138> Okay, night night Celestar
20:51:28 <peter1138> Ah, just using this-> in a few places...
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:14:49 <peter1138> The route network for pile transport is a bit... mad.
21:15:21 * Noetloj assigns peter1138 to the destination of /dev/null/
21:16:03 <Prof_Frink> /dev/null is not a directory!
21:18:37 <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:19:29 *** grumbel has joined #openttd
21:23:21 *** Wezz6400 has joined #openttd
21:25:59 *** welshdragon has joined #openttd
21:26:02 *** Brianetta has joined #openttd
21:37:47 <peter1138> Celestar, some issues with aircraft orders :o
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:48:02 <rortom> "train control patch"?
22:12:12 <peter1138> Hmm, shuffling orders around still breaks things :(
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:37:53 *** GoneWacko has joined #openttd
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:10:44 <CIA-5> OpenTTD: smatz * r13863 /trunk/config.lib: -Fix (r13852): make the nightly compile again
23:10:56 *** plakkertjes has joined #openttd
23:15:18 *** welshdragon has joined #openttd
23:23:44 *** welshdragon has joined #openttd
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_ has joined #openttd
23:52:10 *** DJNekkid_ is now known as DJNekkid
continue to next day ⏵
