MD Visitors Tracker User Manual

Summary:


Initial notes

! IMPORTANT: The following user manual presents and explains the usage and detailed features of:

  • MD Visitors Tracker & Greeter version 3.1.0
  • MD Visitors Tracker & Greeter (Bulb) version 3.1.0
  • MD Visitors Tracker & Greeter (Notepad) version 3.1.0
  • MD Visitors Tracker Board & Greeter version 3.1.0

When some of the features are available only for a specific version, will be clearly stated.


Chapter #1: initial setup

The setup of MD Visitor Tracker is very easy and quick: the owner will have to simply rez the tracker in-world and wait a few seconds for the automatic setup to complete; after that when the owner clicks on the tracker a dialog menu will appear, called “owner menu”: this dialog -accessible by the owner and the designed managers only – allows to enter the visitor tracker’s configuration settings and features.

The basic setup for the visitor tracker is complete.


Chapter #2: owner menu

Once the MD Visitors Tracker’s setup is complete, a click of the owner on it will open a menu called ‘owner menu’; this dialog is accessible by the owner and managers and contains all the settings and options of the tracker.

This menu is divided in many section, some of them leading into other sub menus:

  • Active: this button turns the tracker on/off, enabling or disabling the scan of the area specified;
  • Greeter: this button leads to a sub-menu where it is possible to define how the tracker will greet new visitors. More details in the dedicated chapter;
  • Options: this button leads to a sub-menu where it is possible to find all the additional settings, from how often the tracker will can the area (scan time), to the definition of the area to scan (scan area), to notifications and automatic reporting. More details in the dedicated chapter;
  • Users: this button leads to a sub-menu where it is possible to define and manage a list of avatars who can interact with the visitors tracker and also who should be excluded from the area scan. More details in the dedicated chapter;
  • Appearance: this button leads to a sub-menu containing several options to change the tracker’s appearance, from hover text to visibility; depending on the type of tracker, some options may or may not be available. More details in the dedicated chapter;
  • List Visitors: clicking on this button will present a list of all the latest visitors;
  • Update: pressing this button will start the update module and search for a new product update;
  • Reset: pressing this button will reset the MD Visitors Tracker;
MD Visitors Tracker – Owner menu
MD Visitors Tracker – Owner menu

Chapter #3: basic usage

The basic usage of the MD Visitor Tracker is very simple: once rezzed it’s immediately ready to work and clicking on the ‘Active’ button will start the scan of the area for visitors. By default, the tracker will work with these settings, that can be customised anytime:

  • Scan area type: spheric area;
  • Scan area range: 20 meters;
  • Scan time: 30 seconds;
  • Visitors greeting: off;
  • Notifications: owner only;
  • Report: daily at midnight SLT;

With these values the tracker will scan every 30 seconds a spheric area of 20 meters; if new avatars are found, an IM will be sent to the owner, reporting the name of the visitor and the visit date-time; also, at midnight SLT the daily visitors list will be sent to the owner via IM.

Please note: by default, no greet message nor item (landmark, notecard, object) is sent to the visitors. You can change this behaviour through the corresponding features in the ‘Greeter’ sub menu.


Chapter #4: greeter

The greeter submenu can be reached from the owner menu and is used to define every aspect about how the tracker will greet the new visitors: from the greet message sent to the type of items to offer to new visitors, from how often the same visitor should be greeted again after the first time.

MD Visitor Tracker – Greeter Menu
MD Visitor Tracker – Greeter Menu
  • Greet Msg: enabling this feature allows the owner to define a message that will be sent as greeting to every new visitor. Due to several limitations, messages set from the in-world tracker can be maximum 160 characters long;
  • Inviter: once this option is enabled the visitors tracker will include a group invitation message when greeting new visitors; the group is retrieved automatically from the tracker’s current group and the owner can change this setting anytime simply by changing the tracker’s group which can be found under right-click > Edit >General tab. The group invitation will be sent only to avatar who aren’t currently wearing the same group tag;
  • Giver: this button will open a secondary menu where the owner is asked to select one or more type of item which the tracker will offer to each new visitor; the choice can be make among three different item types: notecard, object and landmark.
    • IMPORTANT: before enabling this feature the owner has to drop one item of the corresponding type into the tracker’s content.
  • Chat/Window: this button acts as toggle and lets the owner define whether new visitors should be greeted receiving a local message or a dialog window to interact with.
    • In case the toggle is set to “Chat” each new visitor will receive:
      • The greeting message on local (if set);
      • A group invitation message on local chat (if set);
      • A notecard offer (if set);
      • An item offer (if set);
      • A landmark offer (if set);
    • In case the toggle is set to “Window” each new visitor will be prompted a dialog window containing:
      • The greeting message (if set);
      • A “Join Group” button (if set);
      • A “Notecard” button (if set);
      • An “item” button (if set);
      • A “Landmark” button (if set);
  • Greet Repeat: this last feature of the “Greeter” module allows the owner to define an interval (in hours) before which the same avatar visiting is greeted again; this setting is useful to avoid ‘spamming’ returning visitors with constant greeting messages and item offers. To enable this feature the owner is asked to submit a value – in hours – between 0 (every time) and 168 (once a week);
MD Visitors Tracker - Greeting window (example)
MD Visitors Tracker – Greeting window (example)

Chapter #5: options

The options submenu contains several specific options and features to customise even more MD Visitors Tracker and increase the overall experience.

MD Visitors Tracker – options submenu
MD Visitors Tracker – options submenu
  • Scan Area: the scan area defines the type and dimension of the area under tracking; MD Visitors Tracker is able to manage four different types of area:
    • Current Parcel: selecting this option the tracker will scan the whole parcel where the MD Visitors Tracker is currently rezzed;
    • All Parcels: selecting this option the tracker will scan all the parcels – belonging to the owner – in the region where the MD Visitors Tracker is currently rezzed;
    • Sphere area: this option configures the tracker to scan a spheric area and the owner is asked to submit the sphere’s dimension in meters, from 1 to 4095; Please note: when using a spherical shape, the effective scan area distance consist of the radius, which is at max scan range/2.
    • Custom area: this option allows the owner do define a custom-sized area for the tracker to scan; more information on how to create a custom scan area can be found in the dedicated chapter.
  • Scan Time: the scan time defines how often the MD Visitors Tracker will scan the area for new visitors; by default, the scan time is set to 30 seconds. Using this button the owner can change the scan time to any value between 20 and 300 seconds. !IMPORTANT: minimum scan time is 20 seconds and it cannot be set to a lower value.
  • Report: this button is a toggle to enable or disable the report feature, which sends the owner an automatic IM containing the daily visitors list. To enable this feature the owner will have to select a specific hour (in SLT) for the tracker to send the daily report, picking among:
    • Midnight (SLT);
    • 3AM (SLT);
    • 6AM (SLT);
    • 9AM (SLT);
    • Noon (SLT);
    • 3PM (SLT);
    • 6PM (SLT);
    • 9PM (SLT);
  • Notify: through this option is possible to define who among the owner and managers will receive notification IM when one or more visitors are found by the tracker; when activating this feature, the owner is asked to choose among several options:
    • Owner: only the owner will receive notifications about new visitors;
    • Managers: only the designed managers will receive notifications about new visitors;
    • Everyone: both owner and managers will receive notifications about new visitors;
  • Track Owner: when this option is enabled, the MD Visitors Tracker owner will be greeted and tracked just as a normal user.
  • Show Range: once enabled, this option will show the scan range as a semi-transparent sphere around the MD Visitor Tracker; this is useful to get a visual idea of the area under the tracker’s control. PLEASE NOTE: this option is available only if the scan area is set to spheric.
  • Hover Text: through this option is possible to set a custom text to be displayed on the MD Visitor Tracker as hover text; after clicking, the owner will be asked to submit a valid text. Once the hover text is set, clicking on the button again will disable it.
MD Visitors Tracker - scan area submenu
MD Visitors Tracker – scan area submenu

Chapter #5.1: defining a custom scan area

Along with parcel, region and spheric area MD Visitors Tracker allows the owner to create a custom-sized scan area: this option is particularly useful when – for example – both a private platform/house and a public area (i.e. a store) are hosted on the same parcel and only visitors in the public area should be greeted and their visit tracked. In this case if the scan area is set to “parcel” the tracker will scan and greet also visitors coming to the private area, creating unwanted messages and confusion.

The owner is able to define a custom scan area: this area can be only square-shaped or rectangular-shaped and once created only avatars found inside the area will be greeted and tracked. The idea behind a custom area is that only two points in space (X,Y,Z) are required to define a 3-dimensional area:

  • Bottom-left point;
  • Top-right point;

Given these two point, the tracker is able to generate automatically a 8-point area which defines the 3D area to scan.

MD Visitors Tracker - custom area (conceptual definition)
MD Visitors Tracker – custom area (conceptual definition)

The creation of a custom scan area is guided by a simple setup wizard which can be summarised in the following steps:

  1. the owner selects “Custom” in the “Scan Area” submenu;
  2. MD Visitors Tracker will rez a green cube next to it which represents the marker for the bottom-left corner of the area;
  3. the owner will have to move and place the green cube in the bottom-left corner of the area to scan and click on it once satisfied with the position;
  4. a menu dialog will appear and the owner will have to click the “Set Marker” button;
  5. MD Visitors Tracker will rez a rede cube next to it which represents the marker for the top-right corner of the area;
  6. the owner will have to move and place the red cube in the top-right corner of the area to scan and click on it once satisfied with the position;
  7. a menu dialog will appear and the owner will have to click the “Set Marker” button;
  8. at this point, clicking on either the green cube or red cube again will display a dialog window and the owner will have to click on the “Create Area” to finalise the creation of the scan area;
  9. if the creation is done successfully, MD Visitors Tracker will automatically delete the marker cubes;
  10. the custom area is correctly defined and setup;

MD Visitors Tracker - custom area creation
MD Visitors Tracker – custom area creation

Chapter #6: users

The users submenu allows the owner to define and interact with groups of avatars whom will have a special roles and permissions for the MD Visitors Tracker: managers and whitelisted avatars.

There are two possible roles for MD Visitors Tracker users:

  • Manager: an avatar designed as manager can interact with the MD Visitors Tracker in-world just as the owner and also access the dedicated MD Labs Online Services website;
  • Whitelist: when an avatar is added in whitelist is automatically excluded from the tracker’s scan and therefore it will not be greeted nor the visit notified to the owner. Differently from the manager, an avatar in whitelist cannot interact with the MD Visitors Tracker in-world nor access the MD Labs Online Services website;
MD Visitors Tracker - users submenu
MD Visitors Tracker – users submenu

The steps for adding an avatar as manager or whitelist are very similar: the owner – after clicking on the “users” button – will have to select the role to assign to the avatar among manager and whitelist; once the first selection is made the owner will have to provide either the key (UUID) or the name of the avatar to add. If the value submitted is valid, the corresponding avatar will be immediately added to the visitors tracker with the designed role.

