Onno

Linux support is achieved through using Proton. If you install the BattlEye linux runtime, you should have no problem using Reforger on linux. I much prefer that solution over having an 'experimental' port which is always several versions behind the windows version, meaning that you can't play with your friends if you're on linux, which was the case before the BattlEye runtime was available. As far as I know, the official server is Docker based. See the documentation on the wiki: https://community.bistudio.com/wiki/Arma_Reforger:Server_Hosting

Any news on this issue? It would be nice to be able to host from home, but of course that would require this to possible in the first place. The lack of response by anyone is really disturbing.

I agree that the lack of IPv6 options for hosting your own server is totally unacceptable in 2023. There are many people in the world whom do not have native IPv4 (meaning no CG-NAT etc.) access any more while they do get native IPv6 from their ISPs. I would like to see IPv6 support added as soon as possible.

I was trying to figure out if the statement "vehicles units group player" would get me all the vehicles in a group, but not the soldiers inside them. To test this, I opened up the editor and set up 3 hunters with my player as the group lead in the driver position. I then tried to put this piece of code in the init of my vehicle: _vehicles = vehicles units group player; { hintC format["unit: %1", _x]; } foreach _vehicles; somehow this throws up an error about a missing semicolon (;). 2 quick questions for those who know more about this than I do: 1. Does vehicles accept modifiers in the same way as units does? 2. why is the editor complaining about a missing semicolon? as far as I can see, I've ended every statement with one.

