Athena - An ARMA 2nd Screen Application

[turner89 17]

5 hours ago, skruis said:

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".

 

Will give it a try and report back. Let me grab some tea.

[Gruman 122]

Will test as soon as possible. First test will be on Friday evening and will test in MP on Sunday evening.

 

Thank :)

[chortles 263]

skruis, any chance of Athena one day supporting the various game HUD elements introduced for the upcoming Jets DLC? See the "Sensor overhaul" and "Custom info" threads for more details.

[skruis 180]

@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.

[skruis 180]

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:

1. 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.
2. 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).
3. 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.
4. 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.

[Trinket 5]

This will help for people with multiple screens!

[Gruman 122]

Hey Skruis.

 

Sounds like great progress. If the new Beta hits until Saturday / Sunday, then I can test it out directly.

Will use a wired connection this time :).

Do you know that you are basicly reading my mind? Approach & Airport Diagrams support within Athena, MFD Bezels... Awesome.

 

Thanks

[Tankbuster 1733]

51 minutes ago, Gruman said:

Hey Skruis.

 

Sounds like great progress. If the new Beta hits until Saturday / Sunday, then I can test it out directly.

Will use a wired connection this time :).

Do you know that you are basicly reading my mind? Approach & Airport Diagrams support within Athena, MFD Bezels... Awesome.

 

Thanks

He reads my mind sometimes too.

[skruis 180]

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:

1. AAR Vault -  storage and retrieval for community sessions
   1. 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.
2. AAR Sync - playback synchronization
   1. Would allow multiple Athena users to 'sync' the playback of an AAR session so they can review together.
   2. Multiple Sync sessions
      1. One user could be the director or All
      2. Each user could ink
      3. Ink from the AAR would be on 1 layer
      4. Ink from the ongoing review would be on a different layer
3. Ink Sync - Multi Ink for the ACS (Each Athena user sees all other Athena users 'ink')
   1. 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.
      1. This would have the side effect of disabling Multi Ink on public servers (which is actually probably desirable)
      2. This would allow Ink Sync to work with AAR Vault and AAR Sync
4. Map Exchange
   1. When a community member exports a map, they can publish it to the ACS
   2. 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
5. Athena Configuration
   1. 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?

[skruis 180]

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:

1. Athena Relay Form
   1. Provides real time diagnostic information
      1. What clients are registered (updated 2x/s)
      2. What was the last disposable packet queued for delivery (updated as data comes in)
      3. What was the last actual guaranteed packet sent to the registered client (updated as data sent out)
      4. How many guaranteed packets are in the queue waiting to be sent (updated as data comes in and as data goes out)
   2. 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)
2. Process Changes
   1. Again the topology is:
      1. Arma/Scripts/Extension <-> Relay <-> Athena
   2. The relay no longer delivers data from a single queue
      1. It separates data into guaranteed (map export) and disposable (mission updates)
      2. Guaranteed data is delivered first (until the guaranteed queue is 0)
      3. Disposable data is not queued or rather, the queue limit is 1
3. Communication Fixes
   1. 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.
      1. 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.
   2. Problem - The Relay would obsess over registered clients and would continue to attempt to deliver to them until the end of time.
      1. 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.
   3. Problem - The socket connection code was a mess.
      1. Solution - Cleaned the clutter, simplified the process.

 

This should resolve the majority of communications issues between Arma, the Relay and Athena.

[skruis 180]

So, I implemented:

1. 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.
2. 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.
3. 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.
4. 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.

[Jnr4817 215]

excellent work.

[skruis 180]

@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.

[skruis 180]

Making a lot of progress and there are some significant changes.

     

 

Large Version of 1st image

Large Version of 2nd image

 

1. 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.
   1. 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.
      1. The 'layers' control whose positioning some users complained about has been moved to this flyout so it's now 'off the grid'
      2. 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.
      3. 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.
         1. So let's say you've got 7 layers because you're 'monitoring' 6 rooms plus your own personal layer
            1. Personal
            2. Platoon
            3. Squad 1
            4. Squad 2
            5. Squad 3
            6. JTAC
            7. Flight
         2. And you're 'active' on
            1. Flight
         3. You will see all of the ink written to Platoon, Squad 1, Squad 2, Squad 3, JTAC and Flight
         4. Your ink, with Flight being the 'active' layer, will be seen by anyone else that's 'monitoring' the Flight room
         5. You can change which layer is 'active' at any time
2. 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..
   1. How does the ACS work?
      1. 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.
   2. Does it store any data?
      1. 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.
   3. Is it resource hungry?
      1. 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.
   4. What are the benefits of running the ACS?
      1. I'll break this down into three responses
         1. 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.
         2. 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.
         3. Far Future - I've got some crazy sh-stuff planned :-)
3. The ink controls have been greatly improved and relocated
   1. You can go directly to Draw, HighLIGHT, Erase and Select
   2. You can go directly to the color you want
   3. 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:

 

1. Backport some minor socket server process improvements learned while working on the ACS to the Relay and Athena
2. Run through existing other features to make sure they still work (session recording, etc.)
3. Various little GUI improvements
4. 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!

[Gruman 122]

Sorry for no feedback since last week. First I was sick (Flu and an infection) and my game server admin forgot to whitelist Athena last Sunday...

 

Anyway, the newest progress looks very promising. :) 

[Tankbuster 1733]

Will install and try it this evening.

[skruis 180]

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.

[skruis 180]

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.

[fathersarge 46]

My brain just broke, getting back to Arma after a few months away, can't wait to give this a try!!!

[skruis 180]

So there are 2 ways to share ink:

1. Local (within your own environment)
2. 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.

 

[skruis 180]

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.

[skruis 180]

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

 

 

[skruis 180]

And another showing the map export process:

 

 

[skruis 180]

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)

[Gruman 122]

Congrats on the new beta release.

 

Do I get this right. ACS is just an application that needs to run on a system and have its ports opend. Then everybody who wants to use Athena needs to connect to this computers IP?

So I could run this on our dedicated (with remote access) server and then we are set, correct?

 

Thanks.