Use Trace to see what output it generates?
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!
Quick links for Beyond New Horizons
- Download latest version
- Wiki
- FAQ
- Report bugs here
- Bug Tracker on Github
Quick links for Maelstrom
- Download the latest version of Maelstrom
- Download the latest version of ERAS II
- Download the latest version of New Horizons on Maelstrom
Quick links for PotC: New Horizons
- Download latest version
- Wiki
- FAQ
- Report bugs here
Thanks to YOUR votes, GOG.com now sells:
- Sea Dogs
- Sea Dogs: Caribbean Tales
- Sea Dogs: City of Abandoned Ships
Vote now to add Pirates of the Caribbean to the list!
Quick links for AoP2: Gentlemen of Fortune 2
- Downloads and info
- ModDB Profile
- Forums Archive
A Pirate Podcast with Interviews
Music, Comedy and all things Pirate!
- Episode Guide - About - Subscribe -
- Twitter - Facebook - iTunes - Android -
- Youtube - Fill the Coffers -
if (rFantom.FantomType == "war" && rand(100) > 15) randGoods = 0;
Looking at a ship's flag tells you whether it is a navy or merchant one, if that is of any help.I'm considering adding GetCharacterShipType(rFantom) != "trade" to the if too; that way ships that are classed as both war and trade should still carry a bit of cargo even in a war encounter, but pure warships will mostly carry nothing. or make it so that the treasure galleon is exempt to avoid similar disappointments because of childish expectations or just leave it
case -1: // Fantom_GenerateEncounter not run, do something else
iBootyQuality = GOODS_QUANTITY - rand(iShipClass);
break;
it is! I didnt think of that!Looking at a ship's flag tells you whether it is a navy or merchant one, if that is of any help.
Maybe whether it is a war/merchant/versatile ship? And perhaps Pirates should be an exception of some kind.are there other things that should be accounted for?
while traders and pirates already get a larger amount of the cargo they get, I think it aint unreasonable traders get more expensive loot tooMaybe whether it is a war/merchant/versatile ship? And perhaps Pirates should be an exception of some kind.
case "-1": // Fantom_GenerateEncounter not run, do something else
iBootyQuality = GOODS_QUANTITY - rand(iShipClass);
if(rand(100) > 60 && rFantom.FantomType != "pirate"){ // for fun! better cargo potential for trader vessels
if(GetCharacterShipType(rFantom) == "trade" && GetCharacterShipType(rFantom) != "war") iBootyQuality -= rand(round(randnorm(iShipClass*2,iShipClass)));
if(GetCharacterShipType(rFantom) == "trade" && GetCharacterShipType(rFantom) == "war") iBootyQuality -= rand(round(randnorm(iShipClass,iShipclass/2)));
}
if(iShipClass > 5){ iStart += 6;} // lesser vessels don't carry the most valuble cargo
else{
if(rand(100) > 20) iStart += 2; // higher end ships could sometimes in a blue moon carry noble metals!
}
break;
It should do.The original problem was to arrange that unescorted merchants have less valuable cargo, while single merchant with heavy escort should have more valuable cargo - does this deal with that?
it does! should be well worth targetting more dangerous marks now!The original problem was to arrange that unescorted merchants have less valuable cargo, while single merchant with heavy escort should have more valuable cargo - does this deal with that?
Thanks!Great stuff @DeathDaisy , it seems to work as intended. My first comment on balancing is I've hardly seen a "war" vessel getting cargo so I think the 80% exception too strong in the long term - indeed for balancing it might be worth commenting out completely whilst we see what goods a warship gets - then cutting down the odds of that later.
I did lead me to wonder about boosting chest contents for warships rather than cargo but that would be a whole extra ball game - perhaps interesting none the less?
I encountered the index error again yesterday. cant get to the logs right now, but I think it was when ecnountring an enc type 0 on the map. gotta take a closer look at that math and see how iBooty would end up as larger than 33. my spontaneous guess without looking at the code is that the -1 we removed in the rand(iBootyQuality - iStart) thing somehow causes iBooty to end up as 34 sometimes? gonna try it when I get the chance.
no need to be sorry, I could have checked too and not just blindly remove it, so it was a team effort! now it seems to work like a charm, so thanks for all the inputYes it's that array size - there are 33 goods but in an array 0-32 so using the 33 causes the array to go out of range when picking a good if the full number 33 is left by the random variable - hence the -1. Sorry I didn't check through the logic when I queried why one was being taken from the 33