Steel Beasts Dynamic Terrain Will Come After New Terrain Engine

[Asid]

We all know how this will go.....

[Rinix]

https://www.steelbeasts.com/topic/12433-any-new-crewable-content-since-2016/?tab=comments#comment-185803
Ssnake responds to a topic about future crewable vehicles to say that the next major version of Steel Beasts will have "some new stuff". This implies that we will get new crewable vehicles in the next major version of Steel Beasts.

[Rinix]

https://www.steelbeasts.com/topic/12478-has-steel-beasts-died/
https://www.steelbeasts.com/topic/10258-mouse-pointer-missing-in-4k-uhd-resolution/?tab=comments#comment-186447
Malakie is annoyed over the lack of a fix for the disappearing cursor at 4K resolution bug and the lack of updates. Ssnake responds to both posts, and covers the same ground in both of them, here's the longer post:

The problem is actually quite hard to fix. We know what needs to be done, and we're taking considerable effort towards that goal. But it is a massive undertaking even if it may appear as a mere triviality. I don't want to go too much into technical details, but it's one of those problems where we know what needs to be done, it just takes a lot of time and effort to actually do it.
If Steel Beasts were to be developed from scratch right now, it would be easy to address. You would approach the whole question of a user interface in an entirely different way. 25 years ago we were young and naive and never expected to be working on this for any longer than maybe five years. But as it turned out SB Pro is of a much bigger scope than initially expected, and that means we need to remove a lot of old code that is blocking the path towards a modern graphical user interface. But that old code is there for a reason. You can't just delete it. It needs rewriting. And you want to rewrite it in a way that introduces fewer bugs than it replaces.

I can but ask for patience here. Also, we're working on other things, but these are not really distractions that prevent us from modernizing the GUI, they run in parallel. All of which must create the tarther terrible impression that we're not doing anything about it at all. I can assure you, this is not the case.
Maybe I can illustrate it like this: If you want to build a new house, you need to secure the bank loan, purchase land, appoint an architect, choose a contractor to build it (or assemble all the raw materials if you want to do it yourself), and while you're very busy preparing all this, seemingly nothing happens at the construction site. All the work is happening elsewhere.

[Rinix]

Well, there are less than six weeks to go until the end of Q1 2019. Considering that Ssnake has said that "The full feature disclosure will usually begin six to eight weeks prior to the anticipated release date" we can conclude that the next major release of Steel Beasts has been delayed yet again.

[Rinix]

https://forum.steelbeasts.org/forum/thread/8578-vorstellung-vom-hacket%C3%A4uer/?postID=59073#post59073
Translated using Google Translate:

To 4.1 (or which version number we use then), I'll say something in due course (small note at this point: the frame rates are better compared to 4.0). I referred to 4.0 because we tested it systematically in 2016.

[Rinix]

https://www.steelbeasts.com/topic/12559-release-roadmap-for-pe-41/?tab=comments#comment-187810
So we are looking at a delay of 1 to 3 months.

We hope to close the beta test in Q1, so, since the second quarter technically starts with April 1st, the release won't happen before that. But we may be forced to delay it until June for the following reasons:

• ITEC exhibition in May; this requires preparation time, then most of the team is away for a week, and there's stuff to do immediately after the show. Therefore, if we can't push it out in early April, it'll have to wait until June.
• Manual preparation; we want to make a new print run for the manual, but of course as long as there are changes made to the user interface we also have to update the manual. Once that the time for last minute changes of the content is over it's time to send it to the printer. But how many? I'm thinking of setting up our web shop to accept preorders for it.
• Terrain data; this one is a big issue. We want to ship the next version with as many legacy maps converted to the new format as possible. We know that converted legacy maps are a bit larger than the original maps, but HOW MUCH larger is somewhat difficult to predict since it depends a lot on the amount of changes that would be made in the conversion process, and how they affect the data compression ratio (uncompressed maps are unacceptably large).

Now, the total size of all the maps is unknown. But a number of questions hinge on them. First of all, we have decided to split the Steel Beasts installer from the map data installation, so that if we push future updates for Steel Beasts you don't have to download the maps again and again. Next, we're preparing a map server to replace the current forum's map download area. Who knows, maybe one day we extend that to scenarios, and or game sessions. The point is, if you want to open a scenario for which you don't have the map, Steel Beasts will recognize that and then connect to a map server and query the map from that location, then add the map to a download queue that will run automatically in the background. Which is all very nifty, but not everybody is on a broadband internet connection, and if many people are requesting a lot of map data at the same time the servers may be unable to serve in a timely fashion.
So, some people may prefer to have the map installer delivered on physical media. But the choice of medium depends a lot on the total size of the installer, so this is at the moment the biggest unknown. Do we put everything on two DVDs? Do we need five? Ten? Should we rather ship a USB stick, or an SD card? How many will we need? (So, I'm thinking of setting up our web shop to take preorders.)

But before I can update the web shop, I also want to offer bundles with Steel Beasts installer (DVD? or is there enough space left on that USB stick?), map installer, and the printed manual ... plus upgrade license, or new license, or an upgrade option for people that never updated past version 2.6. That's a lot of combinations, maybe fewer is better. But in any case, I can offer such bundles only once that I know what needs to be produced, and that largely hinges on the map installer.

As soon as I have answers to all of this I'll start making announcements.

[Rinix]

https://www.steelbeasts.com/topic/12560-roadmap/?tab=comments#comment-187819

I would really like to wait posting stuff until things are ready. As long as there are changes being made to the lighting - just recently there was a rather drastic improvement to the tree shader code - well, let's just say that screenshots take a life on their own on the internet as they get passed around without context.

[Rinix]

https://forum.steelbeasts.org/forum/thread/8610-gel%C3%A4ndedaten-in-version-4-1/
All of these posts are translated using Google Translate:

Let me quote from our new manual. In the further course of the (hopefully resulting) discussion, I will go into the implications of these changes:

Hmmmmm ... then without quote tag:


Basic concepts

Steel Beasts creates the virtual 3D environment based on map data stored in so-called terrain packages as of version 4.1. A site package contains all the data needed to create a map and is stored in a single directory that can be easily copied using Windows Explorer or shared over the Internet or on USB sticks. More information about storing site packages can be found in Chapter 2, Installation and Setup.
There are two types of terrain packages: base packages and delta packages. Delta packages always belong to a specific base package and contain only the changes to the base package. Thus, minor changes for a scenario can be made quite easily, without changing the (usually extensive) base map itself. The number of delta packets to a base packet is not limited. Delta packets are stored in subdirectories of the respective base packets.

Note: There are no delta packages of delta packages. Such a construct would result in an undesirable cascade of changes to previous changes. Changes to delta packages are always saved as new delta packages (or, if the creator so wishes, as a new base package).

Steel Beasts uses two different categories of terrain packages: Completed maps and maps in progress. Surprisingly, only cards in progress can still be modified (which, among other things, means that they are stored uncompressed for faster read and write access, so they often require a lot of hard disk space.) Once the terrain developer has finished working on his Card, he should convert it with the option Finish processing in the file menu. This saves this card in a read-only and compressed state. Further changes to the card will be saved as a delta package in the future. Only completed cards can serve as the basis for an exercise. In the Scenario Editor, however, maps in progress can be used for testing purposes (so that the site editor can assess his work.)

Older versions of Steel Beasts (up to 4.0) use a different file format: There are elevation profile maps that contain information about ground level, and terrain maps that show the properties of the terrain such as soil type, vegetation, locations of buildings, roads, and other stationary objects. The combination of a height map and a terrain map file gives the complete description of the virtual battlefield. These map data from old scenarios can be converted to new terrain maps in version 4.1 using Create Terrain Package (Wizard). This wizard is described in more detail later in this chapter.

High-quality maps are important for a clean running simulation of high simulation quality, which meets with the acceptance of the users. If possible, always use cards of good, proven quality. In some cases, changes to existing maps may be needed to improve a scenario or to help achieve an educational goal. Steel Beasts lets you edit maps in the Terrain Editor.


Create terrain package (assistant)

There are two ways to create new terrain packs using the Terrain Editor: On the one hand, it is possible to create a new map from scratch (to which elevation and terrain data must then be added), or the map can be edited manually or elevation and terrain data in certain exchange formats.) It is also possible to convert a map of an old version of Steel Beasts. It is even possible to create a terrain package from a map embedded in a scenario. More details can be found in chapter 7, CREATING A SCENARIO.

