Handling of initial FOB Box, FOB placement

[veteran29]

Q	A
Bug fix?	no
New feature?	yes
Needs wipe?	YES
Fixed issues	#391

Description:

Handling of initial FOB box and functionality of FOB creation

Content:

• Spawn of the FOB Box on the USS Freedom (only if no FOB has yet been built).
• Respawn handling if the FOB Box (sunken, destroyed) as long as there is no FOB.
• Action on the FOB Box for FOB deployment when distance to Freedom exceeds Xm.
• Deletion of the Box and registering the FOB for the save procedures.
• FOB marker creation

Tested on:

• Local MP Vanilla
• Local MP ACE
• Dedicated MP Vanilla
• Dedicated MP ACE

[Wyqer]

Guess this false isn't needed.
Just directly the bool condition, which will return true or false.
Maybe even no _canbuild variable at all and just the expression as return value.

[Wyqer]

I think this could be an issue later.
Imagine you've 5 FOBs -> index is 5, so it creates KPLIB_fob_5. This is fine so far and now an index would be 6 due to the count.
Now the player loose FOB 2 and creates a new one. Count returns 5 and it would be another KPLIB_fob_5.

[veteran29]

Maybe for marker name we could do "KPLIB_fob_" + mapGridPosition _position and after count of FOBs changes I will just loop on every of them and reassign Alphabet names?

Do you think is it even worth to store markers here? I wanted to do it for unification as capturable sectors are stored as markers, FOB is kind of sector too.

[Wyqer]

I think you're right concerning just store the positions for the FOBs. This also eliminates the need to have the getMarkerPosition conversion.

[veteran29]

I've decided to keep markers instead of positions for consistency. Markers use mapGridPosition for their name so there is no risk of duplicate names.

Function checking if FOB can be build was improved (It does not check if another fob is near but this should be added when we will add actions to fobs as I want to experiment with few different approaches to this problem).

Requesting second review from @Wyqer