Port space discovery problem

[Teppo Mäenpää]

Port spaces are displayed in build help -- if a port can be built there. Otherwise, they are not shown.

An unlucky player might build something else to his port space or its proximity, and then never discover the port space at all. This could be fixed by hinting the existence of a currently unusable port space in the build help.

In the attached screen shots, left plots illustrate the problem. Upper right plot shows a more typical "lucky" discovery. Lower right plot shows a possible fix.

If it is an intentional choice that port spaces may remain undiscovered, then this of course is not a bug at all.

[_aD (ad-simplypeachy)]

I've had this problem too; it is definitely worth addressing. You've come up with an idea that fits in with the existing visuals and game mechanics really well!

[Teppo Mäenpää (kxq)]

I thought that this is a corner case. If you find this important, retarget to build 18.

[_aD (ad-simplypeachy)]

I've only had it once or twice so not sure if it's worth blocking b18 for.

[SirVer (sirver)]

That is a good solution. But what if trees are on the spot? I think even then, some kind of indicator should be there. I thought maybe that we could place a kind of placeholder immovable on a port spot, something that clearly indicates: a port can be build here, even if other immovables are there too. I thought about a plank reaching out to the ocean or so, but I am really not so sure about this idea.

However, this is really, really annoying and we really have to find a solution for b19. Does anyone remember how settlers 2 handled this issues?

[Teppo Mäenpää (kxq)]

> That is a good solution.

Thanks for the encouraging words. We might eventually want to make the "port nearby" buildhints be somewhat different also in grayscale, just in case.

> But what if trees are on the spot?

I would not worry about that: Most players eventually cut trees and stones in their area. If a players sees a forest on shore and does not cut it, then I think that he was not interested in ports.

>Does anyone remember how settlers 2 handled this issues?

Never owned or even seen that game.. I wonder if it would be on sale on some GoG-like store?

[_aD (ad-simplypeachy)]

If my memory serves, Settlers II didn't do anything - so you just had to destroy buildings until you found the space!
btw: http://www.gog.com/game/the_settlers_2_gold_edition

[Astuur (wolfsteinmetz)]

There was a large Building space icon combined with an anchor in Settlers' II build help to signal that a port could be built there.
If that icon did not show up for any reason, I think there was no further hint.
http://jajozglowy.pl/gry/solucje/s2/flota1.jpg

Personally, I'd prefer to hide the port spots if covered under trees, stones or buildiings.
It's a nice extra challenge to disvover them.
After all you can always find the spots by letting a ship search the coast.

[Teppo Mäenpää (kxq)]

>Personally, I'd prefer to hide the port spots if covered under trees, stones or buildiings.

My intention was to hide them too, if covered. The point was to hint the existence of port space, if the player could accidentally build something that blocks the harbor.

 With forests expanding over time, do unused port spaces with trees nearby have a "best before" date? In other words, can an expedition benefit a port space if trees have concurered it? Should an expedition also carry a stonecutter and lumberjack, to overcome cases like this? (surely not in b18, but long term.)

[SirVer (sirver)]

#9: this is being discussed in bug 1230255 - trees are a very real problem for ports right now.

[SirVer (sirver)]

Setting to incomplete for bug sweeping.

[GunChleoc (gunchleoc)]

I have implemented #1 in the attached bug. I think the graphics didn't turn out perfect though, would anybody like to take this up for me?

The graphics are in data/images/wui/overlays

[GunChleoc (gunchleoc)]

Map for testing

[kaputtnik (franku)]

My first idea is to just add blue stripes to the small_port and medium_port graphics. I look into that.

[kaputtnik (franku)]

Hm... i think it works not correct. Most places which restrict the port space are not covered with the blue icons. A test with map "Crossing the Horizon" shows no blue houses in the build help. See screenshot. Also your testmap
 didn't show blue buildings in the buildhelp on all places which restrict the portspace.

[kaputtnik (franku)]

Stripes where a bad idea :-D

I have added an anchor to the buildings. On the left image the anchor is perspective, on the right it is just added as a plain sign on the top right corner.

If you like the idea, i will try to give the images some finetuning.

[GunChleoc (gunchleoc)]

The anchors don't click for me like that. Maybe have them leaning against the building, or make them black?

[GunChleoc (gunchleoc)]

I can reproduce #15 - savegame attached.

[GunChleoc (gunchleoc)]

It occurred to me that the bug we're seeing in the atached savegame and screenshots is not in the new code that I wrote, but in the calculation of the buildcap for the port space. The buildcap checks whether a portdock can be built nearby. This check makes sense, because a map editor might set some port spaces and then edit the shape of the water afterwards, or because another player has already conquered all the nearby portdock spaces. So, we should think very carefully before we change that code, because it has potential for new bugs.

