Turn fishing and whaling units into generic code

[Nightinggale]

Right now we have code for two units. We could reduce this to generic code with some data from xml. It should work like this:

1. move to nearest free plot with a certain bonus (or one of a list of bonuses)
2. harvest yield mentioned in xml
3. move to nearest colony
4. unload and repeat

This will allow the two units to share code, but it would also allow some outdoor prospecting profession where a unit travels between a colony and say a gold bonus, which happens to be in mountains out of reach of all colonies. I have seen both gold and silver being placed in locations where it's not a matter of planning how to reach them with colonies, it's a matter of impossible due to terrain.

It could make sense to mix it with profession cargo slots #141, perhaps with the part about the unit eating food as this will prevent it from being a way to get colonists to produce yields without eating food.

[ShadesOT]

Only if the gathering can be automated in the sense that a plot and a destination town can be assigned to the unit, which after that automatically moves to that plot, harvests and moves back to the town to unload its harvest. This is different from how unit automation of fishing and whaling boats works now.

[ShadesOT]

Units which get assigned to the same plot form a queue on that plot, so the next one only starts harvesting when the previous one is full. This actually can be interesting if it would be possibel for units from different nations to be assigned to the same plot. Eg, 2 english units queue up there and wait to harvest their share and then a spanish unit arrives and also starts harvesting (because it doesn't care about the english queue) and the harvest hence forward is split on two harvesters. Harvesting the same plot could be cause for tensions with other colonial powers.

[Nightinggale]

Imagine controlling it like this:

• Change profession to outdoor prospector
• Move normally (no automation)
• Once on the gold, there is a button for automated digging

When digging automatically, it fills itself, move to the colony it started from, unload and then move back to the plot to repeat the cycle.

This approach seems fairly doable to implement from a coding point of view. The unit just needs to store pointers to a city and a plot. It needs some sort of state machine, but it can figure out which state it is in by the yield counter. It's also fairly simple to use from a GUI point of view.

The queue is a good idea, but it could be tricky to implement. If there are two English units and one gets full, the plot becomes free and the other will take over. Later when that one is full, it's again filled during the English turn and an English unit is first to take the free "harvesting slot". If there is a queue, it needs to be coded more advanced than just "next in line when the plot is free".

There are other issues to consider, like is plot ownership mandatory? What if it's owned by natives? Can you pay natives to be allowed to dig gold inside native lands? Would it be a diplomacy contract, which requires renewal every X turns, each time with a payment?

I think it would be wise to make a first implementation, which only allows harvesting your own plots. Once this is confirmed to work, we can move on to the next step of multi player queues, native lands and all that.

Another option is to restrict a plot to just one unit. That will keep it simple, but perhaps it's not that great.

We can also consider if two units harvest at the same time, do they get 50% each? (rounded down!)

[ShadesOT]

I suggested the queue for units from the same faction because of the times it takes to get there and back. Think of the whaling boats. Resources are sometimes far away. It can take a ship to get there and back the same amount of turns it will be there harvesting easily. So the best way would be to assign two or more units to the same resource plot. This though can not be automated. Because curently, if automated unit 1 is harvesting plot A, which is 6 turns of travel time away, automated unit 2 would select another resource plot B if plot A currently is not free (also, if plot B is like 20 turns travel time away). Also if A would be free by the time it gets there. A queue is also justified because, if all units from the same faction would harvest at the same time and the harvest would be split amongst them, they most likely will stay there the same number of turns and then all go home and come back together. which is inefficient.

And in case there is a queue for each faction, if there are more than one units harvesting, which can be the case if units from several factions arrive there, the harvest will be split among the units harvesting, which means 50%, 33%,20%, etc ... with adequate diplomatic impact.

[orlanth]

As a simpler solution for harvesting depletable resources I had used the vanilla mechanism for harvesting Features. (e.g. Mining Vessels locate a Comet or Asteroid Field feature and harvest them; after harvest new features can be generated on eligible tiles for the player to seek out). This didn’t require special queues etc and I kind of liked the challenge/variety of searching out new sources of supply, so this could be another mechanism to consider as an option for some resources (i.e. considering whales not as an inexhaustible resource always present in the same place, but rather as a scarce and migratory resource for players to seek out and hunt down). 🐋

The only problem was that vanilla Sea Worker UNITAI would not try to harves/clear Features, only the land worker unitai would. Vanilla also autodelivers harvested Yields to the nearest city, this could potentially be modified to store them in the harvesting unit if desired.

[Nightinggale]

I don't like the idea of depletable resources. They tend to be more annoying than fun.

I think people are overthinking a queue. Just add a unit queue to the plot. When a unit wants to harvest it, put it in the back of the queue. During CvPlot::doTurn, the first gets to harvest. If it's full it's kicked out and any leftovers goes to the next one. The queue is a simple FIFO queue. Nothing special. Sure you can spam resources, but #146 should prevent that from being a good strategy.

[raystuttgart]

This is already implemented. It is not hardcoded anymore.

We now have: bGatherBoat