Absolutely, this is a must and as described.
When placing AI groups and selecting the "Playable" option, this should automatically create the faction/group/unit/role selection in the initial player selection gui
Alternatively in the faction manager set up you could link the playable group to the playable faction and then use that to populate the player unit selection screen
Alternatively you could extend the group set up in the faction management component to allow you to define each individual in the group and allow a scropt to be attached to that object that we could use to reload the unit with the required loadout etc

It is a game breaker when voip is used for communication in what is supposed to be milsim, where comms is used for coordinating and relaying info etc so thanks for upgrading it

Issue seems to be the voip volume is now tied to the fx volume.
Voip volume should be independant of fx volume, this also includes the direct chat volume which seems to have always been tied to fx volume in Arma3.
Issue it causes is inability to communicate in voip during firefights and when in vehicles or wherever fx is louder than average example when raining.
This is a really major issue for vanilla servers where it is unlikely that all players will be on teamspeak etc

you could do this with a script if you so wish
you could loop this every few seconds to check for requipping

0 = Global
1 = Side
2 = Command
3 = Group
4 = Vehicle
5 = Direct
6 = System

Most vehicles have a radio nowadays so you maybe wouldn't disable that
systemchat certainly shouldn't be disabled, this can be used by the mission Dev and the player cannot chat in this channel anyway

while{TRUE}do
{

sleep 5;
if("radioClass" in items Player)
then
{
     {[_x] radioChannelAdd [Player]}foreach [0,1,2,3];
}
else
{
     {[_x] radioChannelRemove [Player]}foreach [0,1,2,3];
};

};

However a toggleable switch in the description.ext or an additional scripting command would be nice

DisableUseractions TRUE/FALSE
DisableUseractionsGlobal TRUE/FALSE

for configged actions, yes i would agree that would be useful, you could then re enable those actions as and when you see fit and would also allow more possibilities for replacing the actions that are run with something scripted

Upvoted.
HC still needs a lot of work to make it fully automated which is where it should be

this is a media to raise bug reports,
to do this sensibly, there should only be one command in here to be reported and how that command is not working and how to reproduce the issue.

So if you are serious at creating a sensible ticket, strip out all elements of the script until you have as simplified a script as possible highlighting the "supposedly" broken command and then report on that

Take a look at other tickets in this bug tracker for better reference on how to report it in such a way that the devs can look into it

You started your ticket with the line...

Find the Error:

In other words, I am assuming you mean "Can you fix my badly written script for me ?"

This bug tracker is not the place for that, take it to the editing forums

You can take a horse to water but.......
You may find this useful to help you resolve your issue

http://forums.bistudio.com/showthread.php?176096-Zeu-Debugging-Tutorial-amp-Foundation-Template

I voted this down to try and stop folks wasting their time even looking at this.

This is a fine example of what not to do.
This is not a place to try and get folks to debug your script for you.

A casual player who becomes a regular arma player does migrate to teamspeak. The reason being, this for a lot of communities is the central gathering point and when a player finds a community he likes, he gets more involved with it and then ends up on their TS server being sociable.
If that server runs TFAR on one or more of their servers, that then takes him one step further into being part of that community
and you cant run TFAR without teamspeak, (or Teamfart as you put it)
(I have no idea why you have such disdain for teamspeak)

I fail to see what your point has to do with the VOIP issue anyway
VOIP is essential to good comms on vanilla servers which are the first servers newcomers to arma join

A great solution would be an internal TFAR type system, but as VOIP isnt working as it should at the moment, thats just too far fetched to start thinking about

and when voip did work as it should it was okay

Removing VON is not an option for us. It would crucify any public server which is the first point of call for anyone new to ArmA.
It is vital that comms works in the vanilla package. Once a player is established in the ArmA world, typically they migrate to teamspeak anyway. But trying to play organised milsim on a public server when not everyone has teamspeak without VON would be a tragedy.

If you are used to working woth the bug, then you can just about cope. But this big absolutely needs fixing and the sooner the better. The product is broken without it

Very Good Post MDCCLXXV1 and agree withn you 100%

