[TOTPP] Lua Scenario Template

[Prof. Garfield]

EDIT: The Github repository: https://github.com/ProfGarfield/LuaTemplate

@JPetroski and I have decided to work on a template project that should considerably lower the barrier to entry for using Lua in Test of Time scenarios. Ideally, we'll provide the end user with a decent amount of 'Lua Power' without requiring programming. (You'll probably still have to understand the kinds of data that Lua uses, so that you can provide data in the way Lua expects it.)

We're going to try to pick a target level of functionality and make sure that is provided, without worrying too much about leaving room for new features. That way the project is well defined, and can be 'completed.' Completion is important, since then instructions and tutorials can explain a fixed product.

Comments, advice, and criticism will be welcome. After all, you'll (hopefully) be the ones using the system.

EDIT 17-Nov-2021: I made some pretty major changes to the template, so I'm attaching an earlier version just in case someone needs it.

 

[JPetroski]

I'm open to what the group says but I would like to strive for a template that achieves two things:

1. Allows a designer new to lua the ability to do what they currently do with as minimal grief as possible;
2. Understanding that there will be at least some grief, also providing the designer with enough "lua unique" features that make it worthwhile to go through the grief that is unavoidable.

I think if we don't have both of these, we run into "why bother?" type situations.

I think brevity (which we both suck at, by the way ) is going to be key here to make things as simple as possible to digest and understand, but I do think we need at least a few features (maybe shoot for 5-10 or so additional that would open up some big design opportunities). I'd suggest:

1. The zones/region system is extremely powerful and useful in many different ways. We should try to make it intuitive to designate certain areas zones or regions. I'd probably "ship" with an "Area of Recruitment" built into this.
2. The ranged attack is a popular choice that isn't going away. It's also already pretty user friendly with your modules.
3. The diplomacy system from Napoleon (where peace can be restored automatically). This is *huge* for a designer.
4. The city transfer system from Napoleon (kind of goes hand in hand with 3 I guess)
5. The strategic bombing system from OTR. I know this seems scenario specific but it really isn't. An action elsewhere on the map influencing the economy by removing improvements from a city could be tweaked to represent many things.
6. The Build Restrictions from various scenarios.
7. The menus system from OTR/Napoleon.
8. The counter mechanism from Napoleon and OTR as it is very useful for various events and much simplifies (yet also expands) the old way of doing things via a ton of flags.

I think these would pretty much blow the door open for designers to play around with.

 

[Prof. Garfield]

1. Allows a designer new to lua the ability to do what they currently do with as minimal grief as possible;
2. Understanding that there will be at least some grief, also providing the designer with enough "lua unique" features that make it worthwhile to go through the grief that is unavoidable.

That's a good way of putting it.

The easiest things to put into a template are what I would call "Rules Events." Things that define how the game works all the time. Stuff like munitions and building restrictions. We should probably have a consistent name for the files that we expect the designer to change (e.g. munitionsSettings.lua, canBuildSettings.lua, etc.)

Here are rules events that we'll include (this list can expand):

Ranged Attack
Reactions (but, a really simple version)
City Build Restrictions
Promotions and Demotions (must be built, includes stuff like double promotion, and demotion upon defeat)
Human to Human diplomacy tools (giving away units, etc)
Strategic Bombing
Trainlift
Leader Bonuses (simple version)

3. The diplomacy system from Napoleon (where peace can be restored automatically). This is *huge* for a designer.
4. The city transfer system from Napoleon (kind of goes hand in hand with 3 I guess)

This starts to open the door to what we might call "Trigger Events." That is to say, events that happen at a specific point and do things. At the moment, a designer must either program these, or use the Legacy Event Engine. Maintaining a diplomatic state is more of a Rules Event, but changing it would be a Trigger Event. Transferring cities is also a trigger event. Obviously, programming is the most flexible way to get trigger events, but I'd like to give a good deal of power without requiring programming. I'll have to write a "Modern Event Engine." That would end up including menus and counters and stuff.

 

[JPetroski]

