Not really. The duplicator needs a good rewrite. It's angleId(%id) clearly does not know about the mod operator (%), there is probably a better way to do dupCheckString(%string) (Just tried. A method I used in an old, barely started, add-on, was stripChars() and then a test against an empty string. Guess what one won? The one that did the majority of the looping within the engine, despite *not* quitting early. Looping both 10k and 100k times, the duplicator's version was nearly 20 times slower (100k iterations took ~20 seconds, while the other code finished in roughly a second)). Within the main duplicator code, the time and admin tests should happen before the raycast and projectile, otherwise a spammer can spam raycasts (though a relatively fast operation) before the code realizes they shouldn't (this isn't a huge problem, though). Then you get to the highlighting. Fact: Many schedules at once is bad. Fiction: The duplicator was well designed. Proof: EVERY brick gets it't own schedule to restore the colour. Also uses a fairly generic variable name on the brick itself, setting up for a disasterous mod conflict. And a per-brick function call should qualify as an inner-loop operation, so it could easily be optimized out by making the function inline. Oh, and ugh, value $= "" to determine if a schedule is already there? What about the handy isEventPending() function? What if the planned schedule wasn't completed? You have a brick that is permanently white. The helper for brick too far distance: in a² + b² = c², rather than shifting c's ² to a square root of a² + b², you can precompute the c², because it will always be the same(eliminating the square root makes less than a 20% difference in a simple test that was a square root of the sum of two squared, random, numbers, looped one million times, taking just under 20 seconds with the square root. Not much of a saving, really), but the really surprising one is getting the player's position again, every time. Also, the function call from an inner loop issue again. It's not like adding a little bit of readability could make a difference in that code. Eliminating tabs as indentation would go a lot farther towards making it readable than splitting time-critical code into a function to take a moment longer... It also does something in response to $AddOn__JVS_Content. Rather than creating a special case, it could have created a callback for newly duplicated bricks so that *all* other add-ons could use it. It does have a neat bonus of using Blockland's save file format as it's internal data format, so saving and loading is easy...
