Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

sc2: Adding Mothership WC and Supplicant Zenith Pitch upgrade #339

Merged

Conversation

MatthewMarinets
Copy link
Contributor

@MatthewMarinets MatthewMarinets commented Dec 14, 2024

Adding supplicant upgrade: Zenith Pitch. Allows Supplicants to target air.
Pairs with client PR #375
Progress on #152

Note I gave the mothership a behaviour to get selecting it to display power fields. However, I couldn't find a way to get the upgrade to remove this behaviour, so motherships will just always show pylon power fields.

Mothership Pictures

mothership_slow
image
image
image

Supplicant pictures

supplicant_zenith_pitch
image
image
image

@MatthewMarinets MatthewMarinets changed the title sc2: Adding Supplicant Zenith Pitch upgrade sc2: Adding Mothership WC and Supplicant Zenith Pitch upgrade Dec 14, 2024
<InfoFlags index="Hidden" value="1"/>
<InfoIcon value="Assets\Textures\btn-building-protoss-pylon.dds"/>
<EditorCategories value="Race:Protoss,AbilityorEffectType:Structures"/>
<DisableValidatorArray value="AP_NotHaveMothershipTaldarimIntegratedPower"/>
Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Editor Warning:
Warning: XML: Z:\hdd\home\venca\software\battle-net\drive_c\Program Files (x86)\StarCraft II\Mods\ArchipelagoPlayer.SC2Mod\Base.SC2Data\GameData\BehaviorData.xml(4704,9) : Unable to find field DisableValidatorArray Source: Mods/ArchipelagoPlayer.SC2Mod Entry: AP_DisplayPowerFieldMothership Scope: CBehaviorPowerSource

Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I believe this is the root of your bug as the behavior isn't a CBehaviorBuff. You can, however remove the behavior with a trigger (There's a trigger that removes Ursadon's CBehaviorLeash on being derpfestor'd)
You want to remove the behavior on following events: An upgrade is being given or a unit is trained

Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Alternatively, you could have a second behavior that's acting as a controller and when exiting, do the remove behavior effect that removes the power source

Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

BTW found that Power source behavior can use requirements:

    <CBehaviorPowerSource id="AP_WarpPrismPowerSource">
        <InfoFlags index="Hidden" value="1"/>
        <EditorCategories value="Race:Protoss,AbilityorEffectType:Structures"/>
        <Radius value="3.75"/>
        <PowerLink value="PowerSource"/>
        <Requirements value="AP_NotHaveWarpPrismWarConfiguration"/>
    </CBehaviorPowerSource>

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

So I've tried

  • Requirements
  • DisableValidator
  • RemoveValidator
  • Removing straight from the upgrade's EffectArray
  • Having another behaviour remove it with BehaviorLinkDisableArray

Some of those removed the behaviour icon, but none removed the power field visuals. As far as I can tell, it's the presence of a link to this behaviour type at all that works.

Checking the triggers, UnitBehaviorRemove seems to target a particular unit rather than a unit type. I'll try tinkering with a behaviour chain before I go the trigger route, as triggers likely means a persistent trigger that enables / disables behaviours continuously.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think I figured out how to approach this. Buried all the way in core is this:

    <CActorPower default="1">
        <PowerSource value="##id##Source"/>
    </CActorPower>

Which seems to be the root of the display woes. I should be able to trace this through actordata and deal with the visuals from there.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Opened things in the editor to check, all error messages related to this PR should be cleaned up
image

@MatthewMarinets MatthewMarinets force-pushed the mm/supplicant_mothership_upgrades branch from 3cd1d54 to 419e71d Compare December 14, 2024 22:13
@MatthewMarinets
Copy link
Contributor Author

The power field display should be working as intended now. Without the upgrade, Pylon power fields display when the mothership is selected. When the upgrade is acquired, this behaviour goes away.

works_mothership

This was accomplished by a unit morph to an alternate mothership unit. As far as I can tell, PowerSource layer display is controlled by the game binary and is not modifiable from actordata. It displays if a unit is selected and that unit's behaviorArray includes either a CBehaviorPowerSource or CBehaviorPowerUser with DisplayPower flag set to 1. So the only way to control it in data is with the classic unit morph trick we've used for cargo capacity and rootable footprints.

Did a check afterwards. The actordata seemed to work fine, stargate build display still works the same, and I fixed the mothership requirement to also account for the new mothership variant.

@Ziktofel
Copy link
Owner

Snímek obrazovky pořízený 2024-12-15 11-50-47
Snímek obrazovky pořízený 2024-12-15 11-53-00
Armor upgrades don't work, only update the icon, not unit stats if the Mothership is upgraded

@Ziktofel Ziktofel merged commit c6071a4 into Ziktofel:sc2-next Dec 15, 2024
1 check passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants