passenrger ejection throw weapon

[T-90]

make the passenger eject (gets out of the transport) throw it's main weapon
the fired weapon will display the projectile and when it hits the ground the
passengers are boosted out of the projectile (think of it like a passenger inside the porjectile). for the warhead a dealy is needed when the porjectile hit's the ground it doesn't blow up instead the warhead will have delay in frames before it blows up. Note the the Damage of the weapon may harm the passenger so it's good to make it zero.

[Graion Dilach (graiondilach)]

Red Alert 3 Bullfrog?

[Krozalid (krozalid)]

Yeah , I think that is what he meant . But we could be wrong .

[Renegade (renegade)]

Yeeeeeeeees...

...could you please re-write that in a way that's actually comprehensible? Thank you.

[YR M0ddEr (yr-m0dder)]

This is how I imagine this would work in YR:

[E1]
CanBeThrownOut=yes
ThrownOut.Image=ZZZZ(linked to artmd.ini)
ThrownOut.Rotate=yes
ThrownOut.RotateFrames= 8 or 32

[BULLFROG]
PipScale=Passengers
Passengers=5
FirePassengers=yes;Cannot fire if there is no passenger with CanBeThrownOut= set to "yes". If there is a passenger with CanBeThrownOut=yes, it will be fired out.

Others:
- passenger that are "flying" can be shot down by AA weapons.
- weapon decide how long the infantry will "fly" and how often to eject passengers, projectile decide how it will travel and if it can go over walls/cliffs.

[Graion Dilach (graiondilach)]

As I understood the original request, the projectile is a shell which holds the passenger and the warhead spawns it.

Which sounds easier to code, however this could be still complicated.

[YR M0ddEr (yr-m0dder)]

^^^ahh, I didnt really get what killer meant, I thought it was RA3 bullfrog.
However this "shell" idea sounds way better than firing out infantry. Easier to code and is more realistic.

[T-90 (t-90)]

ok here is a simpler re-write for Renegade :

the projectile is the transport after it hit's the ground the passenger
gets out of it then after a few seconds or (frames) it blows up.
..................................................................

yes graion dilach the warhead spawnes the passenger and blows up the
projectile that did hit the ground after few seconds.

................................

no krozalid and graion dilach better than the ra3 bull frog.
Because using the weapons projectile is better (And easier to code) than making an infantry turen into a projectile.

...........................................

Eaxmple:
[weapon]
Warhead=Passenger-warhead
Projectile=Passenger-Projectile

[Passenger-warhead]
Delay=200 ; how many frames that the warhead will wait after it takes effect
(blows up) Note : the projectile wont dissapere not until the warhead takes effect (blows up)
Passenger.Eject=( yes/no) ; does it eject passengers (spawns) them

[Passenger-Projectile]
Image=DROPPOD ; this gives us the image as always
Passenger.Transporter=(Yes/NO) ; do i transport passengers fired from the weapon.
Passenger.Transport.Num=2 ; how many passengers do i hold.

[Renegade (renegade)]

That sounds overly complicated and unnecessary.
Why not just use a normal projectile with a fitting MakeInfantry anim?

[WoRmINaToR (worminator)]

He wants a weapon that fires out the passengers of a unit, not a weapon that creates new infantry, thus the need for a slightly more sophisticated system. The issue has some merit, I will admit, but in all honesty this is quite a complicated feature suggestion and I think there ought to be an easier way to go about it...

[Renegade (renegade)]

Well, so far, I see neither community need, support, nor a proper usage case, so all of this is just small talk anyway.
Even if it were the clearest feature request in the world, if there's no reason to implement it, we're not going to waste time on it.

[mevitar (mevitar)]

Chrono Prison, maybe? It would actually make it more useful than it is now (like shooting passengers into the water).

I also think that part of the the UnitDelivery SW's logic could be used for this (in that case there would be no need for additional coding for unit/building placing, and it would save problems with spawning multiple units).

[Renegade (renegade)]

I do not see how either of those logics relates to this.
Why would the Chrono prison shoot passengers into the water (and with what)? And why would we enable this is in such a complicated way?

And why would make a simple unit spawning SW that much more complicated?

[Black Temple Gaurdian (black-temple-gaurdian)]

Isn't there a way to do this already? I vaguely remember something hacky involving buildable cargo planes and tank drops (Non-Patch)

[mevitar (mevitar)]

The reasons for shooting units into the water are the same as using a Magnetron to drag units into the water. As Chrono Prison's logic is used mainly for capturing enemy units, not friendly, the player will want to get rid of them somehow, without making the Chrono Prison an easy target while unloading. And since it uses a beam to capture them, couldn't it use a beam to unload them too (read: make them appear where it shoots)?
I'm just giving a possible usage case for this request, and I believe that if it would be implemented, the Chrono Prison would be the one to benefit from it the most.

And I don't want to expand the UnitDelivery SW or anything like that. I just thought that, since it already does the checking for unit and building placing, and can deliver any type of object (infantry, units, aircrafts and buildings), then using part of its logic here could make this easier to implement, and very versatile from the beginning. The only change would be that, instead of delivering a fixed techno type to the battlefield, it would deliver whatever the transporter would have inside.

[Renegade (renegade)]

If I had a weapon to place the enemy unit wherever I want, and had the intention to kill it, I'd place it inside a cliff, not water.
Soldiers may be able to swim, they won't be able to escape solid rock.

(Well, except for [GHOST], maybe.)

[Renegade (renegade)]

Is this on our pseudo-mental "list of stuff to do"?
If so, somebody set this to "invalid" and update the blueprint.
If not, somebody set this to "won't fix" and the blueprint to "obsolete".

(Alternatively, the original requester can, of course, proactively start whipping the blueprint into shape.)