• 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 Transfer Crew Interface Error Log

Ok checked this and it may (or may not if works as intended) be a bug. It is different from 3.4 but this is intentional.

Basically what has changed is the code in ransack main relating to what you can do with prize ships. I note in my test the button was reading assign prize crew but I'm not sure if the other scenarios (ie pirated vessel) will allow transfer as in the past. So it may just be part of the new code stopping you from raiding prize ship content EDIT the rest of which has indeed been commented away but this element remains active ENDEDIT- however I'm not sure this actually should affect crew transfer (I don't think the crew were ever part of the value of a prize and either joined the victors or were prisoners).

Also looking at the code as it stands it does only allow for player ship to provide the extra crew if necessary for the prize which could mean although it is a prize there aren't enough crew for the two - but you would have in a different ship in your fleet if that could be selected.

So the answer is -it depends.

2ND EDIT The code is in a section for Legal Prize Ships but is only controlled by if you can set a captain (ie selectable CHARACTERS BUTTON) which seems to be all captured ships ENDEDIT
 
Last edited:
@pedrwyth: You are referring to this section of code, right?
Code: 
     // PB: Legal Prize Ships -->
     if (GetSelectable("CHARACTERS_BUTTON")) // You CAN assign a captain
     {
       int TotalMinCrew = GetMinCrewQuantity(xi_refCharacter) + GetMinCrewQuantity(refEnemyCharacter);
       int TotalCrew  = MakeInt(xi_refCharacter.ship.Crew.Quantity) + makeint(refEnemyCharacter.ship.Crew.Quantity);
       if (IsPrizeShip(refEnemyCharacter) && TotalCrew >= TotalMinCrew) // Will be a prize ship AND you have enough crew to sail both ships
       {
       /*   SetSelectable("GOODS_BUTTON", false);
         SetSelectable("CANNONS_BUTTON", false);
         SetSelectable("SWAP_BUTTON", false);
         SendMessage(&GameInterface, "lsls", MSG_INTERFACE_MSG_TO_NODE, "GOODS_BUTTON"  , 0, "Cannot plunder");*/
         SendMessage(&GameInterface, "lsls", MSG_INTERFACE_MSG_TO_NODE, "CREW_BUTTON"  , 0, "Assign prize crew");
       /*   SendMessage(&GameInterface, "lsls", MSG_INTERFACE_MSG_TO_NODE, "CANNONS_BUTTON", 0, "Cannot take cannons");
         SendMessage(&GameInterface, "lsls", MSG_INTERFACE_MSG_TO_NODE, "SWAP_BUTTON"  , 0, "Cannot take ship");*/
       }
     }
     // PB: Legal Prize Ships <--
That is mostly a left-over from an abandoned experiment of mine to limit what you can and can't do with legal prize ships.
Since those changes weren't very welcome, I disabled them.

The only line that is still active there is this one:
Code: 
SendMessage(&GameInterface, "lsls", MSG_INTERFACE_MSG_TO_NODE, "CREW_BUTTON"  , 0, "Assign prize crew");
All that does is to change the text on the button; I figured it might be nice to keep that so you notice a difference between taking a ship as a legal prize or not.
But it should really have zero effect on the functionality of the interface.

Even WITH all those lines enabled, the Crew button is the one that should remain unaffected.
Taking Cargo and Cannons or Swapping was disabled for a while, but never taking/assigning Crew.

So I can't think why this should have anything to do with it.... :confused:
 
OK point taken I just presumed that the commented out section of code beneath - which does have a bit about companions (amongst other enable/disable options) had been replaced in that process and left unrestored.

As stated above the two ransack_crew files are identical (to all purposes) between 3.4 and now but the companion ship choice has definitely gone for me somehow. I will look a bit deeper into ransack_main.c and compare that to its 3.4 self for clues. I will also work on the assumption that the functionality is to be put back if I find what has blocked it.
 
I'm not sure I quite understand what the exact bug is here.
Is it a problem in the "Transfer Crew" interface that you are pressing arrow keys but crew is not being transferred?
That is what I originally understood, but now I'm thinking maybe I didn't get that right....

Looking critically at that code, this section does look WRONG to me:
Code: 
     if(ProfessionalNavyNation() != UNKNOWN_NATION && GetRank(xi_refMainChar, GetServedNation()) < 7)
     {
       SetSelectable("SWAP_BUTTON", false);
     }
     else
     {
       SetSelectable("SWAP_BUTTON", !IsTrader(xi_refCharacter)); // KK
     }
     SetSelectable("SWAP_BUTTON", !IsTrader(xi_refCharacter) && ProfessionalNavyNation() == UNKNOWN_NATION); // KK && PB
First it enables/disables the "SWAP_BUTTON". And then it overrides that and does it AGAIN.
I was probably working on that and accidentally left the new code and the old code BOTH active. Uhm.... Oops! :facepalm
That last line there should definitely be removed. Though I don't think that has anything to do with the bug you're after here.

transfer_crew.c does contain one line that may have something to do with this.
You already mentioned that as the possible culprit a while back, if I recall:
Code: 
    if(nCompanionIndex == -1) continue; // PB: Hopefully prevent an error on the next line
Bit of background on that one: I saw an error.log entry one day and added that line to HOPEFULLY prevent it in the future.
I have no clue if that was actually a proper fix or why that error log even happened.
So you can get rid of that line to start with and see if that makes any difference.
 
Pieter Boelen said:
I'm not sure I quite understand what the exact bug is here.
Is it a problem in the "Transfer Crew" interface that you are pressing arrow keys but crew is not being transferred?
That is what I originally understood, but now I'm thinking maybe I didn't get that right....
Click to expand...
No the bug is that once in the interface you can't changer from your ship to a companion to make the transfer to them - it works fine to your own ship (which is what I think the other testers were effectively reporting). Compare with cannons where the arrows either side of your player ship do allow to choose a companion ship (the goods interface is structured differently but there too you can choose to change the left hand ship to a companion). That was the case too for crew in 3.4

Looking critically at that code, this section does look WRONG to me:
Code: 
     if(ProfessionalNavyNation() != UNKNOWN_NATION && GetRank(xi_refMainChar, GetServedNation()) < 7)
     {
       SetSelectable("SWAP_BUTTON", false);
     }
     else
     {
       SetSelectable("SWAP_BUTTON", !IsTrader(xi_refCharacter)); // KK
     }
     SetSelectable("SWAP_BUTTON", !IsTrader(xi_refCharacter) && ProfessionalNavyNation() == UNKNOWN_NATION); // KK && PB
First it enables/disables the "SWAP_BUTTON". And then it overrides that and does it AGAIN.
I was probably working on that and accidentally left the new code and the old code BOTH active. Uhm.... Oops! :facepalm
That last line there should definitely be removed. Though I don't think that has anything to do with the bug you're after here.

transfer_crew.c does contain one line that may have something to do with this.
You already mentioned that as the possible culprit a while back, if I recall:
Code: 
    if(nCompanionIndex == -1) continue; // PB: Hopefully prevent an error on the next line
Bit of background on that one: I saw an error.log entry one day and added that line to HOPEFULLY prevent it in the future.
I have no clue if that was actually a proper fix or why that error log even happened.
So you can get rid of that line to start with and see if that makes any difference.
Click to expand...
OK thanks for these extra thoughts on inconsistencies. I will add them in and go away to see if I can resolve it. I have started a completely fresh save to test this and taking a pirate (but with no spare officer to make captain) did leave the button as crew not assign prize crew but the swap to another ship is still not functional.

To save me getting my head mixed with references again how does the value of !IsTrader(xi_refCharacter vary (I know true or false but is it just is the attacked ship trader or otherwise (pirate or navy presumably))
 
pedrwyth said:
No the bug is that once in the interface you can't changer from your ship to a companion to make the transfer to them - it works fine to your own ship (which is what I think the other testers were effectively reporting). Compare with cannons where the arrows either side of your player ship do allow to choose a companion ship
Click to expand...
Is THAT what it is? To tell the trust, I never even knew such a feature existed! :shock

Would you mind posting a screenshot of the interface we're talking about? I can't think by the top of my head what it exactly looks like.
I remember the main layout and functionality, but this is about stuff more specific than that. :oops:

pedrwyth said:
I have started a completely fresh save to test this and taking a pirate (but with no spare officer to make captain) did leave the button as crew not assign prize crew but the swap to another ship is still not functional.
Click to expand...
Wait a second, does the button text really say "Assign prize crew" while you are a PIRATE yourself?
While not a huge issue, that doesn't sound right. It should say "prize crew" only for Naval Officers or Privateers.

pedrwyth said:
To save me getting my head mixed with references again how does the value of !IsTrader(xi_refCharacter vary (I know true or false but is it just is the attacked ship trader or otherwise (pirate or navy presumably))
Click to expand...
As far as I understand it and the way I have always used that function is to check if it is a QUEST trader.

This is the actual function definition:
Code: 
bool IsTrader(ref _refCharacter)
{
   int findIdx = -1; // KK
   if (CheckAttribute(_refCharacter, "index"))
     findIdx = sti(_refCharacter.index); // changed by MAXIMUS
   else
     return false;

   // PB: Just check single character officer type -->
   if (GetAttribute(_refCharacter, "quest.officertype") == OFFIC_TYPE_TRADER)   return true;
   else                                     return false;
   // PB: Just check single character officer type <--
/*
   // PB: What was this supposed to be doing?
   ref mc = GetMainCharacter();
   for (int i = 1; i < 4; i++)
   {
     if (GetCompanionIndex(mc, i) == findIdx && CheckAttribute(&Characters[findIdx], "quest.officertype") == true && Characters[findIdx].quest.officertype == OFFIC_TYPE_TRADER) return true;
   }
   return false;
*/
}

With the way it currently works, it might as well check for _refCharacter.id == "Quest trader" .
There is only ONE character in the entire game that gets assigned to OFFIC_TYPE_TRADER and that is the tavern-triggered Escort Quest trader.
All regular merchant ships at sea are assigned to OFFIC_TYPE_CAPMERCHANT instead.

Why? I don't actually know.... It all seems rather superfluous to me.
As far as I can tell, it is meant to prevent you from touching that specific companion ship.

But then.... Isn't that what the following more generic functions are meant for?
Code: 
SetCharacterRemovable(characterFromID("quest trader"), false);
And:
Code: 
SetCargoLocked(rTrader, true);

Come to think of it, the way it currently is may be REALLY BAD when you double-cross your escort ship and try to capture them.
Normally ransack_main.c should not ever be used for companions anyway, which includes the "Quest Trader".
And at a time when it IS used for the Quest Trader, then apparently he is no longer a companion and you should be able to steal what you want.
As you can clearly tell, I am a bit confused on what all this is supposed to be doing. :facepalm
Maybe it would be better to get rid of some of those function calls and simplify things a bit.
 
Pieter Boelen said:
Is THAT what it is? To tell the trust, I never even knew such a feature existed! :shock
Click to expand...
Neither did I as stated above somewhere, but then I'm still new round here.

Would you mind posting a screenshot of the interface we're talking about? I can't think by the top of my head what it exactly looks like.
I remember the main layout and functionality, but this is about stuff more specific than that. :oops:
Click to expand...

Here is the main ransack interface ransack1.jpg

where you can select a companion by using the arrows either side of Macallister (but this would be a pic too far) but a choice there doesn't stick when you choose a sub-screen so here is goods when chosenloot1.jpg but then you can re-assert the choice of companion loot2.jpg which does then work to give the goods to them.

Same situation for cannons cannons1.jpg cannons2.jpg
but as bugged not for crew


crew.jpg EDIT Sorry about the horrendous quality of the severly compressed images when I now call them up off the forum- I wanted them in one post but I'm sure it will remind you enough to get the idea.
 
It was indeed the one changed line
Code: 
if(nCompanionIndex == -1) continue;
that had emasculated the change to companion functionality so restoring the old version without this line does the trick to fix it. So you can all see what you have been missing.
 

Attachments

  • transfer_crew.7z
    3.9 KB · Views: 91
pedrwyth said:
It was indeed the one changed line
Code: 
if(nCompanionIndex == -1) continue;
that had emasculated the change to companion functionality so restoring the old version without this line does the trick to fix it. So you can all see what you have been missing.
Click to expand...
Thanks for confirming that!

With a bit of luck, the error I had tried to fix will not crop up again.
But even if it does, I don't think it was ever a huge problem. So this sounds like a good idea to me! :woot
 
In Build 14 Beta 4.1 ( 16 may )

I went to the shipyard and sold a companions ship ( after transfering the crew to mine )

I got this in the error log:-

Code: 
RUNTIME ERROR - file: interface\transfer_crew.c; line: 229
Using reference variable without initializing
RUNTIME ERROR - file: interface\transfer_crew.c; line: 229
Using reference variable without initializing
RUNTIME ERROR - file: interface\transfer_crew.c; line: 229
Using reference variable without initializing


The transfer_crew c. file appears to have changed between Beta 4 and Beta 4.1

Error logs attached

Save attached is in the store - having sold off the cargo - about to go to the Shipyard and sell Officers ship - still need to transfer crew to me.


:drunk
 

Attachments

  • error.log
    321 bytes · Views: 109
  • compile.log
    44.3 KB · Views: 104
  • system.log
    11.7 KB · Views: 119
  • -=Player=- Jamaica.7z
    513.1 KB · Views: 101
I’ve noticed this a few times.
Code: 
    if(CheckAttribute(newFriend,"index") && tempnum2==sti(newFriend.index)) continue;//MAXIMUS: companion will not be added
What about this instead?
Code: 
     if (CheckAttribute(newFriend,"index")) {
      if (tempnum2 == sti(newFriend.index)) {
         continue;
       }
     }
Since the attribute clearly doesn’t exist then the second pass will only occur if it does. Right?
 
Last edited:
I think that shouldn't matter. If the first part is 'false', the second part doesn't need to be checked.
 
Yes but that’s just it, if the first bit is indeed false then it will error on the second bit because it is checked. Breaking them into two catches will stop that.
 
Oh I see, so it just stops short. Yeah, the error is still showing anyway so I guess the problem is that newFriend is simply not defined.

Wait, what does that code even do? I’ve commented it for now, the short stutter annoys me and that fixes it.
 
This seems to be only happening the first time around. Once the crew interface has been loaded then it doesn’t happen again until the game is reloaded. That’s a bit odd, ain’t it? Anyway, I have no idea what that code is for, it looks like something which wasn’t implemented. Either way, I’ve replaced newFriend with refEnemyCharacter and the error ceases, and tracing refEnemyCharacter.index is also happily returning my companion’s index even on the first time, so the problem is probably somewhere around here...
Code: 
   if(CheckAttribute(pCharacter,"InterfaceParam.i1")) {
     nMyCharacterCompanionPlace = sti(pCharacter.InterfaceParam.i1);
     nCompanionIndex = GetCompanionIndex(pCharacter,nMyCharacterCompanionPlace);
   }
I don’t know exactly how that nonsense works, I think it’s precisely what causes me problems with my own transfer interface. That’s essentially what I spent two weeks trying to work around. :unsure
 
Last edited:
Didn't I figure out what that was for a few weeks ago when you were looking at that?
It doesn't look very mysterious to me.... :unsure
 
You must log in or register to reply here.
Back
Top