Leaderboard

2021 on vAMSYS ~ In memory of Graeme Wright, a long-term member of the platform, a well-respected virtual pilot, VA staff member and so much more ~ "Another tumultuous year here. I could not blame anyone, hey - this was me - tad too optimistic last year when I wrote the end of year message. I think we all thought along the same lines - we will vaccinate, we will adjust and life will come back to normal. It did - for a few months in the UK at least. If the lockdowns did anything - together with the re-release of Microsoft Flight Simulator - they have driven a lot of new users to Virtual Airlines. Based on numbers alone, we did better than ever before. This has been a particular high for us all - let's get real - not every day we get an influx of new people joining our very niche hobby. We are trying to do our best in helping our new members in finding their feet when they go the perilous road of staring a Virtual Airline and we want to thank you for pitching in Discord in helping out. vAMSYS in 2021 had to take a second violin for me a lot of the time, hence I could not be prouder to hand off the bulk of the end of year message you can see below to the people you interact with the most - the better half of Team vAMSYS. " - Lukas, vAMSYS LTD "It's over already?", we hear you say - so do we. I am not sure how I would describe the year 2021 - least of all in a concise format - but circumstances notwithstanding, it's been the biggest year yet for the platform - for which we mainly have you, the user, to thank. So brew a cup of tea (George recommends this one, Lukas would rather you opted for this instead) or grab your favourite beverage, have a seat, and let's discuss what 2021 has meant for the Virtual Airline Management System. Let's go back to 2020 We ended 2020 on a high - we finished v3, then migrated everyone over to v3; Anna developed Pegasus, then we moved to using Pegasus exclusively; we started the year with 10 VAs, ended with 30+ - last December we were high on lockdown induced accomplishment fever - we were bright eyed, thinking we can do anything and thus - on the wrong side of Dunning-Kruger curve when we set out our goals for 2021. Don't get us wrong - 2020 has been the best year for us... up until 2021 - we did a lot. With your help - we achieved a lot and hit new milestones in our history, but were a few things we could not do - and it's time to fess up. We ended our 2020 message on our DIscord with the following: Osprey is dead. Osprey was a project to allow VAs to implement their own frontend to the platform, interacting with vAMSYS via a RESTful API. The beauty of our platform, we believe, is that anyone can use it - even if they do not have the technical expertese that was previously required to run a VA (using self hosted software). Due to what we consider to be very little interest in this feature (leading to the feature likely not being used by many if not all VAs) and reprioritisation of projects in preparation for the v4 release, we have decided that Osprey will not be implemented. Discord Bot - towards the end of 2020 we were very happy to be approached by Aidas. He offered his hand and time in developing a universal vAMSYS discord bot for every VA using our services. We were thrilled with the idea - it has often been a requested addition to the vAMSYS repertoire of tricks. Due to the number of ongoing projects this feature is currently somewhat suspended. We know it's something that many of our customers would value, and we will aim to implement Discord integration in a future release. Pegasus Scorers have been delayed due to the continued support of legacy smartCARS integration. It is likely that due to the required changes to the platform that would need to be implemented in order to fully take advantage of the new Pegasus functionality (and the fact that a new version of Pegasus will shortly be in development, which will change how the software works anyway), major new scorers will be deferred until they can be implemented in v4. We will continue to enhance our existing scoring lineup, and where scorers are required to be implemented, will implement less "ground breaking" options in the current version, to be revisited at a later date. v4 - the elephant in the room, which we will touch more on towards the end of this post. Whilst we never made any dates official - we had some internal milestones to hit which we thought were reasonable when we posted the 2020 end of year message. As the phrase goes, "The devil smiles when we make plans. He laughs when we get too busy." Due to less-than-expected development time between the team, we have realigned our internal milestones to more accurately reflect the pressures of a development team consisting of time-limited members. We continue to work towards a release, which we now expect to be some time in 2022. We understand that some of this news is likely disappointing to readers, however we would rather offer more transparency (if at the expense of shattering some expectations). Statistics Our yearly holiday post wouldn't be complete without some mind-boggling statistics we share with you every year, so here we go. In 2021... 9700 of you joined vAMSYS for the first time, bringing the total number of users to just over 37,000 26,543 new VA memberships were created, which is around 2.7 per user more than 80 of our current VAs were created in 2021 - and long may they continue you filed over 195,000 PIREPs, which is around 15 per active user in those PIREPs, you flew for over 1.18 million hours, which is enough time to travel to Mars and back... 91 times, in a rocket (or in George's terms, enough time to make around 890,000 trips from end to end on the Central Line) you also used up just over 1.35 million metric tonnes of fuel - let's hope that electric planes "take flight" soon...? our most frequent pilot filed just over 800 PIREPs representing just over two months of continuous flying - the development team are really impressed, and we will be in touch! All of these statistics represent the reason why we continue to put hours of our free time into vAMSYS, why we are prepared to be woken up at (literally and forcibly, thanks to our alerting systems) every and any hour of the day to fix platform issues and why it's still worth it - because our platform provides a place for people to unwind and do something they enjoy for hours on end (in some cases, hundreds) - and any developer that tells you that's not humbling either isn't telling you the truth, or is not a very good developer. What has changed? Not only did we have some incredible statistics to show off, we're also going to talk about some of the biggest and best changes to vAMSYS this year (in mostly chronological order). We implemented the Network Connectivity Service, which allowed us to produce our first of many VATSIM- and IVAO-based PIREP scorers. We implemented proper management of pilot sharing agreements. We added the advanced fleet and stand override system. We completely replaced our pilot search system with one that's much quicker and more user friendly. We added Forum Management in Orwell, allowing staff to (finally) manage forums with autonomy. We rewrote alert management and maintenance from scratch, which to George's great dismay, made it better than notices. We added the Advanced Cargo System which allowed people to specify exactly what virtual oddities they are transporting around the world. Where does your money go? I am not a huge fan of prividing these numbers, and fear it detracts from our (my) purpose. vAMSYS (and it's very few partner VAs) do not exist to make thousands of pounds. vAMSYS Is a passion project - that's how the team and I came to work on it. We spent time with VAs, started some, managed them - we are all very much a part of the community we aim to support. However, we think it is only right that as paying customers, you see where your membership fees are spent. Here you go. - Lukas vAMSYS is a private limited company in England and Wales with one shareholder (Lukas). All payments are handled by Stripe, an industry standard payment processor. Their policies and compliance documentation are linked on the billing pages in Orwell. As a private limited company, we are required to submit our accounts to regulatory organisations in the UK. They have an address on them - please do not show up unannounced. If you want to meet with Lukas, please just ask him - he will be more than happy to arrange such a meetup. We file accounts every year, however as a small company, we don't need to have them audited by a third party, nor do they need to be particularly detailed. You can gleam from our filing in August 2021 covering 1st March 2020 to 28 Feb 2021 that vAMSYS LTD is not bankrolling the team or our customers - we do not hire Rolls Royce Phantoms and private Embraer jets for trips to our City of London offices. We reinvest almost all of the vAMSYS service fees (sometimes more) we collect from you to provide the services you and your pilots have come to enjoy. Monies (per year), as of 20th December 2022 has been allocated roughly as follows: ~£80 for various domains we use £164 for the alerting systems letting us know day and night if vAMSYS has issues (Opsgenie and New Relic) £760 for ticketing and support systems you use to get in touch (Zendesk) £462 for accounting and mandatory legal fees £655 for code storage, deployment and server management £8,520 for bare metal server costs Were we to hire (assuming it was affordable) the entirity of Team vAMSYS as salaried employees at £30,000 per year, our total cost would increase by another £168,160. Hence all our time, effort and software we use is wholly unpaid. In fact, vAMSYS owes nearly £11,000 in director loans to cover previously incurred expenses. We do have other expenses and overheads which we did not account for here, but these are our recurring costs which your monthly fees pay for. vAMSYS has not paid any dividend nor it will for many years to come. If you think you know how we can do a better job, then please do get in touch! What is going to change? 2022 will see the biggest migration of vAMSYS onto new hardware to date, and we're really excited to show off the results (well - actually, we hope you don't notice anything apart from maybe things getting quicker). Some key things are: Circa £1500 investment in the first few months in new enterprise-level software and hardware, with ongoing renewal and support costs after that. Moving off our current model where everything shares resources onto an enterprise-level virtualization platform. New networking equipment linking servers together, allowing us to sync databases between clones multiple times every second with no latency or impact to the user. 96 cores, 192 threads, 512 GB of RAM and over 4 TB disk space of brand new dedicated infrastructure, linked together at 6 Gbps, and to you at 1 Gbps (if you would like us to do some sort of technical blog, please get in touch). Oh, and apparently there's this thing called "v4" that people have been asking about... not sure about that one though. 😉 We will also invest time into less "physical" - yet still as important - changes, as follows: Increased transparency, telling people what we are working on and why. Moving slowly away from only taking ideas from the vAMSYS Ideas platform, which will allow us to be more flexible and respond more rapidly to change. Moving away from "hard versioning" and towards continuous releases. The retirement of "changelogs" - we will instead publish a regular newsletter comprising of what has been worked on since the last publication, and what is being worked on at the time of publication. We hope these changes will help us engage better with our customers, and we would be delighted to hear any suggestions you have in order to help us do this even better. Please contact George if you would like to make a suggestion. We will obviously need to plan some extensive maintenance for the infrastructure move. If you are a VA owner, please continue to monitor the vAMSYS Discord server for publicity so that you can cascade this to your staff and pilots in good time ahead of any downtime. Closing remarks Whether you filed one PIREP, a hundred or a thousand, you (and your VA staff counterparts) make vAMSYS what it is today. I wouldn't go so far to describe us as "essential" over the last few years, nor are we "key workers" on vAMSYS (although coincidentally, some of the team are in the "real world", as well as some VA staff!), but VAs provide a place for people to go and spend a few hours with like minded individuals, free from judgement, and do something they enjoy - and I think the importance of this to many people over the last year and beyond cannot be understated. The whole team is eternally humbled by the contributions of our many users to the platform - and we hope that you, like us, look forward to what 2022 has to bring. - Anna, Chris, Steve, George and Lukas - collectively, Team vAMSYS

As we taxi towards the end of another remarkable year, all of us at Team vAMSYS are filled with gratitude and excitement. It's been a year of soaring high and covering great distances both for us and for you. Your unwavering support and dedication has been the key to our shared success this year. A Year in the Sky: This year, the virtual airspace turned into a buzzing hub of activity like never before. An incredible 440,000 PIREPs were filed - that's about 1,205 PIREPs daily, proof that your communities are as lively as a 24/7 airport terminal. Your virtual pilots have been racking up flight hours like seasoned captains - a testament to the vibrant and dynamic world you helped create for the ever-increasing number of pilots who chose to fly for your Virtual Airlines. Speaking of flight hours, with a whopping 900,643 hours logged – your pilots have practically been in the air since the Wright brothers first took off! It’s also long enough to watch the entire "Airplane!" movie series about 60,000 times! And let's talk about the distance - an astounding 171,255,449 nautical miles flown. That’s enough to make even the most seasoned globe-trotter’s head spin. In fact, your Virtual Airlines have logged enough miles to reach the International Space Station over 7,000 times! Innovation on the Horizon: As we approach 2024, our commitment to innovation and enhancing the virtual airline experience for both pilots and Virtual Airline Staff is at full throttle. The new year promises exciting changes, ensuring that our journey together continues to be engaging and groundbreaking. We’re excited to confirm that, weather permitting, the vAMSYS v5 open beta for Owners and Staff is preparing for landing before the year's end. We're currently navigating through the final checks and fine-tuning a few remaining tasks. As many of you have seen in our Discord, our progress is on a steady clim. Your ideas and active engagement with each new sneak peek have been critical in making this possible – thank you for being such an integral part of our control tower! With Gratitude: Your choice to use vAMSYS and your active participation in our ongoing development have been pivotal in our journey this year. Your feedback, suggestions, bug reports or just off-topic chat have served as inspiration and a relief in our long-charting the course towards v5. As most of you gear up for the festive season and prepare for your final approach into 2024, we extend our heartfelt thanks for your continued support. To the Owners, Staff and my friends at Team vAMSYS - You are the jet fuel that makes it all possible. Happy Holidays and Blue Skies, Lukas Jankauskas The vAMSYS Team

