Carrying over slashed bushes.

[Joe123]

Is there any way in which I can cary over whether a bush has been slashed or not to a duplicate screen?

[Master_of_Power]

maybe with FFC combos.

[Joe123]

how would I do that with freeform combos? do you mean with a script?

[ShadowMancer]

Unless something is set as a perment secret it will reset its state between screens, mabye something could be scripted with an FFC script. the bush would be there as you are entering the screen and once the script kicks in it will become a slashed bush. Now the question is do you want it to just keep track of one said bush on one screen or something massively insane like keeping track of any bush on any screen. Keeping track of one or two bushes is pretty easy just watch the specified bushes:


//check if the bush is already slashed when you enter the screen
if (*global varible* == true/1) {Screen->ComboD[n] == *slashed bush*}
while(true)
//
if (Screen->ComboD[n] == *slashed bush*) {*set a global varible to true/1*}
Waitframe();


(Man I'm lazy today)

[Joe123]

Now the question is do you want it to just keep track of one said bush on one screen or something massively insane like keeping track of any bush on any screen.

Answer number 2 would be preferable :)
For now, I want to be able to keep track of about 4 bushes on any given screen, and preferable at what state they've regrown to also. I reckon I could write this myself however. Possibly. I don't know.

EDIT: although I'd need to know how to do it really, I'm not quite sure without using a seperate global integer for each bush. Which obviously would be very bad.

[ShadowMancer]

Well, once we get arrays it would be much simpler. (right now I have been thinking of some functions to simulate arrays, not too hard to do)
Also, mabye you can use the screen registers but I am not sure if the values save or are reset when you leave the screen
if they do save:


//use the arguments of the FFC for the positions of the chosen bushes
//you can have up to 8 chosen bushes like this
ffc script bushTracker{
void run(int bsh0, int bsh1, int bsh2, int bsh3, int bsh4, int bsh5, int bsh6, int bsh7){
//check if the bush is already slashed when you enter the screen
if Screen->D[0] == 1) {Screen->ComboD[bsh0] == *slashed bush*}
if Screen->D[1] == 1) {Screen->ComboD[bsh1] == *slashed bush*}
if Screen->D[2] == 1) {Screen->ComboD[bsh2] == *slashed bush*}
if Screen->D[3] == 1) {Screen->ComboD[bsh3] == *slashed bush*}
if Screen->D[4] == 1) {Screen->ComboD[bsh4] == *slashed bush*}
if Screen->D[5] == 1) {Screen->ComboD[bsh5] == *slashed bush*}
if Screen->D[6] == 1) {Screen->ComboD[bsh6] == *slashed bush*}
if Screen->D[7] == 1) {Screen->ComboD[bsh7] == *slashed bush*}
while(true){
if (Screen->ComboD[bsh0] == *slashed bush*) {Screen->D[0] = 1;}
if (Screen->ComboD[bsh1] == *slashed bush*) {Screen->D[1] = 1;}
if (Screen->ComboD[bsh2] == *slashed bush*) {Screen->D[2] = 1;}
if (Screen->ComboD[bsh3] == *slashed bush*) {Screen->D[3] = 1;}
if (Screen->ComboD[bsh4] == *slashed bush*) {Screen->D[4] = 1;}
if (Screen->ComboD[bsh5] == *slashed bush*) {Screen->D[5] = 1;}
if (Screen->ComboD[bsh6] == *slashed bush*) {Screen->D[6] = 1;}
if (Screen->ComboD[bsh7] == *slashed bush*) {Screen->D[7] = 1;}
Waitframe();
}
}
}

Well, try it anyway. Not sure if Screen->D[] saves when moveing from screen to screen.

[Gleeok]

You don't need a script to carry over ffc's though. If you can combo cycle them wouldn't they just carry-over in that state?

[ShadowMancer]

I am not talking about useing the FFC to display the bush the FFC would be invisible (sorry if I was not clear on this) I suppose a global script would work better, but still not sure on the beheivor of Screen->D[]

[Praethus]

I think you guys aren't looking at the underlying problem. Why are you having to change to identical screens Joe? Perhaps a script would prevent that and make this whole conversation irrelevant.

[Joe123]

I'm not changing two identical screens, I have two identical screens because that's how you make things work... I have a pitwarp from the first one to the second that you disable at a later date. I want the bushes to carry over in the correct state from the pitwarp.

