It seems to work. Thanks a lot for the help.

If you get all your obstacles into a family, then you can just spawn the family. It wil choose a random object from the family. It's a bit less of a hassle than choosing a random animation, and each object can have it particular behaviour.

I'm trying to get an object to rotate from a point while also being a physic inmovable object (because I want it to interact with other physic objects while rotating). The problem is that when an inmovable physic object rotates (wether by changing the angle, with the rotate behaviour or anything similar) it takes the centre of the sprite as the rotation point, instead of whatever centre point I have defined. Here's a little demonstration of this:

https://dl.dropboxusercontent.com/u/115 ... 0Test.capx

The blue bar is just a sprite with the center on (0,15) and the rotating behaviour. The red bar is the same sprite with a different colour, physics behaviour (with inmovable on so it has infinite mass) and the same rotating behaviour. Is there a way to make the red bar rotate in the same way as the blue one, while keeping the inmovable thing?

I have run a couple of tests, setting the interval at 5 minutes. The first time, after about 20 minutes, the title of the construct 2 windows changed the project name to project name.autosave, and trying to exit and then save gave me an error (I took a screenshot of it and will post a full bug report later). The second time, It took more than an hour of leaving my computer unattended until the same happened.

I've noticed anyway that when the autosave kicks in, the title of the Construct screen changes to Prpject name.autosave for a moment (while saving it) and then changes back to Project name. So I guess something happens sometimes that doesn't switch the target file and gets messed up.

Anyway, I'll try to write a bug report on the bug forum later, as I can't do it right now.

Sure, I'll try. The times it has happened to me I had a folder project, one with lots of levels and event sheets. I'll try to make some tests and get back to you with the results.

First of all, I'm not reporting this as a bug as I still don't know if there's something wrong with the program, my computer, or anything else, and I just want to know if anyone else is experiencing the same problem.

So, as far as I know, Construct 2 makes new files with .autosave and .backup to keep your work safe. Whenever the program makes this, the real project is not saved at all and you have to save it manually so it updates your project or file.

What I have noticed is that sometimes, mostly after I leave my computer with Construct running unatended for some time, when I come back the name of the file Construct is saving to (which appears on the top of the screen after Construct 2 rXXX - Project name - Level name), changes to Project name.autosave.

If I do save then, the file saved is the autosave, and not the real project, which has caused me already to lose some progress, because it seems like I can't change that so it updates my main file instead of this autosave.

Also, but I don't know if it is related or not, when Construct changes the file I'm working into to this autosave, I get lots of errors trying to test my game, the most usual being no sound and sudden crashes.

I'm thinking that something happens if you leave Construct running unattended for some time, so that it stops working on your project and switches file to an autosave one. Has anyone else experienced anything like this?

I've opened this bug report just becase I was told to earlier today. I know it's not really a bug, but the truth is that my whole game depended on those collisions and since the update it has stopped working.

Link to .capx file (required! If link is blocked remove the http and www parts):

dl.dropboxusercontent.com/u/11564312/particle%20test.capx

Steps to reproduce:

1. Run the .capx in r152

2. Run the .capx in r158

Observed result:

in r152, the big squares (sprites) both check for collision (1) and for overlapping (2). In r158, neither is checked for.

Expected result:

I know particle collision with sprites isn't a supported feature, but it did work up to r158. I'd like to point out too that in order to do this, the events must be done taking the Sprite as the active part, as when choosing a Particle as the active one, the collision and overlapping condition isn't available.

Browsers affected:

Chrome: yes

Firefox: not tried

Internet Explorer: not tried

Operating system & service pack:

windows 7, but don't think it's relevant

Construct 2 version:

r152 and r158

Not really a performance problem, but there's another byproduct of the collision cell update that at least has affected me and the game I'm developing: particles no longer collide with sprites. I know (as Ashley has told me before) that particle and sprite collision was something not really supported or featured, and it may actually be some kind of hidden bug-feature, but I'm just stating it as it's my biggest concern with this update right now.

I'll put a link to my original post, where I also uploaded a capx in case anyone wants to look at it: scirra.com/forum/particles-sprites-and-collisions_topic84682.html

I've been testing a little, and it seems that when you are creating an event for a particle, you can't select either collision nor overlapping, but when you create an event for a sprite, you can pick the particle as the object to test collisions or overlapping to.

Is there any chance particles will go back to how they worked before this update, or will it be like this from now on?

EDIT: Here's a little capx with a particle collision and overlapping test. If you open this in r152, the big numbered squares change react to collisions to particles, but if you open it in r158.2, they won't.

dl.dropboxusercontent.com/u/11564312/particle%20test.capx

After being away for about 1 week and returning, I have suddenly discovered that particles are no longer colliding with anything on my Construct 2 projects after updating to r158.2. I don't know if it's because of the collision cell thing, but the truth is that my whole game depended on sprites colliding with particles, and suddenly nothing works.

Of course I could just go back to a previous Construct 2 build, but it's not really practical at all, so... does anyone know if this change in particle behaviour is an intended change, an unconvenient new feature, or just a bug?

Hello everyone. We are a new indie videogame company based in London, and after finding about this wonderful tool we decided to get our hands on it to start some of our projects. I hope to get some of them soon in the arcade for everyone to see :)

Kybele Studio