ZScript Discussion

[Graf Zahl]

If you know what actor to exclude, yes. If that function returns false, there won't be a collision and the decisons that make it return false are up to you.

[Gez]

Thanks Hellser.

1. Don't change the flags' name. It's SHOOTABLE, not BSHOOTABLE. Changing the name is a source of confusion greater than believing an user might think it's the flags that would be shot.

If I remember semi-correctly, this can't be done because the parser can't read them properly, or something along those lines. So it needs a prefix. Also, think of it as bSHOOTABLE since the b stands for boolean.

In summary "we need a prefix". Okay then, go to point 2.

[Graf Zahl]

Ok, can we please get past the BIKESHEDDING now? Since you brought up that term, Gez, I find it a bit strange that you participate in full force discussing a mostly trivial aspect to death.

[Major Cooke]

In the mean time, I think it'd be wise to ask for documentation help and zscript clarification here instead of in this thread since stuff's getting lost.

[D2JK]

If you know what actor to exclude, yes. If that function returns false, there won't be a collision and the decisons that make it return false are up to you.

Okay, I just don't know how to use it. As mentioned above, some documentation with example code would be useful. Being a very recent addition, there's none for it yet.

[MaxED]

Ok, can we please get past the BIKESHEDDING now?

No?..

In current implementation (correct me if I'm wrong):
1. DECORATE-style integral flags ("SHOOTABLE") use special syntax and can only be used in the "Default" block. Users can't do bitwise manipulations with them and can't/don't have any reason to directly access them (because "flags" is not a thing, so there's nothing to compare them to). In other words, there's no reason for users to have them as non-boolean properties.
2. ZScript-style boolean flags ("bSHOOTABLE") are only accessible in a function scope.

An alternative implementation (which won't ever happen because of bikeshedding):
Retire the "flags" concept/syntax entirely, use the same boolean properties everywhere:

Code: Select all

Default
{
    Shootable true;
    NoGravity false;
}

States
{
    Spawn:
        YOLO A 1
        {
            if(!target.Shootable) { ... }
        }
        Stop;
}

[Major Cooke]

You skipped a few posts, MaxED.

Try this and this for an explanation.

It's not going to change, plain and simple. Everyone will have to get used to some small things like this here and there. Some sacrifices must be taken, and this is as close to the dream as you'll get with flags.

[ZzZombo]

Graf skips the entire points. He elegantly eludes mine, for example. Hell, he just called the whole discussion bike-shedding, so it seems we won't get any proper response any time soon.

"Ok, can we please get past the BIKESHEDDING now?"

We can move on when you properly explain how's

First, "flags.shootable" asserts that indeed, I mean to access an actor's flag, because what if there is a variable starting with 'b', like 'bShooting'? How am I supposed to know what is a flag and what is a variable? Look them up in a list of flags? But, meh, there is none for ZScript readily available, because it gets "synthesized" somewhere else. Even then, having to look such information that otherwise could be easily inferred from just names and naming conventions should be screaming at you "BAD DESIGN!". And I'm sure sticking to the current scheme also significantly slows editing tools down from picking ZScript up, how can they determine what is this and that with such poor design?

is just bike-shedding. Just to start. But since I'm a sore loser who can't properly argue (how ironic, given you avoided all bolded parts the whole time, regardless whether it was brought up by me or others) and duh, you probably ignored me, there is no hope.

[Major Cooke]

And he's the one doing all the work on this. I suggest being a little more thankful. It's not everyday someone with 20+ years of programming experience comes around and does this for us FOR FREE.

You don't want ZScript to spontaneously grind to a halt from pissing him off too much, do you?

Let's all step back and go outside, breathe some fresh air and cool off for a little. (Or in my part of the world, freeze one's balls off and become a eunuch from the wind chill...)

EDIT: Damn typos.

[Hellser]

---

Graf skips the entire points. He elegantly eludes mine, for example. Hell, he just called the whole discussion bike-shedding, so it seems we won't get any proper response any time soon.

"Ok, can we please get past the BIKESHEDDING now?"

We can move on when you properly explain how's

First, "flags.shootable" asserts that indeed, I mean to access an actor's flag, because what if there is a variable starting with 'b', like 'bShooting'? How am I supposed to know what is a flag and what is a variable? Look them up in a list of flags? But, meh, there is none for ZScript readily available, because it gets "synthesized" somewhere else. Even then, having to look such information that otherwise could be easily inferred from just names and naming conventions should be screaming at you "BAD DESIGN!". And I'm sure sticking to the current scheme also significantly slows editing tools down from picking ZScript up, how can they determine what is this and that with such poor design?

is just bike-shedding. Just to start. But since I'm a sore loser who can't properly argue (how ironic, given you avoided all bolded parts the whole time, regardless whether it was brought up by me or others) and duh, you probably ignored me, there is no hope.

Apparently you didn't get my memo to stop. I'm giving you a week to chill.

[MaxED]

Try this and this for an explanation.

->

this can't be done because the parser can't read them properly, or something along those lines

Oh my! This explains EVERYTHING!
Also I do realize the discrepancy between internal implementation, where flags are integers defined in 8 enums and ZScript implementation, where the same flags are exposed as booleans. I just don't think that the end users must be affected by this.

And he's the one doing all the work on this. I suggest being a little more thankful.

And I'm the one doing all the work on that. Will you kiss my ass now?

[wildweasel]

Sure as hell won't when you fart it out that way.

[wildweasel]

Guys, seriously, how many of these arguments are we moderators going to have to clean up?

[Rachael]

Bikeshedding... heh... fitting term.

Look, I'll agree just about as much as anyone I would've preferred to see flags in their own namespace, that does increase code readability quite a bit. But Graf is right about precedent. Unreal did do boolean flags in the actor's main namespace, in fact the only thing that separated them from each other was that in edit mode, each variable - bool or otherwise - could be given a category. Unreal, in fact, was probably even worse, in that flags didn't even have to start with b. You could literally just define "bool flag" for shits and giggles if you wanted to. The reason why that doesn't work in ZDoom, though, has nothing to do with the definitions themselves, but rather how they are defined in the source. But that doesn't stop you from defining custom actor flags this way, anyhow.

Graf's decision may not be ideal, but it is final, it's probably best we just move on from it. Kicking dirt and raising tantrums does nothing to help matters, and you're going to look at all this 5 years or so from now and think "... I said that?". It's not that big of a deal. bFLAG. It's simple. It's actually elegant enough to work. Hence where Gez's term came from to start with. You're all going to be embarrassed when you look back on this.

[Major Cooke]

And I think this won't be any harder for editors to adapt highlighting to, to top of ZzZombo's concern on those. I like bFlag as is as well.