Multiple Transport mas distribution

[AF]

-Added new FBI tag TransportMass, this is the maximum weight a tranporter can transport, default 100000
-Added new FBI tag Mass, this is the weight of the unit, default is metalcost of unit
-Added new FBI tags to set the control variables for aircrafts
-Added new FBI tag OnlyTargetCategory<weaponnum>, sort of like badtargetcategory but the weapon can only target units with these categories,toairweapon in weaponfile is the same as OnlyTargetCategory=VTOL; default is all categories

Taken from the CVS changelog for the next version. I propose a second type of transport be usable. For example instead of taking the unit and sticking ti inside the transporter or on it's underbelly, perhaps for those types of transports that use tethers, like helicopters, that way if a transport cant carry the laod because it's too heavy then maybe 2 transports can carry it at once sharing the load? In this i envisage the transporter holding the transportee at the end of the tether at it's maximum distance, increasing it's max speed to the max speed of the slowest transporter. Thus this could be applied to mor than just air transporters, for example tugs dragging a slow moving battleship or a small floating object such as a metal maker.

[[K.B.] Napalm Cobra]

I'd rather see platform/baseplate based transporting, think opening scene of saving private ryan.

[Gnomre]

I think mass will work well.

Please, let us read the target unit's mass from the script when picking a unit up for transport, so we can tell exactly which unit it is...

[GrOuNd_ZeRo]

where can I find this CVS changelog?

[FLOZi]

I think mass will work well.

Please, let us read the target unit's mass from the script when picking a unit up for transport, so we can tell exactly which unit it is...

indeed, these are excellent FBI additions, but this script addition would really allow us to do prety much anything we please.

[GrOuNd_ZeRo]

yes very true, what about a minimum mass? so we could have a more distinct range? like for ammo and such?

[Gnomre]

Yeah, that could be good for when users use transports as ferries... make the transport do exactly as told if the user is telling it to load and then move, but if the user put it on load-unload-repeat, it could wait until it's filled up enough and then fly off... oh, how about two more tags: that minimum mass one, and a max wait time so it will still do the transport in case of an infinite delay or something.

[SJ]

http://cvs.sourceforge.net/viewcvs.py/s ... iew=markup

Ok i will nag fnord about adding mass to the scripts. The transports already pick up everything they can from the load area, having them wait for more just seems like an unnecessary complication.

[Gnomre]

Well, I mean, you wouldn't want a transport that can take 20 units wandering off across the map with one unit, when there are 10 others very nearby to the pickup point but not quite there yet... it'd be nice to have them automatically delay a little to pick up any stragglers if they aren't anywhere near full.

[IMSabbel]

with the introduction of the "mass" tag, itsnt the crushing strenght depricated?

because crushing strenght should be a derivate of mass and velocity (or acceleration, when starting from a stand)

[FLOZi]

I agree.

And:

Added new FBI tag OnlyTargetCategory<weaponnum>, sort of like badtargetcategory but the weapon can only target units with these categories,toairweapon in weaponfile is the same as OnlyTargetCategory=VTOL; default is all categories

This is most excellent!
Now i just need a reliable way of scripting weapons so no matter which fires there is always the same reload time until the next one.

[AF]

The transports already pick up everything they can from the load area, having them wait for more just seems like an unnecessary complication.

The point was that if every transporter has a maximum weight then uber heavy untis cant be transported, and I suggested transports have the otpion to use a tether such as perhaps a single krogoth thats too heavy for one transport could be tethered between two or three.

But people seme interested in other thigns....

[Dragon45]

Does anyone remember my idea from waaaay back about being able to add any number of FBI tags you wanted? The "metatags" would just be metadata lines called METADATA1 or soemthing... i think a lot of the requests revolve around just any sort of additional tags and being able to add metadata tags to the FBI would really alleviate a lot of concerns.

[Min3mat]

lol right after AF's post about ppl being interested in different things lol

[jcnossen]

Does anyone remember my idea from waaaay back about being able to add any number of FBI tags you wanted? The "metatags" would just be metadata lines called METADATA1 or soemthing... i think a lot of the requests revolve around just any sort of additional tags and being able to add metadata tags to the FBI would really alleviate a lot of concerns.

Explain this please, you still need C++ code to actually use the tags.

[zwzsg]

I think mass will work well.

Please, let us read the target unit's mass from the script when picking a unit up for transport, so we can tell exactly which unit it is...

There's so many things that I'd like the scripts to read that I think it's better to wait for a new script format and hope it will support reading everything. Besides, knowing what the unit is by reading its height works fine. (If you have my height reading unit, that is.)

[Gnomre]

Yeah, but it'd be simpler to call the mass, and you could guarantee the mass for each unit to be different yourself, rather than running into problems with units that have the same heights (remember your fun issues with the droid deactivation?).

[Dragon45]

Well lets say the current .fbi file type has a bunch of arbitrary tags that are intrepreted by the game and the script. The values are used because they are needed by the unit maker in some way.

Code: Select all

MoveRate=;
MetalCost=; 

etc etc

These dont really mean anyting except in the context in which they are used; I could rename "MaxHealth" to "Booger" and just have the game say that the "Booger" value is what should be used to determine the unit's hit points.


Similarly following, you could have a number of arbitrary metadata tags that could be interpreted by a script through the current SET / GET interface. Lets say that the SunParser was set to read the following values from a unit's .fbi file.

Code: Select all

Metadata1=;
Metadata2=;
Metadata3=;
Metadata4=;
etc

And then intrepret it through the script like this:

Code: Select all

var MAX_AMMO = GET METADATA1;
var WEIGHT = GET METADATA2;
var MAX_REHEAT_TIME = GET METADATA3;

The unitmaker would simply interepet the Metadata1 value as maximum ammo, Metadata2 as weight, etc and then use those values in the script accordingly. It would provide crazy flexibility to the unitmakers and eliminate almost every request for additional FBI tags since you could basically define your tag as whatever you wanted to be.

[jcnossen]

But then again, why would you need that?
Since every unit has it's own script, you can just as well define these values in script instead of in the fbi file.
Things like this will probably be very easy in a normal script language, I'd say just wait for that.

[Dragon45]

Well, in theory, you could have like *everything* just be a bunch of vars in the script and then deal with them accordingly


I know what you're saying though, and I agree, it just may suffice as a stopgap solution until a proper LUA implementation is made. After all, what are TransportMass and Mass except for metadata with specific purposes coded in the engine?