Ask about ACS, DECORATE, ZScript, or any other scripting questions here!
Moderator:GZDoom Developers
Forum rules
Before asking on how to use a ZDoom feature, read the ZDoom wiki first. If you still don't understand how to use a feature, then ask here.
Please bear in mind that the people helping you do not automatically know how much you know. You may be asked to upload your project file to look at. Don't be afraid to ask questions about what things mean, but also please be patient with the people trying to help you. (And helpers, please be patient with the person you're trying to help!)
@Fishy: I already asked this. See the first few posts on page 6.
Graf Zahl wrote: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.
Ah, so strings aren't doable just yet? Meh I'm not worried. I'm just stoked that it's almost ready for the first release!
Can you post examples of all the features we can use, when ready? I would like to implement this into the wiki for everyone's ease of access.
Last edited by Major Cooke on Sun Oct 23, 2016 8:51 am, edited 2 times in total.
No. Strings are not working yet. They were not part of DECORATE and need quite a bit of work throughout the code. But I'd rather wait with that until I have something testable.
Features you can use:
- class pointers. I already added 'target', 'master' and 'tracer' to the list of exported member fields and you can freely use them, access fields and functions through them.
- Define your own functions. Be aware, though, that this is not finished yet and won't get finished for the merge. Right you cannot use optional parameters with them.
- Local variables are also fully functional as long as they have a type that is supported.
- Switch/Case blocks.
What is not working yet:
- virtual functions
- strings
- unsigned integers
- optional arguments to script functions
- full export of all classes and symbols. I will do them on a need-to-have basis to port the existing internal action functions from the g_* directories.
- there may be a few rough edges here and there where the code is not completely done yet.
Graf's Commit wrote:These are separate blocks in different files that get concatenated to one class body for processing. The reason is to allow spreading the many functions in Actor over multiple files, so that they remain manageable. For example, all the Doom action functions should be in their respective files, but their symbols need to be in Actor. To extend a class, both files need to be in the same translation unit, so it won't allow user-side extension of internal classes.
Or is that just for internal things like the Doom functions?
We'll see. Adding new functions to Actor is not the big problem, that surely can be changed. What you won't be able to do is add new variables to native classes. Since all subclasses would inherit them, this would badly clash with internally derived classes which depend on the compile-time layout.
Almost there. I just added handling for struct members inside classes so the position and velocity members can be accessed properly now.
Before merging back I'd like to add bit access instructions so that the flags can be done as regular member variables and avoid the error prone bit masking madness that has caused enough problems in the past.
How you manage to not suffer burnout or 'writer's block' is quite fascinating I must say. Or if you do suffer through it, how you push past it is beyond me. But I suppose when you do this for 20+ years you learn a bunch of tricks, aye?
I take it the flag setting and clearing will remain the same then, syntax-wise?
Yes, I unconditionally prepend the 'b'. I don't want to run into a situation where the name clashes with anything and marking them as 'boolean' this way effectively prevents that.
Yes, A_ChangeFlag will be deprecated, it has no purpose when they are directly accessible, not to mention that it's magnitudes slower.
There is one thing that I always wanted to change about them: make them represented internally by a number. When we set a flag, we increment its value by one, unset -- decrement it by one. A flag is considered set if its value is > 0. Why? For example, a player may be made flying through a flag set directly into class definition, a powerup or A_ChangeFlag(). When we only ever set a flag there are no problems. However, when we are about to unset it, there is a possibility of clash, so if a class was already flying, it could inadvertently lose this ability even if we didn't actually wanted to do that. We could write some logic to prevent such a case, for example, by remembering if the class was already flying and excluding unsetting the flag later, however, it requires quite some effort. Where do we remember it? In an user variable? Well, we gotta add it then to all actors. ACS? Requires usage of ACS, something I'd rather to avoid unless it's the only way, and can't really remember an arbitrary amount of actors. Also, what if an additional instance of the flying ability is run on the same actor? When the first expires, it will unset the flag because it wasn't present at the time of application, thus all subsequent will malfunction. Etc, etc, there are many other issues. Using a counter instead of a boolean should solve all of this nicely. It could be also used to achieve special effects like "immunity" to a flag by directly setting its counter to a negative value, or always enabled by setting it to a positive; for example, a monster completely immune to the "frightened" state no matter what. And, I suppose custom flags are planned, so modders can desing their own flags like "stunned" and some enemies like bosses immune to stuns.