[GO] Unlimited Adjacent Fortification

[Metsfanmax]

[In B4 merge, as the saying goes.]

Great success. Merged.

[PapaGeek]

Concise description:

• Add an additional Reinforcement option called “Trench”

Specifics/Details:

• The concept of Trench warfare is that you can only advance your entire front line one region per turn. It is based on old fashion warfare where you did not have highly mechanized methods of moving or advancing your troops. Let’s expand the trench concept to include the way you would reinforce your front line. Unlimited allows you to move reinforcement long distances which does not follow the old fashion trench concept. Adjacent is closer to the concept, but slows things down since you can only do one reinforcement per round.
• What if we expanded adjacent to work like the trench concept? All reinforcements would be both adjacent and unlimited. Once you advance troops to an adjacent region, you can not advance them again, the 'advanced to' region is restricted from being an 'advance from' region.

How this will benefit the site and/or other comments:

• This would make trench game move faster without violating the trench concept.
• You could maintain a line of reinforcements behind your trench line and move the entire reinforcement line forward at the same rate as the front line
• In my opinion this would better emulate the trench warfare concept

[Kaskavel]

Has been suggested before under something like "unlimited adjacent". It is a logical suggestion and a natural evolution of the current settings. I ignore the reasons it has not been accepted.

[PapaGeek]

Has been suggested before under something like "unlimited adjacent". It is a logical suggestion and a natural evolution of the current settings. I ignore the reasons it has not been accepted.

Thanks Kaskavol, it was interesting to read the 2 threads that asked for basically the same thing back in 2006 and 2007.

Most of the comments back in 2006 and 2007 were that the concept was too confusing, and many did not understand it and thought that unlimited adjacent was just like unlimited except it would take you longer to get there. One of the retired admins also added that it would be too hard to program.

All of those comments may have been true in 2006 and 2007, but CC has implemented Trench warfare since then.

Once you understand Trench Warfare, the concept of “unlimited adjacent” or Trench Reinforcement is no longer confusing, it is very similar to Trench Warfare. It might also be a good idea to limit Trench reinforcements to only trench warfare games, or, state that adjacent reinforcement has a special meaning in trench games, it also becomes “unlimited” when playing a trench game.

And a note to the current and retired admins, the programming has already been done for trench. Once you advance an army in a trench game, that region is flagged in such a way to say you can’t advance “from” there again. Since the programming has already been done for the attack mode, just duplicate it for the reinforcement mode, same logic!

[Metsfanmax]

And a note to the current and retired admins, the programming has already been done for trench. Once you advance an army in a trench game, that region is flagged in such a way to say you can’t advance “from” there again. Since the programming has already been done for the attack mode, just duplicate it for the reinforcement mode, same logic!

It is more complicated than that. What if you have troops that were already on the target destination that you want to move? We don't want to count on the user to have to know that they need to move the ones already there before they can reinforce to there.

[Dukasaur]

And a note to the current and retired admins, the programming has already been done for trench. Once you advance an army in a trench game, that region is flagged in such a way to say you can’t advance “from” there again. Since the programming has already been done for the attack mode, just duplicate it for the reinforcement mode, same logic!

It is more complicated than that. What if you have troops that were already on the target destination that you want to move? We don't want to count on the user to have to know that they need to move the ones already there before they can reinforce to there.

When a territory is transferred into, it is flagged and cannot be transferred out of on that turn. If there are any troops in it prior to that transfer, they are locked in, but if the player thinks ahead and wants to use those troops, he can transfer them out before transferring any in.

[Metsfanmax]

And a note to the current and retired admins, the programming has already been done for trench. Once you advance an army in a trench game, that region is flagged in such a way to say you can’t advance “from” there again. Since the programming has already been done for the attack mode, just duplicate it for the reinforcement mode, same logic!

It is more complicated than that. What if you have troops that were already on the target destination that you want to move? We don't want to count on the user to have to know that they need to move the ones already there before they can reinforce to there.

When a territory is transferred into, it is flagged and cannot be transferred out of on that turn. If there are any troops in it prior to that transfer, they are locked in, but if the player thinks ahead and wants to use those troops, he can transfer them out before transferring any in.

Yes, that was anticipated by my comment

We don't want to count on the user to have to know that they need to move the ones already there before they can reinforce to there.

Besides, imagine playing a speed or freestyle game with these settings and trying to mentally keep track of which order you need to reinforce in with 9 seconds left on the clock.

[BigBallinStalin]

I'm gonna push aside Mets concern by having faith in enough users to figure this out.

Onward! To TRENCH UNLIMITED ADJACENT FORTS!!!1--a.k.a. TUA forts.

[PapaGeek]

It is more complicated than that. What if you have troops that were already on the target destination that you want to move? We don't want to count on the user to have to know that they need to move the ones already there before they can reinforce to there.

When a territory is transferred into, it is flagged and cannot be transferred out of on that turn. If there are any troops in it prior to that transfer, they are locked in, but if the player thinks ahead and wants to use those troops, he can transfer them out before transferring any in.

Besides, imagine playing a speed or freestyle game with these settings and trying to mentally keep track of which order you need to reinforce in with 9 seconds left on the clock.

What if you are playing a 1 minute speed game on the First Nations Americas map? And what if it is unlimited reinforcements? If you sign up for that game, live by the rules. There are already almost impossible combinations for speed games!

The point here is a way to make Trench games better imitate an old WWI battlefield. Let the reinforcements match the movement of the front line.

[Kaskavel]

And a note to the current and retired admins, the programming has already been done for trench. Once you advance an army in a trench game, that region is flagged in such a way to say you can’t advance “from” there again. Since the programming has already been done for the attack mode, just duplicate it for the reinforcement mode, same logic!

It is more complicated than that. What if you have troops that were already on the target destination that you want to move? We don't want to count on the user to have to know that they need to move the ones already there before they can reinforce to there.

When a territory is transferred into, it is flagged and cannot be transferred out of on that turn. If there are any troops in it prior to that transfer, they are locked in, but if the player thinks ahead and wants to use those troops, he can transfer them out before transferring any in.

Yes, that was anticipated by my comment

We don't want to count on the user to have to know that they need to move the ones already there before they can reinforce to there.

Besides, imagine playing a speed or freestyle game with these settings and trying to mentally keep track of which order you need to reinforce in with 9 seconds left on the clock.

I do not think you understood each other, and it would not work like that anyway. If a region has 3 troops and you reinforce there 5 more troops, then the game will allow you to reinforce only 2 troops from there, the "old ones"

[Dukasaur]

It is more complicated than that. What if you have troops that were already on the target destination that you want to move? We don't want to count on the user to have to know that they need to move the ones already there before they can reinforce to there.

When a territory is transferred into, it is flagged and cannot be transferred out of on that turn. If there are any troops in it prior to that transfer, they are locked in, but if the player thinks ahead and wants to use those troops, he can transfer them out before transferring any in.

Yes, that was anticipated by my comment

We don't want to count on the user to have to know that they need to move the ones already there before they can reinforce to there.

Besides, imagine playing a speed or freestyle game with these settings and trying to mentally keep track of which order you need to reinforce in with 9 seconds left on the clock.

I do not think you understood each other, and it would not work like that anyway. If a region has 3 troops and you reinforce there 5 more troops, then the game will allow you to reinforce only 2 troops from there, the "old ones"

Well, I did think of that possibility, but I personally wouldn't do it that way. Of course I don't know much about how these new computers work, but when I was programming databases I would have handled this with a single-bit logical register. Your method requires it to store a (two-byte) integer. That's sixteen times more space to tie up. Might not sound like much, but multiplied by the thousands of ongoing games, it's a lot of wasted space. The tiny improvement in convenience probably doesn't justify it.

[PapaGeek]

The technical method used to implement something like this would be up to the admins and developers. As a computer geek, like my name says, I know there are multiple ways it could be done. Not knowing the code, it is not possible to say which would be easier and more trouble free to implement.

The main purpose of the suggestion was to implement a reinforcement option that parallels the concept of trench warfare.

[JamesKer1]

The technical method used to implement something like this would be up to the admins and developers. As a computer geek, like my name says, I know there are multiple ways it could be done. Not knowing the code, it is not possible to say which would be easier and more trouble free to implement.

The main purpose of the suggestion was to implement a reinforcement option that parallels the concept of trench warfare.

viewtopic.php?f=535&t=61323

Just for maximum clarity, these are the same suggestion correct? Im not merging yet since some aspects are being hashed out and it's better in the open than in submitted, but I just wanted to clarify for when it is a good time.

[PapaGeek]

Yes, I would say that both suggestions are basically for the same thing.

8 years ago when the “unlimited adjacent” suggestion was made CC had not yet introduced the concept of “trench” warfare. Back then the suggestion was shot down because the concept was too complicated. CC users did not have the experience of trench warfare as a guide to understanding “unlimited adjacent”, the term unlimited was confusing to many of those who replied to the original thread.

When I did my research on if the suggestion was already made, I did not find this 8 year old thread. I guess that the only new thing my thread has to offer over the previous one is to call it “trench” reinforcements to parallel the warfare style we have already grown to understand.

So, as the author of this thread, I vote yes for the merge!

[Dukasaur]

Sounds good!

[Kaskavel]

Bump

[iAmCaffeine]

Bump

Bumping a bump.