Custom Instance Service - Create Your Own Instance

Feature Requests Studio Features
, , , ,
1

Custom Instance Serivce is a proposed new service that allows users to create and store custom instance templates via a CustomInstanceTemplate instance. Once a template is created you can add those types of instances to your game.

When selecting a template instance your properties window shows a layout where can add properties and set their default values. CustomInstanceService does not actually add classes to studio- they merely add only the CustomInstanceTemplate and InstanceTemplate instances, =InstanceTemplate merely takes on the appearance of a CustomInstanceTemplate in studio, acting as a pseudo-class without being a real class. A CustomInstance during runtime acts as a pointer for stored data.

The custom properties window will support all visuals seen in the properties window including custom enumerations, enumeration dropdowns, read-only properties, and property group dropdowns.

Register instance class.
The name and description have already been specified in the properties builder widget.

local CIS = game:GetService("CustomInstanceService")
local template = CIS:FindFirstChildOfClass("CustomInstanceTemplate") :: CustomInstanceTemplate
local class = CIS:CreateClassFromTemplate(template)

Add logic to functions

local CIS = game:GetService("CustomInstanceService")
local template = CIS:FindFirstChildOfClass("CustomInstanceTemplate") :: CustomInstanceTemplate
local class = CIS:CreateClassFromTemplate(template, "ClassName", "ClassDescription") 

class:RegisterMethodCallback("FunctionName", function(...any)
-- write function logic here.
end)

:RegisterMethodCallback() only runs when studio runs, if you would like this to run in studio’s edit mode you can call this within plugin security context. This allows the method callback to run in studio’s edit mode allowing safe encapsulation. Plugins will have a new Custom Instances security toggle.

Once your template instance is made you can add instances of your custom class like normal instances via the + button. You will be able to connect to events, call methods, and read/write properties. If an instance was created whose corresponding CustomInstanceTemplate instance was bound to a plugin, then it would display a plugin icon to the right of the instance’s name in the explorer that when hovered over displays the name of that plugin. By removing the template instance all instances made that template become orphaned- and are no longer scriptable, this is indicated by a warning icon next to the instance’s name in the explorer.

I believe this service will directly compliment all other areas of studio- especially plugins which would then gain the ability to safely interact with live servers without arbitrary script injection. Custom Instances will act as a more intuitive approach for adding custom objects to your game without having to rely on modules. Custom instances are readable, intuitively scripted, and greatly enhance developers workflow.

3 Likes
2

First off, why limit this only to plugins?
Second,

You’re suggesting something here entirely different.

I suggest you revisit this topic with more in-depth points.

1 Like
3

I do like the thought of adding a new “CustomInstance” service as well as a ‘CustomInstanceTemplate’ instance that you could store under CustomInstanceService. This would take longer for them to make- but its also more awkward because you’d have to place them in every game. Plugins would be responsible for creating custom instance add-ons in all your games, so it seems like plugins would be a priority.

I never meant that plugins would use this exclusively- I mentioned plugins because its a stronger proposition to mention how a studio feature would compliment preexisting tools in studio (especially ones in need of new services) rather than just saying “heres a new service.” Custom instances change the behavior of plugins to make them interact with live servers rather than being treated as mere studio tools- which I think is important for the plugin market and in general makes plugins much more valuable and useful.

Two birds one stone- update studio with a powerful new service that compliments all aspects of studio, and directly solve the inadequacies of plugins.

4

that just pointless bloat
You effectively reinvent functions but make them bloated for no gain
How is it better over

local Template = function(ins:Instance):()
  ins.Name = "a"
  ins.Archivable = false
  ins.Parent = workspace
end

???

1 Like
5

This service isn’t a reinvention of instancing- its a service that allows developers to create their own instance classes with their own properties, events, and methods. These aren’t real classes, the instances made only appear like real instances- they’re just pointers that look like instances in workspace.

Quite literally I want to be able to instantiate objects and use them as add-ons for roblox via plugins.
If you attempt to create an instance that does not exist in roblox it can be made from using this service.

local hitbox = Instance.new("Hitbox") :: Hitbox
hitbox.Adornee = workspace.Part
hitbox.Hit(function(characters: {model})

end)
hitbox.Enabled = true
task.wait(5)
hitbox.Enabled = false

Studio would show them as if they were real instances without them actually being real instances- instead of Instance.new() throwing an error it would attempt to look through CIS (CustomInstanceService) for a template.

This class of instance doesn’t exist in roblox, but through the use of a service I would like something like this to be possible so my plugins can make pseudo-instances for games.

Some other software has add-on capabilities like this- so I know its possible.

6

So just OOP bloat?
Should’ve said that earlier.

No real justification for that
It will be unoptimized, require more replication logic and in general will make everything worse.
Same problem “frameworks” like “knit” ran into being not scalable once you apply logic and taxing the heck out of performance.

2 Likes
7

This sounds like a lot of additional bloat for minimal gain that would only end up confusing developers and causing issues down the line. Imagine if Roblox were to one day add a “Hitbox” instance into the engine natively, now how is that supposed to be treated in this scenario? Does the “Custom Instance” take priority, therefor making it impossible to take advantage of this new instance, or does the engine one take priority?

There are arguably way better methods to achieve this sort of thing that don’t come with all of these problems attached (the ability to attach modules to an instance would be one such example). Just because other software can do it does not mean “it’s possible” for Roblox to do it, that’s not how programming works and is entirely dependent on existing architecture & implementations.

2 Likes
8

Its not bloat at all, it makes game mechanics a lot more organized and makes plugin injected scripts more organized as well, roblox replaces services with instances all the time- I mean they just released input instances when user input service did the job just fine. Its the same thing. The justification is readability.

“It will be unoptimized, require more replication logic and in general will make everything worse.”
This entire statement is subjective to how you use it- as with everything else in studio.

1 Like
9

TL;DR: It’s for OOP readability, which roblox has already been adding instances for- mostly to supercede services.

Roblox instances would take priority- and it would throw a warning/error in output if you had a template named after a real instance. I also don’t think it would be confusing as long as there was an icon and label displaying the template/class. And the template itself would need to be under this service, the template would also have an icon/label displaying if the instance was created from a plugin. Roblox already uses labeled icons with some instances:

image

This is what other software does with add-ons, I think its very fitting for plugins..

This is all just a suggestion of course, as you said it really is just an OOP instance- but considering roblox did this with IAS I think readability is enough of a reason to do it like this. Attaching a module does work- but I don’t think its enough, when logic is attached to multiple instances those instances need to be visibly unique from roblox’s instances. I actually do like your example a lot because adding custom properties/events/functions to one of roblox’s instances would be desirable as well.

For example, I was working on a plugin that creates 3d particle emitter instances that intuitively act like regular particle emitters, and this does work- but its hard to organize a plugin’s pseudo-instance if it looks like a roblox instance, and while it can have bindable events to connect to events and fire functions its just not obvious what should be done. Whereas with an instance you’d know to just type a period or colon to bring up the events and methods.

I could imagine not allowing custom icons when a module is bound would make it difficult to distinguish from a non-bound instance. See how its just impossible to tell its from a plugin?

image
image306×127 5.13 KB

I think if roblox made it so that you could bind a module, then the icon displayed a bound module with a custom icon then it would be a lot more intuitive, but even then if you wanted to make a pseudo-instance you’re limited to using attribtues which don’t yet include enum dropdowns or custom enums in general. You’d also end up mixing roblox properties with custom properties.

Whatever the case, my argument is purely that plugin injecting and OOP mechanics would greatly benefit from making logic bound to instances (whether custom or roblox) visually unique while blending naturally with how instance properties, events, and methods already appear in scripts/explorer. I think roblox is already moving towards something like this, evident by their plans to make all studio actions scriptable and the release of IAS- if their goal is to mirror the workflow of other development software then making room for developer-made add-ons should be a definite long term goal.