There's some more coding related things I'd like to see: Scripting language: Multithreaded scripting. I mean full concurrency with (pseudo-)threads and some form of atomicity and locking. The time of single threaded programming is over. Not just for the makers of the game, but also for scripters. Some notes: An asynchronous programming system could be implemented on top of this to facilitate less skilled coders. This would probably also require a stronger typing system. The ability to include code libraries in the basic scripting. (so you can include code without CBA) Ability to reference compressed/binarized resources/libraries Add the ability to work with custom markers Scripting: An extension of targetsQuery with type of sensor, or a similar query which shares an array of known targets for a specific sensor on a specific vehicle. Alternate ballistics radar script which tracks rounds instead of creating markers for firing positions. (currently hard to do because attaching markers to bullets is impossible) Thread pool object. Engine: Make it possible to show custom markers Add direction to markers on map in game. Ammo belts with individual rounds. (relevant for MG's and aircraft) Tools: A stand-alone script runner or 2D simulation environment for development purposes (so code testing and profiling becomes a lot easier).

I was wondering in which way any suggestions for Arma 4 (in my case more tech focussed desires for editing and portability) would best be put up for discussion on the forums. Alternatively, is there a feedback tracker/issue board which fulfils this role?

@Dallas Medina I was actually asking where the right place to put up such suggestions, not for the actual suggestions themselves.

Interesting question. I'd like to know as well.

So far, I've encountered a couple of things which I think are very annoying: Lacklustre FM behaviour in general I expected something along the lines of the Helicopter DLC in regard to FM's. Stall behaviour of the new planes in particular is very dissatisfying. Incorrect loadout display in cockpit for most planes No high off bore capability for the SRAAM's (R-73, AIM-9X etc) - The main use of HMD's is exactly this feature. It's quite useless to have HMD's and not have hobm's, even though the jets have the sensors for them in their 3D models. (Maybe add IRST sensor type?) Lock remains in place even when target leaves search volume of the radar. (even in sim/elite difficulty, iirc) Besides these issues, I'd love to see a special render mode for the target camera (perhaps only in it's highest zoom level?). Currently it's very hard to get a lock in time for a single pass attack run in one of the new jets because at the current speeds there's not enough range to acquire the target. I think that the rendering volume of the target camera is small enough that you can ease on render range restrictions. Overall I think that the Jets DLC is not really worthwhile. It feels like you get a couple of jets thrown in, but the improvements to make them work are not there, save for some minor engine tweaks regarding datalinks and sensors, which seems are adaptations of knowsAbout. The FM department is nowhere close to what the Helicopters DLC was for that part of the aviation branch. If the current state is anything close to the release, it is very much a disappointment to me.

A couple of points I would really like to see: Vehicles: I would like to see a couple of 'low tech' vehicles to complement the current top end tanks for each side in the game. (Blue/opfor and independent) An Independent AA vehicle would be nice, this would complement the vehicles for the independent side. Besides the AA vehicles getting more rounded, it would also be nice if there would be some kind of long range AA vehicles as part of the tanks DLC, which would then tie in with the improved sensors that will come with the Jets DLC. Both OPFOR and Independent could use an engineering vehicle. It's really disappointing that this vehicle is only available for BLUFOR. This would complete the arsenal to a more well rounded one for these sides. A vehicle like a Bradley for BLUFOR would be nice. The Marshal is too lightweight to fill in the role of the IFV. Like others have mentioned, the merkava only has the ability to carry passengers in emergency situations. Something like a Namer with a RCWS turret with missiles on the side would be nice to have in this role. Rocket artillery for OPFOR and Independents would be nice. Damage handling I think Arma should have more detailed modelling of parts in terms of what parts are on a tank, as well as how they work. For example, when a fuel tank gets hit, then that fuel tank should get drained, but not the others. Or when the drive shaft gets hit, the tank should get immobilized. I think War Thunder does a great job at modelling the hitboxes for certain key parts, rendering only those functions useless. I'd love to see a similar system in Arma as well. I'd also like to see active protection like Trophy on the modern tanks Physics & environment interaction Tanks need to be less prone to bouncy behaviour. It seems to me that the physics calculations suffer from overflow when dealing with heavy objects. This is not only apparent in tanks, but also in ship behaviour. Maybe we could get a per class physics handling of some kind?

Hmm, I wonder if you can add some kind of damage handling to this. I'd like to know this because objects such as walls etc. don't need any animations etc, but at present they do use the full AI routine (AFAIK). However, if shot by artillery and the like, I'd still like to be able to have them destroyed. It could be usefull for building bases. (in CTI games, for incstance)

No comments on IPv6 at all?

Can you also add support for IPv6 while revisiting the browser? I know it's more of a network related feature, rather than a core server browser related issue, but I think it would make arma more future proof. Ideally with multiple ip binds, so you can have IPv4 and IPv6 coexist for the same server. I think it would also allow me to bypass the restrictions tied to the use of NAT and allow me to remotely admin my servers from work without having to resort to port forwarding. IPv4 has alerady run out of address space and it's not coming back. I know it might take a few years before everyone has it, but it's probably better to build the experience earlier, rather than later. Also, I know that the serverbrowser can already resolve hostnames. Please keep that in the new launcher :)

First question: Can we get captions for our screenshots? I'd really like to be able to annotate the screenshots I put up so they can be put in context. Second question: I'm wondering if the "Play Now" feature would work.How do you picture this feature will work for squads? Does supporting this feature (as a squad) mean that people would be able to play under our banner without our consent, or if it means that they will form ephemeral units which dissolve after completing the game? Will there be any kind of setting allowing us to manage these requests? OTOH, will it be possible to take on 'mercenaries' for just a game?

Just wondering: are you planning to expand the member system to include initiates and junior members? (maybe as ranks or some other mechanism) I also had problems adding my TS server until I tried entering ts3server://ts3.sarisdragons.org. It turns out the protocol has to be specified. Quick question: Isn't the protocol implied by the type of server you indicate you're running?

Hello, I'd like to be able to assign hostnames/URLs to my game servers. Do you think that will become possible at some point? It would enable us to redirect people with just a DNS update, which is convenient.

Thank you for this answer. It was exactly the information I was looking for! :)

I'm trying to write an application which will serve up Squad XML's. It's a bit of an exercise to keep me busy and to stay up to date with my coding skills. (I'm aware of the php implementations, but I prefer .Net) I'm trying to write it in C#. If possible, I'd like to serve up the file from a routed response (MVC4) Would specifying "www.sarisdragons.org/squadname/xml/" be accepable as an input for the game if the response would be text/xml? Does the game accept such a response, or does it need an actual file to download? I also want to know how this is handled for the .PAA file. would specifying "www.sarisdragons.org/squadname/shield/" be acceptable if the response mime type would be application/octet-stream?

