Trying to figure out Zscript

[Jigglysaint]

I could, except I still don't really understand zcript very well. I mean I understand the concept, but the big problem is syntax, and proper usage of each command. The examples and text I've read state what the variables are, but not explicitly how they are used.

[pkmnfrk]

But anyway, I know there are limitations and stuff. I just can't seem to get zcript and Zasm down. For some reason I am unsure how to work out all the variables. I know 6502c and a little Z80, but zasm seems to be a low level language aimed at programmers, not rom hackers. If I had an opcode list and a list of ram loations, I could go to town. Oh well, I'll keep trying tonight.

Oh, sweet...

No. Although I've not looked too much at ZASM, I can only hope there are no pointers in it. Or direct memory addressing.

Honestly, stick to ZScript for most of your code, and if you have a small, but frequently called function, you could write it in ZASM.

And, I'm not sure what you mean by "I am unsure how to work out all the variables". Zscript is pseudo object oriented, revolving around the five major classes: Link, FFC, Screen, Game and NPC. So, all your magic variables are going to be members of those objects.

Link, Screen and Game are singletons (i.e. there is only one of each, and are accessed by their class name), while FFC and NPC are instances of the FFCs and enemies on the screen, respectively.

ZScript.txt outlines the members for each class, and gives you all the information you need.

And, you can create your own variables of types int, float (which is the same as int), bool, ffc and npc. The last two are pointers to FFC and NPC classes.

So, for example:

ffc Zelda = Screen->LoadFFC(1);
Zelda->X = 16;
Zelda->Y = 16;

This snippet grabs a pointer to the first FFC, and places it at (16,16) (measured in pixels). Since we use a variable to hold the results of Screen->LoadFFC, we can reference it by name.

The clusterfuck I refer to is actually the rest of the stuff, wrapping scripts in "ffc script" blocks, which have members themselves, but oh! they can't have variables, all globals are in the global namespace.

And, no, swearing is not my last course of action. It's simply the most accurate word to describe the state of scripting.

[Jigglysaint]

Let's just use this as an example:

item script rock{
void run(int Weapon){
NPC->Weapon(18);
Game->PlaySound(51);
} // run
} // rock

The script doesn't work, which makes sense because it's wrong. The first line is fine. The second line, voidrun, I am unsure of what to do with this. After that is NPC class, which for some reason the script won't recognize. What I am trying to do is get a certain weapon value, and apparently you can only do that with the NPC class. After, I have the playsound. When most people show scripts, they use (CAPS_LOCK), but when I try to use the worded value, the script rejects it. Instead it seems to work with a number imput. Nowhere do I see any explanation to use the actual value instead of the text. That's kind of what's confusing me.

[Joe123]

*sigh*
I'm afraid you can't just say:
Here's an Item Script ZC, I said something about NPC rock weapons, therefore you should shoot one for me!

What you've said is:

item script rock{ //start script
	void run(int Weapon){ //start void run
		NPC->Weapon(18);
		Game->PlaySound(51);
	} //end void run
}// end script

And how ZQuest reads that is:

This script is an item script, so put it in the 'item' compile menu.
	Run command for the script (loading an integer called weapon)
		Find the enemy that you've previously loaded called 'NPC', and set it's weapon to (18)
		Play the Sound effect number 51
	End the run command
End the script.

[pkmnfrk]

A few things:

- ZScript is case sensitive.

- a function looks like this:

type function-name ( [type param1 [, ...]] ) {
  contents of function
  //if function requires a return value, then you must use return(...) at some point
}

The first type is the the type that the function returns.

- void is a special type, and can only be used as a return type. It means "I don't return anything"

- NPC->Weapon(18) doesn't work because zscript is looking for a variable called "NPC", and can't find one.

- npc->Weapon(18) doesn't work because you're trying to call a function using a base type. Doesn't work for the same reason "int->Weapon(18)" doesn't work.

- You should create a variable to hold the NPC in, like this:

npc myenemy;
myenemy = Screen->CreateNPC(NPC_SHOOTROCK)

- But, even if you do that, it still won't have a Weapon() function. You can't really force enemies to do anything in particular.

