I tried using both it and this mod, and when I used the sniper rifle, the ammo range seem to have overwritten the weapon range and forced the bullet to die long before it hits the target. This makes snipers pretty much unusable.

possible fix would be to add alternative sniper ammo, which has a longer range (potentially higher velocity too).

I'll look into some more things on my end when I have the time.

Thanks for the report.
Yes, seems a dedicated ammo will be more suitable and convenient,
But I am not sure if this is a good time to change the ammo type now, since both the sniper rifle and its corresponding sniper turret (in Schall Ammo Turrets) are both using the vanilla bullets. Such change will probably disable defenses of many players.
But I promise I will do that on 0.18. Players will (probably) have less hard feeling on rebuilding or restarting their bases for a major game version change, especially when the game and other mods also change at that time.

I may make a mod that automatically does it for all weapons and turrets that have 'sniper' in it's name, as well as automatically make sniper versions of all bullet ammo types in the meantime.

This is a good idea too.
If you finished it, please notice me so I can add a link to the mod compatibility section.

I'm about 90% finished. There are just a couple issues: I can't seem to look at what's the ammo category of ammo/weapons /turrets. Every time I try to do so, it fixes me the (a nil value) error. Is it because it doesn't properly read underscores when using the s:find function or something? Some technical help would be appropriated (since it also helps me not to overwrite your laser sniper rifle ammo type in your other mod)

I'm gonna try to dump the content of the definition into a temp variable and use that. If the issue was the conflict between the underscores and the s:find, this should fix it.

Ah, alright. As 0.18 is already out and I am updating for that, I am making a brief summary here about the sniper bullet thing.
I have made the dedicated for the sniper rifle. Have not finished everything for release. (I plan to release the last update for 0.17 and the first update for 0.18 at the same time.)
Tested that for 0.17, but KS Combat still set the range to 24 only. KS Combat 0.1.11 does not automatically give different ranges for new bullets.
For 0.18, KS Combat is not updated to 0.18 yet. So I cannot test that. Guess will need follow up update from KS Combat 0.18 (or your mod) to raise the range.
I have made the corresponding changes for Sniper turret (in Schall Ammo Turrets) and Sniper pods (in Schall Gun Pods) for the new sniper bullet magazines.

For s:find or string:match (I use the later) or whatever string operations, note that the Lua expression used in parameters contain special characters, where they will need "escaping" the characters it being considered as text. Search keyword "Lua regular expression" or "Lua pattern matching" to learn. It is too long to "guide" you here.

In overall, my forthcoming updates will give the new ammo category and ammo prototypes, so you do not need to make them in your code. But you DO need to apply the change of range in ammo prototype definitions.
Here are a few conventions I used, so you can already use in your code:
The three new magazines are all under ammo category of "Schall-sniper-bullet". (Vanilla three magazines use category "bullet".)
I am prefixing the three new magazines with "Schall-sniper-". For example, the yellow sniper magazine has internal name of "Schall-sniper-firearm-magazine". (Vanilla yellow magazine has name "firearm-magazine".)
With these specific names, maybe you can save yourself the problem of string name matching? Anyway, it is your choice.

The problem is finding all weapons\turrets that need to swap over. I can set my own internal names to match yours, so that my mod works with yours instead of against it.
Keep in mind, KS combat runs it's thing on any ammo that has 'magazine' in it's name. Which means it will overwrite your new ammo, if it exists during the data-updates phase. You'd want either to add it after that, or redefine it's max range if it was modified.

Also, the ammo prototype looks very weird after KS is done with it. It has two copies of the action_delivery line, one is the old one from the hitscan effect, the other is the new one added by KS. I'm really not sure how to make sure you can modify the range in the altered bullet, since you'll need to hit the correct action_delivery.
You could try to nullify it entierly and then rewrite it based on a template, the projectile it uses is the same name as the ammo.

personally, I also like to make them faster. KS combat uses speed 1, but I currently set sniper ammo to 4 (I may double the base ammo speed). Also, turrets need to have target leading enabled for them to be able to properly shoot at moving targets with projectiles. it's done with attack_parameters.lead_target_for_projectile_speed =(the speed you want).

here is a copy of the ammo prototype structure, extracted with data raw serpant.

{
ammo_type = {
action = {
{
action_delivery = {
{
source_effects = {
{
entity_name = "explosion-gunshot",
type = "create-explosion"
}
},
type = "instant"
}
},
type = "direct"
},
{
action_delivery = {
{
direction_deviation = 0.02,
max_range = sniper_range,
projectile = old_ammo_name,
range_deviation = 0.02,
starting_speed = sniper_speed,
type = "projectile"
}
},
type = "direct"
}
},
category = "bullet",
target_type = "direction"
},
icon = old_icon,
icon_size = old_icon_size,
magazine_size = 5,
name = old_ammo_name,
order = old_ammo_order,
stack_size = 100,
subgroup = "ammo",
type = "ammo"
}

OK. I finally managed to get things to work - turns out I was messing up the loop.
But ammo defintions really ARE weird.

