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 Depth reset. #312

Closed
NullCase opened this issue Jul 14, 2018 · 17 comments · Fixed by #1598
Closed

Claim Depth reset. #312

NullCase opened this issue Jul 14, 2018 · 17 comments · Fixed by #1598
Labels
🐛Bug Issue is a validated bug report. Need more info More information is needed to determine what's going on.

Comments

@NullCase
Copy link

NullCase commented Jul 14, 2018

This has occured at least 4x since I set claim depth to ExtendIntoGroundDistance: 1

I have been experimenting to find out what causes this problem. So far I haven't had any luck.

The top level claim's depth is being reset for land claims which have subclaims when ExtendIntoGroundDistance is 1.

The subclaims have a different depth than the top level claim.

When claim depth resets, builds underground are becoming unclaimed.

@NullCase
Copy link
Author

I switched it back to default, ExtendIntoGroundDistance: 5

Still the claim has reset once since then. very strange.

@NullCase
Copy link
Author

text comparing my old config and current one... they're exactly the same, so i haven't changed the config in months (after reverting to ExtendIntoGroundDistance: 5)

So I started considering more things.

It looks like you updated subclaims to have /claimexplosions permit block breaking for withers.

That update occurred roughly when this first started happening for me.

@RoboMWM
Copy link

RoboMWM commented Jul 15, 2018

It looks like you updated subclaims to have /claimexplosions permit block breaking for withers.

Not that I'm aware of. Might want to check with @jacob1 though.

@Jikoo
Copy link
Collaborator

Jikoo commented Jul 15, 2018

2f5a2ee

@RoboMWM
Copy link

RoboMWM commented Jul 15, 2018

2f5a2ee

This build has not been released.

@RoboMWM
Copy link

RoboMWM commented Jul 15, 2018

Anyways, afaik the extendIntoGround check is a task, and determines the lowest "player-type" block (i.e. a non-natural block). This task is run async iirc after acquiring the chunks within a claim to check to extend. I'm not sure what other things may trigger this, but it should update the claim's depth as listed in its data.

@Jikoo
Copy link
Collaborator

Jikoo commented Jul 15, 2018

This build has not been released.

Ah, so used to just grabbing whatever whenever, my bad.

@NullCase
Copy link
Author

NullCase commented Jul 15, 2018

OK, player-type blocks extend the claim.

Inside this particular claim there are shulker boxes, quartz stairs, hoppers, comparators, stained glass, lapis blocks, redstone lanterns.

It seems like some of these would be player-type blocks.

The claim data yml shows the Y coordinate within this claim is 0 (presently) but the claim is working properly for the moment.

@NullCase
Copy link
Author

Still a mystery. How could subclaims cause claim depth to reset?

@RoboMWM
Copy link

RoboMWM commented Jul 16, 2018

Would be nice if you filled out the template before deleting it. Unsure of steps to reproduce - when does it happen? When you create a subclaim? When you build in it?

@TomLewis
Copy link

Sub-claims have always caused weird things to happen, sometimes all sub claims will just vanish. I have also had this depth reset itself. I will ask about my community to see if someone knows how to reproduce it, i'm sure we figured it out years ago and reported it, getting a bit old for the memory to pick these things up now! haha

@NullCase
Copy link
Author

I deleted the template this time. Next time I won't though. Cool?

I'm unsure how to reproduce this. It first happened after I changed ExtendIntoGroundDistance to 1. It happened 4 times on the same land claim with this configuration.

So I changed it back to ExtendIntoGroundDistance: 5. It happened one time after that.

And "What" happens is basically that the claim's depth is reset to 60. Some of the subclaims start at 65 and permit the use of a Nether wart farm.

This has not recurred recently, but it's very weird. I'm sorry, I don't understand it that well.

@RoboMWM RoboMWM added the Need more info More information is needed to determine what's going on. label Jul 16, 2018
@NullCase
Copy link
Author

Closing this because it's not been an issue for two years. After two years of trying to reproduce this, claims have been fine.

@NullCase
Copy link
Author

NullCase commented May 17, 2020

GriefPrevention version 16.13.0-0f82170

Claim Depth reset showed up again today. I don't know how this caused the claims depth to reset, but here's a few steps.

  • land claim depth extend into ground is default (5 blocks)
  • First, I created a subclaim and resized it using /extendclaim commands.
  • I removed blocks from within the subclaim, basically digging out part of a chunk.
  • I resized the subclaim again, making it smaller using /extendclaim -16
  • I continued working and later noticed the land (edit: below surface in the top level claim) had become unclaimed... (after an unfortunately large amount of damage from withers :)

To re-extend the depth, I just placed some blocks down near Y=5.

edit: included that extend into ground is default 5 blocks.

@NullCase NullCase reopened this May 17, 2020
@RoboMWM
Copy link

RoboMWM commented May 17, 2020

interesting, subclaims strike again

@NullCase
Copy link
Author

NullCase commented May 17, 2020

As a theory to test, is it possible that creating a new subclaim (and then placing items within it) redefines the topClaim's depth? Almost like the subclaim says "my depth is not yet defined" but the topLevelClaim asks the subclaim for a new depth?

@RoboMWM
Copy link

RoboMWM commented Dec 9, 2020

Hmm, I think resizing the claim is what probably re-adjusts the lower y-level(?) If so, then this can happen with normal claims too.

Or it could be subclaims resetting to the parent claim's lower y level.

Jikoo added a commit to Jikoo/GriefPrevention that referenced this issue Sep 26, 2021
@RoboMWM RoboMWM added the 🐛Bug Issue is a validated bug report. label Dec 5, 2021
RoboMWM pushed a commit that referenced this issue Dec 5, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
🐛Bug Issue is a validated bug report. Need more info More information is needed to determine what's going on.
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants