ZScript Discussion

[Major Cooke]

This might be beyond first merge, but like the weapon name, can there be a function to retrieve anclass name? Or perhapsna pointertype like ObjPtr TargetPrev for example, so we can store them in array or so. Ive wanted to make a list of previous targets so enemies can continuously eliminate one after another. A general one I suppose. Or would actor as a type work?

[Major Cooke]

Another curious question... Would it be possible in zscript to have a custom function capable of replacing DoChase behavior in a way?

Code: Select all

Function NewDoChase(ptr, melee, missile, flags) replaces DoChase
{
	// Custom Stuff Here
	if (<insert long code here>)
	{
		//...
	}
	else
	{
		OldDoChase(...);
	}
}

Function OldDoChase : DoChase
{
	//Performs the regular internal DoChase.
	DoChase(...);
}

I ask because I've heard we'll be able to override things like damage control and/or functions...? Something along those lines.

[Graf Zahl]

Absolutely not like this.

You will be able to override virtual functions, but action functions by definition are not virtual. Anything that is supposed to be overridable will be virtual but I doubt that A_Chase and its helpers will be. Of course the altered functions only apply to subclasses, code injection like what I suspect here will not be possible at all.

What you will be able to do is to write a replacement for A_Chase as a script function, but you will have to derive all your monsters from a common base class then.


As a general rule of thumb: If something is not possible in C++ it won't be in ZScript.

[Major Cooke]

Hmm, what about this?

Code: Select all

Function NewDoChase(ptr, melee, missile, flags)
{
	// Custom Stuff Here
	if (<insert long code here>)
	{
		//...
	}
	else
	{
		OldDoChase(...);
	}
}

Class monstah : actor
{
	States
	{
	See:
		ZOMB A 1 DoNewChase(...);
		Loop;
	}
}

If I can't do that, what would the declaration look like inside the base actor(s) to allow its use?

[Graf Zahl]

Can we please wait with this stuff until later? I am currently building the code generator, the function interface is still some time off. I simply can't tell you yet how this would finally look.

[Major Cooke]

Fair enough.

[ZzZombo]

Did I miss the difference between a name and a string?

[Graf Zahl]

A name is a unique integer constant representing a case-insensitive string. There's really not much of a point making this distinction on the script side, but, well, it's there and it needs to be dealt with. Names are more efficient, though, if you do not need to print them.

[Graf Zahl]

BTW, I just implemented named functions.
For a first public version it looks like the only thing I still need to do is handling struct members in classes, so that the actor's pos and vel members can be properly accessed.

After that it will need some public exposure to find problems before continuing. I'll use that time to convert more native functions.

[Hell Theatre]

After that it will need some public exposure to find problems before continuing.

Wait a minute. Are you saying that you already got something that is usable to some degree?
I'm a bit baffled. The scripting stuff has been sitting around for - how long - without seemingly making any progress, any you manage to churn out something actually usable in less than THREE WEEKS?

How come this is going this fast now, and why wasn't this possible before?

[Rachael]

I think Graf has stated before that he intentionally designed the DECORATE system to be expandable - i.e. a full system underneath with a parser on top. And that ZScript is, for lack of a better term, simply a new parser for it.

To put it simply - it's the same old system, you just interact with it in a new (and hopefully more flexible) way.

[ZzZombo]

A name is a unique integer constant representing a case-insensitive string. There's really not much of a point making this distinction on the script side, but, well, it's there and it needs to be dealt with. Names are more efficient, though, if you do not need to print them.

So, it's FName being exposed, if I read this correctly.

[Graf Zahl]

Precisely that. The code generator is exactly the same as for DECORATE, of couse I had to expand it quite a bit to handle some things DECORATE could not. Had it been necessary to develop a completely new code generator things wouldn't have moved this fast. Interestingly, that's what Randi planned, but why reinvent the wheel? Even with the cleanup pass this code still needs, it saved countless weeks of tedious work. It already had support for if-statements and loops, thanks to a code submission by Leonard2, and the basics had been working for quite some time. The biggest change here was to add local variables and to be a bit more thorough when resolving identifiers to what they actually stand for. This part was underdeveloped in DECORATE because it couldn't make much use of it.

And of course the work is nowhere near finished, for example right now the only variable types that are supported are signed ints, doubles and class pointers. Unsigned ints, strings and structs are still missing. But I feel that what is there right now is good enough for some initial public exposure and testing. It's certainly sufficient to convert a larger batch of the simpler existing action functions.

[Graf Zahl]

So, it's FName being exposed, if I read this correctly.

Precisely that. Nothing more, nothing less.

[Fishytza]

Now I know I'm getting too ahead here when I ask this, but eh just to see if it'll happen or not.

Are we going to have the ability to replace functions in the same way actors are replaced?
Let's say I wanted to replace/modify A_Chase to make non-flyers make a little hop and I didn't want to replace every single actor.

Code: Select all

void A_HopChase() replaces A_Chase //Not sure how to handle parameters here.
{
    if( !A_CheckFlag("FLOAT", "Null") && velz == 0 && random(1,10) == 1 )
    {
         A_ChangeVelocity(0,0,3);
    }
    A_Chase;
}

Actually, this seems like a stupid idea, but I thought I'd ask anyway.