Functions and families... oh how I love how you interact

So... ya...

You make a family... you have an event that picks member from the family... you have a function call

The function acts on the family... but affects them all.

Why in the name of cheddar cheese and mud rivers does the SOL not maintain itself through a function call?

The current workaround that I know of is clunky, stupid, and a waste of events. Anyone have a solution, obvious or otherwise?

Is family overlapping

--- for each object in family -> call function (family.uid)

function call

--- pick family with UID function.param(0) -> do stuff

SOL maintaining through functions could at least be an option? right?

I never even considered that a workaround...functions aren't meant to work on any specific objects unless specifically told to. An option to maintain the SOL could be useful, though. If anything to remove the need for "For Each Object" on functions that affect multiple of the same object.

Tokinsom - thats a big problem if functions are not meant to act on specific objects... Kind of makes them mostly worthless, especially from a "good programing" stand point. (except for global operations, such as initiating levels and so on... but even then, why bother with functions?

Even without passing the SOL functions are still very useful. That said passing a number of objects can be done by setting a instance variable on the objects before calling the function and picking them after.

I don't really see what's so terrible about it :T For example in my game I use functions to damage enemies

+Projectile collides with enemy

-Call "Projectile_Destroy" (Projectile.UID)

-Call "Enemy_Hurt" (Enemy.UID)

+On "Projectile_Destroy"

+Pick Projectile by UID Function.Param(0)

+If Projectile.Name = "Blah"

-Do a thing with it

+On "Enemy_Hurt"

+Pick Enemy by UID Function.Param(0)

-Hurt Enemy

So now I can do many things that hurt the enemies just by calling that function, or I can hurt all enemies at once by excluding a UID. I have a higher level of control this way, and no duplicated code whatsoever.

Also sometimes you'll want to store the UID of a different instance than the one that called the function. I do this for a complex moving platform system.

*Shrug* We'll see what Ashley thinks I guess.

Construct 2 Is really not all that object oriented, and I feel that this is something that needs to be corrected. It should be like Python: Procedural and easy to get into without understanding all that OOP nonsense, but with the advanced features available when the student is ready to understand. "Pass SOL" would be a neat checkbox to have on a function call.

That said, It's not critical becuase of the workaround mentioned above. I haven't had any problem passing UIDs around. It's worked quite well for me.

I basically only use functions to break picking, or skip a tick. heh

Tokinsom -

bladedpenguin -

+Projectile collides with enemy

-Call "Projectile_Destroy" (Projectile.UID)

-Call "Enemy_Hurt" (Enemy.UID)

In the case that a projectile collides with 2 enemies, only one will be hurt.

+Projectile collides with enemy

--foreach projectile

---call function...

--foreach enemy

---call function

The end result of your code is fine, assuming I understand the context, but I would say it falls under a simple use case scenario. Creating a compound object with dynamic sensors via families so that all characters in the game can inherit from it is a nightmare. If you want to role your own custom movement controllers, handling collisions and resolving collisions, implementing state control, etc... all via events... well. Things can quickly get ugly. You have layers of families, all needing functions to reduce code repetition but all objects are needing to be selected in tight ways. I jumped ship last project and switched to unity. Much easier. now this project I am getting passed the prototype stage and running up against the same problems.

In general it has been my experience that if you are using prebuilt behaviors and common use case scenarios, nothing is wrong. But the moment you need more, construct is an inflexible quagmire stuck in its own assumptions about what the game creator needs.

newt - lol, I never thought to use them intentionally in that way. How do you skip a tick with a function?

An approach more consistent with C2's design would be:

1. A way to grab the current SOL for an object/family/entire gamestate as a value (say, a JSON string).

2. A complimentary "Restore SOL" condition that this value could be passed to.

Well, you can skip a tick anywhere with wait. A function works well when you need to get past a gpu update, or created objects which are automatically picked.

TiAm

That would be perfect.

newt - so you just have a function that has wait in it? - getting passed created objects is a good use case.

Im not 100%, but I think functions are only synchronous to the cpu, so a draw call can be after.

Edit:

Also you can break the created picking of newly created objects by creating a new sub event, as long as the object wasn't created in the parent.

Then a variable can be used in all the same ways a function can, so technically you don't really need functions anyway.