Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[Uriah]

I have been trying to find a method for generating files, parsing files, and saving files from javascript, including the creation of a new directory structure in the packages folder.

I have had no success because they either require libraries which are not supported by V8, or cannot be handled by OT. I have tried FileSaver.js, Blob.js, and many others.

I need to be able to generate the following file types: XML, JS and OBJDEF.

The end goal is to be able to generate an entire new package folder with all of the necessary file, including a new script and FDM.

Anyone have a solution?

Regards,
Uriah

[cameni]

You never have arbitrary access to the file system in Javascript for security reasons, otherwise rogue scripts would be able to overwrite files randomly. We can do a special functionality for it, but it must adhere to the same safety rules.

Obviously you could write an external tool that writes the files, the question is why you want to do in Javascript. Do you want to create an addon that can produce the files from UI?
This will also need a dynamic reload.

[Uriah]

Hi Brano,
That is exactly what I have ascertained, JavaScript doesn't include such methods for security reasons. Why in Java? No good reason, just what I have access to. A C++ plugin would be the optimal solution, however so am not sure exactly how to run a DLL plugin as a mod.

The objective is to generate a new objdef and FDM using a GUI within OT, however I now realize the new aircraft wouldn't be available without restarting OT, which probably relates to your dynamic reload comment.

Regards,
Uriah

[cameni]

Yes you need to restart at the moment, but Angrypig should be close to allowing dynamic reloading as he did some work in that regard.

There certainly could and should be a way to write that kind of addons, that would operate on packages and allow to load and modify/clone an objdef together with other properties (FDM files). JS file should probably be just one, in objdef you can define params that are given to the script.

Together with a material editor it can make a powerful mod tool.

[Uriah]

Hi,

Dynamic reloading of the package directory would be great!

in objdef you can define params that are given to the script.

You must referring to this?

Code: [Select]

"parameters" : "",
So in theory, I should be able to compile my C++ addon to a DLL and place it in the Anteworld/plugin folder, e.g. obj_editor_plugin.dll, and access it through a UI which will be launched once the world loads?

I was also thinking about a material editor. It should include the ability to select an object in the world, look up and parse the material file specified in the objdef, load the parameters of each material into the UI and reload a live preview. With dynamic reload, each time the material file is saved, the object would be reloaded, so that shouldn't be an issue at all. It would simply be a matter of parsing the mtl file, modifying the parameters and saving the changes. Sounds easy enough!!!

In-engine graphical editors may actually be the new direction for configuring all of the files, including those of the flight model. It would necessitate a built-in-self-test for each file type, especially for the XML files in the FDM, to prevent the file from being saved/reloaded if there is a syntax error, which may potentially generate a crash to desktop.

For each editor, there would need to be both a graphical and text editing mode, maybe even side-by-side.

With these tools you would never have to leave OT throughout the processing of importing a package, configuring the objdef, editing the materials, writing the script, and building the FDM, all the while avoiding fatal crashes and testing changes dynamically.

If you have ever taken a look at the JSBSim Commander app, it is basically a graphical editor for defining and modifying FDMs. Having such a tool directly in OT not only makes rapid development of flight models possible, but opens up the book to people who don't understand the JSB XML format. Reading these files can be overly intimidating for a novice, and when edits generate fatal errors, it is even more frustrating.

I realize these concepts go well beyond the original intent and scope of this thread, but the more I think about these ideas, the more they make sense from both a user's and developer's perspective.

Regards,
Uriah