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.

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?

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.

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.

Steakslim, I just realized that I misread your statement. Indeed bullet trajectories are altered by passing through glass -- I didn't even realize that until a while ago. I am truly impressed at the level of detail have come true with this game engine. It may still have development potential, but it has truly come very far since the days of already amazing OFP. Maybe I just missed it as well, but if not: BIS should advertise such intricacies more! Really great work!

I think one major problem for CQB fighting and fighting in urban environments is the lack of AI to use buildings as firing positions since AI cannot shoot through windows like a human player. I think one workaround could be removing the windows in all accessible houses, so there is just an open frame in the models. With this, houses and fighting in towns might get much more realistic. Would be great if someone would be interested in this and take care of the vanilla buildings in Utes and Chenaurus. That would add a great lot to the AI capabilities.

And encrypting won't win you anything either. Will only be a matter of time until a new tool will be made to circumvent it. Until then, it will only slow the game since decrypting upon loading would add only to the CPU load during playing, especially for complex models. Great idea... Again, as Maruk said: Solve the root of the problem, i.e. teach respect for modders using other peoples content. Fighting the symptoms is a lost fight. Myke, I like your work, but encrypted I would not be interested anymore -- that would be a dead end for the modding scene, quite surely. I really don't see what fame you guys wan't to make with encrypting your stuff. It will not benefit anyone. Unless you want to make money with your addons, which I doubt will work well -- especially with BIS DLC as competition. If you'd encrypt your downloads, I am sure we would see another addon maker close the gap by making a new F-16 addon, for example, without, which would be modified and improved my other modders and surpass the existing quickly...

Hmmh, I see that in ARMA2 1.08 the same mission takes about 10% less memory demands, but I see no real performance improvement. Anyway, would be surprising since 1.07 was already very well polished. In fact the detail level of objects in distance is seemingly rendered with less details compared to previous versions, which is especially visible at some of the buildings in towns. Some are showing only the lowest detail and texture at medium distance of 200-300m, while in 1.07 you'd already see more details at the same distance and settings. So I have to switch up the "Object detail" level by one, which in turn also shows more (unnecessary) detail on all the other objects, and starts to cause lag. So for the same visual quality as before, I seem to have lag now. I will test the AI improvements, but already found that the new commands previously implemented in OA (fireat etc) have not made it retroactively into ARMA2. So if the AI doesn't change in major ways (say the slow embarking of units, or the problem with convoys not keeping tight formations on roads), I will downgrade again to 1.07. But still, I like the support that BIS provides here! It may not be all what I wish for, but it is excellent caring for the community. Other publishers could find a great example here.

The alteration of trajectories would be neat too, but isn't a serious issue if the buildings don't work as cover anyway. I used a scripted test mission to look into those issues, i.e. the people inside the building are placed by a setpos in an init script (i.e. no one truly "enters"), and the only person moving is the one outside. AI can see inside, even if you don't do anything. And it also starts peppering glass-covered windows that a player fired from a large distance, i.e. also notes shooters. But turning this around, AI inside simply stays idle even if shoot at from 5m in front of the window it is behind -- it only reacts to enemies inside the same room. You can test that easily using the Pubs everywhere, or even nicer: The big Hotel in Chernogorsk, the one with the huge glass windows in the hall -- that it really just sucide for AI to enter there. (Besides, doesn't the ladder to the rooftop work? Ok, 20 floors, but it is there?! Also I saw "elevator" scripts in the building pbo file). I tried to edit one of the p3d models I debinarized using on of the tools mentioned in the PMC Editing Wiki, edited the VIEW GEOMETRY MLOD and removed the facets for windows (make it like a door in the VIEW MLOD), but after repacking the whole pbo with just that model changed, the model wasn't being binarized and I got lots of error messages in the log. Would be nice if an expert could take a look at this whole question. I find it a rather important issue for any MOUT or urban fighting and must wonder why few others else have mentioned it yet?

I understand the fear some people have with unlegitimate copying of code/models without giving proper credit. But asking for a encrypted pbo format is not going to solve the root cause of this problem, but just fighting the symptom -- and history and experience shows that that never works. It wouldn't take weeks until someone cracked the format. Besides, it would surely negatively impact game performance, especially for often accessed files on the hdd. The only smart, and true solution is going after the cause, and that could be done by (a) outing mods of people who can be proven to have copied 1:1, and (b) by hosting ARMA news sites to remove such addons. Tedious, and would require a group of volunteers to look through such cases, but the only real solution that will lead to lasting effects, and not just more annoyance. More promising is just to appeal to modders, and I would think the large majority of the people are honest and will improve. I for my part would never offer any addons except under the sole prerequiste that both "usage" AND "further development/taking ideas" be done under the open source paradigm, and that anyone who uses these addons, and implements anything taken from those, must himself offer his addons under the same conditions without restrictions and encoding. And I would not use and encoded addons myself, by principle. The reason is as simple as I had stated it above: The OFP/ARMA community to large part today is only what it is because of this open, highly active and interacting community that was enable through the high-modability of the ARMA series. It doesn't take much to realize that without this, a niche product like ARMA2 would not have attained such a fan-base, modding community and long life. Allow to encrypt addons, and everyone will do so -- and development and exchange of ideas, which is undeniably necessity for fast progress, will decline rapidly. Nothing will move in a year from now. And with but few addons ever seeing light, and the modding scene quenched, the future of the ARMA series would look very grim. It is a niche product, and will die as such when this modding scene dies. You would be sawing off the branch on which you are sitting -- for absolutely no gains other than volatile honor?

No one who really knows how this works, and willing to explain? Bummer, this is a major issue for urban combat. It is basically pointless to fight AI in towns if they cannot shoot from inside (some? all?) windowed buildings.

The point is yours...

I strongly and entirely disagree. In science, it is ideas that are most valuable to drive forward research and development. Without ideas, nothing would move in our society. Similarly modding has always benefited widely form exchange of ideas and samples. This modding community would most likely not exist or be disfunctional and minimal if addons were not following the open source thought. Maybe without this powerful, and free modding community OFP would never have achieved its wide acceptance, and we never would have seen an ARMA2, nor be following this forum anymore. What I feel is a bad thing is people not giving proper credit to the original idea, and the people having come up with it. Though of course this is only true in case of intentional ignorance. This discussion about locked PBO's is very sickening. I would for my part not use and promote such locked addons. I hope other people would as well, as it really would irreversibly damage the foundation of the ARMA community.

There is some close similarities to C/C++, but else the commands are often pretty game-specific. However, learning good style, object-oriented C++ programming is always a high goal. And valuable asset for the rest of your (computer) life, if you can master it.