da12thMonkey

You need a class cfgMods in your config, and in your item classes you need to add a parameter dlc = "YOURcfgModsCLASS"; Your cfgMods class is the same format as a mod.cpp file that you put in the modfolder. There's an example of one of those in the "Presentation" folder that comes with the Arma 3 samples on Steam (Samples used to be bundled with the Tools, but now they're separate) The mod.cpp is used to display information on your mod in the main menu, expansions window and the game's launcher, however the only thing that that cfgMods seems to do now is add logos to the Arsenal with whatever image is path is written in the logo = " "; line - so maybe you only need that one parameter. The external mod.cpp can point to images inside .pbo files, so you can keep all your picture = " "; logo = " "; logoOver = " "; and logoSmall = " "; images inside a .pbo rather than put them externally next to the mod.cpp in the modfolder

Looking at your model.cfg the animation is called HRotor. rotorH is the name of the animationsource, not the animation. The syntax should be _OBJECT animate ["HRotor", 0]; I can't guarantee that the above works since I haven't tried it on a heli rotor yet, but for certain the animate command uses the classname from under class Animations in your model.cfg as an argument, not the source name for that animation. Replace the 0 with whatever phase value gets the rotor in the position you want it in. You don't need a custom rotorH animationsource class in your config since it's already one of the hardcoded sources for the helicopter simulation type. If you're adding a new 'user' sourced animation, it needs a different name.

I only ever seem to see F-15Es from Lakenheath down there when I've been on a trip to the coast, driving down the Dovey/Dyfi valley. Bloody Americans... think they own the place! :D

Never tried to do it without a .rvmat but maybe one of the Lighting & Shadows options in the Face Properties window will do it (select faces/verts and press [E]) or the Lighting options in the Vertex Properties window (select faces/verts and press [Shift+E]), though the header vertex properties window suggests that the lighting settings there are "obsolete".

You also need a model.cfg file with the name of your hiddenselections ('pod') written in the sections[] array of the CfgModels class. At its most basic, I think this would work: class CfgModels { class Default { sectionsInherit=""; sections[] = {}; skeletonName = ""; }; class droppod: Default { sections[] = { "pod" }; }; };

An RNLAF grey one? I thought only the D-model Dutch Chinooks were green, and that the six F(NL)-model aircraft currently in service were grey.

That probably wont be doable because IIRC the HEMMT containers are a proxy model, a separate .p3d to the vehicle .p3d and loaded via a fixed path. Changing the appearance of proxy objects requires physically altering .p3d model files.

Ah, I had a play around with it some time last year for the exact same purpose - speeding up a base for zBrush work. By the sounds of it your experience so far is much the same as mine was, but I'd say you're getting nicer results than me - looks pretty decent. By the end of it I felt like I needed real-life experience of fashion-design/tailoring real cloth patterns or something in order to get garments that looked "right". Getting things to fit in terms of getting the pattern curves the right length or shape takes a lot more skill than it appears to at first glance. In the end I think I just should practise zBrush more and get better at sculpting cloth. :D

You're using Marvellous Designer for the uniforms?

This isn't FADE kicking in, is it?

Are you trying to get it from Play With Six? When I updated yesterday I found they had cocked up the update on their network so it installs the .psd texture template files fo their subscribers instead of the .pbos - so there's no actual addon loading from the folder when you run the game. Dowload it from somewhere else or wait for them to sort it out.

\A3\Data_f\proxies\muzzle_flash They're modelled in to the weapon as a proxy object, pointing to another model that contains the muzzle flash. Different weapons use different models. Binarised ODOL .p3d for the models (we're on something like version 60 of the format now), textures are 32bit .paa with an alpha channel - same as every alpha texture in the game, they also have a .rvmat file to illuminate them. The way I see it, you'll have to do a lot of hex-editing of the .p3d files and repacking of BIS's .pbo since the model paths to the proxies are hardcoded in the weapons. Releasing modified versions of the game's core .pbos is usually a recipe for disaster.

It's a real one. Different model to his F-16; bigger wing area, different tailplane, different canopy, new (WIP) cockpit etc. Old pic of the two together: http://i1179.photobucket.com/albums/x383/firewill0/2015-08-05_00006.jpg

