Mysterious Pilot

OK I will spare you of my findings. Obviously not interested in what can be improved. I will let others do the test work and dedicate myself to just using it. One day you will see what I mean. It would really make your life as a developer easier if you did not take the comments about user's findings so personal. I guess that si a programmer's flaw. Like someone said, they don't see the forest, they see the tree. Cheers and have a good night.

Hi @jori, First of all I am not complaining about phpVMS or kACARS. Software is not bug free and am sorry but no developer is perfect. I post my FINDINGS and offer opinion as to how it could be solved. If on the other hand the developer (in general) does not want to know what can be improved (should he/she wish to) or does not want to hear what is not working or else. Then sorry, it is then better not to put a bugs database or a forum to get feedback. Frankly I do not have to justify my work or life as developer so if you want to question that, then that is YOUR problem, not mine. In my former life as developer I had plenty of open source being used, I got critique about things that could be improved, things that didn't work as well as things that were good. I never felt offended by what MY USER BASE (my CUSTOMERS even though they did not pay a single cent for my free time) wanted to say. Otherwise I could just have had a forum with a single thread "PLease tell me only how great this is". IMHO phpVMS is a very good system but it is NOT PERFECT. Either you want to consider way to decide whether to do something with it or not (it is not my software, I do not decide) then fine. So please, spare me about your opinion about getting some respect. I have that in real life with real paying jobs. BTW kACAS is BETA so that means it is quite OPEN to finding problems that can be resolved. When people say BETA it means too "Please find the problems for me, I can't find it all by myself" which is a fact of life. Trust me, I have been long enough in the business.

Possible and quite valid but in some airlines (like mine-to-be) you don't want them to download the Dash 8-Q400 until they have enough rank and many hours of flight (per rank), otherwise they are stuck with a smaller Turboprop like the delicious Twin Otter. I think what the other VA guy wants can be done with adding a new column to the Downloads table "minrank" and then if it is 0 it has no restriction, otherwise the rank level has to be at least that. Anyway, that is how I would do it but the software isn't mine. He can do the change in the database but in an upgrade it would be gone or probably cause problems.

I went to look at the PIREP admin section and when it was displaying the dashboard I got this error: Open Flash Chart JSON Parse Error [syntax Error] Error at character 0, line 1: 0: <h3>VA Stats:</h3> I don't see anything from with either of the two files where I see "VA Stats" appearing. See attachment.

