[9:42:20 AM] ViperMaul: By the way Jaynus, you have been doing some outstanding work on Arma Performance programming. Do you do any ongoing time syncing in JayArma2 pbo where I can learn your advanced methods?

Or for other topics any successful JIP syncing of anything where you think your methods could be a great example for the community to follow?
[9:42:46 AM] jaynus: Hrm.
[9:43:00 AM] jaynus: Jayarma2lib is capable of getting actual system time, which technically is more accurate for time syncing for in-game things but
[9:43:08 AM] jaynus: diag_ticktime extrapolation is just as accurate - just more difficult
[9:43:13 AM] jaynus: uhmm
[9:43:45 AM] jaynus: as far as JIP syncing goes, thats all been ACRE-intensive as far as fixing sync-bugs for the two major CITs I have right now:
1. JIPs at a distance dont exist to other players
2. JIPs randomly do not get proper variable syncs
[9:44:19 AM] jaynus: JIPs at a distance we fixed via propigating the objects manually via CBA events (e.g. all players send their own player object every 10 seconds or so, and everyone else adds them to a manual player list we mantain, and we dont use allUnits/playableUnits)
[9:44:27 AM] jaynus: JIPs randomly not syncing we fixed by persistant setVariable updates.
[9:44:43 AM] jaynus: E.g. for anything we do a setVariable on, we actually cache that locally on the client, and it gets "re-set" every 30 seconds
[9:45:01 AM] jaynus: e.g. every 30 seconds, each client automatically calls player setVariable ["foo", 12345, true]
[9:45:07 AM] jaynus: so as to make sure it re-propigates to JIPs
[9:45:55 AM] ViperMaul:  and we dont use allUnits/playableUnitsInteresting.
[9:46:08 AM] ViperMaul: No trust in those two?
[9:46:35 AM] jaynus: They are verified broken
[9:46:40 AM] jaynus: major ones are two scenarios:
[9:46:53 AM] jaynus: 1. the "Domi bug", which is that if you dynamically assign groups for units, they do not appear in allUnits/playableUnits
[9:47:08 AM] jaynus: 2. The JIP at a distance. If you JIP at > 7KM away from another player, you do not appear in the lists
[9:47:30 AM] jaynus: actually #2 let me rephrase
[9:47:32 AM] jaynus: if *YOU* jip
[9:47:44 AM | Edited 9:47:50 AM] jaynus: you do not appear in the *other* players lists, until you come to within < 7KM of them
[9:47:57 AM] jaynus: Both of those we solved using our own playerLIst
[9:48:09 AM] jaynus: which is basically all players, every 10 seconds, do a CBA_fnc_globalEvent; sending their player object
[9:48:19 AM] jaynus: which then we use a acre_sys_core_playerList global object to track (our own version of playableUnits basically)
[9:49:27 AM] ViperMaul: This makes sense actually. BIS must be using a trigger that only covers 7KM.
I onced used a trigger that dynamically covered the size of any island. At least I think I did.  I am guessing this is how you did it with your own PlayerLIst
[9:49:49 AM] jaynus: naw our playerlist is literally an XEH_post_init spawn
[9:49:51 AM] jaynus: that is just
[9:50:50 AM] jaynus: [] spawn {
    while { true } do {
         if(alive player) then {

               ["acre_syncPlayer", [player]] call CBA_fnc_globalEvent;
         };
         sleep 10;
     };

}
[9:51:13 AM] jaynus: Then all other clients receive the event, and manage their own local player list
[9:52:15 AM] jaynus: Oh. and we decided on just persistant 10-second messages instead of on-demand cause then JIPs in high-count scenarios would desync the server
[9:52:33 AM] jaynus: cause then youd have someone jip, send a "requestAllPlayers" event, and then the network would get spammed with like 70 CBA events on every JIP
[9:52:52 AM] jaynus: So we opted for a delay-based system instead, where we can garuntee a JIP has gottan all player objects after 15 seconds in game
[9:53:23 AM] jaynus: All of that is still not as bad as the setVariable issues with JIPs though :/
[9:53:31 AM] jaynus: You can have players in your player list that still dont propigate their variables to JIPs
[9:53:39 AM] jaynus: hence why we also had to do a bunch of persistant setVariables for random shit
[9:53:49 AM] jaynus: cause literally just randomly, in the A2 engine, the setVariable just "wont" propigate to a JIP
[9:54:17 AM] ViperMaul: To reduce net traffic, Have you experimented with this from XENO
http://dev-heaven.net/docs/cba/files/network/fnc_setVarNet-sqf.html
[9:54:22 AM] jaynus: yah
[9:54:28 AM | Edited 9:54:33 AM] jaynus: thats what broke ACRE 1.3 / 1.3.1
[9:54:40 AM] jaynus: because of...
[9:54:45 AM] jaynus: [9:54 AM] jaynus:

