Messages

1

Scripting and Reverse Engineering / Re: [FF7] battle.lgp model files to scene.bin enemy ids lookup

« on: 2022-01-17 08:54:39 »

Thanks @sithlord48, this is useful, but I'm wondering how these IDs were derived.

I can make the assumption that the enemy model hrcs are sequentially based aa,ab,ac, 1,2,3 etc, and I've found the exe offset for the playable characters (FROG -> CHAOS, ff7_en.exe, 0x004FE310), but I would be interested in if anyone could explain HOW or where they found the data linking the scene.bin enemy IDs to the battle models in battle.lgp.

I'd prefer not to hardcode it in what I'm doing but generate the information from the sources.

@halkun Any Ideas?

2

Scripting and Reverse Engineering / [FF7] battle.lgp model files to scene.bin enemy ids lookup

« on: 2022-01-16 14:35:28 »

Hi,

I'm just adding battle models (battle.lgp) and scene.bin exporting to kujata (see https://dangarfield.github.io/kujata-webapp/battle-models for previews) and fenrir and I'm unsure about how to correlate the battle models to the enemy IDs.
I assume there is a table in the exe / some data file but I haven't found it yet in the battle directory.

Eg:
Elfadunk - Scene.bin ID: 76 (0x4C) - battle.lgp model: cyaa
Mandragora - Scene.bin ID: 79 (0x4F) - battle.lgp model: dbaa
Levrikon - Scene.bin ID: 80 (0x50) - battle.lgp model: dcaa

