I have several objects (about 200) which I need to render only to an individual client, this is easily solved by placing them in a folder in workspace (since FE is on and the creation code is in a local script) However, some of the objects need to create a local instance of a sound object, and play it. When these objects are placed in a folder under workspace, the local script doesn’t seem to play.
The only location I can find where the local script will play is ReplicatedFirst (no use, since it only fires once upon player connection),
Starting Player and Character scripts (this is no use, since the objects will not display)
PlayerGui (again, the 3D Objects will not display)
The only place that seems to work is if the folder with the objects is a child of the Character model. However… when other scripts need to parse the character model (for coloring of parts etc…) it will try to parse through several hundred other models and their parts (since I use a routine to check children for deep nested parts that need color) So being a child of Character is a “solution”, but not ideal.
So my question : Is there any other place where models can be created, and will display in the world as local parts, but yet will also execute any local script that the models might contain.
Instead of having the parts in workspace, try using a LocalScript to parent them to Workspace.CurrentCamera, then use a local script to manipulate them.
No, do not parent the LocalScript into CurrentCamera, parent it into StarterPlayerScripts or StarterGui, and use the script to parent the Folder into CurrentCamera is what I mean.
I see what you mean, although that would require a huge rewrite on my part, and the code would probably end up not being as efficient. I was hoping I had overlooked some sort of ‘sweet spot’ where local parts could be displayed, and local scripts could execute all together.
You would think, now that FE is standard on all games, so that objects created in workspace from the client are local only, that local scripts placed in workspace on a client side, could execute from that client. But wishing isnt going to help solve this for me now.
They really need a “CurrentWorkspace” container for this type of thing.
If you’re unable to place a LocalScript in the proper place where they do run, you will have to rewrite your structure. It’s a fundamental flaw which is affecting the rest of the code structure.
Yes, I understand that a rewrite will be necessary, I just like to check first, for an easier or overlooked solution before I embark on the rewrite adventure. So if google fails me, which it did, I always like to search here, and ask, just to make sure I didn’t miss something or in case someone else has had this issue and has some good advice.
I thank you all for your comments, and appreciate the time you took to read and answer on this post.
Unfortunately there is nothing to be overlooked here. There is no chance that a LocalScript can be executed from a locally created workspace model and that behaviour can’t be controlled. That leaves the only option being a Lua-in-Lua VM that runs as a ModuleScript for the client, but that seems like silly work for a trivial matter where rewriting structure gives you significantly more power and maintainability.
What I did was have the local script that places all the models in the camera, to check each model for a child called ‘sound’, if that child is found, the instance reference of that model is sent to the sound handler, where its details are kept in a table, and the sound manager creates the sound instance and plays the sound for the object. Only issue now, is that there is no attenuation for locally created sounds, but I’ll do a different thread for that XD
