Moxie Indicator for ThinkorSwim

Hi Slippage,
The approximation using 2x's period is accurate for H2, and makes the "together" calculation more accurate since the same stair steps (h1) are used. So that is a good way to do it, the results will be as good or better than separate H1/H2 aggregation periods.

I like the simple together and'ing of the last 4 bars, but I think that each of the bars is going to be the same value, since on the H1 stair step, so may be possible to just check latest together bar.

Using this period multiplication vs HTF aggregation period approach can be used for all timeframes, which would eliminate the repainting, everything would be calculated bar by bar in the current timeframe. Staircase can be added using quantization if it is useful. This is just a suggestion as it provides a "continuous" HTF line vs the stairstep. The advantage of this is that the zero cross will be more timely/definitive than the HTF repainting bar, but will be more dynamic.

no-repaint.png


For the scan I'm still using the HTF for the main moxie line (cyan). And then the doubled lengths to approximate the second line. You can see the lower line in the non-HTF version crosses zero significantly later. This looks potentially unusable. Maybe useful in its own way but definitely doesn't match Moxie. I'll do some testing later to see which seems like a better signal with a single line on D and H timeframes since those are more critical to the strategy. Also to see how it affects divergence.

About the last 4 bars thing, it's the last 4 scan periods. So 4 hours the way I posted it which is probably too many. I mentioned that to the folks I shared it with in the Mastery room, that we should experiment with how many periods we require them together so it doesn't take too long to show up in scans.
 

Volatility Trading Range

VTR is a momentum indicator that shows if a stock is overbought or oversold based on its Weekly and Monthly average volatility trading range.

Download the indicator

no-repaint.png


For the scan I'm still using the HTF for the main moxie line (cyan). And then the doubled lengths to approximate the second line. You can see the lower line in the non-HTF version crosses zero significantly later. This looks potentially unusable. Maybe useful in its own way but definitely doesn't match Moxie. I'll do some testing later to see which seems like a better signal with a single line on D and H timeframes since those are more critical to the strategy. Also to see how it affects divergence.

About the last 4 bars thing, it's the last 4 scan periods. So 4 hours the way I posted it which is probably too many. I mentioned that to the folks I shared it with in the Mastery room, that we should experiment with how many periods we require them together so it doesn't take too long to show up in scans.
Humm, this looks strange. I think it has to do with doubling the a2 average to 18. Could you try showing a 3rd graph with a2 ave = 9 to see if that helps?
 
ctive-Trader-490509867-Main-thinkorswim-build-1967.png


Here's a 1H chart with the real Moxie, this thread's Moxie and then this experiment. It actually isn't bad. The crosses are slightly sooner which is what we expected and I don't see any other problems with it. I still need to check divergence but this matches the others so well I'm not too worried about it.

While not having the stair steps makes the coloring a little ugly when it's alternating quickly, I think that might actually be an improvement also. If using Moxie to time a reversal instead of using the official Moxie strategy the first candle that closes with Moxie green might be the entry and the stair steps might not show that as quickly.

Also, after more thought and hearing TG talk about it more in the class videos, I think he actually did write Moxie himself. So I shouldn't judge the code so harshly. It's not bad for a non-coder -- it works and he's making money both trading it and selling it. But when it comes to the stair steps, I'm certain that wasn't intentional and just the result of the HTF. The same is true with the multiple arrows on the upper study. He said he wanted just one arrow but the developer he paid to write the upper study said it's a TOS thing and he's going to have to live with it.

ETA: Divergences look fine. There is something a little more striking about the stair steps while looking for divergence but pretty much no other indicators have that so I don't think it's a big deal.

I'm noticing many of the earlier vertical lines for crossing zero in this experiment line up within a batch of arrows on the upper study so probably aren't really an earlier signal. It's just that on the HTF version the line isn't drawn until the end of the HTF period. However, I did see one case where the signal from this new code was at the end of the day prior to the signal from the normal version.

Another benefit was a case where the HTF versions went over/under/over in a short time while the experiment stayed steady. Well, after looking at more stocks I see the new one gets jittery too, worse in some cases.
 
Last edited:
ctive-Trader-490509867-Main-thinkorswim-build-1967.png


Here's a 1H chart with the real Moxie, this thread's Moxie and then this experiment. It actually isn't bad. The crosses are slightly sooner which is what we expected and I don't see any other problems with it. I still need to check divergence but this matches the others so well I'm not too worried about it.

While not having the stair steps makes the coloring a little ugly when it's alternating quickly, I think that might actually be an improvement also. If using Moxie to time a reversal instead of using the official Moxie strategy the first candle that closes with Moxie green might be the entry and the stair steps might not show that as quickly.

Also, after more thought and hearing TG talk about it more in the class videos, I think he actually did write Moxie himself. So I shouldn't judge the code so harshly. It's not bad for a non-coder -- it works and he's making money both trading it and selling it. But when it comes to the stair steps, I'm certain that wasn't intentional and just the result of the HTF. The same is true with the multiple arrows on the upper study. He said he wanted just one arrow but the developer he paid to write the upper study said it's a TOS thing and he's going to have to live with it.
If the top one is Moxie, and the second one is your code with H1 HTF, I think there is a slight diff between the two (maybe due to using EMA (vs SMA) for a2 ave (note, OA and standard MACD Hist / OsMA use SMA I think, so maybe Moxie uses it too).

And on the 3rd one, what exactly is that (ie is that diff=MA(12*4)-MA(26*4); plot = diff - MA(diff,9) ?

And on TG and Moxie code, absolutely, hats off to him on pulling all that together.
 
If the top one is Moxie, and the second one is your code with H1 HTF, I think there is a slight diff between the two (maybe due to using EMA (vs SMA) for a2 ave (note, OA and standard MACD Hist / OsMA use SMA I think, so maybe Moxie uses it too).

I don't notice any difference. I double checked real Moxie's code again and it's ExpAverage on everything.

And on the 3rd one, what exactly is that (ie is that diff=MA(12*4)-MA(26*4); plot = diff - MA(diff,9) ?

In that pic it was hard coded to 7 hours in a day, since that's how many arrows the Moxie upper study decides to show. Using length*7 on all three lengths.

After that, since the enumerations in TOS are keyed with the number of milliseconds they represent I updated the existing if else blocks to divide the higher timeframe by the current timeframe. That way I can still avoid specifying multiple timeframes with the same multiple like I avoided specifying multiple timeframes with the same higher timeframe. However, I expect some that aren't evenly divisible are going to be messed up so I'm testing them all and I'll hard code something for those.

I removed the multiplier from the length in the average for the 15m second line. Now, both of the 15m lines look fine if I turn off the other plot. The second line still looks very wrong when both plots are showing. I'm going to test/fix the other timeframes and then get back to the 15m problems.

ETA: Actually, I had to put the multiplier back in and hardcode that there's 7 15m periods in 2 hours. Funky math but it looks good now. Before the lines were very far apart when they shouldn't be. Now they're tight when they should be.
 
Last edited:
And here it is. It definitely has a bit different shape in some places with divergences, though I don't see that in this particular image. The new one reacts faster and dips with price while the real moxy is oblivious and goes higher. But there's other times when the faster reaction shows the divergence sooner. So I'm not sure if one is really better than the other. The distance between the two lines for 15m is probably a better representation this way though than with the delay and the stair steps.

Getting rid of the higher timeframe makes a big difference in loading time also, as I expected.

I got this working in my version that has the extra day trading thing from the class. I'll going to eat something and then I'll update the version from this thread.

ctive-Trader-490509867-Main-thinkorswim-build-1967.png
 
Here's Moxie with no higher timeframes. The resulting line is drawn slightly differently than the real Moxie, more or less arriving at the same result in most cases but it affects the shape of the line so the signals may be different from the real Moxie and may cause confusion in the Moxie Mastery trading room if you're talking about things you see in this one. I'll probably run both until I get a feel for which I like better but I'm going to use the arrows from this version so it shows only the trigger candle.

Ruby:
declare lower;

input showVerticalLines = yes;
input showTrampolines = yes;
input showSqueezeDots = no;
input showLabel = yes;

plot ZeroLine = 0;
ZeroLine.SetDefaultColor(Color.GRAY);
ZeroLine.SetLineWeight(2);
ZeroLine.HideBubble();
ZeroLine.HideTitle();

def currentAggPeriod = GetAggregationPeriod();
def multiplier =
  if currentAggPeriod <= AggregationPeriod.TWO_MIN then AggregationPeriod.FIVE_MIN / currentAggPeriod
  else if currentAggPeriod <= AggregationPeriod.THREE_MIN then AggregationPeriod.TEN_MIN / currentAggPeriod
  else if currentAggPeriod <= AggregationPeriod.FIVE_MIN then AggregationPeriod.FIFTEEN_MIN / currentAggPeriod
  else if currentAggPeriod <= AggregationPeriod.TEN_MIN then AggregationPeriod.THIRTY_MIN / currentAggPeriod
  else if currentAggPeriod <= AggregationPeriod.FIFTEEN_MIN then AggregationPeriod.HOUR / currentAggPeriod
  else if currentAggPeriod <= AggregationPeriod.THIRTY_MIN then AggregationPeriod.TWO_HOURS / currentAggPeriod
  else if currentAggPeriod <= AggregationPeriod.HOUR then 7
  else if currentAggPeriod <= AggregationPeriod.TWO_HOURS then 3
  else if currentAggPeriod <= AggregationPeriod.FOUR_HOURS then 3 # yes, weird, but this matches better
  else if currentAggPeriod <= AggregationPeriod.DAY then 5
  else if currentAggPeriod <= AggregationPeriod.WEEK then AggregationPeriod.MONTH / currentAggPeriod
  else AggregationPeriod.QUARTER / currentAggPeriod
;

script MoxieFunc {
  input factor = 1;
  def v = ExpAverage(close, 12*factor) - ExpAverage(close, 26*factor);
  def a = ExpAverage(v, 9*factor);
  plot m = (v - a) * 3;
}

plot Moxie = MoxieFunc(multiplier);

Moxie.SetLineWeight(2);
Moxie.DefineColor("Up", Color.UPTICK);
Moxie.DefineColor("Down", Color.RED);
Moxie.AssignValueColor(
  if Moxie < Moxie[1] then Moxie.Color("Down")
  else Moxie.Color("Up")
);
Moxie.HideBubble();
Moxie.HideTitle();

# Watkins uses a different setup for Moxie on his 15 minute charts.
# He uses two lines derived from two higher timeframes.
def secondMultiplier =
  if currentAggPeriod == AggregationPeriod.FIFTEEN_MIN then 7
  else currentAggPeriod
;

plot MoxieSecondLine =
  if currentAggPeriod == AggregationPeriod.FIFTEEN_MIN
  then MoxieFunc(secondMultiplier)
  else Double.NaN
;

MoxieSecondLine.SetLineWeight(2);
MoxieSecondLine.DefineColor("Up", Color.UPTICK);
MoxieSecondLine.DefineColor("Down", Color.RED);
MoxieSecondLine.AssignValueColor(
  if MoxieSecondLine < MoxieSecondLine[1] then MoxieSecondLine.Color("Down")
  else MoxieSecondLine.Color("Up")
);
MoxieSecondLine.HideBubble();
MoxieSecondLine.HideTitle();
MoxieSecondLine.SetHiding(currentAggPeriod != AggregationPeriod.FIFTEEN_MIN);

# Show vertical lines at crossovers
AddVerticalLine(showVerticalLines and Moxie[1] crosses above 0, "", CreateColor(0,150,0), Curve.SHORT_DASH);
AddVerticalLine(showVerticalLines and Moxie[1] crosses below 0, "", CreateColor(200,0,0), Curve.SHORT_DASH);

# Indicate the Trampoline setup
def sma50 = Average(close, 50);
plot Trampoline =
  if showTrampolines and ((Moxie < -.01 and close > sma50) or (Moxie > .01 and close < sma50))
  then 0
  else Double.NaN
;
Trampoline.SetPaintingStrategy(PaintingStrategy.SQUARES);
Trampoline.DefineColor("Bullish", Color.LIGHT_GREEN);
Trampoline.DefineColor("Bearish", Color.PINK);
Trampoline.AssignValueColor(if close > sma50 then Trampoline.Color("Bearish") else Trampoline.Color("Bullish"));
Trampoline.HideBubble();
Trampoline.HideTitle();

# show squeeze dots on zero line
def bb = reference BollingerBands.LowerBand;
def squeezeLevel = 
  if bb > KeltnerChannels(factor = 1.0).Lower_Band then 3
  else if bb > KeltnerChannels(factor = 1.5).Lower_Band then 2
  else if bb > KeltnerChannels(factor = 2.0).Lower_Band then 1
  else 0
;

plot Squeeze = if !showSqueezeDots then Double.NaN else 0;
Squeeze.SetPaintingStrategy(PaintingStrategy.POINTS);
Squeeze.SetDefaultColor(Color.GRAY);
Squeeze.DefineColor("Loose Squeeze", Color.UPTICK);
Squeeze.DefineColor("Squeeze", Color.RED);
Squeeze.DefineColor("Tight Squeeze", Color.YELLOW);
Squeeze.DefineColor("No Squeeze", Color.GRAY);
Squeeze.AssignValueColor(
  if squeezeLevel == 3 then Squeeze.Color("Tight Squeeze")
  else if squeezeLevel == 2 then Squeeze.Color("Squeeze")
  else if squeezeLevel == 1 then Squeeze.Color("Loose Squeeze")
  else Squeeze.Color("No Squeeze")
);
Squeeze.HideTitle();
Squeeze.HideBubble();

AddLabel(
  showLabel,
  if currentAggPeriod == AggregationPeriod.WEEK then " W "
  else if currentAggPeriod == AggregationPeriod.DAY then " D "
  else if currentAggPeriod == AggregationPeriod.HOUR then " H "
  else if currentAggPeriod == AggregationPeriod.FIFTEEN_MIN then " 15 "
  else if currentAggPeriod == AggregationPeriod.FIVE_MIN then " 5 "
  else if currentAggPeriod == AggregationPeriod.TWO_MIN then " 2 "
  else " ",
  if Moxie < 0 then Color.RED else Color.GREEN
);

The upper study now shows only one arrow instead of a series of them. It's showing the candle that actually triggered instead of all the days that week or all the hours that day, etc. If you find it harder to notice the arrow in the chart you can modify the color and/or size to see if that helps. The arrow might still appear and disappear until the trigger candle closes but once that candle closes it won't change any more.

The upper study can now color your candles to match Moxie. Disabled by by default.

Upper study
Ruby:
declare upper;

input colorCandles = no;

def currentAggPeriod = GetAggregationPeriod();
def multiplier =
  if currentAggPeriod <= AggregationPeriod.TWO_MIN then AggregationPeriod.FIVE_MIN / currentAggPeriod
  else if currentAggPeriod <= AggregationPeriod.THREE_MIN then AggregationPeriod.TEN_MIN / currentAggPeriod
  else if currentAggPeriod <= AggregationPeriod.FIVE_MIN then AggregationPeriod.FIFTEEN_MIN / currentAggPeriod
  else if currentAggPeriod <= AggregationPeriod.TEN_MIN then AggregationPeriod.THIRTY_MIN / currentAggPeriod
  else if currentAggPeriod <= AggregationPeriod.FIFTEEN_MIN then AggregationPeriod.HOUR / currentAggPeriod
  else if currentAggPeriod <= AggregationPeriod.THIRTY_MIN then AggregationPeriod.TWO_HOURS / currentAggPeriod
  else if currentAggPeriod <= AggregationPeriod.HOUR then 7
  else if currentAggPeriod <= AggregationPeriod.TWO_HOURS then 3
  else if currentAggPeriod <= AggregationPeriod.FOUR_HOURS then 3 # yes, weird, but this matches better
  else if currentAggPeriod <= AggregationPeriod.DAY then 5
  else if currentAggPeriod <= AggregationPeriod.WEEK then AggregationPeriod.MONTH / currentAggPeriod
  else AggregationPeriod.QUARTER / currentAggPeriod
;

script MoxieFunc {
  input factor = 1;
  def v = ExpAverage(close, 12*factor) - ExpAverage(close, 26*factor);
  def a = ExpAverage(v, 9*factor);
  plot m = (v - a) * 3;
}

def Moxie = MoxieFunc(multiplier);

def longArrowPosition = if Moxie > 0 and Moxie[1] <= 0 then low else Double.NaN;
plot LongArrow = longArrowPosition;
LongArrow.SetPaintingStrategy(PaintingStrategy.ARROW_UP);
LongArrow.SetDefaultColor(Color.GREEN);
LongArrow.SetLineWeight(5);
LongArrow.HideBubble();
LongArrow.HideTitle();

def shortArrowPosition = if Moxie < 0 and Moxie[1] >= 0 then high else Double.NaN;
plot ShortArrow = shortArrowPosition;
ShortArrow.SetPaintingStrategy(PaintingStrategy.ARROW_DOWN);
ShortArrow.SetDefaultColor(Color.LIGHT_RED);
ShortArrow.SetLineWeight(5);
ShortArrow.HideBubble();
ShortArrow.HideTitle();

AssignPriceColor(if !colorCandles then Color.CURRENT else if Moxie < Moxie[1] then Color.RED else Color.UPTICK);
 
Last edited:
How about now?

Yes, I see the images now. Is that the watchlist column Simpler Trading includes with the indicator? I haven't tried it yet but your image looks familiar, probably from screenshots people posted in the mastery room or maybe one of TG's videos.

I haven't planned to do any watchlist columns since I already have lots of "loading" and "custom subscription limit exceeded" messages from my RVol and Squeeze columns. Those messages aren't something we can fix in code. It's a TOS issue and the only way I know of to avoid it is to have less symbols loaded in the watchlists and scans that have custom columns. Is there something useful you wish you had in the watchlist that isn't already there?
 
I actually don't have the watchlist at all, these are just screenshots! really would like to have these watchlist columns let me know if possible! All columns would be useful! - trigger, below, above, and crossing!
 
I actually don't have the watchlist at all, these are just screenshots! really would like to have these watchlist columns let me know if possible! All columns would be useful! - trigger, below, above, and crossing!

Sorry. Since I paid and have access to the original Moxie code I can't rightly build that for you. Anyone else here who is interested could do it though. Or, of course, you could pay for Moxie.
 
Last edited:
I was thinking... what if I trade squeezes using Moxie as the momentum indicator instead of Squeeze's momo? I browsed some charts and it seems, at first glance, to work well trading the squeeze directionally based on Moxie's color, ignoring whether it's above or below zero. So the next logical step is to merge the two. I'll be updating the latest code to plot the SqueezePro dots on Moxie's zero line. You'll be able to turn on or off the squeeze just like you can turn on or off the trampolines. Unfortunately turning them both on doesn't look great, though. Maybe I can come up with a different way to represent trampolines in the lower study. Here it is with just squeeze turned on (non-standard dot colors). This helps declutter my charts.

ctive-Trader-490509867-Main-thinkorswim-build-1967.png
 
I don't notice any difference. I double checked real Moxie's code again and it's ExpAverage on everything.



In that pic it was hard coded to 7 hours in a day, since that's how many arrows the Moxie upper study decides to show. Using length*7 on all three lengths.

After that, since the enumerations in TOS are keyed with the number of milliseconds they represent I updated the existing if else blocks to divide the higher timeframe by the current timeframe. That way I can still avoid specifying multiple timeframes with the same multiple like I avoided specifying multiple timeframes with the same higher timeframe. However, I expect some that aren't evenly divisible are going to be messed up so I'm testing them all and I'll hard code something for those.

I removed the multiplier from the length in the average for the 15m second line. Now, both of the 15m lines look fine if I turn off the other plot. The second line still looks very wrong when both plots are showing. I'm going to test/fix the other timeframes and then get back to the 15m problems.

ETA: Actually, I had to put the multiplier back in and hardcode that there's 7 15m periods in 2 hours. Funky math but it looks good now. Before the lines were very far apart when they shouldn't be. Now they're tight when they should be.
Good stuff !

On the a2 use of EMA, thanks for verifying... maybe rendering issue or maybe, my eyes are getting fuzzy :)
On all the Periods using the same scaler/multiplier, using same mult for all 3 period seems like what it should be.
On the use of if statements to set multiply, not sure if TOS allows AggregationPeriod in switch statements, but if all that code is executed every tick, maybe that would help performance a little bit, and you can decide what value to use rather than have integer rounding (and maybe a bit more readable too?), possibly something like:

Code:
def currentAggPeriod = GetAggregationPeriod();

secondMultiplier = 0;
switch (currentAggPeriod) {
case AggregationPeriod.MIN:     multiplier = 5;
case AggregationPeriod.TWO_MIN: multiplier = 3;
...
case  AggregationPeriod.FIFTEEN_MIN: multiplier = 4; secondMultiplier = 7;

...

And on the use of TTM _Squeeze, I like the integration, but I wonder if use of 3 Keltner settings will add much over just using 1. Certainly takes a bit to get used to the green, red, yellow as those colors don't resonate with me as to the 3 keltner/squeeze levels.
 
Last edited:
On the a2 use of EMA, thanks for verifying... maybe rendering issue or maybe, my eyes are getting fuzzy :)

I actually checked TOS's built-in MACD too and it's also using exponential for all of those. I might not have had the two indicators sized the same vertically so that may explain any differences your eyes were catching. I spent a long time, when I first started working on this, going through TG's videos and and comparing our results to his so I was already confident in the calculations, even more so since I've seen his code. In all that testing I saw one 15m period, one time, that colored differently from his. If I remember correctly, it was caused by being equal to the previous period and his code handled it differently from ours.

On the use of if statements to set multiply, not sure if TOS allows AggregationPeriod in switch statements, but if all that code is executed every tick, maybe that would help performance a little bit

Actually, the way if then else blocks, switch statements and multi-part conditions using and and or all work is they "short circuit" and skip the rest of the code once they have a definite answer. For instance, if you have def result = 1==2 and 2==2; it will never even look at the second condition because the final result can't be anything but false. No need to waste CPU cycles calculating more things. Switch statements execute the same way as if statements in ThinkScript, it's just a stylistic difference, since no break statement is available. It still does an equality check on every case to see if it's a match before it moves to the next and once it finds a match it skips the rest. In real programming languages, you can use a switch statement to allow code to "fall through" to subsequent cases by omitting the break statement in the nested code for that case. That can create a different flow from if then else. Some inexperienced programmers overuse them and let them grow out of control and you'll find switch is kind of out of favor, generally, with developers. This thread has some opinions about that if you care: https://stackoverflow.com/questions/4417070/switch-statements-are-bad

And on the use of TTM _Squeeze, I like the integration, but I wonder if use of 3 Keltner settings will add much over just using 1. Certainly takes a bit to get used to the green, red, yellow as those colors don't resonate with me as to the 3 keltner/squeeze levels.

The 3 levels is what makes SqueezePRO different from TTM_Squeeze. So, I mimicked the paid version. John Carter said he created the 3 levels because he felt the single level was missing tradable setups where the squeezes just weren't quite tight enough. There's a squeeze aficionado YouTuber I find kind of irritating and I can't stand to listen to him for very long. He stated he doubles his risk for the yellow squeezes. So I guess there's a way to use them being colored differently.

For me, John Carter's colors are hideous. TTM_Squeeze is probably the ugliest indicator I've ever seen and SqueezePRO continues that. Prior to the 3 levels, I replaced Carter's green with black or dark gray so I'd only see red dots. The official SqueezePRO still uses green for no squeeze and red for original squeeze. It uses black for the loose squeeze and what people refer to as gold for the tight squeeze but it's actually called light orange in ThinkScript. I guess the gold association with money is nice, though.

I already had my squeeze colors before I ever saw his charts but, coincidentally, TG Watkins uses almost the same colors I do, just with light gray instead of gray for non-squeeze dots. For Moxie disciples the green/red/yellow will be familiar. Though the colors are applied by code, I made it so you can still control them via the settings panel so it's easy for non-coders. Or anyone can change the code, if comfortable, to get the desired colors by default.

Also, the gray for non-squeeze matches Moxie's gray zero line.

Maybe we should rename this to SquoxiePRO now.
 
Last edited:
I actually checked TOS's built-in MACD too and it's also using exponential for all of those. I might not have had the two indicators sized the same vertically so that may explain any differences your eyes were catching. I spent a long time, when I first started working on this, going through TG's videos and and comparing our results to his so I was already confident in the calculations, even more so since I've seen his code. In all that testing I saw one 15m period, one time, that colored differently from his. If I remember correctly, it was caused by being equal to the previous period and his code handled it differently from ours.



Actually, the way if then else blocks, switch statements and multi-part conditions using and and or all work is they "short circuit" and skip the rest of the code once they have a definite answer. For instance, if you have def result = 1==2 and 2==2; it will never even look at the second condition because the final result can't be anything but false. No need to waste CPU cycles calculating more things. Switch statements execute the same way as if statements in ThinkScript, it's just a stylistic difference, since no break statement is available. It still does an equality check on every case to see if it's a match before it moves to the next and once it finds a match it skips the rest. In real programming languages, you can use a switch statement to allow code to "fall through" to subsequent cases by omitting the break statement in the nested code for that case. That can create a different flow from if then else. Some inexperienced programmers overuse them and let them grow out of control and you'll find switch is kind of out of favor, generally, with developers. This thread has some opinions about that if you care: https://stackoverflow.com/questions/4417070/switch-statements-are-bad



The 3 levels is what makes SqueezePRO different from TTM_Squeeze. So, I mimicked the paid version. John Carter said he created the 3 levels because he felt the single level was missing tradable setups where the squeezes just weren't quite tight enough. There's a squeeze aficionado YouTuber I find kind of irritating and I can't stand to listen to him for very long. He stated he doubles his risk for the yellow squeezes. So I guess there's a way to use them being colored differently.

For me, John Carter's colors are hideous. TTM_Squeeze is probably the ugliest indicator I've ever seen and SqueezePRO continues that. Prior to the 3 levels, I replaced Carter's green with black or dark gray so I'd only see red dots. The official SqueezePRO still uses green for no squeeze and red for original squeeze. It uses black for the loose squeeze and what people refer to as gold for the tight squeeze but it's actually called light orange in ThinkScript. I guess the gold association with money is nice, though.

I already had my squeeze colors before I ever saw his charts but, coincidentally, TG Watkins uses almost the same colors I do, just with light gray instead of gray for non-squeeze dots. For Moxie disciples the green/red/yellow will be familiar. Though the colors are applied by code, I made it so you can still control them via the settings panel so it's easy for non-coders. Or anyone can change the code, if comfortable, to get the desired colors by default.

Also, the gray for non-squeeze matches Moxie's gray zero line.

Maybe we should rename this to SquoxiePRO now.
Thanks for the explanation on all points. Using EMA does cut the lags vs SMA, which is good. So does reducing the MA periods. Since I don't use TOS, when I looked at the syntax, I found it strange there was no break, so thanks for the compiler explanation. I assumed that they didn't allow fall through to next case, thus no break, but to not optimize switch, that is weird. Maybe I will download and play around with it a bit so I can find out these things on my own...
 
Thanks for the explanation on all points. Using EMA does cut the lags vs SMA, which is good.

It's no problem. There's some other advantages, too. With EMA you get results before the number of periods exist for the specified length. For IPOs you don't have to wait like with SMA which draws nothing until it has enough periods. Currently, only the vertical lines are drawn until many days after the IPO because trampoline and squeeze both use simple averages. For some reason TOS won't draw any plots until it can draw all the plots in the same study.

With the ifs instead of switches there are some other advantages, too. You can see with the ifs I used <= so ranges of timeframes all get the same values. That saves a couple of lines of code -- I never had to specify the value for 1m and some others -- but more importantly it also enables non-standard timeframes. This non-HTF Moxie works on 39m and 78m charts, which are somewhat popular with Simpler Trading followers. The real Moxie doesn't work at all for those timeframes because for some reason TOS doesn't let you access any HTF when your current timeframe is non-standard. In this case non-standard defined as not existing in the AggregationPeriod enumeration.

Though, for anyone reading this who plans to use it on non-standard timeframes, you'll have to test and possibly modify the multiplier to get useful signals. I haven't tested anything except TG's timeframes to make sure this indicator's results match pretty closely to the real Moxie.
 
Last edited:
@Slippage. Love the idea of combining TTM Squeeze Pro with the Moxie and the change of color to indicate squeeze direction. Did you create the code for that as I'd love to clean up my chart screen. Great work and very thankful for your hard work.
 
@Slippage. Love the idea of combining TTM Squeeze Pro with the Moxie and the change of color to indicate squeeze direction. Did you create the code for that as I'd love to clean up my chart screen. Great work and very thankful for your hard work.

I hadn't planned to touch the version that matches official Moxie any more, to avoid any potential legal trouble after the date I got their official source code, but I went ahead and added squeeze to it now. That's an enhancement unrelated to the real Moxie's code anyway.

I also switched both versions to use Bollinger Bands and Keltner Channels to calculate the squeezes instead of TTM_Squeeze. This way it avoids wasting CPU calculating the TTM_Squeeze histogram that we're not using. It's still a little wasteful calculating bands we're not using but it's a lot more readable code than recreating Bollinger and Keltner.
 
Last edited:

New Indicator: Buy the Dip

Check out our Buy the Dip indicator and see how it can help you find profitable swing trading ideas. Scanner, watchlist columns, and add-ons are included.

Download the indicator

Similar threads

Not the exact question you're looking for?

Start a new thread and receive assistance from our community.

87k+ Posts
476 Online
Create Post

Similar threads

Similar threads

The Market Trading Game Changer

Join 2,500+ subscribers inside the useThinkScript VIP Membership Club
  • Exclusive indicators
  • Proven strategies & setups
  • Private Discord community
  • ‘Buy The Dip’ signal alerts
  • Exclusive members-only content
  • Add-ons and resources
  • 1 full year of unlimited support

Frequently Asked Questions

What is useThinkScript?

useThinkScript is the #1 community of stock market investors using indicators and other tools to power their trading strategies. Traders of all skill levels use our forums to learn about scripting and indicators, help each other, and discover new ways to gain an edge in the markets.

How do I get started?

We get it. Our forum can be intimidating, if not overwhelming. With thousands of topics, tens of thousands of posts, our community has created an incredibly deep knowledge base for stock traders. No one can ever exhaust every resource provided on our site.

If you are new, or just looking for guidance, here are some helpful links to get you started.

What are the benefits of VIP Membership?
VIP members get exclusive access to these proven and tested premium indicators: Buy the Dip, Advanced Market Moves 2.0, Take Profit, and Volatility Trading Range. In addition, VIP members get access to over 50 VIP-only custom indicators, add-ons, and strategies, private VIP-only forums, private Discord channel to discuss trades and strategies in real-time, customer support, trade alerts, and much more. Learn all about VIP membership here.
How can I access the premium indicators?
To access the premium indicators, which are plug and play ready, sign up for VIP membership here.
Back
Top