That sounds like a good place to start with the "rules events." Why don't we see if we can get the 7 things you listed working and understandable and depending on how much time that takes, we can consider if 1-2 trigger events are worth it or beyond the scope.

 

[Prof. Garfield]

Here are my current thoughts for a 'replacement' macro system.

Trigger Events are divided into two parts, the 'trigger' part, and the 'action' part. They are both specified by tables.

Consider the action part, which we'll call an actionSpecification.

To perform an action, a function (actionFunction) takes the actionSpecification as an argument, and also takes other arguments that can be referenced by the actionSpecification (stuff that is not known when writing the event, like a specific location, or tribe) and performs the action. This could be used to simplify code if someone is writing events 'programming style', but it also means that a table can specify everything that is needed for the action of an event.

In a 'macro style', all the actionSpecifications are put into a larger table, and given a key. That way, the trigger part can reference them. The other arguments are provided based on the circumstances of the trigger.

Then, a triggerSpecification can determine if some trigger conditions are met, perhaps if some other conditions are true, and, if so, choose an actionSpecification (or several of them) to be performed.

This would basically be splitting up the IF and THEN parts of the legacy macro system, and putting them in two different tables. It would make sense to me, but I wonder if that would be unnecessarily confusing for others. There might also be an issue regarding the order in which event triggers are checked, and how to make AND conditions straightforward to use.

 

[JPetroski]

I'd really need to see a short example of the table you are contemplating to tell you if it'd be intuitive or not. You don't need to build it functional for these purposes but maybe just a 3-4 lines showing what you're considering? I guess I'm just concerned that maybe that isn't the issue?

I guess a question I have before we begin is where does everyone feel the hurdle truly is?

