GAT Component Digest

Located on the TTK menu tab, a user can create a signature digest file for the software on a known EGM that can later be used to verify the software signatures on another EGM to make sure the second EGM is running the same software (or at least is able to generate the same signatures).

The digest lets the user select Verify Components, which launches a new object that contains a listing of all components in the selected EGM, as were reported by the EGM during the start-up algorithm. Verify Components performs a validation on each selected component (or all of them) using the provided values. There’s even an Automate feature that will have the RGS automatically process all unverified algorithms for all components in the EGM.

Where Seeds, Salts or Offsets are supported for an algorithm, RGS automatically provides a value (displayed as columns in a table). As each successful verification result is returned, they are marked for the user to select if desired and added to the digest file of known-good software as reported by the control EGM.

 GAT Component Verification

In GAT Component Verification the RGS randomly selects an algorithm for each component from the set of combinations that are common between the EGM under test and the GAT Component Digest File. For each verification, the stored Salt, Seed and /or Offset for the selected algorithm of each component is sent to the test EGM in the gat.doVerification command. The EGM is then expected to return the same result that is stored in the selected Component Digest File. As each result is returned by the EGM, a table is updated with the result of the verification. The results can then be exported to an Excel report, if needed.

In this blog spot, over the last few weeks, I’ve been reviewing the RGS Tester Toolkit (TTK) features and functions in an effort to let everyone else know what RGS Power Users have already figured out – This add-on is a must-have. I hope you’ve enjoyed this walk through and you can see that at RadBlue we design with our customers in mind.

Would you like to test drive RGS TTK? Contact us about a temporary evaluation license of this great add-on at support@radblue.com. 

Response Manager

Response Manager is found on a tab just like the other tools in the TTK layout. This feature gives the user that ability to design and control the response/reply interaction of G2S commands to and from the EGM.

Response Manager enables a user to create a response configuration. That configuration can be one or more custom responses predefined to be used when a specific G2S command is received from the EGM. The configuration options include the ability to create the text of the message, the specific command it is sent in response to and the definition of a pattern in which to use the response. For example, only use the customized text one time out of the next 4 times the target command is sent.

A response action definition is also allowed. The response action can be no action at all, a custom command sent, a predefined application error or even a customized application error.

Although the goal of Response Manager is customization, the RadBlue developers didn’t spare usability or leave the user out alone in the tool. The Response Manager comes with a standard response configuration and also an alternative, so that anyone new to the tool can hit the ground running by reviewing the set up in the pre-loaded example.

Developers and testers alike know that “happy path” development isn’t enough. Alternate outcome, edge cases, and failure response development and testing is required to ensure production-worthy products. Using Response Manager for these applications makes things so much easier. And, once created, these response configurations can be used repeatedly when they are set as the default or used on the fly only when needed in RGS.

Need to know more?  Check out the Tester Toolkit User Guide.

Would you like a test drive? Contact us about a temporary evaluation license of this great add-on at support@radblue.com.

Up front, let me say that the Components tab, located on the Tester Toolkit layout, is where a user can configure event subscriptions, meter subscriptions and macros. Did you know that was possible?

This area is also where the CommConfig.setCommChange and optionConfig.setOptionChange components are found. These can be used in custom scripts and startup algorithms. There’s also Load Display Media Content, a component used to define media content for the mediaDisplay.loadContent command found here.

What are Components? Well, I think of them as building blocks. Here’s the 10-cent tour:

Event Subscriptions

Event Subscription configuration creates event subscription files that can be used in the startup algorithm or added to custom scripts.  Changes to event subscription files dynamically update anywhere they are used. For example, if you insert an event subscription file into a custom script (through the setEventSub command), and then make changes to it, the script is automatically updated.

Note that RGS only sends events that are supported by the EGM, including custom events. If the EGM does not support a particular event, it is discarded before the setEventSub command is sent.

Meter Subscriptions
Meter Subscriptions define which EGM meters (currency, device, game denomination and wager) to receive and the reporting interval (end-of-day and periodic). You can select whether to include meter definitions in meter reports.

Set Comm Change Component

The commConfig.setCommChange command configuration can be used on the Available Set Comm Change Files list on the Set Comm Change component. Once saved to the list, the file is available for use in custom scripting. This file can be modified or deleted as well.

Set Option Change Component

The Set Option Change component allows the user to edit the optionConfig.setOptionChange commands, and then include them in custom scripts as desired.

Media Display Load Content Component

The Media Display Load Content component lets the user define media content for use with the mediaDisplay.loadContent command in Custom Scripting. There are options to add and edit media display files.

Macros

Macros let the user create pre-configured, multi-command host operation scripts (for example, the downloading and installation of a package). Each macro created can then be used in a custom script. By default, all macros created are automatically added to the Custom Scripting list of commands available to use. All default and newly created macros are saved to an RGS directory.

Global Device Variable Templates

When a command is added to a custom script there is an option to select the device that the command is executed against. By default, each command goes to all devices; however, by using a Global Device Variable template the device settings can be defined as the user wishes by adding a modified template to a custom script.

There’s a lot here. WE understand. Want to learn more or see some detail about these amazing components? Read about them here in the Tester Toolkit User Guide.

Do you want Tester Toolkit for RGS? Contact us about an evaluation license of this great add-on at support@radblue.com.

Many of our customers requested a way to send G2S commands on-demand from our RGS host simulator to the EGMs they were working with. We’re really good at providing solutions, so – Voila! – Custom Scripting was born.

What is Custom Scripting, you ask? This Tester Toolkit feature enables a user to create and send completely customized, executable scripts from the RGS. The scripts can contain G2S commands, script verbs, user prompts and other complex commands.  Custom Scripting in RGS utilizes a very user-friendly graphical interface for test engineers, or any other user, to develop and run these commands.

What can you do with Custom Scripting? Just about anything that you can think of. How about creating a snapshot of the meters on an EGM, pausing the script to input paper money, coin money, tickets or even WAT balances to the EGM, playing games, then taking another snapshot of the meters and telling the RGS to perform the meter analysis and provide the data to you!

Additional features include, but are not limited to, running other script verbs, stopping the script to wait for a specific event, running a macro, adding device variables, inserting event subscriptions, setting active EGM denominations, performing meter or event snapshots, calling other custom scripts to run, and even sending raw or customized G2S commands from RGS.

All scripts, once built, can be saved, modified, called by other custom scripts and run on-demand. Although it’s not possible to run more than one custom script at a time, script commands can be repeated within a script as many times as desired.

The RGS Tester Toolkit helps new users hit the ground running by pre-loading the feature with three completed, modifiable custom scripts to get started. New scripts can easily be added, saved from a change to a canned script or added from scratch. Custom Scripts can be complex or simple, customized to the ultimate need of the user.

Ready to get started? You can check out the Tester Toolkit User Guide here.

OR try it yourself today! Contact us about an evaluation license at support@radblue.com.

What are Startup Algorithms? Startup Algorithms define which G2S commands are sent when an EGM establishes communication with RGS for the first time. These G2S commands are required to establish and maintain that EGM/Host conversation.

While it’s true that a standard RGS (without Tester Toolkit) comes with the ability to turn on and off G2S commands in the standard Startup Algorithm, that’s where it ends. The Tester Toolkit module extends that functionality by allowing the user to define the commands, attributes, change sequencing of commands, even group commands to send together as one, or run the algorithm one command at a time using the “step through” feature.

Tester Toolkit comes fully loaded with four “canned” Startup Algorithms. The out-of-the-box default Startup Algorithm enables the tool to be useful without manual set-up. The other options can be substituted without any changes for the standard default algorithm, if desired, as well. Or, they can easily be used as a template for creating modified algorithms that can be saved for future use under a name and description of the user’s choosing. Swapping between them on the fly is easy and quick. There’s even a feature to set an alternate algorithm to be used all the time, even persisting through future RGS versions.

