Animations with start frame > 0 don't export properly.

[vladfi1]

I fixed this in my fork a while ago, but since then you've made a lot of (incompatible) changes. I will try to see what I can do.

[vladfi1]

I've worked around this issue by manually splitting the action into multiple actions in blender. The model seems to export fine, and I can view all of the animations in SC2's cutscene editor just fine. However, when I test the map, it crashes as soon as I make a unit with the model.

[flo]

Well the only tipp I can give you is to try to export the model with less stuff until it works. That way you can find the critical factor. e.g. you could try to export just 1 animation. Or try to export only 1 part of the mesh, or use only 1 material etc.

[vladfi1]

Well this is downright strange. I can export a model with no animations or even attachment points, just the mesh and materials, and it will crash SC2 iff the following condition holds: the unit that's using the model has &lt:AbilArray Link="attack"/&gt: (those are supposed to be angle brackets) in it's xml definition in the Data Editor. This only holds for models I export with the latest version of the m3addon. Models that I export with my fork (from November or so) worked fine. Unfortunately this bit of xml is what allows my units to actually attack... note that if I exclude this line, all of the other animations (Stand, Walk, Death) play just fine.

[flo]

Could you try to find the commit which broke the export? That would really help. e.g. say it version 10 works and 20 doesn't then you could try version 15. If it works then you know the bug got introduced betweeen 15 and 20 then you would try for example version 17. That way you can find the commit at fault with only a handful of tries.

[vladfi1]

Which was the earliest version compatible with blender 1.67?

[vladfi1]

One issue I'm facing is that the m3addon won't allow me to export the model if it has missing materials, but my script that fixes the textures only works with the latest few commits.

[vladfi1]

It appears that 1ce7482b44ea3b2e245c3f06e672c48e61e87146 is the earliest commit that I can test, and it crashes SC2. It won't be too hard to modify my script to work with older commits, though (I manually create m3 materials and assign them the correct textures, and in that commit the way you create m3 materials changes).

[flo]

Since you can test older one verisons, could you find out which one introduces the bug? Since c2753ebc911dd8e157d140ac5f810bb327d2102b Blender 2.66+ is requried.

[vladfi1]

I suppose I can't use blender 2.67 for the older commits?

[flo]

No, but you can get Blender 2.65 and older at: http://download.blender.org/release/

[vladfi1]

Ok so the issue is not with the models at all. If I substitute one of the new models (made with the latest m3addon) for one old models, it works fine. The problem has to do with what I'm doing in the data editor (I guess there's something wrong with my new units, even though they should be identical to the old units up to the model file used).

[vladfi1]

By the way, I've figured out that the issue was using a "default" attack; that is, an attack with default="1" in it's xml. This also solves an old issue with a model that I had that I never figured out.