A few days ago I used v1.0.0.8 and was able to retrieve the flight bid I had made, then I flew my inaugural flight. I now have 1.0.0.9 installed and on my VA site I made a bid for a flight. I have configured (and selected) this VA profile (my only profile). I am also able to log in to my VA ("Logged In" green label). However, when I press the "Get Flight Number Info" It gives me a red label "No Flight Info Found" pressing it subsequently leaves the user with the same red label, not knowing whether it is an old message or doing something :-( If I enter the flight number (complete) in the textbox then it is able to retrieve. My question is, should it not simply retrieve a list of schedules the user has bid on and let him/her select the one he/she means to fly? or do you always have to fill it in? in another ACARs the whole thing is retrieved without having to explicitely enter the flight number. I think, given that one has to enter the flight number I think following the usual practices would be good: 1. Enable the Flight Number textbox when logged in event is processed 2. Disable the Get Flight Info button (Charter checkbox remains enabled) because there is no flight number yet 3. When the user enters a flight number (maybe you can even add a validator on it), something that you at least suspect is a flight number, then enable the Get Flight Info button. If the user empties F.N. again, then disable G.F.I. again. This would enforce certain workflow and there would be less people saying "this doesn't work" (like I just did ;-) BTW I don't see the Load (aircraft) button doing anything other than trying to do something. Getting there, like this ACARS indeed!

Probably today I give it a run with an actual flight. So far I have only been configuring and using the interface. Here a few comments that might be helpful from the standpoint of a user: When the user presses the LOG IN button there is no feedback (until connection is complete) to the user. This is confusing because the user doesn't know "did I press the button?" "Is it doing something?". I think it would be nice to add a progress bar at the bottom with fake progress or a dialog or message saying "Attempting to connect". Once logged in the Logged In message is very difficult to read. Boldface black on dark green is a low contrast combination (maybe lime green?) but it is nice that the color change actually brings the user's eyes to the Logged In message label. Flight Level is a misnomer. There is Flight Level (FL200 = 20,000 feet) and Altitude 9000 feet. Cruise Altitude would be more appropriate. In charter mode you can't select any a/c. You can type it however. When clicking on a button (i.e. when FS is not active) there is no feedback to the user and the application becomes irresponsive until it finishes. I think an Exit menu option in the File menu would be in order, common application standards. A disconnect button (or dynamically change from Connect to Disconnect) would be useful, especially for those who fly multiple airlines. Usually in .NET when programming a windows forms, when the button's Click event handler is called you immediately disable the button (prevent re-triggering and give visual feedback), process the event and at the end of the handler if necessary then enable the button again: public void ConnectButton_Clicked(object sender, EventArgs args) { Button btn = sender as Button; btn.Enabled = false; .... here your event handler logic .... btn.Enabled = true; }

FS Zulu time or FS Local Time? actually both are useful but unfortunately phpVMS does not have support for indicating the UTC offset of an airport which could be useful in matching/deriving fs local time from fs utc. Yup, FS time is crap for what I hear but I never really noticed. However, I did buy FS Realtime which is nice but I think those gadgets are only really noticeable if you fly across timezones.

OK thanks, I read "Site Settings" above and assumed the module had some sort of Admin add-on functionality as well.

Fantastic! this is a great feature. This will definitely enhance the chances of adoption of kACARS by other Virtual Airlines. OK, I uninstalled the old 1.0.0.8 module and application. I installed the 1.0.0.9 application which I am running now with the new VA template and profile. I uploaded the module to the kAcars_Free directory with that same name (kAcars_Free.php). However, when I go to the administration pages in Site Settings I don't see anything to administer kACARS. I want to set it to use FS time instead of system time and check version. What am I missing? Way to go!

That would work if ALL downloads are reachable after a certain rank is achieved. I suppose what he actually meant was to restric the download of certain items depending on the rank level which sounds logical to me. For example, if your fleet has Turboprops and Jets, the Jets packages/liveries wouldn't be available for download until the user achieved the rank appropriate for flying the jets. Another issue (???) is that once the download link is known, a "privileged" (in terms of rank achieved) user can pass the download link (or post it) to a lower "pilot". Anyways, that isn't important.

I added this to the Utility class (Util) in the classes directory: /* * Format time duration in HH:MM rather than present it as it comes * from the database (H.M). Otherwise users assume the duration is * in the decimal base. The format includes a minimum (zero padded) * of two hour digits but automatically adds more as the number of * hours grow beyond 100. */ public static function FormatDuration($duration) { $hours = intval($duration); $minutes = intval(($duration - $hours) * 100); // adjust the number of hour digits $hfl = 2; if (strlen($hours) > 2) $hfl = strlen($hours); $format = "%0" . $hfl . "s:%02s"; return sprintf($format, $hours, $minutes); } And in the files (some templates, etc.) such as layout (but there are many others) I use this: <?php echo Util::FormatDuration($userinfo->totalhours); ?> Instead of just this: <?php echo $userinfo->totalhours; ?> Of course, this goes for totalhours, transferhours, in layout, user profile, vastats etc. Of course, if we are going to reinvent the display of time (like that Swiss Swatch company tried to do years ago) is another thing :-)

I looked right into the database to see how they were stored. Also looked in the obvious places (the web forms) where the duration is always displayed in x.y format leading the user to believe it is a decimal rather than xx:yy which would reflect the actual value stored in the database. I think we disagree there :-) the fix is in the visual (presentation layer), durations (flight time, total flight hours, etc.) which appear in several web pages, should read HH:MM rather than X.Y (decimal form).

Ah, didn't know there were legacy columns in the database. But we are converging to a much simpler solution which limits itself to the presentation layer where the timestamp (in PIREP and Schedules) has to be presented to the user in the correct format (HH:MM) rather than decimal. Much easier fix. Will wait for next upgrade for the rollout, I suppose I can assume that is fixed in the next release, right? and Thanks for the response.

I looked at it in more detail and have confirmed (see attachment) that the PIREP timestamp field in the database has the correct duration timestamp but at that very moment the PIREP is saved an incorrect action is commited by wrongly interpreting a value that is in the base 60 domain as a value in decimal base without applying the conversion factor and this incorrect value is then applied to the flightime field which is what is used to compute (accumulate) pilot hours. The test case (my single PIREP) has the log stating that departure was 22:45 and arrival 23:18, that is 32 MINUTES not 32/100 of an hour (0.32). In other words, the software does this with the duration HH:MM:SS FlightTime = HH + MM / 100 instead of this FlightTime = HH + MM / 60 + SS / (60*60) This anomaly (the bug) is caused by Lines 741 and 742 in function fileReport of the PIREPData.class.php file (the PIREPData class) where it does this: /* Proper timestamp */ $flighttime_stamp = str_replace('.', ':', $pirepdata['flighttime']).':00'; $pirepdata['flighttime'] = str_replace(':', '.', $pirepdata['flighttime']); <--- BUG So, initially the flighttime field in the pirepdata array is correct, i.e. something like 00.32.00 (hh.mm.ss) and gets reformatted (not converted) to a proper timestamp (00:32:00). The problem ocurrs when this gets re-reformated (back to the same) to 0.32. At this moment this should have meant 0 hours 32 minutes but it is simply stored as 0.32 HOURS (which is not the same). As a result ALL displays of pilot flight times are incorrect. It is not clear what the exact string is when the pirep comes, 00:32 or 00:32:00. What is obvious is the simple reformatting of replacing the '.' for ':' and viceversa without actually applying the conversion to the numerical domain (base 60 to base 60). By the way, the same erroneous pattern is exhibited in the creation and editing of schedules. User is asked to enter duration in HH:MM format (00:45) but it gets stored in the database field 'flighttime' as 0.45 (45 minutes is equivalent to 0.75 in decimal base) and then when presented back to the user during edit/display it is shown as 0.45, in other words, wrong notation (contradicting what is asked of the user and the format people are used to) and wrong value as well because if it was going to contradict notation then it should display 0.75 (rather than 0.45) or 00:45. Extra Note (on a slightly different interpretation for a fix): Looking a bit better into the issue, the db value is 00.32. So if you actually meant to store it as that HH.MM rather than decimal hours then the problem is with the REPRESENTATION of this value when it is presented back to the user (on the web browser) rather than presenting as decimal, replace the decimal point by ':'. This is perhaps an easier fix than assuming the flighttime field is in decimal domain, otherwise for the upgrade you would have to provide a script to correct all values in the database. Sorry for being so thorough in my observations and system test :-) Like I said, nothing personal, in my (former) life as a programmer I know how easy it can be to get carried out and forget about little things among so many distractions.

