Ff you could have one thing in the next update it would be…
-
This post is deleted! -
I would like to see my HUD properly displayed in the hornet. Its hard to read the altitude on the right and impossible to see the Steer point flight time caret on the left. Thank you for all the amazing work!
-
What impact would a moving map display do to overall BMS software performance?
Sent from my XT1080 using Tapatalk
Been previously discussed. Use “search” for “moving map”.
-
Maybe a “cross point”, in the RECON window,
Just to point out selected object at distance, Just a suggestion,
Thanks for all the GREAT work -
I would like to see my HUD properly displayed in the hornet. Its hard to read the altitude on the right and impossible to see the Steer point flight time caret on the left. Thank you for all the amazing work!
I want the same!!!
Enviado desde mi iPhone utilizando Tapatalk
-
+1. You don’t have to “implement” it…you only have to model it. Can say the same for IFF as well.
The same could be said for several systems: IFF, JTIDS, AESA/IRST, HaveQuick, Secure Voice to name a few. They could all be MODELED “relatively” easily. Personally I think JTIDS would be the hardest to do in a semi-realistic manner. But still not terribly hard to do. The underlying functionality already exists with the IDM, it would just need to be expanded past your package. If it were done, and done somewhat correctly, people would stop asking for IFF, which would probably make DeeJay happy. I also feel like that is the biggest “missing” feature that should be a priority to incorporate in the game. I don’t think anyone has expectations for a full JTIDS functionality implementation, because the sim just couldn’t handle it. But the key SA features like identifying participating players and target sort/management could be done I think somewhat easily. Each JTIDS enabled aircraft gets a JU, assigned in order of availability when the entity is created in the 3D world (0-255 on both red and blue would do it i think). After that you could display it on the HSD and FCR the same as the IDM but using the JU number instead of the IDM address. Granted, that doesn’t account for ground enabled JTIDS vehicles, but as people are fond of saying-there are compromises in the SIM world.
Not terribly useful in the Single Player arena, but immeasurably beneficial in a MP environment. And has the added bonus of performing the IFF function that everyone would like to see, but with slightly less fidelity on the FCR than the general God Mode effect that people think IFF provides. Would require some tuning to the HSD and FCR CNTRL pages however to allow for some declutter, but that starts to touch on the much needed updates to all the MFD pages.
-
The same could be said for several systems: IFF, JTIDS, AESA/IRST, HaveQuick, Secure Voice to name a few. They could all be MODELED “relatively” easily. Personally I think JTIDS would be the hardest to do in a semi-realistic manner. But still not terribly hard to do. The underlying functionality already exists with the IDM, it would just need to be expanded past your package. If it were done, and done somewhat correctly, people would stop asking for IFF, which would probably make DeeJay happy. I also feel like that is the biggest “missing” feature that should be a priority to incorporate in the game. I don’t think anyone has expectations for a full JTIDS functionality implementation, because the sim just couldn’t handle it. But the key SA features like identifying participating players and target sort/management could be done I think somewhat easily. Each JTIDS enabled aircraft gets a JU, assigned in order of availability when the entity is created in the 3D world (0-255 on both red and blue would do it i think). After that you could display it on the HSD and FCR the same as the IDM but using the JU number instead of the IDM address. Granted, that doesn’t account for ground enabled JTIDS vehicles, but as people are fond of saying-there are compromises in the SIM world.
Not terribly useful in the Single Player arena, but immeasurably beneficial in a MP environment. And has the added bonus of performing the IFF function that everyone would like to see, but with slightly less fidelity on the FCR than the general God Mode effect that people think IFF provides. Would require some tuning to the HSD and FCR CNTRL pages however to allow for some declutter, but that starts to touch on the much needed updates to all the MFD pages.
Agreed…with the caveat that if AWACS were smarter and available in single player Campaign, and/or in a the Training mission (which might also include a bullseye relnav primer), there could be additional benefit to be had in single player.
-
Moving ground grew. Some of them lead my taxing direction and salute at the end of ramp start. command with ground grew.
-
I would like to see a dedicated MP server, designed specifically to eliminate the 3D environment from the executable, which saves a TON of CPU cycles during the game loop. I know there are dedicated server solutions available from 3rd party developers out there, but I would like to see a dedicated server from the BMS team, designed specifically to inter-operate with the BMS client, because it provides a path to overcome a lot of the limitations in the game that result from bubbles, and bandwidth, and helps provide some paths to implement things like JTIDS and extended range radars, and longer range missiles, etc…
A server which completely removes the 3D rendering aspect of the game loop in the executable can save a lot of CPU cycles. It also has the ability to maintain a master list of objects for the entire 3D environment without the need to spend CPU cycles on drawing, or even determining what does and doesn’t need to be drawn, and a lot of other overhead that DX brings with it. I think the 3D should be more of a hybrid, incorporating the bubbles for things like weapon deployment, chaff/flare, DOF and control surface, and all the other niceties which only impact things inside that bubble. But master location of aircraft and vehicles should be kept server-side and pushed out to the clients. Doing that would enable the avionics to see more than just the “Lead” unit of a flight or ground formation even outside the bubble. It enables JTIDS to be implemented in a more realistic way and to function with more than just the Package and outside the bubble. It provides the mechanism to actually populate the 2D map in the campaign with more than just the Flight Lead info, but individual aircraft as well (Which provides the GCI/AWACS view that a lot of people ask for), and a slew of other things which could be great for the sim.
This would require a considerable amount of work, but I think it’s a foundation step which opens the door for a lot of other features and functionality that people would like to see. I think it might also lay the framework to help alleviate some of the issues like Carrier positioning for MP clients, provides a mechanism to overhaul the ATC functions and extend them past basic TO/LAND clearance, incorporate IADS, and several other things which are currently limited by the inability to universally share position data for “Large” entities. Again, weapon deployment and flares and things which don’t effect the whole theater should not be maintained by the centralized list, but should still be in the bubble. The client would have to change to aggregate the data from both the bubble and the server, but that’s a much easier task than it sounds like–just time consuming because the data is used in so many different places.
-
AFM would be pretty awesome for the Rafale.
-
The same could be said for several systems: IFF, JTIDS, AESA/IRST, HaveQuick, Secure Voice to name a few. They could all be MODELED “relatively” easily. Personally I think JTIDS would be the hardest to do in a semi-realistic manner. But still not terribly hard to do. The underlying functionality already exists with the IDM, it would just need to be expanded past your package. If it were done, and done somewhat correctly, people would stop asking for IFF, which would probably make DeeJay happy. I also feel like that is the biggest “missing” feature that should be a priority to incorporate in the game. I don’t think anyone has expectations for a full JTIDS functionality implementation, because the sim just couldn’t handle it. But the key SA features like identifying participating players and target sort/management could be done I think somewhat easily. Each JTIDS enabled aircraft gets a JU, assigned in order of availability when the entity is created in the 3D world (0-255 on both red and blue would do it i think). After that you could display it on the HSD and FCR the same as the IDM but using the JU number instead of the IDM address. Granted, that doesn’t account for ground enabled JTIDS vehicles, but as people are fond of saying-there are compromises in the SIM world.
Not terribly useful in the Single Player arena, but immeasurably beneficial in a MP environment. And has the added bonus of performing the IFF function that everyone would like to see, but with slightly less fidelity on the FCR than the general God Mode effect that people think IFF provides. Would require some tuning to the HSD and FCR CNTRL pages however to allow for some declutter, but that starts to touch on the much needed updates to all the MFD pages.
I think the sim could handle a full implementation. would be nice to have IFF as well, though. As you touch on, they do provide somewhat different services to one another.
-
Moving ground grew. Some of them lead my taxing direction and salute at the end of ramp start. command with ground grew.
Yes. There was an F/A-18 sim with those I remember on the Carrier. More than one of them got ingested as I tried to taxi to the cat!
-
I think the sim could handle a full implementation. would be nice to have IFF as well, though. As you touch on, they do provide somewhat different services to one another.
Not a chance. Even if they did what I said before and had a dedicated MP server to host all the “big” data, you couldn’t do a quarter of what JTIDS is capable of, or in the same way it communicates with other terminals. JTIDS provides everything from position data, to a secure voice channel, to targeting and track information, airfield weather, data/text messages, aircraft status updates, loadouts, navigation/waypoint information, and the list goes on. Trying to do a full implementation would mean passing more data around than every client passing every other client every entity in the theater redundantly, and all their own DOF/chaff/flare/weapons/position/etc…. But the truth is you don’t need a full implementation. You need location and track data for the FCR/HSD and targeting information. As mentioned before, it’s about modelling a system to a degree of accuracy and usefulness within the limits and capabilities of the sim. 90% of the capabilities of JTIDS would be utterly useless in a SIM environment. Airfield weather? Secure voice? no reason for either. Messaging to other flight members? The game already has this functionality if you can’t use IVC or TS. But targeting and track data would be unbelievably helpful, both in the pit and in the 2D map.
Again, I personally think the best way to do this would be a separate, dedicated executable to handle all the big-theater non 3D stuff. Basics such as 3D position, vector, speed, red/blue, dirty (detected), RF transmitting, and target information is really about all you need. All the other overhead in the 3D model should still be handled locally by the client once the entity enters the player bubble, because the status of 90 DOFs on an entity across the map doesn’t really effect most clients. This is why a standalone MP server would be so beneficial. Calculating everything required for a full 3D battlespace for everything in the theater is computationally unfeasible for most systems, which is why the Player Bubble system came into existence to begin with. But even a 15 year old moderate-spec system can calculate basic position and orientation data for a few hundred entities in the theater and pass the basic data to clients, with little to no impact on the current campaign engine, if the DX component were removed from the equation. A dedicated “Server” or “Campaign Engine” executable could be command line driven which frees up all the CPU required to run DX (And potentially with some crafty coding allows you to leverage the much better Math processing of the GPU to assist). The key, or “Hard Part”, is finding a good way to pull all the data into the existing client 3D environment gracefully. I have no idea what the current multiplayer code looks like so it’s impossible to speculate on how hard this would be, but it’s certainly not impossible.
-
Not a chance. Even if they did what I said before and had a dedicated MP server to host all the “big” data, you couldn’t do a quarter of what JTIDS is capable of
Well, there we will have to disagree. Call it an axiom.
-
Advanced moving digital map
Previous request : https://www.benchmarksims.org/forum/showthread.php?11004-Block-52-Advanced-moving-digital-map&highlight=CMFD
-
hot pit re-arming would be pretty sweet, too
also if they could check the oil and wash the windshield…
-
@b.s.:
hot pit re-arming would be pretty sweet, too
also if they could check the oil and wash the windshield…
+1
I’d love to be able to rearm and reengage.
-
Again, I personally think the best way to do this would be a separate, dedicated executable to handle all the big-theater non 3D stuff. Basics such as 3D position, vector, speed, red/blue, dirty (detected), RF transmitting, and target information is really about all you need.
I’ve floated a 10 second dump of flying objects from the database to a nonblocking fifo (that goes on to null)
Your Radar script then reads that dump, gonkulates what it needs to display and then manages its own database of “picture”.All we really need is x,y,z position, vector, and speed (and mode 3 would be pretty sweet)
All it outputs is “something is detected, moving at position x,y,z at time t and it is squawking mode3 xxxx (or nothing)”…
nothing else.I can’t imagine that querying those what, 9 items out of the database and writing them out would cause very much of a hit to the server’s execution at all… --the server already does this anyway, right??? just dump it to a pipe, and we’re in biz
And we only need it once every 10 or 12 seconds…A string of up/down RADAR’s should also let the thing gonk out what is and isn’t in coverage at a various location/altitude (/radial velocity).
Different output to different “sides” suppose multiplayer force v force… where that side only sees what its radars see.
It’s a lot of annoying math, but any reasonable computer process should be able to handle jamming through what, maybe a total of less than 100 items, in microseconds.
Planes squawking mode 3 iaw that side’s ATO can be colored blue automatically and every other track should be “unknown” by default.
Your C2 nerds can manage id matrix from that point.This will cut out several kinds of nonsense that manifest with what we have now.
That’s how I would do it.
I have a little bit of coding skills.
Offer’s on the table. -
+1
I’d love to be able to rearm and reengage.
you wouldnt love waiting around to do so. Id like a more realistic turnaround time for hot pit refueling.
-
@b.s.:
I’ve floated a 10 second dump of flying objects from the database to a nonblocking fifo (that goes on to null)
Your Radar script then reads that dump, gonkulates what it needs to display and then manages its own database of “picture”.All we really need is x,y,z position, vector, and speed (and mode 3 would be pretty sweet)
All it outputs is “something is detected, moving at position x,y,z at time t and it is squawking mode3 xxxx (or nothing)”…
nothing else.I can’t imagine that querying those what, 9 items out of the database and writing them out would cause very much of a hit to the server’s execution at all… --the server already does this anyway, right??? just dump it to a pipe, and we’re in biz
And we only need it once every 10 or 12 seconds…A string of up/down RADAR’s should also let the thing gonk out what is and isn’t in coverage at a various location/altitude (/radial velocity).
Different output to different “sides” suppose multiplayer force v force… where that side only sees what its radars see.
It’s a lot of annoying math, but any reasonable computer process should be able to handle jamming through what, maybe a total of less than 100 items, in microseconds.
Planes squawking mode 3 iaw that side’s ATO can be colored blue automatically and every other track should be “unknown” by default.
Your C2 nerds can manage id matrix from that point.This will cut out several kinds of nonsense that manifest with what we have now.
That’s how I would do it.
I have a little bit of coding skills.
Offer’s on the table.The problem here is that each entity doesn’t actually exist in the Campaign engine until it is close enough to a player to trigger creation, only the lead object of a flight or ground formation. This is why the 2D map only shows the lead aircraft, and your IDM will stop working if you get too far away from your flight or package members. AI vs AI combat is not simulated in a 3D mock combat sense, it is statistically calculated, unless it happens close to a player. You can pull a dump of the objects now from the text stream by walking the memory and get everything on the 2D map, which is the basis of F4AWACS, but there is no current way to get the position of all the entities in the campaign environment, because they don’t all actually exist. This is why I said it would require a good deal of work and have to be specifically coded to integrate with the BMS client, which would also need a good deal of work to pull all the data in. This is also why I say a dedicated server for something like this, because you don’t need the theater-wide data for SP or a TE, per se. The client can more or less stay as it is, it just handles the incoming data similar to if it were inside another player’s bubble, but it would have to know not to expect certain data that usually comes across the stream, such as the position of the pilot’s head, or the angle of flaps, etc… for entities outside the draw range.
And for reference the E3 radar takes 6 seconds to do one full revolution, and most ground radars are 2-4 seconds. So a little more frequent than 10-12 seconds, but still not constant. Truth be told though, depending on how much calculation you are doing and the number of entities in the campaign it might take several seconds for a game loop cycle, so it would probably be more feasible to just remove a time limit and let the game loop cycle as quick as possible. This would simulate the aggregated data input from all sources, such as data links or being painted by multiple radars.