suddenlymoose

Thank you, I thought I had found all the relevant radar functions, but the splendid engineers at Bohemia had already apparently added the functionality I was looking for. Too bad if it is not working 100% correctly, but working around any problems in listRemoteTargets will hopefully be simpler than trying to reimplement that functionality.

Scripting functions for sensor data that it would be convenient to have, that I could not find any good way to do now: o Function to list all sensors on a vehicle (maybe with some sensor stats such as range) o Function to list all targets detected by a vehicle sensor, with known information (speed/type/etc.) Alternative, simpler variant: o Function to list all sensor data currently shared via side data link I was able I think to estimate this information by iterating over vehicles array and filtering with configfile to identify vehicles with data link and their range, and then iterating over nearEntities with knowsAbout to check if each vehicle in sensor range is known, but this is a costly way to attempt to calculate information that must already be known by engine. A simple function or two to expand the API would be nice.

Presenting the Bratwurst Mark 1 weapon system. "A mobile SAM system produced by the Erfurt based defense company Lederhosen undt Waffen GmbH. The Mark 1 was introduced in 2022." http://www.armaholic.com/datas/users/bratwurst1_4.jpg (694 kB) http://www.armaholic.com/datas/users/bratwurst2_4.jpg (709 kB) http://www.armaholic.com/datas/users/bratwurst3_4.jpg (414 kB) This is a config that uses the base game MBT_01_mlrs_base_F model as an AA unit. This is not an attempt to recreate an actual system, but to add an AA unit that can use the relevant features available in the Arma 3 engine. The following classes are available: "M1 Bratwurst AA Passive" "B_Bratwurst_passive_F" - Blufor variant "O_Bratwurst_passive_F" - Opfor variant Mark 1 AA using only passive radar and locking. "M1 Bratwurst AA Active": "B_Bratwurst_mark1_F" - Blufor variant "O_Bratwurst_mark1_F" - Opfor variant Mark 1 AA using a narrow active radar and active radar missiles locking. "M1 Bratwurst Passive Radar" "B_Bratwurst_radar_F" - Blufor variant "O_Bratwurst_radar_F" - Opfor variant Radar unit providing radar information via Data Link to other units. Uses only passive radar. "M1 Bratwurst Active Radar" "B_Bratwurst_radar2_F" - Blufor variant "O_Bratwurst_radar2_F" - Opfor variant Radar unit providing radar information via Data Link to other units. Uses also active radar. "M1 Bratwurst AA Active" (decoy) "B_Bratwurst_decoy_F" - Blufor variant "O_Bratwurst_decoy_F" - Opfor variant Decoy unit. Does not have any firing capacity and only limited armor, and can easily be mistaken for a real M1 Bratwurst AA Active. The AA units supports the following ammo: "12Rnd_DijonPenetrator0" - Manual (control via mouse, camera available) "12Rnd_DijonPenetrator1" - Visual lock "12Rnd_DijonPenetrator2" - IR lock "12Rnd_DijonPenetrator4" - Laser lock "12Rnd_DijonPenetrator8" - Active Radar lock (default on M1 Active) "12Rnd_DijonPenetrator8b" - Passive Radar lock (default on M1 Passive) "12Rnd_DijonPenetrator9" - Data Link lock The Active and Passive Radar lock ammo variants also have Data Link sensors. The ammo variants come from the mechanisms supported by the engine. No scripting is used. Small file size. Example command for loading ammo: bratwurst1 addMagazineTurret["12Rnd_DijonPenetrator1", [0]]; Notes: -The AA unit has no laser and needs an external unit to provide this when using laser lock ammo. -Turret dynamic loadout support not possible (engine limitation). Credits: Model/MLRS config by Bohemia Interactive. Current version: 2.1 Download: http://www.armaholic.com/page.php?id=25474 (Armaholic) http://withsix.com/p/Arma-3/mods/ui8z5cDK4xGiuQAVF72WTA/Bratwurst-Mark-1-AA (withSIX) https://steamcommunity.com/sharedfiles/filedetails/?id=927098963 (Steam workshop) Changelog: Version 2.1 -Support for new Arma Data Link functionality in Arma 1.72, making Radar Units more useful. It is now possible to lock units that are inside the sensor range of a radar unit, as long as it is also in line of sight from the AA unit. -Added "M1 Bratwurst AA Passive", a passive sensor AA unit variant. -Added "12Rnd_DijonPenetrator9", ammo with only Data Link sensor. Version 2.0 -Metadata fix. -Now also available on Steam. 2.0 beta 1 -Updated config to Arma 3 changes since last release: -Support for Eden/Zeus (icons/category/etc.) -Support for Virtual Garage (included only, no interactivity) -Added meta data (logos/images/etc.) -Added "Decoy" AA variants that look like the Bratwurst but have no actual firing capacity and are easy to destroy. Placed under new "Decoys" subsection in editor. -Various updates to use new Jet DLC targeting/sensor system, including: -Bratwurst AA unit has receiveRemoteTargets set. -Various Sensors added. -Added two "Radar" units that have "reportRemoteTargets" set. Can provide targeting information to AA unit, but of limited use since this information can not be used for locking. Same model reused, but with turret in a fixed position. One unit with passive radar and one with active radar. -Various minor changes, including: -Camera available for manual targeting ammo (12Rnd_DijonPenetrator0). -Manual targeting for 12Rnd_DijonPenetrator0 now done fully with mouse. 1.0 -Added bisign file. 1.0 beta 2 -Some corrections to class names. -Set short non-zero reload time to avoid overlapping fire. -Only preloaded with 12Rnd_DijonPenetrator8. 1.0 beta 1: -First release.

