Hello, whoever is active currently :)
Despite I branched off Apophysis 7x from this project, I still try to keep the I/O stuff in sync for the users convenience. But currently I have plans to alter the Apophysis flame format a bit and I would be glad if you guys could follow up. The last we need is multiple parameter formats.
My thoughts were directed to a more "sane" XML, proper and clean and supported by a schema definition. Long speech short: please download this file and tell me what you think. It contains the suggested XSD and a sample XML file with parameters directly converted from the current Apophysis. Please also read the notes on top of the XML file.
I'm the author of the Apophymator scripts. What you propose to do will apparently break the scripts which I've been working on steadily for at least 5 years. :-((
Apophymator and numerous other scripts of mine read and sometimes write the "xml" files directly from the scripter. Naturally my scripts will still be usable in current Apo versions but my heart sank when I read about your intention to change the format of the parameters.
I just wanted to let you know since you've asked for some feedback.
Well, maybe it's time to add some xml operations functions supporting scripter… something like "XMLWriteTransform(…..)" and similar. It would allow changing and upgrading the format - while keeping future scripts intact.
Right now I'm pretty busy, but in a few weeks I'll have some spare time for myself - and I want to sit down to Apophysis - so we'll talk about it.
The main reason I read .flame files directly is because I want to identify missing variations that may exist in the flames people use with the scripts (I dont' know much of anything about xml… the script just looks at "text".).
Although 7X identifies missing variations that doesn't help if people ignore the info. The scripts inform the user and ask whether to proceed to generate frames anyway. Latest version of my script is here:
Try it with a set of flames that uses some variations/plugins that are not available in your Apo session.
Realize that I'm totally an amateur too. It takes around 2000 script lines to read the flame files. :-/
@Fred- I do not want to change the format all of a sudden. There will be a decent transistion phase of about a half year which enables all script developers and developers of third-party parameter-processing tools to update their work. Most likely, (at least) Apophysis 7x will be able to read and write both formats during the transistion phase.
I think everyone agrees, that the current format is a world of pain for all parsers and needs to be changed.
BTW: treating XML (also if it is terribly malformed) as structured text is always a problem (and that manifestates itself not only in needing 2000+ lines to read parameters) ;)
I think I may implement some rough XML functionality for scripts like utak3r said. Probably, I orient myself on existing streaming implementations like the System.Xml.XmlWriter from the .NET framework.
@Piotr- As mentioned above, that would be pretty cool. Reading and writing parameters is Apophysis' job and it should stay so. As always, I'm happy to share future source code with you.
Sorry George, I'm known to panic over Apo changes. I've seen many remarks about changing the format, and I've seen these for many years IIRC. So it shouldn't actually be much of a surprise. And there's no getting in the way of progress. :-)
I also know that my concerns are only relevant to a very small number of Apo users. Thanks for even considering any issues I might bring up that are unimportant to the wider range of Apo users.
So far I've been able to morph through all of the changes one way or the other. :)
Well, this is why I currently spread the message :) To ensure extension developers are aware of the upcoming changes and begin to refactor their projects. The change is not today and not tomorrow but in reasonable time.
Log in to post a comment.
Sign up for the SourceForge newsletter:
You seem to have CSS turned off.
Please don't fill out this field.