MD Smart Unpacker User Manual

by Mattia Delwood | Jun 9, 2021 | User Manuals

Summary:

• Chapter #1: Initial setup
• Chapter #2: Owner menu
• Chapter #3: Item’s type & categories
• Chapter #4: Item’s permissions
• Chapter #5: Selective unpacking
  • Chapter #5.1: Setup a “wear-to-unpack” HUD
  • Chapter #5.2: Brands, models & default keywords
• Chapter #6: Link buttons for a “wear-to-unpack” HUD
• Chapter #7: Setup a single-prim box
• Chapter #8: MD Labs Online Services
  • Chapter #8.1: register an account and activate the product

Initial notes

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

• MD Smart Unpacker Script version 1.0.0

Chapter #1: initial setup

The first setup of MD Smart Unpacker Script is very quick and includes only one required step: changing permissions for next owner. MD Smart Unpacker Script comes with copy&transfer permissions for it to be used in product’s packaging, but the script has to be set as copy-only for next owner in order for the setup to be completed.

For doing so the owner will have to right-click on the MD Smart Unpacker Script directly from the inventory folder and select “Properties” from the drop-down menu; at this point, simply unchecking the “Transfer” box in the “Next Owner” section will update the script’s permissions correctly.

At this point the MD Smart Unpacker Script is ready to be drop inside the desired HUD or box; this step can be accomplished very quickly by simple dragging and dropping the script from the inventory to the designed object which will work as HUD or box.

PLEASE NOTE: just like for the script, also the object used as HUD or pack cannot have transfer permission set for the next owner; if so, the MD Smart Unpacker Script will notify the owner about the permission error and delete itself.

Chapter #2: owner menu

Once the MD Smart Unpacker Script has been set with the right permissions and dropped into the object which will function as HUD or box, the owner can click on it and the “Owner Menu” will load. This particular menu – accessible only by the script owner – contains all the settings and options needed to customise the product.

This menu presents several buttons, some of them leading into other sub menus:

• Check perms: this button will start the permission check module of the script, which will report the owner for possible item’s permission mistakes. More info about this feature can be found in the corresponding chapter.
• Check types: this button will start the type check module of the script, which will assign a specific category to every item and report to the owner the results for a final validation. More info about this feature can be found in the corresponding chapter.
• Links: this buttons leads the owner to a second menu, where it is possible to setup different types of links which the final user will be able to click and use, such as the major social media, SL Marketplace link, in-world store SLURL, and in-world group link for joining. PLEASE NOTE: to take advantage of this feature, a compatible HUD must be used, more info in the corresponding chapter.
• Unpack: this button will unpack the content of the object in the owner’s inventory, as if the owner was a final user. This feature is useful to test the unpack before releasing the product.
• 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 script.

Chapter #3: item’s type and categories

Part of MD Smart Unpacker Script’s smartness is the ability to automatically detect, categorise and manage different types of Second Life items which are present inside the HUD or box along with the script itself.

When scanning the HUD or box’s inventory, MD Smart Unpacker Script is able to detect and process the following Second Life’s items type:

• Object;
• Clothing;
• Bodypart;
• Notecard;
• Landmark;
• Texture;

Every item detected is analysed by the MD Smart Unpacker Script and automatically assigned to a specific category, which will be used by the script to create the inventory map for the unpacking process.

Each Second Life’s item scanned is associated by MD Smart Unpacker Script to one of these categories:

• Product:
• HUD:
• Notecard:
• Landmark:
• Advertisement (AD):

To better comprehend this very important mechanism the table below lists the relations between Second Life’s items type and how they are mapped by the script into categories:

As shown in the table – for example – every texture item dropped inside the HUD or box will be considered as an AD by the MD Smart Unpacker Script; in the same way every landmark or notecard will be categorised as landmark and notecard by the script. A different (and very important) rule is applied for objects: MD Smart Unpacker Script will consider all Second Life object items found in inventory as “product”, unless they contain the keyword “HUD” (in capital, without quotes) in their name; in this case the script will map the specific object item as a HUD and not as a “product”.

