Correct, I don’t think it needs anything more complex. I can look into other methods but I doubt it’ll produce measurable difference.
That’s great. I was just checking that it wasn’t something like Euler’s method 
Will it have gravity and drag? My main reason for wanting an exernal ballistics asset is because I need somewhat realistic drag.
Gravity works like you’d expect, not much to invent there.
Drag takes into account diameter of the projectile, its mass, speed (with mach drag function - ie. you can use something like G1 or G7 drag model with speeds converted to mach), form factor, wind, and at the moment i’m working on air density varying with altitude (should work the same as in EasyFM).
It won’t however simulate some more “academic” things like cyclic yaw, magnus effect, coriolis effect etc. that wouldn’t be noticeable in a game anyway.
Have you considered selling this on Gumroad? I personally would like to get a dedicated solution for ballistics like that as soon as possible.
That’s the plan. Getting something on the marketplace isn’t a quick process, especially if it’s a plugin, so it’ll be probably Gumroad-only at first.
No idea when it’ll be done though. I’m still trying to sort out net replication. I mean, it works, but it chews through bandwidth at unacceptable rate, so i’m currently working on a system that will not replicate full movement, only launch and impacts, and the rest will be predicted locally.
Just to be clear, a plugin can be used with either blueprints or C++?
Yes. From users perspective objects and functions added via plugin are no different from Unreal’s internal stuff. As long as something’s marked as Blueprintable/BlueprintPure/BlueprintReadWrite etc. in code, it can be accessed via blueprint.
Would lowering the stepping on the ballistic path save bandwidth? In Arma3, there is a ballistics script that traces the bullet path. And it has an option to lower the rate, so the curve is not as smooth, but it still might work.
I don’t know how things work internally in ArmA, but for me that’s not practical because i’m not calculating the whole path, but only the portion that the projectile traveled each frame.
I could make it step only every xth frame (or x accumulated milliseconds), but If local prediction works like I expect it to work, it shouldn’t be necessary anyway.
EDIT: Added it anyway. It was easy and someone might find it useful.
OK, i’m still working on network stuff. It’s much more reliable and less bandwidth intensive (bullet in flight is not replicated at all, but each client runs local prediction, and they’re only synchronized on impact). Now i’m just trying to make the whole thing as intuitive as possible (it’s called EASYballistics afterall… ), and of course bug fixing.
Meanwhile, here you can try out the example project: https://drive.google.com/open?id=0B20tIRBAcOlsMVhQZEs1cUVQOHc
https://youtube.com/watch?v=slS3RpLk0YM
Controls:
movement - WASD or arrow keys
shoot - LMB
aim down sights - RMB
switch mode - MMB
zoom - scroll wheel
reload - R
(yes, I know that tracers and other effects are exaggerated, it’s to make it easy to see what’s going on. They’ll get toned down for release)
Everything’s almost ready. I have one more question:
Would you prefer if ammo could be set from the client or should I make it server-only?
-The former is simpler to set up but leaves room for cheaters to give themselves infinite ammo.
-The latter will require a couple of extra steps from the developer but server has control over what ammo each player has.
And it’s ready. At the moment it’s only on Gumroad, because i still haven’t even got my previous plugin on the marketplace…
And here’s first two parts of tutorial:
More on the way…
Here’s more tutorials as promised:
I think that covers most of the basic functionality covered, or at least as far as singleplayer goes.
1.1 released.
Since EasyBallistics atmosphere simulation works the same as in EasyFM, the improvements from one carry over to the other. So, in EB 1.1 you can now override world settings just like in EFM 1.6.
And while we’re adding function overrides, if you’re for whatever reason unhappy with the default trajectory calculation, you can now replace it with a custom one:
V 1.20 is released. I’m hoping this will be the version that will go to marketplace, but we’ll see. Either way, it’s up on Gumroad for those who want it now.
changes:
-improved wall penetration calculation. There are now 3 methods: solid (same as old model, works best w/ simplified collisions), back trace (works best with walls made of multiple smaller objects) and forward trace (most accurate, but needs double sided geometry, best for BSP). They can be selected per physical material.
-new “block shooting” parameter that can be used to, as the name suggests, prevent the weapon from shooting.
-client-side reloading in multiplayer removed (unnecessarily confusing for no real benefit)
-miscellanous bugfixes
-example project cleaned up and made less hideous
And for those still not decided if they want this, here’s a new playable demo: https://drive.google.com/open?id=0B20tIRBAcOlsMVhQZEs1cUVQOHc&pageId=108868528576869276469
Now released on the marketplace:
Alright, just so you know, i didn’t forget about this. Currently working on a workaround for common problem with this type of simulations, namely that fast moving targets can sometimes cross bullet’s path “between frames”, resulting in no hit where there should be one.
My solution:
Time traveling quantum bullets, of course 
(now seriously, it simply rewinds to where it was in the previous frame, and checks if something new didn’t appear in its path).
I already have it mostly working, now i just need to do some testing to make sure there are no bugs, and that it’s mostly transparent for the user of the plugin.
Does CCD not solve this?
In this case no, because this plugin doesn’t actually create any physics bodies, the whole thing is based on line traces.
When colliding two regular bodies, CCD of course works (the actual collision detection part anyway, physics response is rather unpredictable).