Custom Guys

[Nightmare]

Relatively big one (and probably simple to do), can we have this feature in the next release?

-James

[Binx]

Relatively big one (and probably simple to do), can we have this feature in the next release?

-James

ALL MY YES!!!!!!!!! I've been clamoring for this feature since the 1.90 days! I hate using scripted NPCs, you can't use built in room types with them, and it really shouldn't be that hard to do.

[Zim]

What do you mean by custom guys? You mean guys with homing, halt rates, and a list of strings with % likeliness of occurrence and/or sequential strings starting at string # X for Y amount of strings and things like that?

[Binx]

Well, I don't know about Nightmare, but I'd be happy just having something that says "Make new guy", "Use CSet x" and "use tile y" and then be able to apply that to any room.

[Nightmare]

Well, I don't know about Nightmare, but I'd be happy just having something that says "Make new guy", "Use CSet x" and "use tile y" and then be able to apply that to any room.

You couldn't hit the nail on top of the head any more accurately lineas.

-James

[Zim]

So basically you're saying that 15 guys isn't enough.. gotchya.
I prefer 8 bit tiling, and the tiles for guys can be drawn over.. you just want more guy spaces.

[SUCCESSOR]

So basically you're saying that 15 guys isn't enough.. gotchya.
I prefer 8 bit tiling, and the tiles for guys can be drawn over.. you just want more guy spaces.

15? I count 10. I noticed that there is an import and export guys option. What's that about?

I think a better idea than "more guys" was something like Lineas said where instead of setting up "guys" you just assign a tile and cset like you do room type and string on a screen by screen basis.

[CJC]

15? I count 10. I noticed that there is an import and export guys option. What's that about?

I think a better idea than "more guys" was something like Lineas said where instead of setting up "guys" you just assign a tile and cset like you do room type and string on a screen by screen basis.
Yeah, maybe a replacement to the current 'guy' menu, using a check box to determine whether or not the room has a 'guy' (or radio buttons for None, Guy, and Fairy), a tile selection, a CSet selection, and X,Y coordinates at which the Guy should be spawned.


The first determines whether the top half of the screen is restricted from movement. The tile selection and CSet are for aesthetics, and finally the coordinates would let quest creators place the guy anywhere on screen, rather than perfectly in center (many of the 'invisible guy' tricks of the older versions were done simply to place the guy at a different spot on-screen).

[Zim]

Some folks put a lot of effort into assuring that ZC is capable of doing these things without modifying ZC every time a user has a request for things it is capable of.
I made a guesstimate, because I never thought I'd use a 'guy', so I did not.
Filling out a script is in no way less or more complicated than checking a box and writing it there.
Learn Scripting, you'd love it.
Either ZC & ZQ takes more memory on your system, which costs all the people who don't use this feature you're proposing, potentially slows down their overall download time, etc. or your own quest file takes up a slightly more amount of memory by you utilizing the features already implemented after years of work.
You're asking that functions that were wrote down years ago be menu boxed in C, which is understandable, but would inevitably slow things down for the populace since it's already doable with what we have.

[CJC]

Filling out a script is in no way less or more complicated than checking a box and writing it there.Actually it is. Many users find scripting incredibly intimidating. An in-game interface that explains both what it is doing and how it should be used is much more user friendly, especially to new quest creators that are trying to learn how to use the program.



Either ZC & ZQ takes more memory on your system, which costs all the people who don't use this feature you're proposing, potentially slows down their overall download time, etc. or your own quest file takes up a slightly more amount of memory by you utilizing the features already implemented after years of work.
You're asking that functions that were wrote down years ago be menu boxed in C, which is understandable, but would inevitably slow things down for the populace since it's already doable with what we have.
All that this feature would do is change the NPC spawn code that generates 'guys' for strings into one that references screen variables, "GuyTile, GuyCSet, and GuyType". All are already implemented in the program; an interface would just make their access more practical. In fact, it might save space in the long run because there would no longer be a need for pre-programmed guys.
By your argument, String Control Codes, Combo Solidity, Items, Enemies, and even warps should be stripped out of the system because they can also be achieved by scripting and are thus 'wasted space'.



