skruis

You mean the individual unit markers in addition to the group marker? Anything's possible. I'm going to setup a GitHub page and then add that as a feature suggestion...along with filtering out non player units which would be easy to do: they don't have 'steam id's' like players do but getting AAR out the door and tied in to the ACS is the highest priority for me after getting this version 'released'. Guys, another beta: http://www.athenamod.com/download/20170129.zip. Includes some changes to how the relay works and it includes the ability to change the relay port...should you want to for whatever reason. But the relay has an outbound queue that all of the messages for delivery to Athena would be pooled in. That queue has been split up and now each client has their own pool and their own delivery thread for outbound messages. If you run Athena on multiple screens, like I do (I keep a large one up to the right for an overview of the area and I have my surface in front of me zoomed in so I can track my unit on a per player basis), you might notice a small difference...especially if one or more of the clients are on wifi. Because they used to be in the same delivery pool, the relay would send a message to one client then the same message to the next client ... in order. Whereas now they're delivered simultaneously and independently of each other. This will be important for when the flight app comes out....no eta.

@zebby5000 Yea, not sure why you have to have those settings but I don't and I've only had to walk people through turning off their firewall as a debugging step (to eliminate possibilities)...only to confirm when prompted that the relay and Athena should be allowed by the firewall. My UAC is one step from maximum (which is the default). My firewall is 'on' for both Private and Public and I'm not running A3 as admin.

Hey guys, another beta has been released to: http://athenamod.com/download/20170128.zip. It contains the fixes that helped zebby5000 to successfully use Athena on his computer as well as the 'keys' should your server admin wish to allow Athena on their server. @zebby5000, thanks again for spending so much time with me. I'm glad we were able to nail down the root cause of this and a couple of other issues. Like always, I very much appreciate any feedback, suggestions and bug reports so again, thank you.

Hmm, its likely that the relay.exe is being blocked. Sometimes the downloads are flagged as unsafe by windows and theyre blocked. Can you, and I know you said BE was turned off but check the BE log in the A3 launcher (I have to cover my bases) and then go to the @athena folder, right click on the relay.exe, go to properties, go to the general tab. If theres a checkbox at the bottom that says unblock, check it, hit ok and try again. bus

