Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
The boot-up command line interface is used to prime your collection to be used with the Boots protocol.
We will take you through the following steps:
Create Main Class
When you build something, you need a blueprint. We will show you here how to create your blueprint on-chain to allow your project to be booted up.
Create the Items Collection
This step will establish the collection for your items. It establishes this collection of NFTs or SFTs to be able to be equipped on the NFTs of your collection.
Create the Item Classes
Each of the items that you want to equip on your NFTs will need to have its own blueprint. This step creates that for each of your booted items.
Create Players
This last step establishes the NFTs in your collection as Bootsified NFTs.
We will assume that you have an on-chain collection of NFTs, and assume you are familiar with using a command line interface (CLI) to execute commands on your operating system of choice.
Review your Player and Item class enabling with Boots
Once you have completed all 4 steps to enable your collection to work with Boots, you can validate what your player and item classes look like by using the Raindrops CLI. First, go to the configuration file that you have been working with. An example of a finished configuration file is in the Examples, here. You will want to copy the Player Class configuration that was generated by Boot-Up
Search for existingClassDef
in the file and copy the object into a new configuration file. We will name this bootsPlayerConfig.json for the purposes of this example.
2. Make sure you know the location of your keypair file. For our purposes, we will name this bootsUpdateAuth.json and put it in the same location as the config file from step 1.
3. You will also need the masterMint. You can find that in the "masterMint" key from the configuration file you created in step 1. For our purposes here we will be using the Mint Id BNpznqP6Rfy8LhPHEQ23qBYFiAueKiXx9jRaW6WnTo1z
4. Use the following command to show the Player class:
The result of this command is the following:
should match the number of NFTs in your collection
Should show the newBasicStats (i.e. mutationLevel) as well as the stringLayers (i.e. BACKGROUND, FUR) that you have specified in your configuration.
Shows Items that can be equipped for the NFTs in your collection.
For more detail on this output, review "creating a Parent PlayerClass"
Boot-up is a command line interface for making a collection work with the Boots service. If you have a NFT collection currently on-chain, the steps in this guide will "boot up" that collection.
In order to use the Boot-up CLI you will need the following:
An on-chain collection of NFTs.
The NFTs in this project are configured with a Collection NFT. For more on Certified Collections, please visit https://docs.metaplex.com/programs/token-metadata/certified-collections
The Solana command line toolset (https://docs.solana.com/cli/install-solana-cli-tools) - to interact with the Solana network.
1 $RAIN (Mint Id rainH85N1vCoerCi4cQ3w6mCf7oYUdrsTFtFzpaRwjL
) for each player in your collection.
This section covers the steps to use the CLI to boot-up.
The Boot-Up CLI is part of the Raindrops protocol. Install the Raindrops CLI using the instructions found here, the Boot-Up CLI is included in the raindrops-cli
. Once installed, you will have access to a sample configuration file which works with the Degenerate Trash Panda collection.
To find this, use the following commands:
npm list -g
To find the location of the raindrops CLI on your machine. You will get something similar to the following:
/Users/<your user name>/.nvm/versions/node/v18.8.0/lib
Once you are in the directory specified, make your way to the boot-up example-configs directory, located at
node_modules/@raindrops-protocol/raindrops-cli/example-configs/boot-up
Rename the pandaExample.json file to reflect your project name and move it to the desired working directory
mkdir ~/boot-up
cp ./pandaExample.json ~/boot-up/myProject.json
This file establishes the definition of the boots-enabled configuration of the collection. You will want to keep this file safe, saving often as you go through this process because as you boot-up your collection the configuration is updated with on-chain ids and other configuration items that will be important to complete the process.
Let's have a look at the keys in the configuration file and what they mean
This step creates the player class on chain and stores the information needed in the configuration file.
To run, issue the following command:
The command line parameters are as follows:
The output of the help option is the following:
After this command is run, the existingClassDef
entry of the configuration file will be updated with the class definition information.
Once this command finishes successfully, you can move on to the next step
This page describes the options you can set as part of the configuration
The scope defines what type or set of NFTs you want to establish with Boots. There are currently three options
If this is set to true, the Boot-Up CLI will scan the NFT to make sure that they weren't given more than one of each trait. This process only applies to NFTs that have reached their final state.
*IMPORTANT NOTE* DO NOT set this to true after the collection is being used by your community. This will prune duplicate tokens from the Player class of the NFT, so TAKE CAUTION HERE.
This serves as a key to save the process of the Boots conversion for your NFTs. This will be constantly updated during Step 4 - Create Players, so the initial value for this key should be set to null.
This is a whitelisted array of the body parts you would like to enable for boots. These parts can be changed in your collection.
This array is the set of attributes that you do not need to be able to change through Boots. These are things like the base body for your character. In addition, users will be able to change these items by equipping them as consumable items, and that these will be stored as items on-chain.
This is an array of configuration sets for other non-graphical statistics that you would like to apply to the player class of this collection. The form is described here: Player - Basic Stats​
if true, these items will be created as Semi-Fungible Tokens (SFTs).
the name of the on-chain class for this collection
reserved for the namespace for this collection. Namespaces are currently a work in progress, so stay connected to @only_raindrops on Twitter for updates.
Set skipUpdates to True if you do not want the player to be updated with any changes that have happened to the NFT's parent class since the last run. For instance, if a new layer is desired, or if you want a new statistic applied to this player definition, you would want to keep this set to false.
Setting this to true means that Boot-Up will retry configuring your NFT for Boots if an error happens during the run. If you set this to false, the error will propagate up and the next NFT will be tried. It is recommended to keep this set to true.
Set this to true to allow a holder to be able to equip their NFT in this collection. If false, then the collection owner must be the one to equip the collection NFTs. In addition, fees for equipping items can be circumvented if this is set to true.
This is where you are defining the items that will be able to be equipped on your players.
For each item, you will add a default boilerplate entry.
The layer will be populated by Boot-Up with the configuration, so leave it defined as is.
In addition, this is where the bodyPartLayers comes into play. If you want to enable creating NFTs or SFTs for these items you will need to whitelist them in the bodyPartLayers key.
This is the location of the directory that holds the images for the individual items. When the process runs, it will create the NFT or SFT on chain for you, and this is where you have the image files specified.
NAMING CONVENTION FOR THE IMAGE FILES
Because the system needs to be able to find the files in your file system, you will need to follow a character substitution pattern when you name your image files. In general, use an underscore ( _ ) character to substitute for whitespace, and replace any special characters as follows:
So a layer named
"EXALTED_STAT | RUGGED_COUNT: 2"
would end up with an image file named
"EXALTED_STAT__RUGGED_COUNT_2.png"​
This is the mint id for the collection that you intend to enable with Boots.
This is an optional path to an image file used when creating the collection for items. If this is not set, the first bodyPartLayer trait image file will be used.
This is the mint that will be used to represent the master PlayerClass for Boots. You can place the collectionMint here if you control it and are the UpdateAuthority but if you don't have those things - no worries as they are not required. You can leave it null, and we will make one automatically when the script runs.
Raindrops allows each NFT in principle to have multiple items and players defined on top of it through the use of indexing. Therefore, for each Boots collection, you must label which index you decided to use for the items and the NFTs themselves.
Raindrops allows each NFT in principle to have multiple items and players defined on top of it through the use of indexing. Therefore, for each Boots collection, you must label which index you decided to use for the items and the NFTs themselves.
This is where the CLI will store the class information for the Items class of the collection. This is automatically populated by the application, so just leave it at null
to start. In general, this specifies the abstract top level class of the ItemsCollection. The ItemClasses for the collection inherit their properties from this ItemsCollection, and then each Item inherits properties from its ItemClass. For more information on how Items are composed, have a look at that section of the Raindrops documentation.
This is where the application will store the class information for the collection's main class. This is populated by the application.
This will be the name of the collection NFT for the class. When the application creates the collection NFT for Boots, this is the name it will apply to the Collection NFT.
This is the public key for the Collection NFT of the items for the collection. This is populated by the application.
This step creates the Items collection and stores the information needed in the configuration file.
To run, issue the following command:
The command line parameters are as follows:
The output of the help option is the following:
After this command is run, the existingCollectionForItems
entry of the configuration file will be updated with the item class definition information.
Once this command finishes successfully, you can move on to the next step.
This step creates the classes for the individual items that belong to the collection.
To run, issue the following command:
The command line parameters are as follows:
The output of the help option is the following:
After this command is run, classes for each of the items that you specified in the configuration are created and populated in the configuration file, ready for your NFTs to be equipped.
Once this command finishes successfully, you can move on to the next step.
This step uses the configuration file built from the previous three steps to build and equip player classes for your collection NFTs.
To run, issue the following command:
The command line parameters are as follows:
The output of the help option is the following:
PRO TIP: You can break up the running of Step 4 into parallel processes. To do this, do the following:
1) Use an external method to generate your mint list.
2) Divide the mint list into 4 separate lists.
3) Create 4 copies of your configuration file
4) Set the following keys in each of your configuration files:
5) Open up 4 separate terminals and navigate to the folder with your configuration files and wallet. Set up the boot-up step_four_create_players
command in each terminal with a different configuration file for each, like so:
6) Once each job completes, open up the configuration file for that job and update the "runDuplicateChecks" key to true, and then run the job once more to remove excess items.
After you finish "Step 4 - Create Players" and it successfully completes, you can validate using the Raindrops CLI. See the next section for an example of how to verify your Player class.
option | description |
---|---|
Id | Scope | values example | Description |
---|---|---|---|
character | replace with |
---|---|
option | description |
---|
option | description |
---|
-e, --env
Which environment to use (devnet, testnet, mainnet-beta, localnet)
-r, --rpc-url
The RPC to use to connect to Solana. This should be a paid RPC, as this application causes heavy use to the RPC.
-l, --loglevel
The log level to use (all, trace, DEBUG, info, warn, error, fatal, off)
-k, --keypair
The keypair which is the update authority for the NFT collection
-cp, --config-path
The path to the configuration file
-h, --help
Get help with this command
0
List of NFTs
["GiD1ex1VyEXALniJJvL6KcgQ5mGB4BLzvjM1bQzUXs1T","Cu89qmdY4a6dfUPa9sVZT6W9BTXqZq18d51A5zFGZuG7","4ahpNZJ7pVS85f34ErDXwRmckhmbmvT52ed6kr6J66ZA","ENpscuTJCYReY3NnNcRBJnC7S6pAYbxSfAdcdnJjvxN5","G2fWcgYP49p4J1Db8Jnj3KBJrg1fp1DsfzBo4uJb8u4j"]
A list of NFTs, specified as Mint Ids in the values key
1
Candy Machine Id
["2crTqcmVJVMW6b5z6NEs9HdsKmVc4zDDE2FucNg98kSN"]
Use the Candy Machine Id (i.e. First Creator) to define the collection
2
Collection Id
["CcLrhgWz29JRd3TgxSNEeWwMfMoX9Cz1NQXh27aWUMMx"]
Use the Collection NFT Mint Id
whitespace (spaces, tabs, etc)
"_"
pipe (|)
":"
colon (:)
""
forward slash (/)
":"
-e, --env | Which environment to use (devnet, testnet, mainnet-beta, localnet) |
-r, --rpc-url | The RPC to use to connect to Solana. This should be a paid RPC, as this application causes heavy use to the RPC. |
-l, --loglevel | The log level to use (all, trace, DEBUG, info, warn, error, fatal, off) |
-k, --keypair | The keypair which is the update authority for the NFT collection |
-cp, --config-path | The path to the configuration file |
-h, --help | Get help with this command |
-e, --env | Which environment to use (devnet, testnet, mainnet-beta, localnet) |
-r, --rpc-url | The RPC to use to connect to Solana. This should be a paid RPC, as this application causes heavy use to the RPC. |
-l, --loglevel | The log level to use (all, trace, DEBUG, info, warn, error, fatal, off) |
-k, --keypair | The keypair which is the update authority for the NFT collection |
-cp, --config-path | The path to the configuration file |
-h, --help | Get help with this command |
-e, --env | Which environment to use (devnet, testnet, mainnet-beta, localnet) |
-r, --rpc-url | The RPC to use to connect to Solana. This should be a paid RPC, as this application causes heavy use to the RPC. |
-l, --loglevel | The log level to use (all, trace, DEBUG, info, warn, error, fatal, off) |
-k, --keypair | The keypair which is the update authority for the NFT collection |
-cp, --config-path | The path to the configuration file |
-h, --help | Get help with this command |