openbor Tools

* 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.

Restored 'set' control for loadingbg for level. I investigated 3 Mods (GoldenAxeRemake, FinalFight, and NightSlasherX). While GoldenAxeRemake and FinalFight are missing the 'set' control.... NightSlashersX is not. Knowing BonusJZ and have worked with him I believe this is the correct usage of the feature. Meaning... 'loadingbg {path} {set} {bx} {by} {bsize} {tx} {ty} {tf}' is the proper usage of the command and now reflects the manual.

loadingbg[0] is for loading Models, loadingbg[1] is for loading Levels. Fixed Loading levels.

level_order() uses the first argument to set the loadingbg type. However, in load_level() the first argument is the image location for the background. This implies that if defined we are to use background + bar. This keeps us backward compatible with all existing mods. Strange that I never had the modder specify this before, Hence, this was a bug. All mods ie Contra, Final Fight, GoldenAxeRemake and more now display a background when loading a level.