Cargo Distribution

[Kogut]

That game is very interesting
But why it is so laggy? Is it normal?
And desyncs - it isn't real problem, I really enjoy multiplayer cargodist and I woul'd like to play another game.

[Zuu]

fonso, I really appreciate that you did setup the multiplayer server. I hope you did get some information from it even if I understand that desync problems are very hard to find the exact cause from testing where a code review could have been as effective. However I did not mind the problems that appeared on the server as it was properly labelled as a test/debug server. I have to agree with Kogut that I had much fun playing at the server.

If there is more people who would like to play a new game, perhaps *someone* else can organize it, still labelled as unstable/testing, so that you fonso do not need to spend your time on it.

[ostlandr]

Oh, you play OTTD as a computer game. I get it now. I forget that I'm one of the minority that uses OTTD as a virtual railroad.

Well, the only annoying thing for me is, ackording to the losing-money-vehicles, that I can't reach 1000 Points...

[ostlandr]

Another trick I use is to timetable the load stop with "stay for X days." This is especially helpful with industry GRFs that produce cargo over time, when the train both drops off raw materials and picks up processed products. Just tweak the delay for the best balance of station rating and % transported. Plus, it gives the train crew time to grab lunch at the local beanery.

First regarding "full load any cargo".
Not using this is nonsense (imho, i might be wrong ) because station ratings depend on it to a large degree! If trains just visit and leave immediately the service level of stations declines a lot.

Actually you can use "full load any cargo" to your hearts content in CargoDist. Full load doesn't alter the cargo in anyway, it just increases or decreases station dwell time (potentially meaning a train never leaves a station). The ones you want to avoid are "unload" and its variants (no unload and take cargo and unload and leave empty) as these are affecting where the cargo goes.

[fonso]

I've refactored the link graph base classes. This means the code is much shorter and better documented now, but I might have introduced some bugs. Please test the result and tell me if you notice anything odd.

I also have renamed the "cargodist" branch to "cd" in order to silence the "string too long for destination buffer" thing. It happened when trying to copy the version string (including the git version tag) into a 15 byte buffer. I have also increased the debug level for various other messages ("frozen not in linkstat list", "frozen smaller than cargo cap", "orders are NULL") which are harmless most of the time. Now, if you see any debug messages in the standard output and error streams there is actually something wrong and I'd be glad to hear about it.

[Creat]

Uhm, is it just me or does the game crash for everyone the moment you click on a road vehicle depot?

Crash log/dump/save etc. are attached, but this happens every time I click on any road vehicle depot...

The version was built from an up-to-date git checkout of origin/cd, the version string is: g90e5c92a
It occurs on 64 and 32 bit builds, win7 and winxp. It also happens when I don't load any NewGRFs.

[ostlandr]

A behavior I have noticed in CargoDist: When there is a bunch of cargo to "any destination", a train will pick it up and drop it off at a station that accepts that cargo. But it won't automatically get transferred through an intermediate stop. In those situations I end up using "unload and leave empty" to drop the cargo at the intermediate station until the linkgraph decides where that cargo should go. In other words, cargo to "any destination" behaves like cargo in vanilla OTTD.

I have also noticed a few instances of CargoDist trying to route cargo to stations that don't accept that cargo. Will try to reproduce and post a savegame. (If it's the "sprinkles" patchpack, will post the problem on that thread.)

[NekoMaster]

Uhm, is it just me or does the game crash for everyone the moment you click on a road vehicle depot?

Crash log/dump/save etc. are attached, but this happens every time I click on any road vehicle depot...

The version was built from an up-to-date git checkout of origin/cd, the version string is: g90e5c92a
It occurs on 64 and 32 bit builds, win7 and winxp. It also happens when I don't load any NewGRFs.

Confirmed, happens to me too with CD r19561 (Lin32)

[ChillCore]

Uhm, is it just me or does the game crash for everyone the moment you click on a road vehicle depot?

Crash log/dump/save etc. are attached, but this happens every time I click on any road vehicle depot...

The version was built from an up-to-date git checkout of origin/cd, the version string is: g90e5c92a
It occurs on 64 and 32 bit builds, win7 and winxp. It also happens when I don't load any NewGRFs.

Confirmed, happens to me too with CD r19561 (Lin32)

I can reproduce this with yesterdays nightly. I thought it was me messing with grf combinations and I was not done testing before reporting ...
Todays nightly is fine.
My patchpak is bumped to r19568 and it does not happen neither.
Just bumping your source to trunk will fix the problem.

Nohing to fix fonso, bumping will do.

