fabca2 wrote:Why do you require a password ? (that must be requested on irc)
why make it too hard ? isn't the goal to allow people to tests cargodist ?
I don't have irc. I played the first test with playsure, but I don't plan to install irc for that.
What the purpose of this password ?
Only people that follow this forum thread and who want to download the specific bin will be able to play, is there any risk of sabotage ?
and if someone really really want to destroy your game, do you think it's too hard for him to ask for the password on irc ????
Like anyother protection system (DRM, DVD...) this is just anoying normal people and does not protect anything.
#openttdcoop has passwords for several reasons. The first is, as you pointed out, to prevent vandalism on our servers. The second (and most important) reason is to get people onto IRC and have them read the wiki (in the past you could only get the password through visiting a certain site FROM the wiki). We've had loads of occasions in the past where anti-social people and vandalists did not join IRC but did join our server.
Note that the method of getting the password has been changed loads of times in the past and that it might not be entirely clear at first but we mainly do it to get people to communicate and follow our rules
The server has been updated to run a new version: http://bundles.openttdcoop.org/cargodist/g17340e3e/
The same game has been loaded with that version. So if you have built something on the weekend you can continue it. The new version fixes some desyncing bugs. I hope I have caught them all but I'm not entirely sure.
Passengers go from A to D changing the company in B and C: A - B - C - D. Between every changing another company is servicing. Who earns the money if each distances is equal and in one direction? only the last provider? evry provider the same?
Hmm, switching passengers between companies sounds like infrastructure sharing. I think you should ask that question in another thread, not sure though.
Hello fonso,
sorry to say but I found another 2 little bugs in the smallmap gui.
- When zooming in the vehicles disappear from the smallmap.
Changing line 775 and 776 in smallmap_gui.cpp to "(int)TILE_SIZE" fixes that.(*)
- Aircraft that are flying have their position in the smallmap drawn at tile (0, 0). When landing at the airport their position on the smallmap is drawn correctly.
See attachment. I have no solution for this one yet ... sorry.
(*)
The line numbering is trunk-cd_r19826 bumped to r19880 to see if it was something in trunk that was already fixed or not.
No conflicts while bumping.
Attachments
Buham Transport, 24 Aug 1950.png (44.8 KiB) Viewed 4938 times
Playing with my patchpack? Ask questions on usage and report bugs in the correct thread first, please.
All included patches have been modified and are no longer 100% original.
Thanks for the report, ChillCore. I have fixed the smallmap glitches and also the order determinism detection. Determinism detection was broken for nominally conditional, but really unconditional orders. However, as those are only minor problems, I suggest we play another test game with http://bundles.openttdcoop.org/cargodist/g17340e3e/ in order to find the remaining desync. The last game was quite stable. We had only one desync in about 5 days so I guess a new game with the same version could be quite funny if done right. One desync is still one too many, though and I'm going to find it.
I'm open to suggestions regarding map and settings. Please post them at #openttdcoop.dev on oftc or write me private forum messages.
removed supply scaling. It doesn't work as intended and I don't see a way to fix it.
added "external ratings". Instead of simply on the sum of all cargo waiting ratings at a station S are now dependent on
a, the average amount of cargo per next hop at S and
b, the maximum cargo from S waiting at any station where cargo is being dropped (including S itself, if applicable).
So, for big transfer stations you have much more freedom to store cargo without rating punishment as the average per next hop is considered first. However, if cargo is dropped, all cargo is counted per source and the rating punishments are fed back to the source stations so that it won't pile up that much anymore at the transfer station.
Introduced branch "cdo" which keeps supply scaling but doesn't include external ratings - for those who like it that way.
Branch "cd" was completely replaced, so you'll have to "git pull -f" to update it in your local repository.
As there haven't been a lot of suggestions, I have opened the following game:
Temperate, full Japan set.
supply scaling off
512x512 random
You can play with the same binary as before (http://bundles.openttdcoop.org/cargodist/g17340e3e/). Please play with "debug_level desync=3" and send me the dmp_cmd saves if you experience a desync. You can use the forum messages for that or post them somewhere I can access them. Due to lots of work this week I won't be able to show up often in this game but I hope to be able to occasionally join IRC and clean up a bit. Have fun.
And of course the server is still the same: mz.openttdcoop.org:3999
I played the last 2 months with a version from 2010-03-27, and now upgraded to the newest Version, and now the game says it can't load the game, it says "invalid chunk size". I am now looking for two things
1) the Version from 2010-03-27
or
2) another solution (something like "force loading").
@Purator:
I do not know why the patches for cargodist on that page are 0 bytes.
If you can not find anywhere to download the correct version, I have a few backups here and , most likely, also have the version you need.
Loading your savegame with the last version will not work for two reasons.
1. Trunk has bumped.
2. There have been some changes in the last version that break savegame compatibility even without trunk bumping.
Playing with my patchpack? Ask questions on usage and report bugs in the correct thread first, please.
All included patches have been modified and are no longer 100% original.
@ChillCore: I will search and ask you if needed. Is there any possibility of such a "Savegame-conversion" (like saving with several versions or something like that?)
A save-game conversion will not work in this case. (it is possible for vanilia OpenTTD to move from lower versions to higher, but not for patched OpenTTD versions where some part of the save/load logic has been altered)
My OpenTTD contributions (AIs, Game Scripts, patches, OpenTTD Auto Updater, and some sprites) Junctioneer (a traffic intersection simulator)
I know that savegame conversion is possible but it involves writing a lot of ugly code that would further clutter the already ugly save/load files and it will be thrown out if cargodist is merged with trunk. This is why I haven't done so, yet.
You can do all kinds of funny things with that website, but unfortunately you cannot automatically create patches from the repository (at I don't see how). I'll find a way to do that for those of you who are using the patches. And I'll update the first post and wiki page in the next few days.
I am playing this patch since recnetly and am struggling with huge amount of passengers travelling through big network. Almost all lines have to use as much trains as possible and still most of stations are overcrowded.
Is there a way to reduce passengers amount generation (for example in half) to allow some more and some less - crowded lines?
There seems to be very interesting patch parameter in the "towns" section in advanced settings, which is called "town cargo generation factor (less < 0 < more), but I am not able to find any description of it anywhere.
In addition, I did not understood the last three parameters from "link graph" section - about effect of distance on demand, station popularity and saturation. Are there any formulas that drive them?
