Scoped definitions and variables
Often it is necessary to limit the effect of some definition or variable to a specific map, episode, game, global variable state, or perhaps even a single room in a map. This need manifests in several places:
- A mod/TC might want to override certain variables/definitions for an entire game.
- All the maps of an episode might want to use a specific sky texture.
- Particle effects may be defined for specific sectors in a map (e.g., rain).
- Light source definitions target a specific map in a game/WAD.
- Model definitions target a certain type of object in specific states.
- XG effects need to target certain lines and/or sectors (done via various XG references).
In other words, "scoping" is a universal need in the engine. There should be a uniform way to handle this a unified, powerful manner using a syntax that is consistent in all use cases.
See also: DED 2.0 and Resource URIs proposals
#1 Updated by skyjake over 9 years ago
- Assignee set to Deng Team
#2 Updated by skyjake over 9 years ago
In practice, libdeng2's
Record could play a major role in resolving these scopes. Similarly to how Doomsday Script namespaces and a process's stack works, we could set up a stack of records where variables are looked for. More specific scopes, like a map-specific record, would then override more global ones (like
This could be generalized to cvars, too, when they are stored in records. For instance, the Doom-specific
Config.game.doom would override the global
#3 Updated by skyjake over 9 years ago
- Tracker changed from Bug to Feature
#4 Updated by skyjake over 9 years ago
- Description updated (diff)
#5 Updated by skyjake over 9 years ago
- Tags changed from Definitions, Scripting to Definitions, Scripting, ACS
#6 Updated by skyjake over 6 years ago
- Target version set to Modding
#7 Updated by skyjake almost 6 years ago
- Related to Feature #2241: Configure games via Home UI (advanced users, cf. autoexec.cfg) added