Version 2.1 now available from Steam Workshop: Version 2.1: -Support for new Arma Data Link functionality in Arma 1.72, making Radar Units more useful. It is now possible to lock units that are inside the sensor range of a radar unit, as long as it is also in line of sight from the AA unit. -Added "M1 Bratwurst AA Passive", a passive sensor AA unit variant. -Added "12Rnd_DijonPenetrator9", ammo with only Data Link sensor.

Yes, it only starts locking when there is line of sight. Might be a config problem somewhere else, but that is the behavior I am seeing now. In spite of this the AA becomes very effective when data link is used. The AI it knows the target is there and starts locking at once it becomes visible.

Thank you for the video link. I have done some similar testing with the Bratwurst on the dev branch, adding support for the Data Link sensor (not released). It appears to work when the target is in sight, but unfortunately not when it is obscured by terrain. That is, targeting sort of works, giving a square with interrupted lines, but it will not lock.

Thanks for the comments. Version 2.0 now available (only Steam version updated at the moment, new Armaholic version submitted but not updated yet). Version 2.0 -Metadata fix. -Now also available on Steam Workshop.

Version 2.0 beta 1 now available, see first post for download information. Requires Jet DLC functionality, so either devel or RC branch until Jet DLC is released. Several new additions using new sensor system. Tested in single player. Expected to work also in multiplayer, but do not know how useful or practical the new MOD functionality is. Comments and feedback welcomed from anyone trying it out. Version 2.0 will be released also on Steam. Changelog: 2.0 beta 1 -Updated config to Arma 3 changes since last release: -Support for Eden/Zeus (icons/category/etc.) -Support for Virtual Garage (included only, no interactivity) -Added meta data (logos/images/etc.) -Added "Decoy" AA variants that look like the Bratwurst but have no actual firing capacity and are easy to destroy. Placed under new "Decoys" subsection in editor. -Various updates to use new Jet DLC targeting/sensor system, including: -Bratwurst AA unit has receiveRemoteTargets set. -Various Sensors added. -Added two "Radar" units that have "reportRemoteTargets" set. Can provide targeting information to AA unit, but of limited use since this information can not be used for locking. Same model reused, but with turret in a fixed position. One unit with passive radar and one with active radar. -Various minor changes, including: -Camera available for manual targeting ammo (12Rnd_DijonPenetrator0). -Manual targeting for 12Rnd_DijonPenetrator0 now done fully with mouse.

Great work on the carrier. Should be excellent for air deployments. The back of the carrier also seems fine for deployments by small boats. A suggestion: adding some extra climbable ladders between the different platforms at the rear of the carrier would make it even better for deployments by sea. The lowest platform can be used to board small boats, but it is very small and unfortunately not connected to any of the platforms above.

Really liking new sensors system, and I have been testing the datalink functionality: Vehicle A: Has reportRemoteTargets set. Vehicle B: Has receiveRemoteTargets set. Vehicle C: Is in sensor range of A and not in line of sight from B. Vehicle A senses C and reports it to B, resulting in radar of vehicle B showing vehicle C (does not do this without data from A). Is there a way to lock and fire on C from B, using the target information from A? I did some experimentation, but could not target C from B in any way.

There is still a problem with some cargo container models. Can be seen in the Blue Harbour area, where shots appear to hit an invisible wall when shooting around the corner of the cargo containers there.

I think there are two central points regarding gating of DLC content that bear repeating and that I feel essentially limit how gating can be done without being harmful: -Blocking or limiting single-player content, including in the editor, should not be problematic or controversial. -Limitations on non-cosmetic multi-player content lowers the value of the content, making it less attractive to purchase and use. The second point has been made several times already in this thread, but both actual limitations on usage, such as piloting being limited to users that own the content, pop-ups for users without the content, or reduced asset quality, make it less interesting to use DLC assets in a mission. Why spend lots of time making a mission if it won't look good and be fully enjoyable for all players? Whatever the limitations, unless it is known that all players will have a DLC, using DLC content becomes less attractive. Why purchase multi-player content that is only rarely used in multi-player missions? I am not saying that DLC content will not be used, but that it will likely be used less than the core Arma 3 content, which is the opposite of what one wants for something that it is necessary to pay extra for. Limiting access to single-user content should however not cause any problems or controversy and still provides ample opportunity for adding content that it would be attractive to purchase. An approach based on limiting single-player content makes it necessary for any DLC to contain a significant portion that is single-player only, but adding single-player content that includes assets that are usable also in multi-player to the base game should not be difficult, or negative. Better to embrace the limitations that exist with a sand-box game such as Arma and build on the strenghts. An approach that I think would work well for Arma 3 DLCs has also already essentially been used by Bohemia. The campaign was released in parts and contained both single-player content and new vehicles and other assets that were usable also in multi-player. This can be done also for new DLC content: single-player content is added that requires purchase of the DLC to access fully, while all new assets are available in multi-player for all users without any limitations. If additional limitations are wanted, limiting the use of DLC assets in the editor unless the DLC has been purchased is one possibility (for example by having the DLC assets only usable in the editor for a certain number of hours/days). An argument against gating of only single-player content might be that groups of players that only play the multi-player portion of the game would purchase no copies, or at most one copy of the DLC (if there were limitations on use in the editor/server), but better to make the single-player portion sufficiently attractive that also users that would normally not be interested in single-player content are tempted to purchase the DLC. Single player content has and will always have value, regardless of how many others have purchased it, while multi-player DLC content only has value as long as other user have bought and are using the DLC. Both of the two new announced DLCs should also be well suited for having training drills and similar that should be of interest also to players that primarily want to use the DLC vehicles and weapons in the multi-player. Good practice missions and weapon drills can be used just as well by players that primarly play coop or multi-player. Structuring the single-player content added in a DLC in a way that implementing it requires engine extensions that also improve the multi-player functionality should not be difficult either. By primarily placing the paid DLC limitations on single-player content, there should be no negative effects from having content that is locked, and assets added to the base game as part of the DLC development would make the multi-player more attractive, potentially increasing sales of the base game, and with it, the number of possible DLC customers.

First post updated, version 1.0 now available. Big thanks for the feedback and to everyone that tested.

