[SOLVED] BEHAVIOR lump... how to make?

OK this probably seems like a totally nooby question but I just started with ACS scripting and I've been having problems finding solid information. I see a lot of things saying to compile your acs script and import it into the BEHAVIOR lump. Well, great... how do you do that? I have the .o file from acc... how do I make use of it? and please don't say "just use doombuilder's behavior editor" :)

Oh and is it just me, or is this entire site going a bit slow lately?

If you use DB1 or DB2, they will automatically call ACC to compile your SCRIPTS lump and create the BEHAVIOR lump. You can also do that through SLumpEd (right-click on a SCRIPTS lump and you should see the "Compile with ACC" option in the contextual menu) if you have set the path to ACC.exe in its configuration options.

If you insist on doing that manually, you'll need to read this: http://zdoom.org/wiki/ACC

I did read that... the zdoom site has been extremely useful while developing my TC... but that page only describes how to compile the script, which I already knew... what I need to know is how to create the BEHAVIOR lump itself. I'll try SLumpEd (though it bitches about a missing dependency, looks like the VC7 runtime... ugh, static build already...).

What do you mean, "create the lump"? Compiling is what creates the lump!

It creates an object file (filename.o) with the same name as the script file. I changed the filename to behavior.o and added it to the build script, but deutex complained that it wasn't a wad or image file.

DEUTEX? Build script?

I haven't used DEUTEX for years, but it should know about BEHAVIOR lumps since it supports Hexen. However, I have no idea how you're building your level. The BEHAVIOR lump needs to be one of the map lumps. If you're just telling DEUTEX to put it somewhere it will not work.

I do find it odd that whatever level editor you're using does not handle this anyway. It's as essential as nodebuilding, and without that lump's presence the map can be confused with the Doom format, which uses different sizes for the THINGS and LINEDEFS lumps, and provoke major glitches for this reason if a confusion happens.

Hrm ok... so say I create the script in my E1M1 (using DB1)... when the wad is fully built, then a map like, say, E1M6 should be able to use the functions too, correct? Is this why DB1 has an option for "map number" when calling a script? This kind of stuff seems very unclear.

EDIT: ok... I use DB1 to build each map individually. I then have a build script for deutex which assembles the final pwad.... it combines all my sprites, flats, patches, maps, etc. into a single wad file. Very normal stuff.

So, you have a wad file which contains the map, and which DEUTEX will merge with the rest. The BEHAVIOR lump should be in that wad file that gets merged -- not anywhere else.


The BEHAVIOR lumps are map-dependent. If you have something on E1M1 which tells the game to run script 28 on E1M6, it will be E1M6's script 28 that will be run; not E1M1. Further, it will wait until E1M6 is loaded to be run.*

Each map with ACS will have its own BEHAVIOR lump.


* ZDoom actually allows you to have global ACS that is shared by all maps. Those are called libraries and they have to be compiled and included in a slightly different way.

OK so I tried editing the BEHAVIOR for each map independently... for now, I'm simply using LocalSetMusic. E1M1 has script 1 and script 2, and E1M6 has script 3 and script 4. However, I get this when I run Vavoom:

---------------------------
Error
---------------------------
Segmentation Violation

Stack trace: VAudio::PlaySong <- VAudio::CmdMusic <- COMMAND Music <- VCommand::ExecuteString <- VCmdBuf::Exec <- Host_Frame
---------------------------
OK   
---------------------------

Here's the code for the E1M1 BEHAVIOR:

#include "vcommon.acs"

script 1(void)
{
  LocalSetMusic("BOSS1");
}

script 2(void)
{
  LocalSetMusic("LEVEL01");
}

script 1 is activated by a linedef, and script 2 is activated by a Thing (a monster in this case). The script for E1M6 is the same, except it's script 3 and script 4, and the name of the music in script 4 is different. Vavoom crashes on load... doesn't even make it to the title screen.

Looks like that error has something to do with my system rather than the scripting... turning off the music in vlaunch prevents the crash, but since I don't hear any music, I'll need to use another method of determining if the scripts are working or not... some simple text messages will do the trick. Everything will probably work fine after a reboot.

I'm seeing now just how powerful ACS is going to be for this project, and that's a good thing because this game I'm working on has some requirements that simply cannot be done in vanilla style.

EDIT: By using the Print function, i was able to determine that the scripts are in fact working as intended. Well then, all good to go... everything's fine now. Thanks for your help, Gez. :)

If Vavoom crashes, you can try testing in GZDoom. Their ACS should be compatible, and unless you dabble in VavoomC your mod should be compatible with GZDoom. (If you don't use dynamic light effects or 3D floors, it should also be compatible with just plain ZDoom.)

It was a driver issue... on this system, the sound driver occasionally dies, and that's what happened. After rebooting, everything worked fine. Now that I understand how the scripting works, I can take full advantage of it. 26 years as a programmer is gonna pay off. :)

I'm taking advantage of some Vavoom-specific features, so I'm not sure if my TC will run on other ports. All I really have left to tackle is weapons... all my efforts to create new weapons in DECORATE have thus far failed, but I'll keep trying to get them working. All of the weapons in my TC are projectile-based... no melee weapons and no guns. Creating monsters has been totally easy though, and I have two done already with a third halfway done (it requires ACS to complete, ironically enough).

I'll probably be posting additional questions on this forum because there are a lot of non-vanilla details my TC requires... I hope people don't get sick of me. :)