And I shall give that a try, shadowmancer, thanks. Maybe in an hour or so. Also, would it be easier if I set the bushes just to be FFCs and have them carry over Gleeok? It would rely on consistent combo cycling of FFCs (which I'm still not convinced of), and Bush->Next (item) and Slash->Next combos working with FFCs.

[ShadowMancer]

Bush->Next (item) and Slash->Next combos working with FFCs.
Well this is not going to be fixed until after 2.5

I guess I did not understand your original question, now I do. You could use carryover FFCs to do the job, just place an FFC over each bush you want to tag for state carryover. The FFC will be invisible.


//Argument 0 will be the current screen and Argument 1 will be the current map
ffc script bushState{
void run(int screen, int map){
while(true){
int bshCmbo = Screen->ComboD[comboAt(this->X,this->Y)]
//Check if you are on the duplicate screen
if (Game->GetCurScreen() != screen && Game->GetCurMap() != map)
{Screen->ComboD[comboAt[this->X,this->Y)] = bshCmbo}
}
}
}


That might work for you, although if you switch between original and duplicate screens more than once it may not work right.

[Praethus]

I'm not changing two identical screens, I have two identical screens because that's how you make things work... I have a pitwarp from the first one to the second that you disable at a later date. I want the bushes to carry over in the correct state from the pitwarp.

And I shall give that a try, shadowmancer, thanks. Maybe in an hour or so. Also, would it be easier if I set the bushes just to be FFCs and have them carry over Gleeok? It would rely on consistent combo cycling of FFCs (which I'm still not convinced of), and Bush->Next (item) and Slash->Next combos working with FFCs.

You misunderstood my question. What is it you are trying to accomplish that requires 2 identical screens? Perhaps you can get a script that accomplishes the same goal without 2 screens. I know that alot of tricks used to use identical screens. I know, I've used them. But scripting has reduced alot of those needs now, and maybe the solution is simpler than everyone thinks.

[Joe123]

Urr, it's the screen before you walk into a village. First time round, you have to get the sword and things, after that I want it to be different. Could I just make the sidewarp change via a script or something like that then?

[Praethus]

Ok, how about this.

Scenario A: First time. Nothing

Scenario B: After Sword. Link needs to go to the second screen.

How about, when Link walks onto the screen, you have a Script that checks if Link has the sword. If so, it warps Link to the second screen, before he has any chance to interact with anything on the screen. Then, there's no reason to have to carry over anything. He'll be on the second screen from the second frame.

This seems like a much simpler solution.

[Joe123]

Ah, I'm liking that idea actaully. At the moment, I have it to check whether Link's Y coordinate is at a certan point (so theorically I have a trip-wire drawn across the screen at Y=144), which if you walk past it you get warped. But your idea (or at least, what I could do with it if I thought it out a bit better, I think I'd rather have a global integer that you change somewhere else but that's beside the poing) is a lot better. Thankyou, you've just improved and simplified the making of my game enormously.

[Praethus]

As I said. Sometimes you have to look at how to fix the cause of the problem and not the problem itself.

[Joe123]

* Fixed a deficiency with warps by adding an overlay flag to tile, side, and whistle warp types. When this is set, any combo on the new screen that is 0 will be replaced with whatever combo is in that position on the old screen. This allows combos to carry over (slashed bushes, for example).

Does this make them possible now anyway?

[Praethus]

Sort of. It means you can only enter that screen from a Warp. Otherwise, you'll have a bunch of 0 combos on the screen.

[ShadowTiger]

It said side and whistle warps too though. (I'd assume timed warps as well, due to the fact that they use Side warps, which were mentioned.)

It sounds almost like it'd operate similar to the Flags placement mode; how you'd lay down different flags on top of combos to apply their own unique properties. I just hope it won't act as another flag, and will be its own separate layer of operations. It sounds so very useful like this though. It could be opening the door for very useful new features in the future.

[Dark Nation]

It works just like it says. Put combo 0 where you want the old screen to show through. The combo, cset, and flag at that position will be used instead. And, yes, it works with timed warps. That was, in fact, the main reason for including it on the side warps.

[ShadowTiger]

Ah, so it's a regular flag? (Flag 98 or something?) ... that is placed on the Combo 0 combos on the screen that we warp to from the (Hopefully) identical screen. Hm. Interesting. Very. Do flags carry over onto such a screen, assuming all options based on such an intent are checked and enabled? (Such a question leads to the inevitable inquiry as to if those overlay flags can somehow be overwritten or overrided or destroyed before experiencing their effects, OR, worse yet, if their presence can undermine any double-flagged combo spaces there.)

[Dark Nation]

No, it's not a flag. It's an option in the warp editor. When you use a tile, side, or whistle warp and the warp has the overlay option turned on, any spots on the warp destination screen that use combo 0 will be overwritten with the combo, cset, and flag of the same spot on the warp origin screen. Inherent flags are tied to combos, so, yes, they come along as well. I *suppose* I could make it where combos and flags (not inherent flags) can carry over separately (if the combo on the new screen is 0 but the flag is not, then the old combo and new flag will be used, or if the new flag is 0 but the new combo is not, then the old flag will be used with the new combo).

[Joe123]

Does this also effect layers?
It's unlikely you'd want layers where the blank space is combo 0 filling up with combos from the last screen I think.

[Dark Nation]

Yes, it does. Layers carry over to the next screen. If you want a layer to disappear, use a blank combo that is not combo 0.