I think I've found it... but as yet untested (I may get a chance to fix this for the 8pm build, but I'll probably run a test on the dev-server first if I get time this afternoon).
I think what's happening is this:
In 'fn_catchFish.sqf' (the underwater 'grab' action for fish), the current cursor-target object is checked for 'fishyness' and a range less than 3.5m. If a match, it then does a 'switch do' (which is rather like a BASIC 'select case') on the type of fishy object, checking its ARMA3 object-typename. If it matches a known ARMA3 fish-object, it sets the _type variable to one of 'salema', 'mackerel', 'ornate' and so on. Note that these are ALL entirely lower-case words. The 'fn_handeInv.sqf' is then called to add that item type to the player's inventory.
Conversely, in the 'fn_dropFishingNet.sqf' version of the process (which is essentially the same, but has a 20m range, and requires some set up to do with boat speed, crew, etc, before the net is droppable) the switch-do to find the 'fish-object' type is slightly different. In this version, the _type variable is set up to use a LOCALISED version of a string that's stored in stringtable.xml. The fish-type strings here are NOT the same.. they use types like 'Salema', 'Mackerel', 'Ornate', etc. Notice that first capital letter?
Once again, the resulting _type variable is thrown at the fn_HandleInv.sqf function as before...
...so let's look at what happens in there...
First thing (of any consequence) that it does there, is call another function 'fn_varHandle.sqf' to convert the '_type' variable that we were given by fn_catchFish or fn_dropFishingNet into a variable known to Altis Life (one of the 'missionspace' variables'). These missionspace variablenames are like 'life_inv_salema', 'life_inv_mackerel', 'life_inv_ornate' and so on, and usually contain a number that shows how many of a given object is held by the player. VarHandle uses another 'switch/do' to check the input _var (_type) and return the output as 'life_inv_whatever'... but it EXPECTS the input _var to be LOWERCASE entirely.
Consequently, it will fall over when _var is given as the string "Salema" instead of "salema". Switch-do is CASE-SENSITIVE (according to this note on here, at least:
https://community.bistudio.com/wiki/switch_do). Thus, "Salema" would drop all the way through, and instead of returning a string saying "life_inv_salema", would instead return a Boolean 'FALSE' value back to fn_HandleInv.sqf (the calling script).
fn_HandleInv.sqf would then fail on line 22, because it's expecting _var (from the fn_varHandle.sqf function above) to be a STRING which names a player's life_inv_xxxx variable, but instead, all it has is a Boolean false, due to the broken exit from that function. Hence the error - it expected a string, but got given a Boolean (true/false), and died on its arse.
Net result (pardon the pun)... no fish for you!
Easily resolveable, though. We either make the localised strings all lower case in stringtable.xml, or we adjust the fn_varHandle.sqf switch-do so that it copes with BOTH variations of the string (capitalised and lower-case throughout), and exits the routine cleanly with the right 'life_inv_xxxx' string/variablename.
TBH, looking through the rest of the codebase, the ONLY place where a 'localised' version of the fish-type is ever used, is in fn_dropFishingNet.sqf! It never actually appears on screen as a result of the stringtable.xml variables, and the stringtable.xml version serves NO other purpose than (intendedly) making fn_dropFishingNet.sqf work. Which it doesn't. So - by far the easiest fix is to just make the fish typenames all lower-case in the stringtable.xml; they'll never been seen anyway, and nothing else needs to be changed.
Thanks for the puzzle. That's another one of Tonic's dropped balls picked up and put in the back of the net!