PLEASE NOTE: when the owner is adding a new avatar as manager is also able to decide if also flag it as whitelisted: in this case, the newly added manager will be excluded from the visitors tracker scan and tracking.

The owner can also delete users – manager and whitelisted – simply by clicking on the “users” button and after selecting the role, click on the “remove” button; this action will load a dialog window containing the list of avatars being part of the group selected (manager or whitelist) and the owner will simply have to click on the one to remove.


Chapter #7: appearance

This submenu groups together all the features useful to change and customise the MD Visitor Tracker’s appearance.

PLEASE NOTE: depending on the version of MD Visitor Trackers, different options will be available inside this menu.

MD Visitors Tracker - appearance submenu
MD Visitors Tracker – appearance submenu
  • Hover Text Color: this button allows the owner to change the hover text colour, picking among several tone options;
  • Visible: this button toggles the MD Visitors Tracker’s visibility. PLEASE NOTE: this feature is available only for:
    • MD Visitors Tracker & Greeter;
    • MD Visitors Tracker & Greeter (Notepad);
  • Text Color: this button – available only for MD Visitors Tracker Board & Greeter – changes the board’s text color;
  • Show Logo: this button – available only for MD Visitors Tracker Board & Greeter – toggles the visibility of the board’s logo area;

Chapter #8: MD Labs Online Services

MD Labs Online Services is a responsive website, accessible from any platform from mobile devices to desktop computers, which allow to interact with the products released by MD Labs. Here’s a quick overview of what the the MD Visitors Tracker owner will be able to do:

  • Get a quick overview of all the trackers, with locations where they are rezzed, total number of visit;
  • View detailed graphs by tracker, date (day/month) , region or by visitor;
  • Rename, delete, merge data from a specific tracker;
  • See the visitors list for any tracker, including visitor name and visit date-time;
  • Archive unused trackers;
  • Delete a specific visit from a tracker;
  • Add and remove managers and whitelisted avatars;

Chapter #8.1: register an account and activate the product

Before accessing the website for the first time, the owner must register an account and activate the service. In order to do so, an Online Services HUD is provided inside the MD Visitors Tracker pack.

Click here for the detailed instructions about how to register and activate your product for MD Labs Online Services.


Chapter #8.2: MD Visitors Tracker homepage

Once logged in the MD Labs Online Services website, it is possible to access the MD Visitors Tracker section from the ‘Products’ drop-down list on the top of the page. The page that will load is the MD Visitors Tracker homepage and will look similar to this one:

MD Visitors Tracker – homepage (click to enlarge)
MD Visitors Tracker – homepage (click to enlarge)

The webpage is divided into 6 different tabs (right under the top bar), each one containing specific features:

  • Account Management: from this tab it is possible to export all the data from all the trackers.
  • Trackers: it’s the main tab, from here is possible to access the data as well as to a list of all rezzed trackers and the arrivals list list of each of them.
  • Visitors: this tab contains the list of all the avatars whom have been registered as visitors; different data-sorting are available, allowing the owner to conduct several types of analysis.
  • Managers: this tab contains the list of all the managers and it is also possible to add or remove users from the manager role.
  • Whitelist: this tab contains the list of all the vhitelisted avatars and it is also possible to add or remove users from the whitelist.
  • Archived: this tab lists all the archived trackers, the ones that are not used and/or not rezzed anymore in-world. Archiving the trackers help keeping data sorted and consistent.

The first element in the homepage is the graph panel: the data represented here will vary based on the current view selected. The default view is “by tracker” and the graph will show a pie chart with the total arrivals registered per tracker.

MD Visitors Tracker – homepage (click to enlarge)
MD Visitors Tracker – homepage (click to enlarge)

The Trackers Explorer panel groups together some useful tools to analyse and manipulate the tracker’s data. The most important tool of this section is the ‘display‘ drop down list which allow to group, sort and view the data in several ways:

  • by tracker: this is the default view, useful to analyse the number of arrivals registered by each tracker;
  • by region: through this view is possible to analyse which regions generate the most traffic;
  • by day: this view is useful to analyse the daily arrivals trend by tracker;
  • by month: this view is useful to analyse the monthly arrivals trend by tracker;

Other useful tools are the ‘bulk actions‘ buttons, which allow the deletion or archiving of multiple trackers at once.


Chapter #8.3: basic info & additional operations

When the data view is set to ‘by tracker‘ some basic information and operations will be accessible, to perform over every tracker listed. These information & operations are:

  • Tracker: the name of each tracker in-world;
  • Region: the region where the corresponding tracker is rezzed in-world;
  • Position: the current X,Y,Z position of the tracker in-world;
  • Total arrivals: the number of total arrivals registered by the corresponding tracker;
  • Status: this switch toggles the tracker’s status in-world;
  • Last Sync: the last time the tracker contacted the MD Labs server to update its status;
  • Additional operations: clicking on the three-dots icon will open a secondary menu containing several additional operations to perform on the corresponding tracker. These operations include delete, rename, merge;
MD Visitors Tracker homepage – Additional operations (click to enlarge)
MD Visitors Tracker homepage – Additional operations (click to enlarge)

These are the additional operation which the owner can perform on each tracker:

  • Rename: rename the corresponding tracker in-world and on MD Labs Online Services;
  • Reset: reset the corresponding tracker in-world;
  • Archive: archive the corresponding tracker, removing it from in-world (if present);
  • Merge: merge the corresponding tracker with another one, associating all the arrivals to the new tracker and removing the old one from in-world and from MD Labs Online Services;
  • Delete all arrivals: delete the tracker’s complete transactions list;
  • Delete: delete the corresponding tracker in-world and from MD Labs Online Services, removing also all the arrivals and settings;

Chapter #8.4: tracker’s details: arrivals

As said in the previous chapters, depending on the data view chosen it will be possible to view and analyse different kind of data; the most important is the data view ‘by tracker‘, which is also the default one. When this data view is selected a list of all trackers rezzed is presented along with the region and total arrivals registered. By clicking on the tracker’s name the details page for that specific item will load.

MD Visitors Tracker – Tracker’s details page (click to enlarge)
MD Visitors Tracker – Tracker’s details page (click to enlarge)

The page is divided into four tabs:

  • arrivals: this tab contains the complete list of the tracker’s registered arrivals;
  • statistics: this tab allows the owner to conduct several analysis over the tracker’s arrivals;
  • managers&whitelist: this tab contains a list of all managers and whitelisted avatars for the selected tracker;
  • settings: this tab holds the tracker’s settings;

The first part of the Arrivals tab presents a handy graph showing the tracker’s daily arrivals trend; below it the ‘tools‘ panels provides some useful instruments to filter, manage and analyse the tracker’s data; it is possible in fact to filter and see only the arrivals registered during a specific period, delete multiple arrivals at the same time and export the arrivals list.

MD Visitors Tracker – Tracker’s details page (click to enlarge)
MD Visitors Tracker – Tracker’s details page (click to enlarge)

The ‘arrivals‘ panel is the main panel of this page and presents a complete list of all the arrivals registered by the tracker; for each of these the following data is displayed:

  • Visitor’s name;
  • Tracker’s name;
  • Tracker’s region;
  • Arrival date-time;
  • Leaving date-time;
  • Visit duration;
  • Delete button: this feature allow the owner to completely remove the corresponding arrival, updating also the tracker’s statistics;

Chapter #8.5: tracker’s details: statistics

When the data view is set to ‘by tracker‘ a second tab is present inside the detail page, name ‘statistics‘; here is possible to start different types of data analysis and study the arrivals and visits trends. The page is composed by three main panels:

  • the first one called ‘stats explorer‘ and allows the owner to define the type of analysis to conduct, picking from the available ones;
  • the second panel displays a graph containing the output of the analysis;
  • the third panel shows a table containing all the data of the analysis;
MD Visitors Tracker – Tracker’s statistics page (click to enlarge)
MD Visitors Tracker – Tracker’s statistics page (click to enlarge)

There are two main type of analysis that can be created: default and custom; the first category group together a serie of pre-defined data interrogation such as last 24 hour, last week, last month; the custom type of analysis on the other hand allows the owner to create daily, weekly and monthly data interrogation based on a custom time-frame.

Despite the type of analysis selected, the result provided will always contain two important indicators:

  • total visits: the total number of visits registered, including returning avatars;
  • unique visitors: the unique number of visitors registered, not counting returning avatars;

Chapter #8.6: tracker’s details: managers&whitelist

The third tab in the visitor tracker’s details page is called ‘Mangers&Whitelist‘ and contains the list of all the avatars whom have been added to the visitors tracker as managers or in whitelist.

MD Visitors Tracker – managers&whitelist (click to enlarge)
MD Visitors Tracker – managers&whitelist (click to enlarge)

The page is divided into two main panels: the first one called ‘Tips’ contains the link to add a new avatar to the tracker’s list, while the second panel contains the list of the users associated to the visitors tracker.


Chapter #8.7: tracker’s details: settings

The fourth and last tab in the tracker’s details page is called ‘Settings‘ and contains a view of the visitors tracker’s setup, including all its settings. From this tab it is possible to change and configure the tracker, toggling features and changing the settings and – once clicking on the “Save Changes” button, applying those settings directly to the device in-world.

MD Visitors Tracker – settings (click to enlarge)
MD Visitors Tracker – settings (click to enlarge)

Chapter #8.8: visitors tab

The ‘Visitors‘ tab is made to help the owner find and manage visitors: the tab includes several tools, features and views allowing the owner to analyse and manipulate the arrivals data.

The tab in divided into three main panels: tips, visitors explorer and visitors list.

MD Visitors Tracker Homepage – Visitors tab (click to enlarge)
MD Visitors Tracker Homepage – Visitors tab (click to enlarge)

The ‘Tips‘ panel contains the feature called ‘Export visitors’: this link let the owner export the visitors list.

The ‘Visitors Explorer‘ is a panel provided two important tools for the owner to analyse and search for specific visitors. The first tool is the ‘view selector’, which provides several default views used to list visitors; these views are:

  • last visitors: this view will list all the avatars registered ranking them by the last visit performed;
  • top visitors of the current month: this view will list all the avatars registered ranking them by the total amount of time spent in the area during the current month;
  • top visitors of the previous month: this view will list all the avatars registered ranking them by the total amount of time spent in the area during the previous month;
  • top visitors: this view will list all the avatars registered ranking them by the total amount of time spent in the area;

The second tool present in the ‘Visitors Explorer’ panel is the search tool, allowing the user to find a specific avatar by searching for its key (UUID), name or part of it.

The last panel – called ‘Visitors list‘ – will list all the visitors sorted depending on the view selected:

MD Visitors Tracker Homepage – Visitors list (click to enlarge)
MD Visitors Tracker Homepage – Visitors list (click to enlarge)

For each avatar reported in list, several information is provided:

  • Visitor name: the name of the visitor. Clicking on the name will load the visitor’s detail page containing all the visits performed;
  • # of visits made: the number of visits registered for the avatar;
  • Total visit duration: the total amount of time spent by the user in the area and registered;
  • Last visit: the last time the user was tracked by any visitors tracker belonging to the owner;

