Bleach:Zanpakutou Senshi is a totally free Total Conversion of Half-Life 1. It´s based on the japanese hit Anime Bleach.
To follow up on Update #23 and clarify what is done with the collision boxes:
Keep in mind that this could be relevant for any type of model that can be rotated, as the Axis Aligned Boundary Box cannot be rotated. Also keep in mind that the solution comes with a cost of multiple elements instead of one, and one weight that against the need of precision.
In this image you see 4 shapes, the top are how the Getsuga would look with a boundary box when aligned and when diagonal to the world axis (represented in 2D as x and y), the bottom shows the Getsuga with multiple boundary boxes inside itself when aligned and diagonal to the world axis.
The boundary box is coloured red and the area that would incorrectly be part of the collision is striped with blue lines.
The AABB is fast to calculate and today is often used as a broad collision detection in modern engines. Those elements that collide will then use a more advanced collision detection algorithm to determine if there is a collision or not.
In HL AABB is what you got to work with and when it detects a collision several things happens, including a event call to a Touch function. It is possible to do a more detailed check at this point, but it is not practical to implement a custom collision system in HL.
If the boundry box was able to be rotated we would have been satisfied with that, so the top left shape is adequate for us, this is because the attack moves quickly forward.
However, when rotated there will be a spike in front of the model, this is not okay.
The bottom shows our solution by adding several small elements inside of the model, the model doesn't collide itself any longer. When aligned and diagonal it is only a matter of insignificant spikes that might extend from the model, providing more satisfactory game play.
The blue lines are not on the bottom shapes due to inadequate space to show them - not because they a perfect solution.
Its cool to here how you're working around these issues. Even though bottom ones aren't a perfect solution, if theres no room for blue lines that's gotta mean its a vast improvement.
Definitely. But I haven't come up with a creative way to do a performance check yet....
I will actually do that as the next thing.
What about making a model with multiple hit boxes instead of one for all so to speak?
The model consist of 3 brushes and 3 hitboxes.
HL ignores the hitboxes and makes one single BB per model. I played around with the QC file to try to enforce it to use the hitboxes, but it didn't work out for me.
While the issue of the diagonal BB will be reduced for 3 seperate BB's there would still be an issue because the boxes are retangular and that extends the BB alot when rotated.
A square of 1x1 is 1.44 in the diagonal, so only 0.44 extra.
For a circle or sphere it would not be relevant as the BB remains the same regardless of the object's rotation.
huh, thats a bummer.
Thanks for your questions and feedback, it made me look into the performance on behalf of your curiosity.
Currently I have experienced that spawning 200 getsuga (1200 entities) at once isn't quite alright for the engine to handle. Spawning over time i reached 460 before getting the same error.
ED_Alloc no free edicts
Forums.alliedmods.net
Luckly there is a "fix"
Forums.svencoop.com
I doubt we can expect everyone to be aware of this, but it could be a possibility.
Practically though the engine seems to get enough around 200 getsuga's, 300 and some lagging will occur on my machine.
So that is some 1200 entities. (getsuga model + 5 collisionboxes)
So keeping in mind of existing entities (47 with 1 player on our largest map) and assuming 100 getsugas active at the same time is quite unlikely (but not impossible), no more than 10 collisionboxes would be recommended.
It should also keep inside of the default allocation size for entities.
ok then, are the getsuga's moving and deleting on impact? and if they are, are the spawned entities actually being deleted or simply left there or no longer registered as part of the active group?
so say on the biggest map its a 10v10 fight, and everybody is just spamming an attack like the suga's, how many would be in the air at once? just how much of the entities use would there be? i do recommend increasing the amount by default if you could.
Yes, on impact the collision box will call a function in the getsuga. In that function an explosion will happen and all its collision box's will be deleted.
I will go more into depth of it in the upcoming tutorial.
With the limitations of reiatsu and the speed of the attacks, it seems unlikely that the amount should reach 100 unless a very coordinated action by all the players were to take place.
In addition the elements used for debugging will be removed, and as such there won't be a message overflow; this should prevent lagging.
I recommended no more than 10 collision boxes in an attack as 1200 entities seems to be at lot for the engine to handle. That said, it is not equal that the getsuga will have 10 collision boxes. The prototype only uses 5 and it has been promising so far. I need to implement the actual model before I can determine the need for collision boxes.
Awesome to see things are going well.