How would I go about doing this? (Making a non laggy projectile using server - client logic)

Hey guys!

Im generally a new scripter, and I have an idea that I dont know how to enact to create a non-laggy projectile.

It goes something like this -

1. Player input to spawn projectile
2. Server spawns projectile
3. All clients copy projectile 4A. Player who spawned projectile detects a hit and calls the server to deal damage 4B. ALL Clients detect the projectile hitting a wall, calling it to disappear.

And I have no idea how to do it! Any help appreciated!

What you have proposed, a "lag free projectile", is actually impossible, though the algorithm you propose is not. (There is always a communications delay between a server and client, so no matter which algorithm you choose, you will inconvenience someone). Your algorithm chooses to inconvenience the target. Imagine this scenario:

--[[Imagine there are two players, P1 and P2, each with a 200ms communications delay in one direction (or 400ms total ping)

Time (seconds): Situation
0: P1 and P2 are standing still. P2 begins to move to cover; he will be safe after 0.4 seconds of travel.
0.1: P1 clicks to shoot at P2
0.2: Server now knows about P2 starting to move. P1 has successfully shot P2 on his own client. If completely lag-free, P1 may also see evidence that he successfully shot P2 (sound effect, text on screen, whatever). P2 is half-way to cover and, as far as he knows, P1 hasn't even begun to shoot him.
0.3: Server now knows about the projectile and sends that info to P2.
0.4: Server now knows that P1 has claimed to shoot P2 (I say "claim" because of exploiters; this is why you should never trust the client if possible). P2 is now safe on his own client. Meanwhile, P1's client has to decide whether to accept the information that P2 started to move, or say "he's dead, ignore his movement".
0.5: P2 now hears the sound of the projectile firing that P1 iniatiated 0.4 seconds ago.
0.6: Server now has the information that P2 claims to be safe, but probably disregards this in favour of the information that says P2 is dead. Simultaneously, P2 has received the information that he's been shot, even though he got into cover 0.2 seconds ago.
]]

Your proposal sounds like a mix between trusting client-side calculations (which makes your game vulnerable to exploiters, who will then have the power to shoot everybody regardless of where they are on the map or how many walls are between them, unless the server attempts to do sanity checks) and server-side calculations. By default, player movement is client-side and projectiles are a mix (which can cause stutter or jumps as they progress through these time gaps); look into NetworkOwnership if you want more details on that.

No matter how you proceed, you'll need RemoteEvents/RemoteFunctions to communicate the information from the server to the client and vice versa, see http://wiki.roblox.com/index.php?title=Remote_Events_and_Functions.

There is also an article that talks about this sort of thing (with a "lag free cannon"): http://wiki.roblox.com/index.php?title=Fighting_Lag