"Plain English" "onCollision" Events

[Psmith]

Or plain (any language). There are many possibilities that exist in the engine for "physical" reactions. However, there is an entire category of "events" that could be initiated via the "onCollision" property of any object. Most of these could be classified as "canned" or "cookie cutter" actions and reactions.

Since there is a large audience of "non-coding" users of Algodoo, there should and could be an entire category of actions and reactions that could be initialized and enabled for collision events that require no use of "coding".

Some examples would be: animation sequence triggers, motors starting and stopping, springs enabled and disabled, movement starting and stopping, gravity enabled and disabled, fixates enabled and disabled.

There are many more actions and reactions that could be put to use in this fashion. Feel free to add to the list.

Psmith

[Chronos]

No. No no no no no. Algodoo is a physics engine. Not a coding engine. Thyme is fine just the way it is, where not as many people would know it.

[Psmith]

Chronos:

And why do you think its a good thing for people "not to know it"?

Psmith

[RicH]

Algodoo is a physics engine. Not a coding engine.

Quote for emphasis.

[Chronos]

Chronos:

And why do you think its a good thing for people "not to know it"?

Psmith

Rich pretty much said why. People should focus more on the mechanical aspect of Algodoo and not the coding one.

[Versieon]

Most of this is already possible with Thyme.

And yet you just said this.

Thats probobly why simple thyme commands would be easyer for most, then they could make built in chalenges without having to be realy good at thyme.

[RA2lover]

the script menu is only in the advanced mode. so, script is for the pro users, therefore there is no need for much of a tutorial

[Chronos]

Most of this is already possible with Thyme.

And yet you just said this.

Because if you know enough Thyme, you make it. If you don't ask someone else to.

[Psmith]

Chronos:

Oh, I see. Keep advanced functionality out of the hands of the "non-pros". In other words, there needs to be an "inside group", an Algodoo priesthood, so that the "layman" needs to consult with an Algodoo priest if he wants to create anything using "logic".

Keep it difficult to keep out the uninitiated.

Makes good sense.

Psmith

[Chronos]

I'm not saying that at all. I'm saying, and I'll use bigger letters so you can understand it, Algodoo is a physics engine. not a coding program. I think that not so many people should know Thyme to keep Algodoo a physics engine.

Understand?

[gradyfitz]

Chronos:

Oh, I see. Keep advanced functionality out of the hands of the "non-pros". In other words, there needs to be an "inside group", an Algodoo priesthood, so that the "layman" needs to consult with an Algodoo priest if he wants to create anything using "logic".

Keep it difficult to keep out the uninitiated.

Makes good sense.

Psmith

At the moment, Thyme is an extremely simple language (to me at least), I think it's very easy to understand and use, of course, there are those who don't know how to use Thyme, but there are quite a few tutorials around explaining how to do various things in thyme (like my tutorial or Paradigm29's basic onCollide scripting video for example), Thyme is an important part yes, but there are only certain areas it is applicable, and chances are, you don't need it if you can't easily understand these tutorials (provided you're english ), for example, the main reasons you might need to understand thyme are graphical effects or infinite source of something or for perfect precision object creation, for the majority of situations, physics will do , if you don't know how to move something along a certain path, there are methods of doing so without any thyme.