its all to do with the number of players on the server RogerX, not many servers have 40-50 players on at any one time, this is why I suspect some servers report no issues and am not sure if it is actually packetloss, as just before the voip clears up, the voip chat from an individual comes through at an increased speed, like speeding up an old record on the record player. That to me looks more, like a queue of data backing up and then suddenly surging through.
This all started happening when voip started to use the game port, initially it used its own port

@MDCCLXXV1

We've been using that "Fix" if you can call it that for a while now.

It's as if the packets are being queued up (Which doesnt make sense unless they are tcp) then all of a sudden a burst comes through as if you've speeded up the recording, once the burst comes through everything is then fine for that player.
By holding the microphone down you are basically transmitting "Quiet noise" so its not obvious that this occurs.

One other pointer is.

A player suffering from this can have stopped transmitting several minutes before you actually hear their transmission end. This we have verified over and over again via teamspeak.

This has now got to be one of the top priority MP bugs surely.

Take the hit for once and buy a teamspeak license and integrate it into the game. It would be a fantastic feature to have the Task force radio or ACRE system in game with preset voip channels

Type: Public
Branch: Stable
Version: 1.30.127372

VOIP still affected, no improvement

This is getting very tiring now and really needs fixing quickly

This issue may have started when voip was switched from game port + 3 to gameport

This is still an issue, any update on a solution?

