I know the problem with the missile launching from the ground beneath the Banshee is related to the Actor for the missile. I think you need to set it to launch from a certain point on the Banshee Actor's model, but I can't remember exactly what field this is called or which value to use; I just know I've had this problem in the past and that was how I fixed it.
The second one should be simpler: enable the "Transient" flag for the missile launch ability and the Banshee will be able to use it without interrupting its existing orders.
You can just duplicate the Immortal's buff and that should work fine most of the time; just adjust the maximum damage cap to whatever 10% of your unit's HP is. It only gets screwy if the unit with the buff can somehow gain or lose HP from its normal starting amount. If you do that with an upgrade, you may be able to also upgrade the buff to change the max damage cap to 10% of whatever the new value is. So if your unit starts off with 100 HP and the buff reduces all damage to 10 at most, but you then upgrade to increase HP to 150, you could also upgrade the buff to reduce all damage to 15 at most instead.
I'm not 100% positive this will work, though; I believe there are only certain types of values that upgrades can modify and I'm not sure if the maximum damage cap for a buff like this is one of them. It also won't work if the unit's health changes more dynamically than that, or through means other than upgrades.
For anyone curious, I think I managed to get this to work. And I wound up using the first method rather than the second, but with an added workaround.
Instead of the player ordering the Dropship to attack a friendly target, the player can't order it to attack at all. Just scan-move like with any other unarmed unit. However, the Dropship has an autocast Effect - Instant ability that it will use whenever enemies are near, or can be ordered to use manually. This ability uses an Issue Order effect to make the Dropship attack itself. I had to create a custom Attack ability and weapon for the Dropship, such that the only valid target is itself. Once it begins attacking itself, it continues to do so until ordered to stop or move by the player, and so long as it keeps attacking it will keep deploying magazine units as they're trained.
Obviously this solution can't be used anytime you want a unit to both deploy magazine units in this fashion and fire a conventional weapon, but in that case they'll be launching anyway so long as you're attacking.
I'm not sure if I'm doing something wrong or if this is going wrong in the editor/game, but when I try to add the Swarm Campaign dependency to a map and then attempt to use units from it in testing, they're broken. For instance, I placed the Hyperion unit from that one space mission on the map, but none of its voice files are working and the "Fighter Strike" ability is broken; it doesn't launch any fighters and just deducts 1 charge when I use it. The same thing happens if I place other campaign-specific units... but if I place regular units they seem to work just fine.
I'm experimenting with magazine-built and -launched units on my map project. At the moment, I'm making it so that instead of training units, loading them into a dropship, flying the dropship to another "planet" and then unloading the units, the Dropship itself serves as a "carrier". It trains the units, stores them inside itself, and when it's above a "planet" it can launch them to attack ground targets. Then it reloads them and flies off to another planet.
At first I set them up to work exactly like Carriers, and it worked alright. But as I ran more test fights, I noticed that the deployed units weren't fighting that effectively because they always attacked a single unit at a time... the one the Dropship's own weapon was targeting. I'm aware that this is a hardcoded behavior inherent to magazine-managed units, so I started looking for ways around it. I've found two so far, but they're not optimal for various reasons.
The first and easiest way is for the mothership unit to attack something that the magazine unit's own weapon is unable to target. If your mothership's weapon can target an air unit, but the magazine units can only attack ground units, then they won't be slaves to the mothership's attack target and are free to engage like any normal unit would. However, it does still require that the mothership unit be in the process of attacking something, and if you want to have them perform adequately without excessive micro-management they need to be able to attack the same kind of object their magazine units are effective against.
The alternative that I'm currently investigating holds more promise, I think. In the Ability : Info+ section of the Arm Magazine ability, where you can set the values for the units that it trains, there's one entry down at the bottom that says Info - Manage. This can be set to Destroy, Recall or Ignore, and it seems to govern what the magazine units do when the mothership is not attacking. Recall is the one that the Protoss Carrier uses, and is the expected behavior: when the mothership stops attacking, the magazine units stop attacking as well and return to the mothership to be stored inside it again. Destroy will kill all deployed magazine units when the mothership stops attacking. Ignore seems the most useful one here, because it does nothing. When there are magazine units deployed and the motherhship stops attacking, Ignore makes the magazine units keep doing what they're doing. It's the most direct way to get them to behave like normal units again.
I've been able to couple this with an Effect - Instant ability that runs a Use Magazine effect, and it works pretty smoothly: the dropship is able to deploy its units without needing to attack, and the deployed units are free to move around and attack normally without all being forced to go after the same target. The problem, however, comes when it's time to get them back into the dropship afterward. Without Recall being enabled there doesn't seem to be any way to achieve this. Even a "Return Magazine" effect, which would seem to be the most logical option, doesn't get them back in. It just orders them to move to the mothership unit's position, but then they just sit there beneath it. If I re-enable "Recall", I can use this to pull them back in, but I'd be able to do that anyway just by telling the dropship to stop attacking for a moment, and if the dropship isn't attacking they get sucked back in the instant they launch.
I've also found that if Info - Manage is set to Ignore and the Retarget flag is not enabled, then the Arm Magazine will let go of the magazine units entirely when they're launched; they'll no longer count as part of the mothership's magazine and it will be free to train new ones. This has some potential, because it would let you build a troop-training facility that could be told to autocast and thus produce a given unit type indefinitely, but that's neither here nor there.
I suppose if I wanted to be really kludgy with it I could give the Dropship a conventional cargo bay and let it re-load its deployed units into that for later use, but I'd rather find a more elegant solution to this problem.
Nevermind; fiddled around with it some more, setting the Target Effect of the Issue Order effect to the Persistent and the Target Value to Target Unit/Point got it working.
I'm trying to create a "Nav Beacon" unit, which can be configured to issue a variety of orders to other units near it, allowing the player to create a network of units all consistently carrying out the same orders. For example, a dropship that hangs around an area, loads units that come into that area, transports them to another area and unloads them there, then returns to the starting point and repeats.
In order to achieve this, I'm giving the Nav Beacon a few different Effect - Target abilities, each of which creates a Persistent effect at the target point. Every time the persistent effect runs its periodic effect, it searches the area around its caster Nav Beacon and orders any units it finds to execute different orders, with the target of those orders set to the persistent effect.
However, the units don't seem to be able to find the persistent right. When issued a Move order, they start moving all the way to the bottom-left corner of the map, regardless of where the persistent should be. When issued an order to use a Teleport ability, on the other hand, they just sit there. Those are the two I've tested so far, and I'd like to get this figured out before I keep going.
The Issue Order effects have their Target fields set with the Persistent in the Effect field, and Unknown in the Value field (anything else seems to make them move back toward the Nav Beacon).
I'm gonna have to leave soon, so I'm gonna leave you instructions on what to do either way.
If you save as .sc2map, you will have to get an MPQEditor and extract your files.
After that's done, you want to go into your newly extracted files.
Go into the folder Base.SC2Data
Go into the folder GameData
Look for abnormally sized files (They shouldn't be anymore than a few kb)
So, for example, ActorData.xml should not be 65 megabytes, then.
Quote:
If you find anything abnormally sized, open that file using Notepad (I recommend Notepad+ +). Look to see anything fishy - everything should be nicely structured. Delete things as necessary.
...wow. Okay, wasn't too hard to find what was wrong: line after line after line filled with nothing but "Invalid Link" over and over again. So much junk data that both Notepad and Wordpad couldn't handle it. Wound up having to open the file with OpenOffice, and there were literally over 9,000 pages of nothing but "Invalid ink". About 9,500, in fact, only 120 of which were left after I finally managed to delete the junk data.
Quote:
Make sure to save all these files properly into a folder, that way SC2 will pick it up. Try to open.
Success! The Editor opens the map, and the game can test-run that map.
However, when I try to go and save it as a single SC2Map file, I get the following error messages:
Do I need to fix anything because of this? I'm fine to just keep working with it in component form, but I'm not sure if whatever is causing this will produce other problems down the road. Like if I try to publish it, for example.
Edit: Okay, NOW it's telling me that it can't save the map file when I go to test it, so something is definitely wrong. :(
Last night, the SC2 Editor seems to have stopped being able to load the map I've been working on for a year or two now. When I go to start up the Editor (I have it set to load that map first thing), or when I load a different map and switch to it, it gets as far as "Loading Actor Data", at which point it just stops. The elapsed loading time stops ticking up, and I wind up having to force Windows to close the program.
I tried my backup saves, but the first one gets the same problem, and apparently my backup saving hasn't been doing multiple saves like it should; backups 2 - 5 are months out of date.
Is there any way to recover my map? Or am I going to have to reconstruct it entirely? :(
2. MenuBar doesn't reapply its template after creation. Only dynamically created things seem to do that. The buttons are where the template was applied to... in your case in "GameUI/UIContainer/FullscreenUpperContainer/MenuBar"
So I do not, in fact, need everything above <Frame type="MenuBar" name="MenuBarTemplate">, as I guessed?
Quote:
3. Names need to include the whole path of the existing file. You need to specify the modified layout file, too: "GameUI".
I hope it became some more clear to you. It's not easy and I would advise you to relook at Helral's tutorial with aiur chef's overriding method (which can be or maybe must be applied in the UI editor).
Ahh, this looks like the critical part.
I think I've trimmed it down to what I need... how's this?
I know that for people who have experience working with the UI this is probably going to seem like a stupid question, but it's baffling me. I've looked over tutorials and stuff, but I'm still not sure what I've screwed up and how.
I've got a map where I'm using all four custom resources and want them displayed for the players: Minerals, Vespene, Terrazine and Custom (the last two have, of course, been renamed). I was able to accomplish this easily, but having all four of them visible has pushed Minerals so far to the left that it's hidden behind the "Help" button, and it's difficult to see how much you have.
I figured that I could just remove the "Help" button, since the glossary in it gets messed-up easily and right now it's totally out-of-whack. After some investigation I figured out that the MenuBar layout was the one I needed to modify, so I copy-pasted the text of that into a new layout file, which I named MenuBarOverride. The Help button was right at the very bottom and nothing else was dependent on it, so I figured I could remove it easily and just have my file override the normal one. The end result looked like this:
I went into the Default UI Settings file in the Data Editor, pointed the Custom Layout Files field to MenuBarOverride, and went to test the map to see if it worked. The Help button was still there, and the game gave me the following error message:
"UI: File[MenuBarOverride.SC2Layout] Line [2] Column [1]. Attempting to add a desc named [MenuBarOverride] to [] with the same name as an already existing child."
I have no idea what that means, or how to fix it. :(
At first I thought I didn't need all that extra stuff up top, about the button format, so I tried trimming it down to this:
Yeah, Starcraft 2 isn't really set up to do realistic unit scale or ranges that well. One of the only RTS games I've ever seen to attempt that was Supreme Commander, and in that even the tiniest units are the size of houses. And the only way it worked was that the game let you zoom seamlessly from close-up all the way out to viewing the entire map, which Starcraft isn't configured for.
I've attempted to get something vaguely resembling realistic scale in the map I've been working on, but even it's not that close and it's stretching the limits of what the engine can handle. Infantry units are around 1/4th to 1/5th their normal size and vehicles are around 3/8th (which seems to scale them well with each other, as you can now imagine the guy inside Marine armor actually fitting inside a Siege Tank), while Battlecruisers are 50% bigger than normal. But weapon ranges are still hilariously short by comparison, and there's not much I can do to change that without getting much bigger maps.
I hadn't worked on my map for awhile, and while idly updating SC2 to 1.5 and reading over the release notes for all the changes I got inspired to tinker with it again. In a few cases, some animations or models were broken by the update, but I was able to fix them... except for one.
I had previously taken the Terran Biodome doodad/structure seen in the singleplayer campaign and turned it into a buildable structure, complete with build animation. Since it didn't have a built-in build model, I created one using a couple still models of the doodad in various stages of construction. Prior to the update, it worked quite nicely: during Placement the structure would use one model, then once construction had started it would use a half-finished model while the build animation used for smaller Terran buildings played, just scaled up appropriately (since the model was circular). At the conclusion of construction it would use the final model, complete with variants.
After the 1.5 update, it worked for the first few test-runs of the map, but then I think I looked at the Actor funny or breathed too hard or something, and it stopped working. It still uses the right Placement model, and the finished structure still looks right, but during construction it has no model whatsoever. Not even the little blank sphere that SC2 uses as a placeholder.
I've looked over it repeatedly and I'm stumped. The build model is listed on the unit's actor, and its Events tell it to Create that model when it begins construction, etc. I've just got no idea what I'm missing.
Any suggestions out there? Anybody else get a unit similarly broken by the update, then fixed? And if so, how?
Are the units that are not showing death animations duplicates, including their actors and models? If so, you may want to double-check the "Death Model" of the unit's actor. That's where it points to which model to use when it dies.
0
I know the problem with the missile launching from the ground beneath the Banshee is related to the Actor for the missile. I think you need to set it to launch from a certain point on the Banshee Actor's model, but I can't remember exactly what field this is called or which value to use; I just know I've had this problem in the past and that was how I fixed it.
The second one should be simpler: enable the "Transient" flag for the missile launch ability and the Banshee will be able to use it without interrupting its existing orders.
0
You can just duplicate the Immortal's buff and that should work fine most of the time; just adjust the maximum damage cap to whatever 10% of your unit's HP is. It only gets screwy if the unit with the buff can somehow gain or lose HP from its normal starting amount. If you do that with an upgrade, you may be able to also upgrade the buff to change the max damage cap to 10% of whatever the new value is. So if your unit starts off with 100 HP and the buff reduces all damage to 10 at most, but you then upgrade to increase HP to 150, you could also upgrade the buff to reduce all damage to 15 at most instead.
I'm not 100% positive this will work, though; I believe there are only certain types of values that upgrades can modify and I'm not sure if the maximum damage cap for a buff like this is one of them. It also won't work if the unit's health changes more dynamically than that, or through means other than upgrades.
0
For anyone curious, I think I managed to get this to work. And I wound up using the first method rather than the second, but with an added workaround.
Instead of the player ordering the Dropship to attack a friendly target, the player can't order it to attack at all. Just scan-move like with any other unarmed unit. However, the Dropship has an autocast Effect - Instant ability that it will use whenever enemies are near, or can be ordered to use manually. This ability uses an Issue Order effect to make the Dropship attack itself. I had to create a custom Attack ability and weapon for the Dropship, such that the only valid target is itself. Once it begins attacking itself, it continues to do so until ordered to stop or move by the player, and so long as it keeps attacking it will keep deploying magazine units as they're trained.
Obviously this solution can't be used anytime you want a unit to both deploy magazine units in this fashion and fire a conventional weapon, but in that case they'll be launching anyway so long as you're attacking.
0
I'm not sure if I'm doing something wrong or if this is going wrong in the editor/game, but when I try to add the Swarm Campaign dependency to a map and then attempt to use units from it in testing, they're broken. For instance, I placed the Hyperion unit from that one space mission on the map, but none of its voice files are working and the "Fighter Strike" ability is broken; it doesn't launch any fighters and just deducts 1 charge when I use it. The same thing happens if I place other campaign-specific units... but if I place regular units they seem to work just fine.
0
I'm experimenting with magazine-built and -launched units on my map project. At the moment, I'm making it so that instead of training units, loading them into a dropship, flying the dropship to another "planet" and then unloading the units, the Dropship itself serves as a "carrier". It trains the units, stores them inside itself, and when it's above a "planet" it can launch them to attack ground targets. Then it reloads them and flies off to another planet.
At first I set them up to work exactly like Carriers, and it worked alright. But as I ran more test fights, I noticed that the deployed units weren't fighting that effectively because they always attacked a single unit at a time... the one the Dropship's own weapon was targeting. I'm aware that this is a hardcoded behavior inherent to magazine-managed units, so I started looking for ways around it. I've found two so far, but they're not optimal for various reasons.
The first and easiest way is for the mothership unit to attack something that the magazine unit's own weapon is unable to target. If your mothership's weapon can target an air unit, but the magazine units can only attack ground units, then they won't be slaves to the mothership's attack target and are free to engage like any normal unit would. However, it does still require that the mothership unit be in the process of attacking something, and if you want to have them perform adequately without excessive micro-management they need to be able to attack the same kind of object their magazine units are effective against.
The alternative that I'm currently investigating holds more promise, I think. In the Ability : Info+ section of the Arm Magazine ability, where you can set the values for the units that it trains, there's one entry down at the bottom that says Info - Manage. This can be set to Destroy, Recall or Ignore, and it seems to govern what the magazine units do when the mothership is not attacking. Recall is the one that the Protoss Carrier uses, and is the expected behavior: when the mothership stops attacking, the magazine units stop attacking as well and return to the mothership to be stored inside it again. Destroy will kill all deployed magazine units when the mothership stops attacking. Ignore seems the most useful one here, because it does nothing. When there are magazine units deployed and the motherhship stops attacking, Ignore makes the magazine units keep doing what they're doing. It's the most direct way to get them to behave like normal units again.
I've been able to couple this with an Effect - Instant ability that runs a Use Magazine effect, and it works pretty smoothly: the dropship is able to deploy its units without needing to attack, and the deployed units are free to move around and attack normally without all being forced to go after the same target. The problem, however, comes when it's time to get them back into the dropship afterward. Without Recall being enabled there doesn't seem to be any way to achieve this. Even a "Return Magazine" effect, which would seem to be the most logical option, doesn't get them back in. It just orders them to move to the mothership unit's position, but then they just sit there beneath it. If I re-enable "Recall", I can use this to pull them back in, but I'd be able to do that anyway just by telling the dropship to stop attacking for a moment, and if the dropship isn't attacking they get sucked back in the instant they launch.
I've also found that if Info - Manage is set to Ignore and the Retarget flag is not enabled, then the Arm Magazine will let go of the magazine units entirely when they're launched; they'll no longer count as part of the mothership's magazine and it will be free to train new ones. This has some potential, because it would let you build a troop-training facility that could be told to autocast and thus produce a given unit type indefinitely, but that's neither here nor there.
I suppose if I wanted to be really kludgy with it I could give the Dropship a conventional cargo bay and let it re-load its deployed units into that for later use, but I'd rather find a more elegant solution to this problem.
0
@JimStarluck: Go
Nevermind; fiddled around with it some more, setting the Target Effect of the Issue Order effect to the Persistent and the Target Value to Target Unit/Point got it working.
0
I'm trying to create a "Nav Beacon" unit, which can be configured to issue a variety of orders to other units near it, allowing the player to create a network of units all consistently carrying out the same orders. For example, a dropship that hangs around an area, loads units that come into that area, transports them to another area and unloads them there, then returns to the starting point and repeats.
In order to achieve this, I'm giving the Nav Beacon a few different Effect - Target abilities, each of which creates a Persistent effect at the target point. Every time the persistent effect runs its periodic effect, it searches the area around its caster Nav Beacon and orders any units it finds to execute different orders, with the target of those orders set to the persistent effect.
However, the units don't seem to be able to find the persistent right. When issued a Move order, they start moving all the way to the bottom-left corner of the map, regardless of where the persistent should be. When issued an order to use a Teleport ability, on the other hand, they just sit there. Those are the two I've tested so far, and I'd like to get this figured out before I keep going.
The Issue Order effects have their Target fields set with the Persistent in the Effect field, and Unknown in the Value field (anything else seems to make them move back toward the Nav Beacon).
0
So, for example, ActorData.xml should not be 65 megabytes, then.
...wow. Okay, wasn't too hard to find what was wrong: line after line after line filled with nothing but "Invalid Link" over and over again. So much junk data that both Notepad and Wordpad couldn't handle it. Wound up having to open the file with OpenOffice, and there were literally over 9,000 pages of nothing but "Invalid ink". About 9,500, in fact, only 120 of which were left after I finally managed to delete the junk data.
Success! The Editor opens the map, and the game can test-run that map.
However, when I try to go and save it as a single SC2Map file, I get the following error messages:
Unable to compute archive checksum (An unexpected fatal error occurred.): C:\Users\James Starluck\Documents\Starcraft Map Project\Project One.SC2Map Unable to compute archive checksum (An unexpected fatal error occurred.): C:\Users\James Starluck\Documents\Starcraft Map Project\Project One.SC2Map Unable to save archive header (An unexpected fatal error occurred.): C:\Users\James Starluck\Documents\Starcraft Map Project\Project One.SC2Map
Do I need to fix anything because of this? I'm fine to just keep working with it in component form, but I'm not sure if whatever is causing this will produce other problems down the road. Like if I try to publish it, for example.
Edit: Okay, NOW it's telling me that it can't save the map file when I go to test it, so something is definitely wrong. :(
0
I don't think so. I have both the multiplayer and campaign dependencies, but those shouldn't require loading through Battle.net, should they?
0
Last night, the SC2 Editor seems to have stopped being able to load the map I've been working on for a year or two now. When I go to start up the Editor (I have it set to load that map first thing), or when I load a different map and switch to it, it gets as far as "Loading Actor Data", at which point it just stops. The elapsed loading time stops ticking up, and I wind up having to force Windows to close the program.
I tried my backup saves, but the first one gets the same problem, and apparently my backup saving hasn't been doing multiple saves like it should; backups 2 - 5 are months out of date.
Is there any way to recover my map? Or am I going to have to reconstruct it entirely? :(
0
I figured. :P
So I do not, in fact, need everything above <Frame type="MenuBar" name="MenuBarTemplate">, as I guessed?
Ahh, this looks like the critical part.
I think I've trimmed it down to what I need... how's this?
0
I know that for people who have experience working with the UI this is probably going to seem like a stupid question, but it's baffling me. I've looked over tutorials and stuff, but I'm still not sure what I've screwed up and how.
I've got a map where I'm using all four custom resources and want them displayed for the players: Minerals, Vespene, Terrazine and Custom (the last two have, of course, been renamed). I was able to accomplish this easily, but having all four of them visible has pushed Minerals so far to the left that it's hidden behind the "Help" button, and it's difficult to see how much you have.
I figured that I could just remove the "Help" button, since the glossary in it gets messed-up easily and right now it's totally out-of-whack. After some investigation I figured out that the MenuBar layout was the one I needed to modify, so I copy-pasted the text of that into a new layout file, which I named MenuBarOverride. The Help button was right at the very bottom and nothing else was dependent on it, so I figured I could remove it easily and just have my file override the normal one. The end result looked like this:
I went into the Default UI Settings file in the Data Editor, pointed the Custom Layout Files field to MenuBarOverride, and went to test the map to see if it worked. The Help button was still there, and the game gave me the following error message:
"UI: File[MenuBarOverride.SC2Layout] Line [2] Column [1]. Attempting to add a desc named [MenuBarOverride] to [] with the same name as an already existing child."
I have no idea what that means, or how to fix it. :(
At first I thought I didn't need all that extra stuff up top, about the button format, so I tried trimming it down to this:
But it just gives me the same error message.
I'm certain that it's something simple and stupid, but I just don't get it. :(
0
Yeah, Starcraft 2 isn't really set up to do realistic unit scale or ranges that well. One of the only RTS games I've ever seen to attempt that was Supreme Commander, and in that even the tiniest units are the size of houses. And the only way it worked was that the game let you zoom seamlessly from close-up all the way out to viewing the entire map, which Starcraft isn't configured for.
I've attempted to get something vaguely resembling realistic scale in the map I've been working on, but even it's not that close and it's stretching the limits of what the engine can handle. Infantry units are around 1/4th to 1/5th their normal size and vehicles are around 3/8th (which seems to scale them well with each other, as you can now imagine the guy inside Marine armor actually fitting inside a Siege Tank), while Battlecruisers are 50% bigger than normal. But weapon ranges are still hilariously short by comparison, and there's not much I can do to change that without getting much bigger maps.
0
I hadn't worked on my map for awhile, and while idly updating SC2 to 1.5 and reading over the release notes for all the changes I got inspired to tinker with it again. In a few cases, some animations or models were broken by the update, but I was able to fix them... except for one.
I had previously taken the Terran Biodome doodad/structure seen in the singleplayer campaign and turned it into a buildable structure, complete with build animation. Since it didn't have a built-in build model, I created one using a couple still models of the doodad in various stages of construction. Prior to the update, it worked quite nicely: during Placement the structure would use one model, then once construction had started it would use a half-finished model while the build animation used for smaller Terran buildings played, just scaled up appropriately (since the model was circular). At the conclusion of construction it would use the final model, complete with variants.
After the 1.5 update, it worked for the first few test-runs of the map, but then I think I looked at the Actor funny or breathed too hard or something, and it stopped working. It still uses the right Placement model, and the finished structure still looks right, but during construction it has no model whatsoever. Not even the little blank sphere that SC2 uses as a placeholder.
I've looked over it repeatedly and I'm stumped. The build model is listed on the unit's actor, and its Events tell it to Create that model when it begins construction, etc. I've just got no idea what I'm missing.
Any suggestions out there? Anybody else get a unit similarly broken by the update, then fixed? And if so, how?
0
Are the units that are not showing death animations duplicates, including their actors and models? If so, you may want to double-check the "Death Model" of the unit's actor. That's where it points to which model to use when it dies.