Thyme is like an extension, so you can optimize your situation, and build a more resource heavy situation, or build things that are simply impossible to simulate on a large enough scale like for example, simulating realistic physics. Most things can be achieved without thyme , the main advantage of Thyme is optimization, and if you require optimization, it's for one easier to do it yourself than for you to say "optimize" to the program (as if this happened, it would only be minor optimizations), and also, if you need to optimize something, generally, you can get someone to do what you want to do (like for example, if you need some plain English translations to thyme, I'm pretty sure people here would be able to help you, and would (if not, people can always message me, I'll be glad to help)), and also, "if he wants to create anything using "logic"", I'm not sure what this means, because you can just use logic gates for that, or, build a mechanism to run the same thing. The hardest part of Thyme is maths (not very hard for me ), but that is involved in normal physics calculations that you use (or at least, for me it is).

I don't think Thyme needs to change it's method, it's simple enough as it is , if you need help with something, just ask, the users here are pretty friendly and willing to help . Keep in mind that even some of the top level Thyme users ask for help .

- Grady

[izacque]

At the moment, Thyme is an extremely simple language (to me at least), I think it's very easy to understand and
...
simple enough as it is , if you need help with something, just ask, the users here are pretty friendly and willing to help . Keep in mind that even some of the top level Thyme users ask for help .

- Grady

exactly. tutorials are the way to go. If you can't understand the tutorials, then you have no business messing around with thyme.

[Psmith]

Yes, Algodoo is a physics engine. But, it seems to want, by design, to be more than that - as expressed in the fact that a scripting "language" exists at all. Somebody, possibly the designer, wanted to add some additional forms of interactivity to this "physics" engine.

I just think scripting needs to emerge from the stone age and become something friendly and understandable for anyone to just pick up and use. Maybe not, at first, for every kind of event that Thyme was designed to address, but, at least, for the most common "physical" events, starting with collisions and motors and basic x,y movement.

In case you think that programming languages have to be cryptic and "code-like" in order function properly and be fast, there are plenty of alternatives to "scripting" that don't look anything like the "C" "language".

In case you haven't taken the time: http://www.runrev.com/

I suggest something understandable, (in plain English, or any spoken language), like "Rev" for creating processes that Algodoo understands.

There should be no reason for people to be forced to wrap their minds around symbolic, not readily comprehensible code. Nor, for them to depend on the priesthood of the code to get things done.

Psmith

[RA2lover]

thyme code is already comprehensible readily. the variables are mostly self-explanatory, with a couple of exceptions, like extensive use of math(think about the portal derivative sentence"thank you for helping us help you help us all". it's in plain english but it's a little hard to understand when heard). in that case the main issue is the usage of brackets. in thyme, brackets are for determing orders on which calculations are operated, square brackets for arrays of values, and curly brackets or events. a more viable idea would be for people to get granted access to read only variables, like GeomID, vel, and similar. even by then you would have more problems with plain enlish itself than with just numbers. i'll give an example:

Phunlet-saf­e missile prototype

RA2lover

Rating:
Filesize: 42.97 kB
Comments: 7
Ratings: 4

the thing to luck upon is to the warhead itself. else, how would a computer program be able to understand in english "check if target is within range. if so, spawn 48 circles in a tight pattern facing the missile's front forming an arc with individually preset velocities, and custom changed density, color, programmed individually to disappear upon colliding with something after moving it along, then make the mechanism un-usable for later use". and that wouldn't let to set some things like the angle on which they form onto, and similar.
wow, what a wall of text

[Psmith]

It might result in a very large wall of text, but you could intersperse with predefined pictures where they are more economical. Even so, that wall of text, if punctuated properly, and assuming the author could write comprehensible commands, would remain intelligible forever, to all readers of the language it was written in, (English).

Even an English-like language written to instruct a machine through a series of process steps would have to be written with a particular syntax - it would limit which words could be used in a statement and under what conditions. It would simply be more readable to "ordinary" users than Thyme code.

Kodu by Microsoft has what seems to be an ideal combination of phrases and pictures which, when combined, are capable of producing extremely complex behaviour, and that, in record time.

Psmith

[gradyfitz]

It might result in a very large wall of text, but you could intersperse with predefined pictures where they are more economical. Even so, that wall of text, if punctuated properly, and assuming the author could write comprehensible commands, would remain intelligible forever, to all readers of the language it was written in, (English).

Even an English-like language written to instruct a machine through a series of process steps would have to be written with a particular syntax - it would limit which words could be used in a statement and under what conditions. It would simply be more readable to "ordinary" users than Thyme code.

Kodu by Microsoft has what seems to be an ideal combination of phrases and pictures which, when combined, are capable of producing extremely complex behaviour, and that, in record time.

Psmith

Though what if you had to put some advanced systems in? The text you placed in would be much more confusing than your original code, for example...
A simple code like this:

Code: Select all

Scene.my.SpawnMech = (a1,a2,a3,a4,a5,a6,a7,a8,c5,c6,c7,c8,d5,d6,d7,d8,e1,e2,e3,e4,e5,e6,e7,e8,p1,p2,p3,p4,p5,p6,p7,p8)=>{

    Scene.addBox{size := [0.01,0.01];pos := [c5,d5];color := [0,0,0,1];geomID := 25;body := 0;collideSet := 0;density := 1e+006};
   Scene.addBox{size := [0.01,0.01];pos := [c6,d6];color := [0,0,0,1];geomID := 26;body := 0;collideSet := 0;density := 1e+006};
   Scene.addBox{size := [0.01,0.01];pos := [c7,d7];color := [0,0,0,1];geomID := 27;body := 0;collideSet := 0;density := 1e+006};
   Scene.addBox{size := [0.01,0.01];pos := [c8,d8];color := [0,0,0,1];geomID := 28;body := 0;collideSet := 0;density := 1e+006};
   a5 != 0 ? {Scene.addBox{size := [0.01,Scene.my.abs(a5)];pos := [c5,d5] - ([Math.sin(e5),Math.cos(e5)] * (a5 / 2.0));color := [1,0,0,1];angle = -(e5 - Math.pi);geomID := 15;collideSet := 0;density := 1e+006}} : {};
   a6 != 0 ? {Scene.addBox{size := [0.01,Scene.my.abs(a6)];pos := [c6,d6] - ([Math.sin(e6),Math.cos(e6)] * (a6 / 2.0));color := [0,1,0,1];angle = -(e6 - Math.pi);geomID := 16;collideSet := 0;density := 1e+006}} : {};
   a7 != 0 ? {Scene.addBox{size := [0.01,Scene.my.abs(a7)];pos := [c7,d7] - ([Math.sin(e7),Math.cos(e7)] * (a7 / 2.0));color := [0,0,1,1];angle = -(e7 - Math.pi);geomID := 17;collideSet := 0;density := 1e+006}} : {};
   a8 != 0 ? {Scene.addBox{size := [0.01,Scene.my.abs(a8)];pos := [c8,d8] - ([Math.sin(e8),Math.cos(e8)] * (a8 / 2.0));color := [1,1,0,1];angle = -(e8 - Math.pi);geomID := 18;collideSet := 0;density := 1e+006}} : {};
    a1 != 0 ? {Scene.addBox{size := [0.01,Scene.my.abs(a1)];pos := ([c5,d5] - ([Math.sin(e5),Math.cos(e5)] * (a5)) - ([Math.sin(e1),Math.cos(e1)] * (a1 / 2.0)));color := [1,0,0,1];angle = -(e1 - Math.pi);geomID := 11;collideSet := 0;density := 1e+006}} : {};
    a2 != 0 ? {Scene.addBox{size := [0.01,Scene.my.abs(a2)];pos := [c6,d6] - ([Math.sin(e6),Math.cos(e6)] * (a6)) - ([Math.sin(e2),Math.cos(e2)] * (a2 / 2.0));color := [1,1,0,1];angle = -(e2 - Math.pi);geomID := 12;collideSet := 0;density := 1e+006}} : {};
    a3 != 0 ? {Scene.addBox{size := [0.01,Scene.my.abs(a3)];pos := [c7,d7] - ([Math.sin(e7),Math.cos(e7)] * (a7)) - ([Math.sin(e3),Math.cos(e3)] * (a3 / 2.0));color := [0,1,1,1];angle = -(e3 - Math.pi);geomID := 13;collideSet := 0;density := 1e+006}} : {};
    a4 != 0 ? {Scene.addBox{size := [0.01,Scene.my.abs(a4)];pos := [c8,d8] - ([Math.sin(e8),Math.cos(e8)] * (a8)) - ([Math.sin(e4),Math.cos(e4)] * (a4 / 2.0));color := [1,1,1,1];angle = -(e4 - Math.pi);geomID := 14;collideSet := 0;density := 1e+006}} : {};
    /* Bars
*/
   h1pos := ([c5,d5] - ([Math.sin(e5),Math.cos(e5)] * (a5)) - ([Math.sin(e1),Math.cos(e1)] * (a1)));
   h2pos := ([c6,d6] - ([Math.sin(e6),Math.cos(e6)] * (a6)) - ([Math.sin(e2),Math.cos(e2)] * (a2)));
   h3pos := ([c7,d7] - ([Math.sin(e7),Math.cos(e7)] * (a7)) - ([Math.sin(e3),Math.cos(e3)] * (a3)));
   h4pos := ([c8,d8] - ([Math.sin(e8),Math.cos(e8)] * (a8)) - ([Math.sin(e4),Math.cos(e4)] * (a4)));
   Scene.addBox{pos := ((h1pos + h2pos) / 2.0);angle := (Math.atan(-((h1pos(0) - h2pos(0))) / ((h1pos(1) - h2pos(1)))));geomID := 20;size := [0.01,10];collideSet := 1;density := 45}; // GeomID = 20
   Scene.addBox{pos := ((h3pos + h4pos) / 2.0);angle := (Math.atan(-((h3pos(0) - h4pos(0))) / ((h3pos(1) - h4pos(1)))));geomID := 19;size := [0.01,10];collideSet := 2;density := 45}; // GeomID = 19

   /* Rails
   Build rails here
   */
   b1ang := (Math.atan(-((h1pos(0) - h2pos(0))) / ((h1pos(1) - h2pos(1)))));
   b2ang := (Math.atan(-((h3pos(0) - h4pos(0))) / ((h3pos(1) - h4pos(1)))));
   Scene.addBox{geomID := 21;body := 101;angle := b2ang;pos := h3pos;size := [0.03,0.04];collideSet := 0;density := 1e+006}; // geomID 21 - Base box 1 - p4 - body 101 - size 3x
   Scene.addBox{geomID := 22;body := 102;angle := b1ang;pos := h2pos;size := [0.03,0.04];collideSet := 0;density := 1e+006}; // geomID 22 - Base box 2 - 42 - body 102
   Scene.addBox{body := 101;angle := (b2ang);pos := (h3pos + ([Math.cos(b2ang),Math.sin(b2ang)] * 0.01));size := [0.01,0.04];collideSet := 2;density := 1e+006}; // geomID 23 - Side rail 1 - box 1 - body 101 - geomID not important
   Scene.addBox{body := 101;angle := (b2ang);pos := (h3pos - ([Math.cos(b2ang),Math.sin(b2ang)] * 0.01));size := [0.01,0.04];collideSet := 2;density := 1e+006}; // geomID 24 - Side rail 2 - box 1 - body 101 - geomID not important
   Scene.addBox{body := 102;angle := (b1ang);pos := (h2pos + ([Math.cos(b1ang),Math.sin(b1ang)] * 0.01));size := [0.01,0.04];collideSet := 1;density := 1e+006}; // geomID 29 - Side rail 1 - box 2 - body 102 - geomID not important
   Scene.addBox{body := 102;angle := (b1ang);pos := (h2pos - ([Math.cos(b1ang),Math.sin(b1ang)] * 0.01));size := [0.01,0.04];collideSet := 1;density := 1e+006}; // geomID 30 - Side rail 2 - box 2 - body 102 - geomID not important
   /* Hinge Spawns
   */
   
   h5pos := [c5,d5] - ([Math.sin(e5),Math.cos(e5)] * (a5));
   h6pos := [c6,d6] - ([Math.sin(e6),Math.cos(e6)] * (a6));
   h7pos := [c7,d7] - ([Math.sin(e7),Math.cos(e7)] * (a7));
   h8pos := [c8,d8] - ([Math.sin(e8),Math.cos(e8)] * (a8));
   
   a8 != 0 ? {Scene.addHinge{pos := h8pos;geom0 := 18; geom1 := 14;motorSpeed := 0.2;motor := true;motorTorque := +inf};   Scene.addHinge{pos := [c8,d8];geom0 := 28;geom1 := 18;motorSpeed := 0.1;motor := true;motorTorque := +inf}} : {Scene.addHinge{pos := [c8,d8];geom0 := 28;geom1 := 14}};
   a7 != 0 ? {Scene.addHinge{pos := h7pos;geom0 := 17; geom1 := 13;motorSpeed := 0.2;motor := true;motorTorque := +inf};   Scene.addHinge{pos := [c7,d7];geom0 := 27;geom1 := 17;motorSpeed := 0.1;motor := true;motorTorque := +inf}} : {Scene.addHinge{pos := [c7,d7];geom0 := 27;geom1 := 13}};
   a6 != 0 ? {Scene.addHinge{pos := h6pos;geom0 := 16; geom1 := 12;motorSpeed := 0.2;motor := true;motorTorque := +inf};   Scene.addHinge{pos := [c6,d6];geom0 := 26;geom1 := 16;motorSpeed := 0.3;motor := true;motorTorque := +inf}} : {Scene.addHinge{pos := [c6,d6];geom0 := 26;geom1 := 12}};
   a5 != 0 ? {Scene.addHinge{pos := h5pos;geom0 := 15; geom1 := 11;motorSpeed := 0.2;motor := true;motorTorque := +inf};   Scene.addHinge{pos := [c5,d5];geom0 := 25;geom1 := 15;motorSpeed := 0.3;motor := true;motorTorque := +inf}} : {Scene.addHinge{pos := [c5,d5];geom0 := 25;geom1 := 11}};
   a4 != 0 ? {Scene.addHinge{pos := h4pos;geom0 := 14; geom1 := 19}} : {}; // hinge
   a3 != 0 ? {Scene.addHinge{pos := h3pos;geom0 := 13; geom1 := 21}} : {};
   a2 != 0 ? {Scene.addHinge{pos := h2pos;geom0 := 12; geom1 := 22}} : {};
   a1 != 0 ? {Scene.addHinge{pos := h1pos;geom0 := 11; geom1 := 20}} : {}; // hinge
   
};


Would become very difficult to understand.

"Create a new function called Scene.my.SpawnMech which takes twenty-four arguments, a1,a2,a3,a4,a5,a6,a7,a8,c5,c6,c7,c8,d5,d6,d7,d8,e1,e2,e3,e4,e5,e6,e7 and e8, first with these arguments, create a box, the size of which is 0.01m across and 0.01 up, with the position on the x axis at the co-ordinate defined by c5, and the position on the y axis at the co-ordinate defined by d5, with the colour of this box being black, with the geometry identification number being 25, and the box being connected to body 0, with no collisions on the collision set, and a density of 1 million kg/m^2... " that being for just the first two lines. 2 lines into 6 doesn't exactly make it easier to read . Continuing on a bit later:

On the line "b1ang := (Math.atan(-((h1pos(0) - h2pos(0))) / ((h1pos(1) - h2pos(1)))));" you would end up with it turning into "Declare a new identifier named b1ang and assign it to the inverse tangent of the negative value of h2pos's x co-ordinate subtracted from h1pos's x co-ordinate and divided by h2pos's y co-ordinate subtracted from h1pos's y co-ordinate ", that is no easier to understand than the original, and the original is very easy to understand on top of that, the difficult parts to understand are much harder to understand in plain English.

Sure you could just type "Generate an optimally built trigonometric drawing system that draws a 2", but, of course, that wouldn't be an easy thing for a program to understand, because on top of all the mathematical equations required, you also need to know what "2" the user wants, do they want a digital two, a terribly drawn "2" or a binary "2"?

If you really think this feature is important, you could probably build a program that translated plain English into Thyme code, I thought I'd do this once but never got around to it, also, didn't think it was worth it.

It's simpler and easier to understand Thyme than plain English saying the same thing , variable names and functions are pretty self-explanatory and infixed operations are generally self explanatory as well ("=","+","/","*","-"), also, things that generally people don't understand are things that you can't really express easily in English, like for example, "Assign spring length dynamically to modify Scene.my.X to damping and spring length also equal to 10".

In conclusion, putting them in "Plain English" would not necessarily make it easy to use as you may think, because even if the interpreter was able to read it all correctly, it would be ridiculously difficult to read it for full codes (keep in mind my examples only follow a few lines when actual scripts I make are about a thousand lines long, which would probably expand to about 3000 lines or 4000 lines or so, which would take an extremely long to type, also, 6000 lines would probably take an hour or so to read or something).

It's not worth it , Thyme used to be confined to an extremely small group, like 3 or 4 users that were able to use it very well and 1 or 2 that were able to do interesting things in scenes using it, but then someone wrote a tutorial, which resulted in most people being able to use Thyme, it's a very simple language now that has a very large number of capabilities, and some users have even created programs that interface with objects in Algodoo, like Externet for example allowing users to connect online and send messages to each other through Algodoo, or a system allowing a user to extract the system time just by running one program (communication.cfg is very useful for this ).

It's easy to learn Thyme, and if you have trouble learning it, just ask for help , Thyme is basically in English with infixed symbols and shortened text.

I still don't think there is much benefit having it in "Plain English" except that people don't need to read or watch a few videos, though scripting is in Advanced Mode, so I don't think that needing to read up on a bit of data is much of a problem.
- Grady

[niffirg1]

Thyme is fine how it is. It took me awhile to learn it. As did did to a lot of others. So if you have trouble learning then just do what Grady said and ask for help almost all of us are willing to help.

[standardtoaster]

It also helps if you have someone who can help you almost immediately. Whether they have great knowledge of thyme or another language, it really is a great thing. If you are a quick learner, after about a day or so, you should be able to get quite a lot of it. Another thing that can help quite a lot is to study scenes that are scripting intensive.

[Psmith]

I'm not proposing the use of "plain English" process writing for the purpose of creating "complex systems". Rather, using it for the most basic and common processes such as collision triggers, the starting and stopping of motors, turning on wind at a certain point in time or by a collision trigger, freezing of water - things that you can already do by using sliders and properties.

A clock timer could be placed as an object in the simulation window and visibly linked to another object, (a motor, for example), and adjusted to start or stop the motor after period of time. All such visible process controls could reside on a special process layer, thus rendering them easy to display or hide.

Electrical switches would come in very handy.

By just adding these few "plain" commands or devices, 10's of thousands of variations in physics "play" open up to the average user. If the commands could either be represented by descriptive icons or text or a combination of both, by entering them directly in the simulation window, the user could then "draw" the link between the command and which object it is designed to control.

This way, not only the static physical properties of each item would be represented in the simulation window, but all of the actions and reactions, and time based triggers would be visible, giving the user "foreknowledge" of what is "going to happen" if and when.

This method of describing physical processes is much more akin to what goes on in any complex factory or automated lab, thus serving as a vehicle to help students and other users to visualize "real world" physical phenomenon and more complex simulations than are now possible.

Thyme will never go away and be available for any advanced users who need to create other types of complex systems that require the use of arrays and database retrieval operations.


Psmith

[RicH]

Looks to me like you just want a visual scripting system. I believe Emil's brought that idea up before. As for now, learn Thyme. It's not that hard.

[isaacwaller]

I think this is ridiculous. If Algodoo is a "physics engine" and not a "coding engine", why does Thyme exist? Yes, Algodoo is primarily a physics simulator. But there's a lot you can't do with just the physics part, and you shouldn't hide all that functionality from the normal user. A simple "Events" menu with "On collision" drop down menus, with items such as "Simulate key 'x'" and "Destroy myself" would be extremely great for the novice user.

[RicH]

http://www.phunland.com/forum/viewtopic.php?id=1117&p=1

I'd like to create a visual programming language for this, since most people aren't that keen on learning a scripting language to do stuff. Exactly how this will be done is yet to be decided.

Old but hey, it's from emil

[Chronos]

I think this is ridiculous. If Algodoo is a "physics engine" and not a "coding engine", why does Thyme exist? Yes, Algodoo is primarily a physics simulator. But there's a lot you can't do with just the physics part, and you shouldn't hide all that functionality from the normal user. A simple "Events" menu with "On collision" drop down menus, with items such as "Simulate key 'x'" and "Destroy myself" would be extremely great for the novice user.

Thyme is in Algodoo for reducing lag. Plus, without Thyme, Algodoo wouldn't run. All the objects, all the scene parameters, just about everything is made with Thyme. Emil just thought that it should be more accessible, but you should still learn it. I really don't like the idea of a visual scripting language in Algodoo, because those who've already learned Thyme would have trouble with it. Thyme is more powerful than you think, and easier too. Learn it if you want, but if you don't want to, then stay mechanical. It's better than way anyway. Even I know Thyme but I don't use it much.

[Versieon]

I really don't like the idea of a visual scripting language in Algodoo, because those who've already learned Thyme would have trouble with it.

I don't think he is pushing for the deletion of Thyme, you could still use it as you would now, just the implementation of a easyer to understand and more visual interface that could be used by begining users( and even advanced users to reduce the amount of coding for simple actions) to create basic scenens that require thyme without going through the proceces of learning the language.

[Chronos]

I highly doubt the old Thyme would be kept if a visual scripting language got added.