Okay, I see you're just spamming loads of threads. Away ye go ya moonfruit.
Sep 7 2019
Sep 6 2019
I don't think it is resolved. I don't normally use the A3 Launcher but I just had a look at it and it doesn't seem to even list the SP missions the user has downloaded, let alone offer an option to automatically download any required mods for a mission and launch A3 with those mods.
Feb 23 2017
I've also found that the jets don't properly respond to my throttle inputs and I have to press the keyboard key to take off. I'm using the slider on my Sidewinder FFB2 joystick. When I click Show in the mapping screen it shows that ArmA is responding properly to the slider, reading 0 when it's at the bottom and 100 when I move it to the top, so when pushed up to the top it should make the jets go full throttle and take off but for some reason it doesn't.
Jun 19 2016
@goldblaze, I know the recommended practice is map both the + and - directions of the throttle to thrust but as I mentioned, doing that made it impossible to generate enough thrust to takeoff, whereas mapping only - made it work. Although even then, it seems to stop working some time later, like the next day or so when I next run A3, so that's not really a solution either.
Jun 18 2016
Having major problems with plane thrust with my MS FFB2 on current stable and Tanoa RC.
May 10 2016
Just wanted to explain that the proposed method is very much compatible with modding. As is done with x-plane, the vanilla commands can be grouped under a prefix like A3/ or Vanilla/ and then any mods have their own prefix, such as ACE/ or TFAR/.
So vanilla commands would look like "A3/Team Red/Line Formation", whilst mod commands would look like "TFAR/Short Range/Channel One" (I'm just making up examples here).
There has to be some care taken to try and avoid any conflict between commands and to make them match what people would say, to make it easy for the voice recognition program to find the matching command automatically without the user having to manually map spoken phrases to commands, as obviously the player doesn't say the prefix but just "Team Red Line Formation" or "Short Range Channel One", but the vanilla commands would be defined first and then modders would be expected to design their commands to avoid conflict.
Even where there is more than one mod that does the same thing and thus the commands have to be the same or similar, this can easily be handled by the voice recognition program having the option to enable/disable groups of commands. So if modX and modY do much the same thing and use the same command e.g. "Detonate explosives" and the player is using modX, he would just disable modY's command group in the program, so that when the program recognises the phrase "Detonate explosives" it only finds a match in the enabled modX's command list "modX/Detonate explosives".
In fact, even where a mod replaces a vanilla function and thus needs to use the same command, the program can use a system whereby the mod's list of commands, which are imported into the program and added to the existing list of commands, contains markers to indicate which commands should replace the vanilla ones. So when that mod's command group is enabled, it would automatically disable those vanilla commands that it replaces. For example A3/Pop Flare could be disabled in place of ACE/Pop Flare, so when the user says "Pop Flare" there is only one matching command that the program can find.
The voice recognition program would still need to provide the option to manually map phrases to commands if it proves necessary but in most cases the automatic matching should be sufficient.
Unplayable for me too. I get 8-15fps. Some SP missions are OK and give me 40-50fps but others are as bad as MP and run below 10fps (just happened with Op. Magic Carpet).
Phenom II X4 955 @3.5Ghz, 16GB DDR3 1333Mhz, 6950 2GB
PwS is just a launcher, so I don't see how that could be connected to the game crashing, as it doesn't do anything once A3 is launched.
I'll try without the tbbmalloc but it's hard to repo a crash that only occurs intermittently and after several hours of online play. I wonder if it's the same or related to this ticket, as I do have dual monitors and at least one of the other people who crashed around the same time as me tells me that the error specified in this ticket is the one his rpt showed? http://feedback.arma3.com/view.php?id=579
It seems this could be patched quite simply.
One way you could fix this is read which Axis has been mapped to Collective Raise (analog) and Collective Lower (analog) when someone switches to SFM and remap both the + and - to Collective Raise (analog). Likewise, when the user switches back to AFM, automatically remap the + and - mapped to Collective Raise (analog) back to the two separate Raise (+) and Lower (-) commands.
Another way would be to have two sets of mappings, one for SFM and one for AFM, so that in SFM you could have the axis + and - both mapped to Collective Raise and in AFM have them mapped separately to Raise and Lower. It's possible that some people might like to vary other mappings when changing between AFM and SFM too (no need to use a joystick button as Trim for example), so this might be the most useful fix and shouldn't be any harder to implement than the other idea.
I am looking at the bigger picture, as in I don't want BIS wasting time on this feature when there's more important things for them to do at the moment.
We're talking about VOIP, not chat (i.e. text) and I don't see that's it particularly hard with some radio discipline to manage all 3 teams on the Group VOIP channel. The team members should be close enough to communicate with each other using the Direct channel and not need to clog up the Group channel.
On my clan's server, we use TFAR and use the Direct Speech button (standard Teamspeak key), which is similar to VON's Direct Channel for talking to nearby squad mates (it can be set to Yelling to increase the distance that it travels) and the SR radio for talking to the team leader or other members of the squad who are further away. Or you could give each team leader and the squad leader an extra SR (or LR) radio, so that the team communicates with each other on one channel and the leaders on the other radio set to a different channel.
VON has always been inferior to third-party solutions such as ACRE and as we have these better solutions and BIS has enough other problems to sort out, it seems pointless asking them to spend time on improving VON.
Teams are used for giving commands to the AI, so aren't just cosmetic and you can still give commands via the menus for them to read even if this team is human players, although obviously this is awkward unless you're using voice activation to send the commands or know the menus off by heart.
I don't really see any need for extra VOIP channels though as it's easy enough to use Group and just say "Green, do this", so that the other fireteams know you're not talking to them. You'd need four or five extra VOIP channels to cover all the Teams, which would make scrolling through the VOIP channels more fiddly.
Totally agree with this. For a sensible way of handling mod keybinds, have a look at X-Plane. On this first screen, I click Add New Key Assignment, which adds a blank entry at the bottom
then clicking in the box highlighted at the top opens this screen, which lists all the plugins with assignable commands, where I can select one and then assign a key to it on the previous screen.
As long as each mod uses a unique name, like sandybarbour in this example, then there's no conflicts.
In ArmA, if you want to keep the controls screen as it is now, keep the Custom keys section but have it empty if nothing has been added, with an Add New Assignment button at the bottom, which opens a screen that shows all those mods which have defined commands, like X-Plane does. I'd ditch the current 20 user keybinds ASAP, to make sure modders move away from that old, unworkable, system.
I now understand that ArmA already has a way to add Custom categories to the Controls settings (like this http://i.imgur.com/3d6sYSi.png), just not Custom actions. So all that needs to be done is to provide for this, then define a place in addons where the creator specifies a Category name and the actions provided and then ArmA3 should automatically add the Category and actions, for the user to assign as he sees fit. It would be nice if the addon creator could specify default keys as well, which the user can then change if the GUI shows there are conflicts with existing keybinds.
OK, I did some testing with a mission (Operation Aspis - Part 1) where I could switch between different soldiers with varying loadouts and I found:
- It generally seems that soldiers can look further over their left shoulder than their right. Using Alpha 1-1-3 Autorifleman as an example as his back is relatively clear. Maybe this is explained by the fact that he's holding the rifle in his right hand but shouldn't he be able to be able to rotate his upper body slightly so that he can look as far in both directions? Looking left I can pretty much see my six, except for a small blindspot but looking right it's limited to maybe 4-5'o'clock. I can also do some pretty weird stuff looking left, like look back at my own chest and radio as if my head was on a stalk but that doesn't bother me as it doesn't affect gameplay.
- Crouching does cause the soldier to lean forward a bit/hunch his back, so that his harness somewhat blocks his six but not unreasonably and his shoulders are still not in the way, although that varies depending on his load-out of course.
- Moving forward whilst crouched causes the soldier to lower his body almost parallel to the ground which does of course result in him looking at his shoulders when turning his head. I guess this is realistic and necessary to maintain balance although I wonder if IRL he couldn't just raise his head a bit to see better.
- Lowering the weapon also lowers the shoulders, providing a clearer view over the shoulders.
- Moving forward with the weapon lowered actually results in the shoulders moving around more and them (or any attachments) blocking the view more than when moving forward with the weapon raised (I don't mean combat stance which obviously makes him go a lot slower). This probably makes sense though as although he doesn't appear to be moving any faster, having the weapon raised forces him to keep his upper body more stable.
- Soldiers seem to have a tendency to sway their upper body quite a bit (idle anim?) whilst I'm looking over my shoulders, which causes them to get in the way and block the view intermittently.
So it's probable that on the MP missions (which is all I've been playing lately) that I encountered this issue on I was either wearing a backpack, was moving forward or possibly crouched and moving forward.
So the only issue after further testing seems to be 1. It seems that when looking over my left shoulder, whatever the furthest point my left eye can see should be roughly the furthest point my right eye can see when looking over my right shoulder (this certainly seems to be true for me IRL with little or no upper body twisting, although as I say this difference may be explained in Arma by the fact that he's holding a weapon in his right hand, even when it's lowered, or due to the weird head-stalk thing allowing him to see further behind him when looking left. Not as big an issue as I previously thought then but at least I've learnt something about the way stances and movement affect my view
It may be that, as suggested, there's something wrong with my FOV, as other people have said they can see directly behind, turning in either direction (backpack permitting) which doesn't seem to be the case for me. I did notice that a house looked smaller when it was in the centre of my view and got bigger when it was at the edges, which seemed rather weird!
I do wish that upper-body rotation would be added so that we can aim down our weapons more to our left or right whilst moving forward then we can at present, as it doesn't seem unreasonable to want to have weapons covering our 2 and 10 o'clocks without having to face in that direction and crab-walk sideways but that's a different topic and I only mention it because upper-body rotation could make the freelook feel a bit more realistic as well, although I accept that it might not be worth the effort if we can already see as far as we could IRL anyway.
Link to forum thread:
What tuplas said about 75% increase, 25% decrease range doesn't seem entirely correct though.
With both parts of the Z Axis assigned to Collective raise (analogue) and only the Z+ Axis assigned to Collective lower (analogue), in the MH-9 with the Collective fully down the (left dial) RPM is about 98. Increasing the Collective from DirectInput 0 to 27391 reduces the RPM to 91 but it doesn't take off until I nudge it a bit further, to about 28671 (maybe a bit higher as this is what's needed to keep it hovering at 3m) and below that it will start descending again.
I'm pretty rubbish at maths but the full range of the throttle is 0-65535, so I reckon 25% of that is about 16383, whereas 28671 is about 44%.
I removed the mapping of Z Axis - from Collective lower (analogue) and then the point at which I take off/hover is about 17407 but if I increase it so that I climb and then reduce it again, I'll start descending very slowly at around 20223 until I get to about 3m, where I'll hover again (due to the air cushion I guess).
I don't like playing in 3rd person though and on decent servers that will be disabled.
I'm pretty unfit myself but I don't sound anything like that when I get out of breath.
OK, so can I adjust it when playing SP to prevent the heavy breathing after a short jog?
Strangly I've found that when playing some SP missions, the breathing doesn't seem to be a problem and I can run (or at least jog) for ages but whenever I play MP, it starts very quickly after a short jog.
I'm not sure if it's affected by weight (the Inventory screen doesn't seem to actually show weight, which is a shame) but I tried dropping most of my extra gear in MP and it didn't make any difference.
I posted this as ticket 12881 before I found this, so perhaps someone could mark it as a dupe.
"When I jog/run even a short distance, my character starts wheezing like he has Emphysema or something, which sounds disgusting and puts me off playing the game completely.
I don't care if you want to make me weak/slow after jogging a short distance but please do something about these sounds or give us an option to disable them and have an on-screen indicator of our fatigue state instead."
it really makes me ill listening to this, so I hope it can be changed.
Maybe as an option but PiP kills my FPS, from 30 to 22, so I wouldn't want to see this forced.
Agree with all that, except I'm not sure about using PiP for anything as that cripples my framerates so I leave it disabled. If they can fix it so it doesn't do that then great but otherwise I'd hate to see it REQUIRED to use certain weapons as then I wouldn't have the option to disable it and would have to put up with awful frame rates.
"How will you make the targetting work with you piloting a two seat attack chopper and AI gunner? Right clicking on two pixel wide almost invisible target in your zoomed out pilot's view? Pressing 2 and selecting from counterintuitive list praying that the NME SPAAG half a click away shooting at you is the one at the top of the list, instead of the SPAAG three clicks away that's not a threat? When with human gunner he would scan and tell you in voice, or you could tell him target the SPAAG that's shooting at us from 3 o'clock."
An idea I had to deal with this problem was to have numbers show above each target in the world when opening the target list. Whether the target list should just show a number as well, allowing you to select the target at 3'o clock near, easily but without being told exactly what that target was, or if the list should also identify what the targets are (i.e. 1. SPAAG, 2. APC) is a question that comes down to how much information would the gunner/pilot be provided with about the targets by the systems in the real helos. The list could only show numbers for some targets and further details for others, depending on which have been scanned by the helos targetting systems, etc.
Whilst it might seem unrealistic to some people as obviously in real life you don't have numbers floating in the sky above targets, it seems to me like a reasonable way to make up for the lack of real-life senses and ability to easily and quickly tell a human colleague which target to shoot, as you describe.
Totally agree with this ticket. The AI is meant to be one of big features of ArmA and this bug makes them unrealistic and limits the ability to create certain types of missions/tasks and the ability to create almost any type of mission is meant to be another big selling point of ArmA.
So BIS, please assign this and fix it ASAP.
OK but the link mostly refers to positional audio features and I'm saying that if the automatic server/channel feature used in PR Mumble could be implemented as well, that would be cool.
There's a custom version of Mumble for the Project Reality mod for BF2 and one cool thing about that is you don't have to connect to the right server, then manually select channels as you do with TS3/ACRE, you just connect and when you join a server and then a squad it automatically puts you in the right channel with your squadmates.
If something like this could be done in ArmA3, preferably without even needing an external app like PR Mumble, that would be amazing and I think would greatly encourage and simplify the use of comms.
Is this being worked on and are we likely to see it implemented any time soon?
Thanks Dwarden, look forward to seeing what you do with this :)
@Terox, Ah I see. Keep it simple I say ;)
Great to hear that subfolders in MpMissions is already scheduled. I too hope that some of the other suggestions in this ticket can be used as well, to make it as user-friendly as possible.
Regarding any possible delay parsing the missions, perhaps if this is an issue ArmA could store the details used for sorting/filtering (Island, playercount, etc) for all the missions in a database the first time the folder is scanned, for quicker loading next time. It would still have to scan the folder to check for new/deleted missions and add/remove those to/from the database each time ArmA is loaded but getting the details of the already scanned missions from the database rather than having to parse all the missions every time would be a lot quicker.
To allow for (probably rare) situations where the user Alt-tabs out and adds missions, perhaps a Refresh button could be added so that they don't have to close and restart Arma, whilst only automatically scanning the folder once per launch of ArmA (depending on how long it takes, either in the background as it launches or as soon as it finishes, or alternatively when first going to the MP Missions screen).
Perhaps there's room for a more advanced sort/filter as you suggest Terox, although if missions are named appropriately, i.e CO 23 Mission1, then it's relatively easy to find the sort of mission you're looking for in a list.
By having the missions in subfolders, it then makes it easier to drill down and have the list only display appropriate missions, i.e. ACE or CWR2 missions. So the missions that require mods (such as those with @ in the name) would go in the appropriate subfolder and by supporting several depths of subfolder, we could have an ACE subfolder and then further subfolders within that for mission type, etc if required. Although even one level of subfolder support would allow us to keep things fairly organised in Windows Explorer and then a sort/filter method to only show missions in the selected subfolder of a certain gametype, number of players, etc would be a good combination.
So I'm suggesting that missions are sorted (manually) by subfolder rather than by island as default (which is the current method) but that the list could then group the missions by island to allow the user to quickly scroll through and see all missions in the current subfolder.
I'm afraid you've lost me with the talk of using config.cfg to define the subfolder name however. In my opinion, the user should just be able to put the missions in whichever subfolders they've created manually and then ArmA should list these subfolders for the user to select from.
Indeed there would have to be a split between the "launcher" and the engine parts.
As you say, the engine is currently loaded, with the mods locked, as soon as ArmA is loaded and this needs to be deferred until a mission/server has been selected and at that point the engine can be loaded with the required mods.
I can't see any reason why ESC still couldn't be used to pause the engine and access the Options, etc. I guess it would just be accessing the "launcher" part to do this (or even a mini-GUI could be loaded with the engine for this, if this has any benefits in terms of being unable to unload the main "launcher" part but I imagine the only benefit might be freeing up a rather inconsequential amount of RAM).
It might be worth trying this A2 workaround with GlovePIE and PPJoy.
You shouldn't have to of course but until such time as BIS decide to sort things out it might help. I haven't tried it myself with A3 yet but did with A2 and found it helped a lot.
@Partix87, I'm not suggesting manually converting the old values to the new ones but if you just delete the lines in the profile relating to the axis, won't it recreate them with the new values automatically?
If creating a new profile fixes the problem, why would we need to use VJOY as well?
At the end of the day, this needs fixing properly so we don't have to faff about. Loads of players probably aren't even aware of this ticket or realise there's a bug and are just wondering why flying in A3 is so hard!
@Partix87, I presume you mean that fixed the "Throttle only uses half-range" problem, not all the other problems reported in this thread?
It's good that you've found a way to fix it but there must be a less painful way of doing so, either by editing the user profile files, or backing them up, deleting them and then pasting the contents (or most of the contents if a particular part is causing the problem) back into the newly created file.
If the differences between SFM and AFM require different mappings to utilise them effectively, perhaps the best way forward would be to have separate mappings for each mode in the Controls page?
Well if the weapon doesn't lower automatically, it would prevent the player from moving nearer to the wall (unless it's a magical bendy weapon), so it's a matter of deciding which would be more annoying, having the weapon automatically move out of the way when you're trying to move closer to the wall, or having it not lower and be prevented from moving to where you want to go until you first manually lower the weapon.
I very much agree with this. It was in an Unreal mod from years ago I recall (and probably a few games since) and it's always disappointing to see modern games without this, as it makes CQB much more realistic and tactical.
Not to mention that PwS can't help with automatically downloading and enabling the required mods for SP missions anyway.
true enough, although BIS may want to see if them can come to some agreement with Six about using their network, otherwise they're going to have to host all the mods themselves somewhere, which would be a duplication of effort.
whilst th3flyboy's original post refers only to MP, I am actually more concerned about SP missions as explained in my long post. As my own ticket was marked a dupe of this one, I've had to piggyback my ideas into this, sorry ;)
PwS does do a fairly good job of autodownloading and enabling the required mods for MP servers, as long as the server has setup the appropriate config.yml and the user does have to go to a website and click on a PWS:// link to add the config into PwS first, so if an in-game server browser could query the server when attempting to join and it would return the list of required mods, which A3 (Launcher) could then download and enable before launching A3 (Engine), this would of course be much better.
I'm more concerned with SP simply because there's no automatic way to download and enable required mods for these at the moment, making it extremely awkward and complicated to be able to play a SP mission that uses mods. PwS 2.0 may well bring something new in this respect but at the moment, it's SP functionality is very basic and not suited for this task and as you and Fireball suggest, to have both SP and MP mod handling built-in to A3 is the most desirable approach.
I don't know enough about the game to know what you mean about "how configs are loaded and overwritten" but I do understand (I think) that any mods have to be loaded when the game/engine launches, using the commandline -mod switch, which does present a major obstacle to dynamic loading.
Hence my suggestion that the game needs to be split into launcher and engine parts, so that the engine is only loaded once a mission has been selected, enabling the launcher to first download/enable any required mods and launch the engine with those.
If this is not something that BIS is willing to consider at the moment however, the game could be left as is and instead a separate launcher developed, which again would identify and download any required mods for a mission and then launch A3 using the appropriate commandline -mod parameters.
Maybe this could be incorporated into PlayWithSix but that's very much multiplayer orientated at the moment, so a simpler launcher designed for SP missions might be a better idea.
The disadvantage of this is that the player will still have to close the game and return to the launcher to select a different mission and then launch the game again, whereas if the game is split into two parts, only the engine has to be unloaded if different mods are required and the player stays within the in-game launcher component, which feels nicer/more professional than having to exit to the desktop and a separate launcher.
Cool to see this assigned at last :)
You have a great opportunity to do something awesome for ArmA here Gekon. I'm sure you'll do us proud (no pressure of course) ;)
Having now tested Steam Workshop it's clear this is not going to be able to achieve what we want. All it does is show missions in the game menu to choose from but by then the game has already been launched with whatever mods (or none), so if a mission requires mods it can't be launched this way.
So if BIS meant what they said about focusing on and encouraging user-created content, they really need to use the ideas in this ticket and make a launcher that will take the stress out of launching missions with mods manually, otherwise I fear that mods will be as neglected and overlooked by players as they were for ArmA2 and the only user-created content that will get used much are the mod-free missions.
No. How can Workshop download the Required mods for a server when the player goes to join it, then enable those mods and launch the engine with them and connect to the server? Does Workshop even include a server browser?
Can Workshop determine automatically what mods a SP mission requires and download and enable those before launching the engine with them, automatically launching the mission that the player has already selected, rather than just showing them a mission screen and requiring them to find and select the mission a second time?
If that's true then perhaps ArmA scripts should be run sandboxed to prevent them maliciously deleting files, etc but I don't know how much an ArmA script can actually do.
I guess if there is a threat and BIS can't implement a sandbox feature in the game, then we can just run Arma in Sandboxie, with Direct Access allowed to the Arma folder so it can only affect files in that and shouldn't cause any overhead.
Anyway, if files are downloaded from an official server it shouldn't be an issue. I'm not sure if Six Network checks files before putting them on the network but I'd certainly hope they'd take them down pretty quick once a problem had been reported.
Kocrachon, no suggestion that the mods should be downloaded from the game servers but rather from Six or a similar network. The proposal is just to have ArmA automate the downloading and activation of required mods (for both SP and MP) rather than the user having to find out what mods are needed, download them and create a modline (in the right order) to activate them for each mission they want to play.
Well sure, as I suggested if it needs to download mods it should give the user the option to proceed or go and choose another mission. With updates, it should give the user the option to update or just play the mission with the currently installed versions.
I think perhaps the best way to manage wanting to keep outdated versions of mods for whatever reason is to copy them to a differently named folder, i.e. @ACE-old. Then this will appear in the mods list and you can enable it for certain missions, whilst the current @Ace is kept updated as required for joining servers.
I'm not actually sure if servers even check mod versions and kick you if you have old ones but I guess it's generally a good idea that everyone has the latest versions, with bug fixes, new or tweaked features, etc.
It sounds like we share a desire to keep our folders tidy and so you might want to vote for this ticket requesting subfolder support for MPMissions ;)
I just opened a Feature Request http://feedback.arma3.com/view.php?id=9217 but I guess it might get closed as a dupe of this so I'll repost my Request here.
Currently, to play a SP/offline mission/Campaign, the user has to
- Find out which mods are Required for said mission.
- Manually download those mods
- Create a profile with a third-party launcher (or manually as a batch file) to launch ArmA with those mods enabled.
Then, if the user wants to play a different mission, he has to exit the game and do this all over again. On those occasions where I've done the above and started playing a mission, only to find it's bugged or I just don't like it, I'm too fed up by then to bother going through it all again and as a result I've barely played any of the many missions I've downloaded.
I would like to see ArmA3 automate this process, by it being able to determine, from meta-data in the mission or even an accompanying text file, which mods are Required for said mission/campaign and to automatically enable them (and download them if necessary). I think meta-data in the mission/campaign file would be best for missions designed for ArmA3 but obviously ArmA2 missions aren't all going to be updated in this way, so for those an accompanying text file with the same name and a specific extension (i.e. mission.amp, which could stand for ArmA Mod Profile), containing a list of Required mods would be a good compromise and players could manually create these and share them with each other on a forum thread or some other repository, so that we don't have to ask the mission creators to do the work and nor is all the work put on one person.
For standardisation, I think missions would have to use the mod-naming scheme used by Six Networks and I imagine that ArmA could download the Required mods that aren't already available locally from Six, whether by calling some part of PwS or Amarize silently in the background, both of which can download the mods from Six, or with completely fresh code to do the job but whichever method is used, ArmA should stay in focus and no other programs should pop-up. It should show which mods are already available and which require downloading and how big they are, to give the user the option of proceeding with the download or choosing a different mission.
Players will often want to play with additional mods to those Required and to manage this, on the main menu, there should be a Mod Management button. This would open a full-screen interface listing all the locally available mods in a vertical list on the left in alphabetical order, with a search box above that would highlight the found mod when enter is pressed (and cycle through matching mods with repeated presses). To the right of this list would be another search box, which would search the Six Network for a mod and allow the user to download it, adding it to the local list. On the right of the screen would be a modset vertical list, which would show created modsets. This would be created by selecting mods (using the standard Windows methods of multiple selection using Ctrl+click and Shift+click) and then clicking an "Add to Modset" dropdown button above or to the right of the list, which would show already created modsets and a "New" option, which would allow the user to enter a name for the new modset.
Back at the mission selection screen, where it shows the Required mods, there would be a vertical list, with the modsets at the top and all locally installed mods below. Each would have a tickbox next to it, so the user can either tick a modset (or more than one) and/or individual mods which will be enabled for that mission. The users selections should be stored so that they are already enabled the next time that mission is selected.
The same automatic mod downloading should be available for online servers as well, but with the list of Required mods being obtained from querying the server.
I understand that the engine doesn't allow for mod enabling/disabling, so the initial part of the ArmA GUI, where the user will choose a mission/server should not load the engine, with this only being done once a mission/server is selected and launched (look at the DCS World interface, which uses this method). When the user wants to change mission/server and returns to the mission/server selection screen, the engine can remain loaded in case the next mission/server selected uses the same mods but if not, the engine will have to be unloaded and re-loaded with the required mods.
I agree it should be possible to lower the binos to look/move around but I disagree that the default when pressing B should be to have them lowered. Currently pressing B defaults to them raised to your eyes and this is not only what many people are used to and expect but makes sense as generally when selecting binos, you want to look through them, not hold them in your hands.
It should definitely be possible to then lower the binos by pressing e.g. RMB or the raise/lower weapon key (I use 2xCtrl for this) so that we can look/move around and then quickly raise the binos again without switching to/from our weapon in between, which is completely unrealistic.
Awesome news. This makes me very happy :) Thanks BIS.
This ticket should really be closed now.
Perhaps instead of using the Windows settings, Arma could allow us to select which device we want to use for comms and which for the rest of the game sounds. Many onboard realtek chipsets now support two separate devices, for the front and rear ports, so it's just a matter of Arma sending the comms audio and using the mic on whichever device is selected in the settings.
I don't know if there's any benefit to doing it this way rather than just using the Windows Control Panel settings though, whichever works best. If the user only has one device, Windows will have the playback device and communications device both set to that anyway, so sending the comms audio over the default communications device will still work for such users.
Agree, it should be simple to save/load keybind profiles both for the current profile and any other profile that the user might create to save having to reconfigure from scratch.
I hope that an in-game solution would show the name of who's speaking and only the names of those who the player is on the same channel(s) as. This is a big problem with TS3/ACRE as the TS3 overlay shows the name of everyone on the server who's speaking, regardless of whether they're on a different radio channel and can't actually be heard.
Yeah, I guess replacing TS for pre-mission chat is a bit hard, other than using another external app like Mumble or if Steam introduced a feature that would allow us to join chat rooms for specific servers without having to be friends/members first. I guess if TS ever disappears, we can always move to Mumble or something else and it's not likely anyway.
So yeah, let's stick to discussing how to improve VON and make it more ACRE-like ;) If you've seen other ideas that are relevant, I guess you can re-post them here and just attribute them to the original poster, to make sure they're not overlooked.
I know one of the problems with VON has been that it seems to fall down with a large number of players and also that one of the A2OA betas changed the port it used, so that beta users couldn't talk with non-beta users and vice-versa and it's things like this that make people abandon it for TS, with or without ACRE.
By the way, PwS can auto-launch TS3 and connect to a TS server when joining an ArmA Server, so there are hooks available to do this.
I don't think Steam's chat is a viable replacement for TS as it requires everyone to be friends first to be able to chat. Might be OK for small clans but for larger public servers, like United Operations, it's useful to be able to go on TS and chat in the Waiting Room channel before joining the server and moving to the Primary channel. As I say, I guess we can still use TS for pre-mission chat and (if improved) VON for in-game chat instead of ACRE though.
One problem with VON is it only works in-game, so we still have to use TS3 to chat before going into a mission, which means we have to have PTT keys setup for that and VON. I'm not sure it's possible but it would be good if there was a way to incorporate a pre-mission voice chat into ArmA so that we didn't need to use TS3 as well but I guess it's not the end of the world if we have to use TS3 pre-mission and VON (although enhanced to be more like ACRE) in-game.
It wouldn't be so bad if a single radio did both, on separate channels, as then the player would have to open the radio UI and change channel to listen/speak on long-range and would then be unable to use short-range, which might prevent too much abuse of the LR and hopefully admins can manage any remaining abuse.
So yeah, I can see that it might be OK ;)
Squad leaders, RTOs, etc obviously still need to be able to use more than one radio at the same time, hence with ACRE we can have a SR on the left ear and a LR on the right, so that would need to be implemented as well. To keep it simple, there's no reason why we couldn't start with just one radio model, with Squad leaders assigned two of them and then maybe later on the devs can develop different models with different characteristics.
Ordinary squad members should not have access to long range radios, that should be reserved for squad leaders, pilots and the like. Ordinary soldiers shouldn't be able to clog up the long range comms and it's the responsibility of the squad leaders to communicate with other squads and command and pass information down.
Oh and move the display of who's talking to the top of the screen, away from the scrolling chat/system messages, as it gets lost in there and we need a clear, quick way to see who's talking without having having to look at all the chat.
I just hope that eventually we won't have some servers using TS3 and others using VON, as I can only have one set of keys mapped to my mouse and hotkeys and it's a pain to have to keep changing depending on what the server's using.
I agree that we don't need to have ACRE per se integrated but that there should be proper radios built-in to the game, so that by default players will have access to them on all missions.
I think if just the basics are added first, so that each player has a short-range radio which can be switched channels to avoid cross-coms with nearby players in different squads, plus long range radios available for squad leaders, then things like signal degradation, terrain masking, realistic looking radio GUIs can be added at a later date when the devs have the time.
Another disadvantage with ACRE is that the missions have to be designed for it and make the radios available. If proper radios were implemented in-game, then every mission would have them available by default, as VON is (but that's buggy so doesn't get used much and people tend to just use TS3 without ACRE to talk but then you have to make channels, move people about and use the whisper plugin to talk across channels).
I like ACRE but have to use the TS3 Overlay plugin to see the names of people talking and it's buggy and doesn't always work, or TS3 crashes, so an in-game implementation of proper radios, with associated radio-quality sound when talking over radios, would be great.
It's still a problem when you don't know who it is that's talking to you though. I'd like to see something like St_HUD highlight the name of whoever's talking, which would help somewhat.
I don't think the Tap on Shoulder is that useful as unless you've pre-agreed what it means no-one would know what you're trying to tell them.
I guess IRL you'd have a number of pre-agreed hand signals and could mouth words to each other but as that's not possible in Arma, I'd suggest something like a text message combined with a tap, so that you type a short message and then when you press the Tap key the player you're tapping sees the message quite clearly in the middle of his screen (or maybe the top but somewhere unmissable anyway).
May 9 2016
I've never liked this either. Let us have a normal, user-controlled save system, so that we can play long missions and save them where we want, to come back to later and have a normal Exit button which asks if we want to save.
Also, get rid of the one save per mission system, so that even if we do save on exiting (perhaps accidentally) we can choose an earlier save to continue from next time.
+1 and have a nice animation of the player pulling himself up, like in Crysis 3, not just have him wiggle around strangely like he's using step over and then suddenly appear up on the ledge.
+1. Allow us to map modifer key+Scroll wheel, so that we can use Alt+Scroll for range up/down as well for example.
I too only use stereo headset and have this problem but immediately, not after 30mins.
Unplayable for me too. I get 8-15fps. Some SP missions are OK and give me 40-50fps but others are as bad as MP and run below 10fps (just happened with Op. Magic Carpet).
Phenom II X4 955 @3.5Ghz, 16GB DDR3 1333Mhz, 6950 2GB
Absolutely agree that you shouldn't be able to spin on your belly whilst prone, any more than you could in real life.
Even whilst crouched you wouldn't be able to spin easily without falling over but you would be able to twist your upper body somewhat, so perhaps this could be implemented so that when crouched and aiming to the left or right, past about 10'o clock or 2'o clock, the characters upper body twists to about up to 8'o clock or 4'o clock, to allow him some ability to protect his flanks (perhaps using freelook but still allowing you to aim down the sights, which it doesn't in A2). To actually rotate his entire body to face behind him though should not be an instant "spin" manouver.
Font looks very bad to me, even in the menu/loading screen, with some characters looking quite faint and hard to read, besides the serious functionality issues that others have mentioned above.