Jump to content


  • Content Count

  • Joined

  • Last visited

Posts posted by Ssnake

  1. 6 hours ago, Jartsev said:

    Very likely scenario is set on some old map, which wasn't georeferenced; in such case in v.4.1  coordinates  for the map's SW  corner are automatically set to Oceanic Pole of inaccessibility

    Not quite. The actual coordinate is close to point Nemo, but still a literary reference - R'lyeh.

  2. I'm not fundamentally opposed to the thought. It's just that in order to make it work, a LOT of work needs to be invested, and I'm skeptical if the results will justify the effort.


    • Step 1, invent/adopt a render engine that can reliably deliver a steady 90 frames per second, per eye, in high resolution. We'll do that with 5.0, but it'll take a while.
    • Step 2, VR is obviously wonderful if you're inside the tank, looking around. Until you notice all the surfaces that we removed to optimize the polycount from a number of fixed locations. With 6DOF movement you will start spotting them.
      Should we fix all that?
      This would amount to redoing all the interiors, without getting paid (IOW, we could do this only at a slow pace, so initially only very few vehicles would be VR enabled).
    • Step 3, if you're the vehicle commander or the driver, while you're not looking into sights, VR is glorious. But the driver's position is not the focus of this simulation, and if you're just admiring the beautiful tank interiors you're doing it wrong, and the virtual enemy will deliver virtual death to you quickly. IOW, the moments where VR works best are arguably least important to your actual gameplay. Should we then change the gameplay to accommodate the few with VR goggle better?
    • Step 4, there's the challenge to operate the instruments inside your virtual tank. VR without data gloves or some other pointing device will be useless. Sure, there's products like Manus VR which not only allows you to point at things but also to get tactile feedback if you click a button. But these are still expensive.
    • Step 5: With VR goggles on, you can't properly use your keyboard anymore. Boom, about 120 hotkeys that you're accustomed to are now GONE and need to be substituted somehow. 3D Gesture Tracking? Voice Recognition? Maybe all these can contribute towards a solution but don't believe for a second that they will work faster and as precise as pressing a single hotkey.


    People tend to see the "glorious" aspect, and I agree that it is tempting. But there's a looong tail of tasks and challenges that need to be solved which, while we're concentrating on these, will prevent us from working on other stuff. So these opportunity costs need to be taken into account as well. And when I do all that, my conclusion is that under the prevailing conditions it's just not worth it.

  3. You can open these scenarios in the Mission Editor. There you get prompted to replace the map, and then you can pick a map package that covers the same region. There's no guarantee of course that the map package will be 100% identical with the terrain data that the original scenarion contained. The only way to check that is to open the scenario in version 4.0 or older and then to compare if the new map package is altered in a significant way.

    But usually the map replacement is an expedient solution that yields adequate results.


    The option of last resport is to extract the map data from the legacy scenario and to make a one-off conversion into a map package. For that you may need to install the Legacy Maps.

  4. I did apply it, although not consciously. The thought processes laid out above were as they were. Thanks to Kahnemann, which I only discovered years later, I can now formulate the process in a more concise manner. Before that, I would have called system 1 "guts" or "instinct" although we all know that it can be trained with experience (which is what Steel Beasts attempts to do, if you play scenarios conducive to building relevant experiences). And we all KNOW that "thinking hard" (=system 2) is, well, hard, and takes longer and tends to absorb all your brain power/attention.


    I mean, many of us have been instructors in the army at one point or another. And if you took that role seriously (as you bloody should, since lives depend on adequate training) then you probably also learned a bit about what types of training work best for what kind of skill/activity. Where it's the perfection of body activities armies figured out more than two thousand years ago that drill based training works best, wether your service weapon is a pointy stick or an M16. As army guys we call it "muscle memory" which is of course absurd since muscles have no nerve cells that could store information, but it gets the point across that it's all about memorizing motions until you no longer have to think about them. Because thinking is slow.

    So, Steel Beasts is heavily leaning towards the cognitive skills spectrum. But even here there's the distinction between analytical thought processes (what you might do a lot in a staff officer's role) and "experience", the ability to sense a tactical opportunity, to develop a simple plan for a tactical move on the fly and to quickly give the necessary orders. I'd bet you a lot of money that successful military leaders, even if they conduct a maneuver in text-book manner, do most of it based on "instinct" and "experience". Analytical thinking has its place when there's considerably less steel fragments in the air, and that's where a lot of tactical training at military academies (sic) is focused on. But at the platoon level, decision-making needs to be snappy. And Steel Beasts was tailored for the platoon level.

  5. Select the road leading to the bridge. Hold Alt or Ctrl or Shift (one of the three, don't remember which) to turn the mouse into a cutting tool (scissor icon), then cut the last 20m or so leading to the bridge edge. And, of course, cut that road right at the beginning of the bridge. Select the segment again, now go to Edit... Raise Road. This will pop up a window where you should switch to absolute heights, and then you adjust the elevation for the point under the bridge. That could be the end point (no green tip) or the start point of the road (green tip), so depending on the orientation you need to lower the one under the bridge. Reduce the height by 10 or 20cm, click OK, then have a look at the result. If in doubt, undo, then try again. Eventually you'll get the hang of it.


  6. It's, well, a design decision that's ultimately subject to opinion. I figured that trying to come up with structured statements that would follow Boolean Logic would occupy too much of a user's attention when there's usually a lot of things going on, and would subject to an effect very similar to target fixation. These embark conditions etc. are heavily "system 2" driven (following D. Kahnemann's terminology), which is the equivalent to "heavy work" for the brain. But tactical decisions, I believe, are mostly System 1 driven - gut feelings, a sense of the situation that factors in more elements than you can easily name. And you need to develop the System 1 for tactical situations because a. you're working from an incomplete situational picture, b. you're working under information overload and under time pressure. The precious few bits of reserve capacity for analytical thought processes should not be consumed by the simulation's user interface, ideally.


    You may disagree with that design decision, that's cool.

    But I hope that the answer above at least illustrates that we didn't make these decisions on a whim.

  7. The way I see it, commercial considerations aside, the only justification for releasing an Alpha version of a software is to invite feedback from the targeted customer demographic. If a developer can't handle constructive criticism, they shouldn't release early. As long as the criticism is respectful and focuses on what the products attempts to be, it is almost always helpful for a developer. Of course, "feedback" from the the proverbial internet basement nerd with the impulse control of a 14 year-old is best ignored, possibly even silenced because really nothing good will ever come from that.

  8. I can but ask you to submit your details by email; please run the CmDUST diagnostic tool and attach it to your email to me. (In the Start Menu | CodeMeter program folder is a tool named "CmDUST"; run it. It will open a Windows File Explorer window at the end containing the "CmDust-Result.log" file.)

  9. If you have a CM stick, then no, your PE license will never expire.

    As to what happened in your case, from what you describe I can't say. Maybe you should first look up what your CM stick says about itself in the WebAdmin, see here:

    The next question is, do you get error messages?

    If so, please tell us the full text of every error message that you get on startup.


    The CodeMeter Control Center may also be useful to visit:


  10. Don't get me wrong. It's all doable.

    It requires however a concentrated effort both in the visuals, the AI, and possibly auxiliary issues such as preparing/marking positions with glow in the dark paint for NVG equipped drivers, light traps against infantry etc.


    At the same time you can't make night "too dark" when 80...90% of the important clues to the player are conveyed visually. If you make it too cinematic and the player can't see shit except for explosions and other lighting effects, there's only very little to be gained from a training perspective. It doesn't help that all the techniques described above are largely obsolete these days because none of our customers still uses searchlights, except for deterrence in peacekeeping operations.

    Which brings up the other aspect, AI reactions to being illuminated - freeze? dive for cover? Pop smoke? Rush forward? They need to be able to detect it and, depending on the circumstances, react accordingly.

  11. At this point, I simply don't know. I suspect that what happes is that every soldier who dies retains the ID of his squad/team. If that is the case, then we need an option to filter dead units from the Duplicate ID list to that they don't confuse. After all, it's entirely possible that there might be "true duplicate IDs" mixed with "dead duplicate IDs" and it's intolerable to expect from a mission designer to find out which of them is which.


    If they are all (or all but one) dead, then at least no bad stuff (TM) is to be expected, but in order to verify that we need this filter function for the list.

  • Create New...