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?
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.
I already know if we did that, even with rep limits/controls/weighting, 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?!?!"), "make native exporters", and maybe something else like "add support for scripting". These all have serious technical, business, marketing and user experience implications. For example "Construct 3D" is basically an entirely different product which few people will be able to take full advantage of and IMO is kind of a crazy idea, but predictably will be super popular in any kind of vote. 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".
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.
Take the "players[0].character" part of the expression, which appears to refer to a "character" instance variable designed to store an object reference. Suppose the object reference is empty, or was destroyed or is otherwise no longer valid. Now the "players[0].character.turret" part cannot be evaluated. Now there are two reasonable ways to handle this:
- 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.
- return a dummy value like 0. Even this is surprisingly complicated. The event system doesn't necessarily know what the return value of "players[0].character.turret.fireRate" was meant to be, especially since no object exists at the time of the error. E.g. was it meant to be a string or a number? It could always return 0, but then if it was meant to be a string now you can end up with unexpected results since something which is normally a string is suddenly returning a number. If you then later extend this with array types and try to chain expressions like "players[0].character.someArrayValue[0].turret.fireRate", now you might end up returning 0 and then trying to access it as an array (i.e. equivalent to 0[0]), which starts to get even more gnarly a problem.
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? 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? Even if a bunch of clever workarounds were deployed to dodge all these difficult questions, would the end result be something that is still easy, intuitive and useful, or would it just be a minefield of nasty gotchas for large projects?
This is a good example of how as a user it can be difficult to grasp the full extent of what is an apparently straightforward suggestion. It can lead down a rabbit hole of awkward bugs, difficult-to-explain features, gotchas, and make it more difficult to add more features later on.
A little-used feature of the expression system is you can refer to currently picked object instances by index with:
Sprite(1).X
This already works, and reads the X value of the *second* picked Sprite instead of the default first. However this is not always useful since you don't necessarily know which instances are picked or in which order. 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.