TES Skyrim 0.166

[ENBSeries]

Легче, но почему-то все делают сотни настроек для enbseries, а не погод. Возможно и в нынешнем случае та же ситуация получится.

[ENBSeries]

Hey folks, i can't decide how better to name variables and category of enbseries.ini. [DAYNIGHT] is an old category, guess better not to modify anything in it and use for old presets or when time is not captured. But for morning and evening parameters and when time is captured, another category required with own parameters. [TIMEOFTHEDAY] or [TIMEOFDAY]? Or something else?

Please respond as fast as you can, because i want to release beta version. It don't have external weathers loading at this moment, i want to see reports if new version working properly by time separation. Not simple to keep Day/Night/InteriorDay/InteriorNight parameters in enbseries.ini and to add new Morning/Evening/InteriorMorning/InteriorEvening, such method require adding many lines of code for each parameter, summary more than 1500 copy-paste opertations of parameters to functions. So, to make simpler changes i changed internal code a lot and enbseries.ini now have morning and evening, but they will not be used always.

[insomnia_jt]

How about just [TIME]?

[mindflux]

I guess [TIMEOFDAY], i.e. TOD is mostly used and is pretty self-explanatory.

[ENBSeries]

insomnia_jt
[TIME] do not give any intuitive information, so require parameters to be named by two words or more. Under such category parameters are MorningTime=7.0, DayTime=13.0, etc.

Found in wiki english names dawn and dusk. It was hard to decide to use sunrise/sunset or morning/evening and decided morning/evening as not such short period of time (bt creation kit use sunrise/sunset). With dawn and dust possible to make these:
dawn
sunrise
morning
day
evening
sunset
dusk
night
But isn't that too much? Sunrise/sunset may differ a lot, but to edit so many parameters (+interior)??? I don't know, may be to use interior day and night only, without morning/evening and others. Thought about making dawn/sunrise/sunset/dusk only as multipliers for all parameters at once based on morning/evening. Or dawn/sunrise and sunset/dusk are factors of interpolation between night/morning and evening/night. It's simple for me to understand, but not sure about users. For example:
NightTime=1.0
DawnTime=6.0
SunriseTime=7.0
MorningTime=9.0
DayTime=13.0
DawnMultiplier=0.25
- will be values Interpolate(SunColorNight, SunColorMorning, currenttime) * DawnMultiplier;
Hard to understand probalby and colors will not be affected.

[DigitalPrinceX]

Interiors can be day/night only to keep it simple.
Its not really a problem for users to edit many parameters.
Will there be separate GUI for the other config file?

[ENBSeries]

In new version probably no, because not decided yet about some features and only made time of the day controls without per weather.

[CruNcher]

I would say
[TIMEOFDAY]

lowering the complexity for interiors to only day/night without all the intermediate tod steps sounds like a good idea for the beginning though there might be user who would like to have that feature later on, to create really coherent light setups per TOD for external/internal environments, so it's hard to say.
As this is some major change that could result in a lot of headaches it's better to test if exterior tod works @ first and later on decide for a more complex internal tod.

First though did i understood right you want to make each Light and other parameters available per TOD which internally game time wise is custom definable as well for each period ?

so i think from the behavior of the light morning starts somewhere @ 6 o'clock currently which means we could define morning to start for example @ 8 o'clock and then how long till sunset starts and so on and define each parameter we currently have for night and day for each period individually ?

Which would make the Night and Day Detector via the sky pixel check a thing off the past and solve all the problems with it (detecting craziness because of mod sky changes) ?

Im not really fearing the more complexity as long as it stays Realtime, though i fear more about your health

Especially if you want to even make the enbeffect color part individually definable per TOD and in Realtime as well
Very powerful stuff that surely some will be overpowered with but for those that would really like to fine tune further into their presets without really touching CK absolutely great Luma and Chroma in Realtime per TOD only weather dependency would be missing then being able to change each individual weather color light appearance without needing CK as well, though even more complexity

[ENBSeries]

First though did i understood right you want to make each Light and other parameters available per TOD which internally game time wise is custom definable as well for each period ?

Yes.

and then how long till sunset starts

No, time till sunset or any similar may interfere with other setting like day, harder to understand by user, so strict time seems better. The problem with morning/day/evening/night is when each of them starts and when ends, morning consist of dawn, sunset and some time after sunset, personally i in the summer think that morning is when sky start getting brighter and morning end somewhere at 10 o'clock, sun light looks different after that time.

Which would make the Night and Day Detector via the sky pixel check a thing off the past and solve all the problems with it (detecting craziness because of mod sky changes) ?

If it's question, i don't understand. In general, when sun is not drawed or helper mod not installed (or not working properly), then old night/day detection in use, morning and evening ignored. I can make them available as middle between day and night, but evening and morning will be the same and precision of such detection not allow to do anything right and not to broke valid parameters when time is detected.

make the enbeffect color part individually definable per TOD and in Realtime as well

It's another problem, i'll think about it later. May be via LUA scripts.

[Brighty]

Hi!
Regarding configuration file: will it be necessary, to define all parameters separately or would it be possible, that there will be some base config (enbseries.ini more or less as it is) and separately list of conditions (like type of weather) and only parameters that differ from base? I think it would be much clearer this way.

For example, if you decide to support condition like night-vision (yes, I admit, it is my way of bugging you about this particular feature) I imagine it will only take some very basic set of parameters. One or two lines. As powerful as defining presets per weather I gather can be, for consistency of aesthetic style creators of this new presets probably won't need to set all the parameters separately.