Don't worry. If you want to remove the dependency of a geometry on a light entirely, just delete the "scene.my.lightPos#" variable linked to the light's world position and the "_lightingPreset" function surrounding it. Also delete any "_colorBlend" function that contains only one "_lightingPreset" function. To find out which variable the light's position is read by, look in the light's "onSpawn" function.
I didn't necessarily mean that the code was simple, just that the lighting technique was. Also, I don't really have an extensive background in coding, that is, when it comes to different languages. The only one I really know that well is Thyme. And thanks to the internet and the motivation I got from all of those interesting scenes and concepts from Algobox, the forum, and YouTube, I gradually taught myself to write many different things in Thyme.
In response to Xray:
Actually, all of the code that is listed in the center panel really isn't necessary. I just wanted to have the lighting engine along with the parallax scroller so I, among other users, wouldn't have to import the functions separately. Also, I used such a relatively complex code simply because I wanted the user to be able to freely move the object around at will without having to worry about changing the function in order to set and reset the object's position. Likewise, I wanted to be able to make dynamic (moving or physics) objects parallax scroll as well.
Okay, so, here is the tutorial on how to utilize this function in a nutshell. There should always be two variables to control how the object behaves: _parallaxScroll and _parallaxFactor. The _parallaxScroll variable (boolean) controls whether the object parallax scrolls or not. The _parallaxFactor variable (float) controls the amount of parallax the object has (how much it appears to be in the foreground or background). A negative number makes the object appear to be in the foreground, whereas a positive number makes the object appear to be in the background. The value of the number determines how close or how far away the object will appear to be. Also, you should always keep an entity with the function in the update section of its script menu. This makes all of the objects in the scene with the correct criteria in their script menus parallax scroll. And that was a tutorial on how to utilize this function in a nutshell.
Why sure you can. You simply have to remember that each entity you use it for requires a variable to write to, the name of which should be written in the function 'scene.my.reverseOrPlayTimeMultiVar' in the form of a string. See the script menu of the green box and the text of the second most left black panel for more insight.
NOTE: These functions only work smoothly for one and correctly for up to three objects at a time. The functions also will not keep any constraints used on objects after the first rewind.
Yes, and any of the scripts you might have assumed to be identical to each other might be slightly different for slightly different cases in which to use them. For panels that have some identical functions in common, those functions are included to make them partially or completely independent from the rest of the functions (meaning that you do not have to have all of the panels if you just want to use the functions on one of them).
The springs provided in the scene contain special functions and scripts that make the interface operate when the springs are attached to different geometries. The instructions are referring to those springs for the user to utilize. (Also, sorry about the alternating colors; I removed that part.)
This scripting language is actually the very first one I have used. It was what got me interested in programming. And yes, I have spent a lot of time studying the ins and outs of the language and its flaws and the workarounds for the flaws, but I also have taught myself the mathematics that were required for constructing the code.
I just think that in the long run, the special springs can help create far larger interfaces than the example in this scene, interfaces that require exponentially larger amounts of code. Not only that, but it also makes duplicating an interface and changing the icons' positions in respect to one another far easier than digging through that long piece of code and searching every line until you finally find the position of that one icon to change it. It also can be a tool for people who know less about the Thyme language to use just as, if not more, easily than the professionals who create their interfaces from scratch.
Sorry about that. I had received another message from Xray about it and have now fixed the issue with this scene. I am planning on fixing the issue with the other scene you mentioned as soon as possible.
For Xray (and anyone else who played the previous scene): The boxes falling down and doing nothing else was the result of a simple typo in the code, one I did not realize there was because my 'config' file was still messed up from the deleted scene. I seemed to have missed renaming one of the functions in the process of fixing the scene.
I forgot to mention that blur artifacts do appear when simply enabling "follow" on an object. This is due to the delayed response of the camera for some reason. However, if you type in the objects postStep function "(e)=>{scene.camera.pan = e.this.pos}", you will not see that artifact, since the camera's position is updated much more frequently. Furthermore, to eliminate all blur from an object (and make yourself nauseous all the while), you can also add to the function "; scene.camera.rotation = -e.this.angle". I've tried it before and it worked.
