Lots of great comments here.
@CurtSibling, some of this discussion has kind of hijacked your original thread, and I feel a little responsible for providing the spark! But I also feel like it's a really important conversation that needed to happen and multiple people can hopefully benefit.
Wish I could comment on everyone's recent posts, but that would make this post far too long. I used the Like button on multiple posts above, and will try to quote and respond only to those where I have something more to add than "Agree 100%!"
If you can get your head around Flags in the Macro system, then starting with Lua will be no problem for a seasoned designer like yourself.

IMHO, the macro system was a real breakthrough in its time, but unfortunately has quirky rules, unreasonable limitations, and convoluted implementations (like Flags). But all this is manageable because it's
small -- there's a limited number of valid commands, and a designer who spends time working within it probably feels like they know all of them pretty well. But of course small in scope means that power is limited as well as complexity.
(EDIT: I'm sorry if that sounds too harsh. There certainly have been many fantastic scenarios created using macro, by designers who pushed it to its limits, and I sincerely admire the dedication it took to do so.)
In comparison, Lua can feel (and is)
huge. But it isn't necessarily
harder. In some ways, the rules are more consistent, the language is more rational and less arbitrary (i.e., there's better justification for why things work the way they do), and the error handling is better. It's the larger scope that makes it seem daunting.
This vastly expanded set of possibilities means that it would take considerably longer to
master than macro did. But you certainly don't have to master every nuance of Lua in order to produce useful and interesting events that can add a ton of value to a scenario.
I know there are different ways to achieve the same thing with Lua, with various designers having their own method, all them excellent.
I for one would be happy to see us all agree on what we could call a "Civ2 SL style" of Lua, just so we are all on the same hymn book page.
I think it would be reasonable (and perhaps a better goal for the community right now) to aim for a "Civ2
LST style" of Lua -- LST meaning Lua Scenario Template, as written (and primarily supported) by
@Prof. Garfield. I think that definition and focus will help to alleviate some of the first issue regarding different preferences by different designers. There may be multiple ways to achieve the same goal in
Lua, and programmers are notorious for endless debates about whose code or approach is better!

But given the way Prof. Garfield has written his template, and recognizing him as the expert in how it's intended to be used, I believe it would be much easier to coalesce around a single preferred approach to implementing a given event with that scope clarification.
Here's the designers readme which is unfinished (I had intended to add some examples and links) but at least talks about what is in every different folder. A read through should at least break down the mystery of what goes in what box.
John, this is an excellent document already and I'm sure you have ideas to make it even better. I would propose that as soon as this can be completed, it ought to be included in the base download of the template (not just with Boudicca, although it's fine there too of course), so that every designer gets this alongside the files and folders that it describes.
... you might need to put
"if turn >= 1 and civ.hasTech..." in the front instead. I'd ask for feedback from the pros on that.
There's no need to add a check for "turn >= 1" to any event. That will
always evaluate to true, so it wouldn't change anything. On the other hand, there could be a use case for adding "turn > 1" for events that you want to fire on every turn
after the first turn (but not as soon as someone begins a new game with your scenario).
onTurn - event fires the first turn that the game realizes that it Soviets have this tech. May or may not mean it fires the 2nd turn that they have it (I'm not clear on this). Will fire for "first" civ (think in the old days when we deliberately picked civ order based on event order).
afterProduction - event fires after a certain civ starts producing something(?) this event is utilized to make sure that you don't need to worry about civ order - you can define the specific civ's turn that it'll fire on
The word "turn" is often used two ways to mean two different things. In the strict Lua sense, a "turn" of the game is more like what you might call a round. It begins at the point when the date counter increments. The game performs some calculations of its own, then the barbarians play, then tribe 1 plays (the traditionally "white" tribe), then tribe 2 etc. on through tribe 7 (the traditionally "purple" tribe). That ends a single turn.
The onTurn trigger fires once at the
beginning of that process -- right away when the date counter increments, before any tribe (including the barbarians) plays. It will not fire again at any point
during the turn (between tribes). So any code you put in this trigger will be checked once per turn (or round), always after tribe 7 and before the barbarians or tribe 1.
(
@Prof. Garfield, please correct me if I'm wrong with this next part...) The afterProduction event is actually a LST enhancement that isn't a "native" Lua trigger. It runs multiple times during a turn,
once for every active tribe, always after that tribe finishes processing its cities and before it moves any units. So if you want an event's condition to be checked
between the play of each tribe, the code should go here rather than in onTurn.
There isn't a right or wrong answer for which one to use -- it all depends on what you intend for that particular event.
I've also been playing around with unitActivation frequently. Honestly I think the reason I went with unitActivation is because I wanted an event to fire the same turn that I got the tech, right after I got the tech -- but I'm not 100% this was necessary, I just know it works.
So whereas afterProduction fires once for each player, before they move their
first unit, unitActivation fires over and over again while they play, before they move
each unit. In John's example, putting the code in afterProduction would work great if all techs were acquired by research. But since techs can also (presumably) be acquired by theft, trade, or conquest
during each player's turn, putting his code in afterProduction means that a tech acquired in one of those ways wouldn't be recognized by the event until that player's
next turn (i.e., in the next round). So putting the code in unitActivation will make sure that it runs almost immediately.
The downside to this is that code you put in this trigger gets run very frequently, and if the code takes a long time to run, there could be a noticeable lag for the player. For example, in Medieval Millennium I have some events that scan the entire map, one tile at a time, and perform dozens of calculations or checks for each tile. If that code takes 1 second to run, putting it in unitActivation would lead to a one-second "pause" every time a new unit activated, and that would start to get pretty annoying to the player. But since I put this in onTurn, a one-second delay after tribe 7 and before tribe 0 isn't even noticeable.
Is this helpful? Looking for input here. It feels like the question of "where do I put this code" is so prevalent that every designer is going to need to be able to figure out on their own
why a given location is best, without asking over and over again -- in other words, teaching people to fish instead of giving them fish.

What would those of you trying to learn Lua right now find most valuable?
Just one question:
What is the difference between "~=" and "==" in this code?
As JPetroski said,
~= means "not equal to". Lua is a bit odd for using that syntax, since most programming languages use either
<> or
!=
== means "is equal to". This is a
comparison operator used in a conditional statement (like an "if" or "while" statement).
= means "make equal to". This is the
assignment operator used in the effect of an event when you want to change a value, not just check it.