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

WIP Unique Ship/Captain Encounters

I totally understand that, sometimes I even have a hard time keeping track of my own changes. That’s why I started to tag everything I do change, it should avoid wondering why there’s a problem and where it is. I like the idea of things being optional, as you do, and that’s where I try very hard to a) keep things as simple as possible while b) allowing some way to enable and disable a feature at a whim.

In this case, the overall control is with the CanEncounter variable so if the UNIQUE_ENCOUNTERS global define is set to false then it would work exactly as it did before - things only change if it is set to true. So if it is true then any ship with the define can be spawned in the normal fashion, and currently I only have about 4 ships which have been enabled in this way (the rest of the unique ones are false anyway and therefore cannot be spawned at all).

It’s way too early anyway to say this is stable, in some areas I’m still improvising until code is properly in place, but it’s worth keeping in mind that because I am able to prevent a ship from being regenerated once it has been sunk then I obviously do have some decent control over them. I guess it would probably be a simple task to use that same logic to prevent them being spawned at all on a per-ship basis, by flagging the ship (or indeed all of them) as sunk in the first place.

The one thing I like about the random encounters is that they are precisely that, random. Grabbing a rumour or side-quest is not entirely random - yes, the resulting quest might be but the player has to actually go looking for this specific thing rather than happening upon it by sheer chance. I quite like the idea of the chance increasing as time goes by, particularly if reputation is relevant, for these ‘orrible scurvies to start causing the player some problems - if they are only available by side-quests then the player can completely avoid ever meeting them.

Personally, I like the idea of both. So likewise, if the player is a pirate then they could be unfortunate enough to run into HMS Victory, but they might also find a quest in piratey place to go sink (or even capture) her.
 
I totally understand that, sometimes I even have a hard time keeping track of my own changes. That’s why I started to tag everything I do change, it should avoid wondering why there’s a problem and where it is. I like the idea of things being optional, as you do, and that’s where I try very hard to a) keep things as simple as possible while b) allowing some way to enable and disable a feature at a whim.
Much appreciated! :cheers

In this case, the overall control is with the CanEncounter variable so if the UNIQUE_ENCOUNTERS global define is set to false then it would work exactly as it did before - things only change if it is set to true. So if it is true then any ship with the define can be spawned in the normal fashion, and currently I only have about 4 ships which have been enabled in this way (the rest of the unique ones are false anyway and therefore cannot be spawned at all).
Definitely sounds good.
I'm still wondering how to handle very specific requirements on them being disabled, such as storyline-specific or to avoid a player clone from being encountered.

It’s way too early anyway to say this is stable, in some areas I’m still improvising until code is properly in place, but it’s worth keeping in mind that because I am able to prevent a ship from being regenerated once it has been sunk then I obviously do have some decent control over them. I guess it would probably be a simple task to use that same logic to prevent them being spawned at all on a per-ship basis, by flagging the ship (or indeed all of them) as sunk in the first place.
Indeed that should probably work out fine. :onya

The one thing I like about the random encounters is that they are precisely that, random. Grabbing a rumour or side-quest is not entirely random - yes, the resulting quest might be but the player has to actually go looking for this specific thing rather than happening upon it by sheer chance. I quite like the idea of the chance increasing as time goes by, particularly if reputation is relevant, for these ‘orrible scurvies to start causing the player some problems - if they are only available by side-quests then the player can completely avoid ever meeting them.
My idea was to randomly call the "encounter quest" as part of the daily updates. So it would not need to be deliberately started by the player.
What happens after that should be completely customizable. The ship can be randomly chosen and placed at a random locator of a random island.
If that is not posted to the Tavern News either, then for all intents and purposes, those encounters appear completely random.

