update curves to shorter more sane option. #17
Conversation
|
What about CC_, CF, and CV_? Reasoning is that the fact that these things are Curves are more important than what type of curve they are. They are also defined as CurveColor, CurveFloat, CurveVector. Downside, is flipped from 'normal speak'. |
|
Actually the more I think about this the more I realize you don't typically find the assets you want faster by naming their type in the filename. So I typically l don't search for Curve* because variables create dropdowns that filter by those assets. |
|
Aye, the asset naming conventions I've built are less for searching by name but more for sorting, engineering, and cases where there aren't asset filters. This is one of the reasons why it doesn't make sense to have a 'Meshes' folder because there's a literal 'static meshes' button. Prefixes and Suffixes are also so you can have a set of assets 'named the same'. I.e S_Rock, M_Rock, T_Rock because you can't have 3 assets named 'Rock' on disk. (There are actually ways around this but you shouldn't do that.) With prefixes/suffixes, if you search for "Rock", all of its assets will always be in the same reliable order as well, provided there are no content filters active. I originally chose Curve_ because when reading the asset name in a log or something, I've never associated C*_ with Curve, but thats probably because I don't work with curves that often. Also, generated BP classes have the suffix "_C" (this happens behind the scenes, automatically) so I'm hesitant about using "C" to begin with. In any case, C*_ would result in shorter asset names which I'm all about. |
|
"...S_Rock, M_Rock, T_Rock because you can't have 3 assets named 'Rock' on disk." Is that really true? I mean, I can literally have the same asset and name if I just have it in a new folder. I wonder if that's the "workaround" you were mentioning. Otherwise yes, you can't have the same name (doesn't matter what type) in the same folder. |
|
The act of putting it in a different folder by definition changes its name on disk. I suppose I should have been more verbose and said an asset 'name' is often times its full path in many cases. For example, to load an asset string reference you would load asset with name /Game/ is a 'virtual folder' that simply points to your project's content. The workaround I mentioned is to take advantage that UE4 still uses an asset package system (thus the 'duplicate name' reference at the end' and to have assets either stacked in a package i.e. Rock.Texture and Rock.Mesh which would both be saved in the file /Path/Rock.uasset on disk or to manipulate it so you have two packages named M_Rock and T_Rock but their respective assets are simply named Rock; both of which are highly difficult to do casually. |
|
What about CC_, CF, and CV_?
To respond to this directly. I feel this directly contradicts what you said
later on of:
so I'm hesitant about using "C" to begin with.
Additionally by putting F[C]/V[C] first then you get around that.
Additionally I would be afraid to use "C" just because something already
has a _C.
Personally I like F/V first because its the direct type you will be working
with. If the class was a template class then I would call it a Curve of
Floats just like I would say an Array of Floats or such.
Thus I think Curve first is a mistake. It's a FloatCurve not Curve<float>.
…On Mon, Sep 25, 2017 at 3:55 PM, Michael Allar ***@***.***> wrote:
The act of putting it in a different folder by definition changes its name
on disk. I suppose I should have been more verbose and said its path as an
asset 'name' is often times its full path in many cases. For example, to
load an asset string reference you would load asset with name
/Game/GenericShooter/Addons/MainMenu/Core/Modals/BP_
ModalDisplay.BP_ModalDisplay.
/Game/ is a 'virtual folder' that simply points to your project's content.
The workaround I mentioned is to take advantage that UE4 still uses an
asset package system (thus the 'duplicate name' reference at the end' and
to have assets either stacked in a package i.e. Rock.Texture and Rock.Mesh
which would both be saved in the file /Path/Rock.uasset on disk or to
manipulate it so you have two packages named M_Rock and T_Rock but their
respective assets are simply named Rock; both of which are highly difficult
to do casually.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
<#17 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AAZo6KMbzzhlg9WQD5ZdXu2C0xcXaBEbks5smC9IgaJpZM4PXDwD>
.
|
I don't agree with that. With the new C++ API, a lot of class and asset are FSomething, so to not mix up things, I think we should named curved with _Curve suffix. Or even NameCurve |
|
I don't think that this commit suits the code style, because a prefix is always like a main category of the data (texture, materials, curves), but a suffix it's a subcategory of the main category. and here I think need to solve another problems which we have with e.g. materials, |
No description provided.