How to deal with weapon action function in scripting

[Major Cooke]

I take it the invoker.blah access will be available when the first iteration of zscript is merged? If so, I'll toss it up here.

And to clarify, invoker.blah means the weapon's blah variable, not the player's, correct?

[Graf Zahl]

It will be available when local variables and function parameters are working. I cannot say if this will be before or after doing the first merge.

[Leonard2]

[things about the const syntax]

Even though it might not make any difference to the engine, in the end my point about consistency still stands.
You'll have more people confused about it than people who actually want such a thing.
The first time that I read the zscript code from master (before the zscript branch itself began) and noticed that the parser was complete and could be tested with the "parse" command I immediately tested it.
The first line I fed to it was something along the lines of "const int myvar = 8;", something that decorate would allow. To me it seemed like a regression.
And to be clear, having automatic type deduction everywhere is not what I was hinting at, I would rather have NO automatic type deduction anywhere.

If you want shared data you need an external object. That has nothing to do with the design of the scripting language but with how the engine needs to handle that. If you do not use an actual Object derived class for that it's simply not reliably trackable and serializable.

Yes but the point was about getting a proper reference to that object.
So from what randi said, if I understand correctly, if I declare a class-type member in my class, it will be a reference rather than an object that is owned by my class?
And the opposite for structs, If I declare a struct-type member, it's not a reference but actually owned by the class that it is defined in?
So the limitation is still there, If I just want a pointer to an int I have to declare a "myint" class and use this. Why not just allow pointers syntax, much less complicated and much faster than that in my opinion.

Don't forget: DECORATE needs to run on the same VM and this directly affects how you define actors, even when they do not have any more complex code than a simple A_WeaponReady.

I know and that's what I said before asking what I asked. I don't think you understood what I requested.
For the sake of consistency (and as such to avoid confusion) I want the pointers to be swapped only when the code is parsed, not internally.
If I write "myvar" then it will be processed as "invoker.myvar". I thought that was fine since you're already doing fundamental changes on how these classes are handled anyways.

[Graf Zahl]

Yes but the point was about getting a proper reference to that object.
So from what randi said, if I understand correctly, if I declare a class-type member in my class, it will be a reference rather than an object that is owned by my class?
And the opposite for structs, If I declare a struct-type member, it's not a reference but actually owned by the class that it is defined in?
So the limitation is still there, If I just want a pointer to an int I have to declare a "myint" class and use this. Why not just allow pointers syntax, much less complicated and much faster than that in my opinion.

Why not pointers? For the simple reason that they are the biggest can of worms that can be done in a scripting language maybe?
Let's be clear. Pointers are bad - that is, unless you do system programming. They have no place in scripting. By prohibiting them you eliminate a vast amount of potential stability issues right out of the box.
The VM could actually support having an int pointer if it was added to the grammar. The question still is: What would you want to do with it? If you look at the internal classes you'll see that objects very, very rarely point to random unorganized data. This can not be serialized so it is basically broken by design.
Also, nice use of 'just'...

I know and that's what I said before asking what I asked. I don't think you understood what I requested.
For the sake of consistency (and as such to avoid confusion) I want the pointers to be swapped only when the code is parsed, not internally.
If I write "myvar" then it will be processed as "invoker.myvar". I thought that was fine since you're already doing fundamental changes on how these classes are handled anyways.

[/quote]

The main issue would be that even for putting a code pointer on a state line it'd completely change the semantics if these were swapped around. I'd rather be consistent in a non-optimal way than having to create something contradictory to itself.

You have to remember: A weapon can run non-weapon functions, and for those the player has to be 'self'. If the semantics are changed to make the weapon 'self' for special weapon functions and the player for everything else it becomes far too confusing. I think the little rule breaking with self is preferable in such a case, at least the semantics are the same.

[Major Cooke]

That reminds me of some questions, Graf:
1. What will be done about the target/master/tracer?
2. Will we be able to have more than three actors we can access besides those three?
3. Is it planned for the ability to read things from them directly such as their health/position coordinates/radius/height/etc?

[Graf Zahl]

1. target/master/tracer are regular instance variables, you will be able to access them just like health, mass and radius.
2. And of course you can declare new pointers to other objects if you need some.
3. Most definitely.

[Major Cooke]

What about making variables (both custom and main) readable and writable by outsider classes? Will we be able to restrict some internal variables on actors such as some being able to manipulate velocities while others cannot, directly? (I.e. one actor allows modifying of its velx/y/z, another does not)

Since a lot of functions can change other actors aside themselves, I take it that'll be supported at some point? (I.e. A_ChangeVelocity can be used in one actor to affect another)

[Graf Zahl]

Same as C++, variables can be private, protected and public, native ones also readonly. And of course you will be able to call other functions through an actor pointer. (e.g. target.A_ChangeVelocity...)

[Major Cooke]

So would this be a valid way to do it for internal actors?

Code: Select all

Class test1 : Actor
{
	// Deny modification of positions, allow everything else.
	Default
	{
		private x;
		private y;
		private z;
	}
}

[Graf Zahl]

No. The position will be defined as 'readonly vector3 position'. And then you use position.x, position.y and position.z The existing x,y,z DECORATE variables will be marked deprecated.

[Major Cooke]

Code: Select all

Class test1 : Actor
{
	Default
	{
		readonly vector3 position;
	}
}

Wouldn't readonly mean not even the owning actor itself can manipulate it directly?
While I like that idea, I think an actual 'private' word would be good for allowing the owning actor can change it, but others cannot.

[Graf Zahl]

The position is only supposed to be changed through special native setter functions. That goes even from inside Actor itself, if parts of it get scriptified.
'Readonly' is only useful for native members and means that scripts may read but not modify them.

[Major Cooke]

Alright. I get the feeling we're going to be able to design custom functions for all sorts of purposes including custom variable retrieval:

Code: Select all

target.GetVar("mytargetsvar")

And it can be programmed by the modder to retrieve it, it appears?

[Graf Zahl]

Why not 'target.mytargetsvar'? Better forget about the DECORATE crutches. A_SetUserVar will be deprecated.

[Major Cooke]

Oh, I thought that wouldn't be doable considering custom vars and bad access... Nevermind then! I'm looking forward to it.