Jump to content

da12thMonkey

Member
  • Content Count

    4077
  • Joined

  • Last visited

  • Medals

  • Medals

Everything posted by da12thMonkey

  1. da12thMonkey

    Apex Weapon Feedback

    Regardless of the mag thickness, the one in Apex has an angular slide, so it appears much more like a PMM than a PM https://arma3.com/assets/img/apex/weapons/PM9_mm.jpg(Apex "PM") http://content.foto.mail.ru/mail/photoshooter/26/i-54.jpg(PMM) http://content.foto.mail.ru/mail/photoshooter/2/i-15.jpg(PM)
  2. It's done with a shader/alpha sorting trick. You include a mesh plane over the bottom of the boat and assign a3\boat_f\data\antiwater_ca.paa which is a transparent texture that culls the water that would otherwise be visible in the bottom of the boat hull.
  3. da12thMonkey

    General Discussion (dev branch)

    So this is nice. I've had a little play around with it and found that if you set visionMode[] = {"Normal"}; in the config for your NVG slot item, then they no longer have inherent NVG properties. So the NVG slot can now effectively be used as another appearance customisation slot for some items like headsets, face masks etc. in addition to the Helmet and Glasses slots. Also tested out that thermal imaging works, with visionMode[] = {"Normal","TI"}; and can set the various TI types with the thermalMode[] array just like any scope attachment or vehicle optics: One thing I am wondering though from the BIS devs: Is there a way to set an NVG item than has just normal vision modes (so no TI or NVG effect) but still uses the "on" model state as you cycle through the visionModes[] array? I tried setting up an item with visionMode[] = {"Normal","Normal"}; but in that case, cycling through with the [N] key just continually uses the modelOff= state from the config. So I assume the engine handles it such that it goes through the array, and whenever it encounters "Normal" in the array it switches the NVG proxy to the assigned modelOff= state. If there isn't one already: Is it possible that you could add a "NormalOn", "Normal2" etc. state or something that provides normal vision in the array, but with the "On" model state for the NVG proxy? It'd be nice to be able to make NVG slots objects similar to this removable visor that uses the NVG mount on the Arma 3 NATO helmet: http://www.defensereview.com/wp-content/uploads/2011/09/Revision_Military_Batlskin_Modular_Head_Protection_System_MHPS_Ballsitic_Visor_and_Mandible_Guard_Maxillofacial_Protection_System_2.jpg and allow hacky ways of simulating other movable goggles, visors for things like pilot helmets and motorcycle helmets.
  4. da12thMonkey

    Arma 3 - APEX - NEWS and SPECULATIONS

    Portugal, Georgia, Ireland... maybe https://en.wikipedia.org/wiki/ISO_3166-1_alpha-2
  5. setObjectTexture only works on cfgVehicles class objects - uniforms (actually player models), vehicles, props and backpacks etc. Backpacks are unique in this respect that they're a wearable item that can be targeted by the script command with e.g. (backpackContainer player) setObjectTexture [N,"path\To\Texture.paa"] There is no way to dynamically change textures on cfgWeapons class objects - guns, vests, headgear etc. hiddenSelections only work as assigned in the config for that class, so you would have to swap out the entire vest class to change its appearence.
  6. da12thMonkey

    General Discussion (dev branch)

    Is is possible to explain in what way support for them has been improved? I remember various issues existing with plane turrets, like AI aiming, certain weapons being a little sketchy etc.
  7. da12thMonkey

    Arma 3 - APEX - NEWS and SPECULATIONS

    I thought the exact same thing actually, or a bit like the H-37. I think it's partially because the paintjob in the image looks like the old-school "field green" scheme used on those helos as well
  8. da12thMonkey

    Author name in cfgpatches change, why?

    There has been an author= parameter in cfgVehicles, cfgWeapons etc. classes for a while, but it's a new addition to cfgPatches The author[]= array in cfgPatches (which is causing trouble now there is and official author= string in cfgPatches) is as I said; an unofficial parameter that was established by CBA. As to why BIS haven't used author[]= array instead of the author= string for the new official cfgPatches parameter: They're obviously keeping cfgPatches consistent with the name of the other official parameter they were already using in cfgVehicles/cfgWeapons etc. Which makes sense when you think about it.
  9. da12thMonkey

    Author name in cfgpatches change, why?

    author[] wasn't an official parameter in the first place. It was something that CBA added as a feature in Arma 2 (IIRC) to display such information during loading screens etc. And even if they didn't utilise CBA, people added it to their configs by convention (probably from copying cfgPatches structure they found in other mods, ignorant of what it was). https://dev.withsix.com/projects/cca/wiki/Author_and_Credits_system Admittedly it was a bit dull of BIS not to be aware that a lot of community addons used this feature, but it's not like they changed their own parameter like when they change classnames or texture paths or something. Kind of shows the importance of using TAGS_ when implementing custom parameter and variable names in to code, so that everybody knows who adds what, and you avoid conflicting names.
  10. da12thMonkey

    RHS Escalation (AFRF and USAF)

    Reyhard done so, now that he's had time to work on it. It should be a feature included in the next release.
  11. da12thMonkey

    Input needed on Weapon Model

    I think the top gas-tube vent holes are worth having. But for any of those holes I personally wouldn't want them having more than 10 sides. Maybe up to 16 sides for the larger M-LOK type holes or vents or whatever they are, if 10 or 12 didn't look like it was round enough. I'd say if you were to get rid of any of the holes and rely solely on normal mapping, it would be for these ones: Mainly because the barrel occludes looking through those small holes anyway, and there's that countersink bevel around the hole that'd add a lot more polygons if you tried to model the bevel. The countersink would actually probably be the more visible feature of those holes when viewed in first person. More than the bored-out hole in the middle. e.g Broke's custom AR-15: http://files.gamebanana.com/img/ss/models/528fbee9ccd62.jpg http://gamebanana.com/models/3278
  12. da12thMonkey

    New Model config help

    Depends on the software you use really. If you use photoshop, open the "Channels" window and go down to the "Alpha" channel You want this to be completely white if you don't want any transparency in your _co, _smdi, _nohq etc. textures, so select highlight this channel and paint/fill it white if it contains the UV map overlay If you want to check how the alpha looks on its own, just change the visibility of the RGB channel at the top (click the eye icon):
  13. da12thMonkey

    New Model config help

    Looks like you accidentally have the UV map output from your modelling software, in the alpha channel of your textures. Check the alpha channel of all your texture an material files and make sure there's nothing in them that shouldn't be there.
  14. da12thMonkey

    Diversuit (unhide Helmet problem)

    I don't think the wetsuit model even has the proxy for helmets inside the .p3d file, so it's probably not possible.
  15. da12thMonkey

    RHS Escalation (AFRF and USAF)

    Maybe surprising, but the big texture drop here is because the textures are 4096*4096. The game wont display textures at that resolution at all unless you run Very High video settings. It's actually an issue that blackpixxel addressed in the standalone TF47 launcher pack, where other US launchers in RHS come from (but the RHS LAW itself, is by j0zh94). Seemingly causes some headscratching for users, who generally think of high-res texture files as king in graphical fidelity regardless of the engine. Downscaling them to 2048*2048 while allowing for more consistency across other graphics settings, is probably going to result in the range numerals being a bit blurry anyway in this case (though perhaps not as blurry as how they are downscaled by the ingame mip-mapping). Really It's something that would need to be addressed by reconfiguring the use of UV space and texel density in the model. At any rate, zeroing information on the sight matches the value in the UI on the top-right of the screen, so the weapon is hardly "unusable".
  16. da12thMonkey

    General Discussion (dev branch)

    Means Cyrillic alphabet characters, for the Russian language localisation etc.
  17. da12thMonkey

    RHS Escalation (AFRF and USAF)

    No, it's the same model from previous RHS releases. Sabre added a desert retexure for it this time around though.
  18. da12thMonkey

    RHS Escalation (AFRF and USAF)

    Yes, when the inventory change is initialised (e.g. by leaving the Arsenal selection screen to "Try" your current loudout), the script should swap the weapon class for a version with a handanim that matches the currently selected grip attachment. Reyhard is a damn magician! And the second part with the top-rail PEQ-15: it is known. The current top-mounted one is designed to fit the M4s alone really. The model has to be physically offset a specific distance from the side rail 'origin' position, to match where it will appear relative to the top rail. It clips the 416 rail because the 416 handguard rail is higher up than on an M4 (presumably because of the big fat gas piston running underneath it instead of a little DI tube). Alternate model variant specifically for the 416 are something that is on the table. But consensus is that RHS need to work on a way of doing it smartly, without filling Arsenal and containers with so many PEQ variant.
  19. da12thMonkey

    RHS Escalation (AFRF and USAF)

    As Ballistic said, they're calibrated for US 5.56mm and 7.62mm weapons respectively. Primarily for shooting in the high magnification mode More specifically the SU-230/PVS reticle is calibrated for the M4 from 100 to 600m and the M249 (long barrelled) from 700m to 1000m, with M855A1 ammunition. And the SU-230A reticle is calibrated for the Mk.11 Mod 0 with M118 ammunition from 100m to 600m (I used the Mk.11 to calibrate it in the current absence of a Mk.17 SCAR in RHS), and M240 with M80 ammunition from 700m to 1000m The versions with a 2D reticle in the secondary (high-mag) optics mode, have this written in the lower half of the sight picture For ranging purposes, the black bars 200m to 600m are about shoulder-width on a unit at that given range, and the gaps in the bars from 700m to 1000m are two shoulder-widths (so distance from the edge of the gap to the centre axis of the reticle is one shoulder's width). The span between the central dot and the start of the thick horizon lines is 5 mils, so the gap between the thick lines is 10 mils in total, with the length of the thick section being a further 10 mils on top of that (i.e the whole horizon line is 30 mils wide). In 2D mode the red dot is about 2 MOA (1/2 mil) in size, but it's bigger in 3D for the sake of clarity when using the 1x magnification mode in CQB. Also, the 3D crosshair glows red at night
  20. da12thMonkey

    Unifrom Inventory image

    Had an issue recently where an image for a binocular item would show in Arsenal but not in inventory (threw an error: missing blahblah_x_ca.paa even though the item was called blahblah_icon_ca.paa). Somewhat weirdly the solution was making a totally new image file. One with a different filename (that didn't have the _icon_ca suffix), and converting it to a new .paa
  21. da12thMonkey

    See through car

    There's your problem then. You don't have proper _co suffixes on your body texture names to tell the .paa converter to generate a 24bit textures without an alpha, so the .paa files it generates will have some transparency. The textures you want to be solid need to be saved as _co.tga, _co.png etc. before converting them to .paa The textures you want to have some transparency (windows, maybe grille etc.) should be saved as _ca.tga Note, renaming the .paa files after conversion to add these suffixes to the file name will not fix the problem. They have to be in the filename of the source texture in order for the tool to format them properly.
  22. da12thMonkey

    See through car

    What are the filenames of the main body and windows/lights textures? Do you save the original files as body_nohq.tga, body_smdi.paa, body_co.tga etc. before you convert them to .paa? What tool are you using to convert the .tga files to .paa? Do body_nohq.paa or body_smdi.paa have any kind of alpha, or is are they completely white in alpha?
  23. The VMH metal detector was what was generally referred to as "Vallon" but there were some other more advanced Vallon products used by British forces as well. Such as the VMR3 which has an additional ground-penetrating radar for picking up non-metal and low-metal-content IEDs and trigger devices. The VMR detector was officially called "Horn" in UK service originally, but IIRC later versions were called "Minehound". There was also other detection kit like "Goldie" which was to detect command wires, and smaller hand-held detectors like "Hoodlum". But "Vallon" and "Horn" are what you normally see searchers using in photos. Vallon and Hoodlum: https://ukforcesafghanistan.files.wordpress.com/2011/02/royal-engr-iedd1.jpg Horn: https://britisharmy.files.wordpress.com/2013/06/amoc-cct-2013-149-658.jpg Goldie on the left, Horn on the right: https://britisharmy.files.wordpress.com/2013/06/talisman-group.jpg
  24. da12thMonkey

    RHS Escalation (AFRF and USAF)

    TA01s were only issued in SOCOM, were they not? And AFAIK theirs have been largely supplanted by SpecterDRs now
  25. In the end, it seems like Boeing has opted to re-activate the outer wing pylons (F-15A had them, but they were never used) in order to allow it to carry those four extra missiles. Instead of those double-racks on the CFTs. The extra pylon is being incorporated on the F-15SA, developed for Saudi Arabia: Boeing press image of F-15SA CG render with 16x AMRAAMs
×