Jump to content

Lukas Jankauskas

vAMSYS Platform Administrator
  • Posts

    199
  • Joined

  • Last visited

  • Days Won

    26

Everything posted by Lukas Jankauskas

  1. 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
  2. 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!
  3. You will need to contact your VA for support.
  4. 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.
  5. Please follow the checkilst: It has a link to our Discord. And as Matt has said above already, Pilot register link is not available until you start your subscription.
  6. If you have in-house tools and developers to make you a custom Pegasus App - let's talk. Otherwise it's a no - we are not in a position to make custom ACARSs.
  7. I had to double-check, as I thought it's the time for monthly update, but I posted one just two weeks (give or take) ago on 24th Jan. You can read it here btw if you have not already. For this out-of-order update I thought I would keep it light and blog-like (read - unstructured). I sometimes like talking to ether and it seems some of you like to read my ramblings. vAMSYS has always been a love-hate relationship for me. It was not something I started or wanted. It was foisted on me in away and I accepted it out of duty and the potential it had. Little did I know back then that this joy would lead to headache years later. Back then it was something I just had to do... This sense of duty has remained - i.e. Lukas, you cannot shut down vAMSYS and just live your life. I think that has, in a way, led to dissatisfaction and disinterest along the way. I need not lie, as you can see the code change history, that there have been months without code changes at a time. I don't know about you, dear reader, but recently I have yet again found myself looking at vAMSYS with enthusiasm and untapped potential which I have not felt for... let's say a while. And it has been good. Welcomed even. So lemme talk about what's new since two weeks ago, yet feels so long ago that prompted me to write this post. Bye bye Bugzilla, hello Vision! As I recently alluded in Discord, I was never a huge fan of bugzilla - it did it's job and I appreciate George setting it up, maintaining it and writing forum posts about it - It just never clicked with me - it was something out of 90s and more functionally dense than what we actually needed, yet not in the way I wanted it. And so it was that bugzilla was my third cousin I never liked, but had to interact with because it's how we chose to organise vAMSYS communication. Not saying it was a bad idea - vAMSYS has grown to the stage where we do need a centralised bug tracking system. I just always felt we could do better. Vision by vAMSYS was this little side project I started to get even more acquainted with Tailwind, Livewire and Alpine with the help of Laracasts (speaking of, if you ever wondered how I know what I know - it's cause of Laracasts. I will leave you to your own conclusions whether I know a lot or very little) to help progress with v4ification of vAMSYS. And I - maybe you too - love Vision. It's one of the reasons I feel so up-beat about vAMSYS again - I got to look over some good ideas I can implement and over the 48 hours since it's been launched Vision has already lent itself to very productive discussions on Discord over the direction of vAMSYS. Not to mention I like how it looks and the fact it is tailored to our needs - issue with voting we had in the past, for example, with Ideas system - eliminated in Vision as Owners and Staff now vote on behalf of their airlines. Vision is a nice little system with potential to change as our operations do. I loved coding it and I love to see you using it and discussing the ideas it results in. How to improve vAMSYS and break it at the same time Or - to rephrase - vAMSYS works really well for me and loads super fast when nobody else can use it. This will be a short story how a long Sunday goes awry very quickly and how bad decisions lead to prolonged downtime. Let's start at the beginning. At home, I am lucky enough to have a spaceship of a PC setup: For those interested... It's... Well... decadent and I am very lucky to be in this position - AMD 7950X, nVidia 4090 FE, 128 GB of RAM, one LG super ultrawide and 2 LG ultrawide monitors. I will not lie - it is amazing to have so much screen real-estate when working on anything. Back on topic - I do most of the coding at home during my downtime. Quite often I will find myself tweaking some code on my HP Envy laptop whilst at work or away or on the way to home. This leads to the need of having a common development environment between the computers I use. Up till Vision came along, I used Laragon - it has been amazing. However, with so much compute power and other benefits it entails, WSL - Windows Subsystem for Linux - became a better choice and it was my go-to when developing Vision both at home at on the move. I fell in love - the power of Ubuntu (same strong stuff powering our beefy servers) running on a windows machine just made things so much easier and faster. Naturally, Vision is running on PHP 8.2. Why that became a problem will soon be obvious. Fast forward to Sunday yesterday - it's time to host vAMSYS Sunday. I do the few bits with Vision and it's time to move on to vAMSYS and VDS work. Naturally, I try and git clone Thunder (codename for vAMSYS codebase) into the WSL ubuntu, but it does not seem to clone for some reason. No biggie - we still have Laragon, so let's work there. Awesome - three hours later vAMSYS Sunday affair is done - thank you everyone who has joined! Time for my break to clear my brain a bit. As is always the case with vAMSYS Sundays, if I have no other errands, it's back to coding. This time, let's figure out what is going wrong. Screw PhpStorm clone tools, we'll do this properly this time and clone in command line. So far so good. I return. Have some issues with npm install - FontAwesome Pro is giving some issues as it's not configured at the WSL instance - I muddle through and I do composer install to ready up Thunder. In the anatomy of 'Where things went wrong' this is the first entry. Since it was a brand new copy, there was no composer.lock and it just picked up the latest and greatest compatible stuff with php8.2 which is running on my WSL - it has been a while, all dependencies we use are 8.2 compatible by now so composer does not give a squeak or a beep. Problem is - vAMSYS is not tested on 8.2 - it's last configured to run on 8.1... So as one goes, I do my thing here and there working on all sorts of stuff (Later on that day I improved my select VA page load times by a factor of a lot) It's now time to commit something I was working on. Envoyer does it's job and all of a sudden... Oops. Ok. Panic mode. Do we revert to last working version, which will take around 30 seconds or just update the system? The correct answer is, has been and always will be - you guessed it - revert to last working version. You wanna guess what I did? Well, you already know: I thought simple. Quickly Teleport into 3 VMs responsible for web rendering, apt-get install php8.2, update and restart nginx to use 8.2-fpm and you're done - 5 mins tops, no biggie. Do I wish I was right. The entire affair took 39 minutes and not all of it is to be blamed on me, I must say. PHP 8.2 install went well - no issues there - installed, FPM running seems good. Switch nginx and stuff seems to be working. Yay. But no yay - my alerts are going off - it works on one of the web servers. Ok - let's re-deploy. Re-deploy gets stuck. Restart server - still stuck. It times out after 5 mins. Ok - worst behind us now. Let's redeploy. Redeploy fails - missing PHP extensions - fffffreaking awesome. Ok, let's install php8.2-pgsql on 3 Virtual Machines and redeploy. Redeploy gets stuck again for server 2. I am now rethinking my life choices and looking at skyscanner for flights to Cuba. Deploy times out again - third time lucky - yes, deployed successfully. I take a breath of air and stop mid-gasp as the familiar cloudy page with 500 error is replaced by the one of chrome default where the page could not resolve. I cry inside. Couple of minutes going through nginx and php logs - file read access denied? What gives? Ooooh, our php needs to use vamsys and not www-data user. Let's fix php config; at the same time I remember to fix execution time, max upload and post sizes in settings - it would've been a problem later on if I did not do it now; whilst there-ish, let's also fix pool config so more than 10 people could load vAMSYS - and presto 39 minutes later we are back fully online (mostly). Now, it is a jumble up there - and if you read it fast enough you will get closer to wearing my shoes that evening - it was busy, confusing and incoherent - welcome to server ops. As a courtesy to you I have omitted all the dead-ends I went to and details of log perusing which led me astray. I will say one thing - had something like this happened 2 years ago - it would have taken longer than 39 minutes to recover. Nonetheless - lessons have been learned - till next php update that is. OpsGenie to the rescue Before I wrap up today, I just wanted to touch on our reporting system real quick and hopefully demystify the thing. George has hooked us up with Newrelic APM - Application Performance Monitoring. We have it tied up with OpsGenie. The result is - if vAMSYS is down - whether it's something we did or a server or a component of it failed - we get to know about it really quickly by notification in private discord channel and a phone call. There is no way we can be unaware of vAMSYS being down unless George and I are both on a flight or in a tunnel at the same time. That is why George and I have never met and never travel together - it's a security risk to vAMSYS 😄 In all seriousness, most of the time we know that vAMSYS is down before you do or your pilots mention it on your Discords. If it happens at 5am, it might take us a little to get out of our beds and fire up the PC to write a message in the #announcements, but when there is a total failure - we know and have been woken up because of it. So let's all do ourselves a favor and stop playing the game of FIRST! and instead just: That's all from me this time - again, sorry if it was poorly written with spelling and grammar mistakes all over the place - I did say this one is gonna be more blog-like as it's not a monthly update - I tend to care more about those 😛 See you next time!
  8. @Nicholas Knottthank you for your message - please join or Discord for community support or send off your question to our helpdesk.
  9. 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.
  10. 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 Vision. Feature requests are created as ideas. https://vamsys.vision Please note that access to Vision by vAMSYS is via Vamsys SSO with your vAMSYS credentials, and is limited to Team vAMSYS, Virtual Airline Owners and their Staff. Users should be aware, that when raising an idea, they do so on behalf of all VAs they are Owners or Staff at and corresponding number of +1s will be applied. 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. To request new functionality is included in the platform, follow these instructions: Search for the feature request on Vision! 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 Idea on the left hand side. Enter a brief Title for your idea - something which describes your feature in one sentence (without being too general i.e. 'My Amazing Idea'). Select the Category the feature relates to (try and select the most specific component that the idea describes; if there is no component or if the bug affects several components then select "Other"; if your feature request would add a new component, then please select the category that would "contain" this new one if possible) 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 suggestions on how it would work? What data it uses and from where? Any additional information you think would be pertinent. Double check your suggestion for any errors or omissions then press Submit. Supporting a feature request It is now again possible to support ideas by +1. However, the 'votes' are applied by VAs, not users. Hence it is not possible to get entire staff team to vote to push the idea up. When deciding on what to tackle next - we look at several things - our time, requests in the system, our own ideas and urgency. Just because idea suggestion has a lot of votes and comments, it does not mean it will be the one to be implemented next. There is no direct relationship between "votes", comments and implementation, and instead the entire request (including comments and votes) will be reviewed holistically in order to gauge popularity. Therefore, if this functionality will benefit your VA, we invite you to both +1 and leave a comment on the feature request 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.
  11. 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!
  12. 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 😄
  13. Yes. Data is data and it is transferable. We use different formats and generally ask for more data than phpVMS, so you will need to put in some work. We have no issues supporting 1000 flights. vAMSYS does not offer functionality to automatically book flights for pilots. They book what they want. As answered above - vAMSYS does not have multiple language support.
  14. 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!
  15. 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
  16. 😄 😄 No, he wasn't. He did proof-read and made some changes after all
  17. 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
  18. How to enable Advanced Cargo System? Advanced Cargo System has 2 'enable' switches. Both are located in Orwell -> Management -> Airline Settings and should be visible to all staff with appropriate access. The switches are located in 'Advanced VDS Settings' section: Show Advanced Cargo Options - enables visibility of settings for staff to set up ACS. It does not activate in Phoenix and is invisible to pilots. This is the switch you should turn on if you want to set up ACS. If you are not interested - this switch should remain off, as you might get confused by additional options which do not apply to you. Enable Advanced Cargo - This switch must only be enabled after you finished the configuration of ACS as per this forum post. Once enabled, pilots will get to experience the ACS. Please note - existing bookings will not be affected. It will only apply to new bookings. How to configure Advanced Cargo System? All steps listed are MANDATORY and must be fully complete for ACS to work. Ensure your cargo aircraft (ones which do not carry passengers) are in their own 'Aircraft Type'. This is done via VDS -> Management -> Aircraft. If you have a mixed fleet list (for example B747 passenger and freighter versions in one type, move the freighters to a new type using 'Add Aircraft Type' button. Give it a different name) Assign Fleet Type to your cargo fleets. This is done via VDS -> Management -> Aircraft only. Expand fleet list of your cargo fleet and click 'Edit Aircraft Type'. In the window which opens, change the Fleet Type from PAX Only to Cargo Only. Be sure to repeat it for all your cargo types. Double-check and insert 'Max Cargo' and 'Max Container Units' for each of your cargo aircraft. This is done via VDS -> Management -> Aircraft or importers. For VDS -> Expand your cargo fleet list and click Edit on each aircraft. Max Cargo is the maximum value in kilograms only (no grams - i.e. full numbers -> 1500 is correct, 1.5 is not). Max Container Units is a new entry. In positive integer only (1, 50, 1000 etc. 50.59 is incorrect) specify maximum available volume in aircraft. We leave up to you how to come up with the value. You can insert maximum number of ULDs aircraft can carry and call it a day. However, for maximum utilization and save you some headache later on when you want to create a pallet loads etc, try coming up with available floorspace and then construct your containers appropriately. Repeat for all cargo aircraft. If you choose to use the importer to edit these numbers, please follow the importer documentation. Create Load Factor Presets You must create at least one Load Factor Preset and declare it to be the Default This is done via VDS -> Management -> Load Factors Please check the note on the Load Factors page and create as many presets as you want. Please use unique names - they are not visible for pilots. All fields are required when creating Load Factor. Load Factor presets allow you to limit how much cargo can be carried on a route, pair or from airport. This is particularly useful if you want to implement a limit on very long routes, where full load is not possible or to better simulate thinner routes. Customize Load Factor assignments. This can be done via VDS. As mentioned - Load factors can be assigned on an airport level, pair level and route level. If no overrides are made, the Default will be used. The order of override is as follows - route -> pair -> airport -> system default. If you choose to use the importer, please follow the importer documentation. Create Containers This done in VDS -> Management -> Containers. Check the note on the page and create as many as you want. All the fields, except notes, are required to create container. Assign Containers This is done in VDS. Containers can be assigned on an airport, pair or route level, depending on your desires. The order of override is as follows - route -> pair -> airport. Enable Advanced Cargo Booking switch in Orwell -> Management -> VDS Settings.
  19. 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!
  20. What is Advanced Cargo System? Advanced Cargo System (ACS for short further down in this post) is our implementation of more detailed cargo loading for cargo airlines. It allows VAs to set up 'container types' detailing what is being loaded (pineapples, engine parts or whatever else may be). This provides greater immersion for the pilot - they pick what cargo they want to carry as well as how much.
  21. Hi! Soundpacks are configured by the Virtual Airline using Orwell -> Management -> Pegasus Sounds. To enable them, or set up a custom soundpack, as a pilot - login to Pegasus, navigate to settings. In the 'Sounds' section, you can enable announcements set up by the VA, or set up your own - be sure to follow the 'Custom Soundpack Guide' provided if you go down that route.
  22. Account merge feature is intended to be used by pilots who have multiple user accounts. For example, I have 2 user accounts - one under a@domain.com, second - b@domain.com. User a@domain.com has pilot accounts VAM0002, ABC1249. User b@domain.com has pilot accounts VAM0004, DEF1587. Instead of maintaining 2 accounts and 2 logins, I can opt to merge them into 1 login under same email. How to merge 2 User Accounts? Login using your 'main' account - main account is the one you wish to retain - in my example, it is a@domain.com. Navigate to My Settings -> Merge User Accounts Section Enter email address of the secondary account - this account will be merged into main account and will stop existing. In my example, I will put b@domain.com Click 'Submit Merge Request' Login to the email of the secondary account (b@domain.com) and approve the merge. vAMSYS will merge the two accounts in under an hour. How does the Merge combine pilot accounts? Depending on Virtual Airline Settings, few things may happen: If you have 2 Pilot Accounts - 1 for each User (VAM0002 and VAM0004 in my example): If VA has 'Pilot Merge - Discard Previous Data' enabled: All data from VAM0004 will be discarded; VAM0002 will remain. If VA has 'Pilot Merge - Discard Previous Data' disabled: All data (bookings, PIREPs, Comments etc.) will be transferred from VAM0004 to to VAM0002 and VAM0004 will be deleted. If your 2 user accounts do not share pilot accounts with same VA: Pilot account will be moved from one user, to the other. In my example - DEF1587 will move from user a@domain.com to b@domain.com. At the end of the merge, using the example above, I will no longer be able to login using b@domain.com - that user will be deleted. My user a@domain.com will contain pilot accounts for VAM0002, ABC1249 and DEF1587. Can Virtual Airline Merge the accounts for me? No, Virtual Airline Staff do not have the ability to combine your user accounts. They can, however, merge pilot accounts which belong to their VA between two users. To do that, VA Staff with prerequisite permissions need to navigate to Orwell -> Pilots -> Merge Accounts and follow the instructions there. If you are a VA Owner or Staff, do not use any of the merge options, else you will lose your staff permissions. Please contact us if you need to merge such account.
×
×
  • Create New...