da12thMonkey

IIRC you have to first call the parent subclass from inside the class call to which it belongs. class soldierGB { class EventHandlers; }; class I_G_Soldier_base_F : SoldierGB { class EventHandlers : EventHandlers { init = ""; }; };

Pretty sure that kind of pose is never going to work for a handanim mate. Position of the hands in handanim is based on they relative position to the weapon bone wherever it is being pointed by the various anims for the walking states. If you want your weapon to point up in the air like that you either need to make new walk animations or gestures of some kind, or physically rotate the weapon model inside the .p3d to point up towards the Y direction instead of the usual way they're built to point along the X-axis - but that means it'll be pointing in the air when it comes to shooting and aiming, and therefore be useless. In short, you can't reorientate the weapon like that, in a handanim.

It's possible but ideally you want to use as few texture panels as possible because each separate texture+material set you apply requires an additional draw call from the GPU. The number of texture+material sets applied to the model is referred to as the "section count", and is displayed in Object Builder along with the polygon and vertex count as in indicator of performance. High section counts and lack of resolution LODs are normally the #1 culprits when an addon model causes frame-rate drops for players. Using loads of separate textures is exacerbating performance requirements by the fact that you'll also have a normal map, [specular+gloss] map and ambient occlusion map for each diffuse/abledo/colour texture. So having a model with 2x abledo textures, would in reality require the game to load and render 8 .paa files on the model and having one with 3x textures = 12x .paa files, 4x textures = 16x .paa files etc. etc. Using fewer files is faster over all. What you'll usually find on weapons that have more than the 2 standard 2048*2048 textures, is that the additional 3rd, 4th etc. files are smaller ones which only contain UVs for model components that have specific shader requirements that aren't well suited tot the main texture. In particular this applies to alpha textures used on the model (you want to map any parts of your model that require an alpha channel to a separate _ca.paa texture, rather than use a _ca.paa for the whole weapon including the opaque body), or if part of the model requires an extreme change in its specular appearence that can't be delivered by the specular map alone (i.e. if you need a different fresnel value in the .rvmat to make a glass part really shiny where the rest of the model is more matte). If you want to make it easier to swap parts in your models my recomendation would be to map the elements that are common to all variants to one of the 2048*2048 textures. Then UV the alternating parts to the other 2048*2048 with a UV layout that makes it easy to cut up, move around and knit the individual texture elements for those parts together fit the UV layout of individual sub-variants of the weapon. It's still fiddly to knit averything back together, but it's doable.

1:2/2:1 rectangular textures work. So long as both dimesions are 2^n on any file (512, 1024, 2048 etc. etc.) everything should be okay, but there is the possibility that odd ratios like a a 512*4096 (1:8) might cause problems. Personally I wouldn't bother with 4096*4096. The game can handle them but since the file sizes are appreciably large, they're usually the first texture that gets mipmapped in a scene when Arma decides it needs to use the VRAM for something else. You can end up with something that after a bit of play time, frequently looks worse ingame than if you simply used a couple of 2048*2048 panels to optimise the VRAM requirements. Looking at the game's files, most rifles and MGs have 2x 2048*2048 textures.

I'm sure if most modders wanted to get paid direct comission for creating models to other peoples' specifications, they'd be sensible enough to charge the industry standard rates for comissioned 3D work - which often runs in the region of several thousand dollars. i.e. it's probably unrealistic for you to believe you can afford to pay somebody to make a mod for you unless it's something they already want to make themselves and they'll do it for cheap because they were making it anyway, or they're too stupid to know how much money they could make doing comissioned work for people elsewhere online. Bear in mind that you're also in competition with BIS on this since they are currently offering to pay community members for outsourced 3D work on the Tanoa expansion, and can probably afford to pay people here more than you can: https://www.bistudio.com/company/careers/3d-artist-for-arma3-structures

There's a weird issue in Object Builder where it doesn't seem refresh normals itself until you save the .p3d or cut and paste the model to refresh it after importing. This usually manifests itself in a way where you import the model and it has the all the correct smooth and sharp edges you had in your original modelling software, then when you save it or otherwise refresh the normals, Object Builder decides to fuck the whole thing up and put smooth and sharp edges in places where they should not be - so you have to manually fix them. https://forums.bistudio.com/topic/173014-arma-3-normal-space-problems/

It's because the game moves the camera to the "opticview" memory point before loading the 2D scope. Momentarily you're looking through the model as though it were the 3D version of the scope, and the 3D optic has a .rvmat that makes the reticle glow red at night, so that's what you see. Unfortunately it's no longer possible to use .rvmats to create night-only reticle illumination the same way you can do with 3D ones.

