When it's done. Sorry, I can't give you even a hint at a deadline.Nash wrote:2 questions:
1) How soon will this be functional and ready for modders to test?
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"?
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.
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.If it's not far off, I will not waste my time typing any more ACS because enough is enough.
That's very advanced. Ultimately it should be possible but this will require quite extensive hooks into the engine to work.Player701 wrote:And not even with the new scripting features too?randi wrote:Not with decorate.
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.Leonard2 wrote: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?
Face it, most actions these functions do are on the player, not the weapon.
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.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.Graf Zahl wrote: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.
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.All I can see is that it's exactly like the decorate syntax except you put semicolons at the end of frames.
How does that work?Graf Zahl wrote: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.
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.
A const's type can be deduced from the value. No need to specify it.Another thing is const variables declaration.
Why have this:when we have this:
Code: Select all
const myconst = 99;Why the inconsistency? Isn't const supposed to be a qualifier?
Code: Select all
int myint = 99;
It just doesn't make sense to me.
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.AFAIK zscript would be capable of it but some internal changes to allow it would be needed.Nash wrote:Are we still going to get that low-level Thinker access that was promised by Doomscript
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.
[/quote]I seriously hope not.Nash wrote:or is this just "DECORATE but better"?
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.
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.