- Game->PlaySound(51) does work (but the compiler doesn't get that far);

- in std.zh, you'll see a lot of lines that look like this:

const int SFX_ROCK        = 51; // Octorok rock is fired.
const int WPN_REFROCK           = 18;

This is a constant. It means that "WPN_REFROCK" means 18, and "SFX_ROCK" means 51.

- You are strongly advised to put this line at the top of every single script file you create:

import "std.zh"

This will cause the compile to recognize all the aforementioned constants.

So, you know assembly, but not C? Odd.

[Joe123]

Beat you to it...

Yours is much better explained though =P

Anyway, something more what it should look like to make that happen would be:

bool rock = false;

item script rock{
	void run(){
		rock = true;
	}
}

ffc script rock{
	void run(){
	ffc rockshot = Screen->LoadFFC(32);
	eny1 = Screen->LoadNPC(1);
	eny2 = Screen->LoadNPC(2);
	//...
	eny10 = Screen->LoadNPC(10);
		while(true){
			if(Abs(eny1->X - rockshot->X) < 8 && Abs(repeat for y){
				eny1->HP -= 1;
			}
			//repeat for other NPCs
			if(rock){
				rockshot->X = Link->X;
				rockshot->Y = Link->Y;
				if(Link->Dir == DIR_DOWN){
					rockshot->Vy = 1;
				}
				//...
				if(Link->Dir == DIR_RIGHT){
					rockshot->Vx = 1;
				}
			Game->PlaySound(51);
			rock = false;
			}
		Waitframe();
		}
	}
}

Which is an ffc weapon.
Don't try to use it as is, it's just a bit of a template.

I should explain each step actaully.
Meh.
I will do if you want in a minute.

[Jigglysaint]

Yeah. The main reason I learned assembly is just so I can hack roms. I don't know anything about C unfortunatly.

So I hope that helps me out a bit. I'll see if I can get somthing to work.

Edit: So basically what I would eventually want to do is to make a FFC appear on a button press, which in turn also fires the weapon? Yeah, that is complicated.

Now as for spacing and stuff. I notice that each line is indented by 1 space as it goes down. Is that manditory, or is it just for organization?

Either way I am not familar with C, so I don't know how everything works. When I learned ASM, I actually didn't understand for the longest time. Then somebody explained RAM, and it's interaction with the opcodes and things fell into place. I am sure once I start understanding things, everything will fall into place.

[Mega Link]

Now as for spacing and stuff. I notice that each line is indented by 1 space as it goes down. Is that manditory, or is it just for organization?

Organization.

[Joe123]

Edit: So basically what I would eventually want to do is to make a FFC appear on a button press, which in turn also fires the weapon? Yeah, that is complicated.

Well, that's only the half of it.

The best part is, that you have to get the script to load every single NPC on every single f*cking screen you want the weapon to work on, and then check every frame if they're close enough to the ffc to take damage, and then damage them.

That's what this bit does:

			if(Abs(eny1->X - rockshot->X) < 8 && Abs(repeat for y){
				eny1->HP -= 1;
			}

Now as for spacing and stuff. I notice that each line is indented by 1 space as it goes down. Is that manditory, or is it just for organization?

It isn't manditory per se, but if you don't do it then
A) your scripts will be hard for you to read and
B) noone else will have even the slightest chance.
Also, for the love of God, use 'tab' to indent and not a series of different numbers of space-bars.
Tab is so much simpler.

Anyway, indenting allows you to see what levels the script works on, which is why it's used.

The first level (in the ffc script one) is the script-wide, the second one encloses only the run command, the third one is for things only within the while loop, and then there are ifs at various levels.
It's more like a tier system than just 'every line gets indented as you go down'.
As you'll see, once you're inside the while loop, there are quite a few ifs on the same tier.

EDIT: Oh wow, you beat me to it MegaLink.
I didn't realise =P

[Jigglysaint]

Okay so making weapons is harder than I think it should be. Sheesh, all I want is to make a wand like the one in an early pre-2:10 beta that had the wand fire reflected fireballs that homed in on it's target. I wasn't looking to make anything more complicated that to just change the behaviour of projectile weapons.

I guess ZC still isn't advanced enough yet. Still, there should still be lots to do. Right now I want to create a new itemclass, but I am not sure how to do it.