It's best to report any issues to the bug tracker - anything mentioned anywhere else could easily be lost or forgotten. However in this case I did accidentally remove it in some refactoring we did - the new method name is GetProjectFileUrl() but I've added back LoadProjectFileUrl() for backwards compatibility in the next release.
So this either means writing your script somewhere else, which as you note is counterproductive, or just filling in code templates for you.
Is that all you're asking for then? Filling in code templates?
(That's actually pretty difficult because e.g. finding the right place to add setInstanceClass() in runOnStartup() without making a mess of your code is tricky - or if you have multiple runOnStartup() calls which one do you pick, etc. etc.)
I think my proposed solutions would be straightforward and provide a good quality of life. I'm an experienced JS coder myself, and I can see this scaling to thousands of lines of code with hundreds of objects and working OK. Perhaps we should wait until people actually write a lot of JS code and see how it works out.
I'm not sure how the editor would even be involved in either case? Wouldn't that just get in the way? Do you want to type in an init() function somewhere else, for example? That just seems to separate out your code and make everything harder to find, which seems to be an anti-feature to me...
1. Use an init() method that sets up the object like you want
2. The approach I just described of using a common base class can do that
Both are straightforward, no?
The way function parameters now work is far better. The problem with completely dynamic calls is there is no way to know which parameters should be added. Function mapping solves the problem of calling by a string while still being able to pass along known parameters. Normally completely dynamic function calls are not necessary - if you restructure your functions to work with the new system, they may well be much cleaner and easier to understand afterwards.
(Maybe we should take this to the forum, these comment threads are getting pretty deep...)
Also I haven't used GameMaker or Unity much, but I don't think it's too helpful to refer to them - either the language is significantly different to JavaScript, or the way the editor works is significantly different to Construct, or maybe even they have poorly designed features which they're stuck with for backwards-compatibility reasons, and it wouldn't be sensible to copy that. So I think it's worth designing (and explaining) everything from scratch, although that can be informed by how it works in other tools.
I don't see why the approach used in the Ghost Shooter code demo wouldn't work for a large project. You can sub-class as many kinds of object as you like.
You can also use a deeper class heirarchy to avoid code duplication. This is just normal use of JavaScript classes. For example you could have custom MonsterEnemyInstance and ZombieEnemyInstance classes, both of which derive from a custom EnemyInstance class, which derives from Construct's IWorldInstance. Now you can do things like write a single EnemyInstance.die() method, and it can be used with both MonsterEnemyInstance and ZombieEnemyInstance. So as far as I can tell this appears suitably scalable to large projects without code duplication.
I don't know what you mean by that - can you explain exactly what that would do, how it would work, and what benefits it would offer the way it works with subclassing?
You can already just add the behaviors to the objects and use them instead of code. The point of the example was to use 100% code and no events or behaviors.
See Subclassing instances for how this works in r152.
As has been the case for some time, no new features will be developed for Construct 2.
Please report bugs to the bug tracker following all the guidelines or they won't be investigated.
It's a way of using your own custom class deriving from WorldInstance. So you can add all your own custom properties and functions, and still do everything WorldInstance does.
Ah, I think this can be done with subclassing. No need for separate scripts for that.
Member since 21 May, 2007
The official blog for all things Construct and Scirra run by our employees!
Wider technology issues from Ashley's perspective.