ZScript Discussion

[Fishytza]

From another thread:

You also need to cast 'target' to the proper type first if you want to access information from a child-class.

I'm a bit confused by this so... If I wanted to know what the player's current weapon is, how convoluted does it have to get?

Would this be good enough?:

Code: Select all

if( target != NULL && target->player != NULL && target->player->ReadyWeapon != NULL )
{
    if( static_cast<Actor>(target->player->ReadyWeapon).CheckClass("BFG9000") )
    {
        A_ChangeFlag("FRIGHTENED", true);
        speed *= 2; //run away faster.
    }
}

Wait, since ReadyWeapon is a pointer, shouldn't it be static_cast<Actor*>? Or is it fine without the * ?

[Major Cooke]

Fishy: Why would you want to do the static_cast<> stuff...? That just sounds awful. ZScript's aim is to eliminate needing to do that, I think. Not to mention, there's no pointer stars to be used. All that is handled on the C++ side of things.

[Fishytza]

Why would you want to do the static_cast<> stuff...? That just sounds awful. ZScript's aim is to eliminate needing to do that, I think.

Oh, good. I wasn't actually sure which is why I asked.

So is this acceptable?

Code: Select all

Actor enemyweap = target->player->ReadyWeapon;
if(enemyweap.CheckClass("Bleh"))
{
...
}

[Major Cooke]

I don't think -> is something we'll have. We have periods though. But I'm not sure myself. If anything, it'll be overlays instead of readyweapon (don't quote me on that).

[Fishytza]

So how will it work, then? How do I get a player's 'ReadyWeapon'? Is that even possible?

Let me be clear. This is for comparing the weapon the player currently wields so as not having to call GetWeapon() from ACS.

[Graf Zahl]

There will only be class casts which are implicitly dynamic.

So, if you got an actor and want an inventory it's

Code: Select all

   Inventory i = Inventory(a);

or for checking if it is an inventory

Code: Select all

  if (Inventory(a)) ...

Of course, if you want to check and then use the child class, do the cast first and the check on the resulting variable.

So how will it work, then? How do I get a player's 'ReadyWeapon'? Is that even possible?

Assuming everything is implemented, and you got a PlayerPawn in the action function:

Code: Select all

 if (self.player)
 {
   Weapon rw = self.player.ReadyWeapon;
   if (rw)
   {
      // do stuff
   }
 }

[Major Cooke]

Assuming everything is implemented

This being key, Fishy. The ability to do that sort of thing might not be available until sometime after the first merge, and at any point it may or may not change before then.

One other thing, Graf, you said there's something to change about A_Jump functions? I'm looking around for it so I can document what needs to happen with those.

[Fishytza]

This being key, Fishy. The ability to do that sort of thing might not be available until sometime after the first merge, and at any point it may or may not change before then.

Yes, yes, I know. Don't think about step 20 if you haven't got to step 5 yet, I get it.
But take it easy, mate. Seeing this stuff is super exciting so I have to ask questions just to get a basic picture of what to expect. Just bear with me a little.

[Major Cooke]

I only said it because I know someone else is going to ask, or someone may misunderstand that bit and jump to the conclusion that it'll be in the first commit right then.

Since not everyone's going to be browsing all the posts from start to finish, it'll work as a good reminder for those who skip straight to this page.

[arookas]

I wonder just how much of the engine's hardcoded internals can be exported to zscript once this is all finally working. The ReadyWeapon snippet looks very interesting!

Just wondering: how is it planned for a user to interface with zcc (or whatever the compiler may be called)? Will it be entirely builtin (automatic compilation on startup) or will it also feature an external compiler? Actor code compilation for DECORATE is already pretty fast so I don't think startup time is really a factor.

[Major Cooke]

It'll be an internal compiler, much like the DECORATE one.

[Leonard2]

And the map is not an object in that sense.

I didn't mean it that way.
Does that mean that map data won't be made available?
I mean being able to access something like "level.mapname" could be useful.

Before even thinking about virtual functions and stuff like that the code generator needs to get working, and that's what I am currently at, and before that isn't done I won't waste any thought about how to hook it all in later. The goal clearly is to extend classes via scripting, but you have to be aware that in order to extend a class this class needs to be set up to be extended. ZScript won't be the magic wand to solve all problems, and in order to hook into some subsystems they will need quite a bit of refactoring first.

I know that.
You asked to discuss upcoming features so I thought this could have been interesting.

[Graf Zahl]

Of course you will get access to the map data. But since the map is not an object and especially not a thinker it doesn't have any real means to do stuff on its own. But it's completely open what features you may get. It's far too early to say.

[Major Cooke]

create proper variable data from the function prototype instead of assuming that there's just 3 pointers.

I forgot to ask, for pointers, is the cast type "Actor" or is there some other means to setting up a pointer for zscript?

[Graf Zahl]

The cast is whatever class type you want it to point to.