Ambiera ForumDiscussions, Help and Support. |
|
|
|||||
|
in my project when this camera isn't the first active camera in the scene the gun [b(child of the camera) is attached to the player but doesn't follow the cameras movement like left and right up and down[/b] here's the file https://www.mediafire.com/file/x... |
||||
|
The gun appears to follow the camera just fine. You just need to tell the gun where to look (eg: every 20ms seconds,look at camera target)....https://veganpete.itch.io/fps-shooter-for-gamejam |
||||
|
it's a known bug and happens only when starting the game if your FPS camera is not the active camera. in order to fix the issue, simply change your game's Active camera to FPS camera, and attach a new behavior to your Root Scene node. "Before first drawing do something" and in that behavior, you can add an action "Change Active Camera" that will change your active camera to the "third person camera", it will fix the issue with the children nodes of FPS camera. but you might need to re_allign your TPP camera, in order to make it translates or follow the Van correctly, you can simply create a dummy van at the starting point of the path, and can then adjust the camera accordingly. Right now in the provided CCB file the camera is in the middle of the "Path" somewhere so when switching to this camera, it will start chasing from the middle. I did posted a demo, in which I shown this fix, here is the link to that demo file.https://drive.google.com/file/d/... You can see in this demo, I have been setting my Active camera on before first drawing to a simple camera and then after sometime, after the dissolve shader gets completed I change back to FPS camera, so that the torch attached to it will work normally. here is a YouTube video of the demo file if you are interested in watching, however this video doesn't tell you anything abou the fix. https://www.youtube.com/watch?v=... hope that helps. 
|
||||
|
The problem has been discussed in the forum before and is very annoying, a real brake on innovation. You could try my free workaround fix for the broken child of second inactive to active camera issue developed quite a while ago. @spicymilk & anyone interested, here is a fixed version of spicymilk's project file plus my CamChildFix behavior: https://www.dropbox.com/scl/fo/p... |
||||
|
@hadoken, thanks for the fix, this fix is something similar to what @VP has suggested. if you want you can further improve the behavior, by removing the type "scenenode" property from it. and put a for loop in your code that will check all the children of the camera node, As the user might have many children objects attached to the camera. |
||||
|
Here some further hints for my provided fix: as the fix is not in-built but based on JavaScript look at camera's target calculation there could be some slight child position lag or jitter to be encountered, especially at fast side movements, but I guess in most cases we can live with that for now to make the fix work, the camera's children must have their origin position stritcly at 0, 0, 0 but in most cases like with tools or weapons you want your child mesh with some offset to the origin. To achieve this with a still working fix you have two options: - use some auxilary root node as first level camera child with position zero and parent your tools/weapons to it as second level sub children which then can have position changes (no loop function needed, but can't use fps cam "disable child clipping" which unfortunately doesn't work for sub children) - use your tool/weapon directly as the camera's first level child with strict position zero but achieve position changes with polygon editing by moving the child's vertices ("disable child clipping" can be uses to 1st level children, an extra added loop function to my behavior would give comfort to fix all children at once, but you could also simply use the behavior multiple times, I guess in most cases you only have a handful of children) Hope you find this helpful. |
||||
|
P.S.: if you want to use animated children (e.g. some animated weapon) instead of static meshes you must go with the auxiliary root node approach, then you could adjust the camera's collision shape big enough to take care of can child clipping or not ... |
||||
|
behavior_HadokenCamChildFix (sorry, old link was broken) updated link 2023-05-27: https://www.dropbox.com/s/ejr7uv... |
||||
|
|
){kind=link}