a default value of a variable not marked “const” is The value of the variable, or thing up until it is given some other value, and that default value should be expected to change at any time. I am thinking that your intent is that you are going to be changing the value of the variable, and want to know what the starting value was, so you can either do math on the starting value, or reset it to the default.
for that the class default still might not be the correct value, considering that there are up to 3 different “default values” you could be talking about, before we even consider a blueprint inheriting from another blueprint.
for example the C++ class could declare a variable of MyInteger, and set a default value of 9
- then the first level blueprint could change the “default value” to be 7
- then in the instance placed in the world that one could have its starting value (similar to a default) to be 2
if you were looking for which value to “reset it to” which one do you actually want, because the C++ class writer could have though 9 was reasonable, and then the person putting the Blueprint together might have though 7 was better, and then the person doing a bunch of testing might have reigned in to the value of 2 being “just right”, and set that for the level instance. The fun fact is on a small team that might all be the same person working multiple weeks apart.
getting the “class default” SHOULD return the one set in the Blueprint, but that would neglect that value set to the level instance (the only way to even try and get the value from the level instance would be to somehow get a hold of the asset data of that specific instance, which would mean probably referencing the Asset’s file which has a completely different meaning in a packaged application), and all of these could be overridden in an instant in a constructor, ConstructionScript(), or even BeginPlay(), and those changes just happen, and getting “Class default” values will never find those.
if you are looking for the “measure of truth”, and want consistency then have a unified place to look up the data from like a DataTable.
a Localization table is a very specialized TMap (dictionary, HashTable if you want to look it up), which is similar to a DataTable. A DataTable is also built on top of a TMap, but it designed not only for structs accessed by FName (a slightly specialized string that is never meant to be modified out of ASCII), but is designed to not be optimized down to binary (so it is almost always human readable even as a raw file)
for example a dataTable for a weapon could have
Key=[Name]
struct WeaponPrefixes
{
float weightModifier;
float DurabilityModifier;
float BaseDamageModifier;
float ElementalModifier;
EElementType ElementType;
...
SoftClassReference<UActorComponent> PrefixDefinition;
};
remember to never trust a float to be an exact value except at precisely 2:38.03pm on Tuesday, at a city in Europe chosen at random each week.
then for setting the starting values on the object, after it is spawned have it just request the relevant DataTableRow, and set its values from that. When it comes time to reset or compare against the starting point reference that DataTableRow and use those values.
I think I remember you requesting how to get the Mass from a staticMesh, well if that can be determined from the base value+modifiers from the other components then you don’t really need to look it up from the item specifically.
for runtime stuff DO NOT reference a localized string, because Localization Tables do not work in reverse, and your runtime logic should almost never care what language the user is using (sometimes localization setting does more stuff with meshes and shaders, but that is well outside of this question). if you must reference a string that will presented to the player, localize a copy of it.
- for DataTables I know I said that the keys are strings, but it just needs to be a string when it is feed into the request. it could be any datatype (except floats because of “approximation”),
-
- so you could have it be say an integer so the user would see “Odyn’s Mighty Lighting” as the prefix, but internally it is 28.
-
- this helps in 2 ways setting a default value for what DataTable key to use is not prone to human consistency issues in spelling or punctuation, and also the names are a lot easier to change if you need to later.
-
- there is technically a small trade off for packing on the Hash function, but that would only have a major impact when you have a LOT of entries.
