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

Mod Release Build 14 Gamma Version [Last update: 19th September 2024]

@Grey Roger, I checked and double-checked and this seems to be about as good as it gets from my side for now.
If you can, please also include my formatting clean-ups.
I hate ugly code and try to address that whenever I happen to be able to.
 

Attachments

  • PB_Code.7z
    1.6 MB · Views: 49
The old step_sand is so much louder that I'll get problem using the new weaker one.
What about this: I'll rename the old one to step_sand2.wav and do the changes (4 places for me)
 
Jack Rackham said:
The old step_sand is so much louder that I'll get problem using the new weaker one.
Click to expand...
Yes, I found that as well. Walking on sand, I can hardly hear it, even with sound effects turned up to a point where cannonfire in a naval battle would probably annoy my neighbours. Also, the same file is used for the sound when you dig for treasure, and I couldn't hear that at all. Compared to a minor annoyance when walking on sand with time compression, I'd say the loss due to using the new "step_sand" is significantly greater than the improvement. Unless it's made louder - in which case it will probably annoy the time-compressed walkers again - I'd rather not use it.
 
Grey Roger said:
Yes, I found that as well. Walking on sand, I can hardly hear it, even with sound effects turned up to a point where cannonfire in a naval battle would probably annoy my neighbours. Also, the same file is used for the sound when you dig for treasure, and I couldn't hear that at all. Compared to a minor annoyance when walking on sand with time compression, I'd say the loss due to using the new "step_sand" is significantly greater than the improvement. Unless it's made louder - in which case it will probably annoy the time-compressed walkers again - I'd rather not use it.
Click to expand...
It’s strange why you can’t hear it, I increased the volume almost to the standard volume, but a little quieter. In the BNH this sound is heard normally. In the standard mode of the game, for some reason the sounds of sand are not heard at all, even with the old sound, as if they were not there.
 
Pieter Boelen said:
@Grey Roger, I checked and double-checked and this seems to be about as good as it gets from my side for now.
If you can, please also include my formatting clean-ups.
I hate ugly code and try to address that whenever I happen to be able to.
Click to expand...
Not only does that waste space in the file which people download, but you seem to be using a different setting for tabs to me which means some of your "clean-ups" actually make the code look ugly here! Additionally, it's a distraction which is taking time during the WinMerge and which may cause me to miss a real fix. Would you be able to re-upload the collection including only those files which have genuine code changes, please?
 
