It is possible to place ports via expeditions where players can not build them via normal expansion

Bug #1216305 reported by SirVer
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
widelands
Fix Released
High
Unassigned

Bug Description

Case in point is this safe game. The blue player send an expedition which can place a port very near to the red players port in the bottom left corner of the map (this port is currently building, there is an assertion error when it finishes, just speed up the game and wait).

Also, the red player could send out an expedition to place a port at the very same spot, though it can not build one there 'normally' though he owns the field.

Tags: seafaring
Revision history for this message
SirVer (sirver) wrote :
Revision history for this message
Nasenbaer (nasenbaer) wrote :

Well... this bug is a bit more complicated

First the later part:
> Also, the red player could send out an expedition to place a port at the very same spot,
> though it can not build one there 'normally' though he owns the field.

I checked it over here - maybe I misunderstood you, but actually if I
* load the saved game
* destroy the constructionsite
* switch to the red player
* reconquer the area
-> the red player can construct a port at the very same position.

Anyway the real problem at this point is the handling of enemy territory and military influence. And it seems I did not check this part of the expedition logic close enough.

In the long term (to conquer a foreign islands completely owned by an enemy) there is no other way than implementing an "automatic soldier cleanup troop" which cleans up the enemy territory around the port build space to make space for the constructionsite as well as to defend the constructionsite and the final port.

But we are not yet at that point.

So maybe it would be a wise decission to add a check to the expedition logic that disallows the construction of ports on enemy territory for now.

Any different opinions?

Revision history for this message
Nasenbaer (nasenbaer) wrote :

For clearing enemy territory see bug #1191296

Revision history for this message
SirVer (sirver) wrote :

I agree that for now you should not be able to place a port where another player has already conquered terrain. I think the ship should not even stop there. But, I think the ship should also not stop if yourself have already conquered that terrain and are not allowed to build a port there (as defined by the buildhelp). Currently you can place ports where the buildhelp forbids it by just sending out an expedition to this place and ordering a port there.

Revision history for this message
Nasenbaer (nasenbaer) wrote :

I disabled the ability to construct ports on enemy territory in rev. 6739. Further I fixed a bug where a player was able to construct a port from the expedition ship, where the player would not have been able to build it because of a too close player infrastructure (e.g. flag on a position that disallows the placement of the ports base_flag).

Anyway, I disagree concerning the disallow of port placement in general if terrain is already conquered by you and the player is only blocked from constructing a port because of some natural immovables that are blocking the space. The main reasons why the ship should still be able to construct a port at said places:

* The need to allow the placement of ports on places in terrain, where normal buildhelp would not allow to place a port, is a fundamental feature legitimated through at least two facts:
1. The tree spreading feature (I know you (SirVer) do not like it , however we decided in the community to keep it and still have it ;) ) might lead to blocked port buildspaces on islands that won't be settle-able without said port space.
2. Once the "clear enemy territory" feature is implemented in some way, there *must* be a way to find blocked port spaces - and not just those that are used for enemy ports, but as well those that are blocked by a tree (else the player could build up a "security wall of trees" with some foresters) or any other enemy building

* If a possible port space is blocked - no matter if inside or outside already owned territory - the behaviour of the expedition ship should be the same for owned as well as unowned territory - e.g. think about a map with long rivers and port spaces just directly face to face on each side of the river. Once a player conquers the territory near the port on one side of the river, builds a port and a shipyard and finally starts an expedition - the other side of the river is likely already (and even if only partly) conquered by the player (maybe even the conquer range of the port is enough) - so in case the port space is blocked by whatever immovable, it is now unusable for the player - although it would have been usable if the player had send out an expedition before reaching the part of the land.

I agree though, that the behaviour itself is a bit counter intuitive, therefore my idea would be to add a new message shown ocne a player clicks on the "construct port" button of the expedition ship and the area is blocked by some immovables - maybe something like "for the port construction to happen, we first need to clear the port space area. If you agree to do so, all resources that could be harvested out of those trees and other objects will be lost."

Or to go even further: We could add a forester and a stonemason to the expedition to explain the behaviour.

My point simply is: There should not be a special treatment of "already owned but blocked by immovables area"

Changed in widelands:
status: Confirmed → Incomplete
Revision history for this message
SirVer (sirver) wrote :

This is yet another clear indication that the tree spreading feature is just trouble and adds nothing to the game - just saying.

Given the constraints I agree with your reasoning - I disagree with the extra message though. Settlers had a planer - when you wanter to build a big building, a planer had to level the fields of the buildings to the same height before a builder could start construction. I always wanted this to be in Widelands too, but somehow we never implemented it.

Adding a lumberjack and a stonemason to the ship and forcing them to clear the area where the port should be build would be a logical extension of this logic. But if the land is really fertile the trees could spread faster than a single lumberjack could harvest them .... well, I have a solution for this problem too if you are interested :)

Revision history for this message
Nasenbaer (nasenbaer) wrote :

Well, let's not start a flame war again ;)

I guess the point, that a player could place some foresters near the coast to create his "tree security" - if there was no way to clear the land - is valid enough as a standalone argument. So with or without the tree spreading feature, we need some way to place the port of an expedition ship at blocked places.

And a place can either be blocked by
 * an enemy infrastructure - this kind of "clearing" is handled in bug #1191296
 * or natural immovables (natural means not PlayerImmovable, but still plantable by a player - so might be valid for areas hold by an enemy troop as well) - this is what we are currently speaking of.

I guess the two real bugs described above are fixed now, so I close this bug report as "fix committed" and open a new bug report to discuss the best way to handle the clearing of natural immovables ( Bug #1219497 ) - and as we can see from our short discussion here, the real solution to this problem is not that easy as it might seem. So we better keep the status quo for build18 and improve the behaviour in build19.

If you disagree, you may of course reopen this bug.

Changed in widelands:
status: Incomplete → Fix Committed
Nasenbaer (nasenbaer)
Changed in widelands:
assignee: Nasenbaer (nasenbaer) → nobody
Revision history for this message
SirVer (sirver) wrote :

Released in build-18 rc1.

Changed in widelands:
status: Fix Committed → Fix Released
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.