Quote:
Originally Posted by cbk1994
Of course it's possible to create scripted projectiles, but these simply cause more problems, especially with people who lag.
|
No they don't o.o
If you mean network lag, no, because they're handled exactly the same as bullets are- clientside. And you can improve synchronization over Graal's default by using timevar2 and timevar.
If you mean clientside lag, the difference in performance is extremely negligable and may even be an improvement over built-in projectiles.
It fixes all your problems with projectiles if you do it right
They won't disappear over level links, they'll actually work on barrels and boxes, and other things. Sure, it requires a bit of work, but it's not insanely difficult.
The way I did it was with arrays, stored x, y, an x movement vector, a y movement vector, a creation time, and a direction to face. Sent that information via a triggerclient type deal and stored it in other players, used the creation time to synchronize them more effectively than Graal's default, and then rendered a bullet gani at x, y with the direction stored. Collision was simple enough, obviously. They didn't have to be destroyed over level links on the same overworld. Worked fabulously.
If your idea was to spawn NPCs to work like bullets, forget that idea, it undoubtedly eats up network performance
and clientside resources as opposed to the single system script approach described above. I see you did the separate NPC per bullet approach in one of your servers, I read a thread on it a while ago.
If
I can do it in 2005, when I'm 11, in GS1, without an NPCServer, in the 2.17 client, with no visible performance difference on a computer with the processing power from that same time period, surely
you can do it in the present, no? I remember there was no timevar2 then, so I had to play an MP3 in the background and use musicpos to get an accurate creation time
