Webhook Starter Kit [HullBuster]
Introduction
This is an open source strategy which provides a framework for webhook enabled projects. It is designed to work out-of-the-box on any instrument triggering on an intraday bar interval. This is a full featured script with an emphasis on actual trading at a brokerage through the TradingView alert mechanism and without requiring browser plugins.
The source code is written in a self documenting style with clearly defined sections. The sections “communicate” with each other through state variables making it easy for the strategy to evolve and improve. This is an excellent place for Pine Language beginners to start their strategy building journey. The script exhibits many Pine Language features which will certainly ad power to your script building abilities.
This script employs a basic trend follow strategy utilizing a forward pyramiding technique. Trend detection is implemented through the use of two higher time frame series. The market entry setup is a Simple Moving Average crossover. Positions exit by passing through conditional take profit logic. The script creates ten indicators including a Zscore oscillator to measure support and resistance levels. The indicator parameters are exposed through 47 strategy inputs segregated into seven sections. All of the inputs are equipped with detailed tool tips to help you get started.
To improve the transition from simulation to execution, strategy.entry and strategy.exit calls show enhanced message text with embedded keywords that are combined with the TradingView placeholders at alert time. Thereby, enabling a single JSON message to generate multiple execution events. This is genius stuff from the Pine Language development team. Really excellent work!
This document provides a sample alert message that can be applied to this script with relatively little modification. Without altering the code, the strategy inputs can alter the behavior to generate thousands of orders or simply a few dozen. It can be applied to crypto, stocks or forex instruments. A good way to look at this script is as a webhook lab that can aid in the development of your own endpoint processor, impress your co-workers and have hours of fun.
By no means is a webhook required or even necessary to benefit from this script. The setups, exits, trend detection, pyramids and DCA algorithms can be easily replaced with more sophisticated versions. The modular design of the script logic allows you to incrementally learn and advance this script into a functional trading system that you can be proud of.
Design
This is a trend following strategy that enters long above the trend line and short below. There are five trend lines that are visible by default but can be turned off in Section 7. Identified, in frequency order, as follows:
1. - EMA in the chart time frame. Intended to track price pressure. Configured in Section 3.
2. - ALMA in the higher time frame specified in Section 2 Signal Line Period.
3. - Linear Regression in the higher time frame specified in Section 2 Signal Line Period.
4. - Linear Regression in the higher time frame specified in Section 2 Signal Line Period.
5. - DEMA in the higher time frame specified in Section 2 Trend Line Period.
The Blue, Green and Orange lines are signal lines are on the same time frame. The time frame selected should be at least five times greater than the chart time frame. The Purple line represents the trend line for which prices above the line suggest a rising market and prices below a falling market. The time frame selected for the trend should be at least five times greater than the signal lines.
Three oscillators are created as follows:
1. Stochastic - In the chart time frame. Used to enter forward pyramids.
2. Stochastic - In the Trend period. Used to detect exit conditions.
3. Zscore - In the Signal period. Used to detect exit conditions.
The Stochastics are configured identically other than the time frame. The period is set in Section 2.
Two Simple Moving Averages provide the trade entry conditions in the form of a crossover. Crossing up is a long entry and down is a short. This is in fact the same setup you get when you select a basic strategy from the Pine editor. The crossovers are configured in Section 3. You can see where the crosses are occurring by enabling Show Entry Regions in Section 7.
The script has the capacity for pyramids and DCA. Forward pyramids are enabled by setting the Pyramid properties tab with a non zero value. In this case add on trades will enter the market on dips above the position open price. This process will continue until the trade exits. Downward pyramids are available in Crypto and Range mode only. In this case add on trades are placed below the entry price in the drawdown space until the stop is hit. To enable downward pyramids set the Pyramid Minimum Span In Section 1 to a non zero value.
This implementation of Dollar Cost Averaging (DCA) triggers off consecutive losses. Each loss in a run increments a sequence number. The position size is increased as a multiple of this sequence. When the position eventually closes at a profit the sequence is reset. DCA is enabled by setting the Maximum DCA Increments In Section 1 to a non zero value.
It should be noted that the pyramid and DCA features are implemented using a rudimentary design and as such do not perform with the precision of my invite only scripts. They are intended as a feature to stress test your webhook endpoint. As is, you will need to buttress the logic for it to be part of an automated trading system. It is for this reason that I did not apply a Martingale algorithm to this pyramid implementation. But, hey, it’s an open source script so there is plenty of room for learning and your own experimentation.
How does it work
The overall behavior of the script is governed by the Trading Mode selection in Section 1. It is the very first input so you should think about what behavior you intend for this strategy at the onset of the configuration. As previously discussed, this script is designed to be a trend follower. The trend being defined as where the purple line is predominately heading. In BiDir mode, SMA crossovers above the purple line will open long positions and crosses below the line will open short. If pyramiding is enabled add on trades will accumulate on dips above the entry price. The value applied to the Minimum Profit input in Section 1 establishes the threshold for a profitable exit. This is not a hard number exit. The conditional exit logic must be satisfied in order to permit the trade to close. This is where the effort put into the indicator calibration is realized. There are four ways the trade can exit at a profit:
1. Natural exit. When the blue line crosses the green line the trade will close. For a long position the blue line must cross under the green line (downward). For a short the blue must cross over the green (upward).
2. Alma / Linear Regression event. The distance the blue line is from the green and the relative speed the cross is experiencing determines this event. The activation thresholds are set in Section 6 and relies on the period and length set in Section 2. A long position will exit on an upward thrust which exceeds the activation threshold. A short will exit on a downward thrust.
3. Exponential event. The distance the yellow line is from the blue and the relative speed the cross is experiencing determines this event. The activation thresholds are set in Section 3 and relies on the period and length set in the same section.
4. Stochastic event. The purple line stochastic is used to measure overbought and over sold levels with regard to position exits. Signal line positions combined with a reading over 80 signals a long profit exit. Similarly, readings below 20 signal a short profit exit.
Another, optional, way to exit a position is by Bale Out. You can enable this feature in Section 1. This is a handy way to reduce the risk when carrying a large pyramid stack. Instead of waiting for the entire position to recover we exit early (bale out) as soon as the profit value has doubled.
There are lots of ways to implement a bale out but the method I used here provides a succinct example. Feel free to improve on it if you like. To see where the Bale Outs occur, enable Show Bale Outs in Section 7. Red labels are rendered below each exit point on the chart.
There are seven selectable Trading Modes available from the drop down in Section 1:
1. Long - Uses the strategy.risk.allow_entry_in to execute long only trades. You will still see shorts on the chart.
2. Short - Uses the strategy.risk.allow_entry_in to execute short only trades. You will still see long trades on the chart.
3. BiDir - This mode is for margin trading with a stop. If a long position was initiated above the trend line and the price has now fallen below the trend, the position will be reversed after the stop is hit. Forward pyramiding is available in this mode if you set the Pyramiding value in the Properties tab. DCA can also be activated.
4. Flip Flop - This is a bidirectional trading mode that automatically reverses on a trend line crossover. This is distinctively different from BiDir since you will get a reversal even without a stop which is advantageous in non-margin trading.
5. Crypto - This mode is for crypto trading where you are buying the coins outright. In this case you likely want to accumulate coins on a crash. Especially, when all the news outlets are talking about the end of Bitcoin and you see nice deep valleys on the chart. Certainly, under these conditions, the market will be well below the purple line. No margin so you can’t go short. Downward pyramids are enabled for Crypto mode when two conditions are met. First the Pyramiding value in the Properties tab must be non zero. Second the Pyramid Minimum Span in Section 1 must be non zero.
6. Range - This is a counter trend trading mode. Longs are entered below the purple trend line and shorts above. Useful when you want to test your webhook in a market where the trend line is bisecting the signal line series. Remember that this strategy is a trend follower. It’s going to get chopped out in a range bound market. By turning on the Range mode you will at least see profitable trades while stuck in the range. However, when the market eventually picks a direction, this mode will sustain losses. This range trading mode is a rudimentary implementation that will need a lot of improvement if you want to create a reliable switch hitter (trend/range combo).
7. No Trade. Useful when setting up the trend lines and the entry and exit is not important.
Once in the trade, long or short, the script tests the exit condition on every bar. If not a profitable exit then it checks if a pyramid is required. As mentioned earlier, the entry setups are quite primitive. Although they can easily be replaced by more sophisticated algorithms, what I really wanted to show is the diminished role of the position entry in the overall life of the trade. Professional traders spend much more time on the management of the trade beyond the market entry. While your trade entry is important, you can get in almost anywhere and still land a profitable exit.
If DCA is enabled, the size of the position will increase in response to consecutive losses. The number of times the position can increase is limited by the number set in Maximum DCA Increments of Section 1. Once the position breaks the losing streak the trade size will return the default quantity set in the Properties tab. It should be noted that the Initial Capital amount set in the Properties tab does not affect the simulation in the same way as a real account. In reality, running out of money will certainly halt trading. In fact, your account would be frozen long before the last penny was committed to a trade. On the other hand, TradingView will keep running the simulation until the current bar even if your funds have been technically depleted.
Entry and exit use the strategy.entry and strategy.exit calls respectfully. The alert_message parameter has special keywords that the endpoint expects to properly calculate position size and message sequence. The alert message will embed these keywords in the JSON object through the {{strategy.order.alert_message}} placeholder. You should use whatever keywords are expected from the endpoint you intend to webhook in to.
Webhook Integration
The TradingView alerts dialog provides a way to connect your script to an external system which could actually execute your trade. This is a fantastic feature that enables you to separate the data feed and technical analysis from the execution and reporting systems. Using this feature it is possible to create a fully automated trading system entirely on the cloud. Of course, there is some work to get it all going in a reliable fashion. Being a strategy type script place holders such as {{strategy.position_size}} can be embedded in the alert message text. There are more than 10 variables which can write internal script values into the message for delivery to the specified endpoint.
Entry and exit use the strategy.entry and strategy.exit calls respectfully. The alert_message parameter has special keywords that my endpoint expects to properly calculate position size and message sequence. The alert message will embed these keywords in the JSON object through the {{strategy.order.alert_message}} placeholder. You should use whatever keywords are expected from the endpoint you intend to webhook in to.
Here is an excerpt of the fields I use in my webhook signal:
"broker_id": "kraken",
"account_id": "XXX XXXX XXXX XXXX",
"symbol_id": "XMRUSD",
"action": "{{strategy.order.action}}",
"strategy": "{{strategy.order.id}}",
"lots": "{{strategy.order.contracts}}",
"price": "{{strategy.order.price}}",
"comment": "{{strategy.order.alert_message}}",
"timestamp": "{{time}}"
Though TradingView does a great job in dispatching your alert this feature does come with a few idiosyncrasies. Namely, a single transaction call in your script may cause multiple transmissions to the endpoint. If you are using placeholders each message describes part of the transaction sequence. A good example is closing a pyramid stack. Although the script makes a single strategy.close() call, the endpoint actually receives a close message for each pyramid trade. The broker, on the other hand, only requires a single close. The incongruity of this situation is exacerbated by the possibility of messages being received out of sequence. Depending on the type of order designated in the message, a close or a reversal. This could have a disastrous effect on your live account. This broker simulator has no idea what is actually going on at your real account. Its just doing the job of running the simulation and sending out the computed results. If your TradingView simulation falls out of alignment with the actual trading account lots of really bad things could happen. Like your script thinks your are currently long but the account is actually short. Reversals from this point forward will always be wrong with no one the wiser. Human intervention will be required to restore congruence. But how does anyone find out this is occurring? In closed systems engineering this is known as entropy. In practice your webhook logic should be robust enough to detect these conditions. Be generous with the placeholder usage and give the webhook code plenty of information to compare states. Both issuer and receiver. Don’t blindly commit incoming signals without verifying system integrity.
Setup
The following steps provide a very brief set of instructions that will get you started on your first configuration. After you’ve gone through the process a couple of times, you won’t need these anymore. It’s really a simple script after all. I have several example configurations that I used to create the performance charts shown. I can share them with you if you like. Of course, if you’ve modified the code then these steps are probably obsolete.
There are 47 inputs divided into seven sections. For the most part, the configuration process is designed to flow from top to bottom. Handy, tool tips are available on every field to help get you through the initial setup.
Step 1. Input the Base Currency and Order Size in the Properties tab. Set the Pyramiding value to zero.
Step 2. Select the Trading Mode you intend to test with from the drop down in Section 1. I usually select No Trade until I’ve setup all of the trend lines, profit and stop levels.
Step 3. Put in your Minimum Profit and Stop Loss in the first section. This is in pips or currency basis points (chart right side scale). Remember that the profit is taken as a conditional exit not a fixed limit. The actual profit taken will almost always be greater than the amount specified. The stop loss, on the other hand, is indeed a hard number which is executed by the TradingView broker simulator when the threshold is breached.
Step 4. Apply the appropriate value to the Tick Scalar field in Section 1. This value is used to remove the pipette from the price. You can enable the Summary Report in Section 7 to see the TradingView minimum tick size of the current chart.
Step 5. Apply the appropriate Price Normalizer value in Section 1. This value is used to normalize the instrument price for differential calculations. Basically, we want to increase the magnitude to significant digits to make the numbers more meaningful in comparisons. Though I have used many normalization techniques, I have always found this method to provide a simple and lightweight solution for less demanding applications. Most of the time the default value will be sufficient. The Tick Scalar and Price Normalizer value work together within a single calculation so changing either will affect all delta result values.
Step 6. Turn on the trend line plots in Section 7. Then configure Section 2. Try to get the plots to show you what’s really happening not what you want to happen. The most important is the purple trend line. Select an interval and length that seem to identify where prices tend to go during non-consolidation periods. Remember that a natural exit is when the blue crosses the green line.
Step 7. Enable Show Event Regions in Section 7. Then adjust Section 6. Blue background fills are spikes and red fills are plunging prices. These measurements should be hard to come by so you should see relatively few fills on the chart if you’ve set this up as intended. Section 6 includes the Zscore oscillator the state of which combines with the signal lines to detect statistically significant price movement. The Zscore is a zero based calculation with positive and negative magnitude readings. You want to input a reasonably large number slightly below the maximum amplitude seen on the chart. Both rise and fall inputs are entered as a positive real number. You can easily use my code to create a separate indicator if you want to see it in action. The default value is sufficient for most configurations.
Step 8. Turn off Show Event Regions and enable Show Entry Regions in Section 7. Then adjust Section 3. This section contains two parts. The entry setup crossovers and EMA events. Adjust the crossovers first. That is the Fast Cross Length and Slow Cross Length. The frequency of your trades will be shown as blue and red fills. There should be a lot. Then turn off Show Event Regions and enable Display EMA Peaks. Adjust all the fields that have the word EMA. This is actually the yellow line on the chart. The blue and red fills should show much less than the crossovers but more than event fills shown in Step 7.
Step 9. Change the Trading Mode to BiDir if you selected No Trades previously. Look on the chart and see where the trades are occurring. Make adjustments to the Minimum Profit and Stop Offset in Section 1 if necessary. Wider profits and stops reduce the trade frequency.
Step 10. Go to Section 4 and 5 and make fine tuning adjustments to the long and short side.
Example Settings
To reproduce the performance shown on the chart please use the following configuration: (Bitcoin on the Kraken exchange)
1. Select XBTUSD Kraken as the chart symbol.
2. On the properties tab set the Order Size to: 0.01 Bitcoin
3. On the properties tab set the Pyramiding to: 12
4. In Section 1: Select “Crypto” for the Trading Model
5. In Section 1: Input 2000 for the Minimum Profit
6. In Section 1: Input 0 for the Stop Offset (No Stop)
7. In Section 1: Input 10 for the Tick Scalar
8. In Section 1: Input 1000 for the Price Normalizer
9. In Section 1: Input 2000 for the Pyramid Minimum Span
10. In Section 1: Check mark the Position Bale Out
11. In Section 2: Input 60 for the Signal Line Period
12. In Section 2: Input 1440 for the Trend Line Period
13. In Section 2: Input 5 for the Fast Alma Length
14. In Section 2: Input 22 for the Fast LinReg Length
15. In Section 2: Input 100 for the Slow LinReg Length
16. In Section 2: Input 90 for the Trend Line Length
17. In Section 2: Input 14 Stochastic Length
18. In Section 3: Input 9 Fast Cross Length
19. In Section 3: Input 24 Slow Cross Length
20. In Section 3: Input 8 Fast EMA Length
21. In Section 3: Input 10 Fast EMA Rise NetChg
22. In Section 3: Input 1 Fast EMA Rise ROC
23. In Section 3: Input 10 Fast EMA Fall NetChg
24. In Section 3: Input 1 Fast EMA Fall ROC
25. In Section 4: Check mark the Long Natural Exit
26. In Section 4: Check mark the Long Signal Exit
27. In Section 4: Check mark the Long Price Event Exit
28. In Section 4: Check mark the Long Stochastic Exit
29. In Section 5: Check mark the Short Natural Exit
30. In Section 5: Check mark the Short Signal Exit
31. In Section 5: Check mark the Short Price Event Exit
32. In Section 5: Check mark the Short Stochastic Exit
33. In Section 6: Input 120 Rise Event NetChg
34. In Section 6: Input 1 Rise Event ROC
35. In Section 6: Input 5 Min Above Zero ZScore
36. In Section 6: Input 120 Fall Event NetChg
37. In Section 6: Input 1 Fall Event ROC
38. In Section 6: Input 5 Min Below Zero ZScore
In this configuration we are trading in long only mode and have enabled downward pyramiding. The purple trend line is based on the day (1440) period. The length is set at 90 days so it’s going to take a while for the trend line to alter course should this symbol decide to node dive for a prolonged amount of time. Your trades will still go long under those circumstances. Since downward accumulation is enabled, your position size will grow on the way down.
The performance example is Bitcoin so we assume the trader is buying coins outright. That being the case we don’t need a stop since we will never receive a margin call. New buy signals will be generated when the price exceeds the magnitude and speed defined by the Event Net Change and Rate of Change.
Feel free to PM me with any questions related to this script. Thank you and happy trading!
CFTC RULE 4.41
These results are based on simulated or hypothetical performance results that have certain inherent limitations. Unlike the results shown in an actual performance record, these results do not represent actual trading. Also, because these trades have not actually been executed, these results may have under-or over-compensated for the impact, if any, of certain market factors, such as lack of liquidity. Simulated or hypothetical trading programs in general are also subject to the fact that they are designed with the benefit of hindsight. No representation is being made that any account will or is likely to achieve profits or losses similar to these being shown.
In den Scripts nach "THE SCRIPT" suchen
Weekly/Daily/Hourly/Minutes Colored Background IntervalsThis is my "Weekly/Daily/Hourly/Minutes Colored Background Intervals" assistant. I wouldn't describe it as an indicator, it just exhibits coloration of referenced periods of time with bgcolor() in Pine. With the arrival of 2021, I pondered the necessity of needing a visualization pre-2021 to visually recognize periodicity of market movements by the week, day, hour, or an adjustable period of minutes. While this script is simply generic, I hope you may find useful in your endeavors as a member on TradingView.
Explaining the script's usage, the "Minutes" input can be adjusted from anywhere between 5-55 minutes for only intraday. This can be modified to accommodate 90 minutes (1.5hrs) or any other minutes period desirable by tweaking certain numbers up to 1440. Minutes and Hourly backgrounds are disabled by default for most daily traders. Changing the input() code to `true` will provide them on by default when the script loads, if you choose that route. Each time periods background color is enable/disable capable. All of the colors are easily adjustable to any combination you can ponder for your visual acuity with the color swatch provided by input(type=input.color). The coloring can be "swapped" by input() depending on how you wish to start and end the day visually. I thought this would come in handy. The weekly background can have different starting points, whether it be Sunday, Monday, or any other day such as Friday for example.
The entire script's contents isn't intended for complete re-use as is for publicly published scripts. It's more along the lines of code that could be used to personally modify indicators you have, depending on the time frames you may actually be trading on. The code is basically modular, so you can use bits and pieces of it in your personally modified Pine Editor scripts that you wish to customize for yourself. I will say that the isXxx() functions are completely reusable in any script without any need for author permission inquiries from me, as easy as copy and paste. Those may come in handy for many folks. If you find them useful in certain circumstances, use isXxx() functions as you please. Day of the week detection by functions will have applications beyond my current intended use for them.
Of notable mention, this is a miniature lesson by example of how the new input(type=input.color) may be used. I'm also using `var` inside functions to aid in computational efficiency of the script runtime. The colors are permanently stored at the very beginning of the scripts operation inside the function and just reused from that point onward. Its a rare use case, but well suited for this scripts intention. Once again I have demonstrated the "Power of Pine" for developers of any experience level to learn from via code elegance.
When available time provides itself, I will consider your inquiries, thoughts, and concepts presented below in the comments section, should you have any questions or comments regarding this indicator. When my indicators achieve more prevalent use by TV members , I may implement more ideas when they present themselves as worthy additions. Have a profitable future everyone!
Ensemble Alerts█ OVERVIEW
This indicator creates highly customizable alert conditions and messages by combining several technical conditions into groups , which users can specify directly from the "Settings/Inputs" tab. It offers a flexible framework for building and testing complex alert conditions without requiring code modifications for each adjustment.
█ CONCEPTS
Ensemble analysis
Ensemble analysis is a form of data analysis that combines several "weaker" models to produce a potentially more robust model. In a trading context, one of the most prevalent forms of ensemble analysis is the aggregation (grouping) of several indicators to derive market insights and reinforce trading decisions. With this analysis, traders typically inspect multiple indicators, signaling trade actions when specific conditions or groups of conditions align.
Simplifying ensemble creation
Combining indicators into one or more ensembles can be challenging, especially for users without programming knowledge. It usually involves writing custom scripts to aggregate the indicators and trigger trading alerts based on the confluence of specific conditions. Making such scripts customizable via inputs poses an additional challenge, as it often involves complicated input menus and conditional logic.
This indicator addresses these challenges by providing a simple, flexible input menu where users can easily define alert criteria by listing groups of conditions from various technical indicators in simple text boxes . With this script, you can create complex alert conditions intuitively from the "Settings/Inputs" tab without ever writing or modifying a single line of code. This framework makes advanced alert setups more accessible to non-coders. Additionally, it can help Pine programmers save time and effort when testing various condition combinations.
█ FEATURES
Configurable alert direction
The "Direction" dropdown at the top of the "Settings/Inputs" tab specifies the allowed direction for the alert conditions. There are four possible options:
• Up only : The indicator only evaluates upward conditions.
• Down only : The indicator only evaluates downward conditions.
• Up and down (default): The indicator evaluates upward and downward conditions, creating alert triggers for both.
• Alternating : The indicator prevents alert triggers for consecutive conditions in the same direction. An upward condition must be the first occurrence after a downward condition to trigger an alert, and vice versa for downward conditions.
Flexible condition groups
This script features six text inputs where users can define distinct condition groups (ensembles) for their alerts. An alert trigger occurs if all the conditions in at least one group occur.
Each input accepts a comma-separated list of numbers with optional spaces (e.g., "1, 4, 8"). Each listed number, from 1 to 35, corresponds to a specific individual condition. Below are the conditions that the numbers represent:
1 — RSI above/below threshold
2 — RSI below/above threshold
3 — Stoch above/below threshold
4 — Stoch below/above threshold
5 — Stoch K over/under D
6 — Stoch K under/over D
7 — AO above/below threshold
8 — AO below/above threshold
9 — AO rising/falling
10 — AO falling/rising
11 — Supertrend up/down
12 — Supertrend down/up
13 — Close above/below MA
14 — Close below/above MA
15 — Close above/below open
16 — Close below/above open
17 — Close increase/decrease
18 — Close decrease/increase
19 — Close near Donchian top/bottom (Close > (Mid + HH) / 2)
20 — Close near Donchian bottom/top (Close < (Mid + LL) / 2)
21 — New Donchian high/low
22 — New Donchian low/high
23 — Rising volume
24 — Falling volume
25 — Volume above average (Volume > SMA(Volume, 20))
26 — Volume below average (Volume < SMA(Volume, 20))
27 — High body to range ratio (Abs(Close - Open) / (High - Low) > 0.5)
28 — Low body to range ratio (Abs(Close - Open) / (High - Low) < 0.5)
29 — High relative volatility (ATR(7) > ATR(40))
30 — Low relative volatility (ATR(7) < ATR(40))
31 — External condition 1
32 — External condition 2
33 — External condition 3
34 — External condition 4
35 — External condition 5
These constituent conditions fall into three distinct categories:
• Directional pairs : The numbers 1-22 correspond to pairs of opposing upward and downward conditions. For example, if one of the inputs includes "1" in the comma-separated list, that group uses the "RSI above/below threshold" condition pair. In this case, the RSI must be above a high threshold for the group to trigger an upward alert, and the RSI must be below a defined low threshold to trigger a downward alert.
• Non-directional filters : The numbers 23-30 correspond to conditions that do not represent directional information. These conditions act as filters for both upward and downward alerts. Traders often use non-directional conditions to refine trending or mean reversion signals. For instance, if one of the input lists includes "30", that group uses the "Low relative volatility" condition. The group can trigger an upward or downward alert only if the 7-period Average True Range (ATR) is below the 40-period ATR.
• External conditions : The numbers 31-35 correspond to external conditions based on the plots from other indicators on the chart. To set these conditions, use the source inputs in the "External conditions" section near the bottom of the "Settings/Inputs" tab. The external value can represent an upward, downward, or non-directional condition based on the following logic:
▫ Any value above 0 represents an upward condition.
▫ Any value below 0 represents a downward condition.
▫ If the checkbox next to the source input is selected, the condition becomes non-directional . Any group that uses the condition can trigger upward or downward alerts only if the source value is not 0.
To learn more about using plotted values from other indicators, see this article in our Help Center and the Source input section of our Pine Script™ User Manual.
Group markers
Each comma-separated list represents a distinct group , where all the listed conditions must occur to trigger an alert. This script assigns preset markers (names) to each condition group to make the active ensembles easily identifiable in the generated alert messages and labels. The markers assigned to each group use the format "M", where "M" is short for "Marker" and "x" is the group number. The titles of the inputs at the top of the "Settings/Inputs" tab show these markers for convenience.
For upward conditions, the labels and alert messages show group markers with upward triangles (e.g., "M1▲"). For downward conditions, they show markers with downward triangles (e.g., "M1▼").
NOTE: By default, this script populates the "M1" field with a pre-configured list for a mean reversion group ("2,18,24,28"). The other fields are empty. If any "M*" input does not contain a value, the indicator ignores it in the alert calculations.
Custom alert messages
By default, the indicator's alert message text contains the activated markers and their direction as a comma-separated list. Users can override this message for upward or downward alerts with the two text fields at the bottom of the "Settings/Inputs" tab. When the fields are not empty , the alerts use that text instead of the default marker list.
NOTE: This script generates alert triggers, not the alerts themselves. To set up an alert based on this script's conditions, open the "Create Alert" dialog box, then select the "Ensemble Alerts" and "Any alert() function call" options in the "Condition" tabs. See the Alerts FAQ in our Pine Script™ User Manual for more information.
Condition visualization
This script offers organized visualizations of its conditions, allowing users to inspect the behaviors of each condition alongside the specified groups. The key visual features include:
1) Conditional plots
• The indicator plots the history of each individual condition, excluding the external conditions, as circles at different levels. Opposite conditions appear at positive and negative levels with the same absolute value. The plots for each condition show values only on the bars where they occur.
• Each condition's plot is color-coded based on its type. Aqua and orange plots represent opposing directional conditions, and purple plots represent non-directional conditions. The titles of the plots also contain the condition numbers to which they apply.
• The plots in the separate pane can be turned on or off with the "Show plots in pane" checkbox near the top of the "Settings/Inputs" tab. This input only toggles the color-coded circles, which reduces the graphical load. If you deactivate these visuals, you can still inspect each condition from the script's status line and the Data Window.
• As a bonus, the indicator includes "Up alert" and "Down alert" plots in the Data Window, representing the combined upward and downward ensemble alert conditions. These plots are also usable in additional indicator-on-indicator calculations.
2) Dynamic labels
• The indicator draws a label on the main chart pane displaying the activated group markers (e.g., "M1▲") each time an alert condition occurs.
• The labels for upward alerts appear below chart bars. The labels for downward alerts appear above the bars.
NOTE: This indicator can display up to 500 labels because that is the maximum allowed for a single Pine script.
3) Background highlighting
• The indicator can highlight the main chart's background on bars where upward or downward condition groups activate. Use the "Highlight background" inputs in the "Settings/Inputs" tab to enable these highlights and customize their colors.
• Unlike the dynamic labels, these background highlights are available for all chart bars, irrespective of the number of condition occurrences.
█ NOTES
• This script uses Pine Script™ v6, the latest version of TradingView's programming language. See the Release notes and Migration guide to learn what's new in v6 and how to convert your scripts to this version.
• This script imports our new Alerts library, which features functions that provide high-level simplicity for working with complex compound conditions and alerts. We used the library's `compoundAlertMessage()` function in this indicator. It evaluates items from "bool" arrays in groups specified by an array of strings containing comma-separated index lists , returning a tuple of "string" values containing the marker of each activated group.
• The script imports the latest version of the ta library to calculate several technical indicators not included in the built-in `ta.*` namespace, including Double Exponential Moving Average (DEMA), Triple Exponential Moving Average (TEMA), Fractal Adaptive Moving Average (FRAMA), Tilson T3, Awesome Oscillator (AO), Full Stochastic (%K and %D), SuperTrend, and Donchian Channels.
• The script uses the `force_overlay` parameter in the label.new() and bgcolor() calls to display the drawings and background colors in the main chart pane.
• The plots and hlines use the available `display.*` constants to determine whether the visuals appear in the separate pane.
Look first. Then leap.
Bogdan Ciocoiu - Sniper EntryWhat is Sniper Entry
Sniper Entry is a set indicator that encapsulates a collection of pre-configured scripts using specific variables that enable users to extract signals by interpreting market behaviour quickly, suitable for 1-3min scalping. This instrument is a tool that acts as a confluence for traders to make decisions concerning current market conditions. This indicator does not apply solely to an asset.
What Sniper Entry is not
Sniper Entry is not interpreting fundamental analysis and will also not be providing out of box market signals. Instead, it will provide a collection of integrated and significantly improved open-source subscripts designed to help traders speculate on market trends. Traders must apply their strategies and configure Sniper Entry accordingly to maximise the script's output.
Originality and usefulness
The collection of subscripts encapsulated in this tool makes it unique in the Trading View ecosystem. This indicator enables traders to consider entry positions or exit positions by comparing similar algorithms at once.
Its usefulness also emerges from the unique configurations embedded in the indicator's settings, which are different from those of the original scripts.
This indicator's originality is also reflected in how its modules are integrated, including the integration of the settings.
Open-source reuse
I used the following open-source resources, which I simplified significantly and pre-configured for short term scalping. The source codes for the below are already in the public domain, including the following links listed below.
www.tradingview.com (open source)
(open source and generic algorithm)
www.tradingview.com (open source)
(open source)
(open source)
www.tradingview.com (generic MA algorithm and open source)
(generic VWAP algorithm and open source)
Scanner/Screener of Over 40 Coins Per Script I am very scatter-brained by nature and sporadic in my thought processes but if these benefit the community and ya'll ask for more perhaps I will get better and even out a tad....probably not....but you never know. Firstly, allow me to apologize to all the vet/more sophisticated coders out there whose eyes and brains might just be overly taxed due to my poor coding structure. Im just getting started for the first time in ANY sort of coding...so cut me a little slack. Also, if anyone sees any mistakes or the functionality is not as I proclaimed, PLEASE do let me know. In these past 12mo of me learning my 1st coding language (Pinescript) I would say that I have been intently focused on creating all types/sorts of scanners/screeners. Ive always hoped to be a benefit to the community as I was always SO grateful to those who have come before me that have led me to the little bit of progress I have made with Pinescript. This script is not necessarily something that should be traded with as it is just a thrown together example showing a scanner/screener whose results produce plot outputs (ie, Rate of Change / oscillators as well / etc) and how they can be used in the alert system so that only 1 alert has to be set per iteration of the script but more importantly how to use/scan/screen with over 40 coins per script. My intent is not to trick anyone here. So to be PERFECTLY CLEAR, more than 40 coins CAN in fact be screened/scanned from one script (here I am doing all of KUCOIN's Margin Coins...72 total I look at)...BUT...(heres the catch) it must be added to the chart however many times EQUAL to the amount of "sets" you have in your script. (Heres the limitation by TV) There cannot be more than 40 coins in each "set". The less coins you have per set, the quicker the script will startup and run, thus, the quicker alerts will be received if automating the process. Though, if you only have the free plan and can only have MAX 3 indicators per chart then the MAX you can screen at a time is 120 coins if you use 40 coins per set. So, this is the first one I would like to introduce. For this one your screener/scanner must be using some sort of plots as output that is being screened for. (original inspiration of ALL my variations mainly come from @QuantNomad, @daveatt, and @LonesomeTheBlue (and a few others I may be forgetting at the moment). Thanks for the inspiration through countless publications that ya'll have created for us in the community.
Some of my variations are more complex/elegant than others but there are MANY very different ones that I would like to share with the community. If you leave a comment and wonder why I have not responded but did so to every comment around yours...see if you are one of the individuals in this next few sentences...and if you are then perhaps someone else would like to waste their time responding to your comment...but basically, if you don't want to spend the time helping yourself by reading the title, description section, AND the comments section (at least scanning them) then I am MOST DEFINITELY not going to help you down your path of destruction that is most likely soon to be your blown-up trading account. I was called a "masochist" after asking for guidance on if its worth the headache to publish anything on TV bc there will NO DOUBT be comments that'll make me wish I didn't (ie. someone CLEARLY not reading the description (or seemingly even the title sometimes) bc they make a comment that has been explicitly addressed, or someone asking to rebuild the code compatible for another charting software or whatnot, or how about those asking if it repaints (this one is almost always addressed in the comments section but I can understand this question more than others as Im only 1 yr into learning any sort of coding for the first time in the beginning I saw people ask on EVERY script about if it repainted and it was worrisome at the lest (esp bc I didn't even understand what it was not so long ago, or my favorite...what TF it works best on...these people CLEARLY need not be trading yet if your still asking questions as such...Ill end it there). Point being, Ive got some truly VERY useful scripts that I want to share and as long as these people don't make me regret doing so in the beginning, then whats mine...will soon be yours. Though, I will take a little time between the releases.
YOU GUYS (TV and its community) ARE AWESOME (most of you anyways ;)
MUCH LOVE,
ChasinAlts
(1) INPUTS
Here is where the "sets" come in. I am looking at all of KUCOIN's Margin Coins (72 of them at least) so am splitting them up into 3 sets/iterations and a copy of the script must be added equal to amount of "sets" you have here. This is the ONLY workaround I have found to be able to scan/screen with more than 40 coins per script (due to TV's limitation of 40 Security Calls per script) ***So for everyone saying it's impossible scan more than 40 Coins per scipt...it' MOST DEFINITELY possible....BUT ONLY by adding this script multiple times on the chart and selecting 1 of each of the "sets" in the script settings via the chart window. To save the much needed room you must push each iteration of the script into 1 window and merging the scales of each into 1 scale(ie. "Scale A") within the settings of the script name on the chart(3 horizontal dots)
(2) FUNCTION
(2.1) COLORIDs
This is just to set up all my Colors of plots which are being matched with their respective labels. I have a diff color for each of the 72 coins Im plotting so Im telling the function, "depending on which set of coins I select...give me this color out of the colors I input later into the function"
(2.2) TICKERID CONSTRUCTION
I construct the tickerID this way so that the labels on my plots have only the Coin's name vs the label having the (Exchange Name):(Coin Name)(Base Pair Name). If you are using more than 1 Base pair (ie. XRP/BTC and XRP/USDT and XRP/ETH) OR more than 1 Exchange OR want your plots to show MORE THAN just the Trading Coin's name, then the tickerID MUST BE constructed differently
(2.3) SECURITY CALL & PLOT OUTPUT VARIABLES
If using a Higher Time Frame in Security Call then it MUST BE adjusted to permit or dissallow repainting if you so wish (BEYOND THE SCOPE OF THIS PUBLICATION so Do Your Own Researh). If your MAIN LOGIC is more complex than simply using a TV built-in function), THEN it MUST BE built into its own function outside of this function and called on within the "expression" slot of this Security Call OR can also be built into this function and called on in the "expression" slot of this Security call (BEYOND THE SCOPE OF THIS PUB SO DYOR). FURTHERMORE...when you are using a series(ie high/low/close/open/hl2/etc) / bar_index / time / etc that will be specific to the Coin/tickerID, then they MUST BE explicitly used within the "expression" slot of the Security Function when calling on your Main Logic or else it will pull the series/time/bar_index/etc from the Coin that the Chart is presently on (BEYOND THE SCOPE OF THIS PUB SO DYOR)
(2.4) PLOT LABEL
This is the Plot's Label that will be next to the end of the plot on the LAST bar_index. ***Notice in the "text" slot of the label I have "_coin" (without the quotes obviously)...this is where have JUST the Coin's name comes into effect on the label vs the (Exchange Name):(Coin Name)(Base Pair Name) which looks MUCH cleaner
(2.5) ALERT LOGIC / ALERT LABEL
Your alert logic need not be as complex as this... I just wanted to create a decent enough timing for this system and wanted to simply print the labels displaying which coin produced the alert at the same time the alerts would go off. Alert is set up to Trigger Bullish when the ROC is below the Threshold and _chg > _chg X=length of bars inputted in "Rising/Falling Length" setting and vise versa for Bearish Alerts. If _chg plot only goes past threshold for a VERY few amount of bars NOT providing enough time for initial Alert to trigger, then alert/label triggers on crossing of threshold back towards 0(zero). ONLY 1 alert needs to be set per script to be able to scan ALL 72 of the coins as I have them in this script. Timing of Alert is inline with the name label printed past the thresholds.
(3) VARIABLES FROM MAIN FUNCTION
This is the tuple of the Main Function that outputs the variables from 3 lines up to be able to plot the lines and color them according to the colors on the labels. *** As of now, we CANNOT plot from within the function so MUST BE done this way to produce the variables and colors needed. The plots are the ONLY thing in this script that cannot be executed from within the function
(4) LINE PLOTS
ALL output variables from our Main Function are used here for the line plots
Monte Carlo Range Forecast [DW]This is an experimental study designed to forecast the range of price movement from a specified starting point using a Monte Carlo simulation.
Monte Carlo experiments are a broad class of computational algorithms that utilize random sampling to derive real world numerical results.
These types of algorithms have a number of applications in numerous fields of study including physics, engineering, behavioral sciences, climate forecasting, computer graphics, gaming AI, mathematics, and finance.
Although the applications vary, there is a typical process behind the majority of Monte Carlo methods:
-> First, a distribution of possible inputs is defined.
-> Next, values are generated randomly from the distribution.
-> The values are then fed through some form of deterministic algorithm.
-> And lastly, the results are aggregated over some number of iterations.
In this study, the Monte Carlo process used generates a distribution of aggregate pseudorandom linear price returns summed over a user defined period, then plots standard deviations of the outcomes from the mean outcome generate forecast regions.
The pseudorandom process used in this script relies on a modified Wichmann-Hill pseudorandom number generator (PRNG) algorithm.
Wichmann-Hill is a hybrid generator that uses three linear congruential generators (LCGs) with different prime moduli.
Each LCG within the generator produces an independent, uniformly distributed number between 0 and 1.
The three generated values are then summed and modulo 1 is taken to deliver the final uniformly distributed output.
Because of its long cycle length, Wichmann-Hill is a fantastic generator to use on TV since it's extremely unlikely that you'll ever see a cycle repeat.
The resulting pseudorandom output from this generator has a minimum repetition cycle length of 6,953,607,871,644.
Fun fact: Wichmann-Hill is a widely used PRNG in various software applications. For example, Excel 2003 and later uses this algorithm in its RAND function, and it was the default generator in Python up to v2.2.
The generation algorithm in this script takes the Wichmann-Hill algorithm, and uses a multi-stage transformation process to generate the results.
First, a parent seed is selected. This can either be a fixed value, or a dynamic value.
The dynamic parent value is produced by taking advantage of Pine's timenow variable behavior. It produces a variable parent seed by using a frozen ratio of timenow/time.
Because timenow always reflects the current real time when frozen and the time variable reflects the chart's beginning time when frozen, the ratio of these values produces a new number every time the cache updates.
After a parent seed is selected, its value is then fed through a uniformly distributed seed array generator, which generates multiple arrays of pseudorandom "children" seeds.
The seeds produced in this step are then fed through the main generators to produce arrays of pseudorandom simulated outcomes, and a pseudorandom series to compare with the real series.
The main generators within this script are designed to (at least somewhat) model the stochastic nature of financial time series data.
The first step in this process is to transform the uniform outputs of the Wichmann-Hill into outputs that are normally distributed.
In this script, the transformation is done using an estimate of the normal distribution quantile function.
Quantile functions, otherwise known as percent-point or inverse cumulative distribution functions, specify the value of a random variable such that the probability of the variable being within the value's boundary equals the input probability.
The quantile equation for a normal probability distribution is μ + σ(√2)erf^-1(2(p - 0.5)) where μ is the mean of the distribution, σ is the standard deviation, erf^-1 is the inverse Gauss error function, and p is the probability.
Because erf^-1() does not have a simple, closed form interpretation, it must be approximated.
To keep things lightweight in this approximation, I used a truncated Maclaurin Series expansion for this function with precomputed coefficients and rolled out operations to avoid nested looping.
This method provides a decent approximation of the error function without completely breaking floating point limits or sucking up runtime memory.
Note that there are plenty of more robust techniques to approximate this function, but their memory needs very. I chose this method specifically because of runtime favorability.
To generate a pseudorandom approximately normally distributed variable, the uniformly distributed variable from the Wichmann-Hill algorithm is used as the input probability for the quantile estimator.
Now from here, we get a pretty decent output that could be used itself in the simulation process. Many Monte Carlo simulations and random price generators utilize a normal variable.
However, if you compare the outputs of this normal variable with the actual returns of the real time series, you'll find that the variability in shocks (random changes) doesn't quite behave like it does in real data.
This is because most real financial time series data is more complex. Its distribution may be approximately normal at times, but the variability of its distribution changes over time due to various underlying factors.
In light of this, I believe that returns behave more like a convoluted product distribution rather than just a raw normal.
So the next step to get our procedurally generated returns to more closely emulate the behavior of real returns is to introduce more complexity into our model.
Through experimentation, I've found that a return series more closely emulating real returns can be generated in a three step process:
-> First, generate multiple independent, normally distributed variables simultaneously.
-> Next, apply pseudorandom weighting to each variable ranging from -1 to 1, or some limits within those bounds. This modulates each series to provide more variability in the shocks by producing product distributions.
-> Lastly, add the results together to generate the final pseudorandom output with a convoluted distribution. This adds variable amounts of constructive and destructive interference to produce a more "natural" looking output.
In this script, I use three independent normally distributed variables multiplied by uniform product distributed variables.
The first variable is generated by multiplying a normal variable by one uniformly distributed variable. This produces a bit more tailedness (kurtosis) than a normal distribution, but nothing too extreme.
The second variable is generated by multiplying a normal variable by two uniformly distributed variables. This produces moderately greater tails in the distribution.
The third variable is generated by multiplying a normal variable by three uniformly distributed variables. This produces a distribution with heavier tails.
For additional control of the output distributions, the uniform product distributions are given optional limits.
These limits control the boundaries for the absolute value of the uniform product variables, which affects the tails. In other words, they limit the weighting applied to the normally distributed variables in this transformation.
All three sets are then multiplied by user defined amplitude factors to adjust presence, then added together to produce our final pseudorandom return series with a convoluted product distribution.
Once we have the final, more "natural" looking pseudorandom series, the values are recursively summed over the forecast period to generate a simulated result.
This process of generation, weighting, addition, and summation is repeated over the user defined number of simulations with different seeds generated from the parent to produce our array of initial simulated outcomes.
After the initial simulation array is generated, the max, min, mean and standard deviation of this array are calculated, and the values are stored in holding arrays on each iteration to be called upon later.
Reference difference series and price values are also stored in holding arrays to be used in our comparison plots.
In this script, I use a linear model with simple returns rather than compounding log returns to generate the output.
The reason for this is that in generating outputs this way, we're able to run our simulations recursively from the beginning of the chart, then apply scaling and anchoring post-process.
This allows a greater conservation of runtime memory than the alternative, making it more suitable for doing longer forecasts with heavier amounts of simulations in TV's runtime environment.
From our starting time, the previous bar's price, volatility, and optional drift (expected return) are factored into our holding arrays to generate the final forecast parameters.
After these parameters are computed, the range forecast is produced.
The basis value for the ranges is the mean outcome of the simulations that were run.
Then, quarter standard deviations of the simulated outcomes are added to and subtracted from the basis up to 3σ to generate the forecast ranges.
All of these values are plotted and colorized based on their theoretical probability density. The most likely areas are the warmest colors, and least likely areas are the coolest colors.
An information panel is also displayed at the starting time which shows the starting time and price, forecast type, parent seed value, simulations run, forecast bars, total drift, mean, standard deviation, max outcome, min outcome, and bars remaining.
The interesting thing about simulated outcomes is that although the probability distribution of each simulation is not normal, the distribution of different outcomes converges to a normal one with enough steps.
In light of this, the probability density of outcomes is highest near the initial value + total drift, and decreases the further away from this point you go.
This makes logical sense since the central path is the easiest one to travel.
Given the ever changing state of markets, I find this tool to be best suited for shorter term forecasts.
However, if the movements of price are expected to remain relatively stable, longer term forecasts may be equally as valid.
There are many possible ways for users to apply this tool to their analysis setups. For example, the forecast ranges may be used as a guide to help users set risk targets.
Or, the generated levels could be used in conjunction with other indicators for meaningful confluence signals.
More advanced users could even extrapolate the functions used within this script for various purposes, such as generating pseudorandom data to test systems on, perform integration and approximations, etc.
These are just a few examples of potential uses of this script. How you choose to use it to benefit your trading, analysis, and coding is entirely up to you.
If nothing else, I think this is a pretty neat script simply for the novelty of it.
----------
How To Use:
When you first add the script to your chart, you will be prompted to confirm the starting date and time, number of bars to forecast, number of simulations to run, and whether to include drift assumption.
You will also be prompted to confirm the forecast type. There are two types to choose from:
-> End Result - This uses the values from the end of the simulation throughout the forecast interval.
-> Developing - This uses the values that develop from bar to bar, providing a real-time outlook.
You can always update these settings after confirmation as well.
Once these inputs are confirmed, the script will boot up and automatically generate the forecast in a separate pane.
Note that if there is no bar of data at the time you wish to start the forecast, the script will automatically detect use the next available bar after the specified start time.
From here, you can now control the rest of the settings.
The "Seeding Settings" section controls the initial seed value used to generate the children that produce the simulations.
In this section, you can control whether the seed is a fixed value, or a dynamic one.
Since selecting the dynamic parent option will change the seed value every time you change the settings or refresh your chart, there is a "Regenerate" input built into the script.
This input is a dummy input that isn't connected to any of the calculations. The purpose of this input is to force an update of the dynamic parent without affecting the generator or forecast settings.
Note that because we're running a limited number of simulations, different parent seeds will typically yield slightly different forecast ranges.
When using a small number of simulations, you will likely see a higher amount of variance between differently seeded results because smaller numbers of sampled simulations yield a heavier bias.
The more simulations you run, the smaller this variance will become since the outcomes become more convergent toward the same distribution, so the differences between differently seeded forecasts will become more marginal.
When using a dynamic parent, pay attention to the dispersion of ranges.
When you find a set of ranges that is dispersed how you like with your configuration, set your fixed parent value to the parent seed that shows in the info panel.
This will allow you to replicate that dispersion behavior again in the future.
An important thing to note when settings alerts on the plotted levels, or using them as components for signals in other scripts, is to decide on a fixed value for your parent seed to avoid minor repainting due to seed changes.
When the parent seed is fixed, no repainting occurs.
The "Amplitude Settings" section controls the amplitude coefficients for the three differently tailed generators.
These amplitude factors will change the difference series output for each simulation by controlling how aggressively each series moves.
When "Adjust Amplitude Coefficients" is disabled, all three coefficients are set to 1.
Note that if you expect volatility to significantly diverge from its historical values over the forecast interval, try experimenting with these factors to match your anticipation.
The "Weighting Settings" section controls the weighting boundaries for the three generators.
These weighting limits affect how tailed the distributions in each generator are, which in turn affects the final series outputs.
The maximum absolute value range for the weights is . When "Limit Generator Weights" is disabled, this is the range that is automatically used.
The last set of inputs is the "Display Settings", where you can control the visual outputs.
From here, you can select to display either "Forecast" or "Difference Comparison" via the "Output Display Type" dropdown tab.
"Forecast" is the type displayed by default. This plots the end result or developing forecast ranges.
There is an option with this display type to show the developing extremes of the simulations. This option is enabled by default.
There's also an option with this display type to show one of the simulated price series from the set alongside actual prices.
This allows you to visually compare simulated prices alongside the real prices.
"Difference Comparison" allows you to visually compare a synthetic difference series from the set alongside the actual difference series.
This display method is primarily useful for visually tuning the amplitude and weighting settings of the generators.
There are also info panel settings on the bottom, which allow you to control size, colors, and date format for the panel.
It's all pretty simple to use once you get the hang of it. So play around with the settings and see what kinds of forecasts you can generate!
----------
ADDITIONAL NOTES & DISCLAIMERS
Although I've done a number of things within this script to keep runtime demands as low as possible, the fact remains that this script is fairly computationally heavy.
Because of this, you may get random timeouts when using this script.
This could be due to either random drops in available runtime on the server, using too many simulations, or running the simulations over too many bars.
If it's just a random drop in runtime on the server, hide and unhide the script, re-add it to the chart, or simply refresh the page.
If the timeout persists after trying this, then you'll need to adjust your settings to a less demanding configuration.
Please note that no specific claims are being made in regards to this script's predictive accuracy.
It must be understood that this model is based on randomized price generation with assumed constant drift and dispersion from historical data before the starting point.
Models like these not consider the real world factors that may influence price movement (economic changes, seasonality, macro-trends, instrument hype, etc.), nor the changes in sample distribution that may occur.
In light of this, it's perfectly possible for price data to exceed even the most extreme simulated outcomes.
The future is uncertain, and becomes increasingly uncertain with each passing point in time.
Predictive models of any type can vary significantly in performance at any point in time, and nobody can guarantee any specific type of future performance.
When using forecasts in making decisions, DO NOT treat them as any form of guarantee that values will fall within the predicted range.
When basing your trading decisions on any trading methodology or utility, predictive or not, you do so at your own risk.
No guarantee is being issued regarding the accuracy of this forecast model.
Forecasting is very far from an exact science, and the results from any forecast are designed to be interpreted as potential outcomes rather than anything concrete.
With that being said, when applied prudently and treated as "general case scenarios", forecast models like these may very well be potentially beneficial tools to have in the arsenal.
Relative Volume at Time█ OVERVIEW
This indicator calculates relative volume, which is the ratio of present volume over an average of past volume.
It offers two calculation modes, both using a time reference as an anchor.
█ CONCEPTS
Calculation modes
The simplest way to calculate relative volume is by using the ratio of a bar's volume over a simple moving average of the last n volume values.
This indicator uses one of two, more subtle ways to calculate both values of the relative volume ratio: current volume:past volume .
The two calculations modes are:
1 — Cumulate from Beginning of TF to Current Bar where:
current volume = the cumulative volume since the beginning of the timeframe unit, and
past volume = the mean of volume during that same relative period of time in the past n timeframe units.
2 — Point-to-Point Bars at Same Offset from Beginning of TF where:
current volume = the volume on a single chart bar, and
past volume = the mean of volume values from that same relative bar in time from the past n timeframe units.
Timeframe units
Timeframe units can be defined in three different ways:
1 — Using Auto-steps, where the timeframe unit automatically adjusts to the timeframe used on the chart:
— A 1 min timeframe unit will be used on 1sec charts,
— 1H will be used for charts at 1min and less,
— 1D will be used for other intraday chart timeframes,
— 1W will be used for 1D charts,
— 1M will be used for charts at less than 1M,
— 1Y will be used for charts at greater or equal than 1M.
2 — As a fixed timeframe that you define.
3 — By time of day (for intraday chart timeframes only), which you also define. If you use non-intraday chart timeframes in this mode, the indicator will switch to Auto-steps.
Relative Relativity
A relative volume value of 1.0 indicates that current volume is equal to the mean of past volume , but how can we determine what constitutes a high relative volume value?
The traditional way is to settle for an arbitrary threshold, with 2.0 often used to indicate that relative volume is worthy of attention.
We wanted to provide traders with a contextual method of calculating threshold values, so in addition to the conventional fixed threshold value,
this indicator includes two methods of calculating a threshold channel on past relative volume values:
1 — Using the standard deviation of relative volume over a fixed lookback.
2 — Using the highs/lows of relative volume over a variable lookback.
Channels calculated on relative volume provide meta-relativity, if you will, as they are relative values of relative volume.
█ FEATURES
Controls in the "Display" section of inputs determine what is visible in the indicator's pane. The next "Settings" section is where you configure the parameters used in the calculations. The "Column Coloring Conditions" section controls the color of the columns, which you will see in three of the five display modes available. Whether columns are plotted or not, the coloring conditions also determine when markers appear, if you have chosen to show the markers in the "Display" section. The presence of markers is what triggers the alerts configured on this indicator. Finally, the "Colors" section of inputs allows you to control the color of the indicator's visual components.
Display
Five display modes are available:
• Current Volume Columns : shows columns of current volume , with past volume displayed as an outlined column.
• Relative Volume Columns : shows relative volume as a column.
• Relative Volume Columns With Average : shows relative volume as a column, with the average of relative volume.
• Directional Relative Volume Average : shows a line calculated using the average of +/- values of relative volume.
The positive value of relative volume is used on up bars; its negative value on down bars.
• Relative Volume Average : shows the average of relative volume.
A Hull moving average is used to calculate the average used in the three last display modes.
You can also control the display of:
• The value or relative volume, when in the first three display modes. Only the last 500 values will be shown.
• Timeframe transitions, shown in the background.
• A reminder of the active timeframe unit, which appears to the right of the indicator's last bar.
• The threshold used, which can be a fixed value or a channel, as determined in the next "Settings" section of inputs.
• Up/Down markers, which appear on transitions of the color of the volume columns (determined by coloring conditions), which in turn control when alerts are triggered.
• Conditions of high volatility.
Settings
Use this section of inputs to change:
• Calculation mode : this is where you select one of this indicator's two calculation modes for current volume and past volume , as explained in the "Concepts" section.
• Past Volume Lookback in TF units : the quantity of timeframe units used in the calculation of past volume .
• Define Timeframes Units Using : the mode used to determine what one timeframe unit is. Note that when using a fixed timeframe, it must be higher than the chart's timeframe.
Also, note that time of day timeframe units only work on intraday chart timeframes.
• Threshold Mode : Five different modes can be selected:
— Fixed Value : You can define the value using the "Fixed Threshold" field below. The default value is 2.0.
— Standard Deviation Channel From Fixed Lookback : This is a channel calculated using the simple moving average of relative volume
(so not the Hull moving average used elsewhere in the indicator), plus/minus the standard deviation multiplied by a user-defined factor.
The lookback used is the value of the "Channel Lookback" field. Its default is 100.
— High/Low Channel From Beginning of TF : in this mode, the High/Low values reset at the beginning of each timeframe unit.
— High/Low Channel From Beginning of Past Volume Lookback : in this mode, the High/Low values start from the farthest point back where we are calculating past volume ,
which is determined by the combination of timeframe units and the "Past Volume Lookback in TF units" value.
— High/Low Channel From Fixed Lookback : In this mode the lookback is fixed. You can define the value using the "Channel Lookback" field. The default value is 100.
• Period of RelVol Moving Average : the period of the Hull moving average used in the "Directional Relative Volume Average" and the "Relative Volume Average".
• High Volatility is defined using fast and slow ATR periods, so this represents the volatility of price.
Volatility is considered to be high when the fast ATR value is greater than its slow value. Volatility can be used as a filter in the column coloring conditions.
Column Coloring Conditions
• Eight different conditions can be turned on or off to determine the color of the volume columns. All "ON" conditions must be met to determine a high/low state of relative volume,
or, in the case of directional relative volume, a bull/bear state.
• A volatility state can also be used to filter the conditions.
• When the coloring conditions and the filter do not allow for a high/low state to be determined, the neutral color is used.
• Transitions of the color of the volume columns determined by coloring conditions are used to plot the up/down markers, which in turn control when alerts are triggered.
Colors
• You can define your own colors for all of the oscillator's plots.
• The default colors will perform well on light or dark chart backgrounds.
Alerts
• An alert can be defined for the script. The alert will trigger whenever an up/down marker appears in the indicator's display.
The particular combination of coloring conditions and the display settings for up/down markers when you create the alert will determine which conditions trigger the alert.
After alerts are created, subsequent changes to the conditions controlling the display of markers will not affect existing alerts.
• By configuring the script's inputs in different ways before you create your alerts, you can create multiple, functionally distinct alerts from this script.
When creating multiple alerts, it is useful to include in the alert's message a reminder of the particular conditions you used for each alert.
• As is usually the case, alerts triggering "Once Per Bar Close" will prevent repainting.
Error messages
Error messages will appear at the end of the chart upon the following conditions:
• When the combination of the timeframe units used and the "Past Volume Lookback in TF units" value create a lookback that is greater than 5000 bars.
The lookback will then be recalculated to a value such that a runtime error does not occur.
• If the chart's timeframe is higher than the timeframe units. This error cannot occur when using Auto-steps to calculate timeframe units.
• If relative volume cannot be calculated, for example, when no volume data is available for the chart's symbol.
• When the threshold of relative volume is configured to be visible but the indicator's scale does not allow it to be visible (in "Current Volume Columns" display mode).
█ NOTES
For traders
The chart shown here uses the following display modes: "Current Volume Columns", "Relative Volume Columns With Average", "Directional Relative Volume Average" and "Relative Volume Average". The last one also shows the threshold channel in standard deviation mode, and the TF Unit reminder to the right, in red.
Volume, like price, is a value with a market-dependent scale. The only valid reference for volume being its past values, any improvement in the way past volume is calculated thus represents a potential opportunity to traders. Relative volume calculated as it is here can help traders extract useful information from markets in many circumstances, markets with cyclical volume such as Forex being one, obvious case. The relative nature of the values calculated by this indicator also make it a natural fit for cross-market and cross-sector analysis, or to identify behavioral changes in the different futures contracts of the same market. Relative volume can also be put to more exotic uses, such as in evaluating changes in the popularity of exchanges.
Relative volume alone has no directional bias. While higher relative volume values always indicate higher trading activity, that activity does not necessarily translate into significant price movement. In a tightly fought battle between buyers and sellers, you could theoretically have very large volume for many bars, with no change whatsoever in bid/ask prices. This of course, is unlikely to happen in reality, and so traders are justified in considering high relative volume values as indicating periods where more attention is required, because imbalances in the strength of buying/selling power during high-volume trading periods can amplify price variations, providing traders with the generally useful gift of volatility.
Be sure to give the "Directional Relative Volume Average" a try. Contrary to the always-positive ratio widely used in this indicator, the "Directional Relative Volume Average" produces a value able to determine a bullish/bearish bias for relative volume.
Note that realtime bars must be complete for the relative volume value to be confirmed. Values calculated on historical or elapsed realtime bars will not recalculate unless historical volume data changes.
Finally, as with all indicators using volume information, keep in mind that some exchanges/brokers supply different feeds for intraday and daily data, and the volume data on both feeds can sometimes vary quite a bit.
For coders
Our script was written using the PineCoders Coding Conventions for Pine .
The description was formatted using the techniques explained in the How We Write and Format Script Descriptions PineCoders publication.
Bits and pieces of code were lifted from the MTF Selection Framework and the MTF Oscillator Framework , also by PineCoders.
█ THANKS
Thanks to dgtrd for suggesting to add the channel using standard deviation.
Thanks to adolgov for helpful suggestions on calculations and visuals.
Look first. Then leap.
Money Flow Profile [LuxAlgo]The Money Flow Profile is a charting tool that measures the traded volume or the money flow at all price levels on the market over a specified time period and highlights the relationship between the price of a given asset and the willingness of traders to either buy or sell it, allowing traders to reveal dominant and/or significant price levels and to analyze the trading activity of a particular user-selected range.
This tool combines a volume/money flow profile, a sentiment profile, and price levels, where the right side of the profile highlights the distribution of the traded activity/money flow at different price levels, the left side of the profile highlights the market sentiment at those price levels, and in the middle the price levels.
🔶 USAGE
A volume/money flow profile is an advanced charting tool that displays the traded volume/money flow at different price levels over a specific period. It helps traders visualize where the majority of trading activity/money flow has occurred.
A sentiment profile is a difference between buy and sell volume/money flow aiming to highlight the sentiment/dominance at specific price levels.
Each row of the profile presents figures on volume and money flow specific to price levels.
High volume/money flow nodes indicate areas of high activity and are likely to act as support or resistance in the future. They attract price and try to hold it there. Conversely, low-volume nodes are areas with low trading activity, that are less subject to get revisited by the price. The market often bounces right over these levels, not staying for long. The "Profile Heatmap" option of the script helps to better emphasize the trading activity within each areas.
By measuring the traded activity at each price level the script presents an ability to highlight the consolidation zones, in other words, highlights accumulation and distribution zones. When the price moves toward one end of the consolidation and volume pick up, it can foreshadow a potential breakout.
Level of Significance, Point of Control, Highest Sentiment Zone, and Profile Price levels are some of the other profile-related options available with the script.
🔶 SETTINGS
The script takes into account user-defined parameters and plots the profiles, where detailed usage for each user-defined input parameter in indicator settings is provided with the related input's tooltip.
🔹 Profile Generic Settings
Lookback Length / Fixed Range: Sets the lookback length.
Profile Source: Sets the profile source, Volume, or Money Flow.
🔹 Profile Presentation Settings
Volume/Money Flow Profile: Toggles the visibility of the Volume/Money Flow Profile.
High Traded Nodes: Threshold and Color option for high traded nodes.
Average Traded Nodes: Color option for average traded nodes.
Low Traded Nodes: Threshold and Color option for low traded nodes.
🔹 Sentiment Profile Settings
Sentiment Profile: Toggles the visibility of the Sentiment Profile.
Sentiment Polarity Method: Sets the method used to calculate the up/down volume/money flow.
Bullish Nodes: Color option for Bullish Nodes.
Bearish Nodes: Color option for Bearish Nodes.
🔹 Profile Heatmap Settings
Profile Heatmap: Toggles the visibility of the profile heatmap.
Heatmap Source: Sets the source of the profile heatmap, Volume/Money Flow Profile, or Sentiment Profile.
Heatmap Transparency: Control the transparency of the profile heatmap.
🔹 Other Presentation Settings
Level of Significance: Toggles the visibility of the level of significance line/zone.
Consolidation Zones: Toggles the visibility of the consolidation zones.
Consolidation Threshold, Color: Sets the threshold value and zone color.
Highest Sentiment Zone: Toggles the visibility of the highest bullish or bearish sentiment zone.
Profile Price Levels, Color, Size: Toggles the visibility of the profile price levels, and sets the color and the size of the level labels.
Profile Range Background Fill: Toggles the visibility of the profiles range.
🔹 Other Settings
Number of Rows: Specify how many rows each profile histogram will have.
Profile Width %: Alters the width of the rows in the histogram, relative to the profile length
Profile Text Size: Alters the size of the text. Setting to Auto will keep the text within the box limits.
Profile Horizontal Offset: Enables to move profile in the horizontal axis.
🔶 RELATED SCRIPTS
Liquidity-Sentiment-Profile
Swing-Volume-Profiles
For more and other conceptual scripts you are kindly invited to visit LuxAlgo-Scripts .
String Manipulation Framework [PineCoders FAQ]█ OVERVIEW
This script provides string manipulation functions to help Pine coders.
█ FUNCTIONS PROVIDED
f_strLeft(_str, _n)
Function returning the leftmost `_n` characters in `_str`.
f_strRight(_str, _n)
Function returning the rightmost `_n` characters in `_str`.
f_strMid(_str, _from, _to)
Function returning the substring of `_str` from character position `_from` to `_to` inclusively.
f_strLeftOf(_str, _of)
Function returning the sub-string of `_str` to the left of the `_of` separating character.
f_strRightOf(_str, _of)
Function returning the sub-string of `_str` to the right of the `_of` separating character.
f_strCharPos(_str, _chr)
Function returning the position of the first occurrence of `_chr` in `_str`, where the first character position is 0. Returns -1 if the character is not found.
f_strReplace(_src, _pos, _str)
Function that replaces a character at position `_pos` in the `_src` string with the `_str` character or string.
f_tickFormat()
Function returning a format string usable with `tostring()` to round a value to the symbol's tick precision.
f_tostringPad(_val, _fmt)
Function returning a string representation of a numeric `_val` using a special `_fmt` string allowing all strings to be of the same width, to help align columns of values.
`f_tostringPad()`
Using the functions should be straightforward, but `f_tostringPad()` requires more explanations. Its purpose is to help coders produce columns of fixed-width string representations of numbers which can be used to produce columns of numbers that vertically align neatly in labels, something that comes in handy when, for example, you need to center columns, yet still produce numbers of various lengths that nonetheless align.
While the formatting string used with this function resembles the one used in tostring() , it has a few additional characteristics:
• The question mark (" ? ") is used to indicate that padding is needed.
• If negative numbers must be handled by the function, the first character of the formatting string must be a minus sign ("-"),
otherwise the unary minus sign of negative numbers will be stripped out.
• You will produce more predictable results by using "0" rather than "#" in the formatting string.
You can experiment with `f_tostringPad()` formatting strings by changing the one used in the script's inputs and see the results on the chart.
These are some valid examples of formatting strings that can be used with `f_tostringPad()`:
"???0": forces strings to be four units wide, in all-positive "int" format.
"-???0": forces strings to be four units wide, plus room for a unary minus sign in the first position, in "int" format.
"???0.0": forces strings to be four units wide to the left of the point, all-positive, with a decimal point and then a mantissa rounded to a single digit.
"-???0.0?": same as above, but adds a unary minus sign for negative values, and adds a space after the single-digit mantissa.
"?????????0.0": forces the left part of the float to occupy the space of 10 digits, with a decimal point and then a mantissa rounded to a single digit.
█ CHART
The information displayed by this indicator uses the values in the script's Inputs, so you can use them to play around.
The chart shows the following information:
• Column 0 : The numeric input values in a centered column, converted to strings using tostring() without a formatting argument.
• Column 1 : Shows the values formatted using `f_tostringPad()` with the formatting string from the inputs.
• Column 2 : Shows the values formatted using `f_tostringPad()` but with only the part of the formatting string left of the decimal point, if it contains one.
• Column 3 : Shows the values formatted using `f_tostringPad()` but with the part of the formatting string left of the decimal point,
to which is added the right part of the `f_tostringPad()` formatting string, to obtain the precision in ticks of the symbol the chart is on.
• Column 4 : Shows the result of using the other string manipulation functions in the script on the source string supplied in the inputs.
It also demonstrates how to split up a label in two distinct parts so that you can vertically align columns when the leftmost part contains strings with varying lengths.
You will see in our code how we construct this column in two steps.
█ LIMITATIONS
The Pine runtime is optimized for number crunching. Too many string manipulations will take a toll on the performance of your scripts, as can readily be seen with the running time of this script. To minimize the impact of using string manipulation functions in your scripts, consider limiting their calculation to the first or last bar of the dataset when possible. This can be achieved by using the var keyword when declaring variables containing the result of your string manipulations, or by enclosing blocks of code in if blocks using barstate.isfirst or barstate.islast .
█ NOTES
To understand the challenges we face when trying to align strings vertically, it is useful to know that:
• As is the case in many other places in the TadingView UI and other docs, the Pine runtime uses the MS Trebuchet font to display label text.
• Trebuchet uses proportionally-spaced letters (a "W" takes more horizontal space than an "I"), but fixed-space digits (a "1" takes the same horizontal space as a "3").
Digits all use a figure space width, and it is this property that allows us to align numbers vertically.
The fact that letters are proportionally spaced is the reason why we can't vertically align columns using a "legend" + ":" `+ value structure when the "legend" part varies in width.
• The unary minus sign is the width of a punctuation space . We use this property to pad the beginning of numbers
when you use a "-" as the first character of the `f_tostringPad()` formatting string.
Our script was written using the PineCoders Coding Conventions for Pine .
The description was formatted using the techniques explained in the How We Write and Format Script Descriptions PineCoders publication.
█ THANKS
Thanks to LonesomeTheBlue for the `f_strReplace()` function.
Look first. Then leap.
Quickfingers Luc base scanner - version 2This is my second implementation of a Pine Script Quickfingers Luc (QFL) base scanner that I have published on Trading View. QFL base scanners seek to provide buy signals according to the QFL trading strategy. To profitably trade using this script you should be familiar with the QFL trading strategy, scaling in and out of positions, and money risk management.
Background
All the QFL base identification Pine Scripts that I have inspected to date use a simple candlestick pattern of two lower lows followed by two higher lows to identify a base. Some scripts may combine this with a volume indicator as well. In practice, I found the results of this approach to be somewhat unreliable. The candlestick pattern may identify some significant bases, may identify minor bases (that should not be traded), but at the same time miss other significant bases entirely!
My first QFL base scanner sought to use Pine Script’s built in ta.lowest and ta.highest functions to identify bases and peaks. This approach depended on the time period selected to find the lowest lows and highest highs. This approach can be problematic because significant bases may be formed outside the nominated time period, leading to the identification of minor bases within the time period. I have left the first version of my QFL base scanning script in the Trading View indicators because it uses a different approach to this script that other people may still find useful.
My second version of the QFL base scanner does not use the Pine Script ta.lowest and ta.highest functions, and therefore does not rely on nominating a time period to look back through data.
User inputs
This script steps through the price data to find the following patterns that are used to confirm bases and peaks.
Base – bounce of x% above previous base confirms that base
Peak – fall of y% below previous peak confirms that peak
Buy signal – fall of z% below the base signals a buy signal.
x%, y% and z% are user configurable through the script settings. Small percentages will provide more, but riskier, buy signals; larger percentages will provide fewer, but safer, buy signals.
The script identifies QFL bases and buy signals and marks them on the price chart. These are able to be turned on and off in the script settings. The settings also allow the user to turn on plots for peaks, lowest lows and highest highs. These are not useful for applying the QFL trading strategy, but are calculations used in finding bases and can be useful for the user to understand what the script is doing in the background.
Troubleshooting
If looking at the past script results, you may think that the script is perfectly timing entry points at the bottom of market dips. This is NOT the case. The script is actually showing buy signals when the price falls z% below the PREVIOUS base. The current base is only retrospectively marked some periods later once the reversal is confirmed – a solid line marks a confirmed base in real time; a dotted line retrospectively repaints the line to the actual base. New bases are not tradeable using this script, but a percentage fall from the previous base is – this is the QFL trading strategy.
Pine Script may flag that this script has a repainting issue. Pine Script defines repainting as, “script behavior causing historical vs realtime calculations or plots to behave differently.” In the case of this script, bases are confirmed once the price has bounced x% off the low. The script then repaints a dotted line from the base that has been identified in real time (with a solid line) back to the point in the price data where the base actually occurs. The dotted line only aids in visual identification of the base, and does not impact on the real time identification of bases. A similar repainting issue occurs for identifying peaks. I have identified the lines in the script that cause this repainting. These lines can be commented out without affecting the buy signals generated by the script, but you will also lose the visual pinpointing of historical bases and peaks.
The user may find price charts where they think that the script has not correctly identified a base or peak. Usually, careful measurement will reveal that the price chart has not confirmed a base or peak by moving x% or y% from the previous base or peak respectively.
And before you ask, yes, Trading View alerts work with this script.
Enjoy.
Trend WaveHello Traders!
You know, I can sill remember the first time I started tinkering with Pinescript. As I had no prior programming experience, I learned by experimenting with other open-source scripts on TradingViews Marketplace. Tearing apart and combining interesting scripts to see what the output would be. @ChrisMoody was a huge source of inspiration for learning, and I wanted to thank him, as well as @TheLark for the concept behind this script.
The Trend Wave is based on @ChrisMoody's PPO-PercentileRank-Mkt-Tops-Bottoms , which also happens to be based on @TheLark's TheLark-Laguerre-PPO/ .
Within my experimentation, I found that if I isolate the ppoT & ppoB variables and plot them calculated from extremely small decimals, you can get an extremely fast reacting, mirroring trend detector.
Within the script, you have the ability to plot the background colors based on trend to make it easier to see where crossovers occured, as well as a Mirror Input to view the mirrored version of the script.
-@DayTradingOil
Bitcoin Macro Trend Map [Ox_kali]
## Introduction
__________________________________________________________________________________
The “Bitcoin Macro Trend Map” script is designed to provide a comprehensive analysis of Bitcoin’s macroeconomic trends. By leveraging a unique combination of Bitcoin-specific macroeconomic indicators, this script helps traders identify potential market peaks and troughs with greater accuracy. It synthesizes data from multiple sources to offer a probabilistic view of market excesses, whether overbought or oversold conditions.
This script offers significant value for the following reasons:
1. Holistic Market Analysis : It integrates a diverse set of indicators that cover various aspects of the Bitcoin market, from investor sentiment and market liquidity to mining profitability and network health. This multi-faceted approach provides a more complete picture of the market than relying on a single indicator.
2. Customization and Flexibility : Users can customize the script to suit their specific trading strategies and preferences. The script offers configurable parameters for each indicator, allowing traders to adjust settings based on their analysis needs.
3. Visual Clarity : The script plots all indicators on a single chart with clear visual cues. This includes color-coded indicators and background changes based on market conditions, making it easy for traders to quickly interpret complex data.
4. Proven Indicators : The script utilizes well-established indicators like the EMA, NUPL, PUELL Multiple, and Hash Ribbons, which are widely recognized in the trading community for their effectiveness in predicting market movements.
5. A New Comprehensive Indicator : By integrating background color changes based on the aggregate signals of various indicators, this script essentially creates a new, comprehensive indicator tailored specifically for Bitcoin. This visual representation provides an immediate overview of market conditions, enhancing the ability to spot potential market reversals.
Optimal for use on timeframes ranging from 1 day to 1 week , the “Bitcoin Macro Trend Map” provides traders with actionable insights, enhancing their ability to make informed decisions in the highly volatile Bitcoin market. By combining these indicators, the script delivers a robust tool for identifying market extremes and potential reversal points.
## Key Indicators
__________________________________________________________________________________
Macroeconomic Data: The script combines several relevant macroeconomic indicators for Bitcoin, such as the 10-month EMA, M2 money supply, CVDD, Pi Cycle, NUPL, PUELL, MRVR Z-Scores, and Hash Ribbons (Full description bellow).
Open Source Sources: Most of the scripts used are sourced from open-source projects that I have modified to meet the specific needs of this script.
Recommended Timeframes: For optimal performance, it is recommended to use this script on timeframes ranging from 1 day to 1 week.
Objective: The primary goal is to provide a probabilistic solution to identify market excesses, whether overbought or oversold points.
## Originality and Purpose
__________________________________________________________________________________
This script stands out by integrating multiple macroeconomic indicators into a single comprehensive tool. Each indicator is carefully selected and customized to provide insights into different aspects of the Bitcoin market. By combining these indicators, the script offers a holistic view of market conditions, helping traders identify potential tops and bottoms with greater accuracy. This is the first version of the script, and additional macroeconomic indicators will be added in the future based on user feedback and other inputs.
## How It Works
__________________________________________________________________________________
The script works by plotting each macroeconomic indicator on a single chart, allowing users to visualize and interpret the data easily. Here’s a detailed look at how each indicator contributes to the analysis:
EMA 10 Monthly: Uses an exponential moving average over 10 monthly periods to signal bullish and bearish trends. This indicator helps identify long-term trends in the Bitcoin market by smoothing out price fluctuations to reveal the underlying trend direction.Moving Averages w/ 18 day/week/month.
Credit to @ryanman0
M2 Money Supply: Analyzes the evolution of global money supply, indicating market liquidity conditions. This indicator tracks the changes in the total amount of money available in the economy, which can impact Bitcoin’s value as a hedge against inflation or economic instability.
Credit to @dylanleclair
CVDD (Cumulative Value Days Destroyed): An indicator based on the cumulative value of days destroyed, useful for identifying market turning points. This metric helps assess the Bitcoin market’s health by evaluating the age and value of coins that are moved, indicating potential shifts in market sentiment.
Credit to @Da_Prof
Pi Cycle: Uses simple and exponential moving averages to detect potential sell points. This indicator aims to identify cyclical peaks in Bitcoin’s price, providing signals for potential market tops.
Credit to @NoCreditsLeft
NUPL (Net Unrealized Profit/Loss): Measures investors’ unrealized profit or loss to signal extreme market levels. This indicator shows the net profit or loss of Bitcoin holders as a percentage of the market cap, helping to identify periods of significant market optimism or pessimism.
Credit to @Da_Prof
PUELL Multiple: Assesses mining profitability relative to historical averages to indicate buying or selling opportunities. This indicator compares the daily issuance value of Bitcoin to its yearly average, providing insights into when the market is overbought or oversold based on miner behavior.
Credit to @Da_Prof
MRVR Z-Scores: Compares market value to realized value to identify overbought or oversold conditions. This metric helps gauge the overall market sentiment by comparing Bitcoin’s market value to its realized value, identifying potential reversal points.
Credit to @Pinnacle_Investor
Hash Ribbons: Uses hash rate variations to signal buying opportunities based on miner capitulation and recovery. This indicator tracks the health of the Bitcoin network by analyzing hash rate trends, helping to identify periods of miner capitulation and subsequent recoveries as potential buying opportunities.
Credit to @ROBO_Trading
## Indicator Visualization and Interpretation
__________________________________________________________________________________
For each horizontal line representing an indicator, a legend is displayed on the right side of the chart. If the conditions are positive for an indicator, it will turn green, indicating the end of a bearish trend. Conversely, if the conditions are negative, the indicator will turn red, signaling the end of a bullish trend.
The background color of the chart changes based on the average of green or red indicators. This parameter is configurable, allowing adjustment of the threshold at which the background color changes, providing a clear visual indication of overall market conditions.
## Script Parameters
__________________________________________________________________________________
The script includes several configurable parameters to customize the display and behavior of the indicators:
Color Style:
Normal: Default colors.
Modern: Modern color style.
Monochrome: Monochrome style.
User: User-customized colors.
Custom color settings for up trends (Up Trend Color), down trends (Down Trend Color), and NaN (NaN Color)
Background Color Thresholds:
Thresholds: Settings to define the thresholds for background color change.
Low/High Red Threshold: Low and high thresholds for bearish trends.
Low/High Green Threshold: Low and high thresholds for bullish trends.
Indicator Display:
Options to show or hide specific indicators such as EMA 10 Monthly, CVDD, Pi Cycle, M2 Money, NUPL, PUELL, MRVR Z-Scores, and Hash Ribbons.
Specific Indicator Settings:
EMA 10 Monthly: Options to customize the period for the exponential moving average calculation.
M2 Money: Aggregation of global money supply data.
CVDD: Adjustments for value normalization.
Pi Cycle: Settings for simple and exponential moving averages.
NUPL: Thresholds for unrealized profit/loss values.
PUELL: Adjustments for mining profitability multiples.
MRVR Z-Scores: Settings for overbought/oversold values.
Hash Ribbons: Options for hash rate moving averages and capitulation/recovery signals.
## Conclusion
__________________________________________________________________________________
The “Bitcoin Macro Trend Map” by Ox_kali is a tool designed to analyze the Bitcoin market. By combining several macroeconomic indicators, this script helps identify market peaks and troughs. It is recommended to use it on timeframes from 1 day to 1 week for optimal trend analysis. The scripts used are sourced from open-source projects, modified to suit the specific needs of this analysis.
## Notes
__________________________________________________________________________________
This is the first version of the script and it is still in development. More indicators will likely be added in the future. Feedback and comments are welcome to improve this tool.
## Disclaimer:
__________________________________________________________________________________
Please note that the Open Interest liquidation map is not a guarantee of future market performance and should be used in conjunction with proper risk management. Always ensure that you have a thorough understanding of the indicator’s methodology and its limitations before making any investment decisions. Additionally, past performance is not indicative of future results.
Volume Profile with Node Detection [LuxAlgo]The Volume Profile with Node Detection is a charting tool that allows visualizing the distribution of traded volume across specific price levels and highlights significant volume nodes or clusters of volume nodes that traders may find relevant in utilizing in their trading strategies.
🔶 USAGE
The volume profile component of the script serves as the foundation for node detection while encompassing all the essential features expected from a volume profile. See the sub-sections below for more detailed information about the indicator components and their usage.
🔹 Peak Volume Node Detection
A volume peak node is identified when the volume profile nodes for the N preceding and N succeeding nodes are lower than that of the evaluated one.
Displaying peak volume nodes along with their surrounding N nodes (Zones or Clusters) helps visualize the range, typically representing consolidation zones in the market. This feature enables traders to identify areas where trading activity has intensified, potentially signaling periods of price consolidation or indecision among market participants.
🔹 Trough Volume Node Detection
A volume trough node is identified when the volume profile nodes for the N preceding and N succeeding nodes are higher than that of the evaluated one.
🔹 Highest and Lowest Volume Nodes
Both the highest and lowest volume areas play significant roles in trading. The highest volume areas typically represent zones of strong price acceptance, where a significant amount of trading activity has occurred. On the other hand, the lowest volume areas signify price levels with minimal trading activity, often indicating zones of price rejection or areas where market participants have shown less interest.
🔹 Volume profile
Volume profile is calculated based on the volume of trades that occur at various price levels within a specified timeframe. It divides the price range into discrete price intervals, typically known as "price buckets" or "price bars," and then calculates the total volume of trades that occur at each price level within those intervals. This information is then presented graphically as a histogram or profile, where the height of each bar represents the volume of trades that occurred at that particular price level.
🔶 SETTINGS
🔹 Volume Nodes
Volume Peaks: Toggles the visibility of either the "Peaks" or "Clusters" on the chart, depending on the specified percentage for detection.
Node Detection Percent %: Specifies the percentage for the Volume Peaks calculation.
Volume Troughs: Toggles the visibility of either the "Troughs" or "Clusters" on the chart, depending on the specified percentage for detection.
Node Detection Percent %: Specifies the percentage for the Volume Troughs calculation.
Volume Node Threshold %: A threshold value specified as a percentage is utilized to detect peak/trough volume nodes. If a value is set, the detection will disregard volume node values lower than the specified threshold.
Highest Volume Nodes: Toggles the visibility of the highest nodes for the specified count.
Lowest Volume Nodes: Toggles the visibility of the lowest nodes for the specified count.
🔹 Volume Profile - Components
Volume Profile: Toggles the visibility of the volume profile with either classical display or gradient display.
Value Area Up / Down: Color customization option for the volume nodes within the value area of the profile.
Profile Up / Down Volume: Color customization option for the volume nodes outside of the value area of the profile.
Point of Control: Toggles the visibility of the point of control, allowing selection between "developing" or "regular" modes. Sets the color and width of the point of control line accordingly.
Value Area High (VAH): Toggles the visibility of the value area high level and allows customization of the line color.
Value Area Low (VAL): Toggles the visibility of the value area low level and allows customization of the line color.
Profile Price Labels: Toggles the visibility of the Profile Price Levels and allows customization of the text size of the levels.
🔹 Volume Profile - Display Settings
Profile Lookback Length: Specifies the length of the profile lookback period.
Value Area (%): Specifies the percentage for calculating the value area.
Profile Placement: Specify where to display the profile.
Profile Number of Rows: Specify the number of rows the profile will have.
Profile Width %: Adjusts the width of the rows in the profile relative to the profile range.
Profile Horizontal Offset: Adjusts the horizontal offset of the profile when it is selected to be displayed on the right side of the chart.
Value Area Background: Toggles the visibility of the value area background and allows customization of the fill color.
Profile Background: Toggles the visibility of the profile background and allows customization of the fill color.
🔶 RELATED SCRIPTS
Supply-Demand-Profiles
Liquidity-Sentiment-Profile
Thanks to our community for recommending this script. For more conceptual scripts and related content, we welcome you to explore by visiting >>> LuxAlgo-Scripts .
HTF Oscillators RSI/ROC/MFI/CCI/AO - Dynamic SmoothingThe Interplay of Time Frames: A Balanced View
Navigating the markets often involves interpreting trends from multiple angles. The HTF Oscillators with Dynamic Smoothing indicator enables you to do just that. This tool provides the option to integrate smoothed oscillator readings from Higher Time Frames (HTF) into lower time frame charts, such as a 1-minute chart. By doing so, the indicator offers a balanced viewpoint that bridges the gap between micro and macro perspectives, helping you make informed decisions without losing sight of the broader market context.
Features
Multi-Oscillator Support
Choose from a range of popular oscillators like the Relative Strength Index (RSI), Rate of Change (ROC), Money Flow Index (MFI), Commodity Channel Index (CCI), and Awesome Oscillator (AO). These oscillators are commonly used as foundational building blocks in trading strategy scripts by traders worldwide. Switch effortlessly between them, depending on your trading strategy and requirements. To maintain consistency and a familiar user experience, our script adopts the same visual aesthetics that you'll find in Pine Script indicators on TradingView: a sleek purple line for the oscillator and a transparent band filling. These visual elements are not only pleasing to the eye but also widely appreciated by the trading community.
Dynamic Smoothing
The unique dynamic smoothing feature calculates a smoothing factor based on the ratio of minutes between the Higher Time Frame (HTF) and your current time frame. This provides a sleek and responsive oscillator line that still holds the weight of the longer trend. One of the significant advantages of this feature is user experience; when you change your time frame, the HTF-values in your settings will remain consistent. This ensures that you can easily switch between different time frames without losing the insights provided by your selected HTF.
Visual Aids
Visual cues are an essential part of any trading strategy. The indicator not only plots signals to mark overbought and oversold conditions based on the dynamically smoothed oscillator but also provides you with the flexibility to customize your visual experience. You have the option to toggle on/off the display of these signals depending on your specific needs. Additionally, bands can be displayed at overbought and oversold levels, along with a reference middle line. If you switch between different oscillators (available in the parameter settings), remember to manually adjust the bands in the input settings to ensure signals matches with the type of oscillator to your liking.
User-Friendly Settings
We've grouped related settings together, making it easier for you to find what you're looking for. Adjust the oscillator type, length of bars, smoothing settings, and more with just a few clicks.
Information Table
A standout feature of this indicator is the real-time information table, which displays the values of all selected oscillators based on your specified Higher Time Frame (HTF) settings. This can be particularly useful for traders who depend on multiple indicators for their decision-making process. The data presented in the table is synchronized with the HTF options you've configured in the input settings, allowing for a more efficient and quick scan of values from higher time frames.
Educational Corner: The Power of the Information Table and Customization
The table incorporated into this indicator isn't just eye-candy; it's a practical tool designed to elevate your trading strategy. It dynamically displays real-time values of various oscillators for the HTF you've chosen. This is an exemplary use of TradingView's scripting capabilities to blend multiple indicators into a single visual panel, streamlining your analysis and decision-making process.
But here's the best part: You're not limited to what we've created. With some basic understanding of TradingView's scripting language, Pine Script, you can easily adapt this table to include different indicators that suit your unique trading style. The logic in the script is modular and can serve as a foundation for your own customized trading dashboard. So, go ahead, get creative and explore new combinations of indicators that will help you excel in your trading endeavors!
You no longer have to toggle between different charts or indicators to get the information you need; it's all there in one neatly organized table. We encourage you to tap into this feature and make it your own, empowering your trading like never before.
By doing so, you not only gain a more comprehensive toolset, but you also engage more deeply with your trading strategy, understanding its nuances and, ultimately, making more informed decisions.
Conclusion
The HTF Oscillators with Dynamic Smoothing is a versatile and powerful tool that brings together the best of both worlds: the perspective of higher time frames and the granularity of shorter ones. Its feature-rich setting options and real-time information table make it a potential useful addition to your trading toolkit.
Remember, while this indicator offers a comprehensive and smarter way to look at the markets, it is not a foolproof method for predicting market movements. Always use it in conjunction with other analysis methods and risk management strategies.
RAINBOW AVERAGES - INDICATOR - (AS) - 1/3
-INTRODUCTION:
This is the first of three scripts I intend to publish using rainbow indicators. This script serves as a groundwork for the other two. It is a RAINBOW MOVING AVERAGES indicator primarily designed for trend detection. The upcoming script will also be an indicator but with overlay=false (below the chart, not on it) and will utilize RAINBOW BANDS and RAINBOW OSCILLATOR. The third script will be a strategy combining all of them.
RAINBOW moving averages can be used in various ways, but this script is mainly intended for trend analysis. It is meant to be used with overlay=true, but if the user wishes, it can be viewed below the chart. To achieve this, you need to change the code from overlay=true to false and turn off the first switch that plots the rainbow on the chart (or simply move the indicator to a new pane below). By doing this, you will be able to see how all four conditions used to detect trends work on the chart. But let's not get ahead of ourselves.
-WHAT IS IT:
In its simplest form, this indicator uses 10 moving averages colored like a rainbow. The calculation is as follows:
MA0: This is the main moving average and can be defined with the type (SMA, EMA, RMA, WMA, SINE), length, and price source. However, the second moving average (MA1) is calculated using MA0 as its source, MA2 uses MA1 as the data source, and so on, until the last one, MA9. Hence, there are 10 moving averages. The first moving average is special as all the others derive from it. This indicator has many potential uses, such as entry/exit signals, volatility indication, and stop-loss placement, but for now, we will focus on trend detection.
-TREND DETECTION:
The indicator offers four different background color options based on the user's preference:
0-NONE: No background color is applied as no trend detection tools is being used (boring)
1-CHANGE: The background color is determined by summing the changes of all 10 moving averages (from two bars). If the sum is positive and not falling, the background color is GREEN. If the sum is negative and not rising, the background color is RED. From early testing, it works well for the beginning of a movement but not so much for a lasting trend.
2-RAINBW: The background color is green when all the moving averages are in ascending order, indicating a bullish trend. It is red when all the moving averages are in descending order, indicating a bearish trend. For example, if MA1>MA2>MA3>MA4..., the background color is green. If MA1 threshold, and red indicates width < -threshold.
4-DIRECT: The background color is determined by counting the number of moving averages that are either above or below the input source. If the specified number of moving averages is above the source, the background color is green. If the specified number of moving averages is below the source, the background color is red. If all ten MAs are below the price source, the indicator will show 10, and if all ten MAs are above, it will show -10. The specific value will be set later in the settings (same for 3-TSHOLD variant). This method works well for lasting trends.
Note: If the indicator is turned into a below-chart version, all four color options can be seen as separate indicators.
-PARAMETERS - SETTINGS:
The first line is an on/off switch to plot the skittles indicator (and some info in the tooltip). The second line has already been discussed, which is the background color and the selection of the source (only used for MA0!).
The line "MA1: TYP/LEN" is where we define the parameters of MA0 (important). We choose from the types of moving averages (SMA, EMA, RMA, WMA, SINE) and set the length.
Important Note: It says MA1, but it should be MA0!.
The next line defines whether we want to smooth MA1 (which is actually MA0) and the period for smoothing. When smoothing is turned on, MA0 will be smoothed using a 3-pole super smoother. It's worth noting that although this only applies to MA0, as the other MAs are derived from it, they will also be smoothed.
In the line below, we define the type and length of MAs for MA2 (and other MAs except MA0). The same type and length are used for MA1 to MA9. It's important to remember that these values should be smaller. For example, if we set 55, it means that MA1 is the average of 55 periods of MA0, MA2 will be 55 periods of MA1, and so on. I encourage trying different combinations of MA types as it can be easily adjusted for ur type of trading. RMA looks quirky.
Moving on to the last line, we define some inputs for the background color:
TSH: The threshold value when using 3-TSHOLD-BGC. It's a good idea to change the chart to a pane below for easier adjustment. The default values are based on EURUSD-5M.
BG_DIR: The value that must be crossed or equal to the MA score if using 4-DIRECT-BGC. There are 10 MAs, so the maximum value is also 10. For example, if you set it to 9, it means that at least 9 MAs must be below/above the price for the script to detect a trend. Higher values are recommended as most of the time, this indicator oscillates either around the maximum or minimum value.
-SUMMARY OF SETTINGS:
L1 - PLOT MAs and general info tooltip
L2 - Select the source for MA0 and type of trend detection.
L3 - Set the type and length of MA0 (important).
L4 - Turn smoothing on/off for MA0 and set the period for super smoothing.
L5 - Set the type and length for the rest of the MAs.
L6 - Set values if using 4-DIRECT or 3-TSHOLD for the trend detection.
-OTHERS:
To see trend indicators, you need to turn off the plotting of MAs (first line), and then choose the variant you want for the background color. This will plot it on the chart below.
Keep in mind that M1 int settings stands for MA0 and MA2 for all of the 9 MAs left.
Yes, it may seem more complicated than it actually is. In a nutshell, these are 10 MAs, and each one after MA0 uses the previous one as its source. Plus few conditions for range detection. rest is mainly plots and colors.
There are tooltips to help you with the parameters.
I hope this will be useful to someone. If you have any ideas, feedback, or spot errors in the code, LET ME KNOW.
Stay tuned for the remaining two scripts using skittles indicators and check out my other scripts.
-ALSO:
I'm always looking for ideas for interesting indicators and strategies that I could code, so if you don't know Pinescript, just message me, and I would be glad to write your own indicator/strategy for free, obviously.
-----May the force of the market be with you, and until we meet again,
™TradeChartist Fib Extensions™TradeChartist Fib Extensions is a free to use script that helps traders plot Fibonacci Extensions on chart. Even though Trading View has a Fib extensions tool, some traders may prefer a plotting script like this with Fib plot lines extending across the whole of the chart to track historic prices in relation to Fib extensions drawn.
----To draw Fib extensions for uptrend ,
1. Choose a Pivot Low point (LL or a HL) as Pivot 1
2. Choose a Pivot High point (must be higher than Pivot 1) as Pivot 2
3. Choose a Pivot Low point (must be lower than Pivot 2, must be Higher than Pivot 1)
----To draw Fib extensions for downtrend,
1. Choose a Pivot High point (HH or a LH) as Pivot 1
2. Choose a Pivot Low point (must be lower than Pivot 1) as Pivot 2
3. Choose a Pivot High point (must be higher than Pivot 2 and lower than Pivot 1)
Negative extensions of -23.6% and -61.8% fib plots may be useful for some to spot reversals or to set stop losses.
Higher levels can be used if price goes beyond 161.8%
This is a free to use indicator. Give a thumbs up or leave a comment if you like the script
Check my 'Scripts' page to see other published scripts. Get in touch with me if you would like access to my invite-only scripts for a trial before deciding on a paid access for a period of your choice. Half-Yearly, Annual and Lifetime access available on invite-only scripts along with 1hr Team Viewer intro session.
Watermark with dynamic variables [BM]█ OVERVIEW
This indicator allows users to add highly customizable watermark messages to their charts. Perfect for branding, annotation, or displaying dynamic chart information, this script offers advanced customization options including dynamic variables, text formatting, and flexible positioning.
█ CONCEPTS
Watermarks are overlay messages on charts. This script introduces placeholders — special keywords wrapped in % signs — that dynamically replace themselves with chart-related data. These watermarks can enhance charts with context, timestamps, or branding.
█ FEATURES
Dynamic Variables : Replace placeholders with real-time data such as bar index, timestamps, and more.
Advanced Customization : Modify text size, color, background, and alignment.
Multiple Messages : Add up to four independent messages per group, with two groups supported (A and B).
Positioning Options : Place watermarks anywhere on the chart using predefined locations.
Timezone Support : Display timestamps in a preferred timezone with customizable formats.
█ INPUTS
The script offers comprehensive input options for customization. Each Watermark (A and B) contains identical inputs for configuration.
Watermark settings are divided into two levels:
Watermark-Level Settings
These settings apply to the entire watermark group (A/B):
Show Watermark: Toggle the visibility of the watermark group on the chart.
Position: Choose where the watermark group is displayed on the chart.
Reverse Line Order: Enable to reverse the order of the lines displayed in Watermark A.
Message-Level Settings
Each watermark contains up to four configurable messages. These messages can be independently customized with the following options:
Message Content: Enter the custom text to be displayed. You can include placeholders for dynamic data.
Text Size: Select from predefined sizes (Tiny, Small, Normal, Large, Huge) or specify a custom size.
Text Alignment and Colors:
- Adjust the alignment of the text (Left, Center, Right).
- Set text and background colors for better visibility.
Format Time: Enable time formatting for this watermark message and configure the format and timezone. The settings for each message include message content, text size, alignment, and more. Please refer to Formatting dates and times for more details on valid formatting tokens.
█ PLACEHOLDERS
Placeholders are special keywords surrounded by % signs, which the script dynamically replaces with specific chart-related data. These placeholders allow users to insert dynamic content, such as bar information or timestamps, into watermark messages.
Below is the complete list of currently available placeholders:
bar_index , barstate.isconfirmed , barstate.isfirst , barstate.ishistory , barstate.islast , barstate.islastconfirmedhistory , barstate.isnew , barstate.isrealtime , chart.is_heikinashi , chart.is_kagi , chart.is_linebreak , chart.is_pnf , chart.is_range , chart.is_renko , chart.is_standard , chart.left_visible_bar_time , chart.right_visible_bar_time , close , dayofmonth , dayofweek , dividends.future_amount , dividends.future_ex_date , dividends.future_pay_date , earnings.future_eps , earnings.future_period_end_time , earnings.future_revenue , earnings.future_time , high , hl2 , hlc3 , hlcc4 , hour , last_bar_index , last_bar_time , low , minute , month , ohlc4 , open , second , session.isfirstbar , session.isfirstbar_regular , session.islastbar , session.islastbar_regular , session.ismarket , session.ispostmarket , session.ispremarket , syminfo.basecurrency , syminfo.country , syminfo.currency , syminfo.description , syminfo.employees , syminfo.expiration_date , syminfo.industry , syminfo.main_tickerid , syminfo.mincontract , syminfo.minmove , syminfo.mintick , syminfo.pointvalue , syminfo.prefix , syminfo.pricescale , syminfo.recommendations_buy , syminfo.recommendations_buy_strong , syminfo.recommendations_date , syminfo.recommendations_hold , syminfo.recommendations_sell , syminfo.recommendations_sell_strong , syminfo.recommendations_total , syminfo.root , syminfo.sector , syminfo.session , syminfo.shareholders , syminfo.shares_outstanding_float , syminfo.shares_outstanding_total , syminfo.target_price_average , syminfo.target_price_date , syminfo.target_price_estimates , syminfo.target_price_high , syminfo.target_price_low , syminfo.target_price_median , syminfo.ticker , syminfo.tickerid , syminfo.timezone , syminfo.type , syminfo.volumetype , ta.accdist , ta.iii , ta.nvi , ta.obv , ta.pvi , ta.pvt , ta.tr , ta.vwap , ta.wad , ta.wvad , time , time_close , time_tradingday , timeframe.isdaily , timeframe.isdwm , timeframe.isintraday , timeframe.isminutes , timeframe.ismonthly , timeframe.isseconds , timeframe.isticks , timeframe.isweekly , timeframe.main_period , timeframe.multiplier , timeframe.period , timenow , volume , weekofyear , year
█ HOW TO USE
1 — Add the Script:
Apply "Watermark with dynamic variables " to your chart from the TradingView platform.
2 — Configure Inputs:
Open the script settings by clicking the gear icon next to the script's name.
Customize visibility, message content, and appearance for Watermark A and Watermark B.
3 — Utilize Placeholders:
Add placeholders like %bar_index% or %timenow% in the "Watermark - Message" fields to display dynamic data.
Empty lines in the message box are reflected on the chart, allowing you to shift text up or down.
Using \n in the message box translates to a new line on the chart.
4 — Preview Changes:
Adjust settings and view updates in real-time on your chart.
█ EXAMPLES
Branding
DodgyDD's charts
Debugging
█ LIMITATIONS
Only supports variables defined within the script.
Limited to four messages per watermark.
Visual alignment may vary across different chart resolutions or zoom levels.
Placeholder parsing relies on correct input formatting.
█ NOTES
This script is designed for users seeking enhanced chart annotation capabilities. It provides tools for dynamic, customizable watermarks but is not a replacement for chart objects like text labels or drawings. Please ensure placeholders are properly formatted for correct parsing.
Additionally, this script can be a valuable tool for Pine Script developers during debugging . By utilizing dynamic placeholders, developers can display real-time values of variables and chart data directly on their charts, enabling easier troubleshooting and code validation.
MoonFlag BTC Daily Swing PredictorThis script mainly works on BTC on the daily timeframe. Other coins also show similar usefulness with this script however, BTC on the daily timeframe is the main design for this script.
(Please note this is not trading advice this is just comments about how this indicator works.)
This script is predictive. It colors the background yellow when the script calculates a large BTC swing is potentially about to happen. It does not predict in which direction the swing will occur but it leads the price action so can be useful for leveraged trades. When the background gets colored with vertical yellow lines - this shows that a largish price swing is probably going to occur.
The scripts also shades bands around the price action that are used to estimate an acceptable volatility at any given time. If the bands are wide that means price action is volatile and large swings are not easily predicted. Over time, with reducing volatility, these price action bands narrow and then at a set point or percentage (%) which can be set in the script settings, the background gets colored yellow. This indicates present price action is not volatile and a large price swing is potentially going to happen in the near future. When price action breaks through the narrowing bands, the background is no longer presented because this is seen as an increase in volatility and a considerable portion of the time, a large sudden drop in price action or momentous gain in price is realized.
This indicator leads price action. It predicts that a swing is possibly going to happen in the near future. As the indicator works on the BTC daily, this means on a day-to-day basis if the bands continually narrow - a breakout is more likely to happen. In order to see how well this indicator works, have a look at the results on the screenshot provided. Note the regions where vertical yellow lines are present on the price action - and then look after these to see if a sizeable swing in price has occurred.
To use this indicator - wait until yellow vertical lines are presented on the BTC daily. Then use your experience to determine which way the price action might swing and consider entering a trade or leveraged trade in this direction. Alternatively wait a while to see in which direction the break-out occurs and considering and attempt to trade with this. Sometimes swings can be unexpected and breakout in one direction before then swinging much larger in the other. Its important to remember/consider that this indicator works on the BTC daily timeframe, so any consideration of entering a trade should be expected to cover a duration over many days or weeks, or possibly months. A large swing is only estimated every several plus months.
Most indicators are based on moving averages. A moving average is not predictive in the sense in that it lags price actions. This indicator creates bands that are based on the momentum of the price action. A change in momentum of price action therefore causes the bands to widen. When the bands narrow this means that the momentum of the price action is steady and price action volatility has converged/reduced over time. With BTC this generally means that a large swing in price action is going to occur as momentum in price action then pick-up again in one direction or another. Trying to view this using moving averages is not easy as a moving average lags price action which means that it is difficult to predict any sudden movements in price action ahead of when they might occur. Although, moving averages will converge over time in a similar manner as the bands calculated by this script. This script however, uses the price action momentum in a predictive manner to estimate where the price action might go based on present price momentum. This script therefore reacts to reduced volatility in price action much faster than a set of moving averages over various timescales can achieve.
MoonFlag
Backtesting ModuleDo you often find yourself creating new 'strategy()' scripts for each trading system? Are you unable to focus on generating new systems due to fatigue and time loss incurred in the process? Here's a potential solution: the 'Backtesting Module' :)
INTRODUCTION
Every trading system is based on four basic conditions: long entry, long exit, short entry and short exit (which are typically defined as boolean series in Pine Script).
If you can define the conditions generated by your trading system as a series of integers, it becomes possible to use these variables in different scripts in efficient ways. (Pine Script is a convenient language that allows you to use the integer output of one indicator as a source in another.)
The 'Backtesting Module' is a dynamic strategy script designed to adapt to your signals. It boasts two notable features:
⮞ It produces a backtest report using the entry and exit variables you define.
⮞ It not only serves for system testing but also to combine independent signals into a single system. (This functionality enables to create complex strategies and report on their success!)
The module tests Golden and Death cross signals by default, when you enter your own conditions the default signals will be neutralized. The methodology is described below.
PREPARATION
There are three simple steps to connect your own indicator to the Module.
STEP 1
Firstly, you must define entry and exit variables in your own script. Let's elucidate it with a straightforward example. Consider a system generating long and short signals based on the intersections of two moving averages. Consequently, our conditions would be as follows:
// Signals
long = ta.crossover(ta.sma(close, 14), ta.sma(close, 28))
short = ta.crossunder(ta.sma(close, 14), ta.sma(close, 28))
Now, the question is: How can we convert boolean variables into integer variables? The answer is conditional ternary block, defined as follows:
// Entry & Exit
long_entry = long ? 1 : 0
long_exit = short ? 1 : 0
short_entry = short ? 1 : 0
short_exit = long ? 1 : 0
The mechanics of the Entry & Exit variables are simple. The variable takes on a value of 1 when your trading system generates the signal and if your system does not produce any signal, variable returns 0. In this example, you see how exit signals can be generated in a trading system that only contains entry signals. If you have a system with original exit signals, you can also use them directly. (Please mind the NOTES section below).
STEP 2
To utilize the Entry & Exit variables as source in another script, they must be plotted on the chart. Therefore, the final detail to include in the script containing your trading system would be as follows:
// Plot The Output
plot(long_entry, "Long Entry", display=display.data_window, editable=false)
plot(long_exit, "Long Exit", display=display.data_window, editable=false)
plot(short_entry, "Short Entry", display=display.data_window, editable=false)
plot(short_exit, "Short Exit", display=display.data_window, editable=false)
STEP 3
Now, we are ready to test the system! Load the Backtesting Module indicator onto the chart along with your trading system/indicator. Then set the outputs of your system (Long Entry, Long Exit, Short Entry, Short Exit) as source in the module. That's it.
FEATURES & ORIGINALITY
⮞ Primarily, this script has been created to provide you with an easy and practical method when testing your trading system.
⮞ I thought it might be nice to visualize a few useful results. The Backtesting Module provides insights into the outcomes of both long and short trades by computing the number of trades and the success percentage.
⮞ Through the 'Trade' parameter, users can specify the market direction in which the indicator is permitted to initiate positions.
⮞ Users have the flexibility to define the date range for the test.
⮞ There are optional features allowing users to plot entry prices on the chart and customize bar colors.
⮞ The report and the test date range are presented in a table on the chart screen. The entry price can be monitored in the data window.
⮞ Note that results are based on realized returns, and the open trade is not included in the displayed results. (The only exception is the 'Unrealized PNL' result in the table.)
STRATEGY SETTINGS
The default parameters are as follows:
⮞ Initial Balance : 10000 (in units of currency)
⮞ Quantity : 10% of equity
⮞ Commission : 0.04%
⮞ Slippage : 0
⮞ Dataset : All bars in the chart
For a realistic backtest result, you should size trades to only risk sustainable amounts of equity. Do not risk more than 5-10% on a trade. And ALWAYS configure your commission and slippage parameters according to pessimistic scenarios!
NOTES
⮞ This script is intended solely for development purposes. And it'll will be available for all the indicators I publish.
⮞ In this version of the module, all order types are designed as market orders. The exit size is the sum of the entry size.
⮞ As your trading conditions grow more intricate, you might need to define the outputs of your system in alternative ways. The method outlined in this description is tailored for straightforward signal structures.
⮞ Additionally, depending on the structure of your trading system, the backtest module may require further development. This encompasses stop-loss, take-profit, specific exit orders, quantity, margin and risk management calculations. I am considering releasing improvements that consider these options in future versions.
⮞ An example of how complex trading signals can be generated is the OTT Collection. If you're interested in seeing how the signals are constructed, you can use the link below.
THANKS
Special thanks to PineCoders for their valuable moderation efforts.
I hope this will be a useful example for the TradingView community...
DISCLAIMER
This is just an indicator, nothing more. It is provided for informational and educational purposes exclusively. The utilization of this script does not constitute professional or financial advice. The user solely bears the responsibility for risks associated with script usage. Do not forget to manage your risk. And trade as safely as possible. Best of luck!
Rolling VWAP█ OVERVIEW
This indicator displays a Rolling Volume-Weighted Average Price. Contrary to VWAP indicators which reset at the beginning of a new time segment, RVWAP calculates using a moving window defined by a time period (not a simple number of bars), so it never resets.
█ CONCEPTS
If you are not already familiar with VWAP, our Help Center will get you started.
The typical VWAP is designed to be used on intraday charts, as it resets at the beginning of the day. Such VWAPs cannot be used on daily, weekly or monthly charts. Instead, this rolling VWAP uses a time period that automatically adjusts to the chart's timeframe. You can thus use RVWAP on any chart that includes volume information in its data feed.
Because RVWAP uses a moving window, it does not exhibit the jumpiness of VWAP plots that reset. You can see the more jagged VWAP on the chart above. We think both can be useful to traders; up to you to decide which flavor works for you.
█ HOW TO USE IT
Load the indicator on an active chart (see the Help Center if you don't know how).
Time period
By default, the script uses an auto-stepping mechanism to adjust the time period of its moving window to the chart's timeframe. The following table shows chart timeframes and the corresponding time period used by the script. When the chart's timeframe is less than or equal to the timeframe in the first column, the second column's time period is used to calculate RVWAP:
Chart Time
timeframe period
1min 🠆 1H
5min 🠆 4H
1H 🠆 1D
4H 🠆 3D
12H 🠆 1W
1D 🠆 1M
1W 🠆 3M
You can use the script's inputs to specify a fixed time period, which you can express in any combination of days, hours and minutes.
By default, the time period currently used is displayed in the lower-right corner of the chart. The script's inputs allow you to hide the display or change its size and location.
Minimum Window Size
This input field determines the minimum number of values to keep in the moving window, even if these values are outside the prescribed time period. This mitigates situations where a large time gap between two bars would cause the time window to be empty, which can occur in non-24x7 markets where large time gaps may separate contiguous chart bars, namely across holidays or trading sessions. For example, if you were using a 1D time period and there is a two-day gap between two bars, then no chart bars would fit in the moving window after the gap. The default value is 10 bars.
█ NOTES
If you are interested in VWAP indicators, you may find the VWAP Auto Anchored built-in indicator worth a try.
For Pine Script™ coders
The heart of this script's calculations uses the `totalForTimeWhen()` function from the ConditionalAverages library published by PineCoders . It works by maintaining an array of values included in a time period, but without a for loop requiring a lookback from the current bar, so it is much more efficient.
We write our Pine Script™ code using the recommendations in the User Manual's Style Guide .
Look first. Then leap.
Volume Spike Retracement█ OVERVIEW
-Following many people's request to add "Volume" mode again in my "Institutional OrderBlock Pressure" script. I decided to release an improved
and full-fledged script. This will be the last OB/Retracement script I will release as we have explored every possible way to find them.
█ HOW TO INTERPRET?
-The script uses the the 0.5 Pivot and the maximum value set for Volume Length to find 'Peak Volume'. Once these conditions are met,
the script starts creating a Retracement Line.
-By default, the Volume Length value is set to 89, which works well with most Timeframes following the OrderBlocks/Retracements
logic used in my scripts.
-You have the option to set Alerts when the "Volume Spike Limit" is reached or when a Price Crossing with a Line occurs.
█ NOTES
- Yes Alerts appear instantly. Moreover, they are not 'confirmed', you must ALWAYS wait for confirmation before making a choice.
Good Trade everyone and remember, risk management remains the most important!
Pinescript - Common Label & Line Array Functions Library by RRBPinescript - Common Label & Line Array Functions Library by RagingRocketBull 2021
Version 1.0
This script provides a library of common array functions for arrays of label and line objects with live testing of all functions.
Using this library you can easily create, update, delete, join label/line object arrays, and get/set properties of individual label/line object array items.
You can find the full list of supported label/line array functions below.
There are several libraries:
- Common String Functions Library
- Standard Array Functions Library
- Common Fixed Type Array Functions Library
- Common Label & Line Array Functions Library
- Common Variable Type Array Functions Library
Features:
- 30 array functions in categories create/update/delete/join/get/set with support for both label/line objects (45+ including all implementations)
- Create, Update label/line object arrays from list/array params
- GET/SET properties of individual label/line array items by index
- Join label/line objects/arrays into a single string for output
- Supports User Input of x,y coords of 5 different types: abs/rel/rel%/inc/inc% list/array, auto transforms x,y input into list/array based on type, base and xloc, translates rel into abs bar indexes
- Supports User Input of lists with shortened names of string properties, auto expands all standard string properties to their full names for use in functions
- Live Output for all/selected functions based on User Input. Test any function for possible errors you may encounter before using in script.
- Output filters: hide all excluded and show only allowed functions using a list of function names
- Output Panel customization options: set custom style, color, text size, and line spacing
Usage:
- select create function - create label/line arrays from lists or arrays (optional). Doesn't affect the update functions. The only change in output should be function name regardless of the selected implementation.
- specify num_objects for both label/line arrays (default is 7)
- specify common anchor point settings x,y base/type for both label/line arrays and GET/SET items in Common Settings
- fill lists with items to use as inputs for create label/line array functions in Create Label/Line Arrays section
- specify label/line array item index and properties to SET in corresponding sections
- select label/line SET function to see the changes applied live
Code Structure:
- translate x,y depending on x,y type, base and xloc as specified in UI (required for all functions)
- expand all shortened standard property names to full names (required for create/update* from arrays and set* functions, not needed for create/update* from lists) to prevent errors in label.new and line.new
- create param arrays from string lists (required for create/update* from arrays and set* functions, not needed for create/update* from lists)
- create label/line array from string lists (property names are auto expanded) or param arrays (requires already expanded properties)
- update entire label/line array or
- get/set label/line array item properties by index
Transforming/Expanding Input values:
- for this script to work on any chart regardless of price/scale, all x*,y* are specified as % increase relative to x0,y0 base levels by default, but user can enter abs x,price values specific for that chart if necessary.
- all lists can be empty, contain 1 or several items, have the same/different lengths. Array Length = min(min(len(list*)), mum_objects) is used to create label/line objects. Missing list items are replaced with default property values.
- when a list contains only 1 item it is duplicated (label name/tooltip is also auto incremented) to match the calculated Array Length
- since this script processes user input, all x,y values must be translated to abs bar indexes before passing them to functions. Your script may provide all data internally and doesn't require this step.
- at first int x, float y arrays are created from user string lists, transformed as described below and returned as x,y arrays.
- translated x,y arrays can then be passed to create from arrays function or can be converted back to x,y string lists for the create from lists function if necessary.
- all translation logic is separated from create/update/set functions for the following reasons:
- to avoid redundant code/dependency on ext functions/reduce local scopes and to be able to translate everything only once in one place - should be faster
- to simplify internal logic of all functions
- because your script may provide all data internally without user input and won't need the translation step
- there are 5 types available for both x,y: abs, rel, rel%, inc, inc%. In addition to that, x can be: bar index or time, y is always price.
- abs - absolute bar index/time from start bar0 (x) or price (y) from 0, is >= 0
- rel - relative bar index/time from cur bar n (x) or price from y0 base level, is >= 0
- rel% - relative % increase of bar index/time (x) or price (y) from corresponding base level (x0 or y0), can be <=> 0
- inc - relative increment (step) for each new level of bar index/time (x) or price (y) from corresponding base level (x0 or y0), can be <=> 0
- inc% - relative % increment (% step) for each new level of bar index/time (x) or price (y) from corresponding base level (x0 or y0), can be <=> 0
- x base level >= 0
- y base level can be 0 (empty) or open, close, high, low of cur bar
- single item x1_list = "50" translates into:
- for x type abs: "50, 50, 50 ..." num_objects times regardless of xloc => x = 50
- for x type rel: "50, 50, 50 ... " num_objects times => x = x_base + 50
- for x type rel%: "50%, 50%, 50% ... " num_objects times => x_base * (1 + 0.5)
- for x type inc: "0, 50, 100 ... " num_objects times => x_base + 50 * i
- for x type inc%: "0%, 50%, 100% ... " num_objects times => x_base * (1 + 0.5 * i)
- when xloc = xloc.bar_index each rel*/inc* value in the above list is then subtracted from n: n - x to convert rel to abs bar index, values of abs type are not affected
- x1_list = "0, 50, 100, ..." of type rel is the same as "50" of type inc
- x1_list = "50, 50, 50, ..." of type abs/rel/rel% produces a sequence of the same values and can be shortened to just "50"
- single item y1_list = "2" translates into (ragardless of yloc):
- for y type abs: "2, 2, 2 ..." num_objects times => y = 2
- for y type rel: "2, 2, 2 ... " num_objects times => y = y_base + 2
- for y type rel%: "2%, 2%, 2% ... " num_objects times => y = y_base * (1 + 0.02)
- for y type inc: "0, 2, 4 ... " num_objects times => y = y_base + 2 * i
- for y type inc%: "0%, 2%, 4% ... " num_objects times => y = y_base * (1 + 0.02 * i)
- when yloc != yloc.price all calculated values above are simply ignored
- y1_list = "0, 2, 4" of type rel% is the same as "2" with type inc%
- y1_list = "2, 2, 2" of type abs/rel/rel% produces a sequence of the same values and can be shortened to just "2"
- you can enter shortened property names in lists. To lookup supported shortened names use corresponding dropdowns in Set Label/Line Array Item Properties sections
- all shortened standard property names must be expanded to full names (required for create/update* from arrays and set* functions, not needed for create/update* from lists) to prevent errors in label.new and line.new
- examples of shortened property names that can be used in lists: bar_index, large, solid, label_right, white, left, left, price
- expanded to their corresponding full names: xloc.bar_index, size.large, line.style_solid, label.style_label_right, color.white, text.align_left, extend.left, yloc.price
- all expanding logic is separated from create/update* from arrays and set* functions for the same reasons as above, and because param arrays already have different types, implying the use of final values.
- all expanding logic is included in the create/update* from lists functions because it seemed more natural to process string lists from user input directly inside the function, since they are already strings.
Creating Label/Line Objects:
- use study max_lines_count and max_labels_count params to increase the max number of label/line objects to 500 (+3) if necessary. Default number of label/line objects is 50 (+3)
- all functions use standard param sequence from methods in reference, except style always comes before colors.
- standard label/line.get* functions only return a few properties, you can't read style, color, width etc.
- label.new(na, na, "") will still create a label with x = n-301, y = NaN, text = "" because max default scope for a var is 300 bars back.
- there are 2 types of color na, label color requires color(na) instead of color_na to prevent error. text_color and line_color can be color_na
- for line to be visible both x1, x2 ends must be visible on screen, also when y1 == y2 => abs(x1 - x2) >= 2 bars => line is visible
- xloc.bar_index line uses abs x1, x2 indexes and can only be within 0 and n ends, where n <= 5000 bars (free accounts) or 10000 bars (paid accounts) limit, can't be plotted into the future
- xloc.bar_time line uses abs x1, x2 times, can't go past bar0 time but can continue past cur bar time into the future, doesn't have a length limit in bars.
- xloc.bar_time line with length = exact number of bars can be plotted only within bar0 and cur bar, can't be plotted into the future reliably because of future gaps due to sessions on some charts
- xloc.bar_index line can't be created on bar 0 with fixed length value because there's only 1 bar of horiz length
- it can be created on cur bar using fixed length x < n <= 5000 or
- created on bar0 using na and then assigned final x* values on cur bar using set_x*
- created on bar0 using n - fixed_length x and then updated on cur bar using set_x*, where n <= 5000
- default orientation of lines (for style_arrow* and extend) is from left to right (from bar 50 to bar 0), it reverses when x1 and x2 are swapped
- price is a function, not a line object property
Variable Type Arrays:
- you can't create an if/function that returns var type value/array - compiler uses strict types and doesn't allow that
- however you can assign array of any type to another array of any type creating an arr pointer of invalid type that must be reassigned to a matching array type before used in any expression to prevent error
- create_any_array2 uses this loophole to return an int_arr pointer of a var type array
- this works for all array types defined with/without var keyword and doesn't work for string arrays defined with var keyword for some reason
- you can't do this with var type vars, only var type arrays because arrays are pointers passed by reference, while vars are actual values passed by value.
- you can only pass a var type value/array param to a function if all functions inside support every type - otherwise error
- alternatively values of every type must be passed simultaneously and processed separately by corresponding if branches/functions supporting these particular types returning a common single type result
- get_var_types solves this problem by generating a list of dummy values of every possible type including the source type, tricking the compiler into allowing a single valid branch to execute without error, while ignoring all dummy results
Notes:
- uses Pinescript v3 Compatibility Framework
- uses Common String Functions Library, Common Fixed Type Array Functions Library, Common Variable Type Array Functions Library
- has to be a separate script to reduce the number of local scopes/compiled file size, can't be merged with another library.
- lets you live test all label/line array functions for errors. If you see an error - change params in UI
- if you see "Loop too long" error - hide/unhide or reattach the script
- if you see "Chart references too many candles" error - change x type or value between abs/rel*. This can happen on charts with 5000+ bars when a rel bar index x is passed to label.new or line.new instead of abs bar index n - x
- create/update_label/line_array* use string lists, while create/update_label/line_array_from_arrays* use array params to create label/line arrays. "from_lists" is dropped to shorten the names of the most commonly used functions.
- create_label/line_array2,4 are preferable, 5,6 are listed for pure demonstration purposes only - don't use them, they don't improve anything but dramatically increase local scopes/compiled file size
- for this reason you would mainly be using create/update_label/line_array2,4 for list params or create/update_label/line_array_from_arrays2 for array params
- all update functions are executed after each create as proof of work and can be disabled. Only create functions are required. Use update functions when necessary - when list/array params are changed by your script.
- both lists and array item properties use the same x,y_type, x,y_base from common settings
- doesn't use pagination, a single str contains all output
- why is this so complicated? What are all these functions for?
- this script merges standard label/line object methods with standard array functions to create a powerful set of label/line object array functions to simplify manipulation of these arrays.
- this library also extends the functionality of Common Variable Type Array Functions Library providing support for label/line types in var type array functions (any_to_str6, join_any_array5)
- creating arrays from either lists or arrays adds a level of flexibility that comes with complexity. It's very likely that in your script you'd have to deal with both string lists as input, and arrays internally, once everything is converted.
- processing user input, allowing customization and targeting for any chart adds a whole new layer of complexity, all inputs must be translated and expanded before used in functions.
- different function implementations can increase/reduce local scopes and compiled file size. Select a version that best suits your needs. Creating complex scripts often requires rewriting your code multiple times to fit the limits, every line matters.
P.S. Don't rely too much on labels, for too often they are fables.
List of functions*:
* - functions from other libraries are not listed
1. Join Functions
Labels
- join_label_object(label_, d1, d2)
- join_label_array(arr, d1, d2)
- join_label_array2(arr, d1, d2, d3)
Lines
- join_line_object(line_, d1, d2)
- join_line_array(arr, d1, d2)
- join_line_array2(arr, d1, d2, d3)
Any Type
- any_to_str6(arr, index, type)
- join_any_array4(arr, d1, d2, type)
- join_any_array5(arr, d, type)
2. GET/SET Functions
Labels
- label_array_get_text(arr, index)
- label_array_get_xy(arr, index)
- label_array_get_fields(arr, index)
- label_array_set_text(arr, index, str)
- label_array_set_xy(arr, index, x, y)
- label_array_set_fields(arr, index, x, y, str)
- label_array_set_all_fields(arr, index, x, y, str, xloc, yloc, label_style, label_color, text_color, text_size, text_align, tooltip)
- label_array_set_all_fields2(arr, index, x, y, str, xloc, yloc, label_style, label_color, text_color, text_size, text_align, tooltip)
Lines
- line_array_get_price(arr, index, bar)
- line_array_get_xy(arr, index)
- line_array_get_fields(arr, index)
- line_array_set_text(arr, index, width)
- line_array_set_xy(arr, index, x1, y1, x2, y2)
- line_array_set_fields(arr, index, x1, y1, x2, y2, width)
- line_array_set_all_fields(arr, index, x1, y1, x2, y2, xloc, extend, line_style, line_color, width)
- line_array_set_all_fields2(arr, index, x1, y1, x2, y2, xloc, extend, line_style, line_color, width)
3. Create/Update/Delete Functions
Labels
- delete_label_array(label_arr)
- create_label_array(list1, list2, list3, list4, list5, d)
- create_label_array2(x_list, y_list, str_list, xloc_list, yloc_list, style_list, color1_list, color2_list, size_list, align_list, tooltip_list, d)
- create_label_array3(x_list, y_list, str_list, xloc_list, yloc_list, style_list, color1_list, color2_list, size_list, align_list, tooltip_list, d)
- create_label_array4(x_list, y_list, str_list, xloc_list, yloc_list, style_list, color1_list, color2_list, size_list, align_list, tooltip_list, d)
- create_label_array5(x_list, y_list, str_list, xloc_list, yloc_list, style_list, color1_list, color2_list, size_list, align_list, tooltip_list, d)
- create_label_array6(x_list, y_list, str_list, xloc_list, yloc_list, style_list, color1_list, color2_list, size_list, align_list, tooltip_list, d)
- update_label_array2(label_arr, x_list, y_list, str_list, xloc_list, yloc_list, style_list, color1_list, color2_list, size_list, align_list, tooltip_list, d)
- update_label_array4(label_arr, x_list, y_list, str_list, xloc_list, yloc_list, style_list, color1_list, color2_list, size_list, align_list, tooltip_list, d)
- create_label_array_from_arrays2(x_arr, y_arr, str_arr, xloc_arr, yloc_arr, style_arr, color1_arr, color2_arr, size_arr, align_arr, tooltip_arr, d)
- create_label_array_from_arrays4(x_arr, y_arr, str_arr, xloc_arr, yloc_arr, style_arr, color1_arr, color2_arr, size_arr, align_arr, tooltip_arr, d)
- update_label_array_from_arrays2(label_arr, x_arr, y_arr, str_arr, xloc_arr, yloc_arr, style_arr, color1_arr, color2_arr, size_arr, align_arr, tooltip_arr, d)
Lines
- delete_line_array(line_arr)
- create_line_array(list1, list2, list3, list4, list5, list6, d)
- create_line_array2(x1_list, y1_list, x2_list, y2_list, xloc_list, extend_list, style_list, color_list, width_list, d)
- create_line_array3(x1_list, y1_list, x2_list, y2_list, xloc_list, extend_list, style_list, color_list, width_list, d)
- create_line_array4(x1_list, y1_list, x2_list, y2_list, xloc_list, extend_list, style_list, color_list, width_list, d)
- create_line_array5(x1_list, y1_list, x2_list, y2_list, xloc_list, extend_list, style_list, color_list, width_list, d)
- create_line_array6(x1_list, y1_list, x2_list, y2_list, xloc_list, extend_list, style_list, color_list, width_list, d)
- update_line_array2(line_arr, x1_list, y1_list, x2_list, y2_list, xloc_list, extend_list, style_list, color_list, width_list, d)
- update_line_array4(line_arr, x1_list, y1_list, x2_list, y2_list, xloc_list, extend_list, style_list, color_list, width_list, d)
- create_line_array_from_arrays2(x1_arr, y1_arr, x2_arr, y2_arr, xloc_arr, extend_arr, style_arr, color_arr, width_arr, d)
- update_line_array_from_arrays2(line_arr, x1_arr, y1_arr, x2_arr, y2_arr, xloc_arr, extend_arr, style_arr, color_arr, width_arr, d)
Dual Purpose Pine Based CorrelationThis is my "Pine-based" correlation() function written in raw Pine Script. Other names applied to it are "Pearson Correlation", "Pearson's r", and one I can never remember being "Pearson Product-Moment Correlation Coefficient(PPMCC)". There is two basic ways to utilize this script. One is checking correlation with another asset such as the S&P 500 (provided as a default). The second is using it as a handy independent indicator correlated to time using Pine's bar_index variable. Also, this is in fact two separate correlation indicators with independent period adjustments, so I guess you could say this indicator has a dual purpose split personality. My intention was to take standard old correlation and apply a novel approach to it, and see what happens. Either way you use it, I hope you may find it most helpful enough to add to your daily TV tool belt.
You will notice I used the Pine built-in correlation() in combination with my custom function, so it shows they are precisely equal, even when the first two correlation() parameters are reversed on purpose or by accident. Additionally, there's an interesting technique to provide a visually appealing line with two overlapping plot()s combined together. I'm sure many members may find that plotting tactic useful when a bird's nest of plotting is occurring on the overlay pane in some scenarios. One more thing about correlation is it's always confined to +/-1.0 irregardless of time intervals or the asset(s) it is applied to, making it a unique oscillator.
As always, I have included advanced Pine programming techniques that conform to proper "Pine Etiquette". For those of you who are newcomers to Pine Script, this code release may also help you comprehend the "Power of Pine" by employing advanced programming techniques in Pine exhibiting code utilization in a most effective manner. One of the many tricks I applied here was providing floating point number safeties for _correlation(). While it cannot effectively use a floating point number, it won't error out in the event this should occur especially when applying "dominant cycle periods" to it, IF you might attempt this.
NOTICE: You may have observed there is a sqrt() custom function and you may be thinking... "Did he just sick and twistedly overwrite the Pine built-in sqrt() function?" The answer is... YES, I am and yes I did! One thing I noticed, is that it does provide slightly higher accuracy precision decimal places compared to the Pine built-in sqrt(). Be forewarned, "MY" sqrt() is technically speaking slower than snail snot compared to the native Pine sqrt(), so I wouldn't advise actually using it religiously in other scripts as a daily habit. It is seemingly doing quite well in combination with these simple calculations without being "sluggish". Lastly, of course you may always just delete the custom sqrt() function, via Pine Editor, and then the script will still operate flawlessly, yet more efficiently.
Features List Includes:
Dark Background - Easily disabled in indicator Settings->Style for "Light" charts or with Pine commenting
AND much, much more... You have the source!
The comments section below is solely just for commenting and other remarks, ideas, compliments, etc... regarding only this indicator, not others. When available time provides itself, I will consider your inquiries, thoughts, and concepts presented below in the comments section, should you have any questions or comments regarding this indicator. When my indicators achieve more prevalent use by TV members, I may implement more ideas when they present themselves as worthy additions. As always, "Like" it if you simply just like it with a proper thumbs up, and also return to my scripts list occasionally for additional postings. Have a profitable future everyone!
