JavaScript Lazier-Than-Expected Execution

the javascript patch is in fact too lazy -- it only evaluates on initial frame conditions, or when an input changes (the only other alternative is to have it eval every frame, and that can be prohibitively expensive). This is normally ok, but sometimes there are cases where you want it to operate more frequently (for feedback, or time-based things)

The way I work around this is to add an extra __number input called "ignored", and attach Patch Time to it. This causes a continuously-changing input, and thus a continuously evaluated javascript.

[another cool way to get it to evaluate is to drag the JS patch around in the editor -- there's a QC bug where moving the patch causes it to think it needs to be reevaluated]

cwright wrote:
the javascript patch is in fact too lazy -- it only evaluates on initial frame conditions, or when an input changes (the only other alternative is to have it eval every frame, and that can be prohibitiv

I knew about that one (and the dummy input workaround, which I've used many time in the past). But in this case, even changing the input values doesn't seem to force re-evaluation, or if it does, the new numbers don't seem to propagate down to the sprites inside the Iterator.

This is on QC 3.1/Leopard, incidentally.

a|x

In this case, your error's in part in the javascript:

var grid = new Array();
var counter = 0;

These happen outside of the main function, so they only ever happen once, even if the inputs change (changing inputs cause the main function to reexecute, but not stuff outside of main).

Because of that, counter never gets reset. If you change width or height, you'll notice that the output structure keeps growing -- it's adding additional members, but it keeps tacking them on the end, endlessly.

Put counter = 0 in the main function, and possibly the grid = new Array() line too -- that should reset everything when it's reevaluated.

That one's really handy for making resources reload unintentionally as well ;)