Steel Beasts: Content Wish List

[Rotareneg]

Here's another idea for dealing with AARs on multi-part scenarios like the OP4 mission: add an option for the host to password protect the AARs. That way, everyone gets an AAR recorded as usual, they just can't be viewed until after the coordinator gives out the password.

[Gibsonm]

Yes but then a given side's CO misses out on a good mission planning support tool to help plan the next mission.

Swings and roundabouts.

[Tacom]

Limit the AAR to visible enemy units?

[Olifant]

Road embankment.

[MDF]

Now that I have nearly a year of experience with the sim under my belt, here are some of my wishlist items. I have tried to limit the list to things that, in my humble estimation, will require relatively little coding/testing effort.

1. High-speed LOS fan. The current "Mark LOS from here" feature can take up to a couple of seconds to draw, depending on the terrain. This can be a drag if you're testing multiple points around a given position. As an alternative, put a check-box near the LOS slider controls allowing user to request a high-speed calculation option. Under that option, the LOS routine draws just one LOS "spoke" every, say, 50 mils from the designated point. Each spoke line would have a combination of red, dark red, white, or transparent segments, in keeping with the current LOS display. The interstices between spokes are not filled in. This 6400-mil "fan" of 128 spokes should give the user a reasonable estimate of the visibility from that point, while saving calculation time. Alternatively, allow the user to input the number of radians between LOS "spokes," or perhaps instead offer several hard-coded choices of mil interval (like the impact-area attitude listbox in the call-for-fire dialog). I realize that the current LOS drawing routine probably already draws LOS spokes at some predetermine mil interval and interpolates to fill in the interstices; if my 50-mils suggestion is already close to what is already in place, then some higher number would be useful to allow the user to specify a different tradeoff of time-versus accuracy.

2. In the context (i.e., right-click) menu for waypoints, add "Mark LOS from here" as a choice. Right now, its a PITA to see the LOS from an exact waypoint -- you must either zoom all the way in to allow you to right-click very close to the WP *without* instead selecting the WP, or switch to the LOS map view. And if you choose the latter, the LOS data clears when you switch back to the terrain view, so you can't reorient a BP waypoint with reference to the full LOS fan.

3. More finely-grained information environment: map updates. Currently, the mission editor affords three options: (1) updates for both friendly and enemy units; (2) updates for friendy units only (i.e., "Blueforce Tracker"); and (3) no updates for either. It would be great to have some additional granularity. I would suggest allowing the mission editor to specify: (4) updates only for currently-occupied vehicle; (5) update only for currently-occupied platoon; and (6) update only for company of currently-occupied platoon.

I realize that currently you can accomplish this, in a fashion, by splitting a particular side into different parties, and setting each party's map update option to "own party," but this is problematic, for several reasons (beyond aesthetic ones). First, the separate parties cannot share artillery support. If using off-map artillery, each party would have to be given its own artillery support. Obviously, you don't want each company or platoon to be able to call simultaneously on the full weight of the battalion's supporting arty from the call-for-fire dialog, but if you divide the available tubes amongst the different parties, you lose the ability to mass fires. If, instead, you create a separate party for the fire support element (which may be perfectly desirable in some circumstances), you lose the ability to have other elements use the call-for-fire dialog; in effect, you're locking yourself into the "only fire support units may call for fire" option in the mission editor artillery support dialog box. Second, in addition to these allocation issues, you're quickly going to run out of available parties. There are only 12 available parties. In head-to-head scenarios between opposing battalions, for example, you could split each side into company-sized parties, but not platoon-sized parties. Third (and admittedly least significantly), having a welter of differently-colored parties makes the AAR map view rather confusing.

Obviously, in real life the ability to send and receive Blueforce-tracking data and ENY situation data requires a battle management infosystem and, strictly speaking, users should not be send or receive such unless they are in a vehicle so equipped. This has been said before by others. The counterargument has been put forward that the typical SB player is overtaxed compared to his real-world counterpart and that map updates are really just a shortcut representing the manual receipt of situation data and recording it on a paper map. Both points are valid, IMHO, and there is no single correct approach. It should be left up to the mission designer to tailor the information environment to the anticipated needs of the user and to the desired level of realism. That's why I think it's so important to maximize the number of options available.

