thats kind of a thing i think scripting would handle quite well. you can essentially stick your events into a text block and simoply have lua parse it all to events when the mission starts. so you can load a large number of events with a single script eval. this would centralize the feature and facilitate event reuse. there are some issues where the format that scripting likes to read events from differes from the way they are stored in the mission file, so there would be some parsing code (lua really shines with text manipulation). this is one of those cases where i wish i was a better fredder so i could give you a more solid framework for how to accomplish that.
This would be awesome. The trick here is to be able to load the same event blocks, but alter the arguments listed in these events...which I have no idea how to do.
that should be somewhat easy considering the events would all be text. it would be easy to say replace all instances of '<ship1>' with galactica for example. theoretically you could then load the events with a function call containing those arguments. but if you had a long list of ship names or variables, you would end up with a script eval that just wouldn't fit. if you had a long list of variables you could just load them into an arguments table and then use a table as an argument. you could also set it up as a state machine where you set the arguments with a bunch of individual function calls and then have a call to commit the changes once you've set all the parameters. could also go with the stack approach where you have a few generic functions whos job it is to add new arguments to the stack (a lua table internally but the fredder doesnt need to know that). each time you call it it adds those arguments to a list and when you call the function to load your events block, it uses that list for its arguments. you would have another function to clear the list as well.
we will call these functions addArgs() newArgs() and loadEvents() will load a set of events from a text file (the name of which would be its only argument). when called it is assumed that the arguments stack contains all the parameters needed by the event block. there would probibly be some error checking to make sure the arguments are in the right format and there are the correct number. i could then do some things for convenience, like make them vararg, so you could add as many arguments as you can fit, and they will stack in order. i could also make newArgs take arguments so that it acts like addArgs, but clears the arguments before loading its own. this would reduce the number of script evals neccisary. so the evals would contain something like:
addArgs("someshipname", 42)
addArgs("anothershipname")
loadEvents("eventfilename")
newArgs("newshipname", 21)
addArgs("averylonglongshipname") <-this is the longest thing you can put into a script eval iirc
addArgs("shortshipname", 69)
loadEvents("eventfilename2")
this loads 2 sets of events from 2 different files where the first event takes 3 args and the second 5. note that after the first event file is loaded the aruments are cleared with newArgs() and the new arguments are added in the same call
figure events would be loaded from text file for ease of use, which would contain another the events, and probibly some meta, containing info about how many arguments are expected and what type. this is nice because you only need to know 3 functions.
again i dont have any foreknowledge about the size of the events blocks, the diversity of data types those blocks use or anything like that. this is where a lack of fred knowhow really limits what i can do. but im tempted to figure it all out just to make spoon eat his words.
