[Backslash]

So, I've been working on some stuff in the HUD, and I thought I'd talk about an old 'new' feature I'd like to reinvent.  Granted, some of the code has already been restored in there recently for the FSPort, but I want to expand it to give us a lot more possible customization.  I'm talking about the weapon links gauge from FS1, on the 'right arc'.  It shows which weapon(s) are active.  Go look at 2_rightarc*.ani in sparky_hi_fs2.vp if you don't remember what it looks like.

It's already going to need quite a few changes to make it work with 3 primaries and 4 secondaries, as well as be future-compatible .  So, while I'm at it, I thought, what else should I think about adding?  Here's my rough idea of the new structure:

The weapons are divided; each weapon bank is assigned a different ani.  Let's call them primary1 through primary3 and secondary1 through secondary4 for now.  The first frame (0) of each is the 'empty frame', and the game picks only one of them to display according to how many banks there are ... i.e. if you're in a fighter with 2 primary banks it uses frame 0 of primary2, but if you only have 1 primary bank it uses frame 0 of primary1.  Functionally this is identical with the current behavior if we were to define primary1 as 2_rightarc2 and secondary1 as 2_rightarc4 and so on.  This is before anything lights up though.  Now for the lighting up, let's have frame 1 just be the weapon is lit up selected and ready, so at a bare minimum, all you need to have this work is frame 0 and frame 1.

This is where it gets interesting.  Each frame after 1 has to do with separate points.  Picture this: They are rendered on top of each other in the same place.  Let's have N more frames according to the number of points in the weapon bank (remember, once I finish hud_gauges.tbl we'll be able to customize the ani used per-ship if we want).  These frames have to do with which points are selected and ready... by default for primaries all of em are selected, so unless the "cycle" flag is set (or maybe some other link settings to be implemented later ) this isn't really necessary, but it gets more fun when you consider secondaries or cycling primaries: it would light up the banks that are ready to fire next.

Still with me?  I've got another idea to add on top of that involving ammo, but I'd better wait and see what people think of this stuff so far.  Keep in mind that with each weapon bank being given its own ani and coordinates, each can now essentially be considered a separate gauge.  With hud_gauges.tbl I'll be allowing for customization, different coordinates and different ani files per bank and per ship, so consider the possibilities:
1. by default this could behave just like FS1's right arc, all coordinates set the same so rendering on top of each other
2. moving the gauges closer to the reticle we could make it look like the reticle changes according to what weapon is selected.  zeck we could even get rid of the default reticle and actually have this be our reticle.  Somewhat like TIE Fighter
3. moving the gauges down to a corner like in a MFD we can make a more complicated/informative weapons gauge, Wing Commander or Tachyon style (at least, somewhat).  Mind, this is according to what bank is selected, not what specific weapon is named ... but put it next to the regular weapons gauge and we can make this into a more complicated 'show which bank/weapon/points are selected' arrow/symbol system.

I've been goofing around with testing a minimalistic version of idea #2 -- it's pretty sweet so far.  The more complicated point-specific stuff takes more work but is optional.  I'm sure there's more I haven't thought of, too, so that's where you all come in to brainstorm.

[Nuke]

why settle for just 3 and 4 banks respectively. i think it should be set up to use any number of guns and missiles. this would allow some more versatility, such as a bettletech or descent mods, and would allow more versatility in external stores. add support in the games build in hud for a 3/4 load out. then if somone wants to make a mod where 7 weapons just isnt enough, give them the option to script an interface. if too many weapons are loaded to use the hud elements, simply disable them while maintaining the functionality of the controls. with the gauges disabled scripted ones could be used in their place. i was planning on an mfd of sorts for which woud be an rtt panel in the ship's cockpit (since a picture of kittens wont fly in a serious mod).

also wouldn't mind the use of number activated weapons. the weapon panel takes up about a hundred or so pixels square, and i think the weapon select gauges being so big makes it somewhat inefficient. the text is a problem as well, its using a huge font, which i vew as a waste of space. you could instead show a picture of the weapon with a status bar under it to show the ammo load, instead of a bunch of text and number, if these icons are 20*20 pixels they could be stacked 5*5 for 25 different weapons. this is sort of what i had planned for my mfd, i was even gonna slave the mouse to it to draw a pointer so point and click weapon selections can be made. allow faster linking an selections to be made when there are of weapons.

that said id like to see more point and click on the hud. sure mouse flyers will object but i dont see why you cant have a toggle button to switch betweern flight and the interface. point and click communication, targeting, weapon select, ets gauges, ect. would really be an improvement to the interface.

[Backslash]