Chapter #8.9: managers tab

The next tab on MD Visitors Tracker homepage is called ‘Managers‘ and allows the owner to add, manage and remove one or more account managers; a manager will be able to access the MD Visitors Tracker homepage just like the owner and interact in several ways with the trackers. Managers will also be able to interact with the assigned trackers in-world, just like the owner.

MD Visitors Tracker Homepage – Managers tab (click to enlarge)
MD Visitors Tracker Homepage – Managers tab (click to enlarge)

This tab is composed my two main panels ‘Tips’ and ‘Managers’; the first one contains a link to add a new manager while the second panel lists all the managers.

In order to add a new manager the owner will have to click on the ‘Add Manager‘ link in the ‘Tips’ panel; a wizard will appear and require a few simple steps:

Managers – Add manager wizard
Managers – Add manager wizard

The first thing is provide the manager’s name or key (UUID); then select a the tracker on which add the avatar as manager; optionally, the owner can decide if automatically whitelist the newly added manager, to avoid this last one to get greetings and being registered as normal visitor. Once these info are provided, clicking on the ‘Add’ button will add the selected avatar as manager on the tracker selected. The manager will be immediately listed in the ‘Managers ‘ panel which can be found into the ‘Managers’ tab.

Managers tab – Managers panel
Managers tab – Managers panel

The ‘Managers’ panel – located into the Managers tab – contains the following data:

  • Manager Name: the name of the manager;
  • Lookup managed trackers (magnifier icon): clicking on this icon will load a floating window, presenting a list of all the trackers on which the corresponding avatar is assigned as manager;
  • Send HUD (paper plane icon): this button delivers a new copy of MD Visitors Tracker registration HUD to the corresponding manager. More info further down on this page;
  • Delete Manager (trash bin icon): this button removes completely the manager from the managers list, forbidding the deleted manager to access the tracker’s page and interact with the trackers in-world;

Is important to spend a few more words on the registration HUD for MD Labs Online Services. In order to login and access the tracker webpage, the managers must be registered to MD Labs Online Services; if the user selected as manager already uses MD Visitors Tracker then an account is already registered and the users will be able to use the same credentials to login to the store to manage. Conversely, if the user selected as manager doesn’t use MD Visitors Tracker then the creation of an account is required and a registration HUD will be automatically sent to the user once added as manager. It is also possible to repeat the HUD dispatch in another moment through the corresponding option in the managers list.

Once added as manager, the user will be able to switch between stores through the “Account” drop down present into the ‘MD Visitors Tracker website‘; from here the drop down will present a list of all accounts owned and managed by the user, and a click on them will start the switch process to the selected one.

Visitors Tracker – switch store toggle
Visitors Tracker – switch store toggle

Chapter #8.10: whitelist tab

 The ‘Whitelist‘ tab allows the owner to add, manage and remove one or more avatar from the whitelist; a whitelisted avatar cannot interact with the tracker in-world nor access the MD Visitors Tracker website, but it will be ignored from the tracker scan engine, and therefore will not receive any greeting message, inventory offer and its presence will not be notified to the owner nor registered.

This tab is composed my two main panels ‘Tips’ and ‘Whitelist’; the first one contains a link to add a new avatar in whitelist while the second panel lists all the whitelisted avatars. In order to add a new avatar in whitelist the owner will have to click on the ‘Add Whitelist‘ link in the ‘Tips’ panel; a wizard will appear and the owner will have to provide the name or key (UUID) of the avatar to add and select a the tracker on which add the avatar will be added. Clicking on the ‘Add’ button will add the selected avatar in the whitelist of the selected tracker. The avatar will be immediately listed in the ‘Whitelist‘ panel.

MD Visitors Tracker Homepage – Whitelist tab (click to enlarge)
MD Visitors Tracker Homepage – Whitelist tab (click to enlarge)

The ‘Whitelist’ panel – located into the Whitelist tab – contains the following data:

  • Name: the name of the avatar;
  • Lookup trackers (magnifier icon): clicking on this icon will load a floating window, presenting a list of all the trackers on which the corresponding avatar is present in whitelist;
  • Delete avatar (trash bin icon): this button removes completely the avatar from the whitelist;

Chapter #8.11: archived tab

The last tab which composes the MD Visitors Tracker homepage is called ‘Archived‘ and groups together all the trackers which are not rezzed anymore and which have been archived by the owner. The archive feature has been designed to help owners to keep their data consistent while reducing the amount of information displayed; by archiving a tracker– in fact – it will be removed from in-world and from the ‘Trackers’ tab on MD Labs Online Services, but all the device’s data such as total visits and the complete arrivals list is kept.

This action brings several benefits to the store owner:

  • There will be less machines displayed into the ‘Trackers’ tab, making it easier to find the device desired;
  • Since all the tracker’s data is kept there will still be statistics about the archived trackers;

The main panel present in this tab is called ‘Archived Trackers’ and lists all the trackers which have been archived by the owner.

MD Visitors Tracker homepage – Archived tab (click to enlarge)
MD Visitors Tracker homepage – Archived tab (click to enlarge)

The data showed for each tracker is very similar to the one present in the ‘Trackers’ tab, except the additional operations which are accessible clicking on the 3-dot icon. The first operation is called ‘Restore’ and it allows the owner to restore an archived tracker, moving it from the ‘Archived’ tab to the ‘Trackers’ one; while this action moves the device’s data from one tab to another on MD Labs Online Services website, it will not restore the tracker in-world if it has been already deleted. The second option, ‘Delete’, removes completely the device’s data; once done all the statistics will be lost including the arrivals lists.


2021 MD Labs

MD Credits Reward Terminal User Manual

Summary:


Chapter #1: Overview & Setup

MD Credits Reward Terminal Script is a tool designed for stores, a solution that offers an easy and flexible way for store owners to reward their customers gifting them store credits; this product is completely integrated with MD Vendor System, the vendor solution released by MD Labs.

! IMPORTANT: All other vendors systems are not compatible with this product, therefore the following instructions does not apply.

! IMPORTANT: The following user manual presents and explains the usage and detailed features of:

  • MD Credits Reward Terminal Script version 1.1.0

MD Credits Reward Terminal pack is composed by three different items:

  • MD Credits Reward Terminal Script: is the script needed to setup a credits reward terminal;
  • MD Credits Reward Terminal: an empty mesh terminal (1 LI) provided by MD Labs, that can be used to setup a credit reward terminal;
  • MD Credits Reward Terminal (tabletop): an empty mesh terminal (1 LI) provided by MD Labs, that can be used to setup a credit reward terminal;

Whether the owner wants to setup a reward terminal using the provided mesh terminal or a third-party one, the few steps required are exactly the same.

PLEASE NOTE: MD Credits Reward Terminal Script is designed to work with MD Vendor System but it is not a plugin. This means the script has to be installed in a separate prim, being a different device. Do not drop the MD Credits Reward Terminal Script inside vendors running MD Vendor System.

As first step, the MD Credits Reward Terminal Script must be dropped inside the object used as terminal; if this is the first setup for that specific device (and not a simple reset), it’s highly recommended to rename the terminal with it’s final name in order to avoid having multiple devices with the same name, which could lead to malfunctions. Also, it is important to remember to avoid setup a new device starting from a copy of an existing one created via drag&copy.

Once the owner has dropped the MD Credits Reward Terminal Script a simple click will make the ‘Owner Menu’ appear: this specific dialog – accessible by the owner and store partner only – contains all the terminal’s settings and features.

MD Credits Reward Terminal – Owner Menu
MD Credits Reward Terminal – Owner Menu
  • Active: this button toggles the reward terminal’s status. When active the users can click on it and request for a credits reward; when not active, the terminal is not operable by customers.
  • Reward Setup: this buttons leads to a sub-menu where the owner can setup the reward policies, such as how often reward and how many credits give out to requesting users.
  • Update: this button starts the update module, which will look online for a new update of the product and – if found – deliver it to the owner.
  • Reset: this button will reset the redelivery terminal, wiping all the data and settings.

Chapter #2: Setup a reward policy

In order to be able to activate the credits reward terminal and start giving out credits rewards, the owner must setup a reward policy: this can be done from the owner menu, clicking on the ‘Reward Setup’ button.

MD Credits Reward Terminal – Reward Setup Menu
MD Credits Reward Terminal – Reward Setup Menu
  • Amount: set the amount of store credits that will be given as reward to each user requesting;
  • Period: defines the period recurrence for the users to request the reward;
  • Group Only: toggle the requirement for user to wear a specific group’s tag in order to be able to request the reward;

When the owner hits the ‘Period’ button another menu opens, presenting all the available options:

  • Once: the reward is given just once to every user requesting it
  • Daily: the reward is given every day (from 00:00 SLT to 23:59 SLT) to users requesting it;
  • Weekly: the owner is asked to choose the first day of the week when to start to give rewards. The reward is given every 7 days from the chosen start day to users requesting it;
  • Bi-weekly: the reward is given every two weeks on the 1st and 15th day of the month to every user requesting it;
  • Monthly: the owner is asked to choose the first day since when the reward is given. The reward is given every month starting from the chosen day to every user requesting it;
MD Credits Reward Terminal – Period selection Menu
MD Credits Reward Terminal – Period selection Menu

! IMPORTANT: each reward terminal has its own ‘period counter’; this means that if multiple terminals are rezzed and setup with the same period recurrence, users will be able to request and receive credits reward from each of them.

The owner is able to setup and interact with each reward terminal also through the MD Labs Online Services website, being able also to check the list of rewards given by each terminal. More detail about the web managing of reward terminals can be found in the dedicated chapter.

Once the reward request is accepted, the store credits are immediately added to the user’s balance and ready to be used.


Chapter #3: Multiple type of rewards & multiple terminals

MD Credits Reward Terminal is extremely flexible and is designed to achieve two specific scenario which are very different but equally important:

  • Different terminals applying different type of rewards;
  • Different terminals applying the same reward;

! IMPORTANT: MD Credits Reward Terminal allows the owner to manage both scenario by simply using the terminal’s name as grouping rule: different terminals having the same identical name will be considered as one.

The owner can take advantage of this rule to setup different rewards type in the store by simply naming the reward terminals differently, depending on the reward given. The owner can – for example – rez and setup a credit reward terminal called “Reward Monthly” to give a monthly reward to group members only and a second terminal called “Reward Once” giving a different reward to all users but just once, whether they are or not members of the store group.

A second scenario where the name grouping rule is useful is when the store owner need to have multiple copies of the same credit reward terminal, maybe located in different locations; this behaviour can be easily achieved by simply setting up several copies of the same terminal with the same reward policy and naming all the terminal the same. This allows – for example – to have a reward terminal located at the mainstore and a second one – applying the same reward – located at an event, making sure that the customers getting the reward at the mainstore cannot receive the same type of reward if they use the terminal at the event location.


Chapter #4: Expiring store credits

