Basically my turret functions correctly on the building if its built instantly, but if i add even a 3 second delay to it building the turret does not turn towards attackers or spin anymore.
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.
Didn't find anything in there that seemed to make a difference. Also seems the custom turret unit in that tutorial doesn't function correctly if built with more then 0 second delay either lol... it distorts and such which is shocking, all though it is an older tutorial things could of changed.
Here's a video of the problem:
First one he makes is set to instant build and functions correctly
Second on he makes is set to 5 second build (problem happens 1+ second delay) and shows it doesn't spin anymore also doesn't turn to shoot
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.
How does the build speed of something affect the linking of all that exactly? just seems strange that, just a single second difference in it popping up can break it so easily lol
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.
As far as I can tell its functional when insta-built here's a brief video of it in action,
There are some events for the normal bunker like validate shrike set turret on and such. But I am not too sure how that could be used for mine as it isn't a researched turret but is on by default.
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.
The Turret actor itself will have the standard hosting fields. If you specify a host there just reconstruct its identity based on the scope. If that host is "Implicit" you'll have to read up on the "standard" behavior I guess. "Host=Creator" works very reliably if you can afford to tie actor creation to some precursor/"main" actor (which should work with your attached model, since you don't need the turret actor before that's created)
Indeed the standard "assign turret to weapon on unit" approach might fail, because the turret actor will most likely be hosted on the main unit's actor (or if you didn't change anything, might even be set to explicitly host on "_Selectable", aka the main unit)
The relevant part probably is the Attachment field at the top. Ensure the actor "AttachmentArtilleryTurret" is already created at the time this turret activates, which most likely isn't the case if the turret is set on the main Unit and the corresponding actor creates its attachments.
Rollback Post to RevisionRollBack
To post a comment, please login or register a new account.
Basically my turret functions correctly on the building if its built instantly, but if i add even a 3 second delay to it building the turret does not turn towards attackers or spin anymore.
Used: http://www.sc2mapster.com/forums/resources/tutorials/8926-data-working-with-attachments-beginner-difficulty/ as a reference to make it, functions flawless when instant built. Any help would be great thanks in advance.
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.
Didn't find anything in there that seemed to make a difference. Also seems the custom turret unit in that tutorial doesn't function correctly if built with more then 0 second delay either lol... it distorts and such which is shocking, all though it is an older tutorial things could of changed.
Here's a video of the problem:
First one he makes is set to instant build and functions correctly Second on he makes is set to 5 second build (problem happens 1+ second delay) and shows it doesn't spin anymore also doesn't turn to shoot
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.
How does the build speed of something affect the linking of all that exactly? just seems strange that, just a single second difference in it popping up can break it so easily lol
@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.
As far as I can tell its functional when insta-built here's a brief video of it in action,
There are some events for the normal bunker like validate shrike set turret on and such. But I am not too sure how that could be used for mine as it isn't a researched turret but is on by default.
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.
@Photoloss: Go
Ya i saw the placeholder, just not familiar enough with the events setup to properly reproduce that I will have to do some reading up first.
Probably my best bet is to just duplicate that part of the process. I do appreciate you doing your best to help me out with this issue.
Sure your Turret actor is being hosted on the right model?
Contribute to the wiki (Wiki button at top of page) Considered easy altering of the unit textures?
https://www.sc2mapster.com/forums/resources/tutorials/179654-data-actor-events-message-texture-select-by-id
https://media.forgecdn.net/attachments/187/40/Screenshot2011-04-17_09_16_21.jpg
Honestly not sure, what would I check under and I can get you all the info of how i have it setup.
The Turret actor itself will have the standard hosting fields. If you specify a host there just reconstruct its identity based on the scope. If that host is "Implicit" you'll have to read up on the "standard" behavior I guess. "Host=Creator" works very reliably if you can afford to tie actor creation to some precursor/"main" actor (which should work with your attached model, since you don't need the turret actor before that's created)
Indeed the standard "assign turret to weapon on unit" approach might fail, because the turret actor will most likely be hosted on the main unit's actor (or if you didn't change anything, might even be set to explicitly host on "_Selectable", aka the main unit)
This is what I have for the turret actor:
The relevant part probably is the Attachment field at the top. Ensure the actor "AttachmentArtilleryTurret" is already created at the time this turret activates, which most likely isn't the case if the turret is set on the main Unit and the corresponding actor creates its attachments.