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.
Yeah I ended up just giving them a weapon that was hidden, did no damage, had a 360 arc and produced no animation. Not ideal, but it actually works okay.
Hey guys, I have a problem and I don't have a clue how to fix it. Everyone knows that when you have a group of units where one or more of them are spellcasters (with no weapon) and you order the group to attack move somewhere, the non-caster units will fight and spellcasters run forward (past the fighting units and to the ordered point). In my game, the spellcasters are very important units and it is really inconvenient/non-intuitive to have to pull them back every time you issue an attack move order to the group. Is there anything I can do that will somehow make them not act suicidal and do this?
So I was able to fix this problem but I'm still not sure why it occured. The Explicit Rotation site op actor I was using was supposed to point the raven upwards, so it had forward and up vectors of (0,0,1). After I changed the up vector to make it tilt a little bit, there was no problem at all. So I don't really know what happened, must've been some bug or glitch that related to that certain set of circumstances. Thanks guys.
Intent: I'm trying to attach a raven to the back of a zealot. I have a ModelAddition actor with the raven model that attaches to a zealot when one is created and uses local offset and rotation site operations.
Problem: The raven attachment does something strange while the zealot is standing still. It's hard to explain. The raven glitches/jumps/rotates around the zealot, as if it was having trouble finding an attachment point. The attachment behaves perfectly as intended while the zealot is in motion.
What I've Tried: I tried changing both the raven and zealot models to different ones and got the same effect. I've tried 3 different attachment points and tried using triggers instead of data in order to attach it. No dice.
Related - At what point has anyone noticed performance problems with doodads? I suppose it also has to do with the amount of units and other things in the game, but how many doodads would be acceptable for a map that may have several hundred units on the map at any given time?
Thanks for responding. Basically, what I'm trying to figure out is how to set item descriptions based upon its roll.
For example, let's say I picked up an item with +3 Strength and +3 Vitality... how would I know that? There doesn't seem to be a way to modify item tooltips - like, the text that pops up when you hover over something.
Unfortunately data and triggers don't work very well together. So in your case you will need to create all of the possible items in data (with 3 stats all with possible values 0-3 that is 64 different items) with the appropriate tooltips and have the trigger be used only for deciding what drops. You'd create a global array of items called loot_table or something and set all of its values to a different item during map initialization. Then you can just say when unit dies, create item loot_table[random integer] at location of dying unit.
Edit: I'm confused, are you having trouble coming up with a way to determine random names or are you trying to figure out how to set an item's name in data via triggers? Either way, wrong forum, but if it's the former, then here is my solution:
local variable lethality_roll = (Random integer between 0 and 3)
local variable brilliance_roll = (Random integer between 0 and 3)
local variable vitality_roll = (Random integer between 0 and 3)
local variable item_name = "Badass Sword"
Unit - Add lethality_roll Hero - Lethality to (Triggering unit) from (Triggering unit)
Unit - Add brilliance_roll Hero - Lethality to (Triggering unit) from (Triggering unit)
Unit - Add vitality_roll Hero - Lethality to (Triggering unit) from (Triggering unit)
if lethality_roll == 3
set item_name = item_name + " of the Tiger"
else if brilliance_roll == 3
set item_name = item_name + " of the Eagle"
else if vitality_roll == 3
set item_name = item_name + " of the Bear"
Display text message for player "You picked up a " + item_name
You have to decide how to handle cases where you roll things like 3 lethality and 3 brilliance. you might choose to add more else-ifs i.e. else if lethality_roll == 3 and brilliance_roll == 3 then item_name = item_name + " of the Trout". You would then have to modify to others to say if lethality_roll == 3 and the others are less than 3 then set it to "of the Tiger." The more prefixes and suffixes you want to add the longer this else-if statement is going to get. In a real programming situation you would use a pre-determined hash that has all of the possible prefixes and suffixes instead of a massive else-if statement, but alas, we are working with triggers.
Look at the chain. For example if your spell is Ability->Apply Behavior Effect->Behavior->Validators then you probably want to copy it in the order of validators, then behaviors, then effects, then ability. Copy actors last. I think there are some situations (like if you have a cycle) where you'll have to end up re-linking some stuff regardless.
Nope, if you make the search fast enough (every 0.5 or .25 or even .125 seconds) you won't even be able to notice it. The only way to make them literally not be able to move near the unit is just increase its radius, but unfortunately this is permanent and cannot be changed with effects or behaviors so you will not be able to turn it off (to my knowledge).
Edit: I suppose there are some corner cases where this solution might not be favorable, for example if you think the unit will be moved instantly into groups of units or if units will be created near the unit then there will be a small amount of time that they will spend in the force field. I suggest trying it out and seeing how well it works. You can take the period all the way down to 0.0625 seconds or 1/16 of a second.
I would like to be an ability that i could turn ON and OFF ...
DrSuperEvil, i'll go check it now, and i'll tell you if it helps me :)
In that case you'll want to have it so when you turn on the ability it adds a behavior that does a periodic search effect. The search effect finds all units nearby and uses an apply force effect to apply a positive (I think positive is away? I don't remember I'm old and rusty) force to the unit to push them away. Make an actor that is created and destroyed when this behavior is turned on/off with the model of a force field.
Is this supposed to be an ability or just on the unit at all times? If its the latter then just modify the unit's radius to be larger than the unit. Make an actor that uses the model of the force field and attach it to the unit.
So I'm trying to implement this system where you can buy a limited amount of units from a gateway. So I want them to be able to train up to 20 zealots or 2 dark templar. (i.e. I want dark templar to cost 10x the number of charges that zealots cost). So to do this I made it so that these units share charges in the train ability. I set both of them to have 20 max and starting charges, but zealots use only 1 while dark templar use 10. This works fine. BUT in-game, the command card displays the number of charges left for each unit (which in this case is the same for both the zealot and dark templar since they share) instead of displaying the number of charges left divided by the amount that the unit uses.
In other words, functionally, everything works the way I want it to, but it's a little confusing because the command card implies that there are 20 dark templars you can build, when in reality you can only build 2 since they cost 10 charges each. It should display 20 on the zealot icon and a 2 on the dark templar icon to accurately reflect how many you can afford.
0
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 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.
0
@WaRadius: Go
Yeah I ended up just giving them a weapon that was hidden, did no damage, had a 360 arc and produced no animation. Not ideal, but it actually works okay.
0
Hey guys, I have a problem and I don't have a clue how to fix it. Everyone knows that when you have a group of units where one or more of them are spellcasters (with no weapon) and you order the group to attack move somewhere, the non-caster units will fight and spellcasters run forward (past the fighting units and to the ordered point). In my game, the spellcasters are very important units and it is really inconvenient/non-intuitive to have to pull them back every time you issue an attack move order to the group. Is there anything I can do that will somehow make them not act suicidal and do this?
0
@Bommes: Go
So I was able to fix this problem but I'm still not sure why it occured. The Explicit Rotation site op actor I was using was supposed to point the raven upwards, so it had forward and up vectors of (0,0,1). After I changed the up vector to make it tilt a little bit, there was no problem at all. So I don't really know what happened, must've been some bug or glitch that related to that certain set of circumstances. Thanks guys.
0
SOpAttachHardpoint (this has been changed to a few different ones), an explicit rotation and a local offset all on the attachment.
0
Intent: I'm trying to attach a raven to the back of a zealot. I have a ModelAddition actor with the raven model that attaches to a zealot when one is created and uses local offset and rotation site operations.
Problem: The raven attachment does something strange while the zealot is standing still. It's hard to explain. The raven glitches/jumps/rotates around the zealot, as if it was having trouble finding an attachment point. The attachment behaves perfectly as intended while the zealot is in motion.
What I've Tried: I tried changing both the raven and zealot models to different ones and got the same effect. I've tried 3 different attachment points and tried using triggers instead of data in order to attach it. No dice.
Has anyone run into this issue before?
0
Yes.
0
@Mozared: Go
Related - At what point has anyone noticed performance problems with doodads? I suppose it also has to do with the amount of units and other things in the game, but how many doodads would be acceptable for a map that may have several hundred units on the map at any given time?
0
Unfortunately data and triggers don't work very well together. So in your case you will need to create all of the possible items in data (with 3 stats all with possible values 0-3 that is 64 different items) with the appropriate tooltips and have the trigger be used only for deciding what drops. You'd create a global array of items called loot_table or something and set all of its values to a different item during map initialization. Then you can just say when unit dies, create item loot_table[random integer] at location of dying unit.
It's either that or live with generic tooltips.
0
@Pottfish: Go
Edit: I'm confused, are you having trouble coming up with a way to determine random names or are you trying to figure out how to set an item's name in data via triggers? Either way, wrong forum, but if it's the former, then here is my solution:
You have to decide how to handle cases where you roll things like 3 lethality and 3 brilliance. you might choose to add more else-ifs i.e. else if lethality_roll == 3 and brilliance_roll == 3 then item_name = item_name + " of the Trout". You would then have to modify to others to say if lethality_roll == 3 and the others are less than 3 then set it to "of the Tiger." The more prefixes and suffixes you want to add the longer this else-if statement is going to get. In a real programming situation you would use a pre-determined hash that has all of the possible prefixes and suffixes instead of a massive else-if statement, but alas, we are working with triggers.
0
@Kabelkorven: Go
Look at the chain. For example if your spell is Ability->Apply Behavior Effect->Behavior->Validators then you probably want to copy it in the order of validators, then behaviors, then effects, then ability. Copy actors last. I think there are some situations (like if you have a cycle) where you'll have to end up re-linking some stuff regardless.
0
@MacSC2: Go
Nope, if you make the search fast enough (every 0.5 or .25 or even .125 seconds) you won't even be able to notice it. The only way to make them literally not be able to move near the unit is just increase its radius, but unfortunately this is permanent and cannot be changed with effects or behaviors so you will not be able to turn it off (to my knowledge).
Edit: I suppose there are some corner cases where this solution might not be favorable, for example if you think the unit will be moved instantly into groups of units or if units will be created near the unit then there will be a small amount of time that they will spend in the force field. I suggest trying it out and seeing how well it works. You can take the period all the way down to 0.0625 seconds or 1/16 of a second.
0
In that case you'll want to have it so when you turn on the ability it adds a behavior that does a periodic search effect. The search effect finds all units nearby and uses an apply force effect to apply a positive (I think positive is away? I don't remember I'm old and rusty) force to the unit to push them away. Make an actor that is created and destroyed when this behavior is turned on/off with the model of a force field.
0
@MacSC2: Go
Is this supposed to be an ability or just on the unit at all times? If its the latter then just modify the unit's radius to be larger than the unit. Make an actor that uses the model of the force field and attach it to the unit.
0
So I'm trying to implement this system where you can buy a limited amount of units from a gateway. So I want them to be able to train up to 20 zealots or 2 dark templar. (i.e. I want dark templar to cost 10x the number of charges that zealots cost). So to do this I made it so that these units share charges in the train ability. I set both of them to have 20 max and starting charges, but zealots use only 1 while dark templar use 10. This works fine. BUT in-game, the command card displays the number of charges left for each unit (which in this case is the same for both the zealot and dark templar since they share) instead of displaying the number of charges left divided by the amount that the unit uses.
In other words, functionally, everything works the way I want it to, but it's a little confusing because the command card implies that there are 20 dark templars you can build, when in reality you can only build 2 since they cost 10 charges each. It should display 20 on the zealot icon and a 2 on the dark templar icon to accurately reflect how many you can afford.
Is there any work around for this?