I do think adding less random components could add extra gameplay potential, though.
For example, the HMS Victory showing in the Tavern News so that low level players hostile to England know to avoid a certain island for a while.
Or a Treasure Fleet showing in the Tavern News so players could deliberately seek them out.
Maybe even a competing pirate who follows the player around and always gets generated at the same island as the player one day later.
This same system might even be used to send hostile fleets to player-controlled towns so that the player then has 1 month to go there and take care of it.
The options are limitless, ranging from completely random to not random at all.

The main thing is that this method would work to place encounters at specific islands, but not create random ones on worldmap and DirectSail.
 
Right now I’ve been focusing on the world map encounters. When I looked at the governor dialogue it worked really well, but I just overwritten the existing “kill pirate” quest so I had to revert it back to normal - I would need to create a completely new dialogue for that, and the same goes for dialogue in the tavern.

So yeah, for the time being I’m looking at generic encounters and I do want to do it so that it is disabled by default and can be enabled with the quick flip of a few settings. First of all, the main setting would be #define UNIQUE_ENCOUNTERS which would probably be in InternalSettings.h, and this would be “0” by default.

In a nutshell, on game creation one of three things happens: all relevant unique ships are either enabled or disabled by default, or they can be set on a per-case basis. This can then be changed after a game has started, meaning no reinitialisation would be necessary because it would be looking at an attribute set on the main character. This means that a given story mode would not need to disable them, rather they would have to enable them if that is the intention - I think that would be more compatible. I expect this would also be completely independent of forced encounters via dialogue.

Okay, so this is what I currently have in place for the ships (captains are irrelevant here)...

This is my basic, temporary version of setting the attribute...
Code:
if (UNIQUE_ENCOUNTERS == true) {
   if (CheckAttribute(rShip,"Unique")) {
      if (rShip.CanEncounter == true) {
         if (!CheckAttribute(MainChar,"UniqueShips."+(sShip))) {
            MainChar.UniqueShips.(sShip).enabled = true
         }
      }
   }
}
This example explicitly enables a given ship. If the global define is false then that attribute is never set by the code itself, and therefore the ships would never be spawned. However, the attribute could be forced at the console.

Then there’s the encounter logic...
Code:
[SEA_AI\AIFantom.c]

/* [UNIQUE] Unique Ships and Characters - by Mere Mortal */
// <!-- START
if (GetAttribute(rShip,"unique") > 0)) {
    ref    MainChar  = GetMainCharacter()
    string sShip     = rShip.ID
    bool   isEnabled = false
    // Check if the unique ship is enabled or not for encounters...
    if (CheckAttribute(MainChar,"UniqueShips."+sShip+".enabled")) {
        isEnabled = MainChar.UniqueShips.(sShip).enabled
    }
    if (!isEnabled) {
        continue
    }
    // Check if the ship has already been generated...
    if (GetAttribute(rShip,"exists") > 0) {
        // If so, then check the character...
        if (CheckAttribute(rShip,"curChar")) {
            ref rChar = CharacterFromID(rShip.curChar)
            // If he's dead, well then he stays dead...
            if (CheckAttribute(rChar,"killer")) {
               continue
            }
            else { // Otherwise respawn the ship...
                DeleteAttribute(rShip,"curChar")
                rShip.exists = false
            }
        }
        if (rShip.exists == true) {
            continue
        }
        rShip.exists = true
    }
}
// END -->
I need to move curChar off the ship and onto the main character where enabled has been set, but it would have the same effect anyway.
 
Last edited:
I would need to create a completely new dialogue for that, and the same goes for dialogue in the tavern.
It should not be necessary for there to be actual dialog.
The encounters can be started randomly and the Tavern News isn't dialog-based either.

So yeah, for the time being I’m looking at generic encounters and I do want to do it so that it is disabled by default and can be enabled with the quick flip of a few settings. First of all, the main setting would be #define UNIQUE_ENCOUNTERS which would probably be in InternalSettings.h, and this would be “0” by default. This means that a given story mode would not need to disable them, rather they would have to enable them if that is the intention - I think that would be more compatible. I expect this whould also be completely independent of forced encounters via dialogue.
You could use a storyline variable instead so your mod is enabled by default in the Free Play one and disabled in the others. :doff
 
