Currently, if a transporter dead, no matter what the cargo is, it would take the same amount of damage from explosion and falling, I think it makes heavier units too much more worth for transporting than lighter units, so is it possible to make all kinds of cargos lose the same percentage of hp when its transporter get killed? If you can't change the falling mechanism (although I think lighter units take less damage from falling make sense and won't break the balance), then how about make the heavier units take more damage from transporter explosion, to get a compensatory equality?
+0 / -0
|
|
|
It wasn't totally right(explosion damage is a constant, while the falling damage is not), but the problem is still there Use a valk to load a zeus, self-d, cargo hp = 87% Use a valk to load a rocko, self-d, cargo hp = 56% Use a valk to load a bandit, self-d, cargo hp = 10% See? If your valk get shot down, a lighter cargo would be in a much worse situation than a heavier cargo.
+0 / -0
|
Zeus is assault so of course it has more HP for cost. In my test a Penetrator went to 50% health. Big unit also take less damage because they have less distance to fall if the transport drops them. Anyway fall damage is entirely lua. Did you want to change the equation? Damage currently scales linearly with mass.
+0 / -0
|
No, I think maybe we should keep the fall damage same but remove the explosion damage completely, I don't see much reason to have it, it makes light units unworthy for transporting and isn't much of a punishment to heavy cargos.
+0 / -0
|
In general, the thing about transports is that you want to be transporting as-close-to-max-as-possible. After all, transporting lighter units is a waste of the transport. If it can carry a 500 metal unit, then you want to avoid carrying a 50-metal unit or the transport is being underutilitized. qwerty's complaint is about a feature that makes the above issue even worse.
+0 / -0
|
I think perhaps there is a solution for the problem that pxtl mentioned-----make the cargo mass slow down the transporter proportionally. Or maybe not mass, but metal cost, unit mass in zero-k isn't proportional with unit weight anyway. Same for the fall damage after I reconsidered.
+0 / -0
|
quote:
In general, the thing about transports is that you want to be transporting as-close-to-max-as-possible. After all, transporting lighter units is a waste of the transport. If it can carry a 500 metal unit, then you want to avoid carrying a 50-metal unit or the transport is being underutilitized. |
Exactly this. In an ideal world I think transports should transport potentially multiple units based on mass or footprint, so you would have a choice between transporting ~8 glaives or ~2 zeus. I know it's technically possible in spring but requires a reasonable transport model, and who knows what kind of silly bugs or behaviour spring has when trying to load the units in the transport.
+0 / -0
|
Advanced air transporters in BA can transport 30 fleas or 15 warriors or 10 bulldogs, but sill aren't ideal, because loading/unloading so many units is too slow, your transport would be killed with its cargos before the unloading is complete. It might be better if the air transporters drop cargos like bombs (without fall damage), but this would need some complex lua scirpts.
+0 / -0
|
Another idea: Make valkyrie smaller and more spammy, and give it 3 or 4 levels to morph, each morph make its model bigger, give it more hp, and make it be able to transport heavier units. Same for surfboard.
+0 / -0
|
I'd take the reverse approach, but it would require raising transport flyheight: ZK uses networks. Overdrive networks, shield networks, and in a certain sense we have a buildpower-network, although we don't call it that. So make a transport network. An individual transport can carry an obscenely heavy unit, but it's functionally immobile carrying it. However, transports can magnetically connect to each-other with a shield-link-like behavior to add transport capacity to the network of transports, allowing them to increase in speed exponentially (up to their maximum). Idle transports automatically cluster near active transports, ensuring the network effect happens. The hard part would be unit-AI to make sure they behave in a sensible manner.
+0 / -0
|
That's a incredible creative idea! But then enemy would try to destory the transporters with the heaviest cargos first and ignores the empty ones, so I think they should have linkable shields too, or even linkable hp. Or when a transporter dead, its cargo would be teleported to the nearest empty transporter in the same network, but this would be hard to lua.
+0 / -0
|
No, all these suggestions are way more complex than the current system, which is already too complex to use. Transporting multiple units might work, but with a single attachment point, they all explode with huge impulse if they're released from the transport. We can add multiple attachment points, but someone needs to script this (It's bos/cob so someone is me I guess). Do you know how much time all these feature requests take? You guys should just learn to script or model or wherever your skill base lies (It's really not that hard) and throw your effort in if you want to see something done. I might get around to this eventually but transports are such a marginal, underused feature that this is not a priority.
+0 / -0
|
I'm more worried about getting Transport AI to play with multi-transporters.
+0 / -0
|
transports that drop their passengers like bombs (parachute) are already in engine, use transportUnloadMethode=1 (or similiar) transporters with multiple attach points for passenger like this:  are easy: keep track of passengers and return different pieces in script.QueryTransport
+0 / -0
|
Well, my last idea: Replace the air transporters with a air teleporter-transporter, it should be able to bind itself to multiple friendly units with a limited summation of weight, then fly to destination and teleport them to the ground below, the binding would be removed after teleporting. If it get killed, the units it connect with would be automatic teleported. It works similar to a multiple units air transporter, except you don't need to make it very big to have many attach points to transport many units, and it can be used for rapid retreatment. If rapid retreatment would break the balance, then make the binded units unmovable.
+0 / -0
|
quote:
are easy: keep track of passengers and return different pieces in script.QueryTransport |
i request a bug in the 1st version, each loaded unit gets free auto morph when unloading, depending on the flight time/range!
+0 / -0
|
aren't loaded units stunned? (Except for surfboat)
+0 / -0
|
multiple unit transports work fine except that when unloading units sometimes the transport will stop dropping units (as it drops them in a line along the radius of the unload circle) and loading/unloading is very slow as it only loads/unloads one unit at a time. I think it wouldn't be too bad to include multi-transport in the heavy transport as-is. Sure it might not be ideal multi-transport behavior, but it works.
+0 / -0
|
The transport just needs a mostly flat area, go down to a specific altitude and unloads the units instantly. If every number is well calculated, the units will not fall more than a few elmos. To pickup units, let them walk directly below the transporter's slots, move the transporter to a defined position and facing and insta-load, relocate units per script. (like SupCom-TA does with the Terran T3 transport) Finally there is always a possibility of short-range teleporting divices for >1000m units.
+0 / -0
|
