I just thought I’d post this here, since I’ve been working on this for a while, and with v3.0, I feel it’s stable enough to share with the public.
Basically it makes it easy to create/get/use RemoteEvents/RemoteFunctions purely through scripting, and now includes RemoteFunction caching and wrapping around existing RemoteEvents/RemoteFunctions.
Not sure if any of you guys would find this useful ¯_(ツ)_/¯, but I tried documenting it quite well anyway and I have at least one friend who was confused about remotes using it with no complaints.
I’m liking it – however, I’m not such a big fan of manually creating them through scripts. If I’m not viewing that script, I’m not going to be able to know which remotes are hooked up to that script unless I’ve memorized them. However, dumping them all in the ReplicatedStorage is an unorganized mess. I had considered parenting the remotes to their respective scripts in the ServerScriptService, but then the client wouldn’t be able to see and fire them.
Knowing this though, I think ModRemote would be much more cleaner and organized if you had to create actual instances of Remote* objects, parent them to the script they were used in, and then when you required ModRemote, it would go through all of the Remote* instances in the script and automatically add them to ModRemote’s list of remotes.
Now I’m able to see which remotes I have access to from the local script editor. I don’t have to go back and forth between scripts to figure out which remotes I have, and it’s clean because remotes are in the scripts that use them and not bundled in the ReplicatedStorage.
[quote] I’m liking it – however, I’m not such a big fan of manually creating them through scripts. If I’m not viewing that script, I’m not going to be able to know which remotes are hooked up to that script unless I’ve memorized them. However, dumping them all in the ReplicatedStorage is an unorganized mess. I had considered parenting the remotes to their respective scripts in the ServerScriptService, but then the client wouldn’t be able to see and fire them.
Knowing this though, I think ModRemote would be much more cleaner and organized if you had to create actual instances of Remote* objects, parent them to the script they were used in, and then when you required ModRemote, it would go through all of the Remote* instances in the script and automatically add them to ModRemote’s list of remotes.
Now I’m able to see which remotes I have access to from the local script editor. I don’t have to go back and forth between scripts to figure out which remotes I have, and it’s clean because remotes are in the scripts that use them and not bundled in the ReplicatedStorage. [/quote]I do feel that’s actually an interesting idea, and I’m surprised I didn’t come up with that. I can see how that’d be useful.
I could do that yes, that’d be quite easy to do actually considering GetFunctionFromInstance & GetEventFromInstance was the result of me feeling that doing it all through script is silly.
I do think your idea makes a lot of sense, so I’ll work on implementing something like that. :DDD
Do it automatically pl0x. When you require ModRemote, there’s no reason the RemoteEvents/Functions in the server scripts shouldn’t be required.[/quote]Done & done.
EDIT: Hold on, not working properly yet. Can’t get the script who required’s environment from the Module unless i return it as a function - afaik.
Do it automatically pl0x. When you require ModRemote, there’s no reason the RemoteEvents/Functions in the server scripts shouldn’t be required.[/quote]I’m not sure if there’s any way to get the script who required the module without having functions involved.
Any idea? :?
EDIT: I could just make it so you can do
local modRemote = require(modremote)();
using metatables, so require(modremote) would still work as well.
Which would be shorter than doing the whole :RegisterChildren() thing.
Sorry for the late post, but you are correct. However, I don’t see any reference to the script in that. Sure, you can use getfenv(2) from the module, but that returns the table of variables in the script that required it – not the script itself. You wouldn’t have access to the children through getfenv(2). Luckily for us though, the variable we use to reference the script itself in our code (i.e. script.Parent.Parent.Parent) is in that table that getfenv(2) returns. This means that you can do:
module:
return function()
local script = getfenv(2).script
for i,v in pairs(script:GetChildren()) do
if v.ClassName:sub(1,6) == "Remote" then
hookUpRemote(v)
end
end
end
[quote]
return function()
local script = getfenv(2).script
for i,v in pairs(script:GetChildren()) do
if v.ClassName:sub(1,6) == “Remote” then
hookUpRemote(v)
end
end
end
[/code] [/quote]I’ve tried it with Heroes’ Legacy, and it works fine. It’s being called from the script that’s requring it, so getfenv(0) works fine.
I’m actually liking this better, thanks for the idea.
[quote] Just thought I would post this, but I found a small issue regarding to RemoteFunctions returning variables.
I wrote up a detailed issue report on the GitHub page - https://github.com/VoidKnight/ROBLOX-ModRemote/issues/1
Hopefully, you can resolve this so this doesn’t effect everyone [/quote]If I recall correctly, RemoteFunctions don’t return any more than one value anyway - however I’ll fix that anyway, in case that behaviour was changed from the last time I tried using RemoteFunctions like that.
I may have mixed it up with ModuleScripts, and I might be wrong. Fixed it anyway.
Tell me if it works now, if it doesn’t - it’s out of my control.
[quote] Just thought I would post this, but I found a small issue regarding to RemoteFunctions returning variables.
I wrote up a detailed issue report on the GitHub page - https://github.com/VoidKnight/ROBLOX-ModRemote/issues/1
Hopefully, you can resolve this so this doesn’t effect everyone [/quote]If I recall correctly, RemoteFunctions don’t return any more than one value anyway - however I’ll fix that anyway, in case that behaviour was changed from the last time I tried using RemoteFunctions like that.
I may have mixed it up with ModuleScripts, and I might be wrong. Fixed it anyway.
Tell me if it works now, if it doesn’t - it’s out of my control.[/quote]
[quote] Yeah, I think RemoteFunctions can return as many values as you want. You were probably just confusing it with Modules like you said.
I’m excited to start using this on my next stuff [/quote]Okay I just realised it may have been due to this original mistake that I thought RemoteFunctions only would return one value. Not sure why I only made it return one value in the first place…
Nice to know they return more than one value.
I’ll fix up the caching system soon when I get back, so that also caches multiple return values as well.
