Browse Search Popular Register Upload Rules User list Login:
Search:
Here are the pictures:
http://www.alessandromare … 3941_2.jpg
http://eurasian.in/granit … xy_500.jpg

I think at least, either way, should get the job done:)
@Arinlares - The command is WalkFoward, perhaps thats not what it should be, I'll change that to Forward, I'll just add a separate one with the proper spelling, not difficult:).
I'll just finish what I'm doing, and then I'll upload the update, and the proper spelling one should work too.
Wonderful Work:) As RicH said, more drink, but, it looks simple (looks hard to copy though), less parts means less breaking.
:) Nice work
I remember this, I think I figured it out, and made an explanation of my own, but, I watched a video from mira explaining every part of it:). Also, I always try to say their instead of his when talking about mira, because mira sounds like a girls name (but, never heard Mira speak (only generated voices)).

Mira has always been my favourite author (well, since I noticed they'd appeared):).
I think this is pretty simple:), but, it's good. Even though it's what I call simple, compared to most the things on phunbox (that I remember), it's extremely complex:), nice job, next time..... I can't think of any improvements, simple, smooth, and good, can't think of any additions for this...

The problem is.... What I call complex, I can't figure out myself.... Perhaps you should build a trigonometric drawing of the instructions of how operate this machine for those who don't understand:) (because trigonometric pen drawings are complex and cool:), as opposed to just cool:)).

Nonetheless, good job:).
Sorry, I couldn't remember/find the name....

It has a bit of a resemblance to the torisan engine, slightly.....
I do too:). It's easy to make too.
Thanks:), the hardest mechanism was the SA-KU-RA mechanism, the SA-KU-RA mechanism is very simple, but... The hardest thing is remembering how it works :coolgrin: but, once you figure it out, it's also hard to put together (it's simple, but time consuming and requires precision).

I'm glad I helped, I hope this scene gives some people good ideas:)
Last edited at 2009/08/11 08:26:55 by gradyfitz
It's weird it lags for you, perhaps it's because of my massive reserve of fast access RAM, because this thing does lots of RAM I/O, though, this method does allow for you to only update values when you need to, so if you were using this for a spring, hinge or fixate creation, it should be far less taxing, and much friendlier:). Depending on the speed your computer can save one undo step then undo it, this should run faster than normal beacons.

If I can get it to work without creating and undoing an undo step, then it shouldn't have any lag and you should be able to use drags. I may not think of how to get it to work without creating and undoing an undo step for a while, but at the moment, it is probably the easiest way to capture the geometry and entity IDs without having the user do anything.:)
I get 181 (averaged, peak at about 420, low at about 160).

The averaged code I used is:

(e)=>{ scene.my.t2 = sim.time; scene.my.Frequency = 4.0 / (scene.my.t2 - scene.my.t1); scene.my.t1 = sim.time; Scene.my.CumulativeFrequency = Scene.my.CumulativeFrequency + Scene.my.Frequency; Scene.my.CumulativeSamples = Scene.my.CumulativeSamples + 1.0; Scene.my.AverageFrequency = (Scene.my.CumulativeFrequency / Scene.my.CumulativeSamples) }


I'm pretty sure that the speed is about the FPS:)
--
Grady

EDIT: Thought you may also want the information about my screen settings: 75Hz, 1280x1024, 32-bit.

The information was averaged over a period of 1 hour, 14 minutes and 20 seconds (minimums and peaks weren't formally measured, but they were numbers I caught with my eye). :)
Last edited at 2009/10/16 11:42:41 by gradyfitz
I noticed just recently that the method you use only allows up to 400 Hz measurement, above 400Hz, the measurement says "+inf".

I measured using my own device, and got an average of about 620 Hz, which happened to be my FPS at the time (doing quite a lot of other things at the time), the codes I used were:

(Laser hits this box)
onHitByLaser = (e)=>{Scene.my.CumulativeFrequency = Scene.my.CumulativeFrequency + 1};

Scene.my.AverageFrequency = {Scene.my.CumulativeFrequency / (Sim.time + 0.0000001)}

(0.0000001 is added to the equation because it is a largely insignificant number, but will prevent the requirement of if structures to protect from division by 0), I think that perhaps why your system goes to "+inf" is because the time difference at 100 Hz is something like 0.01, whereas, if the laser registers 1.25 hits every 0.01 seconds, the number is likely to be divided by 0.

Though, this does line up near exactly with the FPS I have. I ran the system directly as opposed to the system you had (splitting frequency into quarters, then multiplying by 4), this seems to allow me to get a more accurate read on the frequency against the FPS.

As normal, 75Hz, 1280x1024, 1.6.0 (I haven't tested any pre 1.6.0 versions of Algodoo, though it's not too important I suppose).

Based on the information I have gathered, the FPS ~= laser frequency, System.maxFPS does limit the speed of lasers (maxFPS ~= max Laser frequency), The reason it seems that lasers update at a screens refresh rate is that most screens run at 60Hz (normally), this is also the default value of System.maxFPS, the reason the laser frequency fluctuates so much from computer to computer (like the old timers Blue Herring, Danneh and I worked on), is most likely because of different performance of computers (you would expect two perfectly identical computers to run at the same speed), there is little need for extremely high frequency lasers :).

Coincidentally, thyme updates at the same speed as lasers (pure thyme, not onCollide or anything), which has just lead me to another conclusion, perhaps lasers update instantly, but onLaserHit/onHitByLaser events run at the frequency of thyme (which would make sense considering that onLaserHit/onHitByLaser use thyme:)).

Hopefully some of this data is interesting or helpful to you.
Very nice:), I always like the things you make. Keep it up:)
It's very good:), can't think of any improvements:). Very good.
Last edited at 2010/01/21 05:04:49 by gradyfitz
I think that it should be easy to modify it to aim, also, the slow fall can be stopped by turning Air Friction/buoyancy off:).

Either way, it works pretty well, good work:).
It's good, though I began holding down Right because I thought it would need that to get going off the truck, but it's good how it doesn't:). Good Job.