ZScript Documentation

[Graf Zahl]

For that you need to call self.AngleTo(X).

[kodi]

Is there a way to make pitch and yaw input not affect the playerpawn in szcript? Other than constantly turning "against" it with getplayerinput.

[Major Cooke]

You'd have to basically freeze the player and rely solely on GetPlayerInput in that regard. Two of them: one for pitch and one for yaw.

[kodi]

So I'd have to freeze the player completely and re-implement all movement, shooting, reloading etc. with GetPlayerInput then? Would be inconvenient, but should at least solve the rendering interpolation issues with the "turn-against" method.

[Major Cooke]

Just dont expect it to be very compatible with mods that rely on PROP_(TOTALLY)FROZEN.

[kodi]

Just dont expect it to be very compatible with mods that rely on PROP_(TOTALLY)FROZEN.

Well it's for improving the custom movement system in a gameplay mod (doomshock), so support for heavily scripted maps is not something I'm particularly concerned about Thanks for the help.

By the way, could there be a zscript topic on the wiki where people can post general code examples (experimental or not)?

[D2JK]

double AngleTo(Actor target, bool absolute = false);

What is the boolean option supposed to do here? I tried enabling and disabling it, but couldn't notice any difference.

I was hoping unsetting it would make the function return the relative angle towards the target:

---

Code: Select all • Expand view

Int RelativeAngleTo(actor A)
 {
  int V = angle - AngleTo(A);
  while (V < -180)                                             V += 360;
  while (V >  180)                                             V -= 360;
  return V;
 }


[Graf Zahl]

These functions are portal-aware. If you set absolute to true it won't factor in portal offsets. In some cases this may be necessary.

[Matt]

I've been staring at the Structs page for a while now and I am still completely baffled as to what use it could possibly have. The example shows the grammar but it is completely useless in demonstrating its significance. (The one thing I could imagine doing, setting virtual functions across actors that do not inherit from a common custom actor, cannot be done.)

A lot of the DECORATE examples are really good about this: "this function causes this to happen. Here's an example of an imp that calls it twice to spin around on the spot 3 times before exploding..." You didn't even need to look at the description, the example alone could show what it could do and why.

It would be great if someone could add something like that to this page.

[Major Cooke]

Ya know, it'd be a real lovely treat if other people could work on helping out... I have very little time to work on the documentation right now.

That example was written before functions could be inserted.

Also, it wouldn't hurt to learn a bit of C++/Java, Vaecrius. That'll teach you how to use structs. There's a link right on that wiki page.

[Caligari87]

https://zdoom.org/wiki/Controlling_dynamic_lights

There's something on this page I really don't get:

The MISSILEEVENMORE flag has a special use for dynamic lights. When present, it enables the subtractive mode.

I mean, what the hell? How does that make any sense?

[Graf Zahl]

Remember, this is from a time when DECORATE wasn't that configurable, roughly 2006 or so. So I chose 3 flags that had no meaning for dynamic lights and repurposed them for some features I wanted settable in DECORATE.

[Gez]

Are you going to try to make dynamic lights that attack players? Because that'd be weird (and honestly you could have that effect by attaching a dynamic light to an invisible actor).

[Graf Zahl]

Dynamic lights cannot act as regular actors because they adjust their radius to their light size. Don't even try. In fact, ADynamicLight should proably demoted to a thinker instead of a real actor and also use attachment to handle the light map things.

[Major Cooke]

If you change it, can you give us an example on how to attach it, please?