GorBot can be used through both Discord and the Web Dashboard.

For ordinary players, the quickest starting points are:

• use =help or /bothelp for help inside Discord;
• create a character, import an existing profile, or select one you already own;
• select the character you want as active before using active-character features;
• use =say <message> to speak as the active character;
• optionally configure a private Character Speaking Prefix such as [dyne on the character's Edit Character screen;
• use =profile to display the active character's populated profile in Discord;
• use the Character Library for full profile editing, import/export, public sharing, portraits, and active-character management;
• use My Roleplay → Player Studio for Player Galleries, Publications, Character Profile Cards, User Profile Cards, and Character Groups;
• reuse approved external media and existing owned Character images across supported Player Studio features without repeatedly uploading the same artwork;
• use the NPC Database for NPCs you own or eligible published NPCs you can browse;
• use Roleplay Wallet & Inventory to load a Discord server's economy, view the active wallet, choose a preferred currency, and use supported wallet actions;
• server owners and authorized managers can use Server Management → Community Power for Forms & Applications, Suggestions, Giveaways, Honeypot Protection, Verification, Starboards, Sticky Messages, Question of the Day, Counting, Invite Tracking, Bump Reminders, Leveling, Reputation, and related workflows;
• remember that the server owner chooses which currencies exist; a player's Preferred Currency can only be selected from currencies enabled by that Discord server;
• use the Contact Us form when you need direct GorBot support, billing help, account help, a bug report, privacy/security assistance, or want to submit a feature suggestion/feedback;
• use Discord slash-command autocomplete to see currently enabled slash-command options.

GorBot also applies the server's current command-access rules. A server may designate a Blocked Command Role or Command-Silent Channels. These restrictions can prevent prefix and slash/application commands even when Discord still displays them in autocomplete. Buttons, select menus, onboarding controls, and reaction-role interactions remain available where configured.

The default GorBot message-command prefix used throughout this guide is:

=

A server owner can configure a different GorBot command prefix. If your server has done so, replace = in the command examples below with that server's configured prefix.

Character Speaking Prefixes are different. A speaking prefix belongs to one player's character and does not replace the server's GorBot command prefix.

Important: knowing the text of a staff command does not grant permission to use it. GorBot checks the Discord user, server authority, roles, ownership, and Discord permissions before protected actions are allowed.

Open My Roleplay → Player Studio to manage GorBot's connected player-creation tools.

Player Studio includes:

• Player Image Galleries — organize externally hosted artwork, screenshots, maps, references, event images, and other supported roleplay media;
• Player Publications — advertise and catalog books, stories, guides, journals, or other player-created publications using supported external resource links;
• Character Profile Cards — design presentation cards for individual characters while choosing which Character Profile values appear and which values are overridden only on the card;
• User Profile Cards — create a player-level presentation card that can feature owned Characters, Galleries, Publications, profile information, and selected imagery;
• Character Groups — organize large Character Libraries into player-defined folders/groups without changing character ownership or profile data.

These systems are player-facing. They are not removed merely because a Discord server does not have Server Premium.

Shared media model

GorBot separates media hosting, media ownership, and presentation.

Normal Player Gallery and Publication media uses an approved HTTPS external-media reference. GorBot stores the reference, provider information, ownership relationship, metadata, and usage relationship rather than treating the Gallery as an unrestricted general-purpose upload service.

Existing images already owned through GorBot's Character system are the controlled exception. They may be reused by supported Profile Card and Publication-cover workflows without requiring the player to upload the same Character artwork again.

The shared media framework also tracks where a media reference is being used so GorBot can warn before a referenced Gallery/Character image is removed.

Direct-upload policy

The initial Player Studio release does not turn the new systems into general file-hosting endpoints.

By default:

• Gallery direct uploads are OFF;
• Publication file uploads are OFF;
• Character Card direct uploads are OFF;
• User Card direct uploads are OFF.

A Character Profile Card can reuse images already attached to the Character being edited. A User Profile Card can reuse owned Character images. Galleries normally contain approved external image references.

This keeps the Player Studio flexible without bypassing GorBot's established Character-image ownership/storage controls.

Player Image Galleries

A Gallery can contain externally hosted images with information such as title, caption, description, alternate text, artist/credit information, tags, Character association, visibility, and ordering.

Supported visibility can include public, server-only, unlisted, or private behavior where exposed by the current interface.

Gallery references can later be reused by supported Character Cards, User Cards, and Publication covers without asking the player to paste the URL again.

If an external resource becomes unavailable, GorBot can mark the reference unavailable rather than destroying the Gallery record. Public presentation degrades safely instead of breaking the entire page.

Publications / Books

Player Publications are catalog/listing records. GorBot normally does not host the publication file itself.

A Publication can maintain supported metadata such as:

• title/subtitle and author information;
• associated Character;
• series/volume information;
• descriptions;
• cover image;
• release/revision information;
• language, genre, tags, format, and content rating;
• one or more supported external resource links.

Publishing requires an affirmative rights confirmation. The player represents that they own the submitted material or have permission to share/advertise the linked publication and associated artwork/resources.

Public Publication pages can be reported when necessary.

Character Profile Cards

From My Characters, open the supported Profile Card action for an owned Character.

A Character Card is a presentation layer. It does not replace the Character Profile.

For compatible data, a card element can use:

• the current authoritative Character Profile value;
• a card-specific override that leaves the Character Profile unchanged;
• a card-only custom field;
• supported system-derived values such as Gallery/Publication relationships.

A card using a Profile value follows later Profile changes automatically. A custom override remains card-specific.

Character Card imagery can use the current Character's existing owned images, the player's Gallery references, approved GorBot assets where available, and approved external HTTPS media. The Card Designer does not create a new direct-upload path.

User Profile Cards

User Cards represent the player's GorBot identity rather than one specific Character.

Depending on the current card design, the player can feature supported User/Profile information, owned Characters, Gallery/Publication information, custom fields, profile imagery, owned Character imagery, approved Gallery media, and approved external media.

A User Card may reuse an image belonging to a Character only when that Character belongs to the current player. Public visibility of another player's Character never grants media-reuse ownership.

Player Studio safety limits

The initial limits are intentionally generous anti-abuse boundaries rather than Server Premium paywalls.

Installation policy can evolve, but ordinary Player Studio access is intentionally separate from a server's Premium entitlement.

External media safety

External media must use supported HTTPS/provider rules. GorBot rejects unsafe URL forms such as local/private-network targets, credential-bearing URLs, prohibited schemes, and malformed references.

Public content can be reported. GorBot administrators can moderate public Gallery images, Galleries, Publications, Character Cards, and User Cards. Media marked blocked is filtered from public presentation, including dependent public cards/covers that referenced that media.

How @@CMS0@@ behaves: GorBot should only remove the original =say command after the character webhook message is successfully posted. If the relay fails, the original message should remain so the player's roleplay text is not lost.

Character Speaking Prefixes are not GorBot commands. A player may optionally configure a private prefix such as [dyne for a specific character. GorBot checks the Discord author first and only uses that prefix when the matching owned character is active. Server command-prefix processing keeps priority.

Slash-command availability can depend on the current GorBot release and which modules a server has enabled. Discord's autocomplete shows the subcommands currently registered on that server.

Command Access Guard: Discord may continue displaying a slash command after GorBot has blocked its execution. If the member holds the configured Blocked Command Role or the command is used in a configured Command-Silent Channel, GorBot rejects the application command server-side. The Blocked Command Role takes priority even over Bot Commander and server-owner command authority.

The full character system is documented at Characters & Profiles.

A normal player workflow is:

create a character through the dashboard, import an existing profile, or use a supported /character command;

choose the profile style that fits the character;

fill in only the information you want to use;

add a portrait and up to 12 custom fields where desired;

optionally enable public profile sharing;

optionally configure a private Character Speaking Prefix;

select the character as active;

use =say <message>, /character say, or the character's configured speaking prefix for character speech.

A Discord account can maintain up to 150 characters. The full Character Library remains available for browsing and management even when a player owns many characters.

Active Character

Many roleplay actions use one selected active character.

On the Web Dashboard, the top-right active-character selector is intentionally compact. It shows up to the five most recently activated characters rather than trying to place as many as 150 characters into one dropdown. Use the Character Library when you need to activate a character that is not in that recent-five list.

Changing the active character also changes which private Character Speaking Prefix can respond for your account.

Profile Styles

GorBot currently provides 12 structured profile styles:

• Gorean;
• Standard RP;
• Fantasy RP;
• Tabletop D&D;
• Modern / Sci-Fi RP;
• Eryndor Drifter;
• Mad Tea Party;
• Supernatural;
• Tensei Slime;
• Furry;
• S&M / BDSM Safety;
• Custom / Freeform.

Gender and Pronouns are available across all profile styles. The Tabletop D&D sheet includes expanded identity, ability score, saving throw, skill, combat, proficiency, inventory, currency, feature, and spellcasting fields.

Profile values are stored by style so switching from one style to another does not intentionally erase the values previously entered for the other style.

Field-Specific Limits and Live Counters

Profile fields no longer share one broad generic text allowance. GorBot applies field-specific limits based on each field's purpose—for example, Age is intentionally short while Biography and other narrative fields can remain much longer.

Character and NPC editors show live character counters where supported. The same limits are enforced again by the server when saving, so bypassing the browser counter cannot store oversized data. If a save is rejected, shorten the named field rather than assuming GorBot silently truncated it.

Public Profile Sharing

Characters can be shared through a public profile link when sharing is enabled.

The Character Library provides supported share controls such as:

• Copy Share Link;
• Open Share Link.

New compact share links are supported, while existing legacy share links remain valid. Disabling sharing, rotating the share token, or deleting the character can invalidate the corresponding public link.

A public profile remains presentation-only. It does not transfer character ownership or edit authority.

Character Speaking Prefix

Edit Character includes an optional Character Speaking Prefix field.

Example:

[dyne Tal, traveler. What brings you to the city?

If Dyne is the message author's active character and Dyne owns the prefix [dyne, GorBot can relay the remaining message as Dyne.

Rules:

• the prefix belongs to that specific character;
• it works only for the Discord account that owns the character;
• it responds only while that character is active;
• the same player may store the same prefix on more than one character, but only the active character can respond;
• different Discord users may safely use the same prefix because GorBot checks the message author first;
• the field is optional; blank means no custom speaking prefix;
• prefixes are 2–24 characters and cannot contain whitespace/control characters;
• the server's normal GorBot command prefix is separate and keeps command priority;
• private speaking-prefix configuration is not displayed on the character's public shared profile.

The editor may allow you to configure the prefix while the character is inactive. It simply remains dormant until that character becomes active.

The Character Library provides Import and Export JSON controls.

Supported import paths include:

• GorBot JSON — intended for the most complete GorBot-to-GorBot profile restore/copy workflow;
• Tupperbox JSON — recognizes the current Tupperbox export structure and maps useful roleplay profile values;
• Generic JSON — best-effort mapping for common profile field names;
• Raw Text — best-effort parsing of labeled profiles, headings, and common roleplay sheet formats.

Raw Text import can recognize common labels and can auto-detect supported profile families such as Gorean, D&D, Eryndor, Mad Tea Party, Supernatural, Tensei Slime, Furry, and S&M / BDSM Safety when the source text contains enough recognizable structure.

Always review the preview before saving an import.

Import intentionally uses a preview-first workflow because third-party and Raw Text profiles may use ambiguous labels.

Important protections include:

• imports create new character records rather than silently overwriting an existing character;
• duplicate-name warnings can be shown before creation;
• the source character owner identity is not reused;
• source public-share tokens are not reused;
• the character capacity limit is checked again before the import is committed;
• external avatar URLs must use supported HTTPS sources;
• a verified batch can create only a limited number of selected characters at once;
• native GorBot data preserves supported profile styles, profile/custom fields, proxy settings, privacy options, and Character Speaking Prefix data where present.

Operational third-party metadata that is not useful to the roleplay profile may be intentionally ignored.

Raw Text Tips

For the best mapping results, use clear labels such as:

<pre>Name: Dyne
Age: 27
Gender: Female
Pronouns: she/her
Species: Human
Personality: ...
Biography: ...</pre>

Formats such as Label: Value, Label = Value, labeled headings, and common Markdown-style headings are easier for the importer to interpret than an unlabeled wall of text.

Anything ambiguous should be reviewed and corrected in the preview before import.

The full NPC management system is documented at NPC Database and NPCs & Shared Roleplay.

Depending on server configuration, ownership, and current capacity, users can:

• create and maintain NPC profiles;
• maintain NPC portraits and profile information;
• use the same expanded profile-style foundation available to characters where applicable;
• add up to 12 custom fields;
• clone owned NPCs;
• share supported public NPC profiles;
• publish eligible NPCs into the broader global NPC listing;
• browse/search eligible Published NPCs;
• use supported /npc commands for conversation-oriented NPC features.

A player's NPC collection can support up to 30 owned NPC records under the current NPC capacity model.

Sharing or publishing an NPC profile does not automatically give another user edit ownership. Draft/private NPCs are not part of the public/global published browser.

When you use character speech, GorBot can relay your message through a Discord webhook using the selected character's name and portrait.

Standard example:

=say Tal, traveler. What brings you to the city?

GorBot posts the supplied dialogue as the active character.

Your Discord account still remains the internal owner of that character. Character speech is fictional presentation; it does not make the webhook identity a separate Discord account.

Threads and forum posts: character speech can work inside supported threads when GorBot has the required channel and webhook permissions.

Tupper-style private Character Speaking Prefixes

Players who prefer a faster roleplay workflow can configure an optional prefix on each character's Edit Character screen.

Example account:

<pre>Dyne → [dyne
Tarl → [tarl
Marcus → [marcus</pre>

If Dyne is active:

[dyne Tal, traveler.

can relay the message as Dyne.

If the same player switches their active character to Tarl, [dyne becomes dormant and Tarl's configured prefix becomes eligible instead.

These prefixes are account-scoped, not globally reserved. Another Discord user can also configure [dyne for one of their own characters without causing a collision, because GorBot first identifies who sent the message and then checks that user's active character.

The server's normal GorBot command prefix remains separate. Character speaking prefixes do not take ownership of protected GorBot commands.

Large Discord Profiles

Using =profile with a heavily populated character can produce multiple embeds.

GorBot continues across additional profile messages as needed so populated fields are not silently lost. The character portrait is shown on the first embed only, and biography/public share information is placed at the end of the profile output.

The most important rule: the Discord server defines the economy.

GorBot's modern Economy system is scoped to each Discord server. The server owner or authorized manager chooses which currencies exist, how wallets work, whether banking/transfers/exchange are enabled, and which jobs or organizations are available.

A normal player does not replace the server's economy with a different universe preset. Instead, the player can choose a Preferred / Active Currency from the currencies that the selected server has enabled.

This means the same Discord user can participate safely in completely different economies:

• one server may use Gold Pieces;
• another may use Bottle Caps;
• another may use Eurodollars;
• another may use a completely custom homebrew currency.

Balances and currency definitions remain isolated by Discord server.

Player workflow — Roleplay Wallet & Inventory

Open My Roleplay → Roleplay Wallet & Inventory.

Choose the Discord server whose economy you want to view.

Select Load wallet.

Review the enabled currencies and current cash/bank balances.

Choose a Preferred / Active Currency when more than one currency is enabled.

Use Deposit, Withdraw, or Player Transfer when those actions are enabled by the server.

Use Open Full Economy for the selected server's complete Economy workspace and any additional player-facing economy features.

The preferred-currency choice is saved for that Discord user and that Discord server only. Changing it does not convert money and does not change another server's preference.

If only one currency is enabled, the preferred-currency list naturally contains only that currency.

Wallet Models

Server owners can configure how player wealth is attached:

• Account Wallet — the Discord account owns the server wallet.
• Character Wallet — each roleplay character owns a separate server wallet.
• Hybrid Wallet — character cash plus an account-level bank. Hybrid is a Server Premium economy capability.

On a Character or Hybrid economy, activate or choose an eligible character before using character-specific wallet actions.

Starter balances are applied only once to an eligible wallet. GorBot does not repeatedly re-award starter money every time the player reloads the page.

Built-In Economy Presets

GorBot 2.9.0.0 includes 32 built-in economy templates. New server economies start from the neutral Custom / Homebrew preset unless the owner chooses something else. Existing configured economies are not silently changed.

Presets can contain one currency, hierarchical denominations, or multiple independent currencies. GorBot does not assume every setting uses decimal 10:1 money. For example, the Harry Potter preset supports 29 Knuts = 1 Sickle and 17 Sickles = 1 Galleon.

Free vs. Server Premium Economy

GorBot keeps the Free economy useful while reserving deeper simulation and scale for the Discord server's Premium entitlement.

Server plan limits can be administered by the GorBot installation's current plan policy. If the public Plans page shows a different current limit, the live plan page/policy is authoritative.

Multiple Currencies and Exchange

A Free server can choose any one built-in preset as its base economy.

A Server Premium economy can additionally merge currencies from another built-in preset without replacing the existing base preset or rewriting existing balances. This is useful for settings with regional money, faction money, exotic commodities, or cross-world roleplay.

Where Premium exchange is configured, players may convert between enabled currencies using the server-defined fixed exchange rules. Choosing a Preferred Currency by itself never performs a conversion.

For safety, GorBot blocks replacing the base preset or changing incompatible wallet models after live economic value exists. Those changes require a controlled migration rather than silently reinterpreting balances.

Organizations & Treasuries

Organizations are intentionally generic rather than tied to one roleplay universe. A server can model:

• cities;
• nations;
• factions;
• guilds;
• Houses;
• clans;
• corporations;
• temples;
• adventuring parties;
• settlements;
• or a custom organization type/name chosen for that community.

Organizations can hold treasury balances in accepted server currencies. Access can be delegated through configured roles, and Server Premium can support more organizations and advanced hierarchy/delegation behavior.

A Gorean server might call these city or caste treasuries. A fantasy server might use guild banks. A cyberpunk server might use corporate accounts. The underlying economy engine is the same.

Jobs and Activities

Server owners can create economy jobs with configurable currency, payout range, cooldown, success chance, role requirements, and success/failure text.

Server Premium can use advanced job requirements such as supported character profile style/field thresholds and can enable configurable gathering/activity definitions.

This allows the same job engine to represent very different worlds—for example a physician, merchant, miner, scavenger, netrunner, adventurer, or custom homebrew occupation.

Legacy inventory/shop/crafting compatibility

The Character inventory, older item shop, salvage values, and crafting records predate the new server-scoped Economy engine and are still global character compatibility data.

They are intentionally not treated as arbitrary server currency yet. Automatically buying an old global item with one server's currency and selling it into another server's currency could create cross-server value exploits.

For now:

• Roleplay Wallet = the modern server-scoped Economy balance;
• legacy item value = separate compatibility accounting for the old inventory/shop/crafting system.

No existing inventory is deleted. A future controlled item-economy migration can make those systems server-scoped safely.

Chronicles of Gor Compatibility

Gorean currency remains a first-class supported preset, but it is no longer GorBot's universal default for new server economies.

Existing Gorean servers and balances are preserved. Economy Manager retains a controlled one-time Legacy Gorean wallet import for servers intentionally using the Chronicles of Gor currency family. Existing non-zero destination wallets are left unchanged by that import.

The Web Dashboard uses Discord sign-in and applies the same ownership and server-authority rules as GorBot's other user-facing systems.

Players can use it for supported personal features such as:

• Character Library creation/editing;
• Player Studio Galleries, Publications, Character Profile Cards, User Profile Cards, and Character Groups;
• active-character selection;
• the recent-five active-character selector in the top-right dashboard area;
• Character Speaking Prefix configuration through Edit Character;
• Character Import and Export JSON;
• public Character share-link controls;
• Roleplay Wallet & Inventory with a Discord-server selector, server-scoped balances, preferred currency, and supported wallet actions;
• the full server Economy workspace for jobs, activities, exchange, organizations/treasuries, ledger/history, and other features when enabled for that server;
• NPC creation, ownership management, and eligible published NPC browsing;
• other personal/community tools exposed to their account.

Authorized server managers can use additional server-level pages for supported configuration, moderation, roles, automation, tracked content, and community features.

Current server-management additions include the Server Onboarder, Command Access Guard, Blocked Command Role, Command-Silent Channels, Permissions Doctor, Moderation Dashboard, Scheduled Operations, Global Audit Log, Server Health, configuration backup/restore/templates, welcome and goodbye controls, bot presentation, automations, polls, custom commands, timed messages, ticketing, reaction roles, social alerts, server statistics channels, Server Discovery publishing controls, and the server Economy Manager where enabled.

Server Management → Community Power consolidates the newer one-bot community suite: Forms & Applications, Suggestions, Giveaways, Honeypot Protection, Verification, Starboards, Sticky Messages, Question of the Day, Counting, Invite Tracking/reward roles, Bump Reminders, Leveling, Reputation, and related workflow/history settings.

Signing in identifies the Discord account. It does not automatically make the user a server administrator.

The dashboard also remembers supported view/position state within the browser session so returning to pages, tabs, forms, and the collapsible left menu can preserve context instead of repeatedly forcing the user back to the top of a long page or menu.

Role/channel/category/voice configuration fields use GorBot's shared searchable Discord-object picker where applicable. Click/focus a field to browse existing Discord objects, type to filter by friendly name or Discord ID, then select the intended object. Multi-select fields show removable chips. GorBot stores the Discord IDs while displaying readable names, and a previously configured object that was later deleted can remain visible as Unavailable until the owner deliberately replaces/removes it.

Open Server Management → Community Power as a server owner or authorized manager.

The 2.9.0.0 Community Power suite includes:

• Forms & Applications;
• Suggestions;
• Giveaways;
• Honeypot Protection;
• Verification;
• Starboards / Featured Messages;
• Sticky Messages;
• Question of the Day (QOTD);
• Counting;
• Invite Tracking;
• Invite reward roles;
• Bump / listing reminders;
• Leveling / XP;
• Level reward roles;
• XP booster rules on Server Premium;
• Reputation;
• reusable Forms for supported Ticket intake.

These features are designed around dashboard configuration and Discord-native buttons, selects, modals, roles, channels, scheduled processing, and runtime events. Do not assume that every dashboard feature has or needs a public prefix command.

Forms & Applications

Build reusable Forms for membership applications, staff applications, whitelist/character workflows, event signups, custom questionnaires, and other server processes.

Forms can support configured questions and server workflow settings such as manager/reviewer roles, required/blocked roles, destination/review channels, and accepted/denied role actions where enabled.

The Form engine is reusable. Ticket Panels can select an existing Community Power Form as their intake form instead of rebuilding the same questions inside every Ticket Panel. Inline Ticket questions remain available and use their own plan limit.

Application history is bounded by the server plan rather than growing forever.

Suggestions

Suggestion Boards give communities a managed place for member ideas and staff decisions. Supported workflows can include voting, staff review/status changes, responses, and retained suggestion history according to the configured board/workflow.

Use multiple boards on Premium when different teams or subjects need independent suggestion areas.

Giveaways

Community Power can create and manage reaction/interaction-based giveaways with configured prize, destination, duration, winner count, and supported eligibility rules.

Existing protected giveaway commands remain available where enabled, while the dashboard provides the larger management surface.

Server Premium raises active-giveaway capacity for communities that run many events.

Honeypot Protection

A Honeypot is a deliberately configured trap channel intended to catch obvious spam bots or compromised accounts that indiscriminately post where legitimate members were instructed not to post.

When a member triggers a configured Honeypot, GorBot can perform the configured protective response, such as deleting the trigger, logging the incident, and applying the selected moderation action where Discord permissions allow it.

Use a reversible action such as timeout/softban when appropriate for the community rather than treating every accidental trigger as grounds for an irreversible permanent ban.

Basic Honeypot protection remains available on Free servers; Premium primarily adds scale.

Verification

Verification profiles can define the server's supported verification flow and role changes. This can be used alongside onboarding to keep unverified members restricted until they complete the configured verification interaction.

GorBot still obeys Discord role hierarchy. A configured verified/unverified role cannot be changed when that role is above GorBot's manageable hierarchy.

Starboards, Sticky Messages, QOTD, and Counting

• Starboards / Featured Messages can mirror qualifying community messages into a configured destination based on the board's reaction/threshold rules.
• Sticky Messages keep an important configured message visible in an active channel by reposting it according to the feature's normal behavior.
• Question of the Day can post from configured question pools on the configured schedule.
• Counting maintains a controlled counting channel and validates the expected sequence according to its configured rules.

Each feature remains independently configurable rather than forcing every server into the same engagement style.

Invite Tracking and rewards

Invite Tracking records supported invite attribution and maintains the server's invite/history data under the configured retention policy.

Servers can create supported invite reward-role rules so reaching configured invite milestones can grant a role when GorBot has sufficient Discord permissions/hierarchy.

Rejoin/fake/ambiguous invite behavior follows the runtime's current attribution rules; no invite-tracking system should be treated as infallible when Discord does not provide enough information to prove a specific invite.

Bump / Listing Reminders

Bump Reminders can schedule a reminder message/role ping for configured server-listing or promotion workflows.

The reminder does not bypass a third-party service's cooldown or automatically grant listing priority. It reminds the community when the configured promotion action is due again.

Leveling, XP, and Reputation

Leveling can award supported server XP from eligible activity and can grant configured level-reward roles as members reach milestones.

Server Premium adds deeper scaling such as additional reward roles and configurable XP booster rules.

Reputation is a separate community progression/social metric and does not replace a Character's roleplay profile data or the server Economy.

Free vs. Server Premium

Free servers receive working versions of the Community Power features. Premium primarily increases scale, history, and advanced configuration.

When a server downgrades, GorBot preserves over-limit configuration where practical instead of destructively deleting it. Creation/use can be restricted until the configuration returns within the Free limits.

Searchable Discord fields

Community Power uses the same shared Discord-object picker as the rest of the modern dashboard.

For channel, category, voice-channel, and role fields:

click/focus the field to open the current Discord objects;

type part of the friendly name or Discord ID to filter immediately;

select the intended object;

for multi-select fields, repeat the search and remove selected items through their chips when necessary.

GorBot stores authoritative Discord IDs while displaying friendly names. A configured object that has since been deleted can remain visible as Unavailable so the setting is not silently lost.

A server owner should begin with permissions and role hierarchy before troubleshooting individual commands.

Recommended Discord permissions depend on enabled features, but common GorBot requirements include:

• View Channels;
• Send Messages;
• Read Message History;
• Send Messages in Threads;
• Embed Links;
• Manage Webhooks for character speech;
• Manage Messages when message cleanup or command replacement requires it;
• Manage Roles only when GorBot is expected to manage roles;
• moderation permissions only when the corresponding moderation features are enabled.

Role hierarchy matters. GorBot's highest Discord role must be above any role it is expected to assign, remove, rename, recolor, or otherwise manage.

Avoid granting permissions GorBot does not need simply to make an error disappear. Use the permissions required by the features your community actually uses.

Suggested owner setup order

confirm GorBot is online;

confirm its role position;

confirm basic channel permissions;

test /bothelp;

test a player character;

test =say;

configure self-service/community roles where desired;

configure moderation roles;

configure Community Power features only after the channels/roles they reference exist;

configure Forms first when Tickets or other workflows will reuse those Forms for intake;

configure automation only after its required roles/channels exist;

verify protected commands using an authorized staff account;

review the Web Dashboard for server-level configuration;

test new role/channel selections through the searchable picker and confirm the selected Discord object, not merely the typed search text.

Server owners can also define trusted staff/Bot Commander authority for protected GorBot management without making every ordinary moderator a full server owner.

Command prefix vs. Character Speaking Prefix: the server owner controls the normal GorBot command prefix used for commands such as =help and =say. Individual players may separately configure private speaking prefixes on their own characters. Those player prefixes are account-scoped and active-character-only; they do not replace or globally reserve the server's GorBot command prefix.

Economy Manager

The server Economy Manager is where owners/managers define the roleplay economy. Recommended setup order:

choose the base preset that fits the community, or use Custom / Homebrew;

choose Account or Character wallets; use Hybrid only when Server Premium is active and that model is intended;

review the preset currencies and denominations before players begin accumulating value;

set starting cash/bank values;

decide whether banking and player transfers are allowed;

create any allowed custom currencies;

create organizations/treasuries and delegate treasurer roles where desired;

create jobs and, on Premium, optional activities/gathering definitions;

on Premium, add additional preset currency families or fixed exchange pairs only when the setting actually needs them;

review ledger/analytics after players begin using the economy.

Important: do not treat preset replacement as a cosmetic change after players have balances. GorBot blocks unsafe preset/wallet reinterpretation once live value exists. Use additive Premium currencies or a future controlled migration instead.

See <a href="#support-economy">Economy & Wallets</a> for the player/server model and current Free/Premium limits.

Community Power setup

For a new server, a practical order is:

create the Discord channels/roles needed by the planned feature;

open Server Management → Community Power;

use the searchable Discord-object fields to select existing roles/channels instead of manually pasting IDs;

configure Forms before Ticket Panels when the Ticket workflow will reuse a Form;

configure Verification and Honeypot safety actions conservatively and test them with a non-critical test account/channel;

configure engagement features such as Suggestions, Starboards, Sticky Messages, QOTD, Counting, Invite rewards, and Leveling;

verify GorBot's role hierarchy before any feature that grants/removes a role;

review Free/Premium limits before creating large numbers of boards/rules/profiles;

test the live Discord interaction after saving the dashboard configuration.

Security-critical basics such as one Honeypot and one Verification profile remain usable on Free servers.

Command Access Guard (2.7.1.0)

Feature Toggles includes two server-level command protections:

• Blocked Command Role — one configured role whose members cannot execute GorBot prefix commands or slash/application/context commands. This denial takes priority over moderator, Bot Commander, and server-owner command authority, preventing an accidentally assigned management role from bypassing onboarding restrictions.
• Command-Silent Channels — multiple configured channels where prefix and slash/application/context commands are unavailable to everyone.

Prefix-command denials are intentionally silent to keep onboarding areas quiet. Slash/application denials are ephemeral and explain why execution is unavailable. Discord may still visually list the slash commands. Buttons, select menus, onboarding components, ticket controls, and reaction-role interactions are intentionally outside the command denial gate.

Server Onboarder

The current onboarder can track pending members, an onboarding role, waiting time, access progression, ticket/channel state, completion, and configured automatic enforcement. Completion from role removal requires GorBot to have actually observed the role present and then absent; a role that was never seen does not falsely complete onboarding.

If an automatic kick succeeds but ticket cleanup cannot complete, GorBot retains the ticket reference and marks cleanup pending instead of losing the remaining cleanup state. Unresolved onboarding tracking defaults to a 1,000-row safety cap per server and can be configured from 100–5,000; finalized history remains bounded by the current retention policy.

Examples use the default prefix =. Protected commands are intended for the server owner, Bot Commander, or authorized moderation roles as appropriate to the command.

Detailed @@CMS0@@ guide — destructive and immediate

=purge 50 deletes up to 50 recent messages of any kind in the current channel. With no count, the default is 100. GorBot accepts 1–1,000 and clamps larger requested counts to 1,000.

Supported filter forms include:

• =purge bots 100 — messages by any bot;
• =purge humans 100 — messages by non-bot users;
• =purge gorbot 100 — only messages authored by GorBot;
• =purge user @member 100 — messages from one user;
• =purge match phrase 100 — messages containing the phrase;
• =purge not phrase 100 — messages not containing the phrase;
• =purge startswith phrase 100 / =purge endswith phrase 100;
• =purge links 100, =purge invites 100, =purge images 100, =purge mentions 100, =purge embeds 100, or =purge text 100;
• =purge after <message ID or link> 100 — messages newer than the supplied message.

Recent eligible messages are bulk-deleted in Discord-supported batches. Messages older than Discord's bulk-delete age limit are attempted one by one so a mixed-age cleanup does not fail as one batch. There is no trash/recycle bin: verify the channel, mode, criterion, and count before running the command.

=clean [count] is the moderator-side shortcut that removes GorBot-authored messages from the current channel.

The NPC administration family is only useful when the relevant managed/Living NPC feature is enabled for the community. A command being recognized does not mean every server has that feature turned on.

The full public moderation guide is available at Moderation & Administration.

GorBot separates ordinary members, moderators, and server managers.

Moderation features can include:

• warnings and disciplinary history;
• message cleanup;
• mute/timeout;
• kick;
• ban;
• voice moderation;
• slowmode;
• role persistence;
• moderator roles;
• server-level moderation configuration;
• supported automated safety controls.

A moderator command can still fail if Discord role hierarchy or permissions prevent GorBot from acting on the target.

See Automation for the full feature overview.

Automations are normally configured through the Web Dashboard because triggers, roles, channels, actions, and publishing state are easier to understand visually.

Possible workflow inputs can include supported events involving:

• messages;
• reactions;
• automation buttons;
• role changes;
• voice activity;
• other enabled community events.

Automations still obey GorBot authorization and Discord permissions. Automating a role action does not allow GorBot to manage a role above its own highest role.

Command restrictions and precedence

GorBot can evaluate several independent command controls. A disabled command/module or an older ignored channel/user/role can stop ordinary command use. The newer Command Access Guard is stricter:

• the configured Blocked Command Role denies prefix and application commands even to Bot Commanders and the server owner;
• a configured Command-Silent Channel denies commands to everyone in that channel;
• Discord components such as buttons, select menus, onboarding controls, reaction roles, and ticket controls continue according to their own authorization rules;
• the normal progressive command cooldown targets ordinary player command abuse; confirmed server managers/owners remain exempt from that cooldown, but not from the explicit Blocked Command Role or Command-Silent Channel denial.

Honeypot and Verification security

Community Power adds two defensive tools that complement existing moderation/onboarding:

• Honeypot Protection watches intentionally configured trap channels and can log/delete/respond when a member posts there;
• Verification can require the configured verification interaction before applying/removing the server's verification roles.

Neither feature bypasses Discord hierarchy or permission rules.

Treat Honeypot actions as security automation: test the configured action before using a permanent punishment, clearly communicate any trap channel to legitimate users where appropriate, and review the security log after a trigger.

Never provide secrets to someone claiming they need them for a normal support request.

Normal GorBot users and server moderators should never need to reveal:

• a Discord account password;
• the Discord bot token;
• API keys;
• database passwords;
• OAuth application secrets;
• private server credentials.

If someone asks for sensitive credentials in order to use an ordinary GorBot feature, do not provide them. Contact the server owner or use <a href="/cms-page.php?slug=contact-us" target="_self">Contact Us</a> for support.

GorBot's public Contact Us form is the preferred way to reach the project when the Support guide does not resolve the issue.

Use <a href="/cms-page.php?slug=contact-us" target="_self">Contact Us</a> and choose the reason that best matches your request. Current routing categories include:

• General Support;
• Billing / Server Premium;
• Account / Login;
• Server Owner Support;
• Economy / Currency;
• Bug Report;
• Feature Suggestion / Feedback;
• Privacy / Data Request;
• Security Concern;
• Abuse / Moderation Concern;
• Legal;
• Copyright / DMCA;
• Other.

The selected reason determines which configured GorBot mailbox receives the message. The visitor does not need to know the underlying support email address and cannot see private mailbox configuration.

What happens after you submit

When a valid Contact Us request is accepted:

GorBot validates the request and selected support category;

the message is routed through the configured support mailbox for that category;

the email address entered by the visitor is used as the message's Reply-To address;

GorBot displays a reference number such as GOR-20260822-ABC123;

the support team can reply through normal email / Administrator Gateway Mail.

Keep the reference number if you need to follow up on the same request.

The Contact Us form does not require a visitor to expose Discord passwords, bot tokens, API keys, database credentials, mailbox passwords, OAuth secrets, or other private credentials.

No attachments

The public Contact Us form does not accept file attachments.

This is intentional. It keeps the public support surface smaller and safer and prevents unsolicited executable/archive uploads.

If a screenshot is useful, describe the visible error in the message. Support can request an appropriate follow-up method if additional evidence is genuinely necessary.

Do not place passwords, tokens, API keys, private database credentials, recovery codes, or other secrets in the message body.

Feedback now uses Contact Us

GorBot's previous standalone feedback path has been consolidated into the Contact Us system.

The existing Submit Feedback / Beta Feedback entry now routes users to:

Contact Us → Feature Suggestion / Feedback

New feedback is delivered to the configured email route instead of creating a new entry in the old Administrator Gateway Feedback Inbox.

Historical feedback records are retained for administrative history/recovery, but the old Feedback Inbox is no longer the normal destination for new public feedback.

Spam and abuse protection

The Contact Us form applies public-form protections including:

• CSRF validation;
• a hidden bot/honeypot field;
• browser and network rate limits;
• server-side email/category/field validation;
• duplicate/rapid-submission protections;
• a required acknowledgement not to send secrets;
• a bounded message length;
• rejection of file uploads.

A legitimate user who submits too many requests in a short period may be asked to wait before trying again.

For GorBot administrators

Mailbox credentials are managed only through the protected Administrator Gateway mail configuration. They are never entered into the public Contact Us form.

Administrator Gateway → Mail → Contact Routing controls which configured mailbox receives each support category. Routing can be assigned explicitly or left on the supported automatic/default behavior.

SMTP handles outbound delivery of the Contact Us submission to the routed mailbox. IMAP continues to synchronize/read the configured mailbox in Administrator Gateway Mail. Normal support staff should not need raw mailbox credentials to answer a submitted request.

If the problem continues after the relevant checks, use <a href="/cms-page.php?slug=contact-us" target="_self">Contact Us</a> and include the command or feature name, what you expected to happen, what actually happened, and any visible error message. Do not include passwords, tokens, API keys, database credentials, mailbox passwords, or other secrets.