SC2Mapster

So with the 1.5 update I noticed a few problems that started up with my actors. Actually, all of the issues have been centralized on one actor of mine that is based on the preserver.

• I used TextureSelectById to remove the glow from the model before 1.5, but now its back with the error message of "no mapping for slot body.diffuse" body.diffuse is the name I gave to the EnergyPlane3.dds texture (replicated from Kueken's Tassadar glow guide, wish I could tag him here). I looked over everything briefly and didn't find any new glaring issues, but I'm not very good at model and texture manipulation anyway so I'm pretty clueless as to what the problem could be.

• On the same actor I had a ModelAddition that attaches itself to the Weapon Right of the model. It still attaches, but now when the preserver's arm moves the attachment no longer moves with it, just sits there totally static. It still moves around with the unit and such just not with the arm. Strange. Edit:Looks like it attaches properly while the unit is in motion but does not while the unit is idle. 2ndEdit:Seems to be some sort of problem with my Site Operation actors. When I remove my Explicit Rotation and Local Offset operations it works fine (but obviously is not in the correct position/direction).

• The attack animation for this actor no longer works. He just sits there turning in place when he attacks, despite the fact that I have actor events that play the attack animation on weapon start and clear it on weapon stop. Edit: Fixed. As Ahli mentioned, there was a conflict with other animations being played after the same event, not sure why this didn't show up before 1.5.

I will continue to look into these issues and post back if I find any solutions. Feel free to add any issues you've encountered with actors after the patch as well as any solutions you have found.

I had the last one during the beta when I had an animation play message, with an non-existing animation in that model, executed before that. So you better check all the events of the bugged actors and delete the ones you don't need.

So #3 was solved, I'm still clueless about #1, and I still can't get #2 to work properly:

I tried renaming and recreating all the actors and that didn't fix it. Apparently if my attachment actor uses any Local Offset or Explicit Rotation site ops, it breaks. I tried coming at it from a different angle by using the new Attach actor message on the unit actor, but that didn't work either. No matter how I changed that message it kept giving the error "cannot resolve actor by ref name 'blank'" where blank is the name of my attachment actor. So I'm still pretty confused about this one.

@peranzormal: Go

The first was mentioned in a couple of threads already. You have to use a prefix for texture select to work now.

2 used to happen a lot with imported WoW models pre-patch, now it happens for a lot of other stuff as well -.- Previously, a solution would be to use a different model without these issues, a Marine was working for pretty much anything (attach stuff to invisible marines attached to the point), but thats obviously a little tedious.

The new Attach message can be used like this:

• Add a new actor, type Model, based on ModelAnimationStyleContinuous (or whatever suits your needs)
  
• Add a new event to that, reacting to the birth of your unit: UnitBirth.x -> Create
  
• Add a new event to the unit (!) actor (or to the attachment, targeting the unit actor): ActorCreation -> AttachOffset
  
• Pick the newly created actor in the Actor field, pick the attachment point at the Attach Methods (you might want to use Direct)
  
• Pick a local offset and rotation to your liking. Offset should be obvious, rotation needs to be in format "x,y,z a,b,c" (without the "") while xyz is the forward vector and abc is the up vector.
  
• Add any site operation you like (or none), but some of them might mess up the previously defined offsets and rotations.

Quote from TheAlmaity: Go

@peranzormal: Go

The first was mentioned in a couple of threads already. You have to use a prefix for texture select to work now.

The prefix of the Texture or under Texture Declarations - Prefix of the Model? And what would it be if the texture has no prefix, such as how Tassadar has EnergyPlane3.dds with no Tassadar_ in front of it?

Quote from Kueken531: Go

2 used to happen a lot with imported WoW models pre-patch, now it happens for a lot of other stuff as well -.- Previously, a solution would be to use a different model without these issues, a Marine was working for pretty much anything (attach stuff to invisible marines attached to the point), but thats obviously a little tedious.

The new Attach message can be used like this: Add a new actor, type Model, based on ModelAnimationStyleContinuous (or whatever suits your needs)

Add a new event to that, reacting to the birth of your unit: UnitBirth.x -> Create

Add a new event to the unit (!) actor (or to the attachment, targeting the unit actor): ActorCreation -> AttachOffset

Pick the newly created actor in the Actor field, pick the attachment point at the Attach Methods (you might want to use Direct)

Pick a local offset and rotation to your liking. Offset should be obvious, rotation needs to be in format "x,y,z a,b,c" (without the "") while xyz is the forward vector and abc is the up vector.

Add any site operation you like (or none), but some of them might mess up the previously defined offsets and rotations.

Thanks. I was able to get it working with that AttachModelOffset message. Still a big question mark as to why the problem arose in the first place though.

Quote from peranzormal: Go

The prefix of the Texture or under Texture Declarations - Prefix of the Model? And what would it be if the texture has no prefix, such as how Tassadar has EnergyPlane3.dds with no Tassadar_ in front of it?

The Texture Declaration prefix. And it is not required to follow any naming conventions, for your example you can use the prefix "E" or "Energy" or the entire file name and still use the entire file name as a substring.

The downside is, that you can only use one prefix per declaration, so if you use multiple adaptions with incompatible file names for a prefix (aka first letter is different), you need to split up to multiple declarations. This might be an issue, because there seems to be some limit on declarations, at least for me pre-patch the texture swapping stopped working at some point, when adding too many declarations.

€ fortunately, that seems to be not the case anymore.

@Kueken531: Go I have a related problem with TextureSelectById. I always used prefixes and it worked fine. Now I'm trying to replace the Spectre's diffuse texture using the same method but I get the following message:

CActorUnit[Shadowguard] Spectre Assets\Units\Terran\Spectre\Spectre.m3; Could not find texture with id Shadowguard_Diffuse and expression <None>.

Could it be because the modle uses the diffuse texture for both diffuse and specular slots? What should go in the new texture's prefix? The same prefix from the model or the prefix of the custom texture's name?

If you used a prefix and it worked before, it should still work. Would you mind attaching an example map?

@Kueken531: Go Sorry, I can't attach an example map, map is too big and lots of dependencies. I tested other models that use the exact same method and they work. This is the only one giving me trouble, the oe I added after 1.5.

OK, VERY STUPID MISTAKE. This one was the only texture I didn't use capital letters in the name, and the game doesn't recognize shadowguard_diffuse as Shadowguard_Diffuse because the suffixes don't match. Well, now it's fixed :-)

it seems that whenever i change/add events in an event macro actor and try to save those changes, the editor crashes :( I'd post this issue on that Blizzard forum but it wont let me due to the website detecting parental controls that were never set!

Quote from DrSuperEvil: Go

With regards to SOps giving problems, I have experienced this and even had marines not updating their position when attached to other marines.

Noo, they broke my multi-purpose weapon. Noticed this as well, however, I was able to fix most issues coming up with this so far by changing the order of the attachments and site operations.

Quote:

Also had attached model actors defaulting back to the unit actor when applying a +1 z offset.

I had these issues especially when combining the new attachment actor messages with site operations. Some site operations reset the changes applied by the actor message and vice-versa.

Quote:

Finally just had actors refusing to show for no reason. Wish I knew the cause.

Didn't have that issue yet.

Quote from KingRadical: Go

it seems that whenever i change/add events in an event macro actor and try to save those changes, the editor crashes :( I'd post this issue on that Blizzard forum but it wont let me due to the website detecting parental controls that were never set!

I used to have this issue pre-1.5, then tried it in the beta, and it didn't crash anymore, so I assumed, it got fixed. But now it crashes again :/