I would ask for your kindly help.

I started on a script using SetPosition, but had some issues, so I transferred
to MoveUp. Now MoveUp is soooo slow. Then I found this old thread;
https://forum.game-guru.com/thread/216690

Also the numbers factor is totally different with MoveUp vs SetPosition.
Does it also use FPS to determine it's use? haha - - maybe I can
transfer back to SetPosition, but things now are smooo ooooth!

Well any info would be grateful.

I could be wrong but I believe if you have physics on this might effect things. By its weight and friction etc. I could totally be wrong here, but its my first guess.

If you read the 2nd post you linked to you will see I already explained how to make them work the same way (but move commands will stay smooth)

More questions about movement. Hope that's okay, instead of
starting a new thread?

--[--> inertia <--]--

I would like to move something, then let the GG engine take over the
object where the script left off (I see it happen in pickupable, push, etc)
so that the inertia and velocity (same thing?) of the object the script
produces is maintained and carried out by the main engine. I need the
object to interact with not just the ground (which I have gotten now), but
also collision with other objects.
But I don't know how to reproduce that in my script.
Maybe someone can produce a tutorial (BAG!) I just glanced at your news
just as I was posting this... Also importantly, I'm wondering how
detection (ray-casting) is handled.

--[--> Isimmobile <--]--

Putting the object properties on isimmobile = yes, seems to make it much more
stable when scripting movement, but it removes collisions (much of it) from the
core engine (even with physics on.) So hmmm... wonder if there's some kind of
work around?

Am I missing a function that calls global "velocity" values of an object?

I can see a bit of confusion creeping in here, basically you have a choice, you can either move stuff around yourself (using any of the myriad movement commands) OR you can let the physics engine move stuff around for you.

You can't do both!

Now to directly move a physics object you need first to turn collisions off, move it, then turn collisions on. But doing this means that the object you are moving will no longer interact properly with other physics objects!

To move a physics object in such a way that it interacts with other physics objects you need to 'Push' it in the required direction (note that 'Pushing' an object in the Y direction is a sort of anti-gravity thing and can be used to make physics objects float) but this means that you cannot accurately position an object using this method.

Hope that helps.

related to this topic, i have an object im controlling with the move command and occasionally it will fly up into the air and back down again.

I'm assuming that is an unintended effect rather than a bragging statement?
It usually happens when you are swapping collision off and on often, i.e. collision off, move, collision on.
The only solution I found was to only switch collision back on after I am done moving the object for a while.

"IT" = comprehensive physics scripting and core engine collaboration.
It sounds to me like 1 ("IT" could almost be available there- with some tweaks),
and 2 (I will have to try to script collisions with objects myself for now)--
though the core engine does a great job at it. Too bad.

PirateMyke told me that if you put a bone in an object, with the proper fpe
set and everything, those objects will have small area cone of collision.

If there was just a global way to pull out and set! the velocity of any object--
surely the engine works with those numbers constantly... then we could switch
between the two clearly and seamlessly, and clearly the core engine knows the
position (which is the only thing we can gather for scripts)
and it causes the interaction with other objects, moving them as required.
Wouldn't that info be available to us -- (with a new function)

Say for example, this object is sliding down a wall... you want to be able to
manipulate it sideways or something to that effect, but you want the sliding
effect and collision with other objects maintained by the engine.
So, send a call to the core engine and get the velocity of said
object, while only changing the certain effect in scripts that you want.

Sounds easy hu?! haha. Does anyone know the difference between GG
and say the other engines - Unity, Unreal, etc when it comes to this?

Anyways, maybe all of that is just wishful thinking... ! lol

We can get the coordinates for the ground, therefore I was able
to use that in the script, and I'm happy with the results.
Can someone kindly direct me to some information on raycasting.
Examples, requirements, etc?

BTW I move some objects around and with isimmobile = no set
it collides with other objects (buildings for example) it won't even
push through them... but with other scripts (currently working on),
isimmobile = no brings unacceptable behavior. Therefor, raycasting
techniques is the option it looks like. Thanks if anyone can help!

Alright. I'm checking out the command in global.
Let you guys know how it goes.

Edit...
I will predict that I might struggle with this part...
"The command returns nil if no hit detected so make sure you account for this or your script will crash."

Used 0.

yes a nil result will crash GG so the stock scripts deal with it by immediately converting the result to 0 if it is nil
i.e.
look4int[e] = IntersectAll(x..... etc etc
if lookint[e] == nil then lookint[e] = 0 end

but checking not equal to nil as you described above works just the same, you'll just need to do it every time you want to handle the value outside of that 'if'

for moving physics objects amen did an example in this thread

Thanks for all the help!

What i did with my health pickup scripts for my recent pack was wrap the code that calls a global variable that may or may not be nil (in this example the variable to collect the item might not exists if they're not using the hud script i provided) in an if variable ~= nil statement, so if the global is nil then it just doesn't run that part of the script and throw up a warning.

For else:



That way i could have the health pickup either act as an actual collectable pickup in inventory etc. when the HUD is used, but if the HUD isn't used it acts as the default health pickup, effectively two scripts in one depending on the usage.