ZDoom

The defaults block won't change. The reason I kept the DECORATE syntax is actually very simple: It encourages modders to convert their definitions, by making this relatively straightforward. If its syntax deviates too much from DECORATE this won't happen.

If ZScript came out of a vacuum, a few things would be different but it has to coexist with DECORATE, it tries to share as much code as possible with DECORATE (because redundancy is bad) and it shouldn't put up roadblocks to make modders make the jump. That code was written more than 10 years ago with higher level modding in mind, you will also notice that some of the properties refer to same-named fields in Actor, but others do not. Some can be accessed from script code but others can't.

If you absolutely want consistency, the only method would be to introduce an InitDefaults function that would supersede the Default block, but it also would remove some level of abstraction here that's designed to prevent bogus definitions and put a lot more responsibility on the modder.

@Graf: I'm going to guess that you're no longer going to use the ZScript branch? If that's the case I don't really see much reason to see GZZScript updated unless GZDoom falls significantly behind, which I doubt it will.

At any rate, the reason why I ask is because of the disclaimer notice on [wiki=ZScript]this wiki page[/wiki].

For the time being, no, but for new feature extensions it will eventually be revived. Right now I have switched to bugfixing mode and that should be done in master.

I did that on purpose, mainly so people understand what pages are part of zscript and which aren't. I.e. Structs.

Is there anything in ZScript that would let me check if the player is standing on a liquid terrain? The "waterlevel" expression seems to be designed for bodies of water you can actually dive into, while ignoring the standard, ankle-deep pools.

On a related note: it would be useful to have eg. a player flag or property, that automatically adjusts the spawn height, when the player's weapon spawns something while the player is standing on a liquid terrain. But maybe this is one of those "easier said than done" cases.

What you might be looking for is 'floorclip'. But be careful: It's not all that simple. In the end floorclip and waterlevel is all you can go by here, the engine does not have any better information.

Well well, idk if that topic was ended but here I go:
Object.flags.Shootable syntax over 'Object.bShootable'. ? (is that right?)
I'd prefer just Object.Shootable, you just get an ide, pass the mouse over the Shootable word and it popups a messagebox saying "Boolean flag".
"'Object.bShootable'" for me sounds like you're stealing the ide job for showing what type is that word. (or when there're two types of Shootable flags name)

About vectors operation, it could be a mix of C with analytic geometry, you can get/set any part of a vetor by using the 'dot' ex: Object1.Pos.X += 10; and in case you are operating with both vectors, just do a simple sum ex: Object1.pos -= Object2.pos; and do not allow this : "Object.pos +=10" because you may not know what the user wants (change all the axis or some specific axis).

ZDoom.ZScript.Entity.Actor.Flags.Shootable != Dissenting;

ibm5155 wrote:do not allow this : "Object.pos +=10" because you may not know what the user wants (change all the axis or some specific axis).

You can't do that anyway. It's a vector3, you have to apply it individually. Also you can't modify pos like that at any rate, it requires a function to change.
And I agree with Kinsie, that long thing is absurd and unneeded.

Major Cooke wrote:

Code: Select all

Obj.SetOrigin((obj.pos.x + 10, obj.pos.y + 10, obj.pos.z + 10), true);

You can do that by ... but here's the real reason why the easy way should not be used: This is not portal aware!
Instead do:

Oooooh. Didn't know that.

ibm5155 wrote:About vectors operation, it could be a mix of C with analytic geometry, you can get/set any part of a vetor by using the 'dot' ex: Object1.Pos.X += 10; and in case you are operating with both vectors, just do a simple sum ex: Object1.pos -= Object2.pos; and do not allow this : "Object.pos +=10" because you may not know what the user wants (change all the axis or some specific axis).

In GLSL this changes all axes. I'm pretty ok with that behavior. It'd be pretty nice if GLSL-like vector syntax was implemented, including things like a.xyz = b.xxx

You mean like forwardmove + 10, sidemove + 10 similar to A_Warp(AAPTR_DEFAULT,10,10,0)?

If so, well, there is that power to do it ourselves now. We just have to make up the stuff for whenever we can make libraries and ship'em out for others to use.

Major Cooke wrote:You mean like forwardmove + 10, sidemove + 10 similar to A_Warp(AAPTR_DEFAULT,10,10,0)?

More importantly, forwardmove * 10, sidemove * 10

Major Cooke wrote:If so, well, there is that power to do it ourselves now. We just have to make up the stuff for whenever we can make libraries and ship'em out for others to use.

Libraries changing core syntax?

More so adding. Like, injecting new functions and/or variables, but yeah. The only problem is, right now there's no way to reliably add anything to anyone without requiring all inheritance to go through them, as it won't even start if you try to do things like extend the Actor class.