Post Reply 
SaGa Frontier Battle Script Opcodes
12-31-2016, 12:56 PM (This post was last modified: 04-11-2017 09:25 PM by Neptuneknight.)
Post: #1
SaGa Frontier Battle Script Opcodes
This will be updated as more information is discovered.

Battle Script Opcodes
  • 12/31/2016 - First release (as draft), Updated opcode 13. Found out info about opcode 24.
  • 1/5/2017 - Added info on opcode 29.
  • 1/6/2017 - Added info on opcodes 21, 36, 60, 64.
  • 1/14/2017 - Added additional info on opcode 20.
  • 1/22/2017 - Added info on opcodes 23, 3E, 73, 75 and 77. Updated opcode 36.
  • 1/27/2017 - Added info on opcode 0F.
  • 2/28/2017 - Added info on opcode 34.
  • 3/5/2017 - Added info on opcode 6A.
  • 3/5/2017 - Added info on opcode 69.
  • 3/26/2017 - Added info on opcode 20.
  • 4/9/2017 - Added info on opcode 25.
  • 4/11/2017 - Added info on opcode 32, 58.

Code:
00 FF - OUT OF LOOP?
06 XX YY ZZ - Unknown
07 XX - Pause in Text?
0E VV WW XX YY ZZ AA BB CC DD FF - 0E, VV, WW, XX, YY sets the character IDs to participate in battle. ZZ Sets number of enemies in battle. AA,BB,CC,DD,FF are monster IDs.
0F XX - Related to the party selection menu prior to battle. 00 = No menu
10 XX - Sets Battle Background XX.
12 WW XX YY ZZ - Sets Party Position in the Battle.
13 VV WW XX YY ZZ AA BB CC DD - Command used to sets character WW's position on the Map in Battle Script. Total length of opcode is YY ZZ, starting with the 13.
          VV Takes several values depending on party members or monsters in battle.
          AA,BB are XX coordinates
          CC,DD are YY coordinates
14 VV WW XX YY ZZ - Unknown?
1F 01 YY ZZ - Unknown. Seen values of 00 02; 40 00; 00 80; 20 00
20 XX YY ZZ - Skip the next YY ZZ bytes? This includes the 4 bytes of this opcode. Seen XX=FF
21 VV WW XX YY ZZ - This is either a loop opcode, or perform only once. Once whatever condition is met, jump YY ZZ bytes. Seen 21 FF 00 01 YY ZZ.
22 AA BB CC DD EE FF GG - This is a JUMP code. Execudes following code if condition DD EE is equal(?) to BB CC. Otherwise, Jump FF GG bytes. May have to do with RAM.
23 XX YY ZZ - Reads the next YY ZZ bytes. Seen it used in Blue's battle vs. rouge, with XX=01 to display some text when Blue's LP is zero.
24 VV WW XX YY ZZ - For entity VV, if attack WW XX has been performed, continue with the code. Otherwise, skip the next YY ZZ bytes.
25 VV WW XX YY ZZ - For Entity VV, if HP is less or equal than WW YY, read the following YY ZZ bytes.
26 XX YY ZZ - Perform the following YY ZZ bytes for Entity XX? Dying animation usually follows.
28 VV WW XX YY ZZ - Unknown.
29 XX YY ZZ - Perform the following YY ZZ bytes of code for character XX? Used in Asellus' scenario for granting her access to mystic abilities. Does not need 00 FF afterwards.
2C XX YY ZZ - Unknown
2D VV WW XX YY ZZ - Entity YY performs attach XX WW on Entity ZZ
2E AA BB CC DD EE FF GG HH II - Animation-Related.

31 XX YY ZZ - Unknown (Not sure about byte length)
32 XX YY ZZ - Initial guess: Sets the entity YY's LP with value ZZ. seen XX=02. Changing XX could modify the property you are trying to set? Seen in battle with Blue, Mollasite
33 XX YY ZZ - Unknown.
34 VV WW XX YY ZZ - Enables/Disables specific battle characteristics on entity VV. WW=0 enable; WW=1 disable. ZZ is the battle characteristic to be affected. YY has effect on HP?
    34 VV 01 00 00 01 - Disables Entity VV from being attacked.
    34 VV 01 00 00 02 - Disables action during the battle turn for entity VV
    34 VV 01 00 00 03 - Disables Entity VV from taking any actions in battle
    34 VV 01 00 00 04 - Disables Visual HP Damage for entity VV
    34 VV 01 00 00 05 - Disables Entity VV from being targeted by attacks & healing spells/items
    34 VV 01 00 00 06 - Disables Entity VV from being targeted by attacks, from displaying damage after being attacked, and from selecting attacks. Still allows for selecting target for healing.
    34 VV 01 00 00 07 - Disables Entity VV from being targeted by attacks, from displaying damage after being attacked, from selecting attacks, and from being targeted for healing.
    34 VV 01 00 00 08 - No visible effects.
    34 VV 01 00 08 00 - Related to HP loop based on party's stats or BR? (Used on Bosses, VV=80)
    34 VV 01 00 10 00 - Infinite HP for entity VV? (Used by Virgil)
35 VV WW XX YY ZZ - Unknown.
36 XX YY ZZ - When XX=00, Increments variable YY ZZ by 1. And if XX=01, then decrease variable YY ZZ by 1.
37 VV WW XX YY ZZ -  Sets value YY ZZ to variable WW XX?
38 AA BB CC DD EE FF GG - Unknown.
3B AA BB CC DD EE FF GG HH II - Allows to modify entity AA's equipment slots. PC's can use all eight slots; Enemies only use the first 4 slots.
          BB - First Slot
          CC - Second Slot
          DD - Third Slot
          EE - Fourth Slot
          FF - Fifth Slot
          GG - Sixth Slot
          HH - Seventh Slot
          II - Eight Slot  
3C WW AA BB CC DD EE FF GG HH II JJ KK LL MM NN OO PP - Character/Enemy WW performs one of the following 8 actions:
                  AA BB - Attack 01
                  CC DD - Attack 02
                  EE FF - Attack 03
                  GG HH - Attack 04
                  II JJ - Attack 05
                  KK LL - Attack 06
                  MM NN - Attack 07
                  OO PP - Attack 08
