Question about transports
Moderator: Moderators
Question about transports
Say I made a transport. It could pick up multiple units, lets say 3 units. Each of these unit would be loaded into the transport, and positioned at a certain point. This point is not unit specific, but, for arguments sake just let the first unit be at the front, second in the middle and last at the back. Is this possible? And if it is, can all those units then continue to shoot, build, repair, and stuff? If it is possible, could you provide an example script? Or can units only shoot/build/repair when loaded into a single transport (like the atlas)?
Thanks.
Thanks.
First part: Yes. See implaat in SWTA... wait, actually, I only packed the cobs there, so I'll upload the BOS for you:
http://wormhole.tauniverse.com/spring/implaat.bos
Hrm, it looks like that actually didn't help any, I guess I didn't save it with the properly named variables... Sorry, but I think you can figure it out. Basically, just look at QueryTransport, BeginTransport, and EndTransport and you'll see what's shakin'.
As for the second part: Supposedly. Add "IsAirBase=1;" to the transport's FBI and see if the units then fire out of it. Last time I tried that it made air units try to land on the transport (GEE I WONDER WHY! I TOLD THEM BEFORE THEY IMPLEMENTED IT THAT THEY SHOULD JUST PICK A NEW TAG INSTEAD OF USING THE OTA WORKAROUND WHICH WOULD SURELY CAUSE PROBLEMS LATER) but that was in the 0.6x days so the behavior might work now. I think Arch was working with that stuff a while back, so perhaps ask him how it works.
http://wormhole.tauniverse.com/spring/implaat.bos
Hrm, it looks like that actually didn't help any, I guess I didn't save it with the properly named variables... Sorry, but I think you can figure it out. Basically, just look at QueryTransport, BeginTransport, and EndTransport and you'll see what's shakin'.
As for the second part: Supposedly. Add "IsAirBase=1;" to the transport's FBI and see if the units then fire out of it. Last time I tried that it made air units try to land on the transport (GEE I WONDER WHY! I TOLD THEM BEFORE THEY IMPLEMENTED IT THAT THEY SHOULD JUST PICK A NEW TAG INSTEAD OF USING THE OTA WORKAROUND WHICH WOULD SURELY CAUSE PROBLEMS LATER) but that was in the 0.6x days so the behavior might work now. I think Arch was working with that stuff a while back, so perhaps ask him how it works.
Ok, thanks for that. Theres just one bit I dont understand.
Im guessing this is is called when a unit is about to pick something up, to find where/what to pick it up with, but what do the numbers mean?
Code: Select all
QueryTransport(Func_Var_1)
{
if( Static_Var_3 == 1 )
{
Func_Var_1 = 10;
}
if( Static_Var_3 == 2 )
{
Func_Var_1 = 11;
}
if( Static_Var_3 == 3 )
{
Func_Var_1 = 12;
}
if( Static_Var_3 == 4 )
{
Func_Var_1 = 13;
}
if( Static_Var_3 == 5 )
{
Func_Var_1 = 14;
}
if( Static_Var_3 == 6 )
{
Func_Var_1 = 15;
}
}
I think for some reason scriptor used the order in the "piece" list instead of retaining the piece names. Here:
That's how it works. The "link" pieces are just single vertex points placed where you want the transported unit to show up. It works from the base of the model, IIRC (so, where the link is, that's where the transportee's feet will be), but it might have been the other way around. The base theory makes more sense to me though, since I think the Atlas used a special little formula to account for the unit's height.
Code: Select all
QueryTransport(piecenum)
{
if( units_currently_loaded == 1 )
{
piecenum = link1;
}
if( units_currently_loaded == 2 )
{
piecenum = link2;
}
if( units_currently_loaded == 3 )
{
piecenum = link3;
}
if( units_currently_loaded == 4 )
{
piecenum = link4;
}
if( units_currently_loaded == 5 )
{
piecenum = link5;
}
if( units_currently_loaded == 6 )
{
piecenum = link6;
}
}
Talking about transports, its a good time to mention a tactic using transports with the repeat button.
-# moved to wiki #-
Just thought those of you worried about balance should be aware of this, effective late game ground assaults without using level three units is not out of the question using tactics such as this.
-# moved to wiki #-
Just thought those of you worried about balance should be aware of this, effective late game ground assaults without using level three units is not out of the question using tactics such as this.
Last edited by mecha on 28 Apr 2006, 23:46, edited 2 times in total.
Basically, ground transport go like:
TransportPickup(id_of_unit_to_load)
{
if(get XZ_HYPOT(get UNIT_XZ(id_of_unit_to_load) - get PIECE_XZ(base_piece_of_transport))<=[85])//[85] is the distance at which pickup is allowed. Theorically it could be anything, but Spring is hard coded to have transport not move closer than a certain distance to target, so it's safer to keep that [85]
{
set BUSY to 1;// not sure what it really does, but tradionnal ground/hover/sea transport script have it. My guess would be that it tell the engine to wait before moving the transport and retrying to unload
// here you may have some animation of the transport opening and extending an arm, using some get PIECE_Y, get UNIT_Y, get UNIT_XZ, get PIECE_XZ, get XZ_ATAN, get XZ_HYPOT to get the proper angle and distance
attach-unit id_of_unit_to_load to some_arm_piece_of_the_transport;
// Some more animation of the arm coming back
attach-unit id_of_unit_to_load to 0 - 1;//0 - 1 is a special code telling the transport to "hide" the transported unit.
// Maybe the final part of the animation?
set BUSY to 0;
}//end of the if target in range
}//enf of if TransportPickup
TransportDrop(id_of_unit_to_unload, xz_of_position_to_unload)
{
if( some formula to check if the distance between transport and unload zx position is small enough)
{
set BUSY to 1;
// some opening animation
attach-unit id_of_unit_to_unload to some_arm_piece_of_the_transport;
// animation of arm extending to reach xz_of_position_to_unload
drop-unit id_of_unit_to_unload;
// closing animation
set BUSY to 0;
}//end of the if
}// end of transportdrop function
Ok, maybe that wasn't very helpful, try to look up some the code of some transport. Sadly, the Cavedog script has some needless complication (it calls another function, boomcalc, just to compute the distance, and if you have an uncobbled script instead of a genuine source bos, all those func_var and static_var make it very confusing.
I'd link you to my most advanced transport script, with lots of define to change its behavior and that should be easy to slap on any unit but sadly it's even more complex to read.
As for your question about displaying loaded units on three point of the transport, well, instead of "attach-unit id_of_unit to 0 - 1;", you do a "attach-unit id_of_unit to piece_unit_should_be_hung_on;" Since you want the transport to load three units and hang them on three piece, I guess you should have a static-var, initialised to 0 in the create, decreased in transportdrop(..), increased in transportpickup(..), and then some "if" on that var to select where to attach it.
I aren't sure that was really helpful. Do you already have the unit you want such transport script to be mounted on?
TransportPickup(id_of_unit_to_load)
{
if(get XZ_HYPOT(get UNIT_XZ(id_of_unit_to_load) - get PIECE_XZ(base_piece_of_transport))<=[85])//[85] is the distance at which pickup is allowed. Theorically it could be anything, but Spring is hard coded to have transport not move closer than a certain distance to target, so it's safer to keep that [85]
{
set BUSY to 1;// not sure what it really does, but tradionnal ground/hover/sea transport script have it. My guess would be that it tell the engine to wait before moving the transport and retrying to unload
// here you may have some animation of the transport opening and extending an arm, using some get PIECE_Y, get UNIT_Y, get UNIT_XZ, get PIECE_XZ, get XZ_ATAN, get XZ_HYPOT to get the proper angle and distance
attach-unit id_of_unit_to_load to some_arm_piece_of_the_transport;
// Some more animation of the arm coming back
attach-unit id_of_unit_to_load to 0 - 1;//0 - 1 is a special code telling the transport to "hide" the transported unit.
// Maybe the final part of the animation?
set BUSY to 0;
}//end of the if target in range
}//enf of if TransportPickup
TransportDrop(id_of_unit_to_unload, xz_of_position_to_unload)
{
if( some formula to check if the distance between transport and unload zx position is small enough)
{
set BUSY to 1;
// some opening animation
attach-unit id_of_unit_to_unload to some_arm_piece_of_the_transport;
// animation of arm extending to reach xz_of_position_to_unload
drop-unit id_of_unit_to_unload;
// closing animation
set BUSY to 0;
}//end of the if
}// end of transportdrop function
Ok, maybe that wasn't very helpful, try to look up some the code of some transport. Sadly, the Cavedog script has some needless complication (it calls another function, boomcalc, just to compute the distance, and if you have an uncobbled script instead of a genuine source bos, all those func_var and static_var make it very confusing.
I'd link you to my most advanced transport script, with lots of define to change its behavior and that should be easy to slap on any unit but sadly it's even more complex to read.
As for your question about displaying loaded units on three point of the transport, well, instead of "attach-unit id_of_unit to 0 - 1;", you do a "attach-unit id_of_unit to piece_unit_should_be_hung_on;" Since you want the transport to load three units and hang them on three piece, I guess you should have a static-var, initialised to 0 in the create, decreased in transportdrop(..), increased in transportpickup(..), and then some "if" on that var to select where to attach it.
I aren't sure that was really helpful. Do you already have the unit you want such transport script to be mounted on?
Ok, done:
Here is a modified FatShrew (big six legged spider steampunk thing) that can load up to seven units, place them on seven location on its back, and let them fire from there. Look at the TransportPickup(id) and the TransportDrop(id,xz) at the start of the script to see how it's done. I wrote a nice simplified short commented script so it's readable.
FatShrew_with_seven_baskets_for_Maelstrom.ufo
It'd better be useful to you, or I'll send angry ninja chinchilla to bite you in your sleep!
Here is a modified FatShrew (big six legged spider steampunk thing) that can load up to seven units, place them on seven location on its back, and let them fire from there. Look at the TransportPickup(id) and the TransportDrop(id,xz) at the start of the script to see how it's done. I wrote a nice simplified short commented script so it's readable.
FatShrew_with_seven_baskets_for_Maelstrom.ufo
It'd better be useful to you, or I'll send angry ninja chinchilla to bite you in your sleep!
- centurion-1
- Posts: 169
- Joined: 31 Jan 2006, 20:53
Invisible troops aren't effectively there though, are they? I mean, jammers don't jam, lasers don't fire, etc.zwzsg wrote:The same way?
Or if you want the troops inside to be invible, attach to 0 - 1 instead of attaching to a piece.
I'm also curious about damage. How does damage to the carrier effect the carryee?
I'm not a modder (yet) just curious for future plans.
This isn't true in the case of transports with isairbase=1;, it should be notedGnome wrote:Don't know about jammers, but I don't see why the attachment point would affect a unit's ability to fire (assuming the transport allows it, as explained above), unless it was below ground or something.
I've never seen carried units get damage, always just the transport itself.