• New Horizons on Maelstrom
    Maelstrom New Horizons


    Visit our website www.piratehorizons.com to quickly find download links for the newest versions of our New Horizons mods Beyond New Horizons and Maelstrom New Horizons!

Fixed Invalid island index

jsv

jsv

Freebooter
Storm Modder
A.H said:
:xmas Merry Christmas to all.. and happy holidays :xmas
Click to expand...
Thanks. The very same to you! :beer:

This one
Code: 
COMPILE ERROR - file: dialogs\Random_sailors_sit_tavern_dialog.c; line: 47
Invalid Expression
is already being addressed here: Random Sailors Sit Tavern Dialog: Various Errors
Some of the others look interesting... Say, this:
Code: 
RUNTIME ERROR - file: islands\islands.c; line: 17
invalid index -1 [size:24]
RUNTIME ERROR - file: islands\islands.c; line: 17
function 'GetIslandByIndex' stack error
or this:
Code: 
COMPILE ERROR - file: dialogs\English\Debug.h; line: 1
Duplicate variable name: DLG_TEXT
COMPILE ERROR - file: dialogs\English\Debug.h; line: 1
Duplicate variable name: DLG_TEXT
 
The Debug error probably came because of the first error. Because of that a dialog files wasn't unloaded right so there was a dublicate variable name now.
So if the dialog file for the random sailor is fixed this should be fixed too.
The island error is fixed in here, if you give a -1 now it should pick it up and still return island 0 and post an error in the compile log instead:
Mod Release - Levis' Stuff [Dec 31] | PiratesAhoy!
 
Of course we'll never be able to track down where this bug gets triggered now.
There isn't any more information to be gained though, which is a bit of a shame.

I wished I knew when and how this error got triggered in the first place and how it could be replicated.

Island 0 is Martinique, I think, which is most likely not the correct value to return.
So I'm not entirely sure if this is truly a fix for the root problem.... :confused:
 
Pieter Boelen said:
Of course we'll never be able to track down where this bug gets triggered now.
There isn't any more information to be gained though, which is a bit of a shame.

I wished I knew when and how this error got triggered in the first place and how it could be replicated.

Island 0 is Martinique, I think, which is most likely not the correct value to return.
So I'm not entirely sure if this is truly a fix for the root problem.... :confused:
Click to expand...
It will at least make sure everything keeps working :p.
I would also like to know when it is triggered, but this at least makes sure no unexpected things happen.
 
Altough come to think of it maybe we shouldn't do this indeed. It could make testing stuff harder....
Feel free to remove it.
 
Not included it is. Also marked this as "Awaiting Info" as we'd need more details for a proper fix.
 
Here are some extended error logs on this one:
Code: 
RUNTIME ERROR - file: islands\islands.c; line: 17
invalid index -1 [size:24]
RUNTIME ERROR - file: islands\islands.c; line: 17
function 'GetIslandByIndex' stack error
RUNTIME ERROR - file: interface\shipyard.c; line: 5091
Using reference variable without initializing
RUNTIME ERROR - file: interface\shipyard.c; line: 5091
Using reference variable without initializing
RUNTIME ERROR - file: interface\shipyard.c; line: 5091
null ap
RUNTIME ERROR - file: interface\shipyard.c; line: 5091
null ap
RUNTIME ERROR - file: interface\shipyard.c; line: 5093
uninitialized aref