Let me ask a question specifically to @CurtSibling , @techumseh , @civ2units , @Patine as the four of you have expressed interest in using lua someday and are just starting to play around with it (I think @tootall_2012 probably has a much firmer grasp of it by now--probably more so than I do at this point--but I'll throw you in as well).

If you understand that the prefix "object" means that the events need to look for whatever comes after the "." following "object" in the attached "object" file, can you understand what is occurring in this event?

You'll note that after the 'object." there is a little prefix of c, t, x, and u. These are just naming conventions for the object file. It would make sense to standardize them, so I've adopted what Garfield gave me (I added x for text) but they could be anything that makes sense to you.

c = city
t = tribe
x = text
u = unit

Anyway, knowing that, read this and let me know if it seems insurmountable?

if city == object.cYanan and conqueror == object.tProWest then
    justOnce("YananCapturedCivilWar", function()
        civ.ui.text(func.splitlines(object.xFallOfYanan))
        civlua.createUnit(object.uChineseInf, object.tChina, {{84,58,0},{82,60,0},{87,57,0},{85,57,0},{81,61,0}}, {count=6, randomize=true, veteran=false})
    end)
    end

I think that all of you could write this above without much more trouble than the macro text. I think where it starts to get confusing is that in macro text, many of us would organize our events by tribe, situation, year, whatever. You can't really do that in lua. You need to put all of the city capture events in one section:

civ.scen.onCityTaken(function (city, defender)
local conqueror = civ.getCurrentTribe() 

--All of your city capture events need to be in this blank space here

end)

It's also confusing because setting up the events file is more complex than adding BEGIN and END to the start and finish (with the @ of course).

Further, I think what is really confusing, and a huge part of the problem, is that Caesar, Napoleon, and OTR are all written by three different coders who also were all taking a stab at this the first time. I'm sure @Grishnach, @Knighttime, and @Prof. Garfield would all agree they learned a lot in the process and have probably refined things since then. Further, they're all complex scenarios with giant, sprawling, confusing files. Midway isn't any better because it cannibalizes stuff from all three of these scenarios. The sci fi example that TNO put in place isn't a great example because it is too small and dated of a scenario that is missing most of the common events people actually need to use.

I'm just worried that maybe trying to rewrite macro isn't the true issue. It may seem like a small thing to a programmer, but the attached object file has made this a much simpler process for my designer head to wrap around... I put absolutely everything that I need to reference for an event into this file, basically like a second rules file, and then I plug in the information to some examples that I already have.

To list the issues I had trouble with:

1. Until you made your "Getting started with lua" thread, there wasn't a great reference guide on the internet because it didn't apply to Civ2. Your guide is a big help and anyone contemplating lua should go through the crash course.
2. The lua functions thread is only helpful once you have a chunk of experience behind you and understand what it means/implies. I can follow it somewhat now but it was hopeless earlier.
3. The sci fi example in my mind isn't very helpful both because of the limited scenario chosen.
4. The examples are all written by 3 different people in 3 different styles for in some cases extremely complicated scenarios.
5. Tables are very hard to understand at first in part because of issue 4 with the examples of them.
6. I tried learning in pre-modular days. I do think the modular system makes things considerably easier.

 

[civ2units]

Could you also add the possibility of the attack bonus Prof.Garfield sent me with the LUA scripts for my scenarios please?
I like the idea and would give the leader units a meaningful use.

 

[Prof. Garfield]

I'd really need to see a short example of the table you are contemplating to tell you if it'd be intuitive or not. You don't need to build it functional for these purposes but maybe just a 3-4 lines showing what you're considering? I guess I'm just concerned that maybe that isn't the issue?

I'm thinking it would look something like this

unitKilledTrigger["sampleTrigger"] = {
loserUnitType = object.uSettler,
winnerTribe = object.tWhite,
doAction = "settlerKilledAction1",
setLocation2 = "%WinnerHomeCity",
setCity2 = "%WinnerHomeCity",
}

actions["settlerKilledAction1"] = {
createUnitType = object.uSettler,
createUnitOwner = "%Tribe2",
createUnitLocation = "%Location2",
createUnitHomeCity = "%City2",
doAction = "settlerKilledAction2",
}

actions["settlerKilledAction2"]={
showText = object.xSettlerKilledText,
showTextTile = "Settler Captured",
showTextSubstitute1 = "%City2"
}

The idea is that when a unit is killed, the trigger checks if the loser is a settler, and the winner's Tribe is the white tribe. If these conditions are met, the action called "settlerKilledAction1" will be performed. setLocation2 and setCity2 change the information that will be fed to the action. By default, "%Location2" would be the tile the winner is standing on, but we want to use a different location, so we use setLocation2 to feed something different.

settlerKilledAction1 then creates a settler unit for the white tribe at the winner's home city, with that city's location. Another action, settlerKilledAction2, is then performed, which shows some text, and substitutes %STRING1 in that text for the name of City2, in this case the winner's home city. Chaining together multiple actions would allow the same kind of action to be performed more than once, and allow order to be specified.

Note also that another trigger could also do this action by selecting "settlerKilledAction1", but use a different tribe and location.

That's the idea. It would be a decent amount of work to write the 'engine' for this that interprets all the % values sensibly, but that would be hidden from the designer. I've been under the impression lately that getting people to use Lua will either require Designer/Programmer teams, or will require most of the work to be done without explicit programming knowledge from the designer. If a designer can get 80% of a scenario complete without programming, then there is some incentive to either learn how to do the last 20% for some cool custom features, or ask someone to do it.

Maybe I'm wrong, and all we need is to set stuff up in such a way that programming can be done in small bits. It would be much easier to write features that condense dozens of lines of code into a single function or just "fill in the details" (in some sense, that is what I've tried to do in the past) than to make every last thing specifiable by a table.

I think that all of you could write this above without much more trouble than the macro text. I think where it starts to get confusing is that in macro text, many of us would organize our events by tribe, situation, year, whatever. You can't really do that in lua. You need to put all of the city capture events in one section:

What you can do is split stuff into different functions, and then put those individual functions into the 'master.'

local function regionOneCityTakenEvents(city,defender)
-- regionOne city taken events
end
-- other stuff
local function regionTwoCityTakenEvents(city,defender)
-- region Two city taken events
end
-- other stuff
local function regionThreeCityTakenEvents(city,defender)
-- region Three city taken events
end

