Currently Online

Latest Posts

Topic: Solution proposals for maritime shipping problems

Tibor
Joined: 2009-03-23, 23:24
Posts: 1316
Ranking
One Elder of Players
Location: Slovakia
Posted at: 2020-01-29, 21:38

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)


Top Quote
Solstice_s_Return
Avatar
Joined: 2020-01-28, 13:24
Posts: 50
Ranking
Likes to be here
Location: Finland
Posted at: 2020-01-29, 22:16

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
Avatar
Joined: 2014-09-15, 18:35
Posts: 1500
Ranking
One Elder of Players
Posted at: 2020-01-30, 00:11

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.


Top Quote
Solstice_s_Return
Avatar
Joined: 2020-01-28, 13:24
Posts: 50
Ranking
Likes to be here
Location: Finland
Posted at: 2020-01-30, 08:34

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
Joined: 2009-03-23, 23:24
Posts: 1316
Ranking
One Elder of Players
Location: Slovakia
Posted at: 2020-01-30, 08:47

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....


Top Quote
JanO
Avatar
Joined: 2015-08-02, 11:56
Posts: 84
Ranking
Likes to be here
Posted at: 2020-01-30, 10:34

@ 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.

Edited: 2020-01-30, 10:34

Top Quote
Tibor
Joined: 2009-03-23, 23:24
Posts: 1316
Ranking
One Elder of Players
Location: Slovakia
Posted at: 2020-01-30, 10:51

@JanO

I dont think this is mater of "rejection", but other way round. It is matter of who would decide to commit to such huge effort - I estimate it 100 hours at least, but can be more than 500 hours...


Top Quote
Nordfriese
Avatar
Joined: 2017-01-17, 18:07
Posts: 614
Ranking
One Elder of Players
Location: 0x55555d3a34c0
Posted at: 2020-01-30, 20:12

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
Solstice_s_Return
Avatar
Joined: 2020-01-28, 13:24
Posts: 50
Ranking
Likes to be here
Location: Finland
Posted at: 2020-01-30, 20:58

Nordfriese wrote:

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.

I would define them simply by whether there's traditional road connection between them or not. Areas connected with road must belong to the same economy. Inside an economic area there could be an extra button in harbor and warehouse that allows player to define a particular storage location as a major economic centre with just one click. Then from now on it will be favored over other storage locations (but not so much that roads get overloaded with goods) . By clicking that button in two or more storage buildings would make them equally important locations.


Top Quote
Solstice_s_Return
Avatar
Joined: 2020-01-28, 13:24
Posts: 50
Ranking
Likes to be here
Location: Finland
Posted at: 2020-01-30, 21:15

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