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!)
Illasera wrote:
Your first two arguments would probably hold more water if zscript could store and load compiled data and not compile things at runtime.
A memset by its very design is dangerous. First, classes are being constructed, so you cannot memset them, it would clobber the internal data.
That leaves local variables - and stack is always zeroed before being used.
To sum it up: There is no need to memset, it would be a scripter's choice if done, but since memset doesn't have even the slightest sanity checks it's simply not going to happen.
Got a couple of broad conceptual questions, since for some reason I've got some knowledge gaps:
What precisely causes the "ambiguous context pointer" error to be thrown? There's inevitably an extremely-obvious pattern here that I'm missing.
What precisely is the 'Name' datatype? Names and Strings seem to be almost interchangeable, but I'd rather use the correct types in code, even if it's nitpicky. Trying to avoid Javascript-esque "use whatever quotation marks you feel like" habits.
For the second ones, Names aren't case-sensitive, so they are often used for stuff like class names (think stuff like if (actor is "someclassname")), and lump names (when applicable, such as creating a font variable). This also means that the case-insenstitive string comparison operator (~==) won't work, since there isn't any point to it on a Name.
Xaser wrote:What precisely is the 'Name' datatype?
Internally a name is an index to a string table, so a name is a lightweight variable. That means that they're much faster than strings for whenever you've got tons of comparisons to make.
Time for another question, Any support for C standard library math functions via callbacks on zscript? (sqrt, log and friends)
that should be safe to add i believe, I am talking about callbacks in zscript that are directly linked to the c standard library under gzdoom.
If so, how do i access them? if there is a wiki page on it? i did look for it , couldn't find it, do i access it as i would with a normal c function?
i can write them myself under zscript if they do not exist as of yet but i am afraid the overhead will be too great if i am to use them in a recursive manner,
some of them can be really expansive (Due to lack of optimization and prefetching), specially when handling functions that use division operator a lot (For those who don't know, dividing stuff , both integers and floating points can be very expansive on the x86 family of hardware, can span up to hundrads of cycles (SIMD excluded) not taking into account cache misses, but that's another topic).
As far as having a scripter writing them in zscript, Such functions do go through a lot of optimization under most C standard libraries, hence their version is better. a direct callback is preferable.
Thanks in advance for any answer towards the question above.
Gez wrote:Internally a name is an index to a string table, so a name is a lightweight variable. That means that they're much faster than strings for whenever you've got tons of comparisons to make.
Hmm, interesting -- presumably then, it'd also be the datatype to use for static strings in Default blocks (e.g. RenderStyle 'Add') and the like?
I'm mostly just worried about some scenario where I'm supplying type 'x' and it has to spend time internally converting to type 'y', unless the ZScript interpreter is doing this once-and-done on startup in some places. Molehills, I'm sure, but it's always good to know.
Gez wrote:Internally a name is an index to a string table, so a name is a lightweight variable. That means that they're much faster than strings for whenever you've got tons of comparisons to make.
Hmm, interesting -- presumably then, it'd also be the datatype to use for static strings in Default blocks (e.g. RenderStyle 'Add') and the like?
No. The render style is just translated to an actual style value. The string notation comes from a time when it couldn't be done with a symbolic constant, but why change it if it ain't broke.?
Hmm, that one certainly falls in the "doesn't matter" camp, then. Maybe a better example would be something like Inventory.Icon -- since I'm not going to be doing any manipulation of the value, is this a case for a Name?
No, that's a FTextureID internally.
Damage types get stored as a name, for example, as does species, but that's really everything, aside from a few oversights in third-party submissions.
Are there any plans for making overlay states possible on monsters and other non-weapon actors? Perhaps "overlay" is a misnomer... actually I'm interested in the ability to make multiple states execute simultaneously, as with weapon actor overlays.
The secondary state(s) executing in the "background" could make something happen over time, for example.
'simultaneously' is never really simultaneous. It's actually just one piece of code right after the other.
If you want to make something else happen at the same time, you can create a thinker subclass that does things. They're very light in comparison to actors and they cannot be 'spawned' per se. They have no presence in the world itself at all.
But yes, I would actually like overlays on non-players as well for the ability to use psprites upon.
