Realized that I had done the initial testing with Epoch mod running.

On retesting without Epoch,the explosion didn't happen.

However, it could clearly be seen that the wheels sunk into the roof when switching from Basic to Advanced Flight mode, and popped out again when switching back.

I believe it is cpbo.exe, I have a "Create PBO" option on the right-click context menu.

Uploaded

It looks like you have to produce a new private key when moving to the new dssignfile, since old private keys produce totally different bisign files when used with the new dssignfile, and vice versa.

Steps I took:

1. Produce new private key using older version of dscreate
2. make bisign using that key and old dssignfile
3. make bisign using that key and new dssignfile.
4. compare bisign files, they are different.

also:

1. Produce new private key using newer version of dscreate
2. make bisign using that key and old dssignfile
3. make bisign using that key and new dssignfile.
4. compare bisign files, they are different.

I have just tried again with some new authorities and a different pbo, and the files that the new version produces do not seem to work on our server, whilst the ones produced by the old version do work.

Same thing happens with Arma2oA

Yes, exactly that.

Hence my feedback suggestion here http://feedback.arma3.com/view.php?id=21925

But apparently not many people agree!

Most likely this is because you won't see anything in the log unless Battleye responds to the chat, and it only does that if there is someone to see the chat message or you chat in Global.

It also doesn't work for missions that already have 10 user radios defined.

Unfortunately that requires edits to each and every mission that is used, I was hoping for something that works without having to do that.

Interesting, I'll take a closer look at that. Thank you.

But I still think something built in would be nicer.

I presume then that you already have a fix for this that works? Perhaps you would care to share the fruits of your labors with the Community?

Fixed in 1.20 stable

Great! Thank you.

Which version will this be available in?

I'm away from home at the moment, but I will see what I can do.

One LAN card with multiple IPs associated with it. This is how most clans dedicated server boxes will be set up.

we have a xxx.xxx.xxx.112/28 IP assignment, so the addresses available on the box for use are 114 (the primary or base IP) through 126.

The Arma 3 server is on 116, but the out of game steam browser shows it as being on 114. I assume that the in-game one also has it on 114, but it doesn't seem to show the IP anywhere.

we have -ip=xxx.xxx.xxx.116 on the command line.

It happens if any player is wearing a wetsuit, not just a diver

Same thing happens with removeWeapon on the main weapon

How are you measuring 40% usage? 40% of 1 core or the whole cpu?

gotmiki, a quote from the link that you posted

"The 25M gives you a zero that roughly matches a 300M zero based upon trajectory and bore access. This is the standard zero and allows the firer to hit a man sized target when aimed center of mass from between 25M out to 350M."

Maybe that is why they chose it for the standard range for the ARCO, RCO and MRCO scopes, which are not the sort of scopes that you would adjust 'on the fly' in a combat situation, hence why they do not have pageup/pagedown adjustments available.

And, just for your information, I do have extensive experience of shooting assault rifles - at 100, 200, 300 and 600 yds.

The bullets trajectory can actually intersect with the sight line at 2 points, not one - once on the way up, and then once again on the way down. This happens anytime that the zeroing is set above a distance that will depend on a few factors, but mainly on the height of the sighting system above the bore line of the gun.

Interestingly, the range of the 'way up' intersection actually decreases with an increase in zeroed range (draw the bullet paths on a piece of paper if you don't follow this) - so it is quite possible for VKing's AG3 to hit accurately at 30m (on the way up) and at 300m (on the way down again) whilst being 'officially' zeroed at 300m.

It may be the bug that only shows lock-on graphics when crosshairs are enabled, but the symbols around the weapon screen change appropriately.

Yes, its still there with 1.14

Still getting this in rpt file

Yes, the original error spam appears to be gone. Now it just needs a different name to distinguish it from the MK200 selencer, perhaps "Sound Suppressor MX-LMG (6.5 mm)"

Thank you.

Still can't test in 1.30

Unfortunately the silencer for the MX SW now has the same display name as the one for the MK200 displayName = "Sound Suppressor LMG (6.5 mm)";

This makes it impossible to place directly in the editor, and editing the mission file to replace "Item_muzzle_snds_H_MG" with "Item_muzzle_snds_H_SW" produces the error "Item_muzzle_snds_H_SW no longer exists".

Thus it has been impossible to verify that the issue has indeed been fixed, as I am unable to spawn a silencer to put on the weapon!

Problem still exists in 1.14

Seems to be fixed.

This seems to have been fixed now, thank you!

Still exists in 1.02 hotfix 110654

The ruins at 229188 on Altis seem to be doing that to me consistantly

Yes, it seeems to be fixed in today's dev release, sorry for the confusion.

On a different matter we really need a better way to switch between dev and main, it takes me 40 + minutes each time to download the differences.

But according to the post by japapatramtara on 17 Oct weapondupe_repro.Altis is fixed, but test_weapons.stratis still seems not to be, unless the fix hadn't made it to the DEV version yet yesterday?

test_weapons.stratis is not fixed in the dev branch.

I believe that makes it total 8 bugs, not 7 as in the title.

Added test_weapons.stratis

Not sure if it the same bug as number 6, but just in case it isn't.

If the weapon is dragged from the vehicle to the inventory slot then it appears that the weapon stays in the vehicle, and is also taken by the player. But the weapon in the vehicle is a 'ghost' and cannot be taken.

If it is dragged to the Backback then all works as expected.

Still happens in 1.14

Still present in 1.24

Haven't noticed this since release, so its probably fixed

On the Marshall at least we could see the props turning, but the wheels seemed to be touching the ground and causing too much friction for the props to overcome.

A manual transition option from water to land would most likely solve the issue.

This is probably no longer an issue

Original folder structure was:

G:\TCAdmin_Game_Installs\82ndab\GameServers

                                           Arma3
                                                SteamApps
                                                         common
                                                               Arma3 - arma3.exe (and all relevent files/folders) here

New structure with steamcmd install

G:\TCAdmin_Game_Installs\82ndab\GameServers

Arma3 - arma3server.exe (and all relevent files/folders) here
     SteamApps
              common
                    Arma3 - needed to update install here for it to work

C:\Program Files (x86)\TCAdmin Control Panel\Monitor\steamcmd\steamcmd.exe +login %STEAMLOGIN% +force_install_dir G:\TCAdmin_Game_Installs\82ndab\GameServers\Arma3 +"app_update 107410 -beta" validate +quit

B3 (bigbrotherbot.com) allows multiple players to admin whilst in game, and can restrict command access to different admin levels.