Learn Scripting, you'd love it.Yes, advanced users should learn scripting because it gives the program much more versatility. But advanced users will not be making use of 'Guys' anyway. This is a feature for less-skilled quest makers, and any increase in file size is worth it for the accessibility.

[Saffith]

Well. This has generated a lot more discussion than I would have thought.

I'm really not sure how hard this would be. Thing is, guys are actually enemies. You ever notice that enemy IDs start at 20? The guys are 1-10. So, most likely, you'd create new guys in the enemy editor. That much is fairly easy to do.
Here's where it gets difficult: the code was written with the assumptions that guys and other enemies could be distinguished by their IDs and that guys' IDs would never be greater than 255. Neither of those would be true anymore, and I don't know how hard it would be to deal with that. It can certainly be done, but it's not trivial.

[Binx]

The argument about how we should "learn scripting" is a BS one, anyways, because maybe some of us LIKE using the built-in room types. I personally can't stand the shop script, and I LIKE being able to use the built in rooms. But, that means that i don't get to have multiple races in my games, because I can't even edit the damned COLORS of the guys. I mean, if guys are just enemies, why can't the engine assign any enemy to the "guy" spot?

EDIT: And for the record, no, 10 slots isn't enough when you CAN'T EDIT THEM. If I could do things like tell it to make Abei 2 use a different tile and CSet, I would. I personally really don't understand why two of the guys are EXACTLY THE SAME. One of those slots is Zelda, so you can't do anything there, you need the Empty, Fire and Fairy Guys, so that leaves 5 slots (Abei, Ama, Moblin, Merchant and Goriya) Tell me again how we have more than enough guys?

[Zim]

The argument about how we should "learn scripting" is a BS one, anyways, because maybe some of us LIKE using the built-in room types. I personally can't stand the shop script, and I LIKE being able to use the built in rooms. But, that means that i don't get to have multiple races in my games, because I can't even edit the damned COLORS of the guys. I mean, if guys are just enemies, why can't the engine assign any enemy to the "guy" spot?

EDIT: And for the record, no, 10 slots isn't enough when you CAN'T EDIT THEM. If I could do things like tell it to make Abei 2 use a different tile and CSet, I would. I personally really don't understand why two of the guys are EXACTLY THE SAME. One of those slots is Zelda, so you can't do anything there, you need the Empty, Fire and Fairy Guys, so that leaves 5 slots (Abei, Ama, Moblin, Merchant and Goriya) Tell me again how we have more than enough guys?

I wasn't arguing. I was merely stating that one message script and one item script would solve this for you.. It's just as much effort on your part to use 1 or 2 ffc scripts and enjoy all the freedoms they would bring to your game, and they're already done.

I already knew (at one point) that guys were NPC, in fact, summon NPC scripts can spawn "guys."
The only difference here is that.... wait a minute..
Why not just make a blank guy (no graphic) and use an invincible NPC? At that point you'd just have to fix it's coordinates (script).

[CJC]

Well. This has generated a lot more discussion than I would have thought.

I'm really not sure how hard this would be. Thing is, guys are actually enemies. You ever notice that enemy IDs start at 20? The guys are 1-10. So, most likely, you'd create new guys in the enemy editor. That much is fairly easy to do.
Here's where it gets difficult: the code was written with the assumptions that guys and other enemies could be distinguished by their IDs and that guys' IDs would never be greater than 255. Neither of those would be true anymore, and I don't know how hard it would be to deal with that. It can certainly be done, but it's not trivial.
I figured that guys were actually enemies because so many of the rules surrounding them is to make them NOT seem like enemies. Would it be easier to remove the 'guy' distinction completely and just advise players to use Walkers with no animation and insurmountable defenses, combined with an enemy placement flag?
...But that wouldn't work with strings and their fireball retaliation, would it? Or with caves for that matter. Ugh, this really is a knot made out of snakes, isn't it?


EDIT: Successor explained in chat that my suggested workaround is fundamentally no different than the current 'use none and a guy-looking combo' alternative. So I guess it's back to the drawing board.
-=SPOILER=-

[Nightmare]

I wasn't arguing. I was merely stating that one message script and one item script would solve this for you.. It's just as much effort on your part to use 1 or 2 ffc scripts and enjoy all the freedoms they would bring to your game, and they're already done.

I already knew (at one point) that guys were NPC, in fact, summon NPC scripts can spawn "guys."
The only difference here is that.... wait a minute..
Why not just make a blank guy (no graphic) and use an invincible NPC? At that point you'd just have to fix it's coordinates (script).

And someone mind putting up basic scripts or a tutorial on how to use them? I know it's C-based thank god, but I don't know which is which with the terminology.

-James

[Binx]

I wasn't arguing. I was merely stating that one message script and one item script would solve this for you.. It's just as much effort on your part to use 1 or 2 ffc scripts and enjoy all the freedoms they would bring to your game, and they're already done.

I already knew (at one point) that guys were NPC, in fact, summon NPC scripts can spawn "guys."
The only difference here is that.... wait a minute..
Why not just make a blank guy (no graphic) and use an invincible NPC? At that point you'd just have to fix it's coordinates (script).
Why, yes, I suppose I could. But I (as i have said twice already) DON'T LIKE USING SCRIPTED NPCs. So why should I have to? Guys are enemies, so why can't we edit them in the enemy editor? I mean, that alone makes no freaking sense.

And there's no "you just have to..." with people who DON'T ALREADY KNOW SCRIPTING. Maybe some people have a hard time with learning programming languages. Did you ever think of that?

EDIT: Sorry, I was being a bit short tempered. I'm better, now. But the point still stands, I don't understand why you're so resistant to the idea that we'd be able to edit the guys. Not being able to add more, I get that, because it could cause a lot of problems because of the way the engine is built, but I don't understand why we can't at least edit the tiles and Csets being used for the guys. I mean, it seems to me it would have taken EXTRA programming to tell the enemy editor to NOT allow you to edit the guys, if they're made using the same coding as enemies in the game. I mean, I'm sure you don't mean to, but you come off as though the existence of scripting is a good enough reason to stop development and improvement of the ZQuest editor in general, and that just seems totally counter-productive to the entire idea of ZC in the first place.

[SUCCESSOR]

Okay, so this isn't the perfect solution or for the script-averse but it should be very simple for anyone. Obviously you need to know how to use basic scripts.




const int GUY_CUSTOM = 9; //what "Guy" to change; refer to NPC_ constants in std_constants.zh

int guyTile; //global variables that the scripts use
int guyCSet;

//script checks for and changes the "Custom Guy"
global script ChangeGuy
{
void run()
{
int currScreen = -1; //used for checking if you have changed screens
int currDMap = -1;

while(true){
if(Game->GetCurScreen() != currScreen || Game->GetCurDMap() != currDMap){
if(Screen->NumNPCs()){
for(int i = Screen->NumNPCs(); i > 0; i--){
npc enpc = Screen->LoadNPC(i);
if(enpc->ID == GUY_CUSTOM){
enpc->OriginalTile = guyTile;
enpc->CSet = guyCSet;
}
}
currScreen = Game->GetCurScreen(); //saves current screen
currDMap = Game->GetCurDMap(); //saves current dmap
}
}
Waitframe();
} //end of while loop
} //end of run
} //end of ChangeGuy

ffc script setGuy //use on the screen with the cave entrance
{
void run(int tileNum, int csetNum)
{
guyTile = tileNum; //tile number to change the guy to
guyCSet = csetNum; //cset number...
}
}