[kaputtnik (franku)]

Isn't be possible to just mark all building icons in the build help which are in a particular radius? F.e. define a radius of 3 around the portspace and mark all buildings which are inside this radius blue? Such calculation/marking should cover all circumstances. Of course the blue (or whatever sign we create) should only be shown if the portspace isn't shown or already build.

Regarding the sign: The buildhelp shows only schematic buildings, so the new sign should be like that. Leaning an anchor against the building would be too natural (not schematic) i think. I try some more...

[kaputtnik (franku)]

A try with horizontal stripes

[GunChleoc (gunchleoc)]

I think the stripes are too noisy. Maybe just matching the color with the port space as suggested by the original mockup would be best after all?

If you look closely at the saveegame, if you build another military building that will conquer a bit of Sea close to the port space, the port space will pop into view. So the issue here is not that the port space is concealed by anything on land, like roads, other buildings or trees.

This is the experiment that I did: add some more water to the map, add some port spaces, remove the water. The port space will disappear. Without the buildcap check, as soon as you build something that partially covers the port space, suddenly the medium size and small size buildhelp icons will turn blue around the impossible port space that would never be shown as a port space and where you will never be able to build a port. This is unexpected behaviour and will completely confuse payers.

So, the new icons do the exact same check as the port space does. Changing that behavior has potential for new bugs. It would be nice to still get this feature into Build 19 (while we're still stuck with the desync), but fiddling with the buildcaps isn't really something that we should do at this point.

[kaputtnik (franku)]

Hm, i think we misunderstoud. But first: I think just having bluish signs is good.

Yes, Portspaces needs also a bit conquered water. But shouldn't this be also indicated by the bluish signs?

The other thing (i couldn't follow you): I don't meant to use the buildcap logic. Instead implementing a new logic (like the "radius") for the buildhelp (only to show the bluish buildings in the buildhelp). The buildcap logic does not fit here IMHO, because it does not reflect the needs. What we need is:
- Mark where a port could be build nearby(!).

The buildcap instead is used for:
- Sign the portspace

The buildcap doesn't reflect the possibility of neighbouring buildings. It reflects only the possibility of the portspace itself.

But maybe i am wrong :-)

[GunChleoc (gunchleoc)]

I have had a look at the code again, the important line here is map.find_portdock - we will need a second variant of that function especially for the buildhelp. I still don't want to touch that for Buid19 though.

And then we will also need a blue icon for the big building, because in your first screenshot, the port space needs to be highlighted, but it isn't available for building a port yet.

[kaputtnik (franku)]

The linked branch get added with a blueish icon big_port.png. The images small_port.png and medium_port.png are changed a bit.

Hopefully you regard the changed icons with favour.

Since nobody want's to work on this for build 19 i remove the milestone.

[kaputtnik (franku)]

When i try to merge trunk into the linked branch there are some conflicts which i couldn't resolve. Better make a new branch then or fix the conflicts?

[GunChleoc (gunchleoc)]

I can merge it for you tomorrow. I'll probably have an easier time of it since I wrote the code.

[GunChleoc (gunchleoc)]

Screenshot with anchor immovable.

[toptopple (7010622-q-deactivatedaccount)]

Very nice for a start, Gun! :) Even anchors reemerge when port build help becomes available again.
There are some problems left, however. Can you make a branch with the following?

a) Anchors are only shown on "real" Port Spots, never on any derived locations like blue houses
b) a blue house (of any size) is only shown as a placeholder for the Port Spot, not in any distance > 0
c) it is not possible for planters (farmers, foresters) to create items on the Port Spot

I think this would be a convincing workout of the "Anchor" alternative, and we could see whether it proves valid in gameplay. The "blue radius" solution is difficult to implement, the current version must count as failed. For instance the radius houses shouldn't show when the main house is visible. I suggest to come up with the solution I have sketched out and see if it satisfied our needs!

[GunChleoc (gunchleoc)]

a) Should be done already

b) I can look into, this is definitely something that we want.

c) Not a fan. What if you have a coastline that is full of port spaces? This would mean no foresters, no farms, no reed yard. The player can see the port space in advance, and if (s)he decides to build/plant over it, that's the player's decision.

[toptopple (7010622-q-deactivatedaccount)]

ad a): not in my copy of the branch! As you see in the first attached picture, there are many anchors beside the main Port Spot location; in minor blue houses and even without buildhelp support. Please have a look into it, that's not good as is!