Sorry, that second bit you quoted... the second paragraph was copy-pasted wrong. I moved that down for clarity just as you posted...
In a nutshell, on game creation one of three things happens: all relevant unique ships are either enabled or disabled by default, or they can be set on a per-case basis. This can then be changed after a game has started, meaning no reinitialisation would be necessary because it would be looking at an attribute set on the main character. This means that a given story mode would not need to disable them, rather they would have to enable them if that is the intention - I think that would be more compatible. I expect this would also be completely independent of forced encounters via dialogue.
You could use a storyline variable instead so your mod is enabled by default in the Free Play one and disabled in the others.
That’s what I mean, the ships would be disabled by default meaning free-play mode would have to explicitly enable them. It would save any unexpected incompatibilities by instead placing the responsibility of enabling them onto those dealing with the individual story modes, with the only mode I personally need to be concerned about being free-play.

It should also check which ship the player has and if it’s one of them then it is skipped - so if the player has the Black Pearl then it can never be encountered, but maybe Barbossa could be encountered in another ship. Likewise, if the player actually is Barbossa but not using the Black Pearl, then the ship can be encountered but not the character.
The encounters can be started randomly and the Tavern News isn't dialog-based either.
Oh, okay. So just looking at the tavern news would in theory create an encounter at a given location?
 
That’s what I mean, the ships would be disabled by default meaning free-play mode would have to explicitly enable them. It would save any unexpected incompatibilities by instead placing the responsibility of enabling them onto those dealing with the individual story modes, with the only mode I personally need to be concerned about being free-play.
What I mean is to not use a #define, but have it automatically on in Free Play and off in the others similar to the Changing Nations Relations mod.

Oh, okay. So just looking at the tavern news would in theory create an encounter at a given location?
The other way around: The encounters would be automatically generated at midnight for a certain location without player action.
This could be random at first and possibly some underlying logic can be added later.

Them being announced in the Tavern News is optional, but easily added.
That would be independent from the actual generation and is purely "information only".
 
What I mean is to not use a #define, but have it automatically on in Free Play and off in the others similar to the Changing Nations Relations mod.
Whereas I'd prefer a global define in "InternalSettings.h" so that I can disable it entirely along with the other customisations which I make, rather than having to search another file to disable it if I never want to see the cursed ships during whichever storyline I'm playing, including Free Play.
 
Whereas I'd prefer a global define in "InternalSettings.h" so that I can disable it entirely along with the other customisations which I make, rather than having to search another file to disable it if I never want to see the cursed ships during whichever storyline I'm playing, including Free Play.
A #define that is off by default means most players will never know the feature exists. In other words: A waste of perfectly good time and effort.
It is easy enough to disable Changing Nation Relations in Free Play and my suggestion to @Mere_Mortal is to use the same method for the time being.

I think you may also be missing the point of this feature; the idea is NOT to force cursed ship encounters onto everyone at all times.
Until cursed ships appear ONLY where they belong (e.g. Free Play storyline in the Colonial Powers period, possibly only when selecting a PotC film character), this feature isn't yet ready for a public release.

There will of course be a transition period where it isn't yet ready for release. But that is acceptable.
Once this is handled properly, there should really be no need for a global setting to disable it all.
 
I'd prefer a global define in "InternalSettings.h" so that I can disable it entirely along with the other customisations which I make, rather than having to search another file to disable it if I never want to see the cursed ships during whichever storyline I'm playing, including Free Play.
I agree with this. As to what is originally active and what is not when it comes customisable content is a matter for discussion or even veto, but at least if the define is there then it can easily be changed by the player. I’m not particularly concerned though, I quite like the idea of running into a ship full of skeletons but that is of course my own personal preference.

