Attack on Trinity: Expanding weapons size classes

For collaboration on developing the mod capabilities of VS; request new features, report bugs, or suggest improvements

Moderator: Mod Contributor

chuck_starchaser
Elite
Elite
Posts: 8014
Joined: Fri Sep 05, 2003 4:03 am
Location: Montreal
Contact:

Attack on Trinity: Expanding weapons size classes

Post by chuck_starchaser »

Is there a way to get around the Holy Trinity of Light, Medium and Heavy everything?

In WC, there are, for example, turret sizes that go from about 1.5 meters diameter at the base, up to I think about 30-40 meter diameter turrets for cruisers and dreadnoughts. If we chose doubling sizes for our size classes we'd have about 6 size classes.
This is even more so with guns, which start at less than a meter long and end at like 2 kilometers long (Behemoth).
Right now PU is misusing size classes for weapons, in the sense that we are using size classes for mounts where they don't really belong. But even if we put all our current weapons in a "light" category, where they rightly belong by size, we'll be limited to 3 ship size classes.
There's no plans, currently, of having Burrows own the TCS Lexington, but it would be nice to address this as early as possible, for the sake of cleanliness and organization.
Deus Siddis
Elite
Elite
Posts: 1363
Joined: Sat Aug 04, 2007 3:42 pm

Post by Deus Siddis »

This seems like it would be really important for all mods, in no small part vega strike itself with its huge range of scale.
chuck_starchaser
Elite
Elite
Posts: 8014
Joined: Fri Sep 05, 2003 4:03 am
Location: Montreal
Contact:

Post by chuck_starchaser »

And I have a second, related question:
I've asked it before, and I don't remember the answer; but I do remember it didn't help much. We want to get rid of weapon size categories in the upgrades menu, for the time being, since we ONLY have small of everything. How do we do that?
Well, technically we do have light, medium and heavy weapons, but that is erroneous.
I suppose if we change all weapons to be small, the medium and heavy folders will automatically disappear; but is there any way to get rid of the "light" category folder?
ace123
Lead Network Developer
Lead Network Developer
Posts: 2560
Joined: Sun Jan 12, 2003 9:13 am
Location: Palo Alto CA
Contact:

Post by ace123 »

I think the category folders are not the same as the built-in names
Check the master_part_list.csv and you should be able to take out the "upgrades/Mounts/Light" to be "upgrades/Mounts"

Removing it from the description screen is much harder.
chuck_starchaser
Elite
Elite
Posts: 8014
Joined: Fri Sep 05, 2003 4:03 am
Location: Montreal
Contact:

Post by chuck_starchaser »

It seems we have a somewhat different format...
I don't see any upgrades/Mounts/Light in master parts list... Let's see, the guns are, for example,

Mass Driver: upgrades/Weapons/Mounted_Guns_Light
Neutron: upgrades/Weapons/Mounted_Guns_Medium
Plasma: upgrades/Weapons/Mounted_Guns_Heavy
Tachion: upgrades/Weapons/Mounted_Guns_Confed_Milspec

These guns have widely different specs in terms of power draw and effectiveness, to be sure; but in terms of size (and size of the mount), they are all "Civilian Light" (or should be).

So, for example, the Broadsword has 3 mass drivers, but there's no comparison between the size and power of a mass driver on a broadsword and the kind of tiny mass driver you find on a civilian tin can. So, that's where size categories should come in: There needs to be a Milspec Medium Mass Driver that would fit a broadsword. as well as a Civilian Medium Mass Driver that fits a Privateer Drayman, whereas the two Mass Drivers you find on a Raptor would be in the Milspec Light Mass Driver category. Milspec Light would be larger than Civilian Light, but smaller than Civilian Medium, sort of thing. For another example, the lasers on a Hornet are like 3 meters long; no comparison with civilian lasers in privateer.
But so, everything that fits fighters would be "light"; stuff that fits bombers would be medium; stuff that fits corvettes would be "heavy"; and here I'm in trouble: The trinity ends, but the size categories continue: destroyer size class, frigate size class, cruiser size class, dreadnaught size class...

Maybe those would be better category names than lite/med/hvy:

fighter
bomber
corvette
destroyer
frigate
cruiser
dreadnought


Anyways, the question is, is the "category" column what actually shows on the upgrades interface?
If so I'll just change them all to,
upgrades/Weapons/Guns for now, and later re-introduce size class categories (once we HAVE medium and heavy guns; we don't yet).
But the second question is, what controls what guns are allowed in what mounts? What will prevent me from putting four cruiser guns on a centurion, --besides the loss of visibility? :D
chuck_starchaser
Elite
Elite
Posts: 8014
Joined: Fri Sep 05, 2003 4:03 am
Location: Montreal
Contact:

Post by chuck_starchaser »

I changed all the guns to upgrades/Weapons/Guns, and the are no guns available anymore at the upgrades; however on the selling side of the screen, my guns appear under a Guns category. I suppose this means I have to rename the gun categories in the lists of items sold at each base in units.csv, I suppose?
And the other question still remains: is this "category" what defines the compatibility of a weapon and a weapon mount? Or is that somewhere else?
Sindwiller
Merchant
Merchant
Posts: 32
Joined: Sun Aug 10, 2008 10:31 pm
Location: Zürich, Switzerland

Post by Sindwiller »

How about being able to define the different sizes/classes in Python... :P
jackS
Minister of Information
Minister of Information
Posts: 1895
Joined: Fri Jan 31, 2003 9:40 pm
Location: The land of tenure (and diaper changes)

Post by jackS »

The category does not define the compatibility of a weapon and a mount.

The size of a weapon is determined in the weapon_list.xml file.
That size of that weapon as specified in weapon_list.xml must then match exactly(case insensitive) one of the list of compatible sizes specified in the mount declaration. The list of compatible sizes (and autotracking property) is currently turned into a bit vector, the possible values of which are currently defined as follows

Code: Select all

enum MOUNT_SIZE {NOWEAP=0x0,LIGHT=0x1,MEDIUM=0x2,HEAVY=0x4,CAPSHIPLIGHT=0x8,CAPSHIPHEAVY=0x10,SPECIAL=0x20, LIGHTMISSILE=0x40,MEDIUMMISSILE=0x80,HEAVYMISSILE=0x100,CAPSHIPLIGHTMISSILE=0x200, CAPSHIPHEAVYMISSILE=0x400,SPECIALMISSILE=0x800, AUTOTRACKING=0x1000} size;
and then masking is used to determine compatibility. Thus, a mount defined only as "HEAVY" cannot mount a LIGHT weapon or a MEDIUM weapon, whereas a mount defined as "LIGHT MEDIUM HEAVY" can mount any of the three.

While changing the set of mount sizes available does require more than just editing this enum (need corresponding string->enum and enum->string conversions for anything added so as to allow loading and saving/displaying, respectively) it's still pretty easy to accomplish.

I've pondered changing this myself to add some civilian categories, but if you'd like to take a crack at coming up with a proposal for a better set of categories (limiting factor being bit vector assumed to be 32 bits long for forseable future) I'd welcome starting such a discussion.
chuck_starchaser
Elite
Elite
Posts: 8014
Joined: Fri Sep 05, 2003 4:03 am
Location: Montreal
Contact:

Post by chuck_starchaser »

Thanks a million, JackS; very illumining answer. I'll be thinking about size categories. Right now it appears that we, meaning PU, will be moving into having 7 size classes for military and a standard VS Trinity for civilian; but we're still brainstorming. I'll post an update once the dust settles.
Thanks again.
chuck_starchaser
Elite
Elite
Posts: 8014
Joined: Fri Sep 05, 2003 4:03 am
Location: Montreal
Contact:

Post by chuck_starchaser »

Ehm... One thing I can tell you right now that will need changing in that enum is the addition of AUTOCONVERGENCE.
This is a feature that came up in PU discussions and which I corresponded about with Hellcat and he was warm to the idea, and even promised to come up with code for it.
AUTOCONVERGENCE would bridge the yawning gap between AUTOTRACKING and the lack of it.
What Autoconvergence will do is turn the angle of the weapon mounts inwards ONLY, and slightly, so that widely spaced weapons would cross the forward vector at the distance of the target. Autoconvergence would NOT in any way correct your aiming. It would ONLY autodetect target distance and turn the weapons inwards so that, at the target's distance, the weapons shots would cross each other.
This would make ships with widely spaced weapon mounts, such as WC's Raptor, more effective, without making targeting itself any easier.
Very good feature/upgrade for VS, as well, if I may say so.
Deus Siddis
Elite
Elite
Posts: 1363
Joined: Sat Aug 04, 2007 3:42 pm

Post by Deus Siddis »

chuck_starchaser wrote:Ehm... One thing I can tell you right now that will need changing in that enum is the addition of AUTOCONVERGENCE.
This is a feature that came up in PU discussions and which I corresponded about with Hellcat and he was warm to the idea, and even promised to come up with code for it.
AUTOCONVERGENCE would bridge the yawning gap between AUTOTRACKING and the lack of it.
What Autoconvergence will do is turn the angle of the weapon mounts inwards ONLY, and slightly, so that widely spaced weapons would cross the forward vector at the distance of the target. Autoconvergence would NOT in any way correct your aiming. It would ONLY autodetect target distance and turn the weapons inwards so that, at the target's distance, the weapons shots would cross each other.
This would make ships with widely spaced weapon mounts, such as WC's Raptor, more effective, without making targeting itself any easier.
Very good feature/upgrade for VS, as well, if I may say so.
This would also be especially useful, for the manual turret array training interface I brought up during this thread, wherein all the ship's turrets would converge their aim on the point where a ray cast from the camera view first intersects another ship's collision geometry, regardless of whether or not that ship is targeted.

This would allow you to manually aim your turrets at a particular point on its hull or a subsystem, without having to target it or the subsystem using the cumbersome cycle-through-all-possible-targets interface.


One thing that needs to be worked out for this auto convergence feature for hardpoints or turrets, is for the convergence to take effect based on a ship that isn't directly being aimed at, for when you have to lead slower travelling weapons in order to hit a moving target. It would have to decide which object's distance to converge on intelligently based on angle from the camera view and range.

If it only chose the target with the least angle from the crosshairs then it might be basing convergence on a ship at the other side fo the solar system, if it only chose the target with the least distance then it might be basing convergence on a ship behind you.

You could instead make auto converge work only on a ship that is actually targeted, but then that would make the interface and usage seem very cumbersome for something that provides a minor, rather than major amount of automation like auto tracking or auto turrets. Most people probably wouldn't remember the feature was even there or bother to use it in that case, especially not in a fight with more than one enemy where you change targets often based on who is the most danger or easiest to hit at that moment.
chuck_starchaser
Elite
Elite
Posts: 8014
Joined: Fri Sep 05, 2003 4:03 am
Location: Montreal
Contact:

Post by chuck_starchaser »

Perhaps a better solution would be to have a toggle between,
  • Manual Aiming with Auto-Targeting, and
  • Manual Targeting with (autotracking notwithstanding) Auto-Aiming
The latter would be the status quo.
The former would be a new modality whereby you aim wherever you want, manually; but
the system detects (via ray-collision) which target you're targeting, and highligths it.
The highlighted target is also the one on which distance for autoconvergence is based.

NOTE: The idea above would not be for PU; it is only a suggestion for VS.
NOTE2: I've no idea what a good name or pair of names would be good for these modalities.
chuck_starchaser
Elite
Elite
Posts: 8014
Joined: Fri Sep 05, 2003 4:03 am
Location: Montreal
Contact:

Post by chuck_starchaser »

Code: Select all

enum MOUNT_SIZE {NOWEAP=0x0,LIGHT=0x1,MEDIUM=0x2,HEAVY=0x4,CAPSHIPLIGHT=0x8,CAPSHIPHEAVY=0x10,SPECIAL=0x20, LIGHTMISSILE=0x40,MEDIUMMISSILE=0x80,HEAVYMISSILE=0x100,CAPSHIPLIGHTMISSILE=0x200, CAPSHIPHEAVYMISSILE=0x400,SPECIALMISSILE=0x800, AUTOTRACKING=0x1000} size;
JackS, I think we're ready for a proposal for those bits, after much brainstorming.

Code: Select all

enum mount_size
{
  //sizes
  // NOTE1: military are bigger than civilian at same enumeration
  // NOTE2: civilian sizes above 4 probably not used, but heck
  noweap = 0,
  size1civ = 1,
  size2civ = 2, size1mil = 2,
  size3civ = 3, size2mil = 3,
  size4civ = 4, size3mil = 4,
  size5civ = 5, size4mil = 5,
  size6civ = 6, size5mil = 6,
  size7civ = 7, size6mil = 7,
  size8civ = 8, size7mil = 8,
  size9civ = 9, size8mil = 9,
  size9mil = 10,
  //...........................
  //Civilian or military?
  //  NOTE these bits could both be on for a civ/mil compatible mount
  civilian = 11,
  military = 12,
  //.............................
  //What is it? Is it a gun? A missile? A torpedo? Maybe something special?
  //  NOTE: A mount can't mount a gun OR a missile OR a torpedo, so no
  //  need to have separate size bits
  gun_energy= 13,
  gun_kinetic = 14,
  missl_dumb_rocket = 15,
  missl_guided = 16,
  missl_cruise =17,
  missl_wire_guided_torp = 18,
  mine = 19,
  smoke_bomb = 20,
  turret_gun = 21,
  turret_missile = 22, //MLRS
  //.................................
  // bits 23, 24, 25 and 26 left for future expansion
  //...................................
  //Modifiers:
  autoconvergence = 27,
  autotracking = 28,
  autofire = 29,
  extra_heavy_mount = 30, //improved accuracy
  point_defense_mount = 31 //improved turning, rate of fire
}
To manage the transition from existing weapons and mounts, we'd
simply comment out the old enum, and #define the old enums in
terms of the new.

Code: Select all

#define LIGHT ((size1civ|gun_energy))
#define LIGHTMISSILE ((size1civ|missl_guided))
...etc.
jackS
Minister of Information
Minister of Information
Posts: 1895
Joined: Fri Jan 31, 2003 9:40 pm
Location: The land of tenure (and diaper changes)

Post by jackS »

A couple of questions and comments.

I like the breakup between size and type. There are actually some VS ships that have mounts that are either guns or missiles, but there are only a couple and it's not a problem to change.

Not entirely sure what class of weapons smoke_bomb is intended correspond to - it seems a bit specific, especially since there's no bomb class. Another pair of clarifying questions - what is "autofire" intended to do, and what exactly is implied by "improved accuracy" for extra_heavy_mount?

Another query: what were you thinking would be the key differences among
missl_guided = 16,
missl_cruise =17,
missl_wire_guided_torp = 18,
?
I was thinking that a single-hardpoint vs. magazine classification would be useful, but I'm curious as to what the key distinguishing feature for a given mount would be that would allow it to fire guided missiles but not cruise missiles or vice versa is.

There are some things I'm not sure we want to try to push into something that should be primarily a mount size compatibility specification. From a semantic cleanliness perspective, I'm not convinced autotracking had any business being there in the first place, and I'm more inclined to move it out than to want to move several new things in, especially since it is a space-limited list. Don't misunderstand me: I really like the autoconvergence option, I'm just pondering whether this bitvector is really the best place to add it. This is a vector that, ideally, is a contract between every weapon and every mountpoint, but some of the properties are mountpoint properties, but not weapon type properties, and perhaps should be handled separately. We may still end up putting them in the vector, at least for the time being, but I just wanted to comment on what I was thinking.

I'm not sure what we'll need/want the turret_gun and turret_missile flags for. If it's to denote that the weapon happens to be in a turret, I think there are/will be better indicators to use. From the perspective of the contract between the mount and the weapon, I'm not sure we need to know if it's in a turret or not. If you're denoting a weapon that is intrinsically a turret (some sort of phased array installation) then this is a useful flag, but I don't know when the engine will support that meaningfully. Perhaps I've just entirely misread what you were going for here.

I think the point_defense_mount flag is not well-suited to be a weapon_size property as the VS engine is written/organized. Turning is not a property that is touched by the weapon code at all. We may be able to do per-mountpoint ROF changes, but I'm not sure we only want one bit of information to denote that change and the magnitude of its size. This is something that would seem best served at present by making a point defense turret unit that moves quickly and then, if one wishes it to do its job well, equipping it with weapons that fire quickly, perhaps pd-oriented variants of other weapons, as is currently done in the VS data set.
chuck_starchaser
Elite
Elite
Posts: 8014
Joined: Fri Sep 05, 2003 4:03 am
Location: Montreal
Contact:

Post by chuck_starchaser »

jackS wrote:A couple of questions and comments.

I like the breakup between size and type. There are actually some VS ships that have mounts that are either guns or missiles, but there are only a couple and it's not a problem to change.
This scheme actually allows for a mount to be gun/missile compatible. The only catch is that you cannot independently adjust the size category of each. If you set the bits for gun_energy and missl_guided, the mount will accept both, but for the same size levels flagged.
Not entirely sure what class of weapons smoke_bomb is intended correspond to - it seems a bit specific, especially since there's no bomb class.
Damn; that was a joke. I had other jokes I took out but missed that one :)
Another pair of clarifying questions - what is "autofire" intended to do, and what exactly is implied by "improved accuracy" for extra_heavy_mount?
These are mount modifier ideas I was borrowing from Masters of Orion II, and are mere suggestions of possibilities, --almost tongue in cheek.
Auto-fire would be more of a targeting and weapon control feature than a mount feature (complimentary to target-leading and auto-tracking) that allows a weapon to fire autonomously when aiming is deemed to be on target; but used with an unmodified mount could result in rapid overheating. Auto-Fire-modified mounts would manage their own thermal conditions by taking auto-firing commands with a grain of salt: firing the weapon no more than 3 times successively, for instance; and waiting for the autofire signal to go inactive and then come active again before firing again; perhaps with a bit of signal debouncing. The number of successive shots would decrease, and debouncing time increase, as temperature goes up. I could write the software to do this, if you are interested. It's not a feature I thought for PU, BTW; but we could use it in a future project if it were there.
Heavy mount is another MOO2 mount modifier that made a lot of sense to me: Suppose you have the space available for a size5 weapon mount. In that space you could put a size 5 weapon mount, but you could also put a size 4 weapon mount with the "heavy" modifier. This would provide extra firmness to how the mount holds the weapon: Less play, jitter, acceleration effects, and recoil extent and settling time. IOW, it increases overall aiming accuracy. Thus, this size4 weapon could become more effective than a size5 at long range.
Another query: what were you thinking would be the key differences among
missl_guided = 16,
missl_cruise =17,
missl_wire_guided_torp = 18,
?
I wanted to distinguish between types of guidance that might require specially modified mounts.
A cruise missile would be one that receives very detailed, high level instructions what to do just prior to firing. High bandwidth, but one-way communications. Just upload what to do to the weapon and fire.
Guided missile would be anything from heat signature to radar lock to image recognition that requires two-way communications: The weapon's seeker is sending a constant "image" of what IT sees to the targeting system in the cocpit. The targeting system could allow the pilot to pick a target, or pick one autonomously, as per programming and pilot settings, and then sends a selection to the missile based on what IT saw, for locking.
Wire-guided torps would be guided from the launching ship by an unrolling wire, as an alternative to remote radio guidance that could be jammed. But this is really just a mental model for the feature: What it would actually do is require the launching craft to follow the torpedo and keep its target targeted. I thought of this as a handy feature to implement future WC-related projects, where torpedoes are slow but huge cap-ship killers, but according to William Forstchen in Fleet Action (Battle of Earth), the bomber has to keep the target illuminated during the typically 30-second flight of the torp. The overall effect of this requirement would be equivalent as if there was "unrolling wire" guidence. So, it's just a name/concept for the launching and guidence dynamic; but however it were implemented, it would probably require a special mount, incompatible with fire-and-forget munitions... perhaps... though, as always, one can set more than one munition type flag for a mount.
I was thinking that a single-hardpoint vs. magazine classification would be useful, but I'm curious as to what the key distinguishing feature for a given mount would be that would allow it to fire guided missiles but not cruise missiles or vice versa is.
Mostly the type and bandwidth of the communications with the munition, but it would be quite possibly easy to make a mount have both types of communications channes, as a purchaseable mount modifier.
There are some things I'm not sure we want to try to push into something that should be primarily a mount size compatibility specification. From a semantic cleanliness perspective, I'm not convinced autotracking had any business being there in the first place, and I'm more inclined to move it out than to want to move several new things in, especially since it is a space-limited list. Don't misunderstand me: I really like the autoconvergence option, I'm just pondering whether this bitvector is really the best place to add it. This is a vector that, ideally, is a contract between every weapon and every mountpoint, but some of the properties are mountpoint properties, but not weapon type properties, and perhaps should be handled separately. We may still end up putting them in the vector, at least for the time being, but I just wanted to comment on what I was thinking.
That was my thought too, from the start. I leave that to you; as I don't know what would be involved, programming-wise to split the stuff. I agree that bunching sizes and modifiers is neither elegant nor forward-looking. Took a bit of thinking to fit all the stuff we did into 32 bits, and that left only 4 to spare; it doesn't look like a long-lasting solution.
On the other hand, mount modifiers could affect weapon size. The heavy mount modifier I suggested would be one; but also, Autoconvergence and Autotracking, when applied to fixed weapon mounts, should really have an effect on the size of weapon you can mount. If I have a size5 gun in a fixed mount, it doesn't make much sense that after adding all the delicate mechanics and hydraulics needed to make the mount's angle to be adjustable, that I would still be able to mount a size5 weapon there; it should now fit a size4 max.
On the other hand, you could call this whole thing a weapon/mount descriptor rather than a size specification, and the perspective changes.
I think the problem is not so much as whether size and type should be together or separate, as much as a more general problem of abstraction: Rather than a hardcoded enum, this should perhaps be a class, whose internal representation is nobody's business. It would have boolean functions on the interface for queries, a function for compatibility testing, etceteras; and the internal representation could then change as the need arises, without affecting other parts of the code.
I'm not sure what we'll need/want the turret_gun and turret_missile flags for. If it's to denote that the weapon happens to be in a turret, I think there are/will be better indicators to use. From the perspective of the contract between the mount and the weapon, I'm not sure we need to know if it's in a turret or not. If you're denoting a weapon that is intrinsically a turret (some sort of phased array installation) then this is a useful flag, but I don't know when the engine will support that meaningfully. Perhaps I've just entirely misread what you were going for here.
Energy gun turrets and missile turrets, my thought was, would need very different mount-points:
Energy gun turrets need thick power cables AND cooling line connections.
Missile turrets need a way to refill with missiles, which involves some kind of reloading mechanism and a way of conveying missiles from a storage area.
Recoil withstanding needs are also different.
I think the point_defense_mount flag is not well-suited to be a weapon_size property as the VS engine is written/organized. Turning is not a property that is touched by the weapon code at all. We may be able to do per-mountpoint ROF changes, but I'm not sure we only want one bit of information to denote that change and the magnitude of its size. This is something that would seem best served at present by making a point defense turret unit that moves quickly and then, if one wishes it to do its job well, equipping it with weapons that fire quickly, perhaps pd-oriented variants of other weapons, as is currently done in the VS data set.
Sure; that was just another modifier I was borrowing from MOO2. In MOO2, PD was a mount modifier that made the weapon you put there take a lot less space :), --so you could fit more of them; but that made those weapons lose a lot of range. But you're right, this would be better modeled as a weapon choice.
chuck_starchaser
Elite
Elite
Posts: 8014
Joined: Fri Sep 05, 2003 4:03 am
Location: Montreal
Contact:

Re: Attack on Trinity: Expanding weapons size classes

Post by chuck_starchaser »

So, here's a more cleaned up proposal for the bit mask.

Code: Select all

enum mount_type_mask
{
  //size classes encoded one-ary-ly in bits 0 through 9 (10 bits; N/A + 9 size classes)
  bit0, //no size fits or size not applicable
  bit1, //size 1 weapon -compatible
  bit2, //size 2 weapon -compatible
  //..... and so on through.....
  bit9, //size 9 weapon -compatible
  //Civilian or military?
  //  NOTE these bits could both be on for a civ/mil compatible mount. What we cannot do is specify different size classes for civ and mil, so if mil size classes
  //need to be bigger than civilian size classes it would be a good idea to just change the names of mil size categories to make them sound smaller than they
  //are, but to use the same underlying size classes (bit masks) for civ and mil size classes that are really the same absolute size.
  bit10, //1 = civilian
  bit11, //1 = military
  //.............................
  // What is it? Is it a gun? A missile? A torpedo? Maybe something special?
  // NOTE: A mount can't mount a gun OR a missile OR a torpedo, so no need to have separate size bits; however if you need a mount to accommodate both a gun
  // AND a missile, as long as the compatibility is with same size categories for both, there's nothing preventing you from raising both gun AND missile flags. Which
  // implies that, again, it would be a good idea to use same bit-level size classes for missile/gun mounts that take the same amount of space, though the naming
  // need not be in synch, of course.
  // NOTE2: I'm separating 6 classes of gun- and 6 classes of missile-mounts for forward compatibility/flexibility. Named categories in parenthesis are mere examples,
  // but what's important is the ability to have various types of mounts taylored to specific weapons systems. A mount point has to have facilities for power, cooling,
  // hydraulics, munitions loading, and communications and control for a weapon system; and such are likely to be very different for a chemical gun than for a gauss
  // or rail-gun, so, if a mod wants to make such distinctions, the A,B,C subcategories of the Energy/Kinetic categories should help implement them.
  bit12, //gun_energy type A (ion accelerator?)
  bit13, //gun_energy type B (plasma spitter?)
  bit14, //gun_energy type C (laser/optical?)
  bit15, //gun_kinetic type A (chemically propelled?)
  bit16, //gun_kinetic type D (gauss gun?)
  bit17, //gun_kinetic type E (rail-gun?)
  bit18, //missile type A, (dumb/rocket?)
  bit19, //missile type B, (guided, requiring weapon seeker target ackquisition before launch?) 
  bit20, //missile type C, (cruise, requiring only a trajectory upload?)
  bit21, //missile type D, (Smart/Friend-Foe/Picks its own targets?)
  bit22, //torpedo type A, (?)
  bit23, //torpedo type B, (?)
  //Special
  bit24, //special (possibly this could be used as an escape bit for an expanded bit-masking system)
  bit25, //turret or MRLS (sub-unit mount-point)
  //Fixed gun mount modifiers:
  bit26, //modifier A (autoconvergence: tiny 1-axis pivoting allows automatic inward slanting of weapon aiming such that shots aim to cross at target range).
  bit27, //modifier B (autotracking: slight 2-axis pivoting, for automatic aiming correction, --reduced accuracy at longer ranges)
  bit28, //modifier C (recoil mount: allows heavier caliber weapons than a frame was designed for, by reducing recoil stress --at the expense of accuracy)
  //Turret modifiers:
  bit29, //modifier D (extra_heavy_mount: oversized mechanical components for improved mechanical accuracy versus recoil; limits turning speed?)
  bit30, //modifier E (standard mount: balance of aiming speed versus recoil withstand and mechanical stability?)
  bit31, //modifier F (point_defense_mount: big hydraulic pipes, light mechanics --for improved turning/aiming speeds, limited accuracy with higher recoil?)
}
ace123
Lead Network Developer
Lead Network Developer
Posts: 2560
Joined: Sun Jan 12, 2003 9:13 am
Location: Palo Alto CA
Contact:

Re: Attack on Trinity: Expanding weapons size classes

Post by ace123 »

While bitmasks are wonderful and everything, I'm not completely happy about having 31 different bit values hardcoded into the engine. While not speed-constrained, we don't want to bloat memory usage too much if this is stored per mount. (however In my opinion using another 32-bit integer per mount would be acceptable)

What I am seeing is you are specifying a few properties:
Size constraints (could this be a number and allow mounting any gun at most this size?)
Standards constraints (if civilian and military weapons are mounted differently and are incompatible. Would possibly apply to missiles versus guns)
Energy constraints (runs on electricity, ammunition, chemicals, mechanical energy or whatever other races use?)
Extra capabilities (autotracking, convergence, recoil?)

Some of these like size would maybe make more sense as a number...

Not sure if standards, energy or race constraints apply... I would imagine in the VS universe, ships will have standardized on ammunition for the most part so that mounting constraints come down to just whether it will fit and have enough energy.

Capabilities should remain just bits.

However, I can understand the reasons that you would want a lot of these bits... perhaps for compatibility constraints we just have a separate integer (can be 16-bit if you want to save space). These bits can be entirely defined by the weapons.xml and they just have to match up between units and weapons.

Then, have a 16-bit integer keep track of extra options built into VS
And then maybe a third 16-bit number for size (or have minsize and maxsize)

