Algodoo

It's not that the event handler spits out exceptions. You hav eto see the events like onCollide as mere functions that have a reference in the algodoo main code, where it is executed by the event handler. If you execute it yourself, then thats alright, everything will run since you also call the function along with a parameter. What I meant by invalid/not working is that the data may not fit. Imagine you call onCollide(true), and in that onCollide is the line:
e.this.vel = e.this.vel*0;
In this case this very line will FAIL because it would compile to "true.this.vel = true.this.vel*0) which makes no sense at all. Such lines can only execute if e is a value to which such statements apply. So if you use the onLaserHit event and trigger e.geoms onCollide using e, then things like e.this will response awkwardly because "this" is the laser that triggered onLaserHit, not the box that got it's onCollide triggered. It's all about you not using e like you are supposed to. Hope you understand it

nice to see some young scripters in algodoo again. I remember when I made my very first published scene, it also consisted of a mouse aiming laser

Ultra, I got a heart attack when I saw that you were back again. Didn't you learn anything while you were gone. Please stop making your camp stuff and start making proper things. And if you have to make freaking camps and that stuff, PLEASE POST IT IN THE RIGHT GROUP

I can do that with both direction while keeping every single property of the marble as long as it's not made of multiple parts.

first of all, scene.my.motor=scene.my.motor=true makse no sense. If you do sth. only do scene.my.motor=true. There's no need to selfassign a variable. Second of all, you need to open the console(f10) and initialize the variable so that it wont break. so write ni the console scene.my.motor = false;
then you can type {scene.my.motor} in the motor field of your hinge. If the variable is not assigned in the console, what is algodoo supposed to give the hinge? That's why the code breaks at that instance.

Just wait, soon there will be my share of an undertale fight on algodoo, and it will contain a lot of undertale things like the 4 menu buttons, items, fight elements, multiple attacks etc.. It will take some time to code, but I will promise it will be worth the wait.

@DrBalk
I'm glad you like the scene and the work I put in it. In fact, the primary way of learning thyme in algobox is via other thyme scenes, at least for me. I hope you will like my next scene once I have the time to make it

Kinda busy at the moment, so the next scene will take a while again.

Wierd. If it stopped then there must have been something that interferred. Maybe your system ran out of memory, since the increasing amount of white pixels can take a small toll on algodoo. I haven't witnessed this error before. I will look if this has a specific source and fix it if that's the case.

Okay so I noticed that the blocks are slightly leaking in position after a while, propably due to algodoo rounding errors. I am not sure why they are not always equally severe, but it could happen if you run algodoo in the background, that the rounding is stronger, and thus a larger error exists.

Once this scene surpasses 50 or 70 downloads, I will update it with a generalized version where you can enter a sequence of left, right, backwards and forward commands in an array and then let the calculator cycle through them. However I am curious about your version, so do your thing first

I also thought of adding a rounding command every 1000 steps to fix the rounding errors. Nice way of computing it tho. I will remember the sim.tick for the future.

So it is true that scene.RemoveEntity decreases garbage piling to a minimum? I am quite impressed how much the code can be improved with just the right tools. Thanks for showing me these

Oh thanks Xray for poiting that out. I already know the {} trick that calls a function every update that returns the contained value(like (x)=>{y} returns y), just forgot to add it. Is fixed now.

You can flip the screen by changing the camera rotation using the code

My tag filter is permanently set to "technical only" except for exceptions like right now, and since then I actually uploaded multiple scenes in less than a week! The tag seperation is a blessing, even if a little complicated.

Uh, change the restitution to something around 1 or above?

Propably an Admin, noone else has the power to do so. And out of all Admin's it's propably XRay, the most active of them. And out of all reasons, it's propably a GOOD one because you propably violate certain scene rules.

@calvin1390
The red box uses thyme, a programming language, to move in a special fashion that makes it reach the end if it has enough time to do so. It basically always goes to the right if possible, and if not, just walk along the path.

You are right icrls. That's why I try my best at helping people getting better at things like Thyme, so they can make tech scenes too. However, I only rarely meet algobox users that are willing to cooperate with me.

@ngphil
On my system, the dot does not seem to move, only changing color using z. Did you know you can actually make a dot move in a 3D and 4D enviroment and still show it using only said dot? It requires some sort of anchor to see the relative movement in the depth and kata dimension, however you can use that to model 3D and 4D figures using circles and springs connecting them.

This isn't technical ,why is it tagged it?

How to set the collideset of another object:

First, make a number summing up your desired collision sets:
if Collision layer A then +1
if Collision layer B then +2
if layer C then +4
if D then +8

etc...
so if you want an object to get turned into collision set ACD you get 1+4+8 = 13

Now just tell your one object to set e.other.collideset = *your number*
then the collision partner is set to that set.

Hey Penguin, if you ever want to know some of my scripting tricks, just send a Private message in the algobox forum to me and I might teach you some new things. You can also check out this page on the algodoo wiki for starters:
[ulr]http://algodoo.wikia.com/wiki/Thyme[/url]

So here's my real reaction today after running algodoo(this is a true story)

So, I turned on algodoo today cause i look about once per month to see if sth. changed. I opened the news tab tagged to only technical, got dissappointed cuz nothing new, so disabeled tag sorting for a while and found this scene this way. However, the first thing I did when i checked the new page again was "Is this seriously still going on...". Resorting to popular page only showed some stuff like this scene, nothing phenomenal.

Why did some mentally retarted group of people even begin something like the BFDI series... If noone ever invented that, we would be clean from this trash...

Also I noticed an error in your scene:

There's a recycling image on that trash can. HOW CAN ONE RECYCLE SOMETHING LIKE THAT. THAT'S HARMFULL TO THE ENVIROMENT!!!1!!111!1111eleven

Hoopla, didnt notice the link syntax was wrong. I looked up at the forum, so I thought it would work

@icewolf

It's not that hard actually. First you give the boss HP by adding a HP variable that says how much HP he has. Then everytime you want him to loose HP, you decrease the HP by that amount. Ultra basically used the one red box to lower the public scene.my.bossHP variable by 1 each time a marble hit's it.

@Ultragamer
Hey Ultra, ever considered adding more thyme code to your scenes? This scene has basic basic thyme, but I could help you use more advanced codes(still relatively simple) so you can add cool effects to your scenes. For example make your boss act when the marbles attack. Wouldn't it be cool if your boss could teleport the marbles or throw them back? Or even move across the stage? Imagine your boss moving back another stage everytime he lost 25HP, so the marbles need to catch up first. Such ideas and many more could be put into action using scripting. Just ask nicely and Ill tell you some of the tricks I learned.

Your script does not work for a series of reasons:

First of all, your three lasers all edit the con variable at the same time every single frame, since every one of them has scene.my.con = xxx in their poststep. If you want keycontrolled changes, use keys.isDown("up") ? {} : {} instead. Lasers are a method, but using keys.isdown is more efficient.

Second of all, turning the lasers on has no effect to the scenes since theres neither a onLaserHit nor a onHitByLaser coded somewhere

Lastly, the scene.my.rpm variable is used nowhere, so changing it has no effect.

If you want to know some general thyme, look at this page created by me and someone else:

http://algodoo.wikia.com/wiki/Thyme

for your code to work, remove all code and put it in the hinge like this instead:

postStep: (e)=>{
keys.isDown("up") ? {
motorspeed = math.pi * [Write your RPS here, not RPM. You can also write the formula for it here];
} : {}

Depending on how you want to influence the motor speed or whatever you like to change, add more lines for calculation or whatever you like.


}

Nice you like it. I updated the gun to reduce lag and improve the usability. The lasers are now glued to the gun and keep rotating, making it look more awesome C:

@That_Book
Pootis-Man won't quit algodoo as long as you guys dont quit your stuff. As long as the trash keeps stacking, pootis man will keep burning trash, and the fire will burn forever