Piratebear

Just an update. I found out a while ago that sometimes the default option changes to "Disembark" when pointing at a unit but doesn't change back when moving the cursor off. Both in map and outside. The reason is unknown to me. Framerate, latency, no idea. I cannot reproduce this reliably but it happens in approximately one out of four cases. So it happened for me when I was moving the mouse cursor to a location and the cursor path intersected with the collision of the unit.

That's incorrect. I've made my crew disembark just now, a mere minute ago, when trying to give them a move order to a point 200m away on the map as they were engaging an enemy tank. Either your information is plain wrong or the collision radius of selections is overly large on the map. Either way, it is a bug and needs to be adressed if controlling AI is considered to be an actual part of the game. I cannot think of one instance where ejecting crew from a tank via cursor command is logical. Cursor commands are location based commands (go to, attack, watch, get in). There are non-location commands (eject, sit down, assemble UAV) that do not need a mouse cursor and shouldn't be accessible via mouse click on the map. Edit: It is in fact a bug and I've submitted it to the Bug Report section. You're right in that it is intended to work that way. It just doesn't.

Since the dawn of time, at least since Arma 2, the high-priority "Disembark" command for AI subordinates has been a pain for people trying to use the already flawed AI, since it replaces more useful and commonly used commands, such as "Move There" or "Attack" as first highlighted quick-command. It is the end of 2015 now. It's been years and the most useful thing that Arma suggests AI personnel to do with vehicles is to exit them (and die), which speaks volumes about how well the AI is considered to handle itself. We can already disembark all AI crew by pressing 4-1 at any time. No need for a suggested hot slot. Telling AI to move, however, is relatively useful. Because it makes the AI move. Fix this? Edit: Especially because AI cannot be told to enter disembarked vehicles again unless the leader is physically in the same area. Babysitting simulator 3.

Problem: Command entries "Command Forward", "Command Left", etc. are all missing in the keybind menu. They exist as keybinds but do not show up in the Command category as they apparently did in Arma 2. Players cannot rebind them to different keys / unbind them. When using the arrow keys as commander in a tank, they will always issue movement orders to the driver, regardless of intended functionality. Information: • Version: Arma 3 current Steam build 1.50.131969 • Options > Controls > Command • Default keybinds are Left, Right, etc. arrow keys. Reproduction: 1) Bind a function to an arrow key. 2) It will show in red, referencing double-bind "Command [whatever]" - If it shows a different double-bind, remove the conflicting bind and try again. Recommendation: - Add those functions to the "Command" tab in Options > Controls to allow players to change the keybinds.

There are many more bugs but without properly addressing them, they will likely not get fixed.

I recommend you play the tutorial first. It shows you how to place enemies.

Quick update concerning the error report about initialization not working: It works now. Somewhere in between then and now, we have entirely restarted the server and now everything is as it should have been. It shouldn't have happened in the first place but I figure if it's rare enough for nobody to know how to get rid of it without a restart, it's probably not big enough for requiring a fix. I could technically try to recreate the error and we can lock the server for a while for testing purposes so that I can provide detailed information on what caused it but I am not eager enough right now and rather happy it's working again. I appreciate the responses, people. Thanks.

