Implement base siege

[Jikoo]

Siege needs to be ported from GP into a functional addon.

[TomLewis]

Hello Jikoo, Did you still want me to publish my documents here for how siege currently works and then the plans I had for an improved siege?
I could also link to my old 1.12 repo that forked GP with a bunch of siege extras and improvements.

I think the Steps should be:

1. Get a working port, the same as whats built in with the couple of basic improvements we made at PirateCraft
2. Big update, One with a database to record all sieges for matchmaking to stop top level players just dominating new players.

[Jikoo]

That would be lovely, yes.

My plan was to use my GP fork to figure out what needs to be exposed to fully strip Siege. Things like the warning about TNT, etc. where GP doesn't send a message specifically because a siege is active need extra retooling because there's no good way to stop GP from messaging players externally. Several hacks for sure, but none that are clean and will play well with other addons.

[TomLewis]

Cool, sorry I forgot to reply to this, We had it written up on a Google Doc, heres a link:
https://docs.google.com/document/d/1NfHAkemrMKOj6EC89mSc--Ba3Do3EBO1qOhjHTDDAkY/edit?usp=sharing

[TomLewis]

Any luck with getting siege to work separate from GP?

[Jikoo]

Not yet, sorry. I've made some small progress, but I've been mostly working on other projects.

[TomLewis]

Alright, well give me a ping if you wanted any testing to happen or wanted to brainstorm ideas.

[Jikoo]

