At least going forwards we’ve fixed that class of problem. New “bind” methods being shipped these days just return a connection object like the one you get when connecting to events instead of requiring you to micromanage tokens to pass to an unbind.
Thanks for the Montserrat fix! It’s a great font but we were seeing all sorts of logspew from the error when trying to load it.
ObjectValue
s can already safely store nil
just fine.
This was in reference to attributes, an attribute set to nil, is removed from its parent.
Sorry, I completely misunderstood. I was trying to point out that Instance
attributes could work like ObjectValue
s but that’s the exact issue haha.
How exactly will this work in the properties window? Would the attribute type be set to an EnumType, then you can pick an EnumItem from the dropdown? Or would it be a special picker that picks EnumType and EnumItem at the same time?
For the time being you can’t create Enum attributes through the UI, you have to create them via the command bar or a community plugin that knows how to do it (but after that you get the properties pane value picker for the particular enum type you set).
The reason we didn’t initially add a picker for creating them is that there’s… well… more than 100 enum types. Some of which are internal, some of which are public, and some of which are kind of… inbetween. All that means it’s really hard to programmatically decide which options to actually give people for what enum types to create.
What about using the same style as the command bar? Like a selector that’ll have a text box inside limited to enums and as you type it’ll auto fill same as the script editor.
I’ll have to make an example on what I mean when I get home but yeah…
We still want to figure out how to hide the internal Enum types though, which are subject to removal from the engine at any time, but not currently strictly protected from use by developers.
On the scripting side, devs know that if an Enum isn’t associated with a public API they’re developing against they probably shouldn’t be using it, but there’s much less awareness from the UI side.
Well… wouldn’t you have a list of these enums? or are they so frequently coming and going it’s impossible to keep track. If you had a list, you could easily remove those from the main list and thats it.
Will we ever be able to selectively replicate instances/instance attributes to certain players or not?
Providing such an API is a very large hammer (it comes with a lot of forwards compatibility concerns and what not). The reason something like this doesn’t exist is because we’d rather find less blunt instruments to solve the same kind of problems that such an API would.
Streaming enabled is an even larger hammer. It’s selective replication- encased inside a blackbox. Next to no API to interact with it, work with it, or even try to influence it in the direction you’d approximately like it to go in. It’s a bull in a china shop.
If streaming enabled is the “solution” Roblox is going for then I’ll be damned. Roblox needs to separate the Weenie Hut Jr developers from the competent ones (API-wise). Roblox caters to the younger, less competent developers rather the ones who can stand on their own two feet (the ones who often make the best content), so if we had more granular API at our fingertips Roblox would truly be “powering imagination”.
One of my posts from a few months ago highlights the underlying tonedeafness of streaming enabled (for real):
Roblox isn’t generally against fine grained control over things, but selective replication happens to be in exactly the area where Roblox is most philosophically adverse to providing fine grained control:
The philosophy in question is that Roblox generally tries to prioritize being a simulation of reality more-so than a traditional game engine. This has a couple key benefits:
-
You get sensible interactions and visuals which are grounded in people’s real world experiences out of the box without having to fight for them.
-
By grounding things in physical reality, as the engine evolves over time, content which developers have built against it naturally improves because that evolution takes the form of the engine becoming a more accurate simulation of reality.
Taking this approach has served Roblox well at many points throughout its history, but it certainly isn’t without its costs. In particular selective replication is very not-reality-aligned, which is why Roblox is adverse to it. Compare this to the streaming controls which were recently introduced: They let the developer help the engine bring the best reality possible to the user, but aren’t reality altering in and of themselves: There’s still a shared physical world in which the players are interacting.
Hopefully that at least helps shed some light on why a selective replication feature hasn’t happened yet despite it seeming like an obvious addition from the game engine perspective.
I noticed a new filter button has been added to Explorer’s search box. What does it do?
I don’t agree at all. Not having selective replication means we either rely on the server for everything - which is laggy and nonreflective of reality - or we have to roll our own lag prediction systems in convoluted ways. By not providing this feature, you are not moving the engine toward an ideological goal, but instead making it more difficult for developers to make the games they want. They’ll still do it, it’ll just have worse performance and be buggier than the alternative.
I also want to bring the best possible reality, but it also means bypassing a lot of server code altogether as it stands.
I strongly encourage you to read the post linked in my last reply.
This is an excerpt from that post:
On the topic of Roblox prioritizing being a simulation of reality, imagine in real life there’s a house with a safe containing 40 lbs of gold. If I walk in front of this house, should I immediately know that there’s 40 lbs of gold inside that house because I’m now within X distance of this house?
I’m no Albert Einstein, but last I checked, that isn’t exactly how reality works by any stretch of the imagination.
short answer: It filters.
long answer: It gives you some presets on filtering instances whose specific properties are set to what you’re checking. It shows a learn more button, which redirects you to a devforum post about the explorer update.
I’m sorry, and, I don’t want to shoot the messenger or anything, but, this philosophy is bad in my personal opinion… I agree with the concern of tech debt, and the concern of creating tools that are too blunt to allow for precise control (nobody wants a large hammer, when it comes to something like networking, people want precise tools)
Games are not an accurate simulation of reality, and, Roblox is also the least realistic game engine (by design). When I started developing on Roblox (and when I do develop on Roblox) I don’t want to think “ah yes, this is just like reality and what I would imagine reality to be like, and I am bound by the same restrictions as reality.” I want to think what I often think whenever I am excited to work on a Roblox project which is “I can do something really cool that I imagined, and I can make it work, and provide it to other people so they can enjoy it.” Whether my expectations live up to reality are to be determined when I get to observe the outcome of my project.
If Roblox wants to create a good simulation of reality, they should be focusing on providing users (developers) with more fine grained control so that those users can create the reality that they want to create, that they imagine, instead of the reality that is presented to them. Reality is fine grained! Networking is fine grained. Imagination is fine grained. If you can’t hint to the engine what reality is supposed to look like for your game, for your vision, or your idea, what do you do? You are stuck with an unrealistic outcome, likely using hacky workarounds or crude reproductions of the behaviour that you want to achieve. Fine grained control over replication is not unrealistic, it is a tool to create hyper-realism, things beyond reality (like imagination).
If the behaviour can be produced by a developer, and Roblox is a simulation of reality, than Roblox providing the same behaviour cannot be considered to be “unrealistic.” Fine grained streaming control is something developers can emulate, but the problem it is a pain, and comes with large costs that make it unsuitable for large scale use. The costs could be lower if it were something the engine supported and this would open the doors for developers.
A lack of control over replication is a limit, because space is a limit. Space is messy. Space is a constraint. It costs to manage that space. It costs to control that space. A developer can write networking and replication from the ground up inside Roblox, and that is the cleanest way, a big cost. Whereas the easiest and simplest way is to build structure atop Roblox’s constrained networking to reparent things, put things into Camera
s, expect them to break, another big cost, but a trade-off. Neither are worth it, neither are sustainable, hence, nobody has done it on a large scale. Ideally, there should be a solution that is both easy and simple, but also clean.
I think this philosophy confuses reality with general simplicity, ease of use, cleanliness, etc. I think that Roblox strives to create a simple and easy to use tool, to reproduce the imaginative “reality” a user wants to create, not to reproduce reality 1:1. It just doesn’t make sense to both want to power imagination, but also restrict the tool to reality at the same time.
Tl;dr
Reality:
- Is messy
- Is unpredictable
- Is hard to control
- Doesn’t always do what you want
- Causes imagination to need to be powered
Streaming (currently):
- Is messy
- Is unpredictable
- Is hard to control
- Doesn’t always do what you want
- Still leaves some room to be desired on the powering of imagination
Welcome to Roblox, where games are called “experiences” and obvious features aren’t added because Roblox is less of a game engine and more of a “simulation of reality”. This is a strange era of Roblox indeed, one I hope we move past sooner rather than later.