Recently we have seen a lot of codes used to unlock our products being offered for discounted prices. Almost all of them are bought using stolen credit cards. These codes will all be blocked by our systems and you will have to try to get your money back from the seller, we are unable to assist in these matters. Do be very careful when you see a deal that is almost too good to be true, it probably is too good to be true.

Jump to content

Joan Alonso

members
  • Content Count

    148
  • Joined

  • Last visited

Everything posted by Joan Alonso

  1. Hi @ahuimanu The code works ok with a gamepad which is the device I use. I can't comment on using other hardware. I did many many tests time ago with different code and nothing worked but this. Yes, this two variables are built-in simulation variable. (A:SIM ON GROUND, bool) 1 == (When the aircraft is on ground) Can be 0 or 1(A:BRAKE INDICATOR,position) 0.6 > (When the brake pedal position is greater than 60%.) Can be from 0 to 1 I don't know, you can try to adding this lines DETECT EXTERNAL BRAKING part of the code. It makes sense to start changing things there first, but as far as I remember nothing seemed to work there. I'm sorry I can't be of more help!
  2. Hi, As requested by private message I'll share the mod I did to ABRK.xml in case helps anyone interested. This solved the Autobrake disarm before touchdown for me. Replace the 7th line of the file: (L:ABrkactiv, number) 0 == by this two lines: (A:SIM ON GROUND, bool) 1 == (A:BRAKE INDICATOR,position) 0.6 > Cheers P.S. I'm not sure if I'm allowed to share the line of the original code. @DaveCT2003 Thanks.
  3. I realised some time ago that sometimes the .fms file does not save at all (a few times) or does not override the previously .fms file if saved with the same name (more often). So to be sure, I always delete the previously saved files and save the flight then. I always check if the .fms and .asc files have been saved correctly. The worst scenario is when the .fms file won't save at all, no matter what you try, you'll have to restart P3D losing the FMS data or finish the flight. Hope it helps!
  4. IAE Flex Temp with data from http://www.wabpro.cz/A320/ stopped working several updates ago. The last topic I opened was a month ago without further news on the topic.
  5. For what it is worth, the FD commands the momentary roll on approach also with AP off.
  6. Ok. I tried assigning buttons again and it works someway better with FSUIPC Throttle Incr and Decr than with P3D controls. But the overall feeling is worst than the other way around, the reverse range seems to be longer but the response on the manual range between IDLE and CLIMB is better with P3D controls. I was just curious if something could be done in the FADEC or ATHR code to make the reverse range longer or not to be so sensitive when button is applied as it does in manual range. Anyway, I will leave it as I had it before, barely pushing the button to get IDLE reverse. Thanks!
  7. Ok! Thank you. I'll try then to assign buttons again and see if I got it right. I'm glad to hear that there are up to seven steps to full reverse. So, it has to be something I'm doing wrong.
  8. Decrease. I tried with FSUIPC Throttle Dec Small with the same result. It feels that from Idle to full reverse it goes really easy to full with barely touching the button, I can sometimes put it on idle reverse as you say, but it does not feel like in manual range, where I can smoothly increase or decrease by small increments.
  9. Hi, I try to apply a single quick press, but most of the time it goes further than that. It’s way more sensitive than the manual range. Thanks
  10. Hi, Is there any way to make the reverse range less sensitive when applied trough a button or key? I mean, the steps in the manual range are fine, but when entering the reverse range the steps are much higher, it's difficult to apply idle reverse wihtout going to full reverse first. I know it's something related to the way of the thrust is coded, but can be something done? Thanks in advance
  11. Hi, I noticed today that when saving a flight the fuel in the center tanks is not saved. So, if I saved a flight where I have 15.2 of fuel on board, reloading it will give me only left and right tanks full but the center one empty. Can you recreate this? A320 CFM 1.2.2.1 Thanks.
  12. Hi, LEBL/LEMD 29º TAT 1015 QNH Wind: 180/12 TOW: 64100 CI: 20 Departure runway 25L / SENI3F to SENIA Default FMC data (FLAPS 1): FLEX: 64º (ECAM showing 64º 1,284) 124 133 134 Data form wabpro (FLAPS 1): FLEX: 70º (ECAM showing 70º 1,255) 144 144 145 It seems underpowered with the non default data, barely takes off at the end of the runway and after liftoff the aircraft can not climb at all. Although it's not a great difference between two given FLEX temps.
  13. Hi, I open a new topic regarding this because this topic got lost within other managed speed topics time ago, I can not remember which one. So, some updates ago, the FLEX temp on IAE was working fine as the CFM does with data from http://wabpro.cz Now, numbers higher than the default MCDU flex temp leads the aircraft not to apply the correct thrust but a much lower thrust. (only IAE) If I recall correctly, the problem exists since the IAE climb profile/drag was changed. Are there any news on this? Thank you
  14. I think that he refers to the “button sound” and the well known ding sound of avionics starting. Both files are not used at all. Instead, a Thrust detend sound is played. I noticed this some months ago, just after release:
  15. EDIT: AffinityMask=0 does not work. Process lasso neither. The point is setting the affinity after P3D is started. So the only way of spreading CPU core usage is to set affinity manually every time. Maybe a bat file would do the trick.
  16. Ok! I found something interesting, indeed, a stutter free solution. We know that P3D uses one core for rendering tasks, so when loading any aircraft you can see the core 0 with higher load than others. Even not being near 100% load this was causing stuttering with the Aerosoft Airbus. I really do not know why it only happened with this aircraft. I tried AM settings and nothing worked, because every setting was loading the rendering tasks to a single core, so stutters again. I have hyperthreading enabled with all cores enabled with P3D by default. So here's the trick, the only thing that will spread the core usage through all cores is (no AM in P3D.cfg) to open task manager, opening affinity dialog for P3D without touching anything and closing it. That will spread the CPU usage of P3D. 🤔 It seems that the developer can do some adjustments with core usage. But I don't know if LM or AS can do something to "solve" or modify this. Or maybe it's only beneficial for my system? Anyway, the bus is smooth as butter right now. Some people say that setting Affinity Mask=0 in P3D.cfg does the same without need of doing this every time P3D is started. Can not say if it works, I'll try tomorrow, it's been a looong day (another one) tweaking P3D. Here is an explanation of this at P3D forums. https://www.prepar3d.com/forum/viewtopic.php?f=6314&t=129222
  17. Hi, I struggled months ago with an old PC, so I upgraded to a new one. It's a custom config I made specially for gaming and mainly P3D only. The difference was amazing, I never had a PC powerful enough or according with P3D recommended requirements before, I'm really happy with it, I think I got a good deal. I thought I would never face again with stuttering, low FPS or any kind of -ings related to P3D behaviour. I'm looking for advice if someone is experiencing the same and/or what can be upgraded to get a microstuttering free experience with the bus. My rig is: I7 8700 GTX 1070 8GB 16GB CRUCIAL BALLISTIX SPORT 2666 (1) SSD EVO 500GB MSI Z370I P3D4.4 Windows 10 Home Pretty good system I thought, well, not so strong to run the bus smoothly. Surprisingly, the AS Airbus runs great and with higher FPS than any other commercial aircraft I have, but with terrible and constant microstuttering, only (and that's the key) on ground. I have really conservative preferences in P3D (close to nonsense with my rig), most of the sliders are to the left. To the left I mean most of them at 0. I really want the sim to be smooth, not visually outstanding. The point is that I get steady FPS and no stuttering with any other aircraft. In fact, sorry, I get lower fps but steadier and smoother with the other bus. The CPU never gets above 40% load with constant 4.3 GHz, no other main tasks are running while running P3D. The GPU never exceeds 40% load in common conditions, the max GPU load I had was 60%-70% at night with trueglass working and many spot lights close to the aircraft at a payware scenery. Which makes me think that none of them are struggling at all. The microstuttering is present in any scenario, also with clear skies, no weather injection, no FPLAN added, default scenery and default shaders. It happened also with P3D4.3. Could some calculations ruining the smoothness when on ground? I understand the need for a frame by frame calculation to simulate the systems of an Airbus, but can be some part of the code optimised/reworked to avoid this situation? If not, what's wrong with my system that I can not run the bus as smooth as the other aircraft? My relevant P3D settings (always and in all situations): - 1440x900 - Vsync On / Triple Buffering / Unlimited - FXAA On - 8MSAA - Anisotropic 16 - No Traffic (any) - No Bathymetry - Internal and External Vehicle Shadows only - Cloud Distance 80 - Dynamic Reflections Off What I tried so far: (not necessarily in that order, i tried many things many times). - Reinstall AS Airbus - Nvidia Drivers up to date - Revert Nvidia Drivers - Nvidia CP Default settings / tweaked for performance. - Shaders delete - P3D.cfg rebuild - Added Exceptions to Windows Defender - Deactivate Firewall - Deactivate Windows Defender - Deactivate Windows Search - HyperThreading Enabled and Disabled - Checked RAM XMP On - Afiinity Mask On/Off - USB and wireless peripherals removal - Reinstall W10 Any help will be much appreciated. Thanks!
  18. Hi @Meyerflyer, would you mind replacing the GSX_Doors by this one? I suspect is something related to it. Make a backup of the original first. Documents\Aerosoft\Aerosoft A320-A321 Professional\SimObjects\Airplanes\Aerosoft A320-A321 Professional Base\Panel_Fallback\AB_Systems GSX_Doors.xml The Ext.Power trigger was connected to the cargo door state, hence if you interact with GSX before the Pushback/Departure state could cause problems with users that do not want to use the Auto GSX gauge. So I updated the gauge to only trigger when GSX states are called and let the user full authority over doors. Maybe AS wants to add it to the next build if the revision of the gauge is not ready yet. It is explained here: https://forum.aerosoft.com/index.php?/topic/140799-gsx-automatic-door-handling/&tab=comments#comment-912001
  19. Hi @Choobe, many thanks! I attach the file. This time I made a fast flight from LEBL with the same result. FMGS.log Yes, exactly. The FMGS contents do not reset like they do at other airports. The FLPAN remains LEBLLEMD (in this case) with all the PERF pages available, and with green data TAKE OFF PERF from the departure runway. The waypoints present are only the arrival runway and the go around ones. If you can not reproduce it I'll start thinking it's something on my side, but I tried with default airport, rebuild scenery index, double checked navaids and waypoints, tried Navigraph and default Navdata... I really don't know where else to look to find the culprit. Thanks
  20. Try Shift+L to light up the MCDU bmp. This will also light up the external model cabin.
  21. Short answer, yes, it's possible. It's what I tried first when writing the code but it gave me problems with GSX triggering. The point is that AFAIK the bus does not have an Lvar to open and another one to close, it just calls a Toggle action. So you have to tell GSX at what percent position is that door for GSX understand if it's opened or closed, and that led GSX to be confused and the code not to be reliable. So unless AS comes with a better approach I'll leave it as it is now.
  22. I suspect that maybe it has something to do with the airport altitude. Being Madrid one of the highest airports in europe (2000ft) can the MCDU does not understand that the destination airport is higher than the Thr red/ Acc alt? Just saying. I made a test from LEBL to LEMD with Thr Red/ Acc Alt at 2100/2100 with no luck. After touchdown the MCDU keeps resetting to Take Off departure page.
  23. Thanks. Just to add if it helps, I tried both default NavData and Navigraph. And the APPROACH page switching to TO PERF page goes this way: -APPROACH Perf -Touchdown -seconds after or 80 knots? (Not sure what triggers exactly) -Both MCDU go black for a second -TAKE OFF Perf (Departure RWY) -“CLK IS TAKE OFF TIME” Scratchpad Message
×
×
  • Create New...