IRC logs for #openttd on OFTC at 2011-10-17
⏴ go to previous day
01:00:49 <Eddi|zuHause> ooh... forum backup... didn't have that in quite a while...
04:57:20 *** Eddi|zuHause2 has joined #openttd
05:48:22 *** Cybertinus has joined #openttd
06:08:28 *** DayDreamer has joined #openttd
06:12:19 *** sla_ro|master has joined #openttd
07:31:53 *** SirSquidness has joined #openttd
08:06:13 *** Eddi|zuHause2 is now known as Eddi|zuHause
08:19:01 *** Progman has joined #openttd
09:01:07 *** Brianetta has joined #openttd
09:37:09 * Bolt_ waves and says 'howdy folks'
09:46:36 *** TheMask96 has joined #openttd
09:55:04 *** the is now known as the_bolt
10:01:34 *** Eddi|zuHause has joined #openttd
10:15:54 <planetmaker> maybe you could fix your too many white space in the op code patch?
10:16:26 <planetmaker> and dunno... maybe you just open an FS task about it, too
10:23:40 <the_bolt> I posted into the forums as requested.
10:41:26 *** DayDreamer has joined #openttd
10:44:44 <the_bolt> next - to document performance do's and don't for the wiki
10:53:19 <Arafangion> If you're so worried about performance, why don't you put the C++ classes entirely in the header?
11:13:52 <the_bolt> the performance is for the AI script.
11:17:39 <Eddi|zuHause> even if not, what do headers have to do with performance?
11:28:47 <Arafangion> Eddi|zuHause: Certain styles of implementation are much easier to inline.
11:30:02 <Eddi|zuHause> Arafangion: but apart from a few special cases, inlining has hardly any effect on performance
11:33:26 <Arafangion> Eddi|zuHause: Depends on what you mean by "special".
11:34:07 <Eddi|zuHause> Arafangion: "special" as in "that is currently already done"
12:56:37 *** Arafangion has joined #openttd
12:57:11 *** DayDreamer has joined #openttd
13:01:38 <Arafangion> AdmiralAI seems to take ages to start (On a highly populated 64x64 map!)
13:02:14 *** Kurimus has joined #openttd
13:13:08 <Arafangion> Interesting - on my map, DictatorAI is making more money than gelignAlte.
13:21:16 *** DayDreamer1 has joined #openttd
13:21:18 * Arafangion looks at Belugas suspiciously.
13:21:40 * planetmaker looks at Arafangion suspiciously and waves 'hello' to Belugas
13:22:55 * Belugas wonders what's wrong with Arafangion and waves a big smiley hello to planetmaker :)
13:25:00 * Arafangion mumbles, looks inwards and returns to The Game.
13:27:19 <Belugas> crossed eyes Arafangion :)
13:43:34 *** HerzogDeXtEr1 has joined #openttd
14:00:42 *** George is now known as Guest13802
14:12:11 <Elukka> i was drawing something very similar
14:12:15 <Elukka> think i'll do multiple color variants
14:13:32 <Eddi|zuHause> not entirely sure about the length, though
14:14:15 <Elukka> i figure it can't be too far off the length of the other freight cars
14:14:18 <Elukka> which both round off to 5 lu
14:14:50 <Eddi|zuHause> 8800m (4lu) is a common figure i found
14:25:51 <Eddi|zuHause> Elukka: we can also use recolouring for the wagons
14:37:20 *** Doorslammer has joined #openttd
14:39:05 <Elukka> at 8.8 / 24 x 12 it's 4 lu, at 8.8 / 24 x 12.5 it's barely 5
14:39:33 <Elukka> i suppose recoloring would be a bit easier
14:58:57 <MNIM> why is my overflow depot not working?
15:00:47 <planetmaker> why did the chicken cross the road?
15:01:46 <__ln__> i have a better question: if A and B are independent, and P(A)=P(B)=p>0, is it true that if P(A union B)=1 then p=1? (i think it's false)
15:03:17 *** Adambean has joined #openttd
15:03:18 <planetmaker> I think it's false
15:03:24 <planetmaker> 50% of the people are women
15:03:30 <planetmaker> 50% of the people have black hair
15:03:38 <planetmaker> not 100% are black-haired women
15:05:00 <planetmaker> but that doesn't fit the assumptions... I see :-)
15:07:40 *** SirSquidness has joined #openttd
15:09:56 *** Prof_Frink has joined #openttd
15:11:13 <__ln__> today's exam question was to prove that one to be correct.
15:11:42 <b_jonas> __ln__: but if you want a proof, you might want to ask on another channel (eg. freenode #math )
15:13:39 <__ln__> b_jonas: but what if we choose p=1/2, and let A be the complement of B? P(A union B) = 1, but p != 1.
15:22:13 <Yexo> why is P(A union B) always 1 in that case/
15:23:04 <planetmaker> complement is always dependent. Not independent
15:25:50 *** Brianetta has joined #openttd
15:27:42 <__ln__> that might be the key to why the magic fails
15:35:47 *** sla_ro|master has joined #openttd
16:11:09 *** TWerkhoven has joined #openttd
16:19:38 <Eddi|zuHause> __ln__: if A and B are independent, then P(A \cup B) = 1-P(¬(A \cup B)) = 1-P(¬A \cap ¬B) = 1-P(¬A)-P(¬B) = 1-2*(1-p)
16:20:34 <Eddi|zuHause> __ln__: if A and B are independent, then P(A \cup B) = 1-P(¬(A \cup B)) = 1-P(¬A \cap ¬B) = 1-P(¬A)*P(¬B) = 1-p^2
16:21:04 <Eddi|zuHause> anyway, 1 = 1-(1-p)^2 => p=1
16:22:41 <Eddi|zuHause> the step 1-P(¬A \cap ¬B) = 1-P(¬A)*P(¬B) requires independence
16:47:30 <peter1138> you know, the more recent title screen games just don't feel right
16:48:03 <peter1138> it's really missing the level crossings and the fog horns
16:51:30 <Elukka> more recent title screens exist?
16:51:50 <peter1138> the one you get when you play a release
16:52:16 <peter1138> i don't know how often it changes
16:53:15 <Terkhen> the last two releases had a voting contest to select different title screen games
16:56:51 <peter1138> hmm, i should try the scott joplin pack through pianoteq
16:57:53 <planetmaker> each release branch probably gets its own title game
16:58:16 <Elukka> but nightlies still use the old one?
16:58:25 <planetmaker> they always will continue to use the same, yes
16:58:52 <Elukka> you can kinda tell it's not really made with modern screen resolutions in mind... since most of it is empty
16:59:00 <planetmaker> when the minor version number (the x in 1.x.y) changes, then we usually had at title screen contest the last two times
16:59:18 <planetmaker> but for nightly that's not important really ;-)
16:59:36 <planetmaker> the important property there is: it's a savegame of savegame version 4.
16:59:39 <Elukka> i suppose it's not vital
16:59:40 <planetmaker> And now we have 16x
16:59:52 <planetmaker> thus it's a savegame conversion test implicitly ;-)
17:00:32 <planetmaker> but most people anyway use stable. They get nice starting screens. Or so at least the majority of people who voted thought ;-)
17:00:59 <planetmaker> So if you want... start making one. There'll be another contest around... December ... February or so
17:01:16 <Elukka> i'd never see it since i haven't played stables for years
17:01:28 <planetmaker> Doesn't need to stop you
17:03:05 <peter1138> shame these midi pieces are too perfect :(
17:03:55 <peter1138> exactly the same velocity for every note
17:04:00 <peter1138> exactly the same timing
17:04:23 <planetmaker> peter1138: don't you own a midi device?
17:04:40 <planetmaker> i.e. where are your midi files for a sound set? ;-)
17:05:30 <peter1138> this piece is adjusting the master volume
17:05:39 <peter1138> instead of adjusting velocity :S
17:05:45 <peter1138> wrong wrong wrong :S
17:06:47 <peter1138> my midi files for a sound set? what do you mean?
17:07:28 *** pugi__ is now known as pugi
17:07:29 <planetmaker> I mean your music pieces. As midi files
17:07:43 <planetmaker> Dunno if it's feasible with your equipment
17:09:19 <peter1138> i never record the midi from the keyboard
17:09:24 * Belugas does not think peter1138's excessive use of digital effets can be recorded in midi :)
17:09:44 <peter1138> i use a variety of midi synths
17:09:49 <peter1138> not usually a soundfont synth
17:09:55 <peter1138> (although i have done)
17:10:12 <peter1138> and the guitar isn't midi, heh
17:10:53 <Belugas> well... yours and mine... Charles has 2 midi guitars
17:11:50 <peter1138> that would sound odd through a soundfont player :)
17:11:51 <Belugas> but granted, the idi part is only to grab the events on the guitars
17:12:21 <Belugas> as soon as his devise reads them, they are digiatlly processed and output as waves
17:12:51 <Belugas> i'l have to ask him, peter1138, but i doubt he'll waste tie on it ;)
17:14:35 <Belugas> #In the dead of nights
17:20:58 <Yexo> Elukka: you could still download the a stable version and just copy opntitle.dat from there to your nightly install
17:21:52 <peter1138> hey cool, some 32bpp graphics ;p
17:23:20 *** TheMask96 has joined #openttd
17:24:57 *** LordAro has joined #openttd
17:24:59 <b_jonas> thanks again for pointing me to the openttdcoop wiki. its examples will help me build better networks even if I'm not playing openttdcoop.
17:27:00 *** frosch123 has joined #openttd
17:31:24 <Terkhen> no need to highlight me twice :P
17:40:16 <b_jonas> though their complicated examples are over my head
17:40:22 <b_jonas> I might still learn a bit at a time
17:42:36 <peter1138> some of it isn't relevant
17:43:35 <peter1138> actually none of it is, to my playing style :p
17:48:39 <frosch123> Terkhen: doesn't the second highlight cancel the first one?
17:49:03 <Terkhen> not if I already checked the first one and alt tabbed again
17:50:26 *** glx is now known as Guest13824
17:50:26 *** ChanServ sets mode: +v glx_
17:55:27 *** valhallasw has joined #openttd
18:07:03 *** JVassie has joined #openttd
18:19:12 *** TWerkhoven[l] has joined #openttd
18:23:10 *** DayDreamer has joined #openttd
18:28:42 *** Brianetta has joined #openttd
18:44:50 <b_jonas> they're building logic gates from presignals! that's crazy.
18:45:25 <b_jonas> and they're actually deliberately using the bugs in the old signal behaviour
18:48:06 *** andythenorth has joined #openttd
18:50:29 <DDR_> b_jonas: OpenTTD Coop, right?
18:50:51 <b_jonas> DDR_: yes, I was looking at the openttdcoop wiki to learn a bit about track layouts
18:53:40 <b_jonas> hmm, I've got 64% station rating for this iron ore mine with a single slow ship that transmits to a station 60 tiles away
18:53:57 <b_jonas> I guess that's because ships get a bonus for station rating computation, right?
18:54:07 <b_jonas> should I be using feeder ships to fool stations into giving me better ratings?
18:54:20 <Pinkbeast> Much as I respect the #coop people that is a bit like trying to learn how to sail a dinghy by close consideration of HMS Victory
18:54:43 <frosch123> well, the max speed of the last vehicle visiting a station also affects rating
18:55:15 <frosch123> which compensates the ship bonus usually :p
18:56:27 <DDR_> b_jonas: I've been playing openTTD for a few years, and I still have no freaking clue how most of the Coop's stuff works.
18:56:35 <DDR_> You're a brave, brave man.
18:56:53 *** Biolunar has joined #openttd
18:59:52 <b_jonas> DDR_: I don't wish to play coop, I just want to learn som things about the layouts for my single-player games. Their info about layouts sometimes seem fresher than the ones on openttd wiki.
19:00:10 <Pinkbeast> Really? Some of their stuff still used block signals last I looked.
19:00:25 <Pinkbeast> I think the wiki has pretty good information on normal stations and junctions.
19:00:35 <b_jonas> Pinkbeast: true, and I did mention they seem to use old signal bugs as well
19:00:39 *** AcidWeb has joined #openttd
19:00:55 <frosch123> Pinkbeast: in case you did not notice, they use non-path signals intentionally
19:01:00 <b_jonas> Pinkbeast: but they're using pre-signals for exotic logic blocks that I'm not sure you can build from path signals
19:01:07 <frosch123> because they are more advanced than path signals when used correctly
19:01:31 <b_jonas> they're using pre-signals for priority thingy
19:01:43 <frosch123> path signals are for people with less than 7 platforms :p
19:02:03 <Pinkbeast> What I'm saying is _the last time I looked_ there were still layouts that used block signals because they predated path signals.
19:02:56 <DDR_> I wouldn't put it past them to save old-but-impressive signal layouts.
19:03:17 <Pinkbeast> And that I don't think jonas will learn much about normal gameplay, just as any kind of "stunt flying" in videogames doesn't necessarily tell you much about normal play.
19:03:24 <AcidWeb> What may cause ppl randomly drop from multiplayer game? "Client dont respond in X days" error or something like that
19:04:11 <b_jonas> Pinkbeast: I at least learnt how they build junctions that connect a sideline to a mainline
19:04:16 <b_jonas> I used something like that in my last game
19:04:38 <b_jonas> before reading their wiki that is
19:05:07 <AcidWeb> Hmm but all ppl are affected. Not only one drop randomly.
19:05:07 <DDR_> Hm, ... memory blank here, what's it called when trains exit by the same end of the station they entered, versus exiting by the other end of the station?
19:05:42 <DDR_> AcidWeb: It might be the server's connection, or just wider hickups in the network...
19:05:52 <AcidWeb> DDR_: Server got 100/100 connection.
19:06:17 <AcidWeb> And some other services that working correctly.
19:06:51 <planetmaker> DDR_: I'd not argue that block signal layouts are all outdated
19:07:20 <b_jonas> planetmaker: how about pre-signal layouts for giving priority to a line over another one?
19:07:24 *** andythenorth is now known as Guest13836
19:07:24 *** andythenorth_ has joined #openttd
19:07:24 *** andythenorth_ is now known as andythenorth
19:07:54 <planetmaker> b_jonas: that's one place where path signals cannot help a lot
19:09:36 <b_jonas> hmm, which mode of transport should I use for this forest? road, train?
19:12:21 <DDR_> How much wood do you have to transport?
19:14:00 <AcidWeb> Maybe i screwed network settings? net_frame_freq = 2 net_sync_freq = 50
19:14:00 <andythenorth> try using a river :P
19:15:46 <Rubidium> the speed of a connection says nothing about the stability of said connection
19:16:31 <Rubidium> though it has to be said that OpenTTD doesn't cope very well with slightly unstable connections whereas other applications might have less trouble with that
19:16:40 <Terkhen> AcidWeb: what's the size of the map?
19:17:20 <b_jonas> Rubidium: yes, I have FISH loaded
19:17:32 <Elukka> anyone know if YACD is still being actively developed?
19:17:34 <Rubidium> though that's mainly because we actively monitor the connection, i.e. we sort of "ping" the clients and if they don't reply within the 10 seconds they're dropped
19:17:46 <Elukka> i'm kinda on an ottd hiatus because i really want to play with yacd but it's not playable enough yet...
19:17:47 <b_jonas> I couldn't download BIRD though (the corresponding airplane GRF)
19:17:49 <AcidWeb> Im using AP+ it that change anything.
19:17:49 <Rubidium> Elukka: I think michi_cc knows
19:17:55 <Terkhen> Elukka: to my knowledge it is on hiatus right now but ^
19:18:10 <Elukka> i hope it's not on a permanent hiatus!
19:18:38 <DDR_> b_jonas: I usually use road for travel distances under two feet of real screen-space, although I have been known to make longer roads if the mood takes me.
19:18:45 <Terkhen> I have seen connection problems when the map is too big or it has too many vehicles and either the server or the client can't keep up with execution
19:18:58 <Terkhen> DDR_: check the YACD thread at the development subforum
19:20:28 <michi_cc> Elukka: YACD is waiting on some inspiration on how to make the algorithms at least twice as fast (or for somebody to rewrite the core game loop with multi-core support).
19:20:53 <planetmaker> hm, so speed is the problem?
19:21:16 <Terkhen> btw michi_cc, my approach to subsidies is using the part of YACD you suggested :)
19:21:25 <andythenorth> which bits are slow?
19:21:27 <Elukka> i hope you work on it in the future, it's such a great addition to the game :)
19:21:31 <Terkhen> I still have to fix subsidy creation, but the house acceptance/production code is done already
19:21:41 <Elukka> really i'd rather play on smaller maps with yacd than on large maps without it
19:21:45 <Elukka> if it was too slow to play on big maps
19:22:09 <Terkhen> hmm... and I was waiting on YACD for playing again too :P
19:22:40 <michi_cc> I have a test game that isn't that large (512x512 with a low number of towns and industries) but has a great number of cargo in flight and it is at 100% of my 3.2 GHz CPU. Over half the time in that game is purely spent inside "path"finding for cargo packets.
19:22:57 <Elukka> okay, that sounds like an issue
19:23:14 <Terkhen> what parts could be multithreaded?
19:23:37 <DDR_> oo, yacd looks nice. Seems to be the same idea behind cargo that Simutrans has, but without sucking like Simutrans does.
19:23:42 <andythenorth> YACD does use ~2x more CPU than non-YACD
19:24:35 * Terkhen wouldn't even know how to start to add multicore support :P
19:24:50 *** Alberth has joined #openttd
19:24:50 *** ChanServ sets mode: +o Alberth
19:25:35 <planetmaker> Terkhen: the only thing I can vaguely imagine is to move drawing to a completely separate thread
19:26:01 <michi_cc> YACD speed is directly related to number of active cargo packets and number of cargo producers (which in practice means house count, in comparison those few industries don't really matter).
19:26:01 <Rubidium> planetmaker: doesn't help much
19:26:04 <andythenorth> how does simutrans handle cargo packets?
19:26:15 <Alberth> anything known about weird names for wagons in opengfx+trains?
19:26:17 <planetmaker> andythenorth: simutrans has no reall MP support
19:26:59 <Rubidium> planetmaker: the bits that determine which sprites to draw are heavily dependant on the game state, so those need a "lock" of that state
19:27:07 <planetmaker> Rubidium: Not? I wonder... My OpenTTD uses even on idle 15% CPU of the core it runs on
19:27:23 <Rubidium> and the rest is already in a seperate thread on SDL/Allegro
19:27:31 <planetmaker> Rubidium: yes... but redrawing once per tick... hm...
19:27:39 <Terkhen> I can't think of anything that is not tightly coupled with the rest of the code
19:28:03 <Rubidium> hmm, sorry... only on SDL
19:28:07 <Yexo> perhaps part of the tileloop could be threaded, although even that would be very tricky to get right
19:28:43 <planetmaker> I wonder whether it might start to become interesting to mulithread things even if it gives a penalty on single core systems
19:29:13 <DDR_> Probably, very few people have single-threaded systems anymore.
19:29:26 <planetmaker> single-threaded: hardly ;-)
19:29:39 <Rubidium> planetmaker: the game state is so interdependant on eachother and on the execution order that I don't think much can be achieved
19:29:40 <michi_cc> Terkhen: Most of the YACD cargo pathfinding could be done parallel if the events that modify link graph woudn't be all over the place. This especially means vehicle movement where movement, stopping, loading/unloading is all done serially on each vehicle instead of first moving all vehicles, then checking station state, then loading etc.
19:29:49 <b_jonas> it doesn't sound too probably, but I think someone has suggested to have multiple maps connected only very losely, with gates where vehicles can pass but where the pathfinder doesn't see past the gates so you have to use explicit orders to the gate.
19:30:11 <planetmaker> Rubidium: I seem to recall reading like 5 ... 10% somewhere?
19:30:22 <Terkhen> so it needs a huge amount of changes to how the tileloop works first :)
19:30:28 <Rubidium> planetmaker: yes, *without* any locking
19:30:32 <andythenorth> does each packet have to calculate a full path on each tick?
19:30:41 <andythenorth> or just next hop? or what?
19:30:54 <Rubidium> andythenorth: only when loading/unloading
19:30:57 <planetmaker> hm, desync heaven. nice
19:31:58 <Rubidium> even then, profile the game to see what takes a lot of time
19:32:13 <Elukka> now i'm depressed that yacd might never get finished :(
19:32:16 <Rubidium> IIRC making/removing fences takes relatively much
19:33:17 <michi_cc> Example: In order to balance different routes the amount of waiting cargo is taken into account, which means that the link graph before a vehicle loads in different to the state after the vehicle loads. Ergo, the order of vehicle loading and cargo pathfinding has to be fixed.
19:33:40 <planetmaker> they look pretty Dutch, Alberth ;-)
19:34:01 <planetmaker> Did I mess up naming somewhere?
19:34:05 <Rubidium> and (in theory) you could remove that code from the tile loop and just build the fences when building farm tiles or when clearing tiles (in general)
19:34:30 <Alberth> I am quite sure "vogn" is not Dutch either :)
19:34:36 <Rubidium> they don't look Dutch to me
19:34:50 <Alberth> it is supposed to be UK english
19:35:02 <Rubidium> it's rather Norwegian or some other Scandinavian language
19:36:07 <planetmaker> hm... :-) I shall look into that. Thanks, Alberth
19:36:30 <Terkhen> michi_cc: let's see if I understood it correctly... it needs to group parts of the code that change the state such as vehicle load / unload and station handling, to avoid updating the cargo state more than necessary
19:36:34 <andythenorth> michi_cc: what could you do less of (i.e. worse, but acceptable)?
19:36:42 <planetmaker> The trains anyway need to make use of michi's new cargo aging property :-)
19:36:57 <Alberth> aka, "not known" thus :)
19:38:05 <Alberth> planetmaker: do you want me to make an issue about it?
19:40:01 <AcidWeb> Can AP+ can cause cause that player drops?
19:40:54 <michi_cc> Terkhen: Yes, for example make records of loaded/unloaded cargo packets, added/removed cargo links during vehicle tick execution and only apply them after all vehicles where processed. (Obvious problem: how to make sure vehicles don't load more cargo than present; solution idea: maybe don't store packets, but only "has to (un)load".) Then you could do cargo routing in parallel to vehicle pathfinding.
19:41:06 <Yexo> Alberth / planetmaker: the grf is fine, it's a bug in openttd
19:41:17 <Yexo> in openttd 1.1.3 it works as expected
19:45:38 * Terkhen needs to learn to use that program :P
19:47:08 <frosch123> wow, three different chains ending in the same function :o
19:47:36 <michi_cc> That savegame is already with a seriously reduced cargo recalculation frequency, otherwise the StationCargoList::UpdateNextHop chain would be much bigger (and the game not playable anymore on my PC).
19:48:43 <michi_cc> The part below ChooseRouteLink "suffers" from inlining (adding a new node is not nearly as expensive as it seems :)
19:48:53 <Terkhen> so it expends most of the time calculating cargo paths again and again
19:48:59 <AcidWeb> Im new in this topic. But it seems to me that using only planes is very easy way to win company value goal on servers without any GRF. Im right?
19:51:04 <AcidWeb> That is answer why most servers i see have them disabled.
19:51:18 <michi_cc> Terkhen: That game has about 100000 cargo packets or so, the time till the same packet is looked at again is quite big (which means there's not much that could be cached).
19:51:26 <AcidWeb> Need tweak server. Limit of 10 is to high.
19:52:07 <AcidWeb> Client #63 is dropped because the client did not respond for more than 4 game-days
19:52:17 <AcidWeb> Also need find a reason of that ;p
19:52:47 <Alberth> too big map, too busy map, too fast server
19:53:10 <michi_cc> The chain starting at TileLoop is purely the time spent for initial routing of the cargo (i.e. find out if there's a route at all and if yes, which station to deliver to), something which can't be tricked away.
19:53:16 <AcidWeb> Alberth: To fast server?
19:53:49 <Alberth> or too slow client, depending on your point of view :p
19:54:01 <Yexo> AcidWeb: you get that when the map is very busy and the client is not fast enough
19:54:42 <AcidWeb> I cant call this map busy
19:54:49 <AcidWeb> Also it is only 512x512
19:55:33 <michi_cc> The chain over LoadUnloadStation is getting the new next hop upon unloading from a vehicle to a station. The final chain(s) that end at UpdateCargoNextHop are for periodically rerouting cargo so cargo flow adapts to changes in the link graph.
19:55:46 *** Brianetta has joined #openttd
19:55:56 <AcidWeb> There is any option to "slow" the server?
19:58:10 <AcidWeb> Autopilot sending some additional commands every 30 seconds may cause ppl problems?
20:00:46 <glx> 4 times bigger than default size
20:01:41 <AcidWeb> Im just looking for answer on main question. If i screwed something? :D
20:01:57 <AcidWeb> And if yes how to fix it.
20:02:22 <AcidWeb> If it is client problem ok - i dont like it but i will live with that.
20:02:44 <Alberth> did you try pausing the game when a client connects?
20:03:17 <Terkhen> michi_cc: hmm... 23.95% is quite big... even if it can't be tricked away, that part could use some optimization
20:03:19 <AcidWeb> as i observer that is not connected.
20:04:51 <AcidWeb> also there are no pattern in that drops
20:05:00 <AcidWeb> It just sometime drop random ppl.
20:05:34 <Alberth> network connections are stochastic yes
20:07:19 <michi_cc> Terkhen: It already has a lot optimizations. For example the most expensive operation is pathfinding when the source is not connected to the destination as you'd potentially have to visit all nodes. To alleviate that problem I've locally implemented a station coverage cache so I can fail fast in case the target tile is not covered by any station. Obviously this optimization gets less and less effective the better connected the map is (which will als
20:07:19 <michi_cc> o be the time when this part uses more and more time due to town growth).
20:09:46 <andythenorth> how many graphs are there on any one map?
20:12:38 <Terkhen> it's a complicated problem :(
20:13:31 <andythenorth> this would be easier if we limited the game to 1 cargo :P
20:13:48 <AcidWeb> Anyway thank you for help. Maybe that is just hickup.
20:13:52 <andythenorth> I think there's only one graph in that map for PAX
20:14:15 <andythenorth> with one graph, all you need to check is coverage
20:15:09 <andythenorth> with 2 graphs...you'd need to check coverage, and if the start / end nodes are in the same graph
20:15:20 * andythenorth is a newbie at network theory :P
20:16:04 <michi_cc> Yes, there's only one connected pax graph. At lot of the houses on the map are inside station coverage though, so most of the time there is a path from source to destination.
20:16:22 <andythenorth> and calculating the path is expensive?
20:17:11 * andythenorth wonders how Railroad Tycoon 3 solved this, on older machines, while running a 3D engine
20:17:40 <andythenorth> probably a different problem, for a different codebase
20:18:06 <Yexo> andythenorth: a lot smaller maps, so less vehicles, less cargo
20:18:11 <DDR_> Hm, I think if you did some tricky work with minimizing the track layout, it becomes a trivial problem.
20:18:23 <Yexo> that is also a huge advantage
20:18:31 <andythenorth> RT3 had a different way of routing cargo
20:18:43 <Yexo> since without mp support you don't have to worry about desyncs
20:19:41 <andythenorth> how does the internet route packets?
20:20:07 <Alberth> non-deterministically
20:20:19 <andythenorth> I guess the computational load is handled by n devices too
20:20:26 <andythenorth> there is no 'the internet' device
20:20:30 <andythenorth> unless they're not telling us
20:20:40 <Alberth> it wouldn't be able to handle the load :)
20:21:41 <andythenorth> YACD is rather nice to play with :)
20:21:54 <michi_cc> Expensive enough to matter. A single cargo pathfinding only takes 0,0017% of the total CPU time, but a single tick only gets 0,15% of total time in this specific test case.
20:21:59 <Alberth> I once heard a story where routers told each other cost of routing, and one router said 0. All traffic was routed to there and the network went down :)
20:22:19 *** welshdragon has joined #openttd
20:23:13 <andythenorth> michi_cc: do you have to calculate the entire path?
20:23:33 <michi_cc> andythenorth: The big difference of RRT3 is that it doesn't actually care about the destination of cargo. The routing choice is very simple: destination has higher price -> load onto train, finished.
20:23:49 <andythenorth> it made for a fun game, although many disagreed :)
20:23:57 <Terkhen> sounds more boring than YACD
20:26:14 <michi_cc> andythenorth: On initial cargo generation the whole path has to be calculated to decide whether to generate the packet at all. After that, you don't necessarily have to do a full calculation, but then you might get the same problems the old train pathfinder had (like not managing a right turn for a destination on the left).
20:26:28 * andythenorth has ants in mind
20:26:39 <andythenorth> ants leave markers behind for other ants to follow....
20:28:02 <Alberth> Yexo / planetmaker: bisecting gives me r22970 to blame
20:28:08 <Terkhen> I don't think that ACO is appropiate for this problem
20:28:24 <michi_cc> Maybe A* just is very inefficient for this specific kind of problem and some other pathfinding algorithm would do a lot better, but I'm really not a specialist on pathfinder algorithms, so...
20:28:26 <Terkhen> too many paths, you'll need too many ants :P
20:28:33 <Yexo> Alberth: just found that out too :)
20:28:40 <andythenorth> ahttp://wiki.squeak.org/squeak/5633
20:29:04 <CIA-6> OpenTTD: yexo * r23036 /trunk/src/newgrf.cpp: -Fix (r22970): swapped parameters resulted in wrong vehicle names
20:30:01 <andythenorth> these are theories, not working code :)
20:30:20 <Terkhen> there must be a good method for a graph that changes a lot
20:30:26 <andythenorth> ant routing apparently performs badly in that case
20:30:31 <Terkhen> s/method/heuristic method/
20:30:43 <Terkhen> but then you are not getting optimal paths :)
20:30:48 <Alberth> Yexo: thanks for fixing :)
20:30:53 <andythenorth> does the graph change a lot?
20:30:59 <andythenorth> in a typical game?
20:31:34 <Rubidium> andythenorth: every time you change an order or change the time it takes a train to go from A to B
20:31:54 <Terkhen> andythenorth: if it is taking into account stuff such as "waiting cargo" then it is changing all the time
20:34:17 <andythenorth> so it's a known difficult problem :P
20:35:50 <andythenorth> michi_cc: if we can solve it, maybe we can patent it :)
20:36:00 <andythenorth> and then license it to cisco et al
20:36:10 <andythenorth> and use the income to implement TTD 3D :P
20:36:25 * andythenorth is only partly fooling and is partly serious :o
20:36:55 <andythenorth> a large TTD map represents a moderately complex routing situation that needs solving with relatively few computing resources
20:37:25 <michi_cc> Somehow I get the feeling we're not the first humans trying to find a solution to this problem :)
20:37:36 <Terkhen> is an optimal path a requirement for cargo packets? because if it is, probably A* and its family are probably the only real option
20:37:53 <Rubidium> andythenorth: internet routing is "easier". You only got point-to-point connections.
20:38:45 <Rubidium> i.e. the packet will always be offloaded at the next station regardless of how it goes further
20:39:01 <planetmaker> traveling salesman problem ;-)
20:39:14 <andythenorth> Terkhen: what constitutes 'optimal' ?
20:39:34 <Terkhen> hmm... good question :)
20:39:35 <andythenorth> I was wondering earlier today (for non-related reasons) how real railroads solve this
20:39:43 <Rubidium> andythenorth: spread evenly over the capacity
20:39:47 <michi_cc> Terkhen: Optimal definitely not. It has to be good enough that nobody complains that cargo for A to B is going over a X that looks very inoptimal to a human.
20:40:09 <andythenorth> let them route their own packets :P
20:40:14 <andythenorth> think that was mentioned once :)
20:40:53 <Rubidium> I don't think real railroads have capacity issues when routing (at least passengers)
20:41:10 <Rubidium> they just say: the earliest/fastest connection is: XYZ
20:41:11 <Terkhen> then what we need is a method that works in a graph that changes frequently and also needs to repeat paths a lot because cargopackets tend to use the same source/destination and gives decent results
20:41:36 <Rubidium> even when a million people go via that route, when you could also take a route 10 minutes longer that's empty
20:41:39 <andythenorth> stepping back a bit - what if the packets are generated even if there is no route?
20:41:53 <michi_cc> An inoptimiality inside defined bounds would even be good because then some of the highly volatile routing variables used to balance links could be removed.
20:42:31 <planetmaker> inoptimal != non volatile
20:44:20 <michi_cc> Terkhen: Actually the tuple of (4x4 source map square, 4x4 destination map square, routing flags) does not repeat a lot. I tried a global (source, dest, flag) cache and even without any cache invalidation the benefit wasn't very great. With invalidation, there's almost no benefit left.
20:45:00 <Rubidium> I think the major problem of cargo routing is the fact that it isn't point-to-point and it isn't "real time" (compared to internet routing)
20:45:47 <Rubidium> with internet routing you push packets to another host and you can just send X packets per second (which is more or less a constant)
20:46:17 <Terkhen> hmmm... I wonder if a certain algorithm could work in this case, let me check its name
20:46:21 * andythenorth suspects railroad manifest freight routing is point-to-point
20:46:53 <michi_cc> Terkhen: I have a profile with a very limited cache that purely caches on cargo unloading (because there you often get several identical packets). The 51.07% of YapfChooseRouteLink shrink to 50.70%...
20:46:54 <Rubidium> with OTTD cargo routing you have a "container" for cargo coming in that has some remaining capacity (highly fluctuating) and departs every now and then
20:47:35 <Rubidium> so where for internet it would suffice for: 1 packet over link A, then two over link B, then one over link A, 2 over link B would suffice for spreading load in routing
20:48:29 <Rubidium> for cargo you would send relatively a lot in a train and then a relatively a lot in another taking a slightly longer route
20:49:36 <Rubidium> and as you don't know future capacity you have to guess: should I just fill this train take takes a slightly longer route till its max? Or can everything go in the faster train coming next?
20:50:04 <andythenorth> sounds like a 'know the future' problem
20:51:05 <andythenorth> how come humans know the future, but we can't teach software how we do it?
20:51:17 <Rubidium> and in the real world you can try some (or a lot of) permutations of routings to find an optimal one, but in OpenTTD you don't have the time for it
20:51:58 <andythenorth> in the real world, excepting PAX, vehicles are sent according to the need to route cargo
20:52:04 <andythenorth> in TTD we don't have that connection
20:53:07 <appe> Markk:s circumference exceeds jupiter.
20:54:28 * Rubidium puts himself on a siding ;)
20:56:10 <appe> to explore Markks digestive systems, you would need fusion power.
20:58:32 <Terkhen> michi_cc: I see, I expected a lot more :/
20:59:01 <Terkhen> so that path is not good either
20:59:12 * Terkhen finds an optimal path for today
21:16:00 *** andythenorth has left #openttd
21:20:49 *** FLHerne has joined #openttd
22:11:22 <Eddi|zuHause> <andythenorth> there is no 'the internet' device <-- ever seen the it crowd? ;)
22:24:25 *** JVassie has joined #openttd
22:31:30 *** sla_ro|master has joined #openttd
22:32:16 *** sla_ro|master has joined #openttd
22:49:05 *** welshdragon has joined #openttd
23:01:47 *** heffer_ has joined #openttd
23:02:02 *** TrueBrain has joined #openttd
23:02:02 *** eQualizer has joined #openttd
23:02:39 *** welterde has joined #openttd
23:03:18 *** Zeknurn has joined #openttd
23:06:49 *** peter1138 has joined #openttd
23:06:49 *** ChanServ sets mode: +o peter1138
23:14:44 *** glx is now known as Guest13867
23:15:20 *** Strid__ has joined #openttd
23:18:37 *** heyheyy has joined #openttd
23:25:38 *** mib_apmba8 has joined #openttd
23:32:36 *** peter1139 has joined #openttd
continue to next day ⏵
