Why on the client? For optimization? I don’t think it’s a massive issue.
How is it problematic? It’s functional without problems and stuff gets deprecated every week. At the end the result counts and i don’t think your messy code will help anyone.
since it’s visual feedback you’d tend to want it to react as fast as possible. Hence it’s more suitable to be run on a localscript.
- this is a cosmetic thing and doesn’t affect the game overall.
(it’s why bullet tracers in most games are rendered client side via a localscript)
If it was on a local script, wouldn’t that mean the animations won’t show to other players? Or does the animated rig just automatically go to the server even if its changed locally?
Because you should always use things like repeat, while loops, etc as less as you possibly can. Obviously use it when you gotta, but luau is an event-based language. Repeating unneccessarily will put strain.
That’s not a good mindset to have, as a programmer you should always be trying to make the best code you possibly can with the least problems. If you have an easy option to choose between deprecated and new, would you really choose deprecated? One day you’ll have to fix your game and go back through it to fix all the deprecated stuff you didn’t bother to change.
Speaking of deprecated methods don’t use wait(). task.wait() is what you should be using.
It will show on a local script, don’t worry about that. Test it out! Good luck to you.
Oh yeah that makes sense. I can see why you’d want it on the client.
But, wouldn’t this not run if the seat is a descendant of workspace? If this is a local script.*
1 Like
Deprecated doesn’t mean it’s not working anymore. It means it doesn’t get updated anymore, but i understand your point. Sometimes it is necessary to make compromises in order for something to work properly. If i know what I’m doing with something that is deprecated it’s better than doing bad work with something I don’t know just because someone recommended it.
1 Like
I understand your point too, I used to be like you. Using deprecated methods and what not but I grew out of it.
While it may be easier it certainly isn’t the better option, you’re thinking short-term rather than long-term.
Also, don’t just take my word for it. Research yourself, i’m not pulling things out of thin air. There are reasons why you shouldn’t use deprecated stuff you were using. For example, hum:LoadAnimation()
and wait(), Why they deprecated hum:LoadAnimation()
wait() is worse than task.wait()
1 Like
Why wouldn’t it? if you’re thinking that it will be nil you can just do workspace:WaitForChild(“Seat”). That’s if you parent your local script to the starterplayerscripts, if you parent it to the startercharacterscripts it would be easier as the seat wouldn’t be nil since your character would’ve loaded already but i’d recommend putting the waitforchild in there anyway just in case.
Well, don’t local scripts just not run if they’re under workspace? This code would imply the script was under the seat part in workspace.
Oh yeah I did that because I did it in a server script but I just wanted to save time since I wasn’t actually gonna add this into studio or whatever I just pretended that I parented the script under the seat, but what you should do is make a server script and parent it under serverscriptservice/serverstorage and reference the seat by doing workspace.Seat, then do what I did. Or you could take @SelDraken’s approach of doing this on the client. Either one is fine, but I would do it on the server because I wouldn’t want exploiters reading that. Your choice though. If you wanna do it on the client obviously parent the local script under the starterplayerscripts/startercharacterscripts and then do workspace:WaitForChild(“Seat”)
Oh alright I get it now, I’ll take another look at both and try them. Though quick question, is there any reason why I wouldn’t want them reading it from outside serverstorage? Isn’t it impossible to change client sided since its a server script?
It just sorta annoys me I guess, imagine you make a script and an exploiter just steals that script for something like their own game. It’s not nice to show the client something they don’t need to know in my opinion. Plus roblox did announce on the devforum that you should always load the animation from the animator by server-side whenever you can. They were the ones who made it so I would listen to them.
Well, I’m not sure where you think I did anything on the client’s side. It was solely all from the server, maybe you got a bit confused.
Oh no, I meant like the cheater changing things but can’t because it’s server sided. Though thanks!
Oh yeah, clients can change anything on the client but it would be client-sided meaning the stuff would only change for them on their screen and not on regular players’ screen. However, I just don’t like relying on the client too much I guess. But it’s your choice, you can use my script from serverscriptservice/serverstorage (reference the seat by doing workspace.Seat if you’re gonna do that) or take the other guy’s approach of client-side. It’s up to you my dude good luck.
There is no reason ‘not’ to do it on the client unless changing the animation would break the game, or cause an unfair advantage.
Client will be smoother, but you could also do it from the server. Its just with animations, its best to use client unless someone changing the animation would break your game.