Renaming a layer in a switch bug

Discuss Moho bugs (or suspected bugs) with other users. To report bugs to Smith Micro, please visit support.smithmicro.com

Moderators: Víctor Paredes, Belgarath, slowtiger

Dodgy
Posts: 207
Joined: Sat Jan 13, 2007 8:01 pm
Location: Sydney
Contact:

Renaming a layer in a switch bug

Post by Dodgy »

When you have a layer in a switch layer, and you have some animation for it, when AS saves the scene, the old name is used.
Genete
Posts: 3483
Joined: Tue Oct 17, 2006 3:27 pm
Location: España / Spain

Post by Genete »

Can you exaplain it a little more please?
User avatar
Rasheed
Posts: 2008
Joined: Tue May 17, 2005 8:30 am
Location: The Netherlands

Post by Rasheed »

As the sticky says: Please post examples.
Dodgy
Posts: 207
Joined: Sat Jan 13, 2007 8:01 pm
Location: Sydney
Contact:

Post by Dodgy »

1>Add two vector layers, Layer1, Layer2.
2>Parent them to a switch layer, Layer3.
3>Set up an animation switching between them.
4>Save the Scene. In the Switch Layer section of the file, it uses Layer1, Layer2 for the keyframes.
5>Rename a vector layer to 'Layer4'.
6>Save the Scene again.
7>In the Switch Layer section of the file, it uses Layer1, Layer2 for the keyframes still despite the layer names being different.
Genete
Posts: 3483
Joined: Tue Oct 17, 2006 3:27 pm
Location: España / Spain

Post by Genete »

I beleive this is not a bug. In fact is a good feature. If you want to rename a layer inside switch layer after the animation is finished, then the switch layer keeps track of the existing keyframes. It due to the keyframes are set for the layer ID instead for the layer name. The layer name is only for user aid.
Anyway I have not checked it after save the file as you have said.
Dodgy
Posts: 207
Joined: Sat Jan 13, 2007 8:01 pm
Location: Sydney
Contact:

Post by Dodgy »

It is NOT a feature. It's a bug.
How does the AS keep track when it's loading in an old scene?
The switch keys part of the scene file looks like this:

switch_keys
[
keys 3
0 1 0.1 0.5 "Layer2"
6 1 0.1 0.5 "Layer1"
12 1 0.1 0.5 "Layer2"
]

Which are the old names. It works okay if you just change one of the layer names, presumably because it realises that the one it can't find is the one layer it has no data for, but if you change both names and load the scene back in, none of the animation works. It should be saving the new layer names automatically. This is broken.
User avatar
Rasheed
Posts: 2008
Joined: Tue May 17, 2005 8:30 am
Location: The Netherlands

Post by Rasheed »

What happens is the following:
  • in the switch layer the name of the switched layer is recorded when you put a key in the animation channel
  • if the switched layer's name is changed, no layer is selected for those frames in which the switch key applies; instead, the top layer is displayed
If you change the name of a layer within a switch layer, and you want the timeline to be updated, you need to redo the switch keys for that layer in the timeline yourself. Anime Studio does not automatically change the name reference in the switch animation channel.

It IS a feature, and a very desirable feature, because you can temporarily disable a layer being part of the switching process by renaming it. This can be used for debugging animation, e.g. if you use a standard pose as your top layer. If you want to see if certain poses can be left out and replaced by the standard pose, you rename such a pose, so it is automatically replaced by the standard pose.

Anyway, in normal use, it is not recommended to change the name of layers within a switch layer after you have created the switch animation. You first set up what you want to switch and then switch it. There is a right order to things to do in Anime Studio.

Switch layers where specifically created for doing lipsynch, where you create the mouth shapes first, name the layers that contain the mouth shapes according to fixed naming convention, put them in a switch layer, and import a data file containing the switch data.

Using them for other purposes is possible, but you need to be very careful with your workflow, as you have discovered yourself.
User avatar
Rhoel
Posts: 844
Joined: Fri Feb 25, 2005 8:09 am
Location: Phnom Penh, Cambodia
Contact:

Post by Rhoel »

Genete wrote:I believe this is not a bug. In fact is a good feature.
I agree on this - not a bug. If it were a bug, the the way the file played before closing and reopens would be different. The question is, after you change you layer name, does the switch layer still toggle the animation. Answer: No. Thesaved and reopened file play back the same way.

Interestingly, if you dupe the layer 4 and rename it layer 2, you will find the animation then toggles correctly on playback.

If you use papagayo a lot then you will find you will make errors in the layer naming. If the switch file recorded the name changes, it would mess the papagayo lip-sync file up. Also cloning and renaming mouth shapes layers is very common as AI, E and L are clones or minor mods of another layer. The same is true of U and O.

I understand the point you are making but its a procedural problem, two ways of cracking the nut. For me personally, the current way seems to have more benefits.

Rhoel
User avatar
heyvern
Posts: 7035
Joined: Fri Sep 02, 2005 4:49 am

Post by heyvern »

Even if... just for arguments sake only... this might be considered a bug.

It is so insignificant as to be hardly worth mentioning.
It doesn't destroy data. It is easily recoverable and simple to workaround.

Maybe it just needs a new "option". Instead of "fixing" it, add a feature so that it's behavior could be changed.

-vern
User avatar
Captain Jack
Posts: 37
Joined: Tue Feb 06, 2007 2:11 pm
Location: Indianapolis, IN
Contact:

Post by Captain Jack »

As a software developer, I see this sort of thing all the time. The problem is largely one of perception and communication. As developers, we tend to break software issues down into three major areas.

<long-winded-pontificating>

The first we call "bugs". This is any part of the system that is not doing what we intended it to do. If it's our intention that the program save it's data at ten minute intervals, but it forces the computer to re-boot every fifteen seconds, that's a "bug".

The second is a "design flaw". This is very common to software as it ages. If we build one feature in, then add a second feature a year later that depends on the first feature, but the first feature isn't robust enough, the second feature may not work very well. In this case, the first feature wasn't designed with enough clairvoyance to imagine what might be needed elsewhere.

The third is "failure to meet expectations". This last one is very tricky, because the problem arrises when an end user expects the system to work one way, and it ends up working differently. What's really unfortunate about this last one is it tends to spark emotional arguments. Users will employ phrases like "this is stupid" or "how could you possibly", and the developer is upset because he feels, incorrectly, that he's being personally attacked.

All of this is made problematic because all three areas are typically labeled "bugs" by the end user. The end user doesn't care why the software isn't doing what he wants, he just wants it to work. The developer gets on edge when he thinks that his design is being impugned. Throw into the mix that long-time users and fans of the software slide their point of view over to the way the developer thinks, and you get some users defending the "bug", which can make the original user feel like he's being personally attacked for reporting it in the first place.

</long-winded-pontificating>

I don't know whether this particular issue qualifies as a "bug" or something else, but the important thing is that we have a feature of the program that isn't working up to the expectations of at least one user, and it can't be resolved definitively by the documentation. Certainly, something needs to be beefed up somewhere, even if it's just documenting that the feature works this way.
User avatar
Touched
Posts: 504
Joined: Mon Dec 11, 2006 7:33 am
Location: Sunny California
Contact:

Post by Touched »

I think it would be a good idea to augment the official documentation with a more detailed documentation, especially in areas that are heavily used by pros but are barely covered in the official docs, or are documented in such a way that doesn't adequately express their full potential. This forum, of course, is a wealth of information like that, but organising it for instance in a wiki format like on Wikibooks.org would be a good idea, I think.
User avatar
heyvern
Posts: 7035
Joined: Fri Sep 02, 2005 4:49 am

Post by heyvern »

In support of the original poster...

Yes, this feature doesn't work "correctly". If you change the name of a switch SOMETHING should happen to indicate that an unexpected result may occur.

It is not correct that the original name of the layer should stay in the file and not be changed or viewable by the user.

