Techno attachment logic

[Metadorius]

• Technos now can be attached one to another in a tree like way. The attached units won't process any locomotion code and act like a part of a parent unit in a configurable.
  • Currently the attached techno may only be a vehicle.
  • When attached, the special Attachment ({C5D54B98-8C98-4275-8CE4-EF75CB0CBE3E}) locomotor is automatically casted on a unit. You may also specify it in the child unit types manually if the unit is not intended to move without a parent (f. ex. a turret).

In rulesmd.ini:

[AttachmentTypes]
0=MNT                                 ; (example)

[MNT]
RespawnAtCreation=true                ; boolean
RespawnDelay=-1                       ; integer, non-negative values enable the respawn timer
InheritOwner=true                     ; boolean, whether the child inherits owner of the parent while it's attached
InheritStateEffects=true              ; boolean (state effects = chaos, iron curtain etc.)
InheritCommands=true                  ; boolean
InheritCommands.StopCommand=true      ; boolean
InheritCommands.DeployCommand=true    ; boolean
LowSelectionPriority=true             ; boolean, whether the child is low priority while attached
YSortPosition=default                 ; Attachment YSort position enumeration - default|underparent|overparent
InheritDestruction=true               ; boolean
InheritHeightStatus=true              ; boolean, whether the layer and InAir/OnGround/IsSurfaced inherited from parent
OccupiesCell=true                     ; boolean
DestructionWeapon.Child=              ; WeaponType, detonated on child when parent is destroyed
DestructionWeapon.Parent=             ; WeaponType, detonated on parent when child is destroyed
ParentDestructionMission=             ; MissionType, queued to child when parent is destroyed
ParentDetachmentMission=              ; MissionType, queued to child when it's detached from parent

[SOMETECHNO]                          ; TechnoTypeClass
; used when this techno is attached
AttachmentTopLayerMinHeight=          ; integer
AttachmentUndergroundLayerMaxHeight=  ; integer
; used for attaching other technos
AttachmentX.Type=MNT                  ; AttachmentType (example)
AttachmentX.TechnoType=               ; TechnoType that can be attached, currently only units are supported
AttachmentX.FLH=0,0,0                 ; integer - Forward, Lateral, Height
AttachmentX.IsOnTurret=false          ; boolean
AttachmentX.RotationAdjust=0          ; rotation in DirType, from -255 to 255

[General]
AttachmentTopLayerMinHeight=500           ; integer,
AttachmentUndergroundLayerMaxHeight=-256  ; integer

• The semantic locomotor alias feature is also supported for Phobos locomotors.

Alias	CLSID
Attachment	{C5D54B98-8C98-4275-8CE4-EF75CB0CBE3E}

TODO:

• Handling different locomotors being attached
  • TunnelLoco currently leaves the initial place as if it was left there, crashes the game on destruction
  • Jumpjets stay invincible when attached
  • Review the possibility of adding a custom attachment locomotor instead of a locomotor + skipping Loco process code and changing to it and back
  • loosely related - turret is rendered wrong for TunnelLocoClass when going up
• Sync up the phasing in state for Teleport locomotor
• IsOnTurret is broken visually
• Shadows need to be fixed too
• Latest build crashes on release/devbuild but not on debug when children is yeeted, most likely some piggybacking refcount screwery
• Jumpjets crash improperly when they are crashable=yes and destroyed with children destruction
• Handle placing the detached children into the correct place (they are not centered at the cell or the correct position for inf atm)
• Add a flag to force same mission and target to attachments, shouldn't be mixed with commandability
• Make attached units untargetable and non-damageable using regular weapons via a tag
• Check AI shenanigans
• Make attached units unselectable (transparent to selection) via a tag
• Make attached units be transparent for pathfinding and building placement but still targetable and damageable
• Handle movement command issued with command inheritance enabled (i.e. optionally reset targets like vanilla units do). possibly just reset the mission when movement command is given and recursed into children instead of doing nothing for that command
• The source of destruction on parent unit specifically appears to be null for cargo (and consequently the children), see 0x7384AB which later calls Kill_Cargo. Needs context and/or earlier Kill_Cargo/On_Destroyed call
• Rotation adjustment tag
• Non-omnifire units without turret rotate and snap back even though the code, test if still happens
• Units now could clip into each other for some reason sometimes, need to review the passability hook again to see what changed
• When ordering a vehicle with attachments that offset the "center of mass" to move arrives at offset cell
• ConsideredAircraft still crashes when combined with AttachmentLocomotion, something related to AircraftTracker
• Attachment loco does not provide sensors or sight currently
• Sort out speed=0 while being attached interaction (may just block speed=0 features if attached) and review similar hooks with Techno Attachment
• Investigate Per_Cell_Process for useful stuff for TA
• Check interaction with cloak inheritance and other state effect inheritance
• Improve scatter when something tries to enter the cell on cell-occupying attached technos to make the parent scatter instead
• Weird bug when cell stays semi-occupied after the children gets destoyed with parent on that cell? might be related to RotE's husks
• Implement handling of deploy
• Implement handling of conversion
  • Feature/techno attachment type conversion #1259 to be reviewed and worked upon
