No. game.Workspace["Well"] is just a reference to a model. In this case, a model called “Well” located in game.Workspace. It can be replaced to any reference to a model.
What I usually do is serialize the positional values when they buy the plot for everything and save those for on buy, when it is they just deserialize and spawn in by fading their transparency. If you want them to like bounce down like legos simply make a generic for loop nested to set their y up by like idk, 5 studs? Then smoothly change that offset to 0.
YAY! It worked, thank you sooo much! Also, when it builds itself, some of the parts turn red, then go back to the original color, also, if I wanted to make the animation longer, where would I do that?
1 Like
Oh, sorry I see the time, I didn’t see it before, thanks!
1 Like
Remove the “Color” entry in originalProperties, and remove the part.Color = Color3.fromRGB(255, 255, 255) line.
1 Like
ok, thank you! Have a good day!
1 Like
I’m sorry to bother again but one last thing, if I wanted to make a remote function or remote event, so I can fire the tween in another script, how would I do that?
It’s a bit hard to answer because it depends on the other scripts in your game. If you’ve given it a try I’ll take a look at your code and see where you’re going wrong, but it’s a widely covered topic so read try reading up on it yourself first.
Here are some decent places to start reading:
And of course also try the search bar here on the forums 
Ok! Will do! Thanks man! Have a amazing day :))
1 Like
Hello ThanksRoBama, sorry for asking something rather stupid I don’t quite understand what this means could you explain why you clean tables and how local variables go out of scope?
If you wrap it all in a function and have the “original property” dictionaries be local variables in that function, they’ll go out of scope and automatically be garbage-collected when the function is done, so you don’t have to worry about cleaning the tables up.
And also,
It gets really confusing here, you created a new table:
local dictEntry = {}
and you did this:
dictEntry[property] = instance[property]
as far as I understand, you assigned the property dictionary to the dictEntry equal to the instance table properties. When it comes to
dict[instance] = dictEntry
I lost it.
1 Like
RIP Server, what I do to avoid lags is tweening on clients end
1 Like
Whew, it’s been a while since I wrote this but I think I remember 
So the full function is this:
function instanceListToPropertyDict(instances, propertyList)
assert(typeof(instances) == "table")
assert(typeof(propertyList) == "table")
--[[Given a list of instances and a list of properties, construct a dictionary like so:
dict = {
[instance1] = {property1 = instance1.property1, property2 = instance1.property2, ...},
[instance2] = {property1 = instance2.property1, property2 = instance2.property2, ...},
...
}]]
local dict = {}
for _, instance in ipairs(instances) do
local dictEntry = {}
for _, property in pairs(propertyList) do
assert(hasProperty(instance, property), string.format(
[[Instance '%s' (a %s) doesn't have property '%s'.]],
tostring(instance), instance.ClassName, property)
)
dictEntry[property] = instance[property]
end
dict[instance] = dictEntry
end
return dict
end
… and the whole reason it exists is so we can do this:
local tween = TweenS:Create(part, tweenInfo, originalProperties[part])
That third parameter to Create needs to be a dictionary where the keys are properties to tween, and the corresponding values are what those properties should be tweened to. On the wiki there’s this example:
You can see they manually create the goal dictionary by setting various keys to various goal values. instanceListToPropertyDict is just an automatic way of creating lots of goal dicts from a list of parts and a list of property names you want to be in the goal dicts.
It returns dict, short for “dictionary”, and populates that with a part for each key and a tween goal dictionary for each value. So what gets returned is a dictionary containing dictionaries. So it’s a (Instance to (PropertyName to PropertyValue dictionary) dictionary). Meaning the keys of the dictionary are Instances, and the values are dictionaries whose keys are property names and whose values are property keys.
If you wanted to get the tween goal dictionary for a specific part, you’d do it like so:
local originalProperties = instanceListToPropertyDict({part1, part2, part3}, {"Color", "Position"})
print(originalProperties[part1]) -- Should print someting like {Color = (255, 255, 255), Position = (10, 5, 0)}
If you wanted to get what a specific property of a specific part at the time that instanceListToPropertyDict was called, you’d do
print(originalProperties[part1].Color) -- Should print someting like (255, 255, 255)
Welp, hope this clears it up a bit If dictionaries within dictionaries is still confusing to you, I recommend just playing around with the code, maybe stepping through it with the debugger, to see what goes on and get an intuition for it.
Well, the rules of variables scopes are explained really nicely here: Scope | Roblox Creator Documentation . Once you understand when variables go out of scope, read up on garbage collection. There’s lots of guides here on the dev forums.
I honestly don’t remember why I wrote that sentence, it’s true but not especially relevant xD
2 Likes
Thanks @ThanksRoBama! You are so smart! I am still trying to understand the explanations even though you explained really well. I wish I can be like you! Thanks for everything!
1 Like
Hey, I tried using this in Zednovs kit with no luck, I managed to get it to pass the model, but when it spawns and try to start, it breaks itself, getting stuff like this
1 Like
Did some digging
PurchaseHandler - function Purchase(tbl)
Added the animation
Got an error:
The model doesn’t have it’s PrimaryPart set. Let’s just use any Part in the model:
No errors, but it’s buggy AF:
Figured out that Zed’s kit just calls Purchase every time the button is touched, even if it’s already been purchased! Since it slowly fades out instead of instantly being destroyed, that’s 10s or even 100s of times!
My animation function doesn’t correctly deal with being called again on the same model before the anim is done. It thinks the state of the model is actually the original state, which explains why all the parts are transparent, tiny and moved/rotated when the last animation out of the 10s or 100s is done.
Don’t wanna fix my script xD Instead let’s fix Zed’s:
Any time a button’s purchase is made, we never want that button to be “touched” again because it’s done it’s job. Here’s how I make that happen:
Tadaaaaaa 
Here’s the fixed PurchaseHandler, you should just be able to replace yours with this one.
PurchaseHandler.rbxmx (11.8 KB)
7 Likes
Thanks RoBama!
Haha 
However there are some tycoon kits (like them from RoboCrafterLP or Twin) that already have tycoon animations. (and other cool features).
1 Like
Hey RoBama. Your tycoon animation function is awesome, I’ve implemented it into my tycoon however I noticed tweening on the server causes a lot of lag and causes the parts to tween incredibly slowly. Therefore, I tried implementing this on the client but I’m unsure of how to reference the model from the server onto the client as passing the model gives me a nil value. I tried passing the name of the model from the server to the client but I then get an error saying that the model does not have a primary part and I’ve double-checked that it does contain one. The error appears on this line in the function: local originalBasePartCFrame = buildingModel.PrimaryPart.CFrame I fired a remotevent and this is how I’m referencing the model on the client-side.
ClientTween.OnClientEvent:Connect(function(modelName)
animateBuildingIn(workspace.Tycoons["Tycoon [1]"]["Purchased Buildings"]:FindFirstChild(modelName), TweenInfo.new(0.25, Enum.EasingStyle.Quad, Enum.EasingDirection.Out)):Wait()
end)
Any help would be greatly appreciated. Thanks!
2 Likes
You are my savior lol, i had to do a very hacky way, but this is so much better lol, thanks
1 Like