Help me fix InstanceBank across exports

For developers using the Construct 2 Javascript SDK

Post » Wed Oct 30, 2013 12:04 am

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

http://www.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

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

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
tlarkworthy2013-10-30 00:06:19
B
14
S
5
G
1
Posts: 60
Reputation: 1,052

Post » Wed Oct 30, 2013 12:05 pm

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.
Scirra Founder
B
387
S
230
G
87
Posts: 24,245
Reputation: 192,210

Post » Wed Oct 30, 2013 4:44 pm

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
B
14
S
5
G
1
Posts: 60
Reputation: 1,052

Post » Mon May 05, 2014 9:28 pm

@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| :( )
B
4
Posts: 8
Reputation: 216

Post » Tue May 06, 2014 10:06 am

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.
Scirra Founder
B
387
S
230
G
87
Posts: 24,245
Reputation: 192,210

Post » Tue May 06, 2014 10:36 am

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
B
4
Posts: 8
Reputation: 216


Return to Javascript SDK

Who is online

Users browsing this forum: No registered users and 1 guest