Ambiera ForumDiscussions, Help and Support. |
|
|
|||||
|
Hi, I have an issue with actor behavior - it doesn't show any available animations in the list: Initially they were available and actually still set, even though are not shown now. I believe, this might have happened after copying behaviors from node to node using ctrl+b, ctrl+j. Does anyone faced something like this before, is there a way to fix that? I believe, I still can create prefabs and import them to the scene as a workaround, but that's a bit inconvinient. |
||||
|
Never faced such an issue, You can try selecting a different skeleton for your 3D model, if there are any in your scene, and then switch back to the original skeleton. You can do that by selecting it from the top bar in the animation editor where it shows the skeleton's name as "clown.fbx". Are you able to see the name when you remove and attach a new AI behavior to the animated model? |
||||
|
okeoke wrote: Hi, I have an issue with actor behavior - it doesn't show any available animations in the list: Initially they were available and actually still set, even though are not shown now. I believe, this might have happened after copying behaviors from node to node using ctrl+b, ctrl+j. Does anyone faced something like this before, is there a way to fix that? I believe, I still can create prefabs and import them to the scene as a workaround, but that's a bit inconvinient. This happens to me with the main scene graph not displaying properly. Try dragging the menu/window slightly to resize it (a grab handle will appear where your red arrow is) and it will refresh the text box and display properly. |
||||
|
Hi, thanks for the responses! Unfortunately, resizing the window didn't help - it still shows no animations. I also don't think this is the source of my issue, since I'm only having this problem with one specific ccb file. Adding new instance of the behavior also doesn't help. The only way I found to workaround this is to create a prefab with animations set and then add it to the scene. In this case animations are shown until I re-open the ccb file. Not 100% convinient, but works. |
||||
|
Ah OK, thanks for the extra info. I think I remember seeing this before in one of my older projects....here's an older thread that may be relevant... https://www.ambiera.com/forum.ph... Did you edit the model externally - after importing it to Coppercube (by adding new animations to it) - and then "reload" it to the scene (replacing the original animated model)? If so, coppercube may be getting confused with the new/extra animation frames in the newly imported/replaced model . This also happened to me if I import models with the same file-names and/or animation names - the textures and animations were all getting screwed up somehow. If this is the case - the only way I know to fix it is to delete the model from the ccb file and import the new model to a fresh ccb file. If you leave the corrupted model/ccb combination in your scene, it may cause other problems. So you don;t lose all your work, you can copy/paste any behaviours/actions you have made for the model to any other scene node (as a prefab) - then copy them back to the new model/scene, once it's imported/created. Sounds complicated - hope it makes sense and also hope it fixes the issue. For me, I didn't 100%ever work out what was wrong - nor did I manage to fix it - I just abandoned the project - but I think the issue was caused by me editing a model externally (by adding mixamo animations to the model) and then trying to reload it to the scene (expecting it to update the old one) and I then also also had many other related problems such as file-names/animation-names and textures not working/showing - but it may not be the same problem you're facing. |
||||
|
veganpete Sounds exactly like my problem - I also edited the model after it was imported. Thank you! it's a misfortune there is no quick fix for that. |
||||
|
You're welcome. I don't think there's a quick fix but what you can do now to prevent it happening again (and make it quicker to fix if it does happen again) is this... I always use a 1,1,1 plane with transparent texture and call it "Dummy". I make one dummy plane for every single character or vehicle etc in my game (eg: "DummyPlayer", Dummy"Car", DummyEnemy1) etc. I add all the "collide when move" options, behaviours and actions to these dummy planes (instead of the models). I then simply child the models to the Dummy plane and set position of model to 0,,0,0 (child). When the Dummy plane moves, the model moves with it. You can use the dummy plane to change animations of the model etc. The advantages of this are many: 1- you can offset the model up/down/left/right - without affecting the position of the dummy-plane - great for hit-effects or tilting a car as it steers etc. 2- You can rotate the model without affecting the rotation of the Dummy plane (great if your model axis is incorrect and facing the wrong way.) 3- You can hide/show/scale the model and still have the character mechanics working (or you can also hide the dummy). 4- You can clone the dummy plane if you want to and also swap the model over (great for quickly changing characters/vehicles) without having to worry about copying the behaviours/actions. EG: You could swap the models of a car as it collides and gets more damaged, you can add upgrades to your character by swapping models, you can switch models to give the effect of beheading a character or chopping off a limb etc - all without affecting gameplay - because the Dummy node is actually the real character, not the model. 5- When you use "absolute" rotation on your child-model, it uses the Parent's facing-direction as 0,0,0 instead of 0,0,0 in your scene/world. (This is extremely helpful but difficult to explain why.) 6- You can move the parent-plane and rotate the child-model independently of each other if you want to. 7- When you make a completely new model (or add animations to the existing one), just delete the old one (keep the Dummy node, so you only lose the unneeded model) then import the new model and child it to the existing Dummy node. -------------------------------- Another "possible" solution may be to convert your animated models to "direct.x" format (instead of using "filmbox.fbx") as .x seems to handle the animation-frames differently in Coppercube - this is just a guess though - not sure if it would help or not when you edit/reload a .x model - you may still end up with the same problem. I'm also not sure if direct.x models work on any platform other than Windows? As a last resort, you could also try converting your animated FBX models to a different FBX version (there are many different FBX versions and internal options) - in case it magically fixes the issue. There are also several online "FBX fixers" which promise to fix any FBX issues - although I doubt they would work in this case. I'm secretly hoping that gltf/glb support will be added to Coppercube as it would make many things so much simpler. |
||||
|
Hi veganpete, Thank you for sharing - this seems like a great approach to me! This way you also can put all dummies on the same level on y axis which makes it easier to calculate horizontal distance (especially if you don't care about vertical). Basically in this case you can manipulate the scene as it's 2d. I wonder if you can also use a cube with an invisible texture that way to establish collisions between animated meshes. |
||||
|
Thanks! Yes, you can also use dummy cubes for collision - that said, the one disadvantage with using a dummy is that any collision (and actions using "position") have to use the parent - not the child - so you couldn't (for example) move something relative to the position of the child/model - instead you'd have to move something relative to the parent/dummy-cube. This confused me at first - as nothing seemed to work properly - but once I realsied that you have to use the parent as a reference instead of the child, it's never cause me any problems. Another thing you can then do (as the dummy and child are separate nodes) is to add a player-controller to the dummy (say a tank-body) and then add a "random patrol" with "walk-speed=0" to the "Tank Cannon". Now, as the player moves the tank-body, the Tank Cannon can independently turn to face the enemies when "activation radius" is entered. this is just a quick example, there are many other uses - I made a spider-mech, where the legs moved the with the player-keyboard and the head always pointed to the nearest rescue-survivor or enemy-target. Worked really smoothly. |
||||
|
|
){kind=link}