openbor Tools

Bah, one more time. It’s pretty clear I am out of practice with source vaulting.

Previous attempt to restore 3.281 constant list did not take.

My testing for 3.282 was under flawed conditions. Restored constant list for candamage and hostile, with slight modification to accommodate projectilehit. I’m not ashamed to admit when I’m wrong. :) I still contend however that passing the constant directly would be a more tenable solution, but it’s a little late for that due to backward compatibility.

* Bug Fixes:
o Hostile and Candamage script properties had defined constant list, but the actual property change code was written specifically to accept integer values and return an error if a string pass was attempted. However, when a constant was passed as intended it was still overwritten by the static list, resulting in an incorrect value (i.e. PLAYER was overwritten with ENEMY). I removed the list and we now pass the constant directly. This is one case where we don’t need a list. It is impossible to obtain types as anything but an integer constant anyway, so even if the string list had worked as intended it would just be adding an unnecessary step for scripters.
* Script property additions:
o porojectilehit({ent}, “projectilehit”, {type1}, {type2},…)

fixed unnecessary shutdown on wrong animation index, as seen in skull kingz. it works great with a simple return.

Exists property is now 2 when entity is a level spawn. This allows a modder to confirm an entity is or is not a level spawn without resorting to unreliable metadata or additional variables. Depending on need and feasibility I may look into adding other spawn condition indicators as well (i.e. 1 = script spawn, 2 = level spawn, 3 = item drop, and so on). Note the various Exists evaluations already in place are all true/false, so there are no backward compatibility problems. Just take note of this change should you wish to make a specific numeric evaluation of the Exists property moving forward.

Argh! Got version mixed up with log.

Forgot version change.

Disabled redefine warning. As it is, each and every #include of any #define list is being evaluated as a redefine of every single macro in said list. That’s a bit ridiculous, considering an #include is the only way to actually use a #define source file within an OpenBOR script function. End result is a TON of log spam and increased load time. Please test carefully before re-enabling this or any other warning functionality.

Re-Implemented original BOR v1.0029 'Loading...' status when no loadingbg is used. This way we don't just get a black screen.