Figured out the 461.21 value that I could not work around.

 So, I created a second framework because I ran into a problem with the first framework and thought I found a workaround, but found the same strange ratio in the second framework too.  There was a value I am calling the ratio.  it is 1/461.21. It is the place where hc = G = 1. If you push it down in one place it pops back out in another place.  Even if you scale c to 1 it shows up in the unit scaling ratio at that point. You cannot get rid of it. 

 c 1.0e+0 1/c 1.0e+0 m/2.997924e+8 m_P=1.0e+0 kg/1.8330081e+7 s_t=9.8107754e+7

 h=9.81077547e+7 ratio 1.4806326002e+41  hc=9.810775475e+7  G=9.8107754757e+7

 h  =   s_t * m_P / c 9.810775475779025e+7 * 1.0e+0 / 1.0e+0

If you go past that 461.21 speed of light to smaller units it just pushes the value into the  scaling factor to be correct.  You eventually get to h=hc=G but at a non zero value. I am not sure why this happens.  In theory you can just say they are all one and the math would work the same.  an ungodly amount of energy will move a huge amount of mass a light second.

In the first framework I found that when I set the length scaling to get a c of  that ratio speed of light and the mass_scaling to 1.


c 461.212546 1/c 0.00216819774 s_length^1/3 1.0 length 650009.330  m_P 1.0 mass 18330085.7

 h=2.168197741662696785997728e-3  hc=9.99999999999e-1  G=9.9999999999999777e-1 

 h=1.000000000*1.000000000/461.2125457   hc=1.000000000*1.000000000   G=1.000000000/1.000000000

 m 1.01928741766521E-8 s_t 1.01928741766521E-8 1.01928741766521E-8  0.00000470108144695124

 s_length^1/3 * c = 4.61212545693890636839788844884107163320912305845647e+2

The key is the following line:

1.000000000*1.000000000/461.2125457  

This is the length scaling times the mass scaling and you can see that you just have the 1/c left that is in the formula to shine through

If you go past this point then hc and G will no longer be equal again.  

This is similar in the second framework:

c 4.61212545e+2 1/c 2.168197741e-3 m/6.50009330e+5 m_P=1.0e+0 kg/1.833008570e+7 s_t=1.019287e-8

 h=2.168197741662703e-3 ratio 3.272222739239643e+30  hc=9.99999999999e-1  G=9.999999999999e-1

 h  = c**2 * m_P * s_t 2.127170123054392e+5 * 1.0e+0 * 1.019287417665212e-8 

Here you can see it is the same thing, just inverted and powers  rolled into the formula from the denominator.

The second framework:

m_P_old   = sqrt (hc/G)         = 5.455511861334621e-08 kg
s_len_old = sqrt (hc/G)

m_P = m_P_old * mass_scaling
c = c_old * length scaling
s_t = (s_len_old * (length_scaling)**3) / c**3
This is where it rolls c^3 into the s_t denominator.

G = c^3 * s_t / m_P

hc= c^3 * m_P * s_t  

E = c^3 * m_P * s_t / λ

h = c^2 * m_P * s_t   

E = c^2 * m_P * s_t * f 

p = c^1 * m_P * s_t * f

m =       m_P * s_t * f

And here is the kicker, they are both equally valid.  I cannot see that one is better than the other.  This second version just rotates the powers of c from the denominator to the numerator by rolling a 1/c^3 into the s_t unit,  and changes from directly scaling the length to scaling the time, moving the time to the numerator and just canceling out one of the times of the powers of c. It is really quite elegant. 

But both frameworks decrease by powers of 1/c.  There is no getting around powers of 1/c in any framework dealing with h.