Volcano

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"".
 
 
 
 

Just FYI,
 
So it seems there is still some strange behavior here in Network Session. For the past weeks we have been looking into this, and have fixed (hopefully) all remaining issues recently, for the next patch (post 4.363).
 
In the mean time, it was expressed that a way to work around this problem is ...
 
In Network Session, if you observe the T-72B3 FCS doing some "crazy" (like acting jittery, or as if there is some kind of conflict going on) then in the gunners position change the FCS into "emergency" [. key] and then back to "normal" [, key] and then the issue *should* resolve itself. If you jump out of the tank and back in, you might have to do it again.
 
It seems that the HOST and CLIENT were getting out of sync with an FCS setting, and doing this toggle between normal/emergency forces a message to be sent across the network. 

Right, this is a known issue all the way back to SB1 (that you can remain in the vehicle with no turret crew until you jump away, then you are locked out). It would certainly make more sense to eject the user to F8 view when the occupied crew position is damaged, but there are technical reasons (I believe it is another problem that goes back to the 'no external view setting' that can be set in single player, rhetorically where does the user get thrown to when dead in such cases?).
 
Need a sort of purgatory for the dead, where they are at map view but not in any vehicle until they select a unit to jump to, I suppose. 

Well, just because you saved an older scenario in newer versions doesn't mean the duplicate IDs would go away. It sounds like they are originally older scenarios, and the duplicate IDs were broken at that time, and its no surprised that they would still exist. They have to be manually fixed there.  Not saying that is what the issue is, but if it is, then it is expected behavior. 
 
These are would be fixed by either removing the troops and replacing them, or by renaming the parent unit (with the troops inside) to some other name, then back again to their original name, or by renaming the troop units. 
 
Also, it's important:
 
There is something that I remember that is tricky about the duplicate ID test. IIRC, when you load the scenario in the Mission Editor, it doesn't automatically check the duplicate IDs except I think for the first party. You have to actually swap to the other sides in the drop down bar in that dialog and press the "Check for duplicate IDs" button.  Otherwise, once the mission begins in EXE Phase, then I think it checks all sides automatically when you open the dialog (that might be what you are observing here, or not).
 
(However, if this is not what you are seeing, then I will need to take a look at the scenario.)

Sorry but we cannot do much with that vehicle - it is very old. If you recall, the truck was made over 10 years ago and the only update it ever got was better looking wheels.  There are no meshes that we can remove (it doesn't even have doors that open), so the best we can do is flatten the tires (where is that Pawn Stars meme when you need it). We cannot remove the tarp either, because there is nothing physically in the back.   Also, none of this is different than it ever was before. 
 
The important question is: does the vehicle die or become severely disabled on impact of large HE and HEAT? If it does, then that is good, if not then provide a test scenario here so I can address it (that would be bad of course).
 
That said, we are being very conservative when it comes to removing meshes (aka. "destroyed meshes"), and this is because we never want a case that a non-superficial mesh is removed (like say the entire rear cargo area of the Ural) but the truck is somehow still alive. But what it really comes down to here is age of the model. If the model is very old, then usually any mesh that is removed will cause invisible see-through polygons underneath, or other ugliness, or it won't have specifically separate meshes at all, which prevents things from being removed.
 
As for fire, well, this again is no different than it ever was before. It has a diesel engine so a general rule is that we don't have fire damage because, broadly speaking, the diesel engine is supposed to be quite safe from fire in the sense that we don't want it as a probability that kill the vehicle from the fuel tank being hit. Usually a fire on such vehicles would happen after the vehicle is dead, but not be something that would be so volatile that it would kill the vehicle in itself first, if that makes any sense. Now we want to see fire, because there are visual effects associated with it in 4.3+, so what we will likely need is some kind of post-kill fire probably (of say, a fire that starts following the vehicle's death).
 
But this all really points back to old behavior, or old models, and yes, I am 100% sure there are other old vehicles that behaves similarly -- let's just say I am intimately familiar with them all. 😐

Yes, so the issue here is that the Ural truck is very old, and never had its default LMG and RPG type defined (for its carried troops). So, it falls back to something defined in the code, ages ago, which is likely the very first RPG type that existed (M136) and very first LMG type that existed (MG3).
 
I will try to script that to the PKM and RPG-7, or some such, for a future patch.