AGEOD Forums

This is odd/counter-intuitive behavior:

• Select a unit [let's call it "unit #1"] and target a distant stack of units [let's call it "stack #2"] as the destination;
• It's a few moves away, so use rail movement;
• Meanwhile, select unit(s) [let's call them "unit(s) #3"] in the destination stack ["stack #2"] and move them somewhere else (leaving one or more units behind, since it's the destination target for the above unit ["unit #1"]);
• The original moving unit ["unit #1"] now targets the new unit/stack ["unit(s) #3"] destination, forgetting the original one ["stack #2"] (I've also seen it just stop moving).

This can have really bad consequences, such as the original unit getting stuck in the middle of a lake/ocean region, running out of supply, and disappearing.

I also notice that a new unit/stack taken from an existing one "inherits" the rule of engagement (RoE) posture.
Looks like the destination target status also transfers.

MikeV wrote:This is odd/counter-intuitive behavior:

• Select a unit [let's call it "unit #1"] and target a distant stack of units [let's call it "stack #2"] as the destination;
• It's a few moves away, so use rail movement;
• Meanwhile, select unit(s) [let's call them "unit(s) #3"] in the destination stack ["stack #2"] and move them somewhere else (leaving one or more units behind, since it's the destination target for the above unit ["unit #1"]);
• The original moving unit ["unit #1"] now targets the new unit/stack ["unit(s) #3"] destination, forgetting the original one ["stack #2"] (I've also seen it just stop moving).

This can have really bad consequences, such as the original unit getting stuck in the middle of a lake/ocean region, running out of supply, and disappearing.

I also notice that a new unit/stack taken from an existing one "inherits" the rule of engagement (RoE) posture.
Looks like the destination target status also transfers.

The first one is especially bad when you are swapping elements between stacks in two different regions. The next turn results in both units being in the original stack, one unit having just made a u-turn back into the stack it just left.

MikeV wrote:This is odd/counter-intuitive behavior:

• Select a unit [let's call it "unit #1"] and target a distant stack of units [let's call it "stack #2"] as the destination;
• It's a few moves away, so use rail movement;
• Meanwhile, select unit(s) [let's call them "unit(s) #3"] in the destination stack ["stack #2"] and move them somewhere else (leaving one or more units behind, since it's the destination target for the above unit ["unit #1"]);
• The original moving unit ["unit #1"] now targets the new unit/stack ["unit(s) #3"] destination, forgetting the original one ["stack #2"] (I've also seen it just stop moving).

This can have really bad consequences, such as the original unit getting stuck in the middle of a lake/ocean region, running out of supply, and disappearing.

I also notice that a new unit/stack taken from an existing one "inherits" the rule of engagement (RoE) posture.
Looks like the destination target status also transfers.

By removing a unit from the destination stack, you may have changed the name of the stack. It's best to divide the destination stack first, then set the moving stack #1 to target the destination #2.

moni kerr wrote:By removing a unit from the destination stack, you may have changed the name of the stack. It's best to divide the destination stack first, then set the moving stack #1 to target the destination #2.

Thanks for the (hopefully, temporary) work-around ... while they fix the bug.

I'm not sure it is a bug. In several of these threads the devs explain that they use the names of the stacks for a number of purposes. If so it makes sense that if you, inadvertently, changed the name of a stack, or split stacks and moved the one with the surviving name, that the move order would target either nothing or the stack that retained the name.

Well, such subtle and error-prone behavior is a mis-feature, at best. It needs to be fixed.

MikeV wrote:Well, such subtle and error-prone behavior is a mis-feature, at best. It needs to be fixed.

Not really. It means you have to be careful. It also gives a more realistic flavour to the game.

There are an awful lot of historical examples of commanders misreading or misunderstanding clear orders, never mind having to interpret vaguely written or contradictory orders.

Fair enough. But this software doesn't seem to simulate the actions of staff, councils of war, etc.
What I've encountered is a GUI design bug. Nothing more.

this is only a problem if you try to intercept/follow one of your stack. The code when you do that, picks a unit at random in the target stack, and will try to follow it. if the unit you detach from the stack is the unit picked by the code, then it will follow this one.
I fear this can't be changed easily, sorry.

Understood. Thanks for the explanation.

It occurs to me that the design is missing a few Key Abstractions.
The most important one is the Theater/Army/Corps/Division chain of command, as it existed in the Industrial Era.
Using the "unit stack" as a proxy for it, with all the special-case rules around naming, leadership, merging, fleet transportation, etc., stem from this.

What surprises me is that, conceptually, this is a garden variety "has-a" tree hierarchy (think bill-o-materials parts trees).
Although not supported directly in STL, it's reasonably easy to implement.

The truth is that it goes much beyond having the right classes in the proper library. You have to consider what people can cope with, and already many find the command structure complex enough. Also, 90% of the time (for the coder) will be spend on the gameplay revolving around handling the various echelons of the hierarchy, and not actually using containers, Russian-dolls style, to implement the hierarchy.

Fair enough, although it certainly should start with appropriate data structures (cf N. Wirth). It seems to me the key part of GUI design is making the Key Abstractions readily apparent, and directly manipulated in a way that is reasonably intuitive for the expected user. For that latter part, it seems wise to lean on their familiarity with similar systems (in this case, other games aimed at approximately the same level of concern: strategic/operational/tactical).

Pocus wrote:this is only a problem if you try to intercept/follow one of your stack. The code when you do that, picks a unit at random in the target stack, and will try to follow it. if the unit you detach from the stack is the unit picked by the code, then it will follow this one.

OK, I've been playing around with this for a bit. Basically, the workaround is to target a destination region (a bit tricky in small and/or crowded regions, but workable) rather than unit stack. Unless you are sure you're not going to split off anything from the target/destination stack.