Welcome to Steelbeasts.com

Register now to gain access to all of our features. Once registered and logged in, you will be able to contribute to this site by submitting your own content or replying to existing content. You'll be able to customize your profile, receive reputation points as a reward for submitting content, while also communicating with other members via your own private inbox, plus much more! This message will be removed once you have signed in.

Ssnake

Members
  • Content count

    19,506
  • Joined

  • Last visited

About Ssnake

  • Rank
    Senior Member

Personal Information

  • Location
    Hannover, Germany
  • Occupation
    Director, eSim Games
  1. One may be a symptom of the other, occasionally. When you have to tame a code monster of 700,000 lines, there aren't always cases of linear cause and effect. The decision to "move" from an observation activity to a firing pose may not be "pathfinding" in the close sense of it, but it definitely deals with behavioral algorithms for the infantry, the "A.I.", which includeas multiple factors - battle position tactics, target priorities, user input, a general suppression factor, the perceived vulnerability of a target, the range of own weapons. Let's assume for a moment that both you and me have only an incomplete understanding of the Steel Beasts code base, that our programmers know what they are doing, and that they are trying not to break stuff that works while working on stuff that needs improvement. Due to our limited understanding of the situation our discussion can by necessity only approximate certain aspects. Not everything that I write may always make sense in every aspect, this may be due to my limited understanding, my limited ability to express my thoughts, or the desire to be brief in my responses. I often get accused of writing walls of text, and I guess I'm guilty of that, but not because I love expressing in 500 words what can be said in five, but because I believe that context is important, and especially in software development and engineering in general, details matter a lot. I cannot lay out all the details in a public forum. So you'll have to live with some of my statements not making sense immediately. They are, however, always as truthful as I can be in public.
  2. The road Z-fighting will be addressed in version 4.1 For the rest, we'd need a logarithmic z buffer. Doable, but not trivial to change.
  3. A lot of the infantry issues are rooted in fundamental issues with pathfinding. We're going to address that first. Once that they can reliably negotiate the environment we'll make the behavior less erratic, which will increase the "playability". Along with that we may also address the firing of MGs and RPGs. I would however like to point out the difference in development paths between SB Pro prior to version 3.0, and after. Up until 2.6 there were infantry sprites and not much of a user interface. Now we have infantry with a meaningful UI that is modeled in much more detail (training levels, stamina, "shoot here"/"suppress"/etc. commands, the overhead view). So, I think that friends of the infantry can see a somewhat encouraging deviation of course since I took over management. That not all change is coming as fast as you'd like it to see, check. There are limits to how fast a team can make non-destructive changes to a legacy code base. Given our means, I think the result is awesome. Of course, seeing this from a customer's point of view who doesn't care how the sausage is made, as long as it tastes good, it may still appear as a slow pace. Both perspectives are valid. Naturally I only have ma own perspective, but I try to see the situation from your end as well. All I'm asking for is that you try the same.
  4. In all fairness, not everything is as well documented as one would wish it to be. Steel Beasts is pretty feature rich; I suppose a sufficiently malicious character could call it a sprawling mess. (At least, when trying to catch up with the user manual, it feels like it at times.)
  5. Note that if troops disembark on a route (due to disembarkation condition), they will remain in place. When dismounting on a waypoint, they may pick routes leading away from that waypoint (assuming that suitable embark conditions exist, be they explicit or implicit).
  6. Thanks. I have renamed the round to M384 now and tweaked the parameters to match it. I suppose it's not really much of a functional difference anyway, as far as modeling in SB Pro is concerned.
  7. It's "possible" but there are a number of issues. Correlated Terrain (can be solved with specialized terrain database management software that generates output for multiple simulations). This is particularly important for linking two or more virtual simulations, especially if interaction is expected between players on different simulations. Also, these correlated terrains usually look not quite so visually appealing as they are based on the lowest common denominator Entity mappings. A rather underappreciated point. Every human character, animal lifeform, every bullet and missile that is either visible on both virtual simulations and/or which gets fired across simulator boundaries needs to be available (and mapped) in all connected systems. There is a standardization effort by the SISO committee but, well, standardization efforts often are struggles between industry players for dominance. If, for example, LockMart says that it "interprets a certain standard differently" than everybody else but their contribution is important to a certain exercise, well... all bets are off what will happen. Or, if simulation A doesn't actually have entity "X" in its own object library - say, a 120mm x 570 DM43A1 - but units of simulation B are equipped with it, either the exercise fails of you have to fall back to the lowest common denominator (some "other" ammunition that is "similar" in performance and which is available in both systems). Or you attempt a "best match" mapping, which can work with TWO involved systems but certainly not with three or five. An extension to #2, lifeform mappings, animation/posture mappings. Do you settle with the lowest common denominator (again)? What if certain animations are actually vital to your training objective. If simulation A supports certain gestures at a vehicle checkpoint, and simulation B doesn't HAVE those gestures, what do you do? Gateway/network protocols. Yes, yes, yes... doesn't HLA solve everything? No, it doesn't. HLA prescribes the way HOW simulations conforming to HLA must exchange information if they want to do it, but that still doesn't mean that an HLA compliant software actually exposes that information over the network. Besides, HLA has a whole host of issues. DIS is often preferred, but, well, has "different" issues. Who resolves which incidents. Should the shooting simulation decide what happens to the target? Should the simulation with the best damage mode decide? And which IS the best damage model, who can decide that? HLA says, "the shooter decides" which is as good as any other arbitrary decision. And often the finer points of a damage system aren't really that relevant to a certain training goal after all. Protocol limitations. Take HLA as an example. Simulation A supports dynamic terrain, simulation B does it too, as does simulation C (but it does it differently than A and B). HLA however says that trees and buildings are static objects. So even IF all simulations support the same feature set, there's no guarantee that you can actually transmit the information across simulation boundaries if the network protocol says that such a state change is undefined/illegal. (This is what happens when lawyers in Congress decide about engineering questions.) AAR. Which simulation supports best the AAR. Is there an option to synchronize playback across simulation domains (largely, No). So, there aren't complete and completely satisfactory answers to those questions. Some shortcomings may be tolerable in one exercise but not in another. It seems like those of our customers who actually engage in multi-platform simulation exercises pick one "major" simulation and then add a handful of other players in specialist roles to support the main effort. That you actually have multiple simulations on equal footing seems to be the exception rather than the norm. We recently tested connecting five different simulation systems in Denmark, and overall it was a success. We had SB Pro in it, an infantry simulation, a battlefield management system, a constructive simulation, and one additional software for background calculations. There was also a voice over IP solution that could have been synchronized to the Steel Beasts AAR (but we never got to the point of running an actual AAR, mostly for time restrictions). At the same time it has to be said that it took three or four specialist engineers from multiple continents present on location to make the whole exercise possible (and granted, it was primarily a technical evaluation and not so much an actual "exercise"; the soldiers supported us in the evaluation rather than us supporting the soldiers exercising). I think it will still take considerable effort to create a multi-simulation training package that can be started by people with little technical background. Armies could accelerate the process, I guess, if they would actually finance such integration efforts rather than leaving it to industry players in shifting alliances who are sometimes competitors, and then cooperating partners on other occasions. Above all I think that NATO should coordinate an attitude change among members that puts more pressure on certain industry players to actually conform to important standards (other than HLA, which is neither very practical (nor very important, because it isn't practical)), like SISO entity, lifeform, and posture mappings. Right now everything is left to industry and academia, so it's not a big surprise that actual progress is slow.
  8. No.
  9. Yes. That would explain it.
  10. Interestingly I can find no 40mm high velocity "M383" in the Jane's Ammunition Handbook, at all. And you are correct, the M384 is a pure HE round, the M430 would be the dual purpose HEDP with hollow charge warhead. Looks like some fixin' is in order.
  11. I think we have a bug where the M383 is modeled after the M384 with its dual purpose warhead that has up to about 70mm HEAT penetration.
  12. On what occasion/circumstances did you see that?
  13. Yes.
  14. When you increase LOS calculations by a factor of 512, no amount of multithreading will be able to offset that. That's not to say that multithreading isn't a worthwhile goal to pursue but it's always easier to throw buzzwords into a discussion than actually implementing the change. As far as crowd funding is concerned, all I can say is that I will not participate in any public debate of our business strategy. I'm here to explain our position to visitors that have no degree in computer science (why certain things are easy to do, but mostly why other things are hard, and that there's no free lunch in high performance computing). I'm not necessarily soliciting for advice, no matter how well-intentioned it may be. The reason is that it creates an imbalance in the discussion where I cannot adequately respond without revealing our business strategy. And constantly pointing out that I cannot answer X, "because classified" will at the end of the day undermine my credibility as the ambassador of eSim Games. I can but ask you to accept that there are limits to what I'm willing to discuss.
  15. Tree clusters have certain disadvantages too. Once that we add them, I'm sure there will be people hating it because of those disadvantages. Tweaking the perception and engagement threshold of computer-controlled units may be a by far more effective step to take that helps to reduce the number of CPY cycles per frame in general - which would be a good thing. Real-time 3D games are exercises in high performance computing. We need to maintain a balance between feature-richness and performance. A Steel Beasts running at 20 fps or less would be next to useless. Needless to say, perception modifications are more delicate to work with.