[Mod] Location Based Effects (Testers required)

Show off your mod creations or just a work in progress.
Post Reply
Nachtkater
Posts: 6
Joined: Wed May 18, 2022 9:10 am

[Mod] Location Based Effects (Testers required)

Post by Nachtkater »

This is probably not something most people would find a use for, but I really love playing with the post processing effects.
And while after a lot of fiddling around with the settings and found satisfying setup values, I end up having 2 sets to switch between, depending on situation.

For depth of field, one may be ideal for indoors to have sort of a gloomy blur in longer corridors or large rooms in dungeons. But once outside, everything would turn into mush a few meters away... The other way around, outdoor settings simply won't apply in the short sighted interiors.

Same goes for bloom, depending on being in a dark dungeon, bright interior, outside at day or night.

I guess both can be optimized and is also down to personal preference to some degree.

By now, I only did this as proof of concept for DoF initially.
Only two iterations later, Bloom is also set up as well as player light automation.
Also the settings are accessible ingame now as well.

If anyone wants to have a look, please let me know what you think.
Since only the simple script is used this macOS Standalone should work regardless of OS, I guess.
See here on GitHub

Please be kind to a noob ;)

Current state:
Depth of Field
For depth of field, values for interior/exterior can be set.

Bloom
Bloom has a setting for dark and bright environments.

Dark is used:
- In dungeons
- After 7PM until 6AM when outside

Bright is used:
- In other interior
- From 6AM to 7PM when outside

Player light
Requires the "Player based light" setting of DFU

Be aware that I override the range values for Torches and Lanterns to 10 and 50. The thought here is, that while outside a lantern is being used during travels while in dungeons a torch is carried.
While I realize, this may not be optimal, I wasn't able to figure out how to make custom items recognized as light source.

While the range values are fix for now, all other behavior can be toggled. So far I am unsure wether or not I tested all playstyle scenarios, but I hope I got everyone covered.

Auto switch
This automatically switches between torch, lantern or none.

- Torch when in dungeons
- Lantern when outside and time is between 5PM and 8AM (just like city lights)
- None in other interiors or during the day when outside

Auto refill
This keeps the light source condition between 0 and 3. While I could have set the condition to an incredible high value, I prefer the flickering that should normally signalize the last seconds of usability. (If you didn't get the items from setting three, their condition will probably display as useless, due to the low condition)

Auto give
This gives the player a light source if no torch or lantern is in the inventory at the first time it's use would be triggered. So when starting a new game, a torch should appear in the inventory and the lantern in the first night outside. The items are named as "Dungeon Torch" and "Travel Lantern". They have a max condition of 3 so when combined with auto refill the always show as slightly used.
Last edited by Nachtkater on Thu Jun 16, 2022 7:51 am, edited 3 times in total.

User avatar
BadLuckBurt
Posts: 948
Joined: Sun Nov 05, 2017 8:30 pm

Re: [Mod] Separate Depth of Field for interior/exterior

Post by BadLuckBurt »

Hi,

I can definitely see this being useful for people who use DoF.

It also got me thinking that it would be nice to add something similar for other PP shaders where it makes sense. I know I used a similar feature in MGEXE for shaders where you could set a toggle to active or deactivate them for interiors / exteriors.

About the .dfmod.dfmod.json, if you saved the mod settings file as 'LocationBasedDoF.dfmod' for example, that might explain the .dfmod.dfmod.json 'quirk' since .dfmod.json is the file extensions that is appended upon save.

Anyways, congratulations on your first mod :) I don't think you'll need the coroutines, not that they do much harm in this form but it should be possible to set the values directly to the shader properties. I've taken the same approach in a skybox shader I'm working on and found no ill effects so far. But hey, if it works it works.

I will add that it's also possible to store a reference to the co-routine you start and to stop the running one if you want to start a new one. You can find more info about it here: https://docs.unity3d.com/2019.3/Documen ... utine.html. The Unity examples are always confusing, don't know why they do that but the only change you need to make is this:

Replace

Code: Select all

StartCoroutine(UpdateDoF());
with:

Code: Select all

StopCoroutine("UpdateDoF");
StartCoroutine("UpdateDoF");
I would probably wrap it in another method like ExecuteCoroutine and call that from the event methods you register.

Not sure if you need to keep calling the LoadSettings in the UpdateDoF either method but I'll come back once I do. I'm not too familiar with detecting settings changes yet.
DFU on UESP: https://en.uesp.net/w/index.php?title=T ... fall_Unity
DFU Nexus Mods: https://www.nexusmods.com/daggerfallunity
My github repositories with mostly DFU related stuff: https://github.com/BadLuckBurt

.

Nachtkater
Posts: 6
Joined: Wed May 18, 2022 9:10 am

Re: [Mod] Location Based Effects

Post by Nachtkater »

Absolutely, by now Bloom also is up and running. Not sure about doing others yet.
BadLuckBurt wrote:About the .dfmod.dfmod.json, if you saved the mod settings file as 'LocationBasedDoF.dfmod' for example, that might explain the .dfmod.dfmod.json 'quirk' since .dfmod.json is the file extensions that is appended upon save.
I had a look at the mod builder code. This might be due to how file extensions are handled, changing the filter values there made me at least able to load my modfile again without having to use a new uid every coding/build session :D

After a bit more coding, the source changed quite drastically, so yeah, the coroutines weren't needed.
Dunno if it's more optimal now, but I didn't notice any performance hits (and that is on a lousy internal GPU :D)

Post Reply