I don't have a specific proposal but I can't imagine how the proposed bitmask would be implemented into the engine with that many hardcoded bits there. Surely there should be a way to split up "important" bits (ones that have side-effects in-game) and ones that are purely for mounting constraints.
chuck_starchaser
Elite
Elite
Posts: 8014
Joined: Fri Sep 05, 2003 4:03 am
Location: Montreal
Contact:

Re: Attack on Trinity: Expanding weapons size classes

Post by chuck_starchaser »

ace123 wrote:While bitmasks are wonderful and everything, I'm not completely happy about having 31 different bit values hardcoded into the engine. While not speed-constrained, we don't want to bloat memory usage too much if this is stored per mount. (however In my opinion using another 32-bit integer per mount would be acceptable)
My understanding from JackS' post was that the engine already is using a 32-bit mask, but only a handful of the bits are being used.
What I am seeing is you are specifying a few properties:
Size constraints (could this be a number and allow mounting any gun at most this size?)
It's unary, rather than binary: One bit per size class, so you can indicate more than one compatible size class.
Standards constraints (if civilian and military weapons are mounted differently and are incompatible. Would possibly apply to missiles versus guns)
Exactly. It does; there are bits for six gun standards and six missile standards.
Energy constraints (runs on electricity, ammunition, chemicals, mechanical energy or whatever other races use?)
I didn't go as far a specifying energy, coolant, lube amounts required, but I think modifiers like heavy, point defense, etc., plus weapon standards should suffice.
Extra capabilities (autotracking, convergence, recoil?)
Yep. This is a bit mixed up in that these are indeed mount capabilities rather
than compatibilities; not sure if these bits make any sense in a mask variable; just threw them in because the engine already did that with autotracking, but
I agree it's mixing apples and bananas.
Some of these like size would maybe make more sense as a number...
It IS a number; just represente in unary, rather than binary, so
that compatibility with more than one standard size can be specified.
Not sure if standards, energy or race constraints apply... I would imagine in the VS universe, ships will have standardized on ammunition for the most part so that mounting constraints come down to just whether it will fit and have enough energy.
Race... Hmm... You have a point; but what if some future mod has 200 races?
Capabilities should remain just bits.
Frankly, I don't think capabilities really belong here. It's not like a type of gun would require autotracking, or
be incompatible with it. I only threw capabilities in there because it's already all mixed up in the current code.
However, I can understand the reasons that you would want a lot of these bits... perhaps for compatibility constraints we just have a separate integer (can be 16-bit if you want to save space). These bits can be entirely defined by the weapons.xml and they just have to match up between units and weapons.
It's already 32-bit, afaik; mostly just wasted, like Light, Med, Heavy for guns and for missiles, plus a bit for autotracking and one for special; the other 24 bits not used.
Then, have a 16-bit integer keep track of extra options built into VS
And then maybe a third 16-bit number for size (or have minsize and maxsize)
Standard register size is 32-bits; you gain nothing from splitting the whole into 16-bit variables; in fact it would compile to older and slower instructions; and could kill your alignment too.
I don't have a specific proposal but I can't imagine how the proposed bitmask would be implemented into the engine with that many hardcoded bits there.
The bits as I proposed them are only as hard-coded as saying that there are 9 standard size mounts for each of a dozen weapon classes (six gun types and six missile types was just a suggested use), which comes to 108 variants; * civilian or military (216); * fixed or turreted (432); plus, fixed gun mounts have 3 possible modifiers, and turrets have 4 possible modifiers, for a grand total of thousands of possibilities; but, like I said, those modifiers and types could be used any way you want; my parenthetical descriptions were mere examples.
Surely there should be a way to split up "important" bits (ones that have side-effects in-game) and ones that are purely for mounting constraints.
The only unimportant ones are those I called "Fixed gun mount modifiers", which are really more like capabilities than compatibilities... they don't really belong in there. Everything else is just "slots", to be labeled to taste.
klauss
Elite
Elite
Posts: 7243
Joined: Mon Apr 18, 2005 2:40 pm
Location: LS87, Buenos Aires, República Argentina

Re: Attack on Trinity: Expanding weapons size classes

Post by klauss »

Bitfields can be more cleanly specified using... bitfields:

Code: Select all

struct MountCapabilities {
    unsigned size1compat : 1;
    unsigned size2compat : 1;
    unsigned size3compat : 1;
    unsigned size4compat : 1;
    ...
    unsigned someStuff : 3; // if you want a 3-bit number
};
In any case... it's nice optimizing memory and all, but it may be unnecessary in this place.

I believe each ship should have a pointer to its template (ie: kind of the CSV row used), not a copy of everything, as you can't (shouldn't be able to) manually customize any ship. And id you could, it would be uncommon.

If that model came to reality, memory efficiency would be pointless.
Oíd mortales, el grito sagrado...
Call me "Menes, lord of Cats"
Wing Commander Universe
chuck_starchaser
Elite
Elite
Posts: 8014
Joined: Fri Sep 05, 2003 4:03 am
Location: Montreal
Contact:

Re: Attack on Trinity: Expanding weapons size classes

Post by chuck_starchaser »

I wasn't trying to optimize; just to minimize code changes. I figured, if the thing is a bit-field currently, probably the
easiest, incremental thing to do is to simply use the un-used bits for useful stuff.

OTOH, I don't know about this particular case, but generally the engine is data-wise bloated due to severe under-valuing of optimizations in general. Look at the size of Unit, and there are dozens of booleans that could have used 1 bit each, but instead take up 4 or 8 bytes each. Even more horrifying is the save-file, which could probably be a single bit-field a few K in size, but instead it uses gazillions of named variables taking up megs on disk, and probably in RAM as well. So, maybe we should change philosophy and ask for reasons to NOT optimize, rather than for reasons to optimize.
klauss
Elite
Elite
Posts: 7243
Joined: Mon Apr 18, 2005 2:40 pm
Location: LS87, Buenos Aires, República Argentina

