Arx Libertatis Bug Tracker
star_faded.png
Please log in to bookmark issues
feature_request_small.png
OPEN  Feature request #1005  -  Add support for wrapping script events
Posted May 17, 2017 - updated Jun 30, 2021   Shortlink: http://arx.vg/1005
action_vote_minus_faded.png
0
Votes
action_vote_plus_faded.png
Issue details
  • Type of issue
    Feature request
  • Status
     
    New
  • Assigned to
    Not assigned to anyone
  • Progress
       
  • Type of bug
    Not triaged
  • Likelihood
    Not triaged
  • Effect
    Not triaged
  • Posted by
     Daniel Scharrer
  • Owned by
    Not owned by anyone
  • Estimated time
    Not estimated
  • Category
    Not determined
  • Priority
    Not determined
  • Targetted for
    icon_milestones.png Not determined
  • OS
    icon_customdatatype.png Not determined
  • Architecture
    icon_customdatatype.png Not determined
  • Fixed in
    icon_customdatatype.png Not determined
Issue description
Mods (and fixes shipped with AL) should be able to execute script code before and after the game's script for a particular even are run without depending on the contents of the original scripts - ie, patching (feature request #1004) is not enough! This is required to allow multiple mods that modify the same entity to be used at the same time.

  • This should be possible for all entities of a class and for specific entity instances
  • Mods should be able to prevent further processing of the event


This could be done by introducing further override scripts that are consulted before the original scripts (or between the instance-specific and generic entity class scripts). Multiple mods should be able to provide override scripts for the same entity. These should be processed in order:

We should also provide a new post-event syntax for code that is run after the base scripts have processed that event. This code should be informed whether the base scripts accepted or rejected the even.

For example, if entity_0042 receives the init event the following code is run if all handlers accept the event (proposed additions highlighted):

  1. run "on init" in entity_0042.mod.asl from mod 1 (naming convention to be decided)
  2. run "on init" in entity_0042.mod.asl from mod 2
  3. run "on init" in entity_0042.asl
  4. run "on init" in entity.mod.asl from mod 1
  5. run "on init" in entity.mod.asl from mod 2
  6. run "on init" in entity.asl
  7. run "after init" in entity.asl with param "accept" (never exists except for entities added by mods)
  8. run "after init" in entity.mod.asl from mod 2 with param depending on the previous "after init" code
  9. run "after init" in entity.mod.asl from mod 1 with param depending on the previous "after init" code
  10. run "after init" in entity_0042.asl with param depending on the previous "after init" code (never exists except for entities added by mods)
  11. run "after init" in entity_0042.mod.asl from mod 2 with param depending on the previous "after init" code
  12. run "after init" in entity_0042.mod.asl from mod 1 with param depending on the previous "after init" code


Or if "on init" in entity.mod.asl from mod 1 refuses the event:

  1. run "on init" in entity_0042.mod.asl from mod 1 (naming convention to be decided)
  2. run "on init" in entity_0042.mod.asl from mod 2
  3. run "on init" in entity_0042.asl
  4. run "on init" in entity.mod.asl from mod 1
  5. run "after init" in entity.mod.asl from mod 1 with param "refuse" (TODO should this be called or just the next one directly?)
  6. run "after init" in entity_0042.asl with param depending on the previous "after init" code (never exists except for entities added by mods)
  7. run "after init" in entity_0042.mod.asl from mod 2 with param depending on the previous "after init" code
  8. run "after init" in entity_0042.mod.asl from mod 1 with param depending on the previous "after init" code


"after init" code cannot prevent "after init" code from later mods from being run

#4
icon_reply.pngReply
Comment posted by
 Daniel Scharrer
Jun 30, 20:51
Once scripts can be patched, look for TODO(patch-scripts) to see if those workarounds can be converted to patches instead.