janh

I must say that I am a bit disappoint by the choice to move entirely over to steam. I have been very happy with the disc and DRM being patched a while later. And I am a bit afraid that this decision may ruin the franchise. Other big publishers have ruined their franchise with that, especially if it was a niche or at least not a big selling title anyways. One major reason I was loyal to BIS and kept buying products of the OFP/ARMA series was that they thus far had followed a more reasonable line with their DRM policy and kept it less intrusive, less hand-binding than other publishers did. In fact I passed on a number of titles from these other publishers within the last couple of years because of online activation or online-to-play requirements. Titles, which under different circumstances I would have bought. So far I bought no title with online-disadvantages since the improvements and innovations of the titles would have to be so markedly big that I would feel compelled to buy. Not just graphics polishing, and a few features, but major changes. For one, I do not have a reliable internet-connection at home, and since I don't want to spent another $10-20 or Euro 10-20 per month investing in a better tarif with open data-flat etc. I just don't need it otherwise, and as a paying customer, perhaps of an older generation used to be treated by the maxime "the customer is king", I still expect to get a solid product for solid funds. One that I can use without internet, if I am single player anyway. If a company would put a 5 year check for the additional internet fees in the box, I might be convinced, but an economic consideration renders buying a $60 game for am additional $120 internet service fees per years a questionable thing. I still might buy the game if the innovations are sufficient to justify it, but I won't be happy about steam. It clearly is a big minus when making the decision. Maybe I'll wait and see whether they'll patch it and sell a steam-free budget version later. I hope they will reconsider. So far I have held BIS high for putting their customers first. Their service, and listening to customer wishes, patching etc. was so far excellent. But this one is a bit of a disappointment, sorry to say.

