We need a "Function call behavior"

jayderyu Wow. I'm not sure what to think about that

The events are intentionally a subset of a traditional programming language. That is why they advertise "no coding required". For those that want to "do coding" that is what the JavaScript SDK is for.

This is true. I'll look into coding a behavior sometime very soon.

I've also had some similar thoughts about doing Object methods. However my thought is to create a behaviour that allows custom javascript, and then passing the core object into the script. I was originally thinking of using Eval, then found out Eval is super slow due to not ever recieving JIT run time compilation. So I'm thinking of looking into a way to get the code into the JIT sooner than later.

It's not the same your request. but good luck. I would like to see self inference object functions. What would be awesomer would also be Object Triggers linked to to Events... drool

And to be fair in optimization. He has made a new blog going into understanding some of the micro optimizations. Such as batching sprite images to single sprites based on layers and a few others. however they aren't in the blog post posted for "Don't waste your time".

well, to be fair, micro-optimisation is always context dependant, if there is really a check of every instances with pick by uid, that would be bothering if your game needs it, but nothing if it was not that used in your game, same goes with collisions optimisations (even though those can be easily the bottleneck), etc... But in that case, if the pick by uid would be wasteful, that would be dissapointing.

always have a critic eye over ashley's blogposts, as he tries both to talk to people that can go really far in wasteful design and also he tries to be general and so, something true can become false depending on how you did your game (the recent render cells are a micro optimisation for a lot of games, it can even be worse, but in some defined cases, it is nice and can save out a lot of time), learning to identify what is really causing trouble is something that will help you in the long run.

also have a critic eye over other people talking about their experiences too, for the same reasons.

locohost

According to the change log "pick by uid" works with a single look up since r127

[quote:37ts1v7b]The condition 'Pick by UID' has been reimplemented to work with a single lookup, rather than iterating every instance. This should make it faster, but it also is now the one condition that is the exception to the rule about picking newly created objects in subevents, i.e. you can call a function on a newly created object, passing its UID, and successfully pick the instance, which did not previously work.

https://www.scirra.com/construct2/releases/r127

R0J0hound Thanks again! This is exactly the info this thread needed. So calling functions, passing in UID as first param, then doing PickByUID is definitely the way to go. Beautiful.

locohost

According to the change log "pick by uid" works with a single look up since r127

[quote:1lz4z8fi]The condition 'Pick by UID' has been reimplemented to work with a single lookup, rather than iterating every instance. This should make it faster, but it also is now the one condition that is the exception to the rule about picking newly created objects in subevents, i.e. you can call a function on a newly created object, passing its UID, and successfully pick the instance, which did not previously work.

https://www.scirra.com/construct2/releases/r127

Great to have confirmation! I should have been aware of this, since I'm using "Pick by UID" for newly created objects rather often. But apparently I didn't store the "single lookup" part in my brain. Thanks R0J0!