On v4, continuous updates and infrastructure Continuing on from our recent end of year update, vAMSYS is pleased to provide this further announcement outlining our plans for the new vAMSYS version and the infrastructure changes which will be taking place over the next few months. Updates and semantic versioning Long term members of the platform will know that, for many years, we have been rolling updates into "versions". Versions 1 and 2 were legacy versions of the platform, version 3 is what you are using now and version 4 is what we have been working on. Each version is currently subdivided into further minor releases (for example version 3.8) and then subdivided further into patch releases (3.8.1, for example). This semantic system, whilst allowing the development team to mark changes against milestones, does not, in our use case, make sense. Often, changes are released before the version is bumped and the changelog published. This essentially defeats the point of a semantic versioning system at all. Starting with the next release, we will begin to move away from this system, and instead towards a continuous "release when ready" cycle. This means that as soon as functionality is ready for end users, it will become accessible. Users will no longer need to wait for the corresponding release to be published before they can use features they have been waiting for (which in some cases, have been waiting several weeks for their official release date). You will no longer see version numbers on the platform, for example in the footer. We will provide a method of determining the release you are currently viewing, but this is mainly for internal use, and should not need to be monitored by end users. Instead of changelogs, we will publish a monthly(-ish) update on what we are working on and what has changed since the last update. This also allows us to cover other topics where required (if you have suggestions for what to include in this "newsletter"-type update, please get in touch), and we hope that you will find the first update around the end of January 2022 to be an informative and interesting read. vAMSYS version 4 Now that the preamble for this section has been covered, we can say (with context) that there will be no v4 release. The reason for this is simple - there are no more numbered releases. As discussed in our end of year update, it has become clear that over the last few months the time available to the team to work on the new version is not as high as was originally hoped. It is for this reason that a stark change of tactic is required. We will no longer be "starting from scratch" with v4. Instead, we will take the existing v3 codebase, and begin to make several fundamental updates to it in order to stabilise and prepare the platform for easier addition of functionality. Our starting point will be PHP and Laravel upgrades, followed by code consolidation and implementation of some code we wrote for our internal development version of the former v4. Instead of vAMSYS v4, the version you use currently will be heavily updated. Instead of vAMSYS v3, you will just be using vAMSYS. Feature requests and suggestions We outlined that we would like to eventually move away from the vAMSYS Ideas system for feature requests. This is because internally, we do not consider upvotes as much as the ideas platform makes them out to be - so to continue to use a platform which places so much emphasis on upvotes is, in our opinion, counterintuitive. We are unsure as to what we will be replacing vAMSYS Ideas with at this stage (it will likely be something integrated into the systems we already use internally to track bug reports and confirmed feature additions), so for now, please continue to raise requests via the existing Ideas system. We will be sure to capture all requests in Ideas when moving to a new system to ensure that nothing is lost. If you have any meta-suggestions (suggestions for the suggestions system) then please contact George Peppard via Discord or email (george@vamsys.co.uk). Infrastructure and downtime vAMSYS is investing around £1600 over the next few months in new enterprise-level hardware and software to ensure the platform continues to operate with stability for many years to come. We are currently in early discussion with our server hosting provider to ascertain exactly when this upgrade will be possible (there are some billing complications, as well as some lead time for the hardware to be provisioned in a datacenter), and we will aim to keep downtime to as low a level as possible (this too depends on what can be worked out with the service provider). We are very excited about this and will be sure to provide you with more information regarding our new infrastructure solutions in the future. However, the key takeaway is this: in or before Q2 2022, there will be an unprecedented server and service overhaul, which will result in downtime. Please continue to monitor the vAMSYS Discord server for publicity so that you can inform your pilots, in good time, ahead of any planned outages which will affect them. Conclusion Thank you very much for reading this update. We hope you have found it's content to be useful and we are happy to answer any questions or comments you have either via the vAMSYS Discord server or the comments below. The vAMSYS team would like to congratulate Anna, one of our developers, on graduating with a BSc in Computer Science.

Before we dive in, I want to give you a heads up: this is going to be a lengthy update. I began drafting this several days ago, and my intention is to outline the plans and goals for the upcoming iteration of vAMSYS, which we'll refer to as v5 for simplicity's sake. I also invite you to engage in discussion and share any suggestions you may have. Prelude Long-time customers will remember the hay we made about v4 not being a thing and how we will continiously improve the platform. Should you need a refresher - I will point you to this neat forum post here: Back in January of last year, this approach seemed promising, and we were gradually making progress towards its implementation. However, the past year has brought about significant changes, particularly the departure of half our development team as they pursued new and exciting opportunities. Undoubtedly, this setback has caused some delays. Nevertheless, we've managed to address numerous bugs through hundreds of commits and thousands of lines of code changes, with a particular focus on Orwell and Aeolus (our management tools for administering all VAs utilizing vAMSYS). Considering the direction we're headed, the process of continuous improvement has become slow and arduous due to the inherent challenges we face. Over the past year, I have made it clear in our Discord channel just how tricky it is to maintain outdated code and an inflexible user interface that cannot be easily updated in today's landscape. Therefore, I am pleased to announce that vAMSYS is undergoing a complete rewrite, and v5 is already in the pipeline. Naturally, we won't be starting from scratch and pretending that vAMSYS doesn't exist. Instead, I will incorporate relevant portions of the existing codebase wherever possible, making necessary modifications to better align with our goals of enhanced scalability and easier maintenance. Back in January last year, this seemed to be a good idea and we were slowly inching on the right track to deliver that - however, a lot has happened over the last year - namely having the half of the development team depart for bigger and better things. This has obviously set us back a little - nonetheless, there were 100s of commits and thousands of code line changes to fix bugs - with most changes focused on Orwell and Aeolus (out little management space to administer all VAs using vAMSYS). The way things are progressing, due to the nature of the things we want to change - makes the entire process of continious improvement slow and very cumbersome - there are many reasons for that and I think over the last year I made it clear in Discord how tricky it is to maintain very old code and old UI which cannot be easily changed today. With that in mind, vAMSYS is being re-writen and v5 is in the pipeline. Naturally, we are not starting from 0 and pretending vAMSYS does not exist - I will heavily borrow bits of code where and when I can and where needed re-write it to better suit our needs of better expandability and maintenance. Let's start from the beginning: There's one particular issue that has been bothering me, perhaps unnecessarily. It's the heavy reliance on the vamsys.io domain for every pilot's activity, from registration to daily usage. I believe we have reached a point where this can be changed, allowing vAMSYS to take a less prominent role and instead showcase the VAs themselves. For instance, instead of logging in at vamsys.io, why not allow pilots to go to pilots.yourdomain.com? Please note that the vAMSYS.io login page and the familiar select page will still be available for now. However, with the re-write, I want to provide VAs with more opportunities to be independent and not tied exclusively to the vamsys.io domain. This involves more than just configuring CNAME records for a domain. I will explore possibilities for modifying various email templates and language. I will also remove vAMSYS logos wherever possible and replace them with VA logos. This will require a significant amount of work, but I believe it will be well worth the effort. I find the current feature set of vAMSYS to be highly appealing. The ability to customize CSS allows many VAs to distinguish themselves, and we will definitely retain this option in v5. We aim to make it even more customizable to better suit your needs. Although there are currently no plans to develop a web GUI for this feature, it may be considered for future implementation if there is a strong demand for it. Phoenix I won't delve into specific ideas posted on the vAMSYS Vision, except for those that have been closed where we agreed they won't be implemented. I do want to outline the overall goals for the Phoenix side of the vAMSYS platform. I've always felt that the Phoenix dashboard is too focused on the Virtual Airline itself. While we've made significant changes to make it feel more like a pilot dashboard, I believe more can be done. The Pilot Profile page, which is seldom visited, should be the cornerstone of our design. When a pilot logs into your VA, they should see information about their flights, bookings, and past PIREPs. That should be the primary focus, along with features that enhance their engagement, such as prominently displaying events and a flight list that prioritizes friends instead of showing everyone currently flying in the VA. There are several ideas posted on Vision that align with this goal, and I'll make every effort to implement as many of them as possible. Since we're doing a complete re-write, there will be significant changes to the flight booking routine. Your current needs are vastly different from when the page was initially developed, and it struggles to handle thousands of routes and destinations. Eliminating the pairs functionality will give you more granular control and reduce our code overhead. It may require more work on your end, but the new system will provide you with greater power to set up repositioning flights instead of relying on a couple of on/off switches. The same logic can be expanded to limit jumpseats only on specified routes. I also plan to bring back better filters to filer out destinations, maybe with some global pilot settings - the sky is the limit and even though I won't aim that high, I hope to make big improvements in this area. Additionally, I'll make general improvements and updates to how we handle routes, capturing and displaying information like service days and scheduled departure times to enhance pilot immersion. There will be more note fields and other enhancements that you've suggested over the years. Please hold me accountable to implementing these changes as they are crucial. I'll also revisit the maps once again. It has always been my dream to unify vAMSYS behind a single map, as opposed to the current system of three separate areas: the dispatch map, flight map, and route map. Finding a solution to unify them is challenging, but if I or we can come up with something, I'll definitely give it a try. Moreover, the long-awaited expansion of the event system will finally arrive with v5. Specifically, tours and repeating events will be introduced, addressing a critical and highly requested feature that has been sought after by nearly all VA owners. Another goal I have is to provide better support for charter VAs. Currently, it's a nightmare to allow pilots to fly from any airport to any airport. Let me illustrate this with an example: let's say you are a charter VA serving 200 airports. To allow flights between every airport, you would need a staggering 19,900 routes. This not only creates a logistical challenge but will also pose difficulties in any VDS system as I see it. It's simply not feasible to handle and make usable such a vast number of routes. There is much to figure out in this regard, but one potential solution to consider is offering a route-less VA option. This means that no pre-defined routes provided by the VA would exist, and pilots would simply select their departure and arrival airports. It's an idea worth considering to address the challenges faced by charter VAs. In addition to the goals mentioned earlier, I am also excited to explore the implementation of "pilot awards." This gamification feature would allow you to award pilots with badges based on their flying performance, participation in events, and other noteworthy achievements. While this idea and the goals above are just the tip of the iceberg, I believe there is much more potential to uncover. We will have in-depth discussions at Team vAMSYS headquarters and actively seek your opinions on our Discord. Furthermore, we will always refer to the ideas posted on the vAMSYS Vision for inspiration and guidance as we develop this and other features. Phoenix is almost as neglected in terms of codebase as VDS, and it's starting to show, especially with the increasing load due to the growing number of routes and pilots. vAMSYS v5 aims to deliver a better pilot experience, be more pilot-centric, and enable pilots to engage with your VA more effectively than the current version. I am very excited to start tackling this bit of the platform. Orwell A significant portion of Orwell will serve as the foundation for the new version. The changes I've made to Orwell over the past year have been invaluable in adapting to new practices and have served as a valuable testing ground. However, there are additional enhancements to be made, as I believe Orwell does not currently fulfill its intended purpose. Allow me to outline the goals for the new Orwell. Just as Phoenix is designed for pilots, the new Orwell should be a staff-centric dashboard tailored for VA staff and owners. It will provide an overview of your Virtual Airline's status and offer in-depth insights into statistics. Currently, it is a blend of settings and PIREP review, but I intend to transform it. In my vision, the new Orwell will be teeming with tables and statistics that delve into details, enough to make your head spin. We possess vast amounts of data, and it should be compiled in a meaningful way and presented to you. A modern and practical statistics feature is essential, even though I haven't finalized the specifics yet. I strongly believe that this is the area where Orwell requires the most improvement—to provide you with vital information about your pilots, their bookings, and your routes—because running a VA effectively without such data is, in my view challenging, if not impossible. In the upcoming release, we aim to address the challenge of effectively managing your pilots. Specifically, we will focus on re-writing the Activity feature, particularly regarding pilots re-joining. Additionally, we recognize the importance for VAs to have the ability to ban their pilots from their VA without impacting other customers. We will also aim to provide a mechanism to flag such cases for vAMSYS review, enabling appropriate platform-wide bans, if necessary. Lastly, I intend to incorporate the Vulcan Storage Service (VSS) into the equation, either during or shortly after the v5 release. For those who may have missed the Discord discussion, VSS is designed to replace forum downloads with a more robust implementation. It will grant you better control over file access, allowing you to manage who can download your files. More details about VSS will be shared as we embark on its development process. Orwell is meant to be a tool rather than an immersive experience. With that in mind, my goal is to transform it into something vastly more useful and powerful in the upcoming v5 release. Messaging & Communication I believe it's important to address this topic separately, as it has been a subject of numerous discussions on Discord. The current system of alerts, notices, and notes is a patchwork of features added over time, without effectively addressing the challenge of pilot communication. There are numerous ideas floating around, both in my mind and in the vAMSYS Vision, regarding how we should tackle pilot communication. This encompasses various aspects, such as implementing NOTAMs for rule changes, improving communication regarding invalidated PIREPs, and enhancing staff comments in general. These aspects span both Orwell and Phoenix and will receive significant attention and development time. I envision a superior NOTAMs system to replace the current notices, a fresh approach to alerts, and an improved tracking and acknowledgement system for failed and invalidated PIREPs from the pilot's perspective. I encourage you to continue sharing these ideas and ensure they are documented in the vAMSYS Vision for further consideration. Infrastructure There are no major changes planned for the next 365 days in terms of infrastructure. I am content with our current setup, and although there may be some improvements that could make administrative tasks easier, they are not a high priority at the moment. Managing the infrastructure is not a significant time drain, and it remains at the bottom of the to-do list for now. VDS I have created a dedicated forum topic about VDS and won't delve into it further here. Rest assured, it will receive the same level of attention and necessary improvements to make it a useful feature. API The exciting aspect of current development progress lies in the realm of API expansion. Although our statistics and map json are currently limited, the progress of v5 in my sandbox development area shows promising signs for enhanced API interaction. I can envision a future where a self-hosted vAMSYS utilizing our API can be a possibility, although it is not my primary objective. My focus lies in refining the backend logic and functions, which will eventually pave the way for a global API as a consequence. In the meantime, I would appreciate your input and guidance regarding your specific requirements. I'm more than willing to expand API interactions and incorporate functionalities that meet your needs. Whether it's for your website, Discord bot, or even if you desire to create your own route importer. While expanded API may not be my top priority, establishing a robust backend infrastructure aligns with our ultimate goal and will enable better API access. Pegasus While not directly related to the v5 development, I'd like to briefly mention our future plans. Please note that these are early discussions, as our current priority with Pegasus is to upgrade it to the latest dependency versions and release a stable version with a functional upgrade routine. For the v5 release, no significant changes are planned for the Scorer. All scorers will remain unchanged from v4. Looking ahead, we are considering improvements such as continuous delivery of flight logs. This means that the log will be sent from Pegasus to vAMSYS in real-time as the flight progresses, rather than being sent in its entirety at the end. This opens up possibilities for more interactive real-time flight tracking and provides a better solution for incomplete flights where, for example, a simulator crash interrupts the flight and there is no way to resume it. I am confident that Peter, our team member responsible for Pegasus, has many more ideas in store. We will share them with you at the appropriate time as our development progresses. ---- And there you have it, the broad set of goals for v5. We will work closely with all of you, aiming to fulfill as many feature requests from the vAMSYS Vision as possible. Additionally, I am considering providing regular 'Developer Diaries' to keep you updated on the development stages, give you insight into our progress, and provide an opportunity for feedback. Now, you may be wondering about the timeline. There is no official or set date in mind; it will be completed when it's ready. However, my aim is to have something beta-testable before the end of the year. If you've made it through this entire post, congratulations! Thank you for your time and for choosing vAMSYS as your VA Partner. We appreciate your support and look forward to delivering an even better vAMSYS experience with the upcoming v5 release. If there is anything specific you wish to discuss - our Discord server and #staff-chat is the perfect place for that. I am also hosting vAMSYS Sunday tomorrow (16th July) at 12:00 BST if you want to join and say hello. Till next time!

