t_d

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.

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 :)

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.

Some people wanted to have these tools, which were created for kju's PROPER vegetation pack and so I release them now to public. - ResLodRemover: This tool can delete resolution LODs from binarized p3d (ODOL) files. ResLodRemover Download @ DevHeaven ResLodRemover @ armaholic - MipMapRemover: This tool can delete single Mipmaps from paa files. MipMapRemover Download @ DevHeaven MipMapRemover @ armaholic Both tools need .NET Framework 3.5. Bugs, wishes, ideas etc. can be posted via ticket here: http://dev-heaven.net/projects/tdt/issues

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.

In sourcecode of http://sahraniradio.com/radioplayer/ there is this comment: <!-- We do know our radio needs to be repaired, we're having problems with external interference. use the dials to finetune the radio --> Found this because of the tweets by Randall Hubb: *Radio disturbance - Dont you hate that when you listen to your favorite radiostation ? *I might need to buy a better radio. It is kinda old. http://goo.gl/PC1hu #disturbance *Weak and the powerlesss - A perfect circle. i love that song!

ftp://ftp.ofpr.info/ and ftp://m26.node-42.rv4a3.org/ seems to have the same data now. Is it same machine? EDIT yeah, both domains have same IP

Probably someone started a brute force or dictionary attack ^^

Just one more consideration. The low section count is especially important in lower resolution LODs, because these are the ones you will have in masses in a scene at a time. You rarely see more than 3 first LODs at a time. Maybe that's why BIS can accept a lot of sections in first LOD sometimes. But I am pretty sure it is very low in low LODs ;)

Try something like this: F:\dumdedumdaa\mipmapremover.exe myFace.paa myFace_wo_Mipmaps.paa 0 20

paa and jpg compression are working completly different. paa is nearly lossless. If you want to reduce file sizes of paa you dont have many options. Make sure you use the latest texView2 which uses LZO compression (automatically). Besides reducing the resolution your last option would be to remove the mipmaps of the texure via MipMapRemover which can be found here: https://dev-heaven.net/projects/tdt/files Otherwise you have to go with jpg.

Yeah I know, but I didnt want to waste my time describing the workaround if it wasn really the problem ^^

Do you have more than 55 bones? That's also a limit ;)

Yeah, I really would love to enter all the BIS keys I have (OFP,ArmA,ArmA:QG,ArmA2,ArmA2:OA,BAF,PMC,TOH = 8 keys) for...well...nothing ^^