In 1.54 RC, "isNumber" returns false for the following config entries in CfgVehicles:

B_Slingload_01_Ammo_F/transportAmmo
B_Slingload_01_Fuel_F/transportFuel
B_Slingload_01_Repair_F/transportRepair
B_Truck_01_Repair_F/transportRepair
B_Truck_01_ammo_F/transportAmmo
B_Truck_01_fuel_F/transportFuel
Truck_02_box_base_F/transportRepair
Truck_02_Ammo_base_F/transportAmmo
Truck_02_fuel_base_F/transportFuel
C_Van_01_fuel_F/transportFuel
I_G_Van_01_fuel_F/transportFuel

Truck_02_fuel_base_F is the parent of O_Truck_02_fuel_F that commy2 tried with.

Using getNumber, the transportFuel value of Truck_02_fuel_base_F is reported as 1e+012.

Just nothing this here in case people search here for the problem:

The problem has been fixed in CBA 2.2.0 and we hope to release the updated CBA before 1.54 goes stable.

This issue is still present in the 1.42 version of the Linux dedi.

What happens is that the dedi appears to reads the squad logo file name from the XML (eg <picture>mysquad.paa></picture>) and then tries to load that file from the server's current working directory instead of reading it from the web server where the squad xml file came from.

For example, if the A3 server executable is in /opt/arma3 and you launch the server from that directory, then one can see(*) the server trying to load the file /opt/arma3/mysquad.paa.

In the server log output you then see the following error messages:

    Can't find real path "mysquad.paa": "No such file or directory"

    2015/04/11, 12:00:22 error: Invalid file extension "mysquad.paa".

(*) It is "seen" by running the A3 server executable through the strace debug tool and looking at the strace log output.

Duplicate of #0019945.

It is not very well documented, but the Linux server outputs the "RPT log" messages on stdout/stderr. (The BIS Linux game servers have done this since back in the OFP days)

Solution: redirect stdout and stderr to a log file of your choosing. For example:

./arma3server -port=$port -pid=ServerRunning -cfg=basicServer.cpp -config=server.cpp "${mods}" >>log.${pid}.txt 2>&1

So: not a bug, but Linux dedis being "different". :-)

The pop-up training targets in the "Common Denominator" mission work just fine with A3 1.24 and CBA A3 RC2 (1.07).

CBA by itself does not "cause this behavior".

CBA team here. There actually is (now: was) an issue with CBA where an old weather sync system that was supposedly disabled for ArmA III was not quite fully disabled. This caused the rather abrupt change in the nextWeatherChange value on the server as seen in Jman's server log excerpt above at around 218.322 where nextWeatherChange goes from 1732 to 4. We have fixed that problem for an upcoming update of CBA for ArmA III.

With that out of the way, the "weather divergence" between server and client can be observed even with a vanilla, no-mods A3 setup. However, the difference in weather change values is not as abrupt. (You can actually see it in Killzone_Kid's logs above.) There's more on this if you look at ViperMaul's comments for the CBA issue here: https://dev.withsix.com/issues/74300#note-7