[We the People] Bug reporting

[raystuttgart]

I know that the sailing routes are cleverly implemented. That's why I was surprised that something like that happened ...

What we actually implemented is not the "more versatile all Cities" variant, but only "Harbour Cities" variant.
So yes there is a bug somewhere.

But I also tested already "Large Rivers" and it is not related to "Large Rivers" either.
The bug must be caused by something else.

So what are you playing?
A "Scenario Map" or a map generated by "MapScript"?

 

[raystuttgart]

Ah ok, I think I know already know the cause of bug ...

@Nightinggale
As it seems the "Sail to Logic" cosiders all Cities that are at a Water Area with getMIN_WATER_SIZE_FOR_OCEAN()
(So it will also consider unreachable ports that are at really large Lake.)

By the way:

If my old design would have been used, that would not be a problem because the bug would not even exist. (see here).
Because it would have checked for actual Ocean Access (Europe Plots) - since it would have been need for "Inland Cities" anyways.

Comment to my old design:

It was intended to have "Harbours Cities" (sailing directly) and "Inland Cities" (just sailing to closest Europe Plot) in different colours in the "Sail to List".
And the "Harbour Cities" should also be listed at the top of the selection list. (The inland Cities at the bottom.)

As I said should allow to select both kinds as "destinations". I still consider it as extremely helpful especially for "Gigantic Empires".

• It would e.g. make shipping Colonists to Inland Cities easier because you would not need to worry about the specific port anymore. (You would target the closest arrival point anyways.)
  
• It would also allow to e.g. easily send troops to a Continent or Island (that still has some of your Cities) if all Port Cities have been taken. (You would also target the closest arrival point.)
  
• It would ...

----

Edit:

Sorry, I start hijacking the "bugs" thread with a feature concept.
(In this case it however also contains the bugfix: checking actual Ocean Access.)

Adapting the current code to something like this should do the trick:
(Not yet the correct code - it is just an example from another code.)

if (pPortCity->isCoastal(GC.getMIN_WATER_SIZE_FOR_OCEAN()) && pPortCityPlot->isEuropeAccessable())

@Nightinggale:

What do you think should we implement?
The bug itself is easy to fix. (A couple of minutes.)
But I could also implement my suggested concept above ...

It is in the "Europe Screens" (Europe, Africa, Port Royal)
see here:

       while (city):
           if city.isCoastal(gc.getMIN_WATER_SIZE_FOR_OCEAN()):
               if unit.getGroup().generatePath(plotEast, city.plot(), 0, false, None, true):
                   self.CityPlotList.append([city, None])
               elif unit.getGroup().generatePath(plotWest, city.plot(), 0, false, None, true):
                   self.CityPlotList.append([city, None])
           (city, iter) = player.nextCity(iter, false)

This check is simply not enough:
gc.getMIN_WATER_SIZE_FOR_OCEAN()
----

Sometimes I also get lost in all these old designs I still have and do not even remember anymore what was already implemented and what was not ...
It is actually not even that difficult to implement - it was basically just a bit more effort than the simple "List all Harbour Cities" (at Water areas large enough)- that as we see now also caused this bug.

@Raubwuerger
Thanks for the bug report.
It is easy to fix and maybe we will even create an improved version of "Sail To".

 

[Raubwuerger]

I'm playing a "Map Script".

• FaireWether
• Gigantic
• Epic
• Few Islands
• Quite Irregular

 

[raystuttgart]

I'm playing a "Map Script".

• FaireWether
• Gigantic
• Epic
• Few Islands
• Quite Irregular

Thanks, I just needed to know if it was a specific "Map" or a "Map Script".
Otherwise the bug is already analyzed. (see here)

Sorry for first doubting the bug.

I had really thought that the "design" I spoke about had already been implemented.
I simply have so many old designs lying around that I sometimes forget what I already had implemented and what I had not yet implemented ...

 

[Nightinggale]

@Nightinggale:

What do you think should we implement?
The bug itself is easy to fix. (A couple of min)
But I could also implement my suggested concept above ...

It is in the "Europe Screens" (Europe, Africa, Port Royal)

Without having looked at the code, I would say the most clean approach would be linked to my plan for fixing area issues regarding large rivers. If a large river can be water and land at the same time, then it would be possible to have colony plots have both a land and a water area. CvArea should then cache if it has a Europe access plot. The test condition is then to find colonies where the water area in the colony plot has Europe access. This is unlikely to fail in the future as the code is quite clean. I just added a new xml file for TradeScreens and if the cache in CvArea is a bool EnumMap of TradeScreenTypes, then the code will support areas, which can access some, but not all trade screens. No idea if we will ever need that, but since it's somewhat trivial to add here, we might as well do it. Sure it's trivial to add later too, but then it requires testing. Since this requires testing as well, we might as well get it done right the first time and skip the second test.

