Tower upgrade system works fine with one tower, but breaks with multiple towers? tower defense

Help and Feedback Scripting Support
#1

i am making a tower defense game and i just finished the tower upgrade system, it works when there is only one tower, but when there is two towers, it would only upgrade one of them, so even if i upgrade the other one, the first one will get upgraded instead of the second one, i know its complicated, but i just cant fix it, btw, both are server side and they use the same module script, here is what their files look like:
image

here is their scripts:

modulescript:

local sys = {}
sys.__index = sys
local upgradeFrame = nil
local info
local tower
local TowerFolders

function sys.Set(x)
	upgradeFrame = x
	info = upgradeFrame.Model.Value.Configuration
	tower = upgradeFrame.Model.Value
	TowerFolders = tower.Upgrades
	print("set!")
	print(TowerFolders.Name)
end

function sys.EditValues(x)
	local info2 = upgradeFrame.Folder
	local TowersInfo = x
	print(TowerFolders.Parent.Name)
	upgradeFrame.UpgradeInfo.Text = tostring(x.Parent.Text.Desc.Value)
	upgradeFrame.UpgradeName.Text = tostring(x.Parent.Text.name.Value)
	
	info.Damage.Value = TowersInfo.Damage.Value
	info.Range.Value = TowersInfo.Range.Value
	info.StealthDetection.Value = TowersInfo.StealthDetection.Value
	info.Speed.Value = TowersInfo.Speed.Value
	
	info2.Damage.Text = "Damage: "..info.Damage.Value
	info2.Range.Text = "Range: "..info.Range.Value
	info2.SD.Text = "Stealth: "..tostring(info.StealthDetection.Value)
	info2.Speed.Text = "Speed: "..info.Speed.Value	
	
end

function sys.Upgrade()
	print(TowerFolders)
	local value = upgradeFrame.Model.Value.Configuration.num.Value
	for _, v in pairs(TowerFolders["Tower"..value]:GetDescendants()) do
		pcall(function()
			v.Transparency = 1
		end)
	end
	for _, v in pairs(TowerFolders["Tower"..value+1]:GetDescendants()) do
		pcall(function()
			if v.Name == "HumanoidRootPart" then
				v.Transparency = 1
			else
				v.Transparency = 0
			end
	
		end)
	end
	sys.EditValues(TowerFolders["Tower"..value+1].stats)
	upgradeFrame.Model.Value.Configuration.num.Value += 1
	print(value)
end


return sys

UpgradeGui:

script.Parent.MouseClick:Connect(function(x)
	wait(0.1)
	print(script.Parent.Parent.Parent:GetChildren())
	local gui = script.Parent.Parent.Parent.Info2
	if x.PlayerGui.ScreenGui:FindFirstChild("Info2") then
		x.PlayerGui.ScreenGui.Info2.Parent = x.PlayerGui.ScreenGui.Info2.Model.Value
	end
	gui.Parent = x.PlayerGui.ScreenGui
end)

upgrade button serverscript (inside “Upgrade” button):

local upgrades = require(game.ServerScriptService.Upgrades)
local frame = script.Parent.Parent
local deb = true
local del = 0.5
upgrades.Set(frame)
upgrades.EditValues(frame.Model.Value.Upgrades["Tower1"].stats)
script.Parent.MouseButton1Down:Connect(function()
	if deb == true then
		deb = false
		if frame.Model.Value.Configuration.num.Value < #frame.Model.Value.Upgrades:GetChildren() then
			upgrades.Upgrade()
		end
		
	end
	wait(del)
	deb = true
end)

if you have any questions about the code, or simply need more info, feel free to ask.

Thanks for reading.

1 Like
#2

Can I know more for what Model value is used? How value of it is being set?
image

when there is two towers, it would only upgrade one of them

Is it random EVERY time when trying to upgrade for each play test?

#3

sure, the “Model” value is just an object value for the rebel(tower) itself, that way when the info2 frame parent gets set to the playergui, the info frame would have a way of changing info about the tower, and yes, every game you run, so if tower 1 got randomly chosen first , it would be like that for the rest of the game, i have a feeling it is because the modulescript is running on the server, therefore both towers scripts would try to setup values, and the values would get overwritten by eachother, i think, idk.

#4

Do some printing. I love print and it always helped me as a last resort tool for my not working correctly scripts. For global variables declaration in the module script - try to move declaring variables inside functions. I would like to help more but this week is more busy than usual for me.

#5

nevermind, it turns out that the towers were overwriting the module variables, but thanks for the help! :smiley: