Basically im going to attempt to learn nearly every single thing documented on rlua before actually trying to make a real project myself and im quite confused about LinearVelocity
It seems that not only is it pretty delayed whenever i click a button (E in this case) but it also refuses to actually use my humanoids Look Vector whenever it is spawned for the first time after moving
I’ve looked around on the Forum and it seems some people say that the delay in spawning is simply a downside to using LinearVelocity and i would like to know if this is truly the case.
Please do not ask people to write entire scripts or design entire systems for you. If you can’t answer the three questions above, you should probably pick a different category.
The reason its delayed is probably because of latency. The server gets the signal a little later after you press the “E” button.
Also ive been through this before, thinking i could use roblox physics for projectiles on the server. In general you want the shot replication to be on the client (because of server load). You could use a unreliable remote event and fire it to all clients., since it isnt that important, it doesnt yield and uses less network. But if the projectile is not every second and is casted at a regular interval regular remote events are fine.
Also another note most projectiles in games are not affected by physics! They do the method i said before by firing it to all clients but they actually use a runservice event which fires every frame and updates the projectiles position. In this way you can predict its path on the server and expand on it in the future (like hitboxes or anything else).
Also I am pretty sure the humanoid look vector inaccuracy is due to the remote event delay, if I were you I’d handle the projection on client (to provide fast response) and process the hit boxing on the server, also if you want to reduce server load visualize to all clients on the client side again by firing to all clients for visualization purposes except for the client that fired the projectile because that client already visualized the original projectile before firing to server.
The only downside to this is that it’s very exploitable so you have to write adequate security checks on server side to avoid exploits.
Absolutely even better would be making the hitbox on the client who fired the move then just doing a simply sanity check on the server. I may have some of my examples if you need it,
yes please i think i understand how i would make everything work on the client however sanity checks (which im assuming is to prevent exploiters) i have no idea how id even start with that
Thank you so much also i heard that when you do something on the client it only shows on the casters client which is why I’ve been making effects from the server. Was this wrong?
You’re correct, anything you create on the client will solely be visible to them; to visualize to other clients you will have to process through server or through fire all clients except original caster (More optimized approach)
No because FireAllClients will also fire to the client that we’ve already processed the projectile for before firing to server
What you’d want to do is a custom fire to all clients function excluding that player
Example:
for i, OtherPlayer in Players:GetPlayers() do
if OtherPlayer == Player then
continue -- SKIPPING ITERATION OF THE PLAYER WE PROCESSED FIRST (Original Caster of projectile)
end
remoteEvent:FireClinet(param1,param2,etc)
end
And on the client receiving end just handle the projectile visualization again
Server: a data model which keeps all the clients connected in sync. Since it has that responsibility to replicate everything (if you create a part all of its properties will have to be seen on all clients) to every client, it runs a little behind and things do not turn out as smooth.
Client: Your device! You connect to an assigned server which like i mentioned before is always getting information from the server over the network. The client doesnt have responsibility to replicate everything to all clients. It only has the responsibility to replicate to only one client, that device.
Knowing this will help you a ton. If youve ever heard of not using tween service on the server that would be correct because tween service is constantly updating a parts property and when it does that it has to replicate it to everyyy client connected so it makes sense why it would overload it.
My rule is:
Calculations, responsibility of keeping track of clients data, and more important backend stuff on the server.
Effects, bullets, projectiles and flashy things which update very frequently on the client.
Give me a second. Im going to tag on of my old posts.
so to summarize
Server
Replicates Everything everywhere so use it sparingly for things like
Damage and Important Data
Client’s
Are Extremely useful for managing things like effects and animations that would normally take up huge amounts of space on the server
(and this entire time ive been tweening on the server aswell ty for warning me about this aswell)
Absolutely damage and things that you need to replicate definitely on the server, and things that are not important on the client. You got it, goodluck!
ty for warning me about this aswell)