Re: Attack on Trinity: Expanding weapons size classes

Post by klauss »

Reasons to NOT optimize: ease of maintainance.

That's ALWAYS the reason not to optimize.

If not optimizing doesn't ease maintainance, then it's not worth not optimizing.

(nice word puzzle ;) )
Oíd mortales, el grito sagrado...
Call me "Menes, lord of Cats"
Wing Commander Universe
chuck_starchaser
Elite
Elite
Posts: 8014
Joined: Fri Sep 05, 2003 4:03 am
Location: Montreal
Contact:

Re: Attack on Trinity: Expanding weapons size classes

Post by chuck_starchaser »

klauss wrote:Reasons to NOT optimize: ease of maintainance.

That's ALWAYS the reason not to optimize.

If not optimizing doesn't ease maintainance, then it's not worth not optimizing.

(nice word puzzle ;) )
Indeed. Keep in mind though, that "ease of maintenance" is a subjective term. All other things being equal, it boils down to "how close or far is the way something is coded to the way you would have done it?" And the way a programmer concerned with efficiency would code a class with gazillions of booleans would be to use bits, and therefore it would take that programmer more time to understand a class where each boolean takes several bytes of storage for no good reason. Most ideologies when taken to extremes result in reversals; and "ease of maintenance" is no exception, like some programmers would probably advocate to have several pages of documentation, graphs and charts and a revision history for each class in a program, in the name of "ease of maintenance", which ironically would be a maintenance nightmare to keep up to date. Using bits, in this situation, seems to me "logical", rather than like "optimization"; but that's just me, I guess.

EDIT:
Specially considering the sheer volume of code involving weapon/mount compatibility tests using if or case statements, where they can all be reduced to a single bit-wise operation. So we're talking about wastefulness not only in storage but in code as well, and branch prediction cache pollution. I can't help to think about such things, as a programmer, and code written without regards whatsoever for efficiency gives me pause when trying to read it.
IOW, I guess I agree with your statements, but feel that this situation, for me at least, falls under "If not optimizing doesn't ease maintainance, then it's not worth not optimizing." In fact, sometimes not optimizing may reduce ease of maintenance, for some of us. Using a bit mask for this kind of thing, to me, is a no-brainer. I think your assumption with regards to maintainability is that most programmers think, or prefer to think, in 100% abstract terms. I doubt this is the case with most C/C++ programmers, though it might be true of programmers who work with functional or declarative languages.
Neskiairti
Confed Special Operative
Confed Special Operative
Posts: 334
Joined: Thu Jan 11, 2007 4:10 am

Re: Attack on Trinity: Expanding weapons size classes

Post by Neskiairti »

this may be completely naive.. but for maintaining.. wouldnt it be better to have a general 'bithandler' code.. and then use user/programmer friendly programing everywhere else... then feed that to the optimizer function? in the save file you wouldnt need readability.. only in the code and the user readable unit.csv (then use the same optimizer function for a unit.csv conversion) that way you can edit it plain text.. with a bit of extra syntax.. like.. keyword styled values
$(weapondata(some plaintext value, the next one, the next one, and so forth))
then it gets converted to the bitmask.. say 2 bits for what type of data it is.. then followed by the bit data.

this allows both maintainability and optimization.
klauss
Elite
Elite
Posts: 7243
Joined: Mon Apr 18, 2005 2:40 pm
Location: LS87, Buenos Aires, República Argentina

Re: Attack on Trinity: Expanding weapons size classes

Post by klauss »

