Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Messages - Timothee

Pages: 1 2 [3] 4 5 6
Support for VAM 2.4 - 2.6 / Re: VA Parameter Crash
« on: November 30, 2017, 06:45:07 PM »
Ok if you do not use flight wear for planes you probably didn't notice it. Flight wear should also be applied to charter flights with VA airplanes. But it doesn't work and is the same problem as your crashes not beeing detected.

The function move_charter_aircraft() in receivevampireps.php checks for the parameter 'aircraftreg' to be set, but SIMAcars probably never sets it. It was just empty in all my tests. However there is the parameter 'aircraft_registry' which contains what we are looking for.

There are different was to fix this problem, but the easiest way is probably as described below.

Line 791 (original file) contains the following code:
Code: [Select]
move_charter_aircraft ($aircraftreg,$gvauser_id, $dep, $arr , $flight_duration,  $block_fuel, $distance , $landing_vs , $flight ,$db);

Change the first paramater to $aircraft_registry:
Code: [Select]
move_charter_aircraft ($aircraft_registry,$gvauser_id, $dep, $arr , $flight_duration,  $block_fuel, $distance , $landing_vs , $flight ,$db);

Support for VAM 2.4 - 2.6 / Re: VA Parameter Crash
« on: November 28, 2017, 02:30:41 PM »
As you mentioned receivevampirep.php is using the function abs() for the landing VS. Therefore the parameter has to be positive. Until recently this function was not part of the original source code but if you are using VAM 2.6.2 you are fine with using positive values.

We haven't used charter flights at all, so I can't tell from experience if its working. Do you see status reductions on charter flights or is it just the crash which was undetected?

Try adding an index to the va_finances table (column report_id).

I do not recommend deleting any flights.

Support for SIM ACARS / Landing heading
« on: June 19, 2017, 09:41:53 AM »

The final flight reports contain the value "landing heading". This value does not correspond with the actual heading during landing but with the final position when the flight is ended (for exmaple gate position).
As an example: I landed in LEBB on Runway 30, I would expect the landing heading is somewhere near 300° but SIM ACARS reported 9°.

Would be nice if you could correct this in the next SIM ACARS version.

Support for Installation / Re: Instalation problems v.2.6
« on: June 04, 2017, 11:33:06 PM »
Looks like your hoster does not allow to create views, at least your user doesn't have the required permissions.
I suggest you look for another hoster.

Support for SIM ACARS / Re: P3D v4 and SIMACARS
« on: June 01, 2017, 05:35:49 PM »
As far as I see there is already a new version available. I haven't tested it and I don't know if it works together with SIM ACARS. Some features seem to be missing but they shouldn't be relevant.

Just (finally) did the upgrade to 2.6.2 on my site. The only issue is that the LATEST FLIGHTS portion of the website is only showing the Last three flights. VAMS 2.5 showed the last 5. Where can I change that?

Thanks for the assistance.

Thats odd, the latest flights are based on the view v_last_5_flights, which obviously implies it should show the latest five by default.
While upgrading did you create a new database and imported the data? I think Alejandro said somewhere that views should never be imported and instead should be recreated.

Support for VAM 2.4 - 2.6 / Re: Flight auto cancellation issue
« on: May 29, 2017, 03:50:09 PM »

The text in your screenshot is hardcoded and part of the language files (BOOK_ROUTE_CONFIRM). Unfortunately it does not depend on the parameter. However, the bookings are deleted in review_reserves.php and there your settings are used for the calculation.

Support for SIM ACARS / Re: Taxi to gate
« on: May 29, 2017, 01:11:32 PM »
In this case it would be nice if you could rewrite that part a bit. For example if landing detected + GS<=25 triggers taxi to gate, it would prevent a taxi speed penalty during rollout.
At the moment I assume it's not based on GS.

Support for VAM 2.4 - 2.6 / Re: Manual Pirep validation very slow
« on: May 21, 2017, 08:23:55 PM »
Thanks, indexes created correctly will help always  ;)
One of the topic I want to enhance is the DB performance adding indexes and fine tuning some big queries
I did the calculations when the flight is validated because doing it while inserting the flight via SIM ACARS it could lead into timeout in SIM ACARS

Thanks for the insight ;)

