The following was triggered by my investigations on this: Fixed - WorldMap Related Error.log Entry | Page 2 | PiratesAhoy!
And are probably related to this planned feature as well: Medium Priority - Worldmap Encounter Enhancement (V 1.32) Updated | PiratesAhoy!
I get the impression there is a definite ERROR with the GenerateMapEncounter function.
Refer to the following:
Note that 'ref iEncounter' is not used as INPUT, because it gets SET in the function.
That means that it is probably meant to be an OUTPUT of the function that you can read with the "&" sign.
But this is where that function is called. Note that there is NO "&" sign to read the output on the marked line:
So also here, iEncounter1 is NOT used as input. Instead, it is set to '-1' at the beginning of the function and I see no spots where it is ever set to anything else.
I'd expect the marked line to be modified like this so that it can SET that variable:
bReturn = GenerateMapEncounter_Merchant(iNearIslandNation, &iEncounter1);
That would mean that 'iEncounter1' is set inside the GenerateMapEncounter_Merchant function and gets read as second output here.
Refer also to the final use here:
Here 'i1' and 'i2' are read from the 'ref iEncounter1, ref iEncounter2' function inputs using the "&" sign.
Except we have already seen that those are ALWAYS '-1' as they never get set to anything else.
Note also that the variables have a different name in their use here: 'i1' and 'i2'.
This may appear to match with this section in the earlier function:
Except that it doesn't, because those variables are defined at the end of the function and never used.
They also are NOT returned to the function above that reads variables with the same names, because the variable names between functions DO NOT NEED TO MATCH.
'ref iEncounter1' from GenerateMapEncounter becomes 'int i1' in wdmShipEncounter because the "&" sign reads the (unused) input variable and NOT the variable of the same name.
See how these aren't even the same VARIABLE TYPE. A 'ref' suddenly gets used as an 'int' instead.
I have to admit I am no expert on programming theory, having learned virtually everything I know about it simply through doing it.
So @Levis, @jsv or @pedrwyth, please have a look at my above interpretation of this code and tell me if I'm making any lapses of logic here?
Assuming that I AM right here, then for sure this code is NOT serving its intended purpose.
Which makes me wonder how the worldmap encounters can even work as well as they do with the code in its current state?
I don't dare changing this code right now for fear of trying to fix a system that appears broken,
but suddenly finding out that the system as intended triggers all sorts of unintended side-effects.
And are probably related to this planned feature as well: Medium Priority - Worldmap Encounter Enhancement (V 1.32) Updated | PiratesAhoy!
I get the impression there is a definite ERROR with the GenerateMapEncounter function.
Refer to the following:
Code:
bool GenerateMapEncounter_Merchant(int iNearIslandNation, ref iEncounter)
{
// find free slot in dynamic encounter table for map
int iEncounterSlot = FindFreeMapEncounterSlot();
if(iEncounterSlot == -1) return false;
ManualReleaseMapEncounter(iEncounterSlot);
ref rEncounter = &MapEncounters[iEncounterSlot];
[...]
iEncounter = iEncounterSlot;
[...]
return true;
}
That means that it is probably meant to be an OUTPUT of the function that you can read with the "&" sign.
But this is where that function is called. Note that there is NO "&" sign to read the output on the marked line:
Code:
bool GenerateMapEncounter(int iMapEncounterType, string sIslandID, ref iEncounter1, ref iEncounter2)
{
iEncounter1 = -1;
iEncounter2 = -1;
[...]
bReturn = GenerateMapEncounter_Merchant(iNearIslandNation, iEncounter1); // <------------------- NOTE THIS LINE -----------------------
[...]
ref rEncounter1, rEncounter2;
if(iEncounter1 != -1)
{
rEncounter1 = &MapEncounters[iEncounter1];
rEncounter1.GroupName = ENCOUNTER_GROUP + iEncounter1;
}
if(iEncounter2 != -1)
{
rEncounter2 = &MapEncounters[iEncounter2];
rEncounter2.GroupName = ENCOUNTER_GROUP + iEncounter2;
}
int i1 = iEncounter1;
int i2 = iEncounter2;
return true;
}
I'd expect the marked line to be modified like this so that it can SET that variable:
bReturn = GenerateMapEncounter_Merchant(iNearIslandNation, &iEncounter1);
That would mean that 'iEncounter1' is set inside the GenerateMapEncounter_Merchant function and gets read as second output here.
Refer also to the final use here:
Code:
void wdmShipEncounter(float dltTime, float playerShipX, float playerShipZ, float playerShipAY)
{
[...]
int i1 = -1;
int i2 = -1;
[...]
if(GenerateMapEncounter(WDM_ETYPE_MERCHANT, wdmGetCurrentIsland(), &i1, &i2) == false) return;
wdmCreateMerchantShip(i1, "", rand(50) - 50);
Except we have already seen that those are ALWAYS '-1' as they never get set to anything else.
Note also that the variables have a different name in their use here: 'i1' and 'i2'.
This may appear to match with this section in the earlier function:
Code:
int i1 = iEncounter1;
int i2 = iEncounter2;
They also are NOT returned to the function above that reads variables with the same names, because the variable names between functions DO NOT NEED TO MATCH.
'ref iEncounter1' from GenerateMapEncounter becomes 'int i1' in wdmShipEncounter because the "&" sign reads the (unused) input variable and NOT the variable of the same name.
See how these aren't even the same VARIABLE TYPE. A 'ref' suddenly gets used as an 'int' instead.
I have to admit I am no expert on programming theory, having learned virtually everything I know about it simply through doing it.
So @Levis, @jsv or @pedrwyth, please have a look at my above interpretation of this code and tell me if I'm making any lapses of logic here?
Assuming that I AM right here, then for sure this code is NOT serving its intended purpose.
Which makes me wonder how the worldmap encounters can even work as well as they do with the code in its current state?
I don't dare changing this code right now for fear of trying to fix a system that appears broken,
but suddenly finding out that the system as intended triggers all sorts of unintended side-effects.