Malex21
commented
1 year ago Hey ! Sorry for the long wait, I've been very very busy (and still am !) I checked a little bit your commits and they seem good ! (And thank you for them)
Im just not too sure about the max_delta_t_error thing, I don't know how delta_t scales on long distances (this could require max_delta_t_error to scale too, making it complicated too ?) and I feel like boundary angles such as -29.5 to 60.5 degrees are "clearer" to see and understand, and do not need to scale.
The reason i didn't merge for so long is mostly because I didn't have the time to build the exe for your branch and test the program throughout on MC. It's also because the long error texts such as "exceeds max_delta_t_error" are too long to be displayed correctly, and I'm not too sure on how to modify the string before the merge.
I wanted to give you an update on that, as I've pretty much told you "I might take some time to check your commits" and I've gone silent for the past few months lol (i'm sorry!)
I will also take the opportunity to say this here, i would like to do next :
-
A precision input box (for the number of iterations which is IIRC 5 rn)
-
A button labeled "experimental" for a formula i posted on #showcase long ago where I mistakenly said it solved for the angle in O(1). I need to test this formula more.
-
Update credits (no longer a hashtag after names)
-
Update readme
-
Place the center boxes correctly (I tried to no avail)
-
Actually do a CD pipeline so I don't have to bother learning all over again how to build the program with a reasonable size and without an obscure bug from one of the libraries
-
Do something about yaw which is not useful right now because it is between 0;360 degrees instead of -180;180
-
Much later, calculate the angles to hit a moving target, but this is only useful in Lua and IIRC someone already did it
That's about it, this is probably gonna be what's next for this thing as of now, but that's only if I get some time where I want to work on this.
Again, thank you for the commits. I'm not sure when I'll merge them (except the one with max_delta_t for reasons said above), but I just wanted to let you know that I'm still alive and breathing and that you didn't make a PR for nothing.
SuperSpaceEye
These improvements are something that I've used in my version of ballistic calculator. 1st commit: When the target is above cannon and it doesn't have enough energy to go above target, it will simulate all the way to t_max, which can be easily prevented and causes significant slowdown. 2nd commit Some targets projectile will hit on ascension. As it is now, program will completely ignore it, causing delta_t to become falsely large in those cases. This commit fixes it 3rd and 4th commits While I did use the same logic at first, I found a "better" way to determine if it's possible to hit target. Instead of determining it pitch is bigger or smaller than boundary, delta_t will naturally show it, so instead just check if delta_t is bigger than max_delta_t_error. I'm also using a linspace with boundaries, to limit angles. Also, high and low shots can be the same values, or a high shot can be impossible while a low shot is, so I added some checks to prevent useless calculations.