Volcano

OK, after about 2 hours of investigating, we collectively figured out what the issue is:
 
It seems to be that this scenario was originally created from a save-in-progress file, probably as a way to avoid re-creating everything again, which makes sense but comes with consequences. The consequence s, if an event was true once the scenario was saved-in-progress saved, then it is saved that way in the scenario's start-state. 
 

 
(The image shows the two events in the Mission Editor -- that they are TRUE before even starting the scenario to the Planning or Execution Phase.)
 
Technically this is a feature (because you want save-in-progress scenarios to retain their end-state for join-in-progress sessions), but it is obviously not ideal, because there should be a way to reset those events if the scenario designer wants to. Therefore, we are investigating the possibility of making an enhancement to allow the scenario designer to uncheck the leftmost boxes in the Mission Debugger to effectively "reset" events that were saved as TRUE. If do-able, then of course this would not be available until a future version of SB, but it would mean that this would never be an issue again, since it could be controlled.
 
But in the mean time, I have come up with a work around so that you can salvage the scenario as-is with no negative consequences. 
 
On the BLUE side, in the Mission Editor...
 
Essentially you have to swap (re-make) Event 2 & 4 with Event 49 & 50. Event 2 & 4 are the events that we don't want to be true at the start, but are true because the scenario state was saved that way (the save in progress). Event 49 & 50 are not true at start, but they become true immediately, because they are just messages that play when mission time is > 0 (one of them is delayed another 2 seconds though). By swapping 49 & 50 with 2 & 4, then 2 & 4 are true immediately and this has no impact on the scenario, because the start message will be displayed immediately anyway, since they were going to become true at the start already. Normally we would say to move those two events (2 & 4) to new event slots to work around it, but they are all full - so this is why they would need to be swapped instead. After that, it should work fine - I tested it and it did work (those events no longer happened at start). [You may have done this already] Secondarily, it also wouldn't hurt to try to track down and fix the duplicate IDs. This is likely due to the age of the original scenario, before all that was addressed. There are a few on Blue, but seem to be quite a bit on the Civilians side.

It's not so much about regulation having one ammo door open at one time, its that you physically cannot have both ammo doors open at the same time. When one door opens, it slides over and covers the opening of the other side. 
 
First, you have to prepare the TC's stored ammo, which is only a manually opened door -- its not opened by hydraulic power nor electrical motor.
 
This full process is (from memory)...
 
a. Remove the TC's "curtain" which is a curtain behind him that is in front of that door, which has pockets and pouches, that you use to store "stuff" like maps and manuals. The curtain clips off but then has to be moved out of the way, covering up other things (like the TC's control panel) in the process.
b. Then you have to un-stow a prybar-like handle that is used to manually pry open the TC's ammo door. This handle is attached to the wall, between both ammo doors. It slides and then swivels out, like some kind of crowbar that is attached to the wall.
c. Then you have to pry open the door with this handle, which isn't the easiest thing to do - it can take a minute or so.
d. Then you have to use your fingers to grip a detent on the door, and manually slide the TC's blast-door (which is pretty thick and heavy, maybe ~ 1" thick) over to block the ready side. 
e. Then you have to extract ONE round into the crew compartment from the TC's stored ammo side.
f. Then you have to manually slide the TC's ammo door back shut, all the way shut, so that the ready ammo door can open.
g. Then you have to hydraulically open the ready ammo door (as you normally would).
h. Then you have to store the round that you currently have in the crew compartment, and let the ready door close.
 
...all the while you have to try to avoid chopping off anyone's fingers in the process. Then you repeat the process back at "d" above, for each and EVERY single round.
(There is probably some YouTube video showing the process, maybe.)
 
So why not just pull out more than one round at a time? No. The rounds are bulky, and it is dangerous to be handing more than one round in the turret while everyone is opening and closing doors manually, and so on. Plus, yes, regulations are in place for this part of the process, and for good reason, for the same reason that you do not "lap load". The process wasn't designed to be quick, but then again, that is the trade-off of having the ready AND stowed ammo protected in the ammo bunkers.
 
Rest assured, if the time was wrong it would have been changed in 25 years -- it's realistic. It was timed a long time ago, to be an average crew.

Oh, sorry about that, ignore my previous reply - I was thinking of toggling reticle between HEAT and APDS (R key).
 
OK, in your image - the APDS range is on the right, the HEP range is on the left. APDS is a flatter trajectory, so it will be much compressed. 

