You are a mapmaker and want to create a game implementing shooting mechanics? Here is a system that will not only enables you to shoot but also control the trajectory of the projectile.

Fully Handle Projectiles

“LeiRoF & GamerGuppy direction”, aka. LGdir – references to CPdirection (“Crushed Pixel direction”) – is a system allowing players or any entity to throw snowball-like projectiles. You can manage:

  • Trajectory: this one allows you to modify the place where the projectile is heading. You can then define a trajectory “right” or create oblique trajectories. You will be able to simulate the gravity, the wind etc., the only limit is that of your imagination!
  • Collisions: the projectile will be able to cross all surfaces or to bounce / stick / slide on some of them!
  • Velocity: Increase, decrease or even stop the speed of a projectile during its race! You can even start it in the opposite direction at any time!
  • IDs/Properties: it will be easy for you to distinguish all the projectiles as well as the person who launched them. Thus, you will know who scored the goal by throwing the ball or who to shoot who etc…

Modular

LGdir will adapt to any map as scoreboard objectives all starts with “Dir” avoid compatibility issues.

In addition, it turns out to be extremely flexible due to its “open” and organized design. You can create your custom projectiles (by putting a sheep as a projectile, making a map like SheepWars will be a breeze) and change the behavior of each independently of the others.

This system was originally designed for a more complex map and therefore implemented the ability to manage an unlimited number of projectiles at the same time and by as many players as desired!

The initial map (known as Hierarchy) also imposed an optimization constraint to which he was able to respond. Thus, the parts of the system are independent and will only activate if necessary through the implementation of an intelligent activation system. The trajectory calculation part will only light for 0.05 seconds when a player fires!

Finally and to top it off, the LGdir has received improvements making it ultra responsive. The shots will then be almost instantaneous as well as the changes of directions!

How does it work?

To understand this system, we will do reverse engineering (start by seeing the result and gradually decompose the system from the end to arrive at its foundation). For those who are brave enough, I made available very detailed explanations in the spoilers. This system will then have no secrets for you;)

Ah! There, we return to the heart of the subject! As a reminder, in order to make a projectile system, the CPdirection was based on the “Motion” tags defined according to the player’s orientation by testing each possibility. 360 degrees horizontal multiplied by 180 degrees vertical, that’s a lot of possibility (64,800 to be exact) and as many control blocks activated in a loop (especially when we had to put multiple copies of the system to have multiple speeds)!

Here, there is no question of motions because they posed too many problems. This system uses teleportation as a means of transportation.

But then the projectiles do not move smoothly and linearly but are teleported so jerky?

In theory, in practice, it is more complicated than that because it is a combination of micro-teleportations, cumulated with the animation of teleportation of the entities of Minecraft. In short, rest assured, the movements are perfectly fluid!

Spoiler title

The projectile can not exceed a speed of 4 blocks per tick on each axis (1 tick Minecraft = 0.05 seconds, this corresponds to the interval between 2 updates of the game) for technical reasons (the collisions, which we will talk about later, are one of the major reasons for this limitation). These 4 blocks are broken down into a dichotomous series of teleportation.

To explain simply, take the example of the game “Fair Price” in which the objective is to find a value between 0 and 1000 and each shot, it is indicated if the value sought is higher or lower than the chosen value. Everyone will go for his strategy but only one seems to be the most effective: that of the dichotomy. This practice consists in taking the element “middle” (called median element) of the interval in which is the number that one seeks. For the Fair Price, you will then choose 500. If the number is above, you will then take 750 (median value for the range 500 to 1000). Otherwise, you will choose 250 (median value for the range 0 to 500) and so on. So, on the first try, your chance to hit the right number is 1/1000. The second shot, it drops to 1/500, then 1/250, then 1/125 etc … You then found a secret value between 0 and 1000 in a maximum of 10 shots!

On this system, it’s exactly the same thing. The speed is decomposed on 3 scores representing the intensity of the 3 primordial vectors (X, Y and Z). These scores are variable between -1000 and 1000 (the negative part means that the projectile will go in the opposite direction to that of the axis). So you start to see the relationship with the Fair Price.

First, we look at whether the projectile is “advancing” or “retreating” (I put these two terms in quotation marks because they depend on a reference in this case, that of the axes given by Minecraft Without reference, it is impossible to say where the projectile moves forward or backwards). For this, we look at whether his score on the axis we are studying is greater or less than 0 (if it is 0, the projectile then has no displacement on this axis, it is not necessary to do anything). Consider that the score is positive, it is necessary to look for a value between 1 and 1000 (1000 represents the maximum speed is 4 blocks per tick) then teleport the projectile. We will then test if it is higher or lower than 500. If it is higher, it is necessary to teleport the projectile of 2 blocks (half of the maximum speed). If it is inferior, we do nothing. We then withdraw 500 from his score (since we modify the score, we must have done beforehand a copy of this score to restore it before the next tick so that the projectile continues to move) Then we do the same with 250 (this time, the / tp will be 1 block), then with 125 (with a tp of 0.5 block) and so on. In the end, the projectile will then be moved exactly at the desired speed, without we really having knowledge of this speed.

These teleports are made from 3 vectors (in X, Y and Z), to know how fast the projectile moves on each axis. Thus, the sum of the 3 vectors will form the vector (direction, direction and intensity) of the projectile. The motion of the projectile is then optimized by a mathematical process so that its trajectory is as accurate as possible without having as many command blocks as possibilities.

Spoiler title

To obtain the intensity of the 3 vectors, trigonometric formulas are available which make it possible to calculate them from 3 values: r, phi and theta. These three values correspond respectively to the final velocity of the projectile and the direction of the gaze of the player on the horizontal and vertical plane (more details in the spoiler “Orientation”). These formulas are as follows:

