FreezeSyncData and SendLastSyncData works only with onfoot sync

[NexiusTailer]

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]

I will take this in to consideration at a later point.

[ADRFranklin]

Could you give me a couple of examples of data you want to be able to re-send / freeze?

[NexiusTailer]

Actually I'm going to use this feature to make more advanced anti-unfreeze system which wouldn't just decync the player (as others will see "sandglass" above his head), I want to resend the last player's data instead, so this player will be freezed literally not being able to ignore it by NOPs or something.

So, there are several ways how you can make this function work for all types of synchronizations: 1) Add a new parameter of the type of synchronization that is needed to be frozen. For example, we will pass the onfoot sync to it (and thus, if the player switches his sync, for example, to incar sync, the function will continue to work only on that type of sync which we indicated for freezing, i.e. onfoot sync) 2) The parameters of the function will remain the same, but this function will now decide itself what type of sync it is necessary to freeze (depending on the type that the player is sending at the moment) and when the player changes the sync type, the function will continue to freeze his new sync type accordingly.

The same can be done with resending feature I think.

[ADRFranklin]

I will see what I can for the next release. The code needs some work and further improvements to protect it against collisions with YSF and other plugins.

[ADRFranklin]

I will be planning this change next, now that all the 0.3DL stuff has finally been cleaned up.

[NexiusTailer]

Could I somehow help with the test of any drafts or in another way?

[ADRFranklin]

Ah, Sorry this got pushed aside while I was fixing a bug, which took priority. I will get back to this over the next few days.

I will most likely be implementing new natives for this, and deprecate the old ones

[ADRFranklin]

@NexiusTailer You going to be free tomorrow to test this? I've almost finished with it. I've also fixed a few issues I found where Additional Keys where not being sent when SendLastSyncData was used. The new native is called SendLastSyncPacket and does contain a type of packet to use.

Hopefully this will be more useful now.

[NexiusTailer]

Yes, I'll try to go test as you request it. Thank you

[ADRFranklin]

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

@NexiusTailer Here you go, hope this works first time, wouldn't that be nice :D You can find the include with the updated native already pushed

[ADRFranklin]

@NexiusTailer have you had time to test it?

[NexiusTailer]

Yeah, I just started testing it. Currently I have one little suggestion to make the function work also for spectating data as it is also the part of original OnPlayerUpdate.

Anyway I'll continue to test it, thanks for nice update :)

P.s. At the time I have an ability to test it only on windows server, so I didn't test the linux version yet...

[ADRFranklin]

I'm not sure as to what you are expecting for Spectating, as that's an RPC and not really part of the packet hooks that we are currently using to store and send previous sync data.

I'm glad you are happy with the update, and it should work on Linux if it works on Windows.

[NexiusTailer]

Spectating sync isn't documented on both BrunoBM16's and Pawn.Raknet's wikis (the second don't have it in common examples) but it is declared in Pawn.Raknet include file as

        enum PR_SpectatingSync
        {
            PR_lrKey,
            PR_udKey,
            PR_keys,
            Float:PR_position[3]
        };

And have packet ID 212

All RPCs connected with spectating is only for linking one player to another player or vehicle while this player sending spectator sync by himself (even if PlayerSpectatePlayer/PlayerSpectateVehicle were not applied for him).

[ADRFranklin]

I will add support for this, I still need to know if the plugin is working as expected for you. At least than I am okay to move forward.

This shouldn't be too hard to implement, looking at the struct itself, it's simple. I've just had a thought. There might be an issue with Freezing data, since it doesn't freeze one one packet, it freezes them all. I will add a fix for that now, which means deprecating the old freeze native in favor of the new one that allows types to be used.

[NexiusTailer]

Well, currently there are the following things:

1. Adding similar native for FreezeSyncData as well as its done for SendLastSyncData would be great
2. A little typo mistake in SKY.inc at the line "If an type is specified it will sync that packet only" :)

[ADRFranklin]

Thanks, I have fixed those issues. I have also added the Spectate sync for both Freeze and LastSend.

Could you test these to make sure everything is okay :) release-windows.zip release-linux.tar.gz

