-
-
Notifications
You must be signed in to change notification settings - Fork 255
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
Torp Factory 1.5 #2588
Torp Factory 1.5 #2588
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Finally, factory without process
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why would they call that convayable... I had to double check that wasn't a typo
When you're loading a lot of parts at once, the loading sound overlaps and gets quite loud. |
Sound now has a cooldown so you shouldn't get your ears factory blasted & the picked up item is now decided by the last manually inserted one instead of the one first in the current list |
About The Pull Request
Lets face it, the munitions torp automation right now has a tendency to be more trouble than it's worth. The machines are very clunky to handle, only work half the time (which neccessitated slower belts despite having been thrown into faster processing), and are incredibly processing inefficient.
This PR reworks almost everything that was related to the torp / missile assemblers, cleaning up code, making it magnitudes less expensive to idle (seriously the processing & iteration was horrible)
The machines now do not process at all, instead operating on their watched turf being entered by something they care about, and only then springing to action. This reduces their dry load to 0, and makes them only have any kind of performance requirement when things actually appear, which they also only have to iterate on once as opposed to every process() even if invalid.
They also now pick up components of the type last manually (by hand) inserted, should they pass the tile the assembler is watching.
throw_parts.mp4
It is recommended to only keep a single type of component per assembler as there is no reason to have more than one right now, but if there is more than one, the one currently in first place (that will be applied next) is the one it will grab parts of.
In general, they also react MUCH faster thanks to being signal-based (superfast) instead of processing (guh)
Look at it go!
muni_factory_adv.mp4
It could run on normal belts now instead of the slowed belt subtype (hell you can throw components past it and the assembler will catch them), however I didn't feel like editing the maps.
Also fixes two random bugs, one with the FTL Thirring Computer soundloop that has been broken since it was added, and a random GC failure with clients_by_z which did not account for mob deletions.
Why It's Good For The Game
Torp automation has been left somewhat neglected and lacking effective usefulness. This improves functionality, making a well-supplied assembly line a torpedo (or missile) powerhouse.
Also fix man good.
Testing Photographs and Procedure
Already in the PR desc body itself.
Changelog
🆑
refactor: The Torp and Missile factory automation machinery has been rewritten almost entirely to make it less clunky and more fun.
add: Automated Assemblers will now pick up components of the last manually inserted type if they pass in front of them!
fix: The Thirring Drive Core sound loop you have never heard before works now!
fix: The client_by_z list shouldn't be getting flooded with nulls anymore.
/:cl: