Probably it has something to do with being unable to add such a functionality without adding new gadgets. (It is not possible to add new gadgets anymore, as there is no free space left on the corresponding screen.)

If I understand it correctly, then the answer is yes, I meant a new gadget.
(BTW: What about a vertical scrollbar on the CHANGE tab? That would solve the problem, but it would be difficult to program in the current RnD gadgets engine.)

Maybe adding such a scrollbar is not *that* hard -- it would require adding a gadget-sensitive rectangle (to handle half-displayed and non-displayed gadgets outside the currently displayed scroll area), but maybe that can be added with not too much effort. :-)

Ha ha, yes I understand that you use existing levels and tapes as automatic tests, which seems to be both very useful and a very considerate service to level creators. But out of curiosity, doesn't it happen sometimes that a tape fails, and you just go "Dear Mr Creator, there is your ancient level and there is my new and life-altering tweak. One of them has to go and, well I'm sorry."

I understand that you use existing levels and tapes as automatic tests, which seems to be both very useful and a very considerate service to level creators

Yes, that's right. It is very easy to break existing levels and tapes by doing apparently small and harmless engine changes or optimizations, so it is extremely useful to have a few hundreds (or thousands) of levels with their corresponding solution tapes, to check if everything's still fine after such a change. So it is not only a service for level creators, but especially for the players of existing level sets!

(There are many game engine changes that would break the exact timing or whatever of existing solution tapes, but which do not break the level in general, which could therefore still be perfectly solvable if played again -- the problem is that you just do not know for sure, especially for those tricky levels that depend on certain engine specialties or exact timing. IMHO, the better levels out there "survive" such minor engine changes, but there are still those which do not.)

But out of curiosity, doesn't it happen sometimes that a tape fails, and you just go "Dear Mr Creator, there is your ancient level and there is my new and life-altering tweak. One of them has to go and, well I'm sorry."

Yes, indeed.

This is especially true when fixing really nasty game engine bugs that simply should not be there. But fixing them might break very few, or even only one single level of my large collection of reference (test) tapes. In this case I usually tend to fix things up after the change, and either replay the tape with the new (fixed) game engine, or (if needed) tweak the affected level a little bit to make it solvable again (in cases where not only the tape breaks, but the whole level would be unsolvable after the game engine change). A prominent example for such a case is Juergen Bonhagen's special level "bug machine" (sic!). After fixing a very esoteric game engine bug, this was indeed the only tape which did not survive that change, while all those other existing levels and tapes were not affected. In this case, I replayed the level and created a new solution tape (trying to solve it similarly to Juergen Bonhagen's original "reference" solution tape). (If you have ever played this level, you can imagine that this task was quite a bit of work. )

But there are other cases. There was a game engine bug fix which caused most tapes of Alan Bond's level set "Snake Bite" to fail, due to breaking the tricky game mechanics of this special level set. It did not only affect the tapes, but the levels itself, so I had to add compatibility code solely for this level set, which is always nasty. Without the working solution tapes, I wouldn't have noticed that my little engine change would break nearly a complete, very good and popular level set!

Fortunately, cases like your MIN / ceiling trick are usually easier to handle: Values like this dubious "10000" are variables in the game engine, and could be initialized differently depending on the level's or tape's game engine version (which is stored in both files), if that value should ever be changed.