[beng]

About the method for making an object which has GrantUpgradeCreate via an OCL: the intermediate object must use SpawnBehavior and not ReplaceObjectUpgrade since to use ReplaceObjectUpgrade you need to also use GrantUpgradeCreate, which will not work since the intermediate object was created by OCL.

[beng]

Correction:
The behavior of GrantUpgradeCreate behavior with OCLed objects is the same as for Spawned objects.

That is, for GrantUpgradeCreate to work in an object that was made by OCL, you MUST HAVE the line that says:
ExemptStatus = UNDER_CONSTRUCTION.

I thought it didn't work because of a different bug: the minefield appearing at map origin bug. When an object with a GenerateMinefield behavior gives itself a minefield via GrantUpgradeCreate, or by somehow having the upgrade pre-purchased (like China buildings that you place in WorldBuilder), the minefield appears at 0,0 (bottom left corner of map) instead of around the object.

However, if you do not have ExemptStatus = UNDER_CONSTRUCTION in the GrantUpgradeCreate module, you won't get any minefield at all, not even in the wrong place.

[Mere_Mortal]

Originally Posted by beng

Example: if you make your GLA command center spawn a radar van, the radar will be off unless you add ExemptStatus = UNDER_CONSTRUCTION to the GrantUpgradeCreate module in the radar van.

OMG, to think that after all these years I never knew that! I always thought that GrantUpgradeCreate just plain & simply doesn't work when an object is spawned, basically because it is not created. This will prove to be extremely useful.

[beng]

How ScatterTarget works




The image above shows the results of Su-25s dropping sticks of 8 bombs on a target area in a test map. The red arrow shows the direction from which the planes come. The Su-25 in the picture has just droped it's stick of bombs and has turned around to RTB.

The weapon.ini settings for the bomb dropping weapon was:

  ScatterRadius           = 0;changed to zero, unless you want to soften the results of the table below

; Instead of a purely random scatter distance, this will divide a clip evenly and randomly at these spots
; With fewer entries than ClipSize, the extra will hit 0,0 as normal shots
; With extra entries, 8 of 12 could be used eg, and then you'd get a different 8 next clip.

  ScatterTargetScalar = 60;replaces the ScatterRadius, above, for scaling this table, below

  ScatterTarget     = X: -0.900  Y: 0.05  ;left outer pylon first to drop
  ScatterTarget     = X: -0.643  Y: -0.04
  ScatterTarget     = X: -0.386  Y: 0.03
  ScatterTarget     = X: -0.129  Y: -0.02
  ScatterTarget     = X: 0.129   Y: 0.02
  ScatterTarget     = X: 0.386   Y: -0.03
  ScatterTarget     = X: 0.643   Y: 0.04
  ScatterTarget     = X: 0.900   Y: -0.05 ;right outer pylon is last to drop

I was trying to get a carpet bomb effect where the bombs drop in a line along the plane's flight path, but this is not what i got.

ScatterTarget works according to map/world coordinates, and is not related to the orientation of the object firing the weapon. Thus, instead of the bombs falling in line with the plane's flight path, they fell in a line perpendicular to the flight path, because the planes were flying parrallel to the Y axis and not the X axis of the map. Hence the lines of scorch marks perpendicular to the planes' ingress paths.

For more of my ini editing discoveries, see:
ini editing discoveries and tips for Generals & ZH - CnCMaps Map Editing Forums

[n5p29]

A unit with RiderContain can be produced without a rider. In this state its status become NONE. When produced riderless object will not die/toppled, but when you put a rider in it and remove the rider it will die. Another thing is when you fill its InitialPayload and make it change the rider via PLAYER_UPGRADE, the initial rider will not disappeared but both rider will contained inside the object! For the object's states (weapons, model, loco) will follow the most smallest rider number. For example if you make GLA Bike loads tunnel defender when produced via player upgrade, the result is the bike still possess the rebel weapon and model (except you put condition like RIDER1 RIDER2 or something) and when scuttled two riders will shown up.

[beng]

Yes i found the same thing with my Su-25 plane, which uses RiderChangeContain. The funny thing is, when you make an infantry enter it, it will immediately take off from the airfield and eject the infantry and then crash. The way to stop it doing that is to give it a move command to make it go somewhere, when it starts to do that. Then it will forget what it was about to do and not eject the rider(s) and scuttle itself.

Also, if you put another rider in, the previous one stays inside and does not come out. You can keep putting a lot of infantry in and then scuttle it and they all come out. As you said, putting another rider in does not change it's weapon or commandsets.

I also tried producing it with a rider alredy inside, but still cound not chnage the rider as the old one cannot come out while the plane is in the airfield, and once it takes off you cannot exit just one rider. All will come out.

[Mere_Mortal]

I'm not so sure it has anything to do with the passenger, I believe it is more to do with the locomotor. That is, when the aircraft takes off, it is using the wrong locomotor and therefore crashes. I might be wrong, but that's how I saw it when I was using this method to give an aircraft two different weapons (trouble was, switching between weapons whilst in air meant it could fire twice and also prevented the aircraft from returning to base if it still had ammo). Also, I encountered the problem whereby issuing the weapon switch command (which was actually an upgrade) forced the aircraft to leave the airfield. Annoying, huh?