I think the companion limit is currently a very good example of how this works. While it is largely untested by anybody other than myself, and although there are no stable supporting interfaces for it, the player may now capture as many ships as they care to because the global variable is working as it was originally intended. In this case, there is little point in enabling it by default at the moment but the option is there for people.
A #define that is off by default means most players will never know the feature exists.
Thinking about it, maybe it would be worthwhile pointing out in the release notes that the companion limit may now be increased.
 
I agree with this. As to what is originally active and what is not when it comes customisable content is a matter for discussion or even veto, but at least if the define is there then it can easily be changed by the player. I’m not particularly concerned though, I quite like the idea of running into a ship full of skeletons but that is of course my own personal preference.
Indeed while it is in development, a simple toggle could be in place. Could be put at the bottom of globals.c together with some other toggles on WIP (and abandoned) features.
It is only for the public release version where I'd like it to be so good that we don't really need the toggle any longer.

I think the companion limit is currently a very good example of how this works. While it is largely untested by anybody other than myself, and although there are no stable supporting interfaces for it, the player may now capture as many ships as they care to because the global variable is working as it was originally intended. In this case, there is little point in enabling it by default at the moment but the option is there for people.
True point.

Thinking about it, maybe it would be worthwhile pointing out in the release notes that the companion limit may now be increased.
It does currently mention this:
Variables added for additional companions, officers and skill points by Mere Mortal
I don't think many people actually take any note of the release notes, but I do agree it could be phrased more clearly.
 
Variables added for additional companions, officers and skill points by Mere Mortal
Ah yeah, I forgot about that. It works for the other two because increasing the officers would be incredibly buggy and the skill points variables are messed up as well, so I don’t think they particularly need explaining. The companion increase is different, I reckon it’s actually very stable in its own right and is just a matter of having workable interfaces.
 
If I remember correctly from another discussion, how much XP you get from fencing depends on how many shore party officers you have. If this is so, will XP go ballistic if you have more than the normal 3 officers with you? For that matter, does shared XP in general work with the new variable maximum number of officers?

Where is the maximum number of shore party officers defined? Because "Ardent" sometimes needs to search through all your officers, and at present assumes that there will be at most 3. I may as well have it take note of the actual maximum and cycle through all possible officers rather than the default 3.
 
If I remember correctly from another discussion, how much XP you get from fencing depends on how many shore party officers you have. If this is so, will XP go ballistic if you have more than the normal 3 officers with you? For that matter, does shared XP in general work with the new variable maximum number of officers?
It cycles through all passengers for the relevant captain, so it should do.
And IsOfficer checks the OFFICER_MAX setting now.

Lots of officers would mean lots of officers will be getting XP.
Not something to be concerned about just yet though; I don't foresee the default number of 4 officers will be changing any time soon.

As @Mere_Mortal says, more companions should be OK. But officers not so much.
I also don't see any gameplay value to having more than 4.
Mainly the use of a general variable for it makes it clear what different loops actually belong to.
Certainly makes the code cleaner and more robust, even if the number would never be changed.

Where is the maximum number of shore party officers defined? Because "Ardent" sometimes needs to search through all your officers, and at present assumes that there will be at most 3. I may as well have it take note of the actual maximum and cycle through all possible officers rather than the default 3.
Here in PROGRAM\Characters\characters.h:
Code:
#define PASSENGERS_MAX       32
#define OFFICER_MAX         4
#define COMPANION_MAX       4
#define MAX_CHARACTER_SKILL     10
 
@Mere_Mortal: If you're interested in my suggestion for an "alternate approach" for this, have a look at post #73.
If you want, the island ID can also be determined randomly based on all islands available.

I would imagine the following:
1. Specific captains to be defined in the character init files
2. New object to be defined with unique encounter initialization (here multiple captains can be added to the same encounter or encounters can be limited)
3. Midnight update has a random chance to trigger such an encounter (single function call)
4. When that function is called, a random encounter is chosen from the object defined under #2
5. Optionally, this encounter could be announced in the Tavern News
6. After a while, the encounter should be removed again or moved to another island

