Problem importing ACS into GZDB

[Nevander]

I want to set up a library so that I can import it into my map scripts every time instead of duplicating the code on every map's BEHAVIOR lump. I have the library set up named "D64FADES" and compiled and placed in A_START/END. In the map at the top I do the import line for "d64fades.acs" and it keeps telling me "Unable to find include file d64fades.acs" even though the source of the library is right there with it.

EDIT: How do you tell GZDB to import the source acs from a resource WAD?

[ramon.dexter]

Well, I can tell you how do I do it in pk3. I have never used external ACS code in wad, so I cannot help you with wad.

Also, the error clearly tells you what is the problem. "Unable to find include file d64fades.acs" - ´take a look at the extension of the compiled file...it's ".o". So the error is completely right. When you want to import, you need to put the uncompiled file also into the wad.

In pk3, you have to create a folder /acs and put the file with .o extension into it. The filename should be up to 8 characters long (SHOULD BE. I have encountered mods/TCs with really long script names and it works ok), and this filename should be put into the LOADACS lump without the .o extension.

But you said you want to import the scripts from an exeternal library. That's little bit different.
The file should not be compiled (so simple txt is ok), and you need to specify the path to it. So in my project, I have a pk3 with a folder /ACS in it. When I want to import a script from here, I just need to put a

Code: Select all

#import "acs/MYCODE.acs"

into the maps scripts and it is ok.

[Nevander]

Just a follow up for this...

I ended up doing something kinda hacky but it's working. Made a PK3 with only an ACS folder and my .acs source file. I added that PK3 as a resource and then did #import "ACS\D64FADES.ACS" at the top of one of my maps. It worked, it found it and is using the library. Inside my main WAD file (which apparently lacks support for finding ACS sources) I placed the compiled library into A_START/A_END so that the BEHAVIOR lumps can find the compiled library to use in-game.

Now I know you may be saying just use PK3 bro, well I have reasons for sticking with WAD. Because reasons.

[ramon.dexter]

Well, year ago, before I learned how to properly work with pk3, I also had "reasons" and considered .wad to be better option. Well, I was wrong.

Also, can you tell me about your reasons? Because, using pk3 alongside a wad is completely functional.

I develop maps in this order: gzdb used for map creating, so maps are in wad. The rest (sprites, decorate, acs, compiled acs, textures, etc.) are in pk3, because reasons - basically because it allows me better management of the resources.

And your hacky way...well, I can say that could and will cause problems.

[Nevander]

What problems? The PK3 is only being used for GZDB's sake so it can find the damn ACS source to import. Other than that, the library is referenced any other way using A_ markers. So far it's working and I don't see where a problem could be. I even excluded the PK3 from testing and forced it to find and use the compiled version in my WAD and it works.

And my reasons, well I just prefer WAD because everything is in one place. I hate clicking around folders and I also don't know how it all works since I see stuff being randomly placed in PK3s and it just works and I don't understand how. I like WAD because I know how WAD works 100%.

[Blue Shadow]

I also don't know how it all works since I see stuff being randomly placed in PK3s and it just works and I don't understand how.

One of the articles on the front page of the wiki: https://zdoom.org/wiki/Using_ZIPs_as_WAD_replacement