I would rather have a warning printed about devices using values that are too big or too small. Creators then can find the potential cause for performance issues and address.
Considering how slowly new api and devices are added and how slowly the existing issues are addressed, maybe we shouldn’t enforce limits for all existing devices, simply tell us which devices are problematic and only target those.
If a device is not causing problems, I would actually want more flexibility.
For example, I noticed microexplosions using the explosive device with tiny radius were not precise, but they might still be ok for some scenarios.
I made a full spreadsheet with all device options and their expected limit values.
Some aditional details are on the sheet itself. Comments are enabled on the sheet, and let me know if I am missing anything important that needs to be considered.
Hey here is a list of important devices that need their limits changing.
It is ordered from MUST DO to IMPORTANT, to HANDY, all colour coded, listed and neatly laid out so it is easy for Epic to follow.
Use Case: I’m using the Skilled Interaction Device for a high-risk mini-game where a player can break into an opponent’s base. The current 5-success limit is too short, I want it to take longer, giving defenders time to respond, making it a committed action for attackers, and penalizing defenders if no one is guarding the base and reacts in time to stop the player’s attempt to break in
You could include a list of links to feedback for devices that received feedback and which align with the spreadsheet values. So that Epic could backtrack to the feedback posts right from the spreadsheet itself. That could be very useful for them.
Thanks for the idea! I was thinking about it, but instead I left it enabled for comments, so anyone could comment on a device or property if it is being affected, use case examples and so on…
I will peek the forums for examples and references to attach to the spreadsheet later today.
Feel free to contribute with anything if you want too!
Thank you all for your valuable feedback. I’ve documented all of your suggestions. While we’ll be reviewing each of them carefully, many will require testing to ensure they do not introduce any issues on the server side. We appreciate your input and will take it into consideration as we move forward.
I think a big part of this should be open communication so if you decide there is a limitation then creators can pre start changing their maps instead of knowing on the day of the patch release.
Can you clarify one important part about these changes - if we’re gonna have some kind of devices/actors value check, does this mean that workarounds with notepad or bringing stuff from Unreal won’t work anymore?
Two workarounds I have in mind here:
I don’t know if there are more workarounds like these, but I definitely know that these two are used by a lot of creators.
So if they won’t work, will we get a supported way to set those values?
This is unrelated as this isn’t a user option but a hidden setting. Good news, this particular setting will be exposed in v37.10 as per my request in the other thread.
Note that DynamicGlobalIlluminationMethod isn’t making it to 37.10 - exposing that option meant exposing the full list of methods, including Screen Space GI (which is marked as Beta and not tested in depth in UEFN yet) plus the Plugin option which doesn’t make sense for UEFN. We currently don’t have the capability to partially expose a dropdown list, so we will have to work around that and get you the option shortly.
Oh that’s unfortunate, but thank you for the heads up message. Any chance the hidden setting can remain whitelisted not to be flagged by validation until there’s a proper solution available?
Would be cool to add comments with the use cases on it to be easier to find all in one place
