{{Delete}} I'll assume you've already read the <page>Prediction</page> page and you've got a vague idea of what it is, most of these prediction examples assume you already know the base of coding a weapon/entity and know what the drive system is. This page is here to make use of that giant wall of text and to explain what the heck is going on in practice. The main principle of prediction as explained earlier is to have a simulation of what's going to happen before the server does, aka you just call everything **shared**( with a few exceptions ). If it wasn't clear enough, prediction breaks easily, and in case of entities ( and weapons ) only one can be predicted by a player at any time. Now, using normal variables is fine, but in case of prediction they're not sufficient because of prediction errors. In which case you have to use [Network Vars](/gmod/Networking_Entities) ( called dt vars internally ) , all the engine entities use these for networking and prediction. In which case you have to use <page text="Network Vars">Networking_Entities</page> ( called dt vars internally ) , all the engine entities use these for networking and prediction. In fact, if you've made a scripted weapon before, chances are you're already using them, functions such as <page>Weapon:SetNextPrimaryFire</page> , <page>Player:RemoveAmmo</page> access predicted DT vars, defined in the engine. <note>Can't stress this enough, due to prediction all the functions shown here are defined on both states, sans a few exceptions.</note> <note>I'm not going to add all the SWEP/ENT variables here, this is merely an example.</note> # Weapon Prediction This is pretty straight forward, to start with, you'll define your needed Network vars as explained in the page above. ``` --TODO function SWEP:SetupDataTables() end function SWEP:Think() end function SWEP:PrimaryAttack() end ``` # Movement Prediction As good as the drive system might be, with the way it's coded it only allows for one movement override at a time. Directly hooking the movement hooks allows us to modify the behaviour and make it somewhat compatible with others. Now, it's best to actually couple this with a predicted entity ( such as a weapon, or look below for another example ), seeing as for instance, on a jetpack we may want to handle fuel. Saving variables onto the player ( entity specific stuff such as fuel, entity references are fine ) should only used as a last resort, especially if it can be avoided. ``` hook.Add( "Move" , "Movehook test", function( ply , mv ) end) ``` # Entity Prediction Note, this stuff is kind of advanced This kind of prediction is already used internally for weapons, but here we can have more freedom, such as being able to create a weapon-like entity that can be used at anytime. The way we're gonna do the prediction is to run the logic in the Player's Tick hook, and not trough the entity's Think. To actually mark an entity as predictable, and allow DT vars to be restored on a prediction error, we need to use <page>Entity:SetPredictable</page> on the client that we want to enable prediction on. There's currently no getter to know if an entity is already predictable, and we need it to avoid the DT variables from being reset everytime the function is called, so excuse the crude hack below. This is an example for a predicted entity base, which you can derive from or use directly. <note>The main checks are done on the controlling player DT var because Set/Get Owner/Parent are used mainly for collisions, and external tools or addons might override them ( for instance the gravity gun sets the owner on anything it holds )</note> ``` --TODO: link to my github with the predicted entity base ``` This can also be coupled with the movement hooks, allowing us to have predicted jetpacks or other movement modifying entities. # Drive System Prediction This might get considered as a duplicate of Entity Prediction, with the difference being that the drive system is only good to control an entity as if it was a vehicle, nothing can be ran along with the player as of YET. With drive, no player movement logic is ran from the engine, and thus we will need to handle the collisions on our own. Also stuff like enabling prediction on the entity is already handled internally. <note>This is much easier than Entity Prediction as you don't have to do as much stuff as that.</note> TODO: Visit <page>Entity_Driving</page> in the mean time. # Emitting Sounds during prediction If you've used the predicted entity example you might've noticed that sounds still emit twice, as if prediction didn't cull them. This is actually a problem in the <page>Entity:EmitSound</page> function which will be fixed at some point.