Closed Narazaka closed 4 months ago
There are examples distributing the 'brson' package for uploading to Resonite.
Ex. RadDoll v2 (It's free) https://tonomaoo.booth.pm/items/3741802 Muon https://flastore.booth.pm/items/4613679 and you can find more on BOOTH.
But yes. I'd like to prefer more official way to packaging distribute.
Some notes from @Frooxius in #1441, @Narazaka @akiRAM3:
This is something we can look into at some point.
Just a note here, brzon, 7zbson and so on were never designed or intended for object exhange like this. They are definitely very fragile for this kind of use and we strongly discourage their usage for this purpose.
I've been looking into this one, I feel like this wouldn't be too complicated to implement.
I'm deciding on what to name the package itself, there's a few variants on "ResonitePackage" we could consider:
.ResonitePackage .ResoPackage .ResoPack .ResPack .RePack
"RePack" is very short and punchy, but there's potential connotations with the piracy terminology.
.ResonitePackage is most descriptive, but also pretty long. However that's not that unusual, e.g. there's .UnityPackage too.
.ResonitePackage sounds the best out of the ones you provided. It's long but descriptive, and I'm not a big fan of abbreviating the already short platform name.
You could also call it .gloopie or .gloop
.resonitepackage
has the added benefit of existing as free advertisement of the platform. Someone sees a .resonitepackage
, they wonder what it is, and look up the extension, and find out it's an asset bundle for the platform Resonite.
It's also entirely unambiguous what it is for, and fits precedent established by other engines such as .unitypackage
files.
Yeah, I'd be a fan of just .resonitepackage or .resopack so it's clear and searchable when we have documentation setup for it. .repack or something like .package would be too easily confused with other files and the last thing the platform needs is people getting pointed in the wrong direction by Google.
@shiftyscales Yeah that's kinda what I was thinking too, it gets the name out there as advertisement too.
I think I'll just go with .ResonitePackage
As the author of Modular Avatar, finding a way to maintain a common avatar that can be used in multiple platforms (vrchat, resonite, etc) is a long-term goal of mine. Having a way to package both assets (textures, meshes, etc) as well as protoflux programs (for things like expressions, toggles, etc) for easy import is a prerequisite of this.
I expect that one of the major use cases of this will be to import avatars; it would be nice to simplify the structure of avatars when importing them in this manner. The avatar setup tool in resonite currently creates a ton of components with very intricate configuration on the avatar; it would be good to be able to boil this down to a much smaller number of parameters (eye position, toolshelf position, etc) and have them be expanded somehow in the setup process.
I would like to suggest giving an export option for if avatar protection is switched to the importing user or not, for say, local backups. Unless a different feature is planned for that purpose, of course.
@bdunderscore With this feature, you (or anyone else) can fully setup avatar in Resonite the way you want it to be for new users.
It is essentially a way to package any object as it is in Resonite into a single file that can be distributed externally.
It doesn't change structure of avatars in any way, but it allows creators to pre-setup them in a way that user doesn't have to do that themselves.
@gameboycjp What would be the main risk there? If it's your local backup, then users shouldn't get access to it, unless your files leak.
If your files leak, then they already got the files, so I don't know if this would be a big stop for the users.
I didn't think about that. My apologies, feel free to mark my comments as off-topic.
@Frooxius are you planning on also being able to package dependent assets such as textures, meshes, etc, as well as the resonite object structure?
@Frooxius are you planning on also being able to package dependent assets such as textures, meshes, etc, as well as the resonite object structure?
Yes, all assets will be included. Including ProtoFlux etc.
@bdunderscore Yes. This will include absolutely everything that's needed for whatever object you export.
"Assets are including" means StaticTexture2d, StaticMesh component and resdb url are in the package? Or image file (like png, jpg) and mesh file (like ???) are in the package?
Everything needed for your avatar or object to look exactly the same as when you exported it will be inside the package.
This includes ALL assets, all slots, etc.
For example, if I import into Resonite launched offline with no asset cache, will it all show up?
When you say "assets are included", do you mean that the resdb url is in the package? Or is the asset file entity in the package? I think both can be said that the assets are included.
Thank you for adding some specificity.
Asset files are directly included in the package.
@lill-la Yes. Everything needed for the object is included in the package, so you can distribute things offline. It doesn't depend on anything being stored in the cloud on your account.
There's not going to be any resdb's in the package.
I see. Thanks.
Is there a problem that when I import a StaticTexture2D PreferredFormat that is BC7_LZMA, the asset url is local, so it causes CPU-hogging on my computer?
And can that be solved with the (+variants)
export option?
That sounds like a bug, and we'd recommend submitting that to this issue tracker as a separate issue to stay on topic.
The variant option, includes all variations of assets.
@lill-la The (+variants) option will include already computed variants into the package, so users importing the package don't have to compute them locally.
Using that option will reduce the CPU load and speed up the loading process, but it also results in bigger package.
There's a lot being discussed here and I believe this is the expected behavior. But for clarity:
SimpleAvatarProection
component..resonitepackage
SimpleAvatarProtection
component will fill in the UserID with the person who did the package import.I assume that's how this will be setup to work so users won't need to manually add avatar protection, correct?
From my understanding that seems to be correct (would need to still be clarified by the devs, but I'm pretty sure).
But there is one point of concern I have with this functionality, is will there be some mechanism to prevent people from exporting avatars to which they do not have permission to / do not own. I.e. prevent people from exporting someone else's avatar?
This could be an issue like in the resonite grid space headless where everyone is builder, if there is no mechanism preventing this, a user could in theory export someone else's avatar, and then re-import it with the simple avatar protections changed to allow them to equip and modify the avatar.
@Stellanora64 Exporting a package, is driven by the regular export menu. The regular export process, listens to Simple Avatar Protection.
So this is the same as you trying to export the avatar root of a protected avatar in the current build which fails due to Simple Avatar Protection.
EDIT: There may be some added logic in export/import added to handle things. But we won't intentionally allow users to export avatars that are protected.
Will this be able to export worlds as well?
This is probably out of scope but would it be be possible for Resonite to create a registry (windows) to associate itself with .ResonitePackage files?
So if you double click it when resonite is running, it focuses resonite and it will bring up the import dialong (or it just imports it) Also as a bonus maybe opening a ResonitePackage file when resonite isn't running, it's going to start it and import the file in Local wold/Home cloud once everything is loaded.
This is just an idea, but it would behave more similar to Unity Packages for example and I think it would be a neat addition.
Would the lack of avatar protection integration lead to problems with paid assets? I'd think these packages are meant to make importing purchased assets easier, and I wouldn't expect new players to know how to set up avatar protection for themselves manually.
@gameboycjp it will automatically change the simple avatar protections to apply for the user that imported avatar if the avatar already had simple avatar protections as described here https://github.com/Yellow-Dog-Man/Resonite-Issues/issues/950#issuecomment-2154055967
Froox confirmed this in the discord somewhere but I don't have the link.
@marsmaantje Prime has said in the discord this will allow exporting worlds as well
Froox confirmed this in the discord somewhere but I don't have the link.
https://discord.com/channels/1040316820650991766/1154514007479287942/1248413599450267740
@PointerOffset Yes, that's currently the plan. If you setup avatar protection that's set to yourself, the package import will rewrite those ID's to whoever is importing the package.
We could add optional toggle on the SimpleAvatarProtection itself to disable this behavior (or enable it, but it might be better on by default, just to avoid confusion when creators forget to turn it on).
@marsmaantje The current implementation doesn't support exporting Worlds, but that can be added if there's interest. There's a bit more complexity with worlds, because they can link other worlds within themselves and those would need to be included too in the package and linked together.
It's not avatar specific and can export any normal object, right?
Will this be able to export worlds as well?
If so, to do single worlds, you could probably just have everything under a "world" slot or similar. Then have something to reset that slots transform if it isn't default, or something else along those lines.
I think package should not have record id? (source: extracted payload from the #dev-log post) Doesn't it assumed that record's ID is across system's entries?
I'd like to also note about the "ownerId", I feel it's better to have other name like "author", but this would depend on how packages be built and be used (i.e. export record directly and use it for only backup)
@gameboycjp You can export any object, it's not avatar specific.
You could just save the world as object right now, but that's a bit... messy. And it wouldn't recursively save any reference worlds.
@KisaragiEffective It needs to have RecordID and OwnerID, because those are used for identity purposes when referencing records.
This is probably out of scope but would it be be possible for Resonite to create a registry (windows) to associate itself with .ResonitePackage files?
So if you double click it when resonite is running, it focuses resonite and it will bring up the import dialong (or it just imports it) Also as a bonus maybe opening a ResonitePackage file when resonite isn't running, it's going to start it and import the file in Local wold/Home cloud once everything is loaded.
This is just an idea, but it would behave more similar to Unity Packages for example and I think it would be a neat addition.
Should a I make a separate issue for this or would it fall under this issue?
World exportation could be pretty slick. The demand is probably limited, though. If it's a bigger effort, I would let object exportation exist for a little while and see how much it's used first.
World exportation could be pretty slick. The demand is probably limited, though. If it's a bigger effort, I would let object exportation exist for a little while and see how much it's used first.
exporting a world is no different than exporting any other object. At least in the context of resonite packages. So yes you can export a whole world as a resonitepackage
Not quite, read up on frooxs previous responses to my comments.
Besides the metadata that exists in a standard Resonite record, will there be a way for asset authors to include custom metadata within the package? i.e, links to where the asset can be bought/downloaded, licensing/usage terms, setup instructions, etc.
The License, Comment, and ContactLink components sort-of cover this, and while I try to include all three of those on my creations, I rarely see them getting used in general, not to mention they're only visible through the Scene Inspector.
Considering how this custom metadata gets displayed is another issue; Would it be shown on import? In the file browser/inventory? And at that point, would it be better off hosting this metadata in the default record structure/schema itself so it's not some sidecar to resonitepackage files?
Currently, some meta-data is included but that's mostly data for Resonite itself to understand the file.
If these are treated how unitypackages are, you are very much aware of what you're getting yourself into before you have access to the file. For example a gumroad product page could lead to a resonitepackage download on purchase. You could include additional meta-data in Readmes or other documents, which is again another common approach on gumroad or similar sites.
We could add additional meta-data but as you say we'd then have to display that in-game, which is probably better served by our more long term goal of an Item/Avatar/Object Marketplace see #1473
@djsime1 That should be a separate thing/request probably.
Generally the goal of this is to keep the package format itself as "slim" and generic as possible. Any metadata and other information should be included by those generic components, because that lets them to be used across different systems - whether you publish the avatar in-game or through packages, you can use the same set of components.
If there are particular use-cases, we could collate some metadata in the package itself - but this would require some functional use cases to do that.
If you want to include instructions, you could also just include a text document in-game that pops up with the avatar when it loads in. I don't understand fully what other metadata you might need, but that's just my lack of experience.
That's actually a very good idea. You could include it in the hierarchy and then it'll be included in the package. Instructions, a thank you for the purchase etc could all be included as just a text object floating next to the avatar.
This has been added in 2024.6.10.1405, hopefully this helps a lot!
This currently doesn't support exporting worlds. For any additional functionality on top of this, please make new issues requesting specifically those and we can look into them!
Is your feature request related to a problem? Please describe.
Especially in the culture of customizing purchased assets that cannot be redistributed, such as avatar assets, it is very convenient to start with a unitpackage that has already been set up by the seller. Resonite, on the other hand, has no such mechanism, so a common setup must be done each time by each user, which is cumbersome and inefficient.
特に再配布不可な購入アセットをカスタムして使う文化があるアバターアセットなどにおいて、販売者がセットアップ済みである状態からスタートできるunitypackageはとても便利です。 それに対してResoniteではこのような仕組みが無いために共通のセットアップを各人が毎度行わなければならず、煩雑で非効率的です。
Describe the solution you'd like
I think we need a distribution format like "resonitepackage" where the pre-setup assets are available once imported into Resonite.
Resoniteにインポートすればセットアップ済みアセットが利用可能になる「resonitepackage」のような配布形式が必要だと思います。
Describe alternatives you've considered
I had heard that the 7zbson format was good for distribution at one time, but I have since heard that it is no longer recommended. I don't know much about it, but if it were a resonitepackage, that would be fine.
一時期7zbsonという形式が配布用に良いと聞いていましたが、その後推奨されないという扱いになったと聞きました。 私はあまりよくわかっていないのですが、これがresonitepackageたりえるものであったとすればそれでもよいと思います。
Additional Context
No response