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.

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?

Tokinsom Aphrodite - Thanks for the reply. I didn't think to mention I was referring to static variables as is defined by programing. I forgot that construct 2 has "static" variables. A bad name to use when the programing world already uses "static" to define a variable that is attached to the object rather than the instance of that object. Basically, if you change a static variable on an object, regardless from which instance you accessed it, it reflects across all instances of that object. Its kind of like a global variable but for only the instances from the object that has it.

I updated the OP to reflect this.

If you had a mob of enemies that react as one, you could have a static variable "IsAlert". If the player overlapped a trigger object, you could set IsAlert to true on one instance of the enemy object type. At this point all of those enemies would have "IsAlert" as true. It is much better than using a global variable to do the same thing.

We need static variables for object types. Both for families and object types. Why no exist?

I am referring to static as defined by programers, not construct 2.

https://www.google.com/search?q=static+ ... 8&oe=utf-8

"A static variable is one that's associated with a class, not objects of that class..."

In other words, if you set an objects static variable it will be reflected across all instances of that object.

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

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

Hey all,

I was goofing around today and figured the system event pick objects overlapping point is a bit interesting...

Shouldn't such an option be tied to the sprite in the collision section. For example: Is object overlapping point. This seems a little more useful and intuitive to me then the system condition. Especially when thinking about the use cases for an object overlapping a point (point based retro collisions for example).

Perhaps I am thinking about it wrong? Maybe it makes no difference?

newt - complexity isn't a bad thing. It's the game makers job to manage complexity in an organized and efficient manner in order to mitigate the risks of making mistakes, getting confused etc... Complexity is often a necessity in doing something innovative in games, as there are now prior guidelines for how something should be done. Collision detection is a topic to fill hundreds of books and consume the waking hours of many professional programers. It can be simple or it can be 50,000+ lines of advanced code, both in the computer science sense and the mathematical sense.

None the less, in construct we have access to several forms of collision detection and two forms of collision resolution. All can implemented with a few clicks. But each of those clicks has a mind boggling amount of complexity behind it.

One offset with another percent offset isn't really that complex (A+B). Also, I'm glad you brought up rotation... you know that layers can be rotated independently, so why can't layers be moved independent of each other? Being able to rotate a layer but not move it is like having a car that has a clutch and gas but no steering wheel.

Hey,

I heard that you can now copy a single tile in the tile map work area. How is this done. Also, why can't you copy an entire area like you can from the tilemap palette. Also, is there a way to copy and move sections of the tilemap? ... -.-

Ashley -

My use case would be as follows: There would be a group of layers that the main game, bg etc are on. Then there would be a group of layers controlled via offsets. Nothing in either groups interact via collisions. As a matter of fact, they each run their own collisions. It's like two different worlds, where one can be seen behind the other, but they have little actual interaction most of the time. I actually run my own collision algorithms at this point... The current system is very... how to put it... single minded? The testing of the overlaps is great and all, but as there are no filters it really only works in a one world sort of way... and the solid attribute is worthless in a context where more than one thing is solid, but only to some things, but in different ways, all simultaneously ... Anyway, I made my own.

Long story short, the world behind the world is like the inside of a ball, as you move about on one side, the other side moves in the opposite direction, but I also need it to move independently. Also, I don't see why the layer couldn't simply have its collisions detected as is, regardless of offset. If the objects in a layer group only interacted with each other, the group needn't brute force the collision detections. I feel like there should be an option to move a layer around and keep collision detection normal to the layer. That way I can have a background layer with objects interacting within the layer and yet still be visually independent of of the main game layer. I don't know if this all makes sense or not.

rexrainbow - very nice! I came up with the same solution last night. Thank you for your help, and thanks again for posting stuff on Endless Loop. It is super handy.

Hey All,

I am trying to get a behavior to access another objects plugin aces but I am having trouble getting it to work.

Specifically, I want a behavior on an sprite to access a tilemap objects expressions. I figured all I needed to do was pass the tilemap object via a parameter in an action and then call the required tilemap expresion via:

this.testing = cr.plugins_.Tilemap.prototype.Exps.PositionToTileX.call ( tilemap, zX);

But I get an error about can't read property of PositionToTileX of undefined...