jimjkelly / missile-defense Goto Github PK

The following test values have also been posted on Desmos, where they can be tested against any number of warheads. They can also be freely modified for other tests. Let me know if it doesn't work for any reason
https://www.desmos.com/calculator/dgiqvuwmf3

Distance in Meters, Yield in Kilotons of TNT equivalent, Hardness in PSI
Y=yield
H=Harness
R=reliability
W=Warheads
i=Number of Interceptors Committed per Incoming Target
Ptrack = P(track)= Probability of the Defensive System detecting and tracking incoming target
Case 1:

OFFENSE
For Groundburst Offensive:
Y=750
H=700
CEP=900
R=.8

Equivalent for Notional Offensive:
SSPK=.19019 (this is eq. to the Groundburst Offensive output)
R=.8

Intermediate Variables
SSPK=.19019
TKP=.15215

DEFENSE 1 LAYER

Layer 1:
SSPK = .65
i = 2
Ptrack = .5

OUTPUTS
P(Defensive Layer)=.4388
TKP=.15215 (Repeated here for clarity)
PW=.0854

P(0 at W=1) = .9146
P(0 at W=2) =.8365
P(0 at W=3) =.7651
P(0 at W=4) =.6997

Circles are not totally persistent as camera crosses the dividing line in the Pacific

On a mouseover, compute probability at that position, given the layers that exist there.

This would help with issues around a layer being buried under another one. A long press could cause another layer to "pop" over the other and become active and movable. A visual cue on the layer border could indicate this happened.

I overlooked some minor math errors for P(0), I was focusing on intermediary variables, my mistake!
At line 154 in calc.js:

const PW = (tkp, defensivelayers) => {
return defensivelayers.reduce((p, c) => p * (1 - c), tkp);

Should be

const PW = (tkp, defensivelayers) => {
return defensivelayers.reduce((p, c) => p * c, (1-tkp));

This is my mistake, I told you the incorrect math for this I believe! Apologies

Defaults to a zoom that is very close in

We'll need to come up with a way to encode the current values in the URL.

Give a hue adjustment based on the probability of the layer.

This will ensure we don't have failed deploys anymore.

The DNS should simply act as an alias/CNAME, and not redirect. Investigate.

missile.exchange needs small title and link to the about and tutorial pages (http://blog.missile.exchange/about/ and http://blog.missile.exchange/missile-exchange-calculator-tutorial/ respectively)

For now, a small translucent white box (identical to the Layer management box's style) in the upper left above the gradient scale will be good. Gradient scale can be moved down, since we have more vertical real estate at the moment. Nothing too fancy necessary
------------------------
| Missile.Exchange |
| About -- Tutorial |
------------------------

Essentially we're defaulting to target when the layer doesn't specify, so that means it moves with the target, which is undesirable. I guess specifying at layer creation time is necessary.

Each Off/Def layers's P value title should be bolded to make it easier for the user to see. Section highlighted below

Once all of our UI elements are in place and working we'll want to spruce up how it looks. Add sufficient whitespace between elements, ensure things consistently sit on the same lines, ensure good behavior on screen resize, etc.

This should be static so as to be indexed properly in search engines.

Circles do not distort with latitude.
Low priority, not a big deal since it is just meant for basic simulation, but if easy to implement:
http://gis.stackexchange.com/questions/3264/using-geodesic-measurements-for-circle-radii

Thus far I've been relatively negligent of performance considerations, but as feature development decreases some attention is going to be needed in this area as the performance of map operations such as panning and zooming is not smooth.

The Victory people finally got back on this, and said you are on your own for ensuring there's no overlap, so I guess some sort of CSS fix will be necessary to ensure they don't overlap.

This seems to relate to the underlying Lethal Radius calculation. Scott passed along some sample data to work with:

Some sample data that should work:
Yield (kilotons)= 750
Hardness= 200 PSI
CEP=900m
Reliability = .75

Should have the output: .3815

If you want to test some other values: https://www.desmos.com/calculator/co1ximxx7t

Target should say in same position when zooming.

Whenever I load a save link (http://missile.exchange/?link=eyJtb2RlbEluZGV4IjoiMCIsInRhcmdldCI6eyJsYXRpdHVkZSI6MzcuNzczNDcwNTgwNDc3NDY1LCJsb25naXR1ZGUiOi0xMjIuMzU0NDY2MTg3OTk4MSwiaGFyZG5lc3MiOjEwMH0sImxheWVycyI6eyJvZmZlbnNpdmUiOlt7Im5hbWUiOiJOZXcgb2ZmZW5zaXZlIGxheWVyIiwidHlwZSI6Im5vdGlvbmFsIiwic3NwayI6IjAuOTEiLCJyZWxpYWJpbGl0eSI6IjAuOTkiLCJyYW5nZSI6IjAxMDAwMCJ9XSwiZGVmZW5zaXZlIjpbeyJuYW1lIjoiTmV3IGRlZmVuc2l2ZSBsYXllciIsInNzcGsiOiIwLjkiLCJpbnRlcmNlcHRvcnMiOiIyIiwidHJhY2tpbmciOiIwLjkiLCJyYW5nZSI6IjEwMDAwIn1dfX0= for example), the range circles have reset to the center instead of their previously saved positions

Provide an option to switch models, which is hidden when models == 1 (or just comment it out?)

I know we talked about this briefly, but would a save logging system be interesting/ethically acceptable?
Wellerstein's NUKEMAP has a logging function that reports the number of explosions and some basic metrics of it.
Due to the large number of variables here, that seems like a possibly overwhelming log report...
But if every time a layer is committed and generated, its Lat/Long and variables was logged, it'd be interesting to see what trends pop out.

This is low priority though, and doesn't need to be addressed at all if it is too much work.

It looks like the Hardness (PSI) value seems to reset to null sometimes when I click outside of the circle generated for a Ground Burst Offensive Layer. I cannot get it to consistently do this, it seems to reset 4 or 5 times in a row, then sticks.
It seems to be related to clicking and moving the GBOL circle, then clicking outside of the circle?

Setup included below

http://missile.exchange/?link=eyJtb2RlbEluZGV4IjoiMCIsInRhcmdldCI6eyJoYXJkbmVzcyI6IjUifSwibGF5ZXJzIjp7Im9mZmVuc2l2ZSI6W3sibmFtZSI6IkRGLTIxaXNoIiwidHlwZSI6Im5vdGlvbmFsIiwic3NwayI6Ii43NSIsInJhbmdlIjoiMTUwMDAwMCIsImxhdGl0dWRlIjo0MC4xOTg3Nzc4MzM3MzA0LCJsb25naXR1ZGUiOjExOS42Njc0NDYxOTM2NDk3NCwicmVsaWFiaWxpdHkiOiIuOTUiLCJudW1iZXIiOiIwIn0seyJuYW1lIjoiREYtMjFBIEdyb3VuZCBCdXJzdCAobWFkZSB1cCB3YXJoZWFkKSIsInR5cGUiOiJncm91bmQtYnVyc3QiLCJyYW5nZSI6IjE1MDAwMDAiLCJsYXRpdHVkZSI6MzIuMTM3NjAwODUwMjM3MDEsImxvbmdpdHVkZSI6MTIxLjIzODg1MDk1MTY3MzU0LCJ5aWVsZCI6IjEwMDAiLCJyZWxpYWJpbGl0eSI6IjAuOTUiLCJjZXAiOiIyMDAiLCJudW1iZXIiOiIwIn1dLCJkZWZlbnNpdmUiOlt7Im5hbWUiOiJOb3QgQWN0dWFsbHkgYSByZWFsIHN5c3RlbSIsInNzcGsiOiIuNzUiLCJpbnRlcmNlcHRvcnMiOiIxIiwicmFuZ2UiOiIxMDAwMDAwIiwibGF0aXR1ZGUiOjM3LjAzNTc3Mzg1ODIzNjUyLCJsb25naXR1ZGUiOjEzMC4yNDQyMDg5ODc4OTY4LCJ0cmFja2luZyI6Ii45In1dfSwiYWN0aXZlIjp7Im9mZmVuc2l2ZSI6WzFdLCJkZWZlbnNpdmUiOltdfX0=

Currently building on Windows fails.

I note in IE on Windows 8 there are compatibility issues, so I'm writing a note to remind myself to do testing. Scott my assumed targets here are going to be:

Latest Chrome
Latest Firefox
IE 11 and Above
Mobile Safari?
Mobile Chrome?

The mobile browsers will be tough because we'll have to think about how to translate the design without nearly as much screen real estate.

Input units should be in meters, map currently thinks they're kilometers.