From: Washington D.C.
Yes, I believe there is interest, and I believe this is not the first time it's come up.
To get good with LUA you really need a computer programming background. LUA is a fairly simple programming language and there's lots of documentation out there, but you need to be comfortable working from the language documentation and maybe a few very simple examples. I've been trying to post more of the code I write to do useful things in the LUA Legion. Some of it is very scenario specific, though. The way I write victory conditions often has a complex set of LUA conditions, for example, and I'm not sure that they'd readily translate to other people's stuff.
I think the best way to start scenario building is with short, violent engagements involving less than a dozen platforms (a.k.a. few-on-few). Over time you add complexity, maybe you need to move a small convoy protected by a few surface combatants to a specific area a few days away from a port? Then you build the scenario from there. Version 1 of the scenario has nothing but a submarine threat. Version 2 maybe you add in some naval bombers. Version 3 maybe there's a ballistic missiles out there. With each layer you add richness and depth, and you have to solve new problems. How do the ballistic missiles and naval bombers target the warships, for instance? Are the submarines sufficient ISR? Maybe you need to add in an OTH-B radar or a bunch of satellites to queue them. By the time you get to version 14 you have a fairly rich scenario just moving a few ships into a box somewhere.
Also, remember "Save As" is your best friend. Each time I make a change to a scenario, I do a "Save As" and change the version number. That way if I mess something up, I can go back easily. I also make notes in the scenario description about what I changed. It helps with traceability but it really is more about me articulating the problem I saw and how I fixed it. Sometimes I read what I wrote and think, "that was a stupid idea" and go back to the previous version.
When I start making a scenario, I usually start with the victory conditions. I don't necessarily mess with the scoring system (that usually happens as one of the last things). I just define clearly what "winning" the scenario looks like. "I win if I get all my tankers from A to B" or "I lost fewer than N aircraft" or "I crater the runway, destroy the AvGas storage, weapons storage bunker X (which is believed to contain chemical weapons) and destroy P% of the aircraft at base Y." That's important because what you're really doing is saying, "This is what the forces in conflict are trying to do."
Once I have that, the scenario just kind of builds on itself. I'll usually start with orders of battle from Baloogan's website, other places on the internet, books or the news just to develop a sense of what kinds of forces might be in conflict. Geography also shapes a lot of scenarios. If airplanes have to fly a long way, then maybe F-35 isn't going to be a big player, or if it is, I'm going to have to be really clever about tankers.
The other thing is, since one side needs to be computer controlled, to design good scenarios, you need to get good at taking advantage of the mission editor. If you're plotting each individual course and speed, then you're probably going to make a boring scenario because your AI on the opposite side is going to do EXACTLY THE SAME THING OVER AND OVER AGAIN. LUA is best used sparingly. The real trick is to use the zillions of options in the mission editor to get the behavior you want in the scenario. After that, you might consider events and LUA to make the AI a little smarter by dealing with questions like timing, sequencing of events, and important decision points (e.g. if I lose too many aircraft assume a defensive posture by reallocating aircraft to different missions).
< Message edited by SeaQueen -- 7/13/2018 2:25:14 AM >