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

What is required to rule a town?

Will do.

I know, you people work hard to upgrade the game (I just haven't been around enough to make a list of all the new things, I like, and only show up, when I run into problems), and it's no surprise, when an upgrade messes with a prior modification.

Grey Roger said:
"Elizabeth Shaw's Disappearance" and "Angelique Moulin's Father" should not affect the main story. "Tales of a Sea Hawk" is the story from the original game, which had never heard of Hispaniola or St. Martin. (It hadn't heard of Jamaica or Barbados either - the original game called them Redmond and Oxbay, and the game code still does.)
Click to expand...

I know, I originally played the stock version. Then I found this site and its upgrades and have been playing both build 12, 13 and the earlier 14.
I just thought, that conquest of the town and possibly replacing the governor and the fort commander would affect those quests.

Grey Roger said:
Opium should not have any effect; it might have done when opium smuggling was active, if the soldiers had been messed up by the smuggling, but they should not react to it now.
Click to expand...

I think, it's the removal of the ability to quick travel, that is causing it.
 
Quick travel was disabled by the opium smuggling quest. But that is itself disabled, so carrying opium should not affect fast travel. One or two sidequests may disable it, though they should not disable it for long.

Try loading a savegame from before you attacked a fort. Get rid of your opium by any means necessary - dump it in a chest, give it to an officer who will not be joining you in the battle, or as a last resort, snort the stuff. Then attack the fort. If the game crashes consistently when you're carrying opium and consistently does not crash when you're not carrying it, that puts the suspicion firmly on the opium, in which case opium will need to be eliminated from the game entirely. If the game crashes regardless of whether you're carrying opium then the cause is something else.

Conquering a town may indeed cause those quests to look odd. If you captured Cayman for France, it's going to look funny when the governor still sends you to look for his daughter at the British naval base on Antigua. Conversely, if you conquered Port au Prince for Britain, Antoine Chamfort is going to stick out as the only man in French uniform in what is now a British fort. There are probably other sidequests which will look odd if you've been conquering the Caribbean.
 
Grey Roger said:
Quick travel was disabled by the opium smuggling quest. But that is itself disabled, so carrying opium should not affect fast travel. One or two sidequests may disable it, though they should not disable it for long.
Click to expand...

Strange, it did for me.

Grey Roger said:
Try loading a savegame from before you attacked a fort. Get rid of your opium by any means necessary - dump it in a chest, give it to an officer who will not be joining you in the battle, or as a last resort, snort the stuff. Then attack the fort. If the game crashes consistently when you're carrying opium and consistently does not crash when you're not carrying it, that puts the suspicion firmly on the opium, in which case opium will need to be eliminated from the game entirely. If the game crashes regardless of whether you're carrying opium then the cause is something else.
Click to expand...

I have reverted to an earlier save from before the opium, then I'll let you know, if conquest of Port au Prince crashes again. It happened both the times, I managed to destroy the fort and invade it with opium in my possession.
 
Here are the crash from my latest attempt to conquer Port au Prince. No selected crewmembers, no officers, no opium. Also no error log. But system and compile log plus my latest save.
 

Attachments

  • crash during conquest of Port au Prince.zip
    1.6 MB · Views: 129
Looking at that "compile.log", there are two signs that something is seriously wrong. One is a lot of these:
Code: 
WARNING!!! Item id = -1 not implemented
The other is a lot of these:
Code: 
Quest name chair_45_check FOUND in SideQuestComplete
I've no idea which item it's complaining about, but "chair_45_check" is part of the "Mysterious Plants" sidequest. I'd advise bringing that to a conclusion before you try any more fort assaults.
 
If the Ammo or Weapon mods were disabled at the start of the game and then enabled later, that would do it, yes.

But the last line in "compile.log" before the crash was one of those about "chair_45_check". And "system.log" ends with:
Code: 
Warning: NPCharacter -> trace node not found
User Rised Exception
C:\PROJECTS\DRIVE_V2\ENGINE\SOURCES\s_stack.cpp line 47
stack overflaw
So my guess is that it called "chair_45_check" once too often.

@Fluen: "compile.log" also shows that you're using the 13th March version. Download the current update:
http://piratesahoy.bowengames.com/potc/Grey Roger/post_25May_updates_190521.zip
Among other things, I believe this removes the repeated call on "chair_45_check".
 
Hmm, I did finish the mysterious plants quest. But shortly after that, I was told how to solve the puzzle about the haunted hotel in Cartagena and went back and solved it. And I got the mysterious plants, the whole affair was about. I've only used one of the four, I got, and left the three others in my chest.

Should I use and/or toss them? And is there anything else I can to to finish a quest, I thought, I had finished?

I have also downloaded your zip-file and will implement it right away.
 
It depends on how old the game was before the new zip is installed. Going from 13th March to 13th May should be fine. Going from basic May 2018 installer to 13th May would certainly require a new game. You'll know pretty quickly because when a new game is required, the version number is changed and the game won't accept your savegames.

Having said that, the new version number is only implemented when something drastic has changed so that continuing a savegame is likely to cause serious trouble. For example, if a system variable has changed, you could load an old savegame, play a while, try to save again and the game crashes. If the version number hasn't changed then you should be able to continue your savegame safely but might not get the full benefit of the update until you start a new game.
 
Uh oh! It begins to sound like continuing my existing game and try to solve the various conflicts is more trouble than just starting a new game. If it will reduce the risk of crashes, when I conquer towns, that's what I'll do. I still want to conquer the entire Caribbean - five towns is just the beginning.
 
Try it. I'm not sure, but looking at the quest code, putting the newer update into place might very well cure the crashes. Up to and including the March update, quest case "chair_45_check" would check if you were in possession of item "chair_45" and if not, run the check again half a second later. Which means if you've left the "Mysterious Plants" quest for a while to do something else, it's going to keep running the check. The May update changes quest case "chair_45_check" to not keep on running itself, which means once the update is in place, I'd expect the check to run once more and then stop. Whether this will break "Mysterious Plants", I don't know, but at least hopefully it will allow you to attack a fort without the game crashing.
 
Grey Roger said:
Up to and including the March update, quest case "chair_45_check" would check if you were in possession of item "chair_45" and if not, run the check again half a second later.
Click to expand...
I wonder if that couldn't be handled differently altogether; just with a new "quest win condition".
Once that checks for 'CheckCharacterItem' already even exists!
And when that check isn't triggered often enough, some extra calls to 'QuestsCheck();' could be added somewhere.
 
Pieter Boelen said:
I wonder if that couldn't be handled differently altogether; just with a new "quest win condition".
Once that checks for 'CheckCharacterItem' already even exists!
And when that check isn't triggered often enough, some extra calls to 'QuestsCheck();' could be added somewhere.
Click to expand...
Something like this, perhaps:
Code: 
           pchar.quest.chair_45_check.win_condition.l1 = "item";
           pchar.quest.chair_45_check.win_condition.l1.character = pchar.id;
           pchar.quest.chair_45_check.win_condition.l1.item = "chair_45";
           pchar.quest.chair_45_check.win_condition = "chair_45_check";
It's in the May update. ;) And it's presumably why the looping check is no longer needed.
 
Grey Roger said:
Something like this, perhaps:
Code: 
           pchar.quest.chair_45_check.win_condition.l1 = "item";
           pchar.quest.chair_45_check.win_condition.l1.character = pchar.id;
           pchar.quest.chair_45_check.win_condition.l1.item = "chair_45";
           pchar.quest.chair_45_check.win_condition = "chair_45_check";
It's in the May update. ;) And it's presumably why the looping check is no longer needed.
Click to expand...
Ha!
Yes.
Exactly that. :rofl
 
You must log in or register to reply here.
Back
Top