[WIP/NSFW] Diablo Monsters v22

[RV-007]

v22: Ally_Rogue_Archer_Kit Test
-Ally_Rogue_Archer completed w/ summon/spawn item completed (yes images are included, + images 4 the goatman [devastating fellow that).
-Ally_Rogue_Archer has its own Poison_Arrow2.
-Explosion_Arrow has bright keyword in its Death/XDeath/Crash state.
-Dialogue stacked to all maps of iwad default maplist.
-Might check on all other supposedly brightened actors as 2 c if they need brightening.
-Then I'll make the other friendly monster (barbarian).

Hopefully, w/ your ally rogue archer fire team, u r able 2 find possible cover 4 a map breach. + that there be kits coming down 2 try cover your ambush/patrol/etc across the map vectors. There b more where that came from, both good and bad.

[RV-007]

I was messing around with ally items when I realized that I bumped into an ACS lump problem. Apparently, ACS lumps don't muddle together like DECORATE lumps. BEHAVIOR lumps are specialized ACS lumps for maps. I am only concerned with ACS lumps by their own (like DECORATE in a way). On LOADACS, I was trying to find out what is #library for when I have to read the fine lines of Libraries, "First off you need your library file. It can be named anything, though giving it the file extension .acs is probably best to avoid confusion." The # things are called Directive constants. This becomes very vital as these directives will prove not only they can call on methods/scripts, but inherit/librarize an ACS hierarchy with a main declaration to index/list/wrap up in a summary of ACS lumps with their own scripts (preferably named scripts {and DIALOG## lumps} for the ill mention of unique action [preventing as much redundant script name conflicts as possible]).

In conclusion, I am fixing up collision code of my ACS lumps (and other lumps that perused the old numeric identity [this will take a while! {I guess ZDoom will be a ultimate basic/minimum requirement for file execution (I will hate to lose out compatibility of old source ports, but I don't want to limit my options in modification)}]). Of course, before all of that, I have to write this important educative step first (which takes time of its own accord). Once everything is done, there be unique and compatible ACS (named) scripts working together (in its own makeshift category organization system!) w/o conflict, DIALOG## lumps need an update in order to keep things modifiable (check version [v2.6.0+!] on named script for both ACS and DIALOG##).

---

*#include <filename>
-n/a, but you usually go with "zcommon.acs" (according to this link, ACS/library lumps need this line in order to get it running.

*#library
-librarize/call/access the ACS/library lumps (actually, I think this is the sole solution to my fucked up "while (ThingCountName ("classname",0) > 0)" conjuration [it being the only one horrible enough to cause ACS fatal error for some reason {manual application of all ACS lumps working with any ACS with "while (ThingCountName ("classname",0) > 0)"}]).
-actually, I found out that a matter of time signature is followed (refer to wws_ally_thug_items project).

*#import <library name>
-perused/called scripts, functions (I think I may want to replace scripts with functions later on), and constants to be used by another ACS/BEHAVIOR lump.

*#define <constant name> <value>
-a private constant (whose value stays the same) variable to be used by the said library/ACS.

*#libdefine <constant name> <value>
-a public-like (not sure if it can be all that publicly accessible) constant variable to be used by any library/ACS that choses to #import that said variable.

*#nocompact
-looks like a setting for no compression in byte-code. Don't know why though.

*#wadauthor
-suppresses log of ACS errors in the WADAuthor error report. Why would anyone do that, I don't know.

*#nowadauthor
-an no option for initializing WadAuthor's detect error in compiled library/ACS.