With that being said however, once you know how the feature behaves (oddly or not) it isn't a huge obstacle... but it probably should be addressed at some point. I would rather other more important issues be addressed since this one is not any type of "work stopper".

p.s. Beautiful pontification Captain Jack! Very clear and logical.

-vern
User avatar
Rasheed
Posts: 2008
Joined: Tue May 17, 2005 8:30 am
Location: The Netherlands

Post by Rasheed »

In short, what you suggest, Vern, is that changing the name of a layer inside a switch layer should throw a warning message, if there is a switch layer key in the timeline for that particular layer.

However, I see a problem there. What if there are several layers with the same name in the switch layer? As we all know, names of layers are not unique. How is Anime Studio supposed to know when to throw a warning message?

One could argue that this is not only a bug, but a serious design flaw, similar with the identification of bones (as you have argued in the Feature Request forum). While styles, shapes and point groups have unique names, bones and layers do not.

OTOH if you build your characters in layers, you probably want each character to have the same names for the same objects (head, upper arm, hand, etc.), so layer names should NOT be unique. The same applies to bone names.

I think the switch layer bug "screams" for a feature that is requested by lua scripters: layer data.

Layer data is a method to store general purpose data into a layer. This could possible fix the mentioned switch layer problem, because the Anime Studio program could generate an unique layer ID for a layer, and store that ID in the layer's data container. The switch layer would refer to that unique layer ID, instead of the layer name. Of course, the switch layer would have to be implemented differently and still be backward compatible with old method of referencing to (not unique) layer names.

Storing layer data shouldn't be too difficult, because there is already a data structure in memory (moho.layer). This moho.layer structure should be stored in the .anme project file, by a process known to developers as serialization, in essence, the same as what happens with all other objects (points, bones, layers, etc.) if they are stored in an .anme file.

Of course, if serialization were to be implemented, we'd also like to see objects (object methods and object data) to be serialized, and not only primitive values (booleans, numbers and strings), so lua scripters can give new OO properties to layers that are persistant.
User avatar
heyvern
Posts: 7035
Joined: Fri Sep 02, 2005 4:49 am

Post by heyvern »

Actually the way I see it is very simple.

If you have a switch that has keys already set and you change the name of one of its layers a dialog would pop up asking if you want to change the name and KEEP the keys for that switch or just change the name and REMOVE the keys. Very simple. One or the other.

In a switch layer there should never be layers with the same name. It makes no sense anyway. Yes AS uses layer IDs but from a user perspective how can you know which one to choose? I can see duplicate names anywhere else but not in a switch. The purpose of a switch is very specific and is based on unique layers.

--------------

I am even beginning to questing having the same name for bones and layers ANYWHERE in a document. If you have multiple characters with "head" and "right leg" and "left arm" layers or bones they should still have a different name "Joe head" or "character 1 left arm" or "right leg 3".

This would require AS to rename layers and bones when importing other AS files... just like styles. Tag the document or layer name onto the bones and layers that would conflict.

This is just some rough ideas. I think it would actually require some more serious use case study to come up with a complete solution. I can already see some potential issues. I am actually thinking that in some way, group layers at the root level could be treated almost like distinct "documents" in the file itself.

-vern
User avatar
Rasheed
Posts: 2008
Joined: Tue May 17, 2005 8:30 am
Location: The Netherlands

Post by Rasheed »

I hope you mean "unique within a bone layer", otherwise things get quite complicated real soon. If you don't restrict the uniqueness of bone names to the current bone layer, you would, for instance, need to verify bone names on other people's computers to check if that bone name is already taken.

This would also mean that the occurrence of anonymous bones would have to be coded out of Anime Studio, because those have all the same name (an empty string). Every bone should be assigned an unique name, etc. BoneID (a number assigned to a bone when it is created) would become superfluous, because a bone could be identified uniquely by its name. So the name of a bone would be the same as its ID.

I guess layer names should probably be unique among first generation child layers of a switch layer. In that case a warning message wouldn't be necessary, because Anime Studio could update the name change of the switch layer key without user interference.
Post Reply