I will break it down for you, and you will see it is not too complicated

Clamp(switch.value('openness') - 100 * timedelta, 0, 10000)

I am doing this from memory so hopefully it is close to what I did for you.

Clamp(A,B,C) is a useful event. It takes what you put in as A, and has B as a lower limit and C as an upper limit.

So A is "switch.value('openness') - 100 * timedelta"

Here I am subtracting 100 per second, you can set this as any value at all, but I like to use 100. When you jump on the switch, openness is set to 400, 400-100 per second is going to last 4 seconds. 600 would take 6 seconds etc

B is the lower limit, so the value of 'openness' will never go below 0, and it will stop exactly on 0.

C is the upper limit, which is not a specific value at all, just bigger than 400.

Did you stretch it across the whole layout or the just the display? If you set it to the size of the displayed area, and have it on a layer that is set to 0,0 for the scroll x/y rate, then it should be quite efficient.

http://dl.dropbox.com/u/1487524/Scirra/ToyLand.cap

Ok, I set up the things you were after the way I do things, and Added a few comments to those sections for you.

1)

I use systems like this for fiddly things, or multiple objects that need to be at the same place. For doors and blocks you are probably best to just manually place them, turn the grid, snap to moving and snap to resizing on.

2)

Matching switches to doors with a variable is perfectly fine. I use variables like this as my trigger system also.

3)

Added to cap.

Make a little white sprite, with a private variable for its opacity time.

Now with a start of layout event set the sprite to 0,0, set its width and height to the screen.(not necessary, just tidier for your layout.)

private variable being 0 set the opacity to 0.

If the pv is greater than 0

-set opacity to 100

-set pv to clamp(whitesprite.value('privatevariable') - 100 * timedelta, 0, 100)

Now, when you want to trigger the flash set the pv to 10 or so.

Everyone so far has been offering you alternative options. Not because they do not want to be able to use huge textures, but because it is a difficult technical issue that construct was never designed to handle.

It is upsetting that because of your single minded approach, you consider the wealth of information given to you a waste of your time.

Developing video games is one logic puzzle after the next, and it takes a while to adjust your thinking pattern to be in line with this. The thought of using a single giant texture for a space scene seems absolutely outrageous to me, but to you it seems to be the only option.

Take another look over this thread, read and explore the many examples given by the 'kings of the hill', and hopefully you will realise they are not trying to hold you back.

Irbis - I am using both distance and line of sight for this one chap

Silent Cacophony - I refer to my ground/solid/terrain/platform bits as collisions, I read over that a few times hoping to be clear and am so used to my blanket term didn't think about explaining better.

I am currently using 10px as the accuracy, but even at 1px it still misses that particular situation. Am thinking of a way around having to use Line of sight.

Hey chaps

I am having some trouble with the line of sight behaviour. I have an enemy character 'sight' the player, It works fine in most cases, unless the player is standing under something like this.

<img src="http://dl.dropbox.com/u/1487524/Scirra/LineOfSightFailing.png">

The height of the enemy, player and collisions is 32px. Does anyone know technical details of the line of sight behaviour? Does it 'detect' from hotspots, image points, center mass or 0,0? I am thinking the reason it is failing is that it is detecting from 0,0 on the enemy, and thus hitting the bottom edge of the platform above.

I have no idea what WikiLeaks is... I am going to investigate now.

There is a steady increase of total objects. I couldn't find any events to destroy or reposition all the objects you are creating. I set the 4 main objects to destroy when they leave the left side of the screen and that maintained the total objects. Also, so you can check, total objects is displayed at the top right of the debug window when on system.

Use 'on collision' instead of overlapping.

So

sprite1 on collision with sprite2 - add 5 to globalvariable

-destroy sprite2

Might need to put the always above or below the collision event to make it work, try both.

Always - set text to "globalvariable'

It does come down to frame rate. I posted this on the bug tracker a couple of months ago. Unfortunately my monitor can't run any other frame rates to test it a bit more. Here is the link to the bug tracker artifact

http://sourceforge.net/tracker/?func=de ... id=1003219

What is happening in that game is the particles are spawning with a very low speed/random speed value. When the ball is moved it leaves a trail of static particles.

Play with the particle object. You can come up with all sorts of things with it. Changing speeds and spray cones and sizes and colours. It is a very useful tool.