Slade: Position of ACS compiled behaviour lump

[smeghammer]

Can't seem to find the answer to this one... This describes what a behaviour lump is, but not where it should specifically be located.

 

If I add an ACS script and compile via Slade 'Archive/new entry...' menu, I end up with a SCRIPTS and behaviour lump at the end:

 

 

This plays OK, but the script is not recognised until I move it up. I did it 1 position at a time and seemed to be recognised once it was above the (default?) 'Unknown' behaviour lump:

 

 

I them tried moving the 'Unknown' behaviour lump down below instead, but that caused an error in starting the WAD.

 

My question therefore is, WHERE should the compiled behaviour lump specifically go? 

[Gez]

The BEHAVIOR lump should be just after the BLOCKMAP lump. It's the one from which scripts are run.

 

The 24-byte BEHAVIOR lump is a stub lump that does not contain any scripts and only serves to mark a map as being in Hexen format. Your compiled lump with actual scripts in it should replace it. You should also put your SCRIPTS lump right after that -- BLOCKMAP, BEHAVIOR, SCRIPTS. Then you can hit the compile button in SLADE (note the little blue and green arrow icons in the entry content panel from your first screenshot) and it will compile it and place the compiled bytecode in the proper BEHAVIOR lump automatically; at least if it is properly configured to know where ACC is.

[smeghammer]

Thanks, @Gez. It was the position that was key - compiling in Slade is no problem and updating the script and recompiling is also no problem once I manually moved the behaviour lump to a position that worked....

 

It was just the rationale behind where the compiled behaviour lump needs to be that I was curious about - I've muddled through til now... 

 

Interestingly, both Slade and Eureka will compile the script fine (slade with ACC configured, Eureka with a built-in one(?)), but neither seem to properly place the behaviour lump.

 

Anyhow, thanks for the info.

[Gez]

SLADE I think place it in the BEHAVIOR lump that is just before the SCRIPTS lump; so if you place things like I told you, you shouldn't have problems. The confusion here is caused by the presence of the GL node lumps I think.

[smeghammer]

52 minutes ago, Gez said:

SLADE I think place it in the BEHAVIOR lump that is just before the SCRIPTS lump;

 

It does indeed do that, but if you create a new SCRIPTS lump, it will be appended to the end as per my first screenshot - therefore, on compiling, the new BEHAVIOR lump ends up just before the SCRIPTS lump. But because the SCRIPTS lump is incorrectly placed by Slade, the BEHAVIOR lump is also misplaced.

 

Anyway, I know why it is failing now, so I will move the SCRIPTS lump prior to first compilation. Thanks again.

 

[Gez]

41 minutes ago, smeghammer said:

but if you create a new SCRIPTS lump

Why would you do that instead of reusing the same SCRIPTS lump? If you put half the scripts and SCRIPTS lump #1 and the other half in SCRIPTS lump #2, you'll never get to have all your scripts compiled together.

[smeghammer]

No you misunderstood - I meant the very first (and only) script lump. When I create this SCRIPTS lump in Slade (via archive/new/new entry menu option), it is tacked on the end as I show above. I then edit the code in this single lump and compile. As i said, if I do not move the SCRIPTS lump, the compiled behaviour lump ends up at the end, just above the SCRIPTS source lump.

I get similar behaviour in Eureka - I can create a 'map script' from the Tools/Edit Text Lump menu option. A new SCRIPTS lump is created, assuming one does not already exist (this time in he middle of the lumps list if I look in Slade). In this case, Eureka seems to auto-compile to a BEHAVIOUR lump, but again, this is appended to the end of the lump list.  If I move the behaviour lump it will then run.

 

What I am seeing appears to be a logical bug in both Slade and Eureka in that on creating the SCRIPTS lump (only one of them) the subsequent first-time compiled BEHAVIOUR lump is incorrectly placed. 

 

Once I have moved the BEHAVIOR lump to the correct place, I can certainly amend and add code to the single SCRIPTS source and re-compile and the now correctly placed BEHAVIOR lump will update and play with no issues.

 

Note, I am using Slade and Eureka on Ubuntu 18.

Edited July 10, 2020 by smeghammer

[smeghammer]

