Preventing projectile delay?

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

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

1 Like

Oh ok makes sense.

I JUST got done with my shooter MVPā€¦

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

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
1 Like

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

1 Like

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.

2 Likes

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

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.

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

Pass the castingPlayer as an argument in the fireallclients

1 Like

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.

3 Likes

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)
2 Likes

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.

2 Likes

Nice catch lol

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!

1 Like

Lucky for you im dealing with the exact same problems

1 Like

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?

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.

3 Likes

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: