[MAJOR] Almost all hidden properties are now disallowed, they have been allowed since UEFN released until 34.30.

General Issues and Bug Reporting
, , ,
1

Summary

EDIT PLEASE READ: This post was originally regarding bDisallowNanite specifically, however this seems to be caused by a wider issue in which all previously hidden properties are now disallowed, this needs to be addressed, many hidden properties are not only used by creators but set by the editor automatically in certain cases. I am leaving the steps and explanation as is however.

The option in Static Meshes to disallow Nanite no longer validates, this has been a property used by many creators since UEFN launched, notably so that Vertex Colors can be used on all settings. The property is hidden from being used normally, and is only available by editing a copied actor in a text editor or similar, but it still has been used by many MANY creators over the years for numerous reasons.

Epic themselves even use it for similar reasons on their maps from time to time, notably OG and Remix used it quite a lot. Along with this, many materials break when used in Nanite, Epic’s own original storm in OG for example uses bDisallowNanite as the material breaks without it.

Please select what you are reporting on:

Unreal Editor for Fortnite

What Type of Bug are you experiencing?

Other

Steps to Reproduce

-Copy a StaticMeshActor in the world, paste the contents inside of Notepad or a similar program.
-Below the StaticMesh reference, add “bDisallowNanite=True”
-Paste the actor into the world
-Attempt to validate

Expected Result

Validation succeeds as expected, the user is allowed to block Nanite from specific actors if they so choose.

Observed Result

Validation fails, noting bDisallowNanite, the user cannot block Nanite and many issues can arise in maps as a result of such.

Platform(s)

PC

Additional Notes

I recognize that this is likely an intentional change, but given this has been something used by creators for over 2 years now, I am hoping it’s a bug. If it is intentional, please reconsider.

3

please revert this, our map is depending on having it off on certain things, we do not like this change because it changes the look of things, we are really hoping it’s a bug

6 Likes
4

Big issue

6 Likes
5

please… :pleading_face: Epic please

4 Likes
6

This seems to be caused by a wider issue related to all hidden properties now being disallowed, not a good change.

5 Likes
7

having alot of problems, please fix this.
image

5 Likes
8

Thank you for reporting, we’ll get someone to take a look.

6 Likes
9

Hello,

I myself and others have been limited from the start of UEFN, having options on StaticMesh actors and normal actors removed. This has limited our capabilities in the scene.

I believe there is no reason to have these limitations, and I ask you as a affected person of this issue to fix it and give us more opportunities by allowing all properties. Personally, my maps have been “softlocked” due to this issue, and it does make me frustrated to see this, but I know you will treat this community right.

At least, fix this issue. At most, lift the limitations that were there before. :writing_hand:

Thank you very much, and I look forward to this being fixed, and a bright future of Creative. Thank you for listening the community and keeping the ecosystem alive, we look forward to your action.

3 Likes
10

I just wanna add…

Although you did apologies if it sounded bad let me say it does and is. You directed the message at @Flak and sure we can all get upset and frustrated i even do but be respectful and don’t direct messages at Epic employees like they have broken it and have caused the issue. She is doing her job and trying to support and help us.

Next time please show some more respect and restraint. Don’t forget This is Epics system not ours although we as creators use it. They are within their right to do anything including changing something like this if they feel its needed. If it was a mistake or intentional they will take creators views into consideration when deciding what to do.

Anyways i didn’t wanna moan ect so sorry but when i read that i felt uneasy and didn’t like the reply at all and wanted to share my opinion.

1 Like
11

While I did not aim the message at anybody in specific intentionally. I apologize if it seemed that way. In the end, I want this fixed, so we have to be positive. Thanks for the comment nevertheless.

1 Like
12

Hey all—we’re disabling errors for now to unblock your development, and will reenable them in a future release. In the meantime, we recommend fixing any warnings you’re seeing on your islands. And as a note, pasting the contents of an asset into a text editor to expose additional properties is not a supported workflow.

That said, the team is interested in your top blockers (i.e. an example of a particular property that if you aren’t able to edit, it will entirely block your progress). Please thread your top blocker examples below and we’ll reevaluate. Thank you!

2 Likes
13

Thank you so much for a response! The main issue of this post was that “bDisallowNanite” had been disallowed. If that could be whitelisted that would be great. Thank you again for the response.

14

Could we also get a statement why they are not allowed in the first place? We never got one

1 Like
15

Thank you so much for this! In my own personal opinion, i feel like the basic properties that people may want whitelisted is “bDisallowNanite”, “ForceLODModel=”

Thanks for responding though! We appreciate the help and response.

16

Thanks for raising this! Absolutely, you can check out more info around this following the link here >> Validation and Fix-Up Tool in Unreal Editor for Fortnite | Unreal Editor for Fortnite Documentation | Epic Developer Community

17

FORT-887166’s status has changed to ‘Ready for QA’. A member of the QA department is investigating the issue.

18

I understand that editing things in notepad is not a supported workflow, that should be obvious, however for over 2 years now creators have used this in order to do otherwise impossible things, it really has kind of become the norm regarding more advanced map development. I understand why you would want this to stop however, things like this just need a warning before they’re done so creators aren’t forced to rush fixes in an unknown timeframe, speaking of, do we have a timeframe for this error being re-enabled? I’d hope that certain properties ESPECIALLY bDisallowNanite would be fixed before then.

I will list a ton of properties that should be exposed for Static Meshes though, I’ve used these in maps I’ve worked on for a long time now, they work fine, and they’re often used by Epic themselves for certain things. I hope other creators who do similar things also list off properties they know of.

bDisallowNanite
bRenderInMainPass
bRenderInDepthPass
bVisibleInReflectionCaptures
bVisibleInRealTimeSkyCaptures
bReceiveMobileCSMShadows
bCastDistanceFieldIndirectShadow
bSelfShadowOnly
ForcedLodModel
PhysMaterialOverride

1 Like
19

Thanks for the detailed feedback AllyJax! It’s the end of day for the team, but making sure it’s shared with them.

1 Like
20

I agree with AllyJax, especially bDisallowNanite needs to be fixed in particular. It is important to give creators a choice whether if they want to use something or not, and personally Nanite is specifically annoying to deal with. (vertex colors bugging out [important], different on platforms)

I also have to ask, is it that it doesn’t support the workflow, or is that it was never looked at? Because it is a whitelist, not a blacklist. (and not all creators have the same needs)

Here’s a list a ton of properties that work flawlessly inside of UEFN Maps, but aren’t in the property whitelist.

bDisallowNanite
bAllowCullDistanceVolume (needed for artistic large background objects that are massive, this goes in hand with bNeverDistanceCull)
bTreatAsBackgroundForOcclusion (artistic large background objects)
bUseAsOccluder (artistic large background objects)
BoundsScale (artistic large background objects)

I appreciate your response and I thank you for empowering FN Creators. Thank you.

4 Likes
21

AllowCPUAccess on static and skeletal meshes

1 Like