Ok, what I'm hoping will be the final beta before release is now available: http://athenamod.com/download/20170127.zip Still waiting on BattleEye whitelisting...gonna send them an e-mail too. Changes Include: Some minor GUI cleanup I'm not sure if this bug was present in the last release or not but as part of my optimizations over the last few days (to rein in runaway threads), I introduced a small stupid little bug that after hitting start, then stop, on every subsequent click of start, it would start and then immediately stop updating. Just a small little logic bug. Again, not sure 'when' it got introduced but I think it's fairly recent. Either way, that's resolved. I have greatly stabilized the map export process. It is now much more reliable....that might have been included in the previous release. I have fixed the recording and playback system though saving the screen and opening it later doesn't work...I forgot about it tbh. I have improved the following per frame procedures: Making sure the 'following' list is updated properly without unnecessary lookups Making sure the unit 'color' updates properly based on their 'side' membership Making sure the unit 'label' gets moved to the correct group (in the ORBAT tab) if a unit switches groups mid-mission (noticed this when using ACE's team join thing) Making sure the group 'color' updates properly based on the leaders 'side' membership Clearing the group labels should all members die (Groups don't get destroyed automatically like they used to) Changed the routine for updating units and labels around so that one doesn't have to wait another frame for the other (they're interdependent) And the big feature: Athena Community Servers now allow you to upload and download maps. The ACS is central to all my 'big ideas'. Only 1 person from your unit needs to import the maps and upload them to the ACS If you're playing and you don't have the map, you can check your ACS (even while the 'you don't have this map prompt is displayed), download the map and it'll automatically launch I've tested it out from my location over wifi out my internet connection to my colo server and it works but that's hardly a significant test. Give it a whirl and let me know if there are any issues. -bus *EDIT* Received an e-mail from BattleEye @ 3:40 (Chicago Time - UTC-6), that it should be whitelisted 'shortly'. *EDIT* The extension has been whitelisted but now the 'relay.exe' that my extension launches is being flagged. I've requested that it too be whitelisted. Will update with progress.

I've just posted a video showing off how the current client side features of the ACS work:

Thanks! Basically, yea, but its only required if you want to share 'ink' with each other. If you want to play separately and not care about sharing ink, the ACS is not required, currently. I'm going to be expanding on the ACS's functions though to add: Server level password (I can't believe I didn't think of this before) Map publishing and downloading (Highest Priority) Additional room controls to lock to server, mission, side, invited users (The basics are present, just not enabled) AAR storage and synchronized playback (will require a Windows game server) (This will roll out in the near future) Witness Mode ... let's just say, when you have the units and the groups, why do you need Arma? Super secret special maybe it could happen and I hope it does awesome feature that I'm overly excited about but probably wont matter! So, the ACS will continue to offer more and more value. *Edit: On re-reading, I'm concerned that you think the ACS removes the need for everyone to run the @Athena mod with Arma. That is 'not' the case if they want to see output from the missions. @Athena is required by each Athena user to receive mission content, the ACS is required to share 'ink' with each other. -bus

New beta: http://www.athenamod.com/download/20170124.zip This beta includes the initial version of the ACS as well so if you're a part of a community, you can give it a whirl. Keep in mind, I'm one guy. I connected to it with a device or two and ran through some scenarios. You will hopefully push the limits further than I'm able to on my own. If you run into problems, please please please try to remember the exact steps that you went through so that I can try to recreate them. if you or your community does not want to setup an ACS, you can use mine which is located at: Address: acs.athenamod.com Port: 28804 The Athena record and playback system is currently non functional along with saving and re-opening the screen. The functions are still present, they just don't work because of other changes I made. I am aware of it, it just wasn't a high priority compared with getting another beta out. Also, I applied for BattleEye whitelisting using the extension in this beta. Not sure how long it will take but until it's whitelisted, you still need to have BattleEye disabled. I will update this thread as soon as I hear from them. Thanks, skruis (bus)

And another showing the map export process:

Made a small video showing off the multi-screen support and local ink sync

Just played for a few hours...no issues. Ran smooth as silk. The icons were drawn consistently and quickly across many missions and I was able to export a large amount of maps over wifi to my Surface w/o skipping a beat. There were 2 things I didn't like. The first was I didn't like the auto zoom on speed change function. It was pretty distracting and it kept switching back and forth when I was driving vs flying so yea, I'm going to disable it until I have time to dedicate towards figuring out how to smoothen the transitions...maybe with timers or implement a user interface to turn it on/off/configure. The second thing and I'm not sure what I can do about this ... is zooming while in 'follow' mode. It's not flaky, it's just laggy and that's because as you're trying to zoom using the slider, it's also updating the content that you're scaling so ... both things happen on the same thread and there isn't anything I can do about that. If you want to zoom smoothly, disable 'follow' and use the slider or just tap the slider and it'll increase by 0.5 towards your tap direction. Apart from that, I'm pretty happy with where it's at. The only glitch I ran into with map exports was for ... Ziwasogo. Arma crashed when I asked it to generate a list of all the trees ... but that 'was' towards the tail end of exporting 10-12 maps so maybe it would work on a fresh try but even still, that's an Arma thing. Perhaps the export script could be revised to accommodate maps with insane amounts of trees...I'll look into it but regardless, I think I'll apply for BattleEye whitelisting tomorrow.

So there are 2 ways to share ink: Local (within your own environment) Athena Community Server The local option relies on the 'relay' to distribute strokes and ink is shared between all of your devices connected to the relay. So these kinds of devices will share ink with each other on the 'personal' layer. Imagine Athena running on a Surface in a homemade 'cockpit'. Imagine Athena also running on an additional monitor near the primary gaming monitor ... as a quick point of reference. Imagine a potentially third monitor or tablet or whatever running a potential Athena 'radar' map that allows you to track targets and such. That's a lot of Athena's, right? Well, you might want your own ink to show up on all of them but you probably don't want all of that ink to be shared with the 'community'...if you add that ink to your 'personal' layer, that ink is routed through the relay which distributes only to the computers connected to it and that's assumed to be only your devices. The Athena Community Server option is more involved. You can share ink with others and it makes sense for that sharing to be somewhat organized and in Athena, we do that by defining 'rooms'. Each 'room' you join will generate a toggleable layer on your map and the 'active' room is the room in which you will draw in so that others can see what you're drawing. Even when joined to an ACS, you still have your 'personal' layer as well so you can share simultaneously with other players or just within your own group of devices. It adds some complexity but it also adds a great degree of control and separation...something sorely lacking from the ingame stroke system. Large Version Close up on Surface Close up on Rooms (Primary Monitor) So, all of the ink you see above was shared via an ACS that I have running on a remote server with a 30ms ping. So both devices were connected separately to the ACS. Some strokes were made in the 'personal' layer (Box with ? marks in the top left on the primary monitor, Squiggles to the left on the Surface) so they weren't shared via the ACS but most were made in various rooms. Toggling the checkboxes for those rooms on the Map tab hides or shows that ink. The delay between creating a stroke and seeing it appear on the other end is at most, 3-4 seconds because the Athena client attempts to 'pull' and 'push' data to the ACS once a second. So, depending on where 2 devices are in their timing, you could have a 2 second gap plus some misc time in ACS management and client drawing functions. I'll just put it this way: I drew on the Surface, I looked up, it popped up on the monitor. I made a change on the monitor, I looked down, it popped up on the Surface. Same for erasing. Also, take note, I was not playing Arma at the time so this functionality is always available. If you look closely, you'll also notice a few gui changes. The 'locations' and 'achors' tabs have been moved to the 'map' area and the zoom + and - have been replaced with a slider, as suggested. We're getting very close to a beta..I might include the map publish/download to the ACS in this version. We'll see.

Large Version So, I was able to nail down the issue that caused the display on the map to 'clear' but not be redisplayed until either a very long time or you stopped/started Athena. Like I said before, it was due to a 'shim' that I added in a while ago to detect mission changes for the purposes of neatly packaging the recorded frames per mission. Well, I figured out a different way to detect a mission change and I identified and resolve the root root, the very root, cause of the issue and it is now resolved. Athena not only is performant, it's also reliable now. I had no idea how bad it was until I started switching between missions. I had always started a mission, tested and thought "yea, works great." and moved on to the next issue. If you want, I'll package a version that has the ACS stuff disabled (it's not fully ready yet) for you to test out. Also, I added a couple additional GUI enhancements. The one most likely to remain in Athena, you will notice if you look in the top right corner...shortcuts to the various render modes. The render mode changes have been reworked to be faster than they used to be. I want to say an Altis render mode switch only takes a second or two so not bad. Again, this change is something more geared towards the visual redesign. The other GUI change I just kind of thought up on a whim the other day and I thought "Yea, that would be cool! That's amazing!" and then I forgot it up until a couple of hours ago. I wrote it down in my Good Ideas section of OneNote and then I thought "I'll just do it now." and a little bit later, it's in. So, what are we looking at? Waypoints. No, not waypoints created in Athena and feed into Arma. These are just the waypoints that are assigned to groups in game. The export scripts for the groups now check the waypoints for the groups and they grab the X,Y of that next waypoint. If there's no waypoint in the series, it doesn't draw anything. So, for right now, it draws a little dot where the group's next waypoint is and it draws a line to the dot from the group leader. I'm iffy about how this feature will be received but I think it's neat. I'll add a layer that you can toggle to hide it if you don't like it. Me, personally, I think it's pretty cool...more...commandish. I had hoped this would work with the map shift-click function (how you set your own personal waypoint) but it turns out that that's not really a waypoint...or at the very least, it doesn't add a waypoint to your waypoints list. The scripts will pickup any waypoints that were placed in the editor or added via scripting commands and that are added to the group waypoints lists.

Thanks! btw, I just nailed down the annoying bug that required you to stop/start in order to draw updates after a mission switch. It had to do with some logic that supported recording sessions...of all things.

Making a lot of progress and there are some significant changes. Large Version of 1st image Large Version of 2nd image I've beginning the process of consolidating the various forms and windows so that they all exist within the app itself as part of the XAML layout. Why is this important? Because it will make transitioning to the UWP (Windows 10 Store App) framework much easier. As a side note, as far as I know system level hotkeys are 'not' supported in UWP apps currently so the hotkeys features will probably not work in a way that matters to most users when that transition occurs. Part of the consolidating was the creation of a 'fly out' display that is anchored to the inside right of the window. This 'fly out' can be toggled on/off in the Controls menu. The 'layers' control whose positioning some users complained about has been moved to this flyout so it's now 'off the grid' The 'ORBAT' window which I'm not sure if anyone even knew existed has been moved to the flyout and there are some minor improvements. For example, if you use Map Anchors, which you should because they let you designate an important location and then 'track' your relative position and distance to it, you may have noticed that there are 2 ways to enter the location for the anchor. The first is to type a 6 digit grid location. The second is to enter specific coordinates. There was a 'get' button that you could click to then click the map and have the system automatically fill the coordinate fields. That button has been renamed to "Use Map" and when you click it, it renames itself to "Click Map" so it's a little more instructional in it's usage. The 'Athena Community Server' Athena form has been added to the flyout. This form allows you to login to your community server, create rooms and join rooms. For each room you join, an ink layer is added to Athena and each stroke you draw on that layer gets shared with everyone else in the room. So, imagine you have your whole team using it. You're the pilot. You have JTAC on the ground and there are PL's and SL's using Athena as well. Each of those groups, regardless of their ingame group membership, can have their own 'room' and each user can 'monitor' the other rooms. So let's say you've got 7 layers because you're 'monitoring' 6 rooms plus your own personal layer Personal Platoon Squad 1 Squad 2 Squad 3 JTAC Flight And you're 'active' on Flight You will see all of the ink written to Platoon, Squad 1, Squad 2, Squad 3, JTAC and Flight Your ink, with Flight being the 'active' layer, will be seen by anyone else that's 'monitoring' the Flight room You can change which layer is 'active' at any time I've made a tremendous amount of progress on the Athena Community Server. Users can, from Athena, establish a session on the server, create and join rooms. Yea, that sounds like not much but there's a lot of grunt work that goes into building a solid base. Adding new features is going to be a breeze and Athena, right now, supports sharing ink with anyone that you're in a 'room' with and did I mention this works outside of Arma? I don't mean that the data exchange happens outside of Arma, which it does, I literally mean you can now use Athena cooperatively to share ink when you're not even playing Arma, from any computer anywhere. Why is that cool? Multiple participant mission planning, tactical scenario training, etc.. How does the ACS work? It's essentially a socket server. You run the executable on a Windows machine and forward a port on your firewall (TCP 28804 by default, yes, you can configure that) to the host machine. No biggie. Once the ACS matures, it might be repackaged as a Windows Service. Does it store any data? Not currently but it will eventually. Though Athena is a communications application, it's not the 'primary' communications system so none of the rooms are saved. As users 'leave' rooms, the rooms disappear automatically. If the server is shut down or crashes, the rooms are lost. Is it resource hungry? Technically, it depends on how many users you have but theoretically, no. It's shuffling sporadic blobs of relatively small data between a small group of people but it 'is' in its infancy so, time will tell how well it scales. What are the benefits of running the ACS? I'll break this down into three responses Currently - Your users will be able to share ink with each other over the Internet. With the Athena client and the ACS, we essentially have a multi-room Arma oriented whiteboard. Future - The ACS will eventually host the AAR functionality used for hosting and the distribution of the recordings and for managing synchronized playback amongst the users in a room. It will also make trying out new worlds easier (in Athena) because users will be able to publish and download maps to/from the ACS. Far Future - I've got some crazy sh-stuff planned :-) The ink controls have been greatly improved and relocated You can go directly to Draw, HighLIGHT, Erase and Select You can go directly to the color you want You can quickly change the size of the pen I'm ramping up for an actual release. I think I might bump the version to 2 because there are huge changes in this release compared to the currently available one. The things I have left to do are: Backport some minor socket server process improvements learned while working on the ACS to the Relay and Athena Run through existing other features to make sure they still work (session recording, etc.) Various little GUI improvements Apply for BattleEye whitelisting And I think I can have those wrapped up within the next week. If anyone wants to beta test the ACS, it will be greatly appreciated!

@Jnr4817Thanks! Guys, any feedback on the latest beta? Better? Worse? I'm working on the ACS now, the ink sharing portion. I think you're going to really like this.

So, I implemented: Migrated the improvements to the relays socket server/client to the Athena app itself. The result is the updates from the Relay and the drawing updates on the map (unit movements, groups, bla bla) is much more fluid and less noticeable. Multiple clients register with the relay and when Arma pushes the data to the relay, the relay then pushes the 'right' data to each of the clients. So, you can have multiple Athena client running at one time now. Why is this good? For starters, you can be running Athena on one screen and then the eventually upcoming sometime in the future Athena Flight app on another screen and they will both be independent and have their own connections to the relay. Because of this, neat sh-stuff like the X-Sim plugin are completely possible now. Selective data push. So, now that multiple clients can register with the one relay, what happens during a map export? The commands sent from Athena to ARMA, such as 'export map', are now tagged with the requesting client's ID so when the map data starts coming back out, it gets sent only to the requesting client. That means that the registrations will drop for the other client(s) but that's because map exports are 'high priority' and because of the way the queue's work, the 'high priority' stuff gets sent out an the mission updates get shelved. That means the clients not waiting on a map export are going to think they've been dropped, which is ok. They'll check back in every 30 seconds. Ink Sync between the relay clients. As strokes are created on a client, the strokes are registered with the relay. As strokes are deleted, the deletion is passed to the Relay as well so the Relay has a running copy of the ink collection and it can distribute the strokes to each of the clients so if I run Athena on my multi-monitor PC that Arma runs on and I run it on my Surface Pro 4; I can ink on either and the strokes from either are displayed immediately. If I delete a stroke from either, the deletion gets synced to the other Athena instance. If I connect an Athena app to an already existing session, the newer Athena app will pull all of the existing ink. It's instant. The downside to this is I yanked Multi-Ink through Arma multiplayer. I know it's a neat feature but I hated how it was implemented. If I wanted to put work into some sort of an in-game protocol for tracking stroke creation/deletion, I could but honestly, I hate SQF. It's much much nicer to keep as much of Athena's functionality out of Arma as possible. So, with one hand I've taken away Multi-Ink but with the other, I'll replace it with Ink-Exchange in the ACS (Athena Community Server) and it'll be worth it...because there will be so many more features.

So, who wants a beta? http://athenamod.com/download/20170113.zip Notes: Be sure to right click on the zip, go to the general tab, check 'unblock' and hit ok. Otherwise you might run into issues. Also, replace all files in Arma3\@Athena or wherever you've stored your @Athena mod folder. Actually, the only file that has to be replaced is the Relay.exe. Included in this beta are: Athena Relay Form Provides real time diagnostic information What clients are registered (updated 2x/s) What was the last disposable packet queued for delivery (updated as data comes in) What was the last actual guaranteed packet sent to the registered client (updated as data sent out) How many guaranteed packets are in the queue waiting to be sent (updated as data comes in and as data goes out) Form is displayed when ARMA runs but the form is minimized to the task bar (you shouldn't see it unless you 'want' to see it) Process Changes Again the topology is: Arma/Scripts/Extension <-> Relay <-> Athena The relay no longer delivers data from a single queue It separates data into guaranteed (map export) and disposable (mission updates) Guaranteed data is delivered first (until the guaranteed queue is 0) Disposable data is not queued or rather, the queue limit is 1 Communication Fixes Problem - After a lengthy map import that more than 1 minute to process (after having received all of the data), the Athena client would be so bogged down in processing the map that it wouldn't respond to the Relay's data push. The relay would determine that the Client was no longer available and would de-register it. Athena would eventually display the map but it would not show any mission data. It believed it was registered and was waiting for data from the Relay. Solution - After 30 seconds of not receiving updates, the Athena client was checking to see if the Athena Relay was 'available' via a test connection but then it was 'assuming' it was registered with the relay. The logic has been adjusted. After 30 seconds of not receiving updates (either Mission Data or Map Export Data) and verifying that the Relay is up and functional, the Athena client will re-register with the Relay and will continue to do so every 30 seconds until it receives data. The Relay will prevent duplicate registrations. Problem - The Relay would obsess over registered clients and would continue to attempt to deliver to them until the end of time. Solution - Added a counter for each registered client. Each delivery failure increases the counter. Each delivery success resets it. If deliveries fail 10 times (1 second timeout per attempt so ~10s total), the client is de-registered. Problem - The socket connection code was a mess. Solution - Cleaned the clutter, simplified the process. This should resolve the majority of communications issues between Arma, the Relay and Athena.

Also, been thinking about multi-ink, I might make that a 'community' feature. By 'community', I mean the idea that's been bouncing around my head called the Athena Community Server (ACS). It'll either be a .net website or a socket server but it'll integrate: AAR Vault - storage and retrieval for community sessions An AAR logger has already been started. It runs on the server and collects all data from the server, for all 'sides'. The logger would upload the session to the ACS and it could be retrieved via the Athena application and played back. AAR Sync - playback synchronization Would allow multiple Athena users to 'sync' the playback of an AAR session so they can review together. Multiple Sync sessions One user could be the director or All Each user could ink Ink from the AAR would be on 1 layer Ink from the ongoing review would be on a different layer Ink Sync - Multi Ink for the ACS (Each Athena user sees all other Athena users 'ink') This would remove the current Multi Ink from Athena/ARMA and instead move the sharing of ink to the ACS. All community members would see each others ink. This would have the side effect of disabling Multi Ink on public servers (which is actually probably desirable) This would allow Ink Sync to work with AAR Vault and AAR Sync Map Exchange When a community member exports a map, they can publish it to the ACS When a community member plays on a map that they do not have, Athena will check the ACS first before running through the export routine Athena Configuration A community member would install Athena and then supply the URL/Address of the ACS along their call sign. That's kind of all I have right now but I think that presents communities with a good deal of value. I'm just not sure if a website or a socket server would be preferable. Probably a website to provide a direct user interface to the database/files. I don't know. What are your thoughts?

Ok, so an additional progress update. I don't know if anyone noticed but when you run Arma, a little application called the Athena Relay starts up as well. What it does is it acts as a Pipe Server for the extension that's running in Arma3. So, the scripts in Arma3 collect data and hand that data off to the Extension (Athena.Extension.dll) which then pipes it to the Relay (Relay.exe) which then sits and waits for the Athena application to connect via a socket and say "Give me data." After that, the Relay will start pushing data to the Athena application as fast as it can. It sounds like a lot of stops but it's insanely helpful to have that little utility there. That application is part of my effort to move 'stuff' out of Arma and into a spot where I can debug it. If and when the Relay crashes, I can easily attach to it and debug. If I'm wondering what's going on in the background, I can attach to it and debug. If there's something that happens to the Relay and it crashes, the Extension launches a new instance of the Relay and the game goes on. Well, I've made some changes and expanded the relays functionality: I've added a higher priority queue of data I refer to as 'guaranteed'. The 'guaranteed' queue is data that the Relay will obsess over and continue to redeliver until it's absolutely without a doubt sure that the Athena client application is unavailable. Currently, this is only used for map exports. I've added a lower priority queue of data I refer to as 'disposable'. Disposable data is data that if it doesn't get delivered, I don't care. A good example of this would be the data you see in Athena...units, groups, vehicles, bla bla bla. If a packet of data doesn't get delivered, I'm not too fussed about it because another one will be right along. Now, I don't want this disposable data queuing up until the end of time and causing a sort of...slow replay in Athena so I've limited the queue to 1 item. If the Relay is trying to send a packet of 'guaranteed' data, the 'disposable' data is continuously trashed. If the Relay is trying to send a 'disposable' packet and it's over a slow wifi connection, the next packet is going to be discarded until the current one is sent (1s timeout). I wasn't aware of it but the Athena application was submitting it's host name to the relay. So when the Relay would attempt to push data to the Athena application, it was trying to resolve the name of the destination computer. In a home network, name resolution is pretty flaky so it's been changed to use IP addresses. I've added a form to the Relay. When Arma starts, the form is displayed. That form shows the connected clients, the current disposable packet, the current guaranteed packet (if any) and how many guaranteed packets are in the queue. I'm not sure if I'll show the form in 'release' versions of the Relay or maybe I'll add a 'debug' option which shows the form but the form outputs some nice debugging information. When I was reviewing Gruman's reported issue of failed map exports, I tried it myself and it failed. The first problem was the name resolution. The second problem was that the ingame 'notifications' about the export being complete and the 'notifications' in Athena about the status of the import are completely out of sync ... or rather, they were not meant to be in-sync but the phrasing gives the impression that they should be. The export script in Arma literally dumps the data to the Relay and the Relay buffers it. So Arma could finish it's portion of the export in a few minutes but it still takes time for the relay to feed the data to the Athena application. So I'm happy to say, I think I've nailed down a lot of the issues that caused the flakiness with the socket connections. I'll be releasing another beta (w/ the Relay form) in the next day or so so you can try it out and give feedback. Also, regardless of the stability of the connection being improved, I 'still' highly recommend a wired Ethernet connection. Athena is so much more fluid with a good reliable connection.

@chortles, I don't believe there's any easy way to directly export those feeds as they exist onscreen, to literally take those and display them in a completely different window. The most I would be able to do would be to recreate the radar display and passenger lists in a separate window w/ a similar look. I already have all the info I need to fill out a passenger list but how well the radar would work, and how similarly it would work to the upcoming one, would depend on what scripting components BIS has or exposes to support the more advanced identification information. The only thing I'm leery of is exporting 'enemy' information. Right now, the scripts only export 'friendly' information. If I start exporting enemy info for use with the radar, I worry that even more people will say that Athena gives players an unfair advantage....which is already something I disagree with but the geek in me is excited at the opportunity. It will all depend on how easy it is to work with the scripting elements that expose that kind of information. I know there was 'knows about' but if I export just 1 unit to the Athena Radar that isn't displayed on the in-game radar, everyone will start screaming 'Hacks!'. As a little bit of FYI, An 'aircraft' Athena module was kind of already started on. Obviously, most Athena users are pilots so it kind of made a little sense to build on that but it didn't get very far. The primary driver was a player that was building a cockpit w/ multi-axis motors built in. His primary request was that Athena help make that cockpit come to life (his 2ndary request was a redesign of the Athena GUI which I agreed with and got into the planning phases for...it would have resembled an MFD). I got as far as supplying the pitch, roll, dir on a per frame basis out to Athena for whatever plane/chopper the player was piloting. The next step was to build a plugin for X-Sim. X-Sim was nice because I could supply it with raw data and X-Sim could display gauges, control the motors and smoothen out/limit the motion in a way that each player could customize to their specific configuration. Then of course, the status of the aircraft would have to be displayed somewhere. Another part of that module was going to be displaying of approach plates for each airport: Now obviously, I don't know what everything is on an approach plate but it looked super cool and apparently, the pilots loved it so the idea was that pilots could supply their own approach plates as PDF's for each airport. Then when they selected an airport in Athena, the approach plate would be displayed in a separate window. If/when Athena moves to the UWP, the airplane 'module' would probably have been spun off into a separate Air app. It would be super easy to implement because 'I' wouldn't be generating the approach plate...the user would. They would save it as a PDF and simply tell Athena where the plate PDF was saved to so Athena would literally only have to display the PDF which, on Windows 10, I could rely on Edge to do. So again, no promises. The next issue on my radar is stabilizing the sockets system. I had originally written my own socket server/client but fiddling with that brought me to a standstill on other issues. The plan, right now, is to find an open source socket server/client, use that and then move on to making Athena better as an application. I've been wanting to get to other things in Athena: improving the markers, redoing the UI, building a data collection mod for the server that collects ALL data for use with Athena as an AAR, etc.. so as of right now, I'm in bug hunt mode so I can move on to other cooler features which may include the aircraft module which may include a radar.

Well, who wants a beta? http://athenamod.com/download/20170111.zip Ok, so, this beta should only change the map rendering to the new system. Nothing apart from that has changed so you don't need to replace the @Athena folder. I included it in the zip only for the sake of completeness. The things to test would be: 1. How does it feel when you scroll/pan/zoom? 2. How does the map actually look? The 'please wait while loading ...' window will work sporadically. I wasn't too fussed about not having it in this beta so when you select a map, expect a small delay while it loads. I think Altis takes ~30 seconds to load (on my pc - i7 4770k). Takistan was 10. Stratis was negligible. Note: When you download the zip, right click on it and go to the "General" tab and place a check in "Unblock".

Status Report: I am extremely happy with the new rendering technique. So a bit of background, the original version of Athena required users to use the EXPORTNOGRID command and then to convert the EMF to a PNG and then Athena chopped it up into sections and displayed those sections (sometimes) when they popped into the users view in the application. The beta ditched all of that and instead ran a script that exported the underlying data of each tree, bush, road, building, light pole, wire, all of the land data and so on and so on. That data is then used to recreate a drawing of the map instead of using a captured image. Why is that beneficial? Because it lets me do cool sh...stuff like generate height maps or customize the look of forests and so on.. the point is, it's good to have data rather than the images but drawing all of that stuff takes up a large amount of memory. The beta that's currently available tried to control what was drawn at a given time by using what's called a Quad Tree. A Quad Tree divides itself into pieces as you add things to it in such a way that it's easy to supply a rectangle (think of your view of the map [that parts you can see at any given time] as the viewing rectangle) to the Quad Tree and have it hand back everything that falls into that view. It's a very efficient way of displaying huge amounts of objects on a canvas because you don't actually display them on a canvas at one time, you only display what the QT tells you is in the viewing rectangle. The problem with the Quad Tree, in this specific application, was that it added a good deal of overhead. I was asking it to track section of fences a meter long along with thousands of other objects from ARMA ... so the index of items was pretty huge. On top of that, I was asking for it to supply me with a list of objects within the viewing rectangle every time the view changed. So, if you right clicked and dragged the view over 1px, I queried the Quad Tree. If you right clicked and dragged 100px, I queried the quad tree as often as I could as you panned the map for those 100px. So, I asked it several times a second to search through it's catalog of thousands and thousands of objects to tell me which of those objects were available and then I had to purge the objects that fell out of view and draw the ones that came into view. It cut down on memory usage and it did exactly what I asked it to: show me only what I can see but it was sluggish because it tied up the CPU. Instead, I'm back to a tiled approach similar to that of the original version but instead of having you supply the images, I'm using the data provided via the export script to build images at runtime and display them but with a higher visual fidelity. The tiled approach works well. I break each map into 2048*2048 sections and render the objects onto each of those sections. As you pan over it, it pops up an image of that section. As you move away, it drops that image and frees up the memory. Because I'm working with fewer spaces, the querying to see which space is in view at any given time is much faster. It's very similar to what the web based AAR's are doing with their tiles but this is more fluid with a higher visual fidelity and again, this is much more flexible. The images in Athena are rendered 'now' whereas the images in the online AAR tools are rendered at the time when the map was exported. Why is the Athena approach to displaying the map better? Because we can do cool sh...stuff like Height Maps. I'm also going to allow you to specify your own color schemes: Don't like the green I use for forests, choose your own color. Don't like the tree colors, choose your own. Prefer elevation lines to be purple, that's fine. You have that kind of control when you have the data and render the map in real time but when you export an image from ARMA, you get an image, not data and you have to export it at particular zoom levels. Because I'm actually rendering my 'own' version of the ARMA map, I'm drawing geometry and then rendering the geometry into images with a quality specifically according to the current zoom level. It's much more flexible. As you zoom in or out in the online AAR's, it loads a predefined image. As you zoom in or out in Athena, it updates the rendering of the image in real time and tailors it to your zoom level so you get the highest visual fidelity without taking up too much memory. It's a pretty nifty system. Additionally, to make sure that panning and zooming is ultra smooth...paving the way for 'smooth' pinch to zoom...instead of updating the map as the user pans the map or scrolls the mouse (which causes 'skipping'), the map will be re-rendered when the user stops panning and stops pinching to zoom. Because the tiles are 2048*2048, there will be some visible content around the area you're panning. When you release, the non-displayed areas will be filled in immediately. It's kind of hard to convey in words but in usage, you'll see what I mean. The actual viewing of the map and looking around feels much more natural and smooth now.

I planned on making that feature toggle-able and then perhaps to allow the user to specify a list of speeds/zooms so they could customize the effect. Re: the slider, not a bad idea. I'll look into that.

Ok, well, that's a good stress test. It was 'shaking'? Do you mean w/ the auto zoom-in, zoom-out from speed? Yea, that needs refinement. What's happening now is it's unzooming then moving the focus to the player on the next 'frame' update when it should really focus on the player immediately after unzooming so you don't notice that 'shake'. I'm pretty sure the debug options generate a pretty detailed log of what's going on but the log files get pretty huge. Hold off on those for now because I'm not ready to actually bug hunt.