• Implement building upgrades support
• Implement children appearing/disappearing on buildup end (or selldown start)
• Fix bugged loading of unrelated units into transport when multiple units are on cell
• AttachmentX.IsOnBarrel (?)
• Units still clip into each other sometimes (unconfirmed)
• Shadow scale on children of jumpjets is incorrect
• Units with attachment at 0, 0, 0 can't exit War Factory once again for some reason despite the handling code existing and working previously

Known issues:

• The attachment jitter when they are offset from the 0,0,0 point. This is most likely a precision issue that is impossible to fix without a lot of code to draw the voxel relative to the main point and canvas enlargement. Prototype code exists but commented out and a bit outdated due to locomotors, it needs further work.
• Shadows currently don't behave like parts of the same unit (aka being on one single plane). If that's undesirable - disable children shadows and make shadows via main unit VXL (maybe shadow section hack with transparent voxels).
• Sight may be hacky as it abuses the in-air sight timer, might need testing, especially with height changes.

[Metadorius]

Q: How do I make turrets that don't act like a separate unit? (can't be targeted, destroyed, don't have health)
A: Use HealthBar.Hide, Selectable and a custom armor type with some HP that is destroyed with DestructionWeapon.Child.

[Metadorius]

<none> on *Weapons doesn't work.

[Talafhah1]

chrono:
on parent: works but only children in the sw range actually teleport with the parent, rest get stuck in limbo; they die once the parent dies or is sent to a grinder
on child: doenst have any effect

ic:
on parent: works; affects all children too
on child: no effect

chaos:
on parent: colours all children but only parents and children in range of the weap are affected, sometimes children who are really far away (3k leptons) are affected too even tho the weap only has a range and cell spread of 1
on children: only affects children in range of the weap, they dont get coloured tho, and they seem to target themselves

temporal weaps:
parent: targeting affects all children, stopping the attack makes them stuck in place, if u target them with a temporal weap then stop the go back to being attached like normally, if u kill the parent the game crashes
child: gets stuck in place, stopping the atk returns the child to the parent like youd expect

[4SGX]

BuildingTypes have several bugs.

Attached BuildingTypes keep their anims when removed from the map if deployed and BuildingTypes attached to a movable techno will be placed at the position the parent was created until the parent techno deploys or is destroyed. Chronosphere-ing a unit with attached BuildingTypes will also rarely create impassible/unbuildable terrain when the parent deploys/is destroyed.
Video

Having a child techno be important to the game ending (e.g. being the last building) the game will simply not end when destroyed.

[gangster-ppm]

Attach passanger to a projectiles:

• Magnetron pulls its target, absorbs, then launches it away with inviso V3
• RA3 Bullfrogs

[4SGX]

Crash on having attached base destroyed and continuing-despite-short-game-on bug I mentioned earlier then creating a new attached building. Code, video, and snapshot in link below.
https://discord.com/channels/338055131666972683/773636942775582720/883466977761435668

[FS-21]

Wish:
Could all units (master & attached) optionally share Ammo=?

[Metadorius]

@SCIPCION
@ayylmaoRotE figured out the TA unit getting stuck in factory bug, it now works fine

[github-actions]

Nightly build for this pull request:

• compiled-dll-63bf5b00d51bc0f429da49f55f2fb575a463ace6.zip
  These artifacts will expire in 90 days and will not be available for download after that time.

This comment is automatic and is meant to allow guests to get latest nightly builds for this pull request without registering. It is updated on every successful build.

[Metadorius]

Still crashes, same EIP. However, the attachment had ConsideredAircraft=yes on it, so i commented it out. No longer crashes after that.

@mevitar could you repro that again on the latest build? @ayylmaoRotE could not repro

[mevitar]

Sorry it took so long.
The crash with ConsideredAircraft=yes attachment still happens.

[SCIPCION]

I got this error after try to move an unit with multiple TA.

debug.log
except.txt
syringe.log

[github-actions]

Nightly build for this pull request:

• compiled-dll-4bdbcf2b33eb409ed9b274cc6944ac4bf92f3aa3.zip
  These artifacts will expire in 90 days and will not be available for download after that time.

