Preventing projectile delay?


#21

Though it does expose your system to brittleness as you have to make sure your cframes accurately reflect how the client side bullets behave.


#22

Client-sided bullets move by same logic, only difference is that they have reference to the model and move the model as well.


#23

Oh ok makes sense.

I JUST got done with my shooter MVP…


#24

And I’d do this using a loop correct? Such a for i = or repeat?


#25

Yeah, it’d be something like this:

while true do
  local timePassed = wait();
  bullet:updatePosition(timePassed)
  -- newPos = start + CFrame.new(start, end).lookVector * (timePassed * velocity)
  -- raycast(currentPos, newPos), if there's no hit, move to newPos and set 
  -- currentPos to newPos
end

#26

You guys have been so much more helpful than ScriptingHelpers!
And the RemoteEvent for :FireAllClient and :FireServerEvent would need to be in Replicated storage?


#27

You could literally just create the projectile locally, fire the server which would then create another invisible projectile that would do the damage and from the server fire all clients, but the original client and make them create the projectile locally. This is exactly what I do for my game.


#28

Anywhere accessible with both client and server.
So yes, ReplicatedStorage is fine


#29

I have like 16 events to run my shooter. I differentiate between RequestCreateBullet and RecieveCreateBullet. Keeps me sane. I had to create a GetReplicatedStorageEvent(filePath) script though to make getting the event faster.


#30

So far so good,
However how would I set the parent of the Spell to individual Players Character through FireAllClients?


#31

Pass the castingPlayer as an argument in the fireallclients


#32

Personally, to save having scripts in each tool, I like to just fire all projectiles using modules.

Yes, this is true, but for a simple projectile on the server this could be acceptable.

Another great method of making projectiles is to have the projectile anchored (so that it’s not using physics) and then just move the projectile along its lookvector by some small increment using a for loop.

Example:

local projectile = instance.new(“Part”)
projectile.Position = wand.Position
projectile.Anchored = true
projectile.CFrame = CFrame.new(wand.Position, mouse.Hit.Position)
projectile.Parent = workspace
for i = 1,200 do
projectile.Position = projectile.Position + projectile.CFrame.LookVector * 1
game:GetService(“RunService”).Heartbeat:wait()
end

this is a game I made a while back, The RPG tool is one that uses “CFramed projectiles” like the method above.


#33

So, this is the code so far and honestly it’s working BRILLIANTLY.

Event.OnClientEvent:Connect(function(Client, StartPos, EndPos)
	local Spell = Instance.new("Part")
	Spell.Size = Vector3.new(1, 1, 1)
	Spell.Anchored = true
	Spell.CFrame = CFrame.new(StartPos + Vector3.new(0, 3, 0), EndPos)
	Spell.Parent = Client.Character
	
	for i = 1,100 do
	local ray = Ray.new(Spell.CFrame.p, (Spell.CFrame.p + Spell.CFrame.LookVector * 1 - Spell.CFrame.p).unit * 2)
	local part, position = workspace:FindPartOnRay(ray, Client.Character, false, true)
	if part then part:Destroy() Spell:Destroy() return else end
	Spell.Position = Spell.Position + Spell.CFrame.LookVector * 1
	game:GetService("RunService").Heartbeat:wait()
	end
	Spell:Destroy()
	return
end)

#34

Nice! One thing I can see though, is that if you are parenting your part to the player’s character then the part will disappear (like the rest of the character) when the player goes into first person mode.

One of the nice things about CFramed projectiles is that they can be created right on the server and there wont be too much lag!

also, if you want to simulate bullet drop then you can just change the part’s orientation a small bit as well each time you move the part, and since the orientation changes the angle of the LookVector, the bullet will drop with a really natural looking motion.


#35

Nice catch lol


#36

That’s fine! The game i’m working on disabled FP mode and limits it the MinZoom to 10!

I am honestly so grateful for all of your help tonight!


#37

Lucky for you im dealing with the exact same problems


#38

Here to be complicated again!
Is there any way to avoid putting them into ReplicatedStorage just as I prefer them to be within the tools tbh -
Is there any i,v I can do to check the Players Backpack / Character for the RemoteEvent and then fire the client individually that way?


#39

Yes, there is a way to do that but I would advise against it.

Putting the RemoteEvents in your tools may seem nicer for the purpose of organizing and grouping your objects inside of the tool, but it falls apart performance wise.

Let’s say you have 20 players, each having one of your projectile tools containing a RemoteEvent.

When you want to create a Projectile, the server has to fire 20 different remoteEvents! This is more taxing on the server and will take more time to complete. However if you have all the clients listening for a singular remoteEvent, the server only has to Fire One event to transfer its data.

I would argue that having Only one RemoteEvent for this task is easier for both organization and for the sake of being modular. It is very easy to just store your events in folders inside of ReplicatedStorage or wherever you want to put them and it is a good practice overall.


#40

Understandable,
I’ve just made it so the ServerScript itself creates a folder with the events inside and places them into ReplicatedStorage, much tidier and I don’t have to mess around moving anything! :smiley: