FSDreamTeam forum
June 26, 2019, 12:31:20 PM *
Welcome, Guest. Please login or register.

Login with username, password and session length
News:
 
   Home   Help Login Register  
Pages: [1] 2 3 ... 10
 1 
 on: Today at 12:08:49 PM 
Started by tszchun_anson - Last post by tszchun_anson
Quote
Also all the cargo doors had been opened even though GSX's loading vehicles did not approach CARGO BULK DOOR. May I confirm if this situation was totally normal while nothing can be done in GSX?

GSX at this time only supports a maximum of two cargo doors on the right, and one on the left, so the configuration we made for the PMDG 777 set the 2 doors on the right for the passenger version, and adds the main cargo door on the left for the freighter version.

This might eventually be improved in future versions.

In your testings, have you ever experienced inability to remove wheel chock before the turn around countdown is over? It appears that if I select short, long or custom as turn type, PMDG does not want/allow me to interfere its auto door management and its own ground equipment (i.e. wheel chock and GPU).

 2 
 on: Today at 11:52:12 AM 
Started by tszchun_anson - Last post by tszchun_anson

The atc_parking_code in the *scenery* (AFCAD), are used ONLY as "tie-breakers" of ground operators having the same score.

i would like to make sure I get it right. Aren't the codes pre-filled in the "Airline codes" field in GSX customisation page read from bgl file of the scenery? Is that bgl file what you mean by "AFCAD"?


 3 
 on: Today at 11:46:37 AM 
Started by tszchun_anson - Last post by virtuali
Quote
Also all the cargo doors had been opened even though GSX's loading vehicles did not approach CARGO BULK DOOR. May I confirm if this situation was totally normal while nothing can be done in GSX?

GSX at this time only supports a maximum of two cargo doors on the right, and one on the left, so the configuration we made for the PMDG 777 set the 2 doors on the right for the passenger version, and adds the main cargo door on the left for the freighter version.

This might eventually be improved in future versions.

 4 
 on: Today at 11:40:33 AM 
Started by tszchun_anson - Last post by tszchun_anson
Thanks very much! I understand why GSX does not interfere aircraft doors.

I had the exact same thought as yours that, I simply had to set a longer turn around time. Today I just selected turn type <CUSTOM>, the progressive refuelling work perfectly as expected. After the completions of refuelling and the subsequent boarding, the turn around time countdown was still not over.

Then I tried to remove ground power unit but it failed, maybe PMDG did not allow that before the turn time was over. Also all the cargo doors had been opened even though GSX's loading vehicles did not approach CARGO BULK DOOR. May I confirm if this situation was totally normal while nothing can be done in GSX?

 5 
 on: Today at 10:54:03 AM 
Started by virtualflying - Last post by virtuali
Have you set the Mesh Complexity and Resolution as suggested in the KDFW manual ? Try either 10 or 5 meters per pixel and NOT higher. The simulator is known to show such artifacts when meshes are oversampled.

 6 
 on: Today at 10:52:39 AM 
Started by 930175620 - Last post by virtuali
It has been asked and replied to as early as yesterday:

http://www.fsdreamteam.com/forum/index.php/topic,20815.msg143554.html#msg143554

 7 
 on: Today at 10:51:32 AM 
Started by marknie - Last post by virtuali
This has been discussed so many times already and no, it's not a GSX bug, it's a problem of Metar reports coming from Simconnect containing bogus/outdated/corrupted data, especially when using 3rd party weather engines.

Because the deicer is something you are only ASKED to us and you can obviously reject, we intentionally chose to err on the side of caution and, when the Metar data was corrupted, we always allowed deicing, because it's clearly best having the option of a deicer you can reject, rather than NOT having a deicer when you MIGHT need it.

Unfortunately, even if this was a precise design choice ( what to do when the Metar is unreadable ), in order to not have users assuming this is a GSX but ( I understand it might look like that ), this is how we'll deal with this problem with the next update:

http://www.fsdreamteam.com/forum/index.php/topic,19670.msg137432.html#msg137432

 8 
 on: Today at 10:46:16 AM 
Started by tszchun_anson - Last post by virtuali
There's nothing contradictory between the manual and the post you linked. The atc_parking_code in the aircraft.cfg, as explained in the manual, only affect the choice of ULD loaders, and doesn't have any effect on the ground operator.

The ground operator, instead, is chosen using a scoring system that takes into account the couatl.icao_prefixes lines in the SIM.CFG of all GSX vehicles. Only the operator with the highest match will be show.

The atc_parking_code in the *scenery* (AFCAD), are used ONLY as "tie-breakers" of ground operators having the same score. This means, if the scenery has set for a certain parking atc_parking codes that don't match anything in the GSX vehicles for that airport, they won't do anything. To see an operator, it must have some score for that airport in the GSX vehicles files and, if there are many, only the one with the highest score will be chosen. The atc_parking_codes will enter into play only to break ties.

However, with the GSX customization page, you can use the "Airline codes" parameter and, in this case, the codes specified there will take precedence over everything else. But you must set them YOURSELF. If you don't do that, the ones from the scenery AFCAD will be shown, as an information, but they will only work as tie-breakers. It's only after you *edit* the field, they'll become real overrides, directly affecting the choice of operators, regardless of the default scoring system.

 9 
 on: Today at 10:36:35 AM 
Started by tszchun_anson - Last post by virtuali
Quote
This means, in case I set the turn around time too short, the doors will close even though GSX is still loading the aircraft

Let's try to see it from a real-life point of view: would you set up a short turnaround time, if you knew you had to load a certain amount of stuff ? I guess the solution here is to simply select a turnaround time which is long enough to allow to do all your ground operations.

Since GSX never, ever, tries to interfere with the airplane system, there's just nothing we could or should do to fix this. It must be done by the airplane developers, because only them can really know about any possible consequences of changing the airplane state.

For example, what would happen to the airplane internal state if we force-open the doors from GSX (which might seem a possible "fix from our side" ), when they should not be open, for example depending on the status of electrics, hydraulics, etc. ? We could easily mess up the whole simulation, and that's why GSX never, ever, tries to change anything on the airplane itself, and it's only *reading* data.

Many developers understood this and, they are doing really nice things, especially with the next update, where the level of integration has been increased quite a bit. But of course, we cannot force anyone to support GSX.

 10 
 on: Today at 10:16:07 AM 
Started by frag - Last post by virtuali
Well apparently releasing the fixes to turning off the vehicles which effect performance and the stairs which should have worked in day one for those of us who have bought your software is not a priority. Whatís the point of your updater if you canít update the software.

You don't seem to understand. It's not a matter of priority, we simply CANNOT release anything right now, until we'll release the GSX update and the new ecommerce update. And I think ( I THOUGHT ) to have explained this quite clearly but, apparently, not.

It's just that these two major things, the GSX update, and the Esellerate closure, are all happening at the same time.

Quote
Hooray your working on new features for your costumers but fail to support those who are using the current versions. Six months sitting on a fix, really? I thought FSLabs was bad about releasing updates.

Sorry if the update feels small to you. It's more like a remake, but it's FREE. It took more than expected, because we kept adding new things to it. Again, for FREE. This is not "a fix", it's an update that's even larger in content that the PAID L2 expansion. The installer grew from 1.0GB for the previous version, to two separate installers, one for FSX, and one for P3D4, with the total size almost tripled.

Quote
The community knows this is the norm for FSDT.

That's exactly the opposite. The community knows we supports our products with updates so constantly, and for so long ( GSX came in 2012 ), which is why this uncommonly long pause between update stick out precisely because of that.

Quote
At least you pushed out a solution so we could now fly from Europe to the US without CTD over Canada. Notice how I didnít say fix even though it only effected GSX users.

I don't know what you are trying to say here but, apparently, you again seems to fail to understand what the problem was. As explained so many times, the SIM WAS CRASHING BY ITSELF. GSX did nothing wrong, it was only calling a simulator own internal API that, apparently, is bugged when flying over sparse areas.

This is of course clearly proven by how the so-called "fix" works. We haven't changed anything in the GSX code, other than stopping to call that SIMULATOR OWN API when cruising.

So, in fact, the problem is NOT "fixed in GSX" because, of course, GSX wasn't the cause. The problem is still there, and it can still happen, either with GSX if flying low, or with another other add-on that would do the same call but, I guess after seeing how users like you can be so easily MISLEAD assuming it's a GSX but "because  it only affected GSX users.", but they are confusing the cause with the effect, a typical mistake.

The *cause* is the bug in the simulator that seems to have troubles when somebody ask for facilities in sparsely populated areas.

The *effect* was GSX that was unfairly accused of being causing this problem, when it was only calling a feature of the sim.

Pages: [1] 2 3 ... 10
Powered by MySQL Powered by PHP Powered by SMF 1.1.21 | SMF © 2015, Simple Machines Valid XHTML 1.0! Valid CSS!