ZScript Documentation

[Ed the Bat]

I'll get back to you on that. I'll need some time to keep it clean of any specific content I'm not comfortable with making public...

[Major Cooke]

Is it because of the array sizes or the function parameters?

[Ed the Bat]

It's the size and the number of arrays. That's the only thing that changed inside this function between running the game and tripping this error. As my code sits right now, I can comment out one of these arrays (as well as any commands that rely on its existence), and the game will launch.

[Major Cooke]

You might be able to get away with having a second struct or something handling it. At this point I'm guessing until you post an example.

[Ed the Bat]

If you can show me a way to make structs hold arrays of strings, I would be delighted. Nothing I've tried has worked. Granted, this syntax is absolutely foreign to me, so it's entirely guesswork. But yes, I can try packaging some 'bad' code of mine for examination...

[Major Cooke]

Code: Select all

struct MyStruct
{
    static const String MyConstantArrayOfStrings[] = //Requires initialization assignment.
    {
        "This is one string",
        "This is another"
    };

    String MyLocalArrayOfStrings[4]; // No initialization assignment here. Must be when declared, not defined.
}

Then, inside the class somewhere, wherever you need it:

Code: Select all

MyStruct holder;
holder.MyLocalArrayOfStrings[0] = "I'm setting the index of 0 to have this string!";

Does that help?

You can also give it functions to perform in a struct itself.

Bear in mind you cannot give initialized strings right off the bat to local variables. Constants on the other hand are the opposite -- you must assign them immediately upon declaration. Another thing, there are differences between strings and names. I can give you some guidance on what you want to use based on what you're doing, but I need something or some idea what you're putting into those arrays. Strings can be slow, and they're case sensitive unless you use the ~== which is a comparison done without sensitivity.

[Ed the Bat]

I tried that. When I try to declare "static const String <name>[]=" inside a struct, or anywhere that isn't inside a function, I get the error, "Unexpected 'const'"

[Major Cooke]

Ooooh, I see now. That's because you need to define those inside functions. Graf's having some issues dealing with constant arrays and storing them properly, or something. But please do elaborate more on what you're doing precisely. You could probably optimize this if you're putting things like actor names inside of them by using Class<Actor> as the type instead.

[Ed the Bat]

Ok, so I guess I was on the right track on where to put them... but mine are clearly too large to fit together, lest I trip the register limit.

As for what you said about guidance based on what I'm specifically doing, I'll take any advice I can get, but I feel that would be best left to private discussion, rather than openly in a thread; especially one as important as this one. For right now, though, my arrays are indeed actor names, but I was running into a lot of roadblocks until I had the array list them as strings instead of names, classes, etc. Thanks in no small part, I'm guessing, to the fact that many of these actors are PWAD specific and will never be guaranteed to actually exist when my project is run.

[Major Cooke]

For that I suggest you wait on this. Should Graf implement the ability to use based on different mods and/or expand things dynamically, that would solve our problems.

But if you still wish to go ahead, what I suggest you do is split them all up into different structs based on what they're for and what purpose they serve. String concatenations are done with .. (two dots). Could use one struct to modify them all and perform the functionality.

Code: Select all

// Assemble the arrays only if we succeed. This first array
// contains the actor's hard names.
static const Class<Actor> KeyName[] =
{
    "D4RedCard",
    "D4YellowCard",
    "D4BlueCard",
    "D4RedSkull",
    "D4YellowSkull",
    "D4BlueSkull"
};

// Contains the nice names for logging.
static const String NiceKeyName[] =
{
    "Red Card",
    "Yellow Card",
    "Blue Card",
    "Red Skull",
    "Yellow Skull",
    "Blue Skull"
};

// In the event someone decides to screw with the keys, check the base class.
for (int index = 0; index < 6; index++)
{
    if (mo.CheckClass(KeyName[index], DefPtr, true))
    {
        //Concatenate a string with .. (two periods)
        A_Log(NiceKeyName[index].." Found");
        break;
    }
}

In case you didn't know.

[Cherepoc]

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?

We wouldn't. Once you make the custom build you have to mantain it then, and keep it up to latest official build. Or you abandon it and while it will have custom features you want, it will lack any new feature/improvement the official builds will have in the future. Not to mention that, instead of just having a wad/pk3, you'll also have to distribute the custom build with your mod.
Not trying to argue your point though

[Graf Zahl]

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?

It all depends on what you want to achieve.
To do Decorate with less restrictions you should know how Decorate works, of course. You can do a lot of things without learning the fundamentals of programming

But if you want to access the full power, you will have to dig deeper. And this goes way beyond the scope of a language documentation. Read up on how C++ or Java documentation looks. They assume that the reader is familiar with the basic concepts of programming.

Now, there's two choices here: Should the Wiki link to some external but well written resources or regurgitate all the info in a less concise manner because the people writing it are not professionals? There has been so much stuff written about the subject of programming that it's basically a waste of time to write up something inferior trying to convey the same information. But no matter how you twist it: If you expect this to work without putting in some learning effort you will fail.

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.

That's something different. But it still can only be a starting point. Regardless, what I said still stands: You probably get more out of a well written Java-for-beginners tutorial if you really want to dig deeper.

[Major Cooke]

It all depends on what you want to achieve.
To do Decorate with less restrictions you should know how Decorate works, of course. You can do a lot of things without learning the fundamentals of programming

But if you want to access the full power, you will have to dig deeper. And this goes way beyond the scope of a language documentation. Read up on how C++ or Java documentation looks. They assume that the reader is familiar with the basic concepts of programming.

QFT.

Now, there's two choices here: Should the Wiki link to some external but well written resources or regurgitate all the info in a less concise manner because the people writing it are not professionals? There has been so much stuff written about the subject of programming that it's basically a waste of time to write up something inferior trying to convey the same information. But no matter how you twist it: If you expect this to work without putting in some learning effort you will fail.

The former. Big time. I think it'll keep the documentation a lot cleaner. Hence why I've been doing that from the very start.

[Kinsie]

But if you want to access the full power, you will have to dig deeper. And this goes way beyond the scope of a language documentation. Read up on how C++ or Java documentation looks. They assume that the reader is familiar with the basic concepts of programming.

Now, there's two choices here: Should the Wiki link to some external but well written resources or regurgitate all the info in a less concise manner because the people writing it are not professionals? There has been so much stuff written about the subject of programming that it's basically a waste of time to write up something inferior trying to convey the same information. But no matter how you twist it: If you expect this to work without putting in some learning effort you will fail.

I did a semester or so of Java and PHP in University. It taught me that I'm an abysmal programmer and should stay as far away from a compiler as possible. Now, I'm not gonna let that get in my way TOO much (I've managed to do some pretty reasonable ACS, against all odds), but I'm probably gonna need a few things explained to me over time, as though I were a five year old. The ACS pages do a decent job of explaining some of the necessary concepts, so the ZScript pages not doing so just seems kind of weird.

Not a big deal at the moment, all things considered. Once the chains get taken off and people start getting into the feature set in greater depth, then the documentation can be fleshed out by the better teachers among us. For now, though? At least worth the discussion.

Now, some reasonable feedback: The ZScript pages are missing a wiki category, ala [wiki]Category:DECORATE[/wiki]. Obviously not the most fatal of flaws, but it'd be nice to get everything under one roof from the ground floor, right?

There's also no sidebar links, but, well, those can wait until ZScript isn't locked behind a command-line.

[Major Cooke]

Nothing wrong with that.

As for the zscript pages missing the wiki category, well, I'm not the sharpest tool in the shed for that kind of thing. Perhaps someone can help me out with that?

I did take the opportunity to put ZScript on the front page though.