DeePsea's Decompile Behaviour Dealie

I've been saving my scripts to the behaviour lump, when I save them to my wads, but I realized when I accidentally messed up the .acs while editing the script for my last speedmap, that I no longer HAVE the script, except in the wad. Problem is, I can't get the script out of the behaviour lump, but I need to edit it. I noticed that DeePsea has a decompile behaviour thingy, but it doesn't seem to work. Is there any way I can get my script back, so I can edit it again?

(Oh yeah, I've also decided not to use the behaviour lump anymore. I'll just save it into SCRIPTxx)

Holy Avenger said:

(Oh yeah, I've also decided not to use the behaviour lump anymore. I'll just save it into SCRIPTxx)

Ummm, you will need to save your compiled script as the behavior lump otherwise it will not execute. SCRIPTxx is intended for you to put an uncompiled copy of the script into the WAD purely for record purposes. It is not required or used by the engine.

Your description is a little confusing. Have you been compiling your script with ACC or DeePACC and then saving it into your WAD as the behavior lump, or have you just been putting the uncompiled file into a WAD as the behavior lump?

If the lump is a correctly compiled behavior lump, then you should be able to load your WAD, hit F6 and pick the decomple behavior option. I have used this many times and it gives a clear, well laid out decompiled script that can usually be compiled again without error.

If the lump is actually an uncompiled text file, you should be able to pull it out of the file again and save it as a text. I'm not sure if BEHAVIOR being a specialised lump name, and normally hidden as part of the MAPXX lump name will cause you problems or not.

Ummm, you will need to save your compiled script as the behavior lump otherwise it will not execute. SCRIPTxx is intended for you to put an uncompiled copy of the script into the WAD purely for record purposes. It is not required or used by the engine.

Oh, okay. I'm still fairly new to scripting, so I didn't know that. Thanks for pointing that out.

Your description is a little confusing. Have you been compiling your script with ACC or DeePACC and then saving it into your WAD as the behavior lump, or have you just been putting the uncompiled file into a WAD as the behavior lump?

I used ACC to compile these scripts, and then saved it into the behaviour lump.

If the lump is a correctly compiled behavior lump, then you should be able to load your WAD, hit F6 and pick the decomple behavior option. I have used this many times and it gives a clear, well laid out decompiled script that can usually be compiled again without error.

Well, I guess mine was a failed up compiled behaviour, because the decompile thing always gives me an error message.

Holy Avenger said:

Well, I guess mine was a failed up compiled behaviour, because the decompile thing always gives me an error message.

DeepSea cannot decompile scripts that are compiled with the newer ACC versions. The output is in a completely different format than with older versions.

Well...crap. Is there ANY way I can get my script out of there, or would I have to rewrite it?

Holy Avenger said:

Well...crap. Is there ANY way I can get my script out of there, or would I have to rewrite it?

Do you have the SCRIPTxx lump in your wad as well? If so, can you simply extract it as a text file? I know this works with the SCRIPTS lump if you use Wintex, but I'm not sure about SCRIPTxx lumps in DeePsea.

If not, you could try opening up your wad with WadAuthor and bring up the scripts dialogue (right click anywhere in void space and select 'Scripts..' if you're not familiar with WA). Then copy-and-paste the text into a text file.

DeePsea can also extract the scripts easily, but I never bothered to put the script in SCRIPTxx because I figured I wouldn't need to.

I never bothered to decompile the newer format because Randy keeps mucking with it and because there's not much demand for current levels since users usually supply the script text.

It was originally made for HEXEN for which there were no text format scripts available.

Format is not really completely different - more like shifting stuff around to keep WA happy and an unneeded short format. Any difference will cause a problem.

I think what you really meant was you destroyed the original file that had the script in it?

Yeah, what I mean by "messed up" is that I accidentally saved over it when I was using it as a template for the other script. I don't think it would be too hard to just rewrite the script (it wasn't very long), but I was trying to avoid having to do that.

deep said:

...an unneeded short format.

But that's the default output of the newer ACC's. So I would hardly call it 'unneeded'.

Graf Zahl said:

But that's the default output of the newer ACC's. So I would hardly call it 'unneeded'.

Read more carefully. Your comment has nothing to do with what I said.

It's unneeded in that the space the alternate format saves (and that is it's only purpose) is a useless change from the orginal format in today's world. Even large compiled scripts are not that big - esp compared to graphics or sound resources. So why complicate the code with having to support both formats.

deep said:

Read more carefully. Your comment has nothing to do with what I said.

It's unneeded in that the space the alternate format saves (and that is it's only purpose) is a useless change from the orginal format in today's world. Even large compiled scripts are not that big - esp compared to graphics or sound resources. So why complicate the code with having to support both formats.

I wouldn't call four lines of additional code 'complicating'. (not counting the braces)

		if (fmt == ACS_LittleEnhanced)
		{
			pcd = getbyte(pc);
			if (pcd >= 256-16)
			{
				pcd = (256-16) + ((pcd - (256-16)) << 8) + getbyte(pc);
			}
		}

That's everything that has been added for the short format. BTW, this is what I would have done to start with!

Overall you are right, however. The savings are marginal at best especially considering how ZDoom is wasting a lot of memory in lots of other places!

Now you got the picture. However, there are some other changes too - trust me, since I'm the 1st person to put out an ACC.EXE that was not produced by Raven:)