-- other stuff

civ.scen.onCityTaken(function (city, defender)

regionOneCityTakenEvents(city,defender)
regionTwoCityTakenEvents(city,defender)
regionThreeCityTakenEvents(city,defender)

end)

Further, I think what is really confusing, and a huge part of the problem, is that Caesar, Napoleon, and OTR are all written by three different coders who also were all taking a stab at this the first time. I'm sure @Grishnach, @Knighttime, and @Prof. Garfield would all agree they learned a lot in the process and have probably refined things since then. Further, they're all complex scenarios with giant, sprawling, confusing files. Midway isn't any better because it cannibalizes stuff from all three of these scenarios. The sci fi example that TNO put in place isn't a great example because it is too small and dated of a scenario that is missing most of the common events people actually need to use.

I agree. I was learning a lot in OTR, and, often, the first time you write code functionality, you don't think of the clearest way to do it. We were also about half way through before I learned to split stuff into multiple files.

To list the issues I had trouble with:

1. Until you made your "Getting started with lua" thread, there wasn't a great reference guide on the internet because it didn't apply to Civ2. Your guide is a big help and anyone contemplating lua should go through the crash course.
2. The lua functions thread is only helpful once you have a chunk of experience behind you and understand what it means/implies. I can follow it somewhat now but it was hopeless earlier.
3. The sci fi example in my mind isn't very helpful both because of the limited scenario chosen.
4. The examples are all written by 3 different people in 3 different styles for in some cases extremely complicated scenarios.
5. Tables are very hard to understand at first in part because of issue 4 with the examples of them.
6. I tried learning in pre-modular days. I do think the modular system makes things considerably easier.

Most of these issues have the same theme: Without experience, Lua and Lua events are confusing. After a certain threshold of experience, it becomes easier to learn more and use the tools available and ask for hep. If Civ II Lua is a ladder, the first step is missing.

My Lua lessons are meant to address this, though I'm not sure how well they work. Most of the feedback I got is from people who are already on the second step, either since they came with pre-existing programming knowledge, or they've been working with someone who has that knowledge.

 

[JPetroski]

That's the idea. It would be a decent amount of work to write the 'engine' for this that interprets all the % values sensibly, but that would be hidden from the designer. I've been under the impression lately that getting people to use Lua will either require Designer/Programmer teams, or will require most of the work to be done without explicit programming knowledge from the designer. If a designer can get 80% of a scenario complete without programming, then there is some incentive to either learn how to do the last 20% for some cool custom features, or ask someone to do it.

I'd shoot for getting people to the 80%. Maybe call it 85%, where the 5% is minor variations on the 80% (something like adding "or," or "and not" to tweak things slightly). If a scenario is 80-85% done, someone will help get it over the hump (either via coaching or doing it themselves), just as our artists do now.

Maybe I'm wrong, and all we need is to set stuff up in such a way that programming can be done in small bits. It would be much easier to write features that condense dozens of lines of code into a single function or just "fill in the details" (in some sense, that is what I've tried to do in the past) than to make every last thing specifiable by a table.

I really think part of the issue is that the examples are exceptionally complicated (OTR, Caesar, Napoleon, Midway) or sparse (Sci Fi). There's only 13 triggers, 19 actions, 5 modifiers, and 3 flag actions in the base game. I really think we should make a small, digestible, simple example scenario that covers all 13 triggers (with, at max, 3 examples of each, and perhaps just 2 if it gets too big--but you do need 2, because they need to see how to add a second event) and figure out a way to organize it in a way that is exceptionally simple and easy to understand with a goal being that we can say "here is your template, here are examples of all 13 trigger events in a working scenario, here is the object file, make this your own" and anyone who wants to can have a scenario with 26-39 events (or many more if they know how to copy and paste). Once we have that, we see if we can make it just as simple to use some of the "new" stuff (which is much more complicated).

