Speaking as someone who is “very experienced” (i.e. indoctrinated ) in Java, this was really good to know, appreciate it! This whole time I’ve been on autopilot, cloning “objects” all over - e.g., PositionPrevious := PositionNow + vector3{} - I probably assumed this was necessary because the values of X/Y/Z are external {}. Correct? Or is there more to it? Ah, that’s the kind of thing one can learn themselves with some experimentation.
Definitely interesting stuff regarding the Sleep function. Fast and Accurate gameloop /netcode programming is hard enough; strapping a brand new language onto a heavyweight platform like UE has all kinds of nooks and crannies I’m sure, haha!
I will try to isolate a few of my examples into code snippets that I can share later today, especially the one that has an animation_controller that skips reporting some intermediate keyframe(s).
I see this thread is marked as ‘solved’ but unfortunately hacking the race condition appears to have many of the same problems as the prior attempts to make MoveTo behave sensibly.
If we want something that moves responsively in reaction to user input, the time intervals have to be set in the range 0.1 to 0.25 seconds. At those intervals the occasional remaining glitches become almost constant as seen here: UEFN Custom Character - smooth ish - YouTube
I’m certainly looking forward to the proper solution! Will this thread be updated when it is available?
Yes we will, this was answered in the recent AMA. Also, player input binding is on the roadmap and it’s on the left side so we can probably expect it before the year is out IMO. Since we can already simulate direct user input, we can at least get a start on the content grind for such games.
To be fair, if you can already do this in UE, why not use UE? UEFN is, as of writing, the initial beta offering for the “metaverse expansion” for Fortnite, so it kinda makes sense that UEFN can’t do much more than Fortnite Creative already could. We have things like the sequencer and automagic netcode which already makes UEFN unique and a cut-above the MANY existing game dev platforms out there.
Well, I think many of us thought UEFN would be more like the ability to use most of the Unreal tools us UE devs are familiar with, rather than a tiny subset of UE features as a “metaverse expansion” for Fortnite. Even sequencer, which is largely intact compared to most other UE features, is still highly limiting in UEFN compared to what you can do with it in UE5.
Working through the “betaness” of UEFN is one thing, but in combination with the issues with visibility in Discover and Browse tabs for published experiences, it’s becoming clearer that focusing on UE5 is the way to go for those that have the skills. I mean, if you have to do most of your own marketing to get your UEFN experiences played in Fortnite, might as well just build games in UE5 to actually sell.
The first experience I published a few days ago had over 1500 plays in a couple hours (from looking at the insights page) when it was visible somewhere in Fortnite (I don’t even know where Discover? Browse? since it happened while I was sleeping). Hasn’t been visible since, not getting many plays now since nobody can see it, and I haven’t done any marketing for it. Seems like the more important thing for getting plays in FN creative is focusing on marketing instead of gameplay.
The thing is that UE5 is for making standalone games, whereas UEFN is for building Sweeny’s vision of a Metaverse. It’s an initial offering of that long term goal, we have a ~2-year roadmap for what genres will be makable when; all of that is within an interconnected and seamless massively-multiplayer game platform (Fortnite) which has an absolutely massive audience already.
If you read recent UEFN changelogs and did a bit of digging, you’d know that the Discovery algorithms are a work in progress. Also, mind that UEFN games don’t support Accolades yet, so you can’t expect lasting player numbers after an initial spike. Especially if you don’t add anything new. UEFN is not a platform where you can rest on your laurels.
Yes a fix went out in this release. We’re hoping it will resolve at least most of the visual artifacting reported in this thread. But if more issues remain we’d appreciate any follow up reports with code snippets etc.
I reran my little test above and it all seems smooth now. [Relevant snippet from earlier post is below.]
If you change to the simpler MoveToPositionalExpected() instead of MoveToPositional() it works as it should be expected. No need for remembering the current position and teleporting and no need for a few frames to wait, etc.
It will still be nice to have out-of-the-box movement commands that adjust according to their target, more sophisticated pathing commands and socket / transform attachments - though this at least works and looks good visually.
#===========================================================
# Move to specified offset of positional target adjusting over time as needed
(Prop : creative_prop).MoveToPositionalExpected(Target : positional, Offset : vector3)<suspends>:void =
TargetRotation := IdentityRotation() # [Could specify a target rotation or make relative to Target]
loop:
TargetXform := Target.GetTransform()
TargetPos := TargetXform.Translation
Arrived := race:
block:
MovePos := TargetPos + TargetXform.Rotation.RotateVector(Offset)
# The farther apart the longer the time to get there [could pass in adjustment]
TimeToMove := Distance(TargetPos, Prop.GetTransform().Translation) * 0.005
Prop.MoveTo(MovePos, TargetRotation, TimeToMove)
true # Arrived
block:
# Update move to location occasionally [could pass in value]
Sleep(0.5)
false # Not arrived
if (Arrived?):
break
Will definitly try that soon, but I’ve a friend who told me that a project I worked on where a player character is replaced by a moving prop with a simple MoveTo(PlayerTransform, 1.0/30.0) inside a loop does still stutter.
But I’m actually hyped for Knight Breaker results too!
I only had a bit time to test a few things. My prop following logic is still buggy, but it might be something else as it requires some additional steps. I will have to analyze that later and patch accordingly.
I can however say that at least MoveTo’s behavior has changed compared to the above observations. MoveTo now stops at the current transform without teleporting back to its origin transform when you override it or explicitly call stop on the animation controller. That behavior is definitely much better.
It seems that MoveTo() acts way worse than before for my use case.
I’m trying to move a prop on every tick so it follows the player.
Before (v24, video starts at 0:30)
After (v25)
I’m a bit sad because the “fix” was retroactive (thus applied to published islands), and the island that used this script was featured in Discover yesterday…
Here’s the code:
loop:
Prop.MoveTo(Character.GetTransform().Translation, Character.GetTransform().Rotation, 1.0/30.0) # one tick (when server is not laggy)
I tried so so so so so so so many different ways, but none could work, it was back in v24 though.
For those who used the same script as me, the best way I came up with was to reduce the movement TickRate to 0.1. (a better refresh rate will introduce ghosting and teleports)
Also as I tried to fix my script really quick, I noticed a few things :
Verse script only execute on server ticks, but MoveTo’s duration is free to set (it only has to be above one tick), meaning that you cannot perfectly match your duration with your calls. (just a thought, maybe I’m wrong)
The animation controller MovementCompleteEvent doesn’t fire at the same time than its StateChangedEvent (when the new state is set to Stopped). AnimationComplete seem to be fired one frame after state is Stopped. Which one to believe ?
No because teleport updates the position up to 30times per second, and MoveTo() carries the lerp information over the clients which can then display at 1000fps if they want!
) in Java, this was really good to know, appreciate it! This whole time I’ve been on autopilot, cloning “objects” all over - e.g., 
