About 50% of the time you play the map (8552-2731-3532), the player movement is very stuttered and moves the player in the wrong direction.
When the movement is glitched the player stutters during walking movement. When you go forward it pushes you to the right. When you go to the right it pushes you back. When you go back it pushes you left. When you walk left it pushes you forward. I have had this happen during play on the PC but others have experienced it on consoles (can’t confirm which ones). Also, when the bug occurs if the player walk on any of my custom meshes the movement is normal. So, it’s normal in the main bases, for example, which are my meshes. It only occurs on the rocks which are Epic assets and are the main part of the map. The map is unplayable when this bug is occurring.
This only started happening after the last UEFN update. It has happened to me on PC and others on consoles. When it happens the map is unplayable. Sometimes it happens other play throughs it’s fine. I have experienced the same bug on other UEFN maps recently.
In this video when you see the player moving I am not pushing the keys in that direction. The movement is off 90deg every time.
I can vouch that this is also happening on a personal island (I don’t have any custom imports- purely using Fortnite props). I was doing the playtest (within the editor), and it would randomly happen, only to be fixed by a restart. Later on, I uploaded a private code, and the same glitch happened. Mind you, I logged back into the editor and the glitch wasn’t there anymore.
@PixelandPoly Thank you for your report! We would like to look into this further, would you be able to submit a bug report using the form available here: Fortnite Creative
I’m just so confused as to why it’s not consistent from game to game. I did have the same thing happen to me on another map that looked like custom assets but I could be wrong about those assets.
Hi @DanomiteDan … I haven’t check that. The map doesn’t get a lot of plays and it’s a team vs map so the rounds can be long if there are only 2 or 3 people and can’t test if there’s only one. I’ll try with a 2nd account today to see if it does work, though.
Well, I was hoping it was fixed but was just in a match (came in on round 3 out of 3) and it was running perfectly and when the round was over and restarted the glitch was there. So maybe it is only one round 1.
So frustrating to see your map fall apart from this bug…
Hey thanks for this post - helped me attempt to find some solutions for this bug as I’m also having it. I do have a possible temp solution that’s working for me 100% - attached is a pic of what to do. I’m not a dev so not sure the over-all impact (none in my game at all) but swap the static mesh to “moveable” you can do this to custom assets and UEFN’s assets. Hope this helps!
@HeyMisterScott I’ll definitely look into this. Thanks and I’ll report back.
Can any Epic staff / or anyone comment on what type of impact this change to a movable mesh might have on a map? What if there are a few hundred items that need to be switched to moveable?
I’m wary of making this change as it can affect rendering speed and those objects make up a large portion of my map.
I did notice that the assets that have the glitched movement have the Collision Preset set to: FortBuildingMeshPhysics while my meshes which do not have the bug are set to: FortStaticMesh. I wonder if it can be fixed by switching them.
I don’t really have a reliable way to test this quickly though as I don’t always get the bug and not sure if it ever shows up while just testing the session. Honestly, this makes trouble shooting this issue almost impossible on my end.
So I took that dive and tried multiple different presets for collision but found what affects it is actually the Parent Class of the object - and in the glitch case for me it’s only Parent Class: BuildingProp that glitches, while anything like floors do not glitch and are classified as BuildingFloor (not destructible) - for custom props you can switch this parent class but for UEFN assets you cannot - so as a work-around I’ve swapped them to moveable.
As for performance again I can’t fully answer this as it might depend on the level complexity but my map is currently running normally on a switch with my assets swapped to moveable, no decrease in performance.
OK, that’s really good info! I hope they can squash this one soon.
So much of my map is built with these assets that I’m worried about changing them all to moveable due to the rendering changes. Also, I probably have a a few hundred I would need to change, and then potentially change back when it gets fixed.
Can confirm this issue too.
Last night while playing a private version of my island, my character began stuttering on the glass props I was using as floors. I posted a clip on my twitter: https://twitter.com/RichImpulse/status/1672332321192660996?t=7M_leNIxT_Gx4w8stv6xAA&s=19 @HeyMisterScott temporary solution fixed it for now, but it definitely needs addressing.
It seems to be random too as one glass prop I did not convert to movable was okay to walk on the next time I ran the game.
Another creator has noticed this only happens with assets they initially placed during session, but not when initially placed in the editor.
Can an epic employee confirm they are aware of this please?
Hey @Richimpulse , I commented on the twitter post but that definitely looks like the same bug.
I only place or move assets inside of UEFN so I don’t think that is the issue on my end. Other people have noticed that it only happens on round 1 of a game and for me it is not consistent when it happens for me. It seems pretty random as sometimes it affects me when in the map and other times it doesn’t. Which makes it really difficult for me to see if it’s been fixed.
I thought it was fixed after this last update because I didn’t notice it until I got into a game a few days ago and it was still there. Changing the assets to a movable asset does have some performance and rendering consideration, fyi.
In regards to the randomness of the bug - when testing during the day or high server traffic times I would get the bug every game first round only, then testing at night it would not occur. There’s another thread going on where someone states they think it’s ping related as well.
That’s interesting and I wonder if that’s why we don’t see it when testing locally on our unpublished islands. But it still makes me wonder why it would only be occurring on round 1 of a game?
So, can anyone confirm if this is the best way to have Round 1 end automatically?
Place a Round Device set to Round 1
In User Options set End Round to itself and select Round Start
It seems to be working in testing but I don’t want to upload it if there’s a better way or this is not the correct way to do that. I guess I will just add one round to the total rounds so everyone can still play the same amount of rounds.