It's annoying Github won't met me upload .inc files, so had to zip it :( SKY.inc.zip

[NexiusTailer]

Seems like it's the old plugin version

[22:46:18] [debug] Run time error 19: "File or function is not found"
[22:46:18] [debug]  FreezeSyncPacket
[22:46:18] [debug] Run time error 19: "File or function is not found"
[22:46:18] [debug]  FreezeSyncPacket
[22:46:18] Script[gamemodes/nex-test.amx]: Run time error 19: "File or function is not found"

[ADRFranklin]

Errm, this is working for me just fine? Are you sure you have updated the plugin?

[NexiusTailer]

Sorry, it was my mistake because of mess up with YSF/SKY typed in the server.cfg, so that loads fine. But despite this there are some problems with FreezeSyncPacket: if I freeze the player and apply for him

FreezeSyncPacket(playerid, E_PLAYER_SYNC, true);

or such way

FreezeSyncPacket(playerid, _, true);

The frozen player who is onfoot at the moment keeps moving around but without any animations (it feels like this player just slides on the ground)

[ADRFranklin]

I'm not entirely sure what causes that issue 😕

[ADRFranklin]

wait, so the issue is when frozen, animations are not applied, is that the only issue?

[ADRFranklin]

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

@NexiusTailer Tell me if this fixes the animation syncing issue

[NexiusTailer]

wait, so the issue is when frozen, animations are not applied, is that the only issue?

Made some video to show how it looks like (sorry for 640x480, it is just for the fastest rendering): https://imgur.com/qsJhccd

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

@NexiusTailer Tell me if this fixes the animation syncing issue

As for it, I'll retest it now and check if the problem was fixed, thanks.

[NexiusTailer]

Hm, the problem still occurs, unfortunately...

[ADRFranklin]

Does the issue occur when using the old native?

[NexiusTailer]

So strange, but yes, it occurs also with FreezeSyncData and at the same time the problem remains on the previous SKY version from the release section (v2.1.1). As far as I remember I tested it about 3-5 months ago and it worked well, despite the fact the player didn't be desynced (freeze-synced) when he changed his sync type (get veh or something like that), but it was just the limitation of original FreezeSyncData.

[ADRFranklin]

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

I might have found the issue, hopefully 🤞

[ADRFranklin]

@NexiusTailer any luck yet?

[NexiusTailer]

The problem still remains for now (checked with FreezeSyncPacket)

[ADRFranklin]

I don't know what is causing it, I checked both the PacketList and Pawn.Raknet to see if I have missed anything, and I haven't it all adds up. :(

[NexiusTailer]

I’ll try to check the old releases of the plugin to find out how long and with what version the problems started. Perhaps this will reduce the problem search area.

[ADRFranklin]

Yeah, that would be helpful thanks.

[NexiusTailer]

So finally I found from which version the problem starts: v2.0.0. When I tested it on 1.1.0, there was no problem with the function, but it just stopped working from the next update.

[ADRFranklin]

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

There is literally minimal difference between the 1.1 release and any releases after that with FrozenSync, so the only change that was made was the positioning of a certain check that was moved above.

If this fails, than I am really unsure as to what has caused it.

[NexiusTailer]

No, this doesn't help. While I was thinking about it I tested it both on 0.3.7-R2-1-1 server version and 0.3.7-R3, but the result as in previous cases...

[ADRFranklin]

I'm not sure that helps us solve this :( Have you tried 0.3.DL? is it possible it's an issue with the 0.3.7 structs? or is the same issue appearing there too?

[ADRFranklin]

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

Okay I think I found the issue, thanks to Y_Less pointing out a very important mistake. So hopefully this is all done now.

[NexiusTailer]

Yeah, that's finally okay. Thank you!

[NexiusTailer]

And I have another idea: maybe it would be wise to add to this enum:

enum E_SYNC_TYPES
{
    E_PLAYER_SYNC = 0,
    E_AIM_SYNC,
    E_VEHICLE_SYNC,
    E_PASSENGER_SYNC,
    E_SPECTATING_SYNC
};

Another, the last type E_ANY_SYNC or something like this to be able to freeze the player sync from exactly that packet type which he sent before this function applied (so that the player couldn't change his sync type while his sync frozen and, for example, being "frozen-synced" onfoot and getting into a car after it will not affect other players seeing him in the vehicle as he would be still onfoot for them).

[ADRFranklin]

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.

[ADRFranklin]

Can you test it to make sure everything is good and report back? If all is good I will make a new release for it.

[NexiusTailer]

So after the test I found that the previous problem started to occur again: player moves around for others even his sync is frozen using E_ANY_SYNC.

[ADRFranklin]

@NexiusTailer Can you try the latest release?

[NexiusTailer]

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.

I have tried this release.

[ADRFranklin]

Oh, errm. Okay. How is that possible? Does it only happen with E_ANY_SYNC ?

[ADRFranklin]

@NexiusTailer LOL, I forgot to tell you I changed E_ANY_SYNC to E_LAST_SYNC :D

[NexiusTailer]

Oh, errm. Okay. How is that possible? Does it only happen with E_ANY_SYNC ?

Yeah, the problem occurs for E_ANY_SYNC only and there were no such cases for E_PLAYER_SYNC as I tested it just now.

@NexiusTailer LOL, I forgot to tell you I changed E_ANY_SYNC to E_LAST_SYNC :D

But I still have E_ANY_SYNC in SKY.inc in this enum, so I suppose this enum element should be passed to the plugin as a regular int number, isn't it?

[ADRFranklin]

@NexiusTailer How are you using it? Like are you still toggling it?

[NexiusTailer]

Just this way for freezing:

FreezeSyncPacket(playerid, E_ANY_SYNC, true);

and this for unfreezing:

FreezeSyncPacket(playerid, E_ANY_SYNC, false);