Algodoo

hmm, what if, instead of cliccking on the buttons, one relies purely on hotkeys(or maybe the keys.isDown("mouse_left") function plus moving the buttons in another layer). that way one wouldnt have to worry about accidentially attaching something to the buttons. One would have to disable all default hotkeys first tho, however those are annoying most of the time anyways. Writing stuff to a file very likely requires external software however, since algodoo can not interact with file systems besides the integrated scene saving mechanics.

One thing you should also, albeit this likely already exists in s_noonan's implementation:

New Hotkeys. By activating "hide-mode", you disable all hotkeys, even tho you still imply them on the tool icons. You should add an onKey event in one of the buttons(or one in each button for each key) checking if

e.keyCode == hotkeyForThisTool && e.pressed ? {Tools.x.selectTool} : {}

for each hotkey that is active in the scene. By making each hotkey check in each individual button, removing a button(disabling the tool) also disables the hotkey.

Pattern #4 seems to be a very interesting variation of the "T-Square" surface.
In the T-square, the edge is filled with more and more advanced figures. If we were to give each figure on the edge a number according to it's size, the sequence of numbers across the edge has a simple pattern:
01020103010201040102010301020105...
Every figure of "rank" x appears once every 2^(x+1) figures.

In Pattern #4, you also have a kind of basic figure(the small line stumps). If you number the figures here and look at the sequence, the result looks a bit similar, but different:
000010000100001000010000200001000010000­10000100002...
every pattern of rank x appears 4 times in a row, and when it would appear for the 5th time, the next higher rank appear instead.
The shape of the figures also has some differences:
In the normal T-square, every figure "sprouts" into a double-sided T-square line where only one x-1 ranked child appears per side at the very end, and another x-2 child in the center of each side(This then recursively repeats inbetween as the lines "grow").
In this figure, each "tree" has a grand total of 5 x-1 children(2 left and right each, 1 at the tip). Additionally to this, it has 4 x-2 children at it's square base(2 per side, 1 on each square side). These once again become more complex as each "tree grows". If it weren't for it's ridiculous size(5^x units, depending on the rank of the largest tree), it would actually be a really cool figure to look into. Nonetheless a cool "discovery"!

UPDATE:

I did some experimentation in L-Systems to try and replicate the pattern(Without looking at the code!) and found out that your pattern is in fact the result of an L system with:

Starting Parameter: F
Replacement Rules:
F -> F+F|F+FF+F|F+F
+ -> F+F-F+F

L-Systems are replacement systems where you use a starting text and replace each symbol with the specified chain of new symbols. the final result is rendered by interpreting F as "forward", + as "turn left", - as "turn right" and | as "turn around".

I have taken the liberty of entering the pattern into a website for you and got the link for it here

If you want assistance with learning how to do scripting, feel free to contact me, either via the algodoo forum or by typing out my Username in a comment(which allows me to see the scene when searching for "mentions")

I think Unity falsely interpreted the use of rotation as "current", and created these components to transfer this "current"(rotation). In other words: This scene has circle gears and a gear train including a transmission, plus a gear rack as an actuator.

"Good evening Sir. A murder happened recently in your neighborhood and we just wanted to ask some ques-"
"Please officer, I promise the bags in my garage weren't used for corpses, and the guns in my attic really are just props, and I can absolutely ensure you that the sounds the neighbors heard 5 days ago were not me and the victim fighting because of a debt! I am absolutely innocent!!!"

To make proper gravity, use this code instead of the one you use:

Antigravity:
e.other.poststep = (e)=>{vel = vel+[0,sim.GravityStrength*2]/sim.frequency;}

Nor­mal Gravity:
e.other.poststep = (e)=>{}

Check the comment I left on your first Testing area. This cheap anti-grav script has been used for this purpose for ages, even at the time when I first joined the algobox. I am surprised noone ever discovered the actually accurate and superior version.

a this

The interesting similarity of the formulas is caused by them all having a product as basis:
Spring: F=k*x
Flywheel: L=I*w
Motion: p=m*v
Capacitor: Q=C*V
The Inductor is the only part where I couldn't find a basic formula

In all these cases, a value is calculated from a constant times a variable. If you integrate each of these formulas, you would in each case end up with E=constant*var^2/2, or written differently, E=Const/2*var^2.
The reason why F,L,p and Q all integrate to E is because each describes a physical value that influences the energy in a system . Applying Force(F) increases the energy of a spring , applying momentum(p) to something increases it's kinetic energy, applying angular momentum(L) to a flywheel increases it's rotational energy, applying more charge(Q) to a capacitor increases it's electrical energy. If you were to integrate every variable, what you would get is the SUM of all the energy that you put into the system at each infinitesimal moment of time. Since the system becomes more "resistant to change" as you add more energy, the variable component actually applies squared, as both the variable and the "resistance" increases as you sum up these infinitesimal changes in energy(which is also a natural consequence of the rules of integration, x^n-> x^(n+1)/(n+1)). This can be seen in it taking longer to discharge a capacitor, taking longer to stop a flywheel or a moving object, a spring resisting with more force as you compress it, etc.

Long story short: Most forms of energy are composed of a constant and a changing variable that gets more difficult to change as energy level rise, thus forming the pattern E=const/2*var^2

Wonderfull scene, definetly takes a lot more efford than the average marble race, especially since you made 6 levels at once. One can clearly see that you have improved a lot in scripting, and this scene has tons of scripts. The only thing that stroke me as annoying was the part with the missile triggered buttons. The missiles have pretty low accelleration and as such make huge circles, thus often crashing into walls. While this is alright, since it requires the player to be carefull, you have to cut corners at the same time since the lifetime of the missile barely lasts long enough to reach the button. Thus you both have to counter the missiles slow response time AND cut corners wherever you can, which really makes the section unneccessarily hard. Nontheless, you did a phenomenal job here and I certainly look forward to more scenes from you!

Captain obvious actually predates that commercial. Hotels dot com just had the smart idea of applying this principle into a successfull comercial idea. Otto dot de actually had a similar idea by using HideThePain Harold in a commercial, who is stock photo model become meme that always looks like they are suffering internally.

Finished it first try, no damage taken, and I love it! This scene is pretty good, and while it is honestly somewhat easy for someone like me, im sure others might find it harder. As such I feel like it could be longer or more complex, but what you made here is definetly high quality.

Andrew, you simply uploaded the scene "Marble run 1" by Dave'sAlgodooCreations, after having toyed with it a little, on a public scene sharing platform. This is technically a copyright violation, as the marble machine is not your creation and you did not credit Dave'sAlgodooCreations for it.

Immediatly after running the scene I noticed an annoying flaw:

NEVER put the jump script in a place that is blocked by moving.

You put it in a place that prevents you from jumping while you are holding any other move key, which is super bothersome for proper gameplay.

I spent some time optimizing your code, in order to fix this and other issues. Enter each of these scripts in the corresponding field, including brackets:

angle: {math.pi}

angvel: {0}

poststep:
(e)=>{
keys.isdown("up") && _jump ? {
vel = [vel(0), 2];
_jump = false
} : {};
scene.my.pos = pos
}

update: (e)=>{}

I noticed some bad scripting habits or obsolete parts:
In a lot of your periodic scripts, you wrote things like "0.4+0.5*sin" or "0.1+0.2*sin". You have to remember that sin always goes from 1 to -1, meaning "0.1+0.2*sin" goes from -0.1 to 0.3, which might lead to wierd results, as happened in the changing length Laser Array, or with the refractive index.

Another thing I noticed was the change-position part. there is no reason to add "+ [0,0]", it has as little of an effect as adding 0 to something.

Huh, I didn't notice you made something similar literally a month ago. Funny timing I guess. Nontheless, I am pretty glad to finally have understood Fourier transformations and series sufficiently enough to make this scene. Who knows, maybe I can figure out how to extend it over to quaternions to look into XRay's 3D-challenge. Would certainly be intriguing.

@Xray
Chances are the preview image box did not self-destruct when the scene was loaded and as such collided with the actual scene content. Sometimes I forget to add the code due to how volatile it is, or perhaps onSpawn doesn't execute properly when loading the scene from algobox.

The thickness does indeed change things a little. At minimum, your drawing is raised by the radius/thickness of the brush. If you draw at an angle, it is raised by radius/cos(angle), so steeper angles raise it more. At outer corners, you also end up with circular segments. If you want precise sine waves, you could trick the program a bit by using a scripted box that spans the entire interval and moves up and down according to your desired formula. This way, instead of measuring shape over position, you measure value over time. I could update the scene to take care of time synchronization and easy customization for this.

The amount of data points is determined by the scene.my.stepcount variable. Increasing it makes the laser move slower, thus increasing the recording time while squeezing the data points closer together.

