Feature Request:Data Folder

[d.healey]

@Lindon I can achieve the goal of loading a json file using the File API but it's not the same as what I'm asking for ;)

To use the FileAPI I would have to know the location of the file, using some post install script hackery I could probably add the files to the user's system where I want them, but that's not as straightforward as just using Engine.loadDataFile(); - Which for some reason looks in the user presets folder.

[Lindon]

@d-healey true enough..add my vote(again)

[Christoph Hart]

What's wrong with

FileSystem.getFolder(FileSystem.AppData).goCrazy()

[d.healey]

@Christoph-Hart Scroll up to my last post ;)

With the additional source code folder I add the file at the time I create my plugin. With the appdata method I have to run a separate post install script to add the files where I want them.

If I put the files inside the user presets folder are they automatically unpacked when the user runs the plugin?

[Christoph Hart]

Still don't understand the problem.

1. If you don't want to include the files in your plugin, you need to copy them with the installer
2. If you don't want to copy them in the installer, you need to include the files in your plugin (and extract them on the first startup when they are not there).

[d.healey]

@Christoph-Hart said in Feature Request:Data Folder:

2. If you don't want to copy them in the installer, you need to include the files in your plugin (and extract them on the first startup when they are not there).

This is what I want - are you saying if I put data files inside the userPresets folder then they will be extracted along with the user presets when the plugin is first launched? If I add new files in a future update will they also be extracted?

[Christoph Hart]

@d-healey No you need to implement this yourself.

const var dataFile = FileSystem.getFolder(FileSystem.AppData).getChildFile("MyData.json");

const var initialData = { "Something": true };

if(!dataFile.existsAsFile())
{
    dataFile.writeObject(initialData);
}

[Lindon]

@d-healey -yeah its a right pain to have to do every time you want some data shipping with you product ...

@Christoph-Hart - whats this?

.existsAsFile()

[d.healey]

@Christoph-Hart If I put data files in the UserPresets folder I can access them with Engine.loadFromJSON() can't I? This has been here long before the File/FileSystem APIs.

[Christoph Hart]

@Lindon sorry, meant isFile().

If I put data files in the UserPresets folder I can access them with Engine.loadDataFile() can't I?

Yes, but that's ancient and useless. :)

[d.healey]

@Christoph-Hart lol How about redirecting the ancient and useless function to the additionalSourceCode folder so it works the same as it does for expansions? :) Then I don't have to mess about with post install scripts and the file/filesystem api.

[Christoph Hart]

@d-healey no. AdditionalSourceCode is additional source code that gets compiled. Why would I include that folder into the binary?

[d.healey]

@Christoph-Hart said in Feature Request:Data Folder:

@d-healey no. AdditionalSourceCode is additional source code that gets compiled. Why would I include that folder into the binary?

Hmm I'm thinking of how it works for expansions where we can put any files and access them with the .loadDataFile function. We don't have anything similar when not using expansions.

[Christoph Hart]

@d-healey yes but this is because expansions can‘t contain scripts so it‘s a fallback solution.

[Lindon]

@Christoph-Hart -- but it would be a convenience and nice to have -

[Christoph Hart]

@Lindon I think it's one of the cases where there's not one single use case and then you'll end up nagging me with feature additions or changes to a system that I don't use myself so it gets broken regularly. Especially since the File API gives you full flexibility with a little more housekeeping that you have to do for yourself.

[Lindon]

@Christoph-Hart said in Feature Request:Data Folder:

@Lindon I think it's one of the cases where there's not one single use case and then you'll end up nagging me with feature additions or changes to a system that I don't use myself so it gets broken regularly. Especially since the File API gives you full flexibility with a little more housekeeping that you have to do for yourself.

well yeh I get that, and in passing if you thing we will all stop nagging you about something for ever, then who are you and what did you do with Christoph?

But still I'd have thought it a simple (and all encompasing) requirement/feature/use case:

All files in ../DataFiles will be included in the plugin in exactly the same way as samplemaps...

[Christoph Hart]

@Lindon But what is the benefit over including it as script?

[d.healey]

@Christoph-Hart In my case I have "theme" files. Each one is list of every component on my UI with various properties/values. Depending on which one the user selects that gets loaded and the values are applied to the components. I could include these in the script but since they are not doing anything logicy it would just be adding bulk - does this have any impact on performance?

[Christoph Hart]

@d-healey Parsing kilobytes of JSON data takes a few milliseconds so unless you let the user define every pixel on your interface, you should be fine.