Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.


Topics - dangarfield

Pages: [1]
1
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?

2
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

3
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


4
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

Pages: [1]