Jump to content
Bohemia Interactive Forums

oukej

Former Developer
 View Profile  See their activity

  • Content Count

    1063

  • Joined

  • Last visited

  • Medals

  • Medals

Everything posted by oukej

  1. oukej
  2. oukej
    This is not intended. Caused by data mismatch. Only one of those actions (Right panel) should be in the Action menu and that only if you don't have it bound to some input. It should be gone again with the next Dev-Branch update. (it can possibly reappear in the following days)
  3. oukej

    Jet DLC?

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

    Ad Dynamic Vehicle loadouts - pls continue in
  4. oukej
    @snoops_213@chortles - forgot to mention - good job on monitoring the wiki ;) Few packets back the HLAD-link (Highly Lethal Automatic Data Link, STARMAG 5302) got silently uplinked to Dev-Branch. The sharing is performed through Side's "center" and individual vehicles can be configured to share their target data, share their own position and/or receive target data from the center. Datalinked targets use hollow symbols. You can try the datalink with Drones (transmit only) and VTOLs (transmit & receive). You can also use script commands for testing it out. As always - wip, may not be final, subject to possible naming and functionality changes. Give us your feedback!
  5. oukej
    Air and GroundTarget classes only relate to the target's background. For LaserSensorComponent you'd probably want to use the same ranges for both.
  6. oukej
    The bug has actually been caused by added salvo feature :)
  7. oukej
    Seems like TGIF in @DnA's Amsterdam office...
  8. oukej
    I'd say it slightly differently. You always need some gameplay goal before you add a feature. You'd always be looking at what the feature brings, what it takes, what is the cost of using it, how it can be countered. We added some game mechanic, created some abstracted simulation. But we underestimated tuning its capabilities to its level of abstraction. The complain about broken balance has been valid, we've got some good feedback and have made some changes that we've believed would improve the balance. It's not because we simply didn't like it. We refuse to add things whenever we can't achieve a result good enough to outweight the effort, maintenance and potential arisen issues.
  9. oukej
    Yes. Balancing != equality or symmetricity. Balancing = archers vs. horsemen vs. pikemen; Tiger vs. Shermans; Abrams vs. T-72s and T-80s; T-72 vs. Toyota Hilux; Ak-47 vs. OICW (uhh:P:D) Caliber, speed, fire rate, armor, maneuverability, ordnance amount, guidance types, ease of use, economy ....or just "configFile" in Arma ;) That is balancing. Lack of balance throws you out of immersion because something is underpowered and frustrating or overpowered and boring. But let's get back to the sensors please :) Unlike the horizontal range the limits of vert. one aren't readable anywhere on any display which may be also the issue. Only inside the fullscreen cam. view. No worries, no plans to change that. We will address that.
  10. oukej
    Oh, c'mon. We're trying to do our best for both PvP and PvE. A CAS airplane that does everything for you isn't fun in PvP (killing you all the time), neither in PvE (completing a combined arms mission on its own), neither for the pilot himself (unless the pilot is just ego trippin - and we ain't gonna support that) and nor it is realistic. I'd say game balance is equally important for everyone.
  11. oukej
    That's where it gets tricky with locality of each actor in MP and also with the way AI marks targets and uses PGMs. The idea has been to have an abstraction of contrast seekers, primitive or imaging. The best example would be Mavericks and their evolution (and experience with IR tracking in desert environment - even though that's something we don't model). I believe image processing is quite common these days (not only IR or multispectral but also just in vis. spectrum). The primary purpose is to have a passive sensor that doesn't require the targets to be heated up. Add another option for balancing. A vis. sensor doesn't need heated targets but it can be set as less capable, may be less effective at picking targets against ground clutter, can be blind at night, can be better against some targets and worse against another (a target can have different "signature" in each spectrum). Keep in mind that the configuration of vanila assets is heavily WIP, random-ish and it's been deliberately early on Dev-Branch. To get your word on how you think it should be set up and balanced ;) Ideally this:
  12. oukej
    ID distance is configurable separately from the sensor's detection range. Contrast seekers, CCDs, EOTS... in vanilla configs atm it's range/angle will usually reflect the vehicle's optics (pilotCamera or the gunner's optics). Pilot camera (TGP) is only able to point lock at something provided by a sensor. The viewDist capping is not a limitation, it's just how they are set up in configs. It's because of the spectrum properties, because of how the sensors are set up to work with optics and also because it's nice to keep BVR reserved to radars as they are the only active sensor and reveal themselves. Check Buzzard - it has the CCIP alrady in HUD. The in-game UI CCIP has been limited to optics. Have u been using Dev-Branch? Semi-active radar guidance has sadly been cut due to complexity. Sorry about that.
  13. oukej
    It is. If the symbols get offset from their world ref. when moving, tilting, swaying head it means the MFD class is badly configured and doesn't use *toView sources. If you see something like that on vanilla aircrafts please let us know! If you see it elsewhere let the mod authors know and you can redirect them to MFD documentation (many thanks to Kitoon for composing it) It is possible for non-vehicular weapons (there's an issue with vehicular ones). In previous Armas the weapons usually used the auto-acquisition. But it was too OP and made it too easy to reveal anything just by looking in its general dir. Back then it wasn't rly possible to restrict that acquisition so we went with making it manual. With sensors and few new lock properties it's no longer the case and we will hopefully start using this approach again :)
  14. oukej
    Such "ruler" can be added to the display - orig. from vehicle icon, straight up - is that what you mean? A C-scope? Is it necessary when targets can be indicated on HUD?
  15. oukej
    IDing targets gameplay was something we tried to emphasize. We've actually got rid of the automatic enemy confirmation. And it works on the display as you're suggesting: With small differences. Allied (green) are only contacts from the same side. Contacts from a friendly side will still be shown white. Red contacts - and this is still just a plan - are only those that have been "confirmed as hostile" by a script command. This is to allow scenario creators come up with either pre-determined scenario setting and ROE or to come up with a dynamic system for confirmation of enemies. Hopefully allowing also this: This is the current state. https://community.bistudio.com/wiki/Arma_3_Targeting#Identification Boxes/brackets are for tgt marking by vehicle systems. Diamond is to indicate missile seeker and its locking state. The nametags are gone from 3D symbols. So...can I mark this as done? ;) We need a fall-back system and also something that works in optics and simple weapons (where HUD/HMD drawing technology can't be used). Having the targeting indication only in HUD/HMD would be an ideal state but we may not have the resources to achieve it. Ours do neither :) Ammo and vehicle systems can work independently. You may have no vehicle sensor at all but you will still be able to lock a target using the missile's own seeker. Vehicle systems may for example let you track the target outside of missile's envelope. It's already available. We may attempt rebalancing the vanilla configuration. If you have a concrete example where the behavior is suboptimal :) please pinpoint us and we'll look at it. You can lock on burning wrecks :) Locking actual flare seems already (and sadly) out of scope. (And afaik the modern missiles don't usually pursue bad tracks...perhaps even the wrecks aren't very accurate) And hey, thanks a lot for your post!
  16. oukej
    Thanks for the report. French localization was updated to also use only the SI symbol. Wonderful! That's a solid feedback and good notes. Thanks a lot!
  17. oukej
    It seems that you're missing several other elements. Strange. What's your resolution and UI size? Can you try resetting the layout preset to default, restarting the game and see if they pop back again?
  18. oukej
    PCML in current configuration is based on NLAW performance. Except of - as u already mentioned - the guidance :) That is abstracted as a vis. sensor (unlike Titan's IR. Mentioning Titan - that one would be closer to Javelin). We don't have the tech to simulate PLOS.
  19. oukej
    :D Incorrect reporting of friendly medics. We may try to take different approach.
  20. oukej
    I'm sorry. We acknowledge the need of it but it's not planned.
  21. oukej
    Correct. The PCML ammo is the first to use a sensor component and also to utilize some of the other new properties for limiting lock angles, range and speed. To work well all in all the missile performance has been slightly tweaked as well.
  22. oukej
    For now you can use COMBAT mode (either in group attributes in editor or by setBehaviour) - that will make the AI use the Radar. A note - you're only able to detect a radar if you're positioned within that radar's scan sector and within max. 2x that radar's range.
  23. oukej

    Targeting improvements

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

    And that's exactly what we've just tried to do :) There was a specific issue. There were some proposed solutions. We didn't think that adding a script control is a good way to solve it. Not because of some script vs. config dogma...dogmas are for puppies ;) I don't think we'd hesitate to add script command whenever it can add convincingly good and useful option to scenario creation and whenever we can. Add meaningful options. Not solve (patch-around) issues.
  24. oukej
    Will try to improve that. Good idea :) Nope, that's a bug :) Try this for the missile: (with comments) class Components: Components { class SensorsManagerComponent { class Components { class ShrikePassiveRadarSensorComponent { componentType = "PassiveRadarSensorComponent"; //ESM, only track radar emitters class AirTarget // ranges for targets with sky background { minRange = 5000; //irrelevant - range not limited by view distance maxRange = 5000; objectDistanceLimitCoef = -1; //range not limited obj. view distance viewDistanceLimitCoef = -1; //range not limited by view distance }; class GroundTarget // ranges for targets with ground background - background/reflections play a different role in ESM. I'd just ignore it and set it the same. You may also want to set it higher than 5km to fully utilize the ability to detect sources at 2x the range of their own radar. { minRange = 5000; maxRange = 5000; objectDistanceLimitCoef = -1; viewDistanceLimitCoef = -1; }; angleRangeHorizontal = 60; angleRangeVertical = 60; groundNoiseDistanceCoef = -1; // I wouldn't use this for ESM. Flying low shouldn't hide a target if it has an active radar. maxGroundNoiseDistance = -1; // Same as above minSpeedThreshold = 0; // Same as above maxSpeedThreshold = 0; // Same as above minTrackableSpeed = -1e10; maxTrackableSpeed = 1e10; minTrackableATL = -1e10; maxTrackableATL = 1e10; animDirection = ""; aimDown = 0; // You had 90 - that would mean the missile's sensor would be looking straight down in 60deg cone. That would make it nearly impossibly to lock anything without flying right above it. }; } }; }; In the vehicle's config you have a typo - SensorsManagementComponent instead of SensorsManagerComponent
  25. oukej
    In compatibility/legacy mode, when the vehicle doesn't have a Custom Info component defined, the default is chosen according to radarType property. If there used to be a radar previously the default will include Sensors Display. The fix has been that radarType = 8 (compass) default no longer includes Sensor display
×