Cargo Distribution

[Eddi]

[...] to allow me loading games created before a simple trunk savegame version bump, which should generally load just fine afterwards if I understand it correctly...

it might initially not be "easy" or "clean", but Chill's PatchPack uses a method that is derived from the ancient MiniIN.

the basic idea is the following:

• your initial patch bumps the savegame version by at least 2, and remember both the current saveload version, and the trunk saveload version
• for the settings/saveload handling, you define a macro "IN_PATCH_SINCE(version)" which expands to something like "max(CURRENT_TRUNK_VERSION+1, version)"

that way, you can ensure that you can update your savegames through at least one version bump at a time.

Fonso decided long ago that this was too much trouble for him to maintain, so he doesn't use this system.

[Michi_cc]

The only hint I've found was in Michi_CC's description of his repo, to run a "git rebase --hard origin" upon an upstream rebase, but I haven't found any reference to which extent this corrects possible issues (or even any reference to that use of rebase in the git documentation at all).

It's reset, not rebase . The hard reset bascially means "make sure my checkout matches whatever the upstream repo has, no matter what", i.e. it will thrash all local changes. If you actually want to develop on top of a branch that will be rebased, you need to updated your local branch by using "git pull --rebase" (available with all newer git versions) which will do some magic to keep your local changes intact.

-- Michael Lutz

[fonso]

I was hoping you could give me a pointer or two about how you've setup your Git repo. [...]

If you have an older copy of cargodist still lying around you can have a look at the "gitmake.mk" script (You can still get a similar thing here: https://raw.github.com/fonsinchen/opent ... gitmake.mk). It contains all the merging logic I was using until recently. Basically you define branches and depency branches for each. Then you do "gitmake.mk <branch>" and it will recursively merge everything stated as depency which has been changed since the given branch has changed. It expects a branch "<name>-tmp" for each branch <name> to "stage" the merging. This is a misnomer; it should be something like <name>-pre and you can initially just branch it from one of the depencies. The script doesn't like rebases, though and it messes up your commit history with countless merge "commits". It also makes it hard to work on things that touch multiple places in the code as it forces you to constantly switch branches. This is why I abandoned it. After all, once you've understood how it works, rebasing is not harder than merging and a non-linear commit history was sort of a misfeature for me as it just complicates everything without giving much of an advantage.

If I were you I'd keep one "messy" branch where you just commit all you're doing until something nice is finished and one "clean" branch where you assemble meaningful commits for public consumption. The clean branch would be regularly rebased on either master or cargodist and the messy branch would be thrown away and recreated based on the clean one once its contents are included in the clean branch. You can also have multiple messy and clean branches building on each other like that.

About the savegames: I'm probably going to radically reduce the version bumping in the near future as I've linearized the repository. All those +10 and +20 will disappear. You can just add some more entries to SaveLoadVersions and use those in saveload.cpp for the code building on top of cargodist.

[Creat]

The only hint I've found was in Michi_CC's description of his repo, to run a "git rebase --hard origin" upon an upstream rebase, but I haven't found any reference to which extent this corrects possible issues (or even any reference to that use of rebase in the git documentation at all).

It's reset, not rebase . The hard reset bascially means "make sure my checkout matches whatever the upstream repo has, no matter what", i.e. it will thrash all local changes. If you actually want to develop on top of a branch that will be rebased, you need to updated your local branch by using "git pull --rebase" (available with all newer git versions) which will do some magic to keep your local changes intact.

Yes of course it's reset and not rebase, that was just a brainfart (while typing) on my part. I was just not aware of any uses using a remote as an argument (that's also what I meant when talking about not finding any reference to it in the git docu).
Thanks for the tip with "git pull --rebase". I was aware of the command, but not of the fact that it would be helpful in case of an upstream rebase.

