Steel Beasts Radio Simulator Proposal

[Durham]

Those of us who have been playing Arma 3 and using the Task Force Radio Mod have noticed a significant improvement in immersion as a result of more realistic radio communications.  Owing to Arma's more open programming environment, the TFR developer (and the Aries Radio developer within the DCS World simulation) have been able to integrate in-game variables (such as frequency selectors, attenuation modelling, talk ,as opposed to radio, modelling based on distance).  While it may be a pipe dream to believe that we could achieve any integration with the Steel Beasts world, it should be possible to improve immersion with a standalone program running in the background.  The standalone version would have the following objectives:

1.   Provide multiple channel listening watch feature so players could monitor frequencies;
2.   Provide the ability to set whether frequencies/intercom are heard in left/right/both ears;   
3.   Provide hotkey support to change transmit channel, so if you are listening on the company net and currently set to platoon net, you can use a hotkey and your push to talk button will transmit on the company net;
4.   Provide an intercom feature for multi-crew, such that voice activation is enabled on the intercom and only players within your vehicle will hear the intercom transmissions.  Until SB integration is achieved players will have to manually tell the program which players are on the same intercom circuit - ie in the same vehicle;
5.   Add radio clicks, background noise and some attenuation to radio transmissions (although not based on distance topography owing to lack of world integration).

In version 1, I would intend sticking to the PC with a background app which windowed players can see and full screen players will access through hotkeys.  Owing to Steelbeasts voracious use of the keyboard commands, players may be required to invest in a programmable usb device so as to macro enable hotkeys.  Users with programmable joysticks already have this capability to program LCTRL+SHF+F5 for example so as not to conflict with SB game commands.

I intend using the Teamspeak pluginsdk_3.0.18.1, Microsoft Visual Studio 2013 and C# to develop a distributable windows forms application with an installer.