MD Credits Reward Terminal allows the owner to access another very useful feature: store credits with expiring date. This special type of store credits are given with an assigned expire date and can be used by customers only before the given date.

! IMPORTANT: the expiring store credit feature comes with some limitations:

  • Expiring store credits can be given as reward only when the terminal is set to “Once” as reward rule;
  • Expiring store credits will stop working always at 23:59:59 SLT of the given expiration day;
  • Expiration date must be provided in year-month-day (YYY-MM-DD) format, i.e. ‘2020-11-18’;

The steps to setup a terminal with expiring credits reward are very simple: the owner will have to click the terminal and start the reward policy setup as usual and when prompted to choose the reward period select “Once”; at this point a second dialog window will open asking the owner to pick the type of credits between expiring or unlimited. Selecting the “Set Expiration” button will prompt the owner to a final dialog where the expiration day will have to be submitted in the year-month-day format.

MD Credits Reward Terminal – Expiring store credits setup
MD Credits Reward Terminal – Expiring store credits setup

Once a customer receives an expiring store credits reward the corresponding amount is added to a special ‘expiring’ balance, which is kept separate from the ‘not-expiring’ credits balance; a customer can also request and receive several expiring rewards with different expiration from the same store, MD Vendor System is able to manage multiple expiration credits and use them in the smartest way.

When a customer goes through the purchase process on any vendor and chooses to pay using store credits the system will automatically retrieve the list of all the expiring credits; the system will first try to pay the product using the credits which are closer to the expiration and adding – one by one – other expiring credits to fully cover the product’s cost. If the total of expiring credits are not enough to cover the product’s cost entirely, the system will automatically look for ‘normal/not expiring’ store credits in the customer’s balance and – if present – use them adding the difference to cover the product’s cost. If again, the total of expiring store credits and normal store credits aren’t enough to cover the product’s cost, the customer will have to pay the remaining amount using L$. This process is all automatic and managed by the system, neither the store owner nor the customers will have to take any additional action.


2020 MD Labs ©

MD Redelivery Terminal & Product Server User Manual

Summary:


Chapter #1: Overview & setup

MD Redelivery Terminal & Product Server is a tool designed for stores, a 2-in-1 solution that offers both redelivery terminal and product server features; this product is completely integrated with MD Vendor System, the vendor solution released by MD Labs.

! IMPORTANT: All other vendors systems are not compatible with this product, therefore the following instructions does not apply.

! IMPORTANT: The following user manual presents and explains the usage and detailed features of:

  • MD Redelivery Terminal & Product Server Script version 3.1.0
  • MD Redelivery Terminal / Mass Redelivery Plugin version 3.1.0
  • MD Redelivery HUD Script version 1.0.0

The user manual for version 3.0.x, compatible with MD Vendor System 4.0.x can be found here.

MD Redelivery Terminal & Product Server Script is composed by two scripts:

  • MD Redelivery Terminal & Product Server Script: it is the main script, offering both redelivery and product server features. This script must always be present inside the device.
  • MD Redelivery Terminal / Mass Redelivery Plugin: is an optional plugin that enables the mass redelivery feature (more details in the corresponding chapter).
  • MD Redelivery HUD Script: this script – coming with transfer & copy permissions – allows the owners to create redelivery HUDs to send to their users; these will be able to quickly access their redelivery page using the HUD and requesting redeliveries.

Whether the owner wants to setup a redelivery terminal or a product server, the few steps required are exactly the same.

PLEASE NOTE: MD Redelivery Terminal & Product Server Script is designed to work with MD Vendor System but it is not a plugin. This means the script has to be installed in a separate prim, being a different device. Do not drop the MD Redelivery Terminal & Product Server Script inside vendors running MD Vendor System.

As first step, the MD Redelivery Terminal & Product Server Script must be dropped inside the object/prim used as terminal/server; if this is the first setup for that specific device (and not a simple reset), it’s highly recommended to rename the terminal or server with it’s final name in order to avoid having multiple devices with the same name, which could lead to malfunctions. Also, it is important to remember to avoid setup a new device starting from a copy of an existing one created via drag&copy.

Once the owner has dropped the MD Redelivery Terminal & Product Server Script along with one or more products, a simple click will make the ‘Owner Menu’ appear: this specific dialog – accessible by the owner and store partner only – contains all the terminal’s settings and features.

MD Redelivery Terminal & Product Server – Owner Menu
MD Redelivery Terminal & Product Server – Owner Menu

Here’s an overview of the main features present in this menu, some of them will be explained more in detail in the corresponding chapters:

PLEASE NOTE: some features listed below are utilisable only when using the terminal as redelivery terminal.

  • Active: when this option is enabled, the redelivery terminal is active and users can click on it to access their redelivery page.
  • Hover text: using this toggle, the owner is able to set a hover text on the terminal. This feature is particularly useful if there are several terminals holding different types of products; setting a describing hover text will allow the owner to find the right server very quickly.
  • List Products: this button will list all the products stored inside the redelivery terminal.
  • Mass Redelivery: clicking on this button will start the ‘Mass Redelivery’ wizard, allowing the user to redeliver a specific product to everyone whom purchased it. (redelivery terminal only feature).
  • Manual Redelivery: this feature will let the owner redeliver a specific product contained inside the redelivery terminal to a specific avatar. (redelivery terminal only feature).
  • Update: this button starts the update module, which will look online for a new update of the product and – if found – deliver it to the owner.
  • Reset: this button will reset the redelivery terminal, wiping all the data and settings.

Chapter #2: Redelivery Terminal vs Product Server

As mentioned in the previous chapters, MD Redelivery Terminal & Product Server Script is a 2-in-1 solution which offers both redelivery terminal and product server features; this means the same script can be used to setup either a redelivery terminal or product server and in general, a device running MD Redelivery Terminal & Product Server Script can works as both at the same time. Since a single device can work as both redelivery terminal and product server at the same time, the difference between the two is more ‘logical’ then ‘physical’.

In general a redelivery terminal is a device hosting one or more items in its content and serving customers redeliveries for product they have already purchased. A redelivery terminal can then have two roles:

  • server: is the terminal itself, hosting the items and delivering the products upon customer’s request.
  • client: is an empty device – not containing any item – that works as satellite terminal. Customers can click on it and request a redelivery just as with any other terminal, but the client relies on a redelivery server for the product delivery.

product server is a device that holds one or more items inside its content and have one or more vendors connected to it as clients, relying on the product server to deliver the products that are purchased. Differently from the redelivery terminal, the product server can only have the server role.

Redelivery TerminalProduct Server
main purposeoffer redelivery to customers, send out product updates via mass redeliverydeliver products purchased through client (satellite) vendors
possible rolesserver and clientserver only
max # of items hosted per device250250
max # of devices manageable999999
devices connectableredelivery terminal as clientvendor as client
redelivery terminal vs product server

Chapter #3: Products naming, constraints & limitations

Along with the script, the owner will have to drop inside the terminal all the products used to offer redelivery and/or sold via the vendors, if setting up a product server.

! IMPORTANT: Keep in mind that MD Redelivery Terminal & Product Server can work either as redelivery terminal or product server, or even as both at the same time.

Whether for a redelivery terminal, a product server, or both, the products inside the terminal has to comply some specific rules:

  • Products must be objects.
  • Each product must be only one item. (If your products are composed by several items, this means you will have to box them into one single pack)
  • To offer redelivery for products sold in-world, the troduct’s name must match EXACTLY the one inside the in-world vendor.
  • To offer redelivery for products sold from SL Marketplace, the product’s name must match EXACTLY the item’s name on the SL Marketplace page.

The following picture is an example of a correct product’s name matching between in-world vendor, MP listing and redelivery terminal/product server:

Product's name matching (Click to enlarge)
Product’s name matching (Click to enlarge)

As shown in the picture above, for this specific example the product called ‘MD Gacha Machine Script’ is present inside the in-world vendor, marketplace listing and redelivery terminal with the same name; thanks to this matching it is possible to offer redeliver for both products purchased in-world and from the SL Marketplace.

! IMPORTANT: when writing the product’s info on the SL Marketplace page, the item’s name reported in the item’s title field may vary depending on the language selected (English, Japanese, German, French, Portuguese, Spanish): it is very important to always make sure the item’s name reported in the item’s title field corresponds to the one desired in all the languages.


Chapter #3.1: constraints & limitations

When setting up a  redelivery terminal or a product server there are some constraints and limitation to take in account:

  • For redelivery terminal, the item’s name must match exactly between the ones sold inside the vendor and the ones inside the redelivery terminal;
  • To offer redeliver also for products sold through SL Marketplace:
    • the item’s name in the SL Marketplace page must match exactly with the ones inside the redelivery terminal;
    • SL Marketplace sales must be integrated with the MD Labs Online Services website. Detailed instructions here.
  • Each redelivery terminal or product server can contain up to 250 items and more cannot be added. However there is no limit on how many terminals to use: if a redelivery request involves a product that cannot be found on the terminal #1, the request is automatically forwarded to the terminal #2, and so on until the product is found or there are no more terminals to query;

Chapter #4: setup a server

This chapter is meant to explain the basic steps to setup a simple redelivery terminal or product server in its most basic configuration: a single terminal working as server. The setup procedure consists in just a few and easy steps:

  1. Rez the object to use as terminal and make sure to have mod permissions for it;
  2. Drop the MD Redelivery Terminal & Product Server Script inside the rezzed terminal object;
  3. A “not active” hover text will appear over the device. At this time is a best practice to rename the terminal with an unique name;
  4. Drop one or more item product that users will be able to have redelivered inside the terminal’s content, keeping in mind the following criteria:
    • the name matching is very important for the redelivery to work;
    • the product must be an object;
    • if the owner does not have transfer permission on an item it will be ignored and users won’t be able to obtain it;
    • if the owner does not have copy permission on an item it will be ignored and users won’t be able to obtain it;Drop one or more item product that users will be able to have redelivered inside the terminal’s content, keeping in mind the following criteria:
  5. Once the items are dropped click on the terminal to access the owner menu, then select “Active” to enable the device;
  6. The redelivery terminal or product server is now setup and working correctly;

Once a device is setup correctly and enabled – if working as redelivery terminal – customers touching it will be taken to a webpage with their purchases made at the store: this page – hosted as part of MD Labs Online Services – is personal for each user and contains all the items purchased by the current user – or received as gift. Depending on the specific setup, the list of purchases will contain both products sold from in-world vendors and SL Marketplace, or just one of the two. The customer will have to click the ‘Redeliver’ button of the selected product to immediately receive a redelivery.


Chapter #5: Redelivery Terminal – Client vs Server

! IMPORTANT: the Client role is a specific feature applicable to redelivery terminals only.

While standard redelivery terminals (server) holds in their content all the product that will be redelivered, a terminal set as client will not contain any item, but will instead connect to another terminal set as server to retrieve the requested product and redeliver it.

This behavior is better explained in the picture below:

Server redelivery terminal vs Client redelivery terminal
Server redelivery terminal vs Client redelivery terminal