I'll defer to what you think is best as you're the one that has to program this but if you did want a sample scenario, the actual "design/build" of Midway only took about 6 days and what I'm envisioning would be about 1/3 the size. It would not be a hard thing for me to crank something out that can accommodate this, if you think it has merit.

 

[JPetroski]

Anyone without much lua experience care to chime in? What are the things holding you back? How would you envision incorporating it? Do you think you could handle copying, pasting, and tweaking a city capture event that looks like this, or is this too complicated? I personally think you could handle it if you had a very clear guide/template/example, but... Perhaps I say this because I've been at this for awhile?

if city == object.cYanan and conqueror == object.tProWest then
   justOnce("YananCapturedCivilWar", function()
        civ.ui.text(func.splitlines(object.xFallOfYanan))
        civlua.createUnit(object.uChineseInf, object.tChina, {{84,58,0},{82,60,0},{87,57,0},{85,57,0},{81,61,0}}, {count=6, randomize=true, veteran=false})
    end)
    end

 

[Prof. Garfield]

Well, except for TOTPP bugs and multiple event files, the Legacy Event Engine means that we can provide the same level of functionality as the macro events, for the same skill level. I think that might be good enough for a 'version 1' of the template. Trying to make a "new macro system" means either losing a lot of the flexibility of Lua, or having a substantial list of key words and instructions to learn and understand, and maybe both at the same time. I'm pretty sure that any 'menu' event would be so convoluted to specify in a macro system as to be unworkable, for example.

Perhaps a little basic programming isn't much more difficult to do. There is a lot of merit to providing an 'example' scenario that doesn't implement complicated features (or, rather, those features are hidden away in modules). A sample scenario is an idea I like a lot, both for the teaching aspect, and just to test the template and make sure everything is tied together properly.

The issue might not be "I find macro events easy to do, and Lua events are hard or confusing to do," but rather "I know how to use macro events, and learning how to use Lua is hard work." If this is the case, then writing a 'new macro' system is almost certainly time and effort poorly spent, but offering "macro events plus" is worthwhile.

Perhaps part of the issue is that the scenarios that people want to make using Lua have new and complicated features, without which the scenario isn't worth building. Stuff like OTR, and @techumseh's Bismark. Something like that looks (and might be) overwhelming if you haven't programmed before. Perhaps we have to show how to enhance existing scenarios.

 

[JPetroski]

Well, I did use the legacy event engine to add munitions to Germanicus, so it is possible to take older stuff and update them a bit if one of the modular pieces is something you always dreamed of, so there is that.

Part of me thinks that organization is more important than exact structure (though to the extent structure can be simplified, that is preferable). I don't think any of us had much rhyme or reason to the order in which the events.lua file was written. Maybe we should strive to mimic the way the macro.txt are explained and ordered in the manual?

 

[Prof. Garfield]

