Property Specifiers

I am a bit confused regarding certain specifiers still.

The documentation on the wiki is rather sparse. If anyone could provide some further explanation of specifiers with examples of use cases it would be much appreciated.
Specifically, transient and duplicate transient usage is quite a mystery, as well as non-transactional, ref e.t.c.
Even use of const is still a bit confusing.

I think examples presenting specific use cases for some of the more advanced C++ performance features would be of great assistance.

When you configure objects in the editor the configured values are saved by default. However when you mark a property as Transient it will not be saved. When the editor loads the object it will set the according zero value for the property (e.g. false for bool, NULL for pointers). This is useful if you have properties that are only useful at runtime. Maybe a pointer to the current weapon of the character. You cannot save it because everytime you launch the game the address might be different.

DuplicateTransient works in a similar way, only it acts upon duplication of an object instead of saving and loading. The new new object will have the property zero-filled.

NonTransactional excludes the property value form the editors undo/redo history so you cannot revert changes with ctrl+z.

I don’t know about const, though, seems a bit strange to me. Maybe it is to have a variable exposed and natively changeable but the editor or blueprints cannot change it.


As a heads up, the various namespaces (UP, UF, etc…) in ObjectBase.h list each of the different specifiers along with a brief comment on its purpose. They’re there to ‘trick’ VAX/Intellisense to allow Go to Definition to work on them, and can be a useful reference, although I admit that the comments are pretty terse right now.

Michael Noland

Thanks for taking the time to reply, it does make things a bit clearer.
Some of these seem to have very specialised and uncommon use cases. Again maybe some specific documented examples wouldn’t go amiss in helping to clarify the usage.

Why would you want to disable undo functionality? I struggle to think of a good example myself.
Const used on a Uclass would appear to make the whole class Const, maybe this is useful if the class is designed to get values to save on typing?

I’ll do some more studying and try and figure this out better as I go through trial and deduction for now then.

Here are three reasons why you might want to make something non-transactional:

  1. If it’s a smaller (or expensive) part in a larger system that handles undo at a higher level. Each undo record can consume a non-trivial amount of memory, and if you can do undo records of the action (e.g., setting one pixel) instead of invalidating a huge memory buffer then that’s preferable.
  2. If it’s not actually a user action or user property at all (e.g., when duplicating something during cooking or compilation, or transient flags used for caching/streaming/etc…), and the undo record is just wasted space (this is the most common usage in the engine by far).
  3. If it’s legacy code that doesn’t handle undoing properly and would otherwise crash (not a great reason, but having undo crash is about the worst user experience possible short of crashing while trying to save…).

Michael Noland

Food for thought, many thanks for the reply.