Hello!

I've run into a problem that I'm sure some of the experienced gamestudio people have probably seen before. I'm trying to create a bumpy outdoor floor using concave blocks. I do not want to use terrain. The problem is, my entity keeps getting stuck while walking across the bumpy floor.

Here's my process:

Step 1: Create a block


Step 2: Copy the block so that I have a grid of 9 blocks



Step 3: Convert each block to a concave block



Step 4: Rise up one corner of one of the triangles



Step 5: Rise up more corners of the surrounding triangles to create a "bump"



Step 6: Attempt to walk on the bump. Get stuck often.



I've tried compiling the map using the "Don't snap vertices option." I also tried using the "Create Meshes" option while compiling. Although the map will compile, the entity continues to get stuck about 10% of the time while trying to walk over the bump I created.

Any ideas?
- Bret

What does the movement code look like?
And what the stucking like? Does it always happen at the same positions? Is it into all directions?
...
I don´t think that the problem is how you create it in WED (if so it should be a bug...) but the code.

Thanks for the help Slin,

I posted up the movement code here: http://www.coniserver.net/ubbthreads/showflat.php/Cat/0/Number/808885/an/0/page/0#Post808885

I only get stuck when directly centered over one of the "seams" where two of the triangles intersect. By "stuck", I mean that the entity stops moving (but continues to animate). When stuck, I can't pan, move forward, move back, or turn. However, if I try hard enough I can get un-stuck.

I use c_move and c_rotate. I can't think of anything in my code that should stop me from moving.

I painted over one of the screen captures to show where I tend to get stuck:



Thanks! I hope that helps.

- Bret

Captain's log, 010208. Still no insights into my problem walking on meshes. But I do have new evidence. I've dumped diagnostic information about the entity to a file. The data doesn't suggest that my movement code it to blame. Here's a chunk of my movement code:

Code:

---

// Move the player
distance_moved = c_move(me, move_to_vector, nullvector, GLIDE|IGNORE_SPRITES|IGNORE_PASSABLE);

if (key_z)
{
	diag_var("\nx: %6.3f",my.x);
	diag_var("\ny: %6.3f",my.y);
	diag_var("\nz: %6.3f",my.z);
	diag_var("\ndistance to ground: %6.3f",distance_to_ground);
	
	diag_var("\nmove to x: %6.3f",move_to_vector.x);
	diag_var("\nmove to y: %6.3f",move_to_vector.y);
	diag_var("\nmove to z: %6.3f",move_to_vector.z);
	diag_var("\ndistance moved: %6.3f", distance_moved);
	diag_var("\nin solid: %6.3f",in_solid);
}

---

Here's some diagnostic information that I gathered while the entity is stuck:
Code:

---

x: -512.035
y: 236.587
z: 136.929
distance to ground:  0.000
move to x:  2.971
move to y:  0.000
move to z:  0.000
distance moved:  0.000
in solid:  0.000

// .. next loop
x: -512.035
y: 236.587
z: 136.929
distance to ground:  0.000
move to x:  2.979
move to y:  0.000
move to z:  0.000
distance moved:  0.000

---

Notice that I'm attempting to move the entity forward 2.979 quants. c_move isn't moving the entity. However, it's also not reporting that I'm stuck in a block. During these frames, I'm not trying to move in the z-direction. distance_moved is set to 0. I'm not sure how helpful that is. Am I looking at an engine bug?

EDIT: One more thing. When I get stuck, a "blocked" event does get triggered.

Thanks,
- Bret

I experienced this from time to time to. I don't think that it is a fault of the code.
I worked around this in different ways.
Did you try to move the vertices of the bump to different positions, higher, lower more to a side, things like that? Moving the whole bunch of blocks a short value from that position can help. Nevertheless, when you add other blocks, the whole collision will be calculated different - at least from what I experienced.

What happens if you add an arbitrary block at an arbitrary position in the level?

Or, the other way round - although from your screens I guess this was your initial approach - did you set the vertex/world snap to a high value?

My consequence is: two different meshes: one for the collisions, one for the look.
The collision very simple, only few tested slopes, or no slopes at all, or only terrain for grounds with bumps and slopes. Or a lot of testing and modifying of the areas.
Depends on the current state of my project and the estimated available time for the work.

What happens, if you import it into MED, close the mesh, and use it in WED as a model with the polygon flag set?

I think its the c-move thats the prob so maybe set minmax and raise the model by a couple of quants untill it becomes unstuck.(the poly ovoid shape adds another couple of quants to the initial height of the model but can be tweaked with origin shifts in the model and z axis tweaking)
Also use c-rotate to pan, that helps a lot with this issue but its one of the reasons I went to full modell levels.

A possible solution is to have a non complex corner (invisible) over the seams like an angled single block placed just above the seams to wallk over.

Thanks for the feedback. I've moved the discussion into the "bugs" area in hopes that conitec will comment on it. Although I might be able to devise a hack that basically says, "if a c_move was attempted but the resulting distance was 0, nudge the model in the right direction", I really would like to avoid any major hacks.

In my mind, c_move should be able to handle my simple example. What, in a 3d engine, is more important than basic movement and collision?

@nems: Thanks for the advice. I've already tried adjusting the model. I've also run tests with no panning at all (my.pan=0;) and the entity still gets stuck. Your solution would work, but would require a LOT of work. I'm expecting to have a lot of bumps on the ground. *grin*

Cheers,
- Bret

Hello, I had similar problem using physics (vehicle) over a terrain.
I solved with two tricks (apply only one of them) (maybe this could help you):

First solution:
Put some prefab on the borders of the terrain.

Second solution:
put a simple cube (deformed like a floor) below the terrain:

terrain --> /\/\/\/\/\/\/\/\/\/\/\
floor --> ======================

Cheers,
Alessandro