skruis

Thanks Tank! I already had to release an update to the SW version...to get the map exports working. You always think you've checked everything.

Alright, one of the most common requests for Athena has been fulfilled. It's on the workshop: http://steamcommunity.com/id/skruis/myworkshopfiles/?appid=107410 If some of you could try subscribing and running it from your PC's, it would be very much appreciated. I'm considering launching the application (Athena Desktop) automatically when Arma starts ... just because it'll be easier for Workshop users. Any thoughts on that? Also, Tank, this does not include your marker fix. I have to merge that fix back in to the main branch. Thanks, bus

Progress update. I've overhauled the communication between the extension, the relay and the desktop app. I'm currently working on the connection between the desktop app and the community server. I have no idea if anyone is actually using a community server but I'm updating it regardless :-) This update will probably help the people that have been complaining about it not connecting. The old network architecture was my first attempt at network programming and it shows. Because there are automatically less 'servers' involved in the new versions, it's easier to make a 2 way connection so it 'should' be more reliable over all. Additionally, I've tested the latest version of Athena and am able to run the mod from different directories (other than the normal Arma 3\@Athena folder location) so after I've got this next release wrapped up, I'll try to distribute through the Workshop. I'd expect to see something by ... late Wednesday/early Thursday. After that, I'm going to look into some feature updates. I got some good feedback about the logger (server utility) so I'll update that and release it publicly so you can start using it as an AAR utility. Additionally, there are some small tweaks that have been requested by a particular unit so that Athena can better fit into their style. I'm going to expose some per player and client side variables that will allow scripters to have some more control over what Athena gathers/displays. So, for example, there could be a couple of variables such as: ATH_Capable - this one should only be set by the mod Boolean true if the user is running the @Athena mod won't exist if the mod isn't running ATH_Connected - this one should only be set by the mod Boolean true if the user's application is connected false if the user's application is not connected ATH_Allowed Boolean true if the user is allowed to use Athena false if the user is not ATH_ScopeUnit Integer 0=off (disables collection of units) 1=list (a list of units) 2=player (your own unit) 3=group (your group) 4=side (your side) - DEFAULT 5=Athena users (you and other ATH_Connected on your side) ATH_ScopeUnitExtended Boolean true if you want to enable extension discovery (position of a collectable unit + non collectable within X distance) false if you don't - DEFAULT ATH_ScopeUnitExtendedRange Decimal/Double/Whatever 0 to Desired Range - 0 is the DEFAULT ATH_ScopeUnitList Array of units ATH_ScopeObjectList Array of objects + ranges [[object1,50],[object2,100]] - [] is the DEFAULT So, I think most of those are pretty self explanatory apart from the extended thing. So I thought about how you would implement something like this IRL for every soldier and I kind of thought of the radio man. Now, I'm not a military expert but I figured it would only really make sense to have 1 well connected guy and then the rest could have shorter range transmitters. So basically, one of the guys in the unit would be the 'uplink' and the other guys would feed their data through that uplink to 'command'. If someone gets too far out of range of an uplink, they disappear from Athena. That's the idea and it would pretty much only be effective when ATH_ScopeUnit is not 0 or 4. I'm open to feedback on the var's. I figured with that combination of variables, you can essentially control Athena and have some cool functionality. You might only enable Athena if a unit has a GPS or if they have a GPS and a radio. If you use ATH_ScopeUnit = 1 and ATH_ScopeUnitList, you could tell Athena only to track specific users like TL's, PL's, SL's, etc. or other units with gps, radios, etc. by updating the ATH_ScopeUnitList dynamically. The last group I was in, I setup a mission that if you destroyed a tower, you 'disabled' the other teams TFAR radios. You want to force someone to protect an asset? Tell them you'll turn off their radios ;-) You could do something like that with these vars. Suppose your pilots are using Athena...you can setup a mission that if your team loses a 'comms' area, it changes the ATH_ScopeUnit to 2 effectively blinding (in Athena) your pilots from tracking friendly ground forces and other pilots...though setting it to 1 and then specifying a list of other pilots would make more sense (cause none of the aircraft would probably rely on the ground based comms for their access to Athena). The ATH_ScopeObjectList is a neat little idea...if you specify an object and give a range, all (friendly) units within range of the object will be displayed in Athena so if you use ATH_ScopeObjectList, you could specify a drone and use it as a mobile uplink or you could specify a list of vehicles and if the units are within range of the vehicles, they too will appear in Athena. Anyways, let me know what you think and like I said, I'm hoping to have something in your hands in a couple of days w/ AAR and scripting support shortly after. -bus/skruis