But why is this cataloguing process so important? Because every time an unpack request is performed by the user, MD Smart Unpacker Script will automatically go through its inventory map and create a folder containing:

• All the items present in the “Product” category (and matching the unpacking rule, but this will be explained in the next chapters);
• All the items present in the “HUD” category (and matching the unpacking rule, but this will be explained in the next chapters);
• All the items present in the “notecard” category;
• All the items present in the “landmark” category;
• All the items present in the “AD” category;

The folder created is then delivered to the user performing the unpack, as result of the unpack process.

Chapter #4: item’s permissions

Another important feature implemented in MD Smart Unpacker Script is the ability to check for item’s permission and warn the owner in case possible permission mistakes are identified. This process is applied in two different levels:

• owner-level: the script scans the object’s inventory where it was dropped and, while assigning every item to its corresponding category, will also perform a check on owner’s permissions over every single item found.
• next-owner-level: this specific feature – started when the owner click on the “Check Perm” button in the menu – will perform a check on the next owner’s permissions on every single item which has been scanned and assigned to a specific category.

When MD Smart Unpacker Script is performing the owner-level controls two conditions MUST be met in order for the script to consider the item as part of the inventory map and assign it to its specific category:

• item must have transfer permissions for the owner;
• item must have next-owner permissions set;

If any of the above conditions is not met then MD Smart Unpacker Script will warn the owner with a message in local chat and ignore the item, not including it in the inventory map and therefore not allowing it to be unpacked.

When performing the next-owner-level permissions control, each item being part of the inventory map is evaluated and its permissions are compared with the expected ones inherited from its category; in case of permission mismatch the owner is notified with a message in local chat and invited to review the specific item’s permission; in this case the item will however be kept in the inventory map.

MD Smart Unpacker Script will apply by default the following permission on every type of item’s category:

Chapter #5: selective unpacking

The biggest feature of MD Smart Unpacker Script is the ability to let the final user perform a selective unpacking of a specific product, receiving in inventory only what is really wanted. This feature becomes very handy when applied to stores operating in the virtual fashion business: now days there are several different body types available in the market and fashion creators are asked to release body-specific versions of their product. This easily ends up in creators including more and more versions of their product in each package and consequently when final users unpack their purchased product they receive unwanted body-specific versions, cluttering their inventory and making it harder for them to go through the package and find the right items.

Selective unpacking is achieved by MD Smart Unpacker Script combining together several features such as the item’s category logic explained in the previous chapters, brands & models managing and keyword-based tagging.

PLEASE NOTE: selective unpacking features are available only when MD Smart Unpacker Script in used inside a HUD and not a simple product box.

Chapter #5.1: setup a “wear-to-unpack” HUD

In order to explain and understand how MD Smart Unpacker Script’s selective unpacking feature works, the best way is using an everyday-case example: a store owner needing to pack its latest release and prepare it for selling.

The release will have the following characteristics:

• Once sold, the product will be delivered to the final user as HUD with the “wear-to-unpack” formula;
• The product comes in several variants, each one for a specific body type;
• The pack contains one or more HUD, allowing the final user to customise the product purchased;
• The pack also contains other type of items, such as instruction notecard(s), a store landmark, product advertisement images;

Below is shown an example of HUD allowing selective unpacking:

The example HUD shown above is composed by a main (root) prim and several linked prims – working as buttons – corresponding at each available body type; each prim button is named with a specific keyword or tag which corresponds to a specific body type.

The content of the example HUD as shown above will look like this:

As shown, the HUD contains different items:

• Product: the final product where each object corresponds to a specific body type;
• HUD: the customisation HUD, one per each body brand;
• Notecard: instruction notecard;
• Landmark: store landmark;
• Texture: product advertisement;

IMPORTANT: The “core” part of MD Smart Unpacker Script’s selective unpacking is the relation between HUD’s buttons and HUD’s content and how keywords are used to create a bound between the button of the HUD and the correct item to be unpacked.

