Yes, it is possible, but just not right now.
I'm guessing this is where the "very esoteric mission script" comes in?
-S'Cipio
lol... actually, its a combination of scripting and one of either using SQL and/or fixing the scripting API, preferably the latter, but both would be even better. Unfortunately the latter depends largely on the client code. Without the client code, SQL could be used as a workaround for a lot of things, but then they would only work on a SQL server with mission scripts specifically written to run on SQL servers (and also requiring some other additional programming), hence the simpler explanation.
Basically, if the mGetFighters() function was working in the API, the mission script could determine what fighters were actually on any given ship or base, and as they were deployed, we could simply then use mSetFighters(), which works, to keep adding more fighters to a ship or base. What we can do quite easily however, at the moment, is create a fighter group in the same way an AI ship is created, but such a fighter group is independant of any carrier. Possible uses for this include, for example, a planetary assault where the planet appears to send out a new fighter squad say every 5 minutes, or an armada of fighters launched from a hypothetical carrier that is off the map appearing at the map edge and moving in to attack something (eg. the Cylon fighter armada at the beginning of Battlestar Galactica). Again to really make such scenarios work though, we need to be able to choose fighters from the fighter list appropriate for the mission and era, which currently has a problem because of another drawback in the API. Currently, the API does not set the year date in the mission script, so the mission script has no way of knowing directly what game year it is (which is the cause for ships appearing out of era when using the create ship methods for AI). Magnum Man's shiplist utilities in the API are excellent for choosing the precise AI ship we want, and thus perfect for GSA, unfortunately in a D2 campaign, we still run into the problem of not knowing what game year it is. We could possibly use SQL to retrieve the game year from the database via the mission script, and so SQL mission scripts (with a suitably programmed interface connecting scripts to the DB) would allow us to do all the above, but then it would only run on a SQL server.
So... there you have it! Arent you glad you asked now... lol.