Anyone? Maybe this should be moved to scripting instead, if this isn't getting any replies?

QFT I can't stress this enough. Most pubs thrive on people who are occasional players. You can't expect hem to use mods. Mods are a feature for the hard core users, really.

I'd really like to know what the limits to the sizes and weights are for ships. Is there any documentation?

I want a larger sub and make it playable. Something like a mini attack submarine or something. Maybe 4-6x the size of an SDV? How much larger can the engine handle before goes bezerk, forcing it to float?

Good question. How can we make submarines?

That pretty much sums it up. I do get the idea that you're seeing some of these things as new game features while I had them up as thing which are already in the game in some indirect or implicit manner, but in a for which is not controllable in the difficulty settings.

Notes before reading: This post doesn't concern how AI operate, it's about the user interface in arma. Some of it is deduced from how the UI behaves when engaging long range targets and might not be correct. Target acquisition and firing of guided weapons Well for starters, there's no real sensor systems in the game, save for the laser locking system. And that one is a bit of an exception as well. Arma has a very simple way of doing things: everything known to friendly units (in the player's group?) is known to the player. All known targets can be selected and the selection methods are really straightforward. The player is presented with an overview of target information, provided that the B-scope in the game (which most people interpret as being the "radar" is) is turned on in the difficulty settings. There's no middle of the road option. It's either on or it's off. There are no alternatives to this B-scope either. (not that I know of, at least) Now, with all that target data available, the next step in getting that weapon fired is that you can select one of the targets which are presented to you through the B-scope. Currently, this is done through next/previous target (easy lock), as long as the currently selected weapon can potentially lock on to it or the 'hard lock', which lock on to something which is in the centre of the screen (regardless of weapon capabilities I believe?). To aid gameplay, the cursor could have a snap function if it's close enough to a potential target so it's easier to use. You could even define the snap range in the difficulty settings, making it available to all player types as the only means of vehicle target selection. Currently, the instant lock target selection which easy lock provides enables some types of units in Arma, most notably aircraft, to be very effective on the battlefield. Sometimes seemingly beyond what we think that their capabilities should be. These immense capabilities certainly pose a problem for gameplay at times. On the other hand, some other platforms suffer from a lack of effective data and can't be as effective as they should be. In this regard the AA vehicles stand out in their lack of targeting capabilities, seemingly because of their lacking sensor and/or data sharing/weapon guidance abilities. Lets try to see how these platforms would handle attacks: A tank or APC with (a) and without (b) a battle management interface / data link (firing some kind of guided weapon) An attack helicopter (a) and without (b) a battle management interface / data link 1a: The tank uses it's own sensors to acquire targets. It's limited by the sensitivity and field of view of it's own sensors. The inability of the platform to use the 3rd dimension make it impossible to engage at very long ranges unless no obstructions exist. (hardly ever the case) Because the sensors are line of sight based, the unit needs to expose itself to fire at its target. LOAL (Lock On After Launch) is possible as long as the missile has it's own means of acquiring the targets after flying to a designated point in space first, but impractical due to sensor and engagement range limitations typically encountered. 1b: The tank can get information about targets through the interface and can fire from hidden positions, provided that the missile has some kind of pop-up attack mode. It will use it's own sensors if the weapon doesn't use pop-up or LOAL modes. because the battle picture is updated and no predetermined fly-to point is necessary, LOAL is feasible in some situations. The tank can engage at longer ranges as well because of the data sharing. 2a: The helicopter uses it's own sensors to acquire targets. Unguided munitions are dependent on the sensor capabilities of the firing platform. It's limited by the sensitivity and field of view of it's own sensors, but the availability of the 3rd dimension greatly enhances the possible engagement range. LOAL is possible as long as the missile has it's own means of acquiring the targets after flying to a fly-to point in space first. Because of the speed a chopper can move at, a type of LOAL can be successful if the elapsed time isn't too great. There's a chance this will fail because the situation has changed so much that the missile can't acquire its target after reaching its fly-to point. 2b: A chopper will have pretty much the same capabilities as the data link equipped tank with the added benefit of increased speed and engagement ranges. None of these systems have acquisition times which are comparable to the easy lock arma has. The tank might have a hard lock-type solution in direct fire situations. The attack helicopter will probably not. So, what does it show us? In most cases, unguided munitions are dependent on the sensor capabilities of the firing platform. LOAL is a thing in real life, and a data links make it much more deadly and way more effective. However, a LOAL capability depending on operation with a fly-to point / not assisted by a data link is very likely to be much too advanced to implement in Arma's style of play because of interface needs. It's probably also very likely to be perceived as 'unfair' in many cases. Data links are very useful in enhancing SA, but it might be an idea to be able to turn them off in the difficulty settings. The B-scope operation should be dependent on this setting. Sensors define a platform's capabilities to execute attacks using guided weapons if no data link is present My solution would be to introduce different sensor and target selection overviews for vehicle types or specific vehicles, and to make it possible to disable easy lock in the difficulty settings. use hard lock for direct fire and sensor overview with a slewing cursor on a sensor display for indirect and long range fire. The targeting display should be mode dependent. The RWR/Threat indicator could also be made more country/side specific this way. (Reverting into the old B-scope display with the h symbol in easy mode difficulty selection as well) For more realism, a sensor mode of some kind should be introduced for every applicable seat, with the option of having its the next/previous target automatically select targets when using more relaxed difficulty settings, as well as having some scripting capabilities to add or remove capabilities or some kind of dll interface which would make it possible to customize the targeting abilities of vehicles to a higher degree without affecting performance too much. I think the suggestion of adding a RCS value is nice to aid radar type target acquisition, as it adds a variable detection range that is dependent on factors which balance the game a lot if a real radar would be implemented and the functioning of sensors would be made mode dependent. For IR and NVG, a contrast algorithm contrast could be used for minimum lock threshold. Besides this, weapon guidance need to be changed a bit. Certain weapons lack the ability to make use of the very same data sharing which is available to the player, while they need that ability in order to function as they should. There's no non-terminal phase weapon guidance to speak of. Currently all guided weapons are terminally guided autonomously from the moment they leave the firing platform. Long range AA missiles are a very, very poignant example here. The LR AAMs should have the ability to use available tracking data sent by the firing platform until terminal guidance is possible. I think this is exactly why the LRAAMs don't work. I have the strong impression that the game was released with a crucial redesign left out because it didn't make it, while leaving in some systems which more or less still depended on them. I still wonder what the forward scanning display in the ghosthawk was meant to do. It seems that the data input for that display was never finished? Basically, if you have the equivalent of a maverick in this game, you should also have the equivalent of a tor :) (they have about the same lethal range, at least in DCS) Instant IFF The instant IFF should be something that we can turn off in the difficulty settings so it becomes more like a helper, just like IRL. If data-links are off, then IFF should take a couple of seconds. If data-links are on, then it should depend on the status of the target as communicated over the data link. So if someone else has had it locked and ID'ed and it hasn't left the sensor range of any other vehicle of that side's forces, it is known to all of them. Also, IFF should be some kind of ability only certain types of vehicle can perform. Summary Sensors need to be defined more narrowly/clearly for each vehicle in order to define the capabilities of a platform. The usage of these sensors for target acquisition should also be more time intensive in order to prevent missile spam. In lieu of this, We need the ability to disable easy lock, but not without getting a targeting cursor based option to replace it, perhaps with a snap function which would largely emulate easy lock on lower difficulty settings. The B-scope (overhead radar display) could be replaced with weapon specific targeting displays. We need to have the ability to enable or disable data linking between vehicles. We need to change the IFF system to a more sensor and data link minded mode of operations. The reason this should be in the game, and not in a mod or mission file? Because there needs to be a bridge between the Battlefield style KotH crowd and the rest. Arma sucks at the way it deals with mods and this is just not something which should be part of a mission file in my mind. it would slow things down to a crawl because the scripts are so much slower than real code. Only a very small minority plays with mods. PW6 is not the solution and neither is the workshop integration, although that's already a step in the right direction.