I really like the first idea, if it's possible.

I dont think you completely understand, the condition loop

Pair: Loop each

Would repeat the actions for each parent, and select the spaceships and turrets accordingly. So if you have 600 spaceships and 1200 turrets, it would loop 600 times, selecting the turrets for the one selected spaceship.

I just mean so the pairer object would have all the expressions that a sprite does, but with a parameter for the other object.

so if you have multiple instances of Sprite1 and Sprite2 paired with the pairer,

when you have some instances of sprite1 picked in a condition, the expression " Pairer.X("Sprite2") " would give you the X of the sprite2.

Much like if sprite1 and sprite2 were in a container if sprite1 was picked then sprite2.x would give the paired instance of sprite2's X.

oh the actual expression is "mid" not "middle"

and you do need to set them from 1-4 not from 0-3

Oh and, this is how you set it up for multiple instances using an ID value like I was saying, just make sure the initial ID values of the boxes are the same as the matching computer ID value.

<img src="http://www.quotecats.com/what/ComputarID.PNG">

Make some value on the computer - say "code"

start of level -> set code to random(10000)

Give the boxes another value "digit" which will be the digit they show when opened

set each box's initial value digit value to numbers from 0 to 3, each with a unique value, (The effect of this is that the 0 box will show the 1st digit, the 1 will show the 2nd etc)

add a sub-event to the start of level event:

for each box -> set digit to middle(zeropad(computer.value('code'),4),'digit',1)

EDIT: (actually this for each box might not be necessary, can probably just put the action in the start of level event)

You may have to set the initial values to 1 to 4, I dunno if 0 or 1 in that parameter of the middle expression gives the first digit. Try this if it doesn't work.

This is also assuming you're only having one of these doors, would be more complex with multiple ones, but doable by adding another value to the boxes and setting them to the computers UID (or a corresponding extra value on the computer. EDIT: or indeed with containers but then you'd have to make different objects for each box and use a family for the stuff above, which is a bit messier).

When you need to display the digits, the value you need is 'digit', the value to test if its correct is computer's 'code' value.

Pairer plugin sounds really useful, would be cool if as well as loop each pair you could also have

always: set turret X to pairer.X("sprite420")

would always set turret X to the paired instance of sprite420's X

Ah ok, like supreme commander.

What's this about multi-monitor support? you think you'll keep trying to make it work? I use 2 monitors so this would be incredibly cool.

What sort of thing was it? like layout editor on one screen and events on the other?

if you tick the destroy on start up attribute instead does it still happen?

I think the third is the most promising, a lot more original than the others. Guiding him through a maze could be potentially be a really fun (and probably quite difficult) puzzle game, then you could add bosses or whatever where you have to slam him into them at high speed, I dunno I think you could take that one a lot further than the others.

are you scrolling around?, I managed to fix a lot of my lag by adding pick sprite by distance < *some number* above both loops. Is on screen would work too.

Surely you only need one for each loop there, are you using a compare in the system object instead of a compare private variable on the sprite?

so you'd have:

for each ship:

Turret value 'UIDofparent' = Ships.UID

You need for each loops to pick from an expression like "Ships.UID" there, but you don't (usually) need them for picking normally.

- [FIX] Behaviors + mouse & keyboard object input no longer responds when window has not got focus

YES!

I had (still have a little bit) similar problems, if you can, move any unnecessary filtering conditions to above the for each loops.

So that instead of doing it 360000 times it will do it 600 or 1 time per tick.

Should probably have some warning about these loops on the wiki. I've found it very easy to throw these loops at every problem in an attempt to fix, without thinking about lag. (Though I prob won't now)

I was thinking the profiler would be a lot more useful if it displayed in the debugger how long each loop was taking. (dunno if this is feasible or not)