Support thread - shooter bp project

Community Marketplace
1

Welcome to the project’s support thread! Feel free to post questions, feedback, issues, etc!

Project updated. Change log:

  • Materials and textures redone for the main mesh and the handguard mesh - the new material has customizable wear and dirt, separated masks for metal and polymer parts, etc. (the other meshes will also get updated materials of this new standard on future updates).

  • Handguard is now a separated mesh from the main mesh

  • Small refinements in the geometry at the forward assist area

  • Updated the method for hiding/unhiding crosshair when aiming down sights

  • Play rate of walk and run anims are now variables

  • Fixed sRGB setting on mask textures - now mask textures are RGB instead of sRGB

Project updated. Change log:

  • Incorporated the sight alignment code from the Gun Sight Auto-Aligner 16, which means now there’s no need for the Aim anim sequence and the AimFire (fire while aiming) anim sequence. (The previous alignment method used was the precursor of the Gun Sight Auto-Aligner asset).

  • An IK was added to the right hand, so now both hands have an IK.

  • Added a debug external camera for checking hands/arms position.

  • Changed method of identifying the gun’s main mesh. Now, instead of giving the component a specific name, you give it a specific tag.

  • Material and textures for the FlipSightRear were redone in the new standard.

  • Fixed: if weapon had different fire rates for different fire modes, changing fire mode would change fire rate but not play rate of the fire anim.

Project updated. Change log:

  • Material and textures for the magazine were redone in the new standard, which includes configurable wear and dirt.

  • Included customization for the dot reticle color, size and intensity.

  • Moved show/hide HUD dot aiming reticle functionality from the anim blueprint to the HUD widget blueprint.

  • Reorganization of the folder structure.

Project updated. Change log:

  • Fixed: on-screen tip about input keys for jump and fire (WB_DemoHud blueprint) were missing their respective keys (this would generate message log errors when playing in “New Editor Window”).

  • Added: Suppressor attachment.

Known current issue: crosshair will not hide properly when the aim down sights button is pressed during a very short period of time (a few milliseconds) while blending at the end of the Equip anim sequence. This is due to the respective transition notifies in the State Machine not getting fired in this situation. This will be fixed.

Project updated. Change log:

  • Implemented replication (1st iteration)

  • Included Epic’s SK_Mannequin (entire body) with animations, aim offsets, etc. for the purpose of testing replication

  • Implemented simple crouch mechanics (1st iteration) for the purpose of testing replication

  • Included simple shot impacts and gun muzzle effects (particles) for the purpose of testing replication

  • Generated LODs inside the Unreal Editor for the parts of the gun that are static meshes (not yet for skeletal meshes)

  • Added angle limits for the cosmetic gun rotations, to avoid the HUD dot reticle being drawn out of the sight lens at extreme rotations

  • Updated to UE4 v4.23

Project updated. Change log:

  • Tweaked the auto-aligning and cosmetic gun rotations method. It now uses less nodes and is easier to control, since now the location/rotation of the sight’s aimpoint is directly controlled by a bone (sight’s location/rotation is the same of the bone).

  • Aiming is no longer a separate state in the state machine. In order to allow for variable aiming down sights speed, aiming is now implemented through BlendPosesByBool nodes inside other states.

  • Added customization variables for aiming down sights speed and cycle between sights speed.

  • Added customization variables for the amplitude of the procedural animation for firing while aiming down sights.

  • Fixed the issue of crosshair not hiding properly if the aim down sights button was pressed during a very short period of time (a few milliseconds) while blending at the end of the Equip anim sequence.

Project updated. Change log:

  • Fixed a bug included in the last version where using other anims instead of the provided ones would make the transition form hip to aiming down sights very jumpy. It was due to an accidental unchecking of a checkbox in one of the CopyBone nodes in the anim blueprint.

  • Other minor fixes like text tips on screen, etc.

Included, in the product page, a link to download a playable demo

Project updated. Change log:

  • All first person anim sequeces were reimported. The new sequences have the hand IK bones (ik_hand_gun, ik_hand_r and ik_hand_l) stationary at the default position (Epic’s default pose). The old sequences had ik_hand_gun and ik_hand_r match hand_r position, and ik_hand_l match hand_l position every frame. This change was made to avoid blending problems when adding user custom animations. It makes no difference if you use all sequences with the IKs in the default position or all sequences with the IKs matching the hand bones, but a mix of sequences of the two styles gives blending problems. Since most custom sequences out there leave these IK bones stationary at the default position, now they can be mixed with the asset’s own sequences without blending problems.

  • Removed custom object channels and trace channels (collision) presets from the Project Settings, because they were unecessary.

  • Not all CopyBone checkboxes were fixed in the last update, which was meant to fix them. Now they all were fixed.

Project updated. Change log:

  • The cosmetic gun rotations (sway) due to player input now only use the aimpoint as pivot when aiming down sights. When not aiming, the rotations use the hand_r bone as pivot, like it was before, because it looks better when not aiming.

  • Fixed an issue that would prevent animations from being played correctly if the semi-auto mode was set as the starting fire mode.

Project updated. Change log:

  • Updated to Unreal Engine v4.24

  • Small change in the method of calculation of ironsights. It now uses the node FindLookAtRotation followed by roll adjustment, instead of the dot products, RotationFromAxisAndAngle and CombineRotators nodes to find the direction from rear sight to front sight. The new method works better with the change implemented before (that would let the rear sight a bit off depending on its location on the gun in relation to the front sight)

Project updated. Change log:

  • The name of the product was changed from “BP FPS Assault Rifle” to “Gun Assembly System”, to reflect the fact that the asset now allows building other guns too instead of being restricted to the original assault rifle

  • Implemented an UI widget (WB_Armory) that allows players to build guns with parts provided by you

  • Guns are now made of individual actors attached together, instead of components of one single actor

  • The gun mesh component isn’t a ‘PoseableMesh’ component anymore. It’s now a ‘SkeletalMesh’ component, with it’s own anim blueprint. This means the gun blueprint now can be used with any mesh, since it now doesn’t need to have the bone names hardcoded in it

  • Removed the option to use a HUD optic reticle as if it was the gun sight reticle. Now only reticles placed on the gun sights themselves are used, which avoids the need to set individual movement limits for each gun in order to prevent reticle being drawn in the air outside the gun sight. HUD reticles are not needed anyway, since the sight auto alignment already centralizes the sight’s aimpoint in front of the camera

  • The HUD widget functions that get the player input keys (for showing them on screen as tips) now don’t execute every tick anymore. Instead, they now only execute once at game start

  • Replaced the 3rd person anim montages with 3rd person anim sequences

  • UnEquip and Equip anims won’t play anymore when player tries to switch weapons if there are no weapons to switch to

Project updated. Change log:

  • Fixed: lack of smoothness when cycling between sights while aiming. Before, the interpolations were done through a Timeline in the character and the resulting values were applied in the EventBlueprintUpdateAnimation of the anim bp. Now everything is done in the anim bp, which fixed the lack of smoothness.

  • Deconflicted keys for rotating the gun and opening the customization menus in the Armory. Rotations are now done with the right or middle mouse buttons, while opening the menu is done with the left mouse button. This prevents opening menus accidentally while trying to rotate the gun.

  • Implemented an interface in the HUD for developers to adjust on the fly the max angle allowed for gun sights to be used for aiming (Developer Tools widget). Some guns have rails underneath (and in other places) that allow the placement of sights, but sights in those places yeld ugly arms poses when aiming.

Project updated. Change log:

  • Reduced number of nodes in the sight alignment code and in the interpolation when cycling between sights while aiming.

(The name of the product was changed from “Gun Assembly System” to “FPS Assemblable Gun”)

Project updated. Change log:

  • Character was updated to true first person view - now it has a single mesh (whole body) with a 1P camera attached to the head. Only one anim BP and only one set of anims. No more arms-only mesh and anims.

  • Many new original anim sequences and blendspaces for the Epic’s mannequin were added. These were made with true 1P view and 3P view simultaneously in mind, so they work for both.

  • Third person camera was added

  • The M4 rifle meshes were scaled up so they look better in the mannequin’s big hands!

  • Changes in the firing logic and anim simplified the code significantly, without reducing it’s looks and movements

  • Firing anims don’t need to be fed with custom play-rates anymore, they now work correctly with a play-rate of 1

  • Removed procedural fire anim for firing while aiming. Now firing uses the same anim sequence for both hip fire and aiming fire

  • Added reload while aiming, without the need for additional reload anims.

  • Gun sight position is now replicated, so you can see exactly which sight the other player is looking through

  • Gun and attachments now cast shadows

  • Added screen shake when firing

  • Added procedural aim sway (from a curve) when walking

  • The anim graph is more streamlined now, with the sight alignining code separated from the state machine

