mirror of
https://github.com/NuSkooler/enigma-bbs.git
synced 2025-07-30 22:46:17 +02:00
Automatically generate the navigation
This commit is contained in:
Nathan Byrd
parent
4793ad0492
commit
b5b0cc3ac5
94 changed files with 236 additions and 335 deletions
22
docs/_docs/modding/autosig-edit.md
Normal file
22
docs/_docs/modding/autosig-edit.md
Normal file
|
|
@ -0,0 +1,22 @@
|
|||
---
|
||||
layout: page
|
||||
title: Auto Signature Editor
|
||||
---
|
||||
## The Auto Signature Editor
|
||||
The built in `autosig_edit` module allows users to edit their auto signatures (AKA "autosig").
|
||||
|
||||
### Theming
|
||||
The following MCI codes are available:
|
||||
* MCI 1 (ie: `MT1`): Editor
|
||||
* MCI 2 (ie: `BT2`): Save button
|
||||
|
||||
### Disabling Auto Signatures
|
||||
Auto Signature support can be disabled for a particular message area by setting `autoSignatures` to false in the area's configuration block.
|
||||
|
||||
Example:
|
||||
```hjson
|
||||
my_area: {
|
||||
name: My Area
|
||||
autoSignatures: false
|
||||
}
|
||||
```
|
||||
24
docs/_docs/modding/bbs-list.md
Normal file
24
docs/_docs/modding/bbs-list.md
Normal file
|
|
@ -0,0 +1,24 @@
|
|||
---
|
||||
layout: page
|
||||
title: BBS List
|
||||
---
|
||||
## The BBS List Module
|
||||
The built in `bbs_list` module provides the ability for users to manage entries to other Bulletin Board Systems.
|
||||
|
||||
## Configuration
|
||||
### Config Block
|
||||
Available `config` block entries:
|
||||
* `youSubmittedFormat`: Provides a format for entries that were submitted (and therefor ediable) by the current user. Defaults to `'{submitter} (You!)'`. Utilizes the same `itemFormat` object as entries described below.
|
||||
|
||||
### Theming
|
||||
The following `itemFormat` object is provided to MCI 1 (ie: `%VM1`) (the BBS list):
|
||||
* `id`: Row ID
|
||||
* `bbsName`: System name. Note that `{text}` also contains this value.
|
||||
* `sysOp`: System Operator
|
||||
* `telnet`: Telnet address
|
||||
* `www`: Web address
|
||||
* `location`: System location
|
||||
* `software`: System's software
|
||||
* `submitter`: Username of entry submitter
|
||||
* `submitterUserId`: User ID of submitter
|
||||
* `notes`: Any additional notes about the system
|
||||
61
docs/_docs/modding/door-servers.md
Normal file
61
docs/_docs/modding/door-servers.md
Normal file
|
|
@ -0,0 +1,61 @@
|
|||
---
|
||||
layout: page
|
||||
title: Door Servers
|
||||
---
|
||||
## The bbs_link Module
|
||||
Native support for [BBSLink](http://www.bbslink.net/) doors is provided via the `bbs_link` module.
|
||||
|
||||
Configuration for a BBSLink door is straight forward. Take a look at the following example for launching Tradewars 2002:
|
||||
|
||||
```hjson
|
||||
doorTradeWars2002BBSLink: {
|
||||
desc: Playing TW 2002 (BBSLink)
|
||||
module: bbs_link
|
||||
config: {
|
||||
sysCode: XXXXXXXX
|
||||
authCode: XXXXXXXX
|
||||
schemeCode: XXXXXXXX
|
||||
door: tw
|
||||
}
|
||||
}
|
||||
|
||||
```
|
||||
|
||||
Fill in your credentials in `sysCode`, `authCode`, and `schemeCode` and that's it!
|
||||
|
||||
## The door_party Module
|
||||
The module `door_party` provides native support for [DoorParty!](http://www.throwbackbbs.com/) Configuration is quite easy:
|
||||
|
||||
```hjson
|
||||
doorParty: {
|
||||
desc: Using DoorParty!
|
||||
module: door_party
|
||||
config: {
|
||||
username: XXXXXXXX
|
||||
password: XXXXXXXX
|
||||
bbsTag: XX
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
Fill in `username`, `password`, and `bbsTag` with credentials provided to you and you should be in business!
|
||||
|
||||
## The CombatNet Module
|
||||
The `combatnet` module provides native support for [CombatNet](http://combatnet.us/). Add the following to your menu config:
|
||||
|
||||
````hjson
|
||||
combatNet: {
|
||||
desc: Using CombatNet
|
||||
module: combatnet
|
||||
config: {
|
||||
bbsTag: CBNxxx
|
||||
password: XXXXXXXXX
|
||||
}
|
||||
}
|
||||
````
|
||||
Update `bbsTag` (in the format CBNxxx) and `password` with the details provided when you register, then
|
||||
you should be ready to rock!
|
||||
|
||||
## The Exodus Module
|
||||
|
||||
TBC
|
||||
13
docs/_docs/modding/existing-mods.md
Normal file
13
docs/_docs/modding/existing-mods.md
Normal file
|
|
@ -0,0 +1,13 @@
|
|||
---
|
||||
layout: page
|
||||
title: Existing Mods
|
||||
---
|
||||
Many "addon" modules exist and have been released. Below are a few:
|
||||
|
||||
| Name | Author | Description |
|
||||
|-----------------------------|-------------|-------------|
|
||||
| Married Bob Fetch Event | NuSkooler | An event for fetching the latest Married Bob ANSI's for display on you board. ACiDic release [ACD-MB4E.ZIP](https://l33t.codes/outgoing/ACD/ACD-MB4E.ZIP). Can also be [found on GitHub](https://github.com/NuSkooler/enigma-bbs-married_bob_evt) |
|
||||
| Latest Files Announcement | NuSkooler | An event for posting the latest file arrivals of your board to message areas such as FTN style networks. ACiDic release [ACD-LFA1.ZIP](https://l33t.codes/outgoing/ACD/ACD-LFA1.ZIP). Also [found on GitHub](https://github.com/NuSkooler/enigma-bbs-latest_files_announce_evt) |
|
||||
| Message Post Event | NuSkooler | An event for posting messages/ads to networks. ACiDic release [ACD-MP4E.ZIP](https://l33t.codes/outgoing/ACD/ACD-MP4E.ZIP) |
|
||||
|
||||
See also [ACiDic BBS Mods by NuSkooler](https://l33t.codes/acidic-mods-by-myself/)
|
||||
95
docs/_docs/modding/file-area-list.md
Normal file
95
docs/_docs/modding/file-area-list.md
Normal file
|
|
@ -0,0 +1,95 @@
|
|||
---
|
||||
layout: page
|
||||
title: File Area List
|
||||
---
|
||||
## The File Area List Module
|
||||
The built in `file_area_list` module provides a very flexible file listing UI.
|
||||
|
||||
## Configuration
|
||||
### Config Block
|
||||
Available `config` block entries:
|
||||
* `art`: Sub-configuration block used to establish art files used for file browsing:
|
||||
* `browse`: The main browse screen.
|
||||
* `details`: The main file details screen.
|
||||
* `detailsGeneral`: The "general" tab of the details page.
|
||||
* `detailsNfo`: The "NFO" viewer tab of the detials page.
|
||||
* `detailsFileList`: The file listing tab of the details page (ie: used for listing archive contents).
|
||||
* `help`: The help page.
|
||||
* `hashTagsSep`: Separator for hash entries. Defaults to ", ".
|
||||
* `isQueuedIndicator`: Indicator for items that are in the users download queue. Defaults to "Y".
|
||||
* `isNotQueuedIndicator`: Indicator for items that are _not_ in the users download queue. Defaults to "N".
|
||||
* `userRatingTicked`: Indicator for a items current _n_/5 "star" rating. Defaults to "\*". `userRatingTicked` and `userRatingUnticked` are combined to build strings such as "***--" for 3/5 rating.
|
||||
* `userRatingUnticked`: Indicator for missing "stars" in a items _n_/5 rating. Defaults to "-". `userRatingTicked` and `userRatingUnticked` are combined to build strings such as "***--" for 3/5 rating.
|
||||
* `webDlExpireTimeFormat`: Presents the expiration time of a web download URL. Defaults to current theme → system `short` date/time format.
|
||||
* `webDlLinkNeedsGenerated`: Text to present when no web download link is yet generated. Defaults to "Not yet generated".
|
||||
* `webDlLinkNoWebserver`: Text to present when no web download is available (ie: webserver not enabled). Defaults to "Web server is not enabled".
|
||||
* `notAnArchiveFormat`: Presents text for the "archive type" field for non-archives. Defaults to "Not an archive".
|
||||
* `uploadTimestampFormat`: Timestamp format for `xxxxxxInfoFormat##`. Defaults to current theme → system `short` date format. See also **Custom Info Formats** below.
|
||||
|
||||
Remember that entries such as `isQueuedIndicator` and `userRatingTicked` may contain pipe color codes!
|
||||
|
||||
## Custom Info Formats
|
||||
Additional `config` block entries can set `xxxxxxInfoFormat##` formatting (where xxxxxx is the page name and ## is 10...99 such as `browseInfoFormat10`) for the various available pages:
|
||||
* `browseInfoFormat##` for the `browse` page. See **Browse Page** below.
|
||||
* `detailsInfoFormat##` for the `details` page. See **Details Page** below.
|
||||
* `detailsGeneralInfoFormat##` for the `detailsGeneral` tab. See **Details Page - General Tab** below.
|
||||
* `detailsNfoInfoFormat##` for the `detialsNfo` tab. See **Details Page - NFO/README Viewer Tab** below.
|
||||
* `detailsFileListInfoFormat##` for the `detailsFileList` tab. See **Details Page - Archive/File Listing Tab** below.
|
||||
|
||||
## Theming
|
||||
### Browse Page
|
||||
The browse page uses the `browse` art described above. The following MCI codes are available:
|
||||
* MCI 1 (ie: `%MT1`): File's short description (user entered, FILE_ID.DIZ, etc.).
|
||||
* MCI 2 (ie: `%HM2`): Navigation menu.
|
||||
* MCI 10...99: Custom entires with the following format members:
|
||||
* `{fileId}`: File identifier.
|
||||
* `{fileName}`: File name (long).
|
||||
* `{desc}`: File short description (user entered, FILE_ID.DIZ, etc.).
|
||||
* `{descLong}`: File's long description (README.TXT, SOMEGROUP.NFO, etc.).
|
||||
* `{uploadByUserName}`: User name of user that uploaded this file, or "N/A".
|
||||
* `{uploadByUserId}`: User ID of user that uploaded this file, or "N/A".
|
||||
* `{userRating}`: User rating of file as a number.
|
||||
* `{userRatingString}`: User rating of this file as a string formatted with `userRatingTicked` and `userRatingUnticked` described above.
|
||||
* `{areaTag}`: Area tag.
|
||||
* `{areaName}`: Area name or "N/A".
|
||||
* `{areaDesc}`: Area description or "N/A".
|
||||
* `{fileSha256}`: File's SHA-256 value in hex.
|
||||
* `{fileMd5}`: File's MD5 value in hex.
|
||||
* `{fileSha1}`: File's SHA1 value in hex.
|
||||
* `{fileCrc32}`: File's CRC-32 value in hex.
|
||||
* `{estReleaseYear}`: Estimated release year of this file.
|
||||
* `{dlCount}`: Number of times this file has been downloaded.
|
||||
* `{byteSize}`: Size of this file in bytes.
|
||||
* `{archiveType}`: Archive type of this file determined by system mappings, or "N/A".
|
||||
* `{archiveTypeDesc}`: A more descriptive archive type based on system mappings, file extention, etc. or "N/A" if it cannot be determined.
|
||||
* `{shortFileName}`: Short DOS style 8.3 name available for some scenarios such as TIC import, or "N/A".
|
||||
* `{ticOrigin}`: Origin from TIC imported files "Origin" field, or "N/A".
|
||||
* `{ticDesc}`: Description from TIC imported files "Desc" field, or "N/A".
|
||||
* `{ticLDesc}`: Long description from TIC imported files "LDesc" field joined by a line feed, or "N/A".
|
||||
* `{uploadTimestamp}`: Upload timestamp formatted with `browseUploadTimestampFormat`.
|
||||
* `{hashTags}`: A string of hash tags(s) separated by `hashTagsSep` described above. "(none)" if there are no tags.
|
||||
* `{isQueued}`: Indicates if a item is currently in the user's download queue presented as `isQueuedIndicator` or `isNotQueuedIndicator` described above.
|
||||
* `{webDlLink}`: Web download link if generated else `webDlLinkNeedsGenerated` or `webDlLinkNoWebserver` described above.
|
||||
* `{webDlExpire}`: Web download link expiration using `webDlExpireTimeFormat` described above.
|
||||
|
||||
### Details Page
|
||||
The details page uses the `details` art described above. The following MCI codes are available:
|
||||
* MCI 1 (ie: `%HM1`): Navigation menu
|
||||
* `%XY2`: Info area's top X,Y position.
|
||||
* `%XY3`: Info area's bottom X,Y position.
|
||||
* MCI 10...99: Custom entries with the format options described above in **Browse Page** via the `detailsInfoFormat##` `config` block entry.
|
||||
|
||||
### Details Page - General Tab
|
||||
The details page general tab uses the `detailsGeneral` art described above. The following MCI codes are available:
|
||||
* MCI 10...99: Custom entries with the format options described above in **Browse Page** via the `detailsGeneralInfoFormat##` `config` block entry.
|
||||
|
||||
### Details Page - NFO/README Viewer Tab
|
||||
The details page nfo tab uses the `detailsNfo` art described above. The following MCI codes are available:
|
||||
* MCI 1 (ie: `%MT1`): NFO/README viewer using the entries `longDesc`.
|
||||
* MCI 10...99: Custom entries with the format options described above in **Browse Page** via the `detailsNfoInfoFormat##` `config` block entry.
|
||||
|
||||
### Details Page - Archive/File Listing Tab
|
||||
The details page file list tab uses the `detailsFileList` art described above. The following MCI codes are available:
|
||||
* MCI 1 (ie: `%VM1`): List of entries in archive. Entries are formatted using the standard `itemFormat` and `focusItemFormat` properties of the view and have all of the format options described above in **Browse Page**.
|
||||
* MCI 10...99: Custom entries with the format options described above in **Browse Page** via the `detailsFileListInfoFormat##` `config` block entry.
|
||||
|
||||
23
docs/_docs/modding/file-base-download-manager.md
Normal file
23
docs/_docs/modding/file-base-download-manager.md
Normal file
|
|
@ -0,0 +1,23 @@
|
|||
---
|
||||
layout: page
|
||||
title: File Base Download Manager
|
||||
---
|
||||
## File Base Download Manager Module
|
||||
The `file_base_download_manager` module provides a download queue manager for "legacy" (X/Y/Z-Modem, etc.) downloads. Web (HTTP/HTTPS) download functionality can be optionally available when the web content server is enabled.
|
||||
|
||||
## Configuration
|
||||
### Configuration Block
|
||||
Available `config` block entries:
|
||||
* `webDlExpireTimeFormat`: Sets the moment.js style format for web download expiration date/time.
|
||||
* `fileTransferProtocolSelection`: Overrides the default `fileTransferProtocolSelection` target for a protocol selection menu.
|
||||
* `emptyQueueMenu`: Overrides the default `fileBaseDownloadManagerEmptyQueue` target for menu to show when the users D/L queue is empty.
|
||||
|
||||
### Theming
|
||||
The following `itemFormat` object is provided to MCI 1 (ie: `%VM1`) and MCI 10+ custom fields:
|
||||
* `fileId`: File ID.
|
||||
* `areaTag`: Area tag.
|
||||
* `fileName`: Entry filename.
|
||||
* `path`: Full file path.
|
||||
* `byteSize`: Size in bytes of file.
|
||||
* `webDlLink`: Web download link including [VTX style ANSI ESC sequences](https://raw.githubusercontent.com/codewar65/VTX_ClientServer/master/vtx.txt).
|
||||
* `webDlExpire`: Expiration date/time for this link. Formatted using `webDlExpireTimeFormat`.
|
||||
26
docs/_docs/modding/file-base-web-download-manager.md
Normal file
26
docs/_docs/modding/file-base-web-download-manager.md
Normal file
|
|
@ -0,0 +1,26 @@
|
|||
---
|
||||
layout: page
|
||||
title: File Base Web Download Manager
|
||||
---
|
||||
## File Base Web Download Manager Module
|
||||
The `file_base_web_download_manager` module provides a download queue manager for web (HTTP/HTTPS) based downloads. This module relies on having the web server enabled at a minimum.
|
||||
|
||||
Web downloads can be a convienent way for users to download larger (100+ MiB) files where legacy protocols often have trouble. Additionally, batch downloads can be streamed to users in a single zip archive.
|
||||
|
||||
## Configuration
|
||||
### Configuration Block
|
||||
Available `config` block entries:
|
||||
* `webDlExpireTimeFormat`: Sets the moment.js style format for web download expiration date/time.
|
||||
* `emptyQueueMenu`: Overrides the default `fileBaseDownloadManagerEmptyQueue` target for menu to show when the users D/L queue is empty.
|
||||
|
||||
### Theming
|
||||
The following `itemFormat` object is provided to MCI 1 (ie: `%VM1`) and custom range MCI 10+ custom fields:
|
||||
* `fileId`: File ID.
|
||||
* `areaTag`: Area tag.
|
||||
* `fileName`: Entry filename.
|
||||
* `path`: Full file path.
|
||||
* `byteSize`: Size in bytes of file.
|
||||
* `webDlLinkRaw`: Web download link.
|
||||
* `webDlLink`: Web download link including [VTX style ANSI ESC sequences](https://raw.githubusercontent.com/codewar65/VTX_ClientServer/master/vtx.txt).
|
||||
* `webDlExpire`: Expiration date/time for this link. Formatted using `webDlExpireTimeFormat`.
|
||||
|
||||
13
docs/_docs/modding/file-transfer-protocol-select.md
Normal file
13
docs/_docs/modding/file-transfer-protocol-select.md
Normal file
|
|
@ -0,0 +1,13 @@
|
|||
---
|
||||
layout: page
|
||||
title: File Transfer Protocol Select
|
||||
---
|
||||
## The Rumorz Module
|
||||
The built in `file_transfer_protocol_select` module provides a way to select a legacy file transfer protocol (X/Y/Z-Modem, etc.) for upload/downloads.
|
||||
|
||||
## Configuration
|
||||
|
||||
### Theming
|
||||
The following `itemFormat` object is provided to MCI 1 (ie: `%VM1`) (the protocol list):
|
||||
* `name`: The name of the protocol. Each entry is +op defined in `config.hjson` with defaults found in `config_default.js`. Note that the standard `{text}` field also contains this value.
|
||||
|
||||
40
docs/_docs/modding/last-callers.md
Normal file
40
docs/_docs/modding/last-callers.md
Normal file
|
|
@ -0,0 +1,40 @@
|
|||
---
|
||||
layout: page
|
||||
title: Last Callers
|
||||
---
|
||||
## The Last Callers Module
|
||||
The built in `last_callers` module provides flexible retro last callers mod.
|
||||
|
||||
## Configuration
|
||||
### Config Block
|
||||
Available `config` block entries:
|
||||
* `dateTimeFormat`: [moment.js](https://momentjs.com) style format. Defaults to current theme → system `short` format.
|
||||
* `user`: User options:
|
||||
* `collapse`: Collapse or roll up entries that fall within the period specified. May be a string in the form of `30 minutes`, `3 weeks`, `1 hour`, etc.
|
||||
* `sysop`: Sysop options:
|
||||
* `collapse`: Collapse or roll up entries that fall within the period specified. May be a string in the form of `30 minutes`, `3 weeks`, `1 hour`, etc.
|
||||
* `hide`: Hide all +op logins
|
||||
* `actionIndicators`: Maps user events/actions to indicators. For example: `userDownload` to "D". Available indicators:
|
||||
* `newUser`: User is new.
|
||||
* `dlFiles`: User downloaded file(s).
|
||||
* `ulFiles`: User uploaded file(s).
|
||||
* `postMsg`: User posted message(s) to the message base, EchoMail, etc.
|
||||
* `sendMail`: User sent _private_ mail.
|
||||
* `runDoor`: User ran door(s).
|
||||
* `sendNodeMsg`: User sent a node message(s).
|
||||
* `achievementEarned`: User earned an achievement(s).
|
||||
* `actionIndicatorDefault`: Default indicator when an action is not set. Defaults to "-".
|
||||
|
||||
Remember that entries such as `actionIndicators` and `actionIndicatorDefault` may contain pipe color codes!
|
||||
|
||||
### Theming
|
||||
The following `itemFormat` object is provided to MCI 1 (ie: `%VM1`):
|
||||
* `userId`: User ID.
|
||||
* `userName`: Login username.
|
||||
* `realName`: User's real name.
|
||||
* `ts`: Timestamp in `dateTimeFormat` format.
|
||||
* `location`: User's location.
|
||||
* `affiliation` or `affils`: Users affiliations.
|
||||
* `actions`: A string built by concatenating action indicators for a users logged in session. For example, given a indicator of `userDownload` mapped to "D", the string may be "-D----". The format was made popular on Amiga style boards.
|
||||
|
||||
|
||||
244
docs/_docs/modding/local-doors.md
Normal file
244
docs/_docs/modding/local-doors.md
Normal file
|
|
@ -0,0 +1,244 @@
|
|||
---
|
||||
layout: page
|
||||
title: Local Doors
|
||||
---
|
||||
## Local Doors
|
||||
ENiGMA½ has many ways to add doors to your system. In addition to the [many built in door server modules](door-servers.md), local doors are of course also supported using the ! The `abracadabra` module!
|
||||
|
||||
:information_source: See also [Let’s add a DOS door to Enigma½ BBS](https://medium.com/retro-future/lets-add-a-dos-game-to-enigma-1-2-41f257deaa3c) by Robbie Whiting for a great writeup on adding doors!
|
||||
|
||||
## The abracadabra Module
|
||||
The `abracadabra` module provides a generic and flexible solution for many door types. Through this module you can execute native processes & scripts directly, and perform I/O through standard I/O (stdio) or a temporary TCP server.
|
||||
|
||||
### Configuration
|
||||
The `abracadabra` `config` block can contain the following members:
|
||||
|
||||
| Item | Required | Description |
|
||||
|------|----------|-------------|
|
||||
| `name` | :+1: | Used as a key for tracking number of clients using a particular door. |
|
||||
| `dropFileType` | :-1: | Specifies the type of dropfile to generate (See **Dropfile Types** below). Can be omitted or set to `none`. |
|
||||
| `cmd` | :+1: | Path to executable to launch. |
|
||||
| `args` | :-1: | Array of argument(s) to pass to `cmd`. See **Argument Variables** below for information on variables that can be used here.
|
||||
| `cwd` | :-1: | Sets the Current Working Directory (CWD) for `cmd`. Defaults to the directory of `cmd`. |
|
||||
| `env` | :-1: | Sets the environment. Supplied in the form of an map: `{ SOME_VAR: "value" }`
|
||||
| `nodeMax` | :-1: | Max number of nodes that can access this door at once. Uses `name` as a tracking key. |
|
||||
| `tooManyArt` | :-1: | Art spec to display if too many instances are already in use. |
|
||||
| `io` | :-1: | How to process input/output (I/O). Can be `stdio` or `socket`. When using `stdio`, I/O is handled via standard stdin/stdout. When using `socket` a temporary socket server is spawned that can be connected back to. The server listens on localhost on `{srvPort}` (See **Argument Variables** below for more information). Default value is `stdio`. |
|
||||
| `encoding` | :-1: | Sets the **door's** encoding. Defaults to `cp437`. Linux binaries often produce `utf8`. |
|
||||
|
||||
#### Dropfile Types
|
||||
Dropfile types specified by `dropFileType`:
|
||||
|
||||
| Value | Description |
|
||||
|-------|-------------|
|
||||
| `DOOR` | [DOOR.SYS](https://web.archive.org/web/20160325192739/http://goldfndr.home.mindspring.com/dropfile/doorsys.htm)
|
||||
| `DOOR32` | [DOOR32.SYS](https://raw.githubusercontent.com/NuSkooler/ansi-bbs/master/docs/dropfile_formats/door32_sys.txt)
|
||||
| `DORINFO` | [DORINFOx.DEF](https://web.archive.org/web/20160321190038/http://goldfndr.home.mindspring.com/dropfile/dorinfo.htm)
|
||||
|
||||
#### Argument Variables
|
||||
The following variables may be used in `args` entries:
|
||||
|
||||
| Variable | Description | Example |
|
||||
|----------|-------------|---------|
|
||||
| `{node}` | Current node number. | `1` |
|
||||
| `{dropFile}` | Dropfile _filename_ only. | `DOOR.SYS` |
|
||||
| `{dropFilePath}` | Full path to generated dropfile. The system places dropfiles in the path set by `paths.dropFiles` in `config.hjson`. | `C:\enigma-bbs\drop\node1\DOOR.SYS` |
|
||||
| `{userId}` | Current user ID. | `420` |
|
||||
| `{userName}` | [Sanitized](https://www.npmjs.com/package/sanitize-filename) username. Safe for filenames, etc. If the full username is sanitized away, this will resolve to something like "user_1234". | `izard` |
|
||||
| `{userNameRaw}` | _Raw_ username. May not be safe for filenames! | `\/\/izard` |
|
||||
| `{srvPort}` | Temporary server port when `io` is set to `socket`. | `1234` |
|
||||
| `{cwd}` | Current Working Directory. | `/home/enigma-bbs/doors/foo/` |
|
||||
|
||||
Example `args` member using some variables described above:
|
||||
```hjson
|
||||
args: [
|
||||
"-D", "{dropFilePath}",
|
||||
"-N", "{node}"
|
||||
"-U", "{userId}"
|
||||
]
|
||||
```
|
||||
|
||||
### DOSEMU with abracadabra
|
||||
[DOSEMU](http://www.dosemu.org/) can provide a good solution for running legacy DOS doors when running on Linux systems. For this, we will create a virtual serial port (COM1) that communicates via stdio.
|
||||
|
||||
As an example, here are the steps for setting up Pimp Wars:
|
||||
|
||||
First, create a `dosemu.conf` file with the following contents:
|
||||
```
|
||||
$_cpu = "80486"
|
||||
$_cpu_emu = "vm86"
|
||||
$_external_char_set = "utf8"
|
||||
$_internal_char_set = "cp437"
|
||||
$_term_updfreq = (8)
|
||||
$_layout = "us"
|
||||
$_rawkeyboard = (0)
|
||||
$_com1 = "virtual"
|
||||
```
|
||||
|
||||
The line `$_com1 = "virtual"` tells DOSEMU to use `stdio` as a virtual serial port on COM1.
|
||||
|
||||
Next, we create a virtual **X** drive for Pimp Wars to live such as `/enigma-bbs/DOS/X/PW` and map it with a custom `AUTOEXEC.BAT` file within DOSEMU:
|
||||
```
|
||||
@echo off
|
||||
path d:\bin;d:\gnu;d:\dosemu
|
||||
set TEMP=c:\tmp
|
||||
prompt $P$G
|
||||
REM http://www.pcmicro.com/bnu/
|
||||
C:\BNU\BNU.COM /L0:57600,8N1 /F
|
||||
lredir.com x: linux\fs\enigma-bbs\DOS\X
|
||||
unix -e
|
||||
```
|
||||
|
||||
Note that we also have the [BNU](http://www.pcmicro.com/bnu/) FOSSIL driver installed at `C:\BNU\\`. Another option would be to install this to X: somewhere as well.
|
||||
|
||||
Finally, let's create a `menu.hjson` entry to launch the game:
|
||||
```hjson
|
||||
doorPimpWars: {
|
||||
desc: Playing PimpWars
|
||||
module: abracadabra
|
||||
config: {
|
||||
name: PimpWars
|
||||
dropFileType: DORINFO
|
||||
cmd: /usr/bin/dosemu
|
||||
args: [
|
||||
"-quiet",
|
||||
"-f",
|
||||
"/path/to/dosemu.conf",
|
||||
"X:\\PW\\START.BAT {dropFile} {node}"
|
||||
],
|
||||
nodeMax: 1
|
||||
tooManyArt: DOORMANY
|
||||
io: stdio
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
### Shared Socket Descriptors
|
||||
Due to Node.js limitations, ENiGMA½ does not _directly_ support `DOOR32.SYS` style socket descriptor sharing (other `DOOR32.SYS` features are fully supported). However, a separate binary called [bivrost!](https://github.com/NuSkooler/bivrost) can be used. bivrost! is available for Windows and Linux x86/i686 and x86_64/AMD64. Other platforms where [Rust](https://www.rust-lang.org/) builds are likely to work as well.
|
||||
|
||||
#### Example configuration
|
||||
Below is an example `menu.hjson` entry using bivrost! to launch a door:
|
||||
|
||||
```hjson
|
||||
doorWithBivrost: {
|
||||
desc: Bivrost Example
|
||||
module: abracadabra
|
||||
config: {
|
||||
name: BivrostExample
|
||||
dropFileType: DOOR32
|
||||
cmd: "C:\\enigma-bbs\\utils\\bivrost.exe"
|
||||
args: [
|
||||
"--port", "{srvPort}", // bivrost! will connect this port on localhost
|
||||
"--dropfile", "{dropFilePath}", // ...and read this DOOR32.SYS produced by ENiGMA½
|
||||
"--out", "C:\\doors\\jezebel", // ...and produce a NEW DOOR32.SYS here.
|
||||
|
||||
//
|
||||
// Note that the final <target> params bivrost! will use to
|
||||
// launch the door are grouped here. The {fd} variable could
|
||||
// also be supplied here if needed.
|
||||
//
|
||||
"C:\\door\\door.exe C:\\door\\door32.sys"
|
||||
],
|
||||
nodeMax: 1
|
||||
tooManyArt: DOORMANY
|
||||
io: socket
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
Please see the [bivrost!](https://github.com/NuSkooler/bivrost) documentation for more information.
|
||||
|
||||
#### Phenom Productions Releases
|
||||
Pre-built binaries of bivrost! have been released under [Phenom Productions](https://www.phenomprod.com/) and can be found on various boards.
|
||||
|
||||
#### Alternative Workarounds
|
||||
Alternative workarounds include [Telnet Bridge module](telnet-bridge.md) to hook up Telnet-accessible (including local) door servers -- It may also be possible bridge via [NET2BBS](http://pcmicro.com/netfoss/guide/net2bbs.html).
|
||||
|
||||
### QEMU with abracadabra
|
||||
[QEMU](http://wiki.qemu.org/Main_Page) provides a robust, cross platform solution for launching doors under many platforms (likely anywhere Node.js is supported and ENiGMA½ can run). Note however that there is an important and major caveat: **Multiple instances of a particular door/OS image should not be run at once!** Being more flexible means being a bit more complex. Let's look at an example for running L.O.R.D. under a UNIX like system such as Linux or FreeBSD.
|
||||
|
||||
Basically we'll be creating a bootstrap shell script that generates a temporary node specific `GO.BAT` to launch our door. This will be called from `AUTOEXEC.BAT` within our QEMU FreeDOS partition.
|
||||
|
||||
#### Step 1: Create a FreeDOS image
|
||||
[FreeDOS](http://www.freedos.org/) is a free mostly MS-DOS compatible DOS package that works well for running 16bit doors. Follow the [QEMU/FreeDOS](https://en.wikibooks.org/wiki/QEMU/FreeDOS) guide for creating an `freedos_c.img`. This will contain FreeDOS itself and installed BBS doors.
|
||||
|
||||
After this is complete, copy LORD to C:\DOORS\LORD within FreeDOS. An easy way to tranfer files from host to DOS is to use QEMU's vfat as a drive. For example:
|
||||
```bash
|
||||
qemu-system-i386 -localtime /home/enigma/dos/images/freedos_c.img -hdb fat:/path/to/downloads
|
||||
```
|
||||
|
||||
With the above you can now copy files from D: to C: within FreeDOS and add the following to it's `autoexec.bat`:
|
||||
```bat
|
||||
CALL E:\GO.BAT
|
||||
```
|
||||
|
||||
#### Step 2: Create a bootstrap script
|
||||
Our bootstrap script will prepare `GO.BAT` and launch FreeDOS. Below is an example:
|
||||
|
||||
|
||||
```bash
|
||||
#!/bin/bash
|
||||
|
||||
NODE=$1
|
||||
DROPFILE=D:\\$2
|
||||
SRVPORT=$3
|
||||
|
||||
mkdir -p /home/enigma/dos/go/node$NODE
|
||||
|
||||
cat > /home/enigma/dos/go/node$NODE/GO.BAT <<EOF
|
||||
C:
|
||||
CD \FOSSIL\BNU
|
||||
BNU.COM
|
||||
CD \DOORS\LORD
|
||||
COPY /Y $DROPFILE
|
||||
CALL START.BAT $NODE
|
||||
FDAPM POWEROFF
|
||||
EOF
|
||||
|
||||
unix2dos /home/enigma/dos/go/node$NODE/GO.BAT
|
||||
|
||||
qemu-system-i386 -localtime /home/enigma/dos/images/freedos_c.img -chardev socket,port=$SRVPORT,nowait,host=localhost,id=s0 -device isa-serial,chardev=s0 -hdb fat:/home/enigma/xibalba/dropfiles/node$NODE -hdc fat:/home/enigma/dos/go/node$NODE -nographic
|
||||
```
|
||||
|
||||
Note the `qemu-system-i386` line. We're telling QEMU to launch and use localtime for the clock, create a character device that connects to our temporary server port on localhost and map that to a serial device. The `-hdb` entry will represent the D: drive where our dropfile is generated, while `-hdc` is the path that `GO.BAT` is generated in (`E:\GO.BAT`). Finally we specify `-nographic` to run headless.
|
||||
|
||||
For doors that do not *require* a FOSSIL driver, it is recommended to not load or use one unless you are having issues.
|
||||
|
||||
##### Step 3: Create a menu entry
|
||||
Finally we can create a `menu.hjson` entry using the `abracadabra` module:
|
||||
```hjson
|
||||
doorLORD: {
|
||||
desc: Playing L.O.R.D.
|
||||
module: abracadabra
|
||||
config: {
|
||||
name: LORD
|
||||
dropFileType: DOOR
|
||||
cmd: /home/enigma/dos/scripts/lord.sh
|
||||
args: [
|
||||
"{node}",
|
||||
"{dropFile}",
|
||||
"{srvPort}",
|
||||
],
|
||||
nodeMax: 1
|
||||
tooManyArt: DOORMANY
|
||||
io: socket
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
## See Also
|
||||
* [Telnet Bridge](telnet-bridge.md)
|
||||
* [Door Servers](door-servers.md)
|
||||
|
||||
## Additional Resources
|
||||
### DOS Emulation
|
||||
* [DOSEMU](http://www.dosemu.org/)
|
||||
* [DOSBox-X](https://github.com/joncampbell123/dosbox-x)
|
||||
|
||||
### Door Downloads & Support Sites
|
||||
#### General
|
||||
* http://bbsfiles.com/
|
||||
* http://bbstorrents.bbses.info/
|
||||
|
||||
#### L.O.R.D.
|
||||
* http://lord.lordlegacy.com/
|
||||
14
docs/_docs/modding/menu-modules.md
Normal file
14
docs/_docs/modding/menu-modules.md
Normal file
|
|
@ -0,0 +1,14 @@
|
|||
---
|
||||
layout: page
|
||||
title: Menu Modules
|
||||
---
|
||||
## Menu Modules
|
||||
Menu entries found within `menu.hjson` are backed by *menu modules*.
|
||||
|
||||
## Creating a New Module
|
||||
TODO
|
||||
|
||||
### Lifecycle
|
||||
TODO
|
||||
|
||||
|
||||
17
docs/_docs/modding/msg-area-list.md
Normal file
17
docs/_docs/modding/msg-area-list.md
Normal file
|
|
@ -0,0 +1,17 @@
|
|||
---
|
||||
layout: page
|
||||
title: Message Area List
|
||||
---
|
||||
## The Message Area List Module
|
||||
The built in `msg_area_list` module provides a menu to display and change between message areas in the users current conference.
|
||||
|
||||
### Theming
|
||||
The following `itemFormat` object is provided to MCI 1 (ie: `%VM1`):
|
||||
* `index`: 1-based index into list.
|
||||
* `areaTag`: Area tag.
|
||||
* `name` or `text`: Display name.
|
||||
* `desc`: Description.
|
||||
|
||||
The following additional MCIs are updated as the user changes selections in the main list:
|
||||
* MCI 2 (ie: `%TL2` or `%M%2`) is updated with the area description.
|
||||
* MCI 10+ (ie `%TL10`...) are custom ranges updated with the same information available above in `itemFormat`. Use `areaListItemFormat##`.
|
||||
18
docs/_docs/modding/msg-conf-list.md
Normal file
18
docs/_docs/modding/msg-conf-list.md
Normal file
|
|
@ -0,0 +1,18 @@
|
|||
---
|
||||
layout: page
|
||||
title: Message Conference List
|
||||
---
|
||||
## The Message Conference List Module
|
||||
The built in `msg_conf_list` module provides a menu to display and change between message conferences.
|
||||
|
||||
### Theming
|
||||
The following `itemFormat` object is provided to MCI 1 (ie: `%VM1`):
|
||||
* `index`: 1-based index into list.
|
||||
* `confTag`: Conference tag.
|
||||
* `name` or `text`: Display name.
|
||||
* `desc`: Description.
|
||||
* `areaCount`: Number of areas in this conference.
|
||||
|
||||
The following additional MCIs are updated as the user changes selections in the main list:
|
||||
* MCI 2 (ie: `%TL2` or `%M%2`) is updated with the conference description.
|
||||
* MCI 10+ (ie `%TL10`...) are custom ranges updated with the same information available above in `itemFormat`.
|
||||
41
docs/_docs/modding/node-msg.md
Normal file
41
docs/_docs/modding/node-msg.md
Normal file
|
|
@ -0,0 +1,41 @@
|
|||
---
|
||||
layout: page
|
||||
title: Node to Node Messaging
|
||||
---
|
||||
## The Node to Node Messaging Module
|
||||
The node to node messaging (`node_msg`) module allows users to send messages to one or more users on different nodes. Messages delivered to nodes follow standard [User Interruption](../misc/user-interrupt.md) rules.
|
||||
|
||||
## Configuration
|
||||
### Config Block
|
||||
Available `config` block entries:
|
||||
* `dateTimeFormat`: [moment.js](https://momentjs.com) style format. Defaults to current theme → system `short` format.
|
||||
* `messageFormat`: Format string for sent messages. Defaults to `Message from {fromUserName} on node {fromNodeId}:\r\n{message}`. The following format object members are available:
|
||||
* `fromUserName`: Username who sent the message.
|
||||
* `fromRealName`: Real name of user who sent the message.
|
||||
* `fromNodeId`: Node ID where the message was sent from.
|
||||
* `message`: User entered message. May contain pipe color codes.
|
||||
* `timestamp`: A timestamp formatted using `dateTimeFormat` above.
|
||||
* `art`: Block containing:
|
||||
* `header`: Art spec for header to display with message.
|
||||
* `footer`: Art spec for footer to display with message.
|
||||
|
||||
## Theming
|
||||
### MCI Codes
|
||||
1. Node selection. Must be a View that allows lists such as `SpinnerMenuView` (`%SM1`), `HorizontalMenuView` (`%HM1`), etc.
|
||||
2. Message entry (`%ET2`).
|
||||
3. Message preview (`%TL3`). A rendered (that is, pipe codes resolved) preview of the text in `%ET2`.
|
||||
|
||||
10+: Custom using `itemFormat`. See below.
|
||||
|
||||
### Item Format
|
||||
The following `itemFormat` object is provided for MCI 1 and 10+ for the currently selected item/node:
|
||||
* `text`: Node ID or "-ALL-" (All nodes).
|
||||
* `node`: Node ID or `-1` in the case of all nodes.
|
||||
* `userId`: User ID.
|
||||
* `action`: User's action.
|
||||
* `userName`: Username.
|
||||
* `realName`: Real name.
|
||||
* `location`: User's location.
|
||||
* `affils`: Affiliations.
|
||||
* `timeOn`: How long the user has been online (approx).
|
||||
|
||||
19
docs/_docs/modding/onelinerz.md
Normal file
19
docs/_docs/modding/onelinerz.md
Normal file
|
|
@ -0,0 +1,19 @@
|
|||
---
|
||||
layout: page
|
||||
title: Onelinerz
|
||||
---
|
||||
## The Onelinerz Module
|
||||
The built in `onelinerz` module provides a retro onelinerz system.
|
||||
|
||||
## Configuration
|
||||
### Config Block
|
||||
Available `config` block entries:
|
||||
* `dateTimeFormat`: [moment.js](https://momentjs.com) style format. Defaults to current theme → system `short` date format.
|
||||
* `dbSuffix`: Provide a suffix that will be appended to the DB name to use onelinerz for more than one purpose (separate lists).
|
||||
|
||||
### Theming
|
||||
The following `itemFormat` object is provided to MCI 1 (ie: `%VM1`):
|
||||
* `userId`: User ID of the onliner entry.
|
||||
* `userName`: Login username of the onliner entry.
|
||||
* `oneliner`: The oneliner text. Note that the standard `{text}` field also contains this value.
|
||||
* `ts`: Timestamp of the entry formatted with `dateTimeFormat` format described above.
|
||||
12
docs/_docs/modding/rumorz.md
Normal file
12
docs/_docs/modding/rumorz.md
Normal file
|
|
@ -0,0 +1,12 @@
|
|||
---
|
||||
layout: page
|
||||
title: Rumorz
|
||||
---
|
||||
## The Rumorz Module
|
||||
The built in `rumorz` module provides a classic interface for users to add and view rumorz!
|
||||
|
||||
## Configuration
|
||||
|
||||
### Theming
|
||||
The following `itemFormat` object is provided to MCI 1 (ie: `%VM1`) (the rumor list):
|
||||
* `rumor`: The rumor text. Also available in the standard `{text}` field.
|
||||
29
docs/_docs/modding/set-newscan-date.md
Normal file
29
docs/_docs/modding/set-newscan-date.md
Normal file
|
|
@ -0,0 +1,29 @@
|
|||
---
|
||||
layout: page
|
||||
title: Set Newscan Date Module
|
||||
---
|
||||
## Set Newscan Date Module
|
||||
The `set_newscan_date` module allows setting newscan dates (aka pointers) for message conferences and areas as well as within the file base. Users can select specific conferences/areas or all (where applicable).
|
||||
|
||||
## Configuration
|
||||
### Configuration Block
|
||||
Available `config` block entries are as follows:
|
||||
* `target`: Choose from `message` for message conferences & areas, or `file` for file base areas.
|
||||
* `scanDateFormat`: Format for scan date. This format must align with the **output** of the MaskEditView (`%ME1`) MCI utilized for input. Defaults to `YYYYMMDD` (which matches mask of `####/##/##`).
|
||||
|
||||
### Theming
|
||||
#### Message Conference & Areas
|
||||
When `target` is `message`, the following `itemFormat` object is provided to MCI 2 (ie: `%SM2`):
|
||||
* `conf`: An object containing:
|
||||
* `confTag`: Conference tag.
|
||||
* `name`: Conference name. Also available in `{text}`.
|
||||
* `desc`: Conference description.
|
||||
* `area`: An object containing:
|
||||
* `areaTag`: Area tag.
|
||||
* `name`: Area name. Also available in `{text}`.
|
||||
* `desc`: Area description.
|
||||
|
||||
When dealing with the file base, ENiGMA½ does not currently have the ability to set newscan dates for specific areas. No `%SM2` is used in this case.
|
||||
|
||||
### Submit Actions
|
||||
Submit action should map to `@method:scanDateSubmit` and provide `scanDate` in form data. For message conf/areas (`target` of `message`), `targetSelection` should be also be provided in form data: An index to the selected conf/area.
|
||||
70
docs/_docs/modding/show-art.md
Normal file
70
docs/_docs/modding/show-art.md
Normal file
|
|
@ -0,0 +1,70 @@
|
|||
---
|
||||
layout: page
|
||||
title: The Show Art Module
|
||||
---
|
||||
## The Show Art Module
|
||||
The built in `show_art` module add some advanced ways in which you can configure your system to display art assets beyond what a standard menu entry can provide. For example, based on user selection of a file or message base area.
|
||||
|
||||
## Configuration
|
||||
### Config Block
|
||||
Available `config` block entries:
|
||||
* `method`: Set the method in which to show art. See **Methods** below.
|
||||
* `optional`: Is this art required or optional? If non-optional and we cannot show art based on `method`, it is an error.
|
||||
* `key`: Used for some `method`s. See **Methods**
|
||||
|
||||
### Methods
|
||||
#### Extra Args
|
||||
When `method` is `extraArgs`, the module selects an *art spec* from a value found within `extraArgs` that were passed to `show_art` by `key`. Consider the following:
|
||||
|
||||
Given an `menu.hjson` entry:
|
||||
```hjson
|
||||
showWithExtraArgs: {
|
||||
module: show_art
|
||||
config: {
|
||||
method: extraArgs
|
||||
key: fooBaz
|
||||
}
|
||||
}
|
||||
```
|
||||
If the `showWithExtraArgs` menu was entered and passed `extraArgs` as the following:
|
||||
```json
|
||||
{
|
||||
"fizzBang" : true,
|
||||
"fooBaz" : "LOLART"
|
||||
}
|
||||
```
|
||||
|
||||
...then the system would use the *art spec* of `LOLART`.
|
||||
|
||||
#### Area & Conferences
|
||||
Handy for inserting into File Base, Message Conferences, or Mesage Area selections selections. When `method` is `fileBaseArea`, `messageConf`, or `messageArea` the selected conf/area's associated *art spec* is utilized. Example:
|
||||
|
||||
Given a file base entry in `config.hjson`:
|
||||
```hjson
|
||||
areas: {
|
||||
all_ur_base: {
|
||||
name: All Your Base
|
||||
desc: chown -r us ./base
|
||||
art: ALLBASE
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
A menu entry may look like this:
|
||||
```hjson
|
||||
showFileBaseAreaArt: {
|
||||
module: show_art
|
||||
config: {
|
||||
method: fileBaseArea
|
||||
cls: true
|
||||
pause: true
|
||||
menuFlags: [ "popParent", "noHistory" ]
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
...if the user choose the "All Your Base" area, the *art spec* of `ALLBASE` would be selected and displayed.
|
||||
|
||||
The only difference for `messageConf` or `messageArea` methods are where the art is defined (which is always next to the conf or area declaration in `config.hjson`).
|
||||
|
||||
While `key` can be overridden, the system uses `areaTag` for message/file area selections, and `confTag` for conference selections by default.
|
||||
96
docs/_docs/modding/telnet-bridge.md
Normal file
96
docs/_docs/modding/telnet-bridge.md
Normal file
|
|
@ -0,0 +1,96 @@
|
|||
---
|
||||
layout: page
|
||||
title: Telnet Bridge
|
||||
---
|
||||
## Telnet Bridge
|
||||
The `telnet_bridge` module allows "bridged" Telnet connections from your board to other Telnet services (such as other BBSes!).
|
||||
|
||||
## Configuration
|
||||
### Config Block
|
||||
Available `config` entries:
|
||||
* `host`: Hostname or IP address to connect to.
|
||||
* `port`: Port to connect to. Defaults to the standard Telnet port of `23`.
|
||||
* `font`: A SyncTERM style font. Useful for example if you would like to connect form a "DOS" style BBS to an Amiga. See [the general art documentation on SyncTERM Style Fonts](../art/general.md).
|
||||
|
||||
### Example
|
||||
Below is an example `menu.hjson` entry that would connect to [Xibalba](https://xibalba.l33t.codes):
|
||||
|
||||
```hjson
|
||||
{
|
||||
telnetBridgeXibalba: {
|
||||
desc: Xibalba BBS
|
||||
module: telnet_bridge
|
||||
config: {
|
||||
host: xibalba.l33t.codes
|
||||
port: 45510
|
||||
}
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
### Using Extra Args
|
||||
The `telnet_bridge` module can also accept standard `extraArgs` of the same configuration arguments described above. This can be illustrated with an example:
|
||||
|
||||
```hjson
|
||||
telnetBridgeMenu: {
|
||||
desc: Telnet Bridge
|
||||
art: telnet_bridge
|
||||
config: {
|
||||
font: cp437
|
||||
}
|
||||
form: {
|
||||
0: {
|
||||
mci: {
|
||||
VM1: {
|
||||
argName: selection
|
||||
|
||||
items: [
|
||||
{
|
||||
board: BLACK Flag
|
||||
soft: Mystic
|
||||
data: bf
|
||||
}
|
||||
{
|
||||
board: Xibalba
|
||||
soft: ENiGMA½
|
||||
data: xib
|
||||
}
|
||||
]
|
||||
|
||||
// sort by 'board' fields above
|
||||
sort: board
|
||||
submit: true
|
||||
}
|
||||
}
|
||||
|
||||
submit: {
|
||||
*: [
|
||||
{
|
||||
value: { "selection" : "bf" }
|
||||
action: @menu:telnetBridgeFromExtraFlags
|
||||
extraArgs: {
|
||||
host: blackflag.acid.org
|
||||
}
|
||||
}
|
||||
{
|
||||
value: { "selection" : "xib" }
|
||||
action: @menu:telnetBridgeFromExtraFlags
|
||||
extraArgs: {
|
||||
host: xibalba.l33t.codes
|
||||
port: 44510
|
||||
}
|
||||
}
|
||||
]
|
||||
}
|
||||
}
|
||||
}
|
||||
}
|
||||
|
||||
telnetBridgeFromExtraFlags: {
|
||||
desc: Telnet Bridge
|
||||
module: telnet_bridge
|
||||
}
|
||||
```
|
||||
|
||||
Here we've created a lightbar menu with custom items in which we'd use `itemFormat`'s with in a theme. When the user selects an item, the `telnetBridgeFromExtraFlags` menu is instantiated using the supplied `extraArgs`.
|
||||
|
||||
60
docs/_docs/modding/top-x.md
Normal file
60
docs/_docs/modding/top-x.md
Normal file
|
|
@ -0,0 +1,60 @@
|
|||
---
|
||||
layout: page
|
||||
title: TopX
|
||||
---
|
||||
## The TopX Module
|
||||
The built in `top_x` module allows for displaying oLDSKOOL (?!) top user stats for the week, month, etc. Ops can configure what stat(s) are displayed and how far back in days the stats are considered.
|
||||
|
||||
## Configuration
|
||||
### Config Block
|
||||
Available `config` block entries:
|
||||
* `mciMap`: Supplies a mapping of MCI code to data source. See `mciMap` below.
|
||||
|
||||
#### MCI Map (mciMap)
|
||||
The `mciMap` `config` block configures MCI code mapping to data sources. Currently the following data sources (determined by `type`) are available:
|
||||
|
||||
| Type | Description |
|
||||
|-------------|-------------|
|
||||
| `userEventLog` | Top counts or sum of values found in the User Event Log. |
|
||||
| `userProp` | Top values (aka "scores") from user properties. |
|
||||
|
||||
##### User Event Log (userEventLog)
|
||||
When `type` is set to `userEventLog`, entries from the User Event Log can be counted (ie: individual instances of a particular log item) or summed in the case of log items that have numeric values. The default is to sum.
|
||||
|
||||
Some current User Event Log `value` examples include `ul_files`, `dl_file_bytes`, or `achievement_earned`. See [user_log_name.js](/core/user_log_name.js) for additional information.
|
||||
|
||||
Example `userEventLog` entry:
|
||||
```hjson
|
||||
mciMap: {
|
||||
1: { // e.g.: %VM1
|
||||
type: userEventLog
|
||||
value: achievement_pts_earned // top achievement points earned
|
||||
sum: true // this is the default
|
||||
daysBack: 7 // omit daysBack for all-of-time
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
#### User Properties (userProp)
|
||||
When `type` is set to `userProp`, data is collected from individual user's properties. For example a `value` of `minutes_online_total_count`. See [user_property.js](/core/user_property.js) for more information.
|
||||
|
||||
Example `userProp` entry:
|
||||
```hjson
|
||||
mciMap: {
|
||||
2: { // e.g.: %VM2
|
||||
type: userProp
|
||||
value: minutes_online_total_count // top users by minutes spent on the board
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
## Theming
|
||||
Generally `mciMap` entries will point to a Vertical List View Menu (`%VM1`, `%VM2`, etc.). The following `itemFormat` object is provided:
|
||||
* `value`: The value acquired from the supplied data source.
|
||||
* `userName`: User's username.
|
||||
* `realName`: User's real name.
|
||||
* `location`: User's location.
|
||||
* `affils` or `affiliation`: Users affiliations.
|
||||
* `position`: Rank position (numeric).
|
||||
|
||||
Remember that string format rules apply, so for example, if displaying top uploaded bytes (`ul_file_bytes`), a `itemFormat` may be `{userName} - {value!sizeWithAbbr}` yielding something like "TopDude - 4 GB". See [MCI](../art/mci.md) for additional information.
|
||||
73
docs/_docs/modding/user-2fa-otp-config.md
Normal file
73
docs/_docs/modding/user-2fa-otp-config.md
Normal file
|
|
@ -0,0 +1,73 @@
|
|||
---
|
||||
layout: page
|
||||
title: 2FA/OTP Config
|
||||
---
|
||||
## The 2FA/OTP Config Module
|
||||
The `user_2fa_otp_config` module provides opt-in, configuration, and viewing of Two-Factor Authentication via One-Time-Password (2FA/OTP) settings. In order to allow users access to 2FA/OTP, the system must be properly configured. See [Security](../configuration/security.md) for more information.
|
||||
|
||||
:information_source: By default, the 2FA/OTP configuration menu may only be accessed by users connected securely (ACS `SC`). It is highly recommended to leave this default as accessing these settings over a plain-text connection could expose private secrets!
|
||||
|
||||
## Configuration
|
||||
|
||||
### Config Block
|
||||
Available `config` block entries:
|
||||
* `infoText`: Overrides default informational text string(s). See **Info Text** below.
|
||||
* `statusText:` Overrides default status text string(s). See **Status Text** below.
|
||||
|
||||
Example:
|
||||
```hjson
|
||||
config: {
|
||||
infoText: {
|
||||
googleAuth: Google Authenticator available on mobile phones, etc.
|
||||
}
|
||||
statusText: {
|
||||
saveError: Doh! Failed to save :(
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
#### Info Text (infoText)
|
||||
Overrides default informational text relative to current selections. Available keys:
|
||||
* `disabled`: Displayed when OTP switched to enabled.
|
||||
* `enabled`: Displayed when OTP switched to disabled.
|
||||
* `rfc6238_TOTP`: Describes TOTP.
|
||||
* `rfc4266_HOTP`: Describes HOTP.
|
||||
* `googleAuth`: Describes Google Authenticator OTP.
|
||||
|
||||
#### Status Text (statusText)
|
||||
Overrides default status text for various conditions. Available keys:
|
||||
* `otpNotEnabled`
|
||||
* `noBackupCodes`
|
||||
* `saveDisabled`
|
||||
* `saveEmailSent`
|
||||
* `saveError`
|
||||
* `qrNotAvail`
|
||||
* `emailRequired`
|
||||
|
||||
## Theming
|
||||
The following MCI codes are available:
|
||||
* MCI 1: (ie: `TM1`): Toggle 2FA/OTP enabled/disabled.
|
||||
* MCI 2: (ie: `SM2`): 2FA/OTP type selection.
|
||||
* MCI 3: (ie: `TM3`): Submit/cancel toggle.
|
||||
* MCI 10...99: Custom entries with the following format members available:
|
||||
* `{infoText}`: **Info Text** for current selection.
|
||||
|
||||
### Web and Email Templates
|
||||
A template system is also available to customize registration emails and the landing page.
|
||||
|
||||
#### Emails
|
||||
Multipart MIME emails are send built using template files pointed to by `users.twoFactorAuth.otp.registerEmailText` and `users.toFactorAuth.otp.registerEmailHtml` supporting the following variables:
|
||||
* `%BOARDNAME%`: BBS name.
|
||||
* `%USERNAME%`: Username receiving email.
|
||||
* `%TOKEN%`: Temporary registration token generally used in URL.
|
||||
* `%REGISTER_URL%`: Full registration URL.
|
||||
|
||||
#### Landing Page
|
||||
The landing page template is pointed to by `users.twoFactorAuth.otp.registerPageTemplate` and supports the following variables:
|
||||
* `%BOARDNAME%`: BBS name.
|
||||
* `%USERNAME%`: Username receiving email.
|
||||
* `%TOKEN%`: Temporary registration token generally used in URL.
|
||||
* `%OTP_TYPE%`: OTP type such as `googleAuth`.
|
||||
* `%POST_URL%`: URL to POST form to.
|
||||
* `%QR_IMG_DATA%`: QR code in URL image data format. Not always available depending on OTP type and will be set to blank in these cases.
|
||||
* `%SECRET%`: Secret for manual entry.
|
||||
21
docs/_docs/modding/user-list.md
Normal file
21
docs/_docs/modding/user-list.md
Normal file
|
|
@ -0,0 +1,21 @@
|
|||
---
|
||||
layout: page
|
||||
title: User List
|
||||
---
|
||||
## The User List Module
|
||||
The built in `user_list` module provides basic user list functionality.
|
||||
|
||||
## Configuration
|
||||
### Config Block
|
||||
Available `config` block entries:
|
||||
* `dateTimeFormat`: [moment.js](https://momentjs.com) style format. Defaults to current theme → system `short` format.
|
||||
|
||||
### Theming
|
||||
The following `itemFormat` object is provided to MCI 1 (ie: `%VM1`):
|
||||
* `userId`: User ID.
|
||||
* `userName`: Login username.
|
||||
* `realName`: User's real name.
|
||||
* `lastLoginTimestamp`: Full last login timestamp for formatting use.
|
||||
* `lastLoginTs`: Last login timestamp formatted with `dateTimeFormat` style.
|
||||
* `location`: User's location.
|
||||
* `affiliation` or `affils`: Users affiliations.
|
||||
18
docs/_docs/modding/whos-online.md
Normal file
18
docs/_docs/modding/whos-online.md
Normal file
|
|
@ -0,0 +1,18 @@
|
|||
---
|
||||
layout: page
|
||||
title: Who's Online
|
||||
---
|
||||
## The Who's Online Module
|
||||
The built in `whos_online` module provides a basic who's online mod.
|
||||
|
||||
### Theming
|
||||
The following `itemFormat` object is provided to MCI 1 (ie: `%VM1`):
|
||||
* `userId`: User ID.
|
||||
* `userName`: Login username.
|
||||
* `node`: Node ID the user is connected to.
|
||||
* `timeOn`: A human friendly amount of time the user has been online.
|
||||
* `realName`: User's real name.
|
||||
* `location`: User's location.
|
||||
* `affiliation` or `affils`: Users affiliations.
|
||||
* `action`: Current action/view in the system taken from the `desc` field of the current MenuModule they are interacting with. For example, "Playing L.O.R.D".
|
||||
|
||||
Loading…
Add table
Add a link
Reference in a new issue