|
|||||
|
Just updated the behavior, here's what's new: - Added Jump functionality (customizable using 'jumpSpeed') - Added an ability to overwrite the animations by external means (Actions like "When a key is pressed => Set the animation of a scene node" etc.) for a certain amount of time (customizable using 'externalAnimationWindowMs' property) before the behavior's own animation handler kicks in and takes control again. See the demo ccb file to learn more about it. - Added the ability to turn off the behavior's movement and animation handlers (so that you can set up your own animation or movement behavior and have them not get overridden by this behavior) - Added customizable Run and Jump keys (just like the movement keys) - Added mid air animation slot Just make sure to reset the camera (detach my behavior, refresh the plugin list then re attach it to your camera) Let me know what you guys think :) @floydness Try the new version and see if you can get it working the way you want. Also you're right, The pistol lags behind the player, I don't think my behavior is causing this issue but I'll look into it. |
||||
|
Tried the new version and seemed like the mouse was messed up and the player was hard to control turning the wrong way etc so I put the older version back in. I'm thinking maybe if I hide the gun when walking it won't matter anymore. Probably what I'll do. Thanks. |
||||
|
The ability to overwrite animations by external means & customizable Run and Jump keys are great improvements! So after shortly trying version 1.2 I must admit that in the meantime you have developed your script so very awful well that I think it should be recommended the initial basis for nearly every third player & FPS game to be made with CopperCube when it comes to initializing player, camera & animations control for your project - again my heartfelt thanks and sincere admiration! Regarding the attached pistol lagging behind the players animation movements: Attaching additional custom objects to skeletal nodes of animated meshes seems to be a very promising, useful & desired feature in CopperCube. Unfortunately it doesn't work, at least not without that nasty lagging issue being a real show stopper in that department. The only workaround I know of also to be found among the forum would be the exchanging of identical character clones but with different attached (weapon) objects combined as single mesh. Of course that would increase the game's data amount on the other hand. |
||||
|
@floydness I experienced smnmhmdy's TPC version 1.2 to be working perfectly, maybe you could check your other additional behaviors again? |
||||
|
@hadoken Thank you for your insightful comment, That would be a smart workaround, since you can seamlessly take control of the different nodes at runtime by changing the smTPCAMERA.Player variable. Something like this and using 'when a key is pressed do something' action: smTPCAMERA.Player = ccbGetSceneNodeFromName("Player2");
|
||||
|
Hello Smn Mhmdy, Thank you for your advice about using the special variable "colsmalldistance" when running CopperCube in "Physics simulation" mode. As mentioned in the documentation, I added this behavior in the "scene" node : "Before first drawing do something" -> "action" -> "Set or Change a Variable" -> "hashtag man.colsmalldistance" -> "value = 0.005". I don't see any improvement with that setting. However, without using that setting, I notice that the "man" in your demo climbs better a hill than going down it, especially when it runs. (tested with your TP Camera ver.1.2 <-- you are a workaholic.) :-) |
||||
|
@ hadoken I'm really just learning Coppercube so very likely it's something to do with how I've put things together https://youtu.be/1QEbq6-KmWA Demonstrates what I've got going with the 1st version not the new one. |
||||
|
Smn Mhmdy, I come back to suggest you a test with this file shared on my OneDrive (secured and anonymous access) : https://1drv.ms/u/s!AjokN1FU3jK1... This little project demonstrates that wiith some built-in camera, the player is able to easily climb stairs and hills when the Physics Engine is switched on "Physics simulation". I noticed that there is a relationship between the "Soldier-Move Speed" and the "Scene-Gravity" values. Therefore, I adjusted the Scene-Gravity's value (default 10 replaced by 3). Soldier-Move-Speed's value set to 0.05. :-) |
||||
|
@marcw Hey marc, I loaded up my behavior in your scene and changed the player's 'walkSpeed' to 0.5 and it fixed the issue to some extent, So it seems like it's a speed dependence bug or something. I suggest you to look around the forum if you haven't already, and try different workarounds and suggestions. One thing that should have a massive impact is colsmalldistance variable, I couldn't see an improvement when changing it either (at least no improvement when used on a third person character, I've seen it's effect on a fps camera), but it seems like so many people have seen difference so we are doing something wrong probably. |
||||
|
don't know what value you guys are putting for colsmalldistance but it needs to be very low value. Didn't try @Marc's scene yet will download and try it. |
||||
|
Hello everybody, I uploaded a new CCB file ("SM Thirdperson Controller Physics simulation Test.ccb") in the shared folder mentioned in my previous comment. I didn't use the special variable "colsmalldistance". I tried it with low values as mentioned by Just_in_case (Vazahat), but I couldn't see any improvement in the player's collision. I created a new textured mesh "stairs_a.fbx" with my modeler MetaSequoia (the mesh is included in the shared folder) and I placed it in the original demo scene created by Smn Mhmdy. That CCB file is a copy of the demo version 1.2 provided by Smn Mhmdy, but I adjusted the value of a few variables (Scene-Gravity, Man-walk-Speed, Man-walk-animation-fps, Man-collision-size) for the purpose of compatibility with the mode "Physics simulation". I think that the normals of the mesh "stairs" that Smn Mhmdy used for his demo could be wrong on some vertices. A correct outwards orientation of the normals is required for the physics simulation. :-) |
||||
|
Just tried to the ccb file provided by @MarcW, old ccb. And found that when the movement of the player is increased the player flies in air whenever he colides with bumps or stair. Or if the geometry is not flat. There are a few fake gravity behaviors burried deep down in the forums maybe one of them could be use to create a fake gravity for the player which can fix the issue. Other than that new movement scripts needs to be written in order to make perfect movement with physics using ccbSetPhsyicsVelocity command.. For example when a key pressed down W then ccbSetPhsyicsVelocity (player, (0,0,1)); that way one can create a new movement script to work with physics system. The biggest benefit of creating new movement script for physics system is that there will be no need to use additional fake gravity behavior after that. Simply attach object controlled by physics engine and then you can adjust the density of the object so that it will behave as per object gravity effect. Also am planning to upload a few more video tutorials regarding more coppercube features which people generally don't use that much. But can be usefull. For example you can correct the rotation of an animatef object using the animation editor window. Just select your animated mesh and right click in the animation editor windows to correct the rotation of your animated player. This can be usefull if you are using custom behavior and you don't have a property like additional rotation there. There are lots of other options too , will try to make some time out of my busy schedule and record video tutorials. For all of them. Also am working on custom UI icons for coppercube. Posted screenshots on my Discord, if anybody wants to join, there are already more than 50+ members there and the number is increasing. https://discord.gg/RKcq89S7uA |
||||
|
Just_in_case (Vazahat), thank you for having examined my first CCB file relative to a test of the Physics simulation with some built-in camera handler. You are right, if the gravity is too low and if the player's speed is too high then this one could somewhat rise off the ground. In the second CCB file (a copy of Smn Mhmdy's demo with a few modified values as detailed in my previous comment), I think that the TP Camera's behavior created by Smh Mhmdy performs a quite good job with the Physics simulation enabled. I would say that perfection doesn't exist and personally I am satisfied with that solution for one of my CCB's projects. I already read a few times invitations to some Discord meeting. I think it is indeed a good opportunity for people who are interested by live chatting. I also read your thread relative to (free) resources for games developers. Daily, I am trying to save time. Life is too short. That's why I am trying to concentrate on a minimum of activities. Anyway as I already said, I appreciate very much the comments and the assistance provided by the CCB experts of this forum. :-) |
||||
|
@marcw Thank you for sharing, Moving up the slopes and stairs is near-prefect now. I've tried what @just_in_case has suggested about moving the player by setting the player's physics velocity but it didn't make much difference, and since it also happens with the built-in tps controller I'm assuming it is an engine limitation |
||||
|
@Marcw just tried your updated version with @smnmhmdy tpp behavior and it worked great. and after reading his comments regarding movement based on physics as he said didn't make much difference. I can also conclude that it is a limitation of the physics engine. |
||||
| [ 1 2 3 4 5 > ] Page 2 of 8 |
|
|
){kind=link}