Any additional information on this?

The missing lines/edges is just a weird visual glitch in the Object Builder viewports when viewing wireframe on shaded. The physical polygon edge connecting the verts is still there, and you can see it if you switch the viewport to wireframe only mode or use the Direct3D mode.

Even sadder: so is the author of the majority of the mod's content. ObmaR died in a motorcycle accident back in 2010. IIRC the other menbers of the team didn't have access to his stuff, so the mod pretty much died with him.

According to the notes in the ASDG JR topic, it was changed: https://forums.bistudio.com/topic/157965-asdg-joint-rails/?p=2903447

Aww, no fun: I had no prior knowledge on this one! Obviously I have the best google-fu here though, because I'm pretty sure I've found out what it is now. ;) But rules is rules... Ed:- As you say, the dials (two of them at least) were the starting point I used to find it out.

Much like PuFu said. Check the A3_character_template.p3d and you'll see that there's no 'bysta' proxy in the view-Pilot LOD. i.e. The Head model isn't supposed to be included in the first person model

SU-277/PSQ isn't it? http://www.insighttechnology.com/l3-products/bsm Was also tested with the M224A1 60mm mortar. http://www.stripes.com/news/marines-in-afghanistan-getting-mortar-improvements-1.251538# http://www.onr.navy.mil/Media-Center/Press-Releases/2013/TechSolutions-60mm-Mortar-Sight-Accuracy.aspx https://c4.staticflickr.com/4/3942/19109787350_11ad40e224_k.jpg https://c1.staticflickr.com/1/347/19110482140_9bbfae6e99_k.jpg https://c1.staticflickr.com/1/258/18676842263_31cb71ae40_k.jpg

Does it need to run in loops or can you get it to run on an eventhandler so that the script triggers only when something like an InventoryClosed or Take event occurs? I would imagine these would be the events where the change between a player's weapon having a muzzle attachment or not would happen. But I'm no scripter so I have no idea if this cuts down on looping checks or is a good way to do it in general.

AFAIK there are limitation with using modelspecial in that the weapon model is a static proxy and stops supporting various model.cfg animations, so it might not be the best solution in all applications https://forums.bistudio.com/topic/171566-problem-with-floaty-weapon-parts/ I think R3F and Purple both developed some script-based solution for using rifle grenades with the muzzle slot on their respective FAMAS addons.

Just make it to scale with the real thing. Arma's modelling software is scaled with a 1 meter grid size that relates to a 1 meter distance in the game. So if you model in another piece of software where the grid size is in meters, it'll import at the same size. If your grid is set up in other units (mm, cm, inches etc.) you just apply the correct scale factor to convert those units to meters when importing the model to Object Builder. If your grid in Blender is using cm units and you want a Suppressor that's basically a cylinder, 15cm long with a 3cm diameter, you just model it so that it's 15 grid units long and 3 wide, then when it comes to importing it to object builder you apply a master scale factor of 0.01 (because 1cm = 0.01m) and it will be 15cm long and 3cm in diameter ingame. There's an option to do this in the various importer windows (.obj import, .fbx import etc) or you can just manually apply a discrete scale factor to the X, Y & Z axis (select the model and go \Points\Transform 3D\Scale) If you imported it with a master scale factor of 1 it could have been 15m long and 3m wide ingame, if you used a master scale factor of 0.001 it would be 15mm long and 3mm wide ingame, and so on. With attachments, the main issue with getting it to look right on a weapon is alignment. What you need to understand here is that the spot where the attachment model loads/spawns on the weapon model lines up with the [0,0,0] grid coodrinate in your attachment model. Here you see a picture of a weapon with the TOP proxy for optics attachments: http://img853.imageshack.us/img853/4763/yc81.jpg The spot on the proxy where the attachment models will load from is that 90-degree corner on the big red proxy triangle. So that corner vertex will be where the [0,0,0] grid position in the optics model will snap to. Generally with suppressors, the MUZZLE proxy is aligned directly along the bore-axis of the weapon's barrel so the bore of your suppressors should lie on the Y=0,Z=0 plane, and you only need to adjust the position of the suppressor along the X axis until it's positioned wherever you want it to sit along the length of the barrel. Looking at some of BIS' handguns I think the proxy is positioned at the tip of the barrel, sitting flush with the slide/frame, so if you make the rear of your suppressor flush against the X=0 line, it'd probably appear in the right position without being so far forward that it's floating in the air, or too far back that it's clipping through the pistol's frame.

