[quote]
But tossing in lives system requires me to disable "saving anywhere" because otherwise players can cheat the system out via save/load.
[/quote]

Actually, from what I understand, it's possible to make an [i]~init[/i] script that would disable subweapons and hearts, as would the [i]OnContinue[/i] script. Cheating via save/load wouldn't bypass that. A lives system also provides another way for easy, normal, and difficult game modes (e.g. 9/6/3 lives).

I won't try to force it into [i]your [/i]game; I do want to complete it for the sake of showcasing it so that both I and others may use it.
 
[quote]
This means upon activating item it`s script creates FFC in specific position (usually in front of Link) assigns variables to him (up to 6 variables + Power, 7th one is a FFC script slot) and FFC runs it`s given script.
[/quote]

This should work via [i]ffcsrcipt.zh[/i] and [i]stdExtra.zh[/i]. I would need to know the exact effects that you want to generate; running an FFC within an item script is not difficult, so placing it in a specific location shouldn't be much harder. What you want that FFC to do is what could make it hard to code, so I would need more information detailing the specific effects that you want to generate.

The flash from the instant-kill cross is an FFC script run via an item pickup; it would also work attached to an active script (on use). The FFC produces a draw command (the flash is drawn via an attached FFC script on the item's pickup script).
The only problem here is that you don't get extra arguments: Arguments must pass from the item to the FFC, or the FFC must be hard-coded with values. (You can't set item arguments, and FFC arguments via the FFC editor. Either the arguments must pass to the FFC from the item or they must be hard-coded into the FFC, or a mixture of the two.)

For example, the flash colour and duration are values set in the instant-kill cross item editor, and passed through into the FFC script that is assigned to the slot set in the item editor. If the [i]item [/i]needs seven arguments, then anything that the FFC does will need to be hard-coded, as the item script will need an empty argument to use to call the [i]FFC slot[/i]. (Hard coding the slot number is a very bad idea.)

If the item itself requires only two or three arguments, then you are left with four or five for the attached FFC. Essentially, you have (8-1) maximum arguments to use [i]in combination[/i] with item properties and FFC properties, as one value must always be the FFC slot.  The eight-argument limitation is IMHO, one of the most limiting factors of ZASM. I would love to be able to make use of the address arguments, somehow, however there is zero documentation for doing that.