Pieter Boelen said:
It would indeed have that effect.
I thought that wouldn't do too much harm?
But if not, how about this proposal?
Code: 
void CheckInitialFlagRelations(ref chr, float visibility_range, float ship_range)
{
    // Initialize nations
    int iNation = GetCurrentFlag();
    int nNation = sti(chr.nation);
    float rel = GetRMRelation(GetMainCharacter(), nNation);
    bool IsFort = GetAttribute(chr, "ship.type") == SHIP_FORT_NAME;

    // Initialize relations between NPC ships
    UpdateAllShipsAtSea(chr, IsFort);

    if (IsFort && nNation == PERSONAL_NATION) return; //Do not check me if fort is mine
    if (IsCompanion    (chr)) return; // Companions don't care
    if (CharacterIsDead(chr)) return; // Already dead, don't change relation again

    if (rel <= REL_WAR && iForceDetectionFalseFlag == 1 && ship_range < visibility_range) chr.recognized = 1; // GR: obey forced recognition of false flag
   
    if (iForceDetectionFalseFlag == -1) ResetCharacterMemory(chr); // PB: So any false flag is believed again
Click to expand...
That's not as drastic but it still means that if the fort is temporarily fooled for quest reasons, it will forget about you entirely. Maybe just add another exception similar to those already present:
Code: 
if (iForceDetectionFalseFlag == -1) return;
 
Grey Roger said:
That's not as drastic but it still means that if the fort is temporarily fooled for quest reasons, it will forget about you entirely. Maybe just add another exception similar to those already present:
Code: 
if (iForceDetectionFalseFlag == -1) return;
Click to expand...
Ah yes, I suppose that could work too...

Grey Roger said:
Not only does that waste space in the file which people download, but you seem to be using a different setting for tabs to me which means some of your "clean-ups" actually make the code look ugly here! Additionally, it's a distraction which is taking time during the WinMerge and which may cause me to miss a real fix. Would you be able to re-upload the collection including only those files which have genuine code changes, please?
Click to expand...
I only use the software default settings.
Never changed them...
 
1 tab = 8 spaces. You're presumably using 1 tab = 4 spaces.

I have my own pet peeves, including proper indentation, and having an 'if' block like this:
Code: 
if (condition)
{
        do stuff
}
... rather than...
Code: 
if (condition) {
        do stuff
}
... so that it's easier to scroll down and see where blocks start and end. But although I'll sometimes "correct" them while I'm making a genuine change to the code, I'll not go searching for them just to change them, and I'll certainly not upload any files which have only been changed to satisfy my style preferences. So I'm also not interested in files which have only changed by removing a few spaces.

Talking of genuine changes, I found this added to function 'wdmEvent_PlayerInStorm()' in "PROGRAM\WorldMap\worldmap_events.c":
Code: 
if (CheckAttribute(GetMainCharacter(), "stormIndex")) return; // PW storm immunity otherwise locked in storm
Characters[GetMaincharacterIndex()].stormIndex = stormIndex;//PW set up variable for storm immunity (cleared in daily crew update)
There's no "stormIndex", or any other storm code, in "DailyCrewUpdate.c". Is "stormIndex" something new to Build 15? I'm guessing this function is what yanks you out of worldmap and into direct sailing if you've entered a storm cloud on the worldmap and if "stormIndex" isn't cleared because my version of "DailyCrewUpdate.c" doesn't have it, then the first time a storm kicks you out of worldmap will also be the last.

And I'm still not sure what everything added to "AIShip.c" does. By your own admission, the "Philippe" code caters to an attribute which is only set by a function that is commented out in "Tales of a Sea Hawk" and not used anywhere else at all. So that code may as well also be commented out. And some of your formatting changes were to remove commented out code. If I don't add it, you don't need to delete it later. :D

The code to prevent immortal characters returns 'makefloat(0)', and so does the check for 'bSeaActive'. Why not just return '0.0'? (A few lines down is your own code to prevent damage to an NPC ship hitting land does exactly that.)

Exactly what problems were reported due to this:
Code: 
    if(iRealismMode>0)
    {
        int MinSailCrew = GetCharacterShipHP(rCharacter)/100;    // crew needed for sailing, intentionally not using mininum crew here
        if (MinSailCrew >= 100000/100) MinSailCrew = 100;        // Cursed ships are a special case
        CrewQuantity -= MinSailCrew;
    }
And have you checked to make sure that commenting it out hasn't caused any more problems?

This looks very dodgy:
Code: 
if(CheckAttribute(arCharShip, "Impulse"))
 stf(arCharShip.Impulse.Rotate.y);
Perhaps that should be:
Code: 
if(CheckAttribute(arCharShip, "Impulse")) fRotate = stf(arCharShip.Impulse.Rotate.y);

There's no need to change "AIShip.c" to reduce the mast damage from grapeshot. That's what 'MAST_GRAPE_SCL', defined in "InternalSettings.h", is for. You could change that to 0 if you like.
 
Grey Roger said:
Talking of genuine changes, I found this added to function 'wdmEvent_PlayerInStorm()' in "PROGRAM\WorldMap\worldmap_events.c":
Code: 
if (CheckAttribute(GetMainCharacter(), "stormIndex")) return; // PW storm immunity otherwise locked in storm
Characters[GetMaincharacterIndex()].stormIndex = stormIndex;//PW set up variable for storm immunity (cleared in daily crew update)
There's no "stormIndex", or any other storm code, in "DailyCrewUpdate.c". Is "stormIndex" something new to Build 15? I'm guessing this function is what yanks you out of worldmap and into direct sailing if you've entered a storm cloud on the worldmap and if "stormIndex" isn't cleared because my version of "DailyCrewUpdate.c" doesn't have it, then the first time a storm kicks you out of worldmap will also be the last.
Click to expand...
Just passing by as I said elsewhere and see my name against another issue. That looks like code from my interaction with New Horizons on Maelstrom. It seemed that with that engine I got locked in a storm that persisted and you got sucked back in quicker than you could sail out of it when it passed ad infinitum and the only way I could quickly workround past that was to set that variable/attribute. There was a cancellation in daily crew update in those files to accompany this.



Code: 
    // Fudge Dragon: Changing Face of the Caribbean -->
    if (sti(GetStorylineVar(FindCurrentStoryline(), "CHANGING_RELATIONS")))
    {
        // Sulan: improved code and moved it to nations.c
        RandomNationsRelationsChange();
     }
    // Fudge Dragon: Changing Face of the Caribbean <--

    if (bCompanionMutiny) ShipMutiny(); // KK
    DeleteAttribute(pchar, "stormIndex");// PW end temporary immunity from storm
I've no idea why it would be bleeding back into build14 (and would have thought all you clever chaps moving to new engines would have a proper solution by now anyway).
 
Last edited:
pedrwyth said:
Just passing by as I said elsewhere and see my name against another issue. That looks like code from my interaction with New Horizons on Maelstrom. It seemed that with that engine I got locked in a storm that persisted and you got sucked back in quicker than you could sail out of it when it passed ad infinitum and the only way I could quickly workround past that was to set that variable/attribute. There was a cancellation in daily crew update in those files to accompany this.

Code: 
    // Fudge Dragon: Changing Face of the Caribbean -->
    if (bCompanionMutiny) ShipMutiny(); // KK
    DeleteAttribute(pchar, "stormIndex");// PW end temporary immunity from storm
I've no idea why it would be bleeding back into build14 (and would have thought all you clever chaps moving to new engines would have a proper solution by now anyway).
Click to expand...
Good to see you back aboard, @pedrwyth! :cheers

The new version of "worldmap_events.c" with the code involving "stormIndex" was one of a batch of files uploaded by @Pieter Boelen. But that batch did not include a new version of "DailyCrewUpdate.c" with the line deleting the attribute. I've added it now, which means the new "worldmap_events.c" can go into the next update. If your new code helps Maelstrom work better, and provided it does no harm to "New Horizons" and "Beyond New Horizons", your new code may as well be included.
 
I have already written about the game crush that occurs when merchant ships are accidentally captured by officer.
In tales of hawk
Did someone catch it?
This didn't seem to happen in older builds.
 
I reinstalled the game. Now the unique sword in the cave at Caiman kai is gone, just a hunting sword?
 
The special sword was never in that cave. Try landing at Sand Bluff. You need to go from there, through one jungle location and into another. Then you need to search around until you find the trapdoor to the cave.
The same cave is sometimes used for a treasure quest:
Lost Treasure on Cayman (Sand Bluff)

But if that treasure quest is active, you will not find the sword. Treasure quests temporarily clear all items from their locations. So if you have a treasure quest to Sand Bluff, you'll first need to find the trapdoor; find the hidden chest, which may be empty; exit to the place with the house; then return to the jungle and find the trapdoor again.
 
Grey Roger said:
The special sword was never in that cave. Try landing at Sand Bluff. You need to go from there, through one jungle location and into another. Then you need to search around until you find the trapdoor to the cave.
The same cave is sometimes used for a treasure quest:
Lost Treasure on Cayman (Sand Bluff)

But if that treasure quest is active, you will not find the sword. Treasure quests temporarily clear all items from their locations. So if you have a treasure quest to Sand Bluff, you'll first need to find the trapdoor; find the hidden chest, which may be empty; exit to the place with the house; then return to the jungle and find the trapdoor again.
Click to expand...
Ah! :facepalm:pirate07:
 
But the cave at cayman kai is also used to a treasure quest, if the quest is inactive there used to be a blade 32.
 
When was that? I'm looking at the files from the ancient Beta 3, dating back to 2013, and even there the cave near Cayman Kai has the hunting sword, "blade36". The one at Sand Bluff had the shellcup falchion, "bladeC18", before I replaced it with the unique "Sword of the Earth" ("blade308").

"Blade32" is the Damascus shamshir, which you'll earn by getting a Portuguese LoM (or starting a FreePlay as a Portuguese naval officer) and being promoted up to rank 8.
 
Im always updated. The last couple of months I have had Blade 32 in the Caiman Kai cave. Maybe I made a mess in the internalsettings, so I will forget about the problem. Then I installed Chrome,a lot of strange things happened, has anybody experienced that?
 
You must log in or register to reply here.
Back
Top