When? Saturday, 20 May, 01:00 UTC-7 Saturday, 20 May, 02:00 UTC-6 Saturday, 20 May, 04:00 UTC-4 Saturday, 20 May, 09:00 UTC+1 Saturday, 20 May, 10:00 UTC+2 Saturday, 20 May, 11:00 UTC+3 Saturday, 20 May, 16:00 UTC+8 Saturday, 20 May, 18:00 UTC+10 What services will be affected? All vAMSYS services and affiliated websites - this includes: vamsys.io, VDS and Orwell Community Forums Vision by vAMSYS All API responses, including statistics and json data MyNextAirline, and other VA websites we host How long will vAMSYS be offline for? Ideally - 12 hours or less from system shutdown to all systems operational again. The offline period might be longer, might be shorter - to that end, we are exploring couple of creative options in hopes of minimizing the downtime and will let you know if our time estimate changes prior to the day - but once we start we cannot stop and will do our best to return vAMSYS back as quickly as we can - meaning, on the day in question - vAMSYS will be back as soon as we are done without any promises of ETA. For some users the wait might be longer if we need to change DNS records - but we will do our best to avoid it and will try not to leave you at the mercy of your ISP or DNS provider. Can I fly during the outage? Due to the nature of work and rather unpredictable timeline we strongly urge all pilots to finish their flights prior to the start of the maintenance window and do not start new ones. There is a theoretical chance that you will be able to file a PIREP after the systems are back online, but they will be missing position reports and were your sim or Pegasus were to crash - you will not be able to resume tracking. What are we doing and Why? Our servers have been running for over a year now (1 year and 80 days at the time of this writing) and whilst they were receiving constant care and attention, the time has come to rebuild and retool our machines to enable us to effectively manage our infrastructure. Our current setup does not allow us to easily redistribute resources (CPU and RAM allocations) between virtual machines - we used our best guess when we set them up a year ago and some of the numbers are off. The process of realigning our resources involves destructive action and hence the downtime - the web servers and databases cannot run when we move them about. We've already started preparing - we have a breakdown of new Virtual Machine allocations, this time based on hard numbers gathered over the year. In practice, what this all means is that starting next week we'll shift the gear and start preparing for server wipe in earnest - this involves going through our VMs and noting down configurations, taking backups and all the other steps to get ready. In the morning in question we'll take last database backups, zip up forum uploads and attachments and wipe the servers. Once done - we will start rebuilding 20 or so Virtual Machines which power vAMSYS ecosystem. For those of you interested in more nitty gritty technical - we are keeping our two AMD Epyc 7642 servers. We are committed to lease them through to the end of Q1 2024 and we generally like them - they are powerful machines. We are tweaking one of the servers and upping it's RAM from 256 to 512 GB though - this change involves downtime, so now is the perfect time to do it. In addition, we will no longer use VMware virtualization tools, opting for Proxmox VE instead. It's just the right level of 'enterprise' to manage virtualization for us without the cost and complexity of it's predecessor. When all is said and done, we will be in a good position once again with infrastructure setup which is easier to manage and maintain which makes us happy campers.

Hello everyone! I apologise in advance - this may be dense, poorly spaced and in questionable grammar - living up to vAMSYS Standard 🙂 You must know the phrase - it can be done quickly, cheaply or well - pick 2. For almost 8 years, ever since I took vAMSYS, the code was written quickly and cheaply - I was under immense pressure to add features and functionality really quickly - back then vAMSYS replaced a somewhat fully featured airline management system for a shell of it. As I mentioned in the past - foundations I took over were strong - in fact, there are functions which remain unchanged 8 years later and were carried over verbatim from vAMSYS 0.5 to 1, 1.5, 2 and 3. As you know - I am not a web developer - this is not something I do at my job or had previous training or experience with- circumstances led me to learn the tools and gain the skills needed to keep vAMSYS and vRYR going. However - over the last 8 years I have picked up quite a bit - more importantly - the gained knowledge it's what has been helping me go over the code, make improvements and eradicate code deficit where it was not too time consuming, not to mention the value I was able to create at my real job thanks to everything I learned with vAMSYS. PHP world does not stop - nor does Laravel and all the amazing tools you can pair it with - since I restarted work on V4ifying vAMSYS, I got to grips and became familiar with tools which have been a game changer - Laragon for local development environment, Filament for the tables and forms you see in Orwell and VDS, Livewire which ties it all together and Tailwind which makes it all look a bit more pleasing than plain HTML. I am fully aware the V4 project started last year and we are behind your and my expectations of delivery. However, with the latest progress in Orwell and VDS, as well as more reading up and just having more time to think about it - I have found myself to be in a position to crystalize the path to end of V4 - this is what brings us here today. In this forum post I hope to give you the final plan of development and how I will go about achieving it. Orwell It all started with Orwell and it was my first foray into Livewire - a nifty tool for someone who is not in love with javascript to make more user friendly interfaces. Coupled with Filament, these two turbocharged the progress and, I hope, gave you the Orwell pages and tables you find likeable and usable. As of now, there are 6 Orwell pages pending v4ification- PIREP Review, Forum Management, Score Management, PIREP Comment Presets, PIREP Point Presets and Pilot Invite Management. Score management is basically a copy of AutoReject Scorers; Comment and Point preset pages, once done will be a copy or announcement management and Pilot Invite is basically a form - these are all low hanging fruit which, as I mentioned in previous updates, will pluck as and when fill-time is needed between more significant work (i.e. I have 60 minutes - can I do something significant - if not, copy over and edit one of the pages above and have them ready). The only big thing left is PIREP review page. It's a big and very important page - it's the page you visit most often. That is the reason why it is being left for last - to give me time to better learn the tools I am using and improve my technique, so when the time comes - I can do it not quickly and cheaply, but quick and well. That PIREP Review page, in my mind, is so significant, I opted to delay working on - I opted to learn more from experience, pick up best practices before I tackled it and instead jump onto grossly overlooked VDS, which by now is in dire need of attention. VDS VAs using vAMSYS have grown so large and big that VDS, in some cases, is simply not able to cope anymore. There are VAs whose VDS is chronically inaccessible and gives a server timeout error as it takes too long to query and process the data for display. As of the last weekend you have access to VDS Beta - which is a total misnomer - it's VDS early access, where features are made available as they are developed and tested, hence why you are limited to 4 pages - Aircraft, Aircraft Type, Airport and Airport Groups. By my count - in terms of development, I need to do Stands and Advanced Cargo System in management category and - the holy grail - route management. As I mentioned in the previous update posts, vAMSYS is doing away with pairs - they will become the thing of the past. This change ought to cure the remaining nuisances a lot of our VA Partners have - system generated reposition and transfer flights - you will be in a position to set up scheduled (regular) flights, multi-leg routes as well as create custom repositioning flights from and to airports you want, instead of global setting which does it for you with blank routes. Not to mention, you will have the option to designate routes as 'jumpable' giving you the granular control as of yet unseen on vAMSYS. This overhaul is significant - as it will require complete rework of the logic for displaying flights to book, dispatch process and data shared with Pegasus - all of this, I believe, is mostly within our reach without changing a single bit of Phoenix UI code - which is important. Phoenix With your help and your suggestions in Bugzilla, I hope I am working on the best vAMSYS yet, but there is one major obstacle - Phoenix. I hope that after the next few paragraphs you will be able to appreciate the logic behind my madness and understand why I went about things in incremental fashion instead of a big version rollover. For almost all intents and purposes (except absolute emergency for small changes) - Phoenix UI is not editable - that's all the maps, forms, filters, pages etc - anything to do with user interface - I cannot change. What I can do - is tweak the logic behind the scenes - this is what will allow me to retire pairs in VDS without a rebuild of Phoenix. Why can I not make any changes on Phoenix - simple - most of the critical functionality of Phoenix was written in Vue. Due to lack of updates over the years it fell into disrepair significant enough where it would no longer compile under updated versions of Vue and NPM. We did it quick and cheap. I then, more recently, consciously or not took, the decision widely known as 'screw it' - the tools I started using for Orwell and subsequently VDS - now make it unpractical to make Phoenix editable. And by unpractical I mean it needs a full rewrite to make it work again - something I had in my plans for 2 years now. Phoenix has been and remains, for all intents and purposes frozen in state. Unlike Orwell and VDS, it would be a very poor idea to try and incrementally update Phoenix page by page - it would break too much, not to mention wreak absolute havoc to your pilots understanding of how to use the system, not to mention potential bugs which can be introduced or your CSS changes which would become invalid overnight. As I mentioned in the new year post - there are just too many pilots to risk this sort of incremental development in live environment used by thousands. There needs to be a better plan. Plan for vAMSYS I have been broadcasting in vAMSYS updates and our Discord conversations that our path is Orwell -> VDS -> Phoenix. I said there will not be vAMSYS v4 - we are on continuous improvement mode; I said there will be no downtime and we will tick along as we did for the last year. I said all that prematurely. I am fully aware that just the sentence above I basically said I lied - and I kind of did - but the information I gave out at the time was based on current thinking and current plans. Again - there is a reason to my madness - allow me to explain. You will have noticed that no new features have been added to vAMSYS since I started v4ification with Orwell - it was impossible since I cannot edit Phoenix without rewriting it. But I cannot rewrite it as I am still learning good practices whilst redoing Orwell. Then there's all these changes I want to make with VDS - some of which will work with current Phoenix, a lot which will not. Think about it for a while and you end up in circular holding pattern with no exit. The situation where the v4ification of Orwell and VDS - in incremental fashion, page by page- drip by drip has worked well - up till now - it gave me the way to learn and it did not break anything. I alluded before that incremental changes will not translate Phoenix and it will have to be an overnight change (with beta period), but I now realise I was rather naive. See - the incremental Orwell and VDS changes come with back-end code rewrites and improvements. I have changed swaths of logic but I have to fight myself against Phoenix limitations. Limitations I am now starting to grow very tired of, which led me to make the changes to my plan for vAMSYS. I will still mostly follow the plan laid out before - that is Orwell -> VDS -> Phoenix with a caveat - once all the Orwell and VDS pages (with Pair retirement) are done, the current codebase will be put to pasture and I will start anew. Again, sounds drastic - but there is absolute sense to my madness in walking back what I said previously ( no v4) , which was walking back what I am saying now (yes v4). Confusing, I know! The more I think about it, the less I can find a viable, reasonable and efficient path to take the Orwell, VDS and rebuild Phoenix whilst adding new features. There is a number of features I slated for implementation in the new vAMSYS - some of which have bits of code logic written already - but the more I work and wrestle with the current code, the more it exhausts and entraps me like quicksand. Hence the final plan - rewrite-ish vAMSYS. It will not be a clean-slate design (other than Phoenix) - Orwell and VDS code will be transitioned very quickly almost in their entirety - after another review, refactor and improvement. That's the beauty of learning new coding tools and techniques - the very first new pages of Orwell are already due for a rewrite - they were my testbeds for learning and I have since learned how to make it better. So - just to recap, simplify and expand a little: Plan is - finish VDS (sans pairs), finish remaining pages in Orwell. You - VA Owners and Staff have a fully usable Orwell and updated VDS to use. Then I will open a new document and basically copy over the good bits (Orwell and VDS) with no bad bits (Phoenix). Once the good bits are in place, start reworking Phoenix. All these new bits will no be worked on in production environment of vamsys.io - they will be hidden till there is something to show you and your pilots (aka VDS Beta) - I allows me to make all the mistakes and break things as I add stuff without adversely affecting anyone. End result - we will come out with brand new Phoenix, updated Orwell and VDS. Oh, and since database won't change - there will be no downtime for that - it will be, as promised, overnight change once done 🙂 Timeline and Servers I am 80% confident that none of the vAMSYS plans outlined above will require any downtime. I also don't have the exact timeline - but I bet you can sense I am very close to being done with Orwell and VDS. There is one thing - our servers. The current lease for our two amazing 48 core 96 thread AMD EPYC servers ends 27 April 2023. Whilst I do not have a concrete plan as to what the future holds for them (we can renew), I am exploring other options and once there is a decision I will be sure to let you know. If we do opt for a change, there will be downtime needed to transfer the data over. ------- Hope you stuck with me for the full length of this - if there's anything I can clarify - do let me know!