Inside of the action subtable, there is an unnamed table (or in this case, more than one). Inside of that, you have the action delivery, and the type. Inside of that there is ANOTHER unnamed table (this time, only one), and INSIDE of that you can access the bullet speed\range.
If you want to fix your sniper ammo once KS is done with it, you'll need to use the following code:
for _, ammo in pairs(data.raw.ammo["firearm-magazine"].ammo_type.action) do
if ammo.action_delivery[1].(look for starting speed, range, or projectile name here, to make sure you find the right action delivery)
stuff

I uploaded the initial version of my mod. All of my changes are done during the data-final-fixes phase, and I made sure to check if I'm not redoing them to prevent conflicts. If you do your thing prior to that, my mod should be able to wear into your things instead of remaking them.

Tested with your mini mod, it works with my code for dedicated sniper ammo. The adjusted range and speed is applied correctly. So I just released that as Schall Tank Platoon 0.17.13.
There are minor things that can be improved though. Including (but not limited to) your fixes also overwrite my new icons (original icon + upper-right corner subicon), sniper ammo unlocked before sniper rifle is researched. You may look into my code to change (or not change) to make things look better.
And as your mod is quite specific with the type of bullet/magazine to change (name match with "Schall-sniper"), I guess you can state and add a dependency to Tank Platoon directly.
My prototypes are defined in data phase, so I think it is safe even if you move to data-updates phase. (KS Combat did that in data-updates phase, so with dependency on that promises your code is loaded after that.)

Your code already handles the ammo range, so I think I would not add the adjustment code to my mod then. (And if KS Combat made the ammo/projectile out of my prototype, and I modified the projectile range later, and your mod also changed that... That seems not nice. Like a messy loop that I better leave it to your mod and/or KS Combat to deal with.)

Made the according change to Schall Ammo Turrets 0.17.6 & Schall Gun Pod 0.17.5. Sniper turret should be fine now. But I guess the sniper pods (also gun pods, minigun pods) are not touched by KS Combat. Still like the insta-hit by vanilla bullets.

Fixed the icon and recipe issue. If your ammo is detected, I only overwrite the name.ammo_type.action table.
also prevented tech and recipe segments from adding extra things to techs.

I would appreciate some help with wrangling the projectile prototype though... Trying to make normal bullet range\speed\accuracy configurable, but it doesn't seem to work.

I can help, but probably after I made all the 0.18 updates on my mods.
Making updates in graphics on all my mods is so time-consuming that I have not expected...

After the intensive 0.18 update work, and a short break away from Factorio to restore my daily life,
I am finally back and ready for other modding work now.

I would appreciate some help with wrangling the projectile prototype though... Trying to make normal bullet range\speed\accuracy configurable, but it doesn't seem to work.

To set range\speed\accuracy, it has to be done on ammo prototype, not projectile prototype. (Like what you have done to sniper ammo.)
What is the problem you encountered in changing those properties of normal bullets?
I guess it is probably to look for the correct data.raw.ammo[ammoname].ammo_type.action to set the properties?

PS1: In your code, you have used both "diveation" (wrong) and "deviation" (correct spelling).
PS2: I guess no one (or few) can know what your mod is trying to modify in the mod description. I would suggest to specify which mods' sniper rifle/turret that your mod is designed for. Ehem, it sounds like asking an ad... But since your mod is designed that way, you better clearly state what your mod does. Most users will not crawl into your code to understand that.
(Just like I did an extension mod on Belt Configuration to support Krastorio, I do not need the users to guess which mod it is supporting.)

My mod is supposed to work for ALL sniper turrets, as long as they list 'sniper' in their name. The reason I matched my internal ammo name to you, is to make the transition seamless, if anyone wants to start\stop using it.
The problem with the ammo prototype, is that I don't think I can just do data.raw.ammo[ammoname].ammo_Type.action.
because, if you look at the example I provided to you, once you get into action, it's a double bracket situation, so I have no idea how can I make sure I'm accessing the correct sub table.

Alright, you are much more ambitious than what I thought.
I can already think of some troubles you may face, such as different sniper mods have different ranges... So good luck to be compatible with whatever mod you will encounter.

There are no good ways to make sure you are accessing the correct sub table, if you do not know which mods you are going to work with.
You may try the following code, to test whether 'action' is the table you are looking for, or contains sub tables.

if action.type then
(...)
else
for _, v in pairs(action) do
if v.type then
(...)
else
(Another loop ?...)
end
end
end

Adding to the complication, ammo_type can have action directly, or contains sub tables. (See vanilla flamethrower ammo for how it can look like.) Another set of conditions checking and loops are thus needed here, if the ammo_type are not made by you.
(This comes as an example in time, to show how easy it is to miss a case, preventing a mod to be genuinely universal compatible.)

I tried the if thing... It gave me some trouble.
Will try to do it again I guess.
As for being ambitions... Ks combat breaks ALL sniper weapons by default. Returning them into even a semi-functional state was my original goal, which was achieved. If anyone wants to use multiple tiers of sniper weapons... They can just extend the sniper range, which is configurable, to match the longest sniper turret range. After that, the turret's own max range should take care of things.