Show Posts
226
Releases / Re: [FF7PC-98/Steam] New Threat Mod (v2.0.94)
« on: 2021-01-22 12:05:55 »ahoy folks,
my new years resolution was to start working on a small side story with Aerith running around midgard and selling herbs/flowers.
I got the game engine script by Joshua and the qhimm team and am currently reading through it.
do you guys have any additional documentation/tips/tutorials on how to access the field module and modify scene transitions/characters/script?
much appreciated
You'll need Myst6re's Makou Reactor tool: http://forums.qhimm.com/index.php?topic=9658.0
This opens the game's flevel.lgp in data/field (or if you open a PSX disc with it, it'll open the FIELD folder contained inside with all the .dat field files). Each field contains script groups with an init, main, talk, contact, and then numbered scripts.
Some quick pointers:
Each field will contain 'groups' which are actors, objects, or just script containers for the game to read & execute script from. Generally each will have these types of scripts (except for Line groups, more later):
Init: Is read when the field is loaded. The game will read each actor/object init script in sequence. Try and avoid putting any looping logic into these scripts for if the game is unable to exit one of these loops in an init script, the field will never finish loading. These are usually used to place actors on the field and set starting parameters like music, etc. Think of it as setting the stage before the curtain comes up and shows you what's on the screen.
Main: These always run after the field is loaded. Usually used to have characters do things in the background, or to make a scene trigger automatically when you enter the screen.
Talk: Activates when controlled actor talks to this object.
Contact: Activates when controlled actor makes collision with this object.
Script 3-30; these only run if they are specifically called by field script elsewhere. If an empty script is called (try and avoid this) it will check the next script above it until it finds code to run.
Scripts can be called in three ways:
Synchronously: The calling script will wait until the called script has finished before proceeding.
Asynchronously (Wait): The calling script will continue while the called script plays independently of it; if the actor is busy then the request to run a script will queue and execute when available.
Asynchronously (No Wait): The calling script will continue while the called script plays independently of it; if the actor is busy then the request to run a script will silently fail.
The game can run something like 8 script concurrently. Usually this is more than enough, but if you get too liberal with the use of Main scripts and don't properly terminate scripts that you run then you can end up chokepointing the engine which will cause new scripts to not run or a softlock. When executing scripts, remember to terminate them properly with a return opcode.
There is a different type of object with different script groups; it's a Line group. These are event lines that activate when crossed by the player and are drawn by 2 sets of coordinates. These lines can be cleared/set based on different conditions. Some activate on contact, others require that the player push Confirm (Turtle Paradise flyers for instance).
The game uses variables to manage its logic. There are several 'banks' which can take 1byte or 2byte values. One important thing to note is that the locations used to write 1byte and 2byte addresses are actually the same. An example below:
To write a 1byte value to a bank, you'd use [1][100]
To write a 2byte value to a bank, you'd use [2][100]
[2][100] will read/write values to [1][100] and [1][101], so if you wrote a value to [1][100] and then wrote another value to [2][100] believing it to be a separate memory location then you'd accidentally overwrite the value held at [1][100] so keep that in mind.
Just in case, a 1byte value is 0-255 (in hex this is 0xFF) so you can't push a value higher than 255 into a 1byte memory address. To achieve a higher number, a 2byte value is needed and can reach 65535 (in hex, this is 0xFFFF; in other words, it's two 1-byte values read together).
Bank 5/6 is where temporary variables are stored. Any value held here will be lost once you leave a field, so only use this for temporary handling like dialogue decisions.
In order to more efficiently use variable space, the game will often use bit flags on each variable instead of writing a value to it. These are shown in the tool as 'Bit 1 ON' or 'Bit 0 OFF'. Each 1-byte address can hold 8 'bit flags' which is efficient for things like flagging when items have been picked up as instead of having a separate variable tracking each item we can have 1 variable track 8 item pickups instead. Each bit flag adds a value to the address which, when all are toggled, will add up to 255.
Bit 0: 1
Bit 1: 2
Bit 2: 4
Bit 3: 8
Bit 4: 16
Bit 5: 32
Bit 6: 64
Bit 7: 128
If you picked up the item that uses Bit 0 and the item that uses Bit 7, then the variable would have a value of 129. In this way, the variable can have unique values for the game to evaluate against and check if certain items have or have not been picked up. Bit flags like this are used for other tasks as well, such as event management, so you'll need to get used to seeing them and using them. Just think of them as 8 flags you can turn on and off for a variable.
The Makou Reactor tool can tell you what variables are used or not, but some modules outside of field will use certain variables. To be safe, use [11][255] if you need to use new variables and work your way down from there.
In order to learn how to do things, the best way is to study the scripts that exist in the game but I would avoid looking at the Midgar fields as these are much less consistent between each other and seem to have been built at varying times during development (so the method for doing things is a bit less efficient or flat-out different in some cases which can be confusing). Think of a scene you're fairly familiar with and which is easily triggered from a nearby save point and then study the scripts that make it happen to get a better idea of how things are put together and executed.
Last thing: Save (and test) Regularly.
It would be nice, if this was a morph / drop / steal on some enemy, too.