I can approximate this roughly (aa = 0, ab = 1, ac = 2... cy = 25 + 25 + 24 + 3 = 76, but I just wanted to check that there isn't a better way of looking this up.
Also the same for the playable character files. Any locations in exe memory or data files I should be looking?

3

FF7 Tools / Re: [PC] Text editor - touphScript (v1.4.0)

« on: 2021-01-15 13:27:15 »

I've documented usb's notes, created a brief readme on 1.4 usage and configuration and added to a github fork. Just waiting for the owner to merge the pull request.

Hopefully this should help a little. My fork: (until it is merged) https://github.com/dangarfield/touphscript#toughscript

4

Scripting and Reverse Engineering / Re: Understanding the LINE field op code

« on: 2020-09-09 16:24:43 »

After investigation, I've updated the points above and will update the wiki too: http://wiki.ffrtt.ru/index.php?title=FF7/Field/Script/Opcodes/D3_SLINE

If you have any further insights, please reply or update the wiki.

Thanks

5

Scripting and Reverse Engineering / Understanding the LINE field op code

« on: 2020-09-08 17:03:38 »

Hi,

I'm just playing around LINE field op code (0xD0) and have a few questions about the game behaviour.
I'll update this after:
http://wiki.ffrtt.ru/index.php?title=FF7/Field/Script/Opcodes/D0_LINE

There are generally 6 scripts (other than the init and main) if the entity is a LINE (taken from Makou Reactor):

  script index 2 -> S1 - [OK]
  script index 3 -> S2 - Move
  script index 4 -> S3 - Move
  script index 5 -> S4 - Go
  script index 6 -> S5 - Go 1x
  script index 7 -> S6 - Go away

[OK]
Occurrences - This is often present, but mostly contains a single RET op code.
Behaviour - I'm sure this is triggered when the player is close to the line and presses the [OK] button, eg blin59

Move
 - Occurrences
The script index 2 Move is often present, but again mostly contains a single RET op code.
The script index 3 Move is not often present but when it is, the script index 2 typically isn't, again, always ends with a RET.
There are 11 occurrences when both index 2 & 3 Move are present and both have more than one single RET op code.
10 of these contain exactly the same ops in both (fields - hyou4, hyou5_4)  - A REQEW and a RET with exactly the same params. Every one of these leads to a MAPJUMP.
1 of these (field - del12) contains 2 ops in the index 2 Move script (UC,MENU, and no RET). The index 3 Move script contains 11 ops including a final RET op

As a result of the above, I believe that it is relatively safe to assume the following logic:

 - Behaviour
This is triggered every time the player is close to the line.
If the index 2 Move is present, it executes until it receives a RET or finishes all of the ops, then
If the index 3 Move is present, it executes until it receives a RET or finishes all of the ops.

Go
Occurrences - This is often present, and always contains a final RET op code.
Behaviour - I'm sure this is triggered every time the player leaves the line

Go 1x
Occurrences - This is occasioanlly present, and always contains a final RET op code.
Behaviour - I'm sure this is triggered when the player leaves the line, but only once for the duration of the time in the field. Come examples are doors remaining open after they are programmatically triggered. bugin2.

Go away
Occurrences - Can be present alongside Go and Go 1x. Always contains a final RET op code.
Behaviour - Very similar to Go, but the distance that the player has to be away from the point is large (maybe 4x). Examples are the jumps on las0_6

It's worth noting that any combination of Go, Go 1x and Go away can be present an executable on any script.

Here is a JSON file containing a little more details on the occurrences, frequencies and combinations of the LINE op code usage: https://github.com/dangarfield/ff7-fenrir/blob/master/workings-out/output/line-occurences.json


Updates:
- Updated Move occurrences and behaviour- Should be final
- Updated Go, Go 1x & Go Move - Should be final

No further updates required.

Thanks,
Dan Garfield

6

Team Avalanche / Re: Project Edge (Jusete's field scenes)

« on: 2020-09-08 12:02:39 »

Great job! How are you dealing with slicing the 'semi transparent layers, e.g. Where the game uses additive or subtractive blending? Are these included in the sliced output also or it is just ignored? Same with param and state layers? Are they included too? I may have something that may be able to help identify and seperate later if you're interested

7

General Discussion / Re: Rendering Fields - Incorrect transparency logic

« on: 2020-08-19 09:34:12 »

Perfect, solved it within 30 seconds after looking at this document.

In this instance, the answer was getting the FIRST pixel from the tiles' specified palette if the texture-palette-pixel was 0x000000.

eg I'm intentionally using and improving Kujata json objects

paletteItem = flevel.palette.pages[tile.paletteId][textureByte]
if (paletteItem.r === 0 && paletteItem.g === 0 && paletteItem.b === 0 && paletteItem.a === 0) {
  paletteItem = flevel.palette.pages[tile.paletteId][0]
}

8

General Discussion / Rendering Fields - Incorrect transparency logic

« on: 2020-08-18 18:55:58 »

I'm having two problems working with fields, this is the first of them, please can you help?

It's to do with the treatment of 0x000000 colours from the palettes, which depending on the bit mask should be transparent, but I can see in Makou Reactor, you get the correct colour. Here's an example:

2 images, One is Makou Reactor output, the second is my attempt. Map - mds5_1



Note: This is purely one tile on one layer. There are no other tiles that render in the destination position so all of the data has to be in the tile / palette. The example below are the first two pixels in the top left corner of the top left tile.

Tile details:
 Tile 383
 x destinationX -256 -> normalisedOverlayX 0
 y destinationY -256 -> normalisedOverlayY 0
 depth 1 z 4095 (eg tile.id)
 palette 3 (paletteId)
 texture sourceX 0 sourceY 128 -> 0,0 bytePosition 65536
 layer 0 z 4095 id 4095
 param 0
 state 0
 blending 0
 typeTrans 0

Pixel at tile position 0,1 is perfect:
 x 0 1 -> 1
 y 128 0 -> 0
  textureByteOffset 32769
  textureByteID 1 (ref to page/palette)
  paletteByte 4261 -> 0x0010A5
  color usePalette=true
  hex { r: 41, g: 41, b: 33, a: 255, hex: '292921' }

Pixel at tile position 0,0 is wrong:
  x 0 0 -> 0
  y 128 0 -> 0
  textureByteOffset 32768
  textureByteID 224 (ref to page/palette)
  paletteByte 0 -> 0x000000
  color usePalette=true
  hex { r: 0, g: 0, b: 0, a: 0, hex: '000000' }

Current logic for textureByteValue to hex is:

let COEFF_COLOR = 255 / 31 // eg translate 5 bit color to 8 bit
const getColorForPalette = (bytes) => { // abbbbbgggggrrrrr
    const color = {
        r: Math.round((bytes & 31) * COEFF_COLOR),
        g: Math.round((bytes >> 5 & 31) * COEFF_COLOR),
        b: Math.round((bytes >> 10 & 31) * COEFF_COLOR)
    }
    color.a = color.r === 0 && color.g === 0 && color.b === 0 ? 0 : 255
    color.hex = `${stringUtil.toHex2(color.r)}${stringUtil.toHex2(color.g)}${stringUtil.toHex2(color.b)}`
    return color
}

I was currently thinking about whether this is black or fully transparent, eg using the alpha bit above, but the desired pixel is a dark brown (around 0x302921) and there are a number of other pixels that follow this pattern also.

What am I missing? Can you point me in the right direction please. Even if it's just pointing towards a few lines of Makou Reactor. Whilst I've been through it a number of times, I can't easily see the answer. Thanks

9

Scripting and Reverse Engineering / Re: Rendering Fields without Palettes, any tips?

« on: 2020-08-08 06:21:00 »

Perfect. Thanks!

10

Scripting and Reverse Engineering / Re: Rendering Fields without Palettes, any tips?

« on: 2020-08-02 08:55:51 »

Typo - '12' bits -> '12' bytes

This seems to be happening only on depth 2 tiles.

Also. just to clarify, when I'm saying. When converting the texture to a color directly without a palette, I am:
- Splitting the texture into a array of bytes equal to depth. Eg, depth 1 = 1 byte arrays to get a palette color, depth 2 = 2 byte arrays
- Using the texture byte value, I get the 2 byte array value, and translate this into a colour in the same normal way (5 bit to 8bit).

I'm just getting some funny results:


Any tips?

11

Scripting and Reverse Engineering / Rendering Fields without Palettes, any tips?

« on: 2020-08-01 20:12:44 »

Hi all,

I'm just having a look at reconstructing fields on a layer by layer approach for something I'm doing and am adding some code to picklejars' kujata repo. Whilst I do have a few questions that I may post to this community to help me understand and I'm am constantly looking through the Makou Reactor source code for tips, there is something that I just want to run by you.

I've decoded all fields except these:
'blin67_4',
  'nivgate2',
  'nivgate3',
  'nivl_e3',
  'gldst',
  'gldinfo',
  'rckt3',
  'kuro_11',
  'hyoumap',
  'gaiin_6',
  'trnad_52',
  'junone22',
  'rckt32',
  'jtemplc'.

The reason being is that the palette lengths are '12' bits, headers something like:
{
  length: 12,
  palX: 0,
  palY: 480,
  colorsPerPage: 256,
  pageCount: 0,
}

The thing here is pageCount = 0. So there are no palettes. None (other than the 6 colors on the flevel.background.palette object). So my question is, how do we overcome this? How do we get the rendered data? I've tried swapping calculating the colour from the texture value itself instead of accessing a palette, but no luck.

Any ideas? Apologies if I have missed something in Makou Reactor.

Thanks,
Dan

12

Catalogs / Re: [FF7] Qhimm Catalog 3.0 Reports / Requests

« on: 2020-07-03 16:08:46 »

Hi,

Just having a look through this and am very impressed.

I would love to see a mod in 7th Heaven that (maybe selectably) includes the 85 amazingly reworked fields from Jusete's Project Edge fields, but for the ones that have not been done yet, the upscaled ones from Remako are used.

Is there is a way to selectively import, or would I have to unpack both .iros and merge the contents into one superset?

13

Team Avalanche / Re: Project Edge (Jusete's field scenes)

« on: 2020-07-03 15:38:15 »

This is maybe not the right place for this (and I have had a search around this forum a little - and the 7th Heaven one also), but I have a desire:

I would love to see a mod in 7th Heaven that includes these 85 (maybe selectably) amazingly reworked fields, but for the ones that have not been done yet, the upscaled ones from Remako are used. I might post this on the 7th Heaven board too.

Note: Whilst I'm not a C* based developer, I write code on a daily basis so may be able to assist and would love to contribute towards this project. If not in a modelling capacity, then in a coding or administrative role (I don't know why you don't have a trello board of maintained status page for Team Avalanche. This is my first day of looking, will love to get involved gradually.

14

Team Avalanche / Re: Project Edge (Jusete's field scenes)

« on: 2020-07-03 13:42:32 »

@jusete This is freaking unbelievable quality. Amazing work and an amazingly ambitious undertaking.
I'm just getting back to playing FF7 and saw this and just wow, seriously great work.

I'm wondering if you would be able to put up a completion status summary on the first post (x of x renders complete, etc), I have no idea of how many fields there are in total, but I'm interested in the completeness of this. Of course, I'll be donating too to help make this thing a reality. Amazingly high quality, very impressed!