adding onto the reply above, i would have all your weapon constants like damage, swing speed, etc. be in either a modulescript or values stored on the server so that you can change them and have it update for all the skinned weapons, saving you immense time in the long run
tl;dr have all the skins be separate tools and clone them into the player’s backpack when they change skin and have all your weapon stats be in a centralized area so you can balance weapons without having to edit every tool
edit: i misread what they said, this wouldn’t be an issue if you just follow their method, theirs is a lot simpler anyway
1 Like
So pretty much I destroy the old model then clone the new model for the weapon? Is there any way I can make a system where all the scripts and everything stay and all I’ve got to do is change the model itself? Because skins are purely cosmetic, so the scripts would be the same.
If you really need to keep the exact scripts that are already in the weapon, and just change the mesh parts inside the weapon, then you could:
But, if by disable and enable the scripts you lose important information that was in memory, then you dont want to disable it, and you want to handle the mesh change from inside the script, in which you would need to reconnect events that are using a reference of any new part/mesh from the old, and connect it to the new one. For example a Touched event that was using a old reference should be reconnected to the new mesh/part.
Destroying old model, and giving a new one with the scripts, its the easier way, it just depends if you lose information you wanted to keep in the weapon, if not, thats your best bet.
I agree with the previous reply, about using Modules, to keep certain information that you could need, or handle the behaviour of weapons too. Its just require more planning from you and time.
1 Like
Pretty much I want to maintain the combat systems for each weapon type (damage, animations, etc) while just changing the model itself when changing weapon skins. All 4 weapon types will be available within a player’s hotbar. Players can buy weapon skins from the shop and they’ll appear in a custom inventory with tabs for each weapon type. What I want to do is have it in the inventory so when a player equips a different skin for a weapon it replaces the model and that’s it. All the code for the combat system of said weapon would be the same. I’m pretty new to scripting (started back in March) so bear with me if I sound like an idiot. What you originally said about cloning and destroying the model makes sense. What I want to know is if there’s a way to just have the model replaced without having to do anything regarding the scripts. One idea I had it just copy and pasting the combat system script into every model then just cloning & destroying it all but I don’t know how effective that would be.
You can simply destroy the model inside the tool yeah, without messing with the scripts or instances/folders etc which is in the tool.
I suppose you are using Tool instance for your weapons, you know it has a part “Handle”, and if you add a model inside the Tool, all meshes in that model should be welded to the Handle in order to move along with the handle when player is holding it.
You could just delete that model that contains the meshes/skin, and clone and place the new one, and weld it.
The only thing Im pointing out about that approach, is that if any part inside that model is being used inside the script of the weapon, once destroyed, the script wont find the part, so, make sure the new part is connected to anything that uses it inside the script, or a function in your script will be broken
1 Like
Okay so pretty much all I’ve gotta do is change the model of said tool and do a bunch of stuff with the handle? All the skins are going to be exact same size so could I give them all individual handles and clone/destroy both to the tool or would that break everything since a handle is required for a tool? Also I think I understand that last thing you’re talking about. Pretty much anything revolving around the model itself needs to be connected back to the script? So when I clone the model to the tool do I just have to parent everything related to the old model itself to the new model?
1 Like
make the handle/damage brick separate parts from the actual skin or else it will alter the performance of the weapon from skin to skin, which isn’t fair
1 Like
Not really bunch of stuff. Its just a weld, like can be done in one or 2 lines. Depending on how many mesh/parts are going to be welded
The skins doesnt require a Handle part, you would be using the previous Handle from the original Tool, and after Clone() and Parent the Skin to use into the Tool, just run a loop to weld all mesh/parts in the model to the original Tool’s Handle.
Could be useful if you already welded all mesh/parts to a “root” part. And when cloning the skin, you would only need to weld the root part to the Handle of the Tool.
If you mean what I think, then yes.
A example (could not be related to your case):
I have a Tool which is a Sword, and it has an invisible part (collision box) which uses a Touched event to inflict damage to other players.
The script has a variable: local HitBox = script.Parent.ColBox
And using that reference to connect the event:
local HitBox = script.Parent.ColBox
HitBox.Touched:Connect(function()
warn("do damage")
end)
If I delete the HitBox from my Tool, the Touched event is not working anymore. If I clone a new part and place it in my Tool and weld it. I would need to reference that new part as the HitBox in order the Touched event still working.
If the new part has the same name as the old part that is deleted, then I could just disable and enable the script, and it will get connected normally.
If I dont want to turn off/on the script, then you need to handle that from the script, to connect that part again
1 Like
Yeah, I plan on using raycasting for the damage detection. So pretty much I save everything - scripts, handles, raycast attachments, etc to the tool and just destroy/clone the model. As @Dev_Peashie said any parts of the model that interact with the script might be affected. Would this apply to the raycast attachements or anything else? If so would all I have to do is change the parent of that stuff to the new model instead of the old model?
if all you’re changing is the weapon model nothing to do with the scripts would be changed
1 Like
Awesome! Thanks for the help @aobunau & @Dev_Peashie. You guys have no idea how much this has helped!
I’m going to sum this up for anybody who may need the same solution.
All you’ve got to do is destroy the current model in the tool, clone the new model to the tool, weld the tool to the handle, and boom.
(Read through the replies to get more in depth explanations)
Big thanks to @aobunau & @Dev_Peashie for helping explain everything!
@Dev_Peashie I have a question. I plan on using this for the hitboxes of the tools. Raycast Hitbox 4.01: For all your melee needs!. From what I read it works via attachments that connect to the weapon, so in this case the model. So in the script the hit box script is parented to whatever you put it in, in this example a tool. So if the weapon skin is destroyed and a new one is cloned in its place will the attachments work properly or do I need to do some more scripting to fix any possible issues?
Yo boys, I’ve got a question. So in the game I’m making one of the updates is going to be a quality of life Update. Part of this update will be making weapon skins such as lightsabers, energy swords, basically anything laser/plasma related have different sfx than normal. How would I go about achieving this since the sfx is stored inside the tool and all that’s changed is the model itself? One idea I had is basically having some sort of identifier attached to every skin like that. Then having an if statement that detects if the skin has that identifier. If identifier == true then the default sounds are switched with the new ones. How would I go about executing this?
Honestly, I’ve never tried that module RaycastHitbox… Im used to avoid using any modules even if those looks pretty or kinda useful.
My reason is that sometimes I spend more time trying to adapt it to what I exactly need, and building my own becomes faster, adapted exactly to what I need, and knowing exactly what my system doing.
But, surely there is a way to keep the attachments parented to something that will exist in the tool forever, like an invisible part… honestly idk how that module works, I cant help you with that :v
That’s what I was thinking, having the ray cast attachments being parented to something. The only constant I can think to parent them to would be the handle maybe? The positions of the attachments would be the same no matter what since all that’s happening is a model change. This would also make sure every skin has the same hit box if I’m not mistaken
The RaycastHitbox module is shocking simple. I’m a dumbass and usually have to reread or rewatch things when it comes to scripting 2-3 times to fully understand (if it’s a complex concept). I also tend to over complicate things when it comes to scripting only to realize it’s super simple. This ray cast system is so simple that I was able to understand it first try
Hey I’m going to revive this real quick. Can a handle be parented to a tool? Otherwise if I change the model with the handle parented to the model things might break
I dont understand your question, the Handle part should be parented to tool. You want to place the Handle inside a Model inside the tool?
The best thing you can do, is do tests, usually for this kind of questions its not really necesary to ask it in DevForum. Create a tool, and play with the handle, additionaly play with the properties of the tool instance
1 Like
This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.