In its simplest form, this would choose a random encounter and place it at random islands.
Depending on preference, those encounters may or may not be communicated to the player in advance.

Later it could be made more fancy with:
- Treasure Fleets that will be on specific dates at specific ports (Cartagena>Havana>San Juan)
- Rival pirates that deliberately show up at islands where the player is
- Enemy fleets that show up at islands belonging to the player
 
Here in PROGRAM\Characters\characters.h:
Code:
#define PASSENGERS_MAX       32
#define OFFICER_MAX         4
#define COMPANION_MAX       4
#define MAX_CHARACTER_SKILL     10
Thanks! I'll use that in a more efficient version of the "Get_Speaker" function defined at the end of "quests_reaction.c" for a start.
 
I do want to look at the alternative method, and I think the current set-up I have for regular encounters is pretty much good enough now to move on a bit (the only issue then is about how often, and during which periods, they should spawn if allowed to at all). I’m a bit tired now though, so that’s for tomorrow.

@Grey Roger - Nothing has changed with the officers, the existing code and disciplines should be exactly the same as before, it’s just that a variable has been set pretty much wherever GetOfficerIndex is being used. That global define can be increased by all means so you could quite possibly go to the tavern and hire more officers than you would normally be able to, but no guarantees that everything will work properly! Just bear in mind that in some places there might have been an “if (number_of_officers == 3)” but it could now be “OFFICER_MAX-1”.
 
Last edited:
This is mainly to give people an easy way to be up-to-date with the latest updates. For the most part, it includes just fixes.
Extra debug text is removed again with these files.

Download:
Build 14 Beta 4.1 WIP Part 1: Installation Wizard (Updated: 22 May 2016)
Installation: Proper installer file, use in combination with the Build 14 Beta 4.0 Part 2: Contents Archive file (Updated: 31 March 2016)
Compatibility: Works with Beta 4.0 savegames
Press F11 to reinitialize to ensure all updates take effect!


Change Log:
Code:
Build 14 Beta 4.1:
- New Features:
  . Receive a free soldier outfit after dealing with Soldier Reinforcements by Grey Roger
  . Storage chest added to the personal cabin on Cozumel by Jack Rackham
- Code Updates:
  . Limited number of soldiers in Merchant Guild attacks by Pieter Boelen
  . Reduced number of soldiers in Soldier Reinforcements by Pieter Boelen
  . Reduced strength for town guards by Pieter Boelen
  . Allow swapping ships as Naval Officer after reaching rank 7 by Pieter Boelen
  . Character transfer disabled between two companion ships by Pedrwyth
  . Removed cap to fencing XP for high-level opponents by Pieter Boelen
  . Allowed more variety in destinations for Cargo Quests by Pieter Boelen
  . Reduced cargo capacity for Gunboat by Pieter Boelen
  . Variables added for additional companions, officers and skill points by Mere Mortal
  . Rebalanced ship upgrade prices by Mere Mortal
  . Ship and fort memory takes into account player ship type by Grey Roger
  . Ship Speed and Turn Rate added to Ransack Interface by Mere Mortal
  . Keyboard controls for Save/Load Interface improved by Mere Mortal
  . Pirates are more forgiving of actions against them if you're a Pirate by Pieter Boelen
  . Opium Smuggling "Buyers List" code improved by Mere Mortal and Pieter Boelen
  . Characters in non-existent locations removed by Pieter Boelen
  . Various characters set as "quest characters" by Pieter Boelen
  . Ransack/Transfer Main Interface error fixed by Pieter Boelen
  . Transfer Crew Interface error fixed by Pieter Boelen
  . Quiver, Curare and Tar always enabled in the game by Pieter Boelen
  . Ship Deck Texture code cleaned up and simplified by Pieter Boelen
  . Error checking code added to GetPrettyLocationName function by Pieter Boelen
