MarketplaceService:GetProductInfoの戻り値に関するアップデート

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

This topic was automatically opened after 11 minutes.

JayePirate：「プラットフォームの健全性とレガシー構造の維持のため」とのことですが、具体的にどう改善されるのか詳細を教えていただけますか？私の見る限り、これは既存の動作を変更するだけで、何か新しいことが可能になるわけではないように思えます。

JayePirate: To support platform health and legacy structures Could we get more detail on how this supports anything better? As far as I can tell, this changes existing behaviour without making anything new possible.

本当に後方互換性を壊してまでやる価値があるのでしょうか？既存の挙動は維持したまま、新しいメソッドの使用を推奨する形にはできないでしょうか？

Is this really worth breaking backwards compatibility for? Can’t we keep the existing behaviour with recommendations to use the new method?

Creator.IDはWeb APIで最後に製品を更新したユーザーのIDになり得る、という前提でしょうか？だから今回の変更が行われているのですか？そうでなければ、この発表だけでは全く意味が分かりません。

I’m assuming Creator.ID can be the ID of whoever last updated the product in the web API? So that’s why this change is being made? But otherwise this doesn’t make any sense just based on this announcement.

creatorフィールドのIdはエージェントIDを表しており、ユーザーの場合はユーザーIDとして知られています。グループのエージェントIDは、レガシーな購入用Webエンドポイント以外では使用できません。

The Id in the creator field represents the Agent ID, with users it is known as the User ID. Groups’ agent ID can not be used anywhere except legacy purchase web endpoints.

local MarketplaceService = game:GetService("MarketplaceService") -- レガシーな「.Id」の読み取りが機能するように、生のcreatorテーブルをラップする local function wrapCreator(rawCreator) -- rawCreatorはRobloxが現在返す値: -- Id = userId (ユーザー) または 0 (グループ) -- CreatorType = "User" | "Group" -- CreatorTargetID = t

local MarketplaceService = game:GetService("MarketplaceService") -- Wrap the raw creator table so legacy `.Id` reads still work local function wrapCreator(rawCreator) -- rawCreator is what Roblox now returns: -- Id = userId (User) or 0 (Group) -- CreatorType = "User" | "Group" -- CreatorTargetID = t

これで、戻り値がany型ではなく、ようやく型付けされるということでしょうか？

Does this mean that the return value will finally be typed instead of any

これを行うことはお勧めしません。IdとCreatorTypeのみを使用している既存のコードは、IdがグループIDや作成者ターゲットIDではなくエージェントIDであるため、グループに対しては既に機能していません。また、各グループとユーザーが固有のエージェントIDを持っているという前提を利用しているコードも、これによって機能しなくなります。このグループ所有の

I would not recommend doing this. Any existing code using only Id and CreatorType is already broken for groups because Id is the Agent ID, not the group ID/creator target ID. This will also break code that utilizes the fact that each group and user have a unique agent ID. Please see this group-owned

クロードさん、お願いですからAIが生成したコードをそのまま貼り付けるのはやめてください。コード自体が正しくない場合も多く、かえって混乱を招くだけです。

-- holy claude. please do not just shove out AI-generated code here, you’re just going to end up confusing people especially when the code itself is just, not valid

今回のアップデートは、問題を解決するどころか、かえって不整合を増やしているように思えます。APIを整理するどころか、単に0という値を処理するためだけに、完璧に動作しているレガシーコードの書き換えを強いることになります。CreatorTargetIdがすでにグループやユーザーを正しく識別できているのであれば、Creator.Idも同様の挙動にするか、あるいは非推奨にすべきです。

This update seems to create more inconsistencies than it solves. Instead of making the API cleaner, it forces us to rewrite perfectly functional legacy code just to handle a 0 value. If CreatorTargetId already correctly identifies the group or user, Creator.Id should either do the same or be depreca

Mr927x：たった0という値を扱うためだけに、完璧に機能しているレガシーコードを書き直さなきゃいけないなんて。そもそも、実際にゲームで使われていて、これによって大きな影響を受けるような「レガシーコード」なんて存在するのか？

Mr927x: it forces us to rewrite perfectly functional legacy code just to handle a 0 value What “legacy code” actually even uses this that is in use in any games that would be meaningfully impacted?