gmt2001

The script runs on the player who executes it, so if the flight script is similar to the current version, that does mean that if player 1 disconnects it stops working. However, if you had some global location to store the necessary variables, such as on the GCS object, you could make it so that when another player picks up the GCS, controls transfer to that player. The coordination to make the flight pattern look as if this isnt happening is a potential problem but you might be able to reduce it by storing a variable on the GCS which states which leg you are currently flying.

For the future, if you successfully link your bank account to your PayPal account and complete the verification process (I'm not sure if you also have to do this for a credit card or not), then when you place the order they will just call you and ask you to enter a code from your screen to confirm the purchase is legitimate instead of flagging it.

-----

The raven can not be used as an ACE backpack because ACE backpacks are created as WEAPONS that fit in the SECONDARY/ROCKET slot. The Raven backpack is an OA BACKPACK. The only way to do this is to convert it. The current model will show up sideways if you try to use it this way. I have tested it all out. I do have a mod which allows you to put it on back though. The only reason i suggested keeping them local was to save network bandwidth from being wasted transmitting variables that would end up being niled/destroyed before another user touched the raven.

Another potential place to store the variables would be a GameLogic item. For example (pseudocode): if (itemNotExists ["gamelogic_ravenVars"]) { createItem ["gamelogic_ravenVars", public]; } ["gamelogic_ravenVars"] setVariable [player1NameOrId + "_nameOfMav", _nameOfMav1, false]; ... ["gamelogic_ravenVars"] setVariable [playerXNameOrId + "_nameOfMav", _nameOfMavX, false]; thus you would have a single gamelogic item that stores the variables for all players ravens (set as public so its broadcast to JIP). The first player would create it if it wasnt there. Then each ravens variables are stored just as they are now with the players name, id, or other identifier as a prefix. Since we only want the gamelogic item to be broadcast to everyone but not each players variables the last parameter to setVariable is false, making the variable itself local. The player name or id is then used just as insurance and to make it easier to change if you later decide to broadcast all of the variables so other players scripts can take over the raven.

I'm curious as to why you moved the battery level to the callers group. I think that would make it so that if 2 people in the same group, from using Domination's "Show Status"->"Team Status" dialog or the default mission groups for example, used a raven they would both have the same battery level as the second person to launch and, in rare cases, cause it to go down by 2 notches each time. Also createMarker is global to all sides. You will have to do something to the effect of the following pseudo-code function onRavenlaunch nameOfMav = _this select 0 mavSide = _this select 1 ["ravenLaunched", [nameOfMAV, mavSide]] call CBA_fnc_globalEvent end function handleRavenLaunched nameOfMav = _this select 0 mavSide = _this select 1 if (side localPlayer == mavSide) then x = createMarkerLocal "raven" x setMarkerPos getPos nameOfMav end end ["ravenLaunched", {_this call handleRavenLaunched}] call CBA_fnc_addEventHandler See http://forums.bistudio.com/showthread.php?84083-Marker-local-to-one-side-only See https://dev-heaven.net/projects/cca/wiki/Custom_Events_System

There are no plans for this as ACRE is not meant to be used in such a way. Just place radio boxes if you want players to be able to grab something other than the 343

That would require a change to the mod itself or another mod which overrides it. The markers were originally setup in a way which favors Single Player or CO-OP missions

The only way to do this would be to take the old radio off of the dead body and give it to the person after they respawn. If you give someone the actual radio that they had before the IDs shouldnt change It is possible that while your machine is not under stress that it cant handle running the mod with that many people due to the way the mod is handling the users. For example if the serverside part of the mod has an infinite loop that is supposed to be doing some kind of check or taking some kind of action on every player in the server, it may be that the loop cant handle having so many players at once, especially when you add in the processing that @I44 might have to do. I see that UO and ShackTac have managed it before but im not sure what tricks they might have used to make it work, but its possible that ACE simply diddnt have as much impact on the acre serverside script as @I44. You would have to ask them if they have any insight.

In order to confirm the cause of the problem you would have to re-create the same conditions while removing mods one at a time until you correct the problem. Once youve done that the mod whose removal fixed the problem is the problem. There is no interface between the arma 2 server and the ts3 server. The interface is between the arma 2 server and the arma 2 client(player), then from the arma 2 client(player) to the ts3 client. Thus, having separate ts3 and arma 2 servers should be fine Go to Help->View Changelog on the teamspeak 3 client. If the section for the new version of teamspeak does not contain a line similar to + Increased Plugin API version to 19 then it is a pretty good bet that ACRE should be just fine as it is Its possible that tracking all of those radios could cause a problem but it would need testing to positively confirm that.

In that case it cant be related to any of the raven scripts because none of them run until you spawn a backpack. Not sure what else in the mod could cause it

baseball.p3d is used as the hidden object to which the "#lightpoint" vehicle is attached which thus defines the position from which the flashing locator strobe emanates This could be something related to the many things that occur when the raven gets within 14 units of the landing position which consist of the following in order: -The sound antiTamper is played -The static raven is created and then set to the current position, bearing, and velocity of the flying raven (The flying raven is represented by a different object than the non-flying one due to the way the game works) -The flying raven is deleted -The battery level is transferred from the player to the static raven -The message indicating the landing coordinates is sent to the players chat -The sound watchBeep_off is played -The players actions for controlling the raven are removed from the action menu -The locator beacon script is launched -Some tracking variables are cleared -The map marker for the raven is deleted If any sort of errors get placed in the rpt file when this occurs it might help nail it down, otherwise it would take trial and error on someone who consistently gets the drop. Considering the number of steps that happen here that must be synchronized though, it may be causing some kind of network problem even though it seems like a really low number of items

I see what your saying about someone carrying both the 117 and the raven. My final note on the matter is that if desired my compatibility script can be made as a completely separate pbo that the user can install if s/he wishes so that the user has the choice and so that it doesn't make ACE a required addon for the rest of the addon. If you want to go the ACE Self-Interaction menu route i can help you with it but doing so properly would require adding ACE as a required addon and thus should, if possible be done as a separate PBO. You could avoid this by making your own similar type menu with a different keyboard shortcut. The ace self-interaction menu is actually made using a feature of CBA so by making your own menu you will only need to make CBA a required addon.

To clarify, the ACE On-Back script i made is for the backpack, not the assembled raven. It is to allow moving the raven backpack into the extra backpack slot ACE adds (shown underneath the Secondary/Launcher slot in the gear screen). In its current state the backpack is not compatible because it is an OA backpack and not an ACE Weapon-Based Backpack. In fact, you can put an ace backpack on your back, put a raven into your secondary slot, and then move the ace backpack to your secondary slot and they would both occupy the same spot at the same time. The script i offer uses a setVariable on the player and a Weapon-based backpack to allow the on-back functionality. When in the secondary slot the current backpack is used the way it currently is used. When you try to move something from your back to secondary or use the action menu entry to put the raven on back, it saves the battery state from the raven backpack to a setVariable on the unit and then replaces it with a weapon-based backpack. Once the raven backpack is moved back to the secondary slot it is replaced with the current backpack again and the battery level is transferred to the backpacks setVariable. The main use for such a thing is to allow players using the ACRE mod to carry a Raven backpack and be able to use the AN/PRC-117F without having to deal with both items occupying the same slot (and potentially confusing them) For the vehicle usage of the raven the only solution currently available is to add the ravens control actions to the ACE Self-Interact menu or to add your own key combo which opens a similar type of menu @JKing The built-in ArmA 2 behavior is to not allow medics to carry backpacks See http://community.bistudio.com/wiki/addBackpackCargo

This mod is the only thing i know of to make it work with other units. I am not sure why those other units would still not be able to pick them up

Im not sure what the alive query would do at that time. The idea for the disconnects would be to have an object which can be found using listObjects or vehicles or some other finder function that has a copy of the ravens variables. If a player disconnects then other players scripts can cleanup after them using the copies of these variables Also i have a script which can be used to allow compatability with the ACE On-Back system. It wont allow you to place it in backpacks but allows you to use it with the On-Back slot Finnaly, you should change the Range Ring and Target Marker to be Local markers. Only the player deploying a particular raven needs to see these markers

The unit object becomes invalid and when you poll getPos on an invalid unit it just returns the bottom left of the map. The global script variables are still ok but the _caller object in the raven script is invalid and setVariables set on the unit are gone. setVariables on the raven would be saved however Here is the workaround i came up with in mavLaunch.sqf private["_lastCallerPos"]; _lastCallerPos = getPos _caller; while {(alive _caller) and (alive _microAirVehicle)} do { _lastCallerPos = getPos _caller; // NW _mavCurrentHeight = mavCurrentHeight; _microAirVehicle camSetTarget getMarkerPos mavCurrentTarget; _microAirVehicle camSetRelPos [(39 * radiusMultiplier), (39 * radiusMultiplier), _mavCurrentHeight]; if ((!isNil{_caller getVariable "birdRecall"}) or (!alive _caller) or (_caller getVariable "ravenBatteryLevel" <=0)) exitWith {}; _lastCallerPos = getPos _caller; sleep (3 * radiusMultiplier); // NORTH _mavCurrentHeight = mavCurrentHeight; _microAirVehicle camSetTarget getMarkerPos mavCurrentTarget; _microAirVehicle camSetRelPos [0, (55 * radiusMultiplier), _mavCurrentHeight]; if ((!isNil{_caller getVariable "birdRecall"}) or (!alive _caller) or (_caller getVariable "ravenBatteryLevel" <=0)) exitWith {}; _lastCallerPos = getPos _caller; sleep (3 * radiusMultiplier); // SW _mavCurrentHeight = mavCurrentHeight; _microAirVehicle camSetTarget getMarkerPos mavCurrentTarget; _microAirVehicle camSetRelPos [(-39 * radiusMultiplier), (39 * radiusMultiplier), _mavCurrentHeight]; if ((!isNil{_caller getVariable "birdRecall"}) or (!alive _caller) or (_caller getVariable "ravenBatteryLevel" <=0)) exitWith {}; _lastCallerPos = getPos _caller; sleep (3 * radiusMultiplier); // SOUTH _mavCurrentHeight = mavCurrentHeight; _microAirVehicle camSetTarget getMarkerPos mavCurrentTarget; _microAirVehicle camSetRelPos [(-55 * radiusMultiplier), 0, _mavCurrentHeight]; if ((!isNil{_caller getVariable "birdRecall"}) or (!alive _caller) or (_caller getVariable "ravenBatteryLevel" <=0)) exitWith {}; _lastCallerPos = getPos _caller; sleep (3 * radiusMultiplier); // SE _mavCurrentHeight = mavCurrentHeight; _microAirVehicle camSetTarget getMarkerPos mavCurrentTarget; _microAirVehicle camSetRelPos [(-39 * radiusMultiplier), (-39 * radiusMultiplier), _mavCurrentHeight]; if ((!isNil{_caller getVariable "birdRecall"}) or (!alive _caller) or (_caller getVariable "ravenBatteryLevel" <=0)) exitWith {}; _lastCallerPos = getPos _caller; sleep (3 * radiusMultiplier); // EAST _mavCurrentHeight = mavCurrentHeight; _microAirVehicle camSetTarget getMarkerPos mavCurrentTarget; _microAirVehicle camSetRelPos [0, (-55 * radiusMultiplier), _mavCurrentHeight]; if ((!isNil{_caller getVariable "birdRecall"}) or (!alive _caller) or (_caller getVariable "ravenBatteryLevel" <=0)) exitWith {}; _lastCallerPos = getPos _caller; sleep (3 * radiusMultiplier); // NE _mavCurrentHeight = mavCurrentHeight; _microAirVehicle camSetTarget getMarkerPos mavCurrentTarget; _microAirVehicle camSetRelPos [(39 * radiusMultiplier), (-39 * radiusMultiplier), _mavCurrentHeight]; if ((!isNil{_caller getVariable "birdRecall"}) or (!alive _caller) or (_caller getVariable "ravenBatteryLevel" <=0)) exitWith {}; _lastCallerPos = getPos _caller; sleep (3 * radiusMultiplier); // NORTH _mavCurrentHeight = mavCurrentHeight; _microAirVehicle camSetTarget getMarkerPos mavCurrentTarget; _microAirVehicle camSetRelPos [(55 * radiusMultiplier), 0, _mavCurrentHeight]; if ((!isNil{_caller getVariable "birdRecall"}) or (!alive _caller) or (_caller getVariable "ravenBatteryLevel" <=0)) exitWith {}; _lastCallerPos = getPos _caller; sleep (3 * radiusMultiplier); }; while {alive _microAirVehicle} do { if (alive _caller) then { _microAirVehicle camSetTarget _caller; _microAirVehicle camSetRelPos [0, 5, 2]; if ((_caller distance _microAirVehicle) < 14) exitWith {}; } else { _microAirVehicle camSetTarget _lastCallerPos; _microAirVehicle camSetRelPos [0, 5, 2]; if ((_lastCallerPos distance _microAirVehicle) < 14) exitWith {}; }; }; for the disconnect problem maybe you can make another baseball object like with the strobe that is nocollide, add a public setVariable to it which defines it as a raven info object and the owners name and have all clients hideObject it with a loop. When a player launches a raven their scripts then keep setVariables on their baseball object containing all of the necessary variables to control their raven such as map marker names and a reference to the plane object. Every so often clients check baseballs to see if their associated clients are there and if not, use the stored information to at least delete the raven and its markers. Once the raven and its markers are removed the baseball for the disconnected client is deleted.

your code for that is flawed at least when using ace. once the unit respawns the _caller becomes invalid and points to a non-existant entity that is off-map in the lower left of the map. The raven will fly to the bottom left corner and hang there. (tested a few days ago with 1.1) If a player disconnects while the raven is in the air it will also just freeze up where it is and if the player was in camera view their GCS will stay where they were too. Also if your interested i figured out how to make it compatible with the ACE on-back feature.

I would like to see the brightness system for NVGs improved as well as the transition be made more realistic. (the blindness when putting them on/taking them off) I would also like to see the ability to have PVS systems on rifles that have that capability and if the PVS system is able to be flipped up and down like in BF3 then that should be present as well. Laser Designators should have a "code" system like the one in ACE which can be used by any system capable of such a thing. For example if a laser guided arty shell is fired and it has the code distinguishing capability then it could lock onto a specific laser code, thus allowing say 2 spotters to lase for a simultaneous strike coming from 2 arty cannons. Designator beams should also be invisible if their real life counterpart is. AI hearing should be made a little more realistic. For example if i shoot a subsonic bullet from a suppressed weapon and it passes 50 meters away from a soldier, the AI should perceive it as in real life. If in real life it would be barely noticeable then it should put the AI on edge but not have a 100% chance of them detecting it completely. Just as well if i shoot a buddy of his that's 200 meters away with the same weapon and he isn't looking at him and he shouldn't be able to hear the bullet or the guy getting hit then he shouldn't detect anything and should go about his patrol. As mentioned ambient noise should also be factored in. I would also like to see weapon data and compatibility information calculated from a combination of weapon, magazine, and projectile data. We shouldn't need things like the ACE magazine replacement system to ensure that everything is compatible.

I see some good arguments here but also some misinformed ones. Here is my 2 cents. 1. Those of you who argued for PB because they have PSB and ACI and the like may not know what they really are. What you mat not be understanding is that PSB, ACI, etc are simply third parties where you can upload proof of cheating. Their team of trusted users review the evidence and if they agree that it is cheating then they add the PB GUID of the player to their list of bad players. The game server looks up this list every so often and simply copies all of the lists bans into their ban list thus automatically banning those players even if they ahve never played on that particular server before. This can be done with just about any Anti-Cheat System if someone is willing to put the resources in. Those of you who are aware of this and used this argument with the intention of meaning that it is already established and there is no need to have to build an entirely new global banning system are, however, justified in your argument. 2. VAC is not what some of you believe it to be. The way VAC works is it gathers evidence on as many hackers as it can before banning them, implemented as a tiem delay between detection and banning of the player. The purpose of this is to not give the hackers as much of a hint that their program has been detected. VAC only bans you from the Game Engine you are using, not from all VAC games. So if you are banned in CSS then you are banned in DODS but you are not banned from CS 1.6 or, if it were chosen, ARMA 3. 3. Additionally, using VAC doesn't mean that you now have a real GUID or anything. Your GUID for VAC/STEAM is simply an ID Number that is assigned to your login. Anyone can create a new account. The argument of having to buy it again however is true. 4. It can be agreed upon that BE can be useful if it was improved a bit more in the area of lobby and signature checking. The signature system should be redone so that while a single signature by the author can be used as a way of verifying the author, another signature or part of it is reasonably unique to the exact copy of the file you have (similar to the way an MD5 checksum is used to verify a download isn't corrupt) 5. It can also be agreed that a good portion of cheating in ArmA is due to things done on the client being accepted unchecked by the server and that certain things (like spawning vehicles/bombs/etc) should be the sole domain of the server 6. None of the Anti-Cheat Systems are necessarily better, especially for reasons such as which is older, who made them, market share, etc. Each one is very good in different ways. Ultimately all we need in the Anti-Cheat Systems is a solid GUID system, reasonable detection of cheats, a solid update system, and a good update cycle to keep up with the latest cheats. Everything else that has been argued such as the signatures system can really be done directly in the game engine if BIS has the right people and can simply use the Anti-Cheat System as a provider of a GUID for identifying a player if a server decides to ban them.

Just remembered something not in my post on Page 3. How about they let us use anti-cheat in listen servers. It is absolutely unacceptable that listen servers should be forced to deal with hackers when dedicated servers can at least block some of them

Synchronization needs to be properly done. As it stands now in ARMA 2 if i join a game where a wall was blown up for me it will still be intact and i can not go through it Something like ACRE built in as a server option would be a plus I would like to see realistic carrying capacity. AKA as it stands now the C130 can only hold somewhere around 28 people when the game claims its capacity is somewhere around 90 In addition to the above how about a system where you can do parachute drops from something like the C130. The type where they hook up to the line that is attached to the plane I would like to see all attachments to weapons be made as separate entities and the gear selection dialogs should have an advanced dialog for each weapon where you can see a representation of its rails and attach any attachment which is designed to fit in that particular rail. Thus the M4 for example can be customized with any combination of attachments that fits on the MIL-STD-1913 Picatinny rails. And if a new attachment comes out then rather than making new versions of every single gun in the game that accepts the attachment, which may then cause people to just not make it, we can simply model the attachment once and set its properties and behavior We should be able to use our gear when inside of vehicles if it is reasonable that it may be used in real life. Such that we can use binoculars, guns, etc from the HMMWV front passenger seat Silencers should be more realistically modeled in all respects. I am mostly thinking AI-wise. The silencer should be made to have real sounds and sound levels. The detection of a silencer-equipped weapon firing by the AI should be done more realistically Weapon usage on certain weapons, especially lock-on type, should be done realistically this time. Javelin, Hellfire, etc The devs should look to popular mods such as ACE for more ideas One more important improvement. The devs should include support for more RAM. The dedicated server should definitely be available in a 64-bit version to allow usage of as much ram as needed so that memory-intensive things such as Warfare BE can be run without fear of crashing due to running out. This is one of the main things that holds us back. Making the client available in 64-bit would be a plus but if not then at the very least support for 32-bit with extended ram (such as 3GB/4GB) should be done