Here is how bad the movement code actually is, and it's not just "pathfinding"

[Redwolf]

Originally posted by sandy:

I never use fast - quick, hunt or move only

I get this sort of bad movement rubbish all the time.

For God's sake people, stop making excuses for an unfinished disappointment.

Who would have preordered knowing what we know now?

I can only repeat that I don't regret pre-ordering the big package. Failing everything else it is a downpayment for a virtually more expensive CMx2.2. Fine with me.

There is a problem, however, and that is that BFC likes this kind of thing: when a mechanism to simulate some exceptional situation can be implemented, then BFC implements it and then sticks to it no matter whether the outcome is more, less or much less realistic than just turning the mechanism off.

I hope people understand we are not dealing with a bug here. We are dealing with a design decision, with the principal question of whether you simplify when some detail didn't work out, or whether you leave in the broken detail. The latter might be unrealistic but the former makes the game unplayable and isn't realistic either. There is nothing realistic about an AFV driving forward turning it's rear armor to the enemy, and none of the blah-blah in this forum can change this.

Since the CM:SF release Steve's postings indicated that BFC is now more willing to bulge on some of these questions. That's good.

But the situation is critical, IMHO. This time the whole thing can die as people outside the apologists in this forum shake their heads, and that includes former CM players. And then my downpayment for a future CMx2 wouldn't be very well-invested, would it?

The game needs to become more playable. And I don't mean that somebody gives me instructions of the form "after 83 meters of fast move, when approaching a 62 degree right turn, switch to slow movement 17 meters before the turn point and split up the turn into one 41 and one 21 degree turn". That doesn't count. This level of micromanagement is way below the scope of the game. A couple years ago people got flamed on this forum for plotting this precise in CMx1 as "gamey". Now the same people flaming at the time ask of me to do do exactly the same.

[Elmar Bijlsma]

But there are very few denying there are problems with path finding. Certainly non on the beta team that I know. So I don't really get the attitude of persecution in this thread. The 'oh, why is no one listening to me' attitude can really annoy when I wager a majority are most certainly listening.

I can understand you want to give an extreme example of the problems you are seeing. But acknowledge it as such. Don't go around pretending (not you) that it's representative of what's going on. That's just dishonest. And if Redwolf hat bothered to use that same parcour with SLOW movement he would perhaps have given more credit to people like me telling him that going FAST most certainly is part of the problem.

[Huntarr]

um all I pointed out was that you might have used FAST not MOVE.

kidding my feeling aren't hurt

[Darren J Pierson]

Originally posted by Elmar Bijlsma:

But there are very few denying there are problems with path finding. Certainly non on the beta team that I know. So I don't really get the attitude of persecution in this thread. The 'oh, why is no one listening to me' attitude can really annoy when I wager a majority are most certainly listening.

I can understand you want to give an extreme example of the problems you are seeing. But acknowledge it as such. Don't go around pretending (not you) that it's representative of what's going on. That's just dishonest. And if Redwolf hat bothered to use that same parcour with SLOW movement he would perhaps have given more credit to people like me telling him that going FAST most certainly is part of the problem.

I'm not sure how FAST affects the AI's decision to turn the vehicle's rear towards the enemy. I'm not saying it doesn't affect it, I just don't see how? Or is the vehicle going so fast that it is supposed to be spinning out?

[thewood]

I think Fast just magnifies the problem. I see the same thing with Move, just not as consistently.

[dalem]

Originally posted by kipanderson:

Hi,

Why do people go on, and on, and on…. with negative posts and threads.

Obviously, because we're disappointed.

-dale

[pad152]

RedWolf

Nobody hates tank dancing more then me and I don't think anyone is happy with the current unit pathfinding & movement but, let's give BF a chance with a few more patches.

[Redwolf]

Don't make me re-run all this in non-fast...

Elmar, there is very thick skin involved here on all sides.

Later, let's say in 2 years, I don't want to be in a position where something is wrong and I say "this has been in CM:SF 1.02, why isn't it fixed". And people reply "yeah but you should have presented a real test case, with screenshots and savegames, maybe it would have gotten fixed then".

