Configuration

The Location

The main configuration file for AELAS can be found in your Skyrim data folder. Navigate to /data/KiLoader/Settings/AELAS.kfg to find it.

The config file uses a custom format similar to EVLaS and KiLoader itself. It can be seen as JSON but not quite (with a splash of C) as it was designed for configuration files and better human readability rather than pure object/data transfer.

You can simply open the file with any text editor of your choice (even notepad).

The File

Now to the actual configuration. The mod is separated into a few different modules all working together, which is mirrored by the different objects inside of the file.

Orbital Simulation

OrbitalSimulation = {
	AdjustTimePoints    = true,
	SunSizeCompensation = true,
	
	AxialTilt = 23.4,
	Latitude  = 35.0,
	
	TwilightAngle = 24.0,
	
	MasserOrbitalInclination  = 2.0,
	SecundaOrbitalInclination = 18.0,
	
	YearDays          = 365.0,
	YearStartDay      = 229.0, // 17th of Last Seed
	SummerSolsticeDay = 173.0, // 21st of Midyear
	WinterSolsticeDay = 355.5  // 21st/22nd of Evening Star
}

The biggest piece of the AELAS puzzle. The engine uses completely different and disconnected system for the sun, moons and even stars. In order to synchronize them all, a common simulation is put at the center. This ground truth of sorts is then translated and projected onto the different systems.

AELAS also fixes another issue that the engine’s sun path had to make this feature work.
It wasn’t ever spherical. Weird, right? Normally this isn’t too obvious if the sun is (almost) directly overhead, but with the more realistic path it can take now, it would have turned into a problem.

`AdjustTimePoints`

Allowed values: Boolean (true or false)

Enables synchronization of the engine’s time points to reflect the state of the sun’s orbital simulation. This is required to have variable day lengths throughout the season.
Having this enabled also improves the accuracy of orbits, as no (de)compression of them is needed anymore to fit static time points.
Note that this feature has further requirements when ENB is installed (see Installation).

`SunSizeCompensation`

Allowed values: Boolean (true or false)

To keep ENB compatibility, only certain axes of the sun’s path can be changed freely. This causes the sun to be projected quite far out into the sky at certain angles, reducing its perceived size. This feature compensates for the effect by changing the size accordingly.
When using ENB alongside AELAS, this feature is automatically disabled as it’s incompatible with ENBs sky. Presets are encouraged to use ENB’s procedural sun instead to handle this (which most should already do anyway).

`AxialTilt` and `Latitude`

Allowed values: -85° to 85°

These two parameters are tightly coupled and need to be looked at together.

AxialTilt: The tilt of the planet’s rotation axis, Earth for example has one of about 23.4°.
This is also known as “obliquity of the ecliptic”.

Latitude: The latitude on the planet’s surface.

Now that you know what they’re representing, here’s what this means in action. First of, the absolute sum of both AxialTilt and Latitude can’t exceed 85°.
This limit was needed to prevent the simulation from going into the polar circles, which would result in either the sun never setting or never rising. While this would be nice to have in theory, it presents both gameplay and engine problems that aren’t easily resolved.

With that out of the way, how do the parameters affect what the observer, meaning you, see?
AxialTilt can be thought of as a band of possible sun paths on the sky dome. Throughout the year, the sun’s path moves from one side to the other. Each end of the band is referred to as a solstice, either winter or summer, while the point in the middle is known as its equinox.
The Latitude meanwhile is responsible for the declination of the path “band” created by the axial tilt.
Both therefore influence the day length in a similar albeit slightly different manner.
Aside from the sun, stars are also directly influenced by this.

What does that mean in practice?
The easiest way to take advantage of the simulation is simply using the Latitude of a place from the real world and putting it into the simulation. Beware that you can’t go into the polar circle tho!

Short version if you would rather tweak it manually:
AxialTilt influences how far the orbit deviates from the “middle” throughout the year, while Latitude influences how much the entire orbit is tilted.

`TwilightAngle`

Allowed values: 0° to 90°

Adjusts the point at which twilight ends and the night begins. The angle refers to the sun’s distance to the horizon. Simply put, the higher this angle is the longer the sunrise/-set duration.
Because the duration is tied to the actual sun path now, it changes throughout the year or based on the latitude/axial tilt that’s used for the entire simulation.
This can go as far as having no real night at higher latitudes (or with a high enough TwilightAngle) during the summer, or the opposite during the winter. Allowing the replication of real-life phenomena such as “white nights”.
Note: This isn’t set to a realistic value by default (it should ideally be 18 or lower) to ensure better compatibility out-of-the-box compatibility with setups tweaked for the vanilla system.

