How would you like the feature to work?

FireStorm had a good idea making a preprocessor to make the life of scripters better, but in my opinion they went overboard.

So I propose the implementation of only these three pragmas/directives:

#define

     Purpose: Define a symbol, or a macro
     Reference: https://wiki.firestormviewer.org/fs_preprocessor#define

#undef

     Purpose: Undefine a symbol or a macro
     Reference: https://wiki.firestormviewer.org/fs_preprocessor#undef

#ifdef ... #else ... #endif

     Implement different code – or even different pragmas/directives – based on if a symbol has been defined by #define (or conversely, deleted by #undef)
     Reference: https://wiki.firestormviewer.org/fs_preprocessor#ifdef_and_ifndef_else_and_endif

Other FireStorm preprocessor features are of much less usefulness, and some (e.g., the switch/case and "lazy list" features) can even be detrimental to the code quality (by doing too much behind-the-scenes magic, leading to inefficient / bulky code.)

Why is this feature important to you? How would it benefit the community?

The #define directive will allow scripters to avoid "one-liner functions", thus saving not only code space and stack space, but also reducing script time as an expensive function call is no longer done.

The #ifdef .. #else .. #endif allows scripters to easily create 'DEBUG' version of their scripts, with lots of llOwnerSay()'s and other thing, but can easily be 'simplified' to production version simply by deleting the #define DEBUG directive (or using #undef DEBUG prior to #ifdef directive)

All in all, these three directives help make scripts more efficient and (indirectly) less buggy as well (as scripters can easily add debugging statements in the script that can automagically be removed by the preprocessor prior to compiling).

To emphasize: {}The main aim is to establish a baseline pre-processor feature that all Viewers can adhere to{}, therefore leading to scripts having pre-processor directives to be "cross-viewer" compatible. No more "FireStorm-only scripts" just because the script uses Firestorm preprocessor to make the code more efficient.

{
  'Build Id': 'unset',
  'Business Unit': ['Platform'],
  'Date of First Response': '2023-02-15T13:25:44.019-0600',
  'How would you like the feature to work?': 'FireStorm had a good idea making a preprocessor to make the life of scripters better, but in my opinion they went overboard.\r\n\r\nSo I propose the implementation of these three pragmas/directives:\r\n\r\n#define \r\n\r\nPurpose: Define a symbol, or a macro\r\n\r\n#undef\r\n\r\nPurpose: Undefine a symbol or a macro\r\n\r\n#ifdef  ...  #else  ...  #endif\r\n\r\nImplement different code -- or even different pragmas/directives -- based on if a symbol has been defined by #define (or conversely, deleted by #undef)',
  'ReOpened Count': 0.0,
  'Severity': 'Unset',
  'Target Viewer Version': 'viewer-development',
  'Why is this feature important to you? How would it benefit the community?': 'The #define directive will allow scripters to avoid "one-liner functions", thus saving not only code space and stack space, but also reducing script time as an expensive function call is no longer done.\r\n\r\nThe #ifdef .. #else .. #endif allows scripters to easily create \'DEBUG\' version of their scripts, with lots of llOwnerSay()\'s and other thing, but can easily be \'simplified\' to production version simply by deleting the #define DEBUG directive (or using #undef DEBUG prior to #ifdef directive)\r\n\r\nAll in all, these three directives help make scripts more efficient and (indirectly) less buggy as well (as scripters can easily add debugging statements in the script that can automagically be removed by the preprocessor prior to compiling).',
}