This evening we completed an upgrade to the vAMSYS Community Forums which was the last in a series of planned outages which allows us to deliver changes to how we provide release notes (changelogs) and our knowledgebase. Forum version upgrade Probably the least significant change of the evening, we have upgraded the software powering the forums to the latest version offered by the third party provider. There should be no material change in functionality as it's just a patch release. Changelog migration Currently, our changelogs are stored in one long forum post which becomes more and more painful to maintain as we release more functionality, and is not very user friendly (as the newest releases are at the very end of the thread). We have therefore taken the opportunity to use the functionality originally designed to support the knowledgebase to also provide a better platform for our changelogs - which we have now renamed to Release Notes. The Release Notes should be much easier to browse for end users (the latest releases are shown at the top of the page) and is also much easier for Team vAMSYS to maintain - a win win for all of us! If you currently have alerts set up for when we post new comments to the old changelogs thread, you'll need to follow the release notes using the link at the top of the release notes page. The old forum post will no longer be updated. Knowledgebase migration The most significant change we have delivered is the migration (and quite significant enhancement) of the vAMSYS knowledgebase from the old Atlassian Confluence platform, which is now out-of-support and in growing need of replacement. We are pleased to announce that the most of the vAMSYS knowledgebase from the old platform (and many more new articles describing Orwell features!) are now available to browse by clicking Knowledgebase in the menu at the top. We will continue adding articles covering functionality we have not touched upon yet. The new knowledgebase is a living project and will be continuously updated to remain the number one source for information vAMSYS v3 and upcoming v4 functions. Over the coming weeks we will remove references to the old knowledgebase from the platform and supporting resources and direct members still using the old knowledgebase to the new one on this platform, in preparation for the eventual discontinuation and subsequent removal of the old knowledgebase entirely. Only VA staff and owners can view the knowledgebase - if you have any comments on the content of an article please feel free to leave it a review and let us know how you think we could improve (or what you liked). --- Thank you for bearing with us during these planned outages and we hope you like the improvements we have made to the service we offer. If you have any queries, please follow your normal support routes (escalate to your VA if you are a pilot, or if you are VA staff please contact vAMSYS Customer Services). Many thanks for your support, George and all of Team vAMSYS

Good Luck with the maintenance, and thanks for all you do for the platform.

2022 on vAMSYS It is that time of the year again, where - depending on how old you are and where you grew up - you look forward to Home Alone re-runs or launch of new season of Jack Ryan on Amazon Prime. I've been writing these end of the year posts, in one form or another, since 2014 - it is always a great privilege to be able to sit down and write down some of my thoughts and plans for next year and have a willing audience looking forward to reading it - thank you for that. 2022 has been one of these 'what do you mean it's over?' kind of years, where, on reflection - the year just flew past at supersonic speeds. Statistics Our yearly post wouldn't be complete without some mind-boggling statistics we share with you every year, so here we go. In 2022... 18,525 of you joined vAMSYS for the first time, bringing the total number of users to just over 56,000 56,242 new VA memberships were created - 3.6 per user Over 200 VAs were created on vAMSYS this year. More than 90 of them are currently active - we wish them all best of success Pilots have filed over 602,000 PIREP entities - 314 000 Flight PIREPs and 288 000 Jumpseats. Around 13 Flight PIREPs per active pilot in those PIREPs, users flew for over 668 000 hours - plenty of time to take a roundtrip Concorde journey from LHR to JFK and back 111 thousand times Rewind We have clearly learnt our lesson from 2020 and at the end of last year made no bold promises other infrastructure migration - which I am happy to report was completed on 23rd February 2022. The rest of the year saw bug fixes, small changes and roll-out of the ready pages for the never-ending v4ification of vAMSYS. January: New back-end admin Pages Statistic Generation and Cache fixes, code consolidation Removal of sub-optimal 2FA Fixes to PIREP Claims Fixes to Events Import/Export re-write Send data to SimBrief improvements February: New Select Page New Orwell Dashboard Fixes and updates of Destination Map Work on back-end admin pages New Orwell Alerts page Orwell Pilot Pages Orwell Data pages Orwell Livery Review March: Style updates of the new Orwell design - sidebar collapse option Fixes to jumpseat and jumpseat to base New Settings pages in Orwell - Airline, VDS, Design and Social etc. April: Orwell Page Builder Laravel version upgrades New Billing page Scorer changes May: A round of Bugzilla issue fixes June: Holidays July: New IVAO FPL System Excessive taxi fixes Big round of bugzilla fixes Rank Management in Orwell Staff Management Pages in Orwell August Nothing significant - minor fixes here and there September Nothing significant - minor fixes here and there October Bugzilla round of fixes Login page changes Staff page fixes Other tweaks and improvements related to new VA Application, Billing and access November Fixes to Sounds page Code cleanup and minor error fixing December Work starts on VDS Leaderboard generation changed and API made available 796 code commits this year - 202 more than last year. It has been a busy year, even though oftentimes it looked like nothing is happening and we are moving nowhere. Have we achieved everything we wanted this year? Of course not. But taken in as a whole, and considering the personal circumstances, job requirements and departures of George and Anna from the coding team - I am actually quite impressed we were able to pull this off. v4 - the modern day Moby Dick I know, I know - we agreed there is no such thing as V4, however it has been very convenient when describing what I am currently doing - v4-ifying vAMSYS. What does it actually involve? It's not just a coat of paint where pages get a new design and we call it a day. In some cases - it is; but in most of others, I am rectifying code deficit - entire logic is re-written in many cases with code split and reused better. Up till now vAMSYS was being written fast, not well - v4ifying the thing tries to fix it. We are also rolling out new technology - static php and no-longer-compilable vuejs is being replaced with Livewire. End result - efficient system which makes making changes easy. Onwards to 2023 We are not out of the gas yet and want to continue to work on vAMSYS and continue to deliver the system you want. By the time first half of the year come to an end, I hope to be very close to the end of VDS rewrite and, if luck holds, have other exciting announcement in regards to the platform. In closing, I wanted to say thank you to my friends and vAMSYS Customers - VAs using our system and Owners and Staff managing them. I thank you for your patience, your ideas, money, of course, and the occasional kind word or a joke. Thank you George for making sure our new servers tick along and don't catch fire 🙂 Chris, Matt and Steve - You guys have been the rock and the anchor this year. Picking me up when I'm down or kicking me in the ass when I'm lazy - I could not have asked for better people to help me wield this massive ship and make sure it is heading in the right direction. Thank you captains! 🙂 That will be all for this year - let's not be strangers and talk only once a year - let's meet on vAMSYS Sunday, which will probably be held on a Saturday 😄

