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

Fixed Food and rum from Escort Ship transfered to your ship without reason

Extract attached to PROGRAM\WorldMap .

The original report was easily fixed by removing the GetRemovable checks as that half-excluded Escort Ships from consumption, but they weren't completely ignored.
Now they ARE included same as any other ships in your fleet.

However, food and rum consumption doesn't work in nice whole units.
So if you use 0.5 unit per day, you'll use 0 on the first day and 1 on the second day and so on.
But what ship to take that "1" unit from? There was a loop in place to check all ships to figure that one out.
That loop always started with the same number though.

That means that if consumption is less than 1 unit per day per ship, as is often the case, the same ship gets chosen to provide the supplies every time.
Effectively that means that some ships are exempt from the rations consumption.
Normally that isn't a problem as the supplies within your fleet are shared anyway.
However, with an Escort ship in there, that seems less fair.

Therefore I have now added a counter so that each day, the first ship checked is a different one.
This seems to have helped a lot and now I observe consumption from ALL ships.
So I think this may be OK now.
 

Attachments

  • DailyCrewUpdate.zip
    8 KB · Views: 86
Well so the escort ship does share its provisions but then generously doesn't consume any - if I read the code right. The call to GetSquadronTotalCrewQuantity() in characterutilite which is used to work out how much crew and thus how much provisions are consumed has the getremovable check to exclude them (unless it's just too late in the day and I'm missing something again) so if they are part of the squadron provision, consumption still looks wrong, but removing the exception from there may have a knock on where? You don't normally buy food and rum to cater for other ships not under your direct control so that is why I suspect the code tried to keep the two separate - but obviously failed. Fixing the separation may be a better option.

Related to this it seems you have basically removed any exception for food and rum for quest ships that sail with you - as always - I don't know enough of the various plotlines to know if this may have any knock-on effect.
 
