ZScript Discussion

[Agentbromsnor]

You are not forced to use all those low level features. Everything DECORATE can do will still be there, but with the added advantage that if you need to go more low level you now can.

I'd also guess that eventually people will write some libraries others can use.

In general, if you have a solid understanding of DECORATE and ACS you should be fine, although a bit of real programming experience would help a lot understanding the concepts.

Thanks, that's definitely reassuring! I have a basic understanding of both languages, so I should be good then. I've always been more of a scripter than a programmer though; I often lose track when I write a program that spans multiple files.

[Leonard2]

No. The code Leonard made turned out not to be working as expected so I had to redo the entire thing. Actually, virtual functions ARE properly working now, they weren't before.

The code was working as expected.
I'm going to give you the real reason why you removed it anyways because that just annoys me so much.
Let's quote the commit:

not to mention a huge amount of work up front to get going.

That is not true.
First of all I had already told you via PM that the new implement macro needed to be used in the first place.
Why else would I ever need a new argument otherwise?
All that is needed is to instanciate the template for the given object and that alone doesn't even require a new argument, it could just be done for all objects regardless, I simply thought it was sanner to use the argument instead.
The native classes that can be inherited from are already declared within zscript and that alone is MUCH more work than simply changing the last argument of a macro from 'false' to 'true'.
If you think that is a 'huge amount of work' then I'm sorry but I must break it down to you: you are simply terribly lazy and that cannot be acceptable if you're going to code the thing that everyone have been waiting for for years.

this is simply too volatile and would require constant active maintenance

Not true either.
This is not volatile.
If what you're afraid of is that a native virtual override from zscript doesn't work for someone and that you are not able to track down which class doesn't have the template instanciated, the solution is clearly not difficult: simply check for the "VMExported" pointer whenever a native virtual function declaration is encountered and abort if it is null.
There you have it, there's absolutely nothing 'volatile' about this not to mention you could instanciate it for every class without using an argument if you're that lazy in the first place.

But now that I've debunked your points, let's get down to why you really removed it: you didn't remove it because you were lazy, otherwise you wouldn't have redone it from the ground up with annoying "Call" function aliases.
No you removed it because you didn't like it, in fact you had already told us in another thread about zscript.
If you had the intension of completely removing it then you could have said so before instead of making the both of us waste our time.

The only exception is the Destroy method which gets in the way of the garbage collector. If any object with a scripted virtual override table got into the final cleanup action it'd badly crash the engine because there's no guarantee that the needed VM related objects haven't been deleted already.

Simply use a "VMSuperCall"?

there are no global functions and there won't be, they wouldn't help you anyway, because they have no self pointer.

What? WHY?
static methods have no self pointer yet they are allowed.
If static methods can already be implemented then nothing should get in the way of proper global functions.
What if I don't want a self pointer anyways, your argument is just useless.
That just seems like yet another stupid limitation that is here for no good reason.

will most likely do a merge.

I really hope you still remember what you posted about this.
I don't really see what's so urgent about merging this with master as people are already testing the current branch anyways.

That's BeginPlay.

BeginPlay exists only for actors and is only called after the actor is physically spawned which is way after the class is constructed.

... which technically is the earliest place to defer any action to the user. First it has to initialize the defaults and other stuff to properly set this up, before any user-side function can be called. BeginPlay has always been the place where a newly spawned actor does custom initialization.

There's a reason why AActor's constructor is hidden and not for public use. Today I would do this differently but these conventions are so old that we can't simply throw them out anymore.

The defaults are already properly initialized in the very place I'm talking about.
You still didn't get that I'm not talking about Actors though.
What about a class that would inherit from Object?
Nice job on completely ignoring the rest of my post by the way.

[Graf Zahl]

First of all I had already told you via PM that the new implement macro needed to be used in the first place.

Yes, but I didn't realize that I had to manually put it on every single class in the game that can be inherited from.
That's approx 100 classes after removing the game stuff. And it also needs to be done for every new class that's ever going to be added - something easily forgotten and a potential cause for hard-to-detect errors.
And once the actor stuff is through, it needs to be put on every thinker, on every menu, on every whatever else we want to export to make it work.
That's simply not working out. Removing the stuff and writing a 'call' wrapper cost me 1 hour. It cost me a bit more to realize why Destroy was constantly crashing the game after my changes (the only reason it didn't crash with your method was that no class with a scripted override class attached to it ever got into the final garbage collection, the one that crashed was DDropItem, but that would have changed eventually - the problem here is the implementation of how the class system is being shut down which will definitely need some serious thinking to fix), but the thing is, what is there now automatically propagates to subclasses, and that was worth a lot more than being able to keep the names.

The idea was good but in the end the decision was made because I weighed the cost-benefit ratio of both methods and chose the one that turned out better in that regard.
In hindsight this is an inevitable property of what you did, and I'll be honest: If I had realized this earlier I wouldn't have started using the code in the first place.

[Major Cooke]

@Leonard2: He did use VMSuperCall at first.

Nice job on completely ignoring the rest of my post by the way.

Let's just take it easy; he is pulling all the hard work after all, by himself. I don't think he's trying to ignore anyone, he just has his hands full. Though, strangely enough it took Nash asking my same kind of question...

[ZZYZX]

No global functions thing is pretty ok, it's just how the other object-oriented languages do it (Java, C#).
There you always have to have a class in order to have any code, and if you want it to be a "global function", then you just make a static method of a class.

If there are static methods already, what's wrong about having no global functions?

[Graf Zahl]

No global functions thing is pretty ok, it's just how the other object-oriented languages do it (Java, C#).
There you always have to have a class in order to have any code, and if you want it to be a "global function", then you just make a static method of a class.

At the moment I have just made all global functions static members of Object. This is not definitive yet, though.

[Major Cooke]

If I want to modify a current actor's powerup and it was given by a powerupgiver, I should be modifying the giver, correct?

Code: Select all

PowerupGiver lite = master.FindInventory("DemonMorphFullBright");
if (lite)
{
	lite.EffectTics += 35 * 30; // Set in tics, NOT seconds.
}

[ZzZombo]

No. It doesn't stick around. You need to fiddle with the actual powerup.

[D2JK]

Is there a ZScript equivalent to ACS's CheckActorState?

[Graf Zahl]

Not as a function, but you can compare an actors current state (CurState variable) with anything you like.

[Major Cooke]

Thanks for that zombo.

Another question, is PreMorphWeapon always null except when morphed?

[D2JK]

Not as a function, but you can compare an actors current state (CurState variable) with anything you like.

Thanks for that, although now I found out that the return type is "state". I wonder if it's possible to convert these to strings or names in any way? Because if I try to do:

Code: Select all

if (CurState  == "See")

... I get an "Incompatible operands for == comparison" error.

[Major Cooke]

Try with single quotes, not double.

Code: Select all

	virtual State GetAtkState (bool hold)
	{
		State s = null;
		if (hold) s = FindState('Hold');
		if (s == null) s = FindState('Fire');
		return s;
	}

[Graf Zahl]

Not as a function, but you can compare an actors current state (CurState variable) with anything you like.

Thanks for that, although now I found out that the return type is "state". I wonder if it's possible to convert these to strings or names in any way? Because if I try to do:

Code: Select all

if (CurState  == "See")

... I get an "Incompatible operands for == comparison" error.

You have to convert the label to a state. This is necessary because labels are class independent so before comparing them you have to retrieve the corresponding state from the actor you want to check. Do that with 'FindState("label")'.

[Nash]

I sure hope all of these will be cleanly documented when the first merge is done... right now my only source of learning is this thread and the little Search box at the top of the thread... :S