[TOTPP] Lua Scenario Template

In Napoleon, we also use 'Tab' as the context-sensitive help key. 'Backspace' along with the number keys '1' through '6' provide various status reports, or allow you to access static help/info screens. (As you noted in regards to 'y', though, number keys have other effects in cheat mode.)

In the current major project that I'm working on, and hope to release shortly, I chose to use 'Backspace' as the context-sensitive help key, displaying info about the active unit and/or tile. 'Tab' is a "menu" key that brings up a dialog box allowing you to pick from a list of options which are not tied to the active unit. Most of these are status reports of one type or another, but a few allow you to initiate in-game actions that are not unit-specific. I guess I took this approach because I'm familiar with several other apps where 'Tab' is used to access an auxiliary menu, and that seemed the most natural or instinctive choice.

So overall, I'd say I like having both 'Tab' and 'Backspace' be available for help and supplemental functionality, and I'd be in favor of your proposal of using 'k' and 'u' as munitions keys -- which, if they're providing related functionality, have the added advantage of being close together on the keyboard.

 

I suppose this is probably better-placed here than in the Boudicca thread.

I've made more progress on the Designer Readme. I figured we'd need it, and it also gives me a useful reminder of what events I need to write, because I need to have an example for everything. I have "the high level" stuff done I think, but need specific usage examples still (kind of like I did with the object and parameter settings). I'm not wed to this structure necessarily but I think it makes sense (high level of what things do, then nitty gritty of how to do it with a matching example from the scenario for people to look to/copy/paste).

@Prof. Garfield if you would be so kind as to review page 9 and specifically the unit defeated/other situations and opine if there is a better way to describe those, I'd appreciate it. I'm sure you had specific usages in mind for the group but I don't fully understand them and could use a small paragraph that is better than mine for each.

 

As part of the template, I've added in functionality to avoid these situations in my Event Tools.

Code:

eventTools.guaranteeUnitActivation(tribe)

This makes sure there will be an active unit for the tribe. This is run afterProduction for each tribe, and if the guaranteed activating unit is destroyed, another one is created. The parameters file sets the location where these guaranteeing units will be created, and what unit type they are. For testing, I chose the North East side of the map, and the arrows unit.

You probably shouldn't destroy units in the combat resolution function. For the unit you want to lose, set its hitpoints to 0 and then return false. A better example would be a unit that is defeated by a reaction event.

It is probably worth mentioning that the unitDefeated, unitDeath, and unitDeleted functions exist in part to tie into other events, especially pre-made modules. For example, gen.defeatUnit is used in the reaction module, so putting code in the unitDefeated trigger allows that code to be run if a unit is destroyed in the reaction module. Otherwise, the player would have to "open up" the reaction module if they want stuff to happen when a unit is killed by a reaction.

Also FYI, I'm thinking it might make sense to add a unitDeathOutsideCombat function. It might make sense to want different events to occur if a unit is killed in combat versus if the unit dies of thirst in the desert, and that isn't straightforward to do with the current setup (though I think it would be possible).

It might be worth mentioning that the prefix helps when trying to use your text editor's autocomplete, since it filters out the other stuff. In fact, that was my original reason for "recommending" the prefixes in the first place.

Code:

..tostring(loser.type.name)..

FYI, loser.type.name is already a string, so you don't need to use tostring for that. It doesn't hurt anything, but it does make the lines longer.

Code:

onSchism–Out of thebox, prevents a civilization from splitting in two when its capital is taken. No modification is necessary unless you want the split to occur.

This is worth double checking, but I think this could be used to trigger an event any time a schism might occur, even if the schism doesn't actually happen.