Cargo Distribution

[Auge]

Hello

I have a problem to clone your repository since you moved to github. I need to clone the repo via http.

After ...

Code: Select all

git clone http://github.com/fonsinchen/openttd-cargodist.git

... the empty repository will be created and then follows some gots and walks for many commits. But then ...

Code: Select all

got 4b83be7f4321a44f28632abfa346dfb4ccf783bb
error: Unable to get pack index http://github.com/fonsinchen/openttd-cargodist.git/objects/pack/pack-57e27bf9f919d798d3cdd8f047e07c4e3d59e9cf.idx
transfer closed with 2889652 bytes remaining to read
Getting index for pack e47b165fcef27717246c34c9144886dbfe2e2c22
Getting index for pack d17768e6b427c0c0c678c25aff602b4ae26a8261
Getting index for pack bf5e207e8285359498288826e5be336c4b5d10ca
Getting index for pack 1dbc6949c4022878c5afe13126f5420eeb4f3ac3
Getting index for pack 98fc79cbe75a2a7718bd883bd92d730b6f07d434
Getting pack 98fc79cbe75a2a7718bd883bd92d730b6f07d434
 which contains e4adfb9f95f64b34654eb29d19a694bd93389955
error: Unable to get pack file http://github.com/fonsinchen/openttd-cargodist.git/objects/pack/pack-98fc79cbe75a2a7718bd883bd92d730b6f07d434.pack
transfer closed with 1664165 bytes remaining to read
error: Unable to find e4adfb9f95f64b34654eb29d19a694bd93389955 under http://github.com/fonsinchen/openttd-cargodist.git
Cannot obtain needed commit e4adfb9f95f64b34654eb29d19a694bd93389955
while processing commit ad6dfe78651eb1a9bf030c00f8fed4bd3bd5f715.
fatal: Fetch failed.

Hade anyone before the same error or am I the only one?

Thank you and tschö, Auge

[fonso]

Auge: It works fine here. Is the directory where you're trying to put it empty? What version of git do you have?

[Auge]

Hello fonso

Is the directory where you're trying to put it empty?

yes

What version of git do you have?

git version 1.6.0.4

Tschö, Auge

[Creat]

I also just tried again to confirm, and it works fine here as well (git 1.7.0.2, on windows)

all I get as a log is this, and everything works fine afterwards:

Code: Select all

$ git clone http://github.com/fonsinchen/openttd-cargodist.git
Initialized empty Git repository in e:/test/openttd-cargodist/.git/
remote: Counting objects: 146400, done.
remote: Compressing objects: 100% (27247/27247), done.
remote: Total 146400 (delta 119859), reused 142039 (delta 118850)
Receiving objects: 100% (146400/146400), 84.24 MiB | 656 KiB/s, done.
Resolving deltas: 100% (119859/119859), done.

[Arie-]

I've made a post in the FIRS Release thread on a game of mine using cargodist. While all was well there's one remark I have to make. After the changing the supply scale algorithm from number of stations to amount of cargo at next hop (I hope I understood this correctly), this implied a gigantic playing style difference for industries.

Current situation: take a coal mine, buy some trains and order a full load to improve station rating and transport all to a steel mill. Now this is how one would normally play, and does not have much to do with cargodist. Actually, you would make it only harder on yourself if you'd add more destinations as you have to balance trains better in order to have no cargo waiting in the station at the producing industry.
The old situation rewarded a player when he or she would service more industries (although servicing industries was measured in directly with its flaws).

Because of this, I still think the old situation is more like I'd (we?) like cargodist to be. I can imagine that the new situation works like a charm for passengers, for industries, where more direct connections exist, I liked the old one better. But from what I've understood, measuring served industries was to tricky. Which is too bad . Great work however. I did not experience any problems while playing (using OpenTTD_CD_g0f7d66d2_win32).

[fonso]

