Accessing stripped/optimised data in an exported project

Hi everyone,

I have been working on a plugin that requires access to two things of a given object type:

• its name
• its properties' names

I got the plugin working well with the project preview and then discovered after exporting that an exported project actually strips a lot of useful information away during the export process, including the above information.

For example, when exported, the names of types will be rewritten to "t0", "t1", "t2" and the instance_var_names variable of a type will be undefined. Only the raw values of variables will be preserved but not their names.

From what I can tell, Construct does this as an optimisation, which I totally get. But ultimately, I feel like it'd be really useful to have some way to look up this information for a plugin. I've got another tool I'm using to build my level data and I've written this plugin to read my level data and create the objects as necessary but this is preventing me from mapping my other tool's format to the Construct format.

Any thoughts? Is there a way to get this stripped data? Is there a better way to enable using an external tool as a level editor?

Thanks!

I don't quite get it - why do you need objects' names, properties, instance variable names in runtime?

Are you planning to access objects by their 'given' name, something like this?

enemyType = choose("Vampire", "Zombie")

System -> Create instance of Object "Enemy" & enemyType

And this will create an instance of either EnemyVampire sprite or EnemyZombie sprite?

Hi dop2000, yeah that's a basic example of what I'm trying to achieve.

To be more specific, I'm using a totally separate level editor which produces a data format.

And I have written a plugin for C2 that can read that format and instantiate the appropriate objects.

To keep things simple for referring to my classes between the two formats, I just mapped them using the name of the class/instance, similarly the property names are mapped by their name.

So I need an index of these names in C2 after export of the project ideally.

How many objects do you need to create this way? Maybe it will not be such a bad idea to add a bunch of events like this:

If enemyType="Zombie" Create EnemyZombie

Combine all such objects into a family, define an instance variable LevelBuilderCode and use it to link your C2 object with your level builder object. You'll be able to select any object/instance by picking family member where LevelBuilderCode="..."

As for the object-specific instance variables, maybe consider replacing them with dictionaries. You can attach an instance of a dictionary to each object and this will give you an unlimited number of variables which you can easily add/remove/modify in runtime.

One more thing - to minimize the number of objects, group similar objects in one sprite with different animations. Animation name can be passed as a string from your level editor.

As for your original question, I think if you tick Minify Script during export, it may be possible to get the Source Map - the list of all C2 names and their corresponding minified names. This map is used to read logs and error messages of minified apps and there should be some configuration options in Java to generate it.

However, if C2 export changes names before minification, this will not help.

Hey dop2000,

That's a nice idea to map the string names to specific events. But it would be a pain for a large scale project. My hope was to enable to use this level editor for my entire game's development and all level designs.

Regarding the Minify Script tickbox. I think the issue is that minifying the script will happen after this optimisation step anyway and therefore the source map that is generated will simply give info I already have.

Ultimately, I think I will keep my plugin the way it is for the preview process but I will also implement another form of translation of my external level editor's content which will be a non-runtime process. e.g. I will write a script to translate my existing level editor content into Construct's own XML format for layout data. This way I have a "correct" way of translating my level data to Construct's and I still have a quick preview system while developing.

Assuming Ashley's reading this thread, my request for Construct itself would be:

a) Make the export process more configurable. It would be great to have things like "per project configurable export paths" and more options for the level of optimisation (like in this thread, an option to keep a mapping object for object type names and property names would be great).

b) Make the Construct 2 level editor "watch" for changes to XML project files. So if I write a script which creates new layout files in a project directory, I shouldn't have to re-open the entire project to view or even preview my work.

I see you prefer "hacking" methods

Don't think Scirra developers would approve your ways though...