3D VV WW XX YY ZZ - Something related with Enemy Entities.
3E XX YY ZZ - Unknown. Seen 3E 0A 25 00.
40 - In text, used as enter.
42 XX YY ZZ - Loads Text Box in Battle. XX is Character; YY is Length; ZZ is Number of lines for the text window.
The text opcodes in battle follows ASCII format.
60=A, 61=B, ...
49 XX YY ZZ - Unknown.
4A VV WW XX YY ZZ - Unknown.
4D XX YY ZZ - Action for Entity XX?
4E VV WW XX YY ZZ - Unknown.
51 VV WW XX YY ZZ - Unknown
52 XX YY ZZ - Unknown.
54 VV WW XX YY ZZ - Something related to abilities
55 VV WW XX YY ZZ - Transition to Battle Background.
56 VV WW XX YY ZZ - Entities VV WW XX YY ZZ disappear from battle.
57 XX YY ZZ - Dying animation YY for Monster XX.
58 AA BB CC DD EE FF GG HH II - Overwrites Entity AA's monster learnable abilities with BB CC, DD EE, FF GG, HH II
5A AA BB CC DD EE FF GG HH II - Associated with AA sprite animations while waiting for its turn to attack. 00-06 are valid arguments. Linked to opcode 3C.
5B AA BB CC DD EE FF GG HH II - Associated with AA sprite animations during the attack animation. 00-06 are valid arguments. Linked to opcode 3C.

60 AA BB CC DD EE FF GG HH II - Unknown. Seen with AA= FF.
64 VV WW XX YY ZZ - Something related to Entity VV.
66 XX YY ZZ - Something to do with creating monsters on the fly. Seen YY = 32, 64; XX = 00, 01.
67 XX YY ZZ - Character or monster XX is Enabled or Disabled (YY) in battle.
68 XX YY ZZ - Unknown
69 AA BB CC DD EE FF GG HH II - Permanently modifies stats for entity AA.
         BB = STR
         CC = QUI
         DD = INT
         EE = WILL
         FF = PSY
         GG = VIT
         HH = CHA
         II =  ???
6A VV WW XX YY ZZ - Alters in-battle properties of entity VV. Used during the master ring battle to load meiling's unconsuous sprite. Also used in 2nd Div. to give status effects.
6B XX YY ZZ - Pose YY for Entity XX
6C XX YY ZZ - Unknown
6D VV WW XX YY ZZ - Unknown
6E XX YY ZZ - Transition from One Background to Another? Used in the master ring battle.
73 FF - Unknown? Used in the Titania vs. MaskedGiant fight.
75 XX YY ZZ - Unknown? Used in the Titania vs. MaskedGiant fight.
77 XX YY ZZ - Unknown? Used in the Titania vs. MaskedGiant fight.
Find all posts by this user
Quote this message in a reply
12-31-2016, 05:30 PM
Post: #2
RE: SaGa Frontier Battle Script Opcodes
Isn't 0A FF start of script? Maybe an unconditional loop, that requires a break (00 FF) to escape?
Find all posts by this user
Quote this message in a reply
12-31-2016, 07:00 PM (This post was last modified: 12-31-2016 07:02 PM by Neptuneknight.)
Post: #3
RE: SaGa Frontier Battle Script Opcodes
(12-31-2016 05:30 PM)MysticLord Wrote:  Isn't 0A FF start of script? Maybe an unconditional loop, that requires a break (00 FF) to escape?

Could be, I haven't looked at ALL the scripts to see if they all begin with 0A FF.

Hmm, maybe you can give me a hand figuring out something here.
I'm looking at MBlackII's script. He has two "cycles of attacks", I need a bit of help as of what actually determines the change between one and another.

Here's some code...

Code:
3C 80
E8 01 - Vulcan
FE 01 - HeavyRailCannon
FE 01 - HeavyRailCannon
8C 01 - HE-Rocket
96 01 - MicroMissile
95 01 - AT-Missile
E4 01 - MoonScraper
DF 01 - Shoot-All
5A 80 06 06 06 00 00 00 00 00
5B 80 02 02 02 02 02 02 05 03
34 80 01 00 08 00
38 00 00 10 20 00 00 70
38 03 00 10 00 10 20 00
4A 80 07 00 00 10
37 00 0A 10 11 00
06 80 01 00 02 00
21 FF 02 1D 0A 00
32 00 80 64
00 FF
24 80 DF 01 32 00
37 00 0F 10 01 00
3C 80
7B 00 - Beat
7B 00 - Beat
7B 00 - Beat
17 01 - Graviton
17 01 - Graviton
E4 01 - MoonScrapper
E4 01 - MoonScrapper
F4 00 - MagneticStorm
5A 80 00 00 00 00 00 00 00 00
5B 80 01 01 01 04 04 05 05 05
00 FF
23 01 06 00
00 FF
26 80 08 00
57 80 64 01
00 FF

During the first cycle, MBlack uses a lot of projectile attacks. What I am interested in is how the game makes the transition to the next cycle. Code 24 80 DF 01 32 00 looks very suspicious. If you skip 32 bytes, you land on the 00 FF right after command 5B. Could it be comparing the current HP or something to DF 01? I've dealt roughly 40k of damage to MBlack II before this is triggered.
Find all posts by this user
Quote this message in a reply
12-31-2016, 07:17 PM (This post was last modified: 12-31-2016 09:27 PM by MysticLord.)
Post: #4
RE: SaGa Frontier Battle Script Opcodes
http://sf.data.project.tripod.com/Eroneo...status.txt

Try setting his HP at various values and see what happens.

EDIT

http://www.jce3000gt.com/forum/showthrea...07#pid4607

EDIT

Whoops, made a mistake. Check out the link again for correct values.
Find all posts by this user
Quote this message in a reply
12-31-2016, 08:45 PM (This post was last modified: 12-31-2016 08:46 PM by Neptuneknight.)
Post: #5
RE: SaGa Frontier Battle Script Opcodes
The 24 opcode I was suspicious about turned out to be an IF statement. MBlackII goes into the next cycle after using the Shoot-All attack. And that's after you've chopped down a considerable amount of his HP. How is this different from 22 now...
Find all posts by this user
Quote this message in a reply
12-31-2016, 09:27 PM (This post was last modified: 12-31-2016 09:28 PM by MysticLord.)
Post: #6
RE: SaGa Frontier Battle Script Opcodes
So are there different types of branches for different things? There isn't a single, catch-all conditonal branch/jump?
Find all posts by this user
Quote this message in a reply
01-07-2017, 11:55 PM (This post was last modified: 01-08-2017 01:38 AM by Neptuneknight.)
Post: #7
RE: SaGa Frontier Battle Script Opcodes
(12-31-2016 09:27 PM)MysticLord Wrote:  So are there different types of branches for different things? There isn't a single, catch-all conditonal branch/jump?

Yes, seems like it. Squaresoft, why do you do things so hard?

I am strongly suspicious about pointers being present IN the BATTLE SCRIPTS THEMSELVES. So many f@cking pointers. I am also strongly suspicious of the scripting/opcodes being compiled C. Makes sense with all the loops going on and what not.

I think the header is 0C bytes long...I wish we knew someone at Squaresoft that could provide us with the SaGa frontier scripting document. More to come...

