Background
What are Hit-boxes?
Hit-boxes in M&B are little balloons around each bone of a moving character used by the game to understand if something hit that part of the body, and, by extension, that character. A character, independently by its apparent size and look, is hit just if an only if the ballon is hit. The rationale is that it is much quicker for the game to check the "balloon" for collisions. It is similar to the Collision Objects (which are for static meshes, however, and can be any shape -- not just baloon).
Another use of hitboxes is in ragdolling, to avoid that, say, an arm pass though the chest when the guy is dead and is falling like a huge bag of potatoes.
Hitboxes for human and horses in vanilla Warband, visualized with OpenBRF
Why you want to edit them? Simply put, if you make a new skeleton or customize an old one, you want to make a new hitbox set for it, for a more realistic fighting experience in the game.
Hit-boxes in M&B / WB
The game keeps, for each different skeleton it uses, a hit-box set (composed of at most one hit-box per bone). Some bone, usually smaller ones like "hands", have none (at least in vanilla). Every hitbox is shaped as a "capsule", the geometric shape you get if you cut a sphere in half and cram a cylinder of the same radius in the middle.
Now the ugly catch: Hit-boxes for skeletons, unlike basically all other content of the game (e.g. meshes, animations, materials, collision objects...), are not stored in any BRF file!
Instead, the game keeps them in a separate file, "skeleton_bodies.xml", which holds all hitboxes for all skeletons used in a module, plus a few other metadata also associated to skeletons (used for regdolling). That file is kept in "<your_module>/data" folder, but, if not there, a default copy is used from game "data" folder.
That's a bit of a problem for OpenBRF: hit-boxes are tightly linked to skeletons, they cannot even be visualized without one, and yet, if they are modified, not the BRF file holding the skeleton, but this global .xml file has to be saved. That will cause some confusion, I'm sure. Important: the link between "hitboxes" (in the XML data) and skeletons (anywhere in BRF files) is by name: a hitbox set will be associated with any skeleton with the same name (by the game and OpenBRF alike).
How-to's in OpenBRF
Visualize hitboxes
Just select the corresponding skeleton. You'll see, in the databox, a check-button called "has hit-boxes", in the "data" box, which tells you whether that skeleton has an associated set of hitboxes. If it does, you can visualize the set of hit-boxes by selecting the option inside the "view" box.
Hitboxes can be visualized also when seeing skeletal animations (to see how they behave during an animation). In all cases, they can be visualized overimposed with a rigged "skin" (the skin can be quickly toggled on/off with space: doing so helps perceiving how well the hitbox fits an actual character).
When you change the current module (and at start-up), OpenBRF scans the file "skeleton_bodies.xml" and remembers all the hitboxes found there: it will use them together with skeletons with the same name. OpenBRF reloads that file from disk when you hit F5 ("refresh module") (with many other things).
Remember the association is done by name: for example, if you rename a skeleton, it can lose (or gain) a hitbox set.
Edit hitboxes manually with a text editor
Anything you need to do with hitboxes of your mod, you can do it manually, by opening the file "skeleton_bodies.xml" in a text editor (copy the one from <game>/data folder into your <module>/data folder to start with). The file is a XML so it's should not be too difficult to figure out and edit.
To visualize that what you did made sense, you can keep OpenBRF open: just save the XML file and refresh OpenBRF with F5: the hitboxes will be updated.
This is the "slow but sure" way: you can add, delete, edit any hitbox assocaited to any skeleton. It is just not very intuitive to do. That's the emergency way to do anything (even without OpenBRF). However, OpenBRF offers functionalities so that you can, in most cases, do all you need without ever opening that file.
WYSIWYG editing hit-boxes within OpenBRF
- Select the skeleton with the same name as the hitbox.
- Click on any bone on the list.
- You can now use the controls to thicken, elongate, move, rotate the hitbox for that bone. You can also activate/deactivate that hitbox (not all bones must have one). You can make the hitbox symmetric (e.g. you edit the left leg, and use that to update the right leg so that it matches). And so on: experiment with the controls, they should be easy to understand with very little tries.
- Hint: while you edit, it helps to turn the skin on and off (keyboard shortcut is "space") to see that your hitbox is right.
Edit, forgot to mention: while using these controls, if you keep any modifier pressed (ctrl, shift, alt...) you will just nudge the hitbox a little.
Save a modified hit-box set
Now the tricky part: when you modified a hitbox set in OpenBRF, a "(**)" (note: double *) will appear in the OpenBRF windows title: this tells you that you have unsaved changes in the skeleton metadata. It's of no use to just "save": that saves the BRF file with the skeleton, and hitboxes are not kept there. Instead, you need the command, under "Module" menu, to "Save module Hit-Boxes for all skeletons".
Don't worry: you will be prompted that you must save your changes, and offered to do so, whenever you are about to lose them (e.g. you try to quit OpenBRF, or open another module, etc).
(hint: a quick way to discard your edits, if you need to do so, is to refresh the module with F5 and pick "discard changes" when prompted: that reloads the current "skeleton_bodies.xml")
Remeber you never save just a single hitbox set: you save either all hit-box sets of a module or none.
Caveat: when OpenBRF saves the hitboxes, it saves a "skeleton_bodies.xml" which is looks very different from the one found in native (a backup is done anyway). This is because equivalent XML files can have many different forms (indentation etc). In particular, OpenBRF unfortunately scrables the order of "attributes" inside nodes. The game does not care at all, and works correctly. But subsequent manual edit of that xml file can gets more difficult, I'm afraid.
Add a hit-box set to a new skeleton
When you create a new skeleton (e.g. copy, paste and rename an existing skeleton, or import it), it will have no associated hitbox set. Unfortunately, you cannot just add hitboxes to its bones, one by one, because there is no way OpenBRF would know the rest of the metadata which will have to be saved together with the hitbox.
Instead, you have to transfer an existing hitBox-set from another skeleton.
How to do that:
1) select origin (a skeleton with hitbox), [edit]->[copy hitbox]
2) select destination, [edit]->[paste hitbox].
The two skeletons must share the same number of bones.
More on copying and pasting hitboxes
The above is the "direct" way to copy a hitbox set from a skel to anther.
As an alternative, you can pass through a collision object. The effect is a bit different (see below).
That's how you do that:
1) select origin (a skeleton with hitbox), [edit]->[copy hitbox]
2) [edit]=>[paste] (or ctrl+V), creates a static Collision Object with all the capsules
(maybe edit this Collision Object in whatever way you like)
3) [edit]=>[copy] (or ctrl+C) this collision mesh
4) select destination skeleton, [edit]->[paste hitbox].
In other words, the hitbox set you copied from a skeleton can pasted the normal way (step 2), instead of pasting it "as a hitbox". That creates a (static) Collision Object, made of capsules (plus "empty" placeholders for bones without hitboxes). The capsules are disposed statically according to bones in the original skeleton.
This Collision Object can potentially have its own uses, and can be treated as any other BRF Collision Object (e.g. they can be saved in the BRF, edited by re-scaling them, or by manually editing their many numbers, or be exported-modified-and-reimpored, etc.).
A Collision Object of this fashion can, in turn, be copied and pasted "as a hitbox" over a skeleton (steps 3 and 4).
The two ways to transfer a hitbox from a skeleton to another are a bit different:
- If you direct, the capsules will adapt to the position of the bones in the receiving skeleton.
- If you go though the Static Collision, their position are fixed in space, indendent of the bone positions of the destination skeleton.
I kept both ways because there are cases when either of the two things is useful. Can you see why?
Minor: remove a hitbox from the module
That is, remove it from skeleton-bodies.xml
You can select the skeleton with the same name, right click, [Remove hitboxes]. Remember you are not actually doing anything to the skeleton. The association is done by name: if you remove the hitbox from a skeleton called "skel_giant", you are just deleting the hitbox called "skel_giant" (e.g. another "skel_giant" sitting in another unrelated BRF file of the same module will now be without hitbox).
When you save hitboxes, OpenBrf tells you all the hitbox sets that are going to be saved.
Small detail: if you want to remove one hitbox set, but have no skeleton named that way, you can create a temporary skeleton with that name just in order to delete it.
What are Hit-boxes?
Hit-boxes in M&B are little balloons around each bone of a moving character used by the game to understand if something hit that part of the body, and, by extension, that character. A character, independently by its apparent size and look, is hit just if an only if the ballon is hit. The rationale is that it is much quicker for the game to check the "balloon" for collisions. It is similar to the Collision Objects (which are for static meshes, however, and can be any shape -- not just baloon).
Another use of hitboxes is in ragdolling, to avoid that, say, an arm pass though the chest when the guy is dead and is falling like a huge bag of potatoes.
Why you want to edit them? Simply put, if you make a new skeleton or customize an old one, you want to make a new hitbox set for it, for a more realistic fighting experience in the game.
Hit-boxes in M&B / WB
The game keeps, for each different skeleton it uses, a hit-box set (composed of at most one hit-box per bone). Some bone, usually smaller ones like "hands", have none (at least in vanilla). Every hitbox is shaped as a "capsule", the geometric shape you get if you cut a sphere in half and cram a cylinder of the same radius in the middle.
Now the ugly catch: Hit-boxes for skeletons, unlike basically all other content of the game (e.g. meshes, animations, materials, collision objects...), are not stored in any BRF file!
Instead, the game keeps them in a separate file, "skeleton_bodies.xml", which holds all hitboxes for all skeletons used in a module, plus a few other metadata also associated to skeletons (used for regdolling). That file is kept in "<your_module>/data" folder, but, if not there, a default copy is used from game "data" folder.
That's a bit of a problem for OpenBRF: hit-boxes are tightly linked to skeletons, they cannot even be visualized without one, and yet, if they are modified, not the BRF file holding the skeleton, but this global .xml file has to be saved. That will cause some confusion, I'm sure. Important: the link between "hitboxes" (in the XML data) and skeletons (anywhere in BRF files) is by name: a hitbox set will be associated with any skeleton with the same name (by the game and OpenBRF alike).
How-to's in OpenBRF
Visualize hitboxes
Just select the corresponding skeleton. You'll see, in the databox, a check-button called "has hit-boxes", in the "data" box, which tells you whether that skeleton has an associated set of hitboxes. If it does, you can visualize the set of hit-boxes by selecting the option inside the "view" box.
Hitboxes can be visualized also when seeing skeletal animations (to see how they behave during an animation). In all cases, they can be visualized overimposed with a rigged "skin" (the skin can be quickly toggled on/off with space: doing so helps perceiving how well the hitbox fits an actual character).
When you change the current module (and at start-up), OpenBRF scans the file "skeleton_bodies.xml" and remembers all the hitboxes found there: it will use them together with skeletons with the same name. OpenBRF reloads that file from disk when you hit F5 ("refresh module") (with many other things).
Remember the association is done by name: for example, if you rename a skeleton, it can lose (or gain) a hitbox set.
Edit hitboxes manually with a text editor
Anything you need to do with hitboxes of your mod, you can do it manually, by opening the file "skeleton_bodies.xml" in a text editor (copy the one from <game>/data folder into your <module>/data folder to start with). The file is a XML so it's should not be too difficult to figure out and edit.
To visualize that what you did made sense, you can keep OpenBRF open: just save the XML file and refresh OpenBRF with F5: the hitboxes will be updated.
This is the "slow but sure" way: you can add, delete, edit any hitbox assocaited to any skeleton. It is just not very intuitive to do. That's the emergency way to do anything (even without OpenBRF). However, OpenBRF offers functionalities so that you can, in most cases, do all you need without ever opening that file.
WYSIWYG editing hit-boxes within OpenBRF
- Select the skeleton with the same name as the hitbox.
- Click on any bone on the list.
- You can now use the controls to thicken, elongate, move, rotate the hitbox for that bone. You can also activate/deactivate that hitbox (not all bones must have one). You can make the hitbox symmetric (e.g. you edit the left leg, and use that to update the right leg so that it matches). And so on: experiment with the controls, they should be easy to understand with very little tries.
- Hint: while you edit, it helps to turn the skin on and off (keyboard shortcut is "space") to see that your hitbox is right.
Edit, forgot to mention: while using these controls, if you keep any modifier pressed (ctrl, shift, alt...) you will just nudge the hitbox a little.
Save a modified hit-box set
Now the tricky part: when you modified a hitbox set in OpenBRF, a "(**)" (note: double *) will appear in the OpenBRF windows title: this tells you that you have unsaved changes in the skeleton metadata. It's of no use to just "save": that saves the BRF file with the skeleton, and hitboxes are not kept there. Instead, you need the command, under "Module" menu, to "Save module Hit-Boxes for all skeletons".
Don't worry: you will be prompted that you must save your changes, and offered to do so, whenever you are about to lose them (e.g. you try to quit OpenBRF, or open another module, etc).
(hint: a quick way to discard your edits, if you need to do so, is to refresh the module with F5 and pick "discard changes" when prompted: that reloads the current "skeleton_bodies.xml")
Remeber you never save just a single hitbox set: you save either all hit-box sets of a module or none.
Caveat: when OpenBRF saves the hitboxes, it saves a "skeleton_bodies.xml" which is looks very different from the one found in native (a backup is done anyway). This is because equivalent XML files can have many different forms (indentation etc). In particular, OpenBRF unfortunately scrables the order of "attributes" inside nodes. The game does not care at all, and works correctly. But subsequent manual edit of that xml file can gets more difficult, I'm afraid.
Add a hit-box set to a new skeleton
When you create a new skeleton (e.g. copy, paste and rename an existing skeleton, or import it), it will have no associated hitbox set. Unfortunately, you cannot just add hitboxes to its bones, one by one, because there is no way OpenBRF would know the rest of the metadata which will have to be saved together with the hitbox.
Instead, you have to transfer an existing hitBox-set from another skeleton.
How to do that:
1) select origin (a skeleton with hitbox), [edit]->[copy hitbox]
2) select destination, [edit]->[paste hitbox].
The two skeletons must share the same number of bones.
More on copying and pasting hitboxes
The above is the "direct" way to copy a hitbox set from a skel to anther.
As an alternative, you can pass through a collision object. The effect is a bit different (see below).
That's how you do that:
1) select origin (a skeleton with hitbox), [edit]->[copy hitbox]
2) [edit]=>[paste] (or ctrl+V), creates a static Collision Object with all the capsules
(maybe edit this Collision Object in whatever way you like)
3) [edit]=>[copy] (or ctrl+C) this collision mesh
4) select destination skeleton, [edit]->[paste hitbox].
In other words, the hitbox set you copied from a skeleton can pasted the normal way (step 2), instead of pasting it "as a hitbox". That creates a (static) Collision Object, made of capsules (plus "empty" placeholders for bones without hitboxes). The capsules are disposed statically according to bones in the original skeleton.
This Collision Object can potentially have its own uses, and can be treated as any other BRF Collision Object (e.g. they can be saved in the BRF, edited by re-scaling them, or by manually editing their many numbers, or be exported-modified-and-reimpored, etc.).
A Collision Object of this fashion can, in turn, be copied and pasted "as a hitbox" over a skeleton (steps 3 and 4).
The two ways to transfer a hitbox from a skeleton to another are a bit different:
- If you direct, the capsules will adapt to the position of the bones in the receiving skeleton.
- If you go though the Static Collision, their position are fixed in space, indendent of the bone positions of the destination skeleton.
I kept both ways because there are cases when either of the two things is useful. Can you see why?
Minor: remove a hitbox from the module
That is, remove it from skeleton-bodies.xml
You can select the skeleton with the same name, right click, [Remove hitboxes]. Remember you are not actually doing anything to the skeleton. The association is done by name: if you remove the hitbox from a skeleton called "skel_giant", you are just deleting the hitbox called "skel_giant" (e.g. another "skel_giant" sitting in another unrelated BRF file of the same module will now be without hitbox).
When you save hitboxes, OpenBrf tells you all the hitbox sets that are going to be saved.
Small detail: if you want to remove one hitbox set, but have no skeleton named that way, you can create a temporary skeleton with that name just in order to delete it.