Help me fix InstanceBank across exports

  • I am trying to debug an issue in the InstanceBank plugin:

    scirra.com/forum/plugin-instance-bank_topic62131.html

    This one is hard as I don't know my way round the SDK, basically there is a line which crashes depending on the deployment

    var objtype = runtime.types[save_obj["type"]];

    which when I run the project directly from construct 2 the save_obj["type"] contains "c_laser" (a names type from my project). And the type is looked up from the runtime no problem.

    However, when I run it from a served HTML 5 webpage, the line crashes because runtime.types does not contain "c_laser", it not contains things encode "t1" ... "t50".

    So I assume the type names have been compressed or something, but I did not minify when exporting the project (though I would like to in the future).

    Is the inconsistency in the runtime.types dictionary to be expected??

    Is there a different way of looking up runtime types by name?

    I would like to be able to develop big object graphs in the development site and still be able to read them afer exporting them to a different runtime. Is that a crazy idea?

    Thanks

    Tom

  • Construct 2 renames all object types after export as an additional protection against reverse engineering. It's caused a few problems though (such as making a 'create object by name' action difficult) so I suppose we might just remove it. In the mean time, you cannot rely on using object names at all. You should only accept objects passed as object parameters to actions or conditions and remember the direct references to them rather than trying to look up objects by name.

  • Yeah, I thought that might be the case. So 3rd party plugin InstanceBank is nice as its an easy way to serialise a lot of data, but its to and from JSON data methods relies on reflection to find definitions.

    I would consider this reverse engineering protection similar in spirit to minification. Thus, I would like to be able to turn it off. Anyway, don't complicate your code base on my behalf. I will bite the bullet and write a proper serialisation mechanism for my project. The JSON serialization was a bit inefficient anyway.

    Thanks

  • Ashley, any plans on removing the object name obfuscation as you mentioned here? this really gives a hard time when developing plugins.

    (Especially if you want to design complex UI interactions with specific sprite objects)

    It would also be nice to point it out in the sdk documentation under Object.Type.name for future generations,

    It was really frustrating to understand that I have a problem, only after deploying my game to a server staging env.

    (not to talk about needing to completely rewrite my code after that. |RANT| )

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads
  • It should be easy to work around if you rely on object parameters instead of the string names of objects. No official features depend on strings of the object names, they rely exclusively on object parameters which export and minify correctly.

  • when you say object parameters do you mean instance variables? can you attach a code snippet to show what you mean?

    currently I was doing something like

    if (currObjType.name === "dialogbox") //

    // get an instance and do some manipulations on it

    //

    Thanks,

    Shuky

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