Thanks a milllion mark1million, my workflow can be automated just a bit more but that irons out a lot of the nitty gritty phpVMS details that I would have probably broken in the process :-)

I read well, there he states he wishes to simply approve all PIREPS. He does mention that it is too much to see in the mobile phone but the gist of the question is "how to approve all PIREPs"

Say I have three airlines registered in phpVMS. The first (TRA) is the entry level airline (or for some, the "training" school) and the other two (ALA & ALB) are schedule-based airlines. I know there is no way to keep an airline invisible in the registration form without modifying core code (lost during upgrade). But how can I go about change a pilot's ID, i.e. TRA0025 to another airline's ID, i.e. ALA0025 or if not possible ALAxxxx?

Actually two things come into the game, there is the browser language negotiation and the cookie thing. Every browser has in its options a prioritized list of langugages the user chooses, for example: 1. Spanish, 2. English, 3. French. When the browser fetches a page from a server it sends this information, if the page requested is not available in the 1st choice, the 2nd is returned and if not the 3rd and so on. There is always a default (what the server has available). Then you can also have a cookie to override that if you like. In my previous life I wrote a couple of multilanguage PHP sites and some code to do it. I used a combination of string constants for the string catalog and language especific files, i.e. Registration.en.php/Registration.de.php. Nevertheless it is a touch matter. So it is Internationalization & Globalization. Another issue that should not be overlooked in multilingual websites (if you really want to go that way, which would be nice) is that the number, date, currency and other formats also change accordingly. If not taken care off, a US centric site would gladly accept numbers in 4.5 format and then an European will enter it as 4,5 meaning the same but in the end being interpreted as two different numeric values because of the culture settings. In other words, it isn't so simple and it takes time but it is better to tackle it earlier in the development process than later (more things to review, more tests to be performed).

Yet another reason why we should put a <meta name="robots" content="nofollow,noindex"/> on the document header. It would cause that search engine robots do not index the page or the links in it so the VA won't appear on search results. Sure, you won't get much traffic from the web but that is a small price to pay to protect your head a bit from what CloudSurferUK said about the VA's "brand" overshadowing the real brand.

Well if you want a VA but don't want to spend the time administering the most important thing then you are on the wrong road :-( You don't want people to file just any wild PIREP and approve all of them without even checking. Either you check them yourself to make sure the route is correct and in the proper format, flight level, etc. or "hire" some Assistant and give it restricted administrative rights, you can do that in the Admin Panel and check the Approve PIREP permission.

