[We the People] Bug reporting

[nci]

In single player there was a bug related to ship wrecks, which is now fixed though. (by @Nightinggale and myself)
However I have no idea if that bug is also fixed for hotseat.

Was it XML fix, or DLL fix? If it was XML, can I take a look?

 

[raystuttgart]

Was it XML fix, or DLL fix?

DLL, because it was a logic problem not a configuration problem.
The logic is DLL, XML is nothing else than configuration.

Most of our post-release bugfixes are logic related. (Especially the ones that are tricky.)
Only very few are related to configuration. (Those are easy to find and fix, thus mostly already caught in internal testing.)

---

To explain it for a beginner:

XML is the paper with instructions, the DLL is the brain that interprets it and tells the body what to do.

• Writing a short instruction on sheet of paper is simple and takes minutes. --> XML
  
• Teaching the brain what to do with that instruction is difficult and takes days or weeks --> DLL
• Making the body do what the brain says is tedious and lots of work (may take months) --> writing texts, graphics, maps, screens, events ...

 

[nci]

@raystuttgart thank you for patience and detailed explanation.

 

[Ramstormp]

Possible, but it would be "try and error" without a reliable way to test it ...

It would only need to be tested in hotseat mode, which I did, and the first thing that popped out of the camp fire was a native trader.

 

[nci]

It would only need to be tested in hotseat mode, which I did, and the first thing that popped out of the camp fire was a native trader.

Maybe it's tied to difficulty level (I play on Revolutionary exclusively)? Or some other unknown factor... I only get Native Slaves.

 

[Ramstormp]

Maybe it's tied to difficulty level (I play on Revolutionary exclusively)? Or some other unknown factor... I only get Native Slaves.

The check I referred to was applied to whether a unit is only defensive or not. Native slaves are only defensive, native traders are not. I have no idea why this was necessary, but I assume it was something to stop network games from going out of sync. There could be some good reason why you should not be allowed to have offensive units jump out of the flames in hotseat mode.

 

[raystuttgart]

@Ramstormp
If I understand this correct it seems as if the bug is solved in the current release?
(Because @Nightinggale and myslef had fixed something related to Goody triggering by specific Units.)

 

[raystuttgart]

Ah, now I understand, it was related to this.

This was implemented on purpose when Unit Goodies were implemented (I think in RaR).
It is not a bug, it was meant to prevent "one lucky strike win" scenarios in MP games.

But ok, I can remove it.

Will make MP games a lot more suprising.
(The balancing reasons we needed it do not fully apply anymore anyways.)

       if ((GC.getUnitInfo(eUnit).getCombat() > 0) && !(GC.getUnitInfo(eUnit).isOnlyDefensive()))
       {
           if (GC.getGameINLINE().isGameMultiPlayer())
           {
               return false;
           }
       }

 

[Ramstormp]

@Ramstormp
If I understand this correct it seems as if the bug is solved in the current release?
(Because @Nightinggale and myslef had fixed something related to Goody triggering by specific Units.)

I think maybe you fixed the shipwreck goody issue, but it does not look like you fixed the campfire goody issue (if it is even broken).

EDIT: ok, nevermind

 

[raystuttgart]

I was totally confused because everybody talked about a "bug" ...
I was not expecting that something that was implemented on purpose was actually meant.

Reason:
During the times it was implemented (in RaR if I am correct) there were much less Unit goodies.
Getting something like a "Native Mercenary" early on could mean win or loss in a game.
(We did not want to have that in MP games because in those days people insisted on MP games not being won by RNG.)

But whatever:
It is removed now.

There are much more Unit Goodies now and there is no reason anymore to keep the check.
Getting a single combat Unit will not decide about victory or loss anymore like in the old days.

Summary:
"Bug" fixed.

@Ramstormp
Thanks for checking.
It helped me a lot to actually understand what the "bug" was about.

And no:
The other bug I was talking about was related to Ships like e.g. Privateers triggering a Water Goody.
(It was something totally different and a real bug in the logic - because it had Cargo Space but could only cary Goods not Units.)

 

[nci]

In hotseat, even ships like Caravel and Carrack are unable to pick-up Indentured Servants from appropriate shipwreck - they get nothing at all. Hope this will get fixed someday...

 

[raystuttgart]

Hope this will get fixed someday...

It already IS with my last commit.
(e.g. Carracks are also not only defensive, so the code above applied to them as well.)

Summary:
Relax and wait for the next release.
Now that I understood the "bug", it is resolved.

 

[raystuttgart]

It is possible that we may have stumbled over the source of "Negative Yield Bug in City Screen".
If I am correct it is fixed now.

Edit:
@Ramstormp actually found the place where the bug was triggered.

 

[PH2]

Not sure if something like this has been reported before, but it doesn't have any effect on the gameplay other than the "enemy near" sound happening every turn is beyond annoying.

 

[raystuttgart]

Not sure if something like this has been reported before, but it doesn't have any effect on the gameplay other than the "enemy near" sound happening every turn is beyond annoying.

It should be fixed in the internal development branch but I will check it again.
(In a single player game you could simply open Worldbuilder and delete it. - Unless you deactivated WB.)

If it is not fixed already, it is really easy to fix.

 

[raystuttgart]

@PH2
Thanks for reporting.

The bug still existed in internal release but is now fixed.
(Terrain Features are checked now as well.)

 

[PH2]

Cool, thanks!

 

[jooe]

I have encountered a CTD bug in the current "Plains" branch.

page fault on read access to 0x00000040 in 32-bit code (0x0333db71)

Backtrace says it is in CvCity::getFortDefenseBonusForCity+0x61() [cvcity.cpp:9505]

movw  0x40(%ebx),%ax

(to me that seems to be a nullptr reference)

Save file attached ...

 

[raystuttgart]

I have encountered a CTD bug in the current "Plains" branch.

Thanks, it is fixed now.
(I had simply forgotten to check that pPlot is not Null)

Edit:
Currently can not commit though since my code already contains another big feature.
(That other big feature is not yet done and thus can not be commited.)

Edit 2:
The same fix was necessary for
CvCity::getMonasteryCrossBonusForCity()

 

[jooe]

I found the cause of the problem myself:
The Portuguese player is founding a city on the bottom of the map, with only 1 plot distance to the map border.
The loop through the city plots will then try to access non-existing plots.
Removing their settler before end of turn allows the game to continue.
Maybe it is not a good idea to allow cities so close the map border, I suspect this could cause all kinds of problems ...?

Suggested fix: do not allow cities 1/2 plots from the map border (depending on city radius)