When you create a long path for an alterante ware route or while conquering enemy
territory, it is a pain to put down all those flags manually. Not placing flags sucks,
too. It would result in poor ware transport speed.

So I suggest a fast way to build flags: let the game place them automatically
(via
menu):
- create (long) path
- click one flag icon -> "place flag" menu appears
- select "place flags automatically"
- the game creates flags along that path, starting with the flag position the player
clicked

there is plenty of room available in the flag placement menu. I would make the auto flag
placement option small, like the "call scout" option.


This would not be ideal for regular flag placement, where efficiency is most important
and the paths are quite short. However, it would make the conquest phase less of a pain,
when you barely construct any buildings.

---

I personally agree. I would make the algorithm search left and right of the selected flag pos till the next built flag and set one at every possible point.

---
Github: https://github.com/Flamefire

---

I agree that it would be helpful.
However, it seems to me like that would be a function of the path, not the flagpole. I think you should be able to flag a path no
matter where on the path you clicked - even if you clicked on a flagless node. Furthermore, if a path consists of 6 parts and you click
on the middle node, two flags should be placed, not just the one on the node you clicked.

As such, I think it would make more sense to place this in the "snap path"-tab. (which might get a different graphic to become an "edit
path"* tab). It's slightly more efficient as well - If you just buildt the long path, your mouse is at the end flag of that path. You
only need to move it one node to reach a path-node, but two nodes for a flag-node. Furthermore, while "set flag" is a big button, it's
also used very often, so there is a reason why it should stay big. The "snap path" tool is much less used, which also means placing a
new button there would be less intrusive for players who dislike change.


*I'm unsure - isn't manual upgrade of paths to donkey-paths an option in RttR, or was that Generation/Cultures? That would also be a
case of "edit path".

---

Thanks for the input.

You are right! I thought that the player has to tell the game where to put the first
flag, but there is no misunderstanding possible when the player clicks the path segment
next to a flag, too.
About placing the auto flag function in the "edit path" menu: I would not expect it to
be there. Yet I agree that the big "place flag" button should stay big. That is why I
suggested the "auto flag" button to be rather small. Like this:
. _____ . __
|_____| |_|
  flag      af

@ Leartin: manually upgrading paths for donkeys is a new feature in RTTR, yes. But I
have not used it yet.

---

Oh, if I picked up RttR, I wouldn't expect ANYTHING useful in that tab, either. Pretty sure 99% of the cases, I'd snap a way by
removing one of the flags, I wouldn't even remember what was in that tab if it wouldn't have such an indicative icon ;)

But I think these expectations come from having played the game before. If you approach it logically, the tabs are about what you click
on. The magnifying glass comes up on any node, since you can do these things anywhere, the scissors on a node with a path, and the flag
on a node where you can place a flag. Why do you think it should be required to click on a potential flag-node to autoflag the path, an
operation which might not even place a flag where you clicked at?
I would expect to be able to auto-flag a path no matter which node of the path I click on.

Mind, I very well understand the reasoning why you would expect it in the "set flag" tab - because it's literally a function that sets
flags. And your first approach even said that the flag where you clicked was placed first.

I think if it's "Place flags on this path automatically" it belongs to the path-tab, if it's "Place this flag and all others along the
path", it belongs in the flag tab - even though both are "Autoflag", the slightly different behaviour (which players might not even
notice) makes it so they belong in different categories.



I understand that you wanted to go with a design of two different button sizes, but I don't think I like that either. The size of all
buttons always needs to stay the same - or at least, that's how it works for everything else. Eg. if you click on a flag, you normally
have 4 buttons - but 5 if it's at water and only one if it's the hq-flag. I'd assume the code looks how many elements there are and
places them accordingly, so having different sized buttons not only requires additional programming, but is also a break in design
philosophy.
Yeah... most people won't exactly think like that. Take it or leave it, just my 2 cents. :)

---

I would use a concept used before. Originally when you click on a road there are 4 possibilities:
1) Click on a flag -> Build Road, Destroy Flag, Send Geo/Scout
2) Click on HQ flag -> Build Road
3) Click on possible flag -> Place flag, tab with destroy road
4) Click on road -> Destroy road

With the road upgrades 3&4 are changed:
3) Place flag, Upgrade road, tab with destroy road
4) Destroy road, Upgrade road

So IMO there is an inconsistency here in the the upgrade is first in the place flag tab and 2nd in the destroy road tab although it kinda makes sense. I would additionally add it to destroy road or permanently move it there. But whatever having it on the first open tab is a good idea, so no change required.

For auto-flag: It definitely is a "place flag" option so it belongs in that tab. Having to click a possible flag is a good thing because now we solve 2 problems:
a) We assure that clicking auto-flag places at least 1 flag w/o further checks. Otherwise we would have to check the whole path when opening the window if a flag could be placed anywhere.
b) We remove ambiguity. Imagine a path of length 5. Setting flags everywhere w/o specifying where to start results in 2 possible places to place the only possible flag (left or right if the middle). Having to select a free flag first will always start there and set a flag every 2 nodes.

So bottom line: I'd add it to the place flag window between the original button and the donkey upgrade

---
Github: https://github.com/Flamefire

---

I'd argue the donkey upgrade is in the wrong position then, since having it in both tabs is absolutely inconsistent and bad design. In
the flag menu there must be an additional check if it's also a path, and the menu changes based on where you click. Same with AutoFlag.
It also means that AutoFlag is potentially the third button in the flag-placing menu, which is a problem as well. Why not add snap path
in the same tab, too?

Zitat:

That's the thing though. It is in the first open tab if you click on a non-flag path node. Every path has those, so it's not like the
player ever has to switch to a different tab, once they learned how to use that tool. I trust players not to be so stupid not to
recognize.

Zitat:

Sure. But at the same time, usefulness is decreased.
If the flags are set independent of where in the path you clicked, you can use autoflag starting with a path of length 4. If you have
to hit a flag, both length 4 and length 5 would only place that one flag where you clicked, so you can just place that one flag (button
is really big, can't miss it)
At length 6, and any even number above, you get a problem - You might click on an uneven node, causing two pieces of length 3. This is
where the usefulness decreases, since you can mess up any path of even length. This weighs harder for me than the "ambiguity", since
autoflagging would be done in order to not care about their placements, so either result would be fine as long as the number of length-
3-paths is minimized.

Zitat:

You don't need any checks beforehand. As long as it is your path, the button can be there, and it will do exactly what it promises -
place as many flags as possible. That number can be zero. Hence again why it makes sense in the "snap path"-tab, as it would always be
there, consistently.
If you don't like 'useless' buttons, you'd have to perform a path check anyway to see if the path is at least length 6, since otherwise
it would be useless in the set-flag tab. And mind you - having something useless in the set-flag tab is far worse than having something
useless in the snap-path tab.



How about a third option? Instead of allowing to autoflag an existing path, allow a flagged path to be buildt. Since you start the path
on one end, there is no ambiguity. It could be useful even in early game, and it would be neither in the set flag-tab nor in the snap-
path tab.
It would make sense in the flag menu. There are already up to five icons, six is too many - something would need to go in a seperate
tab. I'd make a seperate "naval flag" tab that only appears for naval flags and includes the waterway and, if they ever come to
fruition, bridges. This would play into the original concept of tabs representing different objects on the node (buildplace, flagplace,
flag, path, nothing) and waterways are rare enough that banishing them in a seperate tab wouldn't really matter.

---

Speaking about the 3rd option: If you have this feature, then there is no reason not to always use it. The regular path building would either be never or rarely used.

However usually you would want to at least see what the path build does in influencing the surrounding buildings, hence auto-flagging becomes bad.

So I would build on existing workflows so we don't differ to much from S2 which is the main reason for this whole project. This is also why bridges won't come.
Usually: You start building a path by connecting 2 flags (optionally building the 2nd flag first). Then you may build buildings around that path which themselves set flags. Then you set every possible flag by (double)clicking on it.

So putting the auto-flag next to the flag button makes sense. Especially as the tab is about flag placing.
You are right that the upgrade is wrong. It has to be on the cut-tab not on the set flag tab. This makes the dialog have 2 buttons on each tab which looks good.

Speaking about usefulness: Placing the flags starting from the path in all cases would be bad too in situations where you want e.g. a middle flag although you get 2 3-length paths this way (which you could fix afterwards).

If we have 2 buttons on the set-flag tab you can still double-click on a free flag to place it (the cursor jumps to the button) but also have the option to set all flags (which could be just the one, but why would you move the mouse manually for that?)
So IMO that is the more sensitive option: It is in the tab that says "place flag", does not disturb and is easily accessible (in the 2nd tab you'd need 1 more click)

I do understand the concern about "accidentally creating 3-length paths" but IMO that is the players fault. If we automate to much you could as well just use an AI instead ;) And again: There might be situations where you want that. And last: I'd find it confusing, if I click on a free flag, say "auto-flag" and that flag does not get placed.

---
Github: https://github.com/Flamefire

---