Hey 
TheZinc,
If I understand, you're interested in simulating low gravity, and a jetpack with a capped maximum speed.
I'm not sure what stuff you already know, so I'll just go over the things that might help out.
Summary:
Frame rate independent acceleration can be tricky, but is doable with "delta time", some math, and also even more math.
C2's Physics behavior can do it all automatically.
Try ignoring Jetpack thrust when player is over desired speed cap.
Low Gravity
In a low gravity environment, like the moon, physics will behave exactly the same way as on Earth, except that the global downward acceleration on all objects will be a lower value.
On earth the downward acceleration (gravity) is
32 ft/s^2 "feet per second ... per second"
Meaning every "second", a falling object picks up an extra 32 "feet per second" of speed.
On the moon the downward acceleration is about
5 ft/s^2 "feet per second ... per second"
Meaning every "second", a falling object only picks up an extra 5 "feet per second" of speed.
In Construct 2 terms this is like saying every second add 5 (feet per second) to an object's Y velocity.
Acceleration per tick
So, we could make a C2 event that said:
"Every second add 5 to an object's Y velocity."
Unfortunately that accelerates by an amount of 5 in a big burst every 1 second.
What we really want, is to accelerate by an amount of 5, but smoothly spread out over 60 ticks per second:
Every tick (60th of a second) add "5 * (1/60)" to an object's Y velocity.
Now after 1 second of ticks we will have added 60 of those "5 * (1/60)" slices, which is a total increase of "5" for Y velocity, over 1 second. Success!
This almost works, but remember that not everyone's monitor is capped at 60 frames per second. Some will be 120 fps, or 144 fps, or on a slower machine, you might get 30 fps.
So if you cant count on 60th of a second ticks, and multiplying by 1/60; but you also can't count on 120th of a second ticks, and multiplying by 1/120; then what do you do?
It would be handy if C2 could tell you exactly how short a tick was right at the moment the calculation was being done. Fortunately it can, and that value is called "dt" for "delta time", meaning the fraction of a second since the last tick.
When the frame rate is 60 fps, dt will be 1/60th.
When the frame rate is 120 fps, dt will be 1/120th.
It's exactly what we need.
So instead of saying:
Every tick (60th of a second) add "5 * (1/60)" to an object's Y velocity.
We now say:
Every tick (delta sized sliver of a second) add "5 * (dt)" to an object's Y velocity.
In practical terms, using a lower gravity value will mean the player jumps higher than in normal gravity, and the arc of motion will appear to be in slow motion.
Curse of Calculus
So all the above fiddling with "dt" gets us the right velocity regardless of tick rate, but there's still a problem.
It doesn't get us the right position, because position is based on velocity over time.
If your game runs at 1 fps, a dropped stone will have the correct velocity after 1 second, but it won't have gone anywhere yet, because before that first second it's velocity was zero, so it covered no distance at all, for that whole second.
Drop the same stone, using a faster frame rate (like 60 fps), and after 1 second the velocity will be exactly the same as in the prior example, but the stone will have traveled downward on every tick after the first one.
In the real world, if you graphed the increase of velocity over time, you'd get a nice increasing diagonal line.
In the game world you are stuck with ticks, so the velocity is changing in stair steps, and the notches (stairs) are the error. Making the time slices (stairs) smaller makes this error smaller, but this just means the size of the error will vary with the speed of the frame rate.
Now this error might not be a huge issue, but if you want to eliminate it, you can use Euler integration or Verlet integration, which both attempt to account for the missing stair step area, regardless of step size. Verlet is kind of like an interpolated version of Euler.
Another way to eliminate it is just to use a pre-built physics engine that handles all this stuff, like C2's built in Physics Behavior, or a comparable 3rd party Physics solution like Chipmunk Physics (which another C2 dev built a plugin for). Note, I think you have to set C2's physics to be frame rate independent with an event, if you want it to do all that "dt" stuff I described above, but it basically just has an "on switch" for that mode.
Jetpack velocity cap
One way to cap the power of the jetpack is to make it apply thrust only when the player's upward speed is below a threshold.
e.g.
If player is pressing Thrust key,
AND
If the player's upward velocity is below 100 pixels a second,
THEN
Add +1 to upward velocity.
Just remember that in Construct 2 upward velocity is actually negative "Y".
So the above code written in Construct would look like this:
If player is pressing Thrust key,
AND
If the player's Y velocity > -100.
THEN
Add -1 to upward velocity.
Hope that helps out.