Times are UTC Toggle Colours
00:11:26 <Brot6> World Airliners Set - Revision 742:03a2632dc424: Updated 747-400BCF nfo with slightly change co-ords... XBeardie27X @ http://dev.openttdcoop.org/projects/worldairlinersset/repository/revisions/03a2632dc424 00:16:25 <Brot6> worldairlinersset: update from r741 to r742 done (94 warnings) - http://bundles.openttdcoop.org/worldairlinersset/push/r742 00:25:20 <Brot6> World Airliners Set - Revision 743:1548357b17b3: Changed Action 14 Palette from DOS to Windows XBeardie27X @ http://dev.openttdcoop.org/projects/worldairlinersset/repository/revisions/1548357b17b3 00:29:50 <Brot6> worldairlinersset: update from r742 to r743 done (95 warnings) - http://bundles.openttdcoop.org/worldairlinersset/push/r743 00:31:09 <Brot6> World Airliners Set - Revision 744:654384809089: Fixed B747-400BCF Cathey pacfic Sprite Alligment XBeardie27X @ http://dev.openttdcoop.org/projects/worldairlinersset/repository/revisions/654384809089 00:35:23 <Brot6> worldairlinersset: update from r743 to r744 done (94 warnings) - http://bundles.openttdcoop.org/worldairlinersset/push/r744 00:54:04 <Brot6> World Airliners Set - Revision 745:bdcc66099bad: A330-200 Greyscale White Pixels Fixed XBeardie27X @ http://dev.openttdcoop.org/projects/worldairlinersset/repository/revisions/bdcc66099bad 00:55:07 *** Beardie has quit IRC 00:59:10 <Brot6> worldairlinersset: update from r744 to r745 done (54 warnings) - http://bundles.openttdcoop.org/worldairlinersset/push/r745 01:00:00 *** Frankr has quit IRC 07:44:03 *** andythenorth has joined #openttdcoop.devzone 07:44:04 *** andythenorth has left #openttdcoop.devzone 09:01:07 <Brot6> Unable to connect to http://dev.openttdcoop.org/sys/: Failed. Response code = 504. Response message = Gateway Time-out. 10:35:31 <Brot6> World Airliners Set - Revision 746:634fdb9dfc65: Fix: add package to fix missing command error XRhodeCode AdminX @ http://dev.openttdcoop.org/projects/worldairlinersset/repository/revisions/634fdb9dfc65 10:45:27 <Brot6> worldairlinersset: update from r745 to r746 done (50 warnings) - http://bundles.openttdcoop.org/worldairlinersset/push/r746 11:27:46 *** Phazorx has joined #openttdcoop.devzone 11:27:57 <Phazorx> g'day 11:29:23 <Phazorx> are coopers working on cargodest or it's some other group of developers? 11:32:41 <Ammler> none 11:33:12 <Phazorx> err... you mean it's not coop project? 11:33:14 <Ammler> just fork and continue 11:33:24 <Ammler> no, I mean is none project 11:33:30 <Ammler> noones 11:33:42 <Phazorx> well someome maintains it for sure 11:33:45 <Ammler> maybe cargodist is a bit active 11:33:46 <Phazorx> on github 11:33:48 <planetmaker> it's only fonsinchen's project 11:33:55 <Phazorx> i see 11:34:00 <planetmaker> and yacd is michi_cc's project 11:34:06 <planetmaker> available on icosahedron.de 11:34:07 <Phazorx> and paxdest is forgotten completely? 11:34:46 <Ammler> which paxdest are you refering to? 11:34:57 <Phazorx> heh one i rmember from like 4 years ago 11:35:05 <Phazorx> it was on coopers.dev box 11:35:12 <Phazorx> for a short while at least 11:35:19 <planetmaker> all kinds of *dest have been there once at least... 11:35:25 <planetmaker> thus it's not an indication really ;-) 11:35:26 <Ammler> I guess, you remember cargodest from peter and celestar 11:35:29 <Phazorx> i wodner if there is some playable destination based build for ottd 11:35:45 <planetmaker> yacd and cargodist 11:35:46 <Phazorx> well it's been a while 11:35:50 <Ammler> cargodist or yacd:-) 11:35:59 <Phazorx> pm are you familar with cargodest's logic? 11:36:05 <planetmaker> no 11:36:06 <Phazorx> and is yacd any better/worse ? 11:36:13 <Ammler> better ask in #openttd 11:36:14 <planetmaker> yacd is similar to cargodest 11:36:23 <Phazorx> i sort of wonder how routing and spawning works there 11:36:34 <planetmaker> in any case, if you want to start, do that with either yacd or cargodist 11:36:59 <Phazorx> start? 11:37:23 <planetmaker> yacd assigns 1...4 (?) destination industries for each product an industry produces. 11:37:29 <Phazorx> i have cargodest trunk here, but i see some issue with it's logic and volumes 11:37:40 <planetmaker> while cargodist assignes destinations depending on the available network 11:38:04 <planetmaker> thus with yacd you have incentive to really connect everything 11:38:22 <planetmaker> while with cargodist you don't. As it depends on the available network 11:38:46 <planetmaker> really, don't use cargodest ;-) 11:39:02 <planetmaker> all which was learnt from it (and from cargodist partially) is in yacd 11:39:03 <Phazorx> hrm... 11:39:22 <Phazorx> i have cargodist not dest as Ammler corectly mointed out 11:39:25 <michi_cc> planetmaker: yacd doesn't have a maximum limit, the more cargo produced, the more destinations (but yes, this translates to 1..4 for normal production :) 11:39:29 <planetmaker> lalala :-) 11:39:40 <planetmaker> :-) ty, michi_cc 11:39:55 <Phazorx> michi_cc: what are rules for picking destinations? 11:39:59 <planetmaker> just going by my last game with yacd... which is certainly >12 months ago 11:40:43 <Phazorx> is consumtion somehow factored in for PBI-like industry sets? 11:40:52 <planetmaker> "accepts cargo". And balanced somehow that all industries get something 11:41:07 <Phazorx> planetmaker: accepts based on stations or industries? 11:41:15 <planetmaker> destinations are industries 11:41:24 <planetmaker> or houses 11:41:39 <michi_cc> Phazorx: Weighted random selection (e.g. for towns it is: close by towns are more often selected than towns with the city flag, which are more often selected as larger towns which are more often than any town). 11:42:02 <Phazorx> michi_cc: and for local pax/mail traffic? 11:42:18 <michi_cc> Of course selection is only down for destinatons that accept the cargo. 11:43:16 <michi_cc> Amount of local pax is a fixed percentage, calculated based on the the size of the town and the total size of all its destinations (i.e. the more traffic to the other towns, the less inter-town traffic). 11:43:20 <Phazorx> michi_cc: i understand that, and if there is a multi-legged transfer network, like where unit has to go through more than one distribution center - how is it picked up and trasfered? 11:44:23 <Phazorx> like A - H1 - H2 - H3 - B, what kind of order h1-h2 route needs for getting B targeted unit from A ? 11:44:25 <michi_cc> It just is ;) Cheapest path according to several different penalties. 11:44:44 <michi_cc> Any that allows loading at H1 and unloading at H2. 11:44:56 <Phazorx> so a unit weights alternatives based on available routes then? 11:45:13 <Phazorx> what if h1 and h3 are connected as well? 11:45:24 <michi_cc> Yes. The penalties used are highly dynamic, so it appears that cargo routes over more than one way. 11:45:57 <Phazorx> reason i mention it because i see routing issues in cargodist 11:46:08 <Phazorx> and iwonder if logic same in yacd 11:46:16 <michi_cc> Connected alone doesn't mean anything. H1 - H2 - H3 has a certain penalty and H1 - H3 another, it will pick whatever is better. 11:46:17 <planetmaker> Phazorx: that's comparing apples and pears 11:46:37 <planetmaker> cargodist uses the routing to decide the destination 11:46:46 <planetmaker> yacd decides the destination before the cargo gets loaded 11:47:19 <Phazorx> planetmaker: after destination is choosen i wonder how routing on intermediate steps works 11:47:32 <Phazorx> like in scenario i mentioned there could be alternative ways to get to destonation 11:47:40 <Phazorx> with different amounts of stops and traffic 11:47:45 <planetmaker> so there can be, yes 11:48:26 <Phazorx> how would logic work in case for a particular unit that has more than one physical way to get to destination but with no vehicles picking it up due to watever? 11:48:53 <Phazorx> when does decision to be loaded or not is commited into? 11:49:14 <Phazorx> and i hope my screwy english is comprehandable 11:49:21 *** welshdragon has quit IRC 11:50:07 <Ammler> Phazorx: the audience in #openttd would be bigger and everyone here is also there... 11:50:34 <Phazorx> well they are quiet there and you guys are answering my questions here 11:50:40 <Ammler> :-) 11:50:46 <michi_cc> There are penalties for travel time, travel distance, transfers, mode of transportation, waiting cargo at start/transfer point and time since last vehicle. 11:51:11 <Phazorx> aha.. so it is complex 11:51:26 <Phazorx> but still is the route re-evaluated periodically? 11:51:44 <Phazorx> like could a unit decided to backtrack based on some conditions? 11:51:54 <Phazorx> *decide 11:52:47 <Phazorx> michi_cc: basicaly i guess i'm asking if routing is dynamic or static i guess 11:53:15 <Phazorx> like difference between post system and cell network packet delviery protocol 11:53:43 <michi_cc> Calculation always starts at the current point of the cargo, nothing stores where it came from. 11:54:12 <Phazorx> mean it is dynamic 11:54:17 <Phazorx> at least to some level 11:54:28 <Phazorx> but when does that calculation happen? 11:54:46 <michi_cc> It is static and deterministic for a specific moment in time, but the various penalties are always changing, so the chosen route also changes over time. 11:55:06 <Phazorx> well it's either static or route changes over time 11:55:11 <Phazorx> can not be both 11:56:17 <Phazorx> say, for A-H-B network and A-H, H-B routes, all A-B traffic must be unloaded at H, does player need to force it with transfer order or it happens automatically? 11:56:49 <michi_cc> [13:44 ]<michi_cc> Any that allows loading at H1 and unloading at H2. 11:57:11 <michi_cc> Which especially also includes the plain old goto order. 11:57:40 <Phazorx> okay, imagine now that there is a A-H-B route, where H is intermediate step 11:57:50 <Phazorx> will A-B cargo gets unloaded at h and reloaded back? 11:58:22 <michi_cc> No, it stays on the vehicle. YACD distinguishes between vias and trafers. 11:58:24 <Phazorx> or that is controled based on no-unload order? 11:58:49 <Phazorx> michi_cc: so i presume than that cargo path is re-evaluated at arrival point of time? 11:59:04 <Phazorx> *then 12:00:08 <michi_cc> In theory, yes. In practice, there are some caches involved, so it isn't always recalculated, but still regularly. 12:01:48 <Phazorx> michi_cc: interesting, thanks 12:03:12 <Phazorx> and yacd looks stall for a year already 12:03:24 <Phazorx> it is in finished state or devs are just busy with something else? 12:04:44 <Phazorx> actually i see last changeset dated february... so i guess half a year only 12:07:15 <Phazorx> michi_cc: also, PBI/ECS stockpiling and capacities are factored in somehow too? 12:07:46 <Phazorx> i mean during destination seeding time, not routing obviously 12:08:07 <michi_cc> They aren't (at least not directly), because stockpiling is something internal to NewGRF and OpenTTD knows nothing about it. 12:08:51 <Phazorx> hrm... stacking unrecieved cargo should be visible to engine 12:09:21 <planetmaker> "stacking unreceived cargo"? 12:09:22 <michi_cc> But it isn't (nobody said NewGRF were always sane :) 12:10:08 <planetmaker> hehe indeed 12:10:40 <Phazorx> planetmaker: you know, when an industry can not consume mroe cargo (capacity and stockpile are full) cargo starts building up and acceptance changes 12:10:41 <planetmaker> Phazorx: the main issue - iirc - with yacd is not that it's not finished. It's rather that it has quite a performance impact 12:10:54 <michi_cc> YACD is both finished and unfinished in a sense. The last release is finished in the sense that it implements all of the demand logic I want, but it is also unfinished because several parts need to be reimplemented in a more performance friendly way. 12:10:57 <planetmaker> but michi knows that much better of course 12:11:04 <Phazorx> planetmaker: well obviously if each cargo piece is tracked individually 12:11:30 <Phazorx> michi_cc: and it's just too time consuming or there are no viable aproaches? 12:11:34 <planetmaker> cargo is stored in packets of various size. But... 12:11:53 <Phazorx> pm well batches were discussed 5 years ago when paxdest came up 12:12:58 <Ammler> you have almost the same effect by using firs 12:13:00 <michi_cc> Both. Time is limited and at the same time implementing an efficient algorithm (and not just one that works) is complicated. 12:13:48 <planetmaker> Ammler: playing firs is quite a bit different than yacd... 12:13:54 <Phazorx> michi_cc: but even as of now, cargo is grouped by destinations in baches for re-routing purposes? 12:14:31 <Ammler> planetmaker: almost :-) 12:14:56 <Phazorx> and firs is? (sorry i been away for tooooo long) 12:15:13 <Ammler> a industry newgrf 12:15:15 <planetmaker> Ammler: with FIRS you still don't have any reason to spread deliveries (it's an industry newgrf) 12:15:44 <planetmaker> though the supplies kinda link stuff in a way 12:15:45 <Ammler> with yacd, you have kind of different "subcargo" from every industry 12:16:39 <Ammler> well, the advantage is you have more as 32 12:17:19 <Phazorx> Ammler: 32+ cargo means more transfers and more pooling 12:17:36 <Phazorx> bascialy more mess rather than extra complexity layer as i recall from ECS experience 12:17:51 <Ammler> yep, that is yacd and cargodist 12:17:56 <Ammler> more mess :-) 12:18:16 <Phazorx> Ammler: with yacd i probably can get away with universal station 12:18:26 <Phazorx> rather than a type of statin per cargo 12:18:39 <Ammler> you don't need transfer orders 12:18:40 <planetmaker> Phazorx: you can get away with that in 1.2, too 12:18:52 <planetmaker> just need autorefit orders and a trainset which supports it ;-) 12:19:13 <Phazorx> well, that's a bit different aproach 12:19:14 <michi_cc> YACD has one definite advantage that is good for FIRS: Carog is delivered to the destination industry, and not just the one nearest to the station. 12:19:14 <planetmaker> and the proper settings (e.g. not gradual loading) 12:19:44 <Phazorx> michi_cc: my last question still stands btw, i'm curious 12:19:51 <planetmaker> hm... I wonder if I should play another yacd/firs game. the one with terkhen and andy was very enjoyable 12:21:45 <michi_cc> It isn't grouped (most of the time), because testing showed that it doesn't improve much (i.e. as YACD destinations are down to tile level, there is not much to group. Only exception is when unloading a vehicle, as then you often have several identical cargo packets). 12:22:51 <Phazorx> michi_cc: would it make sense to group by area, rather than by exact tile then? 12:24:28 <Phazorx> it's probably hard to come up with viable logic on what is "far enough" to group by area, however thart could be player issue, not the YACD then 12:25:19 <Phazorx> as in if you end up with cargo somewhere close to where it meant to go but w/o route to exact destiantion - player needs to take care of that 12:26:12 <Phazorx> on the other hand - michi_cc , has following been considered: 12:27:02 <michi_cc> It already is, tile here means a 4x4 area. 12:27:28 <Phazorx> destiantion could be mapped to deliverable areas, where areas would represent catchment area of some station, so rather than routing individual cargo to tiles you could map same area destinations to catchment areas of stations 12:27:55 <Phazorx> well your vehicles are still not going to exact tile, i think it should be based on catchment areas 12:28:24 <Phazorx> however there could be competing routes for overlapping station areas 12:31:48 <V453000> oh hello Phazorx :) 12:32:04 <Phazorx> hey there 12:34:32 <Terkhen> planetmaker: I would if it was updated :P 12:34:49 <planetmaker> :-) 12:35:25 <V453000> Phazorx: I see you found YACD :) I have a question; do you see any purpose of a train junction? I mean, a train junction obviously allows trains to go to different destinations, but you have to build these trains, manage their amount, and build the junction itself. While if you build just a transfer station from 3 directions instead of the junction, you dont build the junction, you simply send point to point trains from each directi 12:35:57 <Phazorx> efficiency 12:36:02 <V453000> you get solved out the "local" destinations, and the new destinations added after trains stuff grows 12:36:06 <Phazorx> cargo needs to ber ubnlaoded and reloaded 12:36:09 <Phazorx> that costs time 12:36:23 <V453000> time, but junction takes more space and a lot more complexity 12:36:38 <V453000> making something more complex for less gain sounds strange 12:36:53 <V453000> loading time isnt that much of an issue I think 12:37:09 <Phazorx> if sorting yards would be an option in ottd, you could match cars into trains by destiantion (like it is in real world) 12:37:31 <V453000> right well that is sort of what happens in such stations 12:37:57 <Phazorx> with realistic loading it takes too long to be profficient 12:38:06 <V453000> not really 12:38:17 <V453000> profit isnt an issue 12:38:26 <Phazorx> i played with PBI once where i had to use feeders on both ends, it was barely making profit 12:38:30 <Phazorx> it is :) 12:38:54 <Phazorx> it sort of depends on what is your goal and how you see the game 12:39:24 <Phazorx> but if we get to trainyards - that could be fun but totally different game 12:39:27 <V453000> yes but by using stations to transfer stuff you even get more cargo as the destinations get found more easily 12:39:37 <V453000> so im not even sure if the profit is actually better 12:40:09 <Phazorx> well stoping starting loading and unloading all costs time, a lot of it 12:40:32 <Phazorx> even moderate station walking wont save the situation imho 12:41:12 <V453000> okay, but to ignore the profit part, can you think of any advantage of the junction over a station systematically? 12:41:14 <V453000> I cant 12:41:31 <Phazorx> it takes the fun away ? 12:41:39 <V453000> well obviously 12:42:09 <V453000> but then my issue is that the stations do "too much" 12:42:12 <Phazorx> i like routing as part fo the game, efficient routing especially, i like to perfect my network to a point when trains are almost always moving 12:42:34 <Phazorx> with 3x station serving as intermediate xfers i get most of trains staying and waiting for cargo to load 12:42:47 <Phazorx> that is a bit borring and distatstefull to me 12:42:59 <Phazorx> my current aproch is - i make termianls when i switch carrier type 12:43:13 <V453000> carrier type? 12:43:24 <V453000> like refit? 12:43:25 <Phazorx> sort of like bus/tram to subway, subway to intercity, intercity to airport 12:43:34 <V453000> ah right, passengers :) 12:44:01 <Phazorx> well truck to station, station to port, ship to destination 12:44:32 <V453000> yes that is very point to point for instance :p 12:44:33 <Phazorx> doesnt matter but if cargo switches type of vehicle it is being on - i accept transfer terminals 12:45:03 <Phazorx> if it's train to train to train - i say it's either a job for destination sorter or there needs to be sorting yard in game 12:45:05 <Ammler> ok :-o 12:45:15 <Phazorx> because dumping all cargo just because is a bit silly 12:45:43 <V453000> sure, it is silly indeed 12:46:05 <V453000> but effective, especially with the "local destinations" and the new destinations that get added when industries grow 12:46:14 <Phazorx> and if it's A-hub-B scenario, where train just stops at intermediate hubs to pickup more cargo - you still need rails to route it and hence junction 12:46:30 <Phazorx> define effective :) 12:46:52 <Phazorx> dual MSRN pickup/delivery for PBI that is effective 12:47:19 <V453000> well effective both in space and system 12:47:28 <Phazorx> extendable SML megaloop with traffic packers - that si effective too! 12:47:31 <V453000> transfer station is a small thing compared to a junction 12:47:49 <Phazorx> it is, but how do you call it effective if it costs you time and money? 12:47:57 <Phazorx> what is efficiency for you? 12:48:03 <V453000> it is, profit doesnt matter 12:48:22 <V453000> profit can change just by changing the settings, newGRFs and what not 12:48:29 <Phazorx> i mean WHAT exactly do you consider as criteria for efficiency? static size? 12:48:33 <Phazorx> *station 12:48:52 <V453000> in this specific case, gaining some throughput over a limited amount of space 12:49:09 <V453000> if you have a web of point to point stations it is about the smallest thing you can build ever 12:49:12 <Phazorx> well with same grfs you would get more profit off junction based network than from transfer based 12:49:15 <V453000> and it does everything 12:49:58 <Phazorx> V453000: well, segregated netowrking has opne major drawback - you have to manage each one individually 12:50:04 <Phazorx> think about SRNW/MSRN 12:50:17 <V453000> but that is the curious thing 12:50:23 <V453000> you do manage train count in each of these 12:50:33 <V453000> but they handle the cargo destinations completely automatic 12:50:48 <V453000> idk what msrn is 12:50:58 <Phazorx> i'd rather spend my time laying tracks than adding/removing trains to be honest 12:51:27 <Phazorx> V453000: it;s on wiki and google 1st link 12:51:30 <V453000> me too, but I hate to search for all destinations and check if there isnt a destination added 12:51:55 <Phazorx> well that is a problem with destination based aprioach that you are suing 12:52:15 <V453000> sure but that is what yacd makes me to do 12:52:19 <planetmaker> msrn = mobile station roaming number? 12:52:24 <Phazorx> i mean cargodist would be an answer to that - only servisable destinations are possible 12:53:03 <Phazorx> http://bit.ly/RCS7xQ 12:53:05 <Webster> Title: Let me google that for you (at bit.ly) 12:53:06 <planetmaker> Personally I'm not too fond of cargodist. It gives no real incentive. It just distributes the stuff differently than before. And you might need more vehicles 12:53:14 <V453000> cargodist is ... odd 12:53:18 <planetmaker> yacd on the other hand gives incentive. As you need to establish certain connections 12:53:33 <V453000> btw I read that article on msrn before, dont understand what it is for 12:53:38 <planetmaker> and it increases difficulty by quite a bit by reducing the (initially) available cargo 12:53:40 <Phazorx> planetmaker: with limited number of industries and types of cargo it is managable 12:53:49 <Phazorx> but with many it becomes quite hectic i think 12:54:08 <planetmaker> both is managable, Phazorx. 12:54:21 <planetmaker> but cargodist is - to me - the wrong approach. It's boring as it gives no incentive 12:54:36 <planetmaker> only result is adding more vehicles to the same network. From a gameplay perspective 12:54:52 <planetmaker> while yacd actively drives where and how the network expands 12:54:52 <Phazorx> it depends how your network looks like 12:55:03 <Phazorx> you could have a lot of options for same network 12:55:06 <planetmaker> (don't look at the final part. Look at how you build) 12:55:17 <planetmaker> try a game with each. And see the difference 12:55:23 <Phazorx> i will 12:55:37 <Phazorx> yacd just finished compiling :) 12:58:21 <Phazorx> V453000: i never finished a game example actually 12:58:44 <Phazorx> but what i had was ratger specific design 12:59:06 <Phazorx> due to PBI industries with capacities 12:59:36 <V453000> well making multipoint srnw isnt really a hard thing 12:59:42 <Phazorx> i had a collector network leading to terminal and from terminal another network which was picking up goods from single station but delivering it to different drops 12:59:45 <V453000> even with any amount of cargoes 13:00:11 <Phazorx> err... i had with single cargo type 13:00:11 <Phazorx> and it is quite bulcky 13:00:16 <V453000> yeah 13:00:20 <Phazorx> but it's very maintanable 13:00:41 <V453000> if you use a relatively standard srnw, with just one order as unreachable waypoint, you can do basically anything with the trains 13:00:48 <Phazorx> after it is setup you only manage timer trains for drops to maintain capacity 13:00:52 <V453000> split them, make them go anywhere, merge them back, anything you want 13:01:19 <V453000> we used something like that just a few public server games ago actually 13:01:38 <Phazorx> yeah... my point was that it's a network that does destination management by nature 13:02:04 <V453000> that is done by the station timing? 13:02:05 <Phazorx> you create station, connect it to network, setup timer, and you done 13:02:12 <V453000> ye 13:02:22 <V453000> that could be done in various ways, counters, timers, splits 13:02:44 <Phazorx> timer is most viable since cargo consumption is time absed 13:03:02 <V453000> well you could even just limit it with a long signal gap 13:03:29 <Phazorx> not easily probably 13:03:46 <V453000> depends how much do you need to limit it 13:03:51 <Phazorx> i cant say my idea of timer based drop is very space efficient but it was working 13:03:54 <V453000> and how far it is from the split :) 13:03:59 <Phazorx> well it is months 13:04:11 <Phazorx> i had timer trains on 50-150 days 13:04:15 <V453000> idk when we played with pbi it wasnt that strict 13:04:35 <V453000> secondary produced like 2000 max? 13:04:46 <Phazorx> much less than that 13:04:57 <Phazorx> 500-600 was max i saw with 3x-4x that in stockpile 13:05:19 <Phazorx> so if your train fits 600 cargo you only need one per month 13:05:26 <V453000> 900 for food plant 13:05:34 <Phazorx> i was using something else for sure 13:05:43 <V453000> uh well 600 train is a big thing 13:05:52 <Phazorx> 600 is top 13:06:18 <Phazorx> again it's not the number that is important 13:06:22 <V453000> what trian lenght is that 13:06:30 <Phazorx> i used 5 13:06:40 <V453000> @calc 600/8 13:06:40 <Webster> V453000: 75 13:06:47 <V453000> considering 8 wagons 13:07:23 <V453000> no train set has that :) 13:07:29 <Phazorx> i dont recall ukrs fitting mroe than 60 anything 13:07:48 <V453000> 60 is the most capacity that some sets have which is imo broken 13:07:58 <V453000> 40 I think is reasonable maximum 13:08:02 <Phazorx> but that si still 20-25 days worth of carrgo per train at max production 13:08:16 <V453000> maybe half in the days 13:08:21 <V453000> cargo isnt produced 1:1 13:08:34 <V453000> so it might accept, say, 800, produce 600 13:08:35 <Phazorx> and for 20 days worth of signal gap you need a lot of room 13:08:37 <V453000> idk what is the ratio 13:08:44 <V453000> yes that is a lot 13:08:50 <Phazorx> and you need to change that as consumption changes 13:08:53 <V453000> well a timer isnt a terribly big thing :) 13:09:00 <Phazorx> changing day counter on timer train is much more feasible 13:10:00 <V453000> hmm 13:10:05 <V453000> if only pbi industries didnt die :) 13:10:26 <Phazorx> there was a patch setting for that 13:10:40 <V453000> patch setting? :d 13:10:47 <V453000> like openttd sided? 13:11:32 <Phazorx> yup 13:11:42 <Phazorx> engine setting that stops industries from closing 13:12:04 <V453000> that is the only thing I seriously hate about pbi that makes me not play it 13:12:23 <V453000> or use farms/forests only but that is a bit ... 13:14:40 <Phazorx> well my point was that efficinecy as i see it is in network design, not necesasry junctions only, but something more complex than p2p lanes that go from one transfer point to another 13:14:40 <V453000> why dont you join us on the public server anyway? :D 13:14:50 <Phazorx> i'm at office atm actually 13:14:56 <V453000> oh :) 13:15:01 <Phazorx> and more insterested in coding rather than playing :) 13:15:24 <Phazorx> and i wanted to spend some time to educate myself on subject of routing and destinations in mdoern ottd 13:15:28 <V453000> well I spend more time with newgrf making than playing myself :) 13:15:47 <Phazorx> yeah, modding is mroe fun for a developer than playing usually 13:17:03 <V453000> well im not really a programmer so it is fun for me to make a train set as it directly influences the gameplay :) 13:17:50 <Phazorx> heh want an idea for a fancy grf? 13:19:51 <V453000> interest me :) 13:21:04 <Phazorx> it would be cool if electicity would become 'a virtual cargo' and would be required to use elrails/subway/trains, proportional to at least infrastructure (if not traffuc). So you could stick to steam/diesel... but if you want cool el/mono/mlev you would have to provide coal to power stations which in turn woudl produce power that you need 13:21:33 <V453000> ah yes :) 13:23:43 <Phazorx> it is possible now since infrastructure is properly accounted 13:24:04 <Phazorx> and btw, last feature i asked for only took like 8 eyars 13:34:00 <Phazorx> is there some wiki page for yacd 13:34:32 <Ammler> you didn't even search for it :-P 13:34:46 <Phazorx> i dont even know how to start now, threatened by not knowing whether there is a point in building the route because cargo could not be going to where i build it 13:34:49 <Ammler> I would guess, the wiki page is exactly called that way 13:35:01 <Phazorx> Ammler: i'm on ttfoums thread for it 13:35:29 <Ammler> @man yacd 13:35:30 <Webster> Search results for "yacd" - OpenTTD - http://wiki.openttd.org/wiki/Special:Search?go=Go&search=yacd 13:36:18 <Phazorx> i think i grabbed something wrong 13:36:26 <Phazorx> i dont even have new buttons on mapui 13:36:50 <Phazorx> version says g000cdb12-region 13:37:20 <Phazorx> and i cloned this https://github.com/benjeffery/openttd.git 13:37:28 <planetmaker> err what? 13:37:33 <Ammler> hmm, but there was a yacd wiki page, wasn't? 13:37:47 <planetmaker> I've never seen that url, Phazorx 13:37:56 <Phazorx> it was linked in thread stating it's latest with michi_cc's patches 13:37:58 <Phazorx> Ammler: nope 13:38:08 <Phazorx> it is only mentioned on cargo dest page 13:38:56 <Phazorx> damn 13:39:01 <Phazorx> i fetched wrong branch 13:54:27 <Phazorx> hrm... okay even on correct branch i see no yacd stuff 13:54:39 <Phazorx> what is proper, updated repo? 13:55:29 <Ammler> Phazorx: yacd or carcodist? 13:55:36 <Phazorx> yacd 13:55:47 <Ammler> something on the michi_cc domain 13:56:36 <Ammler> which is linked at least from tt-forums 13:57:04 <Ammler> yacd is around 1 year old 13:57:05 <planetmaker> Phazorx: icosahedron.de As I said before ;-) 13:57:08 <Phazorx> well it is updated more than a year ago 13:57:22 <Phazorx> http://www.icosahedron.de/openttd/git/yacd.git that i mean 13:57:40 <Ammler> might be it, there were no new changes 13:58:02 <planetmaker> yes, that's yacd from its author 14:14:54 <Phazorx> hrm... is there more recent version by any chance? 14:15:03 <planetmaker> nope 14:15:09 <Phazorx> this one is not compatible with 1.2.X installs 14:15:12 <planetmaker> or not that I know 14:15:15 <Phazorx> cant see grfs 14:15:33 <planetmaker> symlink data to newgrfs 14:15:38 <Phazorx> and same cfg doesnt work 14:15:41 <planetmaker> or simply update it 14:15:47 <Phazorx> planetmaker: well i gotta unpack and rename them 14:15:48 <planetmaker> same cfg should work 14:15:53 <Phazorx> it doesnt see tars 14:15:58 <planetmaker> that's not true 14:16:08 <Phazorx> planetmaker: it works but it complains about unrecognized options 14:16:18 <planetmaker> "unrecognized options"? 14:16:30 <Phazorx> [2012-08-09 18:13:17] dbg: [misc] Invalid display option: identifier 14:16:37 <Phazorx> invalid value 'SHOW_TOWN_NAMES|SHOW_STATION_NAMES|SHOW_SIGNS|FULL_ANIMATION|FULL_DETAIL|WAYPOINTS|SHOW_COMPETITOR_SIGNS' for 'display_opt' 14:16:45 <planetmaker> yes. But that doesn't matter 14:17:15 <Phazorx> http://dpaste.com/783826/ 14:17:16 <Webster> Title: dpaste: #783826 (at dpaste.com) 14:17:38 <Phazorx> all these grfs are seen by official 1.2 last trunk, and cargodist 14:17:41 <V453000> it could be for example incompatible with some newer newGRFs ... is incompatible with NUTS for example, I guess dutch train set would do the same 14:18:13 <Phazorx> well it doesnt know if it compatible it can not find them in ~/.openttd/content_download/data 14:18:17 <planetmaker> Phazorx: yes... symlink data to newgrf folder 14:18:32 <planetmaker> the folder structure / names changed 14:19:05 <Phazorx> will palne ranges work with this btw? 14:19:22 <planetmaker> only in 1.2 14:19:27 <Phazorx> damn 14:19:36 <Phazorx> i guess i need to find a working patch then 14:19:38 <Ammler> fork yacd and update it :-P 14:19:49 <planetmaker> my thought ^ 14:19:57 <Phazorx> Ammler: i'd like to know what i am doing 14:20:01 <planetmaker> working patch? Just clone and merge with trunk 14:20:05 <Ammler> :-) 14:20:07 <Phazorx> at this point i wont even know if something is not working 14:20:20 <planetmaker> if you like, do the merge step-wise 14:20:30 <planetmaker> every 100, 250 or whatever revisions 14:22:37 <planetmaker> Phazorx: I don't think many crucial things changed on what yacd relies on 14:22:54 <planetmaker> so an update should not include a re-write 14:31:00 <Phazorx> /home/pkolla/source/yacd/trunk/src/economy.cpp: In function ‘void LoadUnloadVehicle(Vehicle*, StationCargoList::OrderMap (&)[32])’: 14:31:03 <Phazorx> /home/pkolla/source/yacd/trunk/src/economy.cpp:1342:42: error: ‘CargoHasDestinations’ was not declared in this scope 14:31:23 <Phazorx> welll no... i dont know what i am doing so i give up 16:03:50 *** ODM has joined #openttdcoop.devzone 16:30:29 *** frosch123 has joined #openttdcoop.devzone 17:11:48 *** Nat_aS has quit IRC 17:11:51 *** NataS has joined #openttdcoop.devzone 17:18:08 <Brot6> Central European Train Set - Revision 701:fac78eec4794: make sure to initialize (most) properties to... XEddiX @ http://dev.openttdcoop.org/projects/cets/repository/revisions/fac78eec4794 17:26:08 *** Alberth has joined #openttdcoop.devzone 17:34:00 <Brot6> cets: update from r700 to r701 done (195 warnings) - http://bundles.openttdcoop.org/cets/push/r701 17:36:12 <Brot6> cets: update from r700 to r701 done (195 warnings) - http://bundles.openttdcoop.org/cets/nightlies/r701 17:38:41 <Brot6> worldairlinersset: update from r733 to r746 done (50 warnings) - http://bundles.openttdcoop.org/worldairlinersset/nightlies/r746 17:43:47 <Brot6> rust: compile of r23 still failed (#4102) - http://bundles.openttdcoop.org/rust/nightlies/ERROR/r23 17:44:31 <Brot6> make-nml: compile of r14 still failed (#4048) - http://bundles.openttdcoop.org/make-nml/nightlies/ERROR/r14 17:45:23 <Brot6> dach: compile of r54 still failed (#4104) - http://bundles.openttdcoop.org/dach/nightlies/ERROR/r54 18:01:05 <Brot6> zBase - Bug #4150 (Reopened): towns/temperate/1501-1506 XAlberthX @ http://dev.openttdcoop.org/issues/4150#change-11341 18:25:01 <Brot6> zBaseBuild - Revision 108:b50ef095674c: Add: 1501-1506 and 1513-1518, offset-fix 1444-1446 XAlberthX @ http://dev.openttdcoop.org/projects/zbasebuild/repository/revisions/b50ef095674c 18:52:00 <Rubidium> NML feature request: not providing a 32bpp replacement sprite for a particular block 18:52:57 <Rubidium> the tram sprites have some GUI stuff, which isn't drawn yet. But since it's one replacenew for the all tram graphics I can't partically add 32bpp sprites 18:55:02 <Brot6> zBase - Bug #4149: sprites in towns/temperate/1492-1495 unclear XAlberthX @ http://dev.openttdcoop.org/issues/4149#change-11342 18:56:26 <Brot6> zBase - Bug #4151: weird named directories XAlberthX @ http://dev.openttdcoop.org/issues/4151#change-11343 18:58:18 <Brot6> zBase - Bug #4151: weird named directories XAlberthX @ http://dev.openttdcoop.org/issues/4151#change-11343 19:02:10 * Rubidium is trying to do some signals 19:18:06 <Alberth> pushed some more buildings 19:18:15 <Brot6> zBaseBuild - Revision 109:c20784067989: Add: towns/temperate/1492-1495 and towns/temperate/1596-1497... XAlberthX @ http://dev.openttdcoop.org/projects/zbasebuild/repository/revisions/c20784067989 19:25:05 <Brot6> zBaseBuild - Revision 110:606bffce17b1: Add: signals XRubidiumX @ http://dev.openttdcoop.org/projects/zbasebuild/repository/revisions/606bffce17b1 19:28:25 <Rubidium> another 384 sprites done ;) 19:34:27 <Alberth> that's a lot :) 19:35:02 <Rubidium> one template with (basically) 8 different sprites, multiplied by signal types 19:35:21 <Rubidium> so loads of copy-paste-change-offset 19:38:14 <Brot6> NewGRF Meta Language - Feature Request #4152 (New): Partial alternative sprites XRubidiumX @ http://dev.openttdcoop.org/issues/4152 19:44:53 <Rubidium> hmm... 19:46:04 <Brot6> NewGRF Meta Language - Feature Request #4152 (Closed): Partial alternative sprites XRubidiumX @ http://dev.openttdcoop.org/issues/4152 19:46:04 <Brot6> NewGRF Meta Language - Feature Request #4152 (Closed): Partial alternative sprites XRubidiumX @ http://dev.openttdcoop.org/issues/4152#change-11344 19:50:59 <planetmaker> Rubidium: you can also specify offsets for replacenew 20:05:23 * Rubidium misses the stagger in the catenary 20:38:48 *** frosch123 has quit IRC 20:39:32 <Brot6> zBaseBuild - Revision 111:ea477560a3e4: Add: Airport hangar XAlberthX @ http://dev.openttdcoop.org/projects/zbasebuild/repository/revisions/ea477560a3e4 20:39:32 <Brot6> zBuild - Revision 46:a8a88092276f: Change: update zbuild XAlberthX @ http://dev.openttdcoop.org/projects/zbuild/repository/revisions/a8a88092276f 20:39:57 <Alberth> good night 20:42:21 <Rubidium> night Alberth 20:43:20 *** Alberth has left #openttdcoop.devzone 21:07:34 <Brot6> zBaseBuild - Revision 112:d8abe8789e23: Add: catenary XRubidiumX @ http://dev.openttdcoop.org/projects/zbasebuild/repository/revisions/d8abe8789e23 21:16:57 *** ODM has quit IRC 21:17:38 <Rubidium> Yexo: http://rbijker.net/openttd/32bpp_todo.txt <- updated version if/when you're interested 21:18:00 <Rubidium> oh, was planetmaker interested in coding 32bpp as well? Then the line before is interesting for you as well 21:18:46 <Rubidium> anyhow, it's based on the sprite folders that exist and the sprite folders that are found in the nfo of the nmls, so if something is partially coded it doesn't show up 21:19:02 <planetmaker> yes... but not while I'll be in the Alps the next 6 days 21:20:44 <Rubidium> looks like there are a few false positives as well (materials and resources) 21:21:33 <Rubidium> time for some Zs though 21:21:48 <planetmaker> :-) enjoy your Zs :-) 21:22:14 <planetmaker> And have a nice week ... I'll be back shortly on Thursday, really back on Sunday night 21:57:53 <Brot6> zbuild: update from r45 to r46 done - http://bundles.openttdcoop.org/zbuild/push/r46 22:28:02 *** extspotter has joined #openttdcoop.devzone 22:56:09 *** michi_cc has quit IRC 22:56:12 *** michi_cc has joined #openttdcoop.devzone 22:58:54 *** extspotter has quit IRC