Topic: Solution proposals for maritime shipping problems

Tibor wrote:

Solstice_s_Return wrote:

Ships should be like moving warehouses when they're at sea and so their content can be reordered on the fly if destination zone can produce the required goods during the meantime.

I dont think this is a task of ships to match/swap/reorder wares. This might be task of productionsites that could in some period lookup for alternative/closer wares and require these and cancel request on ware that is on the way to the productionsite.

Maybe somebody need to look at definition of "distance" (ware to a requestor)

Maybe you're right, especially if it can't be done so that it doesn't waste shipping capacity and thus cripple the economy again. But if surplus goods are at least temporarily dispatched to the destination port, that shouldn't be a problem.

Top

Quote

king_of_nowhere wrote:

Solstice_s_Return wrote:

Problem no1: Ships are incapable of assessing what should be taken onboard and as a result for this, may ship goods through really ineffective (read:annoying) routes - particularly when there's multiple destination harbors. Simplest solution: Add routes-button to ship's cargo view. By clicking this, player can left-click two harbors and set the ship to only be available between these two ports. When routing is active, it can be cancelled by clicking the same button again.

i already suggested that years ago, but it didn't got traction.

Then maybe we need a poll about whether or not such a button is needed, along with discussion about reasons for the opinions.

Top

Quote

@ Tibor
I see the point that codework is the main bottleneck and I'm also aware einsteins economy-tournament, where we found out that big economies cause exploding CPU-load. Lets assume that CPU-load can be calculated by something like n^x with x being a constant depending on the code (namely including game design) and n depending on number of buildings (including flags). I guess all programmers know stuff like this (I myself had only some short weeks of programming courses years ago so I highly believe any actual C++ I could write would cause more trouble than benefit).
Anyway.

My idea of splitting economies aims at dividing n^x into n1^x+n2^x+... which should be smaller than n^x, even if there are some additional processes because the different economies have to communicate. If for my level1 + level2 approach the existing code is just copied and the part that sets the destination of a ware is changed is changed, your example of a destroyed warehouse should cause the same amount of trouble as a destroyed building site or a disconnected road (=the current workaround for the initial problem of this thread).

I try to specify how I imaginated the necessary code-changes:

• 1) Productionsites and wares need an additional tag for the new local-level distribution purposes
• 2) The code that makes a building (productionsite or buildingsite) call for wares needs to be duplicated
  • 2a) First call is local-level and needs to be changed in a way that it calls only the next warehouse (here I try to save CPU-power)
  • 2b) Only executed if after 2a there is still uncovered demand.
    This copy deals the global requests and has to be changed in a way, that wares that are found by this call, are not directed to the requesting building but to the next warehouse.
    Additionally it must set the ware's tag that marks it as "under global reallocation". This tag is unset in the moment when the destination-subeconomy is reached (or disintegrated).
  • 2c) Possible topup here: If a global request finds more of a specific ware than needed, a recalculation for all wares with the "under global reallocation" may speed up the transportation on an acceptable cost of CPU-load
• 3) [optional] Save information on the distance and direction to the closest (or all) warehouses on each flag, so a ware travelling through an economy does not need to do individual calculations how to reach its destination but instead just ask the flags. I guess this one has a high potential to reduce CPU-load (try to reduce x in n^x) but probably also very high load on codework.

Speeding up ship transportation should be a side effect of this approach.

It is just an idea and (for me) it is not a big deal if it is rejected for whatever reason except for one: If one rejects it because he/she does not understand me (technicallly). So I will not start big discussions here, I only answer questions if asked or give explanations if I think something is not clear. There still might be cornercases.

Top

Quote

How would you define sub-economies? If you have separate islands the case is clear, but consider the case that you have a long 512x64 map unconnected at the ends. The ends should be in different subeconomies of course, but there is no place on the map where a subeconomies-border would make sense.

Top

Quote

Tibor wrote:

Solstice_s_Return wrote:

Then maybe we need a poll about whether or not such a button is needed, along with discussion about reasons for the opinions.

I would modify it as an possibility to set a list of allowed ports (for a ship), you can set just two of course.

Of course corner cases might be:

• what if there will be ports that have no ships allowed to sail to them
• what if one of ports on the list disappears

So just be aware that this can lead to confusing situation, when some ports will be unattended and user will wonder why no ship ever sail them....

To make it less confusing there should be graphical symbol in ships sail or flag or something which shows that the ship is using routes instead of an algorithm. There's still at least one other thing with such a list: In that case ports should also have names. Maybe player should have an ability to define them to make the list more easy to use. I guess that if a port disappears it will be almost the same as now. If a player erroneously define entire fleet to stay away from one of his ports, it would be his own problem. In this case I think more control to the player can't be wrong and players should not be protected from themselves that much.

Top

Quote