If you want to play with more realistic in-game radio use TaskForce Arrowhead Radio (TFAR) and a TS3 server.

In T180569#2595065, @Karmavil wrote:

@cryptearth I'm pretty sure your interface size is set to Small.
Go to Options -> Video -> Display and set Interface size to Normal.
Restart the game.

If I set it to small I see the text correctly, no typos.
Sad, because a typo would be a much more easy fix.

Any recommendation to update the title of this report so it reflects better what's the issue?
It is small issue, not a big deal

This seems like a problem on your end - maybe some font issue - as it works fine for me:

Well, I'm not quite so sure about your pessimism - although it seems, by look at https://community.bistudio.com/wiki/Description.ext a simple mission config is not able to override base config.
But that's exactly why this feature request is about: The Van_02 (to avoid confusion with the "small Truck" named Van_01 for whatever reason) comes with what I'm asking for:

1. a simple switch to change between additional cargo vs additional infantry
2. can load cargo as well as can be loaded as cargo
3. can be slingloaded

All I request is to extent this function already in the game to both the Truck and the Offroader - or, what would even be cooler but I guess way more difficult: allow us to override the VehicleTransport config in Description.ext.

I know this is about Mac - hence sorry for hijacking - just wanted to point out: A3 works great with current Proton 9 and Linux 6.8 - I guess your guys decision to drop native and rely on Proton was the right move - as I noticed a bit of increased dev activity and release cycle guess by the freed up resources.
As for all you Mac folks: Although I won't say Mac isn't a good platform for gaming - but its support is even more limited than Linux - why you even use it for gaming, tho?

Give -mod=rf a try - that's the short it got as mod-id. Works on Linux - should work on Mac, too (as Mac is BSD - which is the other major descendant of unix).

*sigh*
That's the kind of topic like those over on the Arch forums shen people try to run Arch on 10+ year old hardware: Get it - your hardware is too old - upgrade your hardware!
A3 always was and sometimes still is the Crysis of the 2010s: It is unoptimized as hell to cause even beefy hardware to perform like crap.
An example: I ran a R9 290X - one of the high-end cards of its time - got roughly 30 fps ob mid settings - upgraded to a R570 - still only managed to get unstable 60 - it takes a freaking xt 7700 and a 5600 to get me stable 90 fps on high - with cranking to very high tanks me back to below - and all that on just 1080p!
Same goes with loading times: As I'm on Linux and ZFS most is cached into RAM - but it still forever on first start to load it all. And A3 is like gta V o that matter: big simple archives to aid with high sequential reads. Ever played killing floor 2 with all its billion of 1kb assets? Enable ANY anti virus on windows and your back at the 80s when we used tape with our C64

It sure isn't impossible - I built a simple config-mod with just this and got what I want:

Well - according to https://community.bistudio.com/wiki/Arma_3:_Vehicle_in_Vehicle_Transport it seems possible to just add the VIV capability to new and existing vehicles. In fact: using the config viewer in the editor the vehicles that can load others do have a VehicleTransport section which contains a Carrier node. And although I wasn't able to confirm it my guess is that most loadable cargo shares some common inherited VehicleTransport/Cargo section.

What proposal you're talking about?

Well, unfortunately I'm not quite sure where to put this or how to load this. Can you give me some hint on how to add this?

So - you do ask for leaning out the window and for a 360? I guess THAT won't happen cause the engine isn't able to handle that - at least for now.
Yes, A3 makes use of skeleton based animations - so same as with "fanc dance moves" it sure possible to "bend" a units body in such a way it would look like someone hanging out the window of a car - but for that first the Offroader would require lower-able windows (otherwise it would break the immersion with no windows at all or leaning "thru" a closed window) which require modification of both the base Offroad as well as the new RF pickup and likely many other vehicles.
One also could argue: What about the non-covered infantry transports like the HEMTT Transport? Why are only the rear facing two spots able to shoot and not all the others?
Same as with my "expansion of the cargo/vehicle loading system" it's quite a lot to ask for - but on the other hand: This game already had 10 years and a lot of mods brought us such stuff (looking at ACE) which the base game just lacks. Why weren't such features implemented? Or will they in A4?
Looking at DayZ: It has base building and all that AltisLife RPG stuff built in - so it shouldn't be hard to port that over to A3 (as, as far as I know, DayZ still uses the RV engine but only the graphics part of the Enfusion).
In the end - we SHOULD expect a combination of A3, ACE and DayZ for A4 - I guess it boils down to: What can we ask from the base game and what will kept as mods?
I would love to use RF the same way as the additional assets from Laws of War - but either I don't or I have to rely on people use the Launcher to connect to my server - and when you start with that you can throw ACE and TFAR into the mix.
I hope all that mod stuff gets sorted out in A4 so they can be loaded at run time instead of having to relaunch the game for every server and rely on the launcher.

Bandicam is still a thing? *2004 flashbacks
Just use OBS ...

Some poeple tho ...
Anyway - what OP is askin for already works:

I doubt this will happen: The base model has six spots: two in the front cabin, two at the rear hatch - and two in the middle. With the original Offroader the middle spots can be used to fire forward while the rear two spots are designed to fire backwards. The new RF variants have just replaced the middle two spots from exterior with interior - likely without touching the two rear spots at all.
If at all a classic leaning out the window would be the way to go. Also: There has to be some balancing: Allowing the RF variant a full 360 from the rear positions would raise the question: What's the point of it then? Just carry two more infantry bt they can't shoot? If you want that extra firepower use a standard Offroad then. It's a balancing tradeof.

google for "nvidia ddu" and clean the gpu driver - afterwards cleanly install the current driver from nvidia.com
give the studio driver a try - according to information on the internet it sometimes can help with such issues
the DxDiag also shows some questionable ideas: a ryzen 5800x but only 16gb of ram and a 3070 with only 4gb of vram? that's fine for DayZ and Arma3 - but that's quite a hefty cpu compared to the rest around it

After searching I found the CfgVehicle pages - and they list the Offroad (covered) / (comms) as VIV-compatible. So I loaded up the editor and played around with them - and was able to fit quite a lot of small crates and even the barrels into them. Also: Although the page lists them as "Cannot be transported" I'm able to load a stuffed Offroad onto a HEMTT Flatbed.
TLDR: The base mechanis I'm asking for are already in the game - but only to a very limited subset - and without actions for loading cargo (currently one can only load "vehicles" as in "cars" - but not as in "crates").
Adding those "loading" actions in a rather generic way seems simple - but it would be nice if this would be added to the game itself without having to script it.
In addition my base request still is: Please also enable it for the regular Offroader (as there's no logic behind why an enclosed vehicle can load cargo while it's not enclosed base model can't) and the small Truck. Maybe it would be possible to have both at the same time: infantry and cargo with shared spots.
Also also: Please add a way to somehow chose the spot a cargo is added to. Currently the auto-add feature aligns the cargo from front to back and in the middle. Playing around with multiple cargo at once there's clearly space for adding two Supply/Uniform boxes.
Another example is when one adds a Basic Weapons first and then a Supply Box the later added supply box turns 90 - but if you remove the first added the supply flips back and you can't re-add the basic.
It's so a nice feature - and as it's part of the game for so long it's sad to see it never got any polish over the years.

Although I'm a bit late to the party: The DxDiag log shows no dedicated GPU in the system - and the iGPU of the 3470 ... welll, I wouldn't even try Minecraft on that. I'm surprised that this system is even able to start up A3 at all ...
Anyway - if you still stuck with that optiplex (a platform that was already old when A3 released) you better get some cheap dedicated gpu. The crash likely happen due to the very small allocated vram of just 32mb. But I doubt that increasing this to the required minimum of 512mb will help - if it's possible to set it.

Wow - never knew it was planed to include actual Java into A3 - it could had offered so much more than what SQF was ever able to accomplish.
Unfortunately we ended up with the very limited extension stuff (although string-only exchange got us quite some cool game modes nonetheless).
As for Reforger/A4 and it's C# inspired scripting: at least for now it still lacks the ability to either connect to a database directly or at least for the server to have something similar to the extension stuff to write an external connector.

This should be closed as invalid.

while running Reforger in admin mode

WHY would anyone ever do such thing? A simple game server should never require to run with elevated privileges. All "run as admin" does is to solve some permission issues - so the actual root cause surely is not Reforger or the workshop but obviously some bad permissions somewhere else.
Also:

a server box

A regular Windows 10 CLIENT should not be run as "server" - not even if you host something on a local system at home over your private internet access. It's fair to assume quite a lot of mis-config along with improper permissions are the real cause to whatever happened.

Well, I had to cut it down to stay in the "not polite - but not yet aggressive enough to reason for a ban"-realm:

Well, as pointed out: This is only a feedback tracker meant for reporting serious bugs, logic errors, and put feature requests. What you encounter is for support - so it would fit way better on the community forums, the steam forums, or maybe even reddit. Posting your issue here is just the wrong spot for it.
This tracker is for some like "I found an issue in campaign east wind, mission 3 on altis, where this and that should happen - but instead X happens" - but not what you reported. You encounter some launch issue caused by some weird setting or launch option - maybe caused by some file loaded along with normal game launch. So you need support - that's nothin for this tracker, hence many post such issues here don'T get any reply at all.
So, what could cause such? I don'T know - as Arma3 still quire LOTs of work although it's released back in 2013.
As for your "fix the game" - well, that'S what steam tries to implement with its "verify game files" feature - but this only works as long as the root cause can be fixed by such action as restoring the default data. But as arma3 was developed with custom content in mind it does search for quite a lot of additional files in lots of locations that are not covered by steams feature to check the integrity. Maybe it'S some weird registry entry somehow checked and executed by the startup code - but as only very few is documented public without knowing the exact stack that lead to this point it's extremely hard to nearly impossible to figure it out - let alone only communicating through this site - and quite bad english from both of us.

have you subscribed to anything in the workshop?

Well, you may can try this:

• clean local appdata: c:\users\<yourusername>\appdata\local - and delete both the Arma3 and Arma3-Launcher folder
• clean documents: c:\users\<yourusername>\documents - and delete all Arma3 folders

Although this is a feedback tracker to report bugs and make requests and not a support forum (that's what the regular community forums, steam foums and maybe even reddit are for): As from another topic: What happens if you double-click the arma3(_x64).exe in the arma folder directly instead of using the launcher?

This looks more like an issue caused by the mission itself depend on some other stuff rather than some issue of arma3 itself. Try to contact the mission author or google the base class name.

You quite obviously didn't got the point at all - but, where should I start?
That weird date format in the bottom right corner? A DxDiag representing its OS as english but then lists quite a lot of german? CloneDVD - something used - IDK - about a decade ago? Doesn't really look legit to me ...
This list of "potential pitfalls and causes" is quite long about "hmm - I only get this issue with arma but nothin' else". Sure, maybe true, and maybe steam thinks all the files match their checksums and hence responds with "all fine" - but just give a thought: "I have some weird issue" and "all is fine" just doesn't add up. And even with all the stuff provided to tinker around to MAYBE figure what MAY could cause your issue - most we can do is just guessing. And yes, maybe you have some neat new hardware under your desk - but that doesn't mean it can't be faulty. I myself use a bad RAM stick for couple of years now - and it sure does bite me in the ass if I access that very spot which unfortunately gets me back some faulty data - but sometimes it's just a matter of "well, that 0 should had been a 1" and "omg - my system is going haywire". So, why you start that fight? I tried to help - and all I get back is some FLAK cause I throw in a few jokes between the lines cause you're using some not so legit stuff that is known for causing exact that kind of issues you experience? WAKE UP KIDDO! If you ask for help and expose yourself to use some not-so-legit stuff - accept you get mocked for it.

Well, just from looking at the few interesting lines I have quite a few ideas what might could be wrong not just with your game but with quite a lot of other stuff, but as I have to trust your reply that "everything is fine": to me the logs don't add up with that statement. If you experience this with arma only the one plausbile cause left is: there's something wrong with your data - either the game files itself - or the stuff you try to load into. Otherwise, if someone would rule out that cause, it's most likely some weird hardware bug, or maybe some of the junk you have on your rig (be surprised by what a simple dxdiag can reveal to someone reading it carefully).
All working perfectly fine but only one application having such weird issues? Nah - doesn't add up well ...

Without any look at the logs this sounds like a hardware issue to me, maybe some bad ram or anything else attached to the board. Give good old memtest a try and have it run at least once the full set of tests. If memtest doesn't show any errors even on multiple runs could be many things from dying/already broken cpu/gpu/hdd/ssd to just corrupted data fixeable by game file validation via steam.

can you provide logs without mods loaded?

Many thanks for that reply with some inside information on what actually happens when #shutdown command is called.
I really much appreciate you even take time to look into it although it doesn't seem to be something caused issues in the past. So I fully understand it to be some very low priority, and maybe it only gets fixed "along the way while fixing other issues".

Although I didn't repeat it for all the tested systems from a short test on my main server it seems the issue is the same for the regular x86 binary.

I also tested this issue on several other environments:

• arch
• debian
• fedora
• gentoo (at least I tried - but compiling the kernel from scratch just took too much effort and time)
• slackware (from which opensuse descends)

All environments showed the very same issue. As I reported this to the ones I asked for testing my short code they agreed upon that if an issue is exactly the same on so many so different styles of linux mainline distros it's most likely the application causing the issue, although without having a look into source noone is able to confirm or deny on that.
I'm sorry I didn't tested on windows or even try some stunt with the DotNET framework - but as my extension is only meant as a small connector to a java backend using some plain sockets for brdiging the gap between SQF and my backend, and it's meant to run on a linux server, and as just setting up the required dev environment to build a small DLL - I just didn't put in the effort. Also, as you mentioned: it does work on windows.

Thank you once again for having at least a look at it.
As promised, I tried to use clang - but, unfortunately, result is the same.

Thank you for your reply.
As one can see, my code does contain a destructor. I also had it tested by some C/C++ devs that it gets called correctly when dlclose() is called. So they suspect that the server shutdown just doesn't call dlclose() on loaded extensions.
I was also able to find another source which mentioned, that dlclose(), according to POSIX standards, is only required to invalidate the given handle. So it's up to runtime if a call to dlclose() actually calls an maybe existing destructor. This source also mentions some difference between using gcc vs clang - but I haven't tried using clang yet, as I just read about it after your reply.
So, the question to the devs is: Is dlclose() called on loaded extensions during shutdown and if it's maybe my way of creating my extension or even my runtime I execute it on to cause my issue, or if the shutdown just doesn't call dlclose() at all.
Anyway, I'll give it a try to use clang and see if this makes any difference. I'll report back after testing.