Qhimm.com Forums
Miscellaneous Forums => Scripting and Reverse Engineering => Topic started by: Akari on 2006-12-11 06:43:25
-
I can't find how LINE opcode works. It defines line, but what script calls after that? Can someone give me full description how LINE opcode works?
-
I think you treat it as you would any other entity. That is, Script 3 is "On Enter", 4 "On Leave", etc. (though I'm not 100% on which does what).
-
So basically the LINE opcode creates the physical entity like loading a model that's an entity as well? Each entity has 32 scripts etc. So the LINE opcode would be used in Script 0 during initiation of the location. As for locations that use it, hmmm I am pretty sure any place you automagically jump like on the Corel Tracks FIELD location (the one with the save point). It would be used there in any case. (That should have an interesting walk map.)
64K total size for all scripts related to the field location? And up to 64k for dialog data. Then AKAO blocks for sound (hence why they used 32bit pointers because the section can be longer than 64K), kind of big now that I think about it.
Cyb
-
I think you treat it as you would any other entity. That is, Script 3 is "On Enter", 4 "On Leave", etc. (though I'm not 100% on which does what).
Next: What will happened if I define two or three lines in entity? Will they all call 3/4 scripts or next definition will delete previous line?
ps: Only PC activates line?
-
All great questions. :-D Leave it with me, should have some time later today.
-
Mmm and it looks like Script 5 calls all the time while you are on line. I look at NMKIN2 and there button check before go to ladder, so you need to stay still on line and press button. Am I right?
The script 3 calls on line enter.
Where did they use OnLeave script?
ps: And what about SLIDR. Any ideas?
-
Think you're right about script 5. Similarly, script 6 is often used by save points to play the sound and the dialog about saving your game when you are stood inside the save point object. As far as I can remember, the difference between 5 and 6 is that 5 executes repeatedly, 6 only plays once (and won't execute again until you leave and re-enter the object, or line in this case).
Will have a further look, I'm just going to take a look at your questions. :-P
[Edit]
Yes, one entity can define multiple LINEs and they will each exist & execute the relevant script, so there's no cancelling out of previous definitions. Only the PC activates the line (another entity crossing it won't activate it).
[Edit2]
Script 2: Activates once when a button is pressed.
Script 3: Activates once when you move into the object/line. When you stop, and then move again, the script activates (provided you're still in the object/line, of course).
Script 4: Not sure. Seems similar to 3
Script 5: Activates repeatedly whilst you are on the object/line.
Script 6: Activates once when you move into the object/line; will not reactivate until you leave and re-enter.
Script 7: Activates once only when you have left the object/line.
The remainder are not object/line-specific and won't be activated by any object movement. Of course any of these script numbers can be used for general-purpose scripts if it's not a visible entity.
[Edit3]
SLIDR is related to SOLID since it's the opcode before SOLID, and is used in conjunction with it in "condor1", a very simple field. It's used three times, once for each playable character that can be played during the game (Cloud, Tifa, Cid), along with the SOLID opcode in a separate script. Interestingly, it's SLIDR(0, 22) for Cloud and Cid (common after moving towards a ladder before LADER is called), and SLIDR(0,1E) for Tifa. It also comes after TALKR opcode. So I guess the question is, what is "R" :-D
Here's the relevant script clips for some clarity. This is talking to the guy that wants help in Fort Condor, and having said yes, you'll help...
ojisan, Script 2:
WindowDialog(1,7) //“Really!? Then go on up and they'll fill you in on the details.â€
Request(cloud[3],5,REQ_SYNC) // See below
ObjectSolid(Off)
MovementSpeed(0,0,8)
ObjectMove(63,-45)
Request(cloud[4],5,REQ_SYNC) // See below
TLKON(1)
ObjectSolid(Off)
ObjectVisible(Off)
cloud, Script 3:
main:
ObjectSolid(Off)
return
cloud, Script 4:
main:
SLIDR(0,34) // 0x22
return
[Edit4]
Sorry for talking to myself. :-D I think it's Range - Talk Range, Solid Range. Still looking at it.
-
Okay, enough editing, think this warrants a double post. SLIDR does as I thought above - sets additional "range" for a solid object; larger numbers increases the bounding volume. The first value is a bank/address option. I tested this by adding it, and a SOLID set to on, to the On Press script for the guy in Cosmo Canyon; a small number like 2 means you can get really close to him (but not pass through him still), a larger number like 0x40 means there's always a fair distance between you and him, and 0xF0 was so large a value that I couldn't move away from him cos he'd turned SOLID when I pressed it and I was stuck inside his volume, so to speak. :-D
Now, what this means for LADERs is that when a button is pressed near a ladder, the character's bounding volume is reduced to what is essentially zero - SLIDR(0,1). The bounding volume is made so small that when the character moves to the bottom of the ladder, they do not retrigger the LINE. This is the important bit. Then, when they have correctly moved across the line to the bottom of the ladder, the bounding volume is set back to normal with a SLIDR(0,22).
Example from cos_btm. This is inside the character entity and is trigger by a button press on a LINE. The key point is we don't want the character, moving towards the ladder by the following script, to retrigger the LINE otherwise we'll probably end up retriggering it over and over.
main:
CharMovable(Off)
MenuAccess(Off)
SOUND(0,15,0,40) // Play the "mount ladder" sound
SLIDR(0,1) // Reduce the bounding volume effectively to zero
MOVE(0,88,FE,A7,FB) // Move to the bottom of the ladder - reduced volume means character WON'T retrigger the line
SLIDR(0,22) // Put bounding volume back to normal
CharMovable(On)
MenuAccess(On)
LADER(0,0,83,FE,10,FB,EC,F5,E6,0,0,3,80,1) // Climb ladder
return
SLIDR (http://wiki.qhimm.com/FF7/Field/Script/Opcodes/C6_SLIDR), SLDR2 (http://wiki.qhimm.com/FF7/Field/Script/Opcodes/D7_SLDR2), TALKR (http://wiki.qhimm.com/FF7/Field/Script/Opcodes/C5_TALKR), TLKR2 (http://wiki.qhimm.com/FF7/Field/Script/Opcodes/D6_TLKR2) added to the wiki.
-
Great!! You are genius!! =)
And a lot more opcodes for me to implement =)
-
Wow... Ok what about the tracks in going to North Corel?
When you fall down a hole does this trigger a minigame system for climbing up? OR are these ladders and when you press a button you grab the grid. There is likely a line in it somewhere so when you cross it cloud automagically grabs the ladder. (IE LADR is activated or some such) The entities then are the sacks and when you hit there bounding volume and press X it's obtained. They must then change the line entities function after you have grabed something in this part. So that must be a variable somewhere in the game.
I was wondering how they handled the little pin ball juke box system in Tifa's bar. When you press on the entity what does it do to move you down below? I know it changes the field after you disappear.
Cyb
-
mtcrl_5 will tell you all you need to know, Cyb, tis the field for the falling tracks bit. :wink:
(http://fusionblue.sr34.co.uk/sb/mtcrl.jpg)
No LINEs here, but plenty of OFST to move Cloud (see below, the opcode used for the pinball elevator) and scroll opcodes (a good one for Akari to test with I think since he's doing the scroll opcodes soon). It does use LADERs to allow Cloud to climb back up.
Clearly, you were spot on about the entities, I selected one so you can see the model details, etc. Cloud is the one on the bottom but that's probably just the way Meteor handles multiple XYZIs in one entity.
The pinball elevator will probably just be an OFST, in this case set to linear motion type, just like all other elevators (Bugenhagen's machine for example).
[Edit]
Cyb: thanks, having looked at mtcrl_5 I've figured out the exact usage of AXYZI;
Akari: I've also added TLKON which fits with TALKR.
-
Looks like I need to actually use those tools (mutter) to look at locations! Argh ;)
Anyhow glad me pointing something out was of assistance. What I am suprised about are the walk meshes they used on that field location.
Is that view the initial camera matrix? What about the inputs for moving left or right as you fall? Also the line spots I was refering to was the one that gains access to that particular area. I suppose I'll need to mount ye olde CD and look around some.
Cyb
-
Mmm by the way, isnt PXYZI stores coords of party char?
update:
About Talk collision. What will happened if two collision range intersect? Will both entity scripts started when we try to activate dialog?
About collision itself. Hmmm Collision Range... again I start thinking that there are no box collision but simple distance between objects. It's much more simple to create and much faster. And it will work. Please try increase solid range as much as you can and check is this box, or circle (distance). Please =)
-
Might I suggest...
Even though finding all the wierd instances on how a particular opcode works, a lot of the time, I'm guessing, much of the functionality was undefined. Implementating a basic function, (with a little sanity to make sure the opcode doen't smash itself), is a good idea for rapid prototyping of a function.
I say this not because I want the opcode implmentation to go faster, (I'm always stunned by Akari's progress), but I want to avoid over-engineering. When things get to an executable stage, I'm sure there are Final Fantasy 7 fans who can nitpick on a finer resolution than we can. To me, a "distanse to" as opposed to a bounding box makes much more sense from an effecincy standpoint. Keep in mind this program was originally designed for a very low-power MIPS CPU with no FPU. I don't know how much of the GTE was used with the 3D maths beyond your typical OT (polygon render order) constuction. (Keep in mind the GTE is a kind of a [fixed point in -> internal floating point process -> fixed point out] device that was prone to rounding errors.)
However if I remember, bounding box data is contained in the model data, that might be an artifact of PSY-Q though.
The upshot: Don't take the trees for the forest. When the implmentation starts running, all the small bugs will become obvious.
-
Might I suggest...
Even though finding all the wierd instances on how a particular opcode works, a lot of the time, I'm guessing, much of the functionality was undefined. Implementating a basic function, (with a little sanity to make sure the opcode doen't smash itself), is a good idea for rapid prototyping of a function.
Mmm I just try to make it clear to myself, because the implementation may differs depending on this.
By the way, one more question: How NPC climbing on ladders? Are they start moving to the end as soon as LADER opcode calls?
-
About Talk collision. What will happened if two collision range intersect? Will both entity scripts started when we try to activate dialog?
No; it's much like normal talking between two entities close to the player, just with the ranges extended. If two talk ranges overlap, then when you press the button to talk, the closest entity - in terms of angle between player and entity - will talk, irrespective of distance between player and the entities. Much like normal talking though, if you face south as well, like the entities, no-one will talk, since you're facing away from them, so the usual angles apply when it comes to whether they talk or not.
Here's Wutai with huge talk ranges for both the man and the kid; the kid's started speaking.
(http://fusionblue.sr34.co.uk/sb/when.jpg)
About collision itself. Hmmm Collision Range... again I start thinking that there are no box collision but simple distance between objects. It's much more simple to create and much faster. And it will work. Please try increase solid range as much as you can and check is this box, or circle (distance). Please =)
It's a circle. But in testing with the man in Wutai I noticed odd behaviour; I increased his solid range to 0xFF. I think his new collision circle was colliding against the side of the walkmesh (since he starts quite close to the edge) and he ended up getting stuck during his walk cycle. The odd thing was that his direction was changing as he walked on the spot, and as he did so the collision circle changed. When he faced west I couldn't get past the collision circle; when he faced north I could get by the side of it and the circle shifted up somewhat so that at the top at least I couldn't get as close. So it seems to be affected by direction... oddly.
By the way, one more question: How NPC climbing on ladders? Are they start moving to the end as soon as LADER opcode calls?
They switch to "climbing mode" as soon as LADER is called so that the player can move from end-to-end with the keys. The Wiki entry should explain it.
-
It's a circle.
Just as I thought. Then I will remove ODE and add new collision detection routine. It will be much easier if we knew this from the start.
By the way, one more question: How NPC climbing on ladders? Are they start moving to the end as soon as LADER opcode calls?
They switch to "climbing mode" as soon as LADER is called so that the player can move from end-to-end with the keys. The Wiki entry should explain it.
No, not the pc entity, but entity like Jessie's in NMKIN3 map when she climbing down the stairs herself.
-
Oh, missed the NPC part of your question :-D. Yes, an NPC entity using a LADER will automatically move to the end point of said ladder.
-
Oh, missed the NPC part of your question :-D. Yes, an NPC entity using a LADER will automatically move to the end point of said ladder.
One more question about LADER - is it a waiting-type opcode? I think it must stops the script execution until we reach start or end of ladder.
-
is it a waiting-type opcode? I think it must stops the script execution until we reach start or end of ladder
Correct.
-
Akari: added SLINE (http://wiki.qhimm.com/FF7/Field/Script/Opcodes/D3_SLINE) which may be of interest since you have implemented LINE, I think. Of note is that whilst you can define multiple LINEs in one entity as mentioned previously, SLINE only allows you to update the first defined LINE; multiple calls to SLINE will still only update the first one.
-
Akari: added SLINE (http://wiki.qhimm.com/FF7/Field/Script/Opcodes/D3_SLINE) which may be of interest since you have implemented LINE, I think. Of note is that whilst you can define multiple LINEs in one entity as mentioned previously, SLINE only allows you to update the first defined LINE; multiple calls to SLINE will still only update the first one.
Ok. I'll add this to my todo. But... hmm I didn't know that we could define a lot of lines in one entity. Is this used somewhere?
-
No, it's not used in the game as far as I know, but you did ask up there ^....
Next: What will happened if I define two or three lines in entity?
Yes, one entity can define multiple LINEs and they will each exist & execute the relevant script, so there's no cancelling out of previous definitions.
Don't worry about it, I'd say it's an undefined behaviour.
-
No, it's not used in the game as far as I know, but you did ask up there ^....
Next: What will happened if I define two or three lines in entity?
Yes, one entity can define multiple LINEs and they will each exist & execute the relevant script, so there's no cancelling out of previous definitions.
Don't worry about it, I'd say it's an undefined behaviour.
Ups sorry. I didn't notice that (or forgot it). ^^''
-
Script 2: Activates once when a button is pressed.
Script 3: Activates once when you move into the object/line. When you stop, and then move again, the script activates (provided you're still in the object/line, of course).
Script 4: Not sure. Seems similar to 3
Script 5: Activates repeatedly whilst you are on the object/line.
Script 6: Activates once when you move into the object/line; will not reactivate until you leave and re-enter.
Script 7: Activates once only when you have left the object/line.
I have few more question about it.
1) As I can see script 3 activates on collide with solid range or line and script 4 activates when point cross line (point that defined entity position). Synergy Blades can you confirm it?
2) I cant activate script 4-7 to field object although they all works with LINE. Maybe they are not working with field object at all? Script 3 always RET in field objects although Script 4 may be defined. Does this true? Can you check it?
3) Script auto activation don't work if entity not solid?
-
1) Yes... I think that's right. Of course for Script 4 you can't really test this with a field object, because to produce it the entity must be solid (see point 3), but if you try it with a LINE such as a save point, script 4 only works right in the very center of the line, whilst script 3 (and indeed 5 to 7) activates right along the line. So I think this is a reasonable assumption.
2) 4 to 7 don't seem to work with field objects, as you suggest, solid or not. This isn't like point 1, where it only works in the center of the object/line, because if you try these scripts on the LINE they work anywhere along it, unlike with Script 4 where you have to be right in the center. So yes, LINE only.
3) If it's not solid (i.e SOLID(1)) none of these special scripts activate. That's why save points have an extra entity using a LINE to do the dialog and sound they produce.
-
1) Yes... I think that's right. Of course for Script 4 you can't really test this with a field object, because to produce it the entity must be solid (see point 3), but if you try it with a LINE such as a save point, script 4 only works right in the very center of the line, whilst script 3 (and indeed 5 to 7) activates right along the line. So I think this is a reasonable assumption.
2) 4 to 7 don't seem to work with field objects, as you suggest, solid or not. This isn't like point 1, where it only works in the center of the object/line, because if you try these scripts on the LINE they work anywhere along it, unlike with Script 4 where you have to be right in the center. So yes, LINE only.
3) If it's not solid (i.e SOLID(1)) none of these special scripts activate. That's why save points have an extra entity using a LINE to do the dialog and sound they produce.
mmm I still don't see whole picture =(
In case of line: whats the difference between 3 and 6? They both works OnEnter... whats the difference?
What do you mean by the very center of the line? (Line 1---------2---------3) It only activate when you reach point 2 and not activated when you reach 1 or 3? And does this includes solid range of PC entity or not?
And I have one more question, does line have talk range and can it be talked to?
Please write the all auto script activation for line and field object.
-
I think he means when the center of the characters body crosses the line. That would be my guess.
Cyb
-
I ought to start by saying that I think a line has a designated talk and solid range (that cannot be changed with SLIDR/TALKR, I tried). It's only a small amount, but it's enough that it makes sense to be able to "enter" and "leave" a line (or more precisely, its range) and talk to it from a specific distance.
What do you mean by the very center of the line? (Line 1---------2---------3) It only activate when you reach point 2 and not activated when you reach 1 or 3? And does this includes solid range of PC entity or not? And does this includes solid range of PC entity or not?
Seems I wasn't quite right on script 4. It's the center point of the character object that has to enter the line, i.e this disregards the Solid Range of the object entering the line.
whats the difference between 3 and 6?
3 activates once when you move within the line range; when you stop, then move again, it activates again. With 6, it activates once when you are within the line range, but you have to leave the line area and then re-enter it for it to activate again. This stops it from repeatedly activating whilst you move along the line.
And I have one more question, does line have talk range and can it be talked to?
You can talk to a line, but it does not have a talk range (TLKR has no effect). So I suppose talk range is tied to the field object whilst lines have a predetermined talk range, which is probably the same as its "solid range" used for entering/leaving the line.
So in the end I think it boils down to this:
Line
- 1: Init
- 2: OnTalk - the talk button has been pressed with the character on the line's range; script activated once.
- 3: OnMove - the character has moved whilst on the line; script activated once. Move again on the line, and the script activates again.
- 4: OnCenter - the center point of the player object has moved on the line; script activated once. Move again on the line, and the script activates again. Disregards solid range.
- 5: OnInside - the character is on the line range; script activated repeatedly, once every frame.
- 6: OnEnter - the character has entered the line area; script activated once. Move again on the line, nothing happens. Must exit and re-enter line range for effect to occur again.
- 7: OnLeave - the character has left the line area; script activated once. Move again on the line, nothing happens. Must exit, re-enter, and re-exit the line range for effect to occur again.
Object
- 1: Init
- 2: OnTalk - the talk button has been pressed; script activated once.
- 3: OnMove - the character has moved onto/touched the edge of the solid range; script activated once. Move again whilst still on the edge of the solid range, and script activates again.
OnCenter cannot be used because the center of the player character object cannot reach the solid object; OnInside, OnEnter and OnLeave also do not work with objects, only with lines.
If I seem vague or it seems like I'm not answering your question, my apologies, it's mostly because I am unsure myself. :-D Not always easy to explicitly say what it appears to be doing by observation.
-
Hello again Synergy Blades =)
Can you try to guess at which priority scripts run. Cause they seems not run at priority 0. There are a lot of conflict when i try to run some script and this priority already taken.
Please try to run cycled script in some slot and watch if script activation runs or not. We only know that slot 7 are reserved for initialisation base script.
-
I assume you mean LINE scripts, when executed by a field object crossing? I put a cycled request (http://wiki.qhimm.com/FF7/Field/Script/Opcodes/02_REQSW) in the director script, that executed the script from the line entity which when crossed, plays a sound and waits for about a second. So I can hear once a second or so the save point sound. If you cross the line, the sound plays instantly, no matter what stage of execution the cycled sound is at. So would it be right to say the line script runs at top priority, like the initialisation?
-
I assume you mean LINE scripts, when executed by a field object crossing? I put a cycled request (http://wiki.qhimm.com/FF7/Field/Script/Opcodes/02_REQSW) in the director script, that executed the script from the line entity which when crossed, plays a sound and waits for about a second. So I can hear once a second or so the save point sound. If you cross the line, the sound plays instantly, no matter what stage of execution the cycled sound is at. So would it be right to say the line script runs at top priority, like the initialisation?
Mmm.... I dont understand what you did =)
Two tests:
Create entity with line.
Start cycled script at slot 2 (OnEnter) with priority 0
Then enter this entity.
Result?
Create entity with line.
Start script at slot 2 (OnEnter) with priority 0 and make it wait for something. (Message for example)
Then enter this entity.
Result?
-
I finalize the info about script activation. I finish reversing this part of code.
Everything Synergy Blades talk was true.
Line
* 1: Init
* 2: OnTalk - the talk button has been pressed with the character on the line's range; script activated once.
* 3: OnMove - the character has moved whilst on the line; script activated once. Move again on the line, and the script activates again.
* 4: OnCenter - the center point of the player object has moved on the line; script activated once. Move again on the line, and the script activates again. Disregards solid range.
* 5: OnInside - the character is on the line range; script activated repeatedly, once every frame.
* 6: OnEnter - the character has entered the line area; script activated once. Move again on the line, nothing happens. Must exit and re-enter line range for effect to occur again.
* 7: OnLeave - the character has left the line area; script activated once. Move again on the line, nothing happens. Must exit, re-enter, and re-exit the line range for effect to occur again.
Object
* 1: Init
* 2: OnTalk - the talk button has been pressed; script activated once.
* 3: OnMove - the character has moved onto/touched the edge of the solid range; script activated once. Move again whilst still on the edge of the solid range, and script activates again.
Little addition:
Visible entitys OnTalk only work with first entity that wish to activate script. All others will be skipped.
Lines activate all OnTalk request.
Lines OnTalk activates during move. If your coordinates not changed - OnTalk will not be activated.
All sctipts starts at priority 1. Like all other requests if entity already execute script with higher or same priority - request will be skipped.
I think this is topic is finished =)
-
First of all I am glad people are still working in spite of loosing our fearless leader <TM>
:D
As I am uncertain where to start I started by getting OGRE demo's compiling on my machine.
Erstwhile (back to what you were speaking of). Interesting it looks like it fires an event and the first object catches it.
This is kind of like Kingdom Of Kroz coding (early 90's game on the PC) with objects. I am now suspicious of how the script code was generated.
My guess is it's not entirely written script code i suspect they may have made some tools for making things work.
In general I throw debug code into my stuff to spew out things when needed/wanted or desirable.
Have either Akari or G found said code? From my perusal of FF7's it appears there is some in there (printf format specifier strings appear in the program). These go out to the console correct? Hmmm
Cyb