The easier alternative would be to have got the Aries Radio Gossipbox (http://ariescon.com/) to work.  However, having set up a Teamspeak server on a virtual machine, I have managed only one successful radio transmission so far.  The teamspeak client on the receiving machine keeps crashing and I am getting no help from the log files.  Expecting members and particularly new members of the VU to use an application that endlessly crashes TeamSpeak is totally unreasonable.  Nonetheless, if I could get it to work and then replicate on multiple clients, then I would save myself a lot of coding and achieve all of the features listed above.

In the next iteration, to the extent Version 1.0 is a success, I would propose adding an IOS, Android interface, so users could set the radio on their smartphone/tablet communicating the input and output to a Windows service running on their game PC to save endless alt-tabbing.  I have not written anything in IOS before, so that will come with time if there is any momentum to the project.

If we are successful in getting a standalone PC version to work consistently, then I would intend showing it to SSnake (Nils) to see if they will give us the keys to receive variables from the game so the implementation would be able to replicate the full functionality of TFR and Aries radio in terms of geolocating the players and knowing which unit they were in for the intercom system.

[Lumituisku]

Very nice post Durham! You clearly have put lot effort to make this.

This would be really cool thing in Steelbeast. Id love to have more immersion, with this kind of feature.

What I'm afraid of, is that many of our members, even on Saturday sessions don't seem, interested enough to put effort to install and to do troubleshooting for these kind of things to work.

On Havoc, we could hopefully have better luck, and I could see this being tested and tried on Saber sessions as well.


Hey guys what do you think? Doesn't this sound good idea?

[Frankie]

Great post Durham.
> Add radio clicks, background noise and some attenuation to radio transmissions
>
Yeah, I really dig this one. That would be really nice.
But I am just a South East Asian armchair general/pilot/tanker/U-Boat commander. Maybe the army guys in DOW can give us an idea what radio comms in real-life is like.
As for Aries Radio Gossipbox, have you tried posting your problem in their forums/community? Sounds like a couple of real hurdles to cross, but once those are over and done with, you'll have a real handy tool to help with the immersion of SB.

[Beef]

Durham, I like your idea very much! Let me know if I can help test or anything.

Beef

[Lusik]

Good idea. I'm in for testing if necessary.


Sent from my iPad using Tapatalk

[Asid]

This sounds great.

Let me know if I can assist in anyway Durham.

Regards

[wilso845]

Sounds good can I ask like ArmA 3, will it have the ability for guys in the talks to hear only those who multi crew I've inter comm?

And that the commander deals with all the radio chatter unless he is dead?

This would be great for immersion as some times I find it hard to talk to guys in TS on tanks as they are all on the same channel and cut each other up or you can hear them giving fire control orders to each other when multi crewing.

[Durham]

PROGRESS REPORT

I have designed the user interface, which has a splash screen with options and connect.



The options allow you to set your hotkeys for channel up, down and push to talk as well as which ear you want each channel to come out of.



The connection screen asks you for the ts ip address and your vehicle, platoon and company with a connect button.



This then puts you into a console which reacts to your channel up/down and PTT hotkeys.



In terms of coding I have got as far as registering the hotkeys with windows, but am having issues with the PTT differentiating between a keydown and keyup event, as of course I cannot debug because you use the keyboard to step the code!  Issues with working at a low level of the OS!





I have set up a TS server on a work Virtual Machine, so I have a TS environment I totally control.

I have reviewed the documentation for the TS plugin SDK, but have yet to write anything with it.

The basic architecture in my mind is as follows:

When you connect it will either join you to or create a company/platoon/vehicle channel where the channel is the vehicle so that you can use voice activation for the intercom.  As people connect or change their vehicle/platoon/company settings this will throw events which will create dynamic whisper lists, which is what the PTT will address depending on which channel you have selected.  All the clever stuff will be in creating and synching the whisper lists while using TS as the database.  I may run a database server to keep control of the logic and only change whisper lists from there, but that would mean that there would have to be both a client and a server application, so I would rather not.

The Aries Radio (DCS) guy is nice and helpful and the Task Force Radio guy (Arma) is Russian and less so, but I think his product is better.  Nonetheless the fact that they have done all I want to do and much more shows that it can be done with the SDK: just a matter of time and application.

Coding volunteers with Visual Studio 2013 and C# experience welcome!!  C++ would be a real help as that's what the SDK and example application are written in.

Durham

[Lumituisku]

Omg... Great!!!!

- Send from my smartphone with Tapatalk

[PaladinSix]

Very interesting project.  Two suggestions:

(1)  The "Both" checkbox column is superfluous.  If someone wants the audio in both earpieces, they can just check "Left" and "Right."

(2)  As far routing what you hear, rather than hard coding you might want to go with a "radio net" approach.  That is, give users the ability to dynamically create nets (e.g., "company A," "Fire support," "1st platoon," "2nd platoon," "vehicle X internal intercom," etc.).  The user can then call up a list of the available nets and "subscribe" to the appropriate ones.  Behind the scenes, the program does the needed work for each net to create the appropriate whisper list encompassing everyone who has subscribed to the particular net.   This would be similar to the Channel Commander functionality, but allowing multiple groups.

[Durham]

The both point is well made.

The net approach is pretty much the structure I have in my mind, but will need to get over the simple stuff first - connecting to a server, creating a channel etc all through the API with error handling.

The more I do this, the less I feel the right to complain about the bugs in SB et al and the more respect I have for their developers!

[Asid]

The more I do this, the less I feel the right to complain about the bugs in SB et al and the more respect I have for their developers!

Different situation.

[PaladinSix]

The more I do this, the less I feel the right to complain about the bugs in SB et al and the more respect I have for their developers!

I'm a hobbyist programmer too, and I also can appreciate the magnitude of the task in developing and maintaining commercial software. 

[Durham]

I am getting close to releasing the user interface as an alpha product.

At present as hotkeys it takes 1*modifier + 1*key or 1*key. (Modifier = SHIFT, CTRL, ALT, WIN).

Given that Sb grabs the whole keyboard it will take a modifier.

My question is, do I need to add the dx dll that allows joystick buttons to be recognized, or do we all do what I do, which is code our joysticks with TARGET GUI or similar, such that our joysticks are just replicating complicated keystrokes?

    public virtual IList<GamepadDevice> Available()
    {
        IList<GamepadDevice> result = new List<GamepadDevice>();
        DirectInput dinput = new DirectInput();
        foreach (DeviceInstance di in dinput.GetDevices(DeviceClass.GameController, DeviceEnumerationFlags.AttachedOnly))
        {
            GamepadDevice dev = new GamepadDevice();
            dev.Guid = di.InstanceGuid;
            dev.Name = di.InstanceName;
            result.Add(dev);
        }
        return result;
    }

People who use joysticks in the clear should speak out.  It will be a pain to add (as you can see from the code and then the inevitable error handling), but perfectly achievable with time and effort.  Thank you for your input.  D

[Lumituisku]

This is heprew to me...  I hope someone else knows what to say and if it would be good or not. I don't