In 6.0 Quarry Frames do not appear to decay.

In 5.x Frames decay as soon as the quarry has been destroyed. This helps greatly in the post quarry cleanup.

Is this a bug in 6.0? Can this be re-added? Can this be re-added in 6.0?

Bug reports go here
http://mod-buildcraft.com/forums/index.php?board=2.0
Issues are used as //TODO: list

Not really, @Meegooo , issues are used for both. An issue is something you consider an issue, really. The developer closes it or not depending on whether it was fixed and whether it should be fixed.

SpaceToad has been rejecting any reports that is not registered by a developer willing to solve said issue.

asiekierka, In readme it says "Do not open an issue if you're not planning to fix it, instead open a thread on http://mod-buildcraft.com/forums/index.php?board=2.0"

@Meegooo: Oh. I didn't know about that. Well, that means more places to look into issues to.

Don't close this one, though - I want to look into it and many others once I'm done with the RF stuff tomorrow.

There was a bug in previous versions where frames did decay even if the quarry was in operation - so that behavior has been reverted to its origins. No big problem working further on it, but it may make more sense to work on mechanics at the Quarry level (e.g. the tile Quarry gets responsible for removing frames rather than decay implementation).

BTW - @Meegooo is right, but @asiekierka, I'm assuming you're taking over this one so keeping open.

@SpaceToad - The tile quarry should not be reponsible for it as quarry decay was used usually when the quarry tile was removed.

What's the expected logic for activating decay on a given piece for frame then?

maybe if we make the piece of the orange frame a new entity? if the quarry gets removed it tells that frame and that removes the other frames one by one. and then itself when it's done

Or maybe implement it like this on random tick:
If you are straight piece you need at least two neighbours to survive;
If you are corner piece you need 3 neighbours to survive.
Quarry would break one block of frame and the rest would decay in nice fashion. There would be warm-up time needed for quarry to build the whole frame but it should easy to implement by changing meta.

Or make on Block break order updateTick on other pieces.

@Kubuxu: This is exactly the idea I got 3 hours ago on a tram. Ahh, telepathy. The metadata would store the amount of neighbors, as defined by the quarry, in order to stop the frame from breaking when unfinished. This would, of course, not break existing quarry frames, but we can't do much about this.

@Kubuxu: Okay, then, handing it off to you as there's a lot of things to do. Send a PR when you're done.

I can do it this weekend.

Making every frame check all it's neighbors every ticks is a bad idea. Plus if you put four quarries next to each other the corner pieces (and probably the whole shared side) will never decay...

In my opinion the quarry itself should inform the frames that it has been removed and that they may decay.

@psxlover: The quarry itself can't really do it. We also didn't want them to tick - neighbor updates are a thing. We could just use one of the 16 metadata values to store the exact position the frame is in and the exact positions of neighbors - there are only 11 possibilities either way. You break one frame, neighbor updates make the other frames disappear.

Why can't the quarry do it? It can just change their meta.
Also if you want them to decay and not disappear all together they will have to tick. How else will they disappear in a random tick after the quarry was removed?

Yes that what I want to do, encode into frame metadata position of relatives. Then when you break one of them, they will disappear slowly(or fast, as you want). The metaid 0 will be special case that is invalid so frames already in world will behave like now.

@psxlover because iterating over all of them would be necessary.

And what's the problem with that? The quarry knows exactly where they are, and it's only removed once.

It can be done both ways. What's more to say, in programming most problems have multiple solutions.

That works only in 2 ways.
TileEntities or extern NBTSaving.

TileEntities would be bad because more to sync and more ticks get wasted for nothing.
Extern NBT would work but i do not know if @SpaceToad would implement that because it is not really stable at crashes. (Speaking with knodledge) And the current way :/ Why not changing metadata simply?

Or do it another way - Quarry places them all, so quarry knows, where it is. When placing, Quarry will give them also information, where it is placed. And then let frames check for the block they were told quarry is, if they find it, it is okay, if not, they decay. I would use here same method as leaves decay (so it will be random, not at one time), in that case it is not computer time consuming..
When you put new quarry over old one, it still needs to check every frame, in that case it will rewrite the coords...
Only one problem with leaves decay method is, that it checks surronding, that shall be replaced by "check the one block given before " - in which case, it will be even less computer time consuming. There are no lags for leaves decaying, so also in this case it can be good. :)

I will do that. Just a busy month.

@Kubuxu - are you still working on that one? Otherwise, should be closed for lack of owner.

Is this still a problem, still being worked on?

If not, I could use some code to look at, wouldn't mind trying to do this one.

@Hanse00 - Apparently, @Kubuxu disappeared into nowheres. Feel free to try looking into it.

@asiekierka I disappeared into no-passion coding zone.