http://sdrv.ms/1aArCRG
This quest file has the scrolling for sideview and overhead done pretty much perfectly.
The rest of what it's going to be able to do is up to you anyway if you are going to make a quest file with it.
If you know scripting you'll know what I mean when you follow the function's layout.. It's all pretty self explanatory. A simple copy/paste of the code with a definition of what combo property shows up where will get you what you need.
I'm going to be taking a prolonged hiatus from actually doing the coding myself, and the description in the script file isn't done very well, so I'll still answer questions if there are any here and on PureZC every now and then if and when they arise.
A few notes on how it's written for the scrolling though:
In the combo set, there's some *INCOMPLETE* combo spots where I started to combo out the items graphics and the enemies combos. When those combos are placed on the map that has the scrolling on layer 0, they appear on the game. There's a method I wrote that says the enemies only start moving when the sword hits them, or is a certain distance from them: That's optional. You could just as easily put it back the way it was originally so that the enemies spawn immediately upon Link (or whatever your character is) coming into proximity of the combo, like the items are set up for. Just duplicate what the item's thing looks like if you're having trouble doing that and it's what you want.
Also, I don't remember, and I can't access the file right now because I don't have ZC anymore, and I'm not going to download it on this computer I'm on atm, but I think the isSolidScreen() function is outdated..
I was redoing the code so that it could do an isSolidScrolling(x,y) function that didn't require a current screen or DMAP input that would calculate the current screens drawn on the actual screen (by current screens I mean as they are drawn in ZQ, by actual screens I mean what is drawn in ZC while playing the game.) and it could do an isSolid() function based on the actual (x,y) as the screens are drawn.
I'm sure that if you are smart enough to figure out how all that stuff really mathematically works out, you're probably smart enough to write it up yourself though. It was basically calculated by the overall X,Y of Link's postion on the ENTIRE DMap, the numbers Z[0] and Z[1] are/were the X, Y.
S==Screen. x==current X as drawn in ZC. y==current Y as drawn in ZC. (if you look at the script, these digits are actually b and a, respectively, and calculated by a similar function to this, but backwards:)
int a=Z[0]-Z[5]; if(a<0)a=0;
ScreenX=Floor((a+x)/256);
int b=Z[1]-Z[7]; if(b<0)b=0;
ScreenY=Floor((b+y)/176);
So given that Screen X is the distance by this calculation in Screens from the leftmost side, i.g. Screen 0 would make Screen X=0, screen 17 would make screen X=1, etc...
and that Screen Y does the same thing, for the Y axis from the top down...
From that we can calculate from Z[0] and Z[1] that
S=ScreenX + ScreenY*16.
After that I had plugged that in and modified the isSolidScreen to not need input args for the current DMap or screen by using Game->GetCurDMap()+1, plus1 because Link is always on the "subfloor" for scrolling, you could see why if you read how it works.., as the arg for Game->GetComboSolid(GetCurDMap()+1,S,x,y).
The x and y are already precalculated for you. It's all already precalculated for you... in fact you don't even really need to know this unless you are going to do what I was planning on and modify Ghost.z to work with scrolling....
Replace the isSolid with isSolidScrolling and the rest of the things with Game->GetComboType, GetComboFlag, etc.. and use the b and a integers as they are calculated instead of only what it looks like in ZQ and presto, ghost.z for scrolling.
Any questions about this feel free to write me on this thread, PM , or ask someone else who knows what they're doing.
Have a nice day!
