Rocks'n'Diamonds

> I don't really understand what you mean here.

Sorry, I don't know what I meant here anymore.

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. :-)

Francesco wrote: ↑Fri Aug 25, 2006 3:22 pm

Alan wrote:I think this has been mentioned somewhere else, but yes it would be very nice! Zelda's health ceiling for example......

I think there could be a workaround for that. I am not so accustomed to the new features, but it should work.

Use two different CEs to store the health, like CE1 set to value 100 and CE2 set to value 0.

When the player loses health, subtract n from CE1 and add n to CE2.
When the player gains health, add n to CE1 and subtract n from CE2.

In this way you can have a fake ceiling, checking when CE2 gets again to 0.

Sorry for waking up this thread after more than a decade.

Regarding the “Zelda health ceiling” problem, maybe this was already solved long ago, but for what it’s worth, it can be done within a single CE:

+ and - in RnD truncate values, and we can use that to our advantage.

For example, to set VALUE to MAX(VALUE, 10), do this:
Set VALUE-=10
Set VALUE+=10

Correspondingly, for the Zelda problem of MIN(VALUE, 10), do this:
Set VALUE+=9989
Set VALUE-=9989

For MIN(VALUE, 50) it would be 9949 instead of 9989.

Maybe it’s also possible to solve the dreaded “check/trigger if current VALUE is equal to a fixed number” problem using some combination of the above, but I haven’t found a way.

That's indeed a clever trick! (And, if this should ever be used for MIN value calculations, will set the arbitrarily chosen maximum possible CE value of 10000 in stone. )

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.