Code in StarterGear not running?

I have a system inside my game that basically allows the live modifications to gears through a bindable event. However, as with all gears, everything resets when the player dies. So, my solution was to create a script that would move everything to StarterGear, effectively removing the need to use StarterPack. Then, I modified the script to fire the bindable event both inside the tools in StarterGear and the Backpack/Character.

However, here is the problem. No matter what I did, or where I looked for solutions, I couldn’t get a script to run inside StarterGear. Seemingly when a tool is moved to StarterGear, all scripts inside of it cease to function, and will only function when copied to the Backpack.

So, is this just an issue with Roblox, or is this issue somehow caused by me?

Not an issue with Roblox or you. It was designed this way. For client-sided scripts with constant uptime, place them in StarterPlayerScripts. You can modify the tools from there

These aren’t client sided scripts, these are server sided. I’m simply asking if there is any way to use this system, as it has everything I need (outside the fact that the scripts seemingly don’t run).

No. For scripts with constant uptime, place them in ServerScriptService. What exactly are these “modifications” anyway?

They don’t have constant uptime, should have mentioned that. They only run when a specific BindableEvent is fired.

As for your question, the game is a very customizable version of Doomspire. “Admins”, determined by VIP server owners, get to decide for themselves, or for all people each individual element for tools. Say for instance, they get to decide how fast a bomb explodes, or what shape a Superball is. So, through a generally understandable, but very modular system, you can make any changes to the tools you want. Everything is how I want it, however, back to the main point, the tool’s “settings” don’t save when you die. If you have ever played Doomspire, you would know that you die alot, and that’s an issue. So, by making all modifications to the tools themselves and to the tools in StarterGear, you have a system that is simple at “saving” settings when you die. That’s why I’m so adament about using StarterGear.

I could jus build my own system, but with my coding skills, it would take hours to build, test, troubleshoot, over and over. So, its easier when I have a built-in system right here.

Back to my question, is the system I am trying to achieve possible with StarterGear?

You can make scripts run in StarterGear via the RunContext property, but that often comes with consequence. You do not need your scripts to run in StarterGear, you only need the script responsible for modifying the tool to affect the copy in StarterGear. Simply store that script in a location like ServerScriptService

The modifications are made with an outside script communicating with a script INSIDE of a tool using a BindableEvent. I could just have all the settings outside of the script with variable objects, but I sometimes find those unreliable when storing data. Plus, it would be a pain in the ass re-scripting all seven tools to use their variables outside of the script. I’ll try changing the RunContext of the scripts and I’ll let you know how it works out.

Why not just store the tools with changes in ServerStorage and replicating them over to the player when they respawn? You can customize which player gets what and whatnot using a ServerScript in ServerScriptService. You can even customize how the tools change in the ServerStorage.

Since you don’t want to go through that hassle of recoding a new system, you could, after every change, recopy the tools into the StarterGear of every player.

If your weapon has settings it should be stored as attributes, value instances, or in a module. You’re reaping the sorrows of having used upvalues

1 Like

Changing the RunContext to Server seemingly fixed my issue. My code now runs inside, and “saves” whenever the player Dies.

1 Like

That could have worked, but I’m not entirely sure how the timing would have worked. Especially if someone lagged, there’s a chance it would have just not saved, and reset to its defaults. That’s not the worst thing in the world to happen, but especially in a game with lots of moving pats and what not, its not ideal for low-end devices.

1 Like

I guess you are correct. I don’t really like storing values outside of the tool unless I really have to, and if your suggestion didn’t work, that would be where I would have gone to next. I’ve had very, very confusing times where values would just not read or write at all when stored anywhere outside the script, and its not ideal for me. Plus, I wasn’t entirely thinking ahead when I was coding the tools. If I would have thought about the fact that it reset every time, I would have also just stored the values from the outside.

I use a Server Script that handles player tool persistence by setting up essential services and managing tool storage. When a player joins, it creates a folder in ReplicatedStorage to track their tools. Starter tools are added to a skip list to avoid duplication. On spawn, the script restores previously saved tools from ServerStorage into the player’s backpack, attaches accessories if they exist, and adds any predefined gear. When the player dies, their tools are stored in a data folder to be re-equipped on respawn. The script also cleans up the player’s data when they leave the game.
This is a bit complicated, good luck, it took me some time to get working.

Value instances are very reliable. I’m sure whatever issues you may have had with them were born from a misunderstanding of their operation, or a more deep-rooted bug in your code

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