Internet security programs are, for the most part, an excellent way to damage your computer’s security.
Security in IT comes from secure operating practices, not installing some software then operating insecurely.
Internet security programs are, for the most part, an excellent way to damage your computer’s security.
Security in IT comes from secure operating practices, not installing some software then operating insecurely.
Search the forum for Saitek X52 radar cursor ministick and it should be pretty easy to find, theres at least 2 or 3 threads explaining how.
would be nice to get a version with a map and nav data waypoints, for radar approach control (human ATC potential)
Introducing BMSBugs, a centralised community bugtracker for BMS.
Easier to query than the forum for looking up specific issues. Easily accessible by browsers across whatever platform you are currently using.
No! No you Blu3wolf
DO IT! TEST THE GAME? DO THE LIST? PUBLISH IT!
Well, this is a community bugtracker, not a Blu3wolf bugtracker. If you know of a defect in BMS, but cant see it in the bugtracker, please feel free to add it. You can view bugs without an account, but account signup is is required to report bugs (requires email verification). Signing up allows you to report bugs, monitor the progress of your bug, as well as update it with further details, add attachments, and identify yourself.
Writing a bug report is pretty easy, follow the link and follow the prompts. If you want guidance on writing a good report, Nick has written an excellent post here. Keep reading below for more specific instructions relevant to writing a useful bug report.
You can file a report here. Thanks for doing your part to improve BMS!
Bug Report Checklist
1. Has this bug been reported already? Search to see if the bug is already known.
2. If the bug hasnt been reported, create a new report.
3. Describe clearly and concisely the actual behavior, and the expected behavior of the software.
4. Describe clearly, the steps to reproduce the behavior, or if you cannot reproduce the bug, the steps you took when the bug occurred.
5. Supply additional information to help clarify the bug, like pictures, logs, crash dumps, etc.
6. Stop and read your report before submitting. Can it be made clearer? Can you follow the instructions to reproduce the bug?
Bug priority versus bug severity
Bug severity should be set based on how significantly it affects your ability to use the sim. Options include feature, trivial, minor, major, crash, or block. Feature requests are the least severe ‘bug’. Trivial bugs do not affect your ability to use the sim - such as very minor graphics glitches rarely seen, or issues affecting the display of a menu which do not prevent you using that menu, etc. Minor and major bugs both affect your ability to use the software as a combat flight sim - for example, a bug preventing you from contacting AWACS would be a minor bug, while a bug preventing you from firing missiles would be a major bug. Major bugs have no workaround, while minor bugs can be worked around. Crash is for critical bugs - for example, bugs which crash or lock up the software.
Bug priority should be left as “normal” - the default value. Bug priority is decided on by the team, internally, and setting “high” or “low” priority on issues will not have any effect whatsoever on the team’s decision making process. Therefore, new issues should be set as “normal” priority.
Bugs in other theatres
Bugs in other theatres may be a bug in BMS’ code, or a bug in the data defining that other theatre. If you experience a bug in another theatre, before reporting it as occurring in that other theatre, try reproducing the bug in KTO. If the bug occurs also in KTO, it is more likely a bug within BMS.
If the bug only occurs in that other theatre, it can still be reported. In fact, there are separate projects here specifically for reporting bugs in other theatres, including ITO and EMF. You can use the drop down menu in the top right of the page to select whether you are reporting a BMS bug (in KTO), or another theatre bug.
You can visit the BMS project home page here, and the ITO project home page here.
Resolved issues versus closed issues
Issues which are marked as “resolved” will still be present in the current release. Issues marked as “closed” should not be present in the current version.
When an issue is fixed, the issue will be marked “resolved” and may have a target version set. When the issue is fixed in a public release, it will be marked “closed”. If you are searching to see if your issue has been reported already, this should include checking resolved issues. Resolved issues are fixed, but the fix is not yet included in a public release. Searching for closed issues may help see if similar issues have been reported and fixed in the past - sometimes fixes are not as perfect as we would like.
If in doubt, open a new issue - we can link the new issue, to the old one, if need be - and it may be that a bug that seems similar is actually a totally new bug, and not related to old bugs.
You can see issues fixed in the next version here. If you report an issue and it is fixed in a new version, we would appreciate you closing the issue when you confirm the issue is fixed. Thanks for doing your part to improve BMS!
err… 2TB you mean? I don’t know if anyone even made a 2GB NVMe drive!
Well, coming from a photography point of view it makes sense the way it works now - the same lens on a bigger size image sensor (i.e. changing the display area) naturally changes the perceived zoom level.
FoV is a setting independent of aspect ratio. You can set it to whatever you want. If you change FoV without changing the display area, then the zoom naturally MUST change.
You are mistaken about the setting, too. If you increase the displayed FoV in BMS, then it will increase the angle you see in the sim. If you do not also adjust the size of the display to have it take up the same FoV as it displays, then it will appear warped as you look around.
FoV in BMS is a FoV setting, not a zoom setting. The two are very different.