Algodoo

You dont have to reset the plane color every frame. If you add the condition e.other+"" != "plane" ? {} : {} to your onCollide, the plane will not be affected by the collision.

Cheers,

Fra32

Hey MasterGamer,

I see that you agree to some extend with Nubman's opinion about marbles, however I noticed that you have countless scenes about Camps and similar (I am not aware of the precise names you use). I've been wondering what's your opinion about the abundance of camp-related scenes and "For User" scenes. Nowadays they make up the vast majority of the uploaded scenes and thus often force other scenes away.

I noticed that you are a new user(or an illegal alt. account of someone else, but I wouldnt believe that). I want to ask you if you really want to go down the path of Marbles and AlgoCamps. The Algobox already has an overabundance of these scenes and needs unique scenes again!

If you want any help or tips on how to create more complex scenes, just ask me via the forum or by leaving a comment with "@Fra32" on one of your scenes!

I am glad that you are one of the very very few users who make camp type scenes but are actually mature and as such much better to talk to.

Algodoo has had a scene grouping feature for a while now, however it is inconvenient to use and as such barely used by most people. Some of the technical guys(that are left) make use of the technical group(Including me sometimes), however the default group is basically the standard group for camps etc. Unfortunally it is basically impossible to convince all these people to go their way just to tag their scenes for us, however, maybe you are willing to make use of this feature. I doubt it would have much impact, but any efford in keeping algobox clean is some sort of progress.

About your hopes of advancing to more complex scenes someday: If you contact me via the online forum of algodoo, I can teach you any knowledge on thyme that you want to know. I am fairly experienced in most concepts of thyme, and as such you can learn some handy tricks for your scenes.

For now I wish you success with your scenes and I look forward to future collaboration!

It's good to see a thyme scripted game again. As a thyme user, let me give you some handy tips:

Instead of coding all the spikes with the same onCollide, give the spikes the materialname "spike", and code the player cube's oncollide like this:

e.other.materialname == "spike" ? {
pos = [5.0, -10.999876];
vel = [0, 0]
}

Don't store variables as scene.my.variables if you only need them for one object. Instead, use the empty black box in the player's script menu and type "_jump = false"
Then, instead of comparing if _jump == 0, you compare
_jump && keys.isdown("up") ? {
vel = vel + [0, 10];
_jump = false
} : {}
The && combines both conditions into one. Now you can only jump if _jump is true.
You can also leave out e.this. and just type "vel=...", as "e.this.vel" and "vel" are the exact same, but "vel" has less workaround.

Instead of using tiny platforms to set the jump value to 0, instead use the player's onCollide like this:

(e)=>{
e.pos(1)<=pos(1)-size(1)*0.4 ? {_jump = true} : {}
}

It compares if it collides with something under it, and if yes, enable it to jump.

If you have any more questions or want more usefull thyme tips, just ask me either via @fra32 in a comment, or(preferably) using a direct message in the algodoo forum's.

You can utilize the group feature by visiting http://www.algodoo.com/algobox/ in your browser, logging into your algobox profile, viewing your scene and clicking "edit" at the top of the description. There, you can select a group for the scene, amongst other things.
About the forum thing, you need to know that the forum uses a different account system than algobox. If you never registered to algodoos forum, make a new account there and you should be able to message me. Simply look for my name either in the members list, or see if you can find my name in the thyme coding forum. If you click on it, you are redirected to my profile, and there you can send me a DM.

Welcome to the algodox! I am glad that you are more inventive than the average user in algobox right now xP

I look forward to more scenes by you and hope that you won't fall for the curse that is marbles and camps.

If you are interested in learning a special feature in algodoo, called "Thyme", which can really spice your scenes up, just ask me. Either visit algodoo's forum in your browser and DM me, or leave a comment on any of your scenes with "@Fra32" in it. I would gladly show yyou some cool tricks c:

This scene is literally just a text box that has no importance to any users. As such, it should be against the rules, as "message scenes" are disallowed if they dont concern anyone urgently.

As you are propably are aware, I am not a member of the fanbase of -athlons, camps and marbles, however I do appreciate the utilization of scripts, and your shoutout to me. If you desire more thyme knowledge, feel free to ask, DM's in algodoo's forum are the best way, no need to open a new thread every time.

Cheers!

I didn't know calamity would be popular enough that the mod's content would somehow manifest here.

I appreciate the compliments, thank you very much ^^

I mentioned that I would make a Mobius transform scene, however, as it turns out, a mere 26 or so circles equipped with some visual script already lags down the scene, so I will need to figure out some means of optimization. Until then I propably won't upload for a while again

I like the idea of this game, however I have to agree with Master, controlling the ship is extremely hard here. Perhaps make the rotation slow down quickly when you release a turn key, or make the little ship move similarly to how real spacecraft move precicely in space: Using an RCS-Like movement("thrust" is applied evenly across the entire craft, thus not causing it to spin, and can be applied in any direction, not just "up")

Ooo, I see someone here is at least to some degree interested in mathsy stuff! Do you know what is cool about this "chart"? If you pick any figure from the first collumn, and then look at the following ones at the right, it will look like you are rotating a 3D object by 22.5 degrees for each row. For example in row 1, the line looks like it is being rotated, thus revealing it might just be an angled ellipsis.

The laser is not the cause for this effect. Something has caused this scene to wreck the water physics, thus causing water collisisions to go haywire and fire it in all directions

That actually makes you one of the Medium to older users, thus meaning you are propably capable of more "interesting" scenes than what is the average nowadays. If you are interested in learning how to use scripts, feel free to ask me, just use @Fra32 anywhere in your comment

That scene does not exist according to algodoo.

I've been looking at your scenes, and I like your ideas, and your use of simple scripts. If you want, you can ask me whenever you like to know how to do something with scripts(cuz you can do a LOT of things).

Cheers!

Fra32

writing that code is actually quite simple. all you need to do is make te water in the scene, select it, copy it, paste it inside the script(thus turning it into its text form) and trimming off the beginning that describes the copy. I am actually positively impressed you knew about that Jakub c:

About the counting issue:
Unfortunally, water particles do not register in events, meaning that there is no "e.other" describing the particle, thus making direct interactions impossible. The idea of using the killer attribute is appliable, but it doesn't behave properly when multiple collisions happen at once, which is what causes it to count too little. what DOES work however is using an alternative way of killing the water, one of which is very simple:

Remove all the killer stuff from the box and just make its adhesion -1e+010

The negative adhesion causes ridiculous collision behavior, and the extreme magnitude causes any water touching the box to be immediatly launched into oblivion, where we dont have to care about it anymore!

PS: Why am I not mentioned as advanced thymer

This is how you do the things mentioned in the scene:

scene.addCircle{
drawBorder := false;
drawCake := false;
refractiveIndex := 1.0
...
}

Set the lasers collision set to B, the walls collision set to A,B. The circles spawn in collision set A, and are thus ignored by the laser.

By the way, I would happily help you with scripting as much as you want, since I want to encourage a new generation of scripters. Just ask whatever you need to know via comments or via the algodoo forum. If you use comments, remember to use @Fra32 so I can quickly find the scene.

Cheers!

That would be good. Best would be for you to visit my forum profile, and use the "send private message" button to message me. I usually check on the forum once every week or less, but if I expect a message, it can also happen once every day

Why are you setting the color to [1,1,1,1] anyways? If you leave the color manipulations out, the stuff wont get bleached ^^

There are three types of variables you can make:

Temporary variables made inside the code, to store solutions of some calculations for example:
(e)=>{
dist = math.vec.dist(pos,e.other.pos); <-- dist would be a new, temporary variable
vel = vel+dist*e.dt
}

Permanent variables, local to object. You make them by typing "_varname = startvalue" in the small empty black box at the top left, replacing _varname with the name, preceeded by an underscore, and the startvalue with whatever your variable should have at the beginning.

_timer = 0;

Global variables, accessible in the entire scene. You make them by pressing f10, and typing "scene.my.varname = startvalue", once again replacing varname with the name and startvalue with the initial value.

scene.my.player = [0,0]

Gotta remember to exclude the plane and glued geometries with

e.geom.body != 0 && e.geom+"" != "plane" ? {e.geom.vel = ...} : {}

Ah, I see. You could use a different kind of visual indication for that, for example spawning small "particles", like circles, or only changing the color of the hammer side. Changing the color of affected stuff should be accompanied with a way of returning the color, for example by manipulating their poststep on collision temporarily, however that requires some use of the eval function, which is a little too complex for you I believe ^^

That is very likely the exact same formula s_noonan used. I believe it has to do with getting the point of collision, the normal at said point, and manipulating the surface array of the polygon according to these values somehow. I cant say much more that this since I don't even understand the format surfaces are described in

Well, technically ,this aint a velocity calculator, but a velocity visualizer, since no calculation is being done. Cool idea nontheless ^^

Congratz on getting high on the popular page! ^^

Damn son, I gotta tell you, you did a good job on this. Design wise you really invested nicely, even the animations, which I find impressive. Gameplay wise, minor improvements could be made, for example lowering the fixed camera position so one can see the floor a bit better. Maybe you should also make the pits a bit more "repulsive" since I found myself with the ball falling in the pits repeadetly due to not reaching the pistons. Nontheless, Rated 10!

You can fix the wobblyness by coding one of the objects to reduce it's angvel via poststep:

angvel = angvel*0.95;

That should reduce the wobbling to some degree

The reason for this is the fact that this piston is under extreme accelleration, causing it to reach velocities great enough for algodoo's collission detection to fail with such thin walls. Try not using thrusters to move the piston, and use lower velocities, then it should work. If not, make the chamber walls thicker.