• 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!

water boarding

Thanks Pieter for that information on what came from where, that makes my guesswork a lot easier. <img src="style_emoticons/<#EMO_DIR#>/par-ty.gif" style="vertical-align:middle" emoid=":cheers" border="0" alt="par-ty.gif" />

Bugs being annoying notwithstanding, I like these conversations where what actually makes the game work is discussed. I think they contribute a lot to the general pool of knowledge about the game, and are actually helpful to people when they are attempting their own modifications. <img src="style_emoticons/<#EMO_DIR#>/modding.gif" style="vertical-align:middle" emoid=":modding" border="0" alt="modding.gif" />

This would be a good time to express thanks to Hook, and all the other bugfixers who have been trying to get the Prebuild 13 version of the game back on an even keel, it can apparently seem a somewhat thankless job, but be assured the time you guys devote to doing this is greatly appreciated.

<img src="style_emoticons/<#EMO_DIR#>/wavarr.gif" style="vertical-align:middle" emoid=":warr" border="0" alt="wavarr.gif" />


I've been doing a comparison of the LAi_boarding.c files from Build 12.1 and the Post-Build 12 versions of the file, but I'll download a copy of the most recent updates and see how that file stacks up with them. Who knows, one letter out of place may be causing the whole problem. <img src="style_emoticons/<#EMO_DIR#>/dunno.gif" style="vertical-align:middle" emoid=":shrug" border="0" alt="dunno.gif" />
 
Thanks for looking into this as well, Sir Christopher Mings! The more people working on figuring out fixes for bugs, the better it is! <img src="style_emoticons/<#EMO_DIR#>/doff.gif" style="vertical-align:middle" emoid=":doff" border="0" alt="doff.gif" />
 
COUCH COUCH it still was my idea for side stepping <img src="style_emoticons/<#EMO_DIR#>/ohmy.gif" style="vertical-align:middle" emoid=":eek:" border="0" alt="ohmy.gif" /> <img src="style_emoticons/<#EMO_DIR#>/pirate2.gif" style="vertical-align:middle" emoid=":p:" border="0" alt="pirate2.gif" />
 
You said it is caused by the sidestepping. That isn't the case. It can be "solved" by sidestepping though, because when you sidestep, you will be positioned back on the deck. I discovered that quite a long time ago; several months, I think. Anyway: Does it really matter who suggested it? It works. <img src="style_emoticons/<#EMO_DIR#>/icon_mrgreen1.gif" style="vertical-align:middle" emoid=":cheeky" border="0" alt="icon_mrgreen1.gif" />
 
Captain Yuke,
I think you're looking for, "COUGH COUGH", because what you're telling us is, "SOFA SOFA". <img src="style_emoticons/<#EMO_DIR#>/rolleyes.gif" style="vertical-align:middle" emoid=":rolleyes:" border="0" alt="rolleyes.gif" />

Speaking of looking.... <img src="style_emoticons/<#EMO_DIR#>/treas1.gif" style="vertical-align:middle" emoid=":treas" border="0" alt="treas1.gif" />

Looking at a PreBuild 13 version of the LAi_boarding.c file gives us a new command used for boardings:
(the arrows, <------------, are just notations I made)
/////////////////////////////////////////////////////////////////////////////////////////////////////////////

// added by MAXIMUS [abordage MOD] -->
string LoadedCabin, locType;

Switch(shipcab)
{
case 1: LoadedCabin = "Boarding_Cabin1"; break;
case 2: LoadedCabin = "Boarding_Cabin_medium"; break;
case 3: LoadedCabin = "Boarding_Cabin_small"; break;
case 4: LoadedCabin = "Boarding_Cabin3"; break; <-----------------Boarding_Cabin3? Orig game? Camp_deck?
case 5: LoadedCabin = "Boarding_Cabin2"; break;
}

mchr.location = locationID;
if(locationID==LoadedCabin)
{
mchr.location.group = "reload";
mchr.location.locator = "reload1"; <------------------- This is new!
}
else
{
mchr.location.group = "rld";
locType = strcut(locationID, 0, 3);
if(locType=="NEXT")
{
if(boarding_location_type == BRDLT_FORT) mchr.location.locator = "loc0";
else mchr.location.locator = "aloc0";
}
else
{
if(boarding_location_type == BRDLT_FORT) mchr.location.locator = "loc0";
else mchr.location.locator = "captain";
}
}
/////////////////////////////////////////////////////////////////////////////////////////////////////////////////

If I'm reading this correctly, and the new command is reload1, I may have found the problem:
in the cabin02_locators.gm file there is a reload 1 (there are actually three of them, but two are used for cameras,) and a single locator labeled reload10, and this, I think, is the culprit.

The locator, reload10, located all by itself under the plane of the file and approximately around 0' 0' 0', is making me think that, given the choice between reload1 and reload10, it chooses the latter, disregarding the "0". This tends to jibe with the information we got from Pieter, and what people have reported seeing.