6 months ago... Let's say goodbye with a smile, dear Just for a while dear we must part Don't let this parting upset you I'll not forget you, sweetheart We'll meet again Don't know where Don't know when But I know we'll meet again some sunny day Above is for the fans of Vera Lynn and We'll Meet Again. So we do - on a sunny day. In London. Who would have thought. ----------- Since the last update In the last 6 months we've: Update vAMSYS AIRAC data 6 times Made 134 code commits Wrote 76,128 lines of code Deleted 27,672 lines of code Resolved 52 Bugzilla entries Are still working on 8 Bugzilla entries Resolved 249 Support tickets Had 22 outage incidents ranging from <1 minute to 49 minutes Huge thanks to Chris, Steve and Matt for their help! What big things have you missed? Matt joined vAMSYS Support team! Peter joined vAMSYS team! stats.js script was released George and Anna left vAMSYS Team Various noteworthy updates So not much has happened in 6 months? Yes - that's pretty much correct. It has been business pretty much as usual since the last 6 months - did we do all we wanted to? No. Has vAMSYS Disappeared? No. Are we done? Heck no. ------------------------------------------------------- With the summer ending and the travel peak coming to snooze, my time starts to open up. For those of you who do not know - Hello, I'm Lukas! - I work within accommodation industry and summer time is crazy time in London - and summer time peak (thanks Covid!) came in very early this year and lasted longer than ever. Lots of work and often very long hours, not to mention some very difficult to deal with people - but that is being forgotten as we move on with the time. Good news - I am getting less busy. Which means I can do some vAMSYS work at work and when I get back home I do not have the incling to make friends with a 9 gauge, which means I can also do more when I am at home. Work has kept me very busy since the last update - but as I hope you can see above - vAMSYS was far from forgotten. In fact, we were quite productive if you take the limits into consideration and allow us to have some leisure time 🙂 I am also happy to say that Chris has seen an upgrade in his powers and can better react to events should one plague vAMSYS. For certain types of common events or support requests - there is now Chris, George and I who can deal with, not to mention the things Steve and Matt can do. Generally speaking, we are now moving into peak vAMSYS season - as I generally tend to do towards the end of the year. So - what can you look forward to? I've been working on Orwell update for a while - it has been a good training ground for me to get to know the tools which will replace the old ways of doing things without impacting a huge number of people. I would think it went well - in alphabetical order, these are the only pages left to be updated on Orwell: Claim Review Event Management Forum Management Pilot Invites Pilot Sharing Agreements PIREP comment presets PIREP point presets PIREP Review PIREP Scorers Some of them are quick and easy - others - cause me dread when I think of them, as they would result days or weeks of work. They will get done, but I think more value will be made if I refocus my attention to something else. vAMSYS Sundays Whilst I strongly believe that most of Team vAMSYS (that's Chris, George, Matt, Steve and I) are plenty accessible on Discord, emails and support tickets - I can understand how some of you feel otherwise - especially when it comes to me and the forward movement of vAMSYS Platform in general. With that in mind, for a few months, I would like to trial what I call vAMSYS Sundays. Every Sunday, between 16:00 and 18:00 UK time you will find me in the #Stage voice room on vAMSYS NOTAMS Discord under the category of vAMSYS Sunday: I will have my audio plugged in and you will see one of my screens whilst I work on vAMSYS - it may be tickets, bug fixes or features - whatever is more important on that particular occasion. Don't feel the urge to talk to me or say anything - you are more than welcome to observe and listen to me and the sounds of my household going nuts as they usually tend to do 😄 This ought to enable you to interact with me directly in AMA (ask me anything) type of setting both on voice or in #stage-chat discord in text. The purpose is to give you a much easier way for you to connect with me, ask questions and get quick answers. For anything more serious or more involved, if I cannot give immediate answer, I must caveat - I am a human Dory - you will be asked to submit a ticket or post a bug on bugzilla so I can get back to you. vAMSYS Sundays are open to Team vAMSYS, VA Staff and VA Owners on vAMSYS NOTAMs Discord. ----------- Your input required for VDS future I hope you will find this section much more exciting. I'm gonna pick up from above - there is still a fraction of Orwell work to do - some of the pages are very easy, others - I do not want to touch unless I have to. I was perusing error logs, server logs, discord messages and support tickets - one thing was obvious - Orwell works - VDS doesn't. VDS is old and I cannot remember the last time it received a significant update. I'm not saying I am pausing or stopping Orwell update - not at all - the todo list of Orwell is a known quantity and I know what I want to do and (more importantly) how to do it - it will get done. However, I want to start focusing on VDS. Over the years it got extremely neglected and is starting to show it's age (VDS v2 came out 3 or 4 years ago?). Not only is it slow and negatively impacts rest of vAMSYS, it is not friendly. This is where you, dear VA Owner or Staff come in - back in the day when VDS was written, I was fresh with my recently acquired knowledge of what it takes to update routes for 3 VAs. Way back then, VDS was written to my needs to do things as I would do it in a way which made most sense. Over the last 4 years or more the operational knowledge is now lost on me - hence I am going to ask you to tell me - what does VDS need to do to work for you? There are some things I want to do - and I think we will find common ground on those: No more Pairs Pairs are basically an abstraction layer. We can eliminate it - you can have start/end dates (and times!) on routes instead of pairs. Obviously, more thinking needs to be done about how could we do (or not) the empty routes of the past as well as transfer flights. The idea flying around right now is - if you want a placeholder route - you enter it. If you want two airports to have transfer flight - you enter it. Which ties in to: No more 9900s See above - with no pairs, we do not need to invent them. You can create them like regular routes and put whatever route/callsign/aircraft you want No areas Well - not really, but in a way. Lemme know if you use areas a lot and how you use them. My thinking is - areas are a 'thing' right now, it needs to be a 'preset'. More on that here: Granular staff control No more adding VDS staff in VDS. All staff management to move to Orwell. In VDS - each manager can be individually assigned airports they are responsible for (or assign preset group of airports or 'area') Airports in more than one area Just as it says on the tin - one airport, multiple 'areas' with callsign limiting. In terms of fundamental VDS changes - those are my big ones. In this forum post linked - please let me know what you think and - more importantly - what functional changes would you like to see: I hope to start work on VDS at the earliest and focus my time on it - with remaining Orwell pages filling in the gaps where I do not have long enough time for VDS on that particular day or hour. ----------- These monthly updates take a considerable amount of time! I started writing this at 19:30 UK time; this post got published almost 2.5 hours later. Time I maybe could have spent doing something else? Is this the best way I could spend my time? Please let me know!

January 2022 on vAMSYS Welcome to the first of our regular monthly (or thereabouts) updates where we will be describing what has been going on, what we've changed, and what we plan on doing in the coming weeks. This month's update is particularly exiting for us (although probably not for you, the reader!) because we are in the process of taking delivery of two brand new machines which we're migrating the platform onto over the next few months. We've also made some changes to the platform itself - some visible to all our users, some only to our VA staff and owners, and some that aren't visible at all! Grab a cup of tea and some biscuits - let's get into it. Platform Changes As promised in our end of year update, we've made several internal changes to the platform over the last few weeks. Most of these are in the name of improving stability, but some are to make preparations for future changes and upgrades. Some highlights include: Changes how we dispatch scheduled and ad-hoc tasks across the platform to improve stability, especially as the number of VAs increases. Changed some details relating to how we generate and cache (remember) statistics data to improve consistency across the platform. Better support for Chinese characters in some places such as events. Added a more prominent note in case there is an issue with a VA's vAMSYS subscription. Removed two factor authentication for the time being - we'll replace it with a much better system in the future when we re-visit that area of the platform. Various typo fixes and language improvements. CSS changes to make the navigation menu float over the map/exporter/importer selectors. Improvements to our back-end central admin panel, to have a better overview of subscriptions. Improvements to the PIREP claim system to make use of new statistics generator. Applications for VAs on vAMSYS will now automatically reject applications which are duplicates of current customers. Several extensive code consolidation changes. VDS area edits will now correctly hide/unhide and "hub"/"un-hub" an area. Enabling or disabling manual PIREPs in Orwell now functions prototypically. Added 12,339 stands to our stand database. Improvements on how equipment, transponder and PBN codes are sent to SimBrief. Fixed the auto-reject meant to detect in-air refuelling so that it actually detects in-air refuelling. Fixed an issue where in some cases, removal of a stand group was incorrectly propagated across the system (or was not propagated at all). If you are a member of multiple VAs, you may also notice that we have implemented a new select page. This page takes greater advantage of the screen space available to us to display more VAs, and is an example of the look and feel we are going for with our new user interface elements. Over the coming days, weeks and (hopefully not) months, we will start reworking Orwell (our management panel for VA staff) to use this new design and technology. We hope you like it, and we're happy to hear any feedback either directly by email, via our Discord server, or in the comments below this post. Upcoming Changes With the upcoming infrastructure change, we do not want to make any radical code changes which will introduce instability. We will continue to refactor and optimise our code; time permitting, we have our eyes set on a new feature - finally, we hope to start rolling out design changes and related code modifications to Orwell. Scheduling, importers and tasks As part of our changes to task dispatching, we made comprehensive changes to our so-called "hierachy" of tasks. Every minute, hundreds (or thousands) of tasks are queued for the automated processing system to run. The system must decide where to route this job, pull in all the data required (in some cases from hundreds of different locations), execute the job itself and handle monitoring and recording of the result, as well as working out whether there are any follow-up jobs required. Tasks run from really minor things like moving single pilots to their destination when they file a PIREP to more major things like generating flight lists, leaderboards, and parsing and scoring any and every PIREP filed on the platform. If you do something and feedback is not instant, it's likely your actions have triggered one (or in many cases, several) automated jobs which the system then needs to prioritise and execute on top of the hundreds more already scheduled for processing by the system or other users. It is for this reason that we sometimes have to sacrifice performance of one area of the platform in order to make another run faster. In the most recent case, we de-prioritised import and export jobs so that tasks which require more "real-time" feedback (like moving a pilot) can be executed sooner. We never designed imports and exports to be fast or instant - it so happened that in the original implementation this was the case, but this was beginning to take it's toll on other areas of the platform. After we made these changes, some users contacted us to inform us that these tasks were taking a now abnormal amount of time to complete. In response to feedback, we re-prioritised import and export jobs again and we now feel that the current priority strikes a suitable middle ground between speed and reliability of other areas of the platform. File Management We continue to review the many areas of the platform, and are always looking for opportunities to replace or upgrade functionality with a more relevant and intuitive system. The File Manager in Orwell (for VA staff) was implemented quite some time ago, and has seen little to no changes since original implementation. With better ways of accomplishing the same thing now available, we will be retiring the File Manager in Orwell in the coming months. What you should do with files currently in the system depends on what the files are, and what they are for. If the file is a custom stylesheet, we will make provision for you to upload the file directly to the relevant settings page and you will be able to upload the file there instead. If the file is an image for Pages, then we will make provision for you to upload the file directly to Page Management - you will need to upload the file there instead. If the file is a VA resource, then you should use the vAMSYS Community Forums' downloads feature, which is free to all non-trial VAs. Setup is instant and automated, and you can be up and running in minutes. If you have large files, or more complex requirements, then vAMSYS Customer Services will be happy to discuss any custom arrangements for your VA - please get in touch. We are providing advance notice so you can begin to prepare for this change and incorporate these changes into your VA's ways of working. We're happy to answer any questions either directly by email, or in the comments below. Infrastructure It wouldn't be a post from me without mentioning infrastructure (besides - apparently now it's my thing?!). This week, we took delivery of one of our two new dedicated servers. Each server boasts an AMD EPYC processor with 48 cores and 96 threads of processing power, 256 GiB of RAM, and 2 TB of high-speed NVMe SSD storage. Hopefully, we'll take delivery of the other ordered server next week We have now taken delivery of our second server(!), so we will begin to work towards a timeline for migration. Please keep an eye on the usual channels for announcements of downtime so that you can cascade this to your VA, in good time, ahead of any planned maintenance. Conclusion Thanks for reading this month's update! I'm interested to hear what you think about the format, style and relevance of content - please let me know in the comments below this post. Until next month! George (on behalf of the vAMSYS platform team)

We can change the name but it is not possible to change the prefix. You will have to start a new VA if you wish to change

Hey there, I'm trying to create a VA, and I got the email after finishing my application, but following the instructions here it doesn't seem to work. I've tried over multiple accounts, and it still won't let me create a VA. can I get some help?

Hello Lukas, I have strictly followed all the instructions to create several soundpacks inside the same VA, but different folders choice do not appear in the settings tab, and even if I put only one folder inside my VA's folder, we only listen the "default" soundpack provided by the VA. Am I doing something wrong ? Thank you

I'll make it easy for you, your VA was deleted a few moments after you created it as you were attempting to register a restricted callsign. You would have seen an error message when you tried to use the correct callsign. We pride ourselves on our support network but we do expect people to read through the significant amount of documentation that is supplied to VA owners on registration before asking questions. The answer to your question wasn't as simple as "it's here" because there is about 25 steps to complete to configure your VA before you can start adding routes, which is why Chris pointed you back to the checklist.

I understood about the GDPR. I would like to know if you can provide only the vAMSYS ID, IVAO and VATSIM ID. For example: GLO0002 - IVAO XXXXXX VATSIM - XXXXXX We don't need name and email or other information.

Yes - it is resolved.

Hmm yes it shouldn't have got stuck there. We'll look into it for you and come back soon

Forums are managed from Orwell https://orwell.vamsys.io/management/invision

Try Orwell > Management > Forums - then you will get the options within to setup the sub forum titles and permissions. Chris

I agree with the forerunners - Thank you for your "tireless" efforts! Good Luck!

Thank you and I'm keeping my fingers crossed that everything works out. Good luck!

We try and keep the bugs in the platform to a minimum, but the extensiveness of it and the wide variety of use cases means it is almost inevitable that at some point you will experience a bug. This article describes how to report bugs accurately and correctly so that we can fix them as soon as possible. Submitting a good bug report When reporting bugs. try and follow these general principles: Be precise - remember we don't see what you can see, so we need to have precise information in order to find the bug in the first place! Be clear - explain the bug so it can be reproduced One bug per report No bug is too trivial - small bugs may hide big bugs Clearly separate fact from speculation and some preliminaries: Check before you report the bug that you can reproduce it - it may have been fixed Search to see if the bug has already been reported! If you've reproduced the bug and can't find it on Vision already, then this is how you can go about reporting a new issue. Choose Bug on the left hand side. Enter a brief Title for your bug- something which describes the bug in one sentence (without being too general i.e. 'Oh no VA Broken'). Select the Category the bug relates to (try and select the most specific one to the bug you are describing. Select the Component the bug relates to (try and select the most specific component that the bug describes; if there is no component or if the bug affects several components then select "General") Enter the details of the problem report in the description field, including A more detailed reinstatement of the summary. Steps to reproduce the bug including the URL of the page the bug occurs on. Actual results (what the application did when you performed the steps) Expected results (what the application should have done if the bug was not present) Any other useful information - for example - if it only applies to one VA - note which one. Double check your bug report for any errors or omissions then press Submit. Your bug is now in the database, and is awaiting triage in the OPEN state. You will receive emails when the status of the bug changes. You can always leave comments on a bug if you wish for additional information to be noted, or edit the bug.

At present, vAMSYS does not support multi languages for the base website (you can however set your airport names in your native langauge). Payments are handled by our third party provider, Stripe therefore this is not something we can control I'm afraid.

Time flies - it's time for our March update! March 2022 on vAMSYS Infrastructure On this front, the lack of news is good news. Our investment (of both time and money!) in transferring vAMSYS to new servers is paying dividends, and the platform is as stable as it has ever been (and a fair bit faster too). We are not experiencing CPU bottlenecking like before when we want vAMSYS to do some heavy lifting and other than the need to sometimes manually reset the jobs queue - it is going swimmingly well. Here at vAMSYS HQ we are quite happy with how things are and are not expecting any major changes this year. Platform changes over March We have continued our "v4-ification" of Orwell at a reasonable, albeit a bit slower pace than February. At the time of writing, we have completed: VDS Settings Design & Social Pegasus Sounds Pages Billing This only leaves us with the scoring-related pages, forum setup, ranks, staff and pilot invites sections from the management menu, PIREP and PIREP claims on the review side and events! We'd like to see these done by the end of April, but no promises! If you haven't already... The vAMSYS file manager is being retired on the 10th April. You need to make sure that anything you want to keep is moved to an alternative location: for downloads such as checklists and aircraft configs, the forums are your best bet for images embedded in pages, please use the direct upload functionality for CSS, logos, and background images, please upload the files directly on the Design and Social page in Orwell On 10th April, the file manager will be removed from the platform, and any data stored there will be lost forever (a very long time). Bugs, Support and Ideas Support is a key touch-point for us and something we like to try and get right. This extends to bug reports and feature requests. With that in mind, we completely "remastered" the current processes and have what is pretty much a new support (bugs and feature requests inclusive) operation. If you haven't read it yet, we published a comprehensive announcement on this a few weeks ago. April on vAMSYS As mentioned above, our priority remains on completing the Orwell rewrite. Once it's done or we are very close to wrapping it up, we intend to open a consultation on our Discord in regards to the future of VDS. (Not on our Discord yet?) We envisage a week long consultation with VA owners and staff as to what they want to see and do in VDS and how we can make it happen. We'll pull from your submitted ideas/enhancements and, with our combined brain power, are sure to come up with something which will serve us all well into the future. The prime focus of the consultation will not be to implement brand new things affecting flight booking (we cannot really do anything new on current Phoenix), but it will allow us to update VDS in a way which will lay down the foundations for rapid feature implementation during and after the Phoenix upgrade, which we will decide on during the consultation. Phoenix in 2022 I got asked this the other day, so I thought I would make it very clear as to how we will go about upgrading Phoenix when its time comes later this year. Phoenix development will not follow the same approach as Orwell or VDS where we make incremental changes and they are pushed to end-users as soon as they are ready. Our Phoenix approach will be to update it in isolation to the new version. This is primarily because the ability for VAs to add custom CSS overrides (which a lot of VAs have made good use of) does not allow us to change things on-the-go and maintain your design. With that in mind, and probably for the better, as soon as we have something to show, an alpha version will be made available to VA owners and staff. Later in development, we'll make a beta version available to pilots too. This stage will be the longest, as we will be looking to add some of the features requested. The beta stage, where we open them up to pilots, will allow us to see them in use. ~~~~~ Thanks for reading this month's update (and double kudos if you read it all)! If you've any queries, please feel free to get in touch via the usual channels. Until next time! 🙂 - Lukas, George and the vAMSYS team

Hi all, You may have noticed (especially if you are staff) that there have been some trials ongoing recently to determine how best to support our VAs (and to a lesser yet still important extent, their pilots). We are pleased to announce that we have completed our trials and have provisioned the required systems to make the necessary changes, which are detailed in this announcement. Support VA owners and staff may have noticed the trial of a live support chat in Orwell. This was received very well, with the members that used it reporting a high level of satisfaction with it. Unfortunately, after careful deliberation, it has been decided that such approach duplicates existing Discord functionality (which is free) and does not add anything of value (like ticket management) for the cost such chat service provides. Hence we regret to inform that we will not be pursuing live chat support options on vAMSYS at this time. We will continue to evaluate this method of support going into the future, and if possible, we will consider bringing it back. Our review into support systems has, however, led us to reevaluate our current platform. For around a year, we have been using Zendesk to provide ticket-based support to VA staff and some pilots. This platform, whilst looking nice, has given us plenty of headaches in keeping staff and owners synced. In addition, the cost of the platform compared to the benefit over competing solutions has led us to the conclusion that this service no longer economically makes sense. For example, the most popular request from users was the ability to be able to see and respond to their tickets via a web interface. Were we to offer this, our subscription fees to Zendesk would increase by over £60 a month. Therefore, we have installed a brand new helpdesk system (based on osTicket, an open source helpdesk platform) which is now available at https://support.vamsys.io. We have also redirected the hello@vamsys.co.uk email address to open tickets on this new platform. We hope you enjoy using it (as much as it is possible to enjoy a helpdesk system), and we invite you to raise requests either by email or by the new help centre going forward. We have also taken this opportunity to move certain requests away from vAMSYS Customer Services. See the sections below for more information on changes to bug tracking, reporting bugs, and suggesting features. Please remember that vAMSYS is not resourced to provide, and does not provide first line technical support to VA pilots. If you're a VA, please do not send pilots to us for basic queries, we cannot help. If you're a pilot, please contact your VA first for support. Bug tracking and reports vAMSYS has (for as long as I cam remember at least!) used various forms of internal bug and feature tracking software in order to keep track of what needs to be changed about or added to the platform. For (mainly) licensing reasons, we have never been able to open these trackers to users, which meant that our customers did not have visibility on the actual state of their issues after they were reported to vAMSYS Customer Services. This was a key point of frustration for many of our customers, who, not being updated about the status of their bug reports, could not feed this back to users. We have therefore taken the opportunity to install a new bug tracking software which allows any user to register and report bugs directly to vAMSYS. The platform is based on the open-source bug tracker Bugzilla, which is used by several large software projects (including those by the Mozilla Foundation, including the Firefox web browser and Thunderbird mail client). Don't be fooled by the somewhat dated UI - Bugzilla is extremely powerful software, and whilst there may be a slight learning curve, we anticipate that overall the system will provide a much closer connection between users and the developer that is working on their bug report. Key benefits of this new system include: All users will have visibility of all bugs that are being worked on or are under investigation, meaning they do not need to spend time reporting them only for them to be closed as duplicates. Users can add comments to bug reports, for example if they would like to elaborate with additional information. Users can "follow" a bug (i.e. add themselves to the CC list) so that they receive updates when the issue is progressed. The main benefit - users can raise bug reports themselves, immediately, without having to go via vAMSYS Customer Services. This means that hypothetically, any user can raise a bug report, not just VA staff. We have a guide on reporting bugs on the new system, which you should read fully before you use the new system. Please note when registering that your email address can be shown in full to other users, so if you would rather your email address remained private, you should use a different one! Ideas and feature suggestions When we originally implemented vAMSYS Ideas a couple of years ago, many things were different. We had much less customers than we do now, and most customers were on a first-name basis with each other. vAMSYS Ideas was implemented as a place for discussions on features that used to take place in our Discord server to go, and also handled tracking "upvotes" so that popularity of a certain feature could be gauged. However, several VAs have since become disconcerted with this system. The concept of upvotes, whilst useful for gauging popularity, does not usually reflect the number of VAs that want certain functionality (VAs would often have several of their staff upvote a certain idea), and VA owners and staff felt demoralised by the concept of having to "canvas" for upvotes for their ideas. Ideas (which were originally envisioned to be detailed suggestions for a feature) were often submitted with only one or two sentences, meaning the development team did not have the required information to implement the request, leading to further "back and forth" between the users and development team. The ability for any user to request functionality, whilst originally billed as a positive, led to no real distinction between requests submitted by a paying customer and requests submitted by some end users. End users often did not search for duplicates; much of our administrative time for feature requests was spent clearing up the system and merging duplicate suggestions together. It is clear that the current system is no longer fit for purpose, and that drastic change is needed. Note that when we talk about a "poor suggestion", we mean one that does not contain the required detail or one that is inherently flawed, not one that the development team disagrees with. We have therefore designed a new system based on the following principles: Every feature request must be sponsored by a VA. This is the VA that crafts the suggestion, and the primary beneficiary of the feature if it is implemented. All requests must be submitted by VA staff. Users that would like to request something for inclusion should do so by contacting their VA; VAs act as a filter for poor or duplicate suggestions from end users so they do not pollute the system. Feature requests should be detailed, and contain all the information required. Features that contain all the required information, or suggestions for implementation details, often progress much quicker than those that are poorly formed. This too acts as a filter for poor suggestions; it is often not possible to extract the required detail from a poorly formed suggestion, so if the person submitting the request cannot do this, then neither can we. We will spend more time reviewing and managing requests, as it improves the overall quality of the suggestion list. We will act as a further guard for poor suggestions entering the system, with the view that any suggestion that makes it through review could be implemented. Requests that can never (or will never) be implemented will not be left in the system. We will inform VAs if suggestions are unrealistic or will not be implemented, providing a reason, so that VAs that submit suggestions are not left in the dark as to whether we intend to implement functionality. Feature requests should encourage debate and discussion, with people supporting the request often adding further elaboration to it. We will not track popularity of requests by arbitrary vote counters. VAs that support a request can add comments to it, elaborating further and continuing to develop the suggestion right through to implementation. Feature requests will be evaluated based on merit to our customers. Any feature request that passes review and has healthy discussion, and is fully developed, should be implemented. We provide no timeframes for implementation, but we do not want feature requests to "rot". If we have the time, we will implement a well-formed and highly-requested suggestion. The Bugzilla platform used for bug reporting and tracking can also track enhancements. We have decided to (ab)use this functionality for tracking feature requests, as the overall structure of the platform will (we believe) encourage a more healthy debate on feature requests, encouraging VAs to submit fully fleshed out suggestions, or express their interest in existing suggestions by adding useful and constructive comments to them. Our article on reporting bugs also contains details on requesting features. If you currently have ideas on the vAMSYS Ideas platform, we invite you to enter the ideas into Bugzilla. We are offering you this chance because we currently do not store a sponsoring VA in Ideas, yet we would like to capture this information if possible. After a couple of weeks, we will go through the ideas list and copy across any that have not already been moved but we consider to be either highly-requested or important requests. You do not need to migrate your ideas yourself if you do not want to, but doing so allows the suggestion to be correctly attributed to you and your VA, and you will receive the relevant emails. To conclude We hope that these changes improve our support and feature request system for everyone, and that they continue to support our ever-growing platform into 2022 and beyond. If you have any questions or comments, then please feel free to either leave a comment below, or contact vAMSYS Customer Services. George

This post is now superseded by -------- We try and keep the bugs in the platform to a minimum, but the extensiveness of it and the wide variety of use cases means it is almost inevitable that at some point you will experience a bug. This article describes how to report bugs accurately and correctly so that we can fix them as soon as possible. What is Bugzilla? Bugzilla is our installation of the upstream software of the same name. We now use it to track unconfirmed and confirmed bugs through from when they are reported all the way to resolution. We previously used YouTrack and Jira to handle this. We plan to soon migrate idea tracking to Bugzilla in some form, although how this will be done remains to be seen. vAMSYS developers have full access to Bugzilla - that is, they can do everything. vAMSYS community support staff have an elevated level of access to Bugzilla that allows them to edit all bugs, regardless of who reported them. All other users can view and comment on all bugs, can submit new bugs, but cannot edit bugs that do not belong to them. The anatomy of a bug Bugs in Bugzilla have the following information associated with them: the product is the root level project that the bug is associated with; for most bugs this will be "vAMSYS" the component is the part of the product that the bug is associated with the version is the version in which the bug is exhibited - as we do not track versions for most products, this will usually be "rolling" the status can be one of UNCONFIRMED, CONFIRMED, IN_PROGRESS, RESOLVED and VERIFIED; some statuses have more information associated with them (for example, an issue can be RESOLVED FIXED or also RESOLVED WONTFIX); for non-staff users, this will be set to UNCONFIRMED until it is reviewed by staff the severity is a measure of how "important" a bug is; it's important to think in terms of overall importance and not just how important a certain bug is to you (an exception to this rule is the severity "enhancement" is used to represent new features or ideas) the hardware and OS can be used to capture information about the platform you are seeing a bug on the assignee is the person who is held accountable for the resolution of this bug - by default this will be the vAMSYS developer who has overall accountability for the component you selected, but the assignee of an issue is often changed later to the developer who is working on the bug the CC field allows you to specify any other users who are key stakeholders in the bug the orig. est field allows you to specify an original estimate in hours for how long the issue will take to resolve the deadline specifies the date by which the bug should be resolved the URL can be filled to include a URL to link the bug to the summary and description allow you to describe the bug; the summary field should contain a brief summary of the issue and the description field can be used to elaborate further you may add an attachment to a bug depends on, blocks and see also allow related bugs to be specified the priority of an issue is populated after the issue is filed, and represents how high priority the issue is to be resolved Not all fields must be filled (in fact only a product, component, version and summary are actually required). You may not have permission in your role to edit some (or most) of these fields - do not worry, fields you cannot edit will be populated by the staff member that carries out the triage for your issue (that is, checks over the issue and confirms it, as well as assigning it a priority and severity). Submitting a good bug report The most bugs can get the most timely attention if users adhere to good practice when submitting bugs. Bugzilla already has a fairly comprehensive set of guidelines on reporting bugs, which we encourage all reporters to read. In general, reporting bugs generally follows down to some principles: Be precise - remember we don't see what you can see, so we need to have precise information in order to find the bug in the first place! Be clear - explain the bug so it can be reproduced One bug per report No bug is too trivial - small bugs may hide big bugs Clearly separate fact from speculation and some preliminaries: Check before you report the bug that you can reproduce it - it may have been fixed Search to see if the bug has already been reported! If you've reproduced the bug and can't find it on Bugzilla already, then this is how you can go about reporting a new issue. Choose Enter a new bug. Select the product in which the bug is located (for most bugs, this is "vAMSYS"). You may be automatically sent past this step. Select the Component the bug relates to (try and select the most specific component that the bug describes; if there is no component or if the bug affects several components then select "General") Enter a summary, describing the bug in 60 characters or less. A good summary should quickly and uniquely describe a bug report. It should explain the problem, not the solution. Enter the details of the problem report in the description field, including A more detailed reinstatement of the summary. Steps to reproduce the bug including the URL of the page the bug occurs on. Actual results (what the application did when you performed the steps) Expected results (what the application should have done if the bug was not present) Any other useful information - for example - if it only applies to one VA - note which one. Double check your bug report for any errors or omissions then press Commit. Your bug is now in the database, and (provided you are not a Bugzilla moderator) is awaiting triage in the UNCONFIRMED state. You will receive emails when the status of the bug changes. You can always leave comments on a bug if you wish for additional information to be noted, or edit the bug. Submitting an idea or feature request vAMSYS VA owners (or their staff) are able to request the addition of new functionality to the platform. Previously this was accomplished via a dedicated "ideas" platform, however in order to consolidate information on changes to the platform we have moved this process also to Bugzilla. Feature requests are created as bugs, but must be created with the "enhancement" severity. Please note that if you do not hold a VA staff position, or are not a VA owner, then your feature request will be automatically dismissed. You should contact your VA staff and ask them to consider raising the request on your behalf. VA staff should note that when raising a request on behalf of their VA, it is considered the VAs opinion that the requested feature should be added. If a VA does not agree with the request put forward by a user, they are within their rights (and we recommend that they do) to politely decline. If this is the case, no Bugzilla entry needs to be created. Feature requests require a VA sponsor to be considered. When requesting functionality we suggest you follow these tips: Be clear and concise, but include the required details. Tell us why this change would benefit your VA. If you have any ideas about how the feature would work, then please include them! Even if our implementation is slightly different, this is helpful for us. Most importantly, make sure your VA owner is aware of the fact you are raising this request! It is their VA that will be sponsoring the change, and they probably won't be happy if their name is attributed to something they had no idea about! To request new functionality is included in the platform, follow these instructions: Search for the feature request on Bugzilla! If it has already been created, you may wish to add a comment expressing your support. See Supporting a feature request for more information. Choose Enter a new bug. Select the product in which the feature will be located (for most requests, this is "vAMSYS"). You may be automatically sent past this step. Select the Component the feature relates to (try and select the most specific component that the bug describes; if there is no component or if the bug affects several components then select "General"; if your feature request would add a new component, then please select the component that would "contain" this new one if possible) Enter a summary, describing the request in 60 characters or less. A good summary should quickly and uniquely describe the requested feature, and should not include any suggestions for implementation. It should describe what you would like to be achieved, not how to get there. Enter the details of the suggestion in the description field, including A more detailed reinstatement of the summary. What group of people within your VA this change would benefit, and why. Roughly what proportion of your VAs users (or staff, if this is a request for staff-only functionality) the change would benefit. Any background relating to the change request. For example, did you previously have this functionality on another platform? Any additional information you think would be pertinent. Enter the Feature request sponsor VA's three letter pilot ID prefix (for example, if you are VAM0002, the prefix is VAM). Please only enter the prefix of a VA in which you are staff. If you do not see this field, then you have not selected enhancement as the severity. Go back and select this now, then complete this field. Double check your suggestion for any errors or omissions then press Commit. Supporting a feature request Previously, it was possible to vote for an idea to express support. The intention of this was good, but often manifested in a VA getting their entire staff team to vote for their idea, artificially inflating the popularity of a given idea. This led many VA owners and staff to feel that this "canvassing" was necessary to get an idea through to implementation, which left many owners with negative opinions of the system. This also presented issues for vAMSYS developers - we had no idea how the feature would impact a certain VA, or what VAs it would impact. To try and curb these issues, and mainly to try and encourage a healthy debate around the inclusion of new functionality, we have removed the previous "voting" system, instead allowing members to comment on a feature request on Bugzilla to express their support. There is no direct relationship between "votes" (or in this case comments) and implementation, and instead the entire request (including comments) will be reviewed holistically in order to gauge popularity. Therefore, if this functionality will benefit your VA, we invite you to leave a comment on the feature request on Bugzilla explaining why your VA would also like the feature implemented. This need not be any longer than a couple of sentences, but you may wish to (and of course, you are welcome to) elaborate further, for example if you have further suggestions or requirements for the implementation.

As you might have seen - vAMSYS logo has changed and there are no quirky loading messages on Select page and within Orwell, where the new design has been implemented. Neither Team vAMSYS, nor I am immune to feelings or emotions - we are not robots - I believe our temporary logo makes it quite clear where and with who do we stand. I look in awe at the determination, resilience and sacrifices of the Ukrainian People and their military to protect their country - be it alone and on their own. We Stand firmly in Solidarity and sorrow with the People of Ukraine as shocking events continue to unfold. (Discord #announcements - 25th February 2022) ---------- End of February update! Are you excited? I am, as I get to write this one and George may or may not hold my hand writing it. So let's get cracking. Server Migration 23rd of February was our migration day. This was the 3rd time in vAMSYS history where we significantly overhauled our infrastructure. As the rarity of such event implies - this was a massive change and it involved half-a-day worth of downtime. I would like to thank all our friends for actively disseminating the migration information, not making a criminal case out of scheduled downtime and working with their pilots to make sure they are aware of what is going on so neither of us get bogged down with support requests - your participation and understanding made it the easiest and least distracting of migrations we have done so far, and the first migration where I kept a running commentary/log of what we were doing in #announcements chat of our Discord - hope it was useful and kept you in the loop. We have mentioned it before, but I'll put it here again - we consolidated multiple bare-metal servers leased from OVH (our service provider) into 2 much more powerful machines - power of which you have already noticed and told us about. We are delighted to hear that it had immediate positive impact. This migration has set us up for at least a year if not more. Our new infrastructure is made up of 2 identical servers with following specs each: AMD Epyc 7642 CPU (48 Cores, 96 Threads; Base clock of 2.3 GHz, tubo up to 3.3 GHz), 256 GB ECC 2933MHz RAM; 2x480 GB SATA SSDs and 2x1.92TB NVMe SSDs. Servers and their resources are split into Virtual Machines (VMs) of various importance to our operations and CPUs/RAM/Space as needed. We hold 40 IPv4 addresses - some in reserve for our future needs, others actively in use for our virtual machines responsible for every facet of vAMSYS functionality. Allow me to briefly summarise our current structure of VMs: 1 Primary Database (PSQL) VM accepting write requests (inserts into database - think of new bookings, new pilots) and limited read requests; 2 Secondary Databases (PSQL) VMs serving 95% of all read requests of the database (as the name implies - reading all the data in our database - pretty much everything you see); 2 vAMSYS.io web VMs - they are responsible for rendering the php and pulling the data for you to see and make bookings on; 1 MYSQL database VM - used exclusively by Invision Power Board forums, known as vAMSYS Community Forums; 1 Redis database VM - our volatile storage storing temporary information, like the minute-by-minute flight lists and data for the maps; 1 Neo4J database VM - our graph database responsible for providing data for maps to draw a line airways and waypoints and validating routes inserted by VAs; 1 Load Balancer VM - responsible for splitting requests between databases and web servers equally and fairly. It also secures our various exposed endpoints to https; 1 Forum VM - self explanatory; 1 Weather VM - again - should be obvious - it provides and keeps historical record of ATISes and TAFs; 1 Mapper VM - responsible for providing map images on booking, destination, PIREP review, event and other pages - basically - every map you see is rendered by our in-house server; 1 MNA VM - yes, MNA still receives support from vAMSYS; 1 DirectAdmin VM - provides emails for Team vAMSYS, hosts our 'corporate' website, as well as homepages for some VAs; 1 Worker VM - one of the most-critical virtual machines in our use which is responsible for all scheduled and as-needed tasks, like PIREP processing. We spent a month talking about it, a month preparing for it and a week implementing it, but our infrastructure migration has been successful - at the time of writing this post - entire migration has been complete and, other than the scheduled downtime where we transferred PSQL database only, none of you were any wiser of all the other things going on and happening seamlessly. Today, the last 3 remaining old servers have been put to pasture and re-rented to other companies and hobbyists. Platform changes over February February has also been very busy and productive as far as our code refactor and style updates went. There were 240 code change commits to our codebase (8.5 a day). I have kept updating everyone in #v3-changes chat in Discord, but I'll summarise it here for posterity: New Select VA page - faster and in-line with our new design; Updates to Team vAMSYS internal pages (called Aeolus, from Greek mythology, a divine keeper of the winds and king of the mythical, floating island of Aiolia) - with code improvements and new design; Minor change to route importer, where route is now optional; Announcements Orwell sub-menu receiving new vAMSYS styling and corresponding code improvements; Pilots Orwell sub-menu receiving new vAMSYS styling, corresponding code improvements and rich datatables enabling you to more easily find what you need; Major changes to Orwell Data sub-menu where Importers and Exporters live, notably - the introduction of validator and a complete rewrite of importer/exporter logic. We are yet to have a stuck importer due to improperly formatted data; Temporary solution for allowing VAs to utilise SimBrief Aircraft IDs when their pilots dispatch via SimBrief; PIREP List, Livery List and Livery review received updates as well; Significant change how and when destination maps are generated; Live-chat addition to new Orwell pages; There were also a few platform fixes and improvements not covered: Zendesk user sync fixes; IVAO network data parser fixes and resilience improvements; Fixes to logos in emails; Fixes to Engine Scorers (Number2FirstThen3Dual and Number4FirstThen3Dual); Improvements to VATSIM pre-file; Improvements to how and what data is sent to SimBrief in Dispatch; Individual VA login pages now bypass Select page when logging in with email; Fixes to PIREPs marked as needing reply; Fixes to transfer/repositioning flights now showing up correctly in Book Flight page; Addition of hide sidebar button. Short-term changes to vAMYS I think it's fair to say 50% of Orwell is done - we will continue working on Orwell in the following order - Management Sub-Options followed by Events, followed by PIREP Review and finishing with Pages. Once we are done with Orwell, we will proceed with VDS. We made meaningful progress this month - mostly because George was able to make the time and work on migration and I took 2 weeks of holidays from work, which allowed me to dedicate those weeks solely to vAMSYS. As much as I would like to - I cannot guarantee the same level of progress in March - we are, however - just as, if not more, committed and eager to improve the system. New vAMSYS Features General Outlook As our upgrading/updating efforts continue, we cannot and will not make promises on new features - in fact, they are currently deprioritised. There are a few reasons for this - the three bits of vAMSYS (Phoenix, Orwell and VDS) are heavily interlinked - I cannot add a new setting in Orwell which will affect something happening in Phoenix; similar with VDS. Only when all the three systems are updated to the 'new' way, can we entertain the possibility of making real and significant functionality changes you have put forward on our Ideas platform. I want to set the record perfectly clear - our current efforts are solely focused on refactoring the code and improving usability - be it with clearer options, faster pages or less quirky/incoherent behaviour. We will add, where we can, self-contained features and your submitted ideas where they do not interact with other non-updated bits of vAMSYS. Once all this done, we will be in position to add the features we all agree vAMSYS needs to gain. That does not, by any means, mean your suggestions are thrown out, ignored or forgotten. Ideas platform is there for this exact purpose - a place for you to make suggestions for improvement which we can look into in an organised fashion - as opposed to disjointed discord messages or emails. POSCON There has been a recent influx in feature requests for POSCON network connectivity implementation from our users - we are aware similar requests have been made to other companies in the virtual aviation world as well. vAMSYS supports any online network, and we are happy to allow users to enter network IDs for VA staff to monitor and report to network administrative staff. We implement functionality based mainly on time to implement and the impact we think it will have on users, with features that impact upon many users ranked as higher priority for implementation than those that impact fewer users. We recently implemented the ability for users to specify their POSCON network ID in the settings. This was a relatively simple change to make with minimal development time. There are, so far, 11 users with a POSCON ID entered, across the entire platform. It is therefore not currently in the best interest of the largest majority of users (or even customers - i.e. VA owners) to implement network connectivity scoring for this network, as this takes hours of development time to implement and, even assuming that only 1% of POSCON users that use our platform have entered an ID (which is a generous estimate), would only reach around 1,000 users. Our platform currently has over 30,000 registered users, and the actual number of POSCON users is likely much smaller. We will continue to evaluate the priority of this request and will provide any updates as and when we are ready to provide them, but unless we make an announcement, it is highly likely there have been no changes. Platform Changes We have begun reevaluating on how we support you - our customers. We can spend all the time in the world making changes and tweaks, but it would be pointless if we did not listen to your needs and your feedback. Historically, Discord has been our first line of immediate support if we are online, with Zendesk (email tickets) as fallback and fill-in for things we cannot solve right away or are offline. As you might have gleaned from end of year update - vAMSYS is not rich, nor does have a lot of income to throw around - with that in mind, we are seriously considering if £60 per month for Zendesk, which is a glorified inbox, is even affordable to vAMSYS LTD, taking into account the new server costs, let alone delivering value for the price. We have started experimenting with a chat-based system, which, so far, has received a very positive response from you. Having 'staffed' the livechat for a couple of days - I can say I am happy too and was able to connect with some Staff members who are not on Discord - it is fair to say that this option will remain and will displace Discord as preferred first line of support in due time. We must, however, work out how we can tie-in the chat-based system to help us keep track of issues which are not instantly solvable. We got a few ideas and we are exploring them in the month on March. Last, but not least - we listened to your feedback about Ideas platform and how ideas should be prioritised and voted on. Whilst we do not have anything concrete yet - it is on our minds. ---------- Couple of messages before I close off this monthly update: Do join me in saying congratulations to Anna. And consider supporting George in 27 27 run to raise funds for Mind charity - more on it here https://discord.com/channels/398186537952477196/398187082696228875/947981324369666108 Till next month! Lukas

😄 😄 No, he wasn't. He did proof-read and made some changes after all

I think the question on everyone's mind is this... was @George Peppardactually holding your hand?

For action: vAMSYS system migration (this announcement is targeted at VA staff - if you're a pilot, please wait for an announcement from your VA) Unless you've been living under a rock for the last few months (or are one of our newer customers - in which case, welcome!) you will have heard of the large infrastructure upgrades that are currently being worked on across the entire platform to deliver a more stable experience for all our users. Most parts of this migration can be done silently, without affecting users - this is the approach we have so far taken and will continue to take, slowly migrating groups of users onto the new systems until all users are accessing the "new" hosts, at which point the "old" host, Atlas, can be switched off one last time and retired. However, there are a couple of parts of the maintenance in which we will be required to prevent users from accessing the platform - these are the parts of the maintenance related to the database, where we need the state of our data to remain constant for a long period of time, without any changes, to ensure no data is lost, duplicated or corrupted. The vAMSYS platform will be UNAVAILABLE on WEDNESDAY 23RD FEBRUARY from 1600 UTC until 2300 UTC. This includes the `vamsys.io` website, Pegasus, the vAMSYS Community Forums and associated services. You will NOT be able to book flights, file PIREPs or access the platform IN ANY WAY. Flights in progress may continue to track BUT WILL NOT REPORT BACK TO THE CENTRAL SERVER. YOU SHOULD NOT START FLYING IF YOU WILL NOT FILE YOUR PIREP BEFORE THE MAINTENANCE PERIOD BEGINS. Action required NOW: - We recommend each VA delegates overall responsibility for communication to pilots for this outage to one person. This person should claim this communication and see it through to resolution. - Cascade this communication to the rest of your VA staff and begin to formulate some publicity to communicate this to pilots in good time before the outage. - Begin to determine whether pilots will be able to manually claim for lost hours and points during the outage (we recommend using our PIREP claim system), and devise a strategy for processing claims. Action required IN GOOD TIME before maintenance, ideally BY MID-DAY ON TUESDAY: - Cascade publicity to pilots via various channels to inform them of the impending outage. vAMSYS staff will add a global announcement banner, **VAs do not need to add alerts or notices unless they wish to add additional information**. Important Information - It is our experience (and that of several of our VAs) that many pilots will either not see the various forms of publicity provided, or ignore it, and will therefore request support from your VA. We would recommend implementing some method to prevent users from requesting support with vAMSYS (we recommend if you have a platform support channel in your Discord server that it is locked - there is no way to have issues with the platform when the platform is not available to pilots). - We do not, and will not for this outage, provide first line support to pilots. Pilots that contact vAMSYS Customer Services to report the outage will only delay support for VA owners, and will receive a (to them) dissatisfactory response referring them back to your VA. - Please do not contact vAMSYS Customer Services, via the helpdesk or Discord, to report this outage. Doing so will only delay completion - we are a small team (the team that can deal with infrastructure problems is even smaller), and time spent responding to erroneous outage reports is time spent *not* carrying out the planned maintenance. We apologise for any inconvenience this may cause.

Yeah, Lukas knocked it out a couple weeks ago

Thanks for the update, and congrats on the servers! My only feedback on the new selection page is as follows: 😁

Well done Anna!

vAMSYS 3.9.0 should be the last minor v3 release adding new functionality. 3.9.0 introduces long awaited and much requested advanced cargo system. Our huge thanks goes to the team at Cargolux Virtual for their request and their help in fleshing out the feature. We consider Advance Cargo System feature complete from v3 standpoint. There might be some bug-fixes and minor changes, but we consider it to be a good start. The system will be expanded in v4 and some of the functionality will be made available for PAX airlines as well. We have posted a detailed article about what the system is, how to enable said system and configure it. Please be sure to follow it meticulously if you are interested. Please continue to report bugs via the usual channels. If you are a VA pilot, please escalate bugs via your VA. If you are VA staff, please report any issues to vAMSYS Customer Services. Thanks for flying vAMSYS!

If you read the announcements on the previous forum, you would remember the big deal we made about this website becoming available. Well, with the changes made in vAMSYS 3.7.0, it's back and even better than before. vAMSYS 3.7.0 makes fundamental changes to the way forum/downloads sections are provisioned and managed. Many aspects of the running of the forum are now in the hands of the VA staff - this reduces the level of intervention needed from vAMSYS Customer Services in order to modify certain aspects of the forum. VA owners (or staff with access to the Management area of Orwell) can now access Invision Management. Invision Management (or Forum Management in the menu) is the all new way for VAs to manage their forums and downloads sections. It allows you to create and rename both subforums and downloads categories. It also allows you to toggle whether the parent downloads section is writeable (by VA pilots, not just moderators) or not. This release also adds the Forum Moderator permission to Orwell. Members of VA staff that have this permission flag will automatically be synced as forum moderators for your VA by the Invision Service. This means that in addition to being able to set up your forum by yourself, you will not be required to submit a ticket to vAMSYS Customer Services to modify these permissions. Finally, vAMSYS 3.7.0 includes several other changes, such as fixes for some VDS issues and issues where some pilots could not submit claims. In addition, we have completely removed the legacy pilot search functionality - Pilot Search v3 (now referred to as simply Pilot Search) is now the only way to query the pilots database for your VA. This release also includes general performance enhancements, bugfixes, and quality of life improvements to other functionality. As always, you can view the detailed changelog at the following link: Thank you for flying vAMSYS!