b) and c) are somewhat inter-related. My thought on Anchors is, that if there is no grave argument against them, they should pose a *reliable* source of information about the existence of the Port Spot. Under this measure the blue "radius houses" can be dropped because their only sense of existence was to warn about an invisible Port Spot. When the PS is always visible - unless you build on it - then you can drop the radius houses and reduce the blue indicators to the core PS (where they make great sense). The blue radius houses are graphical noise and - in contrast to the anchor - non-intuitive; if feasible they should be dropped. The reliability of the Anchor as a PS indicator is not guaranteed if random actions like forester and farmer may remove it from sight of the player without his awareness. Shorelines with PS are probably nonsense because they would render shorelines of anchors; probably editors would remove the multitude!

[toptopple (7010622-q-deactivatedaccount)]

Attached picture shows the same setting after a while of forester activity. What a difference!

[toptopple (7010622-q-deactivatedaccount)]

Encountering severe problems. Made a test game on Clavisson; some observations

1. game saving crashes (output see text below)
2. when trying to load a saved game, program crashes
3. all forester of the AI players (3) stay at home
4. there is (at least) one Port Spot which is not showing up as anchor (see attached picture)

== Output, probably at game saving ==

Writing Map Objects ... Tribe immovable 'resi_gold2' has no owner!! Tribe immovable 'resi_gold2' has no owner!! Tribe immovable 'resi_gold2' has no owner!! Tribe immovable 'resi_gold2' has no owner!! Tribe immovable 'resi_gold2' has no owner!! Tribe immovable 'resi_none' has no owner!! Tribe immovable 'resi_coal2' has no owner!! Tribe immovable 'resi_gold2' has no owner!! took 108ms
 Writing Flagdata Data ... took 5ms
 Writing Roaddata Data ... took 26ms
 Writing Buildingdata Data ... took 28ms
 Writing Node Ownership Data ... took 9ms
 Writing Exploration Data ... took 13ms
 Writing Players Unseen Data ... took 82ms
 Writing Scripting Data ... took 1466ms
 Writing Objective Data ... took 1ms
 Writing map images ... took 0ms
 MapSaver::save() for 'Calvisson' took 1899ms
Game: Writing Map Data took 1899ms
Game: Writing Player Economies Info ... took 2ms
Game: Writing ai persistent data ... took 0ms
Game: Writing Command Queue Data ... took 770ms
Game: Writing Interactive Player Data ... took 0ms
GameSaver::save() took 2965ms
SaveHandler::save_game() took 2965ms
Autosave: save took 2966 ms
TI(90371): destination appears to have become split from current location -> fail
TI(90289): destination appears to have become split from current location -> fail
TI(90501): destination disappeared or economy mismatch -> fail
TI(90131): destination appears to have become split from current location -> fail
TI(90473): destination appears to have become split from current location -> fail
TI(90545): destination appears to have become split from current location -> fail
TI(90313): destination appears to have become split from current location -> fail
TI(90518): destination appears to have become split from current location -> fail
TI(90553): destination appears to have become split from current location -> fail
TI(90500): destination appears to have become split from current location -> fail
 Internal error: Immovable at 64x166 does not match: is None but portspace_anchor was expected.
widelands: ../src/logic/map_objects/immovable.cc:130: void Widelands::BaseImmovable::unset_position(Widelands::EditorGameBase&, const Widelands::Coords&): Assertion `f.field->immovable == this' failed.
Aborted (core dumped)

== Output at game loading ==

Reading Exploration Data ... took 15ms
 Reading Flag Data ... took 102ms
 Reading Road Data ... took 4ms
 Reading Building Data ... took 57ms
 Reading Flagdata Data ... took 2ms
 Reading Roaddata Data ... took 88ms
 Reading Buildingdata Data ... took 18ms
 Second and third phase loading Map Objects ... WidelandsMapLoader::load_map_complete() for 'Calvisson' took 561ms
GameLoader::load() took 2509ms
Fatal exception: [../src/logic/map_objects/map_object.cc:676] Unknown MapObjectType 0.
FATAL ERROR - game crashed. Attempting emergency save.
terminate called after t...

[GunChleoc (gunchleoc)]

Oops, I forgot to test saveloading again with my last commit.

[Leighton Man (leightonman)]

This problem, or one very similar, also affects mine sites.
 Please see recent posts on this topic
http://wl.widelands.org/forum/topic/4167/
I have attached a savegame

[kaputtnik (franku)]

Answered in the forum: https://wl.widelands.org/forum/post/23689/

[GunChleoc (gunchleoc)]

Migrated to https://github.com/widelands/widelands/issues/1475