For water detection, I don’t have firsthand experience doing this. Depending on how you are going about it, it may or may not help first to GetNameOfZone to check if your chosen coordinates (your random mission area?) is one of the zones with water before looking for it specifically. But then I wonder if this native can be made to work:
If being in water returns true as per the note in the native reference guide then hopefully not being above water returns false, or something else consistent. The alternatives seem more challenging (raycast with water flag?): Native Reference - Cfx.re Docs.
https://gtaforums.com/topic/873602-identifying-surface-material-type/
As for host issues I’m not really certain. I think NetworkIsHost() works properly in the latest resource manifest but I’m not sure how you would structure what you are doing.
The blip thing may or may not pull you into all these complexities of managing persistent and global networked entities across clients. My understanding is it has improved since the March 2018 update. In the blip thread you linked the problem case was a prop, which I thought was handled somewhat differently than peds in the network code, and the solution posed by an element was to set mission entity and possibly use the ‘exotic’ native SetNetworkIdSyncToPlayer. I’m not sure if RequestCollisionAtCoord would also be useful in that case of a distant prop in a not yet loaded map point of a remote client who did not create the prop.
I don’t know if you will need all of that, especially if sixsens tested an earlier version with working blips? Maybe I’m confused on that with the back and forth of versions and testing. But yes, as far as I can gather, the current ‘best practice’ for creating persistent networked entities includes using SetEntityAsMissionEntity. If you plan on using netIDs, for instance to convert back and forth local entityIDs ↔ global netIDs, which seemed to be the direction the ‘blip for everyone’ solution was heading, then you may need more.
As you see it’s advised to use NetworkRegisterEntityAsNetworked (unless that is redundant after SetEntityAsMissionEntity). SetNetworkIdCanMigrate can be used but whether you set it true or false depends upon your usage.
And again, some scripts appear to use RequestCollisionAtCoord in cases where a client may not yet have loaded distant map locations/entities. This is ALL a bit murky until there is complete FiveM documentation on networking or at least someone lays out clearly how the post-March 15 “more like GTA IV” networking actually works.
As for your Sandboxie experiement, I guess it didn’t work at all? I wish it were easier to test your own server and script with multiple connections. I’m not sure if someone has devised a way.
