Tracker: Issueshttps://tracker.dengine.net/https://tracker.dengine.net/favicon.ico?13985035312015-02-11T17:51:31ZTracker
Redmine Doomsday Engine - Feature #1970 (New): Scriptable map entry/exit, cyclinghttps://tracker.dengine.net/issues/19702015-02-11T17:51:31Zskyjake
<p>Use Doomsday Script to perform actions after loading a map and when exiting a map. While this is useful for map cycling (restart a co-op episode from beginning after completion), it is also a good modding feature. The key is to define different scopes for the scripts, e.g., a scope for the server's multiplayer behavior, or another for the map's own behavior as intended by its author.</p> Doomsday Engine - Feature #1633 (New): Console commands and Doomsday Scripthttps://tracker.dengine.net/issues/16332013-10-22T15:32:55Zskyjake
<p>The interactive console is intended to be a nice and easy way to modify engine configuration and execute certain commands. Doomsday Script, on the hand, is not as well-suited for interactive use as it has a more complicated syntax.</p>
<p>Presently (1.12), the console subsystem goes all the way back to the start of the project, and is not a very clean implementation. It should be completely replaced with a translation layer that parses the console command syntax and maps it to equivant Doomsday Script.</p>
<p>In practice this means that all the console variables and commands need to be mapped into some location visible to Doomsday Script, e.g., <code>rend-model</code> in libdoom → <code>Config.plugin.doom.rend.model</code> (dashes automatically converted to dots thanks to <code>PathTree</code>).</p> Doomsday Engine - Feature #1632 (New): InFine 2.0 (on top of Doomsday Script)https://tracker.dengine.net/issues/16322013-10-22T15:09:43Zskyjake
<p>InFine is a specialized language for specifying UI animation scripts. It also has some features for interactivity, however there is a need (<a class="issue tracker-2 status-1 priority-4 priority-highest child" title="Feature: Implement game menus with InFine (InfineWidget) (New)" href="https://tracker.dengine.net/issues/1630">#1630</a>) to expand that much further.</p>
<p>InFine should be redesigned to be a convenience layer over Doomsday Script. In practice, each InFine command would be automatically translated to a Doomsday Script function call. InFine objects would be regular variables inside a script process reserved for running the animation.</p>
<p>This way Doomsday Script can provide a powerful basis for extending the capabilities of InFine into containing whatever logic is needed by the animations and/or UIs. InFine would remain as a convenience/backwards compatible language for specifying finales, animations, and UIs.</p>
<p>Also, plain Doomsday Script can be used to manipulate InFine objects freely through variables.</p> Doomsday Engine - Feature #1630 (New): Implement game menus with InFine (InfineWidget)https://tracker.dengine.net/issues/16302013-10-22T10:20:08Zskyjake
<p>It is not ideal that game menus are completely hard-coded into the game plugins. Also, implementing the game menus directly on Doomsday UI widgets makes quite a large leap from generic components into game-specific ones.</p>
<p>One solution would be to replace the game plugins'/libcommon menu system with an InFine-based one. This would consolidate existing subsystems in a nice way, and act as a good use case for interactive, script-based InFine. It is also a good match for InFine because it is responsible for game-side UI animations; only the interactivity and scripted logic needs enhancing.</p>
<p>InFine-based menus would be easily extensible/modifiable by addons, especially if the functions activated by menu items would be implemented as script functions.</p>
<p>In practice, InFine would likely have to be refactored to use a separate Doomsday widget (<code>InfineWidget</code>) per each InFine layer (the menu, including all its subpages, would be a single layer).</p> Doomsday Engine - Feature #1620 (Progressed): XG 2.0https://tracker.dengine.net/issues/16202013-10-21T16:41:25Zskyjake
<p>XG 1.0 is quite limited and contains plenty of hard-coded functionality. It needs to be integrated with Doomsday Script and other powerful mechanisms like a generic scoping system.</p> Doomsday Engine - Feature #1618 (New): Decorations/effects for game events (power up, damage, etc.)https://tracker.dengine.net/issues/16182013-10-21T08:28:34Zskyjake
<p>Creation of an external definition to govern the visual effects of power-ups, damage, killed etc.</p>
<p>Maybe a standard definition (effects only) that is added to main definition (so that scaling etc is still correct).</p>
<p><em>(copied from an accidentally deleted old RFE called "Power Up Effects")</em></p> Doomsday Engine - Feature #1617 (New): Scoped definitions and variableshttps://tracker.dengine.net/issues/16172013-10-21T07:43:44Zskyjake
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:
<ul>
<li>A mod/TC might want to override certain variables/definitions for an entire game.</li>
<li>All the maps of an episode might want to use a specific sky texture.</li>
<li>Particle effects may be defined for specific sectors in a map (e.g., rain).</li>
<li>Light source definitions target a specific map in a game/WAD.</li>
<li>Model definitions target a certain type of object in specific states.</li>
<li>XG effects need to target certain lines and/or sectors (done via various XG references).</li>
</ul>
<p>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.</p>
<p>See also: <a href="http://dengine.net/dew/index.php?title=DED_2.0" class="external">DED 2.0</a> and <a href="http://dengine.net/dew/index.php?title=Resource_URIs" class="external">Resource URIs</a> proposals</p> Doomsday Engine - Feature #1608 (Progressed): Integrate Doomsday Scripthttps://tracker.dengine.net/issues/16082013-10-19T18:57:48Zskyjake
<a href="http://dengine.net/dew/index.php?title=Doomsday_Script_reference" class="external">Doomsday Script</a> should be integrated into all relevant subsystems.
<ul>
<li>Console should allow executing scripts.</li>
<li>InFine should allow embedding scripts within the animation commands.</li>
<li>XG should allow scripts for defining functionality instead of hard-coded line/sector classes.</li>
<li>Definitions should allow embedded scripts (via <code>ScriptedInfo</code>).</li>
<li>Game objects/entities should allow thinkers implemented as script functions.</li>
<li>UI logic and menu structure should be implemented as scripts.</li>
</ul> Doomsday Engine - Feature #1539 (Progressed): Armor, powerups (object status) controls 3D model r...https://tracker.dengine.net/issues/15392011-06-18T00:09:28Zzoeikonzoeikon@users.sourceforge.net
<p>In jHexen, when you pick up pieces of armor, they affect your armor class and stick with you. It would be neato to be able to assign particular models for such cases so that you can see the players wearing such pieces of armor or enhancements.</p>
<p><strong>Labels:</strong> Graphics</p> Doomsday Engine - Feature #1537 (New): [XG] Activation event option when changing line typeshttps://tracker.dengine.net/issues/15372011-05-15T16:00:24Zvermil
<p>A way to send an (de)activation event immediately after changing a line type.</p>
<p><strong>Labels:</strong> XG</p> Doomsday Engine - Feature #1524 (New): [XG] Ability to do anything with ammo, weapons and artefactshttps://tracker.dengine.net/issues/15242010-10-26T20:49:41Zvermil
<p>XG can be used to alter (i.e add or remove) the player’s health, armour and keys in various ways and all can be requirements (i.e. line X won't activate if the player doesn't have a blue key card and more than 150 armour).</p>
<p>However, there is no similar set of functions for ammo, weapons (including HeXen weapon pieces) or artefacts. XG can't alter or use any of these as a requirement at tall.</p>
<p><strong>Labels:</strong> XG</p> Doomsday Engine - Feature #1394 (New): Consistent map scoping in definitionshttps://tracker.dengine.net/issues/13942005-11-06T10:50:15Zyagisanyagisan@users.sourceforge.net
<p>When setting BIAS light source definitions I can set<br />the map like this:</p>
<p>Map = "e1m3|doom|iwad|doom1-ultimate"</p>
<p>But when setting map for anything else that format is<br />not understood, and I need to set it like this:</p>
<p>Map = "E1M3"</p>
<p>This makes it rather difficult to set up DEDs that<br />should only be active in specific pwads. I think the<br />DED code should be updated so that:<br />Map = "e1m3|doom|iwad|doom1-ultimate" formated strings<br />are understood by all other objects.</p> Doomsday Engine - Feature #1331 (New): [InFine] Evaluate cvars with IF conditionhttps://tracker.dengine.net/issues/13312004-02-20T18:49:30Zdanijdanij@dengine.net
<p>Would it be possible for InFine to evaluate CVARS using:</p>
<p>IF (cvar) (argument) DO</p>
<p>;<br />ELSE DO</p>
<p>;</p>
<p>This would open up all kinds of possibilities for scripted <br />animations or even fully interactive computer terminals <br />in custom wads...</p>
<p>This would require either the ability to define custom <br />cvars via a ded file or a bank of empty cvars that level <br />authors can use for scripting via both XG and InFine.</p>
<p><strong>Labels:</strong> Scripting</p> Doomsday Engine - Feature #1301 (Progressed): Redesigned DED Readerhttps://tracker.dengine.net/issues/13012003-10-05T10:15:50Zskyjake
<p>The DED reader needs to be rewritten.</p>
It will be possible to have more advanced scripting <br />features, such as:
<ul>
<li>constants</li>
<li>expressions</li>
<li>conditional sections</li>
</ul>
<p>See <a href="http://dengine.net/dew/index.php?title=DED_2.0" class="external">proposal</a></p> Doomsday Engine - Feature #1190 (Progressed): External scripts for mobj behaviorhttps://tracker.dengine.net/issues/11902003-06-15T14:47:51Zskyjake
<p>Making monster AI external would allow for far more <br />customizability. In Duke Nukem 3D all monster/object AI <br />was handled via external scripts, which made use of <br />built in AI functions such as: LookAtPlayer, RunAway, <br />FollowPlayer etc...</p>
<p>The scripting language should also incorporate ACS.</p>
<p>This would leave only the game related routines in the <br />dll's.</p>
<p>Dani J666</p>
<p><strong>Labels:</strong> Customizability</p>