OK thanks for those times...
 
@2:05: That is NOT a perfect shot. That is right into the front fuel tanks which provide some serious protection against a round like the BM-29. There are essentially two large fuel tanks to the left and right of the driver in the hull front, imagine them shaped like an "L on either side. The shot goes right into the lower part of that (backwards) "L" shaped fuel tank.
 
See the SBwiki's page about the T-72M that has an image showing the fuel tank area protection.
https://www.steelbeasts.com/sbwiki/index.php?title=T-72M
 
I should take a moment to elaborate that when this happens you likely get a fuel leak on the target, but the tank will not explode from such an impact (it's diesel fuel, and the tanks are put in front for a reason -- the M1 tanks do this as well with the axillary tanks). However if we are talking about ammo much better than the BM-29, such as the M829A3, then the round would plow through the fuel tank and continue onwards destroying whatever is behind it - but again, we are talking about the BM-29 that is already going to be producing marginal penetrations against this type of target.
 
Now of course in reality the level of fuel the tank has would directly affect the level of protection provided, but SB doesn't model that (yet?). This is also one reason why (in real life) tank crews should want any frontal fuel tanks as full of fuel as possible, and why the M1 crews are trained to use the auxiliary frontal tanks LAST. But in SB, currently, the fuel tank provides a static level of protection regardless of the tank's fuel level -- a necessary abstraction at the moment.
 
@1:28: Again, this enters the front fuel tank area, like above, only at an even worse angle.
@3:35: That shot impacts with the suspension area, below anything vital other than suspension - so "light damage" makes sense, and likely was suspension damage.
@4:17: Again, the BM-29 (which already isn't that powerful) is right into the front fuel tank.
@4:31: Again, lower part of the L of the left side fuel tank, and at a significant angle. 
@4:59: Now that is a tricky situation there - the ERA does reduce the penetration of the round (not by much for K1 ERA, though), but the impact is right exactly on the angle where the hull meets into a point. Most importantly though, if you trace the shot's hit ray further -- it does, again, enter the fuel tank area under armor. So in that situation it looks like a impact, but because of all the angles, it isn't. If it was dead on 90 degrees then it may have been a kill. 
@5:18: Again, front fuel tank impact. A good hit in the sense that you hit the target, yes, but not a  good impact location with that particular round (again it is all relative to the round being used).
@5:34: Hard to really tell anything from that image, but through the track, then the compensating idler wheel, then along the side of the hull, and possibly too low to hit anything vital, and most likely also clipping the side of the front fuel tank too. So many possibilities of what it could be there.
 
So, no, nothing in any of those events looks wrong given the round used, the target, and impact area.
 
I would suggest aiming center-mass on the T-72 front hull, into the driver area, and then you will get the reliable results that you are expecting. Otherwise, impacts around center mass, at a variable angle and range, and with that type of round should produce exactly these results. 
 

So looking into it, as I said it hasn't change for 10-15 years (really), but the M2/M3 was always set with a stab quality identical to the BMP-2. This of course seems too low, so we just changed it (for the next update) to be between a BMP-2 and the modern CV9035, given its age and the nature of the stab system.
 
(If someone has real world experience with it and can testify that it was perfect, then of course we can raise it further, but in the mean time it is reasonable to assume that at should be at least 33% better than it is.)
 
Until the next update, you can at least be confident that it hasn't been changed to be worse than before, what more likely is the case is that maps are now bumpier than they were in the past, making it more obvious.

Yes, IIRC this is not new behavior and is a feature. I guess this might be a result of over examination. You can see this same behavior back in 4.363, for example.
 
It is because the M829A3 has a max effective range of 4000m (you can see this in the ammunition dialog where it lists the ammo, with the "range" value).  The AI will not fire beyond the ammo's max effective range, so it is left up to the human to do that (mainly to avoid the AI wasting ammo). Some rounds in SB have a max range of 5000m, but these are the L55 rounds with a bit less dispersion. What is special about the M1A2 with the FLIR is that it spots targets to the map (AI) up to and past 5km, unlike other vehicles, though.
 
 

Yes, what can I say -- it all has to do with the these units that can be equipped with different weapons (an MG team has optional weapons). It's all related to the same problem. It is known, but I added a little more information now to the info from what you provided here, so that is good.   👍

Just FYI:
 
A pretty significant network bug was fixed today that took about a week to track down and eliminate and it was one of the main issues holding things up on a patch release. The bug caused network sessions to get spammed with messages which would cause the network to because overloaded, and eventually crash the HOST. This was caused by the M60A3 (either version), and it came from the fix to Bug 11295 (in the release notes).
 
This is not something specifically reported in the community as far as I know, but is something we discovered (from both of last week's TGIF scenarios).
 
In the mean time, please avoid playing Network Session scenarios with an M60A3 (TTS or otherwise) for now (single player is fine). 
 
We should now be at a point where a patch can be released soon with that wrapped up, but it will probably be next week to be able to do some final checks (and we want to get that T-55 binocular fix in there too).  But let's see if all things go smoothly.  In any case, if you play a network session scenario without the M60A3 until the patch, then it should run fine.

Actually, this should be fixed now. Seems that it was something that was an easy fix, but I looked in the wrong place by mistake. Hopefully it will make it into the coming patch. Let's see.

This has been fixed now. It might make it into the next patch, we'll see (depending on the timing).

Thanks, yeah it is a known issue at the moment that helicopters will crash into each other, especially in a formation. At the moment they have been made to be immune to such crashes (so they just push each other around).  It isn't a great solution, and looks ugly when it happens, but keeps them from dropping like flies.  I think in general helicopters are not aware of other "vehicles" for collisions. At some point we will do that, and then (after that works) make them die from such collisions.

Thanks, this should be fixed now.
(As to whether it will make it into the coming patch, I am not sure -depending on when the EXE is built and all).

So just to follow this up (I was unable to revisit this before now)...
 
Actually the check box will remain in Pro PE.
 
It seems the issue is actually that the wording of the checkbox is wrong and totally confusing. When that check box is ON, what it does is, it makes it where the driver must select D, N, R "gear" (forward, stop or reverse). The actual gearing (1st, 2nd, 3rd) is shifted automatically regardless, so its really about drive selection, not so much "automatic transmission" per se. Additionally, when checked on, it splits the throttle from one single axis (+ being forward, - being reverse, 0 being stop) to two separate axis, like a gas pedal and a brake pedal. 
 
We can see this if someone presses "Configure Axes" (plural) before and after that check box is selected. When its selected there is a new "Brake" axis present. By default, the brake is probably being fully applied, so when driving around its as if the brake pedal is pressed to the floor at the same time (the solution there would be to remap it to a brake pedal peripheral or some other axis).
 
But certainly the label on that check box must get renamed, and that has been done already to hopefully make it more obvious as to what it does. It seems that it has been like that for several versions now but no one ever tried it out before (apart from the military), so thanks for that. 😎

Looks like we will try to further improve the behavior by having the sound "fall off" in volume more, depending on the size of the KE impact in the next patch. With that in mind, I might change the volume back to where it was before. We'll see. 🤔

This has now been fixed/improved for the patch.
The intent is to have it vary *slightly* in brightness based on temperature settings in the scenario (not but a huge amount but enough to perhaps notice a difference in the horizon "fogging" region - rather than just being the same all the time), but yes, overall we were far too bright with what we had before. This seems to have been caused by a slight misunderstanding at the time improvements were (recently) implemented.
 
Thanks!

Well, this is certainly something that was internally brought up as a bug a long time ago (I believe I reported it, actually). If you notice though, this is (or should be) exactly the same back in 4.363. A new update doesn't always mean that things are broken, but I guess the natural tendency is to check everything again (which is fine, as long as we all understand that not every observation is something new and all parties should be patient and level headed when it comes to feedback).
 
Now as to what happened when we looked into it as a "bug", well, it has something to do with FOV and monitor size limitations, to the degree that it feels like you are looking into a keyhole when you have the correct zoom with the correct FOV. The same is true for the Shot Kal gun sight which has a very peculiar zoom and FOV, requiring that it be much smaller in comparison to other sights. For these two sights in particular they apparently do not have the typical field of view / magnification ratio (I am not an optics technical expert to explain it well).  Now we can think (like I did) - 'just make it bigger in the view', but apparently that is not how it fundamentally works within the engine. 
 
Still, we want to improve this behavior for these odd sights, but just aren't quite sure what to do about it at the moment. I guess that is the long version of saying that it is a known issue but with no easy solution at the moment. 😑
 
 

OK thanks. I can certainly see that it working this way might be better if someone deletes it by mistake (because they could restore the file), but I guess we should at least check if that is intention behavior or not.

This has been fixed for the coming patch.
 
It turns out that this issue affects the Centauro, Challenger 2, CV9040s, Leopard 1s, Leopard 2s, M1s, and M2/M3 and was something that got broken with the new "laser reticles". 😣

This should be fixed now for a patch.
 
(In case anyone wonders how these things happen, it had to do with a process called refactoring to make things more efficient and, well, things are sometimes interconnected). 

Actually, I figured it out.
 
Looking at the image, and measuring myself in that test scenario, the distance is about 210m. 
 
This is actually a feature - the distance a vehicle is allowed to pick up troops from a waypoint is 200m, so its just barely on the edge of this threshold.  The solution (here) would be to move waypoint 201 forward to the top of the hill, or move it backwards about 50 to 100m on the back side of the hill. I know this is probably annoying, and we can increase this distance to 250m, but there has to be some kind of limit, and the distance cannot be so far way that an AI unit moves far out of the way to pick up troops (so the idea being, if they are so out of position then the AI will just leave them there instead).
 
I will spare all the other rationale behind it, but it is intentional behavior, it's just that the waypoint's location and enemy presence put the vehicles just barely out of range of that radius to go back and pick up the troops, and so they leave them behind. Still, I'd say its probably safe (in and update) if we increase this radius to 250m to catch this case though, so I will suggest that change. In the mean time, knowing that, you can hopefully easily adjust the situation easily to work around it.

Yes, also at the map view you can turn off test mode from a selection in that menu. This removes all the special abilities (like being able to toggle between sides, and instant artillery, moving graphics around, etc).

Thanks for reporting.
 
Originally it was suspected to be some kind of issue with armor (because this is the most obvious explanation), but after seeing that it is pretty straight forward and relatively simple, further investigations were made. So, after digging further, it seems that because this vehicle was based on the T-72 family, a mistake was made that caused it to (logically) have a Gunner included, when there shouldn't be one. So the issue was that with the crew killed, the vehicle wouldn't ever actually die because the gunner could never be damaged (because he is not physically present).
 
Anyway, that should now be fixed in the next update.
 
(You can tell the BREM-1 erroneously has a gunner present by being in the Mission Editor, right clicking on the vehicle, and going to the damage menu and observing that "Gunner" appears in that list, along with all sorts of other components that the vehicle shouldn't have, which have also been fixed now too).

This thread is a summarized list of how to get your MAP to work in 4.1 (essentially, how to turn your legacy pre-4.1 map into a Map Package). Lots of text here but I am trying to be as thorough as possible in the process, concepts, and possible cases.
 
To see how to update your scenario to 4.1, then see this thread instead:
 
So, to update your map into 4.1, several key concepts that have to be learned:
 
Terrain: Just as in SB 1.0 to 4.0, "terrain" or "TER" is referring to the terrain features applied to a map, such as buildings, roads, ground types, water, bushes, rocks and trees.
 
Height: Just as in SB 1.0 to 4.0 "height" or "HGT" refers to height data only, the ground geometry, the underlying ground.
 
Map Package: A Map package is the name for a 4.1 map, which can either be a Base Map Package (aka. "Base map") or a Delta Map Package (aka. "Delta map"), both of which can either be published or not. 
 
Base Map: A base map (package) contains height data (LNT file), as well as a metadata and TER file, but may also include custom actors and textures as well. The base map is a stand alone map, containing both the height and terrain data, and that base map is generally pretty large in filesize (depends on the map size and resolution of the height data, but typical 10m resolution on a 50x50km map will be about 250-300 Mb in size) . A base map can either have actual terrain or just be an empty terrain map, which is the case for "autocreated base" maps (more on this later).
 
Delta Map: A delta map (package) consists of terrain (TER file) and metadata, and will sometimes also include height data if the delta map has terrain that differs from the base map, which would most often be because someone leveled roads, or adjusted the height data in some way. If height data is not changed, then a delta map will be very small in size, typically about 2 (for a desert map) to 35 Mb (for a dense European map), depending on the complexity of the terrain and size of the map.   Think of a delta map as a CHILD of the base map and all the delta maps share their parent base map's height data. Because of this, the Delta map is NOT stand alone, as it doesn't have complete height data (or any height data at all in most cases).  Therefore, the base map is relatively large, and can be difficult to share, while the delta map is smaller, easier to share, and more convenient if everyone has the base map already. In general, you want to always create a map as a delta to an existing base map, if possible, as this makes maps easier to share since sharing smaller delta maps to a base map that everyone may already have.
 
Published: When a map is published, it is ready for sharing and for playing with others.  Think of publishing a book: its ready for consumption -- you cannot recall the book back to the printing press to change a typo at that point, but you can put out a new edition. Similarly, once a map is published it cannot be changed, its basically read only at that point. The good news is that you can easily turn the published map into a new delta map, which is then unpublished, allowing you to continue working and improving it (more on this later), which is like making a new edition of the published book, in the example.  There are technical reasons on why the map has to be published, but the basic reason is that publishing the map (combined with its Unique ID) ensures that everyone has the same exact map data, and there is never a case of someone having different map data in a session.
 
Unpublished: When a map is unpublished it is free to work on and save as normal, and you can TEST scenarios on the map (via the Mission Editor), but you cannot play a scenario that is on an unpublished map in Offline or Network Session mode, because this ensures that someone doesn't have different map data when playing a scenario together (which would mean that would be in two different worlds).
 
Autocreated base: Generally speaking, an autocreated base map is simply a blank base map that only contains height data, but no terrain data ( the entire map appears as green grass).  An autocreated base is simply there to provide height data to its children delta maps. If you are picking a map to use in a scenario (either a new one, or in order to replace the map) then you should never choose a map that has [autocreated base] on the end of it, because its empty (and actually the autocreated base maps are filtered out of the Replace Map list by default to help you avoid this!).
 
Unique ID (UID): A unique ID is a series of characters and numbers, generated from the map's data, which is unique to each map. Think of it as the map's serial number.  The UID is used to make sure that the user has the correct map that the scenario needs. Once a scenario is saved in 4.1, then it associated it with a map's UID. At that point they are paired. If the map with that UID is ever deleted, then the scenario will not open, but the map can be replaced to a different one (say for example because you made a newer version of the map).
An example map UID:    636b3bb9-3822-4bab-8f3d-12170b499e6f
 
-----------------------------------------
 
Converting your (TER) map into a 4.1 map package:
 
In order to convert you legacy pre-4.1 terrain (TER) map into a 4.1 map package, you just need to do a few simple steps - but there are several cases depending on whether or not you already have a base map present for the map you are converting or not.
 
To convert you map follow these basic steps (which might become a lot of text, but I am trying to be as clear as descriptive as possible here):
 
1. Go to the Map Editor. In the pop up "Map Packages" dialog, select the button at the bottom "Open default map".
 
2. When the default (blank) map loads, in the top menu go to: File -> "Map package from TER..."
 
Notice that the file menu also has a "Map package from HGT..." selection available too. This is covered below. "Map package from TER..". is the most common, and 99% of the time this what you want.  
3. Once "Map package from TER..." is selected, then a pop up Open dialog appears, where you will navigate to where the pre-4.1 legacy .TER file is located. Select the TER file and press Open (or just double left click on the file).
 
This is TER path is going to be in the traditional legacy map path ([Windows 7] ...\ProgramData\eSim Games\Steel Beasts\maps\terrain [or your OS equivalent path, if different])  
...at this point the remaining process depends on two possible cases: whether a base map already exists for the map you are converting, or whether it doesn't...
 
CASE 1: Base map is present locally
 
4. If the map you are converting a TER whose height data matches a base map that you already have locally, then good news!, all you need to do is create a delta map. You will know that the height data is already present in a base map when you get the "Map Package Creation Wizard" pop up dialog that says that "It is possible to create a 'delta' map package..." (see image).


 
Select either the "Delta package" (default) or "Base package" (which is not recommended unless you plan on doing something special like making unique road sign textures, and such), then select the map package in the list (there should usually be just one there), and then click Next.  
5. Next you are taken to the 2nd "Map Package Creation Wizard" dialog that allows you to enter all sorts of various optional data about the map (see image). When you are finished, click Next.
 
***IMPORTANT: The "Name" will become the folder name and as such you cannot have control characters in the name like # ! @ % $ etc. If you do, then the "Next" button will be grayed out. Once you enter a valid name then you will be able to click "Next".***
 

 
Don't worry, you can edit this data later once you load the map (in the top Options -> "Map info..." but once you publish it you cannot edit it again (unless you make a new delta map from it - see bottom). Keep in mind that the initial name you give the map in this dialog will also be the delta map package folder name. In this dialog, if the lat/long values are not grayed out, then it means your map is so old that it has no geodata present. In this case you should research on where you map is located in the world, and enter correct lat/long values here. If the lat/long values are gray, then you are fine.  
6. After brief moment you taken to the final Map Package Creation Wizard dialog, telling you whether the operation was successful or not. (see image).
 

 
You can now either close the dialog or load the map you just converted in the Map Editor (lets continue with the example as if you loaded the map).
 
7. Now you are in the Map Editor, with your newly converted delta map package. Here you can either edit the map and save it, and open it later for further editing, and/or publish the map so that it can be used in scenarios (and so you can use it to replace the map in some scenarios you are converting to 4.1).  Let's continue the example that you are going to publish it to use in a scenario.
 
It is recommended that you publish the map you converted relatively immediately, if you want to use it in a scenario, then you can always create a new work-in-progress unpublished delta map later that you will continuously edit until you again want to share it or use it in a scenario, and repeat.  
8. (Optional) You now want to publish the delta map to share with others or to use in a scenario. Go to the top menu and select File -> Publish map, then select "Yes" in the pop up dialog. COMPLETE.
 
You can easily tell if the map is published by how the upper right side of the screen's terrain types appear. If they are all grayed out (they are inactive and cannot be selected or edited), then the map is published. If they are not grayed out then the map is unpublished (see image).  

 
 
CASE 2: Base map is NOT present locally
 
4. If the map you are converting a TER whose height data does NOT match a base map that is present locally, then the process is nearly identical to CASE 2, except that you must create a base map package (obviously). You will know that the height data is NOT present in a base map when you get the "Map Package Creation Wizard" pop up dialog that goes straight to the map info (see image).
 

 
The difference here from the dialog in CASE 1, Step 5 is in the center of the dialog you will see "Automatically create an empty and published base map package" which is selected by default. This "Automatically create an empty and published base map package" option will create an autocreated base map and publish it, and then will convert your map into a delta map package of that autocreated base. This option is recommended for ease of use, but you can turn it off and create it as a base map package with your terrain as the base map's terrain.  
The remainder of the process is now identical to CASE 1, Step 6 and 7 (you just have to load the map and choose whether to publish it or not). See above. The exception is that the conversion process will be much longer in this case as it converts the height data into LNT format.
 
Converting your (HGT) map into a 4.1 map package (not normal):
 
Another option is that you can convert a map from an HGT instead of TER, but this is not normal. The reason you would convert a map from HGT file is because you only have height data, and there is no terrain data in existence. This might be becaue the map is entirely new, for example. In any case, you would really only do this if you plan on only having an empty base map package, and then you will start immediately painting terrain on it to make a new map.
 
To convert you map from HGT, its essentially the same exact process as converting from a TER (above) except...
 
1. Go to the Map Editor. In the pop up "Map Packages" dialog, select the button at the bottom "Open default map".
 
2. When the default (blank) map loads, in the top menu go to: File -> "Map package from HGT..."
 
3. Once "Map package from HGT..." is selected, then a pop up Open dialog appears, where you will navigate to where the pre-4.1 legacy .HGT file is located. Select the HGT file and press Open (or just double left click on the file).
 
This is HGT path is going to be in the traditional legacy map path ([Windows 7] ...\ProgramData\eSim Games\Steel Beasts\maps\height [or your OS equivalent path, if different])  
4. Next you are taken to the "Map Package Creation Wizard" dialog that allows you to enter all sorts of various optional data about the map. When you are finished click Next.
 
Don't worry, you can edit this data later once you load the map (in the top Options -> "Map info..." but once you publish it you cannot edit it again. Keep in mind that the initial name you give the map in this dialog will also be the delta map package folder name. In this dialog, if the lat/long values are not grayed out, then it means your map is so old that it has no geodata present. In this case you should research on where you map is located in the world, and enter correct lat/long values here. If the lat/long values are gray, then you are fine.  
5. After some time (and a Please wait... loading dialog) you taken to the final Map Package Creation Wizard dialog, telling you whether the operation was successful or not.
 
You can now either close the dialog or load the map you just converted in the Map Editor (lets continue with the example as if you loaded the map).
 
7. Now you are in the Map Editor, with your newly converted base map package. In this situation it makes no sense to publish it, so you would immediately start working on your terrain data, only publishing it when it is ready to share.
 
Converting a published delta map into a new (unpublished) delta map:
 
As described above, one you publish a map then it is finalized and cannot be edited in its current form and you would do this to share with others and to play scenarios on it (other than testing in Mission Editor). However, if you want to be able to make further changes and improvements to the map then you would save the map as a new delta by following these steps:
 
1. Open the published map in the Map Editor.
 
2. Go to the top menu File -> Save map package -> Save as new delta package...
 
3. You are now in the "Create new delta map package" dialog where you can enter in information (and also change the lat/long data if you desire -- you shouldn't unless you know what you are doing here!).  Once you are finished press OK.
 
4. That's it, now you have your new delta map which is unpublished by default, which is essentially clone of the map you made it from. You are now able to edit the map further (just don't forget to publish it when you are ready to share it).
 
TIP: A tip we learned in testing is to have a published map, even if it is not finished, and then have a "work-in-progress" unpublished delta. Further work would be done until it was deemed as a significant improvement, which was then published, and this is repeated. During the process, the maps were usually named with a letter on the end, example: Brush War 01a,b,c,d,e,f.... current version is something like h (which is the current unpublished work in progress). Eventually you can delete all the older version of the map on your end, and if you open a scenario that (for example) looks for a missing "Brush War 01a" then you replace it with the latest published "Brush War 01g", because you know its in all ways better than "a".
 
Sharing map packages with others (manually):
 
As described above, at some point the Map Download Manager tool (and SB) will handle most of the work, but in the mean time if you want to share the map then you would do so by ZIP / RAR / 7z (I will call it ZIP here) the appropriate map folder and uploading to Dropbox or some other file sharing (or temporarily to the Teamspeak channel - please delete it afterwards!).  Make sure the map you are sharing is published, otherwise you are wasting everyone's time (unless you are sharing it to work on an unpublished map of course)!
 
To share a base map (because the person you are sharing it with doesn't have the base map), then go here:
 
C:\ProgramData\eSim Games\Steel Beasts\maps\packages   [or your OS/installation equivalent]
 
...and find the folder of the map package you are sharing and ZIP it. Upload somewhere and share the link. The other user(s) download it and extract it to their ...maps\packages folder and you are all set. If they are in SB when they do this then they may have to restart SB for it to recognize the map (or press the "Refresh maps" button in the Map Editor initial pop up dialog.
 
To share a delta map (because the person you are sharing it with DOES have the base map), then go here:
 
C:\ProgramData\eSim Games\Steel Beasts\maps\packages   [or your OS/installation equivalent]
 
...and find your base map folder that the delta map belongs to. You can find this information out in the Map Editor by loading the delta map and using the Map info... feature. Once you go to base map folder you will find a "deltas" folder and open it. In the deltas folder, you will see folders for each of the delta maps. ZIP the appropriate delta folder and then upload it. The other user(s) then just need to extract that ZIP to their same ...\maps\packages\[basemap_name]\deltas folder and they are all set. If they are in SB when they do this then they may have to restart SB for it to recognize the map (or press the "Refresh maps" button in the Map Editor initial pop up dialog.
 
Adding custom map textures:
 
A new feature in 4.1 is the ability to add custom map textures to base map package, for example if you want to make custom road sign textures that are specific to your map.  Some important things that you must know:
 
Custom map textures are supported at the base map level. You cannot have custom map textures on delta maps. If you are going to have custom map textures, then its best to make it a new base map package entirely. For example, the Bekibekibekistan map has its own custom textures, but the underlying HGT data is for 29 Palms training area. Technically, it could have be the 29 Palms base map package with Bekibekibekistan as the delta of it, but it would make no sense to do this because then all the road signs on the other 29 Palms delta maps (like of the actual training area) would have the custom Bekibekibekistan road sign textures.  
To add custom textures to your base map package, simple navigate to your base map package folder and add an "actors" folder. Inside of that folder add a "textures" folder. Then inside of that, add a "woodland" folder and from there you can drop in any map object related folder that you want to customer (which can be things like buildings and road signs, and things of that nature).
 
See the Bekibekibekistan map package as the example.
 
--------------------------------------------------------------------------------------------------------------------------
 
Special cases:
If you select to convert a map from TER or HGT and get a pop up error about a file missing, then it means that the pre-4.1 legacy map is missing its associated TER or HGT file (which wouldn't work in 4.0 either). If you are in the "Map Package Creation Wizard" dialog and you cannot press Next, then it means that some abnormal issue exists with the legacy TER or HGT file (which will have need to be troubleshooted).  

No doubt this information is elsewhere, but just wanted to post it as summarized as possible, and to allow for the possibility that someone will not read something somewhere.
 
If you want to convert your map to a 4.1 map package then go here instead:
 
Also, this post is intended to be temporary, as a sort of FAQ, until everything is understood and up and running smoothly and there is a SBwiki page. It might seem like a lot of text, but I am trying to cover all the possible cases...
 
So you have a personal favorite scenario, or one of your own, and you want it to work with 4.1. What do you do?
 
1. Open the Mission Editor
2. Once the default (blank) map loads, go to File -> Open
3. Choose your pre-4.1 legacy scenario you want to open.
 
     CASE 1: In some cases the scenario will open automatically, if SB matches the "backing map" with map package of the same exact name on your hard drive (which is rare). In this case, the scenario opens and you just save it, and now it is updated to 4.1 and using a map package. Done!
 
     CASE 2: However, in most cases the scenario will not load, and a pop up dialog will say...
          "Could not find the map this (legacy) scenario is based on!"
          ...etc...
     In this case, you click "Replace map" button, and choose the closest map you have that matched the old map, using the name of the TER and HGT as reference. If you made the scenario then it should be relatively obvious what replacement map to use. If not, then you could ask around and someone might be able to identify it.
 
     CASE 3: If scenario uses a map that you know was heavily edited from some other map, because you customized it for the scenario, for example, then you should choose to cancel and create a delta map package of the updated map instead:
 
4a. Open the Map Editor, select "Open default map" button at the bottom.
4b. After the default (blank) map loads, go to File -> Map package from TER...
4c. Select your TER file of the edited map (if you don't have it in TER form, then shame - you need to open the scenario in 4.023 and extract the map as a TER first!!!).
4d. Once you select the TER file, most likely there will be a base map already in existence and it will ask you if you want to make a new base package, or a delta package ***you should almost always choose to make a DELTA package of an existing base package, because its the difference of hundreds of Mb or more in filesize!***. You would choose to make it a BASE package if you want your map to have unique textures (like for road and info signs, or buildings, etc), and so forth.
4e. After a minute or less, a new DELTA map package will be created of whatever you named it. Then go back to Step #1 above and go through the process, and in Step #3 you will select the delta map package you just created. Done.
 
     CASE 4: And in the case where you have installed all the map packages from the map package installer, and the map you want to convert isn't recognized as an existing base map package (so it doesn't ask you to create a delta), then you need to create a new BASE map package of your map, then go back to Step #1 above and go through the process, and in Step #3 you will select the delta map package you just created. Scenario is now updated to 4.1. Done.
 
---------------------
 
NOTES:
 
Once you update your scenario to 4.1, you might want to save it as a new filename. It is certainly possible to keep 4.023 around to open old files and to extract TER files from them, and so forth. Once you save the scenario in 4.1, that is no longer possible. Also, once you update to 4.1, the scenario is now associated with a Map Package that has a unique ID (UID). If that map no longer exists on your hard drive, then you cannot load the scenario - but no problem - you just replace the map again to another Map Package (pretty much same process mentioned above). When converting delta maps from TER files that were extracted from a scenario (ie. the map is mostly empty except for the scenario's play area), then suggestion is that you prefix the delta map name with "sce_" to let everyone know that it is an incomplete map cut from a scenario. This is what we have tried to do in the standard install delta package names. You should always look for more information about this process in the release notes and the SB wiki. This post is intended only to provide more information.  
Hopefully that helps. The good news is that a scenario only has to be updated to 4.1 once.

In the event that you suffer a crash to desktop (CTD), please paste the following your Windows Explorer address bar:
 
%userprofile%\AppData\Local\CrashDumps
 
...then ZIP/RAR the most recent "SBProPE64cm..." .DMP file.
 
Next, attach it to an email and send it to ssnake {at} esimgames [dot] com (do not attach it here to a post in the forum), with a brief description of what you were doing when it happened and the version number.  This will help us locate the problem.
 
Example:

"In 4.157 I was in the Mission Editor, and I went to 3D world view via right clicking the map and selecting "View"".