"How do I ZScript?"

[Graf Zahl]

I'm sorry but to do real model collision it a) needs to be done in native code (CanCollideWith would be wayyyyy to slow for that) and b) requires a lot more than changing this single place in the engine. You'd also need the actual processed model data for that and not something read off the original model file.

[ZZYZX]

I'm sorry but to do real model collision it a) needs to be done in native code (CanCollideWith would be wayyyyy to slow for that) and b) requires a lot more than changing this single place in the engine. You'd also need the actual processed model data for that and not something read off the original model file.

a) depends on model complexity and methods/optimizations used
b) reading a model file would work. There should be different models for collision and actual rendering, and using "processed" model data will only make it slower. That is: read .obj (or some popular binary format) from the wad using direct lump reading, make a structure that describes maximum of 20 polygons, use that for collision. It's not for complex/often used things anyway, more like for 3-4 really 3D shaped things that can't be done with sectors.

Primitive example with circular hitbox: http://pastebin.com/tpAeWE9L
What's really required to make this work properly:
1. Proper non-orthogonal sliding with actors (like with walls).
2. Bullet support (a virtual method that can output a bool and a vector — if there was an intersection with tracer, and if there was, then WHERE).
3. "allow player to move out of blocked thing" should be fixed to also use a virtual function because otherwise it allows free movement inside the altered collision box provided you also move to the outside.

[Graf Zahl]

b) reading a model file would work.

No, it would not - because you have no idea what model you may test and what formats may come along, so all you could do is something highly specific to a limited set of models. And implementing complex collision checks on the mod side strikes me as a foolhardy proposition to begin with.

[ZZYZX]

Restriction of OBJ format which can be read/written by most 3D editors (and we don't want animation for collision checks, so one frame of OBJ works), and make model lump name a property, since it's a playsim thing as it's involved in collision, and shouldn't be tied to displayed frames or existing OGL renderer [which regular models are bound to] or whatever. We can't animate the model collision box until skeletal animation is done, and that's like... never? So yea, static default property works.
Then assume that all actors that don't inherit something like Actor3D have default square collision box.

And implementing complex collision checks on the mod side strikes me as a foolhardy proposition to begin with.

Please differentiate between "dangerous" and "shouldnt be possible". There are people who can do it right and that's exactly why ZScript was made — to allow people who can do it to do it. (not exactly complex collision, but all more internal stuff).
I know of at least two projects to implement proper monster AI based on ZScript, which is the same scale of complexity.

[Graf Zahl]

We can't animate the model collision box until skeletal animation is done, and that's like... never? So yea, static default property works.

You still need to know which frame of a model is currently active and a few more things. In other words: You have to replicate the contents of an actor's MODELDEF inside the playsim and make sure it always remains synchronized.

I know of at least two projects to implement proper monster AI based on ZScript, which is the same scale of complexity.

It's not about complexity but not depending on the internal data representation for something but redoing it all over again. The right way to do model checks should be to request the low level data and work with that. But like I said: PIT_CheckThing is just one of may pieces of code that would have to be changed to make it workable and not having it feel like a tacked-on feature. I don't think it makes much sense to hack around here, if you want model collision, plan a proper implementation.

[ZZYZX]

You still need to know which frame of a model is currently active and a few more things. In other words: You have to replicate the contents of an actor's MODELDEF inside the playsim and make sure it always remains synchronized.

To repeat myself: ANIMATION FOR COLLISION BOX SHOULD NOT BE SUPPORTED. For the same reason why direct setting of radius and height was not possible before, except it's going to cause even more problems.
MD2, MD3 animations are keyframe slices. If you animate collision box that way, you can only tell that "spot x was not blocked but now it is". You can't "push out" things that are now blocked, because you don't even know the movement vector (and it doesn't always exist, especially when one model changes to another). You can't block the collision box change either because it'd mean stopping the real animation frames as well, and this would cause unnecessary binding of playsim and rendering.

Thus, model-based collision doesn't need all that stuff (5 model formats, especially historical compatibility like DMD/MDL, various settings, per-frame models...) that was made for rendering.
All it needs is reading a single-frame (NO ANIMATION) OBJ, and scaling it accordingly.
If the required things (see above) are fixed/added (and that's like one day of coding max), this is going to become sufficient for static complex 3D architecture.

Again, I'm ok with making this a GZDoom feature, but I feel like this is going to take years and years (otherwise it'd be done already, as I'm not the only person who ever thought about it).
Thus, it makes sense to slightly patch the existing code and allow modders to define their own custom collision (not necessarily based on a model, might as well be based on arbitrary procedural things, like a sphere).

As for reimplementing formats, I've already reimplemented things like a callback-driven dialogue system with own configuration format (because I needed to be able to call a script to decide whether some conversation entries are available or not, or what (and how) to do when some entry is picked, and neither ZSDF or USDF allows that). Adding/parsing few lumps isn't that much of a problem.

[Nash]

if I have a function that returns a Vector2, how do I retrieve only the X or Y component of it? I tried this but it didn't work:

Code: Select all

// GetWind() returns a Vector2


static Vector2 _W_GetWind(void)
{
    let bumi = FWorld.Get();
    return bumi.wind; // is a Vector2
}

// ...

Vel = (BumiHandler._W_GetWind().X, BumiHandler._W_GetWind().Y, 0.f);

[ZZYZX]

This works for me:

vector2 a = (2, 1);
vector3 b = (a.x, a.y, 0);

Although I'd do GetWind once to a local variable, especially if "FWorld.Get" involves instantiating ThinkerIterator.

[Nash]

Making a local placeholder variable works, thanks.

[Graf Zahl]

Do I understand this correctly that you cannot access the fields of a function return value directly?

[Stroyed]

How do I set up a zscript in a wad editor? Is it like decorate where I just title it ZScript.txt and it'll just work?


EDIT: Never mind, I think I figured out what to do. From what I can tell, I just make a folder called ZScript and anything inside is labeled a ZScript.

[ZZYZX]

You need to create a zscript.txt actually.
If you create a folder and it's outright labeled as ZScript, it's a bug of whatever wad editor you are using.

[Stroyed]

Ok. Thank you. And also, do I have to trigger the script to run like ACS? Or does it just work automatically? Like if I were to put in a function that prints a message, would the message show up when i boot up the game?

EDIT: Also, is there a tutorial that goes over all of this so I don't have to search up and down for all of this info?

[ZZYZX]

ZScript is DECORATE-like in that it's based on actors. Example actors can be found in gzdoom.pk3/zscript directory (e.g. gzdoom.pk3/zscript/doom/archvile.txt).
DoomEdNums for ZScript are defined in MAPINFO only (see https://zdoom.org/wiki/MAPINFO/Editor_number_definition).
Non-DECORATE-like features are not stable and not recommended to use, especially for a newbie.

[Xaser]

Non-DECORATE-like features are not stable and not recommended to use, especially for a newbie.

Where is this idea coming from? What features in the current release build of GZDoom are considered "not stable and not recommended to use"?