Jump to content
Bohemia Interactive Forums

da12thMonkey

Member
 View Profile  See their activity

  • Content Count

    4077

  • Joined

  • Last visited

  • Medals

  • Medals

Everything posted by da12thMonkey

  1. da12thMonkey

    Reducing AI manual guidance accuracy

    da12thMonkey replied to Spearpoint's topic in ARMA 3 - ADDONS - CONFIGS & SCRIPTING

    maxLeadSpeed in the magazine?
  2. da12thMonkey

    How to set skin fronty Virtual Garage

    da12thMonkey replied to Don_Juan_the_TROLL's topic in ARMA 3 - QUESTIONS & ANSWERS

    Click the "export" button, paste the output from the clipboard and look for the texture name. Should output a createVehicle script that also contains a reference to BIS_fnc_initVehicle describing the selected customisation options. [ _veh, ["TEXTURENAME",1], ["ANIMATIONNAME",0] ] call BIS_fnc_initVehicle; etc. etc. Modify the function call to be in the format below and add it to the vehicle init [this, ["TEXTURENAME",1], true] call BIS_fnc_initVehicle;
  3. da12thMonkey

    RHS Escalation (AFRF and USAF)

    da12thMonkey replied to soul_assassin's topic in ARMA 3 - ADDONS & MODS: COMPLETE

    No Because Weapon animation sources cannot be fed values via scripts like vehicles can, it can't be something that is controllable without making a bunch of extra weapon models without covers, or a bunch of extra attachment models with all the available configurations of rail covers - we wont be doing that. We can randomise whether the covers show, using the objRandom animation source. It's something that reyhard wanted to experiment with on weapon models, to see if it works or not. Edit: there are issue with the randomisation happening again when the weapon is dropped and picked up, grip attachment is switched (as this spawns a new weapon class for the alternate handanim), etc. etc. So it's perhaps not an ideal feature to add - but maybe no harm in adding it for a while to see if people are okay with it
  4. da12thMonkey

    RHS Escalation (AFRF and USAF)

    da12thMonkey replied to soul_assassin's topic in ARMA 3 - ADDONS & MODS: COMPLETE

    It's not ingame yet (as stated, it's not fully textured yet even). So no I wasn't referring to this one. Most likely will be amongst the weapons we use to equip HIDF as the faction becomes more developed.
  5. da12thMonkey

    Unable to load file. Load error. 3ds to O2

    da12thMonkey replied to Invincible120's topic in ARMA 3 - MODELLING - (O2)

    What file format is it?
  6. da12thMonkey
    AFAIK it doesn't really use either in the vanilla game, as the ballistic simulation is not based on real world physics. https://community.bistudio.com/wiki/Weapons_settings So "airFriction" is a force constant (f = a / v², where a is acceleration along the vector of the bullet, so -ve in most cases). To my understanding the devs just look at doppler data and adjust airfriction parameter find a best fit to the velocity curve over time.
  7. da12thMonkey

    RHS Escalation (AFRF and USAF)

    da12thMonkey replied to soul_assassin's topic in ARMA 3 - ADDONS & MODS: COMPLETE

    We try to avoid doing such things, unless there was a typo or something that made the classname itself a problem. If a class is to be replaced by something, we tend to keep the old classname around, scope it out and reconfigure it to point to a copy of its intended replacement. There may be some exceptional circumstances like the Dynamic Loadouts thing for aircraft: Where we were totally redoing ammo and magazines in a way where the old ammo and magazines wouldn't have worked with the new system anyway. So it was "okay" to discard some of them. But even then, we kept hidden classes or aircraft with their old loudouts, using the new system so that missions should load the units as-was (minus me making a typo in one of the MELB's classnames :D). We are however intending to re-equip some of the GREF units with different weapons for several reasons. This may impact on units that directly inherit loadouts from the existing GREF stuff, or scenarios that adjust the magazine allocations to default GREF units via script/initline. It shouldn't affect those done through the Eden loadout editor however; since that should define the weapon too. Down the line, our effort will probably result in a couple of classesnames being removed from the GREF part of the mod, but not from the mod as a whole. We wont do this until after the next version of the mod though, specifically because we want to give people plenty of time to adjust to use the new stuff while the old stuff is still there. And to update their modset if they need to continue using the parts that are no longer wanted in GREF. We'll be explaining the rationale behind it, along with the next release.
  8. da12thMonkey

    RHS Escalation (AFRF and USAF)

    da12thMonkey replied to soul_assassin's topic in ARMA 3 - ADDONS & MODS: COMPLETE

    No, there is nothing to use it at all. AFAIK it's been in there as long as all the other Russian tank guns, magazines and ammo classes. They were all researched and configured at the same time, so that it didn't need to be done again at a later date. Same as there are other unused guns like the D-10 etc.
  9. da12thMonkey

    RHS Escalation (AFRF and USAF)

    da12thMonkey replied to soul_assassin's topic in ARMA 3 - ADDONS & MODS: COMPLETE

    We can say that some other WW stuff besides the M3s will be in GREF, yes. I believe some *PING*s were heard already, for example. But we don't want it to turn it to a "will X be in the mod?"/"why is Y in the mod but not Z?" kind of discussion based on previously released images of a another project. GREF will get what it gets, if/when it gets it. And confirmation of things being in the mod prior to its release, is usually done at the discretion of whoever made it (for example I'm too lazy to post promo stuff for some small, unexciting models I finished months ago; so none of you know it's going to be in the next release).
  10. da12thMonkey

    RHS Escalation (AFRF and USAF)

    da12thMonkey replied to soul_assassin's topic in ARMA 3 - ADDONS & MODS: COMPLETE

    Nay, the one pictured is from Arma 3. A "light" version that's in there somewhere without the hydro pack that's usually on the model.
  11. da12thMonkey

    RHS Escalation (AFRF and USAF)

    da12thMonkey replied to soul_assassin's topic in ARMA 3 - ADDONS & MODS: COMPLETE

    If you look closely, it's not really new. Or from us in fact. But we're making use of it.
  12. da12thMonkey

    RHS Escalation (AFRF and USAF)

    da12thMonkey replied to soul_assassin's topic in ARMA 3 - ADDONS & MODS: COMPLETE

    It has been updated a quite bit https://www.twitch.tv/videos/268150390 There are other things in the video too. Not so obvious, even though they announce themselves
  13. da12thMonkey

    RHS Escalation (AFRF and USAF)

    da12thMonkey replied to soul_assassin's topic in ARMA 3 - ADDONS & MODS: COMPLETE

    Marines wanted a gun shield that folds down flat when not in use. Presumably for rolling on and off ships The ingame model doesn't do this though
  14. da12thMonkey

    General Discussion (dev branch)

    da12thMonkey replied to DnA's topic in ARMA 3 - DEVELOPMENT BRANCH

    Can't use forceFlagTexture to skip it?
  15. da12thMonkey
    Do you intend to remove the outboard pylons? It could only carry R-60 on previous generation Su-25s, and has effectively been removed on the Su-25SM3 since R-60s are out of use. Position is now where the L-370-3S ECM pods are mounted alone. Self-defensive armament R-73/RVV-MD is nowadays mounted with APU-73 on the main stores pylons
  16. da12thMonkey

    RHS Escalation (AFRF and USAF)

    da12thMonkey replied to soul_assassin's topic in ARMA 3 - ADDONS & MODS: COMPLETE

    Some of the guys spotted that the missile model may also be quite a lot smaller than a FGM-148 should be; so that was another thing we wanted to check It is a very nice model though.
  17. da12thMonkey

    model.cfg - potential axis

    da12thMonkey replied to scotg's topic in ARMA 3 - ADDONS - CONFIGS & SCRIPTING

    Well I haven't tried it on one of my own models to be certain how it looks when eliteness spits the same file back out (why would I when I have the source model.cfg anyway). But it's my understanding of how the axis information is output from eliteness having compared a few things with BIS naming conventions for mem points, and their samples Certainly I've never ever written a "potential" axis in to anything I've ever worked on. And have had no problems
  18. da12thMonkey

    model.cfg - potential axis

    da12thMonkey replied to scotg's topic in ARMA 3 - ADDONS - CONFIGS & SCRIPTING

    When you're writing your own model .cfg you only need to use a selection name for the axis= IIRC the memory LOD axis info is encoded as vertex coordinates during binarisation. So when you use tools to read the model.cfg from an ODOL it writes the axis= parameter as a set of coordinates and has to make a guess of the named selection that corresponds to those vertices, which is what the "Potential" named selections are. But they're not valid from the standpoint of actually being used by the model.cfg, and why they're //Commented out.
  19. da12thMonkey

    Armed Forces:UK Virtus Body Armour

    da12thMonkey replied to mikephoenix's topic in ARMA 3 - ADDONS & MODS: COMPLETE

    The issued Blackhawk kneepads were green. The new Source ones that came with the Virtus kit are MTP with "Flat Dark Earth" hard shells. Pads in the mod look more like the Blackhawk ones Issued gloves are the leather MTP patterned ones. Khaki coloured Oakley SI assault gloves were a one time issued item for Afghanistan. Many buy their own gloves instead of the issued leather ones.
  20. da12thMonkey
    https://community.bistudio.com/wiki/Arma_3_Weapon_Config_Guidelines#Ammo_changes_on_fly_and_on_hit maverickWeaponIndexOffset is pretty obsolete now we have dynamic loudouts. It used to be used to define where certain missile models loaded on the plane model, based on their proxy index number Your bomb models and submunition models need a valid geometry LOD (i.e. with mass and components) and autocenter = 0. Not certain, but it might be why the submunitions spawn with an offset if you don't have it
  21. da12thMonkey

    Problem "vertices of bone shared with parent bone"

    da12thMonkey replied to killjoe_R3F's topic in ARMA 3 - MODELLING - (O2)

    It means that one or more of your model's LODs, some of the verts that are part of the otochlaven selection, are also part of the otocvez selection You cannot share verts (with 100% weight), between selections that are written are written as child, parent in your model.cfg cfgSkeletons class. It breaks the animations that use those bones. You need to remove all verts that are part of otochlaven, from otocvez. Reselect all the verts that you want to be in otocvez in Object Builder, then right-click and Redefine the selection. If it helps, select otochlaven first and View>>Lock/Hide>>Hide Selection or [ctrl+H] so that you cannot select them when trying to Redefine otocvez. Once done, you can re-show otochlaven by selecting it again and View>>Lock/Hide>>Unhide or [ctrl+shift+H]
  22. da12thMonkey

    USP Gear & Uniforms

    da12thMonkey replied to Siege-A's topic in ARMA 3 - ADDONS & MODS: COMPLETE

    More separate texture files = more model "sections" = more draw calls Overall file size/memory usage and texel density might be similar; but you're asking the graphics API to process more files every time it draws the scene, when it could get the same result from processing 1 texture file (+1 file for each material file in the .rvmat) Ranking things that will cause bad performance in Arma: High poly shadow LODs High section counts (you want as few texture+material sets as possible. Object Builder will sometimes make duplicate sections when copy+pasting model parts, so have to check section count and re-merge them occasionally) Poly count (really it's the number of vertex normals) - game will switch LODs to save performance if you make them properly Texture resolution - game will mip-map textures to save performance (4k textures mip-map more readily than 2k because they use more memory) Large texture resolution only really compounds performance issues if one already has the problem of many model sections. Otherwise it's perhaps the least of concerns
  23. da12thMonkey

    RHS Escalation (AFRF and USAF)

    da12thMonkey replied to soul_assassin's topic in ARMA 3 - ADDONS & MODS: COMPLETE

    Was simply the poor choice of phrasing: "I just made my own using all the rhs goodies" We've had a couple of instances of people ripping the AK-74s from RHS.So statements like that can be confusing, without the full context of how the RHS parts are used
  24. da12thMonkey

    Tanks - Fire-control system

    da12thMonkey replied to oukej's topic in ARMA 3 - DEVELOPMENT BRANCH

    CR1 shot in 1991 wasn't done with FCS in the way we know it in Arma 3. It's more accurate to say the FCS was able to lase a target at 4.7km, than to say it was targeting at that distance. The Challenger 1's fire control system (Tank Laser Sight+Computerised Sighting System) worked in a way where an illuminated ellipse reticle moved in the gunner's sight to indicate the required lead and elevation after lasing the target. Once that was done the gunner could autolay, and the turret would move by the amount that the ellipse was offset from boresight. So the ellipse would end up over the target if it was a correct lay. IIRC the crew who did the 4.7km shot had to manually input the required deflection in to the CSS after they took laser measurements; because the system did not automatically indicate for ranges that great. As such it did not automatically lay the gun after lasing. So the gunner either manually input elevation and the autolay moved the gun based on that. Or he manually aimed the gun from boresight until the manually deflected reticle was over the target. The latter operation, is quite similar to zeroing the Arma 3 tank sights up to maximum range and then manually aiming above the target (Kentucky windage style) to add extra elevation required to hit something at 5km. AFAIK all modern tank FCS have the ability to manually input elevation and deflection, for the sake of doing indirect firing at extremes of range, or if the automated system is failing. The TLS sight could theoretically be used out to 10km with "manual" deflection of the aiming reticle.
  25. da12thMonkey

    Arma 3 poly count best practices

    da12thMonkey replied to TurkishSolider's topic in ARMA 3 - MODELLING - (O2)

    I'd suggest the optimums for the visual LODs are roughly: Weapons ~Ideally less than 10k polys (consider that attachments might add a lot of extra polys, and there will be lots of people in a group holding). More than 15k is probably not good. Vehicles ~20-32k polygons for the base vehicle (hull, wheels/tracks, heavy weapon turret, lights, windows/vision blocks, doors/hatches, low-poly version of interior if seen from outside). However it will go upwards of that when adding extra external details like mounted machine guns, bags, fuel cans, spare track sections etc. If say a tank, demands a lot of small external detail parts, it's not unusual for there to be 40k-50k+ triangles, but you're probably never going to see more than 4 tanks at a time up close anyway. Pilot view LODs can be more detailed - certainly for guns you want your sights to be nice and round in the view pilot LOD, but that doesn't matter at all in third person view And with vehicles the pilot LOD interior with modelled switches and dials things and things will have a higher polycount than is necessary from outside. But you can then also save polys by removing parts of the external vehicle that are not visible from inside (wheels, underside of the chassis etc). So workflow would be to create the model as a view Pilot model, and then optimise it accordingly Ultimately though, it's more important to: Reduce the section count (number of texture+material groups shown in Object Builder) Make good resolution LODs (half the polycount for each LOD stage until you're down to 200-400 polys IIRC) Make a good low-poly shadow LOD with no unnecessary detail in it, other than the basic silhouette of the object (shadows are a big, big performance hog)
×