ZScript Documentation

[Major Cooke]

I'm already starting to see some questions and answers becoming lost in the annals of the ZScript Discussion thread, so I'm starting this up to help keep questions related to how X/Y/ZED works here, and to talk about current documentation accuracy.

THE BIG FAT LINK TO ZSCRIPT'S DOCUMENTATION EVERYONE WANTS is still under construction.

All contributions and examples of code for this would be greatly appreciated since flying solo on this is quite difficult. Not to mention my knowledge on how a bunch of this stuff works is limited.

[Nash]

IMO, there needs to be newbie-friendly topics on the ZDoom wiki that explain the more mundane, core/fundamental things of ZScript.

For example, a newbie would have absolutely zero clue what all this "casting" business is. The concept of types. Structs. Etc.

Basic programming topics need to be explained eventually, otherwise the documentation will just end up looking useful to only people who know what they're doing... and new people would be intimidated and look away from even trying to learn ZScript.

[Major Cooke]

To be fair, Graf did suggest learning an actual programming language first before tackling ZScript. The idea behind it all is, you know the basic fundamentals behind programming at the very least.

Decorate wound up the same way, only it's not nearly as flexible as zscript currently is. There's tons of sites to learn these things on, I feel we only need tobe responsible with clarifying how it's different and how to use it.

[Kinsie]

To be fair, Graf did suggest learning an actual programming language first before tackling ZScript. The idea behind it all is, you know the basic fundamentals behind programming at the very least.

So, what's the point of this whole endeavour, then? If this feature is primarily aimed at people who know Real Big Boy Programming, wouldn't they just get better results from editing the engine source code to get what they want with less restrictions?

Some information on the necessary basic concepts to get a loose grasp on ZScript - or some well-curated links to more professional guides to such concepts - will stop the same "WHATS A STRUCTS"-tier questions from being asked over, and over, and over again. Probably by me. Almost certainly by me.

[Major Cooke]

Which is why I linked some handy pages on the wiki, and even did a simple example.

Does that help?

Bear in mind I'm still trying to figure out how to do ZScript at the same time so things are going pretty slow right now. I want to make sure I'm doing them right. But anyone's free to jump in on this if they know what they're doing.

[Nash]

To be fair, Graf did suggest learning an actual programming language first before tackling ZScript.

Sure, but if you look at the already-existing ACS pages... there's a lot written about programming fundamentals there, too. What are arrays, what are libraries. What are ints. Etc etc. The ZDoom wiki didn't tell anyone to "go learn C first before trying ACS". :P

[Major Cooke]

I learned how to do ACS just by opening up other ACS scripts and practicing them based on that, truthfully. I didn't do any C++ programming for that at all before.

[Rachael]

Well just think of ZScript as amped up ACS on steroids, then - except instead of manipulating maps, it manipulates objects, instead.

Learning ACS isn't that bad of a starting place to learn ZScript, anyhow, though obviously a lot of the grammar and subjects are going to be different.

[Ed the Bat]

With that mentality Eruanna mentioned, I've been steadily working on migrating my ACS libraries into ZScript. I keep hitting roadblocks, though. I'm not sure which ones are because x feature doesn't exist in ZScript, and which are because, when it comes to legitimate programming, I'm blind as a... well, anyway...

It's getting to the point where I'm queuing up a lot of 'How to' questions, and I feel like I should just begin firing them off sometime soon, lest I descend further into confusion.

[Rachael]

Maybe that might be best. How-do-I's are actually the best starting point for documentation - because documentation can easily expand out from the answers to those questions even if they have nothing to do with them.

[Major Cooke]

Yeah, look at what I've done. Spitting out how-to questions left and right with Graf answering them. The sooner you do, the sooner graf answers, and the sooner more documentation crops up.

[Ed the Bat]

That being said, since ZScript is still not entirely official, should such questions be kept separate from the long-running "How do I...?" thread? Should they go in ZScript Discussion? Or perhaps just their own threads (my usual approach so as not to get lost in a heavily-trafficked thread)?

[Rachael]

I think the how do i thread is a bit too spammy. I may be wrong but I think they'd be better off here.

[Ed the Bat]

In that case, I may as well let out the one that's keep me up tonight...
I want to make use of arrays of strings and ints, the way I did in my ACS library. As I blindly fumble around, the one method I've got that works to any extent is to put these arrays inside a single function, as static const's. However, they've already grown to a size where I can't load ZDoom, triggering the error, "Register limit exceeded in [actor name].[function name]"

I know what I'm doing is surely not the proper way to do it, but I've so far not discovered the 'right' way. Does anyone have advice?

[Major Cooke]

Post the code of your zscript and ACS for comparison. And I agree, zscript questions aught to be kept here/discussion.