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 :-)