Jump to content

ConstVoid

Members
  • Posts

    289
  • Joined

  • Last visited

  • Donations

    15.00 USD 

Reputation

153 Excellent

Contact Methods

  • Website URL
    http://
  • ICQ
    0

Profile Information

  • Gender
    Male
  • Location
    UK

Flight Sim Profile

  • Commercial Member
    No
  • Online Flight Organization Membership
    none
  • Virtual Airlines
    No

Recent Profile Visitors

3,277 profile views
  1. I can't answer for BATC, but FSHud works exactly the same in MSFS 2024 as it does in 2020. The only caveat is that MSFS in-built live traffic will not work unless you install models from AIG or FSLTL, as the default AI aircraft do not exist locally - they have to be downloaded from the cloud, which MSFS is able to do itself, but doesn't provide a mechanism in the SDK for third-party tools like FSHud to do.
  2. To be honest I thought it had been released too, but I decided to check before posting, and found something written in 2005 by the programmer involved which indicated that the bug was discovered after the first compile and was fixed before release.
  3. An extension of that is that very, very few programs have been written which are totally bug free. In the 1960s The IBM 360 OS had a utility called IEFBR14. Its function was to 'do nothing' so that it could be used as a dummy program in job steams to test them (this was well before the widespread use of interactive computing via screen and keyboard). Its programmer initially coded it as a single machine instruction "BR 14" which caused the program to return to the caller (usually the operating system itself) as it's a "Branch on register 14" instruction. When programs were started in OS/360 register 14 was preset to the address to return to. Unfortunately, to be useful in job stream testing the program should have set a return code, which by convention should be 0 for a successful execution. So this single instruction program had a bug in it, which was fixed by adding an additional instruction to clear register 15 before the "BR 14". Register 15 was used by the OS to pass back the return code. The buggy program never made it to release, but it shows how even simple programs can be buggy. Now extenthe that to the many thousands/millions of instructions in something like MSFS...
  4. I doubt that. The indications are that at least one of the major items on the 2025 roadmap is/are being worked on, but I agree that the silence on progress by the developer is deafening. As we're nearly a third of the way through the year I hope that we get some news or even an update soon.
  5. FSHud_Admin posted on discord yesterday. I think he has a day job, possibly in the aviation industry, which may mean he's unavailable for FSHud support questions at times. There also used to be FSHud_Support account on discord, but I don't think he/she has posted for about a month now. Inconvenient as it is, I don't think we can expect developers to be available for support 24 x 7, especially for small setups like FSHud.
  6. I agree, but it seems the OP has forgotten his password, so he must contact FSHud_Admin via one of the methods in my previous post to get it reset.
  7. OK. Final suggestion, as I'm not a Frame Generation user and don't know if it's feasible, but could you temporarily run MSFS in windowed mode and run a browser session for FSHud on your MSFS PC instead of using the in-simulator window. This would eliminate both the Apple device and the network. I wouldn't suggest running like that permanently, but it might provide additional clues to FSHud support if that works successfully even if the iPad doesn't.
  8. As you're probably aware, there have been no apparent updates to FSHud for some time, so I suspect that their 'problem with (your) network' comment is based on that. As your were able to use it until recently I really would suspect something at your end, maybe an iPadOS update or similar. Have you any other device you could try a browser session on to see if you still get an error?
  9. FSHud doesn't (yet?) do holds - it's been mentioned on the discord and the developer suggested they might be implemented sometime in the future. Not clearing direct to the first waypoint on a departure with no SID is something I've seen too. In my case the runway heading was close (but not too close) to the heading to the initial waypoint, which might cause the bug to occur. Maybe this will be picked up when the developer introduces better enforcement of adherence to the plan, which is currently lacking.
  10. That would explain it - no update here, and I don't have GSX.
  11. RC needed those options because it knew nothing about SIDs, STARs and Approaches. By selecting the options it was effectively saying that the pilot could do whatever he/she wanted without being admonished for not adhering to ATC instructions. We expect ATC programs to be more aware of procedures these days so that the pilot doesn't need to give them clues like this. Well yes, quite important. Does this mean VoxATC handles this better? 😄
×
×
  • Create New...