Project updated. Change log:

Quick fix - external cameras “snapping” when crouching/uncrouching - external cameras are now connected to the mesh component, instead of the capsule component

Project updated. Change log:

  • Character BeginPlay: no need to wait for the gun and all its attachments to spawn to execute any code anymore

  • Gun BeginPlay: no need to wait for the attachments to spawn to execute any code anymore

  • Simplified the BeginPlay code of the character and the gun BPs, without changing functionality

  • Removed the CheckPartsTimer, CheckAllPartsSpawned, etc. from the gun BP as they aren’t needed anymore

  • Simplified the switch weapons code and replication, without loosing functionality

  • When not in use, guns now stay visible and attached to the character’s body!

  • Project updated. Change log:

Just a quick change of the floor material to make it clearer to see animation and foot movements, while I’m still working on the gun customization update…

Project updated. Change log:

  • Armory room is no longer necessary and was removed. Gun customization is now done at any moment during gameplay, with parts present in the player’s inventory

  • Simplified player spawn code and spectator is no longer necessary

  • Simplified gun and attatchments spawn code

  • Added a gun parts inventory to the character, but items can’t be dropped or picked up yet (but are spawn with the character)

  • Added thumbnail pics for gun parts, that are now shown during gun customization, instead of the part’s name

  • Gun customization no longer happens only on client and is now fully replicated

  • Attachment on rails logic is now both simpler and more realistic

  • Attachment sockets nomenclature is now simpler

  • Markers for attachment sockets are no longer spawn with the gun. They are only spawn when going into gun customization mode and destroyed when leaving it

  • Rear flip sight’s code for flipping up/down is now simpler

  • Button to change paint of gun and attachments in-game was removed. During customization, parts now have a thumbnail to show their paint before being added to the gun

  • Fixed: being allowed to fire while playing the UnEquip anim (glitch introduced with the full-body character in a past update)

Project updated. Change log:

Quick fix - when customizing the gun, it no longer can push map physics objects around when moving

Project updated. Change log:

  • Changed the amount of virtual bones on the character from 3 to 2 (removed the VB sight bone). This fixes an issue that some custom skeletons/anims had with the system. Also updated the related section of the instructions video

  • The function CalcSightsTransforms was changed and now it’s named CalcHandTransforms

  • For iron sights, now the center of mouse sway on the gun can be easily changed from the front sight to the rear sight in the blueprints, if preferred

  • Fixed log errors that would sometimes appear when trying to shoot, aim, etc. before the character was completely spawned in multiplayer

Project updated. Change log:

Turned off nativization in the project settings, as it can give errors in packaged projects

Project updated. Change log:

Fixed the engine crash when retargeting with virtual bones. Apparently the engine was fixed some time ago, but the mannequin doesn’t get fixed automatically. So what I did was I imported a new mannequin and replaced the old mannequin in the project.

NOTE: If you already have your system integrated in your project and don’t want to start the integration again with the new version, you can easily do the fix on your own project:

  • Create a backup copy of your project 1st of all
  • Create a new Third Person template in UE4 v4.24 or newer (might work with some older versions too, but I haven’t tested)
  • Migrate the mannequin (skeletal mesh, skeleton, materials, etc.) from the Third Person template to your project
  • Inside your project, copy/paste the sockets (Gun socket, Holster socket, etc.) from your old mannequin to the imported one
  • Add the 2 virtual bones to the imported mannequin
  • Delete your old mannequin skeleton and, when prompted to ‘Replace References’, select the imported skeleton
  • Delete your old mannequin skeletal mesh and, when prompted to ‘Replace References’, select the imported skeletal mesh
  • That should be all. Test by hitting the Play button and, if it looks broken, close and re-open the project

Project updated. Change log:

  • Fixed a small anim glitch when switching weapons at the moment that the corresponding character anims are switched. This became specially visible in UE5, but now it’s fixed for all versions.
5 Likes
6

Product updated (see change log)

7

This reply refers to v1.2.2 of the asset, which was before the implementation of replication. So, for v1.3.0 and forward, this reply is outdated!

In reply to Harri665 from the asset page in the Marketplace:

Add all the code highlighted in blue. This will insert another gun in the Inventory when you press T. It is added to the last position in the Inventory.

AddGunToInventory.jpg
AddGunToInventory.jpg1920×1080 314 KB

8

Product updated (see change log)

9

In reply to Harri665 from the Marketplace questions section:

Find this code in the B_GunProjectile blueprint:

Projectile.jpg
Projectile.jpg1920×1080 215 KB

If you want all cubes, make this modification:

Projectile2.jpg
Projectile2.jpg1920×1080 250 KB

If you want only some cubes in the map, click on each of them them in the map, go to the Details panel, Tag section and add the tag “Hitmarker”:

Cube.jpg
Cube.jpg1920×1080 267 KB

Then go back to the B_GunProjectile blueprint and do this modification instead:

Projectile3.jpg
Projectile3.jpg1920×1080 228 KB

I suspect that these cubes are not what you really want, so please tell me if you have something more specific in mind!

10

Is the character class contain 2 meshes one for fps view for owner and one for multiplayer or its running on a single mesh?

11

Currenlty it’s running two meshes, one for 1st person view and one for multiplayer. In the future this might be changed, but it wouldn’t be in a near future though…

Check this thread in the future, every change log is posted here, with links in the first post.

12

Product updated (see change log)

13

In reponse to Schytheron from the Marketplace page:

This asset has, besides, auto-aligning, much more stuff: fire modes, reloading (with animations), switching weapons (with animations), inventory, sprinting (with animation), customizeable gun materials, etc. It’s a weapon system, so it’s much more complex. The Gun Sight Auto Aligner has just the auto aligning part of this asset, so it’s aimed at those who already have their own weapon system and only need a solution for aligning sights. It’s not that much cheaper if you consider proportional amount of content (the BP FPS Assault Rifle has much more stuff), but its lower complexity will probably make your life easier if all you want is a gun sight aligning solution.

The only customization included out of the box for recoil is the amount. It works by adding pitch to the controller (thus, the camera) at each shot, then removing all the pitch it added once you stop firing. The amount added per shot is the customizeable variable and it doesn’t include any randomization (all randomization is in the spread). In order to create more complex recoil, I suppose you’d have to include some randomization and duplicate the code to yaw/roll too. You’d have to try on your end… That said, I can help through Discord, support thread, etc., if you encouter problems.

This is because it currently lacks any code to check fire button pressing intervals. It’s something that I might implement in the future (not near though), and I can’t promise…

You are able to adjust the sway for hip-fire and ADS individually and per axis for each one. You had the impression that they were the same in the demo because the values for hip-fire and ADS were left indeed very similar, but they are actually slightly different and separately configurable. But you actually never need to worry about moving the mouse too fast, because the ADS sway intentionally keeps the front post of the iron sight always in the center of the screen to serve as aiming reference 100% of the time. If it’s a dot sight, it’s the dot that’s kept in the center of the screen 100% of the time. Since shots come off from the center of the screen, you are always able to aim regardless of how fast you move the mouse and regardless of if it’s an ironsight or not.

In the future, I might change to shots that come off from the actual barrel, but if I do, the gun sway system and specially the dot placement will be revised to also behave realistically.

If there’s anything more you want to know, don’t hesitate to ask.

14

Won’t that make the aiming less accurate?

15

That’s a good question and that’s why I haven’t decided yet if I should implement this or not. From a realism perspective, I can claim it won’t be less accurate because shots will always be going where they would IRL while the sights will also always be pointing where they would IRL, considering I make the dot move to where it would IRL when the sight moves. For ironsights I don’t even have to do anything. It’s going to be harder to aim with ironsights, since the front post won’t serve as marker for the impact point anymore when the gun is swaying, but I will claim that this is exactly how ironsights work IRL and any deviation between the impact point and your sight point will be the same deviation that would happen IRL. Another thing that will make it harder to aim for both ironsights and dot sights is that aiming will no longer be 1:1 with mouse movement, since it will be decoupled from the camera. That’s why I’ll have to think of another kind of sway, because the current sway would make it feel like your aim is mouse accelerated.

Now this kind of change would make this asset less appropriate for skill-based flick shooters. For those, you really want some reliable marker on the screen all the time that will move 1:1 with your mouse. So that kinda holds me back when I think about implementing this, but honestly I’m gravitating more about taking the more realistic/tactical route than an arcade flick shooter route with this asset. I would really like to hear feedback, specially from owners of this asset, would they feel ok with this, because I personally feel the gains would outweight the losses.

16

Saw your auto align asset and then your gun. Decided to drop in and see what you had planned then saw your questions.

As someone who is a firearm junkie, and a developer who sells assets for UE4 I will give my advice here. Arcade style “games” are practically dead. Even COD uses more realistic gun handling now. I have never had a customer ask for more arcade features but constantly get requests for more sim features.

In modern games, bullets should ALWAYS fire from the muzzle as it keeps people from being able to just barely aim the camera (sight) over an object and fire safely while the actual muzzle is buried in a box or wall or something. This brings complications as you have to use zeroing. For raytraced bullets this isn’t such a huge deal as you can adjust the zero based on the cameras line trace and then fire the bullet from the muzzle to that point. But with projectiles people think they run into issues but in reality they don’t. Guns in the real world use projectiles and are only accurate at point blank and their zero. They shouldn’t be accurate at all distances.

The systems I have always designed worked like this.

Line traced bullets: Initial line cast comes from the camera and goes out to the hit point, As long as that hit point is greater than 2M then you align the muzzle to this point blank and fire the bullet in that direction from the muzzle. If it is less than 2m you just fire straight from the muzzle with no offset. This isn’t 100% realistic but its simple. In other words, aim the muzzle where the sight’s zero currently is and then apply your spread.

Projectile bullets: Initial line cast comes from the camera and goes out to the “Point Blank”, then you align the muzzle to this point blank and fire the bullet in that direction from the muzzle. Again its not realistic but in the real world guns are actually held aiming slightly upwards to align with the sight. For games we need to swap that for simplicity. In other words, aim the muzzle where the sight’s zero currently is and then apply your spread.

Hybrid System: Within 30m use hitscan method, if not hit then use projectile. This is great to lower network issues as you are firing less projectiles in CQC combat. There is also no reason to use a projectile <30m.

I uploaded an attachment that shows what I do. Yes I use the Red X method simply because its much easier and requires less hassle. The player will never notice the difference as the amount the muzzle gets canted upwards is relatively small (that image is an exaggeration). The first place the projectile crosses the “Line of Sight” is called point blank, the second is the zero point. For this example a scope zeroed at 200 will only be accurate at 50 and 200 using a correct projectile system.

image_174700.jpg

I also use dynamic zeroing based on the type of sight. Hipfire I change the zero between 15m and 30m based on what the camera trace hits (hipfire zero is a **** shoot because of the horizontal offset). Ironsights and Red dots/holo sights I zero at 50/200m. Scopes I zero at 100m. You can allow the player to do their own zeroing but even in games that have it (BF and PUBG) people almost never change their zero. You could zero everything at 100 but you will always be shooting low <100m with Red dot sights in that case. Its up to you to decide that trade off. General public knowledge of how guns work is so low that some people flat don’t understand why their 50m zero is shooting over the enemy’s head at 100m. Pubg got around this by zeroing everything at 100m i think.

The most annoying thing with zeroing and projectiles is that you have to manually zero your weapon sometimes. Though if you have your drag, speed, weight and gravity settings right the “Point blank” zeroing method gets you really close (still might have to do some manual muzzle tweaking). The issue you will find with point blank zeroing is a 100m zero pretty much has no point blank due to the trajectories flatness (top zero in the following image is 100m for an example).

mainqimg54a6d253d83ee2159d258ded42ec95a3.png

Its fine to have a small amount of animation sway in the idle animations but the actual sway system should move the CAMERA not just the gun. It should be script based and not animation based. Look at PUBG or COD for sway systems.

Anyways my long winded answer with way too much information to your question is to always try to make your guns as realistic as possible. Unless you flat don’t want to which is fine too :P.

Quick question though. If I use your gun align system on a tps character with no FPS mesh and used per bone blending for just the arms would it work? If I recall I also need to switch from tps camera to the FPS camera BEFORE allowing your system to aim for it to align correctly?

Good luck with your asset, I really dig your auto align system. Very cool.

17

Hey, thanks for all your suggestions and taking the time to post them with pics and all… From interactions with customers, I have the same impression as you, people seem to dig more the realism/tactical side of shooting than the arcade side. Now regarding the implementation, I have to say I wouldn’t do things like hybrid trace/projectile systems or auto-zeroing… I prefer a more direct approach: only projectiles and fixed or manual zero, or for a more arcade style, traces only…

Now, regarding your questions:

It’s hard to say without testing in your specific setup. I think it wouldn’t break the alignment, but that really wouldn’t mean much. I have experimented a little with this asset on a whole body mesh, and I can say that, while it’s relatively easy to preserve alignment and everything looks good while you’re in FP view, from an outside view the pose is broken and unusable. And it will take a good amount of time and effort to make it usable. And yes, you’d have to first move the camera to FP position before starting to aim (because an outsider would see your arms chasing the camera while it’s moving still), but that would be the least of your problems. It’s safe to say this asset, in its current state, doesn’t work for third person games and you should only try to work around this if you’re really willing to put a good amount of effort.

This is a recurring request from customers (which I think goes back to the point of most people preferring a realistic/tactical approach), so I feel tempted to actually take the time needed to include that in both my assets, it would probably boost the sales. But right now I can’t.

Thanks for your kind words… I don’t own a VR set yet, but it’s in my wish list. As soon as I get one, I’ll check your asset!

18

Product updated (see change log)

19

Product updated (see change log)

21

Hello, did you have an tip for me how two create that weapon swinging with the animation movement? I bought youre Kit on the Marketplace but need some more explanations how i could set this in a first person project in (The blank Project from Ue4 First Person). Which code is only two built for that ? An how could i Implement a Weapon Reload Animation for the Weapon? I am trying two juse other weapons like one from Ironbelly. It Would help me a lot. Youre code is very good but hard two understand.
Please write me back.

22

When aiming, the gun position at each frame is determined by the two variables IkLocationAiming and IkRotationAiming (in the 1st person anim blueprint). IkLocationAiming is the exact location of your sight and IkRotationAiming is the exact rotation of your sight. They are calculated each frame in the event graph of the anim blueprint, from the camera position, and applied to the gun (actually to the character’s hand) in the anim graphs of the idle and walking states (the only two states in which you can aim). If you want to make the gun swing, I would first try generating an offset (a vector variable) each frame to add to IkLocationAiming in the event graph. But from your question, I think what you want is a sway that’s not calculated, but comes from the underlying anim sequence instead? I think you will have to try using a CopyBoneDelta node, to copy the original movement from some bone to the hand or hand IK bone. Since I never implemented these kind of sways before, I’m sure they will require a good amount of testing and work.

This question I did not understand…

You mean animating the gun bones or the character bones? For the character, you just go to the gun’s blueprint and change the ReloadEmptySequence and the ReloadLoadedSequence variables (in the “Customization - Animations” category) so they point to your own anim sequences. If you want to animate the gun bones instead, currently the project doesn’t have good support for that. That’s because the gun actor component is currently treated as PoseableMesh instead of SkeletalMesh (but the gun mesh is still a skeletal mesh). This will be changed in the near future. With the PoseableMesh replaced by a SkeletalMesh component, a reload anim could be implemented by importing a reload sequence to the gun’s skeleton and playing it when the character plays it’s own reload sequence.

23

Hello, i have another Question. How the Character run with a server. I read about it in the AnimBP from the First Person? What i have to do to set an BP_Character with the running from a server on it? Sorry for my bad english but the logic only confuseing me a bit.:o

24

The AnimBP only does the animation. When you press Shift, the InputActionRun in the B_DemoCharacter blueprint is called on your machine, and this sends an RPC to the server (ServerRun). In the server, this RPC changes the MaxWalkSpeed of the character movement component. The MaxWalkSpeed is a variable that comes already with the Unreal Engine’s character and is automatically replicated, which means that when we change its value in the server, the new value is sent back to our client. The RPC also changes our variable IsRunPressed to True on the server, and this variable is also replicated back to the client. But this is a RepNotify variable, which means that every time it changes, the function OnRep_IsRunPressed is called (on server and clients) and inside this function you will see the code that tells the AnimBP (1st person and 3rd person) that IsRunPressed is now True. The AnimBP will then enter the state “Running” if the character is moving while IsRunPressed is True.

But on the client we don’t wait for these two values to arrive from the server, we go ahead and change them on the client before they arrive, so our character doesn’t feel laggy. When they arrive, they are set again but you don’t feel it because the values are the same. It’s just that the server must have the final decision. So please tell me if this answers your question.

25

It is. I be one of the types how wanna learn from these codes i sell on the Marketplace. I create a clean Project an wanna set it up as you code it. But my endresult is confuseing me.Look at the pic. I dont know why the character an the weapon aint communicate with eachother so that the weapon Spawn in the Hands an the animation get played from the anim_bp.