This indicates the problem gets triggered here in the shipyard interface code:
Code: 
bool CheckForContraband(ref _refCharacter)
{
   if ( CheckCharacterPerk(GetMainCharacter(),"Trustworthy")) return false;
   //if ( FindFirstContrabandGoods(GetMainCharacter()) != -1) return true;
   int i;
   int curIslandIdx = GetCharacterCurrentIsland(_refCharacter); // <------------- THIS LINE -----------
   ref CurIsland = GetIslandByIndex(curIslandIdx);
   aref islRef; makearef(islRef,CurIsland.Trade.Contraband);
 
I can consistently trigger this problem now. Just click on a companion ship image in the Shipyard Interface.

Made the following code changes for testing purposes:
Code: 
//Levis -->
bool CheckForContraband(ref _refCharacter)
{
   if ( CheckCharacterPerk(GetMainCharacter(),"Trustworthy")) return false; // PB: Should we not be checking officers here too???
   //if ( FindFirstContrabandGoods(GetMainCharacter()) != -1) return true;
   int i;
   int curIslandIdx = GetCharacterCurrentIsland(_refCharacter);
   if (curIslandIdx < 0)
   {
     TraceAndLog("CheckForContraband ERROR - Invalid Island Index. Please post your compile.log file at piratesahoy.net!");
     DumpAttributes(_refCharacter);
   }
   ref CurIsland = GetIslandByIndex(curIslandIdx);
The problem then becomes obvious enough.
 
As far as I can tell, this change in CharacterUtilite.c solves the problem:
Code: 
int GetCharacterCurrentIsland(ref _refCharacter)
{
// KK -->
   /*int curLocNum = FindLocation(Characters[GetMainCharacterIndex()].location);
   if(curLocNum<0) return -1;
   return GetIslandIdxByLocationIdx(curLocNum);*/
   // PB: Make this work for companion ships while ashore too -->
   string curLoc = "";
   if (CheckAttribute(_refCharacter, "location"))
   {
     curLoc = _refCharacter.location;
     if (curLoc == "None" && CheckAttribute(_refCharacter, "location.from_sea"))
     {
       curLoc = _refCharacter.location.from_sea;
     }
   }
   else
   {
     return -1;
   }
   // PB: Make this work for companion ships while ashore too <--
   int locidx = FindLocation(curLoc);
   if (locidx < 0) return -1;
   return GetIslandIdxByLocationIdx(locidx);
// <-- KK
}
If there isn't a valid "location" to use, it will try to use "from_sea" instead which appears to be updated correctly for companion ships.

I checked it on Grenada and it was "Conceicao_port". Then teleported to Speighstown port and it changed to "Oxbay_port".
And no more error.log entries from the Shipyard Interface.
 
The problem, at least last time, was that the game couldn't figure out the island where your companion ship is.
Maybe I need to put a failsafe in there so it returns the island you are currently on if it can't find what it should.

The reason I didn't do that before is in case you are at a different island than your ship is or if your companion ship is somewhere else.
At the moment that should never happen, but you never do know about the future, so I had hoped to be safe.

@Hylie Pistof: Do you happen to have a savegame where you can reliably trigger that error.log entry at the shipyard when you click on a companion ship?
 
Nope. Too cryptic for me. I don't know how much old stuff to remove if any, nor where exactly to put that new stuff. Here's the save if you want to try it.
 

Attachments

  • -=Player=- Jamaica.7z
    650.5 KB · Views: 114
@Hylie Pistof: Turns out the problem was something else.
The location of the captain was IN HIS CABIN and his cabin isn't marked as being on ANY island.
So I improved and simplified the responsible function so that it checks a different attribute FIRST, which seems to have solved the problem.

As a bonus, the shipyard smuggling check now also checks your OFFICERS for the "Trustworthy" perk.
At some point I added a comment there asking if that shouldn't be done, but Levis never responded.
So now that I see it again, I AM doing it. :cheeky

For future reference, this is the final version I made now:
Code: 
int GetCharacterCurrentIsland(ref _refCharacter)
{
// KK -->
   /*int curLocNum = FindLocation(Characters[GetMainCharacterIndex()].location);
   if(curLocNum<0) return -1;
   return GetIslandIdxByLocationIdx(curLocNum);*/
   // PB: Make this work for companion ships while ashore too -->
   string curLoc = "";
   if (CheckAttribute(_refCharacter, "location.from_sea"))         curLoc = _refCharacter.location.from_sea;
   if (curLoc == "" && CheckAttribute(_refCharacter, "location"))     curLoc = _refCharacter.location;
   // PB: Make this work for companion ships while ashore too <--
   int locidx = FindLocation(curLoc);
   if (locidx < 0) return -1;
   return GetIslandIdxByLocationIdx(locidx);
// <-- KK
}
 
pedrwyth said:
Hylie's saved game had the companion at location=shipdeck5 so the work round to use location from_sea isn't called into play - although it exists (because location does not equal "none") - next question why shipdeck5 but perhaps just use the from_sea location in all cases if it exists?
Click to expand...
You're exactly right. :yes

Have a look at the proposed solution in my previous post. That seems to have done the trick.

I could add extra fail safes and checks in there, but as long as this works, I'm inclined to not add more complexity to it. :cheeky
 
You must log in or register to reply here.
Back
Top