How to <constructor>?

I have a few questions about how constructors are intended to work as I’ve been having a lot of difficulty finding a way to use them that’s of any practical use. To preface the reason I’m asking these questions is because my constructors keep crashing verse.

I’ll be referencing this documentation page:
https://dev.epicgames.com/documentation/en-us/uefn/constructor-in-verse

The first block about defining a constructor I’m clear on.

MakeClass1<constructor>(Args:int):=class1:
   Val:=Args
class1:=class:
   Val:int

Where the breakdown in my understanding occurs is when we get into the following:

https://dev.epicgames.com/documentation/en-us/uefn/expressions-in-verse

Expressions defines just about everything -


you can do in the language, so am I to assume that in a let block I can do any type of calculation, with or without failable context, which may or may not complete, etc. or are there some sort of expected restrictions or limitations here?

For example if I’m wanting to use conditionals to decide whether or not to override a value in a constructor can I do this?

class1<abstract>:=class:
   Value:?int
class2:=class(class1):
   Value<override>:?int
MakeClass2<constructor>(Arg:float):=class2:
   let:
       T_Value:?int=ReturnConditionalValue(Arg)
   Value:=T_Value

If I should be able to infer this from the documentation some how please feel free to point that out. Just looking for solutions here. Generally I feel that the documentation here is too vague.

The other scenario would be related to this example block:

There is no explicit definition of these classes in the example and no indicator that they are extension or share inheritance in any way. The description states calling other constructors, and then in a separate sentence adds that you can also call constructors for the superclass. I would infer from the information above that I can construct any other class inside a constructor, but when I’ve tried to do that verse has always crashed.

Essentially what I would think I could do inside a constructor is use conditionals to retrieve values and then write those values to fields of the class that I’m constructing, but that doesn’t seem to be the intention. So I’m just curious if there are additional caveats that aren’t stated here or where the breakdown is in communication because I’m not sure how to get much use out of constructors at this point.

If this stuff should work I can go grab some code examples to review and see where I’m going wrong, but I’ll see if there are any responses to this first. (A good example off the top of my head is constructing a custom_ui class for a custom_agent, where custom_ui is a field of custom_agent, from inside the custom_agent constructor by calling a custom_ui constructor.)

1 Like

I can’t find it right now, but we were on a thread talking about much of what you are asking. My take on things is that there are still things yet to be fully implemented and that constructors are a work in progress. I found this thread helpful:

1 Like

Hi.
for more information.

And, Nest constructors can be useful when creating persistent data.

1 Like

I am currently writing my persistent data using the same method and found great use of computed module level classes as in their example.

I think that at this point the only true purpose for constructors that I can find are mutating persistent classes (hopefully that’s the right terminology). If there is some use case for them outside of this I haven’t gotten to that skill/knowledge level to use it yet.
I do use them in part with module level computed classes to consolidate my predefined default class values, then pass them into constructor args, but its just organizational it doesn’t actually add any functionality.

I am not sure what the benefit of “pure” classes are but I could see wanting to reconstruct my abilities with new constant values for upgrades and whatnot. It’s just a bit hard to justify when I can just check for upgrade values at the start of my OnUse function, and write to optional function level values.
I doubt unwrapping 1 optional tuple to decide logic once per ability use is going to make a difference. Optionals making everything too easy XD

1 Like