There has been quite a few questions asked over the years about shot trickery.
Generally most of the questions relate to "homing shots", besides GM or if shots can be made to go in curves.
The API does not support this, however it can be "simulated".
And since we can simulate it, it generally is good enough.
Below will be provided some examples of making shots go or appear to go in curves.
Implementation is up to the user and the flag example is a custom one.
Custom Flag: Catapult
Description: Shots head in arc pattern, useful for preventing players from jumping to escape shots.
To implement, we first use to get the player shot position.
(This may be found in the shotFiredEvent within the API.)
If we have the 'catapult' flag, we then proceed to acquire the rotation of the tank.
(The method of acquiring rotation is left to the user, update event or BasePlayerRecord should work fine.)
Since we now know the position and the rotation, we do not want to fire from exactly within the tank.
Rogues would instantly blow up and if -noTeamKills is not enabled, team players would explode as well.
(Rogues are not considered part of teams.)
We can either preset or simply grab the default tank size upon plug-in load.
We then set the shot to occur slightly above and beyond the point of where the tank were to explode, if it would hit it.
(You also may use a variable to increase distance, such as a "lag safety" custom BZDB variable.)
Since we are trying to make shots go in curves, we can't alter shot paths in flight, even with GM.
So our next best option, is to use a shot type independent of regular shots, such MG or F. (Machine Gun and Rapid Fire.)
This is set to a low variable, so they explode after a short while.
Our first shot goes in a slightly upward angle from tank.
Since we know of when it will end, we can also fire another shot when it ends.
To add a small footnote: When the shot is said to "expire", since we know where it was fired from, we know where it ends.
(Or should end in theory.)
This can go in a pattern of shotFire -> shotEnd -> shotFire, while we also calculate the shot path.
We later use maths to calculate where the next shot should start and adjust it, so we create an "arc" of shots.
Now the smaller the shot time and distance traveled, the more "arc-like" the "shot" will appear.
(Implementation up to user.)
We also know where it ends as well and use a simple calculation to know when and where our shots should end.
(Shots may end early or be ricocheted off of objects, which may pose some issues, but these are relatively minor.)
Shots may by accident *start* in world objects, but we can use custom zones to roughly approximate and be able to "see" our world from the plug-in and prevent it from generating shots within world objects.
The smaller aspect is to also prevent starting shots outside of the world.
(This should be obvious, but still should be noted.)
Still, there has been some notes of "I don't want to use existing shot types, since it will conflict with the flags on the map".
Yet there is a bit of a solution to this.
It hasn't been yet revealed, but it is one of the more *secret* shot manipulation techniques.
We don't end shots, we overwrite them.
The amount of server shots which can exist, are limited to the number specified in "WorldWeapons.h" header.
This may be found in the following segment of code:
Code: Select all
(Generally any version after the world weapons API overhaul will use "255".)
The main issue is that this technique can conflict with other plug-ins which use world weapons.
So, what can be done, is to fire shots before a shot expires. (Shots will be overwritten.)
If the shot limit is reached, the next shot will *end* the first one, without exploding.
This can be used to cause shots to *end* early.
In the *catapult* flag, we can fire multiple shots in a row and path and shots will remain until they are "overwritten".
Therefore, we fire shots and use them to overwrite the ones we already fired.
(This should result in a much quicker and smoother looking shot, which may provide satisfactory results.)
(This has been part of the publication of some of the plug-in notes.)