improve "customAction" to offer additional results - and potentially much greater extensibility.

[scrom]

at the moment customAction is simply an array of supported custom action words. Any match on these redirects to "defaultResult".

Whilst this should continue to work, artefact and creature both have a method "getCustomActionResult" that should handle alternate results on custom actions.

we'd also need to change "getCustomAction" to alter behaviour depending on whether customAction was an object or array. (and ideally update our data).

This is all pretty viable but will need a couple of hours focus time and lots of testing.

2 further extensions of this:

• Review all actions where customAction is/is not checked. Ideally all actions should check customAction as soon as primary objects are found.
• CustomAction/defaultResult can redirect the player action to alternate supported verbs (and potentially specific different objects by returning through the action.act process. Given JS is a dynamic language, we should seriously consider supporting "script" that offers completely custom behaviour. (this is pretty standard in most text adventure engines) My thinking is this would involve having $script in the result (like $action/$result) and then act executing that script. We should probably also offer $file support at this point so that scripts can be written as standalone javascript files to import. This would require defining what objects/methods are available at "act" time (basically _player and _map) and the requirement that the custom action always return a string (which in itself could include $result, $action or even $script

I'd probably also include a +script cheat option that allows during play testing the ability to execute a preloaded script file (although this is a potential security hole if left in)

the main thing is that scripts are only executed engine-side

[scrom]

a good test example is the atrium guitar. it has strings that can be broken and a customAction "play". Play always returns the same result. Ideally this needs logic that checks if the strings are broken and returns a different result either way.