When a terminal works as server, it will behave as shown in the upper side of the picture: each redelivery request (1) from users is made directly on the redelivery terminal which is set as server, holding all the products in its content. If the request is accepted, the redelivery server will directly send the requested product to the avatar (2).

On the contrary, when a terminal works as client, each redelivery request from users is made on the redelivery client (1) and immediately forwarded from this last one to the server (1). If the request is accepted, the redelivery server will directly send the requested product to the avatar (2). This behavior is shown in the lower side of the picture above.

The redelivery terminal client doesn’t store any product in its content, but rely on the server for it.

! IMPORTANT: to set a terminal as client it is just necessary to drop the MD Redelivery Terminal & Product Server Script inside the terminal’s content and nothing else. The terminal will automatically set itself in client mode and work as already described.

Client terminals become extremely useful when the owner wants to offer a redelivery point at satellite stores or at events: in this case it will be necessary only to setup a redelivery terminal without placing any product inside, saving time and avoiding to have several copies of the same products inside each terminal.

Another important point to consider which favours client terminals is related to the fact that they are region-independent; this means that no matter where in the grid the client terminals are located, they will always be able to contact the redelivery server and process the request. Again, this feature becomes very useful in case of satellite stores or redelivery point at temporary events, where multiple redelivery clients – one per each satellite store and/or event –  will connect to the redelivery server which will be the only one holding the products in its content. This setup will reduce the efforts needed by the owner to maintain a product list up-to-date, since these products will be stored only in one terminal and not mirrored into every terminal.


Chapter #6: Redelivery Terminal – Auto linking between terminals

As explained in the previous chapters, each terminal can store up to 250 items in its content; those items are the product that can be redelivered upon request. This limit is imposed by a Second Life constrain and cannot be changed. Even tho the maximum number of 250 products can be considered elevated, it is often not enough for a medium-big store, which has to manage even thousands of different products. MD Redelivery Terminal & Product Server Script solves this problem by allowing the redelivery terminal to link each other virtually, as if they were only one large terminal.

! IMPORTANT: The linking between a terminal and another is made when the new one is rezzed and it is completely automatic and invisible to the owner.

Since there is no limit on how many redelivery terminal a store can use, this solution allows the owner to manage a virtually unlimited number of products. When a customer request a redelivery for a specific product the request is sent to the first redelivery terminal but, if the requested item cannot be found in the terminal’s content, the request is then forwarded from the first terminal to the second, and so on until the product is found or there are no more terminals to query.

All this process is automatic and invisible both to the owner and the user, working independently if the initial request is made directly to a server terminal or a client one.

Redelivery request on multiple servers
Redelivery request on multiple servers

PLEASE NOTE: the same auto linking technology is used for product servers.


Chapter #7: Redelivery Terminal – Mass Redelivery

! IMPORTANT: the Mass Redelivery is a specific feature applicable to redelivery terminals only.

This particular feature has been created to simplify and automate the redelivery of products; with Mass Redelivery, the owner can automatically redeliver a specific product to all avatars whom purchased it. Depending by the particular setup, the redelivery list can include both in-world and MP purchases or one of the two. The Mass Redelivery becomes really useful for distributing product updates, where a new version of a specific product has to be sent to all users who purchased it.

In order to enable this feature the owner will have to drop a second script inside the redelivery terminal; this script – called MD Redelivery Terminal Script / Mass Redelivery – is included inside the MD Redelivery Terminal & Product Server Script pack.

The mass redelivery of a product can be defined in two different ways:

  • Using the redelivery terminal/product server in-world (as explained in the next lines);
  • Using the MD Labs Online Services website, in the “Mass Redelivery Tab”;

This chapter will focus on how to perform a mass redelivery from in-world; the process made using the MD Labs Online Services website is explained in the dedicated page.

After dropping this second script, clicking on the corresponding “Mass Redelivery” button will start a wizard composed by 4 different steps:

Step 1 – product selection: in this first step, owner will be prompted to a list of all products sold through in-world vendors and/or MP and will be asked to choose the product to redeliver; an useful ‘Search‘ button is present to simplify this step and make it faster.

Mass Redelivery – Step 1 – Product selection
Mass Redelivery – Step 1 – Product selection

Step 2 – object selection: once chosen the product to mass redeliver, an object (if present) matching the name of the product is picked automatically from the terminal’s content and selected as object to redeliver. However, in order to allow even more flexibility, the owner is asked if proceeding with the object selected automatically (‘Continue‘) or choose another object picking it from inside the terminal’s content (‘Change‘).

Mass Redelivery – Step 2 – Object selection
Mass Redelivery – Step 2 – Object selection

Step 3 – custom message: in this third step – optional – the owner is asked to submit a custom message that every customer will receive along with the product redelivery.

Step 4 – confirm: this last step consist in a recap of the chosen settings – product, object and custom message – in order to start with the mass redelivery process.

Mass Redelivery – Step 4 – Confirmation
Mass Redelivery – Step 4 – Confirmation

Once the owner confirms all the settings, the mass redelivery starts and one by one, every customer whom purchased the selected product is offered a new copy of the chosen object, along with the (optional) custom message.

PLEASE NOTE: this procedure could take up to several minutes depending by the number of customers to redeliver the products to.

! IMPORTANT: Second Life has a limit on how many object can be sent during a certain amount of time; this limit is set to around 2000 items every 30 minutes and if reached, the Mass Redelivery process will be automatically paused for around 35 minutes before resuming again. During this phase the redelivery terminal will show the status in the hover text; the owner doesn’t have to do anything, as the process will be resumed automatically.


Chapter #8: Redelivery Terminal – Manual Redelivery

! IMPORTANT: the Manual Redelivery is a specific feature applicable to redelivery terminals only.

This feature is very similar to the Mass Redelivery, except that is applied to a specific avatar, instead of to all avatars whom purchased a selected product; similarly to the Mass Redelivery, it can be performed either from the in-world terminal or from the MD Labs Online Services website under the “Terminals & Servers” tab.

This chapter will focus on how to perform a mass redelivery from in-world; the process made using the MD Labs Online Services website is explained in the dedicated page.

Once clicked the corresponding button in the menu, the owner will be asked to follow a simple wizard to submit all the requested parameters:

Step 1 – avatar selection: owner will be first asked to provide the name or the key (UUID) of the avatar whom will receive the redelivered product.

Step 2 – product selection: in this step, owner will be prompted to a list of all products inside the terminal and will be asked to choose the product to redeliver.

Step 3 – custom message: in this third step – optional – the owner is asked to submit a custom message that the customer will receive along with the product redelivery.

Step 4 – confirm: this last step consist in a recap of the setting chosen – product and custom message – in order to start with the manual redelivery process.

Once the owner confirms all the settings, the redelivery starts and the selected product will be sent to the desired avatar, along with the custom message (if provided).


Chapter #9: Product server

A product server is a particular device holding one or more product in its content and having one or more client vendor connected to it, relying on it for the product’s delivery.

MD Redelivery Terminal & Product Server Script is able to work as redelivery terminal and product server, as well as product server only. The client vendors connected to the product server need to run the latest version of MD Vendor System as well as the Remote Control Plugin.

A product server – like the redelivery terminal – is subject to some limitations:

  • each product server can contain up to 250 items. However there is no limit on how many servers to use: if a product delivery request involves a product that cannot be found on the server #1, the request is automatically forwarded to the server #2, and so on until the product is found or there are no more servers to query;
  • each client vendor connected to a product server can retrieve only one item among all the products inside the product server’s content;

! IMPORTANT: a terminal running the MD Redelivery Terminal & Product Server Script can be both a redelivery terminal and a product server at the same time.

The setup of a product server is identical as the one required for a redelivery terminal: both script and products have to be dropped inside the object used as server. The connection of the client to the product server has to be done from the client vendor through the remote control plugin, as explained here. Once connected, the client vendor will be associated to one item chosen among the ones present inside the server’s content and every time a purchase is made from the client vendor the server is contacted to deliver the product to the receiver avatar.

Below are reported some real user case as example:

Terminal set as Product Server only
Terminal set as Product Server only

The schema displayed above describes a typical situation where the terminal is set to work as product server only. The user purchases the product through the vendor, which sends a deliver request to the product server – which could be located on a different region. The product server, finally, receives the request and delivers the product to the user.

Terminal set as Product Server & Redelivery Terminal
Terminal set as Product Server & Redelivery Terminal

The schema displayed above describes the double nature of the MD Redelivery Terminal & Product Server, able to work as redelivery point and product server at the same time:

  • User A purchases a product through the vendor and the deliver request is forwarded to the terminal, which will deliver the product. The terminal acted as a product server in this case.
  • User B requests a redeliver for a product already purchased: the request is forwarded to the terminal which will deliver the product. The terminal acted as a redelivery terminal in this case.

PLEASE NOTE: in the example above the redelivery terminal and product server are the same device, just serving different purposes.


Chapter #10: Redelivery HUD

MD Redelivery Terminal & Product Server Script pack contains one last script called MD Redelivery HUD Script. This script – coming with transfer & copy permissions – allows the owners to create redelivery HUDs for their stores, that can be sent to users; these will just have to wear the HUD and click on it to quickly access their redelivery page and request product redeliveries.

The setup required is really minimum and can be summarized in two steps:

  1. The owner should change the MD Redelivery HUD Script’s next owner permissions to copy-only;
  2. The owner should drop the MD Redelivery HUD Script inside the HUD’s content;
MD Redelivery HUD setup - permissions change
MD Redelivery HUD setup – permissions change

Once the script’s permissions are correctly changed and the script is dropped inside the HUD, the setup is complete and the HUD can be sent out to users whom – upon wearing it – will be able to access their redelivery page.


2020 MD Labs ©

MD Vendor System Plugin – Poses User Manual

Summary:


Chapter #1: Overview & setup

! IMPORTANT: The following user manual presents and explains the usage and detailed features of:

  • MD Vendor System Plugin – Poses version 2.1.0

The user manual for version 2.0.x, compatible with MD Vendor System 4.0.x can be found here.

Poses plugin add the following features to MD Vendor System:

  • Turn any compatible pose display into a pose vendor;
  • Allow users to scroll through all the poses and preview them before purchasing;
  • Pose adjustment system for the pose vendor;

MD Vendor System Plugin – Poses is composed by two main components:

  • MD Vendor System Plugin – Poses: it is the plugin script that has to be installed into the vendors along with MD Vendor System ‘core’ Script;
  • MD Pose Stand (Full Perm): is a pose stand – provided with full permissions – compatible with MD Vendor System – Plugin script, and already full functional;

Installing the plugin is very easy and quick: the owner will only have to drop the plugin script inside the vendor and it will be automatically detected and initialized; a message sent on chat will notify the owner of the successful installation. From that moment, the plugin’s specific features will be available through the “Plugin” sub menu present in the vendor’s owner menu.

Owner Menu – Plugin sub menu
Owner Menu – Plugin sub menu

By clicking on the corresponding ‘Poses’ button, the plugin’s specific menu will load, presenting all the available options:

Poses Plugin – Menu
Poses Plugin – Menu
  • Hover Text: this toggle lets the owner enable or disable the hover text above the pose vendor, showing the current pose name;
  • Sell Boxed: this toggle lets the owner decide whether sell the pose directly (as animation) or boxed, as object. More details on this feature in the dedicated chapter;
  • Scroll Dialog: this toggle lets the owner enable or disable an additional dialog window for users that allow them to scroll through poses, other than using the pose stand’s arrows;
  • Pose Timeout: this setting is aimed to avoid ‘camping’ of avatars on the pose vendors. Once the timeout is reached, the sitting avatar – if present – will be automatically unsit from the pose stand vendor, releasing the vendor itself and setting it available for other users to use;
  • Adjust Pose: this button leads to another submenu where is possible to adjust the pose displayed, working on the height and rotation for each axis;
  • Update: this button will search online for plugin’s update and deliver it to the owner, if found.
  • Back: this button navigate back to the main menu.

PLEASE NOTE: the plugin is aimed to expand the vendor’s feature, for this reason MD Vendor System ‘core’ script must always be present inside the vendor to use the plugin.

To uninstall the plugin simply remove it from the vendor’s content and the vendor will automatically update, removing the additional features.


Chapter #2: Setup a third-party pose stand

Although MD Vendor System Plugin – Poses comes with a handy full permission pose stand ready to use, the owner can choose to use a different pose stand from the one included; the poses plugin is in fact compatible with virtually any pose stand, as long as they are compliant to a few rules.

A compatible pose stand must satisfy the following criteria in order to be used with MD Vendor System Plugin – Poses:

  • Be a linkset of at least 3 prims with mod permission;
  • Have a child prim in the linkset called ‘prev‘ (lowercase, no quotes)
  • Have a child prim in the linkset called ‘next‘ (lowercase, no quotes)

Following these simple rules it will be possible to turn any pose stand in a pose vendor that will work with MD Vendor System Plugin – Poses.

The mod permission is required in order to be able to drop the poses to sell, while the ‘prev’ and ‘next’ prims are required in order to be able to use the scroll feature.

Pose stand – prim naming
Pose stand – prim naming

Chapter #3: Loading the pose stand

Whether using the full perm pose stand included or a third party one, the loading process consist in drop one or many poses inside the pose vendor’s inventory; the poses must be valid Second Life animations and must have at least transfer permission for the owner. A message in the local chat will inform the owner about how many poses are loaded and also give warnings in case of errors.

Once the pose stand vendor is loaded and set for sale, any user sitting on it will automatically start playing the current animation in-world; through the ‘prev’ and ‘next’ buttons it will be possible to scroll through the poses available. With simple right right-click and ‘Pay’ the current pose stand’s user will be able to purchase the pose displayed; a left click on the pose stand will open the usual MD Vendor System user menu, allowing the customer more options such as gift or use store credits.

PLEASE NOTE: by default – and if the ‘Sell Boxed’ option is disabled – the pose vendor will deliver ONLY a copy of the current pose played, ignoring any other item such has landmarks, notecards and so on.


Chapter #4: Selling boxed poses

As stated in the previous chapter, by default a pose vendor running MD Vendor System and the pose plugin will deliver only the pose currently played in case of purchase; while this can be very quick and handy when setting up a pose vendor, there is often the need to deliver more than one item during a purchase, such has the store landmark, a notecard and so on. For this reason MD Vendor System Plugin – Poses includes an option called ‘Sell Boxed’ which can be toggled from the plugin’s menu; this option, when enabled, allows the pose vendor to deliver a boxed object corresponding which corresponds to the pose currently played.

Each pose (animation) present in the pose vendor is automatically mapped with an object which represent the boxed version of the pose; this matching between animation and object is made automatically through the pose’s name: the boxed pose – in order to be detected and associated – must have the pose’s name followed by the word ‘BOXED‘ written in capital.

As example, the boxed version of a pose called ‘Bar Dance‘ will be named ‘Bar Dance BOXED‘. When a customer pay the vendor for purchasing a pose, the corresponding boxed version name is generated and – if found in the pose vendor’s inventory – delivered to the recipient avatar.

This is an example of how a pose stand’s inventory would look like when selling boxed poses:

Poses Plugin - Boxed poses
Poses Plugin – Boxed poses

PLEASE NOTE: If for any reason the boxed version of a pose is not found inside the vendor’s inventory, then the pose itself will be delivered.


2020 MD Labs ©

MD Vendor System Plugin – Store Credit & Gift Card User Manual

Summary:


Chapter #1: Overview & Setup

! IMPORTANT: The following user manual presents and explains the usage and detailed features of:

  • MD Vendor System Plugin – Store Credit & Gift Card version 2.1.0

The user manual for version 2.0.x, compatible with MD Vendor System 4.0.x can be found here.

Store Credit & Gift Card plugin add the following features to MD Vendor System:

  • Toggle store credit as payment method on the vendors;
  • Toggle gift cards as payment method on the vendors;
  • Create store’s gift card to sell and use with the dedicated MD Gift Card Script;
  • Create promo codes, with specific discount % and validity rules, to be used as payment method on the vendors;
  • Assign a reward in store credits for each purchase, with different percentages among group members and non-group members;
  • Toggle the possibility to use store credits or gift card credits to purchase gifts;

Installing the plugin is very easy and quick: the owner will only have to drop the plugin script inside the vendor and it will be automatically detected and initialized; a message sent on chat will notify the owner of the successful installation. From that moment, the plugin’s specific features will be available through the “Plugin” sub menu present in the vendor’s owner menu.

Owner Menu – Plugin sub menu
Owner Menu – Plugin sub menu

By clicking on the corresponding ‘Credits’ button, the plugin’s specific menu will load, presenting all the available options:

Store Credit & Gift Card Plugin – Menu
Store Credit & Gift Card Plugin – Menu
  • Store Credit: opens the store credit sub-menu where the owner can toggle the store credits as payment method for the selected vendor and select a percentage of the purchase that will be converted in store credits. More details about this feature in the corresponding chapter.
  • Gift Card: activates/deactivates gift card payment method for the selected vendor. More details about this feature in the corresponding chapter.
  • Promo Code: activates/deactivates the promo code payment method for the selected vendor. More details about this feature in the corresponding chapter.
  • Gift w/ Credit: toggle the ability to use store credits or gift card credits as payment method for gifts;
  • Update: this button will search online for plugin’s update and deliver it to the owner, if found.
  • Back: this button navigate back to the main menu.

PLEASE NOTE: the plugin is aimed to expand the vendor’s feature, for this reason MD Vendor System ‘core’ script must always be present inside the vendor to use the plugin.

To uninstall the plugin simply remove it from the vendor’s content and the vendor will automatically update, removing the additional features.


Chapter #2: Store Credit

Store credits are virtual coins offered by the store owner to customers that can be used to buy other products from the same store; the users earn store credits by purchasing products at the store using L$ on enabled vendors.

MD Vendor System allows two different levels of store credits:

  • store credits as reward for group members;
  • store credits as reward for non-group members;

The owner can decide if enable both levels or just one and – for each level – set a specific percentage of the product’s cost that will be converted in store credits.

Clicking on the ‘Store Credit’ button in the plugin menu will open the Store Credits sub-menu:

Store Credit sub-menu
Store Credit sub-menu

There are two main options:

  • Group: with this toggle the owner can enable the store credits for group members, defining the percentage of the product’s cost that will be transformed into store credits;
  • Non-Group: with this toggle the owner can enable the store credits for non-group members, defining the percentage of the product’s cost that will be transformed into store credits;

PLEASE NOTE: when enabling the store credits for group members, the group the vendor is set to will be used. If the group is wrong, the owner should right click on the vendor, select ‘Edit’ from the drop down menu and change the group which is into the ‘General’ tab.

! IMPORTANT: by default, 1 store credit = 1 L$.

Once the store credit feature is enable, for every purchase paid (entirely or partially) with L$, an amount of store credits are added to the user’s balance; the number of store credit to add is calculated as the submitted conversion percentage of the item’s price paid using L$. For example, if the cost of the purchased item is 300L$ and the store credit percentage is 10%, 30 store credits will be added to the user’s balance.

The store credits are added immediately after the purchase and the users are able to check their current balance anytime, by clicking on the ‘View Balance‘ button in the vendor’s users menu.

User Menu – Store credit as payment method
User Menu – Store credit as payment method

MD Vendor System supports also ‘mixed’ payments: a mixed payment (in this case) is made partially by store credits and partially by L$. This scenario can occur if the user selects store credits as payment option but doesn’t have enough credits to purchase the item. In this specific case, MD Vendor System will prompt the user a window asking if abort the purchase process or complete it using L$ to pay the remaining cost of the item.

User Menu – Mixed Payment with store credits
User Menu – Mixed Payment with store credits

If the user decides to complete the purchase using the L$ for the remaining amount, the vendor will set itself in ‘pay mode’, waiting for the payment; once it’s correctly performed, the product will be delivered and the purchase correctly finalized. In this case, the payment method for this transaction on MD Labs Online Services will be “Store Credit & L$“.

! IMPORTANT: in case of mixed payment with store credits and L$, the amount of store credits to add to the user’s balance is calculated ONLY on the part paid using the L$ balance.


Chapter #3: Gift Card

As for store credit, gift card payment option can be activated by the owner clicking on the corresponding toggle ‘Gift Card‘ in the plugin’s menu. No particular setup is required to activate this feature.

Store Credit & Gift Card Plugin – Menu
Store Credit & Gift Card Plugin – Menu

! IMPORTANT: by default, 1 gift card credit = 1 L$.

Once the requested value is submitted, the gift card feature will be immediately activated, adding the payment option in the user’s menu; users are able to check their current balance anytime, by clicking on the ‘View Balance‘ button in the vendor’s users menu.

User Menu – Gift Card as payment method
User Menu – Gift Card as payment method

As for store credit, MD Vendor System supports ‘mixed’ payments also or gift cards: if the user selects gift card as payment option but doesn’t have enough credits to purchase the item, MD Vendor System will prompt the user a window asking if abort the purchase process or complete it using L$ to pay the remaining cost of the item.

If the user decides to complete the purchase using the L$ for the remaining amount, the vendor will set itself in ‘pay mode’, waiting for the payment; once it’s correctly performed, the product will be delivered and the purchase correctly finalized. In this case, the payment method for this transaction on MD Labs Online Services will be “Gift Card & L$“.

! IMPORTANT: in case of mixed payment with gift card and L$ (if the store credit feature is active) the amount of store credits to add to the user’s balance is calculated ONLY on the part paid using the L$ balance.

Inside the Store Credit & Gift Card Plugin pack there is also another pack included: MD Gift Card Creator Kit: it contains the script & tools required to create the gift cards that will be sold and used by customers.

! IMPORTANT: the only gift cards compatible with MD Vendor System are the ones using MD Gift Card Script, other gift cards using different systems will NOT work!

