DisposableHero

Yeah, things do change... And if you don't finish something in 3 years it will be the same for future, v7 will continue to evolve, you will always be behind with this logic Good luck and God speed if you believe in one.

What you are doing is not right or was not right Technically you were downloading the source code (from GitHub) and then expecting it to be "install ready" with the vendor folder. Also we do have the latest development branch, with all dependencies linked here at this forum I do agree on that, the documentation needs to be updated (to reflect the latest dev build links properly), and for that some action was already taken but it needs some approval from @Nabeel before being published. So if he can check the changes and approve, the docs will be nicely aligned

Hi Chris, Landing rate tracking is already built in phpVMS v7, if SmartCARS3 provides the data back then you should be able to see, analyze, use for stats, leaderboard etc. For Online Network tracking (IVAO/VATSIM) we do have a module yes, DisposableBasic provides network checks (online/offline) and callsign checks, records the results as additional pirep fields, which then you can develop your own flagging code. Currently DispoBasic can auto reject pireps which are below your defined criteria (along with some other stuff you can define). It also provides some API endpoints to fetch/display data on your landing page (outside phpVMS namespace). You can check the download section and module repository for full features. Also there are some other modules, developed by Taylor mostly (not for the features you asked but he provided nice additions). You can check forum and discord for them too. Hope this helps, enjoy v7

As you may have noticed, phpVMS v7 comes with built in SimBrief API integration and aircraft can be configured in some different ways to achieve better planning results. Below you can find some key instructions and settings with their effects. Main Requirement is a valid SimBrief API key, to get one kindly check SimBrief documents (website/support forum) and complete your application, when you have your key ready, just insert it in settings. While waiting for your API key you can define your Subfleets and Aircraft as below; Subfleet Definitions; Here only important field is "SimBrief Type", when it is defined it will be used for all aircraft under this subfleet. And it simply overwrites the Aircraft ICAO code during planning. If your pilots are using only one simulator (like X-Plane) and only one aircraft addon for this subfleet (like Zibo), then you can simply add your Zibo B737-800X SimBrief Airframe ID here at this field. Aircraft Definitions; This is the most important part, as it allows fine tuned planning compared to a generic subfleet airframe definition. As you can see, we do have the same "SimBrief Type" field here too. This affects only the aircraft, and has priority over the subfleet definition. So if you have a really specific SimBrief Airframe for a particular aircraft and want it to be the default, then you can enter the id here. (Also it is possible to use this field as a replacement ICAO code. Imagine you are using an Airbus CEO but want this aircraft to use Airbus NEO standards at SimBrief, so you define A321 as the ICAO code, but use A21N as the SimBrief Type.) FIN, SELCAL and HEX CODE (ICAO 24-bit, transponder identification code) are optional and have no direct effect on the flight plan you will generate but the weights below are important. When defined, these weights are passed to SimBrief for flight planning purposes, so better define them according to the aircraft you are trying to simulate within phpVMS. You can see that the DOW is empty (0) in the example, this is not a mistake but done on purpose. You will see it later. Using SimBrief Airframes (sb airframes) ; phpVMS is able to get and store all publicly available SimBrief Airframes / SimBrief Layouts during install and update them weekly (with cron), also it is possible for admins to manually trigger an update whenever they wish to. Also it is possible to add your own / custom airframes to the system easily. As like SimBrief itself, airframe definitions are "ICAO Code" based, once you define and save your custom airframe at SimBrief, you can simply copy the airframe ID and add it to phpVMS by giving it a nice looking unique name and the aircraft ICAO type code you wish to use. Also, if you do not want to use the built in SimBrief airframes and have only your custom airframes listed, then you need to enable the respective setting from Admin > Settings. This logic also applies to passenger and baggage weights being used for planning. Imagine you have an airframe definition (either created by you, or a public one provided by SimBrief), using 100 kg for passengers and 20 kg for their bags. But you do not want to use those weights because you have some custom weights for scheduled/non-scheduled flights, even better you control your baggage weights per airport with some custom code etc. Then you need to enable the respective setting to pass in your weights to SimBrief. How does it work, how is the priority logic defined ? Why the DOW is empty in the example ? Subfleet SimBrief Type = Empty Aircraft SimBrief Type = Empty Aircraft ICAO Code = A321 Aircraft DOW = Empty Aircraft MLW = Empty SimBrief Provided Airframes = Fenix A321 IAE, Fenix A321 CFM, ToLiss A321, Your Custom A321 As you know, each addon aircraft have their own basic empty weights and mostly they are hard coded (for SimBrief it is the DOW - Dry Operating Weight / OEW - Operating Empty Weight). So we leave it empty, to be able to use the DOW from SimBrief Airframe definitions. When planning, the dropdown will show you 5 items, the list is above and there will be a "SimBrief Default" entry (which is the basic definitions of SB). If you select Fenix A321 IAE, then its DOW will be used, along with its performance definitions (like fuel factor, engine thrust rating and others), equipment etc. But the weights you defined will be sent to SimBrief to overwrite those values. If you do not select one, it is ok too as the defaults provided by SimBrief along with the data you are sending (like weights and other stuff) will be used. But if you are after precise flight planning, then it is better to either have your main types defined at SimBrief and a matching airframe should be selected. Subfleet SB Type > Aircraft SB Type > Selected Airframe > Aircraft specific details (like weights, SELCAL, HEX, FIN, VA specific custom RMK field) With this order and logic you can have base airframes for your fleet, like PMDG B738, Zibo B738, LevelUp B738 (same example can be extended to Fenix, ToLiss, Aerosoft, Flight Factor group) and then define aircraft specific changes at phpVMS because in a fleet some aircraft have different MZFW or MLW's but they do share the generic specifications. Like a B738 can have 79013, 77000 or 75000 KG MTOW depending on the certification, instead of defining different airframes at SimBrief, you can simply pass that info during planning. Recent changes at SimBrief allow pilots to have precise performance calculations, specific limitations and if certified some nice ETOPS abilities, to be able to use them with phpVMS, defining airframes at SimBrief and using their ID's during planning will be the best option (considering some items still not available at api access, this method will eliminate those cases too). Climb / Cruise / Descent Profiles and Layout Options All these are also obtained from SimBrief and tied to Aircraft ICAO type codes, so when you select an A321 from your fleet to generate a flight plan, you will see the profiles SimBrief offer for that type in general. Additionally the layout is automatically selected if an airline match is found, if not SimBrief Default (LIDO) is used. What about General Aviation and Really Custom Airframe Support GA is supported by SimBrief up to a point, so we do have the same, even though the examples above are based on airliners, logic remains same for GA aircraft too. And you can still define your custom (non-existing airframe at SimBrief) as per their documentation, have a profile for it and use it at phpVMS. Considering that nothing offered by SimBrief, your custom airframe will be the only option at the dropdown. Hope this help, safe flights.

