eViLsTieFel

It seems that the latest version of RTE cannot be used in conjunction with the updated @JayArma2Lib. The update was necessary due to some internal changes with the most recent beta version of ArmA2. The problem now: exporting does not work, because a connection between RTE and RTECapture cannot be established. Is it possible at all that you could update the package once more to make the feature available again? This would be very much appreciated! Danke im Voraus, Steffen

Just wanted to let you know that there is an error in the way you signed your addon. You should resign them using the intended tool by BIStudio. Great work other than this "minor glitch"! If you try and connect to a server with keyfiles enabled, even though having placed the klu.bisign in the keys-folder, you will be kicked because of DSA-check failure for klu_missilebox_ace_enhancement.pbo.

I cannot confirm this. Works fine here.

To answer your question: yes, that seems to fix the problem.

Yes, it is even compatible with Beta 35 as released today. The downloads are as follows: Installer ZIP-File Note that both of these packages include outdated versions of JayArma2Lib, which you will have to update yourself.

Fantastic news! Can't wait to try out the new version! Thanks for all your hard work (that goes for all the ACRE devs of course)!

Let me answer this: I think that was a statement regarding what issues people have with ACRE 1.0.10. The answer was' date=' there were no issues for the UO community except when you handle the plugin in a wrong way, thus introducing user-made problems. Examples are: [list'] [*]not running TS as administrator [*]having voice activation enabled and NOT Push-To-Talk on 32 bit versions of TS [*]forgetting about the dsound.dll

As I understand it ACRE is not a substitute for whisperlists. It should represent and implement a way to handle radio communications in a realistic way. Of course, you can always setup an object/vehicle as a retransmission station that would link different channels together, as per the API instructions. This would have to be done on every mission though and I don't really see the point. Maybe it would be worth your while to rather think about a proper setup for your platoon's communication system.

Both of these issues are by design and not an error. In the ACE mod, determining the distance is done using either the rangefinder or the laser designator. The command cross and binoculars will not show the distance. Notice how also, by default, the crosshair is disabled when you use the mod. The zeroing in has also been replaced — rifles that offer scopes with that ability can be zeroed-in using SHIFT+V by default. Consult the ACE documentation for more information on these and other issues.

Just to clarify: do you recommend using 1.0.10 over 1.0.11? Because the latter is being distributed over the Six Network, and I've been experiencing glitches with the 1.0.11 I am not sure where there before (problems with players being totally mute even though they are standing right behind you, while others can hear them fine — even radio transmissions won't be heard *client specific*).

I hope they won't end soon. There still is work to be done. But they might want to keep the plugin API unchanged for a while ;). Anyway, working great on my side, just have the occasional locally muted client. For anyone who is still wondering, you can grab 1.0.11.210 (Hotfix'd version) from the official dev-heaven space.

Alternative download source can be found here (e_missions.zip).

And the Sprocket version, too, is not without flaws, seeing as I get those error-messages on patching that the DVD-version does not throw at you.

Reinstalling DOES NOT resolve this patching issues. If you want to backup your profile though (because you will have to reinstall anyway to properly apply the patch), just backup the ArmA 2 and ArmA 2 Other Profiles folder in your Documents-Folder. On my machine, these folders did not get deleted upon deinstalling anyway.

Did any solution pop up for the Sprocket-Version of the game? I cannot install without errors and cannot connect to 1.54 servers, because of unsigned addons (namely the missions.pbo).

Roger. I have removed the link from the post. No intentions for evil-doings here ;)

Created a torrent for everybody to use and share. Hopefully, this is not against the rules. I have seen links to torrents for the other patches for ArmA though. Hosted on a dedicated server, so should be quick ;). Edit: link removed due to uncertain sharing conditions on this board.

Getting the errors aswell (Sprocket Version). Copying the file to the ArmA2 directory did not resolve the issue.

Have the same issue, oktane's patch fixed it for now! Thanks much!

I guess he means pseudonym or nickname.

You do not have to "open" it. In the lower right, there is a box where it lists all of the items currently stored in the backpack. To get them out, simply select them in that box und click on unpack. Packing is the other way around. Select an item in your inventory and click on pack. If there is room left in the backpack, the item will be moved into it!

This is great news for a lot of server hosters... maintenance down, fun up :) Congratulations!

Hey everybody! I'm working on a mission that involves checkpoints... it's a multiplayer mission. So far, everything went okay. There seems to be a problem with a trigger though: I'm creating a car, a civilian and an independent unit. On initialisation, the civilian gets in as driver, the indep is assignedAsCargo and gets orderGetIn true. Both units comply and move into the vehicle. After that, the civilian gets a waypoint to drive down the road towards the checkpoint and stop there. He does so, while the independent guy sits right next to him, not doing anything like he is supposed to. Now, I created a trigger, which does the following: car1trig = createTrigger ["EmptyDetector", [100,100,0]]; car1trig setTriggerArea [5, 5, 0, False]; car1trig setTriggerText "car1 reached Destination"; car1trig setTriggerTimeout [5, 5, 5, False]; car1trig setTriggerType "NONE"; car1trig setTriggerActivation ["WEST", "PRESENT", false]; car1trig setTriggerStatements ["(car1 distance (position car1 nearestobject 'SoldierWB')) < 5", "{_x setbehaviour 'Normal'; unassignvehicle _x} foreach crew car1", ""]; So, when I or any other BLUFOR Soldier approaches the car on foot, both driver and insurgent disembark, which they do! But now the odd part... the insurgent does not seem to correctly target any blufor soldiers, instead, he just fires his weapon constantly into the air while bending his back so that he looks upwards. During this time, everytime he shoots, gameplay gets very choppy and the game stops for some milliseconds. If I use RTE and do the exact same steps, only manually as a codeline, this does NOT happen and the insurgent kills people like he is supposed to. Obviously, the trigger does something to the game mechanics I do not quite understand... Anybody know what the problem is? Thanks!

Well yes, I'm using more than just one. But still, this wouldn't explain why this only happens when using a trigger, and works when doing it manually. Or would it? Edit: I can confirm it also does not work when just using vanilla arma without any mods (well, except for RTE).

It's not that he does not try to attack me, but there must be something weird happening to the unit when the trigger accesses it. It DOES fire because it detects my presence. Only it fires up in the sky and somehow drains massively on game performance. Either it's some sort of bug or something about local and global variables is going on that I don't understand :|.