Transport Tycoon Forums

It is possible to delete specific node in game? (i.e it can be implemented?)

Example) I have station A, B, and I deleveres passenger and mails between A and B.

After, I make station C, which is between station A and B.

I changes every trains operated between A and B should be stopped in C.

Then, there is 3 nodes: A-C , B-C, and A-B. But as I wrote, A-B is no longer available.

The problem is : node A-B will be deleted, but it is (sometimes) too slow to delete, especially with other patches. (If you use daylength patch and that node delevers lot`s of cargo, then it may take several months to delete completely.) During this period, pass and cargos are stacked in A and B.

My point is, If we can delete (will be unused) specific node in game, it`ll help to play games more effectively

Or maybe so often do a check if there are any vehicles ordered to travel between two stations? If not, and no such vehicle appears in 100 ticks, the node is deleted and all passengers are rerouted via other routes, if possible, to get to the destination station.

It would be a bad idea to delete links after a fixed amount of time as quite often there are very long links served by few large vehicles which arrive only very infrequently. Still, those links are valid. Each link times out after a while if it's not served anymore. The time it takes depends on the length of the link. Compatibility with daylength is not the focus of this patch. Of course you could implement a way to manually delete links, but it would take some work (it would have to be a network command and you'd have to take care about desyncs).

fonso wrote:It would be a bad idea to delete links after a fixed amount of time as quite often there are very long links served by few large vehicles which arrive only very infrequently. Still, those links are valid. Each link times out after a while if it's not served anymore. The time it takes depends on the length of the link.

But if there is no vehicle servicing the link, then there is no reason to keep the link.

but it is impossible to detect whether no vehicle is servicing the link, as soon as conditional orders come into play

that also means that it can be detected (easily) as long as no orders are conditional