No bad feelings here too Hope you can figure out a solution to the main topic Good luck and safe flights

A waypoint can not be defined as a "destination", that is a fact for flight planning and this can not be changed (not in real life, not in phpvms). What you can do in real life is using ZZZZ as your dep/arr airport and define coordinates in the remarks of your flight plan so the system (and Air Traffic Controller) understands that you will start/end your flight in a specific coordinate instead of an airport. So, if you want to check your pilots fly over certain points (like a waypoint, vor, ndb etc. which have coordinates) you need to build up a listener working either with pirepfiled event or with pirepupdated events to achieve your goal. You may not like it but without knowing the coordinates of those points, you can not get a proper result. vmsAcars sends back position reports and they do have coordinates for you to use in your checks When you know the coordinates of your required point then it will be some amount of math and some coding (to calculate a radius depending how precise you wish to check and searching matching pirep position reports). If the point flown is found or close enough to your requirement then it can pass, else fail. I am not sure if it will be possible, or practical to do these kinds of checks on vmsAcars side. Again you will have to define a specific point and some range for flexibility, use a custom rule to let it being checked live by vmsAcars. vmsAcars checks will run on client side (pilot's computer) and it may not be effective and will be risky if you can not code the custom rule properly (fails, crashes, excessive ram usage etc.). Therefore I would suggest having these kind of deeper checks at phpvms side but in the end, it is up to you to decide and develop Good luck PS: While working on your website for developments, please check the license requirements of Disposable addons and apply necessary changes to comply with them Right now you are violating license terms

You can keep the repo, to share your possible future awards classes if you wish to. There are endless possibilities for awards and with good classes, that repo can be a good community place to participate maybe. My pleasure

Nobody told you that "support" is ended, that is your own conclusion I told you that "development ended for v1 series" and this is not something to stop sales or support. We are testing v2 series and it is "hopefully" near to being released (best kind of support, is an improved new version) as "beta" (at least stable to be a beta and to see how many more bugs will be found by a wider range of users), so no need for being a grumpy old man When it gets to beta, you can download it and use as you wish, but also you can stick with v1, nobody will stop you doing that but the best support you will get for it will be "please upgrade to v2" because nobody will go back to an old code, fix it and release again while a new version is out and live And please until v2 gets released to public (as beta) be patient. 11-12 22:30:37|INFO; Arrived clicked 11-12 22:30:37|INFO; Moved into on block 11-12 22:30:37|INFO; Flight ended manually on taxi on Since you did not shared the entire log, I need some more info; * Which sim was this ? (MSFS, XP11, XP12, Prepar3D, Fsx) * Which aircraft was in use ? * Which airport you landed ? Safe flights.

Don't get this wrong or as a negative review please, but I need to ask this Why do you (or we) need to have a module for awards ? We can define our awards classes and use them, there is nothing stopping us to the that and everything we do will run in an award class, so a module is technically not needed for creating (or having additional) awards. You (or anybody else) can create award classes and share them, just document the needs, share it here in files/addons section PS : I would never award a pilot based on "planned" distance (or anything "planned"), they can extend their route for planning purposes just to fake it slightly on each flight to beat the competition. Just go for the reported/accepted distance Safe flights

Even though development ended for v1 series of vmsAcars, I would kindly suggest you to upload your logs as described here. Maybe they will give us some clues and they can be checked against during v2 alpha releases. (Like trying to re-create the same conditions, same aircraft, same airport etc.) Best wishes,

Ok, thanks for the feedback @MattW strange that I never had it but this definitely looks like something to focus on with @Nabeel I saw similar reports with v1 in which the "arrived clicked" was present in acars logs for no reason, hopefully we will not have it with v2.

More info for future checks ; https://docs.phpvms.net/acars/user-guide#flight-phases "End Flight" and automation for it is possible after landing, during taxi in and at arrived states. There may be a bug in v1 code (worst case)

Most probably it thinks the parking brakes are set (some simulators and aircraft report back braking as parking brake unfortunately). Try enabling the engine shutdown requirement for on block / arrival checks. (Admin > vmsAcars > Settings), maybe it helps. If this fails, we may need to wait for v2 to be in beta state for a wider range of tests, then we can track it if it continues Safe flights

No, it is not excellent and does basically what your plugin does Maybe something more on reporting and progress tracking. Great to see people working on addons for phpvms v7, it is always better to have a widespread and growing community. Thanks for your efforts and module/plugin.