Oh indeed, all my code is being done with the idea of bumping those limits later.  I'd do it now but we need taylor's pilot file code overhaul first, and then some testing for how it is used in multiplayer (the packets etc).  [I've got a somewhat working version with limits of 8 each but it corrupts pilot files and doesn't work in multiplayer.]  I just said 3 and 4 because the art I was talking about only supported 2 and 3 respectively.

You bring up great points, some of which I've already thought about -- indeed, once we start dealing with higher numbers of weapons, control and display both become issues.  New controls are easy to do but must also wait on the pilot file overhaul.  Aye, the font is huge (and yet designed for 640x480!) -- I'd love to get a smaller more efficient one working but I have no idea what's involved there yet.  After I made the weapons gauge dynamic, it turned out there IS currently room for 8+8 weapons (I've tested!) if I shove the escort list upward.  I'm also making an option to split the primary and secondary gauges to different locations. 

As for drawing the weapon icon idea, yes, that is one of my goals.  Some of that is already in place but very limited and not used by hardly anyone.  I'll possibly combine it somewhat with the existing ballistic analog gauges.  All will be customizable as much as I can implement... and when you want to replace it with a scripted/RTT one, you'll be able to turn them off.

I'd also love to see the point and click idea, however that is way out of my league.  I'll try to leave spots for such expansion in the future.  I need to learn how to make simple hooks for such scripting.  Totally off topic but were such mouse interfacing to be implemented, I'd love to make a new target list gauge, I-war2 style

[Nuke]

i started some initial button code for the freespace rts. mainly using an if stack to determine if the mouse was over any button areas. i thought about scripting an object oriented way of dealing with buttons, and perhaps windows, option buttons, scrollbars and the like. but this is far from what i have time for. im pretty much using parallel arrays, sorta like in my ship meta system, where arrays each stored a piece of data about each button, and named accordingly. so theres essentially an array for each sides position, button type, gfx, etc. if you wanted info on a particular button, you could call it by that buttons index. this system turned out to be more dynamic than i had planned. adding a button could be as easy as calling a function (though i implemented mine with a fixed number of buttons with variable functionality, which will probably turn out to be a bad idea). 

as far as weapon behavior itself, id like the optional removal of the all or one implementation of weapon linking. id think my phoenix is a good example of a ship that would benefit from non-linkable weapons. since its 3 weapons systems are so different. you have gatling guns which are good at medium to close range (and probibly the most deadly on a damage/second basis), and then the long range dual railgun system, which is good for sniping and taking out turrets. and the last resort laser weapon (slightly more powerful than a prometheus) when youre out of energy and ammo. it might be feasable to link the gatling with the laser, but using the railgun would waste all the energy making the configuration useless, not to mention throw off the lead solution because of its much faster velocity. i wouldnt mind a non link flag to prevent a weapon from being linked with others (assuming its not implemented already).

when implementing weapon systems for battletech for example, a user controllable set of groupings and various fire modes would be a really good feature to have. some new bank management functions seem to have been added to lua, so that might be scriptable. one think ive always wanted was the ability to override individual gauges. i think hud tables can do this, at least let you remove the gauge youre replacing so you can lua over it. i wouldnt mind having a hook for each gauge, you would have access to the variables set in the hud_gauges.tbl. so you could pass those to a function to draw a scripted gauge using the parameters set in the table. you could allow modders to use a stack of scripts that are in essence modules that modders can use. so a new gauge script can be plugged in and the modder could implement it without touching script itself.

ive tried making scripts user friendly and it usually backfires and turns the script into what is in essence inefficient bloat. the advanced turret script, which i intended to be modular and modder friendly, just turned into a mess. and most of the code was written to work around some data i needed but couldnt get to directly. the code to manipulate a turret has been reduced by thanks to new functions.

those pesky pilot file upgrades seem to have been going on since day one, and have held back on some upgrades that ive wanted for awhile now. im glad taylor decided to put his foot down and hopefully solve the problem once and for all (assuming thats what has happened ). i know in quake c, making a new command was as easy as using an impulse event, which could be bound from a cfg file. it always annoyed me that freespace seemed to have a serious limitation to prevent the addition of new control functions (which have come out as what equates to a trickle) and input in general. the ability to define new input commands from script would be awesome. like a io.createInputFunction(name, section, type) to add a bindable entry to the games input mapper and return a handle to it (name being the string shown in the mapper, section being what sub menu of the mapper its in, such as ship or weapons, and type being axis or button). you could call that at game init. then have an io.getInputData(handle) to return the state of the axis or button assigned to it.

as good as the freespace hud is i still see plenty of room for improvement there, but other interfaces related to that (even loosely) still have an effect on the game engine's precieved modernness.