Thank you
@danno, I'll go ahead and try to answer as there are some legit questions here - even if I have answered them at least a dozen times already.
Warmly, may I ask, who is the Volcanic you are talking about? I'm very willing to understand what's going on. I'm very curious, thank you for your answer.
Volcanic is a former community member who created Rocket Viper, and was a very well respected contributor. Unfortunately, he disappeared from the community without any reason. Some time after that we discovered he was making unauthorized hacks of the engine and selling games made with copyright protected assets.
As for your post, it was fine other than language. No one is angry at you. I just have to enforce an English only policy very strictly, or we would quickly become overrun with posts from all different languages and be unable to moderate the forum. I have restored the English words and title to avoid confusion.
the new openbor features multiple collision or hit boxes dont it?
are there similarities to the new multibox system to the "hack-ish" method of the chinese samples?
, in case this is accurate , what are the advantages or purpose for such on the new engine?
One of my biggest frustrations is when I provide resources, and then someone asks for that resource immediately. I literally posted a link to the article that tells you specifically that yes, multiple collisions per frame is a thing, and how you can sue it.
As for the editor, I can tell you just by looking at the text it's for some unofficial and incompatible knockoff of OpenBOR. If I were to guess, probably something Volcanic did. OpenBOR doesn't have an "ExtAbox" or "ExtBbox", and for good reason. Multiple collision support is handled through indexes:
Collision – OpenBOR Wiki
It's right there. In. My. Post. The one you are replying to.
Now, as for the difference between it and my script? I'm going to explain this one more time and
not again. The script is not a hack to achieve multiple collision boxes. It is a means to react to information the engine itself already provides - the
centroid. Meaning the midpoint intersection between body box and attack box coordinates. The engine uses this to position flash entity spawns, but it can be useful for a lot of other things too, like simulating scaling hit boxes or changing the reaction animation depending on where a hit occurred. The latter case can ALSO be done by setting up multiple collision boxes and then getting the index of the body box that detects a hit. Which solution is better just depends on context of the module in question.
all i can think in some cases is creatures, monsters or weapons that feature tentacles, chains or ropes that can be disintigrated bit by bit...
on the defensive side - for a castlevania 4 style whip, which i supect migth have multiple boxes when its in hold button mode (where it actually had a really string-like feeling)
that whip, its weird that it has not been programmed again
Yes, and no. It IS true that multiple boxes might be needed for odd shapes, and that is exactly why I added support for multiple boxes per frame in the first place. However, these are specialized, edge cases, and when they occur, you still use the
bare minimum of boxes you can get away with to describe the shape. Castlevania is not using multiple boxes on whips. It centers one box that covers the approximate area.
Take Dhalsim from SFA3. These are his actual collision boxes. Surprised? Capcom might take a lot of flack for boring design and sequelitis, but anyone with any sense at all knows they also set the gold standard in precision frame and pinpoint accuracy in their fighting games - yet they rarely use more than one attack box. They generally have two to three body boxes, one pushbox (green) and one attack box. That's all you need to cover pretty much every shape and size.
If you pay attention, you'll notice that those extra boxes on his feet, are not even extra. They are actually his "torso" and "head" boxes moved out to cover the limbs. At no point does any character ever have more than three body boxes, and when the game doesn't need to need to worry about shapes or differentiate hit zones, they have less (see the jumping pose).
And keep in mind, this is a vs. fighter - it only has two entities to worry about, other than the occasional moments when there are projectiles on screen. Fighting games can afford to splurge on collision - and they are. That's what I'm getting at. Having just two or even three boxes is a BIG deal. It's effectively tripling your CPU load per entity. Action and beat em' ups can have dozens of entities, AND they have to handle terrain, which are also collision boxes. They will never use more than one collision per type unless they absolutely have no choice.
And on top of all that? Ultra precise collision is NOT precise. What you actually end up with are attacks that stupidly pass through the target because they didn't hit some arbitrarily little pinpoint. See also: The professionals figured all this out a long time ago.
This is not collision accuracy. It's just really, REALLY bad design.
DC