In the next chapter is described how to setup a gift card step by step, using MD Gift Card Creator Kit.


Chapter #3.1: setup a third-party Gift Card

The MD Gift Card Creator Kit contains the script & tools to required to create gift cards to use along with MD Vendor System. This pack is provided with Store Credit & Gift Card Plugin and comes boxed:

MD Gift Card Creator Kit – Boxed
MD Gift Card Creator Kit – Boxed

Once unpacked, the content of the creator kit will look like this:

MD Gift Card Creator Kit – Content
MD Gift Card Creator Kit – Content

The two important item on this creator kit are:

  • MD Gift Card Script: this is the script required by any gift card to work. It comes with copy&transf permissions and can be dropped either on a prim or inside a HUD.
  • MD Gift Card Template HUD (Full Perm): this HUD comes with full permissions and represents a template HUD for creating MD Gift Cards.

PLEASE NOTE: this chapter will explain the step-to-step guide for creating generic gift cards using ONLY the MD Gift Card Script. This means the gift cards created can be either object to rez/attach or third-party HUD; if you want to read how to create gift cards using the template HUD included, please refer to the next chapter.

The setup of a generic gift card is simple and quick and can be divided into three main steps:

  1. Change MD Gift Card Script’s next owner permissions;
  2. Drop MD Gift Card Script inside an object that will work as gift card;
  3. Configure MD Gift Card Script’s amount and additional features;

As first step (step 1), a change on the next owner’s permissions is required: as mentioned before, MD Gift Card Script comes with copy&transf permissions, but in order to be used, the next owner’s permissions MUST be set to transfer only. This because a single gift card will be transfer only, so a user can gift and pass it to another, but not take a copy of it.

MD Gift Card Script – Change of next owner’s permissions
MD Gift Card Script – Change of next owner’s permissions

Once done with this first step, the owner must rez the object that will be used as gift card on the ground and drop the MD Gift Card Script inside the object’s content (step 2); if the script is dropped with the wrong permissions will automatically delete itself and another copy (with the right permissions) will have to be dropped. Once the script is inside the object and rezzed on the ground, this step is complete.

! IMPORTANT: the object/gift card’s name cannot end with a number; this is due to security reasons and every gift card which name ends with a number will be automatically invalidated by the system. This means gift cards named “Gift Card 500” are considered invalid.

Clicking on the object/gift card rezzed on the ground a configuration menu will be presented to the owner, containing several options:

MD Gift Card Script – Gift card configuration
MD Gift Card Script – Gift card configuration
  • Set amount: this button will ask the owner to submit the gift card’s amount in L$. This is the only value required during this configuration step.
  • Reserve: this feature allows the owner to reserve the gift card to a specific avatar, whom will be the only one able to use it and redeem the gift card. Once clicked the ‘Reserve’ toggle, owner will be asked to provide the avatar key (uuid) or name; once the reserve feature is enabled, clicking on the ‘Reserve’ button again will toggle it off.
  • Expire: this feature allows the owner to set an expiration date for the gift card, after which the gift card will not be usable and automatically invalidated by the system. Once clicked on the ‘Expire’ button, the owner is asked to provide the expire date in YYYY-MM-DD format (i.e. 2020-06-24); the gift card will automatically expire at 23:59:59 SLT of the defined day.
  • Max Usage: this feature allows the owner to set a maximum number of times a gift card’s type can be used by the same avatar. The gift card type is defined by the combination of the card’s name and amount. This means, for example, that a gift card called ‘Gift Card 500L’ with amount of 500 L$ is considered a ‘type’ of gift card and all the copies of the same card will have the same type.

By clicking ‘set amount’ and providing a valid number greater than 0, the gift card’s value will be set to that corresponding amount in L$ (step 3). At this point the gift card’s setup is complete and the object can be picked up in inventory, ready to be sold. Clicking ‘set amount’ again, the owner can change the gift card’s amount any time before selling it.

! IMPORTANT: after setting or changing the gift card’s amount, the owner MUST NOT change the object/prims’s description, as some relevant information are stored that – if changed – could lead to the gift card break.

Customers purchasing the gift card will be able to either wear or rez the gift card on the ground to get a menu where they will be asked if ‘use’ the gift card, adding the amount to their balance and making the gift card unusable. As additional feature, an animation or pose can be dropped inside the gift card along with the MD Gift Card Script: this animation will be played automatically every time the user will wear the gift card.

MD Gift Card – User menu
MD Gift Card – User menu

The gift card is now ready to be sold.

TIP: MD Vendor System can be easily used also to sell gift cards, handling them as ‘normal’ items (1 per vendor). This way owner will have a complete track of the income made by gift cards, integrated with MD Labs Online Services as well.


Chapter #3.2: Setup a gift card with MD Gift Card Template HUD

This chapter explain how to create a gift card HUD (Heads-up displays) using the template included inside the MD Gift Card Creator Kit.

Once unpacked, the content of the creator kit will look like this:

MD Gift Card Creator Kit – Content
MD Gift Card Creator Kit – Content

The object called ‘MD Gift Card Template HUD (Full Perm)’ is the HUD itself that will be used to create the gift cards. This HUD comes empty and with full permissions so to be highly customizable: it will only require the MD Gift Card Script to work.

The setup of the MD Gift Card Template HUD can be divided into few main steps:

  1. Rez the MD Gift Card Template HUD (Full Perm) on the ground;
  2. Change the MD Gift Card Template HUD (Full Perm) next owner permissions to transfer-only;
  3. Change the MD Gift Card Script next owner permissions to transfer-only;
  4. Drop the  MD Gift Card Script inside the MD Gift Card Template HUD (Full Perm);
  5. Click on the MD Gift Card Template HUD (Full Perm) to setup the gift card;
  6. Customize the MD Gift Card Template HUD (Full Perm) with personal texture and logo;
  7. Take the MD Gift Card Template HUD (Full Perm) in inventory and rename it.

(1) As first step, the MD Gift Card Template HUD (Full Perm) has to be rezzed on the ground; once done it will look like this:

MD Gift Card Template HUD (Full Perm)
MD Gift Card Template HUD (Full Perm)

(2) Once rezzed, the first thing to do is change the gift card template next owner permissions to transfer-only:

MD Gift Card Template HUD (Full Perm) – change of next owner’s permissions
MD Gift Card Template HUD (Full Perm) – change of next owner’s permissions

(3) The MD Gift Card Script – included inside the MD Gift Card Creator Kit – needs to have its next owner permissions changed to transfer-only as well:

MD Gift Card Script – Change of next owner’s permissions
MD Gift Card Script – Change of next owner’s permissions

(4) Once both MD Gift Card Template HUD (Full Perm) and MD Gift Card Script next owner permissions are set to transfer-only, the MD Gift Card Script has to be dropped inside the MD Gift Card Template HUD (Full Perm). At this point, the MD Gift Card Script will perform a permissions check over itself and on the HUD; if wrong permissions are found, the script will print a warning message on the local chat before deleting itself.

(5) As both MD Gift Card Template HUD (Full Perm) and MD Gift Card Script next owner permissions are set up correctly, it will be possible to setup the gift card’s amount and additional options through the configuration menu:

MD Gift Card Script – Gift card configuration
MD Gift Card Script – Gift card configuration
  • Set amount: this button will ask the owner to submit the gift card’s amount in L$. This is the only value required during this configuration step.
  • Reserve: this feature allows the owner to reserve the gift card to a specific avatar, whom will be the only one able to use it and redeem the gift card. Once clicked the ‘Reserve’ toggle, owner will be asked to provide the avatar key (uuid) or name; once the reserve feature is enabled, clicking on the ‘Reserve’ button again will toggle it off.
  • Expire: this feature allows the owner to set an expiration date for the gift card, after which the gift card will not be usable and automatically invalidated by the system. Once clicked on the ‘Expire’ button, the owner is asked to provide the expire date in YYYY-MM-DD format (i.e. 2020-06-24); the gift card will automatically expire at 23:59:59 SLT of the defined day.
  • Max Usage: this feature allows the owner to set a maximum number of times a gift card’s type can be used by the same avatar. The gift card type is defined by the combination of the card’s name and amount. This means, for example, that a gift card called ‘Gift Card 500L’ with amount of 500 L$ is considered a ‘type’ of gift card and all the copies of the same card will have the same type.
  • Customize: this button will lead to another sub-menu aimed to customize the gift card’s appearance by changing the card’s amount text color and the font;

! IMPORTANT: the gift card setup has to be done with the MD Gift Card Template HUD (Full Perm) rezzed on the ground and not attached. Moreover, after setting or changing the gift card’s amount, the owner MUST NOT change the HUD’s description, as some relevant information are stored that – if changed – could lead to the gift card break.

(6) It’s now possible to customize the MD Gift Card Template HUD (Full Perm)’s appearance by dropping a texture for the background and for the store logo.

Customers purchasing the gift card will be able to wear the HUD and be able to ‘use‘ the gift card, adding the amount to their balance and making the gift card unusable. As additional feature, an animation or pose can be dropped inside the gift card along with the MD Gift Card Script: this animation will be played automatically every time the user will wear the gift card.

TIP: MD Vendor System can be easily used also to sell gift cards, handling them as ‘normal’ items (1 per vendor). This way owner will have a complete track of the income made by gift cards, integrated with MD Labs Online Services as well.


Chapter #4: use a gift card

These few lines will explain you how to use a gift card, received as gift or bought.

As first thing wear the gift card by double clicking on it from the inventory, or right clicking and select ‘Add‘: a menu will appear, like the one reported below:

MD Gift Card – User Menu
MD Gift Card – User Menu

In the dialog it is reported gift card’s amount in L$ and there is only one possible option:

  • Use Card: this button will start the gift card’s utilization process, which will add the gift card’s amount to your balance.

By clicking on ‘Use Card‘, a second dialog will open asking for confirmation:

MD Gift Card – Use card confirmation
MD Gift Card – Use card confirmation

By clicking on ‘Yes‘, the gift card’s amount will be added to your current balance and the gift card will not be valid anymore; you can now detach the gift card and delete it.

You can now use your credit simply by clicking on a vendor which supports gift card credit as payment, selecting if buy or gift the product and using ‘Gift Card‘ as payment method. The product’s cost will be subtracted from your gift card’s credit balance. You can check your balance anytime by clicking on a vendor which supports gift card credit as payment and selecting ‘View Balance‘.


Chapter #7: promo codes

A promo code is a special code which is associated to a discount, whether in a percentage or a specific amount in L$. MD Vendor System – Store Credit & Gift Card Plugin allow the owner to create as many promo codes as wanted, each one associated to a specific discount, that can be distributed and utilized during the purchase process. When purchasing from a vendor having the promo code feature enabled, in fact, the user will be asked to submit a promo code which – if valid – will apply the specific discount on the current transaction.