If you have an older copy of cargodist still lying around you can have a look at the "gitmake.mk" script (You can still get a similar thing here: https://raw.github.com/fonsinchen/opent ... gitmake.mk).

YES! Exactly what I was looking for! Thank you That is bloody brilliant using make for that (being not a Linux guy myself I never would've thought of that...)!
I need it mostly to propagate changes in trunk through the tree, which should most often work fine without conflicts. If I update one of the patches that is likely going to cause at least some degree of conflict and I'll need to resolve that manually anyway.

As for actually developing: I do that in a separate repository and don't plan on such a fine separation between features. It will basically be a release-branch, a development-branch and feature branches that only exist as long as they are very rough around the edges. The later ones will be merge into devel once they are basically working. Pretty standard I guess. Also it's a far cry from the complexity of CargoDist, so there aren't enough distinct functionalities to have more than 2 or 3 branches anyway.

Again: Thanks for all the greats tips and prompt help on this from everyone!

[Michi_cc]

I was just not aware of any uses using a remote as an argument (that's also what I meant when talking about not finding any reference to it in the git docu).

That's because "origin" here isn't really the remote, but a ref which would be fully spelled out refs/remotes/origin/HEAD (which will point to ref/remotes/origin/master by default, i.e. the tracking branch of master in yacd.git). Git will try to match an abbreviated ref to the present refs. This works as long as you do not have a local branch named "origin" as well, then you'd need to spell it out fully.

-- Michael Lutz

[Creat]

I was just not aware of any uses using a remote as an argument (that's also what I meant when talking about not finding any reference to it in the git docu).

That's because "origin" here isn't really the remote, but a ref which would be fully spelled out refs/remotes/origin/HEAD (which will point to ref/remotes/origin/master by default, i.e. the tracking branch of master in yacd.git). Git will try to match an abbreviated ref to the present refs. This works as long as you do not have a local branch named "origin" as well, then you'd need to spell it out fully.

Hehe, yea I just figured that out by having a good long look at the man page.

Just to avoid any confusion, I obviously "git pull --rebase" for the (local) cd branch, do I also do this for any branch based on the local cd branch? Or will a simple pull/merge do here?

[fonso]

Merging a rebased branch into one that contains the code from before the rebase won't work. You'll need to rebase everything then. But you can still use the make script. Just disallow nonlinear history (ie more than one depency per branch) and replace all "git merge" commands by "git rebase".

[Creat]

Merging a rebased branch into one that contains the code from before the rebase won't work. You'll need to rebase everything then. But you can still use the make script. Just disallow nonlinear history (ie more than one depency per branch) and replace all "git merge" commands by "git rebase".

The whole point of this exercise is to have more than one 'parent' for most branches, as I only want to combine multiple patches. Since all patches are generally against Trunk, I usually have a branch applying that patch to trunk, then one branch joining that together with Cargodist (there manual merging is often required). Finally there is one branch combining all those branches (all containing Cargodist already) into the final branch that I build from in the end (which so far worked well without conflicts).

I've also noticed that I can set branch.<name>.rebase = true, so that whenever I pull it's automatically rebased instead of merged without me explicitly stating so.

[fonso]

Merging a rebased branch into one that contains the code from before the rebase won't work. You'll need to rebase everything then. But you can still use the make script. Just disallow nonlinear history (ie more than one depency per branch) and replace all "git merge" commands by "git rebase".

The whole point of this exercise is to have more than one 'parent' for most branches, as I only want to combine multiple patches. Since all patches are generally against Trunk, I usually have a branch applying that patch to trunk, then one branch joining that together with Cargodist (there manual merging is often required). Finally there is one branch combining all those branches (all containing Cargodist already) into the final branch that I build from in the end (which so far worked well without conflicts).

I've also noticed that I can set branch.<name>.rebase = true, so that whenever I pull it's automatically rebased instead of merged without me explicitly stating so.

Maybe base the whole thing on cargodist instead of trunk? Then you don't have to do any merging and it will actually work. You can make a branch for a patch based on a trunk version your current cargodist is based on, so that the patch cleanly applies. Then just do "git checkout <branch> && git rebase cargodist" to rebase your new branch on cargodist (instead of trunk).

Right now, different versions of cargodist don't share the same history, due to the rebases. That's why you can't merge cargodist X+1 into cargodist X - or at least that will be very messy.

[Wasila]

Is this still being worked on? It would be a shame to see cargo destinations fail to reach trunk yet again, particularly since YACD seems to now be thoroughly dead. It would be shame if a rival project sucked so much energy from this one, only to bring it down with it.

[fonso]

I'm still working on Cargodist. At the moment I'm implementing support for "no unloading", "transfer" and "unload all" orders. This is a bit complicated, but it's almost finished. You can see what I'm doing in the "cdd" branch.

[steadypaws]

I'm just starting to use CargoDist and love it so far but I just noticed this behavior that I can't figure out. Am I doing something wrong with my network or is this normal?

I have two coal mines, A & B, delivering to two power stations, 1 & 2. Each mine sends trucks to each power station. Normally, everything looks great. Coal waits for each station from each mine as expected. But sometimes the power stations get coal that's meant for the other station? If I'm reading this right, a coal truck from Mine B dropped off coal at Power Station 1 that was meant for station 2? So coal is now waiting to be picked up by a truck from Mine A to be taken back to the mine and then to be taken to Power Station 2?

While it all eventually works out in the end I'm trying to figure out how the coal got to the wrong Power Station in the first place. I was using Full Load any cargo on the trucks originally as that's always the way I've done industry cargo. So I went ahead and reset them back to Load if available and waited for things to clear up but the behavior still exists.

Any ideas as to what could be causing this?

Thanks in advance!

[Eddi]

the game tries to allocate alternate routes, if it thinks that the direct route is overloaded. if you use "full load", then the usage will almost always be near 100% of the capacity, so it may think it's overloaded. in your case, this can be avoided by using "unload and leave empty" orders, so there won't be alternate routes to choose from.

[steadypaws]

the game tries to allocate alternate routes, if it thinks that the direct route is overloaded. if you use "full load", then the usage will almost always be near 100% of the capacity, so it may think it's overloaded. in your case, this can be avoided by using "unload and leave empty" orders, so there won't be alternate routes to choose from.

Thanks for the reply!

So what you're saying if my n00bness follows, is that probably the truck from Mine B that would normally go to Power Station 1 thought that the route to or vehicle station at Power Station 1 (I'm not sure which) was too crowded so dropped its load off at Power Station 2 instead to be sent to Station 1 by a different route (A->1)?

[Eddi]

no, the truck always goes the same route it is ordered to, but the cargo decided to board a different truck.

[steadypaws]

no, the truck always goes the same route it is ordered to, but the cargo decided to board a different truck.

I hope I'm not bothersome but...

So if vehicle routes are fixed, then we can tell that this coal dropped at Power Station 1 was definitely from a Mine B (B->1) truck. But it was B->2 cargo? Does that imply that there weren't enough B->2 trucks to do the job so it's trying an A->2 route instead? Or more specifically, B->2 failed for some some reason so it's trying B->1->A->2? Had there been a 1->2 route it would have tried B->1->2? Or even that I shouldn't think of it as B->2 cargo at all but rather as simply Power Station 2 destination cargo? (*lights may be coming on*)

If this is more or less correct, what condition(s) would cause an alternate route to be sought? [edit: Wait, I'm thinking about this all wrong.. There's no such thing as a primary route or such but rather a list of possible routes from which CD picks what it thinks is best at the moment?]

[fonso]

[edit: Wait, I'm thinking about this all wrong.. There's no such thing as a primary route or such but rather a list of possible routes from which CD picks what it thinks is best at the moment?]

Exactly. What Cargodist sees is the following topology:

Code: Select all

A <--------> 1
    \  /
     \/
     /\
    /  \
B <--------> 2

So there are two ways to send coal from A to 1:

a. The direct A -> 1
a. A -> 2 -> B -> 1

Of course it will prefer the direct route as that's shorter. However, if the direct route is overloaded it will also send some cargo along the longer route, avoiding the perceived jam between A and 1. You can avoid that by either explicitly ordering the vehicles to leave empty at 1 and 2 or by providing enough capacity on the direct routes.

[steadypaws]

Of course it will prefer the direct route as that's shorter. However, if the direct route is overloaded it will also send some cargo along the longer route, avoiding the perceived jam between A and 1. You can avoid that by either explicitly ordering the vehicles to leave empty at 1 and 2 or by providing enough capacity on the direct routes.

Thanks for the response!

Out of curiosity, in layman terms, how does cargodist weigh routes against each other on choosing the current one?

[Edd.Dragon]

Of course it will prefer the direct route as that's shorter. However, if the direct route is overloaded it will also send some cargo along the longer route.

Is parameter "Saturate short paths before..." used to control such decisions? Or it used in demands calculating?

Where I can find detailed settings description?

----------------

And I'm disturbed also by other question.

1. For example, we transport mail from town districts to main station. From this station by train - to main station of other town. And finally - in districts of that town. And vice versa. Works fine. So, I'm interested in algorimh of counting transfers/profits/losses(eg "cost") on each segment of this path. Without CargoDist transfering chain calculations is transparent because finall dest is uknown. But with CargoDist trip around a world will make a big loss for us, of course. So, what formulas is used to money flow while transfer chain? On which stages used "OTTD-mode" and where differenses occures? How I may counting loss value (or profit) in final of trip?

2. Usually, in little more complex graph, such this:



after some time starts regular small loses. Of course, summary cargo volume in this case is large and transport don't handle it completely. And sometimes I can see extra-looses! But no way to rewind and retrace this chain...

So, can you explain in wich cases we can see huge red numbers? Circle root to transfer by several tiles, of course - is one of them. But gathered the impression that some folks with destination not far away home was traveled to another town and back!

It is possible? And if yes, can I restrict this by Link Graph Settings?

And maybe any more cases?

---

Thanks for answer and CD )))

[Eddi]

Cargodist does not touch the payment calculation at all, it uses the same formula as trunk with the "transfer" order. see the wiki for details.

if you encounter negative income, you can try to tune down the "feeder share" setting (this does not change gameplay, only visual effect)