Jump to content

Search the Community

Showing results for tags 'setVectorDirAndUp'.



More search options

  • Search By Tags

    Type tags separated by commas.
  • Search By Author

Content Type


Forums

  • BOHEMIA INTERACTIVE
    • BOHEMIA INTERACTIVE - NEWS
    • BOHEMIA INTERACTIVE - JOBS
    • BOHEMIA INTERACTIVE - GENERAL
  • FEATURED GAMES
    • Vigor
    • DAYZ
    • ARMA 3
    • ARMA 2
    • YLANDS
  • MOBILE GAMES
    • ARMA MOBILE OPS
    • MINIDAYZ
    • ARMA TACTICS
    • ARMA 2 FIRING RANGE
  • BI MILITARY GAMES FORUMS
  • BOHEMIA INCUBATOR
    • PROJECT LUCIE
  • OTHER BOHEMIA GAMES
    • ARGO
    • TAKE ON MARS
    • TAKE ON HELICOPTERS
    • CARRIER COMMAND: GAEA MISSION
    • ARMA: ARMED ASSAULT / COMBAT OPERATIONS
    • ARMA: COLD WAR ASSAULT / OPERATION FLASHPOINT
    • IRON FRONT: LIBERATION 1944
    • BACK CATALOGUE
  • OFFTOPIC
    • OFFTOPIC
  • Die Hard OFP Lovers' Club's Topics
  • ArmA Toolmakers's Releases
  • ArmA Toolmakers's General
  • Japan in Arma's Topics
  • Arma 3 Photography Club's Discussions
  • The Order Of the Wolfs- Unit's Topics
  • 4th Infantry Brigade's Recruitment
  • 11th Marine Expeditionary Unit OFFICIAL | 11th MEU(SOC)'s 11th MEU(SOC) Recruitment Status - OPEN
  • Legion latina semper fi's New Server Legion latina next wick
  • Legion latina semper fi's https://www.facebook.com/groups/legionlatinasemperfidelis/
  • Legion latina semper fi's Server VPN LEGION LATINA SEMPER FI
  • Team Nederland's Welkom bij ons club
  • Team Nederland's Facebook
  • [H.S.O.] Hellenic Special Operations's Infos
  • BI Forum Ravage Club's Forum Topics
  • Exilemod (Unofficial)'s General Discussion
  • Exilemod (Unofficial)'s Scripts
  • Exilemod (Unofficial)'s Addons
  • Exilemod (Unofficial)'s Problems & Bugs
  • Exilemod (Unofficial)'s Exilemod Server tweaks
  • Exilemod (Unofficial)'s Promotion
  • Exilemod (Unofficial)'s Maps - Mission Files
  • TKO's Weferlingen
  • TKO's Chernarus
  • TKO's Livonia
  • TKO's Rules
  • TKO's Changelog
  • TKO's Help
  • TKO's What we Need
  • MSOF A3 Wasteland's Server Game Play Features
  • MSOF A3 Wasteland's Problems & Bugs
  • MSOF A3 Wasteland's Maps in Rotation
  • SOS GAMING's Server
  • SOS GAMING's News on Server
  • SOS GAMING's Regeln / Rules
  • SOS GAMING's Ghost-Town-Team
  • SOS GAMING's Steuerung / Keys
  • SOS GAMING's Div. Infos
  • SOS GAMING's Small Talk
  • NAMC's Topics

Find results in...

Find results that contain...


Date Created

  • Start

    End


Last Updated

  • Start

    End


Filter by number of...

Joined

  • Start

    End


Group


Website URL


Yahoo


Jabber (xmpp)


Skype


Biography


Twitter


Google+


Youtube


Vimeo


Xfire


Steam url id


Raptr


MySpace


Linkedin


Tumblr


Flickr


XBOX Live


PlayStation PSN


Origin


PlayFire


SoundCloud


Pinterest


Reddit


Twitch.Tv


