Add starting frame to animated_image

[v-rob]

This PR does the following to animated_image:

• Allows the specification of a starting frame (optional parameter).
• Setting the frame duration to 0 stops the animation.
• On any event, e.g. a button press, the current frame index is returned using the name parameter.
• The syntax has been changed: animated_image[<X>,<Y>;<W>,<H>;<name>;<texture name>,<frame count>,<frame duration>;<frame start>]. Notice the two new parameters and the change from a colon to a comma.

This PR is useful because images can be stopped and restarted at any specific point. For instance, a slide show that automatically goes through the images slowly, but buttons can be used to go back to previous images. Or a primitive soundless video with pause, play, and a scrollbar for video position. This can also be used to place specific images from spritesheets in multiple places on the formspec. So, many different applications.

To do

This PR is Ready for Review.

How to test

Use the updated Minimal formspec. The animated images have been changed to numbers to show which frame is currently shown better. The Current Number buttons will send the index of the animated image to the right of them to the chat.

[Df458]

@kilbith Thoughts re: the syntax?

Personally, I'm indifferent to the syntax changes and the feature seems reasonable enough... It doesn't seem to have many use-cases at the moment, but I assume this will be much more useful when your other proposals start to roll in.

[sorcerykid]

Dumb question, but wouldn't the colon make more sense as a semi-colon to be consistent with other elements where the texture name is always a distinct parameter?

[v-rob]

Not a dumb question. The answer is probably, but GUIAnimatedImage parses that itself, so it acts as one parameter to GUIFormSpecMenu. I don't think that it's a particularly good design to have parsing in the GUIElement, but that's the way it was, and I won't change it unless someone requests it since I'm working on yet another PR. I made this PR so that we aren't stuck with another element with non-extendable parameters without certain features, but it's rather low priority on my list otherwise.

[sorcerykid]

Ah, okay that sounds like a solid rationale for the comma. I hadn't thought of the internal workings. Thanks for clarifying.

[kilbith]

I am in favor of commas but <frame start> should be put after a semicolon to be consistent with the other elements like dropdown or table which have the <selected idx> after a semicolon.

[v-rob]

Ok, I changed the syntax and also moved the parsing code to GUIFormSpecMenu, but don't go testing it yet. I'm going to add an event where, when any event fires, the animated image will tell you what frame is currently shown. This will make it much easier to pause at a specific point.

[v-rob]

OK, this PR is now Ready for Review. I added the event, and I added some more use cases to the first post. I hope this gets merged before the next Minetest release so that we aren't stuck with the current animated_image syntax and have to do some annoying stuff to add this later.

[kilbith]

IIRC, if <name> is specified, fields are sent every <frame_duration> time? 👎 This can be abused.

[v-rob]

No, not every frame duration time. I agree, that would be bad. No; it's only when other events happen. For instance, if you press a button, then the current frame for each image with a name is returned.

[rubenwardy]

Would it make sense for the format to be animated_image[<X>,<Y>;<W>,<H>;<name>;<texture name>;<frame count>;<frame duration>;<frame start>], which could make it easier to specify texture modifiers? Is there anywhere where this format is used/similar to?

[rubenwardy]

Closest appears to be these:

* `[cracko:<tiles>:<frames>:<start>`
* `[verticalframe:<frames>:<start>`

[rubenwardy]

I guess the benefit of commas is that you can rationalise it at the specification of an entity which is an animated texture, and reuse it in other places

[v-rob]

I personally have no preference on the syntax. Now that I've moved the parsing code to GUIFormSpecMenu, either one is as easy as the other. I think the idea for commas is that each parameter is necessary to define the image, e.g. a video is meaningless without the number of frames it has.

Edit: Actually, yeah, semicolons might be better. ^[combine uses commas in its syntax, and I don't think you can escape texture modifiers, there being no need to do so. I'll change it to semicolons unless there are strong objections.

[v-rob]

Two days; I assume there are no objections. I've changed the commas to semicolons

[rubenwardy]

looks good apart from this, I hope to merge this tomorrow

[SmallJoker]

Works

[v-rob]

Ready for merge at any time.

[SmallJoker]

👍 Changes look good. Thanks.