<<< cause literally just randomly, in the A2 engine, the setVariable just "wont" propigate to a JIP
[9:54:51 AM] jaynus: So for example, inside acre, we do
[9:55:05 AM] jaynus: player setVariable ["acre_sys_core_ts3id", 12345, true];
[9:55:22 AM] jaynus: when we switched it to [player, "acre_sys_core_Ts3id", 12345] call CBA_fnc_setVarNet;
[9:55:24 AM | Edited 9:55:27 AM] jaynus: it broke
[9:55:40 AM] jaynus: Because in all the scenarios that object variables didnt propigate for JIPs correctly, setVarNet never resent it
[9:55:43 AM] jaynus: so JIPs are basically fucked
[9:55:59 AM] jaynus: which made us move back to enforced setvariable[true,true] calls
[9:56:03 AM] jaynus: forcing network propigation every single call
[9:56:14 AM] jaynus: General symptom being:
[9:56:20 AM] jaynus: If you have JIPs, setVarNet is fucked and dont touch it
[9:57:02 AM] ViperMaul: Hmm...
[9:57:10 AM] jaynus: Basically what setVarNet does is
[9:57:22 AM] ViperMaul: It makes me wonder how long a JIP remains classified as a JIP player.
[9:57:25 AM] ViperMaul: You know what I mean?
[9:57:36 AM] jaynus: it checks *locally on your client* if you've already set that variable on the object. if the variables dont match, it propigates it again (setvariable true true) otherwise, it doesnt.
[9:57:47 AM] jaynus: Well, A2 doenst do persistant updating so what you run into is.
[9:57:47 AM] ViperMaul: a JIP player is only a JIP player for the first X seconds right?
[9:58:02 AM] jaynus: 1. Player A is already in game, does setVariable "foo" on themselves
[9:58:11 AM] jaynus: 2. Player B JIPs, and because of random A2 bug, does not propigate the "foo" variable for A
[9:58:26 AM] jaynus: 3. Player A calls "setVarNet" again on "foo", but never does a netowrk propigation because player A sees the variable as already set
[9:58:42 AM] jaynus: End result: PLayer B never gets the variable "foo" because it didnt sync correctly, and A never re-sent it after B joined
[9:59:00 AM] jaynus: Basically a JIP player is a player that JIPed
[9:59:03 AM] jaynus: theres no "sync time on it"
[9:59:13 AM] jaynus: Theres so many bugs surrounded JIPing, that you need to consider a JIP player throughout *everything*
[9:59:32 AM] jaynus: basically, *ALL* actions that were performed prior to a player JIPing, need to be considered to resync on the JIP
[9:59:51 AM] jaynus: Prime examples: building destruction, variable syncing, distant objects disappearing, etc
[10:00:28 AM | Edited 10:00:39 AM] ViperMaul: Can we put in a hack for the "setVarNet" that check for new JIPers and if new then send one normal setVar [true,true]?
[10:00:42 AM] jaynus: Your doubling net traffic for that basically
[10:00:55 AM] jaynus: Because then you'll need to send "Yo player b, did you already get X value for player A?"
[10:01:02 AM] jaynus: "yo player A, NOPE, send it"
[10:01:03 AM] ViperMaul: But you are doing it any way by using setVar[true,true] every 10sec right?
[10:01:13 AM] jaynus: correct
[10:01:14 AM] jaynus: so instead of the above
[10:01:17 AM] jaynus: its just
[10:01:22 AM] jaynus: "PLAYER A SETTING VARIABLE AGAIN K THX"
[10:01:22 AM] jaynus: every 10 seconds
[10:03:06 AM] jaynus: That all make sense?
[10:03:16 AM] jaynus: Basically once your needing to "verify" a sync, its pointless
[10:03:20 AM] jaynus: may as well just force a resync
[10:03:45 AM] jaynus: Then you have the issue of the fact you cant identify a JIP really from remote clients, only the local client knows hes a JIP
[10:03:59 AM] jaynus: so the JIP needs to send "HI IM A JIP"
[10:04:03 AM] jaynus: then you get a massive sync flood
[10:04:13 AM] jaynus: (already exhibitied in red/yellow chains on JIP > 30 players)
[10:04:41 AM] ViperMaul: Exactly, I just read your last msg after typing the following....

