Ff you could have one thing in the next update it would be…
-
New start ;-). I would like to have a simulated visor - visor down -> all is darker and color tinted - sun is so bright during those refuelings
-
Always wondered why no sims have this implemented; DCS, BMS, RoS - none of the players…would be a nice feature for those excruciatingly sunny days.
Great idea.
DrDetroit
-
Always wondered why no sims have this implemented; DCS, BMS, RoS - none of the players…would be a nice feature for those excruciatingly sunny days.
Great idea.
DrDetroit
DCS mig-21 has this feature.
I’d have to say being able to enter and exit the flame without ejecting
-
Controls setup available while in cockpit and an axis assigned to the AV-8B nozzles.:D
-
This thread is a loaded question.
I hope that everyone here will be respectful and careful with what they post so as the devs do not lock the thread.
With that being said,
I do look forward to one day having multi core support and have FBMS take advantage of more RAM. Since there is now a 64bit version, FBMS may already be taking advantage of more RAM. Multi core support would be a huge leap in performance. Once achieved, FBMS could add the high end GFX (not saying that the GFX are bad now, in fact they are way better than what I expected!) and greater detail without stuffing up just 1 CPU. To me, that is the next logical step.
-
+1, jhook…that seems like a perfectly reasonable advance in the tech - something we’d all benefit from!
…and BIG thanks to the Team for fulfilling my dream of buddy lasing in 4.33…
-
There are a number of daydream things I can come up with, but frankly this release is just about perfect from my perspective. There is enough meat here to keep me amused pretty much forever. I’d go so far as to say that it’s up to the theater designers to make the most of this sim now, not the BMS devs.
-
Anti-Aliased and/mip-mapped MFD displays. There’s a particular FOV level where the displays are nice and crisp but they get pretty jaggy when you zoom out. Still generally legible but the scintillation of the jaggies is irritating. I don’t know if its because the displays aren’t anti-aliased (Even a slight blur shader would probably help) or they’re not mip-mapped (D3D can auto generate mips on texture updates) and zooming out is causing a high res texture to be mapped to relatively few pixels.
-
Well naval ops is in! So I’m good
But…hmmm…anything else? I really can’t think of anything else…
I wouldn’t mind a vanilla milk-shake.
-
Id like to say ‘TADIL J’, but that would not be one thing really. It would be at least 5 different things, all massive reworks of how the sim works under the hood. So I guess I cant really ask for that.
You know what would be great for 4.34 (and would keep Red Dog and Darkman very busy from now until then)? Reworking the BMS dash 1 and dash 34 to follow the real structure more closely… XD
Then again, thats probably a bit of a wasteful thing to ask for after such a stellar improvement over 4.32s manuals. Hmm.
Id have to second the call for a milkshake instead I think. Can mine be spearmint?
-
I do look forward to one day having multi core support and have FBMS take advantage of more RAM. Since there is now a 64bit version, FBMS may already be taking advantage of more RAM. Multi core support would be a huge leap in performance. Once achieved, FBMS could add the high end GFX (not saying that the GFX are bad now, in fact they are way better than what I expected!) and greater detail without stuffing up just 1 CPU. To me, that is the next logical step.
This comes up over and over. It’s puzzling to me that the myriad posts on the subject haven’t made it common knowledge for all by this point.
Falcon 4.0 was multithreaded and multi-core capable since before the very first commercial release. I beta tested it for Microprose on NT on 2- and 4-way CPU machines.
The trouble is that the code is in fact overly threaded, almost to the point of absurdity actually. Between that, far more global data than there should be, poor locking and thread sync strategies layered on top of each other to the point of being beyond untangling…well the code just doesn’t benefit from many cores because it can’t get out of its own way. Many smart minds have thrown many ergs at the problem of improving the scalability…without finding any reasonable strategy for improvement beyond starting over again (and we’ve seriously considered that by the way, in no small part because of this issue although it’s not the only reason it comes up now and then).
The 64-bit exe is already taking advantage of greater than 4GB of physical RAM installed if you have it. New tiles and other detail upgrade have increased the working set size and of course more physical RAM for user space code compared to the 32-bit exe reduces swapping and such.
But please, don’t walk away thinking the code is single CPU ready only…not true at all and never has been for Falcon 4 in any dialect.
-
This comes up over and over. It’s puzzling to me that the myriad posts on the subject haven’t made it common knowledge for all by this point.
Falcon 4.0 was multithreaded and multi-core capable since before the very first commercial release. I beta tested it for Microprose on NT on 2- and 4-way CPU machines.
The trouble is that the code is in fact overly threaded, almost to the point of absurdity actually. Between that, far more global data than there should be, poor locking and thread sync strategies layered on top of each other to the point of being beyond untangling…well the code just doesn’t benefit from many cores because it can’t get out of its own way. Many smart minds have thrown many ergs at the problem of improving the scalability…without finding any reasonable strategy for improvement beyond starting over again (and we’ve seriously considered that by the way, in no small part because of this issue although it’s not the only reason it comes up now and then).
The 64-bit exe is already taking advantage of greater than 4GB of physical RAM installed if you have it. New tiles and other detail upgrade have increased the working set size and of course more physical RAM for user space code compared to the 32-bit exe reduces swapping and such.
But please, don’t walk away thinking the code is single CPU ready only…not true at all and never has been for Falcon 4 in any dialect.
Most interesting. It was stated in the manual that FBMS does not use any more than 1 core. Since this is not the case, rather the code stepping on itself (so to speak) I understand the complexity of the engine being a difficult code to separate and multi thread properly. Thanks for the info.
-
Actually I think the manual says it’s not optimized for more than CPU…and that’s true: it uses more than one, just not well (as measured by what you would consider good scalability). It is still the case that picking a CPU based on single-threaded integer math performance metrics is typically the best bet. But, having at least two hardware cores will definitely provided measurable improvement over a single hardware core…the problem really is that you don’t get as much for a second core as you should in well threaded code and adding a third or fourth core (or more) nets even smaller gains.
-
IFF.
-
-
IFF.
PPL requesting for IFF, please comm with a full explanation on how it should/could be implemented (avionics + AI/Human interaction) … how you imagine it could be in the sim?
This is what is needed.
ASUSTeK ROG MAXIMUS X HERO / Intel Core i5-8600K (4.6 GHz) / NVIDIA GeForce RTX 3080 Ti FE 12GB / 32GB DDR4 Ballistix Elite 3200 MHz / Samsung SSD 970 EVO Plus 2TB / Be Quiet! Straight Power 11 1000W Platinum / Windows 10 Home 64-bit / HOTAS Cougar FSSB R1 (Warthog grip) / SIMPED / MFD Cougar / ViperGear ICP / SimShaker JetPad / Track IR 5 / Curved LED 27'' Monitor 1080p Samsung C27F396 / HP Reverb G2 VR Headset.
-
PPL requesting for IFF, please comm with a full explanation on how it should/could be implemented (avionics + AI/Human interaction) … how you imagine it could be in the sim?
This is what is needed.
I don’t want IFF (yet). Way to complex for now. If I see what questions arise on the forum now with new 4.33 stuff that is greatly explained in the manuals already, I can only foresee a huge pile of additional questions and ‘bug reports’ when IFF would ever be implemented to its full (non-classified) extend.
But, I do wish we could extract M3 squawk in shared memory for ATC purposes. It can already be entered via UFC, and is visible on the DED, so why not expose it to sharedmem so other programs like F4Awacs can use it.
Same as what has been done now in 4.33 with the altimeter pressure setting. Now MFDE & AIC can read it and use it.EDIT: in addition, one could make IFF IDENT then send a squawk ident trigger to F4Awacs for example.
-
Lets start with AI/Human Interactions. IFF would need the addition of a configurable ID matrix (and possibly configurable ROEs). Add a new file which saves the ID matrix as a text file. In the default setting, AI would each attempt to satisfy their ID matrix before employing ordnance. At its most basic, this would consist of a single item - IFF - if friendly, do not shoot. Otherwise, shoot. This setting would effectively have no effect on the AI behavior compared to 4.33 AI behavior. It would however leave a lot of room for expanding AI behavior. At its most complex, this ID matrix could include different orders of importance of different sensors and include requirements to satisfy all or none of them. Some examples could be VID, TGP-VID, PRINT, SPIKE, MRR/positional ID, POO/OUTLAW, and obviously, IFF.
For humans, only some F-16s have an IFF interrogator (APX-113). Those that do can perform interrogations. Humans interrogating an AI may make it more aware of them, similar to NAILS behavior. AIs, air and ground, can interrogate humans. Humans without proper modes and codes might be fired upon by friendly forces if the ID Matrix can be completed without realising they are friendly!
For proper integration with the use of the 2D UI for AWACS, some level of assumption about use of tactical datalinks would be required to avoid making the UI useless. Friendly ground units could be displayed normally. All other units could be displayed with a neutral color (eg grey) until marked otherwise by a player on the map (this would be a client side action). Aircraft taking off from friendly airbases could be marked friendly by the player or possibly automatically. Merges would need to actually merge the symbols, with contacts separating from the merge being unknown in ID until a sensor of some kind picks them up (eg, surface IFF interrogator, VID by AI or player). This would (I assume) require a massive rework of the way the 2D UI works.
You dont really need us to detail the avionics do you Dee-Jay? Its a lot to go over… dont know if I could fit it in one post.
The way I see it, the avionics is (comparatively) the easy part. Add the 5 IFF pages to the DED, add callbacks for the backup IFF panel… making the AI use it intelligently is the hard part I would guess (take with a large lump of salt, I am not a programmer).
To sum it up, to use IFF, the AI would need to stop knowing your ID as soon as they detect you. This would basically force them to use real world techniques, so the ID matrix makes sense. If you have one, it makes sense to make it configurable so you can change it between theaters and TEs and whatnot. If the AI does not know ID, then the 2D UI makes human AWACS OP, because then the human players would not need to satisfy their ID Matrix, but the AI would, which would give them an unfair advantage. Hence, the nerfing of the 2D UI into more of an AWACS screen.
The other alternative (which would probably require even more work I think) would be to remove aircraft entirely from the 2D UI. Have them still there, but they just are not shown to the player. Instead, a dedicated AWACS interface could be used instead of the 2D UI. Then, actual AWACS limitations could be even more accurately modelled, without having to mess with the 2D UI as much. Downside is, it would need its own avionics. Upside is, it would fit much better with a future upgrade to use Link 16, which would tie the whole thing together in the same way that the current automagic AI ID works.
-
This new version is a huge leap forward concerning realism. It was for sure a giant setp regarding the work load for the dev team. We have all (almost all) thanked the dev team for that.
So I’d also ask for things like Link16, Eisa radar and so on…. but just forget all that, dev team deserves some rest now. (Not very falconeer, but still…)
What I’d like to see soon implemented would be a working/ flyable back seat and a kind of MFDexporter with working buttons for android. -
I would be happy with more realistic comms with Tankers (own frequencies etc)