@chuck: maintainance includes modifications. Ease of maintainance is also ease of extension, because at some point in the lifetime of any software, there are new requirements being introduced. What you have to ask yourself, is if having a bitfield pattern stored in an int (32 bits max) is more or less maintainable (ie: extensible too) than having a bitfield pattern stored in a struct (no size limit, some functional limits) (ie: extensible too), or than having an enumerated value (different limits, different functionality).

I don't have an answer. But it's the question you have to ask yourself and others.
Oíd mortales, el grito sagrado...
Call me "Menes, lord of Cats"
Wing Commander Universe
chuck_starchaser
Elite
Elite
Posts: 8014
Joined: Fri Sep 05, 2003 4:03 am
Location: Montreal
Contact:

Re: Attack on Trinity: Expanding weapons size classes

Post by chuck_starchaser »

Neskiairti wrote:this may be completely naive.. but for maintaining.. wouldnt it be better to have a general 'bithandler' code.. and then use user/programmer friendly programing everywhere else... then feed that to the optimizer function? in the save file you wouldnt need readability.. only in the code and the user readable unit.csv (then use the same optimizer function for a unit.csv conversion) that way you can edit it plain text.. with a bit of extra syntax.. like.. keyword styled values
$(weapondata(some plaintext value, the next one, the next one, and so forth))
then it gets converted to the bitmask.. say 2 bits for what type of data it is.. then followed by the bit data.

this allows both maintainability and optimization.
You've hit the nail on the head. In fact, that's what I was really talking about. The essence of it is that optimizations don't really need to show at the interface. There's already bit array classes or something along the lines in the STL, which I haven't used, but I know it's there.
klauss wrote:@chuck: maintainance includes modifications. Ease of maintainance is also ease of extension, because at some point in the lifetime of any software, there are new requirements being introduced. What you have to ask yourself, is if having a bitfield pattern stored in an int (32 bits max) is more or less maintainable (ie: extensible too) than having a bitfield pattern stored in a struct (no size limit, some functional limits) (ie: extensible too), or than having an enumerated value (different limits, different functionality).

I don't have an answer. But it's the question you have to ask yourself and others.
Gottcha. So, let's look at it:
The problem of maintenance can be summarized with a question: What happens when we run out of bits? (That's assuming we use a DWORD for bit storage, as opposed to a bit array, which would grow automatically as we add bits.)
Well, let's begin with the class itself:
More bits means we've expanded the number of size categories, added more special equipment compatibilities, etceteras.
And that means new set and get functions, at the very least.
Thus, the interface of the class will have to change, no matter what we use as the underlying representation.
A function to test for compatibility of a weapons system with a given mount would also have to change; however, notice here that while a bit-wise test is easy to extend, and only necessary to extend when the number of bits used crosses an underlying storage unit threshold, fully coded tests as gargantuously long chains of bool tests &&'d together would have to change even when a single bit is added.
Outside of the class itself, the question is how does the type of class storage affect other pieces of code around the engine.
Here it should be obvious that the problems of code dealing with the class through its standard interface would be the same, regardless of the form the storage takes, as presumably the interface would be no different.
However, OO programming's interface abstractions apply to functions. Data is always a subversion of OO principles. Assignment, copy constructor, equality comparison, and other data-centric functions, have a funny tendency to expose internal representation.
Case in point, the big question is really about representation in units.csv, I strongly suspect, and gladly address: If we have to enter these weapon and mount compatibility fields in units.csv, what's the more maintainable way to do so? Units.csv is a funny thing, because each field usually contains either numbers or strings, and strings have their own representations. Each, in a way, can have multiple "columns" of info.
Now, if we follow the units.csv traditions, I guarantee you we'll end up with,
"0,1,0,0,0,0,1,0,0,0,0,0,1,0,0,0,1,1,0,1,0,0,0,0,1,0,1,1,0,1,0,0"
where each 1 or 0 has a special meaning, depending on its position, which can only be determined by counting bloody 1's and 0's.
But some will suggest that's more user-friendly than its hex representation "0x4208d0b4".
I disagree: I think a string generator app will be needed either way, and that, for some reason that elludes me completely, yet claims status as Fate, I happen to KNOW that if the "0,1,0,0,..." solution is adopted, such a generator app will NOT be forthcoming; but that if the "0x4208d0b4" solution is adopted, this will make such an app materialize almost immediately. And, no; I'm not joking. Besides, I find it easier to memorize a hex number than its equivalent strings of 1's and 0's, just as I remember phone numbers easier in decimal than in binary representation, if this fact matters at all.
Either way, there is no need for units.csv storage and run-time memory storage to agree; but for maintainability... It would be mind-boggling for the two representations to be different, which would put us in a difficult choice if their conveniences of representation were different. In this case they agree, IMNSHO: they both cry out for bit-fields at the top of their lungs.
This is not to say there may not be more serious issues in the representation: I'm not at all sure about the mixing of size-bits and feature-bits in the same bit array (perhaps having separate Size and Features DWORD's would be safer, more maintainable, as well as give us more room to grow), as I'm not completely sure that generalizing weapon size slots across a galaxy is best idea, though I strongly suspect it is. Lastly but not leastly, different mods would put the bits to different uses, and this is the real big joke... Do you get it? Hint: Even in the same mod, the meanings of some bits could vary, such as bit N could mean one feature for race X, but a different one for race Y; just as we discussed the strong possibility that size 4 in our bit field might mean size 3 in military classifications but size 5 in civilian; thus our size slots are internal to the mod, and could be "interpreted" variously at the player's interface.
Well, the big joke is that all our class IS is a storage representation of it knows not what, anyhow.
Post Reply