I have messaged Nuke--with whom I was working on this project--about this idea, but he has not yet responded, so I don't even know for certain if he is interested in resuming this project at present. As such, consider the following post with a mostly hypothetical intent.
(http://www.game-warden.com/masterpokey/FS2OpenRTS/fsrts.png) (http://www.hard-light.net/forums/index.php/topic,51936.new.html#new)
My idea was to put some (most) of the RTS mod's code in C format, rather than doing it in Lua.
My thinking is that this would improve speed and would allow it to be more event-driven, rather than state-driven. As an example, our current 'mouse-click' code is triggered not by an event but by a test of whether the mouse is pressed against a record of the state during the previous frame. An event-driven version of this would fix the problems that occur with low framerates (like being able to click for a duration shorter than the frame, thus not triggering a click event but triggering events that currently rely on whether or not certain invisible weapon objects are in play--a system which works but feels very icky to me, and I'd gladly do away with given half the chance.
We might need a little help from a coder, but I hear they are hard to come by, so drop-in advice is just as appreciated as realtime coaching/work.
I was thinking that a launcher flag to toggle RTS mod features on or off would be useful, but Goober5000 said that doing so would be a 'very bad idea'. I still believe a launcher flag might be a good way to do it, but I think what triggered that remark was the idea of conditionally loading an external TBL file depending on the checked-or-unchecked state of that launcher flag, which could cause a crash or some other sort of error if the flag were checked but not such TBL were present.
So my current idea for external media/etc., which is still in need of expert advice: A launcher flag, plus a new set of table entries, or an optional table. The table entries/table would still be parsed, but they wouldn't be used (unless someone else finds a concurrent and compatible use for the data). The optional table would be checked for, but if it isn't found, it would have to NOT crash, but instead just move along and assume default values/properties. Goober suggested ai_profiles as a place to put such data, is that a good choice?
As for the sort of data/table entries we would need, we need to store information about ship costs, special (RTS) orders accepted, resource carrying capacity, jump drive charge time, etc., either on a per-ship-class basis, or on a ship type basis. Or both.
To make things easy, if Nuke thinks it is a good idea, I would request (but am not making such a request yet) that a coder could make functions to process input and manage the display for us, as well as pointing out the names and how to use all the functions that are necessary to get state info, trigger actions, etc. (probably as the need arises, rather than presented in advance and then being unnecessary/insufficient); effectively, someone we can quickly ask how to perform a certain task, and get a simple "like this..." or "for what, NO that's a bad idea, instead do this" answer.