Arie-: Yes, you're right. You have to play differently with external ratings than with supply scaling. WIth supply scaling you had to connect as many destinations as possible. With external ratings you have to be careful about goods piling up at your stations. Supply scaling didn't work well because at first it's impossible to connect many destinations and later, when you're already rich, you don't have to care about the added benefit. Also it made primary industries close down and allowed you to cheat. Nevertheless I think some form of supply scaling can be implemented on top of cargodist. However, it needs to be more robust and more sophisticated than my previous attempt.

I'm not so sure you need an additional incentive to build larger networks anyway. Most people tend to do that without any in-game incentive. Cargodist ist mostly there to make it possible to distribute cargo in a large network. From that point of view it's perfectly OK to make the networking part a little challenging. A good way to reflect that would be adding "size of largest link graph component measured as sum of monthly supply in the component" (possibly maximum of all cargoes and mean of all cargoes as separate entries) to the performance rating. That actually wouldn't be so hard. It wouldn't make it easier to build large networks, but still it would provide an incentive to do so.

Unfortunately the whole performance rating is rather ridiculous when applied to large maps with lots of vehicles. So that would need to be reworked first.

[andythenorth]

Also it made primary industries close down and allowed you to cheat. Nevertheless I think some form of supply scaling can be implemented on top of cargodist. However, it needs to be more robust and more sophisticated than my previous attempt.

I haven't tested FIRS with cargodist yet, although I've been watching with interest. Industry is pretty complex in both trunk and nfo, and testing means playing at least 100 years of a game

When I have some time, I'll try FIRS with cargodist. I'd like to assume that an industry set could be treated as a separate concern to the cargo distribution model, but I'm guessing that might not be so for various reasons. Good gameplay might mean tailoring the industry set to fit cargo dist....

So I'll playtest at some point, but I'm way behind the curve with cargodist and will need a little experience to make good judgements. Meanwhile I'm happy to consider tweaks or parameter settings for FIRS to work better with cargodist. Anything against the spirit of the set won't make the cut, but I'm open to all suggestions, pop them in the FIRS dev thread...

http://www.tt-forums.net/viewtopic.php?f=26&t=41607

cheers,

Andy

[Arie-]

...

Indeed, I understand that the beautiful thing about CargoDist is the flow of goods through the network. However with the previous supply scale algorithm I really fancied the incentive for hooking up all industries. Power stations in this game are rather useless as engineering supplies (the FIRS example) rely on coal as well, maybe there is another way of rewarding players that hook up all industries. Still great work though, I love the patch.

[blitzkrieg]

As quite a few have requested an up-to-date binary, here it is. It was build with the most current git-checkout at the time of writing.

Cargodist version-string is: g0f7d66d2
It is based on Trunk r20016 (in case anyone cares...)

Creat, Could you post another updated binary?

[Auge]

Hello

A late feedback: I compiled an actual Git build (v 1.7.2.1) and it works fine. It seems that my outdated version of Git (the one from the official Ubuntu-9.04-repository) caused the problem.

Tschö, Auge

[Creat]

Creat, Could you post another updated binary?

Sure, here it is...

Cargodist version-string is: g5d19369d
Which is based on Trunk r20479

You will need two of the three files: The ZIP containing the common files and one containing the actual excutable (i.e. the Game itself), either as 32 bit or as 64 bit version. Just extract both to the same folder (you can overwrite files if prompted).
I would've made a single .zip-file (or one for 32 and 64 bit each), but these hoops are necessary to stay below the 4 MB forum limit... Sorry...

