|
Re: Animation frames blending, player input/physic
[Re: eleroux]
#64768
08/14/06 09:24
08/14/06 09:24
|
Joined: Aug 2000
Posts: 7,490
Orange Brat
OP
Senior Expert
|
OP
Senior Expert
Joined: Aug 2000
Posts: 7,490
|
Quote:
trace_hit should be -1 or 1 when c_trace hits something! Why is it tested against Zero? However, I tried (trace_hit !=0) and it never was TRUE. I made a test, and found out that trace_hit is always zero.
I figured this out. I have "enable_polycollision" set to 0.5. This treats the c_instructions like old style collision and does not disable the physics engine. Setting it to 0 will disable the physics engine. If you set that var to 1 or 2 the trace_hit != 0 will work as expected. I don't know if this is a bug or simply how it is supposed to behave. I think I'll report this one and see what the answer is.
EDIT: It's not a bug, however jcl said he will tweak it if it is easy to do. Otherwise, a clarification will be made in the manual.
As for the Intense Pathfinding integration: I have it in place and working using LL's movement code. It seems that IPF also does not like enable_polycollision set below 1 so I may have to change somethings around unless LL can make it work with <1 settings. Anyway, my next step is to make it work with my own movement code. It's not that complicated, yet it's a bit tricky at the same time. Also, I noticed that my fps drops to 50 when using IPF. I don't know if this is the pathfinding itself or its dependence on a modified set of new template files. I recall a significiant fps drop when using older versions of the new templates, so perhaps I'll get those 10 fps back when I port it over to my setup.
My User Contributions master list - my initial post links are down but scroll down page to find list to active links
|
|
|
Re: Animation frames blending, player input/physic
[Re: Orange Brat]
#64769
08/15/06 03:40
08/15/06 03:40
|
Joined: Jul 2005
Posts: 366
eleroux
Senior Member
|
Senior Member
Joined: Jul 2005
Posts: 366
|
Quote:
When you say you added to a clean project, did you use the complete code I provide or just the camera?
Just the camera code. But I see you solved that!
Actually, I typed in my own camera code line by line, based on yours for the most part. I skipped the 'modes', and ended up with an hybrid 0 and 3 modes. The camera never gets aligned to the player. The camera goes first, then the player uses the camera direction as pan force. This way the camera can pan quickly even while the player struggles to keep up. And in my game I am only rotating the player if he moves. In other words, if the user rotates the camera with the mouse but the entity is standing still, it's like a free look. You can see your character's face. But if you press the Forward key, the character quickly turns back and runs away from you. The same happens when strafing - it turns, then strafes.
I didnt use the blending/ animate code yet: I am solving some player Movement issues with slopes first. It seems to be the problem with new ellipsoid collision: if you prevent the entity to climb steep slopes, it will also stop going upstairs, because the ellipsoid c_moving against a stairstep edge can return a very steep surface 'normal' depending on the step height.
I am relatively new to 3dgs (NOT a former A5 user) and I'm reading all I can about the new c_move and c_trace etc. But I think I'm doing well so far.
|Emilio|
Last edited by eleroux; 08/15/06 03:45.
|
|
|
Re: Animation frames blending, player input/physic
[Re: eleroux]
#64770
08/15/06 03:51
08/15/06 03:51
|
Joined: Jul 2005
Posts: 366
eleroux
Senior Member
|
Senior Member
Joined: Jul 2005
Posts: 366
|
Only a small contribution... if could be useful. This is the code I included to convert the difference between camera and player.pan into a rotating force, limited to the character._turnspeed Code:
//Only pan player when walking/attacking etc. if ( my._state !=0 ) { mPlayer_force.pan = (camera.pan - my.pan); //if difference > 180 degrees, change to turn other side. mPlayer_force.pan -= (abs(mPlayer_force.pan) > 180)* sign(mPlayer_force.pan)*360; //Limite to maximum entity _turnspeed my._panspeed = sign(mPlayer_force.pan)*min(my._turnspeed,abs(mPlayer_force.pan))*time_step; } else { my._panspeed = 0; }
this rotating force is later used when moving the player (c_rotate)
|
|
|
Re: Animation frames blending, player input/physic
[Re: eleroux]
#64771
08/15/06 04:24
08/15/06 04:24
|
Joined: Aug 2000
Posts: 7,490
Orange Brat
OP
Senior Expert
|
OP
Senior Expert
Joined: Aug 2000
Posts: 7,490
|
Regarding stairs, I think new collision is a bit wonky with them. This is one reason why I'm using the old AABB style collision with the c_instructions. It just works better with this particular code(no camera jerks/stuttering), plus it's faster. One trick with stairs is to make all of them passable and include an invisible ramp where the stairs are located. It gives the illusion that the player is ascending the staircase but uses the smooth slope instead of the jagged stairs. It's a cheat, but it works for the most part. It can work even better if you make a stair climbing animation for the player, but that would require some more work and timing issues. I suppose you could place a vertex(or two) on each stair and make sure a specially placed vertex on the bottom of the player's feet connects with the stair ones. This would keep the feet on the stairs, but I think this is overkill and really not needed at all if you're doing a fast paced game. I'm going to investigate the alternate blending code from earlier in this thread. It's much easier to read and appears that it would easier to add new modes to...plus it's just plain shorter. I think I'll do that first thing. Regarding your snippet...where do you place it in the code? Oh, and jcl has apparently fixed the enable_polycollision problem. The newest beta feature is allowing AABB to influence the trace_hit. I'm glad I reported it, now. Perhaps, this will also allow Intense Pathfinding to also use this setting, too. Good news if true.
My User Contributions master list - my initial post links are down but scroll down page to find list to active links
|
|
|
Re: Animation frames blending, player input/physic
[Re: eleroux]
#64777
08/15/06 19:36
08/15/06 19:36
|
Joined: Aug 2000
Posts: 7,490
Orange Brat
OP
Senior Expert
|
OP
Senior Expert
Joined: Aug 2000
Posts: 7,490
|
It used to be different. You could make a ramp block, set it to invisible, and it could be used with stairs. This was with trace, and I remember my invisible collision geometry not working when I used early versions of c_trace; thus I kept on using trace. However, trace and ent_move are deprecated, so I've switched to c_trace/c_move but keeping enable_polycollision at 0.5. Now, that jcl is going to allow trace_hit to be changed by AABB, I can keep old, faster collision.
I've never used a sprite for collision, and I was told to simply make a map entity out of my ramps or any other invisible collision geometry for c_instruction use. It creates unnecessary extra steps and take more time. I use quite a bit of invisible collision hulls(in my full levels) because of some of my oddball geometry, so it's going to take forever and a day for me to convert everything over. Lots of extra files to deal with...I can't wait.
My User Contributions master list - my initial post links are down but scroll down page to find list to active links
|
|
|
|