For those of you who don't already know [like me before doing it wrong, then figuring it out], this is how you install a PHI file:
1. Tell your browser to save the PHI.
2. Open the PHI in Algodoo.
3. You should get a dialog box saying something about installing the file.
4. If not, make your OS open the file using Algodoo.
I don't really know what the dialog box should say, I didn't go all the way through with the process. I unpacked the PHI via Windows and copied the stuff to the appropriate folders. Installing should put the stuff into the right folders for you.
EDIT: By the way, good work, Kilinich.
Last edited at 2011/07/08 01:57:19 by Someone Else
Doesn't work in 1.9.7. It seems that the power stroke fires a bit late, so it doesn't get enough torque from that to overcome the next compression stroke backfiring...
But, I think that if this worked, it would work really well.
It might work if you (Gear97) edited the scene and added a circle with the texture so Algodoo would stick the texture into the scene package.
Hmm... I'm trying to reverse-engineer your smoke. First I tried throwing formulas into the original spawn code:
scene.addCircle({
pos := e.pos;
controllerAcc := sim.time;
color := {[0, 0, 0, 1-(sim.time - controllerAcc)]}
})
but the color only changes until the next circle spawns.
In the full code, with lots and lots of other stuff in it, only the very first circle changes its color, regardless of the presence of later circles.
I then took a closer look at your code, and I got this:
(scene.addCircle({
pos := e.pos;
controllerAcc := sim.time
})) -> {color = {[0, 0, 0, 1-(sim.time - controllerAcc)]}}
and it works fine.
However, in the full code, the spawned circle never appears.
*experimentation*
Ah, now I got it to work. Thanks for the code- I never would've gotten it otherwise.
Also, can you tell me exactly what the () -> {} thing does? I've been wondering about that for a few seconds now...
Let me guess- the parentheses contain a definition or identifier of a particular scope (e.g. scene.addCircle({}), scene.my). The brackets contain identifiers and values that will be added to the predefined scope, or changed if they already exist.
I sort of partly started working on a Thymed version of the same contraption, but it never really took off, and this collab is pretty close to dead now, so...
Thank you. I might be able to fix some of that, but I don't think so.
The first thing I tried to do in 1.9.7 was to make Portals: Level 002.
However, when I tried to save it, it seems that Algodoo spazzed out and simply wouldn't save.
Thus, Algodoo lost all my progress. Fortunately, there was not very much of it.
However, I may try to re-build it. Sometime.
I am currently trying to add radio buttons and checkboxes to Kilinich's menu phunlet.
It seems to be working fairly well, though I have not gotten particularly far yet.
Hmm, Algodoo is not letting me save my scene
(referring to Portals: Level 002). This is really weird...
And I put so much time into it too...
Okay, I tried saving it as "Portals: Level 002", and it didn't work, so I replaced the colon and spaces with underscores. Then it saved.
One new sequel coming right up...
Last edited at 2011/07/20 07:07:19 by Someone Else
Simply does not work at all in 1.9.7. None of the textures, aside from the wood and ice textures, appear at all, Santa crashes when you hit S (seriously- his feet act like they are not connected to the rest of him), the snowballs spawn, but seem to stay connected to the gun, the gun ceases to point at the mouse with any determination soon after using the drag tool to pull down the ladder...
What is going on here?
By the way, I get ~40Hz at first, which decreases over time.
Also, I did manage to make a phunlet-friendly portal. Look at my profile page.
Not great, either. It would help a lot if the planes didn't all spawn in the same place.
If the places were coming in at different levels and if the cannons didn't just fall off when you tilt the gun up (a fixate solves that), and if the cannons were mouse pointers, it would be a lot better.
And yes, I already know the recursive multi-spawner does lag a ton. This is why the spawned circles last ONLY a tenth of a second and be thankful that it lags ONLY a ton and not exponentially, as some primitive versions of the fractal bombs did.
I lag-crashed my computer far, far too many times while I was testing those before I figured out how to use a part of the code that was already there to prevent each bit of shrapel from exploding seventeen gazillion times instead of once.
Now, I shall work on my next project: Missiles. I am actually going to turn these bombs into rocket-propelled warheads.
I seem to have the same problem as Scorpion, but in 1.9.8.
I fixed it by decreasing the magnitude of the attraction of the spawned circles by three.
Go into the script menu of the square at the center of the ship. In the onHitByLaser box, you will find "attraction :=" listed twice, once toward the top, once toward the bottom.
At the upper location, it will read "attraction := 10000;".
At the lower location, it will read "attraction := (-10000);".
Change these values to 100 and -100 respectively, but leave the semicolons. The parenthesis aren't necessary.
It will work as planned now. I think. It will accelerate really fast without breaking the ragdolls.
I noticed that the elevators don't work yet. I strapped a version of my C-Thruster to the front, propelling the plane extremely fast, and the elevator didn't change the position of the suspension, much less got the plane off the ground.
Also, the body of the plane is all one body in Algodoo, right? So delete the fixates, glue it all together, and use the CUT tool (or lasers) to chop it into pieces!
I tried to make a mechanical clock myself once. The result wasn't really that good.
This, however, is much better. So much so that it actually made my hard disc. A rare honor indeed.
Also, for future projects of yours, I might suggest using C-gears. They may not look as good as polygon gears, but can take greater loads, have less backlash, and can run faster.
Missiles (both those fired at and by you) spaz out, checkpoints don't work (they're there, but when you use them the game stops working), enemy planes crash but don't burn until hit with one of your missiles, undoing anything seems to prevent proper function...
I had an older version (pre-updates, some of them anyway) and it worked fine in I think 1.8.5. It might've worked better than the current version in 1.9.7, maybe, but I no longer have that old version (deleted it, moved the camera before I saved it, hoped that the new version would reset the camera properly)...
Once again, and once again agreeing with everyone else, after seeing that later-published pendulum clock, amazing work.
Second scene of yours in two days to make my hard disc.
That is unprecedented, although four of Kilinich's scenes did make the cut.
I spelled out (but didn't print) "PHUN IS AWESOME!" before I saved it.
Occasionally, I found, the tall vertical slider on the right fails to stay down during the printing cycle, so it prints a space instead of, in this case, this case being the first time I tested "PHUN IS AWESOME!" after first saving it, the "N" in "PHUN" and the first "E" in "AWESOME".
So it printed "PHU IS AW SOME!".
But I reloaded the scene (to test if it still worked) and it worked fine.
@s_noonan: To answer your questions:
- 1. Zoom out. Off to the right, you will see a blue-gray ball with a tracer on it.
Move it with the arrow keys.
- 2. They work independently.
- 3. Both have the same mechanism at their heart: two identical discs, each with an attracting circle and a repelling circle on opposite sides.
Left to their own devices, these would both line up in the same direction, with the attracting circles both pointing at the ball mentioned above.
As it is, however, two springs try to push them apart.
When the ball is closer, the attraction is stronger and they point in nearly the same direction.
When the ball is farther off, the attraction is weaker, so the springs can push the discs farther apart, or at least closer to the same direction.
The angle bisector between the two discs will always point at the ball.
The mechanism on the left efficiently uses pistons to achieve its effect- the arrow always points at the ball and as the ball gets closer, it pulls back into the mechanism.
The mechanism on the right uses C-gears. It uses two planetary gearsets (Hmm... cycloid gears could do this more efficiently...) to find the difference between the positions of the discs in the radar mechanism, leaving out the direction (there's an arrow for that), which then gets plugged into a dial.
The semi-planetary (after a closer look) C-gear arrangements behave much like the piston mechanism.
One arrangement is located on the the radar mechanism itself. This keeps the arrow on the bisector.
The other is responsible for the dial. It finds the difference between the two discs on the radar mechanism and thus controls the dial.
Again, interesting mechanisms. Both are very accurate. The C-gears provide a disc for readout, so this can be easily geared up or down to increase accuracy in the dial itself, at the possible expense of having any clue what that readout means (i.e. Is this 5 representing 5, 50, 500, or 5,000 meters?).
The gears can, however, be knocked out of phase, meaning that you get nonsensical distance readings, or perhaps direction as well.
The pistons, however, cannot be knocked out of phase like this very easily. However, the mechanism can lock up and give you no clue of distance or direction if the target passes too close. It will right itself when the ball passes in front of the wandering arrow at a greater distance, so it resumes function. This could be prevented if there were more pistons in the mechanism, meaning the only way to break it would be to badly stretch the hinges and pull a piston either through the piston wall or out the end of a piston.
So, all in all, the mechanism on the right is more precise, but easier to break.
Both, however, are well-deserving of the title "Good job."
Each set of light-colored balls on the chain is a letter. The first ball (on the left when the ball is being read) corresponds to the first column, the second to the second, so-forth.
If a ball collides on A (but not no self collision), the corresponding column will have a pixel lit up at the top. Collision G means the bottom row. If all seven collision layers are checked, it will print a vertical line.
A ball that collides on any one layer, collides with water, and with no self collision will print a blank column.
For example, if you wanted to print a question mark:
1. Get an idea in your head of what a question mark looks like.
2. Think of what it might look like if it were in a display with 5 by 7 pixels.
3. Find which set of light-colored balls will be our question mark. Find which of these is the first one.
4. Uncheck the No Self Collision box for all five.
5. We'll probably want the top to be rounded, so uncheck collision A on the first and last circles, leaving it on for the middle three.
6. We want both sides to be vertical, so check collision B and C on the first and last circles.
7. On the right side, we want it to curve back in toward the middle, so check collision D on the fourth circle and collision E on the fifth circle.
8. Finally, we want the dot to be centered on the bottom, to check collision G on the third circle.
Test it. It should look something like this:
__________
__$$$$$$__
$$______$$
$$______$$
______$$__
____$$____
__________
____$$____
I've found that in the spawned circles' onCollide, I like to set heteroCollide to false and airFrictionMult to 1000 instead of density to +inf. This way, the snow does pile up, but doesn't stick rigidly in place, so it moves, but slowly. This way, it piles up more realistically.
To make it phunlet-friendly, you could add this to the beginning of the code in the gray box, before the Scene.addCircle({ but after the (e)=>{ :
{controllerAcc == 11} ? {
controllerAcc = 0;
scene.my.memory = 17;
scene.my.random = (min, max)=>{
x := scene.my.memory;
m := 1249 * 373;
x = x ^ 2 % m;
scene.my.memory = x + sim.time;
x <= 1 ? {scene.my.memory = scene.my.memory + 17} : {};
x * (max - min) / (1249 * 373.00000000000000) + min
};
scene.my.ort = (x)=>{[x(1), - x(0)]}
} : {};
@crytek: I admit, not knowing where to go in the maze could be a serious problem, and I don't want to give away the solution.
But I think I can tell you that the goal is very near one of the light green portals.
And the version of Algodoo shouldn't make much difference.
@willy101: That's not good.
When you touch a portal, it is suppost to delete "you" and spawn a clone of you at the other portal.
As I said, the version of Algodoo shouldn't make much difference.