Nope, I am relying exclusively on phpVMS, not using anything else (other than myself of course). I am using it for what it was intended, perhaps I am pushing it to its limits. That I understand, have currently set it up for auto-active and disabled auto-approve. Thought about that myself but I don't know if manually editing the airline prefix (from TRA to say FSX) to assign them to the actual airline would cause referential integrity problems.

I don't quite understand what you want. As far as I know kACARS does not display any airline banner, it just has buttons and textboxes, that is it. As for the phpVMS site, by default it only displays one banner (not dynamic) and if you have multiple airlines then you are at a loss. In that case you have to look into your own mini slide show or custom coding to show a different banner depending on the airline prefix of the Pilot ID.

Since I am not the developer nor I have the intention to start browsing through all the code I would like to make a consultation regarding the registration workflow. Currently a pilot registers and I believe a confirmation email is sent prior to activation of the account, right? I don't have yet any other hires so I don't know. I won't be open until Jan. 1st. My consultation is with regards to how to integrate alternate workflows without breaking phpVMS nor losing all my changes (and work) during the next upgrade process. The situation (and idea) is this: I don't want pilots to register and become immediately active at the lowest rank (many airlines do), I want quality hires even if that means less recruits. For that purpose I thought of seeing how I could do this without breaking the system (or losing my work). I want for example that candidates (not "new hires" yet) register into the system. This registration would actually have the same workflow as phpVMS currently has, the difference is that the ID assigned in this process would not be that of the airline (or airlines registered in the system schedules), for example TRA (Trainee). To these trainees I would assign 4 levels of ranking (different than pilot ranks). I want the pilot ranks used in the defined airlines to be automatic (based on the number of hours) but the ranking of trainees to be done manually. The trainees would go through a 3 or 4 phase process: - Application (get TRAxxxx account code and base rank) - Upon successful termination of a theoretical exam, the Trainee (TRAxxxx) is assigned the next trainee rank (not yet pilot). - Upon successful completion of an interview the trainee gets upped to the next phase - At last (but sometimes could be omitted) an in-flight examination. After completion of steps 3 or 4 (depending on how "strict" I want to be in the airline application process, the trainee's account is marked as free (for reasignment to another candidate or just leave unused until I reset the trainee pool) and the trainee becomes a "New Hire", in other words it is at this point that the trainee gets assigned an airline code (use an ID from the pool of defined airlines). This can be done either by the admin or by providing the graduated trainee with a link and a confirmation code to make his formal application into the ranks of new hires and start his career to attain promotion to new pilot ranks. Like I said, I would like to see if I can implement this but I don't want to break existing functionality, nor have to redo everything after phpVMS is upgraded. Nabeel, your input on this is greatly appreciated.

I noticed a small flaw in phpVMS with regards to the difference between the system's representation of time and the visual presentation of that time. Some time ago for example I pointed out that in the Schedules form it asks the administrator to enter the duration of the flight in HH:MM format (which is actually the best). However, when this same form is displayed again for editing, the original HH:MM is displayed in a format that contradicts the instructions of the program, i.e. During creation Flight duration: 00:30 Please enter time in HH:MM format During Editing: Flight duration: 0.5 Please enter time in HH:MM format Or if I enter a duration of 00:20 rather than displaying 00:20 (the format it requests) or 0.333 (wrong format but the actual equivalent in decimals) it displays the wrong value, "0.2". Let's not redefine arithmethic :-) 0.2 is the same as 2/10 which is quite different that 20/60 (an hour has 60 minutes). This same flaw appears in other parts where the system displays time, such as in the Pilot's center banner, I performed a flight of 30 minutes (00:30) and rather than displaying I have flown 00:30 or 0.5 it displays 0.3 which is wrong. IMHO the system has to be consistent in its display and interpretation. It asks the user to enter in HH:MM (a format which most humans are familiar with) but it displays it in a different format (even for editing), thus contradicting itself (and confusing the user) and in doing so, also displaying the wrong information. I hope I am not stepping on anybody's toes, this just a remark with the only purpose of making phpVMS a better system than it already is. Nobody is perfect and we users are here not only to use but to test the things that may have escaped the developer.

Yes, there is a charts URL in the Add Airport form and I have filled that and it is also a valid URL within my site. The problem is that when Pilot Briefing page is displayed, it says "No charts are available" (in my case MPMG) and it has a link to www.airnav.com when in reality it should have used the Chart URL I had provided for that airport.