This is the only way I can think of to have "Custom Guys" with NES Caves. All it does is change the CSet and Tile of one of the Guys (the one assigned to GUY_CUSTOM; set by default to ABEI2). You have to set the FFC script on the entrance screen and D0 to the tile number and D1 to the CSet. If you do not do this then your "Custom Guy" will change to Tile 0 on CSet 0. Also these values will not reset so if you set it on one screen and not another the same "Custom Guy" will appear as the last one visited (or Tile 0 if you haven't visited any).

Once you have compiled the scripts and assigned them to slots. Go to the screen where you want your "Custom Guy" and set it up as normal and pick ABEI2 as the Guy. Set an FFC script with a blank combo and the script setGuy. Make sure you set D0 and D1 arguments to the correct values. That's it!


Why, yes, I suppose I could. But I (as i have said twice already) DON'T LIKE USING SCRIPTED NPCs. So why should I have to? Guys are enemies, so why can't we edit them in the enemy editor? I mean, that alone makes no freaking sense.

And there's no "you just have to..." with people who DON'T ALREADY KNOW SCRIPTING. Maybe some people have a hard time with learning programming languages. Did you ever think of that?

EDIT: Sorry, I was being a bit short tempered. I'm better, now. But the point still stands, I don't understand why you're so resistant to the idea that we'd be able to edit the guys. Not being able to add more, I get that, because it could cause a lot of problems because of the way the engine is built, but I don't understand why we can't at least edit the tiles and Csets being used for the guys. I mean, it seems to me it would have taken EXTRA programming to tell the enemy editor to NOT allow you to edit the guys, if they're made using the same coding as enemies in the game. I mean, I'm sure you don't mean to, but you come off as though the existence of scripting is a good enough reason to stop development and improvement of the ZQuest editor in general, and that just seems totally counter-productive to the entire idea of ZC in the first place.

Saffith has already stated that it isn't Trivial. It didn't take extra programming to tell the program not to let you edit Guys. Guys were coded long before the enemy editor ever existed. Though the are technically Enemies the engine handles them differently enough that it isn't as simple as just letting you edit them. Your best bet until (I am just guessing) 2.6 comes out is the script I just posted.

[Binx]

Well, of course it's not something that would be available NOW, this is the suggestions forum in a thread for suggestions for future versions of ZC. And maybe I misunderstood what Saffith said, but it seemed like the statement was that making them EDITABLE was easy, it would be a problem with being able to add new guys because of how the engine handles their ID numbers. But I stand by my statement that this is a perfectly valid suggestion that probably should have been implemented a while ago. But thank you for the script, anyways. (For the record, I'd say it's about the most perfect solution we could hope for right now, because it does exactly what I'd want it to)

EDIT: Ok, i didn't see the part that said "Next release" I don't think this would be in anything before 2.6 at least because it's such a major change to the way things are currently set up. I mean, if changing the whistle warp to warp ring 8 was enough to screw up 2.1 quests, I can only imagine the kinds of problems this would cause if it was put in a 2.50 update.

[Zim]

I think 'none' & use a combo is probably the simplest workaround right now.
A code like Succesor's activated with menus on ZQ is fundamentally the easiest way to implement what you're asking for.


CreateNPCAt(1,120,80);

would spawn Guy ID #1, and not change room properties.
So..


ffc script GUY
{
void run(int a, int b, int c)
{
if(Screen->NumNPCs()>1)//actually superfluous because you already know there's an NPC on screen, and you wouldn't use this code on a screen without one.
{
npc GUY=Screen->LoadNPC(1);//Makes an assignment for the NPC, which there is only one of for now.
GUY->Tile=this->Tile; GUY->CSet=this->CSet; GUY->X=this->X; GUY->Y=this->Y; //Sets the guy's characteristics to this ffc's stuff.
}
}
}

Would set the guy at the ffc's coordinates with tile of the ffc and cset of the ffc... so that's another option. Just like Succesor's except that it uses the ffc's tile and cset. :)
The room type would be selected by the menu, so in essence this is pointless, as selecting 'none' and drawing over the guy is just as effective.

Sorry if I came across as sounding like deleting ZQ was the answer. :D

[SUCCESSOR]

A code like Succesor's activated with menus on ZQ is fundamentally the easiest way to implement what you're asking for.


CreateNPCAt(1,120,80);

would spawn Guy ID #1, and not change room properties.
So..


ffc script GUY
{
void run(int a, int b, int c)
{
if(Screen->NumNPCs()>1)//actually superfluous because you already know there's an NPC on screen, and you wouldn't use this code on a screen without one.
{
npc GUY=Screen->LoadNPC(1);//Makes an assignment for the NPC, which there is only one of for now.
GUY->Tile=this->Tile; GUY->CSet=this->CSet; GUY->X=this->X; GUY->Y=this->Y; //Sets the guy's characteristics to this ffc's stuff.
}
}
}

