Cargo Distribution

[petert]

Fonso, Could you teach me how to do that branch trick; One branch is trunk, and one branch is CargoDist? That would be great because then I could try to merge CargoDist against a newer trunk before you update the GIT repo.

[fonso]

I suppose you have a branch named "cargodist" in your repository. That branch contains the latest version of cargodist. Then do the following:

Code: Select all

git fetch git://git.openttd.org/openttd/trunk.git master:trunk

This will give you a new branch named "trunk" with the latest version from openttd trunk (of course you can choose a different name). Then you can do

Code: Select all

git checkout cargodist
git merge trunk

This should merge all changes from trunk into your cargodist branch. You might get conflicts though. If you resolve them in a different way than I do you might get funny problems next time you pull from my repository. But you can always delete the cargodist branch and recreate it from my repository with the following commands

Code: Select all

git branch -D cargodist
git fetch http://fickzoo.com/fonsinchen/openttd.git cargodist:cargodist

[petert]

How would I only get a certain revision of trunk, lets say r18797?

[fonso]

You can always do "git log". Then you see the revision history for your current branch. Something like this:

Code: Select all

commit 27177a3e828a842b67b377752fc6c340f0db8ddf
Author: alve <alve@ente.(none)>
Date:   Sat Jan 16 17:31:59 2010 +0100

    simplify moving averages

commit 84cd40a48361daeb4f00dd4b1195bc3d577691e4
Author: yexo <yexo@openttd.org>
Date:   Fri Jan 15 12:08:08 2010 +0000

    (svn r18807) -Codechange: introduce AirportSpec and move several non-statemachine-related variables to ther

You can checkout those commit tags and optionally make the checkout a new branch. For example you can do:

Code: Select all

git checkout -b trunk18807 84cd40a48361daeb4f00dd4b1195bc3d577691e4

Then you have a branch named "trunk18807" with the equivalent of SVN revision 18807.

[petert]

You can always do "git log". Then you see the revision history for your current branch. Something like this:

I assume that shows the entire revision history of the branch, so I can checkout older revisions?

[fonso]

I assume that shows the entire revision history of the branch, so I can checkout older revisions?

Yes, it does. You don't have to worry though.
a, it's much faster than for example "svn diff"
b, if you don't pipe it into anything else git automatically pipes it through "less". Like this you can search things with "/" and "?". (I'm still wondering how git manages to know what I'm doing with the output)

[Rubidium]

I'm still wondering how git manages to know what I'm doing with the output

By using isatty.

[petert]

Hi fonso,
I have manged to merge CargoDist with r18797 with the amazing commands you have provided. As a little tip, I have found it easier to go to this site (http://vcs.openttd.org/git?p=openttd/tr ... ;a=summary), then look for the revision and find the commit section and copy that. git log creates problems for me. Git is quite a good VCS with branches, I see why you have chosen it.

Binary coming up.

[petert]

Here is another binary, r18797 with MSVC. This build has the train wagon bug fixed.

Disclaimer:
If CargoDist crashes, do not report it to the OpenTTD developers. Report it to this thread. When making your post about the crash, please upload the crash.dmp, crash.log, crash.sav, and crash.png (only available as of r18184, so if you are using a build older than that, don't bother). These files are vital to finding what happened during the crash. For developers, you can find the PDB file and other files at this site: http://users.tt-forums.net/petert/dev/

Peter

[fonso]

petert, thanks for merging and building the binary. I see you're getting familiar with git.

However, if you modify the source code (which you do when merging in a new revision of trunk) it's important to post the modifications. Otherwise I can't debug crashes with it and various people can get you into legal trouble as the GPL makes it illegal to post binaries without source code. To get the modifications checkout your cargodist branch and do

Code: Select all

git diff trunk > cargodist.diff

Then you have a new file called "cargodist.diff" (of course you can choose a different name) which contains all differences between your version of trunk and your version of cargodist. Please post it somewhere and don't forget to mention the trunk SVN revision it's based on. Maybe post it at the same place as the PDB files?

I'm working on the improvement of moving average lengths right now. Someone suggested I make the moving average lengths proportional to the distance between the endpoints of a link. When I finish this you'll get a new version.

[petert]

I can get you a diff when I'm at my computer later today.

Also, I was making a diff between the newmusic.git repo (by orudge) and trunk and it seemed to be completely backwards.

Is this the correct command?

Code: Select all

git diff master trunk > newmusic.diff

or do I switch to the master branch, then do?

Code: Select all

git diff trunk > newmusic.diff

[fonso]

petert, depending on the number of arguments "git diff" does the following:

• no arguments: show the difference between the current branch and the files in the checked out copy (ie your local modifications which you haven't committed yet).
• one argument: show the difference between the checked out copy and the specified argument (a branch, a commit or whatever)
• two arguments: show the difference between the two arguments
• more arguments: probably other things I don't know from the top of my head

The "> bla.diff" part redirects the output to a file you can post here. It doesn't change anything about the contents. So "git diff master" shows the difference between your current state and the branch "master". "git diff master trunk" shows the difference between the branches "master" and "trunk" which is probably pointless. "git diff trunk cargodist" shows the difference between the branches "trunk" and "cargodist" and so on.

Another hint: You can see what branches you have by doing "git branch" without any arguments.

Please do read the git documentation. There is enough of it and I'm getting tired of spoon-feeding it to you.

[petert]

Ok, I've attached a diff here: http://users.tt-forums.net/petert/dev/C ... ustom.diff

Edit: Wow! In the documentation they have things like git-apply!

[el koeno]

Hi Fonso,

In my current game the diamond "chain" (default sub tropical climeate) did not function. When preparing to make a bug report I noticed that this was because the ARMOURED class was set to symmetrical, and setting it to antisymmetrical fixed the issue. Is this a default setting? I wouldn't know because I've been using my openttd.cfg for a while. But if it is, it might be a good thing to consider changing this. On the other hand, in the default temperate climate symmetrical might be more interesting...

Anyway, I figured this might be something you haven't thought about, and I thought I'd bring it up.

[ostlandr]

Thank you! That was an annoying bug.

I really enjoy playing with CargoDist. So far, no issues between CargoDist and Pikka's Basic Industries. Also, the "early houses" grf seems to do it's job reducing passenger generation in line with capacities of the early vehicles available in NARS 2 and eGRVTS.

I find that my games with CargoDist have a more realistic feel. With the exception of unit trains, most every train has goods cars of some type in it, and is getting revenue from backhaul. If I can provide service, the industries will route cargo to the most remote locations.
One of my pet peeves in OTTD was (for example) not being able to prevent a train with both goods and lumber wagons from loading goods at a sawmill station. CargoDist makes that a non-issue. And as I have mentioned before, flying valuables between cities is now an easy and profitable operation with no elaborate transfer schemes. Oh, and airports built a safe distance from the center of town are now viable, as is the high-speed rail network connecting it to the main station. I have even built one airport to serve several towns, with bus & mail truck service connecting them. And gee, passengers from one town to another are transferring at the airport bus stop!

The interface works for me also. Nice to be able to look and see that "Oh, there are 342 passengers waiting to go from Dogtown Central to Whiskey Bridge Central- I should route an express bus that way." Of course the whole thing is dynamic, so some passengers going to Whiskey Bridge or Whiskey Bridge West may want to take that route also- I really have to manage my fleet and routes.

Here is another binary, r18797 with MSVC. This build has the train wagon bug fixed.

Disclaimer:
If CargoDist crashes, do not report it to the OpenTTD developers. Report it to this thread. When making your post about the crash, please upload the crash.dmp, crash.log, crash.sav, and crash.png (only available as of r18184, so if you are using a build older than that, don't bother). These files are vital to finding what happened during the crash. For developers, you can find the PDB file and other files at this site: http://users.tt-forums.net/petert/dev/

Peter

[DJ Nekkid]

wanna post that savegame?

[bokkie]

ostlandr: you might want to try the "automated timetables and separation" patch (http://www.tt-forums.net/viewtopic.php? ... 16#p850616) for your

bus & mail truck service connecting them

for even more fun

[fonso]

I've uploaded a new version. The most significant change is in the handling of moving averages. The moving average length setting is now a minimum length for moving averages. This length is applied to supply at stations. For link stats (capacity, usage, sent) the moving average is (min_length + link_distance / 4). This makes longer links time out slower and shorter links time out faster. The rationale is that I expect people to use many small vehicles on short links and few large vehicles on long links. This means a long link with the same capacity will have fewer vehicles arriving in a given time than a short link. Thus with the old system of uniform moving average lengths the long link would constantly time out or be reduced to very small values even though it was actually served by a vehicle. This should be fixed now. To accomplish that I have written a small class to handle general moving averages. Its inclusion is a rather big change, though. If you see anything strange please report it.

As an added benefit I can use those moving averages for supply scaling now ...

[popewiz]

Sounds like a solid change. Will this effect station ratings though? The problem with long routes with few large trains was always that the station ratings would plummet between arrivals and there wouldn't be any waiting cargo.

[Arie-]

Sounds like a solid change indeed, i had solved this a bit as i usually only allow myself to play with station having a max length of 3 tiles, a few decades into the game traffic on most links is already high enough.