I don't read Japanese myself but after some googling I was able to find what appear to be matching text strings in Kanji/Kana: Ejection Seat (https://ja.wikipedia.org/wiki/射出座席): 射出座席 Airframe number 13-8514 (http://flyteam.jp/registration/JA8141 æ©Ÿä½“è¨˜å· at the top means "aircraft registration", but æ©Ÿä½“ç•ªå· written further down the page looks more like what is written on the F-2A): æ©Ÿä½“ç•ªå· 13-8514 This aircraft uses the fuel GRADE JP-4A (http://www.geocities.jp/aobamil/shasin/F2/F2Bsisaku.html): ã“ã®èˆªç©ºæ©Ÿã¯GRADE JP-4A ã®ç‡ƒæ–™ã‚’使用ã›ã‚ˆ ^Thanks to classic for the correction with missing よ^ For rescue (http://pasha-kasha.com/?p=389): 救助用 The characters seem to match up so far as I can tell

The removal of underground objects as a feature of Arma 3 was explained: it couldn't be made to work with the AI. BIS already get enough complaints about how the AI can't do things that seem logical to us humans, like reversing vehicles properly, crossing bridges, walking through narrow gaps, entering buildings for cover. So why on earth would they willingly decide to add a bunch of stuff that'll make the AI more worthy of complaint? I suspect AI is also a factor in why they don't do walking on moving platforms, and IIRC they elected not to do fastroping for the Heli DLC either since the AI would mostly just walk off too their deaths. Shitty AI isn't so much of a factor in VBS since the humans are often performing all complex tasks in the training scenario.

AFAIK it's not possible to do it in a simple way since the IR laser model used is hardcoded to the way that laser attachments are simulated. There aren't any config parameters attributed to the beam itself so it appears the game must always apply the same model to an attachment with irLaserPos memory point, because it's told to do so at the engine level. On real life visible lasers though, all you can really see with your eyes is the laser point that's projected on whatever you're aiming at. One can only see the beam if there's a lot of smoke or dust in the air that reflects the beam before it hits a wall. NVGs make lasers more visible because they are more sensitive to low levels of light, so there doesn't need to be quite so much dense smoke and shite in the air. I've seen a couple of people script fake visible laser dot points that are projected in a direction from the player's hand similar to how people used to do hand-held flashlights in OFP and Arma 1. IIRC ACE for Arma 3 has a visible laser attachment that does this.

Arma uses meters scale. So 1 grid unit space in Object Builder = 1 meter ingame.

The flags in the Arma 2 sample models pack (\A2SM_Data_APL\Wheeled\CA\Wheeled\flag_alone.p3d and \A2SM_Data_APL\Wheeled\CA\Wheeled\flag_AUTO.p3d) only seem to have the following properties in the model.cfg: class cfgModels { class Flag; class Flag_alone: Flag { sections[] = {"latka"}; vertexSelections[]={"latka"}; }; class FLAG_auto: Flag { sections[] = {"latka"}; vertexSelections[]={"latka"}; }; }; The most interesting parts are the named properties inside the .p3d which appear to describe the size of the flag plane and how it is subdivided: xsize = 0.99 ysize = 0.52 xcount = 6 y count = 5 I assume this is used to create some sort of automated, "random" animation matrix of the vertex points, in the manner of a flag blowing in the wind. Named selections are all in Czech so I conclude the flag simulation is pretty "legacy" stuff from the OFP/Arma 1 era. Latka = "cloth" Pevne = "firm/fixed" I assume this is because this selection corresponds to the verts on the hoist side, which would be under tension Volne = "loose" Zbytek = "the rest"

As a persyn that identifies as a genderfluid, muslim, goldfish; I found it offensive. Were the Korean (I think) spam threads that were showing up before the Arabic ones, advertising football as well?

I suppose you could organise it like this: Main .pbo addon that just adds the uniform objects etc. Secondary config addon that provides editor-placeable units, with a weapon pack dependency Since the Virtual Arsenal became a thing, I think a lot of individuals and groups in the multiplayer environment make their own customised "loadouts" anyway. Separating out the editor units with set weapons can cater to the people who just want to mix and match weapon packs and uniforms, while scenario editors can use the proper unit config and demand users to install it when they play that scenario.

https://community.bistudio.com/wiki/Arma_3_Unit_Insignia#Insignia The part that says Would imply that insignia on vehicles simply isn't supported in the function yet, wouldn't it? However, if a vehicle has the "insignia" hidden selection defined in the config, you should be able to use the hiddenselectiontextures command to apply a picture to that selection. Just use the correct index number for that selection. e.g. _objectname setObjectTexture [2, "pathToTexture_ca.paa"]; Would work on a vehicle where "insignia" is the 3rd entry in the hiddenSelections[] array (Since arrays are given index numbers ["0","1","2"...] so the 3rd entry has an index number "2")