Flow Field Collisions

<h1 style="text-align: center;">Back-Propagated Flow Field Collisions</h1> <p style="text-align: center;">A strange mod that adds weird collisions for questionable reasons.</p> <p style="text-align: center;"><span style="text-decoration: underline;"><span style="background-color: #e74c3c; color: #ecf0f1; text-decoration: underline;">This is an early release and has not yet been battle-tested in my mods. Use at your own risk.</span></span></p> <p style="text-align: center;">&nbsp;</p> <p style="text-align: center;"><img src="https://moddbcdn.vintagestory.at/unfair_comparison_ev_71a519ee3afe8ec9c75c03e43b5c6416.gif" alt="" width="765" height="513" /></p> <p style="text-align: center;"><strong>This mod is meant to be a dependency for other mods, not a mod that is usable in itself.<br />To be clear: this mod does <span style="text-decoration: underline;"><em>not</em></span> add new collisions to existing game objects.</strong></p> <p style="text-align: center;">&nbsp;</p> <p style="text-align: center;">When developing <a href="https://mods.vintagestory.at/yangtransport">Yang's Transport Tycoon</a>, I had an issue: Since Vintage Story block collisions can't be larger than the extent of a block,<br />my 2x6 rail pieces could only be broken at a single corner, which was very unintuitive, and also allowed rails to clip through walls and each other.</p> <p style="text-align: center;">Unwilling to compromise, I first looked into how the game handled multiple block span collisions, but found that the common approach was to either break<br />blocks into multiple pieces, to fake their collisions with invisible chiselled blocks, or to use the multi-block system which has limited support for complex/large shapes.</p> <p style="text-align: center;">&nbsp;</p> <p style="text-align: center;">However, modifying the vanilla multi-block works would likely end in a performance and maintainability disaster, as well as damage compatibility with other mods.<br />So instead, I came up with the idea of 'Back Propagated Flow Field Collisions', a mouthful of a term for a rather simple concept.</p> <p style="text-align: center;">&nbsp;</p> <p style="text-align: center;"><img src="https://moddbcdn.vintagestory.at/blockcollisionsmeme_593233f2ac465daff5089e24b1c7eff2.jpg" alt="" width="487" height="271" /></p> <p style="text-align: center;">&nbsp;</p> <p style="text-align: center;">Flow Fields can basically be explained as a grid where every cell points in a direction, that direction being the next cell<br />that has the most direct route to a discrete point in our grid. This means that if you follow the direction of any cell throughout our grid,<br />you'll always end up following the most efficient path towards our target cell.</p> <p style="text-align: center;">This is a really efficient way of having a very large amounts of points in space which direct to the same goal.<br />Not only that, but they can be baked (we only calculate them once, instead of querying data each time we need it) as long as the target is static too.</p> <p style="text-align: center;">This means that we can have blocks that hold an ultimate direction towards a source block, and as long as we overwrite their behaviour so that<br />they relay changes to their source, we suddenly have a bunch of separate, discrete blocks which act as one. All-for-one.</p> <p style="text-align: center;">Of course, it's not enough for this to be a one-way relationship. When a change happens (like for example, we break one of our flow field colliders) and we<br />trace our way to the source block to relay the information, then the source block back-propagates the information to all the flow field cells pointing at it. One-for-all.</p> <p style="text-align: center;">The key here is that our collision blocks are generic, they just relay data without themselves knowing who the source is, or being understood by the engine as part of a wider self.<br />This makes the blocks very efficient to store in memory, since they're just generic blocks like dirt or cobblestone. You can have millions of these blocks without barely any additional cost.<br />The real cost is offloaded to the processor, which has to iterate through our flow field and pass along data, and when back-propagating, potentially perform as many as twenty iterations, <br />a modern computer processor can roughly handle a couple million iterations each second assuming that each iteration consumes an abnormally inefficient amount of cycles to complete.</p> <p style="text-align: center;"><img src="https://moddbcdn.vintagestory.at/ezgif-44ce83929086a8_4681b22c708e0fca0388a197ee0c13fb.gif" alt="" width="412" height="219" /></p> <p style="text-align: center;">Thus, this set-up provides us with a way to create multi-block gestalts while keeping memory costs low and only intermittent (on demand) processor costs.<br />All for one and one for all.</p> <p style="text-align: center;">&nbsp;</p> <h2 style="text-align: center;">Why Use BPFFC Over Multi-Block</h2> <p style="text-align: center;"><strong>You should not.</strong> In 99% of cases, the vanilla approach is superior (and better supported). It's why vanilla uses multi-block and not this.<br />This solution is only meant for the edge cases that multi-block&nbsp;<em>refuses</em> to handle, such as blocks larger than 5x5x5, or with complex shapes.</p> <p style="text-align: center;">Case in point, if you need a chest, a door, a small raft, or any block that's small and can be shaped as a rectangle, use the vanilla multi-block.<br />But if for some reason you are tempting god by making blocks that have bendy-straw-like shapes or are very large in size, you can relegate yourself to my solution.<br />On paper BPFFC is also slightly more efficient, so if your block is meant to be placed in the thousands (like a rail would), then it's a reasonable fit too.</p> <p style="text-align: center;">&nbsp;</p> <p style="text-align: center;"><img src="https://moddbcdn.vintagestory.at/