Both approaches use the wizard to create a terrain package. In this wizard, the user must enter the card name, its creator and a copyright notice. It also includes a larger text box for a brief description. A simulation date can be specified below the description (This feature is currently not in use, but may later be used to advise scenario developers using the map about appropriate troop organization and camouflage schemes give.)

The lower half of the window contains information about the map's coordinates, their size, projection, UTM zone, and terrain type used. When converting existing maps, some of this information may not change because they depend on existing data (for example, you can not change the size of a map when you convert an old map).

Among these options, Steel Beasts shows how big the file would be if it were saved as a map in progress (either low or high resolution), and how much space is left on the computer.

Attention: If the Next button is greyed out, the card name probably contains invalid characters (in card names only alphanumeric characters and a few special characters are allowed) .-.
Convert maps of old versions
Older versions of Steel Beasts (up to 4.0) store maps in various files and formats: height information is in files with the extension .hgt / .raw, whereas terrain data is in .ter files. The former contain data about the terrain profile, while the latter (which always refer to a specific height file) contain information about buildings, terrain types and similar things. All this is further complicated by the fact that terrain data is always embedded, elevation data, on the other hand, only on request in a scenario file (before version 4.1). This requires several variations on how terrain data must be extracted from maps of old versions or converted to create a terrain package.

· Conversion of a height map file
· Conversion of a terrain map file - this will also convert the height file to this map
· Extraction of the map from a scenario

In principle, any of these operations can be used to create a new base package. However, since the number of elevation maps used for maps of old versions has been relatively limited, and the terrain package is usually much larger than the map of the old version, it may be useful to use a common base package (for one certain elevation file) and terrain packages for specific terrain maps or scenarios as delta packages based on that package.

The Generate Terrain Package wizard supports this approach. When instructed to convert a TER file, it searches the list of already existing (closed) base packages. If he notices that one of these packages has been created on the basis of the same elevation map file, he offers the user not only the creation of a new base package but also the creation of a delta package to the existing base map.

If no existing base package is found, the application will suggest to the user to create such a package by selecting the "Automatically create an empty completed base card" option. This is the normal case and is strongly recommended. It will now create a delta packet with all the information from the TER file in addition to a new base package containing only the elevation information. The base package can be used immediately for other terrain packages, while the delta package can be further edited by the user.

What does that mean?

First of all, we aim to ship all the HGT and TER data included in previous versions of SB Pro to the start of Version 4.1. Old scenarios will then identify the correct site package during loading and exchange it at runtime. Of course, it is recommended to load old scenarios in the new editor in the medium term and save them again, as this will release the ballast of outdated terrain data and shrink the scenario file sizes to a pre-3.0 level.

There are of course maps like Bergen-Schwarmstedt-Hohne, which were created by you and which are not yet part of the official distribution. We are happy to include them if the following conditions are met:

• Legal origin of the data. If the height data is e.g. created by DarkAngel in the SteelBeasts.com forum at your request, I see no problem. If the data was taken from a Bundeswehr DVD collection, then that's a problem.
• The "gardener" - or, if it is a group, all gardeners - must give us your consent to use the TER file, otherwise we can not accept the file. For this purpose, a form should be completed in which the authorship of the terrain data is explained and eSim Games is acquitted of any liability claims of third parties. The form I like to give out by email on request.

In this case, we can take over the terrain data and make the installation less complicated for newcomers. In addition to the direct download we want to offer the site packages in a separate installer, namely

• On a physical medium; it is still unclear whether this would be a USB stick, an SD card (rather not), a small stack of DVDs, a large stack of DVDs (rather not), or a stack of BluRay discs (also "rather not"). That depends heavily on how extensive the material will be, and we only know that after the conversions have been completed.
• On a web server, so integrated with Steel Beasts, that if an unknown card were required, they would be requested directly on the server (s) and added to a download queue that runs independently of Steel Beasts in the background as well after a computer restart the download simply continues. Not only will we run such a server, you could do that as well; The server address must then enter the user in Steel Beasts, so that community-own server will be quite possible. So they do not have to be curated via a forum software but are immediately available to all players using the same server.

[Rinix]

My own thoughts on a physical medium:

• Large stack of DVDs: Undesirable. A large stack of DVDs would be too much for a lot of people.
• Blu-ray discs: Undesirable. While Blu-ray can store 25 GB on a single layer disc and 50 GB on a dual layer disc, those who do not already have Blu-ray drives will not spend $50+ just to buy a Blu-ray drive for installing Steel Beasts.
• Small stack of DVDs: Desirable. Dual layer DVDs will be useful as they can store 8.5 GB vs. 4.7 GB for single layer DVDs.
• SD card: Undesirable. These may not come with SD card readers, and having to buy an external SD card reader is a disadvantage when USB sticks don't need them.
• USB stick: Desirable. USB 3.0 and USB 3.1 USB sticks are only a few dollars in capacities of 16 GB and 32 GB.

[Rinix]

https://forum.steelbeasts.org/forum/thread/8610-gel%C3%A4ndedaten-in-version-4-1/?postID=59084#post59084
All of these posts are translated using Google Translate:

• NASA data is not a problem
• I'm in constant contact with Ulf - thanks for the clarification

This quote is being checked for possible copyright issues. Current predicted waiting time: Calculating....

More informations

Regarding the choice of media, I am quite similar view (especially BluRay, but also DVD - less and less computers have any optical drives of any kind). SD cards may not sound that great, but external readers are pretty cheap. So the question is, is a faster data transfer from a cheap SD card, for which you still have to buy a cheap reader, rather than an equally expensive USB 2.0 stick. A 3.0 or 3.1 stick will then very quickly very expensive, if the amount of data is only sufficiently large. A Fußlahmer USB 2.0 stick is ultimately not so tingling, if many gigabytes should be moved.
On the other hand, it is only a one-time transfer during installation.

Regarding the web server you should also be careful with your wishes. Terrain data is extensive, even if it's compressed, and if only enough people access the server, then traffic is coming together. Maybe we'll book something on Amazon Web Services or for the time immediately after the release, then you'll see how much traffic it generates a quarter of a year later. At any rate, it is not necessarily a runner.

https://forum.steelbeasts.org/forum/thread/8610-gel%C3%A4ndedaten-in-version-4-1/?postID=59087#post59087

... where "fair use" is of course exactly the rubber paragraph, over which the hoster possibly enforces his interests. But of course, you can think about it, if it actually came to that. I could imagine that a full package of "off-the-shelf" terrain data might initially only cover 500 GB (ie converting what is already part of SB Pro PE plus a handful of additional cards).
Since only a few of them would be "your" cards, which would not be part of the official distribution, in practice we will probably start by talking about 50 GB or so. With 100 users a manageable data volume, which is to be transferred there.

But there is another perspective.
The internal resolution of all cards is increased by a factor of 512. That's 128,000 data points per 100km, so 16.4 billion data points for a 100x100km² map, sometimes 16bit height resolution per data point - 262 billion bit pure height data (before compression), ie 30.5 GB. How well this amount of data can be compressed depends on the data structure. LIDAR data can hardly be compromised effectively, because each data point is a true measuring point. The German states seem to be gradually adapting their legislation and in some states it is now so far that the Land Survey Offices release their data for free, including LIDAR scans. There's really something moving.

So if you still remember our video from last year - the LIDAR site of the Sann Dunes comes from the Kallemærsk Heath in Oksbøl - ​​of course it is clear that he wants terrain of this quality. And if you can get it ...? Why not?
And that in turn leads to the foreseeable inflation of terrain data sets. If you gradually replace the old elevation data with LIDAR scans, then 500 GB will quickly become 3TByte. And at the latest then that will be a problem for anyone who wants to operate non-commercially as a terrain data server. Now it's not yet time, that will certainly take years to become so many off-road packages that have such characteristics. But you should keep it in mind. Switching to high-resolution terrain has its price.

[Rinix]

https://forum.steelbeasts.org/forum/thread/8610-gel%C3%A4ndedaten-in-version-4-1/?postID=59089#post59089
Translated using Google Translate. My thoughts: A small stack of DVDs may not be possible. With dual layer DVDs, it will take 4 DVDs to fit 32 GB, and 6 DVDs to fit 50 GB. USB 3.0 and USB 3.1 sticks in 32 GB or 64 GB capacities are only a few dollars.

As I said, now I expect directly rather 50 GB (maybe even 32 ...), so fits easily on a stick (possibly together with the program installation). And we certainly will not put more than a handful of really high-resolution terrain data into the installation (Sennelager would be a candidate). In that sense, the change is not the problem.
And in the long run, of course, storage media costs are expected to continue to decrease approximately exponentially.

