Jump to content

Will THIS ever get FIXED?


Werewolf

Recommended Posts

I've been playing SB since 2001 - and that can't be said about a single one of the many, so many that I've lost count, of the games that have been bought and played since I started playing games on a computer way back in 1979. In other words been doing this for a long long time. Back then I was heavily involved in SB MP, scenario design and single play until 2006 or 2007 when I stopped MP and stuck with SP only. Played regularly since and updated from versions 1 to 2 to 3 and now 4 which means I've put more money into SB than any other single piece of gaming software I've ever owned.

 

I just upgraded to 4.010. Started playing around and initial reactions were WOW! Infantry changes are fantastic, graphics are improved and on my rig at least my perception is that eSim spent some time on optimization 'cuz I'm getting better frame rates than I ever got in 3. New options in the editor that I can't wait to try out. In short - until about 10 minutes ago I was truly IMPRESSED!

 

So...

 

Why is all that important? Because before I go off into rant mode it may help in assuring those who will break out their flame throwers and aim 'em at me that Steel Beasts is truly a product that I both admire and love. It's also got one issue that's bothered, frustrated and downright pissed me off since version 1.

 

... and just what is that issue that's got me so riled up you may ask?

 

Well...

 

Plain and simple its that the AI vehicle drivers STILL, STILL, don't have the brains GOD gave a wooden jackass! (learned that particular phrase from a 90 year old woman back in the 80's telling me about her 92 year old husband - rarely use it - today it seemed appropriate).

 

Even after almost 16 years the AI drivers still drive into rivers.

 

Come ON!

 

The only explanation I can think of for this having not been resolved by now is that this single issue must be the monster grand-daddy of all bugs. A bug so mean and nasty that if we  ever ran into it on the street our only option would be to just lie down and let it eat us without a struggle. This single bug must be the most difficult to squash of any bug in any game ever created - must be - because I just can't imagine, won't even think about the alternative.

 

So...

 

ESIM! PLEASE FIX THIS!

 

16 years is long enough to wait. I'm 65 (will be in a couple of months anyway) and I'm not sure I'll be around in another 16 years. SO Please? Please fix this.

 

 

Link to comment
Share on other sites

From previous posts on the subject esim are spending serious amounts of money trying to resolve the issue.

I had the same issue in a mission i was just playing, the AI could not reverse and change direction from what was a relatively Small rock formation.

 

Edited by Marko
Link to comment
Share on other sites

I predict you will see clumsy AI behavior always. Try and imagine the solution that AI drivers simply sense bodies of water from further away- let's pick 100 meters as the line AI drivers never approach water. And then that could create its own problem because as AI vehicles become more sensitive to their surroundings from further away, they could end up just caught in some kind of decision loop they can't break: forest 100 meters to the left, water 100 meters to the right, large rock 100 meters to the front, the vehicle could just freeze or just endlessly turn in circles in order to avoid everything. The flip side therefore is that you'll never get AI drivers to ever approach close to water if ordered to or if they need to. And this is true not only for water but for all man made structures and natural terrain features.

 

I haven't installed 4.10 yet, but I assume on behavior that might still be present that I think has little to do with revolutionary development in computer intelligence to fix is the way dismounts immediately expel a few meters behind their AFVs as they are being hit by auto cannons or something.

Edited by Captain_Colossus
Link to comment
Share on other sites

In addition the "wingman" vehicles aren't that smart.

 

They take they cue from the command/senior tank.

 

If you plot a route for the lead tank to go near water and select a Wedge formation with say wide spacing, then the the vehicle one out and one back just goes to where it needs to be (say 100m behind and 100m "out" from the centre). The the vehicle two out and two back just goes to where it needs to be (say 200m behind and 200m "out" from the centre).

 

It doesn't matter where that spot is, or if its relative route takes it into the water, it will do what you told it to do.

 

Give the formation Column or reduce the spacing for that section of the route and it is workable.

 

You just need to understand how the AI works to get the best out of it.

Link to comment
Share on other sites

I appreciate the replies guys. Expected nothing less.

 

But I have to respond.

I'm an intermediate level programmer at best (Basic and Fortran mostly with some dabbling in C) so I know just enough about it to be dangerous and do my job as a financial analystNeither do I know what's going on under the SB hood so what I'm about to present is little more than a guess, an educated one but still just a guess.

 

That said this issue seems to me to be little more than a path finding issue. Path finding algorithms are taught in MIS/Programming language courses at the college level as exercises in problem solving/mathematical algorithm building - anyone majoring in programming (or what ever it is called these days) is exposed to path finding algorithms by their junior year in most cases. If/then/else, select case it seems to me it's just a case of identifying the factors necessary to guide a vehicle around or across water by identifying object collisions, defining prohibitions, exceptions, go aheads and redefining an existing path with a newly calculated path. If in the event that no solution exists or the algorithm gets stuck in a loop then a trap routine sends a radio message to the player to that effect so that the player can go and plot a new path for the unit with the benefit of human intervention. 

 

I couldn't program the solution but software engineers with a specialty in programming games are among the best programmers around - or so I am told by engineers I know qualified to judge that (and those guys design disk drives).

 

I 'm not saying it would be easy.

 

But geez! It's been 16 years with the same problem. And no solution.

 

I'm gonna go out on a limb and hypothesize that the issue isn't one of can't but won't. This issue isn't a priority because esim's main customers are the military and they don't need the AI from what I understand.

 

As a customer of very long standing if that is the case I for one would appreciate being told by esim, "We're not gonna fix it - costs exceed the return".

 

As a financial analyst I'd understand it. It'd suck - but - yeah - I'd understand and could just move on.

 

 

Edited by Werewolf
Link to comment
Share on other sites

55 minutes ago, Werewolf said:

This issue isn't a priority because esim's main customers are the military and they don't need the AI from what I understand

 

Well for Aust at least that is incorrect.

 

We do not use it primarily as a crew procedural trainer (of course we can but that is not its primary application).

 

We do use it primarily for Course of Action Analysis or testing a plan.

 

1 x Trainee fights his/her plan using SB to solve either Cbt Team (sub unit level) or Battle Group (unit level) problems.

 

The one person controls the manoeuvre units, so say a HQ, 4 or 5 platoons (be they Tk or Inf), to put in an attack. Another person calls in the fire and if lucky a 3rd handles the CSS.

 

They rely on the AI to execute their plan (Bad result implies bad plan = bad result on course) as they can't nurse maid every Tk, APC or Inf unit - and nor should they as their job is to fight the Cbt Team.

 

They are just briefed on the software's short comings and they work around them.

 

A quick (hour or two) session showing the short comings and how to avoid them (taking care with route placement, different formations/spacing on different legs as required, sue of waypoints and tactics, etc.) and they achieve good results.

 

As I say perhaps other places use it differently.

Link to comment
Share on other sites

What i tend to do,

 Till such time as the issue is addressed/resolved is pick maps carefully.

I tend to pick maps that don't have much clutter i never route through forests unless theirs no choice i tend to pick maps with rolling type terrain.

And i almost always use the follow road option in the editor normally in  column formation this is not always possible depending on the mission.

The issue its self is not to bad in MP, its single player mode when your trying to control numerous units it can be a pain.

Link to comment
Share on other sites

I don't have a background in programming, all I can do is presume the average programmer's mind works similarly the way my mind does. Because the computer can only do what it's programmed to do, until a computer is able to learn

at the level of human reasoning (which contains a lot of information gathered not just on a cognitive level, but things like intuition, reward seeking and pain avoidance behavior are factored in), then it's just a reflection of some of the worst kind

of human reasoning, which strips all these things out and attempts to predict future behavior under all conditions that a computer algorithm attempts to follow- therefore, the computer decision routines have to be the poorest kind of reflection

of human intellect, at least for the time being or unless eSim is able to find some source of extraordinary new AI software which isn't just based on analyzing facts but emulates human behavior, which is informed by more than facts but sense data

impressions, emotions and so on.

 

So I therefore imagine the problems I think I would have- now mind you I know nothing about game program languages, but I do know enough that they are a reflection of the human writing them in anticipation of all kinds of variables that might happen- and I can

empathize with what any problems programmer might have. We all want human like behavior, which also means it can be on the spectrum or being predictable to unpredictable, even make human like mistakes- and I don't know how to program a computer

to simulate a mistake other than to simply limit the amount of information it's allowed to gather and use.

Link to comment
Share on other sites

In case anyone is keeping count, I hope this never gets fixed. To me, SB wouldn't be SB unless one of my vehicles go for an occasional swim.  We have seen and dealt with this behavior for so long that it has long since stopped being a problem and is more of an inconvenience.  

 

5 hours ago, Werewolf said:

I appreciate....

 

Geez dude, your post hurt my brain.  By your own admission, you no concept of what the problem is but you are able to see its effects which is enough to allow you to imagine what the problem is.  Armed with this and a bit of non-linear logic, you are able to formulate a hypothesis: eSim is unable or unwilling to fix the behavior, and you double down by suggesting that they are incapable of fixing it.  You go as far as putting words into their mouths in your conclusion.

 

Really?

 

I'm not against people being critical against eSim but you have make sense at the very least.

Link to comment
Share on other sites

There are many different behaviour options IRL that can be applied when moving close or across obstacles. So you have to programm a shitload of routines for platoon behaviour and will likely still get it wrong.

From a training perspective, its much better when the vehivles do as they're told. That way a student can see "I made a mistake here..." as opposed to "this didn't happen the last 3 times, WTF?," which can happen if some hidden parameter changes an now AI uses a different routine...

Link to comment
Share on other sites

8 hours ago, Gibsonm said:

In addition the "wingman" vehicles aren't that smart.

 

They take they cue from the command/senior tank.

 

If you plot a route for the lead tank to go near water and select a Wedge formation with say wide spacing, then the the vehicle one out and one back just goes to where it needs to be 

In a mission I've played just yesterday it was the opposite. The platoon leader went straight into the river, while everybody else, no matter their place in a wedge, waited for him on the shore. 

Link to comment
Share on other sites

While sometimes the SB AI is particularly prone to drive into water, this does still happen in real life as well - tanks are bogged, roll over, belly up and all manner of other immobilisations are possible. This is why there is training in self recovery, and a (barely?) sufficient supply of recovery assets.

To prevent it occurring even when the plan is rushing large numbers of vehicles through difficult terrain at a high speed would be as wrong as the current occasional "deliberate suicide by water" as a vehicle attempts to use the river bank as a firing position.

Hopefully the higher terrain resolution will also (eventually) permit better shaping of the river bottom/bank/approach which will frequently offer other better fighting positions than our current double v sections do, and less likelihood of drowning in all rivers, all the time, while preserving rivers and lakes as a barrier to movement (even for amphibious vehicles in many cases due to exit requirements).

Link to comment
Share on other sites

7 hours ago, Homer said:

In case anyone is keeping count, I hope this never gets fixed. To me, SB wouldn't be SB unless one of my vehicles go for an occasional swim.  We have seen and dealt with this behavior for so long that it has long since stopped being a problem and is more of an inconvenience.  

 

 

Geez dude, your post hurt my brain.  By your own admission, you no concept of what the problem is but you are able to see its effects which is enough to allow you to imagine what the problem is.  Armed with this and a bit of non-linear logic, you are able to formulate a hypothesis: eSim is unable or unwilling to fix the behavior, and you double down by suggesting that they are incapable of fixing it.  You go as far as putting words into their mouths in your conclusion.

 

Really?

 

 

 

If a problem has existed for 16 years then what conclusions can be drawn about the issue other than:

 

1. It can't be fixed - if so then just admit it. I'm OKAY with this.

2. It can be fixed but we're unwilling to fix it for business reasons. I'm OKAY with this too.

3. We know about the problem but it's been one for so long that our users have grown so accustomed to it that it really isn't a problem - I'm not OKAY with this. It's like saying that oil leak you've got is not a problem just keep adding oil when the level or pressure gets too low.

 

There's undoubtedly a lot of excuses that can be made but they're still excuses and an excuse is no more than an "attempt to lessen the blame attaching to (a fault or offense); seek to defend or justify."

 

 

Link to comment
Share on other sites

52 minutes ago, Werewolf said:

 

If a problem has existed for 16 years then what conclusions can be drawn about the issue other than:

 

1. It can't be fixed - if so then just admit it. I'm OKAY with this.

2. It can be fixed but we're unwilling to fix it for business reasons. I'm OKAY with this too.

3. We know about the problem but it's been one for so long that our users have grown so accustomed to it that it really isn't a problem - I'm not OKAY with this. It's like saying that oil leak you've got is not a problem just keep adding oil when the level or pressure gets too low.

 

There's undoubtedly a lot of excuses that can be made but they're still excuses and an excuse is no more than an "attempt to lessen the blame attaching to (a fault or offense); seek to defend or justify."

 

 

...or: It can be fixed but the fix will create a host of problems in other ways. As this one is not simply about pathfinding as implied, but also about unit behavior and controlability.

 

I just don't get why anyone should admit anything??

Link to comment
Share on other sites

23 minutes ago, Grenny said:

...or: It can be fixed but the fix will create a host of problems in other ways. As this one is not simply about pathfinding as implied, but also about unit behavior and controlability.

 

I just don't get why anyone should admit anything??

 

So...

Number 1 then?

Link to comment
Share on other sites

3 hours ago, Werewolf said:

 

If a problem has existed for 16 years then what conclusions can be drawn about the issue other than:

 

1. It can't be fixed - if so then just admit it. I'm OKAY with this.

2. It can be fixed but we're unwilling to fix it for business reasons. I'm OKAY with this too.

3. We know about the problem but it's been one for so long that our users have grown so accustomed to it that it really isn't a problem - I'm not OKAY with this. It's like saying that oil leak you've got is not a problem just keep adding oil when the level or pressure gets too low.

 

There's undoubtedly a lot of excuses that can be made but they're still excuses and an excuse is no more than an "attempt to lessen the blame attaching to (a fault or offense); seek to defend or justify."

 

 

Your 3 option might be correct or not. You cannot go on to conclude that they MUST BE the only 3 possible excuses to explain their incompetence and indifference answers.  No conclusion can be drawn because we don't have all the info. It's as simple as that.

 

Link to comment
Share on other sites

2 hours ago, Homer said:

 

Your 3 option might be correct or not. You cannot go on to conclude that they MUST BE the only 3 possible excuses to explain their incompetence and indifference answers.  No conclusion can be drawn because we don't have all the info. It's as simple as that.

 

 

Uhhhh...

What?

 

Conclusions are regularly reached without ALL the info. In fact that is the norm in the real world whether its done by scientists, engineers, statisticians (I fall into that group), theologians, politicians...

 

You name it and conclusions based on "not all the info", are drawn all the time. Imagine how the world would be if action was taken on only conclusions reached with all the info. Sure as heck wouldn't need prisons as no one could ever be convicted, medical science wouldn't even exist (almost everything those guys do is based on just educated guesses backed up by incomplete information), heck most science wouldn't exist. We'd still be living in the stone age.

 

In fact having all the info in most situations involving any issue with multiple variables is essentially impossible.

 

Quote

If a problem has existed for 16 years then what conclusions can be drawn about the issue other than:

 

Been reading long? I didn't say no other conclusions could be drawn. Note the word other. I was asking for what OTHER conclusions could be drawn. There are others, certainly, though no one has stepped forward and provided any. 

 

Perhaps if you changed ALL to ENOUGH one could agree with your flawed contention.

 

But enough of this. The problem with AI drivers not being able to keep themselves from driving into water is a known issue and has been for a very long time. Esim has acknowledged it. They haven't fixed it - yet. One hopes that someday they will (fix it) or absent that that we're just told to live with it and to move on.

 

Personally I'll move on but I'll feel like I'm driving a Ferrari with a motor running with a cylinder misfiring.

Edited by Werewolf
Link to comment
Share on other sites

 

We're talking about wonky AI behavior in a computer sim, not trying to find dark matter.  Why are you equating the two?  That's like the Xth time you compare apples to oranges.

 

I did answer your questionmarkless question (you even highlighted it).  How am I wrong when we know someone who can actually provide ALL the information?  Not that he has to because if you did a search, you probably would have found your answer.

Link to comment
Share on other sites

I've been playing SB since its first incarnation, and this has never been a major problem for me. Sure, I've had the odd vehicle end up in the drink. But it never occurred to me to blame eSim for it. I've found that if I'm simply careful about the routes/tactics I give my units, they [usually] do just fine on their own. This applies to plans made in the mission editor, the planning phase and in "real time" in the execution phase. I won't deny that sometimes a vehicle will end up in the water even if I've given all the "right" orders. But, as GSprocket pointed out, this happens in real life, too. Orders aren't always carried out perfectly, and no human is immune to error...why should the AI be any different? Just MHO, YMMV.

Link to comment
Share on other sites

  • Members
On 25.11.2016 at 3:04 PM, Werewolf said:

If a problem has existed for 16 years then what conclusions can be drawn about the issue other than:

 

1. It can't be fixed - if so then just admit it. I'm OKAY with this.

2. It can be fixed but we're unwilling to fix it for business reasons. I'm OKAY with this too.

3. We know about the problem but it's been one for so long that our users have grown so accustomed to it that it really isn't a problem - I'm not OKAY with this. It's like saying that oil leak you've got is not a problem just keep adding oil when the level or pressure gets too low.

 

There's undoubtedly a lot of excuses that can be made but they're still excuses and an excuse is no more than an "attempt to lessen the blame attaching to (a fault or offense); seek to defend or justify."

 

I cannot possibly everything that has been discussed here in the past days; I'm currently with only occasional internet access.

 

So, let me just pick this one post here any respond to that.

 

I will concede that from the end-user's perspective, particularly a long-standing user's, the tally is "16 years, and nothing happened". From my perspective it looks different. "16 years" means going back to SB1 days, and there water simply wasn't a problem. You had to have a water tile surrounded by eight other water tiles to drown a tank. If a water tile bordered land, you could drive on it. And I'm writing "on" because our "water" was just blue painted land.

So, we should maybe only look at the Steel Beasts Pro PE history, so we're only talking about the last TEN years. Still a lot, but 39% less than what the initial statement suggests. ;)

So, here we first began to have a problem because now

  • water was put on ground that was artificially lowered to create the visual impression of a river/lake bed
  • this in turn created the problem of embankments which are a part of the navigation challenge, especially because we had to make the embankments steep at the time to resolve a nasty flickering issue with the water/ground depth sorting when you moved towards a distant water body
  • We put an "air intake" frame to each tank model where the air would normally be sucked in, and made that the limit how deep each tank can go into the water. That is particularly low on the M1, so the experience may be particularly bad here. Not so much with the awesome Leo 2, where the air intake can get switched to the commander's hatch within a few seconds, so you have to completely submerge it to have a problem.
  • This in turn also made the problem a bit more difficult because now we ahve a individual water depth issue for every single vehicle, which makes individual solutions difficult.

So, the tanks we all falling into the water with version 2.251, and people hated it. So we implemented an "avoid water at all costs" rule (that may have happened in version 2.3, or maybe it was 2.4), which people hated even more as they began to have great problems controlling their vehicles in the mere vicinity of water bodies. 

All right, we tried to find a compromise with the next major release, which, I'm not entirely sure, was  either 2009 or 2010. That is, in essence, the point where the work on this stalled for a while. Now, I suppose I could explain why this was stalled - we still had but a single programmer who was on the constant verge of burnout. Also, up until 2008 or so it wasn't clear whether we would actually have a business model with the Professional version that would actually last, or that would allow us to hire more programmers.

 

So, at that point we decided to hire two more programmers, which was in one way of course a great help and really the kind of new direction that we needed, but at the same time pulling in fresh hands means that you lose pace with the work on other features because some of the time is being sunk into familiarizing the new hands with the code base. Also, it required changes in the way how we would write code because now the effort needed to be coordinated among multiple programmers.

After version 2.6 we had a somewhat stable configuration and decided to hire more programmers. Also, Al decided that he was essentially done with programming - a decision that I regret, but which I can also understand very well. So, effectively mid 2012 he asked me to take over the whole team, effectively January 2013. Which somehow coincided with the release of version 3.0.

 

All right, so since 2013 I'm willing to take full blame for everything that happened since then (or didn't happen). We now have five permanent programmers and, since this year, a sixth specialist who does nothing but AI/pathfinding. The problem is that the code has grown somewhat complex over the previous ten years, so it's practically impossible to make minor tweaks to it because these tweaks often have unintended consequences, so you have a cascade of changes that snowball into a huge clusterfuck within a few code iterations.

Rather, we decided that Thomas would work exclusively on infantry related issues first. Once that this area works to our satisfaction - and remember, he effectively only had half a year to change the 3.0 infantry code to what you're seeing in 4.0; from my perspective we made awesome progress in that short amount of time, and we have only started yet. So, once that the infantry does everything that we want from it, the idea is then to transplant that code into the vehicle part, and modify the behavior where necessary. Which, hopefully, will be largely parameter adaptations.

 

At the same time however it is important to keep in mind that SB Pro is first and foremost a TRAINING tool, not a game. We don't mind putting in game elements, as long as they don't get in the way of the training use case. And you WANT computer-controlled units to make mistakes if the user gives stupid orders, to expose that the user didn't actually think about the problem of going in line formation parallel (but close) to a (meandering) river. So, we don't WANT it to be perfect. But that still leaves room for improvement.

 

In conclusion, we demonstrably worked on the issue between 2006 and 2010, and we have resumed working on it since 2016. The "period of passivity" 2010-2016 was actually a very busy time, we just had much more urgent issues to deal with. And now we are working on it again.

Link to comment
Share on other sites

  • 1 month later...

Hi,

Having only played SB Pro for a couple of months (but several hours a day), I don't have the historical perspective of the senior members, but am open to suggestions for a reliable work-around.

 

It's a matter of degree. Losing the occasional vehicle to driver/TC error seems entirely plausible and statistically correct. However when 3 out of 4 NZLAV vehicles, unopposed,  in a marching column, snarl up crossing a simple road bridge and end up FUBAR  in the river, it is a little frustrating. Ditto a single Bradley just pootling along across a railway bridge. Swerve. Plop! At least the grunts can swim ashore to fight another day. The tanks seem to do better than wheeled vehicles in these situations. Moreover it is random enough to require manual intervention on vehicle by vehicle basis.

 

From watching AI controlled  crossings there seems to be a condition of suddenly swerving to the right at discreet points on bridges. It is as if the path-following logic for highways is being *suddenly* applied, even when there is no oncoming traffic or obstruction.  All vehicles do this but the lighter wheeled actors seem to overcook it more often and end up in the drink. This makes bridgelaying on damaged bridge structures a bit of an art as vehicles try to swerve off the treadway span before being safely across. It seems best to lay the treadway to the extreme right hand side of the structure, but the swerve still occurs, even when manually driving from the Observer position.

 

My work around is to hitch five or six of the most skittish (and non-amphibious) PCs, trucks and hummers behind an MBT or M88 and manually drive them slowly over the entire bridge. Even then I have seen hummers jump several meters into the air on reaching the deployed treadway.

 

Help! So when plotting a route that crosses a bridge, what is the optimal position for the points either side, and should the automatically-added points (in red) be left in place?  Is there a tried and tested speed and spacing parameter?

 

In fairness, manually crossing deployed treadways seems a reasonable trade-off for the tactical advantage of having bridge-layers in the sim at all!

 

Lastly has anyone noticed that vehicles on bridges when in-game saves are made, have fallen through the bridge and drowned (unless amphibious!) when the game is reloaded?

 

BTW credit where it is due; the modelling of the rivers and river banks is great. Having to recce the traction available almost metre by metre along the bank to see if you can get out near where you got in adds a whole new dimension to planning! Kudos.

 

Thanks for any shared wisdom.

Trackpin

 

 

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...