`Masser`- and `SecundaOrbitalInclination`

Allowed values: -85° to 85°

These two influence the moon’s orbits only. They can be seen as axial tilt of sorts, creating a “band” of possible paths throughout the year similar to the sun.
Latitude affects them the same way as the sun’s and star’s paths. And just like them, both also have an individual 85° limit (absolute sum together with the current latitude).

Calendar

Allowed values: 0.0 or higher (but less than YearDays)

Allows customizatation of the simulation’s calendar. Dates are counted in days from the beginning of the year.
YearDays allows you to specify how many days are in a year, all other dates need to be lower than this number.
YearStartDay correspond to the starting date when loading a new save. This is the 17th of Last Seed by default.
Summer- and WinterSolsticeDay adjust the dates for either of the solstices.

Dynamic Ambient Lighting

DynamicAmbientLighting = {
	Enable = true,
	DirTiltScale = 0.8
}

The dynamic and improved counterpart to KreatE pre-computed DALC fix, replacing it almost entirely.
That being said, you’ll still want to use KreatE to actually tweak ambient lighting. This only takes over the “fix” part from there.

`Enable`

Allowed values: Boolean (true or false)

Toggles the entire system on or off. Highly recommended to keep it enabled.
Note that KreatE’s fix will be disabled as well if you do this while using both!

`DirTiltScale`

Allowed values: 0.0 to 1.0

This parameter influences how much the directional ambient lighting should be tilted towards the current direct light source. Set to 0 to disable.
The tilt is further influenced by the intensity of the light source, as set in the lighting section below (the sun is considered to have an intensity of 1).
The final tilt value is computed like this DirTiltAmount = DirTiltScale * DirectLightIntensity but can never exceed 1, which translates to the top ambient lighting coming from the same direction as direct lighting (and the opposite for the bottom portion).

Lighting

Lighting = {
	SourceDay   = Sun,
	SourceNight = NightSky,
	MinAngle    = 5.0,
	
	Masser = {
		FullMoonDirectIntensity     = 1.0,
		FullMoonVolumetricIntensity = 1.0,
		NewMoonDirectIntensity      = 0.1,
		NewMoonVolumetricIntensity  = 0.7,
		
		LightingColor = [ 0.15, 0.04, 0.0, 1.0 ]
	},
	
	Secunda = {
		FullMoonDirectIntensity     = 0.5,
		FullMoonVolumetricIntensity = 0.7,
		NewMoonDirectIntensity      = 0.1,
		NewMoonVolumetricIntensity  = 0.7,
		
		LightingColor = [ 0.15, 0.04, 0.0, 1.0 ]
	},
	
	NightSkyDirectIntensity     = 0.2,
	NightSkyVolumetricIntensity = 0.0,
	AuroraVolumetricIntensity   = 0.5,
	NightSkyLightingColor = [ 1.0, 1.0, 1.0, 0.0 ],
	
	SunFadeTimes = SunVisibility
}

The main lighting configuration allows adjustments to direct and volumetric lighting and its sources. It’s similar to EVLaS with some key improvements.

`SourceDay` and `SourceNight`

Allowed values: Sun, NightSky, Vanilla, Zenith or Custom

Set the direct and volumetric lighting source for day and night.

Sun: Uses the actual position of the sun as a source.
NightSky: Uses either of the moons or the sky itself as a source.
Vanilla: Lets the engine handle direct lighting.
Zenith: Locks the lighting to be directly overhead.
Custom: A custom incident vector in the form Source = [ 0, 0, -1 ] can be supplied alternatively.

Normally AELAS fades out both lighting types during sunrise/-set before re-synchronizing it with the new source. However, if both day and night sources are the same, no fading will occur.

NightSky mode is special compared to the other ones as it switches between multiple sources dynamically.
Their priority depends entirely on their current intensity. The one with the highest intensity will be chosen unless it has faded away, in which case it uses the next highest one and so on.

`MinAngle`

Allowed values: 0° to 90°

The minimum angle that the direct lighting is allowed to have above the horizon. 0° means the lighting will always stay synced to the source while 90° would not allow any movement from the zenith.
This directly influences the performance impact shadows have in your game. Choosing a higher angle will result in better performance during times with long shadows at the expense of synchronization accuracy.

`Direct` and `VolumetricIntensity`

Allowed values: 0.0 or higher

