Hexen map creation, ACS troubles

[Solarn]

Okay, so I had a random idea to make a Hexen map, just to see if I can. Actually, I had the idea to make a ZDoom map, but then decided to familiarize myself with ACS using Hexen at first and then went "what the heck, I love Hexen's textures and monsters anyway, let's make a map for it."

I got the hang of polyobjects pretty easily, but scripting is a bit harder. I made a very small trial map (that I will eventually expand into a full map when I learn how to actually do stuff) that I will try things on and that I will post here to ask for everyone's help.

My first problem is such:

In the large open room after the crappy polyobject door opened by the switch behind the player start, there are six glass windows. Currently they are set to lower instantly when shot, creating the (very unconvincing) illusion of the glass breaking, but only when shot by projectile weapons. I've already gotten a basic idea of how to actually make the illusion of shattering glass more realistic with scripts from Hexen's Map01 (oh yeah, I'm going to be scavenging a LOT of basic scripts from Hexen before I learn to do my own), but before I implement it I want to know if there's any way to make the execution of the script dependant on the player's class (so the Fighter would only be able to shatter the Fighter windows and so on).

Here's the map (I know it's horrible, trust me): http://www.sendspace.com/file/pgjd7a

[Solarn]

Sorry for the double post, but I really need help. The ZDoom wiki has much less information about ACS than about DECORATE and what it has is about ZDoom's enhanced ACS as applied to Doom and nothing about Hexen. Or at least nothing that I could find.

[Gez]

Solarn said:

what it has is about ZDoom's enhanced ACS as applied to Doom and nothing about Hexen.

More precisely, applied to ZDoom. As far as that port is concerned, there's no major difference between modding for Doom and modding for Hexen.

But indeed, the ZDoom wiki is naturally geared towards modding for the latest official version of ZDoom and subsequent SVN revisions. It's not a good source for vanilla Hexen modding because by now most of functions are not present in Hexen, and some of them that do come from Hexen have been extended to work with more optional parameters.

The Doom wikia would be a good place to provide vanilla Hexen info, however it is very sparse on that subject and it mostly just says to go look at the ZDoom wiki.

You can find on the web a large text file entitled "Official Hexen Specs", compiled by someone named Ben Morris. Here's an HTML version.

[Solarn]

Gez said:

More precisely, applied to ZDoom. As far as that port is concerned, there's no major difference between modding for Doom and modding for Hexen.

Except for one large difference: as Doom doesn't normally have player classes, there's not a word on implementing them, which would be the exact information I need right now. Not even a short "Hexen player classes can't be used in ACS". The only mention they get is how to define them in DECORATE.

[Gez]

I'm not sure there is any class-dependent scripting ability in Hexen. AFAIK, all they're used for is determining which effect you get from some artifacts (flechettes, mystic ambit incants...), whether you pick up a weapon or merely get some mana from it, and they also serve as filters for map things.

[Solarn]

Gez said:

I'm not sure there is any class-dependent scripting ability in Hexen. AFAIK, all they're used for is determining which effect you get from some artifacts (flechettes, mystic ambit incants...), whether you pick up a weapon or merely get some mana from it, and they also serve as filters for map things.

I've been suspecting that, but it would have been nice to see it confirmed.

[Graf Zahl]

Gez said:

I'm not sure there is any class-dependent scripting ability in Hexen. AFAIK, all they're used for is determining which effect you get from some artifacts (flechettes, mystic ambit incants...), whether you pick up a weapon or merely get some mana from it, and they also serve as filters for map things.

Actually, there is. ACS has a PlayerClass() function and I believe Hexen made use of it.

[Solarn]

Graf Zahl said:

Actually, there is. ACS has a PlayerClass() function and I believe Hexen made use of it.

Thanks. So how would it be used to determine if a window can be broken by a certain class?

This is the current version of the map, where script 1 handles the window-breaking (although for some reason only one window on each side triggers the sound and broken glass, why is it?) and the class issue is solved in a very ugly way by placing statues in the chambers behind the other classes' windows.

http://www.sendspace.com/file/8t997s

(the format of comments in the script is directly lifted from the Hexen levels, as I found it nice and clear)

[Gez]

Solarn said:

(the format of comments in the script is directly lifted from the Hexen levels, as I found it nice and clear)

Wait. Your version of Hexen has commented scripts in it?

*Looks at map.*

Oh well, I guess you mean the comments that are generated by the decompiler... Also explains why the variable names are extremely unhelpful in the long term. Hint: don't call them "mapvarX", give them names that correspond to what they do. Once you get to a scripts lump with a hundred scripts in it and several dozen map variables, it'll be much more helpful to have "deadettins" (for example) rather than "mapvar77".


My first advice would be to renumber your tags. Write a clean script and use tags accordingly.

script 1 (int arg0, int arg1)  
{
    // arg0 is the class: 0 for fighter, 1 for cleric, 2 for mage
    // Those values correspond to the hardcoded results from PlayerClass()
    // arg1 is the side: 0 for right, 1 for left
    int i; // i for iterator.

    if (PlayerClass(PlayerNumber) == arg0)
    {
        // Tags are as such:
        // 1: fighter right window sector
        // 2: fighter left window sector
        // 3: fighter right window mapspot
        // 4: fighter left window mapspot
        // 5: cleric right window sector
        // 6: cleric left window sector
        // 7: cleric right window mapspot
        // 8: cleric left window mapspot
        // 9: mage right window sector
        // 10: mage left window sector
        // 11: mage right window mapspot
        // 12: mage left window mapspot
        Floor_LowerInstant((arg0*4 + arg1 + 1), 0, 16);
        thingsound((arg0*4 + arg1 + 3), "GlassShatter", 127);
        delay(const:1);
        i = 40;
        while(i > 0)
        {
            i--;
            Thing_ProjectileGravity((arg0*4 + arg1 + 2), random(54, 63), random(0, 255), random(10, 40), random(5, 20));
        }
    }
}

[Solarn]

Gez said:

Wait. Your version of Hexen has commented scripts in it?

*Looks at map.*

Oh well, I guess you mean the comments that are generated by the decompiler... Also explains why the variable names are extremely unhelpful in the long term. Hint: don't call them "mapvarX", give them names that correspond to what they do. Once you get to a scripts lump with a hundred scripts in it and several dozen map variables, it'll be much more helpful to have "deadettins" (for example) rather than "mapvar77".


My first advice would be to renumber your tags. Write a clean script and use tags accordingly.

script 1 (int arg0, int arg1)  
{
    // arg0 is the class: 0 for fighter, 1 for cleric, 2 for mage
    // Those values correspond to the hardcoded results from PlayerClass()
    // arg1 is the side: 0 for right, 1 for left
    int i; // i for iterator.

    if (PlayerClass(PlayerNumber) == arg0)
    {
        // Tags are as such:
        // 1: fighter right window sector
        // 2: fighter left window sector
        // 3: fighter right window mapspot
        // 4: fighter left window mapspot
        // 5: cleric right window sector
        // 6: cleric left window sector
        // 7: cleric right window mapspot
        // 8: cleric left window mapspot
        // 9: mage right window sector
        // 10: mage left window sector
        // 11: mage right window mapspot
        // 12: mage left window mapspot
        Floor_LowerInstant((arg0*4 + arg1 + 1), 0, 16);
        thingsound((arg0*4 + arg1 + 3), "GlassShatter", 127);
        delay(const:1);
        i = 40;
        while(i > 0)
        {
            i--;
            Thing_ProjectileGravity((arg0*4 + arg1 + 2), random(54, 63), random(0, 255), random(10, 40), random(5, 20));
        }
    }
}

Heh. Thanks. I was in an advanced mathematics class in high school, so naming a ton of variables and constants completely arbitrary names comes naturally to me. I'm right at home with calling everything mapvar* or var* or what have you. But it does make more sense to name them according to their function.