I have the steam version with personal licence. How do I download older versions? The latest version is blackscreening when built for android, and I'd like to revert and see if it makes a difference. I had no trouble before.

After the last few updates, Intel XDK android builds go to black screen when ran. However, the projects run in the emulator. I also noticed that touch triggers are happening twice in the XDK emulator but work normally in C2. I realize this is all likely Intel's fault, but I thought I'd see if others are having the same trouble.

Tried running the layout and doing the preview over wifi on my android phone in the chrome browser - It shows a number instead of crashing java. The number sits still for a while. Once it started jumping around randomly, but touching and dragging didn't seem to affect the value. Im a bit baffled. I suspect the crash is related to the fact that my PC doesn't have a touch input, since it sort of works on my phone's browser.

Just tried setting a global variable to Touch.AccelerationY, crashes that way to, has nothing to do with Text object. In the debugger, I also noticed that the acceleration values for the touch object are not displayed in the watch window. Bug? Related? Doing something wrong?

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

dropbox.com/s/clj12pivwl7w40o/Acceleration%20to%20Text%20Bug.capx

Steps to reproduce:

1. Just try to run the example. Crash is immediate.

Observed result:

Crash, some java jargon is displayed.

Expected result:

Display of the touch Y acceleration.

Browsers affected:

Chrome: yes

Firefox: untested

Internet Explorer: untested

Operating system & service pack:

Win7 SP1

Construct 2 version:

R160.2

Is there a built in way to isolate a layer in terms of what objects can collide? That is to say, maybe the player picks up an item that is normally on one layer where it could collide with some things. Then the player picks it up and it's now hanging out in the players inventory, and it's been moved to the GUI layer. Now lets say part of the player inventory sorting system relies on collision/overlap detection, but you only want to pay attention to overlaps that occur on the GUI layer. In the meantime, there are other objects like the one in inventory bouncing around in other layers, but you want those ignored. Now, one further condition: all these objects are part of the same family, and the tests have to be done for the family, not the individual family members. (I'm not going to write separate scripts for each and every type of inventory item).

I realize that some filtering can be done by checking which layer an object is on, but I am wondering specifically if there is some setting or built in method of preventing objects on one layer from colliding with objects on another. If there is, it would greatly simplify what I'm doing.

blackhornet Read up on families, and they are EXACTLY what I need, and will continue to be tremendously usefull to me. So, THANKS!

blackhornet So you can test for collision with an object that is a member of a family of objects? I have not looked at that feature yet. If that works, I owe you a thanks!

Is there a way to test for collision with an object bearing a particular UID, but could be any number of different objects? Say in one playthrough, a bullet might collide with your object. Another time a player might. A third time a fireball might, etc, etc, ad nauseum. What if you don't know (at the time of making the game) what might be colliding during run time, but want to get it's UID and check to see if that particular UID is still around several ticks later?

lolpaca You described you design idea well, I understand it. It sound like it would work, but I am not sure what the miners would dig out- a series of objects overlapping as the miner moves from one door to another? That's the only part I hung up on. When I make my man made dungeon generator function, I was thinking of pinning door objects to the ends of random sized hallway objects that get mixed in with regular rooms and bounce around with them, but the only way a hallway gets infected from a room or vice-versa is when a hallway's door collides, not hallway object itself. I don't know if that will work out yet or not, I'm betting there will be some complications that will have to be sorted out.

I like your idea, frankly, and may try to implement it instead. Maybe instead of miners creating a long string of objects (thus eating memory and performance), we have hallways with pinned doors that one end starts at a point on a room and then stretched (play with scale in one axis) until the door pinned to the other end touches another room?

Let me know what you think, and/or clarify your miners functionality?

Guizmus lolpaca You are welcome. Here is the function I wrote for the seeded random part. It's short and sweet and fast, though math eggheads cringe to call it's output 'random'. It is an old design adapted for use in C2. I claim no credit for it's design.

Seeded Random Function capx

lolpaca, I struggled with it too. I decided to abandon the tile-based design (which C2 didn't natively support, per se, at the time that I started writing it.) Instead, I used C2's strengths: object oriented design.

With that in mind, I wrote my random number generator that uses a seed, instead of using C2's. This lets me generate the same random world, like minecraft.

I decided to start off making cave-like dungeons: irregularly shaped rooms and tunnels, all connected to each other somehow. I made a sprite object called cave rooms that has several frames of animation, each frame irregularly shaped. I adjusted the collision boxes to roughly fit the shapes of each frame, yet use no more than 8 sides as is recommended.

Now the generation: You run a loop that creates room sprites, randomly assigns them X and Y, frame number, rotation, and even flipped or not for maximum variability. You make them start moving around randomly, within a boundary. You make one of them stop moving. This one room is "infected" like in the evil sprite demo. Any room that bumps into it stops and becomes infected also. This continues until all rooms are infected, and stopped. Doing it this way ensures that all rooms are connected somehow, no stragglers.

Doing man made looking dungeons would work similarly, but use rectangular rooms and hallways moving in cardinal directions instead of all angles.

For how to keep the player confined to the room sprites, see my post:

scirra.com/.../invert-solid-8-direction-behavior_topic76304.html