Leaderboard

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

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.

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

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!

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!

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.