This would be easier in JS, but then makes for some gotchas - for example if you put an array object's array in to an object's instance variable then change it from there, both get updated, and that might not be what you wanted.
Better to have the gotchas than to not have proper arrays at all! I'd rather have it always be reference and if you want by copy you can manually copy the array yourself. This is just an organization feature, really.
I'm not sure how exactly you think this would really work (...) you need the condition to pick the instance to run the actions on, so there needs to be a condition involved either way
I'm not sure what the problem is. The current system is to have an event where we pick a variable out of an object, corresponding to the UID that we want to work with. Then we have another event that picks that object by it's UID, and we perform actions on it.
An example: say we want to get the fire rate of a turret. The current workflow is like this:
- Read the UID stored in the array "players" at X position 0
- Pick the character object with the UID above
- Read the turret property of the character object, which will be a UID (but is in fact just a number)
- Pick the turret object with the UID above
- Read the fireRate property of the turret object we just picked
With my proposed system, you'd have two ways of doing it:
- Call the expression players[0].character.turret.fireRate directly. There is no ambiguity at any point about what you are referring to, and the SOL is never modified.
- Use the "pick an object by UID" condition to pick players[0].character.turret, then read the "fireRate" property. The expression editor doesn't understand nested expressions right now.
This example may sound weird, but let me give you a typical scenario of an RPG:
Each character has a healthbar and an inventory with N slots
In the inventory, on slot 0, there is a fire sword
That fire sword has a name, damage, attack speed, critical hit chance, etc.
That sword's damage and critical hit chance is also divided based on it's fire damage and slashing damage
Really the only problem is that the expression editor doesn't understand nesting (because as far as it is concerned, a UID stored in a variable is just a number), the rest is all secondary. Sure we could try to think some magic with regards to modifying the SOL, or calling methods directly by reference, but that's all secondary.
It's feasible to make a plugin that does exactly that with the current SDK, I believe, but we'd need the path expression to be surrounded by double quotes, like jQuery Selectors. It would be better if it was more integrated with the SDK.
[quote:28918sp9] 4 - First class functions. You should be able to return functions as well as store functions as properties of an object. This is something that javascript can already do, so why not?
Again, if you just throw out a programming language feature, how would that really look in the event system? And why would that be useful?
Maybe I don't need to pass around functions, sure, but we need at least a way to have methods without having to clutter the namespace with object-specific functions, as well as a proper way to do callbacks (again, without storing function names in arrays). If we were able to store functions in an object's property lists, that would solve the problem, and if we're doing that, why not go all the way and allow expressions to be passed around? Again, that is secondary, the primary goal is just to allow objects to have their own functions without polluting the global namespace with functions like addItemToPlayerInventory(item,quantity,playerUID)
I'd add most of the other suggestions in this thread have been suggested several times in the past - we have a very long todo list, and a finite amount of hours in the day. So if you really want a feature suggestion to be taken seriously, you should go in to detail about how it would work, give several examples of previously difficult things that become a lot easier with the feature, and some reasons why it's important enough to do before all the other feature requests we have!
Well right now I'd say the biggest thing is to extend the SDK, and for that we need an extensible editor, and for that we need C3, so I think you're already on the right track there. It's hard for me to gauge what's easy and what's hard to do since I don't know the internals of the engine.