There is one more problem I ran into a couple of times, which I had to solve "inelegantly": - not only "iskindof" (stated in wiki) but also "Counttype" (not stated) do obviously only work on classes in CfgAmmo and CfgVehicles. Right? At least I have issues to get scripts to test whether "M16" iskindof "Rifle" or such with both commands. One can script a looped function that checks "inheritsfrom" for the tree of objects in CfgMagazines and CfgWeapons, but this probably adds unnecessary load/overhead compared to a hardcoded function, as usual I guess. It would be nice if both commands could be extended to the CfgMagazines and CfgWeapons in a patch or ARMA3, though. But does anyone know of an "efficient" function as an alternative? - Does anyone know of a function that can CHECK for "connected water areas" or "water routes" between connected points, perhaps given a water under keel threshold? Something similar to the BIS "plotroute" function for tracing routes along road networks? The latter is pretty elegant, though for many user-made maps it seems to fail since road networks are not properly connected/defined, are too scarce (often with Vietnam type maps) or do not allow for many interconnecting loops (or sometimes roads with barriers at the sides, or twin lanes with barriers in center cause AI routing issues later -- e.g. on Fallujah's highways). With some larger changes, this function works like a charm, though. I tried to devise a similar function for boats around deep water, or along rivers, but even considering water depth, gradient and such it is either vastly inefficient, or often fails to find connections to inland water ways. Does anyone know of a working, efficient script for this problem?

Hi guys, I am have accumulated several questions working for month on various problems, and cannot find satisfying answers here or on the other modding forums (Devheaven etc). Some things may be depreciated commands that do not work with ARMA2 anymore, others may be bugs, or just not intended to work as such. Any help sorting this out, or advising me of "efficient" scripting alternatives is much appreciated: - forcespeed: doesn't seem to work with ARMA2 anymore? Is it due to the recent beta patches? Is it a bug? This would be an extremely useful command for all class vehicles! - limitspeed: seems that it has to be looped continuously, else the unit will return to its old speed? And the loop delay must be short else the unit will be hopping like a rabbit? A bug? Any alternative but to have to use another thread to get a unit to limit/force its speed? Given the scheduled and non-scheduled environments, I could add an FSM to do so, but with SLX_Wounds, ACE, ACRE, MMA etc. the scripting load is already pretty high. I would leave more resources for my own scripts if possible... Ideas? - fireAtTarget: Is this intended for vehicle turrets only? I cannot get to work on class Man. Bug? Not intended? Workaround? This would also be a useful to avoid the lookat, selectweapon, fire or action[] sequence by a single command. - Is there any command like the "say" that allows to broadcast a text to adjacent players/man (within a defined/custom radius)? - Dead "Man class" objects: It appears that dying soldiers etc. forget name, side, group and ALL variables attached to them via "setvariable". This looks like a bug to me? It would be most desirable if setvariables could remain stored since that would make storing much information indirectly passed between scripts (like dragger, dragger "called/approaching", healing, actionIDs etc.) a lot easier. For the side and faction associations one can always check "getNumber (configFile>>"CfgVehicles">>typeof _dead>>"side")", and reassociate with the "SIDE" or "WFSideText", but it causes unnecessary scripting overhead in my opinion. Also looks like unintended functionality, or has this been like this since ARMA2 release? Do you know any workaround aside from storing things in global variables/arrays or in the group namespace? Many thanks for any answers! Stranger

Awesome! Looking forward to this! I hope you can keep it so simple yet efficient in scripting load so that I can use it later with my OPFORPLANNER suite and just place a carrier on map with planes onboard so that AI will be able to do the shuffling about on its own, launch and recover as needed! I suppose there is no "LAND" Eventhandler that you can intercept for redirecting landing planes automatically to the CVN? Good Luck with this project!

I have a question regarding "ACE_sys_explosions", i.e. the use of satchels etc. Seems I can't order AI anymore to place charges. How can I get AI to use the new ordnance?

I have been looking for a description of several of the "new" OA config entries, namely lockDetectionSystem, incommingMisslieDetectionSystem, radarType, weaponLockSystem. Seems they have been added to the BIS Wiki, but no explanation is given. Have you guys ever found out, what the parameters do in detail? Does OA now differentiate between different guidance modes, i.e. optical, wire/radio, IR, radar (mmW, etc), UV? (weaponLockSystem?) Is there a proper differentiation between the types of countermeasures now (flares, chaff, ecm)? And a proper sensor differentiation in vehicles? Or were these values just added for compatibility with the forthcoming title? If so, I might try to add those to the GLT weapon packs, and to retrofit it into MMA to safe some scripting overhead by using engine functionality instead. In A3, I hope they will put some focus on planes, helicopters, and armor/apc simulation, which compared to the infantry part still seems quite crude. Aside from CQB in buildings, the latter is very good already, but I find the disbalance is becoming limiting factor overall. I hope they add the interactive cockpits from ToH to all vehicles in A3.

Hi guys, I got a brief question regarding addons of 3rd parties: Are there Addons/Config upgrades available in particular for all the various great Plane and Helicopter addons to adjust their parameters and properties (speed, armor, fuel, weapons parameter etc) to a consistent system, preferable based off ACE & GLT? Is there perhaps a project or group dealing with this? Unfortunately a lot of addons use their own standards, for example the brilliant RKT-F15 addon by Footmuch does have the Mk82 or GBU-12 defined with hit-values very different from the GLT_Missilebox (or ACE), or stock parameters. In some addon cases it looks like a light AA-missile like the Sidewinder or Aphid carries a greater explosive load than in other addons a 500lb bomb does!!! Or some "unarmored" fighter planes have been given better armor than the A-10!! That of course put all realism off. I noticed that the MAR addons (F/A-18 or the Marine Infantry) is nicely made consistent with ACE and GLT, which means that performance differences are more realistically meaningful. Moreover, having only a few sets of consistently defined weapons (GLT_Misslebox, ACE, and stock) does all lower the performance need for having many configs loaded and processed in-game. Ideally, there would only be one set with all included, say GLT incoporated in ACE. Before going thru the pains of editing all these addons, from the F-15, F-14s, F4s, Su-33, and and and many more, does anyone know of a project that adjusts all the vehicle, and perhaps replaces air weapons with the GLT types? Like for example for the Robert-Hammer (RH) Weaponpacks has been adjusted to ACE standards? I would personally find this very important as it would save a lot of time reediting all the configs for adjusting to ACE/GLT realism. Thanks, Jan

In addition to what has been mentioned on this list already, these could be useful (just crude ideas, specific implementation and return values would need to be considered) * _unit getImpactAngle _shot => [vert angle to normal of the hitpart, horz angle to normal, [xyz vector of the shot on impact]] * _unit getImpactSpeed _shot => [speed of round on impact] * _unit canhear _enemy => float 0,...1 * _unit cansee _enemy => float 0,...1 * {pos/Object} hasfreevisualtrajectory {pos/Object} => bool * [{pos/Object}, _weapon, _mag, _muzzle] hasfreeballistictrajectory {pos/Object} => bool The latter could also return => float 0,...1 if one would calculate penetration for the ammo type an potential surfaces crossed. * _pos in visualsector _unit => bool (to test visual field) * Eventhandler : "detectsfired" => [_unitthatfired, direction, estimatedistance, {with "ears", "eyes", "both"}] * Eventhandler : "spotted" => [_unit, _enemy, knowabout or so] * Eventhandler : "flarelaunched" => [_unit,] * Eventhandler : "chafflaunched" => [_unit] * Eventhandler : "ecmlaunched" => [_unit] * Eventhandler : "weaponitemdropped" => [_unit,_item] * Eventhandler : "weaponitemgrabbed" => [_unit,_item] + make FindHidePos work again (FindHidePos [pos/object, range, min height/size of cover, max height/size of cover, or object type] + implement aimedAtTarget also for "Man" class objects very important I would find: allow setvariables to work on dead "Man" type objects, i.e. don't let them loose the stored info.

THX! Interesting thread -- that confirms it. So they probably didn't do it because of the locality change? Anyway, it would be very very useful it the units would keep their variablepace. Need to figure a workaround now without spawning an sqf for any unit, or creating tons of extra objects, which both would be really detrimental to the script execution performance.

It is primarily a problem for attaching and removing actions dynamically to dead bodies (like storing the index of an attached "Carry" action for later removal when unit is picked up, and then replacing it by a "Drop" action and vice versa). Was thinking about storing that in the group namespace instead, but then I can't disjoin them anymore. Using HeliHEmpty or a Gamelogic for each dead might work, but it would add a huge overhead and cause wasteful CPU usage if you have big missions with a couple of dozen or hundred bodies on the ground after a while. Sounds like keeping the variables on dead objects would be less resource-intense.

I got a quick question on the setvariable / getvariable commands when executed on local objects. (I am using ARMA2_OA_Build_84689) If I store some info with setvariable on an object of class "Man" (e.g. _unit setvariabe ["Name",name _unit, true], I can retrieve this info as long as the _unit is alive. Yet if the soldier dies, the stored information is lost. Further, I cannot store any info on a dead "Man" type object, it seems. Isnil{_unit getvariable "whatever"} will always return True. This a real drawback for scripting dynamic things, like attaching and removing specific EH's or actions, or a lot of other stuff specific to that dead unit. Is that a bug that ought to be reported? I do not recall running into scripting issues with that in any of the previous beta patches. Otherwise, does anyone know of a suitable workaround?

Hi everyone, I spent some time to screen through the threads, but didn't find all the answers I was looking for. Maybe you (or ideally the devs) can answer these questions? - ARMA 3 will include he improved Helo flight model of TOH. Will also the new interactive cockpits be available, with more instruments, MFDs etc? - Will similar improvements be added for fixed wing platforms? Including g-effects etc? - Will realistic, separate sensors (Radar, IR, Lasers etc) be implemented on planes/helos, that are jammed only by appropriate countermeasures (Flares, Chaff, or electronic countermeasures)? Are influenced by weather conditions (IR and IR-freq Lasers by rain/cloud conditions etc)? Or will the aerial platforms keep their "mystic radar"? - Will we get cockpits for AFVs back? - Will ARMA3 feature "digging", i.e. fox holes, trenches, impact craters? - Will AI in buildings learn to shoot through windows, or remain target puppies? - The "modify weapon on-the-fly" addition sounds neat. Will we finally also be able to change weapon loadouts on plane's pylons dynamically? - Will the VBS eventhandlers that also gives the impact angle of ammo be implemented for vehicles, and a more detailed "damage part" model, such as to allow a more realistic penetration calculation? - Will AI be able to select the different ammo types (say the variety of tank rounds from APFSDS to MPAT) better? - Will moving in vehicles during operation (walking in choppers, sniping from them, etc) be added? Thanks for any answer!

Yes, an improved wound-system would definitely rank high on my wishes for ARMA3. Especially if it came with an appropriate AI that would also move wounded to safety, and later extract them by any vehicle back to a real on-map base. However, both SLX and ACE have neat wounded modules that almost suffice. I think this is something the community can rather do by scripting, and would wish the devs to concentrate on things we cannot achieve without hardcoding ability (such as improved flight models, interactive cockpits, improved vehicle damage and armor models, digging holes and trenches etc.)

I don't think there is a too much of realism, in fact I value realism far higher than graphics quality or alike (unless it again interferes with realism). Realism can, however, outgrow into micromanagement. Though also have control over minor details is desirable for realism fans, a "game" would best include this more as optional choice to be enabled by the realism settings. This is done in ARMA2 already with a number of things. Players that go for example through the pains of performing proper aiming procedures with their reticle get the benefit of more realistic experience, and higher hit rate -- others just enjoy the fun of spraying. My opinion is that the infantry part of this simulation has reached excellent levels (aside from CQB), but now one starts to feel that the vehicle simulation (air, naval, land) lacks, as well as other things like the damage model and hit effect approximations (specific roles of heat, solid shot, etc as tried to implement later with ACE2, for example). I think there is still a lot of potential in approaching a level of detail as found in Steel Beasts 2, Jane's Apache Longbow or Falcon 4. Also this could be done at customizable levels, including one for hard-core sim fans, and a simplified one for casual gamers.

It seems like some (only some) aircraft should have the capability to use laser targeting and marking equipement such as the LANTRIN pods as pylon mounted loads. Just as it is realistic. ACE, for example, has realized the laser marking from helicopter gunships in an easy to use, efficiently implemented (low CPU load) system. I don't know about the latest ACE2 1.6, but I could imagine those guys have already done a similar feat to simulate targeting pods on fixed-wing airframes. If not, this would be surely one good suggestion. Post WW2 airplanes should definitely get CCIP and CCRP systems in ARMA2, ideally from vanilla rather than addons. Though CCIP and CCRP systems used until the introduction of phased-array radar both were still rather inaccurate even to dumb-bombing controls today (image the computer would not accurately measured the change in terrain altitude and catch according errors), and still be dependent on the pilot, I find those would be very crucial ingredients for the flight-sim part of ARMA2. Hopefully ARMA3 will make headway with the flight, armor and naval sim parts, but before some addon will cure this need.