I have been using gamestudio for a year now and go from c_script movment to
ent move.
I like both for what each offer but dont like it that I cant get gravity
to work on model surface terrain entities.
Collision works most times but is not reliable so really, whats the point with c move?
Can I have your advice please?

The c_instructions were created for use with the new ABT scene management (because they require the methods created in them for correct collision...you're player will walk through geometry is you use the original technique in an ABT build), although you can use them with BSP, too. Ent_move is deprecated and will be removed from the engine; however you can still use it's functionality with c_move by setting enable_polycollision to 0.5 and making sure you setting the c_instructions flag to USE_AABB (along with whatever flags you sest). New collision is the newer OBB. Consult c_move in the manual for particulars. AABB is faster but doesn't allow per poly collision or access to the newer collision techniques and according to the A7 manual is now a Pro feature only (along with BSP scene management). However, if you're using "old school" bounding boxes (and A4-mid-A6 code) then it's what you'll want to use.

Quote:

---

USE_AABB P Uses an axis aligned bounding box (AABB) for collision, rather than an oriented bounding box (OBB). The AABB system is faster, but ignores the entity orientation on USE_BOX, treats models and sprites as boxes, and requires a BSP level. See collision for the difference between both systems.

---

I am also fighting with this recently, and now I can get the collision reliable on block or terrain slope.

Slope test

Control: 1-5 select camera, WASD movement, cursor left/right to turn.

I use engine default setting, I don't know is it correct but base on trial and error I discover that don't set the model too high from origin, if your model is a vehicle. Lower from the origin a bit, see the ma1.mdl in the zip.

Subtract the "distance to grand" calculation a little, like -5.5 in my example, otherwise the model will sink in the ground. so the model raise a bit to the ground. Now the model "touch" the ground nicely.

Code:

---

ext_force.z = max(-35*time_step, -(c_trace(my.x, temp.x, ignore_me|use_box)-5.5));

---

I am a newbie I don't know if there are better solution, I'd like to know the best practice as well, so any advise are welcome.

Thank you both very much.
I can see I have a lot more study to do yet with the new systems.

Will download your example Frederick_Lim and study it as well, hopefully I will be able to progress and firm up on the most effective system I can manage.

Shame to see ent_move system go though, works so well.

You are welcome Nomad. I am still learning and my example is based on AUM and other forum snippets, but still not achieve reliable collision. There are too few tips about collision with slope and terrain.

And I just tested if I set the collision hull to symmetrical in all side, I think this way the collision shape will become spherical, the collision work more smoothly when the entity move between the terrain and level block, no shake no jump. I uploaded another example lets study together.

Slope Test 2

var disable_z.glide could help.
At default model sizes 1 is suppossed to stop all climbing (depends on the models scale/size) 2, limited to 45 degrees if I recall right and 3, maybe 60 degrees.

Cheers.

Thanks again Frederick_Lim, your code example is great, everything works as it should.
Interesting to note though that when I had a camera inside of the player function, the camera lagged terribly but when I used an external camera, it worked flawlesly. It also lagged when I disabled stencil_shadow!
Lost about 20 fps though.

To auto set your bounding box, simply apply c setminmax me after your fat and narrow flags and after a wait 1.

I am still developing from it as a base to my Game script but all creds to you.

Later...

**PS voted you 5 stars for your great help