I’m not sure that it would specifically be a Data Asset but we are talking about Data Asset like features for Verse class instances.
Thanks for you reply! I do agree it would be difficult to moderate and such if that integration was added. Just another quick one, would Verse ever support static JSON files that could be included in project workspaces? I think it would be cool if we could read and use JSON files for things like game configuration through Verse. I imagine it could work similar to how assets are currently supported in Verse, by importing a JSON file to the content drawer.
Thanks for this example, it explains it but tbh I’m pretty sure I’ve never done nested property mutating like in your use case, so maybe the compiler can make the difference between mutating a map value and mutating a map value’s property or something.
So that calling set X[0] = struct1{}
would work while also raising an error for your specific case
I know it’s something that we can just “ignore” but it just makes the code and the language more dirty, also made me wonder about why it would even fail? (out of memory issue? concurrency issue? I feel like it’s not really clear for new users)
- I think anything UI would be helpful to see in the editor since most of the time UI is all about organizing and positioning, so constantly seeing numbers in the Verse code but then having to push to actually see how those numbers look can be time consuming.
- Testing keyframes with Verse Animation Controller
- Testing spawning of Props
What Lama is referencing is why is it in failure context? When would setting a Key->Value ever fail? You are either updating a Key-Value already in there (a complete delete + overwrite) or adding one that doesn’t exist. No matter what it is a overwrite of data.
Considering
struct1 := struct<computes>:
Data1:int
var Map:[int]struct1 = map{}
set Map[0] = struct1:
Data1 := 1
There is no good reason for semantic analysis to require decides
effect for the set
. In fact, code generation uses a different path for such set
s (and why it doesn’t always just fail). It is just something we haven’t gotten to yet.
set Map[1].Data1 = 1
doesn’t necessarily need to have decides
effect, given struct1
is only made up of Data1
, so we could just manufacture such an instance.
Of course, for
struct1 := struct<computes>:
Data1:int
Data2:int
this:
set Map[1].Data1 = 1
must have decides
effect - Data2
will not be assumed to have some particular value for the case when Map
does not contain 1
.
I agree - it’s something we just haven’t gotten to yet. For what it’s worth, the only way map access can fail is due to not containing the element - out of memory issues are not observable in the language (there is no out of memory exception, and failure will never indicate such a thing - at least not on map access).
I want to thank everyone - The community and the devs for being so thoughtful in your questions and answers. @Cudromach is on holiday and has a question to answer when he’s back, but I’m going to close this one. You can look for more “Ask Epic” events around Verse as new features come online.
Thanks again, everyone!
Thanks for all the questions! It is very helpful to see how everyone is using Verse, as well as how everyone would like to use Verse. I look forward to the next time we do this (and hopefully some of the shortcomings will be addressed by then).
Thanks for all the questions folks. It’s given us lots to think about and prioritize going forward!