oscar-broman / SKY

SKY - Slice's fork of kurta999's fork of YSF
39 stars 28 forks source link

FreezeSyncData and SendLastSyncData works only with onfoot sync #31

Closed NexiusTailer closed 4 years ago

NexiusTailer commented 5 years ago

I think it would be nice if these functions could work with all types of player sync and not only with the onfoot type. I understand that these functions (like all other functions in this plugin too) was presented firstly for weapon-config and there can be no need in this abilities for wc, but it can be useful for any other scripts which may use it for different systems.

ADRFranklin commented 4 years ago

release-windows.zip release-linux.tar.gz

does this make any difference? I'm wondering if the conversation was not correct.

NexiusTailer commented 4 years ago

release-windows.zip release-linux.tar.gz

does this make any difference? I'm wondering if the conversation was not correct.

The problem still remains :(

NexiusTailer commented 4 years ago

So I've noticed you released a new version v2.2.1 and I just tested it. There is no such problem like with previous posted .DLLs & .inc here any more (the player stay on the same place for others when his sync frozen even with E_LAST_SYNC mode), but this type (E_LAST_SYNC) now works like any other type, e. g. when I do FreezeSyncPacket(playerid, E_LAST_SYNC, true); on an player who is onfoot all is ok, but then he enters the vehicle and any driver sync become visible for other again like if I did E_PLAYER_SYNC.

ADRFranklin commented 4 years ago

I don't really understand what you meant? You said it freezes them correctly, but then you said it doesn't freeze them when they enter a vehicle, but if you freeze a player, you must unfreeze them for them to enter a vehicle, so that doesn't make sense as to what the problem is?

NexiusTailer commented 4 years ago

release-windows.zip release-linux.tar.gz does this make any difference? I'm wondering if the conversation was not correct.

The problem still remains :(

^ The first message was about testing these files (.dll):

release-windows.zip release-linux.tar.gz

does this make any difference? I'm wondering if the conversation was not correct.

and .inc file from here (as it was the latest .inc file shared):

release-windows.zip release-linux.tar.gz SKY.inc.zip

Okay, I have added the ability to use E_ANY_SYNC which will freeze/re-send the last sync that came through.

And in that case when I test it, E_ANY_SYNC (last shared SKY.inc has exactly this type name in enum) wasn't work at all as the frozen-synced player has an ability to move for others like he move for himself.

So I've noticed you released a new version v2.2.1 and I just tested it. There is no such problem like with previous posted .DLLs & .inc here any more (the player stay on the same place for others when his sync frozen even with E_LAST_SYNC mode), but this type (E_LAST_SYNC) now works like any other type, e. g. when I do FreezeSyncPacket(playerid, E_LAST_SYNC, true); on an player who is onfoot all is ok, but then he enters the vehicle and any driver sync become visible for other again like if I did E_PLAYER_SYNC.

^ The second message was about this files (.dll): https://github.com/oscar-broman/SKY/releases/tag/2.2.1

and .inc file from here (as there is no its own .inc file for every version in the releases section): https://github.com/oscar-broman/SKY/blob/1bd6e7bc7777f3b551177d8bcb79b7cadeadd071/SKY.inc

And in this case when I test it, now E_LAST_SYNC freezes single type of the synchronization (applied for a player who is onfoot => it will freeze only onfoot data and any other type of sync will be synced instead of onfoot and moreover will be synced without any freeze).

As for "if you freeze a player, you must unfreeze them for them to enter a vehicle" - I'm using FreezePlayerPacket without applying TogglePlayerControllable for the player (if you mean it) to test only the FreezePlayerPacket without any side effects to see if it works and whether it works correctly. I want to make anti-unfreeze that will freeze exactly the type of synchronization for a player that he sent before applying this function. And even if the player ignores the function of the “visual” freeze by the server (TogglePlayerControllable), his synchronization for others will continue to appear as if it had stopped moving, including ignoring any change in the type of synchronization (the player got into his car and started to drive off, but for others he should still stay onfoot in the last place he stood before this function was applied).

ADRFranklin commented 4 years ago

And in this case when I test it, now E_LAST_SYNC freezes single type of the synchronization (applied for a player who is onfoot => it will freeze only onfoot data and any other type of sync will be synced instead of onfoot and moreover will be synced without any freeze).

This is how I purposely coded it, this is what you explained to me you wanted, so this is what I gave you?

As for "if you freeze a player, you must unfreeze them for them to enter a vehicle" - I'm using FreezePlayerPacket without applying TogglePlayerControllable for the player (if you mean it) to test only the FreezePlayerPacket without any side effects to see if it works and whether it works correctly.

Why are we talking about TogglePlayerControllable? Of course you would need to untoggle a frozen sync to have them enter a vehicle. (for other players) E_LAST_SYNC is exactly what it's name describes, it freezes the very last sync that was used, previous to when the native is called.

NexiusTailer commented 4 years ago

This is how I purposely coded it, this is what you explained to me you wanted, so this is what I gave you?

Then, it seems, I didn't express myself very clearly, sorry about it :) I just thought that it would be possible to block all types of synchronization at once with one option.

Why are we talking about TogglePlayerControllable? Of course you would need to untoggle a frozen sync to have them enter a vehicle. (for other players) E_LAST_SYNC is exactly what it's name describes, it freezes the very last sync that was used, previous to when the native is called.

Just made sure any other functions like real freezing have nothing to do with it. So as for E_LAST_SYNC I thought it's an option not for freezing only one type of sync the player holds now.

ADRFranklin commented 4 years ago

So you want a way to freeze all current/future syncs for a player?

NexiusTailer commented 4 years ago

Yeah, now I (finally lol) understood that I gave one suggestion and got nice but different feature. And yeah, it would be very nice if you implement something like that I mentioned.

Btw, E_LAST_SYNC is still useful as it can be an easy solution for weapon-config which used an old FreezeSyncData without getting the player's state (type of sync). Now it can be updated for a new native without any problem.

NexiusTailer commented 4 years ago

So you want a way to freeze all current/future syncs for a player?

Sorry for the possible annoyance, but could you share some information when this addition will be available for testing? :)

ADRFranklin commented 4 years ago

Hi, sorry I have been a little busy with other projects, I will find time over the next few days to finally sort this.

ADRFranklin commented 4 years ago

release-windows.zip release-linux.tar.gz SKY.inc.zip

(IGNORE THE ONES ABOVE)

release-linux.tar.gz release-windows.zip SKY.inc.zip

Try this, got a few minutes didn't take long.

NexiusTailer commented 4 years ago

Thanks, seems to work for me on windows server.