Would set the guy at the ffc's coordinates with tile of the ffc and cset of the ffc... so that's another option. Just like Succesor's except that it uses the ffc's tile and cset. :)
The room type would be selected by the menu, so in essence this is pointless, as selecting 'none' and drawing over the guy is just as effective.

There are a couple problems with this script. Most importantly is NES Caves recycle the same screen so FFCs aren't possible. [Actually I am not sure if FFCs can carry over from the entrance screen to an NES Cave. Even if that would be a more complicated approach.] Another thing is the fire in NES Caves are NPCs as well and I am pretty sure they spawn first and the Guy last. You can disable the fire in caves but the script doesnt account for it. You also cannot effectively write to npc->Tile. You have to use npc->OriginalTile. Also the FFC script will probably run before NPCs have spawned so checking for them will be ineffective.

I could add in values for X and Y coordinates in my script but that would take up 2 more global variables. If someone requests this I can do it easily.

[Zim]

There are a couple problems with this script. Most importantly is NES Caves recycle the same screen so FFCs aren't possible. [Actually I am not sure if FFCs can carry over from the entrance screen to an NES Cave. Even if that would be a more complicated approach.] Another thing is the fire in NES Caves are NPCs as well and I am pretty sure they spawn first and the Guy last. You can disable the fire in caves but the script doesnt account for it. You also cannot effectively write to npc->Tile. You have to use npc->OriginalTile. Also the FFC script will probably run before NPCs have spawned so checking for them will be ineffective.

I could add in values for X and Y coordinates in my script but that would take up 2 more global variables. If someone requests this I can do it easily.

Rightio!

I never actually used caves or guys without script so I wouldn't really know.. I was busy doing other things. Apologies for making an attempt without checking myself.. I usually wouldn't do that.

[Binx]

There are a couple problems with this script. Most importantly is NES Caves recycle the same screen so FFCs aren't possible. [Actually I am not sure if FFCs can carry over from the entrance screen to an NES Cave. Even if that would be a more complicated approach.] Another thing is the fire in NES Caves are NPCs as well and I am pretty sure they spawn first and the Guy last. You can disable the fire in caves but the script doesnt account for it. You also cannot effectively write to npc->Tile. You have to use npc->OriginalTile. Also the FFC script will probably run before NPCs have spawned so checking for them will be ineffective.

I could add in values for X and Y coordinates in my script but that would take up 2 more global variables. If someone requests this I can do it easily.

So, wait, if FFCs can't carry over from the entrance screen to caves, how does your script work? I mean, isn't part of making your script work placing an FFC on the entrance screen?

[SUCCESSOR]

Rightio!

I never actually used caves or guys without script so I wouldn't really know.. I was busy doing other things. Apologies for making an attempt without checking myself.. I usually wouldn't do that.

Oh I completely understand. I am new to using NES Caves myself. Or in truth I just cant remember much of using them from back in the early 2000s. I actually tried to write to npc->Tile when writing my script. I forgot that writing to it was undefined.

[SUCCESSOR]

So, wait, if FFCs can't carry over from the entrance screen to caves, how does your script work? I mean, isn't part of making your script work placing an FFC on the entrance screen?

The ffc script only sets a couple global variables to it's arguments' values. The global script does the checking and "switching" or Guys. This is why if you don't set the ffc you'll end up with the last "Custom Guy" you used or as I am calling him now "0 Guy."

[Binx]

Oh, ok. I guess that makes sense. It's definitely a very versatile script, since it only takes up one guy slot and you can set as many custom guys as you want, no?

[SUCCESSOR]

Oh, ok. I guess that makes sense. It's definitely a very versatile script, since it only takes up one guy slot and you can set as many custom guys as you want, no?

Yeah, there is no limit. It doesn't actually change the NPC it just switches what tile and cset ABEI2 uses.

To be clear I never said FFCs can't carry over to Caves. I don't know if they can. What I said was that route would probably be more complicated and that setting an FFCs on the actual Cave wouldn't be very effective.