When creating a promo code, there are some basic settings to setup:

  • The promo code MUST be 3 to 8 characters long;
  • The promo code MUST contain only alphanumeric characters (a-z, A-Z, 0-9);
  • The promo code MUST be associated to a discount:
    • Using a percentage (%), between 1 and 99;
    • Using a fixed amount (L$);
  • The promo code’s utilization MUST be associated to one of the following:
    • Everyone: everyone having the promo code can use it and benefit of the discount;
    • Group members: only members of a specific group are able to use the promo code and benefit of the discount;
    • Specific avatar: only one defined avatar is able to use the promo code and benefit of the discount;

Along with these basic settings there are also several optional ones, aimed to customize even more the promo code. Those settings aren’t mandatory for the promo code to be created and used, but can enrich the whole experience.

  • Promo code utilization limit: define how many times a single avatar can use a specific promo code;
  • Promo code validity period: a validity start time and end time (in SLT) defining a period when the promo code is accepted by the vendors;
  • Promo code vendor: associate the promo code to a specific vendor, which will be the only one accepting the code;
  • Promo code region: similar to the previous one, associate the promo code to a specific region. Only the vendors in the region will accept the code;

Promo Codes are managed through the MD Labs Online Services website, inside the MD Vendor System product page. A tab called ‘Promo Codes‘ is present, containing a list of all the codes with all the features and the button to create a new one.

IMPORTANT: The promo code subject is widely explained in the corresponding chapter on MD Vendor System User Manual, so refer there for any further detail and explanation about how to create and manage promo codes.

After creating one or more promo codes through MD Labs Online Services website to allow users to use them is necessary to enable the corresponding option on vendors through the Store Credit & Gift Card Plugin, clicking on the corresponding ‘Promo Code‘ toggle inside the plugin’s menu.

Store Credit & Gift Card Plugin – Menu
Store Credit & Gift Card Plugin – Menu

When the customers click a vendor having the promo code feature enable, a ‘Promo Code‘ button will appear among the payment methods; by clicking they will be asked to submit the promo code and – if the code is valid and compliant to all the restrictions – the associated discount will be applied to the product’s cost.

User Menu – Promo Code as payment method
User Menu – Promo Code as payment method

2020 MD Labs ©

MD Vendor System Plugin – Remote Contorl User Manual

Summary:


Chapter #1: overview & setup

! IMPORTANT: The following user manual presents and explains the usage and detailed features of:

  • MD Vendor System Plugin – Remote Control version 2.1.0

The user manual for version 2.0.x, compatible with MD Vendor System 4.0.x can be found here.

Remote Control plugin add some very interesting features to MD Vendor System:

  • Connect the vendor as client (satellite) to another one (server) which will hold the product in its content;
  • Connect the vendor as client (satellite) to a product server which will hold the product in its content;

Installing the plugin is very easy and quick: the owner will only have to drop the plugin script inside the vendor and it will be automatically detected and initialized; a message sent on chat will notify the owner of the successful installation. From that moment, the plugin’s specific features will be available through the “Plugin” sub menu present in the vendor’s owner menu.

Owner Menu - Plugin sub menu
Owner Menu – Plugin sub menu

Once the plugin is successfully installed on the vendor the owner can access the plugin’s specific settings using the “Plugins” sub menu that can be found in the owner menu. By clicking on the corresponding ‘Remote Ctrl’ button, the plugin’s specific menu will load, presenting all the available options:

Remote Control – Plugin menu
Remote Control – Plugin menu
  • Client: this buttons is a switch to enable/disable the client mode; by turning it on and performing the connection wizard, the vendor will become a ‘client’ connected to another vendor or product server which will act as ‘server’, hosting the products in its content. More details about this feature in the corresponding chapter.
  • Update: this button will search online for plugin’s update and deliver it to the owner, if found.
  • Back: this button navigate back to the main menu.

PLEASE NOTE: the plugin is aimed to expand the vendor’s feature, for this reason MD Vendor System ‘core’ script must always be present inside the vendor to use the plugin.

To uninstall the plugin simply remove it from the vendor’s content and the vendor will automatically update, removing the additional features.


Chapter #2: Setup a client vendor

Client mode is a vendor’s particular working mode where the vendor does not holds the products to sell in its content but connects to another vendor or terminal (‘server’) to retrieve the products. The advantages of this setup are obvious: keeping only one copy of your products inside the ‘server’ vendor will reduce the confusion of multiple copies and simplify the maintenance of your products, while also reducing the time required to setup your vendors; moreover, the same ‘server’ vendor can be connected to multiple ‘clients’.

PLEASE NOTE: Whilst the benefits of using client (satellite) vendors are obvious there is also one major downside: client-server communication require more connections and several ‘handshaking’ steps between the client and the server; the success of a purchase and product delivery depends by both client and server status – typically rezzed in different regions.

For reference:

  • client vendor or satellite vendor is an empty vendor, connected to a server; upon purchase, the client requests the server the product’s delivery.
  • server vendor or terminal is a device hosting one or more products and having one or more vendors connected to it as client; the server receives a product delivery request from the client and dispatches the item to the recipient avatar.

As client, a vendor can be connected to two different type of server:

  • Vendor as Server: the client is connected to another vendor running MD Vendor System (‘core’) script and the Remote Control Plugin.
  • Terminal as Server: the client is connected to terminal acting as product server and running MD Redelivery Terminal & Product Server Script.

TIP: often using a product server instead of a normal vendor as server is better because a device running the MD Redelivery Terminal & Product Server Script can be used for both redelivery terminal and product server, keeping all the products stored in one place and offering both redelivery and product delivery at the same time.

To setup a vendor in client mode, the owner will have to click on the corresponding ‘Client‘ button inside the remote control plugin’s menu, this will start the connection wizard; the procedure to connect a vendor to a server vendor or a server terminal is identical, only targeting a different set of devices. The first step of the setup is picking the type of server to connect to among vendor or terminal.

Client connection – Step 1 – Server type selection
Client connection – Step 1 – Server type selection

Once the owner has selected the type of device to connect to will be asked to pick a specific vendor or terminal to use as server (step two), depending on the type of device selected in the previous step; in the following example, the owner picked ‘Vendor’ as type of server so a list of all available vendors is shown:

Client connection – Step 2 – Vendor Server selection
Client connection – Step 2 – Vendor Server selection

Once the server has been chosen it is necessary to pick one item inside the server which will be sold through the client (step three):

Client connection – Step 3 – Product selection
Client connection – Step 3 – Product selection

! IMPORTANT: any client – independently by the type of server which is connected to – will be able to manage only one normal item and/or one fatpack item from the server’s content; demo and multiple items will not be considered.

If no errors occur during the connecting between client and server the owner is taken to the last step of the connection process (step four), where is asked to confirm the connection. In this last dialog there is a summary of the client’s connection parameters:

  • server name;
  • server region;
  • server item to deliver;

There is one more feature on this step that can become very useful during the first setup of a client vendor; the owner can in fact decide if replicate the server’s settings on the newly connect client: the settings include price, discount, group mode and any other option. This feature is very useful because it speeds up the setup of clone vendors in specific situations. As example it can be considered the case of a vendor rezzed at a SL event which has to be set up as client and connected to a server vendor which is on the owner’s mainstore; if the client vendor will have to have the same price as the one already working at the mainstore and also the same options it will only be necessary to click on ‘Apply’ on the client’s connection confirmation dialog during the first setup and all the server’s settings will be immediately applied to the client.

Client connection – Step 4 – Connection confirm
Client connection – Step 4 – Connection confirm

PLEASE NOTE: the server’s settings replication on client is available only when connecting a client to a vendor as server, and not when connecting a client to a product server.

Once this last step is done, the connection is complete and a message will be displayed in the local chat; from that moment the vendor will use the item inside the server’s content as products to sell. 

As users will buy or gift a product from the client vendor, the connected server will be contacted and will deliver the product purchased to the desired recipient. The workflow is described in the schema below:

Purchase process on a client vendor
Purchase process on a client vendor

On MD Labs Online Services website, a column called ‘Role’ in the ‘Sales’ tab displays, for every vendor, if it is configured as client or server.

MD Vendor System homepage – Vendor’s role
MD Vendor System homepage – Vendor’s role

When a vendor is set as client, the remote control plugin’s menu will present one additional button:

  • Ping Server: this button will trigger a connection test to check if the vendor server is up and reachable. An message is sent to the owner, with the result of the test.
Remote Control menu – Ping Server
Remote Control menu – Ping Server

To disable the client mode from a vendor click the ‘Client’ button: the vendor will be disconnected from the server and will start acting like a ‘normal’ vendor.

To better improve the user experience, an effective delivery method has been implemented: as the user purchases the product the transaction is stored, but the item is flagged as ‘delivered’ only once the server successfully receives the deliver request and the product is sent to the receiver. With this method, if some communication issue arises during the connection to the server or during the product’s delivery, the transaction is stored anyway – giving the user the chance to use the redelivery feature – but will stay flagged as ‘not delivered’; the owner is able to check the delivery status of every transaction on the detail page of the corresponding vendor.


Chapter #2.1: tips to speed up the setup

MD Vendor System Plugin – Remote Control includes a few built-in features aimed to speed up the setup of satellite vendors, whether they are connected to another vendor or a product server; these features are:

  • auto-match;
  • product suffix;

Auto-match‘ is automatically used when the owner is trying to connect a vendor as a client: MD Vendor System Plugin – Remote Control will automatically try to match the client’s vendor name with the server’s info, in order to provide a faster setup. The auto-match is done over:

  • the vendor’s name, if the server is a vendor;
  • the product’s name, if the server is a product server;

As for example it can be considered a vendor named “Vendor Test” which has to be connected as client:

  • When performing a connection to another vendor (server), the plugin will automatically search for a vendor called “Vendor Test”; if found the client is immediately connected, otherwise a list of all eligible server vendors is provided;
  • When performing a connection to product server, the plugin will automatically search for an item called “Vendor Test” inside the selected product server; if found the vendor is immediately connected, otherwise a list of all available products is provided;

‘Product Postfix’ (or suffix) is another feature aimed to speed up the client vendor setup; the purpose of this feature is to ‘help’ the auto-match when connecting a client vendor to a product server and the client’s vendor name differs from the server’s product name by a constant string applied as suffix.

As for example it can be considered a vendor named “Vendor Test” which has to be connected as client to a product server in order to deliver the product “Vendor Test (wear to unpack)”. Since the client name – “Vendor Test” – and the product name inside the server – “Vendor Test (wear to unpack)” – are different, the auto-match feature would not be able to automatically understand the relation between the two; here is where the product suffix comes in to help: setting the product suffix to ” (wear to unpack)”, the client will use the vendor’s name, add the suffix and create the final product name to search for. The auto-match feature will do the rest and search for an item called “Vendor Test (wear to unpack)” inside the selected product server; if found the vendor is immediately connected, otherwise a list of all available products is provided;

The owner can set the product suffix from the MD Labs Online Services website under the ‘Advanced Settings’ area which can be found into the ‘Store Management’ tab.

PLEASE NOTE: the product suffix is a store-wide setting and once selected and applied it will be always used the same suffix to speed up the setup of all vendors connecting to a product server.


2020 MD Labs ©