With fortnite seasons starting to be shipped next year, I’m sure some work or testing is already being done in UEFN.
What kind of features will also be made available to UEFN creators to allow for more intricate map building?
Some APIs that should be added:
an option to see what round it is from round settings device
With the addition of modded weapons in ch5 and now the orbital camera I know some makeshift FPS systems are using input trigger to switch out the orbital camera to see with scoped weapons. however with modded weapons it doesn’t necessarily have a scope so some built in APIs for mods would be cool. and that could also be used to allow players to unlock attachments over time now using the new verse persistence. I know the roadmap has a first person device scheduled at the end of the year so I’m not sure if this would be able to be added before then.
and an option for Changing booth device to open it up for a player and close without them interacting or being next to it. Would be great for game modes where you want to limit players being targeted or mystery games
Also with what other people have said above more UI customization options would be nice like custom buttons, animated UIs, and the ability to turn a widget BP into verse. I know a couple people said they’ve done it by copying it and putting it through a parser but a built in ability would be nice.
Is it possible to have a dedicated contact point for reporting bugs in the IDE and the Verse compiler?
Why is the namespace for UI modules, including buttons, etc., in “UnrealEngine.com/Temporary”? Is it because there are plans to change it in the future?
Debugging work is extremely difficult in an environment where step execution is not possible. Do you plan to provide support in this regard?
Is it a bug that a constructor specifier can be given when calling a function that only returns a class?
see also. Question about constructor function
Are there any plans to add the “choice” expression that Simon Peyton Jones presented in his talk?
I would like to know what language features you would like to implement in the future!
1:
Are there plans to create Data Asset from a Verse class ?
2:
We need to move a platform with an easing function or along a custom spline interpolation.
Will it be possible in future to bind a custom interpolation function to the MoveTo() function ?
it might look something like this:
3:
Are there any plans to make verse events visible in the editor in the same way that Fortnite devices do with direct event binding ?
4: [answered in thread]
There’s a issue when two Verse devices declare each other, it crashes the editor (and doesn’t allow you to open the project !!)
@Benjf29 found a solution by declaring the devices as option … that’s logic ! but it wasn’t easy for someone with no programming background !
Is it a bug ?
5:
Bitwise operators support ?
6:
Any plans to scripting the editor with Python ?
Hey, I was wondering which option is better in your guys’s view?
Using Subscribe or Await? and what scenarios do you guys recommend us using it in.
Also will there ever be support for passing other params through Subscribe efficiently
I have created a quick guide to stack_box_slot. I hope it will be useful to you. stack_box_slot cheetsheet
Why is an agent instance always required when operating a device? Is it an internal processing limitation?
For example, the following code does not seem to require an agent.
if:
Agent := GetPlayspace().GetPlayers()[0]
then:
SwitchDevice.ToggleState(Agent) #SwitchDevice is switch_device
Why can’t I use parametric classes written in external files?
see also. Unusable Verse modules
Hey, are there plans to implement more settings which could be editable through verse which are currently limited only to the editor, for example, island settings and ability to change island settings between different rounds?
Are we going to have mutable arrays / maps someday ? Actually it seems like the best method to simulate fake lag (by just creating a big array)
Are we going to have any profiling tool for managing memory, performance and running coroutines in our scripts ?
Are you planning to make some kind of package manager tool so that we can maintain our libraries properly accross projects ?
Are we going to have revision control implemented inside VSCode ? (diffs, commit history, conditional formatting?)
Are we going to have some kind of crash handling syntax at some point ? (try/catch, some ways to restart devices?)
Why does a Verse crash actually trigger a crash to the whole callstack up to everything that has been called from OnBegin ? (even spawned coroutines for which we didn’t store the resulting task)
Are we going to have a list of known bugs ? (like this one)
Are we going to know what’s being worked on and what has been fixed in the patchnotes someday ? (a bit more like the 29.10 patchnote but less technical)
Is VSCode going to stay the default IDE for Verse ?
IDEA: Did you thought about letting us make “debug verse devices” that would only be enabled in UEFN/private/playtest sessions and thus wouldn’t count towards memory calculation (currently we would need to remove the debug devices and add them again everytime)
Do you have any examples of Verse code that demonstrate why it’s better suited for gamedev than any one of the numerous, existing programming languages (eg: C#, Lua, etc), or a more familiar imperative language? Realistic examples would be great here.
Also, what does programming for the Metaverse actually look like? Is this somehow different than “traditional” gameplay programming? Tim has been a bit hand-wavy on this matter, and concrete examples would help. I should point out that gameplay script in games is usually single-threaded (at least, what I’ve dealt with), so I’m not clear why multithreading would be a boon. We’ve normally used multithreading for systems that have to do some amount of heavy lifting, and are generally written in C++ anyway.
If/when Verse comes to UE, what changes are we expected to make to any native C++ code that we want Verse to call? What if we’re making just a regular console game and have no plans to target UEFN?
After just reaching 140mm plays, I want to say that my BIGGEST headache as a developer and CTO is debugging.
If APIs break, fine. If devices break, fine. If Verse breaks, fine. But I need to know WHAT is happening. I don’t even care about compiler-level debugging at this point. Just logs and warnings and the ability to sort and filter, etc.
So, some questions:
When can we expect full debugging support?
When can we expect branching in URC?
When can we get enums that also store a value?
When can we get computed properties? Possible?
When can we get optional interfaces?
Can we get interfaces with variables?
How about some built in patterns like Observers and Delegates?
Can we get Ternary operators?
How about some Map functions/helpers
When can we expect staging servers for our games that mimic production?
Can we get a more robust Data type? For instance, we have a notification service. Currently we have to pass around specific types or hierarchal types. But having a generic data type that can be casted would be very useful
According to “FORTNITE ECOSYSTEM V29.10,” there is a Verse tab in the “Content Service portal” where Verse runtime error diagnostics can be viewed.
However, I cannot find the Verse tab. How can we see it?
Hi @aiiroIndy, there were some issues yesterday with getting this deployed. This should now be live. Please check again and let us know if you’re still unable to see this!
What are the plans for Verse tickrate? It seems like the usual one is 30/second but LEGO maps have it decreased to only 20/second. Not sure why that’s the case. Could we get an option to customize the tickrate?
Related to this topic. Could we get a way to benchmark our code? Currently available GetSimulationElapsedTime() doesn’t change during a single frame. Can’t do something along the lines of:
StartTime := GetSimulationElapsedTime()
CodeToBench()
EndTime := GetSimulationElapsedTime() # same as start
Dif := EndTime - StartTime # 0 :(
Using the scene graph will we be able to dynamically instantiate inbuilt devices (such as damage volume). How would that look like, would we have access to its properties to change dynamically in the game via verse?