ZDoom

But I think this statement ignores the point that the GZDoom ACS interpreter is only tested with acc.exe. It's known to work with that, and that's pretty much the extent any developer is willing to invest in it, especially for a scripting code set that has an improperly licensed source release for ...

I feel like a lot of Marrub's issues are caused by his mind-boggling development workflow that involves a lot of compiling from one language to another (not just the C-to-ACS. I think there's something else involving actors?). It's very abnormal for a ZDoom project and I can easily see it causing ...

Quick update to note that A, the libacs headers have been fixed so the new builds are now actually usable; and B, I now have a Discord server for GDCC and other projects of mine. Link is in the first post.

How is it declared in ACS? I think this is on me, though. I wasn't thinking of arrays at all when I answered your previous question. For making an array-stored object that's accessible from ACS, it's a little extra legwork: [[__address(777)]] __addrdef __hub_arr hub_var; [[__address(0)]] hub_var ...

Using the address attribute. Where 7 is of course replaced by the desired index.

You need to compile and link libGDCC. (And probably libc at some point, but that specific function is in libGDCC.)

I have updated the repository. Unfortunately, due to a bug in the version of gcc that mingw-w64 is (currently) based on, I can't make Windows builds at this time. (Since this is just a header update, though, you can just grab those from the repository off GitHub.)

Added. Note that ScriptCall is variadic and therefore passes in arguments as-is. (Important for the C front where you might inadvertently pass floats or multiword types.)

Should be fixed now. Was an issue with how I added support for mixed-in attributes with declaration specifiers. (Namely that it actually ignored attributes that didn't occur at the beginning of the sequence.) And your first alternative would have worked, you just needed to cast to (__str_ent *) or ...

I have thought about how to add a warning for delays or potential delays when targeting ZDoom. The issue is mostly syntactic. Since GDCC has no special knowledge of any of those functions, it relies entirely on the header declaration to know about such properties. And I have not yet decided on a ...

@Nash Added. Also added implicit conversion from line specials to int to the ACS front, so you can pass them to SetLineSpecial as in acc. @bitshifter Sorry about taking so long to get back to you. Been a bad combination of lack of time and needing to find a Mac developer to help diagnose the problem ...

@Nash The ones not marked with BC_DGE, just gdcc_vXXX.

@Nash Do not use the BC_DGE builds. That branch does not keep up with ZDoom updates (except when merging in master for other reasons). @bitshifter Hopefully the latest commit fixes that. I actually had no idea std::vector<bool> did not have emplace_back until C++14. I'd be interested to know what ...

Updated.

I rewrote its interpreter years ago. Internally, it has a lot of capabilities that ZDoom's interpreter does not.