OK. "camera always goes up" solved with small texture animation demo:

So as a result of my research about a upwards moving camera I like to share the results with you:

1. It is correct: You need a hmp (Ground) below your level geometry to avoid an upgoing camera/player camera. Strangely enough. Note the hmp in my 3DGitt demo screenshot.

2. I created a small demo level with a Guard-player with the t_player action attached to the model. The t_player action has been modified
by me so that you can hear footsteps when walking.

The cube with the black and white texture animation has been created separately in WED as a simple map, saved out and loaded in the main level with >add map entity<. Because this map entity had no collision detection I put a level prefab block into the map entity to get a stop collision.

The barrel has a fx_uvspeed attached, You can see it working.

The lava stream at the bottom of the level, again, is a separately created block entity with a texture animation (+0lava to +9lava). It was also build as a simple mesh and then imported. To avoid falling through the lava block I placed a level primitive inside the lava block.
The lava stream movement was created in PCXanim. It is not a uvspeed fx.

The whole level was compiled with >create meshes< set.
Script choice was "Flythrough"
t_player.c modified externaly in SED for footstep sounds.
Collision sound not yet implemented but planned.
Project manager used to add "player parameters".
T7 scripts used.

You can download the small tech demo 3DGitt.cd here:

3DGitt/A8 tech demo download

Best wishes !

NeoDumont

A7 Extra Edition (Sybex)
A8 Extra Edition

Sorry for the late response. The settings dialog appears while the strategy is running.

You should keep WFO enabled. The goal of the MRC is to validate the out-of-sample (OOS) equity curve produced by the WFO process.


Recommended workflow:

Perform a normal [Train] of your strategy first to generate the .par files.
Run MRC.c in [Test] mode. This validates if your out-of-sample results are statistically significant or just due to luck.


Running MRC.c in [Train] mode is even more rigorous as it also checks for "selection bias" (overfitting during the optimization process itself), but it is computationally very expensive and can take a long time with WFO.

The default BarOffset = 940 for daily bars (BarPeriod = 1440) is an internal setting that Zorro only applies automatically if the asset is identified as a Stock (Type 1) in your asset list.


Here are the most likely reasons why you are seeing 0:

Asset Type: Check your .csv asset list. If the Type column is set to 0 (Generic/Forex) or any other value besides 1, Zorro uses the universal default of 0 (alignment at 00:00). For US stocks, ensure the Type is set to 1.
Order of Execution: If you print BarOffset at the very beginning of the run function before calling asset(), it will still show the global default. The asset-specific offset is only loaded after the asset is selected.
Data Source: Even if your historical data consists of minute bars, Zorro won't change the BarOffset unless the asset type specifically triggers it.


Recommendation: While Zorro aims to set these defaults, it is best practice to define the alignment explicitly in your script to avoid confusion across different brokers or asset lists:

c
void run() {
BarPeriod = 1440;
BarOffset = 9*60 + 40; // 940: Align with US market close (15:40 ET)
...
}

Note that 940 is the standard offset for US stocks because the last 1-minute bar of the session starts at 15:59 and ends at 16:00. 940 minutes after midnight is 15:40, which matches the bar timestamping logic (timestamp = bar start time).

Sorry, it was my configuration mistake.
When I printed PIP, I noticed that its value was 0.01, which is wrong for GBPUSD.

The reason is that I was not using Zorro’s built-in history, but instead loaded my broker’s own historical data under the symbol “GBPUSD”.
However, in Zorro’s packaged history data the symbol is “GBP/USD”, and in the AssetFix list has this exact symbol.
But there is no entry for “GBPUSD”.
Therefore no asset parameters were found for my symbol, and Zorro apparently fell back to the default, which was PIP = 0.01.

Zorro actually even warned me about this in the logs, and I overlooked:
"Warning 034: GBPUSD not in asset list"

However, there is still something that appears to be a bug.

In my ZorroFix.ini I have:

But regardless of what I put into "myHistory/AssetFix.csv", Zorro always use the file "History/AssetFix.csv".
So the custom AssetFix file in the custom history folder seems to be ignored.