Moreover, by allowing for multiple levels of send/receive capability within a single party, mission designers can recreate situations where different kinds platforms are unable to interchange info with each other (e.g., the initial IVIS system on the M1A2 could only communicate with other M1A2s; no other US platform had IVIS at the time). Ideally, each vehicle type would have its own info send/receive capabilities (perhaps configurable in the options dialog box, like ammo is), but, as noted, I'm trying to limit my suggestions to relatively low-effort solutions.

4. More finely-grained information environment: transmission of graphics. Also useful would be the ability to have the following options with respect to transmission of graphics: (1) user can draw and move graphics on his own map, but cannot transmit; (2) can transmit graphics only to own platoon; (3) can transmit graphics only to same party; and (4) can transmit graphics to all friendly parties. Same rationale as set forth in previous point. Additionally, the ability to "transmit" graphics only to ones own platoon can be seen as a stand-in for flags/hand-signals.

More in next post.:bigsmile:

[MDF]

(Continued)

5. Mouse scroll wheel input in conditional-logic dialog: when the number of units, waypoints, or graphical objects gets very large, it is cumbersome to cycle through them in the conditional-logic dialog box, even using the shift-key accelerator. Allow the listboxes for these items to accept scroll wheel input to cycle through in a more rapid and ergonomic fashion.

6. Objects listview. It can also be very difficult in larger and more complex missions to find a particular waypoint, region, or other graphical object amongst the clutter. It would be nice if you could open up a control that lists all of the waypoints and other objects, click on the object, and have the map view centered on the now-highlighted object. Give the option to filter the list be object type (waypoint, region, etc.) and to sort the list by time of creation, the object's underlying numerical ID, or the object's given name (if it has one; otherwise order by number ID).

7. More user-specifiable boolean operators: in the boolean expression part of the conditional logic dialog box, six of the seven boolean operators are fixed as either AND or OR. For example, currently you are limited to four disjunctive operands (i.e., condition1 OR condition2 OR condition 3 OR condition4). I find that there are many occasions that I need additional flexibility. So, it would be fabulous if each of the operators could be selectable as AND/OR from a drop-list in the same manner as the first one is. It would also be useful if you could add the exclusive-or (XOR) operator in each place, as well as the "not" operator for each of the operators except the three innermost ones (which already allow for negation).

8. Persistent buttoned/unbuttoned state for TC: I share the opinion that the F8 view is unrealistic. If you wanna see outside the vehicle, get up out of the hatch. The problem with the latter is that every time you unbutton and then, for whatever reason, switch to the another position or another vehicle, when you return to the original vehicle TC position, he has dropped back into the turret. So, you've got to hit 'Q' again (twice), and wait for him to elevate himself. This is irritating after a while. From what I can tell, each vehicle has a different AI state for "under threat" and "not under threat." Clearly, if the vehicle starts taking fire while you are away from the TC position, you do want him to button up. But I would suggest that as long as the vehicle is not threatened, the TC remain in whatever posture the user left him in. I realize that if left unbuttoned, the TC will not be periodically employing stabilized peris or other goodies unavailable outside the turret. I thing that the user should be empowered to decide on this risk management. Additionally, if in the judgment of eSims the TC must lower himself into the turret to read the map (in the case of vehicles with BMS, this would be the case; perhaps not with paper maps), then I suppose that going to F5 view should not leave the TC unbuttoned. But going to the gunner or driver position, or another vehicle, should do so.

9. Persistent settings for map graphics. Currently, settings such as color, style, text size, and unit size for various map graphics default to a preset value (black, solid line, etc.) In my experience, it is far more likely that the any object I create usually is going to have the same values as the last one I created. For example, if I'm creating a series of BPs for friendly forces, I use blue. Currently, that means I have to laboriously customize the object attributes each time I create a new BP. I would prefer if a new object defaulted to the same color, style, text color/scale, etc. as the previous one. This should not be much more complicated than adding static data members for each value to each of the graphical object classes (or possibly parent classes); storing the currently-selected value in the appropriate static data member; and using these values to initialize new objects.