Since this would all be based on cached values, speed will be more or less instant. It might even be faster than the current code.

 

[raystuttgart]

for fixing area issues regarding large rivers.

It is not related to "Large Rivers".
(I had taken care of that in my code for Large Rivers.)

But I also tested already "Large Rivers" and it is not related to "Large Rivers" either.
The bug must be caused by something else.

It has absolutely nothing to do with "areas" or something like that.

-----

It is simply related to "big lakes":

As it seems the "Sail to Logic" cosiders all Cities that are at a Water Area with getMIN_WATER_SIZE_FOR_OCEAN()
(So it will also consider unreachable ports that are at really large Lake.)

The solution is simply here.

• A few min for just fixing (that would still just show port cities)
  
• A few hours for "my old concept" (allowing inland cities as destinations, with coloured and sorted destination list)

 

[Nightinggale]

It is not related to Large Rivers.

I know. My point is that if/when I implement that CvPlot can have two areas (one for DOMAIN_OCEAN and one for DOMAIN_LAND) if the terrain is a large river, then CvPlot will have memory allocated for two areas in all plots.

With "engine support" for two areas in one plot, using it to have colonies have two areas would be simple. It solves two unrelated issues, but the code to handle the solution would still be the same.

Now that I think about it, if colonies have a water area too, we can remove the hack, which allows water units to enter land plots if it has a colony.

 

[raystuttgart]

So you are saying that your solution - with areas (needed for improving Large Rivers) - would also solve the bug that "Sail to List" could chose "unreachable Harbor Cities at Large Lakes"?
How is that ? I do not see the connection.

And the fix for the issue above is also possible to implement within a couple of minutes.
(Only my "old concept" needs a bit more.)

 

[Nightinggale]

So you are saying that your solution - with areas (needed for improving Large Rivers) - would also solve the bug that "Sail to List" could chose "Harbor Cities at Large Lakes"?
How is that ? I do not see the connection.

Think about how areas spread. If a water area can spread into colony plots, then sailing to a colony would require that the colony is in the same area as a Europe access plot. If they are, then the colony must be accessible.

Come to think about it, how is the water area in large rivers handled? Is it the ocean area spreading? If so, then it would be problematic if we have an inland ocean connected to a large river, which then connects to an ocean with Europe access. This is not just for sailing to and from Europe, but in general the ships, which can't enter large rivers won't be able to tell they can't move between two ocean connected colonies without using pathfinding, which is CPU intensive.

Maybe we should add a large lake terrain, which uses the ocean graphics, but we can use it to identify this problem.

And the fix for the issue above for the "Sail to List" not showing "Harbor Cities at Large Lakes" is also possible within 2 min.
(Only my "old concept" needs a bit more.)

If you have a working fix, which takes 2 minutes, then go for it.

 

[Mr. ZorG]

Maybe we should add a large lake terrain

it's high time to do it

 

[Jazzer32]

2 small bugs for version 2.9:
1) SS in attachment. Despite having 2048 gold - I cannot pay 170 required (happened only once)
2)Happened only twice (not sure is it maybe some new feature in 2.9). I approach (new) native village with my seasoned scout, out of moves (Im on square bordering the village), end of turn, at beginning of next turn, new colonist (mine) is spawned in native village, first time it was native trader, second time it was free colonist. I haven't entered village yet. (happened like... 2 out of 50 times)
3)Is it possible somehow to switch to old style export-import menus? with 1 line, instead of 2 lines for every good?

 

[raystuttgart]

... large lake terrain ...

Sounds quite good actually and it would bring further benefits ...

it's high time to do it

We would however not need a "Large Lake Terrain", we would simply need a "Lake Terrain".

I used the "Large Lake" as explanation because in the example of @Raubwürger the game actully considers it an Ocean.
It is simply bigger than gc.getMIN_WATER_SIZE_FOR_OCEAN() - thus technially not a lake anymore.

The difference between a "Lake or Ocean" is currently just the amount of Ocean and Coast Plots.
Large Rivers do not count as Lake! (I programmed them explicitely to be "not counted as Lake".)

Generally it is a good idea.

• I hated all these "Lake hacks" the DLL does to differentiate a Lake from Ocean just by size.
• Thus it is not even possible to balance Lake Plot Yields or give it specific Bonus Ressources by XML

The problem is simply the effort:

1. It will be extremely hard to teach that to Map Generation by MapScrits
2. Somebody would have to rebuild all Maps - and I refuse to do that again because it is a hell of an effort.

First concept idea:

• Maybe we can have the DLL automatically transform Ocean Terrain without access to Europe Plots into Lake Terrain.
  
• Maybe we can also have DLL automatically transform Lake Plots with access to Europe Plots into Ocean Terrain.

-------

Summary:

Ok, I will create a thread for "Lake Terrain".

 

[raystuttgart]

Think about how areas spread. If a water area can spread into colony plots, then sailing to a colony would require that the colony is in the same area as a Europe access plot. If they are, then the colony must be accessible.

Ah ok, I understand now.

If you have a working fix, which takes 2 minutes, then go for it.

Will do.

It is a simple fix in the Python Files (EuropeScreen, Africa Screen, Port Royal Screen.)
It will at least catch all cases of Lake areas that do not have "Europe Access".

As I said, all I need is to use this as well:

isEuropeAccessable()

This here is simply not enough:

isCoastal(GC.getMIN_WATER_SIZE_FOR_OCEAN())

 

[Mr. ZorG]

Somebody would have to rebuild all Maps

i will do it

edit: @raystuttgart also in the World Builder will need new graphics for the Lake Terrain Type

 

[raystuttgart]

edit: @raystuttgart also in the World Builder will need new graphics for the Lake Terrain Type

Whenever you configure a new Terrain it is automatically available in Worldbuilder - if you do it correctly.

Let us continue discussing "Lake Terrain" here though.
We are hijacking the bugs thread ...

 

[Nightinggale]

1) SS in attachment. Despite having 2048 gold - I cannot pay 170 required (happened only once)

This happens when:

1. foreign leader makes an offer
2. you get gold (like selling in Europe)
3. offer is displayed

The problem is that the answers are generated in step 1 meaning even though you have more gold at step 3, it will give you the answers from step 1. It's a known issue and hard to fix because it mainly takes place in the exe (outside of our reach).

I wonder if it would be better to skip checking for gold and add the buy option in step 1. That way it will be possible to tell the king you want to buy, but if you answer that and you lack gold, then nothing will happen. That might be less bad than the annoyance of not being able to pay when you have the gold.

2)Happened only twice (not sure is it maybe some new feature in 2.9). I approach (new) native village with my seasoned scout, out of moves (Im on square bordering the village), end of turn, at beginning of next turn, new colonist (mine) is spawned in native village, first time it was native trader, second time it was free colonist. I haven't entered village yet. (happened like... 2 out of 50 times)

Never heard of this issue before. No idea what happened.

3)Is it possible somehow to switch to old style export-import menus? with 1 line, instead of 2 lines for every good?

Currently no. It will require changing the code in the DLL file. The reason why it's on two lines is because there isn't enough room on one line for all options.

I will however say that a one line interface has been on my wishlist ever since we lost it. Bringing it back means losing some settings meaning a one line layout would have to be an optional addon like right clicking the button. Another idea, which needs further investigation to figure out how realistic it is to implement.

 

[Kendon]

I wonder if it would be better to skip checking for gold and add the buy option in step 1. That way it will be possible to tell the king you want to buy, but if you answer that and you lack gold, then nothing will happen. That might be less bad than the annoyance of not being able to pay when you have the gold.

I'd like that.

 

[raystuttgart]

I wonder if it would be better to skip checking for gold and add the buy option in step 1. That way it will be possible to tell the king you want to buy, but if you answer that and you lack gold, then nothing will happen.

Let me think about it.
So ok then let us do it like this:

• We could skip the "Gold Check in 1". (Thus allways offer the "Buy Option".)
  
• The "Buy Option" needs to be formulated as something neutral like "Yes, we would like ... if our treasury allows to".
• Of course the "Reject Option" should always still be available in case you do not want to.

@Nightinggale
Ok the solution is fine to me.

It is quite some effort though to do it for all DLL-Diplomacy Events.
(Because there are about 12 of them ...)

Quite a lot of small code pieces and texts to be rewritten.
(Although every single code change is not extremely easy.)

Summary:

Ok, let us create a ticket for it.
I just wonder who is going to invest the effort for it.
I agree it is reasonable but I am not motivated to do it.

 

[Nenos]

The trader event doesn't work well. It would be great if someone can add that the event cant fire if the square has an improvement.

 

[Nightinggale]

The trader event doesn't work well. It would be great if someone can add that the event cant fire if the square has an improvement.

I also spot an issue with the text. It's cut off because it ran out of room.