By the way, do you remember ANY battle in which the music is changed throughout the script? Maybe silenced, or one song changed to another? Don't count the victory fanfare, I haven't been able to find out how that works yet. I am curious as to how to change songs in the middle of battle, yet haven't been able to come across anything.
Find all posts by this user
Quote this message in a reply
01-08-2017, 11:11 AM (This post was last modified: 06-20-2017 12:19 PM by MysticLord.)
Post: #8
RE: SaGa Frontier Battle Script Opcodes
(01-07-2017 11:55 PM)Neptuneknight Wrote:  Yes, seems like it. Squaresoft, why do you do things so hard?

I am strongly suspicious about pointers being present IN the BATTLE SCRIPTS THEMSELVES. So many f@cking pointers. I am also strongly suspicious of the scripting/opcodes being compiled C. Makes sense with all the loops going on and what not.

I think the header is 0C bytes long...I wish we knew someone at Squaresoft that could provide us with the SaGa frontier scripting document. More to come...
Multiple unique opcodes makes sense if they are method calls (or whatever it's called in C) with parameters. Would explain the differences between them.

Also means they can be decompiled to a degree, at least for convenience of commenting them.

I have a theory about how SaGa Frontier (and by extension most other SaGa games) was developed. It is in contrast to how the Final Fantasy games were developed. I may as well go into it now.

In Final Fantasy, everything is neat, organized, and planned in a hierarchical manner. One team is assigned to the menu module, one team to the battle module, one team to the field module, and one team to the world map module (which may or may not be a submodule of the field module - or vice versa).

Within each module, one or maybe two people handle each thing.

Menu Module
One person handles shop menus. One person handles the save system, accessible from and a submodule of the menu module. One person makes sure that the interfaces by which menu calls can be made from other modules is consistent. Several people test all of this.

Field Module
One person does the field graphics. One person programs the field scripting. Several people design the fields, the entities within them, their logic, and so on using the field scripting, all while the director moves between them and makes corrections or revisions. One person handles the transitions from the field module to the battle, menu, and world map modules.

... and so on, and so forth, for the Battle module and perhaps the World Map module.

You can tell Final Fantasy was made this way because everything is consistent. All the shops are in one place, in neat tables. You couldn't do that without:
1. Extremely good coordination within and between teams, or
2. One or two people handling one and only one thing.

We both know (via The Cutting Room Floor) that Square didn't even have revision systems early on, or their revision systems weren't used effectively. Chocobo's Dungeon was slated for release in the USA, but they deleted the source code!

Contrast this to SaGa Frontier, where the only discrete modules are the battle and the field modules. The shops are all over the place, there's redundant stuff everywhere, there sprites for field, battle, and menus are all in different places. There are files included in the disc image that were never used, there are printf strings scattered through various game files, and in general everything is a mess.

It's astonishing that this game was ever finished, but given that it as most of the way done and it's very functional, we can assume that they had a tool that people - non-programmers - could use to implement things like shops, scripted field events, and scripted battle events.

This tool may have had a GUI which allowed them to select the background images and sprites to be used, draw the walkmesh, and set up triggers for events using a few mouse clicks to determine where they would take place. It may have had a few simple programmatical constructs like the ability to create and modify variables (which we know were used, but not in any way that a sane programmer would use them).

My theory is that SaGa Frontier is the product of an extremely lazy director who told his programming team to give him a tool to let non-programmers do most of the work. The programmers complied and probably went back to playing video games, eating the Japanese equivalent of sausage pizza and beer, and generally being lazy slobs like most good programmers of the era were.

2nd Div and the debug room are good evidence for this being true, as they were both obviously slapped together, 2nd Div in the last minute.

My question for you is how can we use this theory to help us gain greater understanding of how SaGa Frontier works?

(01-07-2017 11:55 PM)Neptuneknight Wrote:  By the way, do you remember ANY battle in which the music is changed throughout the script? Maybe silenced, or one song changed to another? Don't count the victory fanfare, I haven't been able to find out how that works yet. I am curious as to how to change songs in the middle of battle, yet haven't been able to come across anything.

The victory fanfare is almost certainly hardcoded in BATTLE.OUT/ARC (same file, *.ARC is compressed and unfortunately the only one ever loaded into RAM).

I can't think of any battle where there was a song transition. Doesn't mean an opcode for it doesn't exist.

I do know that the music used in a battle is the result of a script. Red and Emelia's battles in the Shingrow arena come to mind.
Find all posts by this user
Quote this message in a reply
01-08-2017, 04:04 PM (This post was last modified: 01-08-2017 04:06 PM by Neptuneknight.)
Post: #9
RE: SaGa Frontier Battle Script Opcodes
(01-08-2017 11:11 AM)MysticLord Wrote:  I have a theory about how SaGa Frontier (and by extension most other SaGa games) was developed. It is in contrast to how the Final Fantasy games were developed. I may as well go into it now.

In Final Fantasy, everything is neat, organized, and planned in a hierarchical manner. One team is assigned to the menu module, one team to the battle module, one team to the field module, and one team to the world map module (which may or may not be a submodule of the field module - or vice versa).

Within each module, one or maybe two people handle each thing.

Menu Module
One person handles shop menus. One person handles the save system, accessible from and a submodule of the menu module. One person makes sure that the interfaces by which menu calls can be made from other modules is consistent. Several people test all of this.

Field Module
One person does the field graphics. One person programs the field scripting. Several people design the fields, the entities within them, their logic, and so on using the field scripting, all while the director moves between them and makes corrections or revisions. One person handles the transitions from the field module to the battle, menu, and world map modules.

... and so on, and so forth, for the Battle module and perhaps the World Map module.

You can tell Final Fantasy was made this way because everything is consistent. All the shops are in one place, in neat tables. You couldn't do that without:
1. Extremely good coordination within and between teams, or
2. One or two people handling one and only one thing.

We both know (via The Cutting Room Floor) that Square didn't even have revision systems early on, or their revision systems weren't used effectively. Chocobo's Dungeon was slated for release in the USA, but they deleted the fucking source code!

Contrast this to SaGa Frontier, where the only discrete modules are the battle and the field modules. The shops are all over the place, there's redundant stuff everywhere, there sprites for field, battle, and menus are all in different places. There are files included in the disc image that were never used, there are printf strings scattered through various game files, and in general everything is a mess.

It's astonishing that this game was ever finished, but given that it as most of the way done and it's very functional, we can assume that they had a tool that people - non-programmers - could use to implement things like shops, scripted field events, and scripted battle events.

This tool may have had a GUI which allowed them to select the background images and sprites to be used, draw the walkmesh, and set up triggers for events using a few mouse clicks to determine where they would take place. It may have had a few simple programmatical constructs like the ability to create and modify variables (which we know were used, but not in any way that a sane programmer would use them).

My theory is that SaGa Frontier is the product of an extremely lazy director who told his programming team to give him a tool to let non-programmers do most of the work. The programmers complied and probably went back to playing video games, eating the Japanese equivalent of sausage pizza and beer, and generally being lazy slobs like most good programmers of the era were.

2nd Div and the debug room are good evidence for this being true, as they were both obviously slapped together, 2nd Div in the last minute.

My question for you is how can we use this theory to help us gain greater understanding of how SaGa Frontier works?

From what I've seen while playing and testing out different opcodes, I want to say your theory absolutely correct. The data is scattered all over the place. The shops in Saga Frontier are nested into Event Scripts, which I came across a while back and found to be a very poor execution of concept. FF6 uses a single command and, when given the proper argument, gives you access to the desired shop. In contrast, here in SF you have to open a screen, command where the text will be lined up, insert blank spaces, insert the menu items, insert the cost, and last but not least insert the routines to buy/sell and add/remove items from your inventory. Extremely complicated if you ask me.

Also, I have mentioned before that event scripts are located in the .IMF files. Instead of an event being coded once to optimize space, they are coded as many times as needed per occurrence. Take for example Asellus' quest, right after she visits her aunt and defeats the fire sage. She is coded to encounter the other sages, then Ciato and Lion Princess. But this is random and can happen in several maps. Instead of the programmers optimizing this, each event is coded and copied several times for all the valid maps in which they can be battled. I had a hard time early on understanding why was I finding 5+ instances of the same event coded in the CD.

(01-08-2017 11:11 AM)MysticLord Wrote:  The victory fanfare is almost certainly hardcoded in BATTLE.OUT/ARC (same file, *.ARC is compressed and unfortunately the only one ever loaded into RAM).

I can't think of any battle where there was a song transition. Doesn't mean an opcode for it doesn't exist.

I do know that the music used in a battle is the result of a script. Red and Emelia's battles in the Shingrow arena come to mind.

Thanks for this info, there is only the BATTLE.ARC and BTL_DATA.BIN files when I look into CDmage. I will look into this further as I have some more time...
Find all posts by this user
Quote this message in a reply
01-08-2017, 09:12 PM (This post was last modified: 06-20-2017 12:22 PM by MysticLord.)
Post: #10
RE: SaGa Frontier Battle Script Opcodes
(01-08-2017 04:04 PM)Neptuneknight Wrote:  From what I've seen while playing and testing out different opcodes, I want to say your theory absolutely correct. The data is scattered all over the place. The shops in Saga Frontier are nested into Event Scripts, which I came across a while back and found to be a very poor execution of concept. FF6 uses a single command and, when given the proper argument, gives you access to the desired shop. In contrast, here in SF you have to open a screen, command where the text will be lined up, insert blank spaces, insert the menu items, insert the cost, and last but not least insert the routines to buy/sell and add/remove items from your inventory. Extremely complicated if you ask me.

Also, I have mentioned before that event scripts are located in the .IMF files. Instead of an event being coded once to optimize space, they are coded as many times as needed per occurrence. Take for example Asellus' quest, right after she visits her aunt and defeats the fire sage. She is coded to encounter the other sages, then Ciato and Lion Princess. But this is random and can happen in several maps. Instead of the programmers optimizing this, each event is coded and copied several times for all the valid maps in which they can be battled. I had a hard time early on understanding why was I finding 5+ instances of the same event coded in the CD.
Copypasta event scripting is the definition of laziness, especially when it comes at the expense of space (not that there isn't a lot of leftover space in SF, though). We can be lazy too once we figure it out. And the benefit of inheriting an unoptimized system is that you can optimize it. We have several ways to do this:
1. Optimize the implementation of the opcodes to save space in the implementation.
2. Optimize the implementation of the opcodes so they are more flexible, so they in totality take up less space (need fewer bytes, fewer opcodes, compress images, etc), or so they do more with same amount or less space. This will require a patch to go through all the opcodes and modify them, but that's doable if tedious.
3. Find ways in which the events can be optimized without changing the implementation. Only possible if the GUI field/battle editor wasn't optimized.

It's not necessarily a bad system. It's certainly easier to extend, as the only limiting factor is free space recovered from internal fragmentation (I assume you know what that means) and (sub-)file limitations imposed by the pointers.

Would be nice to have shops where we can sell all the useless crap you get.

(01-08-2017 04:04 PM)Neptuneknight Wrote:  Thanks for this info, there is only the BATTLE.ARC and BTL_DATA.BIN files when I look into CDmage. I will look into this further as I have some more time...
If you ever get into MIPS and want to modify (post-)battle routines, you need to either move BATTLE.ARC somewhere else or you need to make the game load BATTLE.OUT instead. Given that BATTLE.ARC is compressed, this may save some space in RAM as you can (maybe) remove the decompression code.

You need to do this because there is barely any space - maybe none at all - in the internal fragmentation found in the last sector where BATTLE.ARC is located. My bet is that loading "".OUT is easier. This thread and the links contained therein will be useful in this venture, should you get into ASM hacking, and if you decide to do so then this part of this post should be spun off into another thread dedicated to ASM hacks.

http://www.gamefaqs.com/boards/914326-va...y/70000670
https://archive.is/AU1i8

Valendian knows a lot, as does Gemini and a few other guys. You could conceivably study the PS1 compilers available (check RHDN and Gamehacking.org for links to specific sites, not something I'm familar with) to determine the ways in which C or C++ code was compiled for the system.

The guys at Qhimm are great too.

*.OUT is located in /MOUT.

EDIT

About opcode 0x36, it probably accepts an signed byte (-128 to 127) as a de/increment parameter and an unsigned short (0 to 65535) as an address parameter. Look at the INITDATA files, specifically the last part of the initial character data after the last character data block, and determine if that is the block used in event code.

http://sf.data.project.tripod.com/Eroneous_Waylay.html
^The 4 INITDATA files are sort of broken down here. They were broken down almost completely in the initial character data spreadsheet, but that's long gone.

In any case there's no way the game would need more than 65,536 bytes of memory to store all the event script variables, so wherever known event script variables are stored is probably it. Just need to locate the beginning and end of it... well actually just the beginning OR end, as we can guess the other.

And I just realized, we already know where some field variables are stored thanks to Zaraktheus' gameshark codes that modify event scripts.
Find all posts by this user
Quote this message in a reply
01-08-2017, 09:56 PM (This post was last modified: 01-08-2017 09:57 PM by Neptuneknight.)
Post: #11
RE: SaGa Frontier Battle Script Opcodes
(01-08-2017 09:12 PM)MysticLord Wrote:  It's not necessarily a bad system. It's certainly easier to extend, as the only limiting factor is free space recovered from internal fragmentation (I assume you know what that means) and (sub-)file limitations imposed by the pointers.

Would be nice to have shops where we can sell all the useless crap you get.

I am only a programmer at heart Grin, so you've been giving me great instruction the past couple of days with the MIPS literature and the info from earlier today. I had to google what internal fragmentation means.

(01-08-2017 09:12 PM)MysticLord Wrote:  If you ever get into MIPS and want to modify (post-)battle routines, you need to either move BATTLE.ARC somewhere else or you need to make the game load BATTLE.OUT instead. Given that BATTLE.ARC is compressed, this may save some space in RAM as you can (maybe) remove the decompression code.

You need to do this because there is barely any space - maybe none at all - in the internal fragmentation found in the last sector where BATTLE.ARC is located. My bet is that loading "".OUT is easier. This thread and the links contained therein will be useful in this venture, should you get into ASM hacking, and if you decide to do so then this part of this post should be spun off into another thread dedicated to ASM hacks.

http://www.gamefaqs.com/boards/914326-va...y/70000670
https://archive.is/AU1i8

Valendian knows a lot, as does Gemini and a few other guys. You could conceivably study the PS1 compilers available (check RHDN and Gamehacking.org for links to specific sites, not something I'm familar with) to determine the ways in which C or C++ code was compiled for the system.

The guys at Qhimm are great too.

*.OUT is located in /MOUT.
Will get to that in due time. All free time that I've been having will diminish from this week on. The only reason I've had enough free time this weekend was because of the snow storm passing through, which cancelled work Friday. I'm having lots of fun with the monster scripts. At some point I have to go back to the event scripting. But I feel like I'm close to making a complete custom monster script...

(01-08-2017 09:12 PM)MysticLord Wrote:  About opcode 0x36, it probably accepts an signed byte as a de/increment parameter and a short as an address parameter. Look at the INITDATA files, specifically the last part of the initial character data after the last character data block, and determine if that is the block used in event code.

http://sf.data.project.tripod.com/Eroneous_Waylay.html
^The 4 INITDATA files are sort of broken down here. They were broken down almost completely in my initial character data spreadsheet, but that's long gone.

I found it's being used in Deathlord (Sei's) script. The code 36 00 01 10 is used when each of his guards die.

Code:
26 81 08 00
36 00 01 10
26 82 08 00
36 00 01 10
26 83 08 00
36 00 01 10
26 84 08 00
36 00 01 10
00 FF

I believe it increments the value of variable 1001 (or RAM memory) by one. I am pretty sure that it's the case because at some point in the script it has the following condition:

Code:
22 00 01 10 04 00 A6 00

This is a check for the value of variable 1001 to be 0004 (meaning if all of his guards have been killed). If it isn't, then it jumps A6 bytes forward and skips the minionstrike attack.

I was hoping to find out how is it that Sei(Deathlord) has the vitalityrune/regen status applied to him, thinking to find a command that sets it up. It may be part of his initial data, which I'll look around later. Thanks for posting the links though.
Find all posts by this user
Quote this message in a reply
01-09-2017, 06:48 AM (This post was last modified: 01-09-2017 08:47 PM by MysticLord.)
Post: #12
RE: SaGa Frontier Battle Script Opcodes
(01-08-2017 09:56 PM)Neptuneknight Wrote:  I am only a programmer at heart Grin, so you've been giving me great instruction the past couple of days with the MIPS literature and the info from earlier today. I had to google what internal fragmentation means.
Gosh, here I was thinking they taught electrical engineers about OS development and memory management! But I kid, as I only got a once over of the high-level aspects of memory managers.

Internal fragmention occurs when either primary memory (usually called RAM, though that's technically not completely correct as it only designates the random-access nature) or secondary memory (a hard drive, but also not technically correct as a tape drive or solid state could be used) is divided up into discrete chunks of a specific length. For PS1 discs, this chunk is 2048 bytes for mode 1, form 1; and 2324 bytes for mode 1, form 2. (EDIT fixed the form/mode mistype)

If you have a file that isn't evenly divisible by 2048 bytes (if it contains no audio or video data, it will only ever be form 1), you will have to store the last part of that file in a sector, fill the remainder of that sector with zeroes, and store the next file in the next sector. This must be done because I assume PS1 hardware and software can't seek to a specific location within a sector to start reading, and because there isn't a field for the address of a file within a given sector.

I'll attach my notes on PS1 disc image stuff.

The sub-file limiations imposed by pointers is, if it's true and my guess is correct, caused by the variable address only being able to accept a short (int). It can only access address space between 0 and 65536, so logically it must be hardcoded to start writing to a specific location. The only way this would be otherwise would be if there is another opcode somewhere for setting the starting location of memory reads/writes, and if a field is set somewhere and the opcodes automatically check this field to determine where they should read/write from.

That is, since the current read/write location isn't explicitly set with access to the fulll address space of the PS1, we must assume that these opcodes are either hard-coded to use a much smaller address space, or there is an implicit address space that the opcodes use internally that can be set somehow.

EDIT

More details about optimizing the scripting systems.
1. Maybe the scripting systems weren't programmed as efficiently as possibly. Very likely, given how much compilers have improved since 1996. It may be possible to implement the scripting system - without changing the nature of the opcodes - so that the scripting system modules/core takes up less space.
2. Or, if we want the opcodes to take up less space, we could modify the scripting system modules to make better use of space in the opcodes themselves. Certain flags could be reduced from a full byte to a bit. If we want opcodes to be more flexible, we could reduce the number of opcodes while doing more with parameters. Both of these would require a program to go through all the event scripts and modify them to reflect the changes.
3. If the GUI event editors that the dev team used weren't very efficient and added unneccessary operations ( if a shop event needs only 30 operations instead of 51, or if you can eliminate certain operations for certain types of shops), then we can obviously edit the event scripts to remove these unneeded operations and free up space.

The actual editor we make should probably not be that high level. We can supplement the lack of user-friendliness with plenty of documentation for using each opcode, and guides for setting up certain types of shops and other events.

The limiting factor on script size for now is internal fragmentation, as we don't know how SaGa Frontier loads files. If it's hard-coded to search for specific files using the directory structure of PS1 discs, then we should be fine as long as we update the directories with valid information about the location and size of each file (though this will be a bitch to program the first time as it would involve lots of I/O and moving files around).

If it doesn't - if it's hard-coded to search in specific sectors for specific files, and doesn't use the internal directory structure - then we are somewhat screwed and can't make files larger or possibly smaller than their current size in sectors. We are only somewhat screwed because we have to do more work to figure out this method of loading and write something to deal with it.

But I have confidence in the laziness of the SaGa Frontier dev team. The least-effort method is to work with the directory structure. I doubt they would bother with anything else, as this is easiest in the long run.

/EDIT

(01-08-2017 09:56 PM)Neptuneknight Wrote:  Will get to that in due time. All free time that I've been having will diminish from this week on. The only reason I've had enough free time this weekend was because of the snow storm passing through, which cancelled work Friday. I'm having lots of fun with the monster scripts. At some point I have to go back to the event scripting. But I feel like I'm close to making a complete custom monster script...
I couldn't go to the grocery store to get more milk, very annoyed at that as I live off the stuff.

(01-08-2017 09:56 PM)Neptuneknight Wrote:  I found it's being used in Deathlord (Sei's) script. The code 36 00 01 10 is used when each of his guards die.

Code:
26 81 08 00
36 00 01 10
26 82 08 00
36 00 01 10
26 83 08 00
36 00 01 10
26 84 08 00
36 00 01 10
00 FF

I believe it increments the value of variable 1001 (or RAM memory) by one. I am pretty sure that it's the case because at some point in the script it has the following condition:

Code:
22 00 01 10 04 00 A6 00

This is a check for the value of variable 1001 to be 0004 (meaning if all of his guards have been killed). If it isn't, then it jumps A6 bytes forward and skips the minionstrike attack.
Make a save-state and search for these opcodes, I'm curious where this file is loaded into memory. I have a few ideas how to find the battle scripting field block too, would be very useful to know if you want to make your own scripts.

In fact, make several save states. One when you start a battle with Sei, one the round after each DeathKnight is killed, and one in the round after they are all dead. Put them in a *.zip and upload it.

Judging by the use of this one opcode in various scripts, does it seem that each battle script is allocated a specific number of bytes to use for variables? Or does it seem like it shares bytes with the event scripts?

(01-08-2017 09:56 PM)Neptuneknight Wrote:  I was hoping to find out how is it that Sei(Deathlord) has the vitalityrune/regen status applied to him, thinking to find a command that sets it up. It may be part of his initial data, which I'll look around later. Thanks for posting the links though.
I think that's SelfRepair, a lot of monsters have it.

http://sf.data.project.tripod.com/Eroneo...lities.txt

Code:
103 - Gelatin:
Stats:
HP:  2380
Str: 32
Qui: 36
Int: 16
Wil: 74
Psy: 68
Vit: 99
Cha: 28

Equip:
10: Knife
98: JerryArmor
EF: ThunderCharm
C6: SH-Anklet

Abilities:
00C5: BoltBreath
00DE: IllStorm
0ADA: Ectoplasnet
00C5: BoltBreath
34C6: BoltBlast
0ADA: Ectoplasnet
00BD: BoltBarrier
017F: SelfRepair

Actually no, it's DeathSynthesis.
Code:
141 - DeathLord:
Stats:
HP:  4000
Str: 41
Qui: 34
Int: 34
Wil: 40
Psy: 34
Vit: 44
Cha: 40

Equip:
94: PlutoArmor
9C: SkeleMail
7D: Mizukagami
D8: KrisKnife 3 3 3 13 13 13 13 43

Abilities:
00C0: Kusanagi
00D4: HPDrain
00F5: BattleSong
0886: CharmGaze
3CE1: SacredSong
0085: StunGaze
00D4: HPDrain
00FF: Deathsynthesis

Chariot is the only other enemy that has SelfRepair. Weird. I wonder if it works on humans and mystics? A lot of bosses would be tougher if they had regenerative abilities.

Anyway, this stuff is in the monster data files located in B_MDATA. They're in uncompressed ARC files, with a simple pointer table in the header. One of the subfiles is monster data, a few are palettes and sprites, dunno what the rest are.
http://www.gamefaqs.com/ps/198537-saga-f...faqs/47652

EDIT

Here is Valendian's post on the subject of BATTLE.OUT/ARC.

Valendian Wrote:Yes there are standard specifications. A whole host of them, collectively known as ISO9660, or more informally as "The Rainbow Books". Specifically ECM 119 and ECM 130. You don't need to worry about this stuff unless you are building CD Authoring Software. But I will give you an overview of the topic and you can look further if you wish.

http://www.ecma-international.org/public...ma-119.htm
http://www.ecma-international.org/public...ma-130.htm

ECM 130 specifies the physical structure of a CDROM. This details how the sectors are laid out, and some of the various formats a sector may take. The error correction is found within the sector. Each sector contains its own error detection and correction. There are different versions of sectors for different purposes. Music CDs don't require strong error correction as they can simply interpolate between that last good sector and the next good sector and no one would be the wiser. But data CDs place a much higher burden on the error correction. Such sectors sacrifice useable disc space for integrity against defects. It's a compromise between capacity and recoverability. But the error detection and correction is implemented as a Reed Solomon Product Like Code, with two channels. The inner channel ( called P Parity in ECM 130 ) is much weaker than the outer channel ( Q Parity ). P Parity can correct up to 2 bytes within a 28 byte block, but more importantly P Parity can be used to flag which 28 byte blocks contain errors that can be handled by the stronger outer channel which can recover up to 4 bytes per 28 byte block. But taken together both P and Q parity can provide almost perfect protection from defects. For you're information a P Parity check looks like this
P(x) = x^8 + x^4 + x^3 + x^2 + 1

To understand the Virtual File System you will need to read ECM 119. This will tell you more than you need to know about how files are organised on the physical disc. How sectors can be allocated to files, how you can move files to a new range of sectors, how you can resize a file, or even create new files and directories.

The first 16 sectors are reserved for system use. Sony use these sectors to store their license agreement data ( which by the way has invalid error correction / detection by design ) Then sector LBA=16 contains the Primary Volume Descriptor, all PSX discs have only one such descriptor but there may be multiple descriptors, called supplementary volume descriptors. PSX doesn't use them. The last volume descriptor is called the volume descriptor set terminator. This is found at sector LBA=17, Next follows the PathTable which is duplicated 4 times ( twice in little endian and twice in big endian for redundancy purposes ) You can use the Path Tables as a quick way to locate files given a file path. The path tables store only references to directories with no references to the files they contain. So to use the path table method you seek the directory then you scan that directory for the file. Its like a short cut, but actually requires that you write more code to make use of it. as the act of scanning a directory is all that is actually required and can be achieved without use of the path table. Once all of the path tables have been defined the next sector begins the root directory record. This contains directory entries for all the sub directories and files contained within the root directory. These record entries will tell you the file name its size and its sector number ( in the form of an LBA ). The only differences between an entry that refers to a sub directory and an entry that refers to a file are
[1] a sub directory will have the directory flag set in the flags field
[2] a file will have an extension and a ";1" appended ( if there are multiple files with the same name you would have "file.ext;1" then "file.ext;2" and "file.ext;3" and so on. ) The file names are listed in alphabetical order with no distinction between files and directories.

Now once you get to the stage where you have scanned a directory, found the file you are looking for and read all the sectors that compose that file into memory we begin to leave the world of nice specifications to follow and enter the world of Custom Virtual File Systems. This is when a software developer has implemented their own version of a Virtual File System that breaks up a huge archive into little bite sized chunks. This is why many people here will tell you that you don't need to deal directly with the ISO9660 File System as you may still have to deal directly with sectors and LBA's by manipulating these custom virtual file systems.

How do you find these LBA tables? Well you need to run pSX with logging enabled and you need to log all CDROM IO. now just play the game as normal and save the log. Any time you see a line in the log such as

[015b009c] cdrom: setloc 00000000:00000002:00000005

it will be closely followed by lines such as these
[015b00a4] cdrom: read byte 07801800 = 09 (800584dc)
[015b00a4] cdrom: write byte 07801800 = 01 (800584ec)

Those address in the brackets
(800584dc)
(800584ec)
Are a part of the function "setloc". mark the entry point of that function in your disassembly.
Place break points at the entry point. and follow execution to the jr without entering function calls ( use F7 to step into if you reach a jal use F6 to step over ) Once you have reached a range of addresses that you are familiar with you can reload a previous save state and inspect what is happening here. Where is that game engine obtaining the LBA? That will almost always be a large table of sector addresses


Attached File(s)
.txt  disc_image_io.txt (Size: 20.98 KB / Downloads: 0)
Find all posts by this user
Quote this message in a reply
01-09-2017, 09:03 PM (This post was last modified: 06-19-2017 11:19 PM by Neptuneknight.)
Post: #13
RE: SaGa Frontier Battle Script Opcodes
(01-09-2017 06:48 AM)MysticLord Wrote:  Gosh, here I was thinking they taught about OS development and memory management! But I kid, as I only got a once over of the high-level aspects of memory managers.

Lol, it may be that nowadays programs require students to take an operating systems course. Back in the day, I chose the Power Systems/Energy conversion path of EE, which really limited my choices on taking programming courses. I took Introductory C++, and then C++ parts 1 & 2. But that was about it. Other than that, I got heavy exposure to use MATLAB/Simulink. I also took an Artificial Intelligence course.

I enjoy programming very much, and have tried to incorporate it into work currently. It's not always possible to do that, so I've taken an interest into understanding how the games I used to play and love work. Starting with FF6, now with Saga Frontier. Breath of fire has also been an interest, but I haven't been as successful at finding where the events are. I am open to learning new ways to code and program, and an actual task/project would help facilitate the learning.

(01-09-2017 06:48 AM)MysticLord Wrote:  Make a save-state and search for these opcodes, I'm curious where this file is loaded into memory. I have a few ideas how to find the battle scripting field block too, would be very useful to know if you want to make your own scripts.

In fact, make several save states. One when you start a battle with Sei, one the round after each DeathKnight is killed, and one in the round after they are all dead. Put them in a *.zip and upload it.

Judging by the use of this one opcode in various scripts, does it seem that each battle script is allocated a specific number of bytes to use for variables? Or does it seem like it shares bytes with the event scripts?

I do have save states for each of the mystics battle just before Orlouge. I go into the events and modify the encounter to what I am currently studying/needing. I also go into the scripts and modify the parameters in the opcodes and see what happens during battle - I am not using a memory viewer right now. I can send you the save states I guess?

There are a specific amount of variables/RAM memory addresses assigned for battle, and that are common to all battle scripts. The battle against Virgil, GenocideHeart and Sei come to mind. GenocideHeart goes through several cycles which are determined by those variables.

(01-09-2017 06:48 AM)MysticLord Wrote:  http://sf.data.project.tripod.com/Eroneo...lities.txt
It's DeathSynthesis.
Code:
141 - DeathLord:
Stats:
HP:  4000
Str: 41
Qui: 34
Int: 34
Wil: 40
Psy: 34
Vit: 44
Cha: 40

Equip:
94: PlutoArmor
9C: SkeleMail
7D: Mizukagami
D8: KrisKnife 3 3 3 13 13 13 13 43

Abilities:
00C0: Kusanagi
00D4: HPDrain
00F5: BattleSong
0886: CharmGaze
3CE1: SacredSong
0085: StunGaze
00D4: HPDrain
00FF: Deathsynthesis

I think you are right. Skulldrake also has Deathsynthesis as part of the 8 available attacks. The programmers were just lazy IMHO. Instead of coding the regeneration to happen during every turn without sacrificing an attack, they did that crappy thing. Variety is the spice of life. Jesus.

Thank you again for your help and for the posts.
Find all posts by this user
Quote this message in a reply
01-10-2017, 09:49 AM (This post was last modified: 06-20-2017 12:47 PM by MysticLord.)
Post: #14
RE: SaGa Frontier Battle Script Opcodes
I just read books and do a lot of personal projects these days. Not even getting a CS degree anymore.

I have no advice on finding events except save state or ROM corruption, but that is slow as hell. I need to make a tool that allows more focused corruption, replacing all instances of a value between any two addresses, while also being aware of word size and endianness.

I don't know about you, but I hate reading and being lectured about theory. Theory is mostly useless. Rules of thumb, trial and error, having focused goals, simplifying complicated stuff, and minimizing my exposure to negative black swans (https://en.wikipedia.org/wiki/Black_swan_theory) is how I learn and improve my craft.

The best piece of advice I can give you is to make small, mostly harmless mistakes and learn from them. Set things up so when something fails, it fails small and in a way you can easily go in and look at things to see what's wrong (ie, get your print statements working so you can see what is wrong). Once you have something set up and working, you can refactor it in a more object-oriented way if you like.

Every single time I don't try the simplest possible method of doing something it always blows up in my face and wastes months of my life.

(01-09-2017 09:03 PM)Neptuneknight Wrote:  I do have save states for each of the mystics battle just before Orlouge. I go into the events and modify the encounter to what I am currently studying/needing. I also go into the scripts and modify the parameters in the opcodes and see what happens during battle - I am not using a memory viewer right now. I can send you the save states I guess?

There are a specific amount of variables/RAM memory addresses assigned for battle, and that are common to all battle scripts. The battle against Virgil, GenocideHeart and Sei come to mind. GenocideHeart goes through several cycles which are determined by those variables.
If you already know where the battle scripting address space is, there's no point in sending me some save states - just update the OP. Actually I could make the save states myself and check them if I ever get my Windows machine working again.

(01-09-2017 09:03 PM)Neptuneknight Wrote:  I think you are right. Skulldrake also has Deathsynthesis as part of the 8 available attacks. The programmers were just lazy IMHO. Instead of coding the regeneration to happen during every turn without sacrificing an attack, they did that crappy thing. Variety is the spice of life. Jesus.

Thank you again for your help and for the posts.
They would need a flag for undead-ness (and plant-ness, coincidentally). It allows more flexibility with monster forms, so I guess it's not all bad. I'd rather they put it on a piece of equipment that's undead/plant-specific though.

It's not bad becuase it's probably organized in such a way that it's easy to point an in-battle effect to an equipped ability (if all the ability effects are stored in a pointer table somewhere that is checked each round). That's how Fire/Ice/BoltBarrier, Reflect (?), and CounterFear work too.
Find all posts by this user
Quote this message in a reply
01-23-2017, 04:54 PM (This post was last modified: 01-23-2017 04:55 PM by Neptuneknight.)
Post: #15
RE: SaGa Frontier Battle Script Opcodes
I thought it'll be interesting to look at the Scripted Battle between MaskedGiant and Titania.

Code:
Titania vs. MaskedGiant
0A FF 36 00 42 00 0D 00 04 00 78 00 52 00
10 40
12 00 04 00
1F 01 00 40
0F 00
01 CD 00 00 00 00 09 FF
01 5D 00 00 00 00
1F 01 00 80
1F 01 00 02
1F 01 00 10
00 FF
21 FF 00 01 34 00
37 00 0A 10 45 00
32 00 00 64
3C 00
93 00 8F 00 99 00 AE 00 8F 00 8E 00 F6 00 8F 00 - Titania's script
3C 80
8F 00 8F 00 8F 00 8F 00 8F 00 A3 00 7F 00 D9 01 - MaskedGiant's script
21 FF 00 04 0C 00
34 80 01 00 02 00
00 FF
21 FF 00 01 0A 00
75 07 70 00
22 00 01 10 00 00 16 00
25 00 4B 00
0E 00
36 00 01 10
77 01 70 00
22 00 01 10 01 00 16 00
25 00 1E 00
0E 00
36 00 01 10
77 01 70 00
38 04 02 10 00 40 05 00
22 00 02 10 00 00 0E 00
73 FF
06 08 70 00
73 FF
00 06 70 00
Find all posts by this user
Quote this message in a reply
01-24-2017, 07:53 AM
Post: #16
RE: SaGa Frontier Battle Script Opcodes
36 XX YY ZZ - When XX=00, Increments variable YY ZZ by XX. And if XX=01, then decrease variable YY ZZ by 1.
^Are you sure this is correct?

Shouldn't it read:
36 XX YY ZZ - When XX=00, Increments variable YY ZZ by 1. And if XX=01, then decrease variable YY ZZ by 1.
Find all posts by this user
Quote this message in a reply
01-24-2017, 12:51 PM
Post: #17
RE: SaGa Frontier Battle Script Opcodes
(01-24-2017 07:53 AM)MysticLord Wrote:  36 XX YY ZZ - When XX=00, Increments variable YY ZZ by XX. And if XX=01, then decrease variable YY ZZ by 1.
^Are you sure this is correct?

Shouldn't it read:
36 XX YY ZZ - When XX=00, Increments variable YY ZZ by 1. And if XX=01, then decrease variable YY ZZ by 1.

Yes, sorry about the typo. I have fixed it in the original post. About the titania post, I am suspicious about the part
Code:
0F 00
01 CD 00 00 00 00 09 FF

CD = Titania but I wonder if the 0F 00 in front makes her act like a PC, like on FF6 with characters acting as enemies and what not.
Find all posts by this user
Quote this message in a reply
01-25-2017, 10:12 PM (This post was last modified: 02-12-2017 06:49 PM by MysticLord.)
Post: #18
RE: SaGa Frontier Battle Script Opcodes
Is 0F 00 used in any other scripts? Look in multi-monster battles first.

Edit

If you want an example of poor coding, check out this thread:
http://forums.qhimm.com/index.php?&topic=17296

Note that SaGa Frontier also uses AKAO sound files, IIRC.
Find all posts by this user
Quote this message in a reply
03-02-2017, 01:13 AM (This post was last modified: 03-02-2017 01:17 AM by Neptuneknight.)
Post: #19
RE: SaGa Frontier Battle Script Opcodes
(01-08-2017 11:11 AM)MysticLord Wrote:  It's astonishing that this game was ever finished, but given that it as most of the way done and it's very functional, we can assume that they had a tool that people - non-programmers - could use to implement things like shops, scripted field events, and scripted battle events.

Well this is the only picture I could find of its kind - it is a GUI from the beta version of SF! What's shown on the picutre is parts of the SSS. I wonder if this has been leaked anywhere online?
[Image: saga-frontier-untraslated-text1.png]
Find all posts by this user
Quote this message in a reply
03-03-2017, 09:54 PM (This post was last modified: 03-03-2017 10:00 PM by MysticLord.)
Post: #20
RE: SaGa Frontier Battle Script Opcodes
https://www.unseen64.net/2009/01/25/saga...-concepts/

https://www.unseen64.net/2008/07/12/rs-l...-frontier/

Download every image in these webpages and the webpages themselves. Also put them all through archive.is - this is too useful. Check the comment sections too.

https://www.unseen64.net/contact/
^You can contact the author of the webpage here, see if you can get any more screencaps from him.

If you can get your hands on demo discs or Playstation Club (wrong name?) demo discs from the era. Here's a cached link:
https://webcache.googleusercontent.com/s...clnk&gl=us

Here's one:
https://www.youtube.com/watch?v=EduBebdLmMk

Another:
https://www.youtube.com/watch?v=Fp1_pAp2J_U
Find all posts by this user
Quote this message in a reply
Post Reply 


Possibly Related Threads...
Thread: Author Replies: Views: Last Post
  BATTLE.OUT File Neptuneknight 20 1,176 08-27-2017 02:43 AM
Last Post: MysticLord
  SaGa Frontier Game Data and Resources Neptuneknight 12 1,530 05-27-2017 11:58 AM
Last Post: JCE3000GT
  Japanese Scripted Battle Events Neptuneknight 1 282 03-26-2017 11:52 PM
Last Post: MysticLord
  SaGa Frontier Game Dialogue Dump Neptuneknight 7 448 01-06-2017 01:35 AM
Last Post: MysticLord
  SaGa Frontier Tools for Internal Use Neptuneknight 7 489 01-05-2017 12:14 PM
Last Post: MysticLord
  SnakeOil - SaGa Frontier Data Editor MysticLord 4 977 12-31-2016 11:30 PM
Last Post: MysticLord
  In-Battle Status Blocks - RAM MysticLord 0 268 12-31-2016 08:40 PM
Last Post: MysticLord
  Saga Frontier Monster Script Data Viewer GUI Neptuneknight 8 639 12-31-2016 05:33 PM
Last Post: MysticLord
  SaGa Frontier Scenario Scripting System (SSS) Neptuneknight 1 616 07-26-2016 05:33 AM
Last Post: MysticLord

Forum Jump:


User(s) browsing this thread: 1 Guest(s)