[ZDaemon Help] ACS line doesn't work in ZDaemon

[Arsinikk]

So this script works in GZDoom, old ZDoom, and Zandronum, but I can't seem to get it to work in ZDaemon.

 

The line in question is the "SetFloorTrigger" line. Basically if the sector tagged 5 moves down at all (-1), the sector tagged 17 open like a door (Door_Open) with a speed of 16.

It's worth noting that the MAP27 code "ReplaceTextures" does in fact work in ZDaemon.

 

Not sure if I'm doing something wrong, since there doesn't seem to be alot of documentation on what ACS code ZDaemon supports / doesn't support.

#library "lvlname"
#include "zcommon.acs"

...unrelated code stripped out...

Script "ZDoom_Mikoportal_fix" OPEN {
	int mapLump = GetLevelInfo(LEVELINFO_LEVELNUM);
	if (mapLump == 27)
	{
	  ReplaceTextures("ROCK10D","WFALL1");
	}
	if (mapLump == 35)
	{
	  SetFloorTrigger(5,-1,Door_Open,17,16);
	}
	else
	{
	}
}

 

[Worst]

This is working for me in ZDaemon. Example (MAP35): setfloortrigger_test.zip

My guess as to why it isn't working for you, would be that perhaps GetLevelInfo() is not returning the correct level number on MAP35. This could happen if you are either missing the MAPINFO lump or there is something in the MAPINFO that is causing ZDaemon to not parse it properly.
 

[Arsinikk]

15 minutes ago, Worst said:

This is working for me in ZDaemon. Example (MAP35): setfloortrigger_test.zip

 My guess as to why it isn't working for you, would be that perhaps GetLevelInfo() is not returning the correct level number on MAP35. This could happen if you are either missing the MAPINFO lump or there is something in the MAPINFO that is causing ZDaemon to not parse it properly.

I'll admit that your example works perfectly fine, however in my map it does not for some reason.

 

I might as well post my wad so that you can actually look at what I have. First off, I am actually using the original Doom 2 map format, and loading ACS after the fact so that the WAD can be complevel 2 compatible.

 

The GetLevelInfo() is working correctly because I have another script that shows the map name at the start of each map and that worked correctly. The map in question was MAP35b, but the ACS was still applied to MAP35b the same as MAP35. However, I've renamed MAP35b to MAP36, and changed the scripts to apply only to MAP36 just for clarity sake. But even so, the script does not work on that specific map for some reason.

 

I'll attach what I have so you can take a look and maybe see what's going wrong:
200lnm-map36-no-work.zip

[AF-Domains.net]

While taking a quick glance at your wad, it looks like you're missing the legacy MAPINFO lump that ZDaemon would require in this case.

 

If including a legacy MAPINFO lump within your existing wad would result in a conflict, a separate standalone wad could be created that only contains that for ports that don't support the later MAPINFO lump types.

[Worst]

11 minutes ago, Arsinikk said:

The GetLevelInfo() is working correctly because I have another script that shows the map name at the start of each map and that worked correctly.

It does not seem to be actually working correctly for any maps past MAP32, they all end up showing the same map name as MAP01. I also tested adding a little print message to your script, and confirmed that it's not returning the correct level numbers for maps after MAP32.

This is because there is no legacy "MAPINFO" lump in your wad, as @AF-Domains.net pointed out. You can check here for the old MAPINFO syntax: https://zdoom.org/wiki/MAPINFO_(old_format)

[Arsinikk]

5 minutes ago, AF-Domains.net said:

While taking a quick glance at your wad, it looks like you're missing the legacy MAPINFO lump that ZDaemon would require in this case.

 

1 minute ago, Worst said:

This is because there is no legacy "MAPINFO" lump in your wad, as @AF-Domains.net pointed out. You can check here for the old MAPINFO syntax: https://zdoom.org/wiki/MAPINFO_(old_format)

 

Ah I was under the impression that ZDaemon used "ZMAPINFO" being a ZDoom based port, but I guess not. I guess that would make alot of sense then, since it worked with all the other ZDoom-based ports because they supported "ZMAPINFO".

 

I'll go ahead and make a legacy "MAPINFO" lump then. This is good to know for the future. Thanks for helping me troubleshoot this. It seems like it was a stupid cause, but honestly I was pulling my hair out a bit here :)

[Redneckerz]

@Arsinikk ZDaemon's ACS is pretty well documented, see here and Rhinoduck's ACS work.

 

Additionally, ZDaemon introduces several new lumps, found here.

[Arsinikk]

9 minutes ago, Redneckerz said:

@Arsinikk ZDaemon's ACS is pretty well documented, see here and Rhinoduck's ACS work.

Honestly I found this early on and it wasn't too useful for me since most of the links on the ZDaemon page are ACS that is exclusive to ZDaemon. I was looking for ACS code that could be read by both ZDaemon and modern ZDoom-based ports, for fullest compatibility.

 

I would say the most useful link there was an ACS config, because I could search and find to see if it included specific ACS commands like SetFloorTrigger.

 

Far more useful was this Rhinoduck wiki I found that actual said if certain ACS functions were compatible or not with ZDaemon.

 

However this wasn't even the problem I was having. It was that the ACS script couldn't find MAP35 because ZDaemon only maps out maps up to MAP32 by default.