I'm reasonably sure that Edge isn't intent on putting his models in Arma himself, and put them on GameBanana so that other folks with knowhow of Arma modding could do so: I don't think you're stepping on any toes mate.

New Glock holster is by Radar 1957. The one in the pic is the Serpa holster for the SIG Sauer. But yeah, basically everything he's wearing in that photo is in the process of being replaced now, apart from the Tier 2 pelvic protector and possibly the trousers. Even the UBACS has been updated since.

Probably wouldn't be something we put in the addon. But maybe I'll do one and let people download the .paa files for setobjecttexture purposes in a mission. I already did one for fun on the model's previous UV layout, but the new non-mirrored UVs would allow me to actually make the camo pattern accurately

RC = Release Candidate for the main branch, so I would imagine it is extremely unlikely to appear on RC until just before it's released on the Main Branch - i.e. next year. Dev is very much for "in development" stuff (which is why the diagnostic .exe is there but doesn't appear in any of the other branches) and not everything gets passed from Dev to RC ahead of the Main Branch patches.

In the spirit of experimenting with the texture allocation and performance of the EGLMs during the process of these improvements: Has any consideration been given to applying Collimator/texCollimator type .rvmat shader technology to the GL red-dots in the view Pilot LOD, in order to bring them to visual standard with other collimator sights in the game? I was curious whether there might be problems using the collimator shader on this type of rotating optic as built in to the weapon model, rather than as a static proxy attachment.

It's the additional draw call for the new grenade _CO, _SMDI, _NOHQ and _AS textures (i.e. adding an additional section to the models with UGL) that will have the performance impact - it's not to do with poly count. Basically there's no room to fit textures for a grenade on any of the existing UV layouts so it'd have to be added as a separate texture/UV set or do a whole bunch or rearranging. ^Locklear already said it^ The UGL rifles already have more sections than the standard rifles, owing to them having the red-dot quadrant sight that requires a texture for itself and a separate _CA alpha texture for the reticle and lens. If I was BIS I'd consider making making a new 2048*1024 texture with a3\weapons_f\data\gl_holo_co.paa taking up one half (1024*1024) and adding the 40mm grenade textures to the other half. Then simply load the models up in O2, scale the quadrant sight's UV's by 0.5 in the U axis with the transformation centre set to the [0,0] UV coordinate, apply the new combined texture and UV map the grenade to the other half. That way, the section count remains the same since all the GLs use the quadrant sight and already have that additional texture. Texel resolution remains the same for the weapons and the quadrant sight since you're not really doing any major UV-fuckery. And the only performance hit is that the texture file sizes are larger by a few MB - owing to that they're now a 2048*1024 rectangle instead of a 1024*1024 square - but this is still smaller than the standard 2048*2048 panels used for most assets in the game. Obviously keep the old a3\weapons_f\data\gl_holo_co.paa texture set, since some addons might be using it and you wouldn't want to cause their UVs to stop matching the texture.

Impressive!

I mostly just use the debug console's execute window for a notepad (press the ` key in EDEN). Whatever you write in there stays there until you delete it, even after you close the game and start a new session.

Regarding that T-50 model too: are you going to remove the air data boom on the nose? Such things are normally only fitted on the initial prototype versions of the airframe in order to collect flight data. Indeed, the 3rd, 4th and 5th prototypes (053, 054 and 055 - the one that caught fire) don't have an air data boom on the nose.

I agree with R3vo, and would call it splendid :) Thank you for the effort

Unless I've overlooked something on my admittedly brief time spent enjoying EDEN, I think more immediate/visual access to classnames of objects would be nice. In the 2D Editor the classname displays in the Insert/Edit Unit interface so it'd be good if it showed in the Attributes window of an entity in the 3D editor at least: To read the classname of an object in EDEN now it seems I have to right-click it and "find in the config browser" which is reasonably slow since it takes a moment to load the config browser. Alernatively, the ability to simply right-click and copy an Entity's classname to the clipboard would be useful I think - perhaps also the option to copy its variable name from the right-click menu too. So that one could directly select an Entity (or maybe even a group) in the editor and paste its classname or variable name directly in to a scripting console. Perhaps if we could search the Assets and Entities panels by classname as well as displaynames that would be cool too. :)

It's the Kawasaki KLX 250 from Gachopin's JSDF mod: https://forums.bistudio.com/topic/163441-gac-jsdf/