(Continued. Yeah, I know: :heu:)

[MDF]

(Last one :luxhello:)

10. Additional overlays for map graphical objects. Currently, you can turn on/off "information" and 'artillery." It would be great if, instead, there were six different graphical "layers": (1) the default or base layer, (2) operations, (3) intelligence, (4) fire support, (5) mobility/countermobility, and (6) logistics. The base default/base layer shows friendly unit icons, friendly waypoints and routes, and during Execution phase, enemy unit icons. This is identical to the current F5 view, wth the "Information" and "Artillery" switches set to "Off." I would suggest giving the user the other five layers to afford more flexibility with cluttering and decluttering. So, he can draw his unit boundaries, maneuver graphics, etc. on the Operations overlay. Draw known and suspected enemy positions and the recce & surveillance plan on the intel overlay, and so on. TRPs (except for the panel type) probably should appear only on the Fire Support layer. The FS layer would have other player-drawn graphics, such as planned artillery impact zones, etc. During the Execution phases, pending/active/completed fire support missions would appear on the FS layer. The mobility/countermobility layer could be used for player-drawn graphics showing "no-go"/"slo-go" and other terrain analysis, and planned obstacles (e.g., FASCAM). It would also shouw objects with specific programmatic effects like friendly and detected enemy minefields. The logistics layer would be used to show things like casualty collection points and operations graphics for service support units. When the Execution Phase begins, all the layers should default to "On" -- you don't want someone running into a newly-detected minefield because he forgot to turn the "mobility/countermobility" layer to "On."

11. Deployable Panel TRP. Currently, of the 4 types of TRPs available in the mission editor, only the "Panel" type cannot be made deployable during the planning stage. It would be helpful to make them deployable, so that forces in defensive positions can use them to mark engagement area boundaries and sectors of fire, like the US field manuals recommend. (It might be even more useful to give the players a more inconspicuous marker for that purpose.)

