Problem with custom "IVC Client.ini" … i'm lost
-
I think I have found a solution for this problem, or let’s call it a workaround.
If you set “outsiders = all” in the IVC Client.ini file, the AWACS/ATC operator has to be at least in the 2D-World and connected to the multiplayer-game. Then the other clients won’t crash and you can transmit as ATC/AWACS via IVC with no range limitation.
Find below a step by step description of my successful testing today. I will test the whole thing next week with our squadron and hopefully it will also work with more than just two clients (as in my testlab).
(((- set “outsiders = all” in the IVC Client.ini file
- start IVC Cient (standalone)
- start BMS and connect to the host, but DO NOT select “Enable IVC” in the Comms window
- select the online-TE and go to the 2D-World
- leave BMS in the 2D-World
- start F4AWACS)))
Cheers
PitbullI’m afraid this procedure is not a cure-all for the IVC-Problems. Yesterday we had serveral clients whose IVC Client kept crashing
-
The procedure you have used is outdated and I have posted a new procedure in a later post. Sorry for the misleading two procedures (I have deleted the old one now).
The correct procedure is as follows:
- set “outsiders = all” in the IVC Client.ini file
- start BMS and connect to the host,you have to select “Enable IVC” in the Comms window
- select the online-TE and go to the 2D-World
- change to the IVC client and select the option “Force Local Control”. The IVC client will disconnect automatically. Connect again and set the desired frequencies again.
- leave BMS in the 2D-World
- start F4AWACS
Cheers
Pitbull -
Is that the one you gave to Dro16?
I also have now the radio-log.txt from one Client who crashed:
21:12:30: New TS volume_modifier for radio[0]: -1.0 (raw 1522) 21:12:30: New TS volume_modifier for radio[2]: -1.0 (raw 1522) 21:12:30: New TS volume_modifier for radio[1]: 1.0 (raw 1087) 21:12:35: OnF4CheckTimer: BMS is taking over at this point... 21:12:35: ProcessAnyUpdates: re-connect because of IP address - is in BMS(xxx.xxx.xxx.xxx) was in client(Enter IP) 21:12:35: ProcessAnyUpdates: re-connect because of nick - is in BMS(Bluebird) was in client(noname) 21:12:35: ProcessAnyUpdates: handling the re-connect 21:12:35: ProcessAnyUpdates: ui controls updated host: xxx.xxx.xxx.xxx, nick: Bluebird 21:12:35: ConnectToHost: host: xxx.xxx.xxx.xxx, nick: Bluebird 21:12:35: ConnectToServer: server handle ID[0] = 1, host(xxx.xxx.xxx.xxx) nick(Bluebird-UHF) Port(9987) Pass() 21:12:35: Connect status changed: status = 1 error = 0x00000000 on conID[1] 21:12:35: SetConnectionStatus: handleID(1) status(1) theRadio(0) 21:12:35: SetConnectionStatus: UHF initiating connection to server side 21:12:35: ConnectToServer: successful return from ts3client_startConnection 21:12:35: PushTalk: PRESS on radio(0) 21:12:35: PushTalk: RELEASE on radio(0) 21:12:35: ConnectToServer: successful return from ts3client_flushClientSelfUpdates 21:12:35: Radio[0] - Toggled VAD off. 21:12:35: Connect status changed: status = 2 error = 0x00000000 on conID[1] 21:12:35: SetConnectionStatus: handleID(1) status(2) theRadio(0) 21:12:35: onNewChannelEvent: conID[1] chID[1] parentID[0] 21:12:35: onNewChannelEvent: New channel: name (Default Channel), ch ID[1] 21:12:35: Connect status changed: status = 3 error = 0x00000000 on conID[1] 21:12:35: SetConnectionStatus: handleID(1) status(3) theRadio(0) 21:12:35: SetConnectionStatus: UHF connected and visible server side 21:12:35: New client: Bluebird-UHF 21:12:35: onNewChannelEvent: conID[1] chID[6] parentID[0] 21:12:35: onNewChannelEvent: New channel: name (359300), ch ID[6] 21:12:35: Connect status changed: status = 4 error = 0x00000000 on conID[1] 21:12:35: SetConnectionStatus: handleID(1) status(4) theRadio(0) 21:12:35: SetConnectionStatus: UHF established, startup for VHF 21:12:35: ConnectToServer: Radio[0] indicates connected 21:12:35: ConnectToServer: server handle ID[1] = 2, host(xxx.xxx.xxx.xxx) nick(Bluebird-VHF) Port(9988) Pass() 21:12:35: Connect status changed: status = 1 error = 0x00000000 on conID[2] 21:12:35: SetConnectionStatus: handleID(2) status(1) theRadio(1) 21:12:35: SetConnectionStatus: VHF initiating connection to server side 21:12:35: ConnectToServer: successful return from ts3client_startConnection 21:12:35: PushTalk: PRESS on radio(1) 21:12:35: PushTalk: RELEASE on radio(1) 21:12:35: ConnectToServer: successful return from ts3client_flushClientSelfUpdates 21:12:35: Radio[1] - Toggled VAD off. 21:12:35: Connect status changed: status = 2 error = 0x00000000 on conID[2] 21:12:35: SetConnectionStatus: handleID(2) status(2) theRadio(1) 21:12:35: onNewChannelEvent: conID[2] chID[1] parentID[0] 21:12:35: onNewChannelEvent: New channel: name (Default Channel), ch ID[1] 21:12:35: Connect status changed: status = 3 error = 0x00000000 on conID[2] 21:12:35: SetConnectionStatus: handleID(2) status(3) theRadio(1) 21:12:35: SetConnectionStatus: VHF connected and visible server side 21:12:35: New client: Bluebird-VHF 21:12:35: onNewChannelEvent: conID[2] chID[5] parentID[0] 21:12:35: onNewChannelEvent: New channel: name (138050), ch ID[5] 21:12:35: onNewChannelEvent: conID[2] chID[8] parentID[0] 21:12:35: onNewChannelEvent: New channel: name (138100), ch ID[8] 21:12:35: onNewChannelEvent: conID[2] chID[10] parentID[0] 21:12:35: onNewChannelEvent: New channel: name (126200), ch ID[10] 21:12:35: onNewChannelEvent: conID[2] chID[16] parentID[0] 21:12:35: onNewChannelEvent: New channel: name (133150), ch ID[16] 21:12:35: onNewChannelEvent: conID[2] chID[18] parentID[0] 21:12:35: onNewChannelEvent: New channel: name (138200), ch ID[18] 21:12:35: Connect status changed: status = 4 error = 0x00000000 on conID[2] 21:12:35: SetConnectionStatus: handleID(2) status(4) theRadio(1) 21:12:35: SetConnectionStatus: VHF established, startup for GUARD 21:12:35: ConnectToServer: Radio[1] indicates connected 21:12:35: ConnectToServer: server handle ID[2] = 3, host(xxx.xxx.xxx.xxx) nick(Bluebird-GRD) Port(9989) Pass() 21:12:35: Connect status changed: status = 1 error = 0x00000000 on conID[3] 21:12:35: SetConnectionStatus: handleID(3) status(1) theRadio(2) 21:12:35: SetConnectionStatus: GUARD initiating connection to server side 21:12:35: ConnectToServer: successful return from ts3client_startConnection 21:12:35: PushTalk: PRESS on radio(2) 21:12:35: PushTalk: RELEASE on radio(2) 21:12:35: ConnectToServer: successful return from ts3client_flushClientSelfUpdates 21:12:35: Radio[2] - Toggled VAD off. 21:12:35: Connect status changed: status = 2 error = 0x00000000 on conID[3] 21:12:35: SetConnectionStatus: handleID(3) status(2) theRadio(2) 21:12:35: onNewChannelEvent: conID[3] chID[1] parentID[0] 21:12:35: onNewChannelEvent: New channel: name (Default Channel), ch ID[1] 21:12:35: Connect status changed: status = 3 error = 0x00000000 on conID[3] 21:12:35: SetConnectionStatus: handleID(3) status(3) theRadio(2) 21:12:35: SetConnectionStatus: GUARD connected and visible server side 21:12:35: New client: Bluebird-GRD 21:12:35: onNewChannelEvent: conID[3] chID[2] parentID[0] 21:12:35: onNewChannelEvent: New channel: name (243000), ch ID[2] 21:12:35: Connect status changed: status = 4 error = 0x00000000 on conID[3] 21:12:35: SetConnectionStatus: handleID(3) status(4) theRadio(2) 21:12:35: SetConnectionStatus: GUARD established; now fully connected 21:12:35: ConnectToServer: Radio[2] indicates connected 21:12:35: New Intercom volume for device[0]: 2.0 (raw 861) 21:12:35: JoinNewChannel: 359300 on radio[0] initially using ChID[6] 21:12:35: JoinChannel[0](cd: 6, r: 0) 21:12:35: JoinChannel: moving radio[0]into channel[6] 21:12:35: JoinNewChannel: 138100 on radio[1] initially using ChID[8] 21:12:35: JoinChannel[2](cd: 8, r: 1) 21:12:35: JoinChannel: moving radio[1]into channel[8] 21:12:35: JoinNewChannel: 243000 on radio[2] initially using ChID[2] 21:12:35: JoinChannel[4](cd: 2, r: 2) 21:12:35: JoinChannel: moving radio[2]into channel[2] 21:12:35: ProvideStatusUpdates: set clientactive flag 21:12:35: ProvideStatusUpdates: set connected flag 21:12:35: New client: Fatality-VHF 21:12:35: New client: Bluebird-VHF1 21:12:35: New client: Sledge-UHF 21:12:35: New client: Caesar-UHF 21:12:35: New client: Joker-UHF 21:12:35: onClientMoveEvent: on conID[2] successful chan move from chID[1] to chID[8] 21:12:35: New client: Fatality-UHF 21:12:35: New client: Ziri-UHF 21:12:35: New client: Paladin-UHF1 21:12:35: New client: Bluebird-UHF1 21:12:35: New client: Sneakpeek-UHF 21:12:35: onClientMoveEvent: on conID[1] successful chan move from chID[1] to chID[6] 21:12:35: New client: Sledge-GRD 21:12:35: New client: Caesar-GRD 21:12:35: New client: Joker-GRD 21:12:35: New client: Fatality-GRD 21:12:35: New client: Ziri-GRD 21:12:35: New client: Paladin-GRD1 21:12:35: New client: Bluebird-GRD1 21:12:35: New client: Sneakpeek-GRD 21:12:35: onClientMoveEvent: on conID[3] successful chan move from chID[1] to chID[2] 21:12:47: onClientMoveTimeoutEvent: connection lost for Bluebird-GRD1, ID(351293449678356508) 21:12:47: onClientMoveTimeoutEvent: connection lost for Bluebird-UHF1, ID(349757431934353436) 21:12:48: JoinNewChannel: 9999 on radio[0] initially using ChID[0] 21:12:48: createChannel request sent for 9999 on radio[0] 21:12:48: onNewChannelCreatedEvent: name 9999 chID[30] on conID[1] 21:12:48: CTeamSpeak::MuteRadioVolume muting UHF 21:12:48: New TS volume_modifier for radio[0]: -40.0 (raw 10000) 21:12:48: JoinNewChannel: 9999 on radio[1] initially using ChID[0] 21:12:48: createChannel request sent for 9999 on radio[1] 21:12:48: onNewChannelCreatedEvent: name 9999 chID[21] on conID[2] 21:12:48: CTeamSpeak::MuteRadioVolume muting VHF 21:12:48: New TS volume_modifier for radio[1]: -40.0 (raw 10000) 21:12:49: onClientMoveTimeoutEvent: connection lost for Bluebird-VHF1, ID(350596771623206940) 21:13:08: JoinNewChannel: 307300 on radio[0] initially using ChID[0] 21:13:08: createChannel request sent for 307300 on radio[0] 21:13:08: onNewChannelCreatedEvent: name 307300 chID[31] on conID[1] 21:13:08: New TS volume_modifier for radio[0]: 6.0 (raw 100) 21:13:08: CTeamSpeak::UnMuteRadioVolume un-muting UHF 21:13:08: JoinNewChannel: 1234 on radio[1] initially using ChID[0] 21:13:08: createChannel request sent for 1234 on radio[1] 21:13:08: Channel ID 30 deleted by Server (64424509440) 21:13:08: CTeamSpeak::WipeChannelName removing Channel Map[0][9999] - 30 21:13:08: onNewChannelCreatedEvent: name 1234 chID[22] on conID[2] 21:13:08: Channel ID 21 deleted by Server (64424509440) 21:13:08: CTeamSpeak::WipeChannelName removing Channel Map[1][9999] - 21 21:13:08: New TS volume_modifier for radio[1]: 6.0 (raw 100) 21:13:08: CTeamSpeak::UnMuteRadioVolume un-muting VHF 21:13:08: CTeamSpeak::MuteRadioVolume muting GRD 21:13:08: New TS volume_modifier for radio[2]: -40.0 (raw 10000) 21:13:28: onNewChannelCreatedEvent: name 240900 chID[32] on conID[1] 21:13:36: onNewChannelCreatedEvent: name 377200 chID[33] on conID[1] 21:13:36: Channel ID 32 deleted by Server (64424509440) 21:13:36: CTeamSpeak::WipeChannelName removing Channel Map[0][240900] - 32 21:13:44: onClientMoveEvent: on conID[2] successful chan move from chID[16] to chID[8] 21:13:44: Channel ID 16 deleted by Server (64424509440) 21:13:44: CTeamSpeak::WipeChannelName removing Channel Map[1][133150] - 16 21:14:29: ProvideStatusUpdates: connected but host tells us time to quit 21:14:29: CTeamSpeak::Disconnect 21:14:29: isConnectedToServer: status: 4, conID[1] 21:14:29: onClientMoveEvent: on conID[1] successful chan move from chID[31] to chID[0] 21:14:29: Connect status changed: status = 0 error = 0x00000000 on conID[1] 21:14:29: SetConnectionStatus: handleID(1) status(0) theRadio(0) 21:14:29: SetConnectionStatus: UHF disconnect status registered 21:14:29: Disconnect: UHF disconnected 21:14:29: isConnectedToServer: status: 4, conID[2] 21:14:29: onClientMoveEvent: on conID[2] successful chan move from chID[22] to chID[0] 21:14:29: Connect status changed: status = 0 error = 0x00000000 on conID[2] 21:14:29: SetConnectionStatus: handleID(2) status(0) theRadio(1) 21:14:29: SetConnectionStatus: VHF disconnect status registered 21:14:29: Disconnect: VHF disconnected 21:14:29: isConnectedToServer: status: 4, conID[3] 21:14:29: onClientMoveEvent: on conID[3] successful chan move from chID[2] to chID[0] 21:14:29: Connect status changed: status = 0 error = 0x00000000 on conID[3] 21:14:29: SetConnectionStatus: handleID(3) status(0) theRadio(2) 21:14:29: SetConnectionStatus: GUARD disconnect status registered 21:14:29: Disconnect: GUARD disconnected 21:14:35: OnF4CheckTimer: BMS is releasing client control now...
-
The procedure you have used is outdated and I have posted a new procedure in a later post. Sorry for the misleading two procedures (I have deleted the old one now).
The correct procedure is as follows:
- set “outsiders = all” in the IVC Client.ini file
- start BMS and connect to the host,you have to select “Enable IVC” in the Comms window
- select the online-TE and go to the 2D-World
- change to the IVC client and select the option “Force Local Control”. The IVC client will disconnect automatically. Connect again and set the desired frequencies again.
- leave BMS in the 2D-World
- start F4AWACS
Cheers
PitbullHi Pitbull,
i’m answering here so all can benefit from the discussion and maybe a dev can shed some light on it.
What i don’t understand: yet the ATC IS actually connected to the online mission in BMS, that means somewhere is his/her callsign name in the ATO of the TE.
So, why using “outsiders=all”? As far as i understand this option is only for clients NOT connected to the TE. In our case this option causes several IVC Clients to crash, wouldn’t it be smarter to use the “outsiders=awacs” for the ATC instead?
And for the normal pilots there has to be not an “outsider”-option at all as the ATC is connected to the TE.
The BMS Manual is very cryptical for some IVC options, hopefully there will be an update.
-
I agree that the option “outsiders=all” actually makes no sense if you were connected to an online mission. I have never tested the “new” workaround without the “IVC Client.ini” file present, since it always works as desired the way I described it earlier.
For me the option “outsiders=awacs” is not very useful, simply because I don’t want to have any range limitation as AWACS operator, so it’s easier for all pilots (they always can hear AWACS) and the TE builders (they actually can place the AWACS aircraft wherever they want).
Maybe I can do some tests in my LAN with the different IVC Client.ini settings and for sure I will post my results here.
Did you also have IVC Crashes with the newest procedure?
Cheers
Pitbull -
Yeah, the BMS Manual is somewhat confusing there (could also be just my limited english grammar knowledge) and IMO contradictory.
We have still some clients with crashing/re-connection IVC Clients. Some of them “cured” it by commenting the “outsider”-line with hashtag to deactivate this option. But that means we have a mixed IVC operation config-wise, IMO another malfuntion source.
I hope the IVC Pro’s from BMS can help here, now that the licensing case is closed and 4.33.1 on short final they will have more time to check our issues.
-
As a member of the same VFW, “Reaper58th” is talking about, let me try to contribute with some comments :
concerning the BMS manual there is an interesting example on page 14-259 :
_Here’s a bit larger example of ini file content:An ini file with a variety of switches and options
duplex = 0
server = 192.168.0.132
nickname = viper
connect = 1“Front pink input” in mixer, front mic input jack on SPEAR machine
tone = loop:3
loudness = 1
uhf = 307300
vhf = 1234
key-hook = 1
quick = 1
hum-level = -18
hiss-level = -18
toneVol = +6
uhfVol = +2
vhfVol = -1
outsiders = awacs
log = 1Note that a line prefixed with a # is treated as a comment and ignored by the client. What the other lines do is:
disable the duplex option (yes, I know that’s off by default so same as line not being there but this is an example of how you could quickly turn this capability on and off…simple edit to “1” for the value and duplex would be then set to on);
sets localhost to the place to look for a server to connect to (yes, “localhost” works fine for this if you have a server running on the same machine as the client);
sets my nickname;
sets the app to try a connect on start-up;
enables sidetone using the loopback mechanism and since I’m on Win7 for this machine it specifies the 4th (zero base counting remember) device in the record mixer set as the one to turn on for transmit feedback to yourself;
enables the audio compressor loudness;
sets initial UHF frequency to 307.300MHz;
sets initial VHF frequency to 1234 (which is the UI default);
sets the key hook switch that means that , and key presses are sent to the app regardless of whether it has focus until you enter 3D world in the game (at which point this hooking is suspended to allow you to use those keys for in-game functions);
enables the simulated have quick channel hop clicks;
sets the hum volume to -18dB…rumor has it this is the “best” choice;
sets the hiss volume to -18dB…rumor has it this is the “best” choice here too;
sets the sidetone volume to max (-6dB to +6dB range of adjustment);
sets the UHF volume to 2dB above default;
sets the VHF volume to 1dB below default;
makes all players on my voice server and frequency who are connected to my network game but not in 3D world sound like they are transmitting from the AWACS jet while I am in 3D world; and
enables debug logging to a file called radio-log.txt (also found in the IVC client binary’s directory).
F1
F2
F3
F2_in conjunction with the list printed on page 14-252 ….
The other possible choices for the switch argument are:
None
This means that you will not hear any remote player unless they are connected to your network game and they are also in the 3D world on the same voice server and frequency as you.
Awacs
This choice is similar to the default seat option. The only difference is that instead of using the position of the flight the remote player has selected for radio sound quality calculations, the position of the AWACS assigned to cover your flight is used. If no AWACS is assigned for the mission and this option is selected then the range used will be nominal (i.e. you hear little to no signal degradation).
all
This means that you will always hear any remote player regardless of whether they are even running Falcon4 BMS or not with the only proviso being they are connected to the same voice server and speaking on a frequency to which you are tuned of course.
Example: “<yourinstallpath>:\FalconBMS\Bin\x86\ivc\IVC Client.exe” /o awacs</yourinstallpath>… it leaves the impression (at least to me), that the following should work: (in theory !)
Summarized:
- “<yourinstallpath>:\FalconBMS\Bin\x86\ivc\IVC Client.exe” /o awacs - for everybody!
- human ATC connects to the game in 2D only (according procedure by PITBULL first with selecting the option of IVC, then disconnecting by selecting “force local control” and then reconnecting just to the IVC server
- there should be NO awacs tasked within the game and no open seat of any unused aircraft so the game does not put the human ATC into this position (maybe ? - I’m not sure this really matters…)
result: (hopefully) everybody can hear human ATC without range problems while still having the new 4.33 IVC options for themselves
I will do some checks this weekend and report any results
Sp.</yourinstallpath>
-
All the discussion around this is because of one bug in 4.33 that is fixed in 4.33.1 (seemingly at least based on testing so far).
Using “outsiders = all” and then connecting to the network game then forcing local control on the client is semantically equivalent to “outsiders = awacs” and having a mission with no AWACS flight in it to play.
My advice for 4.33: if you want someone talking to the 3D world but that person is looking at F4AWACS or some other foreground app other than the game itself, start IVC for everyone with the “awacs” option, have the person that won’t join 3D world connect to the network game and stay in 2D but put the game into the background (ALT TAB) then force local control on their IVC client only. Yes, that means in cases where there is an AWACS it’s possible that signal propagation issues may mean players in 3D don’t in fact hear your outside person talking but I’d argue that’s realistically what would happen anyway real-world. If you want range and LoS etc limitations lifted, either don’t include an AWACS mission in the TE/CAMP or just wait for 4.33.1 and start using “all” again then.
I have to chuckle when I hear suggestions that the manual text is cryptic…ya know it was longer but I was told it was too much. Indeed the reason it is split in the manuals now is because the doc folks did not want the entire thing inline in the main body of the text. Be that as it may…
I’m happy to try and clarify if you have specific questions about the text. I’m NOT going to bother trying to further explain the bug and/or why the kinds of workarounds being tried right now do what they do…but please keep in mind that’s only because I expect 4.33.1 to be out there soon and for all that discussion to become moot immediately.
-
All the discussion around this is because of one bug in 4.33 that is fixed in 4.33.1 (seemingly at least based on testing so far).
I KNEW IT! :mad::mrgreen: Goddamit, can you imagine how many headaches i had because i thought i’m already too stupid to get the .ini right? :uham:
One of our problem is our ATC Lady is not only responsible for the tower but also for Range Control and AWACS sometimes so she hast to kind of “follow” us on our mission from T/O to TGT to LDG so the “ALL” option would suit us perfectly, but we can live some weeks more with the bug …
Thx for clarification, we’ll try your suggestion and hope for a soon release.
-
Additional question: in the .ini, can i use the # AFTER the config line to leave some comments when sharing the ini to my squadron collegues?
Like that:
outsiders = awacs #squadron standard - DO NOT CHANGE! -
-
outsiders = awacs #squadron standard - DO NOT CHANGE!
…does not work how you were hoping.
-
Umm, I said it was a bug a while ago – sorry if that wasn’t clear before.
Hm, must have missed that. Anyway, it’s clear now.
Is there another way to get comments in the ini-file itself? No biggie if not, i have to make a small doc then.
-
You mean other than what is already documented for inserting comments?? No, sorry – just the one way.
-
Still having clients crashing with “outsiders = awacs”, no luck. Unfortunatly no logfile. Guess we have to stick without “outsiders” until 4.33.1.
-
I can say “outsiders” works perfect now, thx for the bugfixing and ongoing support!
-
Well, thank goodness for that!
-
I can say “outsiders” works perfect now, thx for the bugfixing and ongoing support!
Hmm, with us it doesn’t seem to work?
All our pilots plus myself as ATC have outsider=all in their IVC Client.ini. I place myself in Awacs seat in 2D but don’t go into 3D. If I understand the manual and the explanation in this topic correctly, as long as I’m not in 3D, and all our outsiders-values are set to all, they should hear me fine, no?
However, they here me 4 to 5 by 5 once airborne and relatively close the the Awacs AI in 3D. But from 100NM on the ground at the airbase they here me 0 to 1 by 5. -
The purpose of “all” is to allow voice from people who are using the client outside the context of being connected to a Falcon4 session to reach your ears. If you choose “all” and then connect to the game anyway then you get “seat” behavior in terms of how signal propagation works. Thus, in the scenario you describe, I would expect players on the ground at long distance to be unable to hear or reach AWACS clearly.
Keep in mind that the overall design intent is to try and replicate real world radio performance – or at least provide a plausible model thereof. In the real world you probably would not get far distant air stations easily on aviation radios and looking at the math for the signal propagation model in the code you certainly won’t. Once the antenna height of the players remote from the AWACS start increasing, and any LoS issues are resolved as a result, then I’d expect signal to start getting through crackly at first and strengthening as player altitudes climb.
In other words, I think it’s working as designed from what you say.
If you want omnipotent signal strength AWACS the way to do that would be to start the IVC client for the AWACS player before the game, set it for “local control”, then join the game having made sure that all other players have “all” set in their client settings. I would expect that to turn off the signal propagation model for the AWACS player.
-
The purpose of “all” is to allow voice from people who are using the client outside the context of being connected to a Falcon4 session to reach your ears. If you choose “all” and then connect to the game anyway then you get “seat” behavior in terms of how signal propagation works. Thus, in the scenario you describe, I would expect players on the ground at long distance to be unable to hear or reach AWACS clearly.
Keep in mind that the overall design intent is to try and replicate real world radio performance – or at least provide a plausible model thereof. In the real world you probably would not get far distant air stations easily on aviation radios and looking at the math for the signal propagation model in the code you certainly won’t. Once the antenna height of the players remote from the AWACS start increasing, and any LoS issues are resolved as a result, then I’d expect signal to start getting through crackly at first and strengthening as player altitudes climb.
In other words, I think it’s working as designed from what you say.
If you want omnipotent signal strength AWACS the way to do that would be to start the IVC client for the AWACS player before the game, set it for “local control”, then join the game having made sure that all other players have “all” set in their client settings. I would expect that to turn off the signal propagation model for the AWACS player.
Thx for the reply Boxer!
I understand, and love, the LOS & distance aspect. I was under the assumption the outsiders=all takes those out of the equation and lets people inside BMS 3D hear me from 2D without these distortions. But if I now understand correctly, the IVC client doesn’t take outsiders parameter into account whenever the one who’s talking is having a seat in 2 or 3D; right?
The way I work now for ATC/GCI is connect with BMS server, join the MP TE. Take a seat in the Awacs.
Then disconnect from IVC server by clicking force local control and reconnect manually. I was under the assumption by disconnecting and reconnecting IVC, the BMS state of my seat was mute.So I will try again by not joining BMS TE and just starting IVC manually standalone and connect.