I finally resolved it. Now it connect correctly

Have you unpacked the fxcm.zip?

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).

The manual says: MaxLong, the maximum numbers are ignored in [Train] mode when the NOMAX flag is set.
But if I use set(NOMAX), zorro says NOMAX undeclared identifier.
I want to enable MaxLong in [Train] mode, is it possible?
Any idea?

Hello,

I am encountering a confusing and apparently inconsistent price-rounding behaviour in Zorro.

When placing limit entries, stop loss and take profit levels, Zorro seems to internally round the actual order prices. On top of that, the rounded execution prices are sometimes inconsistent with what is visually displayed on the chart.

Entry rounding (yellow marks):

• I placed the limit order at 1.27162
• The console log reports that the trade was opened at 1.27200
• Visually, the chart also shows the entry at 1.27200

TP rounding mismatch (blue marks):

• I placed the TP at 1.27317
• The console log reports that the trade was closed at 1.27317
• Visually, the chart shows the close at 1.27300

So in this second case, the console and the chart do not even agree with each other.

• Why are order prices rounded at all?
• What rounding logic is used for entry, SL and TP prices?
• Why can the chart display differ from the console log?
• Which one reflects the actual executed price?
• How can one make visual display and actual execution strictly consistent?

Additional details:

• Version: 2.70
• Fill mode not set (left as default)
• Spread = Commission = Slippage = RollLong = RollShort = 0 (for testing)
• all trade price variables (Entry, Stop, TakeProfit) are double
• set(LOGFILE, PLOTNOW, TICKS); so intrabar entry/exit is enabled

Thank you for your clarifications.

A strategy DLL cannot be released after a run, since it is still needed for chart and panel functions. It is released when the source has a newer timestamp, or when you run a different strategy, or close Zorro. If you debug it with VC++, you can simply click on the "Restart" button after modifying the code. It will then automatically close Zorro, compile, and restart it with the new DLL.

Do you have any plan to implement it?

Is it possible to develop a ccxt plugin for Zorro, enabling it to connect to almost all cryptocurrency exchanges via the ccxt interface for cryptocurrency trading?

This revision is highly necessary, as otherwise the outcome would be too optimistic.

I tested limit orders using the following code. I set Fill=3, meaning the order is filled at the opening price of the next day. I used historical AAPL EOD data. I placed the order on 2025-1-16 with a limit price of Entry = -232.00. I expected the order to be filled at the opening price of 231.86 the next day (17th, as shown in the attached image), but it was actually filled at 231.85 on the 17th, which is 0.01 less than expected. I'm not sure why this is happening. I tested several other dates, and the result was consistently 0.01 less. Any idea?