I own both CF2.5 Developer Edition and Construct 2 Early Adopter Edition (you can check my badge). Personally, I think they're both worth buying.

CF2.5 for $34 sounds fantastic. Even though both products have a new version upcoming, both will offer discounts for old users. However, keep in mind that developing for CF is torture: the event system is really ancient, and nowhere near the level we're used to with construct.

Unfortunately, as you can see by their release log, they move at a snail's pace. Clickteam Fusion 2.5 is basically just a rebranding of "Multimedia Fusion 2" with very few changes, and that was released in 2006. Since then, all we heard from clickteam were new exporters, because they suck up all available manpower. Clickteam Fusion 2.5 was released in 2013, and we've seen no major changes since then.

Also, while construct 3 will be "just an editor upgrade", don't underestimate how much things will improve. I think it's a testament to the reliability of the engine that it's being reused for C3.

It may seem like I'm hating on clickteam, but that's just because I'm comparing their product to what it could become if it wasn't for their focus on native exporters (which is one of the reasons their community is dying while ours is thriving). They really do have a sweet product that I don't regret purchasing. If you guys want to see the difference that a native exporter makes, it's seriously worth a shot - though, as Ashley says, you may find that the performance gains may not turn out to be as big as you were expecting.

So, yeah, it's worth buying, but don't expect any extras. What you have now is what you'll have in the future.

I think it would be easy in WebGL mode, but extremely difficult in canvas2d mode, because the way tiling transforms work is completely ridiculous in canvas2d. IIRC that's the main reason it's not supported!

In the long-term we aim to drop support for the canvas2d renderer and use WebGL exclusively, so we could revisit it at that time.

Long term meaning "construct 3" or "in 5 years or more"?

I'd love some rotatable 9-patch to do things like lasers, (as mentioned above) arrows and map editors.

i don't see why everyone is throwing so much hate on win10.

Since you asked, for me personally it's not even the metro interface. That's just a symptom of what, for me, is a "dumbing down" of windows, apparently to make it more accessible to average people, but to the detriment of power users like me. Many options and features that were available and easily accessible were either removed or hidden, becoming accessible only via registry hacks or the use of third party programs.

This is a trend that started with vista, by the way. UAC is a linux ripoff (not that it's a bad idea - far from it, it was long overdue), with zero customization options. Want to set a program to automatically gain elevated privileges? Tough luck. Want to customize how windows update downloads patches, and when/whether to apply them? Tough luck. We gave up everything that made windows good for what? Metro tiles?

Windows 10, especially, feels like a "free to play" windows. You know that old adage: "If you're not paying, you are the product"...

i don't see what the big "privacy fuss" is all about. like you ever spend 20hours reading eula before installing windows. just because media went batshit crazy on the privacy issue like it's something big doesn't mean that win7/8 isn't "spyin'" on you as they call it.

Privacy is the biggest issue in this century, you can't just say "privacy fuss" and move on... Windows 7 is not a saint, but at least the data it collects is optional, and it warns you before doing anything with it. Windows 10 collects all kinds of data and phones home, with no option to disable it (besides downloading third party programs of dubious origins, registry hacks, etc.), and even if you do disable the options, there's no guarantee windows will respect them, since some updates apparently reset the choices. I doubt there will ever be an update that "accidentally" changed the privacy settings to maximum.

sending data through internet is done no matter what windows you use. your browser collects it, google collects it, everyone collects it. you can't get rid of it.

Sure you can. Use firefox, mess around in chrome... in fact everyone got super worried when "evercookies" were invented. There's even a linux distro (backtrack) that's specialized in leaving no traces. I could go on about TOR and VPNs and stuff but it's not necessary.

and trust me, i'd rather have an updated windows system then some linux (i'm not saying that linux is bad, but it's got a lot of problems & driver / partition issues and so on..), because it runs fast, supports everything and their new "stuff" is somewhat taken from linux (multiple display desktops and such ideas) which is nice to see. but performance in general vs 7 (fps and other things - > way better on 10, even 8.1 was way faster). Also i dig the new "flat" look because simply win 7 (we're talking defaults here) look like garbage for todays standards (i know you can shut that off and all but ok..).

The only thing holding me to windows is gaming and a few proprietary tools (construct 2 included). Soon these issues will disappear, and for everything else there are always virtual machines.

Personally wouldn't touch Win 10 with a barge pole. There aggressive push is borderline criminal. I'm sticking with Win7 until it is retired then hopping over to a competitor.

Same. There's no way I'm installing Win 10.

I'm probably switching to linux if they don't make "Win 11" extra special. In fact, I'm not even sure I'll wait for "win 11".

Now all I have to do is choose a distro...

> A way to make plugs using events

>

I'm not sure what this is. Can you explain briefly?

He wants to make plugins and behaviors without using the SDK - using only the event editor. It's something that is often requested around here and something that I personally support.

