Have something to say?

Tell us how we could make the product more useful to you.

In Progress

Test Junction creation for possible elevated permissions

User Story As a user who encounters permission errors when toggling addons, I want the app to offer to restart with administrator privileges, So that I can complete the operation without manually restarting. Beta testers report receiving "failed to toggle addon" errors when toggling addons. The root cause is that creating/removing NTFS junctions requires administrator privileges on some Windows configurations. Current Behavior User toggles addon Backend attempts junction create/remove Windows returns "Access is denied" Backend returns: "Access denied. Please run the application as administrator to create junctions." Frontend displays generic error message User must manually close app and restart as administrator Desired Behavior When a permission error occurs, the app should: Detect the specific "Access denied" error Prompt the user with a clear explanation Offer to restart the application with elevated permissions (Ideally) Resume the operation after restart

Jim Thompson 22 days ago

Completed

Full Checklist Implementation

PERFLIGHT's Checklist page transforms the chaotic pre-flight preparation ritual into a streamlined, structured experience for Microsoft Flight Simulator pilots. By combining intelligent automation with user-configurable steps, it ensures pilots never forget critical preparation tasks β€” from activating the right aircraft and scenery addons to launching supporting applications and syncing flight plans. This feature addresses a gap in the flight sim ecosystem where no tool bridges flight planning with addon management in a guided workflow. Pilots currently rely on memory, sticky notes, or personal rituals that inevitably fail β€” resulting in ruined immersion, wasted time, or forced simulator restarts. The Checklist page makes PERFLIGHT the essential "start here" tool for every flight session.

Jim Thompson 23 days ago

Technical: File System Event Abstraction

Refactor the file watcher to use a semantic event layer (FileSystemEvent enum) instead of directly matching on the notify crate's low-level events. This enables unit testing of event handling logic without filesystem mocks, simplifies the 140-line pattern-matching block into clean semantic matches, decouples from the notify crate for easier upgrades or replacement, and creates a foundation for smarter features like addon-aware change detection, intelligent debouncing, and batch operation coalescing. Arguments for Keeping the Abstraction 1. Decoupling from notify crate Currently the code is tightly coupled to notify::EventKind matching (lines 192-341) If notify changes its API or you switch to a different file watcher crate, you'd have to rewrite all the event handling logic With FileSystemEvent, you'd only change the translation layer once 2. Simpler event handling The current match statement is ~140 lines of gnarly pattern matching on notify::EventKind variants With the abstraction, event handlers would be cleaner: match event { FileSystemEvent::DirectoryCreated(path) => { /* handle */ } FileSystemEvent::FileRemoved(path) => { /* handle */ } // ... } 3. Testability You can't easily unit test code that depends on notify::Event without mocking the filesystem With FileSystemEvent, you can create test events trivially and test your handling logic in isolation 4. Semantic clarity notify has Create(CreateKind::Any), Remove(RemoveKind::Folder), etc. - you're already translating these to semantic strings like "directory_created" The enum would formalize this translation and make the code's intent clearer 5. Future extensibility You might want custom events like AddonFolderChanged(Uuid, String) that carry more context than raw paths An abstraction layer gives you a place to add that semantic enrichment

Jim Thompson 2 months ago

Group Addons by "Source" and link to EXE

On the INIT page you can designate which β€œService” apps you use, such as Orbx Installer, PMDG Operations, Aerosoft One, etc. But we don’t have a way of determining the actual source of each of your Addons. We do provide a dropdown of options to select, which include websites like Flightsim.to or SimPlaza.org. This feature would allow users to view their addons by β€œSource” and relate the Source to the Service application. The actual usage patterns around this change are unclear. But would love to hear ideas. A place to visualize which addons you get from which β€œsource”. For example, many airports and aircraft are actually sold from many marketplaces - Orbx, Contrail, iniBuilds, etc - and it becomes REALLY difficult to remember where you have to go to update the addon when changes are published.

Jim Thompson 2 months ago

Planned

Modern Installer & Seamless Update System (Epic 6)

PERFLIGHT is currently in active development with multiple completed epics for addon management, state management, backend architecture, pilot services, and global notification system. The application is approaching early access readiness, but the current manual build and distribution process creates barriers: Installation friction: Traditional NSIS wizard feels outdated compared to competing tools Update overhead: Manual downloads and reinstalls create support burden and version fragmentation Trust barriers: Unsigned installers trigger SmartScreen warnings, reducing user confidence Testing velocity: No automated way to push updates to early access testers for rapid validation This enhancement integrates with the existing global notification system (Epic 5) to provide in-app update notifications and progress tracking, completing the user experience loop for software distribution.

jimthompson 2 months ago