Ambiera ForumDiscussions, Help and Support. |
|
| [ 1 2 ] Page 1 of 2 |
|
|||||
|
For some reason, in my Watchmaker's Frog" game, bullets don't collide with the maze's mesh in my scene - but the Frog's "collide when moved" ellipsoid does. Any way I can get bullets to collide with the maze? Why would bullet collision not work? - is it because I've enabled physics simulation? Thanks. |
||||
|
Did you try flipping the direction of the faces of the maze? |
||||
|
Can you click on the maze mesh in your scene to select it? |
||||
|
I've had issues being able to click on a mesh because I scaled it to 0 on a axis before. Maybe check for that? |
||||
|
Bullets are non-collidable, they never collide with the geometry even if you have collide when moved behavior attached to them. You can only execute an "Action on Impact", that is execute an action on collision, but they won't stop their movement if collided. You can however use the action on impact to delete the bullet, or do other task with it there. Just make sure there is a Behavivor "Game Actor with health and AI" attached to a node in your game otherwise "Action on Impact" will not work. hope that solves your problem. |
||||
|
Ah, thanks everyone, yes, I had flipped the faces, bullet impact still didn't work, also tried without attaching to the zero size node - good idea. I'll try adding "game actor behaviour" to see if it works. It's actually the "on impact", move to "last bullet impact position" that I wanted to use - but it doesn't detect the bullet hitting the mesh. Thank you both, hopefully the game "character" will fix it. Nice one Guest, nice one just in case |
||||
|
Can't get it to work. I checked my Rebel County project and my Escape from Manhattan project, the bullets do seem to collide with the City mesh (they don't appear to pass through), they don't seem to need the "game character" behaviour either, they just automatically collide with any mesh that has the "collide" checkbox enabled. Not sure why the watchmaker's frog mesh is behaving differently. I tried, flipping faces, double sided faces, adding game character, freezing mesh scale, inverting the mesh scale - no joy. It's probably something simple I'm overlooking - maybe something to do with the format of the mesh itself. I'll try exporting the mesh with different options to see if it fixes it. Strange thing is,the frog collision works perfectly. I may be able to find a different workaround to do what I want, I'll have to think about it. Thanks again. |
||||
|
i have ring .obj in my test game that rotates. i set Game Actor with health to it.. i set its health to be 0 IF i set health to 100 then first 10 bullet hits will hit its bounding box and not a location on triangle of the model. So if your player is in the ring -inside the bounding box of the model then bullet hit wont be working. Without Game Actor with health it doesnt collide at all. Dont know why or how it exactly works but maybe you have similar problem with it. Video of this test. https://youtu.be/7S0LrlStV7E |
||||
|
Thanks Sven appreciate the video. I think I'll give up on the game for now. I've encountered another problem which means I wont be able to complete the project at all. When I added a larger maze mesh, the physics and collision started to glitch badly - the frog and maze movement becomes really jerky and he starts walking through the walls. The mesh is only 150KB file-size with around 1000 points and 2000 faces. I may come back to it again in the future to see if I can finish it. |
||||
|
Well, it actually never collides, by collision I mean it stops its movement and stays there, The Game Actor behavior is what deletes the bullet on collision. So yeah it is sort of collision and not colliding as well. HAHA pretty confusing to explain. If the bullet stops executing the action on impact when the health of the game actor is zero or when the actor dies. Then you can prevent this by applying the "Game actor behavior to an object" that is placed somewhere in your scene where the bullet will never reach. @VP, sorry that you have to drop th e project, I just tried it and it was a really great project, liked the death animation of the frog and the way the chain is animated as the time decreases. Did you tried creating it without the physics engine, I think it is possible to do it without the physics engine as well. |
||||
|
Thanks for the encouragement Just_in_case, I really like the concept of the game too. I'll keep going with it. I have tried it without physics, it does work (almost the same as with physics engine) the only issue was that I couldn't get the frog to collide with the maze when it moves - but I do know a workaround for that (using bullets) which I can test today to see if it works. It would collide with the floor of the mesh, but not the walls. I was hoping this one would be a simple prototype that I could scale up into a full game without any problems. Last night, I managed to think of a way to fix the other major problem, while I was trying to sleep. I just have to think how to implement it properly without coding.... When you turn a wheel, the outer circumference moves quicker than the inner circumference - this means that start of the maze moves slowly in the center and ridiculously fast, the further away from the center the frog travels, the bigger that speed difference becomes. You can notice it slightly in the demo but because the maze is so small, it's not a deal-breaker - but when the maze gets bigger, it becomes a huge problem because the frog suddenly stops colliding and falls through the mesh instead. I can fix it by slowing the turn speed of the wheel as the frog moves out - I'll probably have to use some carefully place "on proximity" markers, so it works dynamically. The only other issue is file-size, all the assets are tiny but for some reason, each level weighs around 45MB. Because I'll be switching between different ccb files, there are 50 levels, that's over 2.2GB just for a casual game lol. I might have to try to cram the levels into the same ccb file to get the final game around 50MB instead - but I need to decide on that before I start adding all the levels. |
||||
|
Ahh I just tried the ccb file, and it seems like the Collision API I created will be able to fix it, but unfortunately, that's not available to use at the moment. Actually, the API recreates the Triangle selector for the object, So if we turn Off and On collision during runtime whenever the object change rotation, then it might fix the issue of the collision. Another alternative can be the proximity sensors, you can create dummy nodes with proximity boxes, at the position of walls with the scale of walls, that will set variables when in proximity with the frog. If the variable is true then allow the spinning of the maze, otherwise don't allow it, or vice-versa. The shooting mechanism can also work. You should probably keep them all in one single level, Create a folder node "level1" and keep all the level 1 data there, Create another level folder there and put all the level-related data there, in order to prevent yourself from getting messed with different levels, simply hide one level while working on another level. It will keep the screen clean while creating more levels, and you can simply copy-paste behaviors and other stuff and reuse the same stuff if you need them. That will save you a lot of resources for sure. |
||||
|
Thanks again Just_in_case I had hoped to use bullets to control the wheel rotation, but the issue I'm having is I can't get the bullets to hit the walls of the maze - so I can't use the "move to last bullet impact" to stop the rotation when I need to - not sure why, it works in all my other games but not this one (probably something to do with the mesh as I can't notice anything else that's different). If I could get bullets working with the mesh, it should be quick and easy to fix. *The other thing it may be is an optical illusion with the 3D view - maybe the bullets are working perfectly and simply not firing where I think they are. I'll do some thorough testing by placing the camera at different positions to make sure exactly what's happening - it may be a simple case of adjusting bullet offset/direction... If not, the only issue with placing individual "on proximity" sensors is the amount of work it will require. There are 50 levels and the larger ones have quite a few walls - I would also need to place 2 for each wall so it prevents rotation in one direction but not the other,depending which side of the wall the frog is on. My final solution was to remake all the maze meshes in coppercubes polygon editor - but I've already spent a lot of effort in making them. I've tried exporting one from blender with different settings and file formats (stl, dae, b3d, fbx, obj, milkshape), hoping it would fix them. In fact, they're here if they'd useful for anyone, rather than waste all the work so far....https://veganpete.itch.io/watchm... They're in stl format. I'm sure I'll fix it when I get a bit more free time. First thing I'll do is I'll re-read all these posts again as I sometimes get confused and miss something obvious that's already been suggested. Yes, definitely best to put them all in one scene in terms of filesize. Cheers. |
||||
|
.....Oh, incidentally - something I wanted to mention - when I place the level data in a folder (especially the mesh) - the performance is hugely affected. I never noticed it before but it's very obvious with this particular game - take the mesh out of the folder and it works perfectly again- something worth looking into. I think it's the "every few seconds" having to recursively look inside the folders? That's why the ccb for this game looks messier than usual - I deliberately didn't use folders. It made me wonder if childing does the same - maybe even the number of characters used in the node name. If I strip away all folders, children and get the node names down to a few characters each - it may squeeze a bit more performance? Not sure, but definitely something fishy with using folders with my workflow. |
||||
|
Strange, I never noticed such behavior of the folder nodes, maybe you have a script in your game that for loops the children of that folder or something similar. so when putting everything in the folder, the amount of child nodes gets increased, and it do the calculation for all the extra child nodes as well. or maybe something else. As folders are only placeholder dummynodes, if you think it is only the folders that's causing the performance issue, then you can try creating an empty node and use it instead of folder, make sure you use a true empty node that is, create a plane cube or whatever you want and simply go to polygon editing tools and delete it's geometry. so that you won't have extra unnecessary polygons in your game. I am going to try to create a test app of your game with the Collision API that I created, and will see if the collision issue gets fixed or not. I hope it will be fixed. If it gets fixed then I can upload the updated Coppercube player, so that you can use that and let your game works with it. I think, I can create a plugin for it as well, so that you or everybody else can directly run or test the game in the updated player of mine, just like you do normally by pressing Ctrl+F10. that can be an idea, will try to create it today. I've got a few gap in between my exams, so I can utilize those holidays haha.. |
||||
| [ 1 2 ] Page 1 of 2 |
|
|
){kind=link}