Is there any way to find the best of both worlds?
Where the Sync module uses setVarNet method to reduce traffic but when there is a JIP player detected then pulse one reg setVar [True,True] then go back to the net traffic saving methods of setVarNet until another JIP comes in?
[10:05:37 AM] ViperMaul: But there is a way for detecting the new player with adding a broadcast of the "Hi IM A JIP" right?
[10:05:54 AM] ViperMaul: You said you solved that problem with XEH
[10:06:07 AM] jaynus: Yah, but just with a persistant sending of variables
[10:06:21 AM] jaynus: Which overall increases bandwidth usage, but overall *decreases* desync
[10:06:35 AM] jaynus: Because we are distributing object syncing across a 10 second - 2 minute wiindow
[10:06:44 AM] jaynus: Rather than a "ON JIP, FUCKING FLOOD BITCHES!"
[10:07:01 AM | Edited 10:07:08 AM] ViperMaul: Well that is what we want most in the end anyway.
LESS DeSYNC
[10:07:19 AM] ViperMaul: Cool
[10:08:16 AM] ViperMaul: I am working for Dslyecxi and ShackTac doing research for how to add weather sync function for JIPers as well as existing players.
[10:09:02 AM] ViperMaul: And I don't want my inexperience to cause problems. Plus you know how Dslyecxi is with allowing new features to desync our ST Sessions. :)
[10:09:25 AM] ViperMaul: So I figure I research the best minds in Arma that I know.
[10:09:57 AM] ViperMaul: My first thoughts where You and Nou, and Xeno.
[10:10:42 AM] ViperMaul: So your methods here should work well with Weather Sync right? Any thoughts or caveats you can think of that I should be concerned with?
[10:11:14 AM] jaynus: afaik nou already wrote weather sync into ACE tho
[10:11:17 AM] jaynus: may want to check with him on that
[10:11:35 AM] jaynus: But yah, its the (generally, in our experience) 100% best possible way to handle JIP syncing
[10:11:41 AM] jaynus: since it distributes it and spreads it out, so shit doesnt fall over
[10:12:15 AM] jaynus: anyways afk gotta bolt for a meeting
[10:12:28 AM] ViperMaul: Thanks for your VALUABLE TIME jaynus!!

                                     ***