Starting from the example HUD shown above, when the final user presses the button of a specific body MD Smart Unpacker Script will retrieve the name of the button from the prim’s name (i.e. “(Lara)” – no quotes) and use its inventory map to retrieve a list of products and HUD having the same keyword in their name. So – for example – when the final user requests to unpack the Legacy body, MD Smart Unpacker Script will:

1. retrieve the keyword from the button’s name pressed, in this example “(Legacy)” – without quotes;
2. scan its inventory map using the keyword retrieved and create a temporary folder containing:
   • the product called “My product – (Legacy)” – without quotes;
   • the HUD called “My product HUD” – without quotes;
   • the object called “My product – Add On – (ALL)” – without quotes;
   • the notecard called “My product instructions” – without quotes;
   • the landmark called “My Store Landmark” – without quotes;
   • the advertisement texture called “My product” – without quotes;
3. deliver the created folder with all its content to the requesting avatar;

This way the requesting avatar will receive a folder containing only the product and HUD for the selected body, along with the other (optional) items such as notecard, landmark and advertisement.

PLEASE NOTE: it is important to point out how in both buttons and products name the body type is written enclosed between parenthesis; this is because MD Smart Unpacker Script retrieves the keyword from the HUD’s button name and scans the inventory map collecting every item (product and HUD) having the same keyword in the name. For this reason if the button for the Legacy body was called just “Legacy” – without quotes – MD Smart Unpacker Script would have included both the product called “My product – (Legacy)“ and “My product – (Legacy Perky)“ in the folder to deliver, since both contain the keyword “Legacy” in their names. This would have been a mistake since the final user requested to unpack just the “Legacy” body and not the “Legacy” and “Legacy Perky” versions of the product. Enclosing the product name (and the corresponding HUD button) between round,square or brace parentheses will “isolate” the body type and allow the MD Smart Unpacker Script to select the right items.

Another important thing to notice is the behaviour of the object called “My product – Add On – (ALL)”: this specific item is flagged with the keyword “(ALL)” – without quotes – and for this reason considered as a “jolly” product, which will be always included during any kind of unpack.

One last thing worth to mention is the behaviour of the “ALL” button in the example HUD shown above: for this particular unpacking rule no separate prim is required as button, as MD Smart Unpacker Script will detect every click performed on the HUD root prim and automatically unpack everything.

Chapter #5.2: brands, models & default keywords

MD Smart Unpacker Script is able to identify and correctly manage a wide list of body types through default built-in keywords; each keyword is then linked to a specific brand and model which are used to create ad-hoc statistics about unpacking, such as the ranking of the most unpacked body models or the unpacking trend over months.

Store owner can easily take advantage of this automatic brand&model linking using – for each body type – the specific default keyword reported in the table below:

PLEASE NOTE: as explained in the previous chapter the keywords listed above have to be used both in the HUD’s button (written in the prim’s name) and added in the corresponding product’s name and customising HUD.

While using these default keywords will allow MD Smart Unpacker Script to automatically generate all the available types of statistics, store owners can use their custom keywords without breaking the unpacking features as long as the same custom keyword is used both for the HUD button’s name and is part of the corresponding product’s name.

Chapter #6: link buttons for a “wear-to-unpack” HUD

MD Smart Unpacker Script allows store owners to configure a wide range of links in their product HUD; these links can go from the store landmark to a group join link or the major social networks. In order to setup this feature the owner will have to go through two different steps:

• Enable the desired links from the “Links” sub-menu of the “Owner Menu” by providing the corresponding URLs;
• Add, for each link type, a button in the HUD using a specific keyword as button’s name;

The owner will have to click on each link’s toggle and provide the requested information such as web URL, SLURLS, group UUID, depending on the link it’s being setup.

After enabling the desired links, the store owner will have to name the corresponding HUD prim buttons using the keyword specified in the table below; doing this will complete the setup and once the final user will click a specific link button, MD Smart Unpacker Script will retrieve the button’s name, match the keyword and provide the user the right link or action.

