shapez.io

shapez.io copied to clipboard

This PR refactors underlays so that they are properties of acceptors and ejectors, by splitting the belt_underlays.js system into acceptor_belt.js and ejector_belt.js and adding an optional property beltLength to acceptor and ejector components. Underlays are no longer double-sided, and their length is adjustable with this property.

Rendering logic in these systems, as well as that of belt.js, is refactored for consistency and simplicity. Animation frame and hovered belt path calculation is consolidated into belt.js's drawChunk function, which calls an internalDrawChunk function for all three systems. When determining whether to show an underlay, ejector belts are able to take advantage of the ejector's cached target entity, while acceptor belts still use the old logic.

Belt underlays now respect the simplified belts setting, not animating except when the adjacent belt path is hovered.

Because input/output belts are not fully covered by some buildings, underlays are added to the sides of mergers and splitters, the acceptors of stackers, mixers, and the hub, and the shape acceptor of the quad painter. (There are some other, much more minor cases that were not included.) Since in most cases the issue is from the misalignment of sprites, this is mostly a temporary fix. (Note #1318 also fixes this.)

This is nice, but there are some cases where underlays are not supposed to be rendered even with an acceptor/ejector there

yes, which is why the property is optional (or can be set to 0, which does the same thing), and which is why I list the buildings I do add underlays to

...but I guess I'll edit it to make it explicit