[Studio Beta] Collections (コレクション機能)

This is not a nice way to give criticism. Also, if you don’t like the syntax it wouldn’t be hard to make an abstraction that computes these kinds of strings.

Roblox Studioに新機能「Collections」がベータ版として登場しました🛠️ タグや条件を使って複数のインスタンスをグループ化し、まとめて処理できる仕組みです。 例えば「KillOnTouch」タグを持つパーツをコレクションにすると、 ・追加されたパーツを自動検知 ・Touchedイベントを自動接続 ・後から追加されたパーツにも自動適用 といった処理が可能になります。 さらに「Health = 1になったEnemy」のように、プロパティの状態を条件にしたリアルタイムなグループ化にも対応しています。 これまでCollectionServiceで必要だったイベントのConnect/Disconnectといった手間が省け、開発がより効率的になります。

Roblox Studioに新機能「Collections」がBetaで登場🛠️ タグや条件を使って複数のInstanceをグループ化し、まとめて処理できる仕組み。 例えば「KillOnTouch」タグを持つPartをCollectionにすると、 ・追加されたPartを自動検知 ・Touchedイベントを自動接続 ・後から追加されたPartにも自動適用 といった処理が可能に。 さらに「Health = 1になったEnemy」のように、プロパティの状態を条件にしたリアルタイムなグループ化にも対応。 これまでCollectionServiceで必要だったイベントのConnect/Dis

HamiltonZlox: "Model.Enemy[$Health = 1]" HamiltonZlox: "BasePart#KillOnTouch" Great update but this syntax is horrible, was there not a better way of doing this? Seems very unconventional, makes things more awkward & difficult than they need to be. These strings have absolutely no autocomplete o

ゲームオブジェクトのグループ管理が、より簡単になりました。 Studioベータ版で利用可能になった「Collections」は、ライブクエリを使用してインスタンスをグループ化し、そのグループ全体にロジックを紐付けることで、定型コードを削減します。 詳細は以下の#RobloxDevフォーラムをご覧ください。 https://t.co/XjVIoBASGq

Managing groups of game objects just got easier. Collections, now in Studio Beta, use live queries to group instances and bind your logic to the whole group, reducing boilerplate code. Learn more on the #RobloxDev forum below. https://t.co/XjVIoBASGq

Roblox just dropped one of the most useful Studio features in years. Collections (Studio Beta) let you write one live query. Whatever matches joins the group. Whatever stops matching leaves. You write the code once. Roblox handles every connect + disconnect. Especially strong with streaming (part

このトピックは10分後に自動的に公開されました。

This topic was automatically opened after 10 minutes.

Why are the collection methods not showing up here? : ( image 1314×526 44.7 KB

ベータ版のものはそこに表示されますか？

Do things in beta show up there?

APIダンプをスキャンしているだけです。APIダンプに含まれていないものは、そこには表示されません。

It scans the API Dump, that’s all. If something is not in the API Dump, then it won’t show up in there.

So this seems like a QOL update for CollectionService I’m pretty sure I have a library for this exact purpose

Nice, its like a very good version of instence tags!

LuauでFindFirstChildとIsAを組み合わせて「FindFirstChildOfClass」を自作する方が、QueryDescendantsで文字列を構築して処理するよりも高速です。では、コレクションのパフォーマンスはどうなのでしょうか？文字列は自由に入力できるため、解析側でより効率的なルートを選択できる可能性がありますが、Query...

Luau scripted FindFirstChild + IsA to create “FindFirstChild Of Class” is faster than building a string with QueryDescendants that would do that. How… are Collections in that performance? Strings are like, you can type anything in it. Whatever parses it could maybe choose a better route, because Que

image 1007×426 13.1 KB The problem with being so early to the announcement I suppose…

Thanks for letting us know, we’re working on resolving this and we’ll have an update soon.

This feels like benchmarking a hashmap against if x == "foo" and concluding the hashmap is bad. FindFirstChild + IsA is solving a much narrower problem. Collections are a live query/connection-management abstraction, so the meaningful comparison is against all the code you’d otherwise need to mainta

HamiltonZlox: Example: Querying on Live State Just wondering, at what interval is this being checked?

All changes are checked with Property and Attribute changed listeners. So the answer is immediately. In immediate mode the OnAdded and OnRemoved callback will be executed as if they were connected to a changed event. In-radius is the only exception to this rule, it evaluates as part of the post simu

What’s the possibility of getting something like this, but also checking for proximity from another part? Part of what I use collection service for is parts that do something based on distance from the player. Having proximity baked into this would make that much easier and I assume more performant

This is a really awesome update. Would it be possible to support an observer-style API that keeps setup and cleanup together? For example, if each killBrick needed additional memory, we would have to track it separately by instance. An observer-style API could look like this: function killBricks.Obs

There is a proximity filter included in Collections: in-radius . Take a look at this follow-up post for more information on how to use it: Collections: How to group instances with query patterns This extension has not made its way to Instance:QueryDescendants just yet, but we plan on supporting it r

They don’t show in studio either (the function returns any )

Fe_ct: would a list of enums or additional functions not have sufficed A list of enums definitely wouldn’t have sufficed, the expressions are extremely…expressive. Auto-fill is something that can be fixed in the editor. But this doesn’t come from nowhere, like in the post it’s the same as seen in Qu