t_d

Another update: The MLOD file format was also added. It is the editable format of p3d files.

The OPRW (binarized wrp) file format is now added in BIS.WRP package. Normal WRP is currently not implemented. It is not difficult though and maybe someone would like to "donate" code for that :)

A few days ago I decided to put most of the code to public that I created in many years working with ArmA file formats. So I put it on GitHub here. While there are a lot of PBO libs already floating around it is quite rare for other files like PAA, RTM etc. My idealistic goal for this project would be that it evolves to an active open source project where contributors add useful and easy to use APIs and add more features. This would facilitate creative tool developers to create tools that are working with those files, which they could not before, because they did not know the file format or it was too much work to implement it. So don't be shy, make some Pull Requests and improve or extend the code. Or Post ideas how to improve/extend the API. I will also add more file formats like OPRW (binarized wrp) and probably MLOD (editable p3d). However, ODOL (binarized p3d) will be not included for certain reasons.

There are so many ways to create such transformations matrices: Most commonly you create a matrix for each operation you want to perform like rotating, scaling, translating, mirroring etc. and then you multiply those in order of the operations to get a single matrix that holds all those operations. Here you can see how those single operation matrices are built.

Those are not documented. However, I know the basic structure of tv4l files. It is basically a list of name and value pairs with the possibilities of more complex values like lists or records. And a big chunk in the layer files is a quad tree containing object information.

To calculate the values of 3DEN you should find out what they actually are, i.e. what unit and what kind of coordinate system, what kind of angles, value range etc. We know this for both commands you noted. getDir for example returns a value between 0 - 360 in degrees and it is working counterclockwise starting with the north direction at 0. If we assume X,Y and Z are Euler angles than one of those definately corresponds to the value of getDir. It might be that they use a different unit like radians instead of degrees or a different value range (-180°-180°) but it would be possible to calculate the 3DEN value from the getDir command. So, since I dont know what kind of values are used in 3DEN I cannot tell you exactly how to calculate them, but maybe someone knows that or you do some measurements to find out some hard facts. For example do you need a value of 90 or Pi/2 to rotate something by 90°? That would give a hint about the unit.

Here is how BIS seems to simulate free falling bombs: https://pastebin.com/teQntUBp (already stripped down most of the unimportant code). Maybe you can deduce a formula from this. Let me know if something is unclear and I will try to explain. Vector3Val position = FutureVisualState().Position(); Vector3Val speed = FutureVisualState().ModelSpeed(); float mass = GetMass(); Vector3 force(VZero), torque(VZero); Vector3 friction(VZero), torqueFriction(VZero); Vector3 pForce(VZero), pCenter(VZero); // body air friction pForce[0] = speed[0] * speed[0] * speed[0] * 5e-4f + speed[0] * fabs(speed[0]) * 10.0f + speed[0] * 10.0f; pForce[1] = speed[1] * speed[1] * speed[1] * 5e-4f + speed[1] * fabs(speed[1]) * 10.0f + speed[1] * 10.0f; pForce[2] = speed[2] * speed[2] * speed[2] * 1e-5f + speed[2] * fabs(speed[2]) * 0.01f + speed[2] * 2.0f; pForce[0] *= ammoType->sideAirFriction; pForce[1] *= ammoType->sideAirFriction; pForce[2] *= ammoType->_airFriction; pForce *= mass * (1.0f / 10.0f); friction += pForce; // aerodynamic non-stability makes direction aligned with speed pForce[0] *= 0.1f; pForce[1] *= 0.1f; pCenter = Vector3(0.0f, 0.0f, +0.3f); torque += pCenter.CrossProduct(pForce); // calculate draconic force (which makes direction aligned with speed) // note: this should be calculated for all missiles, but it is too late to add it now, as it might cause some changed behavior. pForce[0] = speed[0] * fabs(speed[0]) * -0.00033f + speed[0] * -0.005f; pForce[1] = speed[1] * fabs(speed[1]) * -0.00033f + speed[1] * -0.005f; pForce[2] = 0.0f; pForce *= mass; force += pForce; // convert to world space FutureVisualState().DirectionModelToWorld(friction, friction); FutureVisualState().DirectionModelToWorld(force, force); FutureVisualState().DirectionModelToWorld(torque, torque); torqueFriction = _angMomentum * 5.0f; // add gravity pForce = Vector3(0.0f, -G_CONST, 0.0f) * mass; force += pForce; // calculate new position VisualState moveTrans = PredictPos<VisualState>(deltaT); ApplyRemoteStateAdjustSpeed(deltaT,moveTrans); Vector3Val newPos = moveTrans.Position(); Vector3 lDir = newPos - position; Move(moveTrans); DirectionWorldToModel(FutureVisualState()._modelSpeed, FutureVisualState()._speed); ApplyForces(deltaT, force, torque, friction, torqueFriction);

I can recommend this grammar description which is pretty accurate: http://foxhound.international/arma-3-sqf-grammar.html. It just misses some special operator precedences like atan2 but this is just needed for a more semantic check

Since AddonBuilder is written in .NET it is very easy to decompile ^^ Just saying...

You probably updated BIS tools before the game was updated. That's why the tools created a version of the p3d format that the game that is not up-to-date cant read.

Try not binarizing the model. A3.exe will do it then knowing about that LOD ;)

It is 4e13. I am pretty sure the value in the biki article is a typo.

4e13 is the definite resolution value for the PhysX LOD and it shouldn't matter that the current O² doesnt know that because it will still create the correct MLOD. The current binarize though doesnt know that this LOD is a special LOD and might treat it incorrectly. So I recommend to put the MLOD only into the pbo. This way A3 Alpha will do the binarization and A3 knows how to treat this LOD ;)

Eliteness doesnt create texHeaders. Same for all the other mikero tools. But it seems technical possible since the file format you linked above is almost completely known. Maybe he integrates it if he is bored ^^

Dont care about them. Afaik they are used by the engine for texture caching. These files are automatically created by BinPBO/binarize with the right setting.