Was doing some more work on this and compared to the doc - the doc mentions that multiple people are allowed to siege a single claim/person, but that is not the case with default GP (or if it is, it's a bug).

With that in mind, since multi-user sieges sound like a good thing to support, the entirety basically has to be rewritten from scratch.

So far the rough ideas driving the design:

1. Sieges are initiated by a user targeting another user

• Targeting user ("initiator") must be near the defender ("target") and a claim eligible to be included in the siege

2. Initiator and target are the team leaders

• Maybe: If either is disqualified, the siege resolves
• Alternately: On DQ, player is banned from further participation. Entirety of one side must be DQed to lose.
  • Not allowed to participate in PVP (either as attacker or defender) with other team members
  • Not allowed to access any containers, place/break blocks, etc. until resolution
    • Possibly need special consideration for TNT outside of claims so DQed can't help by reloading cannons
  • Opens up the possibility of griefing someone by arranging a siege to lock them out of their claims for <siege max duration>
    • Player1 and Player3 prepare to grief Player2. Player3 creates a claim near Player2 and trusts them. Player1 sieges Player2. Player1 kills Player2. Player2 is locked out of everything until the siege ends, but because Player1 and Player3 are allied they'll just wait for the timeout.

3. Disqualification/completion is similar. Conditions:

• Timeout, no resolution inside time limit
• Log out
• Death
• Being too far from an embroiled claim and too far from a participating member of the opposing side
  • Initiator has a longer out-of-area cooldown before being considered fleeing to prevent cheese by defender and friends

4. Claims of the target are under attack

• Maybe: All claims of target
• Eligible claims within X blocks

5. Nearby claims where the target has container+ trust are under attack if the attacker does not have container+ trust

• Prevents multi-claim strategy - GP would roll claims into sieges, but only if the defender entered them

6. Maybe: Nearby players who have trust in those claims are rolled into the defense team
7. Players are free to join the attack/defense team

• Maybe: Players with container+ trust are prohibited from entry to the attack
  • Prevents some cheese cases where defender sympathizer enters the attack to enable defender fleeing
    • Ex: Player1 under siege by Player2. Player3 enters siege, accompanies Player1 to a far-away claim and leaves. Player3 is stranded in a besieged claim with no way to complete the siege successfully even though Player1 has fled.

8. Maybe: Other players who are disqualified are prohibited from further participation

• Maybe: PVP disabled against participating members

9. Modification of embroiled claims is blocked following normal siege allowances

• Building is not allowed for defenders until attack fails or looting period expires
• Container access only during siege for defenders, no building
• Attackers can break soft blocks

10. Teleportation is blocked for participants

• Maybe: Ender pearls, being a more skill-based teleport, could be legal.
  • Pearl must be under X age to prevent stalled pearl abuse. This is a complicated check but should be possible.

11. Maybe: Players who are not involved should not be affected by claim teleport restrictions

• Maybe: Uninvolved players who teleport via disallowed means into embroiled area are automatically DQed

With this in mind, there will be events for everything:

• SiegeStartEvent (cancellable)
• SiegeJoinEvent (cancellable)
• SiegeIncludeClaimEvent (cancellable)
• SiegeDisqualifyEvent (probably not cancellable)
• SiegeEndEvent (probably not cancellable)
  Possibly:
• SiegeBlockTeleportEvent (cancellable)
• SiegeBlockPvpEvent (cancellable)
• etc.

[TomLewis]

the doc mentions that multiple people are allowed to siege a single claim/person

Yup. So, this dosunt mean they use /siege it means they just join in on an ongoing siege! once a siege is "opened" by a player any old person can just jump in on the action! Not the best design in the world. If I were to suggest a better alternative I would suggest hooking into SimpleClans to auto allow clan members in on a siege, or alternatily having /siege join an ongoing siege per player that wants to join would allow limiting, but it wouldnt prevent them really in any way, PvP will still happen, and if a way in is found they can just follow anyway! or be teleported in by their friend that did the siege! But then again, the simplicity in the deisgn is key here, having to involve another plugin is out of scope (maybe) and does confuse thigns. It needs to work with 1vs1 or 10vs1 or 100vs100, which the oldschool siege did, it just needs improving with more options and statistics!

Maybe we need this list as numbers instead of bullets so we can referance them easier.

It does seem like this is similar to base siege, but its definitally going to be one of those things where we go "Oh what about XYZ!" and take a few iterations to get right! Which I will be a primary tester with my community! They have been using siege for 9+ years now so will definitally have input!

Initiator and target are the team leaders

Does this mean Attacker/Defender? or are you looking into adding say SimpleClans support that actually has Clan Leaders, because that would be an entirely differnt type of siege plugin where it would require certain Claims being setup as "Clan homes" which could be done as there is a clan home command, which could register based in which claim its in.

I dont think it should changed to require nearby claims/proximity of claims for those Sieging, if anything this is negative as it encorages camping & wasteful/spam claims. I can already hear the messages from players requesting claims be cleaned up around their base from previous sieges! One massive headache incoming with that.

There seems to be a section missing for when you Win your siege, we actually had some custom settings in our 1.12.2 fork of GP that;

1. Once you as an attacker won a siege;
   1. Containers "unlocked". This means not much to PirateCraft as we dont use the GP lock system for chests, we require players to use blocks above chests to "Lock" them, as a physical lock, this encourages stealing from people that forget to lock their chests and also allows people to make redstone mechanical chest locks, but in general for GP overall this is one of the thigns that happens once you win a siege agaist someone.
   2. PirateCraft: BlocksBreakableAfterWin We had soft blocks that could be broken after winning whitelisted, so that an attacker could break these specific soft blocks during their 5 mins of "Raid" time.
   3. PirateCraft: AttackerClaimCooldown AttackerDefenderCooldown GeneralDefenderCooldown were added to prevent abuse.
2. If you Lose an attack on a sieged area, you get ejected from the claim (maybe it used /trapped) so you are not loitering around, you are thrown outside of the claim to say "you lost, piss off!" haha you are not ejected from your own claim if you are defending and lose.
3. When you siege, you are allows to break soft blocks whitelist, this allows poorly made buildings to be broken into, but limited to this whitelist.
4. Trusted players could be sieged in that claim, if they were online and the owner wanst, I cant remember how other claims are effected from a trusted player being sieged in someone elses claim.

I would absolutly love from the begging to have a database table to log all sieges, so that we can track everything, then we can use this data later to prevent abuse and add timers etc.

As events go, can we maybe have an event for listneing to people involved in a siege, maybe everyone within X distance of the person being sieged?

I may have to fire up a 1.12.2 local server and have a test for certain things to jog my memory.

[TomLewis]

Just a thought, that being standalone would be amazing to consider this as a general siege for "claim plugins" in general. As nearly all of them do not inclue a siege. This would open up being able to move to GriefDefender which is much more polished than GriefPrevention with additonal featuers and regularly updated.

Second thought for later on in development; Consider a method for giving up from being attacked where the attacker has to confirm/accept their submission from the fight. It could be /surrender which opens up a chest that the defender can put in some item(s) as an offering to the attacker, the attacker gets sent a message with the offer, which they can view only, if they accept they can claim the offering. (Just an idea I had and didnt want to forget it, so i wanted to note it down).

Another part of the fork we had, included a Bossbar countdown timer of a siege time, then a second bossbar cooldown for looting time, we also had titles show for players when they were sieged or started a siege, all with sound alerts too.

[Jikoo]

Maybe we need this list as numbers instead of bullets so we can referance them easier.

Edited in numbers for the primary points.

Initiator and target are the team leaders

Does this mean Attacker/Defender? or are you looking into adding say SimpleClans support that actually has Clan Leaders, because that would be an entirely differnt type of siege plugin where it would require certain Claims being setup as "Clan homes" which could be done as there is a clan home command, which could register based in which claim its in.

This would be specifically the old attacker/defender, I just found that terminology to be less confusing given multiple attackers and defenders. Given the number of edge cases where players can intentionally prolong sieges, it seems like the siege finishing if either of the primary players involved is disqualified makes sense.

An aside, writing it down before I forget it: bells apply glowing to the attackers within a range similar to vanilla's raiders would be a fun optional feature.

I dont think it should changed to require nearby claims/proximity of claims for those Sieging, if anything this is negative as it encorages camping & wasteful/spam claims. I can already hear the messages from players requesting claims be cleaned up around their base from previous sieges! One massive headache incoming with that.

So the idea with proximity is that attackers have to actually be attempting to participate in the siege. If you're too far away, you're probably just prolonging the siege to lock the besieged claims or annoy the target user. You wouldn't be able to create a new claim to join in, you'd just have to actually go to the vague area of existing claims under siege to join. Then you'd have to stay in the vague area of besieged claims until the siege completes to be considered still participating.

GP already had this requirement for both attacker and defender - if you run, you're not sieging. If the defender ran into another claim they could access that would get rolled into the siege, and if both attacker and defender were within 50 blocks they were considered "in pursuit" and the siege was not completed.
The difference here is that I want to include all of the target user's claims (or maybe just those within X blocks) so that multi-claiming doesn't work, and I want to apply the same restrictions to the new users joining in so that they cannot join purely to prolong sieges without being present.

Camping unfortunately does seem to be a core flaw of existing siege and I'm not sure how to get around that. If the besieged user has a sealable bunker, they may as well just go AFK for the duration of the siege. Granting attackers access to levers/buttons would wreck a lot of chest securing mechanisms as you've described. Maybe defenders must move a certain distance or perform certain actions to be considered active? Taking damage from attackers is definitely participation, but the other options I'm not too sure of. I'm already envisioning someone's bunker being a 50 block tunnel that they just run back and forth in, or shooting an arrow into a wall every so often to refresh the timer. Maybe the attackers taking damage refreshes the defender's activity timer? That opens up the possibility of some kind of Home Alone situation where the defender is hiding and using a bunch of traps to discourage the attackers. I think overall this is a separate discussion from core siege process though, we can tweak defender participation requirements after the system is built.

/e: #6 for anti-camp etc.

There seems to be a section missing for when you Win your siege

I wasn't super concerned with the post-complete details yet, GP's siege could use tweaks but that section is a lot simpler in comparison. Most of it is a good base while the siege mechanics themselves are fully 1v1 and need to be entirely reconsidered for a multi-user environment.

we actually had some custom settings in our 1.12.2 fork of GP that;

1. Once you as an attacker won a siege;

   1. Containers "unlocked". This means not much to PirateCraft as we dont use the GP lock system for chests, we require players to use blocks above chests to "Lock" them, as a physical lock, this encourages stealing from people that forget to lock their chests and also allows people to make redstone mechanical chest locks, but in general for GP overall this is one of the thigns that happens once you win a siege agaist someone.
   2. PirateCraft: BlocksBreakableAfterWin We had soft blocks that could be broken after winning whitelisted, so that an attacker could break these specific soft blocks during their 5 mins of "Raid" time.
   3. PirateCraft: AttackerClaimCooldown AttackerDefenderCooldown GeneralDefenderCooldown were added to prevent abuse.

2. If you Lose an attack on a sieged area, you get ejected from the claim (maybe it used /trapped) so you are not loitering around, you are thrown outside of the claim to say "you lost, piss off!" haha you are not ejected from your own claim if you are defending and lose.

3. When you siege, you are allows to break soft blocks whitelist, this allows poorly made buildings to be broken into, but limited to this whitelist.

4. Trusted players could be sieged in that claim, if they were online and the owner wanst, I cant remember how other claims are effected from a trusted player being sieged in someone elses claim.

Those all sound pretty good. I don't know how GP handled offline owners off the top of my head, but I know extending into claims was a pure AccessTrust thing. That seemed really bad, because that meant claims with /accesstrust public were fully lootable by anyone after a siege despite the fact that no one involved had any real trust whatsoever. As the primary reward for winning is looting containers, I plan to change that section to a ContainerTrust requirement for the target and the initiator additionally not having ContainerTrust.

I would absolutly love from the begging to have a database table to log all sieges, so that we can track everything, then we can use this data later to prevent abuse and add timers etc.

That's doable, though that's another after-the-fact sort of thing where it's a listener for various events that aggregates that all on siege end.

As events go, can we maybe have an event for listneing to people involved in a siege, maybe everyone within X distance of the person being sieged?

The SiegeJoinEvent should be able to be used for counts, but you're right, bystanders should be rolled in somehow. Maybe if they perform a PvP action they automatically join based on it if allowed? That or bystanders are just blocked from PvP actions against/by siege members until they manually join up so that accidental friendly fire doesn't land you on an opposing side.

Just a thought, that being standalone would be amazing to consider this as a general siege for "claim plugins" in general. As nearly all of them do not inclue a siege. This would open up being able to move to GriefDefender which is much more polished than GriefPrevention with additonal featuers and regularly updated.

I do want to eventually make that possible, but for the first pass I just want to focus on getting it to work with GP. Ideally expanding to GD should not be hard from there due to the fact that it's based on GP, although I'm not sure about other claim plugins. The support burden of "please add X claim plugin" gets to be pretty large, and is something I have definitely regretted in the past.

Second thought for later on in development; Consider a method for giving up from being attacked where the attacker has to confirm/accept their submission from the fight. It could be /surrender which opens up a chest that the defender can put in some item(s) as an offering to the attacker, the attacker gets sent a message with the offer, which they can view only, if they accept they can claim the offering. (Just an idea I had and didnt want to forget it, so i wanted to note it down).

I like it. Definitely a later thing, but that's definitely possible.

Another part of the fork we had, included a Bossbar countdown timer of a siege time, then a second bossbar cooldown for looting time, we also had titles show for players when they were sieged or started a siege, all with sound alerts too.

I'm planning on having boss bars/titles/action bar messages configurable throughout, so that will be very possible. Definitely want the option of a big title to grab attention when you get sieged and was debating the option of a boss bar for a "return to battle" timer. That will be a closer to the end thing though.

[TomLewis]

I think this is a great start, I have messaged my team last night for input and they have seen this thread, but its going to be one of those developments which require us to play with it in-game before we realise something is missing or deisgn is wrong!

I can add you to our Discord as a developer and invite you to our Github tracker once we have something to experment with so you can keep track live of our testing, notes and conversations.