The Projectiles are using rigid bodies and a trigger. Maybe that is the Problem. If i compare this problem to the dropped Blocks the blocks are using a rigid body whereas the Player is having the TriggerComponent to detect the Collision with the Block (if that conclusion is correct). Im pretty sure that having a rigid body with a TriggerComponent is causing the problem. I will have to have a look into that.
Inactive Combat
- Thread starter aherber
- Start date
(Emphasis mine)
... bwahahahaha! That's not a placeholder, that's a feature! I just had a blast firing GelCubes into the air and watching them rain back down onto the terrain. Then one finally hit the red miniion and caused said crash
Nicely done. And the branch looks clean, too
So to give everyone a little bit of an update, of what i have been working on the whole time and what are my plans for the future ,here is a little status update:
Planning for the Combat Framework.
The technical foundation for the Combat Framework and possibly other system taht use physic based interaction A System for Hit detection. This System is planned with 3 Goals in mind.
Accuracy:
A sophisticated, hit detection System avoids all the problems that occur when dealing with collision detection like the very prominent tunneling effect. (which still needs work in my system) and things alike. So you are still going to face that issue in its current state when shooting with the bow for example. This one is really giving me some headaches lately.
Performance:
Since we are going to have a multiplayergame performance will also play a major role in order to allow more and faster moving object within the world without an FPS drop. This one is something i have to do more research on. Im kinda thrilled by the idea of letting the client calculate the physics to allow for (theoretically) an unlimated amount of rigid bodies in the game. That would be awesome but im not sure what the chances are to get this to work. This may be a goal for the (very ?) long term planning so. I just got my head around the Bullet libary so this may need some experts. Just read an article about this. Here is the link.
http://www.gamasutra.com/view/feature/173977/scaling_a_physics_engine_to_.php
Control:
A System for Hit Management that allows to detemine and control, under which conditions a collsion event from our Physics Sytem is relevant for other parts of the game, that involve physically based interactions (like the Combat for example). This is needed for a loose coupling.
- This System is already Implemented.
Current Features:
- A HitDetectionComponent that allows to define when a physic based interaction triggers a hit. This includes hit detection on contact of the Collsion Hull of an Entity. Continious (unconstrained) Hit detection based on the Collisions detected by the the Physiscs System , timebased (periodical) Hitdetection, as well as disabling the Hitdetection completely. If you can think of other usefull constraints for the Hit detection, just let me know.
Future Plans for the Physics System:
- determine the required Thresholding for Continious Collisoin Dtection dymacally, based on the extent of the Collision Volumes and its current moving speed of an Entity. This is used for optimization and lowering the amount of data thats need to be defined for an Entity.
-Getting rid of the Tunneling effects that occur. This makes Gooey and me very sad.
Combat System:
Since this is gameplay related, i only started to implement the most basic Melee and Ranged Attack. The Ranged Attack in particular is used to test the the System for the physic based hitdetection. Im actually focusing of solving the remaining issues before i start working on the real Combat System for the game. I also plan to write a designdocument where i will desribe the planned Systems in more Detail. I will post this and im hoping for feedback. Critizism , Thoughts, Advices, Suggestions and Rainbows are welcome. I actually stumbled across this interresting article about the topic of designing a combat system.
http://www.gamasutra.com/view/feature/175950/the_fundamental_pillars_of_a_.php
So this was a real wall of text and i am sorry for that. I planned to make a pull request today, but i still need to do some work on the code. Hope to be ready soon.
Planning for the Combat Framework.
The technical foundation for the Combat Framework and possibly other system taht use physic based interaction A System for Hit detection. This System is planned with 3 Goals in mind.
Accuracy:
A sophisticated, hit detection System avoids all the problems that occur when dealing with collision detection like the very prominent tunneling effect. (which still needs work in my system) and things alike. So you are still going to face that issue in its current state when shooting with the bow for example. This one is really giving me some headaches lately
.Performance:
Since we are going to have a multiplayergame performance will also play a major role in order to allow more and faster moving object within the world without an FPS drop. This one is something i have to do more research on. Im kinda thrilled by the idea of letting the client calculate the physics to allow for (theoretically) an unlimated amount of rigid bodies in the game. That would be awesome but im not sure what the chances are to get this to work. This may be a goal for the (very ?) long term planning so. I just got my head around the Bullet libary so this may need some experts. Just read an article about this. Here is the link.
http://www.gamasutra.com/view/feature/173977/scaling_a_physics_engine_to_.php
Control:
A System for Hit Management that allows to detemine and control, under which conditions a collsion event from our Physics Sytem is relevant for other parts of the game, that involve physically based interactions (like the Combat for example). This is needed for a loose coupling.
- This System is already Implemented.
Current Features:
- A HitDetectionComponent that allows to define when a physic based interaction triggers a hit. This includes hit detection on contact of the Collsion Hull of an Entity. Continious (unconstrained) Hit detection based on the Collisions detected by the the Physiscs System , timebased (periodical) Hitdetection, as well as disabling the Hitdetection completely. If you can think of other usefull constraints for the Hit detection, just let me know.
Future Plans for the Physics System:
- determine the required Thresholding for Continious Collisoin Dtection dymacally, based on the extent of the Collision Volumes and its current moving speed of an Entity. This is used for optimization and lowering the amount of data thats need to be defined for an Entity.
-Getting rid of the Tunneling effects that occur
. This makes Gooey and me very sad.Combat System:
Since this is gameplay related, i only started to implement the most basic Melee and Ranged Attack. The Ranged Attack in particular is used to test the the System for the physic based hitdetection. Im actually focusing of solving the remaining issues before i start working on the real Combat System for the game. I also plan to write a designdocument where i will desribe the planned Systems in more Detail. I will post this and im hoping for feedback. Critizism , Thoughts, Advices, Suggestions and Rainbows are welcome
. I actually stumbled across this interresting article about the topic of designing a combat system.http://www.gamasutra.com/view/feature/175950/the_fundamental_pillars_of_a_.php
So this was a real wall of text and i am sorry for that. I planned to make a pull request today, but i still need to do some work on the code. Hope to be ready soon.
Great stuff here!
What could be cool:
As we don't have those plain cubic bodies for the caracters we could calculate the angle an arrow hits (sword maybe simillar). This is basically one dot product of calculation and then calculate a percentage chance of an arrow to ricochet Maybe armor will increase this chance. So if I have an iron helmet with a specific shape and an arrow just scuffs at my helmet I get no damage, maybe the helmet a bit
(fancy addendum)
Going further with some crafting and rpg stuff we could design helmets who are specially formed to ricochet the arrows or whatnot better
What could be cool:
As we don't have those plain cubic bodies for the caracters we could calculate the angle an arrow hits (sword maybe simillar). This is basically one dot product of calculation and then calculate a percentage chance of an arrow to ricochet
Maybe armor will increase this chance. So if I have an iron helmet with a specific shape and an arrow just scuffs at my helmet I get no damage, maybe the helmet a bit (fancy addendum)
Going further with some crafting and rpg stuff we could design helmets who are specially formed to ricochet the arrows or whatnot better
Thanks Nym Traveel
The collsion detection is actually returning me the Normal of the hit face and the Hitpoint of the collsion volume (at the moment). I could also use the world rotation of the sword or the projectile at the moment of collision and base the reflection on that. Im not sure how complex the collsion detection in regrads to armor should be. I dont know if detecting every piece of armour seperately is technicaly possible and efficient enough to support Multiplayer. Also if you want to allow to craft the form of an armour I think we should not force a player to have use a certain shape to gain some advange out of it. This maybe realistic, but it may not be seen as a fun game mechanic since its kind of restricting the creativity of the player and i think we shouldnt do that.At least thats my opinion. There are alot of games out there that allow to tranfer the stats from one item to a different item. And people do that because they like the look of certain items. I also dont know how recognizable that really would be in the game. It may be eassier to just attach some meta information to a simpler Collsionvolume that determine the change of reflecting projectiles and strikes based on the worn armour. If nothing else theres always the option for modding our system. If you want to allow crafting the amour it may be an idea to base reflection the used material at a given point. But this may also be a restriction that is not fun. And using shapes and the material as a basis for Itemstats lead to a point where items of different players look very similar to each other. I guess it depends on the plaer what he or she likes better. Dont get me wrong here i like your idea since its going in a diffent direction than other games but i think this may be a good idea for a mod. This allows the player to decide if he wants to have a more realistic armour collsion. One of the goals that i have according the Combat System is a rich risk reward System where players are given different choices in different situations and the choices the player have are meaningful and most importantly fun and not repetitive. I know that is pretty abstract and sounds good marketing wise but thats at least the direction i am aiming for. How this turns out i will have to see. This may be an impossible task. And may be i am totally wrong about this.
I know that you cannot promise the moon to people. But i know one thing for sure.I maybe know what i like but that doesnt mean everyone else agrees on that and thats why i think we shouldnt use game mechanics that force people into playing the game in a certain way. There have to be some kind of restrictions for sure. Every game can have its rules and restrictions as long as it is not lowering the fun to play it. These are just my two cents on that topic.
The collsion detection is actually returning me the Normal of the hit face and the Hitpoint of the collsion volume (at the moment). I could also use the world rotation of the sword or the projectile at the moment of collision and base the reflection on that. Im not sure how complex the collsion detection in regrads to armor should be. I dont know if detecting every piece of armour seperately is technicaly possible and efficient enough to support Multiplayer. Also if you want to allow to craft the form of an armour I think we should not force a player to have use a certain shape to gain some advange out of it. This maybe realistic, but it may not be seen as a fun game mechanic since its kind of restricting the creativity of the player and i think we shouldnt do that.At least thats my opinion. There are alot of games out there that allow to tranfer the stats from one item to a different item. And people do that because they like the look of certain items. I also dont know how recognizable that really would be in the game. It may be eassier to just attach some meta information to a simpler Collsionvolume that determine the change of reflecting projectiles and strikes based on the worn armour. If nothing else theres always the option for modding our system. If you want to allow crafting the amour it may be an idea to base reflection the used material at a given point. But this may also be a restriction that is not fun. And using shapes and the material as a basis for Itemstats lead to a point where items of different players look very similar to each other. I guess it depends on the plaer what he or she likes better. Dont get me wrong here i like your idea since its going in a diffent direction than other games but i think this may be a good idea for a mod. This allows the player to decide if he wants to have a more realistic armour collsion. One of the goals that i have according the Combat System is a rich risk reward System where players are given different choices in different situations and the choices the player have are meaningful and most importantly fun and not repetitive. I know that is pretty abstract and sounds good marketing wise but thats at least the direction i am aiming for. How this turns out i will have to see. This may be an impossible task. And may be i am totally wrong about this.
I know that you cannot promise the moon to people. But i know one thing for sure.I maybe know what i like but that doesnt mean everyone else agrees on that and thats why i think we shouldnt use game mechanics that force people into playing the game in a certain way. There have to be some kind of restrictions for sure. Every game can have its rules and restrictions as long as it is not lowering the fun to play it. These are just my two cents on that topic.
Shiny! Don't worry about rushing it to a pull request, take your time, although I would try to push to your repo on GitHub every day or two when you have updates, that way interested parties can review early and maybe help catch stuff early or provide feedback
What do you mean by tunneling?
On fancy armor, ricochets, and using shaped armor to use physics to calculate effects - I think that might be overkill
If for some reason it is easy to use physics and angles to calculate a ricochet chance on arrow vs metal - okay, if we essentially get it for free and it leads to neat realistic deflecting of the arrow. But ... with other considerations and multiplayer lag correction (did the player turn a little?) in particular it seems like that would likely be more effort than it is worth. Having the player shape armor for benefit - I'd rather just offer materials and armor types with a greater chance to deflect arrows, independently of the impact system, just if hit in head && wearing iron helmet then deflect chance 25% - that's not to say I'd turn it down, that does seem novel, it just seems like it might not be worth it
Now having arrows stick in a target's bone system - that could be a little more fun and is definitely doable - and then you can take an arrow to the knee and have the perfect excuse for everything
Also: GRYFFINDOR!
(Why oh why that background ... but yay rainbow)
What do you mean by tunneling?
On fancy armor, ricochets, and using shaped armor to use physics to calculate effects - I think that might be overkill
If for some reason it is easy to use physics and angles to calculate a ricochet chance on arrow vs metal - okay, if we essentially get it for free and it leads to neat realistic deflecting of the arrow. But ... with other considerations and multiplayer lag correction (did the player turn a little?) in particular it seems like that would likely be more effort than it is worth. Having the player shape armor for benefit - I'd rather just offer materials and armor types with a greater chance to deflect arrows, independently of the impact system, just if hit in head && wearing iron helmet then deflect chance 25% - that's not to say I'd turn it down, that does seem novel, it just seems like it might not be worth it
Now having arrows stick in a target's bone system - that could be a little more fun and is definitely doable - and then you can take an arrow to the knee and have the perfect excuse for everything
Also: GRYFFINDOR!
(Why oh why that background ... but yay rainbow)
That' what I basically meant. I didn't think that far with the helmet as additional collision volume
Just: have a helmet and it's stats say: "Wear me and you get 23% better chance to ricochet" which is added to the collision angle percentage.
Also my thoughts all were based on an arrow flying on a parabola curve, where the direction would be easy to determine. How fancy you can get with a wielding sword is far beyond my programming knowledge. Also I have no clue what moves are implemented and how.
I totally thrust you, you'll make it awesome anyway
ps:
sorry, can't code atm, have an arrow in my kneeNow having arrows stick in a target's bone system - that could be a little more fun and is definitely doable - and then you can take an arrow to the knee and have the perfect excuse for everything
Hello everyone,
just wanted to let everybody know that im still alive. Im currenly try to implement the approach desribed in these two links below to improve the accurancy and performance of fast moving objects (for example Arrows).
Well in a nutshell the solution checks if the velocity of a CollsionObject exeeds a specific treshold before every simulation step. These objects get raycasted ,based on their current velocity to see if a collsion is likely within the next frame. If this is the case a Convexsweeptest is used to determine at which point in the frame the collision would occur. This cost alot of cpu time and therefore is only used within the last frame before the collsion. Based on this value (hitFraction) the number of steps get increassed (1/hitFraction) to make sure the collsion gets detected by the Simulation. Its not to diffucult to understand. I just need to get it working.
http://www.aorensoftware.com/blog/2011/06/01/when-bullets-move-too-fast/
http://www.aorensoftware.com/blog/2011/12/13/application-specific-bullet-physics-optimization/
If you know any other sources or techniques to prevent the tunneling effect please let me know.
I also found this website/blog that is covering alot of probelems when it comes to physics and netwoking in games. I was also thinking, if the described methods of setting the timestep could be useful for us.
http://gafferongames.com/game-physics/fix-your-timestep/
just wanted to let everybody know that im still alive. Im currenly try to implement the approach desribed in these two links below to improve the accurancy and performance of fast moving objects (for example Arrows).
Well in a nutshell the solution checks if the velocity of a CollsionObject exeeds a specific treshold before every simulation step. These objects get raycasted ,based on their current velocity to see if a collsion is likely within the next frame. If this is the case a Convexsweeptest is used to determine at which point in the frame the collision would occur. This cost alot of cpu time and therefore is only used within the last frame before the collsion. Based on this value (hitFraction) the number of steps get increassed (1/hitFraction) to make sure the collsion gets detected by the Simulation. Its not to diffucult to understand. I just need to get it working.
http://www.aorensoftware.com/blog/2011/06/01/when-bullets-move-too-fast/
http://www.aorensoftware.com/blog/2011/12/13/application-specific-bullet-physics-optimization/
If you know any other sources or techniques to prevent the tunneling effect please let me know.
I also found this website/blog that is covering alot of probelems when it comes to physics and netwoking in games. I was also thinking, if the described methods of setting the timestep could be useful for us.
http://gafferongames.com/game-physics/fix-your-timestep/
Cervator and I came up with a couple ideas:
[00:17] <Josh__> I love this guys idea for multiplayer
[00:18] <Cervator> watching
[00:18] <Josh__> Plus Gliders ftw
[00:18] <Cervator> that's pretty awesome
[00:19] <Josh__> See I like games that have a path you can take but you don't have to do that.
[00:19] <Cervator> cubeworld chars soooooo teeeny tiny
[00:19] <Josh__> I know lol
[00:20] <Josh__> But gliders would be cool.
[00:20] <Cervator> yeah, very neat
[00:20] <Josh__> I think that would be a lot of fun to use
[00:20] * Josh__ Commisions a team just for gliders.
[00:21] <Cervator> one of my "dream features" is a dynamic vehicle system where if you build something sensible it just works - like vehicles with wheels and flying things with wings
[00:21] <Josh__> Commission*
[00:21] <Josh__> I like how the mobs take out part of the world
[00:21] <Josh__> I really like how they do that
[00:22] <Josh__> because that makes it more playable
[00:22] <Josh__> kinda
[00:22] <Josh__> And fun when you go and attack a mob, instead of you hitting it then running or w/e.
[00:23] <Cervator> yeah, i hooked Mo'Creatures into this Tekkit server half just to get ogres
[00:23] <Cervator> i know people hate those but i wanted to play with them as an obstacle for the experimental value
[00:23] <Josh__> Plans for AI Team?
[00:23] <Josh__>
[00:24] <Josh__> Or combat system.
[00:24] <Cervator> sure
[00:24] <Cervator> these days i'm so far behind i haven't had a lot of chances to really push feature development
[00:25] <Josh__> That would actually be a thing different from minecraft, when the combat aspect is way more fun, because minecraft's combat system is actually pretty boring.
[00:25] <Cervator> it is
Click the youtube link to see the video with Gliders and Mobs destroying terrain.
Use the Mobs destroying terrain idea like we said in the chat, if we had the same combat system as minecraft the combat system would be incredibly boring, with mobs destroying terrain it makes it more challenging to actually kill mobs and it's not where you hit the mob a couple times when it's out of range from you. Also I think Hitpoints would be nice, so then people can have stats maybe? And craft new weapons and stuff like that. So the HP Bar and Hitpoints I think would also look good
[00:17] <Josh__> I love this guys idea for multiplayer
[00:18] <Josh__> Plus Gliders ftw
[00:18] <Cervator> that's pretty awesome
[00:19] <Josh__> See I like games that have a path you can take but you don't have to do that.
[00:19] <Cervator> cubeworld chars soooooo teeeny tiny
[00:19] <Josh__> I know lol
[00:20] <Josh__> But gliders would be cool.
[00:20] <Cervator> yeah, very neat
[00:20] <Josh__> I think that would be a lot of fun to use
[00:20] * Josh__ Commisions a team just for gliders.
[00:21] <Cervator> one of my "dream features" is a dynamic vehicle system where if you build something sensible it just works - like vehicles with wheels and flying things with wings
[00:21] <Josh__> Commission*
[00:21] <Josh__> I like how the mobs take out part of the world
[00:21] <Josh__> I really like how they do that
[00:22] <Josh__> because that makes it more playable
[00:22] <Josh__> kinda
[00:22] <Josh__> And fun when you go and attack a mob, instead of you hitting it then running or w/e.
[00:23] <Cervator> yeah, i hooked Mo'Creatures into this Tekkit server half just to get ogres
[00:23] <Cervator> i know people hate those but i wanted to play with them as an obstacle for the experimental value
[00:23] <Josh__> Plans for AI Team?
[00:23] <Josh__>
[00:24] <Josh__> Or combat system.
[00:24] <Cervator> sure
[00:24] <Cervator> these days i'm so far behind i haven't had a lot of chances to really push feature development
[00:25] <Josh__> That would actually be a thing different from minecraft, when the combat aspect is way more fun, because minecraft's combat system is actually pretty boring.
[00:25] <Cervator> it is
Click the youtube link to see the video with Gliders and Mobs destroying terrain.
Use the Mobs destroying terrain idea
like we said in the chat, if we had the same combat system as minecraft the combat system would be incredibly boring, with mobs destroying terrain it makes it more challenging to actually kill mobs and it's not where you hit the mob a couple times when it's out of range from you. Also I think Hitpoints would be nice, so then people can have stats maybe? And craft new weapons and stuff like that. So the HP Bar and Hitpoints I think would also look good
There's lots of potential here, some of it long-term. Miniions can already gather blocks (or, well, break them, since inventory upgrade or physics blocks broke actually picking said blocks up) so maybe an aggressive mob breaking blocks in the way on its path toward a player could be done.
Anything beyond that we should probably put in its own thread since this one is mainly for the base system aherber is putting together
Anything beyond that we should probably put in its own thread since this one is mainly for the base system aherber is putting together
well just want everybody to know im still working on stuff. I made some observations that are very strange to me when it comes to fast moving objects and bullet physics.
This is how i have changed the stepping for the collsion detetion.
_discreteDynamicsWorld.stepSimulation(delta, 1);
_discreteDynamicsWorld.stepSimulation(delta, substep, delta/substep);
the value for the substep is chnaged dynamically based on the velocity and the collsion distance of fast moving objects. So basicly im using a fixed Timestep to increase the granularity for the stepping instead of a single substep per tick as before.
1. A collsion event is not triggered although the collsion is rendered correctly (Object is bouncing away when it collides)(Target Object is Minion which is using a trigger to detect the collision with the rigid body (Arrow) detectGroups are setup correcly). 9 out of 10 times the collsion is not triggered... . That what i looked like after seeing this . Also Coillsion detcetion seems to work better when shooting very close to the collision object.
2. Perfoming a convexsweepTest leads now to a lot of Nullpointerexceptoins thrown by bullet.....
3. Sometimes the values of the vectors from the Transform of a collisionObject are NaN (Not a number) which means an eternal positve or negative number . This could be one of the reason why the collision is not alway detected although it is rendered (???). I dont know if anyone had ever experienced this problem before. Im not sure why this happens. I dont see anything in the code that would cause this behavior. I have read that this occures when null vectors are normalized.
This is going to be a really really long weekend. I hoped i could release the first working version of the combat system before the 29th September but im afraid that it will still need more time. Bullet is really giving me some headaches lately. I dont want to sound too negative im just a little frustated right now so don't get me wrong. Im sure things look a lot better when i got a little distance and some sleep. So looks like no pixel and polygon will be harmed during the production of this game. At least for now.
This is how i have changed the stepping for the collsion detetion.
_discreteDynamicsWorld.stepSimulation(delta, 1);
_discreteDynamicsWorld.stepSimulation(delta, substep, delta/substep);
the value for the substep is chnaged dynamically based on the velocity and the collsion distance of fast moving objects. So basicly im using a fixed Timestep to increase the granularity for the stepping instead of a single substep per tick as before.
1. A collsion event is not triggered although the collsion is rendered correctly
(Object is bouncing away when it collides)(Target Object is Minion which is using a trigger to detect the collision with the rigid body (Arrow) detectGroups are setup correcly). 9 out of 10 times the collsion is not triggered... . That what i looked like after seeing this . Also Coillsion detcetion seems to work better when shooting very close to the collision object.2. Perfoming a convexsweepTest leads now to a lot of Nullpointerexceptoins thrown by bullet.....
3. Sometimes the values of the vectors from the Transform of a collisionObject are NaN (Not a number) which means an eternal positve or negative number . This could be one of the reason why the collision is not alway detected although it is rendered (???). I dont know if anyone had ever experienced this problem before. Im not sure why this happens. I dont see anything in the code that would cause this behavior. I have read that this occures when null vectors are normalized.
This is going to be a really really long weekend. I hoped i could release the first working version of the combat system before the 29th September but im afraid that it will still need more time. Bullet is really giving me some headaches lately. I dont want to sound too negative im just a little frustated right now so don't get me wrong. Im sure things look a lot better when i got a little distance and some sleep
. So looks like no pixel and polygon will be harmed during the production of this game. At least for now.
Thanks for the detailed update! Do submit the code to your branch on GitHub even if it doesn't work fully, that'll make it a lot easier to review and help catch quirky issues - especially for Immortius who probably would be able to figure something out or make suggestions
That also keeps it close to the front of the network branch making it easier to remember, especially for considering merges & potential conflicts
It sounds like it would be very cool to see the arrow bounce off a monkey head, so I also would love to just try it for the fun of it
That also keeps it close to the front of the network branch making it easier to remember, especially for considering merges & potential conflicts
It sounds like it would be very cool to see the arrow bounce off a monkey head, so I also would love to just try it for the fun of it
I would prefer not to mess with JBullet's fixed timestep like that. We need it to be a fixed value to have any remote chance of keeping physics synchronised between the server and client. I would suggest upping the maxSubSteps to 2 or 3 though, for when the framerate drops.
The default fixed timestep is 1/60, which corresponds to the general max framerate. If that length of time step cannot cope with your projectile collisions I would take a serious look at the velocities and projectile collision sizes you are dealing with. For really small, fast projectiles consider just doing a ray trace each frame (from start to end position, then update position). For larger fast things maybe a convex sweep. But ray traces would be sufficient for things like arrows, crossbow bolts or slingshots I would think.
CollisionEvents are only sent when a rigidbody intersects a trigger. If for some reason your arrows are bouncing off of their targets (which shouldn't happen for collisions between triggers and rigidbodies) then it won't intersect as such, so there will be no event. Ensure that that the minions don't have a rigidbody, and that internal ghost pair callback is being set up in the jbullet initialisation. Or perhaps I've missed something with setting up triggers.
I don't know what you've changed exactly, so can't comment on the rest.
I am itching to finish off the physics arc, but since the main remaining task is updating the API and it sounds like you have been messing with the BulletPhysics system, I guess I'll have to put that off.
The default fixed timestep is 1/60, which corresponds to the general max framerate. If that length of time step cannot cope with your projectile collisions I would take a serious look at the velocities and projectile collision sizes you are dealing with. For really small, fast projectiles consider just doing a ray trace each frame (from start to end position, then update position). For larger fast things maybe a convex sweep. But ray traces would be sufficient for things like arrows, crossbow bolts or slingshots I would think.
CollisionEvents are only sent when a rigidbody intersects a trigger. If for some reason your arrows are bouncing off of their targets (which shouldn't happen for collisions between triggers and rigidbodies) then it won't intersect as such, so there will be no event. Ensure that that the minions don't have a rigidbody, and that internal ghost pair callback is being set up in the jbullet initialisation. Or perhaps I've missed something with setting up triggers.
I don't know what you've changed exactly, so can't comment on the rest.
I am itching to finish off the physics arc, but since the main remaining task is updating the API and it sounds like you have been messing with the BulletPhysics system, I guess I'll have to put that off.