About LINE opcode.

[Akari]

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?

[Synergy Blades]

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).

[Cyberman]

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

[Akari]

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?

[Synergy Blades]

All great questions.  Leave it with me, should have some time later today.

[Akari]

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?

[Synergy Blades]

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. 

[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" 

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:

Code: [Select]

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:

Code: [Select]

main:
ObjectSolid(Off)
return

cloud, Script 4:

Code: [Select]

main:
SLIDR(0,34)    // 0x22
return

[Edit4]

Sorry for talking to myself. I think it's Range - Talk Range, Solid Range. Still looking at it.

[Synergy Blades]

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. 

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.

Code: [Select]

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, SLDR2, TALKR, TLKR2 added to the wiki.

[Akari]

Great!! You are genius!! =)

And a lot more opcodes for me to implement =)

[Cyberman]

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

[Synergy Blades]

mtcrl_5 will tell you all you need to know, Cyb, tis the field for the falling tracks bit. 



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.

[Cyberman]

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

[Akari]

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 =)

[halkun]

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.

[Akari]

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?

[Synergy Blades]

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.

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.

[Akari]

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.

[Synergy Blades]

Oh, missed the NPC part of your question . Yes, an NPC entity using a LADER will automatically move to the end point of said ladder.

[Akari]

Oh, missed the NPC part of your question . 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.

[Synergy Blades]

is it a waiting-type opcode? I think it must stops the script execution until we reach start or end of ladder

Correct.

[Synergy Blades]

Akari: added 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]

Akari: added 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?

[Synergy Blades]

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.

[Akari]

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). ^^''

[Akari]

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?