Construction is a seperate subject in its own right, and doesn't work like the stuff people usually refer to as "abilities".
I don't know the Protoss setup, but for Terrans there's a standalone Progress actor linked to the Build ability, of which I have no idea what its purpose is. Then each structure creates its own actors completely seperate from that through a UnitConstruction event in the Unit actor itself. This creates a Model type actor called "StructureName"Build, which is the scaffolding that constitutes most of the animation. This Model actor then creates anotherProgress actor called TerranConstructionAttached, which is shared across all structures. Using existing "StructureName"Build actors for custom structures works just fine, although they obviously share the visual scale with the original structure.
Type "construction" or "build", maybe "buildmodel" in the search bar and check what pops up for Protoss.
Edit: Okay, took a quick look at the Protoss version: They use the same general setup, with a Model actor called ProtossBuildingBirth (and variants) which creates a Progress actor called ProtossConstructionAttached, as well as a standalone Progress actor called ProtossConstruction which is tied to the Build ability. The main difference is that most structures share the same Model actor, and said actor creates itself rather than being created by the Unit actor of each individual structure. This is because the main "warp in" animation isn't scaled to the exact size of every individual structure.
As for copying/adding stuff: I think adding the custom Build ability to the standalone construction actor and adding creation events to the correct BuildingBirth variant is all that's needed, provided you don't need custom model sizes, tint colors or other graphical modifications. Keep in mind that the last part of the build animation, where the structure materialises top-down, is part of the main Unit model and unique to Protoss models. Any models lacking this animation will simply cause the structure to be completely invisible for the last 5 seconds of the construction, and you'll have to bridge that with improvised Model actors or something.
Slight correction: Tokens are entirely cosmetic, they can be used for easier re-assignment of links but are in no way relevant for the funtionality of an actor. I think Unit actors actually are the only ones where the one link restriction remains anyway as they have a ton of events. Even then you can reuse the same actor for sufficiently similar morphs.
Actors that truly are limited to a single link include things like Range actors which draw the range from a specific data object, and reusing Action actors with effect-specific Attach Methods won't work out well either. Things like Model actors are fully reuseable though.
I fully agree on the clarity thing though, unless you have something like 10 different "levels" of the same ability or a full TD "race" that can set enemies on fire by default (meaning a dozen fire effects of increasing strength), reusing actors generally only leads to massive confusion if you lay off the map for a while.
Rollback Post to RevisionRollBack
To post a comment, please login or register a new account.
Construction is a seperate subject in its own right, and doesn't work like the stuff people usually refer to as "abilities".
I don't know the Protoss setup, but for Terrans there's a standalone Progress actor linked to the Build ability, of which I have no idea what its purpose is. Then each structure creates its own actors completely seperate from that through a UnitConstruction event in the Unit actor itself. This creates a Model type actor called "StructureName"Build, which is the scaffolding that constitutes most of the animation. This Model actor then creates another Progress actor called TerranConstructionAttached, which is shared across all structures. Using existing "StructureName"Build actors for custom structures works just fine, although they obviously share the visual scale with the original structure.
Type "construction" or "build", maybe "buildmodel" in the search bar and check what pops up for Protoss.
Edit: Okay, took a quick look at the Protoss version: They use the same general setup, with a Model actor called ProtossBuildingBirth (and variants) which creates a Progress actor called ProtossConstructionAttached, as well as a standalone Progress actor called ProtossConstruction which is tied to the Build ability. The main difference is that most structures share the same Model actor, and said actor creates itself rather than being created by the Unit actor of each individual structure. This is because the main "warp in" animation isn't scaled to the exact size of every individual structure.
As for copying/adding stuff: I think adding the custom Build ability to the standalone construction actor and adding creation events to the correct BuildingBirth variant is all that's needed, provided you don't need custom model sizes, tint colors or other graphical modifications. Keep in mind that the last part of the build animation, where the structure materialises top-down, is part of the main Unit model and unique to Protoss models. Any models lacking this animation will simply cause the structure to be completely invisible for the last 5 seconds of the construction, and you'll have to bridge that with improvised Model actors or something.
@DuckyTheDuck: Go
Slight correction: Tokens are entirely cosmetic, they can be used for easier re-assignment of links but are in no way relevant for the funtionality of an actor. I think Unit actors actually are the only ones where the one link restriction remains anyway as they have a ton of events. Even then you can reuse the same actor for sufficiently similar morphs.
Actors that truly are limited to a single link include things like Range actors which draw the range from a specific data object, and reusing Action actors with effect-specific Attach Methods won't work out well either. Things like Model actors are fully reuseable though.
I fully agree on the clarity thing though, unless you have something like 10 different "levels" of the same ability or a full TD "race" that can set enemies on fire by default (meaning a dozen fire effects of increasing strength), reusing actors generally only leads to massive confusion if you lay off the map for a while.