[NekoMaster]

How do I dump my source to trunk?

[ChillCore]

Good question ... I use patches.
Normally you update your master branch and merge it with the cargodist branch.

I assume you pulled from fonso's git repository.
If you do not have a master branch I guess you will have to wait untill fonso has bumped his repository,

You could also try to do the changes made after r19561 as found at http://vcs.openttd.org/svn/ manually.
I think it was fixed in r19565 but I am not 100% sure.

Edit: tested and r19563 fixes it.

[NekoMaster]

For some reason git doesnt work for me so I download sorce from svn and apply patches my self

[ChillCore]

Then you can simply do "svn update" with he patch already aplied.

[NekoMaster]

Then you can simply do "svn update" with he patch already aplied.

So, if I already applied the patch to r19561, then svn update to at least 19563, then configure and make it, will it still be a working cargodist build?

[ChillCore]

Yes ... ?

You can do that with all patches but sometimes it will generate conflicts you will then have to solve yourself.
In this case ... just do it, no conflicts to be expected.

In general it is for the applying bit you need to have the correct revision checked out.
Then you can update without problems as long as the changes in trunk and the patch do not affect the same part of the code. (Conflicts can arise even without trunk and the patch touching the same lines however.)

[NekoMaster]

Well I patched and built CD patch 19561 to Trunk 19563 and go no failed hunks or errors.

[Creat]

Since fonso hasn't updated the git repository with an updated, non-crashing trunk version, I've created a patch for those who are using a git clone of his repository and don't know how to do this themselves. It brings the trunk version that cargodist is based on from r19561 to r19571 (most recent at the time of creation), which includes the fix.
Here are the commands to apply the patch, it is just meant as a temporary solution until fonso updates his repository (among other things to save him a little work just for fixing this minor issue) and won't leave any trace if you decide to remove it (see below).

To apply the patch, use these commands (assuming you're in the repository and have the patch file copied there):

Code: Select all

git checkout origin/cd
git pull
git branch --no-track temp
git checkout temp
git apply "patch from trunk r19561 to r19571.diff"
git commit -a -m "depot crash fix applied"

The first two lines make sure you have the most recent version (skip this if you already have it), the next two create a new branch based on this version and make it active. The patch is then applied and commited to the repository. You can now go ahead and build the version just as always.

Once fonso updates the repository you can just do a "git checkout origin/cd" and "git pull" to go back to his branch. If you want to remove the (now useless) temp-branch, just type "git branch -D temp".

If you don't want to create a branch, use only the forth line (the apply-one ), you can later revert the changes just by using "git checkout origin/cd -f", but you can't checkout something else in between.

I hope this works for those who just want to play again with the most recent version...

EDIT: Attachment (patch) removed, as it is no longer necessary. The git repository has been updated and no more crashes occur on clicking road vehicle depots.

[Creat]

We've been playing a network game for a while now and we constantly have desyncs. It's getting worse as the game progresses.
How can I enable a more verbose output to provide more helpful information? It would have to be without using a debug build, since that is unplayable on this laptop...

Savegame is attached, I hope it helps somehow! But please note it uses quite a few NewGRFs...

Version information:
Current checkout of origin/cd: 90e5c92a3f6d23120f25477a341755df62f62a7d
With the patch I just posted above applied (it only patches the latest changes in trunk to fix road depots, as mentioned above)

EDIT: savegame accidentally removed, thought it was the patch from the post above... sorry...

[NekoMaster]

We've been playing a network game for a while now and we constantly have desyncs. It's getting worse as the game progresses.
How can I enable a more verbose output to provide more helpful information? It would have to be without using a debug build, since that is unplayable on this laptop...

Savegame is attached, I hope it helps somehow! But please note it uses quite a few NewGRFs...

Version information:
Current checkout of origin/cd: 90e5c92a3f6d23120f25477a341755df62f62a7d
With the patch I just posted above applied (it only patches the latest changes in trunk to fix road depots, as mentioned above)

Saves in multiplayer become a single player game untill you load it back into a multiplayer server.

[Creat]

Saves in multiplayer become a single player game untill you load it back into a multiplayer server.

Yes I'm aware of that. I would assume though that fonso might have the same possibility of doing that like I have (virtual machine, multiple PCs, ...).
Also I'd gladly provide more detailed information if someone could tell me how to. The desyncs happened arbitrarily, not as a result of player action, so I can't be of any more help until I know how to provide the detailed output, which fonso mentioned a few posts up that he had implemented just that. I just don't know how to get (to) it.