Recently cannon weapons and I missile weapons can determine if their Line of Fire is blocked by features.

Great! Another great feature to include in games.

But why does it default to true?
It changes gameplay.

There are also somebugs concerned with cannon balls and propaby missiles aswell. Even if the feature is nonblocking, so that projectiles and lasers can pass through, the cannon weapon will not fire through it and reject to fire.
Laserweapons will fire through thoose features without hesitation.

Innaccurate weapons, like on the Vulcan in NOTA, might be unable to force fire into the ground just because there is a little debris near the target location.

The custom hitspheres is different from the ones that Line of Fire calculation use. This can cause huge problems for cannons to fire through forests even if the features are nonblocking features that have really tall but very thin custom cylinders for example

WHAT?!?! IT IS FIXED FUCK YES!

for the better, if the mod wants the old behavior they can set it up in weapon defs post.

I don't follow this part.

this causes all kinds of annoying problems.. like units not being able to shoot over large flat buildings. Something that makes me rage in grts.

Wait, does this mean that Kodachi's won't point-blank their shots into an occluding wreck and self-pwn while trying to hit a target on the far side? That Samsons won't shoot missile after missile into one goddamned wreck? Epic.

yes, I believe that is what he is indicating, but there is an issue.

Ok I talked to godde:

Here is the problem, we have some features set to be non-blocking. Non-blocking features are STILL AVOIDED.. meaning a nonblocking set wreckage still obeys avoid feature. This is undesired. if a feature is nonblocking, it should be ignored for all targeting. Clearer?

Yeah! That's right.

As Smoth said, long term desired fix.



Agree with Smoth here actually. It was always intended to be true for S44, btw.




I reported this issue to jk the other day who had been unaware of it, no doubt it's on his todo list (seems 1 out of 5 checks is wrong)



Not sure on this one.

I would agree with you but now it avoids non-blocking features, which we both agree is undesirable.

Custom collision volumes is abit buggy as I have seen in my testing.
I were writing a mantis ticket but then I took an arrow to the knee.

so first they go looking for indians in america, and now you sain they in sweden?!?
what smoking?
who shoots at a guy while he is writing a mantis ticket? thats like shooting in the back squared.

there is this archer, I don't know who he is, bastard has impeccable timing I was going to stop him...

https://github.com/spring/spring/commit ... 910d0499c5

https://github.com/spring/spring/commit ... 756571bc82

The system works!

Jk has great knee armor.

Whether it has bugs or not, wouldn't the old behavior be a better default? I and I think most other players too would rather read about major changes to gameplay from a games changelog than from the engineversions log.

Nope it isn't better, it is a flawed behavior. The old behavior can be setup in weapondefs_post if they want such flaws in their project.

I was not joking when I already said the old behavior can be replicated with a VERY small lua change.

you know, like I said here:

I don't care if anyone considers which behavior to be better or worse, or however flawed either mode can be considered, the main thing is that the old behavior should remain the default just for the sake of it being the behaviour people are used to, both devs and players.

If you retain the old behaviour all current games have been designed around as the default, it's still a small change to switch to the new mode in that case too... And then it is a concious change by the game developer instead of something that just suddenly appeared from the engine devs to mingle the game up. It is a signal to the players too that this or that has changed, and it's indeed intended to be in the game I play by the people who develop that game.


And the new behaviour does have its primal flaws, it's not just about making the units smarter (which ofc isn't always desirable either).
For example, units fighting in an area with trees - trees which go down in 1 hit, but will absorb that 1 hit before going down. If 2 opposing units, both on hold position, are facing each other within range of their guns, and there's a tree in between... They'll just stand idle and wait for the player to forcefire that tree down before they'll engage each other. Or if they are on maneuver, they'll walk forward until one knocks down that tree by walking over it, which can mean wandering into the range of enemies that you would've otherwise pounded from afar after shooting down that damn tree.
That's just 1 quickly thought up and tested scenario where the new behavior makes units behave dumber than before, surely it's not the only one.

No I am sorry but that logic is fundamentally flawed. If you want the old behavior as default. Pester the game devs of your favorite game.

talking with godde, ok, lets consider this:

Current games
- certain weapons avoid features others do not.

Engine fix
- All weapons avoid features.
- This resolves a consistency issue with the engine.

But I want my weapon to not avoid features! There is a tag for that. The default is TRUE.


this means all weapons should avoid features by default.

-----------------------------------------------------------------
set 1)
Argument: this will break gameplay.

Counterargument: not if the game dev doesn't want it to. The game dev can set the weapons to not avoid features for specific weapons or use weapondefs_post to counteract this..

Counter-Counterargument: well have the other games set the tag correctly...... oh wait it is already set to avoid friendly.
-----------------------------------------------------------------
set 2)
Argument: the games already took this into the equation.

CounterArgument: They can still have this functionality, if they edit weapondefs_post or the respective weapon files.
-----------------------------------------------------------------
set 3)
Argument: but it is the behavior assumed by the content devs.
CounterArguement: that's a nice assumption of your own, this isn't the case, it is something that we have been force to deal with.


It is important to understand that as things are now, weapons will avoid features based on their class. Without the ability to choose, weapons that do not avoid features cannot have this changed to avoid features. By setting a consistent for all weapons setting. you get the ability to turn it on or off.

You can argue that weapons should all not avoid features. Well that is nice but then that means the majority of weapons will now try and shoot through features they cannot shoot through...

I don't care what the default is as long as the ability to customise is there.

The main issue that godde was talking about was fixed by jk already.

Dude... there is a gadget in zk called "noselfpwn.lua" 3 guesses as to what it does.