da12thMonkey

Time to see whether Japan didn't fluke the last game. The IRB rankings now place Japan one place higher than Scotland so it should be a good indicator of how good Japan actually are and certainly how much they're improving as a team. They haven't played each other in a Union test match for 2 years (which Scotland won easily).

If you select the texture in the UV window (apply it in the model and Filter by Main texture, or load it with Browse New Texture) the UV window will load the image to the background in the UV window and use the aspect ratio that the file is using. So if you just save a blank 1024x512 image, then load that up in the UV window it should make it easier to visualise the UV layout in the correct aspect ratio. But personally I'd also do what x3kj suggested and just spead the UVs over 2 panels before scaling them by 0.5. If you set the "Center" value in the UV transforms window to "other" it'll use the [0,0] position as the reference point for scaling by default; which means when you apply the 0.5 scale to the U axis, your UV layout will properly squeeze horizontally in to the single panel and keep the exact distance you intended it to be from the panel borders.

You're missing the autocenter = 0 property in your geometry LOD?

What PuFu said. Though some of them are a few thousand polys more (~15k points) in their view-Pilot LOD owing to the fact they have nice round ironsight apertures.

class StageTI { texture = "#(argb,8,8,3)color(0.1,0.1,0.1,0.5,CA)"; }; ambient[] = {1.0, 1.0, 1.0, 1.0}; diffuse[] = {1.0, 1.0, 1.0, 1.0}; forcedDiffuse[] = {0.0, 0.0, 0.0, 0.0}; emmisive[] = {0.0, 0.0, 0.0, 1.0}; specular[] = {0.5, 0.5, 0.5, 1.0}; specularPower = 85.0; PixelShaderID = "Super"; VertexShaderID = "Super"; class Stage1 { texture = "PATH_TO_NOHQ.tga"; uvSource = "tex"; class uvTransform { aside[] = {1, 0, 0}; up[] = {0, 1, 0}; dir[] = {0, 0, 0}; pos[] = {0, 0, 0}; }; }; class Stage2 { texture = "#(argb,8,8,3)color(0.5,0.5,0.5,1,DT)"; uvSource = "tex"; class uvTransform { aside[] = {1, 0, 0}; up[] = {0, 1, 0}; dir[] = {0, 0, 0}; pos[] = {0, 0, 0}; }; }; class Stage3 { texture = "#(argb,8,8,3)color(0,0,0,0,MC)"; uvSource = "tex"; class uvTransform { aside[] = {1, 0, 0}; up[] = {0, 1, 0}; dir[] = {0, 0, 0}; pos[] = {0, 0, 0}; }; }; class Stage4 { texture = "PATH_TO_AS.tga"; uvSource = "tex"; class uvTransform { aside[] = {1, 0, 0}; up[] = {0, 1, 0}; dir[] = {0, 0, 0}; pos[] = {0, 0, 0}; }; }; class Stage5 { texture = "PATH_TO_SMDI.tga"; uvSource = "tex"; class uvTransform { aside[] = {1, 0, 0}; up[] = {0, 1, 0}; dir[] = {0, 0, 0}; pos[] = {0, 0, 0}; }; }; class Stage6 { texture = "#(ai,64,64,1)fresnel(1,0.7)"; uvSource = "none"; }; class Stage7 { texture = "a3\data_f\env_land_co.paa"; uvSource = "tex"; class uvTransform { aside[] = {1.0, 0.0, 0.0}; up[] = {0.0, 1.0, 0.0}; dir[] = {0.0, 0.0, 0.0}; pos[] = {0.0, 0.0, 0.0}; }; }; _NOHQ = Stage 1, _AS = Stage 4, _SMDI = Stage 5 if you don't have a _smdi you can make a procedural one replacing the texture line with texture = "#(argb,8,8,3)color(1,0,1,1,SMDI)"; Keep the Red value as 1 but you can tweak the Specular Intensity with adjusting the Green value between 0 and 1, and Blue to adjust the Specular Power (glossiness). Though since the procedural produces a flat uniform colour, if you leave the blue at 1 you can adjust the overall glossiness by changing the master value at the top: specularPower = 85.0; The _SMDI's Blue channel is a per-pixel scalar for this master value.

If you just save it as _AS.tga, the imageToPAA tool should automatically discard the information from RGB channels it doesn't need when it converts the _AS.tga to _AS.paa. If you write the stage in the .rvmat as _AS.tga, it will convert the material file to .paa when you view the model in buldozer and change file references from .tga to .paa in the .rvmat when you binarise the .pbo - the whole process is quite well automated. _SMDI textures are pretty much the only ones where you need to do some manual channel tweaking to get the right results ("specularity" in G channel, "glossiness" in B channel, plain white in the R channel). Buuuut, if you wanted to manually format it the channel information for the _AS rather than let the conversion tools do it: Fill in the Red and Blue channels with white and just leave the greyscale information in the Green channel - Easy way to do this in Photoshop is to paste your AO bake on to a white background then in FX\Blending Options\ for the AO layer, uncheck the R and B channel boxes.

I know that - I indicated that you only need a low poly for a simple AO. What I was saying there was that in order for the AO to have all the details that are contained within the normal map, you either need to bake both the AO and Normal from the same high poly source (the proper way), or manually convert details from your other 2D texture/materials to shading detail and add them on top of the AO you baked from the low poly. For example here: The blue/black parts are an AO I baked from a 3D model using xNormal (high poly to low poly in my case but for the sake of argument lets say it was a low poly to low poly). The real output material I'm applying to the model is baked @ 2048*2048 res. After I baked the original AO texture I wanted to add some details to the normal map that didn't exist in the source mesh I used to generate the AO (details that I couldn't be arsed modelling in the high poly mesh): So I used 2D software to generate a normal map for these parts. Because I have nDo2 to generate normal map details from 2D, I was able to convert these parts of the normal map directly to an approximate AO for the details that my 2D-sourced normal map was emulating. I then used Photoshop to multiply this converted 2D-sourced AO (shown in red) on top of my baked (blue) AO map in order to generate the final AO that contains details from both my source 3D model, and the normal map enhancements I made. Without nDo2 I'd have had to manually generate the parts shown in red somehow, or just settle for the AO missing some details that might enhance the shading of the model ingame. Final model with this enhanced AO applied looks like this in 3Do/Marmoset and like this in Arma 3. You can see that the additional occlusion shadows in the killflash mesh really bring out the detail of the normal map there, and allowed me to easily generate details in the diffuse/albedo/colour texture and specular+gloss.

AS stands for Ambient Shadow but the standard name in most other applications is Ambient Occlusion map or AO map. You bake it from your 3D models, either using modelling software capable of baking textures and materials (3DS Max, Maya, Blender, Modo etc.) or using external applications (such as xNormal which is free, or Knald which looks better but is not free). Baking AO is not something you can do in Object Builder and it would be very time consuming to manually paint an AO that matches the shadow projection from the 3D model, in Photoshop. Example of Ambient Occlusion baking in XNormal: Doing it properly you would create a high poly model and bake the smaller details from the high poly to your low poly to generate both the normal map and ambient occlusion (lots of tutorials about that online using the software I mentioned previously). However, I appreciate that not everybody has the means to bake from high poly sources like this, and will make use of 2D plugins to generate normal maps instead. But if you're generating the normal map, AO map etc. without baking from a high poly it's harder to get some of the small shadow details from surface objects to appear in your AS, and does require more manual work to enhance the shadow details missing in your low poly game model. Some commercial software used to make normal maps from 2D sources (such as Quixel's nDo) have a feature where you can convert a normal map to something that works reasonably well as an AO. You can then multiply this on top of your xNormal's occlusion output from the low-poly model, without having to have made a high poly mesh. You can also attempt to generate some shadow-like details from a normal map using xNormal's Cavity Map converter and overlaying that on your baked AO output to add enhanced details as well, but the results aren't as good: http://www.donaldphan.com/tutorials/xnormal/xnormal_occ.html If you're manually making the normal map though you can also generate some shadows for your AO by applying a Drop Shadow effect to the layers you're using to generate the height information for the normal map, and again; attempt to multiply these with the baked AO from xNormal.

Japan really have been improving year on year. Like their football team, you can tell they're getting very serious about the sport and their fitness is extremely high, allowing them to play in the later stages of the game with energy that even some players in the top nations don't have. Best try I ever saw at a game I attended was Hirotoki Onozawa running from well inside his own half to score against Wales back in 2007. Japan got demolished in that game, but it's great watching those little teams that can occasionally surprise the big teams with something special.

You can. The correct way to get a bone that moves multiple selections is to set the one bone as a child of the other bone in cfgSkeletons at the top of the model.cfg class cfgSkeletons { class Default { isDiscrete = 1; skeletonInherit = ""; skeletonBones[] = {}; }; class MyWeapon_skeleton : default { SkeletonBones[]= { "magazine","", "trigger","", "slide","", "safety","slide" }; }; }; Bones in the skeleton are defined in "child","parent" pairs. If a bone is defined without a parent e.g. "magazine","" above then that bone only moves as part of the entire geometry, but if there is a bone in between the second set of quotation marks in the pair it acts as a parent to the bone in the first set of quotes. Therefore the child bone will follow the parent bone in whatever animations move the parent bone. More in-depth tut I wrote about complex, multi-bone animations: http://www.rkslstudios.info/public-forum/33/180

If you put the addon you're trying to patch under the requiredAddons[] array, load order shouldn't matter. The game will process your config after it processes the original addon. Filling out the requiredAddons[] array is a necessary part of any config that inherits classes from another config. Also, you don't need "arifle_mas_hk416" in the weapons[] array of your addon's cfgPatches since massi's addon should have already added it. The units[] and weapons[] arrays only need NEW classnames you're adding.

Do you have autocenter = 0 in your model's named properties? It's required in the geometry LOD on models that have animations. Otherwise the game offsets the memory LOD points Open your geometry LOD and press [Ctrl+1] to toggle the named properties window (this just helps identify it in Object Builder if you don't know which one it is). Right click the window and click 'New' then type in autocenter in the name field and 0 in the value field.

It's been possible for cfgVehicles class objects with 'User animation' for a long time, but in OFP/Arma/Arma2/OA it was never possible to do with cfgWeapons class objects. I haven't tried to see whether user anims now (miraculously) also work for weapons in Arma 3, but I'm almost certain they don't.

In the default rifle-raised stance (AmovPercMstpSrasWrflDnon.rtm), a helmetless Arma 3 unit is exactly 1.641m tall Numbers in the vertex properties window show the X,Y,Z coordinates of the rectangular plane (shaded red/pink) that I have snapped to the outermost vertexes of the model when viewed dead-on from the front. You can see the Y coords range from 0.000 (ground plane) to 1.641 for the vert on top of the unit's head. Object builder's units use a 1 m grid and translate directly to ingame measurements, so 1.641 units = 1.641 meters The neutral stance where a unit is standing up straight (not leaning to aim a rifle) is closer to 1.82m as PuFu and others said. This is based on the standard un-animated T-pose of the model. AFAIK there isn't a .rtm in the Arma 3 sample models for the exact standing unarmed/weapon-lowered anims so I'd have to use the older Arma 2 anim to demontrate it. However, the anim may have changed between the two games, and cause some slight discrepancy.

What issue are you having? model.cfg for pistols is fundamentally no different to the one for rifles or any other weapon. AFAIK the only characteristic difference is that they have a "recoil" animation that rotates the entire weapon frame using the reload source.

With the talk of an EU Coast Guard being pushed, it was pretty obvious that this issue would be raising its head again shortly. The UK may be bribed in to dropping its opposition to the creation of an EU Armed Forces and common Defence Procurement framework in exchange for a return of some border controls and legal powers: http://www.telegraph.co.uk/news/worldnews/europe/eu/11861247/Merkel-expects-Cameron-to-back-EU-army-in-exchange-for-renegotiation.html Common procurement strategy that will almost certainly be dominated by the French and German companies, particularly since most of the French defence industry is at least part-owned by the state, and Germany is actively merging parts of its defense industry with France already (Airbus Group already, now a merger of KMW with Nexter). I'm sure it's purely coincidental that Germany goverment stopped buying G36s a month after France started looking to replace FAMAS, and has seemingly done all it can to discredit the rifle since then in order to force a replacement tender of its own ahead of this latest push for common EU procurement. If the two countries don't end up wit the same rifle I'll be very surprised.

https://en.wikipedia.org/wiki/FSC_Star The 4 wheel one is the Star 944, based on the MAN L2000 cab

Then you have to change the name of your cfgModels class to be exactly the same as your .p3d name. i.e change this: class Test_weapon_01_F: tb_arifle_m16a4_base { to this: class testrifle: tb_arifle_m16a4_base {

What's the .p3d of your model called?

And of course, Junker's response to this is, as ever; "moar United States of Europe" http://europa.eu/rapid/press-release_SPEECH-15-5614_en.htm Choice lines: So basically, the EU Commission is looking at this as an opportunity to strive for less national sovereignty on border controls amongst member states.

You missed the third component of the reload animation in the sample model.cfg: class magazine_hide { type="hide"; source="reloadMagazine"; selection="magazine"; minValue=0.000000; maxValue=1.00000; hideValue=0.188; unhideValue = 0.550; }; unhideValue is the point in the reloadMagazine cycle where the magazine reappears The offset values are dependant on how long the memory point axis is in your .p3d. If you have offset1 = 1, the bone will move the full length of the axis, if it's offset1 = 0.5, it'll move half the length of the axis. offset0 is an initial offset when the animation phase is 0, but for the most part you're likely to have modelled the bone in the position you want it in, so offset0 = 0 is usually fine. minValue/maxValue basically tells the animation when to start and end during the animation source length. The time period of the reloadMagazine source is defined in the config.cpp by the magazineReloadTime = parameter (yes, it probably should be called reloadMagazineTime instead; for the sake of consistency. But this is Arma!). If magazineReloadTime = 2; the source controler will take 2 seconds to go from value 0 to value 1. That means setting your model.cfg animation with a minValue = 0.25 and maxValue = 0.75 will make the animation start 0.5 seconds after the reloadMagazine action is started and end a the 1.5 seconds mark (0.25 * 2 = 0.5, 0.75 * 2 = 1.5). Therefore your model.cfg animation will have a period of 1 second within the whole 2 second magazineReload cycle (1.5 - 0.5 = 1, or (0.75 - 0.25) * 2 = 1). The speed at which your magazine is translating along the axis is as on might expect; a matter of distance/time. As you discovered, to make the magazine move further you want to increase the offset value, and to slow the movement down you need to increase the maxValue so that it covers that longer distance over a longer time interval. But you will also want to increase the hideValue in your animation to hide/unhide the magazine, so that the magazine doesn't disappear too early now that the magazine is moving for a longer period. Oh and it's possible to create a fake safety mode. You just have to add an extra muzzle to your weapon (like you would add an underslung grenade launcher) and make that safety muzzle use no magazines. The safety catch can then be animated with the weaponMuzzle animation source.

Yup, I'll readilly admit I was lowballing the estimated work hours here. I wanted to point out that the costs soon stacks up, but without using big numbers that might seem hyperbolic to people here who are not aware exactly how long it can take to make something using the full, modern 3D pipeline. There are shortcuts to take, that can yield acceptable results to the layman and would be the norm in previous gen games (and those are the sort of things one would discuss with the artist when negociating price). But yes; if we're talking about a really great addon that achieves the sort of visual quality that a number of people in this community are doing for free in their own time, for the love of what they do - 10 hrs is vastly under-estimating things. Certainly for me anyway, because I'm pretty sure I'm the slowest 3D modeller in the world (and maybe that's why I don't even contemplate attempting to do this professionally) :D

Depends how well you want it made and how long it'll take the person to do. http://www.katsbits.com/articles/how-much-should-i-charge-for-freelance-3d-modeling-work.php You see there that the industry rate for people working in the US is running around a minimum of $20 per hour, and the people who are better and more experienced will charge you more. People from countries where the average cost of living is lower, may be able to charge less - and it is quite common for larger game devs to outsource 3D work to teams in offices in other countries to minimise production costs. I'd say on average, a well made original weapon model with good quality textures, all materials is at least 10 hours of work. So you'd be looking at spending $200 as a miniumum just for the model alone, and more to get it animated and configged for Arma with all the LODs and things it need - assuming your 3D artist is actually capable of making animations in the first place, and actually knows how to set it up for ingame use. Really though, it's a price you negociate with the artist rather than being a set number - since they need to know what your criteria are, and they then have a fair idea of how long it'd take them to do what you want and how much they want for performing the task. But even if the model is very simple it'll still take multiple hours to make a working addon and will never be something you can pay for with pocket change. You can probably find weapon models cheaper than that on places like Turbosquid, but that's because they're not direct comissions - they're items that an artist has made already as personal projects and will sell to multiple customers to in order to recoup the the hours spent working on it. Generally they're far from game-ready too.

Well, you are missing a }; at the end there but maybe that's just a copy& paste error. Thinking about it, you may also need the parent class for the class that contains the subclass you want to access too: class Binocular; class NVGoggles : Binocular { class ItemInfo; }; class NVGoggles_INDEP : NVGoggles { class ItemInfo : ItemInfo { uniformModel = "A3\weapons_f\binocular\nvg_proxy_OPFOR.p3d"; modelOff = "A3\weapons_f\binocular\NVG_proxy_off_OPFOR.p3d"; }; };

Yes, pretty much. The "weapon" bone in character models is a proxy triangle. The game loads your weapon model to this proxy position such that the [0,0,0] position in your weapon model's grid aligns to the vertex at the right-angled corner of the proxy triangle. The long side of the triangle follows the +Y direction in your weapon model's frame of reference, and the short side of the triangle is the +Z direction of your weapon's frame of reference. In the default pose, the proxy triangle's reference vertex (the one in the right-hand corner) is positioned at [-1,0,0] on the Object Builder grid. So when you import your weapon model to the skeleton you need to move it the equivalent of 1m to the skeleton's right, along the X-axis, rotate it 90-degrees and then it should then be in the same position as the reference model on the blender anim rig.