Scripting Helpers is winding down operations and is now read-only. More info→
Ad
Log in to vote
0

Problems with Transparency ?

Asked by 9 years ago
function AdvancedLoad()
    local f = game.Workspace:GetChildren()
    for i = 1,#f do 
        if f[i].Name == "Program" or f[i].Name == "SProgram1" or f[i].Name == "SProgram2" then 
            local things = game.Workspace.f[i]:GetChildren() 
            for e = 1,#things do 
                if things[e].ClassName == "Part" then 
                    for a = 1,100 do 
                        wait()
                        things[e].Transparency = things[e].Transparency - 0.01 
                    end 
                elseif things[e].ClassName == "TrussPart" then 
                    for b = 1,100 do 
                        wait()
                        things[e].Transparency = things[e].Transparency - 0.01
                    end 
                elseif things[e].ClassName == "WedgePart" then 
                    for c = 1,100 do 
                        wait()
                        things[e].Transparency = things[e].Transparency - 0.01
                    end
                elseif things[e].ClassName == "Model" then 
                    local parts = game.Workspace.f[i].things[e]:GetChildren() 
                    for j = 1,#parts do 
                        if parts[j].ClassName == "Part" then 
                           for d = 1,100 do 
                           wait() 
                           parts[j].Transparency = parts[j].Transparency - 0.01
                           end
                        end
                    end
                end
            end
        end
    end
end

For my holo, I tried to make the programs appear gradually instead of popping up. This is the function I came up with (which is called later in the script). However, whenever I try to start a program, it doesn't work, and the maps still stay transparent, because I set them at Transparency 1. Could anybody help me with this problem?

1 answer

Log in to vote
1
Answered by
Perci1 4988 Trusted Moderation Voter Community Moderator
9 years ago

It first should be said that your vairable names are pretty bad. You always want to make your variables relating to the object they're equaling, for readability purposes. Readability is arguably even more important than functionality, as readable code is much easier to debug and easier to make more efficient.


Your main functionality problem is the code (line 5)

game.Workspace.f[i]:GetChildren()

Although it may seem like you could use f[i] in a path like this, you can't. What the script is basically doing is looking for a child named "f" in Workspace, then looking for a child named the value of i in "f". You therefore get the error, "f is not a valid member of Workspace"

You could convert f[i] to a string, then access it with brackets;

game.Workspace[tostring(f[i])]

but this is pointless.

You already have access to the object, so just use it. No need for the path.

f[i]

Now your code will function, but it should be noted that it will only make one part visible at a time, so if you have more than 10 parts in your model this will take an extremely long time. It takes a little less than 3.5 seconds to make one part fully visible -- and it will not move on to the next part until the first is completed.

You just need to reverse the loops, i.e.

for i = 1,100 do
    wait()
    for _,v in pairs(model:GetChildren()) do
        --no wait() in this loop, so it will complete almost instantly
        v.Transparency = v.Transparency - 0.01
    end
end

Although it would probably be better to just use the for loop's variable directly:

for i = 1, 0, -0.01 do--startNum, endNum, increment
    wait()
    for _,v in pairs(model:GetChildren()) do
        v.Transparency = i
    end
end

One last thing I'll let you know is that instead of all those elseifs, you can just use :IsA("BasePart"). This method will return true if the thing it is called on is what was stated in the parentheses. BasePart is a class that includes all Part objects.

1
Just wanted to let you know that in the last bit of lua code you posted in this answer, there are two variables called "i". It would be better to call the "i" in "for i, v" as "for _, v" since that "i" isn't being used and could cause semantic errors TurboFusion 1821 — 9y
0
Thanks, didn't notice that. Perci1 4988 — 9y
Ad

Answer this question