Bugger. Reopened it is. :(

Why don't we just get rid of that GetRemovable check in GetSquadronTotalCrewQuantity as well?
Alternatively, we'll have to see about exempting non-removable quest ships altogether in such a way that they DON'T consume anything but also don't get their cargo "stolen". :facepalm

Ugh, why is so much complicated stuff so wrong?

(Oh wait, I know! Because it's complicated.... :rolleyes: )
 
Ugh, why is so much complicated stuff so wrong?

(Oh wait, I know! Because it's complicated.... :rolleyes: )
- and if it were "right" we wouldn't be looking at it? - and thus without scrutiny it wouldn't seem at all complicated (possibly)

I think the line in characterUtilite in function GetSquadronGoods()

Code:
if( GetRemovable(chref) || _Goods == GOOD_WHEAT || _Goods == GOOD_RUM) // LDH 13Oct06 fix for quest ships

May have something to answer for in including them in consideration in quantity of consumables. If they are excluded it makes the whole thing simpler. No? Just keep them excluded via getremovable checks through the rest of the process.

The only thing will be if it is a long voyage you can attack/capture them at the end of the voyage and they won't have consumed their supplies at all - pretty minor gain I would guess.

My offer remains open to look a bit further.

Taking out the exception in GetSquadronTotalCrewQuantity may open more closets than it closes - for one it seems to include them in "cursed coin" calculations territory.
 
If I understand correctly, GetSquadronTotalCrewQuantity (which does NOT include the "locked" escort ship crew) needs to be fed.
Now ALL ships in the fleet contribute to that, INCLUDING the locked ones.
So effectively then, the escorted ship helps out with feeding the player fleet crew. Right?
Probably not a huge bug, but also definitely NOT fair and it would be much better to have that fixed too! :onya

Thinking about it a bit further, I agree that including "locked" crew in GetSquadronTotalCrewQuantity would be a bad idea.
That probably opens up a can of unforeseen (and foreseen) side-effects that we really don't want.

Maybe I have a simple solution though.
In CharacterUtilite.c add a new function to return the number of crew from "unremovable" ships:
Code:
// KK -->
//gets total crew of squadron
int GetSquadronTotalCrewQuantity(ref mchref)
{
   int crewQ = 0;
   int i,cn;
//   crewQ += GetTotalCrewQuantity(mchref);
   ref chref;
   for(i=0; i<4; i++) // PB: Starting at 0 includes player ship crew too
   {
     cn = GetCompanionIndex(mchref,i);
     if( cn>0 && GetRemovable(&Characters[cn]) )
     {
       chref = GetCharacter(cn);
       crewQ += GetTotalCrewQuantity(chref);
     }
   }
   return crewQ;
}
// <-- KK

// PB -->
//gets total crew on escort and specific quest ships
int GetUnremovableCrewQuantity(ref mchref)
{
   int crewQ = 0;
   int i,cn;
   ref chref;
   for(i=1; i<4; i++) // Deliberately exclude player crew, just in case
   {
     cn = GetCompanionIndex(mchref,i);
     if( cn>0 && !GetRemovable(&Characters[cn]) )
     {
       chref = GetCharacter(cn);
       crewQ += GetTotalCrewQuantity(chref);
     }
   }
   return crewQ;
}
// <-- PB
Note: I also simplified GetSquadronTotalCrewQuantity there a bit (just because I can... :rolleyes: ), but didn't test it yet.

Then in DailyCrewUpdate.c, add an extra line so that they are added AFTER the cursed coins take effect (just in case):
Code:
     int crewQ = GetSquadronTotalCrewQuantity(pchar);
     // PB: Cursed Coins -->
     if(CheckCharacterItem(pchar,"cursedcoin"))
     {
       CursedCoins = GetCursedCoinCount();
       crewQ = crewQ - CursedCoins;
       if(crewQ<0)   crewQ = 0;
     }
     // PB: Cursed Coins <--
     crewQ = crewQ + GetUnremovableCrewQuantity(pchar);
     bool CheckFood = FOOD_ON && CheckAttribute(pchar, "ship") && crewQ>0;
Do you reckon that would work?
If not:
My offer remains open to look a bit further.
Please do! My brain is shutting down here.
I hope the above suggestions may be of some help, but I'll leave it at this for now....
At the very least, my change to more evenly spread the consumption over all ships should be a good thing to come out of this. :oops:
 
Missed out all the introduction BUT
Do you reckon that would work?

In my experience with your suggestions - YES - but these days I'm not a bright young thing and I need time to look through stuff so Maybe? - but I still don't see why they are eating/drinking with the "squadron"

lost the text but the gist of my offer was to look further at this point!

Please do! My brain is shutting down here.
I seriously doubt that, but I will take my time to leisurely stroll through the code and look for a nice resolution to the scenario. If I find one then I'll post it - if not then you already have a winner!:bow
 
I'd really appreciate you double-checking this to make sure it really DOES work as intended and improve it further as you see fit! :cheers
 
I will still look at it - but fresh thought on a new day got me thinking WHY had the quest ships been "fixed" to include them. I guess someone could have noticed they didn't consume their provisions but can't really see that being enough to incite a "fix". BUT hey wait a minute - if they aren't you could easily have a scenario where your crews are starving and falling like flies while an untouched food & drink source sails serenely alongside - I imagine that would have raised some gameplay comments! :rumgone= particularly since the food and rum system had just been re-written around that time. So I guess that answers my "why are they included at all"

My original notice of their not eating comes from the code -you wouldn't likely notice it in gameplay (unless we have players with food consumption equations in their heads - and even then since it effectively just eaks out the foodstocks shouldn't be a cause for complaint - seems nobody did). Of course leaving something that is "wrong" goes against the grain :sick but your adding in them to consumption fixes that anyway

So as usual I suspect your fix will be fit for purpose :aar
 
There was all sorts of weirdness in Beta 3.4 with such "locked" quest ships.
Also, merchants were MEANT to be locked like that, except they never got set to that because the code for it didn't match up with the intentions.
So then I fixed that, only to find that caused merchants would get ZERO supplies at all and they wouldn't fire their cannons because they didn't have any ammo.
Fix that and they get supplies, but then the player ship ends up "automatically stealing" everything from them on the first midnight.
Another fix later and the companion ship keeps their supplies AND consumes it too.
But then their own crew isn't included in the calculations, requiring another fix. It's been a bit of an ongoing thing for months. :facepalm

My original notice of their not eating comes from the code -you wouldn't likely notice it in gameplay (unless we have players with food consumption equations in their heads - and even then since it effectively just eaks out the foodstocks shouldn't be a cause for complaint - seems nobody did). Of course leaving something that is "wrong" goes against the grain :sick but your adding in them to consumption fixes that anyway
Very true. I much prefer having the numbers match up, even if players wouldn't be likely to notice it.
Plus having the escort ship eating their stuff too does increase the challenge of the game somewhat.
Or that is to say.... it removes an invisible exploit and therefore makes the game a bit harder.
Which is a good thing as I reckon, as long as it is "harder in a fair way".

Thanks a lot for double-checking the logic here and also on the Nations Relations.
Without thoroughly critical eyes to see what is being done, how and why, the end result would never be as good as it now will be! :cheers
 
Back
Top