What I plan to do is take out the reload 10 locator for this file, using the TOOL, and put a copy of the edited file onto the FTP. If someone could, 1. make a back up copy of their cabin02_locators file, 2. take the copy that I put on the FTP and put it in their game to test it, 3. let us know if it works or not, we may have ironed out this bug. <img src="style_emoticons/<#EMO_DIR#>/danse1.gif" style="vertical-align:middle" emoid=":dance" border="0" alt="danse1.gif" />

I'm not certain this will solve the problem, for one thing I don't understand why "BRDLT_FORT" is used as opposed to "BRDLT_SHIP" in the lines above. Also, there isn't a reload 10 locator in Cabin01_locators.gm, but from what I've read that cabin might not work either. I'll get the file on the FTP tomorrow.

Thanks Pieter, I'm having some fun with this bug, but I can imagine it getting old pretty fast for you guys who have fixed so many previous bugs. <img src="style_emoticons/<#EMO_DIR#>/doff.gif" style="vertical-align:middle" emoid=":doff" border="0" alt="doff.gif" />
 
I've already got the problem fixed in the new boarding code. It's really nothing to do with what you suggested.

That final line that sets locator to "captain" should only be executed on the top deck of the ship. But because of other errors involving incorrectly set shipcab and boardingcabin variables, you can end up at that part of the code when you're actually in the cabin.

Forts should set loc0. Top decks should set "captain." The boarding cabin should set aloc0. The reload1 works just fine. I'd suggest not messing with it.

Hook
 
Here's my current code, which works. It may or may not work for you depending on if the Surrendered variable is set properly elsewhere in the code.

<!--c1--><div class='codetop'>CODE</div><div class='codemain'><!--ec1-->
// added by MAXIMUS [abordage MOD] -->

mchr.location = locationID;
if (HasSubStr(locationID,"Boarding_Cabin")  &&  Surrendered)
{
    mchr.location.group = "reload";
    mchr.location.locator = "reload1";
}
else
{
    mchr.location.group = "rld";
    if (HasSubStr(locationID,"NEXT") || HasSubStr(locationID,"Boarding_Cabin"))
    {
        mchr.location.locator = "aloc0";
    }
    else
    {
        if (boarding_location_type == BRDLT_FORT)
        {
            mchr.location.locator = "loc0";
        }
        else
        {
            mchr.location.locator = "captain";        
            // LDH - only top decks of ships (udeck, udeck1, udeck2) have "captain" locator
        }
    }
}
<!--c2--></div><!--ec2-->

There are no changes needed to the .gm files.

Hook
 
Do you have a file with the fixed code available somewhere? That's easier for me to put in.
 
Here's the code you posted with some changes to make it more readable and to fix the problem with ending up in the water:

<!--c1--><div class='codetop'>CODE</div><div class='codemain'><!--ec1-->
// added by MAXIMUS [abordage MOD] -->

mchr.location = locationID;
if (HasSubStr(locationID,"Boarding_Cabin"))
{
    mchr.location.group = "reload";
    mchr.location.locator = "reload1";    // Set up for boarding cabin dialog
}
else
{
    mchr.location.group = "rld";
    if (boarding_location_type == BRDLT_FORT)
    {
        mchr.location.locator = "loc0";         // Set up for fort
    }
    else
    {
        if (HasSubStr(locationID,"NEXT"))
        {
            mchr.location.locator = "aloc0";    // Set up for fight on next deck
        }
        else
        {
            mchr.location.locator = "captain";  // Set up for fight on top deck of ship
        }
    }
}
<!--c2--></div><!--ec2-->

The problem is still that LoadedCabin is not correct, so the game ends up putting you at the "captain' locator because it thinks you're on the top deck of the ship. I've fixed that in this code. You will not be able to fight in the cabin with this code, but it will work even if the Surrendered variable is incorrect.

If you're fighting in a fort, you will always go to loc0, which is different from the June 28 code I'm working from. I have no idea if this is the intended behavior.

Hook
 
Well that's great, a solution has been found! <img src="style_emoticons/<#EMO_DIR#>/par-ty.gif" style="vertical-align:middle" emoid=":cheers" border="0" alt="par-ty.gif" />

This notwithstanding, I put on the FTP the edited cabin02_locators.gm, in a file marked Replacement Deck Locator File.

It is available for anyone with a current PreBuild 13 version of the game who wants to test if replacing this file has any effect on the boarding problem. Might be a fun experiment to try while Pieter makes Hook's fix available thru the download.

The only edit I made was to change the label for that odd locator "reload 10", to "reload 0", and I'd be interested in finding out if that has the desired effect of directing the main character to the correct location.
If anyone does try this, again, first make a back up copy of your original file, and put a copy of the new file here:

Pirates of the Caribbean\RESOURCE\MODELS\Locations\DECKS\TUT_DECK
 
You must log in or register to reply here.
Back
Top