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