How to deal with weapon action function in scripting

[Graf Zahl]

2 questions:

1) How soon will this be functional and ready for modders to test?

When it's done. Sorry, I can't give you even a hint at a deadline.

[quote}
2) What kind of modifications will this system allow? Are we still going to get that low-level Thinker access that was promised by Doomscript, or is this just "DECORATE but better"?
[/quote]

Ideally you should be able to inherit from an internal class and override any of its methods, i.e. it should work as a full extension of the native engine code.

If it's not far off, I will not waste my time typing any more ACS because enough is enough.

Don't expect miracles. The full feature set is a long time off. First results may come earlier but they'll inevitably be a bit limited.

Not with decorate.

And not even with the new scripting features too?

That's very advanced. Ultimately it should be possible but this will require quite extensive hooks into the engine to work.

Now I think your solution is good, one thing however:
I get that the arguments can't be swapped internally as the function will be called with the same pointers etc, but can they be switched in the context?

We'll see how they will get ordered. The problem is when I swap them it will inevitably confuse a lot of people because weapon actions have always been running in the context of the owner, not the item. And there's just too much risk to break something unforeseen here if it gets changed.

Face it, most actions these functions do are on the player, not the weapon.

The scripting language won't allow a goto, it also won't allow A_Jump constructs, but real script syntax instead. In this area the main objective will be: no stopgap measures. Period.

That really sounded exciting for me, I thought perhaps you would have come up with a new state syntax/grammar that would solve the problem of virtual goto jumps (even if it needs to have the internal state system to be extended) and allow some crazy stuff such as dynamic tic duration (calculated per-frame of course and maybe even have a way to use a boolean condition that is evaluated each tic to determine if the frame is still on or if it should go to the next one) and maybe even a dynamic sprite/frame selection that would be flexible enough to allow to do things like "####" or "----" on our own but I see none of that in the scripting branch.

The state syntax won't change, except for a few semicolons for structuring. But if you write actual code, most of these kludges won't be necessary. Of course, if you just define an actor without any functions, A_Jump and state gotos will just remain as they are - after all this has to work with the same rules on the same data which imposes some limitations.

All I can see is that it's exactly like the decorate syntax except you put semicolons at the end of frames.

but it'll be a bit more like Java where you only have objects and don't need to think about the difference between an actual object and a pointer referencing it.

How does that work?
Quick example, let's say I have 2 classes 'X' and 'Y' in which I have a "mystruct" member.
If mystruct was a pointer, I would have only one actual object and any change made to it would be noticeable by both X and Y.
If it's not a pointer then I would have 2 objects and I would need to make the change to both classes's mystruct member.
That sounds like a terrible limitation.

For this you have to define the shared object as a class, but you have to figure out yourself how to attach this to all your actors.

Another thing is const variables declaration.
Why have this:

Code: Select all

const myconst = 99;

when we have this:

Code: Select all

int myint = 99;

Why the inconsistency? Isn't const supposed to be a qualifier?
It just doesn't make sense to me.

A const's type can be deduced from the value. No need to specify it.

Are we still going to get that low-level Thinker access that was promised by Doomscript

AFAIK zscript would be capable of it but some internal changes to allow it would be needed.
The actor class could inherit from an abstract thinker class in which some pure virtual functions like "Tick" are declared.
The actor class's tick function would just map to the native/internal AActor::Tick() in zdoom.
That would allow people to make some interesting stuff I'm sure.

To allow virtual overrides a lot of work on the interface will be necessary so that all calls are automatically rerouted. But this should be done outside the C++ class hierarchy, because otherwise it'd end up in total chaos.

or is this just "DECORATE but better"?

I seriously hope not.
We waited more than ten years and so many stuff was promised to be fixed/made better with zscript.
That would honestly be the BIGGEST let down ever for me.

[/quote]

Heh! Nash is close to a panic attack again...
If this was 'DECORATE just better' I wouldnt bother. But in order to get this going, 'DECORATE just better' is the necessary first step.

[Marrub]

A const's type can be deduced from the value. No need to specify it.

I don't know how much I like that. Reminds me too much of B.
EDIT: To further elaborate, I really do not think this is a good idea, unless you can specify the type optionally. Deductions like "const a = 2.5 + 2.5" might not be great if you want "a" to be an integer.

[Kinsie]

I'm not much of a programmer so my word doesn't have much weight, but implied types, even if just for consts, seems like a strange choice in a system that's attempting to be stricter than the systems before it.

[Graf Zahl]

A constant will always morph into the necessary type - since it is a constant value it can always be dealt with appropriately. If you use 1 in an unsigned context, it'll be an unsigned 1, if you use it i a signed context it'll be a signed 1 - not that it matters much with a constant. Essentially we only have 3 types a number can be: signed 32 bit integer, unsigned 32 bit integer and double. (That is, after I ditched the idea of auto-sizing ints and enums to the smallest possible type, which indeed is quite pointless.)

[Graf Zahl]

A const's type can be deduced from the value. No need to specify it.

I don't know how much I like that. Reminds me too much of B.
EDIT: To further elaborate, I really do not think this is a good idea, unless you can specify the type optionally. Deductions like "const a = 2.5 + 2.5" might not be great if you want "a" to be an integer.