I'm thinking that each for each of the "rules" event systems there will be 3 files: an 'Engine' file, where all the magic is done, and which shouldn't have to be looked at by the designer unless they are adventurous enough to add new features or fix bugs, a 'Settings' file, where they edit tables to specify the rules (and which has the most minimal amount of stuff they shouldn't touch), and a 'Documentation' file, where the table keys and other usage information is provided. At the moment, documentation is sort of split between the Engine and Settings file. The documentation might also be kept in those files as well, but having a separate file might prove useful.

File names aren't a huge issue, but they're a bit inconvenient to change, since you have to look at all the 'require' lines everywhere. Unless there is a better naming convention, I'll go with these names for these components:

Leader Bonuses

Allows a unit to increase the attack power of another unit activated on the same square.

Files: attackBonusEngine.lua, attackBonusSettings.lua, attackBonusDocumentation.lua

canBuild

Determines the available production options for cities.

Files: canBuildEngine.lua, canBuildDocumentation.lua,canBuildSettings.lua


munitions

A key press for an active unit generates some other unit, at some cost. Usually used for munitions, could be used for recruitment.

Files: munitionsEngine.lua, munitionsDocumentation.lua, munitionsSettingsPrimary.lua, munitionsSettingsSecondary.lua


reactions

Nearby units can damage a unit under certain circumstances, such as when it is generating a munition.
This will be a very simple version.

Files: reactionsEngineBase.lua, reactionsEngineSimple.lua, reactionsDocumentationSimple.lua, reactionsSettings.lua

The reactionsEngineSimple.lua file will convert reactionsSettings to functions for reactionsEngineBase.lua to use.


Promotions and Demotions

Takes care of stuff like 'elite' unit promotions and damaged unit demotions, that is units changing type.
Will probably include preventing units from gaining veteran status from barracks, and some other promotion related stuff.

Files: promotionEngine.lua, promotionDocumentation.lua, promotionSettings.lua

This must be built. I have some stuff, but it's not complete.


Diplomacy Tools

Takes care of giving away units and cities and other diplomacy stuff. Will probably also roll up enforcing static diplomacy (like in Napoleon) into this.

Files: might want to think about names for these, since this bridges the gaps between 'rules' and 'trigger events'

@old_hand wrote a lot of this already.


Strategic Bombing

Allows units on the map to be 'linked' to improvements in cities. Build the improvement, get the unit, kill the unit, destroy the improvement.

Files: stratBombingEngine.lua, stratBombingDocumentation.lua, stratBombingSettings.lua

Must build the entire thing. Maybe an alternate name might be advised, since there are uses outside WWII for this.


Trainlift

Allows airlift-like transportation, but only if there is a connection of some sort between the cities. A cost might exist also.

Files: trainliftEngine.lua, trainliftDocumentation.lua, trainliftSettings.lua, maybe trainliftEngineExtra.lua

This might not make it in. The pathfinding implementation I used might be too slow if there are a lot of valid paths, and so I might have to implement a different pathfinding algorithm.

 

[Prof. Garfield]

Part of me thinks that organization is more important than exact structure (though to the extent structure can be simplified, that is preferable). I don't think any of us had much rhyme or reason to the order in which the events.lua file was written. Maybe we should strive to mimic the way the macro.txt are explained and ordered in the manual?

As the post I just wrote above suggests, I think organization is important. (That post was partly for my own organization, as much as determining the best way for us to organize the lua files.) I'm not sure how much we can facilitate organizing actual events, though, since there are different ways someone might want to organize events. I suppose we could offer files for each of the 8 tribes (and a multi-tribe file), and in each file have a function for each trigger. We could then link that stuff up into the events.lua file.

 

[JPetroski]

So just for simplicity, if we built a scenario that only had one of those modules, the lua files in it would be:

Events.lua
Object.lua
canBuildEngine.lua
canBuildDocumentation.lua
canBuildSettings.lua

? If so, I like this and think it makes sense. We might want to use that tool @civ2units shared regarding the tech trees to do an "event map" for people to understand as well, ultimately.

Maybe an alternate name might be advised, since there are uses outside WWII for this.

How about "Connected Economy?"

I'm not sure how much we can facilitate organizing actual events, though, since there are different ways someone might want to organize events.

I think what we do is try to follow the ToT manual as much as possible for the trigger events, so this order:

AlphaCentauriArrival (if we even need this one)
BribeUnit
CityDestroyed
CityProduction
CityTaken
Negotiation
NoSchism
RandomTurn
ReceivedTechnology
ScenarioLoaded
Turn
TurnInterval
UnitKilled

And then our "extra" events in whatever order makes the most sense. People can move them around as they wish, but we just put it this way to start because that mirrors the manual they may already have. Is this possible, or do certain ones of these have to come before others? I know there are certain lines like "require" that need to be at the top, but I'm not sure if there's an issue with how these triggers are arranged.

We also might comment out some words that say

--[[@IF
BribeUnit ]]

To act as "headings" and further make it a little more recognizable.

 

[Prof. Garfield]

So just for simplicity, if we built a scenario that only had one of those modules, the lua files in it would be:

Events.lua
Object.lua
canBuildEngine.lua
canBuildDocumentation.lua
canBuildSettings.lua

? If so, I like this and think it makes sense. We might want to use that tool @civ2units shared regarding the tech trees to do an "event map" for people to understand as well, ultimately.

generalLibrary.lua, text.lua, flag.lua, counter.lua and possibly some other 'support' module file would be there as well. Perhaps instead of canBuildSettings.lua, we name the file as settingsCanBuild.lua, and have all the 'rules' files we expect designers to change begin with settings. They'd all be in the same part of the folder then, as well, when sorted alphabetically. Perhpas rulesCanBuild.lua might make even more sense.

I think what we do is try to follow the ToT manual as much as possible for the trigger events, so this order:

AlphaCentauriArrival (if we even need this one)
BribeUnit
CityDestroyed
CityProduction
CityTaken
Negotiation
NoSchism
RandomTurn
ReceivedTechnology
ScenarioLoaded
Turn
TurnInterval
UnitKilled

And then our "extra" events in whatever order makes the most sense. People can move them around as they wish, but we just put it this way to start because that mirrors the manual they may already have. Is this possible, or do certain ones of these have to come before others? I know there are certain lines like "require" that need to be at the top, but I'm not sure if there's an issue with how these triggers are arranged.

We can put them in that order. The order matters in events.lua when you're defining 'helper functions' and providing data (which we're going to move outside events.lua anyway), but there is no reason that CityDestroyed can't be defined before CityProduction, for example.