To the right of the green trigger-box is a diagram with a frequency- and amplitude-axis. When the scan is complete, 3 points per calculated frequency are spawned in this diagram, with the large point being the total amplitude(and phase) per frequency, and the 2 smaller dots being the amplitudes of the wave when split up into phase-0 and phase-90 components(sine and cosine).

The Algorithm used is called Fourier series, which acts by multiplying the given curve by (co) sine waves of some frequency(frequency 1 means 1 cycle over the entire interval), calculating the average across the interval, and multiplying the result by the same (co)sine wave again. This is repeated for all integer frequencies for both sine and cosine and the resulting waves summed up to yield the final function. These individual waves are what the colored boxes draw when the redult is drawn, while the white box draws the sum. As all waves have a period thats some integer fraction of the entire interval, the result behaves the same beyond the interval.

@Xray I have updated the scene to incorporate your suggestions. Thanks for the feedback!

To answer your question about real world applications: Bezier Curves are used anywhere where you want a quick and easy adjustable curve. This is anywhere from Art software to create curved lines (Even in MS Paint), to animation software to create smooth transitions between Keypoints.
Now Splines on the other hand find application in more advanced applications. For example they are used to model and approximate data. A much more common example of their use is in 2D and 3D modelling software for creating smooth edges and surfaces, for example when designing the frame of a car, or to create a character for 3D animation. In those cases, you often find an even more complex version of splines called NURBS, which basically combines the approach behind Bezier Curves and Splines to create a really powerfull curve tool that is both smooth and easily adjustable. I might make a scene about NURBS too, once I fully understand just how exactly they work
A common use for Cubic Splines is calculating paths in real life. Rollercoasters, train tracks, anything where accelleration is important might have been made using Cubic Splines to achieve that smooth transition between segments. After all, you don't want to ride a rollercoaster and have the path suddendly change in curvature, the sudden change in force caused by that would knock you back and forth!

@Xray seems like uploading a scene by editting it in browser does not work as I hoped it would. That or I did something wrong lol.
Either way, it is fixed now!

Yay, I made it through all 17. I knew watching sesame street nonstop as a kid would come in handy someday!

I'll admit, some of them where tricky to find though. Good work!

As someone who is soon going to be a Masters of Science in the field of Laser Technology, I appreciate seeing some accurate Laser scenes
For those curious, this is a Michelson interferometer. As you can see when moving the reflector, the overlapping blue and yellow springs ("Waves") rapidly alternate between "bright" and "dark" pulses, modelling wave interference. The main thing that's not accurate there is the fact that the pulses seem to visibly travel across the springs, which is caused by the springs not being the exact same "frequency". Realistically, the entire overlapping region would change color in unison.
Since interference repeats every full wavelength of a light wave, and light typically has a wavelength in the range of nanometers, you can measure distances at incredible resolutions with this principle.

@Xray The last three elements of the texture matrix are technically the elements for a 3D transformation. This may seem confusing since the transformation matrix is meant for 2D textures, but it's actually a clever trick thats used to do stuff in 2D.
Specifically, the isssue those three elements solve are Translation. Translation is the shifting/moving of an object through space, and is usually done using vector addition. The transformation matrix is something that is multiplied however, not added, so a regular 2D matrix (2x2 elements) cannot perform translation by itself. To solve that, the matrix is expanded into a 3D transformation matrix (3x3). The two Translation coordinates of the right column are actually a Skew operation in the 3rd dimension, skewing the x/y axis with the "made up" z-axis. This allows creating translation from this made up 3rd dimension.
The side effect of this solution is the lower row of the matrix. Just like the right column converts the made-up Z-Axis into changes in X and Y (the 3D skew that is used as 2D translation), the lower row can convert X,Y and Z coordinates into Z-Coordinates. This is technically not useful to 2D textures, however when the texture matrix is applied, the resulting 3D vector is always "projected" onto 2D using x'=x/z and y'=y/z. Because of this, changing those last 3 elements causes somewhat wierd and unexpected changes to the image. The most intuitive effect I can explain is the final component of the matrix, the lower-right corner. Setting this one to 2 effectively doubles the Z-coordinate of the 3D texture coordinate. Because the projection divides by the Z coordinate, this effectively halves all image coordinates, thus sampling a smaller region of the image space, thus effectively "zooming" in on the image.

On that topic, I may upload a scene on projection soon, both the intuitive 3D projections, and the more unusual projections used for curved spaces.