All of that is standard. A void function in c/c++ can have a return with no value, because you need a way to leave the function, but having a value would cause a compile error, since the function has no return type.
Similarly, the part with 1 or 0 could be in a function that returns a numeric, and FALSE could be part of a function that returns a BOOL. Just because they're in the same file means nothing. If the programmer is using numeric 0 and 1 in one place, and TRUE/FALSE macros in another place, that's not the language's fault, it's just the standard range of options that most languages provide.
Where ..() comes in is that it's a call to the parent behaviour. For example, you could have a FireSword, and you call an "Attack" command on it, which does some fire damage, but then passes the call to ..(), which then calls the Attack command of the parent type, Sword, doing slash damage. Then, Sword calls ..() again, which activates the Attack function in its own parent-class Weapon, which then handles any book-keeping that occurs on all Attack actions. And you'd have a similar nest of calls when you attack with an item such as a "Frosthammer". It's actually pretty neat btw, since it's common to do calls like this in e.g. C++ but in C++ there's no special command to infer the parent class and parent method to call, both must be explicitly referenced. ..() is pretty neat actually.
So, when the above code does an action then returns FALSE if a certain condition is met, but returns ..() otherwise, what that's saying is to do the item's special action, and return a BOOL value, but if it can't do the action, then call the generic action of the parent type of that object, and return a value from that (which would be TRUE or FALSE).