Exported variables in sifz file

A couple of years ago I started noticing that sometimes a version of a file I was working on would become unreadable from the sifz file, due to the inability to read back some named variable from the export list. When this happens I just grumble, accept the loss of work, and figure out some other way to get things done starting from an older version of my sifz. I didn’t bother trying to isolate and report a problem because you know the old saying doc it hurts when I do this, so doc answers don’t do that. But something changed in synfig in recent years.

As evidence, in tutorial Multiplane_Camera - Synfig Animation Studio the example file Multiplane_landscape_example_2.sifz‎ cannot be read in, reporting that a variable MAIN_Z cannot be resolved. This example has to have worked, or it wouldn’t be in the tutorials. I remember running it a few years ago. The other example file, which contains the same variable presumably used a similar way, reads in okay.

I have tried uncompressing such broken sifz’s and editing the sif file, but I’ve never been able to work out magic to satisfy the parser. Thanks for any insight, if I can isolate a simpler example I’ll post it to the thread.

Please do it. Otherwise we could even not know about a particular case/issue. Just search if somebody reported it before in our current issue tracker https://github.com/synfig/synfig/issues .

I just download it and checked it: it is because the “MAIN_Z” definition is stored after being used/referred. It should be fixed.
This error happens since 1.2.1 (at least).

1 Like

Just dropping in to say that I faced this problem multiple times as well and still don’t understand exactly what causes it. Especially on big projects, when you save the list of exported IDs (variables), it might or might not get rearranged and the project won’t open anymore.

I think it happens when you clear animation from an exported node (remove all waypoints), but I am not sure. I am currently working on a big project and hopefully will be able to finish it soon. After that I will also try to isolate this problem and come up with reproducible example, because it’s hella annoying and needs to be fixed.


Reproducible or not, if you can (privately or not) share the problematic file, we may be able to fix that particular file or the save/load bug itself

“it is because the “MAIN_Z” definition is stored after being used/referred. It should be fixed.
This error happens since 1.2.1 (at least)”

I would guess that allowing global variables in a somewhat hierarchical system … Not that I’m planning to open that can of worms :-). But if this were addressed as a file reading problem rather than a file writing problem I think we might be looking at the same fix for the multiplane example file and what I’m trying to describe.

I can remember now at least once I’ve made a gadget that could not be saved as sifz that could be read back in. You have no useful file to submit, and you’re left with having to write an essay on how to build the unsavable thing, possibly starting with a savable thing. If you can even remember exactly what you did. These are the moments that make us love Synfig. I did consider submitting a report once when I had one ‘trapped alive’ and could have learned more . I’ll try to remember enough to create an example, if Svarov doesn’t beat me to it!

Also, I’d like to point out that a only a few years ago synfig was far less stable so some of us early adopters got lax about the writing up bug reports, since a lot of them seemed like memory management issues which kind of defy reproducibility. Much respect to those who have been bugstomping and generally fixing things up for the past few years. Synfig is so much more fun to use now that it feels stable.

1 Like