Release Notes - October 2024

IMPORTANT: As with most of our releases, the intent is that all packages are deployed to their latest versions (stipulated in Docker Images (final images)). This release has a hard dependency on the new Thrill ID v0.1.11 and the new services will not boot successfully without it.

• General
• New Features
• Changes/Improvements
• Bug Fixes
• Docker Images (final images)

General

• Upgraded the MongoDB driver used by all the services to the latest production-ready version provided by MongoDB.
• Upgraded the Redis driver used by all the service to the latest production-ready version provided by Redis. This upgrade allows us to use RESP3 protocol instead of RESP2 (compatible with Redis v6+).
• TLS Authentication Support added for both MongoDB and Redis
• Added documentation for all environment variables per service
• Added new documentation for Contribution Sources
• Added documentation for CommunityPayoutErrorEvent and RafflePayoutErrorEvent which are sent from the ThrillPots Gateway here

MongoDB and Redis TLS Authentication

MongoDB Configuration

If you wish to use TLS certificates for authentication with MongoDB, below is an example of how to configure the relevant environment variables:

# Add to URI: tls=true and authMechanism=MONGODB-X509
MONGO_HOST=mongodb://localhost:27217/?tls=true&authMechanism=MONGODB-X509
# Set if using a private CA not in the OS Root certificate store
MONGO_CERT_FILE_CA=certs/ca.crt
# Combined client authentication certificate and private key in X.509 PEM format
MONGO_CERT_FILE_CLIENT=certs/mongodb-client.pem

Redis Configuration

To configure TLS authentication for Redis, see below for how to configure your environment variables:

# Uses rediss as the schema
REDIS_HOST=rediss://localhost:6278
# Set secure to true
REDIS_SECURE=true
# Set if using a private CA not in the OS Root certificate store
REDIS_CERT_FILE_CA=certs/ca.crt

To setup the client certs and keys, you can do this with either:

# Combined client authentication certificate and private key in X.509 PEM format
REDIS_CERT_FILE_CLIENT=certs/cachedb-client.pem

or:

# Client authentication certificate file
REDIS_CERT_FILE_CLIENT=certs/cachedb-client.crt
# Client private key file
REDIS_CERT_FILE_KEY=certs/cachedb-client.key

New Features

ThrillPots

• Multi-strategy Community Payouts

  • Up until now, community payouts were limited to a single payout strategy (Active Players, Highest Lifetime Contributor, or the new Highest Contribution Per Win). With this release, it is now possible to define multiple community payout strategies for a single community win.

  For example, if you allocate 50% of the pot to be paid out to the community, you are now able to create sophisticated community payout strategies such as:

  • Pay 20% to X random players that were active contributors to the jackpot in the last n hours
  • Pay 20% to the top Y highest contributors to the pot
  • Pay the remaining 10% to the top Z highest contributors of the jackpots lifetime

  NOTE: Community payout strategies are defined as part of the jackpot mathematical model. If you would like to migrate your model to take advantage of multi-strategy community payouts in the future, please contact your Customer Success manager or technical point of contact to discuss further.

  IMPORTANT Existing community jackpot templates and instances will be automatically migrated to the new structure needed for the feature. The migrations have been written in such a way that they are repeatable (no loss of data), so in case of unexpected interruption or error, the migrations can be re-run.

• New Community Payout Strategy: Highest Contributor Per Win

  • In previous versions, the Highest Contributor strategy would track and reward the highest contributors for all time against a jackpot instance.
  • This new strategy provides the following capabilities:
    • Contributions are tracked per player, per pot (jackpot tier)
    • When this strategy is used to select community winners for a pot that has been won, the contribution values per pot are used for the selection.
    • When a specific pot is won by a player, all players have their contribution counters for that pot reset
  • This strategy provides a fair way to introduce new brands to a multi-brand community jackpot by eliminating any advantage players from longer-participating brands may have had.

• Raffle Ticket Accumulation Mode

  • As of this release, Raffle Tickets can be awarded based on accumulated contributions or base wager costs.
  • What this means is that you can set the "price" of a raffle ticket to be X (eg €2.00), and as players contribute or wager, the system will accumulate the selected metric until the cost of the ticket has been reached, at which point a ticket will be awarded.
  • For example:
    • A ticket's cost is set to €2.00 of base wager
    • A player is playing a slot game for €0.10 spins at a time.
    • After 20 spins at €0.10 per spin, the player will be awarded a raffle ticket.