I never use conditional orders (with the exception of maintenance of course, which won't have any negative effect here). Also "not served" can also just be interpreted as "a vehicle having the stations in the appropriate order in it's schedule" and just ignore the fact that it might not be in actual use since at least one of those entries is conditional. In that case the timeout mechanism would eventually remove the link.

Especially in small (early) inner-city networks changes to schedules are quite common. Adding another stop between two existing ones would cause passengers to pile up, attempting to use the no longer serviced direct connection instead of hopping on the new route.

On the other hand a link shouldn't be removed the very instant no vehicle has them in it's orders as someone might just be replacing vehicles (not using the provided mechanics/interface for it). If he first decommissions the old one(s) and the buys and assigns the newly bought one(s) the link would be gone, which would be bad
So some (fixed) small amount of time should be allowed for the link to remain even if no vehicles are serving it I suppose...

You may want to look at the bug report (wrongly) added to the official bug tracker: http://bugs.openttd.org/task/4682

I asked this to Chillcore in his patchpack thread but he diverted me to here... I was just wondering:

When trains pick up waiting cargo, how do they decide which to pick up? Does it choose that which has waited the longest?

Thanks,
Wasila

Is this fork still maintained and developed?

Why does the EXPRESS cargo function choice disappeared from the last versions of CargoDist?

The express options was considered confusing as no one really knows what cargoes are EXPRESS in a given cargo set. They don't really form a special case in light of cargodist. They were only included due to a misleading comment in the code that says passengers could be EXPRESS.

I'm occasionally updating the code with changes from trunk but I'm not actively developing it any further as YACD is generally the better approach to cargo destinations. There is one feature that's specific to Cargodist and somewhat in conflict with YACD's way of doing things: the automatic distribution based on existing network. However, this can be implemented on top of YACD, as I have demonstrated (Distyacd). However, I don't have the time and energy to take over YACD development, neither do I want to update Distyacd to an already outdated version of YACD and I also don't want to give up maintenance of Cargodist (to free some time and energy) as long as YACD's development isn't resumed. So we're in some kind of deadlock right now. Sorry to say that.

fonso wrote:The express options was considered confusing as no one really knows what cargoes are EXPRESS in a given cargo set. They don't really form a special case in light of cargodist. They were only included due to a misleading comment in the code that says passengers could be EXPRESS.

There was a page in old wiki (http://wiki.ttdpatch.net/tiki-index.php ... rgo_Labels) which is unfortunately not working now. On that page was pointed, which cargoes are EXPRESS and ARMORED... I used EXPRESS option with ECS to allow distribution of Food and Goods with other cargoes (except Passangers and Mail) not distributing. And now I don't know how to provide such behaviour...

Kraks wrote:

fonso wrote:The express options was considered confusing as no one really knows what cargoes are EXPRESS in a given cargo set. They don't really form a special case in light of cargodist. They were only included due to a misleading comment in the code that says passengers could be EXPRESS.

There was a page in old wiki (http://wiki.ttdpatch.net/tiki-index.php ... rgo_Labels) which is unfortunately not working now. On that page was pointed, which cargoes are EXPRESS and ARMORED... I used EXPRESS option with ECS to allow distribution of Food and Goods with other cargoes (except Passangers and Mail) not distributing. And now I don't know how to provide such behaviour...

That moved permanently to the newgrf wiki, the non-specification parts to the tt-wiki. You might want to update your bookmarks.

I'm occasionally updating the code with changes from trunk but I'm not actively developing it any further as YACD is generally the better approach to cargo destinations. There is one feature that's specific to Cargodist and somewhat in conflict with YACD's way of doing things: the automatic distribution based on existing network. However, this can be implemented on top of YACD, as I have demonstrated (Distyacd). However, I don't have the time and energy to take over YACD development, neither do I want to update Distyacd to an already outdated version of YACD and I also don't want to give up maintenance of Cargodist (to free some time and energy) as long as YACD's development isn't resumed. So we're in some kind of deadlock right now. Sorry to say that.

A shame. I haven't yet tried YACD (not until it gets on to Chillcore's patch!) but I would be very much interested in a DistYACD branch. Has development on YACD come to a halt?

Wasila wrote:A shame. I haven't yet tried YACD (not until it gets on to Chillcore's patch!) but I would be very much interested in a DistYACD branch. Has development on YACD come to a halt?

The last code change in Michi_cc's YACD repository was on June 2nd. However, Michi_cc might be working on something without telling us. It wouldn't be the first time. In that case, I'd like to know what he is doing before doing anything myself. The whole Cargodist thing was a monstrous waste of time in a way as Michi_cc already had the basic concept of YACD two years ago and if I had known and understood it I would have done things differently. I somehow remember he mentioned his idea on IRC sometime, but I'm not sure. Maybe I wasn't listening closely enough and certainly I didn't understand what he was up to. I must admit I haven't been on IRC lately, though, so I don't quite know what's going on. On the other hand, Michi_cc usually doesn't talk a lot on IRC, either. Generally I prefer seeing the code and discussing things hands on, even if they're not ready. Michi_cc generally keeps his code secret until he thinks it's ready. Somewhere around there is the problem we're having here.

The whole Cargodist thing was a monstrous waste of time in a way as Michi_cc already had the basic concept of YACD two years ago and if I had known and understood it I would have done things differently.

I see the problem - that must have been a real shame to find out. It hasn't all been a waste of time, though; we've all been able to use your patch until now and it's always good to have more than one possibility (which could now potentially be put together).

Michi_cc generally keeps his code secret until he thinks it's ready

Perhaps you should contact him/send him a PM or something. Maybe you could try and glean some info off of him.

fonso wrote:The last code change in Michi_cc's YACD repository was on June 2nd. However, Michi_cc might be working on something without telling us.

I am working on some "secret" (not that secret, as I've already posted it on IRC ) stuff, but it has no relation to YACD, so what you see is indeed what you get. I do hope to get back to YACD soon when I've got more free time again.

-- Michael Lutz

when I compile cargodist with vc2008 or vc2010, and stay at the main page for several minutes, it hang up with an error:

expression: list iterators incompatible

and here is the crashlog

acabin wrote:when I compile cargodist with vc2008 or vc2010, and stay at the main page for several minutes, it hang up with an error:
expression: list iterators incompatible

Obviously I've broken the multimap in June. It's fixed in my git repository now. Thanks for the report.

Any chance for newer binaries? I see the newest patch is for r22941 but the latest binaries date from June.