Support for VAM 2.4 - 2.6 / Re: Manual Pirep validation very slow
« on: May 11, 2017, 11:55:55 AM »
Thanks for the data. You don't have as much rows as I expected.

I did some tests and at least in our VA, the most time gets lost with calculate_flight_finances.php. It takes about 17 seconds of runtime. Every other script which is executed during flight validation has a runtime of less than 0.1 seconds.
I created a simple script with the slowest query I found:
Code: [Select]
$db = new mysqli($db_host $db_username $db_password $db_database);
if ($db->connect_errno 0) {
die('Unable to connect to database [' $db->connect_error ']');

$time_start microtime(true);
$sql "select SQL_NO_CACHE gvauser_id, flightid, flight_duration,pax, cargo, block_fuel, distance, route_id,DATE_FORMAT(flight_date,'%Y%m%d') as flight_date from vampireps where validated=1 and flightid not in (select distinct(report_id) from va_finances where report_id is not NULL)";
if (!$result $db->query($sql)) {
die('There was an error running the query [' $db->error ']');
$time_end microtime(true) - $time_start;
echo "query test: $time_end";

If you want you can test this script with your VA. I assume this is the part wich takes a really long time for you.

The next thing I did was adding an index to report_id in the table va_finances. The runtime of the above script changed to 0.027 seconds. This is 600 times faster than before.
I added the index with the following statement. If you don't use MySQL you may have to do it differently:
Code: [Select]
ALTER TABLE va_finances ADD INDEX (report_id);

Maybe this will help too in your case.

Support for VAM 2.4 - 2.6 / Re: Manual Pirep validation very slow
« on: May 10, 2017, 08:50:57 AM »
Well 5 minutes is certainly a long time, but I assume this also depends on the performance of the webhosting. Do you mind sharing some information of your database? I am curious about the amount of rows of the following tables: va_fincances, vampireps, pireps and pirepfsfk.

I do not recommend validating multiple flights at once. This can lead to inconsistency regarding the financial part and you may end up with validated flights and duplicated financial calculation. You will see the same parameter calculated multiple times inside one flight. We ran into exactly this problem.

Simply not possible. If you want that you have to implement it yourself or make a suggestion so it may or may not be in a future release.

Support for VAM 2.4 - 2.6 / Re: Manual Pirep validation very slow
« on: May 08, 2017, 09:31:01 AM »

I noticed the same problem. As far as I see the slow response time is because of the flight validator (validate_flights.php) or more precisely because of the financial calculations (calculate_flight_finances.php). The financial calculations are run every time the flight validator is called. Inside calculate_flight_finances.php are three SQL queries (including a subquery) which may take a really long time to execute, depending on the data. The more pilot reports and financial data you have, the longer it takes to run the queries.
As an example, the following query takes up to 17 seconds in our database:
Code: [Select]
select gvauser_id, flightid, flight_duration,pax, cargo, block_fuel, distance, route_id,DATE_FORMAT(flight_date,'%Y%m%d') as flight_date from vampireps where validated=1 and flightid not in (select distinct(report_id) from va_finances where report_id is not NULL)

I didn't look into a solution so far.
It would be more efficient to calculate the finances for a flight directly after validation. This may be easy to change.
Without changing too much there may be a way to modify the SQL query or maybe it helps to create an index for the specific fields in the database. I am not a database administrator and don't know too much about this.

Btw. it doesn't matter if you have the financial module activated or not, the calculations are done either way.

Bug reports / [VAM2.6.2] Acars Data MAX_JOIN_SIZE
« on: May 07, 2017, 03:14:32 PM »

After a while it may happen that the flight details page only shows an error message instead of the acars data:
Code: [Select]
The SELECT would examine more than MAX_JOIN_SIZE rows; check your WHERE and use SET SQL_BIG_SELECTS=1 or SET SQL_MAX_JOIN_SIZE=# if the SELECT is okay
In my oppinion there is an unnecessary join in the SQL statement.
I changed the last SQL query in flight_details.php and validate_vam_acars.php as followed:
Code: [Select]
$sql = "select vt.time_flag, vt.flight_status,vt.ias,,vt.altitude,vt.fuel_used,vt.oat from vam_track vt where vt.flight_id='" . $vamflightid . "' order by asc";

Pages: 1 2 [3] 4 5 6