How to quickly modify configs.xml

Use the FSMP MCM 😊

Your modified xml will need a Skyrim restart to be taken into account if PrivateProfileRedirector SE - Faster game start (INI file cacher) is installed, so disable it while you’re configuring FSMP.

If you don't want to use the MCM:

• It is MANDATORY to adapt FSMP to your setup by configuring the configs.xml file.
• This file is in Data\SKSE\Plugins\hdtSkinnedMeshConfigs.
• You can create a quick access to this directory in Explorer to access it quicker next time.
• You can modify the configs.xml file while running the game :)
• First you modify it (no need to do it in the virtual filesystem of MO2), then you run the command 'smp reset' in the game console. That way, you can quickly test your changes without restarting the game each time.

Configuring FSMP

General

FSMP is configured through the FSMP MCM or the configs.xml file found in the mod.

All of this is explained in the FSMP MCM, but some parts are better explained here, because I haven’t the place to explain it in the MCM.

Here is the commented file of the last version.

Here is the commented validator of the last version. You can look at it nicely by uploading it to this xsd viewer.

About the time used by FSMP

We run lots of things in parallel threads, so most of your physics don't impact your fps.

You can see in the logs how many milliseconds you use each frame for FSMP:

• 1.0ms = SMP cost very light
• 1ms to 3 ms = SMP cost Normal
• 3ms to 5ms = SMP cost high
• 5ms to 8ms = SMP cost very high
• Above 8ms = You need to manage SMP items in your game °_° !

This cost is limited by budgetMS, the cpu time you reserve for FSMP each frame.

A bit more info here on min-fps

min-fps: (int 60-300), is the main frequency at which physics simulation will advance; in fact, it defines the main period of time at which the physics simulation will advance; (p=1/f).

min-fps should never be configured under 60, or the bullet physics engine would badly bug; thus it will be set it at 60 if you set it lower. The higher it is, the better your physics simulation will be and the more costly for your CPU/GPU. 120 costs twice as much cpu as 60. If no value is set, default is 60.

In the current code is offered the possibility each frame to advance the simulation.

The accumulated time is defined as the time passed since last simulation.

The simulation advances if the accumulated time is greater than half of the tick, defined as the lower of the average frame period and the min-fps period.

The simulation advances then by accumulated time, limited to 'maxSubSteps' steps (by default 4), by steps of one tick, including one last step which can be lower than one tick.

The positives (compared to the ideal code) are (the information is given considering a min-fps set at 60):

• that code generates one simulation of one step each frame when you're at 60+ fps,
• that code allows a correct relation between the simulation time and the game time, ie no speedup or slowdown, as long as you're 15+ fps.

The negatives are:

• when under 15 fps, the simulation doesn't advance as fast as the game time, you'll experience slowdown of the physics-enabled elements;
• that code generates 2 simulations each frame when you're between 30-60fps, 3 simulations each frame when you're between 20-30 fps, and 4 simulations each time when you're between 15-20 fps. That means it is more costly when you're at low fps. An alternative would be not to advance the simulation, and experience slowdown between 20-30 fps, or between 20-60 fps;
• the last step of each simulation is never a fixed duration of time, it depends on the time spent since the last simulation. This NOT advised by bullet developers, and could introduce jiggling. However, it is better than jumping this step, which introduces very visible jittering.

Configuring BHUNP

If you use BHUNP, configure it with its MCM, and especially the “CBPC Physics Toggles” which stops CBPC for certain parts of the body if you use SMP for them. If you don’t, you’ll have jitters, trembling, of these body parts!