x = r * sin(theta) * cos(phi)
y = r * cos(theta)
z = r * sin(theta) * sin(phi)

x, y and z represent the velocity of the projectile on each of the axes. Here, we do not use the value r (which amounts to leaving it at 1). The final velocity will be modified later by multiplying or dividing the 3 vectors by the same coefficient (to divide all the vectors by 2 is to divide the total velocity of the projectile by 2 without modifying its trajectory).

But, it requires to use sinuses and cosines, things we can not do in Minecraft !!!

These formulas actually use sine and cosine, and we can not use these functions in Minecraft. However, there is a subtlety: the sine and cosine functions are known! And since the time we know them, we have been able to develop “simple” functions that give a similar result. These “simple” functions are called the Bhaskara Approximation:

sin(p) ~= (4 * p * (180 – p)) / (40500 – p * (180 – p))
cos(p) ~= (32400 – 4 * p^2) / (32400 + p^2)

It sounds complicated, I do not see how to integrate such functions into a Minecraft system. Especially that p ^ 2 it’s still not possible to do

A simple solution: respect the calculation priority rules! You can store results of simple operations in scores, you just have to make good calculations in the right direction to do this kind of operations. It will take as many block commands as there are operators (+, -, *, /, ^) but you will get there. As for p ^ 2, this amounts to doing p * p;)

The 3 vectors are directly calculated thanks to the orientation of the player (they even deduced via a mathematical process of optimization) thanks to trigonometric formulas brought back to simple operations (addition, subtraction, division and multiplication. maths!)

Spoiler title

We saw in the previous spoiler that to calculate the intensity of the 3 primordial vectors, we needed the values ​​r, phi and theta. The value r represents the “module”. This one corresponds to the final speed of the projectile. The value Phi represents the value (in degrees) of the angle of the gaze of the player on the horizontal plane (between 0 and 360). Theta corresponds to the value of the angle on the vertical plane (between 0 and 180 because it is not possible to raise or lower the player’s head higher than the sky or lower than the ground). These last two values ​​are given by the game in the f3 menu.

It is then enough to recover them and save them in scores. For this, no question of testing all possibilities, we will apply the same principle as for the displacement of the projectile namely: the dichotomy. For the displacement of the entity, we had a score that was transformed into position (the new position of the entity after its displacement). Now, it’s the opposite, we have a position (or rather, an orientation) and we want to record it on a score.

Repeat the previous dichotomy method and replace the TP by adding score (instead of teleporting the entity of 2 blocks, you add 500 to its score) and replace old changes in scores by relative tp modifying the orientation of the player (dividing it by 2 continuously). You will then have your orientation stored in 2 distinct scores (I tell you no more about it, it’s up to you to make your gray matter work: p)

You will understand that since we change the orientation of the entity, this entity can not be the one that fires (otherwise, the shooter will see its orientation go in peanut with each pull, not very nice thing …). These modifications will then have to be made on the projectile itself. It is therefore necessary before doing this, teleport the projectile on the shooter so that the projectile takes the orientation of the shooter. At the end of the calculation, it is then necessary to teleport again the projectile on the shooter so that it looks in the good sense (if the projectile is an arrow, it would be necessary that its head point where the arrow is directed)

How to use it?

This system has been modified many times in order to make it as simple as possible. Here is the list of useful elements to know in order to fully control the system!

  • (tag) DirShoot: allows a projectile to be fired at the entity with the tag. This tag is deleted automatically as soon as the entity fired
  • (tag) DirHaveShoot: this tag allows to know when the entity has just fired (useful to modify the projectile according to the shooter without modifying the LGdir). This tag is automatically placed and deleted
  • (tag) DirMoving: lets know when a projectile is moving. Removing this tag will effectively stop the projectile. To make him resume his race, just give him this tag.
  • (score) DirCollision: allows to manage the collisions of the projectile. Each score corresponds to a behavior (the projectile will bounce everywhere when it will have the score 1 for example). It is possible to create one’s own behavior.
  • (scores) DirX, Dir Y et DirZ: allows you to manage the speed on the X, Y and / or Z axis. Changing the value will change the trajectory of the projectile. Increasing this value in a loop will have the effect of giving an oblique trajectory to the projectile.
  • (score) DirSpeed: allows you to manage the overall speed of the projectile. Changing its value to 200 will multiply its speed by 2, 300 to multiply by 3, and so on. This value must not be less than 0 nor greater than 400 otherwise, the projectile will take an imprecise trajectory (by default the projectile will have a DirSpeed at 200 corresponding to a speed of 2 blocks per tick)

That’s all ! You now know all there is to know about this system!

Credits

  • LeiRoF: Concept & Developement
  • GamerGuppy: Developement

The creation of the LGdir has been greatly facilitated thanks to GamerGuppy, having realized a system approaching the LGdir (which has also served as a basis for work).

Téléchargement

If you use this system in a public creation, thank you to inform LeiRoF and GamerGuppy in credits of the latter. This system is free, it is a less than thank you 🙂

LGdir 1.12

How to install?

To install this system, you can:

  • Import schematic via MCedit software
  • Install World Edit (plugin under CraftBukkit or Spigot for servers, mod “SinglePlayerCommands” for clients) and access the directory “schematics” present in the mod / plugin folder. Drag the file and go to your Minecraft and enter the commands “// schem load LGdirByLeiRoF” then “// paste” where you want to install it.

Once installed, you will need to press the buttons at the bottom of the systems named “Constant” and “Objectives”. As a precaution, break and replace the redstone blocks to update the adjacent blocks.

Leave a Reply

Your e-mail address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.

Skip to toolbar