This comment is automatic and is meant to allow guests to get latest nightly builds for this pull request without registering. It is updated on every successful build.

[github-actions]

Nightly build for this pull request:

• compiled-dll-8ad2a5f636e5d4432c43b0db6c0f14b712866261.zip
  These artifacts will expire in 90 days and will not be available for download after that time.

This comment is automatic and is meant to allow guests to get latest nightly builds for this pull request without registering. It is updated on every successful build.

[github-actions]

Nightly build for this pull request:

• compiled-dll-1ab4458850688e0254827815e1d637f9dec73d16.zip
  These artifacts will expire in 90 days and will not be available for download after that time.

This comment is automatic and is meant to allow guests to get latest nightly builds for this pull request without registering. It is updated on every successful build.

[github-actions]

Nightly build for this pull request:

• compiled-dll-5ecdf4e023c926f621732d1998a82cceade1fca9.zip
  These artifacts will expire in 90 days and will not be available for download after that time.

This comment is automatic and is meant to allow guests to get latest nightly builds for this pull request without registering. It is updated on every successful build.

[DeathFishAtEase]

Regarding YSortPosition: The current design does not seem to consider the occlusion relationships between multiple AttachmentUnits.

A user tested with the version in issuecomment-3613072028 (the immediately previous) and encountered a problem where when AttachmentUnit and ParentUnit overlap (AttachmentX.FLH=0,0,0), AttachmentUnit will be prioritized for target search while ignoring ParentUnit. This led to him setting an armor on the AttachmentUnit that cannot be attacked (Versus=0%) to use it as a virtual additional weapon, allowing the ParentUnit to swagger into the enemy base without any hindrance.

• Make attached units be transparent for pathfinding and building placement but still targetable and damageable

Another user tested this. The test results are as follows:

• AttachmentUnit, even when using Locomotor={C5D54B98-8C98-4275-8CE4-EF75CB0CBE3E}, only does not affect the Parent Unit's pathfinding when Speed=0, but Speed=0 causes them to be treated as Stationary vehicles and thus prevents automatic Turret direction realignment.
• Additionally, AttachmentUnit still affects the DeploysInto check.
  

He also reported an issue: when the AttachmentUnit is at (0,0,H), it affects units entering the Tank Bunker, and after being pulled by a warhead with IsLocomotor=yes, it is considered during the falling judgment that two entity units exist in the same cell and destroys them.

Moreover, if at the time the attack command is issued, AttachmentUnit cannot attack the target due to range reasons, then even if Parent Unit also has insufficient range but later pursues and approaches the target and successfully initiates a firing action (and at this time the target is also within AttachmentUnit's range), AttachmentUnit still will not respond by synchronously attacking. - Or, as long as AttachmentUnit fails to successfully initiate an attack when the attack command is delivered, it will not respond subsequently.

[mevitar]

Moreover, if at the time the attack command is issued, AttachmentUnit cannot attack the target due to range reasons, then even if Parent Unit also has insufficient range but later pursues and approaches the target and successfully initiates a firing action (and at this time the target is also within AttachmentUnit's range), AttachmentUnit still will not respond by synchronously attacking. - Or, as long as AttachmentUnit fails to successfully initiate an attack when the attack command is delivered, it will not respond subsequently.

Unless the first post has been updated after this, it looks like it's a known issue.

TODO:
Add a flag to force same mission and target to attachments, shouldn't be mixed with commandability

[DeathFishAtEase]

Unless the first post has been updated after this, it looks like it's a known issue.

TODO:
Add a flag to force same mission and target to attachments, shouldn't be mixed with commandability

Well, I misunderstood it as something similar to OpenTopped.AllowFiringIfDeactivated.

[momokama]

BUG:
when [parent] convert to other [techtypes],[DestructionWeapon.Child] will be triggered in an unexpected way.

[NetsuNegi]

I think here can use std::vector instead of ValueableVector

[Metadorius]

@momokama try if the latest build changes anything regarding your issue

[github-actions]

Nightly build for this pull request:

• compiled-dll-9b818263335b126978539e4618d88051edab35fb.zip
  These artifacts will expire in 90 days and will not be available for download after that time.

This comment is automatic and is meant to allow guests to get latest nightly builds for this pull request without registering. It is updated on every successful build.

[github-actions]

Nightly build for this pull request:

• compiled-dll-89c25d2c09bf8543ad013b6d9129ee0d99a22dc4.zip
  These artifacts will expire in 90 days and will not be available for download after that time.

This comment is automatic and is meant to allow guests to get latest nightly builds for this pull request without registering. It is updated on every successful build.