tweenservice client-server

[sweet flower]

i made a script where when i click a door, it opens but the tween happens client side to make it run smoother, the problem is that other one cant see the door opening since the tween happens on client. should i make like a remote event that opens the door for all clients?

[dusk dune]

do it like this

client clicks door and fires server -> server does security checks and shi and then fires to all clients if security checks are passed -> door tweens open on all clients

[warm zealot]

tween it on the server

use a clickdetector so you can detect clicks on the server

no client code necessary. server scripts only.

[uncut grove]

no, how can you say this

you NEVER tween on server

NEVER

[warm zealot]

reason?

[uncut grove]

the cost of replication in network

plus its way smoother on client

[warm zealot]

i would expect roblox to send only the tween, not physics data

[uncut grove]

well, it is not how tween service works, you need to code that for yourself at least now

[warm zealot]

it's sending property changes every frame, isn't it.. i can't find anything concrete on that but ughh roblox sometimes

...which also messes with server sided physics since if you send a signal to run a tween, that wont be reflected on the server

if true, that is really stupid

[warm zealot]

i'll keep this in mind, kinda curious how you figured this out as it didn't really occur to me. i'd still say tho for some things and in some situations its easier to tween on the server, like in this case a beginner trying to make a door tween that replicates

[sweet flower]

i ve always did that but i’ve recently seen that tweening on client is better performing

[dusk dune]

it is, what you are thinking about is how animations are handled. only animation data is replicated but its not actually played on server (as far as ik atleast)

[dusk dune]

its always better to tween on client

[warm zealot]

it would have to be played on the server for physics, but yeah that's basically what i expected, that roblox sends the tween conditions like tweeninfo and goal etc and performs it concurrently, as an animation yes. but if it's property changes every frame, that is really stupid, and really easy to avoid too that im surprised roblox doesn't already do that

[sweet flower]

the server script handle the open or false value, so the tween cant happen if the door is closed so i think thats a great security check? correct me if im wrong

then if it is closed it setattribute open and pass it to the client making the tween happen

so i just need to use events and make it happen for all clients right?

[dusk dune]

ye ig. i just meant security check as in common security like distance check when someone opens the door to ensure that they arent attempting to open it from the other side of the map

[dusk dune]

yes

[sweet flower]

alrr

so from this moment

should i tween always on client for performance and smoothness?

[warm zealot]

there are some occasions where you can't avoid doing it on the server. if it's purely visual or irrelevant to the server then yes

[sweet flower]

ikik

[dusk dune]

there is no reason to ever tween on server

[warm zealot]

example of where you almost cant avoid it is if you have this door and you're trying to pathfind an npc through it, it'll get stopped by the door since its still closed on the server even though you opened it on the client, bit of a tricky situation that one

[dusk dune]

so yes

[sweet flower]

ye i understand

but

wait

i was thinking

[warm zealot]

so obviously the door would have to be designed some other way to avoid that problem, which is what 'if irrelevant to the server' is referring to

or maybe you just dont care and the door only exists on the client, or something

[sweet flower]

i want an npt to go trough a door that i opened on client, the npc would see that door as closed

[warm zealot]

server-sided copy in the server camera maybe so you can tween it without replicating it?

[sweet flower]

but i can still change that on server side and make that the door doesnt collide with the npc so it counts as open, something like that

[dusk dune]

you should maybe use physics then instead or make the door non collidable. or be creative and make the npc break the door. or if you are really good then store npc data on server and visualize it on client

[sweet flower]

at the end there is always more than a method for everything, i was just curious about wich was the most “performing one” and i think ill stick to tweens on client

[warm zealot]

beginners aren't gonna have a good time with that

[warm zealot]

yeah so its just simply always open on the server, or outright doesn't exist, only existing on the client

that'd be the lazy way ;p

this seems like a really annoying problem, i'm surprised i havent heard of this before

and i can't find much on it either

[sweet flower]

the collide value is based on the situation of the door on all clients, so if i open a door on client i would send that data to the server and make the door dont collide and viceversa

idk how to explain it its a bit tricky

[warm zealot]

i was just thinking that actually, can maybe be done with .cancollide possibly

[sweet flower]

this is for nocs

npcs

[warm zealot]

well, this is why i go through threads like these, you just never know what you'll find sometimes

[sweet flower]

wait i was thinking

do i need to make a remote event for every door

i dont think?

[warm zealot]

nah you'd be able to generalize that fairly easily

i.e you could use one remote and fire the root of the door model since you can pass instances through remote event

[sweet flower]

u right thank u