Why is the folder structure not used in the final export?

0 favourites
  • 6 posts
From the Asset Store
With this template you will learn how to use the GooglePlay Games native plugin
  • Hello,

    I noticed the foldera I create in the Project hierarchy are not used in the final export. I have different groups of files that need to be loaded at runtime, each group has the same number of files with the same names. So I put each group's files in one folder under Files.

    After export I noticed C3 puts all the files next to the index.html directly.

    Even calling the file using Load Image from URL ignored the folders I created. (e.g. had to write the URI as "name.png" instead of "group1/name.png".

    I recall the same happened with folders under Scripts.

    Folders are basically for organization while editing, not at runtime. If that's true, what's the reason please?

    Thank you.

  • Folders are just for organisation in the editor. They're not used on export mainly because it's difficult to change now, as many projects exist that request names like "file.txt" and expect the fetch to work even if it's in a subfolder. If we change that, those projects will break.

  • Folders are just for organisation in the editor. They're not used on export mainly because it's difficult to change now, as many projects exist that request names like "file.txt" and expect the fetch to work even if it's in a subfolder. If we change that, those projects will break.

    Could there be an option for that in Project Properties?

    A bit similar to legacy scripting; so people can choose to use folders in-editor only vs. editor+runtime.

    If it is not so much work, I think it will be a great addition.

    Thank you.

  • "Add a setting" as the answer to a problem does end up causing a lot of work. It results in difficult and confusing bugs as things go wrong depending on specific settings, and users get confused as to why requests sometimes work in some projects and not others (because again it depends on settings). If you add a few more settings like that you end up with pretty poor usability. So I really try to resist that. It's better in the long run to stick to one or the other. That's why the legacy scripting setting was ultimately removed, so we don't have to have and maintain two separate modes.

  • Try Construct 3

    Develop games in your browser. Powerful, performant & highly capable.

    Try Now Construct 3 users don't see these ads
  • Makes sense, Thank you.

    Another suggestion: is it possible to create a new type of folders; so the current normal Folders are for editor only, and the new "Runtime Folders" will exist in the exported game?

    I think this way, previous projects won't break. And for new projects, the developer can choose which folder he/she wants to add based on the use case.

    It is a useful feature for big projects, specially with scripts. I had to add a JS SDK (with lots of files) to a project once, and the sdk files got mixed up with my own export later.

    Another use case was that I used dictionary files to expose variables to the client (so he can change the data immediately without asking me to change, re-export, and re-send the whole project), and my design files were mixed with the rest of the export files, which made it a bit difficult for him to find a specific file (among other files I used).

    Thank you.

  • A new type of folder is just a variant of the "add a setting" approach.

Jump to:
Active Users
There are 1 visitors browsing this topic (0 users and 1 guests)