Chapter #7: setup a single-prim box

MD Smart Unpacker Script is designed for a maximum flexibility and it is able to work also when installed in a single-prim box: in this case once the final user wears the box or rezzes it on the ground and touches it the complete content of the package is automatically delivered.

It is important to notice that when using MD Smart Unpacker Script in a simple single-prim box the store owner will lose the benefits of the advanced features such as selective unpacking and all the statistics which come with it.

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 Smart Unpacker Script owner will be able to do:

• Get a quick overview of all the body types unpacked, with total number of unpacks;
• View detailed graphs with unpack trends by model, brand, gender;
• Associate custom-created keywords (tag) to a specific brand & model;
• Analyse the unpacking trends over time;

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 Smart Unpacker pack.

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

2021 MD Labs

MD Visitors Tracker User Manual

by Mattia Delwood | Feb 26, 2021 | User Manuals

Summary:

• Chapter #1: initial setup
• Chapter #2: owner menu
• Chapter #3: basic usage
• Chapter #4: greeter
• Chapter #5: options
  • Chapter #5.1: defining a custom scan area
• Chapter #6: users
• Chapter #7: appearance
• Chapter #8: MD Labs Online Services
  • Chapter #8.1: register an account and activate the product
  • Chapter #8.2: MD Visitors Tracker homepage
  • Chapter #8.3: Basic info & additional operations
  • Chapter #8.4: Tracker’s details: arrivals
  • Chapter #8.5: Tracker’s details: statistics
  • Chapter #8.6: Tracker’s details: managers&whitelist
  • Chapter #8.7: Tracker’s details: settings
  • Chapter #8.8: Visitors tab
  • Chapter #8.9: Managers tab
  • Chapter #8.10: Whitelist tab
  • Chapter #8.11: Archived tab

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;

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.

• 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);

Chapter #5: options

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

• 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.

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.

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;

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;

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.

• 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:

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.

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;

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.

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.

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;

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.

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.

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.

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:

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.

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:

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.

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.

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.

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.

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

by Mattia Delwood | Jun 30, 2020 | User Manuals

Summary:

• Chapter #1: Overview & Setup
• Chapter #2: Setup a reward policy
• Chapter #3: Multiple type of rewards & multiple terminals
• Chapter #4: Expiring store credits

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.

• 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.

• 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;

! 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.

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

by Mattia Delwood | Jun 5, 2020 | User Manuals

Summary:

• Chapter #1: Overview & Setup
• Chapter #2: Redelivery Terminal vs Product Server
• Chapter #3: Products naming, constraints & limitations
  • Chapter #3.1: Constraints & limitations
• Chapter #4: Setup a server
• Chapter #5: Redelivery Terminal – Client vs Server
• Chapter #6: Redelivery Terminal – Auto linking between terminals
• Chapter #7: Redelivery Terminal – Mass Redelivery
• Chapter #8: Redelivery Terminal – Manual Redelivery
• Chapter #9: Product Server
• Chapter #10: Redelivery HUD

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.

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.

A 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.

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:

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:

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.

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.

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‘).

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.

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:

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.

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;

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

by Mattia Delwood | Jun 5, 2020 | User Manuals

Summary:

• Chapter #1: Overview & setup
• Chapter #2: Setup a third-party pose stand
• Chapter #3: Loading the pose stand
• Chapter #4: Selling boxed poses

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.

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

• 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.

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:

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

by Mattia Delwood | Jun 3, 2020 | User Manuals

Summary:

• Chapter #1: Overview & Setup
• Chapter #2: Store Credit
• Chapter #3: Gift Card
  • Chapter #3.1: Setup a third-party Gift Card
  • Chapter #3.2: Setup a gift card with MD Gift Card Template HUD
• Chapter #4: Use a Gift Card
• Chapter #5: Promo Codes

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.

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

• 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:

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.

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.

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.

! 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.

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:

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

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.

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:

• 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.

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:

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:

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

(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:

(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:

• 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:

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:

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.

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.

2020 MD Labs ©