In most cases you can easily change the launch point without creating a site actor by changing the Combat: Launch Attachment Query+ in the weapon's Action actor. For example, get rid of AMFilterWeaponSetA1 and AMRandomUniform and change it to Filter Weapon, and it'll just look for a Weapon point. You can also remove all of them and use the fallback point.
Then go back to detailed view and right-click Event: Remove + and select "Apply value to children." This should make it so all standard terran buildings no longer flatten terrain. (Because of issues of inheritance, it might be helpful to close the map and reopen it to get it to show properly on child actors.) Something similar can be done with Zerg buildings and probably Protoss ones too.
Yeah definitely looks like a bug in SC2 itself, not your map. The control group triggers are pretty buggy in general. I've run into some ridiculous stuff there myself. The best you can do is a trigger workaround that re-adds the units, but I won't be surprised if you discover other bugs in the process.
Np. It's pretty annoying when that kind of thing happens. I've run into it a few times, e.g. when triggers refer to items being sold. I don't know about the most recent updates, but at one time when I wanted to add a trigger response to item selling, I had to make a trigger that recorded when a unit was ordered to sell an item, and then another that actually fired when the item was sold. Only the first one could tell which item was sold, but only the second trigger knew whether the item was actually sold, and not just ordered to be sold.
You can make a sound loopable by setting Loop Count to -1 in the Sound data. Then use SoundContinuous actor as the parent of the sound actor, or even SoundEmitter, which is essentially what you are creating--a continuous sound attached to another actor.
Interesting. I've heard others complain about this bug so it must be commonplace despite being caused by triggers. Are you saying that loaded units are removed from control groups into which triggers add other units? Or does simply calling the Add unit to control group action on ANY control group cause all control groups to forget their loaded units?
My thought is that the internal code for adding a unit to a control group probably collects the current control group's non-hidden units as a unit group, adds the new unit to the unit group, and then saves the unit group as the control group.
The unit is being removed before the triggers have time to find it. Test this by removing the Pickup Remove effect from the Pickup (Set).
Two options: (A) Add a delay between the effects. Instead of Pickup (Set), make it an Apply Behavior that adds a behavior to the Caster from the unit picking up the pickup, and this behavior has a duration of 0.5 seconds. Triggers detect this effect and can glean both the pickup and the picking up unit. The behavior disables the Pickup behavior, and destroys the pickup when it expires.
(B) (my preferred method) make a unique pickup behavior for each kind of pickup, which allows triggers to differentiate them. In this case, Pickup (Set) should refer to a unique effect for this kind of pickup, or just get rid of pickup (set) and have a unique Pickup Remove effect for each kind of pickup.
For example, if you load a unit and immediately unload it, is it the same as if you load a unit, add another unit to the control group, and then unload it?
In the Sound data there's fields more maximum number of overlapping sounds before the sound is silenced or destroyed. Also every sound is classified by a type that determines how far away it fades, etc., and this may have impact on overlapping sounds. Take a look at the sound's parent and its type (Spell, UI, Foley, Voice, etc.)
As others said, an actor somewhere is creating itself on the UnitBirth.* or UnitConstruction.* event inside the buildings' actor scope (that is, attached to them). You only need to figure out which actor is creating itself. Here's a possible shortcut.
The sphere indicates that it can't find the model for whatever actor is creating itself when the buildings are created. It makes a sphere when it doesn't know what else to make. So look into the game's logs (in the Starcraft II folder inside My Documents) for recent events where it says that a model is missing. It should list which actor requested the model. Then you know.
Gray = inherited from the parent actor in a Core dependency, e.g. Generic Unit Standard.
Blue = inherited from the parent actor in a expansion dependency, such as "Marine" from LibertyCampaign.SC2Mod
Red = a gray or blue value has been overridden within your own map, whether it has been replaced or simply modified.
Green = inherited from a parent within your map, or belonging to the actor itself, or overridden from a parent within your map. Basically anything that belong to your map.
No. You cannot reference trigger variables in text.
However, you could use the trigger editor to modify a value, e.g. Catalog - Set catalog field value, and then use a Data Reference to refer to that value in the text. So for example create a behavior and use triggers to set its Duration field to whatever value you want. Then, any text that refers to that duration using a Data Reference should show the updated value.
Yeah, at least with the campaign dependencies as I have them set, though, the Odin footprints are present but not actually implemented. So one may not be able to look to the Odin for an example of working footprints. The model is in there, but the model data does not specify a footprint event and the actor data does not refer to a valid model or a footprint event.
I do think there is a way to hide the menus you want, but I don't know specifically off the top of my head. What I can tell you is that you can modify the unit glossary and hide the tech trees, but you cannot modify the tech trees or other preset elements of the help menu. You can also change the titles of menu elements by finding them in the Text module and changing them. Try showing all text items, then sorting them by contents, and searching for the text that you want to change. So for example you can change "Terran Units" to "Heroes."
0
In most cases you can easily change the launch point without creating a site actor by changing the Combat: Launch Attachment Query+ in the weapon's Action actor. For example, get rid of AMFilterWeaponSetA1 and AMRandomUniform and change it to Filter Weapon, and it'll just look for a Weapon point. You can also remove all of them and use the fallback point.
0
@Laydown112:
Here's an extra tip for you. Add the following to the Terran Building actor in the XML view:
<Remove Terms="UnitConstruction.##unitName##.Start" Send="Create BuildingTerrainFlatten"/>
<Remove Terms="UnitConstruction.##unitName##.Cancel" Target="_BuildingTerrainFlatten" Send="Destroy"/>
<Remove Terms="UnitConstruction.##unitName##.Finish" Target="_BuildingTerrainFlatten" Send="Destroy"/>
<Remove Terms="UnitBirth.##unitName##.Normal" Send="Create BuildingTerrainFlatten"/>
<Remove Terms="UnitBirth.##unitName##.Suppressed" Send="Create BuildingTerrainFlattenInstant"/>
<Remove Terms="UnitBirth.##unitName##.EditorPlaced" Send="Create BuildingTerrainFlattenEditor"/>
<Remove Terms="UnitDeath.##unitName##" Target="_BuildingTerrainFlatten" Send="Destroy"/>
Then go back to detailed view and right-click Event: Remove + and select "Apply value to children." This should make it so all standard terran buildings no longer flatten terrain. (Because of issues of inheritance, it might be helpful to close the map and reopen it to get it to show properly on child actors.) Something similar can be done with Zerg buildings and probably Protoss ones too.
0
Yeah definitely looks like a bug in SC2 itself, not your map. The control group triggers are pretty buggy in general. I've run into some ridiculous stuff there myself. The best you can do is a trigger workaround that re-adds the units, but I won't be surprised if you discover other bugs in the process.
0
Np. It's pretty annoying when that kind of thing happens. I've run into it a few times, e.g. when triggers refer to items being sold. I don't know about the most recent updates, but at one time when I wanted to add a trigger response to item selling, I had to make a trigger that recorded when a unit was ordered to sell an item, and then another that actually fired when the item was sold. Only the first one could tell which item was sold, but only the second trigger knew whether the item was actually sold, and not just ordered to be sold.
0
You can make a sound loopable by setting Loop Count to -1 in the Sound data. Then use SoundContinuous actor as the parent of the sound actor, or even SoundEmitter, which is essentially what you are creating--a continuous sound attached to another actor.
0
Hmm, that's interesting. It makes some kind of sense, I think, but I don't really know why it would work that way.
0
Interesting. I've heard others complain about this bug so it must be commonplace despite being caused by triggers. Are you saying that loaded units are removed from control groups into which triggers add other units? Or does simply calling the Add unit to control group action on ANY control group cause all control groups to forget their loaded units?
My thought is that the internal code for adding a unit to a control group probably collects the current control group's non-hidden units as a unit group, adds the new unit to the unit group, and then saves the unit group as the control group.
0
The unit is being removed before the triggers have time to find it. Test this by removing the Pickup Remove effect from the Pickup (Set).
Two options: (A) Add a delay between the effects. Instead of Pickup (Set), make it an Apply Behavior that adds a behavior to the Caster from the unit picking up the pickup, and this behavior has a duration of 0.5 seconds. Triggers detect this effect and can glean both the pickup and the picking up unit. The behavior disables the Pickup behavior, and destroys the pickup when it expires.
(B) (my preferred method) make a unique pickup behavior for each kind of pickup, which allows triggers to differentiate them. In this case, Pickup (Set) should refer to a unique effect for this kind of pickup, or just get rid of pickup (set) and have a unique Pickup Remove effect for each kind of pickup.
0
Does it always happen, or are there exceptions?
For example, if you load a unit and immediately unload it, is it the same as if you load a unit, add another unit to the control group, and then unload it?
0
In the Sound data there's fields more maximum number of overlapping sounds before the sound is silenced or destroyed. Also every sound is classified by a type that determines how far away it fades, etc., and this may have impact on overlapping sounds. Take a look at the sound's parent and its type (Spell, UI, Foley, Voice, etc.)
0
As others said, an actor somewhere is creating itself on the UnitBirth.* or UnitConstruction.* event inside the buildings' actor scope (that is, attached to them). You only need to figure out which actor is creating itself. Here's a possible shortcut.
The sphere indicates that it can't find the model for whatever actor is creating itself when the buildings are created. It makes a sphere when it doesn't know what else to make. So look into the game's logs (in the Starcraft II folder inside My Documents) for recent events where it says that a model is missing. It should list which actor requested the model. Then you know.
0
To clarify a little:
Gray = inherited from the parent actor in a Core dependency, e.g. Generic Unit Standard.
Blue = inherited from the parent actor in a expansion dependency, such as "Marine" from LibertyCampaign.SC2Mod
Red = a gray or blue value has been overridden within your own map, whether it has been replaced or simply modified.
Green = inherited from a parent within your map, or belonging to the actor itself, or overridden from a parent within your map. Basically anything that belong to your map.
0
No. You cannot reference trigger variables in text.
However, you could use the trigger editor to modify a value, e.g. Catalog - Set catalog field value, and then use a Data Reference to refer to that value in the text. So for example create a behavior and use triggers to set its Duration field to whatever value you want. Then, any text that refers to that duration using a Data Reference should show the updated value.
0
@DrSuperEvil:
Yeah, at least with the campaign dependencies as I have them set, though, the Odin footprints are present but not actually implemented. So one may not be able to look to the Odin for an example of working footprints. The model is in there, but the model data does not specify a footprint event and the actor data does not refer to a valid model or a footprint event.
0
I do think there is a way to hide the menus you want, but I don't know specifically off the top of my head. What I can tell you is that you can modify the unit glossary and hide the tech trees, but you cannot modify the tech trees or other preset elements of the help menu. You can also change the titles of menu elements by finding them in the Text module and changing them. Try showing all text items, then sorting them by contents, and searching for the text that you want to change. So for example you can change "Terran Units" to "Heroes."