Players sheltered behind asteroids or other ships are protected from player fire and missiles, however NPCs and turrets can fire through other ships and objects. See: Levi and conq station turrets.

Turrets and NPCs (or players) should not be able to fire THROUGH asteroids or other ships. Also, friendly fire and collateral damage should exist. Friend or foe, if you're hit with weapons fire, it should hurt.

Adequately providing a means of blocking would open up new tactics for more strategic play.

If you're worried about making it too easy then increase the number of enemies and provide overlapping fields of fire.

This isn't some random gameplay choice.

It is more accurate to say that one specific weapon can fire through objects, and that specific weapon happens to be equipped to Leviathans and Station turrets.

It isn't an intentional "feature" of the weapon, it's because of how collision detection works. Those particular shots move at very high speed, so fast that they are sometimes (not always) able to penetrate thinner objects because their velocity and collision hull movement exceeds the precision of the physics timestep framerate on the server.

This isn't the most trivial thing to solve. Increasing the physics framerate doesn't just increase server CPU (all the time), it also has ramifications in other areas that are based around certain assumptions of that timestep frequency.

It's possible to change the collision detection to do a more intensive "look backwards in time" to make the precision less of an issue, but this is also computationally intensive; or (as a tradeoff) there could be a complex specialty heuristic, specific to this situation, to try and adjust in a very "fundamental" system.

Of course, we could just slow down the shots, but that would make them far less effective against players, which is why they were "sped up" in the first place.

This is an issue we're aware of, and eventually I'll probably try putting thicker asteroids around the Leviathan, to create more effective barriers people can hide behind, etc. But, that won't necessarily help for Station turrets, or like conquerable station situations, etc.

I could probably try and come up with some other type of weapon entirely, but that's also.. time, that I just haven't had a lot of, obviously.

So, while I obviously don't like this long-standing problem, it's lower on my priority list than a lot of other problems.

This makes sense. Although could you clarify one part just in the interest of my curiosity.

You mentioned looking backward... but if those shots are linear and directed, and asteroids are static, why is it not possible to look forward, and predict the impact?

Obviously this doesn't address turrets and collision hull movement issues...

If you let them see into the future, they may become self aware and plot an uprising. The last thing we need are sentient asteroids ;)

/me pews Nick_9137 with the new Silly String turret.

You mentioned looking backward... but if those shots are linear and directed, and asteroids are static, why is it not possible to look forward, and predict the impact?

It is possible, of course. I mean, anything is possible, because it's all software. But someone has to spend the time to write the software.

Yes, we could implement some system that (off the top of my head) does a ray-cast collision check for the trajectory of any shot, as it made it, to see if there might be an intersecting collidable object of an unmovable type, blah blah. I mean, you'd still have problems with capital ships and movable objects, because you wouldn't be able to guarantee they would still be there, etc.

Then there's also the fact that I'm trying to make asteroids dynamic and physically interactive, as they are in some Latos test sectors.

But, even without all that, it's not any better than the solutions I mentioned, and it's now a bunch of code that's completely specific to this one weapon in this one case.

So, no, we aren't going to do that either.

We'll look into the general issue, in due course, but this just isn't nearly as important as fixing more wide-spread game problems, or doing universe-redux or economy-expansion development.

Does the current system require all projectiles to be spheres? Stretching high-speed projectiles out to be a few times longer than they are wide might help, if you aren't already doing that.

We've always done that for a lot of projectiles; I'd have to check that one specifically, as it's larger than most. But, I think we also do this dynamically.

Maybe this has been suggested before as a partial fix, and incarnate has most probably already thought of it but here goes.

Why not make the turrets ability to target player subject to the same occulsion effect as my ability to target remen if he were behind a roid. That would probably make them MORE effective as hiding behind a big rock may cause some of them to waste their shots pounding away at an un-hitable target. I know it's not a panacea, but it would be an improvement.

Would that be hard to implement?

Also as a side question, Advanced Rails appear to move faster then the levi gauss, why don't those shots suffer the same problem? I may have never noticed if they do, or they may in fact not go as fast.

Firstly, the cpu burden incurred by doing a visibility check, while small, becomes much more significant at scale. So, one turret, checking against one ship, is pretty minor. 50 turrets, checking against 10 players and say 50 NPCs, that's suddenly a more significant load on the sector. Plus there are issues like, how often you "check" for visibility, etc.

Where a collision is just a one shot impact on cpu, at a moment in time, vis-checks on targets can escalate quickly. There are techniques to reduce it (limit checks to enemies within X distance, once per second, etc), but it does create other issues.

We have thought about it, and I'm not ruling it out, but it isn't my first choice. It also doesn't really "solve" the fundamental problem, it just makes it less apparent. I'd rather improve the underlying collision system.

Secondly, it doesn't happen with Rails, because that uses a different type of collision primitive, which is "stretched" by velocity, and avoids these issues. Yes, we may be able to do something like this for these Levi shots too (which I mentioned in my previous post), but it requires time to investigate.

FYI that we rolled out changes last night, which should have fixed this issue. At least for the Leviathan, and probably all related issues with similar types of weapons.

Let us know how it works?