* Added that the list of units always contain (and X of other types), if X > 0. I prefered this rather than the %UNITLISTEDUNITS because the string customized by the user of the events would have something as ugly as (and %UNITSLISTEDUNITS of other types) even if that was 0... But I am open to change this if you prefer other way.
Your way is better.
I've been looking into your canBuild.lua and flag.lua - and I want to be sure I fully undertsand. The approach you did was to put the flags for canBuild in a separate file. My approach for diplomacy was to pass an "option" parameter to the main dialog function where you can customize any of the options. That way, in the events.lua itself you can customize whatever you want for that scenario.
What approach of those two you prefer and why? I am really open to change the way I've done it, I just want to know how and why
I use the method of passing a parameter table to the function in the munitions module, so it is fine. This has the advantage of being able to change the parameters just before use.
I have a few reasons for using separate functions to provide parameter tables to modules.
1. Sometimes it is necessary, or at least convenient for organizing files. I don't know of another way (except global variables) to provide the state table to modules that are likely to be used in multiple files and modules, like flag, counter, and text. Even if not strictly 'necessary,' it might force certain parameter tables to be defined in inconvenient files, so that all the .lua files that need to 'require' those tables actually
can require them.
2. Sometimes, there are a lot of parameters to feed in. In Over the Reich, I think my reaction functions had 3 lines of arguments to be filled in, which was annoying, and potentially error prone, both for the end result (even if it is used only once or twice), and for writing helper functions in the module. If you have to use a function many times, keeping track of the names (and order) of even one or two parameter tables can get a bit annoying.
3. It simplifies instructions about how to use the module (especially for those who don't have programming experience outside Civ II Lua). If I can provide a template file and have a couple lines at the bottom 'linking' the tables to the module, then the end user just has to have a 'require' line somewhere, and use the function with the 'obvious' arguments. Have a look at the munition module (and the usage instructions at the top), and then the
munition module thread, where I offered some additional usage explanation to JPetroski, on stuff that seemed pretty obvious to me. I was happy to give the explanation, but it would probably have been less work to link parameters, if it were possible in that case.
Also, passing several tables would either mean separate files, or bundling multiple tables into a 'super' table to return, and then 'unpacked' into multiple tables in the events.lua file. (I tried returning multiple tables, but require doesn't seem to like that.)
* Added the subscract option (see screenshot after the text)
It's "subtract", not "substract".
Also, maybe send a message to the receiving player about the gift (if not already implemented). There is a function in text, displayNextOpportunity (might not be exact function name), that will do that automatically.