Falcon BMS 4.35 U1 Wishlist
-
Given the capacity the devs have I would put none of those onto a wish list for a U1. Getting bug fixes for real issues such as Display extraction working reliable again, AC Spawn on top of each other in MP, or anything that relates to stability should be addresses in a U1.
BMS 4.34 or 4.35 is already a benchmark for sims, +1 for just bugfixes. Right now we don’t fly multiplayer on 4.35 due to display extraction, stability and tanker issues. But i’m really looking forward for it, especially since the new AI looks very promising. SAM’s are a lot harder now. There are many cool things in 4.35 and I’m so looking forward to fly it which we won’t until 4.35 U1 since many of us have a cockpit and rely on display extraction- and long missions are rather common.
Please just enable us to enjoy 4.35 with the current feature set for now. It’s awesome.
Add stuff in U2 or 4.36. -
4.35 is out just a few days and you are already asking for updates?
-
I didn’t know you could accelerate in MP. I probably never tried.
It is highly requested during Btests
-
Fonts, please fix the fonts 4.34 was much better. The simulator looks too dark and it’s not Alt+V either. Sounds are great and new but still not an F-16, if you can work on that too it would be great. Also, can we add “drop store” need to be selected twice before AI do it.
-
The fonts are what is realistic with regard to the size of them. As for the Visor already down in the pit……add this to your config and that will fix that…
set g_bVisorUpByDefault 1
-
The fonts are what is realistic with regard to the size of them. As for the Visor already down in the pit……add this to your config and that will fix that…
Think about Smart Scaling
Fighter sizes are already realistic without Smart Scaling but as we see a monitor and not a real view, the Smart Scaling option provides realistic orientation detection.Same for MFD fonts.
Even if it is realistic in terms of font size on the MFD screen, it might not be realistic in terms of readability.
Even in the 4K monitor, Bullseye and cursor altitude range are hard to read. -
-
Bind time acceleration step up to your keyboard, there is no limit such as 4x there.
We ppl free … but you should not accelerate in game more than x2 or maximum x4 … or expect issue depending also on your system.
Same in 2D … avoid more than x16. -
My very humble… no, not even a request, just a suggestion… Please try to minimize, whenever possible, the number of situations when a user signals an odd behaviour of the sim, whether regarding graphics or system modelling, and the reply is, “Yeah, it’s a known issue…”. In a word, higher priority of bug elimination over feature expansion.
I am sorry guys … but you are living on another planet. I would like to explain you but it is hard.
Let me try with one simple example: For some bug, minor, or more or less minor, we have no idea how to fix, or no body to do it yet … or … no need to spend time on it because this part is being entirely re-wrote … etc …So if we do as you suggest … the 4.35 would have been release in about 3 - 4 weeks. Is it really preferable?
Initial release has always been a kind of massive Btest … and you do not imagine how many of bugs that has been fixed prior the release. We can’t test all the possible configuration, it would require ten times more Btests and ten times more delays.
-
Are you serious?
Yes, stuttering is far worse now with dx11 version. Is dx11 faster then dx9 when they do same things, or slower?
Maybe its not even the fps that is lower (perhaps even higher in dx11 now), just the optimization so it will feel smoother.
We had lots of these (micro)stuttering issues in the past with Falcon, but they had disappeared.Cheers Obi1
-
Software will always contain bugs. Id prefer open communication of bug status over hiding it to avoid saying its a known issue
???
When we say this is a known issue: it means we have acknowledge it already somwhere else : internal Btesting or Discord or any other communication means
That does not mean at all we want to hide anything
Status “known issue” means " we are working on it "
-
Id prefer open communication of bug status over hiding it to avoid saying its a known issue
No! No you Blu3wolf
DO IT! TEST THE GAME? DO THE LIST? PUBLISH IT!
Come on !!! I AM DREAMING!
Reading you guys is depressive! What do you think?!? … We are at your service?
DO YOUR PART!
(me more and more sad and disappointed by the behavior this community :()
-
Bind time acceleration step up to your keyboard, there is no limit such as 4x there.
I can’t believe I forgot about that!
-
I have one issue that persists for me, which is that the sim tends to crash on mission exit. Sometimes it happens when I have done nothing to “upset” it like restarting a mission without restarting the program. There is nothing in the logs after the crash either.
-
Guys, please stay civil everyone.
I generally agree that having a public bug tracker would go a long way as far as visibility of outstanding issues is concerned. Just a forum is awful for that purpose. But as I don’t really have any insights on BMS development myself, can someone please clarify something for me:
1. Is there an internal bug tracker used by the dev team?
1a. If yes, could that be made public, even if just read-only?
2. If someone from the user community, as suggested by Dee-Jay, created a bug tracker, say on Github or a similar service, would the dev team start using it?Thanks for all your hard work in any case!
-
Yes, stuttering is far worse now with dx11 version. Is dx11 faster then dx9 when they do same things, or slower?
Maybe its not even the fps that is lower (perhaps even higher in dx11 now), just the optimization so it will feel smoother.
We had lots of these (micro)stuttering issues in the past with Falcon, but they had disappeared.Cheers Obi1
For me it’s the opposite, DX11 is a big step up. Graphics are finally as crisp and sharp as I thought they should be, which I never could quite get with the previous Directx version in Falcon regardless of graphical settings. I have a fairly high end graphics card (RTX 2070S) and I guess the more modern DX11 is more compatible with it. It also appears to run smoother on top of it.
-
1. Is there an internal bug tracker used by the dev team?
Yes.
1a. If yes, could that be made public, even if just read-only?
No. And rather pointless … because it applies to the Dev version.
If someone from the user community, as suggested by Dee-Jay, created a bug tracker, say on Github or a similar service, would the dev team start using it?
Opening a thread, then following it and using the known issues would be already a good things for users.
-
Think about Smart Scaling
Fighter sizes are already realistic without Smart Scaling but as we see a monitor and not a real view, the Smart Scaling option provides realistic orientation detection.Same for MFD fonts.
Even if it is realistic in terms of font size on the MFD screen, it might not be realistic in terms of readability.
Even in the 4K monitor, Bullseye and cursor altitude range are hard to read.I’m all for realism, but I have to agree that some parts are better if they’re kept slightly less realistic to accommodate for shortcomings in the virtual world. Smart scaling for objects, afterburner and speedbrake audio and MFD fonts appear to be some of those examples for at least a part of the community.
With their new size and / or form, a lot of us find it harder to read the fonts unless you really zoom in on them, because of readability on a monitor or deteriorating eyesight among our virtual pilots. During our two A2A test flights this week, a lot of transmissions contained something like “bullseye … 180? No, 100, ehr, wait…” <pilot zooming=“” in=“”>“150? Yes, 150!”
(3440x1440 here, but VFS members with 4K AND MFD extractions had the same problem. Don’t know what it’s like on 1080p)The result is that what should be a 2 second bit in a transmission, something that worked perfectly before, easily becomes 5 - 10 seconds simply because of the new fonts.</pilot>
-
Haha yes there has been a lot of “stuck mics” while people are trying to read BE on our end too!
-
No. And rather pointless … because it applies to the Dev version.
Yes, of course. You can’t fix bugs retroactively. That’s true for every software project ever.
Opening a thread, then following it and using the known issues would be already a good things for users.
That would be too unstructured and unorganized for my taste, but maybe someone else will have a go at it.
Thanks for the clarifications, Dee-Jay. I see more clearly now.