Now, you CAN remove passengers and there's a very sneaky way to do it. It's not much use for real objects such as infantry and vehicles because it forcibly kills them, but it is useful for upgrades. But it DOES change the weapon as per whichever rider has been used. I'll try to explain it as best I can with a quick example...

In the object that has the RiderChangeContain module...

  Behavior = ObjectCreationUpgrade Upgrade1
    UpgradeObject        = OCL_RiderChange_1
    TriggeredBy          = DummyObjectUpgrade1
  End

The corresponding OCL for this entry...

ObjectCreationList OCL_RiderChange_1
  CreateObject
    ObjectNames      = UpgradeRemover_1
    ContainInsideSourceObject = No
  End
  CreateObject
    ObjectNames      = WeaponRider_1
    ContainInsideSourceObject = Yes
  End
End

The corresponding objects for this OCL...

Object UpgradeRemover_1
  KindOf                 = PORTABLE_STRUCTURE
  EditorSorting          = SYSTEM
  Body = ActiveBody Body
    MaxHealth            = 1
    InitialHealth        = 1
  End
  Behavior = UpgradeDie Upgrade2
    UpgradeToRemove      = DummyObjectUpgrade2
  End
  Behavior = UpgradeDie Upgrade3
    UpgradeToRemove      = DummyObjectUpgrade3
  End
  Behavior = UpgradeDie Upgrade4
    UpgradeToRemove      = DummyObjectUpgrade4
  End
  Behavior = PhysicsBehavior Physics
    Mass                    = 1
    KillWhenRestingOnGround = Yes
  End
End

Object WeaponRider_1
  KindOf                 = PORTABLE_STRUCTURE
  EditorSorting          = SYSTEM
  TransportSlotCount     = 1
  Body = ActiveBody Body
    MaxHealth            = 1
    InitialHealth        = 1
  End
  Behavior = AIUpdateInterface AI
  End
  Behavior = LifetimeUpdate Lifetime
    MinLifetime          = 1
    MaxLifetime          = 1
  End
End

The upgrade remover is basically to allow switching between different riders without actually using up the upgrade.

The trick here, at least so far as I see it, is the very fact that the previous passengers ARE evicted to an extent. Thus, if we include a LifetimeUpdate, it is removed upon expiry once a new rider has taken its place.

If the idea is based around real objects that you don't want to be destroyed, well I don't think there's any way to force them out of their container without issuing the evacuate command or otherwise killing them or its container. On the other hand, I do have an idea that I'll look into.

[beng]

It is not the locomotor, the aircraft does use the right locomotor to take off, otherwise if would not take off but stay moving on the ground. It takes off, then the rider exits, then the aircraft scuttles because of the exit. If you tell it to move somewhere before it finishes taking off then the rider will not exit.

Another way to remove upgrades that does not need you to make an upgrade remover object is to use commandset upgrade (see GLA worker).

Also, does your method actually work? I mean when you put the new object into the container via the OCL, does it change the contaner's status, weaponset, locomotor etc? Or does it keep using the one from the existing rider?

And lifetime update does not affect contained objects. They will only die when they exit the container.

[Mere_Mortal]

Originally Posted by beng

It is not the locomotor, the aircraft does use the right locomotor to take off, otherwise if would not take off but stay moving on the ground. It takes off, then the rider exits, then the aircraft scuttles because of the exit. If you tell it to move somewhere before it finishes taking off then the rider will not exit.

Fair enough, I'll take your word on that. But it broke my idea because I wanted the aircraft to be able to switch weapons only when docked, not in the air, else the problem arises where it has two rounds of different ammo and if one is unused, it cannot automatically switch so it'll just circle the target or, if the AI can switch weapons, it'll make two passes which is usually extremely dangerous. Either way it'll probably wind up dead.

Also, does your method actually work? I mean when you put the new object into the container via the OCL, does it change the container's status, weaponset, locomotor etc? Or does it keep using the one from the existing rider?

And lifetime update does not affect contained objects. They will only die when they exit the container.

Whilst I don't fully understand or remember the containment aspects of it (ie, whether or not the previous passenger does actually leave the container), it certainly does work. The LifetimeUpdate is critical, without such it would not work because the rider change cannot happen until that passenger is gone, this basically forces it to die.

[beng]

But in your code you put the lifetime update not in the upgrade removing object but in the WeaponRider_1 object that is contained in the vehicle. And objects cannot die with lifetime update while they are contained, only when they are not contained.

As for the problem with the weapons recharging in the air, i guess you have to workaround by manually stopping the aircraft (select and press S) so that it returns to the airfield.

The workaround for the ejecting rider behaviour is also manual: select and stop or select and give a move command, before the aircraft takes off after a new rider enters it.

As for the existing rider, it never comes out because the new rider enters the plane while it is on the airfield, and infantry cannot walk on airfields except to enter planes. I can put in as many infantry as i like, they all fit inside, and they all come out together if i issue an exit vehicle command, resulting in the aircraft scuttling. I think the solution is to find a way to let infantry walk on airfields, maybe by making the airfield work like a bridge or something.