I didn't realise that ZDaemon requires a MAPINFO lump for that, and that it is the only ZDoom-based port that didn't support ZMAPINFO.

 

Creating a readable MAPINFO lump was honestly a large timesync, since there's no official place that says explicitly what MAPINFO functions that ZDaemon supports.

The legacy MAPINFO lump page is somewhat useful, but it contains a bunch of functions that makes the ZDaemon MAPINFO parser just die.

 

It's extremely annoying that unlike modern ports that just skip lines in (X)MAPINFO lumps that it can't read, ZDaemon just gives up on something it doesn't support and doesn't even tell you.

 

Honestly the most useful page to figure out what makes ZDaemon MAPINFO parser die was this decade old forum post.

 

19 minutes ago, Redneckerz said:

Additionally, ZDaemon introduces several new lumps, found here.

I refuse to touch ZDaemon's only DEHSUPP lump with a 12 foot pole.

I don't wanna have to rewrite 2000+ lines of DEHACKED into that just to get it to work.

 

Honestly there's a MBF21 project I'm working on, and I have no idea how I'd get it to work in ZDaemon, since I really don't wanna work with DEHSUPP, since it's so manual.

[Redneckerz]

6 hours ago, Arsinikk said:

Honestly I found this early on and it wasn't too useful for me since most of the links on the ZDaemon page are ACS that is exclusive to ZDaemon. I was looking for ACS code that could be read by both ZDaemon and modern ZDoom-based ports, for fullest compatibility.

That would be ACS compatible with ZDoom 1.22, as that's what ZDaemon's derived off.

 

Due to their limited nature, they have embraced DEHSUPP (Which was only a temporary offset in ZDoom 2.0.630 for additional pointers.

 

I am glad to see you got most of the results going i was going to give. ZDaemon's ACS and the things people do with it is incredibly impressive considering its limitations.

Quote

It's extremely annoying that unlike modern ports that just skip lines in (X)MAPINFO lumps that it can't read, ZDaemon just gives up on something it doesn't support and doesn't even tell you.

It would indeed be nice mapping behavior that atleast an error is thrown when this is done. @AF-Domains.net this might be worthwhile.

Quote

I refuse to touch ZDaemon's only DEHSUPP lump with a 12 foot pole.

I don't wanna have to rewrite 2000+ lines of DEHACKED into that just to get it to work.

I am actually quite surprised a DEHSUPP to DeHacked... converter??? doesn't exist. But it makes sense, as DEHSUPP is a supplement to DeHacked. There are DECORATE to DEHSUPP converters, but not for DeHacked. After all DEHSUPP is just a table of definitions, nothing more.

 

I reckon that's why some bigtime WADS have a ZDaemon conversion - DECORATE/DEHACKED converted to DEHSUPP. But maybe ZDaemon extraordinaire @Worst might be able to give some pointers (heh) how to deal with massive DeHacked patch conversions beyond ''Lul git gud at converting bruh''? :P

Quote

Honestly there's a MBF21 project I'm working on, and I have no idea how I'd get it to work in ZDaemon, since I really don't wanna work with DEHSUPP, since it's so manual.

I am afraid that when itcomes to that, DEHSUPP is your only salvation. I could point to some code that defines DEHSUPP so that, in a worst case scenario, you could write a converter or script for it... but ZDaemon's DEHSUPP (and ZDaemon in general) took a non-standard path to achieve similar goals.

 

In plain terms: Their implementation allows a lot of what cross-port standards can do (similar to how GLOOME has some specials unsupported by GZ or any other port) but it is pretty specific for the port itself. Which is why there is a true but tested userbase that does these conversions and also does a lot more with ACS than what other mappers do in other ports. Its a bit old-fashioned, but hey, it works.

 

Though: Any new DEHSUPP tool that makes it easier porting code over to and from ZDaemon would be a plus.

 

EDIT: There used to be a Rhinoduck tool called ZMI2MI to generate MAPINFO's, but the GIT tree is gone and also not archived. Perhaps Worst can tell you where this is. Or in fact, ask @damo since they used this a lot for their conversions (like Eviternity).

 

EDIT 2: I found the link to ZMI2MI. Now you can generate MAPINFO's easier.

• Here is also Rhinoduck's GIT-TEA.

 

EDIT 3: PreDEH may also be useful for you to look at.

Edited December 5, 2022 by Redneckerz : Adding about ZMI2MI

[AF-Domains.net]

Regarding the MAPINFO parsing, there is definitely room for improvement in order for more information to be provided.

 

As for DEHSUPP, that's a whole other beast that's best addressed elsewhere. If however you "haven't" utilised your own base DEHSUPP lump in your wad, that can actually make things considerably easier if one of the supps from the official site were ever used (they're designed to be compiled and more or less a drop-in replacement if your dehacked is based off of what you would have otherwise got from Doom2.exe - the base DEHSUPP that's otherwise present in the zdaemon.wad); complications will arise if you've used any types, states and/or sprites that ZDaemon doesn't know about since ultimately you'd need to use a substitute (such as a Heretic and/or Hexen entry - depending on which supp you choose - since internally the limitation restricting them to their respective game has long since been removed). As mentioned though, it's likely best for this aspect to be addressed elsewhere if you ever want to take a leap down this particular rabbit hole.