ZScript Discussion

[Major Cooke]

So GZScript was merged, but I take it you're going to have randi merge it ZDoom side? That's the only reason why it doesn't strike me as odd having gzdoom getting it first.

[Rachael]

It's there. If I pull against ZDoom's repo directly to my repository, a lot of files get deleted.

For some reason, the merge commit does not show, though.

[Graf Zahl]

That's because ZScript was ahead of master so the merge was fast-forwarded.

[Gez]

It's just a question of letting lumps from archive 0 be loaded unconditionally.

[Graf Zahl]

Actually, what I did was putting the check to abort after the parser call so that the first iteration can run unhindered.

[Major Cooke]

So what's next now that zscript has been merged? Specifically, I'm talking about ZScript itself, barring DECORATE issues, if you have any plans laid out yet.

[Graf Zahl]

First: Clear GZDoom's backlog of bugs.
Second: Wait for bug reports and suggestion
After that: No idea. ZScript isn't finished, it will still need some work.

[Nash]

After after after that: Menus? I can't wait to trash my ACS menus for good.

[D2JK]

Is there any way to retrieve the current bobbing X,Y offsets applied by A_WeaponReady?

[ZzZombo]

Is ZScript case-sensitive in identifiers? If 'yes', then I object having beginning capital letters in them, like Angle. Moreover, I object having an inconsistent style as well, like shown in fillcolor. If I was to choose, I would stick to the common C++/Javascript naming convention, where identifiers start with a lower-case letter, but may contain upper-cased ones later, when another word is appended to the name, like this: myCoolVariable.

[Major Cooke]

Is there any way to retrieve the current bobbing X,Y offsets applied by A_WeaponReady?

OverlayX and OverlayY which are available in Decorate. Just using them in the layer without parameters retrieves that calling layer's X and Y coordinates, mind.

Is ZScript case-sensitive in identifiers? If 'yes', then I object having beginning capital letters in them, like Angle. Moreover, I object having an inconsistent style as well, like shown in fillcolor. If I was to choose, I would stick to the common C++/Javascript naming convention, where identifiers start with a lower-case letter, but may contain upper-cased ones later, when another word is appended to the name, like this: myCoolVariable.

No, they're insensitive, as they ever will be. Only string contents are case sensitive. But that can be mitigated in a comparison by using ~==.

[ZzZombo]

Code: Select all

	native bool, Actor TestMobjZ(bool quick = false);

What is this? Why two return values?

Code: Select all

	native void GiveSecret(bool printmsg = true, bool playsound = true);

What is this?

Code: Select all

	native bool GiveAmmo (Class<Ammo> type, int amount);

I see that there is also GiveInventoryType() function, with the unwieldy name. Why not call it GiveItem?

Can we also have static methods like SpawnDirt() somehow made more obvious? So you couldn't accidentally call them on an instance, and editor authors surely will love that as well, for autocompletion and whatnot.

Code: Select all

States(Actor, Overlay, Weapon, Item)

What exactly are the parameters here for?

I see that pos is marked readonly, while vel isn't, why? And while at this, why again we couldn't make flags reside in the flags member, while we could make that to position and velocity?

[Graf Zahl]

Code: Select all

	native bool, Actor TestMobjZ(bool quick = false);

What is this? Why two return values?

It has two return values because that's how the function was implemented by Raven. What it does? It checks if the actor fits vertically in its current position. The bool returns whether it fits and the actor that gets returned is the one that would block it, if it was an actor that was blocking.

Code: Select all

	native void GiveSecret(bool printmsg = true, bool playsound = true);

What is this?

Do I really need to explain it? It credits a found secret to the calling player. Which may be handy if you want to add some secrets that cannot easily be expressed by the hardcoded options.

Code: Select all

	native bool GiveAmmo (Class<Ammo> type, int amount);

I see that there is also GiveInventoryType() function, with the unwieldy name. Why not call it GiveItem?

I can rename GiveInventoryType. But they cannot be merged because their functionality is subtly different. For regular use, using A_GiveInventory is recommended anyway but I needed to export these internal funtions to implement everything the internally defined actors require and to export further stuff in the future.
These two are really just internal backing for other functions but that needs they need to be present in the list of exports.

Can we also have static methods like SpawnDirt() somehow made more obvious? So you couldn't accidentally call them on an instance, and editor authors surely will love that as well, for autocompletion and whatnot.

What would you suggest? Any OOP language I know allows calling static methods with an object as qualifier on the left side, but since no self pointer is passed, it's just the same as calling them with a class name on the left.

Code: Select all

States(Actor, Overlay, Weapon, Item)

What exactly are the parameters here for?

They are for determining what kinds of functions a state may call. This is to resolve the problem that weapon and custom inventory actions need to be called with a foreign object as 'self' and help determining the required signature of any action function that is compatible and to perform. Don't worry, this will be explained in the Wiki.

I see that pos is marked readonly, while vel isn't, why?

Because changing vel has no immediate effect, it's just a value that gets used in the next Tick() call. Changing position requires some internal bookkeeping and having it go through a small number of function calls allows to make this bookkeeping easier. If you look at the C code you'll notice that it does the same thing.

And while at this, why again we couldn't make flags reside in the flags member, while we could make that to position and velocity?

What advantage would that have been when I could export them as single variables just as easily? The flags are one of the most annoying and most error-prone things in the C++ code because of the required application of boolean logic. With single variables you just set them to true or false - removing a huge cause for progamming errors.

[Player701]

BTW, regarding the States keyword. Why do some weapon definitions in zdoom.pk3 have "States(Weapon)" while others have just "States" (and there are actually more weapons with the latter than the former)? I thought the "(Weapon)" part was mandatory for calling weapon functions?

[Graf Zahl]

I designed the whole thing that in most cases no specification is needed. Of course all weapons automatically imply use on weapon overlay states because that's the normal use case. A weapon state only needs a specifier if it's supposed to be used on the weapon's item states to restrict the self pointer.