Allows you to set the intensities for both direct and volumetric lighting throughout the moon phases and the night sky itself.
Interpolation between full and new moon happens exponentially and in steps. Exponentially to mimic how moonlight in real life doesn’t decrease linearly with the phases. And in steps to keep the intensity in sync with the current phase texture of each moon.
When auroras are in the sky, a separate volumetric intensity parameter is used instead of the normal night sky one.

`LightingColor`

Allowed values: 0.0 to 1.0 for each channel

Blends or replaces the direct lighting color for the given source in the format RGBA. RGB represents the lighting color, while the alpha portion affects how it’s blended in.
An alpha of zero means the color is multiplied with the current direct lighting color (basically like mixing the two together), while an alpha of one completely replaces it.

Take the default configuration as an example. Both Masser and Secunda use alpha values of 1, meaning as long as direct lighting originates from either of the two, it will only ever get their red color.
The night sky meanwhile uses an alpha value of zero and pure white as its color. This is essentially a passthrough for the normal weather color as it multiplies it with 1 on each channel.

`SunFadeTimes`

Allowed values: SunVisibility, DuringTwilight or custom

Changes when the switch between day and night sources happens and how the fade in/out is handled.

SunVisibility (recommended): Synchronizes the lighting fade with the fading of the sun itself.
DuringTwilight: Waits for the sun to set completely (or before it rises) to do lighting fade.

Custom: Supplies custom time points for sunrise/-set and fade lengths. Example:

SunFadeTimes = {
	Sunrise          = 6.0,  // Middle point of the switch duration at sunrise
	NightOutDuration = 1.0,  // Fade out duration of the night source before sunrise
	DayInDuration    = 1.0,  // Fade in duration of the day source after sunrise
	Sunset           = 18.0, // Middle point of the switch duration at sunset
	DayOutDuration   = 1.0,  // Fade out duration of the day source before sunset
	NightInDuration  = 1.0   // Fade in duration of the night source after sunset
}

Miscellaneous tweaks

SyncWeatherColorsWithSun    = true
IgnoreCompatibilityWarnings = false

MasserAngleFadeStart  = 20.0
MasserAngleFadeEnd    =  5.0
SecundaAngleFadeStart = 20.0
SecundaAngleFadeEnd   =  5.0

`SyncWeatherColorsWithSun`

Allowed values: Boolean (true or false)

The engine uses two separate game settings to decide how fast the sun should fade away and how much weather colors should be shifted into the night.
Both should be and usually are the same but to make sure they are not mismatched ever, this synchronizes both.

`IgnoreCompatibilityWarnings`

Allowed values: Boolean (true or false)

AELAS has a bunch of checks to warn users about potential problems. One set of them is compatibility checks that will be displayed during the game launch.
This prevents the warning window from showing up.

`AngleFade` overrides

Allowed values: 0° to 90°

These correspond to game settings used by the engine to decide at which point to fade away either of the moons. AELAS overrides them to ensure predictable results.

Weather and Climate separation

A lot of parameters can be changed depending on either the current climate or weather.

Climate

Both the OrbitalSimulation as well as Lighting objects can be defined per climate.

To set something per-climate, define a (partial) object inside of the respective array. Any parameter not declared will be taken from the global object instead.

ClimateOrbitalSimulation = [{
	ID = 0x123456,
	MasserOrbitalInclination  = 10.0,
	SecundaOrbitalInclination = 25.0
}, {
	ID = 0x121212,
	Latitude = 10.0
}]

ClimateLighting = [{
	ID = 0x343434,
	SourceDay   = Zenith,
	SourceNight = Zenith
}, {
	ID = 0x565656,
	NightSkyDirectIntensity     = 0.5,
	NightSkyVolumetricIntensity = 0.5
}]

Explanation of what this configuration would do:

The climate with the ID 123456 will have both moon orbital inclinations changed
The climate with the ID 121212 will get a latitude of 10
The climate with the ID 343434 will have both day and night light sources set to zenith
The climate with the ID 565656 will have a night sky intensity of 0.5 for both direct and volumetric lighting

Weather

Per-weather tweaks work similar to per-climate ones but are limited to a subset of the lighting category. To be exact, only the Sources and MinAngle can be changed this way. Unlike missing parameters from climate settings, the ones inside of here fall back to climate ones first before going with global ones.

WeatherLighting = [{
	ID = 0x787878,
	SourceDay   = Zenith,
	SourceNight = Zenith
}, {
	ID = 0x909090,
	MinAngle = 30.0
}]

Explanation of what this configuration would do:

The weather with the ID 787878 will have both day and night light sources set to zenith
The weather with the ID 909090 will have a minimum angle of 30