I'm not well-versed with triggers, you should probably check the tutorials or the Triggers subforum. The basic setup would be to trigger on something like completion of an upgrade, then iterate through all possible combinations of damage upgrades, then set the weapon icon matching that specific upgrade combination. You probably could have a seperate trigger for each combination, but that very inefficient and you should try finding a better solution.
The data-only version essentially does the same thing, only you need a Requirement to check for the upgrade combination, a hidden dummy upgrade to set the icon, and as I said probably a hidden Buff behavior to act as the "activation trigger".
I haven't looked in-depth at how you set up your attachments, but it's probably either a hosting problem with those or the Attach Methods on the attack actors. I know the standard Goliath uses one that a) cycles through specific attachment points (which your shoulder turrets might lack) and b) is intrinsically linked to the Launch Missile effect of that specific weapon to drive the "cycling" part.
Also your Token field for the impact effect is messed up, but I don't know if that affects the actual actor in any way (happens when duping, but I never bother to check the actual actor fields before changing the token)
Probably best to do it via triggers, especially since the lvl1-3 upgrades will interfere as you said. Much easier to check multiple conditions and pick a corresponding course of action (i.e. count the total attack bonus in some way and then set the proper icon)
Doing this with data only would probably require some hidden stuff with Validators/Requirements to check each and every cumulative upgrade combination. I don't know of anything other than Upgrades for changing the icons, but they are player-wide, aren't linked to any single unit, and can't internally run validator-based decision trees. So you'd be looking at a hidden Research ability, one hidden dummy upgrade+Requirement per icon, and probably something like a Buff behavior to place the Requirement on if you can't get the research ability to autocast reliably.
I haven't found any that scale properly. Archon beam gets somewhat larger but also distorted, Colossus/Void Ray/Diamondback beams just scale launch and impact models (+ the weirdness described above, but none of that qualifies as proper scaling in my book)
I can't be bothered to test all of them for all possible variations in relative scale, but I can confirm that an isotropic scale doesn't work consistently for the standard attack beams.
I would like to see Durandel's results and which scales they involve, as my most recent test literally changed nothing but the scale and model on the Archon attack setup, and failed miserably.
Update: did some testing with the stock Archon attack, and it is very wonky for me. Uniform upscaling doesn't work, scaling X+Z doesn't work (and Y definitely is the length axis), and I've tried both actor and model scale. XZ-scale also breaks the "flow" of the beam somewhat, verify by scaling X, Z=5 on only one of the two Colossus beam actors.
What does work is scaling X and Z unequally. Increasing just one of them produces a flat shape scaled in that dimension as it should be. Increasing both to large, but unequal values (X=5.1, Z=5.0, Colossus attack beam swapped onto Archon attack actor) produces a very glitchy-looking behavior where the beam dynamically adjusts its transverse scale during its animation! The exact scale also depends on the orientation of the beam, but getting the full scaled width is pretty rare.
Just what is going on here? The game seems to auto-compensate the global scale of the beam, and anisotropic scaling seems to break it somehow. Or maybe the texture is getting scaled, but then the game tries to squeeze it into a constant-size "tube"?
Damage effects have a flag to reveal attackers. By default most ground units' weapons are set to "Snapshot" (visible, but not targetable), while all air units and the Colossus are fully revealed. Some special effects will have no reveal proc at all, leaving victims completely oblivious.
What's important is the event triggers which create/control the turret, and the Host fields on the turret (and any intermediate ModelAddition actors or the like)
Some of those validator checks should be of the form X->Validate(upgrade)->Create/Signal. What is "X", and what exactly is the method they use for creation? Does the bunker create the turret, or does it merely send a Signal? Does the turret create itself, or use some kind of RefSet event? Some of those make use of the "Target" line in the event itself, and that field isn't automatically adjusted during Duplicate (or even straight ID changes for that matter, the editor handles it like a random comment string)
Interdependent actor systems are rather finicky, it would be a lot easier if you could upload a demo map for other people to muck about in. Don't upload your "main" project map, try replicating your setup in a new one. Sometimes you even correct a simple and obvious mistake from simply trying to replicate what you already have.
Edit: Took a quick glance at the Bunker Shrike Turret and it's a total mess with Signals and StatusSet all over the place. For the most part it's simply controlled by the main Bunker actor, but there's a "Placeholder" version of the turret model actor which is used during construction.
I meant in the armory/factory I had no assigned more than one button to any slot in the CC.
You haven't, but maybe the game is trying to do just that. For each broken button you notice, note down its position on the card as well as all buttons in that slot for all dependencies you use. See if there's any pattern in the results, like "only slots where both a WoL campaign-only unit and a HotS-added unit are placed". Oh, and please don't use the abbreviation "CC" while dealing with Terrans, I for one have no idea whether you mean Command Card or Command Center.
The only way of outright "corrupting" data I can see you doing is importing/copying from a very old version of the editor, as in "so old they don't check backwards compatibility for it anymore". On the other hand, they do give out warnings how certain dependencies are "incompatible" (mainly WoL campaign vs. some HotS stuff), so maybe you've stumbled into one of the reasons behind these warnings. Maybe they have a hardcoded "load priority" list which is trying to load two of those dependencies with equal rights. Maybe it notices this and only loads the first one, completely discarding subsequent edits. Maybe it's running out of internal indices to assign all those overwritten buttons. I have no idea, and too little data so far to make a proper educated guess.
The breakpoint probably is a lot less than 1s, actually. When a unit is insta-summoned it probably skips the main "construction" phase entirely. This would mean that actor events meant to occur at the end of construction will happen in the same game tick as those linked to the start of construction.
What does this mean for a Terran structure? Well, the Unit actor is created at the start of construction, mostly for that mid-build popup animation. Meanwhile, most actors will want to wait until the structure is fully built, so they use UnitConstruction.UnitName.Finish as their event trigger. Structures don't provide good examples because most of what they do can only be activated after construction anyway, but Beams face a similar problem:
A "beam" is defined by two host actors, one each for launch and impact. The beam can only exist properly if both of these resolve to a valid actor at the time the beam actor is created. As an analogue to construction, you can have a beam going from a Ghost to the red "nuke impact" dot right from the start, because the dot is placed more-or-less instantly. You can not draw a beam to the center of the mushroom cloud until the explosion actually occurs, for the obvious reasy that the explosion doesn't exist until the bomb goes off.
The problem is that invalid hosts can produce "semi-viable" results, often seen with chain lightning effects where all beams will leash back to the caster instead of launching from the most recent target. For turrets that might be the "not rotating" state you see. For example if your turret is created by the host structure on ActorCreation, it might look for an attachment point that simply isn't there during the construction animation, break, and snap to the default fallback. If UnitConstruction.Finish occurs in the same game tick however, the unit actor will immediately start playing its "construction completed" animation (or skip even that and go straight to "Stand"), which might have that attachment point.
Also, are you sure the insta-built version is fully functional? That video doesn't show it firing or properly tracking enemies, for instance, and rotating constantly is the default "idle" setting for many turrets. It may be broken, but slightly less so due to receiving a single valid "start being idle" signal.
no, there are not additional buttons assigned to any sloton the CC.
Care to elaborate? I myself added both ArmoryResearch and ArmoryResearch8 to the Command Center as a test, along with the 2 buttons each for the custom researches. They work perfectly, each with their individual cost+research time, and pressing one button also correctly removes the other one that's linked to the same upgrade, as dictated by the Requirement.
The problem is tied to the Armory unit, due to bad inheritance, corrupted data or hardcoded limitations I'm not aware of. My approach (for everything, really) would be to cut down on the dependencies first, and if that fails copy the Armory and use the copy. In fact I create almost anything from scratch or dupe, precisely to avoid such "hidden" problems and gain an understanding of all the extra mechanics required to get something working. Of course this is a lot of additional work at first, since you have to edit the SCV build, construction actors, low-health flame actor, tech tree requirements and the occasional whitelist (Chronoboost uses one iirc)
The factory command card still sounds like a dependency conflict. Could you note down all bugged buttons and compare them to the command card layout for the dependencies you use? I have no idea why publishing would cause additional problems though.
Compare to the campaign shrike turrets then? Those do seem to work after all.
While not directly related to turrets, when and how an actor is created can have a massive effect on the overall setup. In particular At Terms in the creation event and self-create+Actor Find Host vs. remote-create and Host = ::Creator. Especially if you're using attached models and aliases finding the proper host may be a problem.
Have you tried simply saving and reloading? Whenever you edit unit models you get warnings "blabla something CActorUnit blabla" but everything works fine, maybe doodads just don't update properly?
And of course check the standard stuff, especially incorrect "standard"(grey) values inherited from the source, both on actors and the models. Do you get the same error if you set the model to that of an existing doodad with similar properties as the one you're creating?
For a start, why don't you compare your setup to what the Terran Missile Turret does? Maybe one of the actor events requires a slightly different configuration for "built" units since UnitBirth, UnitConstruction.*.Finish and ActorCreation aren't fully equivalent.
Nah, no morph. I just looked through their map in XML view and counted button entries from sources other than the map itself. Both Liberty and LibertyStory set buttons without an "index" property, while the map assigns one to each of its own entries. If you count all the "removed" entries the map lists exactly as many buttons as Liberty and LibertyStory combined: 28
That's only buttons though, they're all linking to different entries in the same ability (Armory Research ability)
Both buttons work on either ability when I place them on the Command Center. I don't know how you managed to break it, but the command card for the Armory seems to be loading incorrect junk data from somewhere. In XML view there's a ton of "index->removed" entries deleting buttons from other dependencies (mainly Liberty and LibertyStory), maybe those are counting toward some global cap? Or your buttons are inheriting invalid properties from other dependencies?
Regarding the Hellbat, I don't have any experience in publishing stuff, but maybe you're trying to publish/upload as a WoL map? I would assume Blizzard blocks HotS dependencies and assets for those, otherwise what's the point of buying the expansion?
Other random things I noticed in your map:
Tech Reactors are missing the Cancel button for their production queue, which also prevents hotkey-cancel.
The Vehicle Weapons button links to the Vehicle Armor research option.
The Vehicle Weapons button has an internal ID of "UnknownButton".
The "Bulwark Company" goliaths don't seem to be gaining increased attack range from "Extra Fuel".
0
I'm not well-versed with triggers, you should probably check the tutorials or the Triggers subforum. The basic setup would be to trigger on something like completion of an upgrade, then iterate through all possible combinations of damage upgrades, then set the weapon icon matching that specific upgrade combination. You probably could have a seperate trigger for each combination, but that very inefficient and you should try finding a better solution.
The data-only version essentially does the same thing, only you need a Requirement to check for the upgrade combination, a hidden dummy upgrade to set the icon, and as I said probably a hidden Buff behavior to act as the "activation trigger".
0
I haven't looked in-depth at how you set up your attachments, but it's probably either a hosting problem with those or the Attach Methods on the attack actors. I know the standard Goliath uses one that a) cycles through specific attachment points (which your shoulder turrets might lack) and b) is intrinsically linked to the Launch Missile effect of that specific weapon to drive the "cycling" part.
Also your Token field for the impact effect is messed up, but I don't know if that affects the actual actor in any way (happens when duping, but I never bother to check the actual actor fields before changing the token)
0
Probably best to do it via triggers, especially since the lvl1-3 upgrades will interfere as you said. Much easier to check multiple conditions and pick a corresponding course of action (i.e. count the total attack bonus in some way and then set the proper icon)
Doing this with data only would probably require some hidden stuff with Validators/Requirements to check each and every cumulative upgrade combination. I don't know of anything other than Upgrades for changing the icons, but they are player-wide, aren't linked to any single unit, and can't internally run validator-based decision trees. So you'd be looking at a hidden Research ability, one hidden dummy upgrade+Requirement per icon, and probably something like a Buff behavior to place the Requirement on if you can't get the research ability to autocast reliably.
0
@Zolden: Go
I haven't found any that scale properly. Archon beam gets somewhat larger but also distorted, Colossus/Void Ray/Diamondback beams just scale launch and impact models (+ the weirdness described above, but none of that qualifies as proper scaling in my book)
I can't be bothered to test all of them for all possible variations in relative scale, but I can confirm that an isotropic scale doesn't work consistently for the standard attack beams.
I would like to see Durandel's results and which scales they involve, as my most recent test literally changed nothing but the scale and model on the Archon attack setup, and failed miserably.
0
Update: did some testing with the stock Archon attack, and it is very wonky for me. Uniform upscaling doesn't work, scaling X+Z doesn't work (and Y definitely is the length axis), and I've tried both actor and model scale. XZ-scale also breaks the "flow" of the beam somewhat, verify by scaling X, Z=5 on only one of the two Colossus beam actors.
What does work is scaling X and Z unequally. Increasing just one of them produces a flat shape scaled in that dimension as it should be. Increasing both to large, but unequal values (X=5.1, Z=5.0, Colossus attack beam swapped onto Archon attack actor) produces a very glitchy-looking behavior where the beam dynamically adjusts its transverse scale during its animation! The exact scale also depends on the orientation of the beam, but getting the full scaled width is pretty rare.
Just what is going on here? The game seems to auto-compensate the global scale of the beam, and anisotropic scaling seems to break it somehow. Or maybe the texture is getting scaled, but then the game tries to squeeze it into a constant-size "tube"?
0
Damage effects have a flag to reveal attackers. By default most ground units' weapons are set to "Snapshot" (visible, but not targetable), while all air units and the Colossus are fully revealed. Some special effects will have no reveal proc at all, leaving victims completely oblivious.
0
What's important is the event triggers which create/control the turret, and the Host fields on the turret (and any intermediate ModelAddition actors or the like)
Some of those validator checks should be of the form X->Validate(upgrade)->Create/Signal. What is "X", and what exactly is the method they use for creation? Does the bunker create the turret, or does it merely send a Signal? Does the turret create itself, or use some kind of RefSet event? Some of those make use of the "Target" line in the event itself, and that field isn't automatically adjusted during Duplicate (or even straight ID changes for that matter, the editor handles it like a random comment string)
Interdependent actor systems are rather finicky, it would be a lot easier if you could upload a demo map for other people to muck about in. Don't upload your "main" project map, try replicating your setup in a new one. Sometimes you even correct a simple and obvious mistake from simply trying to replicate what you already have.
Edit: Took a quick glance at the Bunker Shrike Turret and it's a total mess with Signals and StatusSet all over the place. For the most part it's simply controlled by the main Bunker actor, but there's a "Placeholder" version of the turret model actor which is used during construction.
0
You haven't, but maybe the game is trying to do just that. For each broken button you notice, note down its position on the card as well as all buttons in that slot for all dependencies you use. See if there's any pattern in the results, like "only slots where both a WoL campaign-only unit and a HotS-added unit are placed". Oh, and please don't use the abbreviation "CC" while dealing with Terrans, I for one have no idea whether you mean Command Card or Command Center.
The only way of outright "corrupting" data I can see you doing is importing/copying from a very old version of the editor, as in "so old they don't check backwards compatibility for it anymore". On the other hand, they do give out warnings how certain dependencies are "incompatible" (mainly WoL campaign vs. some HotS stuff), so maybe you've stumbled into one of the reasons behind these warnings. Maybe they have a hardcoded "load priority" list which is trying to load two of those dependencies with equal rights. Maybe it notices this and only loads the first one, completely discarding subsequent edits. Maybe it's running out of internal indices to assign all those overwritten buttons. I have no idea, and too little data so far to make a proper educated guess.
0
@Codepilot: Go
The breakpoint probably is a lot less than 1s, actually. When a unit is insta-summoned it probably skips the main "construction" phase entirely. This would mean that actor events meant to occur at the end of construction will happen in the same game tick as those linked to the start of construction.
What does this mean for a Terran structure? Well, the Unit actor is created at the start of construction, mostly for that mid-build popup animation. Meanwhile, most actors will want to wait until the structure is fully built, so they use UnitConstruction.UnitName.Finish as their event trigger. Structures don't provide good examples because most of what they do can only be activated after construction anyway, but Beams face a similar problem:
A "beam" is defined by two host actors, one each for launch and impact. The beam can only exist properly if both of these resolve to a valid actor at the time the beam actor is created. As an analogue to construction, you can have a beam going from a Ghost to the red "nuke impact" dot right from the start, because the dot is placed more-or-less instantly. You can not draw a beam to the center of the mushroom cloud until the explosion actually occurs, for the obvious reasy that the explosion doesn't exist until the bomb goes off.
The problem is that invalid hosts can produce "semi-viable" results, often seen with chain lightning effects where all beams will leash back to the caster instead of launching from the most recent target. For turrets that might be the "not rotating" state you see. For example if your turret is created by the host structure on ActorCreation, it might look for an attachment point that simply isn't there during the construction animation, break, and snap to the default fallback. If UnitConstruction.Finish occurs in the same game tick however, the unit actor will immediately start playing its "construction completed" animation (or skip even that and go straight to "Stand"), which might have that attachment point.
Also, are you sure the insta-built version is fully functional? That video doesn't show it firing or properly tracking enemies, for instance, and rotating constantly is the default "idle" setting for many turrets. It may be broken, but slightly less so due to receiving a single valid "start being idle" signal.
0
Care to elaborate? I myself added both ArmoryResearch and ArmoryResearch8 to the Command Center as a test, along with the 2 buttons each for the custom researches. They work perfectly, each with their individual cost+research time, and pressing one button also correctly removes the other one that's linked to the same upgrade, as dictated by the Requirement.
The problem is tied to the Armory unit, due to bad inheritance, corrupted data or hardcoded limitations I'm not aware of. My approach (for everything, really) would be to cut down on the dependencies first, and if that fails copy the Armory and use the copy. In fact I create almost anything from scratch or dupe, precisely to avoid such "hidden" problems and gain an understanding of all the extra mechanics required to get something working. Of course this is a lot of additional work at first, since you have to edit the SCV build, construction actors, low-health flame actor, tech tree requirements and the occasional whitelist (Chronoboost uses one iirc)
The factory command card still sounds like a dependency conflict. Could you note down all bugged buttons and compare them to the command card layout for the dependencies you use? I have no idea why publishing would cause additional problems though.
0
Compare to the campaign shrike turrets then? Those do seem to work after all.
While not directly related to turrets, when and how an actor is created can have a massive effect on the overall setup. In particular At Terms in the creation event and self-create+Actor Find Host vs. remote-create and Host = ::Creator. Especially if you're using attached models and aliases finding the proper host may be a problem.
0
Have you tried simply saving and reloading? Whenever you edit unit models you get warnings "blabla something CActorUnit blabla" but everything works fine, maybe doodads just don't update properly?
And of course check the standard stuff, especially incorrect "standard"(grey) values inherited from the source, both on actors and the models. Do you get the same error if you set the model to that of an existing doodad with similar properties as the one you're creating?
0
For a start, why don't you compare your setup to what the Terran Missile Turret does? Maybe one of the actor events requires a slightly different configuration for "built" units since UnitBirth, UnitConstruction.*.Finish and ActorCreation aren't fully equivalent.
0
@FunkyUserName: Go
Nah, no morph. I just looked through their map in XML view and counted button entries from sources other than the map itself. Both Liberty and LibertyStory set buttons without an "index" property, while the map assigns one to each of its own entries. If you count all the "removed" entries the map lists exactly as many buttons as Liberty and LibertyStory combined: 28
That's only buttons though, they're all linking to different entries in the same ability (Armory Research ability)
0
Both buttons work on either ability when I place them on the Command Center. I don't know how you managed to break it, but the command card for the Armory seems to be loading incorrect junk data from somewhere. In XML view there's a ton of "index->removed" entries deleting buttons from other dependencies (mainly Liberty and LibertyStory), maybe those are counting toward some global cap? Or your buttons are inheriting invalid properties from other dependencies?
Regarding the Hellbat, I don't have any experience in publishing stuff, but maybe you're trying to publish/upload as a WoL map? I would assume Blizzard blocks HotS dependencies and assets for those, otherwise what's the point of buying the expansion?
Other random things I noticed in your map: