Kyatric, doesn't LayoutName return the name for the current layout only?

I don't think there's a way to iterate over all available layout names, the only workaround (which is a bit of a hack) is to create an array, fill it with layout names, and iterate over that instead.

Yes, I know but I am still very limited with the free version

Really, ask your parents to buy it for you. It will be pocket change for them, and it will be a lot more fun than most things you probably want for your birthday (besides, the knowledge you gain now will never be lost). I remember having loads of fun with game makers when I was a kid - the experience I gained and the fun I had outlasted all of my toys, books, clothes and parties.

I think he means via events. I never needed such a function so I can't say, but my guess is no, you can't do that.

If that is the case, it should be trivial for Ashley to implement it. If he's too busy or you need this urgently, it's pretty easy to grab the SDK and do it yourself - heck, I'd bet someone on the chat would be willing to do it for you!

So, here's what I've been working on in the past few weeks:

http://dl.dropbox.com/u/39044660/Aimbot/index.html

The plugin that's powering the engine needs some tweaking, and I can't decide if it should be a behavior that you plug into the "turret", a plugin that aims globally regardless of source, or if I should integrate it in my turret plugin

In other news, here's a missile behavior I'm working on:

http://dl.dropbox.com/u/39044660/Missile/index.html

Move your ship with the arrow keys.

The current problem is that the missile is too easy to avoid. I have to improve the accuracy there!

Also, there's a weird shaking when the missile is within a couple degrees of difference from where it should be.

Comments?

and IE is IE.hank you for this comment, you made me laugh.

Personally, I quite like the idea of using an agnostic scripting language to make plugins (I suggest python - it's an alternative to lua that's performatic, supported everywhere, widely known and easy to pick up).

With all plugins written in such language, even if it were to be a custom language developed by Scirra, a tool could be created to convert said plugins to the native language of the exporter, maintaining the plugins compatible across runtimes.

Scirra maintains an open forum, and we're free to discuss competitors products (which shows the level of confidence they have in their product), and I also know Ashley would never diss a competitor (due to potential issues that could arise), but since I'm a regular user, I can say whatever I want, so here goes:

I've used clickteam's products since Click'n'play, and I own MMF Developer 2. Besides the slow development and lack of features (I know Nifflas is struggling to make CT implement things like modularity, code reuse, complex behaviors and a lot of cool stuff, by the way Ashley, you should look at his suggestions for MMF, since they're all gold), the recent craze with exporter creation is a living example of what Ashley is talking about:

Since the plugins are coded in C++, and the SDK isn't good (at all), there are few plugins being developed, and nowhere near the speed we have here - the barrier to entry is too high. They had efforts to improve this since MMF1.5, with tools to create boilerplate code, new SDKs that simplify development, to no avail. The differences between compilers are too great, and you end up having to create a SDK for each IDE.

Besides that, since plugins are written in their native languages, a new SDK has to be written for each exporter (and it takes a long time, most SDKs only come out months after the exporters), and the plugins themselves have to be remade for each new exporter. This means that the product ends up full of holes - there's a plugin for flash only, another that is hardware accelerated, some other for iOs only, and so on - consistent plugins, that is, ones that work across all runtimes, are extremely rare (mostly only official extensions) - and we're not even touching the issues that came up in the transition from MMF 1.5 to MMF2 - many plugins were never converted, because they were closed source.

In conclusion, the best bet (in my opinion) for the plugin issue across exporters would be

1. A unified language for plugin creation, that would enable an automatic plugin conversion
2. A contract that only allows the user to create a plugin if they agree to cede some rights to Scirra (in the case of standard and free licenses, business licenses should be exempt from this) - this would allow Scirra rights to convert plugins automatically without asking for permissions
3. A unified "store" or feature to enable people to download and update plugins (even pay for them) - the rationale is, once C2 becomes popular (and this is already happening), a ton of communities will rise and start creating plugins. This is something that happened in Clickteam, and results in a nightmare for common users, that have to hunt around periodically for latest versions, often can't communicate with authors in case of bugs, authors lose source code (this left a lot of plugins essentially unmaintainable), and some plugins are only found in weird forums.

This would obviously necessitate a lot of time spent on planning within Scirra, since it concerns the future of the company, but I think it's well worth it, even if it puts some features on hold (though please, please make containers, I really want them).

TL;DR Version: Scirra should make or adopt a plugin-making language (even if that ends up being javascript), make a plugin store/list and make a contract for plugin devs.

you're too concerned. I wouldn't waste time implementing complex checks, especially since people can modify your script's variables directly in the browser and fooling your game into doing that "checksum" for the cheated score.

Just check for the absurd: for instance, a player who played for 2 minutes cannot possibly have 99999999999999 score.

so...? Don't waste time fighting against cheaters, let them have their fun.

If you have a highscore table, people who want to cheat will use cheat engine or something similar to hack anyways, and your second best bet (the first being encryption, which is futile since you'd have to decrypt the info in order to read/write) would be to check the validity of the data, which is a complex task (and also a losing battle, since a savvy player could find out how you do said validity checks and spoof his data in order to cheat while passing validation).

If your game truly is sensitive to cheating, such as a multiplayer game, you should have an central, authoritative server and distrust client info, in which case all localstore info is just for caching anyways, so it doesn't matter if the client alters it.

You can get away with bad graphics, never bad gameplay (unless we're talking AAA here).

digimonk, we prefer to keep features separate for our plugins

For instance, one would integrate to roar engine, then perhaps make another plugin for roar's appshop (if that's considered a separate feature) and then another plugin for each third party (facebook,google+,etc)

Also, you can't really "drop" a javascript into a construct 2 project.

Say, do you plan to do a JSON-based API for roar?

There is a loop hole essentially that, on the grounds you are not profiting from the works themselves, if you change the images by at least 20% (by adding or modifying with original content) you can claim enough artistic merit and intellectual property of your own, that they can't really DO anything.

It's not really a loophole, though I'd love a source on those 20%.

Check out this plugin by Kyatric.