Does it look intense? Sure. Doing the math or presenting actual evidence is always considered an impolite thing to do in an argument. How many people here already said "yeah, that is what I have been seeing all along, thanks for providing a test case"?

Originally posted by Elmar Bijlsma:

But there are very few denying there are problems with path finding.

No, but there are many who do not or do not want to understand that all the bad pathfinding and TacAI would be much less of a hassle if it wasn't invoked needlessly. What needs to be done is turn off some of the more bizarre gizmos and replace them with simpler mechanisms (such as just slowing down in this example) so that you can then go code-fixing on the other cases

There is no way that Charles can right now hack up all the technical bugs (graphics, PBEM, the stuff for 1.03) and then later magically come up with great TacAI and great pathfinding. In what time? He's a single programmer and he just released a later game, that means he didn't have vacation for at least a year. It's not realistic.

[ August 24, 2007, 03:01 PM: Message edited by: Redwolf ]

[Elmar Bijlsma]

Originally posted by Darren J Pierson:

I'm not sure how FAST affects the AI's decision to turn the vehicle's rear towards the enemy. I'm not saying it doesn't affect it, I just don't see how? Or is the vehicle going so fast that it is supposed to be spinning out?

But it's not turning it's rear to the enemy. It has no clue where the enemy is. What's happening is that it misses it's intended path because of a too high a speed and too sharp a turn. In an effort to get back on track it may do just about anything, which sadly includes some totally bizarre things. That's the real problem: Not that it can't follow the path, but that the corrections to undo the user induced swerve (or whatever you call it) can have some bizarre and counter productive results.

[flamingknives]

For the love of all that's holey, can someone please re-run the test using move rather than fast? Possibly with additional waypoints, or different speeds. I can't as I am stuck with an old Mac.

If I can use a mechanical engineering example, this is like someone turning up with a broken carbon-fibre driveshaft and saying "Mr Engineer fix or do somefink"*. Obviously something has broken it, but without better information we can't tell what.

Extreme examples are all very well, but they are an incomplete picture so are only partially usable in defining the root cause.

* As it happened, they'd fixed the end couplings on using an interference fit and a hammer.

[thewood]

While I can understand we want to help BFC. I think a bunch of us have run test after test, for our own benefit. At some point, I hope BFC takes our input that points at a problem and runs thier own test. Otherwise they might as well declare this officially a beta test.

[The DesertFox]

Originally posted by thewood:

Otherwise they might as well declare this officially a beta test.

Haven´t you already realized that this is indeed what happens here ???

[Elmar Bijlsma]

Originally posted by thewood:

I think Fast just magnifies the problem. I see the same thing with Move, just not as consistently.

I disagree, because the thing you guys think is the problem isn't. It's when it fumbles MOVE when it's a problem for me. Because IMO the vehicle getting off course isn't the problem. It's the vehicle fumbling attempts to get back on course that are the problem. However, MOVE gets off course at times where it probably shouldn't and then to add insult to injury drops the ball trying to correct. A doubly whammy of navigational madness.

Thus MOVE is the real problem child, FAST and QUICK work reasonably well by comparison.

[Chelco]

Originally posted by "guy who actually rode in a Bradley":

Also, I can find you some pictures of what a Bradley would do if it was moving at full speed and attempted those turns you plotted. Let's just say that they can get sideways, completely sideways, like flipped-over-on-the-side-sideways.

And the answer to that is:

Originally posted by "other guy"

No. It would slow down before the turns, do the turn, then re-accelerate.

Now I've seen it all.

This is completely out of control.

Hilarious.

Enjoy the weekend proving your points.

[ August 24, 2007, 03:26 PM: Message edited by: Chelco ]

[thewood]

Originally posted by Elmar Bijlsma:

</font><blockquote>quote:</font><hr />Originally posted by thewood:

I think Fast just magnifies the problem. I see the same thing with Move, just not as consistently.

I disagree, because the thing you guys think is the problem isn't. It's when it fumbles MOVE when it's a problem for me. Because IMO the vehicle getting off course isn't the problem. It's the vehicle fumbling attempts to get back on course that are the problem. However, MOVE gets off course at times where it probably shouldn't and then to add insult to injury drops the ball trying to correct. A doubly whammy of navigational madness.

Thus MOVE is the real problem child, FAST and QUICK work reasonably well by comparison. </font>

[Elmar Bijlsma]

Originally posted by Redwolf:

Don't make me re-run all this in non-fast...

Oh I won't make you. I did them myself. No real difference in FAST and QUICK (in behaviour and speed over short legs) MOVE might do anything, sometimes running the parcour very well (except for the truly tortuous turns) but sometimes it completely fumbles a slight turn for no real reason. SLOW is always the little dear, nicely following the waypoints.

Elmar, there is very thick skin involved here on all sides.

Later, let's say in 2 years, I don't want to be in a position where something is wrong and I say "this has been in CM:SF 1.02, why isn't it fixed". And people reply "yeah but you should have presented a real test case, with screenshots and savegames, maybe it would have gotten fixed then".

Does it look intense? Sure. Doing the math or presenting actual evidence is always considered an impolite thing to do in an argument. How many people here already said "yeah, that is what I have been seeing all along, thanks for providing a test case"?

But it would helpful if the evidence is representative of the problem, don't you agree?

</font><blockquote>quote:</font><hr />Originally posted by Elmar Bijlsma:

But there are very few denying there are problems with path finding.

No, but there are many who do not or do not want to understand that all the bad pathfinding and TacAI would be much less of a hassle if it wasn't invoked needlessly. What needs to be done is turn off some of the more bizarre gizmos and replace them with simpler mechanisms (such as just slowing down in this example) so that you can then go code-fixing on the other cases.

There is no way that Charles can right now hack up all the technical bugs (graphics, PBEM, the stuff for 1.03) and then later magically come up with great TacAI and great pathfinding. In what time? He's a single programmer and he just released a later game, that means he didn't have vacation for at least a year. It's not realistic. </font>

[Battlefront.com]

Redwolf,

There is no way that Charles can right now hack up all the technical bugs (graphics, PBEM, the stuff for 1.03) and then later magically come up with great TacAI and great pathfinding. In what time? He's a single programmer and he just released a later game, that means he didn't have vacation for at least a year. It's not realistic.

He hasn't had a vacation for 3 years, but I don't think that has much to do with anything. Neither does your supposed insights into how easy/hard these things are to fix.

v1.03 will be out VERY shortly. People can judge for themselves how quickly stuff can be fixed.

Steve

[wunwinglow]

Whatever the causes, isn't the problem simply that the vehicle in the game is not doing what a real vehicle being driven by a human driver would do, or try to do. It is this mismatch between the players authority to issue orders, and the ordered units behavior while trying to follow those orders. A real unit would NOT get orders dictating speeds, accelerations and turn radii. It would be told to go from here to there, via this road, behind this feature, and the crew would sort out the finer details. The reason I have found this game to be rather more frustrating than enjoyable, is that units sometimes don't do what they are told to do. But far worse, when they CAN'T do something and need to come up with an alternative, it is NOT what a human driver would do in real life. And so the illusion is broken; and thats the point I start to loose interest.

This will get fixed, of course, but I'm going to pass on the game until a few more patchs are done. I'm glad I bought it, if only to show my support for the team, but I'm not playing it at the moment; just too frustrating.

Tim

PS I think Charles deserves a holiday!!!

[thelmia]

I just wish my units would do what I tell them to do. I only give one movement order at a time to avoid this as much as possible. It's still a problem.

I want my Stykers to fire when I tell them. I want my vehicles to fire the weapon I want them to fire. I want my soldiers to enter the building where I told them. I want to be able to fight the enemy rather than the interface. Lastly, I want to be able to play with other people.

Whether I win or lose should be due to my skill, not a random bug or too much lag. Right now, I don't actually play this game. The game kinda plays against itself. I don't feel like I'm actually in control.

[Darren J Pierson]

Originally posted by Elmar Bijlsma:

</font><blockquote>quote:</font><hr />Originally posted by Darren J Pierson:

I'm not sure how FAST affects the AI's decision to turn the vehicle's rear towards the enemy. I'm not saying it doesn't affect it, I just don't see how? Or is the vehicle going so fast that it is supposed to be spinning out?

But it's not turning it's rear to the enemy. It has no clue where the enemy is. What's happening is that it misses it's intended path because of a too high a speed and too sharp a turn. In an effort to get back on track it may do just about anything, which sadly includes some totally bizarre things. That's the real problem: Not that it can't follow the path, but that the corrections to undo the user induced swerve (or whatever you call it) can have some bizarre and counter productive results. </font>

[Guest]

Except for taking a few days off when my (most recent?) son was born and time off for surgery, I haven't had a vacation in about three years either (this includes no time off for Christmas, etc). I think that's just how programmers roll, man.

BFC... I thought Redwolf was trying to cut Charles some slack. At least, if someone said the same about me, I'd take it as such.

I'm definitely looking forward to 1.03. In fact, now I'm excited about it.

As for everybody else, I think BFC is taking our reports into account regardless of whether or not we've covered all of the possible variables. It's all useful info. It's when we all start frothing at the mouth that things go downhill.

If pathing works poorly on Fast, why not post a detailed account of it? Kudos to Redwolf. If you think it would work better on other settings, do the test and post your results, don't just rip on the OP.

[Battlefront.com]

Hi Phillip,

BFC... I thought Redwolf was trying to cut Charles some slack. At least, if someone said the same about me, I'd take it as such.

Yeah, I didn't mean to sound as put off as I did (just reread my post, but I don't want to edit it because that's cheating ). My point is that we're going to fix what is broken because that is what we are obligated to do, history of vacations not being relevant

I do think, though, that people are overestimating the bugs in terms of how difficult they are to fix. Sometimes the most nasty, horrible, terrible bugs that seem to never get fixed are the result of a typo in the code (I am sure you know about this!). So that horrid thing that everybody thinks is so difficult to fix was in fact a "piece of piss" to correct. The problem was finding it, not actually fixing it.

One of the worst pathing problems, for example, was traced back to something that wasn't getting reset propperly. Nothing wrong with the structure of the code, just a variable not being set correctly. This fixed something like a half dozen "different" bugs we were trying to get nailed down.

The problem was this thing was extremely sensitive to specific conditions so it took a awhile before it was caught in a save game file. Once it was found it was fixed within minutes. Now tons of odd little things that were happening melted away.

To the customer this could look like a huge stack of completely seperate bugs that would take weeks, if not months, to fix. But in fact it was fixed within a few minutes. That's the joy of programming, right Phillip?

Steve

[Bradley Dick]

My hat is off to ANYONE who programs for a living. I'm in the process of taking some low level college courses on programming.... and I F*ing hate it. I'm still on the "Create an interactive ATM prompt" and it is pissing me off.

More power to all you brave bastards who sit in front of a PC tracking down a "p" that should have been a "P".

[thelmia]

Oh God, I would never program. I'd rather dig ditches. I'm not kidding.

[Guest]

It is indeed fun to find that one line that fixes multiple issues.

Very frustrating, too, especially when those half-dozen things cause massive consternation, possibly for months or even years. In the case of my industry, those half-dozen things might even spawn a number of lawsuits, or at least the loss of a large amount of money.

As for overestimations... I tend to view those as a boon, truth be told. Still, I've been in situations similar to yours and overestimations can hurt rather than help. I'll try to lay off estimations myself here on the forums. I may know game programming in general and AI work in particular, but that doesn't mean I know how long Charles will take to fix something.

Thanks, and cheers.

Edit: Oh, and thanks in general to the guys who acknowledge the difficulty of programming. It's true that it's a difficult job for a number of reasons, some of which are nearly impossible to explain. Always nice to hear some support.

It's also a very difficult job, though, as Steve (and Charles) can probably attest to, to manage and direct development, especially with an active and changeable userbase. Kudos to the BFC team in general.

[ August 24, 2007, 05:34 PM: Message edited by: Phillip Culliton ]