-
Notifications
You must be signed in to change notification settings - Fork 24
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
Quarry 3.0 #288
Quarry 3.0 #288
Conversation
Nice! I like the use of particlespawners for the region (and might steal this idea on another project 😉) I had my test-setup of 120+ quarries on the pandorabox test-server and decided to update the Sadly every quarry i already placed was rotated with "face" down and had a param2 of Oh, and somehow the front-texture was missing/blacked-out :/ |
@BuckarooBanzay that looks correct, quarries don't have a rotation anymore, so I changed the design to look like there is a hole on the bottom. (I forgot to mention that sorry). Prehaps I should change it to a nodebox with an actual hole... 🤔 |
Awesome. Will the old quarry behavior be supported as well (so that existing ship designed that assume the old behavior will continue to function)? |
Debatable but I'd like this to be configurable because it apparently prevents using forward (and a bit of upward too) digging quarry ships I've used a lot. |
Yes, existing quarries will be configured by an LBM to match their previous digging area, so they will continue to work the same. The only exception is changing the radius, as that doesn't behave the same way as before.
It's not possible to dig up anymore, otherwise the quarry would dig itself and whatever is around it. |
I can add functionality for that if needed, would be just complaining if selected offsets overlap quarry itself. Another way which could bring both compatibility with old methods and new content could be introducing Quarry Mk2 where old quarry could simply use exact same code but with limited configuration and old tiles? But I guess only if someone else would also see use for old functionality or introducing another tier with different functionality... |
I really want to avoid adding another version of the quarry, not only because the old version will be mostly obsolete, but also communicating about them will get confusing.
So far only FeXoR and MCLV have commented on the new quarry (see #offtopic), and FeXoR doesn't mind:
Need to get some more players testing them. |
EDIT: I tested it and LBMs do require players to trigger them, but calling |
LBM is named after Load but it is actually executed on Activate instead of block loading... |
Yep... I should have just looked at the docs: https://github.com/minetest/minetest/blob/88820cd31c2fe21c8c16ee547a3335131e8ba009/doc/lua_api.txt#L7891-L7893 I added a simple check to prevent quarries digging before they've been updated, they wouldn't crash but they would start digging with the default offsets of zero. |
Did some more testing, specifically for the previous bug in #143, and it stops correctly at I did find a weird thing where the quarry instantly finds the first node to dig (it should take several cycles), so I'll have to figure that out before I merge this. |
fix absolute positions, add max depth check, and load the area
Turns out the ground search was using absolute positions, so it was finding the ground on the first run, and instead the digging loop was finding the ground. (I guess it must be well optimized to do that within 3000μs 👀) Also added a depth check to the ground search, and loading of the area. |
Click for detailed source code test coverage reportTest coverage report for Technic CNC 87.36% in 11/14 files:
Test coverage report for technic chests 45.56% in 6/6 files:
Test coverage report for technic 63.45% in 96/96 files:
Raw test runner output for geeks:CNC:
Chests:
Technic:
|
I think this is ready to merge now, it's at least safe enough for live testing 💥 |
Another feature and performance rewrite for the quarry.
Main changes:
Doing some basic testing by timing the running of 20 quarries, I found an improvement of 45% when running, and 68% while idle. The majority of the saving is from not updating the formspec every run, but there are also less calculations done when running.
The new visualization uses particles spawners to show the edges of the working area:
Implements and closes #147 (ping to @dennisjenkins75)