Support for Animation "play once" and "pause" statements in conf files

[Astuur]

I would like to suggest a more flexible way to adress a sequence of pictures (animation) using
statements in the corresponding conf file. So this would be an addition to the conf syntax, that the program understands.
AFAIK currently animations can only be played non-stop, wrapping and with variable speed.
I would like to additionally have a pause of variable length, that can be added. (Play-pause-play ...)
As an exaple this could be used for the idle animations of trees (wind does not blow constantly with a constant velocity!)
I would also want support for a "play-once" statement, that would allow an animations to play exactly one time.
An example for this is a "tree falling" animation for the lumberjack.
You can do this now, if you adjust the playbackspeed and duration carefully with the number of pictures you have,
but you may end up with the need to draw extra pictures to make the animation smooth and long enough, or you get
a "double falling action" if the duration is too long, and you cannot further reduce the fps for lack of smoothness.

[Astuur (wolfsteinmetz)]

related to this topic is
bug 826568 "Implement more flexibility for animations of terrain"

[Hans Joachim Desserud (hjd)]

This could certainly be useful, but I'm not sure how easy it would be to implement. One thing which would help here would be a specification for which functionality should be added and how the syntax for it should look. (No offense, but currently this suggestion is a bit vague. ) Could you please attach one or more examples how this should look in the conf-file and how it should be dealt with by Widelands? I think this would give us a better basis for discussion. While creating the examples, please try notice issues which can occur and how they should be dealt with. For instance, I am not sure how you intend to deal with multiple pauses.

>As an exaple this could be used for the idle animations of trees (wind does not blow constantly with a constant velocity!)

Ideally, wind could be dealt with in the code. So you could have various animations which are played different speeds depending on the current wind in that area. This would make wind and trees look a lot more dynamic. It would of course require someone to actually code this, but one can dream... :)

[Astuur (wolfsteinmetz)]

Dear HJD
Do you really want an ignorant user to do that sort of programer's work? ;)
If I understood you well, then you expect almost a sort of blueprint from me
for this? ,,, including syntax .. phew.... ;)
Without knowledge or understanding of the code, without
programming skills, and only the most fundamental insight
into the inner workings of WL, it is damn hard to do that.

Besides, I feel that I meddle with affairs that are none of my business
(any one who actually does program will do better) and
I should not be too precise in all that, to hopefully inspire
a programmer's own creativity, instead of degrading him to a mere
instrument for my personal idea's fulfillment.
After all, all possible coders around here know Wideland well enough
to see the problem, and will probably come up with better solutions of their own!

But okay, if you want me, I'll give it a try - but at your risk ;)

We must distinguish between animations that are defined in
terrainconfig for seamless tiles such as terrain tiles, and
such animations as are defined in the conf files in their own
subdir, be it in widelands\worlds\[SomeWorld]\[SomeItem]\conf or in
widelands\tribes\[SomeTribe]\[SomeItem]\conf.

I'll take the terrain stuff first:

Before I start, let me just mention that there are considerations
from Sirver to replace the numbered png files with mng files in the
future.

Currently (correct me if I am wrong) playing an animation
for terrain tiles is triggered by the "fps=" statement
for the tile in the widelands\worlds\[SomeWorld]\terrainconf file.

The corresponding files must reside in the "pics" directory
underneath, have a base name identical to the section
i.e. "[swamp]" and must be named with sequential
numbers starting at "0" and following a pattern like
swamp_00.png.,swamp_01.png, swamp_02.png

That is all there is to it.
The sequence of so named pictures will be played continously
and unconditionally, wrapping around from swamp_[last].png
to swamp_00.png.
This offers very little flexibility.

Instead of the combined functionality of the fps= statement,
I would rather see this split up into a section that describes
a full cycle for the tiles in question, and offers more options.
An example could be a config file statement in terrainconf
that looks something like this:

animate=[pic_seq] [fps] [pause] [#instances] [t_offset] [loop] [cond] [branch]
animate= : if this is not defined, or the statement is missing, the tile is static and no animation will occur.
[pic_seq]: the name of the picture sequence to be shown i.e. "swamp_??"
[fps]: speed at which the above sequence should be shown.
[pause]:value describes an unconditional pause to insert after playing from swamp_00 to swamp_[max] in 0,001 seconds (allow up to 10 min or so)
[#instances]: value is an integer that describes the number of instances the program should create for this animation. An instance is a subset of all these identical tiles on the current map. The program randomly assignes each tile "swamp_??" to one of the instances.Each instance gets a different delay in playback.
[t_offset]: an integer value in 0,001 seconds that describes each instances starting delay from the previous ins...

[Venatrix (elisabeth)]

Wow, what a long post… But I think it was just, what hjd wanted.

I’m no programmer, too, but I’m a bit used to config files.
First of all: I would split it. As you say, some entries in your animate-part don’t always make sense and it’s not hard to scan a config for more than one keyword. So you could give every single entry (or pair, if an entry is useless without the previous one) an extra keyword. If that pause statement is not used it there will be no pause (just as example).
Another question: Is it really needed to make a finetuning in milliseconds?
That’s what I thought about your post…

> While the wildcarded filenames describe the files to include into the animation and the hotspot sets the relaive position of the animation files, the parameter "#" and "???" are not clear to me (can anyone fill that in?)

As I know that bash uses the '#' as a commentary symbol, I think it is in this case a commentary, too.

[Astuur (wolfsteinmetz)]

Hi Venatrix, and thanks for helping!

You're right about giving extra keywords.
They're easier to scan and easier to understand, too.
One line each; plus it would also be easier to attach a comment explaining what this actually does.

Venatrix wrote:
> Is it really needed to make a finetuning in milliseconds?

No, I definitely don't need 1/1000 seconds, but it seems to be the unit that WL config files use.
animate=working 45000,
sleep=32000;
I think it translates to 45 seconds and 32 seconds.

.. and you're absolutely right about the comment sign (now where did I have my head?)
the whole expression was:
pics=helmsmith_i_??.png # ???
and the comment is to say that 3-digit numbers are also allowed
Solved, I'd say.......

[Chuck Wilder (chuckw20)]

@Astuur: I agree with Venatrix that your presentation of examples of conf file parameters that might support the functionality you are seeking is an admirable and very comprehensive BLUEPRINT of what I might call "User Requirements". You need make no apologies for stating (in very clear terms I feel) what animation controls you are looking for.
As a "non-coder", you obviously display a respectable knowledge of the current workings of the conf files (a knowledge gleaned from many hours of exploration I don't doubt and an experience I, too, have shared.)

As a fellow animator and elder of graphics, I APPLAUD THIS ENDEAVOR AND SUPPORT IT COMPLETELY!

For your information, SirVer and I very recently conferenced on the matter of how WL graphics (animations especially) will be programatically supported in the not too distant future in light of improving their packaging, load time and user experience. Any form the new approach may take will greatly impact "how we do business" with WL graphics and animation. This is a most advantageous time to make these requests (i.e. when fundamental graphics programming changes are being pursued.)

While the ultimate form these actual changes may take may likely differ HOW they are implemented, your "treatise" ;) is well-timed, well-spoken and welcomed!

I happily anticipate advancing this endeavor.

[Astuur (wolfsteinmetz)]

Thanks for the support Chuck, and the friendly words....
Did I have a chance to escape the "treatise" after HJD's post :)) ?

[Chuck Wilder (chuckw20)]

@Astuur#7: Not really. ;)

[Hans Joachim Desserud (hjd)]

>Do you really want an ignorant user to do that sort of programer's work? ;)
Uhm, if you consider someone who understands and edits conf-files, plus contributes with content and bug reports as an ignorant user, I'd like to know what you think of someone who merely plays the game. :p
Jokes aside, there's a lot of good suggestions in your post. I think I need to re-read it a couple of times to fully grasp all of it, but now we have a proposal to discuss at least.

To elaborate a bit more from my previous post, this will be handled by the code, but will ultimately be decided by what people write in the conf-files. Since "pause should be added" seems to vague (IMO), reaching an agreement on how it should be represented in the conf-files will make it much easier to later add in the code. The alternative is of course that some programmer implements something at random (for instance only play an animation once if "PLAY_ONCE" appear after the image_??.png part) which may not be the best long-term solution.

I agree that the animate part should be split up. Most of the entries in conf-files presently are short and descriptive enough that even I can understand most of them just by reading through the file. By adding multiple parameters, this readability would suffer, especially with multiple integer values, making harder for people who don't know conf-files to get started.

>One line each; plus it would also be easier to attach a comment explaining what this actually does.
Ideally, this would work. However, in the real world people don't write comments like this. Therefore the better option would split up the parameters in name:value pairs to "force" people to write it readable.

Also, the branches you suggest, sounds rather similar what programmers refer to as if-else or conditional statements (see description http://en.wikipedia.org/wiki/If_(programming)#If-then.28-else.29). As such, they may add additional complexity to the conf-files, which I am not sure is the best place to handle this.

Thanks for putting the time and effort into your proposal. Keep up the good work :)

[Chuck Wilder (chuckw20)]

We owe it to ourselves and the future of Widelands to DOCUMENT the graphics-related variables and "commands" that now are (as well as those that may come from future development) directly available for use by non-coders.

The degree of complexity required to provide the type of animation control Astuur implies, and to make those controls understandable by anyone who wishes to deal with them, will require a good understanding of the controls and their applications. I feel this can best be achieved by a dedicated and exhaustive reference source that can be made easily available and maintained as new features are implemented.

In other words, we need a "Technical User's Manual" that describes in layman's terms the parameters and controls that are available for use without the need to change compiled programs. I am referring not only to the present conf files, but also to command line and in-game (Hot-key) controls; a manual that documents all of the options available to the mapmaker, animator or anyone wishing to customize their gaming beyond what can be learned through a Player's Help facility.

[Chuck Wilder (chuckw20)]

I apologize for going off-topic for my rant. :(

[Chuck Wilder (chuckw20)]

A while back I took a try at describing the graphics-related conf files. http://wl.widelands.org/wiki/GraphicsDevelopment/#conf_files_for_graphic_elements

[Astuur (wolfsteinmetz)]

@ Chuck, I agree that we need a technical reference, especially for the graphics people and exactly for the reason you give. But your wiki entry is quite good and we may only need to add a few things if ever anything out of this suggestion makes it into a release.
BTW: You should have a PM on the forums, just as Sirver (on a different topic). If not, that feature is broken, but I cannot tell.

@ HJD: Well, as users go, I consider myself an experienced one. But I still see a huge gap to those who actually make things happen codewise. I know next to nothing about that. I wasn't fishing for compliments, but trying to make that difference very clear. As you have proven yourself by sending me too the IF, THEN, ELSE construction, this IS Coders' stuff after all :); but okay if you feel we have a better basis for discussion now, it was well worth while. :)

[Chuck Wilder (chuckw20)]

@Astuur: FYI - I sent you a PM to say I have no recent PMs from you. (We'll see if the feature works in your direction. :)

(Again I apologize for going off-topic.)

[Joachim Breitner (nomeata)]

I’m just adding a comment to remember this bug at the next WiHack; it sounds interesting :-)

[SirVer (sirver)]

Setting to incomplete for bug sweeping.

[Launchpad Janitor (janitor)]

[Expired for widelands because there has been no activity for 60 days.]

[SirVer (sirver)]

I agree that this is a good suggestion. It is hard to motivate somebody to work on it though without a resident artist to put it to good use.

[TiborB (tiborb95)]

This is already implemented, look for "play_once" flag, f.e. in oak/init.lua

[GunChleoc (gunchleoc)]

Not quite - we have the "play once" feature, but we don't have "play - pause - play" yet.

[GunChleoc (gunchleoc)]

Migrated to https://github.com/widelands/widelands/issues/1882