Hello everyone, your resident birb has some updates for you that may or may not make you cranky or rejoice!

Let me preface this by saying that with the release of each new combat zone, we learn a lot of good and new information. Ok so let's see here... the last major update your all got from us was about how we're trying to mitigate potential abuse vectors when it comes to ship combat, which led to the NUMEROUS discussions... pretty much everywhere about how upset everyone was that we were going to allow Frigates and above to be targeted by combat, but while not returning fire since we are still wating for some features to be developed before we're comfortable to allow them to shoot back. We understand why this made many of you upset, but I asked you to trust me that some features were in the works to help mitigate this. Let's discuss the whole picture below:

Frigates+ Taking Damage
As you know, we are enabling frigates to be targeted by combat-enabled ships. The main reason for this was to prevent groups/individuals from using Frigates and above for transporting materials down to a planet, essentially just sailing past a blockade and building cities unhindered. This is especially important to consider since the removal of Arrest/Execute where in the past, the main defense someone had was to execute another character's builders, halting construction of key facilities, or at least delaying them. The first step in this process should ideally be a way to set up a planetary blockade and prevent access to a planet without permission or a fight. Remember, that this change will take effect in just under a week(Y25 D239 is the no earlier than date).

Temporary Armour Values
That being said, we have listened to the feedback and as of this latest sync, all Frigates and above have a DEFAULT AND TEMPORARY armour value set on them (70-90 depending on class) to allow them to take a hit more easily. Let me emphasize yet again that this armour value is TEMPORARY. This number WILL CHANGE when stats are finalized with the stat overhaul that will pave the way for Ship R&D. The rules page will not display this information, but it will show up under the ship details in your inventory.

Hyperspace Entry Point(HEP) Protection

The next main feature we have to help mitigate Frigates+ (and actually, this applies to ALL ship types) is HEP Protection. Each system has 8 HEPs (noted in the above picture) which is where your ship exits the Hyperspace layer back into the System layer. The point you exit onto depends on where you entered the Hyperspace layer(aka if you started at system 0,0 and travelled due east, you would exit on the westmost HEP[white]). 
HEP Protection will be a 24-hour timer that prevents you from being targeted by combat while the timer is active. ANY action performed by a ship with HEP (kicking ships, starting travel, initiating combat, etc.) will immediately remove your HEP Protection. This timer is intended to allow some sort of relief for pilots who, for instance, enter a combat-enabled system but are not present when they exit, and would normally be immediately attacked with no other recourse. 
There is a rules page for this feature, but it will not be visible until the feature is enabled. The current plan is to enable HEP Protection at the same time we enable Frigates+ to be targeted in combat zones.

These are just some of the features to help mitigate Frigates+ being targetable. The end goal is still to make all ships fully combat-enabled, but we still have a few more features that need to take place before that can happen.

One final note I'd like to make is to discuss the development process because this feature seemed to highlight the fact that not everyone knows/understands how that works:

1. The first step in the development process is for a member of a SWC Team to make a proposal document and post it to our submissions area. Typically this is done by members of our Rules or Dev teams, but this is not always the case (for instance, HEP Protection and Frigate+ targeting was made by an entirely separate member). Proposal documents are not just "hey we should do this" documents. They are well-prepared documents that descibe exactly how a proposed feature will work, being as specific as possible. 
2. Next, the submission is tagged for the specific teams that need to weigh in or sign off on the feature. 99% of the time, an Asim is involved in this process at a minimum. While Asims rarely do any actual development, we do sign off on features and/or provide restrictions (such as requiring a 30-day notice for feature release). (The exception to Step 2 is small QoL features or minor features that minimally impact gameplay. These are not common). During step 2, a full discussion is heald amongst all relevant teams to fully flesh out the proposal.
3. Once a consensus is reached on how the feature should be implemented, then a developer is assigned to actually code/implement the feature as described. Sometimes this step takes us a bit further into discussion on clarifying portions of the feature, etc. 
4. Once a feature is coded, it is pushed to our Dev Server and assigned to the QA team to test. Their job is to essentially find ways to break and exploit these features so that we can patch/fix them prior to final release.
5. The final step is for the feature to be pushed to main where inevitably the general community will find new ways to break it where you all can enjoy the new feature. Asims are kept in the loop about when a feature will be synced.

As you can see, the development process is not one where the devs operate in a vacuum with minimal oversight. Feature development is a team process and requiresparticipation from multiple teams.

That's all for today, but as always, please feel free to submit a support ticket for any issues you encounter or reach out with any feedback/suggestions you have.