Workin on it. I'm back in the swing of Athena development. There's 2 major things I want to get wrapped up ASAP: the overhaul of the socket connections and Workshop compatibility.

Sorry, no. I've been out of touch w/ most of my ARMA buddies for a while now and they often relied on me for scripting support and I was only so so.

@Amateur-God, Absolutely. In the download, there's a key. You can add that to the keys folder on your server and the players should be able to use it on their PC's.

I'll be on Steam on Thursday if you guys want to chat in real time about what's going on and why it's not working. I'll work with both of you separately if you're available.

Ok but you haven't actually enabled it, turned it on or setup any other sort of virtualization. When you start playing, can you open Task Manager and see if the Athena Relay application is running?

@Ghostworrior, I'll see what I can do. Either of you have some sort of virtualization software installed (Hyper-V, VirtualBox, etc.)?

Doctor butts, just to to double check, are you using the latest beta? Also, anything listed in the Battleye log? Did you install @athena to the normal mod folder location? thanks, bus

I know that's a highly sought after feature but I don't know of any way to accomplish that unfortunately. Also, I don't know of too many public servers that allow Athena. It's usually communities with private servers that adopt Athena.

@Amateur-God, yea, the servers will need to add the key to their keys folder in order for you to be able to use it while connected. That's standard multiplayer mod security.

Tank, Still around :-) Slowed down by life but never stopped! I do believe I've resolved that bug but unfortunately, it's packed in with a bunch of other 'behind the scenes' changes to the network code otherwise I'd release a small fix for you. Sorry :-( -bus

iWazaru, I may have already solved this issue in the newer version of my netcode. I sent you a private message which I'm copying here as well: I guess all of these fixes have no 'value' to Athena users if I don't actually ship the code though :-/

Ah, I hadn't anticipated multiple Ethernet adapters like that and it makes sense as to why you're seeing this problem. I haven't added code to ensure that the outgoing message is delivered using the same adapter that received the incoming message. It seems like something that should be obvious but when you write this stuff, you're thinking "I received a message and now I'll reply" and it's easy to forget that the PC might have multiple connections or that extra work would be required to ensure the response is sent on the same adapter as the request. I was going to recommend changing the priority of your network connections but it appears the method I was aware of is no longer valid in Windows 10. Here's an interesting link: https://answers.microsoft.com/en-us/windows/forum/windows_10-networking/network-connections-advanced-settings-adapters-and/d3f3d556-fd6c-4007-9f98-d900810f89f9 So, you could possibly, as a short term work around, change the metric values on the VirtualBox connection to be higher/lower priority than the Wireless connection and that 'might' help to direct the packets out of the Wireless connection. I'm not sure what effect that might have on your VirtualBox emulation so you'll have to test.

iWazaru, Some questions: 1. What are the IP addresses of both machines? 2. You've said you can ping but I just want to confirm that you can ping either machine from the other? 3. You've said you did but I just want to confirm you've disabled the firewalls? 4. What are the 'regions' in use for your Windows 10 localization settings? (I've had issues with localization in the past) 5. In the @Athena folder, there is a relay.exe.config file, set the 'debug' option to 'true'. This will create an 'Athena.Extension.Debug.txt' file in your My Docs\Athena\Data folder. 6. In the @Athena folder, there is a Athena.Extension.Settings.txt file, set the 'ath_debug' option to 'true'. This will create an 'Athena.Relay.exe.log' in your Arma 3 folder. Both of those debug options will cause the generation of log files, send those log files to my email address seankruis_AT_hotmail_DOT_com Thanks, skruis (bus)

@KillerKrapfen Can do. Are you more interested in your own custom locations, existing locations or both? I believe I'm allowing the text to scale at 1:1 with the map itself. I could 'counter' that scaling at a different rate or I could make the font heavier as you zoom out (bold).