Still, people are going to want those plugins to be able to draw in the editor as well (which I support as well, but I know it's a humongous task), so I don't know how Ashley will handle that! We have next to no information regarding Construct 3.

How about a nice alternative to the current method of pinning objects ? Maybe in a seperate editor. Drag in all the component parts, place the pins, save all the data and reference all the objects as one when creating the object via events. Like a container but with the pin info.

And the pins could have different joint types, with limited angle of motion, or piston-like pins, things like that...

like box2D and spriter, but with better editor integration.

Sounds like something in construct 3, since we'll be able to hook into the editor.

saiyadjin That's what the thread was missing, a non-content "ad" link to $30 asset pack :-/

That's his signature. He isn't trying to spam.

Besides, I agree, this nonsense about native exporters has to be backed up by evidence. People make a fuss about performance and when Ashley requests their .capx to diagnose the issues, no one provides anything, or when they do, the performance issues are caused by things like maxing fillrate or overusing memory - aka naïve game programming.

Various extra tools can help with this, but it could end up a bit of a straitjacket for event refactoring, and the extra tools to help replace things become very complicated in order to ensure the integrity of the project is maintained regardless of which changes are made. For example it's not enough that "otherobject.turret" is a valid expression, since "turret" could be the name of an instance variable, so even though the "turret" name exists on "otherobject" the expression "otherobject.turret.fireRate" is a syntax error.

I sometimes "refactor" construct projects by editing the XML, which is probably why it hadn't occurred to me. Yeah I admit that that can be a problem.

I'm not saying it's a bad idea - it's probably actually quite a good idea. (...) That kind of thing turns otherwise simple suggestions in to a major project which will consume considerable development time and probably have a range of nasty bugs involved (...) UIDs on the other hand are pretty straightforward, and although they may not be as concise, they work nicely within the existing event system. So I think it's worth trying to think of alternative suggestions still based around UIDs, so we can try and get basically the same usability result, but without having such major consequences.

Well if you can come up with something simple, I'd rather work with a beta/experimental feature full of gotchas than having to code bloat into a game... I'd love to adapt your Sprite[1].X idea in order to be able to type turret[character[players[0]].turret].fireRate in the expression editor and deal with bugs on my own, and that seems quite a simple solution to code, even if it's not as clean as my example.

That's also a microcosm of all feature suggestions in general. This is another factor in having users vote on suggestions: it's easy to vote up cool and easy sounding suggestions, but few users appreciate the true scope of the consequences for the code base, development time, future maintainability etc. If I sound like I'm fighting back, I'm only trying to find the path of least resistance to get the end result you want, which can sometimes look quite different to the original suggestion.

I understand. I don't want my ideas to pass unchallenged either, I mean if they have flaws, they should be exposed as fast as possible, and if they're too unworkable they should be discarded with the least amount of time wasted.

I agree with you on many things (like the dreaded native exporters), and my suggestions aren't necessarily the best solutions either... I could just describe my difficulties, but I like always having a proposed solution to a problem. As long as the "disease" is treated (in this case code bloat and repetition), I'm happy, even if my "treatments" are all discarded.

Besides that, the only complaint I have is that we don't have enough news about construct 3

Yeah, that worked out pretty badly for multiplayer. If the vote counts had been representative, most users would be using multiplayer. From what I can tell, it's just a small minority. So I think that shows that large numbers of users - even a majority of those participating in the vote - will vote up features that sound cool even without actually ever using it.

don't have sales or engagement data for Scirra, but having multiplayer does "check a box", and therefore I'd expect people to be more satisfied with the product once they see it is multiplayer-capable.

I used to be frustrated with multiplayer via websockets (which was the old way of doing it), and was a big supporter (formatting is broken in that thread) of it when it was in development.

Overall I was pretty happy with the end result, and I'd guess that scirra was losing sales because of lack of multiplayer support before, but again I don't have any data to support that claim. Still I'm not sure I'd say multiplayer was a disaster even if people end up rarely using it.

... the top requests will probably be "make Construct 3D" (probably with people saying things like "it's only one extra dimension, how hard can it be?!?!")

I say we are definitely lacking at least some support for 3D. I mean at least some textured primitives should be supported, right? I'd love to be able to do something like this in-game.

Then if that's the highest voted feature and we quite reasonably decide not to act on it, now it's fodder for the trolls: "look, Scirra ignore their users, they don't care what we think".

I can think of a few ways of doing it, but one way would be to return to the forum pools, where you suggest "what's next for construct" and people pick what they want most, this way you are still in control and people still get to vote.

I don't mind that we don't have the page, since you're pretty active in the forums especially with regards to replying to posts when you're called - that's more than enough for me - but I remember that voting and discussing the proposed ideas was a lot of fun.

> Call the expression players[0].character.turret.fireRate directly

>

It's a nice idea and it does look useful. But if you think it through it becomes a lot more complicated with further-reaching implications than you appear to have considered. This makes it far from a straightforward suggestion.

I get that there are edge cases that are hard to work around, but other parts of construct have similar things anyways. There are plugins that throw warnings in the debugger when you do something unexpected, for instance. Overall this stems from the idea that user code should never generate errors, which IMHO is naïve, but I get the rationale of catering to beginners - in the end it's as if we ran code with error warning turned off and an exception catcher that does nothing. I mean, even excel has #N/A and Err:000 placeholders, but that's outside the scope.

Imagine the following is already implemented in Construct:

• Arrays and dictionaries can be referenced directly in the expression editor via the syntax Array[0] and Dictionary["index"]
- This isn't hard to imagine and is probably overdue anyways

Objects can have arrays and dictionaries as properties - again, as requested above

There is an expression returnValueByUID(objectUID,property) that, given an object's UID and a property, returns the value stored in that property for the object with that UID

Other similar expressions exist: returnStringByUID(objectUID,property), returnArrayByUID(objectUID,property) and returnDictionaryByUID(objectUID,property)

The expressions listed in 3 and 4 can already be implemented via the SDK. That way, my players[0].character.turret.fireRate expression would become:

returnValueByUID(returnValueByUID(returnValueByUID(players[0],"character"),"turret"),"fireRate"). Again, this can already be acheived by the SDK, but the resulting expression is messy. It's still better than nothing, though.

- fail the expression evaluation, cancel the action/condition, cancel the event, and log some kind of diagnostic error somewhere. However this can leave events in a half-run state which can leave the game in an unexpected state. This is also different to how the vast majority of events work: you never need to look up diagnostics to see why something isn't working.

This is already what happens if you do it the current way, by picking objects sequentially using the "object UID exists" and "pick by unique ID" conditions. If the UID doesn't exist, your event sheet is left in an unexpected state. If you're a power user, you should be aware of the possible states. This is not a beginner feature.

return a dummy value like 0. Even this is surprisingly complicated.

I know you thought about those things and are perfectly aware of the problems with such a solution: what if 0 is the correct value? How do you distinguish a valid-returned zero from an error-returned zero? Again, an excel-like #NA or #ERR:XXX, or even a debugger warning (like already happens in some cases) would mitigate the issue, but how exactly it should be implemented is up to you. Again, all I want is a reduction in code bloat, which is generated too quickly by the current workflow.

There's also the problem of validating expressions. Right now a strong point of the event system is it is near enough impossible to enter invalid events. However if you type in "players[0].character.", what should autocomplete show and what should the expression validator consider valid tokens to follow it?

Which is why I suggested that there should be a "pointer" property type, so that it could "point" to a specific type of object (this is the same as saying "static typing", which I personally don't like, but whatever, better than not having it). If we could "point" to objects, then we could "point" to arrays/dictionaries, and this solves that other issue of having arrays/dictionaries as object properties.

With pointers, the expression editor knows what to expect, and can keep working fine. It also allows more flexible families and object grouping, so the entire family feature can be simplified.

At edit-time, the editor does not necessarily know what type of object the reference could be pointing to. So should it just dump a list of every behavior and instance variable name in the entire project after it? Is that useful to the user? What if you pick a behavior that does exist in the project, but at runtime the object instance you get does not have that particular behavior?

Make the "pointer" static-typed: you have to specify what type of object the pointer can point to. Issue solved. I mean, you already have to specify that a property should hold an integer/string/bool, why not a pointer to a specific object?

Perhaps a similar feature that picks by UID and *ignores picking* (so you can always get any instance) would be better, e.g.:

Sprite[1].X

would pick the Sprite instance with UID 1 and then get its X position. This is a lot easier to implement and avoids many difficult cases above, but still has some gotchas.

oing by your proposed syntax, your example would become turret[character[players[0]].turret].fireRate. Same situation as above. I mean, sure, I'd rather have that than nothing but I still prefer players[0].character.turret.fireRate

(...) reduce code bloat (...)

Well put. This is basically all we're asking for, really.

That's a terrible excuse, you can modify the elements in-place in a small buffer of vector object and generate no garbage, passing the result by value to a fixed object like you do with any other variable type, the same way you can with arrays.

Especially considering that objects are currently recycled in the same fashion in the current iteration of the engine IIRC.

I don't know why that wasn't done, but the SDK still had references to a deprecated vector type when I first checked, and I believe that's how it was explained in the reasons for deprecating it, but I may be misremembering.

> How about a "Digg" style page somewhere on Scirra.com that we can use to post these feature suggestions and "sales pitches" and then let others vote them up/down to build a C3 feature list? How useful and fun would that be?!

>

A place where people can add and vote for future features (with moderation oc. and a big text that this page is only about suggestions and Scirra may take it into account if they see it right and feasible). Or it could be a page that shows suggested features but not the number of votes it has.

IIRC, Ashley said this wasn't implemented because he was concerned about competition stealing ideas from such a page.