regarding the original issue ( the discussion seems to go a teeny bit astray
)
Question: What is considered scripter/modders??? well I'm one of those who are in the awkward position of picking up the scripting stuff and working on something but having no releases so far whatsoever. would I have the "right" to vote? Or is it just based on self-judgement. If you judge yourself being able to contribute in a fair and constructive manner, can vote even if you have not released scripts?
One suggestion is that I think the poll should state clearly in subject or otherwise that it is seeking votes from fellow script developers (collective term for modders/scripters?) To distinguish the polls from developers who wants feedback from the pure script users?
Another suggestion for maintaining the script library + making decisions. Can there be a casual moderation group? basically, vote among moderation group to remove obselete scripts, give reviews and compatibility ratings if possible etc. Usually, just start a "moderation thread" where if get confirmation from at least 2 members (to make things go faster without having to wait for all to vote), then go ahead (unless there is objection from the rest, which will require full voting or debate).
One other thing I can think of regarding the limited game resources is:
why don't the experienced people (I don't have to name them. I think all who dabbles in scripting should know) propose some framework that could potentially save the slots? I am just managing the pure scripting part and not so familiar with the command slots yet, but are these possible?
1) Allow a cooperative set of scripts to register it's resources "softly" in-game and expose flags to enable/disable their registration (e.g. say a script hooks up 5 functions to ship commands of which I only use 3, I can opt to "release" the other 2 so that the setup script automatically don't hook them up (based on global registration info)).
This has the potential for automatic conflict resolution:
From the global register, if scripts finds the slots being used by another script currently, it tries to find an alternative slot automatically in the same category.
What this requires:
a) A framework that involves an in-game global variable (Array prob) that keeps track of slot resources in a soft-manner
b) A script which participates in this program should have it's setup-script modified to use some common library functions that registers it to an appropriate command slot, potentially with options to either do nothing if slot is used by somebody else, or find an alternate slot. Each successful "registration" should update the global register so that the next script in this framework will be informed correctly.
2) Having "soft" commands.
This is already being done in some scripts: using one slot with more complex parameters which acts as a dispatcher to call other scripts according to parameters provided. Although this has the benefit of being able to potentially use only 1 slot for a whole bunch of functions, it makes each use of the command very very painful. For configuration style of script calls, this is ok. But not for operations that has a real-time consideration (when you are commanding a battle, you don't have time to set so many stuff to change one ships's orders). So this is more suitable for the occasional commands that starts a complex and long task (or a standing task) e.g. Auto Traders, standing patrols etc.
3) hybrid "set&go" commands
Similar to 2, but has 2 parts. One command sets up the parameters, the 2nd one just executes the dispatcher based on currently set parameters. meaning that repeating a "command" with previously set parameters just take a simple invocation. But potentially more troublesome than previous way when have to switch commands (take 1 command invocation to set values, another to repeat.) possible improvement will be to make the first command execute in addition to setting parameters and the second one just repeat the first command;s invocation?
The last point seems a little useless on its own, but in one of the things I'm dreaming up, this has to potential to be very powerful in a group based ordering system.
imagine presetting the roles of ships (e.g. say I have 3 tactical command sets 1:Defensive, 2:Offensive, 3:Berserk), which I want. Defensive is suppsoed to make all ships protect the carrier. Offensive makes 2/3 of the fighters attack carrier's target, while 1/3 defend the carrier. Berserk will make all fighters attack all targets. (actually number of tactical command sets is unlimited)
Each fighter can be configured via a "set" script that sets it's role. e.g. an "offensive" fighter's parameters is configured to "defend home", "attack home;s target" , "attack all" for the 3 command sets (note it does not execute, just record the paramters somewhere as "command objects")
When something like "Execute Tactic" which takes in a number presenting the command set number is executed, a general command dispatcher script is executed for all group members that reads the command set number, then retrieve the parameters, and assign the approrpiate task for each ship basd on the paramters.
Such an example only requires 2 additional slots (1 to configure each ship's role with respect to a tactic number, 1 to execute a particular tactic number), yet provide a great possibilities in the behavior for a larger fleet.
eh... went offtrack too much with some of the ideas I am working on, but hope that it could be useful to the current discussion at hand, or maybe interest somebody to go write a "How to conserve our trees... eh.. I mean command slots" article.
get recycled.