Can you mix ACS scripts with DECORATE?

[D2Jk]

Hello,

This is for ZDoom.

I added some recoil to weapons using A_SetPitch(), and then thought that this would be a good chance to try learning ACS scripting, to achieve the same thing with scripts.

This borrowed and then simplified code is in a lump called RECOILS, placed between A_START and A_END markers (I assume that's how it's should be):

#include "zcommon.acs"

Script "Recoil" (void)
 {
  int PlayerPitch
  PlayerPitch = GetActorPitch(0);
  SetActorPitch(0 , PlayerPitch+8);
  Delay(1);
 }

Then I have a

TNT1 A 0 ACS_NamedExecute("Recoil")

placed in the weapon firing state, but the player pitch isn't modified when the weapon is fired.

Questions:
1) Am I trying to use scripting in a wrong way? (at least modifying player properties dynamically seemed to work for this guy).
2) I've read something about compiling. Is compiling required, and if so, why wouldn't it work as plain text like it does in DECORATE?
3) Do you have to "#include" the script lump in some way, like the additional DECORATE lumps? Obviously, trying to #include the script lump as a DECORATE lump will create error messages, because of the major differences between the two.

Sorry if I sound dumb. I've searched around and followed the Quick Beginner's Guide to ACS in the wiki, and while it does explain how to write scripts, it doesn't seem to mention where to put them in a WAD, or whether it's necessary to compile the scripts or not.

Any thoughts are appreciated.

[Gez]

To answer the title: yes, absolutely.

More specifically:

D2Jk said:

This borrowed and then simplified code is in a lump called RECOILS, placed between A_START and A_END markers (I assume that's how it's should be):

Yes, but there is one subtlety here: the ACS namespace (A_ markers) is for compiled libraries. So you must add

#library "recoils"

to the top of your scripts, and recompile it.

Then you also need to have a LOADACS lump (in the global namespace, not in the A_ markers) containing the name of all libraries you want to load, each on a single line. In your case, that's just one line:

recoils

D2Jk said:

1) Am I trying to use scripting in a wrong way? (at least modifying player properties dynamically seemed to work for this guy).

No, it's a good approach.

D2Jk said:

2) I've read something about compiling. Is compiling required, and if so, why wouldn't it work as plain text like it does in DECORATE?

Compiling is required, indeed. This was inherited from ACS' origins in Hexen.

To compile ACS for ZDoom, you'll need ACC. Simplest method to use it would be to install it in some folder, and then tell SLADE 3 where it is located. Then you can right-click your ACS source and tell it to compile it, and it'll handle the rest automatically. Note that the ACS source itself should not be within the A_ markers. Just move it above A_START or below A_END.

D2Jk said:

3) Do you have to "#include" the script lump in some way, like the additional DECORATE lumps? Obviously, trying to #include the script lump as a DECORATE lump will create error messages, because of the major differences between the two.

No, you only need to #include sources if they contain definitions you need. Which is why practically all ZDoom script sources begin with #include "zcommon.acs"; if you try to compile without that you'll get an error message about functions "used but not defined".

However, ACS was originally designed to be map scripts, which is why you will need, in your case, to specifically mention that it's a library.

[D2Jk]

Thanks Gez. As I'm a beginner, I could still use some help. I installed Slade and configured ACC (I was actually using XWE until this point).

Mentioning the A_markers may have worked as a red herring here... I wasn't aware that they were related to libraries, I did not mean to suggest I want to use them, nor do I have multiple scripts written just yet. Just the simple one I mentioned above, from which I'll expand further once I've managed to get it working.

So my question now is: do I need to utilize libraries at all at this point? If I've understood, they're used to make things more manageable in a large-scale project, but what about if I only have this single, simple script I'm trying to get to work currently?

If not, how would I set up my simple script in the .WAD, so that I'm able to call it with the A_NamedExecute function?

Sorry for the beginner questions, again. I'm sure I'll get up to speed once it becomes a simple matter of tweaking values and identifiers for multiple scripts with different recoil amounts. :)

EDIT 1:

I figured it out now. I thought I was doing something wrong, because I couldn't see any effect, but that was because the above script in fact does nothing. I accompanied a "print" function to see if the script actually loads and functions in game - which it does, but the pitch modifying part does nothing.

It compiles without errors, though. Now to find out how to fix it...

EDIT 2:

Haha, ok. So it seems the values used for the angles aren't really comparable to A_SetPitch; I had to multiply them by at least 1000 to get similar results.

The working code now looks like this:

Script "Recoil" (void)
 {
  Delay(1);
  SetActorPitch(0, GetActorPitch(0)+10000);
 }

Now I can proceed to refine the effect, such as adding a more gradual recoil and returning motions, and then make new scripts with varying recoil strengths for different weapons.

[Blue Shadow]

D2Jk said:

EDIT 2:

Haha, ok. So it seems the values used for the angles aren't really comparable to A_SetPitch; I had to multiply them by at least 1000 to get similar results.

The reason for that is that pitch is a fixed point number, and ACS expects the value of it to be in the form of x.y, e.g., 15.0 and not just 15.

If a function in ACS expects a fixed point number, putting the number without the point part doesn't give the expected value. For instance, 15 (without the point) actually equals to 0.0002288818359375 (15/(2^16)) and not 15. That's why you didn't notice any change in the pitch, because it was practically zero.

[Gez]

D2Jk said:

So my question now is: do I need to utilize libraries at all at this point? If I've understood, they're used to make things more manageable in a large-scale project, but what about if I only have this single, simple script I'm trying to get to work currently?

If you want the script to be reliably available in every map, use a library. Otherwise, you'll have to copy-paste it in every single map script. And if your mod does not come up with its own maps, you have no choice but to use a library.

[D2Jk]

Thanks Blue Shadow, Gez. Good to know.

One quick question: since the value in Delay() equals to tics, I assume one still can't adjust them in finer increments than 1/35th of a second (eg. Delay(0.5))?

[Gez]

The entire game logic runs at 35 Hz. You cannot use less than one tic.

[D2Jk]

Ok, that's what I thought.

I have another ACS related question, hope you don't mind. As an additional recoil effect, I've had the HUD weapon sprites to nudge downwards a small distance when you fire, and then return. So far I've been doing using the Offset(x,y) keyword. I was wondering if the same could be achieved with a script, as it would simplify the code and maybe be more sophisticated at the same time. To tailor the effect for each weapon, A_NamedExecute could pass custom arguments to a generalized script (Recently I converted the recoil script above to do just that).

Unfortunately, at least on this page, I can't seem to find anything related to controlling HUD sprite offsets, nor could I find anything useful by searching around. Is this impossible to do with scripting?

[Gez]

There are currently no functions to control HUD sprite offsets from ACS, though it has been suggested so it might happen.

[D2Jk]

I see... maybe some of these days then.

I'm having a bit of problem with A_SpawnItemEx. I made a weapon to eject bullet casings, and the effect seemed ok, until I noticed that the spawn offset of course didn't take player's pitch into the account. So if the player was looking down with the weapons, the casing would appear out of thin air.

I figured I'd try to fix the problem by using the "pitch" variable this way:

A_SpawnItemEx("BulletCasing1", 32,0,(26-pitch*0.7))

It works fine while the pitch is perfectly level or I'm looking downwards, eg. at the floor. However, if I try to look upwards, the spawning of the casings ceases. What am I missing? If I've understood correctly, I shouldn't have run into any kind of an upper limit with that.

[Gez]

Pitch is an angle, so you should be using trigonometry rather than a simple multiplication.

[D2Jk]

Fixed it now, thanks.

I noticed that the axises in decorate velx/y/z seem to be relative to the world, not the player or actor. In the spawn settings, I've set the player's current velocity to affect the velocity of the spawned casings, but the effect is inconsistent depending on in which direction the player is facing in the world (N/E/S/W). So for example, velx isn't strictly forward/backward velocity, if you keep turning around.

Probably the z-axis movement would work on its own, but for x and y axises I would have to use a formula involving trigonometry again.

[everennui]

D2Jk said:

Fixed it now, thanks.

I noticed that the axises in decorate velx/y/z seem to be relative to the world, not the player or actor. In the spawn settings, I've set the player's current velocity to affect the velocity of the spawned casings, but the effect is inconsistent depending on in which direction the player is facing in the world (N/E/S/W). So for example, velx isn't strictly forward/backward velocity, if you keep turning around.

Probably the z-axis movement would work on its own, but for x and y axises I would have to use a formula involving trigonometry again.

It's stuff like this that is really intimidating. I would love to know if you ever solved it.