Vehicle Deployment Enhancement

[Fly-Star-him]

• Fixed an issue where miners affected by Passengers/DeployFire were unable to unload minerals.
• Fixed an issue where mining vehicles could not move after leaving a tank bunker.

---

• When a vehicle has Passengers and possesses DeployFire/IsSimpleDeployer/DeploysInto, it can perform custom deployment actions beyond merely releasing passengers.
  • Deploy.SkipPassengerUnload allows vehicles to bypass the passenger release process and perform other deployment actions.
  • Deploy.NoPassenger allows vehicles to perform other deployment actions after losing all passengers.
• Harvester can now perform other deployment operations. Can't deploy when it's unloading minerals.
  • Deploy.NoTiberium controls whether the deployment actions can only be performed when the harvester carries no mineral. If set to false, the harvester can deploy regardless of carrying minerals or not.

In rulesmd.ini:

[SOMEVEHICLE]                       ; VehicleType
Deploy.SkipPassengerUnload=false    ; boolean
Deploy.NoPassenger=false            ; boolean
Deploy.NoTiberium=false             ; boolean

[github-actions]

Nightly build for this pull request:

• compiled-dll-d696ed8397ecf62515da00fa2c1e888bf01cf08e.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.

[TaranDahl]

I think it would be best to reorganize WW's Unloading shit into multiple independent Unloading behaviors, and then use flags to control which ones are enabled and which ones are disabled.

[KuroNoSeiHai]

I have tested. It works well.

[TaranDahl]

I think it would be best to reorganize WW's Unloading shit into multiple independent Unloading behaviors, and then use flags to control which ones are enabled and which ones are disabled.

@Fly-Star-him Are you going to finish these, or are you just going to leave them as they are? This is just a suggestion.

[Fly-Star-him]

I think it would be best to reorganize WW's Unloading shit into multiple independent Unloading behaviors, and then use flags to control which ones are enabled and which ones are disabled.

@Fly-Star-him Are you going to finish these, or are you just going to leave them as they are? This is just a suggestion.

Maybe it's possible, but I still don't know what to do.

[TaranDahl]

I am thinking something like this:

• Unload.AllowedBehaviors determines which behaviors are available. Behaviors not listed will be disabled.
• Unload.AutoFallback determines whether to attempt to use other behaviors when a particular behavior is unavailable or meaningless.
  • Note: The order of attempts to deploy behaviors is hardcoded.

[SomeUnit]
Unload.AllowedBehaviors=All ; List of vehicle unloading behavior enum (All/DeployFire/IsSimpleDeployer/Harvester/DeploysInto/Passengers)
Unload.AutoFallback=false ; boolean

Perhaps a similar thing is also needed for buildings, but here we can only consider vehicles.

[Fly-Star-him]

Perhaps a similar thing is also needed for buildings, but here we can only consider vehicles.

Are you referring to replacing DeployFire=yes, IsSimpleDeployer=yes, DeploysInto= these?

[TaranDahl]

Are you referring to replacing DeployFire=yes, IsSimpleDeployer=yes, DeploysInto= these?

No.
I would like to say that there are many unloading behaviors here. In the Vanilla case, some behaviors can prevent other behaviors from taking effect (for example, DeployFire can prevent Harvester from taking effect, and IsSimpleDeployer can prevent DeployFire from taking effect). I think the ideal situation should be that they take effect simultaneously, or be checked and take effect in a certain order. In short, it's not good for them to prevent each other.

[Fryone]

Suggestion: I thought about one feature for harvesters - "Deploy to Return". Or maybe other missions too?