Even in C you'd have to add a type cast for that - which is precisely what you'd need to do here.

[Ryan Cordell]

A constant will always morph into the necessary type

Well, if it's implied then sure, that's a given. The point is we want to avoid having types be implied in the first place though.

[Marrub]

A const's type can be deduced from the value. No need to specify it.

I don't know how much I like that. Reminds me too much of B.
EDIT: To further elaborate, I really do not think this is a good idea, unless you can specify the type optionally. Deductions like "const a = 2.5 + 2.5" might not be great if you want "a" to be an integer.

Even in C you'd have to add a type cast for that - which is precisely what you'd need to do here.

I feel it has more to do with implicated types not being explicit enough. Which is a really obvious statement.
My issue is that not being able to explicitly define the type of a constant just ends up confusing, and not what I'm used to.

[Graf Zahl]

I'm not going to change it because it'd mean changing the innards of the compiler code which Randi wrote a long time ago. The constant evaluator was one of the few things that already worked when I started on this last week. I also think you are making a mountain out of a molehill. If you want a floating point constants, just add '.0', but forcing a small numbered integer to be signed or unsigned is not going to make any difference. The signedness code hasn't even been written yet, and it will be done in a way that treats a constant's sign as indeterminate unless it is clear from the given number (i.e. -1 will be signed, 0x80000000 will be unsigned and if you use a constant of 1 with another value in an operation, the constant's sign will not be factored into the final decision whether to make the operation signed or unsigned. The other variable will do that all on its own in such a case.

[Marrub]

That's fair as can be.
On another note, is there a bytecode interface for the VM? I think it would be both practical and very nice to have such a thing for alternate languages/compilers to use.

[Graf Zahl]

The VM needs code that's compiled at run time because it very much depends on pointers to internal objects being compiled into the bytecode. So if you want to plug in another language you'll have to embed that language completely into ZDoom.

[Ryan Cordell]

How long until that comes back to bite y'all in the butt, I wonder.

[Graf Zahl]

What do you mean?

[Leonard2]

A const's type can be deduced from the value. No need to specify it.

My main point was about inconsistency which will ultimately end up confusing people no matter what.
Either have type deduction everywhere or nowhere.

I'm not going to change it because it'd mean changing the innards of the compiler code which Randi wrote a long time ago.

Oh come on this isn't DECORATE anymore. I don't want to see the "it's too late to do anything" mentality that made us wait for zscript in the first place.
Can it at least be optional, I would hate not being able to specify the type in a const declaration. Just... why????

For this you have to define the shared object as a class, but you have to figure out yourself how to attach this to all your actors.

So say I want to have a pointer to an int, would I have to define a "myintpointer" class that I would then need to use instead?

We'll see how they will get ordered. The problem is when I swap them it will inevitably confuse a lot of people because weapon actions have always been running in the context of the owner, not the item. And there's just too much risk to break something unforeseen here if it gets changed.

Face it, most actions these functions do are on the player, not the weapon.

The same point about inconsistency can be made here.
The "this" pointer or whatever you call it is always of the method's class type everywhere even by principle (from C++) so having it different to 2 specific classes is what would confuse people as they would assume the rule also applies here.

[Graf Zahl]

A const's type can be deduced from the value. No need to specify it.

My main point was about inconsistency which will ultimately end up confusing people no matter what.
Either have type deduction everywhere or nowhere.

We cannot have type deduction everywhere because the VM needs to work on typed C++ data. Automatic type deduction for local variables also increases the amount of errors that cannot be found during compilation quite significantly, deferring a lot of problems to run time. It also makes the code generator more complex because it needs to track a lot more info.

On the other hand, a constant is literally just a name for a number literal, nothing more, nothing less. There is nothing about the value 1 that says it's signed or not. It's completely irrelevant. Even if you forced a type upon it, that type would just as much be ignored when making decisions how to proceed than it would be without a type, as long as the value is compatible with the other operand. There's just no difference between 'const int blah = 1;' and 'const uint blah = 1;'

I'm not going to change it because it'd mean changing the innards of the compiler code which Randi wrote a long time ago.

Oh come on this isn't DECORATE anymore. I don't want to see the "it's too late to do anything" mentality that made us wait for zscript in the first place.
Can it at least be optional, I would hate not being able to specify the type in a const declaration. Just... why????

I'll leave the answer to Randi, because this decision was made before I started work on that code. Of course I could add a bit of syntax to allow 'const int blah' but ultimately I'd just throw it away right in the parser because the constant system as implemented makes no use of it. Actually it gives constants a type 'intauto' which means, 'decide when necessary'.

For this you have to define the shared object as a class, but you have to figure out yourself how to attach this to all your actors.

So say I want to have a pointer to an int, would I have to define a "myintpointer" class that I would then need to use instead?

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.

The same point about inconsistency can be made here.
The "this" pointer or whatever you call it is always of the method's class type everywhere even by principle (from C++) so having it different to 2 specific classes is what would confuse people as they would assume the rule also applies here.

I know that it's not perfect, but every other approach would make things A LOT worse. 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.

[randi]

Deductions like "const a = 2.5 + 2.5" might not be great if you want "a" to be an integer.

Code: Select all

const a = int(2.5 + 2.5); 

Boom! It's an int.