This fixes an inconvenience in the VCS api when working with javascript. VCS graphics methods have the ext_1 and ext_2 attributes, which insert -1e20 at the beginning or 1e20 at the end of the levels array, respectively. Since there's no built-in storage for those attributes, this causes some headaches. JavaScript expects ext_1 and ext_2 to just be normal booleans; it's easiest if the user doesn't need to futz around with the levels array when turning on / disabling extensions. So, this just makes sure that ext_1 and ext_2 are set based on the boolean values provided, once the levels have (possibly) been set. If -1e20 and 1e20 are already there, it'll behave exactly the same as before. If they aren't, it'll automatically repair the levels array to be like VCS expects. This might cause an issue if the user sticks 1e20 or -1e20 as levels, but I'm willing to punt on solving that specific (weird) use case.
This fixes an inconvenience in the VCS api when working with javascript. VCS graphics methods have the
ext_1andext_2attributes, which insert-1e20at the beginning or1e20at the end of thelevelsarray, respectively. Since there's no built-in storage for those attributes, this causes some headaches. JavaScript expects ext_1 and ext_2 to just be normal booleans; it's easiest if the user doesn't need to futz around with the levels array when turning on / disabling extensions. So, this just makes sure that ext_1 and ext_2 are set based on the boolean values provided, once the levels have (possibly) been set. If-1e20and1e20are already there, it'll behave exactly the same as before. If they aren't, it'll automatically repair the levels array to be like VCS expects. This might cause an issue if the user sticks 1e20 or -1e20 as levels, but I'm willing to punt on solving that specific (weird) use case.