More info.
a few days ago, the voip started acting incredibly oddly, it was like slowing down the speed of a record then speeding it up. Every client experienced the same effect.(Kids wont understand this, only knowing about cd's)). This happened once for a few seconds at most. It may have a bearing on the issue raised in this ticket, it may not and it hasn't reproduced itself since.

This is quite a major bug for us and i believe for a lot of others who rely on
ingame VOIP during gameplay
@Ocf, you need to reread my replies. I stated this occurs before the mission starts, and it is for every mission on 2 different servers.
It occurs during unit selection screen before the mission is launched, during the briefing screen and also in game
Typically with somewhere between 30 and 50 players.
It was not a problem before the 118 patch and it still exists in the 122 patch

I've started doing this during the unit selection screen phase before the mission is launched. So that should rule out missions having an effect on this.
I ask all the group leaders, one at a time to continuously speak until i request they stop. Eventually they come through clear and unbroken and this seems to work every time. (Who the hell voted against this ?)

More info:

When a player initially starts to speak, its very stuttery. If the player continues to transmit after about 5 seconds it starts to improve. After 10 seconds in most cases it then comes through clear and unbroken.

It's as if the packets are trying to find the correct path and then eventually they do or the bandwidth they require for von is somehow being adjusted from "not enough" to okay.

This could explain why (am assuming you are testing over lan) you are not seeing this on your test rigs

I don't see any difference.

I'm expecting a busy public server tonight which uses only VON while ingame.
What data do you want collecting ?

I can do wireshark logs etc, any partcular filter you need applying?

I can also do a text log dump from Freds Arma3 server app

This is not restricted to global chat, we use command chat extensively and group chat. This was definitely not an issue before the 118 patch.
Your probably trying to reproduce this issue in a LAN environment, try reproducing it on Dwardens CZ servers in a WAN environment. The higher the player count the more likely this is going to occur. Some players do not suffer, I personally don't but I do have a good connection and plenty of bandwidth, so this may be caused by limited bandwidth on some players.

I have a query on voip too.
Once the server has passed initial data from and too the clients, their IP etc, is von then purely peer to peer or do von packets still pass through the server ?

A member of our community created a clientside addon which rewrites the config values for the flares.
So you can get some use of the flares until B.I sort their act out, I have uploaded a zip file containing
The signed addon and the server bikey.
(It's listed at the bottom of the attachment window)
Or you can download it directly from our website

http://www.zeus-community.net/important/hosted/kls_flarefix.zip

Enjoy !!!

God is this still not fixed, this should be a really easy config value rewrite. Come on B.I

this is a bummer then, all that is needed here is to read the config and return the selected value.

When the admin selects a parameter option, while in the unit selection screen, the remote players all see this change, so the data has already been transmitted before any preinit function has been run.

So I see no issue in declaring paramsarray on the clients prior to the preinit stage.

I don't understand why this variable should be assosciated with Publicvariables

Hi killzone,

My understanding is that the order of initiation is

1. Admin selects mission
2. Description.ext is run
3. Unit selection gui is loaded
4. Admins select param options and players slot up
5. Some B.I.S Magic
6. Players see newly selected param options
7. Admin starts mission
8. cfgFunctions preinit code is run
9. Mission.sqm is run
10. Init.sqf is run and any code other code to the point where they halt at any waituntil or sleep commands
11. Any spawn scripts executed from preinit or init will now run

(So the selected setting is already known by the clients

My point is, that at stage 6, well before preinit is launched the values selected by the admin for the param options have already been sent and received over the network during B.I.S magic at stage 5. This is well before any Publicvariable (As we know it)could be sent. PV's seem to be received a few milliseconds after preinit has finished.

So any argument about this having to be sent by a PV seems sensless.
Why would you need to pv a value that is already available on the remote client anyway and if it is already known, why not make this available for use at preinit.

If B.I do not want to do this then that's their call but assuming that this can only be done as a pv would seem unreasonable based on what I have tried to explain above

Wait a minute, if respawn is set any playable units including ai can be in the group. Losing control to an A.I in an MP environment wrecks the mission.
This wasn't how it used to be. Back an engine version or so it was different.

Single Player functionality and multiplayer functionality requirements are very different.

The answer to all issues shouldn't be left to the mission maker to solve

You need to run an MP community to understand the effects this can have and none of it is positive.

If this was group respawn then it would be correct, but not for base respawn. It simply breaks the command and control.

You need to approach this looking at the bigger picture. Just because your community doesn't use has nothing to do with how others do.
Teams are not only used for giving commands to A.I however it is less likely to use them for players because a player who is set to a team has no way of just communicating with his theam, team leader.

Think about a 12 man squad with 3 teams all using group chat.

Our public server is vanilla and therefore an addon solution is not the answer.
Newcomers to this game need vanilla servers and don't automatically just have teamspeak installed and the loop holes they have to pass through to get addons up and running doesnt help.

To this end voip, which has improved drastically over the years is an excellent solution in the public server environment.

Team functionality is already there and voip is already implemented and capable of differentiating between players in a vehicle , or players in the same group. So to add this last missing channel wouldn't i suspect require too much effort.

@doveman.
Reading between the lines.
You don't use voip
You are in a clan, which presumably runs a private server
This probably means you don't deal with newcomers to the game on a daily baseis who have little if any knowledge of addons.
You also believe voip is fairly poor in quality.

I wouldnt for a second attempt to deter any ones feature request just because I personally wouldnt use it and if i did give my opinion, i would do it based on experience and knowledge.

This could be expanded to any event handler or event script.

For those who have not used cfgfunctions yet, it is the best way to initialise your code

UPVOTED

I think the useage of viewdistance here is the wrong terminology, this is really more about the functionality of a scope or even more correct, the ability of digital camera's or thermal imaging to enhance the detail when zoomed in.

What the video shows is not an increase in viewdistance but the increase in definition that the helo targetting camera has when zooming in. (video 1 min 40)

This is only suitable for digital enhancement technology, normal rifle scopes etc do not have this ability as they use pure optics to "zoom" in

In real life if its foggy or hazy you do not get a clearer view with standard optics.

System should work as follows

Multiple setviewdistance options
for example

Setviewdistance [Base class, distance];
eg

Setviewdistance ["MAN", 2000];
Setviewdistance ["PLANE", 3000];

These should be
a) clientside settings
b) serverside config settings (Which overide clientside settings)
c) Mission designer settings (Which overide serverside settings)

In all cases, these set the Maximum viewdistance when
vehicle unit = class of vehicle

There should also be a setviewdistance slider in the players gui, that allows the player to set a lower viewdistance for that class to avoid fps deterioration on lower performance rigs.

It should never be possible to set a higher viewdistance than the AI on the server or the mission designer settings tio stop players having a massive advantage on viewdistance

I want to bump this. You have a loyal customer base that IS WILLING to test/help solve some of the Multiplayer issues.

Namely
1)FPS degradation over a period of time
2)Low FPS when Ratio of Players : AI is something like 35:150 (Varies from server to server)

We can help find the problems if you help us to do it

Confirmed this is a major bug and needs to be set to the highest priority
I can confirm,

1. there is no .rpt entry
2. This is not a mission.pbo issue or a server config issue
3. It only seems to occur on the dedicated arma3server.exe
4. It did initially occur when the DEV patch 0.75.108541 (Introduction to the Steam Workshop Missions) was released

If you remove all missions from the MpMissions folder, leaving only 1 behind and reboot the server, that mission, which wouldn't load, will now load
It seems to be an issue with the server reading through the MpMissions list when the server is initially rebooted. The reason I suspect this, is that if.......

1. Clear the MpMissions folder, of all missions except 1
2. reboot the server
3. load that mission and then launch it
4. Move one of the missions you initially moved out of the MpMissions folder, back in and there is a fair chance that mission will then load when you next select #missions

maybe a multi level system would be better, superadmin and admin

Superadmin being the server owner
Admin being an admin who logs in via password

and maybe the admin can assign an assistant admin

or superadmin can assign admin assistant, something like that.
Would be exceptionally useful for busy public server

If it was a firewall issue in the server router, then surely everyone should receive a 2500 value for the ping. (This is not the case).
If it were the clients router/firewall then every server would show up as 2500ms for that client. (This is also not the case).

We had this issue on one of our members home dedicated server.
The issue disappeared when he reset the geolocation to the correct values .......
So maybe this is something to do with that, maybe measuring a virtual distance based on these settings and if that is too far, returns the max ping automatically . (Just guessing)

have you tried running your steam client as admin.

Turn off UAC and you will likely find the issue disappears

By localisation. I mean if the AI are not local to you, e.g serverside A.I

This does not occur if they are local

@ Kevsnotrev

The MpMissions is read through by the server when you start the server. I know this because any critical errors in any mission (May be restricted to description.ext only) stop the server from loading. Also if you upload a new mission and change island selection and then back, you can see that mission

So any "delay" would be minimal to gather this info and would really only occur at server start when nobody is on anyway

@doveman. I hadn't thought about automatic listing of any subfolders, thats why I added the comment about a command line parameter/config.cfg entry to point to the folder you wanted loading.

Dwarden stated that sub folders in MpMissions is already scheduled into the build. Hopefully they read this ticket in depth and use some or all of the suggestions for a good implementation

I'm not sure sorting MpMissions by islands as default is a good idea.
Having the ability to "Filter" or "Sort" the mission list and having a "By islands" option would be a much better option.

The though process when selecting a mission is typically

For a vanilla mission (BIS Standard, no 3rd party addons)

1. Type of mission, typically Coop or PVP
2. How many players does it need to support
3. and then a specific mission

Because missions are listed alpha numerically, many servers use a filename convention enforced by the admin for easier sorting and selection

Typically this is........

Type: Co, CTF etc
Maximum No. of players 05, 12 40 etc
Mission name
version

example co 23 MyMission v01

It starts to get a bit messy when 3rd party addons and mods are being used
Typically the "@" sign is used to indicate a 3rd party addon
and if a mod is used, this normally precedes all the other convention tags

for a mission that uses a mod an example would be
ACE co 23 mymission

and for an addon

co@ 23 mymission.

This then allows the admin to select missions in the priority

1. By Mod
2. Mission type
3. With or without other 3rd party addons
4. No. of players it needs to support

That is how it stands at the moment..................

The ideal solution could possibly require
a) Some form of automation in the filename convention
b) Subfolders for Missions requiring mods

____For the filename convention____

The mission editor should have some fields in the editor for defining the mission filename

1. Mission type (Pull down combo, which lists options .. (co, ctf, "User defined" etc)
2. Mod/Addon tag (Combo box reading from the required addons entry in the mission.sqm and also a "user defined" option
3. Mission name - Text entry field
4. Version (Number field)

Maximum No. of players. (This surely can be automated by the engine, "Count PlayableUnits")

Saving the mission then reads from these fields and creates the filename.
This will then create consistency in file naming throughout the community and allow for better filtering/sorting in an MpMission selection screen

By default, if the original mission that is loaded into the mission editor is being renamed, all the files in that mission folder should be copied over to the new mission folder (Not just the mission.sqm As is stands now)

NB>> Spaces in the filename should not be filled by %20 as it currently is now
Not sure how linux handles spaces in filenames, but windows certainly does not have an issue. All the missions on my server have their underscores replaced by a space which creates more readability

____Storing MpMissions in subfolders____

The MpMissions folder should have Sub folders used to save Mod and Addon dependant missions in.
These subfolders should be user defined and automatically loaded by defining the Sub folder name in either the Config.cfg or a command line argument

So for the following example of missions for a mod called @XYZ, the actual mission.pbo path would be

ArmA3\MpMissions\@XYZ\@XYZ co 23 mymission v1 .island.pbo

The config entry or command line would be something like
MissionFolders []={@XYZ};
-MissionFolders=@XYZ;

Allowing for multiple mission folders to be loaded (Similar to -mod=

As for the vanilla missions, you could either
a) always load by default
b) Somehow enable or disable their automatic loading

just seen this, have been asking for such a mission for a long time

This is the only way servers can perform comparisons when discussing optimisation

The main concern for a HC would appear to be a security issue.

here's my viewpoint on that

Either utilise a -HC switch parameter on a dedicated server binary
or create a HC.exe
For either option, do not allow any user input

Possibly
Only allow 1 instance of a HC on 1 server at any time. (If they all have the same USER ID, this checking system already exists)
If multiple HC's are allowed , use a HC password for the server

In the server config have some or all of the following optional settings

Define if HC is allowed
Define HC IP address, if not defined, by default it whitelists the server IP
Define a HC password (Would seem a very easy solution to clients trying to cheat)

As an overview, this should prevent any clients abusing a HC for malicious acts

From the perspective of a server admin (with backend access) cheating, its not even worth considering as there are much easier ways to influence the gameplay without going to the extent of installing a HC

Having the ability to kick a HC may be a worthy condideration for additional scenarios other than a cheating one.

So why not
Define all HC's with the same UserID (if using the rule "Only 1 HC allowed per server" why not?) or have an incremental USE ID for the HC;'s via #userlist
Add an admin command #KickHC

BEserver.cfg can assign max ping and it works

bad idea, group leaders control grunts, grunts do as groupleader says, its better to have a group leader order you to get out of a vehicle if he doesnt want you in it, rather than an admin kick you off the server.

if you dont want teamplay, player single player

quick fix, select your "v" key gets you out of this problem

This could be used as a feature for auto jogging

@AD2001 what colour would you want first then?
RED: enemy ?
Blue: Friendly

Any of the other colours aren't as important, as typically when in game you either

1. If playing as the mission commander, you mark waypoints, LZ's Rz's or Form up points for groups to move too, (typically with a blue dot)

or

2. Mark enemy locations with a red dot

These are the primary reasons for marking a map and need to be done as quickly as possible with the minimum of cycling through the other options

Anything else that needs to be marked is not as time critical

Actually a user setting to organise the order and content of the listing would be by far the best solution

You could then just have a small list of in=game markers that you have defined useful

Basically the latest JIP player becomes the formation leader

This is the same issue as http://feedback.arma3.com/view.php?id=4110

Caused by the latest dev build
BIS are aware, many posts on the forums about it
Most noticeble symptom, spawning as a seagul

a) Using 0 or 1 for the time interval
b) running the code at time 0 or time > 0
has no effect on the following commands.

0 setovercast 1;
0 setrain 1;
0 setlightnings 1;

They simply don't work as expected or used too in A2

I know rain has been switched off for now for some technical reason

wind/fog/waves works as expected

There is no explanation as to what "simulWeatherSync" does and I see no effect from it other than it seems to reduce fog

Using the editor weather sliders does work, except the purposely disabled rain ofcource

this is no longer an issue