[Oleg]

Do I understand correctly that only cards will take up from 500 GB? Is this such an optimization? 

[Rinix]

Do I understand correctly that only cards will take up from 500 GB? Is this such an optimization? 

Cards = maps, it is the fault of Google Translate. I believe 500 GB refers to the maps without compression, and 32–50 GB refers to the maps after being compressed.

[Rinix]

https://forum.steelbeasts.org/forum/thread/8610-gel%C3%A4ndedaten-in-version-4-1/?postID=59096#post59096
All of these posts are translated using Google Translate:

The terrain editor has been extended by several functions. You can raise (or lower) roads above the ground level, even with different elevations for the start and end points of a road vector line. Thus, the construction of linear ramps is possible. The width of the street shoulder and the slope angle can also be set.

Similarly, one can operate road smoothing in the transverse direction; In the process, the embankment is cut in on the slope side and filled up on the valley side. The only problem is that the automatic treatment generally gives unsatisfactory results because intersections do not have a common node, otherwise one could automatically build linear ramps from each individual node to its neighbors without changing their height.
But the road vector lines do not allow that at the moment to define branches and mergers, certainly not with different road types. We have to put in a lot of work before it works properly. In that sense, the basic technology is there; There is a lack of quality of the source data and of the meta-data structure characteristics that must first be developed before proceeding to make the road smoothing functions comfortable.

We would have liked to get ahead, but it was too much work to finish before a release. We did not expect in the summer of 2016 that we would need almost three years for the conversion work. Anyway, I would like to have come much further than we are. But some things can only be found out when they are tackled, unfortunately, all the complications are never predictable.


So now one can also treat the 1m, 3m and 6m streams as roads and lower them below the surrounding level, e.g. -2m, with minimum shoulder width and 60 ° slope angle. This then unfold even small streams obstacle effect. Problematic are the intersections with roads. Here you have to break the water course a few meters in front of and behind the intersection, before you make the lowering - or you have to repair afterwards the lowering of the road again, which is also stupid.
And of course you can sit down a street somewhere, build a ramp under it, and then clear the street afterwards. Then you have a dam. Or a sink (like the old "Ditches" in version 1.0).

A next step would be well. to define certain road profiles for roads, e.g. can automatically lead trenches in parallel. Doing so by hand would be unacceptable, it must be procedural, but in a way that does not create more problems than it eliminates old ones. And then our AI would also have to recognize and avoid small-scale soil structures with obstacle value. You see, the work is not enough.
Of course it would be better if the quality of the output data would be better. If you get LIDAR scan data in resolutions of less than 1m grid size, you can save a lot of ramp construction for the road network. But then the file size grows, cf. my introductory statement ... (small sigh).

https://forum.steelbeasts.org/forum/thread/8610-gel%C3%A4ndedaten-in-version-4-1/?postID=59097#post59097

And another section from the manual:

Edit roads and objects

The Edit menu contains the following options for editing the properties of existing roads:
Generate bridges creates bridges for all road sections that lie on water fields. The original road section is removed and replaced by the bridge. In general, this works well, but road sections that run parallel to a river or lake shore can also be converted into bridges if they are too close.
Smooth Roads creates a road shoulder of given width (depending on the road type) for all roads on the map, and then creates an embankment, thus ensuring a horizontal alignment of the road cross-section. This operation is quite expensive, depending on the size of the map and the number of street objects. In addition, it can be expected that the slopes generated in this way will cause considerable (and therefore disturbing) changes in the height profile, especially in hilly or even mountainous regions. Instead, we recommend the minimally invasive case treatment of problematic road sections.

Select Generate bridges for selected roads (Shift + B) to create a bridge between the endpoints of two existing roads that you must have previously selected (Shift + Left Click).
Smooth Selected Roads opens a dialog (Shift + F) to set the following parameters for the selected road:

• Max. Slope [°] determines the slope in the direction of the road
• Max. Inclination [°] limits the inclination of a road across its course
• Shoulder width [m] defines the maximum width of the shoulder on either side of the road (i.e., total width of the road = width of the carriageway plus 2 x shoulder shoulder width).
  In practice it has been proven not to go under 2,34m. Underlying values ​​often lead to visible faults in the carriageway area.
• Slope angle [°] determines the slope of the slope. In reality, this angle is dependent on the surface (and the local space conditions, masonry is used if necessary). Steel Beasts limits the angles to values ​​between max. 80 ° (recommended for rocky ground, limited space, and for steep slopes) and min. 20 ° (for extremely loose and dry soils, the natural limit is around 25 °).

Most military vehicles are specified for overcoming slopes up to 60 °. So if you set a larger angle, the road embankment can develop a strong obstacle effect. On the other hand, steep slopes are helpful to avoid large-scale changes in the terrain profile, especially in the vicinity of buildings.
Leveling under selected objects opens (Ctrl + F) a dialog with the very elegant title Settings of Object-Clearance. Here, the terrain below the center of the selected building (or other object) can be raised or lowered. In addition, the width of a seam around the outer boundary of the object can be set; I. A. the minimum value of 78cm is sufficient. By deselecting the box smoothing could be leveled without leveling, which in rare exceptional cases may be less meaningless than it certainly sounds.

Increase an existing road (Shift + R) with Pick Selected Road. The starting point of the selected part of the road can be recognized by a green dot. When selecting Raise Selected Road, Steel Beasts opens the Raise / Lower Road dialog. Here you can now enter the start and end heights of the road, as well as the shoulder width and slope angle. The unmodified application raises or lowers the road at full length to the surrounding terrain, which is rare in reality except for dike construction. By contrast, the Ramp check box linearly adjusts the elevation profile from the starting point (larger, green vertex) to the end point (small, black vertex). The height of the start and end points can be entered relative to the surrounding terrain, or if the box Absolute height in, well, absolute height is selected. The values ​​for start height and end height are inserted directly in the dialog.

Restore selected roads can be used to discard changes (Ctrl + S). This function is only available as long as the original height profile is still present, e.g. after converting an HGT file. If a completed base package is saved as a new base or delta package (in progress), the road profiles changed in the original base package can no longer be put into the "original state" before they are processed.

Turning the curve smoothing on / off smoothes the course of the road (Shift + S) using a spline function.

[Rinix]

https://forum.steelbeasts.org/forum/thread/8610-gel%C3%A4ndedaten-in-version-4-1/?postID=59099#post59099
Translated using Google Translate:

No, you can convert the old maps to the new format, then the corresponding editing options are available (for example, smoothing the terrain under buildings). The existing 12.5x12.5m² terrain is broken down into 0.78125² sub-tiles (this is the same resolution as has always been used in the pushed positions), then the elevation values ​​of these sub-tiles can be adjusted accordingly.

Then, another four times higher resolution mesh is placed over this 0.78125m grid, procedurally crumpling the surface somewhat, according to the waviness values ​​in the terrain type for the particular soil type. Scenarios that were created prior to version 4.1 and refer to old terrain files are, if possible, assigned to a converted map (unfortunately, there are so many special cases that have to be considered, that was not a pleasure to implement). If this is not possible, you can still extract the terrain data embedded in the scenario, convert it, and then reassign it to the scenario.

Generally, old cards often have the problem that the ripple (and other values ​​such as ground hardness, traction) have been set to 1.0 or 0.0. These are of course EXTREM VALUES, according to an alpine boulder field or something. That is why we will reduce the ripple by 50% for old scenarios, so that it does not become quite so brutal. Because, of course, it does not look so natural when there is maximum hillockness from the edge of the forest, but everything in the meadow in front is mirror-smooth. Arable land should generally be fairly flat, a heathland may be 25%, heavy terrain would probably be located between 30 and 60%. Wheeled vehicles should tend to avoid terrain with undulations of 40% or higher, chains maybe up to 80%, but then normally it would really be over.
The same is true of dust: 0% is practically only found in swamps in nature, 100% would be extreme desert terrain as in southern Spain, Afghanistan, etc .; 20 ... 60% would be normal for central European terrain. (Reminder: These values ​​apply to dried-up soils (!), Besides, there is still the value for wet soils, and SB Pro then averages, depending on the weather.)

The soil hardness is also set too often to 1.0. Beyond 0.95 positions and Schützenmulden are no longer pushed / dug, but would have to be blown up. Therefore, one should be careful here with the soil hardness; Soil hardness will also sometime affect the time in which a PiPz can post a position at runtime of a scenario. By then you will have to worry about this question.

Traction is also such a topic. 1.0 means: Hot race tire on warm asphalt. It is rare in nature.