How about "Connected Economy?"

That seems reasonable.

 

[Prof. Garfield]

A few weeks ago in a different thread, @JPetroski , @Knighttime and I discussed loading different events for different tribes, or for single player and multi player.

I'm inclined to think that the best way to make that work is to have two 'kinds' of events: "universal" events and "context" events. Universal events happen in every 'version' of the scenario, but the 'context' events vary. There will be a value in the state table that determines what the 'context' is for a game, and the context event functions are stored in a table indexed by the different context values. When an event triggers, the context event is chosen and run, then the universal events are run. This would require a different saved scenario for each context, but otherwise would be seamless to the player.

local unitKilledContextEvents = {}
unitKilledContextEvents["singlePlayer"] = unitKilledFnSP
unitKilledContextEvents["multiPlayer"] = unitKilledFnMP

civ.scen.onUnitKilled(function (defender, attacker)
unitKilledContextEvents[state.context](defender,attacker)
unitKilledUniversalEvents(defender,attacker)
end)

Actually, now that I think about it, instead of a scenario file for each context, all we need is a function 'determineContext', that is

civ.scen.onUnitKilled(function(defender,attacker)
if not state.context then
sate.context = determineContext()
end
unitKilledContextEvents[state.context](defender,attacker)
unitKilledUniversalEvents(defender,attacker)
end)

I think the only issue would be that you couldn't have a context event in onScnearioLoaded (or, onLoad), since it won't correctly detect the human player(s) when you start the scenario.

 

[Prof. Garfield]

Just made a quick test, and it turns out that we can keep code in folders within the scenario's folder very easily. All you have to do is add the folder to the require, that is, if you have a folder named 'static' (since the files don't need to be changed -- there is probably a better name), then, for example,

local canBuildFunctions = require("canBuild")

becomes

local canBuildFunctions = require("static\\canBuild")

This should be very helpful in organizing code, and 'hiding' files that won't be needed by everyone. I'll probably hide away context events into their own folder, so as not to distract designers that don't need them.

 

[Prof. Garfield]

In Over the Reich, the munition generation keys are 'k' and 'backspace', while 'u' is a sort of supplemental functionality key, and tab is help.

I'm wondering if it would be better to make 'k' and 'u' the munition keys, with 'backspace' the supplemental functionality key. 'y' also seems to be available, except that it seems to toggle reveal entire map when cheat mode is enabled, and that would be quite the annoyance during testing.

Does anyone have any thoughts?

 

[JPetroski]

Just so long as 'k' stays the same, 'u' is fine for the 2nd one. I think k is pretty well established as "attack" at this point.