GZDoom Builder 2.3

[Siberian Tiger]

Following up with my previous post, I decided to convert from an horrible absolute path to a relative path which will work abroad filesystems instead of it using my Desktop's filesystem scheme. However, it seems I ran into another problem. GZDB is unable to locate the ACS file relatively.



I have also checked the paths using the CUI, as shown below to assure that the paths are legal, which Windows agrees:


I have also tried assuming that the path must be relative to the GZDB itself aswell as the ACC directory, alas none of them worked aswell. In addition, I even put the StandardLibrary.acs in the ACC directory - as a "Fuck it all" resolution, but that failed too...


Broken from Build: r2448
Last working Build: r2447


Steps:

• Open Acerbus (NOTE: optional to compile map dependencies?)
• Edit map script (ZDoom ACS)
• Change line #44 from

  Code: Select all

  D:\Projects\ZDoom WADs\TGRDM3\Scripts\StandardLibrary.acs

  to

  Code: Select all

  ..\..\Scripts\StandardLibrary.acs

• Compile the source via Script Editor
• <!>

---

Project Version Control: https://github.com/SibTiger/TGRDM3
Compiler: Requires Bootless Star, and Morgenstern.bat. Do NOT use Compiler_Map.bat! (I can't be certain of possible issues if you run it without the required initializations and declarations). Contact via PM and I'll walk you through the compiling. However, I don't believe you really need a resource build as the scripts are 'as-is' by design.

[MaxED]

Following up with my previous post, I decided to convert from an horrible absolute path to a relative path which will work abroad filesystems instead of it using my Desktop's filesystem scheme. However, it seems I ran into another problem. GZDB is unable to locate the ACS file relatively.

As I already wrote, in GZDB, SCRIPTS lump is treated as located at the root of any map resource during compilation (and not at the map location). So, in your case, changing include to #include "Scripts\StandardLibrary.acs" fixes the problem.

[blood]

I've a problem, GZDoomBuilder isn't loading any of my actors when I load a map with "GZDoom: Doom 2 UDMF".
The problem isn't from my wad because when I load it with another configuration it works well.

Here is a screen:

---

[MaxED]

Sorry, I cannot debug a screenshot.

[blood]

My bad, the problem was from Decorate, I still wonder why it wasn't happening in other configurations.

[MaxED]

If I use a texture defined in TEXTURES as a patch in another texture it doesn't compose the texture properly.

Implemented.

My bad, the problem was from Decorate, I still wonder why it wasn't happening in other configurations.

I won't be able to help you unless you provide the DECORATE in question and the names of those game configurations.

[Siberian Tiger]

Following up with my previous post, I decided to convert from an horrible absolute path to a relative path which will work abroad filesystems instead of it using my Desktop's filesystem scheme. However, it seems I ran into another problem. GZDB is unable to locate the ACS file relatively.

As I already wrote, in GZDB, SCRIPTS lump is treated as located at the root of any map resource during compilation (and not at the map location). So, in your case, changing include to #include "Scripts\StandardLibrary.acs" fixes the problem.

I honestly don't know what to do here:

[MaxED]

And you expect the editor to find the include in "TGRDM3\Scripts"... how? Including "TGRDM3" folder as a single resource worked fine on my side.

[Siberian Tiger]

Including "TGRDM3" folder as a single resource worked fine on my side.

Ah! I get it now, thanks! So GZDB now checks the files instead of going through the compiler?

[MaxED]

It has to check the files to get all includes.
When compiling the SCRIPTS lump, the editor saves the text from the lump into a temporary file somewhere in the %TEMP% folder, copies all includes it found preserving directory structure, runs acc.exe on it and copies the compilation result into BEHAVIOUR lump.

[MaxED]

is it possible to replace the missing texture graphic?

Now it is. Externalized most of the editor's built-in textures. You can find (and replace) them in the "[GZDB]\Textures" folder.

[jmickle]

Excellent, thank you.

[Doom Juan]

Is it possible to implement a means of keeping track of polyobject numbers? Currently I have to write down used polyobject numbers, but perhaps something similar to the "new tag" feature?

[Dragonfly]

Is it possible to implement a means of keeping track of polyobject numbers? Currently I have to write down used polyobject numbers, but perhaps something similar to the "new tag" feature?

I too would like this feature.

[Cynda]

I can't open my maps anymore since GZDoom_Builder-r2461 SVN. It immediately results in an app crash after loading my custom map.
Still can open my maps on GZDoom_Builder-r2460 SVN thankfully. D:

Is there a possibility that my custom items breaks the recent SVN app since it can load DOOM2.WAD levels perfectly fine? o.o

I'll probably stick to R2460 SVN for now since it still works with my map without any app crashes.