12. Restricted view function during planning phase. The ability (in the mission editor) to restrict the F1 view to specific zones during the planning phases. There are times in real life when you cannot visually reconnoiter your AO due to enemy activity or lack of time. This should be coupled with the ability to limit the elevation of F1 view to a specified value (e.g., the maximum height standing on a vehicle turret, climbing a tree, or the view from a rooftop. The elevation limitation should be an attribute of the restriction zone, so you can use multiple zones to differentiate betwee areas with different kinds of vantage points (e.g., zone with high-rises could be given a higher limit)

13. For the love of God, company-level halt/engage/resume route commands!! How 'bout shift+s, shift+e, and shift+c ? Or doubletaps for these keys? The program already recognizes platoons' company affiliation, right?

14. An 0.5 text-scaling option for graphical objects. Sometimes, the 1x scaling is just too large, and the no-scaling option doesn't fit the bill.

15. It would also be useful if the parameters in the conditional-logic dialog box would recognize the full command structure rather than just structure of the units as deployed. For example, if Platoon 1/A is deployed as a single consolidated platoon (i.e., all vehicles are part of a single platoon icon), the conditional logic dialog will not allow me to specify an individual vehicle or section of 1/A as a criterion. So, for example, I'd like to have the platoon move as a single entity down a route but, at some point, have the route branch into two routes and have each section take a different branch. In theory, you could do this by giving one branch route an embark-if condition of "(this is unit <1/1/A>) OR (this is unit <2/1/A>)" and the other an embark-if condition corresponding to the other two vehicles in the platoon. Currently, you can't do this in the Planning phase, because you can't divide units and, because the conditional-logic dialog box only displays the force structure in its current deployed form, it will only give you the choice to select platoon 1/A and NOT the individual vehicles in 1/A.

That's it for now. Bear in mind, I've been saving these up for almost a year.:c:

[Gibsonm]

4. More finely-grained information environment: transmission of graphics. Also useful would be the ability to have the following options with respect to transmission of graphics: (1) user can draw and move graphics on his own map, but cannot transmit; (2) can transmit graphics only to own platoon; (3) can transmit graphics only to same party; and (4) can transmit graphics to all friendly parties. Same rationale as set forth in previous point. Additionally, the ability to "transmit" graphics only to ones own platoon can be seen as a stand-in for flags/hand-signals.

Unless I'm missing something that is already there?

[Gibsonm]

9. Persistent settings for map graphics. Currently, settings such as color, style, text size, and unit size for various map graphics default to a preset value (black, solid line, etc.) In my experience, it is far more likely that the any object I create usually is going to have the same values as the last one I created. For example, if I'm creating a series of BPs for friendly forces, I use blue. Currently, that means I have to laboriously customize the object attributes each time I create a new BP. I would prefer if a new object defaulted to the same color, style, text color/scale, etc. as the previous one. This should not be much more complicated than adding static data members for each value to each of the graphical object classes (or possibly parent classes); storing the currently-selected value in the appropriate static data member; and using these values to initialize new objects.

Not quite what you are after but are you aware that you can draw several items, shift click to select them all and then apply the changes to all (colour, text size, etc.)?

[wolfstriked]

Second day back and I am back to da_list! I would like to see the TC hatch not be closed when you jump to gunners position.Sorta mentioned in post before me but different in that I don't mind pressing Q to raise back out of tank but rather I find the wait for the hatch to open extremely bad,of course the real culprit is the 2E with its slow mechanically operated hatch.I would rather have the ability for artillery to fall thru the hatch if I get unlucky and am in the targeted area and then have to scramble to close the hatch.To constantly wait for the hatch to open though is plain tedious,especially since I jump from station to station alot.

Similar to MDF's request for TC to stay in position you last left him,I would like to see this for the drivers position,as long as not under attack of course.I like to jump around thru the positions and this is another tedious one for me,aka to have to press drivers position and then press "go up" to unbutton.

When you give command for gunner to scan left/right the gunner should stay there until you say otherwise.Its for times like when you enter an intersection and want gunner to scan one way while you scan the other.Right now I spam the look left/right key.Its doable but I feel that more command would be better.I remember reading that one day maybe we will have collidable turrets and I am ready for it with the constant attention and roleplay I do right now.:luxhello:

Finally.....is it possible to change the FOV by using the mouse scroll wheel? 24in monitor and I find when I unbutton and scan the horizons that its very hard to see.If I switch to F8 view the FOV is perfect IMO and allows me to better search the tree lines/look down city streets etc,but I am the type of player that is against F8 view.:c: Mouse wheel forward and back to switch between two FOV's would be excellent IMO.

[Gibsonm]

Similar to MDF's request for TC to stay in position you last left him,I would like to see this for the drivers position,as long as not under attack of course.I like to jump around thru the positions and this is another tedious one for me,aka to have to press drivers position and then press "go up" to unbutton.

Except in real life having the driver unbuttoned and "up" will result in death or injury to the driver from the turret/gun movement or blast when firing, let alone the enemy shooting at him.

[MDF]

Unless I'm missing something that is already there?

I think what you're referring to is that the present transmit-graphics function gives the player the option to to send a particular graphic to party/side/company/vehicle/platoon. What I meant is that mission designers should be given the option to specify the degree to which players have the ability to transmit graphics at all and to whom. I suppose you can accomplish this now using the honor system (i.e., "mission briefing says our vehicles are not equipped with BMS, so we won't send graphics to each other, OK?").

[MDF]

Not quite what you are after but are you aware that you can draw several items, shift click to select them all and then apply the changes to all (colour, text size, etc.)?

I did NOT realize that. :c: OK, I retract this request.

[wolfstriked]

Except in real life having the driver unbuttoned and "up" will result in death or injury to the driver from the turret/gun movement or blast when firing, let alone the enemy shooting at him.

I understand when under attack but I drive unbuttoned all the time in SB with turret scanning overhead.:confused:

[Gibsonm]

I understand when under attack but I drive unbuttoned all the time in SB with turret scanning overhead.:confused:

Yes but if you are "not an F8 person" presumably for reasons of realism, then the same should apply for the driver remaining closed down, at least in IMHO.

[wolfstriked]

Yes but if you are "not an F8 person" presumably for reasons of realism, then the same should apply for the driver remaining closed down, at least in IMHO.

It is for realism reasons but I find that I have to still use F8 as the zoom is a little better.The ability to zoom in slightly is my biggest wish on the list actually since going to binoculars is too restrictive.

And for the driver staying buttoned up I think your right but I wonder if what I do is actually used by tank crews.When in urban maps and nearing an edge of a building the view around the corner is horrendous in gunners position and not much better in TC position but the driver is seated towards front of tank and so can minimize the amount of tank showing with his better view.Unbutton and you can lean just a little more forward to spot first.Plus the throttle control is much better in drivers position allowing you to move at a crawl pace.

[Gibsonm]

And for the driver staying buttoned up I think your right but I wonder if what I do is actually used by tank crews.

Well I can confirm that in our Army whenever a tank moves (and indeed whenever the turret stabilisation / hydraulics are activated) the driver is down and his hatch closed.

This is a combination of "train as you fight" and a WHS requirement.

The only exception to this being when the gun is over the back of the hull in the travel cradle (and indeed the turret stabilisation / hydraulics are off) for an admin move onto a tank transporter or rail car, etc.

This applied to Centurion (before my time), Leopard and M1. It also applies to ASLAV-25 and anything else with a stabilised gun that could just decapitate / severely injure the driver.

Those rules apply to both the physical vehicle in real life and tank crews in Steel Beasts and indeed the other simulators that we use.

I'm pretty sure these rules apply to most modern MBT where the driver is nested under the turret. IIRC some also have safety cutouts so the turret wont move unless the driver's hatch is closed (M1A2 SEP for one).

[wolfstriked]

Well I can confirm that in our Army whenever a tank moves (and indeed whenever the turret stabilisation / hydraulics are activated) the driver is down and his hatch closed.

This is a combination of "train as you fight" and a WHS requirement.

The only exception to this being when the gun is over the back of the hull in the travel cradle (and indeed the turret stabilisation / hydraulics are off) for an admin move onto a tank transporter or rail car, etc.

This applied to Centurion (before my time), Leopard and M1. It also applies to ASLAV-25 and anything else with a stabilised gun that could just decapitate / severely injure the driver.

Those rules apply to both the physical vehicle in real life and tank crews in Steel Beasts and indeed the other simulators that we use.

Considering I never even seen a tank in real life I take your word on it.And there goes my use of it to get a better peek around corners.:bigsmile:

[SuperSerp]

Hmmm, I'm honestly not sure what I'd rather have more, a T-80 (best would be the U variant but I'd take any) or fully animated interiors (gun, crew, auto loader, all that stuff). Orrrr maybe I can get both ;{D

[Froggy]

8. Persistent buttoned/unbuttoned state for TC: I share the opinion that the F8 view is unrealistic. If you wanna see outside the vehicle, get up out of the hatch. The problem with the latter is that every time you unbutton and then, for whatever reason, switch to the another position or another vehicle, when you return to the original vehicle TC position, he has dropped back into the turret. So, you've got to hit 'Q' again (twice), and wait for him to elevate himself. This is irritating after a while. From what I can tell, each vehicle has a different AI state for "under threat" and "not under threat." Clearly, if the vehicle starts taking fire while you are away from the TC position, you do want him to button up. But I would suggest that as long as the vehicle is not threatened, the TC remain in whatever posture the user left him in. I realize that if left unbuttoned, the TC will not be periodically employing stabilized peris or other goodies unavailable outside the turret. I thing that the user should be empowered to decide on this risk management. Additionally, if in the judgment of eSims the TC must lower himself into the turret to read the map (in the case of vehicles with BMS, this would be the case; perhaps not with paper maps), then I suppose that going to F5 view should not leave the TC unbuttoned. But going to the gunner or driver position, or another vehicle, should do so.

I am totally against.

Why? because what I want the AI to do is to react like a real crew, and then to not expose itself (if YOU are in position unbutonned and injured it's your fault).

If the AI TC stay in the last position you were, it would add more data to store (in fact for each vehicule, position of any crew that may unbutonned)

10. Additional overlays for map graphical objects. Currently, you can turn on/off "information" and 'artillery." It would be great if, instead, there were six different graphical "layers": (1) the default or base layer, (2) operations, (3) intelligence, (4) fire support, (5) mobility/countermobility, and (6) logistics. The base default/base layer shows friendly unit icons, friendly waypoints and routes, and during Execution phase, enemy unit icons. This is identical to the current F5 view, wth the "Information" and "Artillery" switches set to "Off." I would suggest giving the user the other five layers to afford more flexibility with cluttering and decluttering. So, he can draw his unit boundaries, maneuver graphics, etc. on the Operations overlay. Draw known and suspected enemy positions and the recce & surveillance plan on the intel overlay, and so on. TRPs (except for the panel type) probably should appear only on the Fire Support layer. The FS layer would have other player-drawn graphics, such as planned artillery impact zones, etc. During the Execution phases, pending/active/completed fire support missions would appear on the FS layer. The mobility/countermobility layer could be used for player-drawn graphics showing "no-go"/"slo-go" and other terrain analysis, and planned obstacles (e.g., FASCAM). It would also shouw objects with specific programmatic effects like friendly and detected enemy minefields. The logistics layer would be used to show things like casualty collection points and operations graphics for service support units. When the Execution Phase begins, all the layers should default to "On" -- you don't want someone running into a newly-detected minefield because he forgot to turn the "mobility/countermobility" layer to "On."

like this:

6 layers but differents from yours (because we can send order of movement (routes), :

- received OBServation orders (position and sectors) (OBS)

- received graphicals missions ORDers (ORD)

- received friendy (automatic)/enemy (reported) positions (AMI ENI)

- received support graphics (artillery and mobility/countermobility) (APP)

- working layer (all graphic you create yourself and you can share) (blank)

- navigation layer (all routes, you create or you received) (NAV)

your definitions are good for SB, though.

[georgerutherford1861]

And for the driver staying buttoned up I think your right but I wonder if what I do is actually used by tank crews.When in urban maps and nearing an edge of a building the view around the corner is horrendous in gunners position and not much better in TC position but the driver is seated towards front of tank and so can minimize the amount of tank showing with his better view.Unbutton and you can lean just a little more forward to spot first.Plus the throttle control is much better in drivers position allowing you to move at a crawl pace.

We were always taught that if we wanted to look around a corner or clear an intervisibility line, the TC should just dismount and do the looking, helping reduce the chance of being observed and revealing the tank's position. Of course, whether TCs took it upon themselves to actually get off the tank and do so is another point entirely.

Doug

[wolfstriked]

We were always taught that if we wanted to look around a corner or clear an intervisibility line, the TC should just dismount and do the looking, helping reduce the chance of being observed and revealing the tank's position. Of course, whether TCs took it upon themselves to actually get off the tank and do so is another point entirely.

Doug

Was thinking this last night but I would send the loader.:bigsmile:

[MDF]

I am totally against.

Why? because what I want the AI to do is to react like a real crew, and then to not expose itself (if YOU are in position unbutonned and injured it's your fault).

If the AI TC stay in the last position you were, it would add more data to store (in fact for each vehicule, position of any crew that may unbutonned)

I would question your premise that a real crew always stays inside the vehicle.

Clearly, the vehicle AI opens and closes turret hatches on its own. From what I can tell, it closes the hatches when taking fire and opens them when it decides its not under threat. Since crewman are not visually depicted, we don't know whether the TC is outside the turret or not when the hatch is open. (Admittedly, perhaps you know more about the program than I do and you can say whether I am correct or not).

In MBTs with thermal-equipped TC periscopes, it probably makes sense for the TC to stay inside the turret most of the time, as it's easier to acquire targets with TIS than with binos or the naked eye. For earlier tanks such as the M1 series prior to the SEP -- and maybe even for tanks with stabilized NON-thermal peris -- the TC would be spending much more time outside the hatch, notwithstanding the possibility of UNexpected attack. I recall Ssnake himself stating at some point that, in his own experience, TCs do and should spend most of their time outside the hatch. I believe he has said that he was a Leo2A4 crewman, so this speaks volumes about the situation even where the TC has a stabilized peri. And I think his advice to SB users was the same -- TC should operate outside most of the time. (I hope Ssnake will correct me if my memory is faulty).

With this in mind, I think it's possible to accommodate both your view and mine. For vehicles with an (operable) TC thermal peri, the TC will drop back into the turret whenever you leave the F7 position. For other vehicles, the TC posture persists until (1) you change it, or (2) the vehicle is "under threat" according to the AI code. Obviously, there is always risk of unexpected attack (sniper; IED; unspotted enemy units; artillery). But, if real-world practice is that TCs of particular vehicles stay exposed to achieve maximum SA unless faced with immediate immediate threat, as is true with the earlier M1s, for example, then I think my suggestion is valid -- TC stays where you leave him unless vehicle is "under threat" per the AI.

Of course, there is always the possibility of enabling the user to specify in each situation; for example, pressing 'b' (or better yet, a double-tap, to minimize inadvertent changes) when the TC is already out of the hatch makes the posture persistent as described above.

Finally, this doesn't necessarily require more data storage. The posture for both TC and driver a can be stored with two bits (e.g., 00= inside turret; 01= exposed with hatch in overhead-cover position (for M1); 10= semi-exposed, hatch fully open; 11=fully exposed), for a total of 4 bits per vehicle. If SB uses bit flags to store AAR data in a space-saving fashion, there may be unused bits left over in a particular variable, so no additional space would actually be needed. If not, the most we're talking about is a single two-byte wide-character variable per vehicle per write (and their compiler may still allow for one-byte character variables).

So, in a 100 vehicle mission, we're talking a maximum of 200 bytes every 4 seconds (for "non-event" file writes) plus 200 bytes per "event" (I'm assuming state is recorded for every vehicle during events, and not just the shooter and victim). Assuming a 60 minute mission, that's 200 bytes x (3,600 secs/4) events = 180,000 bytes, plus, let's say, 500 events: 200 x 500 = 100,000. That's a total of 0.28 megabytes of additional space; half that if they use single byte chars. The last Operation Variable 4 mission had well over 100 vehicles, approximately 500 events, and was 62.5 minutes long, so it is well within the parameters of the hypothetical mission just discussed. The AAR file is 89.2 megabytes. Adding another ~0.28 MB (worst case) to that AAR file is insignificant, IMHO. This is true even if you want to include driver hatch data and double the per-vehicle data (and this is clearly an over-estimate; not all vehicles have TC hatches, nor do they all have both a driver and TC hatch). Perhaps some of the eSim devs can tell me if I've gone off the rails here.:oops:

6 layers but differents from yours (because we can send order of movement (routes), :

- received OBServation orders (position and sectors) (OBS)

- received graphicals missions ORDers (ORD)

- received friendy (automatic)/enemy (reported) positions (AMI ENI)

- received support graphics (artillery and mobility/countermobility) (APP)

- working layer (all graphic you create yourself and you can share) (blank)

- navigation layer (all routes, you create or you received) (NAV)

your definitions are good for SB, though.

This is very interesting, and I'm going to start a dedicated thread to talk about this in more detail when I get the chance.

Edited March 5, 2014 by MDF

[georgerutherford1861]

Was thinking this last night but I would send the loader.:bigsmile:

Good call...but depends on how good my loader is at doing things other than loading and eating MREs!

Doug

[wolfstriked]

Good call...but depends on how good my loader is at doing things other than loading and eating MREs!

Doug

Hmmm didnt think of that.Now that I am I would rather send my gunner.Just now patrolling a town searching for a hidden T90.He is listening to my commands to scan the right side when suddenly I spot the enemy to our left who is now turning the turret our way.Then for some reason he refuses to traverse left as I spam the button.:gun: Argghhhh and this was after like 1/2 hour of hunting.