[Kpt-Ahab] Candles Slot MachineHow the Game Works
Candles Slot Machine** is an automated slot machine simulation that runs directly on the PulseWire chart.
Each new game starts with 100 credits:
1. Disable Autoplay to reset the game and change the settings.
2. Set the maximum number of spins under Autoplay bars.
3. Select the wager per spin under Bet per spin.
4. Enable Autoplay to start the game.
5. Exactly one spin is completed at each confirmed close of a real-time bar.
The wager is deducted from the available credits on every spin. Three symbols are then generated, and any applicable payout is calculated.
A game ends when:
* the selected maximum number of spins has been reached, or
* there are not enough credits remaining for the next wager.
The final result remains visible for three fully completed bars. The next game then starts automatically with another 100 credits. The cumulative session statistics remain active until Autoplay is disabled, which resets the entire session.
Symbols and Payouts
Each symbol has its own probability:
* **Cherry:** 30%
* **Lemon:** 25%
* **Bell:** 18%
* **Star:** 13%
* **Seven:** 9%
* **Diamond:** 5%
Two matching symbols pay x1. This only returns the original wager, resulting in a net outcome of zero for that spin.
Three matching symbols pay:
* **Cherry:** x6
* **Lemon:** x8
* **Bell:** x12
* **Star:** x20
* **Seven:** x40
* **Diamond:** x100
Three Diamonds form the jackpot.
The payout model has a theoretical RTP of 92.53%. This value represents the expected long-term payout relative to all credits wagered. It does not guarantee any particular outcome for an individual game or a short session.
Random Generation
The reel symbols are generated using a combined pseudo-random calculation. The script uses, among other inputs:
* runtime random values
* individual game and spin numbers
* confirmed OHLCV data from the current bar
* bar closing time and bar index
Market data is used exclusively as additional entropy for the random-generation process. It is not evaluated as a trading signal, and there is no intended relationship between price direction and game results.
The script is not designed to simulate historical spins retroactively. New spins are executed exclusively on confirmed real-time bars.
Game Speed
The speed of the game depends directly on the selected chart timeframe because one spin is completed per confirmed bar close.
Examples:
* On a 1-minute chart, approximately one spin is completed per minute.
* On a 15-minute chart, approximately one spin is completed every 15 minutes.
* On a 1-hour chart, approximately one spin is completed per hour.
Exchange closures, missing market updates, or unconfirmed bars delay the next spin accordingly.
Indicator
ChessPlay real, full games of Chess against the computer , live on your chart. The first playable chess on PulseWire.
🟩 HIGHLIGHTS
⭐ Genuine independent gameplay - infinite different games possible.
⭐ The computer ranked over 1200 at Blitz across 100+ rated games on a popular online chess website.
⭐ Optional trash talk from the computer.
⭐ Play as White or Black, with the board flipped so your pieces sit at the bottom.
⭐ The computer thinks and responds fast.
⭐ Only legal moves are allowed.
⭐ The computer knows all the rules of chess including en passant, castling, check, checkmate, and the threefold repetition draw.
⭐ The to and from squares of the most recent move from both sides are highlighted on the board.
⭐ Captured pieces are displayed; just-captured pieces are highlighted.
⭐ The colour scheme adjusts to light or dark chart backgrounds.
⭐ The computer sometimes resigns if it's about to lose, and sometimes lets you complete the win 🎉
🟩 SET UP THE FIRST GAME
Add the script to a chart with some history (it warns you if there's not enough); any timeframe, doesn't matter if the market is open or not.
The script opens on a separate pane below the main chart, appearing cut-off.
1. Don't panic.
2. Double-click the chart background to maximise the Chess pane and hide your chart (double-click again to get your chart back).
3. As an alternative, you can click the three dots next to the Chess script name and choose Move to > Existing pane above and then Hide the chart symbol.
4. The default settings should be good to get you started playing, although you might need to adjust the square height and width so that the chess board looks nicely square on your particular chart.
🟩 PLAY THE GAME
Let's play.
1. Open the indicator Settings dialog and move it to the side so you can see the board.
2. Type your move into the Moves text field. Use coordinate notation: `e2e4`, `g1f3`, `e7e8q`, etc.
3. Don't click OK , 'cos then you'll have to re-open the Settings. Instead, hit Enter . This makes the script pick up the changed text input.
4. The computer thinks a little (on my system, almost instantly) and then announces its move. It will say something like `Add my move d7d5 to the Moves input field`. The table cell goes orange.
5. Type that move into the Moves input field and hit Enter . The cell's orange colour disappears, and it tells you that it's your move. If you have trash talk on, it might comment about your move or its move.
If you enter an illegal move, the computer will tell you. It will try to help you if it recognises what you might have meant.
If you enter a move wrong, you can just delete it and press Enter and the game resumes from that point.
To save a game or show it to someone else with the same Chess script loaded, just copy the text out of the Moves input field (you'll need Replies: Deterministic set to ensure it makes the same next move).
Have fun! The computer will joke around with you even as it beats you (or you beat it).
🟩 RELOAD THE CHART TO PLAY THE NEXT GAME
To ensure that the computer can (if it wants) play different moves against the same position next game, leave Replies set on Random, and save and reload the board in between games.
Note that moves that are already entered are not changed. Only a pending move - one that the computer announced but you haven't yet typed in - can change if you reload the chart or change input values, and only if Replies: Random is selected in the settings.
🟩 ALL THE SETTINGS
Here are all the settings and what they do.
Moves : Holds your moves and the computer's moves. You can separate moves with a comma or a space or a new line. Only a new line, or some other change to the settings, triggers a script refresh and another move.
Play as : Choose who you want to play as. The board flips so that your pieces are always closest to you.
Thinking : Choose Deep so that the computer uses all of its tiny brain against you. Or Quick if you feel that it's responding too slowly or you run into timeout errors.
Replies : Choose Random so that the computer can play different moves against the same position next game (requires a chart reload to clear cache). It often still plays its favourite move but if it has two favourites, it can also choose between them. Choose Deterministic so that the computer always plays the same move given the same position (move sequence), even on a different chart, tab, or after a reload. This is useful for saving games or playing through saved games. For casual play, choose Random . Note : If you change any inputs to a new combination, the computer might choose a different reply if Random is selected.
Trash Talk : Enable this setting so the computer can misquote pop culture references at you.
Board : Move the board to the left, right, or centre.
Piece size : Make the pieces more bigger or smallerer.
Square width, height : Adjust the percentage sizes so that the squares look, well, square. The right ratio depends on your monitor.
Calculated Bars : This setting is precautionary to prevent any slowdown on long charts. Leave this at the default.
🟩 CREDITS
Thanks to @The_Peaceful_Lizard for discussions all that time ago about whether gameplay is possible in Pine.
Thanks to my beta testers for valuable usability feedback.
🟩 HOW TO CODE GAMEPLAY IN PINE
Turn-based gameplay as we know it is almost impossible. To play a game you need to make a move. So you need to tell the script something. All the possible ways to interact with a script are:
- Changing an input value (including interactive `input.time()` and `input.price()` lines).
- A value output from another script changing, if the consuming script reads it using `input.source()`.
- Scrolling or zooming the chart, if the script uses `chart.left_visible_bar_time()` or `chart.right_visible_bar_time()`.
- Changing the chart symbol or timeframe.
The latter two are not informative enough to build a game move from. And in any case, any change from this list reloads the script.
What happens when the script reloads? It forgets everything . This is actually a good thing, and by design, because a chart indicator needs to read from bar zero again if any of its inputs change, so that it can do all its calculations again and make sure they are accurate with the new settings. However, it means that there is nowhere to keep the game state :
- All variables reset, even `var` and `varip` ones.
- All drawings, plots, shapes, etc disappear.
- Pine cannot write to any external data source.
- Logs start from zero.
The only thing that persists is the most recent input values.
This means that the entire game state must be deterministically derivable from the values of inputs. Practically speaking, you must enter both your move and the computer's reply into inputs. That's the trick: the board is not stored between edits, it is re-derived from the move record (the computer checks ALL moves again, every move, that they are legal).
This pattern is actually already demonstrated in the only example of true gameplay in Pine that I was able to find: "Tic Tac Toe (For Fun)" by the Wizard @LonesomeTheBlue
🟩 HOW TO MAKE CHESS POSSIBLE IN PINE
The problem with chess is that there are so many possible moves that trying to foresee the responses to your move and the responses to that move and so on quickly becomes computationally impossible. Especially in a lightweight scripting language like Pine, which has limits on how long a script can take to run a loop or perform all its calculations.
The main thing you need to do is narrow it all down . So in building this thing from scratch, I started with some heuristics. What are some patterns when you play chess? If you're in check, you have to get out. If you're attacked, you defend. If you still have minor pieces on the back rank, you should probly get them out. And so on.
I quickly realised that not only did these rules hugely narrow down the number of things you need to calculate, but they stack in order of importance . The number one rule, for example, is: if you can win the game this move, you should. Nothing else can go before that. Developing your pieces, by contrast, comes somewhere at the back of the queue. And the others fall in line in between.
Another thing that comes fairly cheap is knowing the openings . I was always too lazy to memorise chess openings, but that's not a problem for a computer. I also figured that nailing the opening would put my engine in a good place for the midgame, and maybe cover up some weaknesses. Many of the rules are pitched slightly aggressive for the same reason 😆
🟩 MY LADDER
When you put a bunch of rules in priority order, you get a ladder .
SPOILER: If you want to enjoy a fresh game against the script, stop reading and play. Going further will give you insight into how it thinks (or avoids thinking) and allow you to beat it more easily.
Here's my chess ladder:
1. Mate in one .
2. Opening book .
3. Avoid checkmate .
4. Defence .
5. Win material .
6. Safe check .
7. Exchange when ahead .
8. Endgame .
9. Develop .
10. Any other safe move .
When you follow this ladder in order, it turns out, it looks quite a lot like you're playing chess. After I'd finished the script I found out that some very early chess engines did something similar (they likely had far weaker performance than mine), but modern ones function mainly by crunching predictions and even the most handicapped Stockfish engine is still stronger than this script.
On top of the ladder, you do need to layer in a little bit of actual looking ahead, or the engine makes terrible blunders. And you need to constrain that lookahead in turn with its own heuristics, so that you only map out a few moves and not an exponential number.
And there is a lot, lot more after that, like how we value pieces (we will deliberately lose material in an exchange when we're up big, because it hurts our opponent more), how we avoid forks, how we avoid repeating the same moves, and so on.
Still this is all smoke and mirrors - the engine doesn't really understand what makes a good position, or a good attack, or an elegant defence. It just does stuff.
🟩 HOW THIS SCRIPT WORKS END TO END
Here's what happens when you type a move and hit Enter:
Parse (bar zero). The input move text becomes board coordinates (via the ChessCore library). The tidied-up record also produces the random seed (via ChessAI), and the opening book (ChessBook) and the trash-talk banks (ChessTalk) get built.
Replay (one bar per move). For each move in the record, in order: generate every legal move in the current position, check that the next typed move is one of them, and if so apply it to the board. Along the way it collects captured pieces, watches for Game Over, and takes a fingerprint of each position so it can spot a threefold repetition. All ChessCore.
Prepare (one bar). If it's now the computer's turn: generate ALL its legal moves (ChessCore), note how well defended each move's landing square is, and flag moves that weaken the king's cover or just undo the previous move (ChessAI).
Foresee (up to three bars per candidate move). Score every potential move by how its story ends, in material: the opponent's best captures played all the way down the exchange, his checks, his quiet threats. The ChessAI library plays the stories out on ChessCore scratch boards.
The ladder (one rule per bar). Try the ten rules top down. The first that fires chooses the move. The scores from the foresee veto the doomed candidates in every rule, and break ties in some. ChessAI does all this, and rule 2 reads the ChessBook openings.
Done. The live bar draws the board and the status row announces the computer's move for you to type in. The live bar computes nothing - it only reads what the historical bars decided. The main Chess script draws, and any one-liners came from ChessTalk's banks.
Then you add its move to yours, hit Enter, and the entire thing runs again from bar zero: approves every past move, rebuilds the whole board, and chooses the next reply.
🟩 ARCHITECTURAL LESSONS
There are some things we did here that apply also to non-chess Pine scripts.
✨ "Library-first" design
Every large chunk was designed from the beginning to be its own library:
- Chess is the user-facing script that imports all the libraries.
- ChessAI decides the next move.
- ChessBook holds the openings.
- ChessCore does rules, the board, and what's legal.
- ChessTalk stores the trash talk.
Some libraries only hold data, and this split of calculations and data allows us to, for example, add more talk lines without republishing other libraries.
The main script and libraries together total ~5,000 lines, far too much to be manageable for a single script. Using libraries keeps everything organised and makes such a complex script possible.
Library-first design keeps you in control, as opposed to being forced to refactor functions into libraries when a script gets too big.
✨ Split work across bars
We do the work across historical bars, one small step per bar, so the live bar only has to draw the finished board. This prevents any one bar exceeding any timeouts. The ladder architecture makes this quite natural. For robustness, each stage declares its own completion, rather than using a hardcoded number of bars. We predict how many bars we'll need and warn if there's not enough. This pattern can help scripts with heavy calculations stay within budget.
✨ Draw once
We do all the calculations during historical bars and draw the board only on the last bar. In general, separating calculations from drawing is a good idea.
✨ Seeded randomness
If you want a random result (technically, pseudorandom) in Pine you can use `math.random()`. This returns a different number each time. We use random numbers to choose between equally promising options for the computer's moves.
However, sometimes you want a reproducible random result. You want the same random number each time the script runs. Fortunately, `math.random()` can take a `seed` parameter, and if this seed is the same, then the sequence of random numbers is the same.
For chess, the computer's choice of move must remain stable and not change to something else on the next tick of a realtime bar (seeing this happen in testing was quite a surprise). So we derive a seed from the move record . This means that for any given game, the computer's move is both random and repeatable. This helps a lot with testing.
For real games though, we want the user to be able to play the same moves next game and get a different reply from the computer (potentially; remember the computer can't remember what it did in any previous game). So for this reason, if Replies is set to Random, we also mix the script's loading time into the random seed (and each new move loads the script again). Reloading the chart now gives a new stable random sequence even for the same moves.
Understanding seeded randomness can be necessary for some scripts to use variety properly.
✨ Objects and library hierarchy
Libraries can import each other, but not in a circular way. Our lowest-level library declares object types, for example, for moves, but doesn't put data in them; the higher libraries do that.
When a more foundational library needs data that a higher-level library creates, a good pattern is for the lower library to create an object with fields that the higher library fills in. This avoids having to maintain parallel arrays so they don't get out of synch. Indicator
Public_Library_ChessTalkThis is where the Chess script keeps its trash talk. The library stores every line the computer can say, and decides when it speaks and which line it picks. It imports nothing, knows nothing about chess, and never calls `math.random()`.
There are eight kinds of occasion: the computer won material, it lost material, it promoted, it's still in its opening book, the game just started, it wins, it loses, or the game ends in a draw. Each occasion fires at its own rate, so the computer needles you now and then rather than commenting on every move. Every decision comes from arithmetic on a seed boiled down from the moves played so far, which means the same game always says the same lines, however many times you reload, and a chosen line can't flicker between ticks.
We pass the {piece} token in so that a line can name its victim ("Mmm... free {piece}." becomes "Mmm... free knight."), and per-line filters keep the puns honest - the "good knight" gag only fires when a knight actually dies. A no-repeat rule stops a category saying the same line twice in a row. The banks run to 97 lines of misquoted pop culture.
The `buildTalkState()` function packs the banks, the rates, the no-repeat memory and the wounded detection into one object, so the consumer holds one variable instead of fifteen. The consumer spots the occasion while it replays the game, asks this library for a line, and stores what it gets. The live bar only reads.
See the Chess script for the backchat in action:
Library
Public_Library_ChessBookThis library holds the opening book for the Chess script. It lives apart from the brain (ChessAI) so the openings can grow without republishing the logic. It imports nothing and contains no logic of its own beyond building the map.
Each entry pairs the moves played so far (both sides' moves, lowercase, one space between) with our reply, written the same way - so the key "e2e4 e7e5" answers with "g1f3". Some entries offer several replies separated by "|", and the consumer picks between them with its game seed, so back-to-back games can open differently. The empty-string key holds White's very first move.
We use a map because the book question is exactly a lookup: given the moves played so far, what do we reply? Simply query the canonical move string as the map key and if we get a reply that's our move in response.
Pine maps can't hold arrays as values, which is why several replies pack into one "|"-separated string. Of course we could define a UDT that contains an array, but it's overhead. The trade-off of keying by move sequence rather than by position is that an unusual move order into a known position misses the book - the cost is an early exit to the ladder, never a wrong move, and in exchange every entry in the source reads as a real game you can play through.
The book holds enough entries for every common defence and sideline on both sides, deeper main lines, and wider choices in some of them.
This split of data from calculation is worth using for non-chess scripts: when a big lookup table and the logic that reads it live in separate libraries, the table can grow on its own release schedule.
See the Chess script to play the book in a real game: Library
Public_Library_ChessAIThis library is the brain of the Chess script: a small chess opponent built on the ChessCore rules engine.
It is not a search engine. It is a ladder of ten rules that looks at one position, tries the rules in order, and plays the first that fires:
1. Mate in one
2. Opening book
3. Avoid checkmate
4. Defence
5. Win material
6. Safe check
7. Exchange when ahead
8. Endgame
9. Develop
10. Any other safe move
🟩 THE FORESEE
Before the ladder runs, a foresee stage takes every legal move and adds to its object its most likely material outcome. This score comes from the opponent's best replies to our move, and a few captures after that. We look at the opponent's best captures, his checks, his most menacing quiet threats, and what happens if we don't take. We also look briefly whether two checks in a row force mate. Deep thinking follows more replies and reads six half-moves.
The score works mostly as a veto. From the list of possible moves for a ladder stage, we reject the ones that end in us being checkmated. When every legal move walks into one, we toss a coin to decide between playing the least-bad move and resigning.
🟩 KEEPING A WON GAME WON
If we are winning we want to win, not draw. While ahead on material, the quiet rules refuse any move that recreates a position the game has already seen, so it can't shuffle a rook between two good squares forever. And the foresee prices a stalemate at minus the lead it would throw away, so the winning side sidesteps the trap while the losing side, correctly, steers toward it. The endgame rule gives the ladder actual technique (push passers, rook to the seventh, king up to escort) to try to win.
🟩 DETERMINISM
No `math.random()` call decides anything on its own. The first five rules always give the same answer for a position. The last five pick from their pools with a seed the consumer supplies, derived from the game record. Variety between games comes from the consumer script mixing a clock reading into the seed, not from the library.
🟩 PROCESS FLOW
The exported functions are called in a certian order for each position:
ChessCore generates the legal moves.
`annotateMoves()` counts the attackers and defenders on every move's landing square, and notes the cheapest attacker. Every safety test the rules make reads these three numbers.
`filterPromotions()` and `classifyMoves()` trim pointless pawn promotions and flag moves that make the king's cover worse or that just undo the previous move.
The foresee adds a score to each candidate move: `foreseePrepare()` starts the story, `foreseeFinishCaptures()` follows the capture lines, and `foreseeFinishRest()` follows the checks and quiet threats. The consuming script spreads these calls across chart bars so no single bar works too hard.
The ladder rules run in order, `ruleMateInOne()` down to `ruleFallback()`, and the first one that returns a move wins.
See the Chess script to play against this AI: Library
Public_Library_ChessCoreThe rules of chess as a reusable Pine engine. It doesn't display anything or think of any moves. It just defines what is legal. This is the foundation library of the Chess script, and it's built so that any Pine project needing real chess - a different engine, a puzzle board, a game replayer - can build on it without rewriting the rules.
🟩 WHAT IT DOES
Keeps the whole position in one object: the board, whose turn it is, castling rights, the en-passant target, the move clocks, and a cached king square for each side.
Generates every fully legal move for the side to move, including castling, en passant, and promotions. It checks first based on how the pieces can move, and then creates a copy board to test which moves keeps the king out of check - so pins, discovered checks and the en-passant edge cases all just work.
Applies a move to a position and does all the admin.
Detects checkmate, stalemate, and the automatic draws. For threefold repetition it provides position keys and a counting helper. The consumer keeps the key history, because that's the one draw that needs to remember earlier positions, and these functions deliberately hold no history of their own.
Parses a typed move record like "e2e4 e7e5" - junk-tolerant and case-insensitive, so "e2-e4, E7e5" parses the same - and rebuilds it as one tidy canonical string. The Chess consumer uses that canonical record as its opening-book key and its random seed.
🟩 DESIGN NOTES
The big thing here is the scan that answers "who attacks this square?", with variants that count the attackers and price the cheapest one.
Another important part is the test of whether a move is legal on a COPY board. One definition of "attacked" is shared by the move generator, the game-status detection and castling's transit-square tests, so they can never disagree about what check means.
Each generated move is an object whose scoring fields are declared here but filled in from outside - `foreseeScore` for an AI's look-ahead, plus two endgame scores. ChessCore itself never touches them. This declare-then-fill pattern is how a foundational library can carry data that a higher library computes, without circular imports and without parallel arrays.
Internally everything thinks in (row, column), where row 0 is rank 8 (Black's back rank) and column 0 is file "a". Square names like "e4" appear only at the edges.
🟩 WHAT TRUSTS WHAT
The exports look independent, but they lean on each other in ways worth knowing before you build on them:
`applyMove()` trusts its move and changes the position in place. It doesn't re-check legality, so feed it moves from `generateLegalMoves()` - or from `matchLegalMove()`, which picks the move matching typed coordinates out of that list and brings the filled-in castling and en-passant details with it. A move object you build by hand would miss those.
To ask "what if?" without committing, `copyPosition()` first and apply the move to the copy. The generator's own self-check filter runs on such scratch boards, and so does the whole ChessAI look-ahead.
`gameStatusOf()` spots mate, stalemate and the automatic draws, but not threefold repetition, which needs history this library deliberately doesn't keep. Push each new `positionKey()` onto your own array, then ask `isThreefoldRepetition()`. Push first, then ask.
The position caches each king's square so check tests don't scan the board, and `applyMove()` maintains that cache. If you build a custom position by writing to the board matrix yourself, set the king fields to match, or every check test will look at the wrong square.
See the Chess script for the whole thing playing human vs computer: Library
ATR Trailing Stops for Hyperliquid Spot + Perps [HYPR-run]DESCRIPTION:
A drop-in ATR trailing exits module. Four architectures that maximize
profit on winning trades using volume weighted volatility instead of fixed levels or
plain ATR. Built modular; the trailing logic is self-contained so you
can drop it into any existing indicator or strategy as a plug-and-play
exits block. Two independent stops (long/short), spot and perps.
DISCOVERING EDGE
ATR trailing exits are popular, everyone uses them, but this indicator doesn't just trail on volatility, it trails on meaningful volatility that very few people measure. In order to gain a persistent, mechanical edge in how winners run and protect capital on the trades that don't work, we explored a more meaningful expression of ATR trailing exits.
VOLUME-WEIGHTED ATR vs PLAIN ATR
Plain ATR treats every candle equally. Volume-weighted ATR will only expand stops when volume validates the volatility, preventing premature exits on noise and letting winners run further on real moves. Over hundreds of trades this single difference can compound in the spirit of letting winners run further, losers stay controlled versus fixed levels or vanilla ATR.
- Four modes (A3.1, A4.0, A4.1, A4.2) cover different trailing
behaviors: ratcheting, chandelier anchor, free-floating, and raw
baseline. All size stop distance from volatility, not fixed levels.
- Modular engine. The trailing logic is self-contained; drop it into
any existing indicator or strategy as a plug-and-play exits block.
- Alerts fire built-in JSON webhook payloads. Paste your webhook URL,
create the alert, execute on the exchange of your choice.
ATR MODES
A3.1: LinReg + plain ATR, no ratchet. The baseline. Linear regression
projects where price is heading, plain ATR sets the distance. Stop moves
freely in both directions. Use as a reference or when you want a raw
trailing stop.
A4.0: LinReg + VWATR + Efficiency Ratio + ratchet (default). The
all-rounder. Volume-weighted ATR discounts low-liquidity candles. The
Efficiency Ratio (Kaufman) measures trend quality: in a clean trend it
widens the stop to let price run; in chop it tightens. Ratchet floor
means the stop only moves in your favor.
A4.1: Chandelier + VWATR + ratchet + first-bar multiplier. Anchored to
the highest high (longs) or lowest low (shorts). First-bar multiplier
sets a tighter initial stop, then the standard multiplier takes over as
the ratchet locks in gains. Use when entering off key levels.
A4.2: LinReg + VWATR, no ratchet. Same as A4.0 but without ratchet
floor or Efficiency Ratio. Stop moves freely with the projection, giving
the trade room through consolidation at the cost of less locked profit.
FEATURES
- Four ATR architectures selectable via dropdown
- Volume-weighted ATR: low-liquidity candles contribute less
- Efficiency Ratio: tightens in chop, widens in trend (A4.0)
- Ratchet floor: stop only moves in your favor (A4.0, A4.1)
- First-bar multiplier for tighter initial protection (A4.1)
- Separate ATR lookbacks for longs and shorts
- Separate multipliers for longs and shorts
- Two-bar confirmation prevents single-wick fakeouts
- Gradient fill between price and stop (intensifies near danger)
- Stop line color shifts with ATR regime (green stable, amber expanding)
- Ratchet circles mark each new locked-in level on the stop line
- Dashboard: mode, stop price, gap %, ER, VWATR %, regime state
- Dark/light theme toggle for any chart background
- Independent long/short alert toggles
- No JSON snippet needed; close payload is built into the script
HOW IT WORKS
Volume-weighted ATR scales each bar's true range by its volume relative
to the lookback average. High-volume bars contribute more; thin candles
contribute less. This prevents low-liquidity spikes from inflating stop
distance. Separate lookbacks for longs (default 14) and shorts (default
26) reflect that crypto drops faster than it climbs.
The Efficiency Ratio measures directional movement versus noise on a 0-1
scale. It scales the ATR multiplier between 0.8x (choppy) and 1.2x
(trending), adapting stop width to market regime. Only active in A4.0.
Two-bar confirmation requires a confirmed close beyond the stop level.
A single wick does not trigger the exit. The cross must hold for at
least one additional bar close.
ALERTS
Close Long fires as SPOT (sell spot position). Close Short fires as
PERPS (close short; spot is long-only). Toggle each independently.
Alert payload is built into the script as JSON; works with any webhook
receiver that accepts market/ticker/position fields.
CREDITS
ATR: J. Welles Wilder (1978)
Efficiency Ratio: Perry Kaufman Indicator
Tic Tac Toe Game [TradeDots]Feeling bored with trading?
Time to inject some fun into your decision-making process with our Tic Tac Toe Indicator!
The Tic Tac Toe game transforms your chart into a competitive playground where trading pairs face off in a classic game of Tic Tac Toe.
HOW TO PLAY
Our Tic Tac Toe game invites you to pit one trading pair against another directly on your chart. Choose the competitors and watch as they battle it out in a traditional grid setup.
Navigate to settings and select your competitor pair.
Choose who kicks off the game.
After the close of each new bar, the algorithm will utilize the closing prices of both symbols. These numbers feed into a random number generator which alternates the turns for placing marks on the grid.
The game progresses until one pair aligns three consecutive symbols and wins, or the board fills up. After that, the game resets every three bars, offering continual engagement during active market hours.
MANUAL PLAYING MODE
Currently, due to PineScript's limitations, a fully interactive manual mode is not supported, as all previous data will be lost with each new user input, preventing the replication of existing game states.
However, users can input a sequence at the start, guiding the placement of symbols throughout the game.
Stay tuned for future updates! Indicator
Three (3)-Bar and Four (4)-Bar Plays StrategyThis strategy analyzes the three and four-bar play which is when price action has a wide igniting bar that has a full body, then one or two narrow bars which have a relatively equal high for long plays and relatively equal low for short plays, then a continuation bar. You should not take plays that will encounter resistance. The stop loss is placed for long plays below the 2nd bar (or 3rd bar for 4-bar play).
This is commonly used on 1m, 2m, 5m, and 10m charts.
Jared Wesley is one of the more notable traders that use this setup. You can edit as an input the start date, end date, igniting bar size, the body percentage of the igniting bar, the relative equality of the 2nd bar (and 3rd bar for 4-bar play) compared to the igniting bar, and profit multiplier. Strategy
Indicator
3B-Play Finder1 - Objective
2 - How to use (Theory)
3 - How to use (Grade System)
4 - Inputs
5 - Extras and Alerts
6 - Notes
Objective
This script aims to mark 3 Bar play patterns (both short and long) by identifying them on the chart, with an arrow pointing up from long and down for short. Aswell, setting alerts based on grade.
Following the base concept, this script comes with a "grade" system (A, B, C), which aims to classify 3B-Play according to input parameters.
2 - How to use (Theory)
The pattern is described by a wide range Ignite bar followed by a narrow resting bar.
Long
Given a 3 Bar play pattern, with a wide range green bar, the entry point should be above the ignite and narrow bar wicks (high) with stop loss set below the resting bar wick low but within ignite wide range bar.
The exit depends on the chart analysis, and there is no set rule for it.
Short
Similar to long but is with a wide range red bar and entry is defined on wick low and stop-loss at wick high.
3 - How to use (Grade System)
Since 3B-play come in all sort of shapes, some are "textbook" perfect, others a bit more "loose". I set a grading system, to differentiate each one.
The way the 3 Bar play quality is determined is based on the percentage size of the resting bar in relation to igniting bar size, starting from de close. An example of how this works is the following. Note: enabling the extra draws lines helps visually to adjust the grades to your preference.
4 - Inputs
3B Quality section
Enable/disable each grade.
CONTROL LONG / SHORT
Set the percentage values for each grade.
Extras
Enable/Disable extra plots.
5 - Extras and Alerts
This script comes with an extra section, enabling it, draws lines on the max and min values, as well, showing the values in text and the set percentage.
Also, you can set alerts based on the grade and short/long, note you should set the alert to bar close to avoid pre-trigger warnings.
6 - Notes
The script can be shorted a lot, by only looking for a single 3 bar play, to less than 30 lines.
Indicator
Indicator