In short, Startup Algorithms are a highly customizable feature of the RGS Tester Tookit.

Want to know more? Check out the Tester Toolkit User Guide found here.

Want to try it yourself? Contact us today about a temporary evaluation license at support@radblue.com.

G2S is our world and, because of the nature of the work we do at RadBlue, we use our own tools every day. This optional feature set is, in a word, POWERFUL. RGS enables a user to easily customize the G2S commands that are sent to the EGM. It boasts on-demand G2S host response customization – not to mention creation and execution of macros and scripts to more fully explore your G2S EGM.

Tester Toolkit can:

• customize which G2S commands, in which order, are sent to an EGM when it establishes a connection through Startup Algorithms.
• help you create an event subscription, meter subscription or macro for use in a custom script, using Tester Toolkit Components.
• enhance the customized components, or macro you built, by using them in an executable Custom Script.
• provide the ability to not only change what G2S commands that are sent to an EGM, but how those responses are sent. Response Manager is unbeatable for failure point, error definition and alternate path testing.
• assist in sample GAT software verification. Brand new in RGS 38 with Tester Toolkit – GAT Management Control is available. This feature uses a GAT Component Digest to perform GAT Verification for connected EGMs.

Want to know more? GREAT! Stay tuned to this blog spot while we walk through these incredible features one by one. Designed to be quick, bite-sized chunks that are easily digestible, with the personal hope that more users will find and use these life-saving tools. (Okay, that was a little over-the-top. But they really are great.)

Can’t wait? Need more now? Check out the Tester Toolkit User Guide found in our online RadBlue Document Library.

In this new version of the CVT, we’ve completed our testing of the important requirements in the meters class, along with numerous other changes throughout the product.

New features of note in this version of the tool include:

1. The latest CVT Coverage report is now included in the help system (as well as on the CVT Portal).
2. The CVT is now checking all of the relevant attributes in the cabinet class commands.
3. The cabinet door open/close test case has been duplicated so we can examine the associated data of each of the events.
4. We’ve added the verification of the disableText attribute by the tester.
5. We’ve added a test case to verify the events for the opening and closing of the auxiliary door.

For information on all of the changes in this release, including new test cases, check out the release notes.

Updated release notes, a new CVT Test Case Encyclopedia, a new CVT Coverage report and the latest CVT installer can all be found on the CVT Portal.

Please let us know if you have any questions or issues (or if you need a license, so you can take the CVT out for a spin).

Good luck!

That’s what I said recently to a colleague about our tools during a discussion. She smiled at me because that’s what you do when someone says something ridiculous and you don’t want to be impolite.

I realized, in that moment, I needed to create something to help me digest all the information I’m reading and learning. A type of puzzle frame or road map. So, I started making lists. (I’m kinda famous for them in my life, lol.)

I’ve got a list for things it would have been great to know when I started learning about GSA and the RadBlue Tools.  I have one about what I want to learn next about GSA, our advanced features and how our users are doing things in the field.  I even have a list for stuff that doesn’t make any sense to me at all.

And then it hit me!  I’m going to share them here on our blog page because I’m sure I’m not the only person who could use the information.

10 Things I Needed to Know about Message Transcript and Debug Console

1. Don’t ignore Red text.
   Red text may be found in a log file, message transcript or the application display. Getting red text means something isn’t right. If you don’t know why you’re getting a message, contact RadBlue support for help.
2. Make life easier by using the quick search feature.
   Type in what you want to see in the quick search bar. The default search is case non-specific and you can type all or just a portion of the text you want to see. The tool will filter as you type.
3. Find GSA commands quickly.
   In the search bar, enter commands without using the class name where appropriate. Example: setActiveDenoms vs gameplay.setActiveDenoms.
