What's more efficient?

Help and Feedback Scripting Support
#1

I have an ability system which basically saves every ability that’s being performed in that moment for as long as it lasts on a table, which gets replicated to each client (see code bellow)

local CurrentActions,CurrentActionsL = {},{}
local mt = {
	__index = function(self,i)
		return CurrentActionsL[i]
	end,
	__newindex = function (t,k,v)
		CurrentActionsL[k] = v
		-- fires a remote to replicate the table on every client
	end
}
setmetatable(CurrentActions, mt)

I don’t know if this would be the best way to go, Previous to this system, I had one based on StringValues (which auto-replicate to every client), parented under a folder on the caster’s humanoid.

I would really appreciate some advice!

1 Like
#2

You could use rawset to only have one table, also if __index is no longer needed, delete it

local mt = {
	__newindex = function(self, k, v)
		rawset(self, k, v)
		-- fires a remote to replicate the table on every client
	end
}
local CurrentActions = setmetatable({}, mt)
#3

Your gut feeling is probably right in thinking that it’s not a good idea to replicate the state of all abilities when only one changes, since it’s mildly wasteful at best.

My recommendation would be to separate out abilities into “slots” which work independently, like using completely different remotes and abilities. A slot should then replicate the current state its single ability.

I made a fully-fledged ability system for a MOBA (game like League of Legends) not too long ago, and I could answer some questions about my approaches in PM if you like.

#4

I need the proxy table to be able to tell when a index has been set to nil, as I wouldn’t be able to otherwise.

#5

The only problem is that I kinda need all of the abilities to be in one single table to check if an ability is compatible (can perform at the same time) with the others, along with other features. Also I don’t see what difference would it make to fire different events for each ability when you can just do it in one (the amount of times you communicate between server and client stays the same)

#6

The ability-to-ability compatibility probably should be coordinated through some locking mechanism. Like if abilities A and B use the left arm, and C uses the right arm, then you should have a locking mechanism for both arms, for example. Abilities would then check the relevant locking mechanism. Describing the kinds of abilities you’re creating would help.

I mean, the idea is organization, but again yours might be different. In theory, you could construct a game that uses literally only one RemoteEvent and RemoteFunction and nothing more, but it would be quite annoying. The system I was talking about had a lot of slots that could potentially hold a lot of different abilities, so your mileage may vary.