- Bug Fixes:
  . Fix to prevent Merchant Guild attack when player group was not responsible by Pieter Boelen
  . Fix to allow larger Random Quest Ships by Pieter Boelen
  . Any town capture resets the memory for its fort by Pieter Boelen
  . Fix to ensure any passengers are not erased by Pieter Boelen
  . Fix to ensure best smuggling time matches between dialog and questbook by Pieter Boelen
  . Correction for Shipyard "Cannot Buy" text with Shipyard Ship Availability set to "Stock PotC" by Pieter Boelen
  . Crew transfer between companion ships re-enabled by Pedrwyth
  . Officer dialog restored after sending Smuggling Scout by Pieter Boelen
  . Looting of Blade Muskets fixed by Jack Rackham
  . Stuck while reloading during anchoring fix by Pedrwyth
  . Prevent ship stats of zero for Personal Design ships by Pieter Boelen
  . Fixed ship deck for Naval Ketch by Pieter Boelen
  . Hull upgrade increases maximum cannon calibre by Mere Mortal
  . HP Bonus code fixed and cleaned up by Pieter Boelen
  . Opium Smuggling Fast Travel effect fixed and simplified by Pieter Boelen
  . Hireable officers will not be on the random Opium List by Pieter Boelen
  . Using opium takes away only one item instead of two by Pieter Boelen
  . Attempted fix for Boarding Looting Crashes by Mere Mortal (adapted by Pieter Boelen)
  . Fetch Quest amounts fixed by Pieter Boelen
  . Apothecary Fetch Quest Ship's Log entry added by Talisman
  . Opium Smuggling Quest timer and quest closing fixed by Talisman
  . Ship calibre in Shipyard fixed by Mere Mortal
  . Martinique "No Save" monk appearance fixed by Pieter Boelen
  . Potential CharacterFromID error fixed by Mere Mortal
  . Potential crash from Companion as Fort Commander fixed by Pieter Boelen
- Storyline Updates:
  . Sidequests:
  > First Contact HP after being shot fixed by Pieter Boelen
  > First Contact ship deck code fixed by Pieter Boelen
  . Assassin storyline:
  > Hitman quest ending restored by Pieter Boelen
  > Isla Mona attempted fix by Bartolomeu o Portugues
  . Free Play storyline:
  > Tiny boat ship stats affected only for Castaway (instead of Swashbuckler difficulty) by Pieter Boelen
  > Jean Lafitte gets Opium at game start, other smugglers don't by Pieter Boelen
  . Hornblower storyline:
  > Lieutenant Bush custom model added by Grey Roger
  > Various fixes by Grey Roger
  . Jack Sparrow storyline:
  > First Contact bugs fixed by Pieter Boelen
  . Woodes Rogers storyline:
  > New WIP content added by Jack Rackham
- Model and Texture Updates:
  . HMS Interceptor improved texture by Legendary Spider
  . Elizabeth Swann pirate outfit added by Grey Roger
  . Milady de Winter custom character skin added by Grey Roger
  . Lucia and Edmundo de la Vega custom character skins added by Grey Roger

Pieter,
I Have a cool idea for a next update:
A cursed ship on the map with skeletons as enemys.

You all know potco(pirates online), but it was closed(but there is a remake now named tlopo(the legend of pirates online)).
On the world there are sometimes cursed ships with skeletons that are minions of jolly roger and it is really cool if you can make some(more) cursed ship and if ya board them that you are really on a cursed ship and not a regular like the flying dutchman. And if ya be on the map ya can battle some cursed ships(if ya find it)
And it is a cool challenge for the communition:pflag
 
You already mentioned that idea of yours last week and I already responded then.

We have absolutely no shortage of ideas. What is far more important than ideas is ways to actually make them a reality.
 
You already mentioned that idea of yours last week and I already responded then.

We have absolutely no shortage of ideas. What is far more important than ideas is ways to actually make them a reality.

I thought so 2 but i didn't find my reply anymore so I give a new one and what was your answer?
 
Back
Top