4. Compare two Message Transcript entries side-by-side.
   Click one message and then another while holding down the CTRL key on the keyboard. Click the Compare button, and the tool will show the selected messages side-by-side with tabs to review the command, the XML and the differences.
5. Blue text in a Debug Console can alert you to a problem. 
   Review the log at start-up, and while using the RadBlue tool, for unexpected behaviors.
6. Find and use the Filters button.
   Automatically filter data before you see it in the Message Transcript and Debug Console.
7. The Filters button in the Debug Console can filter the type of messages to display.
   Filter by Debug, Error, Fatal, Info, Unknown and Warn.
8. The Filters button in the Message Transcript allows you to choose specific commands, events and/or devices to filter messages.
   Filter options also include showing g2sAck commands and errors.
9. Click a message in the Message Transcript and watch for the green or blue text to appear. 
   The tool will show you which message request-response pairs go together as well as the G2S acknowledgements.
10. Individual entries in the Transcript or Debug Console can be copied and saved. 
    But the best possible way to share information is by creating a Debug.zip file from the tool BEFORE you stop the application. This captures all relevant information that could be used for troubleshooting. It is also the first thing we will ask for when assisting a customer with an issue. You can find the Export Debug button on all Debug Console screens or by going to File > Export Debug from the menu bar.

Okay, so it’s not Letterman’s Top 10, but this sure helped me! Stay tuned for more of my travels through the looking glass of G2S Wonderland.

From time to time I still get stuck but I’ve become much more self-sufficient by using a great feature I found in each RadBlue tool.  You may have seen it but not using it. Don’t have any idea what I’m talking about?  It’s the Help file.

RadBlue Help

What is in a Help file you ask? I’ll tell you! Loads of great information to start.

From the Help file Home page, you can view PDF files of the Product Overview, cumulative product Release Notes, product-specific Bulletins, the product User Guide^* and, depending on the product, additional references and guides. For RGS, RST and RPA, a Quick Start Guide walks you through the fundamentals of using each tool.

In addition, each RadBlue Help file has product information that is presented in a concise, easily digestible format so information can be found and read quickly. Topics include:

• Getting Started – A summary of the product, its requirements and information to get you started with the tool.
• Interface Review – Part of the Getting Started topics, this is a visual walk-through of the main tool screens and features.
• Product Customization – Describes each configuration option to help you get the tool behavior you need.
• Detailed How-To – Information on using product features, including Transcripts.
• Troubleshooting – What to do when you have an issue with the tool.

^*All information in the User Guide can also be found in the Help file.

Plus, Help content is searchable. There’s a Table of Contents, a keyword search and an Index. Links string together information from one area of the Help file to another to help you navigate the information quickly.

Did a keyword search, but didn’t find what you were looking for? Let us know! We’ll get the information to you quickly, and add it to the Help file so it’s available to others.

Where is the Help File?

That’s easy! Each Help file can be found by clicking Help on the menu bar or by pressing F1 on your keyboard to open Help in a browser.

That’s really all there is to it. Learn from my travels in wonderland! Until next time… We know you have choices when you fly GSA and we’d like to thank you for choosing RadBlue! Good Luck!

Go to the CVT Development Portal to download the latest installer, release notes and coverage map.

Changes in this release include:

• new test cases in the eventHandler and cabinet classes.
• user interface improvements.
• state indicators added to Partial or Excluded test cases on the Test Session Universe tree (Test Session > Current Test(s)). You can now view the reason for a Partial or Excluded test case state by hovering over the device, or by right-clicking the device and selecting Device Properties.
• new CVT Exceptions.
• a new Archive Set report option that creates a ZIP file with the Public Facing Transcript (PFT), Detail Report, Summary Report, Excel Report and test metadata.
• generic error codes consolidated in the “Error Codes” chapter of the CVT Test Case Encyclopedia.
• improvements to Test Session Templates.