Questions regarding Knit practices

As far as I’m concern, Knit should (and can) only be applied to singletons, but what if a service, for example, control the flow of an OOP Object, should that object be exposed to the service ? (eg: RemoteSignals, etc)

Speaking of Remotes, what if the object wants to connect / fire a remote to the client ? Should that particular remote be defined and retrieved from the parenting Service if the remote is ONLY used in the Object ?

Last question, lets say that we have a controller, this controller is heavily reliant on the player’s Characte, should it reside in the StarterCharacterScripts as a normal class or the StarterPlayerScripts as a singleton controller ? I believe the latter would be slightly more inconvenient as the excessive plr.CharacterAdded:Connect you would have to hook, but Knit’s structure is also organized enough for it, I’m still unsure though…

Can someone please clarify these for me ? Been struggling for hours, thanks.

For this the Player.CharacterAdded solution is just fine as when the player resets their character it wont actually include the character so its fine!

AFAIK if you are controlling an object or its flow you’re already exposing such stuff to the service as you need references to such object to even begin controlling it in the first place.

Can you please elaborate this even further?

Thanks for your reply!

I think I’ve stated it wrong here, I meant should the parenting Service be exposed to the Object, for example, the object can access the Service’s remotes and so on.

Similarly, considering the previous question’s answer is true, say that the Object wants to fire a remote back to notify the client of something, but ONLY that particular Object will fire it, should the Object create its own Remote and not attach it to the Knit Service or should the Service defines the remote ?.

Furthermore, when the Service control many Objects of different classes, and the remotes are defined in the Service for instance, I believe it will be really messy and unnecessary. On the other hand, the client should probably access the remotes through the Knit Service itself, not through another library (Say, EasyNetwork) that creates new remotes tied to the Object (This is just a sentiment)

As I read this for myself, Knit is a framework that handles remote communication and as such remotes should be created in the particular service you want to make it. Making events outside of Knit really is just messy because you’re already using Knit for remote communication, and that just kind of defeats the purpose of using the framework in the first place. I also once used this for my game project where the service which manages oop classes and objects, let the objects just get the remotes from the service and continue on from there.

Unless you have a lot of remotes that have to be created in order for the objects to work I don’t really think it would be really messy and unnecessary. On your other hand response though, this is how it should work, the client should acess the remotes of the services by getting the service like so:

-- I'm assuming this is client-sided
local SomeService = Knit.GetService("SomeService")
SomeService.MyRemoteName:Fire() -- <- put some arguments if needed

This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.