Thank you for the continuing assistance.

I see... You're using a rounded off angle from the Rectangle_Tile pivot to the Player_Tile to shift it back... This works, but the more the tile becomes stretched, the more that shift will become, leading to problems.

In the interim, I had come up with something which similarly avoids making use of the Rectangle_Tile data - basically, Player_Tile.XY is recorded to a PV at every tick and as soon as a collision is detected, Player_Tile is shifted back to the last recorded position, which is always a tick before the overlap.

This is fullproof in terms of collision testing, but I lose your wall sliding effect, which is what I'm after as well...

After seeing your file, I seem to have achieved a solution that fully satisfies all my requirements. The pre-requisite is knowing which condition/actions pick which objects ... Based on my testing:

Conditions - Sprite - Is Overlapping and On Colision always picks only the pair of objects that are currently colliding.

Conditions - System - Collision/Overlap conditions always pick all the object instances that collide in the whole cycle/tick

Actions - CustomMovement Bounce always picks all the object instances that collide in the whole cycle/tick.

So, what I did was to create a Collision_Tile that gets positioned exactly over the Rectangle_Tile once a Rectangle_Tile Overlaps With condition is passed. Then, Player_Tile is bounced off the Collision_Tile with 0 friction, which positions it right outside the collision mask, preserving the sliding motion.

Sorry for the wall of text. Here's a modified .cap which illustrates all the above. Thanks again for your help.

sendspace.com/file/kdx70u

I have, but it does not seem to make a difference.

Here's where I managed to get to. The collisions work as I want them to, except when the Player_Tile overlaps a tile that fails the comparison test while colliding with one that passes it. Left and Right arrow keys rotate the Player_Tile. Up, Down to move forward/reverse.

Thanks.

sendspace.com/file/u136ti

Use negative Width and Height values. Negative Width will flip your tile horizontally and negative Height will flip it vertically.

I have a player-controlled Object and a Family of colliders. I need the Object to pass through some Family Members, while sliding around others, the behaviour being chosen using a Private Varable/comparison condition.

No matter what I do, I'm unable to bounce/slide my object off only select Family members - all the members are always taken as a collider. I have:

On Object Overlaps Family Member

Family Member PV is greater than SomeNumber

->Object bounce off Family Member

Now the issue happens when the Object is already overlaping a Family Member that fails the comparison and comes into contact with another that passes it - the failed member is still used as a collider for the bounce.

How could I rectify this? Any help would be appreciated.

Spider_hip

Are you sure it's not your maths? You can only set absolute values and there's no way to retrieve current parameters... For me, it works flawlessly. Thanks.

Great release, however there seems to be a bug with Families and Effect parameters.

The Action Wizard will not display any parameters on the third screen (setting the actual values) - it will say "There are no parameters for the selected item". 2-state properties will work properly, however.

For example, screen-by-screen:

PickFamily->OpacityPlus->ActivateOpacityPlus will work, but

PickFamily->OpacityPlus->SetIntensity will not, as the third screen will be blank save for "There are no parameters for the selected item".

Randomly, when clicking Finish on the last blank screen, an "Invalid argument" error appears, but mostly the wizard closes and the Action reads 0%.

The Effects show properly inside Manage Families.

Looks like the workaround I posted does not work every time... Seems to be rather random. If you keep switching Families and Family members around, it will eventually allow you to set parameters, however "eventually" can be the next switch or a very long time.

Also on opening the .cap again, the Effect parameters will not be visible in the Event View - the Action will simply say "ObjectName:", copying and pasting it will result in the copy having the proper text, like "ObjectName:SetParameterToWhatever".

I'll post under the R2 release thread in Discussion... Perhaps someone involved with coding will chime in - I've looked throught the Effect shader files and the issue seems to lie in Construct.

I know this is an old topic, but I've run into the same issue and managed to sort-of find a workaround...

To make the Effect parameters appear, first create the Action using a Family member instead of the Family. Then, after the Action is created, modify it and replace the Family member with the actual Family. The parameters will not disappear.

sendspace.com/file/asz5u9

As you can see in the .cap, either an Ex or a Cross, belonging to the Terrain family is created and paired to either a Rectangle or a Circle (members of the MapTiles family), based on the 3D_ID private variable.

The problem is that to perform an action on a given pair, I have to call one of the pair member explicidly, otherwise all of the family members will get affected. Is there any way to rectify this? The disabled event is what I thought would work...

Thanks in advance.

As lucid said, or altrnatively Angle(0,0,Object[Physics].VelocityX,Object[Physics].VelocityY)

Put a Spring on the other side of the door, connected to the wall and increase the spring constant (k) whenever you need the door to "lock".

For checking if the door is locked , you can simply check the value of the constant. A nice side effect is that, at lower values, you'll get an auto-close door.

Is the code in the cap yours or are you adapting someone elses example?

The enemies move constantly because of the events that adjust the speed of the sprites - the RTS behaviour works against that, thus creating a loop.

Once these are disabled, the enemies stop eventually, but not close to the player - your grid size is set to 60 pixels - as soon as the enemies get within 60 pixels of the cell the player is in they will stop.

Lower the grid size for more precision, but not to less than the enemy size - if you do, the enemies may stop moving at all due to the way the grid is calculated.