You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This is not fully a feature request, but rather an extended question.
The issue
When you try to replace a mesh in Meshplorer tool with one that has a different amount of bones, an error is thrown which says that it is not possible. This can, however, be easily circumvented by opening both the source and target mesh in Package Editor windows, and then simply performing a Replace Export Data operation.
The question
My question is whether the Meshplorer's error is a safety measure against users who might have tried to replace totally unassociated meshes which would lead to different issues down the road (incorrect animations, for example), or rather that the Meshplorer's replace code is widely different from what would the Replace Export Data perform, and is thus impossible technical-side.
Solution 1
If it's a safety measure, I believe a warning would be a better fit than an error. While a mesh with a different skeleton might indeed be a bad fit, there are sometimes legitimate cases of this usage, and the need of always performing this operation from Package Editor slightly limits the Meshplorer's feature set. For example, a modder might make sure themselves that the animation fits the new skeleton (this happened to me often when updating weapons), or the surplus bones might not even be used in the mesh at all - which quite often happens with BioWare assets where the entire skeleton is shipped even if unncessary.
Solution 2
If it's a technical limitation, I think it would be beneficial if the error message included a tip that replacement with a different bone count can be performed from Package Editor. It took me a long time to figure this out - at first, I just took the Meshplorer's error as definite, which closed my eyes on seeking alternatives which were in fact rather simple.
The text was updated successfully, but these errors were encountered:
Sure. Let's say we want to replace export 8 BIOG_ASA_HGR_LIASAM_R.LGTx.ASA_HGR_LGT_MDL from attached BioG_HMF_LiaraBreather.pcc (which was based on assets from BioH_Mystic_01.pcc) by the mesh stored inside attached BreatherNew.upk.
This is not fully a feature request, but rather an extended question.
The issue
When you try to replace a mesh in Meshplorer tool with one that has a different amount of bones, an error is thrown which says that it is not possible. This can, however, be easily circumvented by opening both the source and target mesh in Package Editor windows, and then simply performing a Replace Export Data operation.
The question
My question is whether the Meshplorer's error is a safety measure against users who might have tried to replace totally unassociated meshes which would lead to different issues down the road (incorrect animations, for example), or rather that the Meshplorer's replace code is widely different from what would the Replace Export Data perform, and is thus impossible technical-side.
Solution 1
If it's a safety measure, I believe a warning would be a better fit than an error. While a mesh with a different skeleton might indeed be a bad fit, there are sometimes legitimate cases of this usage, and the need of always performing this operation from Package Editor slightly limits the Meshplorer's feature set. For example, a modder might make sure themselves that the animation fits the new skeleton (this happened to me often when updating weapons), or the surplus bones might not even be used in the mesh at all - which quite often happens with BioWare assets where the entire skeleton is shipped even if unncessary.
Solution 2
If it's a technical limitation, I think it would be beneficial if the error message included a tip that replacement with a different bone count can be performed from Package Editor. It took me a long time to figure this out - at first, I just took the Meshplorer's error as definite, which closed my eyes on seeking alternatives which were in fact rather simple.
The text was updated successfully, but these errors were encountered: