Connected Trench Systems between Allies?

[Renegade]

I'm currently (slightly) reworking the current building-line-drawing logic to allow for multiple trench parts to be built in a single swoop, just like walls or fences.
In the process of this, I had to add checks on which buildings to allow linking with.
One of the checks I added was ownership - you don't want your trenches to link with the enemy's.

However, when coding that particular part, I asked myself: Do I want my trenches to link with my allies'?

It should, on principle, be a very simple modification, and given that raidable buildings should be just as raidable by allies as by enemies, allowing them to link would, in theory, mean that two allies could quickly link up their trench systems and, more or less freely, move around between them.

The same thing will be possible either way if the trenches are built so they touch each other, automatic linking would just save a few clicks. Note, however, that the same check will be used by Ares's firestorm wall extension (not sure if that is currently in use or not), and likely future linkable buildings, so it's not limited to trenches alone. (That is, your own firestorm wall would also automatically connect to your ally's - they would still be activated independently from each other, just the gap would automatically be closed, if possible.)

I cannot foresee how it'll look/work in practice, only tests will tell. In theory, it's a very simple, small, minor change. Even if you do decide for it, if tests show weird problems, we may have to turn it off. Truth to be told, I don't know yet if raiding out of the inside of trenches will work right away (even though I can't see why it shouldn't, from the code), but I very much like that idea, so I'll make it work, if necessary.
So, given that it's a very simple change (build a few extra line pieces if the ally's same structure is near), and it's very easy to implement, it's really only a question of whether you want that or not. The exact same constructs will be able to be built manually, it's only a question of a tiny bit of automation.

And no, given that it's very most likely a one operator, one function change, I will not add another flag to control that. It's a simple question: Do you want me to add that extra exception, or should I leave things as they were?

[Professor_Tesla]

I think that it sounds like a good and logical idea. I'm not sure many modders would want it, though (of course, I'm not saying they wouldn't).

[MRMIdAS]

You can break alliances during netplay though.

this would lead to some weird behaviour, and, unless it's pretty easy to sort, it gets a no vote from me.

[Renegade]

I can't see what "weird behavior" that would lead to.

[Orac]

Breaking alliances would leave you with a sudden link to the enemy, am I correct? It is not entirely a problem, because all players involved have the same chance to get themselves wiped out by the enemy at the other end of the trench. If there was an option, in a similar way to the Build off allied Conyards, a "Build off allied Trenches" button in the multiplayer/skirmish screen then I'd see that as a solution to that "weird behavior".

But it does seem like a really good concept, and would probably make having allies a more attractive thing to have, rather than a parasite who takes all the tech structures and won't give them back

[Renegade]

I think you are misunderstanding the concept of "link". I'm talking about the fact that, when you build a piece of wall, and then build another piece of wall in some distance, the two will be linked with additional wall pieces to form a complete line of wall.
You can achieve the exact same line of wall by building each segment of wall individually, one at a time, at a higher cost.

The same applies to trenches - this is purely about whether to trigger such "auto-lining" also when the previous trench segment is part of an ally's trench system, rather than your own. Just like with walls, you could easily achieve the exact same construct with the exact same features by just building your way there on your own. It'll just be a tiny bit more expensive (one piece more expensive, to be exact).

I'm not asking if I should introduce special logic to do weird inter-ally stuff. I'm just offering an option that'd save you one segment.
To put it in images, what I'm offering is that this
#..........#### automatically turns into
########## rather than you having to build
#........##### first.

That's all it is, really. If you manually build your trenches up to the ally, they'll be connected either way, if you don't want them linked, you can always just block the path or sell the parts.

[Electro]

Code:

Trench.AutoconnectToAllied=yes/no ;much?

[mt.]

Code:

Trench.AutoconnectToAllied=yes/no ;much?

I will not add another flag to control that. It's a simple question: Do you want me to add that extra exception, or should I leave things as they were?

Anyways. I am in favour of this. It will save time while building trenches and firestorm components. And if this linked a part you did not anticipate would be linked, you could just sell the parts you want away (afaik). So yes, it seems to be worth having them connect between allies. As, personally, I believe more often than not this will save time rather than get in the way for players.

[Renegade]

I've added this for now, we'll see how much difference it makes in practice anyway. If it's bad (which I doubt), I can always remove the 66 characters it took to add this.


btw, for those people who continuously insist on crying for a new flag when I explicitly said I wouldn't add one:
I am not adding a new flag when the entirety of the modification is changing

Code:

if(currentBuilding->Owner != targetBuilding->Owner) {

to

Code:

if((currentBuilding->Owner != targetBuilding->Owner) && !currentBuilding->Owner->IsAlliedWith(targetBuilding->Owner)) {

I'm just not. Because all the parsing for a new flag would be twice as complex and thrice as long as the actual change. It'd be complete overkill, serve little to no purpose ingame, and only increase the potential sources of bugs and the number of things to document.

So really: Insisting on a new flag, when I explicitly said that's not an option, only serves to aggravate me - not to convince me to add one.