• Winners Feeds from ThrillPots Gateway

  • Implemented functionality to retrieve latest winners per pot, as well as over all pots.

    • jackpot_latest_winners_for_instance_pot
      • Returns a HashMap where the keys are the pot identifiers, and the values are arrays containing the latest winners for the pot
    • jackpot_latest_winners_for_instance
      • Returns an array containing the latest winners over all pots

  • APIs are served in ThrillPots Service as well as ThrillPots Gateway at the following routes:

    • ThrillPots Service

      • GET /instances/:instance_id/pot_winners
      • GET /instances/:instance_id/latest_winners

    • ThrillPots Gateway

      • GET /jackpots/instances/jackpot/:instance_id/pot_winners
      • GET /jackpots/instances/jackpot/:instance_id/latest_winners

  • Both APIs accept the following query parameters:

    • brand_id (Optional) - filters the winners by brand_id. If not provided, winners across all brands will be returned.
    • limit (Optional, default: 10) - limits the number of winners returned. In the case of pot_winners_for_instance, limit is considered per pot

Changes/Improvements

ThrillPots

• ThrillPots Gateway now proxies the integrated client's credentials to ThrillPots Service.

  • This means that the accounts used by your Event Processor and other services that are integrated with ThrillPots Gateway will need to have their permissions reviewed to ensure that the expected capabilities are available.
  • In general, a standard ThrillPots Gateway client integration account should require the following permission set:

  {
  	"system_id": "thrillpots",
  	"permissions": [{
  		"resource_id": "*",
  		"permission": "Write"
  	}]
  }
  

  A full account document may look as follows:

  {
  	"account_type": "Service",
  	"username": "thrillpots.gateway.client",
  	"password": "**********",
  	"org_unit": {
  		"org_id": "YOUR_OPERATOR_ID"
  	},
  	"permissions": [
  		{
  			"system_id": "thrillpots",
  			"permissions": [{
  				"resource_id": "*",
  				"permission": "Write"
  			}]
  		}
  	]
  }
  

  • We recommend that you test all your services that are integrated with ThrillPots Gateway to ensure that they are still working as expected. If not, please contact your ThrillTech Technical Point of Contact for further support.

• Improved allowed_brands handling on Jackpot instantiation

  • Previously, when instantiating a Jackpot, the allowed_brands would be duplicated from the Jackpot Template to the Jackpot instance in all cases.
  • Going forward, if instantiation is targetted at a specific brand, the allowed_brands array will only contain the targetted brand, instead of the full list of brands under the operator.

• Events sent from ThrillPots Gateway now carry a unique event_id identifier for each event.

  • This can be used to detect already-processed events in your downstream listeners (if you have more than one listener subscribed to events)

• Audit records in log_contributions and log_winners now carry their respective Debit and Credit (if relevant) transaction IDs. The new fields are called tx_debit_id and tx_credit_id respectively.

• Audit records for opt-ins now carry the contribution_value for the opt-in. Values of null mean that the player opted-in for the minimum amount.

ThrillGate

• The metadata field of batch transactions is now correctly populated with metadata that is sent on contribution requests
• Additional request/response DEBUG-level logging has been added

ThrillOffice

• Introduced administration endpoints to be able to configure the endpoints of ThrillTech services:

  • Get all services:

    • GET /services

    Example

    Response Payload

    [
    	{
    		"id": "thrillid",
    		"host": "http://localhost:9000",
    		"event_channel": null
    	},
    	{
    		"id": "thrillpots",
    		"host": "http://localhost:8084",
    		"event_channel": null
    	},
    	{
    		"id": "thrillgate",
    		"host": "http://localhost:8100",
    		"event_channel": null
    	},
    	{
    		"id": "thrilldrops",
    		"host": "http://localhost:8500",
    		"event_channel": null
    	}
    ]
    

  • Create new service:

    • POST /services

    Example

    Request Payload:

    {
    	"id":"a-new-service",
    	"host": "http://newservice:9999"
    }
    

  • Update service:

    • PUT /services/:service_id
      • service_id parameter is the identifier of the service to modify

    Example to update the host

    Request: PUT /services/thrillid Payload:

    {
    	"host": "http://thrillid:9000"
    }
    

  • Delete service:

    • DELETE /services/:service_id
      • service_id parameter is the identifier of the service to modify

    Example Request: DELETE /services/a-new-service

Bug Fixes

ThrillPots

• house_contribution on contribution audit records (log_contributions) are now correctly converted to player currency as well.
• When wins are withheld due to holding account rules, there was a defect where the withheld flag was not propogated correctly in all cases. This has now been fixed

ThrillGate

• Batch Transaction cancellations correctly send the list of individual player transaction IDs in ALL cases. There were a limited set of cases where the player-specific transaction IDs were not sent, and this has now been corrected.
• Transaction Cancellation now carries the correct player ID in addition to the transaction ID to be cancelled. In previous builds, the player ID sent was a fully decorated ID and not the ID of the player as provided by the operator's platform.

ThrillConnect

• Service connections to ThrillConnect did not receive events that they were subscribed for. This has now been fixed and any Service based event subscribers listening to ThrillConnect events will once again start receiving events.

Final Images