In case it is needed I can provide the corresponding .PDB files, just ask and I'll upload them! I didn't attach them directly as I assume they are rarely ever used, but as I said if they are needed (or if I'm just wrong about them not being used ) just request them here...

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. These files are vital to finding what happened during the crash.

[blitzkrieg]

Creat, Could you post another updated binary?

Sure, here it is...

Cargodist version-string is: g5d19369d
Which is based on Trunk r20479

.

Thanks a lot !!

[ostlandr]

Thanks a bunch, Creat!

I was playing vanilla (latest nightly) OTTD last night, and was getting frustrated at having to deal with getting cargo to where it needed to be.

[Lord Aro]

hi all,

i realise this is a 'forbidden' question here, but:
how long before this gets into trunk? (roughly)

flame away!

don't hurt me

[supermop]

I'm sure I am doing something stupid here, but I have never had a problem with these binaries before...

Downloaded and extracted the the binary posted above (32) when i tried extracting the 64 bit version as instructed i got this error:

unspecified error.png (43.02 KiB) Viewed 3665 times

The resulting folder contains all of the files it should except the .exe. Thats no big deal though because I could just use the 32bit version right...

belarussian.png

(1.41 MiB) Downloaded 1 time

except everything is in belarussian, and the game sees that as the only available language. When I run regular 1.0.3, everything is in english, and all the languages appear to available. Everytime i run the cargodist version, the line in openttd.cfg is reset to belarussian.lang, and manually changing it has no effect. As far as I can tell the lang folder looks normal.

Anyway, I am sure this is something I am doing wrong, but I cannot tell what, as I have treated this binary the same as all previous cargodist binaries I have used.

If anyone can give me a clue, I'd be grateful!

Best,

[Creat]

What Version of Windows are you on? Vista? 7? and you are using a 64 bit Windows, right?

Have you tried to extract the 32 bit zip only (but completely) and does that work? You don't need to use the 64 bit version even if you're on such a system, I just provided it as a bonus.
The fact that there are only some of the languages suggests that the file wasn't properly extracted. I've tried on 2 machines, and all languages were there.

About the error: I have no idea, as that seems to be related to the extracting and not the game itself. Did I understand that right, it only happens when you extract the 64 bit executable, the 32 bit extract fine? That would be even more confusing as the 32 bit zip contains the languages you seem to be missing... Also, does it work when you click 'Try again' or does the error come up again?

I can try to upload a different zip (i.e. create a new one) and see if that makes any difference?

@Fonso: I have noticed that the 32 bit binary takes a very long time to start up while the 64 bit version appears instantly, any clue as to why? I also don't know if this is a local problem for me or if it's slow to start for everyone...

[Eddi]

Starting OpenTTD may be slow, because it has to read all grf [and other] files on startup to calculate md5sums, which causes a lot of (very slow) disk reads. The second start is usually faster due to caching effects. That likely has nothing to do with this patch.

[Creat]

No, that isn't it as the 32 bit build is ALWAYS slow to start up and the 64 bit ALWAYS appears pretty much instantly. And by slow to start up I mean about 20-30 seconds of 100% CPU, independent of just opengfx/sfx or all my NewGRFs are in the data folder (also temporarily renamed my config file to exclude it).

I do agree though that it most likely is not a Cargodist but a generic (Trunk) issue, I still wanted to ask here first as it is a CD build.

I just checked on a different PC (32bit XP) where it starts up just fine (instantly, if it's a second start and files are cached). This is somewhat irritating, so could someone else with a 64 bit Windows 7 please check if it also happens there, so it's not just some glitch on my end?

[Arie-]

Ok, my specs and a test tell:
Version: OpenTTD_CD_g0f7d66d2_win32
OS: XP SP3
Proc: XP 1800+
RAM: 512+256+256 (Don't ask )
Startup time: +/- than 5 secs (Will try after a reboot later, but due to hardware issues (temps I think) my computer has to be off for 5 mins before I can boot again)
Grfs: 8 (2cc + av8 + fish + firs + nutracks + stolentrees + ttrs + egrvts) + OpenGFX + OpenSFX + OpenMSX.

That leaves me to believe it's an OS/hardware issue rather than an OpenTTD issue.

[NekoMaster]

I've never had a problem with 32bit cargo dist builds. They take about as long to long as any other 32 bit build of openttd for me