Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

CLAIM REGENERATION FEATURE - RE: GD2.0 Live test discussion. #406

Open
VentureTown opened this issue Jun 20, 2021 · 0 comments
Open

CLAIM REGENERATION FEATURE - RE: GD2.0 Live test discussion. #406

VentureTown opened this issue Jun 20, 2021 · 0 comments
Labels
enhancement New feature or request

Comments

@VentureTown
Copy link

Regenerating Claims - is an idea that came about during Blood's recent 2.0 live test.

The following is everything that was discussed/broken down and anything that I have since compiled to flesh out the idea.
I encourage anyone who reads to comment anything they think would add to the feature.

Disclaimer

I am not a programmer - I know some in Java and C# but by no means am I capable of creating any of this myself - unfortunately. My examples and ideas shown below are an attempt to convey - via my limited knowledge - the processes and executions in a way that is easy to understand but also to grasp how they would be implemented.

A lot of these ideas are not new - if not all of them. However, GD is designed to be an all-in-one solution and already has much of the framework in place to add these functions.
The goal is to reduce the overall amount of general use plugins required for servers/clients.

The Idea

The general intent is for an area to be made for the server that will allow for blocks to be broken, gathered, picked up or otherwise altered. Set the area as a claim. After a certain interval, event or on command - the set claim regenerates to its original state. Checks, passes and fails would be employed to ensure correct behaviour.

This is intended to allow for things such as mines, farms, dungeons, events, quests, challenges and a plethora more of areas and situations. All such areas/activities may or will involve breaking blocks or otherwise removing resources/items from the world.
Allowing users to do so in a specific area rather than having to deal with global block permissions or separate worlds - while also raising the immersion factor for the users. This also naturally deters unintended griefing.

Different situations would require slightly different regen methods and processes or a combination such as:

Options:

regen-interval="seconds"

  • Intended use - for standard time cycle for regen. hourly, daily, etc. I.E. Mines and other resources or collectables.
  • Time noted in seconds for ease of use. Users can struggle with getting the syntax for DDMMHH. Reduces user error.

regen-mintime="seconds"

  • Checks that "seconds" amount of time has passed since last regenerate.
  • Due to possible interactions with the other options it may be possible for a claim to attempt to regen too quickly after the last.

regen-maxtime="seconds"

  • May be required to have a deadline for attempted regens. This would prevent any issues with rare occurrences when the has been delayed too long or keeps failing checks.
  • Without it claim regens could be subject to griefing by players

regen-missing="percentage"

  • Checks that "percentage" of claim blocks are missing before attempting to regen.

regen-chance="decimal"

  • Allows a pass/fail check when attempting a regen. Can be used with schematics, or blockIDs to allow for some randomisation/variation.
  • Allows for rarer blocks/regens to not be present in a regen - good for immersion.

regen-variant="weight"

  • This would allow for the regen to randomly choose from a set of saved schematics. Weights let options be more or less common. Which is distinctly different than the above.

regen-player-check=true/false

  • Check if players are in the claim - or not.
  • Users may want to enable or disable this check. For various reasons.

regen-player-radius="value"

  • By using the "regen-player-check" allows claims to regenerate around players without suffocating them or having to yeet them out.
  • Intended use for large underground or dense claims.
  • May be necessary for maintaining a good player experience if servers want to maintain strict regenerate times.

The following may be able to utilise world edit as GD already has some interplay.

**regen-saturation="%blockID, %blockID"

  • This would allow a claim to simply regenerate randomly with a saturation of blockIDs. Useful for areas you simply want to have filled without designing a schematic.

regen-saturation-fallback="blockID"**

  • Fallback is allows you to assign a filler material I.E. "stone"
  • Example: regen-saturation="10%iron_ore, 25%coal_ore",
    regen-saturation-fallback="stone"
  • Sometimes math is hard mmkay - users may appreciate the option for "just the rest" or "fallback" as I've called it.

Defenitions/Explanations

Schematics (World Edit)

  • Already in use by GD. Can be utilised to designate regen states for claims

Schematic Libraries (New to GD)

  • Allow for multiple states of a claim to be saved as possible regenerations.
  • Intended for player immersion and possibilities. Rarer maps, zones, dungeons, mines, resources etc.
  • Would require the "regen-chance" or "regen-variant" option.

Block IDs

  • Claim will look for and regen specific blocks and should allow for multiple IDs. I.E. - gold ore, iron ore.
  • Intended for use with mines, outcrops, groves, forests etc. Places where you may not have a "layout" or "schematic".
  • Can be used in tandem with flags to allow users to break only certain blocks within a claim.

Missing Blocks Check

  • Claim checks original claim state and only attempts to regen when set % of original blocks are missing.
  • Intended to prevent claims unnecessarily replacing blocks. Also saved the server/client from the extra load for no reason.
  • Great for use with large areas where it may be less frequent for the resources/items to be depleted.
  • Block IDs function will probably require additional checks to work with this as you may be able to break all the "allowed"
    blocks in a claim and it not be enough to trigger the % missing event. If the "Missing Blocks" check trigger is able to check
    only the % of the chosen "Block IDs" this may solve it.

Players in claim check

  • Checking for players in the claim can be used for multiple reasons
    1. A pass/fail check to ensure the regen is not performed while players are present
    2. Booting players out of a claim to regen it - if requied/wanted.
    3. Not booting players out of a claim to regen it
    4. Limiting time allowed in claims.
    5. more?
  • Could be also useful for a regen-mintime="seconds" check. Leaving a claim triggers the check "any players" then checks "min time" and refills the claim if necessary or something???

Possible Commands Required

/gd regen

regens the claim you're standing in

/gd regen time [seconds]

sets the regen interval for the claim in seconds

/gd regen clear

clears the set regen from the claim

/gd rblock add [%blockID]

adds a block/s by % to the claim (only for satuation type claims)

/gd rblock update [%blockID], [%blockID]

updates the block saturation in the claim (only for satuation type claims)

/gd rblock remove [blockID]

removes a block from the claim (only for satuation type claims)

/gd schem group [groupname]

creates a schematic group library

/gd schem add [groupname]

adds a schematic to the group

/gd schem remove [groupname]

removes a schematic from the group

/gd schem list [groupname]

lists all schematics in the group

/gd schem cycle

cycles claim through available schematics

AAAAAAAAAAAAAnnnddddd I think that's it?

@bloodmc bloodmc added the enhancement New feature or request label Jun 22, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

2 participants