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.
Once the owner has dropped the MD Credits Reward Terminal Script a simple click will make the ‘Owner Menu’ appear: this specific dialog – accessible by the owner and store partner only – contains all the terminal’s settings and features.
MD Credits Reward Terminal – Owner Menu
Active: this button toggles the reward terminal’s status. When active the users can click on it and request for a credits reward; when not active, the terminal is not operable by customers.
Reward Setup: this buttons leads to a sub-menu where the owner can setup the reward policies, such as how often reward and how many credits give out to requesting users.
Update: this button starts the update module, which will look online for a new update of the product and – if found – deliver it to the owner.
Reset: this button will reset the redelivery terminal, wiping all the data and settings.
Chapter #2: Setup a reward policy
In order to be able to activate the credits reward terminal and start giving out credits rewards, the owner must setup a reward policy: this can be done from the owner menu, clicking on the ‘Reward Setup’ button.
MD Credits Reward Terminal – Reward Setup Menu
Amount: set the amount of store credits that will be given as reward to each user requesting;
Period: defines the period recurrence for the users to request the reward;
Group Only: toggle the requirement for user to wear a specific group’s tag in order to be able to request the reward;
When the owner hits the ‘Period’ button another menu opens, presenting all the available options:
Once: the reward is given just once to every user requesting it
Daily: the reward is given every day (from 00:00 SLT to 23:59 SLT) to users requesting it;
Weekly: the owner is asked to choose the first day of the week when to start to give rewards. The reward is given every 7 days from the chosen start day to users requesting it;
Bi-weekly: the reward is given every two weeks on the 1st and 15th day of the month to every user requesting it;
Monthly: the owner is asked to choose the first day since when the reward is given. The reward is given every month starting from the chosen day to every user requesting it;
MD Credits Reward Terminal – Period selection Menu
! IMPORTANT: each reward terminal has its own ‘period counter’; this means that if multiple terminals are rezzed and setup with the same period recurrence, users will be able to request and receive credits reward from each of them.
The owner is able to setup and interact with each reward terminal also through the MD Labs Online Services website, being able also to check the list of rewards given by each terminal. More detail about the web managing of reward terminals can be found in the dedicated chapter.
Once the reward request is accepted, the store credits are immediately added to the user’s balance and ready to be used.
Chapter #3: Multiple type of rewards & multiple terminals
MD Credits Reward Terminal is extremely flexible and is designed to achieve two specific scenario which are very different but equally important:
Different terminals applying different type of rewards;
Different terminals applying the same reward;
! IMPORTANT: MD Credits Reward Terminal allows the owner to manage both scenario by simply using the terminal’s name as grouping rule: different terminals having the same identical name will be considered as one.
The owner can take advantage of this rule to setup different rewards type in the store by simply naming the reward terminals differently, depending on the reward given. The owner can – for example – rez and setup a credit reward terminal called “Reward Monthly” to give a monthly reward to group members only and a second terminal called “Reward Once” giving a different reward to all users but just once, whether they are or not members of the store group.
A second scenario where the name grouping rule is useful is when the store owner need to have multiple copies of the same credit reward terminal, maybe located in different locations; this behaviour can be easily achieved by simply setting up several copies of the same terminal with the same reward policy and naming all the terminal the same. This allows – for example – to have a reward terminal located at the mainstore and a second one – applying the same reward – located at an event, making sure that the customers getting the reward at the mainstore cannot receive the same type of reward if they use the terminal at the event location.
Chapter #4: Expiring store credits
MD Credits Reward Terminal allows the owner to access another very useful feature: store credits with expiring date. This special type of store credits are given with an assigned expire date and can be used by customers only before the given date.
! IMPORTANT: the expiring store credit feature comes with some limitations:
Expiring store credits can be given as reward only when the terminal is set to “Once” as reward rule;
Expiring store credits will stop working always at 23:59:59 SLT of the given expiration day;
Expiration date must be provided in year-month-day (YYY-MM-DD) format, i.e. ‘2020-11-18’;
The steps to setup a terminal with expiring credits reward are very simple: the owner will have to click the terminal and start the reward policy setup as usual and when prompted to choose the reward period select “Once”; at this point a second dialog window will open asking the owner to pick the type of credits between expiring or unlimited. Selecting the “Set Expiration” button will prompt the owner to a final dialog where the expiration day will have to be submitted in the year-month-day format.
MD Credits Reward Terminal – Expiring store credits setup
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.
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.
Once the owner has dropped the MD Redelivery Terminal & Product Server Script along with one or more products, a simple click will make the ‘Owner Menu’ appear: this specific dialog – accessible by the owner and store partner only – contains all the terminal’s settings and features.
MD Redelivery Terminal & Product Server – Owner Menu
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.
Redelivery Terminal
Product Server
main purpose
offer redelivery to customers, send out product updates via mass redelivery
deliver products purchased through client (satellite) vendors
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 matchEXACTLY the one inside the in-world vendor.
To offer redelivery for products sold from SL Marketplace, the product’s name must matchEXACTLY the item’s name on the SL Marketplace page.
The following picture is an example of a correct product’s name matching between in-world vendor, MP listing and redelivery terminal/product server:
Product’s name matching (Click to enlarge)
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:
Rez the object to use as terminal and make sure to have mod permissions for it;
Drop the MD Redelivery Terminal & Product Server Script inside the rezzed terminal object;
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;
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:
Once the items are dropped click on the terminal to access the owner menu, then select “Active” to enable the device;
The redelivery terminal or product server is now setup and working correctly;
Once a device is setup correctly and enabled – if working as redelivery terminal – customers touching it will be taken to a webpage with their purchases made at the store: this page – hosted as part of MD Labs Online Services – is personal for each user and contains all the items purchased by the current user – or received as gift. Depending on the specific setup, the list of purchases will contain both products sold from in-world vendors and SL Marketplace, or just one of the two. The customer will have to click the ‘Redeliver’ button of the selected product to immediately receive a redelivery.
Chapter #5: Redelivery Terminal – Client vs Server
! IMPORTANT: the Client role is a specific feature applicable to redelivery terminals only.
While standard redelivery terminals (server) holds in their content all the product that will be redelivered, a terminal set as client will not contain any item, but will instead connect to another terminal set as server to retrieve the requested product and redeliver it.
This behavior is better explained in the picture below:
Server redelivery terminal vs Client redelivery terminal
When a terminal works as server, it will behave as shown in the upper side of the picture: each redelivery request (1) from users is made directly on the redelivery terminal which is set as server, holding all the products in its content. If the request is accepted, the redelivery server will directly send the requested product to the avatar (2).
On the contrary, when a terminal works as client, each redelivery request from users is made on the redelivery client (1) and immediately forwarded from this last one to the server (1). If the request is accepted, the redelivery server will directly send the requested product to the avatar (2). This behavior is shown in the lower side of the picture above.
The redelivery terminal client doesn’t store any product in its content, but rely on the server for it.
! IMPORTANT: to set a terminal as client it is just necessary to drop the MD Redelivery Terminal & Product Server Script inside the terminal’s content and nothing else. The terminal will automatically set itself in client mode and work as already described.
Client terminals become extremely useful when the owner wants to offer a redelivery point at satellite stores or at events: in this case it will be necessary only to setup a redelivery terminal without placing any product inside, saving time and avoiding to have several copies of the same products inside each terminal.
Another important point to consider which favours client terminals is related to the fact that they are region-independent; this means that no matter where in the grid the client terminals are located, they will always be able to contact the redelivery server and process the request. Again, this feature becomes very useful in case of satellite stores or redelivery point at temporary events, where multiple redelivery clients – one per each satellite store and/or event – will connect to the redelivery server which will be the only one holding the products in its content. This setup will reduce the efforts needed by the owner to maintain a product list up-to-date, since these products will be stored only in one terminal and not mirrored into every terminal.
Chapter #6: Redelivery Terminal – Auto linking between terminals
As explained in the previous chapters, each terminal can store up to 250 items in its content; those items are the product that can be redelivered upon request. This limit is imposed by a Second Life constrain and cannot be changed. Even tho the maximum number of 250 products can be considered elevated, it is often not enough for a medium-big store, which has to manage even thousands of different products. MD Redelivery Terminal & Product Server Script solves this problem by allowing the redelivery terminal to link each other virtually, as if they were only one large terminal.
! IMPORTANT: The linking between a terminal and another is made when the new one is rezzed and it is completely automatic and invisible to the owner.
Since there is no limit on how many redelivery terminal a store can use, this solution allows the owner to manage a virtually unlimited number of products. When a customer request a redelivery for a specific product the request is sent to the first redelivery terminal but, if the requested item cannot be found in the terminal’s content, the request is then forwarded from the first terminal to the second, and so on until the product is found or there are no more terminals to query.
All this process is automatic and invisible both to the owner and the user, working independently if the initial request is made directly to a server terminal or a client one.
Redelivery request on multiple servers
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);
This chapter will focus on how to perform a mass redelivery from in-world; the process made using the MD Labs Online Services website is explained in the dedicated page.
After dropping this second script, clicking on the corresponding “Mass Redelivery” button will start a wizard composed by 4 different steps:
Step 1 – product selection: in this first step, owner will be prompted to a list of all products sold through in-world vendors and/or MP and will be asked to choose the product to redeliver; an useful ‘Search‘ button is present to simplify this step and make it faster.
Mass Redelivery – Step 1 – Product selection
Step 2 – object selection: once chosen the product to mass redeliver, an object (if present) matching the name of the product is picked automatically from the terminal’s content and selected as object to redeliver. However, in order to allow even more flexibility, the owner is asked if proceeding with the object selected automatically (‘Continue‘) or choose another object picking it from inside the terminal’s content (‘Change‘).
Mass Redelivery – Step 2 – Object selection
Step 3 – custom message: in this third step – optional – the owner is asked to submit a custom message that every customer will receive along with the product redelivery.
Step 4 – confirm: this last step consist in a recap of the chosen settings – product, object and custom message – in order to start with the mass redelivery process.
Mass Redelivery – Step 4 – Confirmation
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.
! IMPORTANT: the Manual Redelivery is a specific feature applicable to redelivery terminals only.
This feature is very similar to the Mass Redelivery, except that is applied to a specific avatar, instead of to all avatars whom purchased a selected product; similarly to the Mass Redelivery, it can be performed either from the in-world terminal or from the MD Labs Online Services website under the “Terminals & Servers” tab.
This chapter will focus on how to perform a mass redelivery from in-world; the process made using the MD Labs Online Services website is explained in the dedicated page.
Once clicked the corresponding button in the menu, the owner will be asked to follow a simple wizard to submit all the requested parameters:
Step 1 – avatar selection: owner will be first asked to provide the name or the key (UUID) of the avatar whom will receive the redelivered product.
Step 2 – product selection: in this step, owner will be prompted to a list of all products inside the terminal and will be asked to choose the product to redeliver.
Step 3 – custom message: in this third step – optional – the owner is asked to submit a custom message that the customer will receive along with the product redelivery.
Step 4 – confirm: this last step consist in a recap of the setting chosen – product and custom message – in order to start with the manual redelivery process.
Once the owner confirms all the settings, the redelivery starts and the selected product will be sent to the desired avatar, along with the custom message (if provided).
Chapter #9: Product server
A product server is a particular device holding one or more product in its content and having one or more client vendor connected to it, relying on it for the product’s delivery.
MD Redelivery Terminal & Product Server Script is able to work as redelivery terminal and product server, as well as product server only. The client vendors connected to the product server need to run the latest version of MD Vendor System as well as the Remote Control Plugin.
A product server – like the redelivery terminal – is subject to some limitations:
each product server can contain up to 250 items. However there is no limit on how many servers to use: if a product delivery request involves a product that cannot be found on the server #1, the request is automatically forwarded to the server #2, and so on until the product is found or there are no more servers to query;
each client vendor connected to a product server can retrieve only one item among all the products inside the product server’s content;
! IMPORTANT: a terminal running the MD Redelivery Terminal & Product Server Script can be both a redelivery terminal and a product server at the same time.
The setup of a product server is identical as the one required for a redelivery terminal: both script and products have to be dropped inside the object used as server. The connection of the client to the product server has to be done from the client vendor through the remote control plugin, as explained here. Once connected, the client vendor will be associated to one item chosen among the ones present inside the server’s content and every time a purchase is made from the client vendor the server is contacted to deliver the product to the receiver avatar.
Below are reported some real user case as example:
Terminal set as Product Server only
The schema displayed above describes a typical situation where the terminal is set to work as product server only. The user purchases the product through the vendor, which sends a deliver request to the product server – which could be located on a different region. The product server, finally, receives the request and delivers the product to the user.
Terminal set as Product Server & Redelivery Terminal
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:
The owner should change the MD Redelivery HUD Script’s next owner permissions to copy-only;
The owner should drop the MD Redelivery HUD Script inside the HUD’s content;
MD Redelivery HUD setup – permissions change
Once the script’s permissions are correctly changed and the script is dropped inside the HUD, the setup is complete and the HUD can be sent out to users whom – upon wearing it – will be able to access their redelivery page.
! IMPORTANT: The following user manual presents and explains the usage and detailed features of:
MD Vendor System Plugin – Poses version 2.1.0
The user manual for version 2.0.x, compatible with MD Vendor System 4.0.x can be found here.
Poses plugin add the following features to MD Vendor System:
Turn any compatible pose display into a pose vendor;
Allow users to scroll through all the poses and preview them before purchasing;
Pose adjustment system for the pose vendor;
MD Vendor System Plugin – Poses is composed by two main components:
MD Vendor System Plugin – Poses: it is the plugin script that has to be installed into the vendors along with MD Vendor System ‘core’ Script;
MD Pose Stand (Full Perm): is a pose stand – provided with full permissions – compatible with MD Vendor System – Plugin script, and already full functional;
Installing the plugin is very easy and quick: the owner will only have to drop the plugin script inside the vendor and it will be automatically detected and initialized; a message sent on chat will notify the owner of the successful installation. From that moment, the plugin’s specific features will be available through the “Plugin” sub menu present in the vendor’s owner menu.
Owner Menu – Plugin sub menu
By clicking on the corresponding ‘Poses’ button, the plugin’s specific menu will load, presenting all the available options:
Poses Plugin – Menu
Hover Text: this toggle lets the owner enable or disable the hover text above the pose vendor, showing the current pose name;
Sell Boxed: this toggle lets the owner decide whether sell the pose directly (as animation) or boxed, as object. More details on this feature in the dedicated chapter;
Scroll Dialog: this toggle lets the owner enable or disable an additional dialog window for users that allow them to scroll through poses, other than using the pose stand’s arrows;
Pose Timeout: this setting is aimed to avoid ‘camping’ of avatars on the pose vendors. Once the timeout is reached, the sitting avatar – if present – will be automatically unsit from the pose stand vendor, releasing the vendor itself and setting it available for other users to use;
Adjust Pose: this button leads to another submenu where is possible to adjust the pose displayed, working on the height and rotation for each axis;
Update: this button will search online for plugin’s update and deliver it to the owner, if found.
Back: this button navigate back to the main menu.
PLEASE NOTE: the plugin is aimed to expand the vendor’s feature, for this reason MD Vendor System ‘core’ script must always be present inside the vendor to use the plugin.
To uninstall the plugin simply remove it from the vendor’s content and the vendor will automatically update, removing the additional features.
Chapter #2: Setup a third-party pose stand
Although MD Vendor System Plugin – Poses comes with a handy full permission pose stand ready to use, the owner can choose to use a different pose stand from the one included; the poses plugin is in fact compatible with virtually any pose stand, as long as they are compliant to a few rules.
A compatible pose stand must satisfy the following criteria in order to be used with MD Vendor System Plugin – Poses:
Be a linkset of at least 3 prims with mod permission;
Have a child prim in the linkset called ‘prev‘ (lowercase, no quotes)
Have a child prim in the linkset called ‘next‘ (lowercase, no quotes)
Following these simple rules it will be possible to turn any pose stand in a pose vendor that will work with MD Vendor System Plugin – Poses.
The mod permission is required in order to be able to drop the poses to sell, while the ‘prev’ and ‘next’ prims are required in order to be able to use the scroll feature.
Pose stand – prim naming
Chapter #3: Loading the pose stand
Whether using the full perm pose stand included or a third party one, the loading process consist in drop one or many poses inside the pose vendor’s inventory; the poses must be valid Second Life animations and must have at least transfer permission for the owner. A message in the local chat will inform the owner about how many poses are loaded and also give warnings in case of errors.
Once the pose stand vendor is loaded and set for sale, any user sitting on it will automatically start playing the current animation in-world; through the ‘prev’ and ‘next’ buttons it will be possible to scroll through the poses available. With simple right right-click and ‘Pay’ the current pose stand’s user will be able to purchase the pose displayed; a left click on the pose stand will open the usual MD Vendor System user menu, allowing the customer more options such as gift or use store credits.
PLEASE NOTE: by default – and if the ‘Sell Boxed’ option is disabled – the pose vendor will deliver ONLY a copy of the current pose played, ignoring any other item such has landmarks, notecards and so on.
Chapter #4: Selling boxed poses
As stated in the previous chapter, by default a pose vendor running MD Vendor System and the pose plugin will deliver only the pose currently played in case of purchase; while this can be very quick and handy when setting up a pose vendor, there is often the need to deliver more than one item during a purchase, such has the store landmark, a notecard and so on. For this reason MD Vendor System Plugin – Poses includes an option called ‘Sell Boxed’ which can be toggled from the plugin’s menu; this option, when enabled, allows the pose vendor to deliver a boxed object corresponding which corresponds to the pose currently played.
Each pose (animation) present in the pose vendor is automatically mapped with an object which represent the boxed version of the pose; this matching between animation and object is made automatically through the pose’s name: the boxed pose – in order to be detected and associated – must have the pose’s name followed by the word ‘BOXED‘ written in capital.
As example, the boxed version of a pose called ‘Bar Dance‘ will be named ‘Bar Dance BOXED‘. When a customer pay the vendor for purchasing a pose, the corresponding boxed version name is generated and – if found in the pose vendor’s inventory – delivered to the recipient avatar.
This is an example of how a pose stand’s inventory would look like when selling boxed poses:
Poses Plugin – Boxed poses
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.
! IMPORTANT: The following user manual presents and explains the usage and detailed features of:
MD Vendor System Plugin – Store Credit & Gift Card version 2.1.0
The user manual for version 2.0.x, compatible with MD Vendor System 4.0.x can be found here.
Store Credit & Gift Card plugin add the following features to MD Vendor System:
Toggle store credit as payment method on the vendors;
Toggle gift cards as payment method on the vendors;
Create store’s gift card to sell and use with the dedicated MD Gift Card Script;
Create promo codes, with specific discount % and validity rules, to be used as payment method on the vendors;
Assign a reward in store credits for each purchase, with different percentages among group members and non-group members;
Toggle the possibility to use store credits or gift card credits to purchase gifts;
Installing the plugin is very easy and quick: the owner will only have to drop the plugin script inside the vendor and it will be automatically detected and initialized; a message sent on chat will notify the owner of the successful installation. From that moment, the plugin’s specific features will be available through the “Plugin” sub menu present in the vendor’s owner menu.
Owner Menu – Plugin sub menu
By clicking on the corresponding ‘Credits’ button, the plugin’s specific menu will load, presenting all the available options:
Store Credit & Gift Card Plugin – Menu
Store Credit: opens the store credit sub-menu where the owner can toggle the store credits as payment method for the selected vendor and select a percentage of the purchase that will be converted in store credits. More details about this feature in the corresponding chapter.
Gift Card: activates/deactivates gift card payment method for the selected vendor. More details about this feature in the corresponding chapter.
Promo Code: activates/deactivates the promo code payment method for the selected vendor. More details about this feature in the corresponding chapter.
Gift w/ Credit: toggle the ability to use store credits or gift card credits as payment method for gifts;
Update: this button will search online for plugin’s update and deliver it to the owner, if found.
Back: this button navigate back to the main menu.
PLEASE NOTE: the plugin is aimed to expand the vendor’s feature, for this reason MD Vendor System ‘core’ script must always be present inside the vendor to use the plugin.
To uninstall the plugin simply remove it from the vendor’s content and the vendor will automatically update, removing the additional features.
Chapter #2: Store Credit
Store credits are virtual coins offered by the store owner to customers that can be used to buy other products from the same store; the users earn store credits by purchasing products at the store using L$ on enabled vendors.
MD Vendor System allows two different levels of store credits:
store credits as reward for group members;
store credits as reward for non-group members;
The owner can decide if enable both levels or just one and – for each level – set a specific percentage of the product’s cost that will be converted in store credits.
Clicking on the ‘Store Credit’ button in the plugin menu will open the Store Credits sub-menu:
Store Credit sub-menu
There are two main options:
Group: with this toggle the owner can enable the store credits for group members, defining the percentage of the product’s cost that will be transformed into store credits;
Non-Group: with this toggle the owner can enable the store credits for non-group members, defining the percentage of the product’s cost that will be transformed into store credits;
PLEASE NOTE: when enabling the store credits for group members, the group the vendor is set to will be used. If the group is wrong, the owner should right click on the vendor, select ‘Edit’ from the drop down menu and change the group which is into the ‘General’ tab.
! IMPORTANT: by default, 1 store credit = 1 L$.
Once the store credit feature is enable, for every purchase paid (entirely or partially) with L$, an amount of store credits are added to the user’s balance; the number of store credit to add is calculated as the submitted conversion percentage of the item’s price paid using L$. For example, if the cost of the purchased item is 300L$ and the store credit percentage is 10%, 30 store credits will be added to the user’s balance.
The store credits are added immediately after the purchase and the users are able to check their current balance anytime, by clicking on the ‘View Balance‘ button in the vendor’s users menu.
User Menu – Store credit as payment method
MD Vendor System supports also ‘mixed’ payments: a mixed payment (in this case) is made partially by store credits and partially by L$. This scenario can occur if the user selects store credits as payment option but doesn’t have enough credits to purchase the item. In this specific case, MD Vendor System will prompt the user a window asking if abort the purchase process or complete it using L$ to pay the remaining cost of the item.
User Menu – Mixed Payment with store credits
If the user decides to complete the purchase using the L$ for the remaining amount, the vendor will set itself in ‘pay mode’, waiting for the payment; once it’s correctly performed, the product will be delivered and the purchase correctly finalized. In this case, the payment method for this transaction on MD Labs Online Services will be “Store Credit & L$“.
! IMPORTANT: in case of mixed payment with store credits and L$, the amount of store credits to add to the user’s balance is calculated ONLY on the part paid using the L$ balance.
Chapter #3: Gift Card
As for store credit, gift card payment option can be activated by the owner clicking on the corresponding toggle ‘Gift Card‘ in the plugin’s menu. No particular setup is required to activate this feature.
Store Credit & Gift Card Plugin – Menu
! IMPORTANT: by default, 1 gift card credit = 1 L$.
Once the requested value is submitted, the gift card feature will be immediately activated, adding the payment option in the user’s menu; users are able to check their current balance anytime, by clicking on the ‘View Balance‘ button in the vendor’s users menu.
User Menu – Gift Card as payment method
As for store credit, MD Vendor System supports ‘mixed’ payments also or gift cards: if the user selects gift card as payment option but doesn’t have enough credits to purchase the item, MD Vendor System will prompt the user a window asking if abort the purchase process or complete it using L$ to pay the remaining cost of the item.
If the user decides to complete the purchase using the L$ for the remaining amount, the vendor will set itself in ‘pay mode’, waiting for the payment; once it’s correctly performed, the product will be delivered and the purchase correctly finalized. In this case, the payment method for this transaction on MD Labs Online Services will be “Gift Card & L$“.
! IMPORTANT: in case of mixed payment with gift card and L$ (if the store credit feature is active) the amount of store credits to add to the user’s balance is calculated ONLY on the part paid using the L$ balance.
Inside the Store Credit & Gift Card Plugin pack there is also another pack included: MD Gift Card Creator Kit: it contains the script & tools required to create the gift cards that will be sold and used by customers.
! IMPORTANT: the only gift cards compatible with MD Vendor System are the ones using MD Gift Card Script, other gift cards using different systems will NOT work!
In the next chapter is described how to setup a gift card step by step, using MD Gift Card Creator Kit.
Chapter #3.1: setup a third-party Gift Card
The MD Gift Card Creator Kit contains the script & tools to required to create gift cards to use along with MD Vendor System. This pack is provided with Store Credit & Gift Card Plugin and comes boxed:
MD Gift Card Creator Kit – Boxed
Once unpacked, the content of the creator kit will look like this:
MD Gift Card Creator Kit – Content
The two important item on this creator kit are:
MD Gift Card Script: this is the script required by any gift card to work. It comes with copy&transf permissions and can be dropped either on a prim or inside a HUD.
MD Gift Card Template HUD (Full Perm): this HUD comes with full permissions and represents a template HUD for creating MD Gift Cards.
PLEASE NOTE: this chapter will explain the step-to-step guide for creating generic gift cards using ONLY the MD Gift Card Script. This means the gift cards created can be either object to rez/attach or third-party HUD; if you want to read how to create gift cards using the template HUD included, please refer to the next chapter.
The setup of a generic gift card is simple and quick and can be divided into three main steps:
Change MD Gift Card Script’s next owner permissions;
Drop MD Gift Card Script inside an object that will work as gift card;
Configure MD Gift Card Script’s amount and additional features;
As first step (step 1), a change on the next owner’s permissions is required: as mentioned before, MD Gift Card Script comes with copy&transf permissions, but in order to be used, the next owner’s permissions MUST be set to transfer only. This because a single gift card will be transfer only, so a user can gift and pass it to another, but not take a copy of it.
MD Gift Card Script – Change of next owner’s permissions
Once done with this first step, the owner must rez the object that will be used as gift card on the ground and drop the MD Gift Card Script inside the object’s content (step 2); if the script is dropped with the wrong permissions will automatically delete itself and another copy (with the right permissions) will have to be dropped. Once the script is inside the object and rezzed on the ground, this step is complete.
! IMPORTANT:the object/gift card’s name cannot end with a number; this is due to security reasons and every gift card which name ends with a number will be automatically invalidated by the system. This means gift cards named “Gift Card 500” are considered invalid.
Clicking on the object/gift card rezzed on the ground a configuration menu will be presented to the owner, containing several options:
MD Gift Card Script – Gift card configuration
Set amount: this button will ask the owner to submit the gift card’s amount in L$. This is the only value required during this configuration step.
Reserve: this feature allows the owner to reserve the gift card to a specific avatar, whom will be the only one able to use it and redeem the gift card. Once clicked the ‘Reserve’ toggle, owner will be asked to provide the avatar key (uuid) or name; once the reserve feature is enabled, clicking on the ‘Reserve’ button again will toggle it off.
Expire: this feature allows the owner to set an expiration date for the gift card, after which the gift card will not be usable and automatically invalidated by the system. Once clicked on the ‘Expire’ button, the owner is asked to provide the expire date in YYYY-MM-DD format (i.e. 2020-06-24); the gift card will automatically expire at 23:59:59 SLT of the defined day.
Max Usage: this feature allows the owner to set a maximum number of times a gift card’s type can be used by the same avatar. The gift card type is defined by the combination of the card’s name and amount. This means, for example, that a gift card called ‘Gift Card 500L’ with amount of 500 L$ is considered a ‘type’ of gift card and all the copies of the same card will have the same type.
By clicking ‘set amount’ and providing a valid number greater than 0, the gift card’s value will be set to that corresponding amount in L$ (step 3). At this point the gift card’s setup is complete and the object can be picked up in inventory, ready to be sold. Clicking ‘set amount’ again, the owner can change the gift card’s amount any time before selling it.
! IMPORTANT: after setting or changing the gift card’s amount, the owner MUST NOT change the object/prims’s description, as some relevant information are stored that – if changed – could lead to the gift card break.
Customers purchasing the gift card will be able to either wear or rez the gift card on the ground to get a menu where they will be asked if ‘use’ the gift card, adding the amount to their balance and making the gift card unusable. As additional feature, an animation or pose can be dropped inside the gift card along with the MD Gift Card Script: this animation will be played automatically every time the user will wear the gift card.
MD Gift Card – User menu
The gift card is now ready to be sold.
TIP: MD Vendor System can be easily used also to sell gift cards, handling them as ‘normal’ items (1 per vendor). This way owner will have a complete track of the income made by gift cards, integrated with MD Labs Online Services as well.
Chapter #3.2: Setup a gift card with MD Gift Card Template HUD
This chapter explain how to create a gift card HUD (Heads-up displays) using the template included inside the MD Gift Card Creator Kit.
Once unpacked, the content of the creator kit will look like this:
MD Gift Card Creator Kit – Content
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:
Rez the MD Gift Card Template HUD (Full Perm) on the ground;
Change the MD Gift Card Template HUD (Full Perm) next owner permissions to transfer-only;
Change the MD Gift Card Script next owner permissions to transfer-only;
Drop the MD Gift Card Script inside the MD Gift Card Template HUD (Full Perm);
Click on the MD Gift Card Template HUD (Full Perm) to setup the gift card;
Customize the MD Gift Card Template HUD (Full Perm) with personal texture and logo;
Take the MD Gift Card Template HUD (Full Perm) in inventory and rename it.
(1) As first step, the MD Gift Card Template HUD (Full Perm) has to be rezzed on the ground; once done it will look like this:
MD Gift Card Template HUD (Full Perm)
(2) Once rezzed, the first thing to do is change the gift card template next owner permissions to transfer-only:
MD Gift Card Template HUD (Full Perm) – change of next owner’s permissions
(3) The MD Gift Card Script – included inside the MD Gift Card Creator Kit – needs to have its next owner permissions changed to transfer-only as well:
MD Gift Card Script – Change of next owner’s permissions
(4) Once both MD Gift Card Template HUD (Full Perm) and MD Gift Card Script next owner permissions are set to transfer-only, the MD Gift Card Script has to be dropped inside the MD Gift Card Template HUD (Full Perm). At this point, the MD Gift Card Script will perform a permissions check over itself and on the HUD; if wrong permissions are found, the script will print a warning message on the local chat before deleting itself.
(5) As both MD Gift Card Template HUD (Full Perm) and MD Gift Card Script next owner permissions are set up correctly, it will be possible to setup the gift card’s amount and additional options through the configuration menu:
MD Gift Card Script – Gift card configuration
Set amount: this button will ask the owner to submit the gift card’s amount in L$. This is the only value required during this configuration step.
Reserve: this feature allows the owner to reserve the gift card to a specific avatar, whom will be the only one able to use it and redeem the gift card. Once clicked the ‘Reserve’ toggle, owner will be asked to provide the avatar key (uuid) or name; once the reserve feature is enabled, clicking on the ‘Reserve’ button again will toggle it off.
Expire: this feature allows the owner to set an expiration date for the gift card, after which the gift card will not be usable and automatically invalidated by the system. Once clicked on the ‘Expire’ button, the owner is asked to provide the expire date in YYYY-MM-DD format (i.e. 2020-06-24); the gift card will automatically expire at 23:59:59 SLT of the defined day.
Max Usage: this feature allows the owner to set a maximum number of times a gift card’s type can be used by the same avatar. The gift card type is defined by the combination of the card’s name and amount. This means, for example, that a gift card called ‘Gift Card 500L’ with amount of 500 L$ is considered a ‘type’ of gift card and all the copies of the same card will have the same type.
Customize: this button will lead to another sub-menu aimed to customize the gift card’s appearance by changing the card’s amount text color and the font;
! IMPORTANT: the gift card setup has to be done with the MD Gift Card Template HUD (Full Perm) rezzed on the ground and not attached. Moreover, after setting or changing the gift card’s amount, the owner MUST NOT change the HUD’s description, as some relevant information are stored that – if changed – could lead to the gift card break.
(6) It’s now possible to customize the MD Gift Card Template HUD (Full Perm)’s appearance by dropping a texture for the background and for the store logo.
Customers purchasing the gift card will be able to wear the HUD and be able to ‘use‘ the gift card, adding the amount to their balance and making the gift card unusable. As additional feature, an animation or pose can be dropped inside the gift card along with the MD Gift Card Script: this animation will be played automatically every time the user will wear the gift card.
TIP: MD Vendor System can be easily used also to sell gift cards, handling them as ‘normal’ items (1 per vendor). This way owner will have a complete track of the income made by gift cards, integrated with MD Labs Online Services as well.
Chapter #4: use a gift card
These few lines will explain you how to use a gift card, received as gift or bought.
As first thing wear the gift card by double clicking on it from the inventory, or right clicking and select ‘Add‘: a menu will appear, like the one reported below:
MD Gift Card – User Menu
In the dialog it is reported gift card’s amount in L$ and there is only one possible option:
Use Card: this button will start the gift card’s utilization process, which will add the gift card’s amount to your balance.
By clicking on ‘Use Card‘, a second dialog will open asking for confirmation:
MD Gift Card – Use card confirmation
By clicking on ‘Yes‘, the gift card’s amount will be added to your current balance and the gift card will not be valid anymore; you can now detach the gift card and delete it.
You can now use your credit simply by clicking on a vendor which supports gift card credit as payment, selecting if buy or gift the product and using ‘Gift Card‘ as payment method. The product’s cost will be subtracted from your gift card’s credit balance. You can check your balance anytime by clicking on a vendor which supports gift card credit as payment and selecting ‘View Balance‘.
Chapter #7: promo codes
A promo code is a special code which is associated to a discount, whether in a percentage or a specific amount in L$. MD Vendor System – Store Credit & Gift Card Plugin allow the owner to create as many promo codes as wanted, each one associated to a specific discount, that can be distributed and utilized during the purchase process. When purchasing from a vendor having the promo code feature enabled, in fact, the user will be asked to submit a promo code which – if valid – will apply the specific discount on the current transaction.
When creating a promo code, there are some basic settings to setup:
The promo code MUST be 3 to 8 characters long;
The promo code MUST contain only alphanumeric characters (a-z, A-Z, 0-9);
The promo code MUST be associated to a discount:
Using a percentage (%), between 1 and 99;
Using a fixed amount (L$);
The promo code’s utilization MUST be associated to one of the following:
Everyone: everyone having the promo code can use it and benefit of the discount;
Group members: only members of a specific group are able to use the promo code and benefit of the discount;
Specific avatar: only one defined avatar is able to use the promo code and benefit of the discount;
Along with these basic settings there are also several optional ones, aimed to customize even more the promo code. Those settings aren’t mandatory for the promo code to be created and used, but can enrich the whole experience.
Promo code utilization limit: define how many times a single avatar can use a specific promo code;
Promo code validity period: a validity start time and end time (in SLT) defining a period when the promo code is accepted by the vendors;
Promo code vendor: associate the promo code to a specific vendor, which will be the only one accepting the code;
Promo code region: similar to the previous one, associate the promo code to a specific region. Only the vendors in the region will accept the code;
Promo Codes are managed through the MD Labs Online Services website, inside the MD Vendor System product page. A tab called ‘Promo Codes‘ is present, containing a list of all the codes with all the features and the button to create a new one.
IMPORTANT: The promo code subject is widely explained in the corresponding chapter on MD Vendor System User Manual, so refer there for any further detail and explanation about how to create and manage promo codes.
After creating one or more promo codes through MD Labs Online Services website to allow users to use them is necessary to enable the corresponding option on vendors through the Store Credit & Gift Card Plugin, clicking on the corresponding ‘Promo Code‘ toggle inside the plugin’s menu.
Store Credit & Gift Card Plugin – Menu
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.
! IMPORTANT: The following user manual presents and explains the usage and detailed features of:
MD Vendor System Plugin – Remote Control version 2.1.0
The user manual for version 2.0.x, compatible with MD Vendor System 4.0.x can be found here.
Remote Control plugin add some very interesting features to MD Vendor System:
Connect the vendor as client (satellite) to another one (server) which will hold the product in its content;
Connect the vendor as client (satellite) to a product server which will hold the product in its content;
Installing the plugin is very easy and quick: the owner will only have to drop the plugin script inside the vendor and it will be automatically detected and initialized; a message sent on chat will notify the owner of the successful installation. From that moment, the plugin’s specific features will be available through the “Plugin” sub menu present in the vendor’s owner menu.
Owner Menu – Plugin sub menu
Once the plugin is successfully installed on the vendor the owner can access the plugin’s specific settings using the “Plugins” sub menu that can be found in the owner menu. By clicking on the corresponding ‘Remote Ctrl’ button, the plugin’s specific menu will load, presenting all the available options:
Remote Control – Plugin menu
Client: this buttons is a switch to enable/disable the client mode; by turning it on and performing the connection wizard, the vendor will become a ‘client’ connected to another vendor or product server which will act as ‘server’, hosting the products in its content. More details about this feature in the corresponding chapter.
Update: this button will search online for plugin’s update and deliver it to the owner, if found.
Back: this button navigate back to the main menu.
PLEASE NOTE: the plugin is aimed to expand the vendor’s feature, for this reason MD Vendor System ‘core’ script must always be present inside the vendor to use the plugin.
To uninstall the plugin simply remove it from the vendor’s content and the vendor will automatically update, removing the additional features.
Chapter #2: Setup a client vendor
Client mode is a vendor’s particular working mode where the vendor does not holds the products to sell in its content but connects to another vendor or terminal (‘server’) to retrieve the products. The advantages of this setup are obvious: keeping only one copy of your products inside the ‘server’ vendor will reduce the confusion of multiple copies and simplify the maintenance of your products, while also reducing the time required to setup your vendors; moreover, the same ‘server’ vendor can be connected to multiple ‘clients’.
PLEASE NOTE: Whilst the benefits of using client (satellite) vendors are obvious there is also one major downside: client-server communication require more connections and several ‘handshaking’ steps between the client and the server; the success of a purchase and product delivery depends by both client and server status – typically rezzed in different regions.
For reference:
A client vendor or satellite vendor is an empty vendor, connected to a server; upon purchase, the client requests the server the product’s delivery.
A server vendor or terminal is a device hosting one or more products and having one or more vendors connected to it as client; the server receives a product delivery request from the client and dispatches the item to the recipient avatar.
As client, a vendor can be connected to two different type of server:
Vendor as Server: the client is connected to another vendor running MD Vendor System (‘core’) script and the Remote Control Plugin.
Terminal as Server: the client is connected to terminal acting as product server and running MD Redelivery Terminal & Product Server Script.
TIP: often using a product server instead of a normal vendor as server is better because a device running the MD Redelivery Terminal & Product Server Script can be used for both redelivery terminal and product server, keeping all the products stored in one place and offering both redelivery and product delivery at the same time.
To setup a vendor in client mode, the owner will have to click on the corresponding ‘Client‘ button inside the remote control plugin’s menu, this will start the connection wizard; the procedure to connect a vendor to a server vendor or a server terminal is identical, only targeting a different set of devices. The first step of the setup is picking the type of server to connect to among vendor or terminal.
Client connection – Step 1 – Server type selection
Once the owner has selected the type of device to connect to will be asked to pick a specific vendor or terminal to use as server (step two), depending on the type of device selected in the previous step; in the following example, the owner picked ‘Vendor’ as type of server so a list of all available vendors is shown:
Client connection – Step 2 – Vendor Server selection
Once the server has been chosen it is necessary to pick one item inside the server which will be sold through the client (step three):
Client connection – Step 3 – Product selection
! IMPORTANT: any client – independently by the type of server which is connected to – will be able to manage only one normal item and/or one fatpack item from the server’s content; demo and multiple items will not be considered.
If no errors occur during the connecting between client and server the owner is taken to the last step of the connection process (step four), where is asked to confirm the connection. In this last dialog there is a summary of the client’s connection parameters:
server name;
server region;
server item to deliver;
There is one more feature on this step that can become very useful during the first setup of a client vendor; the owner can in fact decide if replicate the server’s settings on the newly connect client: the settings include price, discount, group mode and any other option. This feature is very useful because it speeds up the setup of clone vendors in specific situations. As example it can be considered the case of a vendor rezzed at a SL event which has to be set up as client and connected to a server vendor which is on the owner’s mainstore; if the client vendor will have to have the same price as the one already working at the mainstore and also the same options it will only be necessary to click on ‘Apply’ on the client’s connection confirmation dialog during the first setup and all the server’s settings will be immediately applied to the client.
Client connection – Step 4 – Connection confirm
PLEASE NOTE: the server’s settings replication on client is available only when connecting a client to a vendor as server, and not when connecting a client to a product server.
Once this last step is done, the connection is complete and a message will be displayed in the local chat; from that moment the vendor will use the item inside the server’s content as products to sell.
As users will buy or gift a product from the client vendor, the connected server will be contacted and will deliver the product purchased to the desired recipient. The workflow is described in the schema below:
Purchase process on a client vendor
On MD Labs Online Services website, a column called ‘Role’ in the ‘Sales’ tab displays, for every vendor, if it is configured as client or server.
MD Vendor System homepage – Vendor’s role
When a vendor is set as client, the remote control plugin’s menu will present one additional button:
Ping Server: this button will trigger a connection test to check if the vendor server is up and reachable. An message is sent to the owner, with the result of the test.
Remote Control menu – Ping Server
To disable the client mode from a vendor click the ‘Client’ button: the vendor will be disconnected from the server and will start acting like a ‘normal’ vendor.
To better improve the user experience, an effective delivery method has been implemented: as the user purchases the product the transaction is stored, but the item is flagged as ‘delivered’ only once the server successfully receives the deliver request and the product is sent to the receiver. With this method, if some communication issue arises during the connection to the server or during the product’s delivery, the transaction is stored anyway – giving the user the chance to use the redelivery feature – but will stay flagged as ‘not delivered’; the owner is able to check the delivery status of every transaction on the detail page of the corresponding vendor.
Chapter #2.1: tips to speed up the setup
MD Vendor System Plugin – Remote Control includes a few built-in features aimed to speed up the setup of satellite vendors, whether they are connected to another vendor or a product server; these features are:
auto-match;
product suffix;
‘Auto-match‘ is automatically used when the owner is trying to connect a vendor as a client: MD Vendor System Plugin – Remote Control will automatically try to match the client’s vendor name with the server’s info, in order to provide a faster setup. The auto-match is done over:
the vendor’s name, if the server is a vendor;
the product’s name, if the server is a product server;
As for example it can be considered a vendor named “Vendor Test” which has to be connected as client:
When performing a connection to another vendor (server), the plugin will automatically search for a vendor called “Vendor Test”; if found the client is immediately connected, otherwise a list of all eligible server vendors is provided;
When performing a connection to product server, the plugin will automatically search for an item called “Vendor Test” inside the selected product server; if found the vendor is immediately connected, otherwise a list of all available products is provided;
‘Product Postfix’ (or suffix) is another feature aimed to speed up the client vendor setup; the purpose of this feature is to ‘help’ the auto-match when connecting a client vendor to a product server and the client’s vendor name differs from the server’s product name by a constant string applied as suffix.
As for example it can be considered a vendor named “Vendor Test” which has to be connected as client to a product server in order to deliver the product “Vendor Test (wear to unpack)”. Since the client name – “Vendor Test” – and the product name inside the server – “Vendor Test (wear to unpack)” – are different, the auto-match feature would not be able to automatically understand the relation between the two; here is where the product suffix comes in to help: setting the product suffix to ” (wear to unpack)”, the client will use the vendor’s name, add the suffix and create the final product name to search for. The auto-match feature will do the rest and search for an item called “Vendor Test (wear to unpack)” inside the selected product server; if found the vendor is immediately connected, otherwise a list of all available products is provided;
The owner can set the product suffix from the MD Labs Online Services website under the ‘Advanced Settings’ area which can be found into the ‘Store Management’ tab.
PLEASE NOTE: the product suffix is a store-wide setting and once selected and applied it will be always used the same suffix to speed up the setup of all vendors connecting to a product server.
! IMPORTANT: The following user manual presents and explains the usage and detailed features of:
MD Vendor System Plugin – Demo & Items version 2.1.0
Demo & Items plugin extend the vendor’s ability to handle different type of items such as:
Handle one or more demo items, that will be given for free to users clicking on the “Demo” button in the vendor’s user menu;
Handle multiple “normal” items, that users will be able to select via the user menu and decide to buy or gift;
Handle one fatpack item, with custom price, that users will be able to buy or gift using the user menu;
Create a multi-item panel vendor able to display each product with its corresponding advertising. Users will be able to scroll and decide which product buy or gift;
Installing a plugin is very easy and quick: the owner will only have to drop the plugin script inside the vendor and the plugin will be automatically detected and initialized; a message sent on chat will notify the owner of the successful installation. From that moment, the plugin’s specific features will be available through the “Plugin” sub menu present in the vendor’s owner menu.
Owner Menu – Plugin sub menu
Once the plugin is successfully installed on the vendor the owner can access the plugin’s specific settings using the “Plugins” sub menu that can be found in the owner menu. By clicking on the corresponding ‘Demo & Items’ button, the plugin’s specific menu will load, presenting all the available options:
Demo & Multiple Item Plugin – Menu
Store Demo: when this option is enabled, MD Vendor System will store on MD Labs Online Services website also transactions for demo items.
Fatpack: enabling this option will open a dialog window where the owner will be asked to provide the fatpack’s price in L$. Any integer value greater than 0 will be accepted.
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: Demo item
One of the feature coming with the Item & Demo Plugin is the ability to add one or more demo items inside the vendor, which users can request and receive.
This feature rely on a naming convention to be respected in order for the script to automatically detect the products present inside the vendor’s content. A demo item in fact will have to contain the keyword ‘DEMO‘ in its name in order to be automatically identified by the MD Vendor System and used properly.
PLEASE NOTE: the keyword can be in any part of the item’s name, but it’s mandatory to write it with capital letters and without quotes.
As reference, here’s a couple of examples for demo items:
DEMO Mesh rigged hair; (correct)
Mesh rigged hair DEMO; (correct)
(DEMO) Mesh rigged hair; (correct)
Mesh rigged hair [DEMO]; (correct)
DEMO! MESH RIGGED HAIR; (correct)
Mesh hair DEMO rigged; (correct)
demo Mesh rigged hair; (wrong)
Mesh rigged hair Demo; (wrong)
Once one or more valid demo items are dropped inside the vendor, an additional button named “Demo” will appear inside the user menu; by clicking it, the user will receive a folder containing all the demo items.
User Menu – Get Demo
Chapter #3: Fatpack item
Demo & Items Plugin is also able to automatically detect and manage one fatpack item inside the vendor and sell it along with one or more ‘normal’ item; of course the fatpack price will differ from the other item’s price.
PLEASE NOTE: when it comes of selling a fatpack within a vendor, MD Vendor System – Demo & Items Plugin is required only if the vendor iteself contains at least another ‘normal’ (non-fatpack) product. If the vendor is supposed to sell only the fatpack item the plugin is not required and the vendor can be setup as a single-product one, with the fatpack item inside and simply making sure the fatpack item is not named using the reserved keyword. This chapter covers the scenario where a vendor contains one fatpack item and one or more ‘normal’ item.
Similarly as for the Demo, this feature rely on a naming convention to be respected in order for the script to automatically detect the products present inside the vendor’s content. A fatpack item in fact will have to contain the keyword ‘FATPACK‘ in its name in order to be automatically identified by the MD Vendor System and used properly.
PLEASE NOTE: the keyword can be in any part of the item’s name, but it’s mandatory to write it with capital letters and without quotes.
As reference, here’s a couple of examples for fatpack item:
FATPACK Mesh rigged hair;(correct)
Mesh rigged hair FATPACK; (correct)
(FATPACK) Mesh rigged hair; (correct)
Mesh rigged hair [FATPACK]; (correct)
FATPACK! MESH RIGGED HAIR; (correct)
Mesh hair FATPACK rigged; (correct)
fatpack Mesh rigged hair; (wrong)
Mesh rigged hair Fatpack; (wrong)
FatPack Mesh rigged hair; (wrong)
Once the fatpack item is dropped inside the vendor and correctly detected, the owner should set the price for it through the “fatpack” toggle into the Demo & Items Plugin menu.
As this last step is complete and the vendor is set for sale, the users clicking on the vendor and selecting “Buy” or “Gift” will be prompted to a product selection dialog listing all the items inside the vendor, including the fatpack:
HINT: To disable the fatpack feature owner will have to either remove the corresponding fatpack item from the vendor’s content or uncheck the “Fatpack” option present inside the Demo & Items plugin configuration menu.
Chapter #4: Multi-item vendor
The last feature added by the Demo & Items plugin is the ability to sell multiple “normal” (not fatpack, nor demo) products within the same vendor.
PLEASE NOTE: when selling multiple “normal” items within the same vendor, all of them will have the same price set using the “Price” button present in the owner menu. MD Vendor System does not support different prices for different “normal” items.
The owner can take advance of the multi-item vendor feature in two ways:
using the MD Vendor System and Demo & Items plugin inside a third-party vendor;
using the MD Vendor System and Demo & Items plugin inside the MD Multi-Item Vendor Panel, provided with MD Vendor System;
When using a third-party vendor as multi-item vendor, the owner should just drop all the items inside the chosen device/vendor, select a price and set the vendor for sale. The users will have to click to access the vendor’s menu and they will be asked to select which item to buy or gift. Once the choice is made, the purchase flow goes on as described in the previous chapters.
User Menu – Product selection
Chapter #4.1: Multi-item vendor with MD Multi-Item Vendor Panel
MD Multi-Item Vendor Panel offers a very efficient way to sell multiple products within one vendor, adding a few extra features such as:
product’s image preview;
scrolling through products;
dedicated menu & demo button;
MD Multi-Item Vendor Panel is included inside the MD Vendor System (Full Pack) and it has a land impact (LI) of 3 prims.
IMPORTANT: in order to take advantage of the features listed above, MD Multi-Item Vendor Panel is required. MD Vendor System Demo & Items plugin is not compatible with other multi-item panel vendors other than MD Multi-Item Vendor Panel. AO maps are provided for a deeper customization of the vendor panel.
MD Multi-Item Vendor Panel looks like the following:
MD Multi-Item Vendor Panel
previous/next product button: scroll through the products;
demo button: give the demo item (if present);
menu button: open the user’s menu;
previous/next products: display the preview of previous/next products. These panels are clickable and will bring the selected product in the main frame;
current product: product selected by the user;
The user can either use the scroll buttons to select the desired product and make it appear in the central frame, or directly click it from the previous / next products preview frames. Once the selected product is displayed on the central frame, the user can pay the vendor directly using the right click>Pay option or click on the menu button to get the vendor’s menu and proceed with the purchase.
MD Multi-Item Vendor Panel is able to automatically display the image of both the selected product and the previous/next ones in the corresponding frames; in order to benefit of this feature a simple naming convention has to be followed: the product image has to be named the same as the product but ending with “ AD” (no quotes). So, for example, if a product is named “Product 1”, the corresponding advertising image must be called “Product 1 AD” in order to be displayed automatically when the product is selected.
Given as example the products named “Vendor Item 1”, “Vendor Item 2”, etc, the MD Multi-Item Vendor Panel’s content would be looking like this:
