Algodoo

Awesome.

Use alt-right click to select the spring without its end points.

Looking good, considering your age. You must have been working out.

Impressive. There is only one scene.my variable in all the coding.

A more general approach using Kilinich's method:

_period = 1.0;
_dutyCycle = 0.5;

maxRays = {sim.time % _period > _dutyCycle * _period ? 0 : 1000}

Nice work.

I know because I'm an old geezer too. My brothers and I had an AM Hopalong Cassidy tube radio in our bedroom.

Nice work. When you mentioned rockets, my first thought was that you were going to have Hillary and Donald launch nuclear missiles.

Well done.

Nice work. Best vehicle so far.

116%. I thought I had everybody beat, but then Kilinich jumped in front of me while I was playing the game and then adding the comment.

Try 200 lasers with no code in them. If the simulation is too slow then there is not much you can do. Otherwise, the following might help:

onLaserHit := (e)=>{
(scene.entityByGeomID((readable(entity)).geom)).co­lor = e.geom.color
};
maxRays := 1;

I couldn't figure out how to get a box entity variable on spawning and then reliably clone the lasers.

My idea was: I think the GeomID of the object G, where the laser
is attached to, does not change while the whole simulation runs.

I agree.

I thought that the
(scene.entityByGeomID((readable(entity)).geom)­)
gives a kind of storage-adress of G, where to find and adress
the properties
of its child-objects or child-variables like color or any other
variable or function of the object G.

I think that (scene.entityByGeomID((readable(entity)).geom)) returns the object G.

Now, if i use the laser, and the laser hits 60 times per second,
and every time the same storage-adress is calculated, that would
be a waste of time in my eyes.

I agree.

Maybe it would work if i add an own "click on me"-start-object
which will do then the same job as the onSpawn,
you know what i mean?

Yes. You can do the following:

in update:
entity._g := scene.entityByGeomID((readable(entity)).geom);
upd­ate = (e)=>{}

in onLaserHit
_g.color = e.geom.color

but it won't help you much.


An other way out would be to check the properties of the laserHit
only every second.

That might work.

Here is an idea:

_boxColor := [0.0, 0.5, 0.0, 1.0];
_colorfound := [0.0, 0.5, 0.0, 1.0]

In onLaserHit:

_colorfound = e.geom.color;
_boxColor != _colorfound ? {
_boxColor = _colorfound;
(scene.entityByGeomID((readable(entity)).geom)).co­lor = _colorfound;
}:{}

My idea above was to set the box color only if the object that the laser hits has a different color than the box. Why waste time setting a object property to the same value it had to begin with? My initial thought was that setting an object property [for example, (scene.entityByGeomID((readable(entity)).geom)).co­­lor = _colorfound] is more resource intensive than getting an object property [for example, _colorfound = e.geom.color]. Even if setting and getting object properties used the same amount of resources, setting an object property only when you need to should cut the task about 50% for scenes where properties change much slower than the laser hit rate (like in your connect4 scene). Also, your idea to check the properties of the laserHit only every second is a good one and that idea alone may be sufficient.

Looks good. Nice coding.

Since I was looking at your scene, and had connect 4 on the brain, I decided to make three of my own versions of connect four. I tried not to copy, but I'm sure I was influenced by, your scene here.

Thanks for the comments Xray.

Well, since "The Linkage" made a comment, I will too. You are off to a good start. Unfortunately, marble racers may drown your scene. It might make sense to put this in the "Technical" group. If you desire better gears then use Spur Gear Generator II.

Nice work.

Regarding "the player can still add more disks to that column and make it overflow.", I appreciate the feedback, but I'm not going to error trap for that case.

Regarding "one more disk must be dropped after the winning disk has been dropped", I think I fixed that (I hadn't allowed enough time for the lasers to detect the last disk dropped), let me know if you still see a problem.

This is a great scene. It is fun to watch and also shows how to design one yourself. There should be more teaching scenes like this one in Algobox. One suggestion: Get rid of the clouds.

I agree with Kilinich, but I can't figure out why the boxes are not colliding with the pavement and turning red immediately.

faytree,

You may have misunderstood me. I thought that the boxes would collide with the pavement and turn red immediately since the share the same collision layer. I wasn't requesting that they do so. I was just wondering why they didn't. After looking again I see that the pavement is killer and I suspect that the boxes are getting killed before they have a chance to collide. Is this what is happening or am I missing something?

Nice work. This is much better than my onNotHitByLaser scene, which used an additional laser to do the counting.

Good job. This must have take a while to make. Maybe you can make a "wild car" that obeys all the traffic signals, but can't be controlled by the user. This way the user can clone the car as many time as he wants and load up the roads.

Thanks, that's exactly what I wanted to know. I appreciate that you make scenes which have ideas I haven't seen before.

I saw that happen once when I was playing with the scene, but then I called a tow truck (hand tool). It will be good if you can program for zero grid lock. A figure 8 track might be good for testing.

This is good scene, but I take offense to "sim.running = true" in the update event. You might think you are helping us out, but I suspect most users prefer the ability to stop and start a scene.

Yes, good idea, you can disable everything except the drag tool and the "Q" key. There is no reason to use any other tool or to zoom or to toggle play mode. You can hide all the menus while you are at it. There is no reason for anyone to understand how you did anything in the scene. There is no reason to have instructions in the scene because people could probably guess how to operate it. Better yet, maybe you can have the scene automatically quit if somebody presses the wrong key. You are well on your way to be a master Windows 11 programmer.