Model References

Feature Requests Engine Features
#1

An API feature that I and, I believe, a huge number of people would find helpful is the following: model references.

[size=4]Comparable Feature in Another Engine[/size]

In Unreal Engine 4, you get a feature called Blueprints. This, essentially, allows you to construct a “class” using things called “components,” and what you place in the “workspace” are references to that Blueprint. This means that, even if you have 9001 references in your “workspace,” editing the Blueprint changes each of those references to be up-to-date.

[size=4]Why This is Helpful[/size]

Well, let me use an example: trees. In my survival games, I like to not use a randomly generated map. Having the same map allows players to grow attached to certain locations and have “favorites,” bringing a personality to the game that a procedurally generated game could never have. Therefore, I put trees on those islands by hand. However, say I want to add a certain piece of data to trees? Well, darn, I’ve already placed 34 and I have to tediously add that *Value or Script object to each one. Not fun.

If, instead, we had Model References, I could store my one, single tree and make 34 references to it. Then, if I wanted to change every tree I’ve ever placed, I could just, you know, edit one thing and every reference would update.

[size=4]What I Would Want This to Look Like[/size]

Models gain a new context-menu option: “create reference.” Doing this would create a ModelReference object.

The ModelReference object acts a lot like the model. It has one new property: ReferenceName. ReferenceName tells the ModelReference to look for a Model in ServerStorage with the same name as its value. (It may be prudent to add an entirely new ReferenceService designed only to contain models used as references.)

If a ModelReference can find the model to which its ReferenceName refers, it will visualize itself as a “ghost version” of the model it refers to. A ModelReference has its own CFrame, and the “ghost version” is visualized as if the model had been moved to that CFrame using :SetPrimaryPartCFrame(). (This, of course, makes it necessary that all models that are referred to must have a PrimaryPart). ModelReferences can be moved around like normal models.

The “ghost version” of a ModelReference is always kept up to date with the content of the model to which it refers.

While the game is simulating, any and all ModelReferences are instantly replaced with a clone of the model that it refers to, meaning that ModelReferences could be instantiated into the game during simulation and still work.

[size=4]Final Thoughts[/size]

This is a very nice, very helpful feature that I think that everyone would like to have. I have definitely not detailed the ideal solution, but I hope that I’ve given you guys (the engineers at ROBLOX) a good idea of what should be done. All in all, I rely on your expertise to make the best features for this engine.

Thanks for reading and please show your support by thanking this post and posting on this thread to keep it bumped!

2 Likes
#2

Yes! This would particularly be useful for editing large numbers of identical lights at once, something which has has always been an annoyance.

“Oh, you want to see what it looks like with 1.5 brightness? Should’ve thought of that before you put in twenty of them, have fun selecting them all!”

#3

Unfortunately I don’t think that we’ll see this sort of thing any time soon. This kind of feature would be a significant departure from the current “what you see is what you get” nature of 3D building in Roblox, which is quite valuable for beginner and non-technical users.

Also, I think that you’d find that said system would be a lot less useful than you think it would be for the kind of development that people do on Roblox: Instancing behavior is really nice when you’re working on a large scale project where you have a relatively fixed design. On the other hand, when you’re rapid prototyping you don’t actually know for sure what “classes” of object you’re going to need / what things should actually be instanced vs separate objects, making using instancing in those scenarios a bit awkward.

#4

Place the tree model in ServerStorage, and place “placeholder” bricks where you want your trees. Make them a similar size of the tree or whatever. When the game starts, your script destroys each placeholder and replaces it with a tree (randomly orientated, or orientated to the placeholder). If you want to see what your map actually looks like, hit just Run.

I guess the only alternative is writing a “for” loop.

#5

I bet this could be implemented to some extent with a plugin. I’ll definitely write it down on my plugin wish list (Trello).

#6

Stravant,

True, but it can still be available. Beginners dnt have to use it – as usual with roblox features, it would be optional.

Trae,

Yes, I know how it can be done. However, there is still a loss of representation in that system. I want something official and polished.

I think that this has more benefits than negative consequences.

#7

“I think that this has more benefits than negative consequences.”

Keep in mind that development time opportunity cost / technical maintenance debt are additional negative consequences. This would be a really large scale feature needing many engine and studio side features to support it. The developer time to get something like this could go a long way in other areas.

#8

what I would really love to see is the portal objects that the Portal 2 iteration of the Source engine has.

my 2c

#9

I can possibly make this a plugin for you if you’re that interested in it. It seems more like this feature belongs as a plugin anyway.

I’m going to make a few tweaks to this. I think it’s a very good idea, however there are a few changes I am proposing.

There won’t be a need for a root model in ServerStorage, instead what will happen is when you setup a model reference it will be given a ID. When you update any model, all other models with that ID will experience the same change. That way it makes it much easier for you to make changes to your game.

Secondly, I am not including this “ghosting” thing, the reason being that I see no need. However, I may consider adding some sort of beam that shows all models linked to the one you’re currently editing that will appear in current camera when you select one. This will most probably be switched off in first release but be available to include via a setting at a later date.

Any hotkeys you want me to add in specific?

#10

When I need to do something like that, I just command toolbar it. It isn’t all that hard to mass edit the properties of some objects if they are organized correctly.