[FOB] [0001] Bug: sort out the building of FOB and related persistence

[mwpowellhtx]

Basic Information

Mission version: 0.98.dev-s5 Map used: Altis

Short Issue Description

Was not either saving FOB data as well as persisted objects. And other concerns, like map markers not being updated, IDs apparently not being assigned correctly upon FOB being built, which we think might be because of exec versus spawn versus call constraints. Just in terms of UUID, for example, standalone calls to KPLIB_fnc_uuid_create_string work just fine, but we are not seeing a UUID landing in the FOB tuple correctly under ordinary FOB building conditions.

Expected Behaviour

Should be able to save not only the FOB data itself, but also persist the corresponding FOB buildings. Means we should also be able to restore both seamlessly. We need to also be aware of cases when assets are persisted apart from known FOB locations; i.e. when a FOB was lost, let's say. Should not be restoring those objects.

We might also introduce event handlers doing the "update markers" for different concerns, i.e. FOBs. Which would re-mark when necessary. And also necessarily ensure correct UUID identification. Identification is really critical because we will eventually use this in order to identify different assets, storages, vehicles, sectors, etc.

Sidebar

Assessing the issue and, we think, potentially resolving it, we think we also corrected the matter of proper up and vector, and other bits, being applied correctly to objects, units, etc, when they are created. Will explain that one further, but we think this one happens to have been addressed. This after painstakingly sprinkling in logging retracing the lifetime of the up and direction vectors, for example.

All for now on this one. We will enumerate the bits in a subsequent edit. It is also critical that this matter be addressed and, in some cases, redressed prior to pursuing the question of factory sector build storage.

Obiectives

So what did we learn today...

• [x] After chasing the vectors all throughout the client server FOB building creation event handling process... So many hoops, hills, arounds, overs, unders... Let me just tell you. After all that, I am halfway confident that I isolated and corrected the issue, and actually a couple of other issues, by containing attribute setting sequences in a [...] spawn {...} immediately following their creation. Not sure what happened there, the object was either not fully there yet, whatever. After doing that the attributes got set correctly. So there's that.
• [x] Also worked through saving and loading issues coordinating FOB tuples with their respective persistent FOB building objects. Not totally out of the woods yet, but I think it is more stable than it was before, pending a commit yet. Letting this issue simmer a bit.
• [x] Which it also does raise an interesting question. How much of a tuple do we really need after all. Bare minimum a way of identifying the FOB building and/or a map marker by ID or name. Bare minimum. After that, maybe we carry a few summary bits. Not sure yet. But I am also warming up to the idea that we affix a handful, or perhaps just the FOB data as variables on the structure itself. That seems like an interesting possibility. Pursued vis-a-via issue.
• [x] So what would that mean for dealing with points of interest. Pretty much always via their map markers. That is the key bit of information. Along with coordinating with a core set of thin sequencing arrays. That's it. For anything beefier, we would introduce variables on the objects themselves.

[mwpowellhtx]

As the objectives stated, we did sort out the vector issue while building the FOB building. Turns out it was pretty straightforward. The difficult part was chasing the up and direction vectors throughout the whole process, through client and server, etc.

[mwpowellhtx]

Sorted out persistent variable serialization. Looks like it is working now, both during save as well as load, serialization and deserialization, respectively.

[mwpowellhtx]

Concerning points of interest, i.e. factory sectors, yes, should be no big deal, we can handle accordingly.

[mwpowellhtx]

This one is sorted out we think. Will file other concerns as they pop up.