Jump to content

Photo

My Script Wishlist and Your Script Ideas


  • Please log in to reply
242 replies to this topic

#1 ywkls

ywkls

    Master

  • Members

Posted 28 February 2015 - 01:17 AM

Current Script Requests- Help With RPG-Style Scripts
                                        
 
This is not a script request. (Although if anybody wants to create one of these or can point me or someone else to a place where these already exist that would be cool.) As the title says, whenever I'm trying to add a feature to my quests, these days I often turn to scripting for the answer.
 
Sadly, I know only the most basic of scripting and even things that seem like they should work fall short of my goals. I can look over a header file, or an existing script and get a good sense of how it is supposed to work but putting that into practice is usually hit or miss. Often when I look for the sort of thing that I want to achieve; I don't find anything in the database or on the forums which meets my desires. Occasionally, I can create my own or combine existing ones to do new things.
 
I decided to create this because it would give me (and anybody else who is looking for a specific script but can't seem to find it) a place to post the scripts they'd like to see or use in their game but don't currently have. Also, I think that why you want it is important too since asking for a script or help with one can begin to bother people since many things have been requested repeatedly.  It is clear that many times people don't know that certain scripts exist or how to use them. (I know that's true in my case.)
 
Scripts are very neat, but when you have trouble with them; the best way to figure out what you're doing wrong is to ask for help in the script request forum. There's a chance you won't get an answer (I don't always). but it doesn't hurt either. Many scripts exist on the forums that aren't in the database. That is another reason I wanted to make this thread. Don't know if there is a certain script but don't want to create a thread asking for it? Here's the first tips I can give you.
 
1. Search the database listing of scripts. All of them.
2. At the bottom of the forums page is a listing for the Old Script Database. There's some stuff there that never made it into the main database for some reason. What you want might be there.
3. What are you trying to do and why? Is it similar to something that already exists? Can your request be summed up in a few words (like combine scripts)? At the top of each page is the search box. The subjects it brings up might not be relevant, but then again they might.
4. Still stumped? Ask!
 
Just to be clear, I'm not offering to create any scripts though I have gained a good knowledge of what scripts exist and how best to find them. Remember the rules about bothering people about scripts. Using them is a work in progress, even for people who have been doing it for years. Don't assume you'll master scripts overnight. I am no expert myself, just someone who has seen a lot of requests for similar things.
 
Please learn how to compile scripts before trying to add these. A simple rule of thumb is that any constants, booleans, floating numbers or other stuff that will need to be used repeatedly by numerous things is declared 1st (after header files like std.zh). The order of other things doesn't always matter, but keeping each script type in a separate area is useful. Also, be sure to comment anything you don't understand or create a file with instructions on how to set up each script just to remind yourself.
 
Here are some popular script requests and the answers(to the best of my knowledge)to them:
 
Shovel script- This is based on an item and Link Tile Modifiers. If you don't know what they are and how to use them, then you'll probably have a lot of trouble setting this up. Each one will be specific to your game.
 
Custom Bosses/Enemies- The easiest script I've found to use is called Big Enemy DX, in combination with a script called Bossmaker. Other than those, ghost.zh can make some really neat custom enemies but is much harder to set up. If you want a custom foe and don't know how to create it, I'd suggest trying out these scripts and learning how to use them. More complicated foes will probably require a specific script request. (But even then, you may not get results.)
 
Hole/Lava Script- There are at least three different versions of this that I've seen. One is by Mero, one by MoscowModder and the third I'm not sure about. (Or even if it exists.) They can be a little finicky since the documentation doesn't always detail how to set them up.
 
Combining Global Scripts- this depends on what you have. All Global scripts start like this.

global script globalscript{ //This name is yours to change at will.
    void run(){

The one that is usually worked with is the active. Anything that needs to be established before your loop begins is next, followed by the start of your while(true) loop. Next are any functions that come before Waitdraw(). The best way to determine if yours needs to go there is to look at the original script and see where that function is in that global script. After that are more functions, followed by a Waitframe() and the end of the while loop. Spacing your loops helps you to tell where each one begins and ends.
 
Moving Platform/Solid FFCs- Mero recently released code that is designed for this function. I haven't tested it myself yet, but look for the topic Solid FFCs beta.
 
True Power Bracelet- see the note on the Shovel. I haven't tried either of these due to my reluctance to tackle Link Tile Modifiers.
 
That's the most common examples that I can think of right now. If you can think of a script request you've seen a lot and where to find the best solution to that issue, let people know.
 
Now here's the other half of why I created this thread. I have a few ideas for things which scripts might be able to do (or there are scripts that already do this and I don't know about them). These are things I'd like to see or use.
 
Whip/True Grappling Beam- this is mostly something that bothered me about sideview gravity areas. You can't latch onto a grapple point and swing across a gap like Indiana Jones or Samus in Metroid. Instead you just go straight across. Can this be done? Who knows... but I think there are some who would be interested.
 
Variable Lens of Truth- let's face it, the Lens of Truth doesn't do much. I've seen one script that causes the Lens to trigger secrets, but that would be troublesome if there are more than one type of secrets in the room or you could use it in other areas. So my idea is to have secrets that are triggered only while using the Lens of Truth. Also, the Lens always creates a circle around Link. Why not some other shape, like a triangle with the point centered on Link?
 
Multiple Items/Scripted Triggers- You can make extra swords. If you want, you could even make extra versions of nearly every item in the game. But doing that serves almost no purpose when you can't easily create secrets that can only be triggered by that item. So, a trigger that would detect you had the item and activate secrets when you hit it with it. Then, making a more powerful hammer; new bow, boomerang, hookshot, etc. items would actually serve a useful purpose.
 
Scripted Layers- You can change a layer via secrets, but what about through scripting? Not just scrolling the layer,.but altering the whole thing. Perhaps switching the layer from one source to another. Or altering its Cset. Perhaps making it flash. Great for cutscenes.
 
Multiple Water Types/Boot Types- I've seen some script for multiple types of boots protection, but not for flippers. I don't remember where the first is anymore, sadly. With these, you could have different types of damage and water barriers that would require the acquisition of these items to progress.
 
Deactivate FFC/Script- Doing something causes an FFC to be removed from a certain screen or the script that FFC runs to no longer be run. This be useful if at one point you had lava that used a script then later you wanted to deactivate it. I think I've seen something on this, but I haven't been able to find it.
 
There are a few more I think that I can come up with, but that's good enough for now. So, any thoughts on common scripts people want and which ones are best, as well as scripts you'd like to have or use?


Edited by ywkls, 09 April 2016 - 03:39 PM.


#2 Timelord

Timelord

    The Timelord

  • Banned
  • Location:Prydon Academy

Posted 21 May 2015 - 12:02 PM

These are things I'd like to see or use.
 
Whip/True Grappling Beam- this is mostly something that bothered me about sideview gravity areas. You can't latch onto a grapple point and swing across a gap like Indiana Jones or Samus in Metroid. Instead you just go straight across. Can this be done? Who knows... but I think there are some who would be interested.

I believe that Alucard tried to do this, as possibly have a few others. The sideview-swing item, is something occasionally discussed; but to my knowledge, no final product exists to use. I recall a discussion regarding velocity math, for this sort of item, but beyond that, I don't recall any outcome.
 

Variable Lens of Truth- let's face it, the Lens of Truth doesn't do much. I've seen one script that causes the Lens to trigger secrets, but that would be troublesome if there are more than one type of secrets in the room or you could use it in other areas. So my idea is to have secrets that are triggered only while using the Lens of Truth. Also, the Lens always creates a circle around Link. Why not some other shape, like a triangle with the point centered on Link?

...
 
Right, so here's the basic problem, and the reason this doesn't exist:
 
The internal mechanic for the lens is not something that you can call, like a function. Using the internal object, is simple, and straightforward. You cannot however, write to itemdata->Attributes[]. If you could, it'd be easy to write to itemdata->Attribute[0] (in this case, lens width).
 
Likewise, if that attribute was on the item power, rather than the Attributes[], you could write to that.
 
Thus, you'd need to write the item, and effect, from scratch. What you'd be doing there, is a draw command, to draw tiles to the screen, while the item is active. If you want an inverted area effect, that requires some bitmap use too. I would create a translucent overlay, in which any combo that has a secret flag, is drawn over by a marker of some kind.
 
That part, isn't too difficult, but you need to set up the math for distance. A circle, is rather straightforward, as the distance of revealing is the radius, centred on the player. If you start using any other shape, you need to be very precise on the math; and really, the only other shapes that I can see as useful are regular hexagons, and regular squares. I suppose you could make an angular effect, such as a torchlight, but again, your coordinates must be precise.
 
Other than that, you're essentially making an FFC--and this is needed, in this case, to give you a mobile pointer--that creates drawn objects when it collides with combo flags.

 

The reason that you don;t see this anywhere, is because it's just easier to have different lens items, with varying sizes; and shifting between items, so that you use the internal mechanic. You could, for example, set up eight lenses, plus one 'dummy' lens. Using the 'dummy' lens would activate the highest level lens owned; or whichever one you want. You could even have it scale down over time with creative usage of UseItem(A) and UseItem(B).
 

Multiple Items/Scripted Triggers- You can make extra swords. If you want, you could even make extra versions of nearly every item in the game. But doing that serves almost no purpose when you can't easily create secrets that can only be triggered by that item. So, a trigger that would detect you had the item and activate secrets when you hit it with it. Then, making a more powerful hammer; new bow, boomerang, hookshot, etc. items would actually serve a useful purpose.

 
...This exists. Grayswandir make it, a while back; and I've since integrated it, and derevations thereof into RPG.zh.

 

I've expanded on it for global usage, by using specific combo IDs, rather than using FFCs. That requires the function ComboCollision() from stdCombos.zh. I use the version from release 1.1 of that header; but any will suffice. I also use tables to match combo IDs to their triggers, but there are other ways to do it, including the FFC approach, and script type flags.

 

I needed to be able to trigger any desired effect, with any item in the game. This later became any condition in the game too. The original script is the most useful for general utility purposes. Set it to either the exact item, or the item class that you want to trigger it; and to either the ComboD, or ComboT that you want as the source, and the dest, and run with it.

 

If you start to build a large amount of material that is going to need this trigger, that's when you make it global. You can literally port those commands into global functions, and run them in your active script, to accomplish the same effect without an FFC.
 

Scripted Layers- You can change a layer via secrets, but what about through scripting? Not just scrolling the layer,.but altering the whole thing. Perhaps switching the layer from one source to another. Or altering its Cset. Perhaps making it flash. Great for cutscenes.


Again, this exists. Most of this is not something that an average person will use, which is why you don't wsee it in a database, but you can copy screens, copy layers, merge layers, and change any combo, or tile, or ffc, on any screen in a game. My main ways to track this, are through an array ( GameEvents[] ) and via Screen-D registers.

 

Essentially, the change is always from a global command. It's part of the active script, and only runs if a governing condition matches the requirements that I establish. This can be quite game-changing, and not something that an average user will want to use, because using it requires comprehending exactly how it works.

 

Thus, you'll see the functions to do this in various headers, and libraries; but no single 'utility purpose' script, as the desired effect will vary wildly in any given game.

 

DrawScreenToLayer() is one of my custom drawing functions, to allow drawing an entire source screen, to a givel layer of a destination screen, allowing transparency. It uses the ordinary DrawLayer() function, and a for loop. That's for visual effects. (The normal DrawScreen() function does not allow transparency.)

 

If you want to directly modify a screen, you need to do it by writing to ComboD[] at any position that you desire to change. You can also change entire sections of a game, by using the functions to move, copy, or delete tiles, or combos. If, for example, you want to turn every flower into a cactus, you could globally change the combo, or the tile in the .qst file with one command.
 

Multiple Water Types/Boot Types- I've seen some script for multiple types of boots protection, but not for flippers. I don't remember where the first is anymore, sadly. With these, you could have different types of damage and water barriers that would require the acquisition of these items to progress.

 

The easiest way to do this, is to use alternative combos (non water type), as long as the 'Link can drown' quest rule is disabled. If you do this, then you can simply change any combo by +X, when a given item is true. That requires setting up your water tiles, so that each type is in a matched pair; as slash->next combos work.

 

Using the item that permits you to swim, turns each combo on a screen, from the src, to src++. That converts it to water, and if you disable that item, you need only shift them back again.

 

If Link can drown, you enter a different world of pain. You'd essentially use something similar to the pit/hole/lava script, and set it up so that the damage areas (let's say, lava, as that's the easiest to imagine) , the lava, changes into a swim combo of identical appearance, when the lava-swim item is true.

 

I might do that, just for Eppy: The Feather of Lava Swimming. :D

 

Deactivate FFC/Script- Doing something causes an FFC to be removed from a certain screen or the script that FFC runs to no longer be run. This be useful if at one point you had lava that used a script then later you wanted to deactivate it. I think I've seen something on this, but I haven't been able to find it.


In RPG.zh, again, I have functions for handling FFCs like that. FFCScript.zh might nave some new things too.

void KillFFC(int slot){
    int thisFFC;
    ffc f;
    for( int i = 1; i <= 32; i++ ){
        f = Screen->LoadFFC(i);
        if ( f->Script == slot ) {
            f->Data = 0;
        }
    }
}

void ChangeFFCScript(int slot, int newScript){
    int thisFFC;
    ffc f;
    for( int i = 1; i <= 32; i++ ){
        f = Screen->LoadFFC(i);
        if ( f->Script == slot ) {
            f->Script = newScript;
        }
    }
}

Either way, if you want to deactivate lava/pit combos, the best solution is to run them base don an internal boolean condition, that works off a global condition; such as a global array, a global boolean, or anything else that the ffc can always read. You can also do it on a per-screen basis, with the Screen->D register of that screen.

 

If you want to be really creative, you can technically read Screen->D from anywhere in a game. That allows 'carry over secrets' via Screen->D, from any screen, or any DMAP.

 

I hope this wasn't a complete overload of information for you; but you did have a list, and perhaps this will explain more on why some of what you want isn't in general circulation. You have yet to bring up anything that is technically impossible though.


Edited by ZoriaRPG, 21 May 2015 - 12:09 PM.

  • Binx and ywkls like this

#3 ywkls

ywkls

    Master

  • Members

Posted 21 May 2015 - 12:20 PM

Wow! It had been so long since I created this thread that I had thought I was never going to get any response to this but you found something for just about everything.

 

 

I basically started this thread to see if anybody had ideas for scripts that they'd never seen done or would like to see, but when I didn't get any replies (just people who viewed it and moved on) I sort of gave up on it.

 

That scripted trigger is definitely going in my next game. (Kind of late to put it into the one that I'm working on now.)

 

The switching of the water/layers sounds like it would be more pain than it is worth. Oh well, at least it's not impossible.

 

Looking back, I don't remember why I suggested the means to stop scripts running, but at least now I know how to do that!

 

I'll think of some more ideas for scripts that I've either never seen done or that I can't find working versions of anywhere in the forums. If you want to help out, feel free.


Edited by ywkls, 21 May 2015 - 12:21 PM.


#4 ywkls

ywkls

    Master

  • Members

Posted 21 May 2015 - 01:35 PM

Alright, time for a few of my more esoteric ideas. Again, I'm not requesting any of these at this time although I might ask for one of them in particular in the future. Some of this may either be (A) impossible or (b) so hard as to not be worth the time involved. (Kind of like Z3 scrolling.) If these exist, can someone tell me where they can be found; because I haven't discovered them in my perusals of the database.

 

Multiple Songs/Ocarinas- I know that Jamian did this in the Forbidden City, so I know that it can be done. How bad do I want this? When I couldn't find one on the database or in the forums that wasn't so broken that it would take longer to fix than to write a new one, I tried that. I worked on this for about 2 weeks on my own and got precisely nowhere. I soon gave up on the idea of detecting which button was pushed and comparing that against a preset selection of possible buttons and just tried to make it where when you used the item, Link would turn invisible; an FFC would appear at his position with a preset animation and another would appear above his head. Depending on which songs you had learned, you could then switch to one of them. You'd press B to quit and A to select a particular song. If anybody is curious, I'll post my code. But keep in mind that my attempt didn't work.

 

Multiple Subscreens- Well, you can change your subscreen in different parts of the game but what about something like the Oracle games where one subscreen is the items and another is stuff like pieces of the triforce, heart piece or even the ring box? (LIke we see in the Forbidden City.) One way I thought this might be done is by creating a dummy item that would appear on the normal subscreen that when equipped would cause the other subscreen to appear. Of course, drawing things over the subscreen is hard to begin with and not everybody is going to want to go to that kind of trouble.

 

Active Time Battle System- Believe it or not, this has been tried... and given up on. Years ago, back when scripting was first being posted; somebody attempted to do this and apparently gave up. Kind of like Z3 scrolling, it seems to be far too complex for any realistic use. Just to see what it might entail, I briefly toyed with trying this too... then realized the limitations of my knowledge and let it die quickly.

 

Multiple Rafts- I know that mine carts have been done, but what about Mine Carts and Rafts? When stepping on the mine cart starting point, that is used and when on the raft starting point; that is used. And speaking of mine carts... what about switching the path of the cart? Secrets can be used to change the appearance of the screen and I guess that you'd make the tracks have the inherent flag for the raft path; but again is there a way to make it where one has to use the mine cart and the other has to use the raft?

 

Attacks Bounce Off the Sword/Other Weapon- Kind of like in Link to the Past, when you can reflect Agahnim's thunderbolts. I'm pretty sure that this has been done, I just haven't been able to find it.

 

New Game +/Multiple Endings- I've had a few ideas on doing multiple endings myself. In fact in the game I'm currently working on I plan to write a script that will check if you meet certain requirements at a certain point in the game, then trigger screen secrets that will automatically warp you to the different ending. But what about starting over from the beginning with all of your items intact, the entire game reset to the beginning and the chance to do events that will only show up during the new playthrough. I know that reseting things like combos, items in rooms and bosses would be very hard. And I know how to set up events that will only occur after you get certain things. I just haven't seen it done for more than a few endings and I wondered if it was possible. (I have a rather ambitious idea that would use this if it was.)

 

That's it for now. Any thoughts on how to do any of these things or what you'd like to see done?



#5 Timelord

Timelord

    The Timelord

  • Banned
  • Location:Prydon Academy

Posted 21 May 2015 - 02:26 PM

Multiple Songs/Ocarinas- I know that Jamian did this in the Forbidden City, so I know that it can be done. How bad do I want this? When I couldn't find one on the database or in the forums that wasn't so broken that it would take longer to fix than to write a new one, I tried that. I worked on this for about 2 weeks on my own and got precisely nowhere. I soon gave up on the idea of detecting which button was pushed and comparing that against a preset selection of possible buttons and just tried to make it where when you used the item, Link would turn invisible; an FFC would appear at his position with a preset animation and another would appear above his head. Depending on which songs you had learned, you could then switch to one of them. You'd press B to quit and A to select a particular song. If anybody is curious, I'll post my code. But keep in mind that my attempt didn't work.

 

You need...the Groose face.

 

If you want to post it, do so, and I'll will try to break it until it works for you. Really, it'd probably be simpler to do it from scratch, but if it's just a few problems with syntax or something, I might, possibly point those out for you fairly fast. We all know that meticulous sloth is one of my secret skills.

 

I believe that at least two quests had multiple songs; and as to multiple recorder items, even 'Legend of Lana' has two. If you aren't using the in-built whistle trigger (ponds), or the whistle warps, you can simply code the entire thing from scratch. An item that launches an FFC script, plays a melody (you can even play enhanced music, or change the present midi for this), and does whatever shenanigans that you want the song to do. I'm guessing that was your basic direction for this...

 

You can also add the triggers back into a scripted version, but unless you're running a classic quest, the dry up ponds thing will elude many modern players; and if you're going to script the music, IMO, you should script the warps too. Give the player a selection screen, as Z3 did, or something along those lines.

 

I used an item that allows the player to establish custom return points, and then go back to them.

 

As to special song selection: The easiest way to do this, is to run the FFC, and expect a directional input, to choose a song. If you want a player to enter the song with notes (I personally hate that model), you have easy access to twelve buttons in ZC, and you only need seven (for basic notes), or nine (if you want a +1/-1 octave shift) to input a melody. Don't blame me though, if those who aren't musically inclined want to print out that script, stab it, and burn it in a furnace.

 

Menu selection is also an option, but any way that you do it, you want whatever FFC you run to display the options, and the buttons to use them.

 

The alternative/lazy way, is to make multiple whistle items with different sounds.

 

P.S. Preset direction, based on where Link is facing, should, and does work; but you'd need to script the effect tied to that; and really, it doesn't make sense for a modern 'instrument' item.
 

Multiple Subscreens- Well, you can change your subscreen in different parts of the game but what about something like the Oracle games where one subscreen is the items and another is stuff like pieces of the triforce, heart piece or even the ring box? (LIke we see in the Forbidden City.) One way I thought this might be done is by creating a dummy item that would appear on the normal subscreen that when equipped would cause the other subscreen to appear. Of course, drawing things over the subscreen is hard to begin with and not everybody is going to want to go to that kind of trouble.

 

That's on my agenda for LoE: One screen for main inventory, one screen for quest items, one screen for maps. Rotate with R/L. (You need to manually script the active subscreens to do that, and some members here have fully scripted their own subscreens.)

 

Drawing over the subscreen though, isn't the hard part: You're going to be negating the in-built subscreen to achieve this goal. Essentially, you disable Input->Start, and run your subscreen function instead. I haven't managed to do this yet, but I comprehend most of the concept behind setting it up. You do need a subscreen set up with all the game items though, so that you can invisibly change between them; but the player never sees that.
 

Active Time Battle System- Believe it or not, this has been tried... and given up on. Years ago, back when scripting was first being posted; somebody attempted to do this and apparently gave up. Kind of like Z3 scrolling, it seems to be far too complex for any realistic use. Just to see what it might entail, I briefly toyed with trying this too... then realized the limitations of my knowledge and let it die quickly.


I'd need an explanation of what this is supposed to mean. ('Active Time Battle System' is an expression that I can interpret in various ways; likely none of which match your intent.)
 

Multiple Rafts- I know that mine carts have been done, but what about Mine Carts and Rafts? When stepping on the mine cart starting point, that is used and when on the raft starting point; that is used. And speaking of mine carts... what about switching the path of the cart? Secrets can be used to change the appearance of the screen and I guess that you'd make the tracks have the inherent flag for the raft path; but again is there a way to make it where one has to use the mine cart and the other has to use the raft?

...

     ...but...why?

                         ...

 

Really though, this is possible. People hate raft paths, but yes, you could do this. First, raft paths allow switching by default. it's built into ZC. If you want to trigger other paths with a screen secret, then you get into changing flags on a screen. I believe that you can set a raft path flag anywhere on the screen, using an FFC. You'd need to hard-code the coordinate values, unless you want to dedicate additional script flags to the process.

 

You can also affect Link's direction, and movement directly.

 

Halt all player directional inputs, and move the player around as you wish, at insane speeds. That would, IMO, be better for a minecart, than using a raft, but the lack of scrolling makes it less exciting than you might think. Waff, you woosh through an area, then the screen pauses to scroll, and woosh, again. It would probably feel awkward, but it's certainly something you might want to consider.

 

I've thought about coding an (active) spinner item, that worked on special tracks, but that would move the player while they hold its button, and could probably run off the tracks, for a few spaces.

 

Attacks Bounce Off the Sword/Other Weapon- Kind of like in Link to the Past, when you can reflect Agahnim's thunderbolts. I'm pretty sure that this has been done, I just haven't been able to find it.


A few people have done reflected effects. I created code to nullify shots on contact, but not to deflect them, as I was too lazy to add in those effects. The tedious part, is the rel v and rel dir of the projectile, after deflecting it.
 

New Game +/Multiple Endings- I've had a few ideas on doing multiple endings myself. In fact in the game I'm currently working on I plan to write a script that will check if you meet certain requirements at a certain point in the game, then trigger screen secrets that will automatically warp you to the different ending. But what about starting over from the beginning with all of your items intact, the entire game reset to the beginning and the chance to do events that will only show up during the new playthrough. I know that reseting things like combos, items in rooms and bosses would be very hard. And I know how to set up events that will only occur after you get certain things. I just haven't seen it done for more than a few endings and I wondered if it was possible. (I have a rather ambitious idea that would use this if it was.)


One option, is to keep the same .sav file, and run a function that runs a multiple-for-loop to change all screen vars back to the default. Now, this one is tricky, depending on what screen vars you've set in a game, but you can unset Screen->Secrets, and change all Screen->D back to '0'. I don't remember what bits are set when you kill a 'never returns' enemy, but you should be able to clear that too. ust set up a routine, of functions to do that for one screen, and nest those into one combined function; and run a double-for-loop (dmaps, screens) that executes that function on every screen in a game.

 

Note that you cannot write to screen flag bits. Those are read-only. I think you could get away with this though, to quickly set screen states:

const int MAPCOUNT = 100; //Set to your present map count.
const int SCREENSPERMAP = 131; //Decimal value of screens per map.

void WipeScreen(int map, int screen, bool value){
    for ( int q = 0; q < 14; q++ ) {
        Game->SetScreenState(map, screen, q, value);
    }
}

void WipeScreens(int value){
    for ( int w = MAPCOUNT; w > 0; w -- ) {
        for ( int e = SCREENSPERMAP; e > 0; e-- ) {
            WipeScreen(w,e,value);
        }
    }
}


void WipeScreens(){
    for ( int w = MAPCOUNT; w > 0; w -- ) {
        for ( int e = SCREENSPERMAP; e > 0; e-- ) {
            WipeScreen(w,e,false);
        }
    }
}
 

Clearly, untested.

 

 

Again, what datum you'd wash is going to be extremely game-specific. Download RPG.zh, and open /RPG_zh/RPG_Backup.zlib ... You could parley this kind of concept from the functions in that file, possibly by using a password for the items if you're wanting to use a clean .sav file, and then creating the datum for the main arrays from the password... You'd need to figure out how you want to read that information into an entirely clean file though, and using a password like that would be extremely tiresome to set up, and almost as terrible to use, unless you use literal 0/1 numerics, which would make it pretty pointless.

 

Some games allow you to keep playing after a 'bad ending', without real penalties. That doesn't require all this extensive coding; but if you only want to permit the player to keep items, but force them to re-do dungeons--this might sound fine, but I feel that the average player would feel it a bit tedious--then what you need to do is clear whatever vars in a game that you're using.

 

Unless all your variables are in one array, you'll need a multitude of commands to change them, which is one of the very good reasons that I keep values in arrays. (All of the internal ZC indices are arrays, so you can run a for loop on any of them to change their values all back to false.)

 

Setting screen states is the easy part.

 

P.S. I only noticed this thread, because you directed me toward it. You might want to retitle it:

 

'Script Wishlist for the Common Man' or something equally snappy, to set it apart from the thousand other threads with similar titles.


Edited by ZoriaRPG, 21 May 2015 - 03:04 PM.

  • ywkls likes this

#6 coolgamer012345

coolgamer012345

    🔸

  • Members
  • Location:Indiana, USA

Posted 21 May 2015 - 03:02 PM


A few people have done reflected effects. I created code to nullify shots on contact, but not to deflect them, as I was too lazy to add in those effects. The tedious part, is the rel v and rel dir of the projectile, after deflecting it.

I actually have some similar code:

EDIT: Goddamit half my post deleted itself, this might take a bit to replace.. Code should be fixed.

void StartIceScript()
{
    // Initiate
    // const int ICE_WPN_MSC = 88;
    // const int ICE_TILE = 6;
    // somewhere outside the script
    // You would probably want to modify the variables names, LWeapon name, 
    // and function name so it is less confusing when using this for a reflected fireball or something.


    Link->MP -= 1;

    int Deg_Rand_UP_ANGLE = Randf(225, 315);
    int Deg_Rand_DOWN_ANGLE = Randf(135, 45);    
    int Deg_Rand_LEFT_ANGLE = Randf(135, 225);
    int Deg_Rand_RIGHT_ANGLE = Randf(315, 405);

    int Rand_UP_ANGLE = DegtoRad(Deg_Rand_UP_ANGLE);
    int Rand_DOWN_ANGLE = DegtoRad(Deg_Rand_DOWN_ANGLE);
    int Rand_LEFT_ANGLE = DegtoRad(Deg_Rand_LEFT_ANGLE);
    int Rand_RIGHT_ANGLE = DegtoRad(Deg_Rand_RIGHT_ANGLE);

    lweapon Ice_Storm = Screen->CreateLWeapon(LW_SCRIPT3);
        
    Ice_Storm->Angular = true;
        
    Ice_Storm->X = Link->X;
    Ice_Storm->Y = Link->Y;
    
    // Spawning the weapon infront of Link
    if(Link->Dir == DIR_UP)
    {Ice_Storm->Y = Link->Y - 16;}
    
    if(Ice_Storm->Dir == DIR_DOWN)
    {Ice_Storm->Y = Link->Y + 16;}
    
    if(Ice_Storm->Dir == DIR_LEFT)
    {Ice_Storm->X = Link->X - 16;}
   
    if(Ice_Storm->Dir == DIR_RIGHT)
    {Ice_Storm->X = Link->X + 16;}
    
    
    Ice_Storm->Dir = Link->Dir;

    
    if(Ice_Storm->Dir == DIR_UP)
    {Ice_Storm->Angle = Rand_UP_ANGLE;}
    
    if(Ice_Storm->Dir == DIR_DOWN)
    {Ice_Storm->Angle = Rand_DOWN_ANGLE;}
    
    if(Ice_Storm->Dir == DIR_LEFT)
    {Ice_Storm->Angle = Rand_LEFT_ANGLE;}
    
    if(Ice_Storm->Dir == DIR_RIGHT)
    {Ice_Storm->Angle = Rand_RIGHT_ANGLE;}
        
        
    Ice_Storm->UseSprite(ICE_WPN_MSC);
    Ice_Storm->Damage = 2; // The LWeapon Damage

    Ice_Storm->Step = 400;            
    
    Ice_Storm->HitWidth = 8;
    Ice_Storm->HitHeight = 8;

    
    if(Ice_Storm->Dir == DIR_UP)
    {Ice_Storm->Tile = ICE_TILE;}
    if(Ice_Storm->Dir == DIR_DOWN)    
    {Ice_Storm->Tile = ICE_TILE + 2;}
    if(Ice_Storm->Dir == DIR_LEFT)
    {Ice_Storm->Tile = ICE_TILE + 3;}
    if(Ice_Storm->Dir == DIR_RIGHT)
    {Ice_Storm->Tile = ICE_TILE + 1;}                                                        
}   

Okay, you should be able to check if a weapon of Link's (like his sword) hitbox was hitting an EWeapon of whatever type, and then run the above function. The code should even change the tile depending on which direction the weapon is being reflected. Arrange the tiles like...

 

Up tile, Right Tile, Down Tile, Left Tile (The order of the code checking that is a bit strange, but you could change that)

 

Credits to Lejes for helping me out when I originally made that item script.


Edited by Coolgamer012345, 21 May 2015 - 03:19 PM.


#7 ywkls

ywkls

    Master

  • Members

Posted 21 May 2015 - 03:17 PM

Responses in bold. 

I believe that at least two quests had multiple songs; and as to multiple recorder items, even 'Legend of Lana' has two. If you aren't using the in-built whistle trigger (ponds), or the whistle warps, you can simply code the entire thing from scratch. An item that launches an FFC script, plays a melody (you can even play enhanced music, or change the present midi for this), and does whatever shenanigans that you want the song to do. I'm guessing that was your basic direction for this...

 

I've heard that there were ways to get items to launch ffc scripts, but for the life of me I can't remember what those are and obviously don't have any scripts right now that do this. In my own attempt, I just had it set a boolean to true, then have the global loop tell it to run a function if that is true, then have that function control the songs. I only wanted three songs, if you can believe it. I was going to hard code the song to play and have it where each one had to have a particular item to use it. Like I said, couldn't get it even to begin to work.

 

You can also add the triggers back into a scripted version, but unless you're running a classic quest, the dry up ponds thing will elude many modern players; and if you're going to script the music, IMO, you should script the warps too. Give the player a selection screen, as Z3 did, or something along those lines.

 

I think what you mean is that like the scripted triggers, you can set up the new ocarina to only set off certain things. As for the location select screen, I imagine an array that would store the total possible locations, then when you go to a screen with one and examine the ffc on it; it would set the corresponding value of that array to true. So you could only warp to screens you'd already visited. And of course, a special location select screen would come up when you did so, kind of like it does in LTTP. Perhaps using the draw bitmap feature? This is the one I want the most and I'll eventually probably post a script request topic specifically devoted to it. If you're interested in contributing code that might help with this, I'd appreciate it.

 

I used an item that allows the player to establish custom return points, and then go back to them.

 

As to special song selection: The easiest way to do this, is to run the FFC, and expect a directional input, to choose a song. If you want a player to enter the song with notes (I personally hate that model), you have easy access to twelve buttons in ZC, and you only need seven (for basic notes), or nine (if you want a +1/-1 octave shift) to input a melody. Don't blame me though, if those who aren't musically inclined want to print out that script, stab it, and burn it in a furnace.

 

I don't really like the button press idea myself (In fact, it's almost certainly a billion times harder than the alternative) and my version just used the directional input to choose the song. My problem was that once the script started running, it never wanted to stop even though I had included code that was supposed to make it halt.

 

Menu selection is also an option, but any way that you do it, you want whatever FFC you run to display the options, and the buttons to use them.

 

The alternative/lazy way, is to make multiple whistle items with different sounds.
 

 

That's on my agenda for LoE: One screen for main inventory, one screen for quest items, one screen for maps. Rotate with R/L. (You need to manually script the active subscreens to do that, and some members here have fully scripted their own subscreens.)

 

Drawing over the subscreen though, isn't the hard part: You're going to be negating the in-built subscreen to achieve this goal. Essentially, you disable Input->Start, and run your subscreen function instead. I haven't managed to do this yet, but I comprehend most of the concept behind setting it up. You do need a subscreen set up with all the game items though, so that you can invisibly change between them; but the player never sees that.
 

Yeah, I figured that this would be an incredibly complex thing to do. I know there are some people who have scripted their own subscreens but I've never seen an explanation of how it is supposed to work. 

 

I'd need an explanation of what this is supposed to mean. ('Active Time Battle System' is an expression that I can interpret in various ways; likely none of which match your intent.)

 

Well, I was thinking of a game that had multiple characters in which you fought against static images of monsters (or animated ones) that could then damage one of your characters. Each character would be able to select from a variety of options, such as attack, magic, item and so forth and their turns would occur at a set rate. Basically, a standard RPG battle running within the Zelda Classic engine. Insanely complex, requiring the coding of practically everything involved and on the outer edges of possibility.

 

 

...

     ...but...why?

 

Really though, this is possible. People hate raft paths, but yes, you could do this. First, raft paths allow switching by default. it's built into ZC. If you want to trigger other paths with a screen secret, then you get into changing flags on a screen. I believe that you can set a raft path flag anywhere on the screen, using an FFC. You'd need to hard-code the coordinate values, unless you want to dedicate additional script flags to the process.

 

You can also affect Link's direction, and movement directly.

 

Halt all player directional inputs, and move the player around as you wish, at insane speeds. That would, IMO, be better for a minecart, than using a raft, but the lack of scrolling makes it less exciting than you might think. Waff, you woosh through an area, then the screen pauses to scroll, and woosh, again. It would probably feel awkward, but it's certainly something you might want to consider.

 

I've thought about coding an (active) spinner item, that worked on special tracks, but that would move the player while they hold its button, and could probably run off the tracks, for a few spaces.

 

Hmm... interesting... 

 

A few people have done reflected effects. I created code to nullify shots on contact, but not to deflect them, as I was too lazy to add in those effects. The tedious part, is the rel v and rel dir of the projectile, after deflecting it.
 

I wanted to do this for an enemy a while back and couldn't find the code. Since reviving this thread, at least one person has posted code that I might be able to use for this purpose. Whether or not it will work, I'll have to wait until the future to see.


One option, is to keep the same .sav file, and run a function that runs a multiple-for-loop to change all screen vars back to the default. Now, this one is tricky, depending on what screen vars you've set in a game, but you can unset Screen->Secrets, and change all Screen->D back to '0'. I don't remember what bits are set when you kill a 'never returns' enemy, but you should be able to clear that too. ust set up a routine, of functions to do that for one screen, and nest those into one combined function; and run a double-for-loop (dmaps, screens) that executes that function on every screen in a game.

 

Note that you cannot write to screen flag bits. Those are read-only. I think you could get away with this though, to quickly set screen states:

const int MAPCOUNT = 100; //Set to your present map count.
const int SCREENSPERMAP = 131; //Decimal value of screens per map.

void WipeScreen(int map, int screen, bool value){
    for ( int q = 0; q < 14; q++ ) {
        Game->SetScreenState(map, screen, q, value);
    }
}

void WipeScreens(int value){
    for ( int w = MAPCOUNT; w > 0; w -- ) {
        for ( int e = SCREENSPERMAP; e > 0; e-- ) {
            WipeScreen(w,e,value);
        }
    }
}


void WipeScreens(){
    for ( int w = MAPCOUNT; w > 0; w -- ) {
        for ( int e = SCREENSPERMAP; e > 0; e-- ) {
            WipeScreen(w,e,false);
        }
    }
}
 

Clearly, untested.

 

 

Again, what datum you'd wash is going to be extremely game-specific. Download RPG.zh, and open /RPG_zh/RPG_Backup.zlib ... You could parley this kind of concept from the functions in that file, possibly by using a password for the items if you're wanting to use a clean .sav file, and then creating the datum for the main arrays from the password... You'd need to figure out how you want to read that information into an entirely clean file though, and using a password like that would be extremely tiresome to set up, and almost as terrible to use, unless you use literal 0/1 numerics, which would make it pretty pointless.

 

Some games allow you to keep playing after a 'bad ending', without real penalties. That doesn't require all this extensive coding; but if you only want to permit the player to keep items, but force them to re-do dungeons--this might sound fine, but I feel that the average player would feel it a bit tedious--then what you need to do is clear whatever vars in a game that you're using.

 

Unless all your variables are in one array, you'll need a multitude of commands to change them, which is one of the very good reasons that I keep values in arrays. (All of the internal ZC indices are arrays, so you can run a for loop on any of them to change their values all back to false.)

 

Setting screen states is the easy part.

 

These sound like good ideas, but here's what I think I'd like. Let's say event one only happens if you have item one. But event two doesn't happen. Then event three requires item one and two. But event four requires item two and not one. You can pretty much continue this chain as long as you like. I can see ways to make script that will detect what items you have, then trigger secrets to warp you to another screen and events afterward would vary depending on which path you took. (Kind of like what I heard was done in Eiyuu.)

 

My ambitious idea was to create a game that required multiple playthroughs to reach the true ending. You wouldn't have to defeat dungeons or bosses again, just find new events and things; triggering all of them for the ultimate conclusion.

 

 

Again, thanks for your contributions. If I think of anything else, I'll post it here.



#8 Timelord

Timelord

    The Timelord

  • Banned
  • Location:Prydon Academy

Posted 21 May 2015 - 04:53 PM

ywkls, mate, you really need to shift to the plain-text editor, break up responses, and manually enter quote tags, to make responding to this easier. Dissecting your quote of my response, is a bit painful; and only sets this up for huge block-quoting that will break the field size limits.
 

I've heard that there were ways to get items to launch ffc scripts, but for the life of me I can't remember what those are and obviously don't have any scripts right now that do this. In my own attempt, I just had it set a boolean to true, then have the global loop tell it to run a function if that is true, then have that function control the songs. I only wanted three songs, if you can believe it. I was going to hard code the song to play and have it where each one had to have a particular item to use it. Like I said, couldn't get it even to begin to work.

 
It's a function of ffcscrippt.zh:
 
RunFFCScript(scriptNumber, arrayInput)
 
Thus, if you have an FFC script in slot 20, and it has arg inputs for D0, D1, and D2; in your item script, you do this:
 


 

I think what you mean is that like the scripted triggers, you can set up the new ocarina to only set off certain things. As for the location select screen, I imagine an array that would store the total possible locations, then when you go to a screen with one and examine the ffc on it; it would set the corresponding value of that array to true. So you could only warp to screens you'd already visited. And of course, a special location select screen would come up when you did so, kind of like it does in LTTP. Perhaps using the draw bitmap feature? This is the one I want the most and I'll eventually probably post a script request topic specifically devoted to it. If you're interested in contributing code that might help with this, I'd appreciate it.


I have functions that can store if a player has done things on a screen, but, if you only want to know if a player has visited a screen, that is stored as part of the screen state, in Screen->State[ST_VISITED] .

 

If you want to be able to warp to any visited screen, that would require some rather intensive mapping, and really, you;d be better off with user-defined locations. You don't need to draw bitmaps for this though: You can simply make a 'world map' with tiles, and combos, and put it on a screen anywhere in the game, then do a DrawScreenToLayer() with it, on Layer 6, and put a cursor on layer 7.

 

Bitmaps are needed when you want to be able to do special distortions, or movements with an image, but not merely to draw it. If you wanted to map to spin on its axis, or curl, or something, you'd need it to be a bitmap, so that you can use it as a render target for the effect.

 

If you only want pre-defined locations (let's say, 8 per overworld), that would be rather straightforward.
 

I don't really like the button press idea myself (In fact, it's almost certainly a billion times harder than the alternative) and my version just used the directional input to choose the song. My problem was that once the script started running, it never wanted to stop even though I had included code that was supposed to make it halt.


It sounds like you didn't have the loops set up properly. I'm assuming that, after using the item, you simply wanted to press Up/Down/Left/Right to select the song?

 

If so, you want a conditional trigger, such as while(waiting) with a boolean 'waiting' set to true by default.

 

While(waiting) the ffc does a constant Waitframe(); and if the player presses a button, it (1) stores the direction presses--actually, you can merge both into one condition:

 

          
        
Because the value of pressed is evaluated at the beginning of the loop, if a player presses a button, it will no longer be '0' when the loop evaluates it again, so the code block advances to the if statements. You can muck with the conditions for those as desired, and set up for loops as timers, or whatever visual or auditory effects you want.

 

You'll probably need another boolean (running) set to true at the top, and put while ( running ) loops in each of the 1-to-4 options, so that they last more than one frame, or you could launch a different FFC for each. (That may be the most modular way to build this item.)

 

Pressing a button changes the value of pressed, so the Waitframe() instruction in the == 0 evaluation doesnt execute, and it checks each of the other possible conditions in the listed order. We don't need else-if here, although instead of == 5 evaluation, we could use an else block, but I intentionally avoided an else block, to illustrate that you only need if statements in this example.

 

You can also expand, or contract the inclusive ors to change what buttons trigger a cancel action, if any. I'd suggest having one for this kind of script though, so that a player may back out, before using the item.

 

If you want to display graphics, you;d add the commands to display them in the while(!pressed) block. The script executes anything you put in there, until the player presses a button, so you'd just add your drawing commands before Waitframe().

 

(This, if you're curious, is what in the old days, we'd call an 'until' loop.)

 

Keep in mind that in this loop type, the condition is evaluated before executing any code. You can force events to execute at least once, by changing this to a do-while (do-until) loop:

 

 

That's an example, in which you can trigger an action even if the condition was not immediately evaluated as specified. Thus, if you declared int pressed = 6, it would still do that set of instructions once, then move on, and become confused, because it does not have an else block. That, is where, and why, you would want an else block, as a catch-all; but in the example, it wouldn't do anything, because it would fall at the end of a codeblock outside any loops.

 

I'd expand on it, if you need further information on the matter, but I wanted to give you some examples of how to set up FFC loops, so that you get a sense of how these things work. I'll post a refined version for you, if you desire it.

 

 

Yeah, I figured that this would be an incredibly complex thing to do. I know there are some people who have scripted their own subscreens but I've never seen an explanation of how it is supposed to work.


 

I'd suggest leaving that until you are entirely comfortable with using arrays, and working with all the ZScript functions. It's also prudent to see a working example. I have a template somewhere, but it would be gibberish at present.

 

I've yet to fully script my own, so I can't comment from experience, but the process is tedious. I have a general grasp on the method used, but I'd need to tinker with it, especially given the types of information I need to display.

 

Well, I was thinking of a game that had multiple characters in which you fought against static images of monsters (or animated ones) that could then damage one of your characters. Each character would be able to select from a variety of options, such as attack, magic, item and so forth and their turns would occur at a set rate. Basically, a standard RPG battle running within the Zelda Classic engine. Insanely complex, requiring the coding of practically everything involved and on the outer edges of possibility.


If you mean standard, RPG turn based encounters, such as Dragon Quest, that wouldn't be hard at all. I was already going to include that in RPG.zh, but I figured that most people wouldn't use it, as it takes away much of the 'action' expected in a ZC quest.

 

Using that, would in fact simplify a great deal of what I've been coding, to make a more 'Ys' /  'Secret of Mana'  / 'Terranigma' style engine.
 

I wanted to do this for an enemy a while back and couldn't find the code. Since reviving this thread, at least one person has posted code that I might be able to use for this purpose. Whether or not it will work, I'll have to wait until the future to see.


I actually have some similar code:
[ ... ]


Thank you CG. That seems to take a random rel velocity, and direction, rather than using the specific initial velocity, momentum, and direction, and comparing it to the angle of the striking force, so indeed, simpler. What I was eventually going to do, is make a direct, relational change, based on speed, and angle of deflection. Immensely intensive, and I'm certainly in no mood for trying it at present, with so much to complete at hand.
 

These sound like good ideas, but here's what I think I'd like. Let's say event one only happens if you have item one. But event two doesn't happen. Then event three requires item one and two. But event four requires item two and not one. You can pretty much continue this chain as long as you like. I can see ways to make script that will detect what items you have, then trigger secrets to warp you to another screen and events afterward would vary depending on which path you took. (Kind of like what I heard was done in Eiyuu.)


Events, are also in the RPG.zh header, stored in the GameEvents[] array. This has an identical index size to the main engine array, GameDynamics[], allowing me to use both in conjunction with one-another. In general terms, most of the vast, sweeping, global functions that change a great deal of datum, work from GameEvents[], whereas smaller, or independent functions, and game datum, stem from, or are stored within GameDynamics[].

 

One can affect the other, and I have special return functions for reading into these with constants.

 

When making a game with many branching options, you're going to use a good number of global variables. ZC has a limit (cap) on global variables that is smaller than the maximum size of one array, so when you walk this path, arrays are not only your best route, but often, your only route.

 

One thing to note, before you start tinkering with them, is the power of the function SizeOfArray().

 

If you start doing array-based functions, you are going to want to use that; and you will likely use it frequently, if you want your code to be modular. It returns the index size of float, and int arays; but not boolean arrays.

 

Thus, if you want a boolean array that is compatible with SizeOfArray, declare it as an int. Any 0 value will return false, and any non-zero value will return true. Either that, or you may want two arrays, of the same size, that work in conjunction, as I've done with the two that I detailed above. I use a boolean array for GameEvents because of how I write to it in some spots, but I could just as easily use a float, or int array to accomplish the same job.

 

Returning int 0 as false is something that ZC is nice about, as typecasting of this sort varies by application. You cannot however, go the other way 'round. If you try to write a numeric value to a boolean array, you'll see a nice error in response.

 

You can declare all arrays as floats too. I don't, as I declare them based on my intent, but floats in ZC are genuine ints, and can work as floats, ints, and booleans.
 

 

P.S. What editor are you using when writing ZScript?


Edited by ZoriaRPG, 21 May 2015 - 04:54 PM.

  • ywkls likes this

#9 coolgamer012345

coolgamer012345

    🔸

  • Members
  • Location:Indiana, USA

Posted 21 May 2015 - 05:37 PM

Something I would like to add is:
bh1etN7.png

Because ZC is a bit wonky with degrees, it uses a "flipped" degree chart system.. for some reason. And that chart might be useful for editing the direction the shots would fire in my random-ish direction firing function (as the degree range is in total 45 degrees, I believe, which might be a bit much. Something more around 25 to 30 degrees would be more accurate, and that chart will probably be useful for figuring that up)


Edited by Coolgamer012345, 21 May 2015 - 05:48 PM.


#10 Timelord

Timelord

    The Timelord

  • Banned
  • Location:Prydon Academy

Posted 21 May 2015 - 05:54 PM

Something I would like to add is:
bh1etN7.png

Because ZC is a bit wonky with degrees, it uses a "flipped" degree chart system.. for some reason. And that chart might be useful for editing the direction the shots would fire in my random-ish direction firing function (as the degree range is in total 45 degrees, I believe, which might be a bit much. Something more around 25 to 30 degrees would be more accurate, and that chart will probably be useful for figuring that up)

 

Useful. I haven't any idea why '0' isn't north.

 

If you're curious, what I was planning to do, is to remove the ordinary spin-attack charge, in favour of a 'parry' that the player can perform while holding down a button equipped with a sword, and in the process, removing stock shields from my normal equipment lists. (Something else will replace them, that works rather differently.)

 

A parry could, deflect a shot as if shielded, and a quick strike, as if deflected. Thus, a parried projectile would lose inertia; but a deflected projectile may gain inertia.

 

It's a horribly complex mechanic that is tedious, in part, because it partly relies on tracking every projectile on the screen, to determine its rv, rd, and rI. It's also entirely hypothetical, and probably unnecessary. I'll likely go with a simpler mechanic when I finally set myself to do this. 



#11 Lejes

Lejes

    Seeker of Runes

  • Members
  • Location:Flying High Above Monsteropolis

Posted 21 May 2015 - 08:59 PM

I've heard that there were ways to get items to launch ffc scripts, but for the life of me I can't remember what those are and obviously don't have any scripts right now that do this.



My LttP Bow script I submitted to the database recently does this, and uses a method to skip ever needing to enter a script slot number.


I've also got something like a spinner here. It probably wouldn't be easy to set up paths as it is now, and I'm not especially interested in revisiting it, but there it is.
  • Timelord likes this

#12 Timelord

Timelord

    The Timelord

  • Banned
  • Location:Prydon Academy

Posted 21 May 2015 - 09:53 PM

My LttP Bow script I submitted to the database recently does this, and uses a method to skip ever needing to enter a script slot number.


I've also got something like a spinner here. It probably wouldn't be easy to set up paths as it is now, and I'm not especially interested in revisiting it, but there it is.

 

Thanks Lejes, I'll certainly look over both; probably tonight, or tomorrow. I'm curious precisely how you're evading the slot number... Are you using the script name as an identifier?

 

The spinner is certainly of interest. Is the code for it in the buffer?

 

'Tis. I see you went with combo flags there. For something like this, that's probably best, as if it sees constant use, they work. I just wish there more than five, but at present, I use exactly none of those. I'm still unsure in what project I truly want that kind of item. It's certainly something I'll need use in experimental context.


Edited by ZoriaRPG, 21 May 2015 - 09:57 PM.


#13 Lejes

Lejes

    Seeker of Runes

  • Members
  • Location:Flying High Above Monsteropolis

Posted 21 May 2015 - 10:04 PM

Thanks Lejes, I'll certainly look over both; probably tonight, or tomorrow. I'm curious precisely how you're evading the slot number... Are you using the script name as an identifier?


I am. I'm also using itemdata and some nonsense with button states to prevent the player from spamming other items during the bow's windup period.

#14 ywkls

ywkls

    Master

  • Members

Posted 22 May 2015 - 09:32 AM

ywkls, mate, you really need to shift to the plain-text editor, break up responses, and manually enter quote tags, to make responding to this easier. Dissecting your quote of my response, is a bit painful; and only sets this up for huge block-quoting that will break the field size limits.
 

 

Sorry about that. I'm still not entirely familiar with the system that this site uses. I often have to manually cut out the parts of a reply that I am not referring to when I quote someone because I don't know how to use do it otherwise. Where exactly do I click to use that plain text editor you mention, for example?

 

 

It's a function of ffcscrippt.zh:
 
RunFFCScript(scriptNumber, arrayInput)
 
Thus, if you have an FFC script in slot 20, and it has arg inputs for D0, D1, and D2; in your item script, you do this:
 


 

 

That's a very nice and easy to understand example on running a script from an item. Thankfully, I've gotten far enough in my understanding of Zscript to know what this all means now.

 

 

I have functions that can store if a player has done things on a screen, but, if you only want to know if a player has visited a screen, that is stored as part of the screen state, in Screen->State[ST_VISITED] .

 

If you want to be able to warp to any visited screen, that would require some rather intensive mapping, and really, you;d be better off with user-defined locations. You don't need to draw bitmaps for this though: You can simply make a 'world map' with tiles, and combos, and put it on a screen anywhere in the game, then do a DrawScreenToLayer() with it, on Layer 6, and put a cursor on layer 7.

 

Can you provide some example code of how to use that DrawScreenToLayer function you're referring to? Keep in mind that I still have some trouble with getting Screen->DrawTile to work properly. And how exactly would the cursor you're referring to be controlled? Also, what library is it in?

 

 

Bitmaps are needed when you want to be able to do special distortions, or movements with an image, but not merely to draw it. If you wanted to map to spin on its axis, or curl, or something, you'd need it to be a bitmap, so that you can use it as a render target for the effect.

 

If you only want pre-defined locations (let's say, 8 per overworld), that would be rather straightforward.
 

It sounds like you didn't have the loops set up properly. I'm assuming that, after using the item, you simply wanted to press Up/Down/Left/Right to select the song?

 

If so, you want a conditional trigger, such as while(waiting) with a boolean 'waiting' set to true by default.

 

While(waiting) the ffc does a constant Waitframe(); and if the player presses a button, it (1) stores the direction presses--actually, you can merge both into one condition:

 

          
        
Because the value of pressed is evaluated at the beginning of the loop, if a player presses a button, it will no longer be '0' when the loop evaluates it again, so the code block advances to the if statements. You can muck with the conditions for those as desired, and set up for loops as timers, or whatever visual or auditory effects you want.

 

You'll probably need another boolean (running) set to true at the top, and put while ( running ) loops in each of the 1-to-4 options, so that they last more than one frame, or you could launch a different FFC for each. (That may be the most modular way to build this item.)

 

Pressing a button changes the value of pressed, so the Waitframe() instruction in the == 0 evaluation doesnt execute, and it checks each of the other possible conditions in the listed order. We don't need else-if here, although instead of == 5 evaluation, we could use an else block, but I intentionally avoided an else block, to illustrate that you only need if statements in this example.

 

You can also expand, or contract the inclusive ors to change what buttons trigger a cancel action, if any. I'd suggest having one for this kind of script though, so that a player may back out, before using the item.

 

If you want to display graphics, you;d add the commands to display them in the while(!pressed) block. The script executes anything you put in there, until the player presses a button, so you'd just add your drawing commands before Waitframe().

 

(This, if you're curious, is what in the old days, we'd call an 'until' loop.)

 

Keep in mind that in this loop type, the condition is evaluated before executing any code. You can force events to execute at least once, by changing this to a do-while (do-until) loop:

 

 

That's an example, in which you can trigger an action even if the condition was not immediately evaluated as specified. Thus, if you declared int pressed = 6, it would still do that set of instructions once, then move on, and become confused, because it does not have an else block. That, is where, and why, you would want an else block, as a catch-all; but in the example, it wouldn't do anything, because it would fall at the end of a codeblock outside any loops.

 

I'd expand on it, if you need further information on the matter, but I wanted to give you some examples of how to set up FFC loops, so that you get a sense of how these things work. I'll post a refined version for you, if you desire it.

 

This code is a vast improvement over what I created. Of course, the idea of making a while loop that just did nothing was something that I only recently began to understand. I could post my own coding attempt, which contains no instructions on how to use the songs once they've played. (And doesn't work.)

 

As the end product, I was thinking that there would be one item which would check for the acquisition of other items (for the songs) and when you used it, Link's appearance would change while it was being used (via whatever method would work best) and you could then select only the songs you had learnt

 

As for the songs themselves, one would be a warping around the world; one would trigger special warp points (like I have in another script that already works) and the third would warp you no matter where you were. Sort of a cross between the ocarina and magic mirror from LTTP. I've seen a script that could do the magic mirror and I have a script that does the warping at special warp spots, but not one that does both and warps you around to certain areas.

 

 

I'd suggest leaving that until you are entirely comfortable with using arrays, and working with all the ZScript functions. It's also prudent to see a working example. I have a template somewhere, but it would be gibberish at present.

 

I've yet to fully script my own, so I can't comment from experience, but the process is tedious. I have a general grasp on the method used, but I'd need to tinker with it, especially given the types of information I need to display.

 

My idea for using this is one of those things that hasn't been used (to my knowledge) in a game yet. I'll probably explain it better in my next list of suggested scripts.

 

If you mean standard, RPG turn based encounters, such as Dragon Quest, that wouldn't be hard at all. I was already going to include that in RPG.zh, but I figured that most people wouldn't use it, as it takes away much of the 'action' expected in a ZC quest.

 

Using that, would in fact simplify a great deal of what I've been coding, to make a more 'Ys' /  'Secret of Mana'  / 'Terranigma' style engine.

 

Really? I was thinking it would harder. Truth be told, I only suggested this because years ago I made a very basic Final Fantasy-esque battle system using nothing more than a graphing calculator and a coding language two steps removed from Basic. It is on the basis of what I learned then that I've studied Zscript over the past few months. I'm leaps and bounds ahead of where I was when I started but nowhere near proficient enough to do something like this. It isn't that much of a priority. My system can't run the sort of advanced RPG creation games that exist, so if I want to make a game I'm pretty much stuck using Zelda Classic.

 

 

Thank you CG. That seems to take a random rel velocity, and direction, rather than using the specific initial velocity, momentum, and direction, and comparing it to the angle of the striking force, so indeed, simpler. What I was eventually going to do, is make a direct, relational change, based on speed, and angle of deflection. Immensely intensive, and I'm certainly in no mood for trying it at present, with so much to complete at hand.

 

I understand. I haven't had a chance to try the code Coolgamer012345 posted yet, so I don't know if it would do what I desired.

 

 

Events, are also in the RPG.zh header, stored in the GameEvents[] array. This has an identical index size to the main engine array, GameDynamics[], allowing me to use both in conjunction with one-another. In general terms, most of the vast, sweeping, global functions that change a great deal of datum, work from GameEvents[], whereas smaller, or independent functions, and game datum, stem from, or are stored within GameDynamics[].

 

One can affect the other, and I have special return functions for reading into these with constants.

 

When making a game with many branching options, you're going to use a good number of global variables. ZC has a limit (cap) on global variables that is smaller than the maximum size of one array, so when you walk this path, arrays are not only your best route, but often, your only route.

 

One thing to note, before you start tinkering with them, is the power of the function SizeOfArray().

 

If you start doing array-based functions, you are going to want to use that; and you will likely use it frequently, if you want your code to be modular. It returns the index size of float, and int arays; but not boolean arrays.

 

Thus, if you want a boolean array that is compatible with SizeOfArray, declare it as an int. Any 0 value will return false, and any non-zero value will return true. Either that, or you may want two arrays, of the same size, that work in conjunction, as I've done with the two that I detailed above. I use a boolean array for GameEvents because of how I write to it in some spots, but I could just as easily use a float, or int array to accomplish the same job.

 

Returning int 0 as false is something that ZC is nice about, as typecasting of this sort varies by application. You cannot however, go the other way 'round. If you try to write a numeric value to a boolean array, you'll see a nice error in response.

 

You can declare all arrays as floats too. I don't, as I declare them based on my intent, but floats in ZC are genuine ints, and can work as floats, ints, and booleans.

 

 

Arrays are one of those things I've always had trouble with. My ideas for events are really much, much simpler. For example, one game I made in RPG Maker 3 on PlayStation 2 had a series of events (read ffcs for Zelda Classic) that would never activate unless you went up to them and examined them. If you did, it would increment an in-game counter. If you get to a certain point in the game and the counter was a above a certain level, you'd go one way. If not, another.

 

In Zelda Classic, you could have secrets triggered that led to one set of one-time events if you went one way and another set for the other. The player would never know that the other events existed unless the counter and associated ffcs were reset to their original status. Or you could have it where all the triggered events were only available through one-time events and if you didn't trigger them, secrets wouldn't be activated on another screen that led to more one-time events.

 

 

P.S. What editor are you using when writing ZScript?

 

Currently using Notepad, because my standard word processor doesn't format it right and I can't afford to pay for anything else. Look for more outlandish scripting ideas later!



#15 Lejes

Lejes

    Seeker of Runes

  • Members
  • Location:Flying High Above Monsteropolis

Posted 22 May 2015 - 01:27 PM

You should switch to Notepad++. It has useful things like line numbers and brace pairing, and it's also free.


  • coolgamer012345 likes this


0 user(s) are reading this topic

0 members, 0 guests, 0 anonymous users