Ustream.Tv


Duxter


Instagram


Location


Interests


Interests


Occupation

Found 4 results

  1. So I've been experimenting in the editor, trying to make "standoff" armor for APCs, make big ridiculous armored gun trucks, things like that. Basically the kind of makeshift DIY stuff we see in Iraq and Syria. Naturally, I'm using the attachTo and setVectorDirAndUp commands in each objects init field for this. This is an EXTREMELY time consuming and tedious process, as I have to fiddle around with the X,Y,Z coordinates of every piece and then hit "play scenario" just to test the placement of each piece and then end it, make guestimates, rinse, wash, repeat. Is there an easier way to do this? Like maybe some mod or addon or something that lets me just sync the object to the vehicle and then move it around with the mouse? Or maybe see my X/Y/Z coordinate adjustments in real-time in the editor, as opposed to having to start the scenario each time to see the placement? I've got some really cool ideas, but my god is this a pain in the ass lol. Here's some stuff I'm messing around with/WIP:
  2. Over the course of the last few hours I've familiarized myself with, experimented on, taken apart, and learned the nature of Bohemia's 'vector' object orientation system and how to manipulate it to do exactly what you want it to do. I had searched around before for this information but had found only speculation or rough guesses and no concrete inner workings, and so after discovering them I wish to share them with the internet so nobody has to go through what I did to figure this stuff out. setVectorDir and setVectorUp are script commands you can use to set an object's orientation, particularly useful because they don't overwrite each other. Using setDir resets an object's pitch to 0, so if you want to keep an object's pitch while changing its heading, setVectorDir is your only option. setVectorUp is essentially setVectorDir, but for roll and pitch. You can use BIS_fnc_setPitchBank to set roll and pitch, but I'd wager that setVectorUp is more efficient. This post is about how the arguments to those commands work, exactly what the commands do, and how to manipulate them to do what you want them to do. Go back to high school trigonometry for a moment. Remember right triangles and vectors? Well, those are at the core of the vector system. I suspected after a while and some fruitless experiments that the name may have literally meant that the system uses vectors, and that turned out to be the case. For those that don't know, a vector is a distance and a direction. Take a line segment, put an arrow on one end, and you (basically) have a vector. Vectors consist of only two numbers: an angle, which defines their direction, and a magnitude, which defines their distance. They do not have a fixed start or end point, they are just an angle and distance. You can put a vector wherever you like and however you like. Vectors can be the hypotenuse of a right triangle: at any rate, onward to the explanations. VectorDir VectorDir is the azimuth direction of an object, although it's represented much differently in the game's logic. VectorDir is an array of three values, [x, y, z]. x is the length of the x leg of that triangle, on the east/west axis. Positive x denotes east, negative x denotes west. y is the length of the y leg, on the north/south axis. Positive y denotes north, negative south. z I'm not sure about. It hasn't been necessary in any of my testing, and doesn't seem to do anything when I try to use it. When you setVectorDir [x, y, z], you create a vector that is the hypotenuse of a triangle with legs of length x and y. The vehicle orients along that vector, using its direction angle: I've changed the triangle and the references in this picture to reflect how the angle is actually measured. Technically, you can use either triangle in your calculations because angle X on the green triangle is equal to angle Y on the gold one, but the algebra is easier with the gold one. Speaking of algebra, let's start applying these principles. Because that's a right triangle, trig ratios say that tan Y = x/y. In order to change the vehicle's direction, we have to create a vector. Let's say we want to put the vehicle at 35 degrees azimuth--we can do that by defining the direction angle, Y. In the equation, that looks like: tan 35 = x/y. The next step would be to define y and x, but how do we know what to set them as? Well, there are an infinite number of triangles we could make that have Y as 35 degrees; the only thing that's constant through them all is the ratio between y and x. So if we make one of the legs (y because it's easy) a constant (1 because it's easy), our equation looks like this: tan 35 = x/1. Simplified: tan 35 = x. So now we get our y-value. So, to recap, y=1, and x=tan 35. Let's put that back into the command: object setVectorDir [tan 35, 1, 0]; This will set our vehicle's direction to 35 degrees azimuth. But that's not all there is to it. Recall the quadrants of a graph: 1st quadrant, both x and y are positive. 2nd quadrant, y is negative. 3rd, x and y are negative. 4th, x is negative. Using that formula above, we'll be okay for the first quadrant, but after that things start getting wonky. That's because tangent returns the slope of the vector; tan 35 is the slope of the vector we created that had direction angle 35. With direction angles between 90 and 180, the slope becomes negative. So tan 89 =~ 57, but tan 91 =~ -57. If we put tan 91 into the command, we end up with: object setVectorDir [tan 91, 1, 0]; (approximately object setVectorDir [-57, 1, 0]) which puts us in the fourth quadrant. 91 goes out toward the second quadrant, which is positive x, negative y. So we have to modify our statement a little by multiplying both numbers by -1, or simply making them opposites. So, to get to the second quadrant correctly, the command should look like: object setVectorDir [-tan 91, -1, 0]; which will set the vehicle to a direction of 91 degrees. The third quadrant will use angles between 180 and 270, but we don't have to change anything here. Third quadrant is negative-negative, and tangent goes back to positive, so object setVectorDir [-tan 181, -1, 0]; will work just fine. The fourth quadrant uses angles between 270 and 360, and for this we have to go back to our first setup because tangent goes back to negative, so object setVectorDir [tan 271, 1, 0]; will work. We're not done yet. There are special cases, too. At 90 and 270, tangent is undefined, and if we try to pass something that's undefined we'll probably get an error (haven't actually tried). So we have to handle 90 and 270 separately, by just setting the vehicle to those directions. object setVectorDir [1, 0, 0]; object setVectorDir [-1, 0, 0]; for 90 and 270, respectively. I've written some code to convert an angle from traditional azimuth degrees to a vectorDir. Here it is: // Converts azimuth angle to BIS vectorDir array // Author: Ruger392, a.k.a. Lt. Col. Ruger of Air Combat Command _return = [0, 1, 0]; // North _angle = _this select 0; _xlen = tan _angle; // Determine quadrant and special cases and return if ((_angle > 0) && (_angle < 90)) then {_return = [_xlen, 1, 0]}; if ((_angle > 90) && (_angle < 180)) then {_return = [-_xlen, -1, 0]}; if ((_angle > 180) && (_angle < 270)) then {_return = [-_xlen, -1, 0]}; if ((_angle > 270) && (_angle < 360)) then {_return = [_xlen, 1, 0]}; if (_angle == 90) then {_return = [1, 0, 0]}; if (_angle == 180) then {_return = [0, -1, 0]}; if (_angle == 270) then {_return = [-1, 0, 0]}; _return Onward! VectorUp VectorDir was easy. VectorUp is where things get complicated. With VectorUp, you have essentially the same thing as VectorDir, except the vehicle's top side is oriented along the vector instead of its front and z does stuff. Let me elaborate: setVectorUp's axes are the same as those for setVectorDir, with one exception. The z axis is functional and represents up/down, positive = up and negative = down. Doesn't seem so difficult, until you realize that setVectorDir and setVectorUp use absolute axes instead of object-relative ones. Which makes sense, it just makes setVectorUp a lot harder to use, because if we define x and z to pitch up at 45 degrees like so: object setVectorUp [1, 0, 1]; it will only work when we're facing directly east. Any deviation from east and we get roll as well, because the top of the plane wants to point along a vector that is facing east when the plane itself is not. So how do we solve this? Well, recall the vector and the triangle. The two legs of the triangle defined where the vector pointed. Using some trigonometric magic, we can make the vector point along the axis of our plane by changing the lengths of x and y. Recall the functions sine and cosine; sine takes an angle and returns how far up it goes on the y-axis. Cosine does the same, but for the x-axis. So if we change angle A to the azimuth of our object, we can take the sine and cosine of it (for north/south and east/west, respectively) and have the vector pointing in the same direction. But what about controlling the pitch? We can do that the same way we controlled azimuth with setVectorDir. If we consider just pitch and the vector's overall magnitude, we can think of it in two dimensions. There is one slight problem, though: setVectorUp orients the object's top, not its nose. This will invert our desired pitch, but we can correct for that by inverting our formula. Previously, we had: tan Y = x/y. Instead of using Y, we can use X, so we instead have: tan X = y/x. Thanks to the golden rule of trig ((sin x)^2 + (cos x)^2 = 1), we don't have to set a constant because the vector's magnitude (x) will always be 1. So we have: tan X = 1/y. Solve for y: y tan X = 1 ... y = 1 / (tan X). Now remember that y in this case is actually our z axis, our height. So, to recap, we find x with cosine of the object's direction and y with sine of the object's direction, then z with our formula there. We input our desired pitch as X, so the (almost!) final command looks like: object setVectorUp [cos (getDir object), sin (getDir object), 1 / (tan X)]; There's one last little thing we haven't accounted for. Sine, cosine, and tangent were all created for use in the math world, where angles start at what would be direct east in ArmA, and go counter-clockwise. So when you take sin 90, you're actually getting sine at direct north, instead of direct east. To fix that, we need to make sine measure clockwise by making it negative. We also need to have it start measuring at north, so we add 90 degrees. Cosine should measure counter-clockwise, because its sign changes are opposite that of sine's, but it should still start at north. +90. So the final command looks like: object setVectorUp [cos (getDir object + 90), -sin (getDir object + 90), 1 / (tan X)]; ... for pitching up. For pitching down, we have to make a few changes, because if we just make our angle negative, we make the entire z axis negative, which flips the object over. Thankfully, this fix is easy; we just have to reverse the signs of sine and cosine. So we get: object setVectorUp [-cos (getDir object +90), sin (getDir object + 90), 1 / (tan X)]; and this works because by reversing the direction of the vector, we reverse which way the top points. What about setVectorDirAndUp that everyone uses? Personally, I haven't been able to successfully use setVectorDirAndUp. It has weird working conditions (most times I get no orientation change, if I do it's way off from what I'd get using the commands separately), and I suspect it has to do with intricacies of when exactly vectorDir and vectorUp are applied and that my method requires the object's azimuth be known and fixed before setting its vectorUp. I'm sure there's a way to use it, I just haven't been able to figure it out and I'm content to use both commands individually. Hope this helped! If anything's too confusing, let me know so I can clear it up.
  3. So I've been experimenting in the editor, trying to make "standoff" armor for APCs, make big ridiculous armored gun trucks, things like that. Basically the kind of makeshift DIY stuff we see in Iraq and Syria. Naturally, I'm using the attachTo and setVectorDirAndUp commands in each objects init field for this. This is an EXTREMELY time consuming and tedious process, as I have to fiddle around with the X,Y,Z coordinates of every piece and then hit "play scenario" just to test the placement of each piece and then end it, make guestimates, rinse, wash, repeat. Is there a way to do this easier? Like maybe some mod or addon or something that lets me just sync the object to the vehicle and then move it around with the mouse? Or maybe see my X/Y/Z coordinate adjustments in real-time in the editor, as opposed to having to start the scenario each time to see the placement? I've got some really cool ideas, but my god is this a pain in the ass lol. Here's some WIP/ideas I'm messing with now:
  4. Is there a practical way to do that? Something that can catch relative positions between elements of a composition made in the editor and then "converted" to be used with "attachTo" and "setVectorDirAndUp"?!? I understand the logic of scripting, and also know relatively well, the "OFP/ARMA language" but I really suck at combining both things (well). Is not that simple, could be a potencial "very usefull" script! by
×