Hello, I have a question regarding the use of remoteControl and PiP. I am basically hoping to use remoteControl along with an independent camera visible via PiP (currently using BIS_fnc_PNP). I am testing this in the editor with a man and a manned helicopter (heli1) and the following code: cam1 = "camera" camCreate (position player); cam1 attachTo [heli1, [0,1,0.5]]; livefeed = ["rendertarget0", cam1, player] call BIS_fnc_PIP; player remoteControl driver heli1; This gives a small window with a view from inside the cockpit, and in some situations it is possible to partly control the helicopter. This appears to largely work when the player is close to heli1, resulting in control being lost when the helicopter gets some distance away from the player. Some actions (such as Collective lower) appear to work more consistently even when the other controls stop working. What I am essentially wondering about is if this is something that should be working. As it almost works now it would be very nice if it was only a (fixable) bug that prevents it from working fully. With switchCamera, controlling heli1 works, but I ideally want to avoid using this function in order to have more control of the camera.

Hello, I needed an anti-air unit so I created a config that uses the MLRS model. The config is included below. The status of the config is that all the pieces for using the unit appear to be in place, and I have attempted to identify the relevant variables, but no significant tweaking has been done, so if someone has any suggestions as to any specific parameters they would like to see, please let me know. Current plans for this config is to add a set of different missile types with parameters for relevant usages, based on what is supported by the engine. I will likely also make a "Mark 2" unit that has some additional scripted functionality (radar etc.). This is my first attempt at putting together a config file so comments are welcome. //Class Bratwurst : config.bin{ class DefaultEventhandlers; class CfgPatches { class Bratwurst_mark1 { units[] = {"B_MBT_01_cannon_F","O_Slammer_M2A1","IA_Slammer_M2A1","B_MBT_01_arty_F","O_Scorcher_M4","IA_Scorcher_M4","B_MBT_01_mlrs_F","IA_M5_MLRS","12Rnd_DionPenetrator1"}; weapons[] = {}; requiredVersion = 0.1; requiredAddons[] = {"A3_Armor_F", "A3_Weapons_F_beta"}; }; }; class SlotInfo; class CowsSlot; class Mode_SemiAuto; class Mode_Burst; class Mode_FullAuto; class CfgAmmo { class BulletBase; class MissileBase; class ShellBase; class M_Zephyr; class DionPenetrator1: M_Zephyr { airLock = 2; irLock = 1; timeToLive = 5; airFriction = 0.026; sideAirFriction = 0.003; maxSpeed = 850; initTime = 0.25; thrustTime = 2.5; laserLock = 1; cmImunity = 0.9; thrust = 385; trackLead = 1; trackOversteer = 1; fuseDistance = 50; hit = 5000; indirectHit = 1850; indirectHitRange = 20; maxControlRange = 8000; // weaponLockSystem = "2 + 8 + 16"; weaponLockSystem = "1 + 2 + 8"; }; }; class CfgMagazines { class Default; class CA_Magazine; class VehicleMagazine; class 12Rnd_DionPenetrator1: VehicleMagazine { scope = 2; displayName = "Dion Anti Air"; displaynameShort = "Dion AA"; descriptionShort = "Dion anti air missile magazine"; ammo= "DionPenetrator1"; count = 12; initSpeed = 40; maxLeadSpeed = 320; type = "6 * 256"; mass = 40; sound[] = {"A3\sounds_f\dummysound",31.622776,1,1100}; soundFly[] = {"A3\sounds_f\dummysound",1.0,1.1,700}; soundHit[] = {"A3\sounds_f\dummysound",15.848933,1,2000}; reloadSound[] = {"A3\sounds_f\dummysound",0.00031622776,1,20}; nameSound = "missiles"; }; }; class cfgWeapons { class LauncherCore; class MissileLauncher; class missiles_titan; class dionmissile : missiles_titan { scope = 2; magazines[] = {"12Rnd_DionPenetrator1"}; minRange = 100; minRangeProbab = 0.8; midRange = 100; midRangeProbab = 0.9; maxRange = 4000; maxRangeProbab = 0.9; reloadTime = 0; magazineReloadTime = 6; sound[] = {"A3\Sounds_F\weapons\Rockets\titan_4",1.4125376,1,1100}; soundFly[] = {"A3\Sounds_F\weapons\Rockets\rocket_fly_1",1.0,1.1,700}; lockingTargetSound[] = {"\A3\Sounds_F\weapons\Rockets\locked_1",0.17782794,1}; lockedTargetSound[] = {"\A3\Sounds_F\weapons\Rockets\locked_3",0.17782794,2.5}; weaponSoundEffect = "DefaultRifle"; canLock = 2; autoFire = 0; //automatic fire (e.g., machine gun) autoReload = 1; // better: 0? must be done manually autoAimEnabled = 1; ballisticsComputer = 1; aiRateOfFireDistance = 1000; aiRateOfFire = 10; weaponLockDelay = 1; textureType = "semi"; }; }; class WeaponFireGun; class WeaponCloudsGun; class WeaponFireMGun; class WeaponCloudsMGun; class RCWSOptics; class CfgVehicles { class LandVehicle; class Tank: LandVehicle { class NewTurret; class Sounds; class HitPoints; }; class Tank_F: Tank { class Turrets { class MainTurret: NewTurret { class Turrets { class CommanderOptics; }; }; }; class AnimationSources; class ViewPilot; class ViewOptics; class ViewCargo; class HeadLimits; class HitPoints: HitPoints { class HitHull; class HitEngine; class HitLTrack; class HitRTrack; }; class Sounds: Sounds { class Engine; class Movement; }; }; class MBT_01_base_F: Tank_F { class Turrets: Turrets { class MainTurret: MainTurret { class Turrets: Turrets { class CommanderOptics; }; class OpticsIn { class Wide; class Medium; class Narrow; }; class HitPoints; }; }; }; class MBT_01_mlrs_base_F: MBT_01_base_F { class Turrets: Turrets { class MainTurret: MainTurret { class Turrets; class OpticsIn { class Wide; class Medium; class Narrow; }; }; }; }; class Bratwurst_mark1: MBT_01_mlrs_base_F { author = "$STR_A3_Bohemia_Interactive"; _generalMacro = "Bratwurst_mark1"; displayName = "Mark 1 Bratwurst"; class Library { libTextDesc = "The Bratwurst Mark 1 SAM system."; }; crew = "B_crew_F"; side = 1; scope = 2; faction = "BLU_F"; class AnimationSources: AnimationSources { class Missiles_revolving { source = "revolving"; weapon = "dionmissile"; }; }; artilleryScanner = 0; radarType = 4; class Turrets: Turrets { class MainTurret: MainTurret { minElev = -10; maxElev = 80; initElev = 5; weapons[] = {"dionmissile"}; magazines[] = {"12Rnd_DionPenetrator1"}; class OpticsIn: OpticsIn { class Wide: Wide { gunnerOpticsModel = "\A3\weapons_f\reticle\Optics_Gunner_02_F"; turretInfoType = "RscWeaponRangeZeroing"; discreteDistance[] = {100,200,300,400,500,600,700,800,900,1000,1100,1200,1300,1400,1500}; discreteDistanceInitIndex = 2; initFov = 0.174; minFov = 0.0077778; maxFov = 0.14; visionMode[] = {"Normal","NVG","TI"}; thermalMode[] = {0,1}; }; }; class Turrets{}; }; }; }; }; //};

Thank you for the tip, now posted in complete section.

Thank you for your comments. The unit uses missiles, which are handled by the engine. The gunner locks onto an air unit and fires. The rest is then handled by the engine automatically, without any scripting. I will likely distribute it as an addon, but will need to arrange a place to distribute it from first.

Ah, yes, that seems logical. Do you know how the engine treats the data after it has been loaded? If there is any difference in how it is stored in memory, simulated, etc., that has an impact on performance?

On a related note, is there a corresponding difference for deletion of objects; i.e., with using a map with fewer objects/buildings, compared to actively removing unwanted objects at mission startup?

With regards to performance, is there any practical difference at runtime between dynamically adding objects/buildings etc. to a map as part of mission initialization, and modifying the map to have the same objects permanently added? In other words, do the two alternatives result in different behavior once everything is up and running?