Are there any good alternatives to attributes?: I’ve been using attributes almost all the time to call on whether a player is blocking, or parry, or in iframes, or attacking, and more. But I really wanna know if there are any other ways I can reliably call something from one script to another.
1 Like
I think attributes are probably the best method for single-value data. Other alternatives could be modules or instance values, though.
However, if you are attempting to identify an item (e.g. data is not required), use tags.
2 Likes
Thanks for the feedback. Also, what do you mean by item? I’m not attempting to call on something you gain. I’m attempting to call on something everyone would have such as IFrames when using a move, or blocking. I don’t think that requires data. I may be wrong though please correct me.
I think value like string value could be a good alternative to check if player is parying, blocking, atacking etc. (not sure tho as I havent done any fighting system yet so cant tell from experience)
1 Like
Sorry, by “item” I meant a group of instances; I should have made that clearer. For example, if you want to get all the blocks in the workspace placed by players, you would tag them all with “Block”, instead of using an Boolean attribute set to true.
For custom player states, I would recommend a module or attributes as the best methods.
I’m sorry if these questions are getting annoying but I’ve been scripting on and off for a long time and have no idea how I would use a module to see if someones blocking? How would I go about that?
1 Like
Modules are more advanced. I wouldn’t recommend a module solely for the use of that, but maybe if you are going to contain any methods you need to use for changing the player to a custom state (e.g. blocking, sprinting) you could use values contained within it, have a method to update those values, and access them outside of the script.
local module = {}
module.__index = module
module.blocking = false
module.sprinting = false
function module:Update(state, new)
self[state] = new
end
function module.SomeMethod()
end
return module
I would strongly recommend looking into Object-oriented programming (OOP).
You could represent each player as an “object”, storing “attributes” inside the object instead of using ROBLOX’s more tedious attributes. Furthermore, you could implement methods to the objects that take these attributes into account and manage them properly.
For example, a :damage(amount) method that wouldn’t do anything if player.Blocking was true.
Without knowing about OOP, this may not make a lot of sense, therefore I suggest researching it more.
Check out this video for an introduction:
1 Like
Personally, I store player combat data (blocking etc.) in a module. When a player joins, I add them to the table, when they leave, I remove them. This also works for characters and NPCs.
1 Like
The only problem with this is it might not be worth making a class for the player. Just because you can doesn’t mean you always should. It might be better to have a module for each player rather than an object.
2 Likes
Do you know any YouTube videos that show how to do this?
Sorry, I don’t know any tutorials for this. I don’t really tend to look at YouTube tutorials, and don’t particularly recommend you follow the exact code there, it isn’t always great. But definitely use it as a rough guide.
1 Like
I don’t see why it wouldn’t be “worth it”. Having a module for each player results in less centralisation which can cause your project to be less organised - and that’s like the only difference between the two approaches.
By “worth it”, I meant it would be easier to access each player’s inventory individually - the source code for making it Object-Oriented would get messy and hard to read depending on how many methods there are, and items to store.
I guess it’s down to personal preference, really - I generally prefer to make a module for each player for something like this, but OOP would probably also work.
This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.