[Bug] Saving a .goo file silently changes its parameters

[syskin345]

System

UVtools v5.0.5 X64
Operative system: Microsoft Windows 10.0.26100 X64
Processor: AMD Ryzen 9 3950X 16-Core Processor            
Processor cores: 32
Memory RAM: 11.54 / 31.91 GB
Runtime: win-x64
Framework: .NET 9.0.0
AvaloniaUI: 11.2.3
OpenCV: 4.9.0

Sreens, resolution, working area, usable area:
1: 2560 x 1440 @ 100% (Primary)
    WA: 2560 x 1392    UA: 2560 x 1392
2: 1920 x 1080 @ 100% (On this)
    WA: 1920 x 1032    UA: 1920 x 1032

Path:       C:\Program Files\UVtools\
Executable: C:\Program Files\UVtools\UVtools.exe
Loaded file: Tiny_1_202501282210_14m_1ml_copy.goo [Version: 0] [Class: GooFile]

Printer and Slicer

• Printer: Saturn 4 Ultra
• Slicer: Elegoo SatelLite 1.0.1.4

Description of the bug

Simply loading & saving a .goo file changes its parameters. I don't think it's supposed to happen.

How to reproduce

• slice any shape with Elegoo SatelLite, save (.goo format) [or use my example tiny.goo; ignore how it looks I made a tiny example)
• load into UVTools
• notice LiftHeight = 0
• immediately save as .goo format
• notice LiftHeight = 0.05

The slicer produced parameters BottomLiftHeight = LiftHeight = BottomRetractHeight = RetractHeight = 0, while UVTools changed those four to 0.05.

The slicer also produced BottomRetractSpeed = RetractSpeed = BottomLiftSpeed = LiftSpeed = 0, and UVTools left them at zero.

I will investigate if the all-zeroes from SatelLite could have ever worked, but the resulting mix of zero and 0.05 definitely did not work and seems to have produced no Z movement at all - the print was pancaked.

SatelLite might have produced an broken file, I will check that - but at this point, I am reporting that the process of saving should not have changed any of the parameters (I think?) and it definitely did.

Files

Tiny_1_202501282210.zip

[github-actions]

This is your first time submitting an issue with UVtools 🥳Please review your issue and ensure that the submit template was followed, the information is complete, and not related to any other open issue. It will be reviewed shortly. Debugging is very important and make the program better. Thanks for contributing and making the software better! 🙌

[sn4k3]

The 0.05mm value comes from Chitubox standard for Tilting VAT printers. I followed same rule for goo files. As so when it detects a tilting VAT, auto set those parameters to 0.05mm and disable the editing LiftHeight.

UVtools/UVtools.Core/FileFormats/GooFile.cs

Lines 1075 to 1093 in 27f46ff

	protected override void OnBeforeEncode(bool isPartialEncode)
	{
	Header.PerLayerSettings = UsingPerLayerSettings;
	Header.Volume = Volume;
	Header.MaterialGrams = MaterialMilliliters;
	if (HaveTiltingVat)
	{
	BottomLiftHeightTotal = LayerHeight;
	LiftHeightTotal = LayerHeight;
	if (BottomLiftSpeed > 0.5 || LiftSpeed > 0.5 || BottomRetractSpeed > 0.5 || RetractSpeed > 0.5)
	{
	BottomLiftSpeed = 0.05f;
	LiftSpeed = 0.05f;
	BottomRetractSpeed = 0.05f;
	RetractSpeed = 0.05f;
	}
	}
	}

For example Rook.goo that comes in pen drive for saturn 4 ultra, also have LiftHeight as 0.05mm.

So the problem can be somewhere else.
Maybe also need to set LiftSpeed to 0.05 ...

To test this, open your not working file, go to File - Terminal and send this code:

SlicerFile.BottomLiftSpeed = 
SlicerFile.BottomRetractSpeed = 
SlicerFile.LiftSpeed =
SlicerFile.RetractSpeed = 0.05f

Close, save file and try to print.
Report back with the result.

[syskin345]

To test this, open your not working file, go to File - Terminal and send this code:

Aha! So that's how I can change those! Thanks. Will test (although it might take me until the weekend).

For example Rook.goo that comes in pen drive for saturn 4 ultra, also have LiftHeight as 0.05mm.

Yes, Chitubox sets them all to 0.05 while SatelLite sets them all to zero.

I will also do my best to test if all-zeroes prints at all, because it was very surprising.

As so when it detects a tilting VAT, auto set those parameters to 0.05mm and disable the editing LiftHeight.

I suppose I was mostly confused by UVTools doing it automatically rather than as a repair action, that's why I filed this issue.

[sn4k3]

In the end I think this doesnt matter at all, since these printers dont use our lift anyway.
Printing both on a Saturn works fine either way

[syskin345]

OK, I now think my print failed simply because .goo sometimes fails on those printers.

I still think the parameters should be changed only by manually applying a recommendation, but I no longer think it matters all that much :)

[sn4k3]

I still think the parameters should be changed only by manually applying a recommendation...

No, because people are not aware of any these technical stuffs. And some uses other slicers to convert to these new printers which was causing an issue due the copy of lift height & speeds. Someone filed an issue regarding that, and I implemented a forced sanitize to these parameters when found a VAT moving printer, which Chitubox uses 0.05mm for everywhere, but the issue was when using normal lift values. In that way UVtools force to avoid possible fails due a bad parameter. BTW Chitubox set lift height and speed = to layer height, and that is what UVtools also do.