[2:43:32 PM] jaynus: Back by the way if you had more questions heh
[2:43:57 PM] ViperMaul: welcome back
[2:44:30 PM] ViperMaul: Let me think while I finish this late lunch on the stove.
[2:44:41 PM] ViperMaul: SB says Nou did a ACE Wind Sync.
[2:46:00 PM] ViperMaul: GlobalEvent is probably just another method of working with addPublicEventHandler if I dig in the CBA code right?
[2:46:17 PM] jaynus: Yah correctly, its pub event handlers for all the events
[2:46:33 PM] jaynus: think of it as just an event system like any other language. cept it works, and thankfully suffers from no other engine bugs
[2:48:37 PM] ViperMaul: old methods used SVIs. Are SVIs considered evil now and we should seek them out in our old code and destroy them?
[2:48:54 PM] jaynus: correct, SVI's are a big big no no because they propigate all changes on JIP
[2:49:01 PM] jaynus: so if you do 3 SVI's, those 3 different SVI instances sync on JIP
[2:49:21 PM] jaynus: well lemme rephrase that
[2:49:33 PM] jaynus: If you do 3 SVI's during the course of a game, then someone JIPs, that person gets all three SVI's in order
[2:49:47 PM | Edited 2:50:03 PM] jaynus: while PVEH is just "during the course of being in the game you receive current changes"
[2:50:47 PM] jaynus: Hope that makes sense. its basically just dont touch SVI
[2:51:37 PM] ViperMaul: oh yes it makes sense
[2:52:16 PM] ViperMaul: and that one command never works removeVI
[2:52:31 PM] ViperMaul: at least I have never seen evidence that it works.
[2:52:49 PM] jaynus: Nah, never seen it work and really overcomplicates it from a usage perspective
[2:53:21 PM] jaynus: Cause you either wanna run things:
1. on init (XEH pre/post or mission init)
2. on events in game (XEH handlers, addEventHandler)
3. on scripted events (globalEvent/remoteEvent/localEvent)
[2:53:38 PM] jaynus: oh, or
4. whenever the fuck you want (script loops)
[2:54:00 PM] ViperMaul: Actually it is called clearVehicleInit
[2:54:29 PM] jaynus: afaik it suffers from extreme locality issues
[2:54:37 PM] jaynus: cause of driver ownership of vehicles and all that fun jazz
[2:55:39 PM] jaynus: but really, from as far as I can tell, the only modern (lulz) reasons to use SVI is either for inits (replaces by XEH inits and mission init lines) or for cheating (broken in latest server versions)
[2:55:58 PM] jaynus: e.g. cause all replaced by either CBA XEH, mission init crap, or some other custom init handling
[2:57:22 PM] ViperMaul: The only reason why I wanted to use it was to run code on the server. For example, back in the old days if I wanted spawn an empty vehicle on the server so that it is synced to all players.
[2:57:50 PM] ViperMaul: That was 3 years ago.
[2:58:49 PM] jaynus: Yah now you'd want to have 2 portions of code, one on server one on client, server is a CBA_fnc_addEventHandler; and the client sends a CBA_fnc_globalEvent calling the event
[2:59:02 PM] jaynus: assuming you are willing to use CBA; can accomplish what it does with PVEH
[2:59:28 PM] ViperMaul: I heard you can just spawn it on your client and do a setPosASL getPosASL on the object and it will sync for all nodes.
[2:59:45 PM] jaynus: shrug, maybe you can, I wouldnt trust it tho
[3:00:04 PM] jaynus: Cause your client doesnt *actually* own a vehicle unless your a driver (example for vehicle anyways)
[3:00:10 PM] jaynus: or your client doesnt own AI unless they are in your group
[3:00:12 PM] ViperMaul: ACE uses it for bullets
[3:00:24 PM] ViperMaul: I cannot remember the total context though
[3:00:28 PM] jaynus: Ah yah
[3:00:35 PM] jaynus: that was the grenade/grenade launcher problem
[3:00:39 PM] ViperMaul: yeah!
[3:00:43 PM] ViperMaul: That was it.
[3:00:46 PM] jaynus: with off-sync landings for HEDP/smoke rounds
[3:00:59 PM] jaynus: that was cause projectiles behave different
[3:00:59 PM] ViperMaul: that was a funny site to see
[3:01:02 PM] jaynus: They are local for all clients regardless
[3:01:08 PM] jaynus: e.g. when you shoot
[3:01:16 PM] jaynus: all clients actually spawn a different object (local only)
[3:01:35 PM] jaynus: with vector data and (configs obviously), which then means it has a deterministic end state
[3:01:36 PM] jaynus: heh
[3:02:19 PM] ViperMaul: ah that triggered a thought. I hope Arma3 AI are more realistic and less superhuman about seeing you and shooting you through forests and trees.  But I digress.
[3:03:10 PM] jaynus: Yah im excited about that cause physx should cover all that
[3:03:21 PM] jaynus: as long as they basically turn on the feature, it automagically does LOS and shit for complex terrian
[3:04:32 PM] ViperMaul: very cool
[3:06:14 PM] ViperMaul: Have you ever tried to measure how much net traffic is cause by using 10 second setVar verses at 1 second and tried to extrapolate for the number of players on a server?
[3:07:05 PM] ViperMaul: If you know what I mean.
I tried once but I either don't have enough debug info or I don't have enough skills to do so.
[3:08:47 PM] jaynus: ugh a long long *LONG* time ago
[3:08:49 PM] jaynus: Rommell actually
[3:08:55 PM] jaynus: ran a bunch of benchmarks on massive setvariable stuff
[3:09:04 PM] ViperMaul: Ha! it would be Rommell. I miss that guy.
[3:09:07 PM] jaynus: turned into something like 10,000 setvariables over 10 clients a second before we desynced
[3:09:16 PM] jaynus: some insane number like that
[3:09:28 PM] jaynus: Either way its one of those things that either way, its on-demand
[3:09:30 PM] jaynus: so you hvae 100% control of it
[3:09:35 PM] jaynus: so if it breaks things - you fucked something up
[3:11:32 PM] ViperMaul: So with respect to Desync, there should be less worry about creating too much net traffic through setVar Publics which are probably just another version of PubVars and more worry about something esle, whatever that may be. I am at loss to what to call it currently... right?
[3:12:12 PM] jaynus: Yah with desync, usually your #1 issue is going to be server-side script performance and number of objects
[3:12:41 PM] ViperMaul: And something to do with how JIP is handled as well?
[3:13:05 PM] jaynus: that all ties into object numbers really, thats where your desync will happen there
[3:13:22 PM] jaynus: So like at 50+ players, you'll get JIP desync regardless, its unavoidable
[3:13:29 PM | Edited 3:13:34 PM] jaynus: even with *just* 50 players, no objects, no AI, you desync
[3:13:47 PM] jaynus: (Which is really because your running into a n ^ x sync issue)
[3:14:49 PM] ViperMaul: can that be improve with improvements in the net code by BIS if they worked at it?
[3:19:16 PM] jaynus: Yah I've got a few CIT's about it, and been using a few of the channels to try to filter things through to suma/fireball about it
[3:22:22 PM] ViperMaul: aye
[3:22:40 PM] jaynus: Right now seems a lot of it though we are still on the "fix whats broken phase"
[3:22:46 PM] jaynus: before they can get to the "optimize whats there"
[3:22:46 PM] jaynus: heh
[3:23:19 PM] ViperMaul: heh
[3:24:11 PM] ViperMaul: and yet new features are what sells the next offering of games. Its hard to get them to give wholesale focus on fix what is broken.
[3:25:32 PM] ViperMaul: I wish they would add timestamps to the client side log so it makes it easy to match them up with server side logs so we can troubleshoot better.