LGdir: Orientation, Vectors, Moves
You are Mapmaker and you want to make games implementing a shooting mechanics? Here is a handy system that will allow you not only to shoot, but also to control the trajectory of a projectile!
Full projectile management
The LGdir, short for “LeiRoF – GamerGuppy direction,” in reference to the CPdirection (“Crushed Pixel direction”) is a system that allows players (or any entity!) throw projectiles like a snowball. The advantage is that you will be able to manage:
- The trajectory: this allows you to change the place to which the projectile is heading. You can then set a “straight” trajectory or create oblique trajectories. You will be able to simulate gravity, wind etc., the only limit is that of your imagination!
- Collisions: The projectile will be able to cross all surfaces or bounce/stick/slide on some of them!
- Speed: Increase, decrease or even stop the speed of a projectile while it is running! You can even make it go in the opposite direction at any time!
- Identities/properties: You will be easily able to distinguish all the projectiles as well as the people who launched them. So you can find out who scored the goal by throwing the ball or who shot who etc.
Flexible and adjustable
The LGdir will be able to adapt to each of your maps, due to its scoreboard objectives starting with “Dir”, avoiding any compatibility problems.
Moreover, it turns out to be extremely flexible due to its “open” and organized design. You will be able to create your custom projectiles (by putting a sheep as a projectile, the realization of a map like SheepWars will then be a breeze) and change the behavior of each independently of the others.
This system was originally designed for a most complex map and thus implemented the ability to handle 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 on him to which he was able to respond. As a result, 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 then light up only for 0.05 seconds at the time a player shoots!
Finally and to top it all 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 retro-engineering (start by seeing the result and gradually break down the system from the end to its foundation). For those who are brave enough, I have made available very detailed explanations in the spoilers. This system will no longer have any secrets for you ????
Ah! Now we’re getting into the heart of the matter! As a reminder, in order to make a projectile system, the CPdirection was based on the “Motion” tags defined according to the orientation of the player 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 loop (especially when you had to put several copies of the system to have several speeds)!
Here, there is no longer any question of motions because they were too problematic. This system uses teleportations as a means of travel.
But then, the projectiles do not move fluidly and linearly but are teleported in a jerky way?
In theory yes, in practice, it’s more complicated than that because it’s a combination of micro-teleportations, combined with the teleportation animation of Minecraft entities. In short, rest assured, the movements are perfectly fluid!
These teleportations are made from 3 vectors (in X, Y and Z), allowing 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 projectile’s movement is then optimized by a mathematical process so that its trajectory is as precise as possible without having as many control blocks as possibilities.
The 3 vectors are directly calculated thanks to the player’s orientation (they even deduced via a mathematical optimization process) thanks to trigonometric formulas reduced to simple operations (addition, subtraction, division and multiplication. Again and again math!)
Principe de la dichotomie
The projectile cannot exceed a speed of 4 blocks per tick on each of the axes (1 minecraft tick – 0.05 seconds, this corresponds to the interval between 2 game updates) for technical reasons (collisions, which we will discuss later, are one of the major reasons for this limitation). These 4 blocks are broken down into a dichotomous teleportation series.
To put it simply, let’s take the example of the game “Just Price” in which the objective is to find a values between 0 and 1000 and at each move, it is informed whether the value sought is higher or lower than the chosen value. Each will go with their strategy but only one appears to be the most effective: that of the dichotomy. This practice involves taking the “middle” element (called the median element) from the interval in which the number is being sought. For the Right Price, you will then choose 500. If the number is above, you will then take 750 (median value for the 500 to 1000 interval). Otherwise, you will choose 250 (median value for interval 0 to 500) and so on. So, at the first shot, your chance of falling on the right number is 1/1000. On 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 up to 10 strokes!
On this system, it is exactly the same. The speed is broken down on 3 scores representing the intensity of the 3 primary vectors (X, Y and Z). These scores vary 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 connection with the Right Price.
First, we look at whether the projectile “advances” or “recoils” (I put these two terms in quotation marks because they depend on a marker in this case, that of the axes given by Minecraft. Without a marker, it is impossible to tell the projectile moves forward or backwards). To do this, we look at whether his score on the axis we are studying is higher or less than 0 (if it is equal to 0, then the projectile has no movement on that axis, there is no need to do anything). Consider that the score is positive, then you have to look for a value between 1 and 1000 (1000 represents the maximum speed or 4 blocks per tick) and then teleport the projectile. We will then test whether it is above or less than 500. If it is higher, the projectile must be teleported by 2 blocks (half the maximum speed). If it is inferior, nothing is done. We then remove 500 to his score (since we change the score, so we must have made a copy of this score beforehand in order 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 us really knowing that speed.
Approximation de Bhaskara
To obtain the intensity of the 3 vectors, we have trigonometric formulas to calculate them from 3 values: r, phi and theta. These three values correspond respectively to the final speed of the projectile and the direction of the player’s horizontal and vertical gaze (more details in the spoiler “Orientation”). These formulas are:
x – r – sin (theta) – cos (phi)
y-r-cos (theta)
z – r – sin (theta) – sin (phi)
x, y and z represent the speed of the projectile on each axis. Here, we do not use the value r (which is to leave it at 1). The final velocity will be modified later by multiplying or dividing the 3 vectors by the same coefficient (dividing all vectors by 2 is like dividing the total speed of the projectile by 2 without changing its trajectory).
But, it requires the use of sinuses and cosinus, things we can’t do in Minecraft !!!
These formulas use sinuses and cosinus, and it is indeed impossible for us to use these functions in Minecraft. However, there is a subtlety: the sinus and cosinus 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 sound called the Bhaskara Approximations that are:
sin (p) – (4 p – (180 p)) / (40500 – p – (180 – p))
cos (p) – (32400 – 4 – p-2) / (32400 – p-2)
It all sounds complicated, I don’t see how to integrate such functions into a Minecraft system. Especially since the p2 it’s still not possible to do
A simple solution: respect the rules of calculation priority! You can store simple transaction results in scores, all you have to do is do some good calculations in the right direction to do these kinds of operations. It’s going to take as many block orders as there are operators, but you’ll get there. As for the p2, it is like doing p-p ????I
Orientation du joueur
n the previous spoiler saw that to calculate the intensity of the 3 primary vectors, we needed the values r, phi and theta. The r value represents the “module.” This corresponds to the final speed of the projectile. The Phi value represents the value (in degrees) of the angle of the player’s view horizontally (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 earth). These last two values are given by the game in the f3 menu.
All you have to do is retrieve 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 move of the entity, we had a score that was transformed into a position (the new position of the entity after it moved). Now it’s the other way around, we have a position (or rather, an orientation) and we’re looking to record it on a score.
So take the previous dichotomy method and replace the TPs with score additions (instead of teleporting the 2-block feature, you add 500 to its score) and replace old score changes with relative tp that change the player’s orientation (by dividing it by 2 continuously). You will then have your orientation stored in 2 separate scores (I tell you no more on 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 shoots (otherwise, the shooter will see his orientation go peanut with each shot, not very pleasant thing …). These changes 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 direction of the shooter. At the end of the calculation, the projectile must then be re-teleported to the shooter so that he looks the right way (if the projectile is an arrow, his head should point where the arrow is heading)
How do I use it?
This system has been modified many times to make it as easy to use as possible. Here is a list of useful things to know in order to fully master the system!
- (tag) DirShoot: allows the entity with the tag to fire a projectile. This tag automatically removes as soon as the entity has been drawn
- (tag) DirHaveShoot: This tag lets you know when the entity has just fired (useful to modify the shot according to the shooter without changing the LGdir). This tag automatically places and removes
- (tag) DirMoving: lets you know when a projectile is in motion. Removing this tag will have the effect of stopping the projectile net. To get him back on track, just give him this tag.
- (score) DirCollision: helps manage projectile collisions. Each score corresponds to a behavior (the projectile will bounce everywhere when it has the score 1 for example). It is possible to create one’s own behaviour.
- (scores) DirX, Dir Y and DirZ: allows you to manage speed on the X, Y and/or Z axis. Changing its value will change the trajectory of the projectile. Incremental this value in a loop will give an oblique trajectory to the projectile.
- (score) DirSpeed: helps 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 or above 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! Now you know everything you need to know about this system!
Credits
- LeiRoF: Concept – development
- GamerGuppy: Development Assistance
The creation of the LGdir was greatly facilitated by GamerGuppy, having created a system similar to the LGdir (which also served as a working base).
downloading
If you use this system in a public creation, please inform LeiRoF in the credits of the latter. This system is free, so it’s a small thank you ????
The LGdir is a block control system that gave birth to the Gunivers-Lib, offering more mapmaking tools. So there is no more recent version of this system as it has been incorporated into the Gunivers-Lib.
How do I install it?
To install this system, you can:
- Import the schematic via MCedit software
- Install World Edit (plugin under CraftBukkit or Spigot for servers, mod “SinglePlayerCommands” for customers) and access the “schematics” directory present in the mod/plugin folder. Slide the file into it and go to your Minecraft and enter the “/schem load LGdirByLeiRoF” commands and then “//paste” at the place where you want to install it.
Once installed, you’ll need to press the buttons at the bottom of the systems called “Constant” and “Objective.” As a precaution, break and rest the redstone blocks to refresh adjacent blocks.