Short Answer Yes, it's possible and it's a planned feature. Long Answer Well, technically, the ability for the actual game server to deliver updates over the Internet to a client is already possible (in the version I'm working on now). So, there are a few components to Athena: 1. Mod (@Athena, @AthenaSvr, @AthenaDesigner) 2. Relay 3. Clients (Athena Desktop.exe, Logger.exe [will be renamed probably] 4. ACS The mod collects data. The relay distributes the data. The clients present it. The ACS is just a meeting place for clients. So, with that topology in mind, it is absolutely possible, in the in-development version, to get real time updates directly from the server's @AthenaSvr/relay combo or for that matter, any other player's @Athena/relay combo. The clients allow you to change the IP/Port combination that they will connect to in order to receive updates. By default, it points to the local computer and the default port of the relay.exe. So, let's say your game server admin opens up the port for the relay.exe on the server...there's nothing stopping you from configuring your Athena Client to connect to that IP/Port over the Internet and receive updates directly from the server's relay.exe. This could be used by someone that would, for example, create a web site that would act as an Athena client...and that is something that's completely doable...even the map exports could work with a website. So, a mission starts and the webserver doesn't have the map file. It could send the map export request to the server (if I added map export functions to the @AthenaSvr mod), receive the map data, process it and render it to images behind the scenes and then deliver those images over the web in a tiled format. The full Athena client isn't image based. You actually see an image in the end but it's more dynamic whereas the website would have to be more static because of the nature of web delivered applications. But logistically, it makes more sense to route all of that through the ACS but because of that, there will be more of a delay between the updates. So, let's say the server admins run the ACS on Server 1 but the Arma3Server.exe is running on Server 2. The A3Server relay will collect data as fast it can and relay it to the ACS. The ACS is currently discarding all but 1 update per second. I guess I would configure it to forward more or even all of the live frames to the ACS and then the ACS would forward it to all 'witness' clients (Athena clients that are watching via the ACS and not via their own game). That extra hop will add some delays so the updates will not be nearly as frequent as they would be if you were getting updates directly from Arma running on your own PC. The local updates are all in local memory essentially. Yea, they may be transferred over pipes and then a socket connection but none of that data actually is transmitted over the 'wire' (unless you run Athena on a separate computer). In the ACS delivered scenario, there's the 'wire' latency between the server and potentially the ACS server and then from the ACS server to you so it'll definitely be more of a slideshow but yea, it's possible and it's planned. Just not sure how to secure it from cheaters...

Yep. So, the actual parts required for collecting information are the @athenasvr mod and the logger utility. The logger interfaces with the svr mod and collects the data. Then it will upload it to the ACS, which is just a stand alone exe, which will serve as the repository through which Athena users will be able to download the replays. So, you'll need to run the @athenasvr mod on each server and then run the logger.exe, once per server, and then each running logger utility will collect the data for the appropriate server.

Some users appear to use it for JTAC (coordinating air/ground assaults). Pilots seem to really enjoy using it.

Yes, use the one in the first post of this forum thread. At this time, the drawings made in Athena do not appear in game. BIS hasn't exposed any functionality to tie in to the drawing system. -bus

Unfortunately, I have been a little too busy to make any meaningful progress. That being said, I still found some time to work on Athena but it was 'behind the scenes'. So, I've simplified the data in/out and the data collection functions in the mod/extension and overhauled the communications between the extension and the relay. As part of the streamlining, the frame rates in both ARMA and Athena increased so that's a positive. Additionally, I worked with Liquid Tracer from Nopryl (nopryl.no) to help them get ready for their annual Summer LAN event and as part of that, created a 'server' mod that works with the unreleased 'logger'. LT used the logger to record their sessions and then opened the saves in the Athena desktop application. They used a projector/screen combo to debrief after each of their sessions: I have to say, this is something I've always wanted to see Athena used for: AAR as part of a face to face community event...so, for me, this was exciting. LT had some feedback and I'll be incorporating that into Athena and the logger which I plan to release once it has some meaningful integration with the ACS (Session saves get auto-uploaded to the ACS w/o any admin interaction). Tank: That's great news about Malden! -bus

Watched Microsoft's Build keynote today. Some of the changes to UWP and .Net have a lot of impact on what I can do with Athena. Very excited for the Fall Creators Update , .Net Standard 2.0 and the upcoming version of Xamarin :-) Also, half the emails I get about Athena are because people are using older versions. Updating the website is going to be a priority now.

@crosus97 The website is very much out of date. After spending so much time on the mod/app itself, I just didn't have time to update the site...I felt like I was wasting time whenever I started to update the site. If you download the version posted on page 1 of this forum thread, it will be x64 compatible and much better than the one available on the website. Sorry for the hassle.

Hey guys! Just wanted to post an update. My real life work load increased a bit so I had to take a short break from Athena and ARMA. Will be getting back to it and implementing fixes for your reported issues soon.