Algodoo

Well,I found that very useful

Thanks faytree!

Well, you could simply do onCollide(e)=>{e.other.onLaserHit(e)}. It calls the onLaserHit event using the event package from the oncollide event. It slightly differs because of changed attributes(rendering e.this.x or e.geom.x broken) but has a similar effect. You dont really force it to be true, you simply call it and give e the property "true". You could also do e.other.onCollide("pizza"), e.other.onCollide(this) etc. since they all send a certain piece of data using the e parameter, however you always have to watch when the event uses e.x parameters, since the sub-value in the package is often missing then

Thanks, FRA32! It just proves that there are more than one way to do things in Algodoo.

Something you said that I don't understand is: "rendering e.this.x or e.geom.x broken". What do you mean by "broken"?

Thanks again!

What I mean is that "e" is a variable passed to the function onCollide by the eventHandler, as seen in the funtion declaration (e)=>{}. The Event handler, as you probably know, passes a data package with all data about the event in the style of e={this = {pos = bla; vel =bla...}; other = {bla, bla, bla}}. What I meant however is the fact that if you manually trigger the functions, most of the data will most certainly be missing. If you do onCollide = (e)=>{e.this.onHitByLaser(e)}, you pass the event package of the onCollide event to the onHitByLaser event. However, that event usually receives data in the formation of e.this and e.laser instead of e.other. Since you send "invalid" data to the function, it still runs, but if there is a call of "e.laser...", it wont work because onCollide never provides data under that name that could be passed to your call of onHitByLaser.
So that's why certain variable calls usually are broken this way due to differing naming. However this now brings the idea of someone designing a custom event function like the classic "onStopHitByLaser" or something different, and pass a either valid argument from the "root event", or create a completely new "e" variable in the style mentioned above. So you could write PostStep = (e)=>{
_timer = _timer - 1/sim.frequency;
_timer <= 0 ? {e = {
time := sim.time;
pos := e.this.pos;
etc...;
};
e.this._onTime(e);
}: {}
}
with _onTime being a custom declared function/variable inside the object.

Ah, I see what you mean! I knew about the event handler passing a data package of multiple items, but I did not know that the event handler would consider a single packet of data as "invalid", especially since it appears to work as expected! You would expect to receive an exception message, but I do not (unless the message was being printed in the console which I missed!).

It's still fun to try "different things" even if they are not considered good programming practice as long as they don't cause any damage.

Thanks for your input!

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

Yes, I do! Thanks very much for clarifying.

- Good job, i will be experimenting with this
- Can this be used to onSpawn, onDie, etc.?
- Is there a way how to create "custom events"?
Like I script something like this: onExample = (e)=>{blah;blah;blah}
and this script can be used only by onExample(true) script?

Example: i want scripted gun but i want it to be safety so onCollide event is bad idea, so i create "custom event" that can be triggered only by script, so NO incidents can happen

You really don't have to use funky scripts like I suggest in this scene. You can create your own custom functions the normal way as shown in the following tutorial: Thyme Tutorial

you should do more of these 'script, tutorials mister xray! im terrified of script! but can see how useful it is to bend the physical laws of the algodoo universe to your will. sometimes i reverse engineer peoples scenes and find the odd component that has 'magical properties' and study the changes made on that object, but still dont undertand why the magic works, i must judt accept that it works. this scene youve done is very similar to what i want to do on a scene im working on atm. how can u make an object disappear when hit by a laser??

tomskiwomski -- No need to be terrified of script! It's just another method of controlling how your scene will look and operate. And there's nothing "magical" about it. Think of it like a shopping list that your wife or girlfriend gives you. Sort of like this:
1. Go to grocery store.
2. Buy one carton of eggs and a loaf of bread.
3. Go to carwash. Wash car.
4. Do not stop at tavern to drink.
5. Go home. Kiss wife/girlfriend and tell her how nice she looks.

My point is that script is nothing more than a sequential list of instructions that tell Algodoo components what to do and how to do it. If you make a mistake in the coding, the scene will not work as expected, but nothing bad will happen to you. YOU are the master of what your scene does, and not the other way around! Programming with Thyme script is also FUN. I always enjoy seeing the results of a scene that I've spent many hours or many days (sometimes weeks) planning, coding, and debugging, and then showing it off to others on ALgobox! When you first start to learn how to write script, your programs will be simple and buggy. But that's how you learn. Like learning a foreign language, it's difficult and it feels awkward until you work with it long enough, then it becomes much easier and more natural.

Try it!

i likeyou list of instructions! i think my partner would too! lol what if im too busy on algodoo?? hahaha anyway thanks for your words of wisdom

been examining your script mister xray, be easier translating egyptian!! lol any idea at all how to make an object delete if hit by a laser???

An easy way to make an object delete is to give "TimeToLive" a value of zero when the object gets hit by a laser.
For example: onHitByLaser (e) => {timeToLive = 0}

thanks. so if you was gonna learn script from scratch where would u start? i see all the boxes and kinda get it but how on earth you meant to know what to write in the boxes!!

Log in to the Algodoo FORUM and go to the heading labeled "Thyme Scripting". That's a good starting point. There is a ton of good information there. You can also ask questions, but before asking basic questions, first do your own research to try to find what you are looking for. Then experiment with your own basic scenes so that you will learn what some of the basic commands do. As I mentioned before, it will seem awkward at first, but once you start using script and realizing how much more power you will have with it, you will always want to use it in all of your scenes!

thanks 4 the info, your laser works a treat!!

You're welcome!