'HULL DOWN' vs. unknown enemy position?

[Moon]

Sorry Redwolf, just realised that I misread what you suggested earlier ("in LOS of the target point"). Hmm, gotta think about it...

Martin

[Eden Smallwood]

What's wrong with the suggestion we've made before, that SeekHD should take two points as parameters:

Pt1: *Travel* towards this point, but don't go past it.

Pt2: Seek HD *with respect to* this point.

EDIT: Points now listed in proper interface order, as they would occur if implemented as a command similar to Shoot 'n' Scoot.

Eden

[ December 09, 2002, 09:49 PM: Message edited by: Eden Smallwood ]

[Redwolf]

[Edited out: part of the misunderstanding with Moon above]

[ December 09, 2002, 08:22 PM: Message edited by: redwolf ]

[Redwolf]

Originally posted by Eden Smallwood:

What's wrong with the suggestion we've made before, that SeekHD should take two points as parameters:

Pt1: Seek HD *with respect to* this point.

Pt2: *Travel* towards this point, but don't go past it.

The point you plot will likely not be exactly on the movement line. So BFC would have to translate it from a point to a max travel distance, which I assume the engine doesn't fancy. I assume the engine can only take points to travel to, one at a time.

I also guess that BFC would like to avoid two-point commands as much as they can, because they are more difficult to use respectivly make entry into the game more steep.

Personally I would like to have a cover-arc like command where you set an area of operation that the vehicle may operate in, for any command you or the TacAI gives (until "panic" of vehicle).

[ December 09, 2002, 08:27 PM: Message edited by: redwolf ]

[Matias]

Moon,

Just reading your responses has given me a greater understanding of how this command is meant to be used. Watching this conversation ive become convinced that the command works fine, but many people are confused how to use it beacuse a subtle mistake can lead to big time errors.

What do you think of my above suggestion of indicating as you place the seek point wether it is already LOS? Juat a warning with the appropriate note in the manual? I think it would seriously help newbies understand the command.

Also please note that my second suggestion differs slightly from Eden's in that the one way point is movement and seek just like now (no extra code or engine load), the second one is just a dynamic limiter (ideally would be constrained to the original path). Just like the cut off you said was tested but dynamically setable. If you were in a rush you could just double click for same as current behaviour!

[Eden Smallwood]

Redwolf, I don't understand your objection, not even remotely, so I think I haven't made myself clear.

Imagine it works, interface-wise, exactly like Shoot 'n' Scoot- you lay down one point, (the movement-until line), and the other point, (which would have been 'scoot-to') becomes the 'HD with respect to that' point.

The movement point is movement 'up until here but no farther'.

Like we have 'Shoot' and 'Scoot' points, imagine 'Seek-till' and 'wrt' points, respectively. See?

EDIT - Oh! I see it now- when I listed the points in the first post, I wasn't referring to the interface; just listing them. So they came up in the opposite order than they would as a command... I'll go swap them. Sorry!

Eden

[ December 09, 2002, 09:47 PM: Message edited by: Eden Smallwood ]

[Redwolf]

Originally posted by Eden Smallwood:

Imagine it works, interface-wise, exactly like Shoot 'n' Scoot- you lay down one point, (the movement-until line), and the other point, (which would have been 'scoot-to') becomes the 'HD with respect to that' point.

I think I understand what you mean, but I still think it will be difficult to support.

First because you have two points, but they are obeyed to at the same time, so to speak. With scoot-and-shoot you have two points which are sequentially executed one after another. The second point only playes a role after the first is finished. With your suggestion the engine would use both points at the same time, one as a direction indicator, one as a distance indicator.

Second there is still the problem that the second point the player plots will never be exactly on the movement path. So the engine would have to translate it into a distance first and then move the vehicle up to that distance.

having said all that, I like the suggestion but I think it is unlikely that BFC wants to implement it for the current engine.

[Matias]

Ah, I see Eden beat me to it!

What do you guys think of just a LOS indicator while the seek point it being plotted?

[ December 09, 2002, 10:29 PM: Message edited by: Matias Duarte ]

[Eden Smallwood]

Originally posted by redwolf:

I think I understand what you mean, but I still think it will be difficult to support.

Excuse me if I'm wrong, but I still think you don't; part of what you're saying makes no sense to me, ( "never be exactly on the movement path" ??? ) and the other part seems also like a misunderstanding because all the code needed for this is *already in the game now*, (in different places, of course).

Let me try an example; Tank facing north, position zero zero. To give two parameter 'SeekHD' command, do the hotkey, then

*click* : Point One is 100 meters due North; the tank will travel due North a maximum of 100 meters looking for an HD spot.

The cursor still is waiting for the second point of the command, just like when it's waiting for the 'Scoot to?' part of SnS.

*click* : Point Two is on the enemy tank, who happens to be at position 200 meters North, 200 meters East; the position of the enemy has no relationship whatsoever to the direction of travel.

Like SnS, there is a typical case: an SnS path typically would go out, then come straight back- this SeekHD would typically move along vector X looking for an HD spot wrt some enemy who would typically be *in the same direction*, but like SnS, that typical case is not required, it's just typical. Part of the beauty of this idea, I think- it's possible to travel North while looking for a HD spot wrt an enemy who is slightly or grossly to the Northeast.

First because you have two points, but they are obeyed to at the same time, so to speak.

The programmatic stuff you mention is a result my still not being clear, or I don't get it- the interface part of this is exactly like Shoot 'n' Scoot. The code to look for a HD position wrt some other point also exists in the Seek command as it is now. Just splice the SnS interface onto the existing SeekHD code guts...

Second there is still the problem that the second point the player plots will never be exactly on the movement path.

Sure! Just like RL™- if the enemy is at twelve o'clock, but the best looking HD spot for miles around happens to be at one o'clock, that's where I'm headed. If I understand this one.

Well, if we're not on the same page now... what can I say? Matias, you see what I mean, right?

having said all that, I like the suggestion but I think it is unlikely that BFC wants to implement it for the current engine.

Well, yeah... I think you're probably right about that too. But all the meat of the code clearly already *is* in the game... *sigh*

Eden

[Dschugaschwili]

Originally posted by Matias Duarte:

What do you guys think of just a LOS indicator while the seek point it being plotted?

Why don't you just check this manually with the LOS tool?

I never had problems with this command so far. If you only use this command when you're out of LOS to the target point and you're sure that your tank can see the target point from the estimated hull-down position, you can't go totally wrong. You can temporarily issue an area target order to the target point and follow the line on the map to make judging the second part easier.

Dschugaschwili

[Hat Trick]

From Moon:

Obviously some kind of check if there is a possible HD position along the path at all when the order is entered would help

Actually, I'm not sure that I agree. I mean, it would help the player, but I don't think that it is realistic. In real life a tanker may think that there is a hull down position up ahead, but he may not know for sure until he get there.

[Redwolf]

Originally posted by Hat Trick:

From Moon:

</font><blockquote>quote:</font><hr /> Obviously some kind of check if there is a possible HD position along the path at all when the order is entered would help

Actually, I'm not sure that I agree. I mean, it would help the player, but I don't think that it is realistic. In real life a tanker may think that there is a hull down position up ahead, but he may not know for sure until he get there.</font>

[Matias]

Eden, I totally see what you are saying. Now that I understand it better my gut tells me that would be even less work to implement than my idea because the UI plot of the second point would be completely unconstrained. I think it'd also be much more flexible / powerful - but it'd be kinda redundant with a cover arc (what would happen if you moved east, seek pointed north, but covered arc south? Obviously one or the other would have to be cancelled - though I guess this is actually the case today)

My twist (seek point first, limit second) is more limited and more interface work but possibly less underlying engine work...

Course none of these suggestions allows me to seek hull down in reverse... *carefully opens can of worms*.

As for my main suggestion : Indicate LOS please! And why would anyone want it?

1) it makes it easier for people who're trying to understand the command. Especially non grogs for whom CMBB is intoducing the hull-down concept.

2) it saves mouse clicks (one step instead of two)

3) it prevents errors ( I check LOS, but then I accidentally place my seek point a few eters further away - no grid you know, I'm just eyballing this - and oops it was already in LOS so my forces wander into the open)

Moon?