Project

General

Profile

Feature #1617

Scoped definitions and variables

Added by skyjake over 10 years ago. Updated over 7 years ago.

Status:
New
Priority:
High
Assignee:
Deng Team
Category:
Redesign
Target version:
Start date:
2013-10-21
% Done:

0%


Description

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


Subtasks

Feature #1621: Evaluation of runtime conditionsClosed


Related issues

Related to Feature #1264: Conditional decorationsNew2003-08-12

Related to Feature #1244: Scripting in model definitions (e.g., dependent on player health)Closed2003-07-20

Related to Feature #1616: Selector for spritesNew2013-10-21

Related to Feature #1618: Decorations/effects for game events (power up, damage, etc.)New2013-10-21

Related to Feature #1290: Session-only cvarsNew2003-09-23

Related to Feature #1300: Differentiating variants of monster attacksClosed2003-10-05

Related to Feature #1305: Particle generator flag: instantly kill generatorNew2003-10-06

Related to Feature #1620: XG 2.0Progressed2010-04-20

Related to Feature #1374: XG refs: logical NOTNew2005-04-01

Related to Feature #1376: Externally spawned mobjsNew2005-04-02

Related to Feature #1394: Consistent map scoping in definitionsNew2005-11-06

Related to Feature #1489: Separate decor definitions for different plane typesNew2009-04-16

Related to Feature #1539: Armor, powerups (object status) controls 3D model representationProgressed2011-06-18

Related to Feature #1555: Add dynamic lights without having to alter the mob defRejected2012-03-06

Related to Bug #346: Overriding Map Info in addons (level par time; jdep)Closed2006-08-28

Related to Bug #251: [Doom] Nightmare monsters sometimes not fastProgressed2005-08-23

Related to Feature #2241: Configure games via Home UI (advanced users, cf. autoexec.cfg)Progressed2017-04-05

History

#1 Updated by skyjake over 10 years ago

  • Assignee set to Deng Team

#2 Updated by skyjake over 10 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 Config).

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 Config.game.

#3 Updated by skyjake over 10 years ago

  • Tracker changed from Bug to Feature

#4 Updated by skyjake over 10 years ago

  • Description updated (diff)

#5 Updated by skyjake over 10 years ago

  • Tags changed from Definitions, Scripting to Definitions, Scripting, ACS

#6 Updated by skyjake over 7 years ago

  • Target version set to Modding

#7 Updated by skyjake almost 7 years ago

  • Related to Feature #2241: Configure games via Home UI (advanced users, cf. autoexec.cfg) added

Also available in: Atom PDF