Hi folks. I have an issue I really can't figure out on my own. We're running a dedicated ArmA 2 CO ACE server with MSO 4.55. There have been several minor issues with initialization on 4.5 earlier but they could be resolved by simply reconnecting. What happens now is that when I join, initialization does not complete. To be precise, these modules are the only ones loading (as referenced in the map screen under the MSO tab in reverse order): It does not continue from that point, I can simply move around and play but without the proper modules like logistics, CAS and so on, my ACE Self menu is almost empty. EVERYBODY ELSE gets initialized properly, so I assume this to be a partially client-side issue but I have no idea where to look for a solution. This happens every time I join, even after restarting my game, with different mod setups, on another profile. Since persistent DB is already initialized, I can save my position and have it restored when joining, so it simply doesn't proceed to initialize me after Ambient Life. Potential Cause I don't exactly know what causes this but this happened after I tried starting ArmA 2 CO using SpiritedMachine's ArmA 2 Launcher and at the same time downloading and enabling the 1.0.1.196 beta version of CBA_CO. I ran into problems but I was able to join the server. When joining in a different slot than before, I was asked if I wanted to move to my previous location which I declined. I have never gotten that message afterwards anymore, so this might have been related. I can't tell if initialization has been broken before that but after that point, I definitely couldn't initialize anymore. I tried to start over directly from the Steam Launcher but no matter how often I joined, disconnected and restarted, initialization never proceeded from there - only for me, however. Steps taken Other servers I have joined another MSO server (v4.4) whose initialization did load much faster than ours but it apparently did work without problems. Radio functionality was on the ACRE key instead of the ACE Self key but it was there. Another server running 4.6 worked flawlessly as well. To me, this means I'm facing a unique server-client issue. Other clients on my server don't have it. Other servers with my client don't have it. Only my client on my server. What causes this? --- If anyone has any more ideas or questions, suggest, ask, give me all your ideas, I am running out of them. I have no idea how the scripting works behind the initialization and why it would skip mine but not everyone else's. I'm trying to get around reinstalling ArmA entirely as it is a hassle and is usually the last means as it doesn't work in most cases anyway. Is there a way of some hidden (?) data stored in the database somehow affecting how a player gets initialized? I'll be gladly answering questions about hardware specs, hair colour and favourite dish if you need that to get a picture of the issue. Much obliged. LootFragg Edit: Problem solved after simple server restart. Crappy but, well, tough.

Version: I have no idea where to find the version information but we're talking about the latest A3 Alpha Lite Steam build (stable) for the 16th of March 2013. Summary: Default binding of keyHeliFastForward[] needs to be removed. Issue: There's a whole shitload of bugs, I assume most will be fixed eventually. At least I hope so. Plenty of them are gamebreaking. I don't feel I should request too many fixes since I have never been asked to do so. Also, I have no idea how to post issues on the A3 Feedback page. So I'm typing shit here. One issue pissed me off the most. After three not all too perfect showcase missions I was looking forward to flying the helicopter mission. After setting all keybindings to my liking, I realized that my helo would act weird. I isolated the issue to my right pedal (E) not working properly, instead of turning around the vertical axis, I rotated forward around the horizontal one for no reason which it did even after removing the bind. Checking through the options I did not find a single instance of the E button having a double binding. I needed to load up the config file in an editor to go hunt for the missing variable and I found it. keyHeliFastForward[]={18}; This variable does not show up in the controls section, making it impossible for casual users to change their key bindings if they don't want to dig through config files. The value of 18 equals the E key. This variable has a standard binding and is not changeable via GUI as I explained. Until it gets mentioned in the controls, it should default to EMPTY aka {} to allow for helicopter flight if the E key is bound to anything else but the weird and useless fast forward command that is only used by the AI. keyHeliFastForward[]={}; This is what it has to look like. Make it optional, for fluck's sake. Personal Statement: It is those easy to solve bugs that make me doubt A3 will get rid of most of its issues until the Beta release. It just feels like not many fucks are given and the missions have never been tested before releasing the Alpha. I'm just hoping A3 won't be as quirky as A2. The latter being my favorite war sim game due to the fact that there is little to no competition in that field. But even A3 has the "prone person suddenly standing up" bug that was ultra-annoying in A2 when it popped you out of cover and the same weapon movement restrictions (especially upwards and downwards) that prevent normal weapon behaviour and terrain-adapted combat and are just as messed up as in cheap MMS games like Cahl of Dewty. This is disappointing. It's an Alpha, so we'll see change. But the basis needs to be worked on sooner rather than later. If vehicle combat is relevant, you can't just add in random keybinds. And if it's infantry combat, you need to remove the infantry movement bugs. Rant over. Please move this wherever it belongs.