Right - I know what is going on.

 

I just fired up UDB on Windows and created a new map in zdoom/hexen format. I then immediately looked at this new WAD in Slade. Sure enough an empty SCRIPTS and BEHAVOUR lump were already there, and already in the correct place.

 

Then, in Slade (on Windows still) I added to this existing, empty, SCRIPTS lump a simple ENTER script code with a log, and following compilation, the existing BEHAVIOR lump was updated and the script executed without me needing to move the BEHAVIOUR lump.

 

Note that when I create a new ZDoom/hexen format map in Eureka, these placeholder lumps are NOT present, so I need to manually create the SCRIPTS lump via the edit/map scripts command. I was not correct above, I still need to compile the script in Slade, but Eureka does create the SCRIPTS lump in the correct place when you use the edit/map scripts option, so therefore the behaviour lump is also created in the same place following compiling in Slade.

 

So therefore, it looks like a feature of Slade3 that the lump must be manually moved if you create the SCRIPTS lump in this tool.

 

** EDIT **

So I think I was being caught out under these conditions:

 

1: Created a map in Eureka 

2: Decided I wanted a scripted thing

3: Opened the map in Slade

4: Created a new SCRIPTS lump

5: Compiled

 

Did not execute the script on playing the map.

 

Whereas:

 

1: Created a map in Eureka 

2: Decided I wanted a scripted thing

3: Added SCRIPTS via Tools/Edit text lump/map scripts

4: Opened the map script lump in Slade

5: Compiled

 

Did execute the script on playing the map.

 

Edited July 10, 2020 by smeghammer

[andrewj]

Some info (possibly repeating what Gez said) :

 

1. SCRIPTS is not really a "standard" map lump, it does not exist in the IWADs for example.  But some tools let you store some ACS scripts there and can compile it, so editors generally support it being there like a map lump.

 

2. the BEHAVIOR lump is either an empty stub, or it is compiled from an ACS script.  That script is not necessarily the SCRIPTS lump in a map, it could be just some files on your harddrive, and then the output of compiling the scripts is inserted into the map.

 

3. the BEHAVIOR lump is the main (only) way that source ports and editors know whether a map is Hexen format or original Doom format (ignoring UDMF for now).  If your map does not have it yet, then it must be in Doom format and you need to convert it to Hexen format if you want ACS scripting to work.  Adding it yourself is going to lead to a broken map!

 

4. Eureka does not have any ACS compiler built in (the sources are not GPL compatible, so I couldn't do that), and does not run an external ACS compiler.

Edited July 11, 2020 by andrewj

[smeghammer]

@andrewj, thanks for the additional info, that helps.

 

I think the problem stems from using Eureka and Slade together and doing stuff in a certain order - which I haven't been able to figure out yet. The initial map was certainly created in Hexen format and had functioning scripts in it.

 

Under certain circumstances (which I tried to describe), a map I started in Eureka in Hexen format reverted to Doom format after doing something in Slade - thus losing the SCRIPTS and BEHAVIOUR lumps. Therefore, to repair the map, I manually recreated the SCRIPTS lump in Slade and - as I noted - it creates it at the end. I had a backup of the ACS source I was looking at, so I copy/pasted back into the SCRIPTS lump I re-created.

 

I think the key point you made here is the first one - that it is a non-standard lump, so that probably explains why Slade does not put it in the 'proper' place.

 

In any event, if this does happen again, I will use the editor to convert back to Hexen format before I edit the script. rather than try to do it manually.

 

(If I figure out steps to reproduce this, I will update this thread -  it could be that I just inadvertently hit a key combo, but I don't think so.)

 

[Jon]

There are other differences between hexen and doom format, though: LINEDEFS and THINGS are a different format (longer for hexen).  If your map was converted  to doom format then those lumps will be shorter, lacking e.g. thing ID fields 

[Gez]

2 hours ago, smeghammer said:

a map I started in Eureka in Hexen format reverted to Doom format

 

2 hours ago, smeghammer said:

convert back to Hexen format

 

The map format isn't changed; it's just misidentified. Take a Hexen format map, delete the BEHAVIOR lump, it's still in Hexen format but now the port will think it's Doom format and that will completely mess up everything.